Co dělat během přerušení služby Azure

V Microsoftu tvrdě pracujeme na tom, abychom měli jistotu, že jsou pro vás naše služby vždy dostupné, když je potřebujete. K neplánovaným přerušením služeb ale dochází. Tento článek vysvětluje, co se stane, když k tomu dojde.

Microsoft poskytuje smlouvu o úrovni služeb (SLA) pro řadu svých služeb jako závazek pro dostupnost a připojení. Smlouvu SLA pro jednotlivé služby Azure najdete v Azure smlouvy o úrovni služeb.

Vysvětlení rozsahu incidentů

Pokud porozumíte rozsahu tohoto incidentu, můžete určit nejlepší postup.

Pokud chcete porozumět rozsahu incidentu, postupujte takto:

1. Přejděte na Azure Service Health, která poskytuje:

   • Informace o problémech nebo událostech , které můžou mít vliv na vaše služby.

   • Automatická upozornění na aktualizaci incidentů, abyste mohli být upozorněni na všechny aktualizace stavu incidentu automaticky. Když Microsoft rozumí rozsahu incidentu, aktualizujeme stav incidentu. Tyto aktualizace stavu můžete nakonfigurovat tak, aby přešly do skupiny akcí Azure Monitor, která může odesílat výstrahy na různá místa, jako je e-mailová adresa nebo do vlastního systému správy incidentů.

2. Pokud máte problémy s přístupem k portálu Azure, přejděte na stav Azure.

   Poznámka:

   Azure stav zobrazuje pouze rozšířené problémy, které splňují určitá kritéria. Protože stránka stavu Azure neví, která předplatná a tenanty spravujete, nemůže poskytnout přesné zobrazení menších problémů, které můžou mít vliv na vaše služby.

3. Pokud na stránce stavu dochází k problémům, zkontrolujte příspěvky z @AzureSupport na sociální platformě X.

Incidenty zóny dostupnosti a datacentra

Řada problémů je omezená na jednu zónu dostupnosti. Zóny dostupnosti představují datacentra nebo skupiny datacenter, které jsou izolované od jiných zón dostupnosti ve stejné oblasti. Když u zóny dostupnosti dojde k problému, dopad, který uvidíte, závisí na způsobu nasazení služby:

• Může to mít vliv na zónové služby připnuté k ovlivněné zóně dostupnosti.
• Zónově redundantní služby pravděpodobně nebudou ovlivněny. U zónově redundantních prostředků byste neměli provádět žádnou nápravnou akci.
• Místní (neonální) služby můžou být ovlivněné, protože můžou používat ovlivněnou zónu dostupnosti.

Další informace o podpoře zón dostupnosti ve službách Azure a rozdílech mezi zónovými, zónově redundantními a regionálními službami (mimo zónové) najdete v tématu Azure služby s podporou zón dostupnosti.

Pokud máte nějaké obavy týkající se zónových nebo regionálních prostředků nasazených v ovlivněné zóně dostupnosti, zvažte zahájení plánů provozní kontinuity a zotavení po havárii (BC/DR).

Logické a fyzické zóny dostupnosti

Každé Azure předplatné uvidí jiný seznam zón dostupnosti. Logické zóny používané jednotlivými předplatnými můžou odpovídat různým fyzickým zónám. Můžete namapovat mezi logickými zónami a fyzickými zónami, abyste potvrdili, které prostředky běží v ovlivněné zóně fyzické dostupnosti. Další informace najdete v tématu Fyzické a logické zóny dostupnosti.

Incidenty na úrovni celé oblasti

Občas se problémy týkají celé oblasti. K problémům v celé oblasti může dojít, když oblast nemá zóny dostupnosti. Pokud dojde k incidentu v celé oblasti, možná budete muset zvážit zahájení plánu zotavení po havárii. Plánujete zahrnout převzetí služeb při selhání do jiné oblasti.

Stanovení priority provozní kontinuity

Když se setkáte s incidentem, je nejvyšší prioritou zachovat provoz vaší firmy. Příliš mnoho zaměření na izolování nebo opravu příčiny problému může vaši pozornost odvrátit od obnovení provozu vašeho řešení a zachování kontinuity podnikových procesů.

Následující faktory představují situace, kdy nemusíte dělat nic, aby se zachovala kontinuita podnikových procesů:

• Skutečný dopad problému na produkční prostředky a na uživatele nebo úlohy. Například problém, ke kterému dochází mimo standardní pracovní dobu, nemusí vyžadovat, abyste něco udělali okamžitě.

• Rozsah incidentu. V případě problémů izolovaných do jedné zóny dostupnosti nemusíte dělat nic, pokud používáte zónově redundantní prostředky nebo pokud jsou prostředky, které používáte, v neovlivněné zóně fyzické dostupnosti.

• Odhadovaná doba řešení, pokud je k dispozici. Microsoft se snaží co nejdříve poskytnout jasné časové rozvrhy pro obnovení. Pokud provádění vašich obnovovacích postupů trvá značnou dobu, zvažte, zda se očekává, že se problém vyřeší do doby, než budou dokončeny.

• Cíle na úrovni služeb (SLO) vytvořené s uživateli ovlivněných úloh, pokud je máte. Úrovně služby (SLO) jsou zde, aby usměrňovaly rozhodování v takové situaci. V některých situacích můžete být například schopni přepnout na ruční operace, dokud vaše služby nejsou v pořádku, a toto rozhodnutí se může projevit ve vašem SLO systému. Další informace o cílech úrovně služeb a jejich definování najdete v tématu Poručky pro definování cílů spolehlivosti v Azure Well-Architected Frameworku.

Pokud ale provozní kontinuita vyžaduje nějakou formu akce a máte zavedený plán zotavení po havárii, je dalším krokem zvážení, jestli se má tento plán zahájit.

Zvažte svůj plán zotavení po havárii.

Plán zotavení po havárii vysvětluje, co očekáváte v případě závažného incidentu. Plány zotavení po havárii obvykle zahrnují akce, jako jsou následující:

• V případě izolovaného výpadku v rámci zóny dostupnosti rozšiřte kapacitu prostředku, pokud je to možné.
• Pro výpadek zóny dostupnosti při použití zónových služeb nejprve přeneste provoz do jiné zóny dostupnosti a poté nasaďte do další zóny dostupnosti.
• V případě výpadku zóny dostupnosti při použití zónově redundantních služeb nemusíte nic dělat. Pokud zaznamenáte problémy s výkonem, zvažte zvýšení kapacity prostředku, aby instance ve zbývajících zónách mohly zpracovat nárůst provozu, který na ně přijde.
• V případě regionálního výpadku nasadte do jiné oblasti a přepněte na jiný region.

Důležité

Nepromýšlejte žádné akce, aniž byste je promysleli. Spěchané rozhodnutí můžou někdy dělat horší věci. Pokud jste už vytvořili plán zotavení po havárii, který tento scénář pokrývá, je obvykle lepší ho použít místo vytvoření plánu v tuto chvíli.

Převzetí služeb při selhání může být složitý proces. Failover byste měli aktivovat pouze tehdy, když můžete lépe odůvodnit náklady a rizika. V některých situacích může dojít ke ztrátě dat, například pokud se nedávné změny nereplikovaly mezi oblastmi před zahájením výpadku. K výpadkům může dojít také, zejména pokud potřebujete přesměrovat provoz do nasazení v jiné oblasti. V závislosti na způsobu návrhu vašeho řešení možná budete muset aktualizovat záznamy DNS a počkat, až se rozšíří.

Převzetí služeb při selhání iniciované Microsoftem

Některé služby Azure se automaticky přepnou na alternativní oblasti během incidentů. Microsoft spravuje proces převzetí služeb při selhání těchto služeb. Nouzové převzetí iniciované společností Microsoft se ale obvykle provádí jako poslední možnost a po delším časovém období stráveném pokusy o obnovení. Obecně platí, že zásady Microsoftu minimalizují ztrátu dat, i když to znamená delší dobu obnovení. Pro vlastní řešení byste se neměli spoléhat výhradně na převzetí služeb při selhání iniciované Microsoftem, zejména pokud potřebujete minimalizovat dobu obnovení. Pokud můžete, použijte převzetí služeb při selhání iniciované zákazníkem pro služby, jako je Azure Storage.

podpora Azure

Pokud už je servisní incident oznámen v Azure Service Health, najdete tam všechny nejnovější informace a nemusíte otevírat žádost o podporu.

Můžete ale zvážit otevření případu podpory v případech, kdy:

• Dochází k problémům, které nejsou popsané v popisu incidentu v Azure Service Health.

• V rámci úsilí o obnovení potřebujete pomoc od Microsoftu.

  Návod

  Pokud vás naruší přerušení služeb, budete moct po dobu až 72 hodin po zmírnění problému vytvořit bezplatný lístek podpory, aby vám pomohl s případnými kroky, které možná budete muset provést k obnovení.

Při otevření případu podpory jasně vysvětlete, které prostředky jsou ovlivněné, a dopad problému. Zadejte ID Azure předplatného a oblast, u které dochází k problému. Nastavte závažnost případu podpory na základě dopadu na vaši firmu. Mějte na paměti, že mnoho zákazníků může reaktivně kontaktovat podporu Azure v důsledku přerušení služby Azure, které nespadá do těchto popsaných podmínek. Toto přidání zatížení podpora Azure prostředků by bohužel mohlo zpozdit řešení vašich potřeb podpory.

Po incidentu

1. Pokud chcete zjistit, co se Microsoft z incidentu naučil, přečtěte si Přehled po incidentu (Post Incident Review, PIR) z podokna Historie stavu Azure Service Health nebo prostřednictvím upozornění Service Health nakonfigurovaných zákazníkem. Různé incidenty mohou mít různé typy přezkoumání incidentů. Předběžné zprávy PIR jsou obvykle publikovány několik dní po incidentu a podrobnější zprávy PIR následují za několik týdnů.

2. U hlavních incidentů, které byly uvedeny na naší veřejné stránce stavu, se připojte k živému streamu Azure Incident Retrospective, abyste získali odpovědi na jakékoli otázky nebo podívejte se na nahrávku.

3. Pokud si myslíte, že máte nárok na kredit SLA, vytvořte novou žádost o podporu s typem žádosti o refundaci a uveďte ID sledování incidentu.

4. Zvažte, co se z incidentu můžete naučit, abyste zlepšili vlastní odolnost a procesy. Zamyslete se nad otázkami, jako jsou:

   • Jak dobře váš plán zotavení po havárii fungoval? Existují nějaká vylepšení, která byste mohli udělat? Další informace najdete v pokynech k Azure Well-Architected Frameworku pro strategie zotavení po havárii.

   • Byla vaše reakce na incident odpovídající závažnosti? Pokud ne, existují způsoby, jak byste mohli být lépe informovaní a činit lepší rozhodnutí o tom, co dělat?

   • Existují Azure průvodci spolehlivostí služeb pro služby, které používáte? Průvodci spolehlivostí poskytují informace o tom, kolik služeb Azure je možné nakonfigurovat tak, aby splňovaly vaše požadavky na odolnost.

   • Existuje nějaký návrhový kompromis, který můžete udělat, abyste do budoucna zlepšili svou odolnost proti tomuto typu problému? Další informace najdete v pilíři spolehlivost architektury Azure Well-Architected.

   • Je cíl úrovně služby (SLO) nebo smlouva SLA nabízená vašim uživatelům stále vhodnou, když jste zaznamenali tento neplánovaný výpadek? Teď je vhodná doba k tomu, abyste se znovu seznámili se závazky, které provádíte s uživatelskou základnou, aby odpovídaly očekáváním, co jste se z tohoto incidentu naučili.

   • Měli byste nakonfigurovat výstrahy Azure Service Health tak, aby se automaticky dostávaly oznámení o jakýchkoli budoucích incidentech?

5. Pokud máte zpětnou vazbu k tomu, jak můžeme zlepšit reakce na incidenty, dejte nám vědět prostřednictvím svého přiřazeného zástupce Microsoftu nebo prostřednictvím web pro Azure zpětnou vazbu.