Kategoria: Automatyzacja i autonomia
Dwa pytania rozstrzygają, jak będzie wyglądał wieczór: „co się zepsuło?” i „co zmieniłem?”. Brzmią podobnie, dotyczą tego samego gasnącego światła w korytarzu, a prowadzą do dwóch zupełnie różnych procedur. Pomyłka na tym rozwidleniu kosztuje więcej niż sama usterka.
Ten budynek obsługuję Home Assistantem od 2019 roku, a procesy w firmach automatyzuję od 2005 roku. To drugie zajęcie nauczyło mnie rzeczy, której nie wyniosłem z majsterkowania: w zarządzaniu usługami IT nieplanowana przerwa i planowana zmiana to dwa osobne procesy, z osobnymi formularzami, osobnymi ludźmi i osobnym tempem. W domu nie ma formularzy ani ludzi. Rozdzielenie tych dwóch procesów zostaje i działa tak samo.
Dlaczego to rozróżnienie w ogóle istnieje
Awaria to utrata usługi, której nikt nie zaplanował. Zmiana to świadoma ingerencja w działający system, podjęta przez kogoś, kto wiedział, że ją podejmuje. Objaw bywa identyczny, na przykład rolety nie zjechały o zachodzie, ale przyczyna leży w zupełnie innym miejscu, więc i szukać jej trzeba inaczej.
Utrata usługi kontra świadoma ingerencja
Przy awarii nie wiesz, co się stało, i musisz to ustalić. Przy zmianie wiesz dokładnie, co zrobiłeś, a pytanie jest tylko takie, czy to, co zrobiłeś, miało takie skutki, jakich się spodziewałeś. Pierwsza sytuacja to śledztwo. Druga to weryfikacja hipotezy, którą sam sformułowałeś godzinę wcześniej. Te dwie czynności wymagają innej kolejności kroków, a mieszanie ich jest głównym źródłem zmarnowanych wieczorów.
Triage, czyli zanim cokolwiek naprawię
Najpierw odpowiadam na trzy pytania, zawsze w tej samej kolejności. Dopiero ich wynik decyduje, którą z dwóch procedur uruchamiam, i w tym zawiera się cała metoda, ponieważ odpowiedzi zajmują chwilę, a wybór złej procedury zajmuje wieczór.
Pierwsze pytanie brzmi: co zmieniłem w ostatniej dobie
- Czy w ostatniej dobie coś zmieniałem: konfigurację, aktualizację, nowe urządzenie, nową automatyzację? Jeśli tak, mam kandydata na przyczynę i zaczynam od niego, a nie od logów.
- Czy objaw dotyczy jednej encji, czy całej grupy? Jedna encja wskazuje na warstwę fizyczną. Cała grupa wskazuje na logikę, integrację albo host.
- Czy to działało kiedykolwiek? Automatyzacja, która nie zadziałała ani razu, nie jest awarią. To niedokończona zmiana.
Trzecie pytanie wyłapuje najczęstszy przypadek. Rzecz, która nigdy nie działała, trafia do procedury zmiany, nie do procedury awarii, i to oszczędza najwięcej czasu, bo szukanie przyczyny psucia się czegoś, co nie było skończone, nie ma końca.
Procedura awarii: najpierw usługa, potem przyczyna
Przy prawdziwej awarii pierwszym zadaniem nie jest zrozumienie, co się stało. Pierwszym zadaniem jest przywrócenie działania, bo w budynku, w którym od jednego hosta zależy oświetlenie i rolety, dom musi działać także wtedy, gdy ja prowadzę diagnostykę.
Przywrócenie usługi nie jest naprawą
Rozdzielam więc dwie czynności, które amatorska wersja tej pracy skleja w jedną. Przywrócenie usługi to przejście na tryb ręczny, przełączenie światła wyłącznikiem, zamknięcie zaworu. Naprawa to ustalenie, dlaczego do tego doszło, i usunięcie przyczyny. Pierwsze robię od razu, drugie wtedy, kiedy mam na to czas i spokój.
Taki podział ma jeszcze jedną zaletę: wymusza istnienie trybu ręcznego. Automatyzacja bez ścieżki obejścia nie jest wygodą, tylko pojedynczym punktem awarii. Dwa tryby pracy, za zgodą i w ramach barier ochronnych, rozwinąłem później w pięciostopniową skalę, którą opisałem w tekście od automatyzacji do autonomii: pięć poziomów.
Dojrzała obsługa awarii ma jeszcze końcówkę, o której łatwo zapomnieć: klasyfikację, zapis zdarzenia i sprawdzenie, czy objaw faktycznie zniknął. Wyciek pod zlewem to nie samo powiadomienie, lecz zamknięcie zaworu, zapis danych z czujnika, utworzenie zadania naprawy i potwierdzenie, że woda przestała płynąć. Bez tego ostatniego kroku nie wiesz, czy usługa wróciła, czy tylko czujnik przestał krzyczeć.
Procedura zmiany: okno, wycofanie i jeden parametr
Zmiana wygląda zupełnie inaczej, bo ryzykiem nie jest tu niewiedza, lecz nieodwracalność. Zmianę planuję, a nie odkrywam.
Zmiana bez planu wycofania nie wchodzi do instalacji
Trzy warunki, które sobie stawiam, są wzięte wprost z pracy zawodowej. Zmianę wprowadzam w oknie, w którym mogę ją obserwować, nigdy przed wyjazdem i nigdy w ostatniej godzinie wieczoru. Każda zmiana ma ścieżkę wycofania, opisaną przed wprowadzeniem, nie po. I zmieniam jeden parametr naraz, bo dwie zmiany jednocześnie dają wynik, z którego nie da się wyciągnąć żadnego wniosku.
Ta ostatnia zasada jest najmniej wygodna i najbardziej opłacalna. Jeśli po dwóch zmianach coś nie działa, nie masz jednej usterki do zdiagnozowania, lecz cztery możliwe kombinacje do przetestowania, a przy trzech zmianach osiem. Dyscyplina jednego parametru jest tym, co utrzymuje diagnostykę w rozmiarze wieczoru.
Co się dzieje, gdy pomylisz jedno z drugim
Cena tej pomyłki jest asymetryczna i warto wiedzieć, w którą stronę.
Zmiana diagnozowana jak awaria zabiera wieczór
Zmiana wzięta za awarię prowadzi do przeszukiwania logów, czujników i integracji w poszukiwaniu przyczyny, która siedzi w tym, co zrobiłeś pół godziny wcześniej. Awaria wzięta za zmianę jest groźniejsza: wycofujesz własną konfigurację, która była w porządku, i dokładasz drugi problem do pierwszego.
Mam na to własny materiał dowodowy. W siedem lat eksploatacji zaliczyłem trzy awarie (własny rejestr) i wszystkie trzy były fizyczne: interfejs sieciowy, połączenie lutowane i przekaźnik, a żadna nie dotyczyła logiki automatyzacji; rozpisałem je w tekście siedem lat z Home Assistant: co się zepsuło. Najdroższa z nich była ta, którą najtrudniej było zaszufladkować: sporadyczne, nieodtwarzalne usterki mojego własnego okablowania Arduino. Nieodtwarzalny objaw wygląda dokładnie jak skutek zmiany, więc diagnoza szła w złą stronę i pochłaniała całe wieczory.
Rejestr, który odpowiada na to pytanie za mnie
Triage opiera się na pytaniu „co zmieniłem w ostatniej dobie”, a na to pytanie pamięć odpowiada źle. Potrzebny jest zapis.
Data ostatniej zmiany jako najważniejsze pole
Każdą automatyzację trzymam w rejestrze, w którym są: cel, wyzwalacz, zależności, sposób, w jaki się psuje, ścieżka obejścia i data ostatniej zmiany. Ostatnie pole wygląda na najnudniejsze i jest najważniejsze, bo zamienia pytanie o pamięć w zapytanie do tabeli. Bez niego pierwszy krok triage’u jest zgadywaniem, a instalacja bez rejestru to nie dojrzała automatyzacja, tylko dług techniczny z ładnym pulpitem.
Rejestr jest też warunkiem wejścia na wyższy poziom autonomii. Systemowi, którego zmian nie zapisujesz, nie powinieneś oddawać decyzji. Jak wyglądało oddawanie ich u mnie, opisałem w tekście miesiąc, w którym system przestał pytać.
Trzy awarie, których żadna procedura nie zatrzyma
Rozdzielenie awarii od zmiany porządkuje reakcję. Nie zmienia natomiast kilku rzeczy, i lepiej wiedzieć których.
Czego procedura nie dotyka
- Nie zapobiega awariom. Wszystkie trzy, które u siebie odnotowałem, były zużyciem sprzętu albo wadą połączenia. Żadna procedura nie powstrzyma przekaźnika od zestarzenia się.
- Nie zastępuje testu przywracania. Ścieżka wycofania, której nigdy nie przeszedłeś do końca, jest założeniem, nie planem, podobnie jak kopia zapasowa bez odtworzenia.
- Nie daje liczby oszczędzonego czasu. Nie mam zmierzonej liczby godzin dla żadnej z domen, które u siebie zautomatyzowałem, i nie wstawię tu szacunku w jej miejsce. To, co da się uczciwie powiedzieć, jest jakościowe: diagnostyka kończy się w wieczór, w którym się zaczęła, częściej niż zanim rozdzieliłem te dwie procedury.
- Nie działa bez zapisu. Cała metoda stoi na pierwszym pytaniu triage’u, a to pytanie wymaga rejestru. Na instalacji bez niego zostaje sama intuicja.
