Die meisten Observability-Stacks können eine Frage hervorragend beantworten: Was ist passiert?
Bei der nächsten Frage sind sie schwächer: Wo beheben wir das Problem?
In dieser Lücke verlangsamt sich die Reaktion auf Vorfälle. Das Team sieht die Fehlerrate, öffnet den Trace, liest die Protokolle, überprüft den Bereitstellungszeitplan und muss dann noch die Codebasis manuell durchsuchen.
Ein bekannter Vorfall
Stellen Sie sich vor, dass eine API nach einer Bereitstellung zeitweise 500 Sekunden zurückgibt. Das Dashboard zeigt die Spitze. Der Trace deutet auf den Kassenservice hin. Die Protokolle enthalten einen Validierungsfehler, die Meldung ist jedoch generisch.
In diesem Moment benötigt das Team kein weiteres Diagramm. Es braucht Orientierung:
- das Repository, das den Checkout besitzt
- Der Handler, der mit der fehlerhaften Route verbunden ist
- das letzte Commit, das das Validierungsverhalten geändert hat
- die Person oder das Team, die den Fix überprüfen soll
Das ist Codekontext.
Warum Codekontext wichtig ist
Beobachtbarkeit ohne Codekontext schafft Bewusstsein. Durch die Beobachtbarkeit im Codekontext wird ein Weg zur Reparatur geschaffen.
Der Unterschied ist gering, aber operativ wichtig. Eine Ablaufverfolgung kann Ihnen sagen, dass eine Anfrage fehlgeschlagen ist POST / Kasse. Der Codekontext kann auf den Validierungszweig, die gestern geänderte Datei und den Eigentümer verweisen, der diesen Bereich normalerweise überprüft.
Diese Zuordnung spart bei vielen Vorfällen die erste Stunde.
Der minimal nützliche Kontext
Sie müssen nicht die gesamte Untersuchung an eine Pull-Anfrage anhängen. Ein Rezensent benötigt in der Regel eine kompakte Faktensammlung:
- Produktionssymptom
- betroffenen Dienst
- wahrscheinlich Datei oder Funktion
- kürzliche Bereitstellung oder Codeänderung
- Eigentümer oder Rezensent
- vorgeschlagene nächste Maßnahme
Alles andere sollte diese Tatsachen untermauern und nicht begraben.
Wo Dashboards aufhören
Dashboards dienen dazu, das Systemverhalten anzuzeigen. Pull-Requests dienen der Änderung des Systemverhaltens. Ein gesunder Sanierungsworkflow verbindet diese Welten, anstatt dass Ingenieure sie jedes Mal manuell überbrücken müssen.
Wenn das Signal den Code nicht finden kann, wird die Warnung zu einem weiteren Warteschlangenelement. Wenn das Signal den Code finden kann, kann das Team entscheiden, ob ein Patch durchgeführt, ein Rollback durchgeführt, ein Backlog-Element geöffnet oder eine eingehendere Untersuchung durchgeführt werden soll.
Worauf man aufbauen soll
Das praktische Ziel ist nicht eine größere Beobachtungsfläche. Es ist ein kürzerer Weg:
Produktionssignal -> Codekontext -> überprüfbare Aktion
Diese Aktion könnte eine Pull-Anfrage sein. Es könnte sich um ein Jira-Problem handeln. Es könnte sich um einen Hinweis handeln, der besagt, dass das Problem bei einem Upstream-Anbieter liegt. Der Punkt ist, dass das Team nicht jedes Mal mit einer leeren Untersuchung beginnen sollte, wenn die Produktion spricht.
Die Beobachtbarkeit zeigt den Fehler. Der Codekontext weist darauf hin, dass der Fehler irgendwohin führen kann.
