DevOps, CI/CD und Infrastruktur — ohne Fanatismus.
Eine Infrastruktur, die Ihr künftiger Administrator pflegen kann. Keine 40-zeiligen Helm-Charts für eine kleine Site, keine Microservices um der Microservices willen. Docker, einfaches CI, verständliches Monitoring, Runbooks im Repository. Es funktioniert — und funktioniert weiter, wenn wir wieder weg sind.
§ 09.1 Was wir machen
Auto-Build und Deployment
GitHub Actions, GitLab CI, eigener Runner — passend zu Ihrem Git. Tests, Linting, Build, Deploy, Rollback. Kein „Push auf Master und Daumen drücken".
Containerisierung
Dockerfile, Compose für lokal, Production-Images. Multi-Stage-Builds, kleine finale Images, schnelles Deployment.
K8s — wenn er nötig ist
Für Anwendungen, die Orchestrierung wirklich brauchen: Auto-Scaling, Rolling Updates, Blue-Green, Canary. Für kleine Projekte ist Docker Compose auf einem Server günstiger und einfacher.
Wechsel zwischen Providern
Von AWS / GCP / DigitalOcean / Heroku auf Hetzner / Selectel / Yandex Cloud — und zurück. DB-Migration ohne Downtime, DNS-Umzug, Verifikation, Rollback bei Problemen.
Monitoring und Alerts
Prometheus + Grafana, Loki für Logs, Sentry für Fehler. Alerts in Telegram, Vorfall-Prioritäten. Damit Probleme nicht zuerst der Kunde sieht und erst danach Sie.
Infrastructure as Code
Terraform, Ansible, Pulumi. Die ganze Infrastruktur in Git: reproduzierbar, reviewbar, rollback-fähig.
§ 09.2 Provider und Stack
Standard: Hetzner (günstig und zuverlässig für europäische Projekte), Selectel / Yandex Cloud (für russische), Cloudflare (CDN, R2, Workers).
Manchmal: AWS, GCP, Fly.io, Railway, Vercel — wenn die Aufgabe ihren Spezifika entspricht.
Was wir vermeiden: Heroku (zu teuer), nacktes FTP (unsicher), „packen wir auf unseren Linux-Server und aktualisieren ihn nie" (eine tickende Zeitbombe).
§ 09.3 Prinzipien
- Die Komplexität der Infrastruktur muss zur Größe des Teams passen. Kubernetes für ein Zwei-Personen-Team ist Overkill.
- Jede Änderung — über Code und Pull Request. Keine Anpassungen in Produktion per SSH.
- Backups werden regelmäßig getestet. „Wir machen Backups" und „wir können wiederherstellen" sind zwei sehr verschiedene Dinge.
- Monitoring wird vor dem Release eingerichtet, nicht nach dem ersten Datenverlust.
- Runbooks werden während des Setups geschrieben, nicht „dokumentieren wir später".
§ 09.4 Häufige Fragen
Uns wird Kubernetes empfohlen. Brauchen wir das wirklich?
Mit hoher Wahrscheinlichkeit nein, wenn Sie weniger als ein Dutzend Services und weniger als zwanzig Requests pro Sekunde haben. Docker Compose auf ein bis zwei VMs löst dieselbe Aufgabe für 10 % der Zeit und Kosten. Wir sagen ehrlich, wann k8s gerechtfertigt ist.
Können wir von AWS auf etwas Günstigeres umziehen?
Meistens — ja. AWS ist oft 3–5× teurer als Hetzner oder Selectel bei vergleichbarer Hardware. Wir rechnen Ihre Kosten durch, schätzen die Migration ab und entscheiden, ob es sich lohnt. Manchmal lohnt es sich auch nicht.
Wer wartet die Infrastruktur nach Ihnen?
Jeder, der mit Docker und Git umgehen kann. Konfiguration im Repository, Runbooks im README, keine „geheimen Skripte" auf unseren Laptops. Die Übergabe dauert ein paar Stunden.
Unsere Site ist down. Können Sie einmalig einspringen?
Ja, wenn die Aufgabe klar ist. „Site liegt, Ursache unklar" — wir nehmen es an, diagnostizieren, reparieren, dokumentieren. Ein einmaliger Vorfall ist ein normales Arbeitsformat.
Beschreiben Sie,
was gerade wehtut.
hi@weiss.help ↗
Erstes 20-Minuten-Gespräch — kostenlos. Akute Vorfälle nehmen wir noch heute an.