この記事はNikkei Advent Calendar 2021の20日目の記事です。

長期でシステムを運用していると様々なトラブルに遭遇します。 サーバー停止、潜在的なバグ、設定ミス、SaaSの障害...。 トラブル対応は腕が鳴るという人もいますが、気がつくといつも同じ人が対応していたりしないでしょうか。 もしその人に連絡がつかないとサービス復旧ができないという状況は健全ではないですし、チームとしての安心感も失ってしまいます。

少しでもこの状態を減らして障害対応できる人を増やせるよう、今回はチームで社内障害訓練をした話です。 システム障害訓練の参考になればと思います。

背景

チームのメンバーはどうしても少しずつ入れ替わりますが、システムはそれよりも長く稼働することが多いです。 システムの運用期間が長くなってくると、当初の運用や過去の障害内容などは 初期からいる一部のメンバーのみ知っている状況になり、新規で来たメンバーがすべてを把握するのは簡単ではありません。 特に障害対応は日常業務では触れないような操作が多いですし、一方でスピード対応も求められるため、事前準備なしでは手出しがなかなか難しいと思います。

問題時でも大丈夫なよう対応手順ドキュメントが用意されていたり、 過去の障害対応資料はまとまっているかもしれません。

しかし、

• 1度は参照したことがないと資料の場所がわからない→ないのと同じ
• あまり利用されていないと更新されない→今も使えるのかわからない

といった問題が発生します。

年末年始という長期休暇の前にこれらの課題解消をしておきたいということから 12/14にバックエンドチームで障害訓練を行いました。

チームで障害訓練は今年5月に続いて今回が2回目です。

実施方法

事前に実施日を決めて全員の時間を確保し、問題(シナリオ)を作っておきます。

当日の流れはこのような内容です。

• 参加者
  • バックエンドチームのメンバー全員(6人)
• 方式
  • リーダー(1人)が出題者となり、問題を次々にSlackに投稿
  • 他のメンバー(5人)はその内容を分担し、障害対応
• 時間
  • メンバー全員の3時間を丸々確保
  • 最初の2時間を競技、残りの1時間は振り返り・情報共有
• 内容
  • 開発系システムを中心にサーバを止めたりデータ変更をしたり
  • 過去の事例を元に影響範囲の集計報告
  • (シナリオは次章にて)

今回は2回目の障害訓練ということもあり、前回の反省として今回は以下の点を盛り込みました。

• 振り返りの時間を最初から用意した

決められた時間内で多数の障害に対応するため、メンバーは分散して別々の障害に対応をする流れになります。 その結果、前回は他のメンバーが何にどう対応したのか分からず終いになったという課題がありました。 記憶が新しく、熱の冷めないうちに情報共有するのが良いと考えて終了直後に振り返り時間を確保しました。

• どのように対応したかをスプレットシートにメモしてもらう

後から振り返るときに、当時の作業手順や思考内容を共有しやすいよう スプレットシートを事前に用意しました。

• あえて詳しくない人に問題を振る

新規で入ったメンバーがシステムの概要を理解するきっかけにするため、 「この障害対応はxxxさん以外で」と詳しい人が対応できない前提で対処する出題にしました。 訓練とはいえ、結局スピード優先で詳しい人が対応しがちです。 得意な人には別の問題や、あくまで補助としての対応にあたってもらいました。

シナリオ

障害訓練のポイントは、どのような障害シナリオを作るかです。 事前に実施背景となる課題への対応ができるような問題(シナリオ)を作る必要があります。

今回は

• 開発メンバーのみの参加で小規模
• バックエンドチームなので全員サーバ構成はある程度把握しており、手を動かせる

ということもあり、実際の作業に特化したエンジニア参加者中心の形で実施しました。

参考までに、大規模にやる場合は「出題者」「参加者」以外にも「上層部役・記者役」や「記録係」などを用意して

• 上層部への説明資料を用意
• 対応に掛かる想定時間と影響範囲から何を優先するか
• 指揮役の指示は適切だったか評価

といったマネジメント層の行動が重要になる構成も考えられます。

参加メンバーに合わせた構成で検討しましょう。

今回はエンジニア中心なので、調査と復旧作業を中心に問題を用意しました。 利用したシナリオ(の一部)は以下です。

13:00 説明
対象の環境は開発中心、出題・回答はSlack、作業内容はスプレットシートに記載することを伝える

13:00 サービスAのDBをこっそり止める
13:00 S3の記事画像を1枚こっそり消しておく(削除フラグ付与)

13:00 「手始めに、まずはi-xxxxxxxxxxxxxxxxのインスタンス名,IP,AZ,CPU使用率を教えて」
  * 開発系Elasticsearchクラスタの1台

13:05
  * 「上記ESのバージョンは?」
  * 「最後にyum updateしたのはいつになってる？」
  * 「最後アクセスがあったのはどこ? 誰から？」

15:05 
* 「serviceBのサーバの詳細教えて」
  * インスタンス名
  * IP,AZ
  * CPU使用率, メモリ使用率おしえてー
  * あとtopの値も貼っといてよ
  * メモリ使用率の履歴とか分かる？

13:05 serviceC の内部ドメイン(route53)をこっそり書き換える
  * (service-c.local -> service-caaaaaaaaa.local 誰かが打ち間違っちゃった想定)

13:20 突然たくさんくる質問(宿題)
  * 「test-2って誰が作ったやつかな？」
  * 「test-es7.16って消して良いんかな？」
  * 「開発のメール送信ログみたいっていう人がいるんやけど、簡単な手順書用意してもらえんかな？」
  * 「log4jの攻撃って今どれぐらい来てるんだっけ?わかる範囲で教えて」
  * 「N日前にあった障害で、サービスログアウトされてしまった人数を教えて」

13:30 気づかなかったら連絡
「serviceC落ちてるから対応よろしく(xxxさん以外で)」


13:30 気づかなかったら連絡
「serviceAの管理画面にアクセスするとやらた時間掛かるみたい」


13:30 serviceDのdockerプロセスを殺す
「serviceD落ちてるらしいで。。まあ多分俺が落としたんやけど、急ぎ直しといてー」

14:00 serviceC 強制復旧(時間かかりすぎると開発系といえど迷惑なので)
「こっちは思ったより時間かかってるんで直しといたわ」

14:00 開発系記事の画像がおかしいことを伝える
「このURLの記事画像が出ていないみたい」
  * 何時から？どれぐらい影響が出ている？
  * 原因は？
  * どうやって復旧させる？
  * キャッシュクリアはどうやる?

14:00 i-xxxxxxxxxxxxxxxx(最初に確認したやつ)をしれっと落とす

14:10 データ調査
「このURLの文章、何時にどこが変わったか調べて教えて」

14:20 serviceEをElasticbeanstalk環境ごと殺す
「ごめーん、なんかどれかのEB環境を消してしまったみたい。大丈夫かな...？てへぺろ」

14:30 梅崎の悪事でほか気づいてないことを探して

14:30 15時までに作業内容まとめて


---
問題が不足すれば以下も直してもらう

* 記事データのxxが欠損してそう。理由を調べて。
* デプロイが出来ないserviceF
* E2Eが失敗しているserviceG
* バッチが止まってしまった!
* ESのデータが消えてしまった!(※消してしまった)
* RDSが消えてしまった!
* lambdaを書き換えてしまった!

出題者側は当日このシナリオをベースに、参加者の対応速度を見て 問題数を調整しながら行動します。

実施してみて

実施後の振り返りで出たメンバーからの反応はこちらです。

• 前回と近い内容のものは覚えていてサクサク対応できた
• 復旧系はわかってきた。AWS特有の動きも予想できた。けど調査系は少し手間取った
• AWS知識不足、ドメイン知識不足、ログ検索系の慣れ不足を感じた
  • 障害訓練の復習を個人的にやったが、めちゃくちゃ良かった。操作方法や内容をちゃんと確認できた
• ログ分析は慣れていて動けた、一方アプリ側のオペは知らなかったことが分かった
• 有意義だった、開発が減っているので思い出しはいい機会。ログ分析系は不慣れなので復習したい

出題者側としても、今回本当にやってよかったです。

まず運用を見直す機会にななります。 ドキュメントとして不足している箇所や更新の洗い出しができますし、 開発系のE2Eテストを外していて気づけない障害もあったのでモニタリングの見直しにも繋がりました。

そして今回メンバー全員対応が非常に早かったです。 前回は一つの問題に囚われて手がつけられていない障害もありましたが、今回は出題内容を一通り解決されました。

もちろん前回の障害対応で慣れたというのもあると思います。

しかし今回の訓練が初めてとなるメンバーも、明らかに詰まって動けない時間が少なかったです。

これは、2回目のメンバーがサポートしながら進めることで 全員が初めてよりも相乗効果で解決スピードが上がったと考えています。

構成理解や問題箇所の特定までの過程を、言語化しつつ修正を加えられる人がいると 全員の対応力が大きく上がるのだと感じました。

また、私の当初想定以上に高い集計精度で報告書を用意してくれたものもありました。

得意な分野が複数にまたがると出来ることが広がるというのを今回本当に実感しました。

参考:社外イベント

社内でのイベントに限らず、外部のイベントに参加することで得られることもたくさんあります。

障害訓練に近いなと個人的に思うのは、

• セキュリティ堅牢化の競技会、Hardening Project
• Webサーバのチューニングバトル、ISUCON

です。

最初から社内での実施が難しい場合も、なにかしら外部のイベント参加から始めてみるのはおすすめです。

最後に

本記事では、バックエンドチームで実施した社内障害訓練について紹介しました。

障害対応に慣れた人が二倍になることで、解決可能な問題数や速度は数倍にもなります。

ぜひ、定期的に時間を取って実施してきましょう。