Izaicinājumu pārvarēšana pārvaldītā DevOps: visaptverošs ceļvedis

Ievads

Strauji mainīgajā programmatūras izstrādes un IT operāciju ainavā organizācijas arvien biežāk izmanto pārvaldītus DevOps pakalpojumus, lai racionalizētu procesus, uzlabotu sadarbību un paātrinātu piegādi. Pēdējos septiņus gadus esmu pavadījis, palīdzot uzņēmumiem īstenot DevOps transformācijas, un varu teikt no pirmavota - tas nekad nav tik vienkārši, kā tas izskatās glancētajās brošūrās. Lai gan pārvaldītā DevOps piedāvā milzīgus ieguvumus, sākot no izmaksu ietaupījuma līdz ātrākai izvēršanai, organizācijas bieži sastopas ar ievērojamiem šķēršļiem ieviešanas un nepārtrauktas darbības laikā. Šajā visaptverošajā rokasgrāmatā ir apkopota mana reālā pieredze, lai palīdzētu jums pārvarēt biežāk sastopamās pārvaldības DevOps problēmas un ieviest praktiskus risinājumus, kas patiešām darbojas ražošanas vidēs.

Realitātes plaisa pārvaldītā DevOps gaidās

Viena no lielākajām problēmām, ar ko es sastopos, konsultējot klientus, ir atšķirība starp gaidām un realitāti. Daudzas organizācijas iesaistās pārvaldītā DevOps ar nereālistiskiem termiņiem un cerībām.

Pagājušajā gadā es strādāju ar vidēja lieluma finanšu tehnoloģiju uzņēmumu, kas cerēja pilnībā pārveidot savu izlaišanas ciklu no ikmēneša uz ikdienas izvietošanu tikai sešu nedēļu laikā pēc tam, kad piesaistīja pārvaldītu DevOps pakalpojumu sniedzēju. Realitāte? Lai sasniegtu šo mērķi, bija nepieciešami gandrīz seši mēneši. Kāpēc? Tāpēc, ka viņi nepietiekami novērtēja vairākus būtiskus faktorus:

1. mantotās sistēmas sarežģītība: Banku pamatplatformai bija vairāk nekā 15 gadu tehniskais parāds un praktiski nekāda automatizācija.

2. Komandas prasmju trūkumi: Viņu izstrādātājiem bija minimāla pieredze ar konteinerizāciju, infrastruktūru kā kodu vai CI/CD praksi.

3. Organizācijas pretestība: Vidējā līmeņa vadība klusībā izrādīja pretestību pret ieviestajiem procesiem.

Reālistisku gaidu noteikšana

Lai izvairītos no līdzīgām vilšanās situācijām, es tagad saviem klientiem iesaku:

• Veiciet rūpīgu novērtējumu: Pirms parakstīt līgumu ar jebkuru pārvaldītu DevOps pakalpojumu sniedzēju, veiciet detalizētu pašreizējā stāvokļa analīzi, tostarp tehnisko parādu, prasmju trūkumu un organizatoriskās gatavības analīzi.

• Izveidojiet pakāpeniskas īstenošanas plānu: Sadaliet pāreju 30, 60 un 90 dienu posmos ar skaidriem, izmērāmiem mērķiem.

• Budžets mācību procesa izmaksām: Sākotnējā pārejas posmā, kad komandas pielāgojas jaunajiem rīkiem un procesiem, sagaidiet par 20-30% zemāku produktivitāti.

Viens no maniem veselības aprūpes klientiem izmantoja šo pakāpenisko pieeju un panāca daudz vienmērīgāku pāreju. Mēs sākām ar vienkāršu CI cauruļvadu nekritiskai iekšējai lietojumprogrammai, pēc tam, kad komanda ieguva pārliecību un kompetenci, pakāpeniski paplašinājām to līdz sarežģītākām sistēmām.

Kultūras pretestība: Klusais DevOps slepkava

Mana pieredze liecina, ka pārvaldītā DevOps tehniskie izaicinājumi reti kad ir visgrūtāk risināmie. Patiesie šķēršļi parasti ir cilvēciski un organizatoriski.

Ražošanas nozares klients mani piesaistīja pēc tam, kad viņa pārvaldītā DevOps iniciatīva bija iestrēgusi mēnešiem ilgi. Uz papīra viss izskatījās pareizi - viņiem bija visi rīki, cienījams pakalpojumu sniedzējs un vadības atbalsts. Problēma? Dziļi iesakņojusies kultūras pretestība starp viņu izstrādes un operāciju komandām.

Izstrādātāji uzskatīja, ka jaunie CI/CD cauruļvadi "ierobežo viņu radošumu", savukārt operatīvie darbinieki uzskatīja automatizēto izvietošanu par "riskantiem īsceļiem", kas radīs problēmas, kuras viņiem būs jānovērš. Neviena no šīm grupām nebija pienācīgi iesaistīta lēmumu pieņemšanas procesā.

DevOps kultūras veidošana, kas noturīga

Lūk, kas patiesībā palīdzēja pārvarēt šo pretestību:

• Izveidojiet kopīpašumtiesības: Mēs izveidojām daudzfunkcionālas komandas ar kopīgiem pienākumiem un KPI, kas sasaistīja attīstības un darbības panākumus.

• Demonstrējiet agrīnas uzvaras: Mēs identificējām ātrus ieguvumus, kas bija izdevīgi abām grupām - izstrādātāji ātrāk saņēma atgriezenisko saiti par savu kodu, savukārt operatīvie darbinieki saņēma mazāk ārkārtas zvanu pusnakts laikā.

• Nodrošināt praktisku apmācību: Tā vietā, lai veiktu teorētisko apmācību, mēs izmantojām reālas ražošanas problēmas kā mācību iespējas problēmu kopīgai risināšanai.

• Atzīmējiet panākumus publiski: Mēs izveidojām paneli "izvietošanas uzvara", kurā tika sekots līdzi veiksmīgai izvietošanai, samazinātam incidentu skaitam un ietaupītajam laikam.

Sešus mēnešus vēlāk tās pašas komandas, kas bija apdraudējušas DevOps pāreju, bija tās lielākie atbalstītāji. Galvenā mācība? Tehniskā ieviešana bez kultūras saskaņošanas vienmēr būs sarežģīta.

Drošības integrācijas izaicinājumi strauji mainīgajos cauruļvados

Drošība joprojām ir viena no problemātiskākajām jomām pārvaldītā DevOps ieviešanā. Es nespēju saskaitīt, cik reizes esmu redzējis, ka organizācijas ievieš ātrus piegādes ciklus tikai tādēļ, lai radītu jaunas drošības ievainojamības.

Mazumtirdzniecības klients, ar kuru es strādāju pagājušajā gadā, palielināja izvietošanas biežumu no mēneša uz nedēļu, izmantojot pārvaldītu DevOps, bet netīšām ievietoja ražošanā trīs kritiskas drošības ievainojamības, jo drošības procesi nespēja tikt līdzi paātrinātajam izstrādes ciklam.

Praktiska DevSecOps integrācija

Pamatojoties uz vairākām veiksmīgām drošības integrācijām, ko esmu īstenojis, ir aprakstīts, kas darbojas:

• Pārvietojiet drošību pa kreisi: Integrējiet automatizētu drošības skenēšanu visos izstrādes posmos, sākot ar IDE spraudņiem, kas brīdina izstrādātājus par problēmām, pirms viņi vēl nodod kodu.

• Automatizēt atbilstības pārbaudi: Regulētajās nozarēs ievietojiet automatizētas atbilstības pārbaudes, kas pārbauda konfigurāciju atbilstību nepieciešamajiem standartiem pirms izvietošanas.

• Īstenojiet drošību kā kodu: Drošības konfigurācijas un politikas tiek uzskatītas par kodu, kas ir līdzās lietojumprogrammas kodam, ievērojot tos pašus pārskatīšanas un testēšanas procesus.

• Izveidojiet drošības čempionus: Ieceliet un apmāciet komandas locekļus, kuri savās komandās darbojas kā drošības aizstāvji, ieviešot drošības izpratni ikdienas izstrādes darbos.

Pēc šīs prakses ieviešanas mans mazumtirdzniecības klients varēja saglabāt savu iknedēļas izvietošanas ciklu, vienlaikus uzlabojot savu drošības stāvokli. Viņu drošības komanda no bloķētājiem kļuva par drošas un ātras piegādes veicinātājiem.

Tehniskais parāds: DevOps ieviešanas bloķētājs

Gandrīz visas organizācijas, ar kurām esmu konsultējies, ir nepietiekami novērtējušas, kā to esošais tehniskais parāds ietekmēs DevOps transformāciju. Pārmantotās sistēmas, manuāli procesi un slikta dokumentācija var ievērojami palēnināt pārvaldītu DevOps ieviešanu.

Finanšu pakalpojumu uzņēmums, ar kuru sadarbojos, mēnešiem ilgi cīnījās, lai integrētu savas mantotās mainstreima sistēmas jaunajos CI/CD cauruļvados. Sistēmās nebija atbilstošu API saskarņu, tām bija minimāla automatizēta testēšana, un tās balstījās uz dažu vecāko inženieru, kas tuvojās pensijai, cilmes zināšanām.

Stratēģiska tehniskā parāda risināšana

Tā vietā, lai izvēlētos "viss vai nekas" pieeju, mēs īstenojām šādu stratēģiju:

• Kartējiet savu īpašumu: Kataloģizējiet visas lietojumprogrammas un infrastruktūras komponentus, novērtējot katras no tām gatavību DevOps, izmantojot vienkāršu sarkanās/dzeltenās/zaļās krāsas sistēmu.

• Izveidojiet integrācijas robežas: Vecākām sistēmām, kuras nevar viegli modernizēt, izveidojiet tīras saskarnes un API slāņus, kas ļauj jaunākām sistēmām mijiedarboties ar tām.

• Stratēģiski jānosaka prioritātes: Koncentrējiet sākotnējos DevOps centienus uz sistēmām ar lielu biznesa vērtību un mazāku sarežģītību, kurās varat ātri pierādīt panākumus.

• Piešķiriet laiku parādu samazināšanai: Vispirms pievērsiet 20% sprinta laika tieši tehnisko parādu samazināšanai, koncentrējoties uz elementiem, kas rada vislielāko ietekmi.

Izmantojot šo pieeju, finanšu pakalpojumu uzņēmums gada laikā veiksmīgi ieviesa mūsdienīgu DevOps praksi 60 % lietojumprogrammu portfeļa, vienlaikus izstrādājot ilgtspējīgu plānu pārējām mantotajām sistēmām.

Instrumentu izplešanās un integrācijas sarežģītība

Vēl viena bieži sastopama problēma, ko esmu novērojis, ir DevOps rīku, kas nedarbojas labi kopā, izplatīšanās. Vienam telekomunikāciju klientam bija uzkrājušies 14 dažādi CI/CD cauruļvada, monitoringa, drošības skenēšanas un infrastruktūras pārvaldības rīki, un lielākoties bija nepieciešams manuāli pārslēgties starp sistēmām.

DevOps rīku ķēdes pieradināšana

Pamatojoties uz manis vadītajām veiksmīgajām instrumentu ķēžu konsolidācijām, šeit ir aprakstīts, kas darbojas:

• Nosakiet prioritāti integrācijas iespējām: Izvēloties rīkus, priekšroku dodiet tiem rīkiem, kuriem ir spēcīgas API un iepriekš sagatavotas integrācijas ar jūsu esošo rīku kopumu.

• Platformas pieejas īstenošana: Apsveriet DevOps platformas, kas nodrošina vairākas iespējas integrētā paketē, nevis apkopo labākos no dažādiem punktveida risinājumiem.

• Automatizēt rīku ķēdes testēšanu: Izveidojiet automatizētus testus savai DevOps rīku ķēdei, lai nodrošinātu, ka integrācijas turpina darboties, kad rīki tiek atjaunināti.

• Dokumentu darbplūsmas no gala līdz galam: Izveidojiet skaidru vizuālu dokumentāciju, kurā parādīta darba plūsma visā rīku ķēdē, identificējot manuālās darbības, kuras varētu automatizēt.

Konsolidējot rīku ķēdi līdz pieciem labi integrētiem rīkiem, mans telekomunikāciju klients par 70 % samazināja izvietošanas laiku un novērsa daudzus manuālus soļus starp sistēmām, kas rada risku kļūdām.

Mēroga mērogošanas izaicinājumi uzņēmumu vidēs

DevOps prakses paplašināšana ārpus sākotnējām izmēģinājuma komandām rada unikālus izaicinājumus, kurus daudzas organizācijas nepietiekami novērtē. Veselības aprūpes uzņēmums, ar kuru es strādāju, veiksmīgi ieviesa DevOps praksi vienā lietojumprogrammu komandā, bet, kad to mēģināja paplašināt līdz vairāk nekā 20 komandām, modelis sabruka.

Veiksmīga DevOps mērogošana

Šī ir pieeja, kas galu galā izrādījās veiksmīga:

• Izveidojiet iekšējo DevOps platformas komandu: Izveidojiet īpašu komandu, kas koncentrējas uz atkārtoti izmantojamu cauruļvadu, infrastruktūras veidņu un automatizācijas izveidi, ko var izmantot citas komandas.

• Ieviest iekšējo resursu praksi: Mudiniet komandas dalīties ar automatizācijas kodu, konfigurācijām un labāko praksi, izmantojot iekšējos repozitorijus ar skaidrām norādēm par ieguldījumu.

• Pārdomāti standartizējiet: Nosakiet, kuri DevOps procesa aspekti ir jāstandartizē visās komandās (drošības prasības, izvietošanas apstiprinājumi), bet kuriem komandām jābūt elastīgām (testēšanas ietvaru izvēle, iekšējās darba plūsmas).

• Veidojiet prakses kopienu: Izveidojiet regulārus forumus, kuros DevOps praktiķi dažādās komandās var dalīties panākumos, gūtajā pieredzē un sadarboties kopīgu problēmu risināšanā.

Pēc šīs prakses ieviešanas veselības aprūpes organizācija 18 mēnešu laikā sekmīgi paplašināja DevOps praksi visās 24 lietojumprogrammu komandās, vienlaikus saglabājot konsekventus kvalitātes un drošības standartus.

Izmaksu pārvaldība un optimizācija

Lai gan pārvaldītā DevOps bieži sola izmaksu ietaupījumu, esmu novērojis, ka daudzas organizācijas sākotnēji faktiski saskaras ar izmaksu pieaugumu, ja netiek īstenota pareiza pārvaldība un optimizācijas prakse. Manam mazumtirdzniecības klientam trīs mēnešu laikā pēc DevOps ieviešanas mākoņa infrastruktūras izmaksas divkāršojās, jo izstrādātāji ieguva iespēju paši nodrošināt resursus.

Izmaksu kontrole, neierobežojot inovācijas

Lūk, kas ir strādājis ar maniem klientiem:

• Ieviest marķēšanu un atrādīšanu: Lai varētu izsekot izmaksām un informēt komandas par saviem izdevumiem, pieprasiet, lai visa infrastruktūra tiktu marķēta ar komandu, lietojumprogrammu un vidi.

• Automatizētas izmaksu pārvaldības iestatīšana: Izveidojiet automatizētas politikas, kas atklāj un brīdina par izmaksu anomālijām vai nodrošina ar ražošanu nesaistītu resursu izslēgšanu ārpus darba laika.

• Izmaksu optimizācijas iekļaušana cauruļvadā: Integrējiet infrastruktūras izmaksu analīzes rīkus tieši CI/CD cauruļvados, lai identificētu neefektīvas konfigurācijas pirms izvietošanas.

• Izveidojiet izmaksu līderus: Līdzīgi kā drošības čempionu gadījumā, nozīmējiet komandas locekļus, kas savās komandās ir atbildīgi par izmaksu izpratni un optimizāciju.

Pēc šīs prakses ieviešanas mans mazumtirdzniecības klients samazināja savus mākoņpakalpojumu izdevumus par 40 %, vienlaikus turpinot palielināt izvietošanas biežumu un lietojumprogrammu veiktspēju.

Secinājums: Pārvaldītas DevOps darbības nodrošināšana reālās organizācijās

Balstoties uz maniem gadiem, palīdzot organizācijām ieviest un optimizēt pārvaldīto DevOps, esmu secinājis, ka panākumiem ir jāpievērš vienlīdz liela uzmanība gan tehniskajiem, gan kultūras, gan procesu izaicinājumiem. Organizācijas, kas pieiet pārvaldītai DevOps kā tīri tehniskai ieviešanai, neizbēgami cīnās ar grūtībām, savukārt tās organizācijas, kas līdztekus tehniskajiem elementiem pievēršas cilvēciskajiem un organizatoriskajiem elementiem, gūst ilgstošus panākumus.

Visveiksmīgākajām pārvaldītajām DevOps ieviešanām, kurās esmu piedalījies, ir kopīgas iezīmes:

• Skaidra DevOps mērķu un biznesa mērķu saskaņošana

• Izpildvaras sponsorēšana apvienojumā ar vietējo iedzīvotāju entuziasmu

• Reālistiski termiņi, kas ņem vērā organizācijas mācīšanās līknes.

• Līdzsvarota koncentrēšanās uz cilvēkiem, procesiem un tehnoloģijām.

• Gatavība pielāgoties, pamatojoties uz atgriezenisko saiti un izmērītajiem rezultātiem.

Paredzot un proaktīvi risinot šajā rokasgrāmatā aprakstītās problēmas, organizācijas var ievērojami palielināt savas izredzes pilnībā izmantot pārvaldītas DevOps priekšrocības: ātrāku piegādi, uzlabotu kvalitāti, uzlabotu drošību un galu galā labākus biznesa rezultātus.