A számítási feladatok megbízhatóságának kompromisszumai Power Platform
A megbízható számítási feladatok következetesen megfelelnek a meghatározott megbízhatósági célkitűzéseknek. El kell érnie a meghatározott rugalmassági célokat, ideális esetben a megbízhatóságot befolyásoló események megkerülésével. Reálisan nézve azonban a munkaterhelésnek tolerálnia és ellenőriznie kell az ilyen események hatását, és aktív meghibásodás esetén előre meghatározott szinten kell tartania a műveleteket. Még katasztrófa esetén is a megbízható munkaterhelésnek adott időn belül vissza kell állnia egy adott állapotba, mindkettőről az érdekelt felek megállapodnak. Létfontosságú egy olyan incidens válasz terv, amely lehetővé teszi a gyors észlelést és helyreállítást.
A számítási feladatok tervezési fázisában át kell gondolnia, hogy a megbízhatóság tervezési alapelvein és a megbízhatóság tervezési felülvizsgálati ellenőrzőlistájában található javaslatokon alapuló döntések hogyan befolyásolhatják más pillérek céljait és optimalizálását. Bizonyos döntések egyes pillérek számára előnyösek lehetnek, mások számára azonban kompromisszumot jelenthetnek. Ez a cikk olyan kompromisszumokat ismertet, amelyekkel a számítási feladatok csapata találkozhat a számítási feladatok architektúrájának és műveleteinek megbízhatósági tervezése során.
A megbízhatóság és a biztonság kompromisszumai
Kompromisszum: Nagyobb munkaterhelési felület. A Biztonság oszlop a csökkentett és zárt felületet részesíti előnyben a támadási vektorok minimalizálása és a biztonsági vezérlők kezelésének csökkentése érdekében.
A megbízhatóság gyakran replikációval érhető el. A replikáció történhet az összetevők szintjén, az adatok szintjén vagy akár földrajzi szinten is. A replikák kialakításukból adódóan növelik a számítási feladatok felületét. Biztonsági szempontból a csökkentett és zárt felület előnyös a potenciális támadási vektorok minimalizálása és a biztonsági ellenőrzések kezelésének egyszerűsítése érdekében.
Hasonlóképpen, a vészhelyreállítási megoldások, például a biztonsági mentések, növelik a számítási feladatok felületét. Ezek azonban gyakran el vannak különítve a számítási feladat futásidejétől. Ehhez további biztonsági vezérlők végrehajtására van szükség, amelyek a vészhelyreállítási megoldásra jellemzőek lehetnek.
A megbízhatósági célok érdekében további komponensekre lehet szükség az architektúrához, ami növeli a felületet. Ez a megnövekedett összetettség növeli a számítási feladat felületét azáltal, hogy új összetevőket ad hozzá, amelyeket biztonságossá kell tenni, esetleg olyan módon, amelyet a rendszer még nem használ. Ezeket az összetevőket általában további kód kíséri a használatuk vagy az általános megbízhatósági minták támogatásához, ami szintén növeli az alkalmazás felületét.
Ha egy számítási feladat olyan megbízhatósági eseményt tapasztal, amelyet az aktív incidens válasz kezel, a sürgősség nyomást gyakorolhat a számítási feladatok csapataira, hogy megkerüljék a rutinszerű hozzáférésre optimalizált biztonsági vezérlőket.
A hibaelhárítási tevékenységek miatt a csapat ideiglenesen letilthatja a biztonsági protokollokat, így az amúgy is stresszes rendszer további biztonsági kockázatoknak lehet kitéve. Fennáll annak a kockázata is, hogy a biztonsági protokollok nem lesznek azonnal visszaállítva.
A biztonsági vezérlők részletes megvalósítása, például a szerepköralapú hozzáférés-vezérlési hozzárendelések vagy a tűzfalszabályok bonyolultabbá és érzékenység vezetnek be, növelve a helytelen konfiguráció esélyét. A megbízhatóságra gyakorolt lehetséges hatás széles körű szabályokkal való enyhítése mindhárom Teljes felügyelet architektúra alapelvét erodálja.
A kiadási hullám frissítéseinek vagy a szállítói kódtárak, például harmadik féltől származó összetevők vagy megoldások frissítéseinek alkalmazása megzavarhatja a célösszetevőt, ami elérhetetlenséget okozhat a módosítás során. A javítás késleltetésével vagy elkerülésével elkerülhetők a lehetséges megbízhatósági kockázatok, de védtelenül hagyja a rendszert a változó fenyegetésekkel szemben.
Az előző szempont a számítási feladat kódjára is vonatkozik. Például olyan alkalmazáskódra vonatkozik, amely régi kódtárakat és összetevőket használ. Ha az alkalmazáskód frissítését és üzembe helyezését nem csökkentett megbízhatósági kockázatnak tekintjük, az alkalmazás idővel további biztonsági kockázatoknak van kitéve.
A megbízhatóság és a kiváló működés kompromisszumai
A számítási feladatok átfogó monitorozási stratégiája a működési kiválóság kulcsfontosságú része. Ha további összetevőket vezet be egy architektúrába a megbízhatósági tervezési minták megvalósításához, több adatforrást kell kezelnie, ami növeli az elosztott nyomkövetés és megfigyelhetőség megvalósításának összetettségét.
Ha több régiót használ az egyrégiós erőforrás-kapacitás korlátainak leküzdésére és/vagy egy aktív/aktív architektúra megvalósítására, az növeli a számítási feladatok üzemeltetési felügyeletének összetettségét. Ezt az összetettséget a több régió kezelésének szükségessége és a közöttük lévő adatreplikáció kezelésének szükségessége vezeti be.
Ahogy a számítási feladatok robusztusabbá válnak a megbízhatósági összetevők és minták hozzáadásával, több időt vesz igénybe az üzemeltetési eljárások és az összetevők dokumentációjának fenntartása.
A betanítás összetettebbé válik, ahogy a munkaterhelésben lévő összetevők száma növekszik. Ez az összetettség hatással van a bevezetéshez szükséges időre, és növeli a termékfejlesztési ütemtervek és a szolgáltatásiszint-útmutatás nyomon követéséhez szükséges ismereteket.
Kompromisszumok a megbízhatóság terén a Felhasználói élmény optimalizálásával
A szigorú tesztelés hangsúlyozása késleltetheti a bevezetéshez elengedhetetlen felhasználói élmény funkciók kiadását.
A megbízhatóságra való optimalizálás túlindexelheti az összetettség minimalizálását, ami csökkenti a funkciók prioritását a vonzóbb felhasználói élmény, például az egyéni összetevők és integrációk érdekében.
A megbízhatóság és a teljesítményhatékonyság kompromisszumai
A megbízhatósági minták gyakran tartalmaznak adatreplikációt a replika hibás működésének túlélése érdekében. A replikáció további késést vezet be a megbízható adatírási műveletekhez, ami egy adott felhasználó vagy adatfolyam teljesítményköltségvetésének egy részét felhasználja.
A megbízhatóság néha az erőforrás-elosztás különböző formáit alkalmazza a terhelés kifogástalan állapotú replikák közötti elosztására vagy újraelosztására. A kiegyensúlyozáshoz használt dedikált összetevők általában befolyásolják a kiegyensúlyozott kérés vagy folyamat teljesítményét.
Az összetevők földrajzi határokon vagy rendelkezésre állási zónákon keresztüli elosztása a hatókörrel rendelkező hatások túlélése érdekében hálózati késést vezet be a rendelkezésre állási határokon átnyúló összetevők közötti kommunikációban.
A számítási feladatok állapotának megfigyelésére kiterjedt folyamatokat használnak. Bár a figyelés kritikus fontosságú a megbízhatóság szempontjából, a rendszerállapot-kialakítás hatással lehet a rendszer teljesítményére. A megfigyelhetőség növekedésével a teljesítmény csökkenhet.
Az automatikus skálázási műveletek nem azonnaliak, ezért nem képesek megbízhatóan kezelni a hirtelen és drámai igénynövekedést, amelyet nem lehet alakítani vagy simítani. Ezért a nagyobb példányokon vagy több példányon keresztüli túlépítés kritikus megbízhatósági taktika a keresleti jel és a kínálat létrehozása közötti késés figyelembevétele érdekében. A kihasználatlan kapacitás ellensúlyozza a teljesítményhatékonyság céljait.
Előfordulhat, hogy egy összetevő nem méretezhető az igényeknek megfelelően, és ez az igény nem teljesen kiszámítható. Ha nagy példányokat használ a legrosszabb eset lefedésére, az a hulladék túlzott kiépítéséhez vezet olyan helyzetekben, amelyek kívül esnek a használati eseten.