Költségoptimalizálási kompromisszumok

  • Cikk

Amikor olyan számítási feladatot tervez, amely pénzügyi korlátozások mellett maximalizálja a megtérülést (ROI), először egyértelműen meghatározott funkcionális és nem funkcionális követelményekre van szükség. A munka- és erőfeszítés-rangsorolási stratégia elengedhetetlen. Az alapítvány egy olyan csapat, amely erős pénzügyi felelősséggel rendelkezik. A csapatnak ismernie kell az elérhető technológiákat és azok számlázási modelljeit.

Miután megismerte egy számítási feladat megtérülését, megkezdheti annak fejlesztését. A megtérülés javítása érdekében gondolja át, hogy a Költségoptimalizálás tervezési alapelvein és a Költségoptimalizálás tervezési felülvizsgálati ellenőrzőlistáján szereplő javaslatokon alapuló döntések hogyan befolyásolhatják más Azure Well-Architected Framework-alappillérek céljait és optimalizálását. A költségoptimalizálás érdekében fontos, hogy ne az olcsóbb megoldásokra összpontosítsunk. Azok a döntések, amelyek csak a költségek minimalizálására összpontosítanak, növelhetik a számítási feladatok üzleti céljainak és hírnevének aláásásának kockázatát. Ez a cikk a számítási feladatokért felelős csapat által a költségoptimalizálás célbeállításának, kialakításának és műveleteinek figyelembe vétele során felmerülő lehetséges kompromisszumokat ismerteti.

Költségoptimalizálási kompromisszumok a megbízhatósággal

A szolgáltatáskimaradás költségeit az egyik szolgáltatás megelőzésének vagy helyreállításának költségével kell mérni. Ha a fennakadások költsége meghaladja a megbízhatóság tervezésének költségeit, érdemes többet befektetnie a fennakadások megelőzése vagy csökkentése érdekében. Ezzel szemben a megbízhatósági erőfeszítések költsége meghaladhatja a fennakadások költségeit, beleértve az olyan tényezőket is, mint a megfelelőségi követelmények és a hírnév. A megbízhatósági tervezésben csak ebben a forgatókönyvben érdemes megfontolni a stratégiai elidegenítést.

Kompromisszum: Csökkentett rugalmasság. A számítási feladatok rugalmassági intézkedéseket tartalmaznak, hogy megpróbálják elkerülni és ellenálljon bizonyos típusú és mennyiségű hibás működésnek.

  • A megtakarítás érdekében a számítási feladatokért felelős csapat alulprojektelhet egy összetevőt, vagy túlkényeztetheti annak méretezését, így az összetevő nagyobb eséllyel hiúsul meg a hirtelen megugrások során.

  • A számítási feladatok erőforrásainak összevonásával (a sűrűség növelésével) a költségoptimalizálás érdekében az egyes összetevők nagyobb valószínűséggel hiúsulnak meg az igénynövekedések és a karbantartási műveletek, például a frissítések során.

  • A rugalmassági tervezési mintákat támogató összetevők, például az üzenetsínek eltávolítása és a közvetlen függőségek létrehozása csökkenti az önmegőrző képességeket.

  • A redundancia csökkentésével pénzt takaríthat meg, ami korlátozhatja a számítási feladatok egyidejű meghibásodásainak kezelését.

  • A tervezett termékváltozatok használata korlátozhatja a számítási feladat által elérhető maximális szolgáltatásiszint-célkitűzést (SLO).

  • A kemény költségkeretek beállítása megakadályozhatja, hogy a számítási feladatok a jogos igényeknek megfelelően skálázhatók.

  • Megbízhatósági tesztelési eszközök vagy tesztek nélkül a számítási feladatok megbízhatósága ismeretlen, és kevésbé valószínű, hogy megfelel a megbízhatósági céloknak.

Kompromisszum: Korlátozott helyreállítási stratégia. A megbízható számítási feladatokhoz tesztelési incidensmegoldási és vészhelyreállítási terv tartozik.

  • A számítási feladatok vészhelyreállítási tervének csökkentett tesztelése vagy részletezése hatással lehet a helyreállítási műveletek sebességére és hatékonyságára.

  • Kevesebb biztonsági mentés létrehozása vagy megőrzése csökkenti a lehetséges helyreállítási pontokat, és növeli az adatok elvesztésének esélyét.

  • A kevésbé költséges támogatási szerződés növelheti a számítási feladatok helyreállítási idejét a műszaki segítségnyújtás esetleges késése miatt.

Kompromisszum: Megnövekedett összetettség. A megbízhatóság szempontjából általában könnyebben kezelhetők azok a számítási feladatok, amelyek egyszerű megközelítéseket használnak, és elkerülik a szükségtelen vagy túlterhelt összetettségeket.

  • A költségoptimalizálási felhőminták használatával új összetevőket adhat hozzá, például egy tartalomkézbesítési hálózatot (CDN), vagy áthelyezheti a feladatokat olyan peremhálózati és ügyféleszközökre, amelyeknek a számítási feladatnak megbízhatósági célokat kell biztosítania.

  • Az eseményalapú skálázást bonyolultabb lehet finomhangolni és ellenőrizni, mint az erőforrás-alapú skálázást.

  • Az adatmennyiség csökkentése és az adatok adatéletciklus-műveleteken keresztüli rétegezése – esetleg az összesített adatpontok életciklus-esemény előtti implementálásával együtt – megbízhatósági tényezőket vezet be a számítási feladatban.

  • Ha különböző régiókat használ a költségek optimalizálására, az megnehezítheti a felügyeletet, a hálózatkezelést és a monitorozást.

Költségoptimalizálási kompromisszumok a biztonsággal

A számítási feladatokban a titkosság, az integritás és a rendelkezésre állás sérülésének költségeit mindig el kell egyensúlyozni a biztonsági rés elkerülése érdekében tett erőfeszítések költségével. A biztonsági incidensek számos pénzügyi és jogi hatással járhatnak, és károsíthatják a vállalat hírnevét. A biztonságba való befektetés kockázatcsökkentő tevékenység. A kockázatok jelentkezésének költségeit el kell egyensúlyozni a befektetéssel. Általában ne sérüljön a biztonság, ha olyan költségoptimalizálást szeretne elérni, amely nem éri el a felelősségi pontot, és a kockázatcsökkentésről állapodott meg. A biztonsági költségek optimalizálása a megoldások jogosításával fontos optimalizálási gyakorlat, de ha így tesz, vegye figyelembe az alábbihoz hasonló kompromisszumokat.

Kompromisszum: Csökkentett biztonsági ellenőrzés. A biztonsági vezérlők több rétegben, néha redundánsan vannak kialakítva, hogy mélységi védelmet nyújtsanak.

A költségoptimalizálás egyik taktikája, hogy hogyan távolíthatók el az egység- vagy működési költségeket felhalmozó összetevők vagy folyamatok. Vegye figyelembe, hogy az alábbi példákhoz hasonló biztonsági összetevők eltávolítása a megtakarítás érdekében hatással van a biztonságra. Gondosan el kell végeznie egy kockázatelemzést erre a hatásra.

  • A hitelesítési és engedélyezési technikák csökkentése vagy egyszerűsítése veszélyezteti a megbízhatóság nélküli architektúra explicit módon történő ellenőrzését . Ilyen egyszerűsítések például az alapszintű hitelesítési sémák, például az előmegosztott kulcsok használata ahelyett, hogy időt fordítanának az iparági OAuth-megközelítések megismerésére, vagy egyszerűsített szerepköralapú hozzáférés-vezérlési hozzárendelések használata a felügyeleti többletterhelés csökkentése érdekében.

  • Az átvitel közben vagy inaktív állapotban lévő titkosítás eltávolítása a tanúsítványok és azok működési folyamatai költségeinek csökkentése érdekében az adatokat potenciális integritási vagy bizalmassági incidenseknek teszi ki.

  • A kapcsolódó költség- és időbefektetések miatt a biztonsági vizsgálati vagy vizsgálati eszközök vagy biztonsági tesztelés eltávolítása vagy csökkentése közvetlenül befolyásolhatja az eszköz és a tesztelés által védeni kívánt titkosságot, integritást vagy rendelkezésre állást.

  • A biztonsági javítás gyakoriságának csökkentése a katalogizálásba és a javítás végrehajtásába fektetett működési idő miatt hatással van a számítási feladatok változó fenyegetések kezelésére való képességére.

  • A hálózati vezérlők, például a tűzfalak eltávolítása a rosszindulatú bejövő és kimenő forgalom blokkolásának sikertelenségéhez vezethet.

Kompromisszum: Megnövekedett munkaterhelési terület. A Biztonsági pillér a támadási vektorok minimalizálása és a biztonsági vezérlők kezelése érdekében rangsorolja a csökkentett és zárt felületi területeket.

A költségeket optimalizáló felhőtervezési minták néha további összetevők bevezetését teszik szükségessé. Ezek a további összetevők növelik a számítási feladat felületét. Az összetevőket és a bennük lévő adatokat biztonságossá kell tenni, esetleg olyan módon, amely még nincs használatban a rendszerben. Ezek az összetevők és adatok gyakran megfelelőségi követelményeknek vannak kitéve. Példák az összetevők bevezetésére szolgáló mintákra:

  • Statikus tartalomtárolási minta használata adatok új CDN-összetevőre való kiszervezéséhez.

  • A Valet Key minta használata a feldolgozás kiszervezéséhez és az erőforrás-hozzáférés biztonságossá tételéhez az ügyfélszámításhoz.

  • A Queue-Based load leveling minta használata a költségek gördülékenyebbé gördítéséhez egy üzenetbusz bevezetésével.

Kompromisszum: Eltávolítva a szegmentálás. A biztonsági pillér fontossági sorrendbe helyezi az erős szegmentálást, hogy támogassa a célzott biztonsági vezérlők alkalmazását és a robbanási sugár szabályozását.

Az erőforrások megosztása, például több-bérlős helyzetekben, vagy több alkalmazás közös keresése egy megosztott alkalmazásplatformon a költségek csökkentésére a sűrűség növelésével és a felügyeleti felület csökkentésével. Ez a megnövekedett sűrűség az alábbihoz hasonló biztonsági problémákhoz vezethet:

  • Az erőforrásokat megosztó összetevők közötti oldalirányú mozgás egyszerűbb. Egy biztonsági esemény, amely veszélyezteti az alkalmazásplatform-gazdagép vagy az egyes alkalmazások rendelkezésre állását, szintén nagyobb sugárral rendelkezik.

  • A közösen elhelyezett erőforrások megoszthatják a számítási feladatok identitását, és kevésbé jelentéssel bíró naplózási naplókkal rendelkezhetnek a hozzáférési naplókban.

  • A hálózati biztonsági vezérlőknek elég szélesnek kell lenniük ahhoz, hogy lefedjenek minden közös elhelyezésű erőforrást. Ez a konfiguráció egyes erőforrások esetében esetleg sérti a minimális jogosultság elvét.

  • A különböző alkalmazások vagy megosztott gazdagépeken található adatok együttes meghatározása a megfelelőségi követelmények és a biztonsági vezérlők kiterjesztését eredményezheti az olyan alkalmazásokra vagy adatokra, amelyek egyébként hatókörön kívüliek lennének. A hatókör bővítése további biztonsági ellenőrzést és naplózást igényel a közös elhelyezésű összetevőkre.

Költségoptimalizálási kompromisszumok az operatív kiválósággal

Kompromisszum: Feltörték a szoftverfejlesztési életciklus (SDLC) kapacitásait. A számítási feladatok SDLC-folyamata szigorú, konzisztenciát, specifikusságot és rangsorolást biztosít a számítási feladatok változáskezeléséhez.

  • Ha csökkenti a tesztelési erőfeszítéseket, hogy időt takarítson meg, és a tesztelési személyzettel, az erőforrásokkal és az eszközökkel kapcsolatos költségek további hibákat eredményezhetnek az éles környezetben.

  • Ha késlelteti a technikai adósság visszafizetését, hogy a személyzet az új funkciókra összpontosítson, lassabb fejlesztési ciklusokhoz és általánosan csökkenő rugalmassághoz vezethet.

  • A dokumentáció deprioritizálása, hogy a személyzet a termékfejlesztésre összpontosítson, hosszabb előkészítési időt eredményezhet az új alkalmazottak számára, hatással lehet az incidensmegoldás hatékonyságára, és veszélyeztetheti a megfelelőségi követelményeket.

  • A képzésbe való befektetés hiánya stagnált készségekhez vezet, ami csökkenti a csapat újabb technológiák és gyakorlatok bevezetésének képességét.

  • Ha eltávolítja az automatizálási eszközöket, hogy pénzt takarítson meg, a személyzet több időt fordíthat a már nem automatizált feladatokra. Emellett növeli a hibák és inkonzisztenciák kockázatát is.

  • A tervezési erőfeszítések, például a hatókörkezelés és a tevékenységek rangsorolásának csökkentése, a költségek csökkentése növelheti az átdolgozás valószínűségét a homályos specifikációk és a rossz megvalósítás miatt.

  • Ha elkerüli vagy csökkenti a folyamatos fejlesztési tevékenységeket, például a visszatekintéseket és az incidens utáni jelentéseket, a számítási feladatokért felelős csapat a teljesítésre összpontosítva kihagyott lehetőségeket teremthet a rutin-, nem tervezett és vészhelyzeti folyamatok optimalizálásához.

Kompromisszum: Csökkentett megfigyelhetőség. A megfigyelhetőség szükséges annak biztosításához, hogy a számítási feladatok értelmes riasztásokkal és sikeres incidenskezeléssel rendelkezzenek.

  • A napló- és metrikamennyiség csökkentése a tárolási és átviteli költségek megtakarítása érdekében csökkenti a rendszer megfigyelhetőségét, és a következőket eredményezheti:

    • Kevesebb adatpont a megbízhatósághoz, a biztonsághoz és a teljesítményhez kapcsolódó riasztások létrehozásához.
    • Az incidensmegoldási tevékenységek lefedettségi hiányosságai.
    • Korlátozott megfigyelhetőség a biztonsággal vagy megfelelőséggel kapcsolatos interakciókban vagy határokban.

  • A költségoptimalizálás tervezési mintái összetevőket adhatnak hozzá a számítási feladatokhoz, ami növeli annak összetettségét. A számítási feladatok monitorozási stratégiájának tartalmaznia kell ezeket az új összetevőket. Előfordulhat például, hogy egyes minták olyan folyamatokat vezetnek be, amelyek több összetevőre terjednek ki, vagy folyamatokat helyeznek át a kiszolgálóról az ügyfélre. Ezek a változások növelhetik az információk korrelációjának és nyomon követésének összetettségét.

  • A megfigyelhetőségi eszközökbe és a hatékony irányítópultok karbantartásába való kisebb befektetés csökkentheti az éles környezetből való tanulás, a tervezési döntések ellenőrzése és a terméktervezés tájékoztatásának képességét. Ez a csökkentés akadályozhatja az incidensmegoldási tevékenységeket is, és megnehezítheti a helyreállítási idő célkitűzésének és az SLO-nak való megfelelést.

Kompromisszum: Késleltetett karbantartás. A számítási feladatokkal kapcsolatos csapatoknak a kód, az eszközök, a szoftvercsomagok és az operációs rendszerek javítása és naprakészen tartása várhatóan időben és megfelelően történik.

  • Ha az eszközgyártókkal kötött karbantartási szerződések lejárnak, az nem fogadott optimalizálási funkciókat, hibafeloldásokat és biztonsági frissítéseket eredményezhet.

  • A rendszerjavítások közötti idő növelésével időt takaríthat meg, ami az elmulasztott hibajavításokhoz vagy a változó biztonsági fenyegetések elleni védelem hiányához vezethet.

Költségoptimalizálási kompromisszumok a teljesítményhatékonysággal

A Költségoptimalizálás és a Teljesítményhatékonyság alappillérei a számítási feladatok értékének maximalizálását helyezik előnyben. A teljesítményhatékonyság a teljesítménnyel kapcsolatos célokat helyezi előtérbe anélkül, hogy a szükségesnél többet költenek. A Költségoptimalizálás hangsúlyozza, hogy a számítási feladat erőforrásai által előállított érték maximalizálása a teljesítménycélok túllépése nélkül. Ennek eredményeképpen a költségoptimalizálás gyakran javítja a teljesítményhatékonyságot. A költségoptimalizáláshoz azonban teljesítményhatékonyság-kompromisszumok is társulnak. Ezek a kompromisszumok megnehezíthetik a teljesítménycélok elérését, és akadályozhatják a folyamatos teljesítményoptimalizálást.

Kompromisszum: Alulprovisionált vagy alulskálázott erőforrások. A teljesítmény-hatékony számítási feladatok elegendő erőforrással rendelkeznek a kereslet kiszolgálásához, de nincs túlzott használaton kívüli többletterhelés, még akkor sem, ha a használati minták ingadoznak.

  • Az erőforrások csökkentésével a költségek csökkentése megfoszthatja az alkalmazásokat az erőforrásoktól. Előfordulhat, hogy az alkalmazás nem tudja kezelni a használati minták jelentős ingadozásait.

  • A korlátra vagy a költségek csökkentésére való skálázás korlátozása vagy késleltetése a kereslet kielégítéséhez nem elegendő kínálatot eredményezhet.

  • Az automatikus skálázási beállítások, amelyek a költségek csökkentése érdekében agresszíven leskálázhatók, felkészületlenné válhatnak a szolgáltatások a hirtelen megugrásokra, vagy gyakori skálázási ingadozásokat (kiugrást) okozhatnak.

Kompromisszum: Az optimalizálás hiánya az idő múlásával. A hatékonyság növelésének egyik módja a funkciók változásainak, a használati minták változásainak, az új technológiáknak és a számítási feladatok különböző megközelítéseinek kiértékelése.

  • Ha a teljesítményoptimalizálással kapcsolatos szakértelem fejlesztésére összpontosít a teljesítés rangsorolása érdekében, az kihagyott lehetőségeket okozhat az erőforrás-használat hatékonyságának javításában.

  • A hozzáférési teljesítménnyel kapcsolatos tesztelési vagy monitorozási eszközök eltávolítása növeli a nem észlelt teljesítményproblémák kockázatát. Emellett korlátozza a számítási feladatokért felelős csapat azon képességét is, hogy mérték/ciklusok javítására hajtson végre.

  • A teljesítménycsökkenésre hajlamos területek, például az adattárak figyelmen kívül hagyása fokozatosan ronthatja a lekérdezési teljesítményt, és emelheti a teljes rendszerhasználatot.

Ismerkedjen meg a többi pillér kompromisszumával: