ニフティトップページの運用メンバーで障害対応ロールプレイングをやってみたよ！

2022.12.02Update

添野翔太

概要

この記事は、ニフティグループ Advent Calendar 2022 2日目の記事です。
こんにちは。ニフティトップページチームの添野、山田、佐々木、宮本、碇川、渡辺です。今回は共同執筆記事です。
ニフティで開催した障害対応ロールプレイングについてご紹介します。
障害対応ロールプレイングとは、「実際にシステムに障害が起こったことを想定し、擬似的な障害を起こすことで、実際の障害対応をスムーズに行えるようにしよう」というコンセプトでニフティで実施しているイベントです。

詳細内容

担当

開発サイド
- 障害対応：碇川
- 補佐兼議事録：佐々木
- 運営：添野、山田、宮本
企画サイド
- 関係者への障害告知：渡辺

ロールプレイングで扱った障害

今回の障害対応ロールプレイングで扱った障害について軽くご紹介します。
ニフティトップページでは、ログインしたユーザーのメールやニフティポイントなどの情報を表示しています。各サービスを回らなくても、ニフティトップページにログインするだけで手軽に確認することができてしまうなんて便利ですね！

しかし、そんな便利な機能が使えなくなると、ユーザーの方々に大変ご迷惑をおかけしてしまいます。できる限り問題が発生しないよう心がけ、ユニットテストなども実施して日々対策していますが、残念ながら障害とはいつか思わぬ原因で発生してしまうもの。そしていざ障害が発生したとき、あたふたしてしまうだけでは問題です。
ということで、今回のロールプレイングでは、ユーザーの皆様がよく使う新着メール通数の表示機能に障害を起こすことに決めました。重要な機能にあえて障害を起こすことで、いざというときスムーズに対応できるよう経験を積むことができます。
余談ですが、障害対応ロールプレイングのために、本番環境や開発環境からも完全に独立したロールプレイング専用の環境も用意しました。これなら憂いなく壊し放題です。もちろん、本番と同じアラートやサービス監視用ダッシュボードも完備しています。これなら完璧ですね。

障害！新着メール通数が表示されない！

ターゲットが決まったところで、次にどのように障害を発生させるかについてです。ニフティトップページで利用しているAPIは、どれもうっかり外部に公開しようものなら、第三者からの不正アクセスされ放題になってしまいます。これを防ぐため、複数の方法を組み合わせAPIへのアクセスを限定しています。
そして、認証もその仕組みの一つです。つまり、”うっかり運用ミスで認証情報を誤ったものに書き換えた”りすれば、それだけでAPIへのリクエストが失敗するようになり、障害が発生してしまいます。人間のうっかりミスで発生する障害……気をつけてはいても起こってしまいそうです。
障害の原因としてはあっさりしたものですが、もちろん実際の障害対応者にはいろいろと考えることがあります。単にニフティトップページ上の表示では、新着メール通数が表示されないだけです。APIからデータを取得していることを理解していても、どこで問題が発生しているのかはすぐにはわかりません。認証以外でも、たとえば以下のようないろいろな原因を考えることができます。

リファクタリングした際にAPIのリクエスト形式が変わってしまった
リクエスト先を開発環境のAPIにしてしまった
ニフティトップページ開発チームでは管理していないAPI側での障害
クラウドプラットフォーム自体の障害 etc.

アラートの種類や吐き出されるログ、監視用ダッシュボード、その他ドキュメントなども用いて、障害の原因を特定していきます。

ロールプレイングの流れ

当日は、事前に打ち合わせをしてお客様問い合わせから障害が発覚したというシナリオでスタートしました。

お問合せとほぼ同時にアラートも発生させています。ですが、実際の障害だと流石にアラートと同時にお問合せまでは発生しないため、もう少し実際の障害と近いような状況を設定する余地があったかもしれません。この辺りはよりリアルなロールプレイをするための反省点でした。
障害の発生を検知した時点で、開発チームが対応に当たります。ロールプレイでは事前に障害対応者と補佐兼議事録役は決めていたので、初動はスムーズです。

障害対応で行う作業について、議事録役がSlackに記録していく

しかし、ここでちょっとした問題が発生します。今回想定しているのは「メール通数が表示されない」という障害であり、データの大元を辿ればそれはトップ開発チームの管轄外のAPIです。そのため、もちろん原因としては大元のAPIに何かが発生したということも考えることができます。もちろん原因がトップページ側にある可能性もあり（今回はそのパターンです）、調査は行っていきますが並行してAPIを管理しているチームに問い合わせを行うのは自然なことだと思います。
が、そのことを完全にロールプレイングの運営側は失念してました……。運営3人いたのに、完全に、素で忘れていました。
そこで、急遽運営が一人外部のチーム役として、対応するようにしました。ロールプレイのシナリオを考える段階で、関係者としてどんな人が出てくるか？という考慮が漏れていると、せっかくの障害対応ロールプレイングもどんどん実際の障害と乖離してしまうため、注意が必要です。

こうして想定から漏れていた外部のチームとのやりとりも行いつつ、障害を解消しようと対応に当たっていただきました。単純な障害の解消以外にも、ユーザーの方に向けたお知らせのための正確な情報収集や、企画サイドとのリアルタイムな意思疎通など、なかなか普段の業務では行わない作業も多いです。
また、実際に障害調査を行う過程を経ることで、どのようなドキュメントが不足しているかについても浮き彫りになります。さらにドキュメントとして用意していても、いざというときまだシステムに不慣れなメンバーでもすぐに参照できる場所にあるか？といったこともわかります。とりあえず必要だからとドキュメントを用意しても、その存在自体が共有できていなかったり、わかりやすい場所になく探すために時間がかかってしまっては宝の持ち腐れになってしまいます。普段のシステム運用時から障害発生時の備えはしていますが、その備えが適切かという点について確認することができるのが良いところです。
ロールプレイの終了後には、運営から発生させた障害原因についての詳しい解説と、障害の特定方法についての解説を行いました。今回のロールプレイを通し見つかった問題点を改善しつつ、より安定したシステム運用を行えるようにしていけるようにしていこうと思います。

所感

ロールプレイの参加者と運営から所感を書いていただいています。

参加者目線

佐々木

今回は補佐兼議事録役として参加しました。
ロールプレイングでは一部サービスが動かないというケースの想定でしたが、ドメイン知識やシステム構成の知識が背景として求められるなと実感しました。すでにあるドキュメントやシステムを理解していないと直ぐに答えにはたどり着けないものもあるので、すぐに情報を得られるように普段からチームで整理しておくことも対策になると感じました。
最終解決までは至らなかったですが、今回のように役割分担を決めておくと実際の障害対応時には動きやすくなると思うので活かしていきたいと思います。

渡辺

企画側の立場で障害時の対応を把握するために開発と一緒に参加しました。対応するエンジニアがどれだけシステムを把握しているかで初動が変わってくるのがよくわかりました。全員で同じ知識を持つというのも、難しいことではありますが、みなさんに力を付けていただき、企画側はお客様への周知や関係者への情報提供に努め、不測の事態が起こっても障害に対処できる対応力をつけてゆければと思います。
定期的にこのような機会をもって、企画・開発メンバー全員で対応できるようにしようと思います。

碇川

今回私がメインで障害の対応を行ったのですが、自分が持っている情報だけではうまく解決できない点もあり、補佐役の佐々木さんには頼りきりになってしまったことが反省点です。この障害対応ロールプレイングでどのような立ち回りをすればよいかを理解することができたんじゃないかと思います。
今回得た知見や反省点を活かし、実際の障害時はメンバーとしてうまく立ち回っていきたいです。

運営目線

添野

今回は起こりうるシナリオを想定した上で、開催をしましたが、準備を進める中でも不足している情報がちらほらあり、見直す良いきっかけになりました。またロールプレイングの最中では、参加者の動き方を見て、障害への向き合い方が人それぞれだということを改めて感じました。実際の障害時や次回ロールプレイングを開催する際には今回得た知見を活かしていきたいと感じました。

宮本

普段はいかに安定してシステムを運用するかを考えていますが、「ロールプレイングとしてどんな障害を起こそうか？」というのを考えるのは正直結構楽しかったです。他にもいくつか対象とする障害の案が出ていたので、今後も色々試していきたいと思います。ぜひこの記事を読んでいる方々も、どんな障害が起こりそうか考えてみてください。
一方で、実施してはみたいものの、なかなかロールプレイングとして起こし辛い障害（クラウド自体の障害等）もあります。そうした障害にも対応していけるよう、日々対策は怠らないようにしていきたいです。

山田

ロールプレイング実施に当たっては「こう対応するだろうな」という想定シナリオを用意していましたが、実際はその通りに進まない部分が多く苦労しました。運営側は障害前後の状況などを現実に起こりうる形で作っていく必要があり、そのためには普段の運用をより広く理解していなければならないため、大変ですが学びが多かったとも思っています。
本番に近い形での障害を起こす、という部分でまだ再現が難しいものも多いため、カオスエンジニアリングツールなども取り入れて改善していきたいと思います。

まとめ

今回はニフティで開催した障害対応ロールプレイングについて紹介しました。
このように実際の障害対応を意識したチーム体制で動くことで、本番の対応でもスムーズに動ける対応力が身につきますし、「障害に強いシステムへの改善」という目線でも気づきを得るきっかけにつながると思います。

明日は、@takenokoroidさんのSvelteに関する記事です。
お楽しみに！