Tema DevOps in IaC je zelo priljubljena in hitro raste. Vendar se večina avtorjev spotoma ukvarja s čisto tehničnimi težavami. Opisal bom težave, značilne za veliko podjetje. Nimam rešitve - težave so nasploh usodne in ležijo na področju birokracije, revizije in »mehkih veščin«.
Ker je naslov članka tak, bo Daenerys delovala kot mačka, ki je prešla na stran Enterprisea.
Nedvomno se zdaj dogaja spopad starega in novega. In pogosto v teh kolizijah ni ne prav ne narobe. Tako se je zgodilo. Da pa ne bomo neutemeljeni, bomo začeli s tem zaslonom:
To je tako imenovana zahteva za spremembo. Vidite približno tretjino polj, ki jih je treba izpolniti iz različnih imenikov, ostala polja so v drugih zavihkih. Takšen dokument je treba izpolniti, da lahko skript uporabimo na produkcijskem strežniku ali naložimo nove datoteke in na splošno nekaj spremenimo.
Število polj je takšno, da sem napisal svojo malo avtomatiko za izpolnjevanje teh polj. Poleg tega je ta stran napisana tako, da nobeno orodje za avtomatizacijo ne vidi njenih polj, in edina možna rešitev je bila uporaba AutoIt-a za neumno udarjanje koordinat z miško. Ocenite stopnjo obupa, da se odločite za to:
Torej, vzamete jenkins, chef, terraform, nexus in tako naprej in vse to veselo namestite na svoj razvijalec. Toda čas je, da ga pošljete QA, UAT in PROD. Imate artefakt Nexus in od DBA prejmete pismo z nekaj takega:
Dragi,
Prvič, vaš nexus, lahko si predstavljate, da nimam dostopa do vašega nexusa
Drugič, vse spremembe je treba vložiti kot zahtevo za spremembo.
Skripte SQL morate izolirati iz Nexusa in jih priložiti zahtevi za spremembo.
Če sprememba ni nujna, jo je treba izvesti v 7 dneh po objavi (izključno ob koncu tedna)
Ko vašo zahtevo za spremembo odobri kup ljudi, bo DBA izvedel vaš skript in celo poslal posnetek zaslona rezultata po pošti.S spoštovanjem, vaš DBA, ki dela tukaj že od glavnega računalnika.
Veš na kaj me to spominja? Polavtomatizacija: robot drži okvir, delavec pa ga udarja s kladivom. No, res, kaj pomaga ta Nexus, če se potem vse dela popolnoma ročno?
Ampak ne krivite Enterprise za to! Seveda je krvavo, a vsa ta birokracija z zahtevami za spremembe je izsiljena in prihaja od revizorjev. Podjetje mora delovati tako, pika. Ne more drugače. In revizija je zelo konzervativna stvar. Koliko je bilo na primer povedanega o tem, da so dolga psevdokompleksna in pogosto spremenjena gesla slaba, vendar bodo podjetja zadnja, ki bodo to spremenila. Tudi z uvajanji in vsem ostalim.
Mimogrede, nekoč sem poskušal ustvariti datoteko za terraform, vendar mi ni uspelo. Po naključju sem naletel na pomen oznake 'Project Accounting Billing Code', ki ga nikoli nisem uspel ugotoviti - nisem imel dovolj mehkih veščin.
Sploh ne jemljem teme pasivnega ludizma - oh, vaša avtomatizacija ogroža mojo varnost službe, nočem se naučiti ničesar novega, zato bom tiho sabotiral.
Torej, kaj bi lahko bila rešitev? Sistem ITSM ima izjemno primitiven API za samodejno ustvarjanje dokumentov. In na splošno večina teh sistemov izvira iz časov velikih računalnikov. Mogoče kdo pozna res sodobne ITSM sisteme? Ima morda kdo uspešno izkušnjo z integracijo modernih DevOps in birokracije? Tu seveda ne gre za čisto koruptivna mesta, kjer se lahko res vsak dan namesti, ampak na primer za bančni sektor, ki je pod nadzorom in zelo močno izolacijo višjih okolij.
Samo ne pozabite, da so vse vaše fantazije omejene na revizijo. In to spremeni vse. Čakam vas v komentarjih!
Vir: www.habr.com