春分の日の振替休日であった月曜日
朝から鳴り響く電話
無視して二度寝・・・
するわけにもいかないので出ましたよ。
はい。タイトル通りシステム障害のお電話でした。
この記事ではシステム障害が発生した際に何をしているのかを書いていきます。
システム障害は発見が遅れれば遅れるほどきつい
システムを構築する際、いくつかの工程を経て作成していくのですが、障害って後になればなるほど面倒臭くなります。
その理由の一つが、ウォーターフォール型と呼ばれる開発手法が使用されているからです。
ウォーターフォール型の開発手順
・お客さんと打ち合わせをして要件を固める
・システム全体の機能の設計、画面の見た目などを決める
・各機能の処理の流れを設計する
・（各機能の処理を更に細かく設計する）←省略されることも多い
・実際にプログラムを作成する
・作成したプログラム単独で動くかテストする
・プログラム間で連携できるかのテストをする
・システム全体として動作するかのテストをする
・実際のデータを用いての運用テストをする
・システム稼働
ざっくり上記の流れでシステムが構築されます。
プログラム作成時の障害
障害はテストの工程以降で発生するのですが、プログラムを作ってすぐでは別段問題にはなりません。ただ直すだけです。
障害の一覧表を個人レベルで記入したりします。
そうすることで別の機能を作成する時に同じミスを減らすことができたりします。
この障害が少なすぎると本当にテストしたのか疑われるという面倒臭いイベントが発生するので、適度に障害を出します。
また、ここ以後でプログラムテストレベルの障害が出ると嫌な目で見られるので、とにかくプログラムを叩きまくりましょう。
結合テスト時の障害
プログラム間の連携テスト以降の工程で障害が出ると、プログラムを直す時にはソースコードにどこをどう直したかコメントを入れます。
これをしないと以後の障害の原因がわからなくなります。この連携のテストでの修正が原因で障害が出る可能性があるのです。
さらにその修正によって他の箇所に影響が出ないかの調査＆修正が必要になります。
まぁ修正したせいで他の箇所に障害が出ては本末転倒なので当たり前なのですが笑
ここで障害が沢山出ると、プログラムテストをやり直せというお客さんも稀にいます。気をつけましょう。
ただ、障害を見つけないと後で苦労します。このあたりから障害を見て見ぬふりをしたがる輩が増えるので、リーダーは嘘つきがいないか目を光らせないといけません。
システムテスト時の障害
システム全体のテストで障害が発生すると、上記に加えてさらにプログラム間の連携テストを一部やり直します。
今までできていたことができなくなってないよね〜テストが増えていくわけです。リグレッションテストなどと呼ばれます。
そして、お客さんによっては「何故この工程で発見されたのか？もっと前の工程で障害を発見できたのではないのか？」という問いに答える必要がでてきます。
これがまた本当に面倒臭いです。そんなことはいいから障害調査や影響調査に時間を費やさせてくれと言いたくなります。
この工程までくるとちゃんとした人しか大体残らないので、障害の見て見ぬふりは減ります。ただし言い訳をして障害ではないと言い出すのもこの頃からです。
運用テストで障害が発生してもやることはシステム全体のテストの時とあまり変わりません。会社にもよりますが。
稼働後の障害
そして晴れて稼働を迎えます。
そして障害が出ると・・・
障害の原因調査、影響調査、修正方針の決定、原因・影響・修正方針をまとめた報告書の作成、プログラム修正、テスト沢山、始末書の作成、リリースが待っています。
私自身は報告書や始末書を書く立場にないので助かってますが・・・非常に申し訳ない気持ちになります。
しかしながら、金融系や医療系など、絶対に障害を発生させてはいけないシステムを構築している人たちは本当に凄いと思います。
私なら発狂しますね。
決して障害を発生させても良い現場なわけではないですけど、それでもやはりまだ楽をさせてもらえてると感じます。
障害を発生させないためのコツ！
面倒臭い、端折ってもいいかなという場面でキッチリやること。
後になればなるほどもっと面倒臭くなる。
嘘はつかないつかせない。
障害を隠さない隠させない。
お客さんとは仲良くしておく！！