そうして費用をいくらつぎこんでも, 信頼性だけは手に入らない. 信頼性は, 無縁まで単純さを追求することでしか手に入らないのだ. 〜 C.A.R Hoare, チューニング賞記念講演にて
第二部「原則」の最終章となる. 各節を通して「シンプルイズベスト」が言われていると感じた.
おそらく, この SRE 本を手に取った人たちのほとんどは, 自分の担当するシステムについてシンプルに保ちたいと思っているはず. ところが現実はそういう訳にはいかない. シンプルに保とうとすると, 開発者のアジリティの足枷となったり, ビジネスの成長に相反してしまうかもしれない. そんなジレンマに陥ってしまっている SRE エンジニアに達に送るメッセージ的な内容になっていると思う.
また, UNIX の哲学や YAGNI の精神, オブジェクト指向のクラス設計等に通ずるものがあり, これらをちゃんと勉強しなければと思った次第.
ソフトウェアシステムは動的で不安定であり, より複雑なシステムは障害になりやすい. システムに何もしなければ, システムは安定し, 状態を固定すればシステムのスケールは不要となる...とは言ってられないので, 「システム内でのアジリティ (素早さや柔軟性) と安定性のバランスを取る」 ことが SRE に求められている.
- 個人的には, システムにおいて安定性とアジリティは相反するものだと思う (書籍の中ではそこまで言及されていない)
- その中において, SRE はシステムの安定性とアジリティのバランスよく調整していかなければいけない
- ソフトウェアの信頼性向上を高めると同時に信頼性を高める行動が開発者のアジリティへの影響を最小限に留める (弊害にならないようにする)
- 信頼出来るプロセスは開発者のアジリティを高めることが出来る
- (memo) ここでの「プロセス」とは何を指しているのか
尚, 原著において, 本節の最後には以下のように書かれている. (Powerded by Google 翻訳)
信頼性の高いプロセスでは、開発者の敏捷性が実際に向上する傾向があります。その結果、バグが発生すると、そのバグを見つけて修正する時間が短くなります。信頼性を開発に組み込むことで、開発者は、ソフトウェアやシステムの機能と性能について、実際に気にかけていることに注意を集中することができます。
- ソフトウェアに関する限りでは, 退屈なことは良いことである
- プログラムには, あくまで定められた通りに動作し, 予想通りに作業の目標を完遂してもらわなければならない
- プロダクション環境における予想代の出来事は, SRE にとっては難敵である
- 想定外の複雑さを最小限にするために SRE チームが実施すべきこと
- 担当しているシステムに想定外の複雑さが生じていたら差し戻す
- システムから複雑さを取り除く努力を断続的に行う
この節を読んでいて, 「プログラマの三大美徳」を思ったのでメモ.
- 怠惰（Laziness）
- 短気（Impatience）
- 傲慢（Hubris）
- エンジニアは, しばしば自分の作成したものに共感を抱くもの (わかる〜)
- コメントアウトされたコードが多くなればなるほど困惑と混乱がそこに生じる！ (爆発を待つ時限爆弾のようなもの)
- 安定稼働を求められる Web サービスであれば, 新しいコードの一行, 一行がある程度の負債と言える
- SRE は, 全てのコードが本質な目的を持っているようにすることを推し進める必要がある
- ソフトウェアの肥大化 (機能が常に追加されているくことによって, 時間が経つにつれてソフトウェアが大きくなり, 低速になっていく傾向)
- プロジェクトに新しい機能を追加したいと思ったら, 「ちょっと待てよ, その機能は本当に必要か」と懐疑的になるべき
- YAGNI の精神 = 「必要になるまで作らない」
- (memo) ここでの API は REST API というよりも, より広義な意味の API を指していると思う
- フランスの詩人の言葉「最終的に完璧なものが生まれるのは, 追加するものがなくなった時ではなく, 取り除くべきものがなくなったときである」
- 最小限の API を書くことは, ソフトウェアシステムの単純さを管理する上で欠かせない
- 利用者に提供するメソッドや引数が少ない程, その API は理解し易くなり, その API のメソッドを改善しやすくなる
- ソフトウェアにおいては, 少ないということがは多くのことをもたらす
- オブジェクト指向プログラミングに適用される経験則の多くが分散システムの設計にも当てはまる
- システムの一部を独立して変更出来るようにしておく (疎結合) にするパターンは, 単純さをもたらすことによってアジリティと安定性を同時に高める
- 大規模なシステム中のコンポーネントにおいてバグが見つかったら, そのバグはシステムの中の他の部分とは独立して修正しプロダクション環境にデプロイすることが出来る
- API にバージョンを与えることで, 開発者は自分のシステムが依存しているバージョンを使い続けることが出来ると共に, 安全かつ配慮の行き届いた方法で新しいバージョンへアップグレード出来る
- システムの複雑なものに成長していくと, API やバイナリ間の責任範囲の分割が重要になる, これはオブジェクト指向のクラス設計に例えることが出来る (「単一責任の原則」のことを言ってるんだと思う)
miscやutilといった複数の責任範囲を持つような実装をプロダクション環境に置くのは良くないことである...ギクッ
- 単純なリリースは, 概して複雑なリリースよりも優れている
- 複数の変更をまとめて同時にリリースするよりも, 単一の変更をリリースする方が良い (というのは判る), そして, その変更の影響を理解することははるかに容易である
- リリースを小さなまとまりで行うことで, 大規模なシステムの中で分離してそれぞれのコードの変更分を理解出来るので, 自信を持って速度を高めることが出来る (memo) ここでの「速度」はアジリティに掛かっているのかな
- リリースに対するこの (単純さ) のアプローチは「勾配降下法」と比較することが出来る (超ざっくり言うと, ちっちゃくお試ししてその結果が吉と出るか, 凶と出るかを検討することによって最適な解を得る方法)
- ソフトウェア (に限らずシステム) を単純にすることは, 信頼性を持たせる為の前提条件である
- タスクの各ステップを単純化する方法を考える場合, 私達は怠けたりしない
- 本当に実現したいこととそれを最も簡単に行う方法を明確化する
- ゴミで散らかったりしなうような環境を保つことで, イノベーションにまっすぐに焦点を当て続けて, エンジニアリングに集中出来るようにしている
- 9.1 ここでの「プロセス」って何を指しているのか
- 9.5 ここでの API は REST API というよりも, より広義な意味の API を指していると思う
- 9.6 オブジェクト指向設計の「単一責任の原則」
- 9.7 自信を持って速度を高めることが出来る, ここでの速度はおそらくアジリティの速度なんだと思う
- 「単純さ」 = シンプルに保つこと, UNIX 哲学に通ずる
- エクストリームプログラミングの原則である YAGNI にも通ずる = 「必要になるまで作らないということ」