Zarządzanie zdarzeniami dla obciążeń SaaS na platformie Azure
Niezależni dostawcy oprogramowania (ISV) dla rozwiązań saas (software as a service) muszą obsługiwać rozwiązanie dla swoich klientów. W ten sposób wymagana jest konfiguracja organizacji i kultura, która bezproblemowo obsługuje nieoczekiwane sytuacje produkcyjne. Jako architekt należy odpowiednio zaprojektować procesy zarządzania i narzędzia.
Ten artykuł zawiera instrukcje dotyczące dostosowywania kultury, procesów i narzędzi organizacji do obsługi zarządzania zdarzeniami w produkcyjnym rozwiązaniu SaaS.
Zrozumienie obowiązków jako dostawcy usług
Obsługa rozwiązania SaaS oznacza, że jesteś 24x7 działem IT i działu operacji klientów. Musisz przygotować się z odpowiednim personelem, kulturą, procesami i narzędziami.
Uwagi dotyczące projektowania
Weź odpowiedzialność za pomoc techniczną 24x7x365. Obsługa rozwiązania SaaS wymaga, aby organizacja zawsze przygotowywała się do reagowania na zdarzenia. To przygotowanie obejmuje zawsze dostępność członków zespołu, ponieważ zdarzenia mogą wystąpić poza godzinami pracy.
Obsługa lokacji na żywo obejmuje monitorowanie w czasie rzeczywistym i reagowanie na zdarzenia wpływające na dostępność systemu, bezpieczeństwo, wydajność lub wdrażanie. Ty lub Twoi klienci mogą wykrywać te zdarzenia. Do obsługi takich zdarzeń potrzebne są określone umiejętności, w tym możliwość analizowania i rozwiązywania problemów pod presją.
Obsługa witryny na żywo może być stresujące i ważne jest, aby wspierać członków zespołu. Jeśli zespół jest nowym użytkownikem tej odpowiedzialności, należy uważnie zaplanować przejście. Rozwiąż obawy dotyczące obowiązków na wezwanie, odszkodowania i zarządzania niedostępnością podczas incydentów.
Ryzyko: Zarządzanie umiejętnościami i oczekiwaniami. Nie wszyscy inżynierowie są odpowiedni dla roli pomocy technicznej 24x7x365. W przypadku przejścia istniejącego zespołu na pomoc techniczną rozwiązania SaaS upewnij się, że są ustawione odpowiednie oczekiwania i że są dostępne możliwości edukacyjne.Instytut kultury na żywo. Zastanów się, jak zarządzasz sprawami pomocy technicznej i zdarzeniami oraz jak występują eskalacje. Celem jest zapewnienie, że członkowie zespołu rozumieją swoje obowiązki i mają niezbędne umiejętności i narzędzia do obsługi zdarzeń.
Startupy i mniejsze organizacje mogą mieć lekki plan problemów z witryną na żywo. Inżynierowie mogą początkowo służyć jako pomoc techniczna linii frontu, odpowiadając na zgłoszenia do pomocy technicznej klientów. Dojrzałe organizacje lub dostawcy SaaS z klientami korporacyjni potrzebują bardziej ustrukturyzowanej pomocy technicznej i dedykowanych zespołów.
Kompromis: doskonałość operacyjna i koszty. Zarządzanie zdarzeniami w witrynie na żywo może uniemożliwić tworzenie nowych funkcji lub poprawek błędów. Jeśli szybkość rozwoju jest problemem, rozważ zatrudnienie dedykowanych zasobów na żywo.
Zalecenia dotyczące projektowania
| Zalecenie | Korzyści |
|---|---|
| Wprowadzenie do zespołu linii frontu do obsługi spraw pomocy technicznej. W przypadku złożonych przypadków zespół zbiera informacje potrzebne zespołowi inżynierów do badania. Dostawca może służyć jako zespół pomocy technicznej linii frontu i przeprowadzać początkową analizę problemów i rozwiązywać proste problemy. |
Unikasz nadmiernego przeciążenia zespołu inżynieryjnego z obowiązkami obsługi zdarzeń i radzenia sobie z przerwami w regularnych obowiązkach. |
| Zainwestuj w funkcję na wezwanie dla inżynierów, aby obsługiwać złożone przypadki, badać i podejmować działania. Jeśli to możliwe, obróć obowiązki na wezwanie między członkami zespołu, a każdy inżynier jest na wezwanie przez kilka dni naraz. |
Dzięki dobrze zdefiniowanym obowiązkom i ścieżkom eskalacji można szybko identyfikować i rozwiązywać problemy bez zakłócania przepływu pracy inżynieryjnego. |
| Pozyskiwanie narzędzi przeznaczonych do zarządzania zdarzeniami. Upewnij się, że wszyscy responderzy mają dostęp do tych narzędzi i dowiedz się, jak efektywnie korzystać z tych narzędzi. Wybierz narzędzia, które mogą monitorować stan systemu, śledzić problemy zgłaszane przez klientów, identyfikować problemy, eskalować do inżynierów na wezwanie, zarządzać inżynierami nieodpowiadczymi i włączać wprowadzanie zmian w środowisku produkcyjnym. |
Posiadanie odpowiednich narzędzi ułatwia zespołowi telefonicznemu szybkie identyfikowanie i rozwiązywanie zdarzeń przy zachowaniu zabezpieczeń i kontroli operacyjnej. |
| Usprawnij monitorowanie, wdrożenia, aktualizacje i inne regularne operacje zarządzania. | Inwestując w dojrzałość operacyjną, zmniejszasz prawdopodobieństwo problemów z siedzibą na żywo. Jeśli wystąpią problemy, dobrze zdefiniowane operacje skracają czas rozwiązywania. |
Definiowanie planu odpowiedzi
Przyznaj, że zdarzenia są nieuniknione i przygotuj się do nich, definiując plan reagowania na zdarzenia. Takie proaktywne podejście uniemożliwia opracowanie strategii reagowania podczas pierwszego incydentu.
Zaplanuj przed sobą poważne zdarzenia, które zwykle wpływają na możliwość korzystania z usługi przez klientów. To przygotowanie pomaga zminimalizować stres i złożoność podczas zarządzania zdarzeniami w miarę ich występowania.
Uwagi dotyczące projektowania
Zdefiniuj ścieżkę eskalacji. Upewnij się, że zespoły rozumieją proces eskalacji pod kątem zadań pomocy technicznej. W wielu rozwiązaniach SaaS klienci kontaktuje się z zespołem pomocy technicznej linii frontu, który następnie komunikuje się z zespołem inżynierów. Upewnij się, że klienci wiedzą, z kim należy korzystać, i dlaczego nie powinni pomijać tych procesów. Upewnij się również, że zespół inżynierów wie, kiedy i jak szukać pomocy od dostawców, w tym zespołów pomocy technicznej firmy Microsoft.
Zdefiniuj poziomy ważności. Różne zdarzenia różnią się w zależności od Ciebie i Twoich klientów. Sposób obsługi poważnej awarii produkcyjnej różni się od sposobu rozwiązywania drobnych usterek. Zdefiniuj poziomy ważności na podstawie wpływu klienta i ustaw odpowiednie oczekiwania i osie czasu dla każdego poziomu.
Informacje o dokumencie potrzebne do klasyfikacji. Aktualizowanie dokumentacji jest niezbędne do efektywnego reagowania na zdarzenia. Ta dokumentacja zawiera układ architektury systemu, szczegóły na poziomie składnika, właścicieli i kontakty kluczowe. Niedokładne lub nieaktualne informacje mogą spowodować, że zespół reagowania na zdarzenia zmarnuje cenny czas na ustalenie operacji systemowych, obowiązków i potencjalnego wpływu zdarzenia.
Zaplanuj skuteczną komunikację z klientami. Zapewnianie aktualizacji stanu jest kluczem do zarządzania zdarzeniami. Aktualizacje stanu pomagają klientom zrozumieć charakter zdarzenia, a także zmniejszyć liczbę spraw pomocy technicznej od klientów, którzy napotykają podobne problemy.
Zalecenia dotyczące projektowania
| Zalecenie | Korzyści |
|---|---|
| Podaj jasny proces raportowania zdarzeń, taki jak otwarcie zgłoszenia do pomocy technicznej z zespołem pomocy technicznej linii frontu dla klientów. | Zapewnisz spójność sposobu odnajdywania i reagowania na zdarzenia, co skraca czas rozwiązywania problemów i zapobiega utracie lub pomijaniu informacji. |
| Dokumentowanie układu architektury, szczegółów na poziomie składników, klasyfikacji prywatności lub zabezpieczeń, właścicieli i kluczowych kontaktów. | Zespół klasyfikacji ma łatwo dostępne informacje i może skupić się na badaniach i ocenie wpływu. |
| Upewnij się, że zespół reagowania na zdarzenia może uzyskać dostęp do niezbędnych zasobów i systemów, takich jak dzienniki. Muszą również mieć możliwość wprowadzania zmian produkcyjnych za pośrednictwem bezpiecznego i kontrolowanego procesu. | Operacje przywracania są wykonywane szybciej, upewniając się, że zespół nie marnowa czasu. |
| Użyj strony ze stanem komercyjnym zamiast tworzyć własne. | Oszczędzaj czas przy użyciu strony ze stanem komercyjnym. Strona stanu hostowana przez inną organizację pozostaje również dostępna dla klientów podczas przestoju w systemie. |
Zarządzanie zdarzeniami metodycznie
Przestrzeganie zdefiniowanego planu ma kluczowe znaczenie dla uniknięcia improwizacji w czasie odpowiedzi. Takie podejście pomaga zminimalizować stres i złożoność zarządzania tymi sytuacjami.
Uwagi dotyczące projektowania
Przypisz ważność zdarzenia. Użyj planu reagowania na zdarzenia, aby określić ważność zdarzenia. Klienci są często sfrustrowani podczas zdarzeń. Ważne jest, aby zrozumieć ich wpływ, aby można było ustalić priorytety. Jasno przekaż ważność zdarzenia, aby klienci mieli realistyczne oczekiwania.
Bądź spokojny i wyraźnie pomyśl. Incydenty mogą być stresujące i niejednoznaczne, a wielu uczestników projektu domaga się uwagi. Mieć jasny proces, kto przejmuje prowadzenie w ramach incydentu. Klasyfikacja zdarzeń najlepiej, jak to możliwe, uznając, że może być konieczne działanie z niedoskonałymi informacjami. Staraj się kontrolować sytuację.
Liderzy organizacji mogą pomóc, chroniąc członków zespołu, którzy aktywnie badają lub korygują zdarzenie.
Poinformuj klientów o stanie. Zaktualizuj stronę stanu, aby opublikować wystarczająco dużo informacji. Przekaż szybko i podaj niezbędne informacje, takie jak szacowane czasy rozwiązywania problemów. Zapewnienie klientom częstych aktualizacji w celu zachowania zaufania.
Zalecenia dotyczące projektowania
| Zalecenie | Korzyści |
|---|---|
| Podczas incydentu należy określić priorytety odzyskiwania nad odnajdywaniem. W przypadku wystąpienia zdarzenia należy szybko określić priorytety operacji przywracania, aby zminimalizować zakłócenia dla klientów. |
Odzyskiwanie może być możliwe przez routing wokół składnika, którego dotyczy problem, lub wycofywanie aktualizacji, nawet jeśli jeszcze nie rozumiesz przyczyn problemu. |
| Zapewnianie terminowych, przejrzystych i częstych aktualizacji podczas przestojów. | Możesz zaszczepić zaufanie klientów i zmniejszyć obciążenie zespołu pomocy technicznej pierwszej linii. |
| Wyznaczanie menedżera komunikacji podczas aktywnego zdarzenia. Ten menedżer może być jedną osobą lub możesz wymienić odpowiedzialność między członkami zespołu między zdarzeniami. | Mając jeden głos dla zespołu inżynierów, centralizujesz rozmowy i zmniejszasz rozproszenie uwagi do innych członków zespołu. Zapobiegasz również konfliktowi informacji, które docierają do klientów lub osób biorących udział w projekcie podczas chaotycznego incydentu. |
| Upewnij się, że masz plan pomocy technicznej o znaczeniu krytycznym dla dostawców, takich jak Microsoft. | Jeśli wystąpi awaria, potrzebujesz dynamicznej komunikacji z dostawcami platformy, takimi jak Microsoft, aby pomóc w ustaleniu, gdzie występuje problem i skrócić czas przestoju. |
Przeprowadzanie przeglądów po zdarzeniu
Po odzyskaniu sprawności po zdarzeniu przejrzyj i przeanalizuj, co się stało, aby się z niego uczyć. Zaimplementuj akcje korygowania, które mogą obejmować zmiany techniczne, korekty procesów lub więcej szkoleń.
Uwagi dotyczące projektowania
Dowiedz się na podstawie zdarzeń. Awarie oferują cenne możliwości uczenia się. Przeprowadzanie dokładnych przeglądów po zdarzeniach w celu zidentyfikowania lekcji i wdrożenia ulepszeń. Główne zdarzenia często mają wiele przyczyn. Oceń, czy inne warstwy rozwiązania, takie jak procesy operacyjne, mogą uniemożliwić lub wykryć problem przed jego eskalacją. Ponadto poszukaj podobnych wzorców w innym miejscu rozwiązania, które mogą być również narażone na ten sam problem.
Komunikowanie się z klientami. Wiele niezależnych dostawców oprogramowania zapewnia komunikację po zdarzeniu, zwłaszcza w przypadku klientów korporacyjnych, którzy oczekują wysokiej jakości aktualizacji. Bądź przejrzysty i podaj wystarczającą ilość informacji, aby klienci mogli zrozumieć problem i kroki zaradcze. Jednak aby zachować bezpieczeństwo i integralność, należy unikać udostępniania nadmiernych wewnętrznych szczegółów dotyczących architektury lub składników rozwiązania.
Zalecenia dotyczące projektowania
| Zalecenie | Korzyści |
|---|---|
| Utwórz proces wykonywania wewnętrznych przeglądów po zdarzeniu. Skoncentruj się na identyfikowaniu przyczyn, które przyczyniły się do problemu. Rozważ przyczyny techniczne, sposób, w jaki procesy mogły przyczynić się do awarii i jak zareagowano na zdarzenie. |
Wewnętrzne przeglądy po zdarzeniu pomagają uczyć się z przestojów produkcyjnych i zminimalizować ryzyko wystąpienia podobnych problemów. |
| Utwórz plan ustrukturyzowany, aby rozwiązać wszystkie elementy, które wymagają korygowania. Uwzględnij jasne odpowiedzialności i osie czasu. | Jasna odpowiedzialność pomaga zapewnić, że każda rola spełnia oczekiwania funkcjonalne, zwiększa przejrzystość i umożliwia przejrzyste raportowanie na żądanych poziomach. |
| Publikowanie przeglądów po zdarzeniu skierowanych do klientów. Zapewnij klientom wystarczającą ilość szczegółów, aby zrozumieć problem i kroki zaradcze bez ujawniania niepotrzebnych wewnętrznych szczegółów lub architektury systemu. Komunikacja po zdarzeniu powinna być zawsze napisana i opublikowana przez ludzi. Uczestnicy projektu technicznego i nietechnicznego powinni przejrzeć komunikaty pod kątem dokładności i jasności. |
Takie podejście pomaga utrzymać zaufanie klientów i zapewnia im, że dowiedzieliśmy się z incydentu i są one rozwiązane zidentyfikowane problemy. |
Następny krok
Po przejrzeniu obszarów projektowych przejdź do narzędzia do oceny, aby ocenić projekt.