本記事は学習用です。作成には ChatGPT と GitHub Copilot を使用しています。
1. 信頼性設計が必要になる場面と「信頼性」の位置づけ
信頼性設計は、故障や停止を「ゼロにする」活動ではなく、許容できる失敗を定義し、その範囲内でサービスや製品を継続提供できるように設計・検証・運用を一貫させる活動です。特に次の条件では重要度が上がります。
- 停止が直接損失になる（EC、決済、基幹、24時間365日運用）
- 故障が安全・法規・補償に直結する（車載、医療、電力、航空）
- 構成が複雑（分散システム、マイクロサービス、冗長構成）
- 現場交換・修理が難しい（遠隔地、無人、宇宙、海中）
ここでいう 総合信頼性（Dependability） は、IECの用語体系では「要求されるときに要求される機能を果たす能力」として整理されています。 (IEC)
また、ITシステム開発では、信頼性・可用性・運用性などを非機能要求として明確化し、関係者間の期待値を揃えることが重要になります。IPAの「非機能要求グレード」は、この合意形成を支援するために項目と段階を整理しています。 (IPA)
※安全要求や法規（機能安全、医療規制など）が絡む場合は、ここで述べる一般的手法だけで判断しないほうがよく、規格・規制の確認が必要になります。
2. 信頼性要求を仕様に落とす：SLOと「停止してよい時間」を数値で決める
信頼性設計の失敗要因で多いのは、「高信頼にしたい」という抽象要求のまま設計・テストに入ることです。要求は次の順序で具体化します。
2.1 要求を「ユーザ影響」に翻訳する
- 例：注文確定APIが失敗すると売上が失われる
- 例：監視が止まると復旧が遅れ、二次障害が増える
- 例：計画停止（メンテ停止）が許されるかで設計が変わる（冗長切替、無停止リリース、バックアップ手順）
IPA資料でも、運用時間や計画停止の有無が可用性レベルの検討要素になり、運用コストにも影響すると説明しています。
2.2 SLI / SLO / SLA を定義する（ソフトウェア・サービス向け）
- SLI（Service Level Indicator）：測定指標（成功率、レイテンシ、エラー率など）
- SLO（Service Level Objective）：目標（例：月間成功率 99.9%）
- SLA（Service Level Agreement）：契約（違反時のペナルティ等）
SLOを決めると「停止してよい時間（エラーバジェット）」が計算できます。Googleの解説では、30日（43,200分）で99.9%なら停止許容は 43.2分になります。 (Google Cloud)
2.3 要求を「設計可能な条件」に分解する
要求は1行で終わらせず、設計判断につながる粒度に分解します。
| 分解軸 | 例（要求として書く） |
|---|---|
| 対象機能 | 注文確定、決済、検索、監視など |
| 影響範囲 | 全停止／部分停止／性能劣化 |
| 許容停止 | 月43分まで（=99.9%） |
| 復旧目標 | P1は15分以内に暫定復旧、60分以内に恒久対応 |
| データ要件 | RPO/RTO、整合性、再実行可能性 |
| 運用制約 | 計画停止可否、夜間作業可否、要員体制 |
※RPO/RTOやBCP要件は業種・契約で大きく変わるため、業務側・運用側との合意が必要です。
3. 信頼性指標を正しく選ぶ・計算する：MTBF/MTTRだけでは不足する
信頼性指標は「作った後に測る」だけでなく、「設計時にトレードオフを判断する」ためにも使います。指標は大きく 時間系 と 確率系 に分かれます。
3.1 時間系指標：MTBF / MTTR / 可用性（Availability）
- MTBF（Mean Time Between Failures：平均故障間隔）
- MTTR（Mean Time To Repair：平均修復時間）
- 可用性（Availability）：稼働している割合（時間基準や要求成功率基準など複数の定義がある）
実務では、簡易モデルとして次を使うことが多いです。
$$
A \approx \frac{MTBF}{MTBF + MTTR}
$$
ただし、MTBFの定義や算出は業界差が出やすいです。例として、MTBFはJIS/IEC由来の用語体系の一部ですが、分野によっては「現場で使うMTBF」と規格上の定義に乖離が生じる可能性がある、という注意が示されています。 (福田工業株式会社)
計算例（設備/システムの概算）
- MTBF = 500時間、MTTR = 2時間
$$
A = \frac{500}{500 + 2} \approx 0.9960 \; (99.60\%)
$$
この値は「月間で99.6%相当」を直接意味しません（分布、保全、負荷、冗長構成などで変わります）。一方で、設計案の比較には有効です。
3.2 故障率・FIT・MTTF：部品・ハード寄りの指標
- 故障率 ($\lambda$)：単位時間あたりの故障発生率
- FIT（Failure In Time）：$10^{9}$時間あたりの故障数で表す単位
- 例：1 FITは「デバイス時間（個数×時間）の合計が10億時間あたり、1個故障」の意味とTIが説明しています。 (TI.com)
- 国内メーカのFAQでも、FITが$10^{9}$時間基準の単位であり、MTTFがFITの逆数になる旨を説明しています。 (nisshinbo-microdevices.co.jp)
- MTTF（Mean Time To Failure）：修理しない（できない）品目の平均故障時間
指数分布（故障率一定）を仮定すると、信頼度関数（生存確率）は次のようになります。
$$
R(t) = e^{-\lambda t}
$$
計算例（FITから1年信頼度の概算）
- FIT = 100 → $\lambda = 100/10^{9}$ [$1/\mathrm{hour}$]
- 1年 = 8760時間
$$
R(8760)=e^{-(100/10^9)\cdot 8760} \approx e^{-0.000876} \approx 0.99912
$$
※指数分布は「偶発故障（ランダム故障）」の近似であり、摩耗故障や初期故障を含む寿命データにそのまま当てると誤差が大きくなります。
3.3 分布モデル：ワイブル分布で初期故障・摩耗故障を扱う
寿命データは指数分布で説明できないケースが多いです。ワイブル分布は形状パラメータによって故障率が時間とともに増減するため、実務でも広く使われます。J-STAGE掲載の解説でも、劣化現象や寿命がワイブル分布でよく一致する背景や、不信頼度関数 $F(t)$ の形が示されています。 (J-STAGE)
代表的な形（位置パラメータを省略した単純形）を示します。
$$
F(t)=1-\exp\left(-\left(\frac{t}{\eta}\right)^m\right)
$$
- $m<1$：初期故障が優勢（時間とともに故障率が下がります）
- $m\approx1$：偶発故障（指数分布に近くなります）
- $m>1$：摩耗故障（時間とともに故障率が上がります）
3.4 ソフトウェア運用で効く指標：MTTD/MTTR・エラーバジェット
サービス運用では「壊れない」よりも「壊れても早く戻す」が支配的になりやすいです。次が代表的です。
- MTTD（Mean Time To Detect）：検知までの平均時間
- MTTR（復旧）：復旧までの平均時間（Repair/Recoverの意味差が出やすいため、組織内で用語定義を固定しておくと整理しやすくなります）
- エラーバジェット：$1 - SLO$（一定期間に許容する失敗量）
Googleの資料では「エラーバジェットはSLOの1マイナス」と明示し、信頼性とリリース速度のバランスに使うと説明しています。 (sre.google)
※MTTRは「Repair」「Recover」などでニュアンスが揺れやすいため、組織内で用語定義を固定しておくと運用しやすくなります。
4. 信頼性を作り込む設計パターン：冗長化だけに頼らない
信頼性向上の打ち手は多いですが、効果が出やすい順に挙げると概ね次のようになります。
- 単一障害点（SPOF）の除去
- 故障の局所化（影響範囲の縮小）
- 復旧の高速化（MTTD/MTTRの短縮）
- 故障確率の低減（部品選定、余裕設計、負荷低減）
4.1 冗長化：直列・並列の考え方を誤らない
最小構成の「直列」は弱くなりがちです。並列冗長は強くなりやすい一方で、切替機構や共通原因故障（同一バグ、同一電源系統、同一AZ障害など）によって崩れることがあります。
- 直列（両方動作が必要）
$$
R_{series}=R_1 \cdot R_2
$$ - 並列（どちらか生きていればよい）
$$
R_{parallel}=1-(1-R_1)(1-R_2)
$$
例：部品信頼度が各0.99のとき
- 直列：0.9801
- 並列（二重化）：0.9999
この差は大きいですが、「同じ設計・同じ環境」に置いた二重化は共通原因で同時に落ちる可能性があります。実務では次をセットで考えます。
- 電源系統の分離、ゾーン分離、依存関係の分離
- ソフトウェアのバージョン分散（同時デプロイを避ける）
- フェイルオーバー試験の定期実施（「切替できるはず」の未検証を避けます）
4.2 フェイルセーフ／フェイルソフト／グレースフルデグレード
- フェイルセーフ：故障時に安全側へ倒す考え方です（例：危険動作を止めます）
- フェイルソフト：機能を落としてでも動作を継続する考え方です（例：高負荷時に推奨機能を停止します）
- グレースフルデグレード：段階的に品質を落として全停止を避ける考え方です
これらは、単なる冗長化よりも「影響範囲の局所化」に効果があります。特にソフトウェアでは、設計で「落とす機能」を決めておくと停止時間の上限を守りやすくなります。
4.3 余裕設計（デレーティング）と環境ストレス
ハードウェア寄りでは、温度・電圧・振動などのストレスを減らす設計が効果的です。寿命試験では温度加速（アレニウスモデル）を使うことがあり、国内メーカのFAQでも温度加速率の算出式（アレニウス）に触れています。 (nisshinbo-microdevices.co.jp)
また、電子部品の評価では温度急変や温度サイクルなどの試験が規格化されており、JEITAのガイドで関連規格（JEITA ED-4701など）を含め整理しています。 (JEITA)
※加速試験条件や合否判定は製品分野・契約で変わります。
5. 解析と検証：FMEA/FTA/RBD・加速試験・信頼性成長をつなぐ
信頼性設計は「気合い」ではなく、解析→対策→検証の循環で精度が上がります。
5.1 FMEA：ボトムアップで「起き得る故障」を洗い出す
FMEA（Failure Mode and Effects Analysis：故障モード影響解析） は、設計段階で故障モードを列挙し、影響と対策を整理する手法です。 (コアコンセプト・テクノロジー（CCT）)
最低限、次の列を持つと運用しやすい。
| 項目 | 例 |
|---|---|
| 対象 | 決済API、DB、電源、ファン |
| 故障モード | タイムアウト、過負荷、断線 |
| 影響 | 注文失敗、データ欠損、停止 |
| 検知 | 監視アラート、自己診断 |
| 対策 | リトライ、遮断、冗長化 |
| 残余リスク | 監視漏れ、共通原因 |
※FMEAのスコアリング（Severity/Occurrence/Detection、RPNなど）は流派があります。数値化は便利ですが、スコアが目的化しやすい点に注意が必要です。判断基準は組織で固定しておくと運用しやすくなります。
5.2 FTA：トップダウンで「最悪事象」の原因を切る
FTA（Fault Tree Analysis：故障の木解析） は、特定の重大事象を頂上事象として、論理展開で原因を追う手法です。JSPMIの解説でも、FTAが故障・事故原因分析に使われ、信頼性・安全性を高める目的で利用されると説明しています。 (jspmi.or.jp)
FTAは「絶対に起こしてはならない事象」（例：誤課金、誤制御、重大停止）に対して有効で、FMEAと補完関係になります（ボトムアップとトップダウン）。
5.3 RBD（Reliability Block Diagram）で概算する（設計比較に使う）
RBDは、システムを直列・並列ブロックで表し、構成差の効果を概算するのに向いています。詳細な確率モデル（マルコフなど）に入る前の、設計比較の「第一手」として使えます。
図（例：二重化＋単一DBのSPOF）
この図は、Appを冗長化してもDBが単一であれば全体がDBに支配されやすいことを示します。ここから「DB冗長化」「読み取り分離」「シャーディング」「マネージドDBのAZ冗長」などの選択肢が整理できます。
5.4 検証：机上計算と実測を接続する
- ハード：寿命試験、環境試験、温度サイクル、加速試験
- ソフト：負荷試験、故障注入（カオス実験）、フェイルオーバー試験
- 共通：ログ・メトリクスで「設計した挙動」を確認する
ワイブル解析や加速試験は統計前提が強いです。データ打ち切り・サンプル数不足・使用条件不一致などがあると結論が崩れやすいため、レビュー体制を置くと安心です。
6. 運用で信頼性を維持する：監視・復旧・変更管理を指標で回す
信頼性はリリース後に劣化しやすいです。運用では「壊れにくさ」よりも「壊れ方の制御」と「戻しやすさ」が効きやすくなります。
6.1 エラーバジェットで「攻め」と「守り」を数値で調停する
SLOを決めると、一定期間に許容する失敗量（エラーバジェット）が決まります。Googleの資料では、エラーバジェットが SLOの1マイナスであり、使い切っていない限り（原則）変更を進められる、という考え方を示しています。 (sre.google)
運用ルール例：
- 予算消費が閾値（例：月の50%）を超えた場合は、変更凍結や改善の優先度引き上げを検討します
- 予算に余裕がある場合は、リリース頻度を上げやすくなります
- 予算超過が続く場合は、SLO自体が過剰か、設計が不足しているかを見直します
6.2 MTTD/MTTR短縮の定石（ソフトウェア中心）
- 監視：ユーザ影響に直結するSLI（成功率、遅延、キュー滞留）を中心にします
- アラート：ページングは「今すぐ人が起きる価値」がある条件に絞ります
- 復旧手順：ワンコマンドロールバック、Feature Flagで切り離します
- 事後分析：再発防止は「作業」ではなく「設計変更」まで落とし込みます
6.3 MTBF/故障率を上げるより、まず「影響半径」を小さくする
分散システムでは、個々の部品は必ず壊れます。したがって次を優先します。
- 依存先のタイムアウトとリトライ設計（過剰リトライで雪崩を起こさない）
- サーキットブレーカー、バックプレッシャー
- リソース分離（スレッド/プロセス/ノード/ゾーン）
- データ整合性の設計（冪等性、再試行可能性）
6.4 よくある誤り（設計レビューで減らす）
- MTBFが高い＝止まらない、と思い込みやすいです（復旧時間が長いと可用性は上がりません）
- 二重化したのに切替試験をしないままになりやすいです（「切替できるはず」は動かないことがあります）
- 指標が多すぎて運用判断に使いにくくなります（意思決定に直結する指標に絞ります）
- SLO未定のまま「99.99%を目指す」と言いがちです（費用対効果が破綻しやすくなります）
- 規格・法規が必要な製品で、一般論だけで試験条件を決めてしまいがちです
A. 参考サイト
- IPA：非機能要求グレード (IPA)
- Google Cloud Blog：可用性とエラーバジェットの考え方 (Google Cloud)
- Google SRE：The Calculus of Service Availability（PDF） (sre.google)
- JEITA：電子部品の信頼性評価ガイド（PDF） (JEITA)
- TI（Texas Instruments）：FIT（平均故障率）の定義と換算式 (TI.com)
B. 関連書籍
コメント