--- title: "Réponse aux incidents et contexte de supervision | Unolia" description: "Quand un site client tombe, voyez le contexte autour de l’incident : les derniers déploiements, les changements DNS, la santé des fournisseurs et les problèmes ouverts, à côté de le monitoring en échec." url: "https://unolia.com/fr/use-cases/incident-response-monitoring" locale: "fr" --- # Quand un site tombe, voyez le contexte autour de l’incident. Monitorings, déploiements, DNS et problèmes autour de chaque alerte. Un monitoring en échec dit seulement que quelque chose ne va pas. Unolia pose ce qui a changé, ce qui fait tourner le site et ce qui était déjà cassé à côté de l’alerte, et l’enquête commence déjà répondue. ## Une alerte sans contexte, c’est une chasse aux onglets. La plupart des incidents demandent des indices côté supervision, DNS, Git, hébergement et fournisseurs en même temps. Trois nuits se sont passées autrement parce que les indices partageaient une page. ### L’alerte qui s’est expliquée toute seule. Le monitoring du paiement est passé au rouge à 21:47. Le projet montrait déjà le déploiement de 21:32 juste à côté, auteur et message compris. La décision de retour arrière a pris cinq minutes de lecture, pas une heure de questions, et le client a appris la panne par le correctif, pas par l’interruption. ### La panne qui était en fait du DNS. Tout accusait l’hébergement, et l’hébergement allait bien. Le panneau DNS du projet racontait la vraie histoire : un enregistrement modifié le matin même, avec le qui et le quand dans l’historique. Repointé en un clic, et le bilan n’a pas eu besoin d’une liste de suspects. ### Le bilan d’incident qui s’est écrit tout seul. Le lendemain matin, la revue commence d’habitude par de l’archéologie de chat. Cette fois, l’historique tenait déjà l’alerte, le déploiement, la cause et le correctif dans l’ordre, horodatés. Le résumé a pris dix minutes, et il collait à la réalité. ## Le contexte, dans le produit. Tout ce que votre supervision a oublié d’apporter. ### Les monitorings sur le projet Les monitorings Oh Dear, leurs contrôles, incidents et historiques, rattachés au site client qu’ils surveillent. ### L’historique de déploiement à côté de l’alerte Qui a déployé quoi et quand, avec les journaux, juste à côté de le monitoring passé au rouge. ### L’état DNS et son historique Les enregistrements, les changements récents et leurs auteurs, pour les incidents qui se révèlent être du DNS. ### La santé des fournisseurs Jetons expirés, synchronisations figées et alertes fournisseurs signalés comme contexte avant de bloquer une enquête. ### L’incident, expliqué Demandez à votre assistant IA ce qui a changé. Il lit le même projet et aligne la cause probable, pour relecture humaine. ## Alerte de supervision contre contexte projet | Before | After | | --- | --- | | Le monitoring alerte, puis l’équipe ouvre cinq tableaux de bord pour comprendre le site. | La vue projet tient supervision, déploiements, DNS, fournisseurs et problèmes ensemble. | | Seule la personne qui a construit le site peut vraiment enquêter. | La personne d’astreinte part du même contexte que tout le monde. | | La connaissance de l’incident disparaît dans le chat après le correctif. | L’historique garde l’alerte, la cause et le correctif pour la prochaine revue. | ## Donnez aux alertes le contexte projet qui leur manque. Le prochain monitoring au rouge arrive avec ses déploiements, son DNS, ses fournisseurs et son historique. Les enquêtes commencent déjà répondues. [Rejoindre la liste d’attente](https://app.unolia.com/register)