Jautājums «kā ieviest devops» jau gadiem ilgi ir aktuāls, taču labu materiālu ir maz. Dažkārt jūs kļūstat par reklāmas mērķi ne īpaši gudriem konsultantiem, kuriem jāizpārdod savs laiks, neatkarīgi no tā, kā. Dažkārt tas ir neskaidrs, ļoti vispārīgs runas veids par to, kā megakorporāciju kuģi piedalās visuma plašumos. Rodas jautājums: ko mēs no tā iegūstam? Godātais autors, vai varat skaidrāk uzskaitīt savas idejas?
Tas viss notiek tādēļ, ka reālas prakses un izpratnes par uzņēmuma kultūras transformāciju rezultātiem nav uzkrājies daudz. Kultūras izmaiņas ir ilgstošas lietas, kuru rezultāti neparādīsies ne pēc nedēļas, ne mēneša. Mums nepieciešams kāds pietiekami pieredzējis, redzējis, kā uzņēmumi tika veidoti un sabrukti gadu gaitā.
Džons Viliss — viens no DevOps tēviem. Džonam ir desmitiem gadu pieredzes darbā ar lielu skaitu uzņēmumu. Laika gaitā Džons ir pamanījis specifiskus modeļus, kas sastopami katra uzņēmuma darbībā. Izmantojot šos arhetipus, Džons vada uzņēmumus uz patieso DevOps transformācijas ceļu. Vairāk par šiem arhetipiem — Džona lekcijas tulkojumā no konferences DevOops 2018.
Par lektoru:
Vairāk nekā 35 gadi IT vadībā, piedalījies OpenCloud priekšteča izveidē Canonical, piedalījies 10 startapos, divus no kuriem pārdevis Dell un Docker. Pašlaik ir DevOps un Digital Practices viceprezidents SJ Technologies.
Tālāk seko stāstījums no Džona.
Mani sauc Džons Viliss, un mani visvieglāk var atrast Twitterī, . Tas pats segvārds ir arī manā Gmail un GitHub. Un jūs varat atrast videoierakstus par manām lekcijām un prezentācijām.
Man ir daudz tikšanās ar CIO dažādu lielu uzņēmumu. Viņi ļoti bieži sūdzas, ka nesaprot, kas ir DevOps, bet visi, kas mēģina to izskaidrot, runā par kaut ko savu. Vēl viena bieža sūdzība — DevOps nestrādā, lai gan direktori šķiet, ka visu dara, kā viņiem skaidrots. Runājam par lieliem uzņēmumiem, kuriem ir vairāk nekā simts gadi. Sarunājoties ar viņiem, es secināju, ka daudzām problēmām labāk noder nevis augstās tehnoloģijas, bet salīdzinoši zemas tehnoloģijas risinājumi. Nedēļām ilgi es vienkārši sarunājos ar cilvēkiem no dažādiem departementiem. Tas, ko jūs redzat pirmajā attēlā šajā ierakstā — ir mans pēdējais projekts, istaba tā izskatījās pēc trim darba dienām.
Kas ir DevOps?
Patiesībā, ja pajautājat 10 dažādiem cilvēkiem, viņi dos 10 dažādas atbildes. Bet interesanti ir tas, ka visas šīs desmit atbildes būs pareizas. Nepareiza atbilde te nav. Es jau diezgan dziļi esmu nodarbojies ar DevOps apmēram 10 gadus, biju pirmais amerikānis pirmajā DevOpsDay. Ne teikšu, ka esmu gudrāks par visiem, kas nodarbojas ar DevOps, bet gan maz ticams, ka kāds cits ir ieguldījis tikpat daudz pūļu. Es uzskatu, ka DevOps rodas tad, kad cilvēku kapitāls savienojas ar tehnoloģijām. Bieži aizmirstam par cilvēka dimensiju, lai gan runājam daudz par kultūrām.
Tagad mums ir daudz datu, piecus gadus ilgstoši akadēmisku pētījumu, teoriju pārbaude ir izveidota industriālā mērogā. Šie pētījumi mums saka sekojošo: ja organizācijas kultūrā savieno dažus uzvedības modelus, var iegūt 2000 reizes ātrāku izaugsmi. Šim paātrinājumam atbilst tāds pats uzlabojums noturībā. Tas ir kvantitatīvs mērījums tam, kādu priekšrocību DevOps var sniegt jebkuram uzņēmumam. Pirms diviem gadiem es stāstīju par DevOps Fortune 5000 uzņēmuma ģenerāldirektoram. Kad es gatavoju prezentāciju, es ļoti uztraucos, jo man bija jāizklāsta sava daudzu gadu pieredze 5 minūtēs.
Kopumā es sniedzu sekojošo definīciju DevOps: tas ir prakse un modeļu kopums, kas ļauj pārvērst cilvēku kapitālu augstas ražīguma organizācijas kapacitātē. Piemērs — kā pēdējos 50 vai 60 gados strādā Toyota.
(Šajā un turpmākajās shēmās tiek sniegtas nevis kā atsauces materiāls, bet kā ilustrācija. To saturs atšķirsies katrai jaunai uzņēmumam. Tomēr attēlu var atsevišķi aplūkot un palielināt
Viena no veiksmīgākajām šādām praksēm ir value stream mapping. Par to ir uzrakstītas vairākas labas grāmatas, no kurām veiksmīgākais autors ir Karen Martin. Bet 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, kuras esmu daudz izmantojis. Bet, kad izpilddirektors jautā, kāpēc viņa uzņēmums nevar pāriet uz jaunām sliedēm, par value stream mapping runāt vēl ir pāragri. Ir daudz būtiskāku jautājumu, uz kuriem iepriekš nepieciešams atrast atbildes.
Man šķiet, ka daudzu manu kolēģu kļūda ir tā, ka viņi vienkārši dod uzņēmumam piecu punktu vadlīnijas, un pēc tam pēc sešiem mēnešiem atgriežas un skatās, kas noticis. Pat labai shēmai kā value stream mapping ir, tā teikt, mirušās zonas (blind spots). Pēc simtiem interviju ar dažādu uzņēmumu direktoriem esmu izstrādājis noteiktu modeli, kas ļauj sadalīt problēmu sastāvdaļās, un tagad mēs pa kārtai apspriedīsim katru no šīm sastāvdaļām. Pirms jebkādu tehnoloģisku risinājumu izmantošanas, es izmantoju šo modeli, un rezultātā man visās sienās iznāk tādas shēmas. Nesen strādāju ar vienu ieguldījumu fondu, un man rezultātā bija 100-150 šādu shēmu.
Slikta kultūra katru labu pieeju apēd brokastīs
Galvenā doma ir tāda: nekādas Lean, Agile, SAFE un DevOps nepalīdzēs, ja pati organizācijas kultūra ir slikta. Tas ir tāpat kā lekt dziļumā bez skafandra vai operēt bez rentgena attēla. Citiem vārdiem sakot, pārfrāzējot Drukeru un Demingu: slikta organizācijas kultūra noraks jebkuru labu sistēmu un neapēdīs.
Lai atrisinātu šo galveno problēmu, ir jāveic šādi soļi:
- Make All Work Visible: jāpadara viss darbs redzams. Ne tajā nozīmē, ka tam obligāti jāparādās uz kāda ekrāna, bet tajā nozīmē, ka tam jābūt novērojamam.
- Consolidate Work Management Systems: ir nepieciešams konsolidēt vadības sistēmas. Attiecībā uz „cilšu” zināšanām un institucionālajām zināšanām 9 no 10 gadījumiem šaurs posms ir cilvēki. Grāmatā problēma bija vienā vienīgā cilvēkā, Brentā, dēļ kura projekts kavējās trīs gadus. Un uz tādiem „Brentiem” es sastopos visur. Lai atrisinātu šos šauros posmus, es izmantoju šos divus punktus mūsu sarakstā.
- Theory of Constraints Methodology: ierobežojumu teorija.
- Collaboration hacks: sadarbības haiki.
- Toyota Kata (): par Toyota Kata es daudz nerunāšu. Ja interesē, manā GitHubā gandrīz par katru no šīm tēmām.
- Market Oriented Organization: tirgum orientēta organizācija.
- Shift-left auditors: audits agrīnās cikla stadijās.
Es sāku darbu ar organizāciju ļoti vienkārši: ieeju uzņēmumā un runāju ar darbiniekiem. Kā redzam, nav nepieciešamas augstas tehnoloģijas. Viss, kas nepieciešams, ir kaut kas, uz kā rakstīt. Es savācu vairākas komandas vienā telpā un analīzēju to, ko viņi man saka, no maniem 7 arhetipiem. Pēc tam es viņiem dodu marķieri un lūdzu uz dēļa uzrakstīt visu to, ko viņi līdz šim teica balsī. Parasti šāda veida sanāksmēs ir viens cilvēks, kurš visu pieraksta, un labākajā gadījumā viņam izdodas pierakstīt 10% diskusijas. Ar manu metodi šo rādītāju izdodas paaugstināt līdz kaut kur 40%.
(Atsevišķi šo ilustrāciju var )
Mans piegājiens balstās uz Viljama Šneidera (William Schneider, ). Pieejas pamatā ir doma, ka jebkuru organizāciju var sadalīt četros kvadrantos. Šī shēma man parasti ir rezultāts darbā ar tām simtiem citu shēmu, kas rodas, analizējot organizāciju. Pieņemsim, ka mums ir organizācija ar augstu kontroli, bet zemu kompetenci. Tas ir ārkārtīgi nevēlams variants: kad visi staigā pa stīgām, bet neviens nezina, ko vajag darīt.
Kā labāka alternatīva ar augstu kontroli un kompetenci. Ja uzņēmums gūst peļņu, iespējams, ka DevOps viņam nav vajadzīgs. Visinteresantāk ir strādāt ar uzņēmumu, kuram ir augsta kontroles pakāpe, zema kompetence un sadarbība, taču tajā pašā laikā augsta kultūras līmeņa (cultivation) prasības. Tas nozīmē, ka uzņēmumā ir daudz cilvēku, kuriem patīk tur strādāt, un darbinieku rotācija ir zema.
(Atsevišķi šo ilustrāciju var )
Man šķiet, ka metodes ar stingri noteiktām rekomendācijām galu galā traucē sasniegt patiesību. Jo īpaši value stream mapping ir daudz noteikumu par to, kā jāstrukturē informācija. Agrīnos darba posmos, par kuriem es runāju, šie noteikumi nevienam nav nepieciešami. Ja cilvēks ar marķieri rokās apraksta uz galda esošo situāciju uzņēmumā — tas ir labākais veids, kā izprast situāciju. Šāda informācija nenonāk līdz direktoriem. Šajā brīdī būtu muļķīgi pārtraukt cilvēku un teikt, ka viņš nepareizi uzvilcis kādu bultu. Šajā posmā labāk izmantot vienkāršas pamatnoteikumu, piemēram: daudzniveles abstrakciju var izveidot, vienkārši izmantojot krāsainus marķierus.
Atkārtoju, nekādu augsto tehnoloģiju. Ar melno marķieri attēlo objektīvo realitāti, kā viss darbojas. Ar sarkano marķieri cilvēki atzīmē, kas tieši viņiem esošajā situācijā nepatīk. Ir svarīgi, ka šo informāciju raksta viņi, nevis es. Kad pēc sapulces es dodos pie IT direktora, es neiesniedzu sarakstu ar 10 lietām, kas jāpabeidz. Es cenšos atrast saiknes starp to, ko saka cilvēki no uzņēmuma, un esošajām pārbaudītajām shēmām. Beigās ar zilo marķieri tiek piedāvātas iespējamās risinājumu problēmas.
(Atsevišķi šo ilustrāciju var )
Šāda pieeja šobrīd ir attēlota augstāk. Šī gada sākumā es strādāju ar vienu banku. Drošības nodaļas darbinieki bija pārliecināti, ka viņiem nedrīkst ierasties uz prasību un projektēšanas (design and requirement reviews) pārbaudēm.
(Atsevišķi šo ilustrāciju var )
Pēc tam mēs runājām ar cilvēkiem no citām nodaļām un noskaidrojām, ka kaut kur pirms 8 gadiem programmatūras izstrādātāji atlaida drošības darbiniekus, jo tie palēnināja darbu. Un tad tas pārvērtās par liegumu, kas tika uztverams kā pašsaprotams. Lai gan patiesībā nekādu liegumu nebija.
Mūsu tikšanās noritēja ļoti sarežģītā veidā: trīs stundu laikā piecas dažādas komandas nespēja man izskaidrot, kas notiek starp kodu un būvniecību. Un tas šķiet visvienkāršākā lieta. Lielākā daļa DevOps konsultantu uzreiz pieņem, ka tas jau visiem ir zināms.
Pēc tam cilvēks, kurš atbildēja par IT regulējumu (IT governance), kas četrus stundas klusēja, pēkšņi atsāka runāt, kad nonācām pie viņa tēmas, un aizņēma mūs vēl uz samērā ilgu laiku. Beigās es viņam jautāju, ko viņš domā par tikšanos, un es nekad neaizmirstīšu viņa atbildi. Viņš teica: «Agrāk es domāju, ka mūsu bankā ir tikai divi programmatūras piegādes veidi, bet tagad es zinu, ka tos ir pieci, un par trim es pat nenojautu.»
(Atsevišķi šo ilustrāciju var )
Pēdējā tikšanās šajā bankā bija ar komandu, kas nodarbojas ar investīciju programmatūru. Tieši ar šo komandu izrādījās, ka rakstīt shēmas ar marķieri uz papīra ir labāk nekā uz tāfeles un pat labāk nekā uz viedtāfeles.
Fotogrāfijas, kuras jūs redzat, ir tas, kā izskatījās viesnīcas konferenču zāle mūsu tikšanās ceturtajā dienā. Un šīs shēmas mēs izmantojām, lai meklētu paraugus, t.i., arhetipus.
Tātad, es uzdodu jautājumus darbiniekiem, viņi ieraksta atbildes ar trīs krāsu marķieriem (melnu, sarkanu un zilu). Viņu atbildes es analizēju pēc arhetipiem. Tagad apskatīsim visus arhetipus secībā.
1. Make All Work Visible: Padarīt visu darbu redzamu
Lielākajā daļā uzņēmumu, ar kuriem es strādāju, ir ļoti augsts nezināmas darba procents. Piemēram, kad viens darbinieks vēršas pie otra un vienkārši lūdz kaut ko izdarīt. Lielās organizācijās var būt līdz 60% neplānotā darba. Un pat līdz 40% darba nav dokumentēts. Ja tas būtu Boeing, es nekad vairs nelidotu ar viņu lidmašīnu. Ja tiek dokumentēta tikai puse darba, nav skaidrs, vai šis darbs tiek veikts pareizi vai nē. Visi pārējie paņēmieni izrādās bezjēdzīgi — nav jēgas mēģināt kaut ko automatizēt, jo zināmie 50% var būt tieši viskārtīgākā un precīzākā darba daļa, kuras automatizācija nenesīs lielus rezultātus, bet viss šausmīgais ir neredzamajā pusē. Bez dokumentācijas ir neiespējami atrast visdažādākās nepilnības un slēpto darbu, neatrast šaurās vietas, tos pašus “Brentus”, par kuriem es jau runāju. Ir brīnišķīga grāmata no Dominikas De Grandis (Dominica DeGrandis) . Tā identificē piecas dažādas «laika noplūdes» (thieves of time):
- Pārāk daudz darba procesā (WIP)
- Nezināmās atkarības
- Neplānotais darbs
- Pretrunīgas prioritātes
- Nokavēts darbs
Tas ir ļoti vērtīgs analīze, un grāmata ir lieliska, taču visi šie padomi ir bezjēdzīgi, ja redzami tikai 50% datu. Izmantot Dominikas piedāvātos paņēmienus var tikai tad, ja precizitāte ir augstāka par 90%. Es runāju par situācijām, kad vadītājs dod padotajam 15 minūšu uzdevumu, bet tas aizņem trīs dienas; bet vadītājs patiesībā nezina, ka šis padotais ir atkarīgs vēl no četriem vai pieciem citiem cilvēkiem.
Phoenix Project — tā ir lieliska stāsts par projektu, kas kavējās trīs gadus. Viens no varoņiem riskē ar atlaišanu dēļ tā, un viņš sastop citu varoni, kurš tiek attēlots kā sava veida Sokrāts. Tas palīdz saprast, kas tieši ir noticis. Izrādās, ka uzņēmumā ir viens sistem administrators, kuru sauc Brent, un visu darbu tā vai citādi koordinē viņš. Viens no sanāksmes dalībniekiem jautā: kāpēc katra pusstunda uzdevuma aizņem nedēļu? Atbilde ir ļoti vienkāršota rindas teorijas un Littla likuma izklāsts, un šajā izklāstā izrādās, ka pie 90% noslodzes katra darba stunda aizņem 9 stundas. Katrs uzdevums ir jānosūta septiņiem citiem cilvēkiem, tādēļ šī stunda pārvēršas 63 stundās, 7 reiz 9. Es to saku, lai uzsvērtu, ka, lai izmantotu Littla likumu vai kādu sarežģītu rindas teoriju, ir nepieciešami vismaz dati.
Tādēļ, kad es runāju par redzamību, es domāju nevis tikai par to, lai viss būtu uz ekrāna, bet gan par to, lai vismaz būtu dati. Kad tie ir pieejami, bieži izrādās, ka pastāv ļoti liels neplānots darbs, kas kaut kādā veidā tiek novirzīts Brentam, lai gan tam nav nekādas nepieciešamības. Un Brent ir lielisks puisis, viņš nekad nesaka «nē», bet vienlaikus viņš nevienam nestāsta, kā viņš veic savu darbu.
Kad darbs ir redzams, var uzmanīgi klasificēt datus (tieši to Dominika dara attēlā), var pielietot piecu laika noplūdes abstrakciju un automatizēt.
2. Konsolidēt darba pārvaldības sistēmas: Uzdevumu pārvaldība
Arhetipi, par kuriem es runāju, veido sava veida piramīdu. Ja pirmais ir izpildīts pareizi, otrais jau ir sava veida uzbūve. Daudzi no tiem nedarbojas start-up uzņēmumiem, tie jāņem vērā lieliem uzņēmumiem, kuri tiek iekļauti Fortune 5000 sarakstā. Pēdējā uzņēmumā, kurā es strādāju, bija 10 kļūdu izsekošanas sistēmas (ticketing system). Vienā komandā bija Remedy, otra izstrādāja kādu savu sistēmu, trešā izmantoja Jira, kāds vispār iztika ar e-pastu. Tā pati problēma rodas, ja uzņēmumā ir 30 dažādi pipeline, bet man nav laika apspriest visus šādus gadījumus.
Es apspriežu ar cilvēkiem, kā tieši tiek izveidoti biļetes, kas ar tām tālāk notiek, kā tās apiet. Visinteresantākais ir tas, ka cilvēki mūsu sapulcēs runā diezgan atklāti. Es jautāju, cik daudz cilvēku piešķir «minor / no impact» biļetēm, kurām patiesībā vajadzēja piešķirt «major impact». Izrādījās, ka to dara gandrīz visi. Es nenodarbojos ar ziņošanu un visādi cenšos neskaidrot cilvēkus. Kad man kaut kas atklāti pastāsta, es neizpaužu personu. Bet, kad praktiski visi apiet sistēmu, tas nozīmē, ka visa drošība, būtībā, ir tikai dekorācija. Tāpēc no šīs sistēmas datiem nevar izdarīt nekādus secinājumus.
Lai atrisinātu biļešu problēmu, ir jāizvēlas viena galvenā sistēma. Ja jūs izmantojat Jira, tad lai ir tikai Jira. Ja ir kāda alternatīva, lai ir tikai tā. Jautājums ir par to, ka biļetes jāuzskata kā vēl viens attīstības procesa posms. Ikvienai rīcībai jābūt biļetei, kas jāiziet cauri izstrādes darba procesam. Biļetes tiek nosūtītas komandai, kas tās izņem uz paneļa, un tad uzņemas atbildību par tām.
Tas attiecas uz visiem departamentiem, tostarp infrastruktūras un operatīvajiem. Šādā gadījumā var izveidot vismaz kaut cik ticamu priekšstatu par situāciju. Kad šis process ir sakārtots, pēkšņi izrādās, ka var viegli noteikt, kas atbild par katru lietojumprogrammu. Jo tagad mēs saņemam ne 50%, bet 98% jauno pakalpojumu. Ja šis galvenais process darbojas, tad precizitāte palielinās visā sistēmā.
Pakalpojumu plūsma
Tas attiecas tikai uz lielām korporācijām. Ja jūs esat jauna kompānija jaunā jomā — izmantojiet Travis CI vai CircleCI. Runājot par Fortune 5000 uzņēmumiem, ir norādīts gadījums ar banku, kurā es strādāju. Pie viņiem ieradās Google un parādīja diagrammas ar vecajām IBM sistēmām. Google pārstāvji ar nesapratni jautāja — kur ir šim avota kods? Bet tāda avota koda nav, nav pat GUI. Tā ir realitāte, ar kuru jāstrādā lielām organizācijām: 40 gadus veci bankas ieraksti uz novecojuša mākonīša. Viens no maniem klientiem izmanto Kubernetes konteinerus ar Circuit Breaker paraugiem, plus Chaos Monkey, viss tas ir KeyBank lietojumprogrammā. Bet beigās šie konteineri pieslēdzas COBOL lietojumprogrammā.
Google pārstāvji bija pilnīgi pārliecināti, ka viņi atrisinās visas mana klienta problēmas, un tad sāka jautāt: kas ir IBM datapipe? Viņi atbild: tas ir savienotājs. Pie kā tas pieslēdzas? Pie Sperry sistēmas. Bet kas tas ir? Un tā tālāk. Pirmajā acu uzmetienā šķiet: kāds šeit var būt DevOps? Bet patiesībā tas ir iespējams. Ir piegādes sistēmas, kas ļauj nodot darba plūsmu komandām, kas nodarbojas ar piegādi.
3. Ierobežojumu teorija: Ierobežojumu teorija
Pāriesim pie trešā arhetipa: institucionālā / "cilšu" zināšana. Parasti jebkurā organizācijā ir pāris cilvēku, kuri zina visu un visu vada. Tie ir tie, kas visilgāk strādā organizācijā un kuri ir iepazinušies ar visiem apbraucamajiem ceļiem.
Kad tas tiek izcelts diagrammā, es īpaši iezīmēju šādus cilvēkus ar marķieri: piemēram, noskaidrojas, ka kāds Lu ir klāt visās sanāksmēs. Un man ir skaidrs: tas ir vietējais Brents. Kad IT direktors izvēlas starp mani t-kreklā un sporta apavos un uzvalkā tērptu puisi no IBM, viņi izvēlas mani, jo es varu pastāstīt direktoram par lietām, kuras otrs puisis neizstāstīs, un par kurām direktoram varētu būt neērti dzirdēt. Es saku viņiem, ka viņu uzņēmumā ir šaurs vietas, tas ir kāds Frenks un kāds Lu. Šis šaurums ir jāatrisina, to zināšanas ir jānolauž tā vai citādi.
Lai atrisinātu šāda veida problēmas, es varu, piemēram, ieteikt izmantot Slack. Gudrs direktors uzdos jautājumu – kāpēc? Parasti šādos gadījumos DevOps konsultanti atbild: jo visi tā dara. Ja direktors patiešām ir vieds, viņš teiks: nu, un ko? Un tad dialogs beigsies. Bet es atbildu: tāpēc, ka uzņēmumā ir četri šauri vietas – Freids, Lū, Sūzija un Džeins. Lai padarītu viņu zināšanas institucionalizētas, vispirms ir jāievieš Slack. Visi jūsu wiki ir pilnīga muļķība, jo neviens nezina par to eksistenci. Ja inženieru komanda strādā gan pie ārējā, gan iekšējā izstrādes, visiem jāzina, ka var vērsties pie ārējās izstrādes komandas vai infrastruktūras komandas ar jautājumiem. Tieši tad, iespējams, Lū vai Freids atradīs laiku, lai pieslēgtos wiki. Un tad Slack kāds var pajautāt, kāpēc, teiksim, neizdodas 5. solis. Un tad Lū vai Freids labos instrukcijas wiki. Ja šis process tiks sakārtots, tālāk daudz kas ieviesīsies pats.
Manas domas būtība ir šāda: lai ieteiktu kādas augsto tehnoloģiju risinājumus, vispirms ir jānosaka pamati, un to var izdarīt ar iepriekš aprakstītajiem zemas tehnoloģijas risinājumiem. Ja uzsākt ar augstajām tehnoloģijām un neizskaidrot, kāpēc tās ir nepieciešamas, parasti tas noved pie sliktām sekām. Viens no mūsu klientiem izmanto Azure ML, ļoti lēts un vienkāršs risinājums. Aptuveni 30% jautājumu viņiem jau atbildēja paši mašīnmācīšanās algoritmi. Bet šie rīki tika izstrādāti operātoriem, kuri nebija nodarbojušies ar datu zinātni, statistiku vai matemātiku. Tas ir norādāms. Šādu risinājumu izmaksas ir minimālas.
4. Sadarbības hakeri: Sadarbības triki
Ceturtā arhetips ir saistīts ar cīņu pret izolāciju. Lielākā daļa cilvēku to jau zina: izolācija rada naidu. Ja katrs nodaļas darbinieks ir savā stāvā un cilvēki savā starpā vispār nesatiekās, izņemot liftā, tad naids starp viņiem viegli rodas. Bet, ja pretēji, cilvēki atrodas vienā telpā, naids tūlīt izzūd. Kad kāds izsaka kopīgu apsūdzību, piemēram, šāds interfeiss nekad nedarbojas — nav nekā vienkāršāka, kā šādu apsūdzību dekonstrukcēt. Programmētājiem, kas rakstījuši interfeisu, pietiek ar to, lai uzdotu konkrētus jautājumus, un drīz izrādīsies, ka, piemēram, lietotājs vienkārši nepareizi izmanto instrumentu.
Ir daudz veidu, kā pārvarēt izolāciju. Mani kādā brīdī lūdza konsultēt banku Austrālijā, es to atteicu, jo man ir divi bērni un sieva. Viss, ko es varēju viņiem palīdzēt — es ieteicu viņiem grafisko stāstīšanu. Tas ir veids, kas pierādīti darbojas. Vēl viens interesants veids ir lean coffee formāta sanāksmes. Lielā organizācijā tas ir lielisks veids, kā izplatīt zināšanas. Turklāt var rīkot iekšējās devops dienas, hakatonus un tamlīdzīgi.
5. Coaching Kata
Kā es jau brīdināju pašā sākumā, šodien es par to nestāstīšu. Ja interesē, varat apskatīt .
Ir arī labs ziņojums par šo tēmu no Mike Rother:
6. Market Oriented: tirgum orientēta organizācija
Šeit ir dažādas problēmas. Piemēram, cilvēki "I", cilvēki "T" un cilvēki "E". Cilvēki "I" — tie ir tie, kuri nodarbojas tikai ar kaut ko vienu. Parasti viņi pastāv tieši organizācijās ar izolētām struktūrām. "T" — tas ir, ja cilvēks labi pārzina kaut ko vienu, bet paveic arī dažas citas lietas. "E" vai pat "ķemme" — tas ir, kad cilvēkam ir daudz prasmju.
Šeit darbojas Konveja likums (), kuru maksimāli vienkāršoti var formulēt šādi: ja trīs komandas strādā pie kompilatora, tad galu galā izveidosies kompilators no trim daļām. Tādēļ, ja iekšējā organizācijā ir augsts izolācijas līmenis, pat Kubernetes, Circuit breaker, API extensibility un citas modernās lietas šajā organizācijā tiks struktūrētas tāpat kā pati organizācija. Strikti pēc Konveja un negodīgi pret jums, jaunie giki.
Šīs problēmas risinājums ir aprakstīts daudzos veidos. Ir piemēram, organizatoriskie arhetipi, ko aprakstījis Fernando Fernandezs. Tāda problēma arhitektūra, par kuru es tikko runāju, ar izolāciju — tā ir funkcionāli orientēta arhitektūra. Otrais veids — sliktākais, matricas arhitektūra, tur ir divu citu haoss. Trešais — tas, ko novēro lielākajā daļā start-up uzņēmumu, un lielas kompānijas arī mēģina pielāgoties šim tipam. Tā ir tirgum orientēta organizācija. Šeit notiek optimizācija, lai sasniegtu visātrāko atsauksmi uz klientu pieprasījumiem. Dažreiz to sauc par platu organizāciju.
Šo struktūru daudzi apraksta dažādi, man patīk formulējums build/run teams, Amazon to sauc par two pizza teams. Šajā struktūrā visi cilvēki tipa „I” koncentrējas ap vienu pakalpojumu, un pakāpeniski viņi kļūst tuvāki tipam „T”, bet, ja tiek nodrošināta pareiza vadība, var kļūt pat par „E”. Pirmais kontrarguments šeit — šādā struktūrā ir lieki elementi. Kāpēc katrā nodaļā vajag testētāju, ja var būt speciāla testētāju nodaļa? Uz to es atbildu: liekie izdevumi šajā gadījumā ir cena, lai nākotnē visa organizācija kļūtu par „E” tipa. Šādā struktūrā testētājs pakāpeniski uzzina par tīkliem, arhitektūru, projektēšanu utt. Rezultātā katrs organizācijas dalībnieks kļūst pilnībā informēts par visu, kas notiek organizācijā. Ja vēlaties uzzināt, kā šis shēma strādā rūpniecībā, izlasiet .
7. Shift-left auditors: audits agrīnās cikla stadijās. Drošības noteikumu ievērošana ir redzama
Tas ir tad, kad jūsu rīcība, tā teikt, nepārsniedz smaržas pārbaudi. Cilvēki, kas strādā uz jums, nav stulbi. Ja viņi, kā iepriekšējā piemērā, visur norādīja minor/no impact, tas ilga trīs gadus, un neviens neko nepamanīja, tad visi lieliski zina, ka sistēma nedarbojas. Vēl viens piemērs ir izmaiņu padome (change advisory board), kur katru, teiksim, trešdienu ir jāiesniedz ziņojumi. Tur strādā grupiņa cilvēku (starp citu, ne pārāk labi apmaksātu), kuri 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 ārkārtīgi sarežģītas. Un pieci- seši cilvēki ir jāpieņem lēmumu par izmaiņām, par kurām viņi nav iesnieguši un par kurām viņi neko nezina.
Protams, šāds pieejas veids nedarbojas. Man nākas atbrīvoties no šādām lietām, jo šie cilvēki nenodrošina sistēmas aizsardzību. Lēmumam jāņem pašai komandai, jo komandai jābūt atbildīgai par to. Pretējā gadījumā rodas paradoksāla situācija, kad menedžeris, kurš mūžā nav rakstījis kodu, paziņo programmētājam, cik ilgs laiks jāvelta koda rakstīšanai. Vienā uzņēmumā, kurā es strādāju, bija 7 dažādas padomes, kas apsvēra katru izmaiņu, tostarp arhitektūras padome, produktu padome utt. Pat bija obligāts gaidīšanas periods, lai gan viens darbinieks man teica, ka desmit gadu laikā ne reizi vien šajā obligātajā periodā nav noraidītas šī cilvēka veiktās izmaiņas.
Auditorus vajag aicināt pie sevis, nevis no viņiem atbrīvoties. Pastāstiet viņiem, ka jūs rakstāt nemaināmus bināros konteinerus, kas, ja iziet visus testus, paliek nemainīgi mūžīgi. Pastāstiet viņiem, ka jums ir pipeline kā kods un paskaidrojiet, ko tas nozīmē. Parādiet viņiem nākamo shēmu: nemainīgas binārās datnes ir tikai lasīšanai kontejnerā, kas izgāja visus drošības testus; un ne tikai neviens pie tā nepieskaras — pat sistēma, kas izveido pipeline, paliek neaizskarama, jo tā tika veidota dinamiski. Man ir klienti, Capital One, kuri izmanto Vault, lai izveidotu kaut ko līdzīgu blokķēdei. Auditoram nav jāparāda "receptes" no Chef, pietiek parādīt blokķēdi, no kuras ir skaidrs, kas noticis ar Jira biļeti ražošanā un kurš ir atbildīgs par to.
Saskaņā ar , ko 2018. gadā izveidoja Sonatype, 2017. gadā bija 87 miljardi OSS lejupielādes pieprasījumu.
Zaudējumi no drošības ievainojamībām ir nepamatoti lieli. Un tie skaitļi, kurus jūs tagad redzat augstāk, neiekļauj alternatīvās izmaksas. Divos vārdos par to, kas ir DevSecOps. Gribu uzreiz teikt, ka mani neinteresē sarunas par to, cik labi šis nosaukums ir. Jēga ir tāda, ka, ja DevOps ir bijis diezgan veiksmīgs, ir jāmēģina pievienot šo pipeline drošību.
Piemērs šādai secībai:
Tas nav konkrētu produktu ieteikums, lai gan man tie visi patīk. Es tos minēju kā piemēru, lai parādītu, ka DevOps, kas sākotnēji balstījās uz rūpniecības organizācijas paradigmu, ļauj automatizēt katru produkta izstrādes posmu.
Un nav nekādu iemeslu, kādēļ mēs nevarētu piemērot to pašu pieeju drošībai.
Rezultāts
Nobeigumā sniegšu dažus padomus DevSecOps. Jāiekļauj auditoru loma sistēmu izstrādē un jāpavada laiks viņu izglītošanai. Jāstrādā kopā ar auditoriem. Turpinājumā ir jāveic absolūti neapgūstoša cīņa pret viltus trauksmi. Pat ar visdārgāko skenēšanas rīku var izveidot ārkārtīgi kaitīgas ieradumus jūsu izstrādātājos, ja nezināt, kāds ir signālu un troksni attiecība. Izstrādātāji tiks pārslodzīti ar notikumiem, un viņi sāks tos vienkārši dzēst. Ja esat dzirdējuši par Equifax gadījumu, tad tur aptuveni tas arī notika, tur tika ignorēts augstākā līmeņa brīdinājums. Turklāt, ievainojamības ir jāizskaidro tā, lai būtu skaidrs, kā tās ietekmē biznesu. Piemēram, var teikt, ka tā ir tāda pati ievainojamība kā Equifax stāstā. Drošības ievainojamības ir jāskata tāpat kā citas programmatūras problēmas, tas ir, tās ir jāsadarbojas kopējā DevOps procesā. Ar tām jāstrādā caur Jira, Kanban utt. Izstrādātājiem nevajadzētu domāt, ka to izdarīs kāds cits — tieši otrādi, visiem ar to jārīkojas. Visbeidzot, ir jāiegulda spēki cilvēku izglītošanā.
Noderīgas saites
Šeit ir daži ziņojumi no DevOops konferences, kas varētu jums šķist noderīgi:
- Sergejs Berdņikovs, Artioms Kaličkins — Veiksmes stāsts jeb "Dev+DevOps+Ops" (, )
- Baruhs Sadogurskis, Leonīds Igolņiks — DevOps mērogā: grieķu traģēdija trīs cēlienos (, )
- Aleksandrs Titovs, Kirils Tolkačovs —
- Timoty Lister —
Ielūkojieties DevOops 2020 Maskavā — tur arī ir daudz interesanta.
Avots: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish