始める前に
- wiki を閲覧、編集、管理する人の一覧。
- 選択した wiki とその対象バージョンのドキュメント。
- 運用ノート用の場所と、復旧用認証情報のための分離された管理された場所。
1. wiki が果たす役割を説明しましょう。
まず 1 文から始めましょう。「メンバーはこの wiki を使って、共有ワークショップを運営するための最新の手順を確認する。」この仮の目的は「すべてをオンラインに置く」よりも狭いものです。これは管理可能な最初のコレクションを示唆します。開場手順、設備ノート、会議での決定です。個人の連絡先とアクセス認証情報にはそれぞれ別の判断が必要です。便利な検索ボックスは、それらを収集する理由にはなりません。
読者が何を達成する必要があるかを列挙しましょう。たとえば、最新の手順を見つける、参照されている図を開く、古くなったページの所有者を知る、などです。後でアプリケーションを評価するために、実際のコンテンツから小さなサンプルを選びましょう。メンバー数だけからメモリ要件を推測してはいけません。アップロード、インデックス作成、拡張機能、同時作業が負荷を変える可能性があります。
2. 依存関係用に 1 ページ作成しましょう。
この例を出発点のマップとして使い、すべての仮定を選択したアプリケーションのレイアウトに置き換えましょう。「所有者」とは、そのコンポーネントを説明し復旧できる人を意味し、必ずしもインストールした人ではありません。
| 部分 | ノートブックに入れるもの | 復旧時の確認事項 |
|---|---|---|
| Web アプリケーション | バージョン、設定の場所、サービスの所有者 | 別のメンテナーが同じバージョンを再構築できるか? |
| データベース | エンジン、バージョン、バックアップ方法 | どのスナップショットがファイルと対応するか? |
| 画像と添付ファイル | ストレージパスと増加見込み | 復元したページで図が開くか? |
| DNSとHTTPS | ドメインアカウントの所有者と証明書の方法 | wiki なしでアクセスを修復できるのは誰か? |
| メールとスケジュールされた作業 | 送信者、スケジュール、障害時の担当者 | 配信が失敗したとき何がまだ動作するか? |
検索も記録しましょう。それはアプリケーションの一部か、再構築可能なインデックスか、別のサービスか? アプリケーションのドキュメントが再構築方法を確認するまで、インデックスを破棄できると仮定してはいけません。
3. 閲覧、編集、管理を分けましょう。
ワークショップの例では、メンバーは手順を読み、小規模な編集グループがそれらを変更し、2 人の承認されたメンテナーがアカウントを管理します。ホスト管理は別の責任です。誰がページを公開し、ファイルをアップロードし、コンテンツをエクスポートし、権限を変更できるかを書き留めましょう。離脱するメンバーがどのようにアクセスを失うか、またその人が維持していたページを誰がレビューするかを決めましょう。
アプリケーションの権限ルールは意外な形で組み合わさることがあります。たとえば BookStack は、ユーザーのロール全体で権限を組み合わせ、コンテンツレベルの上書きをサポートします。シェルフの権限はその書籍に自動的にカスケードしません。管理者アカウントだけでなく、通常のメンバーアカウントを使って有効な結果を確認しましょう。 BookStack のロールと権限.
4. 復旧セットをまとめて保管しましょう。
各バックアップセットに日付、アプリケーションバージョン、どのデータベースとファイルコピーが一緒に属するかのメモを付けましょう。wiki が失敗してもアクセスできる場所に手順を保管しましょう。秘密情報は適切なシークレットストレージに保管し、ノートブックには誰がどこでそれらを取得できるかを特定し、値を再現しないようにしましょう。
具体的なアプリケーション例として、BookStack のバックアップガイダンスはデータベースレコードに加えて設定、アップロードされた画像、添付ファイル、テーマを対象としています。その設定には暗号化されたアプリケーションデータに関連するキーが含まれるため、表示されるページだけをコピーすると重要な復旧資料を逃します。使用中のバージョンに応じてアプリケーション自身の手順に従いましょう。 BookStack のバックアップと復元.
独立したコピー先と、それがアクセス可能であり続けるか確認する担当者を決めましょう。
5. グループが続けられるルーティンを決めましょう。
メンテナーが実際に守れるレビュー間隔を選びましょう。各レビューでは、失敗したバックアップ、保留中のアプリケーション更新、添付ファイルの増加、アクセスが不要になったアカウントを確認します。緊急のセキュリティ更新は、より早い対応が必要な場合、そのルーティン外に置きましょう。漠然とした懸念のリストを増やし続けるのではなく、次のアクションとその担当者を書きましょう。
例では、編集グループは短い「要レビュー」リストも確認します。所有者のいない設備手順は、静かに権威があるように見えるのではなく、レビュー対象として目立つようにマークされるべきです。重要な更新の前に、動作するバージョン、アプリケーションの移行手順、検証が失敗した場合に使う予定の復旧ポイントを記録しましょう。
6. 役立つ経路を確認し、ギャップを記録しましょう。
別のテストコピーで、2 人目のメンテナーにサンプルページを見つけ、その添付ファイルを開き、許可された編集を行い、そのアカウントでは許可されるべきでない操作を試してもらいましょう。コンテンツ変更後に検索結果を確認しましょう。期待した結果と観察した結果を記録します。ログインが成功しただけでは、wiki が使用可能または正しく制限されていることを証明しません。
添付ファイルが見つからない場合は、データベースレコードを編集する前に、そのストレージ場所とバックアップセットを比較しましょう。権限が異なる場合は、アクセスを広げる前にアカウントのロールとコンテンツの上書きを調べましょう。アプリケーションが起動できない場合は、演習を中止し、バージョンまたは設定の不一致を記録しましょう。これらは実行する受け入れ手順であり、Hoszen インフラストラクチャの報告されたテストではありません。
7. 出口となる経路を残しましょう。
エクスポートする代表的な章を 1 つ選び、元の wiki なしで誰かがそれを読めるか尋ねましょう。その読めるコピーは復旧セットとは別の成果物として扱いましょう。アカウント、権限、アプリケーション設定は保持されない可能性があります。コンテンツが変わったとき、この退出用コピーを誰が維持するかを決めましょう。
完成した計画は横に収まるべきです サービスインベントリを置き換えるのではなく。次に進みましょう ポータブルエクスポートフォルダ と 復元演習。目標は、別の承認された人が理解して復旧できる wiki です。このガイドではアプリケーションはインストールされません。
この注記の背後にあるドキュメント
実際に実行しているバージョンのドキュメントを使用してください。これらの例は計画資料であり、Hoszen VPS でのテストの記録ではありません。