システム障害は、「気の流れ」が変わった時に発生しているのではないか

1. システムの安定運用には、「気の流れ」が変わる時を意識したい

2021年も残り3か月と少し。新型コロナウイルス感染拡大の不安が続く中、テレワークは感染予防策として有効であり、会社の働き方のスタイルの1つとしてスタンダード化されている。

しかし、これといった解決策がないため我慢の状態が続いているが、リフレッシュの時間は取れているだろうか？　ぜひ、休憩時間はパソコンから離れ、外の空気を吸うことをおすすめしたい。

さて、本日は、システムが安定的に稼働している陰には、多くの管理者や社員がバランスよく携わっていて、そのバランスが保たれることが大切だということと、システム障害は、バランスが崩れ、「気の流れ」が変わった時に発生しているのではないか、ということを伝えたい。経験談も含めて話をしたいと思う。

「気の流れ」は、日常的にも注意したいところであり、その日の時間帯や曜日についても考えてほしい。システムの安定運用を目指すには、想定外のことを考え、先読みすることや、少しの変化に対して「本当にこれでいいのか？」、と自問自答をしてみることを試してみてはどうだろうか。

2.人事異動の時期は会社的にも気をつけるゾーン

人事異動は、職種にもよるが、情シス担当の異動時期は大変だったことを覚えている。特にシステムのメイン担当者が異動する場合は、異動先の職場に連絡してヘルプを求めたことがある。僕がスポーツ中継のグラフィック開発を担当していた時、主にゴルフ中継の開発を行っていた。そして、人事異動でネットワークを開発した担当者が異動になり、なぜか動作が不安定になったことを覚えている。普段通りの運用をしているはずなのに、上手く動いてくれないのだ。まるでシステムが「怒っている」ように思えた。

原因は多々あると思うが、同じ経験をしていくと、人事異動の時期は会社的にも気をつけるゾーンと思っていいのである。

当時は、不思議に思っていたが、残された職員に対して何か試されているのだなーとも思っていた。「システムは人に付いていく」ものと思っていたので、体制が変わる時は、大変であることと、システムの安定的な運用は、いろいろな人の手により保たれているのであることを知った気がする。

しかし、この障害をきっかけに新しいメンバー間のチームワークが強化されたことは間違いない。システムの安定運用にはチームの気持ちが1つになっているのが必要なのだ。

システム障害は、体制の見直しを行ない、従来のやり方から一皮むけた新しい体制を作るためのチャンスとして前向きにとらえるのも必要なことである。障害を起こさない努力を忘れてはいけないが、普段から障害対応の心構えを持つことが大切なのである。

情シスの職場が上手くいっているところは、そうした苦労を乗り越えているのかもしれない。40年間働いて感じたことは、このようなことが「繰り返し起きている」ということである。

3.情シス業務で日常的に注意したい時間帯

情シスとしてシステムの運用管理を行っている中、緊張する時間帯があったことを紹介する。

お昼休み前の午前11時ごろから1時間と、終業時間の18時から2時間ぐらい前の時間帯だ。この時間帯は、少しでも早く終わらせて休憩に入りたい気持ちになり、単純なミスを起こしてしまうと思っている。心理的な緊張感にゆるみが生じるということでヒューマンエラーが起きやすく、事故につながるケースが多い。メール開封で注意力も落ちてしまい、ウイルスに感染してしまうといった、パソコンに関する問い合わせが多かった。中でも月曜日の午前中は、休み明けということもあって問い合わせは集中していた。

システム整備作業でもこの時間帯は気をつけていた。作業スケジュールの中に時間を確認するチェックポイントを設けて調整することをしていた。これは「慣れからくる先走り傾向」を防ぐ効果があった。

4.情シス業務は週末も注意したい

日常業務では、上記に加えて金曜日の終業18時から20時の時間帯を気にしていた。
金曜日は特にサイバーセキュリティの脆弱性情報やゼロディ攻撃に備えた情報が流れてくるため、システム上の確認と休日体制の確認作業に追われていた。

当時、僕は週末の緊急体制を作る担当だったが、単身赴任の職員が帰省予定を立てていたり、遠出を予定している職員がいたりするので、体制表を埋めるのが大変だった。必要なメンバーを確保するためには、躊躇しない姿勢を貫き通すが、最後は自分が対応するしかない体制をとっていたのも事実であり、週末に何も起きないことを常に願っていた。体制を確認するときに大切なことは、金曜日の夜から休日モードになっているので、金曜日の行動から確認することが重要だった。

脆弱性の連絡も遅い時間に来ることもあり、正直、脆弱性の連絡メールを見過ごすこともあった。しかし、メールを見た限りは、仕方ないというよりも、自分の中のスイッチが入ったことを今でも覚えている。脆弱性情報には危険レベルを表すのもがあるが、その危険度によっては全システムの「使用アプリ」状況調査をしなければならない。全システムへの連絡となると大変な仕事になる。

不安に思う時は、「少しやり過ぎる」ように心がけていた。いつもと違う「気の流れ」を感じた場合は、躊躇せず実行した方がいいのである。個人的には「あの時、もっとやっていればよかった」と、後悔するのはNGなのである。

週末の危機管理、つまり金曜日の夜から土曜日、日曜日の対応はBCP（事業継続計画）として考えるべきである。緊急体制表は作って対応しているが、時々、連絡体制に演習を行うべきであり、この際に発生する問題点を可視化しておくとよい。

5.インシデント対応の初動はシンプルに

インシデント対応の初動は、標準化が大切である。僕の場合、初動対応はテンプレートを使って、報告の標準化と、システムの「カルテ的なもの」を利用し、症状と対応の標準化を行った。また、勤務管理でも新人同士が組み合わさることがないようにしていた。

情シスのインシデント時は、原因追究ばかりに走ることだけは避けたい。可能な範囲で俯瞰的に見る人を決め、記録をしっかりとることをすすめる。情シスの中には原因追究にこだわる人が多く、職人気質で細かいところに注視しすぎて全体が見えなくなってしまうことがある。これでは本末転倒だ。大切なことは、業務を復旧するための正確な情報を一元化できるかどうかである。全体の復旧ができなくても、障害箇所のリスクを許容し、業務再開の判断を誰がするのかを決めておくことも大切である。

6.最後に

今回のコラムは、システムが安定的に稼働している陰には、多くの管理者や社員がバランスよく携わっているからであり、そのバランスが保たれるように務めることが大切という話を紹介した。

システム障害は、バランスが崩れ、「気の流れ」が変わった時に発生することが多く、あらかじめ想定しておくことも大切である。普段から少しの変化に対して、本当にこれでいいのか？　と自問自答をしてみる習慣を持つことが大切なのではないだろうか。

また、規則性のあることには対応を怠ってはいけないと思う。「あの時にやっていればよかった」という経験はたくさんしているが、「やっててよかった」という経験も数多くある。どうしたらいいか判断を求められた時は「少しやり過ぎる」ぐらいの対応がちょうどいいのである。