Temps de lecture : 6 minutesSérie : « L’histoire de Vezha semaine par semaine » • Edition du 20/04/2026Dans #098, nous avons ajouté une véritable analyse d’access.log, de RPS et de taux d’erreur à Vezha pour une détection précoce des activités suspectes. Après cette étape, les retours des équipes opérationnelles ont été très précis : « Le signal est là, donnez-nous maintenant un moyen de dresser aussi rapidement un tableau probant de l’incident pour ne pas avoir à le faire à la main. »Cette demande est devenue le sujet du numéro 099. Nous avons ajouté un rapport PDF médico-légal de 7 jours sur les erreurs IP aux statistiques Web. Sa tâche n’est pas de créer un autre « beau » planning, mais de donner à l’équipe un document tout fait pour l’action : localisation, escalade, récupération.Contexte : là où le processus a échoué avant cette versionDans la plupart des circuits de production, la situation est typique. L’anomalie est vite visible : la part des 4xx/5xx augmente, le profil du trafic évolue, des requêtes répétées vers des endpoints sensibles apparaissent. Mais entre « nous voyons le problème » et « pris une décision », il y a un écart manuel.Habituellement, cet intervalle ressemble à ceci :l’ingénieur de service filtre les journaux par fenêtre horaire ;sélectionne individuellement les adresses IP avec le pourcentage d’erreurs le plus élevé ;résume les conclusions intermédiaires dans un tableau ou un ticket ;explique à ses collègues pourquoi cette activité mérite une réponse dès maintenant.Le point le plus faible ici est évident : l’équipe dépense des ressources non pas pour l’action, mais pour la préparation du matériel pour l’action. Aux heures de pointe, c’est la perte de temps la plus coûteuse.Ce qui est apparu dans le #099Une nouvelle fonctionnalité de Web-Stats génère un rapport PDF médico-légal sur 7 jours en une seule exécution contrôlée. L’utilisateur travaille dans un seul circuit : ne bascule pas entre plusieurs outils, ne copie pas les données manuellement, ne collecte pas de base de preuves « à partir de zéro ».En conséquence, l’équipe reçoit :section structurée par erreur IP pour la période sélectionnée ;dynamique de l’activité dans le temps pour détecter les ondes répétitives ;document prêt pour SOC/Sécurité, SRE et Incident Manager.L’idée clé est simple : donner aux gens non pas des « fragments bruts », mais du matériel avec lequel ils peuvent immédiatement prendre des décisions.Comment le processus est construit sous le capotNous n’avons pas fait une requête « longue » monolithique, difficile à contrôler et encore plus difficile à restaurer en cas de panne. Au lieu de cela, ils ont mis en œuvre un pipeline par étapes avec des progrès visibles dans l’interface utilisateur.Lancement de la tâche : l’opérateur lance une collecte médico-légale à partir de statistiques Web.Analyse de fenêtre : l’agent parcourt séquentiellement un intervalle de temps et prépare des données agrégées.Transfert progressif : les données sont envoyées en plusieurs parties, sans téléchargement unique « lourd ».Assemblage final : le serveur assemble le résultat, forme le package final et restitue le PDF.Exportation : le dossier terminé est transmis au même circuit de travail où l’équipe mène l’incident.Cette approche offre deux avantages à la fois : la prévisibilité pour l’opérateur et la charge stable pour le système.Ce qui a changé pour les différents rôles de l’équipeNous avons évalué la version non seulement pour la mise en œuvre technique, mais également pour la manière dont elle est utilisée par différents rôles lors d’un seul incident.Pour NOC/On Duty : élimine le besoin d’utiliser nos mains pour expliquer pourquoi une série d’erreurs n’est pas un « bruit aléatoire ». Il existe un document prêt à l’emploi avec une structure claire.Pour le SRE : il est plus facile de se mettre d’accord sur des modifications du périmètre, du taux limite ou du scénario d’isolement lorsque la base de preuves est déjà collectée et unifiée.Pour la sécurité/SOC : démarre son propre processus d’analyse plus rapidement car les données sont présentées dans un format utilisable au lieu de « extraits bruts ».Pour le chef d’équipe : les décisions sont prises plus rapidement car tout le monde examine les mêmes faits au lieu de différentes versions de notes manuelles.Cas pratique anonymiséSur un circuit, l’équipe a constaté une augmentation modeste mais constante de la part de 4xx au cours de la soirée. Le RPS global n’était pas en dehors des limites attendues, donc sans analyse plus approfondie, la situation pourrait ressembler à un « bruit temporaire ».Après l’exécution du rapport médico-légal de 7 jours, un schéma répétitif est devenu visible : l’activité était concentrée sur un petit ensemble de points finaux et présentait une forme d’onde avec des intervalles presque identiques. Cela a permis de coordonner rapidement les étapes entre les équipes :renforcer les règles de protection périmétrique pour des scénarios d’accès spécifiques ;spécifier les limites pour les modèles de demande individuels ;enregistrer l’analyse des incidents dans un seul document sans duplication manuelle.Plus important encore, dans ce cas, l’équipe est passée de la discussion sur les symptômes à l’action en une seule journée.Frontières de sécurité et modèle commercialLe PDF médico-légal par erreur IP est disponible dans le plan Total . Il s’agit d’une décision délibérée, car c’est dans ce segment que la demande en matière de réponse approfondie aux incidents, d’opérations à distance et de calendrier de réponse stable est la plus forte.En même temps, on ne confond pas les objectifs : la surveillance de base et les métriques quotidiennes restent plus largement disponibles, et la couche d’incidents « lourds » est activée là où l’entreprise en a vraiment besoin chaque jour.Ce que cela signifie pour la stratégie de VezhaCette version est une bonne représentation de l’approche de Neemle en matière de développement de produits. Vezha reste une petite plateforme temps réel rapide et sécurisée construite sur Rust avec une gestion centralisée des points de surveillance. Chaque mise à jour doit profiter à la production sans augmenter la complexité opérationnelle.Le rapport médico-légal de 7 jours est à peu près cela :moins de routine manuelle à un moment critique ;transfert de contexte plus rapide entre les rôles ;des décisions plus claires fondées sur des faits plutôt que sur des hypothèses.Il est également important de noter que Vezha a intégré un proxy vers Prometheus, de sorte que les nouvelles fonctionnalités sont naturellement intégrées dans les boucles de surveillance existantes sans qu’il soit nécessaire de « casser » les processus de l’équipe.Effet opérationnel dans les chiffres du processusNous avons délibérément mesuré non seulement les mesures techniques, mais également les mesures comportementales de l’équipe lors des incidents. Depuis l’avènement du PDF médico-légal, le temps nécessaire pour parvenir à une première solution convenue a diminué, le nombre d’artefacts intermédiaires manuels a diminué et la synchronisation entre les modifications est devenue plus prévisible.En d’autres termes, le produit ne se contente pas de « voir le problème », mais aide l’équipe à mettre constamment fin à l’incident.Comment utiliser le rapport dans les 30 premières minutes d’un incidentPour tirer le meilleur parti d’une version, nous recommandons un rituel de travail simple que l’équipe peut exécuter immédiatement après le déclenchement d’une anomalie. Il ne nécessite pas d’outils séparés et s’intègre bien dans le processus opérationnel standard.Enregistrez l’événement. Définissez la fenêtre temporelle à laquelle l’écart a commencé et créez un contexte d’incident dans votre tracker.Exécutez un PDF médico-légal dans les statistiques Web. Cela fournit une factologie unique pour tous les participants à l’incident.Séparez le bruit du risque. Découvrez quelles adresses IP et modèles d’appel génèrent une part importante d’erreurs.Prenez une décision tactique. Convenez de la première série d’actions : filtrage, limitation du débit, modifications du périmètre, escalade du SOC.Capturez les post-actions. Une fois l’environnement stabilisé, ajoutez des améliorations structurelles à l’arriéré pour réduire la répétition des dossiers.Lorsque ce cycle est pratiqué, l’équipe improvise moins en mode « chaud » et passe plus rapidement à un scénario de réponse maîtrisée.Erreurs courantes que le n°099 aide à éviterLors des entretiens avec les équipes techniques, nous avons constamment constaté plusieurs scénarios anti-modèles récurrents. Le nouveau rapport ne les « guérit » pas automatiquement, mais il réduit le risque d’erreur dû à la structure des données.Erreur n°1 : Réagir uniquement au RPS. Un trafic élevé ne constitue pas toujours en soi un problème. Le signal clé réside souvent dans le déséquilibre entre le volume et le taux d’erreur.Erreur n°2 : analyse fragmentaire d’un segment temporel. Sans fenêtre de 7 jours, il est facile de rater des vagues récurrentes.Erreur n°3 : faire semblant de faire semblant sans faits documentés. Cela crée le chaos lors du transfert d’un incident entre les équipes.Erreur n°4 : escalader trop tard. Si la base de données probantes met du temps à se constituer, l’équipe rate l’opportunité d’une intervention rapide et peu coûteuse.C’est pourquoi nous nous sommes concentrés sur le format PDF : il discipline le processus, standardise la communication et réduit « l’effet téléphone cassé » entre les rôles.Où cette opportunité donne le plus grand effetD’après notre expérience, ce sont les contours dans lesquels le cycle d’incidents existe déjà, mais qui « glisse » au stade de la préparation des données, qui en bénéficient le plus. Il s’agit le plus souvent de :e-commerce et services à forte charge avec un trafic ondulatoire pendant la journée ;Plateformes SaaS, où certains points de terminaison ont une sensibilité accrue aux requêtes automatisées ;infrastructures avec des équipes distribuées travaillant sur plusieurs équipes ou zones géographiques.Dans de tels environnements, non seulement le fait de la détection, mais aussi la vitesse de transition vers une réponse coordonnée devient décisif. Le numéro 099 comble simplement cet écart.Une checklist pratique avant d’allumer votre circuitPour que le lancement se déroule sans problème, nous vous conseillons de passer par un petit contrôle de préparation avant la démonstration :se mettre d’accord sur qui dans l’équipe est responsable de la solution aux incidents dans les équipes de soir/nuit ;déterminer le canal de remontée standard (SOC, responsable SRE, responsable d’astreinte) ;fixer le « seuil d’action » pour lancer le processus médico-légal afin d’éviter des fluctuations inutiles ;se mettre d’accord sur les actions post-incident qui doivent être incluses dans le backlog après stabilisation.Cela prend un peu de temps, mais améliore considérablement la qualité du premier mois d’utilisation de la fonctionnalité.Résumé du numéro 099Il n’y a pas de promesses bruyantes cette semaine. Il existe une mesure pratique qui permet de gagner du temps au quotidien et de réduire le chaos dans les situations critiques. Ce sont ces étapes qui forment un produit mature : lorsque chaque version facilite le travail de l’équipe dans un environnement réel.Si vous voulez voir comment ce script fonctionne dans votre circuit, laissez une demande de démo sur vezha.io . Montrons comment Vezha s’intègre dans l’infrastructure actuelle avec zéro CAPEX et des OPEX équitables pour la mise à l’échelle.
Хочете перевірити Vezha на вашій інфраструктурі? Перейдіть на vezha.io та надішліть запит на демо.