Kuinka rakentaa alustatiimi nyt! onnistuneen suunnittelun salaisuudet

TLDR; Skaalausjoukkueet ovat kovia. Oikein tehty alustustiimi voi auttaa lievittämään vaikeuksia.
Alusta keskellä merta (Hyvä metafora tavalliselle laituritiimien eristämiselle)

Conde Nast International -tapahtumassa kasvoimme 20 insinöörin ryhmästä alle 100: aan alle vuodessa. Huomasimme, että monilla markkinoilla käytettävän järjestelmän rakentamisessa on paljon liikkuvia osia ja toistoa. Esimerkiksi infrastruktuurin ja sovellusmääritysten uudelleenrakentaminen. Kolmannen osapuolen lisäosiohjelmiston lisääminen. Sovelluksen rakentaminen CDN-uudelleenohjauksia käyttämällä. DNS-rekisteröinti ja määritykset.

Oli monia AWS-tilejä, joita monet ryhmät käyttivät. Käyttötarkkailun seuraaminen oli sotkua. Jokaisen kehittäjän täytyy miettiä missä ja miten käyttää järjestelmäänsä. He tekevät niin yleensä toisistaan ​​riippumattomasti. Heidän on ajateltava seurantaa ja kirjaamista. Tähän sisältyy myös sekalaisia ​​alajärjestelmiä, kuten jonossa tapahtuvaa kirjaamista, joka ottaa käyttöön ja reitittää liikennettä.

Oli paljon asioita, jotka olisimme voineet tehdä prosessista paljon helpompaa ja sujuvampaa. Tämä on ensisijainen syy, miksi päätimme rakentaa infrastruktuuritiimi sitten myöhemmin alustatiimiksi.

Alustatiimi

Platform-tiimi

Alustatiimi ei ole osa tuoteryhmiä, vaan toimii teknisen tehokkuuden ryhmänä. Tämä tarkoittaa, että alustatiimin tärkein asiakaskunta on tuoteryhmät. Mainitun tuoteryhmän on myös opittava alustasta yleensä. Ota sitten esiin aiheita ja tue jatkuvaa parantamista (uusi CI). Tämä ei tarkoita, että alustatiimi olisi eristetty muun organisaation kanssa. Mutta pikemminkin elintärkeä toimija organisaation menestykseen.

Infrastruktuurin hallinta on yksi alustatiimin vastuusta. Parhaiden käytäntöjen ja syvän infrastruktuurin ymmärtämisen varmistaminen pilvessä tai paikan päällä. Esimerkiksi varmistaa, että infrastruktuuri on auditoitavissa. Tämä voidaan toteuttaa monin tavoin. Mutta yleisin tapa toteuttaa on infrastruktuuri koodina (IAC).

Infrastruktuuri voi palveluna käyttää IAC: ta (IaaS). Platform-tiimi käsittelee IAC: n rakentamista avoimen lähteen työkaluilla. tämä tarkoittaa, että rakennettava alusta on työkalujen abstraktio. Nämä työkalut ovat kytketty löysästi, ja näiden työkalujen integrointi on alusta. Ajattele sitä kuin alusta palveluna (PaaS), mutta lähempänä sitä, mitä yritys käyttää.

Tiesimme, miksi rakensimme alustatiimiä. Nyt meidän oli luotava perusta, jolle alustatiimi rakennetaan. Toisin kuin tuotetiimit, joilla on yleensä näkyvä tavoite ja valtuudet. Platform-tiimillä on enemmän ei-toiminnallisia vaatimuksia, meidän piti määritellä tämä perusteellisesti.

Tässä on henkilökohtainen tehtäväni kuinka rakentaa menestyvä alustatiimi.

Joukkue ja sen valtuudet

toimeksiantoja

automaatio

Ihmiset ovat alttiita virheille. Laajennuksen automaatio antaa meille olla varmempi suorittaessasi koodinpätkää. Tämän avulla voimme eristää koodin mahdolliset virheet ja virheet. ja sitten jatkuva käyttöönotto.

Automatisoidut testit ovat tärkeitä, mitä ei testata, jota ei ole vielä toteutettu kokonaan. Tarvitaan monenlaisia ​​testejä riippuen millaisesta ohjelmistosta. Esimerkiksi integrointiyksikön kokonaisesta fuzzing-kynätestaus.

Turvallisuus on ensiarvoisen huolestuttavaa, ja automatisoidun turvallisuustestauksen tulisi olla etusijalla. Tämä estää CORS-hyökkäyksiä SQL-injektioista ja muista. Tämän saaminen vähentää hyökkäyspintaa.

Käytä vähimmäisoikeuden periaatetta antaessasi käyttöoikeutta. Varmista samalla, että tasapainotat tämän pääsyn helppoutta. Kehittäjä, joka käyttää alusta, joka tarvitsee pääsyn viiden sekunnin välein, on huono ihmissuhteiden suhteen. Alustaryhmän tulisi olla mahdollistajia, ei esteitä. Tämä tarkoittaa pitkien matkojen luomista suhteiden luomiseksi ja tehokkuuden lisäämistä joukkueessa.

Kaikki, mikä on tehtävä kahdesti, pitäisi automatisoida. Pidä DRY-periaate niin paljon kuin mahdollista.
 
Alusta tulisi automatisoida kognitiivisten yläpintojen poistamiseksi. Auta meitä myös olemaan vakaampi alustana. Tämä ei ole vaihtoehto dokumentoinnille ja post mortemille, vaan pikemminkin seuraus niistä.

Suuri osa automaatiosta on käyttöönottostrategia ja käyttöönottojen mittaus metrien avulla. Lopuksi piirretään mittarit asiakkaan omaksumista vastaan.

Käytä älykkäitä käyttöönottoja ja ymmärrä milloin ne soveltuvat. Esimerkkejä tästä ovat seuraavat. Sininen vihreä käyttöönotto, a / b-testaus, automaattiset palautukset ja nolla tietämyksen palautukset.

tehokkuus
Erittäin tehokkaan alustan rakentaminen on tärkeää. Tämän avulla voimme liikkua nopeammin. Korjaa viat nopeasti tehokkuuden lisäämiseksi. Ja rakennuksen ominaisuudet välttämättömyyden perusteella. Koodin uudelleenkäyttö ja referenssitoteutuksen luominen on avainta. Tämä auttaa laajempaa yritystä saamaan pidemmän läpimenoajan markkinoille ja saamaan kilpailuetua. Muista dokumentoida kaikki tunnetut tuntemattomat ja reunatapaukset. Yleiset ongelmat ja lisääntymispolut.

Alustan tehokkuus tarkoittaa myös epäonnistumista ja sen kiinnittämistä. Alustan tulisi olla mahdollisimman avoin virheitä näytettäessä. Virheet johtavat sitten nopeampaan virheenkorjaukseen ja käyttöönottoon. Tehokkuus on pienten ominaisuuksien toistamisessa pikemminkin kuin suuren käyttöönoton sijaan.

Tietokannan laajentamisjärjestelmän saaminen ei ole este. Sen sijaan se on paikka aloittaa, kun sinusta tuntuu kadonnut. Tämä hyvien suhteiden ansiosta tuottaa tuloksia ja tehostaa yhteistyötä. Auttaa joukkueita jakamaan tietoa. He saavat kokemusta toisistaan ​​ja se on hyvä tapa rakentaa erittäin tehokas joukkue.
 
Itsepalvelu

Riittävä ja jatkuva dokumentointi on tärkeää. Koulutusta tarvitaan kehittäjille. Uusien kehittäjien koulutuskustannukset olisi otettava huomioon. Jokaisella hyväksytyllä uudella tekniikalla on yläpinta. Tätä on harkittava huolellisesti, jos yleiskustannukset ovat omaksumisen arvoisia. Interaktiiviset koulutuslaboratoriot ja kehittäjäportaali ovat hyödyllisiä. Paikka, jossa voimme löytää mvp: n ja referenssitoteutuksen. Kaikki tämä auttaa meitä saavuttamaan omavaraisuuden.

Kaikkien uusien insinöörien tulisi rakentaa jotain alustaa käyttämällä ensimmäisen kuukautensa aikana. Tämä voi olla osa uusien vuokralaisten alkuperäistä suuntaamista. Tämä antaa meille myös mahdollisuuden paljastaa ongelmat, jotka liittyvät järjestelmän itsepalveluun. Myös uudelleenkoulutus alustan jokaiselle uudelle osalle. Kannustetaan tekemään DIY-löytöjä alustalla. Pyörän keksiminen uudelleen ja varjo-IT: n käyttö on aktiivista. Useiden saman asian toteuttamisen ylläpitäminen on turhaa ja turhaa.

Mittarien seuranta ja hälytysten jäljitys ovat tehokkaita työkaluja. SRE voi olla alun perin osa alustoimintoa, joka on upotettu ydinalustoryhmään. Tämä auttaa SRE: tä ymmärtämään foorumin taustalla olevan toteutuksen.

Tärkein osa alustaa on, että se on rakennettu kehittäjille. Pyrimme tasapainottamaan parhaiden käytäntöjen kehittämistä ja edistämään ihmistenvälistä kommunikointia. Itsepalvelualusta tarkoittaa, että sinulla on osaamista. Sitten ymmärretään foorumin olemassaolon arvo. Tämä tarkoittaa, että kehittäjillä on joskus turhautumista. Palautteet tulisi ottaa huomioon alustaa kehitettäessä. Pitäisi olla tapa antaa palautetta alustan kehittäjille ja kuinka alustalle menee yleensä. Ilman tätä alusta elää erillään muun yrityksen kanssa. Hyväksyminen on parhaimmillaan rasittava. Ihmiset haluavat käyttää ja omaksua jotain, joka tuntuu hyvältä käytöstä. Loppujen lopuksi ohjelmistokehitys on ihmislähtöinen projekti. Kommunikaatio, vuorovaikutusmotivaatio on tärkeä osa kehitystä. Meidän on täydennettävä tätä yhdessä liiketoimintavaatimusten ja määräaikojen kanssa. Olemattomasta täydellisestä alustasta ei ole hyötyä kenellekään. Puolitoiminen ja suojaamaton alusta on kirous jokaiselle yritykselle.

Viimeinkin tulee aina olemaan asioita, jotka eivät kuulu alustan soveltamisalaan. Asiasta tulisi päättää aina tapauskohtaisesti. Tietäen, että ihmiset tarvitsevat sitä vielä päivän päätteeksi, ja sinun on ohjattava pyyntö toiseen joukkueeseen. Mahdollisesti laajentaa sitä.

Tiimin suunnittelija tarkastelee joukkuetta korkealla tasolla

periaatteet

Joukkue, joka haluaa pysyä päätöksissään

auktoriteetti

Monella tapaa alustustiimin menestys tai epäonnistuminen johtuu sen tekemästä päätöksestä. Alustaryhmän on tehtävä päätöksiä, jotka vaikuttavat muihin joukkueisiin. Tämä tapahtuu samalla, kun rakennetaan alustan perustaa. Esimerkiksi kieli, jota työkalut ja kehykset käytämme.

Alustaryhmän auktoriteetti ei ole standardien täytäntöönpanossa. Mutta kehitystiimin hienovaraisessa ohjauksessa toiseen päätökseen. Esimerkiksi suosituksen laatiminen hakkuille. Jotta se olisi yhteensopiva hakijajäsentimen kanssa lokien lähettämisen aikana. Kovien ja nopeiden standardien laatiminen ei ole alustustiimin vastuulla. Itse kehittämisryhmällä pitäisi olla etuoikeus valita. Kuten työkalujen kehykset ja kielet, se pitää sopivia omaan käyttötarkoitukseensa. Tämän jälkeen on olemassa perustavanlaatuisia voimia, joista on päätettävä etukäteen. Esimerkiksi pilvien tai useiden pilvipalvelujen tarjoajien käyttö.

Myyjän lukitus on sekä lahja että kirous alustustiimille. Lahja siinä mielessä, että muut ryhmät ovat tehneet nämä päätökset. Tämä tarkoittaa, että joukkueet ovat rakentaneet työkalujen ekosysteemit päätöksen ympärille. Kirous myös, koska meidän on elettävä nämä päätökset hakemuksen elinkaaren aikana. Tai lisää ylimääräinen siirtolasku. Alusta joukkueella tulisi olla näkyvyys ja auktoriteetti laajemmassa organisaatiossa, jotta hänellä olisi paremmat mahdollisuudet menestyä.

Käännä se tällä tavalla. Uskomme, että DevOps on kulttuuri, ei henkilö

Edustaminen ja evankeliointi

DevOps on kulttuuri, ei rooli. Alustaryhmän tulisi pystyä evankelisoimaan tämä.

Ohjelmistokehityksen tavallinen epäonnistumiskohta on ymmärryksen puute sovelluksen toiminnasta tuotantoympäristön olosuhteissa.

Ensimmäinen tekninen joukkue, joka helpottaa joukkueiden välistä viestintää, on yleensä alustatiimi. Sitten koodin uudelleenkäytön ja oletusarvoisesti parhaiden käytäntöjen edistäminen kuuluu alustustiimille. Suorituskyvystä ja luotettavuudesta tulee alustatiimin ensisijainen huolenaihe.

Suunnittelutehokkuus on alustaryhmän jatkuvaa puolustamista. Alustaryhmän rakentamisen koko tarkoitus on, että insinöörit voivat rakentaa enemmän vähemmällä kognitiivisella yläpuolella. Tiedot, joita voidaan käyttää uudelleen ja automatisoida, kuuluvat yleensä alustatiimille.

Teemme alustastasi vakaan yhden ankkurin kerrallaan

vastuullisuutta

Valtuutuksella tehdä muutoksia kunkin järjestelmän perustaviin rakenneosiin. Minkä tahansa näistä virhe tai haavoittuvuus aiheuttaa CSS-ongelman. Tällöin vaikutus muihin suunnittelutiimiin.

Vastuullisuus joukkueena on tärkeää varmistaa, että aina kun joukkue tekee muutoksen, muut joukkueet saavat tiedon.

Syytön post mortem on vaatimus, jotta jokainen jäsenistä tunteisi olonsa turvalliseksi muutosten tekemiseksi. Parempien järjestelmien rakentaminen ottaen samalla järjestelmän omistajuuden. Sitten vastuu tukimallin ja toimintojen edistämisestä kuuluu alustalle ja SRE-tiimille.

Ahm .. Joten kaikilla ei ole samaa työtä pyörän kääntämisessä

asiantuntemus

Alustaryhmässä tarvittava kokemus ja asiantuntemus riippuvat yrityksen rakenteesta.

Esimerkiksi joillakin yrityksillä on toimiva SRE-tiimi, joka huolehtii kunkin sovelluksen toiminnasta ja käyttöönottamisesta. Tämä tarkoittaa, että tukimallin luominen ei ole kokonaan alustustiimin vastuulla.

Toimittajan hallinta on myös tehtävä, joka voidaan delegoida sovellusten tukitiimille.

Mutta yleensä tässä on asiantuntemusta, jota tarvitset alustatiimissäsi:

  • konttien orkestrointi ja konttisointi
  • pilvien hallinta
  • myyjän hallinta
  • putkilinjan hallinta
  • dns- ja cdn-asetukset
  • palvelimen kokoonpano
  • git ja scm
  • tuote-ionisaatio
  • havaittavuus (hakkuiden seurannan jäljitys)
  • käyttöönotto (runbookit ja tukien lisääntyminen post mortem -hälytyksissä)
  • pehmeä taito ja ihmisten hallinta
  • ohjelmiston määrittelemä infrastruktuuri (infrastruktuuri koodina)
  • yhteistyö muiden ryhmien kanssa ja neuvottelut johdon kanssa
  • yhteinen työnkulun ja arkkitehtuurin hallinta
  • turvallisuus
  • kehittäjien koulutus ja opetus
  • dokumentoinnin kehittäminen

Ihannetapauksessa insinööreilläsi on verkkotunnuksen asiantuntemus ja heillä on sitten hyvät työskentelytiedot muista aloista.

Ehdotukseni asiantuntemuksen kehittämisessä on vaihtaa jäsenten välillä siten, että alueella on asiantuntijatasoja. Suorita sitten luovutus tai äärimmäinen taulukopariohjelmointi. Sellainen, että irtisanominen on rakennettu joukkueen rakenteeseen.

Ottaen huomioon foorumin tiimin valtava tehtävä. Voimme turvallisesti olettaa, että kaikkien näiden toimintojen suorittamiseen samanaikaisesti tarvitaan suuri joukkue. Osa tehtävästä voidaan siirtää hakuryhmälle. Vaikka se lisäisi ylimääräisiä yleiskustannuksia kehitykselle. Voimme myös jakaa tämän joukkueen, mutta epäasianmukaisella käsittelyllä se voi johtaa vääristymiseen.

Suositellaan puoliksi litteää rakennetta, jossa on useita vanhempia ja pääinsinöörejä, jotka voisivat tehdä ketterän päätöksen. Tällaisen suuren joukkueen pitäminen, jolla on paljon liikkuvia osia, merkitsisi myös sitä, että tekninen johtava rooli ei sovellu, vaan alustan ja ratkaisuarkkitehdin suunnittelujohtaja on välttämätöntä.

Ratkaisuarkkitehti pystyi laatimaan foorumin tiimin etenemissuunnitelman. Koordinoi sitten se muiden insinööritiimien kanssa. Tässä prosessissa voimme ymmärtää myös organisaation tarpeet. Ja sitten suunnitella, mitä ominaisuuksia tarvitsemme. Viimeinkin ratkaisuarkkitehti voi auttaa johtamaan teknologiaa, jota voidaan lisätä alustaan.

Suunnittelupäällikkö voisi auttaa kommunikoinnissa ja suhteiden rakentamisessa. Tämä on tärkeää monista syistä. Ensinnäkin todellinen monialainen tiimi, joten pyyntöjen määrä on suuri. Toiseksi tehtävien priorisointi on ratkaisevan tärkeää valmiuksien kehittämisessä.

Itse asiassa paljon liikkuvaa osaa. Mutta oikein tehty se voi olla kuin hyvin öljytty kone

epilogi

Alustatiimi on uusi konsepti, jonka mahdollistavat markkinoille tulevat uudet tekniikat. Hyvä esimerkki tästä on kubernetes ja sen kaikkialle kuuluvuus. Tämä uusi tiimi voi auttaa yritystä rakentamaan helposti valmiuksia. Skaalausjoukkueiden on vaikeaa ottaa käyttöön uusi tiimi, joka auttaa ryhmää skaalaamaan nopeammin vähemmän kitkaa. Tämä on henkilökohtainen kokemukseni, jonka on oltava tiimin ytimenä ja mitä asiantuntemusta tarvitaan sen rakentamiseksi.

Työskentele kanssamme Tarkista tämä työ Condé Nast International -sivustolla: https://www.linkedin.com/jobs/view/839478085

Liity yhteisöön Slack ja lue viikoittaiset Faun-aiheemme ⬇

Jos tämä viesti oli hyödyllinen, napsauta muutaman kerran alla olevaa taputtaa -painiketta osoittaaksesi tukenne kirjailijalle! ⬇