Śledzenie zdarzeń
Zdarzenia mają cykl życia. Aby skutecznie reagować, musisz mieć możliwość śledzenia ewolucji samego zdarzenia oraz ewolucji odpowiedzi na nie od samego początku tego cyklu życia.
Ocenianie tego, co jest wiadome
Dobrym sposobem oceny procedury śledzenia zdarzeń przy użyciu określonego zdarzenia jest zadawanie sobie szeregu pytań:
- Kiedy po raz pierwszy dowiedzieliśmy się o problemie? Jeśli chcesz skrócić czas odzyskiwania sprawności po zdarzeniu, musisz zacząć zbierać informacje od momentu, w którym uświadamiasz sobie istnienie problemu.
- Jak dowiedzieliśmy się o tym problemie? Czy Twój system monitorowania ostrzegł Cię o tym zdarzeniu? Czy najpierw zaczęli na niego narzekać klienci, bezpośrednio lub w mediach społecznościowych?
- Jeśli po prostu dowiesz się o problemie, czy jesteś pierwszym, który musisz wiedzieć? Jeśli tak, to kogo musisz powiadomić? Jeśli nie, kto jeszcze wie o tym problemie?
- Jeśli inni o nim wiedzą, co jest robione w tej sprawie (jeśli w ogóle)? Czy wszyscy zakładają, że ktoś inny się tym zajął, czy ktoś zaczął podejmować odpowiednie działania?
- Jak źle wygląda sytuacja? Możemy nie mieć żadnego pojęcia ważności lub wpływu i nie ma dla nas miejsca, aby dowiedzieć się, jak źle jest naprawdę problem i kto jest dotknięty.
Jeśli nic nie jest śledzone, uzyskanie odpowiedzi na te pytania może być trudne.
Ustalanie, gdzie będą śledzone informacje o zdarzeniu
Istnieje wiele miejsc, w których można przechowywać i udostępniać listę zdarzeń (aktywnych lub innych) oraz wszystkie bieżące informacje o tych zdarzeniach. Mogą to być tak proste, jak udostępniony obszar plików z dokumentami programu Word i tak złożone, jak wysoce wyspecjalizowane oprogramowanie i usługi śledzenia zdarzeń. Między tymi dwoma skrajnymi rozwiązaniami są systemy śledzenia biletów i pracy, które można nacisnąć do usługi dla tego zadania. Wybrany system jest w rzeczywistości mniej ważny niż sposób jego używania. Niezależnie od używanego systemu każdy, kto może mieć jakiekolwiek połączenie ze zdarzeniami (inżynierowie, obsługa klienta, zarządzanie, public relations, legalne itd.) muszą wiedzieć, gdzie znaleźć system, jak zgłosić zdarzenie i jak uzyskać dostęp do danych, gdy jest to konieczne. Jednym z pewnych sposobów na niepowodzenie śledzenia zdarzeń jest niepowiadomienie ludzi, których ma on wspierać, o tym, jak uzyskać do niego dostęp („jaki jest adres URL do naszego systemu?”), gdy go potrzebują.
W tym module użyjemy funkcji elementu roboczego usługi Azure DevOps na potrzeby naszego przykładowego systemu śledzenia.
Tworzenie pomostu komunikacyjnego
Aby odpowiedzieć na niektóre pytania w poprzedniej sekcji Ocena informacji i rozpocząć proces reagowania na zdarzenia, musisz mieć sposób komunikowania się z innymi osobami na temat zdarzenia. Najlepiej, że będzie to pewnego rodzaju "współpraca zespołowa" elektroniczne medium do rozmowy, choć mostki telefoniczne również działają. Połączenia konferencyjne/mostki telefoniczne są mniej preferowane, ponieważ trudniej jest wstecznie przejrzeć komunikację incydentu (stąd rola "Skrypcja" wymieniona wcześniej).
Niezależnie od wybranego medium, należy pamiętać, aby wyrzuceć unikatowy kanał, który jest ściśle ograniczony do dyskusji na temat tego incydentu i nic innego. Ważne jest, aby tego kanału nie zakłócały niepotrzebne dyskusje, ponieważ musisz mieć możliwość pobrania danych i przeanalizowania ich później podczas przeglądu po zdarzeniu.
W tym module użyjemy usługi Microsoft Teams jako metody komunikacji z incydentami.
Automatyzowanie uruchamiania śledzenia zdarzeń
Przyjrzyjmy się fragmentom, które do tej pory zebraliśmy. Mamy:
- Lista osób na wezwanie (i rotacja zdefiniowana dla nich).
- Rola, jaką możemy przypisać do osób pracujących nad incydentem.
- Konkretne miejsce, w ramach których będziemy deklarować zdarzenie i śledzić je.
- Unikatowy kanał dla osób pracujących nad tym zdarzeniem w celu komunikowania się z nim.
Możesz i należy zautomatyzować tworzenie wszystkich tych elementów i zarządzanie nimi w możliwie najszerszym zakresie. W przypadku wystąpienia pilnego problemu nie chcesz przypominać sobie wszystkich kroków potrzebnych do zgłoszenia zdarzenia, powiadomienia odpowiednich osób i śledzenia go. Wszystko, co naprawdę chcesz zrobić, to mieć możliwość naciśnięcia przycisku „start” uruchamiającego całą wymaganą procedurę pracy nad problemem.
Automatyzacja bez użycia kodu za pomocą usługi Logic Apps
Jednym ze sposobów automatyzacji początkowej odpowiedzi jest użycie usługi Logic Apps, która może uprościć zadanie planowania, automatyzowania i organizowania zadań, procesów biznesowych i przepływów pracy.
Logic Apps to usługa w chmurze platformy Azure do tworzenia rozwiązań integracji. Używa ona łączników do tworzenia zautomatyzowanych przepływów pracy. Wyzwalacze uruchamiają aplikację logiki, gdy wystąpi określone zdarzenie lub gdy dane spełniają określone kryteria. Akcje to operacje, które są wykonywane w przepływie pracy aplikacji logiki.
W naszym przykładzie użyjemy następujących Łącznik aplikacji logiki do śledzenia zdarzeń:
- Usługa Azure Boards (część usługi Azure DevOps), której można użyć do tworzenia i śledzenia problemów/zdarzeń.
- Usługa Azure Storage, w której można przechowywać i pobierać informacje o tym, kto jest na wezwanie, dzięki czemu możesz przypisać odpowiednie osoby do reagowania na zdarzenie. W naszym przykładzie będziemy używać usługi Azure Table Storage, ponieważ oferuje ona bardzo prosty magazyn "klucz-wartość", który ułatwia przechowywanie listy inżynierów i ich stanu na wezwanie.
- Usługa Microsoft Teams, której można użyć do utworzenia nowego, unikatowego kanału zdarzeń w celu śledzenia rozmów zespołów inżynierów w czasie rzeczywistym podczas komunikowania się o określonych zdarzeniach. Dzięki temu można zachować interakcje w odniesieniu do osi czasu zdarzeń później podczas przeprowadzania przeglądu po zdarzeniu.
Teraz powiążemy to wszystko razem za pomocą aplikacji logiki. Najpierw przyjrzyj się kompletnej aplikacji, jak pokazano w Projektant usługi Logic Apps, a następnie omówimy ją krok po kroku.
Pierwszym krokiem jest obsługa wyzwalacza, o którym wspomnieliśmy o żądaniu HTTP. Żądanie HTTP POST jest wykonywane do naszej aplikacji logiki zawierającej ładunek JSON z informacjami o zdarzeniu, które chcemy zadeklarować. Analizujemy ten ładunek i wysyłamy potwierdzenie, że go otrzymaliśmy:
Korzystając z tych informacji, tworzymy nowy element roboczy w naszej organizacji usługi Azure DevOps, która reprezentuje to zdarzenie.
Następnie utworzy nowy kanał usługi Teams dla zdarzenia:
Po utworzeniu kanału element roboczy, który utworzyliśmy chwilę temu, zostanie zaktualizowany za pomocą linku do nowego kanału. Dzięki temu wszystkie informacje będą przechowywane w tym samym miejscu (element roboczy), a osoby, które będą korzystać z niego później, będą wiedziały, gdzie mają przejść, aby dołączyć do kanału.
Teraz nadszedł czas, aby zabrać osobę na wezwanie do zdjęcia. Przeprowadzamy wyszukiwanie w usłudze Azure Table Storage dla adresu e-mail inżyniera wymienionego jako połączenie. Spowoduje to zwrócenie odpowiedzi JSON, którą następnie analizujemy.
Ponieważ nasze zapytanie zwróci listę, musimy iterować poszczególne elementy na tej liście jako kolejny krok. Przypiszemy element roboczy do każdej osoby (są one teraz „właścicielami” zdarzenia).
Następnie w ostatnim kroku wysyłamy wiadomość do kanału usługi Teams ze wskaźnikiem z powrotem do elementu roboczego dla osób, które dołączają do kanału i chcą wiedzieć, gdzie są przechowywane autorytatywne informacje o tym zdarzeniu.
Jest to tylko jeden przykład automatyzacji konfigurowania mechanizmów śledzenia i komunikacji zdarzeń. W następnej lekcji nieco bardziej szczegółowo zajmiemy się aspektami komunikacji dotyczącej zdarzenia.