「運用に追われて、改善に手が回らない」という状態は、規模の大小を問わず多くのチームで見かけます。
厄介なのは、この忙しさが数字として残らないまま個人の頑張りに吸収されてしまうこと。
SRE はここに「トイル（toil）」という名前を付けて、感覚の話を測定できる対象に変えました。
筆者は SRE 未経験なので、Google の SRE 本と SRE Workbook という一次情報をたどりながら、この言葉の輪郭を整理しています。
判定の物差しを6つ持っておくと、目の前の作業がトイルかどうかを自分で見分けられるようになるはず。
トイルは「面倒な作業」の言い換えではない
まず定義から確認しましょう。
Google の SRE 本は、トイルを本番サービスの運用に紐づく作業で、手作業・繰り返し・自動化可能・受動的・恒久的な価値がなく、サービスの成長に比例して増えるものと説明しています。
言葉が多いので、6 つの性質に分けて並べ直してみましょう。
- 手作業（人が手を動かして実行している）
- 繰り返し（一度きりではなく定期的に発生する）
- 自動化できる（機械でも同じ結果を出せる、または設計で消せる）
- 受動的（割り込みで発生し、こちらから仕掛けたものではない）
- 恒久的な価値がない（終わってもサービスの状態は元のまま）
- 成長に比例して増える（利用者やトラフィックが 2 倍なら作業も 2 倍）
大事なのは、6 つすべてを満たす必要はないという点。
当てはまる数が多いほどトイル寄り、という濃淡のある指標として使います。
一方で、経費精算や採用面接、社内の手続きといった仕事は、面倒でもトイルには含めません。
SRE 本はそれらを「オーバーヘッド」と呼んで区別しています。
「嫌な作業＝トイル」と広げてしまうと、次の測定が成立しなくなるので、この線引きは思ったより重要でした。
50% という上限は、平均ではなく個人で見る
トイルを定義したあと、SRE 本はそこに数値目標を置きます。
具体的には、運用作業を各 SRE の時間の 50% 未満に保つという目標が掲げられているのです。
残りの半分は、将来のトイルを減らすエンジニアリングか、機能開発に充てる時間。
実測値も公開されていて、四半期ごとのアンケートでは Google の SRE が平均でおよそ 33% をトイルに使っていると報告されています。
目標より低いので一見うまくいっているように読めますが、同じ調査には 0% と回答する人もいれば 80% と回答する人もいる、というばらつきが併記されていました。
つまり平均が目標を下回っていても、偏りがあれば誰かが潰れるわけです。
チーム平均だけを見て安心しないこと、というのがこの数字から受け取れる実務的な示唆でしょう。
このあたりの前提は、SRE という役割そのものの成り立ちとつながっています。
減らし方は「自動化」から始めない
トイルを見つけたとき、人はすぐスクリプトを書きたくなるもの。
ただ、順番としては消す → 依頼者が自分でできるようにする → 自動化するの順に検討するほうが効きます。
そもそもその作業が必要なのかを問い直せば、自動化する対象がひとつ減るからです。
セルフサービス化も同じ発想で、依頼を受ける側の割り込みそのものが消えます。
優先順位を付けるときは、6 つの性質のうち「成長に比例して増えるか」を先に見るとよさそうでした。
比例して増える作業は、今は 30 分でも利用者が増えた時点で必ず破綻するので、放置するほど高くつきます。
逆に、頻度が低くて増えもしない作業は、手作業のまま残しても大きな害になりません。
もうひとつ意識しておきたいのが、自動化そのものが新しい運用対象を生むという点。
書いたスクリプトは壊れますし、壊れたときに直せる人が限られていれば、それはそれで新しいトイルになります。
自動化を「作業をゼロにする手段」ではなく「作業を移す手段」として見ておくと、この落とし穴を避けやすくなるでしょう。
そして、どこまで減らせば十分なのかを決めるには、信頼性の目標そのものを言葉にしておく必要があります。
最後に
トイルという言葉の価値は、定義そのものよりも「測って減らす対象だ」と宣言したことにあると感じました。
6 つの性質で判定し、時間の何割かを測り、比例して増えるものから順に消す。
この 3 ステップなら、SRE を名乗るチームでなくても今日から真似できます。
筆者も学んでいる途中なので、次は監視の設計あたりを同じように一次情報から整理していく予定です。
参考: Google SRE Book – Eliminating Toil / Google SRE Workbook – Eliminating Toil
以上です。
コメントを残す