# Runbook 40 — utrzymanie

Serwer psuje się powoli i po cichu. Te przeglądy zajmują kilka minut i zapobiegają
sytuacji, w której o problemie dowiadujesz się od użytkownika.

---

## Przegląd tygodniowy — 5 minut

```bash
df -h /                       # < 75%
docker system df              # co rośnie
docker ps -a                  # nic w restart loop
free -h                       # swap w użyciu? coś przecieka
uptime                        # load average
sudo fail2ban-client status sshd
```

Czerwone flagi:

| Objaw | Co znaczy |
|---|---|
| Dysk > 75% | czas na sprzątanie, nie za tydzień |
| Kontener z rosnącym `RESTARTS` | crash loop — sprawdź logi |
| Swap mocno zajęty przy 12 GB RAM | wyciek pamięci w którymś kontenerze |
| Skok liczby banów fail2ban | ktoś się interesuje maszyną |

---

## Przegląd miesięczny — 30 minut

### Aktualizacje systemu

```bash
sudo apt update
apt list --upgradable
```

Zanim `upgrade`: **snapshot OVH.** Potem:

```bash
sudo apt upgrade -y
ls /var/run/reboot-required 2>/dev/null && echo "wymagany restart"
```

Restart robimy świadomie, po snapshocie, nie w środku pracy.

### Aktualizacje obrazów

Obrazy są przypięte do wersji, więc `pull` sam nic nie podniesie — i o to chodzi.
Podnoszenie wersji to świadoma decyzja:

1. Sprawdź changelog obrazu pod kątem breaking changes
2. Podnieś tag w `compose.yaml`
3. Snapshot
4. `docker compose pull && docker compose up -d`
5. Weryfikacja: `curl -I`, logi, `docker compose ps`
6. Commit

Jedna usługa naraz. Aktualizacja pięciu rzeczy jednocześnie oznacza, że przy awarii
nie wiesz, która zawiniła.

### Sprzątanie dysku

```bash
docker system df
docker image prune -a          # bezpieczne
docker builder prune           # zwykle najwięcej odzyskuje
sudo journalctl --disk-usage
sudo journalctl --vacuum-time=30d
```

Wolumeny — **nigdy hurtem**:

```bash
docker volume ls -f dangling=true
# sprawdź każdy, potem docker volume rm <nazwa>
```

### Bezpieczeństwo

```bash
sudo journalctl -u ssh --since "1 month ago" | grep -i "accepted" | tail -30
sudo cat /home/ubuntu/.ssh/authorized_keys        # tylko znane klucze?
sudo ufw status verbose                            # tylko 22/80/443?
docker ps --format "table {{.Names}}\t{{.Ports}}"  # nic na 0.0.0.0?
```

Ostatnia komenda jest ważniejsza, niż wygląda. Opublikowany port kontenera na
`0.0.0.0` omija ufw i jest widoczny z internetu — a `ufw status` tego nie pokaże.

### Certyfikaty

```bash
echo | openssl s_client -connect git.dfkk.cloud:443 2>/dev/null | \
  openssl x509 -noout -dates
```

Odnowienie następuje automatycznie ~30 dni przed wygaśnięciem. Jeśli zostało
mniej niż 14 dni — coś się zacięło, sprawdź logi Traefika i klucze API OVH.

### Dokumentacja

- [ ] `SERVER.md` zgodny ze stanem faktycznym?
- [ ] Lista braków w `SECURITY.md`, sekcja 8 — coś do odhaczenia?
- [ ] Repo `infra` zacommitowane i zmirrorowane na GitHub?

---

## Przegląd kwartalny

- [ ] **Test odtworzenia z backupu.** Nie „sprawdzenie, że plik istnieje" —
      faktyczne przywrócenie danych i weryfikacja, że są kompletne.
      Backup, którego nie odtworzyłeś, to założenie, nie zabezpieczenie.
- [ ] Rotacja tokenów API (OVH, GitHub, SMTP)
- [ ] Przegląd kluczy SSH — czy wszystkie urządzenia z listy nadal istnieją i są Twoje
- [ ] Przegląd projektów: czy wszystko, co działa, jest jeszcze potrzebne?
      Nieużywana usługa to zajęty dysk, otwarta powierzchnia ataku i pakiety,
      których nikt nie aktualizuje.
- [ ] Weryfikacja, czy `CLAUDE.md` odpowiada temu, jak faktycznie pracujemy —
      jeśli zasada jest regularnie omijana, trzeba ją zmienić albo zacząć stosować