DevOpsi ja IaC teema on väga populaarne ja areneb kiiresti. Enamik autoreid tegeleb sellel teel siiski puhttehniliste probleemidega. Kirjeldan suurettevõttele iseloomulikke probleeme. Mul pole lahendust – probleemid on üldiselt saatuslikud ja jäävad bürokraatia, auditeerimise ja “pehmete oskuste” valdkonda.
Kuna artikli pealkiri on selline, tegutseb kassina Enterprise'i poolele üle läinud Daenerys.
Kahtlemata on nüüd vana ja uue kokkupõrge. Ja sageli pole neis kokkupõrgetes õiget ega valet. Nii see juhtuski. Kuid selleks, et mitte olla alusetu, alustame järgmisest ekraanist:
See on nn muudatustaotlus. Erinevatest kataloogidest näete umbes kolmandikku täitmist vajavatest väljadest, ülejäänud väljad on muudes järjehoidjates. Selline dokument tuleb täita, et skripti tootmisserverisse rakendada või uusi faile üles laadida või üldiselt midagi muuta.
Väljade arv on selline, et kirjutasin nende väljade täitmiseks oma väikese automaatika. Pealegi on see leht kirjutatud nii, et ükski automaatikatööriist selle välju ei näe ja ainuvõimalik lahendus oli kasutada AutoIt-i abil rumalalt hiirega koordinaatidel klõpsata. Hinnake oma meeleheidet, et seda teha:
Niisiis, võtate jenkinid, peakoka, terraformi, nexuse jne ja juurutage need kõik rõõmsalt oma arendajasse. Kuid on aeg saata see QA-le, UAT-le ja PROD-ile. Teil on Nexuse artefakt ja saate DBA-lt järgmise kirja:
Kallis
Esiteks, teie nexus, mille saate endale hankida. Mul pole teie Nexusele juurdepääsu
Teiseks tuleb kõik muudatused väljastada muudatustaotlusena.
Peate Nexusest eraldama SQL-skriptid ja lisama need muudatustaotlusele.
Kui muudatus ei ole hädaolukord, tuleks seda teha 7 päeva enne avaldamist (ainult nädalavahetusel)
Kui teie muudatustaotlus on paljude inimeste poolt heaks kiidetud, käivitab DBA teie skripti ja saadab tulemusest isegi ekraanipildi posti teel.Parimate soovidega teie DBA, kes on siin töötanud suurarvuti ajast saadik.
Kas sa tead, mida see mulle meenutab? Poolautomaatika: robot hoiab raami ja töötaja lööb selle haamriga. No tõesti, mis selle Nexuse mõte on, kui siis kõike täiesti käsitsi tehakse?
Kuid ettevõtet ei tohiks selles süüdistada! See on muidugi verine, aga kogu see muudatustaotlustega bürokraatia on pealesunnitud ja tuleb audiitoritelt. Ettevõte peab nii töötama, punkt. Ta ei saa seda teistmoodi teha. Ja auditeerimine on väga konservatiivne asi. Näiteks kui palju on räägitud sellest, et pikad pseudokeerulised ja sageli vahetatavad paroolid on halvad, aga ettevõtted on viimane koht, kus seda muudetakse. Samuti juurutuste ja kõige muuga.
Muide, proovisin omal ajal terraformi jaoks faili luua, kuid see ei õnnestunud. Ma komistasin märgendi 'Projektiarvestuse arvelduskood' tähenduse otsa, mida mul ei õnnestunudki välja selgitada – mul ei olnud piisavalt pehmeid oskusi.
Ma ei võta isegi passiivse ludismi teemat - oh, teie automatiseerimine ohustab mu töökindlust, ma ei taha midagi uut õppida, nii et ma hakkan seda vaikselt saboteerima.
No mis võiks olla põhimõtteliselt lahendus? ITSM-süsteemil on dokumentide automaatseks genereerimiseks äärmiselt primitiivne API. Ja üldiselt on enamik neist süsteemidest pärit suurarvutite ajast. Kas keegi teab mõnda tõeliselt kaasaegset ITSM-süsteemi? Kas kellelgi on edukaid kogemusi kaasaegse DevOpsi ja bürokraatia integreerimisel? Me ei räägi muidugi puhtalt müügisaitidest, kus võib tegelikult iga päev käiku minna, vaid näiteks pangandussektorist, mis on audiitorite all ja kõrgemates keskkondades väga tugevas isolatsioonis.
Lihtsalt ärge unustage, et audit piirab kõiki teie fantaasiaid. Ja see muudab kõike. Ootan teid kommentaaridesse!
Allikas: www.habr.com