Küsimus "kuidas devopsi rakendada" on olnud juba aastaid, kuid häid materjale pole palju. Mõnikord langete mitte-nii tarkade konsultantide reklaamide ohvriks, kes peavad oma aega müüma, ükskõik kuidas. Mõnikord on need ebamäärased, äärmiselt üldised sõnad selle kohta, kuidas megakorporatsioonide laevad kündavad universumi avarusi. Tekib küsimus: mis see meile korda läheb? Kallis autor, kas saate oma ideed loendis selgelt sõnastada?
Kõik see tuleneb asjaolust, et tegelikku praktikat ja arusaamist ettevõtte kultuurimuutuste tulemustest pole kogunenud palju. Muutused kultuuris on pikaajalised asjad, mille tulemused ei avaldu nädala ega kuuga. Vajame kedagi piisavalt vana, et oleks näinud, kuidas ettevõtteid on aastate jooksul üles ehitatud ja ebaõnnestunud.
John Willis - üks DevOpsi isadest. Johnil on aastakümnete pikkune töökogemus paljude ettevõtetega. Hiljuti hakkas John märkama konkreetseid mustreid, mis tekivad nendega töötades. Neid arhetüüpe kasutades juhatab John ettevõtteid DevOpsi ümberkujundamise tõelisele teele. Loe nende arhetüüpide kohta lähemalt tema DevOops 2018 konverentsi raporti tõlkest.
Kõneleja kohta:
Rohkem kui 35 aastat IT-juhtimises, osalenud OpenCloudi eelkäija loomisel Canonicalis, osalenud 10 idufirmas, millest kaks müüdi Dellile ja Dockerile. Praegu on ta SJ Technologies DevOpsi ja digitaalsete tavade asepresident.
Järgmine on lugu Johni vaatenurgast.
Minu nimi on John Willis ja mind on kõige lihtsam leida Twitterist, . Mul on Gmailis ja GitHubis sama pseudonüüm. A leiad minu aruannete videosalvestised ja nende esitlused.
Mul on palju kohtumisi erinevate suurte ettevõtete infojuhtidega. Nad kurdavad väga sageli, et nad ei saa aru, mis DevOps on, ja kõik, kes üritavad seda neile selgitada, räägivad millestki muust. Teine levinud etteheide on see, et DevOps ei tööta, kuigi tundub, et direktorid teevad kõike nii, nagu neile selgitatud. Jutt käib suurettevõtetest, mis on üle saja aasta vanad. Nendega vesteldes jõudsin järeldusele, et paljude probleemide puhul ei sobi mitte kõrgtehnoloogia, vaid pigem suhteliselt madaltehnoloogilised lahendused. Nädalaid lihtsalt rääkisin erinevate osakondade inimestega. See, mida näete postituse kõige esimesel pildil, on minu viimane projekt, selline nägi tuba välja pärast kolme päeva tööd.
Mis on DevOps?
Tõepoolest, kui küsite 10 erinevalt inimeselt, annavad nad 10 erinevat vastust. Kuid siin on huvitav: kõik need kümme vastust on õiged. Siin pole vale vastust. Olin DevOpsiga üsna süvitsi umbes 10 aastat ja olin esimene ameeriklane esimesel DevOpsDay'l. Ma ei ütle, et olen targem kui kõik DevOpsiga seotud inimesed, kuid vaevalt on keegi, kes on selle nimel nii palju vaeva näinud. Usun, et DevOps tekib siis, kui inimkapital ja tehnoloogia saavad kokku. Me unustame sageli inimliku mõõtme, kuigi räägime palju igasugustest kultuuridest.
Nüüd on meil palju andmeid, viis aastat akadeemilist uurimistööd, teooriate katsetamist tööstuslikus mastaabis. Need uuringud ütlevad meile, et kui ühendada mõned käitumismustrid organisatsioonikultuuris, võite saavutada 2000-kordse kiirenduse. Sellele kiirendusele vastab võrdne stabiilsuse paranemine. See on kvantitatiivne mõõtmine kasu kohta, mida DevOps võib igale ettevõttele tuua. Paar aastat tagasi rääkisin DevOpsist ühe Fortune 5000 ettevõtte tegevjuhile.Esitluseks valmistudes olin väga närvis, sest pidin oma aastatepikkuse kogemuse 5 minutiga kokku võtma.
Lõpuks andsin järgmise DevOpsi määratlus: see on tavade ja mustrite kogum, mis võimaldab muuta inimkapitali suure jõudlusega organisatsioonikapitaliks. Näiteks võib tuua viisi, kuidas Toyota on viimased 50 või 60 aastat tegutsenud.
(Edaspidi on sellised skeemid toodud mitte võrdlusmaterjalina, vaid illustratsioonidena. Nende sisu on iga uue ettevõtte puhul erinev. Pilti saab aga eraldi vaadata ja suurendada
Üks edukamaid selliseid tavasid on väärtus oja kaardistamine. Sellest on kirjutatud mitu head raamatut, millest edukaimad on Karen Martinilt. Kuid viimase aasta jooksul olen jõudnud järeldusele, et isegi selline lähenemine on liiga kõrgtehnoloogiline. Sellel on kindlasti palju eeliseid ja ma olen seda palju kasutanud. Kuid kui tegevjuht küsib, miks tema ettevõte ei saa uutele rööbastele üle minna, on vara väärtusvoo kaardistamisest rääkida. On palju põhimõttelisemaid küsimusi, millele tuleb esmalt vastata.
Arvan, et paljude mu kolleegide viga on see, et nad annavad ettevõttele lihtsalt viiepunktilise juhendi ja tulevad siis kuus kuud hiljem tagasi ja vaatavad, mis juhtus. Isegi heal skeemil, nagu väärtusvoo kaardistamine, on näiteks pimealad. Pärast sadu intervjuusid erinevate ettevõtete direktoritega olen välja töötanud teatud mustri, mis võimaldab meil probleemi komponentideks jagada, ja nüüd arutame kõiki neid komponente järjekorras. Enne tehnoloogiliste lahenduste rakendamist kasutan seda mustrit ja selle tulemusena on kõik minu seinad diagrammidega kaetud. Hiljuti töötasin investeerimisfondiga ja sattusin 100-150 sellise skeemi juurde.
Halb kultuur sööb hommikusöögiks häid lähenemisi
Põhiidee on järgmine: ükski Lean, Agile, SAFE ja DevOps ei aita, kui organisatsiooni kultuur ise on halb. See on nagu sukeldumine sügavusse ilma sukeldumisvarustuseta või töötamine ilma röntgenita. Teisisõnu, parafraseerides Druckerit ja Demingit: halb organisatsioonikultuur neelab iga hea süsteemi alla, ilma et see lämbuks.
Selle põhiprobleemi lahendamiseks peate tegema järgmised sammud:
- Tee kõik tööd nähtavaks: peate kogu töö nähtavaks tegema. Mitte selles mõttes, et see peab ilmtingimata olema mingil ekraanil kuvatud, vaid selles, et see peab olema jälgitav.
- Konsolideeritud tööhaldussüsteemid: juhtimissüsteemid tuleb konsolideerida. “Hõimu” teadmiste ja institutsionaalsete teadmiste probleemis on 9 juhul 10-st kitsaskohaks inimesed. Raamatus probleem oli ühe inimese, Brentiga, kelle tõttu jäi projekt graafikust kolm aastat maas. Ja ma satun nende "Brentide" otsa igal pool. Nende kitsaskohtade lahendamiseks kasutan meie loendis kahte järgmist üksust.
- Piirangute teooria metoodika: piirangute teooria.
- Koostöö häkkimine: koostöö häkkimine.
- Toyota Kata (): Ma ei räägi palju Toyota Katast. Kui olete huvitatud, siis minu githubis peaaegu kõigil neil teemadel.
- Turule orienteeritud organisatsioon: turule orienteeritud organisatsioon.
- Vahetusega vasakpoolsed audiitorid: audit tsükli varases staadiumis.
Alustan organisatsiooniga töötamist väga lihtsalt: lähen ettevõttesse ja räägin töötajatega. Nagu näete, pole kõrgtehnoloogiat. Kõik, mida vajate, on midagi, millele kirjutada. Kogun ühte ruumi mitu meeskonda ja analüüsin, mida nad mulle minu 7 arhetüübi vaatenurgast räägivad. Ja siis annan neile ise markeri ja palun kirjutada tahvlile üles kõik, mida nad on seni kõva häälega öelnud. Tavaliselt on seda tüüpi koosolekutel üks inimene, kes kõik kirja paneb ja parimal juhul suudab ta kirja panna 10% arutelust. Minu meetodiga saab seda näitajat tõsta umbes 40%-ni.
(Seda illustratsiooni saab vaadata eraldi )
Minu lähenemine põhineb William Schneideri töödel. ). Lähenemisviis põhineb ideel, et iga organisatsiooni saab jagada neljaks ruuduks. See skeem on minu jaoks tavaliselt nende sadade muude skeemidega töötamise tulemus, mis organisatsiooni analüüsides tekivad. Oletame, et meil on kõrge kontrollitasemega, kuid madala kompetentsiga organisatsioon. See on äärmiselt ebasoovitav variant: kui kõik on joonel, kuid keegi ei tea, mida teha.
Mõnevõrra parem variant on kõrge kontrolli- ja pädevustasemega variant. Kui selline ettevõte on kasumlik, siis võib-olla ei vaja ta DevOpsi. Kõige huvitavam on töötada ettevõttega, kus on kõrge kontroll, madal kompetents ja koostöö, kuid samas kõrge kultuur (kasvatus). See tähendab, et ettevõttes on palju inimesi, kellele meeldib seal töötada ja tööjõu voolavus on väike.
(Seda illustratsiooni saab vaadata eraldi )
Mulle tundub, et jäikade suunistega meetodid jäävad lõpuks tõe saavutamise teele. Eelkõige väärtusvoo kaardistamise puhul on teabe struktureerimise kohta palju reegleid. Töö algfaasis, millest ma praegu räägin, pole neid reegleid kellelegi vaja. Kui inimene, kellel on marker käes, kirjeldab juhatusel tegelikku olukorda ettevõttes, on see parim viis asjade seisust aru saada. Direktoriteni selline info ei jõua. Praegusel hetkel on rumal inimest vahele segada ja öelda, et ta joonistas mingisuguse noole valesti. Selles etapis on parem kasutada lihtsaid reegleid, näiteks: mitmetasandilist abstraktsiooni saab luua lihtsalt mitmevärviliste markerite abil.
Kordan, kõrgtehnoloogiat pole. Must marker kujutab objektiivset tegelikkust, kuidas kõik toimib. Punase markeriga märgivad inimesed, mis neile praeguses asjades ei meeldi. On oluline, et nad kirjutaksid seda, mitte mina. Kui ma pärast koosolekut CIO juurde lähen, ei paku ma nimekirja 10 asjast, mis vajavad parandamist. Püüan leida seoseid ettevõtte inimeste öeldu ja olemasolevate tõestatud mustrite vahel. Lõpuks soovitab sinine marker probleemile võimalikke lahendusi.
(Seda illustratsiooni saab vaadata eraldi )
Selle lähenemisviisi näide on nüüd ülalpool. Selle aasta alguses töötasin ühe pangaga. Sealsed turvainimesed olid veendunud, et disaini ja nõuete ülevaatustele ei tasu tulla.
(Seda illustratsiooni saab vaadata eraldi )
Ja siis rääkisime inimestega teistest osakondadest ja selgus, et umbes 8 aastat tagasi vallandasid tarkvaraarendajad turvatöötajaid, kuna nad pidurdasid tööd. Ja siis muutus see keeluks, mida peeti iseenesestmõistetavaks. Kuigi tegelikkuses mingit keeldu ei olnud.
Meie kohtumine kulges äärmiselt segaselt: umbes kolme tunni jooksul ei suutnud viis erinevat meeskonda mulle selgitada, mis toimub koodi ja koostu vahel. Ja see näib olevat kõige lihtsam asi. Enamik DevOpsi konsultante eeldab juba ette, et kõik teavad seda juba.
Siis ärkas tema teemani jõudes ootamatult ellu IT-juhtimise eest vastutav inimene, kes oli neli tundi vaikinud ja hõivas meid väga pikalt. Lõpuks küsisin temalt, mida ta kohtumisest arvab, ja ma ei unusta kunagi tema vastust. Ta ütles: "Varem arvasin, et meie pangal on tarkvara tarnimiseks ainult kaks võimalust, kuid nüüd tean, et neid on viis ja ma ei teadnud isegi kolmest."
(Seda illustratsiooni saab vaadata eraldi )
Viimane kohtumine selles pangas oli investeerimistarkvara meeskonnaga. Just temaga selgus, et skeemide kirjutamine markeriga paberilehele on parem kui tahvlile ja isegi parem kui nutikale tahvlile.
Fotod, mida näete, on sellised, nagu nägi välja hotelli konverentsiruum meie kohtumise neljandal päeval. Ja me kasutasime neid skeeme mustrite, st arhetüüpide otsimiseks.
Niisiis, ma esitan töötajatele küsimusi, nad kirjutavad vastused kolme värvi (must, punane ja sinine) markeritega. Analüüsin nende vastuseid arhetüüpide osas. Nüüd arutame kõiki arhetüüpe järjekorras.
1. Tee kõik tööd nähtavaks: tee töö nähtavaks
Enamikus ettevõtetes, kellega ma töötan, on teadmata töö osakaal väga suur. Näiteks see, kui üks töötaja tuleb teise juurde ja palub lihtsalt midagi teha. Suurtes organisatsioonides võib olla 60% planeerimata tööd. Ja kuni 40% tööst ei ole kuidagi dokumenteeritud. Kui see oleks Boeing, ei astuks ma enam kunagi oma elus nende lennukile. Kui ainult pool tööst on dokumenteeritud, siis pole teada, kas seda tööd tehakse õigesti või mitte. Kõik muud meetodid osutuvad kasutuks – pole mõtet midagi automatiseerida, sest teadaolev 50% võib olla töö kõige sidusam ja selgem osa, mille automatiseerimine ei anna just suuri tulemusi ja kõige hullem. asjad on nähtamatus pooles. Dokumentatsiooni puudumisel on võimatu leida igasuguseid häkke ja varjatud töid, mitte leida kitsaskohti, just neid “Brentsi”, millest ma juba rääkisin. Seal on suurepärane Dominica DeGrandise raamat . Ta paljastab viis erinevat "ajaleket" (ajavargad):
- Liiga palju tööd protsessis (WIP)
- Tundmatud sõltuvused
- Planeerimata töö
- Vastuolulised prioriteedid
- Tähelepanuta jäetud töö
See on väga väärtuslik analüüs ja raamat on suurepärane, kuid kõik need nõuanded on kasutud, kui ainult 50% andmetest on nähtavad. Dominica pakutud meetodeid saab kasutada, kui saavutatakse üle 90% täpsus. Ma räägin olukordadest, kus ülemus annab alluvale 15-minutilise ülesande, aga tal kulub selleks kolm päeva; aga ülemus tegelikult ei tea, et see alluv veel nelja-viie inimese ülalpeetav on.
Phoenixi projekt on suurepärane lugu projektist, mis oli kolm aastat liiga hilja. Ühte tegelast ootab seetõttu vallandamine ja ta kohtub teise tegelasega, keda esitletakse omamoodi Sokratesena. Ta aitab välja selgitada, mis täpselt valesti läks. Selgub, et ettevõttel on üks süsteemiadministraator, kelle nimi on Brent ja kogu töö käib kuidagi tema kaudu. Ühel koosolekul küsitakse ühelt alluvalt: miks iga pooletunnine ülesanne võtab nädala? Vastuseks on väga lihtsustatud esitlus järjekorrateooriast ja Little'i seadusest ning selles esitluses tuleb välja, et 90% täituvuse juures võtab iga töötund aega 9 tundi. Iga ülesanne tuleb saata seitsmele teisele inimesele, nii et sellest tunnist saab 63 tundi, 7 korda 9. Ma tahan öelda, et Little'i seaduse või mõne keeruka järjekorrateooria kasutamiseks peavad teil olema vähemalt andmed.
Nii et kui ma räägin nähtavusest, ei pea ma silmas seda, et kõik on ekraanil, vaid et teil on vähemalt andmed olemas. Kui nad seda teevad, selgub sageli, et on väga suur hulk planeerimata töid, mis saadetakse kuidagi Brenti, kui selleks pole vajadust. Ja Brent on suurepärane tüüp, ta ei ütle kunagi ei, kuid ta ei räägi kellelegi, kuidas ta oma tööd teeb.
Kui töö on näha, saab andmed kenasti klassifitseerida (seda teeb fotol Dominika), rakendada viie aja lekke abstraktsiooni ja rakendada automatiseerimist.
2. Tööhaldussüsteemide konsolideerimine: ülesannete haldamine
Arhetüübid, millest ma räägin, on omamoodi püramiid. Kui esimene on õigesti tehtud, siis teine on juba omamoodi lisand. Paljud neist ei tööta idufirmade puhul, neid tuleb meeles pidada suuremate ettevõtete puhul, nagu Fortune 5000. Viimasel ettevõttel, kus ma töötasin, oli 10 piletimüügisüsteemi. Ühel meeskonnal oli Remedy, teine kirjutas mingi oma süsteemi, kolmas kasutas Jirat ja mõni leppis meiliga. Sama probleem tekib siis, kui ettevõttel on 30 erinevat torustikku, kuid mul ei ole aega kõigi selliste juhtumite arutamiseks.
Arutan inimestega täpselt, kuidas pileteid luuakse, mis nendega edasi saab ja kuidas neist mööda hiilitakse. Kõige huvitavam on see, et inimesed meie koosolekutel räägivad üsna siiralt. Küsisin, kui paljud inimesed panevad piletitele "väikese mõju / puudub mõju", millele tegelikult tuleks anda "suur mõju". Selgus, et peaaegu kõik teevad seda. Ma ei tegele hukkamõistmisega ja püüan igal võimalikul viisil inimesi mitte tuvastada. Kui nad mulle midagi siiralt tunnistavad, ei anna ma inimest ära. Kuid kui peaaegu kõik lähevad süsteemist mööda, tähendab see, et kogu turvalisus on sisuliselt akende kaunistamine. Seetõttu ei saa selle süsteemi andmetest järeldusi teha.
Piletiprobleemi lahendamiseks peate valima ühe põhisüsteemi. Kui kasutate Jirat, hoidke see Jira. Kui on mõni alternatiiv, siis olgu see ainuke. Põhimõte on see, et pileteid tuleks vaadelda arendusprotsessi järjekordse sammuna. Igal toimingul peab olema pilet, mis peab läbima arendustöövoo. Piletid saadetakse meeskonnale, kes postitab need storyboardile ja võtab seejärel nende eest vastutuse.
See kehtib kõigi osakondade, sealhulgas infrastruktuuri ja operatsioonide kohta. Sel juhul on võimalik asjade seisust moodustada vähemalt mingi usutav ettekujutus. Kui see protsess on sisse seatud, muutub äkitselt lihtsaks tuvastada, kes vastutab iga rakenduse eest. Sest nüüd saame mitte 50%, vaid 98% uutest teenustest. Kui see põhiprotsess töötab, paraneb täpsus kogu süsteemis.
Teenuste torustik
See kehtib jällegi ainult suurkorporatsioonide kohta. Kui olete uues valdkonnas uus ettevõte, käärige käised üles ja töötage oma Travis CI või CircleCI-ga. Mis puutub Fortune 5000 ettevõtetesse, siis näide, mis juhtus pangas, kus ma töötasin. Google tuli nende juurde ja neile näidati vanade IBMi süsteemide diagramme. Google’i kutid küsisid segaduses – kus on selle lähtekood? Kuid seal pole lähtekoodi, isegi mitte GUI-d. See on reaalsus, millega suured organisatsioonid peavad tegelema: 40-aastased pangakirjed iidsel suurarvutil. Üks minu klientidest kasutab KeyBanki rakenduse jaoks Kubernetese konteinereid Circuit Breaker mustriga ja Chaos Monkeyt. Kuid need konteinerid ühendatakse lõpuks COBOL-i rakendusega.
Google'i kutid olid täiesti kindlad, et nad lahendavad kõik minu kliendi probleemid ja hakkasid siis küsima: mis on IBMi andmetoru? Neile öeldakse: see on pistik. Millega see seostub? Sperry süsteemi juurde. Ja mis see on? Ja nii edasi. Esmapilgul tundub: mis DevOps võib olla? Kuid tegelikult on see võimalik. On olemas tarnesüsteemid, mis võimaldavad teil töövoo kohaletoimetamismeeskondadele üle anda.
3. Piirangute teooria: piirangute teooria
Liigume edasi kolmanda arhetüübi juurde: institutsionaalsed/"hõimulised" teadmised. Reeglina on igas organisatsioonis mitu inimest, kes teavad kõike ja juhivad kõike. Need on need, kes on organisatsioonis olnud kõige kauem ja kes teavad kõiki lahendusi.
Kui see diagrammile ilmub, tõmban sellistele inimestele spetsiaalselt markeriga ringi: näiteks selgub, et teatud Lou on kõigil koosolekutel kohal. Ja mulle on selge: see on kohalik Brent. Kui CIO valib minu T-särgis ja tossudes ja ülikonnas IBM-i tüübi vahel, valitakse mind sellepärast, et võin direktorile rääkida asju, mida teine mees ei räägi ja mida direktorile ei pruugi meeldida kuulda. . Ma ütlen neile, et nende ettevõtte kitsaskoht on keegi Fred ja keegi Lou. See kitsaskoht tuleb lahti harutada, nende teadmised nii või teisiti neilt hankida.
Sellise probleemi lahendamiseks võin näiteks soovitada kasutada Slacki. Tark lavastaja küsib – miks? Tavaliselt vastavad DevOpsi konsultandid sellistel juhtudel: sest kõik teevad seda. Kui lavastaja on tõesti tark, siis ta ütleb: mis siis ikka. Ja siin dialoog lõpeb. Ja minu vastus sellele on: kuna ettevõttes on neli kitsaskohta, Fred, Lou, Susie ja Jane. Nende teadmiste institutsionaliseerimiseks tuleb esmalt tutvustada Slacki. Kõik su vikid on täielik jama, sest keegi ei tea nende olemasolust. Kui insenerimeeskond on seotud esiotsa ja tagaotsa arendusega ja kõik peavad teadma, et nad võivad küsimustega pöörduda esiotsa arendusmeeskonna või infrastruktuuri meeskonna poole. See on siis, kui Loul või Fredil on tõenäoliselt aega wikiga liituda. Ja siis võib keegi Slackis küsida, miks näiteks samm 5 ei tööta. Ja siis Lou või Fred parandavad vikis olevaid juhiseid. Kui see protsess paika panna, loksuvad paljud asjad iseenesest paika.
See on minu põhipunkt: selleks, et mingeid kõrgtehnoloogiaid soovitada, tuleb neile esmalt vundament korda teha ja seda saab teha just kirjeldatud madaltehnoloogiliste lahendustega. Kui alustate kõrgtehnoloogiatega ega selgita, miks neid vaja on, siis reeglina see hästi ei lõpe. Üks meie klientidest kasutab Azure ML-i, mis on väga odav ja lihtne lahendus. Umbes 30% nende küsimustest vastas iseõppimismasin ise. Ja selle asja kirjutasid operaatorid, kes ei olnud seotud ei andmeteaduse, statistika ega matemaatikaga. See on märkimisväärne. Sellise lahenduse maksumus on minimaalne.
4. Koostööhäkid: koostööhäkid
Neljas arhetüüp on vajadus võidelda isolatsiooniga. Enamik inimesi teab seda juba: isolatsioon tekitab vaenulikkust. Kui iga osakond on oma korrusel ja inimesed ei ristu üksteisega mitte kuidagi, välja arvatud liftis, siis tekib nendevaheline vaen väga kergesti. Aga kui vastupidi, inimesed on üksteisega samas ruumis, lahkub ta kohe. Kui keegi viskab välja mõne üldsüüdistuse, näiteks selline ja selline liides ei tööta kunagi, pole midagi lihtsamat sellist süüdistust lahti mõtestada. Liidese kirjutanud programmeerijatel tuleb lihtsalt hakata konkreetseid küsimusi esitama ja peagi selgub, et näiteks kasutaja kasutas tööriista lihtsalt valesti.
Isolatsioonist ülesaamiseks on palju viise. Kunagi paluti mul Austraalias pangaga konsulteerida, kuid ma keeldusin seda tegemast, kuna mul on kaks last ja naine. Kõik, mida ma sain nende abistamiseks teha, oli soovitada graafilist jutuvestmist. See on midagi, mille toimimine on tõestatud. Teine huvitav viis on lahja kohvi koosolekud. Suures organisatsioonis on see suurepärane võimalus teadmiste levitamiseks. Lisaks saate läbi viia sisemisi devopsdays, häkatone ja nii edasi.
5. Treener Kata
Nagu ma alguses hoiatasin, ma sellest täna ei räägi. Kel huvi, võib vaadata .
Sellel teemal on hea jutt ka Mike Rotherilt:
6. Turule orienteeritud: turule orienteeritud organisatsioon
Siin on erinevaid probleeme. Näiteks "I" inimesed, "T" inimesed ja "E" inimesed. "Mina" inimesed on need, kes teevad ainult ühte asja. Tavaliselt eksisteerivad need organisatsioonides, millel on isoleeritud osakonnad. "T" on see, kui inimene on hea ühes asjas, kuid hea ka mõnes muus. "E" või isegi "kamm" on see, kui inimesel on palju oskusi.
Conway seadus töötab siin (), mida kõige lihtsustatud kujul võib väita järgmiselt: kui koostaja kallal töötab kolm meeskonda, siis on tulemuseks kolmeosaline koostaja. Seega, kui organisatsiooni sees on kõrge isoleerituse tase, siis on isegi Kubernetes, Circuit breaker, API laiendatavus ja muud uhked asjad selles organisatsioonis korraldatud samamoodi nagu organisatsioon ise. Rangelt vastavalt Conwayle ja kõigile noortele nörttidele vaatamata.
Selle probleemi lahendust on korduvalt kirjeldatud. Seal on näiteks Fernando Fernandezi kirjeldatud organisatsiooni arhetüübid. See probleemne arhitektuur, millest ma just rääkisin, on eraldiseisvalt funktsioonidele orienteeritud arhitektuur. Teine tüüp on halvim maatriksarhitektuur, kahe ülejäänud segadus. Kolmas on see, mida nähakse enamikes idufirmades ja ka suurettevõtted püüavad sellele tüübile sobitada. Tegemist on turule orienteeritud organisatsiooniga. Siin me optimeerime, et saavutada klientide päringutele kiireim reageerimine. Seda nimetatakse mõnikord tasaseks organisatsiooniks.
Paljud inimesed kirjeldavad seda struktuuri erinevalt, mulle meeldib see sõnastus luua/juhtida meeskondi, Amazonis nad kutsuvad seda kaks pitsameeskonda. Selles struktuuris on kõik I-tüüpi inimesed rühmitatud ühe teenuse ümber ja järk-järgult lähenevad nad T-tüübile ning õige juhtimise korral võib neist saada isegi E. Esimene vastuargument siin on see, et sellisel struktuuril on mittevajalikke elemente. Milleks on vaja igasse osakonda testijat, kui saab omada spetsiaalset testijate osakonda? Millele ma vastan: lisakulud on sel juhul hind, mille eest kogu organisatsioon tulevikus E-tüüpi saab. Selles struktuuris õpib testija järk-järgult tundma võrke, arhitektuuri, disaini jne. Selle tulemusena on iga organisatsioonis osaleja täielikult kursis kõigega, mis organisatsioonis toimub. Kui soovite teada, kuidas see skeem tööstuses töötab, lugege .
7. Vahetusega vasakpoolsed audiitorid: auditeerige tsükli alguses. Ohutuseeskirjade järgimine väljapanekul
See on siis, kui sinu tegevus ei läbi nii-öelda lõhnatesti. Inimesed, kes teie heaks töötavad, ei ole rumalad. Kui nad, nagu ülaltoodud näites, määrasid kõikjal väikese/puuduva mõju, see kestis kolm aastat ja keegi ei märganud midagi, siis teavad kõik suurepäraselt, et süsteem ei tööta. Või teine näide - muudatuste nõukoda, kus aruandeid on vaja esitada igal näiteks kolmapäeval. Seal töötab grupp inimesi (muide, mitte väga hästi tasustatud), kes teoreetiliselt peaks teadma, kuidas süsteem tervikuna toimib. Ja viimase viie aasta jooksul olete ilmselt märganud, et meie süsteemid on uskumatult keerulised. Ja viis-kuus inimest peavad tegema otsuse muudatuse kohta, mida nad ei teinud ja millest nad midagi ei tea.
See lähenemine muidugi ei tööta. Ma pean sellistest asjadest lahti saama, sest need inimesed ei kaitse süsteemi. Otsuse peab tegema meeskond ise, sest meeskond peab selle eest vastutama. Vastasel juhul tekib paradoksaalne olukord, kui juht, kes pole elus kordagi koodi kirjutanud, ütleb programmeerijale, kui kaua peaks koodi kirjutamine aega võtma. Ühel ettevõttel, kellega ma töötasin, oli 7 erinevat tahvlit, mis vaatasid üle kõik muudatused, sealhulgas arhitektuuriplaat, tooteplaat jne. Seal oli isegi kohustuslik ooteaeg, kuigi üks töötaja ütles mulle, et kümne tööaasta jooksul pole keegi selle inimese poolt selle kohustusliku perioodi jooksul tehtud muudatust tagasi lükanud.
Audiitorid tuleb kutsuda meiega liituma, mitte neist lahti saama. Öelge neile, et kirjutate muutumatuid binaarkonteinereid, mis kõik testid läbides jäävad muutumatuks igavesti. Öelge neile, et teil on koodina konveier ja selgitage, mida see tähendab. Näidake neile järgmist skeemi: muutumatu kirjutuskaitstud kahendfail konteineris, mis läbib kõik haavatavuse testid; ja siis mitte ainult ei puuduta keegi seda, vaid isegi ei puuduta torujuhtme loovat süsteemi, kuna see luuakse ka dünaamiliselt. Mul on kliente, Capital One, kes kasutavad Vaulti, et luua midagi plokiahela taolist. Audiitor ei pea näitama Chefi “retsepte”, piisab plokiahela näitamisest, millest selgub, mis tootmises oleva Jira piletiga juhtus ja kes selle eest vastutab.
Vastavalt , mille Sonatype lõi 2018. aastal, oli 2017. aastal 87 miljardit OSS-i allalaadimistaotlust.
Haavatavustest tekkinud kahjud on ülemäära suured. Lisaks ei sisalda ülaltoodud arvud alternatiivkulusid. Mis on DevSecOps lühidalt? Ütlen kohe ära, et ma ei ole huvitatud sellest, kui edukas see nimi on. Asi on selles, et kuna DevOps on olnud nii edukas, peaksime proovima sellele torujuhtmele turvalisust lisada.
Selle jada näide:
See ei ole soovitus konkreetsete toodete jaoks, kuigi mulle meeldivad need kõik. Tõin need näitena, et näidata, et DevOps, mis põhines algselt tööstuse organisatsioonilisel paradigmal, võimaldab teil automatiseerida iga tootega töötamise etappi.
Ja pole põhjust, miks me ei võiks turvalisusele samamoodi läheneda.
Summaarne
Kokkuvõtteks annan mõned näpunäited DevSecOpsi kohta. Peate oma süsteemide loomise protsessi kaasama audiitorid ja kulutama aega nende harimisele. Peate tegema koostööd audiitoritega. Järgmiseks peate pidama absoluutselt halastamatut võitlust valepositiivsete tulemuste vastu. Isegi kõige kallima haavatavuse kontrollimise tööriistaga võite oma arendajate seas luua äärmiselt halbu harjumusi, kui te ei tea, milline on teie signaali-müra suhe. Arendajad on sündmustest üle koormatud ja kustutavad need lihtsalt. Kui kuulsite Equifaxi loost, siis seal juhtus peaaegu nii, kus kõrgeimat häiretaset eirati. Lisaks tuleb haavatavusi selgitada nii, et oleks selge, kuidas need ettevõttele mõju avaldavad. Näiteks võite öelda, et see on sama haavatavus nagu Equifaxi loos. Turvanõrkusi tuleks käsitleda samamoodi nagu muid tarkvaraprobleeme, st need tuleks kaasata üldisesse DevOpsi protsessi. Peate nendega koostööd tegema Jira, Kanbani jne kaudu. Arendajad ei tohiks arvata, et keegi teine seda teeb – vastupidi, kõik peaksid seda tegema. Lõpuks peate kulutama energiat inimeste koolitamiseks.
Kasulikud lingid
Siin on mõned DevOopsi konverentsi kõned, mis võivad teile kasulikuks osutuda:
- Sergei Berdnikov, Artjom Kalichkin – Edulugu ehk “Dev+DevOps+Ops” (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps skaalal: Kreeka tragöödia kolmes vaatuses (, )
- Aleksander Titov, Kirill Tolkatšov -
- Timothy Lister -
Vaata sisse DevOops 2020 Moskva — seal on ka palju huvitavat.
Allikas: www.habr.com