第73条
トイル
手作業の繰り返し運用はサービスと一緒に増え、放っておけば開発の時間を食い尽くす。
心得
繰り返す手作業は、務めではなく欠陥として扱う
どうするか
一人ひとりの時間のうちトイルが占める割合を測り、上限を決める(Google は 50%)。同じ作業が三度目に来たら(本書ではなく経験則)開発タスクとして起票する。利用者数に比例して増える作業は、雑用ではなく欠陥として扱う。
なぜ起きるか
トイルとは、手作業で、繰り返し発生し、自動化でき、割り込みでやって来て、片づけてもシステムが良くならず、トラフィックや利用者数に比例して増える作業だ。一件ずつは小さく急ぎなので、その場では必ずプロジェクト作業より優先される。サービスとともに増えるのに開発の時間は増えないので、押し返さないチームは、最後にはトイルしかしなくなる。
実際にあったこと
Google のデータセンターネットワークでは、Saturn と Jupiter のスイッチで故障したラインカードを一枚ずつ手で処理していた。トラフィックを移せるか確かめ、スイッチを切り離し、カードを再起動か交換して、元に戻す。Jupiter はそれまでのどのファブリックより6倍以上大きく、修理の件数も同じように増えた。チームは手順を自動化し(1回目は再起動と再インストール、2回目で交換)、エンジニアを別の仕事に回せるようにした。自動化の前にメモリエラーの分析へ3年近く(2012年から2015年)かけたのは不要だったとも結論づけている。
記録を読む当てはまらなくなるとき
自動化の皮肉:作業を自動化すると、自動化がうまく動かなくなったときに人が対処するための慣れが失われる。作って動かし続けるコストが、置き換えたトイルより高くつく自動化もある。
出典
Vivek Rau「Eliminating Toil」、Beyer, Jones, Petoff & Murphy 編『Site Reliability Engineering』(O'Reilly, 2016) 第 5 章。トイルの定義と 50% 上限の出典。
原典を読む