ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 147
Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 47
Abonament PDF

Gestionarea incidentelor și a vinei într-o cultură DevOps

Claudiu Demian
Systems Administrator
@Yardi România



PROGRAMARE


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 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 :

  1. Deschidere ticket Jira pentru incident.

  2. Oprirea notificării pagerduty.

  3. Intrarea în camera de chat pentru incidente.

  4. Căutarea în baza de cunoștințe disponibilă cu probleme. Probabil alerta a mai fost întâlnită și există o rezolvare.

  5. Dacă problema îi afectează pe utilizatori, este postată o notificare pe site.

  6. Dacă persoana care este on-call nu reușește să rezolve problema, aceasta este data spre rezolvare celor care probabil pot.  

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.

Bibliografie:

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

https://aws.amazon.com/message/5467D2/

https://blog.serverdensity.com/whats-on-call-playbook/

Conferință TSM

NUMĂRUL 147 - Automotive

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects