infra/docs/runbooks/40-utrzymanie.md

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

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

sudo apt update
apt list --upgradable

Zanim upgrade: snapshot OVH. Potem:

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

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:

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

Bezpieczeństwo

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

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ć