ProHoster > Septiņi transformācijas arhetipi, kuru pamatā ir DevOps principi

Septiņi transformācijas arhetipi, kuru pamatā ir DevOps principi

Jautājums ā€œkā ieviest devopsā€ pastāv jau gadiem ilgi, taču labu materiālu nav daudz. Dažreiz jÅ«s kļūstat par upuri reklāmām no ne pārāk gudriem konsultantiem, kuriem ir jāpārdod savs laiks, neatkarÄ«gi no tā, kā. Dažreiz tie ir neskaidri, ārkārtÄ«gi vispārÄ«gi vārdi par to, kā megakorporāciju kuÄ£i ara Visuma plaÅ”umus. Rodas jautājums: ko tas mums nozÄ«mē? CienÄ«jamais autor, vai varat skaidri formulēt savas idejas sarakstā?

Tas viss izriet no tā, ka nav uzkrāta liela reāla prakse un izpratne par uzņēmuma kultÅ«ras transformāciju iznākumu. Izmaiņas kultÅ«rā ir ilgtermiņa lietas, kuru rezultāti neparādÄ«sies ne pēc nedēļas, ne pēc mēneÅ”a. Mums ir vajadzÄ«gs kāds pietiekami vecs, lai bÅ«tu redzējis, kā uzņēmumi ir veidoti un neveiksmÄ«gi gadu gaitā.

Septiņi transformācijas arhetipi, kuru pamatā ir DevOps principi

Džons Viliss - viens no DevOps tēviem. Džonam ir gadu desmitiem ilga pieredze darbā ar ļoti daudziem uzņēmumiem. Nesen Džons sāka pamanÄ«t konkrētus modeļus, kas rodas, strādājot ar katru no tiem. Izmantojot Å”os arhetipus, Džons virza uzņēmumus uz patieso DevOps transformācijas ceļu. Vairāk par Å”iem arhetipiem lasiet viņa ziņojuma tulkojumā no konferences DevOops 2018.

Par runātāju:

Vairāk nekā 35 gadus IT pārvaldÄ«bā, piedalÄ«jies OpenCloud priekÅ”gājēja izveidē Canonical, piedalÄ«jies 10 jaunuzņēmumos, no kuriem divi tika pārdoti Dell un Docker. PaÅ”laik viņŔ ir SJ Technologies DevOps un digitālās prakses viceprezidents.

Nākamais ir stāsts no Jāņa viedokļa.

Mani sauc Džons Viliss, un visvieglāk mani atrast ir vietnē Twitter. @botchagalupe. Man ir tāds pats aizstājvārds pakalpojumā Gmail un GitHub. A ar Å”o saiti jÅ«s varat atrast manu ziņojumu video ierakstus un prezentācijas tiem.

Man ir daudzas tikÅ”anās ar dažādu lielu uzņēmumu CIO. Viņi ļoti bieži sÅ«dzas, ka nesaprot, kas ir DevOps, un visi, kas mēģina viņiem to izskaidrot, runā par kaut ko citu. Vēl viena izplatÄ«ta sÅ«dzÄ«ba ir tāda, ka DevOps nedarbojas, lai gan Ŕķiet, ka direktori dara visu, kā viņiem paskaidrots. Mēs runājam par lieliem uzņēmumiem, kas ir vairāk nekā simts gadus veci. Pēc sarunas ar viņiem nonācu pie secinājuma, ka daudzām problēmām vislabāk piemērotas nevis augstās tehnoloÄ£ijas, bet gan salÄ«dzinoÅ”i zemo tehnoloÄ£iju risinājumi. Vairākas nedēļas es vienkārÅ”i runāju ar cilvēkiem no dažādām nodaļām. Tas, ko redzat paŔā pirmajā bildē ierakstā, ir mans pēdējais projekts, lÅ«k, kā telpa izskatÄ«jās pēc trÄ«s darba dienām.

Kas ir DevOps?

PatieŔām, ja pajautāsiet 10 dažādiem cilvēkiem, viņi sniegs 10 dažādas atbildes. Bet Å”eit ir interesanta lieta: visas desmit Ŕīs atbildes bÅ«s pareizas. Å eit nav nepareizas atbildes. Es diezgan iedziļinājos DevOps, apmēram 10 gadus, un biju pirmais amerikānis pirmajā DevOpsDay. Es neteikÅ”u, ka esmu gudrāks par visiem DevOps iesaistÄ«tajiem, taču diez vai ir kāds, kurÅ” tam ir veltÄ«jis tik daudz pūļu. Es uzskatu, ka DevOps rodas, kad cilvēkkapitāls un tehnoloÄ£ijas saplÅ«st. Mēs bieži aizmirstam par cilvēcisko dimensiju, lai gan mēs daudz runājam par visu veidu kultÅ«rām.

Septiņi transformācijas arhetipi, kuru pamatā ir DevOps principi

Tagad mums ir daudz datu, piecus gadus ilga akadēmiskā izpēte, teoriju pārbaude rÅ«pnieciskā mērogā. Å ie pētÄ«jumi mums liecina, ka, apvienojot dažus uzvedÄ«bas modeļus organizācijas kultÅ«rā, jÅ«s varat sasniegt 2000 reižu paātrinājumu. Å im paātrinājumam ir lÄ«dzvērtÄ«gs stabilitātes uzlabojums. Å is ir kvantitatÄ«vs mērÄ«jums ieguvumam, ko DevOps var sniegt jebkuram uzņēmumam. Pirms pāris gadiem par DevOps runāju ar Fortune 5000 kompānijas izpilddirektoru.Kad gatavojos prezentācijai, ļoti nervozēju, jo 5 minÅ«tēs bija jāapkopo sava gadu pieredze.

Beigās iedevu sekojoÅ”o DevOps definÄ«cija: tas ir prakÅ”u un modeļu kopums, kas ļauj pārveidot cilvēkkapitālu augstas veiktspējas organizācijas kapitālā. Piemērs ir veids, kā Toyota ir darbojusies pēdējos 50 vai 60 gadus.

Septiņi transformācijas arhetipi, kuru pamatā ir DevOps principi

(Turpmāk Ŕādas diagrammas tiek sniegtas nevis kā izziņas materiāls, bet gan kā ilustrācijas. Katram jaunam uzņēmumam to saturs bÅ«s atŔķirÄ«gs. Taču attēlu var apskatÄ«t atseviŔķi un palielināt Å”ajā saitē.)

Viena no veiksmÄ«gākajām Ŕādām praksēm ir vērtÄ«bu plÅ«sma kartÄ“Å”ana. Par to ir uzrakstÄ«tas vairākas labas grāmatas, no kurām veiksmÄ«gākās ir Kārena Mārtina. Taču pēdējā gada laikā esmu nonācis pie secinājuma, ka pat Ŕī pieeja ir pārāk augsto tehnoloÄ£iju. Tam noteikti ir daudz priekÅ”rocÄ«bu, un es to esmu daudz izmantojis. Bet, kad izpilddirektors jautā, kāpēc viņa uzņēmums nevar pāriet uz jaunām sliedēm, ir pāragri runāt par vērtÄ«bu plÅ«smas kartÄ“Å”anu. Ir daudzi daudz bÅ«tiskāki jautājumi, uz kuriem vispirms ir jāatbild.

Es domāju, ka kļūda, ko pieļauj daudzi mani kolēģi, ir tāda, ka viņi vienkārÅ”i sniedz uzņēmumam piecu punktu rokasgrāmatu un pēc seÅ”iem mēneÅ”iem atgriežas un paskatās, kas noticis. Pat tādā labā shēmā kā vērtÄ«bu plÅ«smas kartÄ“Å”ana ir, teiksim, aklās zonas. Pēc simtiem interviju ar dažādu uzņēmumu direktoriem esmu izstrādājis noteiktu modeli, kas ļauj mums sadalÄ«t problēmu tā sastāvdaļās, un tagad mēs apspriedÄ«sim katru no Å”iem komponentiem secÄ«bā. Pirms jebkuru tehnoloÄ£isko risinājumu pielietoÅ”anas es izmantoju Å”o modeli, un rezultātā visas manas sienas ir pārklātas ar diagrammām. Nesen es strādāju ar ieguldÄ«jumu fondu, un man bija 100-150 Ŕādas shēmas.

Slikta kultūra brokastīs ēd labas pieejas

Galvenā doma ir Ŕāda: nekāds Lean, Agile, SAFE un DevOps daudzums nepalÄ«dzēs, ja pati organizācijas kultÅ«ra ir slikta. Tas ir kā nirÅ”ana dziļumā bez akvalangu aprÄ«kojuma vai darbÄ«ba bez rentgena. Citiem vārdiem sakot, pārfrāzējot Drukeru un Demingu: slikta organizācijas kultÅ«ra aprÄ«s jebkuru labu sistēmu, ar to neaizroties.

Lai atrisinātu Å”o galveno problēmu, jums jāveic Ŕādas darbÄ«bas:

  1. Padarīt visu darbu redzamu: jums ir jāpadara viss darbs redzams. Ne tādā nozīmē, ka tas obligāti ir jāparāda uz kāda ekrāna, bet gan tādā nozīmē, ka tam ir jābūt novērojamam.
  2. Konsolidētās darba vadÄ«bas sistēmas: vadÄ«bas sistēmas ir jākonsolidē. ā€œCilÅ”uā€ zināŔanu un institucionālo zināŔanu problēmā 9 gadÄ«jumos no 10 pudeles kakls ir cilvēki. Grāmatā "Fēniksa projekts" Problēma bija ar vienu cilvēku Brentu, kura dēļ projekts trÄ«s gadus atpalika no grafika. Un es visur saskāros ar Å”iem "Brentiem". Lai novērstu Ŕīs vājās vietas, es izmantoju nākamos divus mÅ«su saraksta vienumus.
  3. Ierobežojumu teorijas metodoloģija: ierobežojumu teorija.
  4. Sadarbības uzlauzumi: sadarbības hacks.
  5. Toyota Kata (Treneris Kata): Es daudz nerunāŔu par Toyota Kata. Ja interesē, manā githubā ir prezentācijas gandrÄ«z par katru no Ŕīm tēmām.
  6. Uz tirgu orientēta organizācija: uz tirgu orientēta organizācija.
  7. Revidenti ar maiņu pa kreisi: audits cikla sākumposmā.

Septiņi transformācijas arhetipi, kuru pamatā ir DevOps principi

Es sāku strādāt ar organizāciju ļoti vienkārÅ”i: dodos uz uzņēmumu un runāju ar darbiniekiem. Kā redzat, nav augsto tehnoloÄ£iju. Viss, kas jums nepiecieÅ”ams, ir kaut kas, uz kura rakstÄ«t. Es sapulcinu vairākas komandas vienā telpā un analizēju, ko tās man saka no manu 7 arhetipu perspektÄ«vas. Un tad es viņiem paÅ”iem iedodu marÄ·ieri un lÅ«dzu pierakstÄ«t uz tāfeles visu, ko viņi lÄ«dz Å”im ir teikuÅ”i skaļi. Parasti Ŕāda veida sanāksmēs ir viens cilvēks, kurÅ” visu pieraksta, un labākajā gadÄ«jumā var pierakstÄ«t 10% no diskusijas. Ar manu metodi Å”o skaitli var palielināt lÄ«dz aptuveni 40%.

Septiņi transformācijas arhetipi, kuru pamatā ir DevOps principi

(Šo ilustrāciju var apskatīt atseviŔķi skatīt saiti)

Mana pieeja ir balstīta uz Viljama Šneidera darbu. Reinženierijas alternatīva). Pieejas pamatā ir ideja, ka jebkuru organizāciju var iedalīt četros kvadrātos. Šī shēma man parasti ir rezultāts, strādājot ar simtiem citu shēmu, kas rodas, analizējot organizāciju. Pieņemsim, ka mums ir organizācija ar augstu kontroles līmeni, bet ar zemu kompetenci. Tas ir ārkārtīgi nevēlams variants: kad visi spārno līniju, bet neviens nezina, ko darīt.

Nedaudz labāks variants ir tāds ar augstu kontroles un kompetences lÄ«meni. Ja Ŕāds uzņēmums ir rentabls, tad varbÅ«t tam nav nepiecieÅ”ams DevOps. Visinteresantāk ir strādāt ar uzņēmumu, kuram ir augsts kontroles lÄ«menis, zema kompetence un sadarbÄ«ba, bet tajā paŔā laikā augsts kultÅ«ras (kopÅ”anas) lÄ«menis. Tas nozÄ«mē, ka uzņēmumā ir daudz cilvēku, kuriem patÄ«k tur strādāt un darbaspēka mainÄ«ba ir zema.

Septiņi transformācijas arhetipi, kuru pamatā ir DevOps principi

(Šo ilustrāciju var apskatīt atseviŔķi skatīt saiti)

Man Ŕķiet, ka metodes ar stingrām vadlÄ«nijām galu galā kavē patiesÄ«bas sasniegÅ”anu. Jo Ä«paÅ”i vērtÄ«bu plÅ«smas kartÄ“Å”anā ir daudz noteikumu par informācijas strukturÄ“Å”anu. Darba sākumposmā, par ko es runāju tagad, Å”ie noteikumi nevienam nav vajadzÄ«gi. Ja cilvēks ar marÄ·ieri rokās uz tāfeles apraksta reālo situāciju uzņēmumā, tas ir labākais veids, kā izprast lietu stāvokli. Šāda informācija nenonāk pie direktoriem. Å ajā brÄ«dÄ« ir stulbi pārtraukt cilvēku un teikt, ka viņŔ kaut kādu bultu uzzÄ«mējis nepareizi. Å ajā posmā labāk ir izmantot vienkārÅ”us noteikumus, piemēram: daudzlÄ«meņu abstrakciju var izveidot, vienkārÅ”i izmantojot daudzkrāsainus marÄ·ierus.

Es atkārtoju, nav augsto tehnoloÄ£iju. Melnais marÄ·ieris attēlo objektÄ«vo realitāti, kā viss darbojas. Ar sarkanu marÄ·ieri cilvēki atzÄ«mē to, kas viņiem nepatÄ«k paÅ”reizējā situācijā. Ir svarÄ«gi, lai viņi to raksta, nevis es. Kad es dodos uz CIO pēc tikÅ”anās, es nepiedāvāju sarakstu ar 10 lietām, kas jālabo. Es cenÅ”os atrast saikni starp to, ko cilvēki saka uzņēmumā, un esoÅ”ajiem pārbaudÄ«tajiem modeļiem. Visbeidzot, zils marÄ·ieris piedāvā iespējamos problēmas risinājumus.

Septiņi transformācijas arhetipi, kuru pamatā ir DevOps principi

(Šo ilustrāciju var apskatīt atseviŔķi skatīt saiti)

Å Ä«s pieejas piemērs tagad ir attēlots iepriekÅ”. Å Ä« gada sākumā strādāju vienā bankā. Apsardzes darbinieki bija pārliecināti, ka viņiem nevajadzētu nākt uz dizaina un prasÄ«bu pārskatÄ«Å”anu.

Septiņi transformācijas arhetipi, kuru pamatā ir DevOps principi

(Šo ilustrāciju var apskatīt atseviŔķi skatīt saiti)

Un tad mēs runājām ar cilvēkiem no citām nodaļām, un izrādÄ«jās, ka pirms aptuveni 8 gadiem programmatÅ«ras izstrādātāji atlaida apsardzes darbiniekus, jo viņi bremzēja darbu. Un tad tas pārvērtās par aizliegumu, kas tika uzskatÄ«ts par paÅ”saprotamu. Lai gan patiesÄ«bā aizlieguma nebija.

MÅ«su tikÅ”anās noritēja ārkārtÄ«gi mulsinoÅ”i: apmēram trÄ«s stundas piecas dažādas komandas man nevarēja izskaidrot, kas notiek starp kodu un montāžu. Un Ŕī, Ŕķiet, ir visvienkārŔākā lieta. Lielākā daļa DevOps konsultantu jau iepriekÅ” pieņem, ka visi to jau zina.

Tad par IT pārvaldÄ«bu atbildÄ«gais cilvēks, kurÅ” četras stundas bija klusējis, pēkŔņi atdzÄ«vojās, kad tikām pie viņa tēmas, un nodarbināja mÅ«s ļoti ilgi. Beigās es viņam jautāju, ko viņŔ domā par tikÅ”anos, un es nekad neaizmirsÄ«Å”u viņa atbildi. ViņŔ teica: "Es agrāk domāju, ka mÅ«su bankai ir tikai divi veidi, kā piegādāt programmatÅ«ru, bet tagad es zinu, ka ir pieci no tiem, un es pat nezināju par trim."

Septiņi transformācijas arhetipi, kuru pamatā ir DevOps principi

(Šo ilustrāciju var apskatīt atseviŔķi skatīt saiti)

Pēdējā tikÅ”anās Å”ajā bankā bija ar investÄ«ciju programmatÅ«ras komandu. TieÅ”i ar viņu izrādÄ«jās, ka diagrammu rakstÄ«Å”ana ar marÄ·ieri uz papÄ«ra lapas ir labāka nekā uz tāfeles un pat labāk nekā uz viedtālruņa.

Septiņi transformācijas arhetipi, kuru pamatā ir DevOps principi

Redzamās fotogrāfijas ir tādas, kā izskatÄ«jās viesnÄ«cas konferenču telpa mÅ«su tikÅ”anās ceturtajā dienā. Un mēs izmantojām Ŕīs shēmas, lai meklētu modeļus, tas ir, arhetipus.

Tāpēc es uzdodu strādniekiem jautājumus, viņi pieraksta atbildes ar trīs krāsu marķieriem (melnā, sarkanā un zilā). Es analizēju viņu atbildes arhetipiem. Tagad apspriedīsim visus arhetipus secībā.

1. Padariet visu darbu redzamu: padariet darbu redzamu

Lielākajā daļā uzņēmumu, ar kuriem es strādāju, ir ļoti liels nezināmā darba procents. Piemēram, tas ir, kad viens darbinieks pienāk pie otra un vienkārÅ”i lÅ«dz kaut ko izdarÄ«t. Lielajās organizācijās var bÅ«t 60% neplānotu darbu. Un lÄ«dz pat 40% darba nav nekādi dokumentēti. Ja tas bÅ«tu Boeing, es nekad mūžā vairs neiekāptu viņu lidmaŔīnā. Ja dokumentēta ir tikai puse darba, tad nav zināms, vai Å”is darbs tiek veikts pareizi vai nē. Visas pārējās metodes izrādās bezjēdzÄ«gas - nav jēgas mēģināt kaut ko automatizēt, jo zināmie 50% var bÅ«t sakarÄ«gākā un skaidrākā darba daļa, kuras automatizācija nedos lieliskus rezultātus, un viss sliktākais lietas atrodas neredzamajā pusē. Ja nav dokumentācijas, nav iespējams atrast visdažādākos hacks un slēptos darbus, neatrast saÅ”aurinājumus, tos paÅ”us ā€œBrentusā€, par kuriem es jau runāju. Ir brÄ«niŔķīga Dominikas DeGrandisas grāmata "PadarÄ«t darbu redzamu". Viņa atklāj piecas dažādas "laika noplÅ«des" (laika zagļi):

  • Pārāk daudz darba procesā (WIP)
  • Nezināmas atkarÄ«bas
  • Neplānots Darbs
  • PretrunÄ«gas prioritātes
  • Novārtā atstāts darbs

Å Ä« ir ļoti vērtÄ«ga analÄ«ze, un grāmata ir lieliska, taču visi Å”ie padomi ir bezjēdzÄ«gi, ja ir redzami tikai 50% datu. Dominikas piedāvātās metodes var izmantot, ja tiek sasniegta precizitāte virs 90%. Es runāju par situācijām, kad priekÅ”nieks dod padotajam 15 minÅ«Å”u uzdevumu, bet viņam tas prasa trÄ«s dienas; bet priekÅ”nieks Ä«sti nezina, ka Å”is padotais ir vēl četru vai piecu cilvēku apgādÄ«bā.

Septiņi transformācijas arhetipi, kuru pamatā ir DevOps principi

Fēniksa projekts ir brÄ«niŔķīgs stāsts par projektu, kas bija trÄ«s gadus par vēlu. Vienam no varoņiem Ŕī iemesla dēļ draud atlaiÅ”ana, un viņŔ satiekas ar citu varoni, kurÅ” tiek pasniegts kā sava veida Sokrāts. ViņŔ palÄ«dz noskaidrot, kas tieÅ”i nogāja greizi. Izrādās, ka uzņēmumam ir viens sistēmas administrators, kuru sauc Brents, un viss darbs kaut kā iet caur viņu. Kādā no sanāksmēm kādam no padotajiem jautā: kāpēc katrs pusstundas uzdevums aizņem nedēļu? Atbilde ir ļoti vienkārÅ”ota rindu teorijas un Litāla likuma izklāsts, un Å”ajā prezentācijā izrādās, ka pie 90% noslogojuma katra darba stunda aizņem 9 stundas. Katrs uzdevums ir jānosÅ«ta vēl septiņiem cilvēkiem, lai Ŕī stunda kļūtu par 63 stundām, 7 reizes 9. Es saku, ka, lai izmantotu Litla likumu vai jebkuru sarežģītu rindu teoriju, jums vismaz ir jābÅ«t datiem.

Tātad, kad es runāju par redzamÄ«bu, es nedomāju, ka viss ir redzams ekrānā, bet gan to, ka jums vismaz ir dati. Kad viņi to dara, bieži vien izrādās, ka ir ļoti liels neplānotu darbu apjoms, kas kaut kā tiek nosÅ«tÄ«ts uz Brentu, kad tas nav nepiecieÅ”ams. Un Brents ir lielisks puisis, viņŔ nekad neteiks nē, bet viņŔ nevienam nestāsta, kā viņŔ dara savu darbu.

Septiņi transformācijas arhetipi, kuru pamatā ir DevOps principi

Kad darbs ir redzams, datus var glīti klasificēt (tā fotogrāfijā dara Dominika), pielietot piecu laika noplūžu abstrakciju un pielietot automatizāciju.

2. Darba vadības sistēmu konsolidācija: uzdevumu pārvaldība

Arhetipi, par kuriem es runāju, ir sava veida piramÄ«da. Ja pirmais ir izdarÄ«ts pareizi, tad otrais jau ir sava veida papildinājums. Daudzi no tiem nedarbojas jaunizveidotiem uzņēmumiem, tie ir jāpatur prātā lielākiem uzņēmumiem, piemēram, Fortune 5000. Pēdējā uzņēmumā, kurā strādāju, bija 10 biļeÅ”u pārdoÅ”anas sistēmas. Vienai komandai bija Remedy, cita rakstÄ«ja kaut kādu savu sistēmu, treŔā izmantoja Jira, un dažas iztika ar e-pastu. Tāda pati problēma rodas, ja uzņēmumam ir 30 dažādi cauruļvadi, bet man nav laika apspriest visus Ŕādus gadÄ«jumus.

Es pārrunāju ar cilvēkiem, kā tieÅ”i tiek veidotas biļetes, kas ar viņiem notiek tālāk un kā tās tiek apietas. Interesantākais ir tas, ka cilvēki mÅ«su sanāksmēs runā diezgan patiesi. Es jautāju, cik daudz cilvēku uz biļetēm ievieto "neliela/bez ietekmes", kam patiesÄ«bā bÅ«tu jāpieŔķir "liela ietekme". IzrādÄ«jās, ka gandrÄ«z visi to dara. Es neiesaistos denonsācijā un visos iespējamos veidos cenÅ”os neidentificēt cilvēkus. Kad viņi man kaut ko patiesi atzÄ«st, es to cilvēku neatdodu. Bet, kad gandrÄ«z visi apiet sistēmu, tas nozÄ«mē, ka visa droŔība bÅ«tÄ«bā ir logu dekorÄ“Å”ana. Tāpēc no Ŕīs sistēmas datiem nevar izdarÄ«t secinājumus.

Lai atrisinātu biļeÅ”u problēmu, jums jāizvēlas viena galvenā sistēma. Ja lietojat Jira, saglabājiet to Jira. Ja ir kāda alternatÄ«va, lai tā ir vienÄ«gā. BÅ«tÄ«ba ir tāda, ka biļetes ir jāuztver kā vēl viens solis izstrādes procesā. Katrai darbÄ«bai ir jābÅ«t biļetei, kurai jāplÅ«st cauri izstrādes darbplÅ«smai. Biļetes tiek nosÅ«tÄ«tas komandai, kas tās ievieto sižeta plānā un pēc tam uzņemas par tām atbildÄ«bu.

Tas attiecas uz visiem departamentiem, ieskaitot infrastruktÅ«ru un operācijas. Å ajā gadÄ«jumā ir iespējams izveidot vismaz kādu ticamu priekÅ”statu par lietu stāvokli. Kad Å”is process ir izveidots, pēkŔņi kļūst viegli noteikt, kurÅ” ir atbildÄ«gs par katru pieteikumu. Jo tagad mēs saņemam nevis 50%, bet 98% jauno pakalpojumu. Ja Å”is pamatprocess darbojas, tad visā sistēmā uzlabojas precizitāte.

Pakalpojumu cauruļvads

Tas atkal attiecas tikai uz lielajām korporācijām. Ja esat jauns uzņēmums jaunā jomā, atrotiet piedurknes un strādājiet ar savu Travis CI vai CircleCI. Runājot par Fortune 5000 uzņēmumiem, piemērs, kas notika bankā, kurā es strādāju. Google ieradās pie viņiem, un viņiem tika parādÄ«tas veco IBM sistēmu diagrammas. PuiÅ”i no Google neizpratnē jautāja ā€“ kur tam ir pirmkods? Bet nav avota koda, pat ne GUI. Tā ir realitāte, ar kuru jāsastopas lielām organizācijām: 40 gadus veci bankas ieraksti senā lieldatorā. Viens no maniem klientiem KeyBank lietojumprogrammai izmanto Kubernetes konteinerus ar Circuit Breaker modeļiem, kā arÄ« Chaos Monkey. Bet Å”ie konteineri galu galā savienojas ar COBOL lietojumprogrammu.

Google puiÅ”i bija pilnÄ«gi pārliecināti, ka atrisinās visas mana klienta problēmas, un tad sāka uzdot jautājumus: kas ir IBM datu caurule? Viņiem saka: tas ir savienotājs. Ar ko tas ir saistÄ«ts? Uz Sperry sistēmu. Un kas tas ir? Un tā tālāk. No pirmā acu uzmetiena Ŕķiet: kāda veida DevOps var bÅ«t? Bet patiesÄ«bā tas ir iespējams. Ir piegādes sistēmas, kas ļauj nodot darbplÅ«smu piegādes komandām.

3. Ierobežojumu teorija: Ierobežojumu teorija

Pārejam pie treŔā arhetipa: institucionālās/"cilts" zināŔanas. Kā likums, jebkurā organizācijā ir vairāki cilvēki, kas visu zina un visu pārvalda. Tie ir tie, kuri ir bijuÅ”i organizācijā visilgāk un zina visus risinājumus.

Septiņi transformācijas arhetipi, kuru pamatā ir DevOps principi

Kad tas parādās diagrammā, es Ä«paÅ”i apvelku Ŕādus cilvēkus ar marÄ·ieri: piemēram, izrādās, ka kāds LÅ« ir klāt visās sanāksmēs. Un man ir skaidrs: tas ir vietējais Brent. Kad CIO izvēlas starp mani T-kreklā un kedas un puisi no IBM uzvalkā, es esmu izvēlēts, jo es varu pateikt direktoram lietas, ko otrs puisis nestāstÄ«s un ko direktoram varētu nepatikt dzirdēt. . Es viņiem saku, ka viņu uzņēmuma vājais kakls ir kāds Freds un kāds LÅ«. Å o saÅ”aurinājumu vajag atraisÄ«t, zināŔanas tādā vai citādā veidā no viņiem jāiegÅ«st.

Lai atrisinātu Ŕāda veida problēmu, es, piemēram, varu ieteikt izmantot Slack. Gudrs režisors jautās ā€“ kāpēc? Parasti Ŕādos gadÄ«jumos DevOps konsultanti atbild: jo visi tā dara. Ja režisors tieŔām ir gudrs, viņŔ teiks: nu ko. Un Å”eit dialogs beidzas. Un mana atbilde uz to ir: jo uzņēmumā ir četri vājās vietas, Freds, LÅ«, SÅ«zija un Džeina. Lai institucionalizētu viņu zināŔanas, vispirms jāievieÅ” Slack. Visas jÅ«su wiki ir pilnÄ«gas muļķības, jo neviens nezina par to esamÄ«bu. Ja inženieru komanda ir iesaistÄ«ta priekÅ”gala un aizmugures izstrādē un ikvienam ir jāzina, ka viņi var sazināties ar priekÅ”gala izstrādes komandu vai infrastruktÅ«ras komandu ar jautājumiem. TieÅ”i tad LÅ« vai Fredam, iespējams, bÅ«s laiks pievienoties wiki. Un tad Slack kāds varētu jautāt, kāpēc, piemēram, 5. darbÄ«ba nedarbojas. Un tad LÅ« vai Freds izlabos norādÄ«jumus wiki. Ja izveidosit Å”o procesu, daudzas lietas nostāsies savās vietās.

Tas ir mans galvenais: lai ieteiktu kādas augstās tehnoloÄ£ijas, vispirms ir jāsakārto pamati tām, un to var izdarÄ«t ar tikko aprakstÄ«tajiem zemo tehnoloÄ£iju risinājumiem. Ja sākat ar augstajām tehnoloÄ£ijām un nepaskaidrojat, kāpēc tās ir vajadzÄ«gas, tad parasti tas nebeidzas labi. Viens no mÅ«su klientiem izmanto Azure ML, ļoti lētu un vienkārÅ”u risinājumu. Uz aptuveni 30% viņu jautājumu atbildēja pati paÅ”mācÄ«bas maŔīna. Un Å”o lietu rakstÄ«ja operatori, kuri nebija saistÄ«ti ar datu zinātni, statistiku vai matemātiku. Tas ir nozÄ«mÄ«gi. Šāda risinājuma izmaksas ir minimālas.

4. Sadarbības uzlauzumi: sadarbības uzlauzumi

Ceturtais arhetips ir nepiecieÅ”amÄ«ba cÄ«nÄ«ties pret izolāciju. Lielākā daļa cilvēku to jau zina: izolācija rada naidÄ«gumu. Ja katra nodaļa atrodas savā stāvā, un cilvēki nekādi nekrustojas savā starpā, izņemot liftā, tad naidÄ«gums starp viņiem rodas ļoti viegli. Bet, ja, gluži pretēji, cilvēki atrodas vienā telpā, viņa nekavējoties aiziet. Kad kāds izmet kādu vispārēju apsÅ«dzÄ«bu, piemēram, tāds un tāds interfeiss nekad nestrādā, nav nekā vieglāk Ŕādu apsÅ«dzÄ«bu dekonstruēt. Programmētājiem, kuri uzrakstÄ«ja saskarni, vienkārÅ”i jāsāk uzdot konkrētus jautājumus, un drÄ«zumā kļūs skaidrs, ka, piemēram, lietotājs vienkārÅ”i nepareizi izmantojis rÄ«ku.

Ir daudz veidu, kā pārvarēt izolāciju. Man reiz lÅ«dza konsultēties par banku Austrālijā, bet es atteicos to darÄ«t, jo man ir divi bērni un sieva. Viss, ko es varēju viņiem palÄ«dzēt, bija ieteikt grafisku stāstÄ«jumu. Ir pierādÄ«ts, ka tas darbojas. Vēl viens interesants veids ir liesas kafijas sanāksmes. Lielā organizācijā Ŕī ir lieliska iespēja zināŔanu izplatÄ«Å”anai. Turklāt jÅ«s varat vadÄ«t iekŔējās devopsdienas, hakatonus un tā tālāk.

5. Koučings Kata

Kā jau brīdināju paŔā sākumā, Ŕodien par to nerunāŔu. Ja ir interese, varat apskatīties dažas no manām prezentācijām.

Par Å”o tēmu ir arÄ« laba saruna no Maika Rotera:

6. Tirgus orientēta: uz tirgu orientēta organizācija

Å eit ir dažādas problēmas. Piemēram, "I" cilvēki, "T" cilvēki un "E" cilvēki. ā€œEsā€ cilvēki ir tie, kas dara tikai vienu lietu. Parasti tie pastāv organizācijās ar izolētām nodaļām. "T" ir tad, kad persona ir laba vienā lietā, bet labi arÄ« citās lietās. "E" vai pat "Ä·emme" ir tad, kad cilvēkam ir daudz prasmju.

Septiņi transformācijas arhetipi, kuru pamatā ir DevOps principi

Å eit darbojas Konveja likums (Konveja likums), ko visvienkārŔākā veidā var izteikt Ŕādi: ja pie kompilatora strādā trÄ«s komandas, tad rezultāts bÅ«s trÄ«s daļu kompilators. LÄ«dz ar to, ja organizācijas iekÅ”ienē valda augsts izolācijas lÄ«menis, tad pat Kubernetes, Circuit breaker, API extensibility un citas izdomātas lietas Å”ajā organizācijā tiks sakārtotas tāpat kā pati organizācija. Stingri saskaņā ar Konveju un par spÄ«ti visiem jaunajiem džekiem.

Å Ä«s problēmas risinājums ir aprakstÄ«ts daudzas reizes. Ir, piemēram, Fernando Fernandesa aprakstÄ«tie organizatoriskie arhetipi. Å Ä« problemātiskā arhitektÅ«ra, par kuru es tikko runāju, ar izolāciju ir uz funkcijām orientēta arhitektÅ«ra. Otrais veids ir vissliktākā, matricas arhitektÅ«ra, pārējo divu haoss. TreÅ”ais ir tas, kas ir redzams lielākajā daļā jaunuzņēmumu, un arÄ« lielie uzņēmumi cenÅ”as lÄ«dzināties Å”im tipam. Tā ir uz tirgu orientēta organizācija. Å eit mēs veicam optimizāciju, lai sasniegtu ātrāko atbildi uz klientu pieprasÄ«jumiem. To dažreiz sauc par plakanu organizāciju.

Daudzi cilvēki Å”o struktÅ«ru raksturo dažādi, man patÄ«k formulējums veidot/vadÄ«t komandas, Amazon viņi to sauc divas picu komandas. Å ajā struktÅ«rā visi ā€œIā€ tipa cilvēki ir sagrupēti ap vienu pakalpojumu, un pamazām viņi kļūst tuvāk ā€œTā€ tipam, un, ja ir pareiza vadÄ«ba, viņi var kļūt pat par ā€œEā€. Pirmais pretarguments Å”eit ir tāds, ka Ŕādai struktÅ«rai ir nevajadzÄ«gi elementi. Kāpēc katrā nodaļā ir vajadzÄ«gs testeris, ja var izveidot Ä«paÅ”u testētāju nodaļu? Uz ko es atbildu: papildu izmaksas Å”ajā gadÄ«jumā ir cena, lai visa organizācija nākotnē kļūtu par ā€œEā€ tipu. Å ajā struktÅ«rā testētājs pamazām apgÅ«st tÄ«klus, arhitektÅ«ru, dizainu utt. Rezultātā ikviens organizācijas dalÄ«bnieks pilnÄ«bā apzinās visu, kas notiek organizācijā. Ja vēlaties uzzināt, kā Ŕī shēma darbojas rÅ«pniecÄ«bā, izlasiet Maiks Roters, Toyota Kata.

7. Revidenti ar maiņu pa kreisi: audits cikla sākumā. Izstādes droŔības noteikumu ievēroÅ”ana

Tas ir tad, kad jÅ«su darbÄ«bas neiztur smaržas pārbaudi, tā sakot. Cilvēki, kas strādā pie jums, nav stulbi. Ja, kā iepriekÅ” minētajā piemērā, viņi visur iestatÄ«ja nelielu/bez ietekmi, tas ilga trÄ«s gadus un neviens neko nepamanÄ«ja, tad visi lieliski zina, ka sistēma nedarbojas. Vai cits piemērs - pārmaiņu konsultatÄ«vā padome, kur atskaites jāiesniedz katru, teiksim, treÅ”dienu. Tur strādā cilvēku grupa (starp citu, ne pārāk labi atalgota), kuriem teorētiski bÅ«tu jāzina, kā sistēma kopumā darbojas. Un pēdējo piecu gadu laikā jÅ«s, iespējams, pamanÄ«jāt, ka mÅ«su sistēmas ir neticami sarežģītas. Un pieciem vai seÅ”iem cilvēkiem ir jāpieņem lēmums par izmaiņām, kuras viņi nav veikuÅ”i un par kurām viņi neko nezina.

Protams, Ŕī pieeja nedarbojas. Man ir jāatbrÄ«vojas no tādām lietām, jo ā€‹ā€‹Å”ie cilvēki neaizsargā sistēmu. Lēmums jāpieņem paÅ”ai komandai, jo komandai par to ir jāatbild. Citādi rodas paradoksāla situācija, kad vadÄ«tājs, kurÅ” nekad mūžā nav rakstÄ«jis kodu, programmētājam pasaka, cik ilgā laikā vajadzētu rakstÄ«t kodu. Vienam uzņēmumam, ar kuru es strādāju, bija 7 dažādi dēļi, kas pārskatÄ«ja visas izmaiņas, tostarp arhitektÅ«ras dēli, izstrādājumu paneli utt. Bija pat obligāts gaidÄ«Å”anas laiks, lai gan viens darbinieks man stāstÄ«ja, ka desmit darba gados neviens nav noraidÄ«jis Ŕīs personas veiktās izmaiņas Å”ajā obligātajā periodā.

Auditori ir jāaicina mums pievienoties, nevis jāatbrÄ«vojas no tiem. Pastāstiet viņiem, ka rakstāt nemainÄ«gus bināros konteinerus, kas, izturot visus testus, paliek nemainÄ«gi uz visiem laikiem. Pastāstiet viņiem, ka jums ir konveijera kods, un paskaidrojiet, ko tas nozÄ«mē. Parādiet viņiem Ŕādu shēmu: nemainÄ«gs tikai lasāms binārs konteinerā, kas iztur visus ievainojamÄ«bas testus; un tad ne tikai neviens to nepieskaras, viņi pat nepieskaras sistēmai, kas veido cauruļvadu, jo tā tiek izveidota arÄ« dinamiski. Man ir klienti Capital One, kas izmanto Vault, lai izveidotu kaut ko lÄ«dzÄ«gu blokķēdei. Auditoram nav jārāda Å”efpavāra ā€œreceptesā€, pietiek parādÄ«t blokķēdi, no kuras ir skaidrs, kas noticis ar Jira biļeti ražoÅ”anā un kas par to ir atbildÄ«gs.

Septiņi transformācijas arhetipi, kuru pamatā ir DevOps principi

Saskaņā ar Ziņot, ko 2018. gadā izveidoja Sonatype, 2017. gadā bija 87 miljardi OSS lejupielādes pieprasījumu.

Septiņi transformācijas arhetipi, kuru pamatā ir DevOps principi

Zaudējumi, kas raduÅ”ies ievainojamÄ«bu dēļ, ir pārmērÄ«gi lieli. Turklāt skaitļos, ko redzat iepriekÅ”, nav iekļautas alternatÄ«vās izmaksas. Kas ir DevSecOps Ä«sumā? Uzreiz saku, ka man nav interesanti runāt par to, cik veiksmÄ«gs ir Å”is nosaukums. Lieta ir tāda, ka, tā kā DevOps ir bijis tik veiksmÄ«gs, mums jācenÅ”as Å”im cauruļvadam pievienot droŔību.

Šīs secības piemērs:
Septiņi transformācijas arhetipi, kuru pamatā ir DevOps principi

Tas nav ieteikums konkrētiem produktiem, lai gan man tie visi patīk. Es tos minēju kā piemēru, lai parādītu, ka DevOps, kas sākotnēji bija balstīta uz organizācijas paradigmu nozarē, ļauj automatizēt katru produkta darba posmu.

Septiņi transformācijas arhetipi, kuru pamatā ir DevOps principi

Un nav iemesla, kāpēc mēs nevarētu izmantot tādu paÅ”u pieeju droŔībai.

Kopsavilkums

Noslēgumā es sniegÅ”u dažus padomus par DevSecOps. Sistēmu izveides procesā jāiekļauj auditori un jāvelta laiks viņu izglÄ«toÅ”anai. Ir jāsadarbojas ar auditoriem. Tālāk jums ir jāuzņemas absolÅ«ti nesaudzÄ«ga cīņa pret viltus pozitÄ«viem rezultātiem. Pat izmantojot visdārgāko ievainojamÄ«bas skenÄ“Å”anas rÄ«ku, jÅ«s varat izveidot ārkārtÄ«gi sliktus ieradumus izstrādātāju vidÅ«, ja nezināt, kāda ir signāla un trokŔņa attiecÄ«ba. Izstrādātāji bÅ«s pārņemti ar notikumiem un vienkārÅ”i izdzēsÄ«s tos. Ja jÅ«s dzirdējāt par Equifax stāstu, tas ir gandrÄ«z tas, kas notika tur, kur tika ignorēts augstākais trauksmes lÄ«menis. Turklāt ievainojamÄ«bas ir jāizskaidro tā, lai bÅ«tu skaidrs, kā tās ietekmē uzņēmējdarbÄ«bu. Piemēram, jÅ«s varētu teikt, ka Ŕī ir tāda pati ievainojamÄ«ba kā Equifax stāstā. DroŔības ievainojamÄ«bas jāizturas tāpat kā citas programmatÅ«ras problēmas, tas ir, tās ir jāiekļauj kopējā DevOps procesā. Jums ir jāstrādā ar viņiem, izmantojot Jira, Kanban utt. Izstrādātājiem nevajadzētu domāt, ka to darÄ«s kāds cits - gluži pretēji, tas jādara ikvienam. Visbeidzot, jums ir jātērē enerÄ£ija cilvēku apmācÄ«bai.

Noderīgas saites

Šeit ir dažas DevOops konferences sarunas, kas jums varētu būt noderīgas:

IeskatÄ«ties programmu DevOops 2020 Maskava ā€” tur ir arÄ« daudz interesantu lietu.

Avots: www.habr.com

Pievieno komentāru