1. BusinessOperations ManagementKuidas teie organisatsioonis moodustada DevOps meeskonnad

Autor: Emily Freeman

DevOpsil pole ideaalset organisatsioonilist ülesehitust. Nagu kõik tehnika osas, sõltub ettevõtte struktuuri puudutav “õige” vastus teie ainulaadsest olukorrast: teie praegusest meeskonnast, kasvuplaanidest, meeskonna suurusest, meeskonna olemasolevatest oskuste komplektidest, teie tootest ja sellest edasi.

DevOps-i meeskonna visiooni joondamine peaks olema teie esimene missioon. Alustage meeskondade ümberkorraldamist alles pärast seda, kui olete eemaldanud inimeste vahel ilmse hõõrdumise madala rippuva vilja. Isegi siis lubage teatud paindlikkust.

Kui lähenete saneerimisele avatuse ja paindlikkusega, saadate sõnumi, et olete nõus kuulama, ja annate oma meeskonnale autonoomia - DevOpsi põhiprintsiip.

Teil võib juba olla Pythoni või Go arendaja, kes on kirglik ja uudishimulik infrastruktuuri ja konfiguratsiooni halduse osas. Võib-olla saab see inimene teie uues organisatsioonis üle minna rohkem operatsioonidele keskendunud rolli. Pange ennast selle inimese kingadesse. Kas te poleks lojaalne organisatsioonile, kes võttis teiega riski? Kas poleks teil hea meel kõvasti tööd teha? Ja see elevus on nakkav.

Siit saate teada, kuidas joondada juba loodud meeskondi, pühendada meeskond DevOps'i tavadele ja luua funktsionaalseid meeskondi - kõiki lähenemisviise, millest saate valida, kas suunata oma meeskonnad DevOpsi poole.

Võite valida ühe lähenemisviisi ja lasta sellel sealt areneda. Ärge arvake, et see otsus on püsiv ja liikumatu. DevOps keskendub kiirele iteratsioonile ja pidevale täiustamisele ning see on selle metoodika peamine eelis. See filosoofia kehtib ka meeskondade kohta.

Funktsionaalsete meeskondade joondamine DevOpsile

Selle lähenemisviisi korral loote tugeva koostöö oma traditsiooniliste arendusmeeskondade ja operatsioonide meeskondade vahel. Meeskonnad on oma olemuselt funktsionaalsed - üks keskendus ops-ile, teine ​​keskendus koodile. Kuid nende stiimulid on viidud vastavusse. Nad usaldavad üksteist ja töötavad nagu kaks meeskonda koos.

Väiksemate inseneriorganisatsioonide jaoks on funktsionaalsete meeskondade joondamine kindel valik. Isegi esimese sammuna võib see joondamine tugevdada seni tehtud positiivseid muudatusi. Tavaliselt alustate joondamist sellega, et võtate aega raporti koostamiseks. Veenduge, et mõlema meeskonna iga inimene mitte ainult ei mõista teise meeskonna rolli ja piiranguid intellektuaalselt, vaid suhtub ka valupunktidesse.

Selle lähenemisviisi jaoks on hea mõte reklaamida poliitikat „Teie ehitate seda, te toetate seda.” See poliitika tähendab, et kõik - nii arendajad kui ka tegutsevad isikud - osalevad teie valvekorra rotatsioonis.

See osalemine võimaldab arendajatel mõista pettumusi, mis tekivad siis, kui keset ööd helistatakse ja kui udusilmsed ja kofeiinivabad inimesed pingutavad, et parandada viga, mis mõjutab kliente. Operatsioonide inimesed hakkavad usaldama ka teie arendajate pühendumust oma tööle. Isegi see väike muudatus loob erakordse usalduse.

Ettevaatust: kui arendajad võitlevad kõvasti valves olemise vastu, on teie organisatsioonis suurem probleem. Tagasilükkamine pole haruldane, sest valves olemine erineb metsikult nende tavalistest igapäevastest kohustustest. Tagasilükkamine tuleb sageli ebamugavuse ja hirmu kohast. Selle reaktsiooni leevendamisel saate aidata lahendada tõsiasja, et teie arendajad ei pruugi esimestel kordadel, kui nad on valves, teada, mida teha.

Võib-olla pole nad infrastruktuuriga tuttavad ja see on okei. Julgustage neid juhtumit eskaleerima ja leidke keegi, kellel on rohkem kogemusi. Lõpuks loo käitusraamat koos levinumate märguannetega ja milliseid toiminguid võtta. Selle ressursi pakkumine aitab leevendada teatavat hirmu, kuni nad hakkavad asju ajama.

Teine taktika, mis aitab edendada koostööd ühtsema DevOps-meeskonna moodustamiseks, on varjutamise päeva sissejuhatus, kus iga meeskond “kaupleb” oma kolleegiga. Kaupletav isik varjutab lihtsalt meeskonna kellegi teise, istub oma laua taga (või oma piirkonnas) ja abistab igapäevaseid kohustusi. Nad võivad aidata tööl käimist, meeskonnana probleeme arutada (paariprogrammeerimine) ja õppida süsteemist rohkem teada teisest vaatepunktist. See õpetamisstiil ei ole ettekirjutav.

Selle asemel pakutakse uudishimu ja usalduse loomist. Kolleegid peaksid vabalt esitama küsimusi - isegi „rumalat” - ja õppima vabalt. Mingeid jõudluse ootusi pole. Aeg tuleks kulutada lihtsalt üksteisega tutvumiseks ja üksteise töö väärtustamiseks. Iga produktiivne väljund on boonus!

Selle lähenemisviisi korral peavad mõlemad meeskonnad olema kindlasti kaasatud planeerimisse, arhitektuuri ja arendusprotsessidesse. Nad peavad kogu arengu elutsükli jooksul jagama vastutust ja vastutust.

DevOps meeskonna pühendamine

Spetsiaalne DevOps-meeskond on rohkem Sys Admini arendamine kui tõeline DevOps-meeskond. See on operatsioonide meeskond, kus on mitmesuguseid oskusi. Võib-olla on mõned insenerid konfiguratsioonihaldusega tuttavad, teised IaC (infrastruktuur kui kood) ja võib-olla teised on konteinerite või pilve loomuliku infrastruktuuri või CI / CD (pidev integreerimine ja pidev tarnimine / arendamine) eksperdid.

Kui arvate, et silotornide lagundamiseks piisab inimrühma panemisest ametlikku meeskonda, olete eksinud. Inimesed on keerukamad kui arvutustabelid. Hierarhia ei tähenda midagi, kui teie silod on jõudnud faasi, kus nad on ebatervislikud ja hõimulised. Mürgistes kultuurides võib välja kujuneda kangelase juhtimisstiil, mida peaaegu alati järgivad inimesed, kes võtavad külje alla. Kui näete seda oma meeskonnas, on teil vaja tööd teha.

Ehkki iga lähenemisviis võib teie meeskonna heaks töötada, peaks see pühendunud meeskonna lähenemisviis olema see, mida peaksite kõige paremini läbi mõtlema. Spetsiaalse DevOps-meeskonna suurim puudus on see, et sellest saab hõlpsalt traditsiooniliste insenerimeeskondade jätk, teadvustamata vajadust meeskondi joondada, silohoidjaid vähendada ja hõõrdumist eemaldada. Selle lähenemise korral on hõõrdumise jätkumise (või suurema tekitamise) risk kõrge. Jätke ettevaatlikult tähelepanu, et valiksite selle meeskonna organisatsiooni konkreetsel põhjusel.

Selle DevOps-lähenemisviisi eelisteks on spetsiaalne meeskond, kes tegeleb oluliste infrastruktuuri muudatuste või kohandustega. Kui teil on probleeme operatsioonikeskse probleemidega, mis aeglustavad juurutamist või põhjustavad saidi usaldusväärsusega seotud probleeme, võib see olla hea lähenemisviis - isegi ajutiselt.

Pühendunud meeskond, kui plaanite pärandrakenduse pilve teisaldada. Kuid selle asemel, et seda meeskonda DevOps-meeskonnaks nimetada, võiksite proovida selle automaatikameeskonnaks nimetada.

See spetsiaalne inseneride rühm saab täielikult keskenduda sellele, et olete seadistanud õiged infrastruktuuri- ja automatiseerimisriistad. Seejärel saate jätkata kindlustundega, et teie rakendus maandub pilve ilma suuremate häireteta. See lähenemisviis on siiski ajutine. Kui hoiate meeskonda liiga kaua isoleerituna, siis riskite libiseva nõlva alla minna kiirelt kasvavalt varjatud silo juurde.

Funktsionaalsete ristfunktsionaalsete tootemeeskondade loomine DevOpsile

Ristfunktsionaalne meeskond on meeskond, mis on moodustatud ühe tootefookuse ümber. Selle asemel, et teil oleks eraldi arendamise, kasutajaliidese ja kasutajakogemuse (UI / UX), kvaliteedi tagamise (QA) ja toimingute meeskonnad, ühendaksite kõigi nende meeskondade inimesed.

Ristfunktsionaalne meeskond töötab kõige paremini keskmistes ja suurtes organisatsioonides. Iga tootetiimi positsioonide täitmiseks on vaja piisavalt arendajaid ja operatsioonide töötajaid. Iga ristfunktsionaalne meeskond näeb natuke erinev välja.

Hea mõte on, et meeskonna kohta oleks vähemalt üks inimene. Ärge paluge operatsioonil töötaval inimesel jagada oma kohustused kahe meeskonna vahel. See stsenaarium on nende suhtes ebaõiglane ja tekitab kiiresti kahe tootetiimi vahel hõõrdumise. Andke oma inseneridele privileeg, et neil on võimalik oma töösse keskenduda ja süveneda.

Kui teie organisatsioon on endiselt väike või olete käivitusfaasis, võite mõelda kogu oma inseneriorganisatsioonile kui ristfunktsionaalsele meeskonnale. Hoidke see väike ja keskendunud. Kui hakkate lähenema 10–12 inimesele, hakake mõtlema, kuidas saaksite insenere ümber korraldada.

Allolev pilt näitab, millised võiksid teie funktsionaalsed ristvõistkonnad välja näha. Kuid pidage meeles, et nende koosseis on meeskonniti ja organisatsiooniti erinev. Mõnel tootel on tugev disainifookus, mis tähendab, et igas meeskonnas võib olla mitu disainerit. Muud tooted on tehnilised tooted, mis on mõeldud inseneridele, kes ei hooli esteetikast eriti. Sellise toote meeskondadel võib olla üks disainer või üldse mitte ükski.

DevOps tootetiim

Kui teie organisatsioon on piisavalt suur, saate kindlasti luua mitu meeskonda, kasutades erinevaid DevOps ideid ja lähenemisviise. Pidage meeles, et teie organisatsioon on ainulaadne. Teil on õigus teha otsuseid vastavalt teie praegustele oludele ja kohaneda sealt lähtuvalt. Siin on mõned võimalikud kombinatsioonid eri tüüpi tootemeeskondadest.

  • Pärandtoodete meeskond: projektijuht (PM), esiosa arendaja, tagaosa arendaja, tagaosa arendaja, saidi töökindluse insener (SRE), automaatika insener, kvaliteedi tagamise testija Pilvemuundumise meeskond: SRE, SRE, operatsioonide insener, automaatika insener, tagavara arendaja MVP meeskond: PM, kujundaja, UX-insener, esiosa arendaja, taustaprogrammi arendaja, operatsioonide insener

Ristfunktsionaalse tootemeeskonna miinus on see, et insenerid kaotavad inseneride seltskonna samade oskuste ja kirgedega. Tööga rahulolu oluline aspekt on mõttekaaslaste rühma moodustamine, kellega saate suhelda ja kellelt saate õppida. Vaadake allpool selle probleemi lahendust.

Nagu allpool näidatud, saate anda oma inseneridele pühendatud tööaja, et veeta oma hõimudega. Võite teha midagi nii heldet kui maksta lõunasöögi eest kord nädalas, et nad saaksid kokku ja vestelda. Või võite anda neile 10–20 protsenti tööajast hõimlasena projektide kallal töötamiseks. Mõlemal juhul peate oma insenere teravaks püsima.

Hõimud jagavad valdkonnaalaseid teadmisi, pakuvad põhjalikku tagasisidet ja toetavad karjääri kasvu. Andke oma inseneridele aega õppida inimestelt, kellega neil on ühine haridus, kogemused ja eesmärgid. See aeg tagab turvalise koha, kus nad saavad lõõgastuda ja end koduselt tunda.

DevOps hõimud

Ükski täiuslik finaalvõimlemine ei ületa halva organisatsioonikultuuri puudusi. Kuid kui olete seni tähelepanu pööranud ja teinud asjakohaseid samme, on järgmine samm moodustada meeskonnad, kes tugevdavad juba loodud kultuurilisi ideaale.