Cea mai mare parte din ce scriem e despre prevenție: actualizări, firewall-uri, permisiuni, monitorizare, rutinele discrete care țin un site departe de necazuri. Articolul de față e despre cealaltă parte, planul pentru ziua în care ceva merge totuși prost. Fiecare site de care avem grijă are unul, scris, și credem că fiecare firmă ar trebui să știe ce spune al ei. Nu pentru că incidentele ar fi probabile pe un site bine întreținut, ci pentru că a ști exact ce s-ar întâmpla e ceea ce îi permite fiecăruia să nu-și mai facă griji.
Ce se consideră incident
Un incident e orice eveniment care afectează disponibilitatea, integritatea sau confidențialitatea site-ului sau a datelor lui. Asta acoperă mai mult decât o spargere. O livrare care oprește site-ul, un certificat care expiră, un disc care se umple, un serviciu terț care cade, un cont de editor compromis, o pagină modificată, o scurgere de trimiteri din formulare: toate sunt incidente, iar planul le tratează pe toate cu aceeași structură, pentru că structura e ceea ce ține un răspuns calm.
Detectare: să știi în câteva minute
Planul începe înainte să fie implicat cineva. Monitorizarea urmărește disponibilitatea din mai multe locuri, timpii de răspuns, ratele de eroare, expirarea certificatelor, autentificările eșuate, modificările neașteptate ale fișierelor și configurației și sănătatea fiecărui serviciu de care depinde site-ul. Când un semnal depășește pragul, o alertă ajunge la o persoană, zi sau noapte, și ceasul pornește. Cele mai multe incidente de pe platforma noastră sunt detectate așa, înainte să observe un vizitator sau un client, și o bună parte dintre ele sunt rezolvate înainte ca cineva din afara echipei să afle că au avut loc.
Triaj: primele cincisprezece minute
Persoana de gardă are trei întrebări la care trebuie să răspundă repede. Ce e afectat: o pagină, un site, un server, un serviciu? Se întâmplă încă, sau s-a oprit? Și implică date, ceea ce schimbă obligațiile legale și pe cine trebuie anunțat? Răspunsurile stabilesc severitatea, iar severitatea decide cine mai e chemat și cât de repede aude clientul de la noi.
Pentru orice afectează vizitatorii sau datele, clientul e anunțat în mai puțin de o oră cu ce știm, ce facem și când vine următoarea actualizare. Mesajul acela pleacă chiar și când imaginea e incompletă, pentru că tăcerea e ceea ce dăunează încrederii, nu informația incompletă.
Izolare: să nu se înrăutățească
Înainte să reparăm ceva, oprim incidentul din răspândire. Pasul exact depinde de tip. Un cont compromis e dezactivat și sesiunile lui încheiate. O plajă de adrese suspecte e blocată la edge. O integrare care se comportă ciudat e oprită. Un site atacat activ poate fi pus în spatele unei pagini de mentenanță sau al unui set mai strict de reguli de firewall într-un minut. Pentru că fiecare site rulează în propriul container izolat, cu cod doar pentru citire, un incident dintr-un loc rămâne în acel loc; arhitectura face cea mai mare parte a izolării pentru noi.
Recuperare: înapoi la o stare bună cunoscută
Recuperarea e locul în care pregătirea se răsplătește cel mai vizibil. Fiecare lansare pe care o livrăm e păstrată, așa că, dacă o livrare a cauzat problema, revenirea e un singur pas și durează secunde. Dacă au fost afectate conținut sau date, restaurăm dintr-un backup despre care am dovedit deja că se restaurează, într-un timp pe care l-am măsurat deja. Dacă s-a umblat la cod, mediul de rulare doar pentru citire înseamnă că modificarea n-a putut ajunge la lansarea livrată; relivrăm din repository și site-ul e curat.
Scopul recuperării nu e să înțelegi încă totul. E să ai vizitatorii pe un site funcțional și de încredere cât mai repede posibil. Înțelegerea vine după.
Investigație: ce s-a întâmplat de fapt
Cu site-ul stabil, reconstituim secvența. Jurnalele sunt păstrate exact pentru asta, stocate acolo unde site-ul însuși nu le poate altera, și ne permit să urmărim un incident de la primul semnal până la cauza de fond. Identificăm ce l-a făcut posibil, dacă aceeași condiție există în alte părți și ce schimbare o închide definitiv. Dacă au fost implicate date personale, aici stabilim și ce date, ale cui și dacă s-au atins pragurile pentru notificarea autorităților și a persoanelor afectate, ca clientul să-și poată îndeplini obligațiile în termenele legale.
Comunicare pe tot parcursul
Clienții aud de la noi în fiecare etapă: când detectăm, când izolăm, când recuperăm și când înțelegem. Actualizările merg prin portalul de client și prin mesaj direct, ca să existe o consemnare. Dacă vizitatorii sau clienții trebuie anunțați, ajutăm la scrierea acelui mesaj, simplu, cu ce s-a întâmplat, ce înseamnă pentru ei și ce ar trebui să facă. Scrisă bine, o notificare onestă întărește încrederea în loc s-o consume.
După: analiza post-incident
În câteva zile scriem o analiză scurtă: cronologie, cauză, impact, ce a funcționat, ce nu și ce schimbări facem. E împărtășită cu clientul și, acolo unde lecția e generală, aplicată fiecărui site pe care îl rulăm. Analiza e scrisă fără vină. Scopul ei e ca același lucru să nu se întâmple de două ori, nicăieri, și ca următorul incident, oricare ar fi, să fie gestionat puțin mai bine decât acesta.
De ce contează că e scris
Fiecare pas de mai sus e obișnuit odată ce e planificat. Ce face incidentele stresante e improvizația: să decizi pe cine suni, unde sunt backup-urile, cum revii, ce le spui oamenilor, toate sub presiune. Un plan scris, repetat prin exerciții de restaurare și teste de revenire, transformă o potențială criză într-o procedură. E una dintre părțile mai discrete ale găzduirii administrate, și una dintre cele mai valoroase.
Dacă vrei să știi ce s-ar întâmpla cu site-ul tău într-o zi proastă, întreabă-ne. Îți prezentăm planul, iar dacă nu ai încă unul, te ajutăm să-l scrii.