A felhő modernizálásának megtervezése

A megfelelő tervezés és irányítás kritikus fontosságú a modernizáció szempontjából. Ebben a szakaszban ön dönti el, hogy melyik modernizációs megközelítést és hogyan kell alkalmazni. A átgondolt tervezés csökkenti a költségvetés túlfuttatásainak, hatókörkésésnek vagy szolgáltatáskimaradásoknak az esélyét a végrehajtás során.

Modernizációs stratégia kiválasztása

A számítási feladatok modernizálása azt jelenti, hogy a frissítés jobban igazodik az aktuális üzleti célokhoz, a műszaki szabványokhoz és a felhő képességeihez. A három elsődleges stratégia (replatform, refactor és rearchitect) az összetettség és az érték folyamatosságán alapul. A legtöbb modernizációs törekvés ezen megközelítések kombinációját használja.

A kulcs az, hogy megfeleljen a stratégiának az egyes összetevők konkrét igényeinek, figyelembe véve a célokat, az ütemtervet és a rendelkezésre álló erőforrásokat. Kerülje a kísértést, hogy túl modernizálja. Bár az új technológiák izgalmasak, minden döntést üzleti értéknek kell megalapozni.

Modernizációs stratégia Definition Mikor érdemes használni? Pros Cons
Replatform Alkalmazások áthelyezése felhőplatformokra minimális kódmódosításokkal (IaaS-ről PaaS-ra). Alacsony munkamennyiségű fejlesztések minimális megszakítással. A jelenlegi kód működik, de az üzemeltetési teher nagy. Gyors megvalósítás. Csökkenti a karbantartási munkát. Jobb infrastruktúrával javítja a megbízhatóságot. Korlátozott képességbeli előnyök. Az alapalkalmazás változatlan marad.
Refactor A meglévő kód módosítása a struktúra, a teljesítmény és a felhőoptimalizálás javítása érdekében a funkciók fenntartása mellett. A technikai adósság problémákat okoz, vagy a kód nem felhőoptimalizált. Javítja a karbantarthatóságot, a teljesítményt és a biztonságot. Egyszerűbb jövőbeli fejlesztéseket tesz lehetővé. Jelentős fejlesztői erőfeszítést és tesztelést igényel. Nincsenek azonnali új funkciók a felhasználók számára.
Rearchitect Az alkalmazásarchitektúra újratervezése natív felhőbeli mintákkal (mikroszolgáltatások, kiszolgáló nélküli, eseményvezérelt). A jelenlegi architektúra korlátozza a növekedést vagy a felhőoptimalizálást. Alapvető méretezhetőségi problémák kezelése. Lehetővé teszi a fejlett felhőszolgáltatások használatát. A hosszú távú innováció alapja. A legösszetettebb és időigényes. Magas kezdeti költség és kockázat. Kiterjedt tesztelést és párhuzamos műveleteket igényel.

Modernizációk tervezése fázisokban

Egy teljes (vagy több) összetett számítási feladat modernizálása egy lépésben kockázatos. Az erőfeszítést logikai fázisokra bontsa. A fokozatosság lehetővé teszi a lépésenkénti érték biztosítását, a kockázat csökkentését a kezelhető részekben való megvalósítással, valamint a fázisok közötti irány módosítását a tanulságok alapján.

  1. Ossza fel a modernizációkat logikai fázisokra. Határozza meg, hogyan ossza fel a munkát. Nincs egyetlen "helyes út". Válassza ki az architektúrához és a csapatszerkezethez megfelelő lebontást. A cél az, hogy minden fázis elég kicsi legyen a végrehajtáshoz és a teszteléshez anélkül, hogy túlterhelt lenne az összetettség, de elég értelmes ahhoz, hogy értéket adjon. A fázisok lebontásának gyakori módjai:

    Osztási módszer Description Example
    Összetevő vagy réteg szerint Fázisok elkülönítése a számítási feladatok rétegei vagy a számítási feladatok határai alapján 1. fázis: Adatbázis-migrálás, 2. fázis: Alkalmazás újrabontása, 3. fázis: Felhasználói felület modernizálása
    Prioritás és összetettség szerint A munka rendszerezése az alacsony kockázatútól a nagy kockázatú változásokig 1. fázis: Nem kritikus szolgáltatások, 2. fázis: Alapvető üzleti logika, 3. fázis: Ügyféloldali funkciók
    Üzleti funkció szerint Az alkalmazás vagy a funkcionális határok körüli struktúrafázisok 1. fázis: Felhasználói felügyeleti számítási feladat, 2. fázis: Fizetésfeldolgozás, 3. fázis: Jelentéskészítési szolgáltatások

  2. Kezdje az alacsony kockázatú, nagy értékű változásokkal. Az 1. fázishoz válasszon valamit, amely elérhető, és mérhető előnyt biztosít, de problémák esetén nem veszélyezteti az üzletet. Például modernizáljon egy háttérszolgáltatást vagy belső eszközt az ügyféloldali webhely helyett. Cél az első fázis gyors (egy-két hónap) elvégzése a megvalósíthatóság bemutatásaként. A korai siker a csapat bizalmát és az érdekelt felek támogatását a következő fázisokhoz építi.

  3. A fennmaradó fázisok sorrendje érték és függőségek szerint. Az első fázis után tervezze meg a következő fázisok sorrendjét az üzleti érték és a műszaki függőségek alapján. Hozzon létre egy ütemtervet, amelyben minden fázis meghatározott hatókörrel rendelkezik, és biztosítja, hogy a kritikus fontosságú összetevők már modernizáltak vagy kompatibilisek legyen a támogató elemeikkel.

    • A törékeny területek kezelése. Ha egy számítási feladat jelenlegi állapota törékeny, előfordulhat, hogy egy előzetes "0. fázis" is szükséges ahhoz, hogy stabilizálja azt a helyén (sürgős javításokat alkalmazzon a régi környezetben), hogy biztonságosan modernizálható legyen az 1. fázisban.
    • Először kezelje az előfeltételeket: Ha a B munkaterhelés modernizálása az A munkaterhelés modernizálásán (vagy legalábbis stabilitásán) múlik, először végezze el az A munkaterhelést.
    • Vegye figyelembe az üzleti értéket és a kockázatot: Dönthet úgy, hogy egy nagy értékű, de kockázatosabb darabot hajt végre egy fázisban, majd egy alacsonyabb kockázatú darabot a következőben, hogy kiegyensúlyozza a csapat terhelését és az üzleti kockázatot.

  4. Az egyes fázisok sikerességi feltételeinek meghatározása. Az egyes fázisok esetében döntse el, hogy mikor fejeződik be és mikor lesz sikeres. A világos kilépési feltételek megakadályozzák a projektterjedelem-növekedést egy fázisban. A sikerességi feltételek a következők lehetnek:

    Sikerességi feltétel típusa Examples
    Technikai célok • A Service X az Azure App Service-en fut, és 20% több terhelést kezel
    • Az Y adatbázis a korábbi alapkonfigurációtól számított 10% belül nulla adatvesztéssel és teljesítménnyel migrál az Azure SQL-be
    Minőségi ellenőrzési kapuk • Nincs Sev-1 hiba nyitva
    • Minden automatizált teszt sikeres
    • A biztonsági vizsgálat nulla kritikus biztonsági rést mutat
    Időzítési és költségvetési korlátozások • Három hónapon belül és a költségvetés 5% belül fejezze be
    • Üzembe helyezés ütemezett karbantartási időszakokban

  5. Tervek adaptálása az eredmények alapján. A fázis befejezése után tekintse át az eredményeket és a tanultakat. Előfordulhat, hogy egyes feltételezések helytelenek voltak, vagy egyes feladatok a vártnál egyszerűbbek vagy nehezebbek voltak. Ennek megfelelően állítsa be a közelgő fázisok tervét, például a fázisok hozzáadását, kombinálását vagy újrakriritálását. A szakaszos megközelítés célja, hogy rugalmas legyen. Nem az a fontos, hogy mindent egyszerre csináljunk.

Modernizációs szabályozás megtervezése

A modernizáció gyakran jelentős változásokat vezet be a kritikus számítási feladatokban, ezért a kockázatok kezeléséhez erős irányításra van szükség. A modernizáció szabályozása magában foglalja a változáskezelési folyamatokat, a lefagyásokat és a hatókör szabályozását:

  • Hozzon létre egy formális módosítás-jóváhagyási munkafolyamatot. Strukturált jóváhagyási folyamat definiálása a modernizációval kapcsolatos összes módosításhoz. Integráljon a meglévő változástanácsadó testületekkel (CAB), vagy hozzon létre egy dedikált modernizációs felülvizsgálati testületet. Rendeljen hozzá jóváhagyási hatáskört a változáskategória alapján, és dokumentálja a teljes munkafolyamatot a projekttervben. További információ: Változás kezelése.

  • Szükség esetén zárolja a módosításokat. Közvetlenül a nagyobb üzembehelyezési események előtt és alatt állítsa le az egyéb módosításokat ezeken a munkaterheléseken. A változásbefagyasztás azt jelenti, hogy az elővezetésben és az üzembe helyezés során nem végeznek más, nem kapcsolódó módosításokat ezen számítási feladatokon. Stabilizálja a környezetet, így nem telepít instabil környezetbe. Tájékoztassa az összes érintett csapatot a fagyasztási időszakról.

  • Kerülje el a kiterjedés növekedését. A hatókör növekedése komoly kihívást jelent a modernizációk során. A jóváhagyott modernizációs hatókör javasolt módosításának megkövetelése egy értékelési és jóváhagyási lépés végighaladásához. A legtöbb kérést el kell halasztani, hacsak nem kritikus fontosságúak. Formálissá kell tenni a "nem, nem most" elvet, hogy egy folyamattal további munkát lehessen végezni. Tartson fenn egy hátralékot az olyan ötletekből, amelyek a jelenlegi korszerűsítés után egy jövőbeli innovációs projektbe is bekerülhetnek. Az érdekelt feleknek tudniuk kell, hogy az ötletük nem veszett el.

Az üzembehelyezési stratégia meghatározása

Fontos végrehajtási döntés a modernizált összetevők éles környezetben való üzembe helyezésének módja. Két fő stratégia létezik. Egy helyszíni üzembe helyezés során frissítenie kell a meglévő telepítőt (a meglévő környezetet közvetlenül frissítve). Párhuzamos üzembe helyezés során egy új rendszert telepít a meglévő mellé (új környezet létrehozásával, majd az átállással). Válassza ki azt a stratégiát, amely megfelel az egyes fázisok vagy számítási feladatok változási és kockázattűrési szintjének. A modernizáció minden fázisa gyakran más stratégiát használ. Választhat például helyben az 1. fázishoz (ha kisebb változásról van szó), és párhuzamosan a 2. fázishoz (ha ez jelentős adatbázis-átalakítást igényel).

  • Használjon helyszíni üzembe helyezést alacsony kockázatú, reverzibilis módosításokhoz. A helyszíni üzembe helyezés közvetlenül a jelenlegi éles környezetben vezet be módosításokat, például egy karbantartási időszak során. Ez a stratégia minimálisra csökkenti az infrastruktúra többletterhelését, de növeli az állásidő kockázatát. Csak akkor használja a helyszíni üzembe helyezést, ha a módosítások kicsik, elszigeteltek és könnyen visszafordíthatóak. Ilyenek például az olyan kisebb kódfrissítések vagy sémamódosítások, amelyek gyorsan visszaállíthatók a forrásvezérlők vagy biztonsági másolatok használatával.

  • Használjon párhuzamos üzembe helyezést összetett vagy nagy kockázatú változásokhoz. Ebben a modellben új környezetet állít be a modernizált számítási feladathoz, miközben a régi számítási feladat továbbra is fut. Az adatok szinkronban maradnak (replikációs vagy migrálási folyamatokon keresztül), így ha készen áll, átvághatja a régit az új környezetbe. Ezt a modellt olyan összetett vagy nagy kockázatú változásokhoz használhatja, ahol az állásidőnek minimálisnak kell lennie. Ha jelentős adatbázis-migrálást vagy új infrastruktúrát tartalmazó újratervezést végez, általában a párhuzamos üzembe helyezés a jobb választás. Ha a feladat kritikus fontosságú, és a leállási idő nem haladhatja meg a néhány percet, párhuzamos végrehajtásra van szükség replikációval és gyors átállással.

    Strategy Description Mikor érdemes használni? Pros Cons
    Helyszíni üzembe helyezés Módosítások közvetlen üzembe helyezése az aktuális éles környezetben Kis, visszafordítható változások elfogadható karbantartási időszakokkal Nincs ismétlődő infrastruktúra, gyorsabb üzembe helyezés Nagyobb a kockázat, állásidőt igényel, lassabb a visszaállítás.
    Párhuzamos üzembe helyezés Új környezet futtatása a meglévő számítási feladatok mellett az átmenet során Összetett változások, kritikus fontosságú számítási feladatok, amelyek minimális állásidőt igényelnek Biztonságosabb üzembe helyezés, közel nulla állásidő, azonnali tartalék Duplikált infrastruktúraköltségek, összetett adatszinkronizálás, leszerelési erőfeszítések

Modernizációs kockázatok mérséklésének megtervezése

Még a legjobb tervezés és tesztelés mellett sem minden változás megy tökéletesen. A modernizálás gyakran összetett módosításokat igényel, és mindig fennáll annak a kockázata, hogy az üzembe helyezés problémát okozhat, vagy valami váratlanul viselkedik a termelési környezetben. Egy jól felkészült csapat minden változáshoz vagy fázishoz alapos visszaállítási tervvel rendelkezik.

  1. Használjon progresszív üzembe helyezési technikákat. Ha a platform lehetővé teszi, hajtsa végre a kanári kiadásokat vagy végezze el a forgalom fokozatos átterelését az alkalmazás modernizált részeire. Helyezze üzembe például az új verziót a régi mellett, és kezdetben a felhasználók csak 5%-át irányítsa oda, miközben figyelemmel kíséri őket. Ez a megközelítés észlelheti a problémákat anélkül, hogy a felhasználók többségét érintené. Ha a metrikák jól néznek ki, növelje 50%, majd 100%. Ha valami elkezd meghibásodni, gyorsan térjen vissza a 0% újhoz (visszaállítás).

  2. Hozzon létre visszaállítási eljárásokat minden jelentős változáshoz. Minden jelentős változáshoz vagy fázishoz írjon egy lépésenkénti visszaállítási eljárást. Egyértelműen listázza a módosítás visszavonásához szükséges összes műveletet, hogy ki felelős az egyes lépésekért, és mennyi ideig tart. A visszaállítás után adja meg, hogy milyen ellenőrzések igazolják, hogy a dolgok visszatérnek a normális kerékvágásba.

  3. Ahol csak lehetséges, automatizálja a visszaállításokat. Az automatizált visszaállítási szkriptek vagy az infrastruktúra kódként való használata gyors és megbízható helyreállítást tehet. Az ismert állapotok ismételt üzembe helyezéséhez használjon kódként használható infrastruktúra-eszközöket (Terraform, ARM-sablonok és Bicep). A kék-zöld vagy a kanári telepítések alapvetően lehetővé teszik a "visszaváltást" az előző verzióra, ha szükséges. Tesztelje ezeket a mechanizmusokat az előkészítés során. A cél a manuális munka csökkentése (incidens során) egy szkriptelt műveletre. Írja meg a visszaállítási lépéseket az üzembe helyezési lépések mellett, így könnyen visszaállítható.

  4. Tartsák készenlétben a támogatást az üzembe helyezés alatt és után. Ha lehetséges, tervezze meg a telepítéseket alacsony forgalmú időszakokban (hétvégén vagy éjszaka), de gondoskodjon arról, hogy a megfelelő szakértők rendelkezésre álljanak. Kerülje a telepítések ütemezését, ha a kulcsfontosságú csapattagok nincsenek jelen. Az üzembe helyezést követően a fejlesztőkkel és a készenlétben álló üzemeltetési csapattal kiterjesztett támogatási (hypercare) időszakot tart fenn a problémák korai elhárítása érdekében. A jelentősebb élesítéseket követően egyes szervezetek 24-48 órás war-room stílusú monitorozást alkalmaznak.

Az érdekelt felek biztonságos jóváhagyása

Eddig a technikai tervezésre összpontosítottunk. Ugyanilyen fontos az érdekelt felek jóváhagyása, mind az üzleti, mind a műszaki vezetés részéről. A modernizáció gyakran jelentős befektetést igényel, ezért meggyőző esetet kell bemutatnia, és az érdekelt feleket folyamatosan figyelemmel kell követnie.

  • Testre szabhatja az értékajánlatot az egyes célközönségek számára. A különböző érdekelt feleket a különböző eredmények érdeklik. Az üzenetkezelés testreszabása:

    • A műszaki csapatok a működési hatékonyságot részesítik előnyben: kevesebb karbantartást, jobb üzemidőt és kevesebb eszkalációt.
    • Az üzleti vezetők az eredményekre összpontosítanak: gyorsabb piacra kerülés, jobb ügyfélélmény és költségmegtakarítás.

  • Strukturált terv dokumentálása mérföldkövekkel. Az érdekelt felek jobban érzik magukat, ha egyértelmű ütemtervet látnak. Ismertetheti a korábban elhatározott fázisokat, és hogy mit kell elérnie, egy durva idővonallal. Hangsúlyozzuk a korai győzelmeket, például: "6 héten belül célunk az X összetevő modernizálása és teljesítményének 20%-kal való javítása."

  • A modernizáció értékének számszerűsítése. Készítsen elő néhány előtte-utána metrikát és célzott fejlesztéseket. Példák a metrikákra és a jellemző fejlesztési tartományokra (az iparági teljesítménymutatók alapján):

    Category Példák metrikákra Tipikus értéktartomány
    Költségcsökkentés Infrastruktúra, karbantartás, licencelés 20-40% éves megtakarítás
    Hatékonyságnövekedés Üzembe helyezés gyakorisága, feloldási idő 50-80% javulás
    Kockázatcsökkentés Elkerült állásidő, biztonsági incidensek $100K-$1M+ költségkerülés
    Revenue Gyorsabb piacra lépés, ügyfélmegtartás 10-25% bevételgyorsítás

  • Projektkockázatok kezelése. A lehetséges kihívások azonosítása és a felkészültség konkrét kockázatcsökkentési stratégiákon keresztül történő bemutatása. A gyakori kockázatok közé tartozik az adatreplikáció, a teljesítménycsökkenés és az integrációs problémák. Olyan megoldások bemutatása, mint az automatizált visszaállítási eljárások, az átfogó tesztelési protokollok és a szakértői konzultáció elérhetősége. A transzparens kockázatvita növeli az érdekelt felek bizalmát a projektvezetésben és a tervezés alaposságában.

  • A rendszeres kommunikáció ütemének fenntartása. A megadott sikerességi feltételeknek megfelelő előrehaladás jelentése, a befejezett termékek kiemelése és a közelgő mérföldkövek közlése. Kérjen aktívan visszajelzést, és kezelje a problémákat, hogy fenntartsa a támogatást a modernizálási folyamat során.

Következő lépés

Felhőkorszerűsítés végrehajtása

  • Last updated on