Architektúrastratégiák a biztonságos üzembe helyezési eljárásokhoz

Az Azure Well-Architected Framework operatív kiválósági ellenőrzőlistájára vonatkozó javaslat:

OE:11 Egyértelműen határozza meg a munkaterhelés biztonságos telepítési gyakorlatait. A kis, növekményes, minőségi alapú kiadási módszerek eszményeinek hangsúlyozása. A kockázat szabályozásához használjon modern üzembehelyezési mintákat és progresszív expozíciós technikákat. Vegyen fel rutinszerű és vészhelyzeti, vagy gyorsjavítási telepítésekről.

Ez az útmutató a biztonságos üzembehelyezési eljárások (SDP) használatára vonatkozó javaslatokat ismerteti. A biztonságos üzembehelyezési folyamatok és eljárások határozzák meg, hogyan végezheti el és helyezheti üzembe a számítási feladat módosításait. Az SDP implementálásához a kockázatkezelés szemszögéből kell átgondolnia az üzembe helyezéseket. Az SDP implementálásával minimalizálhatja az emberi hibák kockázatát az üzemelő példányokban, és korlátozhatja a problémás üzemelő példányok hatását a felhasználókra.

A biztonságos üzembe helyezési eljárások megvalósítása során négy fontos iránymutatást kell szem előtt tartani:

  • Biztonság és konzisztencia: Minden változtatás az éles környezetbeli munkaterhelésen eredendően kockázatos, és a biztonságra és a konzisztenciára kell összpontosítani.

  • Progresszív expozíció: Egy progresszív expozíciós üzemi modell alkalmazásával minimalizálhatja az üzembe helyezés által okozott problémák potenciális robbanási sugarát.

  • Állapotmodellek: A telepítéseknek át kell menniük az állapot-ellenőrzéseken, mielőtt a progresszív kitettség minden fázisa megkezdődhet.

  • Problémaészlelés: A problémák észlelésekor az üzembe helyezést azonnal le kell állítani, és a helyreállítást el kell indítani.

A következő szakaszok részletes javaslatokat nyújtanak ezekre a pontokra vonatkozóan.

A telepítések biztonságának és konzisztenciájának biztosítása

Akár egy frissítést helyez üzembe az alkalmazás kódjában, az infrastruktúrát kódként (IaC), a funkciójelzőt vagy egy konfigurációs frissítést, kockázatot jelent a számítási feladat számára. Nincsenek alacsony kockázatú üzembe helyezések az éles környezetben. Minden üzembe helyezésnek szabványos mintát kell követnie, és automatizálni kell a konzisztencia kényszerítése és az emberi hibák kockázatának minimalizálása érdekében. Kritikus fontosságú, hogy a számítási feladatok ellátási lánca és az üzembe helyezési folyamatok megbízhatóak, biztonságosak és egyértelműen meghatározott üzembehelyezési szabványokkal rendelkezzenek. Minden üzembe helyezést lehetséges kockázatként kezelhet, és minden üzembe helyezést ugyanolyan szintű kockázatkezelésnek vethet alá. A kockázatok ellenére továbbra is rendszeresen módosítania kellene a munkaterhelésen. A rendszeres frissítések telepítésének elmulasztása más kockázatokat is jelent, például a biztonsági réseket, amelyeket az üzembe helyezésekkel kell elhárítani. További információ: Javaslatok a számítási feladatok fejlesztési ellátási láncának megtervezéséhez.

Gyakori és kis telepítések előnyösebbek, mint a ritka és nagy telepítések. A kisebb módosításokat könnyebben meg lehet oldani, ha problémák merülnek fel, és a gyakori üzembe helyezések segítenek a csapatnak bizalmat építeni az üzembe helyezési folyamatba. Az is lényeges, hogy az éles környezetből szerezzen tapasztalatot a munkafolyamatok áttekintésével, amikor anomáliát tapasztal a bekövetkező üzembe helyezés során. Előfordulhat, hogy az infrastruktúra kialakításában vagy a bevezetésben hiányosságokat tapasztal. Ha problémák merülnek fel a telepítések során, győződjön meg arról, hogy a hibáztatásmentes postmortemek az SDP-folyamat részét képezik az incidens tanulságainak rögzítéséhez.

Progresszív expozíciós modell bevezetése

Üzembe helyezési problémák esetén a cél az, hogy a lehető leghamarabb elkapjuk őket, hogy minimalizáljuk a végfelhasználókra gyakorolt hatást. Ennek a célnak a megvalósítása érdekében implementáljon egy fokozatos bevezetési üzemi modellt, más néven progresszív expozíciós modellt. A kanári telepítések gyakori példái a progresszív expozíciónak. Ebben az üzembehelyezési modellben a belső vagy külső felhasználók egy kis csoportja kapja meg először az új funkciót. Miután az első csoport probléma nélkül futtatja az új verziót, a szolgáltatás az egymást követő nagyobb csoportokban lesz üzembe helyezve, amíg a teljes felhasználói sokaság nem futtatja az új verziót. A funkciójelzőket általában a kanári bevezetés célfelhasználói számára szolgálnak az új verzió engedélyezésére.

Egy másik gyakori üzembehelyezési modell a kék-zöld megközelítés. Ebben a modellben két azonos, terhelés-infrastruktúrát alkotó készlet van üzembe helyezve. Mindkét erőforráscsoport képes kezelni a teljes éles terhelést. Az első (kék) tárhely az üzembe helyezés aktuális verzióját futtatja, ahová az összes felhasználó irányul. A második (zöld) csoport lett frissítve az új funkcióval, és belsőleg lett tesztelve. A belső tesztelés után a rendszer az éles forgalom egy részét a kék poolból a zöld poolba irányítja. A kanári üzembe állításokhoz hasonlóan a bevezetés fokozatosan történik, mivel a forgalom egyre nagyobb részét irányítja át a zöld készletre az egyre nagyobb egymást követő bevezetési hullámokban. A bevezetés befejezése után a frissítési készlet lesz a kék készlet, a zöld készlet pedig készen áll a következő üzembe helyezésre. A két tartomány logikailag el van választva egymástól, hogy védve legyenek a hibák ellen. A kék-zöld modell egy változata üzembe helyezhető egy olyan számítási feladatban, amely az Üzembehelyezési bélyegek tervezési mintát használja egyszerre egy bélyegen való üzembe helyezéssel.

Mindkét modellben a bevezetés egyes fázisai közötti időnek elég hosszúnak kell lennie ahhoz, hogy a számítási feladat állapotmetrikáit monitorozza. Önnek elegendő sütési időt kell biztosítania a bevezetési csoportok között annak érdekében, hogy a különböző régiókból származó felhasználók vagy a különböző feladatokat végző felhasználók számára elegendő idő álljon rendelkezésre a munkaterhelés normál kapacitással való használatára. A sütési időt órákban és napokban kell mérni, nem pedig percekben. A sütési időt is növelni kell az egyes bevezetési csoportok esetében, hogy nap folyamán figyelembe vegye a különböző időzónákat és használati mintákat.

AI-lehetőség: A manuális bevezetés finomhangolása súrlódást okoz, és lassítja az üzembe helyezést. Az AI felgyorsítja a bevezetést és csökkenti az incidenseket, mivel a szubjektív döntéshozatalt adatvezérelt javaslatokra cseréli.

Kezdje egy korlátozott generatív AI-implementációval. Biztonságos hozzáférést biztosít a modelleknek az üzembehelyezési dokumentációhoz, a kód áttekintéséhez és az incidenselőzményekhez, hogy elemezhessék és javasolják a bevezetési stratégiákat és paramétereket.

A speciális ügynöki megoldások előre jelezhetik a kanárik százalékos arányát, a bevezetés időzítését és a célszegmenseket. Az üzembehelyezési eszközökkel integrálva automatikusan frissítik a bevezetési konfigurációkat. Ezek a megoldások mélyebb integrációt, szabályozott írási hozzáférést és platformtámogatást igényelnek.

Az egyéni prediktív modellek nagyobb pontosságot biztosítanak, de jelentős befektetést igényelnek a képzési infrastruktúrába és a gépi tanulási szakértelembe. Lehet, hogy a legtöbb csapat számára nem praktikusak.

Robusztus számítási feladatok állapotmodelljeinek fejlesztése

A megfigyelhetőségi platform és a megbízhatósági stratégiák részeként robusztus állapotmodellt fejleszthet. Az állapotmodellnek részletes betekintést kell biztosítania a számítási feladat összetevőibe és általános állapotába. A bevezetés során, ha riasztást kap egy végfelhasználóhoz kapcsolódó állapotváltozásról, a bevezetésnek azonnal le kell állítania, és vizsgálatot kell végeznie a riasztás okával kapcsolatban a következő lépés meghatározásához. Ha a végfelhasználók nem jelentenek problémákat, és az összes állapotjelző zöld marad a sütési idő alatt, a bevezetésnek folytatódnia kell. Ügyeljen arra, hogy használati metrikákat is tartalmazzon az állapotmodellben annak biztosítása érdekében, hogy a felhasználók által jelentett problémák és negatív állapotjelek ne rejtsenek el egy problémát. További információ: Állapotmodell létrehozása.

Hibaészlelési mechanizmusok implementálása

Ha az üzembe helyezés hibát okoz az egyik bevezetési csoportban, a bevezetésnek azonnal le kell állnia. A riasztás beérkezése után azonnal meg kell vizsgálni a probléma okát és a hatások súlyosságát. A probléma utáni helyreállítás a következőket tartalmazhatja:

  • Az üzembe helyezés visszaállításához vonja vissza az üzembe helyezésben végrehajtott módosításokat, és térjen vissza az utolsó ismert munkakonfigurációra.

  • Az üzembe helyezés előremozdítása a probléma megoldásával a bevezetés közepén. A probléma kezelése közben használjon gyorsjavítást, vagy más módokon csökkentse a probléma hatását.

  • Új infrastruktúra üzembe helyezése az utolsó ismert munkakonfiguráció használatával.

A módosítások, különösen az adatbázis, a séma vagy más állapotalapú összetevők módosításainak visszaállítása összetett lehet. Az SDP-irányelveknek egyértelmű útmutatást kell adniuk az adatváltozások kezeléséhez a számítási feladat adattulajdon-kialakításának megfelelően. Hasonlóképpen, az előrelépést óvatosan kell kezelni, hogy az SDP ne maradjon figyelmen kívül, és a gyorsjavítás vagy más minimalizáló intézkedések biztonságosan legyenek végrehajtva.

Üzembehelyezési biztonsági védőkorlátok létrehozása

  • Implementálja a verziószámozást a buildösszetevők között, így biztosítva, hogy szükség esetén visszaléphessen és továbbléphessen.

  • Használjon kiadási folyamatot vagy csomagtartóalapú elágaztatási struktúrát, amely gitflow- vagy környezetalapú elágaztatási struktúra helyett szoros szinkronizálást kényszerít ki a fejlesztői csapat között.

  • Az SDP-t amennyire csak lehet, automatizálja. Az IaC és az alkalmazások folyamatos integrációjának és folyamatos kézbesítésének (CI/CD) folyamatainak automatizálásával kapcsolatos részletes útmutatásért tekintse meg az automatizálási javaslatok című témakört.

  • Ci-eljárásokkal rendszeresen integrálhatja a kódmódosításokat az adattárakba. A CI-eljárások segíthetnek azonosítani az integrációs ütközéseket, és csökkenthetik a nagy, kockázatos egyesítések valószínűségét. További információkért tekintse meg a folyamatos integrációs útmutatót.

  • Funkciójelzők segítségével szelektíven engedélyezheti vagy letilthatja az új funkciókat vagy változásokat éles környezetben. A funkciójelzők segítségével szabályozhatja az új kód expozícióját, és problémák esetén gyorsan visszaállíthatja az üzembe helyezést.

  • Az éles környezetet tükröző tesztkörnyezetekbe való változtatások üzembe helyezése. A gyakorlókörnyezetek lehetővé teszik, hogy ellenőrzött környezetben tesztelje a módosításokat, mielőtt üzembe helyeznénk az élő környezetben.

  • A módosítások biztonságos üzembe helyezésének biztosítása érdekében hozzon létre előre üzembe helyezési ellenőrzéseket, beleértve a kódellenőrzést, a biztonsági ellenőrzéseket és a megfelelőségi ellenőrzéseket.

    Ne hagyatkozz csak egy teszttípusra. A különböző tesztek a hibák különböző osztályait észlelik. A szerződés stabilitási tesztjei például ellenőrzik, hogy az API-alakzat kompatibilis marad-e, míg a viselkedési tesztek ellenőrzik, hogy az API-funkciók helyesek-e. Ha a hálózati biztonsági szabályok módosításainak üzembe helyezésére készül, először szimulálja a hatást, hogy biztosan ne blokkolja véletlenül a fontos forgalmat, és ne okozzon kimaradásokat. Vegye fel a hálózati házirend-szimulációkat az előzetes üzembe helyezési ellenőrzésekbe, amikor egy kiadás módosítja az NSG-ket vagy Azure Virtual Network Manager biztonsági rendszergazdai szabályokat. Azure Network Watcher szabályhatás-elemző a végrehajtás előtt érvényesítheti a javasolt szabálymódosításokat az élő forgalmi mintákon, hogy a kritikus alkalmazás- és felügyeleti folyamatok ne tilthatók le véletlenül. Ez az ellenőrzés csökkenti a bevezetés által okozott kimaradások esélyét. Szakaszos üzembe helyezési és visszaállítási tervekhez kell használni, mert az elemzés csak olyan teljes, mint a rendelkezésre álló forgalmi adatok.

  • Áramkör-megszakítók implementálása a problémákat tapasztaló szolgáltatás felé irányuló forgalom automatikus leállításához. Ez segíthet megelőzni a rendszer további romlását.

Vészhelyzeti SDP-protokollok

Olyan előíró protokollokat hozhat létre, amelyek meghatározzák, hogyan módosítható az SDP egy gyorsjavításhoz vagy olyan vészhelyzeti problémákhoz, mint a biztonsági rések vagy a biztonsági rések expozíciója. A vészhelyzeti SDP-protokollok például a következők lehetnek:

  • Előléptetési és jóváhagyási fázis gyorsítása.

  • Füsttesztelés és integrációs tesztelés gyorsítása.

  • Sütési idő csökkentése.

Bizonyos esetekben a vészhelyzet korlátozhatja a minőség ellenőrzését és a tesztelési kapukat, de a kapukat a lehető leggyorsabban kell futtatni sávon kívüli műveletként. Győződjön meg arról, hogy meghatározza, hogy ki hagyhatja jóvá az SDP-gyorsítást vészhelyzetben, és hogy milyen feltételeknek kell teljesülnie a gyorsítás jóváhagyásához. A vészhelyzeti SDP-protokollokat a vészhelyzeti reagálási tervhez igazítva gondoskodhat arról, hogy minden vészhelyzetet ugyanazon protokollok szerint kezeljenek.

Biztonságos leszerelés megtervezése és végrehajtása

Az összetevők eltávolítása vagy elavulttá nyilvánítása az egyik legkockázatosabb módosítás, amelyet végrehajthat. A törlés után az erőforrás gyakran elfogyott, és a helyreállítás nehéz lehet. Még az inaktívnak vagy jelentéktelennek tűnő dolog is támogathatja a kritikus rejtett függőségeket. Minden törlést visszafordíthatatlannak kell tekinteni, és egy biztonságot előtérbe helyező megközelítést követve eljárni, például:

  • Inaktivitás ellenőrzése. Győződjön meg arról, hogy az erőforrás valóban nincs használatban. Egyértelmű inaktivitási mutatók definiálása teljes felhasználói vagy üzleti ciklusban. Ha bármilyen tevékenységet lát, például kéréseket, útvonal-találatokat, üzenetsormélység-módosításokat, funkciójelző-kiértékeléseket vagy DNS-lekérdezéseket, vizsgálja meg és erősítse meg, hogy az jogszerű-e a folytatás előtt.

  • Állapot megőrzése az eltávolítás előtt. Készítsen pillanatképet, exportáljon vagy készítsen biztonsági másolatot az erőforrásról, és címkézze fel egy ártalmatlanítási vagy felülvizsgálati dátummal.

  • Tiltsa le törlés előtt. Ha lehetséges, helyezze át az összetevőt egy letiltott vagy offline módba ahelyett, hogy azonnal törölné. Ez segít a rejtett függőségek biztonságos felfedésében. Csak akkor hagyja ki ezt a lépést, ha a megfelelőségi vagy biztonsági követelmények azonnali eltávolítást igényelnek.

  • Monitorozás egy megfigyelő ablakon keresztül. Figyelje meg a normál és a csúcshasználati mintákat is lefedő óraablakot. Az ebben az időszakban nem várt tevékenységeknek alaphelyzetbe kell állítaniuk a leszerelési folyamatot.

  • Törölje a reziduális hivatkozásokat. Ha biztos a teljes inaktivitásban, törölje az eltávolított összetevőre mutató kapcsolódó hivatkozásokat.

Megfontolások

A biztonságos üzembehelyezési eljárások létrehozása és fenntartása összetett. A robusztus szabványok teljes körű implementálásának sikere a szoftverfejlesztés számos területén alkalmazott gyakorlat érettségétől függ. Az automatizálás, a csak IaC-alapú infrastruktúra változásai, a konzisztens elágaztatási stratégiák, a funkciójelzők és egyéb eljárások segíthetnek a biztonságos üzembe helyezés biztosításában. Ezzel az útmutatóval optimalizálhatja a számítási feladatokat, és a gyakorlatok fejlődésével kapcsolatos fejlesztési terveket is megismerheti.

Az Azure megkönnyítése

  • Az Azure Pipelines és a GitHub Actions jóváhagyási kapuk használatával támogatja a többfázisú üzembe helyezéseket, ami segíthet megtervezni az üzembe helyezések progresszív expozíciós bevezetését.

  • A Azure-alkalmazás szolgáltatás átmeneti pontjaival egyszerűen cserélhet a kódverziók között. Az előkészítési pontok hasznosak az átmeneti környezetekben végzett teszteléshez, és kék-zöld üzembe helyezéshez használhatók.

  • Webalkalmazás-funkciójelzők tárolása és kezelése Azure-alkalmazás Konfigurációban. A szolgáltatás használatával egységes felügyeleti síkon hozhat létre, módosíthat és helyezhet üzembe funkciókat.

  • A virtuális gépén a terhelési alkalmazásokat a VM Applications használatával telepítheti.

  • Az Azure-terheléselosztók használatával üzembehelyezési stratégiákat valósíthat meg, és natív erőforrások használatával teheti közzé a számítási feladatok alkalmazásainak állapotát.

  • Azure Network Watcher szabályhatás-elemző érvényesítheti a javasolt szabálymódosításokat az élő forgalmi mintákon a végrehajtás előtt, hogy a kritikus alkalmazás- és felügyeleti folyamatok ne legyen véletlenül blokkolva. Ez az ellenőrzés csökkenti a bevezetés által okozott kimaradások esélyét. Használja szakaszos üzembe helyezési és visszaállítási tervekkel, mert az elemzés csak olyan teljes, mint a rendelkezésre álló forgalmi adatok.

  • Az Application Health kiterjesztés használatával jelentést készíthet az alkalmazás állapotáról egy virtuálisgép-méretezési csoportpéldány belsejéből. A bővítmény mintavételt küld egy helyi alkalmazásvégponton, és frissíti az állapotot az alkalmazástól kapott TCP/HTTP(S) válaszok alapján.

  • Az Azure Logic Apps használatával bármikor létrehozhatja az alkalmazás új verzióját, amikor frissítést végeznek rajta. Az Azure fenntartja az alkalmazásverziók előzményeit, és visszaállíthatja vagy előléptetheti az előző verziókat.

  • Az Azure Functions Flex Consumption a frissítések során fokozatosan cseréli le a példányokat, ezáltal csökkentve a megszakításokat a telepítések bevezetése során. Ezt a viselkedést a hatókör csökkentéseként kezelje, ne pedig a függőségek ellenőrzésének, a visszaállítási gyakorlatoknak és a verziókompatibilitási teszteknek a helyettesítőjeként.

  • Számos Azure Database-szolgáltatás biztosít időponthoz kötött visszaállítási funkciókat, amelyek segíthetnek a visszaállításban. Az időponthoz kötött visszaállítást támogató szolgáltatások a következők:

Példa

Tekintse meg az Azure Kubernetes Service (AKS) fürtök kék-zöld üzembe helyezésének architektúraútmutatóját, amely példát mutat arra, hogyan használhatja ezt az üzembehelyezési modellt.

Működési kiválósági ellenőrzőlista

Tekintse meg a javaslatok teljes készletét.

Működési kiválósági ellenőrzőlista

  • Utolsó frissítés időpontja: