Pokyny pro aktualizaci víceklientské řešení

Jednou z výhod cloudových technologií je nepřetržité zlepšování a vývoj. Jako poskytovatel služeb musíte použít aktualizace vašeho řešení: možná budete muset provést změny v infrastruktuře Azure, kódu nebo aplikacích, schématech databáze nebo libovolné jiné součásti. Je důležité naplánovat způsob, jakým budete aktualizovat vaše prostředí. Ve víceklientském řešení je obzvláště důležité, abyste měli jasné informace o vašich zásadách aktualizace, protože někteří klienti můžou být zdráhají, aby povolili změny v jejich prostředích, nebo můžou mít požadavky, které omezují dobu, kdy můžete službu aktualizovat. Potřebujete identifikovat požadavky vašich tenantů, vysvětlit své požadavky na provoz vaší služby, najít zůstatek, který funguje pro všechny, a pak to jasně.

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

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

• Mají vaši zákazníci své očekávání nebo požadavky na to, kdy je možné je aktualizovat? Ty můžou být formálně sdělené na základě smluv nebo smluv o úrovni služeb nebo můžou být neformální.
• Očekávají vaši zákazníci časová období údržby definovaná v rámci služby nebo i bez sebe? Můžou potřebovat komunikovat se svými zákazníky o všech potenciálních výpadkech.
• Mají vaši zákazníci nějaké právní předpisy, které vyžadují dodatečné schválení před tím, než se dají aktualizace použít? Pokud například zadáte řešení stavu, které zahrnuje komponenty IoT, může být nutné před použitím aktualizace získat schválení USA pro správu potravin a drog (FDA).
• Je některý z vašich zákazníků obzvláště citlivý nebo odolný pro použití aktualizací? Zkuste pochopit, proč. Pokud například spustíte fyzické úložiště nebo maloobchodní web, můžou se jim vyhýbat aktualizace kolem Černého pátku, protože rizika jsou vyšší než potenciální výhody.
• Co znamená váš záznam o úspěšném dokončení aktualizací bez dopadu na vaše zákazníky? měli byste dodržovat praktické postupy DevOps, testování, nasazení a monitorování, abyste snížili pravděpodobnost výpadků a zajistili rychlou identifikaci všech problémů, které aktualizace zavádí. Pokud vaši zákazníci věděli, že máte schopné aktualizovat svoje prostředí hladce, je méně pravděpodobný objekt.
• Budou zákazníci chtít vrátit aktualizace zpátky, pokud dojde k zásadní změně?

Vaše požadavky

Také je potřeba vzít v úvahu následující otázky z vlastní perspektivy:

• Je vhodné, aby vaši zákazníci měli kontrolu nad tím, kdy se aktualizace používají? Pokud vytváříte řešení používané velkými podnikovými zákazníky, odpověď může být Ano. Pokud ale sestavíte řešení zaměřené na uživatele, nemůžete mu poskytnout žádnou kontrolu nad tím, jak provedete upgrade nebo provoz svého řešení.
• Kolik verzí řešení můžete v jednom okamžiku rozumně udržovat? Mějte na paměti, že pokud zjistíte chybu a potřebujete ji hotfix, bude pravděpodobně nutné použít opravu hotfix pro všechny používané verze.
• Jaké jsou důsledky, jak zákazníkům umožnit příliš daleko od aktuální verze? Pokud budete pravidelně vydávat nové funkce, staré verze budou zastaralé. V závislosti na strategii upgradu a typech změn možná budete muset pro každou verzi vašeho řešení udržovat samostatné infrastruktury. To znamená, že při zachování podpory pro starší verze můžou existovat i provozní i finanční náklady.
• Je možné, že vaše strategie nasazení podporuje vrácení zpět s předchozími verzemi? Je to něco, co chcete povolit?

Najít zůstatek

Pokud ponecháte tempo vaší služby zcela na uvážení vašich tenantů, může se stát, že se neaktualizuje. Je důležité, abyste sami mohli aktualizovat vaše řešení a přitom zvážit případné rozumné obavy nebo omezení, které vaši zákazníci měli mít. Například pokud je zákazník obzvláště citlivý na aktualizace v pátek (protože to je nejvytíženější den v týdnu), můžete jednoduše odložit aktualizace na pondělí, aniž by to mělo dopad na vaše řešení?

Jedním z přístupů, které mohou dobře fungovat, je aktualizace aktualizací na základě tenanta pomocí jednoho z níže uvedených postupů. Sdělte zákazníkovi oznámení o plánovaných aktualizacích. Umožněte zákazníkům, aby se dočasně odhlásili, ale ne trvale; Dejte přiměřený limit na to, kdy budete muset aktualizaci použít.

Zvažte také možnost nasazovat opravy zabezpečení nebo jiné kritické opravy hotfix s minimálním nebo nedůležitým oznámením.

Další možností je, aby klienti mohli iniciovat vlastní aktualizace, a to v době jejich výběru. Znovu byste měli zadat konečný termín, v jakém okamžiku použijete aktualizaci na jejich jménem.

Bez ohledu na to, že máte proces pro monitorování stavu klientů, zejména před a po použití aktualizací. Kritické provozní incidenty (označované také jako incidenty živého webu) se často vyskytují po aktualizacích kódu nebo konfigurace. Proto je důležité aktivně monitorovat všechny problémy a reagovat na ně, aby se zachovala důvěra zákazníků. Další informace o monitorování najdete v tématu monitorování pro DevOps

Komunikace se zákazníky

Možnost Vymazat komunikaci je klíč k sestavení 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:

• Budete informovat zákazníky o nadcházejících aktualizacích?
• Pokud tak učiníte, budete implicitním požadavkem na udělení oprávnění poskytnutím procesu odhlášení?
• Máte naplánované okno údržby, které použijete při použití aktualizací.
• Co když máte nouzovou aktualizaci, třeba důležitou opravu zabezpečení? Můžete v těchto situacích vynutit aktualizace?
• Pokud se vám nedaří interaktivně informovat zákazníky o nadcházejících aktualizacích, můžete poskytnout zpětnou oznámení? Můžete například aktualizovat stránku na webu se seznamem aktualizací, které jste použili?

Komunikace s týmem zákaznické podpory

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

• Byly v poslední době použity aktualizace na infrastrukturu tenanta?
• Jaká byla povaha těchto aktualizací?
• Jaká byla předchozí verze?
• Jak často jsou aktualizace pro tohoto tenanta použité?

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

Strategie nasazení pro podporu aktualizací

Vezměte v úvahu, jak budete nasazovat aktualizace vaší infrastruktury. To je silně ovlivněné modelem architektury , který používáte. Tři běžné přístupy k nasazení aktualizací jsou razítka nasazení, příznaky funkcí a kroužky nasazení.

Ve všech případech se ujistěte, že máte dostatečné možnosti vytváření sestav a viditelnosti, abyste věděli, jakou verzi infrastruktury, softwaru nebo funkcí má každý tenant zapnutý, k čemu mají nárok migrace, a veškerá data související s časem, která souvisí s těmito stavy.

Razítka nasazení

Některé aplikace s více klienty jsou vhodné pro vzor razítek nasazení, ve kterém nasadíte 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ějí úlohy s více klienty.

Razítka představují skvělý způsob, jak zajistit izolaci mezi klienty. Poskytují také flexibilitu pro váš proces aktualizace, protože můžete aktualizace postupně aktualizovat napříč razítky, aniž by to ovlivnilo ostatní.

Příznaky funkcí

Příznaky funkcí umožňují přidávat do řešení funkce, ale zveřejňují se jenom pro podmnožinu vašich zákazníků nebo klientů. Můžete použít příznaky funkcí, pokud pravidelně nasazujete aktualizace, ale chcete se vyhnout zobrazování nových funkcí nebo pokud chcete zabránit použití změn v chování, dokud se zákazník výslovný v.

Do své aplikace můžete vložit podporu příznaku funkce tak, že si napíšete kód sami nebo pomocí služby, jako je Konfigurace aplikace Azure.

Nasazení na prstence

Okruhy nasazení umožňují postupně nasazovat aktualizace v rámci sady klientů nebo razítek nasazení. Každému prstenci můžete přiřadit podmnožinu tenantů. Kanárské prstenec zahrnuje vaše vlastní testovací klienty a zákazníky, kteří chtějí mít aktualizace ihned po jejich dostupnosti, a to s tím, že budou dostávat častěji aktualizace a že aktualizace nemusely být prostřednictvím komplexního procesu ověřování, jako v ostatních věcech. Předčasného přijímajícího okruhu obsahuje klienty, kteří mají poněkud větší riziko – Averse, ale pořád se připravují na pravidelné aktualizace. Většina vašich tenantů bude patřit do uživatelských okruhů, které přijímají méně častější a více vysoce testovaných aktualizací.

Verze rozhraní API

Pokud vaše služba zveřejňuje externí rozhraní API, může to mít vliv na to, jak se zákazníci nebo partneři budou integrovat s vaší platformou. Zejména musíte mít na vědomí zásadní změny vašich rozhraní API. Zvažte použití strategie pro správu verzí rozhraní API ke zmírnění rizika aktualizací vašeho rozhraní API.

Další kroky

• Zvažte, kdy mapovat požadavky na tenanty ve vícetenantových řešeních.
• Prohlédněte si kontrolní DevOps v Azure Well-Architected Frameworku.