Blog invité de Tim Yocum, directeur des opérations chez Composer . Compose est un service de base de données fournissant des bases de données MongoDB et Elasticsearch prêtes pour la production et à mise à l'échelle automatique.

Les utilisateurs de Compose font confiance à notre équipe pour prendre soin de leurs données et de leurs bases de données grâce à notre infrastructure intelligente et à nos collaborateurs prêts à répondre aux alertes 24h/24 et 7j/7 pour résoudre tout problème. Cela fait partie de la promesse de Compose. Mais nous pensons que nos utilisateurs peuvent tirer une leçon de la façon dont nous gérons ces alertes.

La croissance crée la complexité

Un client Compose typique a deux parties principales dans sa pile : son stockage de données et son application. Bien que la plupart des incidents et alertes de stockage de données soient gérés par nos soins, nous constatons qu'il y a souvent de fortes chances qu'il n'existe aucun mécanisme de génération et de gestion des alertes dans l'application. Ce n'est pas intentionnel ; au début, ce sont malheureusement leurs propres clients qui leur font savoir que leur système ne fonctionne pas et ils devront évoluer de manière organique pour gérer ces plaintes, les traduire en problèmes avec votre application, trier les problèmes et résoudre le problème.

Mais à mesure que vous développez vos systèmes et votre entreprise, cette évolution organique exerce une pression sur vos collaborateurs et affecte les temps de réponse et la qualité du tri. L'architecture de votre application devient plus complexe avec davantage de pièces mobiles et de sous-systèmes. C'est à ce stade que nous recevons souvent des appels concernant des problèmes de base de données qui se trouvent plus haut dans la pile du client, plus haut dans l'application.

Détecteurs de fumée

Certains composants de votre système sont peut-être déjà équipés d'instruments ou de dispositifs de surveillance, ce qui vous permet de recevoir un certain nombre d'alertes de vos systèmes. En ajoutant davantage d'instruments, vous pouvez couvrir les angles morts. D'autres systèmes peuvent également fournir des mesures de performance et des contrôles réguliers. En ajoutant tous ces éléments à l'équation, vous pouvez fournir autant de visibilité et de sensibilité des alertes que possible.

Mais vous réalisez ensuite que vous avez créé davantage d'alertes pour votre personnel. Il y aura beaucoup de bruit, car vous constaterez généralement que chaque défaillance a un effet domino dans la création d'alertes dans différents systèmes. Certaines défaillances ressembleront à des détecteurs de fumée, sonnant fort sans cause évidente, tandis que d'autres ne généreront qu'une seule alerte mais auront un impact massif. En plus de tout cela, vous pouvez recevoir ces alertes de plusieurs systèmes de surveillance liés à différentes personnes. Vous pourriez être tenté de créer votre propre système de gestion des alertes… mais c'est un autre composant à surveiller et vous passerez plus de temps à concevoir la surveillance du système qu'à développer votre entreprise.

Répondre aux alertes dans Compose

Chez Compose, notre activité consiste à fournir des problèmes de bases de données à nos clients, c'est pourquoi nous utilisons PagerDuty. Nos anciens systèmes de surveillance de serveur Nagios et Sensu plus récents s'intègrent tous deux à PagerDuty pour générer des rapports sur l'état général des serveurs. Nous utilisons ensuite notre propre plugin Compose pour surveiller nos systèmes de production pour détecter les événements de verrouillage et de réduction de tension élevés, les transformant également en alertes. Nous proposons une offre d'assistance premium et nous utilisons PagerDuty pour garantir des réponses rapides à ses points de contact 911. Nos e-mails d'assistance 911 sont récupérés par les hooks de messagerie de PagerDuty tandis que les appels 911 passent par Twilio dans PagerDuty, transformant également ces appels en alertes.

Une fois les alertes collectées, regroupées et dédupliquées sur PagerDuty, nous utilisons ensuite sa gestion de rotation pour gérer deux rotations simultanées du personnel de support qui se chevauchent. Le responsable de la rotation est le contact principal et le second est un contact de secours. Les planifications se chevauchent et, lorsqu'il y a des tâches qui sont mieux effectuées par deux personnes, nous pouvons faire appel au principal et au secondaire.

Nous ajoutons ensuite à ce mélange l'équipe des opérations pour agir comme une sauvegarde supplémentaire. Enfin, nous veillons à ce que la maintenance programmée n'alerte pas inutilement les personnes de garde - personne n'aime être réveillé ou dérangé pendant le dîner pour découvrir que tout va bien. Nous avons des scripts que nous invoquons via hubot qui désactivent les hôtes et les services et garantissent que les alertes de ces systèmes sont récupérées dans Nagios et Sensu et non transmises à PagerDuty.

PagerDuty est devenu un élément indispensable des opérations de Compose. Nous avions l'habitude de vérifier manuellement plusieurs systèmes et d'utiliser un calendrier pour déterminer la rotation des astreintes. Aujourd'hui, nous sommes plus efficaces, non seulement pour recevoir des alertes en temps opportun, mais aussi en interne, cela nous aide à répartir la charge de travail pour fournir un support de haute qualité. Nous ne pourrions plus nous en passer maintenant. – Ben Wyrosdick, co-fondateur de Compose