前回は、自動化の価値について、学びました。
今回は、自動化のユースケースと自動化システムとプロダクトシステムの階層について学びます。

自動化のユースケース

自動化は、様々な問題を解決するためにコードを書く行為だと思われますが、そのコードの直接の目的を表すと、ソフトウェアに対して動作を行うソフトウェア、つまり「メタソフトウェア」が自動化のコードの役割になります。

自動化のユースケースには、様々なものがあります。

ユーザーアカウントの作成
サービス用のクラスタのターンアップおよびターンダウン
ソフトウェアあるいはハードウェアのインストールの準備や撤去
新しいバージョンのソフトウェアのロールアウト
ランタイムの設定変更
ランタイムの設定変更の特殊なケース：依存対象の設定変更

基本的にこのリストは、システムが成長する限り、続くことになります。
このリストを自分の中でストックしておくことは、重要かなと思います。

自動化のクラスの階層

実際のところは、自動化が必要なシステムよりも、自動化が必要な箇所をシステムに組み込んでしまっている方が良いです。
そもそもそのようなロジックが不必要に設計されていることが重要です。
実際は、自動化のシステムは、プロダクトシステムと別個に管理されていることが多いです。そのため、プロダクトシステムが更新されているのにも関わらず、自動化システムが更新されていない状況が生まれることがあります。この状況を生まないために、この両者のシステムをより密にしていこうとする試みが行われますが、これは失敗することが多いです。
この理由として、テストのたびにデプロイを行う必要があるので、プロダクト開発者からの抵抗があること（この抵抗が悪いということではないです。）が挙げられます。
また、実行頻度が低いためにテストが難しい自動化システムはフィードバックが難しいことが挙げられます。
自動化の進化については、次のような経過をたどります。

1. 自動化以前
　ロケーション間でのデータベースマスターのフェイルオーバーが手動で行われる状態。
2. 外部でメンテナンスされるシステム固有の自動化
　SREが自分のホームディレクトリにフェイルオーバーのスクリプトを持っている状態。
3. 外部でメンテナンスされる汎用の自動化
　誰もが使用する「汎用フェイルオーバー」スクリプトに、SREがデータベースのサポートを追加した状態。
4. 内部でメンテナンスシステム固有の自動化
　データベース自身にフェイルオーバーのスクリプトが同梱されてリリースされている状態。
5. システムが自動化を必要としない
　データベースが問題を検出し、人間の介入なしに自動的にフェイルオーバーを行う状態。¹

自動化はすべて5の状態であることが望ましいのではなく、システムの状況に応じて、必要な進化をするのが良いと思いました。

##まとめ

自動化のユースケースを溜めていってみる
自動化の進化

参考文献

Betsy Seyerほか　SRE サイトリライアビリティエンジニアリング　オライリー　74-77