Správa incidentů pro úlohy SaaS v Azure
Nezávislí dodavatelé softwaru (ISV) pro řešení typu software jako služba (SaaS) musí provozovat řešení pro své zákazníky. To vyžaduje organizační nastavení a jazykovou verzi, která hladce zpracovává neočekávané produkční situace. Jako architekt musíte navrhnout procesy a nástroje správy odpovídajícím způsobem.
Tento článek vás provede sladěním kultury, procesů a nástrojů vaší organizace za účelem podpory řízení incidentů produkčního řešení SaaS.
Vysvětlení zodpovědností jako poskytovatele služeb
Provoz řešení SaaS znamená, že jste it a provozní oddělení vašich zákazníků 24x7. Musíte být připraveni se správným personálem, kulturou, procesy a nástroji.
Aspekty návrhu
Vezměte odpovědnost za podporu 24x7x365. Provoz řešení SaaS vyžaduje, aby vaše organizace byla vždy připravená na reakce na incidenty. Tato příprava zahrnuje vždy dostupnost členů týmu, protože incidenty můžou nastat mimo pracovní dobu.
Podpora živého webu zahrnuje monitorování v reálném čase a reakce na incidenty, které ovlivňují dostupnost systému, zabezpečení, výkon nebo nasazení. Vy nebo vaši zákazníci můžete tyto incidenty rozpoznat. K řešení takových incidentů potřebujete konkrétní dovednosti, včetně schopnosti analyzovat a řešit problémy pod tlakem.
Podpora živého webu může být stresující a je důležité podporovat členy týmu. Pokud je pro tento tým nový, naplánujte přechod pečlivě. Vyřešte obavy týkající se povinností při volání, kompenzaci a řízení nedostupnosti během incidentů.
Riziko: Dovednost a očekávání řízení. Ne všichni inženýři jsou vhodná pro roli podpory 24x7x365. Při přechodu existujícího týmu na podporu řešení SaaS se ujistěte, že jsou nastavena správná očekávání a poskytují se příležitosti pro vzdělávání.Vytvořte kulturu živého webu. Zvažte, jak spravovat případy podpory a incidenty a jak dochází k eskalaci. Cílem je zajistit, aby členové týmu pochopili své povinnosti a měli potřebné dovednosti a nástroje pro zpracování incidentů.
Startupy a menší organizace můžou mít jednoduchý plán problémů s živými weby. Technici můžou zpočátku sloužit jako front-line podpora tím, že reagují na případy zákaznické podpory. Vyspělé organizace nebo poskytovatelé SaaS s podnikovými zákazníky potřebují strukturovanější podporu a vyhrazené týmy.
Kompromis: Efektivita provozu a náklady. Správa událostí živého webu může od času vývoje odčítat nové funkce nebo opravy chyb. Pokud se jedná o rychlost vývoje, zvažte přijetí vyhrazených prostředků živého webu.
Doporučení k návrhu
| Doporučení | Výhoda |
|---|---|
| Představte si front-line tým pro zpracování případů podpory. V případě složitých případů tento tým shromažďuje informace, které technický tým potřebuje pro své šetření. Dodavatel může sloužit jako tým podpory frontline a provádět počáteční analýzu problémů a řešit jednoduché problémy. |
Vyhnete se přetížení technického týmu odpovědností za řešení incidentů a k přerušení jejich pravidelných povinností. |
| Investujte do funkce on-call pro techniky, aby mohli zpracovávat složité případy, zkoumat a provádět akce. Pokud je to možné, obměňte povinnosti na volání mezi členy týmu, přičemž každý technik je na hovoru na několik dní najednou. |
Díky dobře definovaným zodpovědnostem a eskalačním cestám můžete rychle identifikovat a řešit problémy bez narušení pracovního postupu přípravy. |
| Procure tools that are special for incident management. Zajistěte, aby všichni respondenti měli přístup k těmto nástrojům a porozuměli jim, jak tyto nástroje efektivně používat. Vyberte nástroje, které můžou monitorovat stav systému, sledovat problémy hlášené zákazníky, identifikovat problémy, eskalovat volajícím, spravovat nereagující techniky a povolovat provádění změn v produkčním prostředí. |
Správné nástroje pomáhají vašemu týmu na volání rychle identifikovat a řešit incidenty při zachování zabezpečení a provozní kontroly. |
| Vylepšete monitorování, nasazení, aktualizace a další pravidelné operace správy. | Investice do provozní vyspělosti snižuje pravděpodobnost problémů s živými lokalitami. Pokud dojde k problémům, dobře definované operace se zkrátí doba řešení. |
Definování plánu reakce
Uvědomte si, že incidenty jsou nevyhnutelné a připraví se na ně definováním plánu reakce na incidenty. Tento proaktivní přístup vám brání v tom, abyste během prvního incidentu museli navrhnout strategii reakce.
Naplánujte si předem hlavní incidenty, které obvykle ovlivňují schopnost vašich zákazníků používat vaši službu. Tato příprava pomáhá minimalizovat stres a složitost při správě incidentů při jejich výskytu.
Aspekty návrhu
Definujte cestu eskalace. Ujistěte se, že týmy chápou proces eskalace pro úkoly podpory. V mnoha řešeních SaaS zákazníci kontaktují tým podpory frontline, který pak komunikuje s technickým týmem. Ujistěte se, že zákazníci vědí, s kým mají komunikovat, a proč by tyto procesy neměli obejít. Také se ujistěte, že technický tým ví, kdy a jak hledat pomoc od dodavatelů, včetně týmů podpory v Microsoftu.
Definujte úrovně závažnosti. Různé incidenty se pro vás a vaše zákazníky liší. Způsob zpracování hlavního produkčního výpadku se liší od toho, jak řešíte menší chybu. Definujte úrovně závažnosti na základě dopadu na zákazníka a nastavte příslušná očekávání a časové osy pro každou úroveň.
Informace o dokumentech, které potřebujete pro třídění. Udržování dokumentace v aktualizovaném stavu je nezbytné pro efektivní reakci na incidenty. Tato dokumentace zahrnuje rozložení architektury systému, podrobnosti na úrovni komponent, vlastníky a klíčové kontakty. Nepřesné nebo zastaralé informace můžou způsobit, že tým reakce na incidenty ztrácel cenný čas zjišťováním operací systému, zodpovědností a potenciálního dopadu incidentu.
Naplánujte efektivní komunikaci se zákazníky. Poskytování aktualizací stavu je klíčem ke správě incidentů. Aktualizace stavu pomáhají zákazníkům pochopit povahu incidentu a také snížit objem případů podpory od zákazníků, kteří mají podobné problémy.
Doporučení k návrhu
| Doporučení | Výhoda |
|---|---|
| Poskytněte zákazníkům jasný proces hlášení incidentů, například otevření případu podpory u vašeho týmu podpory frontline. | Zajistíte konzistenci při zjišťování incidentů a reagování na ně, což zkracuje dobu řešení a brání ztrátě nebo přehlédnutí informací. |
| Zdokumentujte rozložení architektury, podrobnosti na úrovni komponent, klasifikaci ochrany osobních údajů nebo zabezpečení, vlastníky a klíčové kontakty. | Tým pro třídění má snadno dostupné informace a může se zaměřit na šetření a posouzení dopadu. |
| Ujistěte se, že váš tým reakce na incidenty má přístup k potřebným prostředkům a systémům, jako jsou protokoly. Musí také být schopni provádět produkční změny prostřednictvím zabezpečeného a řízeného procesu. | Operace obnovíte rychleji tím, že zajistíte, že váš tým nebude ztrácet čas. |
| Místo vytvoření vlastní stránky se stavem použijte stránku komerčního stavu. | Ušetřete čas pomocí stránky komerčního stavu. Stavová stránka hostovaná jinou organizací zůstává také přístupná zákazníkům během výpadku ve vašem systému. |
Správa incidentů metodicky
Dodržování definovaného plánu je zásadní, aby se zabránilo improvizaci během doby odezvy. Tento přístup pomáhá minimalizovat stres a složitost správy těchto situací.
Aspekty návrhu
Přiřaďte závažnost incidentu. Pomocí plánu reakce na incidenty určete závažnost incidentu. Zákazníci jsou často frustrovaní během incidentů. Je důležité, abyste porozuměli dopadu, který vidí, abyste mohli určit prioritu. Jasně sdělte závažnost incidentu, aby zákazníci měli realistická očekávání.
Zůstaňte v klidu a myslet jasně. Incidenty můžou být stresující a nejednoznačné, přičemž více zúčastněných stran vyžaduje pozornost. Máte jasný proces, který vede v rámci incidentu. Incidenty třídění jsou nejlepší, jak můžete při potvrzení, že možná budete muset pracovat s neúplnými informacemi. Snažte se zůstat pod kontrolou situace.
Vedoucí organizace můžou pomoct stíněním členů týmu, kteří aktivně vyšetřují nebo zmírňují incident.
Informujte své zákazníky o stavu. Aktualizujte stavovou stránku tak, aby publikovala jenom dostatek informací. Okamžitě komunikujte a poskytněte potřebné informace, jako jsou odhadované doby řešení. Udělte zákazníkům časté aktualizace, aby si zachovali důvěru.
Doporučení k návrhu
| Doporučení | Výhoda |
|---|---|
| Během incidentu určete prioritu obnovení před zjišťováním. Když dojde k incidentu, upřednostněte obnovení operací rychle, abyste minimalizovali přerušení provozu pro vaše zákazníky. |
Možná budete moct obnovit směrováním kolem ovlivněné komponenty nebo vrácením aktualizace zpět, i když nerozumíte tomu, co problém způsobil. |
| Během výpadků můžete poskytovat včasné, jasné a časté aktualizace. | Můžete instilovat důvěru zákazníků a snížit zatížení týmu podpory frontline. |
| Určete správce komunikace během aktivního incidentu. Tento manažer může být jedna osoba nebo můžete obměňovat odpovědnost mezi členy týmu mezi incidenty. | Díky tomu, že máte jeden hlas pro technický tým, centralizujete konverzace a omezíte rušivé prvky ostatním členům týmu. Zabráníte také konfliktním informacím, aby se během chaotického incidentu dostaly na zákazníky nebo zúčastněné strany. |
| Ujistěte se, že máte důležitý plán podpory pro dodavatele, jako je Microsoft. | Pokud dojde k výpadku, potřebujete rychlou komunikaci s dodavateli platforem, jako je Microsoft, abyste mohli určit, kde je problém, a zkrátit dobu trvání výpadku. |
Provádění závěrečného vyhodnocení incidentu
Po zotavení z incidentu zkontrolujte a analyzujte, co se z incidentu stalo, abyste se z něj naučili. Implementujte nápravné akce, které můžou zahrnovat technické změny, úpravy procesů nebo více školení.
Aspekty návrhu
Seznamte se s incidenty. Výpadky nabízejí cenné studijní příležitosti. Proveďte důkladné kontroly po incidentech, abyste identifikovali lekce a implementovali vylepšení. Závažné incidenty často mají několik příčin. Než se eskaluje, vyhodnoťte, jestli by jiné vrstvy vašeho řešení, jako jsou provozní procesy, mohly před eskalacem zabránit nebo zjistit problém. Podívejte se také na podobné vzory jinde ve vašem řešení, které můžou být také ohroženy stejným problémem.
Komunikujte se zákazníky. Mnoho výrobců softwaru poskytuje komunikaci po incidentu, zejména pro podnikové zákazníky, kteří očekávají vysoce kvalitní aktualizace. Buďte transparentní a poskytněte zákazníkům dostatek informací, aby porozuměli problému a krokům pro zmírnění rizika. Pokud ale chcete zachovat zabezpečení a integritu, vyhněte se sdílení nadměrných interních podrobností o architektuře řešení nebo komponentách.
Doporučení k návrhu
| Doporučení | Výhoda |
|---|---|
| Vytvořte proces pro provádění interních závěrečného vyhodnocení incidentu. Zaměřte se na identifikaci důvodů, které k problému přispěly. Zvažte technické příčiny, způsob, jakým vaše procesy mohly přispět k výpadku a jak jste na incident odpověděli. |
Interní závěrečné kontroly incidentů vám pomůžou naučit se od výpadků v produkčním prostředí a minimalizovat riziko výskytu podobných problémů. |
| Vytvořte strukturovaný plán, který bude řešit všechny položky, které potřebují nápravu. Zahrnout jasnou odpovědnost a časové osy. | Jasná odpovědnost pomáhá zajistit, aby každá role splňovala svoje funkční očekávání, zlepšila přehlednost a umožňovala transparentní vytváření sestav na požadovaných úrovních. |
| Publikujte závěrečné kontroly incidentů, které se chytnou zákazníkům. Poskytněte zákazníkům dostatek podrobností, abyste porozuměli problémům a krokům pro zmírnění rizik, aniž byste odhalili nepotřebné interní podrobnosti nebo systémovou architekturu. Komunikace po incidentu by měla být vždy napsána a publikována lidmi. Technické a netechnické zúčastněné strany by měly zkontrolovat komunikaci, aby byla přesnost a srozumitelnost. |
Tento přístup pomáhá udržovat důvěru zákazníků a zajišťuje jim, že jste se z incidentu naučili a řešili zjištěné problémy. |
Další krok
Po kontrole oblastí návrhu přejděte k nástroji pro posouzení a vyhodnoťte návrh.