Kritikus fontosságú számítási feladatok üzembe helyezése és tesztelése az Azure-ban

A sikertelen üzembe helyezések és a hibás kiadások gyakori okai az alkalmazáskimaradásoknak. Az üzembe helyezés és tesztelés megközelítése kritikus szerepet játszik a kritikus fontosságú alkalmazások általános megbízhatóságában.

A kritikus fontosságú számítási feladatok konzisztens eredményeinek biztosítása érdekében az üzembe helyezésnek és a tesztelésnek kell képeznie az összes alkalmazás- és infrastruktúra-művelet alapját. Készüljön fel a heti, napi vagy gyakrabban történő üzembe helyezésre. Tervezheti meg a folyamatos integrációs és folyamatos üzembehelyezési (CI/CD) folyamatokat, hogy támogassa ezeket a célokat.

A stratégiának a következőt kell megvalósítania:

• Szigorú előzetes tesztelés. A frissítések nem eredményezhetnek olyan hibákat, biztonsági réseket vagy egyéb tényezőket, amelyek veszélyeztethetik az alkalmazás állapotát.

• Transzparens üzemelő példányok. A frissítéseket bármikor, a felhasználók befolyásolása nélkül is el lehet végezni. A felhasználóknak zavartalanul folytatniuk kell az alkalmazással folytatott interakcióikat.

• Magas rendelkezésre állású műveletek. Az üzembe helyezési és tesztelési folyamatoknak és eszközöknek magas rendelkezésre állásúnak kell lenniük az alkalmazások általános megbízhatóságának támogatásához.

• Konzisztens üzembehelyezési folyamatok. Ugyanazokat az alkalmazásösszetevőket és folyamatokat kell használni az infrastruktúra és az alkalmazáskód különböző környezetekben való üzembe helyezéséhez. A végpontok közötti automatizálás kötelező. A manuális beavatkozásokat el kell kerülni, mert megbízhatósági kockázatokat okozhatnak.

Ez a tervezési terület javaslatokat nyújt az üzembe helyezési és tesztelési folyamatok optimalizálására az állásidő minimalizálása, valamint az alkalmazások állapotának és rendelkezésre állásának fenntartása érdekében.

Fontos

Ez a cikk az Azure Well-Architected Framework kritikus fontosságú számítási feladatok sorozatának része. Ha nem ismeri ezt a sorozatot, javasoljuk, hogy kezdje a mi az a kritikus fontosságú számítási feladat?

Nulla állásidő üzembe helyezése

Tekintse meg az alábbi videót a leállási idő nélküli üzembe helyezés áttekintéséhez.

Az állásidő nélküli üzembe helyezés elérése alapvető cél a kritikus fontosságú alkalmazások számára. Az alkalmazásnak egész nap, minden nap elérhetővé kell lennie, még akkor is, ha az új kiadások munkaidőben kerülnek kiadásra. Az üzembehelyezési folyamatok meghatározására és tervezésére tett erőfeszítéseit előre kell fektetnie, hogy olyan kulcsfontosságú tervezési döntéseket hozhasson, mint például az erőforrások rövid élettartamúként való kezelése.

Az állásidő nélküli üzembe helyezés eléréséhez helyezzen üzembe új infrastruktúrát a meglévő infrastruktúra mellett, tesztelje alaposan, váltsa át a végfelhasználói forgalmat, és csak ezután szerelje le az előző infrastruktúrát. Más eljárások, például a skálázási egységek architektúrája is kulcsfontosságú.

A Mission-Critical Online és az Azure Mission-Critical Connected referencia-implementációi ezt az üzembe helyezési megközelítést szemléltetik az alábbi ábrán látható módon:

Alkalmazáskörnyezetek

Az alábbi videóban áttekintheti az alkalmazáskörnyezetekre vonatkozó javaslatokat.

Az üzembehelyezési műveletek ellenőrzéséhez és szakaszához különböző típusú környezetekre van szükség. A típusok különböző képességekkel és életciklusokkal rendelkeznek. Egyes környezetek az éles környezetet tükrözik, és hosszú élettartamúak, mások pedig rövid élettartamúak, és kevesebb képességük van, mint az éles környezetnek. Ezeknek a környezeteknek a fejlesztési ciklus korai szakaszában történő beállítása segít biztosítani az agilitást, az éles és az előgyártási eszközök elkülönítését, valamint a műveletek alapos tesztelését, mielőtt az éles környezetbe bocsátanák. Minden környezetnek a lehető legnagyobb mértékben tükröznie kell az éles környezetet, bár szükség esetén egyszerűsítéseket alkalmazhat az alacsonyabb környezetekre. Ez az ábra egy kritikus fontosságú architektúrát mutat be:

Néhány gyakori szempont:

• Az összetevőket nem szabad megosztani a környezetekben. Lehetséges kivételek az alsóbb rétegbeli biztonsági berendezések, például a tűzfalak és a szintetikus tesztadatok forráshelyei.

• Minden környezetnek infrastruktúra-kódot (IaC) kell használnia, például Terraform- vagy Azure Resource Manager- (ARM-) sablonokat.

Fejlesztői környezetek

A rövid élettartamú fejlesztési környezetekről és az automatizált funkciók érvényesítéséről az alábbi videóban tájékozódhat.

Kialakítási szempontok

• Képességek. A megbízhatóságra, a kapacitásra és a biztonságra vonatkozó alacsonyabb követelmények elfogadhatók a fejlesztési környezetekben.

• Életciklus. A fejlesztési környezeteket szükség szerint létre kell hozni, és rövid ideig kell létezniük. A rövidebb életciklusok segítenek megakadályozni, hogy a konfiguráció eltérjen a kódbázistól, és csökkentse a költségeket. Emellett a fejlesztési környezetek gyakran megosztják egy szolgáltatáság életciklusát.

• Sűrűség. A Teamsnek több környezetre van szüksége a párhuzamos funkciók fejlesztésének támogatásához. Egyetlen előfizetésen belül is létezhetnek.

Tervezési javaslatok

• A környezetet egy dedikált előfizetésben tarthatja, és a környezet fejlesztési célokra van beállítva.

• Automatizált folyamat használatával telepíthet kódot egy szolgáltatáságból egy fejlesztői környezetbe.

Környezetek tesztelése vagy előkészítése

Ezek a környezetek tesztelésre és ellenőrzésre használhatók. Számos tesztelési ciklust hajtunk végre annak érdekében, hogy az éles környezetben hibamentes üzembe helyezést biztosítsunk. A kritikus fontosságú számítási feladatok megfelelő tesztjeit a Folyamatos ellenőrzés és tesztelés szakaszban ismertetjük.

Kialakítási szempontok

• Képességek. Ezeknek a környezeteknek az éles környezetet kell tükrözniük a megbízhatóság, a kapacitás és a biztonság szempontjából. Éles terhelés hiányában szintetikus felhasználói terhelés használatával valós metrikákat és értékes állapotmodellezési bemenetet biztosíthat.

• Életciklus. Ezek a környezetek rövid élettartamúak. A tesztelési ellenőrzés befejeződése után el kell pusztítani őket.

• Sűrűség. Egy előfizetésben számos független környezetet futtathat. Érdemes megfontolnia több környezet használatát is, mindegyiket egy dedikált előfizetésben.

Feljegyzés

A kritikus fontosságú alkalmazásokat szigorú tesztelésnek kell alávetni.

Egyetlen környezetben különböző tesztfüggvényeket hajthat végre, és bizonyos esetekben szükség lesz rá. Például ahhoz, hogy a káosztesztelés értelmes eredményeket adjon, először terhelés alá kell helyeznie az alkalmazást, hogy megértse, hogyan reagál az alkalmazás az injektált hibákra. Ezért általában párhuzamosan végzik el a káosztesztelést és a terheléstesztelést.

Tervezési javaslatok

• Győződjön meg arról, hogy legalább egy átmeneti környezet teljes mértékben tükrözi az éles üzemet az éles környezethez hasonló tesztelés és ellenőrzés engedélyezéséhez. A környezet kapacitása a tesztelési tevékenységek végrehajtásától függően rugalmasan rugalmas lehet.

• Szintetikus felhasználói terhelés létrehozása az egyik környezet változásainak reális teszteléséhez.

  Feljegyzés

  A Kritikus online referencia implementációja példaként szolgál egy felhasználói terhelésgenerátorra.

• Határozza meg az előkészítési környezetek számát és azok céljait a fejlesztési és kiadási cikluson belül.

Éles környezetek

Kialakítási szempontok

• Képességek. Az alkalmazás megbízhatóságának, kapacitásának és biztonsági funkcióinak legmagasabb szintje szükséges.

• Életciklus. Bár a számítási feladat és az infrastruktúra életciklusa változatlan marad, minden adatnak, beleértve a figyelést és a naplózást is, speciális felügyeletre van szüksége. A biztonsági mentéshez és a helyreállításhoz például felügyeletre van szükség.

• Sűrűség. Egyes alkalmazások esetében érdemes lehet különböző éles környezeteket használni a különböző ügyfelek, felhasználók vagy üzleti funkciók kiszolgálására.

Tervezési javaslatok

Az éles és az alacsonyabb környezetekhez egyértelmű szabályozási határt kell szabni. A cél eléréséhez helyezze az egyes környezettípusokat egy dedikált előfizetésbe. Ez a szegmentálás biztosítja, hogy az alacsonyabb környezetekben lévő erőforrások kihasználtsága ne befolyásolja az éles kvótákat. A dedikált előfizetések hozzáférési határokat is beállítanak.

Rövid élettartamú kék/zöld környezetek

A kék/zöld üzembehelyezési modell legalább két azonos üzembe helyezést igényel. A kék üzembe helyezés az aktív, amely éles környezetben szolgálja ki a felhasználói forgalmat. A zöld üzembe helyezés az új, amely készen áll a forgalom fogadására és tesztelésére. A zöld üzembe helyezés befejezése és tesztelése után a forgalom fokozatosan kékről zöldre lesz irányítva. Ha a terhelésátvitel sikeres, a zöld üzembe helyezés lesz az új aktív üzembe helyezés. A régi kék üzembe helyezés egy szakaszos folyamaton keresztül leszerelhető. Ha azonban problémák merülnek fel az új üzembe helyezés során, megszakítható, és a forgalom vagy a régi kék üzembe helyezésben marad, vagy átirányítható hozzá.

Az Azure Mission-Critical egy kék/zöld üzembe helyezési megközelítést javasol, amelyben az infrastruktúra és az alkalmazások együtt vannak üzembe helyezve egy üzembe helyezési bélyeg részeként. Ezért az infrastruktúra vagy az alkalmazás módosítása mindig zöld üzembe helyezést eredményez, amely mindkét réteget tartalmazza. Ez a megközelítés lehetővé teszi, hogy teljes mértékben tesztelje és ellenőrizze a változás hatását az infrastruktúrára és az alkalmazás teljes körűre, mielőtt átirányítja a felhasználói forgalmat. A megközelítés növeli a módosítások kiadásának megbízhatóságát, és lehetővé teszi a leállási idő nélküli frissítéseket, mivel érvényesíthetőek az olyan alárendelt függőségekkel való kompatibilitások, mint az Azure platform, az erőforrás-szolgáltatók és az IaC-modulok.

Kialakítási szempontok

• Technológiai képességek. Használja ki az Azure-szolgáltatások beépített üzembehelyezési funkcióit. A Azure-alkalmazás szolgáltatás például másodlagos üzembehelyezési helyeket biztosít, amelyek az üzembe helyezés után felcserélhetők. Az Azure Kubernetes Service (AKS) segítségével minden csomóponton külön podtelepítést használhat, és frissítheti a szolgáltatásdefiníciót.

• Az üzembe helyezés időtartama. Az üzembe helyezés végrehajtása hosszabb időt vehet igénybe, mert a bélyeg nem csak a módosított összetevőt, hanem az infrastruktúrát és az alkalmazást is tartalmazza. Ez azonban elfogadható, mert annak kockázata, hogy az összes összetevő nem a várt módon működik, felülírja az időproblémákat.

• Költséghatás. A két egymás melletti üzembe helyezésnek további költsége van, amelynek az üzembe helyezés befejezéséig együtt kell léteznie.

• Forgalomváltás. Az új üzembe helyezés ellenőrzése után a forgalmat át kell váltani a kék környezetről a zöldre. Ez az áttűnés megköveteli a felhasználói forgalom vezénylését a környezetek között. Az áttűnésnek teljesen automatizáltnak kell lennie.

• Életciklus. A kritikus fontosságú üzembehelyezési bélyegeket rövid élettartamúnak kell tekinteni. A rövid élettartamú bélyegek használata minden alkalommal új kezdést hoz létre az erőforrások kiépítése előtt.

Tervezési javaslatok

• Kék/zöld üzembe helyezési megközelítés alkalmazása az összes éles változás kiadásához. A konzisztens állapot és a nulla állásidő elérése érdekében minden alkalommal üzembe helyezheti az összes infrastruktúrát és az alkalmazást, bármilyen típusú változás esetén. Bár újra felhasználhatja a környezeteket, kritikus fontosságú számítási feladatokhoz nem javasoljuk. Az egyes regionális üzembehelyezési bélyegeket rövid élettartamúként kezelje, amely egyetlen kiadáshoz kötődik.

• Egy globális terheléselosztó, például az Azure Front Door használatával vezényli a felhasználói forgalom automatikus áttűnést a kék és a zöld környezet között.

• A forgalom áttűnéséhez adjon hozzá egy zöld háttérvégpontot, amely alacsony forgalmat használ a kötet súlyához, például 10 százalékot. Miután ellenőrizte, hogy a zöld üzembe helyezés alacsony forgalmú kötete működik-e, és biztosítja-e az alkalmazás várt állapotát, fokozatosan növelje a forgalmat. Ennek során alkalmazzon egy rövid felugró időszakot az olyan hibák elfogására, amelyek nem feltétlenül azonnal nyilvánvalóak.

  Az összes forgalom áttűnése után távolítsa el a kék háttérrendszert a meglévő kapcsolatokból. Távolítsa el például a háttérrendszert a globális terheléselosztó szolgáltatásból, ürítse le az üzenetsorokat, és leválasztson más társításokat. Ez segít optimalizálni a másodlagos termelési infrastruktúra fenntartásának költségeit, és biztosítani, hogy az új környezetek ne legyenek konfigurációs eltérések.

  Ezen a ponton szerelje le a régi és most inaktív kék környezetet. A következő üzembe helyezéshez ismételje meg a folyamatot kék és zöld fordított színnel.

Előfizetés-hatókörű üzembe helyezés

Az alkalmazás skálázási követelményeitől függően előfordulhat, hogy több éles előfizetésre is szükség lehet a méretezési egységekhez.

Tekintse meg az alábbi videót, amely áttekintést nyújt a kritikus fontosságú alkalmazások előfizetéseinek hatókörkezelésére vonatkozó javaslatokról.

Kialakítási szempontok

• Skálázhatóság. A nagy mennyiségű forgalmat bonyolító nagy léptékű alkalmazásforgatókönyvek esetében úgy tervezheti meg a megoldást, hogy több Azure-előfizetésre skálázható legyen, hogy az egyetlen előfizetés méretezési korlátai ne korlátozzák a méretezhetőséget.

  Fontos

  Több előfizetés használata további CI-/CD-összetettséget igényel, amelyet megfelelően kell kezelni. Ezért csak szélsőséges méretű forgatókönyvekben javasoljuk több előfizetés használatát, ahol az egyetlen előfizetés korlátai valószínűleg korlátozássá válhatnak.

• Környezethatárok. Éles, fejlesztési és tesztelési környezetek üzembe helyezése külön előfizetésekben. Ez a gyakorlat biztosítja, hogy az alacsonyabb környezetek ne járuljanak hozzá a méretezési korlátokhoz. Emellett egyértelmű felügyeleti és identitáshatárok biztosításával csökkenti az alacsonyabb környezetű frissítések környezetszennyező termelésének kockázatát.

• Irányítás. Ha több éles előfizetésre van szüksége, fontolja meg egy dedikált alkalmazásfelügyeleti csoport használatát a szabályzatok hozzárendelésének egyszerűsítése érdekében egy szabályzat-összesítési határon keresztül.

Tervezési javaslatok

• Helyezze üzembe az egyes regionális üzembehelyezési bélyegeket egy dedikált előfizetésben, hogy az előfizetési korlátok csak egyetlen üzembehelyezési bélyeg környezetében legyenek érvényesek, és ne az egész alkalmazásra. Adott esetben érdemes lehet több üzembehelyezési bélyeget használni egy régión belül, de ezeket érdemes független előfizetések között üzembe helyezni.

• Helyezze a globális megosztott erőforrásokat egy dedikált előfizetésbe, hogy lehetővé tegye a regionális előfizetések konzisztens üzembe helyezését. Kerülje a speciális üzembe helyezés használatát az elsődleges régióban.

Folyamatos ellenőrzés és tesztelés

A tesztelés kritikus tevékenység, amely lehetővé teszi az alkalmazáskód és az infrastruktúra állapotának teljes körű ellenőrzését. Pontosabban a tesztelés lehetővé teszi, hogy megfeleljen a megbízhatóságra, teljesítményre, rendelkezésre állásra, biztonságra, minőségre és skálázásra vonatkozó szabványoknak. A tesztelést jól meg kell határozni és alkalmazni kell az alkalmazástervezés és a DevOps-stratégia részeként. A tesztelés kulcsfontosságú szempont a helyi fejlesztői folyamat (a belső hurok) és a teljes DevOps-életciklus (a külső hurok) részeként, amely akkor kezdődik, amikor a kód a kiadási folyamat folyamatától az éles környezet felé halad.

A folyamatos ellenőrzés és tesztelés áttekintéséhez tekintse meg az alábbi videót.

Ez a szakasz a külső hurok tesztelésére összpontosít. Különböző típusú teszteket ír le.

Teszt	Leírás
Egységtesztelés	Megerősíti, hogy az alkalmazás üzleti logikája a várt módon működik. Ellenőrzi a kódmódosítások általános hatását.
Füsttesztelés	Meghatározza, hogy az infrastruktúra- és alkalmazásösszetevők elérhetők-e, és a várt módon működnek-e. A rendszer általában csak egyetlen virtuális felhasználói munkamenetet tesztel. Az eredmény az, hogy a rendszer a várt értékekkel és viselkedéssel válaszol. Gyakori füsttesztelési forgatókönyvek például egy webalkalmazás HTTPS-végpontjának elérése, egy adatbázis lekérdezése és egy felhasználói folyamat szimulálása az alkalmazásban.
Felhasználói felület tesztelése	Ellenőrzi, hogy az alkalmazás felhasználói felületei üzembe vannak-e helyezve, és hogy a felhasználói felület interakciói a várt módon működnek-e. Az automatizáláshoz felhasználói felületi automatizálási eszközöket kell használnia. A felhasználói felületi tesztek során a szkriptnek valós felhasználói forgatókönyvet kell utánoznia, és végre kell hajtania egy sor lépést a műveletek végrehajtásához és a kívánt eredmény eléréséhez.
Terheléstesztelés	Ellenőrzi a méretezhetőséget és az alkalmazás működését a terhelés gyors és/vagy fokozatos növelésével, amíg el nem éri az előre meghatározott küszöbértéket. A terheléses tesztek általában egy adott felhasználói folyamat köré vannak tervezve annak ellenőrzésére, hogy az alkalmazáskövetelmények teljesülnek-e egy meghatározott terhelés alatt.
Stressztesztelés	A meglévő erőforrásokat túlterhelő tevékenységeket alkalmazza a megoldáskorlátok meghatározásához és a rendszer megfelelő helyreállításának ellenőrzéséhez. A fő cél a lehetséges teljesítménybeli szűk keresztmetszetek és a méretezési korlátok azonosítása. Ezzel szemben skálázza le a rendszer számítási erőforrásait, és figyelje meg, hogyan viselkedik terhelés alatt, és állapítsa meg, hogy helyre tud-e állni.
Teljesítménytesztelés	A terhelés- és terheléstesztelés szempontjainak kombinálása a terhelés alatti teljesítmény ellenőrzéséhez és az alkalmazásművelet teljesítményértékelési viselkedésének kialakításához.
Káosztesztelés	Mesterséges hibákat injektál a rendszerbe annak kiértékelése és a rugalmassági intézkedések, a működési eljárások és a kockázatcsökkentések hatékonyságának ellenőrzése érdekében. Az infrastruktúra összetevőinek leállítása, a teljesítmény szándékos romlása és az alkalmazáshibák bevezetése olyan tesztek, amelyek segítségével ellenőrizhető, hogy az alkalmazás a várt módon fog-e reagálni a forgatókönyvek tényleges bekövetkezésekor.
Behatolás tesztelése	Biztosítja, hogy egy alkalmazás és környezete megfeleljen a várt biztonsági helyzet követelményeinek. A cél a biztonsági rések azonosítása. A biztonsági tesztelés magában foglalhatja a szoftverellátási láncot és a csomagfüggőségeket, valamint az ismert gyakori biztonsági rések és kitettségek (CVE) vizsgálatát és monitorozását.

Kialakítási szempontok

• Automatizálás. Az automatizált tesztelés elengedhetetlen az alkalmazások vagy az infrastruktúra változásainak időben és megismételhető módon történő ellenőrzéséhez.

• Tesztelési sorrend. A tesztek elvégzésének sorrendje kritikus szempont a különböző függőségek, például a futó alkalmazáskörnyezet szükségessége miatt. A tesztelés időtartama a sorrendet is befolyásolja. A rövidebb futási idővel rendelkező teszteknek a ciklus korábbi szakaszában kell futniuk, ha lehetséges, a tesztelés hatékonyságának növelése érdekében.

• Méretezhetőségi korlátok. Az Azure-szolgáltatások különböző puha és kemény korlátozásokkal rendelkeznek. Fontolja meg a terheléses tesztelés használatát annak meghatározásához, hogy egy rendszer túllépi-e azokat a várt éles terhelés során. A terheléstesztelés az automatikus skálázáshoz megfelelő küszöbértékek beállításához is hasznos lehet. Az automatikus skálázást nem támogató szolgáltatások esetében a terheléstesztelés segíthet az automatizált üzemeltetési eljárások finomhangolásában.

  A rendszerösszetevők, például az aktív/passzív hálózati összetevők vagy adatbázisok megfelelő méretezésre való képtelensége korlátozó lehet. A stressztesztelés segíthet azonosítani a korlátozásokat.

• Hibamód elemzése. Az alkalmazás és a mögöttes infrastruktúra hibáinak bevezetése és a hatás értékelése elengedhetetlen a megoldás redundanciamechanizmusainak értékeléséhez. Az elemzés során azonosítsa a kockázatokat, a hatásokat és a hatások szélességét (részleges vagy teljes kimaradás). A Mission Critical Online referencia-implementációhoz létrehozott példaelemzésért tekintse meg az egyes összetevők kimaradásával kapcsolatos kockázatokat.

• Figyelés. A teszteredményeket egyenként kell rögzítenie és elemeznie, valamint összesítenie kell őket a trendek időbeli felméréséhez. A pontosság és a lefedettség szempontjából folyamatosan értékelnie kell a teszteredményeket.

Tervezési javaslatok

Az alábbi videóból megtudhatja, hogyan integrálható a rugalmassági tesztelés az Azure DevOps CI/CD-folyamatokkal.

• A konzisztencia biztosításához automatizálja az infrastruktúra- és alkalmazásösszetevők tesztelését. Integrálja a teszteket a CI/CD-folyamatokba, hogy szükség esetén vezénylést és futtatásukat elvégezhesse. A technológiai lehetőségekről további információt a DevOps-eszközökben talál.

• Az összes tesztösszetevőt kódként kezelje. Ezeket a többi alkalmazáskód-összetevővel együtt fenn kell tartani és verziószámmal kell vezérelni.

• A tesztinfrastruktúra SLA-jának és az üzembe helyezési és tesztelési ciklusok SLA-jának igazítása.

• Füsttesztek futtatása minden üzembe helyezés részeként. Emellett futtasson kiterjedt terhelésteszteket, valamint stressz- és káoszteszteket annak ellenőrzésére, hogy az alkalmazás teljesítménye és működőképessége megmarad-e.

  • Használjon valós csúcshasználati mintákat tükröző terhelésprofilokat.
  • A terheléses tesztekkel egyidejűleg káoszkísérleteket és hibainjektálási teszteket is futtathat.

  Tipp.

  Az Azure Chaos Studio a káoszkísérleti eszközök natív csomagja. Az eszközök megkönnyítik a káoszkísérletek elvégzését és a hibák azure-szolgáltatásokba és alkalmazásösszetevőkbe való beszúrását.

  A Chaos Studio beépített káoszkísérleteket biztosít a gyakori hibaforgatókönyvekhez, és támogatja az infrastruktúrát és az alkalmazás összetevőit célzó egyéni kísérleteket.

• Ha az adatbázis-interakciókra, például a rekordok létrehozására van szükség a terheléses vagy füsttesztekhez, használjon olyan tesztfiókokat, amelyek csökkentett jogosultságokkal rendelkeznek, és a tesztadatokat elválasztják a valós felhasználói tartalomtól.

• Az ismert CVE-k végpontok közötti szoftverellátási láncának és csomagfüggőségeinek vizsgálata és monitorozása.

  • A GitHub-adattárakhoz készült Dependabot használatával biztosíthatja, hogy az adattár automatikusan naprakész legyen azoknak a csomagoknak és alkalmazásoknak a legújabb kiadásával, amelyektől függ.

Infrastruktúra kódtelepítésként

Az infrastruktúra kódként (IaC) forráskódként kezeli az infrastruktúradefiníciókat, amelyek verziókövetése más alkalmazásösszetevőkkel együtt történik. Az IaC használata elősegíti a kódkonzisztenciát a környezetekben, kiküszöböli az emberi hibák kockázatát az automatizált üzemelő példányok során, valamint nyomon követhetőséget és visszaállítást biztosít. A kék/zöld üzemelő példányok esetében elengedhetetlen az IaC használata teljesen automatizált üzemelő példányokkal.

A kritikus fontosságú IaC-adattár két különböző definícióval rendelkezik, amelyek globális és regionális erőforrásokra vannak leképezve. Az ilyen típusú erőforrásokról az alapvető architektúramintában olvashat bővebben.

Kialakítási szempontok

• Megismételhető infrastruktúra. A kritikus fontosságú számítási feladatokat úgy helyezze üzembe, hogy minden alkalommal ugyanazt a környezetet hozza létre. Az IaC legyen az elsődleges modell.

• Automatizálás. Minden üzembe helyezésnek teljesen automatizáltnak kell lennie. Az emberi folyamatok hajlamosak a hibákra.

Tervezési javaslatok

• Alkalmazza az IaC-t, biztosítva, hogy minden Azure-erőforrás deklaratív sablonokban legyen definiálva, és egy forrásvezérlő adattárban legyen karbantartva. A sablonok üzembe helyezése és az erőforrások automatikusan ki lesznek építve a forrásvezérlőből CI/CD-folyamatokon keresztül. Nem javasoljuk az imperatív szkriptek használatát.

• Tiltsa le a manuális műveleteket minden környezetben. Az egyetlen kivétel a teljesen független fejlesztői környezetek.

DevOps-eszközök

Az üzembehelyezési eszközök hatékony használata kritikus fontosságú az általános megbízhatóság szempontjából, mivel a DevOps-folyamatok befolyásolják az általános függvény- és alkalmazástervezést. A feladatátvételi és skálázási műveletek például a DevOps-eszközök által biztosított automatizálástól függhetnek. A mérnöki csapatoknak tisztában kell lenniük azzal, hogy az üzembehelyezési szolgáltatás nem érhető el a teljes számítási feladat tekintetében. Az üzembehelyezési eszköznek megbízhatónak és magas rendelkezésre állásúnak kell lennie.

A Microsoft két Azure-natív eszközkészletet, a GitHub Actionst és az Azure Pipelinest biztosítja, amelyek hatékonyan üzembe helyezhetnek és kezelhetnek egy kritikus fontosságú alkalmazást.

Kialakítási szempontok

• Technológiai képességek. A GitHub és az Azure DevOps képességei átfedésben vannak. Használhatja őket együtt, hogy a lehető legjobbat hozza ki mindkettőből. Gyakori módszer a kódtárak tárolása GitHub.com vagy GitHub AE-ben az Azure Pipelines üzembe helyezéshez való használata során.

  Vegye figyelembe a több technológia használatakor hozzáadott összetettségeket. Értékelje ki a gazdag szolgáltatáskészletet az általános megbízhatóság alapján.

• Regionális rendelkezésre állás. A maximális megbízhatóság szempontjából az egyetlen Azure-régiótól való függőség működési kockázatot jelent.

  Tegyük fel például, hogy a forgalom két régióra oszlik: az 1. és a 2. régióra. A 2. régió üzemelteti az Azure DevOps eszközpéldányt. Tegyük fel, hogy a 2. régióban kimaradás van, és a példány nem érhető el. Az 1. régió automatikusan kezeli az összes forgalmat, és további méretezési egységeket kell üzembe helyeznie a jó feladatátvételi élmény érdekében. A 2. régióban azonban az Azure DevOps-függőség miatt nem lesz képes.

• Adatreplikálás. Az adatokat, beleértve a metaadatokat, a folyamatokat és a forráskódot, régiók között kell replikálni.

Tervezési javaslatok

• Mindkét technológia egyetlen Azure-régióban üzemel, ami korlátozóvá teheti a vészhelyreállítási stratégiát.

  A GitHub Actions jól használható buildelési feladatokhoz (folyamatos integrációhoz), de előfordulhat, hogy az összetett üzembehelyezési feladatok (folyamatos üzembe helyezés) funkciói nem érhetők el. Az Azure DevOps gazdag funkciókészlete miatt kritikus fontosságú üzemelő példányokhoz ajánljuk. A kompromisszumok értékelése után azonban érdemes választania.

• Rendelkezésre állási SLA meghatározása az üzembehelyezési eszközökhöz, és az alkalmazás megbízhatósági követelményeivel való összhang biztosítása.

• Aktív/passzív vagy aktív/aktív üzembe helyezési konfigurációt használó többrégiós forgatókönyvek esetén győződjön meg arról, hogy a feladatátvételi vezénylési és skálázási műveletek akkor is működőképesek maradnak, ha az üzembehelyezési eszközkészleteket üzemeltető elsődleges régió elérhetetlenné válik.

Elágaztatási stratégia

Az elágaztatásnak számos érvényes megközelítése van. Olyan stratégiát kell választania, amely biztosítja a maximális megbízhatóságot. A jó stratégia lehetővé teszi a párhuzamos fejlesztést, egyértelmű utat biztosít a fejlesztéstől az éles környezetig, és támogatja a gyors kiadásokat.

Kialakítási szempontok

• A hozzáférés minimalizálása. A fejlesztőknek az ágakban és fix/* a feature/* fiókban kell elvégezniük a munkájukat. Ezek az ágak belépési pontokká válnak a módosításokhoz. Az elágaztatási stratégia részeként szerepköralapú korlátozásokat kell alkalmazni az ágakra. Például csak a rendszergazdák hozhatnak létre kiadási ágakat, vagy az ágak elnevezési konvencióit kényszeríthetik ki.

• Gyorsított folyamat vészhelyzetek esetén. Az elágaztatási stratégiának lehetővé kell tenni a gyorsjavítások mihamarabbi egyesítését main . Így a jövőbeli kiadások tartalmazzák a javítást, és a probléma ismétlődése elkerülhető. Ezt a folyamatot csak a sürgős problémákat elhárító kisebb módosításokhoz használja, és használja visszatartással.

Tervezési javaslatok

• Rangsorolja a GitHub használatát a forrásvezérléshez.

  Fontos

  Hozzon létre egy elágaztatási stratégiát, amely minimálisan részletezi a funkciók működését és kiadásait , és a fiókszabályzatok és engedélyek használatával biztosítja a stratégia megfelelő kikényszerítését.

• Automatikus tesztelési folyamat aktiválása a kódmódosítási hozzájárulások elfogadásának ellenőrzése érdekében. A csapattagok a módosításokat is át kell tekinteni.

• Kezelje az main ágat folyamatosan előre- és stabil ágként, amelyet elsősorban integrációs teszteléshez használnak.

  • Győződjön meg arról, hogy a módosítások csak a PRS-en keresztül történnek main . Használjon fiókszabályzatot a közvetlen véglegesítések tiltásához.
  • A lekéréses kérelem minden egyesítésekor mainautomatikusan üzembe kell helyeznie egy integrációs környezetet.
  • Az main ágat stabilnak kell tekinteni. Biztonságosnak kell lennie, hogy bármikor hozzon létre kiadást main .

• Használjon dedikált release/* ágakat, amelyek az main ágból jönnek létre, és az éles környezetekben való üzembe helyezésre szolgálnak. release/* az ágaknak az adattárban kell maradniuk, és felhasználhatók a kiadások javításához.

• Dokumentáljon egy gyorsjavítási folyamatot, és csak szükség esetén használja. Hozzon létre gyorsjavításokat egy fix/* ágban a kiadási ágba való későbbi egyesítéshez és az éles üzembe helyezéshez.

AI for DevOps

A CI/CD-folyamatokban AIOps-módszereket alkalmazhat a hagyományos tesztelési módszerek kiegészítésére. Ez lehetővé teszi a lehetséges regressziók vagy leromlások észlelését, és lehetővé teszi az üzemelő példányok előzetes leállítását a lehetséges negatív hatások megelőzése érdekében.

Kialakítási szempontok

• Telemetriai adatok mennyisége. A CI/CD-folyamatok és a DevOps-folyamatok számos telemetriát bocsátanak ki a gépi tanulási modellekhez. A telemetriai adatok a tesztelési eredményektől és az üzembe helyezés eredményeitől az összetett üzembehelyezési szakaszok tesztösszetevőinek működési adataiig terjednek.

• Skálázhatóság. Előfordulhat, hogy az olyan hagyományos adatfeldolgozási módszerek, mint a Kinyerés, átalakítás, Betöltés (ETL) nem képesek skálázni az átviteli sebességet, hogy lépést tartsanak az üzembehelyezési telemetriai adatok és az alkalmazások megfigyelhetőségi adatainak növekedésével. Az AIOps-modellek folyamatos elemzésének engedélyezéséhez olyan modern elemzési módszereket használhat, amelyek nem igényelnek ETL-t és adatáthelyezést, például adatvirtualizálást.

• Az üzembe helyezés változásai. Az üzembe helyezés változásait az automatikus elemzéshez és az üzembe helyezési eredményekhez való korrelációhoz kell tárolni.

Tervezési javaslatok

• Definiálja az összegyűjtendő DevOps-folyamatadatokat, és hogyan elemezheti azokat. Fontos a telemetria, például a tesztvégrehajtási metrikák és az egyes üzemelő példányokon belüli változások idősoradatai.

  • Az alkalmazás megfigyelhetőségi adatainak felfedése előkészítési, tesztelési és éles környezetekből az AIOps-modellek elemzéséhez és korrelációjához.

• Az MLOps-munkafolyamat bevezetése.

• Környezettudatos és függőségérzékeny elemzési modelleket fejleszthet, amelyek automatikus funkciófejlesztéssel biztosítják az előrejelzéseket a séma- és viselkedésváltozások kezeléséhez.

• A modellek üzembe helyezéséhez regisztrálja és üzembe helyezi a legjobban betanított modelleket az üzembe helyezési folyamatokban.

Következő lépés

Tekintse át a biztonsági szempontokat.

Biztonság