Runbook d'incident

Ce runbook aide le responsable de l’incident à protéger le service client, à établir quel sous-système est à l’origine de la panne et à choisir un chemin de reprise réversible. Le responsable de l’incident décide des priorités et de la communication ; l’opérateur de plateforme est responsable des éléments de preuve concernant Opfield et les nœuds gérés ; les responsables des applications et des bases de données valident leurs services. Ne laissez pas la personne qui saisit les commandes devenir la seule à décider des risques.

Le succès signifie que l’impact client est compris, que les changements ultérieurs sont maîtrisés, que l’état d’exécution faisant autorité est réconcilié et que la reprise est vérifiée depuis le chemin visible par les utilisateurs. Un tableau de bord au vert ne constitue pas à lui seul une preuve de reprise.

Les cinq premières minutes

1. Consignez l’heure de début, le chemin client concerné et les changements récents.
2. Vérifiez la santé d’Opfield, de PostgreSQL, de Redis et de Relay.
3. Déterminez si l’impact concerne le plan de contrôle, l’ingress, un nœud, une charge de travail ou une dépendance partagée.
4. Gelez les changements sans rapport.
5. Utilisez le mode maintenance ou un incident sur la page de statut lorsque l’impact client est confirmé.

Relay indisponible

Examinez le service Relay, le volume d’identité, la joignabilité de la base de données, la version de l’image et le port public 9443/tcp. Dans Settings > Relay, vérifiez l’état de confiance dans la politique et l’état du certificat de chaque membre : Opfield rétablit automatiquement la confiance du relais local, et un membre distant marqué pour réenrôlement ou dont le certificat a expiré peut être rétabli avec Re-enroll ou Renew certificate ; voir Reprise de Relay en 2.11. Ne ramenez pas le port vers l’application et ne contournez pas l’autorisation avec un nouvel écouteur public.

Nœud hors ligne

Les charges de travail existantes peuvent continuer. Les politiques Availability en mode bail déplacent d’elles-mêmes les slots du nœud vers d’autres candidats ; vérifiez Lease mode et les détenteurs dans le résumé Availability de la charge de travail avant d’agir. Vérifiez l’alimentation et le réseau de l’hôte, le service démon, l’heure, l’identité du certificat et la joignabilité sortante de Relay. Ne modifiez rien à partir d’un inventaire périmé.

Mauvaise version

Pour les Deployments, revenez au slot sain précédent. Pour Pages, déplacez le tag. Pour les conteneurs construits depuis Git, redéployez la dernière empreinte approuvée. Si la cible signale BUILD_ROLLOUT_IN_PROGRESS, attendez que le déploiement en cours se termine ou échoue avant de redéployer. Conservez les journaux et l’historique des opérations.

Échec d’une liaison de base de données

Vérifiez Relay, les deux nœuds, la santé de la base de données, l’état souhaité de la liaison, le lien de la liaison sur le connecteur secure-link du nœud cible et le principal dans le moteur. Relancez la réconciliation avant toute modification manuelle d’identité ; il n’existe ni conteneur connecteur par liaison ni écouteur sur l’hôte à redémarrer ou à remplacer.

Utilisez les vérifications couche par couche de Liaisons applicatives aux bases de données et conservez la tâche en échec avant de réessayer. Lorsque les clients signalent Connection terminated unexpectedly ou ECONNRESET sous charge, en particulier pendant un déploiement, lisez d’abord l’exécution du lien : un throttledTotal croissant, consigné sur le nœud sous managed link connection rejected avec reason=link_limit, signifie que les pools des conteneurs dépassent la capacité du lien, c’est-à-dire la limite de connexions propre à la base, partagée par tous ses liens ; voir Capacité des liens et pools de connexions.

Clôture

Confirmez la reprise depuis un client externe, levez délibérément la maintenance, documentez la cause racine et la lacune de détection, et créez des actions de suivi pour chaque mesure d’atténuation temporaire.

Plan de contrôle indisponible

Vérifiez le conteneur ou le processus d’Opfield, PostgreSQL, Redis, les volumes persistants, la pression sur le disque, les migrations et les journaux de l’application. Tant que l’API répond encore, l’assistant ou un client MCP disposant de diagnostics:view peut lire tout cela avec manage_opfield_diagnostics, et diagnostics:logs y ajoute les journaux des conteneurs ; voir Diagnostics d’Opfield. Préservez les clés de chiffrement et la base de données existantes avant de tenter une instance de remplacement. Si les charges de travail clientes continuent, évitez les modifications étendues sur l’hôte pendant le rétablissement du plan de contrôle.

Déterminez d’abord si Relay est encore joignable. Si Relay est sain, la configuration nginx déjà appliquée, les conteneurs, les bases de données et les flux privés existants autorisés peuvent continuer pendant que les nouvelles décisions de gestion et d’autorisation attendent. Les relais continuent d’admettre de nouvelles connexions Secure Link et de liens de bases de données selon leur dernière politique signée pendant la durée du bail de politique, les politiques Availability en mode bail continuent de basculer, et la page de statut publique est servie depuis le cache du nœud Ingress. Si le seul relais est local à l’hôte Opfield en panne, les Secure Links et les sessions des nœuds gérés perdent aussi leur transport ; les charges de travail ordinaires locales aux hôtes peuvent continuer de s’exécuter, mais les flux existants dépendant de Relay ne sont pas garantis. Des membres Relay externes indépendants ne réduisent cette panne partagée que si les nœuds peuvent effectivement les joindre et les utiliser.

Au retour d’Opfield, vérifiez la connexion, le déchiffrement, la santé de Relay, les tâches d’arrière-plan, la détection des mises à jour, les notifications et des instantanés de nœuds récents. Ne supposez pas que les démons se sont réconciliés simplement parce que le tableau de bord se charge.

Utilisez Disponibilité, compatibilité et limites pour classer les chemins concernés, et Mises à jour et sauvegardes avant de restaurer une instance de remplacement ou de modifier l’état persistant.

Panne de l’ingress

Suivez Dépannage de l’ingress du DNS au réseau, à TLS, à l’application de nginx, à la santé de la Route et à l’upstream. Utilisez le mode maintenance lorsque l’hôte virtuel doit rester stable pendant la réparation. Conservez les erreurs de validation de la configuration générée et les éléments des requêtes externes.

Opération de charge de travail bloquée

Examinez la tâche durable, la connexion du nœud propriétaire, l’historique des opérations du démon, la ressource d’exécution et l’identifiant de requête ou d’opération. Un délai dépassé dans le navigateur ne prouve pas que la commande a échoué. Réconciliez la première opération avant de lancer en double une création, une recréation, une migration ou une suppression.

Si Force Cancel est disponible, déterminez s’il annule uniquement le suivi par Opfield ou s’il transmet aussi l’annulation au propriétaire. Après l’annulation, actualisez l’état d’exécution et n’effacez un éventuel marqueur d’opération interrompue que via le chemin de réconciliation pris en charge.

Utilisez Tâches, événements et audit pour distinguer le travail accepté, en cours, annulé et terminé, puis poursuivez avec la ressource Docker propriétaire.

Base de données indisponible

Distinguez les échecs de santé du moteur, de stockage, de publication directe, de liaison managée et de requête applicative. Vérifiez le nœud Storage, le conteneur du moteur, l’image ou le montage de stockage, l’instantané de supervision, le chemin Relay, le nœud Docker cible, le connecteur secure-link du nœud, l’identité de la liaison et la configuration de l’application.

Ne supprimez pas la base de données ou le principal dans le moteur comme étape de diagnostic. Préservez le stockage et l’historique des opérations, puis relancez la réconciliation précise en échec.

Poursuivez avec Exploitation des bases de données pour les vérifications du moteur, du stockage, des sauvegardes et des restaurations, ou avec Liaisons applicatives aux bases de données lorsque seul le chemin applicatif privé est concerné.

Communication et éléments de preuve

Tenez une seule chronologie de l’incident avec des horodatages UTC, les ressources concernées, l’impact visible par les utilisateurs, les changements, les identifiants de tâches et de requêtes, les décisions et les vérifications. Les mises à jour publiques décrivent l’impact et l’avancement sans exposer la topologie ni des détails de sécurité.

Condition de reprise

La reprise exige que :

• le chemin visible par les clients fonctionne depuis l’extérieur du réseau géré ;
• l’état souhaité dans Opfield corresponde à l’état actuel du propriétaire ;
• les alertes se rétablissent pour la bonne raison ;
• les opérations et envois en file d’attente soient compris ;
• les expositions ou contournements temporaires soient retirés ;
• un responsable et une échéance existent pour chaque risque restant.

Cadre de décision pour le responsable de l’incident

Préférez les actions qui préservent les éléments de preuve et réduisent le rayon d’impact. Suspendez l’automatisation sans rapport avant de redémarrer des services partagés. Si le plan de contrôle est indisponible mais que les charges de travail servent encore le trafic, rétablissez la gestion sans recréer les ressources saines. Si l’ingress n’est pas sain, gardez le nom d’hôte stable avec le mode maintenance ou un retour arrière testé plutôt que de modifier le DNS à répétition. Si l’intégrité des données est incertaine, arrêtez les écritures avant d’optimiser la disponibilité.

Escaladez immédiatement lorsque l’incident implique une possible divulgation d’identifiants, un stockage endommagé, un état de migration de schéma inconnu, la perte de l’identité de Relay, une propriété incohérente des liaisons de bases de données ou un artefact de version qui ne peut pas être vérifié. Ces conditions peuvent transformer un redémarrage de routine en perte définitive ou en accès non autorisé.

Tableau des éléments de preuve pour l’opérateur

Élément de preuve	Pourquoi il compte
DNS externe, TLS et réponse de l’application	Confirme l’impact client réel
Santé d’Opfield, de PostgreSQL, de Redis et de Relay	Distingue une panne du plan de contrôle d’une panne du plan de données
Dernière activité du nœud, état des capacités et journaux du démon	Identifie le propriétaire de l’exécution et un inventaire périmé
Identifiants de tâches, d’opérations et de requêtes	Évite les modifications en double ou ambiguës
Dernière version approuvée et empreinte de l’artefact	Fournit une cible de retour arrière connue
État des sauvegardes des bases de données et des volumes	Définit les options de reprise sûres

Après la reprise, effectuez une brève revue tant que les éléments de preuve sont encore disponibles. Consignez le changement déclencheur, pourquoi la détection a fonctionné ou non, quelles étapes manuelles ont été nécessaires et quelle vérification aurait permis de détecter le problème plus tôt. Transformez les instructions temporaires en une modification de runbook testée plutôt que de conserver un historique shell non documenté.