稼働率のパーセンテージ表示はもうやめにしないか？
Can We Stop with the Uptime Percentages?
GitHubやCI、AI、Slackなど、日常的に使うサービスが次々とダウンし、ステータスページを見る機会が増えた。そこに並ぶ「99.9%」「99.99%」という数字は素人にはほぼ同じに見えるが、実際には10倍の差がある。インフラ関係者なら「ナインス」で直感できるが、今や利用者は全員だ。筆者は、パーセンテージではなく「過去30日間で12時間影響（稼働率98.31%）」のように時間で示すことを提案する。
99.9%と99.99%はほとんど同じに見えるが、後者は10倍も劣っているのだ！
HNでの議論
111- proxysna
より広い層のユーザーがステータスページを使い始めたのは、サービスの信頼性の低さが以前よりもずっと目立つようになったからであって、その逆ではない。bear blogやprotonmailでは問題が起きたことがないか、単に気づかなかっただけなので、ステータスページを使う必要は一度もなかった。
今ではgithub、circleci、MSのサービスなどのステータスページを_必ず_確認しなければならない。なぜビルドが通らないのか、なぜリポジトリを開けないのか、なぜ作業が滞っているのかを知る必要があるからだ。
パーセンテージは重要だ。githubのようなインターネットの重要な部分になると、なぜ重要かがずっと明白になる。そして、過去1ヶ月で12時間という数字は非常に疑わしい。MSはGHのパフォーマンス問題をかなり前から軽視してきたし、今それを信じ始める時ではないと思う。こうしたインフラを維持することは責任であり負担だ。
全体として、「100%に近い数字の非線形な重要性」には注意した方がいい。今年のghは90%台後半に達している話をしているし、インフラ関係者がよく思い知らされる数字に「1%は3.5日」というのがある。
ghの人々にとって状況は厳しいし、同情するが、彼らはスタートアップでもなければ、同情されるような弱者でもない。
- hdgvhicv
私は最悪でも3ナイン（99.9%）のシステムで何年も働いたことがあるが、5ナイン（99.999%）でも失敗とみなされるシステムで働いたこともある。
現代のテックが98%で十分だと言う態度は、旧来のテックの受容基準では通用しない。個々のコンポーネントは常に故障していた。先週も、電力障害と配電の配管ミスが重なって、支店への230msの停止があったばかりだ。
現代のソフトウェア関係者は230msを停止とはみなさない。彼らが電力業界で働いていないことを嬉しく思う。
（私たちの障害は、保証している99.1%のサービス、つまり最低SLAのものだけだった。その上には99.95%と99.999%がある。
（実際には最低レベルでも毎年5ナインを達成しているが、「データセンターに大型爆弾」のような重大な懸念があり、それによって重要度の低いユニットが年間5分をはるかに超えて停止する可能性がある。）
- teraflop
数字の提示の仕方とは別に、分散システムの文脈では「稼働率」を単一の数字として捉える概念自体が少し曖昧だ。異なるコンポーネントは、異なるユーザーに対して異なる可用性を持ちうるからだ。
また、月に45分の停止という形での0.1%のダウンタイムは、リクエストの0.1%が短いバーストで失敗するのとは全く異なる。ダウンタイムが「エラー率の増加」として報告されるのをよく見るが、それは曖昧すぎて無意味だ。
Googleの「windowed user-uptime」は、稼働率を単一の数字に凝縮しようとするのではなく、データの異なるビューを公開することで、これを少しうまく扱おうとしている：https://www.usenix.org/system/files/nsdi20-paper-hauer.pdf
- hx8
> 私たちはこんなふうに言う：
> GitHub Actions: 過去30日間で12時間影響（稼働率98.31%）。
これは、悪化する状況に可能な限り有利な光を当てようとしている。ほとんどの企業がダウンタイムで測定可能な収益の損失を被っているという事実を打ち消すものではない。他店で買い物をする顧客、配信されなかった広告、少し冷めたリード。GitHubが12時間ダウンすると、Microsoftが他の企業に外部化した数百万ドルの開発者生産性の損失が生じる。
ダウンタイムを「月にほんの数時間」とスピンしようとするべきではない。その時間は実際のドルを食う。
- runjake
私もパーセンテージにはあまり関心がない。しかし業界によっては、「2ナイン」と「5ナイン」の差が数百万ドルになることがある。だからこそ、顧客向けにそのように公表されるのだ。
- PaulKeeble
稼働率のパーセンテージをオンプレミスの稼働率と比較するとき、私が感じる見落とされている点の一つは、ダウンタイムがいつ発生するかだ。それが勤務時間の真ん中や買い物の繁忙期に起きると、はるかに影響が大きい。ブラックフライデーの真ん中やクリスマス前の時期にオフラインになる店は、日曜の夜や月曜の午前3時のダウンタイムよりもずっと大きな損害を受ける。
長い間気づいていることの一つは、これらAWS、Azureなどのダウンタイムの多くが、みんなの一日の真ん中に発生し、何百万人もの人が影響を受けるということだ。GitHubも同じで、仕事の邪魔になる。一方、自社の機器でサービスをホストしていたときは、ダウンタイムは通常メインの時間帯外だった。パーセンテージは多くの意味でダウンタイムの間違った尺度だ。なぜなら、時間はビジネスへの影響において等しくないからだ。
- procflora
こうしたサービスステータスページには他にも多くの問題があり、この記事の主張にはあまり興奮できない。サービスのユーザーとして、稼働率が0.09%追加されるのが0.9%追加されるよりも難しいかどうかなど、時間の割合で説明されても気にしない。気になるのは二つだけだ：今のサービスステータスはどうなのか、そして長期的にあなたのサービスの信頼性が私に与える影響（30日とかいうのはやめてくれ）。
電力業界では、サービスの信頼性を追跡するためにIEEE標準化された指標（適切にIEEE風の頭字語付き）がいくつかあり、私はそちらの方がずっと好きで、ステータスページを見るたびにいつも欲しいと思う。もちろん絵に描いた餅で、規制当局にやれと言われなければ誰もこんな分析をして結果を公表したくないだろうが、それが人生だ。
SAIDI - System Average Interruption Duration Index。平均的な顧客が一年間に経験したサービス中断の分数。個人的には、あなたのサービスステータスページで一番見たいのはこれだ。電力網では、5分を超える停電は中断（「非瞬時停電」）とみなす。
SAIFI - System Average Interruption Frequency Index。平均的な顧客が一年間に経験した中断期間の総数。
CAIDI - Customer Average Interruption Duration Index。中断があったとき、平均的な顧客のサービスが復旧するまでの時間。
米国の場合、これらの数字はこんな感じだ[…]
- jakevoytko
これらの数字は、自分の制御外で仕事が妨げられる可能性がどのくらいあるかの有用な代理指標だ。
4ナインのサービスに対して1日100回何かをするなら、すべてが成功すると合理的に期待できる。
2ナインのサービスに対して1日10,000回何かをするなら、その日のうちにかなりの数のエラーに遭遇するか、仕事が全くできない長い期間が生じることさえ期待できる。
人々がGitHubに不満を感じるのは、GitHubの稼働率が98%だからとか、その具体的な数字のせいではない。仕事の能力を定期的に妨げるからだ。98%という数字は、それを簡潔に言い表したにすぎない。