Á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 felismeré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óihoz van testre szabva, és 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 beállítani egy alapkonfigurációt, amely alapján figyelheti a számítási feladatot. Figyelembe kell vennie az infrastruktúrából és az alkalmazás összetevőibő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ásokat.

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 a számítási feladatok és annak összes alrendszere futásidejének állapotát kiértékelő modell összeállítását.

Terminológia	Definíció
Állapotmodellezés	Megfigyelhetőségi gyakorlat, amely az üzleti környezetet használja a monitorozási adatok á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	Logikai összetevő, amely egy rendszer egy önálló egységét, több kapcsolódó entitás logikai kombinációját vagy a teljes rendszert jelöli.
Állapot	Egy definiált és mérhető állapot, amely értelmes működési elemzéseket biztosít 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	Összesített modellezési hatókör, amelyben az entitások különböző állapotmodelleket jelölnek az összetevőrendszerekhez.

Javasoljuk, hogy tekintse meg ezt a videót az állapotmodellezés magas szintű megismeré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 egészséget 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ökkent: Kevesebb, mint egészséges viselkedést mutat, ami potenciális problémákat jelez

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

Feljegyzés

Az állapotokat állapotok helyett pontszámmal is jelölheti, így több adatrészletességet biztosíthat.

Az állapotok származtatása a monitorozási adatok tartományinformációkkal való kombinálásával érhető el. Minden állapotot meg kell határozni, és mérhetőnek kell lennie. Az állapotok kiszámítása állapotjelek használatával történik, 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 definiálása során 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árható 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 állapotúró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ők 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 az általános rendszerteljesítmény teljes mértékben teljesülnek. A kérelmek 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 egyensúlyt tart fenn 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 szinteken 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 nem é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 és azok kapcsolatainak modellje vagy grafikus ábrázolása egy számítási feladat architektúrája esetében. Minden csomópont rendelkezik állapotdefinícióval.

Fontos

Az állapotmodellezés egy absztrakt fogalom, amelyet különböző hatókörökben 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. 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.

  Feljegyzé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. Egy alkalmazásmodul meghívhat például egy kapcsolatot alkotó konkrét infrastruktúra-összetevőket.

Fontolja meg azt a forgatókönyvet, amelyben egy e-kereskedelmi számítási feladat egy Azure Service Bus-üzenetsor sikertelen üzeneteinek megugrását tapasztalja, ami a kifizetések sikertelenségé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 a metrikakiugrásnak a kifizetésekre gyakorolt hatását, ezt a törzsi tudást gyakran nem osztják meg az üzemeltetési csapat között.

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 és a lehetséges javítások gyorsabb észleléséhez vezetett.

• Az operátorok állapotalapú riasztásokat kaptak, ami csökkentette 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ítségével az operátorok teljes mértékben megértették 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 adatokat az összes csapattag számára érthetővé tette. Á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 beruházásokhoz az intelligens elemzések kinyeréséhez.

Állapotmodell sémája

Az állapotmodellek a megfigyelhetőségi használati esetekhez 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önyvhöz igazíthatja.

Az állapot egy relatív adatfogalom. Minden modell egyedi állapotadatokat jelöl, és rangsorolja a környezetfüggő hatókörét, még akkor is, ha ugyanazt az entitáskészletet használja. Az, hogy mi minősül kifogástalannak egy adott forgatókönyvben, 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 állapotmodellnek nem szabad minden hibát ugyanúgy kezelnie. 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 kiértékelése

Kezdje el ezt a logikai tervezési gyakorlatot a számítási feladatok 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

• A számításon futó alkalmazásösszetevők és azok releváns összetevői

• Logikai vagy fizikai függőségek az összetevők között

• Felhasználói és rendszerfolyamatok

Az e-kereskedelmi alkalmazások állapotmodelljének például a kritikus folyamatok aktuális állapotát kell képviselnie, például a felhasználói bejelentkezést, a kivételt és a kifizetéseket.

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 forgatókönyvben például a fizetési folyamat meghiúsulása valószínűleg nagyobb jelentőséggel bír, mint a jelentéskészítési folyamat hibája.

Azonosítsa az egyes folyamatokhoz kapcsolódó 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.

Feljegyzés

Az állapotmodellezés értékét csak akkor veszi figyelembe, ha üzleti forgatókönyveket és kontextusokat foglal magában. Ezután ésszerűsítheti az üzleti hatásokat 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ásszintű célkitűzések (SLO-k) meghatározását a teljes alkalmazás és annak egyéni üzleti folyamatai számára. Ezeknek az SLA-knak és SLO-knak összhangban kell lennie az állapotmodellhez figyelembe vett konkrét állapotjelekkel. 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 más minőségi attribútumokkal együtt. Szolgáltatásállapot-célkitűzéseket (SPO-kat) is meghatározhat az összesített időtartományban elérni kívánt állapot rögzítéséhez.

Á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 az alapul szolgáló Azure-erőforrásokból. Ezek a metrikák közé tartozik a processzor százalékos aránya, a hálózat és a hálózat kifelé, valamint a lemezműveletek másodpercenként. Ezeket az adatokat az állapotmodellben a lehetséges problémák észlelésére és előrejelzésére használhatja, miközben megbízható környezetet tart fenn.

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

Feljegyzé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ához irányítsa. Az Azure Policy használatával védőkorlátokat hozhat létre az alkalmazás konzisztens diagnosztikai beállításainak biztosításához és az egyes Azure-szolgáltatásokhoz választott konfiguráció kikényszerítéséhez.

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 nagy léptékben megkönnyítik a naplóadatok 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 Logs-munkaterületen tárfiók helyett. Ezzel a módszerrel állapotjeleket hozhat létre Kusto-lekérdezésekkel 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árok között. Adjon meg egy korrelációs azonosítót, amely bejárja a szolgáltatás határait. Ha egy tranzakció több szolgáltatást is magában foglal, és az egyik sikertelen, a korrelációs azonosító segít nyomon követni a kéréseket az alkalmazásban, és azonosítani a hiba okát.

• Aszinkron naplózást használjon. 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ás 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 a naplózási rekordok megfelelőségi vagy szabályozási követelményeket szolgálnak ki, 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ációja révén. A korrelált telemetriai adatok betekintést nyújtanak a végpontok közötti tranzakciókba, és nélkülözhetetlenek a hatékony kiváltó okelemzéshez (RCA), ha hibák történnek.

Állapotadat-mintavételek használata

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

Az állapotadat-mintavételeket az alkalmazás egészének vagy egyes összetevőinek válaszidejének 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 alkalmazásvégpontokat konfigurált időközönként pingelő állapotminták futtatását. Másik lehetőségként használhat külső watchdog szolgáltatást is. 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 javítást végez az ismert á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 strukturális monitorozástól eltérően a funkcionális monitorozás nem igényel részletes ismereteket a rendszerről. 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 terv modellezése

Az azonosított alkalmazástervet entitásokként és kapcsolatokként ábrázolja. Állapotjelek leképezése adott összetevőkre az állapotok entitásszinten történő számszerűsítéséhez. Fontolja meg az összetevők kritikusságát annak meghatározásához, hogy az á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 állapotok használatával riasztásokat és automatizált műveleteket 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 között általában egy-az-egyhez leképezés van, ami nemkívánatos eredményekhez vezethet, például riasztási viharokhoz és környezeti riasztási zajhoz. 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 nagy számú konfigurált riasztás van, a környezeti riasztások zaja gyakran figyelmen kívül hagyott vagy figyelmen kívül hagyott riasztásokat eredményez.

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 állapotba összesítenek, ami csökkenti a riasztások számát, hogy az operátorok kizárólag a szervezet számára kritikus fontosságú, nagy értékű riasztásokra összpontosítsanak. Fontolja meg az e-kereskedelmi forgatókönyvet. Beállíthat egy riasztást, amely értesítéseket küld a folyamatfizetési folyamat állapotának változásairól a mögöttes erőforrások, például a Service Bus-üzenetsor változásai helyett.

Feljegyzé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 állapot változásairó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

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

Az állapotmodell vizualizációja során érdemes lehet forgalomirányító megközelítést alkalmazni, hogy az á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ökkent, a pirosat pedig a nem megfelelő állapothoz. A színkódolt állapotok gyors azonosításával hatékonyan megtalálhatja az alkalmazások romlásának kiváltó okát.

Feljegyzés

Javasoljuk, hogy az egészségügyi modell irányítópultjának létrehozásakor vegye figyelembe a látássérültek akadálymentességi követelményeit. Az ajánlott diagramkészítési eljárásokért tekintse meg az architektúratervezési diagramokat.

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 különböző szerepkörökre

Az állapotmodellezés a feladatfüggvényekre vagy a szerepkörökre jellemző információkat biztosíthat a számítási feladat ugyanazon környezetében. Előfordulhat például, hogy egy DevOps-szerepkörnek működési állapotinformációra van szüksége. A biztonsági tisztek jobban aggódhatnak 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 átfedésben lévő adatkészletektő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. A tesztelés során ellenőrizheti a futtatókörnyezet működési állapotát, és felmérheti a modell hatékonyságát a skálázási és meghibásodási forgatókönyvekben, ha az állapotmodelleket beépíti a mérnöki életciklusba.

Szervezeti állapot

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

Egyéni számítási feladatok szintjén az állapotmodellek az alkalmazások megfigyelhetőségének és működési elemzéseinek alapjai. Minden alkalmazás rendelkezhet saját állapotmodellel, amely rögzíti, hogy az egyes állapotok mit jelentenek a környezetében.

Több állapotmodellt is kombinálhat egy magas szintű szerkezetbe egy modellmodell létrehozásával. Létrehozhatja például egy üzleti egység vagy egy teljes felhőtulajdon megfigyelhetőségi lábnyomát úgy, hogy egy nagyobb modellen belül az állapotmodelleket összetevőké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ások közötti függőségeket, beleértve az adatfolyamokat, a szolgáltatás-interakciókat és a megosztott infrastruktúrát.

Vegyünk egy kereskedelmi 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 az adott számítási feladat állapotát. Ezután egy szülőmodell használatával az összes összetevőállapot-modellt entitásokként képezheti le, és függőségi láncokon keresztül rögzítheti az alkalmazások közötti működési hatásokat. 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 AIOps (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 érdekében.

Az állapotmodell karbantartása

A heath-modell fenntartása folyamatos mérnöki tevékenység, amely összhangban van az alkalmazás fejlesztésével és működésével. 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 helyzetekben, amelyek hosszú távú mintaelemzést igényelnek az INFORMATIKAI műveletekhez szükséges mesterséges intelligenciában.

Feljegyzé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 állapotadat-mintavételek ASP.NET való implementálását lásd: Állapotellenőrzések a ASP.NET Core-ban.
• A monitorozási metrikákkal kapcsolatos információkért tekintse meg az Azure Monitor-metrikák áttekintését.
• Az Application Insights használatával kapcsolatos információkért tekintse meg az Application Insightst.
• A kritikus fontosságú számítási feladatokra vonatkozó tervezési szempontokért és javaslatokért tekintse meg az Azure-ban kritikus fontosságú számítási feladatok állapotmodellezését és megfigyelhetőségét.
• Gyakorlati tapasztalatért lásd : Állapotmodell tervezése a kritikus fontosságú számítási feladatokhoz.

Következő lépés

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