Költségoptimalizálási kompromisszumok
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.
Kapcsolódó hivatkozások
Ismerkedjen meg a többi pillér kompromisszumával: