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

Költségoptimalizálási kompromisszumok

  • Cikk

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

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, jól megtervezett Azure-keretrendszer pilléreinek 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, tervezésének és műveleteinek figyelembe vétele során előforduló kompromisszumokat ismerteti.

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

A szolgáltatáskimaradás költségét 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ági tervezés költségeit, érdemes többet fektetnie a fennakadások megelőzésére vagy enyhítésére. Ezzel szemben a megbízhatósági erőfeszítések költsége több lehet, mint egy fennakadás költsége, beleértve az olyan tényezőket, mint a megfelelőségi követelmények és a hírnév. Csak ebben a forgatókönyvben érdemes megfontolni a megbízhatósági tervezés stratégiai elidegenítését.

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állni bizonyos típusú és mennyiségű hibás működésnek.

  • Pénzt takaríthat meg, ha a számítási feladatokért felelős csapat alulképez egy összetevőt, vagy túlkonkontegrálhatja annak méretezését, így az összetevő nagyobb valószínűséggel hiúsul meg a hirtelen megnövekedett kereslet során.

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

  • Az olyan összetevők eltávolítása, amelyek támogatják a rugalmassági tervezési mintákat, például egy üzenetbuszt, és közvetlen függőség 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 szigorú költségkeretek beállítása megakadályozhatja a számítási feladatok skálázását a jogos igények kielégítése érdekében.

  • A 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 tesztelt incidensmegoldási és helyreállítási terv tartozik a vészforgatókönyvekhez.

  • A számítási feladatok vészhelyreállítási tervének csökkentett tesztelése vagy fúrása befolyásolhatja a helyreállítási műveletek sebességét és hatékonyságát.

  • 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 technológiai partnerekkel kötött kevésbé költséges támogatási szerződés kiválasztása növelheti a számítási feladatok helyreállítási idejét a technikai segítségnyújtás esetleges késése miatt.

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

  • 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ózatokra és ügyféleszközökre, amelyekhez a számítási feladatnak megbízhatósági célokat kell biztosítania.

  • Az eseményalapú skálázás bonyolultabb lehet, mint az erőforrás-alapú skálázás finomhangolása és ellenőrzése.

  • Az adatmennyiség csökkentése és az adatok rétegzése az adat életciklus-műveletek révén– akár 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.

  • A költségek optimalizálása különböző régiók használatával megnehezítheti a felügyelet, a hálózatkezelés és a figyelés használatát.

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

A számítási feladatokban a bizalmasság, az integritás és a rendelkezésre állás veszélyeztetésének költségeit mindig ki 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 lehetnek, é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ázatvállalás költségeit a befektetéshez kell kiegyensúlyozottan elszámolni. Általában ne veszélyeztessék a biztonságot, hogy olyan költségoptimalizációkat szerezzenek, amelyek nem felelnek meg a felelősségi pontnak, és megegyeznek a kockázatcsökkentésben. 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ések. A biztonsági vezérlők több rétegben vannak kialakítva, néha redundánsan, a mélységi védelem biztosítása érdekében.

A költségoptimalizálás egyik taktikája az egység- vagy működési költségeket felhalmozó összetevők vagy folyamatok eltávolításának módjainak keresése. 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 zéró megbízhatóságú architektúra ellenőrzési alapelvét. Ilyen egyszerűsítések például az alapszintű hitelesítési sémák, például az előre osztott 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 alatt 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 potenciális integritási vagy bizalmassági incidensek esetén teszi elérhetővé az adatokat.

  • A kapcsolódó költség- és időbefektetés miatt a biztonsági vizsgálati eszközök vagy a 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 bizalmasságot, integritást vagy rendelkezésre állást.

  • A biztonsági javítás gyakoriságának csökkentése a katalóguskészítésbe é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 letiltásához vezethet.

Kompromisszum: Megnövekedett számítási feladatok felülete. A biztonsági pillér rangsorolja a csökkentett és zárt felületi területet a támadási vektorok minimalizálása és a biztonsági vezérlők kezelése érdekében.

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 védeni kell, esetleg olyan módon, amelyet még nem használnak a rendszerben. Ezek az összetevők és adatok gyakran megfelelőségi követelményeknek vannak alávetve. Példák az összetevők bevezetésére szolgáló mintákra:

  • A statikus tartalom-üzemeltetési minta használata adatok kiszervezéséhez egy új CDN-összetevőre.

  • A Valet-kulcs mintával ki lehet kapcsolni a feldolgozást, és biztonságossá teheti az erőforrás-hozzáférést az ügyfélszámításhoz.

  • Üzenetsín bevezetésével a költségek simításához használja a várólista-alapú terhelés simítási mintáját.

Kompromisszum: Eltávolított 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 elhelyezé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. Az alkalmazásplatform-gazdagép vagy az egyes alkalmazások rendelkezésre állását veszélyeztető biztonsági esemény nagyobb sugárral is rendelkezik.

  • A közösen elhelyezett erőforrások megoszthatják a számítási feladat identitását, és kevésbé értelmezhető naplózási nyomokkal 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 fekvésű erőforrást. Ez a konfiguráció egyes erőforrások esetében megsértheti a minimális jogosultság elvét.

  • A különböző alkalmazások vagy adatok közös elhelyezése megosztott gazdagépen a megfelelőségi követelmények és a biztonsági vezérlők kiterjesztését eredményezheti olyan alkalmazásokra vagy adatokra, amelyek egyébként hatókörön kívül lennének. A hatókör ezen kibővítése további biztonsági ellenőrzést és naplózást igényel a közösen elhelyezett összetevőkre.

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

Kompromisszum: A szoftverfejlesztési életciklus (SDLC) kapacitásainak biztonsága. A számítási feladatok SDLC-folyamata szigorú, konzisztenciát, specifikusságot és rangsorolást biztosít a számítási feladatok kezelésének módosításához.

  • 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 több hibát 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 termékfejlesztésre összpontosítsa a személyzet erőfeszítéseit, hosszabb előkészítési időt eredményezhet az új alkalmazottak számára, hatással lehet az incidenskezelé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.

  • Az olyan tervezési erőfeszítések csökkentése, mint a hatókörkezelés és a tevékenységek rangsorolása, 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 visszamenőleges és az incidens utáni jelentéseket, a számítási feladatok csapatának a teljesítésre való összpontosítása kihagyott lehetőségeket teremthet a rutin-, a nem tervezett és a 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ással és sikeres incidenskezeléssel rendelkezzenek.

  • A napló- és metrikamennyiség csökkentése a tárolási és átviteli költségek csökkentése csökkenti a rendszer megfigyelhetőségét, és a következőhöz vezethet:

    • Kevesebb adatpont a megbízhatósághoz, a biztonsághoz és a teljesítményhez kapcsolódó riasztások létrehozásához.
    • Az incidenskezelé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 figyelési stratégiájának tartalmaznia kell 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 módosítások növelhetik a korreláció és a nyomon követés összetettségét.

  • A megfigyelhető eszközökbe való kisebb befektetés és a hatékony irányítópultok karbantartása csökkentheti az éles használatból való tanulás, a tervezési lehetőségek 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 incidens-reagálá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: Elhalasztott karbantartás. A számítási feladatok csapatai várhatóan időben és rendezetten javítják és naprakészen tartják a kódokat, az eszközöket, a szoftvercsomagokat és az operációs rendszereket.

  • Az eszközgyártókkal kötött karbantartási szerződések lejáratának engedélyezése elmulasztott 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, ha elmulasztott hibajavításokat vagy a folyamatosan változó biztonsági fenyegetések elleni védelem hiányát okozza.

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 pillérei egyaránt a számítási feladatok értékének maximalizálására helyezik a prioritást. A Teljesítményhatékonyság a teljesítménycélok elérését hangsúlyozza anélkül, hogy a szükségesnél többet költene. A költségoptimalizálás hangsúlyozza, hogy a számítási feladatok 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ény hatékonyságát. A költségoptimalizáláshoz azonban vannak teljesítményhatékonyság-kompromisszumok. 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: Alulprofunká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 nem rendelkeznek túlzottan kihasználatlan többletterheléssel, még akkor sem, ha a használati minták ingadoznak.

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

  • A skálázás korlátra vagy költségcsökkentésre való korlátozása vagy késleltetése azt eredményezheti, hogy a kereslet kielégítéséhez nem elegendő a kínálat.

  • 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ás hirtelen megnövekedett keresletre, 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 hatásainak kiértékelése.

  • Ha a teljesítménnyel kapcsolatos optimalizálási 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ény tesztelési vagy monitorozási eszközeinek 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 csapatának a mértéken vagy a ciklusok javításán való végrehajtását.

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

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