SREの導入で重要な項目のひとつに「トイルの削減」が挙げられます。しかし、トイルを削減すると言っても、「トイルをどのように定義し、何をどこまでトイルとして扱うのか」の判別が難しい場合があるかと思います。
そこで、本記事ではトイルの定義に加えて、トイルを削減するメリットやトイルの判別に役立つポイントを解説します。SREの導入やトイルの削減に関心がある方は、ぜひ最後までお付き合いください。
- トイルの定義と判別方法
- トイル削減はなぜ必要なのか
- サービスのスケーラビリティに悪影響を及ぼす可能性がある
- トイルの自動化によりヒューマンエラーのリスクを減らせる
- エンジニアが本来の作業に集中できない
- トイルを削減するための5ステップ
- STEP1：トイルの洗い出し
- STEP2：トイルを測定する
- STEP3：トイルに優先順位をつける
- STEP4：トイルを解決する
- STEP5：定期的な見直しを行う
- トイルを拒否する/まとめて並列処理する
- トイルをセルフサービス化する
- SLOを利用したトイル削減
- SREの導入実績豊富な弊社がサポートします
トイルの定義と判別方法
toil（トイル）を直訳すると「苦労」「骨が折れる」といった意味を表す言葉です。この表現だけを見ると「トイル=面倒で苦労のかかる仕事」と理解してしまいがちですが、SREにおけるトイルには明確な定義が存在します。
Google Cloud Blogに投稿されたこちらの記事によれば、トイルとは
- 手作業であること
- 完全な手作業だけでなく、「あるタスクを自動化するためのスクリプトを、手作業で実行する」ことも含まれます。
- 繰り返されること
- 1度、2度で終了する作業ではなく、繰り返し何度も行われる作業です。
- 自動化が可能なこと
- そのタスクの処理において「手作業と同レベルで自動化が可能」または「タスクの必要性がなくなる仕組みを作れる」場合を指します。
- 戦術的であること
- 戦略的なタスク、または予測に基づくタスクではなく、通常タスクに割り込んで行われる問題対応的なタスクを指します。
- 長期的な価値がないこと
- 「古いコードや設定を踏み込んで整理する」といった、短期的には必要だが、長期的にサービスに価値をもたらすわけではないタスクを指します。
- サービスの成長に比例して増加すること
- サービスのサイズ、トラフィックの量、ユーザー数などに正比例して増加するタスクは、おそらくトイルである可能性が高いといえます。
といった特徴を持つ作業のことを指します。自社の作業においてトイルを判別する場合、上記の項目に当てはめて考えることで、トイルが判別できるはずです。その際、「作業の種類」「作業の難易度や作業にかかる時間」「作業の発生頻度」を把握することで、トイルの削減による作業効率向上の手がかりになるでしょう。
また、トイルの具体的な例としては以下のような物が挙げられます。
- アカウント発行業務
- データベース スキーマ変更の適用
- 日々のアラートトリアージ業務
- ネットワーク設定変更…etc
上記の項目はすべて定常的で、「ある程度パターン化できる作業」という共通点があります。
逆に、システムの開発に必要なコーディング作業やオーバーヘッド（管理上の雑務）などの作業はトイルには含まれません。
参照：Identifying and tracking toil using SRE principles
トイル削減はなぜ必要なのか
Googleが提唱するSREにおいて、トイルは50％以下に抑えることが推奨されていますが、そもそもなぜトイルを削減する必要があるのでしょうか。ここでは大きく3つの視点で、トイル削減の必要性について解説します。
サービスのスケーラビリティに悪影響を及ぼす可能性がある
先述したトイルの定義の中にある「サービスの成長に比例して増加するもの」が、サービスのスケーラビリティに大きな悪影響を与えてしまうという点です。サービスが成長してアクセス数やデータ数が増えることで、手作業でのリカバリが増えた、確認すべきアラートが増えた、手作業による承認が増えた、などがその一例です。
また、運用が最適化されていないことを示す例として。最も一般的なものは「サービスが成長して売上が増加したが、成長と正比例して運用コストも増加した」というものです。
トイルの自動化によりヒューマンエラーのリスクを減らせる
主なトイルの削減方法は「自動化」です。自動化は再現性があるため、ヒューマンエラーのリスクを減らす点で役立ちます。特に単純な作業や定常化している作業は集中力が切れやすく、ヒューマンエラーが起こりやすいといえます。トイルを明確化・自動化し、ヒューマンエラーが発生するリスクを抑えることは、結果としてサービスの信頼性向上に貢献します。
エンジニアが本来の作業に集中できない
エンジニアがトイルに忙殺されている組織では、エンジニアが本来の役割である新機能の開発やシステム改善作業に工数が割けないことを意味します。これはサービスの向上を妨げると同時に、エンジニアの士気低下にも影響しかねません。トイルは定常的で、「ある程度パターン化できる作業」だという事を認識し、改善する必要があります。
トイルを削減するための5ステップ
トイルを削減するためには、以下のようなステップを踏むと良いでしょう。
STEP1：トイルの洗い出し
洗い出しの方法としては、「定例会議で洗い出す」「社内アンケートで集計する」「ステークホルダーへのヒアリング」といったやり方があります。プロジェクトごとにトイルの規模や発生頻度は異なるため、チームないしプロジェクト単位で実施することが望ましいでしょう。
STEP2：トイルを測定する
トイルの洗い出しが終わったら、各トイルの作業量や工数を把握するために測定します。TrelloやAsanaといった工数管理ツールとTableauやLookerといったBIツールを組み合わせて管理すれば、各トイルにかかる工数を可視化することが可能です。
STEP3：トイルに優先順位をつける
日々の運用業務の稼働を分析しつつ、作業頻度やかかっている作業時間をもとに優先順位付けを行います。同時に削減すべき割合を概算し、削減のための手段を考えます。
STEP4：トイルを解決する
トイルの解決方法として一般的なのは「作業の自動化」です。しかし全ての作業を自動化するというのは現実的に難しいため、作業頻度や作業時間をもとにどれだけの工数がその作業に割かれているかをもとに自動化することを心がけると良いでしょう。
STEP5：定期的な見直しを行う
トイル削減の取り組みが我々の活動にどのように影響しているのか、定期的に振り替えることが必要です。
トイルを拒否する/まとめて並列処理する
トイルの削減について、関係するチームや部門の合意が得られる場合は、上記に記載したような「トイル削減に向けたステップ」に踏み出すことができます。
「トイルを削減する」という目的に向かって進む際に取り得る方法は、「トイルに正面から取り組んで削減する」だけではありません。場合によっては、「トイルを拒否する」「まとめて並列処理する」という方法も有用となりえます。
トイルを拒否する
SREについての実践に関する詳細が記載された本である「サイトリライアビリティ ワークブック」では、「トイルだらけのタスクを拒否することが最初に考慮すべき選択肢である」と記載されています。
具体的には、「トイルに対応するコスト」と「トイルに対応しない（拒否する）コスト」を分析し、トイルに対応しないほうが低コストである場合は、あえてトイルに正面から挑んで自動化する必要はありません。
また、トイルを拒否したが、特に問題が発生しなかったという場合もあります。これは「必要だと思われていたトイルが、実は不要であった」ことを示します。この場合は、「トイルの自動化」すら不要で、単にトイルを廃止するだけで済みます。当初は必要であった作業プロセスが、長期間の運用に伴い形骸化してしまうことも少なくはないため、定期的にトイルの必要性を吟味するという事も必要になるでしょう。
まとめて並列処理する
トイルの撲滅に取り組む第一段階として、「トイル処理をできるだけ先延ばしにして、まとめて並列処理する」という方法もあります。
はじめに、現時点で「毎日」行っているトイルがある場合、本当に毎日行う必要があるのかを確かめるために、頻度を減らして遅れて実施してみます。この意図的なトイル処理遅延により、現在の頻度でトイルが処理される必要が本当にあるのかについて判断できるようになります。
次に、同様のトイルをまとめて並列処理するという方法があります。トイル撲滅・自動化までには時間がかかるが、遅延させて処理可能なトイルが複数ある場合、複数のトイルを同じタイミングで並列処理することで、トイル処理にかかる工数を軽減できます。並列処理はゴールではなく、トイル撲滅に至るまでの一過程ではありますが、効果的であることは間違いありません。
トイルをセルフサービス化する
数あるトイルの中でも、突然の割り込みが求められるが、作業を定型化できるものとして「問合せ対応」があります。
ユーザーからの問合せ対応のうち、分かりやすい例をあげると、「ユーザーアカウントを紛失した」「パスワードを忘れてしまった」「規定回数以上誤ったパスワードを入力しアカウントがロックされた」などがあります。
また、開発部門や情報システム部門からの問合せの分かりやすい例としては、「新しいクラウドリソースの新規作成リクエスト」「稼働中のサービスのリソース追加リクエスト」「新規ユーザー追加とプロビジョニング」などがあります。
上記のようなトイルを削減するためには、「Webフォーム」「バイナリやスクリプト」「API」「ドキュメントの提供」といった方法が有効です。できるだけ複雑なプロセスを組むのではなく、シンプルにWebフォームを提供する、スクリプトを提供するといった対応を実施し、トイルの発生原因となる要素を自己解決できるようにするほうが双方にとって工数が少なくて済みます。
SLOを利用したトイル削減
十分に定義されたSLOがある場合、エンジニアはトイル削減に対して、情報に基づいた判断を下すことができます。具体的には、「特定のトイルを行わなかったとしても、エラーバジェットを消費しない」のであれば、あえてそのトイルを無視することも可能です。
これは、「多数のトイルを『サービスの信頼性向上のために寄与する』と信じて、漫然と行ってきた」ことに対する問題提起となります。これまで行ってきたトイルは、SLOの観点から本当に価値を生んでいるのか、そしてトイルを完了させるための工数と見合うのか、という観点から、これまで行ってきたタスクを自動化せず、やらずに済ませることが正解となる場合もあります。
SREの導入実績豊富な弊社がサポートします
SREを導入する際、トイルをどう判別するかは重要なポイントです。今回紹介したトイルの定義に基いて判別し、解決へのステップを進めることでトイル削減に着手できます。しかし、「トイルを判別できたが解決方法が分からない」「トイルが多すぎて優先順位がつけられない」「最適な自動化方法が分からない」といったケースもあるかと思います。
弊社はこれまで多くの企業様のSRE導入のお手伝いをしてきました。トイルの削減はもちろん、サービスの戦略策定から設計・構築・運用、ならびSREに必要なSaaSの導入支援までサービスの成長に必要な要素を統合的に提供可能です。
もし少しでもSREに興味があるという企業様がいらっしゃいましたら、気軽にお問い合わせください。
東京在住のソフトウェア開発者、Motouchi Shuyaです。
システムの開発・運用・最適化が好きです。