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

Az Operational Excellence kompromisszumoi

  • Cikk

Az operatív kiválóság egyértelmű csapatszabványok, érthető felelősség és elszámoltathatóság, az ügyfelek eredményeire való figyelem és a csapat kohéziója révén biztosítja a számítási feladatok minőségét. Ezeknek a céloknak a megvalósítása a DevOpsban gyökerezik, amely a folyamat varianciájának 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 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érik. Azt is mérik, hogy a csapat milyen értéket ad a fejlesztésre való törekvés során.

A számítási feladatok tervezési fázisában és életciklusa során, a folyamatos fejlesztési lépések végrehajtásával fontos figyelembe venni, hogy az operatív kiválóság tervezési alapelvein és az operatív kiválóságra vonatkozó tervezési felülvizsgálati ellenőrzőlistán szereplő javaslatok hogyan befolyásolhatják más pillérek céljait és optimalizálását. Bizonyos döntések bizonyos pillérek előnyére válhatnak, de kompromisszumot jelentenek mások számára. Ez a cikk azokat a példákat ismerteti, amelyekkel a számítási feladatokkal foglalkozó csapatok találkozhatnak a számítási feladatok architektúrája és műveleteinek tervezésekor.

Az Operational Excellence kompromisszumoi a megbízhatósággal

Kompromisszum: Fokozott összetettség. A megbízhatóság előnyben részesíti az egyszerűséget, mivel az egyszerű kialakítás minimalizálja a helytelen konfigurációt, és csökkenti a váratlan interakciókat.

  • A biztonságos üzembehelyezési stratégiák gyakran igényelnek némi előre- és visszamenőleges kompatibilitást az alkalmazáslogika és a számítási feladat adatai 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 kapcsolatban.

  • A kódként használt magas rétegzett, modularizált vagy paraméteres infrastruktúra növelheti a véletlen helytelen konfiguráció esélyét a kódösszetevők közötti interakció összetettsége miatt.

  • A műveletek számára előnyös felhőtervezési minták néha további összetevők bevezetését teszik szükségessé, például egy külső konfigurációs tároló használatát vagy a sidecar-telepítések koordinálását egy tárolóalapú alkalmazásplatformon. A további összetevők és a hozzáadott indirekt rétegek növelik a rendszer interakcióinak pontjait, növelve a hibás vagy helytelen konfiguráció felületét.

  • Az agilis fejlesztést és üzemeltetést támogató önálló fejlesztésre tervezett számítási feladatok összetevői közvetett rétegként függőségeket vezetnek be a szolgáltatásfelderítéstől. Előfordulhat, hogy a szolgáltatásfelderítés nem reagál a változásra, és a hibás működést nehéz diagnosztizálni.

Kompromisszum: Megnövekedett potenciálisan destabilizáló tevékenységek. A megbízhatósági pillér olyan tevékenységek vagy tervezési lehetőségek elkerülését ösztönzi, amelyek destabilizálhatják a rendszert, és fennakadásokhoz, kimaradásokhoz vagy meghibásodásokhoz vezethetnek.

  • A kisebb, növekményes módosítások üzembe helyezése a kockázat mérséklésére szolgáló technika, de ezek a kisebb módosítások várhatóan gyakrabban kerülnek éles környezetbe. Az üzemelő példányok destabilizálhatják a rendszert, így az üzembe helyezés gyakoriságának növekedésével ez a kockázat is fennáll.

  • Az a kultúra, amely a heti üzemelő példányokhoz hasonló sebességmetrikákkal méri magát, és olyan automatizálást használ, amely gyorsabb ütemben segíti a változások bevezetését, valószínűleg rövidebb időn belül több üzembe helyezést is végrehajt.

  • A műveletek egyszerűsítése érdekében a vezérlési és megfigyelhetőségi felületek számának csökkentésével növelhető a rendelkezésre állás kockázata is, mivel a hibás működés vagy a helytelen konfiguráció növeli a destabilizáló esemény hatássugarát.

Az Operational Excellence és a Security közötti kompromisszumok

Kompromisszum: Nagyobb felület. A biztonsági pillér az összetevők és a műveleteknek való kitettség szempontjából csökkentett számítási feladatok felületét javasolja. Ez a csökkentés minimalizálja a támadási vektorokat, és kisebb hatókört biztosít a biztonság ellenőrzéséhez és teszteléséhez.

  • A számítási feladatokat körülvevő és a műveleteit támogató összetevőknek, például az automatizálásnak vagy az egyéni vezérlősíknak is hatókörrel kell rendelkeznie a rendszeres biztonsági edzettséghez és teszteléshez.

  • A rutin, az alkalmi és a vészhelyzeti műveletek növelik a számítási feladatokkal való kapcsolattartási pontokat. A nulla megbízhatósági megközelítés megköveteli, hogy ezek a folyamatok támadási vektoroknak minősülnek, é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ófeltárási forrás lehet. Ezért a számítási feladat biztonságának ki kell terjednie az adatgyűjtők belső és külső fenyegetésekkel szembeni védelmére.

  • Az ügynökök létrehozása, a külső konfiguráció és a funkcióváltó tárolók, valamint a párhuzamos üzembe helyezési megközelítések mind növelik a biztonságot igénylő alkalmazásfelületet.

  • A kisebb, növekményes változások vagy az "aktuális állapot megőrzése" erőfeszítések által okozott nagyobb üzembe helyezési gyakoriság nagyobb biztonsági tesztelést eredményez a szoftverfejlesztési életciklusban.

Kompromisszum: Megnövekedett az átláthatóság iránti vágy. A biztonságos számítási feladatok olyan kialakításokon alapulnak, amelyek védik a rendszer összetevőin áthaladó adatok bizalmasságát.

A megfigyelhető platformok minden típusú adatot betöltenek, hogy betekintést nyerjenek a számítási feladatok állapotába és viselkedésébe. Miközben a csapatok nagyobb hűséget próbálnak elérni a megfigyelhető adatokban, 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ós fogadóira.

Kompromisszum: Csökkentett szegmentálás. A hozzáférés és a funkció elkülönítésének egyik legfontosabb 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ósul meg.

  • A megosztott számítási, hálózati és adaterőforrások eltérő alkalmazásösszetevőinek együttes elhelyezése a felügyelet megkönnyítése érdekében a szegmentálás megfordítása vagy a szerepköralapú szegmentálás nehezebbé tétele érdekében. Előfordulhat, hogy a közösen elhelyezett összetevőknek meg kell osztaniuk a 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 teljes rendszerből egy egységes naplógyűjtőben, egyszerűbbé teheti a lekérdezést és a riasztások készítését. Ez azonban megnehezítheti vagy lehetetlenné teheti a soralapú biztonság biztosítását a bizalmas adatoknak a szükséges naplózási vezérlőkkel való kezelése érdekében.

  • Az attribútumalapú 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 helytelenül széles körű engedélyekhez vezethet.

Az Operational Excellence kompromisszumoi a költségoptimalizálással

Az Operational Excellence pillér soha nem javasol olyan tevékenységeket, amelyek csökkentik a termelékenységet, vagy veszélyeztetik a számítási feladatok megtérülését. Az olyan javaslatok, amelyek úgy tűnik, hogy a kézbesítési tevékenységekre összpontosítanak, figyelembe veszik a munkaterhelés és a csapat hosszú távú legjobb érdekeit. Ha a számítási feladat közeledik a naplemente dátumához, valószínűleg nem érdemes nagy mértékben befektetni az ilyen kompromisszumokat kiváltó javaslatokba.

Kompromisszum: Megnövekedett erőforrásköltség. A számítási feladatok egyik fő költségillesztője az erőforrások költsége. A kevesebb erőforrás üzembe helyezése, az erőforrások megfelelő méretezése és a fogyasztás csökkentése általában segít alacsonyan tartani a költségeket.

  • A biztonságos üzembehelyezési eljárások megvalósítása még akkor is, ha a módosítások viszonylag kicsik, az egyidejűleg üzembe helyezett erőforrások számának növekedéséhez vezethet. Ezekhez a mintákhoz az alkalmazás vagy az infrastruktúra-összetevő több egyidejű példányának üzembe helyezésére van szükség, hogy a forgalom szabályozott módon elmozduljon. Ez a növekedés hangsúlyosabb az olyan számítási feladatokban, amelyek nem módosítható infrastruktúra-megközelítést használnak.

  • Előfordulhat, hogy a csapatnak további számítási feladat-összetevőket kell bevezetnie ahhoz, hogy működéshez igazított felhőtervezési mintákat vagy számítási feladatok automatizálását implementálhassa. Az üzembe helyezés rugalmasságának támogatása érdekében például hozzáadhatnak egy átjáró-útválasztási összetevőt. A jobb konfigurációkezelés érdekében külső konfigurációs tárolót is hozzáadhatnak. A bérlői életciklus-események támogatásához létrehozhatnak egy vezérlősíkot. Ezek az erőforrások az üzem előtti környezetek költségeit is befolyásolják.

  • Az előkészítési környezetek számának növelése a fejlesztési és tesztelési élmény elkülönítéssel történő javítása érdekében szintén növeli az erőforrások számát. Ezek az erőforrások, amelyek nem a termelési igényeknek való kínálat biztosítására szolgálnak, növelik a megoldás költségeit.

  • Az üzem előtti környezetek és az éles környezetek paritásának növelése az erőforrások száma, az SKU-k és az adatmennyiségek tekintetében javítja a minőségbiztosítási folyamatot. A költség a paritás növekedésével nő.

  • Bár a telemetriai adatok nem közvetlenül erőforrásnak minősülnek, a megfigyelhető platformok hatékonyságának érdekében ezeket az adatokat meg kell őrizni. A legtöbb operatív adattár a betöltési sebesség és a mennyiség kombinációján alapuló díjszabással rendelkezik. Általában az alacsony késleltetésű, nagy sokféleségű telemetriai adatok mennyiségének növekedésével a költségek is növekednek. A többrégiós üzemelő példányok esetében ezek az operatív adatgyűjtők várhatóan régiónként lesznek üzembe helyezve, így az erőforrásonkénti költségek tényezővé válnak.

Kompromisszum: Csökkent a szállítási tevékenységekre való összpontosítás. A számítási feladatok csapatának tagjai a képességeikhez igazodó feladatok hatékony végrehajtásával növelik a számítási feladatok értékét.

  • Azok a számítási feladatok csapatai, amelyek időt töltenek egy kifogástalan és felelős támogatási struktúra és incidensmegoldás létrehozásával és finomításával, értékes szolgáltatást nyújtanak a számítási feladat felhasználóinak. A támogatási munka növekedésével (például a hivatalos ügyeleti rotációkkal) általában az üzleti kritikusság változása miatt ezeknek a tevékenységeknek a költségei növekednek. Ez a költségnövekedés az alkalmazottak számának növekedéséből eredhet, vagy közvetetten is felmerülhet olyan figyelem formájában, amely a kézbesítési tevékenységekről a támogató funkciókra kerül át.

  • A betanítás a számítási feladatok csapatának személyes folyamatos fejlesztési folyamatának kritikus része. Ez a képzés lehet formális vagy önirányított a személyes gazdagodás ideje alatt. A betanítási idő növekedésével csökken a számítási feladat közvetlen fejlesztéséhez rendelkezésre álló idő. A betanításba való befektetés csökken, ha a képzés nem szerepköralapú, vagy kifejezetten a számítási feladatra vagy annak jövőjére vonatkozik.

  • A számítási feladatok megbízhatóságának, biztonságának és teljesítményhatékonyságának védelméhez szükséges szabványosított rutinműveletek meghatározása, finomítása és végrehajtása időt vesz igénybe. Ez az idő nem közvetlenül a kézbesítésre van fordítva. Ilyen feladatok például az átfogó változáshatás-elemzés, a változásvezérlési folyamatok, az alapos tesztelés és a javítások fokozott felügyelete. Ahogy ezeknek a feladatoknak a gyakorisága, átfogósága vagy működési terhe nő, a befektetett idő is nő.

Kompromisszum: Nagyobb szerszámhasználati igények és sokszínűség. A Költségoptimalizálás pillér az eszközhasználat csökkentését, a szállítók összevonását és az eszközvásárlások megfelelő megközelítését javasolja.

A számítási feladatokért felelős csapat eszközöket és hardvereket vásárol a teljes szoftverfejlesztési életciklus (SDLC) során végrehajtott tevékenységek támogatásához, beleértve a tervezést és tervezést, a fejlesztést és a tesztelést, valamint a monitorozást. Egyre nő az eszközhasználat piactere ebben a térben. Az eszközöket különböző árpontokon kínáljuk, amelyek általában megfelelnek az eszközök funkcióinak és képességeinek. Az ingyenes ajánlatok kivételével ezek az eszközök kezdeti licencelési költségekkel járnak, amelyek felhasználónként, eszközönként vagy webhelyszintűek lehetnek. Gyakran folyamatos karbantartási szerződéseket is igényelnek. Előfordulhat, hogy új szállítói kapcsolatokat kell létrehozni. Íme néhány példa a működési kiválóság alapelveihez kapcsolódó eszköz- vagy hardverköltségre:

  • Követelmények és teendőlista-kezelés
  • Architektúratervező eszközök
  • Felhasználói felület/UX tervezőeszközök
  • Kód és eszköz üzemeltetése
  • Kód- és kis kódszámú fejlesztési környezetek
  • Automatizálási eszközök
  • Fejlesztési és minőségbiztosítási munkaállomások
  • Fejlesztési és üzembehelyezési folyamatok
  • Végrehajtás és nyomon követés tesztelése
  • Megfigyelhetőségi eszközök

Az Operational Excellence kompromisszumoi a teljesítményhatékonysággal

Kompromisszum: Nagyobb 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 lehetőségek közül a lehető legtöbb legyen a számítási feladat követelményeihez rendelve.

  • A számítási feladatok megfigyelhetőségi keretrendszere megköveteli, hogy az architektúra összetevői időt és erőforrásokat rendeljenek a naplók és metrikák létrehozásához, gyűjtéséhez és streameléséhez. Ezek az adatpontok biztosítják, hogy a hatékony riasztás és figyelés a megbízhatóság, a biztonság és a teljesítmény szempontjából lehetséges legyen. A rendszerállapot növekedésével a rendszererőforrások terhelése is nőhet.

  • Egyes üzemi modellek, például a kék/zöld üzembe helyezés, amelyeket a számítási feladatok a biztonságos üzembe helyezéshez használhatnak, párhuzamos üzembe helyezéseket eredményezhetnek az éles alkalmazásplatformon. Ezek az üzemelő példányok előzetes skálázást igényelnek ahhoz, hogy elegendő kínálatot biztosítsanak a jövőbeli igények kielégítéséhez, vagy egy többnyire alvó üzemelő példányt hagyjanak érvényben egy ideig a visszaállítás támogatásához.

Kompromisszum: Megnövekedett késés. A feladatokat végző 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.

  • Számos üzemi modellhez átjáró-útválasztási hozzáférési minták használata szükséges, ami késést okozhat. Ez a késés a kapcsolódó folyamatok teljesítménycél-költségvetéséhez kapcsolódik.

  • Egyes felhőtervezési minták, amelyek támogatják a "független változás idővel" megközelítéseket a növekményes fejlesztés eszményeinek támogatásához, késést okozhatnak a további összetevők bejárása miatt. Ezt a késést átjárók, üzenetközvetítők vagy sérülésgátló rétegek is okozhatják.

Ismerkedjen meg a többi pillérre vonatkozó kompromisszumokkal: