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 ↗

Planification de service · 5 min de lecture

Donnez à votre wiki partagé un petit plan complet.

Un wiki partagé a besoin de plus qu'un endroit où déposer des pages. Attribuez-lui un propriétaire nommé, une carte des dépendances, un modèle de permissions restreint et une vérification de récupération qui inclut ses pièces jointes. Cette fiche de travail aide un groupe à décider ce qu'il est prêt à maintenir.

Avant de commencer

  • Une liste des personnes qui liront, modifieront et administreront le wiki.
  • La documentation du wiki choisi et de sa version prévue.
  • Un emplacement pour les notes d'exploitation et un emplacement distinct et contrôlé pour les identifiants de récupération.

1. Décrivez la tâche que le wiki accomplira.

Commencez par une phrase : « Les membres utilisent ce wiki pour trouver les instructions à jour de notre atelier partagé. » Cet objectif hypothétique est plus étroit que « tout mettre en ligne ». Il suggère une première collection gérable : procédures d'ouverture, notes sur le matériel et décisions issues des réunions. Les coordonnées personnelles et les identifiants d'accès nécessitent leurs propres décisions ; une zone de recherche pratique n'est pas une raison de les collecter.

Listez ce qu'un lecteur doit accomplir, comme trouver la procédure la plus récente, ouvrir un schéma référencé et savoir qui est responsable d'une page obsolète. Choisissez un petit échantillon de contenu réel pour évaluer l'application plus tard. Ne déduisez pas un besoin en mémoire du seul nombre de membres : les téléversements, l'indexation, les extensions et le travail simultané peuvent modifier la charge.

2. Consacrez une page aux dépendances.

Utilisez cet exemple comme carte de départ, puis remplacez chaque hypothèse par la disposition de l'application que vous avez choisie. « Propriétaire » désigne la personne qui peut expliquer et récupérer ce composant, pas nécessairement celle qui l'a installé.

PartieCe qui doit figurer dans le carnetQuestion de récupération
Application webVersion, emplacement de la configuration et propriétaire du serviceUn autre mainteneur peut-il reconstruire la même version ?
Base de donnéesMoteur, version et méthode de sauvegardeQuel instantané va avec les fichiers ?
Images et pièces jointesChemins de stockage et estimation de la croissanceUne page restaurée ouvre-t-elle son schéma ?
DNS et HTTPSPropriétaire du compte de domaine et méthode de certificatQui peut réparer l'accès sans le wiki ?
Courriel et tâches planifiéesExpéditeur, planification et responsable des échecsQu'est-ce qui fonctionne encore quand la livraison échoue ?

Consignez aussi la recherche : fait-elle partie de l'application, d'un index reconstructible ou d'un autre service ? Ne supposez pas qu'un index peut être écarté tant que la documentation de l'application ne confirme pas comment le reconstruire.

3. Séparez la lecture, l'édition et l'administration.

Pour l'exemple de l'atelier, les membres lisent les procédures, un petit groupe d'édition les modifie et deux mainteneurs autorisés gèrent les comptes. L'administration de l'hébergement est une responsabilité distincte. Notez qui peut publier une page, téléverser des fichiers, exporter du contenu et modifier les permissions. Décidez comment un membre partant perd son accès et qui examine les pages qu'il maintenait.

Les règles de permissions d'une application peuvent se combiner de façon surprenante. BookStack, par exemple, combine les capacités de tous les rôles d'un utilisateur et prend en charge des dérogations au niveau du contenu ; les permissions d'une étagère ne se propagent pas automatiquement à ses livres. Vérifiez le résultat effectif avec des comptes de membres ordinaires, pas seulement avec un compte administrateur. Rôles et permissions BookStack.

4. Gardez l'ensemble de récupération regroupé.

Attribuez à chaque ensemble de sauvegarde une date, une version d'application et une note indiquant quelles copies de base de données et de fichiers vont ensemble. Conservez les instructions dans un endroit qui reste accessible si le wiki tombe en panne. Gardez les secrets dans un stockage de secrets approprié ; le carnet doit indiquer qui peut les récupérer et où, sans en reproduire les valeurs.

Pour un exemple d'application concret, les conseils de sauvegarde de BookStack couvrent les enregistrements de base de données ainsi que la configuration, les images téléversées, les pièces jointes et les thèmes éventuels. Sa configuration comprend une clé liée aux données chiffrées de l'application ; copier uniquement les pages visibles laisse donc de côté des éléments de récupération importants. Suivez la procédure propre à l'application pour votre version. Sauvegarde et restauration BookStack.

Choisissez une destination de copie indépendante et une personne nommée pour vérifier qu'elle reste accessible.

5. Convenez d'une routine que le groupe peut tenir.

Choisissez un intervalle de révision que les mainteneurs peuvent réellement tenir. À chaque révision, examinez les sauvegardes échouées, les mises à jour applicatives en attente, la croissance des pièces jointes et les comptes qui n'ont plus besoin d'accès. Gardez les mises à jour de sécurité urgentes hors de cette routine lorsqu'elles exigent une attention plus précoce. Écrivez la prochaine action et son responsable plutôt que de collectionner une liste toujours croissante de préoccupations vagues.

Dans l'exemple, le groupe d'édition vérifie aussi une courte liste « à réviser ». Une procédure d'équipement sans responsable doit être visiblement marquée pour révision au lieu de sembler tranquillement faire autorité. Avant une mise à jour importante, notez la version qui fonctionne, les instructions de migration de l'application et le point de récupération que vous comptez utiliser si la validation échoue.

6. Prouvez le chemin utile, puis consignez les lacunes.

Sur une copie de test distincte, demandez au second mainteneur de trouver une page d'exemple, d'ouvrir sa pièce jointe, d'effectuer une modification autorisée et d'essayer une action que son compte ne devrait pas permettre. Vérifiez un résultat de recherche après une modification de contenu. Consignez les résultats attendus et observés ; une simple connexion réussie ne prouve pas que le wiki est utilisable ou correctement restreint.

Si une pièce jointe manque, comparez son emplacement de stockage et son ensemble de sauvegarde avant de modifier des enregistrements de base de données. Si les permissions diffèrent, inspectez les rôles des comptes et les dérogations de contenu avant d'élargir l'accès. Si l'application ne démarre pas, arrêtez l'exercice et consignez l'incompatibilité de version ou de configuration. Ce sont des étapes d'acceptation à réaliser, pas des tests rapportés de l'infrastructure Hoszen.

7. Laissez un chemin de sortie.

Choisissez un chapitre représentatif à exporter et demandez si quelqu'un pourrait le lire sans le wiki d'origine. Traitez cette copie lisible comme un livrable distinct de l'ensemble de récupération : elle peut ne pas préserver les comptes, les permissions ou les paramètres de l'application. Convenez de qui maintient cette copie de sortie lorsque le contenu change.

Votre plan final doit tenir à côté du l'inventaire des services, pas le remplacer. Continuez avec un dossier d'export portable et un exercice de restauration. L'objectif est un wiki qu'une autre personne autorisée peut comprendre et récupérer ; aucune application n'est installée par ce guide.

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.