Cea mai utila lectie despre monitorizare automatizari am primit-o pe 28 iulie 2026, de la propria noastra infrastructura. O actualizare de rutina a sters 16 din 17 sarcini programate si nu a plecat nicio alerta. Nu pentru ca sistemul de alertare era stricat, ci pentru ca functiona exact asa cum fusese gandit.
Scriem despre asta fiindca e cel mai frecvent mod real in care se rup automatizarile dintr-un IMM, si aproape nimeni nu vorbeste despre el. Toata lumea discuta ce sa automatizezi. Foarte putini discuta cum afli ca automatizarea a incetat sa mai ruleze, adica exact ce inseamna o monitorizare automatizari care chiar functioneaza.
Ce s-a intamplat, pe scurt
La ora 11:32 am rulat o actualizare de rutina pe una dintre componentele interne. La 11:46, fisierul de configurare al programatorului de sarcini a fost rescris de acea actualizare. Inainte existau 17 sarcini programate. Dupa, a ramas una singura.
Printre cele 16 pierdute erau sapte agenti de monitorizare (server, securitate, WordPress, analiza, calitate si doua fluxuri de continut) si trei fluxuri de publicare. Ultima rulare inregistrata fusese la 08:00, in aceeasi dimineata. Dupa 11:46 nu mai era programata niciuna.
Niciun serviciu nu a picat. Nicio pagina nu a dat eroare. Nimic nu s-a colorat in rosu pe niciun ecran. Sistemul, vazut din exterior, arata perfect sanatos.
De ce nu a plecat nicio alerta
Explicatia e simpla si merita retinuta, fiindca se aplica la orice firma care are ceva programat sa ruleze singur. Sistemele de alertare raporteaza esecuri. O sarcina stearsa nu esueaza niciodata. Ea pur si simplu nu mai exista, iar ce nu exista nu are cum sa raporteze ca a mers prost.
De aici prima concluzie, si cea mai importanta: absenta erorilor nu este o dovada de sanatate. E doar absenta erorilor. Un sistem care tace poate sa functioneze ireprosabil sau poate sa fie mort de cinci ore, iar din tacere singura nu deosebesti cele doua situatii.
A doua concluzie e putin mai neplacuta. Printre sarcinile sterse se aflau chiar agentii de monitorizare, adica exact mecanismele care ar fi trebuit sa prinda asa ceva. Supravegherea traia in interiorul sistemului supravegheat, asa ca a disparut odata cu el. Cand paznicul si cladirea sunt acelasi lucru, nu ai paznic.
Partea stanjenitoare
Nu o ocolim, fiindca fara ea povestea nu are valoare pentru nimeni. Noi am rulat actualizarea. Tot noi nu am observat ce a facut. Problema a fost descoperita aproximativ cinci ore mai tarziu, la o verificare manuala facuta din alt motiv. Nu de un automatism, nu de o alerta, ci de un om care s-a uitat intamplator in locul potrivit.
Cinci ore in care fluxurile de publicare nu au rulat si nicio verificare de securitate sau de infrastructura nu s-a facut. Ne-am fi putut consola cu ideea ca a fost un ghinion. Nu a fost. A fost o lacuna de proiectare pe care o aveam de mult si pe care nu o vazuseram, fiindca pana atunci nimic nu o scosese la iveala.
Cum am restaurat si ce ne-a salvat de fapt
Restaurarea a fost surprinzator de simpla. Exista o copie de siguranta a configurarii, ramasa in urma unei migrari facute pe 11 iulie. Am comparat structura fisierului intre versiuni, era identica, asa ca am reintrodus cele 16 sarcini si nu a fost nevoie nici macar sa repornim serviciul. Interventia efectiva a durat mult mai putin decat cele cinci ore in care nu am stiut ca avem o problema.
Merita spus cinstit si aici: copia aceea nu exista pentru ca aveam o procedura care o cerea. Exista fiindca ramasese acolo dupa alta operatiune. Adica ne-a salvat norocul, nu disciplina. Diferenta dintre cele doua devine vizibila abia atunci cand norocul lipseste.
Al doilea caz, in aceeasi zi
Ca sa fie tabloul complet, in aceeasi zi am avut si un al doilea incident, cu aceeasi cauza de fond. O actualizare aplicata direct pe productie, fara verificarea prealabila a modificarilor locale, a lasat o alta componenta nefunctionala aproximativ 17 minute.
Doua incidente, o singura radacina: actualizarile au fost tratate ca operatiuni banale, iar starea sistemului de dupa actualizare nu a fost verificata de nimeni si de nimic. Nu a fost o problema de unelte. A fost o problema de procedura.
Trei semne ca nu ai monitorizare automatizari, ci doar impresia ei
Inainte de solutii, un scurt test. Daca te regasesti in oricare dintre situatiile de mai jos, esti exact acolo unde eram noi pe 28 iulie dimineata.
- Toate verificarile pornesc de la o eroare. Daca fiecare alerta pe care ai primit-o vreodata a fost declansata de ceva care a esuat, atunci sistemul tau nu stie sa observe lucruri care lipsesc. Iar disparitia e mai frecventa decat esecul.
- Nu poti spune din memorie cate lucruri automate ruleaza. Daca nu exista nicaieri o lista cu ce ar trebui sa se intample si cand, nu ai cu ce sa compari starea reala. Fara referinta, orice numar de sarcini pare corect.
- Verificarile ruleaza pe aceeasi masina cu ce verifica. Comod la instalare, inutil in ziua in care chiar ai nevoie de ele. Un singur incident le poate opri pe amandoua simultan, exact cum ni s-a intamplat noua.
Cinci masuri concrete de monitorizare automatizari
Toate cele de mai jos se pot aplica fara unelte scumpe si fara o echipa dedicata. Le-am implementat la noi dupa acest incident si sunt, in ordine, exact ce am fi vrut sa avem pe 28 iulie dimineata. Impreuna formeaza minimul rezonabil de monitorizare automatizari pentru o firma mica.
- Verificare de prezenta, nu de esec. Fiecare sarcina importanta trebuie sa lase un semn ca a rulat: o linie intr-un fisier, o inregistrare intr-un tabel, un mesaj. Apoi verifici periodic daca semnul a aparut. Daca lipseste, alertezi. Asta prinde exact cazul in care sarcina nu mai exista, situatie pe care alertarea clasica pe erori nu o poate detecta niciodata.
- Un inventar al sarcinilor asteptate. Tine o lista scrisa cu ce ar trebui sa ruleze si cand, apoi compar-o periodic cu ce e efectiv programat in sistem. Diferenta dintre cele doua liste este raspunsul. La noi, comparatia asta ar fi aratat 17 fata de 1 in cateva secunde.
- Supravegherea sta in afara sistemului supravegheat. Regula pe care am incalcat-o. Verificarea trebuie sa ruleze pe alta masina, alt serviciu sau alt cont decat lucrul pe care il verifica. Chiar si un simplu serviciu extern gratuit care asteapta un semnal periodic si te anunta cand acesta nu mai vine este infinit mai bun decat un agent de monitorizare care poate fi sters odata cu restul.
- Copie de siguranta a configurarii inainte de orice actualizare. Nu doar a datelor, ci a configurarilor: programari, setari, reguli. Sunt fisiere mici, se copiaza in cateva secunde si fac diferenta dintre o restaurare de zece minute si o reconstructie din memorie.
- O verificare dupa fiecare actualizare, trecuta in procedura. Nu la sfarsitul zilei si nu cand isi aminteste cineva. Imediat dupa: s-au pastrat sarcinile programate, ruleaza serviciile, a aparut prima rulare de dupa actualizare. Cinci minute de verificare ar fi economisit cele cinci ore.
Ce ramane din toata povestea
O monitorizare automatizari care asteapta erori te apara doar de esecurile zgomotoase. Automatizarile insa rareori cad zgomotos. De obicei dispar in liniste, iar tacerea care urmeaza seamana perfect cu tacerea unui sistem care merge bine.
Daca ai in firma ceva programat sa ruleze singur, fie ca e un raport, o sincronizare de stocuri, o campanie sau o copie de siguranta, pune-ti o singura intrebare: de unde ai sti maine dimineata ca lucrul acela nu a mai rulat de trei zile? Daca raspunsul este ca ai afla cand se plange cineva, atunci nu ai monitorizare, ai noroc.
Publicam acest caz pentru ca vine din infrastructura noastra, cu ore si cifre verificabile, nu dintr-o prezentare. Alte exemple de lucruri pe care le operam si le reparam gasesti in studiile noastre de caz. Iar daca vrei sa ne uitam impreuna la automatizarile din firma ta si sa vedem care dintre ele ar putea sa taca fara sa afli, scrie-ne pe RoboMarketing.
