r-kaga's log

TopBlogBookmarks

事故ゼロをKPIとすることは適切?

19 December, 2020

概要

ソフトウェア開発/運用に携わっていると事故、障害、インシデントというものは残念ながらそれなりに身近なものである。
当然事故というのは減らす、なくしていくのが大前提ではあるが、とは言え事故ゼロ自体をそのままKPIとしてしまうのはどうなんだろというのを考える機会があり、せっかくなのでまとめてみる。1  

前提

  • サービスの稼働率を表すような別の指標は存在していない

    • シンプルに事故件数=サービスの稼働率を図るような指標に暗黙的になっている
  • 事故の重大度と言う概念も存在しているが、基本は事故件数を減らすのが目標

結論

事故ゼロは良いKPIであるとは言えない。理想はSLI/SLOを定め運用すべきであり、それが無理でも、少なくとも事故の件数ではなく単純な月間稼働率を追うだけでも良いKPIになると思う。
またあえて事故の件数を追うケースもありうると考えているが、サービスの稼働に関しては事故ゼロををKPIとしないのは前提としつつも、それ以外の要因で事故の件数を明確に示す必要がある際には事故ゼロをKPIとするのもありかも。

詳細

まずは単純に事故ゼロをKPIとすると、よくない数値の作り方ができてしまうのでKPIとしては優れていないのではと思う。
ゼロにするための施策として、リリース件数を減らす、テスト期間を長く伸ばす、など達成した結果ビジネス面など、他の箇所でマイナス要因となってしまいそうな施策が成立してしまう可能性があるため、これだけをKPIとするのは有効ではないのではと感じる。2

そしてそもそも事故ゼロをKPIとした場合に、本来成し遂げたい結果とは解離しているケースもあると思っている。
例えば、事故ゼロをKPIとして達成したい事が、本来はユーザーに対して滞りなくサービスが提供できる/することの場合、事故の件数を減らすだけだと、必ずしも上記の目指していることが達成できているとは一概にいえない、またサービスの運用観点では大切にしたい詳細がスルーされる状況が発生してしまうと思っている。

例えば以下の二つは、サービス提供の観点からは、全然影響度が異なる事故であるはずだが、事故の件数だけでカウントすると単に予測可能な事故が2件という扱いになってしまう可能性が高い。
(後者はなぜこうなった感が強いが)

  • 事故は起こったが、カナリアリリースをしていて、リリース後10分ほどで切り戻せた場合
  • 事故に気づかず、1週間サービスインしていた場合

そして事故ゼロを目指すだけだと、前者のような対策を行うモチベーションは存在せず、開発チームにとっては優先順位が上がらないままとなり、結果として一つの事故を起こすことによる影響度が高いままとなる可能性があるのではと思う。

先に触れたリリース件数を減らす、テスト期間を伸ばす、などの対策も結果的にユーザーへの機能提供が遅れてしまい本末転倒では感が強い。
また事故の定義にもよるが、レイテンシが悪化した場合などは、正常にサービスが提供できているとは言い難いが、果たしてこれは事故としてカウントされるのかが疑問。  

上記のような理由から、事故ゼロをKPIとするのはベストであるとは言えない。
個人的には、理想はSLI/SLOを定め運用すべきであり、それが無理でも、少なくとも事故の件数ではなく月間稼働率を追う方が良いKPIだと思う。

例えば月間稼働率をKPIとするのであれば、単に事故ゼロを追う以上に施策の幅を広く取れるため、開発者としても様々な施策を考えやすい。
リリースフローの改善や異常発生時の検知、ロールバックを早めるための仕組みのアップデートも有効な施策になりえるが、特にロールバックを早めるための仕組みは、少なくとも事故ゼロを目指す上では特に影響を与えない。ロールバックをしている時点でおそらく事故としてカウントされてしまっている。
(事故の定義によっては異なる可能性はあるが)

またこれは他社の事例には詳しくないので単なる想像/仮定の域を出ないが、事故の定義をある程度決めてしまっているケースがある場合は、より事故ゼロというのが本来達成したいものとは解離するケースが増えるように思える。
例えば外部PFの影響で不具合が発生した場合などのように、予測が難しい、アンコントローラブルなものは除外をして、あくまでも自分たち起因で、予測可能なものだけを事故と数えるケースなど。
色々な内部事情で上記のような内容になってしまっているケースもあるのではと思ったりするが、この場合事故件数は増えていないが、サービスの提供には影響を受けているといった事象が発生しうる可能性があり、事故ゼロというのが正確にサービスの稼働を表す数値ではなくなってしまっている。

とは言え大規模な事故が続いた際など、あえて事故の件数を追うってのはありうるかなと思っているので、まずはサービスの稼働に関しては別の数値をKPIとするのを大前提としつつも、それ以外の要因で事故の件数を明確に示す必要がある際にはそうするってのがベターではと思う。

まとめ

サービス、システムを開発、運用していく上で、どうしても事故ゼロを目指すのは現実的ではなく、ある程度の障害などはどうしても発生してしまう。
その上で、ユーザーにきちんとサービスを提供し続けるという本来の目的を考えると、安易に事故ゼロをKPI とすると、各チーム、開発者に対してサービス運用の観点で必要な対策を行うモチベーションを与える事も出来ないため、SLI/SLOを定め、少なくともサービスの稼働に関するKPIとしては、SLI/SLO使うのが適切であると考える。
後は何より、一開発者としても単に事故ゼロを求められたり、ただただレビューや承認フローが重くなるのは辛い。チェックリストが増えるだけの事が多い印象。

参考

SLO、SLI、SLA について考える : CRE が現場で学んだこと
メルカリのWeb MicroservicesにおけるSLI/SLO


  1. 明確に違いがあるような気がするが、事故と障害はほぼ一緒の意味で使っている。

  2. 正直KPIの設定方法には詳しくないので、この辺りの問題に関しては「測りすぎ――なぜパフォーマンス評価は失敗するのか?」が参考になりそうなので読みたい。

© 2021, Built with Gatsby