開発者を叱責の無間地獄から解放するためのメトリクス

• DevOps & Product Teams – Win or Fail?
  • http://www.infoq.com/articles/devops-product-teams

DevOps色の強いインフラチーム（infrastructure team）に所属していた著者が、DevOpsの原則が通用しないプロダクトチーム（product team）に移って受けたカルチャーショックと、そこから、従来の「運用チーム（operations team）」という考え方は止めて、プロダクト開発者のためのサービスを開発・運用する「プラットフォームチーム（platform team）」へ移行するべきだという発想に至るまでの話。

この記事では、運用というものが、障害を起こさないという方向に強く動機付けられていて、それがプロダクトを常に更新していかなければならない開発者の利害と衝突してしまうという問題を指摘している。障害が起きたら、たとえ深夜であろうが、まず対応しなければならないのは運用チームであるため、運用としては出来るだけ障害が起こらないよう、システムの変更に対しては保守的にならざるを得ない。

つまり、問題の本質は「維持」と「変更」の対立であって、これは運用だけに限ったことではなく、障害が起きた時に顧客対応しなければならない営業やカスタマーサポートでも同様の問題が起こる可能性がある。

DevOps界隈でよく話題になる、開発者から嫌われる運用チームの人物像というものがある。何故こんな人物像が生まれるかと言えば、「維持」に動機づけられた側の人間が、システムを変更し障害をもたらした人物に対して責任の追及を行う（finger-pointing）ということが頻繁に発生するからである。これは上に書いたように運用に限らず、「維持」と「変更」のトレードオフを理解しない人間によっても度々行われるため、組織で働く開発者というのは常に、完璧に防ぐことが原理的に不可能な問題で、叱責され続ける運命にある。

この問題を解決するためのヒントとなりそうなのが、この記事で紹介されている MTTR と MTBF という二つのメトリクスである。

MTTRというのは Mean Time to Recovery の略で、障害が起きてから回復するまでにかかった時間の平均である。一方、MTBFは Mean Time between Failures の略で、障害から回復後、次に障害が起こるまでの時間の平均、つまり平穏無事にシステムが動き続ける時間の平均である。

「維持」に動機づけられた人間は、これら二つの指標の内、MTBF、つまりシステムが平穏無事に動きづける時間の最大化を目指す。これを MTTR の方に重きを置くように考え方をシフトさせる事が出来れば、開発者の精神的な負担は大分軽くなる。

「維持」と「変更」がトレードオフの関係であること、システムを変更し続けなければ組織のミッションは果たせないというところから、「変更」に対する理解を得ることはそれほど難しくない。しかし、どこまで障害に対して許容するかとなれば、利害が異なる二つのグループの間でそう簡単に折り合いがつく訳でもない。そのような時に「障害をいかに起こさないか」という考え方から「障害が起こる事自体はそれほど大きな問題ではない、問題はいかに早く障害を解決するか」という方向に考え方を変える事が出来れば、変更に対する抵抗も低減するし、変更は MTTR を最小化するための学びの場となる。