Séparez les contrôles d’état du VPN des contrôles d’état de l’application

Votre processus de tunnel peut tourner alors que la connexion protégée est inutilisable, et une page web qui échoue ne prouve pas que le tunnel est cassé. Quand une seule sonde représente toutes les autres, une politique de redémarrage redémarre le mauvais composant et appelle cela de l’automatisation. Chaque contrôle ci-dessous nomme la couche qu’il observe, l’action que son échec déclenche et la preuve que l’action a fonctionné. La dernière étape transforme l’ensemble en une page que quelqu’un peut suivre à trois heures du matin.

Étape 1 : nommez la couche qu’observe chaque contrôle

Demandez ce que chaque sonde peut réellement voir avant d’en écrire une seule. La vivacité prouve que le démon tourne, une poignée de main ou une liste de pairs prouve que la relation existe, une requête routée prouve la livraison et une résolution prouve la résolution de nom. Elles échouent exactement dans cet ordre, et aucune n’implique la suivante. Un contrôle de processus vert à côté d’un tunnel mort est le cas normal, pas une contradiction.

Écrivez les quatre contrôles dans cet ordre, avec la commande exacte et la sortie attendue pour chacun. Une sonde dont vous ne pouvez pas énoncer la sortie attendue sera lue différemment par chaque opérateur qui voit l’alerte. Mettez la même liste dans le texte de l’alerte, pas seulement dans le runbook, pour que la personne réveillée la nuit rencontre la couche avant le symptôme. Gardez chaque commande prête à être copiée sur l’hôte qui l’exécute.

Ajoutez ensuite le contrôle de l’application comme cinquième élément, séparé. Une page dont le service de comptes est en panne ne justifie pas de redémarrer le tunnel.

Étape 2 : liez chaque échec à une seule action

Pour chaque contrôle, décidez ce qui redémarre, ce qui reste bloqué et ce qui alerte un humain. Un échec de la couche tunnel peut justifier un redémarrage du tunnel ; un échec du résolveur pointe vers l’intégration DNS sur le client ; un échec de la couche application ne devrait presque jamais toucher le tunnel.

Dites ce qu’un échec ne doit pas faire, car les valeurs par défaut dangereuses sont les permissives. Un état non sain ne doit jamais devenir une autorisation de trafic applicatif direct, car une solution de repli qui contourne silencieusement le tunnel supprime la raison d’être du tunnel. Resserrez aussi les actions : redémarrer un composant partagé parce qu’une destination est lente transforme un problème local en problème pour toute la flotte. Cela détruit aussi la preuve dont vous aviez besoin pour trouver la cause.

Étape 3 : gardez les sondes inoffensives et bon marché

Utilisez de petites requêtes en lecture seule : une ressource statique, un point de terminaison d’état qui rapporte sa propre dépendance ou une connexion TCP vers un port que vous contrôlez. Évitez les identifiants, la navigation privée et tout ce qui modifie l’état à chaque intervalle, car une sonde qui écrit est un test de charge planifié.

Enregistrez la destination, l’attente de route et le délai d’expiration de chaque sonde. L’attente de route est le champ que les gens omettent, et c’est elle qui sépare un échec de tunnel d’une erreur de routage quand vous lisez l’alerte plus tard. Dérivez l’intervalle et le seuil d’échec du temps de rétablissement que vous promettez, et gardez le délai d’expiration plus court que l’intervalle. Une sonde encore en cours quand la suivante démarre signale un échec deux fois et ressemble à un clignotement.

Étape 4 : cassez chaque couche et regardez la bonne sonde passer au rouge

Arrêtez le processus du tunnel et confirmez que le contrôle de processus échoue alors que le DNS peut encore répondre depuis le cache. Changez une route et confirmez que la requête routée échoue alors que le processus et la poignée de main restent sains. Cassez le DNS seul et confirmez que le contrôle de l’application signale une résolution plutôt qu’une erreur de tunnel. Si deux sondes bougent toujours ensemble, vous avez moins de contrôles que vous ne le pensez.

Testez la direction du rétablissement avec la même discipline. Après avoir restauré la couche, la sonde devrait se rétablir sans redémarrage manuel, et l’action déclenchée ne devrait laisser aucun contournement derrière elle. Observez un cycle complet avant de faire confiance à l’état vert, car une sonde qui ne se rétablit qu’à la main cache un chemin de rétablissement cassé.

Étape 5 : placez le runbook là où pointe l’alerte

Une page de cinq lignes porte toute la conception : couche, commande, résultat attendu, action en cas d’échec, propriétaire. Ajoutez une ligne par sonde sur ce qu’elle ne teste délibérément pas. C’est cette ligne qui empêche la personne suivante d’ajouter un sixième contrôle qui mesure tout et ne distingue rien. Liez la page depuis le texte de l’alerte, sinon personne ne l’ouvrira pendant l’incident.

Dans les déploiements de conteneurs, une condition de dépendance façonne le démarrage et rien d’autre. La documentation sur l’ordre de démarrage et la condition d’état de Compose décrit comment la disponibilité détermine l’ordre dans lequel les services démarrent ; rien de tout cela n’applique ensuite de politique de sortie, et rien de tout cela n’échoue fermé quand le tunnel tombe. L’application continue a besoin de sa propre politique et de sa propre sonde, écrites sur la même page.

Le runbook est terminé quand la bonne couche se rétablit sans que personne ne lise un site indisponible comme un tunnel cassé. Cela teste le document, pas le tunnel.