休暇に入る少し前、自分のチームの TL が「アプリの MTTF 取りたいなー」とバグをファイルした。すでに集めているメトリクスから適当に計算できるのでは、という期待があったようだけれど、ちょっと考えてみるとまあ無理。というか Android  アプリの MTTF はどう計算すればいいのだろうか。

Android の文脈を離れると、MTTF はクラッシュ間隔の平均値を取れば良い。そして Play Services のようなシステムに近いサービスやメッセージングやチャットみたいなほぼ常駐する性質のアプリならこの計算方法で意味がある。けれどたとえば一日一回くらい起動してコンテンツを眺めるようなのアプリだと、単純にクラッシュ間隔を求めても仕方ない。

そこでまずアプリが前面にいるときの時間を記録しておくことにした。そして前回のクラッシュから次のクラッシュまでどれだけ前面にいたかを TTF, time-to-failure とみなす。この指標は悪くない。ユーザからみてどれだけ頻繁にクラッシュするかを表した指標だから。

けれど細かいところに疑問はのこる。具体的には sync など何らかのバックグランド処理中、画面を見せていないときにおきたクラッシュはどう扱うべきか。ユーザの体感クラッシュ頻度という観点だけを考えると、これら background crash は無視してよい。けれどアプリの安定性を気にするならこの crash も指標に加えてあげたい。

そこで厳しい側に倒すべく、バックグラウンドだろうがなんだろうがクラッシュのタイミングで TTF を計上することにしてみる。もし background crash がおきたら、前回の crash からその時点までの foreground 時間の合計を計上する。この方法の問題は、画面を表示することなく二回つづけて background crash がおきると二回目の crash の TTF がゼロになってしまうこと。厳しすぎじゃね？

とはいえ厳しい側に倒す方針なのでまずはこれでよい。厳し目に計算した MTTF をモニタリングしておき、値が下がったら詳しくデータを調べればいいから。そうした breakdown につかうべく TTF event の付加情報として crash した時点でアプリが前面にいたかどうかの状態も送っておく。

というかんじで MTTF が計算できるようになった。のだけれど、休暇に入ってしまったので出荷されたコードがほんとに正しく動いてるかどうかはまだ調べてない。