２０２３年１２月１４日
e-お菓子ねっと会員企業各位
富士通Ｊａｐａｎ株式会社
ｅ-お菓子ねっとサービス 新基盤移行に伴う障害に関しての再発防止策及び更なるサービス向上について（ご報告）
謹啓 貴社益々ご清栄の事とお慶び申し上げます。平素は格別のご高配を賜り、厚く御礼申し上げます。
掲記の障害につきまして、会員の皆様に多大なるご迷惑をお掛けしましたことを深くお詫び申し上げます。
本障害の根本原因及び抜本対策につきまして、下記の通り取り纏めましたのでご報告申し上げます。
今後この様なことの無いよう、鋭意努めて参りますので、相変わらぬご愛顧を賜りますよう、何卒よろしくお願い申し上げます。
謹白記
１．障害発生内容
２０２３年３月１３日（月）１０：００～１２：００ ピーク時のデータ配信レスポンス劣化（最大 130 分）
２０２３年３月１４日（火）１０：００～１２：００ ピーク時のデータ配信レスポンス劣化（最大 118 分）
２０２３年３月２０日（月）１０：００～１２：００ ピーク時のデータ配信レスポンス劣化（最大 79 分）※上記期日以外でも最大で 20 分程度かかっておりました。（3 月 15 日～3 月 23 日）
２．根本原因（真因）について
今回の障害は、旧基盤から新基盤への移行作業に伴う以下の真因により発生いたしました。
（１） 移行設計段階におけるリスク分析不足（クラウド共通機能<Web-API＞利用のリスク分析不足）
クラウド共通機能<Web-API>はクラウド基盤で提供されている共通機能であるため、利用することで通信情報の取得が容易に取得できるメリット面を評価しておりましたが、ピーク時の利用頻度をもとにしたデメリット面の分析・評価が行われておりませんでした。
（２） 負荷テストの不足（新基盤における負荷テスト、新基盤への移行テスト項目の漏れ）
富士通 Japan 内部の判定会議において性能面含めてテスト結果に問題なしと評価しておりましたが外部機能（Web-API）利用のリスクが表面化されていない点から判定会議の中で問題潜在の指摘に至りませんでした。
①負荷テストにおけるテスト手段の不備（テストデータの多重投入パターンの未実施）
実際のピーク時間帯よりも厳しい条件（30 分で 1250 データ）のテストデータを設計で決定しまし
たが、投入方法についての詳細設計がないまま単一プロセスで順次投入する手段を用いてしまいました。そのため、Web-API 部分の同時起動数制限により、ピーク時間帯に必要な同時処理数が足りなくなる問題が負荷テストで検出されず、問題を発見することができませんでした。
②負荷テストにおけるテスト条件の不備（ピーク時間と同時間帯でのテスト未実施）
負荷テスト実施時間帯を通常のピーク時間に実行しなかったため、一部のクラウド仮想サーバで物理 CPU 負荷時間帯に依存した問題が潜在的に発生する可能性を検出できませんでした。

（以下次葉）

（前葉より）③データ配信部分の負荷テスト実施不備
負荷テストでは、データが格納されるまでの時間にのみ焦点が当てられ、データ配信（メーカー様への受信）部分の負荷テストが不十分でした。そのため、状況照会の更新対象が一定数を超えた場合に更新異常が発生する状況を検出することができませんでした。
３．再発防止策について今後、同様の問題を再発させないために、以下の再発防止策を実施いたしました。
（１）設計段階におけるリスク分析不足の対策として、「移行計画項目定義」を作成（2023 年 5 月末完了）
移行計画書を e-お菓子ねっと専用に作成しました。特に今回原因となったクラウド共通機能の利用有無およびリスク評価の項目を追加し、設計工程でのリスク評価を確実に実施できるよう見直しました。
今後の開発においては、この「移行計画項目定義」をベースに移行計画設計を行うことで、今回のようにリスクの把握および対策を実施しないまま製造工程へ進むことを防止します。
（２）テストによる問題検出の対策として、「テスト計画項目定義」の作成（2023 年 5 月末完了）
テスト計画書を e-お菓子ねっと専用に作成しました。特に今回原因となった下記 4 つの観点を規定することで、今回のような性能問題が負荷テストで検出できるよう改善しました。
① ピーク情報調査の明記（データ同時発生状況／ピーク時間帯）② 負荷テスト条件の明記（データ投入多重度／テスト日時）
・テストデータは必ず複数プロセスでの同時投入とし、①で規定した処理多重度と比較・評価します。
・負荷テストの実施は①で規定したピーク時間帯と同じ時間帯で設定します。
③ データ集配信部分のテスト実施範囲の明確化（集信／配信でのテスト範囲規定）
・配信（メーカ様受信）部分の負荷テストも必須として規定します。
④ 並行ランニング試験での性能計測実施評価の明記
・移行元／移行先の環境の互換性を計画時に評価した内容を記載します。
・互換性が低いと判断する場合は、データを新環境へ転送する並行ランニング試験の実施を明記します。
４．有効性検証について「３．再発防止対策（１）（２）」の対策について有効性検証を実施いたしました。
（2023 年 8 月完了）
（１）サービス基盤移行が次回発生した際の移行プロジェクトへの有効性検証
移行計画項目定義、テスト計画項目定義についてサービス基盤移行プロジェクトの要件を元に第三者チームにて改めて移行計画書／テスト計画書を作成し、今回の障害事象をテストで検知できることを確認いたしました。
（２）開発プロジェクトでの適用と有効性検証
インボイス開発プロジェクトにてシステム開発への有効性検証も兼ねて適用しました。
テスト範囲やテスト結果についてテスト項目定義に沿って事前検討をしたことでご利用企業様へ事前案内を強化すべき課題が抽出され、案内強化につながった点で効果を確認いたしました。
今後のシステム開発へも適用し、内容を改善していくことで品質強化が可能と判断いたしました。
（以下次葉）

（前葉より）
５．更なるサービス向上について（会員企業様からのご意見・ご要望に対する取り組み）
今回の障害に対する会員企業の皆様方からの貴重なご意見・ご要望に対し、以下の通りサービス向上・改善施策に全力で取り組んでまいります。
（１）障害発生時の情報提供【ご意見】
障害時に提供するべき情報・状況の対応内容・役割分担の取り決めが曖昧である。
→障害運用（遅延含む）
・訓練などの場で検討見直しする場が設定されていない。
【改善施策】
会員企業様への情報提供内容とルールを下記の通り見直し、「緊急事態対応ガイドライン」を改訂しました。
（2023 年 11 月末製販代表会議にてご承認）①情報提供内容と提供方法の定義項目を追加
障害パターン別に提供するべき情報と提供方法を規定しました。
これにより障害発生時に情報提供する内容の統一と公開までの時間を短縮します。
②情報提供内容とルールについて定期見直しを行う運用とします。（年１回）
障害訓練で新たな障害パターンや、情報提供における改善箇所の訓練を実施します。
（２）障害定義の見直し【ご意見】
緊急事態対応ガイドラインにおける障害の閾値設定が今回の事態と乖離している。
（現在は、対象とする不測の事態を「サービス停止予測時間 1 時間以上の障害」と設定している）【改善施策】
障害発生時の初動運用フローおよび閾値を見直しました。
→業務実態に即した初動運用フローと閾値になるよう見直しました。

本書にて報告した再発防止対策および更なるサービス向上への対策は、今後のサービス運用・システム開発へ適用しながら随時内容を見直します。また、持続的に品質強化できるよう推進体制の見直し・強化を実施することで、同様な障害が再発しないよう努めてまいります。
以上