Assumer la responsabilité du service après son déploiement

Définir le service dont les utilisateurs dépendent

Le déploiement rend le logiciel disponible. L’exploitation le garde utile lorsque les utilisateurs, les dépendances, le trafic et les exigences changent. Un générateur de code ne supprime pas ce travail continu.

Pour un export client fictif, les utilisateurs ont besoin de plus qu’une page accessible. Il leur faut les enregistrements autorisés, au format requis, dans un délai acceptable. Le service doit aussi empêcher l’accès aux données d’une autre organisation.

Désignez le responsable avant la mise en production. Consignez qui répond en dehors des horaires habituels si cela fait partie de l’engagement de service. Un fournisseur peut effectuer une partie du travail, mais l’organisation a toujours besoin d’un circuit clair pour les décisions et la communication.

Choisir des signaux qui aident à agir

Un indicateur de niveau de service, ou SLI, mesure une propriété définie du comportement du service. Un objectif de niveau de service, ou SLO, fixe une cible pour cet indicateur sur une période donnée. Choisissez la cible selon les besoins utilisateurs et les capacités d’exploitation.

Les recommandations SRE de Google expliquent cette approche et l’usage d’un budget d’erreur pour les décisions de fiabilité. Ne copiez pas la cible d’un autre service sans vérifier sa signification. Conseils sur les SLO, exemple de politique de budget d’erreur.

Pour l’export, définissez ce qui constitue une requête admissible réussie. Séparez les refus attendus des défaillances du système. Documentez les exclusions pour qu’une métrique ne puisse pas s’améliorer simplement en masquant les requêtes difficiles.

Évitez de journaliser les exports complets pour gagner en visibilité. Collectez le minimum nécessaire au diagnostic et protégez l’accès à ces informations.

Préparer la réponse aux incidents

Déterminez qui coordonne, qui enquête et qui communique. Une petite équipe peut cumuler ces rôles, mais les responsabilités doivent rester claires. Conservez une trace des observations et des actions.

Les recommandations de Google sur les incidents insistent sur la coordination et la communication, en plus de l’atténuation technique. Un correctif techniquement juste peut laisser les utilisateurs sans information ou plusieurs intervenants effectuer des changements contradictoires. Réponse aux incidents.

Un agent peut résumer des journaux ou comparer des hypothèses dans les limites de données approuvées. L’urgence de l’incident ne doit pas lui donner des pouvoirs illimités en production. Utilisez une procédure d’escalade définie pour les accès exceptionnels.

Tester la reprise et financer la maintenance

Testez la procédure de reprise avec des données fictives représentatives. Identifiez ce qu’un retour arrière du code ne peut pas annuler, notamment des enregistrements supprimés ou des messages déjà envoyés. Consignez le temps et les informations nécessaires au rétablissement du service.

Attribuez le travail continu : mises à jour des dépendances, revues d’accès, renouvellement des certificats le cas échéant, changements de capacité et corrections documentaires. Un service sans capacité de maintenance accumule des obligations après épuisement du budget de lancement.

Après un incident, choisissez des améliorations qui traitent les causes observées. Reliez-les à l’implémentation et à la vérification. Cela boucle le cycle de vie : les preuves d’exploitation modifient ce que l’équipe spécifie et construit ensuite.