Tema e DevOps dhe IaC është shumëpopullore dhe po zhvillohet shpejt. Megjithatë, shumica e autorëve prekin vetëm probleme teknike në këtë rrugë. Unë do të përshkruaj problemet që karakterizojnë një kompani të madhe. Nuk kam zgjidhje — problemet, përgjithësisht, janë fatale dhe qëndrojnë në fushën e burokracisë, auditimit dhe "soft skills".
Nëse titulli i artikullit është i tillë, atëherë si maçok do të shfaqet Daenerys, e kaluara në anën e Enterprise
Së bashku, aktualisht po ndodh një përplasje e së vjetrës dhe të re. Dhe shpesh në këto kolizione nuk ka të drejtë dhe të gabuar. Keshtu ndodhi. Por, për të mos qënë pa argumente, ne do të fillojmë nga ky ekran:
Ky është i ashtuquajturi Kërkesë për Ndryshim. Ju shihni rreth një të tretën e fushave që duhet të plotësohen nga një gamë e ndryshme burimesh, fushat e tjera janë në faqe të tjera. Një dokument i tillë duhet të plotësohet për të aplikuar skriptin në prodhim serverit, ose për të ngarkuar skedarë të rinj dhe përgjithësisht, për të bërë çfarëdo ndryshimi.
Numri i fushave është i tillë, sa që unë shkrova një automatizim të vogël për plotësimin e këtyre fushave. Për më tepër, kjo faqe është shkruar në mënyrë që asnjë mjet automatizimi nuk e shikon fushat e saj, dhe zgjidhja e vetme e mundshme ishte të përdorje AutoIt, për të goditur thjesht me maus në koordinatat. Vlerësoni shkallën e dëshpërimit për të u vendosur në diçka të tillë:
Pra, ju merrni jenkins, chef, terraform, nexus dhe të tjera, dhe me gëzim e deployoni të gjitha këto në dev tuaj. Por vjen koha për ta dërguar këtë në QA, UAT dhe PROD. Artifiakti Nexus që e keni dhe merrni një email nga DBA me tekstin e tillë:
I nderuar,
Së pari, nexus tuaj, ju nuk keni qasje në Nexus tuaj
Së dyti, të gjitha ndryshimet duhet të jenë të formalizuara si Kërkesë për Ndryshim.
Skripted SQL ju duhet t’i nxirrni nga Nexus, dhe t'i bashkëngjitni Kërkesës për Ndryshim.
Nëse ndryshimi nuk është emergjent, duhet të bëni këtë brenda 7 ditëve të lançimit (përjashtimisht në fundjavë)
Kur Kërkesa juaj për Ndryshim miratohet nga një mori njerëzish, DBA do të ekzekutojë skriptin tuaj dhe madje do të dërgojë një screenshot të rezultatit përmes emailit.Me respekt, DBA juaj që punon këtu që nga kohët e mainframe.
E dini se çfarë më kujton kjo? Automatizimi i pjesshëm: roboti mban stafin, ndërsa punëtori godet atë me çekiç. Me të vërtetë, çfarë dobi ka ky Nexus, nëse pastaj gjithçka bëhet krejtësisht manualisht?
Por shëndet, nuk duhet ta fajësojmë Enterprise për këtë! Ai, sigurisht, është i egër, por e gjithë kjo burokraci me Kërkesat për Ndryshime është e detyruar dhe buron nga auditorët. Enterprise është i detyruar të funksionojë kështu, dhe pikë. nuk mund të bëjë ndryshe. Dhe auditi është një gjë shumë konservatore. Sa herë, për shembull, është folur për faktin se fjalëkalimet e gjata, pseudo-të komplikuara dhe shpesh të ndryshueshme janë të këqija, por ndërmarrjet do të mbeten vendi i fundit ku kjo do të ndryshojë. Po ashtu me deployt dhe gjithçka tjetër.
Sidoqoftë, njëherë unë përpiqesha të krijoja një skedar për terraform, por nuk arrita. U pengova në kuptimin e tagut 'Kod i Mbikëqyrjes së Projektit të Shpenzimeve', i cili nuk arrita kurrë ta zbuloj - më mungonin aftësitë e buta.
Nuk po flas as për temën e luddizmit pasiv - oh, automatizimi juaj kërcënon sigurinë time të punës, nuk dua të mësoj asgjë të re, prandaj do të sabotoj qetësisht.
Cila mund të jetë në parim zgjidhja? Sistemi ITSM ka një API tejet primitive për të gjeneruar dokumente automatikisht. Dhe në përgjithësi, shumica e këtyre sistemeve vijnë nga koha e mainframe-ve. A ka ndokush që di për sisteme ITSM vërtet moderne? A ka ndokush me përvojë të suksesshme në integrimin e DevOps moderne dhe burokracisë? Sigurisht, nuk po flas për faqet e shsales që mund të kenë vërtet një deploy çdo ditë, por, për shembull, sektorin bankar, që është nën auditorë dhe shumë i izoluar nga ambientet më të larta.
Vetëm mos haroni se të gjitha fantazitë tuaja janë të kufizuara nga auditimi. Dhe kjo gjithçka ndihmon në ndryshim. Po pres ju në komentet!
Burimi: habr.com
