Dlaczego warto uczyć się na podstawie zdarzeń?

Kiedy wystąpi incydent, twoja pierwsza reakcja prawdopodobnie nie jest: "Hurra, okazja szkoleniowa!" Twoim priorytetem jest ustalenie, co poszło nie tak i naprawienie tego tak szybko, jak to możliwe, aby zmniejszyć wpływ na klientów i użytkowników końcowych, tak jak powinno być. Jest to proces reagowania na zdarzenia omówiony w innym module w tej ścieżce szkoleniowej.

Jednak po rozwiązaniu zdarzenia ważne jest, aby kontynuować i korzystać z doświadczenia. Jeśli nie zajmiemy czasu, aby dowiedzieć się z incydentu, pozostaje to tylko utrata czasu, pieniędzy, reputacji itd. ale jeśli to zdarzenie może być źródłem informacji (w sposób, w jaki nie może być inne źródło), możemy rzeczywiście czerpać z niego pewne korzyści.

Przegląd po zdarzeniu jest częścią fazy analizy procesu reagowania na incydenty. Nie wszystkie przeglądy po zdarzeniu są jednakowe. Istnieją różne sposoby podejścia do procesu, a zbyt duże skupienie się na niektórych aspektach problemu lub formułowanie pytań w niewłaściwy sposób może zmniejszyć wartość przeglądu.

W tej lekcji zaczniesz myśleć nie tylko o tym, dlaczego, ale także o tym, jak najlepiej nauczyć się zdarzeń. Rozszerzymy temat "jak" w kolejnych jednostkach.

Złożone systemy kończą się niepowodzeniem

Musisz "nauczyć się uczyć" od awarii, a nie w przypadku awarii systemów, ale dlatego, że istnieje pewność, że systemy awarii.

W nowoczesnym świecie większość systemów, z jakimi pracujemy dzisiaj — zwłaszcza w środowisku chmury — jest złożona. Składają się one z wielu połączonych części, które muszą współpracować, a ogólne zachowanie systemu pochodzi z interakcji tych części tak samo jak z poszczególnych części.

Niezawodność to wątek uruchamiany w ramach tej ścieżki szkoleniowej, ale złożone systemy nigdy nie są o sto procent niezawodne. Takie systemy zachowują się w ciekawy i nieintuicyjny sposób. Składają się one z wielu części, a często zachowanie systemu pochodzi z interakcji między tymi częściami tak samo jak z samych części.

Aby bardziej szczegółowo omówić ten temat, dobrym zasobem jest dokument zatytułowany How Complex Systems Fail by dr Richard I. Cook. Jest anestezjologiem i badaczem, który spędził dziesięciolecia pracy nad bezpieczeństwem w złożonych systemach, w szczególności bezpieczeństwa pacjentów w systemie opieki zdrowotnej. W tym dokumencie wyjaśnia, co jest wspólne dla złożonych systemów we wszystkich dziedzinach od opieki zdrowotnej po operacje programowe.

Niektóre z jego kluczowych kwestii są szczególnie istotne dla procesu analizy zdarzeń i przeglądu po zdarzeniu:

• Złożone systemy zawierają zmieniające się mieszaniny ukrytych w nich usterek. Nie można uruchamiać systemów bez obecności wielu wad. Awarie zmieniają się stale ze względu na zmianę technologii, organizacji roboczej i wysiłków w celu wyeliminowania awarii. System nigdy nie działa doskonale.
• Złożone systemy działają w trybie obniżonej wydajności. Złożone systemy są zawsze uruchamiane jako "uszkodzone" systemy. Pozostają "działające" w tym stanie, ponieważ zawierają wiele niepotrzebnych elementów, a ludzie mogą utrzymać ich działanie pomimo obecności wielu wad. Operacje systemowe są dynamiczne, a składniki stale kończą się niepowodzeniem i są zastępowane.
• Katastrofa zawsze jest tuż za rogiem. Złożoność tych systemów oznacza, że poważne awarie systemu są w dłuższej perspektywie nieuniknione. Złożone systemy zawsze mają potencjał awarii katastrofalnej i mogą wystąpić w dowolnym momencie. Nie można wyeliminować tego potencjału, ponieważ jest częścią natury systemu.

Zapobieganie i reagowanie

W celu osiągnięcia żądanego poziomu niezawodności systemów i usług wykonaj wszystko, co możliwe, aby zapobiec wystąpieniu zdarzeń. Jednak ze względu na złożoność tych systemów, jak wyjaśniono wcześniej, zapobieganie nie zawsze jest możliwe.

Z tego powodu musimy podjąć dwuczęściowe podejście do niepowodzeń: zapobieganie, a kiedy to nie jest możliwe, przygotowanie do szybkiego i skutecznego reagowania.

Zapobieganie i reagowanie są połączone ze sobą. Może to wystąpić, gdy organizacja wdrożyła zaawansowany element automatyzacji, który przez większość czasu działał. To było wspaniałe, że działał przez większość czasu, ale kiedy zawiódł, robił to zapewne spektakularnie, co utrudniało operatorom zrozumienie, co się stało.

Systemy, na których pracujesz, składają się z więcej niż technologii. W rzeczywistości nie pracujesz "na" ani "z" systemem; pracujesz w systemie. Jesteś częścią systemu. Złożone systemy obejmują zarówno składniki techniczne (sprzęt, oprogramowanie) jak i ludzkie składniki (osoby i ich osobowości, szkolenia i wiedzę). Nasze systemy to systemy, które obejmują ludzi, i sposób, w jaki ludzie reagują, gdy coś pójdzie źle, jest tak ważne, jak zapobieganie wystąpieniu błędu w pierwszej kolejności.

Język

Język ma znaczenie. Dowiesz się w tym module, że będziemy bardzo szczegółowo określać, jakich terminów używamy i jakich terminów celowo nie używamy.

Słowa, których używamy, wpływają na to, jak myślimy o tym, co wydarzyło się w incydencie, i mogą drastycznie zmienić to, co i ile się uczymy. To odkrycie pochodzi z badań w branżach o znaczeniu krytycznym dla bezpieczeństwa, takich jak lotnictwo, medycyna, poszukiwania i ratowanie, strzelaniny i nie tylko.

Wspólnie ta dziedzina badań stała się znana jako Inżynieria odporności (RE).

Mamy wiele do poznania inżynierii odporności w sektorze technologicznym. W dalszej części tego modułu udostępnimy kilka naprawdę przydatnych rzeczy, których nauczyliśmy się z literatury RE, w tym cztery z najbardziej typowych pułapek, w których ludzie wchodzą podczas próby uczenia się od awarii; ale najpierw musimy zdefiniować niektóre terminy.