はじめに
システム運用において、どこまで手順書を作成するべきかという課題には、皆さん頭を悩ませているのではないでしょうか。もちろん、すべての作業について手順書があれば、品質が担保できます。しかし、実際の現場では、作成、メンテナンスの手間を考えるとすべての作業に対して手順書を作成することは、現実的ではないしょう。先日、システム運用の品質担当者の方が、その課題について２つの基準をお話してくれたので、その内容を共有したいと思います。
また、そこでSRE的には、どのような基準で手順書の作成や自動化を行っているのか、という質問を受けました。その問いに対する、個人的な意見も合わせて共有します。
手順を作成するべき作業の基準
基準１：お客様と約束を交わしているかどうか
基準１はわかりやすいのですが、お客様と手順書の作成について、約束を交わしている場合です。この場合、どんな単純な作業でも手順書を作成する必要があります。作成された手順書の内容を、お客様にレビューしていただき、合意をとって、その手順どおりに運用することが求められるでしょう。
基準２：リスクを受容できるか
基準２ですが、手順書がない作業を行って、起きたリスクを受容できなければ、その作業は手順書を作成するべきでしょう。逆に、リスクが起きたとしても、簡単にリカバリをできるものであれば、あえて手順書を作成する必要はないと言えます。これは、情報セキュリティマネジメントの、「リスク保有」と同じような考え方で、リスクの持つ影響力が小さい場合や、コストに見合ったリスク対応の効果が得られない場合が当てはまります。
参考：情報セキュリティマネジメントとPDCAサイクル
https://www.ipa.go.jp/security/manager/protect/pdca/risk.html
SRE的、手順を作成するべき作業の基準（個人の意見も含む）
そもそも、SREは単純に作業フローの見える化や見直し、自動化する活動ではないと考えています。しかし、どのような運用作業を自動化するべきかには、ある程度基準があります。SREでは、その自動化するべき作業のことをトイルと呼んでいます。
トイルの定義
以下の特徴に、１つ以上当てはまれば、その作業はトイルである可能性が高いです。
手作業であること
自動化スクリプトを、手作業で実行するような作業のことです。
繰り返されること
繰り返し何度も行われている作業のことです。作業が１回や２回しか行われないものであれば、それはトイルではないでしょう。
自動化できること
マシンが人間同様に行えるタスクのことです。そのタスクに人間の判断が欠かせないのであれば、それはトイルではないでしょう。しかし、そもそも人間の判断が必要な、運用の設計に問題がある可能性もあります。
戦術的でないこと
割り込みで始まり、問題などが生じたことへの対応として行われる作業のことです。
長期的な価値を持たないこと
あるタスクを終えても、サービスが同じ状態であれば、そのタスクはトイルである可能性が高いです。
サービスに対してO(n)であること
サービスのサイズ、トラフィック量、ユーザー数などに比例してスケールするようなタスクのことです。
なぜ、トイルを自動化するべきか
トイルは、自動化せずにいると、どんどん拡大し、運用作業者の時間の100%を埋め尽くしてしまう傾向があるためです。トイルを減らすことで、サービスのサイズが大きくなっても、運用チームの規模は比例しなくなり、純粋な開発チームや運用チームに比べて、より効率的にサービスを管理できるようになります。
おわりに
理論的には、基準があっても、いざ現場でフローの見える化や見直し、自動化を行うことは簡単ではないです。まずは、小さいことからでも、現場の人が改善しようという意思を持って行動に踏み出すことが大切だと思います。