Küsimus "kuidas DevOps'i enda juurde rakendada" on püsinud juba mitu aastat, kuid häid materjale ei ole eriti palju. Vahel satute te mitteteadlike konsultantide reklaamkerge ohvriks, kellele on tähtis müüa oma aega, ükskõik kuidas. Mõnikord on see udused, äärmiselt üldised sõnad selle kohta, kuidas hiidkorporatsioonide laevad avarustes seilavad. Kuidas see meid aga mõjutab? Auväärt autor, kas saaksite arusaadavalt loetleda oma ideed?
Kõik see tuleneb sellest, et reaalse praktika ja arusaamise osas ettevõtte kultuuri transformatsioonidest on teadmisi veel vähe. Muutused kultuuris on pikaajalised asjad, mille tulemusi ei näe nädala ega kuu pärast. Me vajame kedagi, kes on piisavalt kogenud ja näinud, kuidas ettevõtted on loodud ja kokku kukkunud läbi aastate.
John Willis on üks DevOp'i isa. Johnil on aastate pikkune kogemus, töötades paljude ettevõtetega. Viimasel ajal on John hakanud märkama spetsiifilisi mustreid, mis on igaühes töös omased. Kasutades neid arhetüüpe, suunab John ettevõtteid tõelisele DevOps'i transformatsiooniteele. Rohkem nende arhetüüpide kohta leiate tema DevOops 2018 konverentsi ettekande tõlkest.
Ettekanne:
Üle 35 aastat IT-halduse valdkonnas, osalenud OpenCloudi eelkäija loomisel Canonicalis, olnud kaasatud 10 käivitusettevõttesse, millest kaks müüdi Dellile ja Dockerile. Hetkel on ta SJ Technologiesi DevOps'i ja Digitaalsete Praktikate asepresident.
Edasi räägib John.
Mina olen John Willis ja mind leiab kõige lihtsamalt Twitterist, . Sama hüüdnimi on mul ka Gmailis ja GitHub'is. Ja leiate te minu ettekannete ja esitluste videod.
Mul on palju kohtumisi erinevate suurte ettevõtete CIO-dega. Nad kurdavad sageli, et ei saa aru, mis asi on DevOps, ja kõik, kes püüavad seda neile selgitada, räägivad millestki, mis on neile tuttav. Teine sage kaebus on see, et DevOps ei tööta, kuigi tundub, et direktorid teevad kõik nii, nagu on neile selgitatud. Jutt käib suurtest ettevõtetest, mis on eksisteerinud üle saja aasta. Suheldes nendega, jõudsin järeldusele, et paljude probleemide lahendamiseks sobivad paremini mitte kõrgtehnoloogilised, vaid suhteliselt madala tehnoloogia lahendused. Nädalaid suheldes erinevate osakondade inimestega. See, mida näete postituse esimesel pildil — see on minu viimane projekt, ruum nägi välja pärast kolme päeva tööd.
Mis on DevOps?
Tõepoolest, kui küsida kümnelt erinevalt inimeselt, annavad nad kümme erinevat vastust. Kuid siin on huvitav asi: kõik need kümme vastust on õiged. Vale vastust siin ei ole. Olen DevOpsiga süvitsi tegelenud umbes 10 aastat, olin esimene ameeriklane esimesel DevOpsDay'l. Ei ütle, et olen targem kui kõik, kes DevOpsiga tegelevad, aga ilmselt on harva kedagi, kes on sellesse energiat panustanud sama palju. Usun, et DevOps tekib siis, kui ühenduvad inimkapital ja tehnoloogia. Tihti unustame inimliku mõõtme, kuigi räägime palju erinevatest kultuuridest.
Praegu on meil palju andmeid, viie aasta jooksul tehtud akadeemilisi uuringuid, teooriate kontrollimine tööstuslikus mahus. Need uuringud ütlevad meile järgmist: kui organisatsioonikultuuris ühendatakse mõned käitumismustrid, võib saavutada kiirus suurenemise 2000 korda. Selle kiirusetõusuga vastab sama parendamine stabiilsusele. See on kvantitatiivne mõõde sellest eelisarvest, mida DevOps suudab anda mis tahes ettevõttele. Paar aastat tagasi rääkisin DevOps'ist Fortune 5000 ettevõtte tegevjuhile. Kui valmistusin esitluseks, olin väga närvis, sest pidin viie minutiga esitama oma aastatepikkuse kogemuse.
Kokkuvõttes andsin järgmise DevOps määratluse: see on praktikate ja mustrite kogum, mis võimaldab muuta inimkapitali kõrge tootlikkusega organisatsioonikapitaliks. Näide — see, kuidas Toyota on töötanud viimased 50 või 60 aastat.
(Edasi antud skeemid ei ole lihtsalt viidatud materjalina, vaid illustration. Nende sisu erineb iga uue ettevõtte puhul. Siiski saab pilti eraldi vaadata ja suurendada
Üks kõige edukamaid selliseid praktikaid on value stream mapping.Selle kohta on kirjutatud mõned head raamatud, autor kõige edukamatest neist on Karen Martin. Kuid viimasel aastal olen jõudnud järeldusele, et isegi see lähenemine on liiga tehnoloogiline. Sel on kindlasti palju eeliseid, mida olen palju kasutanud. Kuid kui peadirektor küsib, miks tema ettevõte ei suuda uusi rööpale minna, on veel vara rääkida value stream mapping'ust. On palju märkimisväärselt fundamentaalsemaid küsimusi, millele tuleb eelnevalt vastused leida.
Minu arvates on paljude kolleegide viga see, et nad lihtsalt annavad ettevõttele viie punkti juhendi ja seejärel tulevad kuue kuu pärast tagasi ning vaatavad, mis juhtus. Isegi hea skeemi, nagu value stream mapping, puhul on olemas nii-öelda pimedad kohad. Pärast sadu intervjuusid erinevate ettevõtete direktoritega olen välja töötanud teatud mustri, mis võimaldab probleemi elementideks jagada, ja nüüd arutame neid komponente üksikasjalikult. Enne kui rakendan mõnda tehnoloogia lahendust, kasutan seda mustrit ja tulemuseks on see, et kõik seinad on skeemidega kaetud. Hiljuti töötasin ühe investeerimisfondiga ja mul oli kokku 100-150 sellist skeemi.
Halb kultuur sööb häid lähenemisviise hommikusöögiks.
Peamine mõte on selline: ei Lean, Agile, SAFE ega DevOps ei aita, kui organisatsiooni kultuur on halb. See on nagu sukelduda sügavusse ilma hingamisaparaadita või opereerida ilma röntgenpildita. Teisisõnu, parafraseerides Druckerit ja Demingut: halb organisatsioonikultuur neelab alla iga hea süsteemi ja ei lämbu.
Selle peamise probleemi lahendamiseks on vajalik astuda järgmised sammud:
- Tee Kogu Töö Nähtavaks: kõik töö peaks olema nähtav. Mitte selles mõttes, et see peaks tingimata olema arvutiekraanil, vaid selles, et see peaks olema jälgitav.
- Konsolideeri Tööhalduse Süsteemid: On vajalik konsolideerida juhtimissüsteemid. Probleem „geneetilise” teadmise ja institutsionaalse teadmise osas on 9 juhul 10 kitsaskohaks inimesed. Raamatus oli probleem ühesainses inimeses, Brentis, kelle tõttu projekt hilines kolm aastat. Ja selliste „Brentide” otsa komistan kogu aeg. Nende kitsaskohtade lahendamiseks kasutan meie nimekirjas järgmisi kahte punkti.
- Teooria piirangute metoodika: piirangute teooria.
- Koostöö häkid: koostöö häkid.
- Toyota Kata (): Toyota Kata teemal ma ei räägi pikalt. Kui huvitab, siis minu GitHubis peaaegu iga selle teema kohta.
- Turule suunatud organisatsioon: turule suunatud organisatsioon.
- Shift-left auditeerijad: varajase etapi audit.
Alustan koostööd organisatsiooniga väga lihtsalt: lähen ettevõttesse ja räägin töötajatega. Nagu näeme, ei ole siin midagi keerulist. Kõik, mis on vajalik — on, millega kirjutada. Kogun mitmed tiimid ühte ruumi ja analüüsin, mida nad mulle ütlevad, oma seitsme arhetüübi vaatenurgast. Siis annan neile markerid ja palun kirjutada tahvlile kõik see, mida nad seni kõva häälega rääkisid. Tavaliselt on sellistel koosolekutel üks inimene, kes kõik üles kirjutab, ja parimal juhul õnnestub tal kirja panna 10% arutelust. Minu meetodi puhul õnnestub see näitaja tõsta kuskile 40% juurde.
(Erinevat illustreerimist saab )
Minu lähenemine põhineb William Schneideri töödel (William Schneider, ). Lähenemise aluseks on mõte, et iga organisatsiooni saab jagada neljaks ruuduks. See skeem on tavaliselt minu töö tulemus, mida olen teinud nende sadade teiste skeemidega, mis ilmnevad organisatsiooni analüüsimisel. Eeldame, et meil on organisatsioon, kus on kõrge kontrollitase, kuid madal pädevus. See on äärmiselt soovimatu variant: kui kõik käivad rikka, kuid keegi ei tea, mida teha.
Mõnevõrra parem variant, kus on kõrge kontrollitunne ja kompetents. Kui selline ettevõte teenib kasumit, siis võib-olla DevOps neile ei olegi vajalik. Huvitav on töötada ettevõttega, kus on kõrge kontrollitunne, madal kompetents ja koostöö, kuid samas kõrge kultuuri tase. See tähendab, et ettevõttes on palju inimesi, kellele meeldib seal töötada, ja töötajate vahetus on madal.
(Erinevat illustreerimist saab )
Mulle tundub, et rangelt määratletud soovituste meetodid lõppkokkuvõttes takistavad tõe saavutamist. Eelkõige value stream mappingi puhul on palju reegleid selle kohta, kuidas teavet struktureerida. Varases tööfaasis, millest ma praegu räägin, ei ole need reeglid kellelegi vajalikud. Kui inimene markeri käes kirjeldab tahvlil ettevõtte tegelikku olukorda, on see parim viis olukorraga tutvumiseks. Selline teave ei jõua direktoriteni. Sel hetkel on rumal katkestada inimest ja öelda, et ta on mingit noolt valesti joonistanud. Sellel etapil on parem kasutada lihtsaid reegleid, näiteks: mitmetasandilise abstraktsiooni saab luua, kasutades lihtsalt eri värvi markereid.
Kordan, mingeid kõrgtehnoloogiaid ei ole. Musta markeriga kujutatakse objektiivne reaalsus sellisena, nagu see töötab. Punase markeriga tähistavad inimesed, mis neile olemasolevas olukorras ei meeldi. Oluline on, et selle kirjutavad nemad, mitte mina. Kui pärast koosolekut lähen IT-juhile, ei paku ma 10 asja, mida tuleks parandada. Püüdlen sidemete leidmise poole selle vahel, mida inimesed ettevõttes räägivad, ja eksisteerivate, tõestatud mustrite vahel. Lõpuks pakuvad sinise markeriga välja võimalikud lahendused probleemile.
(Erinevat illustreerimist saab )
Sellise lähenemise näide on nüüd ülal toodud. Sel aastal töötasin ühe pangaga. Seal olid turvameetmete osakonna töötajad veendunud, et nad ei tohi osaleda nõuete ja projekteerimise kontrolldes (design and requirement reviews).
(Erinevat illustreerimist saab )
Ja siis rääkisime teiste osakondade inimestega ning selgus, et umbes 8 aastat tagasi tõrjusid tarkvaraarendajad turvatöötajad välja, kuna need aeglustasid tööd. Ja siis tekkis sellest keeld, mida hakati pidama iseenesestmõistetavaks. Kuigi tegelikult ei olnud mingit keeld.
Meie kohtumine kulges äärmiselt segases tempos: ligikaudu kolme tunni jooksul ei suutnud viis erinevat meeskonda mulle selgitada, mis toimub koodi ja kogumise vahel. See peaks ju olema kõige lihtsam asi. Enamik DevOps nõustajaid eeldavad, et see on juba kõigile teada.
Siis inimene, kes vastutas IT halduse eest (IT governance), kes oli neli tundi vait, ärkas äkki ellu, kui jõudsime tema teema juurde, ja haaras meid veel pikaks ajaks. Lõpuks küsisin temalt, mida ta arvas kohtumisest, ja ma ei unusta kunagi tema vastust. Ta ütles: "Varem arvasin, et meie pangas on tarkvara tarnimiseks kaks meetodit, aga nüüd tean, et neid on tegelikult viis, ja kolmest ma isegi ei kahtlustanud."
(Erinevat illustreerimist saab )
Viimane kohtumine selles pangas oli meeskonnaga, kes tegeleb investeerimistarkvaraga. Just nendega selgus, et skeemide kirjutamine markeriga paberile on parem kui tahvlile ja isegi parem kui nutitahvlile.
Fotod, mida te näete – need on sellised, nagu hotellis konverentsiruum neljandal kohtumise päeval välja nägi. Ja neid skeeme kasutasime mustrite, st arhetüüpide otsimiseks.
Nii et küsin töötajatelt küsimusi, nad kirjutavad vastused kolme värviga markeritega (must, punane ja sinine). Analüüsin nende vastuseid arhetüüpidest lähtudes. Nüüd arutame kõiki arhetüüpe järjekorras.
1. Make All Work Visible: Tehke kõik töö nähtavaks
Enamikus ettevõtetes, kellega ma töötan, on väga suur teadmata töö protsent. Näiteks, kui üks töötaja läheb teise juurde ja lihtsalt palub midagi teha. Suurtes organisatsioonides võib see ulatuda kuni 60% ettenägemata tööni. Ja kuni 40% tööst ei ole mingil moel dokumenteeritud. Kui see oleks Boeing, siis ma ei istuks kunagi enam nende lennukisse. Kui dokumenteeritakse vaid pool tööst, siis ei ole teada, kas töö on õigesti tehtud või mitte. Kõik teised meetodid osutuvad kasulikuks — ei ole mingit mõtet proovida midagi automatiseerida, kuna teadaolevad 50% võivad olla just kõige sujuvam ja täpsem osa tööst, mille automatiseerimine ei too suuri tulemusi, samas kui kõige hirmsam peitub nähtamatus pooles. Ilma dokumentatsioonita on võimatu leida igasuguseid häkke ja varjatud tööd, ei ole võimalik tuvastada kitsaskohti, neid „Brent’e”, millest ma juba rääkisin. On suurepärane raamat Dominica DeGrandiselt. . See toob esile viis erinevat „ajalekke“ (time thieves):
- Liigne töö eelprotsessis (WIP)
- Teadmata sõltuvused
- Ettenägemata töö
- Vastandlikud prioriteedid
- Unustatud töö
See on väga väärtuslik analüüs ning raamat on suurepärane, kuid kõik need nõuanded on kasutu, kui nähtav on vaid 50% andmetest. Meetodeid, mida Dominica soovitab, saab rakendada ainult siis, kui täpsus ületab 90%. Räägin olukordadest, kus juht annab alamale 15-minutilise ülesande, kuid see võtab aega kolm päeva; aga juht ei tea tegelikult, et see alluv sõltub veel neljast või viiest teisest inimesest.
Phoenix Project on suurepärane lugu projektist, mis jäi kolme aasta võrra hiljaks. Ühele tegelasele ähvardab tõttu seda vallandamine ja ta kohtub teise tegelasega, keda kujutatakse kui mingisugust Sokratest. Too aitab välja selgitada, mis täpselt valesti läks. Selgub, et ettevõttes on üks süsteemiadministraator, kelle nimi on Brent, ja kogu töö läbib tema käe. Ühel koosolekul küsitakse ühelt alluvalt: miks iga poole tunni ülesanne võtab nädala? Vastuseks on väga liialdatud järjekordade teooria ja Little'i seaduse selgitus ning selle kohaselt, kui kasutusaste on 90%, igas tunnis töötamine kestab 9 tundi. Iga ülesanne peab minema seitsmele teisele inimesele, seega muutub see tund 63 tunniks, 7 korda 9. Ma ütlen seda seetõttu, et Little'i seaduse või mõne keerulisema järjekordade teooria kasutamiseks on vaja vähemalt andmeid.
Seetõttu, kui räägin nähtavusest, ei pea ma silmas, et kõik oleks ekraanil, vaid et andmeid peab vähemalt olema. Kui need on olemas, selgub sageli, et on suur hulga planeerimata tööd, mis mingil põhjusel suunatakse Brentile, kuigi selle jaoks ei ole mingit vajadust. Ja Brent on suurepärane tüüp, ta ei ütle kunagi "ei", aga samas ei räägi ta kellelegi, kuidas ta oma tööd teeb.
Kui töö on nähtav, saab andmeid hoolikalt klassifitseerida (just sellega tegeleb Dominika fotol), saab rakendada viie aja lekkimise abstraktsiooni ja automatiseerida.
2. Töö haldamise süsteemide konsolideerimine: Ülesannete haldamine
Arhetüübid, millest ma räägin, on omaette püramiid. Kui esimene on õigesti teostatud, siis teine on juba mingis mõttes ülesehitus. Paljud neist ei toimi idufirmades, neid tuleb silmas pidada suurte ettevõtete puhul, nagu need, mis kuuluvad Fortune 5000 nimekirja. Viimases ettevõttes, kus ma töötasin, oli 10 vea jälgimise süsteemi (ticketing system). Ühes meeskonnas oli Remedy, teine kirjutas oma süsteemi, kolmas kasutas Jira, keegi kasutas täiesti e-postiga. Sama probleem ilmneb, kui ettevõttes on 30 erinevat juhtimisprotsessi, aga mul ei ole aega, et arutada kõiki selliseid juhtumeid.
Ma arutan inimestega, kuidas täpselt piletid luuakse, mis nendega edasi juhtub ja kuidas neid mööda hiilida. Kõige huvitavam on see, et meie kohtumistel räägivad inimesed üsna siiralt. Küsisin, kui palju inimesi määravad piletitele „väike / mitte mingit mõju“, millele tegelikult tuleks määrata „suure mõju“. Selgus, et peaaegu kõik teevad seda. Ma ei tegele pealehinejaga ja püüan hoida inimesi anonüümsetena. Kui keegi usaldusväärselt tunnistab, ei avalda ma nende nime. Kuid kui peaaegu kõik mööduvad süsteemist, tähendab see, et kogu turvalisus on tegelikult vaid dekoratsioon. Seega ei saa selle süsteemi andmete põhjal mingit järeldust teha.
Probleemi lahendamiseks piletitega tuleb valida üks peamine süsteem. Kui kasutate Jira, siis las see olla ainult Jira. Kui on mingi alternatiiv, siis las see olla ainult see. Asi on selles, et pileteid tuleb käsitleda kui veel üht etappi arendusprotsessis. Iga tegevuse jaoks peab olema pilet, mis peab läbima arendusprotsessi töövoo. Piletid saadetakse meeskonnale, kes paneb need storyboardile ja kannab siis vastutust nende eest.
See puudutab kõiki osakondi, sealhulgas infrastruktuuri ja operatiivset. Sellisel juhul on võimalik koostada vähemalt veidi usaldusväärne ülevaade olukorrast. Kui see protsess tööle hakkab, selgub äkki, et on lihtne kindlaks teha, kes vastutab iga rakenduse eest. Sest nüüd saame mitte 50%, vaid 98% uutest teenustest. Kui see põhiprotsess töötab, siis täpsus paraneb kogu süsteemis.
Teenuste pipeline
See on jälle ainult suurte korporatsioonide asi. Kui oled uus ettevõte uues valdkonnas – rullige üles varrukad ja töötage oma Travis CI või CircleCI'ga. Mis puutub Fortune 5000 ettevõtetesse, siis on räägitud juhtum, mis juhtus pangaga, kus ma töötasin. Google'ist tulid nad ja näitasid diagramme vanade IBM süsteemide kohta. Google'i poisid küsisid arusaamatult – kus on selle jaoks lähtekood? Lähtekoodi pole, isegi GUI-d pole. See on reaalsus, millega suured organisatsioonid peavad tegelema: 40-aastased pangarekordid vanal peamise raudvara peal. Üks minu klientidest kasutab Kubernetes konteinerite abil Circuit Breaker mustreid, pluss Chaos Monkey, kõik see KeyBanki rakenduse jaoks. Kuid need konteinerid ühendatakse lõpuks rakendusega COBOL-is.
Google'i poisid olid kindlad, et nad lahendavad kõik minu kliendi probleemid, kuid siis hakkasid nad küsima: mis on IBM datapipe? Neil vastatakse: see on konnektor. Kellele see ühendatakse? Sperry süsteemile. Mis see on? Ja nii edasi. Esmapilgul tundub, et siin ei saa olla DevOps-i, kuid tegelikult on see võimalik. On kohaletoimetamissüsteeme, mis võimaldavad edastada töövoo tiimidele, kes tegelevad kohaletoimetamisega.
3. Piirangute teooria: Teooria piirangutest
Liigume kolmandasse arhetüüpi: institutsionaalne / «klannide» teadmine. Üldiselt on igas organisatsioonis mõni inimene, kes teab kõike ja juhib kõike. Need on need, kes on organisatsioonis kõige kauem olnud ja tunnevad kõiki nurgataguseid.
Kui see diagrammil ilmneb, siis ma rõhutan selliseid inimesi markeriga: näiteks ilmneb, et mingi Lou on kõikidel koosolekutel kohal. Ja mulle on selge: see on kohaliku Brent. Kui IT-direktor peab valima minu vahel, kes olen T-särgis ja tossudes, ja ülikonnas IBM poisi vahel, valitakse mind, sest ma saan rääkida direktorile asjadest, millest teine poiss ei räägi ja mis võivad direktorile ebameeldivad olla. Ma ütlen neile, et nende ettevõttes on kitsaskoht, keegi nimega Fred ja keegi nimega Lou. See kitsaskoht tuleb avada, nende teadmised tuleb neilt mingil moel välja saada.
Selle probleemiga tegelemiseks võiksin näiteks soovitada Slacki kasutamist. Nutikas direktor küsib – miks? Tüüpiliselt, kui sellised olukorrad tekivad, vastavad DevOps konsultandid: sest kõik nii teevad. Kui direktor on tõeliselt nutikas, ütleb ta: ja mis siis? Ja see on koht, kus dialoog lõppeb. Minu vastus on: sest ettevõttes on neli kitsaskohta, Fred, Lou, Suzi ja Jane. Et muuta nende teadmised institutsionaliseerituks, tuleb kõigepealt tutvustada Slacki. Kõik teie vikid on täielik jama, kuna keegi ei tea nende olemasolust. Kui inseneride meeskond tegeleb nii välise kui ka sisemise arendusega, peavad kõik teadma, et nad saavad pöörduda välise arendusmeeskonna või infrastruktuuri meeskonna poole küsimustega. Just siis, kui Lou või Fredil on aega vikiga liituda. Ja siis võib Slackis keegi küsida, miks ei tööta, ütleme, samm 5. Siis parandavad Lou või Fred juhendit vikis. Kui see protsess käivitada, hakkab paljuski ise omal kohal olema.
Minu põhisõnum on see: et soovitada mingeid tipptasemel tehnoloogiaid, tuleb esmalt korda teha nende jaoks alus, ning seda saab teha äsja kirjeldatud madaltehnoloogiliste lahendustega. Kui aga alustada tipptasemel tehnoloogiatest ja mitte selgitada, miks need vajalikud on, lõppeb see tavaliselt halvasti. Üks meie klientidest kasutab Azure ML, väga odav ja lihtne lahendus. Umbes 30% küsimustest vastas juba iseõppiv masin. Ja selle asja kirjutasid operaatorid, kes ei tegelenud andmete teaduse, statistika või matemaatikaga. See on tähelepanuväärne. Sellise lahenduse maksumus on minimaalne.
4. Koostöö häkid: Koostöö häkid
Neljandas arhetüübis peitub vajadus võidelda isoleerituse vastu. Suur osa inimesi juba teab: isoleeritus tekitab vaenu. Kui iga osakond asub oma korrusel ja inimesed ei suhtle omavahel muul viisil kui liftis, siis vaenu tekkimine nende vahel on väga lihtne. Kui aga inimesed jagavad sama ruumi, kaob see vaen kiiresti. Kui keegi esitab üldise süüdistuse, näiteks et mõni liides ei tööta kunagi, on sellise süüdistuse analüüsimine väga lihtne. Programmijatele, kes on liidese loonud, piisab, kui hakata esitama konkreetseid küsimusi, ja varsti selgub, et näiteks kasutaja lihtsalt ei kasuta tööriista õigesti.
On palju viise, kuidas isoleeritust ületada. Mind paluti kunagi Austraalias panka nõustama, kuid ma keeldusin, sest mul on kaks last ja naine. Kõik, millega ma neid aidata sain, oli soovitada neile visuaalset jutustamist. See meetod on tõestatud efektiivne. Teine huvitav meetod on lean coffee formaadi kohtumised. Suures organisatsioonis on see suurepärane võimalus teadmiste jagamiseks. Lisaks saab korraldada sisemisi devops-päevi, hackathone ja nii edasi.
5. Coaching Kata
Nagu ma juba alguses hoiatasin, ei hakka ma sellest täna rääkima. Kui huvitav, saate vaadata .
On ka hea ettekande teema kohta Mike Rotherilt:
6. Turule orienteeritud: turule suunatud organisatsioon
Siin on erinevad probleemid. Näiteks inimesed "I", inimesed "T" ja inimesed "E". Inimesed "I" on need, kes tegelevad ainult ühe asjaga. Tavaliselt eksisteerivad nad just isoleeritud osakondadega organisatsioonides. "T" tähendab, et inimene tunneb hästi üht asja, kuid õnnestub ka mõnes teises. "E" või isegi "kamm" tähendab, et inimesel on palju oskusi.
Siin kehtib Conway seadus (), mille võib kõige lihtsamas vormis sõnastada nii: kui kolm meeskonda tegelevad kompilaatoriga, siis lõpuks saab kompilaator, mis koosneb kolmest osast. Seetõttu, kui organisatsioonis on kõrge isoleerituse tase, on isegi Kubernetes, Circuit breaker, API laiendatavus ja muud moes olevad asjad selle organisatsiooni sees üles ehitatud samamoodi nagu organisatsioon ise. Täpselt nagu Conway ütleb, ja pahaks teile, noored geekid.
Selle probleemi lahendust on korduvalt kirjeldatud. On olemas näiteks organisatoorsed arhetüübid, mida on kirjeldanud Fernando Fernandez. See probleemne arhitektuur, millest ma just rääkisin, isoleerimisega – see on funktsionaalselt orienteeritud arhitektuur. Teine tüüp on halvem, maatriksi arhitektuur, seal on kahe teise segunemine. Kolmas – seda, mida täheldatakse enamikes idufirmades, ja suured ettevõtted püüavad samuti sellele tüübile vastata. See on turule orienteeritud organisatsioon. Siin toimuvad optimeerimised, et saavutada kõige kiiremaid reageerimisi klientide päringutele. Mõnikord nimetatakse seda tasandatud organisatsiooniks.
Seda struktuuri kirjeldatakse paljusid erinevaid viise, mulle meeldib väljend build/run teams, Amazonis nimetatakse seda two pizza teams. Selles struktuuris rühmitatakse kõik inimesed, kes on tüübilt «I», ühe teenuse ümber ja järk-järgult muutuvad nad lähemale tüübile «T», ja kui õige juhtimine on korraldatud, võivad nad isegi saada «E». Esimene vastuväide siin on see, et sellises struktuuris on liigseid elemente. Miks on igas osakonnas vajalik testija, kui võib olla spetsiaalne testijate osakond? Millele ma vastan: liigsed kulud on sel juhul hind, et tulevikus kogu organisatsioon muutuks tüübiks «E». Sellises struktuuris omandab testija järk-järgult teadmisi võrkudest, arhitektuurist, projekteerimisest jne. Lõpuks on iga organisatsiooni liige täielikult teadlik kõikidest asjadest, mis organisatsioonis aset leiavad. Kui soovite teada, kuidas see skeem tööstuses töötab, lugege .
7. Shift-left auditors: auditeerimine varajastes etappides tsüklis. Turvameetmete järgimine silmade ees.
See, your actions do not pass, so to speak, the smell test. The people working for you are not stupid. If, as in the example above, they have been marking everything as minor/no impact for three years and no one noticed, then everyone knows perfectly well that the system doesn't work. Or another example — a change advisory board, where every Wednesday reports must be submitted. There’s a group of people working there (by the way, not very well paid) who, in theory, should know how the system works as a whole. And over the last five years, you’ve probably noticed that our systems are incredibly complex. And five or six people have to make decisions regarding changes they didn’t introduce and about which they know nothing.
Of course, such an approach doesn’t work. I have to get rid of these things because these people do not protect the system. The decision should be made by the team itself because the team must be responsible for it. Otherwise, a paradoxical situation arises where a manager, who has never written code in his life, tells the programmer how long the coding should take. In one company I worked with, there were seven different boards that reviewed each change, including an architecture board, product boards, etc. There was even a mandatory waiting period, although one employee told me that in ten years no one had ever rejected changes made by this person during that mandatory period.
Auditoore tuleb kutsuda enda juurde, mitte neist vabaneda. Rääkige neile, et kirjutate immutamatuid binaarseid konteinerite, mis jäävad pärast kõiki teste igaveseks muutumatuks. Selgitage neile, et teil on pipeline as code, ja selgitage, mida see tähendab. Näidake neile järgmist skeemi: immutamatud binaarsed failid ainult lugemiseks konteineris, mis läbib kõik haavatavuse testid; ja sinna ei puutu mitte ükski, mitte isegi süsteem, mis genereerib pipelini, kuna see luuakse ka dünaamiliselt. Mul on kliente, nagu Capital One, kes loovad Vaultiga midagi sarnast plokiahelale. Auditoorile ei pea näitama Chef'i 'retsepte', piisab, kui näidata plokiahelat, mis näitab, mis juhtus Jira pileti tootmises ja kes on selle eest vastutav.
Vastavalt , mille koostas 2018. aastal Sonatype, tehti 2017. aastal 87 miljardit nõudmist OSS-i allalaadimiseks.
Kahjud, mis on tulenenud haavatavustest, osutuvad erakordselt kõrgeks. Ja need numbrid, mida te praegu näete, ei sisalda alternatiivseid kulusid. Lühidalt DevSecOps'i kohta. Tahaksin kohe öelda, et mind ei huvita, kui hästi see nimi töötab. Asi on selles, et kuna DevOps'id olid väga edukad, tuleb proovida lisada sellele pipelini turvafunktsioonid.
Sellise järjestuse näide:
See ei ole soovitus teatud toodete osas, kuigi mulle kõik need meeldivad. Toodud näited on põhjusel, et näidata, et DevOps, mis on algselt rajatud tööstusorganisatsiooni paradigmale, võimaldab automatiseerida iga toote arenduse etappi.
Ja pole mingit põhjust, miks me ei võiks sama lähenemist turvalisusele rakendada.
Kokkuvõte
Lõpetuseks anname mõned nõuanded DevSecOps jaoks. On oluline kaasata audiitoreid teie süsteemide loomise protsessidesse ning investeerida aega nende haridusse. Audiitoritega tuleb teha tihedat koostööd. Järgmiseks tuleb nõudlikult võidelda valehäiretega. Isegi kallima haavatavuste skanneerimise tööriistaga saate lõpuks arendajates luua kahjulikke harjumusi, kui te ei tea, milline on signaali ja müra suhe. Arendajad võivad sündmustest üle koormatud olla ja nad hakkavad neid lihtsalt kustutama. Kui olete kuulnud Equifaxi juhtumist, siis just nii seal juhtus: kõrgeima taseme ohu signaal jäi tähelepanuta. Lisaks tuleb haavatavusi selgitada nii, et oleks selge, kuidas nad mõjutavad äri. Näiteks võib öelda, et see on sama haavatavus, mis Equifaxi loos. Turvalisuse haavatavusi tuleb käsitleda sama tõsiselt kui muid tarkvaraprobleeme, ehk neid tuleb integreerida DevOpsi üldprotsessi. Nendega tuleb töötada läbi Jira, Kanban jne. Arendajad ei tohiks mõelda, et selle töötlemisega tegeleb keegi teine — vastupidi, sellega peavad tegelema kõik. Lõpuks tuleb investeerida jõud, et inimesi koolitada.
Kasulikud lingid
Siin on mõned DevOops konverentsi ettekanded, mis võivad teile huvi pakkuda:
- Sergei Berdnikov, Artyom Kalichkin — Edu lugu ehk "Dev+DevOps+Ops" (, )
- Baruch Sadogursky, Leonid Igolnik — DevOps suurtes mastaapides: Kreeka tragöödia kolmes vaatuses (, )
- Aleksander Titov, Kirill Tolkačev —
- Timothy Lister —
Vaadake DevOops 2020 Moskvas — seal on palju huvitavat.
Allikas: habr.com
