Az Azure célzóna tervezési alapelvei

Az Azure-beli kezdőzóna referenciaarchitektúrája általánosan érvényes minden Azure-beli célzóna-folyamatra vagy megvalósításra. Az architektúra alapjaiban az alapvető tervezési alapelvek halmaza iránytűként szolgál a kritikus műszaki területeken történő későbbi tervezési döntésekhez.

Az alapelvek szándékosan ösztönzők, hogy elősegítsék a célarchitektúra optimális kialakítását. Ha egy Azure-beli célzóna referenciaarchitektúráját vagy a nagyvállalati szintű kezdőzóna kódbázisának bármely verzióját tartalmazó implementációt szeretne üzembe helyezni, a jelen cikkben ismertetett tervezési alapelvek alkalmazásával építsen az architektúrára.

Ezeket az alapelveket hasznos útmutatóként használhatja a felhőtechnológiák előnyeinek kihasználásához. Ez a felhőalapú vagy natív felhőbeli megközelítés olyan munkamódszereket és technikai lehetőségeket jelent a szervezet számára, amelyeket az örökölt technológiai megközelítések általában nem kínálnak.

Ismerkedjen meg ezekkel az alapelvekkel, hogy jobban megértse azok hatását és az eltéréssel járó kompromisszumokat.

A tervezési eltérések hatása

A tervezési alapelvektől való eltérésnek lehetnek érvényes okai. Előfordulhat például, hogy a szervezeti követelmények konkrét eredményeket vagy megközelítéseket diktálnak egy Azure-környezet megtervezéséhez. Ilyen esetekben fontos tisztában lenni azzal, hogy az eltérés milyen hatással van a tervezésre és a jövőbeli műveletekre. Alaposan gondolja át az egyes alapelvekben ismertetett kompromisszumokat.

Általános szabályként fel kell készülni a követelmények és a funkciók egyensúlyára. Az Ön koncepcionális architektúrához vezető út folyamatosan fejlődik, ahogy változnak a követelmények, és Ön tanul a megvalósításból. Például az előzetes verziójú szolgáltatások használata és a szolgáltatási ütemtervtől függően eltávolíthatja a technikai blokkolókat a bevezetés során.

Előfizetések demokratizálása

Az előfizetések demokratizálása skálázható módot kínál az alkalmazások migrálásának és az új alkalmazások fejlesztésének felgyorsítására. Ez a megközelítés lehetővé teszi, hogy a számítási feladatok csapatai egymástól függetlenül férhessenek hozzá és felügyelhessék az Azure-előfizetéseket, miközben a platformirányítási és üzemeltetési védőkorlátokon belül maradnak.

  1. Előfizetések használata felügyeleti egységekként. Az előfizetések az Azure-erőforrások rendszerezésének és kezelésének alapvető határát jelentik. Előfizetések hozzárendelése üzleti egységekhez a számítási feladatok tervezésének, fejlesztésének, tesztelésének és migrálásának támogatásához. Az üzleti igényekhez és prioritásokhoz való igazodás lehetővé teszi, hogy a portfóliótulajdonosok és a számítási feladatok csapatai gyorsabban érhessenek el értéket.

  2. Előfizetések használatával különítse el az alkalmazáskörnyezeteket. Az előfizetéseket a szoftverfejlesztési életciklus (SDLC) környezeteinek szabályozására és elkülönítésére is használni kell, például fejlesztésre, tesztelésre és éles üzemre. Ez az elkülönítés javítja a szabályozást, csökkenti a kockázatokat, és támogatja a konzisztens számítási feladatok kezelését. Kövesse az azure-beli kezdőzónák alkalmazásfejlesztési környezeteinek felügyeletére vonatkozó útmutatást.

  3. Önkiszolgáló előfizetés-feldolgozási folyamat engedélyezése. Hozzon létre egy folyamatot, amely lehetővé teszi az alkalmazás- és szolgáltatáscsoportok számára, hogy minimális súrlódással igényeljenek és fogadjanak előfizetéseket. Az önkiszolgáló vagy közeli önkiszolgáló modellek csökkentik a manuális jóváhagyások és az összetett üzleti kijelentkezések okozta késéseket. Kövesse az előfizetés-átadással kapcsolatos útmutatást a kiépítés egyszerűsítése és az innováció felgyorsítása érdekében.

  4. Több előfizetéstípust is kínálhat a különböző követelmények támogatására. Különböző számítási feladatokra szabott előfizetési terméksorokat biztosít. Ez a rugalmasság lehetővé teszi a csapatok számára, hogy az igényeiknek leginkább megfelelő előfizetési típust válasszák. Tekintse meg a gyakori előfizetés-automaták terméksorainak létrehozását.

  5. Skálázható felügyeleticsoport-hierarchiával rendelkező előfizetések támogatása. Az előfizetések hatékony, nagy léptékű üzemeltetéséhez, szabályozásához és biztonságossá tételéhez használjon jól definiált felügyeleticsoport-hierarchiát . Ez a hierarchia lehetővé teszi a központosított szabályzatkényszerítést és a hatékony több-előfizetéses szervezetet. A konzisztencia biztosítása érdekében kövesse az Azure-beli kezdőzóna által javasolt hierarchiátés előfizetés-kialakítási szempontokat és javaslatokat .

Tip

Az előfizetések demokratizálásával kapcsolatos további információkért tekintse meg az Azure Landing Zones legújabb YouTube-videóját – Hány előfizetést érdemes használni az Azure-ban?

Az eltérés hatása

  • Megosztott kezelés és központosított műveletek. Ennek az alapelvnek az egyik módja a műveletek üzleti egységekre és számítási feladatokért felelős csapatokra való áttérése. Ez az újraelosztás lehetővé teszi, hogy a számítási feladatok tulajdonosai nagyobb ellenőrzést és önállóságot élvezjenek a számítási feladatok felett, a platformalaprendszer védőkorlátjai között. Azok a szervezetek, amelyek központi működést igényelnek, előfordulhat, hogy nem szeretnék az éles környezetek irányítását a munkaterhelést kezelő csapatoknak vagy üzleti egységeknek delegálni. Előfordulhat, hogy ezeknek a szervezeteknek módosítaniuk kell az erőforrás-szervezet kialakítását, hogy eltérjenek ettől az alapelvtől.

  • Az üzemeltetési modell eltérése. Az Azure-beli kezdőzóna referenciaarchitektúrájának kialakítása egy adott felügyeleti csoportot és előfizetési hierarchiát feltételez az összes üzemeltetési felügyeleti előfizetéshez. Előfordulhat, hogy ez a hierarchia nem összhangban van a műveleti megközelítéssel. A szervezet növekedésével és fejlődésével az üzemeltetési modell változhat. Az erőforrások külön előfizetésekbe való áthelyezése bonyolult technikai migráláshoz vezethet. Mielőtt elkötelezi magát egy megközelítés mellett, tekintse át az Igazítás útmutatót.

  • Az előfizetés-feldolgozási folyamat és az automatizálás hiánya. Ha nem biztosít előfizetés-átadási folyamatot és a kapcsolódó automatizálást, akár önkiszolgáló, akár nem, az alkalmazás- és szolgáltatáscsapatok késleltetik a szervezet számára az érték átadását, miközben az előfizetések létrejönnek számukra, és a megfelelő felügyeleti csoportot helyezik a hierarchiába. Ha az új előfizetések beszerzésének folyamata bonyolult, és hosszú időt vesz igénybe, az alkalmazás- és szolgáltatáscsapatok dönthetnek úgy, hogy alternatív számlázási fiókokon keresztül, esetleg nem felügyelt vagy felügyelt Microsoft Entra-bérlőkben is létrehoznak előfizetéseket, ami azt jelenti, hogy az árnyék informatikai részleg már létezik.

Szabályzatalapú irányítás

Az Azure Policy segítségével lásson el védőkorlátokat, és biztosítsa, hogy a telepített alkalmazások megfeleljenek a szervezet biztonsági, irányítási és szabályozási előírásainak, amelyek függetlenek az implementálási és konfigurációs eszközöktől. Az Azure Policy biztosítja a platformcsapatoknak a szükséges eszközöket az Azure vezérlési és adatsík-műveleteinek és konfigurációinak megvalósításához, kikényszerítéséhez, naplózásához és szabályozásához. Ez lehetővé teszi az előfizetések demokratizálását, ideális esetben önkiszolgáló folyamaton keresztül az alkalmazás- és szolgáltatási csapatok számára, hogy gyorsan üzleti értéket nyújtsanak a szervezet számára.

Az Azure Policy használatával kapcsolatos további információkért tekintse át a szabályzatalapú védőkorlátok bevezetését.

Az eltérés hatása

Nagyobb üzemeltetési és felügyeleti többletterhelés. Ha nem használja az Azure Policyt védőkorlátok létrehozására a környezetben, növelheti a megfelelőség fenntartásával kapcsolatos üzemeltetési és felügyeleti többletterhelést. Az Azure Policy segítségével korlátozhatja és automatizálhatja a kívánt megfelelőségi állapotot a környezetben.

Egyetlen vezérlő és felügyeleti sík

Kerülje az absztrakciós rétegek, például az ügyfél által fejlesztett portálok vagy eszközök függőségét. A legjobb, ha konzisztens felhasználói élményt nyújt a központi műveletekhez és a számítási feladatokhoz. Az Azure egységes és konzisztens vezérlési síkot biztosít, amely minden Azure-erőforrásra és kiépítési csatornára érvényes, más néven Azure Resource Manager. A vezérlősík szerepköralapú hozzáférés-vezérlők és szabályzatalapú vezérlők hatálya alá tartozik. Ezzel az Azure-vezérlősíkkal szabványosított szabályzatokat és vezérlőket hozhat létre, amelyek a teljes vállalati tulajdont szabályozzák.

Az eltérés hatása

Nagyobb integrációs összetettség. A vezérlési és felügyeleti síkok több szállítós megközelítése komplexitást okozhat az integráció és a funkciótámogatás terén. Az egyes összetevők lecserélésének célja a "legjobb típusú" tervezés vagy a több gyártós műveleti eszközkészlet, de ennek megvannak a maga korlátai, és az eredendő függőségek miatt nem kívánt hibákat okozhat.

Ha meglévő eszközbefektetést hoz a műveletekbe, a biztonságba vagy a szabályozásba, tekintse át az Azure-szolgáltatásokat és a függőségeket.

Alkalmazásközpontú szolgáltatásmodell

Koncentráljon az alkalmazásközpontú migrálásra és fejlesztésre a tiszta infrastruktúra-átemelési és -váltási migrálások, például a virtuális gépek áthelyezése helyett. A tervezési lehetőségek nem különböztethetők meg a régi és az új alkalmazások, az infrastruktúra szolgáltatásként (IaaS) vagy a szolgáltatásként nyújtott platform (PaaS) alkalmazások között.

A szolgáltatásmodelltől függetlenül törekedjen biztonságos környezetet biztosítani az Azure-platformon üzembe helyezendő összes alkalmazás számára.

Az eltérés hatása

  • A szabályozási szabályzatok összetettségének növelése. Ha a számítási feladatokat a felügyeleti csoport hierarchiájának implementálási beállításaitól eltérően szegmentálta, növelheti a környezetét szabályozó szabályozási szabályzatok és hozzáférés-vezérlési struktúrák összetettségét. Ilyen például a szervezeti hierarchia struktúrájától való eltérés vagy az Azure-szolgáltatás szerinti csoportosítás.

  • Megnövekedett üzemeltetési többletterhelés. Ez a kompromisszum a szabályzatok véletlen duplikálásának és kivételeknek a kockázatát eredményezi, ami növeli a működési és felügyeleti többletterheket.

  • A fejlesztési/tesztelési/éles környezet egy másik gyakori megközelítés, amelyet a szervezetek is figyelembe venek. További információ: Hogyan kezeljük a "dev/test/production" számítási feladat kezdőzónáinak kezelését az Azure célzóna architektúrájában.

Igazodás az Azure natív tervezéséhez és ütemterveihez

Használja az Azure natív platformszolgáltatásait és képességeit, amikor csak lehetséges. Ennek a megközelítésnek összhangban kell lennie az Azure platform ütemterveivel, hogy az új képességek elérhetők legyenek a környezetekben. Az Azure platform ütemterveinek segítenie kell a migrálási stratégiát és az Azure-beli célzóna elméleti ütemtervét.

Az eltérés hatása

Nagyobb integrációs összetettség. Ha harmadik féltől származó megoldásokat vezet be az Azure-környezetbe, függőséget hozhat létre ezektől a megoldásoktól, így funkciótámogatást és integrációt biztosíthat az Azure belső szolgáltatásaival.

Előfordulhat, hogy a meglévő külső megoldásberuházások környezetbe való beépítése elkerülhetetlen. Vegye figyelembe ezt az elvet és annak kompromisszumait, hogy összhangban legyen a követelményekkel.

Következő lépések

Előfordulhat, hogy a szervezetek a felhőbeli utazásuk különböző szakaszaiban járnak, amikor áttekintik ezt az útmutatót. Ezért az előző eredmények elérésére vonatkozó szükséges intézkedések és javaslatok eltérőek lehetnek. A felhőbevezetési szakasz legjobb következő műveleteinek megismeréséhez tekintse át a célarchitektúra felé vezető utat.

A megfelelő Azure-beli célzóna-megvalósítási lehetőség kiválasztásához ismerje meg az Azure célzóna tervezési területeit.