この Wiki.js は、自宅で構築したオンプレミス環境上で運用している。
レンタルサーバーでも、クラウドでもない。
Red Hat Enterprise Linux を基盤とし、Apache HTTP Server を含むミドルウェア層からドキュメント基盤まで、一貫して自前で設計・構築している。
本Wikiは、インフラ技術の検証・構築・運用に関する知見を、単なる作業記録ではなく「構造化された技術資産」として整理するための基盤である。
単に設定値やコマンドを列挙することはしない。まず前提条件を確認し、次に設計意図を整理し、そのうえで変更内容と検証結果を記録する。
つまり「何をしたか」だけでなく、「なぜそうしたのか」までを一貫して残す。
インフラは表面上、問題なく動作しているように見える。しかし、その背後には依存関係や設計上の前提が存在する。これらを言語化しなければ、時間の経過とともに理解は失われていく。
そのため本Wikiは、「構築した」という事実を残す場ではなく、理解し、説明でき、再現できる状態を維持するための基盤として位置付ける。
まず、インフラは動作しているだけでは十分とはいえない。
なぜその構成を採用したのか、なぜそのOSを選定したのか、なぜその設定値を採用したのか。さらに、障害発生時にどのように分析し、どの観点で判断したのか。
これらを明文化しなければ、同じ議論を繰り返すことになる。したがって、本Wikiの目的は次の一点に集約される。
技術判断を再現可能な形で固定すること。
再現できなければ、それは経験の断片に過ぎない。一方で、再現できる状態に整理されていれば、それは継続的に活用できる技術資産となる。
本Wikiでは、情報をレイヤーごとに整理する。
まず設計で前提と依存関係を明確にし、その後に構築手順を記録する。さらに運用観点を分離し、最後に障害対応を体系化する。この順序を守ることで、情報が混在せず、構造が維持される。
設計は「なぜ」を扱い、手順は「どのように」を扱う。両者を混同しないことが、長期的な可読性と再利用性を保つ鍵となる。
文章だけでは、インフラの全体像は伝わりにくい。そこで、本Wikiでは構成図や通信フロー図を積極的に活用する。
ただし、図は装飾ではない。論理構成と物理構成を分け、通信方向や依存関係を明示し、信頼境界や暗号化経路を可視化する。その結果として、図を見るだけで構造を把握できる状態を目指す。
文章は図を補足するために存在し、図は設計を説明するために存在する。この関係を崩さない。
本Wikiでは、セキュリティを後付けの設定項目として扱わない。
すべての設計は、次の三要素を前提として成立する。
通信経路は常に信頼できるとは限らない。
内部ネットワークであっても安全とは限らない。
したがって、「内部だから許可する」という前提は置かない。
アクセス権は必要最小限を基準とする。
管理者権限の付与は例外であり、必ず理由を明記する。
特権アカウントは用途を限定し、日常操作と分離する。
暗号化は設定ではなく設計要素である。
ログは保存するだけでは意味がない。
監査ログは、異常検知と説明責任のために存在する。
「何も起きていない」ことを確認できる状態を維持する。
インフラ設計では、次を明確にする。
境界が曖昧な構成は、必ず脆弱になる。
すべての変更は、次の観点を追加確認する。
構造変更は、常にセキュリティ影響を伴う。
技術文書において曖昧さは排除する。したがって、製品名は可能な限り正式名称で記載する。
例として、次のように表記する。
略称を使用する場合は、初出時に正式名称を明記する。また、バージョンは可能な限り記載し、表記ゆれを防ぐ。
このように統一することで、文書全体の精度を保つ。
本Wikiは特定製品の操作解説に限定しない。むしろ、OS・ネットワーク・セキュリティ・監視を横断し、構造として整理する。
Windows領域では、認証基盤や構成管理を中心に扱う。さらに、GUI操作とコマンド操作が混在する特性を踏まえ、必ず「確認 → 設定 → 確認」の流れを徹底する。
設定前の状態確認、設定内容の明文化、適用後の証跡（gpresultやイベントログ）、影響範囲の明示を欠かさない。スクリーンショットは補助資料であり、文章による再現性を必ず担保する。
Linux領域では、Web・DB・Git・ミドルウェアを含む基盤技術を扱う。操作は原則としてCUIで実施されるため、粒度を小さく保つことを重視する。
基本は「確認 → 変更 → 再確認」である。
変更前に設定ファイルやサービス状態を確認し、バックアップを取得したうえで変更を行い、再起動・ログ確認・疎通確認までを一連の流れとして記録する。
可能な限り一操作一コマンドとし、実行コマンドと出力結果を対で保存する。差分が説明できない変更は行わない。
IP設計、VLAN、ルーティング、Firewallポリシー、DNS設計を対象とする。
構成変更時には、変更前後の状態を保存し、影響範囲とロールバック手順を明確にする。通信経路は図で可視化し、暗号化区間と信頼境界を明示する。
認証・認可・監査を中心に扱う。
最小権限を基準とし、例外が生じる場合には理由を明示する。セキュリティは後付けの設定ではなく、設計段階から組み込むべき要素である。
証明書管理、ログ監査、アクセス制御は単独で扱わず、構造の中で位置付ける。
監視は通知のためだけに行うのではない。
構造を理解し、異常の兆候を捉えるために設計する。ログは保存するだけでは意味がなく、分析できて初めて価値を持つ。
監視設計は、通常時の状態を理解することから始まる。
すべての変更は、次の流れで扱う。
確認 → 変更 → 検証 → 記録
まず現状を把握し、次に変更を実施し、その後に検証を行う。そして結果を記録する。変更前後の差分を説明できる状態を維持することが重要である。
章単位で内容を完結させ、履歴はGitで管理する。
これは成果物の展示ではない。また、単なる作業メモでもない。
判断過程を固定し、時間が経過しても説明可能な状態を維持するための基盤である。
技術は量ではなく、再現性と構造化によって価値を持つ。
したがって、本Wikiは「記録」ではなく「資産化」のために存在する。