Tema DevOps dhe IaC është shumë popullore dhe po zhvillohet me shpejtësi. Megjithatë, shumica e autorëve prekin vetëm probleme teknike në këtë rrugë. Unë do të përshkruaj problemet që janë karakteristike për kompanitë e mëdha. Nuk kam zgjidhje — problemet në përgjithësi janë fatale dhe kanë të bëjnë me burokracinë, auditimin dhe "soft skills".
Meqenëse titulli i artikullit është të tillë, atëherë si "katicë" do të veprojë Daenerys, që ka kaluar në anën e Enterprise.
Pa dyshim, sot po ndodh një përplasje midis të vjetrës dhe të rejës. Dhe shpesh në këto kolizione nuk ka as të drejtë, as fajtorë. Kështu ka ndodhur. Por, për të mos qenë pa prova, do të fillojmë me këtë ekranin:
Ky është i ashtuquajturi Change Request. Ju shihni rreth një të tretën e fushave që duhet të plotësohen nga katalogët e ndryshëm, fushat e tjera janë në skedat e tjera. Ky dokument duhet të plotësohet për të aplikuar scriptin në production. server, ose për të ngarkuar dosje të reja dhe për të bërë ndonjë ndryshim.
Numri i fushave është i tillë, saqë unë shkrova një automatizim të vogël për të plotësuar këto fusha. Dhe kjo faqe është shkruar në mënyrë që asnjë mjet automatizimi nuk mund ta shohë fushën e saj, dhe një zgjidhje e vetme ishte të përdorja AutoIt për të klikuar me miun në koordinatat e duhura. Vlerësoni shkallën e dëshpërimit për të marrë një hap të tillë:
Pra, merrni Jenkins, Chef, Terraform, Nexus dhe të tjera, dhe me gëzim e shprendani të gjithë këtë në dev tuaj. Por vjen koha për ta dërguar atë në QA, UAT dhe PROD. Ju keni një artifact në Nexus dhe merrni një email nga DBA me një tekst të tillë:
I nderuar,
Së pari, nuk keni akses në Nexus-in tuaj
Së dyti, të gjitha ndryshimet duhet të jenë të dokumentuara si Kërkesë Ndryshimi.
SQL skenaret duhet t'i nxirrni nga Nexus-i dhe t'i bashkëngjitni Kërkesës për Ndryshim.
Nëse ndryshimi nuk është emergjent, duhet të bëhet brenda 7 ditëve nga lirimi (përjashtimisht gjatë fundjavës).
Kur Kërkesa juaj për Ndryshim miratohet nga një grup njerëzish, DBA do të ekzekutojë skenarin tuaj dhe madje do t'iu dërgojë një screenshot të rezultatit përmes emailit.Me respekt, DBA juaj që punon këtu që nga koha e mainframe.
A e dini se çfarë më kujton kjo? Një gjysmëautomatizim: roboti mban bazën, ndërsa punëtori e rrah atë me çekiç. Në të vërtetë, çfarë dobie ka ky Nexus, nëse gjithçka bëhet krejtësisht manualisht më pas?
Por nuk duhet ta fajësoni Enterprise për këtë! Ai, natyrisht, është i ashpër, por e gjithë kjo burokraci me Change Requests është e detyruar dhe vjen nga auditorët. Enterprise është i detyruar të punojë kështu, dhe pikë. Nuk mund të veprojë ndryshe. Dhe auditimi është një gjë shumë konservatore. Sa herë, për shembull, është folur për faktin se fjalëkalimet e gjata, pseudo-kompleks dhe shpesh të ndryshueshme janë të këqija, por ndërmarrjet do të ishin vendi i fundit ku do të ndryshonin këtë. Njësoj me vendosjet dhe të gjitha gjërat e tjera.
Sidoqoftë, në atë kohë përpiqesha të krijoja një skedar për terraform, por nuk arrita. U ngatërrova me kuptimin e etiketës ‘Project Accounting Billing Code’, të cilin nuk arrita ta zbuloja — më mungonin aftësitë sociale.
As nuk e hap temën e ludizmit pasiv — oh, automatizimi juaj kërcënon sigurinë time të punës, nuk dua të mësoj asgjë të re, prandaj do të sabotoj gjithçka në heshtje.
Cila mund të jetë zgjidhja në parim? Sistemi ITSM ka një API shumë primitiv për të gjeneruar automatikisht dokumente. Në fakt, shumica e këtyre sistemeve vijnë nga koha e mainframe-ve. A di ndokush për sisteme ITSM vërtet moderne? A ka ndokush përvojë të suksesshme në integrimin e DevOps moderne me burokracinë? Në fakt, nuk po flasim për faqe të pastër shitjesh, ku ka realisht mundësi për deploy çdo ditë, por, për shembull, për sektorin bankar, që është nën auditorë dhe ka një izolim shumë të fortë të mjeteve më të avancuara.
Mos harroni se të gjitha fantazitë tuaja kufizohen nga auditimi. Dhe kjo e ndryshon gjithçka. Po pres komentet tuaja!
Burimi: habr.com
