システム障害対応に対する考え方について
社内システムが普通に12月32日なって 「どーなってるんですか!」とユーザに言われて、 しらねーよ俺作ってねーよとは言えず呼び出されたことがw
2014-01-01 02:57:47後、汎用機で1月1日になったら急に送受信が止まって呼び出されたときに… MMCFに「expire:20〷」って設定がされてた。 訳:期間満了って事 こんな地雷設定しこむんじゃねー!と叫びたくなったよw
2014-01-01 03:00:57この手の話はくさる程あります。 なのでシステムは年次迄回ってやっと一人前です。 年次を超える地雷はもうその都度対応しかない。 @hachi_mitsu それあかんやつw
2014-01-01 03:02:23僕は小さい会社でやってきたことが多いので金額的インパクトはたぶんMAX1億位の障害しか経験してないけど。 ・ユーザー影響ある時はキーマンの上司に報告 ・絶対慌てない(いつもよりゆっくり動くくらいで良い) ・ホワイトボードを活用
2014-01-01 03:18:28正直報告ってそこまで細かく報告してもしょうがないのと、後、とにかく「聞くだけ聞きたい」って人が無茶増えるのでそれにいちいち報告しない(なのでホワイトボード) 本線(直属ライン)以外の報告は無駄す。対応する人自体はあんまり増やすことが出来ない(間違えた行動すると即死)からね
2014-01-01 03:20:51僕の場合、本当に大事になった障害は全て二次災害(戻し失敗)なので、「早く対応しろ!」みたいな怒号は無視する事。5分焦って1日飛ばしたらなんもなんないだろ。大体において焦って動いたって1時間で10分位しか縮まらない。だったら落ち着いてやりましょう。周りのプレッシャーあるからね
2014-01-01 03:24:49後、作りこみのシステムは大体ヌシみたいな開発者がいるのでその人と仲良くなっておくことw 結局、重大障害は「そのシステムをどこまで深く知ってるか」という人が対応するのが一番安全かつ早い。(あとは伝書鳩) なので障害対応は営業的な部分もあります。
2014-01-01 03:28:46普段「これは運用の仕事じゃありません!」ってつっぱねてるとこういう時にしっぺ返しが来ます。 但し、やりすぎちゃうとそれはそれで目を付けられるのでバランスをとること。 お勧めは「やりすぎてその分の工数をちゃんと提案する」と裁量が増えてくし評価も上がります。(がその瞬間はきついw)
2014-01-01 03:30:49それとユーザー影響ない事はあまり大事にしない事。非常に厳しい職場では一つでも手順に無い事を行動するとそれをさも大事の様に騒ぐ人いますが、正直そのお金はどこからも出てこない自己満足しかないです。(本当に止めれないシステム例えば原発なぞは例外だけどね)
2014-01-01 03:34:10そんなことやってる位ならさっさとおうち帰って友達と遊んだりした方が良いです。 僕は「ユーザー影響ないインシデントに対する工数」ははっきり無駄と思います。そういった記録を取ったり、改善会議をする工数ってものすごく膨大な割に成果に跳ねてない事が多いですよ。
2014-01-01 03:37:53今のところリアルタイム情報共有では「ホワイトボード」に勝てるツールは無いです。職場で経費で購入できるし、事象を共有するのが早い。逆に事象を時系列できちんとかければ一人前。これが出来ない人が多い。で、下っ端が書いてある事をキーマンに定時連絡する。(これで分業できる)
2014-01-01 03:41:39それと「原因」と「現象」の違いをはっきり区別して書くこと。 原因なんて即時わかることはまれです。 現象を追って原因にたどり着くので。 即「原因は何だ!」って叫ぶ人がいますが無視無視。原因を勘違いするのが二次災害を呼び込みます。本当に丁寧に原因を絞り込むこと。
2014-01-01 03:44:49原因を絞り込めればそれに対する変更を行えば絶対直ります。注意するのは変更管理。変更するって事は影響があるって事です。変更をかけることの責任分散をできればした方が良いです。(上司に報告とかね)でないと最悪クビが待ってます。
2014-01-01 03:46:41ここまでの事が全て手順化されて現場に浸透している所は見たことないんだよね。殆どの現場は間違った暗黙知が支配している感じ。できる人がそのままやっちゃってて、異動退職で大騒ぎってあるあるすぎる。
2014-01-01 03:48:51ロジカルライト。 シニカルにヒッソリと世の中を見ております。 コンサル、プロマネ、社内SE。 男声合唱団TAG。 ニコ楽プロジェクトマネージャ。 ダイエット。 まとめ:http://t.co/JAEulNWt2M