> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/ja/2022/w23-a-stability-metric-that-accurately-describes-customer-impact.md). # W23-顧客への影響をより正確に表す安定性指標 ### **背景** なぜ安定性指標を考え始めたのか。最近のいくつかの出来事が重なり、この考察につながった。一つは愚公の災害復旧対応を準備していること。二つ目は可用性の向上が今年のチームの O2 で、忠沢の計画づくりを支える必要があること。三つ目は Jerry が先日勧めたデータ思考の講座から、多くの示唆を得たことだ。 ### **基礎概念** サービスには高い可用性、信頼性、安定性が必要だとよく言う。広く捉えれば、成功率に似た指標が一つあれば十分にも見える。しかし狭義では、三つは同じ概念ではない。 **Availability、可用性。** 観測期間のうち、システムが正常に動いている時間の割合。**使えるかどうかを表す。** **Reliability、信頼性。** 所定の時間間隔と条件のもとで、システムが障害なく動き続ける確率。**正しいかどうかを表す。** **Stability、安定性。** 一定の負荷条件のもと、ある稼働周期で操作を続ける間のエラー発生確率や、性能劣化の傾向などを指す。フロントエンドの実行環境は中央集約されず、各端末に分散している。そのため、**安定性は異なる機種とネットワーク条件で、ソフトウェアが快適に使えるかを表す。** 関係は次のように理解できる。信頼性が低いと可用性へある程度影響するが、逆は必ずしも成り立たない。使えることは信頼できるための前提であり、安定性は信頼性をさらに高めるものだ。 次に期待値を簡単に説明する。先ほどのデータ思考の講座には、期待値でマーフィーの法則を説明する、よい応用例があった。 期待値とは、起こりうる結果を、確率を重みとして加重平均した値だ。期待値は確率分布だけで決まる。大数の法則により、回数が十分に多ければ想定した期待値へ近づく。この意味で期待値は事前の予測値だ。一方、通常いう平均値は事後の統計値であることに注意したい。英語でも、期待値は Mean、平均値は Average と、それぞれ表される。 ### **既存の可用性指標の計算方法** ソフトウェアの納品仕様にある SLA は、期待値の組だ。 業界で一般的な可用性の定義は、Availability = MTTF / (MTTF + MTTR)。 MTTF は Mean Time To Failure、平均故障時間だ。一度故障するまでに、システムが平均してどれだけ正常に動くかを指す。長いほど信頼性が高い。 MTTR は Mean Time To Repair、平均修復時間だ。修復可能なシステムで、障害発生から修復完了までの平均時間を指す。短いほど保守性が高い。 社内では可用性をさらに具体的に定義している。修復時間を詳しく定義し、障害による損失データを時間へ換算して計算する。 式は、Availability = ( 525600 - sum( min {1440 \* loss, ( t2 - t1 ) })) / 525600。 525600 は年間525600分、1440 は1日1440分を表す。loss は1日当たり注文数に対する損失割合だ。取引以外の事業なら、ページビューの損失や、増加した苦情件数を選んでもよい。t2-t1 は障害の継続時間を表す。 ### **X 指標の計算方法** 顧客への影響を、より正確に表せる指標を探している。まだよい名前を思いつかないので、ひとまず X 指標と呼ぶ。 顧客への影響の期待値を M（Mean）、影響が生じる確率を P（Probability）、影響の大きさを D（Degree）とすれば、M = P \* D となるはずだ。分かりやすく取引事業を例にする。この場合、P = 障害時間 / 年間時間、D = 損失注文数 / 年間注文数だ。 X 指標は、次のように計算できる。 ( 1 - sqrt ( (損失注文数 / 年間注文数) \* (障害時間 / 年間時間) ) \* 100% 本番環境でこの指標をどう運用するかは、さらに考えを練る必要がある。