障害対応の属人化を防ぐ――freeeのSREが実践する情報共有術：150分間のサービス全停止も教訓に

サービスで発生する障害をゼロにすることは難しい。では、障害をゼロに近づけるために誰が何をしていくか。freeeのSREが大規模障害で学んだことや、障害を減らすための取り組みを紹介した。

LINE

Hatena

　Webサービスで起きる障害の原因は、Webサーバやデータベース、キャッシュの設定ミス、ハードウェアの故障など多岐にわたるため、障害のリスクをゼロにしながらサービスを提供することは現実的には難しい。一方で、障害が起きた場合、社会的信頼の損失など悪影響は避けられない。

　では、できるかぎり障害をゼロに近づけるためにどうすればいいのか。2020年1月に開かれた「SRE NEXT 2020 TOKYO」に登壇したfreeeでSRE プレイングマネージャー坂井学氏の講演内容を要約してお伝えする。

SaaSを提供するなら「障害ゼロ」にはできない

　坂井氏は冒頭、講演のゴールを「障害解消に向けた取り組み（障害対応）に課題を感じている人が、改善のための第一歩を踏み出そうと思えるようになること」と説明。SRE（Site Reliability Engineer）として障害に対応した経験を「赤裸々に話すが、まだ課題も多い。ぜひ、みなさんの取り組みも共有いただきたい」と語り、セッションを始めた。

freee SRE プレイングマネージャー坂井学氏

　freeeは資金や個人情報に関するセンシティブな情報を多く取り扱っている。例えば「会計freee」は個人事業や法人の財務情報を扱うサービスで、電子決済等代行業に該当するため「銀行法等に基づく登録が必要で、金融庁に登録済み」（坂井氏）だという。freeeは2019年12月にマザーズへ上場し、プライベートカンパニーからパブリックカンパニーへ移行。「障害に対して、よりシビアかつオープンな情報公開が求められるようになった」（坂井氏）のだ。

　たとえ障害が許されないような状況でも、坂井氏は「障害はゼロにはできない」と考えているという。

　「新しいチャレンジをして、価値を生み出していく必要がある中で障害が一定数発生するのは避けられない。障害の発生を受け入れながら、安定したプロダクトを目指すという相反することの両立を目指しているのがfreeeだ」（坂井氏）

150分間のサービス全停止――大規模障害の発生から学んだこと

　それでは、freeeでは障害にどう立ち向かってきたのだろうか。

　坂井氏がfreeeに入社した2016年ごろ、約60人のエンジニアが在籍していた。しかし、サービスに障害が発生した際、エンジニアがどう対応するかまとめられていたドキュメントはなかった。「障害発生時は『秘伝のコマンド』などの暗黙知で障害を解消していた」（坂井氏）。つまり、障害対応したエンジニアだけが障害解消の「学び」を得ていたため、「ナレッジが属人的になってしまうという課題があった」（坂井氏）というわけだ。

　2018年に入ると「SOC 1（Service Organization Control）」の取得に向けた準備が始まった。SOC 1とは、freeeのようなSaaS（Software as a Service）の提供企業が「財務情報を勝手に書き換えていない」ことを保証する証明書だ。SOC 1の取得に向けた準備の一環として、「明確な障害対応フローの策定を始めた」（坂井氏）。

　障害対応フローでは、障害がどれくらいのユーザーに影響するものなのか、というような具体的な数値を基に影響度合いを算出。緊急招集レベルとなる「レベル5」を最大の障害としてレベル1～5までを定義した。定義づけをすることで障害に対する判断のブレがなくなり、「『この障害は急いで対応しなくてもよい』というように、定義したレベルに合わせて対応の優先度を明確化できるなど成果があった」（坂井氏）という。

　だが、事件が起きる。2018年10月31日、会計freeeが150分間にわたって停止するという障害が発生した。障害の原因は初歩的なオペレーションミスだったが、データ不整合の可能性が判明したため、そのままサービスを続行するとユーザーデータが壊れるリスクが生じた。そこでやむを得ず、サービスを停止する判断に至った。

　この大規模障害が発生した際も、前述した障害対応フローを基にレベル付けが行われた。しかし、障害対応フローそのものをブラッシュアップしている段階だったこともあり、現場は混乱に陥ったという。

　「大規模障害が発生した際、障害対応フローを基にレベルを算出できても『誰が何をしないといけないか』という明確な判断ができなかった。結果、スキルの高いエンジニアが指揮しながら作業をするため、社内／社外への情報共有がうまくいかない状況が生まれてしまった」

　そこで、障害発生時の初動や、障害そのものの解消に向けて誰が何をするのか、誰が何をしないのかというフローをまとめたドキュメントを用意することにした。またサービスを利用するユーザーや金融庁に対して障害に関する情報を迅速に伝達しなければならないため、「誰がどこに対して、どのような情報を発信するか」という点も、具体的な担当者の名前を挙げてドキュメントにまとめることにしたという。

初動の省力化のために「自動化」を図る

　もう一つの改善内容は「障害解消に向けて取り組む物理的なエリアの設置」だ。情報を1カ所に集約し、復旧までのかじ取りをするためのエリアとして「ブリッジ」と称したルームを用意した。このエリアには大型ディスプレイやビデオ会議システムなどが常設されており、障害発生時はエンジニアの作戦基地になるという。

ブリッジでの作業の様子（提供：freee）

　なぜ「ブリッジ」を設置するのか。それはエンジニアが別々のフロアで作業していると、認識のズレや、遠慮し合って誰も実行していなかったという「お見合い」が生じがちなためだ。

　また障害解消に向けた改善内容として「初動の省力化」も挙げた。障害発生時は現場が混乱するため、とにかく省力化することに力を入れ、初動対応を誰でも平易にできるように工夫しているという。

　例えば、Slackに「障害対応するぞ」と書き込むと「Slackbot」が必要なマニュアルを表示。Slackに「障害フォーム」と書き込むとフォームが表示され、このフォームに書き込むと、社内への告知文やポストモーテムのドキュメントが自動作成され、必要なメンバーに展開されるなどの自動化を進めている。

　「初動の省力化のために準備の自動化を実現したことで、『あの人も呼ばなければいけなかったのに忘れていた……』というようなミスも防げるようになった」

Slackbotの機能を用いた障害対応準備の自動化（提供：freee／編集部で画像を一部加工）

障害からの「学び」を社内で広める3つの工夫

　障害解消に関する取り組みはこれだけではない。サービス障害のような失敗から得た学びを社内で広めるため、3つの仕組みを用意しているという。

　1つ目の仕組みは、障害の学びを開発組織全体に共有する「失敗.js」だ。犯人探しや責任追及の場ではなく、発生した事象や影響、対策内容、得られた学びを共有する。「失敗.js」に取り組むことで、自分と直接関わらないチームの学びを自分のチームに取り込むことができ、全社の障害を減らす結果につながるという。

　2つ目は、「建物の窓が壊れているのを放置すると、誰も注意を払っていない象徴になり、やがて他の窓も間もなく全て壊される」という米国の犯罪学者ジョージ・ケリング氏が考案した割れ窓理論を応用した「割れ窓を改善し隊」だ。小さな問題を放置せず「Backlog」に登録し、週次で「もくもく会」と呼ばれる会を開くことで、小さな問題を消化していく。この取り組みで、3カ月の間に挙がった33個の問題の内、20個を解決できたという。

　「『課題は解決しなければいけない』という意識を持っているメンバーが多いなら、課題解決を実現できる場所や機会を用意してあげることが大切」（坂井氏）

　そして3つ目は、直近1週間に発生したアラートを振り返りノウハウを共有する活動の「alertを振り返り隊」という取り組みだ。2020年1月に始めた取り組みのために、まだ大きな成果は上がってはいないとのことだが「alertを振り返り隊」の活動を続けることで、属人的な対応方法が明確になったり、新たな割れ窓が見つかったりする効果を期待しているという。

　坂井氏は、障害解消に向けた取り組みや改善を進めてきた経験から、組織文化やプロダクトを意識した障害対応フローの作成が重要だと強く感じているという。坂井氏は以下のように述べて講演を締めくくった。

　「組織が大きくなるにつれ障害からの学びは属人的になってしまう。障害が発生しないことに越したことはないが、大きな障害ほど『学び』のチャンスになる。そして、障害対応フローを見直すきっかけにもなるはずだ。今回紹介したfreeeの障害解消に向けた取り組みを参考にしつつも、まねるのではなく、組織文化にあった障害対応フローを作成して取り組んでいってほしい」

特集：「DevSecOps」を支えるSRE

ユーザーに素早く価値を提供しつつセキュアなサービスを運用していく上では「DevSecOps」の考え方が欠かせない。そのような中でGoogleが実践、提唱している「Site Reliability Engineering」（SRE）という役割の導入が、Webテクノロジー企業の間で進んでいる。サービスの信頼性向上をミッションとして改善を行うSREにサービスのセキュリティ部分を担当させる動きもある。一方で、限られたリソースの中でSREを実践することは容易ではない。SREが成果を果たすためには、複数の目標／方針を定め、インシデント対応はもちろん、ロギング、サービス監視、インフラのコード化、運用自動化など並行して取り組んでいく必要があるためだ。日常業務に加えて、自動化に向けた取り組み、そして企業によってはセキュリティへの対応などすべきことは多い。SREを実践している企業は、SREの考え方をどうデザインして実践し、SRE実践に当たって抱えた課題にどう取り組んでいるのか。インタビューや事例を通じて俯瞰（ふかん）してみよう。

特集：「DevSecOps」実現を支えるSRE