Z pamiętnika admina #5

Serwer, którego nikt nie dokumentował, ale wszyscy bali się wyłączyć

Pełna lista odcinków: tutaj

W każdym środowisku jest przynajmniej jeden taki serwer. Czasem to VM-ka postawiona pięć lat temu „na chwilę”, czasem stara maszyna fizyczna. Czasem ma nazwę, która nic już nie znaczy, bo projekt zmienił nazwę trzy razy. Czasem w panelu wirtualizacji opis brzmi po prostu: „nie wyłączać”.

I to jest cała dokumentacja.

Serwer, którego nikt nie chce dotknąć

Na przykład srv-old-app-02. System trochę aktualny, trochę nie. Uptime liczony w setkach dni. Kilka otwartych portów. Dziwny nginx. Jakiś proces Javy. Crontaby z roota. Skrypty w /opt. Logi w katalogu, który nie pasuje do żadnego standardu.

Ktoś mówi, że kiedyś po restarcie „coś się zepsuło”. Ktoś inny pamięta, że serwer był chyba powiązany z fakturami. Trzecia osoba mówi, że „Marek będzie wiedział”. Marek oczywiście jest na urlopie.

To jest moment, w którym AI wydaje się idealnym narzędziem. Można zebrać zrzut informacji z systemu, wkleić go do modelu i zapytać: „co to za serwer?”. Model odpowie. Bardzo możliwe, że odpowie składnie, logicznie i z dużą pewnością.

I właśnie tę pewność trzeba potraktować ostrożnie.

Najpierw fakty, potem hipotezy

Legacy serwer to zbiór faktów, hipotez i brakujących danych, a nie zagadka logiczna, którą rozwiąże jedno dobrze sformułowane pytanie do modelu.

Jeśli model napisze: „serwer obsługuje wewnętrzną aplikację raportową”, może mieć rację. Może też zgadywać na podstawie nazwy procesu, ścieżki albo fragmentu loga. W dokumentacji operacyjnej różnica między faktem a hipotezą jest krytyczna.

Fakt można wykorzystać do decyzji. Hipotezę trzeba sprawdzić.

Dlatego pracę zaczynamy od pakietu diagnostycznego, a nie od wielkiego promptu do modelu.

Zbieramy rzeczy nudne, ale konkretne:

• hostnamectl;
• systemctl;
• ss -tulpn;
• crontaby;
• listę usług;
• konfigurację nginx albo Apache;
• mounty i użycie dysku;
• ostatnie logi aplikacji;
• listę skryptów w /opt;
• informacje o backupie;
• reguły firewalla;
• historię wdrożeń, jeśli istnieje.

Chodzi o zebranie materiału dowodowego, a nie o bezmyślne wrzucenie wszystkiego do modelu.

Pakiet diagnostyczny nie jest jeszcze dokumentacją

Następnie selekcjonujemy informacje.

Fakty:

• port 443 nasłuchuje;
• proces Java działa jako użytkownik app;
• cron uruchamia skrypt o 02:10;
• nginx kieruje ruch na localhost:8080;
• logi pokazują żądania z konkretnego segmentu.

Hipotezy:

• to może być panel raportowy;
• usługa może zależeć od bazy na innym hoście;
• system może być ważny dla finansów.

Brakujące dane:

• właściciel systemu;
• procedura restartu;
• wymagany czas odtworzenia;
• status backupu;
• okno serwisowe;
• akceptowalny poziom przestoju.

Dopiero z tak przygotowanego materiału AI może zrobić użyteczny pierwszy szkic runbooka.

Polecenie dla modelu brzmi inaczej niż proste „powiedz prawdę o serwerze”:

Przygotuj pierwszy runbook operacyjny. Oddziel fakty od hipotez, wypisz brakujące dane i pytania do właścicieli. Nie zakładaj, że można restartować system.

Co powinien zawierać pierwszy runbook?

Dobry pierwszy runbook ma być użyteczny o drugiej w nocy, a nie piękną dokumentacją architektury.

Powinien zawierać:

• widoczne usługi i porty;
• znane zależności;
• potencjalne punkty awarii;
• lokalizację logów;
• procedurę diagnostyki tylko do odczytu;
• pytania do właścicieli;
• ryzyka restartu;
• status backupu;
• sekcję „czego nie wiemy”.

Ta ostatnia sekcja jest jedną z najważniejszych. Brak wiedzy też stanowi informację operacyjną.

AI porządkuje okruchy, ale nie dopisuje historii

Wiele organizacji ma ten problem nie z braku wiedzy, lecz dlatego, że wiedza jest rozproszona i nieoznaczona: trochę w ticketach, trochę w komunikatorze, trochę w nazwach katalogów i trochę w głowach ludzi.

AI może pomóc zebrać te okruchy i ułożyć je w pierwszy szkic. Nie może jednak potwierdzić faktów, których nie zawiera materiał wejściowy.

Największą wartością pierwszego runbooka nie jest kompletność, lecz obniżenie lęku przed systemem.

Zamiast „nie dotykać, bo nie wiemy” mamy:

Wiemy tyle. Tego nie wiemy. To sprawdzamy. Restart wykonamy dopiero po spełnieniu tych warunków.

To pozwala zaplanować przegląd, backup, test odtworzenia, rozmowę z biznesem, migrację albo przynajmniej sensowną obserwację.

Jak rozmawiać z biznesem?

AI może pomóc przygotować konkretne pytania:

• Widzimy ruch z tych segmentów – czy należy do Waszego procesu?
• Te hosty łączą się po tych portach – czy to zachowanie jest oczekiwane?
• Ten cron generuje plik – czy plik jest potrzebny?
• Ten endpoint dostaje żądania – kto jest jego właścicielem?
• Czy można zaplanować test restartu?
• Jaki poziom przestoju jest akceptowalny?

W ten sposób strach przed systemem zamienia się w listę sprawdzalnych pytań. A taka lista prowadzi do sensownego utrzymania procesu.

Wnioski?

AI jest dobra w robieniu pierwszego szkicu z chaosu, nie w zgadywaniu prawdy.

Jeśli masz serwer, którego wszyscy boją się wyłączyć, zacznij od faktów, a nie od restartu czy jednego promptu do modelu. Zbierz pakiet diagnostyczny, oddziel fakty od hipotez, przygotuj pierwszy runbook i daj go człowiekowi (adminowi!) do weryfikacji.

Legacy system oswaja się przez małe, nudne i sprawdzalne kroki. W takich krokach AI może być naprawdę przydatna.

~Maciej Szymczak