Natív felhőmegoldások tervezése

A natív felhőmegoldások új számítási feladatok létrehozásával vagy a meglévők továbbfejlesztésével üzleti értéket hoznak létre. Akár új alkalmazást fejleszt, akár új funkciókat ad hozzá egy meglévő rendszerhez, a natív felhőfejlesztés végigvezeti a számítási feladatok tervezésén, létrehozásán, üzembe helyezésén és optimalizálásán. Ez a keretrendszer útmutatást nyújt az alkalmazás üzleti célokhoz, az architekturális ajánlott eljárásokhoz és a kockázatkezeléshez való igazításához.

Előfeltételek:Azure landing zone

A bal oldalon három címkézett mező, az Startups, a Enterprises és a Existing számítási feladatok az "Új üzleti érték létrehozása" fejléc alatt vannak csoportosítva. A nyilak ezekből a mezőkből négy lépésből álló függőleges sorrendbe vezetnek: 1 a natív felhő megtervezése, 2 a natív felhő létrehozása, 3 a natív felhő üzembe helyezése és 4 a natív felhő optimalizálása. Az utolsó nyíl egy Azure-ikonra mutat, amely azt jelzi, hogy itt élnek a "natív felhőbeli alkalmazások, számítási feladatok és funkciók".

Natív felhőmegoldások üzleti célkitűzéseinek meghatározása

1. Kezdje egyértelmű üzleti célokkal. Határozza meg a megoldás által elérni kívánt konkrét eredményeket, például egy új digitális termék engedélyezését, új piacra lépését, az ügyfélélmény javítását vagy a működési költségek csökkentését. A siker számszerűsítéséhez használjon mérhető mutatókat, például bevételnövekedést, piaci időcsökkenést vagy támogatási jegymennyiséget. Új funkciók esetén definiáljon olyan célokat, mint az ügyfélélmény javítása, a működési költségek csökkentése vagy a rendszer méretezhetőségének növelése.

2. Határozza meg a korlátozásokat és a sikerességi feltételeket. Dokumentálja az üzleti korlátozásokat, például a költségvetést, a megfelelőséget vagy a teljesítési ütemterveket. Határozza meg, hogyan néz ki a siker az egyes célokhoz. Például "nyisson meg egy új ügyfélportált a 4. negyedév szerint" vagy "csökkentse a pénztár késését 40%." Ezek a kritériumok rangsorolást nyújtanak, és segítenek kiértékelni a kompromisszumokat a tervezés során.

3. Az érdekelt felek összhangjának érvényesítése. Győződjön meg arról, hogy minden érdekelt (üzleti és műszaki) egyetért a célokban, a korlátozásokban és a siker megjelenésében. Ez az igazítás workshopokat vagy formális jóváhagyásokat is magában foglalhat. A korai igazítás megakadályozza a későbbi félreértéseket, és elkerüli a költséges újramunkát, biztosítva, hogy mindenki ugyanazokat az elvárásokat használja a kezdetektől fogva.

Natív felhőbeli megoldások követelményeinek meghatározása

1. A dokumentum működési követelményei. Dokumentálja azokat a képességeket és funkciókat, amelyeket a rendszernek biztosítania kell a felhasználói igények kielégítéséhez. Minden követelménynek egy üzleti célkitűzéshez kell kötődnie, biztosítva, hogy a fejlesztési erőfeszítések közvetlenül támogatják a kívánt eredményeket. Az érdekelt felekkel folytatott interjúk és üzleti stratégiai dokumentumok segítségével azonosíthatja a nagy értékű eredményeket. Az üzleti érték és a műszaki megvalósíthatóság alapján rangsorolja a funkciókat. Minden követelményt kövessünk nyomon mérhető üzleti célkitűzésekhez azért, hogy azok igazoltak legyenek.

2. Nem funkcionális követelmények meghatározása. A nem funkcionális követelmények a funkcionális követelményeknek és az irányításnak megfelelő műszaki követelményeket határoznak meg. A funkciók támogatásához szükséges minőségi attribútumok és technikai célok meghatározása. Határozza meg a cél megbízhatósági metrikákat , például a szolgáltatásiszint-célkitűzéseket (SLO-kat) az üzemidőhöz, a helyreállítási pont célkitűzéseit (RRP-k) és a helyreállítási idő célkitűzéseit (KPO-k). Biztonsági alapkonfiguráció létrehozása. Költségmodell létrehozása. Teljesítménycélok beállítása.

3. Natív felhőmegoldások hatókörének szabályozása. Egyértelműen határozza meg a hatókörön belüli és a hatókörön kívüli verziót a kezdeti kiadáshoz. Csábító, hogy több "jó, hogy van" funkciót is beépítsünk, de a terjedelem kúszása veszélyeztetheti az ütemterveket és a költségvetéseket. Dokumentálja a megoldás határait, és implementáljon egy változáskezelési folyamatot minden új kéréshez. Csak olyan módosításokat hagyhat jóvá, amelyek közvetlenül támogatják a meghatározott célokat, és amelyek az ütemezés vagy a költségvetés aláásása nélkül is megvalósíthatók. Halaszd az alacsonyabb prioritású ötleteket egy jövőbeli teendőlistára. A hatókör szigorú kezelésével a csapat elsősorban a legértékesebb funkciók biztosítására összpontosít a korlátozásokon belül.

Natív felhőbeli architektúrák tervezése

A jól megtervezett architektúra elengedhetetlen a célok és követelmények teljesítéséhez. Minden jelentős architekturális döntés magában foglalja a méretezhetőség, az összetettség, a költség és az agilitás kompromisszumoit. Az alábbi lépések és döntési pontok segítenek az ajánlott eljárásoknak megfelelő natív felhőbeli kialakítás kialakításában:

Az érvényesített natív felhőarchitektúrák felfedezése

1. Tekintse át az architektúra alapjait. Mielőtt teljesen új architektúrát talál, tekintse át az Azure Architecture Center érvényesített referenciaarchitektúráit és alapjait. Megismerheti a gyakori számítási feladatok érvényesített referenciaarchitektúráit. Ezek az architektúrák segítenek felgyorsítani a tervezési döntéseket és csökkenteni a kockázatokat.

2. Válasszon egy megfelelő architektúrastílust. Válasszon egy architektúrastílust a számítási feladat jellemzői és a csapat képességei alapján. Az architektúrastílusok közé tartozik az N szintű (monolitikus), a mikroszolgáltatások, az eseményvezérelt (üzenetalapú), a webes üzenetsor-feldolgozó. Ha például gyors fejlesztésre van szüksége egy viszonylag egyszerű alkalmazáshoz, elegendő lehet egy jól strukturált N szintű monolith. A nagy léptékű vagy gyorsan fejlődő, különböző tartományokkal rendelkező alkalmazások esetében a mikroszolgáltatások vagy az eseményvezérelt megközelítések rugalmasságot biztosítanak (az összetettség árán). A gyakorlatban sok rendszer hibrid stílussal végződik. Van például egy mikroszolgáltatás-mag néhány megosztott szolgáltatással vagy egy eseményvezérelt alrendszerrel. A legfontosabb az egyes stílusok kompromisszumoinek megértése és a méretezhetőségi, rugalmassági és rugalmassági követelményeknek legjobban megfelelő megközelítés kiválasztása.

3. Ajánlott tervezési eljárások alkalmazása. Függetlenül attól, hogy milyen stílust választ, tartsa be a felhőarchitektúra alapjait és ajánlott eljárásait. Az Azure Architecture Center katalógust biztosít a felhőtervezési mintákról (Retry, Circuit Breaker, CQRS), amelyek az elosztott számítási feladatok gyakori kihívásaival foglalkoznak. Ezeknek a mintáknak a tervezésbe való integrálása javíthatja a megbízhatóságot és a teljesítményt.

4. Integrálja az öt pillért a tervezési döntésekbe. A Well-Architected-keretrendszer használatával a megbízhatóság, a biztonság, a teljesítményhatékonyság, a költségoptimalizálás és a működési kiválóság terén hozhat döntéseket. Az öt pillérnek tájékoztatnia kell az összes tervezési döntést. Az adatbázis kiválasztásakor például fontolja meg a megbízhatóságot (redundancia, biztonsági mentés), a teljesítményt és a költségeket együtt, hogy megfelelő egyensúlyt teremtsen. Dokumentálja, hogy hol lehet kompromisszumot kialakítani a pillérek között, például hogy a nagyobb teljesítmény több költséggel járjon. Ezek a jegyzetek értékesek a jövőbeli irányítás és felülvizsgálatok szempontjából.

Tervezze meg az integrációkat a meglévő rendszerekkel

1. Leltározza az összes függő rendszert és szolgáltatást. Az új natív felhőmegoldások ritkán működnek elszigetelten, hacsak Ön nem egy korai fázisú startup. Gondolja át, hogyan illeszkedik az új számítási feladat vagy szolgáltatás a környezetbe. Az adatfolyamok leképezése és a szabványoknak való kompatibilitás biztosítása. Hozzon létre egy átfogó listát az összes olyan rendszerről, amellyel a számítási feladat kommunikál. Ez a lista belső API-kat, adatbázisokat, identitásszolgáltatókat (Microsoft Entra ID), monitorozási eszközöket, CI/CD-folyamatokat és VPN-en vagy ExpressRoute-on keresztül elért helyszíni rendszereket tartalmaz. Architektúradiagramok és függőségi térképek használatával vizualizálhatja ezeket a kapcsolatokat.

2. Az integrációs típusokat és protokollokat osztályozza. Az egyes integrációs pontok kategorizálása típus (hitelesítés, adatcsere, üzenetkezelés) és protokoll (REST, gRPC, ODBC, SAML, OAuth2) szerint. Ez a besorolás segít azonosítani a kompatibilitási követelményeket és a lehetséges szűk keresztmetszeteket.

3. Identitás- és hozzáférés-integráció ellenőrzése. Győződjön meg arról, hogy a megoldás integrálva van a szervezet identitásszolgáltatójával. Használhatja például a Microsoft Entra-azonosítót hitelesítéshez és engedélyezéshez új identitásrendszer bevezetése helyett. Erősítse meg az egyszeri bejelentkezés (SSO), a szerepköralapú hozzáférés-vezérlés (RBAC) és a feltételes hozzáférési szabályzatok támogatását.

4. A hálózati kapcsolat és a biztonság felmérése. Tekintse át, hogyan csatlakozik a számítási feladat más rendszerekhez. Ellenőrizze a tűzfalszabályokat, a DNS-feloldásokat és az útválasztási útvonalakat. Hibrid forgatókönyvek esetén ellenőrizze, hogy az ExpressRoute vagy a VPN-konfigurációk érvényben vannak-e és tesztelve vannak-e. Az Azure Network Watcher használatával figyelheti és elháríthatja a kapcsolatot.

5. Az adatfolyamok kompatibilitásának és megfelelőségének biztosítása. Adatáramlások leképezése a rendszerek között. Erősítse meg az adatformátumokat, sémákat és átalakítási követelményeket. Győződjön meg az adattárolási, titkosítási és adatmegőrzési szabályzatoknak való megfelelőségről.

6. Az integrációs pontok korai és folyamatos tesztelése. Integrációs tesztelés végrehajtása a korai fejlesztési szakaszokban. A nem elérhető rendszerekhez használjon maketteket vagy csonkokat. Automatizálhatja ezeket a teszteket a CI/CD-folyamatában olyan eszközökkel, mint az Azure DevOps vagy a GitHub Actions. Figyelheti a késést, az átviteli sebességet és a hibaarányokat. Például el szeretné kerülni, hogy az alkalmazás olyan API-t használjon, amely nem támogatja a szükséges terhelést, vagy egy hálózati tűzfal blokkolja a szolgáltatást.

7. Dokumentumintegrációs szerződések és SLA-k. Az egyes integrációs pontok várt viselkedésének, rendelkezésre állásának és teljesítményének meghatározása és dokumentálása. Adja meg az újrapróbálkozás logikáját, az időtúllépési beállításokat és a tartalék mechanizmusokat. Összhangban a függő rendszerek szolgáltatásiszint-szerződéseivel (SLA-kkal).

A megfelelő Azure-szolgáltatások és szolgáltatási szintek kiválasztása

1. A számítási feladatokra vonatkozó követelményeknek megfelelő szolgáltatások kiválasztásához használjon döntési útmutatókat. Az Azure több lehetőséget is kínál az alkalmazáskód futtatására, mindegyiknek előnyei és hátrányai vannak. Tekintse át a technológiai lehetőségek áttekintését a funkcionális és nem funkcionális követelményeknek megfelelő szolgáltatások azonosításához. Rangsorolja a szolgáltatásként nyújtott platform (PaaS) beállításait, mert ezek a szolgáltatások csökkentik a működési többletterhelést az infrastruktúra-kezelés, a javítás és a skálázás automatikus kezelésével.

2. Használati minták és teljesítménykövetelmények meghatározása a szolgáltatási szintek kiválasztásához. A szolgáltatási szint kiválasztása hatással van a költségekre és a képességekre is. Dokumentálja a várt tranzakciómennyiségeket, az egyidejű felhasználói terheléseket, a tárolási követelményeket és a teljesítménycélokat, például a válaszidőket és az átviteli sebességet. Ezekkel a metrikákkal kiválaszthat egy kezdeti szolgáltatási szintet (SKU), amely jelentős túlépítés nélkül megfelel az alapkövetelményeknek. Tervezze meg a szintek módosítását a tényleges használati minták alapján az üzembe helyezés után.

3. A szolgáltatáskompatibilitás ellenőrzése a kijelölt szolgáltatási szintek között. A kritikus funkciók, például a fejlett biztonsági képességek, a magas rendelkezésre állási lehetőségek vagy az integrációs API-k szolgáltatási szint szerint változnak. Hozzon létre egy funkciómátrixot, amely leképezi a szükséges képességeket az elérhető termékváltozatokhoz. Győződjön meg arról, hogy a kiválasztott szint támogatja az összes szükséges funkciót a költséges migrálások és az architektúra későbbi változásainak elkerülése érdekében. Referenciaszolgáltatás-specifikus dokumentáció a funkciók elérhetőségének és korlátainak megerősítéséhez.

Válassza ki, hogy hány régiót használjon

1. Értékelje ki a többrégiós telepítések kompromisszumait. Az egyrégiós architektúrák egyszerűbbek és olcsóbbak, de a regionális kimaradás miatt az alkalmazás leáll. A többrégiós üzemelő példányok magasabb rendelkezésre állást érhetnek el (az egyik régió meghibásodhat, a felhasználók pedig egy másikból vannak kiszolgálva), és a legközelebbi régióból származó felhasználók kiszolgálásával is javíthatják a teljesítményt. A kompromisszum az üzembe helyezés és az adatszinkronizálás összetettségének növelése. A lehetséges konzisztenciaproblémákkal, globális forgalomirányítással és magasabb költségekkel rendelkező régiók közötti adatreplikálást kell kezelnie. Hagyja, hogy a megbízhatósági követelmények irányítják ezt a döntést.

2. Megbízhatósági célok használata a regionális stratégia irányításához. Szolgáltatási szintű célkitűzések (SLO), helyreállítási pont célkitűzései (RPO) és helyreállítási idő célkitűzéseinek (RTO) meghatározása a regionális követelmények meghatározásához.

3. Ellenőrizze az adattárolási előírásoknak való megfelelést. Jogi és megfelelőségi csapatokkal együttműködve biztosíthatja, hogy a regionális választási lehetőségek megfeleljenek a szabályozási kötelezettségeknek.

Dokumentumarchitektúrák

1. Hozzon létre egy részletes architektúradiagramot és tervezési dokumentumot. A dokumentáció támogatja a megvalósítást, a felülvizsgálatot és a jövőbeli karbantartást. A kiválasztott Azure-szolgáltatások, termékváltozatok, adatfolyamok és felhasználói interakciók belefoglalása. Győződjön meg arról, hogy a diagram egyértelmű vizuálisan ábrázolja az architektúrát a megvalósítás és a felülvizsgálatok támogatásához.

2. Jegyezze fel a legfontosabb tervezési döntéseket és kompromisszumokat. Dokumentálja az architekturális döntések hátterét, beleértve a nem funkcionális követelményeket, például a megbízhatóságot, a biztonságot és a teljesítményt. A versengő prioritások egyensúlyba hozása érdekében tett kompromisszumok kiemelése.

A natív felhőbeli üzembehelyezési stratégia megtervezése

A felhőalapú megoldás éles környezetbe való telepítésekor az ad hoc megközelítés helyett kövesse a tervezett stratégiát. A szilárd üzembehelyezési terv minimálisra csökkenti a felhasználókra gyakorolt hatásokat, és lehetővé teszi a helyreállítást, ha valami hiba történik.

Fejlesztési és üzembehelyezési eljárások tervezése

A fejlesztési és üzembehelyezési eljárások biztosítják a környezetek konzisztens kézbesítését és működési felkészültségét. Ezek a gyakorlatok csökkentik az üzembe helyezés kockázatát, és javítják a csapatkoordinációt.

1. DevOps-eljárások létrehozása az üzembe helyezés automatizálásához. A DevOps-eljárások automatizálással, verziókövetéssel és CI/CD-folyamatokkal igazítják a fejlesztési és üzemeltetési csapatokat. A buildelési, tesztelési és üzembehelyezési munkafolyamatok automatizálásához használjon olyan eszközöket, mint az Azure DevOps vagy a GitHub Actions. Ez a megközelítés csökkenti a manuális hibákat, felgyorsítja a kiadási ciklusokat, és konzisztens üzembehelyezési folyamatokat biztosít a környezetekben.

2. Tervezze meg az üzembe helyezési tevékenységek támogatására való működési készültséget . A működési készültség magában foglalja az üzembe helyezési forgatókönyvek figyelési, riasztási és incidenskezelési eljárásait. Dokumentumterjesztési forgatókönyvek és automatizálási szkriptek, amelyek a visszaállítási eljárásokat, az állapotellenőrzéseket és a hibaelhárítási lépéseket fedik le. Ezeket az erőforrásokat egy központi helyen, például az Azure DevOps Wikiben vagy a GitHubon tárolhatja, hogy biztosítsa az akadálymentességet az üzembe helyezési tevékenységek során.

3. A megbízható üzembe helyezést támogató fejlesztési eljárások meghatározása. Kódolási szabványok, társértékelések és automatizált tesztelés használata a kódminőség és az üzembe helyezés készenlétének biztosítása érdekében. Ezeket a gyakorlatokat integrálhatja a CI/CD-folyamatba, hogy az üzembe helyezés előtt minőségi kapukat érvényesítse. Az üzembe helyezésre vonatkozó teszteket, például integrációs teszteket, füstteszteket és teljesítmény-ellenőrzést is belefoglalhat a rendszer éles üzemkészségének ellenőrzéséhez.

Üzembe helyezés megtervezése új számítási feladatokhoz

1. A hatás korlátozásához használjon progresszív expozíciót. Egy új (zöldmezős) alkalmazáshoz, amely nem rendelkezik meglévő felhasználókkal, érdemes szelíd indítást végeznie. Helyezze üzembe termelési környezetben, de kezdetben csak belső felhasználók vagy egy kísérleti csoport számára tegye elérhetővé. Ez a megközelítés egy kanári telepítés egy új számítási feladathoz. Ha valóban teljesen új és izolált, egy egyszeri teljes éles üzembe helyezés lehetséges, de a fokozatos bevezetést továbbra is javasoljuk, hogy a problémák szabályozott módon észlelhetőek legyenek. Ne engedje fel a rendszert az első napon minden felhasználó számára valós érvényesítés nélkül. További információ: WAF – Progresszív expozíciós modell bevezetése.

2. Dokumentálja az üzemeltetési eljárásokat és az eszkalációs útvonalakat. Hozzon létre egyértelmű dokumentációt a szolgáltatások újraindításához, a naplókhoz való hozzáféréshez, a gyakori problémák kezeléséhez és az incidensek eszkalálásához. A dokumentációt egy megosztott adattárban, például a SharePointban vagy a GitHubon tárolhatja a támogatási csapatok rendelkezésre állásának biztosítása érdekében.

Üzembe helyezés megtervezése új funkciókhoz

1. Tervezze meg az új funkcióintegrációt a változáskezelés használatával. Kövesse a szervezet változáskezelési folyamatát a gyártási változások szabályozása és dokumentálása érdekében. A visszaállítási eljárások definiálása, például az alkalmazásverziók visszaállítása vagy az adatbázis biztonsági másolatainak visszaállítása. Az üzleti célokhoz való igazodás érdekében az üzembe helyezés előtt biztonságossá teheti az érdekelt felek jóváhagyását. További információ: Változáskezelés a CAF-ben.

2. Használjon helyszíni frissítéseket kisebb vagy visszamenőlegesen kompatibilis módosításokhoz. A frissítéseket közvetlenül az éles környezetbe helyezheti üzembe működés közbeni frissítések vagy funkciójelzők használatával. Kezdje a felhasználók vagy példányok kis százalékával. Rendszermetrikák és naplók monitorozása a stabilitás ellenőrzéséhez a teljes bevezetés előtt.

3. Használjon párhuzamos (kék-zöld) telepítéseket nagyobb vagy magas kockázatú változásokhoz. Helyezze üzembe az új verziót egy külön környezetben. Az élő forgalom egy kis részét átirányíthatja az új verzióra a viselkedés ellenőrzéséhez. Ha sikeres, az összes forgalmat az új verzióra kell áthelyezni. Ha problémák merülnek fel, állítsa vissza a forgalmat az eredeti verzióra a folytonosság biztosítása érdekében.

4. Tervezze meg az új számítási feladatok operatív átadását. Azonosítsa a megoldás üzembe helyezés utáni működtetéséért és támogatásáért felelős csapatot. Határozza meg a támogatási modellt (24 órás ügyeleti vagy munkaidős támogatás), és győződjön meg arról, hogy minden érintett tisztában van a szerepköreivel.

5. Tulajdonosi és támogatási feladatok meghatározása. Győződjön meg arról, hogy az operatív csapat készen áll az új funkció támogatására. Frissítse a dokumentációt és az eszkalációs útvonalakat, hogy tükrözze az új felelősségeket, és biztosítsa a gyors incidensmegoldást.

Visszaállítási terv definiálása natív felhőbeli megoldásokhoz

A visszaállítási terv lehetővé teszi, hogy a csapatok gyorsan megfordítják a módosításokat, ha egy üzembe helyezés meghiúsul vagy kockázatot jelent. A jól definiált terv minimálisra csökkenti az állásidőt, korlátozza az üzleti hatásokat, és fenntartja a rendszer megbízhatóságát. A migrálás vagy üzembe helyezés megkezdése előtt mindig hozzon létre visszaállítási feltételeket és eljárásokat.

1. Sikertelen üzembe helyezés definiálása. Együttműködhet az üzleti érdekelt felekkel, a számítási feladatok tulajdonosaival és az üzemeltetési csapatokkal, hogy eldöntse, mi számít sikertelen üzembe helyezésnek. Ilyenek például a sikertelen állapotellenőrzések, a gyenge teljesítmény, a biztonsági problémák vagy a sikertelen sikermetrikák. Ez a definíció biztosítja, hogy a visszaállítási döntések összhangban legyenek a szervezet kockázattűrésével. Adjon meg olyan konkrét feltételeket, amelyek visszaállítást váltanak ki az üzembehelyezési tervben, például a processzorhasználati korlátokat, a válaszidő küszöbértékeit vagy a hibaarányokat. Ez az értékelés egyértelművé és konzisztenssé teszi a visszaállítási döntéseket az incidensek során.

2. A visszaállítási lépések automatizálása CI/CD-folyamatokban. A visszaállítási feladatok automatizálásához használjon olyan eszközöket, mint az Azure Pipelines vagy a GitHub Actions . Például állítsa be a folyamatokat egy korábbi verzió újbóli üzembe helyezésére, ha az állapot-ellenőrzések sikertelenek.

3. Munkaterhelés-specifikus visszaállítási utasítások létrehozása. A számítási feladat típusának, környezetének és üzembe helyezési módszerének megfelelő visszaállítási lépéseket írhat. Például az IaC telepítésekhez újra kell alkalmazni a korábban használt sablonokat. Az alkalmazás-visszaállítások egy korábbi tárolórendszerkép újbóli üzembe helyezését foglalják magukban. A visszaállítási csomaghoz csatolhat visszaállítási szkripteket, konfigurációs pillanatképeket és IaC-sablonokat. Ezek az eszközök felgyorsítják a folyamatot, és csökkentik a manuális lépések szükségességét.

4. Visszaállítási eljárások tesztelése. Üzembehelyezési hibák szimulálása átmeneti környezetben a visszaállítás működésének megerősítéséhez. Hiányosságok keresése és javítása az automatizálásban, az engedélyekben és a függőségekben. Ellenőrizze, hogy a visszaállítási eljárás stabil, ismert állapotba állítja-e vissza a rendszert.

5. A visszaállítási stratégiák javítása. Minden üzembe helyezés vagy visszaállítás után tekintse át, hogy mi működött és mi nem. Frissítse a visszaállítási szabályokat, a lépéseket és a szkripteket a tanultak alapján. A tervezési változások vagy az új eszközök figyelembe vétele. Tartsa naprakészen az útmutatókat, így a visszaállítási tervek naprakészek és hasznosak maradnak.

Következő lépés

Az új megoldás létrehozása