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

Javaslatok számítási feladatok fejlesztési ellátási láncának megtervezéséhez

  • Cikk

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

OE:06 Olyan számítási feladat ellátási láncának létrehozása, amely kiszámítható, automatizált folyamatokon keresztül hajtja végre a javasolt módosításokat. A folyamatok tesztelik és előléptetik ezeket a változásokat a környezetekben. Optimalizáljon egy ellátási láncot, hogy a számítási feladatok megbízhatóak, biztonságosak, költséghatékonyak és hatékonyak legyenek.

Ez az útmutató a folyamatos integráción és folyamatos kézbesítésen (CI/CD) alapuló számítási feladatok fejlesztési ellátási láncának tervezésére vonatkozó javaslatokat ismerteti. Egy ellátási lánc fejlesztése annak érdekében, hogy kiszámítható, szabványosított módszerrel tarthassa karban a számítási feladatokat. A CI/CD-folyamatok az ellátási lánc megnyilvánulásai, de egyetlen ellátási lánccal kell rendelkeznie. Több folyamat is lehet, amelyek ugyanazokat a folyamatokat követik, és ugyanazokat az eszközöket használják.

Adjon meg egy ellátási láncot, amely megvédi a számítási feladatot a számítási feladatok nem megfelelő kezelésekor fellépő károktól. Mindig legyen tisztában a számítási feladat állapotával, így nem fenyegeti a kiszámíthatatlan viselkedés kockázata. Ez a kockázati vegyületek akkor jelentkeznek, ha kritikus időt kell töltenie, amikor problémák merülnek fel a változások miatt. A kockázatok minimalizálása érdekében szabványosítsa az ellátási láncot meghatározó folyamatokat és eszközöket, és győződjön meg arról, hogy a számítási feladatok csapata teljes mértékben elkötelezi magát a használat mellett.

Definíció

Időszak Definíció
Ellátási lánc A felhőbeli számítási feladatokban az ellátási lánc olyan eszközök és folyamatok szabványosított készlete, amelyekkel hatással lehet az infrastruktúra és az alkalmazások változásaira a különböző környezetekben.

Főbb tervezési stratégiák

Feljegyzés

Az ebben az útmutatóban szereplő javaslatok a kód-előléptetési lánc számítási feladatainak környezeteit ismertetik. A tesztkörnyezet vagy más feltáró és megvalósíthatósági környezetek kevésbé szigorúak és strukturáltak.

Alapvető halmazok

Az alábbi javaslatok segíthetnek meghatározni az ellátási lánc alapvető alapelveit.

Javasolt számítási feladatok módosítása az ellátási lánc folyamatain és eszközein keresztül. Szigorú szabályzat kényszerítése az automatizált sablonalapú üzemelő példányokra. Ez a módszer biztosítja, hogy a számítási feladat konfigurációja minden környezetben szabványos, jól definiált és szigorúan szabályozott legyen. A kód-előléptetési láncban lévő környezetek esetében ne végezzen frissítéseket manuális folyamatokkal vagy a felhőplatform vezérlősíkjával való emberi interakcióval, például a portállal vagy egy API-val. A környezet minden módosításának belefoglalása folyamaton keresztül az Ön által meghatározott üzembehelyezési eljárások követésével. A szabályzat érvényre juttatásához fontolja meg a csak olvasási hozzáférés alapértelmezettként való korlátozását, valamint a hozzáférés-engedélyezési kapu használatát az írási hozzáférés engedélyezéséhez.

Ennek a szemléletnek az egyik fontos eleme, hogy az összes módosítás javasolt, amíg éles környezetben nem lesznek üzembe helyezve. Az automatizált tesztelés, például az integráció és a füsttesztelés révén lehetővé teszi, hogy az ellátási lánc automatikusan elutasítsa a módosításokat.

Ismétlődő és nem módosítható infrastruktúra üzembe helyezése kódként (IaC). Az IaC az infrastruktúra kezelése egy leíró modellben, amely egy verziószámozási rendszert használ, amely a forráskódot tükrözi. Alkalmazás létrehozásakor ugyanaz a forráskód minden fordításkor ugyanazt a bináris fájlt hozza létre. Hasonló módon egy IaC-modell minden alkalmazáskor ugyanazt a környezetet hozza létre.

Az IaC beépítése biztosítja, hogy csapata egy szabványos, jól bevált folyamatot kövessen. Egyes szervezetek egyetlen vagy kis csoportot jelölnek ki az infrastruktúra üzembe helyezéséhez és konfigurálásához. Egy teljesen automatizált folyamat implementálásakor az infrastruktúra-üzembe helyezések kevesebb felügyeletet igényelnek az egyénektől. A felelősség átkerül az automatizálási folyamatra és az eszközökre. A csapattagok infrastruktúra-telepítéseket kezdeményezhetnek a konzisztencia és a minőség fenntartása érdekében.

Tervezheti meg a számítási feladatot olyan összetevők logikai csoportjaként, amelyeket egyetlen sablonba csomagolhat, hogy az üzembe helyezés egyszerűen és megismételhető legyen. Ezeket a kötegeket bélyegként vagy méretezési egységként is felfoghatja. További információ: Üzembehelyezési bélyegek minta. Ha üzembe kell helyeznie a számítási feladatot egy másik régióba vagy zónába való vertikális felskálázáshoz ugyanabban a régióban, helyezzen üzembe egy bélyeget egy folyamat használatával. A bélyegek tervezésétől függően előfordulhat, hogy a teljes számítási feladat helyett a számítási feladat egy részét helyezi üzembe. Vegye fel a hálózati összetevőket az IaC-folyamatokba, hogy az üzembehelyezési bélyegek automatikusan csatlakozzanak a meglévő erőforrásokhoz.

Az IaC-folyamat konzisztenciára és hatékonyságra való optimalizálásához ne egy módosítható infrastruktúrát, hanem egy nem módosítható infrastruktúrát tervezzen. Implementáljon egy nem módosítható infrastruktúrát, amely biztosítja, hogy a hatókörben lévő összes rendszer a frissített konfigurációval egyidejűleg és az egyes üzemelő példányokkal azonos módon legyen lecserélve.

Használjon egy kódegység- és összetevőkészletet minden környezetben és folyamatban. A szervezetek gyakori fájdalompontja, ha a nem termelési környezetek eltérnek az éles környezetektől. Az éles és a nem termelési környezetek manuális létrehozása eltérő konfigurációkat eredményezhet a környezetek között. Ez a eltérés lelassítja a tesztelést, és nagyobb valószínűséggel okoz kárt az éles rendszerekben. Az IaC-megközelítés minimalizálja ezeket a problémákat. Az IaC-automatizálás használatakor az összes környezethez ugyanazokat az infrastruktúra-konfigurációs fájlokat használhatja szinte azonos környezetek létrehozásához. Paramétereket adhat hozzá az infrastruktúra konfigurációs fájljaihoz, és módosíthatja őket, hogy megfeleljenek az egyes környezetek követelményeinek.

A költségek szabályozásához általában az éles és a nem termelési környezetek közötti eltérés van. Gyakran nincs szüksége ugyanolyan mértékű redundanciára és teljesítményre a nem termelési környezetekben, mint az éles környezetben. Az erőforrások száma és termékváltozata eltérhet a környezetek között. Győződjön meg arról, hogy szabványosított paraméterekkel szabályozhatja és megértheti a varianciát, hogy a módosítások során a kiszámíthatóság megmaradjon.

Az ellátási lánc és a folyamattervek szervezeti struktúrájának tükrözése. Előfordulhat, hogy a szervezet el van silózva a csapatok között. Minden csapat felügyelheti az ellátási lánc egy részét. Számos szervezet például olyan csapatokkal rendelkezik, amelyek infrastruktúra-tartományokat kezelnek, például hálózatkezelést, adatokat és számítási erőforrásokat. Ezek a csapatok elkülönülnek az alkalmazásfejlesztést, tesztelést és üzembe helyezést kezelő fejlesztői csapatoktól. Egyes szervezetekben fejlesztési és infrastruktúra-csapatok vannak beépítve a DevOps-csapatokba, amelyek együttesen kezelik az összes infrastruktúra- és alkalmazástelepítést. Számos módon rendszerezheti az ellátási láncban részt vevő csapatokat. Az ellátási lánc az összes csapat zökkenőmentes együttműködésére támaszkodik. Győződjön meg arról, hogy minden csapat a szabványos folyamatokat követi, és szabványos eszközökkel teszi a lehető leghatékonyabbsá az ellátási láncot.

Az ellátási lánc külső gyártókra támaszkodhat, ha kiszervezi a számítási feladatok életciklusának egyes részeit. Ezek a szállítók ugyanolyan kritikus fontosságúak az ellátási lánc sikeressége szempontjából, mint a belső erőforrások. Győződjön meg arról, hogy minden csapat kölcsönösen megállapodik a használt folyamatokkal és eszközökkel kapcsolatban.

Szabványosítsa az üzembe helyezési módszert. Beszéljen a termék tulajdonosával a számítási feladat elfogadható üzemszünetéről. Attól függően, hogy az állásidő mennyire elfogadható, kiválaszthatja a követelményeknek megfelelő üzembe helyezési módszert. Ideális esetben az összetettség és a kockázat csökkentése érdekében üzembe helyezéseket kell végrehajtania egy karbantartási időszak alatt. Ha nem elfogadható az állásidő, alkalmazzon egy kék-zöld üzembe helyezési módszert.

Progresszív expozíciós megközelítéssel csökkentheti annak kockázatát, hogy észrevétlen hibákat vezessen be az ügyfelek számára. Ez a módszer más néven kanári-üzemelő példányok, fokozatos sorrendben, szabályozott felhasználói csoportokra telepíthető. A problémákat még azelőtt elkapja, hogy több felhasználót érintenének. A kezdeti bevezetési csoport az ügyfelek egy olyan alszakasza lehet, amely tisztában van a bevezetési stratégiával. Az ügyfelek ezen alszakasza bizonyos mértékű váratlan viselkedést tolerálhat, és visszajelzést adhat. Vagy belső felhasználók csoportja lehet, amely segít a hibák robbanási sugarának megfékezésében a bevezetés során.

Az üzembe helyezési módszer meghatározásakor olyan szabványos szabályzatot kell alkalmaznia, amely csak a legkisebb működőképes módosítást helyezi üzembe az egyes üzemelő példányokban. Az olyan tényezőktől függően, mint a számítási feladat kritikussága és az összetevők összetettsége, határozza meg a legkisebb életképes változást. Ha nem módosítható infrastruktúrát használ, a legkisebb megvalósítható változás általában az erőforrások központi telepítése a legújabb konfigurációval az előző verziót futtató erőforrások lecseréléséhez. Ha mutable infrastruktúrát használ, dönthet úgy, hogy a legkisebb megvalósítható változás csak egyetlen frissítés a hatókörben lévő erőforráscsoporton.

Kövesse a rétegzett megközelítést a különböző életciklusok tükrözéséhez. Az alapszintű rétegeknek statikusnak kell maradniuk a számítási feladatok életciklusának nagy részében, és az alkalmazásrétegek gyakran változnak. Ezeknek a különbségeknek a figyelembe vételéhez különböző folyamatokkal kell rendelkeznie a módosítások minden rétegben való érvénybe léptetéséhez.

A kezdőzóna a legalacsonyabb rétegben található. A kezdőzóna olyan alapvető elemek logikai csoportosítása, mint az előfizetések, a felügyeleti csoportok, az erőforráscsoportok, a szabályozási függvények és a hálózati topológia. A célzóna lehetővé teszi a számítási feladatok egyszerű üzembe helyezését és kezelését, valamint központi üzemeltetési csapatokat vagy platformcsapatokat biztosít a környezeti konfiguráció megismételhető megközelítésével. A konzisztens környezetek biztosításához minden Azure-beli célzóna közös tervezési területeket, referenciaarchitektúrát, referencia-implementációt és egy olyan folyamatot biztosít, amely a tervezési követelményeknek megfelelően módosítja az üzemelő példányt. Az Azure célzóna tervezési alapelvei a szabályzatalapú irányításon alapuló ajánlott eljárásokat biztosítják az előfizetések demokratizálása mellett. A kezdőzónának minimális változtatásokat kell megkövetelnie a számítási feladatok életciklusa során. A célzóna példáját a Mi az Azure-beli célzóna? Ez a fogalmi architektúra az Azure-hoz ajánlott véleményhalmazt nyújt.

Az alapvető infrastruktúrának és funkcióknak, például a bejövő és kimenő hálózati vezérlőknek, a terheléselosztásnak, a hálózati útválasztási megoldásoknak, a DNS-kezelésnek és a magkiszolgálóknak is ritkán kell jelentős módosításokat igényelniük. Előfordulhat azonban, hogy gyakori konfigurációfrissítéseket igényelnek.

Az alkalmazás és az adatréteg gyakori konfigurációfrissítéseket és gyakori infrastruktúra-módosításokat igényel. Ezeknek az összetevőknek a legdinamikusabb folyamatokkal kell rendelkezniük.

Tervezze meg a holisztikus tesztelési stratégiát. A rendszer megbízhatóságának alapvető alapelve a bal oldali eltolódás elve. Az alkalmazások fejlesztése és üzembe helyezése olyan folyamat, amely balról jobbra haladó lépések sorozataként jelenik meg. A tesztelést nem szabad a folyamat végéig korlátozni. A lehető legnagyobb mértékben váltsa át a tesztelést az elejére vagy balra. A hibákat olcsóbban lehet kijavítani, ha korán elkapja őket. Ezek költségesek vagy lehetetlenek lehetnek az alkalmazás életciklusának későbbi szakaszában.

Tesztelje az összes kódot, beleértve az alkalmazáskódot, az infrastruktúrasablonokat és a konfigurációs szkripteket. Az alkalmazásokat futtató környezetet verzióalapúan kell vezérelni és üzembe helyezni az alkalmazáskóddal megegyező mechanizmusokkal. A környezet teszteléséhez és érvényesítéséhez ugyanazokat a tesztelési paradigmákat használhatja, amelyeket a csapatok már használnak az alkalmazáskódhoz.

Ha lehetséges, a konzisztencia biztosításához használjon automatizált tesztelést. Az ellátási lánc kialakításában vegye fel a következő tesztelési típusokat.

  • Egységtesztelés: Az egységtesztek általában egy folyamatos integrációs rutin részeként futnak. Az egységtesztek széles körűnek és gyorsnak kell lenniük. Ideális esetben a kód 100 százalékát fedik le, és 30 másodperc alatt futnak.

    Egységtesztelés implementálása annak ellenőrzésére, hogy az egyes kódmodulok szintaxisa és működése a kívánt módon működik-e, például egy ismert bemenethez meghatározott kimenetet hoz létre. Az egységtesztekkel azt is ellenőrizheti, hogy az IaC-eszközök érvényesek-e.

    Egységtesztek alkalmazása az összes kódegységre, beleértve a sablonokat és a szkripteket is.

  • Füsttesztelés: A füsttesztek ellenőrzik, hogy egy számítási feladat felállhat-e egy tesztkörnyezetben, és a várt módon működik-e. A füsttesztek nem ellenőrzik az összetevők együttműködési képességét.

    A füsttesztek ellenőrzik, hogy az infrastruktúra és az alkalmazás üzembe helyezési módszertana működik-e, és hogy a rendszer a folyamat befejezése után a kívánt módon válaszol-e.

  • Integrációs tesztelés: Az integrációs tesztek biztosítják, hogy az alkalmazás-összetevők külön-külön működjenek, majd meghatározzák, hogy az összetevők képesek-e a megfelelő módon kommunikálni egymással.

    Egy nagy integrációs tesztcsomag futtatása jelentős időt vehet igénybe. Ezért érdemes beépíteni a bal oldali shift elvet, és a szoftverfejlesztési életciklus korai szakaszában elvégezni a tesztelést. Integrációs tesztek lefoglalása olyan forgatókönyvekhez, amelyeket nem lehet füstteszttel vagy egységteszttel tesztelni.

    Szükség esetén rendszeres időközönként futtathat hosszú ideig futó tesztfolyamatokat. A rendszeres időközök jó kompromisszumot kínálnak, és a bevezetésük után legkésőbb egy nappal észlelik az alkalmazás-összetevők közötti együttműködési problémákat.

    Egyes tesztelési forgatókönyvek kihasználják a manuális futtatás előnyeit. Akkor használjon manuális tesztelést, ha emberi interaktivitási elemeket kell bevezetnie a tesztekbe.

  • Elfogadási tesztelés: A környezettől függően manuálisan is elvégezheti az elfogadási tesztelést. Részben vagy teljesen automatizálható. Az elfogadási tesztelés meghatározza, hogy a szoftverrendszer megfelel-e a követelmények specifikációinak.

    Ennek a tesztnek a fő célja annak értékelése, hogy a rendszer megfelel-e az üzleti követelményeknek, és meghatározza, hogy a rendszer megfelel-e a végfelhasználóknak történő kézbesítéshez szükséges feltételeknek.

Minőségi kapuk implementálása a kód promóciós folyamatában teszteléssel. Helyezze üzembe a kódot alacsonyabb környezetekben, például fejlesztésben és tesztelésben, valamint magasabb környezetekben, például előkészítésben és éles környezetben. Ahogy az üzembe helyezés áthalad a minőségi kapukon, győződjön meg arról, hogy az megfelel a minőségi céloknak, mielőtt a változások éles környezetbe kerülnek. Az üzleti követelmények határozzák meg, hogy mi a fókusz a minőségi kapuk. Vegye figyelembe az alapvető, jól kigondolt keretrendszer alapelveit is: a biztonságot, a megbízhatóságot és a teljesítményhatékonyságot.

A jóváhagyási munkafolyamatokat is integrálhatja a minőségi kapukba. Szükség esetén egyértelműen definiálhatja és automatizálhatja a jóváhagyási munkafolyamatokat. Minőségi elfogadási kritériumokat határozhat meg az automatizálásban, hogy hatékonyan és biztonságosan léphesse át a kapuit.

Az Azure megkönnyítése

Az Azure DevOps olyan szolgáltatások gyűjteménye, amelyek segítenek egy együttműködési, hatékony és konzisztens fejlesztési gyakorlat kialakításában.

Az Azure Pipelines buildelési és kiadási szolgáltatásokat biztosít a CI/CD alkalmazásokban való támogatásához.

Az Azure-hoz készült GitHub Actions integrálható az Azure-ral az üzembe helyezés egyszerűsítése érdekében. A GitHub Actions használatával automatizálhatja a CI-/CD-folyamatokat. Létrehozhat olyan munkafolyamatokat, amelyek minden lekéréses kérelmet létrehoznak és tesztelnek az adattárban, vagy egyesített lekéréses kérelmeket helyeznek üzembe éles környezetben.

Az IaC-környezetekhez használhatja a Terraform, a Bicep és az Azure Resource Managert. A követelményektől és a csapat eszközeinek ismeretétől függően ezek közül az eszközök közül egy vagy több használható az üzemelő példányokhoz és az erőforrások kezeléséhez.

Példa

Az Azure Pipelines ci/CD-folyamat létrehozásához való használatát bemutató példaért tekintse meg az Azure Pipelines alaparchitektúrát.

Az Operation Excellence ellenőrzőlistája

Tekintse meg a javaslatok teljes készletét.

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