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

Jednou z výhod cloudové technologie je průběžné vylepšování a vývoj. Jako poskytovatel služeb musíte v řešení použít aktualizace: možná budete muset provést změny kódu aplikace, infrastruktury Azure, schémat databáze nebo jakékoli jiné komponenty. Je důležité naplánovat, jak aktualizujete prostředí. Ve víceklientském řešení je obzvláště důležité mít přehled o zásadách aktualizací, protože někteří z vašich tenantů se můžou zdráhat povolit změny ve svých prostředích nebo můžou mít požadavky, které omezují podmínky, za kterých můžete aktualizovat svou službu.

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

• Identifikujte požadavky vašich tenantů.
• Objasně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 svou strategii svým tenantům a dalším zúčastněným stranám.

V tomto článku poskytujeme pokyny pro pracovníky s technickými rozhodovacími rozhodnutími o přístupech, které můžete zvážit při aktualizaci softwaru tenantů a kompromisů, které se týkají.

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

Zákazníci často mají explicitní nebo implicitní požadavky, které můžou ovlivnit způsob aktualizace systému. Zvažte následující aspekty, abyste vytvořili představu o všech aspektech obav, které by zákazníci mohli vyvolat:

• Očekávání a požadavky: Odkryjte všechna očekávání nebo požadavky, se kterými se zákazníci můžou seznámit s tím, kdy je možné jejich řešení aktualizovat. Ty vám můžou být formálně oznámeny ve smlouvách nebo smlouvách o úrovni služeb nebo můžou být neformální.
• Časové období údržby: Zjistěte, jestli vaši zákazníci očekávají definovaná služba nebo dokonce samodefinovaná časová období údržby. Po dokončení aktualizace možná budou muset komunikovat se svými uživateli o potenciálních výpadkech nebo budou muset otestovat důležité aspekty vaší služby.
• Předpisy: Vyjasněte si, jestli mají zákazníci nějaké regulační obavy, které před provedením aktualizací vyžadují další schválení. Pokud například poskytnete řešení pro zdraví, které obsahuje komponenty IoT, možná budete muset před instalací aktualizace získat schválení od USA Food and Drug Administration (FDA).
• Citlivost: Zjistěte, jestli jsou někteří vaši zákazníci obzvláště citliví nebo odolní vůči použití aktualizací. Pokud ano, zkuste pochopit proč. Pokud například provozuje fyzické úložiště nebo maloobchodní web, může se jim vyžadovat, aby se vyhnuli aktualizacím včerejšku Black Friday, protože rizika jsou vyšší než potenciální výhody.
• Historie: Zkontrolujte si vlastní záznam o úspěšném dokončení aktualizací, aniž by to mělo dopad na vaše zákazníky. Měli byste dodržovat dobré postupy devOps, testování, nasazení a monitorování, abyste snížili pravděpodobnost výpadků a zajistili, že rychle identifikujete všechny problémy, které aktualizace zavádějí. Pokud vaši zákazníci vědí, že jste schopni bezproblémově aktualizovat jejich prostředí, budou mít menší pravděpodobnost, že se budou objektovat.
• Vrácení zpět: Zvažte, jestli zákazníci chtějí vrátit aktualizace zpět, pokud dojde k zásadní změně a kdo by takový požadavek vrácení zpět aktivoval.

Vaše požadavky

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

• Ří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, může být odpověď ano. Pokud ale vytváříte řešení zaměřené na spotřebitele, je nepravděpodobné, že byste měli mít nad upgradem nebo provozem svého řešení kontrolu.
• Verze: Kolik verzí vašeho řešení můžete přiměřeně udržovat najednou? Mějte na paměti, že pokud najdete chybu a potřebujete ji opravit, 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 budou moc daleko za aktuální verzí? Pokud pravidelně vydáváte nové funkce, budou staré verze zastaralé rychle? V závislosti na strategii upgradu a typech změn může být také potřeba udržovat samostatné infrastruktury pro každou verzi vašeho řešení. Proto můžou být provozní i finanční náklady, protože udržujete podporu starších verzí.
• Vrácení zpět: Může vaše strategie nasazení podporovat vrácení zpět do předchozích verzí? Je to něco, co chcete povolit?

Poznámka:

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

I když během procesu aktualizace neplánujete výpadky, můžete i přesto zvážit definování běžného časového období údržby. Okno může pomoct komunikovat se zákazníky, ke který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 tempo aktualizací vaší služby zcela podle vlastního uvážení vašich tenantů, můžou se rozhodnout, že se nikdy neaktualizují. Je důležité, abyste si umožnili aktualizovat řešení a zároveň se pustit do jakýchkoli rozumných obav nebo omezení, která mohou 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 jejich 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ý může dobře fungovat, je zavedení aktualizací na základě tenanta pomocí jednoho z níže popsaných přístupů. Uveďte zákazníka o plánovaných aktualizacích. Umožnit zákazníkům dočasné odhlášení, ale ne navždy; dejte přiměřené omezení, kdy budete vyžadovat, aby byla aktualizace použita.

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. Zajistěte, aby tenanti pochopili tento postup a jeho důležitost při ochraně svých dat.

Dalším přístupem může být umožnit tenantům inicializovat vlastní aktualizace v okamžiku výběru. Znovu byste měli zadat konečný termín, ve kterém použijete aktualizaci jménem příslušného uživatele.

Upozorňující

Dávejte pozor na to, aby tenanti mohli inicializovat vlastní aktualizace. Implementace je složitá a k zajištění a údržbě vyžaduje značné úsilí o vývoj a testování.

Ať už to uděláte, ujistěte se, že máte proces monitorování stavu tenantů, zejména před a po instalaci aktualizací. Často dochází k kritickým produkčním incidentům (označovaným také jako incidenty živé lokality) po aktualizacích kódu nebo konfigurace. Proto je důležité aktivně monitorovat a reagovat na případné problémy, abyste si zachovali důvěru zákazníků. Další informace o monitorování najdete v tématu Doporučení pro návrh a vytvoření monitorovacího systému.

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í ohrožení 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, implicitně požádáte o oprávnění tím, že poskytnete proces 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 se stane, když máte tísňovou aktualizaci, jako je kritická oprava 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 poskytovat retrospektivní oznámení? Můžete třeba aktualizovat stránku na svém webu pomocí seznamu 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 infrastrukturu jednotlivých tenantů. Zástupci zákaznické podpory by měli být schopni snadno odpovědět na následující otázky:

• Byly nedávno použity aktualizace pro infrastrukturu tenanta nebo sdílené komponenty?
• Jaká byla povaha těchto aktualizací?
• Jaká byla předchozí verze?
• Jak často se na tohoto tenanta použijí aktualizace?

Pokud má některý z vašich zákazníků problém kvůli aktualizaci, musíte zajistit, aby váš 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 do infrastruktury. To je silně ovlivněno modelem tenantů, 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žívat 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 dostatek sestav a viditelnosti, abyste věděli, na jaké verzi infrastruktury, softwaru nebo funkce se každý tenant nachází, na co mají nárok na migraci, a všechna data související s těmito stavy související s časem.

Model razítka nasazení

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

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

Hlavní příznaky

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

Pokud se na vás vztahuje některý z těchto situací, zvažte použití příznaků funkcí:

• Aktualizace nasazujete pravidelně, ale chcete se vyhnout zobrazování nových funkcí, dokud nebudou plně implementovány.
• Chcete se vyhnout použití změn v chování, dokud se zákazník nerozhodne.

Podporu příznaků funkce můžete do aplikace vložit napsáním kódu sami nebo pomocí služby, jako je Aplikace Azure Konfigurace.

Okruhy nasazení

Okruhy nasazení umožňují postupně zavádět aktualizace napříč sadou tenantů nebo kolků nasazení. Ke 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ý okruh znamená pro vaše vlastní řešení. Organizace běžně používají následující okruhy:

• Canary: Kanárské okruhy zahrnují vaše vlastní testovací tenanty a zákazníky, kteří chtějí mít aktualizace hned, jak jsou k dispozici, s pochopením, že můžou dostávat častější aktualizace a že aktualizace nemusí projít tak komplexním procesem ověřování jako v ostatních věcech.
• Raný adoptér: Počáteční okruh osvojovatel obsahuje tenanty, kteří jsou mírně více rizik averzní, ale kteří 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 testovaných aktualizací.

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 je potřeba si uvědomit, že dojde k zásadním změnám rozhraní API. Zvažte použití strategie správy verzí rozhraní API ke zmírnění rizika aktualizací vašeho rozhraní API.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autor:

• John Downs | Hlavní softwarový inženýr

Další přispěvatelé:

• Chad Kittel | Hlavní softwarový inženýr
• Daniel Scott-Raynsford | Partner Technology Strategist
• Vladimirskij Vladimirskij | Hlavní zákaznický inženýr, FastTrack pro Azure

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

Další krok

Zvažte, kdy byste v řešení s více tenanty namapovat požadavky na tenanty.