Klausimas "kaip įdiegti devops" buvo jau daugelį metų, tačiau nėra daug gerų medžiagų. Kartais tampate ne tokių protingų konsultantų skelbimų auka, kuriems reikia parduoti savo laiką, nesvarbu, kaip. Kartais tai neaiškūs, itin bendri žodžiai apie tai, kaip megakorporacijų laivai aria visatos platybes. Kyla klausimas: ką mums tai svarbu? Gerbiamas autoriau, ar galite aiškiai suformuluoti savo idėjas sąraše?
Visa tai kyla iš to, kad realios praktikos ir supratimo apie įmonės kultūros transformacijų rezultatus nėra sukaupta daug. Kultūros pokyčiai – ilgalaikiai dalykai, kurių rezultatai nepasireikš po savaitės ar mėnesio. Mums reikia žmogaus, kuris būtų pakankamai senas, kad matytų, kaip įmonės buvo kuriamos ir žlugo bėgant metams.
Džonas Vilisas - vienas iš DevOps tėvų. Jonas turi dešimtmečių patirtį dirbant su daugybe įmonių. Neseniai Jonas pradėjo pastebėti specifinius modelius, kurie atsiranda dirbant su kiekvienu iš jų. Naudodamas šiuos archetipus, Johnas nukreipia įmones tikruoju DevOps transformacijos keliu. Daugiau apie šiuos archetipus skaitykite jo pranešimo iš DevOops 2018 konferencijos vertime.
Apie kalbėtoją:
Daugiau nei 35 metus IT valdymo srityje, dalyvavo kuriant OpenCloud pirmtaką Canonical, dalyvavo 10 startuolių, iš kurių du buvo parduoti „Dell“ ir „Docker“. Šiuo metu jis yra SJ Technologies DevOps ir skaitmeninės praktikos viceprezidentas.
Toliau – istorija Jono požiūriu.
Mano vardas Johnas Willisas ir lengviausia mane rasti „Twitter“, . Turiu tą patį slapyvardį „Gmail“ ir „GitHub“. A galite rasti mano pranešimų ir jiems skirtų pristatymų vaizdo įrašus.
Turiu daug susitikimų su įvairių didelių įmonių CIO. Jie labai dažnai skundžiasi, kad nesupranta, kas yra DevOps, ir visi, kurie bando jiems tai paaiškinti, kalba apie ką kita. Dar vienas dažnas skundas – „DevOps“ neveikia, nors atrodo, kad režisieriai viską daro taip, kaip jiems paaiškinta. Kalbame apie dideles įmones, kurioms daugiau nei šimtas metų. Pakalbėjęs su jais padariau išvadą, kad daugeliui problemų geriausiai tinka ne aukštosios technologijos, o gana žemų technologijų sprendimai. Savaites tiesiog kalbėjausi su žmonėmis iš įvairių skyrių. Tai, ką matote pačioje pirmoje įrašo nuotraukoje, yra paskutinis mano projektas, taip kambarys atrodė po trijų dienų darbo.
Kas yra DevOps?
Iš tiesų, jei paklausite 10 skirtingų žmonių, jie duos 10 skirtingų atsakymų. Tačiau čia yra įdomus dalykas: visi dešimt šių atsakymų bus teisingi. Čia nėra neteisingo atsakymo. Apie 10 metų buvau gana giliai į „DevOps“ ir buvau pirmasis amerikietis per pirmąją „DevOpsDay“. Nepasakysiu, kad esu protingesnis už visus, dalyvaujančius „DevOps“, bet vargu ar kas nors skyrė tam tiek pastangų. Manau, kad „DevOps“ atsiranda, kai susijungia žmogiškasis kapitalas ir technologijos. Mes dažnai pamirštame apie žmogiškąją dimensiją, nors daug kalbame apie įvairiausias kultūras.
Dabar turime daug duomenų, penkerių metų akademinių tyrimų, teorijų tikrinimo pramoniniu mastu. Šie tyrimai mums sako, kad jei sujungsite kai kuriuos elgsenos modelius organizacijos kultūroje, galite pasiekti 2000 kartų pagreitį. Šį pagreitį atitinka vienodai pagerėjęs stabilumas. Tai kiekybinis naudos, kurią „DevOps“ gali atnešti bet kuriai įmonei, įvertinimas. Prieš porą metų apie DevOps kalbėjausi su Fortune 5000 įmonės vadovu.Ruošdamasi pristatymui labai jaudinausi, nes per 5 minutes turėjau apibendrinti savo ilgametę patirtį.
Pabaigoje pateikiau štai ką DevOps apibrėžimas: Tai praktikų ir modelių rinkinys, įgalinantis žmogiškąjį kapitalą paversti didelio našumo organizaciniu kapitalu. Pavyzdžiui, „Toyota“ veikė pastaruosius 50 ar 60 metų.
(Toliau tokios schemos pateikiamos ne kaip informacinė medžiaga, o kaip iliustracijos. Kiekvienai naujai įmonei jų turinys skirsis. Tačiau paveikslėlį galima peržiūrėti atskirai ir padidinti
Viena sėkmingiausių tokių praktikų yra vertė srautas kartografavimo. Apie tai parašyta keletas gerų knygų, iš kurių sėkmingiausios yra Karen Martin. Tačiau per pastaruosius metus padariau išvadą, kad net ir šis metodas yra per daug aukštųjų technologijų. Jis tikrai turi daug privalumų ir aš jį daug naudoju. Tačiau kai generalinis direktorius jūsų klausia, kodėl jo įmonė negali pereiti prie naujų bėgių, dar per anksti kalbėti apie vertės srauto sudarymą. Yra daug daug esminių klausimų, į kuriuos pirmiausia reikia atsakyti.
Manau, kad daugelio mano kolegų klaida yra ta, kad jie tiesiog pateikia įmonei penkių punktų vadovą, o po šešių mėnesių grįžta ir pamato, kas atsitiko. Netgi tokia gera schema, kaip vertės srauto sudarymas, turi, tarkime, aklųjų dėmių. Po šimtų interviu su įvairių įmonių direktoriais sukūriau tam tikrą modelį, leidžiantį suskaidyti problemą į komponentus, o dabar aptarsime kiekvieną iš šių komponentų eilės tvarka. Prieš taikydamas bet kokius technologinius sprendimus aš naudoju šį raštą, todėl visos mano sienos yra padengtos diagramomis. Neseniai dirbau su investiciniu fondu ir turėjau 100–150 tokių schemų.
Bloga kultūra pusryčiams valgo gerus metodus
Pagrindinė mintis tokia: jokie Lean, Agile, SAFE ir DevOps nepadės, jei pati organizacijos kultūra yra bloga. Tai tarsi nardymas į gelmes be akvalango įrangos arba darbas be rentgeno. Kitaip tariant, perfrazuojant Druckerį ir Demingą: bloga organizacinė kultūra prarys bet kokią gerą sistemą, ja neužsprings.
Norėdami išspręsti šią pagrindinę problemą, turite atlikti šiuos veiksmus:
- Padaryti visus darbus matomus: reikia, kad visi darbai būtų matomi. Ne ta prasme, kad jis būtinai turi būti rodomas kokiame nors ekrane, bet ta prasme, kad jis turi būti stebimas.
- Konsoliduotos darbo valdymo sistemos: valdymo sistemas reikia konsoliduoti. „Gentinių“ žinių ir institucinių žinių problemoje 9 atvejais iš 10 kliūtis yra žmonės. Knygoje problema buvo su vienu žmogumi Brentu, dėl kurio projektas vėlavo trejais metais. Ir aš visur susiduriu su šiais „Brentais“. Norėdami išspręsti šias kliūtis, naudoju kitus du sąrašo elementus.
- Apribojimų teorijos metodika: suvaržymų teorija.
- Bendradarbiavimo įsilaužimai: bendradarbiavimo įsilaužimai.
- Toyota Kata (): Apie Toyota Kata daug nekalbėsiu. Jei domina, mano github'e beveik kiekviena iš šių temų.
- Į rinką orientuota organizacija: į rinką orientuota organizacija.
- Kairėnieji auditoriai: auditas ankstyvosiose ciklo stadijose.
Dirbti su organizacija pradedu labai paprastai: einu į įmonę ir kalbuosi su darbuotojais. Kaip matote, nėra aukštųjų technologijų. Viskas, ko jums reikia, yra ant ko parašyti. Suburiu kelias komandas į vieną kambarį ir analizuoju, ką jos man sako iš mano 7 archetipų perspektyvos. Tada aš jiems patiems duodu žymeklį ir prašau užrašyti lentoje viską, ką iki šiol garsiai pasakė. Dažniausiai tokio tipo susitikimuose būna vienas žmogus, kuris viską užsirašo ir geriausiu atveju gali užrašyti 10% diskusijos. Mano metodu šis skaičius gali būti padidintas iki maždaug 40%.
(Šią iliustraciją galima peržiūrėti atskirai )
Mano požiūris grindžiamas Williamo Schneiderio darbu. ). Šis požiūris grindžiamas idėja, kad bet kurią organizaciją galima suskirstyti į keturis kvadratus. Ši schema man dažniausiai yra darbo su tais šimtais kitų schemų, kurios atsiranda analizuojant organizaciją, rezultatas. Tarkime, kad turime organizaciją, kurios kontrolės lygis aukštas, bet kompetencija žema. Tai itin nepageidautinas variantas: kai visi kertasi, bet niekas nežino, ką daryti.
Šiek tiek geresnis pasirinkimas yra tas, kuris turi aukštą kontrolės ir kompetencijos lygį. Jei tokia įmonė yra pelninga, galbūt jai nereikia „DevOps“. Įdomiausia dirbti su įmone, kuri turi aukštą kontrolės lygį, žemą kompetenciją ir bendradarbiavimą, bet kartu aukštą kultūros (auginimo) lygį. Tai reiškia, kad įmonėje dirba daug mėgstančių žmonių, o darbo jėgos kaita nedidelė.
(Šią iliustraciją galima peržiūrėti atskirai )
Man atrodo, kad metodai su griežtomis gairėmis galiausiai trukdo pasiekti tiesą. Vertės srauto atvaizdavimo srityje yra daug taisyklių, susijusių su informacijos struktūrizavimu. Pradiniame darbo etape, apie kurį dabar kalbu, šios taisyklės niekam nereikalingos. Jei žmogus su žymekliu rankose lentoje apibūdina tikrąją įmonės situaciją, tai yra geriausias būdas suprasti reikalų būklę. Tokia informacija direktorių nepasiekia. Šiuo metu kvaila pertraukti žmogų ir pasakyti, kad jis neteisingai nupiešė kažkokią rodyklę. Šiame etape geriau vadovautis paprastomis taisyklėmis, pavyzdžiui: kelių lygių abstrakciją galima sukurti tiesiog naudojant kelių spalvų žymeklius.
Kartoju, jokių aukštųjų technologijų. Juodas žymeklis vaizduoja objektyvią tikrovę, kaip viskas veikia. Raudonu žymekliu žmonės pažymi tai, kas jiems nepatinka esamoje situacijoje. Svarbu, kad tai rašytų jie, o ne aš. Kai po susitikimo einu pas CIO, nesiūlau 10 dalykų, kuriuos reikia taisyti, sąrašo. Stengiuosi rasti sąsajų tarp to, ką sako įmonės žmonės, ir esamų patikrintų modelių. Galiausiai mėlynas žymeklis siūlo galimus problemos sprendimus.
(Šią iliustraciją galima peržiūrėti atskirai )
Šio metodo pavyzdys dabar pateiktas aukščiau. Šių metų pradžioje dirbau viename banke. Apsaugos darbuotojai buvo įsitikinę, kad jie neturėtų ateiti į dizaino ir reikalavimų peržiūras.
(Šią iliustraciją galima peržiūrėti atskirai )
Ir tada mes kalbėjomės su žmonėmis iš kitų skyrių ir paaiškėjo, kad maždaug prieš 8 metus programinės įrangos kūrėjai atleido apsaugos darbuotojus, nes jie lėtino darbą. Ir tada tai virto draudimu, kuris buvo laikomas savaime suprantamu dalyku. Nors realiai draudimo nebuvo.
Mūsų susitikimas vyko labai painiai: maždaug tris valandas penkios skirtingos komandos negalėjo man paaiškinti, kas vyksta tarp kodo ir surinkimo. Ir tai atrodo paprasčiausias dalykas. Daugelis „DevOps“ konsultantų iš anksto mano, kad visi tai jau žino.
Tada už IT valdymą atsakingas žmogus, tylėjęs keturias valandas, staiga atgijo, kai priėjome prie jo temos, ir okupavo mus labai ilgai. Pabaigoje paklausiau, ką jis mano apie susitikimą, ir niekada nepamiršiu jo atsakymo. Jis sakė: „Anksčiau maniau, kad mūsų bankas turi tik du būdus pristatyti programinę įrangą, bet dabar žinau, kad jų yra penki, o apie tris net nežinojau.
(Šią iliustraciją galima peržiūrėti atskirai )
Paskutinis susitikimas šiame banke buvo su investicinės programinės įrangos komanda. Būtent su ja paaiškėjo, kad rašyti diagramas su žymekliu ant popieriaus lapo yra geriau nei lentoje ir net geriau nei išmaniojoje lentoje.
Nuotraukose, kurias matote, atrodo, kaip ketvirtą mūsų susitikimo dieną atrodė viešbučio konferencijų salė. Ir mes naudojome šias schemas ieškodami modelių, tai yra archetipų.
Taigi, aš užduodu darbuotojams klausimus, jie surašo atsakymus trijų spalvų (juodos, raudonos ir mėlynos) žymekliais. Aš analizuoju jų atsakymus dėl archetipų. Dabar aptarkime visus archetipus iš eilės.
1. Padarykite visus darbus matomus: padarykite matomus darbus
Daugumoje įmonių, su kuriomis dirbu, yra labai didelis nežinomo darbo procentas. Pavyzdžiui, tai yra tada, kai vienas darbuotojas ateina pas kitą ir tiesiog prašo ką nors padaryti. Didelėse organizacijose neplanuotų darbų gali būti 60 proc. O iki 40% darbų jokiu būdu nėra dokumentuota. Jei tai būtų „Boeing“, daugiau niekada gyvenime nelipčiau į jų lėktuvą. Jei dokumentuota tik pusė darbų, tai nėra žinoma, ar šis darbas atliekamas teisingai, ar ne. Visi kiti metodai pasirodo nenaudingi – nėra prasmės nieko bandyti automatizuoti, nes žinomi 50% gali būti nuosekliausia ir aiškiausia darbo dalis, kurios automatizavimas neduos puikių rezultatų, o blogiausia dalykai yra nematomoje pusėje. Nesant dokumentacijos, neįmanoma rasti visokių įsilaužimų ir paslėptų darbų, nerasti kliūčių, tų pačių „Brentų“, apie kuriuos jau kalbėjau. Yra nuostabi Dominikos DeGrandis knyga . Ji atskleidžia penki skirtingi „laiko nutekėjimai“ (laiko vagys):
- Per daug darbo apdorojama (WIP)
- Nežinomos priklausomybės
- Neplanuotas darbas
- Prieštaringi prioritetai
- Apleistas darbas
Tai labai vertinga analizė, o knyga puiki, tačiau visi šie patarimai yra nenaudingi, jei matoma tik 50% duomenų. Dominikos siūlomi metodai gali būti naudojami, jei pasiekiamas didesnis nei 90 % tikslumas. Kalbu apie situacijas, kai viršininkas pavaldiniui duoda 15 minučių užduotį, bet tai užtrunka tris dienas; bet viršininkas tikrai nežino, kad šis pavaldinys yra priklausomas nuo keturių ar penkių kitų žmonių.
„Phoenix Project“ yra nuostabi istorija apie projektą, kuris buvo pavėluotas trejais metais. Vienas iš veikėjų dėl to susiduria su atleidimu iš darbo ir susitinka su kitu veikėju, kuris pristatomas kaip savotiškas Sokratas. Jis padeda išsiaiškinti, kas tiksliai nutiko. Pasirodo, įmonė turi vieną sistemos administratorių, vardu Brent, ir visi darbai kažkaip vyksta per jį. Viename iš susitikimų vieno iš pavaldinių klausiama: kodėl kiekviena pusvalandžio užduotis trunka savaitę? Atsakymas yra labai supaprastintas eilių teorijos ir Litlo dėsnio pristatymas, o šiame pristatyme paaiškėja, kad esant 90% užimtumui, kiekviena darbo valanda trunka 9 valandas. Kiekvieną užduotį reikia išsiųsti kitiems septyniems žmonėms, kad ta valanda būtų 63 valandos, 7 kartus 9. Aš sakau, kad norint naudotis Mažojo dėsniu ar bet kokia sudėtinga eilių teorija, reikia bent turėti duomenų.
Taigi, kalbėdamas apie matomumą, turiu omenyje ne tai, kad viskas rodoma ekrane, o tai, kad bent jau turi duomenų. Kai jie tai padaro, dažnai paaiškėja, kad yra labai daug neplanuotų darbų, kurie kažkokiu būdu siunčiami į Brent, kai to nereikia. O Brentas – puikus vyrukas, niekada nepasakys „ne“, bet niekam nepasakoja, kaip dirba savo darbą.
Kai darbas matomas, galima tvarkingai suklasifikuoti duomenis (taip nuotraukoje daro Dominyka), pritaikyti penkių laiko nutekėjimų abstrakciją, pritaikyti automatizavimą.
2. Konsoliduoti darbo valdymo sistemas: užduočių valdymas
Archetipai, apie kuriuos kalbu, yra savotiška piramidė. Jei pirmasis atliktas teisingai, tai antrasis jau yra savotiškas priedas. Daugelis jų netinka pradedančiosioms įmonėms, jų reikia turėti omenyje didesnėms įmonėms, tokioms kaip „Fortune 5000“. Paskutinė įmonė, kurioje dirbau, turėjo 10 bilietų pardavimo sistemų. Viena komanda turėjo „Remedy“, kita rašė kažkokią savo sistemą, trečia naudojo „Jira“, o kai kurios tenkinosi el. Ta pati problema kyla, jei įmonė turi 30 skirtingų vamzdynų, bet aš neturiu laiko aptarti visų tokių atvejų.
Aptariu su žmonėmis, kaip tiksliai kuriami bilietai, kas su jais vyksta toliau ir kaip jie apeinami. Įdomiausia, kad žmonės mūsų susirinkimuose kalba gana nuoširdžiai. Paklausiau, kiek žmonių ant bilietų, kuriems iš tikrųjų turėtų būti suteiktas „didelis poveikis“, įdėjo „nedidelį / jokio poveikio“. Paaiškėjo, kad tai daro beveik visi. Aš neužsiimu denonsavimu ir visais įmanomais būdais stengiuosi neidentifikuoti žmonių. Kai jie man ką nors nuoširdžiai prisipažįsta, aš to žmogaus neišduodu. Tačiau kai beveik visi apeina sistemą, tai reiškia, kad visas saugumas iš esmės yra langų dekoravimas. Todėl iš šios sistemos duomenų negalima daryti išvadų.
Norėdami išspręsti bilieto problemą, turite pasirinkti vieną pagrindinę sistemą. Jei naudojate Jira, pasilikite ją Jira. Jei yra kokia nors alternatyva, tebūnie ji vienintelė. Esmė ta, kad į bilietus reikėtų žiūrėti kaip į dar vieną žingsnį kūrimo procese. Kiekvienas veiksmas turi turėti bilietą, kuris turi praeiti per kūrimo darbo eigą. Bilietai siunčiami komandai, kuri juos paskelbia siužete ir prisiima už juos atsakomybę.
Tai taikoma visiems skyriams, įskaitant infrastruktūrą ir operacijas. Tokiu atveju galima susidaryti bent kokią nors tikėtiną idėją apie reikalų būklę. Nustačius šį procesą, staiga tampa lengva nustatyti, kas atsakingas už kiekvieną programą. Nes dabar naujų paslaugų gauname ne 50%, o 98%. Jei šis pagrindinis procesas veikia, visos sistemos tikslumas pagerėja.
Paslaugų vamzdynas
Tai vėlgi taikoma tik didelėms korporacijoms. Jei esate nauja įmonė naujoje srityje, pasiraitokite rankoves ir dirbkite su Travis CI arba CircleCI. Kalbant apie „Fortune 5000“ įmones, pavyzdys nutiko banke, kuriame dirbau. „Google“ atėjo pas juos ir jiems buvo parodytos senų IBM sistemų diagramos. Vaikinai iš Google sutrikę klausė – kur to šaltinio kodas? Tačiau nėra šaltinio kodo, net GUI. Tai yra tikrovė, su kuria susiduria didelės organizacijos: 40 metų senumo banko įrašai senoviniame pagrindiniame kompiuteryje. Vienas iš mano klientų naudoja „Kubernetes“ konteinerius su „Circuit Breaker“ modeliais ir „Chaos Monkey“, visa tai skirta „KeyBank“ programai. Tačiau šie konteineriai galiausiai prisijungia prie COBOL programos.
Vaikinai iš Google buvo visiškai įsitikinę, kad išspręs visas mano kliento problemas, ir tada pradėjo klausinėti: kas yra IBM duomenų vamzdis? Jiems sakoma: tai yra jungtis. Su kuo tai jungiasi? Į Sperry sistemą. Ir kas tai? Ir taip toliau. Iš pirmo žvilgsnio atrodo: kokie gali būti „DevOps“? Bet iš tikrųjų tai įmanoma. Yra pristatymo sistemų, kurios leidžia perduoti darbo eigą pristatymo komandoms.
3. Apribojimų teorija: Apribojimų teorija
Pereikime prie trečiojo archetipo: institucinių/"gentinių" žinių. Paprastai bet kurioje organizacijoje yra keli žmonės, kurie viską žino ir viską valdo. Tai tie, kurie organizacijoje dirba ilgiausiai ir žino visus sprendimus.
Kai tai atsiranda diagramoje, tokius žmones specialiai apvedu žymekliu: pavyzdžiui, pasirodo, kad tam tikras Lou dalyvauja visuose susitikimuose. Ir man aišku: tai vietinis Brentas. Kai CIO renkasi tarp manęs su marškinėliais ir sportbačiais ir vaikino iš IBM su kostiumu, aš esu pasirinktas, nes galiu pasakyti režisieriui dalykus, kurių kitas nepasakos ir kurių režisieriui gali nepatikti girdėti. . Sakau jiems, kad kliūtis jų kompanijoje yra kažkas, vardu Fredas, ir kažkas, vardu Lu. Šią kliūtį reikia panaikinti, vienaip ar kitaip iš jų pasisemti žinių.
Norėdami išspręsti tokią problemą, galiu, pavyzdžiui, pasiūlyti naudoti Slack. Protingas režisierius paklaus – kodėl? Paprastai tokiais atvejais „DevOps“ konsultantai atsako: nes taip daro visi. Jeigu režisierius tikrai protingas, sakys: na ir ką. Ir čia dialogas baigiasi. Ir aš atsakau į tai: nes įmonėje yra keturios kliūtys: Fredas, Lou, Susie ir Jane. Norint įtvirtinti jų žinias, pirmiausia reikia pristatyti Slack. Visi tavo wiki yra visiška nesąmonė, nes niekas nežino apie jų egzistavimą. Jei inžinierių komanda dalyvauja kuriant priekinę ir užpakalinę dalį ir visi turi žinoti, kad su klausimais gali susisiekti su priekinės dalies kūrimo komanda arba infrastruktūros komanda. Tada Lu arba Fredas tikriausiai turės laiko prisijungti prie wiki. Tada Slack kas nors gali paklausti, kodėl, tarkime, neveikia 5 veiksmas. Tada Lou arba Fredas pataisys instrukcijas wiki. Jei nustatysite šį procesą, daugelis dalykų susitvarkys savaime.
Tai yra mano pagrindinė mintis: norint rekomenduoti bet kokias aukštąsias technologijas, pirmiausia reikia sutvarkyti joms pagrindą, o tai galima padaryti naudojant ką tik aprašytus žemųjų technologijų sprendimus. Jei pradedate nuo aukštųjų technologijų ir nepaaiškinate, kam jos reikalingos, tai, kaip taisyklė, geruoju nesibaigia. Vienas iš mūsų klientų naudoja Azure ML – labai pigų ir paprastą sprendimą. Į maždaug 30% jų klausimų atsakė pati savarankiško mokymosi mašina. Ir šį dalyką parašė operatoriai, nesusiję su duomenų mokslu, statistika ar matematika. Tai reikšminga. Tokio sprendimo kaina yra minimali.
4. Bendradarbiavimo įsilaužimai: bendradarbiavimo įsilaužimai
Ketvirtasis archetipas – būtinybė kovoti su izoliacija. Daugelis žmonių tai jau žino: izoliacija sukelia priešiškumą. Jei kiekvienas skyrius yra savo aukšte, o žmonės niekaip nesusikerta, išskyrus lifte, tada priešiškumas tarp jų kyla labai lengvai. Bet jei, priešingai, žmonės yra viename kambaryje, ji iškart išeina. Kai kas nors išmeta kokį nors bendrą kaltinimą, pavyzdžiui, tokia ir tokia sąsaja niekada neveikia, nėra nieko lengviau tokį kaltinimą dekonstruoti. Programišiams, parašiusiems sąsają, tereikia pradėti klausinėti konkrečių klausimų ir netrukus paaiškės, kad, pavyzdžiui, vartotojas tiesiog netinkamai naudojosi priemone.
Yra daug būdų, kaip įveikti izoliaciją. Kartą manęs paprašė pasikonsultuoti dėl banko Australijoje, bet atsisakiau tai padaryti, nes turiu du vaikus ir žmoną. Viskas, ką galėjau jiems padėti, tai rekomenduoti grafinį pasakojimą. Įrodyta, kad tai veikia. Kitas įdomus būdas – liesos kavos susitikimai. Didelėje organizacijoje tai puiki galimybė skleisti žinias. Be to, galite vesti vidinius devopsdienus, hakatonus ir pan.
5. Treniruotė Kata
Kaip perspėjau pačioje pradžioje, šiandien apie tai nekalbėsiu. Jei domina, galite pasižiūrėti .
Taip pat yra geras Mike'o Rotherio pokalbis šia tema:
6. Į rinką orientuota: į rinką orientuota organizacija
Čia yra įvairių problemų. Pavyzdžiui, „I“ žmonės, „T“ žmonės ir „E“ žmonės. „Aš“ žmonės yra tie, kurie daro tik vieną dalyką. Paprastai jie egzistuoja organizacijose, turinčiose atskirus skyrius. "T" yra tada, kai žmogus yra geras vienu dalyku, bet taip pat gerai kai kuriuos kitus dalykus. „E“ ar net „šukos“ yra tada, kai žmogus turi daug įgūdžių.
Čia veikia Conway įstatymas (), kurį supaprastinta forma galima pasakyti taip: jei prie kompiliatoriaus dirba trys komandos, rezultatas bus trijų dalių sudarytojas. Todėl, jei organizacijoje yra didelis izoliacijos lygis, net Kubernetes, Circuit breaker, API išplėtimas ir kiti įmantrūs dalykai šioje organizacijoje bus išdėstyti taip pat, kaip ir pati organizacija. Griežtai pagal Conway ir nepaisant visų jūsų jaunų geikų.
Šios problemos sprendimas buvo aprašytas daugybę kartų. Pavyzdžiui, yra Fernando Fernandezo aprašytų organizacinių archetipų. Ta probleminė architektūra, apie kurią ką tik kalbėjau, su izoliacija yra į funkcijas orientuota architektūra. Antrasis tipas yra blogiausia, matricinė architektūra, kitų dviejų netvarka. Trečiasis – tai, ką mato dauguma startuolių, o didelės įmonės taip pat bando prilygti šiam tipui. Tai į rinką orientuota organizacija. Čia mes optimizuojame, kad galėtume greičiau reaguoti į klientų užklausas. Tai kartais vadinama plokščia organizacija.
Daugelis žmonių šią struktūrą apibūdina įvairiai, man patinka formuluotė kurti/vadovauti komandas, „Amazon“ jie tai vadina dvi picų komandos. Šioje struktūroje visi „I“ tipo žmonės yra sugrupuoti aplink vieną paslaugą ir pamažu priartėja prie „T“ tipo, o jei yra tinkamas valdymas, gali tapti net „E“. Pirmasis kontrargumentas čia yra tas, kad tokioje struktūroje yra nereikalingų elementų. Kam kiekviename skyriuje reikalingas testeris, jei galima turėti specialų testuotojų skyrių? Į ką atsakau: papildomi kaštai šiuo atveju yra kaina, kad visa organizacija ateityje taptų „E“ tipu. Šioje struktūroje testuotojas palaipsniui sužino apie tinklus, architektūrą, dizainą ir kt. Dėl to kiekvienas organizacijos dalyvis puikiai žino viską, kas vyksta organizacijoje. Jei norite sužinoti, kaip ši schema veikia pramonėje, skaitykite .
7. Auditoriai, dirbantys į kairę: auditas ciklo pradžioje. Ekrano saugos taisyklių laikymasis
Tai yra tada, kai jūsų veiksmai, taip sakant, neišlaiko kvapo testo. Žmonės, kurie dirba jums, nėra kvaili. Jei, kaip aukščiau pateiktame pavyzdyje, jie visur nustatė nedidelį / jokio poveikio, tai truko trejus metus ir niekas nieko nepastebėjo, tada visi puikiai žino, kad sistema neveikia. Arba kitas pavyzdys – pokyčių konsultacinė taryba, kur ataskaitas reikia teikti kiekvieną, tarkime, trečiadienį. Ten dirba grupė žmonių (beje, nelabai gerai apmokamų), kurie teoriškai turėtų žinoti, kaip veikia visa sistema. Ir per pastaruosius penkerius metus tikriausiai pastebėjote, kad mūsų sistemos yra neįtikėtinai sudėtingos. Ir penki ar šeši žmonės turi priimti sprendimą dėl pakeitimo, kurio jie nepadarė ir apie kurį nieko nežino.
Žinoma, šis metodas neveikia. Turiu atsikratyti tokių dalykų, nes šie žmonės nesaugo sistemos. Sprendimą turi priimti pati komanda, nes komanda už tai turi būti atsakinga. Priešingu atveju susidaro paradoksali situacija, kai niekada gyvenime kodo nerašęs vadovas programuotojui pasako, kiek laiko turėtų užtrukti kodo parašymas. Viena įmonė, su kuria dirbau, turėjo 7 skirtingas lentas, kurios peržiūrėjo kiekvieną pakeitimą, įskaitant architektūros plokštę, gaminio lentą ir kt. Buvo net privalomas laukimo laikotarpis, nors viena darbuotoja man pasakojo, kad per dešimt darbo metų niekas niekada neatmetė šio asmens per šį privalomą laikotarpį padaryto pakeitimo.
Auditorius reikia kviesti prisijungti prie mūsų, o ne jų atsikratyti. Pasakykite jiems, kad rašote nekintamus dvejetainius konteinerius, kurie, išlaikę visus testus, išliks nekintami amžinai. Pasakykite jiems, kad turite konvejerį kaip kodą, ir paaiškinkite, ką tai reiškia. Parodykite jiems tokią schemą: nekintantis tik skaitomas dvejetainis failas konteineryje, kuris išlaiko visus pažeidžiamumo testus; ir tada ne tik niekas jo neliečia, bet net neliečia sistemos, kuri sukuria dujotiekį, nes jis taip pat kuriamas dinamiškai. Turiu klientų „Capital One“, kurie naudoja „Vault“, kad sukurtų kažką panašaus į „blockchain“. Auditoriui nereikia rodyti „Chef“ „receptų“, užtenka parodyti blokų grandinę, iš kurios aišku, kas atsitiko su gaminamu Jira bilietu ir kas už tai atsakingas.
Pagal 2018 m. sukūrė Sonatype, 2017 m. buvo 87 milijardai OSS atsisiuntimo užklausų.
Nuostoliai, patirti dėl pažeidžiamumo, yra didžiuliai. Be to, skaičiai, kuriuos dabar matote aukščiau, neapima alternatyvių išlaidų. Kas yra DevSecOps trumpai? Iš karto pasakysiu, kad man neįdomu kalbėti apie tai, koks sėkmingas šis vardas. Esmė ta, kad kadangi „DevOps“ buvo tokia sėkminga, turėtume pabandyti padidinti šio dujotiekio saugumą.
Šios sekos pavyzdys:
Tai nėra rekomendacija konkretiems produktams, nors man jie visi patinka. Pateikiau juos kaip pavyzdį, norėdamas parodyti, kad „DevOps“, kuri iš pradžių buvo pagrįsta organizacine pramonės paradigma, leidžia automatizuoti kiekvieną darbo su produktu etapą.
Ir nėra jokios priežasties, kodėl negalėtume laikytis tokio paties požiūrio į saugumą.
Visas
Baigdamas pateiksiu keletą „DevSecOps“ patarimų. Į savo sistemų kūrimo procesą turite įtraukti auditorius ir skirti laiko jiems mokyti. Reikia bendradarbiauti su auditoriais. Be to, jums reikia visiškai negailestingai kovoti su klaidingais teigiamais rezultatais. Net ir naudodami brangiausią pažeidžiamumo nuskaitymo įrankį, galite susikurti itin blogus savo kūrėjų įpročius, jei nežinote, koks yra signalo ir triukšmo santykis. Kūrėjai bus priblokšti įvykių ir tiesiog juos ištrins. Jei girdėjote apie „Equifax“ istoriją, beveik taip ir atsitiko ten, kur buvo ignoruojamas aukščiausias įspėjimo lygis. Be to, pažeidžiamumas turi būti paaiškintas taip, kad būtų aišku, kaip jie veikia verslą. Pavyzdžiui, galite pasakyti, kad tai yra tas pats pažeidžiamumas, kaip ir Equifax istorijoje. Saugos pažeidžiamumas turėtų būti traktuojamas taip pat, kaip ir kitos programinės įrangos problemos, ty jie turėtų būti įtraukti į bendrą „DevOps“ procesą. Su jais reikia dirbti per Jira, Kanban ir kt. Kūrėjai neturėtų manyti, kad tai padarys kažkas kitas – priešingai, visi turėtų tai daryti. Galiausiai reikia skirti energiją žmonių mokymui.
Naudingos nuorodos
Štai keletas „DevOops“ konferencijos pokalbių, kurie jums gali būti naudingi:
- Sergejus Berdnikovas, Artiomas Kaličkinas – sėkmės istorija arba „Dev+DevOps+Ops“ (, )
- Baruchas Sadogurskis, Leonidas Igolnikas - DevOps mastu: graikų tragedija trijuose veiksmuose (, )
- Aleksandras Titovas, Kirilas Tolkačiovas -
- Timothy Lister -
Įsižiūrėk DevOops 2020 Maskva — ten taip pat daug įdomių dalykų.
Šaltinis: www.habr.com