障害対応はユーザーとの信頼関係を構築できる機会という話
2024年の年の瀬、SRE（Site Reliability Engineering）の仕事のうち、障害対応を自分なりにユーザーを主語にして再考する。
注意書き
多くの会社でSREのJob titleで採用広報を行っており、それぞれの会社で定義や期待値が異なります。この記事は特定の会社でのベストプラクティスや意見ではなく、オープンなWeb開発業界におけるSREの仕事を私個人がSREとして再考するものであり、特定の会社に紐づく意見ではありません。
筆者について
Job Tile：Senior Software Engineer and SRE
Takaaki Kanetsuki: LinkedIn
- インフラ〜Webフロントエンドまで広く開発を行っている
- 軸足はバックエンドやインフラにあり、インシデントマネジメントを得意としており、新卒から今まで（今29歳）一貫してSREで言われるような仕事をしてきた。キャリア初期はSREという言葉がまだ一般的ではなく、インフラエンジニアだった。
- Github: https://github.com/3150
- SRE関連での最近の登壇
- Pager Duty Summit 2023
- Fastly Yamagoya 2023
- Datadog Summit Tokyo 2024
- etc....
SREの定義(Definition)
SREのロールはWikipediaによると、以下のように定義されている。
Site reliability engineers (SREs) are responsible for a combination of system availability, latency, performance, efficiency, change management, monitoring, emergency response, and capacity planning.
https://en.wikipedia.org/wiki/Site_reliability_engineering
ここで私が着目しているのはemergency response（≒障害対応やインシデントマネジメント）で、本記事ではそれらについての現状の業界での課題について掘り下げる。
課題提起
ここでは「業界の課題」という言葉の定義を「Webサービス開発の界隈でよく言われる話題（＝イベントでのテーマにもなるような話題）における課題」における課題とし、議論を進める。
SREの活動としてわかりやすいのは、以下が挙げられる：
- サーバーやDBの設計、運用
- パフォーマンスチューニング
- エラートラッキング
- SLO、SLA設計、運用 etc...
一方で、以下はあまりパブリックに知見が共有されることは少ないと感じている：
- 障害が起きた時の緊急対応についてのプラクティス
- エンジニアとしてどのように瞬時に検知し、K8sのPodをスケールさせるかなどのプラクティスはよく紹介されているが、一方で顧客対応も含めた知見などはあまり公開されているイメージがない。
- セキュリティインシデントだったらどうするか？
- 緊急度判断をどうするか？
- どのように顧客に障害を連絡して、説明を行うのか
- エンジニアとしてどのように瞬時に検知し、K8sのPodをスケールさせるかなどのプラクティスはよく紹介されているが、一方で顧客対応も含めた知見などはあまり公開されているイメージがない。
- 障害事後対応のプラクティス
- ポストモーテムの書き方
- 再発防止策や、顧客への説明
この課題感はIll-definedかつファクトに基づかない体感ベースでの課題であり、先行研究や取り組みの調査が行えていないので、ファクトになるものをご存じの方がおられたらお気軽にコメントや、ご指摘ください。
なぜ障害対応のナレッジが少ないのか
私個人としては、その理由に関して、以下の仮説を持っている
- 1分1秒争うような判断が特定の役職者（例えばCTO、CISO、VPoEなど）に属人化しており、現場のSREがそれらを判断して実行する機会が少ないので、実際の経験と知見を持っている人が少ない
- 例えば、サービス無停止の状態でDBのマイグレーションをミスってデータ不整合が起きてしまったというケースを考えると、そのままリクエストを受け続ければデータ不整合の範囲が広がっていくので、LB側で一旦全てのリクエストをメンテナンスモード画面に向けたり、DB側でWrite operationを全失敗させるようなことをする必要がある。
これらのオペレーションによりサービスが利用できなくなるが、データ不整合が広がるのを止められる。この1分1秒を争う状況において、事業・経営判断としてのリスクと被害拡大をうまく天秤にかけて即判断して実行するというのは、予めマニュアルにない限り、現場での判断だけでは難しそう
- 例えば、サービス無停止の状態でDBのマイグレーションをミスってデータ不整合が起きてしまったというケースを考えると、そのままリクエストを受け続ければデータ不整合の範囲が広がっていくので、LB側で一旦全てのリクエストをメンテナンスモード画面に向けたり、DB側でWrite operationを全失敗させるようなことをする必要がある。
- 障害対応はセンシティブな話題になりやすく、外部に積極的に発信するモチベーションがない & レピュテーションリスクが大きいので、情報が外に出しにくい
主語をユーザーにした障害対応
ここからは、障害対応についての個人的な思いや知見を述べる。繰り返しになりますが、あくまで個人としての意見であって、どこか特定の組織のルールや考え方ではない。
障害対応が起きると組織がパニックになったり、その障害が人為的ミスであれば、そのミスをした人は自責の念に駆られてしまうが、障害対応では主語をユーザー（サービスの利用者） にして動き続けることが大事である。
つまり、障害が起きると色々な社内の人に迷惑をかけていることの謝罪や、その障害が起きる状態にあったことの批判などが起きる場合もあるが、ユーザーから見ると非常にシンプルで、「サービスがいつ利用開始できるのか」「自分にどのような被害が出ているのか」 が関心ごとであり、提供者側の社内で謝罪をしてる・揉めてるなどは関係なく、いかに主語をユーザーにして障害対応に向けるかが鍵だと考える。
主語をユーザーとしたときに、障害が起きた時には以下を判断して伝える必要がある：
-
影響範囲調査をもとにした障害発生第一報
- どのような影響が起きているのかを、影響を受けるユーザーに対して、障害発生後なるべく早くアナウンスする
-
調査中のステータスの共有
- サービス提供者側でどのような調査を行っており、いつまでにサービスが復活する見込みなのか、もしくはしばらく復帰しないのかなどのアップデートを定期的に行う
-
障害対応完了共有
- 障害が治った後には、一定期間のモニタリング期間を経て、ユーザーに完治した旨をアナウンスする
- この際に、なるべく早く障害対応を終わったことにしたくて、治ってないのに不安定な状態な状態で障害対応完了報告（ステータスページの更新など）を行ってしまうと、再発した時にユーザーからの信頼が落ちてしまう
- 障害が治った後には、一定期間のモニタリング期間を経て、ユーザーに完治した旨をアナウンスする
-
ポストモーテムの投稿
- 障害度合いにおいて、ポストモーテムで障害の詳細や、 再発防止策のうち、実現可能な再発防止策を記載する
- 同じ障害を2回起こさないという観点で再発防止策を書く
- 再発防止策では「根本対応にはなるが、1年かかる」というものではなく、直後にすぐ（1-3週間くらい）で実行できて、かつ再発が防止できる対応を書く
- 再発防止策を講じるまでに再発してしまうのを防ぐため、なるべくコスパよく効く策を考える
- 障害度合いにおいて、ポストモーテムで障害の詳細や、 再発防止策のうち、実現可能な再発防止策を記載する
一般的にWebサービス、特にSaaSではCVC（Cost Per Action、顧客獲得コスト）やLTV（Life Time Value)、チャーンレートがマーケティングや事業指標で用いられているが、SREとしてもしっかりとユーザーに向き合い、信頼関係を構築することで、チャーンレートを下げることや、Up-sellに貢献し、LTVの向上、すなわち事業や会社の成長に大きく貢献できる。また、自社だけではなく、ユーザーとしてもそのサービスを使用することで事業が成長すれば、社会全体が少しずつ良くなるので、目の前のタスクベースの障害対応というよりも、もっとマクロな視点で考えると、障害対応をしっかりとやっていくモチベーションが個人としても、組織としても出てくるのではないかと考える。
障害対応で外部に情報を発信する意義
Webサービスを運営していると障害は不可避である以上、障害を起こさないことでユーザーとの信頼関係を築くというよりも、いかに障害対応で誠実な対応ができるか、ユーザー影響を最小限に抑えられるが鍵だと考えている。
上記で述べたそれぞれの意義は以下：
-
影響範囲調査をもとにした障害発生第一報
- ユーザー側が意図しない不具合に悩むよりも先に、ユーザーに障害が起きていることを伝えることで、ユーザーの貴重な時間を不具合への対応（うまく動かなくて調べたり）に費やさない状態にする
- 例えば、「17時に子どものお迎えに行くから16時からこの作業をやろう」と思って予定を組んでいる場合で、16時から作業を始めたのに、そのサービスがうまく動かなくて時間を浪費してしまうというケースはしばしば起こりうる。このケースにおいて、16時の段階でユーザー自身がサービスで障害が起きていることを認知できていれば、先に子供のお迎えに行き、その後障害が治った後から再度作業を再開することができる
-
調査中のステータスの共有
- 業務に不可欠なBtoBツールの場合、そのサービスが止まるとユーザーの作業も止まるということが起こり得る。この状況において、どういう影響が起きているのか、いつ治りそうなのかをユーザーに定期的に報告することは大きな意義がある
-
障害対応完了共有
- 障害対応が完了したことをユーザーが認知できる状況にしておくことで、上述のように作業が止まっていた人が自身の作業を再開できる
-
ポストモーテム
- 障害対応の中では、事後対応のポストモーテムをいかにユーザーに納得感のある形で書くかが鍵だと考える。というのも、障害が起きた時点でユーザーに迷惑をかけてしまっており、信頼感が下がっている中で、いかにそのポストモーテムで納得感のある内容が書けるかや、再発防止策に関して記述し「このサービスは今回は障害が起きたけど、ちゃんとしてるから使い続けても大丈夫だ」と思っていただけるかという点が重要
Datadogをフル活用した障害対応
Datadogを使い始めてもうおそらく6年くらい経ち、そこそこ長く使ってるユーザーだと思っているので、Datadogの最新の機能をフル活用した障害対応の手法を提案したい。
障害検知からポストモーテムまでDatadogで全部やる
今後やっていきたいと思っているが、まだ使えていない機能もあるので、2025年にやっていきたい構想
- DatadogのMonitoringやError Trackingでannomalyを検知する
- DatadogのOn-Call機能で対応者に通知する
先日のDatadog Summit Tokyoのカスタマーセッションの最後に「早く電話発信機能を作ってくださいw」という要望をあげたが、実は内部では開発が進んでいたらしい 🎉
https://docs.datadoghq.com/ja/service_management/on-call/ - DatadogでDeclare Incidentして、インシデント対応をキックする
この際に、asanaなどのステータスページツールと連携して、ステータスページアップをする
https://docs.datadoghq.com/ja/monitors/guide/integrate-monitors-with-statuspage/
https://docs.datadoghq.com/ja/service_management/incident_management/investigate/ - DatadogのIncident ManagementやNotebookに情報を集約して、そこの情報をSSOT（Single Source of Truth)にする
- 障害対応が終わった後にはDatadogでPostmortemを書く
Datadogの障害対応はとても勉強になる
以前起きたDatadogの大規模障害から早くももう2年弱が経とうとしているが、初動から事後対応までお手本のような障害対応で、ユーザーとして、この障害があってさらにDatadogに信頼を寄せたので、ぜひ最後に紹介をしたい。
この障害の際には、初動ですぐにステータスページが上がってきただけではなく、Postmortemも障害復帰後そこまで時間をおかずに、詳細な情報が公開された。また、これだけの障害であったのに、ログの欠損はなかったことも特筆される点である。
最後に
2024年の年の瀬ということで、障害対応について僭越ながら個人の思いをつらつらと執筆しました。障害対応は辛いものではなく、ユーザーからの信頼関係をより構築できる機会でもあるので、ぜひ障害対応を初動から事後対応までやり切って、しっかりとユーザーに価値提供をしていきましょう 🤝
長い年末年始の休暇中にどうぞ
Google - Site Reliability Engineering
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム
SREの探求 ―様々な企業におけるサイトリライアビリティエンジニア
Discussion