Incidentele sunt evenimente nedorite, imprevizibile, dar sigure. Pe măsură ce un sistem devine mai complex, crește probabilitatea ca respectivul sistem să se defecteze sau ca oamenii care îl utilizează să facă greșeli. Modul în care ne raportăm la aceste situații și le gestionăm are un impact major în cultura organizațională și în performanța echipei și a organizației.
Să considerăm următoarea situație:
Sabin este un administrator de sisteme cu o experiență de trei ani. De un an de zile a venit la firma IT SRL unde administrează servere și mașini virtuale Linux, într-o echipă de cinci ingineri. De curând, managerul său a decis că este nevoie de o standardizare a numelor serverelor pentru că au rămas fără personaje Game of Thrones pentru servere. Astfel, a decis ca fiecare categorie de mașini să fie codificată cu culori și numere, în funcție de rolul lor. De exemplu, DNS-urile se numesc de acum red-01, red-02, iar webserverele black-01... black-xy.
Sabin a fost însărcinat să ruleze un update de kernel pe web server-ele folosite pentru staging (denumite blackest-01, blackest-05 etc.), iar pentru aceasta a pregătit o comandă care citește numele serverelor dintr-un fișier, se conectează prin SSH la ele și rulează comenzile necesare pentru update.
Pentru că nu părea o schimbare importantă, Sabin a rulat comanda vineri după-amiază, după care s-a dus acasă, deoarece dura mult să se realizeze upgrade-ul. Ce nu a observat el, însă, a fost că, din greșeală, fișierul cu numele serverelor folosit ca argument a fost blackserv în locul blackest, după cum a decis el să le numescă pe cele cu serverele de producție și, respectiv, staging.
Într-un final, acest update a afectat stiva de rețea și a durat 4 ore până când colegul care asigura permanența a fost notificat de faptul că site-urile nu mai funcționează, și-a dat seama ce a cauzat problema și a reușit să o remedieze.
Luni dimineața, aflând de problemă și de gravitatea ei, singura reacție a managerului lui Sabin a fost să-I spună că astfel de greșeli sunt inacceptabile, iar la următoarea astfel de întâmplare vor exista consecințe.
Astfel de situații se întâlnesc des, oamenii făcând greșeli mereu. Reacții precum cea a managerului ar putea fi considerate firești. Rolul unui manager este de a se asigura că echipa sa livrează ceea ce promite (sistemele să fie disponibile, în acest caz), în cele din urmă.
Dacă analizăm, însă, experiențele avute de-a lungul timpului de companii în care s-a reacționat astfel în fața greșelilor, vom avea o surpriză.
Sabin, personajul principal al întâmplării, aflând că a cauzat din neatenție downtime pentru produs și, mai ales, că un alt coleg a fost nevoit să intervină, s-a simțit vinovat pentru situația creată. Ceea ce i-a spus șeful lui i-a întărit acest sentiment și a creat, în plus, o stare de frică în sinea sa. De acum se va gândi de două ori înainte de a mai face modificări automate pe servere, poate chiar evitând să le mai facă el. Iar dacă apare un nou incident va fi mai puțin dornic să spună tot ce s-a întâmplat, pentru a nu fi pus din nou la zid.
Colegii lui de echipă vor trece prin stări asemănătoare. Incidentele vor fi raportate tot mai sumar și va exista tendința de arunca vina pe colegi sau alte echipe. Pentru a nu fi cei considerați vinovați în cazul unor probleme apărute, chiar dacă ele nu au apărut din erori umane, oamenii vor căuta scuze sau vor evita anumite sarcini.
În astfel de situații se instaurează o cultură a fricii. Ea este bazată pe principiul "mărului stricat": când găsim un măr stricat într-o grămadă de mere, îl scoatem și îl aruncăm. Dacă ne comportăm la fel cu cei ce greșesc, rezultatele pe termen lung sunt departe de a fi pozitive, după cum s-a văzut și în exemplul anterior.
John Alspaw, de la Etsy, consideră că incidentele ar trebui tratate ca oportunități de învățare și nu ca ocazii de a arăta cu degetul pe vinovați și atât. Astfel, dacă fiecărei persoane care a participat la cauzarea sau repararea unui incident îi este permis să își prezinte perspectiva, întreaga organizație are de învățat din situație. În plus, se pot lua măsuri astfel încât astfel de evenimente să fie evitate pe viitor.
Contextul în care se face acest schimb de informații poartă denumirea, în multe organizații, de "blameless postmortem", sau retrospectivă. Aceasta este o ședință care se organizează "la cald", imediat după un incident sau după terminarea unui proiect (cu succes sau nu). Etapele unui astfel de postmortem pot fi rezumate astfel:
Stabilirea contextului: "Ne aflăm aici pentru a înțelege ce s-a întâmplat, pentru a învăța și nu pentru a căuta vinovați."
Descrierea incidentului sau a proiectului.
Stabilirea cronologiei: ce și când s-a întâmplat, ce și când s-a spus, la ce s-au gândit cei implicați când au luat o decizie; pentru acest pas, o cameră de chat orientate înspre aceste probleme este utilă.
Determinarea altor factori care au contribuit la apariția evenimentului: atât de natură personală (oboseală, probleme familiale etc.), cât și profesională (probleme de comunicare între echipe, probleme tehnice etc.).
Descrierea impactului asupra clienților/businessului.
Stabilirea unor acțiuni de evitare a unor astfel de probleme și/sau îmbunătățire a procesului de rezolvare a lor: e recomandat ca aceste acțiuni să respecte principiile SMART (Specific, Măsurabil, Agreat, Realist, limitat ca Timp)
De asemenea, la astfel de ședințe este recomandat să participe toți factorii implicați și/sau afectați de incident, chiar dacă cei din urmă sunt acolo pentru a învăța ce s-a întâmplat și care sunt pașii pentru remedierea problemei. După postmortem se poate redacta un document care să descrie incidentul și cum se vor evita astfel de evenimente. Exemple bune de astfel de documente le oferă Amazon cu ocazia unor evenimente majore în infrastructura sa.
Un element important în gestionarea cu succes a incidentelor îl are încrederea în propria persoană și între membrii echipei. Această încredere este ușor de obținut atunci când fiecare persoană știe ce are de făcut într-o situație de criză. Pentru aceasta, unele companii au proceduri stabilite și respectate de către toți membrii echipei în cazul unor incidente. Un exemplu de astfel de procedură este oferit de Server Density :
Deschidere ticket Jira pentru incident.
Oprirea notificării pagerduty.
Intrarea în camera de chat pentru incidente.
Căutarea în baza de cunoștințe disponibilă cu probleme. Probabil alerta a mai fost întâlnită și există o rezolvare.
Dacă problema îi afectează pe utilizatori, este postată o notificare pe site.
Existența unei astfel de proceduri creează o stare de siguranță celor care asigură permanența, mai ales celor noi din echipă, deoarece ei știu ce au de făcut, cel puțin, la început într-o situație de criză. De asemenea, toți ceilalți colegi știu că au fost parcurși aceiași pași în gestionarea incidentelor și există astfel predictibilitate. Notarea etapelor pentru rezolvarea problemei în ticket și discuțiile de pe chat vor servi ulterior ca bază pentru postmortem, pe lângă beneficiul lor evident din timpul crizei.
De asemenea, pot fi organizate exerciții de intervenție în caz de downtime, asemănător cu simulările de incendii organizate de pompieri. Ele asigură faptul că procedura este testată si respectată și toată lumea știe ce are de făcut, crescând astfel încrederea între membrii echipei. Aceste exerciții mai poartă denumirea de drill-uri sau war games și pot să vizeze chiar și producția, realizându-se în stil chaos monkey.
Dacă ne întoarcem la exemplul de la începutul articolului, ne putem întreba ce ar fi putut să învețe Sabin, managerul său și echipa din respectiva situație. Un prim punct ar putea fi de natură tehnică: actualizarea serverelor prin scripturi sau comenzi scrise de fiecare administrator în parte implică muncă în plus și e susceptibilă la erori; utilizarea unui sistem de automatizare a configurațiilor și de orchestrare ar reduce numărul de erori și ar permite o vizibilitate mai mare la ce se petrece în infrastructură (colegul on-call ar vedea mai repede ce s-a schimbat și ar detecta problema). Un alt punct îl reprezintă peer review: dacă Sabin ar fi prezentat planul său și comanda exactă care urmează să o ruleze unui coleg, acesta ar fi prins, probabil, faptul că fișierul cu servere este greșit sau l-ar fi sfătuit să nu ruleze update-ul într-o după-masă de vineri.
Orice greșeală poate fi privită ca o oportunitate de învățare și îmbunătățire a procesului organizațional. Dacă cineva a făcut ceva ce nu trebuia, înseamnă că nu există o politică care să-l împiedice să o facă; dacă nu a știut că trebuie să facă ceva, înseamnă ca nu există o procedură care să specifice acel lucru, iar dacă nu a știut cum să facă ceva, înseamnă că are nevoie de mai mult training.
Căutarea și evidențierea mereu a celor vinovați mută atenția de la problemele cu adevărat importante și împiedică evoluția în bine a practicilor și proceselor organizaționale, inhibând în oameni dorința de schimbare.
https://codeascraft.com/2012/05/22/blameless-postmortems/
http://chef.github.io/devops-kungfu/\#/59
http://www.slideshare.net/jhand2/its-not-your-fault-blameless-post-mortems
de Ovidiu Mățan
de Vlad But
de Maria Revnic
de Delia Mircea
