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 technicznych, jak i nietechnicznych) wokół wydarzenia, 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, pomocne byłoby uzyskanie lepszego obrazu tego, co zmieniło się tuż 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 wydzielić konkretne miejsce dla komunikacji podczas incydentu. 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 platformy Azure ułatwiające zbieranie danych
Platforma Azure oferuje szereg narzędzi, które mogą pomóc w tym procesie:
Usługa Azure DevOps do przechowywania metadanych dotyczących zdarzenia
W poprzednim module w tej ścieżce szkoleniowej omówiliśmy używanie usługi Azure Boards w pakiecie Azure DevOps jako jedno miejsce do zbierania wszystkich informacji o zdarzeniu, zaczynając 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 typu wiki usługi Azure DevOps jako scentralizowanego sposobu ściągnięcia niektórych informacji o samym zdarzeniu i konwersacji, która wystąpiła podczas zdarzenia.
Interfejs API programu Microsoft Graph do wyodrębniania konwersacji
Interfejs API programu Microsoft Graph umożliwia programowe znajdowanie, eksportowanie i wprowadzanie konwersacji zebranych w kanale usługi Teams poświęconym temu konkretnemu zdarzeniu. Pobrane dane zawierają również metadane, które będą przydatne podczas konstruowania chronologii, w tym osób, które dołączyły do kanału (i kiedy) oraz znaczniki czasu dla poszczególnych części konwersacji.
Jednym z prostych sposobów rozpoczęcia pracy z interfejsem API programu Microsoft Graph jest użycie Eksploratora programu Microsoft Graph. Microsoft Graph Explorer to przeglądarka internetowego interfejsu API, która umożliwia wybieranie wywołań interfejsu API przez wybranie wstępnie wypełnionych opcji. Oto jak wygląda:
Krok po kroku przejdziemy przez wywołania API "Microsoft Teams" i "Microsoft Teams (beta)" w celu pobrania konwersacji. 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.
Oto nasze kroki:
- POBIERZ "moje zespoły, do których dołączyłem" (aby znaleźć identyfikator zespołu, z którego korzystamy).
- GET "kanały zespołu, którego jestem członkiem" (aby znaleźć identyfikator kanału używanego w tym zdarzeniu).
- POBIERZ "wiadomości w kanale" (w celu odzyskania konwersacji).
Jeśli później będziemy chcieli skonstruować program do wykonania każdego z tych kroków (i rzeczywiście zamierzamy to zrobić), w oknie żądania istnieje opcja fragmentów kodu, która przedstawia przykładowy kod tego zapytania w wielu różnych językach programowania.
Docelowe pulpity nawigacyjne na potrzeby wyświetlania kontekstu
Panele w Azure umożliwiają zbieranie informacji z usługi Azure Monitor, które są istotne dla nas dla świadomości operacyjnej na jednej stronie. Interfejs użytkownika pozwala nam wybrać wyświetlany okres, więc można "cofnąć czas" i ponownie wyświetlić informacje o pulpicie nawigacyjnym dla okresu związanego ze zdarzeniem, jeśli tego chcemy (pod warunkiem, że informacje nie są zbyt stare, aby nie były już przechowywane w usłudze Azure Monitor). Ten zrekonstruowany interfejs użytkownika może być przydatny podczas próby ustalenia, co osoby w zdarzeniu widziały podczas tego zdarzenia, ale wymaga, aby osoba wykonująca przegląd zdarzenia ręcznie dążyła do odpowiedniego okresu.
Jedną z funkcji pulpitów nawigacyjnych na platformie Azure, która często jest pomijana, jest możliwość zrzutu szablonu dowolnego pulpitu nawigacyjnego wyświetlanego w pliku JSON przy użyciu przycisku Pobierz (strzałka w dół) i załadowania ich z powrotem za pomocą przycisku Przekaż (strzałka w górę). Oznacza to, że możemy ręcznie ustawić odpowiedni czas, pobrać aktualnie wyświetlany pulpit nawigacyjny i udostępnić plik JSON innym osobom, lub po prostu pobrać bieżący pulpit nawigacyjny i zmodyfikować plik JSON zgodnie z naszymi wymaganiami. Jeśli szukasz ciągu "time" w pobranym pliku pulpitu nawigacyjnego JSON, zostanie wyświetlona sekcja, która wygląda następująco:
"metadata": {
"model": {
"timeRange": {
"value": {
"relative": {
"duration": 24,
"timeUnit": 1
}
},
"type": "MsPortalFx.Composition.Configuration.ValueTypes.TimeRange"
},
"filterLocale": {
"value": "en-us"
},
"filters": {
"value": {
"MsPortalFx_TimeRange": {
"model": {
"format": "utc",
"granularity": "auto",
"relative": "24h"
},
"displayCache": {
"name": "UTC Time",
"value": "Past 24 hours"
},
Zmodyfikuj tę sekcję do specyfikacji i załaduj ponownie. Jeśli nie znasz używanego formatu, możesz ręcznie zmienić pulpit nawigacyjny, pobrać go i wyświetlić wymagany format.
Dzienniki inspekcji i usługa Log Analytics na potrzeby eksploracji zmian
Obszar roboczy usługi Log Analytics może pobrać dane z wielu źródeł, w tym dziennik aktywności platformy Azure. Najpierw utwórz nowy obszar roboczy usługi Log Analytics. Następnie przejdź do funkcji dziennika aktywności w portalu i wybierz pozycję Ustawienia diagnostyczne. Zapewnia to opcję wysyłania dziennika aktywności dla subskrypcji platformy Azure do nowego obszaru roboczego.
W krótkim czasie będzie można korzystać ze wszystkich możliwości 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 dla zapytania w Eksploratorze zapytań, aby dokładniej ustalić czas na krótko przed zdarzeniem, jeśli chcemy.
AzureActivity
| where CategoryValue == 'Administrative'
| where OperationNameValue endswith "write" or OperationNameValue endswith "delete"
| project TimeGenerated, Level, ResourceGroup, ResourceId, OperationName, OperationNameValue, ActivityStatus, Caller
| order by TimeGenerated nulls first
Jedna szybka uwaga: po ustawieniu dziennika aktywności platformy Azure jako źródła danych, informacje zaczynają przepływać do obszaru roboczego usługi Log Analytics od tego momentu. Nie będzie można wykonywać zapytań tego obszaru roboczego wstecz dla danych o zdarzeniach, 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.