Incidents und Rufbereitschaft

Was ein Team ausliefert, muss es auch betreiben. kanman kann für die Services eines Teams Rufbereitschaft übernehmen. Wird ein Service schlechter, eröffnet kanman einen Incident, informiert die Personen in Rufbereitschaft, findet heraus, was sich geändert hat, und tut, was Ihre Einstellungen erlauben: einen Fix mit Regressionstest starten, einen Revert vorschlagen oder einer Person die nächsten Schritte empfehlen. Produktion außerhalb des Codes ändert es nie.

Die Einrichtung beschreibt kanman in Rufbereitschaft nehmen. Alle Einstellungen stehen unter Rufbereitschaft-Einstellungen.

Services und Signalquellen

Ein Service ist etwas, das Ihr Team betreibt, zum Beispiel die Checkout-API. Jeder Service nennt die Repositorys, aus denen er gebaut wird, und seine Umgebungen (Produktion, Staging). So weiß kanman, wo es suchen und was es reparieren darf.

Eine Signalquelle meldet kanman, dass etwas schlechter wird, oder zeigt, was schiefgeht:

Eine Quelle kann mehrere Services speisen. Jede Quelle hat eine eigene Adresse und ein eigenes Secret; Alarme ohne das richtige Secret lehnt kanman ab.

Was passiert, wenn etwas schlechter wird

1. Ein Incident wird eröffnet. Der erste Alarm ab dem Schweregrad-Schwellwert des Service eröffnet einen Incident mit dem Schweregrad, den das Tool meldet. Weitere Alarme mit derselben Identität und andere Alarme desselben Service innerhalb von 30 Minuten kommen zu diesem Incident dazu, statt neue zu eröffnen.

2. kanman informiert. Es postet den Incident in den Incident-Kanal des Teams in Slack oder Microsoft Teams und benachrichtigt die gewählten Personen. Alles, was es danach herausfindet, landet im selben Thread.

3. kanman untersucht und postet jede Erkenntnis, sobald es sie hat:

   • Merges und Deploys vor dem ersten Alarm, und ob einer der Merges aus einem eigenen Run stammt
   • ob die CI auf dem Hauptbranch grün oder rot ist
   • den häufigsten Fehler in den Logs und wo im Code er auftritt
   • durch letzte Merges geänderte Konfigurationsdateien
   • Stories, die mit den letzten Änderungen verknüpft sind

   Erklärt nichts den Ausfall, sagt kanman das: „Ich kenne die Ursache noch nicht.“

4. kanman handelt im Rahmen Ihrer Einstellungen:

   Was kanman gefunden hat	Was es tut
   Der Fehler zeigt in Ihren Code, und ein letzter Merge hat genau diese Datei geändert	Es öffnet einen Revert-Pull-Request und fragt Sie unter Entscheidungen, ob er gemergt werden soll. Reverts werden nie ohne Sie gemergt.
   Der Fehler zeigt in Ihren Code	Es legt eine dringende Story an und startet einen Fix, oder fragt zuerst, wenn der Service das nicht erlaubt. Der Fix-Run reproduziert den Fehler mit einer Regressions-Akzeptanzspezifikation, bevor er etwas ändert, und durchläuft dann das Outcome-Gate wie jede andere Story.
   Ein Konfigurations- oder Infrastrukturproblem	Es fragt die Person in Rufbereitschaft unter Entscheidungen, mit seiner Empfehlung. Änderungen in Produktion außerhalb des Codes entscheidet immer ein Mensch.
   Ein externer Anbieter oder eine unbekannte Ursache	Es empfiehlt der Person in Rufbereitschaft die nächsten Schritte.

   Mergen und Deployen des Fixes folgen der Merge-Richtlinie Ihres Teams. kanman deployt nicht.

5. kanman schließt ab. Erholen sich die Alarme (das Tool meldet sie als aufgelöst, oder der Uptime-Check ist wieder erfolgreich), schließt kanman den Incident, schreibt eine kurze Zusammenfassung mit Zeitleiste, führt ihn im Wochenbericht des Teams auf und legt Folge-Stories als Entwürfe in der Aufnahme an, zum Beispiel „Früher erkennen“ oder „Fehlerhaften Codepfad absichern“. Sie prüfen und genehmigen sie wie jede andere Story.

Dringende Stories werden nie durch Budgets oder Drosselung gestoppt; siehe Budgets.

Die Incident-Seite

Öffnen Sie im Team Incidents, um offene und aufgelöste Incidents zu sehen. Die Seite eines Incidents zeigt:

• Schweregrad, Status, Ursache, wie viele Alarme dazukamen, wie lange er dauerte
• die Zeitleiste: jeden Alarm, jede Erkenntnis, Aktion und Entscheidung, in Reihenfolge, mit Links zur Fix-Story, ihrem Run und den Entscheidungen
• die Zusammenfassung und die Folge-Stories, sobald er aufgelöst ist

Jedes Mitglied des Workspaces kann eine Notiz ergänzen, den Incident von Hand auflösen oder als Fehlalarm schließen.

Sicherheit

• Nur beobachten ist ein harter Schalter pro Service: kanman beobachtet, untersucht und berichtet, startet aber nie einen Fix, schlägt keinen Revert vor und ändert den Alarm nicht.
• kanman stellt Alarme in Ihrem Alarmierungstool nie stumm, bestätigt oder löst sie nur auf, wenn Sie das für den Service erlauben (PagerDuty und Opsgenie).
• Außerhalb der Rufbereitschaftszeiten, die Sie für kanman festlegen, erfasst es Alarme, eröffnet aber keinen Incident; dann übernimmt Ihre menschliche Rufbereitschaft.
• Alles, was kanman tut, steht im Audit-Log: empfangene Alarme, eröffnete und aufgelöste Incidents, geänderte Einstellungen und Quellen und jede Aktion in einem Alarmierungstool.
• Secrets und Zugangsdaten von Quellen werden verschlüsselt gespeichert und nach dem Speichern nie wieder angezeigt.