Rozumiem urok zbudowania własnego „dead man's switch”. Chcesz pełnej kontroli, braku zależności od third-party i satysfakcji z tworzenia czegoś idealnie dopasowanego do potrzeb. Jako ktoś, kto lubi budować, całkowicie to rozumiem.

Muszę jednak podzielić się tym, czego nauczyłem się o tym, dlaczego własne przełączniki mają niepokojąco wysoką awaryjność właśnie wtedy, gdy ludzie najbardziej ich potrzebują. To nie tylko złożoność techniczna—choć to część problemu—chodzi o czynniki ludzkie, których nie da się wyeliminować inżynieryjnie.

Systemy hostowane we własnym zakresie wymagają stałej konserwacji, aktualizacji bezpieczeństwa, zarządzania serwerem i monitoringu. Budując system na wypadek własnej śmierci, tworzysz coś, co musi działać idealnie w chwili, gdy sam już nie możesz tego naprawiać, aktualizować ani utrzymywać.

Widzieliśmy, jak błyskotliwi inżynierowie tworzyli zaawansowane przełączniki, które zawodziły z powodu wygasłych certyfikatów SSL, nieaktualnych dostawców e-mail, zmian hostingu czy zwykłego dryfu konfiguracji. Wyzwania techniczne da się rozwiązać, ale wymagają stałej uwagi, której po śmierci nie można już zapewnić.

Jest też emocjonalne obciążenie dla bliskich. Gdy Twój własny system zawiedzie, zostaną z rozwiązywaniem problemów w Twoim kodzie, rozumieniem Twojej infrastruktury i debugowaniem konfiguracji w trakcie żałoby. To nie jest spuścizna, którą większość chce zostawić.

Nie chodzi o umiejętności techniczne—wielu z was jest znacznie bardziej wykwalifikowanych niż nasz zespół. Chodzi o szczególne wyzwanie zbudowania czegoś, co musi przetrwać twórcę, nie wymagając żadnej konserwacji od osób, które nigdy nie chciały być administratorami systemów.

Jeśli wybierzesz drogę self-hosted, udokumentuj wszystko szczegółowo, zautomatyzuj konserwację, zaplanuj zależności usług i co najważniejsze—mieć plan awaryjny, gdy Twój główny system nieuchronnie napotka problemy.

JP, Luca, CJ, 8 i Summer