A Song of Ice (Bloody Enterprise) and Fire (DevOps en IaC)

It ûnderwerp fan DevOps en IaC is heul populêr en groeit rap. De measte auteurs dogge lykwols ûnderweis suver technyske problemen. Ik sil beskriuwe de problemen spesifyk foar in grut bedriuw. Ik haw gjin oplossing - problemen, yn 't algemien, binne fataal en lizze op it mêd fan burokrasy, kontrôle en "sêfte feardigens".

A Song of Ice (Bloody Enterprise) and Fire (DevOps en IaC)
Sûnt de titel fan it artikel is sa, dan sil Daenerys fungearje as in kat, nei't er oergien is oan 'e kant fan Enterprise

Sûnder mis, no is der in botsing fan âld en nij. En faaks is yn dizze botsingen noch goed noch ferkeard. It barde krekt sa. Mar, om net ûnbegrûn te wêzen, sille wy begjinne mei dit skerm:

A Song of Ice (Bloody Enterprise) and Fire (DevOps en IaC)

Dit is it saneamde Change Request. Jo sjogge sawat in tredde fan 'e fjilden dy't moatte wurde ynfolle út ferskate mappen, de rest fan' e fjilden binne yn oare ljeppers. Sa'n dokumint moat ynfolle wurde om it skript oan te passen op de produksjetsjinner, of nije bestannen op te laden en yn 't algemien wat te feroarjen.

It oantal fjilden is sa dat ik myn lytse automatisearring skreau foar it ynfoljen fan dizze fjilden. Boppedat is dizze side skreaun op sa'n manier dat gjin automatisearringsynstruminten har fjilden sjogge, en de ienige mooglike oplossing wie om AutoIt te brûken om dom de koördinaten mei de mûs te slaan. Beoardielje de mjitte fan wanhoop om hjiroer te besluten:

A Song of Ice (Bloody Enterprise) and Fire (DevOps en IaC)

Dat, jo nimme jenkins, chef, terraform, nexus ensafuorthinne, en sette dit alles mei wille yn op jo dev. Mar it is tiid om it te stjoeren nei QA, UAT en PROD. Jo hawwe in Nexus-artefakt en jo ûntfange in brief fan DBA mei sa'n ding:

Beste,

Earst, jo nexus kinne jo jo yntinke dat ik gjin tagong ha ta jo nexus
Twads moatte alle wizigingen wurde yntsjinne as in wizigingsfersyk.
Jo moatte de SQL-skripts isolearje fan Nexus en heakje se oan it Feroaringsfersyk.
As de feroaring gjin Emergency is, moat it dien wurde binnen 7 dagen nei de frijlitting (eksklusyf op wykein)
As jo ​​wizigingsfersyk goedkard is troch in bosk minsken, sil de DBA jo skript útfiere en sels in skermôfbylding fan it resultaat per post stjoere.

Mei freonlike groetnis, jo DBA, dy't hjir sûnt mainframe wurket.

Witte jo wêr't dit my oan tinkt? Semi-automatisearring: de robot hâldt it frame, en de arbeider slacht it mei in foarhamer. No, echt, wat is it nut fan dizze Nexus, as dan alles folslein mei de hân wurdt dien?

Mar jou Enterprise net de skuld foar dit! It is fansels bloedich, mar al dizze burokrasy mei Change Requests wurdt twongen en komt fan de auditors. Enterprise moat sa wurkje, punt. Hy kin it net oars. En audit is in heul konservatyf ding. Hoefolle is der bygelyks sein oer it feit dat lange pseudo-komplekse en faak feroare wachtwurden min binne, mar bedriuwen sille it lêste plak wêze om dit te feroarjen. Ek mei ynset en al it oare.

Trouwens, op ien kear besocht ik in bestân te meitsjen foar terraform, mar dat is net slagge. Ik stroffele oer de betsjutting fan 'e tag 'Project Accounting Billing Code', dy't ik noait slagge om út te finen - ik hie net genôch sêfte feardigens.

Ik nim it ûnderwerp fan passive luddisme net iens - o, jo automatisearring bedriget myn wurkfeiligens, ik wol neat nijs leare, dus ik sil rêstich sabotearje.

Dus, wat kin de oplossing wêze? It ITSM-systeem hat in ekstreem primitive API om dokuminten automatysk te generearjen. En yn 't algemien komme de measte fan dizze systemen út' e dagen fan mainframes. Miskien immen wit echt moderne ITSM systemen? Miskien hat immen in suksesfolle ûnderfining fan it yntegrearjen fan moderne DevOps en burokrasy? Dit is fansels net oer suver korrupte siden, dêr't it echt alle dagen ynset wurde kin, mar bygelyks de banksektor, dy't ûnder auditors en tige sterke isolaasje fan hegere omjouwings stiet.

Ferjit gewoan net dat al jo fantasyen beheind binne ta auditing. En dat feroaret alles. Wachtsje op jo yn 'e kommentaren!

Boarne: www.habr.com

Add a comment