Eine Person auf Abruf zu haben, reicht nicht aus. Was passiert, wenn Ihr Bereitschaftstechniker seinen Alarm verschläft? Was passiert, wenn der Akku seines Telefons leer wird, ohne dass er es merkt, oder wenn er einen Alarm zu einem wirklich ungünstigen Zeitpunkt erhält, beispielsweise wenn er in einem Bus oder im Stau steckt? Es Wille passieren.

Sie brauchen Verstärkung! Eine oder mehrere Personen, die in den Startlöchern stehen und sofort einspringen können, wenn Ihr primärer Bereitschaftsdienst kriminell fahrlässig nicht in der Lage, seine oder ihre Aufgaben jederzeit bestmöglich zu erfüllen.

Diese Backups müssen nicht SO „auf Abruf“ sein wie Ihr Hauptingenieur ^[1] , aber was sie an Einsatzbereitschaft einbüßen, machen sie durch ihre Anzahl wett. Es ist oft sinnvoll, mehrere Backups zu haben.

In PagerDuty gruppieren wir den aktuell diensthabenden Techniker und alle seine oder ihre Vertretungen in einer „Eskalationsrichtlinie“, die die Reihenfolge festlegt, in der wir Leute alarmieren (E-Mail/Telefon/SMS), und die Verzögerungen zwischen den Alarmen. Es gibt viele Möglichkeiten, diese Eskalationsrichtlinien zu organisieren, aber ich gehe auf einige Muster ein, die viele unserer Kunden (sowohl große als auch kleine) verwenden.

Primär und sekundär

Sie haben natürlich bereits eine Art „primären“ Bereitschaftsingenieur, und diese glorreiche Position wird hoffentlich von einem Kalender, der zwischen den Personen in Ihrem Ops-Team wechselt auf faire Weise ^[2] .

Viele unserer Kunden ergänzen diese Rotation durch eine (einfallslos benannte) „sekundäre“ Rotation. Diese sekundäre Rotation wird normalerweise so eingerichtet, dass sie die primäre Rotation überschattet, indem sie identisch zur primären Rotation konfiguriert wird, jedoch um eine bestimmte Zeit versetzt ist, sodass es unmöglich ist, gleichzeitig primäre und sekundäre Bereitschaft zu sein. Wenn Ihre primäre Rotation beispielsweise „Alex, Bob und Charlie“ enthält, kann Ihre sekundäre Rotation „Bob, Charlie und Alex“ in dieser Reihenfolge enthalten.

Über 25 % der (vielen) Bereitschaftskalender, die wir hier bei PagerDuty verwalten, enthalten entweder das Wort „primär“ oder „sekundär“. Dies ist also ein in unserem gesamten Kundenstamm sehr häufig verwendetes Muster.

First-Tier- und Last-Tier-Support

Wenn Ihr Unternehmen groß genug ist oder Sie genügend Betriebsaufgaben haben, können Sie auch ein separates First-Tier-Supportteam haben, das alle grundlegenden Betriebsaufgaben übernimmt, noch bevor Ihr „primärer“ Bereitschaftstechniker einspringt. Dieses Front-Line-Team ist normalerweise darin geschult, alle sich wiederholenden und lästigen kleinen Probleme zu lösen, die häufig auftreten, und verfügt über klare Lösungsverfahren. (Sie wissen schon, das Zeug, das Sie eigentlich schon längst beheben sollten, aber hey, Sie sind ja beschäftigt.) Diese First-Tier-Supportteams werden oft von mehreren Technikteams gemeinsam genutzt und stehen in einer Eskalationsrichtlinie an erster Stelle.

Wer steht also an letzter Stelle der Eskalationspolitik? Wer ist der zuletzt -stufiges Supportteam? Natürlich das Management!

Ihre Eskalationsrichtlinie sollte nicht nur bei Ihren primären oder sekundären Betriebsteams enden, sondern bis zum Telefon ihrer Vorgesetzten und dann möglicherweise sogar bis zum Telefon der Vorgesetzten ihrer Vorgesetzten eskalieren, vorausgesetzt, niemand bestätigt den Alarm rechtzeitig.

Damit werden zwei Ziele verfolgt: (1) die Verwaltung Ist Er ist letztendlich für diese wichtigen Systeme verantwortlich und sollte logischerweise informiert werden, wenn größere Probleme auftreten. Und (2) Ihr Betriebsteam wird einen automatisierten PagerDuty -Anruf weniger wahrscheinlich „verpassen“, wenn es weiß, dass dies lediglich bedeutet, dass sein Chef es in ein paar Minuten persönlich anrufen und ihm einige sehr gezielte Fragen stellen wird.

Beispiel

Wenn man all dies zusammennimmt, könnte ein (sehr vollständiges) Beispiel für eine Eskalationsrichtlinie für ein hypothetisches „Database Ops“-Team ungefähr so aussehen:

1. Weisen Sie den Vorfall dem Benutzer zu, der Bereitschaft hat im Erstklassiges Einsatzteam Zeitplan
2. Weisen Sie den Vorfall dem Benutzer zu, der Bereitschaft hat im Primärer DBA Zeitplan
3. Weisen Sie den Vorfall dem Benutzer zu, der Bereitschaft hat im Sekundärer DBA Zeitplan
4. Weisen Sie den Vorfall zu an Dilbert Adams (Teamleiter)
5. Weisen Sie den Vorfall zu an Pointi Haredboss (Entwicklungsmanager)

Mit Timeouts von vielleicht 10-30 Minuten zwischen den Eskalationen, je nach Bedarf. Beachten Sie, dass alle Personen (Manager), die direkt in die Eskalationsrichtlinie aufgenommen werden, im Wesentlichen auf Abruf bereitstehen. die ganze Zeit , als letzte Verteidigungslinie, sollten daher versuchen, ihre Mobiltelefone stets griffbereit und aufgeladen zu haben.

[1] Sie müssen kein mobiles Breitbandgerät , zum Beispiel, und können sich weniger schuldig fühlen, wenn sie Dinge tun wie Rauschtrinken während der Arbeit Gelegentliche Teilnahme an Aktivitäten, die ihre Bereitschaft zur Bereitschaft leicht einschränken könnten.

[2] Der Hauptingenieur muss nicht durch Rotation bestimmt werden, und Sie können stattdessen irgendeine arme Seele für die gesamte Dienstzeit in Ihrem Unternehmen jede Minute des Tages als Hauptingenieur in Bereitschaft setzen, aber diese Dienstzeit kann aufgrund von Burnout von kurzer Dauer sein.

Dieser Beitrag erschien ursprünglich am 8. März 2012 im PagerDuty -Blog