Pitanje "kako implementirati devops" postoji godinama, ali nema mnogo dobrih materijala. Ponekad postanete žrtva reklama ne tako pametnih konzultanata koji moraju prodati svoje vrijeme, bez obzira kako. Ponekad su to nejasne, krajnje općenite riječi o tome kako brodovi megakorporacija plove prostranstvima svemira. Postavlja se pitanje: što se to nas tiče? Poštovani autoru, možete li svoje ideje jasno formulirati u popis?
Sve to proizlazi iz činjenice da se nije nakupilo puno stvarne prakse i razumijevanja ishoda transformacija kulture poduzeća. Promjene u kulturi su dugoročne stvari, čiji se rezultati neće pokazati za tjedan ili mjesec dana. Treba nam netko dovoljno star da vidi kako su se tvrtke gradile i propadale tijekom godina.
John Willis - jedan od očeva DevOps-a. John ima desetljeća iskustva u radu s velikim brojem tvrtki. Nedavno je John počeo primjećivati specifične obrasce koji se odvijaju u radu sa svakim od njih. Koristeći te arhetipove, John vodi tvrtke na pravi put DevOps transformacije. Više o ovim arhetipovima pročitajte u prijevodu njegova izvješća s DevOops 2018 konferencije.
O govorniku:
Više od 35 godina u IT menadžmentu, sudjelovao u stvaranju prethodnika OpenClouda u Canonicalu, sudjelovao u 10 startupova, od kojih su dva prodana Dellu i Dockeru. Trenutačno je potpredsjednik DevOps i digitalne prakse u SJ Technologies.
Slijedi priča iz Johnova gledišta.
Moje ime je John Willis i najlakše me možete pronaći na Twitteru, . Imam isti alias na Gmailu i GitHubu. A možete pronaći video zapise mojih izvješća i prezentacija za njih.
Imam mnogo sastanaka s CIO-ovima raznih velikih kompanija. Često se žale da ne razumiju što je DevOps, a svi koji im to pokušaju objasniti pričaju o nečem drugom. Još jedna česta zamjerka je da DevOps ne radi, iako se čini da direktori rade sve kako im je objašnjeno. Riječ je o velikim tvrtkama starim više od sto godina. Nakon razgovora s njima došao sam do zaključka da za mnoge probleme nije najbolja visoka tehnologija, već relativno niskotehnološka rješenja. Tjednima sam samo razgovarao s ljudima iz različitih odjela. Ovo što vidite na prvoj slici u postu je moj zadnji projekt, ovako je soba izgledala nakon tri dana rada.
Što je DevOps?
Zaista, ako pitate 10 različitih ljudi, oni će dati 10 različitih odgovora. Ali evo zanimljivosti: svih deset odgovora bit će točni. Ovdje nema pogrešnog odgovora. Bio sam prilično duboko u DevOps-u, oko 10 godina, i bio sam prvi Amerikanac na prvom DevOpsDayu. Neću reći da sam pametniji od svih uključenih u DevOps, ali teško da postoji netko tko je uložio toliko truda u to. Vjerujem da se DevOps događa kada se ljudski kapital i tehnologija spoje. Često zaboravljamo na ljudsku dimenziju, iako puno govorimo o svim vrstama kultura.
Sada imamo mnogo podataka, pet godina akademskog istraživanja, testiranja teorija na industrijskoj razini. Ono što nam ove studije govore jest da ako kombinirate neke obrasce ponašanja u organizacijskoj kulturi, možete postići 2000x ubrzanje. Ovo ubrzanje prati jednako poboljšanje stabilnosti. Ovo je kvantitativno mjerenje koristi koju DevOps može donijeti svakoj tvrtki. Prije par godina razgovarao sam o DevOps-u s direktorom tvrtke s liste Fortune 5000. Kad sam se pripremao za prezentaciju, bio sam jako nervozan jer sam svoje dugogodišnje iskustvo morao sažeti u 5 minuta.
Na kraju sam dao sljedeće Definicija DevOps-a: To je skup praksi i obrazaca koji omogućuju transformaciju ljudskog kapitala u organizacijski kapital visokih performansi. Primjer je način na koji je Toyota poslovala posljednjih 50 ili 60 godina.
(U daljnjem tekstu takvi dijagrami nisu navedeni kao referentni materijal, već kao ilustracije. Njihov sadržaj će se razlikovati za svaku novu tvrtku. Međutim, sliku je moguće pogledati zasebno i povećati
Jedna od najuspješnijih takvih praksi je mapiranje vrijednosti toka vrijednosti. O tome je napisano nekoliko dobrih knjiga, od kojih je najuspješnija Karen Martin. Ali tijekom prošle godine došao sam do zaključka da je čak i ovaj pristup previše visokotehnološki. Svakako ima mnogo prednosti i ja sam ga puno koristio. Ali kada vas izvršni direktor pita zašto se njegova tvrtka ne može prebaciti na nove tračnice, prerano je govoriti o mapiranju toka vrijednosti. Postoje mnoga temeljnija pitanja na koja se prvo mora odgovoriti.
Mislim da je pogreška koju mnogi moji kolege rade ta što tvrtki jednostavno daju vodič u pet točaka, a zatim se vrate šest mjeseci kasnije i vide što se dogodilo. Čak i dobra shema poput mapiranja toka vrijednosti ima, recimo, slijepe točke. Nakon stotina intervjua s direktorima raznih tvrtki, razvio sam određeni obrazac koji nam omogućuje da problem razložimo na njegove komponente, a sada ćemo raspravljati o svakoj od tih komponenti redom. Prije primjene bilo kakvih tehnoloških rješenja, koristim ovaj uzorak, a kao rezultat toga, svi su mi zidovi prekriveni dijagramima. Nedavno sam radio s uzajamnim fondom i na kraju sam imao 100-150 takvih shema.
Loša kultura jede dobre pristupe za doručak
Glavna ideja je sljedeća: nikakva količina Lean, Agile, SAFE i DevOps neće pomoći ako je sama kultura organizacije loša. To je kao da ronite na dubine bez ronilačke opreme ili radite bez rendgenske snimke. Drugim riječima, da parafraziramo Druckera i Deminga: loša organizacijska kultura će progutati svaki dobar sustav, a da ga ne uguši.
Da biste riješili ovaj glavni problem, morate poduzeti sljedeće korake:
- Učini sav posao vidljivim: morate sav posao učiniti vidljivim. Ne u smislu da nužno mora biti prikazan na nekom ekranu, već u smislu da mora biti vidljiv.
- Konsolidirani sustavi upravljanja radom: potrebno je konsolidirati sustave upravljanja. U problemu “plemenskog” znanja i institucionalnog znanja, u 9 od 10 slučajeva usko grlo su ljudi. U knjizi problem je bio s jednom jedinom osobom, Brentom, zbog koje je projekt kasnio tri godine. I posvuda nailazim na ove "Brente". Kako bih riješio ta uska grla, koristim sljedeće dvije stavke na našem popisu.
- Metodologija teorije ograničenja: teorija ograničenja.
- Hakovi za suradnju: kolaboracijski hakovi.
- Toyota Kata (): Neću puno pričati o Toyoti Kata. Ako ste zainteresirani, na mom githubu o gotovo svakoj od ovih tema.
- Tržišno orijentirana organizacija: tržišno orijentirana organizacija.
- Shift-lijevo revizori: revizija u ranim fazama ciklusa.
S organizacijom počinjem raditi vrlo jednostavno: odem u tvrtku i razgovaram sa zaposlenicima. Kao što vidite, nema visoke tehnologije. Sve što trebate je nešto na čemu ćete pisati. Okupljam nekoliko timova u jednoj prostoriji i analiziram ono što mi govore iz perspektive mojih 7 arhetipova. A onda im samima dam marker i tražim da na ploču zapišu sve što su do sada naglas rekli. Obično na ovakvim sastancima postoji jedna osoba koja sve zapisuje, au najboljem slučaju može zapisati 10% rasprave. Mojom se metodom ta brojka može podići na oko 40%.
(Ova se ilustracija može pogledati zasebno )
Moj se pristup temelji na radu Williama Schneidera. ). Pristup se temelji na ideji da se svaka organizacija može podijeliti na četiri kvadrata. Ova je shema za mene obično rezultat rada sa stotinama drugih shema koje se pojavljuju pri analizi organizacije. Pretpostavimo da imamo organizaciju s visokom razinom kontrole, ali s niskom kompetencijom. Ovo je krajnje nepoželjna opcija: kada svi idu na crtu, ali nitko ne zna što učiniti.
Nešto bolja opcija je ona s visokom razinom kontrole i kompetencije. Ako je takva tvrtka profitabilna, onda možda ne treba DevOps. Najzanimljivije je raditi s tvrtkom koja ima visoku razinu kontrole, nisku kompetentnost i kooperativnost, ali u isto vrijeme visoku razinu kulture (kultiviranja). To znači da tvrtka ima mnogo ljudi koji tamo vole raditi i da je fluktuacija radne snage mala.
(Ova se ilustracija može pogledati zasebno )
Čini mi se da metode s krutim smjernicama na kraju staju na put do istine. Posebno u mapiranju toka vrijednosti postoje mnoga pravila o tome kako bi informacije trebale biti strukturirane. U ranim fazama rada, o kojima sada govorim, ova pravila nikome ne trebaju. Ako osoba s markerom u rukama na ploči opisuje stvarno stanje u poduzeću, to je najbolji način da shvatite stanje stvari. Takve informacije ne dolaze do direktora. U ovom trenutku glupo je prekidati osobu i reći da je krivo nacrtao neku strelicu. U ovoj fazi bolje je koristiti jednostavna pravila, na primjer: apstrakcija na više razina može se stvoriti jednostavno korištenjem višebojnih markera.
Ponavljam, nema visoke tehnologije. Crni marker prikazuje objektivnu stvarnost kako sve funkcionira. Crvenim markerom ljudi označavaju što im se ne sviđa u trenutnom stanju stvari. Bitno je da oni ovo napišu, a ne ja. Kad odem CIO-u nakon sastanka, ne ponudim popis od 10 stvari koje treba popraviti. Nastojim pronaći veze između onoga što ljudi u tvrtki govore i postojećih dokazanih obrazaca. Na kraju, plavi marker predlaže moguća rješenja problema.
(Ova se ilustracija može pogledati zasebno )
Primjer ovog pristupa sada je prikazan gore. Početkom ove godine radio sam s jednom bankom. Tamošnji ljudi iz sigurnosti bili su uvjereni da ne bi trebali dolaziti na pregled dizajna i zahtjeva.
(Ova se ilustracija može pogledati zasebno )
A onda smo razgovarali s ljudima iz drugih odjela i pokazalo se da su prije nekih 8 godina programeri softvera otpuštali zaštitare jer su usporavali rad. A onda se to pretvorilo u zabranu, što se podrazumijevalo. Iako u stvarnosti zabrane nije bilo.
Naš sastanak tekao je krajnje zbunjujuće: oko tri sata pet različitih timova nije mi moglo objasniti što se događa između koda i sklopa. A ovo bi se činilo najjednostavnijim. Većina DevOps konzultanata unaprijed pretpostavlja da svi to već znaju.
Tada je osoba zadužena za upravljanje informatikom, koja je šutjela puna četiri sata, odjednom živnula kad smo došli do njegove teme i zaokupila nas jako dugo. Na kraju sam ga pitao što misli o susretu, a njegov odgovor nikada neću zaboraviti. Rekao je: “Prije sam mislio da naša banka ima samo dva načina isporuke softvera, ali sada znam da ih ima pet, a za tri nisam ni znao.”
(Ova se ilustracija može pogledati zasebno )
Posljednji sastanak u ovoj banci bio je s timom za investicijski softver. Upravo se kod nje pokazalo da je pisanje dijagrama markerom na listu bolje nego na ploči, pa čak i bolje nego na pametnoj ploči.
Fotografije koje vidite prikazuju kako je hotelska konferencijska dvorana izgledala četvrtog dana našeg sastanka. I koristili smo te sheme za traženje obrazaca, odnosno arhetipova.
Dakle, postavljam pitanja radnicima, oni zapisuju odgovore markerima u tri boje (crni, crveni i plavi). Analiziram njihove odgovore u potrazi za arhetipovima. Sada raspravimo redom sve arhetipove.
1. Učinite sav posao vidljivim: Učinite posao vidljivim
Većina tvrtki s kojima radim ima vrlo visok postotak nepoznatih poslova. Na primjer, to je kada jedan zaposlenik dođe drugome i jednostavno traži da nešto učini. U velikim organizacijama može biti 60% neplaniranog posla. A do 40% radova nije dokumentirano ni na koji način. Da je u pitanju Boeing, nikad se više u životu ne bih ukrcao na njihov avion. Ako je samo pola posla dokumentirano, onda se ne zna radi li se taj posao kako treba ili ne. Sve druge metode pokazuju se beskorisnim - nema smisla pokušavati bilo što automatizirati, jer poznatih 50% može biti najsuvisliji i najjasniji dio posla, čija automatizacija neće dati velike rezultate, a sve najgore stvari su u nevidljivoj polovici. U nedostatku dokumentacije, nemoguće je pronaći sve vrste hakova i skrivenih radova, a ne pronaći uska grla, one iste "Brente" o kojima sam već govorio. Postoji divna knjiga Dominice DeGrandis . Ona otkriva pet različitih "curenja vremena" (kradljivci vremena):
- Previše posla u tijeku (WIP)
- Nepoznate ovisnosti
- Neplanirani rad
- Konfliktni prioriteti
- Zapušten rad
Ovo je vrlo vrijedna analiza i knjiga je izvrsna, ali svi ovi savjeti su beskorisni ako je vidljivo samo 50% podataka. Metode koje predlaže Dominica mogu se koristiti ako se postigne točnost iznad 90%. Govorim o situacijama kada šef podređenom zada zadatak od 15 minuta, a za to mu treba tri dana; ali šef zapravo ne zna da je taj podređeni ovisan o još četiri ili pet ljudi.
Projekt Phoenix je prekrasna priča o projektu koji je zakasnio tri godine. Jedan od likova zbog toga se suočava s otkazom, a susreće se s drugim likom koji je predstavljen kao svojevrsni Sokrat. On pomaže otkriti što je točno pošlo po zlu. Ispostavilo se da tvrtka ima jednog sistem administratora, koji se zove Brent, i sav posao nekako ide preko njega. Na jednom od sastanaka, jednog od podređenih pitaju: zašto svaki zadatak od pola sata traje tjedan dana? Odgovor je vrlo pojednostavljena prezentacija teorije čekanja i Littleovog zakona, au ovoj prezentaciji ispada da pri 90% popunjenosti svaki sat rada traje 9 sati. Svaki zadatak treba poslati sedmero drugih ljudi, tako da taj sat postaje 63 sata, 7 puta 9. Ono što želim reći je da ako želite koristiti Littleov zakon ili bilo koju složenu teoriju čekanja u redu, trebate barem imati podatke.
Dakle, kada govorim o vidljivosti, ne mislim da je sve na ekranu, nego da barem imate podatke. Kada to učine, često se ispostavi da postoji vrlo velika količina neplaniranog posla koji se nekako šalje Brentu kada za to nema potrebe. A Brent je super dečko, nikad neće reći ne, ali nikome ne govori kako radi svoj posao.
Kada je rad vidljiv, podaci se mogu uredno klasificirati (to Dominika radi na fotografiji), može se primijeniti apstrakcija pet vremenskih curenja i može se primijeniti automatizacija.
2. Konsolidirajte sustave upravljanja radom: Upravljanje zadacima
Arhetipovi o kojima govorim su svojevrsne piramide. Ako je prvi ispravno izveden, onda je drugi već neka vrsta dodatka. Mnogi od njih ne rade za startupove, treba ih imati na umu za veće tvrtke kao što je Fortune 5000. Posljednja tvrtka za koju sam radio imala je 10 sustava za izdavanje ulaznica. Jedan tim je imao Remedy, drugi je napisao neku vrstu vlastitog sustava, treći je koristio Jira, a neki su se zadovoljili e-poštom. Isti problem se javlja ako tvrtka ima 30 različitih cjevovoda, ali nemam vremena raspravljati o svim takvim slučajevima.
Razgovaram s ljudima o tome kako točno nastaju ulaznice, što se s njima sljedeće događa i kako ih se zaobilazi. Najzanimljivije je to što ljudi na našim sastancima govore sasvim iskreno. Pitao sam koliko je ljudi stavilo "manji/bez utjecaja" na karte kojima bi se zapravo trebao dati "veliki utjecaj". Pokazalo se da to rade gotovo svi. Ne bavim se denunciranjem i pokušavam na sve moguće načine ne identificirati ljude. Kad mi nešto iskreno priznaju, ne odam osobu. Ali kada gotovo svi zaobiđu sustav, to znači da je sva sigurnost u biti samo uljepšavanje. Stoga se iz podataka ovog sustava ne mogu izvući zaključci.
Da biste riješili problem karata, trebate odabrati jedan glavni sustav. Ako koristite Jira, zadržite Jira. Ako postoji neka alternativa, neka bude jedina. Zaključak je da ulaznice treba promatrati kao još jedan korak u procesu razvoja. Svaka radnja mora imati ulaznicu koja mora proći kroz radni tijek razvoja. Ulaznice se šalju timu koji ih objavljuje na ploči scenarija i zatim preuzima odgovornost za njih.
To se odnosi na sve odjele, uključujući infrastrukturu i operacije. U ovom slučaju, moguće je stvoriti barem neku uvjerljivu ideju o stanju stvari. Nakon što se ovaj proces uspostavi, odjednom postaje lako identificirati tko je odgovoran za svaku aplikaciju. Jer sada ne primamo 50%, nego 98% novih usluga. Ako ovaj osnovni proces funkcionira, točnost se poboljšava u cijelom sustavu.
Cjevovod usluga
Ovo se opet odnosi samo na velike korporacije. Ako ste nova tvrtka u novom području, zasučite rukave i radite sa svojim Travis CI ili CircleCI. Kad je riječ o kompanijama s liste Fortune 5000, primjer koji se dogodio u banci u kojoj sam radio. Došao im je Google i pokazali su im dijagrame starih IBM sustava. Dečki iz Googlea su zbunjeno pitali - gdje je izvorni kod za ovo? Ali ne postoji izvorni kod, čak ni GUI. Ovo je stvarnost s kojom se velike organizacije moraju nositi: 40 godina stari bankovni zapisi na drevnom glavnom računalu. Jedan od mojih klijenata koristi Kubernetes spremnike s obrascima Circuit Breaker, plus Chaos Monkey, sve za aplikaciju KeyBank. Ali ti se spremnici u konačnici povezuju s COBOL aplikacijom.
Dečki iz Googlea bili su potpuno uvjereni da će riješiti sve probleme mog klijenta, a onda su počeli postavljati pitanja: što je IBM datapipe? Rečeno im je: ovo je konektor. Na što se to povezuje? Sperry sustavu. A što je to? I tako dalje. Na prvi pogled se čini: kakav DevOps može biti? Ali zapravo je moguće. Postoje sustavi isporuke koji vam omogućuju da tijek rada predate timovima za dostavu.
3. Teorija ograničenja: Teorija ograničenja
Prijeđimo na treći arhetip: institucionalno/"plemensko" znanje. U pravilu, u svakoj organizaciji postoji nekoliko ljudi koji znaju sve i upravljaju svime. To su oni koji su najdulje u organizaciji i koji znaju sva rješenja.
Kad se to pojavi na dijagramu, takve ljude posebno zaokružim flomasterom: na primjer, ispadne da je na svim sastancima prisutan izvjesni Lou. I jasno mi je: ovo je domaći Brent. Kad CIO bira između mene u majici kratkih rukava i tenisicama i tipa iz IBM-a u odijelu, ja sam odabran jer direktoru mogu reći stvari koje drugi neće reći i koje direktor možda ne voli čuti . Kažem im da su usko grlo u njihovoj tvrtki netko tko se zove Fred i netko tko se zove Lou. To usko grlo treba odriješiti, njihovo znanje treba dobiti od njih na ovaj ili onaj način.
Za rješavanje ovakvog problema mogu, na primjer, predložiti korištenje Slacka. Pametan direktor pitat će se – zašto? Tipično, u takvim slučajevima, DevOps konzultanti odgovaraju: jer svi to rade. Ako je redatelj baš pametan, reći će: pa što. I tu dijalog prestaje. A moj odgovor na ovo je: jer postoje četiri uska grla u tvrtki, Fred, Lou, Susie i Jane. Da bi se njihovo znanje institucionaliziralo, prvo se mora uvesti Slack. Svi vaši wikiji su potpuna besmislica jer nitko ne zna za njihovo postojanje. Ako je inženjerski tim uključen u front-end i back-end razvoj i svi trebaju znati da se s pitanjima mogu obratiti front-end razvojnom timu ili infrastrukturnom timu. Tada će Lou ili Fred vjerojatno imati vremena pridružiti se wikiju. A onda u Slacku netko može pitati zašto, recimo, ne radi korak 5. I onda će Lou ili Fred ispraviti upute na wikiju. Ako uspostavite taj proces, onda će puno stvari doći na svoje mjesto.
Ovo je moja glavna poanta: da biste preporučili bilo koju visoku tehnologiju, prvo morate postaviti temelje za njih u red, a to se može učiniti s upravo opisanim niskotehnološkim rješenjima. Ako počnete s visokim tehnologijama i ne objasnite zašto su potrebne, onda to u pravilu ne završi dobro. Jedan od naših klijenata koristi Azure ML, vrlo jeftino i jednostavno rješenje. Na oko 30% njihovih pitanja odgovorio je sam samoučeći stroj. A ovo su napisali operateri koji nisu bili uključeni u znanost o podacima, statistiku ili matematiku. Ovo je značajno. Trošak takvog rješenja je minimalan.
4. Hakovi za suradnju: Hakovi za suradnju
Četvrti arhetip je potreba za borbom protiv izolacije. Većina ljudi to već zna: izolacija rađa neprijateljstvo. Ako je svaki odjel na svom katu, a ljudi se ni na koji način ne susreću jedni s drugima, osim u dizalu, tada vrlo lako nastaje neprijateljstvo među njima. Ali ako su, naprotiv, ljudi u istoj prostoriji jedni s drugima, ona odmah odlazi. Kad netko izbaci neku generalnu optužbu, na primjer, takvo i takvo sučelje nikad ne radi, nema ništa lakše dekonstruirati takvu optužbu. Programeri koji su napisali sučelje trebaju samo početi postavljati konkretna pitanja i uskoro će postati jasno da je, na primjer, korisnik jednostavno pogrešno koristio alat.
Postoji mnogo načina za prevladavanje izolacije. Jednom su me zamolili da se savjetujem za banku u Australiji, ali sam to odbio jer imam dvoje djece i ženu. Sve što sam mogao učiniti da im pomognem bilo je preporučiti grafičko pripovijedanje. Ovo je nešto što dokazano djeluje. Još jedan zanimljiv način su lean coffee sastanci. U velikoj organizaciji ovo je izvrsna opcija za širenje znanja. Osim toga, možete provoditi interne devopsdays, hackathone i tako dalje.
5. Treniranje kate
Kao što sam upozorio na samom početku, danas neću o tome. Ako ste zainteresirani, možete pogledati .
Postoji i dobar govor o ovoj temi od Mikea Rothera:
6. Tržišno orijentirana: tržišno orijentirana organizacija
Tu postoje različiti problemi. Na primjer, osobe "I", osobe "T" i osobe "E". “Ja” ljudi su oni koji rade samo jednu stvar. Obično postoje u organizacijama s izoliranim odjelima. "T" je kada je osoba dobra u jednoj stvari, ali je dobra i u nekim drugim stvarima. "E" ili čak "češalj" je kada osoba ima mnogo vještina.
Ovdje vrijedi Conwayev zakon (), što se u najjednostavnijem obliku može izraziti na sljedeći način: ako na kompilatoru rade tri tima, rezultat će biti kompilator od tri dijela. Stoga, ako postoji visoka razina izolacije unutar organizacije, tada će čak i Kubernetes, prekidač strujnog kruga, proširivost API-ja i druge otmjene stvari u ovoj organizaciji biti uređene na isti način kao i sama organizacija. Strogo prema Conwayu i u inat svim vama mladim štreberima.
Rješenje ovog problema opisano je više puta. Postoje, na primjer, organizacijski arhetipovi koje opisuje Fernando Fernandez. Ta problematična arhitektura o kojoj sam upravo govorio, s izolacijom, je funkcionalno orijentirana arhitektura. Drugi tip je najgori, matrix arhitektura, zbrka druga dva. Treće je ono što se vidi u većini startupa, a velike tvrtke također pokušavaju parirati ovom tipu. To je tržišno orijentirana organizacija. Ovdje optimiziramo kako bismo postigli najbrži odgovor na zahtjeve kupaca. Ovo se ponekad naziva ravnom organizacijom.
Mnogi ljudi opisuju ovu strukturu na različite načine, sviđa mi se formulacija izgraditi/voditi timove, u Amazonu to zovu dva pizza tima. U ovoj strukturi svi ljudi tipa “I” grupirani su oko jedne službe, a postupno se približavaju tipu “T”, a ako postoji pravi menadžment, mogu postati i “E”. Prvi protuargument ovdje je da takva struktura ima nepotrebne elemente. Zašto vam treba tester u svakom odjelu ako možete imati poseban odjel testera? Na što odgovaram: dodatni troškovi u ovom slučaju su cijena da cijela organizacija u budućnosti postane tip “E”. U ovoj strukturi ispitivač postupno uči o mrežama, arhitekturi, dizajnu itd. Kao rezultat toga, svaki sudionik u organizaciji je potpuno svjestan svega što se događa u organizaciji. Ako želite znati kako ova shema funkcionira u industriji, pročitajte .
7. Auditori pomaka ulijevo: revizija rano u ciklusu. Sukladnost sa sigurnosnim pravilima na zaslonu
Ovo je kada vaše radnje ne prolaze test mirisa, da tako kažem. Ljudi koji rade za vas nisu glupi. Ako su, kao u gornjem primjeru, posvuda postavili minor/bez utjecaja, to je trajalo tri godine, a nitko ništa nije primijetio, onda svi dobro znaju da sustav ne funkcionira. Ili drugi primjer - savjetodavni odbor za promjene, gdje se svake, recimo, srijede trebaju podnositi izvješća. Tamo radi skupina ljudi (usput rečeno, ne baš dobro plaćena) koja bi, teoretski, trebala znati kako funkcionira sustav u cjelini. A tijekom proteklih pet godina vjerojatno ste primijetili da su naši sustavi nevjerojatno složeni. A pet-šest ljudi mora donijeti odluku o promjeni koju nisu donijeli i o kojoj ništa ne znaju.
Naravno, ovaj pristup ne funkcionira. Moram se riješiti takvih stvari jer ti ljudi ne štite sustav. Odluku mora donijeti sama momčad, jer momčad za to mora snositi odgovornost. U suprotnom, nastaje paradoksalna situacija kada menadžer koji nikad u životu nije napisao kod kaže programeru koliko vremena treba da mu treba da napiše kod. Jedna tvrtka s kojom sam radio imala je 7 različitih odbora koji su pregledavali svaku promjenu, uključujući odbor za arhitekturu, odbor za proizvode itd. Postojala je čak i obvezna karenca, iako mi je jedan zaposlenik rekao da u deset godina rada nikad nitko nije odbio promjenu koju je ova osoba napravila u tom obveznom roku.
Revizore treba pozvati da nam se pridruže, a ne ih se riješiti. Recite im da pišete nepromjenjive binarne spremnike koji, ako prođu sve testove, ostaju nepromjenjivi zauvijek. Recite im da imate cjevovod kao kod i objasnite što to znači. Pokažite im sljedeću shemu: nepromjenjivi binarni zapis samo za čitanje u spremniku koji prolazi sve testove ranjivosti; i onda ne samo da ga nitko ne dira, nego čak ni ne dira sustav koji stvara cjevovod, jer se i on stvara dinamički. Imam klijente, Capital One, koji koriste Vault za stvaranje nečega poput blockchaina. Auditor ne treba pokazati “recepte” od Chefa, dovoljno je pokazati blockchain iz kojeg je jasno što se dogodilo s Jira kartom u proizvodnji i tko je za to odgovoran.
Prema , koju je 2018. stvorio Sonatype, u 2017. bilo je 87 milijardi OSS zahtjeva za preuzimanje.
Gubici nastali zbog ranjivosti su previsoki. Štoviše, brojke koje sada vidite iznad ne uključuju oportunitetne troškove. Što je DevSecOps ukratko? Odmah da kažem da me ne zanima pričati koliko je ovo ime uspješno. Poanta je da, budući da je DevOps tako uspješan, trebamo pokušati dodati sigurnost tom cjevovodu.
Primjer ovog niza:
Ovo nije preporuka za određene proizvode, iako mi se svi sviđaju. Naveo sam ih kao primjer kako bih pokazao da DevOps, koji se u početku temeljio na organizacijskoj paradigmi u industriji, omogućuje automatizaciju svake faze rada na proizvodu.
I nema razloga zašto ne bismo mogli zauzeti isti pristup sigurnosti.
Ukupan
Kao zaključak, dat ću nekoliko savjeta za DevSecOps. Morate uključiti revizore u proces stvaranja svojih sustava i posvetiti im vrijeme edukaciji. Morate surađivati s revizorima. Zatim, morate voditi apsolutno nemilosrdnu borbu protiv lažno pozitivnih rezultata. Čak i uz najskuplji alat za skeniranje ranjivosti, možete stvoriti izuzetno loše navike među svojim programerima ako ne znate kakav vam je omjer signala i šuma. Programeri će biti zatrpani događajima i jednostavno će ih izbrisati. Ako ste čuli za priču o Equifaxu, otprilike se to tamo dogodilo, gdje je najviša razina upozorenja zanemarena. Osim toga, ranjivosti je potrebno objasniti na način da bude jasno kako utječu na poslovanje. Na primjer, možete reći da je to ista ranjivost kao u priči o Equifaxu. Sigurnosne propuste trebale bi se tretirati isto kao i ostale softverske probleme, odnosno trebale bi biti uključene u cjelokupni DevOps proces. Morate raditi s njima kroz Jira, Kanban, itd. Programeri ne bi trebali misliti da će netko drugi to učiniti - naprotiv, svi bi to trebali učiniti. Konačno, morate trošiti energiju na obuku ljudi.
korisni linkovi
Evo nekoliko govora s DevOops konferencije koji bi vam mogli biti korisni:
- Sergey Berdnikov, Artyom Kalichkin - Priča o uspjehu, ili “Dev+DevOps+Ops” (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps na skali: grčka tragedija u tri čina (, )
- Aleksandar Titov, Kiril Tolkačev -
- Timothy Lister -
Pogledati u DevOops 2020 Moskva — ima tu i puno zanimljivih stvari.
Izvor: www.habr.com