# 14. 設定の設計とベストプラクティス

## 設定の哲学

理想は全く設定がないことであるが、多くのシステムでは実現できないものである。

システムの調整可能な設定の多さは、エラーの発生領域やオペレータの認知負荷に比例する。

Googlerの経験では、　システム対してのコントロールの量を減らすことで、幅広く採用され、内部的なユーザサポートコストの低下を生む結果となった。

### ユーザに質問する設定

ソフトウェアの設定に関しては主に２つの異なる観点がある

- インフラストラクチャ中心の見方
できる限り多くの設定項目の提供を行い、システムは完全にチューニングできるので良いとされる。

- ユーザ中心の見方
設定に答えるのは面倒なので、項目は少ないほど良い。

一般的に、設定の選択肢が限定されているほど、極端に用途の広いソフトウェアより採用されやすくなる。箱から出してそのまま動作するソフトウェアの方がオンボーディングの労力が相当低くなる。

## 質問はユーザの目標に近いものであるべき

ユーザに細かい設定を行わせると、システムは完全にそれに従わなければならなくなる。

代わりに、ユーザが高レベルの目標を述べるなら、システムは時間と共に進化して、それらのゴールの実現方法を改善していくことができる。

このため、システムにとって最初に必要なステップはユーザの目標を事前に理解することである。

### 必須の質問とオプションの質問

必須の質問は極力減らすべきである

必須の質問を減らす最も簡単な方法はオプションの質問にしてしまい、デフォルト値を設定することである

また、デフォルト値はハードコードでなくてもよく、オーバーライドできるとなお良い。

Googlerの経験ではほとんどのユーザがデフォルトの設定を使うことがわかっている。

ユーザを正しい方向に導くことができるが、誤ったデフォルト値の定義は多くの害を生む結果となる

e.g.
臓器のドナーがデフォルトでオプトインになっている国は、オプトアウトになっている国に比べドナー比率が劇的に大きくなっている => [Link](http://bit.ly/2kEGp9c)

## 設定の仕組み

設定変更のUXに関するベストプラクティス

### 設定と結果データの分離

設定がコードなのかデータなのかという古くからある疑問への答えとして、Googler の経験はコードとデータの両方であはあるものの、この両者を分離するのが最適であると示している。

まず、システムのインフラストラクチャはプレーンな静的データ上で運用されるべき。
- Protocol Buffers
- YAML
- JSON

しかし、ユーザはこれらを生成する高レベルのインタフェースを扱える
- Python
- Lua
- Jsonnet => JSONのテンプレートエンジン
- はたまた、WebUI


### ツールの重要性

ユーザによる設定の適用に際して、より安全に適用できるようなツールのベストプラクティス

#### セマンティクスの検証

[セマンティクスとは](https://developer.mozilla.org/ja/docs/Glossary/Semantics) => 設定内容が持つ意味

- ユーザが存在しないディレクトリを指定していたり
- 実際に持っているよりも1000倍の量のRAMを要求していたり

セマンティクス的に意味があるかを検証し、設定ミスをsubmitされた後ではなくcommitする前に回避する

#### 設定の構文

ユーザが設定を記述する際、障害物を取り除くのも重要である。
構文の観点から見た、提供ツールのベストプラクティス

- 構文のハイライト
- Linter
- 自動構文フォーマッター

#### 所有権と変更追跡

設定の変更をGitなどを利用しバージョン管理するベストプラクティス。

- ポストモーテムでの変更タイミングの遡り
- 誰が、何を変更したか
- ユーザだけでなく、WebUI やリモート API から取り込まれた設定についても管理すべき

#### 安全な設定変更の適用

設定変更の適用方法に関するベストプラクティス

- All or nothing ではなく徐々にデプロイできること
- 危険だとわかった際に変更をロールバックできること
- その変更により運用者の制御が失われることにつながる場合、自動的にロールバックされること(あるいは最低限進行を止められること)
- モニタの解像度を変更した際に出てくる10秒カウントダウンなど