DevOps, Lieferwege und Verantwortung
DevOps Beratung: Wo du bei langsamen und riskanten Releases anfangen solltest
Wie du DevOps-Beratung am konkreten Lieferweg auswählst: Wartezeit, Pipeline, Freigaben, Pilot und Übergabe an dein Team.
DevOps Beratung ist für mich dann sinnvoll, wenn sie den Weg einer Änderung bis in den Betrieb nachvollziehbar macht und an einem konkreten Problem ansetzt. Eine passende Fachperson für DevOps sollte erklären können, wo Zeit verloren geht, welche Risiken entstehen und was dein Team anschließend selbst besser steuern kann. Die Auswahl eines neuen Tools ist dabei eine mögliche Maßnahme. Sie braucht zuerst eine begründete Aufgabe.
Wenn ein Unternehmen zuverlässiger ausliefern möchte, würde ich deshalb bei einem vorhandenen Release anfangen. Welche Änderung wurde umgesetzt, welche Prüfungen gab es und was musste jemand von Hand erledigen? An diesem Ablauf lassen sich technische Schwierigkeiten und unklare Zuständigkeiten auseinanderhalten.
Mit einem tatsächlichen Lieferweg anfangen
Nehmen wir ein fiktives Beispiel: Eine Fachabteilung wartet auf eine kleine Korrektur. Der Code ist fertig, die Tests sind grün. Bis zur Freigabe vergehen trotzdem mehrere Abstimmungen. Danach stellt sich heraus, dass für das Deployment eine Konfiguration fehlt, die nur eine Person kennt.
In dieser Situation würde eine schnellere Build-Maschine nur einen Teil des Ablaufs verändern. Die Wartezeit auf Entscheidungen und das fehlende Wissen blieben bestehen. Vielleicht ist zusätzlich der Build langsam. Das muss dann als eigener Befund sichtbar werden.
Diese Unterscheidung gehört für mich zur DevOps Beratung. Entwicklung, Betrieb, Qualitätssicherung und die beteiligten Fachverantwortlichen müssen denselben Ablauf beschreiben können. Dazu passt das Verständnis von DevOps als Verbindung von Menschen, Prozessen und Technik. (DevOps und der Anwendungslebenszyklus)
Als Ausgangspunkt reicht ein abgegrenzter Lieferweg: eine Anwendung, ihre Pipeline, die betroffenen Umgebungen und ein kürzlich durchgeführtes Release. Einen vollständigen Umbau der Organisation würde ich daraus noch nicht ableiten.
Wartezeit, technische Laufzeit und Risiko trennen
Für die Untersuchung brauche ich mehr als eine durchschnittliche Pipeline-Laufzeit. Relevant sind die einzelnen Schritte: Wann war die Änderung bereit, wann startete der Build, wo wartete sie auf eine Freigabe und wann wurde das geänderte Verhalten geprüft?
Dazu gehören auch fehlgeschlagene und abgebrochene Läufe. Ein erfolgreicher Durchlauf zeigt einen anderen Ausschnitt als ein Release, das nur mit zusätzlicher Handarbeit abgeschlossen wurde. Ursachen, die sich aus den vorhandenen Daten nicht belegen lassen, bleiben offen.
Ich würde dafür folgende Informationen zusammentragen:
- Repositories, Pipeline-Definitionen und die Zuordnung zu Anwendungen und Umgebungen.
- Repräsentative Build-, Test- und Deployment-Logs mit Zeitpunkten und Ergebnissen.
- Artefaktversionen, Konfigurationen und die Herkunft des ausgelieferten Pakets.
- Manuelle Prüfungen, Freigaben, Rückfragen und die jeweils verantwortlichen Rollen.
- Einen dokumentierten Fehlerfall einschließlich Wiederherstellung und offener Fragen.
Mit dieser Übersicht lässt sich begründen, ob zuerst ein technischer Schritt, eine Entscheidung oder eine Wissenslücke bearbeitet werden muss. Eine pauschale Vorgabe wie "mehr automatisieren" wäre mir dafür zu ungenau.
Die fachliche Passung am Vorgehen beurteilen
Bei der Auswahl würde ich mir zeigen lassen, wie jemand vom beobachteten Fehler zu einer überprüfbaren Empfehlung kommt. Wird nur die Pipeline-Datei angesehen, oder werden Quellsystem, Tests, Artefakte, Rechte und Betriebsbedingungen mitgedacht?
Auch der Umgang mit Freigaben ist aufschlussreich. Eine zusätzliche Genehmigung kann eine fachliche Verantwortung abbilden. Sie kann aber auch nur eine Unsicherheit weiterreichen, ohne etwas zu prüfen. Für jede Freigabe sollte klar sein, wer aufgrund welcher Informationen entscheidet und was bei einer Ablehnung passiert. Werkzeuge können solche Regeln abbilden; die inhaltliche Entscheidung bleibt eine Aufgabe des Unternehmens. (Freigaben und Prüfungen in Azure Pipelines)
Ein gutes Gespräch liefert deshalb keine universelle Wunscharchitektur. Es klärt den Untersuchungsumfang, die benötigten Daten, die Mitarbeit deines Teams und die erwarteten Ergebnisse. Lass auch benennen, welche Fragen mit dieser Untersuchung nicht beantwortet werden.
Wichtig ist mir die Übergabe. Wenn nach dem Projekt nur die beratende Person einen Fehler einordnen oder eine Pipeline ändern kann, fehlt ein Teil des Ergebnisses.
Einen begrenzten Lieferweg verbessern
Nach der Bestandsaufnahme würde ich einen Pilot wählen, dessen Ergebnis sichtbar überprüft werden kann. Das kann ein reproduzierbarer Build, eine verlässliche Artefaktübergabe oder die Absicherung eines kritischen Deployment-Schritts sein.
Vorher werden Ausgangszustand und Abnahmekriterien festgehalten. Bei einer Laufzeitfrage wird derselbe relevante Ablauf verglichen. Bei einer Zuverlässigkeitsfrage braucht es passende Fehlerfälle. Ein schnellerer Durchlauf allein belegt noch nicht, dass eine Änderung fachlich korrekt ausgeliefert wird.
Zum Pilot gehören auch ein Abbruchkriterium und ein nachvollziehbarer Rückweg. Welche Wiederherstellung möglich ist, hängt etwa davon ab, ob nur Anwendungscode oder auch Daten verändert werden. Kleine Änderungen, geeignete Prüfungen und kontrollierte Auslieferung sind deshalb ein sinnvoller Bezugspunkt. (Praktiken für kontrollierte Deployments)
Erst nach dem gemeinsamen Durchlauf wird entschieden, was auf weitere Anwendungen übertragen werden kann. Der Pilot kann auch zeigen, dass eine zunächst geplante Automatisierung weniger Nutzen bringt als eine klare Zuständigkeit oder ein zusätzlicher fachlicher Test.
Aufwand und Ergebnis gemeinsam abgrenzen
Ein Angebot lässt sich besser beurteilen, wenn die Untersuchung und die Umsetzung getrennt beschrieben sind. Eine Analyse kann Befunde und Prioritäten liefern. Der Umbau von Pipelines, Tests oder Deployment-Schritten braucht einen eigenen vereinbarten Umfang.
Für einen Vergleich würde ich deshalb nach konkreten Ergebnissen fragen: Welche Abläufe werden untersucht? Welche Änderungen werden umgesetzt? Welche Dokumentation und Übergaben entstehen? Wer nimmt den Pilot ab?
Zum Aufwand gehören neben der externen Arbeit auch die Zeit deines Teams, benötigte Testumgebungen und die spätere Pflege. Ohne diese Angaben lässt sich ein günstiger Tagessatz kaum mit einem abgegrenzten Projekt vergleichen. Ein allgemein gültiger Preis oder ein versprochenes Einsparpotenzial wäre daraus nicht seriös ableitbar.
Was vor dem Auftrag geklärt sein muss
Vor dem Start sollten diese Punkte beantwortet sein:
- Der betroffene Lieferweg und das konkrete Problem sind benannt.
- Logs, Konfigurationen und repräsentative Release-Fälle sind zugänglich.
- Fachliche und technische Verantwortliche stehen für Rückfragen und Abnahme bereit.
- Ausgangszustand, Pilot und Akzeptanzkriterien sind vereinbart.
- Dokumentation, Wissenstransfer und die Verantwortung nach der Übergabe sind eingeplant.
Mein eigener Schwerpunkt liegt bei gewachsenen Softwaresystemen, insbesondere .NET, und ihren technischen Risiken. In meinem Stabilisierungsprojekt für .NET-Systeme gehören Build, Tests, CI/CD und Deployment zu den möglichen Arbeitsbereichen. Grundlage ist eine vorherige Bestandsaufnahme; die Umsetzung erfolgt gemeinsam mit dem Team.
Für eine allgemeine Cloud-Architektur, einen vollständigen Plattformbetrieb oder ein umfassendes Organisationsprogramm braucht es einen dazu passenden Auftrag und entsprechende Fachleute. Für die erste Entscheidung würde ich einen überschaubaren Lieferweg untersuchen. Danach lässt sich begründen, welche Veränderung sich lohnt und was dein Unternehmen dafür braucht.