Share via

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

  • 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 folyamateltérés 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 feladat 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ő javaslatokon alapuló döntések 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 kompromisszumokat jelentenek mások számára. Ez a cikk a számítási feladatok architektúrájának és műveleteinek tervezésekor a számítási feladatokkal foglalkozó csapat által tapasztalt kompromisszumokat ismerteti.

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

Kompromisszum: Megnövekedett összetettség. A megbízhatóság elsőbbséget ad az egyszerűségnek, 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 bizonyos mértékű előre- és visszamenőleges kompatibilitást az alkalmazáslogika és a számítási feladat adatai között. Ez az ö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.

  • Az erősen rétegzett, modularizált vagy paraméteres infrastruktúra kódként való használata 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 előnyére szolgáló 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-üzemelő példányok koordinálását egy tárolóalapú alkalmazásplatformon. A további összetevők növelik a rendszer interakciós pontjait, növelve a hibás működés vagy a 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 függőségeket vezetnek be a szolgáltatásfelderítéstől, vagy akár a DNS-t is indirekt rétegként. 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 döntések elkerülését ösztönzi, amelyek destabilizálhatják a rendszert, és fennakadásokhoz, üzemkimaradá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ének egyik technikája, 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.

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

  • A vezérlési és megfigyelhetőségi felületek számának csökkentésével a műveletek egyszerűsítése érdekében a sűrűség növelése a rendelkezésre állási kockázat növekedéséhez is vezethet, 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 kompromisszumai a biztonsággal

Kompromisszum: Nagyobb felület. A Biztonsági pillér az összetevők és a műveleteknek való kitettség szempontjából alacsonyabb 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ági ellenőrzéshez és teszteléshez.

  • A számítási feladatot 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 edukáláshoz é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 zéró 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, hogy megvédje az adatfogyókat a belső és külső fenyegetésektől.

  • Ügynökök létrehozása, külső konfiguráció és funkcióváltó tárolók, valamint egymás melletti ü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, naprakész állapot" erőfeszítések által okozott magasabb üzembe helyezési gyakoriság nagyobb biztonsági tesztelést eredményez a szoftverfejlesztési életciklusban.

Kompromisszum: Az átláthatóság iránti megnövekedett 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 megbízhatóságot próbálnak elérni a megfigyelhető adatokban, nagyobb a kockázata annak, hogy a forrásrendszerek adatbesorolás-vezérlései, például az adatmaszkolás, nem terjednek ki a megfigyelhetőségi platform naplóira és napló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ési é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 közös keresése a felügyelet megkönnyítése érdekében megfordítja a szegmentálást, vagy megnehezíti a szerepköralapú szegmentálás elérését. Előfordulhat, hogy a közösen elhelyezett ö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 rendszer egészéből egy egyesített naplógyűjtőben, egyszerűbbé teheti a lekérdezéseket és a riasztások készítését. Ez azonban megnehezítheti vagy lehetetlenné teheti a soralapú biztonság biztosítását, hogy a bizalmas adatokat a szükséges naplózási vezérlőkkel kezelje.

  • 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.

Működési kiválósági kompromisszumok a költségoptimalizálással

Az Operatív kiválóság 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. Azok a javaslatok, amelyek úgy tűnik, hogy a kézbesítési tevékenységekre összpontosítanak, figyelembe veszik a számítási feladat és a csapat hosszú távú legjobb érdekeit. Ha a számítási feladat közel van a napnyugta dátumához, valószínűleg nincs értelme nagy mértékben befektetni azokba a javaslatokba, amelyek kiváltják ezeket a kompromisszumokat.

Kompromisszum: Megnövekedett erőforrás-kiadások. 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 kifejezettebb 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ásifeladat-összetevőket kell bevezetnie a működéshez igazított felhőtervezési minták vagy a számítási feladatok automatizálásának implementálásához. Az üzembe helyezés rugalmasságának támogatásához 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 az éles igényeknek megfelelő 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ásszám, a termékváltozatok é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ásként jelennek meg, a megfigyelhető platformok hatékonyságának lehetővé tétele érdekében ezeket az adatokat meg kell őrizni. A legtöbb operatív adattár a betöltési arányok és a mennyiség kombinációján alapuló díjszabással rendelkezik. Általában az alacsony késé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 adatfogyó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 kézbesítési tevékenységekre való összpontosítás. A számítási feladatokért felelős csapat 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, 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. Ahogy a támogatási tevékenység növekszik (például a hivatalos ügyeleti rotációk), á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özvetve 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ért felelős csapat személyes folyamatos fejlesztési folyamatának kritikus része. Ez a képzés lehet formális vagy önirányító 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ény-haté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. Néhány példa ezekre a feladatokra: átfogó változáshatás-elemzés, változásvezérlési folyamatok, alapos tesztelés és fokozott javításkezelés. Ahogy ezeknek a feladatoknak a gyakorisága, átfogósága vagy működési terhe nő, a befektetett idő is nő.

Kompromisszum: Megnövekedett eszközigény é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ő szintű 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özök 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 munkaállomásonként vagy webhelyenkéntiek 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 várt eszköz- vagy hardverköltségre, amely a működési kiválóság alapelveihez kapcsolódik:

  • Követelmények és hátralékkezelé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 alacsony 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

Működési kiválósági kompromisszumok teljesítményhatékonysággal

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

  • A számítási feladatok megfigyelhetőségi keretrendszeréhez az architektúra összetevőinek időt és erőforrásokat kell lefoglalnia 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 monitorozás lehetséges legyen a megbízhatóság, a biztonság és a teljesítmény szempontjából. A rendszerállapot növekedésével a rendszererőforrások terhelése is nőhet.

  • Egyes üzembehelyezési 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 hogy a visszaállítás támogatásához egy ideig többnyire alvó üzemelő példány legyen érvényben.

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 végrehajtásához felhasznált időt és erőforrásokat.

  • Számos üzembehelyezési modell esetében átjáró-útválasztási hozzáférési minták használatára van szükség, amelyek késést okozhatnak. 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 növekményes fejlesztés eszményeit támogató "független változás az idő múlásával" megközelítéseket, 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 korrupcióellenes rétegek is okozhatják.

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