Files
kacperor 6ed7a7f4d2 Init repo infra + poprawki runbooka bootstrap i HANDOFF
- Krok 9 (tmux): tee -> tee -a (nie nadpisuj configu), dodano
  focus-events on, poprawiono nazwę sesji na "bootstrap"
- Krok 10: struktura katalogów odzwierciedla stan faktyczny
  (/srv i /srv/infra już istnieją, brakuje apps i data)
- Krok 12: Claude Code oznaczony jako wykonany 20-08-2026,
  instalator natywny bez Node.js
- Nowy Krok 14: audyt po bootstrapie (SSH, ufw, fail2ban,
  unattended-upgrades, swap, Docker, porty, klucze)
- HANDOFF.md: poprawiona numeracja sekcji 6
2026-08-20 15:53:51 +00:00

122 lines
3.6 KiB
Markdown

# 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ć