Jää (verine Enterprise) ja leek (DevOps ja IaC) laul

DevOps ja IaC teema on väga populaarne ja areneb kiiresti. Kuid enamik autoritest käsitleb teel tekkivaid puhtalt tehnilisi probleeme. Mina aga kirjeldan probleemide iseloomu suures ettevõttes. Mul ei ole lahendust — probleemid on pigem fataalsed ja kuuluvad bürokraatia, auditi ja pehmete oskuste valdkonda.

Kuna artikli pealkiri on selline, esindab meie kass Danyeris, kes on läinud Enterprise poole.

Kahtlemata toimub praegu vana ja uue kokkupõrge. Ja sageli pole nendes konfliktides õigesti ega valesti. Nii see lihtsalt on. Kuid et mitte jääda sõnasepieriks, alustame sellest ekraanist:

See on nii-öelda Change Request. Näete umbes kolmandikku väljadest, mis tuleb täita erinevatest registritest, ülejäänud väljad on teistes sakkides. Selline dokument tuleb täita, et rakendada skripti tootmisprotsessis. serveri, või laadida uusi faile ja üldiselt midagi muuta.

Väljade arv on nii suur, et ma kirjutasin oma väikese automatiseerimise nende täitmiseks. Ja see leht on kirjutatud nii, et ükski automatiseerimisinstrument ei suuda näha selle välju, ning ainus võimalik lahendus oli kasutada AutoIt, et lihtsalt hiirega koordinaatide järgi klõpsata. Hindake oma meeleheite ulatust, et selliseks sammuks otsustuda:

Nii et võtate jenkins, chef, terraform, nexus ja muud ning rõõmsalt juurutate kõik oma arendusressursis. Aga tuleb aeg saata see QA, UAT ja PROD. Nexus artefakt on olemas ja saate DBA-lt kirja, milles on umbes selline tekst:

Lugupeetud,

Esiteks, teie nexus on mul puudub juurdepääs teie Nexus'esse.
Teiseks, kõik muudatused peavad olema vormistatud kui Change Request.
SQL skriptid peate võtma Nexus'est ja lisama Change Request'ile.
Kui muudatus ei ole hädaolukord, siis tuleb see teha 7 päeva jooksul alates väljaandmisest (ainult nädalavahetusel).
Kui teie Change Requesti kinnitab suur hulk inimesi, siis DBA täidab teie skripti ja saadab isegi e-postiga ekraanipildi tulemuse.

Lugupidamisega, teie DBA, kes on siin töötanud alates peamiste süsteemide ajast.

Kas teate, millele see mind metsikult meenutab? Poolautomaatset tööd: robot hoiab alust, samas kui töötaja lööb sellele haamriga. Tõepoolest, mis mõte on üldse selles Nexus'es, kui kõik tehakse seejärel täielikult käsitsi?

Kuid ärge süüdistage sellega Enterprise'i! See on kindlasti verine, kuid kogu see bürokraatia muudatuste taotluste osas on sunnitud ja tuleneb audiitoritest. Enterprise peab nii toimima, ja punkt. Nii ei saa ta muudmoodi. Ja audit on äärmiselt konservatiivne asi. Kui palju on näiteks räägitud, et pikad pseudo keerulised ja sageli muudetavad paroolid on halvad, aga ettevõtted on viimased, kes seda muudavad. Samuti kehtib see ülesdeplovanie ja kõigi muude asjade kohta.

Muide, kunagi proovisin ma luua terraformi faili, kuid mul ei õnnestunud. Komistasin sildi 'Projektihalduse arvelduskood' tähenduse peale, mida ma ei suutnud teada saada - mul puudusid soft skills.

Ma ei räägi isegi passiivsest luddismist - oi, teie automatiseerimine ohustab minu töökindlust, ma ei taha õppida midagi uut, seega hakkan ma vaikselt sabotaažima.

Noh, mis võiks üldse olla lahendus? ITSM süsteemil on äärmiselt primitiivne API dokumentide automaatseks genereerimiseks. Ja tegelikult, enamik selliseid süsteeme pärineb peamise raamatu ajast. Kas keegi teab tõeliselt kaasaegseid ITSM süsteeme? Kas keegi on edukalt integreerinud kaasaegset DevOps'i ja bürokraatiat? Rääkime muidugi mitte puhtalt müügisaitidest, kus tegelikult võib iga päev olla väljastamine, vaid näiteks pangandussektorist, mis on auditi all ja väga tugeva isolatsiooniga kõrgemates keskkondades.

Aga ärge unustage, et kõik teie fantaasiad on piiritletud auditi olemasoluga. Ja see muudab kogu asja. Ootan teid kommentaarides!

Allikas: habr.com