Wyciągnij wtyczkę. Uruchom killswitch. Te instynkty sprawdzają się, gdy stoisz obok pojedynczej maszyny. Zawodzą jednak, gdy Twój system AI rozciąga się na pięćdziesiąt węzłów w trzech strefach dostępności. Większość zespołów inżynierskich uczy się tego w trudny sposób. Aktualizują centralną bazę danych, zmieniają wartość logiczną z true na false i zakładają, że system się zatrzyma. Tak się nie dzieje. Baza danych wygląda na czystą. Usługa wciąż działa.
Iluzja pojedynczego przełącznika
Wyobraź sobie kontroler, który rejestruje wycofanie uprawnień w epoce 12. Zapisuje zmianę w trwałym magazynie danych i wzdycha z ulgą. Tymczasem Worker B działa w oparciu o buforowane uprawnienie z epoki 11. Worker nigdy nie otrzymał powiadomienia. Trzydzieści sekund później uruchamia zadanie wnioskowania modelu, podnosi klaster GPU lub wywołuje zewnętrzne API. Log audytowy mówi, że dostęp został wycofany. Akcja i tak została wykonana.
To luka między trwałością a propagacją. Zapis w bazie danych to nie jest stan systemu. To tylko jeden wiersz w jednej tabeli, a wielu aktorów w Twoim systemie nigdy nie odpytuje tej tabeli w dokładnie tym momencie, w którym tego potrzebują. Jeśli potraktujesz zatrzymanie awaryjne jak przełącznik światła, odkryjesz, że w niektórych kątach pokoju ciemność nigdy nie zapada.
Trudna rzeczywistość systemów rozproszonych
Musisz projektować z myślą o awariach. Nie o sporadycznych awariach. Ale o ciągłych, chaotycznych i niezależnych awariach. Workerzy restartują się w środku zadania. Konsumenci