Subiectul DevOps și IaC este foarte popular și se dezvoltă rapid. Cu toate acestea, majoritatea autorilor se ocupă de probleme pur tehnice pe această cale. Voi descrie problemele caracteristice unei companii mari. Nu am o soluție - problemele, în general, sunt fatale și se află în domeniul birocrației, auditului și „abilităților soft”.
Deoarece titlul articolului este așa, Daenerys, care a trecut de partea Enterprise, va acționa ca pisica.
Fără îndoială, acum există o ciocnire între vechi și nou. Și adesea în aceste ciocniri nu există nici bine, nici greșit. Așa s-a întâmplat. Dar, pentru a nu fi nefondate, vom începe cu acest ecran:
Aceasta este așa-numita cerere de modificare. Vedeți aproximativ o treime din câmpurile care trebuie completate din diferite directoare, câmpurile rămase sunt în alte marcaje. Un astfel de document trebuie completat pentru a aplica scriptul pe serverul de producție sau pentru a încărca fișiere noi sau, în general, pentru a schimba ceva.
Numărul de câmpuri este așa încât mi-am scris propria mea automatizare pentru completarea acestor câmpuri. Mai mult, această pagină este scrisă în așa fel încât niciun instrument de automatizare să nu-și poată vedea câmpurile, iar singura soluție posibilă a fost să folosești AutoIt pentru a da clic prostește pe coordonatele cu mouse-ul. Evaluează-ți nivelul de disperare de a face asta:
Deci, luați jenkins, bucătar, terraform, nexus etc. și le implementați cu bucurie pe dev-ul dvs. Dar vine momentul să-l trimitem către QA, UAT și PROD. Aveți un artefact Nexus și primiți o scrisoare de la DBA cu ceva de genul acesta:
Dragă,
În primul rând, nexusul tău pe care îl poți avea pentru tine, nu am acces la Nexusul tău
În al doilea rând, toate modificările trebuie emise ca o Solicitare de modificare.
Trebuie să extrageți scripturile SQL din Nexus și să le atașați la cererea de modificare.
Dacă schimbarea nu este de urgență, aceasta ar trebui făcută cu 7 zile înainte de lansare (exclusiv în weekend)
Când cererea de modificare este aprobată de o mulțime de oameni, DBA va executa scriptul și chiar va trimite o captură de ecran a rezultatului prin e-mail.Cu respect, DBA care lucrează aici din vremea mainframe-ului.
Știi de ce îmi amintește asta? Semi-automatizare: robotul ține cadrul, iar muncitorul îl lovește cu un baros. Ei bine, într-adevăr, ce rost are acest Nexus dacă apoi totul este făcut complet manual?
Dar Enterprise nu ar trebui să fie învinuită pentru asta! Este, desigur, sângeros, dar toată birocrația asta cu Solicitări de Schimbare este forțată și vine de la auditori. Întreprinderea trebuie să funcționeze așa, punct. Nu o poate face altfel. Și auditul este un lucru foarte conservator. De exemplu, cât de mult s-a spus despre faptul că parolele lungi pseudo-complexe și schimbate frecvent sunt proaste, dar întreprinderile vor fi ultimul loc în care acest lucru va fi schimbat. De asemenea, cu implementări și orice altceva.
Apropo, la un moment dat am încercat să creez un fișier pentru terraform, dar nu a funcționat. M-am împiedicat de semnificația etichetei „Cod de facturare contabilă de proiect”, pe care nu am reușit să o aflu niciodată – nu aveam destule abilități soft.
Nici măcar nu mă ocup de tema ludismului pasiv - oh, automatizarea ta îmi amenință siguranța locului de muncă, nu vreau să învăț nimic nou, așa că îl voi sabota în liniște.
Ei bine, care ar putea fi soluția în principiu? Sistemul ITSM are un API extrem de primitiv pentru generarea automată a documentelor. Și, în general, majoritatea acestor sisteme provin din vremurile mainframe-urilor. Cunoaște cineva sisteme ITSM cu adevărat moderne? Are cineva experiență de succes în integrarea DevOps-ului modern și a birocrației? Bineînțeles, nu vorbim de site-uri pur de vânzări, unde poate fi efectiv o implementare în fiecare zi, ci, de exemplu, sectorul bancar, care este sub auditori și izolat foarte puternic în medii superioare.
Doar nu uita că toate fanteziile tale sunt limitate de audit. Și asta schimbă totul. Va astept in comentarii!
Sursa: www.habr.com