バグなり障害が発生しました
さぁ大変、どうなおしましょうか？対応マニュアルある？あるならそれやれよ。
ないならどうしたらいいの考えろよ
セキュリティ突破されたのなら何が悪かったのよ
はい、システム開発やってるとトラブルって、ケースバイケースなんですね。
ものによって対策の仕方は変わってきます。
一番の敵は
不正確な情報です。
もちろん、第一報を受けた時はいろいろ仮定します。起きた事象を聞きながら、あらゆるケースを考え、絞り込んでいきます。
自分も役柄上対策係になるケースは多く、まとめ役をよくやっていましたが
嘘やごまかし、適当な報告をくれる人が一番の敵です。
判断ができません。
というか見当違いな議論して時間食います。
せっぱつまってるときほど正確な情報が欲しいのです。
多少遅くてもいいから正確な情報を知りたいのです。
専門家は散らばっています
システムが大きくなればなるほど業務もそうですしOS、ミドル、ネットワーク、セキュリティなど等、多くの関係者が携わる世界ですので、本当に問題を引き起こしてる箇所がすぐに特定できない場合はいろんな人に可能性を確認してまわります。
で、簡単に”うちそれ関係ないよー”
っていう人、たくさんいます。でもそういう回答人は案外最終的に被疑者になりやすいです。
全く関係ないですよね、、って逆にわかってても聞く場合があるのですが、起きうる可能性考えてみますって回答してくれる人は涙がちょちょ切れるほどたよりになります。
そういう人ほど経験値が高いのであれじゃね？みたいなヒントくれます。
で、全てパーフェクトに物事を知っている人は漫画やアニメの世界にしかいません。
（よっぽどちっちゃいシステムならいるかもしれませんが）
まずは、暫定対処できるかどうか
人間の処置と一緒で血がでているならとりあえず血を止めることを考えます。システムも一緒です。事象がおきないようにするケースを考えます。出血量が多ければ最悪システム停止です。
小さいところからサービス止めたり、バックアップ機（実は最新じゃない）にそっと差し替えたり、それっぽい画面をだして一時しのぎしたりします。
※みなさんがみ慣れている画面で実は裏では50X系とか（内部エラー）でてる可能性があるのもあるんですよ。しらなかったでしょー（棒）
苦情がとまればシステムの寿命は延びますｗｗｗこれ鉄則。
で、出来る限り影響最小限にして再開します。あれ？あんまりいってるとどんなシステムいじってたかばれそうになってきたぞｗ
本格対処は原因がはっきりしてから
本当に対処できるのは、原因がはっきりしてからなので、ここまでもっていくのが実はすごく大変です、数分でわかるものもあれば、数日かかるものまであります。
OSやH/Wのバグとか引いてると数十～数百人単位で調べても再現しなかったり対処が違うバグ引いたりすることもよくあります。
※わざと大小混在ケースを混在させているので分かりづらくてすみません。あまり詳しくかいているとばれそうなので
本格対処は実は放置されたりもします。
だって今後起きるケースはない（限りなく0）のパターンもあります。
でもそれは完全に把握できて分かったからそういう対処ができるのです。
最初にいったように、不確定な情報だとその判断ができません。
あとセキュリティがらみなら無対策はあり得ません。必ずなんらかの対処します。
ここまでかいてきてちょっと脱線
なんとなくわかってくれる人がいるかもしれませんが、情報がすべてなんです。
被疑箇所を特定するためにはログなり出力されるインフォメーションが必要なのです。
プログラム設計レビュー段階で、ここでバグったらあなた特定できますか？ってよくレビューでききますが。適当に作ってる人はだんまりです。
あとはこのログとこのログの違いは？ってきいて同じですと答える人も多いです。
ログの出し方はマジでセンスがいります
重要なのでプロプログラマを目指す方はログを軽視せず、綺麗なログを出すスキル磨いてください
なにがおきても-1（汎用エラー）返す関数（クラス）つくってくれる人がいましたがセンスねーなーっておもってみてまいした。
エラーコード表みただけである程度の力量がわかります（笑）
設計側の要求（意図）を満たしてもらいたいです。
エラーちゃんと分けてるけど、対外・下位レイヤーで起きた事象を丸める人多かったです。
俺：下位レイヤーでXXXがおきたらその情報でしらべられますか？
担当者：無理です。何が返却されてるかわかりません。
このやりとりは何万回したかわかりません。調べるための情報はちゃんとログに出しておきましょう。本当は相手が悪いのに自分のせいにされますよ、ログは自分を守るためにあるんです。
戻せる問題と戻せないトラブル
トラブルシュートは時間がかかるものなので時間で変化するデータ程戻せなくなります。そして被害は拡大します。
それがお金にかかわる事なら事は重大です、どれぐらいの被害がでたか計算しないといけませんからねぇ、、、
なので自分はあまり料金や金融の案件はやりたくなかったです、あと人の命が係わる事。*1*2
戻せない場合は結果をまとめて経営陣にまるなげぽーーーいです。
ぽーいする情報を頑張ってまとめるだけです。そして経営陣が有能であれば、まるっと収めてくれます。無能だと、現場になんとかしろといってきます。
現場ではムーーリーーー。
自分が責任者な場合だと顧客説明と営業つれて賠償についてのお話となります。あれは胃が痛くなります。
が、ここで間違えてはいけないのが
必ず正確な情報とその場で質問に答えられる情報を持っておく（または人をつれていく）です。
もちろん持ち帰らないと分からない想定外（とんちんかん）な質問もたまにきますが基本その場で回答できることが望ましいです。何でもかんでも持ち帰る。後ほど検討しますではお客様の怒りを買うばかりです。
えっと、、わかりませんん、、を繰り返して某企業から出禁を食らう人を何人も見てきました（笑）*3
おきうる障害を想定することも大切
将来設計をしたいと思っている方、おきうる障害をある程度想定しながら設計してください。これができるようになると実際起きた時の対処の時間が格段に軽減されます。
バグと同じでシステム開発上、あとで出てくるトラブルのほうが対処が難しくなります、よって商用で障害が起きてしまうのが一番コストと労力を消費します。設計時・試験でつぶせるものはつぶしておけるようにしましょう。*4
まとめ
またなにかいてるかさっぱりわからんくなってきましたが、優秀なシステムほどトラブ時の対応が早かったり、被害がなかったりします。でもそれが普通って思われるんですよね。インフラに近ければ近いほど動いていることが当たり前ですから。
IT土方の方は頑張ってトラブル対応していきましょう！（他人事）
