Tartalom
- Felkészülés a kudarcra
- A következő lépések
- Nincsenek hibák, nincs stressz - Az Ön életét megváltoztató szoftverek készítésének lépésről lépésre történő leírása az élet megsemmisítése nélkül
- Tanulás és fejlesztés gyakorlatok segítségével
Forrás: pressureUA / iStockphoto
Elvitel:
A modern rendszereknek képesnek kell lenniük a káosz kezelésére az állásidő elkerülése érdekében. Ezért fontos, mint valaha, a rendszerek alapos tesztelése és ellenálló képességük biztosítása.
Annak elkerülése érdekében tett legnagyobb erőfeszítéseink ellenére, hogy az informatikai események elkerülhetetlenek a munka részéhez - és az üzleti befolyásoló leállások előtti próbálkozás csak trükkösebbé válik. A rendszerek ma szorosan összekapcsolódtak és egyre összetettebbek, és a mozgó alkatrészekkel együtt több lehetőséget kínál a dolgok rosszra fordulására.
Ez az egyik oka annak, hogy egyre több szervezet fordul a mikroszolgáltatásokhoz a jobb szolgáltatások elérhetősége és a kudarchoz való jobb ellenálló képesség érdekében. De noha ezek kiválóan alkalmasak a monolitikus alkalmazások megsemmisítésére, potenciálisan felvehetik a kudarc kockázatát is - kivéve, ha kifejezetten a rugalmassággal szem előtt tartva tervezik őket.
Felkészülés a kudarcra
Az elosztott rendszerek természetéből adódóan kaotikus jellegére tekintettel a szolgáltatásokat nemcsak a hiba előrejelzésére, hanem a hiba automatikus elősegítésére is ki kell fejleszteni. Ez azt jelenti, hogy rendszeresen kezdeményeznek hibákat annak biztosítása érdekében, hogy rendszerei kezelni tudják a káoszt anélkül, hogy megszakítanák a végfelhasználói szolgáltatást. És ennek eléréséhez képesnek kell lennie a termeléshez hasonló forgalom szimulálására a tesztkörnyezetekben.
Természetesen érdemes kipróbálni az ellenálló képességet, mielőtt a változtatások a termelésbe változnának. Ha nem ezt teszi meg, akkor nem tudja ellenőrizni, hogy szolgáltatásai támogatják-e az átlagos és a csúcsterhelést is. Valójában a legbiztosabb tét annak biztosítása, hogy a termék a csúcsérték akár kétszeresét képes kezelni anélkül, hogy méretarányos lenne.
A rugalmasság tesztelésekor a megfelelő eszközöknek nem szabad túlzottan aggódniuk a kérelmek kezelésének módja iránt, csak hogy a végső soron a megfelelő hatásuk legyen. Ne feledje, hogy bizonyos körülmények között az input szolgáltatás nem tud átadni egy kérést a rendszer többi részének, de nem jelentheti be a hibát. Ne kockáztasson olyan kérdéseket, amelyek a felügyeleti radar alatt repülnek, ügyelve arra, hogy a végpontok közötti érvényesítés valóban megtörténjen. (További információ: Technikai hibák: Mi élhetünk velük?)
A következő lépések
Miután megértette, hogyan viselkednek a szolgáltatások terhelés alatt, ideje elkezdeni bemutatni a hibaeseményeket. Mint minden szoftver tesztelésnél, a legjobb, ha vannak olyan automatizált eszközök, amelyek lehetővé teszik a forgatókönyvek egyszerű és gyors reprodukálását, hogy összehangolt eseményeket koordinálhassanak, amelyek befolyásolják a különböző infrastrukturális technológiákat. A szolgáltatások javításainak és változásainak ellenőrzésén túl ez lehetővé teszi véletlenszerű hibaforgatókönyvek futtatását bármilyen környezetben és ütemezés szerint.
A jelentõs hibaesemények nagymértékben függnek a szolgáltatások elrendezésétõl, és megfogalmazhatja azokat az Ön számára releváns konkrét kérdések megfogalmazásával. Például, hogyan befolyásolja az elülső résztvevőket az emberek, amikor egy adatbázis egy bizonyos ideig elérhetetlenné válik? E felhasználók továbbra is navigálhatnak az internetes felhasználói felületen? Még mindig frissíthetnek információkat, és ezeket a frissítéseket megfelelően feldolgozzák-e, amikor az adatbázis ismét elérhetővé válik?
Több mikroszolgáltatás futtatásakor megkérdezheti, hogy lesz-e globális leállás, ha valamelyik szolgáltatás összeomlik. Vagy ha van egy sorba állító mechanizmus, amely pufferolja a szolgáltatások közötti kommunikációt, mi történik, ha a fogyasztói szolgáltatás (vagy szolgáltatások) nem működik? A felhasználók továbbra is képesek lesznek dolgozni az alkalmazásoddal? És egy átlagos terhelés alapján mennyi ideig van, mielőtt a sorok túlcsordulnak, és elkezdesz veszíteni?
Nincsenek hibák, nincs stressz - Az Ön életét megváltoztató szoftverek készítésének lépésről lépésre történő leírása az élet megsemmisítése nélkül
Nem javíthatja a programozási képességeit, ha senki sem törődik a szoftver minőségével.
Miután meghatározta az infrastruktúrával kapcsolatos néhány kulcskérdést, elkezdheti felsorolni a hibák szimulálásának különféle módjait. Elég lehet egy adott szolgáltatás vagy adatbázis-kiszolgáló leállításához. Lehet, hogy blokkolja a szolgáltatás fonalat a holtpontok szimulálására, miközben a tárolója továbbra is érzékeny és fut. Dönthet úgy, hogy szabályokat vezet be a hálózatában az egyes szolgáltatások közötti forgalom blokkolására. Linux környezetben olyan eszközöket használhat, mint a „tc”, hogy olyan hálózati helyzeteket emuláljon, mint például a nagy késés, leesett, sérült vagy duplikált csomagok. (Fontos lehet a felhasználók bevonása a tesztelésbe. Bővebben a 4-es okból, hogy a végfelhasználóknak miért kell részt venniük a tesztelésben az UAT előtt.)
Tanulás és fejlesztés gyakorlatok segítségével
A hibaforgatókönyvek létrehozásának egyik legértékesebb aspektusa az, hogy feltárják az összes lehetséges módot, amellyel a rendszer megbukhat, ezáltal meghúzva az öngyógyító logika felé vezető utat. A csapata végigmegy a szolgáltatások manuális helyreállításának lépésein - egyébként nagyszerű gyakorlat, amely megerősíti, hogy képesek ezt megtenni az SLA-kban. Ennek a helyreállítási folyamatnak az automatizálása tovább működhet, de időközben könnyedén pihenhet, tudva, hogy csapata végigjárta a szolgáltatások helyreállításának folyamatát. Ha a hibaforgatókönyveket véletlenszerűnek és rendszeresnek teszi, és nem teszi közzé a futás teljes részletét, felfedezéseket és diagnóziseket is belefoglalhat a fúrógépbe - ami végül is az SLA kritikus része.
Alapjában véve a káoszmérnök a rendszer komplexitását adottnak tekinti, új és szokatlan körülmények szimulálásával teszteli és megfigyeli, hogy a rendszer hogyan reagál. Ez az adatmérnöki csapatok számára a nagyobb rugalmasság elérése érdekében a rendszer újratervezése és újrakonfigurálása. Olyan sok lehetőség van új és hasznos dolgok megtanulására. Előfordulhat például, hogy a szolgáltatások nem kapnak frissítést, amikor a későbbi szolgáltatások megváltoztak, vagy olyan területeken, ahol a megfigyelés hiányzik. Nem hiányzik izgalmas módja annak, hogy a terméket rugalmasabbá és robusztusabbá tegye!