Wprowadzenie

Hierarchia niezawodności Dickersona oferuje mapę nawigowania po wyzwaniach związanych z niezawodnością; co należy rozwiązać i w jakiej kolejności. Podobnie jak inne hierarchie tego rodzaju, ważne jest, aby poziom, na którym jesteś, był solidny przed przejściem w górę piramidy.

Z poziomu podstawy siedem warstw to:

1. Monitorowanie: nie można poprawić tego, czego nie widzisz.
2. Reagowanie na zdarzenia: niezawodne, powtarzalne procesy reagowania podczas wyzwalania alertów.
3. Przegląd po zdarzeniu: uczenie się z występujących zdarzeń, co jest głównym celem tego modułu.
4. Testowanie i wydawanie: przechwytywanie regresji przed dotarciem do środowiska produkcyjnego.
5. Planowanie pojemności: zapewnienie, że system ma zasoby, których potrzebuje, aby zaspokoić zapotrzebowanie.
6. Programowanie: pisanie niezawodnego oprogramowania.
7. Produkt: Tworzenie właściwej rzeczy dla użytkowników.

Ten moduł dotyczy warstwy w przybliżeniu na środku piramidy. Po rozwiązaniu problemu z monitorowaniem i reagowaniem na zdarzenia (być może z pomocą innych modułów usługi Learn w tej ścieżce szkoleniowej) masz teraz możliwość skupienia się na zasadach i praktykach, które mogą pomóc w uzyskaniu poziomu praktyk operacyjnych.

Hierarchia jest dostosowywana z hierarchii potrzeb dotyczących niezawodności Mikey'a Dickersona.

W tym module koncentrujemy się na przeglądach powypadkowych, które mogą pomóc w uczeniu się na błędach, prowadząc tym samym do zwiększonej niezawodności.

Po ukończeniu tego modułu wykonasz następujące czynności:

• Odkryj znaczenie uczenia się na podstawie zdarzeń.
• Poznaj aspekty złożonych systemów, które sprawiają, że uczenie się od awarii jest ważne.
• Dowiedz się, kiedy i jak przeprowadzić przegląd po zdarzeniu.
• Poznaj cel i cele przeglądu po zdarzeniu.
• Poznaj składniki, które składają się na dobry przegląd po zdarzeniu.
• Zapoznaj się z narzędziami Azure, które mogą pomóc w rozpoczęciu pracy z przeglądami po incydentach.
• Zapoznaj się z typowymi pułapkami, aby uniknąć.
• Identyfikowanie przydatnych rozwiązań w celu przeprowadzenia lepszego przeglądu.

Artykuł wprowadzający

Aby wprowadzić w temat tego modułu, oto prawdziwa historia (a właściwie tylko połowa; do drugiej części przejdziemy w dalszej części tego modułu):

Podczas II wojny światowej samolot B-17 "Flying Fortress" brał udział w serii wypadków. Nie znamy wszystkich szczegółów tych wypadków i nie wiemy dokładnie, ile było. To była wojna, a wiele szczegółów było tajnych i pozostaje tajnych. Wiemy, że istnieje znaczna liczba podobnych incydentów obejmujących wiele pojedynczych samolotów. Historyczne opowieści mają tendencję do skupienia się na uszkodzonych samolotach, a nie na poważnych obrażeniach, ale zapisy z czasów wojny są niekompletne.

W każdym przypadku sytuacja wyglądałaby następująco: B-17 podchodziłby do lądowania, lądowałby pomyślnie, a następnie, czy to na pasie startowym, czy podczas kołowania z powrotem do hangaru, działo się coś dziwnego. Stałoby się coś poważnego. B-17 znajdowałby się na ziemi i nagle podwozie nagle się schowa, a samolot zapadłby się na pas startowy.

W każdym przypadku śledczy szukali dowodów awarii mechanicznej lub elektrycznej, a w każdym przypadku nie mogli znaleźć żadnych. Doszli do wniosku, że był to przypadek błędu pilota i że piloci błędnie wycofali podwozie.

Oto dwie dodatkowe informacje: śledczy mieli rację, że nie doszło do żadnych awarii mechanicznych ani elektrycznych. Wypadki ciągle się działy.

Te informacje mogą sprawić, że będziesz niezadowolony z początkowego wniosku, który został wyciągnięty na temat tych wypadków, i być może skłonić cię do zastanowienia się, czy to już cała historia. W tym module zaproponujemy, że brakuje czegoś w tym wniosku i w badaniach, które do tego doprowadziły.