Kuidas nüüd platvormimeeskonda üles ehitada! eduka inseneri saladused

TLDR; Skaalameeskonnad on kõvad. Õigesti tehtud platvormimeeskond võib raskusi leevendada.
Platvorm mere keskel (hea metafoor platvormimeeskondade tavapäraseks eraldamiseks)

Conde Nast Internationalis kasvasime 20 inseneri meeskonnast vähem kui aastaga vähem kui 100-ni. Saime teada, et paljudel turgudel kasutatava süsteemi väljaehitamisel on palju liikuvaid osi ja kordusi. Näiteks infrastruktuuri ja rakenduste konfiguratsiooni ümberehitamine. Kolmanda osapoole lisatarkvara lisamine. Rakenduse loomine CDN ümbersuunamiste abil. DNS-i registreerimine ja konfigureerimine.

Paljud meeskonnad kasutasid palju AWS-i kontosid. Kasutamise jälgimise jälgimine oli jama. Iga arendaja peab mõtlema, kus ja kuidas oma süsteemi käitada. Tavaliselt teevad nad seda üksteisest sõltumatult. Nad peavad mõtlema jälgimisele ja logimisele. See hõlmab ka mitmesuguseid alamsüsteeme, näiteks logimise järjekorda seadmine ja liikluse suunamine.

Protsessi palju lihtsamaks ja sujuvamaks muutmiseks oleksime võinud teha palju asju. See on peamine põhjus, miks otsustasime moodustada infrastruktuurimeeskonna, hiljem platvormimeeskonna.

Platvormi meeskond

Platvormi meeskond

Platvormimeeskond ei kuulu tootemeeskondade koosseisu, vaid tegutseb selle asemel tehnilise efektiivsuse meeskonda. See tähendab, et platvormi meeskonna peamine klientuur on tootemeeskonnad. See tootetiim peab ka platvormi üldiselt tundma õppima. Seejärel tõstatage probleemid ja toetage pidevat parendamist (uus CI). See ei tohiks tähendada, et platvormi meeskond oleks ülejäänud organisatsiooniga isoleeritud. Kuid pigem organisatsiooni edukuse oluline tegur.

Infrastruktuuri haldamine on platvormi meeskonna üks vastutusala. Parimate tavade ja infrastruktuuri sügava mõistmise tagamine pilves või kohapeal. Näiteks veendudes, et infrastruktuur on auditeeritav. Seda saab rakendada mitmel viisil. Kuid kõige tavalisem rakendusviis on infrastruktuur kui kood (IAC).

IAC on lubatud infrastruktuuri kui teenuse (IaaS) kaudu. Platvormi meeskond tegeleb IAC loomisega avatud lähtekoodiga tööriistade abil. see tähendab, et rajatav platvorm on tööriistade abstraktsioon. Need tööriistad on tihedalt ühendatud ja nende tööriistade integreerimine on platvorm. Mõelge sellele nagu platvorm kui teenus (PaaS), kuid lähemale sellele, mida ettevõte kasutab.

Me teadsime, miks me platvormitiimi moodustasime. Nüüd pidime panema aluse, millele platvormi meeskond ehitatakse. Erinevalt tootetiimidest, millel on tavaliselt nähtavad eesmärgid ja volitused. Platvormi meeskonnal on rohkem mittefunktsionaalseid nõudeid, me pidime selle põhjalikult määratlema.

Siin on minu isiklik ettekujutus eduka platvormimeeskonna moodustamisest.

Meeskond ja selle mandaadid

Mandaadid

Automatiseerimine

Inimesed on altid vigadele. Automaatika platvormi piires võimaldab meil kooditüübi täitmisel olla enesekindlam. See võimaldab meil koodis olevad vead ja vead eraldada. ja seejärel tehke pidev juurutamine.

Automaatsed testid on olulised kõik, mida ei testita, pole veel täielikult rakendatud. Sõltuvalt tarkvarast on vaja palju erinevaid teste. Näiteks integreerimisüksuse otsast lõpuni fuzzing pliiatsi testimine.

Turvalisus on hädavajalik ja automatiseeritud turbekontroll peaks olema prioriteet. See väldib CORSi rünnakut SQL-i süstimise ja muu vastu. Selle omamine vähendab rünnaku pinda.

Kasutage juurdepääsu andmisel vähima privileegi põhimõtet. Samal ajal kontrollige seda sisenemise lihtsusega. Arendaja, kes kasutab platvormi, millele on vaja juurdepääsu iga 5 sekundi tagant, mõjutab inimestevahelisi suhteid. Platvormimeeskond peaks olema võimaldajad, mitte tõkked. See tähendab, et tuleb pikka aega suhete loomiseks ja meeskonnas tõhususe loomiseks.

Kõik, mida tuleb teha kaks korda, tuleks automatiseerida. Pidage võimalikult palju silmas DRY põhimõtet.
 
Kognitiivsete õhuliinide eemaldamiseks peaks platvorm olema automatiseeritud. Aidake meil ka platvormina stabiilsem olla. See ei ole alternatiiv dokumentidele ja surmajärgsetele dokumentidele, vaid pigem nende tulemus.

Suur osa automatiseerimisest on juurutamisstrateegia ja juurutuste mõõtmine mõõdikute abil. Lõpuks joonistatakse mõõdikud klientide vastuvõtmise vastu.

Kasutage nutikaid juurutusi ja saate aru, millal neid rakendada. Selle näideteks on järgmised. Sinine roheline juurutamine, a / b testimine, automaatsed tagasipöördumised ja null teadmiste tagasipöördumine.

Tõhusus
Äärmiselt tõhusa platvormi loomine on oluline. See võimaldab meil kiiremini liikuda. Parandab vead tõhususe suurendamiseks kiiresti. Ja hoone omadused vastavalt vajadusele. Koodi taaskasutamine ja viiteteostuse loomine on võtmetähtsusega. See aitab laiemal ettevõttel saada nii turule ülemineku aega kui ka konkurentsieelist. Dokumenteerige kindlasti kõik teadaolevad tundmatud ja servad. Levinumad probleemid ja laienemisteed.

Platvormi tõhusus tähendab ka kiiret ebaõnnestumist ja selle kinnitamist. Platvorm peaks vigade kuvamisel olema võimalikult läbipaistev. Sel juhul viib vead silumise ja juurutamise kiiremini. Tõhusus seisneb väikeste funktsioonide iteratsioonis, mitte suure juurutamise korral.

Teadmistebaasi laiendamise süsteemi omamine ei ole takistuseks. Selle asemel on see koht alustamiseks alati, kui tunnete end kadununa. See annab heade suhetega produktiivseid tulemusi ja tõhusamat koostööd. Meeskondade abistamine teadmiste jagamisel. Nad saavad üksteisega kogemusi ja see on hea viis väga tõhusa meeskonna moodustamiseks.
 
Iseteenindus

Oluline on piisav ja pidev dokumenteerimine. Arendajatele on vaja koolitust. Arvesse tuleks võtta uute arendajate koolitamisega seotud üldkulusid. Igal uuel tehnoloogial, mille me kasutusele võtame, on üldkulud. See tuleb hoolikalt läbi mõelda, kui üldkulud on lapsendamist väärt. Kasulikud on interaktiivsed koolituslaborid ja arendajate portaal. Koht, kus saame teada saada mvp-vormingut ja viidete rakendamist. Kõik see aitab meil saavutada iseseisvat toimetulekut.

Kõik uued insenerid peaksid oma esimesel kuul platvormi abil midagi üles ehitama. See võib olla osa uute töötajate rentimisest. See võimaldab meil ka avastada platvormi iseteenindusega seotud probleeme. Samuti platvormi iga uue osa ümberõpe. Soodustatakse DIY avastamist platvormi piires. Ratta leiutamist ja varjatarkvara kasutamist aktiivselt ei soovitata. Sama asja paljude rakenduste säilitamine on raiskamine ja mittevajalik.

Mõõdikute jälgimine ja häirete jälgimine on võimsad tööriistad. SRE võib algselt olla osa platvormi funktsioonist, mis on manustatud platvormi põhimeeskonda. See aitab SRE-l mõista platvormi aluseks olevat rakendamist.

Kõige olulisem osa platvormist on see, et see on loodud arendajatele. Parimate tavade väljakujundamise ja inimestevahelise suhtluse edendamise tasakaal. Iseteenindusplatvorm tähendab, et teil on oskusteave. Siis saate aru platvormi omamise väärtusest. See tähendab, et arendajatel on mõnikord pettumusi. Platvormi arendamise iteereerimisel tuleks arvesse võtta tagasisidet. Peaks olema võimalus platvormi arendajatele tagasisidet anda ja kuidas platvormil üldiselt läheb. Ilma selleta elab platvorm ülejäänud ettevõttega eraldatult. Vastuvõtmine on parimal juhul pingutav. Inimesed tahavad kasutada ja omaks võtta midagi, mida nad tunnevad hea kasutamise vastu. Lõppude lõpuks on tarkvaraarendus inimestele keskenduv projekt. Suhtlus, interaktsioonide motivatsioon on arengu oluline osa. Peame selle täiustama koos ärinõuete ja tähtaegadega. Olematust ideaalsest platvormist pole kellelegi kasu. Poolfunktsionaalne ja turvamata platvorm on needus igale ettevõttele.

Lõpuks jääb alati asju, mis jäävad platvormi kohaldamisalast välja. See tuleks alati otsustada igal üksikjuhul eraldi. Teades, et inimesed vajavad seda päeva lõpuks ikkagi ja peate päringu teise meeskonda suunama. Võimalik, et eskaleerige seda.

Meeskonna planeerija vaatab meeskonda kõrgel tasemel

Põhimõtted

Meeskond, kes soovib oma otsuste eest seista

Autoriteet

Paljuski seisneb platvormimeeskonna edu või ebaõnnestumine selle otsuses. Platvormi meeskond peab tegema otsuseid, mis mõjutavad teisi meeskondi. See juhtub platvormi aluste ehitamisel. Näiteks keel, mida kasutame tööriistade ja raamistike jaoks.

Platvormimeeskonna autoriteet ei seisne standardite jõustamises. Kuid arendusmeeskonna peent juhtimisel ühte või teist otsusesse. Näiteks soovituse koostamine metsaraie jaoks. Logimise parseriga ühilduvuse tagamiseks logide saatmise ajal. Kõvade ja kiirete standardite väljatöötamine ei ole platvormi meeskonna kohustus. Arendusmeeskonnal endal peaks olema eesõigus valida ja valida. Nagu tööriistade raamistikud ja keeled, peab see sobivaks oma tarbeks. Sellegipoolest on olemas põhilised jõud, mis tuleb eelnevalt otsustada. Näiteks pilve või mitme pilve pakkuja kasutamine.

Müüja lukustus on platvormimeeskondade kingitus ja needus. Kingitus selles mõttes, et need otsused on teinud teised meeskonnad. See tähendab, et meeskonnad on rajanud oma tööriistade ökosüsteemi otsuse ümber. Needus ka seetõttu, et me peame neid otsuseid ellu viima rakenduse elutsükli jooksul. Või lisage täiendav rände üldkulud. Platvormimeeskonnal peaks olema parem nähtavus ja autoriteet laiema organisatsiooni suhtes, et oleks suurem võimalus õnnestuda.

Pöörake seda teed. Usume, et DevOps on kultuur, mitte inimene

Propageerimine ja evangelism

DevOps on kultuur, mitte roll. Platvormi meeskond peaks olema võimeline seda evangeliseerima.

Tavaline tõrge tarkvaraarenduses on arusaamise puudumine selle kohta, kuidas rakendus tootmiskeskkonnatingimustes töötab.

Esimene tehniline meeskond, mis hõlbustab meeskondadevahelist suhtlust, on tavaliselt platvormimeeskond. Siis langeb koodi taaskasutamise ja vaikimisi parimate tavade propageerimine platvormi meeskonnale. Toimivus ja töökindlus saavad platvormi meeskonna peamiseks mureks.

Insenertehniline efektiivsus on platvormi meeskonna pidev propageerimine. Platvormimeeskonna loomise eesmärk on inseneridel rohkem ehitada vähem kognitiivsete kuludega. Üksikasjad, mida saaks uuesti kasutada ja automatiseerida, jäävad tavaliselt platvormi meeskonna hooleks.

Muudame teie platvormi stabiilseks ühe ankruga korraga

Vastutus

Koos volitusega teha muudatusi iga süsteemi põhiosas. Neis sisalduv viga või haavatavus põhjustab kaskaadprobleeme. Seejärel mõjutab see ülejäänud insenerimeeskonda.

Aruandekohustus meeskonnana on oluline veenduda, et kui meeskond teeb murrangulise muudatuse, on ülejäänud meeskond informeeritud.

Süütu post mortem on nõue selleks, et kõik liikmed tunneksid end muudatuste tegemisel turvaliselt. Parema süsteemi loomine, samal ajal süsteemi omamine. Seejärel lasub vastutus tugimudeli ja toimingute otsimise eest platvormil ja SRE-meeskonnal.

Ahm .. Nii et kõigil pole selle ratta keeramisel sama tööd

Ekspertiis

Platvormi meeskonnas vajalikud kogemused ja teadmised sõltuvad ettevõtte struktuurist.

Näiteks on mõnel ettevõttel toimiv SRE-meeskond, kes hoolitseb iga rakenduse toimimise ja kasutuselevõtu eest. See tähendab, et tugimudeli loomine ei kuulu täielikult platvormi meeskonna vastutusalasse.

Müüjahaldus on ka ülesanne, mille saab delegeerida rakenduste tugimeeskondadele.

Kuid üldiselt on siin teie platvormi meeskonnas vajaminevad teadmised:

  • konteinerite korraldamine ja konteineriseerimine
  • pilvehaldus
  • müüja juhtimine
  • torujuhtme juhtimine
  • dns ja cdn konfiguratsioon
  • serveri konfiguratsioon
  • git ja scm
  • produkti ionisatsioon
  • jälgitavus (metsaraie jälgimise jälgimine)
  • kasutuselevõtt (käitusraamatud ja surmajärgsete häirete hoiatusteade)
  • pehme oskus ja inimeste juhtimine
  • tarkvara määratletud infrastruktuur (infrastruktuur koodina)
  • koostöö teiste meeskondadega ja läbirääkimised juhtkonnaga
  • ühine töövoog ja arhitektuurihaldus
  • turvalisus
  • arendaja koolitus ja õpetamine
  • dokumentatsiooni väljatöötamine

Ideaalis on teie inseneridel valdkonnaalane ekspertiis ja siis head teadmised teistest valdkondadest.

Minu soovitus ekspertteadmiste väljaarendamisel on vahetada liikmete vahel nii, et oleks olemas domeenitaseme eksperdid. Seejärel tehke üleandmine või äärmuslik tabelipaari programmeerimine. Selline, et koondamine on meeskonna struktuuri sisse ehitatud.

Arvestades platvormi meeskonna tohutut pädevust. Võib julgelt eeldada, et kõigi nende toimingute paralleelseks tegemiseks oleks vaja suurt meeskonda. Osa ülesandest saab delegeerida taotlusmeeskonnale. Kuigi see annaks arengule lisakulutusi. Võiksime selle meeskonna ka laiali jagada, kuid ebaõige käitlemise korral võib see viia veelgi valesti.

Soovitatav on pooltasapinnaline struktuur, millel on mitu vanem- ja peainsenerit ning kes võiksid otsuseid langetada. Niisuguse suure meeskonna olemasolu, millel on palju liikuvaid osi, tähendaks ka seda, et tehniline juhiroll ei sobi, pigem on vajalik platvormi- ja lahendusearhitekti insenerijuht.

Lahendusearhitekt võiks välja panna platvormi meeskonna tegevuskava. Seejärel kooskõlastage see ülejäänud insenerimeeskondadega. Selles protsessis saame aru ka organisatsiooni vajadustest. Ja siis kavandage, milliseid võimeid me vajame. Lõpuks võib lahendusearhitekt aidata platvormile lisatavate tehnoloogiate valimisel.

Insenerijuht võiks aidata suhtlemisel ja suhete loomisel. See on oluline mitmel põhjusel. Esiteks olles tõeline funktsionaalne meeskond, on taotluste arv suur. Teiseks on võimete väljaarendamisel ülioluline ülesannete tähtsuse järjekorda seadmine.

Tõepoolest palju liikuvat osa. Kuid õigesti tehes võib see olla nagu hästi õlitatud masin

epiloog

Platvormimeeskond on uus kontseptsioon, mille võimaldavad turule tulevad uued tehnoloogiad. Selle heaks näiteks on kubernetes ja selle üldlevinud olemus. See uus meeskond aitab ettevõttel hõlpsalt võimalusi välja ehitada. Ulatusvõistkondadel on raske, kuna uus võimaldajate meeskond aitab meeskonnal kiiremini skaleeruda ja väiksema hõõrdumisega. See on minu isiklik kogemus, mis põhineb kogemusel, mis peab olema selle meeskonna keskmes ja millised teadmised on vaja selle sisseehitamiseks.

Töötage koos meiega Vaadake seda tööd Condé Nast Internationalis: https://www.linkedin.com/jobs/view/839478085

Liituge meie kogukonnaga Slack ja lugege meie iganädalasi Fauni teemasid ⬇

Kui sellest postitusest oli abi, klõpsake mõne korra all allolevat plaksutusnuppu, et näidata oma tuge autorile! ⬇