Pitanje "kako implementirati devops" postoji već godinama, ali nema mnogo dobrih materijala. Ponekad postanete žrtva reklama ne baš pametnih konsultanata koji moraju prodati svoje vrijeme, bez obzira na to kako. Ponekad su to nejasne, krajnje općenite riječi o tome kako brodovi megakorporacija oru prostranstva svemira. Postavlja se pitanje: šta nas to zanima? Poštovani autore, možete li jasno formulisati svoje ideje u listu?
Sve ovo proizilazi iz činjenice da se nije nakupilo puno prave prakse i razumijevanja ishoda transformacija kulture kompanije. Promjene u kulturi su dugoročne stvari, čiji se rezultati neće pojaviti za sedmicu ili mjesec. Potreban nam je neko dovoljno star da vidi kako su se kompanije gradile i propadale godinama.
John Willis - jedan od očeva DevOps-a. John ima višedecenijsko iskustvo u radu sa velikim brojem kompanija. Nedavno je John počeo primjećivati specifične obrasce koji se javljaju u radu sa svakim od njih. Koristeći ove arhetipove, John vodi kompanije na pravi put DevOps transformacije. Više o ovim arhetipovima pročitajte u prijevodu njegovog izvještaja sa DevOops konferencije 2018.
O govorniku:
Više od 35 godina u IT menadžmentu, učestvovao u kreiranju prethodnika OpenCloud-a u kompaniji Canonical, učestvovao u 10 startupa, od kojih su dva prodata Dellu i Dockeru. Trenutno je potpredsjednik DevOps-a i digitalnih praksi u SJ Technologies.
Sljedeća je priča iz Johnove tačke gledišta.
Moje ime je John Willis i najlakše me pronaći je na Twitteru, . Imam isti alias na Gmailu i GitHubu. A možete pronaći video snimke mojih izvještaja i prezentacija za njih.
Imam mnogo sastanaka sa CIO-ovima raznih velikih kompanija. Vrlo često se žale da ne razumiju šta je DevOps, a svako ko pokuša da im to objasni priča 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 kompanijama starim više od sto godina. Nakon razgovora s njima, došao sam do zaključka da za mnoge probleme nije najprikladnija visoka tehnologija, već relativno niskotehnološka rješenja. Sedmicama sam samo razgovarao sa ljudima iz različitih odjela. Ono što vidite na prvoj slici u postu je moj posljednji projekat, ovako je soba izgledala nakon tri dana rada.
Šta je DevOps?
Zaista, ako pitate 10 različitih ljudi, oni će dati 10 različitih odgovora. Ali evo zanimljivosti: svih deset ovih odgovora će biti tačni. Ovdje nema pogrešnog odgovora. Bio sam prilično duboko u DevOps-u, oko 10 godina, i bio sam prvi Amerikanac na prvom DevOpsDay-u. Neću reći da sam pametniji od svih koji su uključeni u DevOps, ali teško da postoji neko ko je uložio toliko truda na to. Vjerujem da se DevOps događa kada se ljudski kapital i tehnologija spoje. Često zaboravljamo na ljudsku dimenziju, iako puno pričamo o svim vrstama kultura.
Sada imamo puno podataka, pet godina akademskog istraživanja, testiranje teorija na industrijskom nivou. Ono što nam ove studije govore jeste da ako kombinujete neke obrasce ponašanja u organizacionoj kulturi, možete postići 2000x ubrzanje. Ovo ubrzanje je praćeno jednakim poboljšanjem stabilnosti. Ovo je kvantitativno mjerenje koristi koju DevOps može donijeti bilo kojoj kompaniji. Prije par godina razgovarao sam o DevOps-u sa direktorom kompanije Fortune 5000. Kada sam se spremao za prezentaciju, bio sam jako nervozan jer sam morao da sumiram svoje dugogodišnje iskustvo u 5 minuta.
Na kraju sam dao sledeće Definicija DevOps-a: To je skup praksi i obrazaca koji omogućavaju transformaciju ljudskog kapitala u organizacijski kapital visokih performansi. Primjer je način na koji Toyota radi u posljednjih 50 ili 60 godina.
(U daljem tekstu ovakvi dijagrami nisu dati kao referentni materijal, već kao ilustracije. Njihov sadržaj će se razlikovati za svaku novu kompaniju. Međutim, slika se može pogledati zasebno i uvećati
Jedna od najuspješnijih ovakvih praksi je mapiranje vrijednosti toka. O tome je napisano nekoliko dobrih knjiga, od kojih je najuspješnija Karen Martin. Ali u protekloj godini došao sam do zaključka da je čak i ovaj pristup previše visokotehnološki. Sigurno ima mnogo prednosti i mnogo sam ga koristio. Ali kada vas izvršni direktor pita zašto njegova kompanija ne može preći na nove šine, prerano je govoriti o mapiranju tokova vrijednosti. Mnogo je mnogo fundamentalnijih pitanja na koja prvo treba odgovoriti.
Mislim da je greška koju čine mnoge moje kolege što jednostavno daju kompaniji vodič od pet tačaka, a zatim se vrate šest mjeseci kasnije i vide šta se dogodilo. Čak i dobra šema poput mapiranja tokova vrijednosti ima, recimo, slijepe tačke. Nakon stotina intervjua sa direktorima raznih kompanija, razvio sam određeni obrazac koji nam omogućava da problem razbijemo na njegove komponente, a sada ćemo raspravljati o svakoj od ovih komponenti po redu. Prije primjene bilo kakvih tehnoloških rješenja, koristim ovaj uzorak, i kao rezultat, svi moji zidovi su prekriveni dijagramima. Nedavno sam radio sa zajedničkim fondom i završio sam sa 100-150 takvih šema.
Loša kultura jede dobre pristupe za doručak
Glavna ideja je sljedeća: nikakva količina Lean, Agile, SAFE i DevOps-a neće pomoći ako je sama kultura organizacije loša. To je kao ronjenje u dubinu bez opreme za ronjenje ili rad bez rendgenskog snimka. Drugim riječima, da parafraziram Druckera i Deminga: loša organizacijska kultura će progutati svaki dobar sistem, a da se u njemu ne uguši.
Da biste riješili ovaj glavni problem, potrebno je poduzeti sljedeće korake:
- Učinite sve radove vidljivim: potrebno je da sav rad bude vidljiv. Ne u smislu da mora nužno biti prikazan na nekom ekranu, već u smislu da mora biti vidljiv.
- Konsolidovani sistemi upravljanja radom: sistemi upravljanja moraju biti konsolidovani. U problemu “plemenskog” znanja i institucionalnog znanja, u 9 od 10 slučajeva usko grlo su ljudi. U knjizi problem je bio sa jednom jedinom osobom, Brentom, zbog čega je projekat kasnio tri godine. I svuda nailazim na ove "brente". Da bih riješio ova uska grla, koristim sljedeće dvije stavke na našoj listi.
- Metodologija teorije ograničenja: teorija ograničenja.
- Hakovi za saradnju: kolaboracioni hakovi.
- Toyota Kata (): Neću puno pričati o Toyoti Kata. Ako ste zainteresovani, na mom githubu na skoro svaku od ovih tema.
- Tržišno orijentisana organizacija: tržišno orijentisana organizacija.
- Shift-lijevo revizori: revizija u ranim fazama ciklusa.
Počinjem da radim sa organizacijom vrlo jednostavno: odem u kompaniju i razgovaram sa zaposlenima. 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 sam dam flomaster i zamolim ih da zapišu na ploču sve što su do sada naglas rekli. Obično na ovakvim sastancima postoji jedna osoba koja sve zapiše, au najboljem slučaju može zapisati 10% diskusije. Sa mojom metodom, ova brojka se može podići na oko 40%.
(Ova ilustracija se može pogledati zasebno )
Moj pristup je zasnovan na radu Williama Schneidera. ). Pristup se zasniva na ideji da se svaka organizacija može podijeliti na četiri kvadrata. Ova shema za mene je obično rezultat rada sa onim stotinama drugih shema koje se javljaju prilikom analize organizacije. Pretpostavimo da imamo organizaciju sa visokim nivoom kontrole, ali sa niskom kompetencijom. Ovo je krajnje nepoželjna opcija: kada se svi drže granice, ali niko ne zna šta da radi.
Nešto bolja opcija je ona sa visokim nivoom kontrole i kompetencije. Ako je takva kompanija profitabilna, onda joj možda i ne treba DevOps. Najzanimljivije je raditi sa kompanijom koja ima visok nivo kontrole, nisku kompetentnost i saradnju, ali u isto vreme visok nivo kulture (kultivacije). To znači da kompanija ima dosta ljudi koji tamo vole da rade i da je fluktuacija radne snage mala.
(Ova ilustracija se može pogledati zasebno )
Čini mi se da metode sa rigidnim smjernicama na kraju stoje na putu do istine. Naročito u mapiranju tokova vrijednosti, postoje mnoga pravila o tome kako informacije treba da budu strukturirane. U ranim fazama rada, o kojima sada govorim, ova pravila nikome nisu potrebna. Ako osoba sa markerom u rukama na tabli opisuje stvarno stanje u kompaniji, to je najbolji način da se shvati stanje stvari. Takve informacije ne dolaze do direktora. U ovom trenutku je glupo prekinuti osobu i reći da je netačno nacrtao nekakvu strelicu. U ovoj fazi, bolje je koristiti jednostavna pravila, na primjer: apstrakcija na više nivoa može se kreirati jednostavno korištenjem višebojnih markera.
Ponavljam, bez visoke tehnologije. Crni marker prikazuje objektivnu stvarnost kako sve funkcionira. Crvenim markerom ljudi označavaju ono što im se ne sviđa u trenutnom stanju stvari. Bitno je da ovo pišu oni, a ne ja. Kada nakon sastanka odem do CIO-a, ne nudim listu od 10 stvari koje treba popraviti. Nastojim pronaći veze između onoga što ljudi u kompaniji govore i postojećih dokazanih obrazaca. Na kraju, plavi marker sugerira moguća rješenja problema.
(Ova ilustracija se može pogledati zasebno )
Primjer ovog pristupa je sada prikazan gore. Početkom ove godine radio sam sa jednom bankom. Ljudi iz obezbjeđenja su bili uvjereni da ne bi trebali dolaziti na pregled dizajna i zahtjeva.
(Ova ilustracija se može pogledati zasebno )
A onda smo razgovarali s ljudima iz drugih odjela i ispostavilo se da su prije otprilike 8 godina programeri softvera otpustili radnike obezbjeđenja jer su usporavali rad. A onda se to pretvorilo u zabranu, što se podrazumijevalo. Iako u stvarnosti nije bilo zabrane.
Naš sastanak je protekao na krajnje konfuzan način: oko tri sata pet različitih timova nije moglo da mi objasni šta se dešava između kodeksa i skupštine. A ovo bi se činilo najjednostavnije. Većina DevOps konsultanata unaprijed pretpostavlja da svi to već znaju.
Onda je osoba zadužena za IT upravljanje, koja je ćutala četiri sata, odjednom oživela kada smo došli do njegove teme i zaokupljala nas jako dugo. Na kraju sam ga pitao šta misli o sastanku i nikada neću zaboraviti njegov odgovor. Rekao je: “Nekada sam mislio da naša banka ima samo dva načina za isporuku softvera, ali sada znam da ih ima pet, a nisam znao ni za tri.”
(Ova ilustracija se može pogledati zasebno )
Poslednji sastanak u ovoj banci bio je sa timom za investicioni softver. S njom se pokazalo da je pisanje dijagrama markerom na listu papira bolje nego na ploči, pa čak i bolje nego na pametnoj ploči.
Fotografije koje vidite su kako je izgledala hotelska konferencijska sala četvrtog dana našeg sastanka. I koristili smo ove šeme za traženje obrazaca, odnosno arhetipova.
Dakle, postavljam pitanja radnicima, oni zapisuju odgovore markerima u tri boje (crna, crvena i plava). Analiziram njihove odgovore za arhetipove. Hajde da sada porazgovaramo o svim arhetipovima po redu.
1. Učinite sav posao vidljivim: Učinite rad vidljivim
Većina kompanija sa kojima radim ima veoma visok procenat nepoznatog posla. Na primjer, to je kada jedan zaposlenik dođe drugom i jednostavno traži da nešto uradi. U velikim organizacijama može biti 60% neplaniranih poslova. I do 40% radova nije ni na koji način dokumentirano. Da je u pitanju Boeing, nikada se više u životu ne bih ukrcao na njihov avion. Ako je samo polovina posla dokumentovana, onda se ne zna da li se taj posao radi kako treba ili ne. Sve druge metode ispadaju beskorisne - nema smisla pokušavati bilo što automatizirati, jer poznatih 50% može biti najkoherentniji i najjasniji dio posla, čija automatizacija neće dati sjajne rezultate, a sve najgore stvari su u nevidljivoj polovini. U nedostatku dokumentacije, nemoguće je pronaći sve vrste hakova i skrivenih poslova, a ne pronaći uska grla, baš one „brente“ o kojima sam već govorio. Postoji divna knjiga Dominike DeGrandis . Ona otkriva pet različitih "vremenskih curenja" (lopovi vremena):
- Previše posla u procesu (WIP)
- Nepoznate zavisnosti
- Unplanned Work
- Sukobni prioriteti
- Zanemareni rad
Ovo je vrlo vrijedna analiza i knjiga je odlična, ali svi ovi savjeti su beskorisni ako je vidljivo samo 50% podataka. Metode koje je predložila Dominika mogu se koristiti ako se postigne tačnost iznad 90%. Govorim o situacijama u kojima šef zadaje podređenom 15-minutni zadatak, ali mu treba tri dana; ali šef zapravo ne zna da ovaj podređeni zavisi od četiri ili pet drugih ljudi.
Projekat Phoenix je divna priča o projektu koji je kasnio tri godine. Jednom od likova zbog toga prijeti otkaz, a on se susreće s drugim likom koji je predstavljen kao neka vrsta Sokrata. On pomaže da se shvati šta je tačno pošlo po zlu. Ispostavilo se da kompanija 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 nedelju dana? Odgovor je vrlo pojednostavljen prikaz teorije čekanja i Littleovog zakona, a u ovoj prezentaciji se ispostavlja da pri 90% popunjenosti svaki sat rada traje 9 sati. Svaki zadatak treba poslati još sedam ljudi, tako da taj sat postane 63 sata, 7 puta 9. Poenta koju želim reći je da, da biste koristili Littleov zakon ili bilo koju složenu teoriju čekanja, morate barem imati podatke.
Dakle, kada govorim o vidljivosti, ne mislim da je sve na ekranu, već da barem imate podatke. Kada to urade, često se ispostavi da postoji jako velika količina neplaniranog posla koji se nekako šalje Brentu kada za tim nema potrebe. A Brent je sjajan momak, 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 primijeniti automatizacija.
2. Konsolidacija sistema upravljanja radom: upravljanje zadacima
Arhetipovi o kojima govorim su neka vrsta piramide. Ako je prvi urađen ispravno, onda je drugi već neka vrsta dodatka. Mnogi od njih ne rade za startapove, treba ih imati na umu za veće kompanije kao što je Fortune 5000. Poslednja kompanija u kojoj sam radio imala je 10 sistema za prodaju karata. Jedan tim je imao Remedy, drugi je napisao neku vrstu sopstvenog sistema, treći je koristio Jira, a neki su se zadovoljili e-poštom. Isti problem nastaje ako kompanija ima 30 različitih cjevovoda, ali ja nemam vremena da raspravljam o svim takvim slučajevima.
Razgovaram sa ljudima kako tačno nastaju karte, šta im se dalje dešava i kako ih se zaobilazi. Najzanimljivije je da ljudi na našim sastancima govore sasvim iskreno. Pitao sam koliko ljudi stavlja "manji/bez uticaja" na karte kojima bi zapravo trebalo dati "veliki uticaj". Ispostavilo se da skoro svi to rade. Ne bavim se osudama i pokušavam na sve moguće načine da ne identifikujem ljude. Kad mi nešto iskreno priznaju, ne odajem tu osobu. Ali kada skoro svi zaobiđu sistem, to znači da je sva sigurnost u suštini izloga. Stoga se iz podataka ovog sistema ne mogu izvoditi zaključci.
Da biste riješili problem ulaznica, morate odabrati jedan glavni sistem. Ako koristite Jira, zadržite je Jira. Ako postoji neka alternativa, neka bude jedina. Suština je da tikete treba posmatrati kao još jedan korak u procesu razvoja. Svaka akcija mora imati ulaznicu, koja mora teći kroz razvojni radni tok. Ulaznice se šalju timu, koji ih objavljuje na storyboardu i zatim preuzima odgovornost za njih.
Ovo se odnosi na sve odjele, uključujući infrastrukturu i operacije. U ovom slučaju, moguće je formirati barem neku uvjerljivu ideju o stanju stvari. Kada se ovaj proces uspostavi, odjednom postaje lako identifikovati ko je odgovoran za svaku aplikaciju. Jer sada dobijamo ne 50%, već 98% novih usluga. Ako ovaj osnovni proces funkcionira, tada se poboljšava preciznost u cijelom sistemu.
Cjevovod usluga
Ovo se opet odnosi samo na velike korporacije. Ako ste nova kompanija u novoj oblasti, zasučite rukave i radite sa svojim Travis CI ili CircleCI. Kada je reč o kompanijama sa liste Fortune 5000, primer koji se desio u banci u kojoj sam radio. Google je došao do njih i pokazali su im dijagrame starih IBM sistema. Momci iz Gugla su zbunjeno pitali - gdje je izvorni kod za ovo? Ali ne postoji izvorni kod, čak ni GUI. Ovo je realnost sa kojom se velike organizacije moraju suočiti: 40 godina stari bankovni zapisi na drevnom glavnom računaru. Jedan od mojih klijenata koristi Kubernetes kontejnere sa Circuit Breaker šablonima, plus Chaos Monkey, sve za aplikaciju KeyBank. Ali ovi kontejneri se na kraju povezuju sa COBOL aplikacijom.
Momci iz Googlea su bili potpuno uvjereni da će riješiti sve probleme mog klijenta, a onda su počeli postavljati pitanja: šta je IBM datapipe? Rečeno im je: ovo je konektor. Sa čime se povezuje? Za Sperry sistem. I šta je to? I tako dalje. Na prvi pogled izgleda: kakav DevOps može biti? Ali u stvari, moguće je. Postoje sistemi isporuke koji vam omogućavaju da predate tok posla timovima za isporuku.
3. Teorija ograničenja: Teorija ograničenja
Pređimo na treći arhetip: institucionalno/„plemensko“ znanje. Po pravilu, u bilo kojoj organizaciji postoji nekoliko ljudi koji sve znaju i svime upravljaju. To su oni koji su najduže u organizaciji i koji znaju sva rješenja.
Kada se ovo pojavi na dijagramu, takve ljude posebno zaokružim markerom: na primjer, ispostavilo se da je određeni Lou prisutan na svim sastancima. I jasno mi je: ovo je lokalni Brent. Kada CIO bira između mene u majici i patikama i tipa iz IBM-a u odijelu, ja sam izabran jer mogu reći direktoru stvari koje drugi tip neće reći i koje direktor možda ne želi čuti . Kažem im da je usko grlo u njihovom društvu neko po imenu Fred i neko po imenu Lou. Ovo usko grlo treba razriješiti, znanje na ovaj ili onaj način dobiti od njih.
Za rješavanje ove vrste problema mogu, na primjer, predložiti korištenje Slacka. Pametan direktor će se zapitati - zašto? Tipično, u takvim slučajevima, DevOps konsultanti odgovaraju: jer svi to rade. Ako je direktor stvarno pametan, reći će: pa šta. I tu se dijalog završava. A moj odgovor na ovo je: jer postoje četiri uska grla u kompaniji, Fred, Lou, Susie i Jane. Da bi se institucionaliziralo njihovo znanje, prvo se mora uvesti Slack. Svi tvoji wikiji su potpune gluposti jer niko ne zna za njihovo postojanje. Ako je inženjerski tim uključen u front-end i back-end razvoj i svi moraju znati da mogu kontaktirati front-end razvojni tim ili tim za infrastrukturu s pitanjima. Tada će Lou ili Fred vjerovatno imati vremena da se pridruže wikiju. A onda bi u Slacku neko mogao pitati zašto, recimo, korak 5 ne radi. A onda će Lou ili Fred ispraviti upute na wikiju. Ako uspostavite ovaj proces, mnoge stvari će doći same od sebe.
Ovo je moja glavna poenta: da biste preporučili bilo koju visoku tehnologiju, morate prvo dovesti u red temelj za njih, a to se može učiniti upravo opisanim rješenjima niske tehnologije. Ako počnete s visokim tehnologijama i ne objasnite zašto su one potrebne, onda se to u pravilu ne završava dobro. Jedan od naših klijenata koristi Azure ML, vrlo jeftino i jednostavno rješenje. Na oko 30% njihovih pitanja odgovorila je sama mašina za samoučenje. A ovu stvar su napisali operateri koji nisu bili uključeni u nauku o podacima, statistiku ili matematiku. Ovo je značajno. Trošak takvog rješenja je minimalan.
4. Hakovi za saradnju: Hakovi za saradnju
Četvrti arhetip je potreba za borbom protiv izolacije. Većina ljudi to već zna: izolacija rađa neprijateljstvo. Ako je svako odjeljenje na svom katu, a ljudi se ni na koji način ne ukrštaju jedni s drugima, osim u liftu, tada vrlo lako nastaje neprijateljstvo među njima. Ali ako su, naprotiv, ljudi u istoj prostoriji jedni s drugima, ona odmah odlazi. Kada neko izbaci neku opštu optužbu, na primer, takav i takav interfejs nikada ne radi, nema ništa lakše dekonstruisati takvu optužbu. Programeri koji su pisali interfejs samo treba da počnu da postavljaju konkretna pitanja i uskoro će biti jasno da je, na primer, korisnik jednostavno pogrešno koristio alat.
Postoji mnogo načina da se prevaziđe izolacija. Jednom su me zamolili da konsultujem banku u Australiji, ali sam to odbio jer imam dvoje dece i ženu. Sve što sam mogao učiniti da im pomognem bilo je da preporučim grafičko pripovijedanje. Ovo je nešto što dokazano djeluje. Još jedan zanimljiv način su sastanci bez kafe. U velikoj organizaciji, ovo je odlična opcija za širenje znanja. Osim toga, možete provoditi interne devopsdaye, hackathone i tako dalje.
5. Treniranje kate
Kao što sam upozorio na samom početku, neću o tome danas. Ako ste zainteresovani, možete pogledati .
Postoji i dobar razgovor o ovoj temi od Mikea Rothera:
6. Tržišno orijentisana: tržišno orijentisana organizacija
Ovdje postoje različiti problemi. Na primjer, "I" ljudi, "T" ljudi i "E" ljudi. “Ja” ljudi su oni koji rade samo jednu stvar. Obično postoje u organizacijama sa izolovanim odeljenjima. "T" je kada je osoba dobra u jednoj stvari, ali i u nekim drugim stvarima. "E" ili čak "češalj" je kada osoba ima mnogo vještina.
Konvejev zakon ovde funkcioniše (), što se u najjednostavnijem obliku može navesti na sljedeći način: ako na kompajleru rade tri tima, onda će rezultat biti kompajler od tri dijela. Stoga, ako postoji visok nivo izolacije unutar organizacije, onda će čak i Kubernetes, prekidač, API proširivost i druge fensi stvari u ovoj organizaciji biti uređene na isti način kao i sama organizacija. Striktno prema Conwayu i u inat svim vama mladim štreberima.
Rješenje ovog problema je više puta opisano. Postoje, na primjer, organizacijski arhetipovi koje je opisao Fernando Fernandez. Ta problematična arhitektura o kojoj sam upravo govorio, sa izolacijom, je arhitektura orijentirana na funkciju. Drugi tip je najgora, matrična arhitektura, nered od druga dva. Treće je ono što se vidi u većini startupa, a velike kompanije također pokušavaju parirati ovom tipu. To je tržišno orijentisana organizacija. Ovdje se 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/pokrenuti timove, u Amazonu to zovu dva pizza tima. U ovoj strukturi svi ljudi tipa “I” grupišu se oko jedne usluge i postepeno se približavaju tipu “T”, a ako postoji pravi menadžment, mogu postati i “E”. Prvi kontraargument ovdje je da takva struktura ima nepotrebne elemente. Zašto vam je potreban tester u svakom odjeljenju ako možete imati posebno odjeljenje testera? Na šta odgovaram: dodatni troškovi u ovom slučaju su cijena da cijela organizacija u budućnosti postane tip “E”. U ovoj strukturi, tester postepeno uči o mrežama, arhitekturi, dizajnu itd. Kao rezultat toga, svaki učesnik u organizaciji je potpuno svjestan svega što se dešava u organizaciji. Ako želite znati kako ova shema funkcionira u industriji, pročitajte .
7. Revizori Shift-lijevo: revizija rano u ciklusu. Poštivanje sigurnosnih pravila na ekranu
Ovo je kada vaše radnje ne prođu test mirisa, da tako kažem. Ljudi koji rade za tebe nisu glupi. Ako su, kao u gornjem primjeru, posvuda postavili manji/bez utjecaja, to je trajalo tri godine, a niko ništa nije primijetio, onda svi dobro znaju da sistem ne radi. Ili drugi primjer - savjetodavni odbor za promjene, gdje izvještaje treba podnositi svake, recimo, srijede. Tamo radi grupa ljudi (ne baš dobro plaćenih, inače) koji bi, u teoriji, trebali znati kako funkcionira sistem u cjelini. I tokom proteklih pet godina, verovatno ste primetili da su naši sistemi neverovatno složeni. A pet-šest ljudi mora donijeti odluku o promjeni koju nisu napravili i o kojoj ništa ne znaju.
Naravno, ovaj pristup ne funkcioniše. Moram se riješiti takvih stvari jer ti ljudi ne štite sistem. Odluku mora donijeti sam tim, jer tim mora biti odgovoran za to. U suprotnom, nastaje paradoksalna situacija kada menadžer koji nikada u životu nije pisao kod, kaže programeru koliko vremena treba da traje da napiše kod. Jedna kompanija s kojom sam radio imala je 7 različitih odbora koji su pregledali svaku promjenu, uključujući odbor za arhitekturu, ploču proizvoda, itd. Čak je postojao i obavezan period čekanja, iako mi je jedan zaposlenik rekao da za deset godina rada niko nikada nije odbio promjenu koju je ta osoba napravila u tom obaveznom roku.
Revizore treba pozvati da nam se pridruže, a ne da ih se riješe. Recite im da pišete nepromjenjive binarne kontejnere 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 šemu: nepromjenjivu binarnu datoteku samo za čitanje u kontejneru koja prolazi sve testove ranjivosti; a onda ne samo da ga niko ne dira, nego čak ni sistem koji kreira cevovod, jer se i on stvara dinamički. Imam klijente, Capital One, koji koriste Vault da kreiraju nešto poput blockchaina. Revizor ne mora pokazivati “recepte” od Chefa, dovoljno je pokazati blockchain iz kojeg je jasno šta se dogodilo sa Jira tiketom u proizvodnji i ko je za to odgovoran.
Prema , koju je Sonatype kreirao 2018. godine, bilo je 2017 milijardi zahtjeva za preuzimanje OSS-a u 87. godini.
Gubici nastali zbog ranjivosti su previsoki. Štaviše, brojke koje sada vidite iznad ne uključuju oportunitetne troškove. Šta je DevSecOps ukratko? Odmah da kažem da me ne zanima koliko je ovo ime uspješno. Poenta je da, pošto je DevOps bio tako uspješan, trebali bismo pokušati dodati sigurnost tom cevovodu.
Primjer ovog niza:
Ovo nije preporuka za određene proizvode, iako mi se svi sviđaju. Naveo sam ih kao primjer da pokažem da DevOps, koji je u početku bio zasnovan na organizacijskoj paradigmi u industriji, omogućava automatizaciju svake faze rada na proizvodu.
I nema razloga zašto ne bismo mogli zauzeti isti pristup sigurnosti.
Rezultat
Kao zaključak, dat ću nekoliko savjeta za DevSecOps. Morate uključiti revizore u proces kreiranja vaših sistema i potrošiti vrijeme na njihovu edukaciju. Morate sarađivati sa revizorima. Zatim, morate voditi apsolutno nemilosrdnu borbu protiv lažnih pozitivnih rezultata. Čak i sa najskupljim alatom za skeniranje ranjivosti, možete stvoriti izuzetno loše navike među svojim programerima ako ne znate koji je vaš omjer signal-šum. Programeri će biti zatrpani događajima i jednostavno će ih izbrisati. Ako ste čuli za priču o Equifaxu, to se uglavnom dogodilo tamo, gdje je najviši nivo uzbune ignorisan. Pored toga, ranjivosti je potrebno objasniti na način da bude jasno kako utiču na poslovanje. Na primjer, možete reći da je ovo ista ranjivost kao u priči Equifax. Sigurnosne propuste treba tretirati isto kao i druge softverske probleme, odnosno treba ih uključiti u cjelokupni DevOps proces. Morate raditi s njima putem Jira, Kanbana itd. Programeri ne bi trebali misliti da će to učiniti neko drugi – naprotiv, svi bi to trebali učiniti. Konačno, morate trošiti energiju na obuku ljudi.
korisni linkovi
Evo nekoliko govora sa 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 -
Pogledaj DevOops 2020 Moskva — tu ima i dosta zanimljivih stvari.
izvor: www.habr.com