#RAKUSMeetup©2021 RAKUS Co., Ltd.©2021 RAKUS Co., Ltd.チームとしての障害対応時間削減に向けて取り組んだこと株式会社ラクス インフラ開発部 西江 正義
View Slide
#RAKUSMeetup©2021 RAKUS Co., Ltd.自己紹介西江 正義（にしえ まさよし）■経歴 大手SIer、通信系ベンダにてインフラの構築・運用を 10数年経験後、2013年ラクス入社。 インフラ開発部にて、メールディーラー および チャットディーラー の運用チームリーダを担当。■趣味 旅行（※できるだけ携帯電話がつながらないところ）
#RAKUSMeetup©2021 RAKUS Co., Ltd.発表内容についてメールディーラーとチャットディーラーで合わせて1,000台近いサーバを運用していますが、それだけサーバがあると、様々な障害が発生します。中でも仮想基盤機器やネットワーク機器で障害が発生した場合は、影響範囲が大きくなりやすいため、主にそういったものに対し、どうすればチームとして迅速に対応できるようになるか？ということを考え、実践したことについて発表させていただきます。
#RAKUSMeetup©2021 RAKUS Co., Ltd.障害対応における問題の分析
#RAKUSMeetup©2021 RAKUS Co., Ltd.過去発生した障害について過去3年以内に発生した以下のような障害について分析した結果、ある問題が見えてきました。（※複数サーバに影響があったもの） ・仮想基盤用機器のダウン ・インターネット回線障害 ・DoS/DDoS攻撃 etc…
#RAKUSMeetup©2021 RAKUS Co., Ltd.問題とは・・・障害発生後、関係者への周知に時間がかかっている
#RAKUSMeetup©2021 RAKUS Co., Ltd.障害概要 影響範囲 原因 発生時間 復旧時間 周知時間仮想基盤用機器ダウン仮想サーバ32台で再起動が発生機器故障 19:41 19:47 20:23インターネット回線障害約800台のサーバに外部からアクセス不可他ユーザによる回線圧迫6:21 6:24 7:54DoS/DDoS攻撃不明(数十台～)外部からの攻撃15:47 16:03 不明(おそらく16:30頃)【障害例】6分 36分3分 90分16分※サービスは数分～十数分で復旧しているが、周知に数十分かかっている
#RAKUSMeetup©2021 RAKUS Co., Ltd.関係者への周知（情報共有）に時間がかかると何が問題か？
#RAKUSMeetup©2021 RAKUS Co., Ltd.・顧客からの問合せに対し、サポートが 何も回答することができない・上層部が何かしらの判断を行うにも、 状況がわからないと判断のしようがない・サービス復旧、事後対応に必要な他部署の 協力を得にくくなる（遅くなる）
#RAKUSMeetup©2021 RAKUS Co., Ltd.周知に時間がかかる要因は？
#RAKUSMeetup©2021 RAKUS Co., Ltd.・ 各自バラバラに対応して、ムダが生じている・ 第一報までの目標時間を定めていない・ 周知文に記載する内容を都度考えている・ 影響範囲特定に必要なアクションが不明瞭主な要因として、以下のようなものが挙げられる
#RAKUSMeetup©2021 RAKUS Co., Ltd.すなわち、「障害発生時における対応方針が決まっていない」ということが周知に時間がかかっている原因であるといえる。そのため今回、障害発生時の対応方針として「時間を意識してチームとして効率的に動く」という方針を定めた。
#RAKUSMeetup©2021 RAKUS Co., Ltd.前ページで定めた方針に沿って、それぞれの要因に対する対策を考えました。
#RAKUSMeetup©2021 RAKUS Co., Ltd.役割分担表の作成各自バラバラに対応しており、ムダが生じている要因対策【資料の一部抜粋（イメージ）】
#RAKUSMeetup©2021 RAKUS Co., Ltd.第一報、第二報以降の目標時間を定める周知を行う際の目標時間を定めていない要因対策アラート認知からの経過時間 目標値 備考第一報までの時間 15分以内障害発生時刻・復旧時刻（復旧している場合）・サービス影響を周知影響範囲特定までの時間 30分以内 単独サーバ障害は除くサービス復旧までの時間 30分以内
#RAKUSMeetup©2021 RAKUS Co., Ltd.周知文のフォーマットを用意する周知文に記載する内容を都度考えている要因対策【資料の一部抜粋（イメージ）】
#RAKUSMeetup©2021 RAKUS Co., Ltd.影響範囲特定方法をまとめる影響範囲特定に必要なアクションが不明瞭要因対策・ サービス影響があったサーバを特定するには、原則として 遠隔監視用サーバでアラート検知したものとする → アラート一覧画面からCSVファイルとして出力する
#RAKUSMeetup©2021 RAKUS Co., Ltd.まだこれで終わりではない
#RAKUSMeetup©2021 RAKUS Co., Ltd.せっかく対策を考えても、実際に障害が起こったときに、その対策に沿って動けなければ意味がないどうするんだっけ？※こうなってはいけない
#RAKUSMeetup©2021 RAKUS Co., Ltd.そのためには、普段からの訓練が重要 ⇒ 障害を想定したリハーサルを行う
#RAKUSMeetup©2021 RAKUS Co., Ltd.影響範囲 障害箇所 障害内容 （例）単体サーバ サーバ本体 サーバがディスクフルになった複数サーバスイッチ スイッチが故障したFirewall Firewallが故障した仮想基盤 仮想基盤用機器がダウンした以下のような障害が発生したと仮定した障害対応のリハーサルを行いました。実際に障害を起こすことが難しいものについては、該当機器に障害が発生した場合に検知すると思われるアラート一覧を事前に用意しておき、「こんなアラートを検知したとしたらどう対応するか？」 という形で実施しました。
#RAKUSMeetup©2021 RAKUS Co., Ltd.障害対応スプレッドシート・影響範囲調査・障害発生箇所調査・障害原因調査影響範囲特定手順・情報整理・関係者への情報共有周知文フォーマット・サービス復旧確認凡例：処理：利用資料・各メンバに対し、役割分担を行う・検証環境でアラートを発生させる役割分担表正常性確認手順各機器のステータス・ログ確認手順・復旧方法調査・復旧対応実施情報記入リハーサルの流れ（参考）
#RAKUSMeetup©2021 RAKUS Co., Ltd.その後、障害対応における周知までの時間はどうなったか？
#RAKUSMeetup©2021 RAKUS Co., Ltd.【結果】約半分の時間に短縮されました！ （42分 → 22分）2021/11/6(土) 22:12に仮想基盤を構成するノードの1台がダウンするという障害が発生しました。（これにより、仮想マシン38台で再起動が発生）このとき、アラート検知から関係者への情報共有にかかった時間は「22分」でした。 → 障害発生時刻、復旧時刻、対象、サービス影響内容、 この時点で想定される原因、について報告を行った。 ※ 前回、同様の障害が発生した際は「42分」かかっていました。 しかも、今回は、土曜日の夜という ”業務時間外” に 発生した障害。
#RAKUSMeetup©2021 RAKUS Co., Ltd.今後の改善予定
#RAKUSMeetup©2021 RAKUS Co., Ltd.● 各機器への疎通・ステータス確認、サーバの正常性確認の自動化 → jenkinsなどにあらかじめPingの実行先IPアドレスや HTTPS・SMTPのポート接続先アドレスを登録しておき、 ワンクリックで確認できるようにする。● アラート検知を契機とした自動復旧の仕組み作り → Zabbixでのアラート検知時に、自動的に処理が実行 されるようにする。 （例）サービス停止検知時、起動コマンドを自動発行する
#RAKUSMeetup©2021 RAKUS Co., Ltd.ご清聴ありがとうございました。
rakus_dev
yoshidashingo
wakamsha
.jpg){kind=avatar}
oshanqq
leveragestech
shibuiwilliam
fedepaol
h1kita
kojira
nwiizo
yokawasa
ufried
takasehideki
addyosmani
cromwellryan
morganepeng
holman
carmenintech
reverentgeek
kneath
hatefulcrawdad
wjessup
bluesmoon
aarron
lauravandoore