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, wenn kanman darf beim Service auf Fixes starten steht, oder fragt zuerst, wenn es auf Vor dem Fix fragen steht. 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.

Um nach einem Incident zu sehen, fragen Sie im Chat des Teams, zum Beispiel „Wie ist der Stand beim Incident?“. kanman nennt zuerst den offenen Incident mit seiner Schwere und der Story, in der kanman ihn behebt, zum Beispiel „e2e-Checkout API hat einen offenen Incident (kritisch): Checkout export fails. Ich behebe ihn in SBX-489.“, und hängt die Karte des Incidents an, danach die Runs und das Board des Teams.

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

Die Incident-Seite

Ein Incident kommt als Nachricht in Ihrer Unterhaltung mit kanman an; ein Klick auf seine Karte öffnet ihn. Seine Befunde landen im Chat des Teams; öffnen Sie kanman in Allgemein, während ein Incident offen ist, sagt Allgemein es auch, mit der Ursache, die kanman gefunden hat, und, wenn kanmans dringende Korrektur auf Ihr OK wartet, mit ihrem Plan zum Freigeben direkt dort. Ist der Service wieder da, sagt Allgemein auch das. Die offenen und aufgelösten Incidents eines Teams stehen unter /teams/<team>/incidents: Klicken Sie im Status des Teams auf “1 Incident offen”, oder suchen Sie nach dem Incident. Die Seite eines Incidents zeigt:

• Schweregrad, Status, Ursache, wie viele Alarme dazukamen, wie lange er dauerte
• wo der Incident steht: Signal, Befund, Maßnahme, Erholung, die erreichten Schritte abgehakt
• die Ursachenkette: Änderung, Fehler, Alarm, kanmans Einschätzung, Fix und Erholung in einem Bild, damit Sie auf einen Blick sehen, was was ausgelöst hat und was noch aussteht; Tabelle zeigen listet dieselben Schritte als Text
• die Zeitleiste: jeden Alarm, jede Erkenntnis, Aktion und Entscheidung, die neueste oben, mit Links zur Fix-Story, ihrem Run und den Entscheidungen
• die Zusammenfassung und die Folge-Stories, sobald er aufgelöst ist

Solange ein Incident offen ist, beginnt die Incident-Seite des Teams mit ihm unter Gerade jetzt: wo er steht und kanmans neueste Befunde, laufend aktualisiert.

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

Sicherheit

• Nur beobachten ist eine harte Grenze pro Service: Steht kanman darf auf Nur beobachten, beobachtet kanman, 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.