Állapotmodellezés számítási feladatokhoz

A felhőalkalmazások nagy mennyiségű operatív adatot hoznak létre, ami megnehezíti a problémák gyors rögzítését és megoldását. Ennek a kihívásnak az egyik gyakori oka az, hogy nincs olyan állapotkonfiguráció, amely a számítási feladat funkcióira van szabva, és hogy nem képes észlelni az alapkonfigurációtól való eltérést.

Az állapotmodellezés egy megfigyelhetőségi gyakorlat, amely az üzleti környezetet a nyers monitorozási adatokkal kombinálva számszerűsíti a számítási feladatok általános állapotát. Segít olyan alapkonfigurációt beállítani, amely alapján figyelheti a számítási feladatokat. Figyelembe kell vennie az infrastruktúra- és alkalmazásösszetevőkből származó adatokat, például a telemetriát. Az állapotmodellezés egyéb információkat is tartalmazhat, amelyek a számítási feladat minőségi céljainak eléréséhez szükségesek.

A teljesítményproblémák vagy a működés romlása a várt működési állapottól való eltérést okozhatja. A számítási feladatok állapotának modellezésével azonosíthatja a sodródást, és megalapozott üzemeltetési döntéseket hozhat, amelyek figyelembe veszik az üzleti hatást.

Az állapotmodellezés áthidalja a törzsi működési ismeretek és a végrehajtható megállapítások közötti szakadékot. Segít a kritikus problémák hatékony kezelésében. A koncepció elengedhetetlen a megbízhatóság és a működési hatékonyság maximalizálásához.

Ez az útmutató gyakorlati útmutatást nyújt az állapotmodellezéshez, beleértve egy olyan modell összeállítását, amely felméri egy számítási feladat és annak összes alrendszere futásidejének állapotát.

Terminológia	Definíció
Állapotmodellezés	Megfigyelhetőségi gyakorlat, amely az üzleti környezetet használja a monitorozási adatok állapotállapotként való értelmezéséhez.
Állapotmodell	Logikai entitások és azok kapcsolatainak grafikus ábrázolása egy adott hatókörhöz. Minden csomópont rendelkezik egy állapotdefinícióval, amely észszerűsíti a monitorozási adatokat a modellben.
Állapot entitás	Egy logikai összetevő, amely egy rendszer egy egyedi egységét, több kapcsolódó entitás logikai kombinációját vagy a teljes rendszert jelöli.
Állapot	Definiált és mérhető állapot, amely értelmes működési megállapításokat nyújt egy entitás állapotáról.
Állapotjelzés	Egyéni adatfolyamok, amelyek betekintést nyújtanak egy entitás működési viselkedésébe.
Modellek modellje	Az aggregált modellezési hatókör, amelyben az entitások különböző állapotmodelleket képviselnek az összetevőrendszerekhez.

Javasoljuk, hogy watch ezt a videót az állapotmodellezés magas szintű megértéséhez.

Mi az állapotmodellezés, az állapotmodellezés és az állapotmodell?

Az állapot kifejezés egy entitás működési állapotát és függőségeit jelenti. Ez az entitás lehet egy rendszer önálló egysége, több kapcsolódó entitás logikai kombinációja vagy a teljes rendszer.

Javasoljuk, hogy az állapotot a következő három állapot egyikében képviselje:

• Egészséges: Optimálisan működik, és megfelel a minőségi elvárásoknak

• Csökkentett teljesítményű: Kevesebbet mutat, mint az egészséges viselkedés, ami potenciális problémákat jelez

• Nem megfelelő állapot: Kritikus állapotban van, és azonnali figyelmet igényel

Megjegyzés

Az állapotot állapotok helyett pontszámmal jelölheti, hogy több adatrészletességet biztosítson.

Az állapotok származtatása a monitorozási adatok és a tartományinformációk kombinálásával. Minden állapotot meg kell határozni, és mérhetőnek kell lennie. Az állapotállapotokat állapotjelek használatával számítjuk ki, amelyek olyan egyéni adatfolyamok, amelyek betekintést nyújtanak az entitás működési viselkedésébe. A jelek tartalmazhatnak metrikákat, naplókat, nyomkövetéseket vagy egyéb minőségi jellemzőket. Egy virtuálisgép-entitás állapotjelzése például nyomon követheti a cpu-kihasználtsági metrikát. Az entitás egyéb jelei közé tartozhat a memóriahasználat, a hálózati késés vagy a hibaarány.

Az állapotjelek meghatározásakor vegye figyelembe a számítási feladat nem funkcionális követelményeit. A cpu-kihasználtság példájában adja meg az egyes állapotok várt küszöbértékeit. Ha a kihasználtság meghaladja a megengedett küszöbértéket a számítási feladatokra vonatkozó követelményeknek megfelelően, a rendszer kifogástalan állapotról csökkentett vagy nem kifogástalan állapotúra vált. Ezek az állapotváltozások aktiválják a megfelelő riasztásokat vagy műveleteket.

Az állapotmodellezéshez az entitásoknak jól definiált állapotokkal kell rendelkezniük, amelyek több állapotjelből származnak, és környezetfüggőek a számítási feladathoz. Egy virtuális gép állapotdefiníciója például a következő lehet:

• Kifogástalan: A fő nem funkcionális követelmények és célok, például a válaszidő, az erőforrás-kihasználtság és a teljes rendszerteljesítmény teljes mértékben teljesülnek. A kérések 95%-a például 500 ezredmásodpercen belül lesz feldolgozva. A számítási feladat optimálisan használja a virtuálisgép-erőforrásokat, például a CPU-t, a memóriát és a tárolást, és fenntartja az egyensúlyt a számítási feladatok igényei és a rendelkezésre álló kapacitás között. A felhasználói élmény a várt szinten van.

• Csökkentett teljesítményű: Az erőforrások nem működnek optimálisan, de továbbra is működőképesek. A tárolólemezen például szabályozási problémák lépnek fel. A felhasználók lassú válaszokat tapasztalhatnak.

• Nem megfelelő állapot: A lebomlás meghaladja a megengedett korlátokat. Az erőforrások már nem reagálnak vagy érhetők el, és a rendszer már nem felel meg az elfogadható teljesítményszintnek. A felhasználói élmény súlyosan érintett.

Az állapotmodellezés eredménye a logikai entitások modellje vagy grafikus ábrázolása, valamint a számítási feladatok architektúrájának kapcsolatai. Minden csomópont rendelkezik állapotdefinícióval.

Fontos

Az állapotmodellezés egy absztrakt fogalom, amelyet különböző hatókörökben is implementálhat és alkalmazhat, ha jól ismeri az üzleti forgatókönyveket.

A képen:

• Az entitások a számítási feladat logikai összetevői, amelyek a rendszer aspektusait képviselik. Ezek lehetnek infrastruktúra-összetevők, például kiszolgálók, adatbázisok és hálózatok. Ezek lehetnek konkrét alkalmazásmodulok, podok, szolgáltatások vagy mikroszolgáltatások is. Vagy az entitások rögzíthetik a felhasználói interakciókat és a rendszerfolyamatokat a számítási feladaton belül.

  Megjegyzés

  A felhasználói és rendszerfolyamatok az alkalmazás- és infrastruktúra-összetevőket tartalmazó üzleti forgatókönyvek nem funkcionális követelményeit összegzik. Ez az összefoglalás az alkalmazás üzleti értékét tükrözi.

• Az entitások közötti kapcsolatok a rendszeren belüli függőségi láncokat tükrözik. Előfordulhat például, hogy egy alkalmazásmodul adott infrastruktúra-összetevőket hív meg, amelyek kapcsolatot alkotnak.

Vegyünk egy olyan forgatókönyvet, amelyben egy e-kereskedelmi tevékenységprofil kiugróan sok sikertelen üzenetet tapasztal egy Azure Service Bus üzenetsoron, ami a kifizetések meghiúsulását okozza. Ez a probléma kritikus fontosságú a szervezet számára a vélelmezett bevételkiesés miatt. Bár az alkalmazásfejlesztők megérthetik ennek a metrikakiugrásnak a kifizetésekre gyakorolt hatását, ezt a törzsi tudást gyakran nem osztják meg az üzemeltetési csapatban.

Az állapotmodellek azonnali betekintést adhatnak az operátoroknak a problémába és annak hatásaiba. A fizetési folyamat a Service Bustól függ, amely a számítási feladatok egyik összetevője. A vizualizáció megjeleníti a Service Bus-példány csökkentett állapotát és a fizetési folyamatra gyakorolt hatását. Az operátorok megérthetik a probléma fontosságát, és a szervizelési erőfeszítéseiket az adott összetevőre összpontosíthatják.

Az állapotmodellezés az előző forgatókönyvben a következő módokon volt fontos:

• A gyorsabb problémaelkülönítés lehetővé tételével javította az észlelési (TTD) és a mérséklésre (TTM) vonatkozó időt, ami a problémák gyorsabb észleléséhez és a lehetséges javításokhoz vezetett.

• Az operátorok állapotalapú riasztásokat kaptak, amelyek csökkentették a szükségtelen zajt. Az üzemeltetők olyan értesítéseket kaptak, amelyek konkrét kontextust biztosítottak a kifizetésekre gyakorolt üzleti hatásról.

• A függőségi láncok segítettek az operátoroknak teljes mértékben megérteni a működési problémák mértékét. Ez a tudás felgyorsította a hatásvizsgálatokat, és rangsorolt válaszokat eredményezett. Az operátorok könnyen azonosítják a kaszkádolt vagy korrelált problémákat is.

• Az operátorok az incidens utáni tevékenységeket pontosan végezték, mivel az állapotmodell betekintést nyújtott az anomáliák kiváltó okaiba és az érintett konkrét állapotjelekbe.

• A monitorozási adatok minden csapattag számára értelmezhetővé tették. Áthidalta a törzsi tudás és a megosztott megállapítások közötti szakadékot.

• A szervezet az állapotmodellt használta alapkonfigurációként az AI-alapú műveletekbe való jövőbeli befektetésekhez az intelligens elemzések kinyeréséhez.

Állapotmodell sémája

Az állapotmodellek a megfigyelhetőségi használati esetekre optimalizált különálló adatsémát biztosítanak. Ez a séma egy absztrakt koncepcióból egy mérhető megoldásba viszi az állapotmodellezést. A konkrét követelmények, célkitűzések és architektúrakörnyezet modellezésével az állapotadatokat az egyedi forgatókönyvéhez igazíthatja.

Az állapot egy relatív adatfogalom. Minden modell egyedi állapotadatokat jelöl, amelyek a környezetfüggő hatókörhöz tartoznak, még akkor is, ha ugyanazt az entitáskészletet használják. Ami egy adott forgatókönyvben egészségesnek minősül, más kontextusokban jelentősen eltérhet.

Vegyük például az azonos típusú Azure-erőforrásokat a számítási feladaton belül.

• Az A virtuális gép processzorérzékeny alkalmazást futtat.
• A B virtuális gép memóriaigényes szolgáltatást kezel.

A gépek állapotdefiníciói eltérőek. A cpu-kihasználtsági metrikák valószínűleg befolyásolják az A virtuális gép állapotát, és a B virtuális gép rangsorolhatja a memóriával kapcsolatos metrikákat.

Fontos

Az állapotmodell nem kezelhet minden hibát ugyanazzal a módszerrel. Egyértelműen különbséget kell tenni a várt vagy átmeneti, de helyreállítható hibák és a valódi katasztrófaállapot között.

Állapotmodell létrehozása

Az állapotmodell elkészítésének első lépése egy logikai tervezési gyakorlat, amely általában az alábbi szakaszokban leírt tevékenységeket foglalja magában.

A számítási feladatok tervezésének értékelése

Kezdje el ezt a logikai tervezési gyakorlatot a számítási feladat tervezésének alábbi összetevőinek kiértékelésével.

• Infrastruktúra-összetevők, például számítási fürtök és adatbázisok

• Számításon futó alkalmazásösszetevők és azok kapcsolódó összetevői

• Az összetevők közötti logikai vagy fizikai függőségek

• Felhasználói és rendszerfolyamatok

Az e-kereskedelmi alkalmazások állapotmodelljének például meg kell jelennie a kritikus folyamatok aktuális állapotának, például a felhasználói bejelentkezésnek, a fizetésnek és a fizetésnek.

Környezetfüggőség az üzleti követelmények használatával

Értékelje ki az egyes folyamatok relatív fontosságát és általános hatását a szervezetre. Vegye figyelembe az olyan tényezőket, mint a felhasználói élmény, a biztonság és a működési hatékonyság. A legtöbb esetben például a fizetési folyamat meghiúsulása valószínűleg nagyobb jelentőséggel bír, mint egy jelentési folyamat hibája.

Azonosítsa az egyes folyamatokkal kapcsolatos problémák kezelésére szolgáló eszkalációs útvonalakat. További információ: Számítási feladatok tervezésének optimalizálása folyamatok használatával.

Megjegyzés

Az állapotmodellezés értékét csak akkor ismerheti fel, ha üzleti forgatókönyveket és kontextusokat foglal magában. Ezután ésszerűsítheti az üzleti hatást a működési problémákból.

Megbízhatósági metrikák leképezése

Keresse meg a releváns megbízhatósági metrikákat az alkalmazástervezésben.

Fontolja meg a szolgáltatásszint-mutatók (SLA-k) és a szolgáltatásiszint-célkitűzések (SLO-k) meghatározását a teljes alkalmazás és az egyes üzleti folyamatok tekintetében. Ezeknek az SLA-knak és SLO-knak igazodniuk kell az állapotmodellhez figyelembe vett konkrét állapotjelekhez. Ezzel létrehoz egy átfogó állapotdefiníciót, amely pontosan tükrözi az alkalmazás elfogadható szolgáltatási szintjének elérését.

Fontos

Az SLA-k és az SLO-k kritikus fontosságú állapotjelek. Létrehoznak egy értelmes állapotdefiníciót, amely tükrözi a kívánt szolgáltatási szintet és más minőségi attribútumokat. Szolgáltatásállapot-célkitűzéseket (SHO-kat) is meghatározhat, hogy rögzíthesse az összesített időtartományon belül elérni kívánt állapotot.

Állapotjelek azonosítása

Átfogó állapotmodell létrehozásához korreláljon különböző típusú monitorozási adatokat, például metrikákat, naplókat és nyomkövetéseket. Ezzel biztosítja, hogy az állapot fogalma pontosan tükrözze egy adott entitás vagy a teljes számítási feladat futtatókörnyezeti állapotát.

Platformmetrikák és -naplók használata

Az állapotmodellezés kontextusában elengedhetetlen, hogy platformszintű metrikákat és naplókat gyűjtsön a mögöttes Azure-erőforrásokból. Ezek a metrikák közé tartozik a processzorhasználat százalékos aránya, a hálózat és a hálózat kifelé, valamint a másodpercenkénti lemezműveletek. Ezeket az adatokat az állapotmodellben felhasználhatja a lehetséges problémák észlelésére és előrejelzésére egy megbízható környezet fenntartása mellett.

Emellett ez a megközelítés segít megkülönböztetni az átmeneti hibákat, az ideiglenes fennakadásokat, a nem átmeneti hibákat és az állandó problémákat.

Megjegyzés

Ajánlott eljárásként konfigurálnia kell az összes alkalmazás-erőforrást, hogy a diagnosztikai naplókat és metrikákat a kiválasztott naplóösszesítési technológiára irányítsa. Védőkorlátokat hozhat létre az Azure Policy használatával, hogy egységes diagnosztikai beállításokat biztosítson az alkalmazás egészében, és kikényszerítse a kiválasztott konfigurációt az egyes Azure-szolgáltatásokhoz.

Alkalmazásnaplók hozzáadása

Az alkalmazásnaplók az állapotmodell diagnosztikai adatainak fontos forrásai. Íme néhány ajánlott eljárás az alkalmazásnaplózáshoz:

• Használjon szemantikai vagy strukturált naplózást. A strukturált naplók megkönnyítik a naplóadatok nagy léptékű automatizált felhasználását és elemzését.

  Fontolja meg az Azure-erőforrások metrikáinak és diagnosztikai adatainak tárolását egy Azure Monitor-naplók munkaterületen tárfiók helyett. Ezzel a módszerrel állapotjeleket hozhat létre Kusto-lekérdezések használatával a hatékony értékelés érdekében.

• Naplózza az adatokat az éles környezetben. Átfogó adatok rögzítése, miközben az alkalmazás éles környezetben működik. Az állapotfelméréshez és az észlelt termelési problémák diagnosztizálásához elengedhetetlen a megfelelő információ.

• Események naplózása a szolgáltatáshatárokon. Adjon meg egy olyan korrelációs azonosítót, amely átlépi a szolgáltatás határait. Ha egy tranzakció több szolgáltatást is érint, és az egyik sikertelen, a korrelációs azonosító segít nyomon követni a kéréseket az alkalmazás egészében, és meghatározni a hiba okát.

• Aszinkron naplózás használata. Kerülje a szinkron naplózási műveleteket, amelyek blokkolhatják az alkalmazás kódját. Az aszinkron naplózás biztosítja a rendelkezésre állást azáltal, hogy megakadályozza a kérések hátralékait a naplóírások során.

• Különítse el az alkalmazásnaplózást a naplózástól. Az auditnaplókat a diagnosztikai naplóktól elkülönítve kell karbantartani. Bár az auditrekordok megfelelnek a megfelelőségi vagy szabályozási követelményeknek, a különálló adatok megtartása megakadályozza az elvetett tranzakciókat.

Elosztott nyomkövetés implementálása

Elosztott nyomkövetés implementálása a telemetria kritikus rendszerfolyamatok közötti korrelálásával . A korrelált telemetriai adatok betekintést nyújtanak a végpontok közötti tranzakciókba, és alapvető fontosságúak a hibák esetén a kiváltó okok hatékony elemzéséhez (RCA).

Állapottesztek használata

Az alkalmazás állapottesztjeinek alkalmazáson kívüli implementálása és futtatása az alkalmazás állapotának és válaszképességének explicit ellenőrzéséhez. Használjon mintavételi válaszokat jelként az állapotmodellben.

Az állapotteszteket az alkalmazás egészéből vagy az egyes összetevőkből származó válaszidő mérésével valósíthatja meg. A mintavételek folyamatokat futtathatnak a késés mérésére és a rendelkezésre állás ellenőrzésére vagy az alkalmazásból származó információk kinyerésére. További információ: Állapotvégpont monitorozási mintája.

A legtöbb terheléselosztó támogatja az állapottesztek futtatását, amelyek konfigurált időközönként pingelik az alkalmazásvégpontokat. Másik lehetőségként külső watchdog szolgáltatást is használhat. A watchdog szolgáltatás a számítási feladat több összetevőjének állapot-ellenőrzését összesíti. A watchdogok olyan kódot is üzemeltethetnek, amely azonnali szervizelést végez az ismert állapotállapotok esetén.

Szerkezeti és funkcionális monitorozási technikák alkalmazása

A strukturális monitorozás magában foglalja az alkalmazás szemantikai naplókkal és metrikákkal való felszerelését. Az alkalmazás közvetlenül gyűjti ezeket a metrikákat, amelyek magukban foglalják az aktuális memóriahasználatot, a kérelmek késését és más releváns alkalmazásszintű adatokat.

A monitorozási folyamatok megerősítése funkcionális monitorozással. Ez a megközelítés a platformszolgáltatások mérésére és az általános felhasználói élményre gyakorolt hatásukra összpontosít. A szerkezeti monitorozástól eltérően a funkcionális monitorozáshoz nincs szükség a rendszer részletes ismeretére. Teszteli az alkalmazás külsőleg látható viselkedését. Ez a megközelítés hasznos az SLO-k és SLI-k értékeléséhez.

A tervezés modellezése

Az azonosított alkalmazástervet entitásokként és kapcsolatokként ábrázolja. Állapotjelek leképezése adott összetevőkre az állapotállapotok entitásszinten történő számszerűsítéséhez. Vegye figyelembe az összetevők kritikusságát annak meghatározásához, hogy az állapotállapotok hogyan propagáljanak a modellen keresztül. Előfordulhat például, hogy a jelentéskészítési összetevők nem olyan kritikusak, mint a többi összetevő, ami eltérő hatással van a számítási feladatok általános állapotára.

Végrehajtható riasztások beállítása

A kiértékelt állapotállapotok használatával riasztásokat és automatizált műveletet aktiválhat. Az állapotot a meglévő működési runbookokban kell integrálni alapvető megfigyelhetőségi adatkészletként.

A monitorozási adatok és a riasztási szabályok általában egy-az-egyhez leképezéssel járnak, ami nemkívánatos eredményekhez vezethet, például riasztási viharokhoz és környezeti riasztási zajokhoz. Egy számítási fürtben például a processzorhasználat és a hibaszám alapján nagy mennyiségű virtuálisgép-szintű riasztás túlterhelheti az operátorokat a hibák során, és késéseket okozhat a megoldásban. Hasonlóképpen, ha sok konfigurált riasztás van, a környezeti riasztások zaja gyakran olyan riasztásokat eredményez, amelyeket figyelmen kívül hagynak vagy figyelmen kívül hagynak.

Az állapotmodellek a figyelési adatok és a riasztási szabályok elkülönítését vezetik be. Az állapotdefiníciók számos jelet egyetlen állapotállapotba összesítenek, ami csökkenti a riasztások számát, így az operátorok kizárólag a szervezet számára kritikus fontosságú, nagy értékű riasztásokra összpontosíthatnak. Fontolja meg az e-kereskedelmi forgatókönyvet. Beállíthat egy riasztást, amely értesítéseket küld a folyamat fizetési folyamatának állapotáról a mögöttes erőforrások, például a Service Bus-üzenetsor változásai helyett.

Megjegyzés

Az állapotmodell minden rétegére kiterjedő riasztási képesség rugalmasságot biztosít a különböző számítási feladatokhoz. Az alkalmazástulajdonosok és a termékmenedzserek riasztást kaphatnak az állapotváltozásokról a kulcsfontosságú üzleti forgatókönyvekben vagy a teljes számítási feladatban. Az operátorok az infrastruktúra vagy az alkalmazás összetevőinek állapota alapján riasztást kaphatnak.

A modell vizualizációja

Hozzon létre vizuális ábrázolásokat, például táblákat vagy grafikonokat az állapotmodell aktuális állapotának és előzményeinek hatékony közvetítéséhez. Győződjön meg arról, hogy a vizualizáció igazodik az üzleti környezethez, és használható elemzéseket biztosít.

Az állapotmodell vizualizációja során érdemes lehet forgalomirányító megközelítést alkalmazni, hogy az állapotállapotok azonnal betekintést nyerjenek a függőségi láncokba.

Rendeljen zöld színt az egészségeshez, a borostyánt a csökkentett teljesítményűhöz, a pirosat pedig az egészségtelenséghez. A színkódolt állapotok gyors azonosításával hatékonyan megtalálhatja az alkalmazások romlásának kiváltó okát.

Megjegyzés

Javasoljuk, hogy vegye figyelembe a látássérültek akadálymentességi követelményeit, amikor irányítópultot hoz létre az állapotmodellhez. A diagramkészítési ajánlott eljárásokért lásd: Architektúratervezési diagramok.

Az állapotmodell bevezetése

Az állapotmodell létrehozása után fontolja meg az alábbi használati eseteket a hibák vagy működési problémák észlelésének és értelmezésének ösztönzésére.

Alkalmazhatóság a különböző szerepkörökre

Az állapotmodellezés olyan információkat nyújthat, amelyek a feladatfüggvényekre vagy a számítási feladat ugyanazon környezetében lévő szerepkörökre vonatkoznak. Előfordulhat például, hogy egy DevOps-szerepkörnek operatív állapotinformációra van szüksége. Előfordulhat, hogy egy biztonsági tisztviselő jobban aggódik a behatolási jelek és a biztonsági kitettség miatt. Az adatbázisgazdákat valószínűleg csak az alkalmazásmodell egy részhalmaza érdekli az adatbázis-erőforrásokon keresztül.

Személyre szabhatja az egészségügyi elemzéseket a különböző érdekelt felek számára. Érdemes lehet különálló modelleket létrehozni az egymást átfedő adathalmazoktól.

Folyamatos ellenőrzés

Az állapotmodell használatával optimalizálhatja a tesztelési és ellenőrzési folyamatokat, például a terheléstesztelést és a káosztesztelést. Az állapotmodellek mérnöki életciklusba való beépítésével ellenőrizheti a futtatókörnyezet működési állapotát a tesztelés során, és felmérheti a modell hatékonyságát a skálázási és meghibásodási forgatókönyvekben.

Szervezeti állapot

Bár az állapotmodellezés általában az egyes alkalmazások állapotállapotainak számszerűsítésével van társítva, alkalmazhatósága túlmutat ezen a hatókörön.

Az egyes számítási feladatok szintjén az állapotmodellek az alkalmazások megfigyelhetőségének és működési megállapításainak alapjait biztosítják. Minden alkalmazás rendelkezhet saját állapotmodellel, amely rögzíti, hogy az egyes állapotok mit jelentenek a környezetében.

Egy modellmodell létrehozásával több állapotmodellt is kombinálhat egy magas szintű szerkezetben. Létrehozhatja például egy üzleti egység vagy egy teljes felhőtulajdon megfigyelhetőségi lábnyomát úgy, hogy az állapotmodelleket egy nagyobb modell összetevőiként használja. Az állapotmodellek a birtokon belüli számítási feladatokat jelölik csomópontként a legfelső szintű gráfon belül. A modell kapcsolataival rögzítheti az alkalmazásközi függőségeket, beleértve az adatfolyamokat, a szolgáltatás-interakciókat és a megosztott infrastruktúrát.

Vegyünk egy kiskereskedelmi vállalatot, amely különböző alkalmazásokkal rendelkezik az e-kereskedelemhez, a kifizetésekhez és a megrendelések feldolgozásához. Ezeket az alkalmazásokat önálló állapotmodellként definiálhatja, hogy számszerűsítse, mit jelent az adott számítási feladat állapota. Ezt követően egy szülőmodell használatával az összes összetevő állapotmodelljét entitásként leképezheti, és függőségi láncokon keresztül rögzítheti az alkalmazások közötti működési hatást. Ha például az e-kereskedelmi alkalmazás nem megfelelő állapotúvá válik, az kaszkádolt hatással van a fizetési alkalmazásra.

Egészségügyi trendek és AI az informatikai műveletekhez

Az állapotmodellezés számszerűsített működési alapkonfigurációt biztosít, amely egy adott üzleti környezethez van hangolva. Az AI for IT Operations (AIOps) a működési hatékonyság növelésének népszerű módja. Az állapotadatok a gépi tanulási modellek alapvető bemenete az állapottrendek elemzéséhez. A gépi tanulási modellek például a következőket tehetik:

• További elemzéseket nyerhet ki az állapotváltozásokból, és műveleteket javasolhat.

• Az állapottrendek időbeli elemzése a problémák előrejelzésének és a modell pontosításának ösztönzéséhez.

Az állapotmodell karbantartása

A heath modell fenntartása folyamatos mérnöki tevékenység, amely igazodik az alkalmazás fejlesztéséhez és működéséhez. Az alkalmazás fejlődésével győződjön meg arról, hogy az állapotmodell párhuzamosan fejlődik.

Emellett kezelje az állapotmodelleket úgy, mint a számítási feladatok összetevőit, amelyeket integrálnia kell a fejlesztési életciklusba. Az infrastruktúra kódként (IaC) való bevezetése az állapotmodell konzisztens, verzióalapú felügyeletéhez. Használja az automatizálást, hogy a modell naprakész maradjon, amikor infrastruktúra- és alkalmazásösszetevőket ad hozzá vagy távolít el a számítási feladatból.

Az állapotadatok idővel fokozatosan csökkennek. A működési hatékonyság optimalizálása és a költségek minimalizálása érdekében kerülje az állapotadatok 30 napon túli megőrzését. Szükség esetén archiválhatja az adatokat az auditkövetelményeknek való megfelelés érdekében, vagy olyan forgatókönyvekben, amelyek hosszú távú mintaelemzést igényelnek az INFORMATIKAI műveletek mesterséges intelligenciájában.

Megjegyzés

Az állapotadatok archiválásakor győződjön meg arról, hogy párosítja azokat a modell konfigurációs állapotával. Az állapotváltozások értelmezése e környezet nélkül is kihívást jelenthet.

Kapcsolódó hivatkozások

• Az állapottesztek ASP.NET való implementálásához lásd: Állapotellenőrzések ASP.NET Core.
• A monitorozási metrikákkal kapcsolatos információkért lásd: Az Azure Monitor-metrikák áttekintése.
• Az Application Insights használatával kapcsolatos információkért lásd: Application Insights.
• A kritikus fontosságú számítási feladatokra vonatkozó tervezési szempontokért és javaslatokért lásd: Az Azure-beli kritikus fontosságú számítási feladatok állapotmodellezése és megfigyelhetősége.
• Gyakorlati tapasztalatért lásd: Állapotmodell tervezése a kritikus fontosságú számítási feladatokhoz.

Következő lépés

Javaslatok a megbízható figyelési és riasztási stratégia kialakításához