Sadržaj
- Priprema za neuspjeh
- Sljedeći koraci
- Bez grešaka, bez stresa - Vaš korak po korak vodič za stvaranje softvera koji mijenja život bez uništavanja života
- Učenje i poboljšavanje vježbama
Izvor: pressureUA / iStockphoto
Oduzeti:
Suvremeni sustavi moraju biti u mogućnosti nositi se s kaosom kako bi se izbjegli zastoji. Zato je najvažnije nego ikad važnije temeljito ispitati sustave i osigurati njihovu otpornost.
Unatoč našim najvećim naporima da ih izbjegnemo, IT incidenti su nezaobilazni dio posla - i pokušati ostati ispred poslovnog vremena zaostaje samo postaje otežano. Danas su sustavi čvrsto povezani i sve složeniji, a s više pokretnih dijelova dolazi više mogućnosti da stvari pođu po zlu.
To je jedan od razloga zašto se sve više organizacija okreće mikroservisima radi veće dostupnosti usluga i veće otpornosti na neuspjeh. No, iako su to sjajne pretpostavke za probijanje monolitnih aplikacija, oni također mogu potencijalno složiti rizik od neuspjeha - osim ako nisu izričito dizajnirani s obzirom na otpornost.
Priprema za neuspjeh
S obzirom na prirođenu haotičnu prirodu distribuiranih sustava, usluge bi trebale biti razvijene ne samo da predvideju neuspjeh, već da se automatski obnove u slučaju kvara. To redovito znači pokretanje kvarova kako bi se osiguralo da vaši sustavi mogu podnijeti haos bez ometanja usluge krajnjim kupcima. A da biste to postigli, potrebna vam je sposobnost da simulirate promet sličan proizvodnji u testnim okruženjima.
Naravno, dobra je ideja testirati otpornost prije nego što se izmjene uvedu u proizvodnju. Ako to ne učinite, nećete moći provjeriti podržavaju li vaše usluge i prosječna i najveća opterećenja. Zapravo, najsigurnija opklada je osigurati da vaš proizvod može izdržati do dvostruko najvećeg iznosa bez potrebe za povećanjem.
Kad je u pitanju testiranje otpornosti, pravi alati ne bi se trebali previše zabrinjavati kako se rješavaju zahtjevi, samo što na kraju imaju ispravan utjecaj. Zapamtite da pod određenim uvjetima ulazna usluga ne može predati zahtjev ostatku sustava, ali ne prijavi kvar. Ne rizikujte s problemima letenja ispod radara nadgledanja tako da provjerite da li se zapravo događa krajnja provjera valjanosti. (Za više, pogledajte Tehničke pogreške: Možemo li živjeti s njima?)
Sljedeći koraci
Nakon što shvatite kako se usluge ponašaju pod opterećenjem, vrijeme je da počnete uvoditi događaje neuspjeha. Kao i kod svih testiranja softvera, najbolje je imati automatizirane alate koji omogućuju lako i brzo reproduciranje scenarija kako biste mogli koordinirati složene događaje koji utječu na različite infrastrukturne tehnologije. A osim mogućnosti provjere ispravka i promjena u uslugama, ovo vam omogućuje pokretanje slučajnih scenarija neuspjeha u bilo kojem okruženju i na rasporedu.
Značajni događaji neuspjeha uvelike ovise o rasporedu vaših usluga, a možete ih formulirati postavljanjem određenih pitanja koja su relevantna za vas. Na primjer, kakav je utjecaj na ljude koji koriste napredne uređaje kada baza podataka postane nedostupna za određeno vremensko razdoblje? Mogu li ti korisnici još uvijek kretati putem korisničkog sučelja? Mogu li i dalje izdavati ažuriranja svojih podataka i hoće li ta ažuriranja biti ispravno obrađena kada baza podataka ponovno postane dostupna?
Ako pokrenete više mikroservisa, možete se zapitati hoće li doći do globalnog prekida ako se padne neka pojedinačna usluga. Ili ako imate mehanizam čekanja za međusobno usklađivanje komunikacije između usluga, što se događa kada potrošačke usluge (ili usluge) prestanu raditi? Hoće li korisnici i dalje moći raditi s vašom aplikacijom? A s obzirom na prosječno opterećenje, koliko vremena imate prije nego što se redovi preplave i počnete gubiti s?
Bez grešaka, bez stresa - Vaš korak po korak vodič za stvaranje softvera koji mijenja život bez uništavanja života
Ne možete poboljšati svoje programiranje kad nikoga nije briga za kvalitetu softvera.
Nakon što definirate nekoliko ključnih pitanja o svojoj infrastrukturi, možete početi nabrajati različite načine za simulaciju tih kvarova. Možda će biti dovoljno za zaustavljanje određene usluge ili poslužitelja baze podataka. Možda želite blokirati glavni nit usluge da simulira mrtvu bravu, dok je njezin spremnik i dalje reagiran i pokrenut. Možda biste odlučili uvesti pravila u svoju mrežu kako biste blokirali promet između određenih usluga. U Linux okruženjima možete koristiti alate poput „tc“ za oponašanje mrežnih situacija poput visokog kašnjenja, ispuštenih, oštećenih ili dupliciranih paketa. (Može biti važno uključiti korisnike u testiranje. Pročitajte više u 4 razloga zašto krajnji korisnici trebaju sudjelovati u testiranju prije UAT-a.)
Učenje i poboljšavanje vježbama
Jedan od najvrjednijih aspekata stvaranja scenarija neuspjeha jest taj što oni mogu razotkriti sve potencijalne načine na koje sustav može uspjeti, a na taj način urezati put do logike samoizlječenja. Vaš će tim postupkom proći korake za ručno vraćanje usluga - uzgred, odlična vježba za potvrdu da su u stanju to učiniti u SLA-ima. Automatizacija ovog postupka oporavka može se raditi, ali u međuvremenu se možete odmoriti znajući da je vaš tim prošao kroz proces vraćanja usluga na pravi put. Čineći slučajne i redovite scenarije neuspjeha i ne otkrivajući sve detalje trčanja, u vježbu možete uključiti i otkriće i dijagnoze - što je, uostalom, i kritični dio SLA-a.
U svojoj srži, inženjering kaosa uzima složenost sustava kao zadatka, testira ga simulirajući nove i otkačene uvjete i promatra kako sustav reagira. Ovo su timovi za inženjering podataka trebali redizajnirati i rekonfigurirati sustav kako bi postigli veću otpornost. Postoji toliko mnogo mogućnosti za učenje novih i korisnih stvari. Na primjer, možete pronaći slučajeve u kojima usluge ne dobivaju ažuriranja kada su se promijenile usluge niže razine ili područja u kojima potpuno nedostaje nadzor. Ne nedostaje uzbudljivih načina da svoj proizvod učinite elastičnijim i robusnijim!