こんにちは！BASE株式会社 上級執行役員の藤川です。今年からTech DepartmentというBASE社の開発の成功や情報システム、セキュリティ等に責任を持つチームを運営しています。
システム障害はWebサービスを自社運用する企業にとって最重要な問題であり、サービス改善のきっかけになることも多々あります。ただ単に目の前の問題を場当たり的に解決するだけでなく、再現性を減らすために体制やシステム投資の見直しなどにもつながるきっかけになるものなので、そこで起きている本質的、潜在的な課題を見つけ出すことも障害対応の重要なミッションです。
また事件は現場で起きているわけで、障害要因となるものは、何もバグやシステム設定の不足や不備などに基づくものだけではありません。インターネットの世界が日常的に変化しているので、外乱としての障害要因も多々存在し、これらの問題と常に戦っています。
そういう不確実な状況下で、障害に対する対応力を培うことはWebサービスのエンジニアにとっては重要な成長のチャンスです。必ずしも自分が把握しきっていないシステムであってもエラーログやシステムの挙動を見ながら、起きている事象を予想しながら解決すべき問題にあたりをつけていく力は、Webシステムのスキルをひろげる絶好のチャンスです。このスキルは、どんな開発言語であろうと関係なく、どの会社に行っても生きる経験であり、Webサービスエンジニアの基礎力とも言えます。
最近のBASE開発チームは、事業テーマに応じて開発チームが分かれ始めていますし、BASE BANKやPayID、AIチームなど担当するリポジトリそのものが分かれていたりして、以前のようなモノリシックな体制から分散型の開発運営体制に移行しています。
そのような状態で適切な部署に障害対応がエスカレーションされるようになると、障害対応に慣れているチームとそうでないチームが分かれてきますし、また、毎月中途入社がいるようなチームであれば、日常のフローがわからない人が常に存在することから、障害発生時の対応フローを決めてほしい、という言葉が頻繁に出てくるようになります。
更に、我々が特性として持つ、お客様の情報を守るWebサービスプラットフォームという視点、クレジットカードなどの決済を提供するサービスという視点において、ステークホルダーが多いのも特徴で、ただシステムとしてのサービスを復旧するだけでなく、そこで起きている事象をしっかり分析し、ショップオーナーさん、関係省庁やパートナー企業への報告が必要ではないか？なども常に精査する必要があります。
これらをスムーズに実行するために、開発、CS、渉外担当、法務、営業などが集まって議論を行った結果として、障害対応フローを整えることにしました。それが以下の図です。
ステップとしては、
- 障害初期調査
- 初期対応決定
- 障害対応（アクション）
- クロージング
で構成されます。
0.障害発生
主たる障害発覚の入り口は下記の誰かであることが多いです。
- ショップからの問い合わせ
- システムアラート
- ショップから営業担当への連絡
主になんらかの経路でエンジニアやCTOやVPoPに直接連絡が来ることが多いです。slackの#incidentチャンネルが作成され、共有チャンネルで全社に共有されます。incidentチャンネルが作られると100人以上の関係者が自動的にチャンネル登録されるようになっていて、とりあえずワラワラと人が集まってくる体制が整います。
ちなみに、チャンネル登録の自動化は、個人の裁量で参加の判断をしてもらってるので、そんなにincidentチャンネルにとりあえず参加する人がいるんだと言うことには驚きです。
1. 障害発見後の初動フェーズ
ここが最重要なフェーズとなります。
ここで如何に適切な関係者に話を広げられるかが、リスク対応の範囲と対応スピードを決定します。
やはりエンジニアはシステム復旧に意識を集中したいものであり、そっちに関心が行ってしまいますので、ついつい別の話はしずらかったり声もかけづらいものです。
一方で、個人情報流出にまつわる意思決定は１分１秒を争います。過小でも過剰でもない情報把握をするための的を絞っていくことが求められます。
そのためシステム復旧と並行して、これを実現するために障害対応は別に、インシデントの対応を別途に行うチームを整理しました。incidentが発生し、個人情報にまつわる懸念がある場合、なんにせよ一旦、エスカレーションしてもらう流れを整えています。
2. 初期対応決定
フェーズ１では、わらわらと集まってきた人たちで議論をしながら問題の把握をし、その後、復旧に繋がっていくのですが、ここで一度、集まって議論を整理するタイミングを入れてほしいというのを伝えています。
システム復旧だけなら勝手知ったるエンジニアだけで対処可能なのですが、もうちょっと範囲が広がった場合、足並みをしっかり整えていかないと適切な対応ができない可能性があるからです。
急がば回れという言葉がありますが、初動の足並みを揃えるのはとても重要です。また、意思決定者、リーダーを決めて、その人を中心にincidentのマネジメントの旗振りをしていくことも求められます。
3. 障害対応、アクション
- システム改修・パートナーやお客様、関係者への連絡の段取り
- データ修正、返金対応等・関係省庁への連絡など
- 広報の調整等
対応方針が決まったら、あとは各役割のプロフェッショナルに作業が移譲されていきますので、エンジニアは各チームが動きやすくなるようなデータの準備などを行います。
余談ですが、さまざまな情報を集めて集約する時には、GoogleスプレッドシートやExcelの関数やピボットテーブルで分析することが多いですが、昨今はChatGPTで実現したいことに対するプログラムを出力したりして非常に役に立ちます。
主にやることはCSVに落としたデータを読ませて、大量のデータを名寄せしたり整理したりする作業なので、慌てているときに落ち着いてコードを書いてる状況でもないことから、かなり助かります。
4. クロージング
- 関係者のふりかえりの実施
- incidentドキュメントの完成
- マネージャmtg / 経営会議等への報告や再発防止に関する議論
障害対応が終わったら、振り返りをし、再発防止策等を議論します。
もし、開発の優先順位を変えてでも対応が必要になるようであればビジネスチームとの調整や議論は必須です。そして、技術的負債の返済と同じか、それ以上に再発防止策をしっかり議論し、今やること、これからやっていくことをしっかりまとめて実行していくことが大切です。
ここで物事をスルーすると絶対に後悔するので、しっかり優先順位の整理をします。
あとがき：タイトルの意味とお気持ち
最後にタイトルに書いた意味と、自分の気持について述べておきます。サービスに携わる人数が増えてくると障害に対する感度がちょっと落ちてしまい「どうせ誰かが対応してくれるだろう」となりがちなところがあります。
システム復旧にとどまらず、ステークホルダーへの考慮すべき点が増えてくると、障害発生時の検討のレベルが一段、複雑になってきます。ここでどれだけ自分が全体視点で前のめりに踏み込めるか？がすごく大切だと思っていて、自分が前のめりに踏み込むためにも、あえてワークフローを設定したというのもあります。
特にリモートワークで仕事しているときに発生した障害は、飛び込むための関心のエネルギーが、普段以上に必要な時があります。slackを見て、誰かがシステム復旧してるなってことを確認だけして、パソコンを閉じてしまえば目の前から事象は消え去ってしまうわけです。でも、そこで適切に判断しなかったことが、あとからツケとなって返ってくることもあり、やはり都度都度、影響範囲をしっかり議論し、「それほど問題ではない」ということをしっかり確認し、そうでなければリスクを洗い出し、管理することが必要だなと思いました。
Webサービスというソフトウェアの固有の事象として、毎日、何回もリリースするという特徴がありますが、言い換えると毎日システムを壊すきっかけを生み出していると言い換えることも不可能ではありません。そのリスクと戦うことがWebサービスのスピード感を実現するわけで、常にトレードオフを迫られています。
その中でやむを得ず起きてしまったシステム障害についての問題解決は、そこに携わるメンバーの技術力や対応力を育てるという成長の機会と考えることも可能です。Webサービスに携わる方々は、是非、前のめりに問題解決に勤しむことをおすすめします。
