Série : « Histoire de Vezha semaine par semaine » • Numéro du 20/04/2026
Dans #098, nous avons ajouté une analyse réelle du journal d’accès, du RPS et du 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 concrets : « Le signal est là, donnez-nous maintenant un moyen de dresser un tableau probant de l’incident le plus rapidement possible sans le faire à la main. »
Cette demande est devenue le sujet du numéro 099. Nous avons ajouté aux statistiques Web
⟪Rapport PDF médico-légal de 5⟫7 jours sur l’erreur IPRapport PDF médico-légal de 7 jours sur l’erreur IP. 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 s’est arrêté avant cette version
Dans la plupart des circuits de production, l’image est typique. L’anomalie est rapidement visible : la part des 4xx/5xx augmente, le profil du trafic évolue, des requêtes répétées vers des points de terminaison 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é particulière mérite une réaction dès maintenant.
Le point le plus faible ici est évident : l’équipe dépense la ressource 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 #099
Une nouvelle fonctionnalité dans Web-Stats génère un rapport médico-légal sur 7 jours au format PDF 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 temporelle de l’activité 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 se construit sous le capot
Nous n’avons pas fait de 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.
- Démarrage de la tâche :
L’opérateur lance une collecte médico-légale à partir de statistiques Web. - Fenêtre de numérisation : l’agent passe séquentiellement l’intervalle de temps et prépare les données agrégées.
- Transfert étape par étape : les données sont envoyées en plusieurs parties, sans téléchargement unique « lourd ».
- Assemblage final :
Le serveur compile le résultat, forme le package final et restitue le PDF. - Exporter : le dossier terminé est remis au même circuit de travail où l’équipe conduit l’incident.
Cette approche offre deux avantages à la fois : la prévisibilité pour l’opérateur et la charge stable pour le système.
Qu’est-ce qui a changé pour les différents rôles de l’équipe
Nous avons évalué une version non seulement en raison de sa mise en œuvre technique, mais également en raison de la manière dont elle est utilisée par différents rôles lors d’un seul incident.
Pour CNO/en service : élimine le besoin d’expliquer manuellement pourquoi une salve d’erreurs n’est pas un « bruit aléatoire ». Il existe un document prêt à l’emploi avec une structure claire.
Pour 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 adapté, et non « sous forme d’extraits bruts ».
Pour le chef d’équipe : Les décisions sont prises plus rapidement parce que tout le monde examine les mêmes faits, plutôt que des versions différentes de notes manuscrites.
Cas pratique anonymisé
Sur un circuit, l’équipe a constaté une augmentation modérée mais régulière de la part du 4xx le soir. 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 avait 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 sur le périmètre pour des scénarios spécifiques de recours ;
- spécifier les limites pour les modèles de demande individuels ;
- enregistrez l’analyse des incidents dans un seul document sans duplication manuelle.
La chose la plus importante dans ce cas : l’équipe est passée de la discussion sur les symptômes à l’action en une seule journée.
Limites de la sécurité et modèle commercial
PDF Forensic par erreur IP disponible sur Total
Plan . 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, nous ne mélangeons 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 réellement besoin chaque jour.
Qu’est-ce que cela signifie pour la stratégie de Vezha
Cette 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 sur 7 jours est à peu près cela :
- routine manuelle en moins à un moment critique ;
- transfert plus rapide du contexte entre les rôles ;
- Des décisions plus claires basées sur des faits et non sur des hypothèses.
Également important, 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 d’équipe.
Effet opérationnel dans les numéros de processus
Nous avons consciemment 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 progressivement fin à l’incident.
Comment utiliser le rapport dans les 30 premières minutes de l’incident
Pour tirer le meilleur parti de la 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 des 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. Après avoir stabilisé l’environnement, ajouter des améliorations structurelles à l’arriéré pour réduire la répétition des dossiers.
Lorsque ce cycle est élaboré, l’équipe improvise moins en mode « chaud » et passe plus rapidement à un scénario de réponse maîtrisée.
Erreurs typiques que le #099 permet d’éviter
Lors des entretiens avec les équipes techniques, nous avons systématiquement 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éagissez uniquement au RPS. Un trafic élevé en soi n’est pas toujours 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 pour un segment temporel. Sans une fenêtre de 7 jours, les vagues répétitives sont faciles à manquer.
- Erreur n°3 : Décisions verbales 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 manque une fenêtre pour une intervention rapide et peu coûteuse.
C’est pourquoi nous avons privilégié le format PDF : il discipline le processus, standardise la communication et réduit « l’effet téléphone cassé » entre les rôles.
Là où cette opportunité donne le plus grand effet
D’après notre expérience, ce sont les contours où 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 :
- Commerce électronique 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éaction coordonnée devient décisif. Le numéro 099 comble simplement cet écart.
Une checklist pratique avant d’allumer votre circuit
Pour 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 résolution des incidents dans les équipes de soir/nuit ;
- déterminer le canal de remontée standard (SOC, lead SRE, responsable d’astreinte) ;
- fixer le « seuil d’action » pour lancer le processus médico-légal afin d’éviter des fluctuations inutiles ;
- convenir des actions post-incident qui doivent être incluses dans le backlog après stabilisation.
Cela prend peu de temps, mais améliore considérablement la qualité du premier mois d’utilisation de la fonctionnalité.
Résumé du numéro 099
Il 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 à 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 та надішліть запит на демо.