DMM.comの、一番深くておもしろいトコロ。

【SRE】サービス稼働率Downを防ぐ!『Disaster in recovery training』というアプローチ方法について

【SRE】サービス稼働率Downを防ぐ!『Disaster in recovery training』というアプローチ方法について

はじめに

こんにちは、プラットフォーム事業本部の石垣雅人(@i35_267)です。
現在は、DMM.comのサービスで利用される基盤システムの開発チームでプロダクトオーナーをしております。

今回は、ローンチしたサービスをチームで運用していく際に、必ず直面するであろう「障害」への向き合い方についてのSREの観点で事例を紹介します。

目次

起因

どの開発チームでも日々、ローンチしたサービスの稼働率を落とさないために様々な障害対策を行っていると思います。
CIツールの導入によってリリース作業を自動化してリリースミスを防いだり、自動テストでプロダクト品質を担保したりなど。

しかし、いくら起こさないようにしても障害は起こってしまうものです。
つまり、稼働率100%をずっと続けるのはとても難しいものです。

では、そうした場合どうすればいいのかと考えて、たどり着いた結論があります。
f:id:ishigaki-masato:20180802150559p:plain:w500

それは、障害を起こさないのではなく、障害が起こった時に『いかに早く復旧するか』に力を入れるということです。
別な言い方をすれば、
『障害』というものをユーザーに気づかせる前にこちらが気づいて、復旧してしまえばそれは障害にならない。
ということです。

Disaster in recovery trainingとは?

では、復旧を早めるためにはどうすれば良いのでしょうか。
もちろん、システムのブラックボックス・ホワイトボックスともにモニタリングを強化して、異常を検知すればすぐに通知するなどの対策も思いつきます。ただ、障害に対してチームで対応することを考えると、まずは全体を通して
『チームとして障害対応する時にどこが弱いか、チームとしてどこに問題があるか』を可視化するべきです。

そして、そこで最適になるのが、『Disaster in recovery training』というアプローチ方法、つまり、障害訓練です。
f:id:ishigaki-masato:20180729173335p:plain:w500
仮の障害シナリオを作成し、実際のサービス環境をCOPYした環境(Stress環境などがオススメです)に対して障害起こします。それをどう復旧するかを訓練するといったプログラムです。


効果としては下記を仮説としていました。
f:id:ishigaki-masato:20180802174408p:plain:w500

Disaster in recovery trainingの実施方法

Disaster in recovery trainingを実施するには、3つのステップを踏む踏む必要があります。
f:id:ishigaki-masato:20180729174301p:plain:w500

実施前 : シナリオ作成

まず、障害となるシナリオを作成します。これは当日まで障害対応者には秘密です。シナリオのイメージとしては、たとえば下記のようなものです。
f:id:ishigaki-masato:20180729174542p:plain:w500
注意点として、作成したシナリオが実際の環境に対して当日に障害を起こせるかを十分に確かめておきましょう。

実施中 : 対応プロセスを記録する

f:id:ishigaki-masato:20180729174834p:plain:w500
障害シナリオをもとに障害訓練を実施中は、チームがどういった動きをしているかを必ず記録していってください。
この記録から障害に対してどういった問題点があるかを明らかにしていきます。
たとえば、下記のようなやり取りがあったとします。
f:id:ishigaki-masato:20180729175833p:plain:w500
上記のようなプロセスを取ることで、下記の問題点が可視化されます。

★Aさん、Cさんによる単独的な行動が可視化され報連相の粒度・質・タイミングの改善ポイントが見える。

上の場合は、まずインシデント対応者のリーダーであるBさんが状況を詳細に把握して体制を組むべきと考えます。それから人的リソースがどのくらい必要になるのかを判断し、適切にインシデント対応者をアサイン、原因追求の分担を行うような流れが良いと考えます。

実施後 : 振り返り

障害が無事復旧したら、チームで振り返りを行います。
オススメのやり方は下の2つです。
①対応プロセスの読み合わせ
②KPT
f:id:ishigaki-masato:20180729180830p:plain:w500
対応プロセスの読み合わせを行うことでいろいろな問題点が浮かび上がってくると思うので、それを次のTryへと結びつけていくといったイメージです。

まとめ

Disaster in recovery trainingの実施までの流れを抑えてきました。
自チームでは、約6回行ってきた結果は下記となりました。
f:id:ishigaki-masato:20180730140735p:plain

もちろん、障害シナリオの難易度によって復旧時間に変動はありますが、おおよそ復旧時間が短縮へと向かいました。実際の効果として主に学習できたと感じ部分は以下の2点です。

① 報連相の重要性
チームとして障害に対して向かい合うには、メンバー単独行動は危険です。障害対応こそチームワークを大事にし、自分が何をしていて何をするべきなのかをリアルタイムでチーム全員に相談しながら復旧対応にあたることが次第に徹底されてきました。

② 一時復旧の重要性
どうしても復旧作業に集中するとユーザーへの配慮が抜けがちになります。
障害が起こった時に最初に目指すべきは一時復旧です。 一時復旧でユーザがサービスを使えるようにされできれば、あとはゆっくり残作業を行えば良いのです。そこをチームとして理解し、目指せるようになったことは大きな成果だと感じています。

今回は、障害への向き合い方として『Disaster in recovery training』というアプローチ方法を紹介させていただきました。 ぜひ、皆さんのチームでも試してみてください。

おわりに〜メンバー募集

最後に採用情報を紹介させてください。
私がプロダクトオーナーを務めるプラットフォーム事業本部 Customer Decision Support Teamでは、一緒に働いてくれる仲間を探しています。 2018年7月に立ち上げたチームでまだまだポテンシャルを秘めたチームです。
少しでもご興味のある方はぜひご応募ください!

dmm-corp.com