Niezmienny, zweryfikowany, nudny

Niezmienny katalog główny i zweryfikowany łańcuch rozruchu to najmniej ekscytujące funkcje, jakie system operacyjny może mieć. Nikt ich nie demonstruje. Dają natomiast możliwość powiedzenia z przekonaniem, co działa na maszynie, której nie widzisz — a gdy się to ma, zaskakująco wiele innych problemów przestaje być problemami.

Co utwardzanie naprawia naprawdę

Nie włamania, przede wszystkim. Dryf.

Maszyna zostaje uruchomiona w znanym stanie. Potem ktoś debuguje problem o drugiej w nocy i zostawia narzędzie. Instalator dostawcy zapisuje konfigurację. Aktualizacja pakietu zastępuje plik ręcznie edytowany dwa lata temu. Nic z tego nie jest złośliwe i wszystko jest niewidoczne — a po roku maszyna jest w stanie, który nie istnieje nigdzie poza tą maszyną.

Dryf jest powodem, dla którego „na tamtej działa” to najdroższe zdanie w utrzymaniu. System niezmienny nie dryfuje, bo do systemu plików, z którego się uruchamia, nie da się zapisać. Stanem jest obraz, a obraz jest artefaktem builda z sumą kontrolną.

Co wnosi każdy element

Katalog główny tylko do odczytu. Pliki systemowe są tymi, które zbudowano. Konfiguracja i dane żyją w zdefiniowanych, zapisywalnych miejscach, więc granica między „systemem” a „stanem tej maszyny” jest jawna, a nie archeologiczna.

Zweryfikowany rozruch. Każdy etap sprawdza podpis następnego, od firmware’u w górę. Atakujący, który dosięgnie dysku, nie sprawi, że maszyna uruchomi coś innego, bez klucza, który kontrolujesz. Liczy się to najbardziej tam, gdzie urządzenia są najsłabiej chronione — robot na hali, deck w torbie, pudełko w szafce.

Lockdown jądra. Nawet root nie załaduje dowolnych modułów ani nie zapisze pamięci jądra. Brzmi restrykcyjnie, bo jest — a na maszynie z jednym zadaniem to ograniczenie nic nie kosztuje i usuwa najprostszą drogę od kompromitacji do kompromitacji trwałej.

Najmniejsze potrzebne uprawnienia usług. Każda usługa działa jako własny użytkownik, z widokiem systemu plików zawierającym tylko to, czego potrzebuje, i filtrem wywołań systemowych na resztę. Środowisko modeli nie powinno móc czytać konfiguracji sieci i nie ma powodu, żeby mu na to pozwalać.

Z czego rezygnujesz

Uczciwość w tej sprawie jest bardziej użyteczna niż sama oferta.

Nie zainstalujesz pakietu, żeby coś naprawić o trzeciej w nocy. Jest zdefiniowana ścieżka — nowy obraz i restart — i nie ma jej obejścia. To realne ograniczenie operacyjne i pierwsza rzecz, na którą ludzie się buntują.

Dwie odpowiedzi. Po pierwsze, na maszynach z jednym zadaniem naprawa o trzeciej w nocy to prawie zawsze zmiana konfiguracji albo wycofanie wersji, a oba są wspierane. Po drugie, możliwość zainstalowania czegoś na maszynie produkcyjnej to dokładnie ta możliwość, która wyprodukowała dryf — więc jej usunięcie jest celem, a nie skutkiem ubocznym.

Gdzie naprawdę idzie wysiłek

Ciekawą pracą nie jest montowanie tylko do odczytu, które jest łatwe. Jest nią zdecydowanie, co ma prawo być zapisywalne i dlaczego.

Logi, oczywiście. Tożsamość maszyny i klucze. Wagi modeli, które są duże, aktualizowane w innym rytmie niż system i specyficzne dla wdrożenia. Stan aplikacji. Każde z tych miejsc to świadoma decyzja o tym, co przeżywa restart, co przeżywa aktualizację i co znaczy przywrócenie do ustawień fabrycznych — a spisanie tej listy jest większością projektu.

Dlaczego przy obciążeniach AI liczy się bardziej

Maszyna uruchamiająca model ma dwie właściwości, które czynią dryf szczególnie kosztownym.

Jej zachowanie i tak jest trudne do wyjaśnienia. Dołożenie „a system, na którym działa, jest w nieznanym stanie” do sesji debugowania, dlaczego model zaczął zachowywać się inaczej, to dokładnie zły kierunek.

I trzyma wartościowy stan — wagi, embeddingi, czasem graf tego, czego się nauczyła. Różnica między systemem niezmiennym z określonymi obszarami zapisywalnymi a ogólnym, gdzie cokolwiek może być gdziekolwiek, to różnica między poprawnym backupem a nadzieją.

Nudny, weryfikowalny, powtarzalny. To są komplementy, gdy maszyna nie ma klawiatury.