Der schnellste Weg, einen erfolgreichen Proof of Concept zu töten, ist ihn ohne Observability an Operations zu übergeben. Sie haben etwas gebaut, das funktioniert. Es löst das Problem. Alle sind begeistert. Dann landet es in Produktion und das SRE-Team hat keine Ahnung, wie man es überwacht, keine Möglichkeit zu debuggen, und kein Vertrauen, dass sie es um 2 Uhr nachts zurückrollen können.
Sechs Monate später läuft es immer noch auf dem Laptop des ursprünglichen Entwicklers, weil niemand ihm genug vertraute, um es richtig zu betreiben.
Wir lösen das mit dem, was wir Telemetrie-Vertrag nennen: eine Reihe nicht verhandelbarer Observability- und Übergabe-Anforderungen, die mit jedem Proof Sprint geliefert werden.
Warum Telemetrie ein Delivery-Problem ist, kein Ops-Problem
Die meisten Teams behandeln Observability als etwas, das Ops nach der Lieferung hinzufügt. Der Telemetrie-Vertrag invertiert das. Observability ist eine Lieferanforderung, kein nachträglicher Einfall.
Signal-Parität: Ihre Kollektoren, Ihre Dashboards
Jeder Proof Sprint sendet Traces, Metriken und Logs in den Formaten, die der Kunde bereits verwendet. Wenn sie auf Datadog sind, senden wir an Datadog. Wenn sie auf Grafana mit Prometheus und Loki sind, senden wir an diese.
Das Evidenz-Paket
Jeder Proof Sprint enthält ein Evidenz-Paket: ein dokumentiertes Bündel von Sicherheits- und Betriebsartefakten. Das Paket enthält: SBOM, SCA-Bericht, IAM-Diff und Datenfluss-Dokumentation.
Startbahn für Ops: Tag 2 langweilig machen
Der erste Tag, an dem ein System in Produktion läuft, ist aufregend. Der zweite Tag sollte langweilig sein. Wir entwerfen für langweilige Tag 2s mit: Canary-Deployment-Plan, Runbooks, Rollback-Prozeduren und Kapazitätsplanungs-Notizen.
Warum das für den Business Case wichtig ist
Der Telemetrie-Vertrag entrisikt all dies im Voraus. Wenn wir den Proof Sprint übergeben, weiß das Ops-Team bereits, wie man ihn unterstützt, weil sie ihre bestehenden Tools verwenden.