Gdy wartownik umiera: dlaczego cisza nie jest dobrą wiadomością

Skonfigurowałeś alerty. Minęły tygodnie i nie przyszedł ani jeden e-mail.

Wyjaśnienia są dwa. Albo naprawdę nic się nie wydarzyło, albo alertowanie przestało działać, a ty o tym nie wiesz. Z zewnątrz te dwie sytuacje wyglądają identycznie.

A ludzki umysł skłonny jest odczytywać ciszę jako dobrą wiadomość. Dokładnie dlatego ta klasa awarii żyje miesiącami niezauważona.

To inny problem niż milknąca kontrola

W innym wpisie tej bazy wiedzy pisaliśmy: gdy kontrola nie może odczytać swoich danych, nie powinna milknąć, tylko powiedzieć, że nie zdołała odczytać.

To, co opisujemy tutaj, jest o poziom wyżej. Tam milkła kontrola wewnątrz działającego wartownika. Tu nie ma samego wartownika. Nie został nikt, kto mówi, więc nie został też nikt, kto powie, że nie zdołał odczytać.

Jak wartownik umiera po cichu

Usługa się zatrzymuje. Aktualizacja, awaria, brak pamięci. To, co miało ci powiedzieć, jest tym, co się zatrzymało.

Rwie się droga pocztowa. Zmienia się hasło, dostawca blokuje, adres odbija wiadomości. Wartownik pracuje dalej, pisze swoje komunikaty i żaden do ciebie nie dociera. To najbardziej zwodnicza wersja, bo po stronie serwera wszystko wygląda zdrowo.

Ktoś wyłącza i zapomina. Powiadomienia wyłącza się tymczasowo na czas badania czegoś. Problem zostaje rozwiązany. Powiadomienia zostają wyłączone.

Maszyna się wyłącza. Przypadek skrajny: nic nie jest zepsute, po prostu wszystko milczy.

Wszystkie cztery łączy to: żaden nie produkuje komunikatu. A jeśli twoim sposobem zauważania awarii jest otrzymanie komunikatu, to awarie nieprodukujące komunikatu są dla ciebie niewidzialne.

Rozwiązanie ma inny kształt: nie alarm, tylko bicie serca

Trzeba odwrócić kierunek.

Alarm mówi: odezwij się, gdy coś jest nie tak. Bicie serca mówi: w regularnych odstępach mów, że żyję, nawet gdy nic się nie dzieje. A potem niech ktoś zauważy, gdy to mówienie ustanie.

Różnica ma znaczenie. Alarm jest komunikatem o problemie; bicie serca jest komunikatem o samym posłańcu. Odpowiadają na różne pytania i żadne nie zastępuje drugiego.

Gdy pojawia się bicie serca, zmienia się znaczenie ciszy. Cisza niesie teraz informację: coś, co powinno mówić, nie mówi.

Ten, kto zauważa, musi być poza obserwowaną maszyną

To część warta zatrzymania. Maszyna nie może zgłosić własnej śmierci.

Miejsce oceniające bicie serca musi znajdować się poza obserwowanym serwerem: inna maszyna, telefon, punkt zewnętrzny. Kontrola działająca wewnątrz serwera wyłącza się razem z serwerem i nikomu nic nie mówi.

Wystarczy nawet najprostsza domowa wersja: niech serwer co godzinę zostawia gdzieś ślad, a ty patrz na wiek tego śladu. Skomplikowana konstrukcja nie jest potrzebna; potrzebne jest tylko to, żeby ocena odbywała się gdzie indziej.

Bicie serca ma własną pułapkę

Kryje się tu subtelny błąd projektowy i wpada w niego większość konfiguracji: przypięcie bicia serca do harmonogramu czegoś, co użytkownik może wyłączyć.

Powiedzmy, że dzieli czas z dziennym mailem podsumowującym. Użytkownik wyłącza podsumowanie, bo wydało mu się nadmiarowe. Bicie serca ustaje razem z nim. Strona zewnętrzna widzi, że sygnał ustał, i podnosi alarm o braku wieści z serwera, choć nic zupełnie się nie dzieje.

Wynik da się przewidzieć: użytkownik raz przestraszy się bez powodu, a za drugim razem wyłącza alarm. Fałszywy alarm wytworzony przez twój własny mechanizm bezpieczeństwa niszczy zaufanie do tego mechanizmu szybciej niż brak jakiegokolwiek mechanizmu.

Reguła: bicie serca musi mieć własny harmonogram, nie może jechać na niczym, co da się wyłączyć.

Ten sam kształt gdzie indziej

We wpisie o zadaniach kopii zapasowych pisaliśmy: nie patrz na stan zadania, patrz na wiek najnowszej kopii.

Ten sam kształt pojawia się tutaj: nie pytaj systemu alertów, czy działa, patrz na wiek ostatniego sygnału. Stan jest twierdzeniem, wiek jest pomiarem.

I na koniec jedna rzecz do zrobienia w dniu konfiguracji: celowo wywołaj awarię i zobacz, jak przychodzi wiadomość. Nieprzetestowany alarm nie jest mechanizmem, jest nadzieją.

Co robi Atlas

Atlas Watch wysyła dzienne podsumowanie, o sytuacjach krytycznych melduje natychmiast, nie czekając na podsumowanie, a obok tego wysyła cogodzinny sygnał, że żyje.

Warto opowiedzieć o tym, do czego ten sygnał nie jest przypięty.

Sygnał nie jedzie ani na harmonogramie dziennego podsumowania, ani na harmonogramie alarmu. Oba mają własne ustawienia i użytkownik może wyłączyć każde z nich. Gdyby sygnał od nich zależał, w chwili wyłączenia podsumowania ustałby razem z nim, a druga strona powiedziałaby, że nie ma wieści z tego serwera, choć nic złego się nie działo. Dlatego sygnał ma własny harmonogram.

Drugi szczegół wynika z tej samej myśli: gdy ustawienie powiadomień jest wyłączone, plik harmonogramu sygnału w ogóle nie jest zapisywany. Nie zostaje więc stan pośredni, w którym coś jest włączone, ale nie działa; sygnał albo istnieje, albo nie.

Sama droga powiadomień należy do ciebie: podajesz własny serwer pocztowy, a wiadomość wychodzi z twojego serwera. Wysyłanie sygnału do punktu zewnętrznego jest dodatkiem opcjonalnym i produkt nie zależy od niego, by działać.

Ogólna lekcja: mechanizm bezpieczeństwa nie może opierać się na wyłączalnych częściach tego, co chroni. Jeśli się opiera, umiera razem z tym po cichu.