Il ne suffit pas d'avoir une seule personne de garde. Que se passe-t-il si votre ingénieur de garde dort pendant son alerte ? Que se passe-t-il si la batterie de son téléphone est morte sans qu'il le sache, ou s'il reçoit une alerte à un moment vraiment inopportun, comme lorsqu'il est coincé dans un bus ou dans les embouteillages ? volonté arriver.

Vous avez besoin d'une sauvegarde ! Une ou plusieurs personnes, en attente dans les coulisses, prêtes à entrer en action si votre principale urgence est négligence criminelle incapable d’accomplir ses tâches au mieux de ses capacités à un moment donné.

Ces sauvegardes n'ont pas besoin d'être aussi « d'astreinte » que votre ingénieur principal ^[1] , mais ce qu'ils perdent en disponibilité, ils le compensent en nombre. Il est souvent judicieux d'avoir plusieurs sauvegardes.

Dans PagerDuty, nous regroupons l'ingénieur actuellement d'astreinte et tous ses remplaçants dans une « politique d'escalade », qui définit l'ordre dans lequel nous alertons les personnes (par e-mail/téléphone/SMS) et les délais entre les alertes. Il existe de nombreuses façons d'organiser ces politiques d'escalade, mais je vais passer en revue certains modèles utilisés par nombre de nos clients (grands et petits).

Primaire et secondaire

Vous avez bien sûr déjà une sorte d’ingénieur « principal » de garde, et cette position glorieuse est, espérons-le, déterminée par un calendrier qui tourne entre les personnes de votre équipe d'opérations de manière équitable ^[2] .

Beaucoup de nos clients complètent cette rotation avec une rotation « secondaire » (au nom peu imaginatif). Cette rotation secondaire est généralement configurée pour suivre la rotation principale en étant configurée de manière identique à la rotation principale, mais décalée d'un certain laps de temps, de sorte qu'il est impossible d'être à la fois le principal et le secondaire de garde en même temps. Par exemple, si votre rotation principale contient « Alex, Bob et Charlie », votre rotation secondaire peut contenir « Bob, Charlie et Alex », dans cet ordre.

Plus de 25 % des (nombreux) calendriers d'astreinte que nous gérons ici chez PagerDuty contiennent soit le mot « principal », soit le mot « secondaire », il s'agit donc d'un modèle très couramment utilisé dans l'ensemble de notre clientèle.

Assistance de premier et de dernier niveau

Si votre entreprise est suffisamment grande ou si vos tâches opérationnelles sont suffisamment nombreuses, vous pouvez également disposer d'une équipe d'assistance de premier niveau distincte qui gère toutes les tâches opérationnelles de base avant même votre ingénieur d'astreinte « principal ». Cette équipe de première ligne est généralement formée à la gestion de tous les petits problèmes répétitifs et ennuyeux qui surviennent souvent et dispose de procédures de résolution claires. (Vous savez, ces problèmes que vous devriez sérieusement résoudre dès maintenant, mais bon, vous êtes occupé.) Ces équipes d'assistance de premier niveau sont souvent partagées entre plusieurs équipes d'ingénierie et sont placées en premier dans une politique d'escalade.

Alors, qui est placé en dernier dans la politique d'escalade ? Qui est le dernier -Une équipe de soutien de haut niveau ? La direction, bien sûr !

Votre politique d'escalade ne doit pas se limiter à vos équipes d'opérations principales ou secondaires, mais doit s'étendre jusqu'au téléphone de leur responsable, et peut-être même jusqu'au téléphone du responsable de leur responsable, en supposant que personne ne reconnaisse l'alerte à temps.

Cela a deux objectifs : (1) la gestion est en fin de compte, il est responsable de ces systèmes importants et c'est logiquement celui qui doit être informé si des problèmes majeurs passent entre les mailles du filet, et (2) votre équipe d'opérations sera moins susceptible de « rater » un appel téléphonique automatisé PagerDuty si elle sait que cela signifie simplement que son patron les appellera personnellement dans quelques minutes et leur posera des questions très pointues.

Exemple

Ainsi, en mettant tout cela ensemble, un exemple (très complet) de politique d’escalade pour une équipe hypothétique « Opérations de base de données » pourrait ressembler à ceci :

1. Affecter l'incident à l'utilisateur qui est de garde dans le Équipe d'opérations de premier niveau calendrier
2. Affecter l'incident à l'utilisateur qui est de garde dans le DBA principal calendrier
3. Affecter l'incident à l'utilisateur qui est de garde dans le DBA secondaire calendrier
4. Affecter l'incident à Dilbert Adams (chef d'équipe)
5. Affecter l'incident à Pointi Haredboss (gestionnaire de développement)

Avec des délais d'attente de 10 à 30 minutes entre chaque escalade, selon vos besoins. Notez que toutes les personnes (responsables) directement placées dans la politique d'escalade sont essentiellement de garde tout le temps , en tant que dernière ligne de défense, ils devraient donc essayer de garder leurs téléphones portables à portée de main et chargés à tout moment.

[1] Ils n'ont pas besoin de transporter un appareil mobile à large bande passante , par exemple, et peuvent se sentir moins coupables de faire des choses comme consommation excessive d'alcool pendant le service participer occasionnellement à des activités susceptibles de diminuer légèrement leurs capacités de disponibilité.

[2] L'ingénieur principal n'a pas besoin d'être déterminé par une rotation, et vous pouvez à la place avoir une pauvre âme qui sera l'ingénieur principal de garde chaque minute de chaque jour pendant toute sa durée dans votre entreprise, mais cette durée peut être courte en raison de l'épuisement professionnel.

Cet article a été publié à l'origine sur le blog PagerDuty le 8 mars 2012