Managed DevOps'i väljakutsete ületamine: põhjalik juhend

Intro

Tarkvaraarenduse ja IT-operatsioonide kiiresti areneval maastikul pöörduvad organisatsioonid üha enam juhitud DevOps-teenuste poole, et ühtlustada oma protsesse, tõhustada koostööd ja kiirendada tarneahelaid. Olen viimased seitse aastat aidanud ettevõtetel DevOps-ümberkorraldusi ellu viia ja võin teile omast käest öelda, et see ei ole kunagi nii lihtne, kui läikivates brošüürides paistab. Kuigi juhitud DevOps pakub tohutuid eeliseid, alates kulude kokkuhoiust kuni kiiremate kasutuselevõtutsükliteni, puutuvad organisatsioonid sageli kokku märkimisväärsete takistustega rakendamise ja pideva tegevuse käigus. See põhjalik juhend tugineb minu reaalsetele kogemustele, et aidata teil juhitud DevOpsiga seotud tavaliste probleemidega toime tulla ja rakendada praktilisi lahendusi, mis tegelikult tootmiskeskkondades toimivad.

Reaalsuse lõhe hallatavate DevOps-ootuste osas

Üks suurimaid probleeme, millega ma klientidega konsulteerides kokku puutun, on ootuste ja tegelikkuse vahe. Paljud organisatsioonid lähevad juhitud DevOpsiga tegelema ebareaalsete tähtaegade ja ootustega.

Eelmisel aastal töötasin koos keskmise suurusega fintech-ettevõttega, kes ootas, et nad muudavad oma versioonitsükli täielikult igakuiselt igapäevaseks kasutuselevõtuks vaid kuue nädala jooksul pärast juhitud DevOps-teenuse pakkuja kaasamist. Tegelikkus? Selle eesmärgi saavutamiseks kulus peaaegu kuus kuud. Miks? Sest nad alahindasid mitmeid kriitilisi tegureid:

1. pärandvara süsteemi keerukus: Nende põhipangandusplatvormi tehniline võlg oli üle 15 aasta ja praktiliselt puudus igasugune automatiseerimine.

2. Meeskonna oskuste puudujäägid: Nende arendajatel oli minimaalne kogemus konteinerdamise, taristu kui kood või CI/CD-meetoditega.

3. Organisatsiooniline vastupanu: Keskastme juhtkond oli vaikselt vastu väljakujunenud protsesside muutmisele.

Realistlik ootuste seadmine

Sarnaste pettumuste vältimiseks soovitan ma nüüd klientidel:

• Viige läbi põhjalik hindamine: Enne allakirjutamist ühegi hallatud DevOps-teenuse pakkujaga, tehke üksikasjalik analüüs oma praeguse olukorra, sealhulgas tehnilise võla, oskuste puudujääkide ja organisatsioonilise valmisoleku kohta.

• Looge etapiviisiline rakendusplaan: Jagage üleminek 30, 60 ja 90 päeva pikkusteks vahe-eesmärkideks, millel on selged ja mõõdetavad eesmärgid.

• Arvestage õppimise eelarvega: Esialgse ülemineku ajal tuleb arvestada 20-30% tootlikkuse vähenemisega, kuna meeskonnad kohanevad uute vahendite ja protsessidega.

Üks minu tervishoiuklient kasutas sellist etapiviisilist lähenemist ja saavutas palju sujuvama ülemineku. Alustasime lihtsa CI-putkega mittekriitilise siserakenduse jaoks, seejärel laiendasime seda järk-järgult keerukamatele süsteemidele, kui meeskond saavutas usalduse ja pädevuse.

Kultuuriline vastupanu: DevOps Killer: Vaikne DevOps Killer

Minu kogemuse kohaselt on juhitud DevOpsiga seotud tehnilised väljakutsed harva kõige raskemini lahendatavad. Tõelised takistused on tavaliselt inimlikud ja organisatsioonilised.

Üks tootmisega tegelev klient tõi mind kohale pärast seda, kui nende juhitud DevOps-algatus oli kuude kaupa seisma jäänud. Paberil näis kõik olevat korras - neil olid kõik vahendid, usaldusväärne teenusepakkuja ja juhtkonna toetus. Probleem? Sügavalt juurdunud kultuuriline vastuseis arendus- ja operatsioonimeeskondade vahel.

Arendajad pidasid uusi CI/CD-putkasid "nende loovust piiravaks", samal ajal kui operatsioonid pidasid automatiseeritud juurutusi "riskantseteks otseteedeks", mis tekitaksid probleeme, mida nad peaksid parandama. Kumbagi rühma ei olnud otsustusprotsessi korralikult kaasatud.

DevOps-kultuuri loomine, mis jääb püsima

Siin on see, mis tegelikult töötas selle vastupanu ületamiseks:

• Looge ühisomand: Me moodustasime eri valdkondade vahelised meeskonnad, millel olid ühised kohustused ja tulemuslikkuse näitajad, mis ühendasid arengu ja tegevuse edukuse.

• Näidata varajasi võite: Me tuvastasime kiireid võite, millest said kasu mõlemad rühmad - arendajad said kiiremat tagasisidet oma koodi kohta, samal ajal kui operatsioonide puhul vähenesid kesköised hädaabikõned.

• Anda praktilist koolitust: Teoreetilise koolituse asemel kasutasime tegelikke tootmisprobleeme õppimisvõimalustena ühiseks probleemide lahendamiseks.

• Tähistage edu avalikult: Me lõime "kasutuselevõtu võidu" armatuurlaua, mis jälgis edukaid kasutuselevõtmisi, vähendatud intsidente ja säästetud aega.

Kuus kuud hiljem olid samad meeskonnad, kes olid DevOps'ile üleminekut õõnestanud, selle suurimad pooldajad. Peamine õppetund? Tehnilised rakendused ilma kultuurilise ühtlustamiseta on alati raskustes.

Turvalisuse integreerimise väljakutsed kiiresti arenevates torujuhtmetes

Turvalisus on endiselt üks kõige problemaatilisemaid valdkondi hallatud DevOps-rakendustes. Ma ei oska kokku lugeda, mitu korda olen näinud, kuidas organisatsioonid võtavad kasutusele kiireid tarneahelaid, et luua uusi turvaauke.

Üks jaemüügiklient, kellega ma eelmisel aastal koostööd tegin, suurendas oma kasutuselevõtu sagedust igakuiselt iganädalaselt, kasutades juhitud DevOps'i, kuid viis tahtmatult tootmisse kolm kriitilist turvaauku, sest nende turvaprotsessid ei suutnud kiirendatud arendustsükliga sammu pidada.

Praktiline DevSecOps integratsioon

Tuginedes mitmetele edukatele turvaintegratsioonidele, mida ma olen rakendanud, on siin, mis töötab:

• Turvalisuse nihutamine vasakule: Integreerige automaatne turvakontroll igas etapis, alustades IDE pluginatest, mis hoiatavad arendajaid probleemidest enne, kui nad koodi isegi kinnitavad.

• Automatiseerida nõuetele vastavuse kontrollimine: Rakendage reguleeritud tööstusharude puhul automaatne vastavuskontroll, mis kinnitab konfiguratsioonide vastavust nõutavatele standarditele enne kasutuselevõtu lubamist.

• Turvalisuse rakendamine koodina: Käsitlege turvakonfiguratsioone ja -põhimõtteid kui koodi, mis elab koos rakenduskoodiga, järgides samu läbivaatamis- ja testimisprotsesse.

• Luua turvalisuse eestvedajad: Määrake ja koolitage meeskonnaliikmeid, kes tegutsevad oma meeskonnas turvalisuse eestkõnelejatena, tuues turvateadlikkuse igapäevastesse arendustegevustesse.

Pärast nende tavade rakendamist suutis minu jaemüügiklient säilitada oma iganädalase kasutuselevõtu tsükli, parandades samal ajal tegelikult oma turvataset. Nende turvameeskond muutus turvalise ja kiire tarne võimaldajaks, mitte enam blokeerijaks.

Tehniline võlg: DevOps rakendamise teetõke

Peaaegu iga organisatsioon, kellega ma olen konsulteerinud, on alahinnanud, kuidas nende olemasolev tehniline võlg mõjutab nende DevOps-ümberkorraldust. Vanad süsteemid, manuaalsed protsessid ja kehv dokumentatsioon võivad märkimisväärselt aeglustada juhitud DevOps-i rakendamist.

Üks finantsteenuste ettevõte, kellega ma töötasin, võitles mitu kuud oma vanade suurarvutisüsteemide integreerimisega oma uutesse CI/CD-putkettidesse. Süsteemidel puudusid korralikud API-liidesed, nende automatiseeritud testimine oli minimaalne ja nad tuginesid mõne pensionile jääva vanema inseneri hõimuteadmistele.

Tehnilise võla strateegiline käsitlemine

Selle asemel, et võtta kõik-või-mitte-mitte midagi lähenemine, on siin strateegia, mida me rakendasime:

• Kaardistage oma kinnisvara: Kataloogige kõik rakendused ja infrastruktuurikomponendid, hinnates igaühe DevOps-valmidust lihtsa punase/kollase/rohelise süsteemi abil.

• Luua integratsioonipiirid: Loo puhtad liidesed ja API-kihid, mis võimaldavad uuematel süsteemidel nendega suhelda.

• Seadke strateegiliselt prioriteedid: Keskenduge esialgsetes DevOps-püüdlustes suure ärilise väärtusega ja vähem keerulistele süsteemidele, kus saate kiiresti edu näidata.

• Eraldage võlgade vähendamise aeg: Pühendage 20% sprindi mahust spetsiaalselt tehnilise võla vähendamisele, keskendudes kõige suurema mõjuga punktidele.

Seda lähenemisviisi kasutades viis finantsteenuseid pakkuv ettevõte 60% oma rakenduste portfellist ühe aasta jooksul edukalt kaasaegsete DevOps-tavade juurde, luues samal ajal jätkusuutliku plaani ülejäänud vanade süsteemide jaoks.

Tööriistade laialivalgumine ja integratsiooni keerukus

Teine levinud probleem, mida olen täheldanud, on DevOps-vahendite levik, mis ei tööta hästi koos. Ühel telekommunikatsiooni kliendil oli kogunenud 14 erinevat tööriista, mis hõlmasid nende CI/CD-putke, seiret, turvalisuse skaneerimist ja infrastruktuuri haldamist - enamik neist nõudis süsteemide vahelist manuaalset üleandmist.

DevOps Toolchaini taltsutamine

Tuginedes edukatele tööriistaketi konsolideerimistele, mida ma olen juhtinud, on siin, mis töötab:

• Seadke prioriteediks integratsioonivõimalused: Tööriistade valimisel eelistage neid, millel on töökindlad API-d ja valmis integratsioonid teie olemasoleva tööriistakomplektiga.

• Rakendada platvormipõhist lähenemist: Kaaluge DevOps-platvorme, mis pakuvad mitmeid võimalusi integreeritud paketina, selle asemel, et koostada parimatest parimad punktlahendused.

• Automatiseerida tööriistaketi testimine: Looge automatiseeritud testid oma DevOps-vahenditele, et tagada integratsioonide jätkuv toimimine, kui vahendeid uuendatakse.

• Dokumendi töövoogude läbilõikamine: Looge selge visuaalne dokumentatsioon, mis näitab, kuidas töö kulgeb läbi kogu töövahendite ahela, tuvastades käsitsi tehtavad üleandmised, mida saaks automatiseerida.

Pärast oma tööriistakomplekti konsolideerimist viie hästi integreeritud tööriistaga vähendas minu telekommunikatsiooniklient oma kasutuselevõtu aega 70% ja kõrvaldas arvukad vigadele kalduvad manuaalsed sammud süsteemide vahel.

Suurendamisprobleemid ettevõtluskeskkondades

DevOps-tavade skaleerimine kaugemale kui esialgsed pilootrühmad esitab unikaalseid väljakutseid, mida paljud organisatsioonid alahindavad. Üks tervishoiuettevõte, kellega ma töötasin, rakendas DevOps-tavasid edukalt ühes rakendusmeeskonnas, kuid nägi, kuidas nende mudel lagunes, kui nad üritasid seda laiendada rohkem kui 20 meeskonnale.

DevOps'i edukas skaleerimine

Siin on lähenemisviis, mis lõpuks toimis:

• Luua sisemine DevOps-platvormi meeskond: Luua spetsiaalne meeskond, mis keskendub korduvkasutatavate torujuhtmete, infrastruktuurimallide ja automatiseerimise loomisele, mida teised meeskonnad saavad kasutada.

• Rakendage innersource tavad: Julgustage meeskondi jagama automatiseerimiskoodi, konfiguratsioone ja parimaid tavasid sisemiste repositooriumide kaudu, millel on selged panustamise suunised.

• Standardiseerige targalt: Tehke kindlaks, millised DevOps-protsessi aspektid peaksid olema standardiseeritud kõikides meeskondades (turvanõuded, kasutuselevõtu kinnitamine) ja millised peaksid olema paindlikud (testimisraamistike valik, sisemised töövood).

• Luua praktikakogukond: Luua korrapärased foorumid, kus DevOps-töötajad saavad jagada edu, saadud õppetunde ja teha koostööd ühiste probleemide lahendamiseks.

Pärast nende tavade rakendamist laiendas tervishoiuorganisatsioon edukalt oma DevOps-tavasid kõigile 24 rakenduste meeskonnale 18 kuu jooksul, säilitades samal ajal järjepidevad kvaliteedi- ja turvastandardid.

Kulude juhtimine ja optimeerimine

Kuigi juhitud DevOps lubab sageli kulude kokkuhoidu, olen leidnud, et paljud organisatsioonid näevad tegelikult kulude kasvu algselt ilma nõuetekohase juhtimise ja optimeerimise tavadeta. Üks minu jaemüügiklient nägi, et nende pilvetaristu kulud kahekordistusid kolme kuu jooksul pärast DevOps'i rakendamist, kuna arendajad said võimaluse ise ressursse pakkuda.

Kulude kontrollimine ilma innovatsiooni piiramata

Siin on see, mis on minu klientidega toiminud:

• Rakendage märgistamist ja tagasiside: Nõuda kogu infrastruktuuri märgistamist meeskonna, rakenduse ja keskkonnaga, et jälgida kulusid ja teha meeskonnad teadlikuks oma kulutustest.

• Seadistage automatiseeritud kulude juhtimine: Looge automaatseid poliitikaid, mis tuvastavad ja hoiatavad kulude kõrvalekallete kohta või sunnivad tootmisväliseid ressursse väljaspool tööaega sulgema.

• Ehitage kulude optimeerimine torujuhtmesse: Integreerige infrastruktuurikulude analüüsi vahendid otse CI/CD-pilootidesse, et tuvastada ebaefektiivsed konfiguratsioonid enne kasutuselevõttu.

• Luua kulude eestvõitlejad: Sarnaselt turvalisuse eestvedajatele määrake meeskonnaliikmed, kes vastutavad oma meeskonnas kuluteadlikkuse ja -optimeerimise eest.

Pärast nende tavade rakendamist vähendas minu jaemüügiklient oma pilvekulutusi 40%, suurendades samal ajal oma kasutuselevõtu sagedust ja rakenduste jõudlust.

Kokkuvõte: Managed DevOps'i tööle panemine reaalsetes organisatsioonides

Tuginedes oma aastatele, mil olen aidanud organisatsioonidel rakendada ja optimeerida juhitud DevOps'i, olen leidnud, et edu nõuab võrdset tähelepanu tehnilistele, kultuurilistele ja protsessidega seotud väljakutsetele. Organisatsioonid, kes lähenevad juhitud DevOpsile kui puhtalt tehnilisele rakendamisele, on paratamatult hädas, samas kui need, kes tegelevad tehniliste komponentide kõrval ka inimlike ja organisatsiooniliste elementidega, saavutavad püsiva edu.

Kõige edukamad juhitud DevOps-rakendused, milles ma olen osalenud, on ühised omadused:

• DevOps'i eesmärkide ja ärieesmärkide selge kooskõlastamine

• Tegevjuhtide sponsorlus koos rohujuuretasandi entusiasmiga

• Realistlikud ajakavad, mis arvestavad organisatsiooni õppimiskõverat.

• Tasakaalustatud keskendumine inimestele, protsessidele ja tehnoloogiale

• Valmisolek tagasiside ja mõõdetud tulemuste põhjal kohaneda

Käesolevas juhendis kirjeldatud probleemide ennetamise ja ennetava käsitlemise abil saavad organisatsioonid märkimisväärselt suurendada oma võimalusi kasutada kõiki juhitud DevOpsist tulenevaid eeliseid: kiiremat tarnimist, paremat kvaliteeti, suuremat turvalisust ja lõppkokkuvõttes paremaid äritulemusi.