Vsebina
- Priprava na neuspeh
- Naslednji koraki
- Brez napak, brez stresa - vaš korak za korakom vodnik za ustvarjanje programske opreme, ki spreminja življenje, ne da bi vam uničila življenje
- Učenje in izboljšanje s pomočjo vaj
Vir: pressureUA / iStockphoto
Odvzem:
Sodobni sistemi morajo biti sposobni obvladovati kaos, da se izognemo izpadom. Zato je bolj kot kdaj koli prej pomembno, da temeljito preizkusite sisteme in zagotovite njihovo odpornost.
Kljub našim največjim prizadevanjem, da se jih izognemo, so incidenti na področju IT neizogiben del dela - in poskušati ostati pred izpadi, ki vplivajo na poslovanje, postaja le bolj zapleteno. Sistemi so danes tesno povezani in vse bolj zapleteni, z več gibljivimi deli pa pride več priložnosti, da bi šlo narobe.
To je eden od razlogov, da se vse več organizacij za večjo razpoložljivost storitev in večjo odpornost na napake obrača na mikroservise. Kljub temu, da so to odlični prostori za razbijanje monolitnih aplikacij, lahko tudi tvegajo neuspeh - razen če so izrecno zasnovani z odpornostjo.
Priprava na neuspeh
Glede na prirojeno kaotičnost porazdeljenih sistemov bi bilo treba storitve razviti ne le za predvidevanje okvare, temveč za samodejno izterjavo v primeru okvare. To pomeni redno sprožanje napak, s čimer zagotovite, da lahko vaši sistemi obvladajo kaos, ne da bi motili storitve končnim kupcem. Da bi to dosegli, potrebujete sposobnost simulacije prometno podobnega prometa v testnih okoljih.
Seveda je dobro, da preizkusite odpornost, preden spremembe povzročijo proizvodnjo. Če tega ne storite, ne boste mogli preveriti, ali lahko vaše storitve podpirajo povprečno in največjo obremenitev. Pravzaprav je najvarnejša stava zagotoviti, da lahko vaš izdelek prenese do dvakrat največjega zneska, ne da bi ga bilo treba povečati.
Ko gre za testiranje odpornosti, se s pravimi orodji ne sme preveč skrbeti, kako se obravnavajo zahteve, le da bodo na koncu imeli pravi učinek. Ne pozabite, da pod določenimi pogoji vhodna storitev ne bo poslala zahteve preostalem sistemu, vendar ne bo prijavila napake. Ne tvegajte vprašanj, ki letijo pod radarjem spremljanja in se prepričajte, da se dejansko preverjanje dejansko izvaja. (Če želite več, glejte Tehnične napake: Ali lahko živimo z njimi?)
Naslednji koraki
Ko razumemo, kako se storitve obnašajo pod obremenitvijo, je čas, da začnemo uvajati dogodke napak. Kot pri vseh testiranjih programske opreme je tudi najbolje imeti avtomatizirana orodja, ki vam omogočajo enostavno in hitro reproduciranje scenarijev, tako da lahko koordinirate zapletene dogodke, ki vplivajo na različne infrastrukturne tehnologije. To pa poleg možnosti preverjanja popravkov in sprememb v storitvah omogoča zagon scenarijev naključnih napak v katerem koli okolju in po urniku.
Pomembni dogodki odpovedi so v veliki meri odvisni od postavitve vaših storitev in jih lahko oblikujete tako, da postavite posebna vprašanja, ki so za vas pomembna. Na primer, kakšen je vpliv na ljudi, ki uporabljajo prednji del, ko baza podatkov v določenem obdobju postane nedosegljiva? Ali lahko ti uporabniki še vedno krmarijo po uporabniškem vmesniku? Ali lahko še vedno izdajajo posodobitve svojih podatkov in ali bodo te posodobitve pravilno obdelane, ko bo baza podatkov ponovno dosegljiva?
Če imate več mikroservisov, se lahko vprašate, ali bo prišlo do globalnega izpada, če se bo posamezna storitev zrušila. Ali če imate čakalni mehanizem za varovanje komunikacije med storitvami, kaj se zgodi, ko potrošniška storitev (ali storitve) prenehajo delovati? Ali bodo uporabniki še vedno lahko delali z vašo aplikacijo? In glede na povprečno obremenitev, koliko časa imate preden se čakalne vrste preplavijo in začnete izgubljati?
Brez napak, brez stresa - vaš korak za korakom vodnik za ustvarjanje programske opreme, ki spreminja življenje, ne da bi vam uničila življenje
Ne morete izboljšati svojih programskih veščin, kadar nikogar ne skrbi za kakovost programske opreme.
Ko določite nekaj ključnih vprašanj o svoji infrastrukturi, lahko začnete navajati različne načine za simuliranje teh napak. Morda bi bilo dovolj, da ustavite določeno storitev ali strežnik baz podatkov. Morda boste želeli blokirati glavno nit storitve za simulacijo mrtvega zaklepa, medtem ko je njegov vsebnik še vedno odziven in deluje. Odločili se boste, da boste v svoje omrežje uvedli pravila za blokiranje prometa med določenimi storitvami. V okoljih Linux lahko z orodji, kot je 'tc', posnemate omrežne situacije, kot so velike zamude, padli, poškodovani ali podvojeni paketi. (Pomembno je vključiti uporabnike v testiranje. Preberite več v 4 razlogih, zakaj morajo končni uporabniki sodelovati pri testiranju pred UAT.)
Učenje in izboljšanje s pomočjo vaj
Eden najdragocenejših vidikov ustvarjanja scenarijev neuspeha je, da lahko razkrijejo vse možne načine, da sistem lahko odpove in s tem izberejo pot do samozdravilne logike. Vaša ekipa bo šla skozi korake za ročno obnavljanje storitev - mimogrede, odlična vaja za potrditev, da to lahko storijo v okviru SLA. Avtomatizacijo tega obnovitvenega procesa je mogoče nadaljevati, vmes pa se lahko sprostite in veste, da je vaša ekipa sprejela postopek vračanja storitev. Če naključne in redne scenarije napak in ne razkrijete vseh podrobnosti teka, lahko vaji vključite tudi odkrivanje in diagnoze - kar je navsezadnje kritični del SLA.
V bistvu inženiring kaosa jemlje kompleksnost sistema kot danost, preizkuša ga s simulacijo novih in čudaških pogojev in opazuje, kako se sistem odziva. To je, da morajo ekipe za inženiring preoblikovati in ponovno konfigurirati sistem, da dosežejo večjo odpornost. Obstaja toliko možnosti za učenje novih in koristnih stvari. Na primer, lahko najdete primere, ko storitve ne dobivajo posodobitev, ko so se storitve nižje spremenile, ali področja, kjer nadzor v celoti manjka. Navdušujočih načinov, kako narediti svoj izdelek bolj prožen in robusten, ne manjka!