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.
Amazon Route 53
Bento
Bunny.net
Cloudflare
DigitalOcean
Gandi
GitHub
GitLab
Ionos
Laravel Cloud
Laravel Forge
Mailgun
Namecheap
Oh Dear
OVHcloud
Ploi
Porkbun
Vultr
La plupart des incidents demandent des indices côté supervision, DNS, Git, hébergement et fournisseurs en même temps. Voici des nuits qui se sont passées autrement parce que les indices partageaient une page.
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.
En savoir plus →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.
En savoir plus →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é.
En savoir plus →Le monitoring dit que le site est tombé. Le projet dit tout le reste : les derniers déploiements avec leurs auteurs, les changements DNS récents, la santé des fournisseurs, les problèmes déjà ouverts. La première minute d’un incident devient de la lecture, pas de la chasse.
L’astreinte n’a plus besoin d’avoir construit le site. La personne de garde ouvre le même projet que tout le monde, lit ce qui a changé, et décide. La personne qui a écrit le code dort, et la revue du lendemain part de l’historique plutôt que des souvenirs.
Créez des monitorings, réglez leurs contrôles et triez les alertes depuis le projet, à côté des déploiements et des fournisseurs qu’ils surveillent. Quand l’un passe au rouge, il est déjà entouré de son contexte, et l’incident commence avec une longueur d’avance.
En savoir plus →Unolia n’est pas un outil de disponibilité de plus. C’est tout ce que votre supervision a oublié d’apporter.
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.
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.