A shift-right tesztelésének megismerása
A tanfolyam korábbi részében leírtak szerint az alkalmazás életciklus-felügyeletének tesztelése elengedhetetlen a kódminőség maximalizálásához és a szoftverek üzembe helyezésével és frissítésével járó működési kockázatok minimalizálásához. Ez az oka a balra tolódásos megközelítés alkalmazásának, amely a fejlesztési fázisban a lehető leghamarabb bevezeti a tesztelési tevékenységeket. Vannak azonban a tesztelés bizonyos aspektusai, amelyek nem hatékonyak, ha ilyen módon hajtják végre. Ehelyett, hogy megfelelően elérjék a céljukat, a termelési környezetben kell elvégezni őket. Ezt shift-right megközelítésnek nevezzük. A mintaforgatókönyvben szereplő szervezetnek ezt kell használnia annak érdekében, hogy a rendszer megbízhatóságát hibainjektálással együtt megfelelően értékelje. Ebben a leckében vizsgálja meg ezt és az egyéb kritériumokat, amelyek alapján a jobbra eltolódó tesztelés indokolt.
Mik a shift-right tesztelés okai?
Bár a balra tolásos tesztelés ideális az egység- és füsttesztelésre, mégis olyan körülmények között végezzük, amelyek jellemzően jelentősen eltérnek a tervezett kézbesítési célokhoz tartozó körülményektől. Még a minőségbiztosítási és a tesztkörnyezetek is ritkán tükrözik teljes mértékben produkciós társaik összetettségét. A számítási feladatok üzembe helyezés utáni viselkedésének teljes körű vizsgálatának leghatékonyabb módja az, ha ezen a ponton teszteli azt.
Az éles tesztelés a következő előnyöket nyújtja:
- A tényleges munkakörülményeket tükrözi, beleértve a végfelhasználói kérések kezeléséhez kapcsolódó többletterhelést is.
- Figyelembe veszi azokat a tényezőket, amelyeket nehéz lenne szimulálni, például a külső rendszerekhez való kapcsolódást.
- A számítási feladatok igényének időbeli változásait tükrözi.
Melyek a tipikus shift-right tesztelési forgatókönyvek?
Bár a shift-right tesztelési megközelítés számos esetben indokolt lehet, kevés olyan van, ahol valóban megfelelő. Ezek a forgatókönyvek a következők:
Mikroszolgáltatások üzemelő példányai: a mikroszolgáltatás-architektúra általában nagy számú egymástól független fejlesztésű összetevőből áll. Ezeknek a szolgáltatásoknak a sokféle kombinációja indokolhatja a tesztelés eltolását jobbra, hogy a tényleges éles környezetben leginkább releváns forgatókönyvekre összpontosítsanak, figyelembe véve azok valós használatát.
A hálózati sávszélesség és a késési feltételek hatásának kiértékelése: a hálózati feltételek általában kihívást jelentenek a szimulálás során, így ha egy számítási feladat teljesítménye nagy késéssel vagy sávszélesség-függő, akkor a váltási jobb oldali tesztelés lehet a legmegfelelőbb megoldás.
Felhasználói elfogadás tesztelése: a felhasználók tényleges visszajelzése elengedhetetlen lehet a számítási feladat teljesítményének és használhatóságának ellenőrzéséhez.
Az ellenőrzési feladatátvételi eljárások redundáns konfigurációkban: a hibainjektálás és a vészhelyreállítási tesztelés az éles számítási feladatok rugalmasságának felmérésére szolgál. A hibainjektálás során szándékosan vezetnek be hibákat a számítási feladatok egyes összetevőibe annak végrehajtása során annak érdekében, hogy azonosítsák a hiányosságokat, és mérsékeljék azokat, növelve az általános megbízhatóságot.
Jegyzet
A chaos engineering a DevOps megbízhatósági tesztelésének egy másik fogalma. A hibainjektáláshoz hasonlóan ez is magában foglalja a hibák szimulálását (ebben az esetben, hogy szabályozott káoszt hozzon létre a tesztelt rendszerben). Hatóköre azonban általában szélesebb, és nem csak az egyes összetevőkre, hanem a teljes rendszerre irányul, és a tesztelési forgatókönyvek általában átfogóbbak. A káosz-tervezés általában olyan kanári környezetekre korlátozódik, amelyek nagyon korlátozottak vagy nincsenek éles hatással.
Jegyzet
Az Azure Chaos Studio használatával olyan káoszmérnöki kísérleteket valósíthat meg, amelyek a Microsoft Azure-ban üzemeltetett megoldásokat célják. Ebben a modulban lépésről lépésre végigvezetik egy ilyen kísérlet példáján.