Proces przeglądu po zdarzeniu

Kluczową częścią przeglądu po zdarzeniu jest budowa wspólnej, dokładnej chronologii, która odzwierciedla nieliniowy charakter incydentu.

Przez nieliniowy rozumiemy, że incydenty prawie nigdy nie polegają tylko na "to się dzieje, potem to się stało, następnie to zauważyliśmy, potem coś zrobiliśmy, a na końcu zakończyliśmy." Ludzie przychodzą i wychodzą, różni ludzie zauważają i próbują różnych rzeczy; niektóre działają, a inne nie. A jeśli wiele osób pracuje w tym samym czasie, te rzeczy mogą się zdarzyć w tym samym czasie, więc jest to nieco bardziej skomplikowane.

Aby utworzyć taką oś czasu, nawet złożoną, zawsze jest ważny pierwszy krok: zbieranie danych.

Zbieranie danych

Przed przeprowadzeniem przeglądu po zdarzeniu należy najpierw zebrać dane. W szczególności musisz zebrać jak najwięcej konwersacji i kontekstu (zarówno technicznego, jak i nietechnicznego) otaczającego wydarzenie, tak jak to możliwe, aby można było używać wszystkich kluczowych danych zawartych w nim. Rozmowa wśród członków zespołu, którzy wystąpili podczas przestoju lub zdarzenia, będzie jednym z najbogatszych źródeł informacji.

Należy również zbierać dane z systemu monitorowania oraz z miejsc, z których osoby zaangażowane w incydent czerpały kontekst. Jakie informacje pochodziły z Twoich systemów w trakcie, gdy incydent się odbywał?

I wreszcie, jeśli to możliwe, warto uzyskać lepszy obraz tego, co zmieniło się przed i podczas zdarzenia, ponieważ zmiany często przyczyniają się do czynników, gdy wystąpi zdarzenie.

Możemy przyjrzeć się temu procesowi jako trzy oddzielne części:

• Zbierz konwersację: W innych modułach tej ścieżki szkoleniowej wspomnieliśmy, że ważne jest, aby przeznaczyć konkretne miejsce do komunikacji podczas zdarzenia. Podczas incydentu, najlepiej ludzie dzielą się tym, co działało i co się nie udało, co nie chcą spróbować, co próbowali w przeszłości. Ta rozmowa wśród osób, które pracują nad rozwiązaniem tego problemu, jest najlepszym źródłem nauki.
• Określanie kontekstu: osoby w zdarzeniu odbierają sygnały z różnych miejsc. Jednym z głównych miejsc jest system monitoringu. Omówiliśmy znaczenie posiadania solidnego systemu monitorowania w poprzednim module w tej ścieżce szkoleniowej. W idealnym przypadku powinniśmy przyjrzeć się systemowi monitorowania, aby utworzyć migawkę z danego momentu dla okresu związanego z incydentem.
• Znajdź zmiany: możesz to zrobić za pomocą dzienników aktywności i inspekcji.

narzędzia Azure ułatwiające zbieranie danych

Azure oferuje szereg narzędzi, które mogą pomóc w tym procesie:

Azure DevOps do przechowywania metadanych dotyczących zdarzenia

W poprzednim module w tej ścieżce szkoleniowej omówiliśmy użycie Azure Boards w zestawie Azure DevOps jako jedno miejsce do zbierania wszystkich informacji o zdarzeniu rozpoczynającym się od początkowej odpowiedzi. Pomaga nam to w zadawaniu pytań o to, kiedy zdarzenie zostało po raz pierwszy zadeklarowane, kto był na wezwanie, który został przypisany do incydentu, i tak dalej. Możesz również użyć witryny Azure DevOps Wiki jako scentralizowanego sposobu ściągnięcia niektórych informacji o samym zdarzeniu i konwersacji, która miała miejsce podczas zdarzenia.

Microsoft interfejs Graph API na potrzeby wyodrębniania konwersacji

Microsoft interfejs Graph API zapewnia programowy sposób pobierania konwersacji zebranej w kanale usługi Teams poświęconym temu konkretnemu zdarzeniu. Pobrane dane obejmują znaczniki czasu, autoryzowanie, edycje, odpowiedzi i niektóre komunikaty systemowe, z których wszystkie mogą pomóc podczas konstruowania chronologii.

Jednym z prostych sposobów rozpoczęcia pracy z interfejsem API Microsoft Graph jest użycie eksploratora Microsoft Graph. Microsoft Graph Explorer to internetowa przeglądarka interfejsu API, która umożliwia wybieranie wywołań interfejsu API z Panelu przykładowych zapytań i przetestowanie ich interaktywnie.

Przed uruchomieniem zapytań upewnij się, że używany użytkownik lub aplikacja ma uprawnienia i zgodę wymaganą dla wybranego trybu dostępu. W scenariuszach delegowanych lista dołączonych zespołów używa Team.ReadBasic.All, lista kanałów używa Channel.ReadBasic.All, a odczytywanie komunikatów kanału wymaga ChannelMessage.Read.All. Jeśli później zautomatyzowasz przepływ pracy z dostępem tylko do aplikacji, użyj GET /users/{id | user-principal-name}/joinedTeams zamiast aliasu tylko delegowanego /me/joinedTeams przy użyciu Team.ReadBasic.All uprawnienia aplikacji. ** W przypadku kroków odczytu specyficznych dla kanału opcje najniższych uprawnień tylko dla aplikacji dotyczą ChannelSettings.Read.Group wyświetlania kanałów i ChannelMessage.Read.Group czytania wiadomości, przy czym obie czynności wymagają zgody specyficznej dla zasobu.

Przejdziemy przez zestaw wywołań interfejsu API Microsoft Graph w wersji 1.0 "Microsoft Teams", aby pobrać konwersację. (Komunikaty kanału zostały przeniesione z wersji beta do wersji 1.0 kilka lat temu, więc punkty końcowe beta nie są już wymagane w tym scenariuszu). W każdym kroku wybierzemy zapytanie, uruchomimy zapytanie, a następnie wybierzemy informacje z odpowiedzi, która pomoże nam w następnym kroku. Następnie użyjemy tych informacji, aby skonstruować następne żądanie. Na przykład najpierw wysyłamy zapytanie o listę identyfikatorów zespołu, aby pokazać zespoły, których jesteśmy częścią. Wybieramy ten, którego potrzebujemy z odpowiedzi i wstawiamy ten identyfikator do następnego adresu URL zapytania, aby uzyskać listę kanałów w tym zespole.

Poniżej przedstawiono kroki przedstawione jako punkty końcowe Microsoft Graph w wersji 1.0:

1. GET /me/joinedTeams (aby znaleźć identyfikator zespołu, który jest używany w scenariuszu delegowanym) lub GET /users/{id | user-principal-name}/joinedTeams (aby wykonać to samo w scenariuszu tylko aplikacyjnym).
2. GET /teams/{team-id}/channels (aby znaleźć identyfikator kanału, którego użyliśmy dla tego zdarzenia).
3. GET /teams/{team-id}/channels/{channel-id}/messages?$expand=replies (aby pobrać konwersację wątkową).
4. Postępuj zgodnie z @odata.nextLink i replies@odata.nextLink według potrzeby lub użyj GET /teams/{team-id}/channels/{channel-id}/messages/{message-id}/replies do przechodzenia przez większe wątki.

Jeśli używasz udostępnionego kanału, pamiętaj, że joinedTeams interfejs API nie zwraca zespołu hosta dla udostępnionego kanału, którego użytkownik jest bezpośrednim członkiem. To zastrzeżenie ma zastosowanie niezależnie od tego, czy wywołujesz GET /me/joinedTeams, czy GET /users/{id | user-principal-name}/joinedTeams. W takim przypadku zacznij od znanych identyfikatorów zespołu i kanału lub użyj skojarzonych interfejsów API zespołu, aby zlokalizować zespół hosta.

W Eksploratorze programu Graph można wprowadzić te adresy URL bezpośrednio lub wybrać równoważne wpisy z wbudowanego panelu Przykładowe zapytania w sekcji Microsoft Teams.

Jeśli później chcieliśmy skonstruować program do wykonania każdego z tych kroków (i rzeczywiście robimy), w oknie żądania istnieje opcja fragmentów kodu , która przedstawia przykładowy kod dla tego zapytania w wielu różnych językach programowania.

W zależności od sposobu korzystania z usługi Teams historia komunikatów może również zawierać komunikaty systemowe, które pomagają wyjaśnić, kiedy członkowie zostali dodani lub usunięci. Jeśli jednak potrzebujesz autorytatywnej ścieżki audytu członkostwa w kanale lub zmian dostępu, uzupełnij te dane dziennikami inspekcji Microsoft 365.

Dashboardy i skoroszyty do wyświetlania kontekstu

Azure dashboardy i workbooki Azure Monitor mogą pomóc zrekonstruować kontekst, który operatorzy widzieli podczas zdarzenia. Pulpity nawigacyjne są przydatne w celu uzyskania błyskawicznego przeglądu operacyjnego w usługach Azure. Skoroszyty zwykle lepiej nadają się do analizy zdarzeń, ponieważ obsługują bardziej złożone zapytania, parametry, przechodzenie do szczegółów oraz tekst narracyjny obok wykresów.

Jeśli masz już pulpit nawigacyjny lub skoroszyt, który przechwytuje odpowiednie sygnały, ustaw jego zakres czasu na okres wokół zdarzenia i użyj go do odtworzenia tego, co ludzie widzieli w tym czasie. Może to być szczególnie przydatne w przypadku korelowania metryk, dzienników i alertów w kilku zasobach.

Udostępnione pulpity nawigacyjne to zasoby Azure i nadal można je eksportować jako plik JSON z portalu. Ta ścieżka eksportu/importu jest przydatna, gdy chcesz wersjonować lub utworzyć szablon pulpitu nawigacyjnego. Jednak w przypadku większości scenariuszy badania po zdarzeniu skoroszyty są bardziej elastycznym narzędziem, ponieważ umożliwiają łączenie wizualizacji, zapytań KQL i tekstu objaśnianego w jednym artefaktzie.

Dzienniki aktywności, dzienniki zasobów i Log Analytics na potrzeby eksploracji zmian

Obszar roboczy Log Analytics może przyjmować dane z wielu źródeł, w tym z dziennika aktywności Azure, dzienników zasobów platformy Azure oraz specyficznej diagnostyki usługi. Najpierw utwórz nowy obszar roboczy Log Analytics. Następnie w portalu Azure otwórz Monitorowanie dziennika aktywności → i wybierz pozycję Eksportuj dzienniki aktywności w górnej części okienka. Spowoduje to otwarcie ustawienia diagnostycznego, które umożliwia wysyłanie dziennika aktywności dla subskrypcji Azure do obszaru roboczego.

W krótkim czasie możesz użyć języka Kusto Query Language (KQL), aby pobrać szczegółowe informacje o zmianach, które miały miejsce w tej subskrypcji od czasu połączenia ze źródłem danych.

Na przykład następujące zapytanie zawiera informacje o zasobach, które uległy zmianie lub zostały usunięte. Możemy ustawić zakres czasu w interfejsie dzienników, aby precyzyjniej skoncentrować się na okresie na krótko przed zdarzeniem.

AzureActivity
| where CategoryValue == 'Administrative'
| where OperationNameValue endswith "write" or OperationNameValue endswith "delete"
| project TimeGenerated, Level, ResourceGroup, ResourceId, OperationName, OperationNameValue, ActivityStatusValue, Caller
| order by TimeGenerated desc

Niniejsze zapytanie jest przydatne w przypadku zmian w płaszczyźnie zarządzania, ale pamiętaj, czego nie pokazuje. AzureActivity przechwytuje operacje płaszczyzny sterowania, takie jak tworzenie, aktualizowanie, usuwanie oraz działania związane z zasadami. Nie przechwytuje zmian na poziomie danych ani na poziomie aplikacji w usłudze. Aby dokładnie zbadać te kwestie, należy sparować to zapytanie z dziennikami zasobów Azure, dziennikami inspekcji specyficznymi dla usługi, historią wdrożenia oraz rekordami CI/CD (ciągłej integracji i ciągłego wdrażania) oraz kontroli źródła.

Jedna szybka uwaga: podczas eksportowania dziennika aktywności Azure informacje są przesyłane do obszaru roboczego Log Analytics od tego momentu. Nie będzie można wykonywać zapytań wstecznie dotyczących tego obszaru roboczego dla zdarzeń, które miały miejsce przed nawiązaniem połączenia.

Te narzędzia powinny być w stanie zapewnić dobry początek zbierania informacji niezbędnych do chronologii do użycia w przeglądzie po zdarzeniu. Zanim przejdziesz bezpośrednio do przeglądu po zdarzeniu, chcielibyśmy ostrzec o niektórych typowych pułapkach. To jest temat naszej następnej lekcji.