Iššūkių įveikimas valdomo DevOps srityje: išsamus vadovas

Įvadas

Sparčiai besikeičiančiame programinės įrangos kūrimo ir IT operacijų kraštovaizdyje organizacijos vis dažniau naudojasi valdomomis "DevOps" paslaugomis, kad supaprastintų savo procesus, pagerintų bendradarbiavimą ir pagreitintų pristatymą. Pastaruosius septynerius metus praleidau padėdamas įmonėms įgyvendinti "DevOps" pertvarkas ir galiu pasakyti iš pirmų lūpų - tai niekada nėra taip paprasta, kaip atrodo iš blizgių brošiūrų. Nors valdomas DevOps teikia didžiulę naudą - nuo išlaidų taupymo iki greitesnio diegimo ciklo, organizacijos dažnai susiduria su didelėmis kliūtimis diegimo ir nuolatinės veiklos metu. Šiame išsamiame vadove remiamasi mano realia patirtimi, kuri padės jums įveikti dažniausiai pasitaikančius valdomos DevOps iššūkius ir įgyvendinti praktinius sprendimus, kurie iš tikrųjų veikia gamybinėse aplinkose.

Valdomo DevOps lūkesčių realybės spraga

Viena didžiausių problemų, su kuriomis susiduriu konsultuodamas klientus, yra lūkesčių ir realybės skirtumas. Daugelis organizacijų į valdomą DevOps įsitraukia turėdamos nerealius terminus ir lūkesčius.

Praėjusiais metais dirbau su vidutinio dydžio finansinių technologijų įmone, kuri tikėjosi visiškai pakeisti savo išleidimo ciklą nuo mėnesinio iki kasdienio diegimo vos per šešias savaites nuo tada, kai pasitelkė valdomą DevOps paslaugų teikėją. Tikrovė? Šiam tikslui pasiekti prireikė beveik šešių mėnesių. Kodėl? Todėl, kad jie neįvertino kelių svarbių veiksnių:

1. Paveldėtos sistemos sudėtingumas: Jų pagrindinė bankininkystės platforma turėjo daugiau nei 15 metų techninių skolų ir praktiškai nebuvo automatizuota.

2. Komandos įgūdžių spragos: Jų kūrėjai turėjo minimalią konteinerizavimo, infrastruktūros kaip kodo ar CI/CD praktikos patirtį.

3. Organizacinis pasipriešinimas: Vidurinioji vadovybė tyliai priešinosi nusistovėjusių procesų keitimui.

Realistinių lūkesčių nustatymas

Kad išvengtų panašių nusivylimų, dabar klientams patariu:

• Atlikite išsamų vertinimą: Prieš pasirašydami sutartį su bet kuriuo valdomu DevOps paslaugų teikėju, atlikite išsamią dabartinės būklės analizę, įskaitant techninius įsiskolinimus, įgūdžių spragas ir organizacinį pasirengimą.

• Sukurkite laipsnišką įgyvendinimo planą: Perėjimą suskirstykite į 30, 60 ir 90 dienų etapus su aiškiais, išmatuojamais tikslais.

• Skirkite lėšų mokymuisi: Tikėkitės 20-30 proc. mažesnio našumo pradinio perėjimo metu, kai komandos prisitaiko prie naujų įrankių ir procesų.

Mano klientas, dirbantis sveikatos priežiūros srityje, taikė šį laipsnišką metodą ir pasiekė daug sklandesnį perėjimą. Pradėjome nuo paprasto CI vamzdyno, skirto ne itin svarbiai vidinei programai, tada, komandai įgijus pasitikėjimo ir kompetencijos, palaipsniui perėjome prie sudėtingesnių sistemų.

Kultūrinis pasipriešinimas: Tylusis DevOps žudikas

Mano patirtis rodo, kad techniniai valdomos DevOps iššūkiai retai būna sunkiausiai išsprendžiami. Tikrosios kliūtys dažniausiai būna žmogiškosios ir organizacinės.

Gamybos klientas kreipėsi į mane po to, kai jo valdoma DevOps iniciatyva kelis mėnesius buvo įstrigusi. Popieriuje viskas atrodė gerai - jie turėjo visas priemones, gerą reputaciją turintį paslaugų teikėją ir vadovų paramą. Problema? Giliai įsišaknijęs kultūrinis pasipriešinimas tarp jų kūrimo ir operacijų komandų.

Kūrėjai manė, kad naujieji CI/CD vamzdynai "riboja jų kūrybiškumą", o operacijų specialistai automatinį diegimą laikė "rizikingu trumpiausiu keliu", dėl kurio kils problemų, kurias jie turės išspręsti. Nė viena iš šių grupių nebuvo tinkamai įtraukta į sprendimų priėmimo procesą.

"DevOps" kultūros kūrimas, kuri įsitvirtina

Štai kas iš tikrųjų padėjo įveikti šį pasipriešinimą:

• Sukurkite bendrą nuosavybę: Mes suformavome tarpfunkcines komandas su bendromis atsakomybėmis ir KPI, kurios susiejo kūrimo ir veiklos sėkmę.

• Parodykite ankstyvus laimėjimus: Kūrėjai gavo greitesnį grįžtamąjį ryšį apie savo kodą, o operacijų specialistai sulaukė mažiau skambučių vidurnaktį.

• Suteikite praktinį mokymą: Vietoj teorinio mokymo mes naudojome realius gamybos klausimus kaip mokymosi galimybes bendrai spręsti problemas.

• Viešai švęskite sėkmę: Sukūrėme "diegimo laimėjimų" prietaisų skydelį, kuriame buvo stebimi sėkmingi diegimai, sumažėjęs incidentų skaičius ir sutaupytas laikas.

Po šešių mėnesių tos pačios komandos, kurios kenkė perėjimui prie "DevOps", tapo didžiausiomis jo šalininkėmis. Pagrindinė pamoka? Techninis diegimas be kultūrinio suderinimo visada bus sunkiai įgyvendinamas.

Saugumo integravimo iššūkiai greitai judančiuose vamzdynuose

Saugumas tebėra viena iš problemiškiausių valdomų "DevOps" diegimo sričių. Nesuskaičiuoju, kiek kartų mačiau, kaip organizacijos priėmė greitus pristatymo ciklus tik tam, kad sukurtų naujų saugumo spragų.

Praėjusiais metais mažmeninės prekybos klientas, su kuriuo dirbau, naudodamas valdomą "DevOps", padidino diegimo dažnumą nuo mėnesio iki savaitės, tačiau netyčia į gamybą įtraukė tris svarbias saugumo spragas, nes jo saugumo procesai nespėjo paskui pagreitėjusį kūrimo ciklą.

Praktinė DevSecOps integracija

Remdamasis keliomis sėkmingai įgyvendintomis saugumo integracijomis, pateikiu, kas veikia:

• Saugumo perkėlimas į kairę: Pradedant IDE įskiepiais, kurie įspėja kūrėjus apie problemas dar prieš jiems atiduodant kodą.

• Automatizuokite atitikties patikrą: Įgyvendinkite automatizuotus atitikties patikrinimus, kuriais prieš leidžiant diegti, konfigūracijos patvirtinamos pagal reikiamus standartus.

• Įgyvendinkite saugumą kaip kodą: Saugumo konfigūracijas ir politiką laikykite kodu, kuris yra kartu su taikomosios programos kodu ir kuriam taikomi tie patys peržiūros ir testavimo procesai.

• Sukurkite saugumo čempionus: Paskirkite ir apmokykite komandos narius, kurie savo komandose veiktų kaip saugumo gynėjai ir į kasdienę kūrimo veiklą įtrauktų saugumo supratimą.

Įdiegęs šią praktiką, mano mažmeninės prekybos klientas sugebėjo išlaikyti savaitinį diegimo ciklą ir kartu pagerinti savo saugumo būklę. Saugumo komanda nebebuvo laikoma blokuojančia, o tapo saugaus ir greito pristatymo iniciatore.

Techninis įsiskolinimas: DevOps įgyvendinimo kliūtis

Beveik kiekviena organizacija, su kuria konsultavausi, nepakankamai įvertino, kaip jų turimos techninės skolos paveiks DevOps transformaciją. Senosios sistemos, rankiniai procesai ir prasta dokumentacija gali labai sulėtinti valdomą DevOps diegimą.

Finansinių paslaugų įmonė, su kuria dirbau, kelis mėnesius stengėsi integruoti savo senąsias mainframe sistemas į naujus CI/CD vamzdynus. Sistemos neturėjo tinkamų API sąsajų, buvo minimaliai automatizuotai testuojamos ir rėmėsi kelių vyresniųjų inžinierių, kurie jau beveik išėjo į pensiją, žiniomis.

Strateginis techninių skolų sprendimas

Vietoj to, kad vadovautumėtės principu "viskas arba nieko", įgyvendinome šią strategiją:

• Sudarykite savo turto žemėlapį: Sudarykite visų programų ir infrastruktūros komponentų katalogą ir įvertinkite, ar kiekviena iš jų yra pasirengusi DevOps, naudodami paprastą raudonos, geltonos ir žalios spalvos sistemą.

• Sukurkite integracijos ribas: Sukurkite švarias sąsajas ir API sluoksnius, kurie leistų naujesnėms sistemoms su jomis sąveikauti.

• Strategiškai nustatykite prioritetus: sutelkite pradines DevOps pastangas į didelę verslo vertę turinčias, mažesnio sudėtingumo sistemas, kuriose galite greitai įrodyti sėkmę.

• Skirkite laiko skolos mažinimui: Skirkite 20 proc. sprinto pajėgumų būtent techninei skolai mažinti, pirmiausia sutelkdami dėmesį į didžiausią poveikį turinčius dalykus.

Taikydama šį metodą, finansinių paslaugų bendrovė per metus sėkmingai įdiegė 60 % savo taikomųjų programų portfelio į modernią DevOps praktiką, o likusioms paveldėtoms sistemoms sukūrė tvarų planą.

Įrankių išsibarstymas ir integracijos sudėtingumas

Dar vienas dažnas mano pastebėtas iššūkis - "DevOps" įrankių, kurie tarpusavyje gerai nedirba, plitimas. Vienas telekomunikacijų klientas buvo sukaupęs 14 skirtingų CI/CD vamzdyno, stebėsenos, saugumo skenavimo ir infrastruktūros valdymo įrankių, iš kurių daugumą reikėjo rankiniu būdu perjungti iš vienos sistemos į kitą.

DevOps įrankių grandinės sutramdymas

Remdamasis sėkmingais įrankių grandinės konsolidavimo procesais, kuriems vadovavau, pateikiu tai, kas veikia:

• Pirmenybę teikite integracijos galimybėms: Rinkdamiesi įrankius pirmenybę teikite tiems, kurie turi patikimas API sąsajas ir iš anksto parengtas integracijas su esamu įrankių rinkiniu.

• Įgyvendinkite platformos metodą: Apsvarstykite DevOps platformas, kurios suteikia daugybę galimybių integruotame pakete, o ne renka geriausius taškinius sprendimus.

• Automatizuoti įrankių grandinės testavimą: Sukurkite automatizuotus pačios DevOps įrankių grandinės testus, kad užtikrintumėte, jog atnaujinus įrankius integracija ir toliau veiktų.

• Dokumentų darbo eigos nuo pradžios iki galo: Sukurkite aiškią vaizdinę dokumentaciją, rodančią, kaip darbas vyksta per visą įrankių grandinę, ir nurodykite rankinius perdavimus, kuriuos būtų galima automatizuoti.

Mano telekomunikacijų klientas, konsolidavęs savo įrankių grandinę iki penkių gerai integruotų įrankių, 70 % sutrumpino diegimo laiką ir panaikino daugybę klaidų keliančių rankinių veiksmų tarp sistemų.

Mastelizacijos iššūkiai įmonių aplinkoje

"DevOps" praktikos masto didinimas po pradinių bandomųjų komandų yra unikalus iššūkis, kurio daugelis organizacijų neįvertina. Sveikatos priežiūros įmonė, su kuria dirbau, sėkmingai įgyvendino DevOps praktiką vienoje taikomųjų programų komandoje, tačiau bandydama išplėsti ją iki daugiau nei 20 komandų, pamatė, kad jų modelis žlugo.

Sėkmingas DevOps mastelio keitimas

Štai metodas, kuris galiausiai pasiteisino:

• Sukurkite vidinę "DevOps" platformos komandą: Sukurkite specialią komandą, kuri daugiausia dėmesio skirtų daugkartinio naudojimo vamzdynų, infrastruktūros šablonų ir automatizavimo kūrimui, kuriais galėtų naudotis kitos komandos.

• Įgyvendinkite vidinių išteklių praktiką: Skatinkite komandas dalytis automatizavimo kodu, konfigūracijomis ir geriausia praktika, naudojant vidines saugyklas su aiškiomis įnašo gairėmis.

• Išmintingai standartizuokite: Nustatykite, kurie DevOps proceso aspektai turėtų būti standartizuoti visose komandose (saugumo reikalavimai, diegimo patvirtinimai), o kurie turėtų būti lankstūs (testavimo sistemų pasirinkimas, vidinės darbo eigos).

• Sukurkite praktikos bendruomenę: Sukurkite reguliarius forumus, kuriuose "DevOps" specialistai iš įvairių komandų galėtų dalytis sėkme, išmoktomis pamokomis ir bendradarbiauti sprendžiant bendrus iššūkius.

Įdiegusi šią praktiką, sveikatos priežiūros organizacija per 18 mėnesių sėkmingai išplėtė DevOps praktiką visose 24 taikomųjų programų komandose, išlaikydama nuoseklius kokybės ir saugumo standartus.

Išlaidų valdymas ir optimizavimas

Nors valdoma "DevOps" dažnai žada sutaupyti lėšų, pastebėjau, kad daugelis organizacijų iš pradžių patiria didesnes išlaidas, jei netaikoma tinkama valdymo ir optimizavimo praktika. Mano mažmeninės prekybos klientas per tris mėnesius nuo DevOps įdiegimo patyrė dvigubai didesnes debesijos infrastruktūros išlaidas, nes programuotojai įgijo galimybę savarankiškai skirti išteklius.

Išlaidų kontrolė neribojant inovacijų

Štai kas pasiteisino su mano klientais:

• Įdiegti žymėjimą ir grįžtamąjį ryšį: Reikalaukite, kad visa infrastruktūra būtų žymima pagal komandą, programą ir aplinką, kad būtų galima stebėti išlaidas ir informuoti komandas apie jų išlaidas.

• Nustatykite automatinį išlaidų valdymą: Sukurkite automatines politikas, kurios aptinka ir įspėja apie sąnaudų anomalijas arba priverčia išjungti negamybinius išteklius ne darbo valandomis.

• Įtraukite sąnaudų optimizavimą į vamzdyną: Integruokite infrastruktūros sąnaudų analizės įrankius tiesiai į CI/CD vamzdynus, kad nustatytumėte neefektyvias konfigūracijas prieš diegimą.

• Sukurkite sąnaudų čempionus: Panašiai kaip ir saugumo čempionai, paskirkite komandos narius, atsakingus už sąnaudų supratimą ir optimizavimą savo komandose.

Įdiegęs šią praktiką, mano mažmeninės prekybos klientas 40 % sumažino savo išlaidas debesijai, kartu toliau didindamas diegimo dažnumą ir taikomųjų programų našumą.

Išvados: Valdomo DevOps pritaikymas realiose organizacijose

Remdamasis savo ilgamete pagalba organizacijoms diegiant ir optimizuojant valdomą DevOps, pastebėjau, kad sėkmei reikia skirti vienodą dėmesį techniniams, kultūriniams ir procesų iššūkiams. Organizacijoms, kurios į valdomą DevOps metodą žiūri kaip į grynai techninį įgyvendinimą, neišvengiamai kyla sunkumų, o organizacijos, kurios kartu su techniniais komponentais sprendžia ir žmogiškuosius bei organizacinius klausimus, pasiekia ilgalaikės sėkmės.

Sėkmingiausiems valdomiems DevOps diegimo projektams, kuriuose man teko dalyvauti, būdingi bendri bruožai:

• Aiškus DevOps tikslų ir verslo tikslų suderinimas

• Vykdomasis rėmimas ir paprastų žmonių entuziazmas

• Realūs terminai, kuriuose atsižvelgiama į organizacijos mokymosi kreives.

• Subalansuotas dėmesys žmonėms, procesams ir technologijoms

• Noras prisitaikyti, atsižvelgiant į grįžtamąjį ryšį ir išmatuotus rezultatus

Numatydamos ir aktyviai spręsdamos šiame vadove nurodytus iššūkius, organizacijos gali gerokai padidinti savo galimybes pasinaudoti visais valdomo DevOps privalumais: greitesniu pristatymu, geresne kokybe, didesniu saugumu ir galiausiai geresniais verslo rezultatais.