Z pamiętnika admina #3

Skrypt po poprzedniku działał, dopóki nie zadziałał.

„Z pamiętnika admina” to cykl artykułów opartych na autentycznych doświadczeniach – bez podręcznikowej teorii, za to z konkretami prosto z placu boju. 

Pełna lista odcinków: tutaj

Każdy zespół ma taki plik. Czasem leży w /opt/scripts. Czasem w katalogu domowym użytkownika, którego konto „na wszelki wypadek” nadal istnieje. Czasem w repo, ale ostatni commit ma opis fix final. Nazwa zwykle mówi więcej o historii organizacji niż o funkcji: backup_cleanup_final_v2.sh, sync_old_do_not_touch.ps1, prod_copy_last_good.sh.

Skrypt działa z crona. Albo z Harmonogramu zadań. Albo ręcznie, kiedy ktoś pamięta. Wszyscy wiedzą, że jest ważny. Nikt nie jest pewien, co dokładnie robi. Najczęściej pada zdanie: „Uważaj, to jest po poprzedniku”.

W środku klasyka. rsync –delete. Trochę rm -rf. Zmienna, która powinna być zawsze ustawiona. Mount, który powinien zawsze istnieć. Katalog backupowy, który powinien zawsze mieć poprawną ścieżkę. Brak locka. Brak dry-runa. Brak sprawdzenia wolnego miejsca. Brak testu na pusty string. Jest za to coś znacznie potężniejszego: organizacyjne przekonanie, że „działa od lat”.

To zdanie jest jednym z najbardziej niebezpiecznych stwierdzeń w IT – „działa od lat” bardzo często oznacza: nikt dawno nie sprawdzał, co się stanie, kiedy założenia przestaną być prawdziwe.

AI w takim przypadku kusi, jak mało co. Wklejasz skrypt do modelu i piszesz: „popraw”. Model robi porządek. Dodaje funkcje. Dodaje logowanie. Dodaje obsługę błędów. Może nawet doda set -euo pipefail. Wygląda lepiej. Czasem naprawdę jest lepiej. Tylko że lepszy kod nie zawsze oznacza bezpieczniejszą zmianę.

Bo problemem nie jest wyłącznie jakość skryptu. Problemem jest tzw. blast radius. Co ten skrypt może usunąć? Co może nadpisać? Co się stanie, jeśli źródło będzie puste? Co się stanie, jeśli punkt docelowy będzie niezamontowany? Co jeśli –delete zsynchronizuje pustkę? Co jeśli poprawka AI zmieni kolejność operacji i nagle „bezpieczniejsza wersja” zachowa się inaczej niż stara?

Często wygląda to tak: „AI, popraw skrypt, kopiuj na produkcję, odpal”. To jest szybkie. Tak samo szybkie, jak wciśnięcie Enter w złym terminalu.

Rozsądny proces jest nudniejszy i dlatego lepszy:

Najpierw statyczna analiza. ShellCheck dla basha. PSScriptAnalyzer dla PowerShella. Proste narzędzia, które nie mają humorów, nie próbują być kreatywne i nie halucynują. Potem AI jako reviewer: opisz, co robi skrypt, wskaż miejsca ryzyka utraty danych, wypisz założenia, które muszą być prawdziwe, zaproponuj minimalne zmiany. Minimalne, nie „przepisz wszystko na aktualnie sexy framework”.

Dobry prompt to nie: „napraw”. Dobry prompt to: „opisz działanie, wskaż ryzyka, zaproponuj najmniejszy patch, nie zmieniaj semantyki bez wyraźnego oznaczenia tego jako decyzji człowieka”.

Potem diff. Co się zmieniło? Czy zmiana dotyczy tylko walidacji wejścia, czy też zmienia logikę usuwania? Czy dodaliśmy dry-run? Czy możemy odpalić skrypt w trybie read-only? Czy logujemy działania? Czy umiemy zatrzymać drugi równoległy run lockiem?

Potem test, ale na kopii danych. Na pustym katalogu. Na braku mounta. Na braku miejsca. Na przerwanym transferze. Na ścieżce ze spacją. Na zmiennej, która nie jest ustawiona. To są nudne testy, ale one odpowiadają na pytanie, czy skrypt faktycznie przeżyje rzeczywistość.

I dopiero potem decyzja: wdrażamy? Wdrażamy etapami? Czy tylko dokumentujemy ryzyko i planujemy większą przebudowę?

W tym wszystkim AI jest naprawdę użyteczna. Potrafi szybko wyjaśnić stary kod. Potrafi zauważyć, że rm -rf “$DIR”/* przy pustym albo źle ustawionym DIR jest proszeniem się o kłopoty. Potrafi zaproponować lockfile, trap, walidację mountpointa, tryb dry-run. Potrafi przygotować opis dla change requestu. Ale AI nie wie, czy ten katalog jest naprawdę backupem, czy ostatnią kopią czegoś, czego nikt nie umie odtworzyć.

W praktyce warto jeszcze rozróżnić dwie rzeczy: refaktoryzację i redukcję ryzyka. AI bardzo lubi refaktoryzować. Dostaje stary skrypt, widzi chaos i „chce” zrobić porządek. Funkcje, zmienne, wspólne helpery, ładniejsze logowanie. Tylko że przy skryptach administracyjnych pierwszym celem często nie jest elegancja. Pierwszym celem jest to, żeby nie usunąć danych, nie wyciąć produkcji i nie zmienić zachowania bez wiedzy operatora.

Dlatego pierwsza poprawka powinna być mała. Dodać sprawdzenie mountpointa. Dodać blokadę przed pustym katalogiem. Dodać dry-run. Dodać logowanie. Dodać lock. Nie przepisywać całego skryptu na nową architekturę, jeśli nie ma na te zdarzenia testów. Duża zmiana bez testów zwiększa niepewność, nawet jeśli kod wygląda lepiej.

AI może pomóc przygotować dwie ścieżki: „minimalny patch bezpieczeństwa” i „docelowa refaktoryzacja”. To jest bardzo praktyczne. Minimalny patch można wdrożyć szybciej, bo zmniejsza konkretne ryzyko. Refaktoryzację planujemy osobno, z testami i właścicielem takiego procesu. Dzięki temu AI nie staje się pretekstem do wielkiej przebudowy pod presją.

Warto też pamiętać o dokumentacji po zmianie. Stary skrypt często nie ma opisu, bo „wszyscy wiedzieli”. Po review z AI można od razu wygenerować krótki runbook: co robi, kiedy działa, jakie ma wejścia, jakie warunki bezpieczeństwa sprawdza, jak odpalić dry-run, gdzie są logi i jak cofnąć zmianę. To często jest większa wartość niż sam patch.

Krótko mówiąc: AI może zrobić draft review. Admin powinien zrobić test, diff i podjąć decyzję, co dalej.

Stare skrypty są często bardziej krytyczne, niż wyglądają. Nie mają UI, nie mają właściciela produktu, nie mają ładnej dokumentacji. Mają za to uprawnienia, cron i dostęp do danych. Jeśli AI ma pomagać przy ich poprawianiu, to świetnie. Ale nie jako generator kodu do natychmiastowego odpalenia, tylko jako twórca, recenzent, tłumacz, asystent testów, wsparcie przed wdrożeniem i w trakcie wdrożenia zmian. 

Bo skrypt po poprzedniku zwykle działa. Aż do dnia, w którym zmieni się jeden z warunków.

~Maciej Szymczak