Ein Release beansprucht fast den ganzen Freitagnachmittag. Nur ein Entwickler kennt alle Schritte, und wenn er in den Ferien ist, möchte niemand die Bereitstellung übernehmen. Der Ablauf liesse sich automatisieren. Vorher muss aber jemand herausfinden, welche Schritte nötig sind und warum der letzte Versuch gescheitert ist. Für eine solche Aufgabe kann sich DevOps-Beratung lohnen.
Sie unterstützt bei der Entwicklung, Bereitstellung und dem Betrieb von Software. In einem Unternehmen geht es um eine unzuverlässige Deployment-Pipeline, in einem anderen um den gesamten Betrieb einer Cloud-Plattform. In Angeboten stehen beide Aufgaben oft unter derselben Überschrift. Entsprechend genau sollte man beim Umfang hinsehen.
Gehen Sie ein konkretes Release durch
Sprechen Sie vor der Ausschreibung mit den Personen, die das letzte Release durchgeführt haben. Wo mussten sie warten? Für welche Schritte brauchten sie jemanden mit besonderen Zugriffsrechten? Wie hätten sie bei einem Fehler die vorherige Version wiederhergestellt?
Vielleicht läuft die Pipeline in zehn Minuten durch, während die Freigabe drei Tage dauert. Vielleicht bestehen alle Tests, aber die Testumgebung unterscheidet sich so stark von der Produktion, dass sich niemand auf das Ergebnis verlässt. Dafür braucht es unterschiedliche Lösungen. Beschreiben Sie einem möglichen Anbieter auch die umständlichen manuellen Schritte. Sonst fehlen ihm wichtige Informationen für sein Angebot.
Als Ausgangspunkt für die Messung eignen sich die Kennzahlen von DORA. Sie erfassen die Dauer von Änderungen bis zur Produktion, die Deployment-Häufigkeit, die Wiederherstellung nach fehlgeschlagenen Deployments sowie Fehler und Nacharbeiten. Betrachten Sie dabei jeweils eine Anwendung. Ein wöchentlicher Release kann für ein System ausreichen und bei einem anderen wichtige Änderungen unnötig verzögern.
Legen Sie fest, was Ihrem Team konkret helfen würde. Beim Freitagsrelease könnte das Ziel sein, dass ein zweiter Entwickler die Bereitstellung während der normalen Arbeitszeit übernimmt und einen Rollback vorführen kann. Das lässt sich bei der Abnahme überprüfen.
Was gehört ins Angebot?
Lassen Sie den Anbieter beschreiben, was er liefert und welche Arbeit bei Ihrem Team bleibt. Begriffe wie «Observability einführen» oder «Infrastructure as Code umsetzen» lassen viel Interpretationsspielraum.
Tabelle seitlich scrollen, um alle Spalten zu sehen.
| Aufgabe | Was im Angebot stehen sollte | Mögliche Prüfung bei der Abnahme |
|---|---|---|
| CI/CD | Build und Tests, Deployment-Rechte, Secrets, Freigaben und Rollback | Ein Teammitglied kann einen Release durchführen und ein fehlgeschlagenes Release zurücksetzen |
| Infrastructure as Code | Versionierte Konfiguration, wiederverwendbare Module, State-Speicherung und Vorgehen bei Updates | Ihr Team kann eine Umgebung neu erstellen und Änderungen vor der Ausführung prüfen |
| Cloud-Aufbau oder Migration | Konten, Netzwerk, Zugriffe, Migrationsablauf und Abschaltung der bisherigen Umgebung | Die Anwendung läuft nach der Umstellung, und die alten Ressourcen verursachen keine weiteren Kosten |
| Überwachung | Metriken, Logs, Traces, Alarme und Aufbewahrungsfristen | Ein Entwickler kann mit den erfassten Daten einer fehlgeschlagenen Anfrage nachgehen |
| Zuverlässigkeit | Verfügbarkeitsanforderungen, Backups, Wiederherstellung und Zuständigkeiten bei Störungen | Die Wiederherstellung wurde getestet, und jemand übernimmt eingehende Alarme |
| Sicherheit | Pipeline-Zugriffe, Abhängigkeitsprüfungen, Umgang mit Secrets und Behebung von Schwachstellen | Das Team weiss, wer Code freigeben darf und wer auf fehlgeschlagene Sicherheitsprüfungen reagiert |
| Cloud-Kosten | Zuordnung der Kosten, ungenutzte Ressourcen, Kapazitätswahl und Budgetalarme | Sie können die Rechnung nach Anwendung oder Team erklären und unerwartete Mehrkosten erkennen |
Mit OpenTelemetry lassen sich Betriebsdaten erfassen und an verschiedene Werkzeuge übermitteln. Damit ist die Überwachung noch nicht eingerichtet. Jemand muss entscheiden, welche Ereignisse gespeichert werden, wie lange sie verfügbar bleiben und welche Störung einen nächtlichen Anruf rechtfertigt. Diese Entscheidungen gehören ebenfalls zum Auftrag.
Für Sicherheitsanforderungen bietet das Secure Software Development Framework des NIST eine Grundlage. Fragen Sie den Anbieter, wie er konkret mit einer verwundbaren Abhängigkeit oder einem offengelegten Zugangsschlüssel umgeht. Dass ein Scanner in der Pipeline läuft, sagt noch wenig darüber aus, wer seine Funde bearbeitet.
Wenn Kubernetes vorgeschlagen wird
Lassen Sie sich erklären, wofür Ihre Anwendungen Kubernetes brauchen. Es kann helfen, viele containerisierte Anwendungen zu verteilen und zu betreiben. Zugleich entsteht ein Cluster, dessen Berechtigungen, Netzwerk, Updates und Wiederherstellung jemand pflegen muss.
Ein Beispiel liefert die adidas-Fallstudie der CNCF. adidas zog Giant Swarm für die Einrichtung und den Betrieb von Kubernetes hinzu, während sich die eigenen Entwickler auf den E-Commerce konzentrierten. Laut der 2019 veröffentlichten Fallstudie stieg die Release-Häufigkeit von einem Release alle vier bis sechs Wochen auf drei bis vier pro Tag. Beschrieben wird auch ein Plattformteam mit 35 Personen für rund 300 Entwickler.
Diese Teamgrösse gehört zur Einordnung dazu. Wenn Sie wenige Anwendungen mit einem kleinen Team betreiben, lassen Sie auch einen verwalteten Containerdienst oder eine Platform as a Service kalkulieren. In den Vergleich gehört der laufende Aufwand, insbesondere für Updates und Unterstützung ausserhalb der Arbeitszeit.
Ähnlich sollten Sie eine interne Entwicklerplattform beurteilen. Sie kann Teams ermöglichen, Umgebungen und Deployments selbst anzulegen. Allerdings müssen die Vorlagen gepflegt und die Mitarbeitenden eingearbeitet werden. DORA empfiehlt einen kleinen Einstieg. Wählen Sie zunächst einen Ablauf, der Ihren Entwicklern wiederholt Mühe macht. Verbessern Sie ihn und prüfen Sie, ob das Angebot genutzt wird, bevor Sie die Plattform ausbauen.
Vereinbaren Sie, was der Anbieter übernimmt und was bei Ihrem Team bleibt.
Mit welchen Kosten müssen Sie rechnen?
Bei Alpine Edge kostet DevOps-Engineering CHF 100 pro Stunde.
Für eine Aufwandsschätzung müssen wir wissen, welche Anwendungen und Umgebungen betroffen sind, was bereits vorhanden ist und wer die Zugriffe bereitstellt. Lassen Sie die erwarteten Stunden nach Aufgaben aufschlüsseln und vereinbaren Sie vor der Umsetzung eine Kostengrenze. Reviews, Dokumentation und Übergabe gehören in diese Planung.
Prüfen Sie beim Angebotsvergleich auch, wer die Arbeit ausführt. Arbeitet die Person, die die Architektur entwirft, an der Umsetzung mit? Wie viel Zeit müssen Ihre eigenen Mitarbeitenden einplanen?
Neben dem Beratungshonorar fallen laufende Kosten an, etwa für Build-Runner, verwaltete Datenbanken oder Log-Speicher. Während einer Migration bezahlen Sie unter Umständen alte und neue Umgebung gleichzeitig. Pikettdienst kann einen eigenen Vertrag erfordern. Lassen Sie sich deshalb neben dem Umsetzungspreis auch die erwarteten monatlichen Betriebskosten und die zugrunde liegenden Annahmen nennen.
Ein Festpreis braucht einen klaren Umfang: betroffene Anwendungen und Umgebungen, Schnittstellen, Migrationsablauf und Abnahmetests. Ist das noch offen, kann eine kurze Analyse die Grundlage für ein belastbares Angebot schaffen. Bei Abrechnung nach Aufwand sollten Sie vereinbaren, wie Sie die bisherigen Kosten und die verbleibende Arbeit regelmässig prüfen.
Welche Zusammenarbeit passt zu Ihrem Team?
Für eine einmalige Migration kann ein Projekt mit klar definiertem Ende genügen. Kennt Ihr Team die Architektur bereits, braucht aber Unterstützung bei einem Teil davon, bietet sich ein Spezialist an, der im Team mitarbeitet. Für die dauerhafte Übernahme des Betriebs ist eine andere Vereinbarung nötig.
Tabelle seitlich scrollen, um alle Spalten zu sehen.
| Form der Zusammenarbeit | Wann sie passt | Vor Vertragsabschluss klären |
|---|---|---|
| Analyse | Sie müssen das Problem vor der Umsetzung genauer verstehen | Welche Systeme werden untersucht, und entsteht daraus ein umsetzbarer Arbeitsplan? |
| Abgegrenztes Projekt | Ergebnis und Abnahme lassen sich beschreiben | Was passiert, wenn eine Abhängigkeit oder Migrationsannahme nicht stimmt? |
| Spezialist im Team | Sie brauchen Fachwissen oder vorübergehend mehr Kapazität | Wer steuert die Arbeit, und wie lernen Kollegen die spätere Wartung? |
| Laufender Betrieb durch den Anbieter | Sie möchten den Plattformbetrieb dauerhaft abgeben | Wer reagiert auf Störungen, was gilt ausserhalb der Bürozeiten, und wie ist ein Wechsel möglich? |
Auch bei einem externen Betriebsdienstleister braucht es intern eine zuständige Person. Sie sollte die Lösung so weit verstehen, dass sie Änderungen beurteilen, Kosten freigeben und die Arbeit des Anbieters erklären kann.
Soll Ihr Team später übernehmen, beginnt die Übergabe während des Projekts. Geben Sie Mitarbeitenden Zugang zu Repositories und Cloud-Konten. Beteiligen Sie sie an Reviews und lassen Sie sie Routineänderungen durchführen, solange der Berater noch verfügbar ist. Wenn erst am Ende auffällt, dass nur er deployen kann, wird die Übergabe aufwendig.
Wie nehmen Sie die Arbeit ab?
Planen Sie Zeit für unerwartete Befunde ein. Bei der Migration kann eine undokumentierte Datenbankabhängigkeit auftauchen. Ein Wiederherstellungstest kann zeigen, dass ein Schlüssel fehlt. Fragen Sie, wo der Projektplan solche Abklärungen berücksichtigt und wer Zusatzaufwand freigibt.
Erproben Sie den Entwurf mit einer echten Anwendung, bevor Sie weitere umstellen. Vereinbaren Sie die Prüfungen vorher. Je nach Auftrag gehören ein Deployment, ein Rollback, die Wiederherstellung von Daten und die Kontrolle der Zugriffsrechte dazu. Die Ergebnisse zeigen, ob die nächste Migration beginnen kann.
Lassen Sie bei der Übergabe jemanden aus Ihrem Team mit der Betriebsdokumentation arbeiten: das passende Log finden, eine Einstellung ändern und die Wiederherstellung erklären. Solange der Berater noch da ist, lassen sich Lücken direkt schliessen. Ob eine Anleitung verständlich ist, merkt man beim Benutzen.
Manchmal reicht ein kleinerer Auftrag
Ein Umzug in die Cloud kann nötig sein, weil ein Rechenzentrum schliesst oder ein Hardwarevertrag ausläuft. Halten Sie diesen Grund fest. Erwarten Sie zusätzlich schnellere Releases oder weniger Administration, muss der Auftrag die dafür nötigen Änderungen enthalten. Wer bestehende Server in Cloud-VMs kopiert, übernimmt unter Umständen dieselben manuellen Abläufe. Die DORA-Forschung zu flexibler Infrastruktur behandelt solche Migrationen ohne Änderung des Betriebsmodells.
Auch bei Cloud-Kosten lohnt sich ein überschaubarer Anfang. Können Sie die Rechnung erklären? Wem gehören die einzelnen Ressourcen? Welche Testumgebungen laufen das ganze Wochenende? Welche Speicher- oder Log-Aufbewahrung wurde einmal eingerichtet und seitdem nicht mehr geprüft? Daraus kann bereits ein sinnvoller erster Auftrag entstehen.
Sie können den Ausbau auch beenden, sobald Deployments wiederholbar sind und die Wiederherstellung funktioniert. Ein kleines Team braucht möglicherweise weder einen Servicekatalog noch ein eigenes Entwicklerportal. Fragen Sie, wer es pflegen würde und wie viel Zeit es den Nutzern tatsächlich erspart.
Prüfen Sie die Zugriffe des Anbieters
Ein DevOps-Dienstleister benötigt möglicherweise Zugang zu Quellcode, Produktionslogs, Datenbanken und Backups. Klären Sie, welche Personen darauf zugreifen, wo sie arbeiten und ob Subunternehmen beteiligt sind. Vereinbaren Sie, wie Zugriffe freigegeben und beim Verlassen des Projekts entzogen werden.
Für Schweizer Unternehmen ist der Hosting-Standort nur ein Teil der Datenschutzprüfung. Der EDÖB erläutert die Bedingungen für Bekanntgaben ins Ausland. Prüfen Sie neben dem Standort der Anwendung auch, wohin Logs, Backups und Supportzugriffe gelangen. Weitere Vorgaben können aus Ihrer Branche oder aus Kundenverträgen entstehen.
Soweit die DSGVO gilt, regeln Artikel 28 und 32 die Auftragsverarbeitung und angemessene Sicherheitsmassnahmen; Kapitel V betrifft internationale Übermittlungen. Lassen Sie die Vertragsbedingungen für Ihre Situation prüfen. Für betroffene Unternehmen im EU-Finanzsektor kommen Pflichten aus dem Digital Operational Resilience Act hinzu, darunter die Überwachung von IKT-Dienstleistern. Diese Verordnung wird ebenfalls DORA abgekürzt und ist vom oben erwähnten Forschungsprogramm zu unterscheiden.
Wenn die Plattform KI-Systeme betreiben soll, beziehen Sie diese in die Prüfung ein. Modellzugriffe, gespeicherte Prompts und Aufzeichnungen über Deployments können zusätzliche Anforderungen mit sich bringen. Unser Leitfaden zu selbst gehosteter KI behandelt die Hosting- und Betriebsfragen ausführlicher.
Was sollte eine Analyse hinterlassen?
Nach einer Analyse sollten Sie entscheiden können, welche Arbeit Sie als Nächstes beauftragen. Verlangen Sie eine kurze Übersicht der Anwendung, ihrer Abhängigkeiten und des Wegs einer Änderung bis in die Produktion. Dazu gehören auch Menschen: Wenn jedes Release auf die Freigabe einer einzigen Person wartet, ist das ebenfalls eine Abhängigkeit.
Die Ergebnisse sollten zeigen, was tatsächlich geprüft wurde und was offenbleibt. «Backups sind eingerichtet» ist eine andere Aussage als «Wir haben ein Backup erfolgreich wiederhergestellt». Fehlende Zugriffe oder Testumgebungen gehören ausdrücklich in den Bericht, damit sie bei der Aufwandsschätzung berücksichtigt werden.
Ein brauchbarer Arbeitsplan benennt die erste Änderung, ihren Nutzen, den erwarteten Aufwand und die Person, die sie abnimmt. Er hält auch fest, was warten kann. Wenn alles dringend erscheint, fragen Sie: Welches Problem würden wir zuerst lösen, wenn das Budget nur für eine Aufgabe reicht?
Anbieter am selben Beispiel vergleichen
Besprechen Sie mit jedem Kandidaten dasselbe Release oder dieselbe Störung. Wie würde er die Ursache untersuchen? Welche Zugriffe braucht er? Was könnte Ihr Team am Ende selbst ausprobieren? Die Rückfragen sagen oft mehr aus als eine Präsentation mit vielen Werkzeugnamen.
- Lernen Sie die Fachperson kennen, die mit Ihrem Team arbeiten würde.
- Bitten Sie um ein Beispiel einer Übergabedokumentation ohne vertrauliche Kundendaten.
- Lassen Sie sich eine günstigere oder einfachere Lösung erklären und begründen, weshalb sie passt oder ausscheidet.
- Klären Sie, was bei unerwarteten Abhängigkeiten oder einem Projektende nach dem Pilot passiert.
Notieren Sie vor dem Preisvergleich die Annahmen jedes Angebots. Vielleicht enthält eines eine Probe der Migration und eine Schulung, während das andere beides Ihrem Team überlässt. Eine gemeinsame kurze Aufgabenbeschreibung macht solche Unterschiede sichtbar.
Nach der Migration weiter hinschauen
Wenn die Anwendung läuft, braucht es weiterhin jemanden, der Kosten, Alarme und anstehende Wartung prüft. Bei einem Kostenalarm muss eine zuständige Person den Anstieg erklären und über die nächsten Schritte entscheiden können. Ein Ressourcen-Tag ordnet eine Ausgabe zu; eine vergessene Testumgebung schaltet es nicht ab.
Gehen Sie nach einigen normalen Änderungen noch einmal das Release-Beispiel durch. Kann ein Kollege ohne den Berater deployen? Hat die Wiederherstellung im Test funktioniert? Kopiert noch jemand Zugangsdaten oder ändert die Produktion von Hand? Betrachten Sie diese Beobachtungen zusammen mit den Lieferkennzahlen. Wird der neue Ablauf umgangen, klären Sie zuerst den Grund, bevor Sie weiter automatisieren.
Was Sie ins erste Gespräch mitbringen können
Sie brauchen noch kein vollständiges Pflichtenheft. Beschreiben Sie das letzte schwierige Release, eine wiederkehrende Störung oder eine Cloud-Rechnung, die sich nicht erklären lässt. Hilfreich ist auch, was Ihr Team bereits versucht hat und wer mit dem Anbieter zusammenarbeiten würde.
Bei Alpine Edge untersuchen wir solche Fragen in einer technischen Analyse und vereinbaren den Umfang vor der Umsetzung. Unsere Cloud- und DevOps-Leistungen umfassen Aufbau und laufenden Betrieb. Für Teams, die Modelle einsetzen, übernehmen wir auch KI-Integration und private KI. Im ersten Gespräch klären wir, was geändert werden sollte, welche Aufgaben Ihr Team übernehmen kann und wo externe Unterstützung sinnvoll ist.