Runājot par programmatūras izstrādi, mūsdienīga devops prakse - kur izstrādātāji un IT operācijas apvieno programmatūras piegādi racionalizētākā veidā - ir plaši izplatījusies uzņēmumā, jo arvien vairāk organizāciju saskata lielākas automatizācijas un citas priekšrocības. biežas izlaišanas.
Tagad, pandēmijai uzsverot nepieciešamību pēc lielākas digitālās veiklības, vai adopcijas adopcija paātrināsies vēl ātrāk?
Tuvojoties Enterprise Devops Summit Londonas izdevumam (jaunajā virtuālajā formātā), tas bija pirmais jautājums, ko mēs uzdevām tā saimniekam un dibinātājam Džīnam Kimam, bijušajam Tripwire CTO un trīs populāru Devops grāmatu autoram.
Tālāk norādītā saruna ir rediģēta skaidrības un īsuma labad.
: Kā pandēmija ir plaši ietekmējusi devops?
Džēns Kims: Pašlaik vietnē Twitter ir meme, par kuru C līmeņa izpilddirektors visvairāk ir virzījis digitālo traucējumu programmu? Vai tas ir izpilddirektors, finanšu direktors, CIO vai COVID-19? COVID-19 ir uzvarētājs. Es domāju, ka tā ir tik patiesa.
Digitālie traucējumi pagājušajā gadā bija gandrīz katrā valdes darba kārtībā. Tagad COVID-19 to ir virzījis uz priekšu trīs līdz piecus gadus. Es domāju, ka tas ir bijis tik interesanti, vai ir tik daudz varoņdarbu stāstu, kas organizācijām ir jādara, lai desmitiem tūkstošu, simtu tūkstošu strādnieku varētu strādāt mājās. Tas bija iespējams tikai pēc būtības pārkāpjot visus noteikumus.
Tas parāda IT un biznesa vadību, kas ir iespējams un uz ko šīs komandas faktiski spēj. Tik bieži viņi tiek važoti, un lielākā daļa cilvēku teiktu, ka viss, kas tika darīts, lai ļautu cilvēkiem strādāt mājās - daži, kas iepriekš nekad nav strādājuši mājās, piemēram, back office finanšu komandas, bija tikai mazs brīnums.
: Jaunākais State of Devops ziņojums parādīja šo milzīgo organizāciju vidusceļu, kad runa ir par devops briedumu.
Vai jūs domājat, ka pandēmija virzīs šo vidusceļu nobriedušākā telpā, vai jūs domājat, ka ir grūti atjaunot komandu darbību, kad visi atrodas tālvadības pultī?
Kima: Es nedomāju, ka tas būs šķērslis, fakts, ka tas ir attālināts. Mēs zinām, ka tas ir iespējams. Viens no maniem lielākajiem pārsteigumiem manā ceļojumā bija uzzināt, ka GitHub 2010. gadu sākumā visa infrastruktūras komanda bija nomaļa. Tāpēc pirmajās dienās vienā un tajā pašā pilsētā nebija divu operētājsistēmu inženieru.
Piecu gadu laikā pēc ziņojuma par Devopsa štatu esam secinājuši, ka nozarei nav nozīmes. Nav svarīgi, vai jūs nodarbojaties veselības aprūpē, mazumtirdzniecībā vai citur. Varbūtība būt labam, vidējam vai sliktam izpildītājam būtībā bija vienāda neatkarīgi no nozares.
Tas mainījās pagājušajā gadā, un tieši mazumtirdzniecība, visticamāk, bija labākā veiktspēja. Es domāju, ka tas parāda, ka mazumtirdzniecības fokuss vai eksistenciāls drauds mudina mazumtirdzniecības nozari ātrāk pielāgot devops praksi. Es domāju, ka no tā izriet, ka COVID-19 mudinās katru nozari ātrāk pieņemt devops tikai visu uzņēmējdarbības spiedienu dēļ, par kuriem mēs tikko runājām.
: Kā jūs jūtaties par DevSecOps un citas jaunas terminoloģijas pieaugumu ap devops?
Kims: Šis ir arguments, kas man bija, kad 2016. gadā iznāca Devops rokasgrāmata kopā ar savu līdzautoru Džonu Vilisu. Viņam bija viscerāla reakcija, ka ir tikai viens devops. Tas nenozīmē, ka viņš tam netic, bet tas, ko viņš mani pārliecināja, bija tas, ka tajā brīdī nozarē mums bija vajadzīgs viens lietussargs, lai visu varētu ievietot. Es mīlu DevSecOps ideju vai jebkādu veidu, kā paplašināt lietussargu un ieved citas ciltis. Es mīlu devopus, jo tas nozīmē, ka viss, kas nav devops, mums jāsaista ar vecajiem, sliktajiem darbības veidiem.
: Kā ar AIops?
Kims: Jā, AIops, MLops, man patīk šī frāze, taču es uzskatu šauru viedokli, ka gandrīz nav vērtību straumes, ko nevarētu uzlabot, izmantojot datus, kurus šī vērtību straume rada. Vai tas ir mārketings klientu pirkšanas prognozēm, vai neveiksmes analīze un infrastruktūras prognozēšana.
Problēma ir tāda, ka tad, kad jums ir 50 miljonu ASV dolāru mašīnmācīšanās projekti, kurus veikuši profesionāļi, kas nav programmatūra, viņi neizmanto versiju kontroli vai labākos paņēmienus, ko esam izstrādājuši pēdējo 30 gadu laikā. Viss apmācības komplektu un šo jauno ražošanas modeļu ģenerēšanas veids ir atšķirīgs, nekā mēs, programmatūras inženieri, izmantojam.
Korporācija Microsoft runāja par to, kā viņi izmanto MLops, lai šos datu zinātniekus integrētu tehnoloģiju vērtību plūsmās. Džons Deerijs sniedza prezentāciju par to, kā viņi to dara daudzu savu iniciatīvu labā.
Problēma ir tāda, ka bieži vien jums ir šie modeļi, kuru prototipi ir veidoti Python vai SPSS, kas ir lieliski, taču tie nav gatavi ražošanai. Tāpēc ir nepieciešams kaut kas cits, lai pārliecinātos, ka misija patiešām tiek pasniegta. AI rada visu šo atšķirīgo ražošanas pakalpojumu radīšanas problēmu. Tur ir īsts bagāts lauks, kas noteikti jārisina.
: Kādas ir lielākās atlikušās problēmas organizācijām, kuras izmanto devops praksi? Un vai ir alternatīvs maršruts?
Kims: Es domāju, ka devops ir nepielūdzams, neizbēgams. Es teiktu, ka vislielākais šķērslis ir vadība un uzņēmējdarbības pirkšana. Kad es skatos konferences pēdējos septiņus gadus, viena no lietām, kas patiešām izceļas, ir cilvēki, kas uzstājas ar prezentācijām, katru gadu ir vecāki.
Šogad mums ir Patriks Eldridžs, Nationwide Building Society vadītājs. Mums ir virkne VP un CTO, un viņi bieži prezentē savu biznesa kolēģi, personu, kas atbild par peļņu un zaudējumiem par šiem uzņēmumiem. Es domāju, ka tas parāda, ka devops faktiski nav tehnoloģiska problēma, tā ir biznesa problēma. Šīs ir sarunas, kas parāda, cik lielā mērā devops ir integrēts visos stratēģijas un darbības aspektos.
Ņemsim Nationwide, viņi pieņem darbā apmēram 1200 cilvēkus, kad liela daļa nozares sarūk. Es domāju, ka tas tikai parāda, cik spēcīgs signāls, ka devops ne tikai ļauj organizācijām izdzīvot tirgū, bet arī uzplaukt vidē, kur tās aug, kamēr citas sarūk.
: Kā konteineru pieaugums ietekmē devops praksi?
Kims: Visas šīs tehnoloģijas - konteineri, iespējams, ir visspēcīgākie - patiešām piespieda cilvēkus domāt par nemainīgu infrastruktūru vai infrastruktūru kā kodu. Es nezinu, uz kuru pusi cēloņsakarība iet, vai nu cilvēki, kas domā devops veidā, kur viņi jau domā par infrastruktūru kā kodu, iespējams, daudz ātrāk uzņem tādas lietas kā konteinerus, vai varbūt konteineru vērtība ir tik augsta ka tas iesūc cilvēkus.
Kurš varētu atgriezties pie vecā veida, mēģinot izdomāt, kā panākt, lai klēpjdatora vide izskatās tāda pati kā ražošanas vide? Tāpēc visas šīs lietas padara tik skaidru, ka ir labāks darba veids. Manuprāt, ir ļoti grūti atgriezties, kad esat paveicis tādas darbības kā nepārtraukta integrācija, piemēram, nepārtraukta piegāde. Kad esat to pieredzējis, ir ļoti grūti atgriezties pie vecā lietu darīšanas veida.
Es domāju, ka Edgars Šeins antropoloģijā un socioloģijā teica, ka “rīki ir kultūras artefakts”. Tātad rīki maina domāšanas veidu un darba veidu. Tāpēc es piekrītu jūsu apgalvojumam, ka šie rīki noteikti paātrina devops darba veidu.
: Kāpēc līdz šim ir bijis tik grūti integrēt drošību devops?
Kims: Ja mums būtu šī saruna pirms astoņiem gadiem, es domāju, ka mēs jautātu: "Kāpēc ir grūti panākt operācijas uz kuģa?" Vai tas ir tāpēc, ka viņi baidās no darba pārtraukšanas?
Daži cilvēki runā par NoOps, kur mums vairs nav vajadzīgas darbības, kad, manuprāt, tas ir diezgan skaidrs ikvienam, kurš ir izmantojis Kubernetes, zina, ka neviens izstrādātājs nevēlas faktiski apgūt Kubernetes, mēs vēlamies, lai infrastruktūras cilvēki to izdarītu mūsu vietā. Es domāju, ka tas pats attiecas uz drošību. Mēs vēlamies, lai produktu komandas un izstrādes komandas būtu pilnībā atbildīgas par pakalpojumu pieejamību, darbspēju un drošību. Mēs nevēlamies, lai izstrādātājiem būtu jākļūst par ekspertiem ikviena kakta līmenī, kurā var paslēpties drošības ievainojamības.
Mēs patiešām vēlamies izmantot drošības speciālistu prasmes, vai nu ievedot viņus komandās, vai arī viņu izveidotās platformas, lai viss, ko mēs rakstām uz platformas, būtu principiāli drošāks. Es domāju, ka tā diena tuvojas. Tāpat kā operācijas, šī plaisa ar izstrādātājiem ir tik liela, ka dabiskā reakcija ir “pār manu mirušo ķermeni”, un es esmu pārliecināts, ka to varētu noorganizēt.
: Kā ir attīstījies devops inženiera iemaņas?
Kima: Viena no vissvarīgākajām prasmēm, spējām un īpašībām, kas vajadzīga šajos celmlauža sacelšanās gadījumos - izmantojot devops, lai gāztu seno vareno kārtību, kuri ir ļoti priecīgi darīt lietas tā, kā viņiem ir 30 līdz 40 gadus, ir funkcionālās prasmes, kas jāspēj sazināties ar biznesa partneriem un palīdzēt risināt problēmas. Tā šīs komandas pieaug un pieņem darbā, kad sarūk tik daudz citu komandu.
Viens no kopsaucējiem sarunās, kuras esmu dzirdējis līdz šim, ir tas, ka viņi visi pieņem darbā. Es domāju, ka novecojušajiem cilvēkiem ir tik daudz darāmā, un jo vairāk viņi var atrast šīs iniciatīvas, un biznesa cilvēkiem, kuriem tie ir vajadzīgi, nākotne ir ļoti gaiša.
Mans draugs Toms Limoncelli, kurš uzrakstīja grāmatu par mākoņu sistēmas administrēšanu - viņš to teica operācijām, bet es domāju, ka to var pielietot visur - ir tas, ka mēs esam ceļa atzarojumā: pa vienu ceļu mūsu alga samazinās uz pusi un vienīgais darbs, ko mēs varam atrast, ir Apple veikala Genius bārā. Pa otru ceļu mūsu alga dubultojas, jo mums tirgū ir viskarstākās prasmes. Es domāju, ka tas bija izcili.
