orangeitems’s diary

クラウドで働くインフラエンジニアの日々の感想です(ほぼ毎日更新)。



システムの障害対応時に心がけること

f:id:orangeitems:20190524123958j:plain

 

はじめに

世の中のシステムの数は間違いなく増え続けるばかりですので、障害対応の絶対数も増え続けることが宿命です。経験したたくさんの障害対応の中で、いくつか心がけることをおすすめしたいことがありますのでまとめます。

 

心がけるべきこと

まず、復旧することを優先すること

システム障害が発生したときに、迷うのは情報を採取するべきか。関係者に連絡を行うべきか。もしくは事前に決められた復旧手順を行うか。この3点です。

間違いなく、事前に決められた復旧手順を実施するべきでしょう。例えばミドルウェアの再起動、OSの再起動、ハードウェアの再起動などです。できれば一次障害対応手順書としてまとめられていた方がよいでしょう。ただし、この手順が複雑ではいけません。コマンドにして数行であるべきです。もし、複雑な手順を行わなければいけないとしたら、即時の復旧は無理ということです。

システムは利用者がいるため、連絡や情報採取に時間を使うより、まずはすぐに復旧させることが重要です。もし情報採取をしたいのであれば、復旧手順書に一行加える程度が良いかと思います。ただ往々にして情報採取には時間がかかることが多いので注意してください。

復旧優先です。

 

一次復旧できない場合、関係者への連絡が先

再起動したけど動かない。これが一番焦るパターンです。

原因調査を行い、根本原因を取り除かないと、復旧しません。

いきなり原因調査に入る技術者も多いのですが、まずはここで手を止めて。電話なりで関係者に連絡してください。基本は上司のはずです。またシステムの利用者がお客様である場合はお客様担当者への連絡も必要です。

連絡に関しては、ここはここで時間がかかるため、まず上司にエスカレーションをしたら上司が連絡をまとめてくれるのが理想です。もしくは上司が連絡役をアサインすること。技術者が連絡に時間を取られていると次に進めません。フォローが必要です。

深夜にエスカレーションもしないで原因調査を行い始めて、朝になったら大騒ぎになってて技術者は電話も出ないで原因調査中、なんてケースもよく起こります。

関係者は不安になり、システムユーザーは怒りだし、そんな状況の中で技術者は普通の精神状態でいることが難しいのですが、まずは連絡をはじめにきちんとつけておくことで、組織でフォローできるようになります。

技術者は原因調査に入る前に、この観点が必要です。

 

原因調査より前に、延焼を防ぐこと

さて、連絡もつけたし原因調査をしたいところですがちょっと待って。重要なポイントです。スケジュールされたバッチプログラムを停止する必要があります。これは異常な状態が継続した状態でバッチプログラムが動き始めると、二次的な悪影響が出る場合があるためです。

例えば、システムが起動しない場合に、取っておいたバックアップをリストアする必要があるかもしれません。しかし、裏で定期バックアップのバッチプログラムが動き、それが失敗するのはいいのですが、その後古い世代を削除しにいくかもしれません。ということは、放っておくと、バックアップは取られないのに古い世代は削除されていき・・データが消失してしまう恐れがあるということです。

このように、起こった障害に対して延焼を防ぐという考え方は重要です。原因調査して解決して終わらせたい気持ちがあるのは十分わかりますが、まずは火事のまわりの家々に燃え移らないようにすること。消火よりも大事なことかもしれません。

被害を限定的にすることは大事なことです。

 

原因調査は会社でやろう

今は会社にいなくてもリモートでシステムメンテナンスができる時代です。インターネットにどこでもつながり、ノートパソコンも高性能です。パッとノートを開きインターネットにテザリングでつなぎ、VPNを使ってシステムメンテナンスする。これは平常時はとても便利な環境だと思います(そのおかげでプライベートもプレッシャーが残る副作用はありますが)。

しかし、システム障害時で原因調査が必要になるときは、会社に行った方がいいです。しかも自分だけが行くのではなく、メンバー全員集合した方がいいです。

一人で、システム障害に立ち向かうと、頭がおかしくなります。

頭がおかしくなると、普段平常時には絶対にやらないようなことを人間はやってしまいます。

コマンドで言うと・・いや、書かないでおきます。そういうヤバいコマンドはいくつかあります。普段の作業では気を付けているのに、心が非常事態になるとやってしまいます。

後で振り返った時に、なんで私はあれをやってしまったんだろう。障害報告書を書きながら絶望するかもしれません。

そんな状況に陥らないためには、実は会社に行き、チームで対応することはとても有効です。窮地に陥ったときに、どのみち自分しか解決できないと思っていても、まわりに人がいてくれることで、少しは正気を保つことができます。

集中することはいいことなのですが、悪い状況で集中すると、どんどん心が追い込まれて情報処理ができなくなることは間違いないと思います。

しかも一人でいると、電話だメールだチャットだとノイズが入りまくります。当然です。一人でいる限り、連絡が入ってくるのは当然です。

会社にいれば、やっていることを後ろから誰かが見て、それを関係者に伝達したり調整してくれたり、障害報告書をまとめてくれたりします。

会社に行ってください。それまで原因不明の障害は放っておいたほうがましです。ただ、延焼するのがわかっているときは、前段の通りそれだけ事前に対応したほうがいいですね。

 

心の問題が非常に大きい障害対応

障害対応をすごくきちんとやったとしても、どうやっても怒られます。そもそも障害が起こった時点でマイナスからのスタートです。そしてゼロにはなりません。

したがって、障害が普段起きないようにするための予兆対策は非常に重要ですが、起きるときは起きます。しかも自分の責任じゃない場合もあります。クラウドですと、全世界で発生した・・、のような基盤の問題もあります。しかしユーザーは誰が原因なのかは全く関心がありません。障害が早く回復してほしいだけです。

そんな状況の中で、最善を尽くしているシステムエンジニア達のホスピタリティーは素晴らしいと思うのですが、やるのは人間です。人間ですから心があり、感情があります。もともとマイナスの状況で楽しい人は誰もいません。しかも障害対応が無ければ、休みだったり別の仕事をやっていたのです。

このマイナスの環境で仕事をすることでの大事な要素は心です。どんな状況であっても安定していて、誠実で、誰かに怒ったりなじったりしない。他人への尊厳を失わないこと。それは技術者だけではなく関係者すべてに求められます。

私の経験した様々な障害対応に関して、結局は人間力が重要となる場面もかなりありました。障害が起こるたびにどんどんギスギスしていく組織。障害発生の電話に出ない人。責任の押し付け合い。仕事に積極的な人に障害対応の負担がどんどん集まる不平等な状況。しかも仕事をする人に責任が求められていく。仕事量が増えれば障害に立ち会う確率も増えますから本来は責任を問うのはおかしいのですが。人間関係がどんどん崩壊していき、障害対応どころではなくなっていく・・。そんなことが起こりえます。

そうならないように、上記でお伝えした「心がけること」を共有したいです。技術者や関係者の「心」を守るような行動を組織で行っていくことで、今後も増え続ける本番システムに関係者全員で立ち向かっていけたらいいなと思います。いかなる時でも自分や関係者を尊重しあうことで、心は守られていき素晴らしい運用組織ができるはずです。