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>
This commit is contained in:
Maciej Pienczyn 2026-01-15 07:35:05 +01:00
parent 637ec2fc75
commit 07171b46b7
2 changed files with 109 additions and 1 deletions

View File

@ -27,7 +27,8 @@ nordabiz/
├── scripts/ # Narzędzia Node.js ├── scripts/ # Narzędzia Node.js
└── docs/ # Dokumentacja └── docs/ # Dokumentacja
├── architecture/ # Architektura systemu (diagramy, przepływy) ├── architecture/ # Architektura systemu (diagramy, przepływy)
└── INCIDENT_REPORT_20260102.md ├── INCIDENT_REPORT_20260102.md
└── INCIDENT_REPORT_20260115.md
``` ```
## Dokumentacja architektury ## Dokumentacja architektury
@ -95,6 +96,13 @@ Kompletna dokumentacja architektury systemu dostępna w katalogu `docs/architect
- Brave Search: 2,000 req/miesiąc - Brave Search: 2,000 req/miesiąc
- Szczegóły: [06-external-integrations.md](docs/architecture/06-external-integrations.md) - Szczegóły: [06-external-integrations.md](docs/architecture/06-external-integrations.md)
**Uruchamianie skryptów na produkcji (KRYTYCZNE!):**
- SSH timeout NIE oznacza że komenda nie została wykonana!
- ZAWSZE sprawdź czy poprzedni proces nie działa przed ponowną próbą: `ps aux | grep <skrypt>`
- Dla długich operacji używaj `nohup` lub `screen`
- Przy problemach z SSH użyj QEMU guest agent: `ssh root@10.22.68.123 "qm guest exec 249 -- <komenda>"`
- Incydent: [INCIDENT_REPORT_20260115.md](docs/INCIDENT_REPORT_20260115.md)
## Technologie ## Technologie
| Warstwa | Technologia | | Warstwa | Technologia |

View File

@ -0,0 +1,100 @@
# 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*