Szervizelés
Ha az incidenskezelési életciklust öt fázisra osztja, ahogyan az ebben a modulban látható, segít megérteni a folyamatot, de a fázisok nem mindig olyan különbözőek, mint a diagramon. Különösen a reagálási és a szervizelési fázis közötti határ kezd gyakran elmosódni. Ez fokozottan igaz akkor, ha a helyzet enyhítésére és javítására szánt intézkedések az ellentétes hatást érik el. Ilyen esetben a reagálás és a szervizelés gyakran összemosódik, vagy váltakozva követi egymást.
Ebben a leckében többet tudhat meg a szervizelésről és a fázist alkotó lépésekről, valamint néhány hasznos tippről és eszközről. Egy fontos dolog, amit meg kell jegyezni: nem szabad az itt ismertetett intézkedéseket előíró ellenőrzőlistaként elvégezni.
Ha már van kész ellenőrzőlistája a szervizeléshez, az gyakran azt jelzi, hogy ideje bevezetni az automatizálást. Ha pontosan le tudja írni, hogy mit kell tenni, és milyen sorrendben kell elhárítani egy problémát, itt az ideje, hogy megtanítsa ezeket a lépéseket egy gépnek, hogy a rendszer elvégezhesse Az Ön számára.
A kiindulópont
Már tudja, mennyire fontos lecsökkenteni azt az időt, amely alatt reagálni tud egy incidensre. Vizsgáljunk meg néhány olyan tényezőt, amelyek hozzájárulhatnak a szervizelés, tehát a probléma kijavítása folyamatának felgyorsításához.
A különböző csapattagok különböző mentális modellekkel rendelkezhetnek a dolgok működéséről, és eltérő elképzelésekkel rendelkezhetnek arról, hogy mi legyen az első lépés. Az egyik először a naplókat tekintheti meg, míg egy másik először lekérdezéseket futtathat, és megnézheti a metrikákat. A sikerhez nem egyetlen helyes út vezet.
Hasznos azonban mindenki számára biztosítani azt a rálátást és útmutatást, amely alapján tudhatja, hogy hol mire figyeljen.
Kit vonjunk be és hogyan?
A szervizelés kiindulási pontjának meghatározásához fontos megválaszolni a következő kérdést: ha elakad, kit hívhat, hogy bevonja a probléma megoldásába? Érdemes arra törekedni, hogy a feladatok nagyobb részét ne csak az üzemeltetési és megbízhatósági mérnökök, hanem az egész csapat vegye át az ügyeletestől. A csapat minden tagjának felelősséget kell vállalnia azért, hogy a rendszerek működjenek és teljesítsék a megbízhatósági célkitűzéseket.
Milyen erőforrásoknak veszik hasznát az első beavatkozók?
A következő szempont meghatározni mindazt, aminek az első beavatkozók hasznát vehetik a folyamat elindításakor. Ilyenek lehetnek a rendszerhez kapcsolódó metrikák, napló, lekérdezések és így tovább. Ezeket, ha csak lehetséges, egy Azure-munkafüzetben vagy hibaelhárítási útmutatóban érdemes elérhetővé tenni. Egy pillanat alatt beszélünk róluk.
Az erőforrásokra mutató egyszerű hivatkozásokat is hasznos lehet megadni (gyakran hibaelhárítási útmutatókban). Ha a cél a lehető leggyorsabb reagálás és a probléma minél gyorsabb szervizelése, akkor a folyamat felgyorsítható, ha megkönnyítjük a felmerülő kérdések megválaszolását anélkül, hogy keresgélni kellene a megfelelő dokumentumot vagy URL-címet.
Az érintettek tájékoztatása
Annyira összpontosíthat a probléma megoldására, hogy elfelejtheti, hogy sok olyan személy van, aki nem vesz részt közvetlenül az incidensre adott válaszban, de akiknek tudniuk kell és tudniuk kell, hogy mi történik.
Fontos, hogy kommunikáljon más belső csapatokkal, és tartsa őket naprakészen arról, hogy mi történik incidens esetén. Ha nem ad nekik konzisztens frissítéseket, valószínűleg állapotfrissítést kérnek. Minden joguk megvan ezekhez az információkhoz, de jobb módszerre van szüksége ahhoz, hogy tisztában legyenek a problémával és azzal, hogy mit tesznek vele.
A belső csapatokat egyértelműen kell tájékoztatnia. Legyen világos, hogy bemutatja, mit tud, és mi történik, és állítsa be az elvárások szempontjából, hogy mikor fognak hallani öntől.
Az érintettekkel való kommunikáció formulája egyszerű:
- Ezt tudjuk.
- Ez az, amit csinálunk.
- X idő alatt visszatérünk.
Ez segít megakadályozni, hogy az érdekelt felek az Önhöz érkezhessenek, és megszakítsa Önt, amikor éppen a problémák megoldására törekszik.
Az ilyen információk terjesztésének egyik módja egy egyszerűen szerkeszthető állapotjelentő weboldal, amilyenről az előző leckében volt szó. Sok esetben érdemes lehet külön, részletesebb állapotoldalt létrehozni a belső érintetteknek, és egy külsőt az ügyfeleknek. Az előző képlet mindkét esetben működik.
Azure Monitor-munkafüzetek és Application Insights hibaelhárítási útmutatók használata
Az Azure két szorosan kapcsolódó funkcióval rendelkezik, amelyek rendkívül hasznosak lehetnek a szervizelési fázisban lévő csapatok számára: Azure Monitor-munkafüzetek és alkalmazás Elemzések hibaelhárítási útmutatók. Ennek a modulnak a alkalmazásában felcserélhetők, beleértve ugyanazt a felhasználói felületet is. Az Azure Monitor-munkafüzetek az Azure Portalon, az Azure Monitor alatt találhatók. Az Azure Elemzések hibaelhárítási útmutatói az Azure Portalon találhatók, amikor kiválasztottak egy Application Insight-példányt.
A munkafüzetekre és a hibaelhárítási útmutatókra "élő dokumentumokként" gondolhat, amit egy oldallétrehozási felületen hozhat létre. Egy új oldalra a következőket veheti fel annak elkészítésekor:
- Tetszőleges szöveg, például a teendők listajeles listája vagy más hasznos információ az oldallal konzultáló személy számára
- Más rendszerekre mutató hivatkozások, például más irányítópultokra vagy dokumentációkra mutató hivatkozások
- Kusto lekérdezési nyelven (KQL) írt lekérdezéseket
Ez az utolsó elem, amely a dokumentumot "élővé" teszi. A képzési terv egy korábbi moduljában a Log Analyticsbe és az Azure Monitor más részeibe beépített KQL lekérdezési nyelvet ismertettük. Ezen a nyelv saját lekérdezések írhatók, amelyek az alkalmazásból és az Azure-infrastruktúrából adnak vissza és jelenítenek meg diagnosztikai adatokat. Amikor egy KQL-lekérdezést beszúr egy munkafüzetbe vagy hibaelhárítási útmutatóba, a lekérdezés aktuális eredményei élőben jelennek meg a dokumentum olvasói számára. Ez azt jelenti, hogy a hibaelhárítási útmutató nem csak az „Ellenőrizze a hibák gyakoriságát a webkiszolgálón” utasítással szolgál, hanem ennek a hibagyakoriságnak az aktuális diagramját is képes megjeleníteni közvetlenül az utasítás mellett. Tartalmazhat egy „Itt található a webkiszolgáló újraindítási dokumentációja” hivatkozást, amellyel az első beavatkozó azonnal eléri a szükséges dokumentációt.
Az Azure néhány kész sablont is kínál a saját dokumentumok elkészítésének első lépéseihez. Az alábbi képernyőképen néhány előre elkészített sablon látható:
A munkafüzetek és hibaelhárítási útmutatók speciális szerkesztőfunkciója lehetővé teszi a dokumentum JSON- vagy Azure Resource Manager-sablonképének elérését és beszúrását. Ez azt jelenti, hogy a dokumentumok nyomon követhetők és terjeszthetők a választott forrásvezérlő rendszer használatával. Emellett automatizálhatja a munkafüzetek kiépítését vagy a hibaelhárítási útmutatókat, ami hasznos lehet más infrastruktúra kiépítésekor. Ezzel az ajánlott eljárással egyszerűvé válik egyéni hibaelhárítási dokumentumok létrehozása egy új szolgáltatással való használathoz a szolgáltatás üzembe helyezésekor.
További hasznos tippek és eszközök
Ebben a modulban megismerhette azokat az eszközöket és billentyűparancsokat, amelyekkel növelheti a hatékonyságot, és csökkentheti az incidensek válaszidejének idejét. Az utolsó leckében röviden áttekintjük azokat az eszközöket és technikákat, amelyek segítenek a rendszerek problémáinak diagnosztizálásában.
- Az Application Elemzések Alkalmazás irányítópult hivatkozásával automatikusan létrehozhat egy olyan irányítópultot, amely a legtöbb fontos elemével rendelkezik, amelyre kiindulási pontként szüksége lesz. Vegye figyelembe, hogy nem tartalmazza az Azure Service Health szolgáltatást. Ezt is érdemes kitűzni az irányítópultra, így ellenőrizhető lesz, hogy az Ön rendszerével vagy magával a felhőszolgáltatással van probléma.
- Az Application Elemzések alkalmazástérképével pontosan megismerheti, hogy mi okozza a problémákat. A navigációs elemek követésével felderítheti a hiba okát (például egy hibás formátumú URL-címet).
- A Log Analytics használatával a rendszer bármely részét lekérdezheti.
A fenti eszközök mindegyike felbecsülhetetlen értékű a problémák megoldásában.