Zum Hauptinhalt springen
Halten Sie Ihren Produktionsbetrieb überprüfbar, ohne einen eigenen SRE-Berater zu bezahlen. Diese zeitgesteuerte Automatisierung prüft Ihren Infrastructure-as-Code-Stand, die CI/CD-Konfiguration, das Monitoring-Setup und Ihre Runbooks und weist auf Lücken gegenüber SRE-Best-Practices hin: fehlende Alerts, veraltete On-Call-Rotationen, fehlende Runbooks für kritische Services und unbestätigte Playbooks.

Diese Vorlage verwenden

Öffnen Sie SRE Health Checker in Devin und erstellen Sie die Automatisierung mit der Standardkonfiguration. Sie können sie vor dem Speichern anpassen.

​
Was diese Automatisierung macht

Beim Reliability Engineering geht es darum, eine Ausgangsbasis aufrechtzuerhalten. Der SRE Health Checker wird wöchentlich ausgeführt, prüft Ihr Setup und liefert einen bewerteten Bericht zu wichtigen Zuverlässigkeitspraktiken — damit Sie Abweichungen erkennen, bevor sie zu einem Vorfall werden, und sie proaktiv beheben können.

​
So funktioniert es

Auslöser: Zeitplan-Ereignis — recurring
  • Ereignis: schedule:recurring
    • Bedingungen:
      • rrule stimmt mit FREQ=WEEKLY;BYDAY=MO;BYHOUR=9;BYMINUTE=0 überein
Was Devin tut: Startet eine Sitzung mit dem vollständigen Ereigniskontext, führt den folgenden Prompt aus und benachrichtigt Sie bei einem Fehlschlag optional.

​
Voraussetzungen

​
Beispiel-Prompt

Die Vorlage enthält diesen Prompt. Sie können ihn nach einem Klick auf Vorlage verwenden bearbeiten oder unverändert lassen.

​
Einrichtung

  1. Öffne Automations → Templates in Devin.
  2. Klicke auf SRE Health Checker. Die Seite zum Erstellen wird mit dieser Vorlage bereits vorausgefüllt geöffnet.
  3. Verbinde alle erforderlichen Integrationen und installiere MCP-Server, falls du das noch nicht getan hast.
  4. Ersetze alle Platzhalterwerte in den Trigger-Bedingungen (zum Beispiel your-org/your-repo durch dein tatsächliches Repo).
  5. Prüfe den Prompt und passe ihn an die Sprache, Konventionen und Vorgaben deines Teams an.
  6. Klicke auf Create automation.
Die meisten Automatisierungsvorlagen enthalten empfohlene ACU- und Aufruflimits, um die Kosten während des anfänglichen Rollouts zu begrenzen. Lass sie unverändert, bis du sicher bist, wie sich die Automatisierung verhält, und erhöhe sie dann entsprechend deinem Workload.

​
Wann diese Vorlage sinnvoll ist

  • Wachsende Engineering-Teams, die ihre ersten Zuverlässigkeitspraktiken einführen
  • Reviews nach Vorfällen, bei denen systemische Lücken überprüft werden sollen
  • Plattform- und Infrastrukturteams, die viele Services betreuen
  • Aufnahme neuer Services in Zuverlässigkeitsstandards

​
Ideen zur Anpassung

  • Auf bestimmte Services, Repos oder Teams eingrenzen
  • Audit-Kriterien anpassen (teamspezifische Zuverlässigkeitsstandards hinzufügen)
  • Mit MCP-Daten aus Datadog, PagerDuty oder Opsgenie abgleichen
  • Schweregrade und Eskalationspfade feinabstimmen

​
Siehe auch