Obsah
- Príprava na zlyhanie
- Ďalšie kroky
- Žiadne chyby, žiadny stres - Váš sprievodca krok za krokom k vytvoreniu softvéru na zmenu života bez zničenia vášho života
- Učenie a zlepšovanie prostredníctvom cvičení
Zdroj: pressureUA / iStockphoto
Zobrať:
Moderné systémy musia byť schopné zvládnuť chaos, aby sa predišlo výpadkom. Preto je dôležitejšie ako kedykoľvek predtým dôkladne testovať systémy a zabezpečiť ich odolnosť.
Napriek nášmu najväčšiemu úsiliu sa im vyhnúť, IT incidenty sú neoddeliteľnou súčasťou práce - a snaha udržať si náskok pred výpadkami, ktoré majú dosah na podnikanie, je len zložitejšia. Systémy sú dnes pevne spojené a stále zložitejšie a s pohyblivejšími časťami prichádzajú ďalšie príležitosti, aby sa veci pokazili.
To je jeden z dôvodov, prečo sa čoraz viac organizácií obracia na mikroservisy kvôli zvýšenej dostupnosti služieb a lepšej odolnosti voči zlyhaniu. Aj keď sú to vynikajúce priestory na prerušenie monolitických aplikácií, môžu tiež potenciálne zvyšovať riziko zlyhania - pokiaľ nie sú navrhnuté výslovne s ohľadom na odolnosť.
Príprava na zlyhanie
Vzhľadom na podstatu chaotickej povahy distribuovaných systémov by sa služby nemali vyvíjať len na predvídanie zlyhania, ale v prípade zlyhania by sa mali automaticky obnovovať. To znamená pravidelné spúšťanie porúch, aby sa zabezpečilo, že vaše systémy dokážu zvládnuť chaos bez prerušenia služieb koncovým zákazníkom. A na dosiahnutie tohto cieľa potrebujete schopnosť simulovať produkciu podobnú prevádzke v testovacích prostrediach.
Je samozrejme dobré vyskúšať odolnosť skôr, ako dôjde k zmenám vo výrobe. Ak to neurobíte, nebudete môcť overiť, či vaše služby dokážu podporovať priemerné aj špičkové zaťaženie. V skutočnosti je najbezpečnejšou stávkou to, že váš produkt zvládne až dvojnásobok maximálnej sumy bez toho, aby sa musel zväčšovať.
Pokiaľ ide o testovanie odolnosti, správne nástroje by nemali byť príliš znepokojené tým, ako sa vybavujú žiadosti, ale len to, že nakoniec majú správny vplyv. Nezabudnite, že za určitých podmienok môže vstupná služba zlyhať pri odovzdaní žiadosti zvyšku systému, ale ohlásiť chybu. Neriskujte problémy, ktoré letí pod radarom monitorovania tým, že sa ubezpečíte, že dôjde ku konečnému overeniu. (Viac informácií nájdete v časti Technické zlyhania: Môžeme s nimi žiť?)
Ďalšie kroky
Po pochopení, ako sa služby správajú pri zaťažení, je čas začať zavádzať udalosti zlyhania. Rovnako ako pri všetkých testoch softvéru je najlepšie mať k dispozícii automatizované nástroje, ktoré vám umožňujú ľahko a rýchlo reprodukovať scenáre, takže môžete koordinovať zložité udalosti, ktoré majú vplyv na rôzne technológie infraštruktúry. Okrem možnosti overovať opravy a zmeny služieb vám to umožňuje spúšťať scenáre náhodných zlyhaní v akomkoľvek prostredí a podľa plánu.
Zmysluplné udalosti zlyhania do veľkej miery závisia od usporiadania vašich služieb a môžete ich formulovať kladením konkrétnych otázok, ktoré sa vás týkajú. Aký je napríklad dopad na ľudí, ktorí používajú klientske rozhranie, keď sa databáza na určitý čas stane nedostupnou? Môžu títo používatelia stále prechádzať webovým používateľským rozhraním? Môžu stále vydávať aktualizácie svojich informácií a budú tieto aktualizácie spracované správne, keď bude databáza opäť dostupná?
Ak prevádzkujete viacero mikroprocesov, môžete sa opýtať, či dôjde k globálnemu výpadku v prípade zlyhania jednotlivých služieb. Alebo ak máte mechanizmus na radenie do vyrovnávacej pamäte na komunikáciu medzi službami, čo sa stane, keď zákaznícke služby (alebo služby) prestanú fungovať? Budú používatelia naďalej schopní pracovať s vašou aplikáciou? A pri priemernom zaťažení, ako dlho máte pred pretečením front a začnete strácať?
Žiadne chyby, žiadny stres - Váš sprievodca krok za krokom k vytvoreniu softvéru na zmenu života bez zničenia vášho života
Svoje programovacie schopnosti si nemôžete vylepšiť, keď sa nikto nestará o kvalitu softvéru.
Po definovaní niekoľkých kľúčových otázok týkajúcich sa vašej infraštruktúry môžete začať s uvádzaním rôznych spôsobov simulácie týchto zlyhaní. Stačí zastaviť konkrétnu službu alebo databázový server. Možno budete chcieť zablokovať hlavné vlákno služby, aby ste simulovali zablokovanie, zatiaľ čo jeho kontajner stále reaguje a beží. Môžete sa rozhodnúť zaviesť pravidlá vo svojej sieti na zablokovanie prenosu medzi konkrétnymi službami. V prostrediach Linuxu môžete na emuláciu sieťových situácií, ako je vysoká latencia, stratené, poškodené alebo duplikované pakety, použiť nástroje ako „tc“. (Môže byť dôležité zapojiť používateľov do testovania. Prečítajte si viac v 4 Dôvodoch, prečo sa koncoví používatelia musia zúčastniť testovania pred testom UAT.)
Učenie a zlepšovanie prostredníctvom cvičení
Jedným z najcennejších aspektov vytvárania scenárov zlyhania je to, že môžu odhaliť všetky potenciálne spôsoby, ktoré systém môže zlyhať, a tak vyrezávať cestu k samoliečiteľskej logike. Váš tím absolvuje kroky na manuálne obnovenie služieb - mimochodom, skvelý výcvik na potvrdenie, že sú schopní urobiť to v rámci SLA. Na automatizácii tohto procesu obnovy sa dá pracovať, ale medzitým si môžete pokojne uvedomiť, že váš tím prešiel procesom návratu služieb naspäť. Vytvorením náhodných a pravidelných scenárov zlyhania a nezverejnením všetkých podrobností o spustení môžete do vŕtačky zahrnúť aj odhalenie a diagnostiku - čo je koniec koncov kritická súčasť SLA.
Inžinierstvo chaosu vo svojom jadre berie zložitosť systému ako danú, otestuje ho simuláciou nových a šialených podmienok a sleduje, ako systém reaguje. Jedná sa o tímy dátového inžinierstva, ktoré musia prepracovať a prekonfigurovať systém, aby sa dosiahla vyššia odolnosť. Existuje toľko príležitostí naučiť sa nové a užitočné veci. Môžete napríklad nájsť prípady, keď služby nezískavajú aktualizácie, keď sa zmenili nadväzujúce služby, alebo oblasti, v ktorých monitorovanie úplne chýba. Neexistuje nedostatok zaujímavých spôsobov, ako zvýšiť odolnosť a odolnosť vášho produktu!