なぜ設定が必要か?

• 用途、ポリシーに対するカスタマイズ
• 環境に対するチューニング
• 自動化のための情報保持

どうやって設定をするか?

• ハードコーディング(プログラム内に埋め込み)
  • C言語のヘッダファイルなどで、プログラムの中に設定を書く。
• スクリプト言語そのものでの定数定義。
  • スクリプト言語の文法そのものが使えるため、よく使われる。
• 環境変数を使う。(環境変数の定義はシェルスクリプトなどで行われる。)
• 設定ファイルを読み出す。(JSON,YAML,TOML,XMLなど)
• 設定用データベースを使う。(RDB, レジストリなど)
• 暗号化ファイルを使う。(Ansible Vault など)

何が問題か? (順不定)

• 設定地獄に陥る。(以下に書かれる問題の総称)
• そもそも設定できないことがある。(ハードコーディング)
• どこにどんな設定があるのか分からない。
• 設定があちこちに散在する。
• 設定が多すぎる。
• 理解に時間がかかる。
• 設定のカテゴリがうまくまとまっていない。
• 設定の意味が分からない。(適切な説明がない。)
• 設定の適切な値・内容が分からない。
• 設定とその反映が時間的に離れている。
• 操作ミスなどで意図しない設定に変わってしまう。
• 設定をミスすると設定すらできない状態に陥る。
  • 画面設定で画面が表示されなくなるなど
• 設定をバックアップできない。手動で再設定が必要になる。
• どこをどう設定したのか分からなくなる。初期状態に戻せなくなる。
• 設定を手動でしか変更できない。(自動化が困難)
• 設定の変更が競合する。
• 設定内に秘密の情報がそのまま書き込まれる。(パスワードなど)
• 設定ファイル自体が脆弱性を持つ。(プログラミング可能だとそこから侵入される可能性が出てくる)

対策

• そもそも設定ではなく規約にする。
• 自動チューニングを用意する。
• 半自動チューニングを用意する。適切な設定を提案する。
• 設定を外出しする。(設定を埋め込まない。)
• 設定のファイルフォーマットを標準的なものにする。(独自フォーマットを使わない。)
• 設定ファイルに無闇に機能を付けない。(単純な値の入出力に限定する。)
• 設定に分かりやすい名前と詳細な説明を付ける。
• 設定の説明が複雑なものは簡単になるように設定の仕組みを見直す。
• 設定の説明が複雑なものは外部サイトなどのリンクを付ける。
• カテゴリを整理する。
• タグ、キーワードで検索できるようにする。
• 状況別の基本設定(デフォルト設定)を用意する。
• UIでは、確認するまでは本当に設定するのを待つ。
• 設定が本当に正しいかどうかの確認手段を用意する。
  • 設定ファイルの整合性チェック
  • 読み込まれている設定の表示
  • 設定後一定時間内に確認ボタンが押されなければキャンセルなど
• 初期状態に戻す方法を用意する。
• バックアップ・リストアする方法を用意する。