Un peu plus longtemps, un peu moins cher · Économisez 28 % pour 6 mois ou 50 % pour un an, payés une fois Voir les forfaits ↗

Accès et exploitation · 5 min de lecture

Rendez le travail derrière la page prévisible.

Un service peut sembler sain alors que les rappels s'arrêtent, le nettoyage stagne ou le travail de la veille s'exécute deux fois. Traitez les tâches en arrière-plan et les notifications comme des parties nommées du service, avec une planification, un résultat observable et une personne responsable lorsque ce résultat est absent.

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.

1. Listez ce qui se produit sans une visite de page.

Regardez au-delà de la page web visible. Un service de fichiers peut nettoyer les téléversements temporaires, créer des aperçus ou actualiser des dossiers externes. Un wiki peut envoyer des messages de récupération de compte ou notifier un autre système après une modification. Un calendrier peut émettre des rappels. Pour chaque tâche, distinguez son déclencheur de son résultat : « planifié à minuit » n'est pas une preuve que le nettoyage est terminé.

Certains logiciels proposent plusieurs mécanismes de planification aux comportements différents. Nextcloud 33, par exemple, documente les tâches AJAX déclenchées par visite de page et des alternatives planifiées séparément, recommandant cron pour une exécution régulière. Un service silencieux peut donc nécessiter une planification plus délibérée, pas moins. Suivez la documentation correspondant à la version et à la méthode d'installation que vous utilisez. Tâches en arrière-plan de Nextcloud 33.

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étiqueDéclencheurRésultat utileEn cas d'échec
Résumé hebdomadaire du wikiCalendrier hebdomadaire convenuUn résumé pour les destinataires prévusL'éditeur vérifie la liste des destinataires et le chemin de livraison
Nettoyage des fichiersCalendrier de maintenance de l'applicationTravail temporaire éligible suppriméLe mainteneur vérifie les erreurs de tâche et la croissance du disque
Rappel de calendrierRappel configuré de l'événementRappel attendu pour un événement de testLe propriétaire vérifie les paramètres d'événement et l'expéditeur
Sauvegarde indépendanteCalendrier de sauvegarde convenuNouveau 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.