はじめに
こんにちは。cappy_potterです。
MailDealer と ChatDeaeler という弊社サービスのインフラ運用チームのリーダを担当しています。
現状、これら2サービスで稼働しているサーバの数は、合計で1,000台近くありますが、
これだけサーバがあると、様々な障害も発生します。
中でも、仮想基盤機器やネットワーク機器で障害が発生した場合は、影響範囲が大きくなりやすいです。
主にそういったものに対し、「どうすればチームとして迅速に対応できるようになるか？」ということを考え、実践したことについて紹介したいと思います。
過去発生した障害について
過去に発生した、『複数サーバに影響があった障害』について分析した結果、
「障害発生時、関係者への周知に時間がかかっている」という課題が見えてきました。
【障害例】
| 障害概要 | 影響範囲 | 原因 | 発生時刻 | 復旧時刻 | 周知時刻 |
|---|---|---|---|---|---|
| 仮想基盤機器ダウン | 仮想サーバ32台で再起動発生 | 機器故障 | 19:41 | 19:47 | 20:23 |
| インターネット回線障害 | 約800台のサーバに外部からアクセス不可 | 他ユーザによる回線圧迫 | 6:21 | 6:24 | 7:54 |
| DoS/DDoS攻撃 | 不明 | 外部からの攻撃 | 15:47 | 16:03 | 不明 |
※サービスは数分～十数分で復旧しているのに、周知に数十分かかっている
また、関係者への周知（情報共有）に時間がかかると、以下のような問題が発生します。
・顧客からの問合せに対し、サポートが何も回答することができない
・上層部が何かしらの判断を行うにも、状況がわからないと判断のしようがない
・サービス復旧、事後対応に必要な他部署の協力を得にくくなる（遅くなる）
周知に時間がかかる要因
主な要因として、以下のようなものが挙げられます。
・各自バラバラに対応していて、ムダが生じている
・第一報までの目標時間を定めていない
・周知文に記載する内容を都度考えている
・影響範囲特定に必要なアクションが不明瞭
すなわち、「障害発生時における対応方針が決まっていない」ということが
周知に時間を要している原因であるといえます。
そのため今回、障害発生時の対応方針として、「時間を意識して、チームとして効率的に動く」
という方針を定め、それぞれの要因に対する対策を考えました。
各要因への対策
要因①：各自バラバラに対応していて、ムダが生じている
⇒対策①：役割分担表を作成し、障害時には、まず、誰が何をするのか決めて、かぶらないようにする
■資料の一部抜粋（イメージ）
要因②：周知を行う際の目標時間を定めていない
⇒対策②：第一報、第二報以降の目標時間を定め、各自がそれに向けて動く
| アラート認知からの経過時間 | 目標値 | 備考 |
|---|---|---|
| 第一報までの時間 | 15分以内 | 障害発生時刻・復旧時刻（復旧している場合）・サービス影響を周知 |
| 影響範囲特定までの時間 | 30分以内 | 単独サーバ障害は除く |
| サービス復旧までの時間 | 30分以内 |
要因③：周知文に記載する内容を都度考えている
⇒対策③：周知文のフォーマットを用意しておき、必要事項を入力するだけで良いようにしておく
■資料の一部抜粋（イメージ）
要因④：影響範囲特定に必要なアクションが不明瞭
⇒対策④：影響範があったサーバの特定方法を定義しておき、迷わないようにする
弊社の環境では、監視用のサーバが複数あり、それぞれ監視している範囲が異なりますが、サービスに影響が
あったかどうかの判別については、原則として、 遠隔監視用サーバでアラート検知したものとする、と定めました。
また、一覧の出力方法も手順としてまとめました。
障害対応リハーサルについて
前項までで、障害発生時における周知時間を短縮化するための対策を行いましたが、これだけではまだ不十分です。
すなわち、各自がこれらの対策内容を「頭で理解するだけでなく、体で覚えておかないと」
実際に障害が起こったときに、何をしてよいかわからず、スムーズに動けないことが想定されるからです。
そのためには、障害が発生したと仮定した「障害対応リハーサル」を行い、各自に手を動かして
もらうことにより、何をすればよいかを体得してもらうことにしました。
【リハーサルパターン】
| 影響範囲 | 障害箇所 | 障害内容 （例） |
|---|---|---|
| 単体サーバ | サーバ本体 | サーバがディスクフルになった |
| 複数サーバ | スイッチ | スイッチが故障した |
| 複数サーバ | Firewall | Firewallが故障した |
| 複数サーバ | 仮想基盤 | 仮想基盤用機器がダウンした |
※実際に障害を起こすことが難しいものについては、該当機器に障害が発生した場合に検知すると思われる
アラート一覧を事前に用意しておき、「こんなアラートを検知したとしたらどう対応するか？」 という形で
実施しました。
リハーサルの流れ
リハーサルについては、前項に記載したリハーサルパターンの障害が起こったと仮定して
下図の流れに沿って、メンバ数名で対応するということを何回か繰り返しました。
その後について
リハーサル実施後、しばらくして土曜日の夜22時過ぎに、仮想基盤を構成するノードの1台が
ダウンするという障害が発生しました。
このとき、アラート検知から関係者への情報共有にかかった時間は「22分」でしたが、以前同様の障害が
起こったときには、「42分」の時間がかかっていましたので、およそ半分に短縮されています。
土曜日の夜という “業務時間外” に発生した障害であるということを考えると、及第点ではないかと思います。
今後の改善予定
今後、さらに周知時間を短縮するおよび、障害からのサービス復旧を早めるための取り組みとして、
以下のようなことを行う予定です。
●各機器への疎通・ステータス確認、サーバの正常性確認の自動化
→ jenkinsなどにあらかじめPingの実行先IPアドレスやHTTPS・SMTPのポート接続先アドレスを
登録しておき、ワンクリックで確認できるようにする。
●アラート検知を契機とした自動復旧の仕組み作り
→ Zabbixでのアラート検知時に、自動的に処理が実行されるようにする。
（例）サービス停止検知時、起動コマンドを自動発行する
以上、最後までお読みいただきありがとうございました。
なお、以下資料にも内容をまとめております。
是非ご参考ください。
speakerdeck.com
◆ 関連ブログのご案内
本内容は、「【Meetup】大規模SaaSを支えるインフラ組織の取り組み／自動化、障害対応マニュアル、CI/CD、SRE」でも発表させていただきました。
他発表については、以下ブログにまとめておりますので是非ご確認ください。
tech-blog.rakus.co.jp
エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
ご興味ありましたら是非ご確認をお願いします。
https://career-recruit.rakus.co.jp/career_engineer/カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
rakus.hubspotpagebuilder.comイベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com
