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 équipes compétentes, prêtes à répondre aux alertes 24h/24 et 7j/7 pour résoudre tout problème. Cela fait partie de la promesse Compose. Mais nous pensons que nos utilisateurs peuvent tirer des leçons de notre gestion de ces alertes.

La croissance crée la complexité

Un client Compose typique possède deux composantes principales : son stockage de données et son application. Bien que nous gérions la plupart des incidents et alertes liés au stockage de données, nous constatons souvent qu'il n'existe aucun mécanisme de génération et de traitement des alertes dans l'application. Ce n'est pas intentionnel ; malheureusement, dès le début, ce sont leurs propres clients qui les informent des dysfonctionnements de leur système. Ils devront donc s'adapter de manière organique pour gérer ces réclamations, les traduire en problèmes avec votre application, les trier et les résoudre.

Mais à mesure que vos systèmes et votre entreprise évoluent, cette évolution organique pèse sur vos équipes et impacte les temps de réponse et la qualité du tri. L'architecture de votre application devient plus complexe, avec davantage de composants 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 situent en réalité plus haut dans la pile du client, 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 systèmes de surveillance, vous permettant ainsi de recevoir un certain nombre d'alertes. En ajoutant des instruments supplémentaires, vous pouvez pallier ces lacunes. D'autres systèmes peuvent également fournir des indicateurs de performance et des contrôles réguliers. En intégrant tous ces éléments, vous optimisez la visibilité et la sensibilité des alertes.

Mais vous réalisez ensuite que vous avez créé davantage d'alertes pour votre personnel. Le bruit sera important, car vous constaterez généralement que chaque défaillance a un effet domino et génère des alertes dans différents systèmes. Certaines défaillances ressembleront à des alarmes incendie, sonnant fort sans cause apparente, tandis que d'autres ne généreront qu'une seule alerte, mais auront un impact considérable. De plus, vous pourriez 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 élément à surveiller et vous passerez plus de temps à concevoir la surveillance du système qu'à développer votre activité.

Répondre aux alertes dans Compose

Chez Compose, notre activité consiste à résoudre les problèmes de bases de données de nos clients, c'est pourquoi nous utilisons PagerDuty. Nos anciens systèmes de surveillance de serveurs Nagios et Sensu, plus récents, s'intègrent à 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 et détecter les événements de verrouillage et de déconnexion, les transformant également en alertes. Nous proposons une offre de support premium et utilisons PagerDuty pour garantir des réponses rapides à nos points de contact d'urgence. Nos e-mails d'assistance d'urgence sont récupérés par les points d'accès de PagerDuty, tandis que les appels d'urgence transitent par Twilio vers PagerDuty , les transformant également en alertes.

Une fois les alertes collectées, collationnées et dédupliquées chez PagerDuty, nous utilisons ensuite sa gestion des rotations pour gérer deux rotations simultanées et superposées du personnel de support. Le responsable de la rotation est le contact principal et le second est le contact de secours. Les plannings se chevauchent et, lorsque certaines tâches sont mieux réalisées par deux personnes, nous pouvons faire appel au responsable principal et au contact secondaire.

Nous ajoutons ensuite à ce dispositif l'équipe des opérations, qui assure un renfort supplémentaire. Enfin, nous veillons à ce que la maintenance programmée n'alerte pas inutilement les personnes d'astreinte : personne n'aime être réveillé ou dérangé pendant le dîner pour finalement découvrir que tout va bien. Nous utilisons des scripts que nous invoquons. hubot qui font tomber 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 indispensable aux opérations de Compose. Auparavant, nous consultions manuellement plusieurs systèmes et utilisions un calendrier pour planifier les astreintes. Aujourd'hui, nous sommes plus efficaces, non seulement pour recevoir les alertes rapidement, mais aussi en interne, ce qui nous permet de mieux répartir la charge de travail et de fournir un support de haute qualité. Nous ne pourrions plus nous en passer. – Ben Wyrosdick, cofondateur de Compose