トイル撲滅の刃
この記事では、エンジニアの業務におけるトイルの解説とトイル撲滅のステップについて執筆します。
お気づきと思いますが、タイトルは、鬼滅の刃のパクリです。
この記事がトイルという鬼を滅する刀になればという思いを込めています😃
「SRE サイトリライアビリティエンジニアリング ――Googleの信頼性を支えるエンジニアリングチーム」の「5章 トイルの撲滅」の内容をベースに書きました。
単に書籍の内容をまとめるだけでなく、トイル撲滅の具体的な手段 も書いています。
トイルについての理解を深め、トイル撲滅のヒントを得ていただければ幸いです。
書籍はSRE向けに書かれていますが、トイル自体はSREに携わるエンジニアだけが抱える問題ではありません。(つまり、ほぼ全てのエンジニアに役立つ内容のはず！)
トイル(Toil)とは
トイル(Toil)とは直訳で「苦しい仕事」、「骨折り」、「苦労」などという意味になります。
この説明を聞くと単に苦しい仕事=トイルに見えますが、SREにおけるトイルは少し違います。
後ほど説明しますが、以下の項目はトイルにはあたりません。
- 管理上の雑務(オーバーヘッド)
- つまらないかもしれないが長期的に価値がある仕事
SRE上のトイルは、プロダクションサービスを動作させることに関するもので、以下の傾向を持ちます。
- 手作業であり、繰り返されることであり、自動化できること
- 割り込み作業 [1]
- 長期的な価値を持たない
- 作業量がサービス成長に比例すること
1つ以上該当すれば、トイルである可能性があります。
ただし、前提としてトイルは苦しい仕事であることを指します。
ですので、上記に該当するタスクでも負担になっていなければトイルではありません。
とくに単発で少量のタスクであれば、放置しておいてよいでしょう。
手作業であり、繰り返されることであり、自動化できること
ある作業をするのが初めて or 2回目くらいまでならば、トイルではないです。
また、人間の判断が必要で自動化できないこともトイルではないです。
上記に該当しないタスクは、トイルである可能性が高いでしょう。
注意点として、単に作業を自動化するだけではトイルを解消したとは言えません。
スクリプトを走らせるたけの実作業に人間が使う時間は、トイルの時間と言えるからです。
例えば、定期的に動作させる必要があるスクリプトは、
定期実行する仕組みを作ることで、はじめてトイルを完全解消できたといえます。
割り込み作業
割り込み作業はだいたいトイルです。
この種のトイルは、完全に無くすことはできないですが、極力無くすべきです。
例えば、アラート通知については自動復旧するしくみを作り、減らすことができそうです。
長期的な価値を持たない
あるタスクを終えたあとでも、サービスが同じ状態のままなのであれば、そのタスクはおそらくトイルです。
サービスが同じ状態は表面だけでなく、内部的な状態も指しています。
例えば、コードリファクタリングです。
コードの改善で開発効率を上げることにつながるため、長期的な価値を持つ改善にあたるといえます。
作業量がサービス成長に比例すること
サービスのトラッフィクやユーザー数に比例して、何かしらの作業が発生するならばトイルです。
少なくともトラフィックやユーザー数が10倍になっても耐えられる設計をすべきだと書籍には書いてありました。
SRE上のトイルにはならないもの
以下、2点は人によっては苦しい仕事になるかもしれないですが、SRE上のトイルではありません。
管理上の雑務(オーバーヘッド)
管理上の雑務はSREにおけるトイルではありません。
これらは、トイルとはオーバーヘッドと呼ばます。
つまらないかもしれないが長期的に価値がある仕事
つまなかったり、苦しかったりする仕事でも長期的に価値を生む仕事があります。
これらは多くのエンジニアにとっては退屈でつまらない仕事でしょう。
人的判断が必要なタスクのため自動化も難しいです。
しかし、実施することで安全で効率的なシステム運用ができるので長期的な価値を生む仕事といえます。
トイルはメンバー間で偏らないように
GoogleのSREチームはトイルは50%以下に抑えて、
残りはトイルの削減やサービスの機能追加等のエンジニアリング業務にあてているそうです。
チームの業務全体(難しければ自身の業務だけでも)で
- トイルに当たる業務
- トイルにかけている時間
を洗い出すところから始めるとよいと思います。
また、私個人としてはトイルにかける時間以上にメンバー間でのトイル負荷を均一化することが大事だと考えます。
トイルは性質上経験を積んだエンジニアに偏る傾向があります。
とくに緊急を要する問い合わせ対応などはその典型です。
特定のメンバーにトイルが偏ると、メンバー間の摩擦につながります。
また、トイルが偏ったメンバーの退職リスクもありそうです。
そうならないためにもトイルはメンバー間で極力均一になることが求められます。
書籍にも書かれているのですが、サービスの問い合わせ対応などはメンバー間でローテションを組むなどするとよさそうです。
トイルは常に悪か?
結論として、常に悪ではないです。
冒頭で説明した通り、トイルを直訳すると「苦しい仕事」なので、
手作業や繰り返しの作業でも「苦しい仕事」に該当しなければ、トイルではありません。
とくに少量で予測可能なタスクであれば、トイルの度合いは低くいでしょう。 [2]
ただ、どのくらいの量のトイルが負担になるかは人それぞれです。
チーム開発においては、認識合わしたうえで、解決すべきトイルに優先度をつけられるとよさそうです。
トイル削減のステップ
ここは、完全に私の意見です。
これまでの内容を踏まえてトイル撲滅までのステップを考えました。
- チーム内で業務の中のトイルを洗い出す
- トイルにかかっている割合を出す
- 作業時間等を基準に対策すべきトイルに優先度つけをする
- 定期的にトイルを削減する時間を作る
- 1から4を繰り返す(ステップ2でトイル削減効果を確認)
まとめ
SREのトイルについてまとめました。
SREの本をベースに書いたので、サービス運用に携わるエンジニア視点の話が多かったとおもます。
しかし、サービス運用にたずさわらずとも、何かしらのトイルを抱えているのエンジニアは多いのではないでしょうか。
トイルという鬼を滅して楽しいエンジニアライフを送りましょう！
以上です。
Discussion