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

Az Operational Excellence kompromisszumai a Power Platform számítási feladatokhoz

  • Cikk

Az Operational Excellence egyértelmű csapatszabványok bevezetésével, a felelősség és elszámoltathatóság megértésével, az ügyfelek eredményeire való odafigyeléssel és a csapatkohézióval támogatja a munkaterhelés minőségét. Ezeknek a céloknak a megvalósítása a DevOpsban gyökerezik, amely a folyamat eltérésének minimalizálását, az emberi hibák csökkentését és végső soron a számítási feladat értékének megtérülésének növelését javasolja. Ezt az értéket nem csak a számítási feladat összetevői által kiszolgált funkcionális követelmények alapján méri a rendszer. Ezt az érték is méri, amelyet a csapat nyújt a fejlődésre való törekvésben.

A számítási feladatok tervezési fázisában és életciklusa során, ahogy a folyamatos fejlesztési lépések megtörténnek, fontos megfontolni, hogy az Operational Excellence tervezési alapelvein és az Operational Excellence tervezési felülvizsgálati ellenőrzőlistájában szereplő 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 tervezésekor.

Az Operational Excellence és a megbízhatóság kompromisszumai

Kompromisszum: Nagyobb komplexitás. A megbízhatóság az egyszerűséget helyezi előtérbe, mivel az egyszerű kialakítás minimalizálja a helytelen konfigurációt és csökkenti a váratlan interakciók számát.

  • A biztonságos üzembe helyezési stratégiák gyakran bizonyos mértékű előre- és visszamenőleges kompatibilitást igényelnek az alkalmazáslogika és a számítási feladatban lévő adatok között. Ez a hozzáadott összetettség növeli a tesztelési terhet, és összetettséghez vagy integritási problémákhoz vezethet a számítási feladat adataival.

  • A nagymértékben rétegzett, moduláris vagy paraméterezett struktúrák növelhetik a véletlen hibás konfiguráció esélyét a számítási feladat összetevői közötti interakció összetettsége miatt.

  • A műveletek számára előnyös felhőtervezési minták néha több összetevő bevezetését igénylik, például a titkos tároló használatát vagy a függőséget Application Insights. A további komponensek növelik a rendszer interakciós pontjait, növelve a hibás működés vagy a hibás konfiguráció lehetőségét.

Kompromisszum: Megnövekedett potenciálisan destabilizáló tevékenységek. A Megbízhatóság pillér ösztönzi az olyan tevékenységek vagy tervezési döntések elkerülését, amelyek destabilizálhatják a rendszert, és zavarokhoz, kimaradásokhoz vagy hibás működéshez vezethetnek.

  • A kisméretű, növekményes módosítások üzembe helyezése a kockázat csökkentésének egyik technikája, de a felhasználók elvárják, hogy ezek a kis módosítások gyakrabban kerüljenek éles környezetbe. A központi telepítések destabilizálhatják a rendszert, így az üzembe helyezés sebességének növekedésével ez a kockázat is nő.

  • Egy olyan kultúra, amely sebességmetrikákkal, például heti üzembe helyezésekkel méri magát, és olyan automatizálást használ, amely megkönnyíti a változások gyorsabb ütemben történő bevezetését, valószínűleg rövidebb idő alatt több üzembe helyezést is végrehajt.

  • A sűrűség növelése a műveletek egyszerűsítése érdekében a vezérlési és megfigyelési pontok számának csökkentésével szintén növelheti a rendelkezésre állási kockázatot, mivel a hibás működés vagy a helytelen konfiguráció növeli a destabilizáló esemény hatását.

Az Operational Excellence és a Security kompromisszumai

Kompromisszum: Nagyobb felület. A biztonsági pillér csökkentett munkaterhelési felületet javasol az összetevők és a műveleteknek való kitettség tekintetében. Ez a csökkentés minimalizálja a biztonsági réseket, és kisebb hatókört biztosít a biztonsági ellenőrzéshez és teszteléshez.

  • A számítási feladatot körülvevő és annak működését támogató összetevőknek, például az automatizálásnak vagy az egyéni vezérlősíknak is a rendszeres biztonsági megerősítés és tesztelés hatókörében kell lennie.

  • A rutinszerű, nem tervezett és vészhelyzeti műveletek növelik a munkaterheléssel való érintkezési pontokat. A zéró megbízhatósági megközelítés megköveteli, hogy ezek a folyamatok biztonsági réseknek minősüljenek, és szerepelniük kell a számítási feladat biztonsági vezérlőiben és érvényesítésében.

  • A rendszer megfigyelhetőségi platformja naplókat és metrikákat gyűjt a számítási feladatról, ami értékes információforrás lehet. Ezért a számítási feladat biztonságának ki kell terjednie a belső és külső fenyegetések véd adatfogadóira.

  • A buildügynökök, a külsőleges konfiguráció és a funkcióváltók tárházai mind növelik a biztonságot igénylő alkalmazásfelületet.

  • A kisméretű, növekményes módosítások vagy a "get current, stay current" erőfeszítések által okozott nagyobb telepítési gyakoriság több biztonsági tesztelést eredményez a szoftverfejlesztési életciklusban (SDLC).

Kompromisszum: Az átláthatóság iránti fokozott vágy. A biztonságos munkaterhelés olyan terveken alapul, amelyek véd a rendszer összetevőin átáramló adatok titkosságát.

A megfigyelhetőségi platformok minden típusú adatot betöltenek, hogy betekintést nyerjenek a számítási feladatok állapotába és viselkedésébe. Ahogy a csapatok nagyobb pontosságot próbálnak elérni a megfigyelhetőségi adatokban, egyre nagyobb a kockázata annak, hogy a forrásrendszerek adatbesorolási vezérlői, például az adatmaszkolás, nem terjednek ki a megfigyelhetőségi platform naplóira és naplófogadóira.

Kompromisszum: Csökkentett szegmentáció. A hozzáférés és a funkció elkülönítésének kulcsfontosságú biztonsági megközelítése egy erős szegmentálási stratégia kialakítása. Ez a kialakítás erőforrás-elkülönítéssel és identitásvezérlőkkel valósítható meg.

  • A különböző alkalmazás-összetevők megosztott környezetekben és adatforrásokban való közös elhelyezése a felügyelet megkönnyítése érdekében visszafordítja a szegmentálást, vagy megnehezíti a szerepköralapú szegmentálás elérését. Előfordulhat, hogy a közös elhelyezésű összetevőknek meg kell osztaniuk egy számítási feladat identitását, ami az engedélyek túlzott hozzárendeléséhez vagy a nyomon követhetőség hiányához vezethet.

  • Ha az összes naplót összegyűjti a rendszerben egy egységes naplófogadóban, megkönnyítheti a riasztások lekérdezését és felépítését. Ez azonban megnehezítheti vagy lehetetlenné teheti a bizalmas adatok szükséges naplózási vezérlőkkel való kezeléséhez szükséges soralapú biztonság biztosítását.

  • Az attribútum- vagy szerepköralapú biztonság kezelésének egyszerűsítése a szerepkörök és hozzárendeléseik részletességének csökkentésével nem megfelelően széles körű engedélyekhez vezethet.

Működési kiválósági kompromisszumok élményoptimalizálással

Kompromisszum: Versengő prioritások. Az Élményoptimalizálás pillér felhasználóközpontú gondolkodásmódot javasol.

  • Előfordulhat, hogy a jelentős erőforrásokat igénylő felhasználói élmény fejlesztése nem lesz prioritásos, ami azt okozhatja, hogy a felhasználói élmény nem rendelkezik a számítási feladatok felhasználóinak szükséges használhatósággal, interakciókkal és vizuális kialakítással.

  • A felhasználói felület fejlesztése gyakran gyorsabb iterációkban és szállítási ciklusokban történik, ami megterhelheti a csapat SDLC-folyamatait.

Az Operational Excellence és a teljesítményhatékonyság kompromisszumai

Kompromisszum: Megnövekedett erőforrás-kihasználtság. A Teljesítményhatékonyság pillér azt javasolja, hogy a rendelkezésre álló számítási és hálózati erőforrásokból a lehető legtöbbet foglalja le a számítási feladat követelményeihez.

  • A számítási feladatok figyelési keretrendszere megköveteli, hogy az architektúra összetevői időt és erőforrásokat foglaljanak le a naplók és metrikák létrehozásához, gyűjtéséhez és streameléséhez. Ezek az adatpontok segítenek biztosítani, hogy a hatékony riasztások és monitorozás lehetséges legyen a megbízhatóság, a biztonság és a teljesítmény érdekében. A rendszerállapotok szintjének növekedésével a rendszer erőforrásainak terhelése is növekedhet.

Kompromisszum: Nagyobb késés. A nagy teljesítményű számítási feladatok létrehozásához a csapatok olyan módszereket keresnek, amelyekkel csökkenthetik a számítási feladatok által a feladataik elvégzéséhez felhasznált időt és erőforrásokat.

  • Egyes felhőtervezési minták, amelyek támogatják a "független változás az idő múlásával" megközelítéseket a növekményes fejlesztés ideáljainak támogatása érdekében, késést vezethetnek be a további összetevők bejárása miatt.