SRE 実践 #6 トイル削減 — 繰り返し手作業の測定と自動化、そして導入ロードマップ

シリーズ最後のテーマは派手ではありませんが、チームの未来を決める問題です。運用の手作業がエンジニアリングの時間を侵食するのをどう防ぐか。 SRE の用語でトイル(toil)と呼ばれるこの作業群を放置すると、サービスが成長するほどチームは運用に沈み、自動化する時間がないから手作業を続ける、という悪循環に閉じ込められます。

トイルの判別 — つらい仕事ではなく、特定の種類の仕事です #

トイルは「つらくてやりたくない仕事」の感傷的な表現ではなく、判別基準のある用語です。次の性質を多く持つほどトイルです。

• 手作業: 人が手で実行します。スクリプトを人が回すのも含まれます。
• 反復的: 初めてではなく、何回目か数えることもできない作業です。
• 自動化可能: 人の判断が本質的には不要で、機械が同じ結果を出せます。
• 戦術的: 長期的な価値を生みません。終えてもシステムは昨日と同じ状態です。
• 成長に比例: ユーザー・トラフィック・サーバーが増えると作業量も増えます。

ディスクの掃除、手動デプロイの承認クリック、アカウント作成依頼の処理、毎週同じクエリを回してレポートを作る作業。すべて典型的なトイルです。一方、障害対応中の判断、アーキテクチャ設計、自動化の開発そのものは、つらくてもトイルではありません。この区別が重要なのは、トイルだけが自動化で消せる対象だからです。

50% ルール — 上限がなければ必ずあふれます #

Google の SRE が広めた運用原則があります。運用業務(トイル + オンコール + チケット)がチームの時間の 50% を超えないようにする。 残りの半分は、トイルを減らすエンジニアリング(自動化、信頼性の改善)に使います。

50 という数字そのものより重要なのは、上限が存在することです。上限がなければ運用業務は必ず膨張します。サービスは成長し続け、トイルは成長に比例するからです。上限を守る方法は測定です。

• 四半期に一度、メンバーごとに直近 2 週間の時間の使い方をざっくり分類してみます。 精密である必要はありません。「運用 70%」という大まかな数字だけでも対話が始まります。
• 50% を超える状態が続くなら、それは個人の時間管理の問題ではなく、チームの投資配分の決定事項です。自動化スプリントを編成する、トイルの発生源であるサービスを開発チームに返す(運用移管の返上)、人員を調整する、といった決定が必要です。

自動化の優先順位 — 頻度 × 時間 + リスク #

トイルの一覧を作ったら、どこから自動化するかを決めます。基本の式は年間の節約時間 = 頻度 × 1 回あたりの所要時間で、ここに 2 つの重み付けを加えます。

1. ミスのリスク: 人がやって間違えたら障害になる作業(本番 DB の手動操作など)は、節約時間が小さくても優先順位を上げます。自動化の価値が時間の節約ではなく事故の防止だからです。
2. 自動化のコスト: 年間 10 時間の節約のために 3 週間かけるのは損です。ただしコスト計算には、「その作業のせいで途切れる集中」や「その作業を知っている人が休暇だと止まる業務」といった隠れたコストも入れるべきです。

注意すべき罠をひとつ。壊れたプロセスの自動化は、壊れた結果を速く作るだけです。 承認フローがおかしいせいで生まれるチケットを自動処理するより、承認フロー自体をなくすほうが先というケースは多いです。自動化の前に「この作業はそもそもなぜ存在するのか」を一度問うべきです。

自動化のはしご — ランブック → スクリプト → セルフサービス #

自動化はゼロかイチかではなく、段階的に上がっていきます。

1. 文書化(ランブック): 頭の中の手順をドキュメントにします。自動化の前段階であり、手順のおかしな部分が最初に露呈する段階です。
2. 半自動化(スクリプト): ランブックのコマンドをスクリプトにまとめ、実行の判断は人がします。ほとんどのトイルはこの段階だけで所要時間が大きく減ります。
3. 完全自動化: トリガーから実行まで人が抜けます。ディスク掃除、証明書の更新、失敗したジョブの再試行のように判断の要らない作業が対象です。安全装置(変更量の上限、異常時の停止)とセットで進めます。
4. セルフサービス: 依頼者が自分で処理できるようにします。「アカウントを作ってください」というチケットを受ける代わりに、依頼者がフォームと自動承認ルールで自己完結できるプラットフォームを提供します。トイルがチームから消える終着点です。

繰り返し処理のスクリプトを書くのが初めてなら、Python 自動化シリーズが第 2 段階の道具箱になります。

シリーズを終えて — 導入の現実的な順序 #

6 回を貫く構造はひとつです。測定が合意を作り、合意が行動を正当化します。 SLO がなければエラーバジェットがなく、バジェットがなければ「今こそ信頼性に投資すべきだ」という主張は、声の大きい人の意見にとどまります。組織への導入の現実的な順序はこうです。

1. サービスひとつ、ジャーニー 2〜3 個で SLO を作ります(第 1 回)。全社導入を宣言しません。
2. バジェットポリシーを経営層と合意します(第 2 回)。ここが最も難しく、最も重要です。
3. アラートを SLI ベースに変えます(第 3 回)。深夜の呼び出しが減るのをチームが体感する段階で、制度への信頼がここで生まれます。
4. オンコールとポストモーテムを整えます(第 4 回、第 5 回)。対応と学習のループが閉じます。
5. トイルを測定し、自動化の時間を確保します(今回)。ループが回り続ける状態を保つ力です。

ひとつのサービスでこのループが回り始めれば、他のチームは結果を見てついてきます。制度は宣言ではなく事例で広がります。

まとめ #

• トイルは手作業・反復的・自動化可能・戦術的・成長比例という判別基準を持つ用語です。つらい仕事のすべてがトイルではありません。
• 運用業務に 50% の上限を設け、四半期ごとに大まかにでも測定します。超過が続くならチームレベルの投資決定に昇格させます。
• 自動化の優先順位は頻度 × 時間にミスのリスクを重み付けして決め、壊れたプロセスは自動化の前にプロセスから直します。
• 自動化はランブック → スクリプト → 完全自動化 → セルフサービスのはしごを登ります。
• 導入の順序は SLO → バジェットポリシー → アラート → オンコール・ポストモーテム → トイル管理です。ひとつのサービスの成功事例が最良の伝播手段です。