nordabiz/docs/INCIDENT_REPORT_20260115.md
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

101 lines
3.1 KiB
Markdown

# 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
1. **06:20** - Pierwsza próba uruchomienia skryptu `fix_google_news_images.py` przez SSH
2. **06:26** - Druga próba (timeout SSH, ale proces się uruchomił)
3. **06:30** - Trzecia próba (timeout SSH, kolejny proces)
4. **06:39** - Alert Zabbix: CPU VM 249 > 85% przez 5 minut
5. **06:41** - Diagnostyka przez QEMU guest agent
6. **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
1. Diagnostyka przez SSH do Proxmox (10.22.68.123)
2. Użycie QEMU guest agent do sprawdzenia procesów: `qm guest exec 249 -- ps aux`
3. Zabicie procesów: `qm guest exec 249 -- pkill -f 'fix_google_news_images.py'`
4. 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:**
```bash
ssh root@10.22.68.123 "qm guest exec 249 -- <komenda>"
```
## Akcje do wykonania
- [x] Zabić procesy obciążające CPU
- [x] Zweryfikować działanie strony
- [x] 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*