Punerea în producție este o decizie umană
Bogdan Hruban · Wizeri
O parte din munca noastră nu are deloc AI în ea. Un client vine la noi cu o platformă care mergea bine cu o mână de utilizatori și acum cedează sub încărcare reală. Codul a fost scris de un furnizor care a ajuns la limita a ceea ce poate face; fiecare release este o după-amiază cu emoții; nimeni nu este sigur că backupurile se restaurează. Cererea nu este „fă-o mai inteligentă”. Este „fă-o să nu mai cadă, și asigură-te că o putem opera după ce plecați”.
Am făcut acest fel de salvare și ne-a învățat ceva ce aplicăm acum la fiecare automatizare pe care o construim: pipeline-ul ar trebui să facă aproape totul, iar decizia de a livra ar trebui să rămână una umană. Această notă este despre unde stă acea linie și de ce.
Cum arată o platformă fragilă din interior
Simptomele sunt de obicei aceleași. Există un singur mediu, și acela este producția. Punerea în producție este o secvență de pași manuali care trăiesc în capul unei singure persoane. Testele există, dar nu sunt rulate înaintea unui release pentru că durează prea mult sau pică din motive pe care nimeni nu le-a investigat. Monitorizarea este un client care trimite email să spună că site-ul a căzut. Planul de recuperare este „sună persoana care a construit-o”.
Nimic din toate astea nu este un eșec tehnologic. Este ceea ce se întâmplă când un sistem crește mai repede decât obiceiurile din jurul lui. Soluția sunt în mare parte obiceiurile, scrise și automatizate ca să supraviețuiască oamenilor care le-au început.
Ce automatizăm
Aproape tot ce stă între o modificare și un release.
Pipeline-uri separate pentru front end și back end, ca o modificare într-unul să nu forțeze reconstruirea celuilalt. Versionare semantică, ca un release să aibă un nume și echipa să poată spune care este live. Puneri în producție automate cu notificări de release, ca nimeni să nu trebuiască să țină minte pașii și toată lumea să știe când s-a schimbat ceva.
Porți de calitate automate pe fluxurile critice: suite de teste end-to-end și în browser care rulează înainte ca un release să poată merge mai departe, și teste de încărcare înainte ca un release să fie promovat, ca prima întâlnire a platformei cu o mulțime să nu fie la un eveniment live.
Monitorizare cu health check-uri reale și alertare, plus referințe de capacitate care spun echipei cum arată normalul, ca deciziile de scalare să fie luate pe numere, nu pe frică.
Proceduri de disaster recovery documentate, rutine de backup și runbook-uri, testate, ca recuperarea să fie o procedură și nu o salvare. Și documentația pentru rest: arhitectura, runbook-urile operaționale, manualele de utilizare, API-ul. Scopul colaborării este o platformă pe care clientul o poate opera fără noi.
Ce nu automatizăm intenționat
Două decizii. Ce se livrează și când intră live.
Este tentant să legi pipeline-ul până la capăt: testele trec, deploy în producție, gata. Noi nu facem asta, și nu este prudență de dragul prudenței. O suită de teste verde îți spune că modificarea face ce descriu testele. Nu îți spune că azi este o zi bună ca să schimbi platforma. Clientul rulează lansări de cohorte și rollout-uri corporate pe acest sistem; un release în dimineața unuia dintre ele este o idee proastă chiar dacă trec toate testele. Pipeline-ul nu poate ști asta. Un om poate.
Așa că pipeline-ul pregătește totul: build-ul, testele, versiunea, notele de release, punerea pe staging unde modificarea poate fi privită. Apoi se oprește și așteaptă ca cineva să spună „dă-i drumul”. Acel cineva are contextul care îi lipsește pipeline-ului, iar decizia durează un minut pentru că toată munca este deja făcută.
Aceeași regulă trece și prin propria noastră platformă de livrare, unde agenții joacă fiecare rol dintr-o echipă de livrare, de la specificație la review și teste, iar un om este păstrat exact la acele două decizii: ce se livrează și când intră live. Nu am ajuns la regula asta din teorie. Am ajuns la ea privind ce se întâmplă când un release iese la momentul nepotrivit.
Securitate de la început, nu ca o etapă
O salvare este și momentul de a pune în loc controalele pe care prima construcție le-a sărit. Un singur punct public de intrare, cu nivelurile de aplicație și de date în spatele lui. Acces pe bază de roluri și jurnalizare de audit. Backupuri care nu sunt doar făcute, ci și restaurate, regulat, ca să dovedească că funcționează. Răspunsul la incidente scris înainte să existe un incident. Un pachet documentat de prelucrare a datelor, ca clientul să poată răspunde întrebărilor unui client corporate cu documente, nu cu asigurări.
Facem asta în timpul salvării pentru că după aceea nu se mai întâmplă niciodată. Odată ce platforma este stabilă, securitatea devine un proiect pentru trimestrul viitor, iar trimestrul viitor are propriile urgențe.
Ce primește clientul înapoi
O platformă care rulează sub încărcare reală, cu un proces de release care nu depinde de o singură persoană, o cale de recuperare care a fost repetată și documentație care permite propriei echipe să o opereze. Arhitectura susține și ce urmează, fie că este single sign-on, infrastructure as code sau o funcție AI, pentru că acestea sunt mai ușor de adăugat la un sistem stabil decât la unul fragil.
Lecția pe care o ducem în munca de automatizare
Când automatizăm un proces de business în loc să salvăm o platformă, se aplică aceeași formă. Automatizarea mută comanda din inbox în ERP, potrivește factura, construiește raportul de luni. Nu decide să schimbe regula de preț sau să trimită emailul de urmărire celui mai mare client în ziua greșită. Acelea rămân decizii, iar deciziile rămân la oamenii care conduc afacerea.
Automatizează munca. Păstrează judecata. Punerea în producție este o decizie umană, la fel ca tot ce seamănă cu una.
Vrei să vorbim despre automatizare pentru afacerea ta?
Programează un apel gratuit sau începe cu o scanare rapidă.