以下では、運用中のデータ32万8348台のHDDについて、2025年第3四半期内の故障率と生涯故障率について順に示した。まずは第3四半期内の故障率だ（図3）＊。

ごく短期間しか運用していないHDDや、台数が少ないモデルは統計的に意味がないため、2025年第3四半期の総稼働日数が1万日以下だったり、台数が100台未満だったりしたものを除いたモデルの故障率を図3に示した。4つのブランド別に31モデルが示されている。HDDの容量は4T～24TBだ。

図3　HDDのモデル別の故障率　項目は左からMFG：メーカー名（ブランド名）、Model：モデル名、Size：容量、Drive count：台数、Avg.age（months）：平均稼働月数、Drive days：総稼働日数、Failures：故障件数、AFR：2025年第3四半期の年間平均故障率（提供：Backblaze）

　図3から分かることは4つある。第一に故障率が上昇したことだ。前四半期のAFRは1.36％だったが、今期は1.55％であり、0.19ポイント上昇した。

　第二に初めて24TBのHDDがデータに加わった。Toshiba「MG11ACA24TE」だ。ただし、台数が2400台で総稼働日数が2万4148日だったので、図3には掲載できたものの、次に示す生涯故障率を示す基準には達していない。

　第三は全く故障しなかったHDDが4モデルあったことだ。4番目のモデル今紹介した新規のHDDだ。

・Seagate「HMS5C4040BLE640」（4TB）
・Seagate「ST8000NM000A」（8TB）
・Toshiba「MG09ACA16TE」（16TB）
・Toshiba「MG11ACA24TE」（24TB）

　2番目のSeagate「ST8000NM000A」（8TB）はBackblazeの統計レポートで何度も故障ゼロとして取り上げられた優秀なモデルだ。最後に故障が起きたのは2024年第3四半期で、それも1回だけだった。

　第四は故障の「ピーク値」がこれまでになく高かったことだ。このため、Backblazeは記事の後半に示したように四分位範囲（テューキー法）を用いた外れ値分析をした。この情報に基づき、四半期のAFRが5.88％を超えるモデルを外れ値とみなした。該当したのは3モデルだ。容量の次の数字がAFRだ。

・Seagate「ST10000NM0086」（10TB、7.97％）
・Seagate「ST14000NM0138」（14TB、6.86％）
・Toshiba「MG08ACA16TEY」（16TB、16.95％）

生涯故障率はどうだったのか

　Backblazeは四半期ごとの故障率に加えて、生涯故障率も計算した。対象になったのは台数や稼働日数の条件＊を満たす27モデルの40万2675台だ（図4）。

＊2025年第2四半期末時点で台数が500台以上あり、生涯の総稼働日数が10万日以上のモデルが対象になった。

図4　HDDのモデル別の故障率　項目は左からMFG：メーカー名（ブランド名）、Model：モデル名、Size：容量、Drive count：台数、Avg.age（months）：平均稼働月数、Drive days：総稼働日数、Failures：故障件数、AFR：生涯故障率（提供：Backblaze）

　図4から分かることは3つある。第一に生涯AFRが非常に安定していたことだ。今回は1.31％だったが、前期は1.30％、その前の期は1.31％だったからだ。

　第二に約40万台の中でも最も導入時期が早かった4TBモデルの影響だ。Backblazeは4TBモデルの運用を徐々に終了している。データセンターに残っている台数は「ALEモデル」が11台、B「LEモデル」が187台のみと少ない。しかし、生涯を通じた母数が比較的大きかったため、稼働日数が追加されていっても平均稼働月数はほとんど増えない。

　第三に大容量HDDが着実に増えてきたことだ。 図4の掲載基準を満たす20TB以上のモデルは、前期から7936台増えた。先ほど紹介したように、この数にはToshiba「MG11ACA24TE」（24TB）は入っていない。Toshibaモデルを加えると、20TB以上のHDDは6万7939台もあり、全体の約21％を占める。

そもそもHDDが故障するとはどういう意味なのか

　Backblazeの調査によればHDDの故障は一般的な工業製品とは異なるようだ。初期には故障しにくく、寿命の末期で急に壊れる。

　Backblazeによると、「故障をどのように定義しているのか」と問われることがあるという。故障したかどうかは直感的に分かりそうだが、実はこれは難問なのだという。この質問に答えるには、データセンター内部のドライブフリート監視ツール（SMART統計を利用）や同社のHDD情報収集ツール（Drive Stats collection program）、データエンジニアリング層の運用管理が関係するという。

SMART統計からは何が分かるのか

　故障の定義についての質問に答えるため、まずはSMART統計のレポートについて紹介しよう。

　Backblazeは「smartmontools」（https://www.smartmontools.org/）を使ってHDDのSMART情報を収集している。さらに「drive sentinel」と呼ばれる別の監視ツールを使用して、特定のしきい値を超える読み出し・書き込みエラーやその他の異常をフラグ付けしている。

　あるHDDを交換すべきかどうかを決定する主な指標は、HDDが読み出しに対して「回復不可能なメディアエラー」（uncorrectable medium errors）を返したときだという。HDDが内部のディスクからデータを読み出す際、データの整合性チェックに失敗することがある。そのときHDDは内部のエラー訂正コードを使ってデータの再構築を試みる。再構築ができなかった場合、HDDはホストに対して回復不可能なメディアエラーとして報告して、読み出せなかった部分を「保留中の代替処理」（pending reallocation）としてマークする。これはSMARTにおいて「Current_Pending_Sector」のような属性で表示される。

　SATA接続でHDDを制御する専用のサーバケース（ストレージポッド）では、drive sentinelがHDDから報告された回復不可能なエラーの数をカウントする。カウント数がしきい値を超えたとき、そのHDDへのアクセスは遮断される。旧型のストレージポッドでは、5台のHDDが単一のSATAリンクを共有していたため、1台のHDDがしきい値に達すると、5台とも影響を受けていた。

　SASトポロジーを使ってHDDを接続するDell TechnologiesやSuper Micro Computerのポッドでは、エラーの報告方法が異なるため、drive sentinelはHDDへのアクセスを遮断しない。しかし、そもそもSASは問題のあるHDDが他に与える影響を最小限に抑えるため、それほど課題にはならない。

Drive Statsプログラムからは何が分かるのか

　Backblazeは図2や図3のデータを収集する目的でカスタムプログラムを使っている。このプログラムはどのように動いているのだろうか。

　このプログラムのロジック＊は比較的単純だ。図2や図3に示したようなDrive Statsにおける「故障」は、HDDがレポート対象の集団から消えたときに発生したと見なされる。そのHDDは再び正常に動作するまで「故障」として扱われる。各HDDはシリアル番号を使って追跡されており、日次ログを報告しているため、かなり詳細な追跡が可能だ。

＊このC++プログラムはpodstatsジェネレーターと呼ばれている。各ストレージポッドにはBackblazeの顧客のデータが保持されており、podstatsジェネレーターは各ストレージポッドに対して数分ごとに実行される。SMART統計の他、幾つかの他の属性を収集して、.xmlファイルに変換する。.xmlファイルは各データセンターの中央ホストにプッシュされる。最後に中央ホストからDrive Statsに送られる。

データエンジニアリング層は何をしているのか

　SMART統計などの情報はこうして一つにまとめられる。だが、これは単なるデータだ。データインテリジェンスを適用して文脈を加える必要がある。あるHDDが1日程度オフラインになることはよくある。これはSMART統計の日次ログを収集するツールにHDDが応答しないことなどを意味するが、単にケーブルが緩んでいるといった単純な理由かもしれない。では、そのようなHDDが1日後、あるいは30日後にツールに応答した場合、その期間のどの時点で故障したと分類されるのだろうか。

　結論を言えば選択期間（今回は2025年第3四半期）の最終日にデータをあるHDDのデータが記録されている場合、そのHDDは故障していないと見なす。

　なお、Backblazeは以前、データセンターの作業チケットを手動で相互参照していた。現在はそのプロセスをSQLで自動化している。SQLの内容を分かりやすく説明すると次のようになる。

・（1）クエリが相互参照する3つの「人間が管理するテーブル」がある。HDDのシリアル番号がどれかのテーブルに現れた場合、そのテーブルの機能に応じて故障か否かが分かる
・（2）見つかったシリアル番号が、HDD交換の作業依頼書（Jiraチケット）における「主要シリアル番号」だった場合、そのHDDは故障している
・（3）HDDのシリアル番号が、クローン作成用のJiraチケット、または（一時的な）交換チケットの「ターゲットシリアル番号」だった場合、そのHDD故障していない

　Backblazeが各四半期の末に「Drive Statsレポート」を作成する際、HDDが各種作業トラッカーのいずれかに現れたか、あるいは集団に再登録されていなければ、それは「故障」と見なされる。

　まれなケースとして、四半期の収集期間よりも長く続く作業を継続している場合に、いわゆる「見せかけ」の故障が起こることがある。今回故障率が16.9％と高かったToshibaのHDDの外れ値だ。これについては文脈を説明した後に説明する。

古いHDDが故障しやすいのか

　記事の前半で触れたように、HDDプール内の一部のHDDでAFRが大きく悪化したため、四分位範囲を用いた外れ値分析を実行した。その分析に基づいて、故障率が5.88％を超えるものは全て外れ値とした。

　狙いはHDDの稼働月数と今四半期のAFRとの関係を可視化することだ。

図5　HDDの稼働月数と今四半期のAFRの関係　稼働月数をX軸に、AFRをY軸に取った。モデル名は横向きに記されている（提供：Backblaze）

　図5は読みにくい散布図かもしれないので、ラベルを取り除いたものも示す（図6）。

図6　HDDの稼働月数と今四半期のAFRの関係（提供：Backblaze）

　Backblazeの関心事は、関係性の「形」だ。もし「HDDは古くなるほど故障率が高くなる」と仮定するなら、図の右上の象限（稼働月数が多いほどAFRが高くなる）に集中するはずだ。しかし、図6のデータはそれよりもはるかに興味深いパターンをたどっている。稼働月数に関係なく、ほとんどのデータポイントがグラフの最も低い領域（X軸近く）に集中している。だが、そのパターンに従わないデータポイントが幾つかある。

　ビジネスインテリジェンス（BI）の文脈では、外れ値を特定するプロセスもまた、アクションにつながるデータだ。「All press is good press」（悪名は無名に勝る）と言うように、HDDを分析する際、データは多ければ多いほど良いという。

　外れ値は3つあった。

・Seagate「ST10000NM0086」（10TB、7.97％）
・Seagate「ST14000NM0138」（14TB、6.86％）
・Toshiba「MG08ACA16TEY」（16TB、16.95％）

Seagate「ST10000NM0086」（10TB）

　このHDDの故障率が高いことには分かりやすい説明がつく。まず、7年以上（92.35カ月）経過していることだ。稼働中のモデルがわずか1018台しかないため、1回の故障が全体の重みに大きく影響する。モデルごとの平均のHDDの数は、今四半期のデータでは平均値で1万952台、中央値で6177台だ。

　これは過去1年間のデータの傾向にも表れている（図7）。

図7　Seagate「ST10000NM0086」の四半期ごとのAFR（提供：Backblaze）

Seagate「ST14000NM0138」（14TB）

　このHDDの稼働月数は5年（56.57カ月）に近づいており、やはりHDDの数が1286台と、比較的少ない。さらに重要なのは、このモデルは過去1年間で高い故障率を示してきた（図8）。

図8　Seagate「ST14000NM0138」の四半期ごとのAFR（提供：Backblaze）

Toshiba「MG08ACA16TEY」（16TB）

　Toshibaのモデルは興味深い傾向を示した。稼働月数は4年未満（44.61カ月）で、HDDプール内に5145台ある。そして、今四半期に突然AFRがひどく悪化した。

図9　Toshiba「MG08ACA16TEY」の四半期ごとのAFR（提供：Backblaze）

　これは何が原因なのだろうか。Backblazeの担当者にとっては意外ではなかったという。同社は東芝と協力してこのモデルのパフォーマンスを最適化するために、東芝が提供したファームウェアアップデートを適用した。作業の際に一部のHDDをポッドから抜き出す必要があったため、故障と判定されてしまったのだ。このモデルが実際に故障したわけではない。