Există un moment în evoluția oricărei infrastructuri când munca manuală devine principala sursă de incidente. Un server nou se configurează în două zile, pentru că nimeni nu mai știe exact ce s-a instalat pe cel anterior. Mediul de test diferă de producție în moduri care ies la iveală doar la lansare. Aceeași procedură executată de doi colegi produce două rezultate ușor diferite. Automatizarea nu este un obiectiv în sine, ci soluția pentru aceste probleme concrete.
Cum abordăm automatizarea
Nu propunem rescrieri complete. Începem prin a identifica operațiunile executate frecvent, cele care consumă cel mai mult timp și cele în care o greșeală produce daune. Aceste trei categorii se suprapun de obicei, iar suprapunerea indică exact de unde trebuie început.
Fiecare automatizare este scrisă pentru a putea fi rulată de mai multe ori fără efecte secundare. O procedură care funcționează doar la prima execuție și strică ceva la a doua este mai periculoasă decât munca manuală, pentru că inspiră o încredere nejustificată. Testăm rolurile Ansible cu Molecule în containere, înainte ca acestea să atingă un sistem real.
Codul de infrastructură trece prin aceleași etape ca orice alt cod: se scrie într-o ramură separată, se validează automat, se revizuiește de un coleg și se aplică prin pipeline. Pentru mediul de producție, pipeline-ul se oprește după generarea planului de modificare și așteaptă aprobare umană. Nimeni nu aplică modificări direct din propriul calculator.
Ce construim
Pentru infrastructură scriem module Terraform reutilizabile, cu starea păstrată centralizat și blocată în timpul aplicării, cu medii separate pentru dezvoltare, test și producție. Pentru configurația din interiorul sistemelor scriem roluri Ansible, structurate astfel încât un server nou să ajungă la standardul agreat printr-o singură execuție.
Pipeline-urile CI/CD acoperă atât infrastructura, cât și aplicațiile: validare sintactică, teste automate, construirea imaginilor cu Packer sau Docker, publicarea în etape și verificarea stării serviciului după publicare. Secretele se păstrează în Vault sau în serviciul echivalent din platforma cloud, niciodată în cod.
Adăugăm și partea care se uită frecvent: documentația și instruirea. O automatizare pe care doar autorul o înțelege este un punct unic de defect mutat din infrastructură în cod. Predăm materialele și lucrăm împreună cu echipa dumneavoastră până când poate modifica și extinde singură ce am construit.
Pentru cine este potrivit
Serviciul se potrivește echipelor care administrează suficiente sisteme încât munca manuală să devină o limitare, de obicei începând de la douăzeci-treizeci de servere sau de la mai multe medii care trebuie menținute sincronizate. Este util și companiilor care au început automatizarea, dar au ajuns la un set de scripturi neîntreținute, scrise de oameni care între timp au plecat.
Un alt caz frecvent este organizația care trebuie să demonstreze control asupra modificărilor pentru un audit. Cerințele NIS2 privind gestionarea schimbărilor și trasabilitatea sunt mult mai ușor de îndeplinit atunci când fiecare modificare de infrastructură are un autor, o dată, o revizuire și un istoric în Git.
Ce se automatizează primul
În aproape toate proiectele, ordinea este similară. Începem cu provizionarea, pentru că un server construit din cod elimină diferențele acumulate manual. Urmează aplicarea actualizărilor, care este repetitivă și se pretează perfect automatizării, cu avantajul suplimentar că raportul de execuție devine dovadă pentru audit. Al treilea pas este publicarea aplicațiilor, unde beneficiul se vede imediat în frecvența livrărilor și în numărul de erori la lansare.
Abia după acestea trecem la operațiuni mai complexe: reconstruirea completă a unui mediu, rotirea automată a credențialelor sau scalarea în funcție de încărcare. Ordinea contează, pentru că fiecare etapă construiește pe încrederea câștigată în precedenta. O echipă care a văzut automatizarea funcționând corect pe sarcini simple acceptă mult mai ușor extinderea ei către operațiuni critice.
Rezultate măsurabile
Timpul de provizionare a unui mediu nou scade de la zile la ore. Diferențele dintre test și producție dispar, pentru că ambele se generează din același cod cu parametri diferiți. Numărul incidentelor cauzate de erori de configurare scade vizibil, iar recuperarea după un incident devine previzibilă, pentru că mediul se poate reconstrui în loc să fie reparat sub presiune.