Po co wyciągać wnioski ze zdarzeń?
Kiedy wystąpi incydent, twoja pierwsza reakcja prawdopodobnie nie jest", "Hurray, okazja szkoleniowa!" Twoim priorytetem jest ustalenie, co poszło nie tak szybko, jak to możliwe, aby zmniejszyć wpływ na klientów i użytkowników końcowych, jak to 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 cyklu życia reagowania na zdarzenia. Nie wszystkie przeglądy po zdarzeniu będą takie same. Są różne sposoby podejścia do procesu, a zbytnie skupienie się na konkretnych aspektach problemu lub zadawanie nieodpowiednich pytań 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 "sposób" w kolejnych lekcjach.
Złożone systemy się psują
Musisz "nauczyć się uczyć" od awarii, a nie w przypadku awarii systemów, ale dlatego, że system zakończy się niepowodzeniem.
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.
W tym module zajmujemy się niezawodnością, ale złożone systemy nigdy nie są w 100 procentach niezawodne. Takie systemy zachowują się w interesujący i nielogiczny 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 wniosków są szczególnie istotne z punktu widzenia procesu reagowania na zdarzenia i późniejszej analizy:
- Złożone systemy zawierają zmienną mieszankę ukrytych możliwości awarii. Nie można uruchamiać systemów bez obecności wielu wad. Rodzaje awarii wciąż się zmieniają, ponieważ zmienia się technologia, organizacja pracy i wysiłki podejmowane w celu usunięcia wad. System nigdy nie będzie działał idealnie.
- Złożone systemy działają w trybie zdegradowanym. Złożone systemy są zawsze uruchamiane jako "uszkodzone" systemy. Utrzymują "pracę" w tym stanie, ponieważ zawierają one wiele zwolnień, a ludzie mogą utrzymać ich funkcjonowanie pomimo obecności wielu wad. Operacje systemowe są dynamiczne, a różne składniki wciąż się psują i są wymieniane.
- Katastrofa zawsze czeka 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ł do wystąpienia katastrofalnej awarii, która może nastąpić w każdej chwili. 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 to połączone ze sobą procesy. Może to wystąpić, gdy organizacja wdrożyła zaawansowany element automatyzacji, który przez większość czasu działał. Póki działała, wszytko było świetnie, ale gdy się zepsuła, awaria była prawdopodobnie spektakularna i pracownikom było jeszcze trudniej odkryć, co poszło nie tak.
Systemy, z którymi pracujesz, to nie tylko technologia. 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 zawierają ludzi, a to, jak ludzie reagują na awarie, jest równie ważne, jak zapobieganie wystąpieniu błędów.
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).
O koncepcji inżynierii odporności w sektorze technicznym musimy się jeszcze wiele nauczyć. 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.