Maciej Pienczyn 07171b46b7 docs: Raport incydentu CPU + ostrzeżenia o uruchamianiu skryptów

- Dodano INCIDENT_REPORT_20260115.md dokumentujący incydent
  wysokiego CPU spowodowany wielokrotnym uruchomieniem skryptu
- Dodano ostrzeżenia do CLAUDE.md o uruchamianiu skryptów:
  - SSH timeout NIE oznacza nieudanego wykonania
  - Sprawdzaj procesy przed ponownym uruchomieniem
  - Używaj QEMU guest agent jako alternatywy

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

2026-01-15 07:35:05 +01:00

3.1 KiB

Raw Blame History

Raport incydentu - 2026-01-15

Podsumowanie

Parametr	Wartość
Data/Czas	2026-01-15, ~06:20-06:42 UTC
Czas trwania	~22 minuty
Serwer	NORDABIZ-01 (VM 249, 10.22.68.249)
Wpływ	Wysokie CPU (85%+), spowolnienie SSH
Status	Rozwiązany

Opis zdarzenia

Chronologia

06:20 - Pierwsza próba uruchomienia skryptu fix_google_news_images.py przez SSH
06:26 - Druga próba (timeout SSH, ale proces się uruchomił)
06:30 - Trzecia próba (timeout SSH, kolejny proces)
06:39 - Alert Zabbix: CPU VM 249 > 85% przez 5 minut
06:41 - Diagnostyka przez QEMU guest agent
06:42 - Procesy zabite, system wraca do normy

Przyczyna

SSH timeout do serwera NORDABIZ-01 nie oznaczał, że komendy nie zostały wykonane. Procesy uruchomiły się na serwerze, ale odpowiedź SSH nie wróciła do klienta (timeout during banner exchange).

W efekcie uruchomiono 3 instancje skryptu fix_google_news_images.py:

PID	CPU	RAM	Start
1005812	34.8%	33%	06:20
1006003	30.9%	26%	06:26
1006162	24.6%	21%	06:30

Łącznie: ~90% CPU, ~80% RAM

Objawy

SSH timeout (Connection timed out during banner exchange)
Zabbix alert: CPU > 85% przez 5 minut
Potencjalne spowolnienie strony (nie potwierdzone - health check działał)

Rozwiązanie

Diagnostyka przez SSH do Proxmox (10.22.68.123)
Użycie QEMU guest agent do sprawdzenia procesów: qm guest exec 249 -- ps aux
Zabicie procesów: qm guest exec 249 -- pkill -f 'fix_google_news_images.py'
Weryfikacja powrotu do normy

Wnioski i działania zapobiegawcze

Problem 1: SSH timeout nie oznacza nieudanego wykonania

Ryzyko: Przy timeout SSH, komenda może zostać wykonana ale odpowiedź nie wraca.

Rozwiązanie:

Zawsze sprawdzaj czy poprzedni proces nie działa przed ponowną próbą
Używaj nohup lub screen dla długich operacji
Przed ponownym uruchomieniem sprawdź ps aux | grep <skrypt>

Problem 2: Brak bezpośredniego dostępu SSH do VM 249

Przyczyna nieustalona: SSH timeout during banner exchange mimo otwartego portu 22.

Możliwe przyczyny:

Obciążenie CPU uniemożliwiło odpowiedź sshd
Problem z konfiguracją sshd po hardeningu
Ograniczenia firewall na poziomie VM

Do zbadania:

Sprawdzić logi sshd na VM 249
Zweryfikować konfigurację /etc/ssh/sshd_config
Sprawdzić czy fail2ban nie blokuje IP

Problem 3: Brak alternatywnego dostępu

Rozwiązanie wdrożone: Użycie QEMU guest agent przez Proxmox API

Komenda diagnostyczna:

ssh root@10.22.68.123 "qm guest exec 249 -- <komenda>"

Akcje do wykonania

Zabić procesy obciążające CPU
Zweryfikować działanie strony
Utworzyć raport incydentu
Zbadać dlaczego SSH nie działa bezpośrednio
Dodać ostrzeżenia do CLAUDE.md
Uruchomić skrypt poprawnie (jedna instancja)

Kontakt

Zabbix Dashboard: https://zabbix4norda.inpi.pl/zabbix/
Proxmox: https://10.22.68.123:8006/

Raport wygenerowany: 2026-01-15 06:45 UTC

3.1 KiB Raw Blame History