Tema DevOps și IaC este foarte populară și se dezvoltă rapid. Cu toate acestea, majoritatea autorilor abordează exclusiv problemele tehnice pe acest drum. Eu voi descrie problemele caracteristice unei mari companii. Nu am soluții — problemele, în general, sunt fatale și țin de birocratie, audit și «soft skills».
Așadar, având în vedere titlul articolului, pisica va fi Daenerys, care s-a alăturat Enterprise.
Fără îndoială, acum are loc o ciocnire între vechi și nou. Și adesea în aceste coliziuni nu există nici buni, nici vinovați. Așa s-a întâmplat. Dar, pentru a nu fi vague, vom începe cu acest ecran:
Acesta este așa-numitul Change Request. Veți vedea aproximativ un sfert din câmpurile care trebuie completate din diverse directoare, restul câmpurilor se află în alte tab-uri. Acest document trebuie completat pentru a aplica un script în producție. server, sau pentru a încărca fișiere noi și, în general, pentru a modifica ceva.
Numărul câmpurilor este atât de mare încât am scris o mică automatizare pentru completarea acestora. În plus, această pagină este concepută astfel încât niciun instrument de automatizare să nu vadă câmpurile ei, iar singura soluție posibilă a fost să folosesc AutoIt pentru a da click cu mouse-ul pe coordonate. Evaluați nivelul disperării necesar pentru a recurge la asta:
Așadar, luați jenkins, chef, terraform, nexus și altele și le implementați cu bucurie pe dev. Dar vine momentul să le trimiteți pe QA, UAT și PROD. Artefactul Nexus îl aveți și primiți un email de la DBA cu un text similar cu acesta:
Stimate,
În primul rând, nu aveți acces la Nexus meu.
În al doilea rând, toate modificările trebuie să fie formate ca un Change Request.
Trebuie să extrageți scripturile SQL din Nexus și să le atașați la Change Request.
Dacă modificarea nu este de urgență, aceasta trebuie realizată în termen de 7 zile de la lansare (exclusiv în weekend).
Când Change Request-ul dv. este aprobat de o mulțime de oameni, atunci DBA va executa scriptul dvs. și va trimite chiar și un screenshot al rezultatului prin email.Cu respect, DBA-ul dvs. care lucrează aici din vremea mainframe-urilor.
Știți ce îmi amintește asta? Semi-automatizare: robotul ține un suport, iar muncitorul îl lovește cu ciocanul. Chiar, care este sensul acestui Nexus dacă apoi totul se face complet manual?
Dar nu trebuie să dăm vina pe Enterprise pentru asta! Este adevărat că este brutal, dar toată această birocrație cu cererile de schimbare este inevitabilă și provine de la auditori. Enterprise trebuie să funcționeze astfel, fără discuție. Nu poate opera altfel. Auditul este, în esență, un proces conservator. Cât de des s-a vorbit despre faptul că parolele lungi, complicate și adesea schimbate sunt nefavorabile, dar va fi ultimul loc unde acestea se vor schimba în cadrul enterprise-urilor. Aceleași lucruri se aplică și în privința desfășurărilor și a tuturor aspectelor conexe.
Apropo, la vremea respectivă am încercat să creez un fișier pentru terraform, dar nu am reușit. M-am împotmolit în înțelesul etichetei 'Cod de facturare pentru contabilitatea proiectului', pe care nu am reușit să-l aflu - mi-au lipsit abilitățile soft.
Nu mă refer nici măcar la tema ludismului pasiv - oh, automatizarea dumneavoastră amenință securitatea locului meu de muncă, nu vreau să învăț nimic nou, așa că voi sabotaj discret.
Care ar putea fi, în principiu, soluția? Sistemul ITSM are o API extrem de primitivă pentru a genera documente automat. În general, majoritatea acestor sisteme provin din vremurile mainframe-urilor. Poate cineva știe cu adevărat sisteme ITSM moderne? Poate cineva are experiență de succes în integrarea DevOps moderne cu birocrația? Desigur, nu mă refer la site-urile doar de vânzări, unde desfășurarea poate avea loc chiar în fiecare zi, ci, de exemplu, în domeniul bancar, care este sub supravegherea auditorilor și cu un nivel foarte mare de izolare a mediilor superioare.
Dar nu uitați că toate visele voastre sunt limitate de audit. Și asta schimbă totul. Vă aștept în comentarii!
Sursa: habr.com
