Megosztás a következőn keresztül:

Javaslatok üzembehelyezési hibák elhárítására szolgáló stratégia kialakításához

  • Cikk

Az Azure Well-Architected Framework működési kiválósági ellenőrzőlistájára vonatkozó javaslatra vonatkozik:

OE:12 Implementáljon egy üzembehelyezési hibacsökkentési stratégiát, amely a gyors helyreállítással kapcsolatos váratlan bevezetési problémákat oldja meg. Kombináljon több módszert, például a visszaállítást, a funkció letiltását vagy az üzembehelyezési minta natív képességeinek használatát.

Ez az útmutató az üzembehelyezési hibák hatékony kezelésére szolgáló szabványosított stratégia kialakítására vonatkozó javaslatokat ismerteti. A számítási feladatok egyéb problémáihoz hasonlóan az üzembehelyezési hibák is elkerülhetetlen részét képezik a számítási feladatok életciklusának. Ezzel a szemlélettel proaktív lehet, ha egy jól megtervezett, szándékos stratégiát alkalmaz az üzembehelyezési hibák kezelésére. Egy ilyen stratégia lehetővé teszi, hogy a számítási feladatokért felelős csapat a lehető legkisebb hatással legyen a végfelhasználókra gyakorolt lehető legkisebb hatással a hibák elhárítására.

Egy ilyen terv hiánya kaotikus és potenciálisan káros válaszokat eredményezhet a problémákra, ami jelentősen befolyásolhatja a csapat- és szervezeti kohéziót, az ügyfelek bizalmát és a pénzügyeket.

Kulcsfontosságú tervezési stratégiák

A fejlesztési gyakorlatok érettsége ellenére időnként üzembehelyezési problémák lépnek fel. A biztonságos üzembehelyezési eljárások és a robusztus számításifeladat-ellátási lánc használata segíthet minimalizálni a sikertelen üzembe helyezések gyakoriságát. Emellett szabványosított stratégiát is ki kell terveznie a sikertelen üzembe helyezések kezelésére, amikor azok történnek.

Ha egy progresszív expozíciós üzembehelyezési modellt használ szokásos gyakorlatként:

  • Megfelelő alapokkal rendelkezik az ügyfelekre vagy belső felhasználókra gyakorolt hatások minimalizálására az üzembe helyezés meghiúsulása esetén.
  • A problémákat hatékonyan kezelheti.

Az üzembehelyezési hibák elhárítására vonatkozó stratégia öt átfogó fázisból áll:

  1. Észlelés: A sikertelen üzembe helyezésre való válaszadáshoz először észlelnie kell a hibát. Az észlelésnek számos formája lehet, például a sikertelen füsttesztek, a felhasználó által jelentett problémák vagy a monitorozási platform által generált riasztások.

  2. Döntés: El kell döntenie, hogy melyik a legjobb kockázatcsökkentési stratégia az adott hibatípushoz.

  3. Kockázatcsökkentés: Végrehajtja az azonosított kockázatcsökkentési műveletet. A kockázatcsökkentés lehet tartalék, visszaállítási, visszaállítási, visszaállítási vagy futtatókörnyezeti konfiguráció használata a jogsértő függvény megkerüléséhez.

  4. Kommunikáció: Az érintetteknek és az érintett végfelhasználóknak tisztában kell lenniük a probléma észlelésekor és a probléma megoldásában a vészhelyzeti reagálási terv által megkövetelt állapottal.

  5. Postmortem: A hibás postmortemek lehetőséget biztosítanak a számítási feladatokért felelős csapat számára, hogy azonosítsák a fejlesztési területeket, és terveket hozzanak létre a tanulás alkalmazásához.

A következő szakaszok részletes javaslatokat nyújtanak ezekre a fázisokra vonatkozóan. Ezek a szakaszok feltételezik, hogy a módosítások egy vagy több felhasználói vagy rendszercsoportra való telepítése után, de a bevezetési tervben szereplő összes csoport frissítése előtt észleli a problémát.

Észlelés

Az üzembe helyezésekkel kapcsolatos problémák gyors azonosításához robusztus tesztelési és megfigyelhetőségi eljárásokra van szükség, amelyek az üzemelő példányokhoz kapcsolódnak. Az anomáliák gyors észlelésének elősegítése érdekében az alábbi lépések végrehajtásával kiegészítheti a számítási feladatok monitorozását és riasztását:

  • Használjon alkalmazásteljesítmény-kezelő eszközt.
  • Naplózás engedélyezése a rendszerállapoton keresztül.

A füsttesztelésnek és más minőségtesztelésnek a bevezetés minden fázisában meg kell történnie. Az egyik üzembehelyezési csoport sikeres tesztjei nem befolyásolhatják a későbbi csoportokban való teszteléssel kapcsolatos döntéseket.

Implementálhat olyan telemetriát, amely korrelálja a felhasználói problémákat egy üzembe helyezési fázissal. Ezután gyorsan azonosíthatja, hogy egy adott felhasználó melyik bevezetési csoporthoz van társítva. Ez a megközelítés különösen fontos a progresszív expozíciós üzemelő példányok esetében, mivel előfordulhat, hogy az üzembe helyezés bármely pontján több konfiguráció fut a felhasználói bázison.

Készen kell állnia arra, hogy azonnal reagáljon a felhasználók által jelentett problémákra. Amikor gyakorlatias, üzembe helyezheti a bevezetési fázist munkaidőben, amikor teljes körű támogatási csapat áll rendelkezésre. Győződjön meg arról, hogy a támogatási személyzet betanított az üzembehelyezési problémák eszkalálására a megfelelő útválasztáshoz. Az eszkalációknak igazodnia kell a számítási feladat vészhelyzeti reagálási tervéhez.

Döntés

Egy adott üzembe helyezési probléma megfelelő kockázatcsökkentési stratégiájának meghatározása számos tényező figyelembevételével jár, beleértve a következőket:

  • A használt progresszív expozíciós modell típusa. Használhat például kék-zöld vagy kanári modellt.

    Ha kék-zöld modellt használ, a visszaesés praktikusabb, mint a visszagördülés. A forgalmat könnyedén visszateheti a nem frissített konfigurációt futtató verembe. Ezután kijavíthatja a problémát a problémás környezetben, és a megfelelő időben újra megpróbálhatja az üzembe helyezést.

  • A probléma megkerüléséhez rendelkezésre álló módszerek. Ilyenek például a funkciójelölők, környezeti változók vagy bármilyen más típusú futásidejű konfigurációs tulajdonság használata, amelyet be- és kikapcsolhat.

    Néha egyszerűen megkerülheti a problémát egy funkciójelölő kikapcsolásával vagy egy beállítás összesítésével. Ebben az esetben a következőket teheti:

    • Folytassa a bevezetést.
    • Kerülje a visszaesést.
    • A jogsértő kód kijavítása közben térjen vissza.

  • A javítás kódban való implementálásához szükséges erőfeszítés szintje.

    Ha a kód javításához szükséges munka szintje alacsony, a gyakori elérésű javítás implementálásával történő továbbgördülés bizonyos forgatókönyvek esetén a megfelelő választás.

  • Az érintett számítási feladat kritikussági szintje.

    Az üzletileg kritikus számítási feladatokat mindig egymás mellett kell üzembe helyezni, például egy kék-zöld modellben, hogy nulla állásidős üzembe helyezést lehessen elérni. Ennek eredményeképpen az ilyen típusú számítási feladatok esetében a visszaesés az előnyben részesíthető kockázatcsökkentési stratégia.

  • A számítási feladat által használt infrastruktúra típusa – módosítható vagy nem módosítható.

    Ha a számítási feladatát úgy tervezték, hogy használjon módosítható infrastruktúrát, a továbbhaladásnak van értelme, mivel magában foglalja az infrastruktúra frissítését. Ezzel szemben a visszagördülésnek vagy a visszaesésnek van értelme, ha nem módosítható infrastruktúrát használ.

Függetlenül attól, hogy milyen döntéseket hoz, a döntési folyamatba bele kell foglalnia a megfelelő jóváhagyásokat, és kodekálnia kell őket a döntési fában.

Kockázatcsökkentés

  • Visszaállítás: Visszaállítási forgatókönyv esetén visszaállítja a frissített rendszereket az utolsó ismert-jó konfigurációs állapotra.

    Fontos, hogy a teljes számítási feladatért felelős csapat egyetértsen az utolsó ismert jó jelentésével. Ez a kifejezés az üzembe helyezés megkezdése előtt kifogástalan állapotú számítási feladat utolsó állapotára utal, amely nem feltétlenül az alkalmazás korábbi verziója.

    A visszagördülés összetett lehet, különösen az adatváltozásokhoz kapcsolódóan. A sémamódosítások kockázatossá tehetik a visszaállítást. A biztonságos megvalósításuk jelentős tervezést igényelhet. Általános javaslatként a sémafrissítésnek additívnak kell lennie. Nem szabad lecserélni a módosításokat – a rekordokat nem szabad új rekordokra cserélni. Ehelyett a régebbi rekordokat elavultnak kell lenniük, és az új rekordokkal együtt kell létezni, amíg biztonságosan el nem távolítják az elavult rekordokat.

  • Tartalék: Tartalék forgatókönyv esetén a frissített rendszerek el lesznek távolítva az éles forgalom útválasztásából. A rendszer minden forgalmat a nem frissített veremhez irányít. Ez az alacsony kockázatú stratégia lehetővé teszi, hogy további fennakadások nélkül kezelje a kódban szereplő problémákat.

    A kanári üzemelő példányok esetén előfordulhat, hogy az infrastruktúra és az alkalmazás kialakításától függően a visszaesés nem egyszerű vagy akár lehetséges. Ha a nem frissített rendszerek terhelésének kezeléséhez skálázást kell végeznie, a visszalépés előtt végezze el a skálázást.

  • A jogsértő függvény megkerülése: Ha megkerülheti a problémát funkciójelölőkkel vagy más típusú futtatókörnyezet-konfigurációs tulajdonsággal, dönthet úgy, hogy a bevezetés folytatása az adott probléma megfelelő stratégiája.

    Világosan meg kell értenie a függvény megkerülésének kompromisszumát, és képesnek kell lennie arra, hogy ezt a kompromisszumot közölje az érdekelt felekkel. Az érdekelt feleknek jóvá kell hagyniuk az előremutató tervet. Az érdekelt feleknek meg kell határozniuk, hogy mennyi ideig tart a csökkentett teljesítményű állapotban való működés. Ezt a meghatározást a hibás kód kijavításához és üzembe helyezéséhez szükséges idő becslésével is mérlegelniük kell.

  • Vészhelyzeti üzembe helyezés (gyakori elérésű javítás): Ha a bevezetés közepén meg tudja oldani a problémát, a gyakori elérésű javítás lehet a legpraktikusabb megoldási stratégia.

    A többi kódhoz hasonlóan a gyakori elérésű javításokat is át kell járnia a biztonságos üzembehelyezési eljárásokon. A gyakori elérésű javítások azonban jelentősen felgyorsítják az ütemtervet. A környezetekben kód-előléptetési stratégiát kell használnia. Emellett minden minőségi kapunál ellenőriznie kell a gyorsjavítási kódot. Előfordulhat azonban, hogy jelentősen le kell rövidítenie a sütési időt, és előfordulhat, hogy módosítania kell a teszteket a gyorsításukhoz. Győződjön meg arról, hogy az üzembe helyezés után a lehető leghamarabb futtathat teljes teszteket a frissített kódon. A minőségbiztosítási tesztelés magas szintű automatizálásával hatékonyabbá teheti a tesztelést ezekben a forgatókönyvekben.

Kompromisszumok:

  • A visszaesés általában azt jelenti, hogy elegendő infrastruktúra-kapacitásra van szükség a számítási feladatok konfigurációjának két verziójának egyidejű kezeléséhez. A számítási feladatokkal kapcsolatos csapatoknak egyszerre két verziót is támogatniuk kell az éles környezetben.
  • A hatékony visszaállításhoz szükség lehet a számítási feladat elemeinek újrabontására. Előfordulhat például, hogy el kell választania a függvényeket, vagy módosítania kell az adatmodellt.

Kommunikáció

Fontos, hogy egyértelműen meghatározott kommunikációs felelősségekkel rendelkezzenek az incidensek során felmerülő káosz minimalizálása érdekében. Ezeknek a felelősségeknek meg kell határozniuk, hogy a számítási feladatokért felelős csapat hogyan vesz részt a támogatási csapatokkal, az érdekelt felekkel és a vészhelyzet-elhárítási csapat személyzetével, például a vészhelyzet-elhárítási vezetővel.

Szabványosítsa a számítási feladatokért felelős csapat által követett ütemezést az állapotfrissítések biztosításához. Győződjön meg arról, hogy az érdekelt felek tisztában vannak ezzel a szabványval, hogy tudják, mikor várják a frissítéseket.

Ha a számítási feladatért felelős csapatnak közvetlenül a végfelhasználókkal kell kommunikálnia, tisztázza a felhasználókkal való megosztáshoz megfelelő információk típusát és részletességi szintjét. Az ilyen esetekre vonatkozó egyéb követelményeket is közölje a számítási feladatokkal foglalkozó csapattal.

Utólagos elemzés

A postmortem-oknak kivétel nélkül követnie kell az összes sikertelen üzembe helyezést. Minden sikertelen üzembe helyezés tanulási lehetőség. A postmortems segíthet azonosítani az üzembe helyezési és fejlesztési folyamatok gyenge pontjait. Számos egyéb lehetőség mellett az infrastruktúrában is azonosíthatja a helytelen konfigurációkat.

A utómortemeknek mindig oktalannak kell lenniük, hogy az incidensben részt vevő személyek biztonságban érezzék magukat, amikor megosztják véleményüket arról, hogy mit lehet javítani. A postmortem vezetőknek nyomon kell követniük az azonosított fejlesztések megvalósítására vonatkozó terveket, és hozzá kell adni ezeket a terveket a számítási feladatok hátralékához.

Megfontolandó szempontok és általános javaslatok

Győződjön meg arról, hogy az üzembehelyezési folyamat képes elfogadni a különböző verziókat paraméterként, hogy könnyen üzembe helyezhesse az utolsó ismert jó konfigurációkat.

A visszaállítás vagy a visszaállítás során konzisztenciát tarthat fenn a felügyeleti és adatsíkokkal. Az erőforrásokra és szabályzatokra jellemző kulcsoknak, titkos kulcsoknak, adatbázisállapot-adatoknak és konfigurációknak hatókörben kell lenniük, és el kell számolniuk azokkal. Ügyeljen például az infrastruktúra skálázásának kialakítására az utolsó ismert jó üzembe helyezés során. Állapítsa meg, hogy módosítania kell-e ezt a konfigurációt a kód ismételt üzembe helyezésekor.

Előnyben részesítse a ritkán előforduló, nagy módosításokat, hogy az új és az utolsó ismert jó üzemelő példányok közötti eltérés kicsi legyen.

Végezzen hibamód-elemzést (FMA) a folyamatos integrációs és folyamatos kézbesítési (CI/CD) folyamatokon, hogy segítsen azonosítani azokat a problémákat, amelyek megnehezíthetik a kockázatcsökkentéseket. A számítási feladat egészéhez hasonlóan a folyamatok is elemezhetők, hogy azonosítsák azokat a területeket, amelyek problémásak lehetnek egy adott kockázatcsökkentési típus megkísérlésekor.

Használja az automatikus visszaállítási funkciókat a következő módon:

  • Egyes CI/CD-eszközök, például az Azure DevOps automatikus visszaállítási funkciókkal rendelkeznek, amelyek beépítettek. Fontolja meg ezt a funkciót, ha kézzelfogható értéket nyújt Önnek.
  • Az automatikus visszaállítási funkciókat csak a folyamat alapos és rendszeres tesztelése után érdemes alkalmazni. Győződjön meg arról, hogy a folyamat elég érett ahhoz, hogy további problémákat vezessen be, ha automatikus visszaállítás aktiválódik.
  • Bíznia kell abban, hogy az automatizálás csak a szükséges módosításokat helyezi üzembe, és csak akkor aktiválódik, ha szükséges. Gondosan tervezheti meg az eseményindítókat, hogy megfeleljenek ezeknek a követelményeknek.

A visszaállítások során használja a platform által biztosított képességeket. A biztonsági mentések és az időponthoz kötött visszaállítások például segíthetnek a tárolásban és az adatok visszaállításában. Vagy ha virtuális gépeket (VM-eket) használ az alkalmazás üzemeltetéséhez, hasznos lehet, ha a környezetet egy közvetlenül az incidens előtt található ellenőrzőpontra állítja vissza.

Gyakran tesztelje a teljes üzembehelyezési hibaelhárítási stratégiát. A vészhelyzeti reagálási tervekhez és a vészhelyreállítási tervekhez hasonlóan az üzembehelyezési hibaterv csak akkor sikeres, ha a csapat betanította és rendszeresen gyakorolja azt. A káosztervezés és a hibainjektálás tesztelése hatékony technikák lehetnek az üzembehelyezési kockázatcsökkentési stratégia teszteléséhez.

Kompromisszum: A támogatási csapat tagjainak képesnek kell lenniük a normál feladataik ellátására és a vészhelyzetek támogatására is. Előfordulhat, hogy növelnie kell a fejek számát annak biztosítása érdekében, hogy a támogatási csapat megfelelő személyzettel rendelkezzen, és képes legyen elvégezni az összes szükséges feladatot. Az üzembe helyezéseket alaposan tesztelje, amikor alacsonyabb fejlesztési környezetekben helyezi üzembe az üzembe helyezést. Ez a gyakorlat segít észlelni a hibákat és a helytelen konfigurációkat, mielőtt éles környezetbe kerülnének.

Azure-beli facilitálás

  • Az Azure Pipelines buildelési és kiadási szolgáltatásokat nyújt az alkalmazások CI/CD-jének támogatásához.

  • Az Azure Test Plans egy könnyen használható, böngészőalapú tesztkezelési megoldás. Ez a megoldás olyan képességeket kínál, amelyek a tervezett manuális teszteléshez, a felhasználói elfogadás teszteléséhez és a feltáró teszteléshez szükségesek. Az Azure Test Plans lehetővé teszi, hogy visszajelzést gyűjtsön az érdekelt felektől.

  • Az Azure Monitor egy átfogó monitorozási megoldás a felhőből és a helyszíni környezetekből származó monitorozási adatok gyűjtésére, elemzésére és megválaszolására. A monitor robusztus riasztási platformot tartalmaz. Konfigurálhatja ezt a rendszert az automatikus értesítésekhez és egyéb műveletekhez, például az automatikus skálázáshoz és más önjavító mechanizmusokhoz.

  • Az Application Insights a Monitor bővítménye, amely alkalmazásteljesítmény-monitorozási (APM-) funkciókat biztosít.

  • Az Azure Logic Apps egy felhőalapú platform automatizált munkafolyamatok futtatásához, amelyek alkalmazásokat, adatokat, szolgáltatásokat és rendszereket integrálnak. A Logic Apps használatával bármikor létrehozhatja az alkalmazás új verzióját, amikor frissítést végeznek rajta. Az Azure fenntartja a verziók előzményeit, és visszaállíthatja vagy előléptetheti az előző verziókat.

  • Számos Azure-adatbázis-szolgáltatás biztosít időponthoz kötött visszaállítási funkciót, amely segítséget nyújthat a visszaállításhoz:

  • Az Azure Chaos Studio Preview egy felügyelt szolgáltatás, amely a káosztechnológia segítségével méri, értelmezi és javítja a felhőalkalmazások és szolgáltatások rugalmasságát.

Működési kiválóság ellenőrzőlista

Tekintse meg a javaslatok teljes készletét.

Működési kiválóság ellenőrzőlista