Spurningin „hvernig á að útfæra devops“ hefur verið til í mörg ár, en það eru ekki mörg góð efni. Stundum verður þú fórnarlamb auglýsingar frá ekki svo snjöllum ráðgjöfum sem þurfa að selja tíma sinn, sama hvernig. Stundum eru þetta óljós, ákaflega almenn orð um hvernig skip stórfyrirtækja plægja víðáttur alheimsins. Spurningin vaknar: Hvaða máli skiptir þetta okkur? Kæri höfundur, geturðu sett hugmyndir þínar skýrt fram í lista?
Allt þetta stafar af þeirri staðreynd að ekki hefur safnast upp mikil raunveruleg æfing og skilningur á niðurstöðu umbreytinga á menningu fyrirtækisins. Breytingar á menningu eru langtíma hlutir, niðurstöður sem munu ekki birtast eftir viku eða mánuð. Okkur vantar einhvern nógu gamlan til að hafa séð hvernig fyrirtæki hafa verið byggð upp og brugðist í gegnum árin.
Jón Willis - einn af feðrum DevOps. John hefur áratuga reynslu af því að vinna með miklum fjölda fyrirtækja. Nýlega fór John að taka eftir sérstökum mynstrum sem eiga sér stað þegar unnið er með hvert þeirra. Með því að nota þessar erkitýpur leiðbeinir John fyrirtækjum á sannri leið um DevOps umbreytingu. Lestu meira um þessar erkitýpur í þýðingu skýrslu hans frá DevOops 2018 ráðstefnunni.
Um ræðumanninn:
Meira en 35 ár í upplýsingatæknistjórnun, tók þátt í stofnun forvera OpenCloud hjá Canonical, tók þátt í 10 gangsetningum, þar af tvö seld til Dell og Docker. Sem stendur er hann varaforseti DevOps og stafrænna starfshátta hjá SJ Technologies.
Næst er sagan frá sjónarhóli Jóhannesar.
Ég heiti John Willis og auðveldast er að finna mig á Twitter, . Ég er með sama samnefni á Gmail og GitHub. A þú getur fundið myndbandsupptökur af skýrslum mínum og kynningar fyrir þær.
Ég á marga fundi með CIO hjá ýmsum stórum fyrirtækjum. Þeir kvarta mjög oft yfir því að þeir skilji ekki hvað DevOps er og allir sem reyna að útskýra það fyrir þeim eru að tala um eitthvað annað. Önnur algeng kvörtun er að DevOps virkar ekki, þó svo að það virðist sem leikstjórarnir séu að gera allt eins og þeim er útskýrt. Við erum að tala um stór fyrirtæki sem eru meira en hundrað ára gömul. Eftir að hafa rætt við þá komst ég að þeirri niðurstöðu að í mörgum vandamálum er það ekki hátækni sem hentar best heldur frekar tiltölulega lágtæknilausnir. Í margar vikur talaði ég bara við fólk frá mismunandi deildum. Það sem þú sérð á fyrstu myndinni í færslunni er síðasta verkefnið mitt, svona leit herbergið út eftir þriggja daga vinnu.
Hvað er DevOps?
Reyndar, ef þú spyrð 10 mismunandi fólk, munu þeir gefa 10 mismunandi svör. En hér er það áhugaverða: öll tíu svörin verða rétt. Hér er ekkert rangt svar. Ég var frekar djúpt í DevOps, í um það bil 10 ár, og var fyrsti Bandaríkjamaðurinn á fyrsta DevOpsDay. Ég mun ekki segja að ég sé klárari en allir sem taka þátt í DevOps, en það er varla nokkur sem hefur eytt eins miklu átaki í það. Ég trúi því að DevOps eigi sér stað þegar mannauð og tækni koma saman. Við gleymum oft mannlegu víddinni þó við tölum mikið um alls kyns menningu.
Nú höfum við mikið af gögnum, fimm ára fræðilegar rannsóknir, prófun á kenningum á iðnaðarkvarða. Það sem þessar rannsóknir segja okkur er að ef þú sameinar einhver hegðunarmynstur í skipulagsmenningu geturðu náð 2000x hraða. Þessi hröðun jafnast á við jafn aukinn stöðugleika. Þetta er megindleg mæling á þeim ávinningi sem DevOps getur fært hvaða fyrirtæki sem er. Fyrir nokkrum árum var ég að tala um DevOps við forstjóra Fortune 5000 fyrirtækis. Þegar ég var að undirbúa kynninguna var ég mjög stressaður því ég þurfti að draga saman áralanga reynslu mína á 5 mínútum.
Að lokum gaf ég eftirfarandi Skilgreining á DevOps: Það er sett af starfsháttum og mynstrum sem gera kleift að breyta mannauði í afkastamikið skipulagsfé. Sem dæmi má nefna hvernig Toyota hefur starfað síðastliðin 50 eða 60 ár.
(Hér eftir eru slíkar skýringarmyndir ekki gefnar sem viðmiðunarefni, heldur sem skýringarmyndir. Efni þeirra er mismunandi fyrir hvert nýtt fyrirtæki. Hins vegar er hægt að skoða myndina sérstaklega og stækka
Ein af farsælustu slíkum aðferðum er gildi straum kortlagning. Um þetta hafa verið skrifaðar nokkrar góðar bækur, þær farsælustu eru eftir Karen Martin. En undanfarið ár hef ég komist að þeirri niðurstöðu að jafnvel þessi nálgun sé of hátæknileg. Það hefur vissulega marga kosti og ég hef notað það mikið. En þegar forstjórinn spyr þig hvers vegna fyrirtæki hans getur ekki skipt yfir í nýjar teinar, þá er of snemmt að tala um kortlagningu virðisstraums. Það eru miklu fleiri grundvallarspurningar sem fyrst verður að svara.
Ég held að mistökin sem margir samstarfsmenn mínir gera séu þau að þeir gefa fyrirtækinu einfaldlega fimm punkta leiðbeiningar og koma svo aftur hálfu ári síðar og sjá hvað gerðist. Jafnvel gott kerfi eins og kortlagning virðistraums hefur, við skulum segja, blinda bletti. Eftir hundruð viðtala við stjórnarmenn ýmissa fyrirtækja hef ég þróað ákveðið mynstur sem gerir okkur kleift að skipta vandanum niður í sína þætti og nú verður fjallað um hvern þessara þátta í röð. Áður en ég beiti tæknilausnum nota ég þetta mynstur og þar af leiðandi eru allir veggir mínir þaktir skýringarmyndum. Nýlega var ég að vinna með verðbréfasjóði og endaði með 100-150 slík kerfi.
Slæm menning borðar góðar aðferðir í morgunmat
Meginhugmyndin er þessi: ekkert magn af Lean, Agile, SAFE og DevOps mun hjálpa ef menning stofnunarinnar sjálf er slæm. Þetta er eins og að kafa á dýpi á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 skipulagsmenning mun gleypa hvaða gott kerfi sem er án þess að kafna í því.
Til að leysa þetta aðalvandamál þarftu að taka eftirfarandi skref:
- Gerðu alla vinnu sýnilega: þú þarft að gera alla vinnu sýnilega. Ekki í þeim skilningi að það þurfi endilega að birtast á einhverjum skjá, heldur í þeim skilningi að það verður að vera hægt að sjá það.
- Samþætt vinnustjórnunarkerfi: Það þarf að sameina stjórnkerfi. Í vandamálinu um „ættbálka“ þekkingu og stofnanaþekkingu er flöskuhálsinn í 9 tilfellum af 10 fólk. Í bókinni vandamálið var hjá einum einstaklingi, Brent, sem olli því að verkefnið var þremur árum á eftir áætlun. Og ég rekst á þessa "Brents" alls staðar. Til að leysa þessa flöskuhálsa nota ég næstu tvö atriði á listanum okkar.
- Kenning um þvingun Aðferðafræði: kenning um þvingun.
- Samstarfsárásir: samstarfsárásir.
- Toyota Kata (): Ég ætla ekki að tala mikið um Toyota Kata. Ef þú hefur áhuga, á github mínum um næstum hvert og eitt þessara mála.
- Markaðsmiðuð stofnun: markaðsmiðað skipulag.
- Vinstri vinstri endurskoðendur: endurskoðun á fyrstu stigum lotunnar.
Ég byrja að vinna með stofnun mjög einfaldlega: Ég fer til fyrirtækisins og tala við starfsmenn. Eins og þú sérð, engin hátækni. Allt sem þú þarft er eitthvað til að skrifa á. Ég safna nokkrum liðum í einu herbergi og greini það sem þeir segja mér frá sjónarhóli 7 erkitýpanna minna. Og svo gef ég þeim sjálf merki og bið þau að skrifa niður á töfluna allt sem þau hafa sagt upphátt hingað til. Yfirleitt á svona fundum er einn aðili sem skrifar allt niður og getur í besta falli skrifað niður 10% umræðunnar. Með minni aðferð er hægt að hækka þessa tölu upp í um 40%.
(Þessa mynd er hægt að skoða sérstaklega )
Nálgun mín er byggð á verkum William Schneider. ). Nálgunin byggir á þeirri hugmynd að skipta megi hvaða skipulagi sem er í fjóra reiti. Þetta kerfi fyrir mig er venjulega afleiðing af því að vinna með þessum hundruðum annarra kerfa sem koma upp þegar stofnun er greind. Segjum sem svo að við höfum stofnun með mikla stjórn, en með litla hæfni. Þetta er ákaflega óæskilegur kostur: þegar allir eru á tánum en enginn veit hvað á að gera.
Nokkuð betri kostur er sá sem hefur mikla stjórn og hæfni. Ef slíkt fyrirtæki er arðbært, þá þarf það kannski ekki DevOps. Athyglisverðast er að vinna með fyrirtæki sem hefur mikla stjórn, litla hæfni og samvinnu en á sama tíma mikla menningu (ræktun). Þetta þýðir að þar er mikið af fólki sem hefur gaman af því að vinna hjá fyrirtækinu og vinnuveltan er lítil.
(Þessa mynd er hægt að skoða sérstaklega )
Mér sýnist að aðferðir með stífar leiðbeiningar komi á endanum í veg fyrir sannleikann. Sérstaklega í virðistraumskortlagningu eru margar reglur um hvernig upplýsingar eiga að vera byggðar upp. Á fyrstu stigum vinnunnar, sem ég er að tala um núna, þarf enginn þessar reglur. Ef maður með merki í höndunum lýsir raunverulegum aðstæðum í fyrirtækinu í stjórninni er það besta leiðin til að átta sig á stöðu mála. Slíkar upplýsingar ná ekki til stjórnarmanna. Á þessari stundu er heimskulegt að trufla viðkomandi og segja að hann hafi teiknað einhvers konar ör rangt. Á þessu stigi er betra að nota einfaldar reglur, til dæmis: hægt er að búa til fjölþrepa abstrakt með því einfaldlega að nota marglita merki.
Ég endurtek, engin hátækni. Svarta merkið sýnir hlutlægan veruleika hvernig allt virkar. Með rauðu merki merkir fólk það sem því líkar ekki við núverandi stöðu mála. Það er mikilvægt að þeir skrifi þetta, ekki ég. Þegar ég fer til CIO 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 mynstur. Að lokum bendir blátt merki á mögulegar lausnir á vandamálinu.
(Þessa mynd er hægt að skoða sérstaklega )
Dæmi um þessa nálgun er nú lýst hér að ofan. Í byrjun þessa árs vann ég með einum banka. Öryggisfólkið þar var sannfært um að það ætti ekki að koma að hönnunar- og kröfurýni.
(Þessa mynd er hægt að skoða sérstaklega )
Og svo var rætt við fólk úr öðrum deildum og það kom í ljós að fyrir um 8 árum síðan sögðu hugbúnaðarframleiðendur öryggisstarfsmönnum upp vegna þess að þeir voru að hægja á vinnunni. Og svo breyttist það í bann, sem þótti sjálfsagt. Þó í raun og veru væri ekkert bann.
Fundurinn okkar fór fram á mjög ruglingslegan hátt: í um það bil þrjár klukkustundir gátu fimm mismunandi teymi ekki útskýrt fyrir mér hvað var að gerast á milli kóðans og þingsins. Og þetta virðist vera það einfaldasta. Flestir DevOps ráðgjafar gera ráð fyrir því fyrirfram að allir viti þetta nú þegar.
Svo vaknaði skyndilega til lífsins sá sem hefur yfirumsjón með upplýsingatæknistjórnun, sem hafði verið þögull í fjórar klukkustundir, þegar við komum að efni hans og tók okkur mjög langan tíma. Í lokin spurði ég hann hvað honum fyndist um fundinn og ég mun aldrei gleyma svari hans. Hann sagði: "Ég hélt að bankinn okkar hefði aðeins tvær leiðir til að afhenda hugbúnað, en núna veit ég að þeir eru fimm og ég vissi ekki einu sinni um þrjár."
(Þessa mynd er hægt að skoða sérstaklega )
Síðasti fundur hjá þessum banka var með fjárfestingarhugbúnaðarteyminu. Það var hjá henni sem kom í ljós að það er betra að skrifa skýringarmyndir með tússi á blað en á töflu og jafnvel betra en á snjallborði.
Myndirnar sem þú sérð eru hvernig fundarherbergi hótelsins leit út á fjórða degi fundarins okkar. Og við notuðum þessi kerfi til að leita að mynstrum, það er að segja erkitýpum.
Svo ég spyr starfsmennina spurninga, þeir skrifa niður svörin með þremur litum (svartum, rauðum og bláum). Ég greini svör þeirra fyrir erkitýpum. Nú skulum við ræða allar erkitýpurnar í röð.
1. Gerðu alla vinnu sýnilega: Gerðu vinnu sýnilega
Flest fyrirtæki sem ég vinn með eru með mjög hátt hlutfall óþekktrar vinnu. Þetta er til dæmis þegar einn starfsmaður kemur að öðrum og biður einfaldlega um að gera eitthvað. Í stórum stofnunum getur verið um 60% óáætluð vinna að ræða. Og allt að 40% af vinnunni er ekki skjalfest á nokkurn hátt. Ef það væri Boeing myndi ég aldrei fara um borð í flugvélina þeirra aftur á ævinni. Ef aðeins helmingur verksins er skjalfestur, þá er ekki vitað hvort rétt sé að verki staðið eða ekki. Allar aðrar aðferðir reynast gagnslausar - það þýðir ekkert að reyna að gera eitthvað sjálfvirkt, því hin þekktu 50% geta verið samhengi og skýrasti hluti vinnunnar, sjálfvirknin mun ekki gefa frábæran árangur, og allt það versta hlutirnir eru í ósýnilega helmingnum. Þar sem skjöl eru ekki til er ómögulegt að finna alls kyns hakk og falið verk, ekki að finna flöskuhálsa, einmitt þessi „Brents“ sem ég talaði nú þegar um. Það er til dásamleg bók eftir Dominica DeGrandis . Hún opinberar fimm mismunandi „tímalekar“ (tímaþjófar):
- Of mikil vinna í vinnslu (WIP)
- Óþekkt ósjálfstæði
- Óskipulögð vinna
- Misvísandi forgangsröðun
- Vanrækt vinna
Þetta er mjög dýrmæt greining og bókin frábær, en öll þessi ráð eru gagnslaus ef aðeins 50% gagna eru sýnileg. Aðferðirnar sem Dominica leggur til er hægt að nota ef nákvæmni sem er yfir 90% er náð. Ég er að tala um aðstæður þar sem yfirmaður gefur undirmanni 15 mínútna verkefni, en það tekur hann þrjá daga; en yfirmaðurinn veit ekki alveg að þessi undirmaður er háður fjórum eða fimm öðrum.
The Phoenix Project er dásamleg saga um verkefni sem var þremur árum of seint. Ein persónan á yfir höfði sér uppsögn vegna þessa og hittir hann aðra persónu sem er sýndur sem eins konar Sókrates. Hann hjálpar til við að finna út hvað nákvæmlega fór úrskeiðis. Í ljós kemur að fyrirtækið er með einn kerfisstjóra, sem heitir Brent, og öll vinna fer einhvern veginn í gegnum hann. Á einum fundinum er einn undirmanna spurður: hvers vegna tekur hvert hálftíma verkefni viku? Svarið er mjög einfölduð framsetning á biðröðfræði og lögum Little og í þessari kynningu kemur í ljós að við 90% nýtingu tekur hver vinnustund 9 klst. Hvert verkefni þarf að senda til sjö annarra, þannig að klukkutíminn verður 63 klukkustundir, 7 sinnum 9. Það sem ég er að segja er að til þess að nota Little's Law eða einhverja flókna biðraðakenningu þarftu að minnsta kosti að hafa gögn.
Svo þegar ég tala um sýnileika er ég ekki að meina að allt sé á skjánum heldur að þú hafir að minnsta kosti gögn. Þegar þeir gera það kemur oft í ljós að það er mjög mikið magn af óskipulagðri vinnu sem er einhvern veginn send til Brent þegar engin þörf er á því. Og Brent er frábær strákur, hann mun aldrei segja nei, en hann segir engum hvernig hann vinnur vinnuna sína.
Þegar verkið er sýnilegt er hægt að flokka gögnin á snyrtilegan hátt (það er það sem Dominique er að gera á myndinni), hægt er að beita útdrætti tímalekanna fimm og beita sjálfvirkni.
2. Sameina vinnustjórnunarkerfi: Verkefnastjórnun
Erkitýpurnar sem ég er að tala um eru eins konar pýramídi. Ef sú fyrri er gerð rétt, þá er sú seinni þegar eins konar viðbót. Margt af þessu virkar ekki fyrir sprotafyrirtæki, það þarf að hafa þau í huga fyrir stærri fyrirtæki eins og Fortune 5000. Síðasta fyrirtækið sem ég vann hjá var með 10 miðakerfi. Eitt lið var með Remedy, annað skrifaði einhvers konar eigið kerfi, það þriðja notaði Jira og sumir létu sér nægja tölvupóst. Sama vandamál kemur upp ef fyrirtækið er með 30 mismunandi leiðslur, en ég hef ekki tíma til að ræða öll slík mál.
Ég ræði við fólk nákvæmlega hvernig miðar verða til, hvað verður um þá næst og hvernig þeir eru sniðgengnir. Það áhugaverðasta er að fólk á fundum okkar talar alveg af einlægni. Ég spurði hversu margir setja "minniháttar / engin áhrif" á miða sem ættu í raun að fá "mikil áhrif". Það kom í ljós að nánast allir gera þetta. Ég tek ekki þátt í uppsögn og reyni á allan mögulegan hátt að bera kennsl á fólk. Þegar þeir játa eitthvað í einlægni fyrir mér, gef ég manneskjunni ekki frá mér. En þegar næstum allir fara framhjá kerfinu þýðir það að allt öryggi er í meginatriðum gluggaklæðning. Því er ekki hægt að draga neinar ályktanir af gögnum þessa kerfis.
Til að leysa miðavandann þarftu að velja eitt aðalkerfi. Ef þú notar Jira, geymdu það Jira. Ef það er einhver valkostur, láttu hann vera þann eina. Niðurstaðan er sú að miða ber að skoða sem enn eitt skrefið í þróunarferlinu. Sérhver aðgerð verður að hafa miða sem verður að flæða í gegnum þróunarvinnuflæðið. Miðar eru sendir til teymisins sem setur þá á söguborðið og tekur síðan ábyrgð á þeim.
Þetta á við um allar deildir, þar með talið innviði og rekstur. Í þessu tilviki er hægt að mynda að minnsta kosti einhverja trúverðuga hugmynd um stöðu mála. Þegar þessu ferli hefur verið komið á, verður skyndilega auðvelt að bera kennsl á hver ber ábyrgð á hverri umsókn. Því nú fáum við ekki 50%, heldur 98% af nýrri þjónustu. Ef þetta kjarnaferli virkar, þá batnar nákvæmni í öllu kerfinu.
Þjónustuleiðsla
Þetta á aftur aðeins við um stór fyrirtæki. Ef þú ert nýtt fyrirtæki á nýju sviði skaltu bretta upp ermarnar og vinna með Travis CI eða CircleCI. Þegar það kemur að Fortune 5000 fyrirtækjum, dæmi um það sem gerðist í bankanum þar sem ég vann. Google kom til þeirra og þeim voru sýndar skýringarmyndir af gömlum IBM kerfum. Strákarnir frá Google spurðu í rugli - hvar er frumkóði fyrir þetta? En það er enginn frumkóði, ekki einu sinni GUI. Þetta er veruleikinn sem stórar stofnanir þurfa að takast á við: 40 ára gamlar bankaskrár á fornri stórtölvu. Einn af viðskiptavinum mínum notar Kubernetes ílát með hringrásarmynstri, auk Chaos Monkey, allt fyrir KeyBank forritið. En þessir gámar tengjast að lokum COBOL forriti.
Strákarnir frá Google voru fullvissir um að þeir myndu leysa öll vandamál viðskiptavinar míns, og þá fóru þeir að spyrja spurninga: hvað er IBM datapipe? Þeim er sagt: þetta er tengi. Hvað tengist það? Til Sperry kerfið. Og hvað er það? Og svo framvegis. Við fyrstu sýn virðist það: hvers konar DevOps geta verið til? En í raun er það mögulegt. Það eru til afhendingarkerfi sem gera þér kleift að afhenda afgreiðsluteymunum verkflæðið.
3. Theory of Straints: Theory of Straints
Höldum áfram að þriðju erkitýpunni: stofnanaþekkingu/„ættbálka“. Að jafnaði, í hvaða stofnun sem er, eru nokkrir sem vita allt og stjórna öllu. Þetta eru þeir sem hafa verið lengst í stofnuninni og þekkja allar lausnir.
Þegar þetta kemur upp á skýringarmyndinni þá fer ég sérstaklega að hringja um slíkt fólk með merki: til dæmis kemur í ljós að ákveðinn Lou er viðstaddur alla fundi. Og mér er ljóst: þetta er staðbundinn Brent. Þegar CIO velur á milli mín í stuttermabol og strigaskóm og stráksins frá IBM í jakkafötum, þá er ég valinn vegna þess að ég get sagt leikstjóranum hluti sem hinn gaurinn mun ekki segja og sem leikstjórinn gæti ekki viljað heyra . Ég segi þeim að flöskuhálsinn í fyrirtæki þeirra sé einhver sem heitir Fred og einhver sem heitir Lou. Þennan flöskuháls þarf að leysa, þekkingu þeirra þarf að fá til þeirra með einum eða öðrum hætti.
Til að leysa svona vandamál get ég til dæmis stungið upp á því að nota Slack. Snjall leikstjóri mun spyrja - hvers vegna? Venjulega, í slíkum tilfellum, svara DevOps ráðgjafar: vegna þess að allir eru að gera það. Ef leikstjórinn er virkilega klár þá segir hann: hvað svo. Og hér lýkur umræðunni. Og svar mitt við þessu er: vegna þess að það eru fjórir flöskuhálsar í fyrirtækinu, Fred, Lou, Susie og Jane. Til að stofnanafesta þekkingu sína verður maður fyrst að kynna Slack. Öll wikis þín eru algjört bull því enginn veit um tilvist þeirra. Ef verkfræðiteymið tekur þátt í framenda- og bakendaþróun og allir þurfa að vita að þeir geta haft samband við framendaþróunarteymið eða innviðateymi með spurningum. Það er þegar Lou eða Fred munu líklega hafa tíma til að taka þátt í wiki. Og svo í Slack gæti einhver spurt hvers vegna, segjum, skref 5 virkar ekki. Og þá munu Lou eða Fred leiðrétta leiðbeiningarnar á wiki. Ef þú kemur þessu ferli á fót, þá mun margt falla á sinn stað af sjálfu sér.
Þetta er aðalatriðið mitt: til að mæla með hátækni, verður þú fyrst að setja grunninn fyrir hana í röð og það er hægt að gera með lágtæknilausnum sem lýst er núna. Ef þú byrjar með hátækni og útskýrir ekki hvers vegna þeirra er þörf, þá endar þetta að jafnaði ekki vel. Einn af viðskiptavinum okkar notar Azure ML, mjög ódýr og einföld lausn. Um 30% spurninga þeirra var svarað af sjálfsnámsvélinni sjálfri. Og þetta var skrifað af rekstraraðilum sem tóku ekki þátt í gagnafræði, tölfræði eða stærðfræði. Þetta er merkilegt. Kostnaður við slíka lausn er í lágmarki.
4. Samstarfsárásir: Samvinnuárásir
Fjórða erkitýpan er þörfin á að berjast gegn einangrun. Þetta vita flestir nú þegar: einangrun elur á fjandskap. Ef hver deild er á sinni hæð, og fólk skerast ekki á nokkurn hátt, nema í lyftunni, þá myndast óvild á milli þeirra mjög auðveldlega. En ef fólk er þvert á móti í sama herbergi við hvert annað fer hún strax. Þegar einhver varpar fram einhverri almennri ásökun, til dæmis, svona og svona viðmót virkar aldrei, þá er ekkert auðveldara að afbyggja slíka ásökun. Forritararnir sem sömdu viðmótið þurfa bara að byrja að spyrja ákveðinna spurninga og fljótlega kemur í ljós að til dæmis var notandinn einfaldlega að nota tólið vitlaust.
Það eru margar leiðir til að sigrast á einangrun. Ég var einu sinni beðinn um að ráðfæra mig við banka í Ástralíu, en ég neitaði að gera það vegna þess að ég á tvö börn og konu. Allt sem ég gat gert til að hjálpa þeim var að mæla með myndrænni frásögn. Þetta er eitthvað sem hefur sannað að virkar. Önnur áhugaverð leið eru kaffifundir. Í stórum stofnunum er þetta frábær kostur til að miðla þekkingu. Að auki geturðu stundað innri devopsdays, hackathons og svo framvegis.
5. Þjálfun Kötu
Eins og ég varaði við strax í upphafi, mun ég ekki tala um þetta í dag. Ef þú hefur áhuga geturðu kíkt .
Það er líka gott erindi um þetta efni frá Mike Rother:
6. Markaðsmiðað: markaðsmiðað skipulag
Hér eru mismunandi vandamá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. Venjulega eru þeir til í stofnunum með einangraðar deildir. „T“ er þegar einstaklingur er góður í einu en líka góður í sumum öðrum hlutum. „E“ eða jafnvel „kambur“ er þegar einstaklingur hefur marga hæfileika.
Lög Conway virka hér (), sem í einfaldasta formi má orða þannig: ef þrjú lið vinna við þýðandann, þá verður útkoman þýðandi úr þremur hlutum. Þess vegna, ef það er mikil einangrun innan stofnunar, þá verður jafnvel Kubernetes, Circuit breaker, API stækkanleiki og aðrir fínir hlutir í þessari stofnun raðað á sama hátt og stofnunin sjálf. Strangt samkvæmt Conway og þrátt fyrir alla unga nörda.
Lausnin á þessu vandamáli hefur margoft verið lýst. Það eru til dæmis skipulagsarkitýpur sem Fernando Fernandez lýsti. Þessi vandræðalegi arkitektúr sem ég var að tala um, með einangrun, er virknimiðaður arkitektúr. Önnur tegundin er sú versta, fylkisarkitektúr, rugl af hinum tveimur. Þriðja er það sem sést í flestum sprotafyrirtækjum og stór fyrirtæki eru líka að reyna að passa þessa tegund. Það er markaðsmiðuð stofnun. Hér fínstillum við til að ná sem hraðastum viðbrögðum við beiðnum viðskiptavina. Þetta er stundum kallað flatt skipulag.
Margir lýsa þessari uppbyggingu á mismunandi hátt, mér finnst orðalagið gott byggja/keyra teymi, hjá Amazon kalla þeir það tvö pizzateymi. Í þessari uppbyggingu er allt fólk af gerðinni „I“ flokkað í kringum eina þjónustu og smám saman verða þeir nær „T“ og ef rétt stjórnun er til staðar geta þeir jafnvel orðið „E“. Fyrsta mótrökin hér eru þau að slík uppbygging innihaldi óþarfa þætti. Af hverju þarf prófara á hverja deild ef hægt er að vera með sérstaka deild prófara? Sem ég svara: aukakostnaðurinn í þessu tilfelli er verðið fyrir alla stofnunina til að verða gerð „E“ í framtíðinni. Í þessari uppbyggingu lærir prófunarmaðurinn smám saman um netkerfi, arkitektúr, hönnun osfrv. Þess vegna er sérhver þátttakandi í stofnuninni fullkomlega meðvitaður um allt sem gerist í stofnuninni. Ef þú vilt vita hvernig þetta kerfi virkar í iðnaði, lestu .
7. Vinstrivakt endurskoðenda: endurskoðun snemma í lotunni. Fylgni við öryggisreglur til sýnis
Þetta er þegar aðgerðir þínar standast ekki lyktarprófið, ef svo má segja. Fólkið sem vinnur fyrir þig er ekki heimskt. Ef, eins og í dæminu hér að ofan, settu þau lítil/engin áhrif alls staðar, þetta entist í þrjú ár, og enginn tók eftir neinu, þá vita allir vel að kerfið virkar ekki. Eða annað dæmi - ráðgjafarnefnd um breytingar, þar sem skila þarf skýrslum til dæmis á hverjum miðvikudegi. Það er hópur fólks sem vinnur þarna (sem sagt ekki mjög vel borgað) sem fræðilega ætti að vita hvernig kerfið í heild sinni virkar. Og undanfarin fimm ár 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 gerðu ekki og vita ekkert um.
Auðvitað virkar þessi aðferð ekki. Ég verð að losa mig við svona hluti því þetta fólk er ekki að verja kerfið. Ákvörðunin verður að vera tekin af liðinu sjálfu, því liðið verður að bera ábyrgð á henni. Annars skapast mótsagnakennd staða þegar stjórnandi sem hefur aldrei skrifað kóða á ævi sinni segir forritaranum hversu langan tíma það eigi að taka að skrifa kóða. Eitt fyrirtæki sem ég vann með voru með 7 mismunandi stjórnir sem fóru yfir hverja breytingu, þar á meðal arkitektúrtöflu, vöruborð osfrv. Það var meira að segja lögboðinn biðtími, þó að einn starfsmaður hafi sagt mér að í tíu ára starfi hefði enginn hafnað breytingu sem þessi maður gerði á þessu lögboðna tímabili.
Það þarf að bjóða endurskoðendum að ganga til liðs við okkur og ekki losna við þá. Segðu þeim að þú skrifir óbreytanleg tvíundarílát sem, ef þau standast öll prófin, haldast óbreytanleg að eilífu. Segðu þeim að þú sért með leiðslu sem kóða og útskýrðu hvað það þýðir. Sýndu þeim eftirfarandi kerfi: óbreytanlegur skrifvarinn tvöfaldur í íláti sem stenst öll varnarleysispróf; og þá ekki bara að enginn snertir það, þeir snerta ekki einu sinni kerfið sem býr til leiðsluna, þar sem það er líka búið til á kraftmikinn hátt. Ég er með viðskiptavini, Capital One, sem nota Vault til að búa til eitthvað eins og blockchain. Endurskoðandinn þarf ekki að sýna „uppskriftir“ frá Chef; það er nóg að sýna blockchain, þar sem ljóst er hvað varð um Jira miðann í framleiðslu og hver ber ábyrgð á honum.
Samkvæmt , búin til árið 2018 af Sonatype, það voru 2017 milljarðar OSS niðurhalsbeiðna árið 87.
Tjónið sem verður vegna veikleika er óhóflegt. Þar að auki innihalda tölurnar sem þú sérð hér að ofan ekki fórnarkostnað. Hvað er DevSecOps í hnotskurn? Leyfðu mér að segja strax að ég hef ekki áhuga á að tala um hversu vel þetta nafn er. Málið er að þar sem DevOps hefur gengið svona vel ættum við að reyna að bæta öryggi við þá leiðslu.
Dæmi um þessa röð:
Þetta er ekki meðmæli fyrir sérstakar vörur, þó ég sé hrifinn af þeim öllum. Ég nefndi þá sem dæmi til að sýna að DevOps, sem var upphaflega byggt á skipulagshugmyndinni í iðnaði, gerir þér kleift að gera sjálfvirkan hvert stig vinnu við vöru.
Og það er engin ástæða fyrir því að við gætum ekki tekið sömu nálgun í öryggismálum.
Samtals
Að lokum mun ég gefa nokkur ráð fyrir DevSecOps. Þú þarft að hafa endurskoðendur með í því ferli að búa til kerfin þín og eyða tíma í að fræða þau. Þú þarft að vinna með endurskoðendum. Næst þarftu að heyja algerlega miskunnarlausa baráttu gegn fölskum jákvæðum. Jafnvel með dýrasta varnarleysisskönnunartækinu geturðu endað með því að búa til afar slæmar venjur meðal þróunaraðila þinna ef þú veist ekki hvert merki/suðhlutfall þitt er. Hönnuðir verða óvart með viðburðum og munu einfaldlega eyða þeim. Ef þú heyrðir um Equifax söguna, þá er það nokkurn veginn það sem gerðist þar, þar sem hæsta viðvörunarstigið var hunsað. Að auki þarf að útskýra veikleika á þann hátt að það sé ljóst hvernig þeir hafa áhrif á viðskiptin. Til dæmis mætti segja að þetta sé sama varnarleysi og í Equifax sögunni. Öryggisveikleika ætti að meðhöndla eins og önnur hugbúnaðarvandamál, það er að segja að þeir ættu að vera með í heildar DevOps ferlinu. Þú þarft að vinna með þeim í gegnum Jira, Kanban osfrv. Hönnuðir ættu ekki að halda að einhver annar geri þetta - þvert á móti ættu allir að gera þetta. Að lokum þarftu að eyða orku í að þjálfa fólk.
gagnlegir krækjur
Hér eru nokkur erindi frá DevOops ráðstefnunni sem þér gæti fundist gagnleg:
- Sergey Berdnikov, Artyom Kalichkin - Árangurssaga, eða „Dev+DevOps+Ops“ (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps á mælikvarða: grískur harmleikur í þremur þáttum (, )
- Alexander Titov, Kirill Tolkachev -
- Timothy Lister -
Skoða DevOops 2020 Moskvu — Það er líka margt áhugavert þarna.
Heimild: www.habr.com