Proces migrace modelu

Tento článek popisuje šestifázový proces migrace úlohy využívající model LLM z jednoho základního modelu na jiný: co je třeba zvážit v jednotlivých fázích, které funkce Microsoft Foundry lze použít a jak se práce liší pro různé typy týmů.

Co znamená migrace modelu

Každý model, který spouštíte v produkčním prostředí, má datum vyřazení. Pokud je model, na který závisíte, nahrazen nebo když novější model bude sloužit vaší úloze lépe, provedete migraci. Výměna modelu není změna na jednom řádku: jiný model může nenápadně změnit tón, formátování, strukturu JSON, latenci, náklady nebo chování při volání nástrojů a narušit navazující kód, který závisí na původním chování.

Úspěšná migrace zachovává chování aplikace nebo ji vylepšuje měřitelnými způsoby. Úspěch vyžaduje opakovatelný proces pro detekci posunu, bezpečné přizpůsobení a prokázání kvality před širokým zaváděním.

Kdy migrovat

Migrace obvykle začíná jedním ze čtyř důvodů:

  • Model se vyřazuje z provozu. Ve Foundry má každý model v obecné dostupnosti stanovené datum vyřazení a starší produktové řady jsou postupně nahrazovány. Informace o zásadách vyřazení a datech najdete v části Životní cyklus Foundry Models a zásady podpory a plán vyřazení modelu.
  • Lepší model je k dispozici. Novější model nabízí vyšší kvalitu, nižší náklady, lepší latenci nebo schopnost (například strukturované výstupy nebo vylepšené volání nástrojů), které vaše úlohy potřebují.
  • Problém s náklady nebo latencí vynutí změnu. Latence aktuálního modelu nebo náklady na jednotky už nevyhovují vašim potřebám.
  • Mezera schopností blokuje produkt. Aktuální model teď nemůže udělat něco, co váš produkt vyžaduje.

Co se stane k datu vyřazení

To, co Azure dělá při vyřazení modelu, závisí na tom, jakým způsobem kapacitu nakupujete, a Foundry pro každý způsob používá odlišnou terminologii:

  • Nasazení Standard, Global Standard a Data Zone Standard (průběžné účtování) se automaticky aktualizují postupně podle harmonogramu pro jednotlivé oblasti. Načasování řídíte nastavením versionUpgradeOption na jednu z následujících hodnot: OnceNewDefaultVersionAvailable, OnceCurrentVersionExpired nebo NoAutoUpgrade (což znamená, že nasazení po vyřazení přestane fungovat). Zpracování priority se řídí stejnou cestou.
  • Zřízená nasazení (PTU)se neupgradují automaticky. Migrujete je sami, ať už in-place (provoz se převede během 20 až 30 minut bez výpadku) nebo side-by-side (nasadíte nové prostředí, otestujete ho, převedete na něj provoz a odstraníte staré).
  • Nasazení služby Batch se řídí souběžnou cestou: nasaďte nový model, znovu odešlete úlohy, vyřadíte staré nasazení.

Ať už se uplatní kterákoli možnost, výzva pro vývojáře je stejná: k určitému datu se váš provoz začne směrovat na jiný model. Koncový bod, který stále reaguje, neznamená, že se vaše aplikace stále chová správně, takže jak automaticky upgradované, tak ručně migrované úlohy získají výhody posouzení a ověření tohoto článku.

Migrace před datem vyřazení

Automatický upgrade je pouze pojistka pro nasazení s průběžnými platbami, nikoli migrační plán. Zřízená nasazení nemají žádnou bezpečnostní síť. V obou směrech se nejedná o náhradu plánu migrace. Dva závazky týkající se zásad vám dávají prostor k migraci podle vlastního harmonogramu místo toho, abyste čekali na termín:

  • Náhradní model bude k dispozici přibližně 90 dní před vyřazením ze služby Global Standard a přibližně 30 dní před vyřazením v zřízených oblastech, kde se předchůdce vyřazuje. V tomto okně můžete nový model vyhodnotit a migrovat ručně.
  • Data vyřazení se nedají prodloužit. Neexistuje žádný proces pro udělení výjimky, takže se na vás stále vztahuje i datum, se kterým jste nepočítali.

K zahájení oznámení o vyřazení nepotřebujete. Pokud je novější model levnější, rychlejší nebo schopnější, spusťte ho teď procesem. Migrace záměrně dělá z data vyřazení pouhou formalitu. Vzhledem k tomu, že se migrace opakují, je vhodné proces opakovat.

Kdo by měl použít proces migrace

Proces migrace nejlépe vyhovuje, když váš tým sestaví funkci s technologií LLM ve větším produktu nebo platformě, migruje přibližně čtvrtletně a má jasného vlastníka (například centrálního týmu platformy nebo aplikačního týmu), který spouští každou migraci záměrně.

Tento proces také vyhovuje týmům nativním pro AI, kde je model produktem. Fáze jsou stejné, ale běží rychleji a často paralelně, nikoli v přísné sekvenci.

Tento proces předpokládá, že přecházíte mezi základními modely, tedy modely, které nasazujete v podobě, v jaké jsou publikovány v katalogu modelů, bez úprav vah modelu. Vyladěné úlohy jsou mimo rozsah. Nemůžou se automaticky upgradovat, protože mají vlastní trénovací a nasazovací hodiny. Přizpůsobení jemně vyladěných úloh znamená destilaci nebo opětovné trénování, nikoli změny výzvy a schématu. Pokud používáte doladěná nasazení, naplánujte včas jejich opětovné doladění na náhradním základním modelu.

Fáze migrace

Migrace prochází šesti fázemi. Každá fáze vytvoří výstup, který bude další fáze používat. Fáze migrace:

Zjišťování → posouzení → přizpůsobení → ověření → zavedení → vyřazení

Kruhový diagram procesu migrace šestifázového modelu zobrazující zjišťování, posouzení, přizpůsobení, ověření, zavedení a vyřazení uspořádané po směru hodinových ručiček

Následující tabulka popisuje jednotlivé fáze a funkce a nástroje Foundry, které ji podporují. Funkce jsou k dispozici v Microsoft Foundry i v Azure OpenAI, pokud není označeno pouze Foundry, což znamená, že Azure OpenAI nemá žádný ekvivalent.

Oddíly pro jednotlivé fáze dále v tomto článku vysvětlují, proč každá fáze existuje, jak vypadá úspěšný výsledek, co je třeba zvážit, kdy použít jednotlivé funkce a kde se fáze běžně přeruší.

Phase Description Funkce a nástroje
Objevte Zjistěte, jestli změna modelu přichází nebo je potřeba, a rozhodněte se, jestli se má jednat.
Ohodnotit Zvolte cílový model a ověřte, že je provozně dostupný.
Přizpůsobit Přehrajte aktuální pracovní zátěž na novém modelu, diagnostikujte změny chování a přepracujte prompty, parametry, definice nástrojů, výstupní schémata a kód, který je volá.
Ověření Vyhodnoťte upravenou pracovní zátěž podle hodnoticího rámce kvality, abyste mohli rozhodnout, zda je její nasazení bezpečné.
Zavedení Povýšení do produkce prostřednictvím fázované expozice, sledování živého chování a potvrzení nebo vrácení zpět
Vyřazení Vyřaďte původní nasazení, uvolněte kapacitu, archivujte vyhodnocení a aktualizujte navazující dokumentaci.

Před migrací: Příprava testovací datové sady

Tento přípravný krok sestaví sadu reprezentativních vstupů, očekávaných výstupů a odsouhlasených kritérií úspěchu před zahájením práce na migraci. Tato sada představuje nezbytnou podmínku pro střední část procesu: ve fázi Adapt nemůžete bez vstupů přehrávat a ve fázi Validate nemůžete provádět hodnocení bez referenčních dat a kritérií.

Co vzít v úvahu

  • Před výběrem cíle vytvořte datovou sadu. Datová sada popisuje vaši úlohu, nikoli kandidátový model, takže ji můžete sestavit paralelně s funkcí Discover.
  • Shromážděte vstupy ze skutečných nebo syntetických zdrojů. Použijte zachycený produkční provoz nebo kurátorované příklady domén jako CSV nebo JSONL. Pokud ještě nemáte reprezentativní data, vygenerujte pomocí simulátoru syntetické a nežádoucí vstupy.
  • Zaveďte sběr telemetrie dříve, než ji budete potřebovat. Zachytávání produkčního obsahu je výslovné a nikdy retroaktivní, takže nemůžete vyhodnotit provoz, který jste nezaznamenali. Začněte protokolovat výzvy, odpovědi, latenci a počty tokenů.
  • Zmrazit datovou sadu. Zachovejte vstupy, základní pravdy a kritéria úspěchu pro celou migraci. Pokud se některý z nich změní, už nemůžete porovnat zdrojové a cílové výsledky.

Potřebujete také inventář nasazení modelů, která vaše úloha využívá, včetně typů těchto nasazení (Standard, Provisioned nebo Batch). Pro každý zdrojový model si poznamenejte datum vyřazení a navrhované nahrazení z plánu vyřazení modelu.

Fáze 1: Zjišťování

Účelem fáze Discover je rozpoznat, že se chystá změna modelu nebo že má taková změna smysl, a rozhodnout, zda jednat. Výstupem je rozhodnutí, zda pokračovat, či nikoli, přičemž setrvání u stávajícího modelu je platnou volbou. Úspěšný výsledek je včasný strukturovaný signál, který vám poskytne datum vyřazení, náhradní model a časové období migrace nebo záměrné rozhodnutí o udržení aktuálního modelu.

Co vzít v úvahu

  • Jaké je datum vyřazení a kolik runway vlastně máte? Považujte datum ukončení podpory po odečtení doby potřebné na ověření a nasazení za skutečný termín.
  • Existuje nějaká konkrétně navržená náhrada, nebo musíte kandidáty do užšího výběru vybrat sami?
  • Obnáší tato změna požadavky na dodržování předpisů nebo regionální omezení (u regulovaných úloh jsou dostupnost a certifikace často důležitější než kvalita)?

Kde se obvykle přeruší

Týmy se o ukončení podpory dozvídají roztříštěně – e-mailem, bannerem na portálu nebo interní zprávou – a varovný signál zaznamenají pozdě. Toto zpoždění zkracuje již těsné okno. Samostatní vývojáři a malé týmy se o ukončení často dozvědí spíše kvůli chybě v produkčním prostředí než z oznámení.

Co přinášíte

Plán vyřazení a rozhraní API modelů zpřístupňují data stabilního kontraktu. Vyspělé organizace přidávají dynamickou interní vrstvu oznámení, která je směruje na správné vlastníky.

Fáze 2: Posouzení

Účelem fáze posouzení je vybrat cílový model kandidáta a potvrdit, že ho můžete spustit: správnou oblast, správný typ nasazení, dostatečnou kvótu a dostupnost společně s aktuálním modelem, aby bylo možné vrácení zpět. Úspěšným výsledkem je jednoznačná volba mezi kandidátními modely, přičemž před zahájením ladění jsou potvrzeny region, SKU, kvóta a náklady.

Co vzít v úvahu

  • Kvalita a pozice kandidátů. Když je v testovacím prostředí několik modelů, rozhodněte se, který z nich vyhovuje kvalitě vaší úlohy, a ne jen to, které skóre je nejvyšší u veřejného srovnávacího testu.
  • Náklady na vlastní provoz. Cenová struktura se mění mezi generacemi modelů. Tokeny pro uvažování, vstupy z mezipaměti a režie strukturovaného výstupu mohou ovlivnit nákladovost na jednotku až dvojnásobně nebo více, proto měsíční náklady odhadujte podle historického provozu, nikoli jen podle ceníkové ceny.
  • Provozní dostupnost. Potvrďte region, SKU a kvótu a ověřte, že cíl může běžet souběžně se zdrojem, abyste zachovali možnost návratu.
  • Kontrola souladu s předpisy. U regulovaných nasazení mohou certifikace a regionální dostupnost zúžit okruh kandidátů ještě předtím, než začne hrát roli kvalita.

Kde se obvykle přeruší

Rozhodovací paralýza nastává, když má několik kandidátů nejasné vymezení. Týmy až uprostřed plánování zjistí, že zvolený model není v jejich regionu nebo pro jejich SKU k dispozici. Nebo projekce nákladů ukazuje, že nový model je pro skutečný provoz materiálně dražší.

Co přinášíte

Benchmarky se vyhodnocují na veřejných datových sadách, proto berte žebříček spíše jako filtr než jako cíl a užší výběr si ověřte na vlastní pracovní zátěži. Odhad nákladů je na tom stejně: měsíční přehled vychází z vašich vlastních záznamů o tokenech, což je poměrně jednoduché, jakmile budete mít k dispozici data o provozu.

Fáze 3: Přizpůsobení

Účelem fáze adaptace je zajistit, aby úloha dobře fungovala na novém modelu. Nejprve beze změny přehrajte stávající zátěž (aby bylo možné izolovat změny v chování řízené modelem), zjistěte, co se změnilo, a poté ji iterativně přepracovávejte. Úspěšný výsledek je souběžné porovnání chování vůči skutečnému nebo reprezentativnímu provozu, přičemž každá změna je sledována.

Adapt není jen úprava promptů.

Prompty jsou nejviditelnější vrstvou, ale migrace obvykle zasahuje i další čtyři oblasti:

  • Parametry.temperature, top_p, max_tokens a ovládací prvky pro úroveň úsilí při uvažování si mezi generacemi neodpovídají v poměru 1:1 a novější modelové řady nemusí některé parametry podporovat.
  • Definice nástrojů. Možná budete muset přepracovat názvy argumentů, popisy a požadovaná pole, která řídila starý model spolehlivě.
  • Výstupní schémata. Modely se liší v tom, jak se řídí strukturovaným výstupem. Možná budete muset do schématu doplnit explicitní omezení, kterému starý model vyhovoval jen volně, nebo možná konečně budete moci vynucovat dodržování schématu.
  • Volací kód. Rozdíly mezi rozhraním API a sadou SDK (dokončování chatu versus odpovědi, tvar streamování a nová nebo přejmenovaná pole požadavků) Možná budete muset aktualizovat i následné analýzy, které předpokládaly starý tvar odpovědi.

U agentních a pracovních zátěží často práce se schématy a voláním nástrojů převažuje nad prací s prompty.

Co vzít v úvahu

  • Před laděním přehrajte znovu beze změny. Spusťte aktuální konfiguraci v cílovém modelu bez jakýchkoli změn. Tento přístup vám pomůže oddělit chování, které model změnil od změn, které zavádíte , a poskytne vám směrný plán.
  • Sledujte, co se skutečně posune. Míra podrobnosti, hloubka uvažování, dodržování strukturovaného výstupu, podoba volání nástrojů, způsob odmítání a kolísání latence se běžně mění.
  • Přehrávejte skutečné trasovací záznamy, abyste zachytili regrese ve volání nástrojů. Nadbytečná pole, přejmenované argumenty a změněné pořadí se projeví pouze v reálných stopách, ne v jednokolových benchmarcích.
  • Sledujte změny. Přepracování promptu je snadné, ale stejně snadné je o něj přijít. Ponechte původní text a zaznamenejte, co se změnilo a proč.

Funkce systému Foundry

Tuto fázi podporují tři funkce Foundry:

  • Prompt Optimizer je tlačítko Optimalizovat přímo pod polem systémové instrukce v dětském hřišti Agent. Restrukturalizuje vaše pokyny pomocí osvědčených postupů pro přípravu výzev, zobrazuje důvody pro jednotlivé odstavce pro každou změnu a podporuje iterující smyčku: přidejte návrh, například "zachovat schéma JSON přesně" a znovu optimalizovat. K dispozici pouze v Foundry, nikoli Azure OpenAI.
  • Optimalizace agentů společně ladí pokyny, nástroje a výběr modelu pro úlohy agentů. K dispozici pouze v Foundry, nikoli Azure OpenAI.
  • Simulátor generuje syntetické a adverzariální vstupy, pokud nemáte k dispozici produkční data pro opětovné přehrání.

Kde se obvykle přeruší

U vložených úloh určených k produktům tato fáze obvykle trvá nejvíce času, protože smyčka diagnostiky je ruční: týmy znovu spouštějí výzvy, porovnávají rozdíly a zřídka zaznamenávají, co se změnily nebo proč.

Co přinášíte

  • Začněte s optimalizátory a pak ověřte. Místo přizpůsobení datové sady používají obecné osvědčené postupy v jediném průchodu a místo definic nástrojů nebo výstupních schémat vylaďují instrukční text. Považujte výstup za solidní návrh: nejprve zkopírujte svůj původní prompt (neexistuje historie verzí) a pak ho znovu porovnejte se svou zmrazenou datovou sadou, než této změně začnete důvěřovat.
  • Naplánujte si další praktickou práci pro přesuny mezi rodinami. Neexistuje žádný tok "optimalizace pro cílový model X", takže přechod mezi rodinami modelů zahrnuje záměrné výzvy a překlad schématu.
  • Zaznamenejte provoz, než ho budete potřebovat. Záznam je jen tak dobrý, jak kvalitní je jeho pořízení, a zachytávání obsahu je volitelné a nikdy není zpětné.

Fáze 4: Ověření

Účelem fáze Validate je rozhodnout, zda je přizpůsobená pracovní zátěž bezpečná k nasazení, a to jejím vyhodnocením podle rubriky kvality na pečlivě vybraném datovém souboru. Hodnoticí rámec může být založený na pravidlech, na referencích, na LLM v roli hodnotitele, na lidském hodnocení nebo na doménově specifickém rámci. Úspěšný výsledek přináší důvěryhodnou sadu hodnocení, která běží na zamrzlé datové sadě, kterou tým aplikace i všichni revidující věří.

Validate je jedna fáze, ale má dva kontaktní body, takže s ní nezacházejte jako s jedinou událostí na konci procesu:

  • Připravte se brzy. Zafixujte datovou sadu a kritéria úspěchu v části Před migrací předtím, než přejdete k části Adapt. V okamžiku, kdy se tyto změny změní, váš zdroj a cíl přestanou být srovnatelné.
  • Brána pozdě, ve dvou průchodech. Nejprve spusťte aktuální model na fixované sadě, abyste stanovili výchozí referenční hodnotu zdroje, kterou musíte překonat. Pak ohodnoťte cíl podle stejné sady a rozhodněte se.

Co vzít v úvahu

  • Ponechte datovou sadu a kritéria beze změn. Toto je jediná nejdůležitější disciplína v procesu pro zachování srovnatelných výsledků.
  • Změřte tři dimenze, které odpovídají kritériím pro schválení: kvalitu (hodnocení hodnotitele nebo recenzenta), latenci (čas do vygenerování prvního tokenu a propustnost, měřené pouze pro volání, které migrujete) a náklady (náklady na vstupní a výstupní tokeny na požadavek).
  • Přiřaďte rubriku k pracovní zátěži. Rubrika pro klinické shrnování, tvrzení o sekvenci volání nástrojů u agentů nebo již existující signály ze zpětné vazby uživatelů mohou být smysluplnější než obecné skóre.
  • Berete tento mezník jako signál pro týmy stavěné na AI. Místo jednorázového hodnocení typu prošel/neprošel probíhá vyhodnocování nepřetržitě, při každém commitu, a splývá s funkcí Roll out.

Funkce systému Foundry

Tuto fázi podporují dvě funkce Foundry:

  • Azure AI Evaluation SDK zahrnuje více než 30 integrovaných evaluátorů pokrývajících ukotvenost, relevanci, vyhledávání, soudržnost, plynulost, referenční metriky (F1, BLEU a ROUGE), bezpečnost, agenty a hodnotitele Azure OpenAI. Zahrnuje také vlastní LLM sloužící jako hodnotitel pro hodnoticí kritéria specifická pro daný úkol.
  • Vyhodnocení v portálu spouští stejné evaluátory pro cíle modelu, agenta, datové sady a trasování.

Spusťte identickou sadu vyhodnocovačů vůči zdrojové i cílové sadě na zmrazeném datasetu, aby byla čísla srovnatelná.

Dimension Co měřit Kde
Quality Hodnocení hodnotitele pro zdrojový a cílový text Azure AI Evaluation SDK, vyhodnocení portálu
Latency Doba do prvního tokenu a propustnost Srovnávací tabulka výsledků, provozní metriky
Cost Náklady na vstupní a výstupní tokeny na požadavek Výstupy vyhodnocení, ceny modelů

Kde se obvykle přeruší

Většina týmů nemá sadu pro vyhodnocování a ty, které ji mají, si ji často vytvořily samy. U regulovaných úloh se na vrcholu nachází povinná kontrola řízení lidských nebo kvality a stává se kritickým bodem. Tyto migrace se zastaví na adrese Validate, not Adapt.

Co přinášíte

Hodnoticí nástroje jsou připravené ke spuštění, ale sestavení testovací sady relevantní pro danou doménu z vlastního produkčního provozu vyžaduje u úloh modelu (bez agenta) praktickou ruční práci. Právě kvůli této potřebě se krok přípravy sám vyplatí.

Fáze 5: Zavedení

Účelem této fáze je propagovat ověřenou konfiguraci do produkčního prostředí ve fázích: napřed neprodukční, pak kanárské nebo vážené procento a pak širší expozice. Po celou dobu sledujte latenci, chyby a ideálně i kvalitu vůči výchozímu stavu před migrací. Pak potvrďte změny, nebo je vraťte. Úspěšným výsledkem je postupné nasazování prostřednictvím kanárkového nasazení, váženého nebo stínového provozu, signál kvality v produkčním provozu přesahující pouhou latenci a chybovost a zachovaná možnost návratu zpět.

Co vzít v úvahu

  • Zjistěte, jaký způsob nasazení používáte. Váš typ nasazení určuje mechanismus: Nasazení řady Standard můžou automaticky upgradovat podle plánu, který řídíte. Předem zřízená, dávková a doladěná nasazení se migrují ručně. Následující tabulka ukazuje mechaniku podle typu.
  • Zachovejte chodbu pro vrácení zpět. Ponechte staré nasazení dostupné, dokud si nejste jistí. Rozhodnutí o vrácení zpět vynucená termínem vyřazení místo důkazů jsou upozorněním, které jste zahájili příliš pozdě.
  • Pokud nemůžete, použijte režim stínu nebo zrcadlení. Regulované datové toky (PHI, finanční transakce) často neumožňují vystavit nový model reálnému zákaznickému provozu. Ekvivalent spouští nový model na produkčních vstupech offline a porovnává výstupy se starým modelem, aniž by to mělo vliv na uživatele.
  • Sledujte regrese, které offline vyhodnocení neodhalilo. Latence reálných uživatelů a chování v okrajových případech se mohou projevit pouze při produkční zátěži.

Mechanismy migrace podle typu nasazení

Typ nasazení Přístup k migraci Quota
Standardní, Globální standard, Standard datové zóny Automatický upgrade podle průběžného plánu. Řízení časování pomocí versionUpgradeOption (OnceNewDefaultVersionAvailable, OnceCurrentVersionExpirednebo NoAutoUpgrade). Zpracování priority se řídí stejnou cestou. Automaticky se přenese
Poskytnuto Ruční: na místě (provoz se převádí během 20–30 minut) nebo souběžně (nové nasazení, přesměrování provozu, odstranění starého). Nejprve se ujistěte, že je kvóta cílového modelu k dispozici.
Batch Souběžně: nasaďte nový model, znovu odešlete úlohy a potom vyřaďte staré nasazení. Zajištění kvóty cílového modelu
Jemné doladění (mimo rozsah tohoto článku) Neprovádí se automatický upgrade; trénování a nasazení mají oddělené lhůty vyřazení. Přelaďte model nebo proveďte destilaci do nového základního modelu. Zajištění kvóty cílového modelu

Po přesunu provozu nastavte průběžné vyhodnocování, aby na řídicím panelu Foundry Observability vyhodnocovalo vzorek produkčního provozu, bylo propojené s trasami pro analýzu hlavní příčiny a při poklesu kvality odesílalo výstrahy Azure Monitor.

Kde se obvykle přeruší

Regrese kvality, které offline vyhodnocení nezachytilo, se projeví při produkční zátěži. Rozhodnutí o vrácení zpět se často vynucují termínem vyřazení, nikoli důkazem, což je znamení, že migrace začala příliš pozdě.

Co přinášíte

Směrování podle vah mezi dvěma nasazeními se implementuje na úrovni vaší vlastní brány nebo aplikační vrstvy a okno pro rollback je záměrná volba, jak po určitou dobu ponechat staré nasazení připravené (týmy vestavěných systémů obvykle chtějí zhruba 30 dní). Obojí stačí navrhnout jednou a používat při každé migraci.

Fáze 6: Ukončení

Účelem fáze vyřazení je odstavit staré nasazení, uvolnit kapacitu, archivovat artefakty vyhodnocení a promítnout tuto změnu do navazující zákaznicky orientované dokumentace, marketingových stránek, provozních příruček podpory a auditních záznamů, pokud je vyžadováno jejich uchovávání. Nakonec je staré nasazení pryč, počet nasazení vykazuje klesající trend a získané zkušenosti se přenášejí do dalšího cyklu.

Co vzít v úvahu

  • K vyřazování z provozu přistupujte jako k součásti řízení, ne jen jako k následnému úklidu. U regulovaných úloh můžou povinnosti uchovávání vyžadovat uchovávání artefaktů po dobu let.
  • Ověřte, že zdroj je skutečně pryč. Ověřte, že je stará verze vyřazená, a pak odstraňte nasazení, aby se zastavila spotřeba kapacity.
  • Přenášejte získané poznatky dál. Přeložte čerstvé výrobní stopy zpět do zlaté datové sady, aby další migrace byla levnější.

Kde se obvykle přeruší

Týmy vynechávají vyřazení, což vede k akumulaci zombie nasazení. Týmy, které aktivně neodstavují stará nasazení, mají v provozu výrazně více nasazení než srovnatelné týmy a většinu z tohoto počtu tvoří strukturální pozůstatky po předchozích migracích. Často opomíjeným dílčím krokem je komunikace: marketingové materiály a produktová dokumentace po výměně stále odkazují na starý model.

Co přinášíte

Panel observability ukazuje, že počet nasazení má klesající trend, ale rozhodnutí, která nasazení jsou stále kritická, je na úsudku vašeho týmu. Udělejte z vyřazení výslovně sledovaný úkol, a ne jen předmět naděje.

Migrace je zřídka binární.

Skutečné migrace jsou často rozdělené mezi dva stavy: část zátěže běží na novém modelu, zatímco větev citlivá na latenci nebo s vyšším rizikem zůstává na starém modelu, někdy i celé týdny. Naplánujte částečné zavedení a částečné vrácení zpět místo jediného přechodu ze starého modelu na nový. Vyřazení často zaostává za zavedením o týdny nebo měsíce a právě tato stará nasazení, která stále přetrvávají, se projevují jako nekontrolované rozrůstání.

Související obsah

  • Poslední aktualizace v