Infra Doctrine – Autonomie, Scale & Ops Exzellenz

Ergänzt das 00_Meta/Manifest und macht klar, wie wir Infrastruktur betreiben, ohne von Fremdplattformen abhängig zu sein. Owner: Ops Captain · Deputies: Server Pilot, Data Platform Lead.

1. Zweck & Scope

• Autonomie: Core-Services (Panel, Game Nodes, Bots, Datenplattform) laufen auf von uns kontrollierten Maschinen (Colo/Dedicated). SaaS nutzen wir nur für Austauschbare (Status Page, Alerts).
• Scale by Design: Alles wird so dokumentiert, dass wir 1 → 20 Server über denselben Blueprint ausrollen können (IaC + Observability + Runbooks).
• Community Impact: Jede Infra-Entscheidung dient Member Experience, Creator-Schutz und Vertrauen (siehe Vision 2026, Regelwerke/Privacy-Notice).

2. Leitprinzipien

1. Code before Clicks – Infrastrukturänderungen kommen aus Repos (Terraform/Ansible) → Templates/Server-Change-Template → Deploy.
2. Vendor Agnostic – Keine Abhängigkeit von proprietären Panels/Cloud-Features, die sich nicht self-hosten lassen. Datenexporte sind Pflicht.
3. Defense in Depth – Netzsegmente, Secrets, Monitoring, Backups. Kein alleinstehender Server ohne Observability (siehe 04_Infrastruktur/Server Setup & 04_Infrastruktur/Incident Playbook).
4. Forward Deployed Pods – Plattformkern liefert Templates; Mission Pods passen sie an Games an und dokumentieren Lessons im 03_Rollen/Lessons Hub.
5. Operational Transparency – Auslastung, Kosten, Incidents werden monatlich im Council geteilt (verlinkt nach 07_Naechste_Schritte/State of the Guild Deck).

3. Layered Architecture

4. Unabhängigkeits-Playbook

• Hardware Mix: 70 % Dedizierte Server/Colo (Leistung + Datenhoheit), 30 % Cloud Burst (Events). Für jedes Cloud-Asset muss ein „Bring-Home“-Pfad dokumentiert sein.
• Mirrors & Escape Hatches: Automatische Backups (PBS/S3), Config Dumps, Export-Skripte für Bots und Metrics, damit ein Provider-Wechsel < 7 Tage möglich ist.
• License Hygiene: Nur Open-Source oder kaufbare One-Time Licenses. Bei SaaS (z. B. BetterStack) wird Self-Hosted Alternative benannt (Uptime Kuma) und funktionsfähig gehalten.
• Network Sovereignty: Eigene DNS bei demselben Registrar, IPv4/6 Adressen dokumentiert. Notfall-Liste mit Support-Kontakten der Provider.
• Dependency Register: Tabelle im Ops Repo: Dienst → Owner → Hosting → Exit-Plan. Monatscheck im 00_Meta/Manifest#Operating Rhythm (CEO-Perspektive).

5. Skalierungsmodell (10–20 Server)

1. Capacity Model: Spreadsheet + Grafana-Dashboard GGN-Capacity zeigen CPU/RAM-Auslastung, „Time to 80 %“. Ab 65 % Auslastung → Pre-order nächster Node.
2. Node Archetypes: Control Tower, Sandbox, Survival, Competitive, Experiment (siehe 00_Meta/Manifest#Server-Archetypen (V1)). Neue Server müssen einem Archetyp entsprechen oder einen neuen per Council ADR definieren.
3. Deployment Packs: Jede Node-Klasse hat ein Pack (Terraform Vars, Ansible Playbook, Monitoring Dashboards, Runbook). Packs liegen im Git Repo infra/manifests.
4. Rollout Ritual:
   • Draft Change → Review (Ops Captain + Mission Lead)
   • Staging Deploy (wenn vorhanden)
   • Production Deploy
   • Post-Deploy Check (Monitoring green, Security scan)
   • Documentation Update (Notes/node0X.md, Templates/Server-Change-Template)
5. Lifecycle: Commission → Active → Warm Standby → Sunset. Sunset bedeutet: Backups archivieren, DNS entfernen, Costs/Tickets schließen, Lessons in 03_Rollen/Lessons Hub.

6. Automation Stack

• Terraform Modules: DNS, Proxmox/LXC, Pterodactyl Nodes, Prometheus Stack. Module katalogisiert in infra/terraform/README.
• Ansible Playbooks: OS Hardening, Docker Setup, Bot Deployment, Backup Agents. Playbooks signiert; CI lint per ansible-lint.
• GitHub Actions Pipelines:
  • plan Job auf PR → Terraform Plan, Ansible Dry Run.
  • deploy Job nur via Manual Approval (Ops Captain).
  • Secrets via OIDC + Vault token exchange.
• Config Drift Checks: Nightly job ruft terraform plan + ansible --check gegen alle Nodes, posted Delta in #ops-alerts.
• Inventory Source of Truth: inventory.yaml + hosts.csv (synced). Wird von Runbooks, Monitoring, On-Call benutzt.

7. Observability & Ops

• Golden Signals: Latency, Traffic, Errors, Saturation für Panel, API, Game Ports.
• Tracing & Logs: Loki Stack sammelt Panel Logs, Game Server stdout/stderr, Bot Logs. Retention 14 Tage, Critical 90 Tage.
• Alerting Policy: Severity 1 = Incident Bridge + Council, Severity 2 = Ops Channel + Status Update, Severity 3 = Async Backlog. Siehe 04_Infrastruktur/Incident Playbook.
• SLOs:
  • Panel Uptime 99.3 % / Monat.
  • Game Nodes 99 % / Node, 0 Major incidents ohne Postmortem.
  • Ticket Bots Response < 5 Min.
    SLO-Reviews laufen im Monthly Manifest Check-In.
• Runbooks: Jede Service-Gruppe pflegt Troubleshooting Steps (DNS, Wings, Game-specific). Runbooks liegen neben Service Repo und verlinken ins Meeting Template.

8. Security & Access

• Identity: SSH Keys via ssh-ca gg-n + short-lived certs. Panel logins SSO (Keycloak) oder TOTP.
• Secrets: SOPS + age Files, stored encrypted in Git. Rotationsplan quartalsweise (siehe Risk Register).
• Network: Default Deny Firewall, Ports per Service. Private mgmt network via Tailscale. Game Ports offen via ufw allow <port>.
• Audits: Halbjährliche Security Review (Logs, Access, Backups). Findings → Risiken und Gegenmassnahmen.
• Compliance Prep: DSGVO/Privacy Mapping – wo liegen Daten, wer hat Zugriff, Retention. Data Processing Agreements archiviert in Legal/.

9. Execution Roadmap (2025)

10. ToDos & Ownership

• infra/terraform Repo initialisieren + Module für Panel + Nodes (Owner: Ops Captain, Due: Feb 10).
• Inventory Template (inventory.yaml) anlegen und in 04_Infrastruktur/Server Setup verlinken (Owner: Server Pilot).
• Config Drift Workflow (GH Actions) einrichten (Owner: Tech Lead Deputy).
• Exit-Pläne für alle SaaS (BetterStack, Ticket Tool) dokumentieren (Owner: Ops Captain + Player Support Lead).
• Monthly Ops Report Template → Templates/Meeting-Template integrieren (Owner: Data Platform Lead).

↩ 04_Infrastruktur/Server Setup · 00_Meta/Manifest · 04_Infrastruktur/Data Platform · 04_Infrastruktur/Incident Playbook