FRACAS - yuuk1's Digital Garden

# FRACAS ## 定義 FRACAS(Failure Reporting, Analysis and Corrective Action System)とは、故障報告・解析・是正処置を一体化し、開発試験・生産・運用で見つかった故障を再発防止へ接続する閉ループである。[[wiki/entities/Practical Reliability Engineering|Practical Reliability Engineering]] は、開発試験で起きたすべての故障を報告・調査し、初回の故障モードを「対象外」や「偶発」として捨てないことを強調する(Source: [[wiki/entities/Practical Reliability Engineering|Practical Reliability Engineering]] ch.12 §12.6, Appendix 5)。 ## 必須データ本書が挙げる故障報告項目は、故障症状と影響、即時修理、故障時の運転時間、運転条件、日時、故障分類、故障部品調査と再分類、推奨是正処置、是正処置フォローアップである(Source: [[wiki/entities/Practical Reliability Engineering|Practical Reliability Engineering]] ch.12 §12.6)。 Appendix 5 では、FRACAS から故障一覧、上位故障モードのパレート分析、MTBF、傾向分析、確率/ハザードプロットを出すことを想定する。パレート分析は重要項目リストの基礎になり、ランタイムが取得しにくい場合はカレンダー時間での分析も許容される(Source: [[wiki/entities/Practical Reliability Engineering|Practical Reliability Engineering]] Appendix 5)。 ## 初回故障を捨てないことの根拠第12章は、初回の故障モードを「無関係」「実運用では起こりにくい」として分類したい誘惑がスケジュールの厳しい状況で生じることを認めたうえで、それでもあらゆる故障モードの初回発生を調査・是正すべき問題として扱うほうが長期的には時間とコストを節約できると述べる。この主張の根拠として、**実運用の信頼性に影響する故障モードは、是正処置が取られなかった開発試験中のインシデントまで遡れることが多い**という経験則が明示される。すなわち、FRACAS が閉ループとして機能しない(初回故障が是正処置に結びつかない)こと自体が、後の運用故障の温床になるという因果を本書は主張している(Source: [[@2012__Wiley__Practical Reliability Engineering - Chapter 12 Reliability Testing]] §12.6.1)。 ## 故障審査委員会(failure review board) FRACAS の運用主体として、故障の評価・是正処置の指示と監視・信頼性成長の監視を担う故障審査委員会の設置が求められる。構成メンバーはプロジェクト信頼性エンジニア・設計者に加え、品質エンジニアや生産・試験エンジニアなど解決に貢献できる要員である。委員会は「責任追及の場」や故障報告を「偶発・対処不要」に押し込める場ではなく、チームとして問題解決にあたるべきだとされ、委員会内で判断できない場合(追加リソースが必要な場合等)は速やかにプロジェクトマネジメントへ報告することが求められる。米国 MIL-HDBK-781 が故障報告方法の参考として、MIL-STD-781 が一貫した報告システムの基礎として挙げられる(Source: [[@2012__Wiley__Practical Reliability Engineering - Chapter 12 Reliability Testing]] §12.6.1)。 ## 是正処置の実効性と再試験是正処置を行った際は、その処置が有効であることを確認するために、故障を発生させた試験を再度実施することが重要だと強調される。是正処置は常に有効とは限らず、(1) 問題を系列内の次に弱い部品へ転嫁してしまう場合、(2) 真の根本原因が当初の解析より複雑な場合、の2パターンが失敗例として挙げられる。したがって原因の理解が十分で是正処置の効果に完全な確信がない限り、100% の有効性を仮定すべきではないとされる。FRACAS の閉ループは「是正処置を実施した」ことでは完結せず、「再試験で効果を確認した」ことをもって初めて閉じると読める(Source: [[@2012__Wiley__Practical Reliability Engineering - Chapter 12 Reliability Testing]] §12.6.2)。 ## 横断的知見 - **FRACAS は SRE のインシデント管理とポストモーテムの製品信頼性版である**: FRACAS は故障を報告し、調査し、是正処置を追跡する。SRE のインシデント管理/ポストモーテムは、運用障害を記録し、根本原因を分析し、再発防止アクションを追跡する。両者は「失敗をデータ化し、是正処置の効果まで閉じる」点で同型だが、FRACAS は部品・試験・保証データまで含む製品ライフサイクル志向が強い。(Source: [[wiki/entities/Practical Reliability Engineering|Practical Reliability Engineering]], [[SRE]], [[インシデント管理]]) - **第12章の開発段階FRACASと第15章の生産段階FRACAS(§15.8)は同一原則の異なる局面への適用であり、生産段階特有の運用上の緊急性が加わる**: 第15章§15.8は「FRACASの原則(§12.6)は生産故障にも等しく適用できる」と明言したうえで、開発段階の記述にはない生産固有の運用要件を追加する。具体的には、(1) 傾向分析を日次・週次で行う必要があること(生産問題は急速に顕在化するため)、(2) 不良部品を即座に廃棄せず1〜2か月程度保管し詳細調査に備えること、(3) データ解析をデータ管理担当者だけに任せず、生産・監督者・QC技術者・試験オペレータが解釈に参加すべきこと(品質サークルのアプローチが有効)、(4) 生産不良は工程品質コストだけでなく、出荷後の実運用信頼性への影響という観点からも分析すべきこと、である。第12章の故障審査委員会(failure review board)が開発段階の閉ループ運用主体であるのに対し、第15章はこれと同じ閉ループ原則(初回故障を捨てない、是正処置を追跡する)を、生産のスループットに合わせた速い分析サイクルへ適応させたものと読める。(Source: [[@2012__Wiley__Practical Reliability Engineering - Chapter 12 Reliability Testing]] §12.6.1, [[@2012__Wiley__Practical Reliability Engineering - Chapter 15 Reliability in Manufacture]] §15.8) - **本文が求める「記録の詳細さ」と、様式(Appendix 5)が実際に集計へ使う「キーの粒度」は一致しない**: 第12章§12.6が求める故障報告の項目は、故障症状と影響・即時修理・故障時の運転時間・運転条件・日時・故障分類・故障部品調査と再分類・推奨是正処置・是正処置フォローアップという、単一インシデントを詳細に記述する粒度である。ところが Appendix 5 の ANALYSES 節が示す故障一覧の出力ヘッダは Failure Report No. / System / Sub-system / Assembly / Part という識別子・階層キーのみで、症状・原因・是正処置そのものはこの出力仕様には現れない。両者は矛盾ではなく、個々のレポートが保持すべき詳細フィールド(§12.6)と、それらを横断集計するための最小限の検索キー(Appendix 5)とが、本書内で別の節に分離して定義されていると読める。(Source: [[@2012__Wiley__Practical Reliability Engineering - Chapter 12 Reliability Testing]] §12.6, [[@2012__Wiley__Practical Reliability Engineering - Appendix 5 Failure Reporting, Analysis and Corrective Action System (FRACAS)]]) - **Appendix 5 Note 1 は、第12章が抽象的に述べる「故障審査委員会による優先順位づけ」に具体的な分析手法と成果物を与えている**: 第12章§12.6.1は故障審査委員会が是正処置の指示・監視を担うと述べるにとどまるが、Appendix 5 Note 1 は「パレート分析が重要項目リスト(Section 7.4.7)の基礎となる」と明記し、どの分析からどの成果物へ接続するかを様式レベルで具体化している。すなわち委員会の意思決定プロセスという抽象的な運用原則が、様式の設計(どの出力を作るか)によって初めて実行可能な手続きになっている。(Source: [[@2012__Wiley__Practical Reliability Engineering - Chapter 12 Reliability Testing]] §12.6.1, [[@2012__Wiley__Practical Reliability Engineering - Appendix 5 Failure Reporting, Analysis and Corrective Action System (FRACAS)]]) - **信頼性成長(第14章)は、FRACASが閉ループとして機能することを暗黙の前提とする測定モデルである**: 第14章はDuane法(§14.13.1)が「複数の故障モードが漸進的に是正される母集団」に対してのみ適用可能であり、早期開発試験のように是正処置が追いついていない段階では当てはまりにくいと述べる。さらに§14.14.1(TAAF)は、本ページが第12章から既に得ている運用原則(初回故障を「無関係」「偶発」として捨てない)を独立に繰り返し、「実運用機に発生しえないと結論的に立証されない限り、いかなる故障モードもrandomやnon-relevantとして棄却してはならない」と明言する。すなわちDuaneの成長曲線という**測定モデル**が前提とする「是正処置が継続的に効いている」という状態は、FRACASという**運用の仕組み**が閉ループで機能して初めて成立する。第12章はFRACASの運用手続きを、第14章はその手続きが機能しなかった場合に何が壊れるか(成長曲線がDuaneモデルに当てはまらなくなる)を示しており、両者は同じ主張を運用と測定の両面から支えている。信頼性成長プログラムの詳細は [[信頼性成長]] を参照。(Source: [[@2012__Wiley__Practical Reliability Engineering - Chapter 12 Reliability Testing]] §12.6.1, [[@2012__Wiley__Practical Reliability Engineering - Chapter 14 Reliability Demonstration and Growth]] §14.13.1, §14.14.1) - **第17章は FRACAS を個別技法としてではなく、統合信頼性プログラムの「戦術的方法」の一つ、かつ設計・生産・運用を貫くデータフィードバックの主経路として位置づける**: §17.18 は FRACAS を DfR・試験(HALT)・生産品質管理・保全計画と並ぶ戦術的方法(継続的に適用すべき方法)として明示的に分類する。さらに図17.1・図17.2(信頼性プログラムフロー)は、開発・生産・運用の各段階から設計への点線のフィードバック矢印すべてに "FRACAS" と注記しており、FRACAS を個々の故障の処理手続きとしてだけでなく、統合プログラム全体を駆動する情報循環の仕組みとして描く。第12章・第15章・Appendix 5 が FRACAS の運用手続き(誰が何を報告し、どう分析するか)を規定するのに対し、第17章はその手続きが企業レベルの信頼性マネジメントの中でどこに位置するか(戦術的方法・データフィードバックの経路)という上位の見取り図を与える。(Source: [[@2012__Wiley__Practical Reliability Engineering - Chapter 17 Reliability Management]] §17.2, §17.18) ## 未解決の問い - 現代のクラウド運用では、FRACAS の故障報告項目を incident report、アラート、ログ、トレース、変更履歴にどう分解して保存すべきか。 - LLM エージェントが診断・修復を提案する場合、是正処置の有効性確認をどのゲートで自動化できるか。 - 保証データや顧客問い合わせのような粗いフィールドデータを、SRE のポストモーテムや AIOps データセットとどう統合できるか。 - 第12章は「是正処置は再試験で効果を確認して初めて閉じる」と主張するが、故障審査委員会が機能不全に陥る(責任追及の場になる、判断が遅延する)場合の対処は本書のどこにも記述がない。第17章(Reliability Management)を確認したが、同章も故障審査委員会の機能不全そのものには触れておらず、依然として本書の範囲外の問いである。 - Appendix 5 の出力仕様(故障一覧の識別子・階層キーのみ)には、症状・原因・是正処置そのものを検索・集計するキーが見当たらない。実際の FRACAS データベース設計でこれらのフィールドがどう索引化・横断参照されるのかは本書の範囲外であり、記述がない。 ## 関連 - ソース: [[wiki/entities/Practical Reliability Engineering|Practical Reliability Engineering]] / [[@2012__Wiley__Practical Reliability Engineering - Chapter 12 Reliability Testing]] / [[@2012__Wiley__Practical Reliability Engineering - Chapter 14 Reliability Demonstration and Growth]] / [[@2012__Wiley__Practical Reliability Engineering - Chapter 15 Reliability in Manufacture]] / [[@2012__Wiley__Practical Reliability Engineering - Chapter 17 Reliability Management]] / [[@2012__Wiley__Practical Reliability Engineering - Appendix 5 Failure Reporting, Analysis and Corrective Action System (FRACAS)]] - 概念: [[Design for Reliability]] / [[インシデント管理]] / [[根本原因分析]] / [[SRE]] / [[製造工程の信頼性管理]] / [[信頼性成長]] / [[信頼性管理]] ## 出典 - [[wiki/entities/Practical Reliability Engineering|Practical Reliability Engineering]](ch.12 §12.6, ch.15 §15.8, ch.17 §17.2, §17.18, Appendix 5) - [[@2012__Wiley__Practical Reliability Engineering - Chapter 12 Reliability Testing]](§12.6.1 故障報告と故障審査委員会、§12.6.2 是正処置の実効性) - [[@2012__Wiley__Practical Reliability Engineering - Chapter 14 Reliability Demonstration and Growth]](§14.13.1, §14.14.1 TAAF) - [[@2012__Wiley__Practical Reliability Engineering - Chapter 15 Reliability in Manufacture]](§15.8 Production Failure Reporting Analysis and Corrective Action System) - [[@2012__Wiley__Practical Reliability Engineering - Chapter 17 Reliability Management]](§17.2 統合信頼性プログラムのフィードバックループ、§17.18 戦術的方法としての FRACAS) - [[@2012__Wiley__Practical Reliability Engineering - Appendix 5 Failure Reporting, Analysis and Corrective Action System (FRACAS)]](ANALYSES: 分析出力の様式、Notes: 運用上の注記)