昨今のWebサービスでは、クラウドベンダーが提供しているパブリッククラウドをSaaS/PaaS/IaaS基盤として利用し、様々な外部システムと連携してサービスを提供することが当たり前になっています。
信頼性の高いサービスを提供するべく、SREとしては、基盤側のクラウドや外部システム側、あるいは通信キャリアなど、あらゆる場所で障害は起こり得るものとして向き合っていくことが不可欠であると考えています。
※ 以降、本記事では、クラウドベンダー側のSaaS/PaaS/IaaS、外部システム、通信キャリアのことをまとめて「基盤」、基盤で発生した障害を「基盤障害」と呼ぶことにします。
本記事ではB2B向けのSaaSを開発・運営する立場のSREとして、筆者が基盤障害とどのように向き合っているかについての心構えや取り組みをまとめておきます。
心構え
技術やプロセスの前に、障害が発生した時の対応に関する心構えが大事であると思います。
サービス提供者としては、サービスを利用するお客様の心情理解を前提とし、決して折れない心を持って最後まで対応する覚悟が必要です。
書籍「プロジェクトのトラブル解決大全」では、トラブル対応のファーストステップとして「腹をくくる」ことを挙げています。「自分は被害者だと思ったらそこで負け」であり、どんな形であれ、責任をもってクロージングまで向かうことが使命となります。
その観点で、クラウドベンダーが提供するIaaS/PaaS/SaaSと、それらのIaaS/PaaS/SaaSを利用する側には「責任分界点」という考え方があり、両者の間で、対策する責任範囲が境界線として分かれています。
ですがサービスを利用するお客様にとっては、責任分界点がどこにあるとか、責任範囲がどちらにあるかは関心のないものです。問題がどこにあったとしても、全て自分たちのサービスの一部と考えて取り組む必要があります。
検知
迅速な初期対応が信頼を生むと考え、そのために障害を正しく検知する必要があります。
自分たちの責任範囲であれば、SLI・SLOを設定し、外形監視・内部監視をしていると思います。一方で基盤側はいわばブラックボックスですので、同等の監視は難しいでしょう。落とし所として、筆者らのチームでは、自前の分散トレーシングの仕組みによって、間接的に基盤側の障害が検知できるように運用しています。
また、基盤のそれぞれについて、公式からの障害情報を確認するための手段はチーム全員が把握しておきましょう。サポート窓口への連絡先、サービス状況サイトへのアクセス方法、バグ管理システムへのアクセス方法などです。
メジャーなクラウドベンダーであれば、Downdetectorのようなサービスを使ったり、X（旧Twitter）などのSNSで同じような境遇に遭遇しているかどうかを確認することがよいでしょう。
ただ経験上、公式からのアナウンスが最速とは限らない、というよりも最速でないことが多いので、監視をしていて疑わしい兆候が見られれば、すぐに動き出せるように身構えておくことが必要でしょう。
状況把握
障害が検知された後は対応にあたることになります。障害対応はほとんどの場合、緊急性が高く、緊迫感のある状況となります。まずは深呼吸し、心を落ち着けてから、対応にあたりましょう。
状況把握では、SNSの情報だけを信用するのではなく、自分たちで正確に状況を把握しようと努める必要があります。基盤障害の場合は、障害が起きているリージョンやサービスが全体なのか一部なのかによって、影響範囲も変わります。
情報のソースがどこであれ、状況を共有するにあたり、発言した内容に関しての責任は自分たちになると思って、事実確認に努めましょう。
状況共有
タイムリーかつ定期的に進捗状況を共有することが重要です。原因が明確でなくとも「問題が発生していること」を早急に共有するようにします。
状況共有に゙関しては、お客様の知りたい情報から優先的に伝えるように意識します。よくありがちなのは、お客様の心情と、エンジニアチームから共有されてくる情報で、優先順にズレがあることです。
調べたことや分かっていることを断片的にかき集めて伝えるだけでは、お客様が知りたい情報とはなりません。
基盤障害においては、お客様の一番知りたい「いつ障害は解消されるのか？」に対して、適切に回答することが困難である場合がほとんどです。公式からアナウンスされている以上の情報を伝えることはできませんので、お客様の心理をケアし、誠実な謝罪と共に、「現在分かっていること」を確実に共有するようにします。
また状況共有の場として、サービスの稼働状況・ステータスを常日頃からステータスサイトとして公開しておくとよいでしょう。
この時、基盤障害の場合は、ステータスサイト自体も共倒れでダウンしてしまう可能性があるので、外部のサービスを利用するのがよいと思います。例えばAtlassian社の「Statuspage」やStatusPal社の「StatusPal」などがあります。こういったサービスには、障害報告やシステムメンテナンス告知の仕組みなども用意されていますし、「何かあった時にココを見ればよい」とお客様に認知してもらえれば、こちらから伝える前にお客様に障害情報の共有が可能になります。
リカバリプランの策定
書籍「システム障害対応の教科書」によれば、障害対応の目的は、システムを直すことではなく、ユーザーの業務影響を極小化し、早期に業務を復旧させることにあります。
基盤障害の場合、適切に手を打つことは難しく、筆者が関わってきたプロジェクトでも、基盤側の早期復旧を待つ以上のことはほとんどできていませんでした。。
フィーチャーフラグなどでうまく極小化・迂回できればよいのですが、それで対応可能な障害パターンはたかが知れていますし、究極的には依存している基盤ごと乗り換える手段もありますが、技術・コスト・政治・制約などの様々な事情で現実的でない場合もあるでしょう。
復旧後のフォローアップ
無事に基盤側が復旧した場合でも、提供しているサービス自体が完全に復旧したと言い切れるかどうかは別物であり、適切なフォローアップが重要です。
例えば以下のような観点で、復旧後速やかに報告できるように備えておくとよいでしょう。
- 障害中のデータはどうなっているのか？
- バッチが止まったままになっていないか？
- 事後対応としてなにか必要な操作はあるのか？
- SLAを公開している場合、補償はどうなっているのか？
また基盤側から原因・経緯・再発防止策などについて発表があった場合は、それらも速やかに共有するようにします。
おわりに
基盤障害はサービス提供者にとって避けては通れない事態ですが、その対応次第で信頼を失うか、むしろ信頼を深める機会になるかが決まると考えています。
安心してサービスをお使いいただけるよう、日々SREとしての障害対応のレベル向上に励んでいきましょう。
Discussion