Sdílet prostřednictvím

Důležité informace o aktualizaci víceklientských řešení

  • Článek

Jednou z výhod cloudových technologií je neustálé zlepšování a vývoj. Jako poskytovatel služeb musíte pro své řešení použít aktualizace: možná budete muset provést změny v infrastruktuře Azure, kódu nebo aplikacích, schématech databáze nebo jakékoli jiné součásti. Je důležité naplánovat, jak budete prostředí aktualizovat. U řešení s více tenanty je obzvláště důležité mít jasno o zásadách aktualizací, protože někteří tenanti se nemusí zdráhat povolit změny svých prostředí nebo mohou mít požadavky, které omezují podmínky, za kterých můžete aktualizovat jejich službu.

Při plánování strategie aktualizace řešení potřebujete:

  • Identifikujte požadavky vašich tenantů.
  • Ujasněte si vlastní požadavky na provoz vaší služby.
  • Najděte zůstatek, který můžete přijmout vy i vaši tenanti.
  • Jasně sdělte svoji strategii tenantům a dalším zúčastněným stranám.

V tomto článku poskytujeme pokyny pro technické pracovníky s rozhodovací pravomocí ohledně přístupů, které můžete zvážit při aktualizaci softwaru tenantů, a souvisejících kompromisů.

Požadavky vašich zákazníků

Zvažte následující otázky:

  • Očekávání a požadavky: Mají vaši zákazníci očekávání nebo požadavky ohledně toho, kdy je možné je aktualizovat? Tyto informace vám mohou být formálně sděleny ve smlouvách nebo smlouvách o úrovni služeb, nebo mohou být neformální.
  • Časové intervaly údržby: Očekávají vaši zákazníci časové období údržby definované službou nebo dokonce samodefinované časové intervaly údržby? O potenciálních výpadcích může být potřeba komunikovat se svými vlastními zákazníky.
  • Předpisy: Mají vaši zákazníci nějaké obavy z právních předpisů, které před aplikací aktualizací vyžadují další schválení? Pokud například poskytnete zdravotní řešení, které zahrnuje komponenty IoT, budete možná muset před instalací aktualizace získat schválení od USA Food and Drug Administration (FDA).
  • Citlivost: Jsou někteří z vašich zákazníků obzvláště citliví nebo odolní vůči instalaci aktualizací? Zkuste pochopit proč. Pokud například provozuje fyzický obchod nebo maloobchodní web, může se chtít vyhnout aktualizacím kolem Černého pátku, protože rizika jsou vyšší než potenciální výhody.
  • Historie: Jaké jsou vaše záznamy o úspěšném dokončení aktualizací, aniž by to mělo dopad na vaše zákazníky? Měli byste postupovat podle osvědčených postupů DevOps, testování, nasazení a monitorování, abyste snížili pravděpodobnost výpadků a zajistili, že rychle identifikujete případné problémy, které aktualizace zavádějí. Pokud vaši zákazníci vědí, že jejich prostředí můžete bez problémů aktualizovat, je méně pravděpodobné, že budou mít námitky.
  • Vrácení zpět: Budou zákazníci chtít vrátit zpět aktualizace, pokud dojde k zásadní změně?

Vaše požadavky

Musíte také zvážit následující otázky z vlastního pohledu:

  • Řízení, které jste ochotni poskytnout: Je vhodné, aby vaši zákazníci měli kontrolu nad tím, kdy se aktualizace použijí? Pokud vytváříte řešení používané velkými podnikovými zákazníky, odpověď může být ano. Pokud ale vytváříte řešení zaměřené na spotřebitele, je nepravděpodobné, že budete mít nad upgradem nebo provozem řešení žádnou kontrolu.
  • Verze: Kolik verzí řešení můžete přiměřeně udržovat najednou? Nezapomeňte, že pokud najdete chybu a potřebujete ji opravovat, možná budete muset použít opravu hotfix pro všechny používané verze.
  • Důsledky starých verzí: Jaký je dopad toho, že zákazníci příliš zaostávají za aktuální verzí? Pokud pravidelně vydáváte nové funkce, budou staré verze rychle zastaralé? V závislosti na vaší strategii upgradu a typech změn může být také potřeba udržovat samostatné infrastruktury pro každou verzi řešení. Proto můžou být provozní i finanční náklady, protože udržujete podporu pro starší verze.
  • Vrácení zpět: Může vaše strategie nasazení podporovat vrácení zpět na předchozí verze? Chcete tuto možnost povolit?

Poznámka

Zvažte, jestli potřebujete převést řešení do režimu offline kvůli aktualizacím nebo údržbě. Obecně platí, že okna výpadků jsou považována za zastaralý postup a moderní postupy a cloudové technologie DevOps umožňují vyhnout se výpadkům během aktualizací a údržby. Musíte ale navrhnout nasazení s nulovými výpadky, takže je důležité při plánování architektury řešení zvážit proces aktualizace.

I když během procesu aktualizace neplánujete výpadky, můžete přesto zvážit definování běžného časového období údržby. Okno vám může pomoct informovat zákazníky o tom, že ke změnám dochází v určitých časech.

Další informace o dosažení nasazení s nulovými výpadky najdete v tématu Odstranění výpadků prostřednictvím aktualizací služby s verzí.

Vyhledání zůstatku

Pokud necháte četnost aktualizací služeb zcela na uvážení vašich tenantů, můžou se rozhodnout, že se nikdy nebudou aktualizovat. Je důležité, abyste si umožnili aktualizovat své řešení a zároveň zohlednit veškeré rozumné obavy nebo omezení, které můžou mít vaši zákazníci. Pokud je například zákazník obzvláště citlivý na aktualizace v pátek, protože je to jeho nejrušnější den v týdnu, můžete stejně snadno odložit aktualizace na pondělí, aniž by to mělo vliv na vaše řešení?

Jedním z přístupů, které mohou dobře fungovat, je zavedení aktualizací v jednotlivých tenantech pomocí jednoho z níže popsaných přístupů. Dejte zákazníkovi oznámení o plánovaných aktualizacích. Umožnit zákazníkům dočasně vyjádřit výslovný nesouhlas, ale ne navěky; nastaví přiměřený limit, kdy budete vyžadovat, aby se aktualizace použila.

Zvažte také možnost nasadit opravy zabezpečení nebo jiné důležité opravy hotfix s minimálním nebo žádným předstihem.

Dalším přístupem může být umožnění klientům inicializovat vlastní aktualizace v době, kdy si zvolí. Znovu byste měli zadat konečný termín, kdy aktualizaci použijete jejich jménem.

Upozornění

Dávejte pozor, abyste klientům povolili inicializaci vlastních aktualizací. Implementace je složitá a k zajištění a údržbě bude vyžadovat značné úsilí o vývoj a testování.

Ať děláte cokoli, ujistěte se, že máte k dispozici proces monitorování stavu vašich tenantů, zejména před a po instalaci aktualizací. K kritickým provozním incidentům (označovaným také jako incidenty živé lokality) často dochází po aktualizaci kódu nebo konfigurace. Proto je důležité proaktivně monitorovat případné problémy a reagovat na ně, abyste zachovali důvěru zákazníků. Další informace o monitorování najdete v tématu Monitorování pro DevOps.

Komunikace se zákazníky

Jasná komunikace je klíčem k budování důvěry vašich zákazníků. Je důležité vysvětlit výhody pravidelných aktualizací, včetně nových funkcí, oprav chyb, řešení chyb zabezpečení a vylepšení výkonu. Jednou z výhod moderního řešení hostovaného v cloudu je průběžné doručování funkcí a aktualizací.

Zvažte následující otázky:

  • Upozorníte zákazníky na nadcházející aktualizace?
  • Pokud to uděláte, požádáte implicitně o povolení poskytnutím procesu odhlášení a jaká jsou omezení pro odhlášení?
  • Máte naplánované časové období údržby, které používáte při instalaci aktualizací?
  • Co když máte nouzovou aktualizaci, třeba kritickou opravu zabezpečení? Můžete v těchto situacích vynutit aktualizace?
  • Pokud nemůžete proaktivně informovat zákazníka o nadcházejících aktualizacích, můžete poskytnout retrospektivní oznámení? Můžete například aktualizovat stránku na svém webu seznamem aktualizací, které jste použili?
  • Kolik samostatných verzí systému budete udržovat v produkčním prostředí?

Komunikace s týmem zákaznické podpory

Je důležité, aby váš vlastní tým podpory měl úplný přehled o aktualizacích, které byly použity pro každého tenanta. Zástupci zákaznické podpory by měli být schopni snadno odpovědět na následující otázky:

  • Byly v nedávné době použity aktualizace infrastruktury tenanta?
  • Jaká byla povaha těchto aktualizací?
  • Jaká byla předchozí verze?
  • Jak často se aktualizace tohoto tenanta používají?

Pokud má některý z vašich zákazníků problém kvůli aktualizaci, musíte zajistit, aby tým zákaznické podpory získal informace potřebné k pochopení toho, co se změnilo.

Strategie nasazení pro podporu aktualizací

Zvažte, jak nasadíte aktualizace infrastruktury. To je silně ovlivněno modelem tenanta , který používáte. Tři běžné přístupy k nasazení aktualizací jsou razítka nasazení, příznaky funkcí a okruhy nasazení. Tyto přístupy můžete použít nezávisle nebo je můžete kombinovat, abyste splnili složitější požadavky.

Ve všech případech se ujistěte, že máte dostatečné vytváření sestav a viditelnost, abyste věděli, na jakou verzi infrastruktury, softwaru nebo funkce se každý tenant nachází, na co má nárok na migraci a jaká data související s těmito stavy souvisejí s časem.

Model razítka nasazení

Mnoho víceklientských aplikací je vhodných pro model Razítka nasazení, ve kterém nasazujete více kopií aplikace a dalších komponent. V závislosti na vašich požadavcích na izolaci můžete nasadit razítko pro každého tenanta nebo sdílená razítka, která spouští úlohy více tenantů.

Razítka představují skvělý způsob, jak zajistit izolaci mezi tenanty. Poskytují také flexibilitu pro proces aktualizace, protože aktualizace můžete postupně zavádět napříč kolky, aniž by to mělo vliv na ostatní.

Příznaky funkcí

Příznaky funkcí umožňují přidat funkce do vašeho řešení a zároveň tuto funkci vystavit jenom podmnožině vašich zákazníků nebo tenantů.

Zvažte použití příznaků funkcí, pokud se vás týká některé z těchto situací:

  • Pravidelně nasazujete aktualizace, ale nechcete zobrazovat nové funkce, dokud nebudou plně implementovány.
  • Chcete se vyhnout použití změn v chování, dokud se zákazník nerozhodne.

Podporu příznaků funkcí můžete vložit do aplikace tak, že kód napíšete sami nebo použijete službu, jako je Azure App Configuration.

Okruhy nasazení

Okruhy nasazení umožňují postupně zavádět aktualizace napříč sadou tenantů nebo razítek nasazení. Každému okruhu můžete přiřadit podmnožinu tenantů.

Můžete určit, kolik okruhů se má vytvořit a co každý z nich znamená pro vaše vlastní řešení. Organizace běžně používají následující okruhy:

  • Kanárské: Kanárské okruhy zahrnují vaše vlastní testovací tenanty a zákazníky, kteří chtějí mít aktualizace hned, jakmile budou k dispozici, s tím, že můžou dostávat častější aktualizace a že aktualizace nemusí projít tak komplexním procesem ověřování jako v jiných věcech.
  • Raný adoptér: Okruh pro rané uživatele obsahuje tenanty, kteří jsou trochu averzi k riziku, ale jsou stále připraveni dostávat pravidelné aktualizace.
  • Uživatelé: Většina vašich tenantů bude patřit do okruhu uživatelů , který dostává méně časté a více otestované aktualizace.

Verze rozhraní API

Pokud vaše služba zveřejňuje externí rozhraní API, zvažte, že všechny aktualizace, které použijete, můžou ovlivnit způsob, jakým se zákazníci nebo partneři integrují s vaší platformou. Zejména musíte mít na pozoru, že dojde k narušení změn ve vašich rozhraních API. Zvažte použití strategie správy verzí rozhraní API ke zmírnění rizika aktualizací rozhraní API.

Přispěvatelé

Tento článek spravuje Microsoft. Původně ji napsali následující přispěvatelé.

Hlavní autor:

  • John Downs | Hlavní inženýr zákazníka, FastTrack pro Azure

Další přispěvatelé:

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky