Nach dem Deployment Verantwortung für den Dienst übernehmen

Definieren Sie den Dienst, von dem Nutzer abhängen

Deployment macht Software verfügbar. Der Betrieb hält sie nützlich, wenn sich Nutzer, Abhängigkeiten, Verkehr und Anforderungen ändern. Ein Codegenerator beseitigt diese laufende Arbeit nicht.

Bei einem fiktiven Kundenexport brauchen Nutzer mehr als eine erreichbare Seite. Sie brauchen die erlaubten Datensätze im erforderlichen Format innerhalb einer akzeptablen Zeit. Der Dienst muss auch den Zugriff auf Daten einer anderen Organisation verhindern.

Benennen Sie den Verantwortlichen vor der Veröffentlichung. Halten Sie fest, wer außerhalb normaler Arbeitszeiten reagiert, falls dies zur Dienstzusage gehört. Ein Anbieter kann einen Teil der Arbeit ausführen. Die Organisation braucht dennoch einen klaren Weg für Entscheidungen und Kommunikation.

Wählen Sie Signale, die Handeln unterstützen

Ein Service Level Indicator, kurz SLI, misst eine definierte Eigenschaft des Dienstverhaltens. Ein Service Level Objective, kurz SLO, setzt für diesen Indikator ein Ziel über einen angegebenen Zeitraum. Wählen Sie das Ziel anhand von Nutzerbedarf und betrieblichen Möglichkeiten.

Googles SRE-Leitfaden erklärt diesen Ansatz und die Nutzung eines Fehlerbudgets für Zuverlässigkeitsentscheidungen. Kopieren Sie das Ziel eines anderen Dienstes nicht, ohne seine Bedeutung zu prüfen. SLO-Leitfaden, Beispielrichtlinie für Fehlerbudgets.

Definieren Sie für den Export, was als erfolgreiche berechtigte Anfrage zählt. Trennen Sie erwartete Ablehnungen von Systemfehlern. Dokumentieren Sie Ausschlüsse, damit eine Kennzahl nicht allein durch das Verbergen schwieriger Anfragen besser wird.

Protokollieren Sie keine vollständigen Exporte, nur um mehr Einblick zu erhalten. Erfassen Sie die minimal nötigen Informationen zur Diagnose und schützen Sie den Zugriff darauf.

Bereiten Sie die Incident-Reaktion vor

Legen Sie fest, wer koordiniert, untersucht und kommuniziert. In einem kleinen Team können Rollen zusammenfallen, aber die Verantwortlichkeiten müssen klar bleiben. Dokumentieren Sie Beobachtungen und Aktionen.

Googles Leitfaden zur Incident-Reaktion betont neben technischer Eindämmung auch Koordination und Kommunikation. Auch bei einer technisch korrekten Fehlerbehebung können Nutzer uninformiert bleiben oder mehrere Einsatzkräfte widersprüchliche Änderungen vornehmen. Incident-Reaktion.

Ein Agent kann innerhalb freigegebener Datengrenzen Logs zusammenfassen oder Hypothesen vergleichen. Er sollte keine unbegrenzten Produktionsbefugnisse erhalten, nur weil ein Incident dringend ist. Nutzen Sie für außerordentlichen Zugriff einen definierten Eskalationsweg.

Testen Sie Wiederherstellung und finanzieren Sie Wartung

Testen Sie das Wiederherstellungsverfahren mit repräsentativen fiktiven Daten. Ermitteln Sie, was ein Code-Rollback nicht rückgängig machen kann, einschließlich gelöschter Datensätze oder bereits gesendeter Nachrichten. Erfassen Sie Zeit und Informationen, die zur Dienstwiederherstellung nötig sind.

Weisen Sie laufende Arbeit zu: Abhängigkeitsupdates, Zugriffsprüfungen, gegebenenfalls Zertifikatserneuerung, Kapazitätsänderungen und Dokumentationskorrekturen. Ein Dienst ohne Wartungskapazität sammelt Verpflichtungen an, nachdem das Startbudget endet.

Wählen Sie nach einem Incident Verbesserungen, die die beobachteten Ursachen behandeln. Verbinden Sie sie mit Implementierung und Prüfung. So schließt sich der Lebenszyklus: Betriebsnachweise verändern, was das Team als Nächstes spezifiziert und baut.