Tema e DevOps dhe IaC është shumë e njohur dhe po zhvillohet me shpejtësi. Megjithatë, shumica e autorëve merren me probleme thjesht teknike përgjatë kësaj rruge. Unë do të përshkruaj problemet karakteristike të një kompanie të madhe. Unë nuk kam një zgjidhje - problemet, në përgjithësi, janë fatale dhe qëndrojnë në fushën e burokracisë, auditimit dhe "aftësive të buta".
Meqenëse titulli i artikullit është i tillë, Daenerys, e cila ka kaluar në anën e Enterprise, do të veprojë si macja.
Padyshim, tani ka një përplasje të vjetër dhe të re. Dhe shpesh në këto përplasje nuk ka as të drejtë e as të gabuar. Thjesht ndodhi kështu. Por, për të mos qenë të pabazë, do të fillojmë me këtë ekran:
Kjo është e ashtuquajtura Kërkesë Ndryshimi. Ju shihni rreth një të tretën e fushave që duhet të plotësohen nga drejtori të ndryshme, fushat e mbetura janë në faqeshënues të tjerë. Një dokument i tillë duhet të plotësohet për të aplikuar skriptin në serverin e prodhimit, për të ngarkuar skedarë të rinj ose në përgjithësi për të ndryshuar ndonjë gjë.
Numri i fushave është i tillë që kam shkruar automatizimin tim të vogël për plotësimin e këtyre fushave. Për më tepër, kjo faqe është shkruar në atë mënyrë që asnjë mjet automatizimi nuk mund të shohë fushat e saj, dhe zgjidhja e vetme e mundshme ishte përdorimi i AutoIt për të klikuar marrëzi mbi koordinatat me miun. Vlerësoni nivelin tuaj të dëshpërimit për ta bërë këtë:
Pra, ju merrni jenkins, kuzhinier, terraform, nexus, etj., dhe me kënaqësi i shpërndani të gjitha te zhvilluesi juaj. Por vjen koha për ta dërguar në QA, UAT dhe PROD. Ju keni një objekt Nexus dhe merrni një letër nga DBA me diçka si kjo:
I dashur,
Para së gjithash, lidhjen tuaj që mund ta keni për veten tuaj, unë nuk kam akses në Nexus-in tuaj
Së dyti, të gjitha ndryshimet duhet të lëshohen si një kërkesë ndryshimi.
Ju duhet të nxirrni skriptet SQL nga Nexus dhe t'i bashkëngjitni ato në Kërkesën e Ndryshimit.
Nëse ndryshimi nuk është urgjent, kjo duhet të bëhet 7 ditë përpara lëshimit (ekskluzivisht në fundjavë)
Kur kërkesa juaj për ndryshim miratohet nga një grup njerëzish, DBA do të ekzekutojë skriptin tuaj dhe madje do të dërgojë një pamje të rezultatit me postë.Përshëndetje, DBA juaj që ka punuar këtu që nga ditët e mainframe.
E dini se çfarë më kujton kjo? Gjysmë-automatizimi: roboti mban kornizën dhe punëtori e godet atë me një vare. Epo, me të vërtetë, çfarë kuptimi ka ky Nexus nëse atëherë gjithçka bëhet plotësisht me dorë?
Por Enterprise nuk duhet fajësuar për këtë! Sigurisht që është e përgjakshme, por gjithë kjo burokraci me Kërkesa Ndryshimi është e detyruar dhe vjen nga auditorët. Ndërmarrja duhet të punojë në këtë mënyrë, pikë. Ai nuk mund ta bëjë ndryshe. Dhe auditimi është një gjë shumë konservatore. Për shembull, sa është folur për faktin se fjalëkalimet e gjata pseudo-komplekse dhe të ndryshuara shpesh janë të këqija, por ndërmarrjet do të jenë vendi i fundit ku kjo do të ndryshohet. Gjithashtu me vendosje dhe gjithçka tjetër.
Nga rruga, në një kohë u përpoqa të krijoj një skedar për terraform, por nuk funksionoi. Kam ngecur në kuptimin e etiketës "Kodi i Faturimit të Kontabilitetit të Projektit", të cilin nuk arrita ta zbuloja kurrë - nuk kisha mjaftueshëm aftësi të buta.
Unë as nuk po merrem me temën e Ludizmit pasiv - oh, automatizimi juaj kërcënon sigurinë time të punës, nuk dua të mësoj asgjë të re, kështu që do ta sabotoj në heshtje.
Epo, cila mund të jetë zgjidhja në parim? Sistemi ITSM ka një API jashtëzakonisht primitive për gjenerimin automatik të dokumenteve. Dhe në përgjithësi, shumica e këtyre sistemeve vijnë nga koha e mainframe-ve. A njeh dikush ndonjë sistem vërtet modern ITSM? A ka dikush përvojë të suksesshme në integrimin e DevOps moderne dhe burokracinë? Natyrisht, nuk po flasim për faqe thjesht shitjeje, ku realisht mund të ketë një dislokim çdo ditë, por, për shembull, për sektorin bankar, i cili është nën auditorë dhe izolim shumë i fortë në mjedise më të larta.
Vetëm mos harroni se të gjitha fantazitë tuaja janë të kufizuara nga auditimi. Dhe kjo ndryshon gjithçka. Ju pres në komente!
Burimi: www.habr.com