Küsimus "kuidas DevOps-i rakendada" on olnud päevakorras juba mitu aastat, kuid häid materjale pole kuigi palju. Vahel satud sa mitte just kõige nutikamate konsultantide reklaamidest petta, kellele on oluline müüa vaid oma aega, olenemata sellest, kuidas. Sageli on need hägused, äärmiselt üldised sõnumid selle kohta, kuidas suured korporatsioonide laevad rändavad universumi avarustes. Tekib küsimus: kas sellest on meile midagi kasu? Lugupeetud autor, kas saaksite selgelt oma ideed loetellu panna?
Kõik see tuleneb sellest, et reaalse praktika ja ettevõtte kultuuri transformatsioonide mõistmise kohta on kogunenud mitte just palju teadmisi. Kultuuri muutmine on pikaajaline protsess, mille tulemused ei ilmne nädalate ega kuude jooksul. Me vajame kedagi, kes on piisavalt kogenud ja näinud, kuidas ettevõtteid on loodud ja hävinud aastaid.
John Willis — üks DevOpsi isadest. Johnil on palju aastaid kogemusi mitmesugustes ettevõtetes. Viimasel ajal on John hakanud märkama erilisi mustreid, mis on nende töödes kohal. Kasutades neid arhetüüpide, juhendab John ettevõtteid tõelise DevOps-muundamise teele. Rohkem nende arhetüüpidest leiate tõlkes tema ettekandest DevOops 2018 konverentsil.
Ettekandja kohta:
Rohkem kui 35 aastat IT-juhtimises, osales OpenCloud eelkäija loomises Canonicalis, töötas kümnes idufirmas, millest kaks müüdi Dellile ja Dockerile. Praegu on ta SJ Technologiesi DevOps ja Digitaalsete Praktikate asepresident.
Edasi — jutustus Johnilt.
Minu nimi on John Willis ja mind on kõige lihtsam leida Twitteris, . Sama hüüdnimi on mul ka Gmailis ja GitHubis. Samuti võite leida videoklippe minu ettekannetest ja nende esitlusi.
Mul on palju kohtumisi erinevate suurte ettevõtete CIO-dega. Nad kurdavad tihti, et ei saa aru, mis on DevOps, ja kõik, kes püüavad seda neile selgitada, räägivad millestki oma. Teine sagedane kaebus on — DevOps ei toimi, kuigi näiliselt järgivad direktorid kõike, nagu neile selgitati. Räägime suurtest ettevõtetest, millel on üle saja aasta ajalugu. Suheldes nendega, jõudsin järeldusele, et paljudele probleemidele sobivad kõige paremini mitte kõrgtehnoloogilised lahendused, vaid suhteliselt madalatehnoloogilised lahendused. Nädalate viisi vestlesin lihtsalt erinevate osakondade inimestega. See, mida te näete postituse kõige esimesel pildil — see on minu viimane projekt, tuba nägi pärast kolme päeva tööd välja selline.
Mis on DevOps?
Tõepoolest, kui küsida 10 erinevalt inimeselt, saavad nad 10 erinevat vastust. Kuid huvitaval kombel on kõik need kümme vastust õiged. Valet vastust siin ei ole. Olen tegelenud DevOpsiga üsna süvitsi, umbes 10 aastat, ja olin esimene ameeriklane esimesel DevOpsDayl. Ma ei ütle, et olen kõigist, kes tegelevad DevOpsiga, targem, kuid kahtlemata ei ole kedagi, kes oleks sellele sama palju aega pühendanud. Usun, et DevOps tekib siis, kui kohtuvad inimkapital ja tehnoloogia. Tihti unustame inimlikud mõõtmed, kuigi räägime palju igasugustest kultuuridest.
Praegu on meil palju andmeid, viis aastat akadeemilisi uuringuid ja teooriate kontrollimine on tööstuslikult seadistatud. Need uuringud ütlevad meile järgmist: kui organisatsioonikultuuris ühendada teatud käitumismustreid, on võimalik saavutada 2000-kordne kiirus. Sellele kiirusel vastab sama suurusjärgu paranemine stabiilsuses. See on kvantitatiivne mõõde sellest, millist eeliseid DevOps võib igale ettevõttele tuua. Paar aastat tagasi rääkisin DevOpsist ühe Fortune 5000 ettevõtte tegevjuhile. Kui ma valmistasin esitlust, olin väga närvis, sest pidin viie minutiga edastama oma pikaajalise kogemuse.
Viimaks esitasin järgmist DevOpsi määratlust: see on praktika ja mustrite komplekt, mis võimaldab inimkapitali muuta kõrge efektiivsusega organisatsiooniliseks kapitaliks. Näide — kuidas Toyota on viimased 50 või 60 aastat töötanud.
(Siin ja edaspidi tuuakse sellised skeemid mitte viidatud materjalina, vaid illustreerimiseks. Nende sisu on igas uues ettevõttes erinev. Siiski võib pilti eraldi vaadata ja suurendada
Üks edukamaid selliseid praktikaid on väärtusvoogude kaardistamine. Sel teemal on kirjutatud mitmeid häid raamatuid, mille üheks edukamaks autoriks on Karen Martin. Kuid möödunud aasta jooksul olen jõudnud järeldusele, et isegi see lähenemine on liiga kõrgetehnoloogiline. Sellel on kindlasti palju voorusi, millest olen palju kasu saanud. Kuid kui tegevjuht küsib sinult, miks tema ettevõte ei saa uutele radadele minna, on väärtusvoogude kaardistamisest veel vara rääkida. On palju oluliselt fundamentaalsemaid küsimusi, millele tuleb eelnevalt vastused leida.
Minu arvates on paljude kolleegide viga see, et nad annavad ettevõttele viiepunktilise juhise ning seejärel tulevad kuue kuu pärast tagasi ja vaatavad, mis juhtus. Isegi hea skeemi, näiteks väärtuste voo kaardistamise puhul on olemas, ütleme nii, pimedaid alasid. Pärast sadu intervjuusid erinevate ettevõtete direktoritega olen välja töötanud teatud mustri, mis võimaldab probleemi osadeks jagada, ja nüüd arutame iga nende osa järjekorras. Enne mistahes tehnoloogiliste lahenduste rakendamist kasutan seda mustrit, ja tulemusena on kõik mu seinad skeemidega kaetud. Hiljuti töötasin ühe investeerimisfondiga, ja lõpuks oli mul 100–150 sellist skeemi.
Halb kultuur sööb häid lähenemisviise hommikuks
Peamine mõte on see: ükski Lean, Agile, SAFE ega DevOps ei aita, kui organisatsiooni kultuur on halb. See on nagu sukeldumine sügavusse ilma hingamisaparaadita või opereerimine ilma röntgenpildita. Teisisõnu, ümber sõnastades Druckerit ja Demingi: halb organisatsioonikultuur neelab alla iga hea süsteemi ega köhi välja.
Peamine probleem lahendamiseks tuleb võtta järgmised sammud:
- Tehke kogu töö nähtavaks: töö peab olema nähtav. Mitte selles mõttes, et see peab ilmuma mingile ekraanile, vaid et see peab olema jälgitav.
- Konsolideerige töö juhtimissüsteemid: töö juhtimissüsteemide konsolideerimine on vajalik. Probleemi "klanniliste" teadmiste ja institutsionaalsete teadmiste osas on 9 juhul 10 nõrk koht inimesed. Raamatus oli probleem üheainsa inimese, Brenti, tõttu, kes sai projekti viibima kolm aastat. Ja selliseid "Brente" ma kohtan igal pool. Nende kitsaskohade lahendamiseks kasutan meie nimekirjas järgmisi kahte punkti.
- Piirangute Teooria Metoodika: piirangute teooria.
- Koostöö nipid: koostöö hack'id.
- Toyota Kata (): Toyota Kata kohta ma palju rääkima ei hakka. Kui huvitav, siis minu GitHubis peaaegu iga teema kohta.
- Turule orienteeritud organisatsioon: turule suunatud organisatsioon.
- Varajased audiitorid: audit varases etapis.
Oma töö alustamine organisatsiooniga on väga lihtne: lähen ettevõttesse ja räägin töötajatega. Nagu näha, ei ole siin mingeid kõrgtehnoloogilisi meetodeid. Kõik, mis on vajalik, on midagi, millega kirjutada. Kogun mitmed meeskonnad samas ruumis ja analüüsin seda, mida nad mulle ütlevad, oma seitsme arhetüübi vaatenurgast. Seejärel annan neile ise markerid ja palun neil kirja panna kõik see, mida nad seni valjusti rääkisid. Tavaliselt on sellistel kohtumistel üks inimene, kes kõik üles kirjutab, ja parimal juhul suudab ta fikseerida 10% arutelust. Minu meetodiga õnnestub seda protsenti tõsta umbes 40%ni.
(Erakordselt seda illustratsiooni on võimalik )
Minu lähenemine põhineb William Schneideri tööl (William Schneider, ). Selle lähenemise aluseks on mõte, et iga organisatsiooni saab jagada neljaks ruuduks. See skeem on tavaliselt minu töö tulemus mitmete teiste skeemide seas, mis tekivad organisatsiooni analüüsi käigus. Oletame, et meil on organisatsioon, millel on kõrge kontrollitase, kuid madal pädevus. See on äärmiselt ebasoovitav variant: kõik käivad sirgelt, kuid keegi ei tea, mida teha.
Veidi parem variant on kõrge kontrolli ja pädevuse tase. Kui selline ettevõte on kasumlik, siis võib-olla DevOps ei olegi vajalik. Kõige huvitavam on töötada ettevõttega, millel on kõrge kontrollitase, madal pädevus ja koostöö, kuid samas kõrge kultuuri(täiendamine) tase. See tähendab, et ettevõttes on palju inimesi, kellel on hea meel seal töötada, ning töötajate voolavus on madal.
(Erakordselt seda illustratsiooni on võimalik )
Minu arvates takistavad rangelt määratletud soovitustega meetodid lõppkokkuvõttes tõe saavutamist. Eriti kehtib see väärtuste voogude kaardistamise kohta, kus on palju reegleid teabe struktureerimise osas. Varases faasis, millest ma nüüd räägin, pole neid reegleid kellelegi vaja. Kui inimene markeriga käes kirjeldab tahvlil ettevõtte tegelikku olukorda, on see parim viis aru saada, kuidas asjad on. Selline teave ei jõua direktoriteni. Sel hetkel on rumal inimest katkestada ja öelda, et ta on valesti joonistanud mingit noolt. Sellel etapil on parem järgida lihtsaid reegleid, näiteks: mitmetasandilise abstraktsiooni võib luua lihtsalt kasutades erineva värvusega markereid.
Kordan, ei mingit kõrgtehnoloogiat. Must marker kujutab objektiivset reaalsust, kuidas kõik töötab. Punase markeriga märgivad inimesed, mis neile olemasolevas olukorras ei meeldi. Oluline on, et seda kirjutavad nemad, mitte mina. Kui läheme pärast koosolekut IT-direktori juurde, ei paku ma välja nimekirja 10 asjast, mida tuleb parandada. Püüan leida seoseid selle vahel, mida ettevõtte inimesed räägivad, ja olemasolevate, tõestatud mustrite vahel. Lõpuks, sinise markeriga pakutakse välja võimalikke lahendusi probleemile.
(Erakordselt seda illustratsiooni on võimalik )
Selle lähenemise näidis on praegu üleval. Selle aasta alguses töötasin ühe pangaga. Seal olid julgeolekuteenistuse töötajad veendunud, et nad ei tohi osaleda nõuete ja projekteerimise ülevaatuses (design and requirement reviews).
(Erakordselt seda illustratsiooni on võimalik )
Siis rääkisime teiste osakondade inimestega ja selgus, et umbes 8 aastat tagasi väljasaatud tarkvaraarendajad pani julgeolekutöötajad välja, sest need aeglustasid tööd. Ja siis sellest kujunes välja keeld, mida võeti kui iseenesestmõistetavust. Kuigi tegelikult ei olnud mingit keelt.
Meie kohtumine kulges äärmiselt segaselt: umbes kolme tunni jooksul ei suutnud viis erinevat tiimi mulle selgitada, mis toimub koodi ja kokkupakkimise vahel. Ning see näib olevat kõige lihtsam asi. Enamik DevOps konsultante eeldavad, et see on juba kõigile teada.
Siis inimene, kes vastutas IT halduse eest, kes oli nelja tunni jooksul vaikinud, äkki ärkas ellu, kui jõudsime tema teema juurde, ja hoidis meid veel pikalt tegevuses. Lõpuks küsisin temalt, mida ta meie kohtumisest arvab, ja ma ei unusta kunagi tema vastust. Ta ütles: "Varem arvasin, et meie pangas on ainult kaks tarkvara tarnimise viisi, aga nüüd tean, et neid on lausa viis, millest kolmest ma isegi ei teadnud."
(Erakordselt seda illustratsiooni on võimalik )
Viimane koosolek selles pangas toimus meeskonnaga, mis tegeleb investeerimistarkvaraga. Just nemad selgitasid, et markeriga skeemide joonistamine paberile on parem kui tahvlile, ja isegi parem kui nutitahvlile.
Fotod, mida näete, on sellest, kuidas hotellis konverentsisaal neljandal kohtumise päeval välja nägi. Ja neid skeeme kasutasime mustrite, st. arhetüüpide leidmiseks.
Nii et, esitan küsimusi töötajatele, nad kirjutavad vastuseid kolme värvi markeritega (must, punane ja sinine). Analüüsin nende vastuseid arhetüüpide osas. Nüüd arutame kõiki arhetüüpe järjekorras.
1. Make All Work Visible: Teha kogu töö nähtavaks
Enamikus ettevõtetes, mida ma tunnen, on väga kõrge määr teadmata tööst. Näiteks, kui üks töötaja palub teiselt midagi teha. Suurtes organisatsioonides võib olla kuni 60% ettenägematut tööd. Ja kuni 40% tööst ei ole mingil moel dokumenteeritud. Kui see oleks Boeing, siis ma ei tõusnud enam kunagi nende lennukiga. Kui ainult pool tööst on dokumenteeritud, ei ole teada, kas see töö tehakse õigesti või mitte. Kõik ülejäänud meetodid osutuvad kasutuks — pole mingit mõtet proovida midagi automatiseerida, sest tuntud 50% võib olla just kõige koordineeritum ja selgem töö osa, mille automatiseerimine suuri tulemusi ei too, samas kui kõige hullem on just nähtamatus pooles. Ilma dokumentatsioonita on võimatu leida igasuguseid trikke ja peidetud tööd, ei suudeta kindlaks teha kitsaskohti, neid samu „Brente”, millest ma juba rääkisin. On suurepärane raamat Dominica De Grandiselt . See toob välja viis erinevat «aja lekkimist» (aeg vargad):
- Liialt palju tööd protsessis (WIP)
- Tundmatud sõltuvused
- Ettenägematu töö
- Konflikteerivad prioriteedid
- Hooletusse 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 nähtav on vaid 50% andmetest. Dominika poolt pakutud meetodeid saab rakendada ainult juhul, kui täpsus on üle 90%. Räägin olukordadest, kus ülemus annab alluvale 15-minutilise ülesande, aga see võtab temalt kolm päeva; kuid ülemus ei tea tegelikult, et see alluv sõltub veel neljast või viiest teisest inimesest.
Phoenix Project — on suurepärane lugu projektist, mis oli kolm aastat hiljaks jäänud. Üks peategelastest seisab silmitsi vallandamise ohuga, kui ta kohtub teise isikuga, keda esitatakse kui omamoodi Sokratest. See aitab selgitada, mis õigupoolest valesti läks. Selgub, et ettevõttes on üks süsteemihaldur nimega Brent, ja kogu töö läbib mingil moel tema. Ühel koosolekul küsib üks alluvatest: miks iga poole tunni ülesanne võtab nädala? Vastuseks tuleb väga lihtsustatud seletus järjekordade teooriast ja Littleri seadusest, ning selles seletuses selgub, et 90% koormuse juures nõuab iga töö tund 9 tundi. Iga ülesanne tuleb edastada seitsmele teisele, mistõttu see tund muutub 63 tunniks, 7 korda 9. Ma ütlen seda selleks, et öelda, et Littleri seaduse või mõne keerulisema järjekordade teooria kasutamiseks on vähemalt vaja andmeid.
Seega, kui ma räägin nähtavusest, ei tähenda see, et kõik peab olema ekraanil, vaid et vähemalt tuleb andmed olemas olla. Kui need on olemas, selgub sageli, et on väga suur hulk planeerimata tööd, mis mingil põhjusel suunatakse Brenti, kuigi selleks ei ole mingit vajadust. Ja Brent on suurepärane tüüp, ta ei ütle kunagi "ei", kuid ta ei räägi kedagi selles, kuidas ta oma tööd teeb.
Kui töö on nähtav, saab andmeid hoolikalt klassifitseerida (just sellega tegeleb Dominika pildil), saab rakendada viie aja lekkimise abstraktsiooni ja automatiseerida.
2. Consolidate Work Management Systems: Ülesannete haldamine
Arhetüübid, millest ma räägin, kujutavad endast mingisugust püramiidi. Kui esimene on õigesti täidetud, siis teine on omamoodi lisand. Paljud neist ei toimi start-upide jaoks, neid tuleb silmas pidada suurte ettevõtete puhul, näiteks Fortune 5000 nimekirjas olevate. Viimases ettevõttes, kus ma töötasin, oli 10 tõrke jälgimise süsteemi (ticketing system). Ühes meeskonnas oli Remedy, teine kirjutas oma süsteemi, kolmas kasutas Jira’t, keegi suisa piirdus e-posti kasutamisega. Täpselt sama probleem tekib siis, kui ettevõttes on 30 erinevat torujuhet, aga mul ei ole aega arutada kõiki selliseid juhtumeid.
Räägin inimestega, kuidas pileteid täpselt luuakse, mis nendega edasi toimub ja kuidas neid mööda käiakse. Kõige huvitavam on see, et inimesed meie koosolekutel räägivad üsna siiralt. Küsisin, kui palju inimesi määravad piletitele „väike / mitte mingit mõju”, kuigi neid oleks pidanud tähistama kui „suurt mõju”. Selgus, et nii teeb peaaegu igaüks. Ma ei tegele kaebamist, vaid püüan mitte inimesi tuvastada. Kui keegi tunnistab midagi siiralt, ei avalda ma nende nime. Kuid kui praktiliselt kõik käivad süsteemist mööda, tähendab see, et kogu turvalisus on põhimõtteliselt dekoratsioon. Seetõttu ei saa selles süsteemis olevatest andmetest järjepidevusi teha.
Probleemi lahendamiseks piletitega on vajalik valida üks peamine süsteem. Kui kasutate Jira, siis las jääb ainult Jira. Kui on mõni alternatiiv, siis las jääb ainult see. Point on selles, et pileteid tuleks vaadata kui veel ühte arendusprotsessi etappi. Igal tegevusel peab olema pilet, mis peab läbi töötama arendusetapi. Piletid saadetakse meeskonnale, kes paneb need storyboard'ile ja kannab seejärel vastutust nende eest.
See puudutab kõiki osakondi, sealhulgas infrastruktuuri ja operatiivset. Sellisel juhul on võimalik koostada vähemalt mingisugune usutav ülevaade seisust. Kui see protsess on paika pandud, selgub äkitselt, et on lihtne kindlaks teha, kes vastutab iga rakenduse eest. Sest nüüd saame 50% asemel 98% uutest teenustest. Kui see põhiprotsess töötab, tõuseb täpsus kogu süsteemis.
Teenuste toru
See puudutab ainult suuri korporatsioone. Kui teil on uus ettevõte uues valdkonnas — rullige varrukad üles ja töötage oma Travis CI või CircleCI-ga. Mis puutub Fortune 5000 ettevõtetesse, siis on rääkida üks juhtum, mis juhtus pangas, kus ma töötasin. Google'i inimesed tulid neile külla ja näitasid diagramme vanade IBM-i süsteemide kohta. Google'i kutid küsisid segaduses, et kus on sellele põhikood? Pole mingit põhikoode, pole isegi kasutajaliidest. See on reaalsus, millega suured organisatsioonid peavad toime tulema: 40-aastased pangasalvestused vanal peamise raamistiku peal. Üks minu klientidest kasutab Kubernetes'i konteinerite ning Circuit Breaker'i mustrite ja Chaos Monkey'ga, kõik see KeyBanki rakenduse jaoks. Kuid need konteinerid ühenduvad lõpuks COBOL-i rakendusega.
Google'i meeskond oli veendunud, et lahendavad kõik minu kliendi probleemid, kuid seejärel hakkasid küsima: mis on IBM datapipe? Vastatakse: see on konnektor. Millele see ühendub? Sperry süsteemiga. Ja see on mis? Ja nii edasi. Esmapilgul tundub, et siin pole mingit DevOps'i. Kuid tegelikult on see võimalik. On olemas tarne süsteeme, mis võimaldavad edastada töövooge meeskondadele, kes tegelevad tarnimisega.
3. piirangute teooria: Theory of Constraints
Käime kolmanda arhetüübi juurde: institutsionaalne / 'rahvuslik' teadmine. Üldiselt on igas organisatsioonis mõned inimesed, kes teavad kõike ja kellel on kõikide üle kontroll. Need on need, kes on organisatsioonis kõige kauem töötanud ja kes tunnevad kõiki kõrvalteid.
Kui see diagrammil välja tuleb, rõhutan neid inimesi markeriga: näiteks selgub, et mõni inimene nimega Lu on kohal igal koosolekul. Ja mulle on selge: see on kohalik Brent. Kui tehnoloogia direktor valib minu ja spordijalatsites T-särgis ja ülikonnas oleva kutti IBM-ist vahel, valitakse mind, sest ma suudan direktorile rääkida asjadest, millest teine tüüp talle ei räägi ja mis võivad olla direktorile ebamugavad. Ma ütlen neile, et nende ettevõttes on kitsaskoht, keegi nimega Fred ja keegi nimega Lu. See kitsaskoht tuleb avada, nende teadmist tuleb neilt mingil viisil kätte saada.
Ette võib sellist probleemi lahendada, näiteks kasutades Slacki. Värske juht küsib: miks? Tüüpiliselt vastavad DevOps konsultandid sellistes olukordades: sest kõik teevad nii. Kui juht on tõeliselt nutikas, ütleb ta: ja mis siis? Siis lõppeb dialoog. Ja ma panen sellele vastuseks: sest ettevõttes on neli kitsaskohta, Fred, Lou, Suzy ja Jane. Selleks, et nende teadmised oleksid institutsionaliseeritud, on esmalt vajalik Slacki kasutusele võtta. Kõik teie wiked on puhas jama, kuna keegi ei tea nende olemasolust. Kui inseneride meeskond tegeleb välise ja sisemise arendusega, peaks kõik teadma, et nad võivad esitada küsimusi kas välise arenduse meeskonnale või infrastruktuuri meeskonnale. Sel hetkel on tõenäoliselt Lou'l või Fredil aega, et wikisse sisse minna. Ja siis võib Slackis keegi küsida, miks näiteks samm 5 ei toimi. Siis Lou või Fred parandavad juhendi wikis. Kui see protsess korda saada, siis palju muud loksub kohale.
Minu põhiteema on see: enne kui soovitada kõrgtehnoloogilisi lahendusi, on oluline kõigepealt rajada neile kindel alus, milleks võivad olla just kirjeldatud madaltehnoloogilised lahendused. Kui aga alustada kõrgtehnoloogiatest ja mitte selgitada, miks need on vajalikud, ei lõppe see tavaliselt millegagi heaga. Üks meie klientidest kasutab Azure ML, mis on väga odav ja lihtne lahendus. Umbes 30% küsimustest sai juba vastuse iseõppiv masina abil. Ja selle lõi operaatorid, kes ei olnud seotud andmete teaduse, statistika ega matemaatikaga. See on üsna näitlik. Sellise lahenduse hind on minimaalne.
4. Koostöö häkid: Koostöö häkid
Neljas arhetüüp seisneb isolatsiooni vastu võitlemises. Enamik inimesi teab seda juba: isolatsioon toob kaasa vaenu. Kui iga osakond on oma korrusel ja inimesed ei puutu omavahel kokku muud moodi kui liftis, siis vaen nende vahel tekib väga lihtsalt. Kui aga inimesed on ühes ruumis koos, kaob see kohe. Kui keegi esitab mingit üldist süüdistust, näiteks et see ja see liides kunagi ei tööta — ei ole midagi lihtsamat, kui sellist süüdistust dekonstrueerida. Liidest kirjutanud programmeerijatele piisab, kui hakata esitama konkreetseid küsimusi, ja peagi selgub, et näiteks kasutaja kasutas lihtsalt tööriista valesti.
On palju võimalusi isolatsioonist üle saada. Mind paluti kord Austraalias ühte panka nõustada, kuid ma keelduin, kuna mul on kaks last ja abikaasa. Kõik, millega ma aidata sain, oli soovitada neile graafilise jutustamise meetodit. See on asi, mis on tõestatud efektiivne. Teine huvitav lähenemine on lean coffee formaadi kohtumised. Suures organisatsioonis on see suurepärane võimalus teadmiste levitamiseks. Lisaks sellele on võimalik korraldada siseseid devops-päevi, hackathone jne.
5. Coaching Kata
Kuna ma juba alguses hoiatasin, et ma täna sellest ei räägi. Kui huvi on, siis võite vaadata .
Samuti on olemas hea ettekande teema kohta Mike Rotherilt:
6. Turule orienteeritud: turule orienteeritud organisatsioon
Siin on erinevad probleemid. Näiteks inimesed 'I', inimesed 'T' ja inimesed 'E'. Inimesed 'I' on need, kes tegelevad ainult ühega. Tüüpiliselt eksisteerivad nad just nendes organisatsioonides, kus osakonnad on isoleeritud. 'T' tähendab, et inimene tunneb hästi ühte asja, kuid oskab ka mõnes muus asjas hakkama saada. 'E' või isegi 'kamm' on siis, kui inimesel on palju oskusi.
Siin kehtib Conway seadus (), mis mida saab maksimaalselt lihtsustatud kujul väljendada nii: kui kolm meeskonda tegelevad kompilaatoriga, siis lõpuks saadakse kolm osast koosnev kompilaator. Seetõttu, kui organisatsioonis on kõrge isoleerituse tase, on isegi Kubernetes, Circuit breaker, API extensibility ja muud moes asjad selles organisatsioonis korraldatud just nii, nagu on korraldatud kogu organisatsioon. Täpselt Conwy järgi ning vastu soovidele, noored geekid.
Selle probleemi lahendust on palju kordi kirjeldatud. Näiteks on olemas organisatsioonilised arhetüübid, mille on kirjeldanud Fernando Fernandez. See probleemne arhitektuur, millest ma just rääkisin, isoleerituse osas – see on funktsionaalselt suunatud arhitektuur. Teine tüüp – halvem, on maatriksi arhitektuur, seal on kahe teise segu. Kolmas – on see, mida täheldatakse enamikus idufirmades, ja suured ettevõtted püüavad samuti sellele tüübile vastata. See on turule orienteeritud organisatsioon. Siin optimeeritakse, et tagada kõige kiirem reageerimine klientide päringutele. Mõnikord nimetatakse seda tasandiliseks organisatsiooniks.
Seda struktuuri kirjeldavad paljud erinevalt, mulle meeldib sõnastus build/run teams, Amazoni puhul nimetatakse seda kaks pitsameeskonda. Selles struktuuris koondatakse kõik "I" tüüpi inimesed ümber ühe teenuse ning järk-järgult muutuvad nad sarnasemaks "T" tüübiga ja kui juhtimine on korralik, võivad nad isegi "E" tüübiks muutuda. Esimene vastuväide on see, et sellises struktuuris on üleliigseid elemente. Miks on igas osakonnas testija, kui võiks olla spetsiaalne testijate osakond? Mulle vastates: üleliigsed kulud on antud juhul hind, et tulevikus saaks kogu organisatsioon olla "E" tüüpi. Sellises struktuuris õpib testija järk-järgult tundma võrke, arhitektuuri, projekti koostamist jne. Lõpuks on iga organisatsiooni liige täielikult teadlik sellest, mis organisatsioonis toimub. Kui soovite teada, kuidas see skeem tööstuses töötab, lugege .
7. Shift-left auditors: audit varajastes etappides tsükli jooksul. Turvaprotseduuride järgimine silma all
See on siis, kui teie tegevused ei läbinud, nii-öelda, lõhna testimist. Inimesed, kes teie eest töötavad, ei ole lollid. Kui nad, nagu eespool näidatud, kõikjal esitasid väikese/mitte mingit mõju, on see kestnud kolm aastat ja keegi ei märganud midagi, siis kõik teavad, et süsteem ei tööta. Või teine näide — muudatusettepanekute komitee, kuhu igal, ütleme, kolmapäeval tuleb esitada aruanded. Seal töötab rühm inimesi (muide, mitte liiga hästi tasustatud), kes teoreetiliselt peaksid teadma, kuidas süsteem tervikuna töötab. Ja viimase viie aasta jooksul olete ilmselt märganud, et meie süsteemid on uskumatult keerulised. Ja viis-kuus inimene peaks võtma otsuse muudatuse kohta, mida nad ei ole teinud ja millest nad ei tea midagi.
Loomulikult selline lähenemine ei toimi. Pean nende asjadega tegelema, kuna need inimesed ei kaitse süsteemi. Otsuse peaks tegema meeskond ise, kuna meeskond peab vastutama. Vastasel juhul tekib paradoksaalne olukord, kus juht, kes pole kunagi koodi kirjutanud, ütleb arendajale, kui kaua koodi kirjutamine peaks aega võtma. Ühes firmas, kus ma töötasin, oli 7 erinevat nõukogu, mis vaatas iga muudatuse üle, sealhulgas arhitektuuri- ja tootenõukogu jne. Oli isegi kohustuslik ooteaeg, kuigi üks töötaja ütles mulle, et kümne aasta jooksul ei ole keegi kordagi selle kohustusliku perioodi jooksul selle inimese tekitatud muudatusi tagasi lükanud.
Auditoore tuleks kutsuda endale, mitte neist vabaneda. Rääkige neile, et kirjutate muutumatuid binaarkonteinereid, mis, kui kõik testid on läbitud, jäävad igavesti muutumatuks. Rääkige neile, et teil on pipeline as code, ja selgitage, mida see tähendab. Näidake neile järgmist skeemi: muutumatu binaar, mida saab ainult lugeda konteineris, mis läbib kõik haavatavuste testid; ja edasi ei puutu mitte ainult keegi sellesse, vaid isegi süsteemi, mis loob pipeline'i, ei puututa, kuna see luuakse samuti dünaamiliselt. Mul on kliente, nagu Capital One, kes kasutavad Vaulti, et luua midagi nagu blockchain. Auditoorile ei ole vaja näidata Chef'i „retsepte“, piisab, kui näidata blockchain'i, millest on selge, mis juhtus Jira tiketi tootmises ja kes on selle eest vastutav.
Vastavalt , mille Sonatype koostas 2018. aastal, oli 2017. aastal 87 miljardit OSS-i allalaadimist.
Turud, mis tulenevad haavatavustest, osutuvad ülemäära kõrgeks. Sellesse numbrisse, mida te praegu üleval näete, ei ole arvestatud alternatiivseid kulusid. Lühidalt DevSecOps'ist. Tahan kohe ära öelda, et mind ei huvita, kui hästi see nimi toimib. Oluline on, et kuna DevOps on olnud üsna edukas, tuleks proovida lisada turvalisus sellele töövoole.
Näide sellisest järjestusest:
See ei ole soovitus konkreetsete toodete osas, kuigi mulle need kõik meeldivad. Too need välja näitena, et näidata, et DevOps, mis algselt põhines tööstusorganisatsiooni paradigmal, võimaldab automatiseerida iga toote arenduse etapi.
Ja ei ole mingit põhjust, miks me ei võiks sama lähenemist turvalisusele rakendada.
Kokkuvõte
Lõpetuseks jagan mõned nõuanded DevSecOpsi jaoks. Oluline on kaasata audiitorid teie süsteemide loomise protsessi ja investeerida aega nende haridusse. Koostöö audiitoritega on vajalik. Järgmine punkt on vajadus kartmatult tegeleda valehäiretega. Isegi kõige kallima haavatavusskaneerimise tööriista kasutamine võib lõpuks tekitada arendajates ohtlikke harjumusi, kui te ei tea, milline on signaali ja müra suhe. Arendajad satuvad üleküllusesse sündmustest ning hakkavad neid lihtsalt kustutama. Kui olete kuulnud Equifaxi loos toimunust, siis just sellega see juhtus — seal läks kõrgeima taseme ohtu signaal tähelepanuta. Samuti tuleb haavatavusi selgitada viisil, mis näitab, kuidas need äri mõjutavad. Näiteks võib öelda, et see on sama haavatavus, mis esines Equifaxi loos. Turvalisuse haavatavust tuleb käsitleda sama tõsiselt kui muid tarkvaraprobleeme, seega tuleks need lõimida DevOpsi üldprotsessi. Nende kallal tuleb töötada läbi Jira, Kanbani jne. Arendajad ei peaks arvama, et nendega tegeleb keegi teine — pigem peavad nad olema kõik selle kaasatud. Lõpuks on oluline investeerida aega inimeste koolitamisse.
Kasulikud lingid
Siin on mõned DevOops konverentsilt pärit ettekanded, mis võivad teile huvi pakkuda:
- Sergei Berdnikov, Artyom Kalichkin — Edu lugu ehk „Dev+DevOps+Ops“ (, )
- Baruch Sadogursky, Leonid Igolnik — DevOps mastaabis: Kreeka tragöödia kolme aktiga (, )
- Aleksandr Titov, Kirill Tolkachev —
- Timothy Lister —
Vaata DevOps 2020 Moskvas — seal on samuti palju huvitavat.
Allikas: habr.com
