Avant de commencer
- Une liste des applications, planificateurs et services externes utilisés.
- Accès à l'état des tâches applicatives et à des journaux correctement expurgés.
- Un environnement de test séparé et une destination approuvée pour les notifications de test.
2. Attribuez à chaque tâche une courte fiche d'exploitation.
Utilisez une ligne par élément de travail distinct. Ajoutez le fuseau horaire, l'identité d'exécution, la durée normale une fois mesurée, le dernier résultat utile et le responsable en cas d'échec. Ne mettez pas de mots de passe, jetons ou corps complets de notifications privées dans la fiche.
| Tâche hypothétique | Déclencheur | Résultat utile | En cas d'échec |
|---|---|---|---|
| Résumé hebdomadaire du wiki | Calendrier hebdomadaire convenu | Un résumé pour les destinataires prévus | L'éditeur vérifie la liste des destinataires et le chemin de livraison |
| Nettoyage des fichiers | Calendrier de maintenance de l'application | Travail temporaire éligible supprimé | Le mainteneur vérifie les erreurs de tâche et la croissance du disque |
| Rappel de calendrier | Rappel configuré de l'événement | Rappel attendu pour un événement de test | Le propriétaire vérifie les paramètres d'événement et l'expéditeur |
| Sauvegarde indépendante | Calendrier de sauvegarde convenu | Nouveau point de récupération avec un résultat enregistré | Le propriétaire de la sauvegarde enquête avant de supposer la couverture |
Les plannings ci-dessus sont des exemples à décider, pas des valeurs par défaut à copier dans une application. Enregistrez le comportement du travail manqué après une indisponibilité : ignoré, rattrapé ou mis en file d'attente pour plus tard.
3. Tracez une notification au-delà de « envoyer ».
Écrivez le chemin depuis l'événement applicatif vers la file d'attente ou le processus d'envoi, puis vers le service de messagerie et le destinataire prévu. Notez qui contrôle le compte d'envoi, où les mainteneurs autorisés obtiennent les identifiants et quelles limites ou rapports d'échec ce service fournit. Une sélection de ressources VPS ne fournit pas en soi un système d'envoi de courrier sortant fonctionnel.
La documentation de Nextcloud décrit explicitement la connexion à un serveur de messagerie fonctionnel plutôt que le fait de contenir un serveur de messagerie complet. Sa fonction de test d'e-mail aide à vérifier un chemin d'envoi configuré. Configuration e-mail de Nextcloud 33.
BookStack utilise également le courrier pour les flux de gestion de compte et propose des webhooks sortants pour les intégrations pilotées par les événements. Ajoutez les deux à la carte des dépendances lorsqu'ils sont activés ; un expéditeur défaillant peut affecter la récupération ainsi que la commodité. E-mail et webhooks de BookStack.
4. Décidez ce que signifie la répétition.
Pour chaque tâche, posez deux questions : une autre exécution peut-elle commencer avant que celle-ci ne se termine, et que se passe-t-il si elle réessaie après avoir effectué une partie de son travail ? Une mise à jour d'index de fichiers et un message envoyé à tous les membres ont des conséquences différentes. Enregistrez le comportement de concurrence et de réessai de l'application plutôt que de supposer que toutes les tâches peuvent s'exécuter deux fois en toute sécurité.
Dans le résumé hebdomadaire hypothétique, le propriétaire conserve une trace de la période de rapport prévue et vérifie si cette période a déjà produit un envoi terminé avant de réessayer manuellement. Il s'agit d'un contrôle d'exploitation, pas d'une affirmation que l'application choisie implémente la suppression des doublons. Si elle ne fournit pas de contrôles adéquats, choisissez une procédure de récupération manuelle plus sûre avant de vous fier à la tâche.
5. Contenez les effets de bord pendant une restauration.
Une base de données restaurée peut contenir du travail en attente ou un état d'événement plus ancien. Avant de démarrer une copie de test, empêchez-la de contacter de vrais destinataires ou des systèmes externes. Isolez l'environnement de test, désactivez ses planificateurs et workers selon le cas, et dirigez la sortie de test explicitement autorisée vers une destination contrôlée. Ne supposez pas qu'un nom d'hôte différent modifie les destinataires stockés ou les URL de webhook.
Pour l'exemple d'atelier, la copie de test devrait permettre à un mainteneur de vérifier une page et une pièce jointe sans renvoyer le résumé de la semaine dernière. Enregistrez quelles tâches restent arrêtées, comment vous inspecterez le travail en attente et qui peut autoriser une exécution de test limitée. Avant un basculement réel, définissez quelle instance est responsable du travail planifié afin que les anciennes et nouvelles copies ne l'exécutent pas toutes les deux.
6. Vérifiez un petit résultat observable.
Utilisez un événement de test inoffensif avec un libellé reconnaissable et un seul destinataire de test approuvé. Enregistrez l'heure du déclencheur, le début de la tâche, le résultat d'achèvement et la réception réelle le cas échéant. Vérifiez le contenu et les liens ainsi que l'arrivée. Une action applicative réussie ne prouve pas que chaque destinataire prévu a reçu un message.
Si rien n'arrive, inspectez le déclencheur, le planificateur, l'erreur de tâche et le chemin de l'expéditeur dans l'ordre. Si des doublons arrivent, arrêtez les réessais manuels répétés et identifiez quelle instance ou tâche a produit chaque tentative. Si le travail est retardé, comparez l'âge de la file d'attente ou des tâches en attente avec le temps d'exécution et l'utilisation des ressources. Conservez des preuves concises sans copier de jetons, de corps de messages privés ou d'adresses inutiles dans les notes générales.
7. Attribuez la prochaine vérification.
Choisissez un intervalle de révision adapté à la conséquence d'une défaillance. Un expéditeur de récupération de compte défaillant nécessite une réponse différente d'un résumé hebdomadaire en retard. Définissez qui vérifie le dernier résultat réussi lorsqu'une alerte est absente, et assurez-vous que le canal d'alerte lui-même n'est pas le seul moyen de découvrir un expéditeur défaillant.
Conservez les fiches de tâches avec votre l'inventaire des services. Ajoutez-les à la exercice de restauration et les routine de maintenance. Ce guide décrit une façon d'organiser et de tester le logiciel que vous avez choisi ; il ne fournit pas de planificateur géré, de garantie de livraison de messages ni de résultat de test exécuté.
Documentation à l'appui de cette note
Utilisez la documentation de la version que vous exécutez réellement. Ces exemples sont du matériel de planification, et non un compte rendu d'un test sur un VPS Hoszen.