Vprašanje "kako implementirati devops" se pojavlja že leta, vendar ni veliko dobrih materialov. Včasih postanete žrtev oglasov ne preveč pametnih svetovalcev, ki morajo prodati svoj čas, ne glede na to, kako. Včasih so to nejasne, skrajno splošne besede o tem, kako ladje megakorporacij orjejo prostranstva vesolja. Postavlja se vprašanje: kaj nas to briga? Spoštovani avtor, ali lahko jasno oblikujete svoje ideje v obliki seznama?
Vse to izhaja iz dejstva, da se ni nabralo veliko prave prakse in razumevanja rezultatov transformacij kulture podjetja. Spremembe v kulturi so dolgoročne stvari, katerih rezultati se ne bodo pokazali čez teden ali mesec. Potrebujemo nekoga, ki je dovolj star, da bi videl, kako so se podjetja z leti gradila in propadala.
John Willis - eden od očetov DevOps. John ima desetletja izkušenj pri delu z ogromnim številom podjetij. Nedavno je John začel opažati posebne vzorce, ki se pojavljajo pri delu z vsakim od njih. Z uporabo teh arhetipov John vodi podjetja na pravo pot preobrazbe DevOps. Več o teh arhetipih si preberite v prevodu njegovega poročila s konference DevOops 2018.
O govorniku:
Več kot 35 let v upravljanju IT, sodeloval pri ustvarjanju predhodnika OpenCloud pri Canonicalu, sodeloval pri 10 startupih, od katerih sta bila dva prodana Dell in Docker. Trenutno je podpredsednik za DevOps in digitalne prakse pri SJ Technologies.
Sledi zgodba z Janezovega zornega kota.
Moje ime je John Willis in najlažje me najdete na Twitterju, . Isti vzdevek imam na Gmailu in GitHubu. A najdete video posnetke mojih poročil in predstavitev zanje.
Imam veliko sestankov z direktorji informacijskih tehnologij različnih velikih podjetij. Zelo pogosto se pritožujejo, da ne razumejo, kaj je DevOps, in vsak, ki jim poskuša razložiti, govori o nečem drugem. Druga pogosta pritožba je, da DevOps ne deluje, čeprav se zdi, da direktorji delajo vse, kot jim je razloženo. Govorimo o velikih podjetjih, ki so stara več kot sto let. Po pogovoru z njimi sem prišel do zaključka, da za marsikatero težavo ni najprimernejša visoka tehnologija, temveč razmeroma nizkotehnološke rešitve. Več tednov sem se samo pogovarjal z ljudmi iz različnih oddelkov. Kar vidite na prvi sliki v objavi, je moj zadnji projekt, takole je izgledala soba po treh dneh dela.
Kaj je DevOps?
Dejansko, če vprašate 10 različnih ljudi, bodo dali 10 različnih odgovorov. Ampak tukaj je zanimivo: vseh deset teh odgovorov bo pravilnih. Tukaj ni napačnega odgovora. Bil sem precej globoko v DevOps, približno 10 let, in bil sem prvi Američan na prvem DevOpsDay. Ne bom rekel, da sem pametnejši od vseh, ki se ukvarjajo z DevOps, a skoraj ni nikogar, ki bi v to vložil toliko truda. Verjamem, da se DevOps pojavi, ko se združita človeški kapital in tehnologija. Pogosto pozabljamo na človeško dimenzijo, čeprav veliko govorimo o vseh vrstah kultur.
Zdaj imamo veliko podatkov, pet let akademskih raziskav, preizkušanje teorij v industrijskem obsegu. Te študije nam povedo, da če združite nekaj vedenjskih vzorcev v organizacijski kulturi, lahko dosežete 2000-kratno pospešitev. Ta pospešek se ujema z enakim izboljšanjem stabilnosti. To je kvantitativna meritev koristi, ki jih lahko DevOps prinese kateremu koli podjetju. Pred nekaj leti sem o DevOps govoril direktorju podjetja Fortune 5000. Ko sem se pripravljal na predstavitev, sem bil zelo živčen, ker sem moral svoje dolgoletne izkušnje strniti v 5 minut.
Na koncu sem dal naslednje Opredelitev DevOps: Je skupek praks in vzorcev, ki omogočajo transformacijo človeškega kapitala v visoko zmogljiv organizacijski kapital. Primer je način delovanja Toyote v zadnjih 50 ali 60 letih.
(V nadaljevanju taki diagrami niso navedeni kot referenčni material, ampak kot ilustracije. Njihova vsebina se bo razlikovala za vsako novo podjetje. Lahko pa si sliko ogledate ločeno in jo povečate
Ena najuspešnejših tovrstnih praks je vrednost toka kartiranje. O tem je bilo napisanih več dobrih knjig, med katerimi je najuspešnejša Karen Martin. Toda v zadnjem letu sem prišel do zaključka, da je tudi ta pristop preveč visokotehnološki. Vsekakor ima veliko prednosti in veliko sem ga uporabljal. Toda ko vas generalni direktor vpraša, zakaj njegovo podjetje ne more preiti na nove tirnice, je še prezgodaj govoriti o kartiranju toka vrednosti. Obstaja veliko bolj temeljnih vprašanj, na katera je treba najprej odgovoriti.
Mislim, da je napaka mnogih mojih kolegov ta, da podjetju preprosto dajo vodnik v petih točkah, nato pa se čez šest mesecev vrnejo in pogledajo, kaj se je zgodilo. Tudi dobra shema, kot je preslikava toka vrednosti, ima, recimo temu, slepe pege. Po stotinah intervjujev z direktorji različnih podjetij sem razvil določen vzorec, ki nam omogoča, da težavo razdelimo na komponente, zdaj pa bomo razpravljali o vsaki od teh komponent po vrsti. Preden uporabim kakršne koli tehnološke rešitve, uporabim ta vzorec in posledično so vse moje stene prekrite z diagrami. Pred kratkim sem delal z vzajemnim skladom in na koncu sem imel 100–150 takih shem.
Slaba kultura poje dobre pristope za zajtrk
Glavna ideja je naslednja: nobena količina Lean, Agile, SAFE in DevOps ne bo pomagala, če je sama kultura organizacije slaba. To je kot potapljanje v globine brez potapljaške opreme ali delovanje brez rentgena. Z drugimi besedami, če parafraziram Druckerja in Deminga: slaba organizacijska kultura bo pogoltnila vsak dober sistem, ne da bi ga zadušila.
Če želite rešiti to glavno težavo, morate narediti naslednje korake:
- Naj bo vse delo vidno: vse delo moraš narediti vidno. Ne v smislu, da mora biti nujno prikazan na nekem zaslonu, ampak v smislu, da mora biti opazen.
- Konsolidirani sistemi vodenja dela: sisteme upravljanja je treba konsolidirati. Pri problemu »plemenskega« znanja in institucionalnega znanja so v 9 primerih od 10 ozko grlo ljudje. V knjigi težava je bila v eni sami osebi, Brentu, zaradi katere je projekt zamujal tri leta. In povsod naletim na te "Brente". Za razrešitev teh ozkih grl uporabljam naslednja dva elementa na našem seznamu.
- Metodologija teorije omejitev: teorija omejitev.
- Triki za sodelovanje: vdori v sodelovanje.
- Toyota Kata (): O Toyoti Kata ne bom veliko govoril. Če te zanima, na mojem githubu o skoraj vsaki od teh tem.
- Tržno usmerjena organizacija: tržno usmerjena organizacija.
- Shift-levo revizorji: pregled v zgodnjih fazah cikla.
Sodelovati z organizacijo začnem zelo preprosto: grem v podjetje in se pogovorim z zaposlenimi. Kot lahko vidite, brez visoke tehnologije. Vse kar potrebujete je nekaj za pisanje. V eni sobi zberem več ekip in analiziram, kaj mi sporočajo z vidika mojih 7 arhetipov. In potem jim sam dam marker in jih prosim, naj na tablo zapišejo vse, kar so do sedaj povedali na glas. Običajno je na tovrstnih sestankih ena oseba, ki vse zapiše in v najboljšem primeru lahko zapiše 10% razprave. Z mojo metodo se lahko ta številka dvigne na približno 40%.
(To sliko si lahko ogledate ločeno )
Moj pristop temelji na delu Williama Schneiderja. ). Pristop temelji na ideji, da lahko vsako organizacijo razdelimo na štiri kvadrate. Ta shema je zame običajno rezultat dela s tistimi stotinami drugih shem, ki nastanejo pri analizi organizacije. Recimo, da imamo organizacijo z visoko stopnjo nadzora, vendar z nizko usposobljenostjo. To je skrajno nezaželena možnost: ko se vsi držijo črte, a nihče ne ve, kaj storiti.
Nekoliko boljša možnost je možnost z visoko stopnjo nadzora in usposobljenosti. Če je takšno podjetje donosno, potem morda ne potrebuje DevOps. Najbolj zanimivo je sodelovati s podjetjem, ki ima visoko stopnjo nadzora, nizko usposobljenost in sodelovanje, a hkrati visoko stopnjo kulture (kultivacije). To pomeni, da ima podjetje veliko ljudi, ki tam radi delajo, fluktuacija delovne sile pa je nizka.
(To sliko si lahko ogledate ločeno )
Zdi se mi, da metode s togimi smernicami na koncu ovirajo doseganje resnice. Zlasti pri kartiranju toka vrednosti obstaja veliko pravil glede strukturiranja informacij. V zgodnjih fazah dela, o katerih zdaj govorim, teh pravil nihče ne potrebuje. Če človek s markerjem v rokah na tabli opisuje realno stanje v podjetju, je to najboljši način za razumevanje stanja. Take informacije ne pridejo do direktorjev. V tem trenutku je neumno prekiniti osebo in reči, da je kakšno puščico narisal napačno. Na tej stopnji je bolje uporabiti preprosta pravila, na primer: večnivojsko abstrakcijo je mogoče ustvariti preprosto z uporabo večbarvnih markerjev.
Ponavljam, brez visoke tehnologije. Črni marker prikazuje objektivno realnost, kako vse deluje. Z rdečim flomastrom ljudje označijo, kaj jim v trenutnem stanju ni všeč. Važno je, da to pišejo oni, ne jaz. Ko grem k direktorju informatike po sestanku, ne ponudim seznama 10 stvari, ki jih je treba popraviti. Prizadevam si najti povezave med tem, kar govorijo ljudje v podjetju, in obstoječimi preverjenimi vzorci. Na koncu modri označevalec predlaga možne rešitve težave.
(To sliko si lahko ogledate ločeno )
Primer tega pristopa je prikazan zgoraj. V začetku tega leta sem delal z eno banko. Tamkajšnji varnostniki so bili prepričani, da ne bi smeli prihajati na preglede načrtov in zahtev.
(To sliko si lahko ogledate ločeno )
In potem smo se pogovarjali z ljudmi iz drugih oddelkov in izkazalo se je, da so pred približno 8 leti razvijalci programske opreme odpuščali varnostnike, ker so upočasnjevali delo. In potem se je sprevrglo v prepoved, kar je bilo samoumevno. Čeprav v resnici prepovedi ni bilo.
Najino srečanje je potekalo izjemno konfuzno: približno tri ure mi pet različnih ekip ni znalo pojasniti, kaj se dogaja med kodo in sestavom. In to se zdi najpreprostejša stvar. Večina svetovalcev DevOps vnaprej domneva, da to že vsi vedo.
Potem pa je odgovorni za upravljanje informatike, ki je štiri ure molčal, nenadoma oživel, ko smo prišli do njegove teme, in nas zaposlil za zelo dolgo časa. Na koncu sem ga vprašal, kaj meni o srečanju, in njegovega odgovora ne bom nikoli pozabil. Rekel je: "Včasih sem mislil, da ima naša banka samo dva načina za dostavo programske opreme, zdaj pa vem, da jih je pet, za tri pa sploh nisem vedel."
(To sliko si lahko ogledate ločeno )
Zadnji sestanek v tej banki je bil z ekipo investicijske programske opreme. Prav pri njej se je izkazalo, da je pisanje diagramov z markerjem na list papirja boljše kot na tablo in celo boljše kot na pametno tablo.
Fotografije, ki jih vidite, prikazujejo, kako je hotelska konferenčna soba izgledala četrti dan našega srečanja. In te sheme smo uporabili za iskanje vzorcev, torej arhetipov.
Torej, delavcem postavljam vprašanja, oni si odgovore zapišejo s flomastri treh barv (črni, rdeči in modri). Njihove odgovore analiziram za arhetipe. Zdaj pa razpravljajmo o vseh arhetipih po vrstnem redu.
1. Naj bo vse delo vidno: Naj bo delo vidno
Večina podjetij, s katerimi sodelujem, ima zelo visok odstotek neznanega dela. Na primer, to je, ko en zaposleni pride k drugemu in preprosto prosi, naj nekaj naredi. V velikih organizacijah je lahko 60 % nenačrtovanega dela. In do 40% dela ni na noben način dokumentirano. Če bi bil Boeing, se nikoli več v življenju ne bi vkrcal na njihovo letalo. Če je le polovica dela dokumentirana, potem se ne ve, ali je to delo opravljeno pravilno ali ne. Vse druge metode se izkažejo za neuporabne - nima smisla poskušati ničesar avtomatizirati, saj je znanih 50% lahko najbolj skladen in jasen del dela, katerega avtomatizacija ne bo dala velikih rezultatov in vse najslabše stvari so na nevidni polovici. V odsotnosti dokumentacije je nemogoče najti vse vrste vdorov in skritega dela, ne najti ozkih grl, tistih samih "brentov", o katerih sem že govoril. Obstaja čudovita knjiga Dominice DeGrandis . Ona razkriva pet različnih "časovnih uhajanj" (tatovi časa):
- Preveč dela v teku (WIP)
- Neznane odvisnosti
- Nenačrtovano delo
- Nasprotujoče si prioritete
- Zanemarjeno delo
To je zelo dragocena analiza in knjiga je odlična, vendar so vsi ti nasveti neuporabni, če je vidnih le 50% podatkov. Metode, ki jih predlaga Dominica, se lahko uporabljajo, če je dosežena natančnost nad 90 %. Govorim o situacijah, ko šef da podrejenemu 15-minutno nalogo, ta pa mu vzame tri dni; ampak šef pravzaprav ne ve, da je ta podrejeni odvisen od štirih ali petih drugih ljudi.
Projekt Phoenix je čudovita zgodba o projektu, ki je bil tri leta prepozen. Enega od likov zaradi tega čaka odpustitev, sreča pa se z drugim likom, ki je predstavljen kot nekakšen Sokrat. Pomaga ugotoviti, kaj točno je šlo narobe. Izkazalo se je, da ima podjetje enega sistemskega skrbnika, ki mu je ime Brent, in vse delo gre nekako prek njega. Na enem od sestankov enega od podrejenih vprašajo: zakaj vsaka polurna naloga vzame en teden? Odgovor je zelo poenostavljena predstavitev teorije čakalne vrste in Littleovega zakona in v tej predstavitvi se izkaže, da pri 90% zasedenosti vsaka ura dela traja 9 ur. Vsako nalogo je treba poslati sedmim drugim osebam, tako da ta ura postane 63 ur, 7 krat 9. Hočem reči, da če želite uporabiti Littleov zakon ali katero koli zapleteno teorijo čakalne vrste, morate imeti vsaj podatke.
Ko torej govorim o vidljivosti, ne mislim, da je vse na ekranu, ampak da imaš vsaj podatke. Ko to storijo, se pogosto izkaže, da je zelo veliko nenačrtovanega dela, ki se nekako pošlje Brentu, ko ga ni treba. In Brent je super fant, nikoli ne bo rekel ne, vendar nikomur ne pove, kako opravlja svoje delo.
Ko je delo vidno, je mogoče podatke lepo razvrstiti (to počne Dominika na fotografiji), uporabiti abstrakcijo petih časovnih uhajanj in uporabiti avtomatizacijo.
2. Konsolidirajte sisteme za upravljanje dela: Upravljanje nalog
Arhetipi, o katerih govorim, so neke vrste piramide. Če je prvi narejen pravilno, potem je drugi že nekakšen dodatek. Mnogi od teh ne delujejo pri zagonskih podjetjih, vendar jih je treba upoštevati pri večjih podjetjih, kot je Fortune 5000. Zadnje podjetje, za katerega sem delal, je imelo 10 sistemov za izdajanje vozovnic. Ena ekipa je imela Remedy, druga je napisala nekakšen svoj sistem, tretja je uporabljala Jira, nekateri pa so se zadovoljili z e-pošto. Isti problem se pojavi, če ima podjetje 30 različnih cevovodov, vendar nimam časa razpravljati o vseh takih primerih.
Z ljudmi natančno razpravljam o tem, kako so vstopnice ustvarjene, kaj se z njimi zgodi potem in kako se jih zaobide. Najbolj zanimivo pa je, da ljudje na naših srečanjih govorijo čisto iskreno. Vprašal sem, koliko ljudi je označilo "majhen/brez vpliva" na vstopnice, ki bi morale imeti dejansko "velik vpliv". Izkazalo se je, da to počnejo skoraj vsi. Ne ukvarjam se z obtožbami in na vse možne načine poskušam ne identificirati ljudi. Ko mi nekaj iskreno priznajo, osebe ne izdam. Toda ko skoraj vsi zaobidejo sistem, to pomeni, da je vsa varnost v bistvu privlačna. Zato iz podatkov tega sistema ni mogoče sklepati.
Če želite rešiti težavo z vstopnico, morate izbrati en glavni sistem. Če uporabljate Jira, obdržite Jira. Če obstaja kakšna alternativa, naj bo edina. Bistvo je, da je treba vstopnice obravnavati kot še en korak v razvojnem procesu. Vsako dejanje mora imeti vstopnico, ki mora teči skozi razvojni tok dela. Vstopnice se pošljejo ekipi, ki jih objavi na snemalni knjigi in nato prevzame odgovornost zanje.
To velja za vse oddelke, vključno z infrastrukturo in operacijami. V tem primeru je mogoče oblikovati vsaj neko verodostojno predstavo o stanju stvari. Ko je ta postopek vzpostavljen, je nenadoma enostavno ugotoviti, kdo je odgovoren za vsako aplikacijo. Ker zdaj ne prejemamo 50 %, ampak 98 % novih storitev. Če ta osnovni proces deluje, se natančnost izboljša v celotnem sistemu.
Cevovod storitev
To spet velja samo za velike korporacije. Če ste novo podjetje na novem področju, zavihajte rokave in delajte s svojim Travis CI ali CircleCI. Ko gre za podjetja s seznama Fortune 5000, primer, ki se je zgodil v banki, kjer sem delal. Google je prišel do njih in pokazali so jim diagrame starih sistemov IBM. Fantje iz Googla so zmedeno vprašali - kje je izvorna koda za to? Vendar ni izvorne kode, niti GUI. To je realnost, s katero se morajo soočiti velike organizacije: 40 let stari bančni zapisi na starodavnem glavnem računalniku. Ena od mojih strank uporablja vsebnike Kubernetes z vzorci Circuit Breaker in Chaos Monkey, vse za aplikacijo KeyBank. Toda ti vsebniki se na koncu povežejo z aplikacijo COBOL.
Fantje iz Googla so bili popolnoma prepričani, da bodo rešili vse težave moje stranke, potem pa so začeli postavljati vprašanja: kaj je IBM datapipe? Rečeno jim je: to je konektor. S čim se povezuje? V sistem Sperry. In kaj je to? In tako naprej. Na prvi pogled se zdi: kakšen DevOps lahko obstaja? Toda v resnici je to mogoče. Obstajajo sistemi za dostavo, ki vam omogočajo, da potek dela predate ekipam za dostavo.
3. Teorija omejitev: Teorija omejitev
Preidimo k tretjemu arhetipu: institucionalno/»plemensko« znanje. Praviloma je v vsaki organizaciji več ljudi, ki vse vedo in vse upravljajo. To so tisti, ki so v organizaciji najdlje in poznajo vse rešitve.
Ko se to pojavi na diagramu, takšne ljudi posebej obkrožim z oznako: na primer, izkaže se, da je na vseh sestankih prisoten nek Lou. In jasno mi je: to je lokalni Brent. Ko CIO izbira med mano v majici s kratkimi rokavi in supergami ter tipom iz IBM-a v obleki, sem izbran, ker lahko direktorju povem stvari, ki jih drugi ne bo povedal in ki jih direktor morda ne bo želel slišati. . Povem jim, da sta ozko grlo v njihovem podjetju nekdo po imenu Fred in nekdo po imenu Lou. To ozko grlo je treba odvezati, njihovo znanje tako ali drugače pridobiti od njih.
Za rešitev te vrste težav lahko na primer predlagam uporabo Slacka. Pameten direktor se bo vprašal - zakaj? Običajno v takih primerih svetovalci DevOps odgovorijo: ker vsi to počnejo. Če je direktor res pameten, bo rekel: pa kaj. In tu se dialog konča. In moj odgovor na to je: ker so v podjetju štiri ozka grla, Fred, Lou, Susie in Jane. Za institucionalizacijo njihovega znanja je treba najprej uvesti Slack. Vsi vaši wikiji so popolna neumnost, ker nihče ne ve za njihov obstoj. Če je inženirska ekipa vključena v front-end in back-end razvoj in morajo vsi vedeti, da se lahko z vprašanji obrnejo na front-end razvojno ekipo ali infrastrukturno skupino. Takrat bosta Lou ali Fred verjetno imela čas, da se pridružita wikiju. In potem se lahko v Slacku nekdo vpraša, zakaj, recimo, ne deluje korak 5. In potem bo Lou ali Fred popravil navodila na wikiju. Če vzpostaviš ta proces, potem se marsikaj postavi na svoje mesto.
To je moja glavna poanta: če želite priporočiti kakršne koli visoke tehnologije, morate najprej urediti temelje zanje, kar je mogoče storiti s pravkar opisanimi nizkotehnološkimi rešitvami. Če začnete z visokimi tehnologijami in ne pojasnite, zakaj so potrebne, potem se to praviloma ne konča dobro. Ena od naših strank uporablja Azure ML, zelo poceni in preprosto rešitev. Na približno 30 % njihovih vprašanj je odgovoril sam samoučeči se stroj. In to stvar so napisali operaterji, ki se niso ukvarjali s podatkovno znanostjo, statistiko ali matematiko. To je pomembno. Stroški takšne rešitve so minimalni.
4. Collaboration hacks: Collaboration hacks
Četrti arhetip je potreba po boju proti izolaciji. Večina ljudi to že ve: izolacija povzroča sovražnost. Če je vsak oddelek v svojem nadstropju in se ljudje med seboj ne križajo na noben način, razen v dvigalu, potem med njimi zelo zlahka nastane sovražnost. Če pa so, nasprotno, ljudje v isti sobi drug z drugim, takoj odide. Ko nekdo vrže neko splošno obtožbo, na primer tak in tak vmesnik nikoli ne deluje, ni nič lažjega dekonstruirati takšno obtožbo. Programerji, ki so napisali vmesnik, morajo le začeti postavljati konkretna vprašanja in kmalu bo jasno, da je na primer uporabnik orodje preprosto uporabljal nepravilno.
Obstaja veliko načinov za premagovanje izolacije. Nekoč so me prosili za svetovanje za banko v Avstraliji, a sem tega zavrnil, ker imam dva otroka in ženo. Vse, kar sem jim lahko pomagal, je bilo, da sem jim priporočil grafično pripovedovanje zgodb. To je nekaj, kar dokazano deluje. Še en zanimiv način so srečanja ob kavici. V veliki organizaciji je to odlična možnost za širjenje znanja. Poleg tega lahko izvajate interne devopsdaye, hackathone itd.
5. Treniranje kate
Kot sem že na začetku opozoril, danes o tem ne bom govoril. Če vas zanima, si lahko ogledate .
Na to temo je tudi dober govor Mika Rotherja:
6. Tržno usmerjenost: tržno usmerjena organizacija
Tukaj so različne težave. Na primer osebe "I", osebe "T" in osebe "E". "Jaz" ljudje so tisti, ki počnejo samo eno stvar. Običajno obstajajo v organizacijah z izoliranimi oddelki. "T" je, ko je človek dober v eni stvari, dober pa je tudi v nekaterih drugih stvareh. "E" ali celo "glavnik" je, ko ima oseba veliko spretnosti.
Tukaj deluje Conwayev zakon (), kar lahko v najbolj poenostavljeni obliki izrazimo takole: če na prevajalniku delajo tri ekipe, bo rezultat prevajalnik treh delov. Torej, če obstaja visoka stopnja izolacije znotraj organizacije, bodo celo Kubernetes, odklopnik, razširljivost API-ja in druge modne stvari v tej organizaciji urejene na enak način kot organizacija sama. Strogo v skladu s Conwayem in v kljub vsem vam mladim geekom.
Rešitev tega problema je bila večkrat opisana. Obstajajo na primer organizacijski arhetipi, ki jih opisuje Fernando Fernandez. Ta problematična arhitektura, o kateri sem pravkar govoril, z izolacijo, je funkcijsko usmerjena arhitektura. Druga vrsta je najslabša, matrična arhitektura, zmešnjava drugih dveh. Tretji je tisti, ki ga opazimo pri večini startupov, temu tipu pa se skušajo ujemati tudi velika podjetja. Je tržno usmerjena organizacija. Tukaj optimiziramo, da dosežemo najhitrejši odziv na zahteve strank. To včasih imenujemo ravna organizacija.
Veliko ljudi opisuje to strukturo na različne načine, meni je všeč besedilo zgraditi/voditi ekipe, pri Amazonu temu rečejo dve ekipi picerjev. V tej strukturi so vsi ljudje tipa »I« združeni okoli ene službe in se postopoma približujejo tipu »T«, ob pravilnem upravljanju pa lahko postanejo celo »E«. Prvi protiargument je, da takšna struktura vsebuje nepotrebne elemente. Zakaj potrebujete preizkuševalca v vsakem oddelku, če lahko imate poseben oddelek preizkuševalcev? Na kar odgovarjam: dodatni stroški so v tem primeru cena, da celotna organizacija v prihodnosti postane tip "E". V tej strukturi preizkuševalec postopoma spoznava omrežja, arhitekturo, dizajn itd. Posledično je vsak udeleženec v organizaciji popolnoma seznanjen z vsem, kar se v organizaciji dogaja. Če želite izvedeti, kako ta shema deluje v industriji, preberite .
7. Shift-left revizorji: revizija zgodaj v ciklu. Skladnost z varnostnimi pravili na zaslonu
Takrat vaša dejanja tako rekoč ne prestanejo testa vonja. Ljudje, ki delajo za vas, niso neumni. Če, kot v zgornjem primeru, povsod določijo minor/brez vpliva, to je trajalo tri leta, pa nihče ni opazil ničesar, potem vsi dobro vedo, da sistem ne deluje. Ali drug primer - svetovalni odbor za spremembe, kjer je treba poročila oddati vsako, recimo, sredo. Tam dela skupina ljudi (mimogrede, ne prav dobro plačanih), ki bi teoretično morali vedeti, kako deluje sistem kot celota. In v zadnjih petih letih ste verjetno opazili, da so naši sistemi neverjetno zapleteni. In pet ali šest ljudi se mora odločiti o spremembi, ki je niso naredili in o kateri ne vedo ničesar.
Seveda ta pristop ne deluje. Takih stvari se moram znebiti, ker ti ljudje ne varujejo sistema. Odločitev mora sprejeti ekipa sama, saj mora ekipa za to odgovarjati. V nasprotnem primeru nastane paradoksalna situacija, ko vodja, ki še nikoli v življenju ni pisal kode, programerju pove, koliko časa naj traja pisanje kode. Eno podjetje, s katerim sem delal, je imelo 7 različnih odborov, ki so pregledali vsako spremembo, vključno z odborom za arhitekturo, odborom za izdelke itd. Bila je celo obvezna čakalna doba, čeprav mi je en zaposleni povedal, da v desetih letih dela še nihče ni zavrnil spremembe, ki jo je ta oseba naredila v tej obvezni dobi.
Revizorje je treba povabiti k nam, ne pa se jih znebiti. Povejte jim, da pišete nespremenljive binarne vsebnike, ki ostanejo nespremenljivi za vedno, če prestanejo vse preizkuse. Povejte jim, da imate cevovod kot kodo in pojasnite, kaj to pomeni. Pokažite jim naslednjo shemo: nespremenljiva dvojiška datoteka samo za branje v vsebniku, ki prestane vse teste ranljivosti; in potem ne samo, da se ga nihče ne dotakne, ne dotaknejo se niti sistema, ki ustvarja cevovod, saj je tudi ta ustvarjen dinamično. Imam stranke, Capital One, ki uporabljajo Vault za ustvarjanje nečesa podobnega blockchainu. Revizorju ni treba pokazati "receptov" od Chefa, dovolj je pokazati blockchain, iz katerega je razvidno, kaj se je zgodilo z vstopnico Jira v proizvodnji in kdo je odgovoren za to.
Glede na , ki ga je leta 2018 ustvaril Sonatype, je bilo leta 2017 87 milijard zahtev za prenos OSS.
Izgube, nastale zaradi ranljivosti, so previsoke. Poleg tega številke, ki jih zdaj vidite zgoraj, ne vključujejo oportunitetnih stroškov. Kaj je DevSecOps na kratko? Naj takoj povem, da me ne zanima, kako uspešno je to ime. Bistvo je, da bi morali poskusiti temu cevovodu dodati varnost, ker je bil DevOps tako uspešen.
Primer tega zaporedja:
To ni priporočilo za določene izdelke, čeprav so mi vsi všeč. Navedel sem jih kot primer, da pokažem, da DevOps, ki je sprva temeljil na organizacijski paradigmi v industriji, omogoča avtomatizacijo vseh faz dela na izdelku.
In ni razloga, zakaj ne bi mogli uporabiti enakega pristopa k varnosti.
Skupaj
Za zaključek bom dal nekaj nasvetov za DevSecOps. V proces ustvarjanja vaših sistemov morate vključiti revizorje in porabiti čas za njihovo izobraževanje. Morate sodelovati z revizorji. Nato se morate popolnoma neusmiljeno boriti proti lažnim pozitivnim rezultatom. Tudi z najdražjim orodjem za skeniranje ranljivosti lahko na koncu ustvarite izjemno slabe navade med razvijalci, če ne veste, kakšno je vaše razmerje med signalom in šumom. Razvijalci bodo preobremenjeni z dogodki in jih bodo preprosto izbrisali. Če ste slišali za zgodbo o Equifaxu, se je skoraj to zgodilo tam, kjer je bila najvišja stopnja opozorila prezrta. Poleg tega je treba ranljivosti razložiti tako, da bo jasno, kako vplivajo na poslovanje. Lahko bi na primer rekli, da gre za isto ranljivost kot v zgodbi o Equifaxu. Varnostne ranljivosti je treba obravnavati enako kot druge težave s programsko opremo, kar pomeni, da jih je treba vključiti v celoten proces DevOps. Z njimi morate delati prek Jire, Kanbana itd. Razvijalci naj ne mislijo, da bo to naredil nekdo drug - ravno nasprotno, to bi morali storiti vsi. Nazadnje, energijo morate porabiti za usposabljanje ljudi.
Uporabne povezave
Tukaj je nekaj govorov s konference DevOops, ki bi se vam lahko zdeli koristni:
- Sergey Berdnikov, Artyom Kalichkin - Zgodba o uspehu ali "Dev+DevOps+Ops" (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps v merilu: grška tragedija v treh dejanjih (, )
- Aleksander Titov, Kiril Tolkačov -
- Timothy Lister -
Poglej v DevOops 2020 Moskva — tam je tudi veliko zanimivih stvari.
Vir: www.habr.com