Conţinut
- Pregătirea pentru eșec
- Următorii pași
- Fără bug-uri, fără stres - Ghidul dvs. pas cu pas pentru crearea de programe care schimbă viața fără a vă distruge viața
- Învățarea și îmbunătățirea prin exerciții
Sursa: pressureUA / iStockphoto
La pachet:
Sistemele moderne trebuie să poată gestiona haosul pentru a evita timpul de oprire. Acesta este motivul pentru care este mai important ca niciodată să testezi minuțios sistemele și să le asiguri rezistența.
În ciuda eforturilor noastre cele mai mari de a le evita, incidentele IT reprezintă o parte inevitabilă a locului de muncă - și încercarea de a rămâne în fața perioadei de dezactivare cu impact asupra afacerilor este doar mai dificilă. Sistemele de astăzi sunt strâns cuplate și din ce în ce mai complexe și cu piese în mișcare vin mai multe oportunități pentru ca lucrurile să nu funcționeze.
Acesta este un motiv pentru care din ce în ce mai multe organizații apelează la microservicii pentru o mai mare disponibilitate a serviciilor și o mai bună rezistență la eșec. Dar, deși acestea sunt premise foarte bune pentru ruperea aplicațiilor monolitice, ele pot, de asemenea, să compară riscul eșecului - cu excepția cazului în care sunt concepute în mod expres cu reziliență.
Pregătirea pentru eșec
Având în vedere natura inerent haotică a sistemelor distribuite, serviciile ar trebui dezvoltate nu numai pentru a anticipa eșecul, ci pentru a se recupera automat în caz de eșec. Acest lucru înseamnă instigarea eșecurilor în mod regulat pentru a vă asigura că sistemele dvs. pot gestiona haosul fără a întrerupe serviciile clienților finali. Pentru a realiza acest lucru, aveți nevoie de capacitatea de a simula traficul asemănător producției în mediile de testare.
Desigur, este o idee bună să testați rezistența înainte ca schimbările să fie aduse producției. Dacă nu faceți acest lucru, nu veți putea verifica dacă serviciile dvs. pot suporta atât încărcarea medie, cât și cea maximă. De fapt, cel mai sigur pariu este să vă asigurați că produsul dvs. poate gestiona până la de două ori valoarea maximă, fără a fi necesar să crească.
În ceea ce privește testarea rezistenței, instrumentele potrivite nu ar trebui să fie prea preocupați de modul în care sunt gestionate cererile, ci doar că acestea au un impact corect până la urmă. Nu uitați că, în anumite condiții, serviciul de intrare nu poate transmite o solicitare către restul sistemului, dar nu raportează defecțiunea. Nu vă riscați să zburați sub radarul de monitorizare, asigurându-vă că validarea finală se întâmplă. (Pentru mai multe, consultați Eșecurile tehnice: le putem trăi?)
Următorii pași
După ce ați înțeles cum se comportă serviciile sub sarcină, este timpul să începeți să introduceți evenimentele de defectare. La fel ca în cazul tuturor testărilor software, cel mai bine este să aveți instrumente automate care vă permit să reproduceți cu ușurință și rapid scenarii, astfel încât să puteți coordona evenimente complexe care afectează diferite tehnologii de infrastructură. Și dincolo de capacitatea de a verifica corecțiile și modificările serviciilor, acest lucru vă permite să rulați scenarii de eșec aleatoare în orice mediu și într-un program.
Evenimentele de eșec semnificative depind în mare măsură de aspectul serviciilor dvs. și le puteți formula punând întrebări specifice care vă sunt relevante. De exemplu, care este impactul pentru persoanele care utilizează front-end-ul atunci când o bază de date devine iremediabilă pentru o anumită perioadă de timp? Acești utilizatori pot naviga în continuare la interfața de utilizator web? Mai pot emite actualizări la informațiile lor și vor fi procesate corect atunci când baza de date devine din nou accesibilă?
Dacă rulați mai multe microservicii, vă puteți întreba dacă va exista o întrerupere globală în cazul în care un serviciu individual se prăbușește. Sau dacă aveți un mecanism în coadă pentru a proteja comunicarea între servicii, ce se întâmplă atunci când serviciul (sau serviciile) consumatorului încetează să funcționeze? Utilizatorii vor mai putea lucra cu aplicația dvs.? Și având în vedere o încărcare medie, cât timp mai aveți înainte de preaplinul cozilor și să începeți să pierdeți s?
Fără bug-uri, fără stres - Ghidul dvs. pas cu pas pentru crearea de programe care schimbă viața fără a vă distruge viața
Nu îți poți îmbunătăți abilitățile de programare atunci când nimeni nu îi pasă de calitatea software-ului.
După ce ați definit câteva întrebări cheie despre infrastructura dvs., puteți începe să enumerați diferite moduri de a simula aceste defecțiuni. S-ar putea să fie suficient pentru a opri un anumit serviciu sau un server de baze de date. S-ar putea să doriți să blocați firul principal al unui serviciu pentru a simula un blocaj mortal, în timp ce containerul său este încă sensibil și funcționează. Ați putea decide să introduceți reguli în rețeaua dvs. pentru a bloca traficul între anumite servicii. În mediile Linux, puteți utiliza instrumente precum „tc” pentru a imita situații de rețea precum pachete cu latență ridicată, stricate, corupte sau duplicate. (Poate fi important să implici utilizatorii la testare. Citiți mai multe în 4 motive pentru care utilizatorii finali trebuie să participe la testarea înainte de UAT.)
Învățarea și îmbunătățirea prin exerciții
Unul dintre cele mai valoroase aspecte ale creării scenariilor de eșec este acela că pot expune toate modalitățile potențiale prin care sistemul poate eșua, făcând astfel calea către logica de auto-vindecare. Echipa ta va parcurge pașii pentru recuperarea serviciilor manual - un exercițiu minunat, apropo, pentru a confirma că sunt capabili să facă acest lucru în cadrul SLA-urilor. Automatizarea acestui proces de recuperare poate fi lucrată, dar, între timp, vă puteți odihni ușor, știind că echipa dvs. a trecut prin procesul de recuperare a serviciilor. Făcând scenarii de eșec aleatoriu și regulat și nu dezvăluind detaliile complete ale rulării, puteți include, de asemenea, descoperirea și diagnosticarea la exercițiu - care este, până la urmă, o parte critică a SLA-urilor.
La baza sa, ingineria haosului ia complexitatea sistemului ca o dată, o testează simulând condiții noi și neplăcute și observă cum reacționează sistemul. Este vorba despre echipele de inginerie de date care trebuie să reproiecteze și reconfigureze sistemul pentru a obține o reziliență mai mare. Există atât de multe oportunități de a învăța lucruri noi și utile. De exemplu, puteți găsi cazuri în care serviciile nu primesc actualizări atunci când serviciile din aval s-au schimbat sau zonele în care monitorizarea lipsește complet. Nu lipsesc modalități interesante de a face produsul mai rezistent și mai robust!