はじめに
こんにちわ。cappy_potterです。
MailDealer と ChatDeaeler という弊社サービスのインフラ運用チームのリーダを担当しています。
前回、こちらの記事で、『チームとして障害対応時間削減に向けて取り組んだこと』について
紹介させていただきました。
その際、記事の中で、取り組み実施後に同様の障害が発生したことについて触れ、取り組み実施前に比べて
関係者への情報共有の時間をおよそ半分にできたと記載しました。
(以前は同様の障害で「42分」かかっていたものが、「22分」に短縮できた。)
あれからさらに半年が経過したところで、再度大きな障害が発生したのですが、今回については
効果的に動くことができず、サービス復旧までに多大な時間を要してしまいました。
(関係者への情報共有についても、障害発生から「30分」かかってしまいました。)
なぜ今回の障害については迅速に動くことができなかったのか?ということと、今後どうすればよいのか
ということについて、チーム内で振り返りを行った結果を中心にお話させていただきたいと思います。
発生した障害の内容について
平日の朝8時前に、外部からのDDoS攻撃を防御するためのセキュリティ機器が
突如誤作動を起こし、正常な通信をブロックしてしまうという事象が発生しました。
これにより、弊社がサービス提供を行っている多数のサーバについて、外部からアクセスしづらい
状態が発生してしまいました。
また、このような状況が起こっているということを把握し、サービス復旧のための対処を
行うまでに「86分」という時間を要してしまいました。
※サービス復旧の方法としては、誤作動を起こしていたDDoS対策用機器の電源を落とし、
異常なブロックが発生しないようにする、というものでした。
対応に時間がかかった要因
以前、障害対応時間削減のための取り組みを実施し、実際、その後に発生した同様の障害に
ついては、比較的迅速に対応できていたのですが、なぜ今回は時間を要してしまったのか、
チーム内で振り返りを行いました。
その結果、以下のようなことが要因として挙げられました。
①現状、どこまで対応が進んでいるのか、把握しづらい状況だった
∟ 誰が何をしているのか、あと何の対応をしなければいけないのか、よくわからない状態だった。
∟ 後から対応に参加した人が現状を把握できない状態だった。
②アラート検知しているサーバの共通項の絞込みに時間がかかり、障害箇所の特定に時間がかかった
∟ どの仮想基盤上で稼働しているか、どのネットワーク機器を経由しているか、など。
③コミュニケーションツール(Zoom)の準備が遅かった
∟ 障害発生の時間が、出勤前・出勤中の時間帯(平日の朝8時前)であったことから、
まずはチャットベースでやり取りを開始しており、そのままの流れでずっと対応してしまっていた。
(テキストベースのツールだと、やり取りに時間がかかる)
④障害対応の司令塔が情報共有・報告者を兼ねていて、メンバへの指示が後手後手になっていた。
∟司令塔自身が、関係者への情報共有のための文章を考え、入力するのに時間を取られていた。
⑤他部署の関係者が障害対応メンバの手を止めてしまっていた
∟ 情報共有が適切にできていなかったため、他部署の関係者が障害対応を行っているメンバに対して
直接状況確認を行おうとて、対応の手を一時的に止めてしまう状況が発生していた。
⑥役割分担の際、2人に対して同じ役割を分担したことにより、混乱が生じてしまった
∟ 役割としては、ざっくりとしたものになっているため、具体的な実施内容については
2人で相談した上で進めてほしかったが、うまくいかなかった。
⑦指示されたことと異なる対応を行っている者がいた
∟ 似たような役割(「障害発生箇所調査」と「影響範囲調査」)があることにより、
見間違えが発生していた。
要因への対策
前項にて、対応に時間がかかった要因の洗い出しを行いましたが、全てに対応しようとすると
対策実施までに時間がかかりそうなため、ポイントを絞って対応することとします。
具体的には、要因①②に対し、以下のように対応する予定です。
なお、以下の対策を実施することにより、要因④~⑦についても、いくぶん改善できると
見込んでいます。
【要因①への対策】
・具体的にやるべきこと、確認すべきことなどを箇条書きにしたリストを作成する。
∟ 基本的に、上から順に実施していくものとする。
∟ リストには「対応者」欄、「実施状況」欄を設け、リアルタイムに更新していく。
∟ リストはスプレッドシートで作成することにより、複数人での同時編集を可能とする。
∟ 障害対応開始時、まずこのリストを関係者で共有する。
(これを見れば、どこまで進んでいるのかがわかるようにする。)
・調査結果の保存場所も、上記リストに記載しておくことにより、調査結果(ログなど)を
どこに格納するかを迷う時間や、パスを共有する時間を削減する。
【要因②への対策】
・現状、各サーバごとのOSやミドルウェアのバージョン、IPアドレス等の情報を管理するための
データベースがあるため、「どの仮想基盤上で稼働しているか」「どのネットワーク機器を
経由しているか」などの情報を記載するための項目を追加し、絞込みが行えるようにする。
∟ これにより、障害発生箇所の推測を早める。
※上記データベースは、弊社の 楽楽販売 を利用しています。
その他の対応について
前回の記事の中で、サービス復旧を早めるための取り組みとして、以下の2点について
実施予定であると記載しましたが、こちらの状況について報告します。
●各機器への疎通・ステータス確認、サーバの正常性確認の自動化
→ 弊社で稼動中のjenkinsサーバにて、あらかじめ以下を登録しておき、ワンクリックで
確認できるようにしました。
・主要機器に対するPing疎通確認用ジョブ
・Firewallのログ確認用ジョブ(エラーログ確認用)
・スイッチのステータス確認用ジョブ
・サービス提供用サーバのWeb管理画面ログインテスト用ジョブ
●アラート検知を契機とした自動復旧の仕組み作り
→ 一部のサーバについて、Zabbixサーバでサービス停止を検知した際に自動的に
サービス再起動コマンドが実行されるようにしました。
以上、最後までお読みいただき、ありがとうございました。
エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております!
ご興味ありましたら是非ご確認をお願いします。
https://career-recruit.rakus.co.jp/career_engineer/
カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
rakus.hubspotpagebuilder.com
ラクスDevelopers登録フォーム
https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/
イベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください!
◆TECH PLAY
techplay.jp
◆connpass
rakus.connpass.com