Liste de contrôle de préparation à la production

Utilisez cette liste comme un registre d’approbation, et non comme une liste qu’un opérateur coche en silence. Le responsable du service définit les chemins critiques pour l’activité, le responsable de la plateforme prouve la reprise de l’infrastructure, le responsable de la sécurité approuve l’identité et l’exposition, et les responsables des applications prouvent la gestion des données et le retour arrière. Attribuez chaque section avant la revue de préparation.

Une installation prête pour la production a des responsables connus, une reprise testée, des chemins clients observables, et la preuve que les pannes courantes n’exigent pas d’improviser sur l’hôte. Réussir un build ou voir des cartes au vert dans l’interface est nécessaire, mais pas suffisant.

Plan de contrôle

• L’URL HTTPS canonique, les cookies, les WebSockets et les redirections OAuth fonctionnent.
• PostgreSQL, Redis, l’identité de Relay, les clés de chiffrement et les artefacts téléversés sont persistants et sauvegardés.
• Relay détient le port public 9443/tcp et se rétablit après un redémarrage.
• Au moins deux relais s’exécutent sur des hôtes autres que l’hôte Opfield, dans des domaines de panne différents (hôte, alimentation, chemin réseau) ; voir Combien de relais.
• L’état de la licence et les droits requis sont sains.

Identité

• Deux chemins de récupération indépendants existent pour les administrateurs.
• La MFA et les scopes des groupes sont testés avec de vrais utilisateurs non administrateurs.
• Les identifiants d’API, OAuth et MCP sont à privilèges minimaux et inventoriés.

Nœuds gérés

• Chaque rôle signale les capacités et le canal de mise à jour attendus.
• Le comportement hors ligne, le redémarrage du démon, le redémarrage du nœud et la reconnexion sont testés.
• Les pare-feu n’autorisent que le trafic documenté.
• Les nœuds Storage joignent ghcr.io, et un nœud Storage LXC dispose d’un ensemble de périphériques loop dimensionné pour chaque instance managée et chaque sauvegarde simultanée.
• Les nœuds Docker qui détiennent des baux Availability exécutent le lease watchdog et joignent chaque relais.

Charges de travail et données

• Le déploiement, la vérification de santé, le retour arrière, les journaux, la sauvegarde et la restauration sont prouvés.
• Les liaisons de bases de données managées survivent aux tests de redémarrage d’Opfield, de Relay, du démon et du nœud, ainsi qu’à la recréation des charges de travail.
• Aucun identifiant de propriétaire ne figure dans la configuration des charges de travail.

Trafic client

• Le DNS, le renouvellement TLS, la migration de l’ingress, le mode maintenance et la panne d’un upstream sont testés.
• Les notifications et la communication via la page de statut atteignent les destinataires prévus.

Exploitation

• Les runbooks de mise à jour et de retour arrière ont des responsables.
• Les alertes sur le disque, les certificats, les bases de données, les files d’attente, Relay et les nœuds sont actives.
• Un exercice d’incident a été mené sans s’appuyer sur des modifications shell non documentées.

Dossier de preuves

N’approuvez pas la production sur la seule base d’une inspection visuelle. Conservez les éléments de preuve concernant :

• la version de l’installation et les empreintes des images ;
• la réussite des sauvegardes et un test de restauration récent ;
• la vérification externe DNS/TLS/HTTP ;
• les tests de permissions non administrateur ;
• les tests de redémarrage et de reconnexion des nœuds pour chaque rôle déployé ;
• le comportement au redémarrage d’Opfield, de Relay, des démons et des charges de travail ;
• les résultats des requêtes via les liaisons de bases de données avant et après la recréation ;
• l’ouverture et le rétablissement des alertes et l’envoi des notifications ;
• la répétition de la mise à jour et du retour arrière ;
• les exceptions non résolues, avec responsable et échéance.

Point de décision go/no-go

Le déploiement est no-go lorsque la récupération des administrateurs n’est pas testée, que les clés persistantes ne sont pas sauvegardées, que le trafic de production dépend du seul relais local, que Relay a un chemin de reprise inconnu, que des erreurs de capacités des nœuds sont ignorées, que le trafic client ne peut pas être vérifié de l’extérieur, ou qu’une liaison de base de données nécessite une réparation manuelle de conteneur ou de rôle.

Une exception temporaire acceptée doit indiquer l’impact client, le contrôle compensatoire, le responsable, l’échéance et le déclencheur de retour arrière. « Ça fonctionne sur l’hôte actuel » n’est pas un argument de préparation à la production.

Observation du premier jour

Après l’activation du trafic métier, surveillez la santé des Routes, TLS, la pression sur Relay, la fraîcheur des nœuds, les redémarrages des charges de travail, les connexions aux bases de données, la croissance du disque, les files de notifications et l’activité d’audit. Gardez le responsable du retour arrière disponible pendant toute la fenêtre d’observation et évitez les changements de plateforme sans rapport.

Format de la revue de préparation

Tenez la revue sur une version et une installation nommées. Pour chaque domaine, consignez pass, accepted exception ou no-go, avec un lien vers les preuves et un responsable. Ne reportez pas des preuves d’une version antérieure lorsque le composant concerné de cycle de vie, de démon, de Relay, de base de données ou d’ingress a changé.

Utilisez une ligne par vérification de recette, afin qu’un relecteur moins expérimenté puisse voir ce qui a été testé et qu’un utilisateur avancé puisse le reproduire :

Domaine	Responsable	Vérification effectuée	Résultat	Preuve	Exception ou suite à donner
Exemple : application publique	Équipe applicative	DNS externe, TLS et parcours utilisateur principal	Pass	Lien vers une tâche, une requête ou un rapport	Aucune

N’écrivez pas seulement « fonctionne » ou « vérifié ». La preuve doit identifier la ressource, la version, le lieu du test, l’heure et le résultat attendu exacts.

Commencez par les trois parcours qui auraient un impact métier immédiat : la récupération des administrateurs, le trafic client public et l’accès des applications aux données persistantes. Examinez ensuite les fonctionnalités de support comme les builds, Pages, les notifications, l’IA et les intégrations facultatives selon ce que l’installation utilisera réellement. Les fonctionnalités inutilisées et non testées ne bloquent pas le lancement ; les fonctionnalités critiques activées, si.

Scénarios de recette minimaux

1. Un nouvel utilisateur autorisé se connecte, valide la MFA et se voit refuser une ressource hors périmètre.
2. Une charge de travail prise en charge est déployée, observée, redémarrée et ramenée en arrière sans modification de l’hôte.
3. Une Route publique est vérifiée depuis un réseau externe, avec le certificat et le comportement de santé attendus.
4. Un nœud géré se déconnecte puis se reconnecte sans perdre l’état souhaité.
5. Opfield redémarre tandis que les charges de travail clientes restent dans leur état documenté.
6. Une sauvegarde est restaurée dans un environnement compatible propre, et les secrets requis se déchiffrent.
7. Les alertes s’ouvrent et se rétablissent lors d’une panne contrôlée, et le destinataire prévu les reçoit.

L’approbation doit indiquer le périmètre testé. N’affirmez pas que l’ensemble du produit est validé alors qu’un seul rôle de nœud, un seul moteur de base de données, un seul profil d’exécution ou un seul chemin de mise à jour a été exercé.