SRE の原則に沿ったトイルの洗い出しとトラッキング
Google Cloud Japan Team
※この投稿は米国時間 2020 年 2 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。
作業効率を検証するために Google のサイト信頼性エンジニア（SRE）が使用している主な測定指標の一つが、日々の時間の使い方です。長期間のエンジニアリング プロジェクトのために時間を確保する必要がありますが、エンジニアには Google のサービスを稼働し続ける責任もあり、そこにも手作業が生じることがあります。Google の SRE は、いわゆる「トイル」に費やされる時間を勤務時間の 50% 未満にすることを目指しています。では、トイルとは何でしょうか。トイルに邪魔されずに開発スピードを維持するには何をすべきでしょうか。本稿ではこれらの問いについて見ていきます。
まずトイルの定義ですが、『Site Reliability Engineering』の第 5 章には次のように書かれています。
「トイルとは、手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、サービスの成長に比例して増加する、といった特徴を持つ作業です。」
トイルの例としては次のようなものがあります。
割り当てリクエストの処理
データベース スキーマ変更の適用
重要性の低いモニタリング アラートの確認
プレイブックからのコマンドのコピーと貼り付け
ここに挙げたすべての例に共通する特徴は、エンジニアが頭で判断する必要がないということです。こうした作業は簡単ですが、やりがいはあまりなく、サービスの拡大や機能のリリースのためのエンジニアリング作業の進捗を妨げます。
ここからは、トイルを洗い出して測定し、撲滅する方法を、順を追って説明します。
トイルを洗い出す
トイルへの取り組みで最も大変なのが洗い出しです。積極的に把握していないとすれば、自覚していない大量の作業がチーム内で発生しているはずです。トイルはリクエストの形で発生することが多く、個人宛てのメールなどでリクエストを受け取った人は、誰にも気付かれずに律儀に作業を終わらせます。これに該当するうってつけの例を、オーストラリアのシドニーで CRE として勤務する Jamie Wilkinson から聞きました。それは、彼が Google のデータストア サービスの一つを管理するチームで SRE として働いていたときの話です。
Jamie が勤務していた SRE チームはシドニーとカリフォルニア州マウンテンビューに分かれていて、2 つのサイトで作業の進み具合に大きなずれがありました。シドニー側の作業を進めるためには、マウンテンビューのチームが担当しているプロジェクト作業が終わらなければならないのに、
それがいつまでたっても終わらないためシドニー側では不満を募らせていました。シドニーのエンジニアがマウンテンビューのチームを訪れてわかったのは、マウンテンビューに拠点を置くデベロッパーのアポなし訪問やメールへの対応で、朝から晩まで何度も仕事を中断されていることでした。
定期的に会議を開いてオンコール インシデントやプロジェクト作業について話し合い、マウンテンビュー側からは仕事が多すぎるのではないかという不満も出ていましたが、シドニーのチームはそうしたリクエストがどの程度なのか知らなかったためどうすることもできませんでした。そこでチームは、すべてのリクエストをバグとして送信するよう義務づけることにしました。マウンテンビューのチームは、顧客が急を要している場合はいつでもすぐに対応するよう訓練されていたため、習慣を変えるのに 3 か月もかかりました。しかし新しいやり方が定着してからは、両サイトをまたいだローテーションを組んで負荷を分散する体制を整え、発生した作業量と作業に要した時間の統計を確認し、頻発していて修正が必要な問題を特定できました。
Jamie は次のように述べています。「この経験から 1 つ学んだことは、測定すべきものをきちんと測定し始めれば、状況を示したうえで賛同を得ることができる、ということです。チームのメンバー全員にチケットの出入りの比率を示したら、一気に状況が変わりました。」
このような方法で作業を把握する場合は、次のような軽量なメタデータを好みのトラッキング システムで収集するとよいでしょう。
作業の種類（割り当ての変更、本番環境へのリリースの移行、ACL の更新など）
作業の難易度: 容易（1 時間未満）、普通（数時間）、困難（数日）（経過時間ではなく実際の作業時間で判断）
作業者
このような基本データがあれば、トイルの影響を測定できます。ただし、この段階では軽量ということにこだわってください。ここで几帳面になりすぎてもほとんど意味はありません。多数の詳細データの取得が必要となれば、むしろチームの負担が大きくなり、必要以上に細かく管理されていると
感じさせることになります。
トイルをうまく洗い出す別の方法として、チームのアンケート調査があります。もう 1 人の Google CRE である Vivek Rau は、Google の SRE 組織全体のアンケート調査を定期的に行っていました。SRE チームごとにトイルの規模と形態にばらつきがあったため、全社レベルのチケット指標では分析が困難だったのです。Vivek は 3 か月ごとに SRE チームを調査し、プロジェクト作業の時間を奪う問題として Google 全体で共通しているものを洗い出しました。トイルに関するアンケートのサンプルを以下に示しますので、調査を始める場合はこちらをご利用ください。
どのくらいの時間をトイルに費やしましたか。全体に占めるおおよその割合を、過去 4 週間の平均値でお答えください。
0～100%
トイルに費やした時間の長さについてどの程度満足していますか。
非常に不満 / 普通 / まったく問題ない
トイルの発生源として多いものを 3 つ教えてください。
オンコール対応 / 割り込み / プッシュ / 許容量 / その他
四半期目標に長期のエンジニアリング プロジェクトが含まれていますか。
はい / いいえ
「はい」の場合、どのくらいの時間をエンジニアリング プロジェクトに費やしましたか。全体に占めるおおよその割合を、過去 4 週間の平均値でお答えください（概算値でかまいません）。
0～100%
自動化のためのトイルに長期プロジェクトの作業時間を奪われるため、自動化できるのにそうしていないトイルがチーム内にありますか。ある場合は、下に記入してください。
自由回答
トイルを測定する
行われている作業の洗い出しが終わったら、作業量が過剰かどうかを判断する必要があります。方法は簡単です。さまざまな種類の作業にどのくらいの時間が費やされているのか、その概算値を定期的（毎月または 3 か月に 1 回が適当）に求めます。チケット、アンケート、オンコール インシデント対応別にパターンや傾向がないかを探し、費やされた作業時間の合計に基づいて優先順位を付けます。Google SRE 内では、トイルに割かれる SRE 1 人あたりの時間を 50% 未満に抑え、残りの 50% をエンジニアリング プロジェクトの作業用に確保することを目標にしています。トイルの割合が 50% のしきい値を超えていることが概算値からわかった場合は、この値を減らして作業の割合を健全な状態に戻すことを目標に、明確な作業計画を立てます。
トイルを解決する
洗い出しと測定が終わったら、いよいよトイルの最小化に取りかかります。すでにお気づきかと思いますが、ここでの解決策としては作業を自動化するのが一般的です。ただし、簡単に自動化できるケースばかりではありません。また、すべてのトイルをなくすことを目指すべきでもありません。
ほとんど行わないタスク（新しいロケーションへのサービスのデプロイなど）の自動化は難しい場合があります。というのも、再度同じタスクを行う頃には、自動化したときに使用した手順や想定した前提が変化している可能性があるからです。この種のトイルに多大な時間を費やしているとしたら、基盤アーキテクチャを変更することでそうした変動を小さくできないか検討してください。たとえば、システム管理に Infrastructure as Code（IaC）ソリューションを使用しているか、副次的な悪影響を与えずにその手順を何回も実行できるか、手順を検証するテストを行っているか、などです。
自動化の作業も他の本番環境システムと同様に扱います。SLO プラクティスを採用している組織の場合は、エラー バジェットの一部を使ってトイルを自動化してしまいましょう。自動化に失敗した場合は事後調査を行い、ユーザー向けシステムの場合と同様に問題を修正します。本番環境のインシデントも含め、どのような状況でも自動化を利用できるようにして、チームメンバーには各自の得意な作業をしてもらえるようにする必要があります。
チケットを開いてサポートをリクエストする方法をユーザーがすでに知っている場合は、チケット システムを API として使用して自動化を行い、すべての作業をセルフサービスで行えるようにします。
また、トイルは技術的なものばかりでなく習慣的なものでもあるため、この作業を行うのはトイル作業を明示的に割り当てられた人だけになるようにしてください。オンコール担当者がこの役目を引き受ける場合もありますが、当番制にしてエンジニアが順番で「チケット」や「割り込み」の処理にあたることもできます。このようにすると、それ以外のチームメンバーがプロジェクト作業を行う時間が確保されるうえ、トイルを明らかにして責任をもって対応するカルチャーが醸成されます。
複雑な作業とトイルの違い
技術や構成の面で複雑な作業をトイルと勘違いしているエンジニアやリーダーをときどき見かけます。人に与える影響は似通っていますが、そうした作業には本稿の冒頭で示したトイルの定義が該当しません。トイルとは基本的に長期的な価値がない作業で、複雑な作業とは価値はあるがやっかいだと感じさせる作業です。
Google 内で調査を行っている Google SRE の Laura Beegle は、複雑な作業には別の対処方法があると示唆しています。シンプルで強固なシステムを設計できたときは大きな満足感が得られますが、分散環境に存在するというだけで必然的にいくらか複雑になり、幅広いユーザーが使用している場合や、徐々に機能が増えていっている場合も複雑にならざるを得ません。システムを徐々に進化させる必要はありますが、いわゆる「経験上の複雑性」（タスクが想定より難しかった、あるいは時間がかかったという理由で生まれる否定的な感情）を少なくすることも必要です。システムを使用したときの主観的な経験を数値で表したものが、別名「ユーザー エクスペリエンス」と呼ばれるものです。この場合のユーザーは SRE です。システムの複雑さがうまく管理されていると、結果としてユーザー エクスペリエンスが改善します。
システムのサポートというユーザー エクスペリエンスへの対処は長期的価値のあるエンジニアリング作業であるため、トイルとは異なります。複雑さゆえにシステムの信頼性が失われつつあると気付いたら、対処が必要です。非難を伴わない事後調査プロセスに沿って調査を進めるか、チームのアンケート調査を行えば、複雑さのせいで想定外の結果を招いていた状況や復旧時間が予想より長くなっていた状況を特定できます。
システムを構築する場合に手動による管理やデータ入力がいくらか必要になることは避けられませんが、VM、ユーザー、リクエストの数に比例して必要な人員数を増やすべきではありません。エンジニアである私たちは、コンピュータを使って定型業務を処理できることを知っているのに、そうした作業を手動で行っている場合がよくあります。トイルの洗い出し、測定、削減によって運用コストを削減でき、困難ながらも興味深いプロジェクトに専念する時間を確保できます。
SRE について詳しくは、SRE の基礎が学べるこちらの記事、または SRE の書籍をご覧ください。
- By SRE システム エンジニア Eric Harvieux
