💡
トイルとは何か？
- トイルとは、「サービスのメンテナンスに関係し、繰り返され、予測可能で、定常的なタスクの流れ」を トイル と定義する
- システムのメンテンナンスには、どうしてもある程度のロールアウト、アップグレード、再起動、アラームの整理などが避けられず、トイルは不可避なもののように見える
- しかし、これらの活動はチェックして計算しておかなければ、チームの開発能力を急速に消耗させる
エンジニアリングであるための条件
- エンジニアリングの作業とは、新しいものをするものであり、本質的に人間の判断を必要とする
- SREでは活動を4つに分類し、ソフトウェアエンジニアリングが50%を上回るように維持する
-
トイルは放置しておくと急速に拡大し、全員の時間の100%を埋め尽くしてしまう傾向がある
- だからこそ、トイルを少なくするように継続的に削減する必要がある
ソフトウェアエンジニアリング
- コードの作成や修正を含む作業であり、関連する設計やドキュメンテーションの作業も含む
システムエンジニアリング
- プロダクションシステムの設定、設定の変更、システムに関するドキュメント作成が含まれ、1回の作業で改善効果が持続するようなこと
- 例えばモニタリングのセットアップやOSのパラメータのチューニングなど
-
アーキテクチャ、設計、プロダクション環境へのセットアップなども含む
- 大きくは1度で終わるような作業のこと
トイル
- サービスを稼働させることに直結している作業で、繰り返されたり、手作業だったりするもの
オーバーヘッド
- サービスを稼働させることに直結していない管理的な作業
- 例えば、採用、人事の事務作業、チームミーティング、自己評価、社内セミナーなど
トイルが持つ特徴
- トイルは必ずしも常にこれらの条件全てを満たすわけではないが、特定の作業がチームの士気に与える影響を考えて、可能ならば取り除くように行動しなければならない
手作業
- Webサーバーのtmpディレクトリの利用率が95%に達したら、サーバー内にログインして、重要ではないログファイルをファイルから探し出して削除する
繰り返し行われる
- tmpディレクトリが一杯になるのは定期的に発生する
自動化可能
- 「X にログインしてこのコマンドを実行し、出力をチェックし、結果によっては Y を再起動して......」というような作業手順書があるのであれば、それは本質的には自動化可能である
-
人間が作業するのではなく、問題の検出と改善を自動化すればいい
- 95%に達したら自動的に特定のログファイルを削除する、など
非戦略的
- 「ディスクフル」「サーバーダウン」などのアラートが日常的に発生していると、潜在的に重要なアラートに気付けなくなる
- これはエンジニアが高付加価値の作業に集中できておらず、非戦略的である
持続的な価値の欠如
- ログファイルを削除することは、タスクが完了したという意味で短期的には満足をもたらす
- しかし、今日そのチケットを解決しても、将来その問題が起こらない（根本的に解決されている）わけではないので、見返りは短期間のものでしかない
- 長期的に価値がある作業に集中できるようにする
発生源と同じ速度で成長する
- 多くの運用作業は、インフラのサイズの成長と共に増大する
- 物理的な修理作業がマシン数と合わせてスケールするのは避け難いことであるが、ソフトウェア/設定の変更は必ずしもそうではなく、インフラが増大しても作業が増えないようにする工夫をするべきである
トイルの見分け方
-
トイルは多くの形を取るため見分けることが難しいが、その場合はこう考えてほしい
- 「メンバーはタスクを行うのを楽しんでいて、それが報われていると感じているか？」
- 「その仕事は、つまらなくて報われないものと見られて軽視されていないか？」
-
トイルに費やされる時間は、多くの場合は重要な思案や創造性の発揮に使われた時間
ではない
- トイルはゆっくりとチームの士気を低下させる
- 先輩がやっているから仕方ない、ではなく、トイルを撲滅しよう
トイルの計測
- 運用作業のどれだけがトイルなのかを知るためにはどうすればいいか？
-
多くのSREチームはこの疑問に対して「経験」と「直感」を使って答えてしまう
-
しかし「経験」や「直感」は客観的でなく繰り返すことも他人に受け渡すこともできない
- つまり納得できるやり方ではなく、再現性もない
-
しかし「経験」や「直感」は客観的でなく繰り返すことも他人に受け渡すこともできない
-
トイルを客観的に計測する方法を考え、問題の重大性を評価し、優先度を決定し、それに投資することが妥当だという正当性を示すことで、リターンを最大限に得ることができる
- 実際の仕事においてもこの考え方は重要
コスト対メリットの分析
- トイル削減のプロジェクトを開始する前に、トイルの撲滅によって節約される時間が、自動化のための最初の開発とその後のメンテナンスに投資される時間に見合うことを確認する
-
節約される時間と投じられる時間を比較するだけでは「利益がない」ように見えても、無形のメリットのために行う価値があるかもしれない
-
無形のメリット
- 時間ともに増大する可能性のあるメンテナンスコストの作業の抑制
- チームの士気の強化および消耗の抑制
- 割り込みによるコンテキストスイッチの減少。それに伴うチームの生産性の向上。
- チームメンバーの技術的スキルの拡大およびキャリアの成長
- ヒューマンエラーによる障害の減少
- セキュリティの改善
-
無形のメリット
トイルをどうやって計測するか？
- SRE本第5章「トイルの撲滅」より
トイルを特定する
- 上の「トイルが持つ特徴」に当てはめて、トイルを特定する
- 実際に作業を行う人たちが最も気付きやすい立場にいるはず
トイルに費やされる計測の単位を決める
- 人間の作業量を表現するために適切な計測の単位を選択する
- 例えば「分」や「時間」は誰にでも理解される単位である
-
ただし、もしコンテキストスイッチ（作業を切り替えること）の負担が高いという労力の場合などには、他の計測単位を採用した方がいい場合もある
- 完了したチケット数
- 手作業によるシステムの変更
- 予想されるメールのやり取り
- ハードウェアの運用
- 単位が客観的で一貫性があるものなら、トイルの計測方法として役立つ
継続的に計測する
- トイルの削減作業の前・作業中・後を決めた単位で継続的に追跡する
- ただしこの追跡作業自体がトイルにならないように注意する（自動化する）
まとめ
- トイルはエンジニアリングでは必ず発生する問題である
- 私たちが優れたエンジニアリングによって毎週少しずつトイルをなくしていけば、徐々にサービスをクリーンアップし、全体の労力を新しい価値の創造に割り当てることができるようになる
- イノベーションを増やすためにトイルを撲滅しよう