メディアコンテンツファクトリーは2022年7月に株式会社レイヤードに社名を変更しました。
弊社からの発信は、今後こちらからご覧ください。
https://layered.inc/

Blog MCF.LAB Blog

クラウドサービスの大規模障害発生時の心得

クラウドサービスをやっていると、どうしてもサーバ障害が起きることがあります。

業務に直結しているシステムであるほど、障害が発生したときはシビアです。MCFでもWEB問診で過去に何回かサーバ障害が発生したことがあります。突然、会社の電話から営業の携帯まで一斉に鳴り始めるのは、心臓をギュッと握られる気持ちになります。

もちろん障害が起きないに越したことはないのですが、100%障害が起きないということは不可能なので、障害が発生したときの対策も準備しておかないといけないと思ってます。今までは障害時には、私やCTOを中心に陣頭指揮をとっていた状態でしたが、組織も大きくなってきたので、そろそろうちも大規模障害時のオペレーションを体系立て始めています。

私も自社サービスの運営に10年以上関わってきて、それなりの数の障害を経験してきた中で学んできたこともたくさんあるので、今日は大規模障害発生時の鉄則、みたいなものを書いてみたいと思います。

大規模障害発生時の対応の鉄則

1.まずなによりも迅速な障害発見報告

障害の対策で一番多い失策は、実は「適切な障害認定ができていなかった、あるいは遅れる」ことです。現場の担当者が一番最初に何らかの兆候を発見することが多いのですが、担当者がまずは自分で調べてからと原因追求の調査を始めてしまったり、責任者がミーティング中だからと報告が遅れたりすることが往々にしてあります。その結果、組織として障害と認識することが遅れて、その間にバラバラといろんなところで五月雨式に情報が錯綜してしまい、気づいたときには大混乱、ということになってしまいます。

障害対策の第一歩は、全担当者レベルで「どんなときに障害と認定するか」を認識合わせしておくとともに、「その兆候を掴んだら、何はさておき『障害発生!』と即座に報告すること」です。あと絶対にミーティング中だろうが、夜だろうが、休日だろうが、誰か上の人間を捕まえることにためらうなよ、ということをメンバーに徹底していい含めておきます。

報告を受けた上司は「原因は?」「影響範囲は?」などと、あまり詳細な報告を求めないことです。まず大切なのは事実を掴むこと。原因追求は、そのあとです。

2.指揮官・本部チームの組成

次に、障害発生時の指揮官の序列を決めておきます。できれば3番目ぐらいまでの序列を決めておいた方が良いと思っています。障害は土日だろうが夜間だろうが関係なくやってくるので、予め決めておかないといけません。本部長が捕まらなくてマネージャークラスがまごまごしてしまうということがありますが、自分より上位の職責がいない間は、自分が全権指揮官であるという意識を持たないといけません。

指揮官は即座に「本部チーム」を決めます。本来の役割や部門関係なく「その場で即座に動けるスタッフ」を中心に組成しましょう。

3. 指揮官は情報の集約と発信を担う

障害のときに一番避けないといけないのは、一番事情に詳しいメンバー(エンジニアだったり担当部門だったり)に問い合わせが殺到して、そのメンバーが問い合わせ対応に忙殺されてしまうことです。そうならないためにも、まずは指揮官は全メンバーに「障害が発生したこと」「現在わかっていること」「お客様からの問い合わせにどう答えればよいか」を発信することが大切です。そして担当部門メンバーは問い合わせ対応ではなく、原因調査と復旧に専念させましょう。障害発生時の対応で、指揮官の一番重要な仕事は、情報の集約と定期的な発信(社内外含め)です。

情報発信について、いくつかコツを付け加えると、まず情報発信するチャンネルを固定化すること、そして状況が変わらなくても30分〜1時間に1回は状況報告の発信をすること、です。

4.ユーザへもできる限りリアルタイムに状況を伝える

社内への情報発信と同様、ユーザへも障害発生認定時や都度の状況報告など、できる限りタイムリーに情報発信したほうが良いです。心理的には原因が判明したり影響範囲がわかるまでユーザへの連絡を待ちたいという気持ちになりがちですが、できる限り素直な情報発信に徹した方が結果としてクレームも少ない気がします。

この前、MCFでもサーバの負荷が急激に上がっていることをエンジニアにて発見しました。まだサーバが落ちたわけではない中でユーザに障害が発生(落ちてはいないけど負荷が高くなっており、いつ落ちてもおかしくない状況)した旨の連絡を行いました。結果として早く情報を出したことで混乱も少なかったですし、各ユーザにアクセスを控えるような協力をしていただいたことで、ギリギリでサーバが耐えている間に対策を取ることができて、結果としてアクセスできなくなるなど実害が発生せずに済みました。本当に、ユーザの皆様には感謝です。

災害対策は平常時とは切り離す

私達みたいなクラウドサービス事業者にとっては、サーバの大規模障害は災害対策と似ていると思っています。結局、災害対策で重要なのは、平常時の考え方で考えないことだと思います。平常時は、ある程度決められたルール・プロセスに従い、意思決定も分散型で行った方が効率的です。しかし、災害時はありとあらゆる場所で大小様々な問題が入り乱れるので、情報が混乱します。そのため、指揮官にすべての権限と情報を集中させて、超法規的措置がとれるようにすることが必要だと思っています。そして、指揮官の最大の仕事は対処すべき事項の優先順位を決めて、限りある資源(専門チームなど)を優先順位の高い事象に集中的に割り当てることです。

これって、最近流行りのティール組織などの組織論とは逆行したマネジメント方式かもしれませんが、平常時から非常時にスムーズに組織メカニズムを変更できることが本当に強い組織なんじゃないかなと感じます。いいときばかりじゃなく逆境のときに強さを発揮できる組織でありたい。

組織が大きくなったときに、社長が不在でも組織の隅々まで災害対策を迅速に取れる組織にしないといけないし、弊社でもまだまだ課題が多いですが、こういう災害対策時の動き方や心持ちを共有しておくことで、突発的な状況下でも迅速に動けるチームにすることが、結果としてユーザのためにもなるんじゃないかなと信じています。

今日はこんなところで。