形あるものはいつかは壊れるのが浮世の定めでございますので、いつ何時でもシステムは障害を起こす可能性を秘めているわけです。また、人は過ちを犯す生き物でもございますので、ちょっとした操作ミスや通知の見逃しなどの可能性もございます。
もちろん一部が壊れることを想定して冗長構成を組むなど、サービス自体が止まらないようにされている場合も多いわけですが、立ち上げたばかりのシステム、低予算でかろうじて動かしているシステムなど、プロセスが成熟していないシステムも多々存在しております。
結果的に、システム運用に関わる多くの人は、障害対応やそのレポート作成を手掛けられた事があろうと思います。

いざ、トラブルが起こり、障害分析を行って報告を行う段になりますと、障害理由や今後の対策などを記載することになるわけですが、障害理由を突き詰めていくと、おおむね以下に落ち着きます。
(1) プロセス、ルール、仕組みが悪い　
(2) 人が悪い　
(3) めったに起きないレアケース

多くは(1)のケースで、検知の枠組みが足りない、作業のチェック不足、アプリの例外想定不足などが挙げられます。対応コスト、対応のスピード感など、顧客との交渉はPMの腕の見せ所です。
(2)に落とし込むケースは顧客向けの報告では、めったに見ませんが、内部の振り返りでは時々あるケースかと思います。よく原因追及の「ナゼナゼ分析」を繰り返すと、最終的には個人の責任追及に向かいがちといった声も聞かれるわけですが、該当する担当者をプロジェクトから外すとか、個人の「やる気・注意力向上」といった対応策に流れがちなので、慎重さが必要になるケースでしょう。
(3)は顧客が納得してくれそうであれば、説明しやすいストーリーではないかと思います。「それが原因ならしかたが無いか」と思わせるようなものであれば、利用者や上司にも説明しやすいというわけです。言葉は悪いですが、ウソのない範囲で(3)っぽい落としどころを探るのもPMの力量の一つかと思います。

障害がでているので顧客に迷惑をかけているのは確かですが、障害対応と障害報告をしっかりやっていくと、逆に顧客に感謝されて信頼される場合も多いです。
実際、かなり大変ですがPMの皆さん頑張りましょう。