Engpass-Diagnose
Reifegrad-Zertifikat — Acht Fragen entlang derselben Bereiche, die wir im Platform-Bottleneck-Assessment prüfen. Am Ende steht die schwächste Stelle und der erste Schritt, den ihr ohne uns gehen könnt.
Was das hier ist — und was nicht
Das ist eine Selbsteinschätzung, keine Analyse. Sie kennt euren Code nicht, euren Cluster nicht und eure Organisation nicht; sie kennt nur, was ihr gleich anklickt. Eine Antwort pro Bereich kann eine Vermutung schärfen, aber sie kann eine Ursache nicht belegen. Für eine belastbare Aussage braucht es Gespräche mit den Beteiligten, einen Blick in die Architektur und den tatsächlichen Weg einer Änderung in die Produktion. Genau das macht das Assessment, und genau das ersetzt diese Seite nicht.
Dazu kommt ein Effekt, den ihr einplanen solltet: Selbsteinschätzungen fallen fast immer freundlicher aus als Messungen. Wer unsicher ist, wählt eher die mittlere Antwort. Wenn ihr schwankt, nehmt die schlechtere — das Ergebnis wird dadurch nützlicher.
Eure Antworten bleiben im Browser. Sie werden nicht gespeichert, nicht verschickt und nicht ausgewertet — auch nicht anonym. An unsere Reichweitenmessung geht nur, dass eine Diagnose geöffnet, begonnen und abgeschlossen wurde. Welche Antwort ihr gewählt habt, erfahren wir nie.
Woher die Fragen kommen
Jede Frage gehört zu einem Prüfschritt des Platform-Bottleneck-Assessments und ist die kurze Form dessen, was dort über mehrere Tage untersucht wird. Die Auswertung ist absichtlich simpel und offengelegt: Die erste Antwort zählt drei Punkte, die letzte null. Nichts wird gewichtet, weil jede Gewichtung, die wir hier erfinden würden, durch nichts belegt wäre. Ausgewertet wird der Bereich mit der niedrigsten Punktzahl; bei Gleichstand der, der weiter oben steht. Eine Null in einem einzigen Bereich schließt das oberste Ergebnisfeld aus, egal wie hoch die Summe ist — ein vollständig blockierter Bereich ist ein Engpass, auch wenn der Rest gut aussieht.
Acht Fragen
Antwortet für den Bereich, den ihr verantwortet, und für den Normalfall — nicht für das beste Team und nicht für den schlimmsten Tag.
Bitte beantwortet noch die offenen Fragen. Erste offene Frage: —
Euer Ergebnis
— von 24 Punkten
Mehrere Engpässe gleichzeitig
Eure Antworten deuten nicht auf eine schadhafte Stelle hin, sondern auf mehrere, die sich gegenseitig halten. Das ist der Fall, in dem einzelne Verbesserungen wenig bewirken: Wer die Pipeline beschleunigt, während Umgebungen knapp und Freigaben spät sind, verschiebt die Wartezeit nur. Fangt trotzdem an einer Stelle an — unten steht, an welcher.
Ein deutlicher Engpass mit Nebenwirkungen
Eure Antworten zeigen ein Muster: An einer Stelle klemmt es spürbar, und ein paar Nachbarbereiche leiden mit. Das ist die Ausgangslage, in der gezielte Arbeit am meisten bringt, weil es eine erkennbare Reihenfolge gibt.
Kein struktureller Engpass sichtbar
Nach dieser Selbsteinschätzung steckt euer Hauptproblem wahrscheinlich nicht in der Plattform. Zwei Vorbehalte: Diese acht Fragen können nur finden, wonach sie fragen, und eine Selbsteinschätzung fällt fast immer freundlicher aus als eine Messung. Wenn sich die Auslieferung trotzdem zäh anfühlt, liegt die Ursache eher in Produktschnitt, Priorisierung oder Abstimmung als in der Technik.
Punkte je Bereich
- Weg in die Produktion— / 3
- Vertrauen in Releases— / 3
- Kopplung der Systeme— / 3
- Umgebungen und Testdaten— / 3
- Betrieb und Störungen— / 3
- Verantwortung und Self-Service— / 3
- Sicherheit und Freigaben— / 3
- Wissen und Schlüsselpersonen— / 3
Kein Bereich liegt unter der besten Antwort, deshalb hebt die Auswertung keinen einzelnen hervor. Was jetzt sinnvoll ist, steht oben im Ergebnisfeld und unten unter „Was danach sinnvoll ist“.
Schwächste Stelle
Weg in die Produktion
Worauf das hindeutet
Zwischen fertigem Code und laufender Software liegt bei euch Wartezeit, keine Arbeit. Das ist der Engpass, den man am schnellsten sieht und am häufigsten falsch verortet: meistens steckt er nicht in der Pipeline selbst, sondern in den Schritten davor und danach, die niemand aufgeschrieben hat.
Was ihr ohne uns zuerst tun könnt
Nehmt die letzten zehn Änderungen und schreibt für jede zwei Zeitpunkte auf: gemerged und in Produktion. Danach markiert ihr, wo die Zeit tatsächlich vergangen ist — im Warten auf eine Freigabe, im Warten auf ein Fenster oder im Warten auf einen Menschen. Das kostet einen Nachmittag und beendet die meisten Vermutungen.
Dazu passt
Leistung:Cloud, Kubernetes & Platform Engineering
Workshop:GitOps einführen
Vertrauen in Releases
Worauf das hindeutet
Nicht die Technik bremst, sondern das begründete Misstrauen gegen den eigenen Auslieferungsweg. Solange ein Release ein Ereignis ist, werden Änderungen gebündelt — und je größer das Bündel, desto berechtigter das Misstrauen. Diese Schleife löst sich nicht durch mehr Sorgfalt.
Was ihr ohne uns zuerst tun könnt
Probt ein Rollback in einer Nicht-Produktivumgebung und stoppt die Zeit. Wenn niemand im Team den Ablauf ohne Nachfragen hinbekommt, habt ihr die Ursache gefunden, bevor ihr über Release-Frequenz redet.
Dazu passt
Leistung:Cloud, Kubernetes & Platform Engineering
Workshop:GitOps einführen
Kopplung der Systeme
Worauf das hindeutet
Euer Engpass ist ein Architekturschnitt, kein Werkzeug. Koordination zwischen Teams ist die sichtbare Folge; die Ursache sind geteilter Zustand und gemeinsame Auslieferung. Werkzeuge beschleunigen hier nichts, sie verteilen die Wartezeit nur um.
Was ihr ohne uns zuerst tun könnt
Zeichnet für die letzte größere Änderung auf, welche Teams zustimmen mussten und warum. Meistens läuft es auf zwei, drei geteilte Datenbestände hinaus — und genau die sind die kurze Liste, über die sich reden lässt.
Dazu passt
Leistung:Architektur-Modernisierung
Workshop:Architekturentscheidung
Umgebungen und Testdaten
Worauf das hindeutet
Der Engpass sitzt vor dem Merge, nicht danach. Wenn Ausprobieren teuer ist, wird weniger ausprobiert — und was nicht ausprobiert wurde, fällt später auf, wenn es mehr kostet. Testdaten sind dabei häufiger das Problem als die Infrastruktur.
Was ihr ohne uns zuerst tun könnt
Fragt drei Entwicklerinnen und Entwickler, wie lange sie beim letzten Mal auf eine brauchbare Umgebung gewartet haben und woran es lag. Wenn zweimal die Testdaten genannt werden, fangt dort an und nicht bei der Automatisierung.
Dazu passt
Leistung:Cloud, Kubernetes & Platform Engineering
Workshop:Platform Engineering — Grundlagen
Betrieb und Störungen
Worauf das hindeutet
Der Betrieb hängt an Personen statt an einem Ablauf. Das fällt im Alltag kaum auf und im Ernstfall sofort — und es ist derselbe Mangel, der Änderungen langsam macht: Wer nicht weiß, wie ein System sich im Fehlerfall verhält, ändert es vorsichtig und selten.
Was ihr ohne uns zuerst tun könnt
Nehmt die drei häufigsten Störungen der letzten Monate und schreibt zu jeder auf, woran man sie erkennt und was der erste Handgriff ist. Ein knapper Ablauf, den jemand um drei Uhr nachts lesen kann, ist mehr wert als ein vollständiges Betriebshandbuch.
Dazu passt
Leistung:Cloud, Kubernetes & Platform Engineering
Workshop:Kubernetes-Betrieb
Verantwortung und Self-Service
Worauf das hindeutet
Der Engpass ist organisatorisch und wird technisch nicht verschwinden. Jede Anfrage, deren Laufzeit unvorhersehbar ist, wird eingeplant wie ein Risiko — Teams bauen Umwege, legen Vorräte an oder verschieben Vorhaben. Der Zeitverlust taucht in keiner Statistik auf.
Was ihr ohne uns zuerst tun könnt
Zählt eine Woche lang mit, wie viele Anfragen bei der Plattform- oder Infrastrukturseite ankommen und wie viele davon dieselbe Sache betreffen. Die zwei häufigsten sind die Kandidaten, die sich zuerst als Self-Service lohnen.
Dazu passt
Leistung:Cloud, Kubernetes & Platform Engineering
Workshop:Platform Engineering — Grundlagen
Sicherheit und Freigaben
Worauf das hindeutet
Sicherheit ist bei euch ein Tor am Ende statt eine Eigenschaft des Weges. Späte Prüfungen finden dieselben Mängel immer wieder, weil zwischen Fund und nächstem Vorhaben niemand etwas ändert. Der Zeitverlust entsteht nicht durch die Anforderung, sondern durch ihren Zeitpunkt.
Was ihr ohne uns zuerst tun könnt
Schaut euch die Befunde der letzten zwei Freigaben an und markiert, welche davon eine Pipeline hätte finden können. Was doppelt vorkommt, gehört nach vorne verlegt — der Rest ist echte Prüfarbeit.
Dazu passt
Leistung:Cloud, Kubernetes & Platform Engineering
Workshop:Kubernetes-Betrieb
Wissen und Schlüsselpersonen
Worauf das hindeutet
Euer größtes Risiko ist eine Abhängigkeit, keine Technologie. Sie wirkt doppelt: Sie macht den Betrieb verwundbar, und sie macht dieselbe Person zum Nadelöhr für jede Änderung, weil alles über einen Schreibtisch läuft.
Was ihr ohne uns zuerst tun könnt
Schreibt auf, welche Handgriffe heute nur eine Person ausführen kann, und lasst genau einen davon in den nächsten zwei Wochen von jemand anderem machen — mit der ersten Person daneben. Was dabei an Fragen entsteht, ist eure Dokumentation.
Dazu passt
Leistung:Cloud, Kubernetes & Platform Engineering
Workshop:Kubernetes-Betrieb
Nochmal deutlich: Das ist eine Einordnung aus acht Antworten, kein Befund. Bevor ihr Budget bewegt, prüft die Vermutung an euren eigenen Zahlen — der erste Schritt oben ist genau dafür gedacht.
Passende Engineering-Leistungen
Die Hinweise verweisen auf technische Themen, nicht auf einen verpflichtenden nächsten Kauf. Ihr könnt damit selbst weiterarbeiten oder offene Fragen mit uns besprechen.