Toil とどう向き合うか
SRE をやっていく上で、「Toil」という概念は切っても切り離せないものであるわけだが、今更ながら「Toil」とはそもそも何なのかということを頭の整理も兼ねてまとめてみたい。
Toil とは何であるのか
定義については Google のエンジニアが書いている2冊の書籍『SRE サイトリライアビリティエンジニアリング（以下、 SRE book）』『サイトリライアビリティワークブック（以下、 SRE workbook）』が原典にあたる。これらによれば、 Toil は一言でこう、と言えるものではなく、以下のように複合的な性質を持つタスクのことを呼んでいる。
- 手作業であること
- 繰り返されること
- 自動化できること
- 戦術的であること
- 長期的な価値を持たないこと
- サービスの成長に対してO(n)であること
難しいのは、これらが AND 条件でもなければ OR 条件でもないということだ。 SRE book の5章から引く。
トイルと見なされるすべてのタスクが、必ずしもこれらの性格をすべて備えているわけではありませんが、以下の説明の1つ以上に当てはまるような仕事であれば、その仕事のトイルの度合いは高いと言えるでしょう。
つまるところ、これらは Toil であるか否かを判別する絶対的な条件というより、 Toil の持つ傾向、性格を表した言葉と考えたほうがいいだろう。 Toil と呼ばれるタスクが、結果的にこういった性格を備えている「場合がある」ということであり、その逆 = こういう性格を備えたタスクが Toil である、とは必ずしも成り立たない。
それを踏まえた上で、改めて Toil をどう定義するかだが、先の6つの性格より、同じく SRE book 5章における以下の記述がより本質を表している。
私たちがこの50%のゴールを共有するのは、トイルというものは、確認しないままにしておけば拡大し、急速に全員の時間の100%を埋め尽くしてしまう傾向があるためです。トイルを減らし、サービスをスケールさせる作業が、サイトリライアビリティエンジニアリングにおける「エンジニアリング」です。エンジニアリングの作業によって、SREの組織の規模はサービスのサイズに比例しなくなり、純粋な開発チームや運用チームに比べて、より効率的にサービスを管理できるようになるのです。
サービス（ここで言う「サービス」はプロダクトの意味というよりは、マイクロサービス的な文脈と捉えている）が拡大、もしくは数を増やしていくとき、比例的に増大して人的リソースを消費するものが Toil である。この側面から捉えたほうが Toil を考えやすいのではないだろうか。例えば、プログラムにより自動化されているタスクであっても、サービスが増えたときにプログラムの改修が常に必要なようでは、運用負荷の高い Toil に成り得る。ソフトウェア開発において、プログラマーはコードのエントロピー増大に向き合うことを求められるが、それと同じ事をソフトウェアやサービスを取り巻くあらゆるタスクに敷衍したのが Toil の考え方だと捉えている。
Toil とは何ではないのか
Toil とは何であるのかをさらに深掘りするべく、傍証として、逆に Toil は何では「ない」のかをいくつか挙げてみたい。
Toil とは運用作業全般のことではない
つまるところ Toil ＝ 運用作業（ここでは、ローンチ後のサービスを保守、維持するためのタスクを「運用作業」と呼ぶことにする）のことだと言いたくもなる。これについては若干判断が難しいところがあって、というのも SRE book と SRE workbook で若干言っていることが違うのだ。
GoogleのSREの組織では、運用作業（つまりはトイル）を、各人の作業時間の50％以下にするという目標が掲げられています。 （SRE book 5章 トイルの撲滅）
Google は、 SRE チームが運用作業（これにはトイル中心の作業もそうでない作業も含まれます）に費やす時間を50%に制限しています （SRE workbook 6章 トイルの撲滅）
SRE book では両者をほぼイコールのように書いているが、 workbook では、運用作業には「Toil 中心ではない作業」も含まれると書かれている。「中心ではない」というだけで、結局は Toil なのかもしれないが、 SRE book とは書きっぷりが明らかに違う。
僕としては運用作業 ≠ Toil だと捉えている。例えば年に1回程度発生するが、自動化にはそれなりに工数が必要そうな運用作業があったとして、これは Toil だろうか。「繰り返される」という条件には当てはまるが頻度が低いし、「自動化が可能」ではあるものの、工数的にベネフィットがそれほど得られるかはわからない。であるならば、これは運用作業ではあるが、 Toil には分類されない、と考えることもできるのではないか。
あるいは、こういった厳密な Toil / not Toil の仕分けを行うほうが手間でもあるし、 Toil は根こそぎ洗い出して消滅させなければならないものでもないので、あえて運用作業全体をざっくり Toil と扱ってしまうのも手かもしれない。その中でより Toil としての性格が強いものもあれば、そうではないものもあるわけだが、より性格の強いものや、作業時間を圧迫しているものから削減を図っていけば、運用上の支障はなさそうだ。
トイルとは「つまらない作業」のことではない
これは SRE book 5章に、明確に「No」であると書かれている。
トイルは、単なる「やりたくない仕事」ではありません。 つまらない仕事には、長期的な価値があることもあります。そうであれば、それもトイルではありません。
運用作業にはつまらないもの、大変なものも少なくない。しかし、長期的に価値があるのであれば、それは Toil = 削減対象ではなく、きちんと向き合うべきだというのが SRE book の主張だ。思いつくものとしては、ゼロデイや脆弱性への対応などだろうか。まぁ「つまらない」は主観でしかないので、個人差が大いにあるところだが。
とはいえ、つまらない作業は誰だってやりたくないし、なるべくなら減らしたいと考えるのが自然だろう。その関連で少し触れたいのだが、都内に NoOps Meetup という勉強会がある。
名前だけ聞くとかなり過激というか、思い切ったことのようにも聞こえるが、実際には「No Uncomfortable Ops」を掲げており、システム運用作業における「嬉しくない」ことを削減することを目的としている。これは単に「やっていて嬉しくない」というだけではなく、障害のようなユーザーにとっての「嬉しくない」こと、コスト的に「嬉しくない」ことも含まれる。
SRE book では、 Toil を削減するべき理由として、士気の低下を招くということも書かれている。長期的な価値のある作業であれば、徒労感も薄くて士気は下がりにくいと言いたいのだろうが、それは人によると言わざるを得ないし、「やりたくない」ことを減らそう、なるべく自動化しようというのはモチベーションとしてわかりやすい。つまらない作業 = Toil ではないのだが、つまらないことに忙殺されているか、敏感になる必要はありそうだ。
結局のところトイルとは何か
そもそも、自分がなぜ Toil の定義にこだわっていたのかと言えば、定義できないものは見つけようがないからだ。SRE として Toil の抑制を図りたいならば、 Toil を見つけなくてはならない。 Toil を見つけるには、 Toil とは何であるのかを定義しなくてはならない。しかし、ここまで見てきたとおり、 Toil とは XXX である、と一言で言い表せるようなものではない。似た性格を持つ単語はいくらか挙げられるが、厳密な定義を考えていくと、それらとイコールで結ぶことはできなくなる。
結論としては、 Toil が何であるか厳密な定義は必要ないと考えている。「 Toil を減らしたい」という言い方をすると、「ではまず Toil なるものを屏風から出してください」という気分になってしまうのだが、どちらかと言えば「 Toil 的なもの」を減らす、ぐらいの心構えでいいのではないか。目的は Toil を厳密に見つけていくことではなく、サービス拡大を妨げるような運用コストの増大を抑制することにある。この目的にさえフォーカスできていればいいのではないか。
SRE の原則に沿ったトイルの洗い出しとトラッキング | Google Cloud Blog においては、 Toil の洗い出しの一環として、チームメンバーへのアンケート調査を勧めている。
どのくらいの時間をトイルに費やしましたか。全体に占めるおおよその割合を、過去 4 週間の平均値でお答えください。
トイルに費やした時間の長さについてどの程度満足していますか。
文面に書かれているとおり、あくまで訊かれているのは「おおよその割合」である。ここで重視されているのは客観的に定義できる Toil の量ではなく、メンバーの主観に基づく負担量やストレス、認知的過負荷といった部分だ。SRE book 『5.4 トイルは常に悪なのか？』でも言及されている通り、簡単なタスクでささやかな達成感を生んでくれるような肯定的な側面も Toil にはある。重要なのは Toil が存在すること自体より、それが無秩序に増大することによる士気の低下のほうだ。
サービスの増加、トラフィックの増大によって増えてしまう運用コストを抑制し、無闇に人員を増やすことなく、安定的なサービスのスケールを行うことが SRE には求められている。SRE にとってもう1つの大きな役割であるSLOとエラーバジェットの管理も、同じ目的に沿うものと言えるわけで、つまるところ SRE とは、サービスの安定的なスケールを、ソフトウェアエンジニアリングによって支援していくことをミッションとした職種なのだと考えている。