Spurningin um „hvernig á að innleiða DevOps“ hefur verið til umræðu í mörg ár, en það er ekki mikið af góðu efni til. Stundum verður maður fórnarlamb ofsókna frá óreyndum ráðgjöfum sem þurfa að selja tíma sinn, sama hvernig. Stundum eru það óljósar, of almennar fullyrðingar um hvernig risafyrirtæki sigla um víðáttumikið geiminn. Spurningin vaknar: hvað höfum við í þessu? Kæri höfundur, gætirðu skýrt orðað hugmyndir þínar í lista?
Allt þetta stafar af þeirri staðreynd að lítil reynsla og skilningur er til staðar á afleiðingum menningarbreytinga fyrirtækja. Menningarbreytingar eru langtímaferli og árangurinn kemur ekki í ljós á einni viku eða mánuði. Við þurfum einhvern með næga reynslu, einhvern sem hefur séð fyrirtæki rísa og falla í gegnum árin.
John Willis John er einn af feðrum DevOps. John hefur áratuga reynslu af því að vinna með fjölmörgum fyrirtækjum. Undanfarið hefur hann byrjað að taka eftir sérstökum mynstrum sem koma fram í vinnu hans með hverju og einu þeirra. Með því að nota þessar frumgerðir leiðbeinir John fyrirtækjum á réttri leið til umbreytingar í DevOps. Frekari upplýsingar um þessar frumgerðir má finna í þýðingu fyrirlesturs hans frá DevOops ráðstefnunni 2018.
Um fyrirlesarann:
Hann hefur yfir 35 ára reynslu í upplýsingatæknistjórnun, hjálpaði til við að skapa forvera OpenCloud hjá Canonical og vann að 10 sprotafyrirtækjum, þar á meðal tveimur sem hann seldi til Dell og Docker. Hann er nú varaforseti DevOps og stafrænnar starfshátta hjá SJ Technologies.
Eftirfarandi er sagan sögð frá sjónarhóli Jóhannesar.
Ég heiti John Willis og ég er best að finna á Twitter. Ég er með sama gælunafnið á Gmail og GitHub. Þú getur fundið myndbandsupptökur af skýrslum mínum og kynningum fyrir þau.
Ég á marga fundi með upplýsingastjórum hjá ýmsum stórfyrirtækjum. Þeir kvarta oft yfir því að þeir skilji ekki DevOps og allir sem reyna að útskýra það fyrir þeim eru að tala um eitthvað allt annað. Önnur algeng kvörtun er að DevOps virki ekki, jafnvel þótt stjórnendurnir virðast gera allt eins og útskýrt er. Þetta eru stór fyrirtæki sem eru yfir hundrað ára gömul. Eftir að hafa talað við þá komst ég að þeirri niðurstöðu að mörg vandamál eru best leyst ekki með hátæknilegum lausnum, heldur með tiltölulega lágtæknilegum lausnum. Ég eyddi vikum í að tala einfaldlega við fólk frá mismunandi deildum. Það sem þið sjáið á allra fyrstu myndinni í þessari færslu er nýjasta verkefnið mitt; svona leit herbergið út eftir þriggja daga vinnu.
Hvað er DevOps?
Vissulega, ef þú spyrð 10 mismunandi einstaklinga, þá munu þeir gefa 10 mismunandi svör. En hér er það áhugaverða: öll 10 svörin verða rétt. Það er ekkert rangt svar. Ég hef verið mjög virkur í DevOps, í um 10 ár, og var fyrsti Bandaríkjamaðurinn til að sækja fyrsta DevOps daginn. Ég myndi ekki segja að ég sé klárari en allir aðrir í DevOps, en ég efast um að nokkur hafi lagt jafn mikla vinnu í það. Ég tel að DevOps komi fram þegar mannauður og tækni koma saman. Við gleymum oft mannlegu víddinni, jafnvel þótt við tölum mikið um alls konar menningarheima.
Við höfum nú aðgang að miklum gögnum, fimm ára fræðilegum rannsóknum og kenningum sem hafa verið prófaðar á iðnaðarstigi. Þessar rannsóknir segja okkur eftirfarandi: ef ákveðin hegðunarmynstur eru sameinuð í fyrirtækjamenningu er hægt að ná 2000-faldri hröðun. Þessi hröðun samsvarar svipaðri framför í sjálfbærni. Þetta er megindleg mælikvarði á þann ávinning sem DevOps getur fært hvaða fyrirtæki sem er. Fyrir nokkrum árum var ég að kynna DevOps fyrir forstjóra Fortune 5000 fyrirtækis. Þegar ég var að undirbúa kynninguna var ég afar taugaóstyrkur því ég þurfti að draga saman áralanga reynslu mína á fimm mínútum.
Að lokum gaf ég eftirfarandi skilgreining á DevOpsÞetta er safn starfshátta og mynstra sem gera kleift að umbreyta mannauði í afkastamikla skipulagsauða. Dæmi um þetta er hvernig Toyota hefur starfað síðustu 50 eða 60 árin.
(Héðan í frá eru slíkar skýringarmyndir ekki ætlaðar sem viðmiðunarefni heldur sem dæmi. Efni þeirra verður mismunandi eftir nýju fyrirtæki. Hins vegar er hægt að skoða myndina sérstaklega og stækka hana.)
Ein af þessum farsælustu aðferðum er gildi straum kortlagningÞað eru til nokkrar góðar bækur um þetta efni, sú farsælasta er eftir Karen Martin. En á síðasta ári hef ég komist að þeirri niðurstöðu að jafnvel þessi aðferð sé of hátæknileg. Hún hefur vissulega marga kosti og ég hef notað hana mikið. En þegar forstjóri spyr þig hvers vegna fyrirtæki þeirra geti ekki fært sig yfir í nýja aðferð, þá er of snemmt að tala um virðisstraumakortlagningu. Það eru margar fleiri grundvallarspurningar sem þarf að svara fyrst.
Ég held að margir samstarfsmenn mínir geri þau mistök að gefa fyrirtæki einfaldlega fimm punkta leiðbeiningar og koma svo aftur sex mánuðum síðar til að sjá hvað hefur gerst. Jafnvel gott rammaverk eins og virðisstraumskortlagning hefur, svo að segja, blinda bletti. Eftir hundruð viðtala við stjórnendur ýmissa fyrirtækja hef ég þróað ákveðið mynstur sem gerir mér kleift að brjóta vandamálið niður í þætti þess, og nú munum við ræða hvern og einn af þessum þáttum fyrir sig. Áður en ég innleiði tæknilegar lausnir nota ég þetta mynstur, og þar af leiðandi eru veggirnir mínir þaktir skýringarmyndum. Nýlega vann ég með verðbréfasjóði og endaði með 100-150 slíkar skýringarmyndir.
Slæm menning borðar góðar aðferðir í morgunmat
Niðurstaðan er þessi: engin Lean, Agile, SAFE eða DevOps aðferðir munu hjálpa ef menning fyrirtækisins er slæm. Það er eins og að kafa án köfunarbúnaðar eða starfa án röntgenmyndatöku. Með öðrum orðum, til að umorða Drucker og Deming: slæm fyrirtækjamenning mun gleypa hvaða gott kerfi sem er án þess að kafna.
Til að leysa þetta stóra vandamál þarf að grípa til eftirfarandi aðgerða:
- Gerðu allt verk sýnilegt: Öll verk þurfa að vera sýnileg. Ekki í þeim skilningi að þau þurfi að birtast á einhverjum skjá, heldur í þeim skilningi að þau ættu að vera sýnileg.
- Sameinuð vinnustjórnunarkerfi: Það er nauðsynlegt að sameina stjórnunarkerfi. Í vandamálinu um „ættbálka“-þekkingu og stofnanaþekkingu eru einstaklingar flöskuhálsinn í 9 af 10 tilfellum. Í bókinni Vandamálið var einn einstaklingur, Brent, sem var að tefja verkefnið um þrjú ár. Og ég rekst á svona „Brents“ alls staðar. Til að leysa þessa flöskuhálsa nota ég næstu tvo punkta á listanum okkar.
- Aðferðafræði takmarkanakenningarinnar: Kenning um takmarkanir.
- Samvinnubrellur: samvinnubrellur.
- Toyota Kata (): Ég ætla ekki að segja mikið um Toyota Kata. Ef þú hefur áhuga, þá er hann á GitHub-síðunni minni. um nánast öll þessi efni.
- Markaðsmiðað skipulag: markaðsmiðað skipulag.
- Endurskoðendur til vinstri: endurskoðun á fyrstu stigum hringrásarinnar.
Ég byrja að vinna með stofnun á mjög einfaldan hátt: Ég fer í fyrirtækið og tala við starfsmennina. Eins og þið sjáið er engin hátækni fólgin í því. Allt sem þarf er eitthvað til að skrifa á. Ég safna saman nokkrum teymum í einu herbergi og greini það sem þau eru að segja mér út frá mínum sjö frumgerðum. Svo gef ég þeim tússpenna og bið þá að skrifa niður á töfluna allt sem þau hafa sagt upphátt hingað til. Venjulega, á svona fundum, er það einn einstaklingur sem tekur glósur og í besta falli tekst þeim að fanga 10% af umræðunni. Með minni aðferð er hægt að hækka þessa tölu í um 40%.
(Þessa mynd má skoða sérstaklega )
Aðferð mín byggir á verkum Williams Schneider (William Schneider, ). Aðferðin byggir á þeirri hugmynd að hægt sé að skipta hvaða skipulagi sem er niður í fjóra fjórðunga. Fyrir mér er þetta skýringarmynd venjulega niðurstaðan af því að vinna með hundruðum annarra skýringarmynda sem koma upp þegar skipulag er greint. Segjum sem svo að við höfum skipulag með mikið stjórnunarstig en litla hæfni. Þetta er afar óæskileg staða: þegar allir fylgja reglunum en enginn veit hvað eigi að gera.
Aðeins betri kostur er sá sem hefur bæði mikla stjórn og hæfni. Ef slíkt fyrirtæki er arðbært gæti það ekki þurft DevOps. Áhugaverðustu fyrirtækin til að vinna með eru þau sem hafa mikla stjórn, litla hæfni og samvinnu, en mikla menningu (ræktun). Þetta þýðir að fyrirtækið hefur marga sem njóta þess að vinna þar og litla starfsmannaveltu.
(Þessa mynd má skoða sérstaklega )
Ég tel að aðferðir með stíflega skilgreindum leiðbeiningum hindri að lokum að sannleikurinn náist. Verðmætastraumakortlagning, sérstaklega, hefur margar reglur um hvernig eigi að skipuleggja upplýsingar. Á fyrstu stigum vinnunnar sem ég er að tala um núna eru þessar reglur engum til gagns. Besta leiðin til að skilja aðstæður er að einstaklingur með tússpenna í hendi sem teiknar raunverulega stöðu fyrirtækisins á hvíta töflu. Slíkar upplýsingar ná ekki til stjórnenda. Á þessum tímapunkti er heimskulegt að trufla þá og segja þeim að þeir hafi teiknað örina rangt. Á þessu stigi er betra að nota einfaldar reglur, til dæmis: hægt er að búa til margstigs abstrakt með því einfaldlega að nota mislita tússpenna.
Ég endurtek, engin hátækni hér. Hlutlægur veruleiki þess hvernig hlutirnir virka er sýndur með svörtum tússpenna. Fólk notar rauðan tússpenna til að gefa til kynna hvað þeim líkar ekki við núverandi ástand. Það er mikilvægt að þeir skrifi þetta, ekki ég. Þegar ég fer til upplýsingastjórans eftir fund, býð ég ekki upp á lista yfir 10 hluti sem þarf að laga. Ég leitast við að finna tengsl milli þess sem fólk í fyrirtækinu er að segja og núverandi sannaðra mynstra. Að lokum eru mögulegar lausnir á vandamálinu lagðar til með bláum tússpenna.
(Þessa mynd má skoða sérstaklega )
Dæmi um þessa aðferð er sýnt hér að ofan. Fyrr á þessu ári vann ég með banka. Öryggisdeildin þar var sannfærð um að þeim væri ekki heimilt að vera viðstaddur hönnunar- og kröfuúttektir.
(Þessa mynd má skoða sérstaklega )
Svo töluðum við við fólk úr öðrum deildum og það kom í ljós að fyrir um átta árum síðan höfðu hugbúnaðarframleiðendur sagt upp öryggisstarfsmönnum vegna þess að þeir voru að hægja á vinnunni. Og þá varð þetta bann sem var tekið sem sjálfsagðan hlut. Þó að í raun væri ekkert bann í gildi.
Fundurinn okkar var ótrúlega ruglingslegur: í um þrjár klukkustundir gátu fimm mismunandi teymi ekki útskýrt fyrir mér hvað gerðist á milli kóðans og byggingarinnar. Og þetta, virðist vera einfaldasta málið. Flestir DevOps ráðgjafar gera ráð fyrir að allir viti þetta nú þegar.
Þá lifnaði sá sem hafði umsjón með upplýsingatækni, sem hafði þagað í fjórar klukkustundir, skyndilega við þegar við komum að efni hans og hélt okkur uppteknum um stund. Í lokin spurði ég hann hvað honum fyndist um fundinn og ég mun aldrei gleyma svari hans. Hann sagði: „Ég hélt áður að það væru bara tvær leiðir til að afhenda hugbúnað í bankanum okkar, en nú veit ég að það eru fimm, og þrjár þeirra vissi ég ekki einu sinni af.“
(Þessa mynd má skoða sérstaklega )
Síðasti fundur minn í þessum banka var með teyminu sem vinnur að fjárfestingarhugbúnaði. Það var hjá þeim sem ég uppgötvaði að það er betra að skrifa skýringarmyndir á blað með tússpenna en á hvítan töflu, og jafnvel betra en á snjalltöflu.
Myndirnar sem þið sjáið sýna hvernig fundarsalur hótelsins leit út á fjórða degi fundarins. Við notuðum þessar skýringarmyndir til að leita að mynstrum eða frumgerðum.
Svo spyr ég starfsmennina spurninga og þeir skrifa svörin niður með tússpennum í þremur litum (svörtum, rauðum og bláum). Ég greini svör þeirra til að finna frumgerðir. Nú skulum við ræða hverja frumgerð fyrir sig.
1. Gerðu allt verk sýnilegt: Gerðu verkið sýnilegt
Flest fyrirtækin sem ég vinn með eru með mjög hátt hlutfall óskráðra vinnu. Til dæmis er þetta þegar einn starfsmaður kemur til annars og biður hann einfaldlega um að gera eitthvað. Í stórum fyrirtækjum geta 60% vinnunnar verið óskipulagt. Og allt að 40% vinnunnar er algjörlega óskráð. Ef þetta væri Boeing, myndi ég aldrei fljúga með þeirra flugvél aftur. Ef aðeins helmingur vinnunnar er skjalfestur, þá er óljóst hvort hún er unnin rétt eða ekki. Allar aðrar aðferðir reynast gagnslausar - það er enginn tilgangur í að reyna að gera neitt sjálfvirkt, því þekktu 50% geta verið hagræðasti og nákvæmasti hluti vinnunnar, sjálfvirkni hans mun ekki skila marktækum árangri, og allt það versta liggur í óskráða helmingnum. Án skjalfestingar er ómögulegt að finna alls kyns brellur og falda vinnu, eða að finna flöskuhálsa, þessa sömu „Brents“ sem ég nefndi áðan. Það er til frábær bók eftir Dominicu DeGrandis. Hún afhjúpar fimm mismunandi „tímalekar“ (tímaþjófar):
- Of mikið verk í vinnslu (WIP)
- Óþekktar ósjálfstæðir
- Óáætlað verk
- Misvísandi forgangsröðun
- Vanrækt vinna
Þetta er mjög verðmæt greining og bókin er frábær, en öll þessi ráð eru gagnslaus ef þú sérð aðeins 50% af gögnunum. Aðferðir Dominiku er aðeins hægt að beita ef þú nærð nákvæmni yfir 90%. Ég er að tala um aðstæður þar sem yfirmaður úthlutar undirmanni 15 mínútna verkefni og það tekur hann þrjá daga; en yfirmaðurinn veit í raun ekki að þessi undirmaður er háður fjórum eða fimm öðrum einstaklingum.
Fönixverkefnið er frábær saga um verkefni sem er þremur árum of seint. Ein persónan stendur frammi fyrir uppsögn vegna þessa og hittir aðra persónu, sem er kynnt sem eins konar Sókrates. Hann hjálpar til við að finna út hvað nákvæmlega fór úrskeiðis. Það kemur í ljós að fyrirtækið hefur einn kerfisstjóra að nafni Brent og öll vinna, á einn eða annan hátt, fer í gegnum hann. Á einum fundi er einn undirmanna spurður: hvers vegna tekur hvert hálftíma verkefni viku? Svarið er mjög einfölduð útskýring á biðröðunarkenningunni og lögmáli Little, sem leiðir í ljós að við 90% nýtingu tekur hver vinnustund níu klukkustundir. Hvert verkefni þarf að senda til sjö annarra einstaklinga, þannig að sú klukkustund verður 63 klukkustundir, sjö sinnum níu. Pointið mitt er að til að nota lögmál Little eða einhverja flókna biðröðunarkenningu þarftu að minnsta kosti að hafa gögn.
Þegar ég tala um sýnileika, þá á ég ekki við að allt þurfi að vera á skjánum, en að minnsta kosti þurfa gögnin að vera til staðar. Þegar þau eru til staðar kemur oft í ljós að það er gríðarlegt magn af ófyrirséðri vinnu sem einhvern veginn er beitt til Brents, jafnvel þótt það sé algjörlega óþarfi. Og Brent er frábær gaur; hann segir aldrei nei, en hann segir engum hvernig hann vinnur vinnuna sína.
Þegar vinna er sýnileg er hægt að flokka gögn snyrtilega (sem er það sem Dominika er að gera á myndinni), beita fimm tímaleka abstraktinu og innleiða sjálfvirkni.
2. Sameina vinnustjórnunarkerfi: Verkefnastjórnun
Frumgerðirnar sem ég er að tala um eru eins og píramídi. Ef sú fyrri er rétt gerð er sú seinni eins konar yfirbygging. Margar þeirra virka ekki fyrir sprotafyrirtæki; þær þarf að hafa í huga fyrir stærri fyrirtæki, eins og þau sem eru í Fortune 5000 listanum. Hjá síðasta fyrirtækinu sem ég vann fyrir voru 10 miðasölukerfi. Eitt teymi notaði Remedy, annað skrifaði sitt eigið kerfi, þriðja notaði Jira og enn önnur létu sér nægja tölvupóst. Sama vandamál kemur upp þegar fyrirtæki hefur 30 mismunandi leiðslur, en ég hef ekki tíma til að ræða öll þessi tilvik.
Ég ræði við fólk hvernig miðar eru búnir til, hvað gerist við þá og hvernig þeim er sleppt. Það áhugaverðasta er að fólk á fundum okkar er frekar einlægt. Ég spurði hversu margir gefa miðum sem ættu í raun að hafa „meiriháttar/engin áhrif“ merkið „meiriháttar/engin áhrif“. Það kemur í ljós að næstum allir gera þetta. Ég upplýsi ekki fólk og reyni mitt besta til að afhjúpa það ekki. Þegar fólk viðurkennir eitthvað fyrir mér af einlægni, þá afhjúpa ég það ekki. En þegar næstum allir eru að fara framhjá kerfinu þýðir það að allt öryggiskerfið er í raun blekking. Þess vegna er ekki hægt að draga ályktanir af gögnunum í þessu kerfi.
Til að leysa vandamálið með miðasölu þarftu að velja eitt aðalkerfi. Ef þú notar Jira skaltu aðeins nota Jira. Ef það er annar valkostur skaltu aðeins nota þann. Málið er að hugsa um miða sem annað skref í þróunarferlinu. Sérhver aðgerð ætti að hafa miða, sem ætti að flæða í gegnum þróunarvinnuflæðið. Miðarnir eru sendir til teymisins, sem birtir þá síðan á storyboardinu og ber síðan ábyrgð á þeim.
Þetta á við um allar deildir, þar á meðal innviði og rekstur. Þá fyrst getum við myndað okkur meira og minna áreiðanlega mynd af stöðu mála. Þegar þessu ferli er komið á fót verður skyndilega auðvelt að ákvarða hver ber ábyrgð á hverri umsókn. Því nú fáum við ekki 50%, heldur 98% af nýjum þjónustum. Ef þetta grunnferli virkar eykst nákvæmnin í öllu kerfinu.
Þjónustuleiðsla
Þetta á aftur aðeins við um stórfyrirtæki. Ef þú ert nýtt fyrirtæki á nýju sviði, brettu þá upp ermarnar og haltu þig við Travis CI eða CircleCI. Hvað varðar Fortune 5000 fyrirtæki, þá er dæmi sem átti sér stað í bankanum þar sem ég vann lýsandi. Google kom til þeirra og sýndi þeim skýringarmyndir af gömlum IBM kerfum. Google strákarnir spurðu, ruglaðir, „Hvar er frumkóðinn fyrir þetta?“ Það var enginn frumkóði, ekki einu sinni notendaviðmót. Þetta er veruleikinn sem stór fyrirtæki þurfa að takast á við: 40 ára gamlar bankafærslur á gamalli stórtölvu. Einn af viðskiptavinum mínum notar Kubernetes gáma með Circuit Breaker mynstrum, auk Chaos Monkey, allt fyrir KeyBank forritið. En þessir gámar tengjast að lokum COBOL forriti.
Strákarnir hjá Google voru alveg vissir um að þeir myndu leysa öll vandamál viðskiptavina minna, en þá fóru þeir að spyrja spurninga: Hvað er IBM datapipe? Þeir svöruðu: Það er tengill. Við hvað tengist það? Við Sperry kerfið. Og hvað er þetta? Og svo framvegis. Við fyrstu sýn virðist sem engin DevOps sé til staðar hér. En í raun er það mögulegt. Það eru til afhendingarkerfi sem gera þér kleift að úthluta vinnuflæði til afhendingarteyma.
3. Kenning um skorður: Kenning um skorður
Förum yfir í þriðju frumgerðina: stofnana-/„ættbálka“-þekkingu. Yfirleitt eru í hvaða stofnun sem er fáeinir einstaklingar sem vita allt og ráða ferðinni. Þetta eru þeir sem hafa starfað lengst hjá stofnuninni og þekkja allar flýtileiðir.
Þegar þetta kemur upp á myndinni hringi ég sérstaklega í kringum þá einstaklinga með tússpenna: til dæmis kemur í ljós að ákveðinn Lou er viðstaddur alla fundina. Og það er mér ljóst: þetta er Brent, héðan í frá. Þegar upplýsingastjórinn velur á milli mín í stuttermabol og íþróttaskóm og gaurs frá IBM í jakkafötum, þá velja þeir mig vegna þess að ég get sagt forstjóranum hluti sem hinn gaurinn vill ekki segja þeim og sem forstjórinn gæti ekki viljað heyra. Ég segi þeim að það sé flöskuháls í fyrirtækinu þeirra, einhver sem heitir Fred og einhver sem heitir Lou. Þennan flöskuháls þarf að leysa úr læðingi; þekkingu þeirra þarf að draga úr þeim á einn eða annan hátt.
Til að leysa svona vandamál gæti ég til dæmis lagt til að nota Slack. Snjall forstjóri mun spyrja: „Af hverju?“ DevOps ráðgjafar svara venjulega í slíkum tilfellum: „Vegna þess að það er það sem allir gera.“ Ef forstjórinn er sannarlega klár mun hann segja: „Og hvað með það?“ Og þar með er samtalinu lokið. Ég svara því: vegna þess að fyrirtækið hefur fjóra flöskuhálsa: Fred, Lou, Susie og Jane. Til að stofnfesta þekkingu þeirra þarftu fyrst að kynna Slack. Allar wiki-síðurnar þínar eru algjört bull vegna þess að enginn veit að þær eru til. Ef teymi verkfræðinga sér um bæði for- og bakendaþróun og allir þurfa að vita að þeir geta haft samband við forendaþróunarteymið eða innviðateymið með spurningar, þá munu Lou eða Fred líklega hafa tíma til að tengjast wiki-síðunni. Og þá, í Slack, gæti einhver spurt hvers vegna, segjum, skref 5 virkar ekki. Og þá munu Lou eða Fred leiðrétta leiðbeiningarnar í wiki-síðunni. Ef þú kemur þessu ferli á fót mun margt falla á sinn stað.
Þetta er aðalatriðið mitt: áður en mælt er með hátæknilausnum þarf fyrst að leggja grunninn að verkinu, og það er hægt að gera með þeim lágtæknilausnum sem lýst var hér að ofan. Ef byrjað er á hátæknilausnum án þess að útskýra tilgang þeirra, þá endar það yfirleitt ekki vel. Einn af viðskiptavinum okkar notar Azure ML, mjög ódýra og einfalda lausn. Um 30% af spurningum þeirra voru svöruð af sjálfnámsvélinni sjálfri. Og þetta var skrifað af rekstraraðilum sem höfðu engan bakgrunn í gagnavísindum, tölfræði eða stærðfræði. Þetta er athyglisvert. Kostnaðurinn við slíka lausn er í lágmarki.
4. Samvinnubrellur: Brellur samvinnu
Fjórða frumgerðin er sú að einangrun verður að berjast gegn. Flestir vita þetta nú þegar: einangrun elur af sér fjandskap. Ef hver deild er á sinni hæð og fólk hefur ekki samskipti sín á milli nema í lyftunni, þá er mjög auðvelt að mynda fjandskap á milli þeirra. En ef fólk er hins vegar í sama herbergi, þá hverfur hann strax. Þegar einhver kemur með almenna ásökun - til dæmis að þetta og þetta viðmót virki aldrei - er auðvelt að taka hana í sundur. Forritararnir sem skrifuðu viðmótið þurfa bara að byrja að spyrja sértækra spurninga og það mun fljótlega koma í ljós að til dæmis notandinn notaði tólið einfaldlega rangt.
Það eru margar leiðir til að sigrast á einangrun. Ég var einu sinni beðinn um að vera ráðgjafi fyrir banka í Ástralíu en ég hafnaði því ég á tvö börn og konu. Það besta sem ég gat gert var að mæla með myndrænni frásögn. Það er eitthvað sem hefur reynst vel. Önnur áhugaverð leið eru „lean coffee fundir“. Í stóru fyrirtæki er þetta frábær leið til að miðla þekkingu. Þú getur líka haldið innri DevOpsDays, „hakkathons“ og svo framvegis.
5. Kataþjálfun
Eins og ég nefndi alveg í upphafi, þá mun ég ekki tala um það í dag. Ef þú hefur áhuga geturðu horft á það. .
Það er líka góð skýrsla um þetta efni eftir Mike Rother:
6. Markaðsmiðað: markaðsmiðað skipulag
Þetta snýst um mismunandi mál. Til dæmis „ég“-fólk, „t“-fólk og „e“-fólk. „ég“-fólk er fólk sem gerir aðeins eitt. Það er yfirleitt til staðar í fyrirtækjum með aðskildum deildum. „t“-fólk er fólk sem er gott í einu en skarar líka úr í nokkrum öðrum. „e“-fólk eða jafnvel „greiðufólk“ er fólk sem býr yfir mörgum hæfileikum.
Lögmál Conways á við hér (), sem í einföldustu mynd má draga saman á eftirfarandi hátt: ef þrjú teymi vinna að þýðanda, þá samanstendur þýðandinn sem myndast af þremur hlutum. Þess vegna, ef stofnun hefur mikla einangrun, þá verða jafnvel Kubernetes, Circuit Breaker, API extensibility og aðrir töff hlutir uppbyggðir á sama hátt og stofnunin sjálf. Stranglega samkvæmt Conway, og til að pirra alla ykkur ungu nördana.
Lausnin á þessu vandamáli hefur verið lýst oft. Til dæmis eru til skipulagsgerðir sem Fernando Fernandez lýsti. Vandamálaarkitektúrinn sem ég nefndi, með einangrun sinni, er virknismiðuð arkitektúr. Önnur gerðin er sú versta, fylkisarkitektúr, sem er blanda af hinum tveimur. Þriðja gerðin er það sem við sjáum í flestum sprotafyrirtækjum, og stór fyrirtæki reyna einnig að passa við þessa gerð. Þetta er markaðsmiðað skipulag. Hér á sér stað hagræðing til að ná sem hraðastum viðbrögðum við beiðnum viðskiptavina. Þetta er stundum kallað flatt skipulag.
Þessari uppbyggingu er lýst á mismunandi vegu af mörgum, mér líkar orðalagið smíða/keyra skipanir, á Amazon kalla þeir það tvö pizzaliðÍ þessari uppbyggingu eru allir einstaklingar af „I“-gerð flokkaðir í kringum eina þjónustu og smám saman verða þeir nær „T“-gerð einstaklingum og ef þeim er rétt stjórnað geta þeir jafnvel orðið „E“. Fyrsta mótrökin hér eru að slík uppbygging er óþörf. Hvers vegna þurfum við prófara í hverri deild ef við getum haft sérstaka prófunardeild? Sem ég svara: aukakostnaðurinn í þessu tilfelli er verðið fyrir að allt fyrirtækið verði „E“-gerð í framtíðinni. Í slíkri uppbyggingu lærir prófarinn smám saman um net, arkitektúr, hönnun o.s.frv. Fyrir vikið er hver meðlimur fyrirtækisins fullkomlega meðvitaður um allt sem gerist innan fyrirtækisins. Ef þú vilt vita hvernig þetta kerfi virkar í atvinnulífinu, lestu þá áfram. .
7. Endurskoðendur sem snúa að vinstri hlið: endurskoðun snemma í ferlinu. Öryggissamræmi er sýnilegur eiginleiki.
Þetta er þegar gjörðir þínar standast ekki lyktarprófið, ef svo má að orði komast. Fólkið sem vinnur fyrir þig er ekki heimskt. Ef, eins og í dæminu hér að ofan, þau hafa lítil/engin áhrif alls staðar, og þetta hefur gengið svona áfram í þrjú ár, og enginn tók eftir því, þá vita allir fullvel að kerfið virkar ekki. Eða annað dæmi: ráðgjafarnefnd um breytingar, þar sem skýrslur verða að berast á hverjum, segjum, miðvikudegi. Þar er hópur fólks (ekki sérstaklega vel launað, reyndar), sem, í orði kveðnu, ætti að vita hvernig kerfið virkar í heild sinni. Og á síðustu fimm árum hefur þú líklega tekið eftir því að kerfin okkar eru ótrúlega flókin. Og fimm eða sex manns þurfa að taka ákvörðun um breytingu sem þeir innleiddu ekki og sem þeir vita ekkert um.
Auðvitað virkar þessi aðferð ekki. Ég verð að losna við svona hluti því þetta fólk verndar ekki kerfið. Teymið sjálft verður að taka ákvörðunina, því teymið verður að bera ábyrgð á henni. Annars kemur upp þversagnakennd staða þar sem stjórnandi sem hefur aldrei skrifað kóða á ævinni segir forritara hversu langan tíma það ætti að taka að skrifa kóða. Hjá einu fyrirtæki sem ég vann með voru sjö mismunandi stjórnir sem fóru yfir allar breytingar, þar á meðal arkitektúrstjórn, vörustjórn og svo framvegis. Það var jafnvel skyldubundinn biðtími, þó að einn starfsmaður hafi sagt mér að á tíu árum sem ég vann með honum hefði enginn hafnað breytingum hans á þessu skyldubundna tímabili.
Endurskoðendur ættu að vera boðið, ekki vísað frá. Segðu þeim að þú skrifir óbreytanlegar tvíundarílát sem, ef öll próf standast, haldast óbreytanleg að eilífu. Segðu þeim að þú hafir leiðslu sem kóða og útskýrðu hvað það þýðir. Sýndu þeim eftirfarandi skýringarmynd: óbreytanlegt, aðeins leshæft tvíundarílát í íláti sem stenst öll varnarleysipróf; og þá er það ekki aðeins aldrei snert, heldur er jafnvel kerfið sem býr til leiðsluna aldrei snert, þar sem hún er líka búin til á kraftmikinn hátt. Ég á viðskiptavini eins og Capital One sem nota Vault til að búa til eins konar blockchain. Þú þarft ekki að sýna endurskoðandanum „uppskriftir“; sýndu þeim bara blockchain sem sýnir greinilega hvað gerðist við Jira miða í framleiðslu og hver ber ábyrgð á því.
Samkvæmt , sem Sonatype bjó til árið 2018, fékk 87 milljarða OSS niðurhalsbeiðna árið 2017.
Tapið sem hlýst af veikleikum er óheyrilega mikið. Þar að auki innihalda tölurnar sem þú sérð hér að ofan ekki fórnarkostnað. Stutt yfirlit yfir DevSecOps. Ég vil strax segja að ég hef engan áhuga á að ræða viðeigandi nafnið. Málið er að þar sem DevOps hefur gengið svona vel ættum við að reyna að bæta öryggi við þessa leiðslu.
Dæmi um slíka röð:
Þetta er ekki tilmæli um neinar ákveðnar vörur, þó að mér líki þær allar. Ég notaði þær sem dæmi til að sýna fram á að DevOps, sem upphaflega byggðist á iðnaðarskipulagslíkani, gerir kleift að sjálfvirknivæða öll stig vöruþróunar.
Og það er engin ástæða til að við getum ekki beitt sömu nálgun í öryggismálum.
Samtals
Að lokum mun ég gefa nokkur ráð fyrir DevSecOps. Þú þarft að fá endurskoðendur með í smíði kerfa þinna, fjárfesta tíma í menntun þeirra og vinna með þeim. Ennfremur þarftu að heyja algjörlega miskunnarlaust stríð gegn fölskum jákvæðum niðurstöðum. Jafnvel dýrasta skönnunartólið fyrir veikleika getur endað með því að skapa mjög slæma venjur hjá forriturum þínum ef þú þekkir ekki merkis-til-hávaðahlutfallið þitt. Forritarar verða yfirþyrmandi af atburðum og eyða þeim einfaldlega. Ef þú hefur heyrt um Equifax atvikið, þá er þetta nokkurn veginn það sem gerðist þar: merki af mestu alvarleika var hunsað. Ennfremur þarf að útskýra veikleika á þann hátt að það sýnir greinilega áhrif þeirra á reksturinn. Til dæmis mætti segja að þetta sé sama veikleikinn og Equifax atvikið. Öryggisveiflur ættu að vera meðhöndlaðar á sama hátt og önnur hugbúnaðarvandamál, sem þýðir að þær ættu að vera samþættar í heildar DevOps ferlið. Þær ættu að vera stjórnaðar með Jira, Kanban og þess háttar. Forritarar ættu ekki að gera ráð fyrir að einhver annar muni gera þetta - þvert á móti, allir ættu að vera að gera það. Að lokum þurfa þeir að leggja áherslu á að þjálfa fólk.
gagnlegir krækjur
Hér eru nokkur erindi frá DevOops ráðstefnunni sem gætu verið gagnleg fyrir þig:
- Sergey Berdnikov, Artyom Kalichkin - Árangurssaga, eða „Dev+DevOps+Ops“ (, )
- Barukh Sadogursky, Leonid Igolnik - DevOps á stórum skala: Grísk harmleikur í þremur þáttum (, )
- Alexander Titov, Kirill Tolkachev -
- Tímóteus Lister —
Skoða DevOops 2020 Moskvu - Þar er líka margt áhugavert.
Heimild: www.habr.com
