スタディストにおける障害対応の実践と今後の展望
本記事はスタディスト Advent Calendar 3日目の投稿です。@katsuhisa__がお送りします。
先日、SRE meetup at Fukuoka vol.3というイベントで、「チームで取り組む障害対応 / Incident response as a team」というテーマで登壇をしてきました。
本記事では、ミートアップ当日に現地で話した内容をあらためて振り返るとともに、当日話せなかった内容についての捕捉を行います。
Agenda
- スタディストにおける障害対応の歴史
- 障害対応できる仲間を増やすための活動
- チームで障害対応の品質を維持向上するための仕組み
- 障害と向き合う文化の醸成
- 今後の展望
スタディストにおける障害対応の歴史
私が入社した頃は、CTOを除くとWebエンジニア（サーバーサイドとフロントエンドの開発を担当）は1人しかいませんでした。当時の障害対応は個人プレーが中心で、障害対応について科学されている領域はほぼなかったと記憶しています。一方で、開発に関わる人数が少なかったこともあり、各人がプロダクトにおける仕様や実装を比較的広く把握しており、「障害対応＝問題が起きれば、気づいた人がなおす」というシンプルな運用が成立しやすい状況でした。
しかし、その後、チームに仲間が増えるにつれ「障害対応のスケールしづらさ」を実感することになります。それは、次のような要因によるものです。
- 新しく入ってきた人が、システムのアーキテクチャを把握することには時間がかかる
- アーキテクチャについて包括的に教えることをしておらず、疑問発生の都度、人対人でのキャッチアップを行っていた（そして、それは非効率だった）
- ドキュメントが不足しており、効率よくシステムの全体像を自習できるようになっていない
- 過去の障害対応の知見が蓄積されておらず、障害発生時の対処が職人技に
- パフォーマンス改善やシステム改修により障害発生頻度が低下していたことにより、障害対応の実践機会を十分に提供できない
スタディストの開発チームは、今でこそ業務にはやく馴染むためのオンボーディングプロセスが整備されていますが、当時はそのようなプロセスは準備されていませんでした。
これらの問題とどう向き合ってきたか / 今後やろうとしているかについて具体的に解説します。
障害対応できる仲間を増やすための活動
先ほどご紹介したオンボーディングプロセスの中で、障害対応できる仲間を増やすための取り組みを重点的に行っています。具体的には次のようなものです。
- アーキテクチャ詳細解説
システムで利用しているコンポーネントを解説するだけでなく、障害を引き起こすトリガーとなりやすいリリースプロセスについての理解や、障害把握のためのモニタリングシステムの全体像の把握にも時間を多く割いています。
- ドメイン理解（Teachme Bizの機能説明会に参加）
どの機能がサービスにとって、よりミッションクリティカルなのか？を
肌感覚で知ってもらう。そうすることで、障害時の影響範囲をよりユーザー目線で想像できることを目指します。
- サービス構築
AWSアカウントだけを与え、既存システムをゼロからつくってもらう。システム全体がどのように構築されているかを深く知ることは、障害時の原因切り分けに必要な知識だと感じています。
- Postmortem reading
過去の障害事例から、システムがどのように動作するかを知ってもらう。また、どのようなオペレーションで対応したかに理解を深めることで、同様の問題が発生した際の対応能力を養う。
チームで障害対応の品質を維持向上するための仕組み
当然のように聞こえるかもしれませんが、障害を認識するためには、何が障害か？を理解している必要があります。しかし、その基準は、時に各人の判断がブレるものです。障害対応の優先度判断となると、なおさらです。
また、障害発生直後の初期対応も標準化が望ましいことが分かりました。エスカレーションを優先する人もいれば、原因究明〜修正のリリース作業まで一気に終わらせようとする人もいるようでは、障害対応を “チームで” 行っているとは言えません。これでは、以前と同じく個人プレーです。
そこで、これらの問題に対処するため、スタディストでは次のようなドキュメントを整備し、各人の判断や初期行動がブレにくくするための標準化を心がけています。
- Severity Levels
障害優先度を判断するためのドキュメントで、障害Levelごとの初期行動を規定しています（Levelの数字が小さいほど優先度高）。Level 2よりも優先度の低いレベルでは、チケットをBacklogに積むだけにするなど、すぐに障害対応から離れられるようにしてあります。アラートのオオカミ少年化問題と同様、すべての障害を最優先で取り扱うとチームは疲弊するからです。
- Incident Response Run Book
Severity Level 1, 2 の時の初期行動を具体的に記述したドキュメント。初期行動や確認すべきダッシュボード、連絡フローを詳細に記載しています。
- Security Incident Response Run Book
セキュリティインシデント発生時は、「Incident Response Run Book」からさらに専用のRun Bookに分岐します。システムの性能面でのインシデントと、セキュリティインシデントでは行う対応プロセスがまったく異なるためです。
ここでは、どんなドキュメントを整備しているか？について紹介しましたが、ドキュメントが存在すること≠ドキュメントに基づいた運用が確実に行われていることだと考えています。そのため、ドキュメントに沿った行動をするためのトレーニングやドキュメントの読み合わせを行うことで、ドキュメントを真に活用することができると感じています。
障害と向き合う文化の醸成
大規模な障害は、機嫌よく開発しているチームに対し、大きなショックを与えうるものだと理解しています。そのため、発生した時にだけ障害と向き合うのではなく、チームとして日頃から継続的に意識を傾けることが望ましいと感じます。スタディストにおける障害と向き合う文化に関する取り組みをここでは2つご紹介します。
- SLI定点観測
スタディストが開発・提供するTeachme Bizでは、チームでSLOを定義し、運用しています。SLOやSLIの概要については、手前味噌で恐縮ですが、私のCode Zineでの連載をご参照ください。
スタディストでは、週次でSLI定点観測の時間を設け、チームでSLIの推移を確認しています。エラーレートやレイテンシの傾向を確認するこで、開発者が性能に対して意識を向けるべきなのか？そうでないのか？を判断します。SREの考え方では、SLOを達成できているのであれば、機能開発を優先します。そうすることで、必要以上に性能面の問題に向き合うことを避け、チームの攻めと守りのバランスを維持することができます。
週次で定点観測を行っていると書きましたが、エラーバジェットを急激に消費する問題の発生時は、迅速にアラートが上がるようにモニタリングシステムが構築されています。週次定点観測した際に、はじめて「あれ、今週めっちゃエラー多かったね・・・」となるようでは、時すでに遅しです。
- リリース頻度や方法に対するチームでの継続的なカイゼン
多くの会社で、リリース作業（またはそれに付随するシステム変更作業）は障害を引き起こすトリガーの上位に入っているのではないでしょうか。
では、障害のトリガーとなりうるリリース作業は悪なのでしょうか？リリース回数をできるだけ減らすことが望ましいのでしょうか？…そんなことはありません。リリース頻度が高い組織ほどパフォーマンスが優れていることは書籍『LeanとDevOpsの科学』で触れられていることでも有名です。
つまり、「リリース頻度を高めつつ、障害発生頻度の極小化」を目指すことが私たちにとって求められる姿勢です。スタディスト開発チームでは、過去に、リリース頻度に関して問題意識のあるメンバーの発案をきっかけとし「リリースサイクルと開発スタイル」に関する意識統一の話し合いが行われました。現在も「リリース頻度を高めつつ、障害発生頻度の極小化」を目指す道半ばではありますが、少なくとも今のスタディスト開発チームには「障害を起こさないためにリリース頻度を減らしさえすればよい」と考えるメンバーはいません。こういった文化の1つ1つがユーザー価値の最大化につながると考えています。
今後の展望
最後に、今後の展望について一部をご紹介します。
- Failure Fridays
Failure Fridays は、 PagerDuty で行われている障害投入演習の取り組みです。スタディストでは、DBに問題が発生したことを想定したリストア試験などは行っていますが、一方で、日々の障害発生時を想定した演習はまだ実施できていません。
- Playing time-bound simulation games
『The Site Reliability Workbook』の「Incident Response」の章で推奨されている取り組みです。インシデント対応のtime-boundである側面を演習するために、シミュレーションゲームに取り組むというものです。『The Site Reliability Workbook』では、「Keep Talking and Nobody Explodes」というゲームが紹介されており、これはSwitchでプレーできます！（業務時間中にゲームしたいわけではないですよ！）
- PagerDuty の導入
現在、スタディストの障害対応時の通知や連絡フローは仕組み化されておらず、口頭やSlackでのやり取りを通じて行われています。現在は、それでもさほど困ってはいないのですが、今後チームが大きくなった際に、お見合い状態になることを防いだり、エスカレーションの仕組みを効率化するためにPagerDutyのようなツールを導入したいと考えています。
以上で、私たちが行っている障害対応に関する取り組みの紹介を終わります。ミートアップ当日は、発表終了後に福岡のSREの皆さんと障害対応について話すことができ、たいへん満足しています。今後も国内外問わず、障害対応やSREに関する様々な勉強会に参加したいです！お誘いお待ちしております！
We are hiring!
最後は、お決まりですが、私たちのチームで一緒に活動してくれる仲間を募集しています :+1: 「障害対応なら俺に任せろーーー！」という方、ぜひ一緒に働きましょう！
