DevOps un IaC tēma ir ļoti populāra un strauji attīstās. Tomēr lielākā daļa autoru šajā ceļā risina tīri tehniskās problēmas. Aprakstīšu lielam uzņēmumam raksturīgās problēmas. Man nav risinājuma – problēmas kopumā ir liktenīgas un slēpjas birokrātijas, audita un “mīksto prasmju” jomā.
Tā kā raksta nosaukums ir šāds, Deenerijs, kurš ir pārgājis uz Enterprise pusi, darbosies kā kaķis.
Neapšaubāmi, tagad notiek vecā un jaunā sadursme. Un bieži vien šajās sadursmēs nav ne pareizā, ne nepareizā. Tā tas notika. Bet, lai nebūtu nepamatoti, mēs sāksim ar šo ekrānu:
Šis ir tā sauktais izmaiņu pieprasījums. Jūs redzat apmēram trešdaļu no laukiem, kas jāaizpilda no dažādiem direktorijiem, pārējie lauki atrodas citās grāmatzīmēs. Šāds dokuments ir jāaizpilda, lai lietotu skriptu ražošanas serverī vai augšupielādētu jaunus failus vai vispār kaut ko mainītu.
Lauku skaits ir tāds, ka es uzrakstīju savu mazo automatizāciju šo lauku aizpildīšanai. Turklāt šī lapa ir uzrakstīta tā, ka neviens automatizācijas rīks nevar redzēt tās laukus, un vienīgais iespējamais risinājums bija izmantot AutoIt, lai muļķīgi ar peli noklikšķinātu uz koordinātām. Novērtējiet savu izmisuma līmeni, lai to izdarītu:
Tātad, jūs ņemat jenkins, šefpavāru, terraform, nexus utt. un laimīgi izvietojat to visu savā izstrādātājā. Bet ir pienācis laiks to nosūtīt QA, UAT un PROD. Jums ir Nexus artefakts, un jūs saņemat vēstuli no DBA ar kaut ko līdzīgu šim:
Dārgs,
Pirmkārt, jūsu nexus, ko varat iegūt sev. Man nav piekļuves jūsu Nexus
Otrkārt, visas izmaiņas ir jāizsniedz kā izmaiņu pieprasījums.
Jums ir jāizvelk SQL skripti no Nexus un jāpievieno tie izmaiņu pieprasījumam.
Ja izmaiņas nav ārkārtas, tas jādara 7 dienas pirms izlaišanas (tikai nedēļas nogalē).
Kad jūsu izmaiņu pieprasījumu apstiprinās daudzi cilvēki, DBA izpildīs jūsu skriptu un pat nosūtīs rezultāta ekrānuzņēmumu pa pastu.Ar cieņu jūsu DBA, kas šeit strādā kopš lieldatoru laikiem.
Vai jūs zināt, ko tas man atgādina? Pusautomātika: robots notur rāmi, un strādnieks sit ar āmuru. Nu tiešām, kāda jēga šim Nexusam, ja tad viss tiek darīts pilnīgi manuāli?
Bet uzņēmumu par to nevajadzētu vainot! Tas, protams, ir asiņaini, bet visa šī birokrātija ar Izmaiņu pieprasījumiem ir uzspiesta un nāk no auditoriem. Uzņēmumam ir jāstrādā šādā veidā, punkts. Citādi viņš to nevar izdarīt. Un audits ir ļoti konservatīva lieta. Piemēram, cik daudz runāts par to, ka garas pseido-sarežģītas un bieži mainītas paroles ir sliktas, bet uzņēmumi būs pēdējā vieta, kur tas tiks mainīts. Arī ar izvietošanu un visu pārējo.
Starp citu, savulaik mēģināju izveidot failu terraformai, taču tas nedarbojās. Es nejauši uzgāju birkas “Projekta grāmatvedības norēķinu kods” nozīmi, ko man tā arī neizdevās noskaidrot – man nebija pietiekami daudz mīksto prasmju.
Es pat nepievēršos pasīvā ludisma tēmai - ak, jūsu automatizācija apdraud manu darba drošību, es nevēlos mācīties neko jaunu, tāpēc es to klusībā sabotēšu.
Nu, kāds principā varētu būt risinājums? ITSM sistēmai ir ārkārtīgi primitīva API dokumentu automātiskai ģenerēšanai. Un vispār lielākā daļa šo sistēmu nāk no lieldatoru laikiem. Vai kāds zina kādas patiesi modernas ITSM sistēmas? Vai kādam ir veiksmīga pieredze mūsdienu DevOps un birokrātijas integrēšanā? Mēs, protams, nerunājam par tīri tirdzniecības vietām, kur faktiski var būt izvietošana katru dienu, bet, piemēram, banku sektoru, kas atrodas revidentu pakļautībā un ļoti stiprā izolācijā augstākās vidēs.
Vienkārši neaizmirstiet, ka visas jūsu fantāzijas ierobežo audits. Un tas visu maina. Gaidu tevi komentāros!
Avots: www.habr.com