Écrire la décision avant de modifier le système
Ce guide est un exercice de planification pour un opérateur d'application. Il ne représente pas un déploiement PrivacyNodes, une action d'assistance ni un résultat client mesuré. Listez chaque dépendance externe et attribuez-lui un budget fini de connexion, de réponse et de requête globale. L'API doit laisser suffisamment de temps pour renvoyer un échec utile plutôt que d'accumuler des requêtes en attente.
Répéter la modification avec des entrées contrôlées
Ne réessayez que les opérations dont le comportement de répétition sûre est défini. Utilisez des tentatives limitées, un délai et un identifiant de requête ou de tâche afin qu'un échec transitoire ne crée pas d'e-mails, de paiements ou d'exports en double.
Utilisez des requêtes synthétiques et des identités de test pendant la vérification de la modification. N'exposez pas de secrets ni de données clients dans une commande, un extrait de journal ou une note d'assistance.
Vérifier le résultat et consigner la limite restante
Exercez une dépendance retardée dans un environnement hors production et inspectez le nombre de requêtes, l'âge de la file d'attente et l'erreur visible par l'utilisateur. Supprimez une tentative qui aggrave l'échec.
Consignez l'heure UTC, la révision de l'artefact ou de la configuration, les symptômes expurgés et le prochain responsable.
Référence officielle
Cette source a été examinée pour la limite technique de ce guide ; elle ne documente pas un test ou une capacité fournisseur de PrivacyNodes.