Geef uw gedeelde wiki een compleet klein plan.

1. Beschrijf de taak die de wiki gaat vervullen.

Begin met één zin: “Leden gebruiken deze wiki om de actuele instructies te vinden voor het runnen van onze gedeelde werkplaats.” Dat hypothetische doel is smaller dan “alles online zetten”. Het suggereert een behapbare eerste verzameling: openingsprocedures, apparatuurnotities en besluiten uit vergaderingen. Persoonlijke contactgegevens en toegangsreferenties vragen hun eigen besluiten; een handig zoekvak is geen reden om ze te verzamelen.

Noteer wat een lezer moet kunnen bereiken, zoals de nieuwste procedure vinden, een gerefereerd diagram openen en weten wie eigenaar is van een verouderde pagina. Kies een kleine steekproef van echte inhoud om de applicatie later te beoordelen. Leid een geheugenvereiste niet alleen af uit het aantal leden: uploads, indexering, extensies en gelijktijdig werk kunnen de belasting veranderen.

2. Maak één pagina voor de afhankelijkheden.

Gebruik dit voorbeeld als startkaart en vervang daarna elke aanname door de indeling van de gekozen applicatie. “Eigenaar” betekent de persoon die dat onderdeel kan uitleggen en herstellen, niet per se de persoon die het heeft geïnstalleerd.

Noteer ook zoeken: maakt het deel uit van de applicatie, is het een herbouwbare index, of is het een andere service? Ga er niet van uit dat een index weg kan tot de applicatiedocumentatie bevestigt hoe deze opnieuw wordt opgebouwd.

3. Scheid lezen, bewerken en beheren.

Voor het werkplaatsvoorbeeld lezen leden procedures, wijzigt een kleine redactiegroep ze, en beheren twee bevoegde beheerders de accounts. Hostbeheer is een aparte verantwoordelijkheid. Noteer wie een pagina mag publiceren, bestanden mag uploaden, inhoud mag exporteren en rechten mag wijzigen. Besluit hoe een vertrekkend lid de toegang verliest en wie de pagina's beoordeelt die diegene onderhield.

Rechtenregels van applicaties kunnen op verrassende manieren samenvallen. BookStack combineert bijvoorbeeld mogelijkheden over de rollen van een gebruiker en ondersteunt overschrijvingen op inhoudsniveau; rechtens voor een plank vallen niet automatisch door naar de bijbehorende boeken. Controleer het effectieve resultaat met gewone ledenaccounts, niet alleen met een beheerdersaccount. BookStack-rollen en -rechten.

4. Houd de herstelset bij elkaar.

Geef elke back-upset een datum, applicatieversie en notitie over welke database- en bestandskopieën bij elkaar horen. Bewaar de instructies ergens die toegankelijk blijft als de wiki uitvalt. Bewaar geheimen in geschikte secretopslag; het notitieboek moet aangeven wie ze kan ophalen en waar, zonder de waarden zelf te reproduceren.

Voor een concreet applicatievoorbeeld: de back-uprichtlijnen van BookStack behandelen databaserecords plus configuratie, geüploade afbeeldingen, bijlagen en eventuele thema's. De configuratie bevat een sleutel die relevant is voor versleutelde applicatiegegevens, dus alleen zichtbare pagina's kopiëren mist belangrijk herstelmateriaal. Volg de eigen procedure van de applicatie voor jouw versie. BookStack back-up en herstel.

Kies een onafhankelijke kopieerbestemming en een benoemd persoon om te controleren dat deze toegankelijk blijft.

5. Spreek een routine af die de groep kan volhouden.

Kies een controle-interval dat de beheerders echt kunnen volhouden. Kijk bij elke controle naar mislukte back-ups, openstaande applicatie-updates, groei van bijlagen en accounts die geen toegang meer nodig hebben. Houd dringende beveiligingsupdates buiten die routine wanneer ze eerder aandacht vragen. Noteer de volgende actie en de eigenaar ervan in plaats van een steeds groter wordende lijst van vage zorgen te verzamelen.

In het voorbeeld controleert de redactiegroep ook een korte lijst “te beoordelen”. Een apparatuurprocedure zonder eigenaar moet zichtbaar gemarkeerd worden voor beoordeling in plaats van stil gezaghebbend te lijken. Noteer vóór een belangrijke update de werkende versie, de migratie-instructies van de applicatie en het herstelpunt dat je wilt gebruiken als de validatie mislukt.

6. Bewijs het nuttige pad en noteer dan de hiaten.

Vraag op een aparte testkopie aan de tweede beheerder om een voorbeeldpagina te vinden, de bijlage te openen, een toegestane bewerking te maken en een actie te proberen die het account niet mag uitvoeren. Controleer een zoekresultaat na een inhoudswijziging. Noteer verwachte en waargenomen uitkomsten; alleen succesvol inloggen bewijst niet dat de wiki bruikbaar of correct beperkt is.

Als een bijlage ontbreekt, vergelijk dan de opslaglocatie en de back-upset voordat je databaserecords bewerkt. Als rechten verschillen, onderzoek dan accountrollen en inhoudelijke overschrijvingen voordat je toegang verruimt. Als de applicatie niet start, stop de oefening en noteer de versie- of configuratiemismatch. Dit zijn acceptatiestappen om uit te voeren, geen gerapporteerde tests van Hoszen-infrastructuur.

7. Laat een uitweg open.

Kies één representatief hoofdstuk om te exporteren en vraag of iemand het zonder de oorspronkelijke wiki zou kunnen lezen. Behandel die leesbare kopie als een apart deliverable van de herstelset: mogelijk blijven accounts, rechten of applicatie-instellingen niet behouden. Spreek af wie deze uitvoerkopie onderhoudt wanneer de inhoud verandert.

Je voltooide plan moet naast de service-inventarispassen, niet die vervangen. Ga verder met een draagbare exportmap en een hersteloefening. Het doel is een wiki die een andere bevoegde persoon kan begrijpen en herstellen; met deze gids wordt geen applicatie geïnstalleerd.