Premagovanje izzivov v upravljanem DevOps: celovit vodnik

Uvod

V hitro razvijajočem se okolju razvoja programske opreme in delovanja IT se organizacije vse pogosteje obračajo na upravljane storitve DevOps, da bi racionalizirale svoje procese, izboljšale sodelovanje in pospešile dostavo. Zadnjih sedem let pomagam podjetjem pri izvajanju preobrazbe DevOps in iz prve roke vam lahko povem, da to nikoli ni tako preprosto, kot se zdi v bleščečih brošurah. Čeprav upravljani DevOps ponuja izjemne prednosti, od prihranka stroškov do hitrejših ciklov uvajanja, organizacije pogosto naletijo na velike ovire med izvajanjem in tekočim delovanjem. Ta izčrpen vodnik temelji na mojih resničnih izkušnjah in vam pomaga pri premagovanju pogostih izzivov na področju upravljanega DevOps in izvajanju praktičnih rešitev, ki dejansko delujejo v produkcijskih okoljih.

Vrzel v realnosti pri pričakovanjih upravljanega sistema DevOps

Ena od največjih težav, s katerimi se srečujem pri svetovanju strankam, je razkorak med pričakovanji in resničnostjo. Veliko organizacij se loti upravljanja DevOps z nerealnimi časovnimi okviri in pričakovanji.

Lani sem sodeloval s srednje velikim fintech podjetjem, ki je pričakovalo, da bo v šestih tednih po vključitvi ponudnika upravljanega DevOps popolnoma spremenilo svoj cikel izdaje z mesečnih na dnevne namestitve. V resnici je bilo tako? Za dosego tega cilja je bilo potrebnih skoraj šest mesecev. Zakaj? Ker so podcenili več ključnih dejavnikov:

1. Kompleksnost starejšega sistema: njihova osnovna bančna platforma je imela več kot 15 let tehničnega dolga in skoraj nobene avtomatizacije.

2. Vrzeli v veščinah ekipe: Njihovi razvijalci so imeli minimalne izkušnje s kontejnerizacijo, infrastrukturo kot kodo ali praksami CI/CD.

3. Organizacijski odpor: Srednje vodstvo se je tiho upiralo spreminjanju ustaljenih postopkov.

Realistično določanje pričakovanj

Da bi se izognili podobnim razočaranjem, zdaj strankam svetujem:

• Izvedite temeljito oceno: Preden podpišete pogodbo s katerim koli ponudnikom upravljanega DevOps, opravite podrobno analizo svojega trenutnega stanja, vključno s tehničnim dolgom, vrzelmi v znanju in spretnostih ter organizacijsko pripravljenostjo.

• Ustvarite načrt za postopno izvajanje: Prehod razdelite na 30-, 60- in 90-dnevne mejnike z jasnimi in merljivimi cilji.

• Načrtujte sredstva za učenje: Pričakujte 20-30-odstotno zmanjšanje produktivnosti med začetnim prehodom, ko se ekipe prilagajajo novim orodjem in postopkom.

Moja stranka v zdravstvu je uporabila ta postopni pristop in dosegla veliko lažji prehod. Začeli smo s preprostim cevovodom CI za nekritično notranjo aplikacijo, nato pa smo postopoma razširili na bolj zapletene sisteme, ko je ekipa pridobila zaupanje in usposobljenost.

Kulturni odpor: Tihi ubijalec DevOps

Po mojih izkušnjah so tehnični izzivi upravljanega DevOps-a le redko najtežje rešljivi. Resnične ovire so običajno človeške in organizacijske.

Stranka iz proizvodne industrije me je povabila, ko je njihova pobuda za upravljanje DevOps več mesecev mirovala. Na papirju je bilo vse videti prav - imeli so vsa orodja, uglednega ponudnika storitev in podporo vodstva. Težava? Globoko zakoreninjen kulturni odpor med njihovimi razvojnimi in operativnimi ekipami.

Razvijalci so nove cevovode CI/CD razumeli kot "omejevanje njihove ustvarjalnosti", medtem ko so operaterji avtomatizirane namestitve razumeli kot "tvegane bližnjice", ki bodo povzročile težave, ki jih bodo morali odpraviti. Nobena od skupin ni bila ustrezno vključena v proces odločanja.

Vzpostavitev kulture DevOps, ki se obdrži

Tukaj je opisano, kaj je dejansko pomagalo premagati ta odpor:

• Ustvarite skupno lastništvo: Oblikovali smo medfunkcijske skupine s skupnimi odgovornostmi in ključnimi kazalniki uspešnosti, ki povezujejo razvojni in operativni uspeh.

• Dokažite prve zmage: Razvijalci so hitreje dobili povratne informacije o svoji kodi, medtem ko je bilo v operativi manj polnočnih klicev v sili.

• Zagotovite praktično usposabljanje: Namesto teoretičnega usposabljanja smo kot učne priložnosti za skupno reševanje problemov uporabili resnične težave v proizvodnji.

• Uspeh proslavite javno: Ustvarili smo nadzorno ploščo "zmaga pri uvajanju", na kateri smo spremljali uspešne uvedbe, zmanjšano število incidentov in prihranjen čas.

Šest mesecev pozneje so bile iste ekipe, ki so spodkopavale prehod na DevOps, njegovi največji zagovorniki. Ključna lekcija? Tehnične implementacije brez kulturne usklajenosti bodo vedno težavne.

Izzivi pri integraciji varnosti v hitro premikajočih se cevovodih

Varnost ostaja eno od najbolj problematičnih področij pri upravljanih uvedbah DevOps. Ne morem prešteti, kolikokrat sem videl, da so organizacije sprejele hitre cikle izdelave samo zato, da so ustvarile nove varnostne ranljivosti.

Maloprodajna stranka, s katero sem sodeloval lani, je z uporabo upravljanega DevOps povečala pogostost uvajanja z mesečne na tedensko, vendar je nenamerno v produkcijo uvedla tri kritične varnostne ranljivosti, ker njeni varnostni postopki niso mogli slediti pospešenemu razvojnemu ciklu.

Praktična integracija DevSecOps

Na podlagi več uspešnih varnostnih integracij, ki sem jih izvedel, vam povem, kaj deluje:

• Varnostni premik v levo: Vključite avtomatizirano varnostno pregledovanje v vsako fazo cevovoda, začenši z vtičniki IDE, ki razvijalce opozorijo na težave, še preden oddajo kodo.

• Avtomatizirano preverjanje skladnosti: Za regulirane panoge izvedite avtomatizirano preverjanje skladnosti, ki potrdi konfiguracije glede na zahtevane standarde, preden dovolite uvedbo.

• Izvajanje varnosti kot kode: Varnostne konfiguracije in politike obravnavajte kot kodo, ki živi skupaj z aplikacijsko kodo, pri čemer se uporabljajo enaki postopki pregledovanja in testiranja.

• Ustvarite varnostne prvake: Določite in usposobite člane ekipe, ki bodo v svojih ekipah delovali kot varnostni zagovorniki in varnostno ozaveščenost vključevali v vsakodnevne razvojne dejavnosti.

Po uvedbi teh praks je moja maloprodajna stranka lahko ohranila svoj tedenski cikel uvajanja, hkrati pa dejansko izboljšala svojo varnostno držo. Njihova varnostna ekipa se je preusmerila od oviranja k omogočanju varne in hitre dostave.

Tehnični dolg: ovira pri izvajanju DevOps

Skoraj vsaka organizacija, s katero sem se posvetoval, je podcenila, kako bo njihov obstoječi tehnični dolg vplival na preobrazbo DevOps. Zastareli sistemi, ročni postopki in slaba dokumentacija lahko bistveno upočasnijo upravljano izvajanje DevOps.

Podjetje za finančne storitve, s katerim sem sodeloval, se je več mesecev trudilo vključiti svoje starejše sisteme mainframe v nove cevovode CI/CD. Sistemi niso imeli ustreznih vmesnikov API, imeli so minimalno avtomatizirano testiranje in se zanašali na plemensko znanje nekaj starejših inženirjev, ki so bili tik pred upokojitvijo.

Strateško reševanje tehničnega dolga

Namesto pristopa "vse ali nič" smo uporabili to strategijo:

• Načrtujte svoje posestvo: Vsa aplikacija in infrastrukturne komponente se katalogizirajo in ocenijo glede pripravljenosti za DevOps z uporabo preprostega sistema rdeča/jantarna/zelena.

• Ustvarite meje povezovanja: Za starejše sisteme, ki jih ni mogoče enostavno posodobiti, ustvarite čiste vmesnike in plasti API, ki omogočajo interakcijo z novejšimi sistemi.

• Strateško določite prednostne naloge: Osredotočite začetna prizadevanja za DevOps na sisteme z visoko poslovno vrednostjo in manjšo kompleksnostjo, kjer lahko hitro dokažete uspeh.

• Razporedite čas za zmanjšanje dolga: Najprej se osredotočite na elemente z največjim vplivom in namenite 20 % zmogljivosti sprinta posebej za zmanjšanje tehničnega dolga.

S tem pristopom je podjetje za finančne storitve v enem letu uspešno preneslo 60 % portfelja aplikacij v sodobno prakso DevOps, hkrati pa ustvarilo trajnostni načrt za preostale starejše sisteme.

Razraščanje orodij in zapletenost integracije

Drug pogost izziv, ki sem ga opazil, je širjenje orodij DevOps, ki ne delujejo dobro skupaj. Neka stranka s področja telekomunikacij je imela 14 različnih orodij za cevovod CI/CD, spremljanje, varnostno pregledovanje in upravljanje infrastrukture - večina od teh orodij je zahtevala ročno preklapljanje med sistemi.

Osvajanje verige orodij DevOps

Na podlagi uspešnih konsolidacij verig orodij, ki sem jih vodil, vam povem, kaj deluje:

• Prednostno določite možnosti integracije: Pri izbiri orodij dajte prednost tistim z zanesljivimi vmesniki API in vnaprej pripravljenimi integracijami z obstoječim naborom orodij.

• Izvajanje platformnega pristopa: Razmislite o platformah DevOps, ki zagotavljajo več zmogljivosti v integriranem paketu, namesto da sestavljate najboljše točkovne rešitve.

• Avtomatizacija testiranja verige orodij: Ustvarite avtomatizirane teste za samo verigo orodij DevOps in tako zagotovite, da bodo integracije delovale tudi po posodobitvi orodij.

• Dokumentirajte delovne tokove od začetka do konca: Ustvarite jasno vizualno dokumentacijo, ki prikazuje, kako delo poteka skozi celotno verigo orodij, in opredelite ročne postopke, ki bi jih bilo mogoče avtomatizirati.

Po konsolidaciji orodne verige na pet dobro integriranih orodij je moja stranka s področja telekomunikacij skrajšala čas uvajanja za 70 % in odpravila številne ročne korake med sistemi, ki so nagnjeni k napakam.

Izzivi skaliranja v podjetniških okoljih

Širjenje praks DevOps prek začetnih pilotnih skupin predstavlja edinstvene izzive, ki jih številne organizacije podcenjujejo. Zdravstveno podjetje, s katerim sem sodeloval, je uspešno uvedlo prakse DevOps v eni ekipi aplikacij, vendar se je njihov model porušil, ko so ga poskušali razširiti na več kot 20 ekip.

Uspešno skaliranje DevOps

Tu je pristop, ki je bil na koncu uspešen:

• Ustvarite notranjo ekipo za platformo DevOps: Vzpostavite posebno ekipo, ki se bo osredotočila na izdelavo ponovno uporabnih cevovodov, infrastrukturnih predlog in avtomatizacije, ki jih bodo lahko uporabljale druge ekipe.

• Izvajati prakse innersource: Spodbujajte ekipe, da delijo avtomatizacijsko kodo, konfiguracije in najboljše prakse prek notranjih repozitorijev z jasnimi smernicami za prispevanje.

• Pametno standardizirajte: Ugotovite, katere vidike procesa DevOps je treba standardizirati v vseh skupinah (varnostne zahteve, odobritve uvajanja) in kje morajo biti skupine prilagodljive (izbira okvirov za testiranje, notranji delovni tokovi).

• Ustvarite skupnost za prakso: Vzpostavite redne forume, na katerih si lahko strokovnjaki iz različnih ekip izmenjujejo uspehe in izkušnje ter sodelujejo pri reševanju skupnih izzivov.

Po uvedbi teh praks je zdravstvena organizacija v 18 mesecih uspešno razširila svoje prakse DevOps na vseh 24 aplikativnih skupin, pri čemer je ohranila dosledne standarde kakovosti in varnosti.

Upravljanje in optimizacija stroškov

Čeprav upravljani DevOps pogosto obljublja prihranek stroškov, sem ugotovil, da se v številnih organizacijah stroški na začetku povečajo, če nimajo ustreznih praks upravljanja in optimizacije. Moja maloprodajna stranka je v treh mesecih po uvedbi DevOps-a opazila podvojitev stroškov infrastrukture v oblaku, saj so razvijalci pridobili možnost samostojnega zagotavljanja virov.

Obvladovanje stroškov brez omejevanja inovacij

Tukaj je opisano, kaj se je obneslo pri mojih strankah:

• Izvajanje označevanja in povratnega prikazovanja: Za spremljanje stroškov in obveščanje ekip o porabi je treba vso infrastrukturo označiti z ekipo, aplikacijo in okoljem.

• Vzpostavite avtomatizirano upravljanje stroškov: Ustvarite avtomatizirane politike, ki zaznajo in opozorijo na stroškovne anomalije ali izsilijo izklop neprodukcijskih virov med delovnim časom.

• Vgradite optimizacijo stroškov v projektno linijo: Vključite orodja za analizo stroškov infrastrukture neposredno v cevovode CI/CD, da pred uvedbo prepoznate neučinkovite konfiguracije.

• Ustvarite stroškovne prvake: Podobno kot pri varnostnih prvakih imenujte člane ekipe, ki so v svojih ekipah odgovorni za ozaveščanje o stroških in njihovo optimizacijo.

Po uvedbi teh praks je moja maloprodajna stranka zmanjšala izdatke za oblak za 40 %, hkrati pa je še naprej povečevala pogostost uvajanja in zmogljivost aplikacij.

Zaključek: Kako upravljani DevOps deluje v resničnih organizacijah

Na podlagi dolgoletne pomoči organizacijam pri izvajanju in optimizaciji upravljanega DevOps-a sem ugotovil, da je za uspeh potrebna enaka pozornost tehničnim, kulturnim in procesnim izzivom. Organizacije, ki k upravljanemu DevOps pristopijo kot k povsem tehnični implementaciji, se neizogibno spopadajo s težavami, medtem ko organizacije, ki poleg tehničnih elementov obravnavajo tudi človeške in organizacijske elemente, dosegajo trajne uspehe.

Najuspešnejše upravljane implementacije DevOps, pri katerih sem sodeloval, imajo skupne značilnosti:

• Jasna usklajenost med cilji DevOps in poslovnimi cilji

• Izvršno sponzorstvo v kombinaciji z navdušenjem navadnih ljudi

• Realistični časovni načrti, ki upoštevajo organizacijske krivulje učenja.

• Uravnotežena osredotočenost na ljudi, procese in tehnologijo

• Pripravljenost za prilagajanje na podlagi povratnih informacij in izmerjenih rezultatov

S predvidevanjem in proaktivnim reševanjem izzivov, opisanih v tem priročniku, lahko organizacije znatno povečajo svoje možnosti za uresničitev vseh prednosti upravljanega DevOps: hitrejše dostave, izboljšane kakovosti, večje varnosti in na koncu boljših poslovnih rezultatov.