DevOps und Serverinfrastruktur

DevOps und Aufbau der Serverinfrastruktur: Builds, Ausrollen, Überwachung und Sicherungen so eingerichtet, dass ein Release Alltag ist und kein Ereignis. Wir übernehmen das als einzelne Aufgabe oder stellen einen Ingenieur in Ihr Team.

An die Infrastruktur denkt man zweimal: wenn ein Ausrollen einen ganzen Tag dauert und wenn etwas ausfällt. In beiden Fällen ist der Grund derselbe: Niemand hat entworfen, wie das Produkt gebaut, ausgerollt und beobachtet wird, es hat sich von selbst so ergeben.

Ziehen wir gleich eine Linie, denn beides wird oft verwechselt. DevOps ist aus der Systemadministration hervorgegangen, dasselbe sind sie deswegen nicht. DevOps ist Infrastruktur als Code und Einrichtung in großer Zahl über Terraform, Ansible und ähnliche Werkzeuge, die Strecke von Build und Auslieferung, Umgebungen, Überwachung und der Umgang mit Geheimnissen. Gebraucht wird das dort, wo viel Code entsteht und regelmäßig Releases anstehen. Die Systemadministration ist eine tragende Einheit: die Server und die Systeme darauf, gezielte Aufgaben, Vergabe und Entzug von Zugängen, der Betrieb des Laufenden, und in Unternehmen ohne eigene Fachkraft für Sicherheit häufig auch diese Rolle. Viele Administratoren üben ebenfalls einen Teil der DevOps-Aufgaben aus, verantworten aber anderes, und die eine Rolle durch die andere zu ersetzen kommt teuer.

Wir bringen die Infrastruktur in einen verständlichen Zustand. Sie wird in Code beschrieben, lässt sich also lesen, wiederholen und wiederherstellen, statt im Kopf eines einzelnen Menschen zu liegen. Bauen und Ausrollen laufen automatisch, deshalb hört ein Release auf, ein Ereignis zu sein. Die Überwachung ist so aufgebaut, dass Sie von einem Problem durch das Überwachungssystem erfahren und nicht durch Ihre Kunden, und dass Sie damit nicht zu uns kommen müssen: Wir erfahren von dem Vorfall an derselben Stelle.

Die Werkzeuge richten sich nach dem Maßstab und nicht nach einer Liste des Modischen. Terraform nehmen wir dort, wo Server schnell und in großer Zahl entstehen müssen. Ansible dort, wo ein Dienst eine gleichmäßige Leistung erreicht hat und neue Maschinen selten hinzukommen: Es richtet einen neuen Dienst mitsamt Schlüsseln und Zugängen in Ruhe ein. Beim Bauen ist es ebenso: Meist genügen GitLab CI oder GitHub Actions, und für manuelle Abläufe und komplexe Strecken richten wir Jenkins oder TeamCity ein.

Aktualisierungen ohne Ausfall sind eine eigene Arbeit. Beim Umzug von Silent Notary wurden die Container im laufenden Betrieb erneuert: Ein Mensch konnte sich in einem Bereich der alten Fassung befinden, auf die Startseite klicken und im neuen System landen, ohne den Übergang zu bemerken. Das ist fast immer möglich, die Frage sind allein das Geld und ob ein Ausfall für Sie tatsächlich untragbar ist.

Ein weiteres Gespräch, das man früh führen sollte, betrifft die Kosten. Die Cloud ist bequem und wächst unbemerkt: ungenutzte Festplatten, vergessene Kopien von Umgebungen, Maschinen für alle Fälle. Wir rechnen die Kosten zusammen mit der Einrichtung durch und zeigen, wo die Infrastruktur mehr kostet, als sie einbringt.

Die Infrastruktur läuft neben Backend, Serversoftware und Webentwicklung. Der Bereich lässt sich vollständig im Modell Outsourcing übergeben, oder ein Ingenieur kommt nach dem Modell Outstaffing in Ihr Team. Ist unklar, was mit einem laufenden System geschieht, beginnen Sie mit einem Audit. Von uns gebaute Infrastruktur trägt das Wallet, die Staking-Plattform und den Netzwerk-Explorer.

01

Was die Leistung umfasst

Jede Auswahl aus dem Folgenden lässt sich einzeln beauftragen.

Infrastruktur als Code

Server, Netze, Zugriffe und Umgebungen sind in einem Repository beschrieben. Terraform dort, wo Maschinen schnell und in großer Zahl entstehen müssen, Ansible für die gezielte Einrichtung von Diensten auf gefestigter Infrastruktur. Eine neue Umgebung entsteht wiederholbar und gleich und wird nicht erneut von Hand zusammengesetzt.

Bauen und Ausrollen

Automatisierte Builds, Tests, Ausrollen auf Knopfdruck und Rückabwicklung in Minuten. GitLab CI oder GitHub Actions für den Regelfall, Jenkins oder TeamCity dort, wo manuelle Schritte und komplexe Abläufe nötig sind. Getrennte Umgebungen für Entwicklung, Prüfung und Produktivbetrieb.

Containerisierung

Hier gibt es zwei Wege. Der einfache sind Docker und Docker Swarm, das genügt einem Produkt aus wenigen Diensten. Der aufwendige ist Kubernetes, wo die Einheit des Starts ein Pod ist und nicht ein einzelner Container, mit eigenen Regeln für Platzierung, Netz und Speicher. Solche Cluster lassen sich bequem über Rancher verwalten. Den Weg wählen wir nach der Zahl der Dienste, der Zahl der Projekte und der Last.

Eigene Plattform auf Proxmox

Wenn eigene Server nötig sind, richten wir Proxmox direkt auf der Hardware ein. Es ist eine Linux-Distribution auf Debian-Basis: Die Knoten werden zu einem Cluster verbunden, darin laufen virtuelle Maschinen oder Images. Sinnvoll dort, wo die Last gleichmäßig ist oder die Daten Anforderungen an die Vertraulichkeit mitbringen.

Überwachung und Benachrichtigungen

Metriken, Protokolle, Ablaufverfolgung und ein durchdachtes System von Benachrichtigungen. Der Wert liegt darin, die Entwicklung früh zu sehen: Langzeitprotokolle zeigen, wie sich die Last verändert und wo sich ein Problem aufbaut, damit der nächtliche Anruf mit der Nachricht vom Ausfall nicht mehr die wichtigste Informationsquelle ist.

Sicherungen und Wiederherstellung

Sicherungen nach Zeitplan, Ablage an einem getrennten Ort und regelmäßige Prüfung, dass sich eine Sicherung tatsächlich zurückspielen lässt. Eine ungeprüfte Sicherung ist keine Sicherung.

Umzug, Sicherheit und Kosten

Wechsel zwischen Plattformen und Clouds ohne Datenverlust, Abgrenzung der Zugriffe, Aufbewahrung von Geheimnissen, Aktualisierung der Systeme und Durchsicht der Rechnungen für die Infrastruktur.

02

Wie wir arbeiten

01
Audit der Infrastruktur

Wir sehen uns an, was ausgerollt ist, wie ausgeliefert wird, was überwacht wird und wo die Engstellen liegen. Das Ergebnis ist das Bild des Ist-Zustands und eine Liste der Risiken.

3-5 Tage
02
Plan und Kalkulation

Das Zielbild, die Reihenfolge der Arbeiten und eine Kalkulation nach Etappen. Zuerst schließen wir, was Ausfall oder Datenverlust droht.

1 Woche
03
Einrichtung

Infrastruktur als Code, die Build-Strecke, Umgebungen, Überwachung und Sicherungen.

ab 2 Wochen
04
Umzug und Prüfung

Umstellung in Teilen, Prüfung der Wiederherstellung und Übungen für den Ausfall, nicht nur auf dem Papier.

parallel
05
Betreuung

Aktualisierungen, Reaktion auf Benachrichtigungen, Bereitschaft und Aufarbeitung von Vorfällen.

laufend
03

Stack und Werkzeuge

LinuxProxmoxDockerDocker SwarmKubernetesRancherTerraformAnsibleGitLab CIGitHub ActionsJenkinsTeamCitynginxPrometheusGrafanaLoki
04

Fallstudien zu dieser Leistung

05

Häufige Fragen

DevOps verantwortet, wie ein Produkt gebaut, ausgerollt und beobachtet wird, dazu die Infrastruktur als Code und die Aufbewahrung der Geheimnisse. Gebraucht wird das dort, wo viel Code entsteht und regelmäßig Releases anstehen. Die Systemadministration kümmert sich um die Server und die Systeme darauf, um gezielte Aufgaben und um Zugriffe. Das sind benachbarte Rollen, und die eine ersetzt die andere nicht.

Ja, das ist ein häufiger Fall. Wir arbeiten mit Ihrem Team und Ihrem Code, bringen die Infrastruktur in Ordnung und übergeben sie samt Beschreibung.

Oft nicht, und wir sagen es offen. Kubernetes lohnt sich bei mehreren Diensten, spürbarer Last oder häufigen Releases, und mit ihm kommen auch die Menschen, die es betreuen. Einem kleinen Produkt genügen in der Regel Docker und Docker Swarm.

Wir rechnen beide Varianten durch. Die Cloud gewinnt am Anfang und bei Lastspitzen. Eigene Server gewinnen bei gleichmäßiger Last und dort, wo die Daten Anforderungen an die Vertraulichkeit mitbringen, und in diesem Fall baut man die Plattform bequem auf Proxmox.

Fast immer. Es ist eine Frage des Geldes und dessen, wie kritisch ein Ausfall für Sie ist: Abwärtskompatibilität, ein Plan für die Rückabwicklung und die Umstellung in Teilen kosten mehr als ein gewöhnliches Release. Wir besprechen das vor Arbeitsbeginn und nicht mittendrin.

Geheimnisse liegen in einem geschützten Speicher, Zugänge werden namentlich und im geringstmöglichen Umfang vergeben, jede Handlung bleibt im Protokoll. Nach Abschluss der Arbeiten werden unsere Zugänge geschlossen, Ihre bleiben bestehen.

Das regelt der Vertrag, und wir halten es in der Phase des Pflichtenhefts fest, noch vor Arbeitsbeginn. Die Konten bei den Anbietern werden auf Sie angemeldet, die Beschreibung der Infrastruktur liegt in Ihrem Repository. Nach Abschluss des Projekts gehen alle Arbeitsergebnisse und die Dokumentation samt den Rechten daran an Sie über.

Ja, in einer gesonderten Vereinbarung: Überwachung, Reaktion innerhalb eines vereinbarten SLA und die Aufarbeitung des Vorfalls im Anschluss.

06

Verwandte Leistungen

Besprechen wir Ihre Aufgabe?

Sagen Sie uns, was zu tun ist - wir melden uns mit einer Einschätzung, der Teamzusammensetzung und einem Plan für die ersten zwei Wochen.