社会インフラを支えるシステム、例えば金融システムや公共システムについては、高い信頼性が求められます。
このようなシステムの本番運用で障害が発生した場合、その結果は重大なものになります。
一般的なイメージとして、その「重大なもの」として、以下のようなものをイメージすると思います。
- 信頼が失墜する（最悪の場合は報道される）
- 経営者がお客様に怒られて、責任者が経営者に怒られて、技術者が責任者に怒られる
- 技術者や責任者が缶詰になる
この記事では、本番運用で障害が発生した場合に、元請けSIerで一体何が発生するのか、元請けSIerのプロパーであった私の経験を交えて、より具体的に書いていこうと思います。
そして、具体的に何が起こるのかを知ることで、品質向上の意識を高めていただければと思います。
【障害の検知】
障害を検知する契機として、「お客様に指摘される」という契機で見つかるのは最悪です。
事前にSIer側で障害を発見できなかったためにお客様の心象が悪くなることで、その後の要求（障害対応、再発防止、補償）が厳しいものになるためです。
また、お客様に指摘されているということは、既にデータが作成されて、「画面」「帳票」といった形でお客様の目に触れているので、そのデータを補正しなければならないということで障害対応の作業内容の難易度も上がります。
そのため、お客様に見つかる前に障害を検知する努力を惜しまず行うべきです。
異常なデータが発生した時点でその箇所の処理を停止させれば、運用作業でその箇所だけ補正して対応することができます。
エラーハンドルが重要であるとされるのはこのような理由からです。
また、この運用作業は人手で行うこととなりミスが発生しやすいので、システムを構築する場合は、運用作業を予め計画して手順化することでミスの発生を抑える努力も重要になります。
システム改修直後は障害が発生する可能性が高いので、すぐに障害対応できるように、改修直後の監視体制を敷くことも重要です。
なお、システム改修の結果、思いもよらぬ箇所に影響が発生し、重点的に監視していない箇所で障害が発生しお客様に指摘されるというのも良くあることです。
影響調査を抜け漏れなく行うことも重要になります。
【障害の対応方針の検討】
障害が発生した場合、どのような障害が発生したのか、その事象内容と原因をお客様に報告する必要があります。
そして、システムの都合の観点と、お客様の業務の継続の観点から、対応方針をすり合わせることになります。
検討している間にも障害は発生し続けているので、検討は迅速に行う必要があります。
システムの都合の観点で言うと、障害対応でプログラム作成が必要なのであればその期間を見る必要がありますし、プログラムを実行・リリースするタイミングも計る必要があります（サービス停止日にしか実行・リリースできないことも多いです）。
それまでの間の暫定対応（運用作業）の計画も立てる必要があります。
そして、暫定対応はお客様の業務を継続する上で必要なレベルを満たす必要がありますし、恒久対応では元々求められていたレベルに戻す必要があります。暫定対応中に制約や機能制限が発生するのであれば、そのことについてもお客様の了承を得る必要があります。
なお、この時点で明らかに対応するべきことがあれば、責任者の許可を取った上で、技術者は検討中にも対応し続ける必要があります。
手順書に書かれた作業や、その他常識的に行うべき作業（例えばディスク容量オーバーでシステムが落ちたのであれば不要データの削除とシステム再起動）がそれに該当します。
【暫定対応の実施】
検討された方針に従って、暫定対応を行います。
この作業は基本的に手作業での運用になることが多いため、運用担当者を立てて体制を整える必要がありますし、運用作業でのミスが無いように手順書や簡易ツールを作成する必要もあります。
また、暫定対応中に制約や機能制限が発生するのであれば、そのことを説明する文書の作成と周知という事務作業も発生します。
【恒久対応の実施】
プログラムの作成が必要なのであれば、それを作成する担当者を用意して工数を割り振る必要があります。
そして、プログラムの本番環境での実行・リリースに向けた準備（手順書作成、社内手続き等）も必要になり、また実行・リリースに向けた出社体制を整える必要も出てきます。
お客様の立ち合いが必要なのであれば、お客様にも立ち合いを依頼する必要があります。
【再発防止策策定】
恒久対応が完了した後、お客様へ恒久対応完了の報告を行います。
しかしそこで終わりではなく、今後同じようなことが起こらないように、障害が発生した要因の報告と、再発防止策の策定を求められることが多いです。
社内での再発防止策の検討、そして再発防止策の説明にまた工数を取られることになります。
また、再発防止策は、チェック体制の強化に繋がることも多いので、それが積み重なると開発スピードの低下にも繋がりかねません。
（多くの開発者にとってストレスになるであろう、重厚長大なチェックリスト、煩雑な承認体制、頻繁なダブルチェック・トリプルチェックは、再発防止策が積み重なって出来上がるものです）
【障害に対する金銭的な補償】
障害が発生した場合、SIer側が金銭的な補償をしなければならない場合もあります。
システムのSLA（サービス内容に関する合意文書）に補償に関する項目があるなら、それに従って補償をしなければなりません。
重大な障害である場合は、裁判で損害賠償請求されることもあります。
仮に、直接的な補償がなかったとしても、障害を発生させたことでその後の交渉でSIer側が不利になり、システム継続利用時に値下げ要求をのまざるを得なくなることも少なくありません。
ニュースで報道された場合は、直接被害が発生していないお客様との交渉でも不利になりやすくなります。
当然、競合システムに離反されることもあり、この場合も収益の低下に繋がります。
以上のように、本番障害を発生させることで、SIer側には以下のような損害が発生します。
- 障害対応や再発防止策のための工数の発生
- 再発防止策による開発スピードの低下
- 障害に伴う金銭的な補償
本番障害が頻発する現場では、不定期に発生する障害対応・再発防止策の工数と開発スピードの低下が原因で、次のシステム開発にも支障が発生し、QCD（品質・コスト・納期）のバランスを取ることが困難になります。
障害に伴う補償をしただけでなく次のシステム開発も予定通りに進めることができなくなるため、収益力が低下することになります。
頑張って長時間働いても、それに見合う収益を得ることができなくなってしまいます。
このように、本番障害を発生させることによる損害は誰にとっても大きいため、本番障害を発生させないように一人一人が意識する必要があります。
障害を発生させた経験から学ぶという姿勢ではなく、社内外の過去の障害事例から学ぶ姿勢が重要になります。
いかがでしたでしょうか。
２次請け以降の立場で案件に参画していると、本番障害発生時に何をしているのか伺い知れない所が出てきます。
この記事により、その情報を上手く共有できれば幸いです。
来年も、この調子でブログを更新していこうと思います。
では、良いお年を！
コメント