Analiza p24-infra — Mapa Procedur, Priorytetów i Automatyki

Wersja: 2026-06-27
Przeznaczenie: Dokument roboczy — przegląd strategiczny, mapa obszarów operacyjnych, inwentarz zdarzeń i mechanizmów samokontroli/samoleczenia.

1. Cele i priorytety p24-infra

Misja

p24-infra utrzymuje przy życiu platformę Ecotrans i jej ekosystem satelitarny (BrandPilot, Art Agency, personal brand). Rola: administrator systemów + oficer bezpieczeństwa + DevOps manager — działa autonomicznie, eskaluje tylko gdy brakuje autoryzacji, narzędzi lub decyzji architektonicznych.

Priorytety operacyjne (malejąco)

Prio	Cel	Definicja sukcesu
P1	Ciągłość produkcji (Pinbox24 / bms-1)	Uptime ≥ 99,5 % · żaden incydent dyskowy niezauważony > 15 min
P1	Bezpieczeństwo danych	Żaden sekret w git · backupy MongoDB < 26 h · SOPS na każdym sekrecie
P1	Monitoring stack (vps-i1)	Prometheus/Alertmanager działający · alerty dostarczane < 5 min
P2	Automatyzacja n8n (bms-4)	Kolejka robocza < 100 zadań · wykonania < 5 % błędów / dobę
P2	Compliance EU AI Act	Rejestr `dev_r_ai_systems` aktualny · audit `eu_ai_act_check` zielony
P2	Rotacja credentiali	Żaden klucz `auto_rotate=true` nie przekroczył deadline
P3	WAHA gateway (vps-h1)	Sesja WhatsApp aktywna · brak `504` na webhookach
P3	Dokumentacja (dev_r_services)	Każdy aktywny element z `compliance_workbook = 'yes'`
P3	Koszty	Całkowite < 700 EUR/mies. · alerty koszt-spike < 24 h od zdarzenia

2. Utrzymanie infrastruktury

2.1 Monitorowanie

Architektura 4-warstwowa:

Warstwa 1 (ciągła, sekunda):   Prometheus → Alertmanager → email/Discord/Telegram
Warstwa 2 (co 2 h):            GitHub Actions health-check.yml → issue p24-infra-nc-alert
Warstwa 3 (co noc, 00:30 UTC): Nightly AI triage (nightly-devops-triage.yml) → P1/P2/P3 issues
Warstwa 4 (co godzinę):        Hourly triage (cron bms-4, claude agent) → auto-fix / AI-Dev / human

Co jest monitorowane:

Obszar	Narzędzie	Alerty
CPU / RAM / disk (vps-i1, vps-h1)	node_exporter	HighCPU >80 % / 5 min, HighMem >85 %, LowDisk <15 %
Kontenery Docker	cAdvisor	ContainerCrash, HighRestarts >2/h
Supabase queue depths	queue-exporter :9200	QueueDeep >1000, ExporterDown
Wolne zapytania SQL	pg-stats-exporter :9201	SlowQueryCount spike
Backupy Wasabi	backup-exporter :9220	BackupStale >26 h
Koszty SaaS	cost-exporter :9210	CostSpike >threshold
Wiek rotacji credentiali	credential-exporter :9230	RotationOverdue / RotationCritical
HTTP endpointy	blackbox exporter	ProbeDown, HighLatency
Vercel deployments	vercel-exporter	DeployFailed
Silniki AI	ai-workers rule	ModelCallError spike
Certyfikaty TLS	Caddy auto-renew + alert rule	CertExpiresIn14d (spec-12 pending)

Znane luki monitoringu (otwarte):

brak node_exporter na bms-1, bms-2, bms-3 → dysk i RAM tych serwerów niewidoczne w Prometheusie
stan sesji WAHA (nie tylko HTTP 200)
pass/fail nightly triage nie jako metryka Prometheus → historia gubi się przy zamknięciu issue

Zasady priorytetu alertów:

Severity	Czas odpowiedzi	Kanał
Critical (P1)	natychmiast	email Mailgun + Telegram page + GitHub issue label `bug`
Warning (P2)	4 h grupowanie	email digest
Info (P3)	digest dzienny	email

2.2 Pielęgnacja

Czynności utrzymaniowe cykliczne — kto robi / co / kiedy:

Częstotliwość	Czynność	Narzędzie / miejsce
Każda godzina	Triage nowych alertów, auto-fix Tier 1	cron bms-4 → hourly-triage claude agent
Co noc (00:30 UTC)	Pełne 11-fazowe sprawdzenie infrastruktury	`nightly-devops-triage.yml`
Co noc	Backup MongoDB (mongodump → Wasabi)	`backup-mongo.sh` na bms-2/3
Co noc	Backup Supabase + n8n + Grafana	`backup-supabase.yml`, `n8n-backup.yml`, `grafana-backup.yml`
Co tydzień (pon. 08:00 UTC)	Audit compliance EU AI Act	audit-engine `eu_ai_act_check`
Co tydzień	Rotacja credentiali (auto_rotate=true)	`credential-rotation.yml`
Co tydzień	Snapshot workflow n8n	`n8n-workflow-snapshot.yml`
Co miesiąc	Przegląd kosztów SaaS	cost-exporter dashboard + ręczny przegląd
Co miesiąc	Image scan CVE	`image-scan.yml`, `trivy-scan.yml`
Co miesiąc	Sprawdzenie restore backup	`verify-backup-restore.sh` (⚠️ ostatni >4 mies. temu — DŁUG)
Co kwartał	Audyt n8n credentiali (brak hardkodowania)	`n8n-secrets-audit.md`
Co kwartał	Rotacja kluczy Wasabi + SOPS	`docs/secrets-rotation-log.md`
Co rok	Przegląd EU AI Act + aktualizacja rejestru	`docs/eu-ai-act-compliance.md`

Dyżur manualny (human-action):

Zatwierdzanie GitHub invitations dla nowych AI-Dev agents
Re-auth Claude runner OAuth po wygaśnięciu (fallback po 2 nieudanych próbach Playwright)
Rotacja kluczy SSH (nieczęste, planowe)

2.3 Archiwizacja

Dane długoterminowe — gdzie i jak długo:

Dane	Lokalizacja	Retencja	Kompresja
Metryki Prometheus (raw)	vps-i1 `/prometheus-data/`	15 dni	—
Metryki Thanos (raw)	Wasabi `p24-infra/thanos/`	90 dni	brak
Metryki Thanos (5 min downsample)	Wasabi `p24-infra/thanos/`	180 dni	—
Metryki Thanos (1 h downsample)	Wasabi `p24-infra/thanos/`	365 dni	—
Logi kontenerów	Loki (vps-i1) → Promtail	kilka dni (spec 02, konfiguracja retencji TBD)
Logi serwera (wszystkie)	Mezmo (LogDNA)	~7 dni	—
MongoDB dump	Wasabi `p24-infra/`	90 dni	gzip
Backupy n8n PostgreSQL	Wasabi `p24-infra/`	TBD	—
PDF raporty fleet	Wasabi `p24-infra/pdfs/`	trwale	—
Snapshoty workflow n8n	GitHub `p24-infra` repo	trwale (git)	—
Historia issues / PR	GitHub	trwale	—
Logi rotacji credentiali	`docs/secrets-rotation-log.md` (git)	trwale	—

Zasada: dane operacyjne (logi, metryki high-res) mają krótką retencję. Dane audytowe i kopie zapasowe danych biznesowych — trwałe lub 90 dni minimum.

Znane braki archiwizacji:

retencja logów Loki niezdefiniowana (spec 02 pending)
brak automatycznego testu restore z Wasabi (ostatni drill >4 mies. temu → natychmiastowe działanie)

2.4 Compliance

Dwa reżimy compliance działające równolegle:

A. Infrastructure Standard (codzienny)

Każdy element w dev_r_services (Supabase) musi mieć:

Workbook ops (docs/{service}-operations.md)
Alert {Service}Down + {Service}HighRestarts + blackbox probe
Backup automatyczny dobowy → Wasabi
Procedura restore < 30 min, przetestowana
RLS włączone na wszystkich tabelach Supabase (nawet backend-only)
Jeśli AI-powered → wpis w dev_r_ai_systems z tier ryzyka

Audit: infra_docs_check → codziennie → tworzy issue przy luce.

B. EU AI Act (tygodniowy)

Deadline: 2026-08-02 (Annex III wchodzi w życie).

Rejestry AI:

dev_r_ai_systems — każdy system AI z klasyfikacją (prohibited / high-risk / limited / minimal)
docs/eu-ai-act-compliance.md — pełna dokumentacja zobowiązań

Trigger wysokiego ryzyka (Annex III.4 — NIE wdrażać bez pełnego checklist):

AI oceniający / rankingujący kierowców / pracowników
AI automatycznie alokujący zadania do ludzi
AI podejmujący decyzje o zatrudnieniu

Audit: eu_ai_act_check → każdy poniedziałek 08:00 UTC → issue na każdą lukę.

C. Secrets Compliance (ciągły)

Każdy sekret w SOPS (secrets/*.env.sops) — nigdy w git plain, nigdy w komentarzach
credential-exporter mierzy wiek rotacji → alert RotationCritical gdy przekroczono deadline
Log rotacji: docs/secrets-rotation-log.md — każda rotacja z potwierdzeniem synchronizacji u wszystkich konsumentów

2.5 Dokumentacja

Standard obowiązkowy przy każdej zmianie elementu infrastruktury:

Zaktualizuj dev_r_services (Supabase) — compliance_workbook, workbook_url, compliance_notes
Zaktualizuj lub stwórz docs/{service}-operations.md
Jeśli AI-powered → zaktualizuj docs/eu-ai-act-compliance.md §4 + dev_r_ai_systems
Jeśli problem może się powtórzyć → napisz playbook w docs/playbooks/<temat>.md

Hierarchia dokumentów:

docs/
├── analiza-infrastruktury.md        ← ten plik
├── infrastructure-overview.md        ← mapa techniczna (co gdzie działa)
├── infrastructure-standard.md        ← wymagania compliance każdego elementu
├── secrets-management.md             ← procedury SOPS+age
├── eu-ai-act-compliance.md           ← rejestr AI + zobowiązania regulacyjne
├── audit-engine.md                   ← spec audit-engine (living doc)
├── secrets-rotation-log.md           ← log każdej rotacji
├── {service}-operations.md           ← workbook per usługa (operacje, backup, restore)
├── servers/
│   └── {bms|vps}-operations.md       ← per serwer: stały spis kontenerów, ufw, SSH
├── playbooks/                         ← 108+ runbooków incydentowych
│   ├── static-api-key-incident-rotation.md  ← ZAWSZE czytaj pierwsze przy rotacji
│   ├── sops-windows-crlf.md          ← CRLF/BOM bug recovery
│   └── ...
└── improvements/                      ← backlog rozbudowy (15 specyfikacji P1-P3)

Zasada “Look First, Write After”:

Zanim naprawisz powtarzalny problem → sprawdź docs/playbooks/
Po naprawieniu problemu → napisz playbook zanim zamkniesz sesję

2.6 Rozbudowa

Backlog specyfikacji (priorytet P1→P3, ~14 dni roboczych łącznie):

#	Specyfikacja	Prio	Estym.	Status	Blokery
01	Backupy + test restore dla usług stanowych	P1	1,5 d	Propozycja	—
02	Centralne logi Loki + Promtail (retencja, Grafana)	P1	1 d	Aktywny (Loki działa)	—
04	IaC pełne (Ansible roles dla stanu VPS)	P2	3 d	Propozycja	spec 03 ✓
05	Synthetic monitoring — blackbox (TCP, ICMP, TLS)	P2	0,5 d	Propozycja	—
06	Konsolidacja health-check workflows	P2	0,25 d	Propozycja	—
07	Status page (Uptime Kuma)	P2	0,5 d	Propozycja	spec 05
08	Image CVE scan + auto PRs (Renovate/Trivy)	P2	1 d	Propozycja	—
09	SSH hardening (fail2ban na bms-2, no-root-login)	P2	1 d	Propozycja	spec 04
10	Dashboard “co gdzie działa”	P3	0,5 d	Propozycja	—
11	Dashboard śledzenia kosztów (Grafana)	P3	1 d	Propozycja	—
12	Alerty wygasania certyfikatów TLS	P3	0,25 d	Propozycja	spec 05
14	Wersjonowanie workflow n8n → git	P3	0,5 d	Propozycja	spec 03 ✓
15	Testy jednostkowe infra-code (dns-manager, queue-exporter)	P3	0,5 d	Propozycja	—

Sugerowana kolejność realizacji:

Tydzień 1:  spec-01 (backupy+restore), spec-06 (health-check konsolidacja)
Tydzień 2:  spec-05 (blackbox), spec-12 (cert alerty), spec-08 (CVE scan)
Tydzień 3:  spec-07 (status page), spec-04 (Ansible IaC)
Tydzień 4:  spec-09 (SSH hardening), spec-10/11 (dashboardy), spec-14/15 (dev quality)

3. Zdarzenia operacyjne

3.1 Zdarzenia powtarzalne — wykaz i procedury

Zdarzenia, na które mamy działający playbook i (często) automatyczną reakcję:

Obszar: Infrastruktura / Serwery

Zdarzenie	Playbook	Automatyka
Kontener Docker zatrzymany / restarting	`playbooks/container-restart.md`	✅ Hourly Tier 1: `docker restart`
Dysk ≥ 85 % na vps-i1 / vps-h1	`playbooks/disk-cleanup.md`	✅ Tier 1: `prune-disk.sh`
Dysk ≥ 95 % — krytyczny	`playbooks/disk-full-critical.md`	⚠️ Tier 3 (human)
OOM Kill detected	`playbooks/oom-auto-remediation.md`	⚠️ Alert + manual
CPU > 80 % przez > 5 min	`playbooks/high-cpu.md`	⚠️ Alert + manual
RAM < 500 MB dostępne	`playbooks/low-memory.md`	⚠️ Alert + manual
SSH timeout do VPS	`playbooks/ssh-timeout.md`	⚠️ Manual
Traefik / Caddy — stale iptables	`playbooks/vps-h1-traefik-iptables-stale-rules.md`	⚠️ Manual

Obszar: Monitoring

Zdarzenie	Playbook	Automatyka
Prometheus target DOWN	`playbooks/prometheus-target-down.md`	✅ Tier 2: AI-Dev SSH spawn
Prometheus config drift (reload needed)	`playbooks/prometheus-reload.md`	✅ Tier 1: `curl -X POST /-/reload`
Alertmanager nie doarcza maili	`playbooks/mailgun-smtp-fix.md`	⚠️ Manual
Grafana niedostępna	`playbooks/grafana-restart.md`	✅ Tier 1: `docker restart`
Backup exporter — brak statusu	`playbooks/backup-exporter-down.md`	✅ Tier 1: restart
Thanos sidecar — bloki nie uploadowane	`playbooks/thanos-upload-stall.md`	⚠️ Manual

Obszar: Sekrety i bezpieczeństwo

Zdarzenie	Playbook	Automatyka
Credential rotacja zaplanowana	`docs/secrets-rotation-log.md` + playbook per typ klucza	✅ `credential-rotation.yml` (auto_rotate=true)
Klucz API przypadkowo w chacie / logu	`playbooks/static-api-key-incident-rotation.md`	⚠️ NATYCHMIAST manual
SOPS plik uszkodzony (CRLF/BOM)	`playbooks/sops-windows-crlf.md`	⚠️ Manual (canary + recovery)
Certyfikat TLS wygasający	Caddy auto-renew	✅ Automatyczny (Caddy ACME)
SSH key expired / revoked	`playbooks/ssh-key-rotation.md`	⚠️ Manual
Claude runner auth expired (OAuth)	`playbooks/claude-runner-reauth.md`	✅ Playwright automation → Tier 3 fallback

Obszar: n8n i automatyzacja

Zdarzenie	Playbook	Automatyka
n8n worker crash	`playbooks/n8n-worker-restart.md`	✅ Tier 1: `docker restart`
n8n kolejka > 100 zadań	`playbooks/n8n-queue-backup.md`	⚠️ Alert + manual
n8n execution error > 5 % / dobę	`playbooks/n8n-execution-errors.md`	⚠️ Alert + manual
n8n API key rotacja (bms-4)	`playbooks/n8n/n8n-bms4-api-key-rotation.md`	⚠️ Manual (zero-downtime)
Dispatcher (CF Worker) 500	`playbooks/dispatcher-cf-worker-error.md`	⚠️ Manual → bug issue → Agent fallback
spawn-worker.sh exit 2	`playbooks/spawn-worker-exit-2.md`	⚠️ `bash -n` parse check

Obszar: MongoDB rs0

Zdarzenie	Playbook	Automatyka
PRIMARY failover (auto-election)	`playbooks/mongodb-primary-failover.md`	✅ rs0 auto-elect
Replication lag > 30 s	`playbooks/mongodb-replication-lag.md`	⚠️ Alert + manual
Arbiter disconnect (bms-4)	`playbooks/mongodb-arbiter-reconnect.md`	⚠️ Manual
MongoDB port 27017 otwarty na internet	`playbooks/mongodb-ufw-lockdown.md`	⚠️ Manual (ufw)
Utrata hasła admin rs0	`playbooks/mongodb-admin-password-recovery.md`	⚠️ Manual (emergency)

Obszar: WAHA gateway

Zdarzenie	Playbook	Automatyka
Sesja WhatsApp rozłączona	`playbooks/waha-session-restart.md`	✅ `waha-session-restart.yml`
Pairing code potrzebny	`waha-pairing-code.yml`	✅ GH Actions manual trigger
WAHA niedostępna (HTTP 503)	`playbooks/waha-down.md`	✅ Tier 1: restart container
Webhook HMAC mismatch	`playbooks/waha-hmac-mismatch.md`	⚠️ Manual (key check)

Obszar: Backup i odtwarzanie

Zdarzenie	Playbook	Automatyka
Backup MongoDB — niezgodność (stale alert)	`playbooks/mongodb-backup-stale.md`	⚠️ Manual
Wasabi key rotation	`playbooks/wasabi-key-rotation.md`	✅ `secrets-sync.yml` resync
Restore z Wasabi (drill)	`playbooks/verify-backup-restore.md`	⚠️ Manual (drill kwartalny)

3.2 Zdarzenia nowe — protokół pierwszej reakcji

Gdy zdarzenie nie pasuje do żadnego playbooku:

1. STOP  — nie próbuj naprawiać bez zrozumienia
2. OPISZ — stwórz GitHub issue w radieu/p24-infra (label: bug)
           Tytuł: "[Infra] <komponent> — <symptom>"
           Treść: co robiłeś, dokładny błąd/status HTTP, już podjęte kroki
3. DIAGNOZA — zbierz dowody (logi, metryki, stan kontenera) BEZ wyświetlania sekretów
4. WORKAROUND — użyj najbezpieczniejszego workaround, udokumentuj go w issue
5. ROOT CAUSE — po stabilizacji, znajdź przyczynę
6. FIX — wdróż poprawkę przez PR → main
7. PLAYBOOK — przed zamknięciem sesji: napisz docs/playbooks/<temat>.md
8. WERYFIKACJA — sprawdź czy stary stan się nie powtórzy (monitoring / alert)

Obszary i pierwsze kroki diagnostyczne (gdy nie ma playbooka):

Obszar zdarzenia	Pierwsze 3 kroki diagnostyki
Kontener / VPS	`docker ps -a` → `docker logs --tail=100 <name>` → `df -h`
Sieć / TLS	`curl -v https://<endpoint>` → Cloudflare dashboard → `caddy reload`
Supabase / DB	Check Supabase status page → `pg_stat_activity` → RLS policy review
n8n workflow	n8n execution log → `docker logs n8n --tail=200` → Redis `LLEN bull:*`
Credentials	Sprawdź wiek rotacji w SOPS → `credential-exporter` metryki → rotation log
GitHub Actions	CI log → runner status `gh run list` → `health-check.yml` log
Sekret ekspozycja	STOP czytania → `docs/playbooks/static-api-key-incident-rotation.md` NATYCHMIAST

Eskalacja gdy Claude nie może rozwiązać samodzielnie:

Brakuje autoryzacji do działania (konto zewnętrzne, OAuth flow)
Ryzyko utraty danych bez human review
Zdarzenie wymaga fizycznego dostępu
Nieznany stan repliki MongoDB przed rs.remove()

W tych przypadkach: Discord alert (P1/P2 webhook) + GitHub issue human-action + kontynuuj wszystko co nie blokuje.

3.3 Modyfikacja procedur — gdy playbook zawiódł

Gdy istniejący playbook okazał się błędny, niekompletny lub prowadzi do nowego problemu:

1. STOP wykonywania obecnego playbooka
2. UDOKUMENTUJ awarię procedury w komentarzu do GitHub issue:
   "Playbook <nazwa> krok N zawiódł: <dokładny efekt>"
3. OPRACUJ alternatywne podejście (bezpieczniejszy workaround)
4. Po stabilizacji — PR z poprawką playbooka:
   - Dodaj sekcję "Znane pułapki" lub "⚠️ UWAGA"
   - Zaktualizuj kroki które zawiodły
   - Dodaj "Prevention" jeśli jej brak był przyczyną
5. Jeśli playbook był używany przez automatykę Tier 1/2:
   - Dezaktywuj automatyczne wywołanie tymczasowo
   - Stwórz issue "Disable auto-trigger for <playbook>" z label: patch
   - Re-aktywuj dopiero po weryfikacji nowej wersji

Sygnały że procedura wymaga modyfikacji:

Playbook zakłada stan który już nie istnieje (np. stary kontener, deprecjonowane API)
Procedura działa ale powoduje alert “side-effect” (np. restart crashuje sesję WAHA)
Czas wykonania playbooka przekroczył zakładany (np. restore > 30 min)
Playbook jest używany jako workaround dla problemu z innym root cause

4. Samokontrola infrastruktury

Mechanizmy przez które infrastruktura sama ocenia swój stan:

4.1 Stały pomiar stanu (Prometheus)

Mechanizm	Co kontroluje	Próg alarmowy
`node_exporter`	CPU, RAM, dysk, I/O sieci (vps-i1, vps-h1)	>80% CPU, >85% RAM, <15% dysk
`cAdvisor`	Każdy kontener Docker (CPU throttle, restart count, pamięć)	>2 restarty/h
`queue-exporter`	Głębokość kolejek Supabase	>1000 zadań
`backup-exporter`	Wiek ostatniego backupu (poll statusu JSON z Wasabi)	>26 h
`credential-exporter`	Dni od ostatniej rotacji każdego klucza	Overdue / Critical per polityka
`cost-exporter`	Miesięczne wydatki Vercel, Supabase, Wasabi	Spike vs. baseline
`pg-stats-exporter`	Wolne zapytania w Supabase (pg_stat_statements)	Count slow_queries spike
`blackbox exporter`	HTTP/TCP endpointy (Grafana, n8n, Traccar, WAHA)	ProbeDown, >2 s latency
22 pliki reguł alertów	Syntetyzują metryki w zdarzenia operacyjne	Per reguła

4.2 Kontrole cykliczne AI (health cognition)

Mechanizm	Kiedy	Co sprawdza
`health-check.yml`	Co 2 h	HTTP probe 6 endpointów + 3 GH runners
`nightly-devops-triage.yml`	00:30 UTC	11 faz: Docker state (5 serwerów), MongoDB rs0, dysk (6 serwerów), Prometheus targets, stan alertów, n8n executions, Wasabi backupy, Supabase compliance, audit failures
Hourly triage (claude agent)	Co godzinę	Klasyfikacja issues → Tier 1 / Tier 2 / Tier 3
`prometheus-alerts-ai-triage.yml`	Trigger via Alertmanager	Klasyfikacja alertu AI → co zrobić
`infra_docs_check` (audit-engine)	Codziennie	`dev_r_services` compliance_workbook != ‘yes’
`eu_ai_act_check` (audit-engine)	Pon. 08:00 UTC	`dev_r_ai_systems` luki + deadline zbliża się
`cloudflare-security-check.yml`	Cyklicznie	Reguły WAF, SSL, cache
`image-scan.yml` / `trivy-scan.yml`	Co miesiąc	CVE w obrazach Docker
`pwd-rotation-check.yml`	Co tydzień	Czy rotacje credentiali nie zostały pominięte

4.3 Rejestr elementów (source of truth)

Rejestr	Lokalizacja	Co rejestruje
`dev_r_services`	Supabase (public schema)	Każdy kontener / usługa SaaS / skrypt / workflow — z compliance status
`dev_r_ai_systems`	Supabase (public schema)	Każdy system AI — risk tier, compliance checklist
`dev_r_projects`	Supabase (public schema)	Projekty ekosystemu
`dev_r_exporters_queues`	Supabase (public schema)	Kolejki monitorowane przez queue-exporter
`docs/secrets-rotation-log.md`	Git	Historia każdej rotacji credentiali
`audit.actions` / `audit.runs`	Supabase (audit schema)	Historia i harmonogram audytów

5. Samoleczenie infrastruktury

Mechanizmy przez które infrastruktura sama przywraca prawidłowy stan:

5.1 Automatyczne (bez interwencji)

Zdarzenie	Mechanizm samoleczenia	Czas reakcji
Kontener crashed	Docker `restart: unless-stopped` policy	< 30 s
Kontener crashed + Docker policy nie pomaga	Hourly Tier 1: `docker restart <name>` via SSH	< 1 h
Prometheus config drift	Hourly Tier 1: `curl -X POST /-/reload`	< 1 h
Dysk ≥ 85 % (vps-i1 / vps-h1)	Hourly Tier 1: `prune-disk.sh` (stare logi, nieużywane obrazy)	< 1 h
Credential overdue (auto_rotate=true)	Hourly Tier 1: trigger `credential-rotation.yml`	< 1 h
TLS certyfikat wygasa (Caddy)	Caddy ACME auto-renew (30 dni przed wygaśnięciem)	Automatyczny
MongoDB PRIMARY failover	rs0 auto-election (bms-2 / bms-3 z kworum bms-4)	< 10 s (election)
Promtail → Loki connection drop	Promtail auto-retry z backoff	< 5 min
n8n queue backup	Redis + n8n queue mode: retry z exponential backoff	Per workflow config
GitHub Actions runner down	Self-hosted runner service `claude-runner.service` → systemd restart	< 1 min

5.2 Wspomagane AI (Tier 2 — AI-Dev spawning)

Gdy Tier 1 nie rozwiąże problemu w ciągu ~1 h, hourly triage klasyfikuje issue jako Tier 2 i spawnuje AI-Dev workera:

Trigger	AI-Dev akcja	Nadzór
Prometheus scrape target DOWN > 2 h	SSH spawn worker → diagnoza + fix + PR	Brak (autonomiczny)
Docs compliance gap (`compliance_workbook = 'no'`)	Spawn worker → napisz workbook + PR	Brak
n8n workflow error pattern (nieznany)	Spawn worker → analiza + fix workflow	Brak
GH Actions workflow failure (flaky)	`auto-fix-gh-actions.yml` → AI-Dev fix	Brak
Nightly triage otworzy P2 issue	Spawn worker if pattern known	Nadzór po PR

SLA watchdog: Jeśli AI-Dev worker nie stworzy PR w ciągu 4 h → issue relabel na human-action → Telegram page do użytkownika.

5.3 Eskalacja do człowieka (Tier 3)

Samoleczenie kończy się i eskaluje gdy:

Warunek	Eskalacja
Tier 1 auto-fix zawiódł 2× z rzędu	Discord Critical + `human-action` issue
Dysk ≥ 95 % (prune-disk.sh nie wystarczył)	Telegram P1 page
OOM kill zatrzymał krytyczny kontener	Discord + issue
MongoDB PRIMARY count = 0 (brak kworum)	Telegram P1 NATYCHMIAST
Claude runner OAuth expired + Playwright fail 2×	Discord + `human-action`: manual re-auth
AI-Dev worker bez PR > 4 h	Telegram P2
Sekret wykryty w logu / chacie	STOP wszystkiego → rotation playbook

5.4 Samoleczenie — mapa przepływu

Zdarzenie
    │
    ▼
Prometheus alert / health-check issue
    │
    ▼
Hourly triage claude agent classifies
    │
    ├─── Tier 1 (auto-fix) ──────────────► SSH komenda → zamknięcie issue (resolved)
    │
    ├─── Tier 2 (AI-Dev) ───────────────► Spawn worker → diagnoza + PR → human review
    │                                      └─ > 4h bez PR → Tier 3
    │
    └─── Tier 3 (human) ────────────────► Discord/Telegram P1/P2 + human-action label
                                           └─ Człowiek interweniuje manualnie

6. Znane luki i zadania natychmiastowe

Luka	Severity	Akcja	Deadline
Restore test MongoDB nie wykonany > 4 mies.	KRYTYCZNA	Uruchom `verify-backup-restore.sh` na bms-2	Następna sesja
node_exporter brak na bms-1/2/3	Wysoka	Ansible role + Prometheus scrape target	Tydzień 1
Nightly triage health nie jest metryką Prometheus	Wysoka	Push gauge po każdym run → Grafana timeline	Tydzień 1
WAHA stan sesji niewidoczny w Prometheus	Wysoka	Custom exporter lub blackbox TCP probe	Tydzień 2 (spec 05)
Brak DR runbooka (co gdy bms-1 odpada)	Wysoka	Napisz `docs/playbooks/disaster-recovery.md`	Tydzień 2
health-check.yml spamuje Discord przy każdym runie	Średnia	Tylko notyfikacje przy zmianie stanu (spec 06)	Tydzień 1
n8n workflow nie wersjonowane w git	Średnia	spec 14	Kwartał

Dokument wygenerowany na podstawie pełnej eksploracji repo i CLAUDE.md / memory, 2026-06-27.
Aktualizować przy każdej zmianie architektury lub nowym obszarze operacyjnym.

p24-infra Docs

Explorer

analiza-infrastruktury