
Salesforce障害の影響と今後の対策
この記事は BizOpsアドベントカレンダー 23日目の記事です。 前回は
一般社団法人日本BizOps協会の村本 佳駿さんによる「アドカレマッピング + 各社利用ツール紹介」でした
こんにちは。株式会社マネーフォワードでBizOpsを担当しております齊藤と申します。
この記事では先日発生したSalesforce障害で業務にどんな影響が発生したのか、そこから何を学んだのかという点について書いてみたいと思います。
なぜこのテーマにしたのか
マネーフォワードのBizOps部では責務でグループが分かれており、私の所属グループでは以下を責務としております。
プロジェクトにおける方法不確実性に対する対処
ツールの持続可能性担保
正しいデータの担保
ツールが使えないという状況は「ツールの持続可能性担保」「正しいデータの担保」を果たせない状況です。
今後同様の事態が発生した場合に正しく対処できるよう、また同様の課題を持っている方の一助となればと思い、このテーマを取り上げました。
11月15日 障害発生
「Salesforceにログインできない」という問い合わせがSlackに届きました。
すぐに私も検証してみると、確かにログインができません。
Salesforce Trust ※1 を確認しても障害は発生していませんでしたが、X(旧:Twitter)でもアクセスできない旨のポストが多数見受けられました。
他のメンバーにも検証を依頼した結果、同様の事象を確認。
今回の事象が個人の端末環境・自社環境に依存しないものであることを確認し、社内向けに部長より一次報告をアナウンス。

とにかく深刻な状況であることがわかりますね
※1 Salesforce Trust
Salesforceのメンテナンス情報や障害情報等を確認することができるサイト
自社のSalesforce組織が稼働している環境(インスタンス)を把握しておく必要がある
Salesforce障害による業務への影響
私たちは多くの業務をSalesforce上で構築しており、今回の障害は業務に大きな影響を及ぼしました。
以下に具体的な影響例を示します。
MKT:資料請求データの連携停止
資料請求はWEBページから受け付け、入力情報をMAツール経由でSalesforceに連携する仕組みを構築
連携ツールがSalesforceにログインできず、連携ストップ
IS:顧客対応の停止
Salesforce上に記録された情報を基に、製品やサービスに関する詳細な情報を提供しています
「コールセンター」機能を利用して架電環境を構築し、架電結果をSalesforceに記録する運用を行っています
Salesforceにログインできない為、運用が停止
FS:契約締結プロセスの停止
プロダクト導入を決定したお客様に申込書を送信する仕組みをSalesforce上で構築
Salesforceにログインできない為、運用が停止
バックオフィス:納品プロセスの停止
製品利用開始に必要な情報をSalesforceから基盤システムに送信する仕組みを構築しています
Salesforceにログインできない為、運用が停止
サクセス:問い合わせ対応の停止
メール to Caseを利用して、お客様からの問い合わせをSalesforce上で管理しています
問い合わせ内容を確認できず、問い合わせ情報をSalesforceに反映することができませんでした
このように、Salesforceの障害は各部門の業務に直接的な影響を与えました。
その時チームは何をしたか
当時を振り返るとかなりバタバタしておりましたが、グループジョイン、組織統合のPJが佳境を迎えていた中でよい対応ができていたと思います。
社内ユーザー向けアナウンス
変化する状況を随時アナウンス
マネーフォワードクラウドの一部製品ではSalesforce連携機能を提供しているため、プロダクト開発をしている社員に対しても情報を連携
Trust情報の確認とSNS状況注視
復旧の進捗状況を把握する為、Trustと X を随時確認。
担当AEへの連絡と状況確認
復旧の進捗状況を把握するため、担当のAEへ確認。
Trust経由で出る情報よりも、早く情報をいただけたので安心感がありました。
余談ですが前職でもSalesforceを利用していた際、担当AEの方は常々「ライセンス費用にはこういった対応も含まれています」と仰っていたので、躊躇することなく問い合わせできました
影響範囲の棚卸とリカバリの実施
外部からSalesforceに対してデータを書き込むツールや機能の確認
復旧した場合に備えて、データリカバリー方法検討とリカバリ実施
障害から得た教訓
平時から対応プランを検討する
障害対応中に対応方針を考えるのは難しく、誤った手段を取ってしまうと二次災害を生む危険性もあります。
平時から「障害発生中」「障害からの復旧」2つの時間軸で対応プランを考えておくのが重要です。
障害発生中
① 障害影響を軽減するためのプラン構築
障害からの復旧
② 障害復旧後の業務を正常化するためのプラン策定

これはまさにBCPとDRの考え方ですね!
BCP(Business Continuity Plan:事業継続計画)とは、機器故障によるシステム停止から、エリア停電・ビル火災といった局地災害、地震・洪水といった地域災害、情報漏洩まで、事業継続を阻む広範なリスクに備えて、事業を継続させる計画のことです。
DRとはディザスタリカバリ(Disaster Recovery)の略であり、日本語に訳すと「災害復旧」となります。
地震や津波などの天災や、テロ、不正侵入などによりシステムが壊滅的な状況になった際に復旧・修復すること、また、その災害に備えたシステムや体制を指します。
効率的、かつダウンタイムを最小限にして早期復旧を可能にすることを検討する必要があります。
今後やっていくこと
トラブル後の振り返りとして、今後以下の点を検討していきます。
① 障害影響を軽減するためのプラン策定
Salesforceが停止したときのプランを検討し、関係者で合意します。
個人的な感覚ですが、Salesforceが今回のインシデントの様に長期間完全停止する確率はかなり低い。
業務インパクトとSalesforceの稼働率を考慮して、どの程度の代替案を用意するのか(もしくはしないのか)を検討する必要がある。
同等のビジネス環境をその他のツールで構築し多重稼働するような手段は、障害発生時間を考えると弊社にとっては過剰な対策になりそうです。
Salesforceの稼働率
過去実績として99.9%の稼働率であるという情報をネット上で複数見かけました。ただし公式情報としては確認することができず、 Salesforce MSA や SOC2レポート にも記載が見当たりませんでした。ご存じの方教えていただけると幸いです。🙇
② 復旧後の業務を正常化するためのプラン策定
Salesforceが復旧した際に障害中に連携できなかったデータを、どのオブジェクトに、どのように連携するのかを検討します。
そのためには、ツールの整理と再連携手段の確立が必要です。
ツールの棚卸
どのツールが、オブジェクトに対してRead/Write をしているのかを見える化しております
Salesforceが数時間停止する 優先システムメンテナンス ※2 が予定されていた際に影響範囲特定にも役立ちました

※2 優先システムメンテナンス
インフラ環境の維持のためのメンテナンス。メンテナンス期間中は数時間の利用停止、もしくはリードオンリー(データは見れるが、更新はできない)モードが伴うことがある。
再連携手順の確立
外部ツールからSalesforceへのデータ書き込み
停止中に連携できずに外部に滞留してしまったデータの再連携手段を検討します
再実行することで再度データ連携が可能なのか
データを抽出したうえでDataLoader等のツールで更新する必要があるのかを確認します
実際にSandbox環境での訓練をしてみる
外部ツールがSalesforceのデータ読み込み
障害発生中に外部ツールからSalesforceへのRead処理が走った場合、データ連携が出来ていない可能性があります。
こちらも自動連携/手動連携 要否とバックアップ手段を確認しておく必要があります。
まとめ
今回の件で障害発生時への備えが甘いことを痛感しました。
Salesforceに限らず、SaaSプロダクトは業務に深く入り込んでいるケースが多く、障害が発生した場合のインパクトはかなり大きいものになると考えます。
Salesforce以外をお使いの皆様におかれましても、SaaS障害対応の方針を検討する際の一助になれば幸いです。
平時にやること
障害影響を軽減するためのプラン構築
ツールが停止した時に備えて代替プランを検討し、関係者で合意します
復旧後の業務を正常化するための計画策定
復旧後の業務正常化に向けてリカバリ計画・手順の作成をします
障害発生(初期)にやること
発生している事象の切り分けを行う
個人環境起因・個社環境起因なのかを確認する
初期段階ではTrustサイトでは確認できない可能性もあるため SNS等も頼る
ただし情報の正確さには注意が必要
担当AEへの確認
複数の顧客を抱えている為、同様の問い合わせが集中している可能性があります
なにかあった際の連絡手段を確保しておくとよいかもしれません
社内ユーザーへのアナウンス
事象の原因がわからなくとも、まずは一報アナウンスすることが重要
障害発生中にやること
障害影響を軽減するためのプランを実施
代替オペレーション運用の開始
事前に決めているリカバリ方法に則った準備の開始
ツール別に確認をする
障害進捗状況の確認
Trustサイトもしくは担当AEに確認する
復旧後にやること
復旧後の業務を正常化するための計画を実施
復旧の確認が取れたら、データのリカバリの開始
復旧する順番に依存性がある場合は注意する。
We are Hiring
一緒に働く仲間を募集しております。
少しでも興味があれば、以下からご応募いただけると嬉しいです!
まずはカジュアルにお話できればと思います!
私達がどんなことに取り組んでいるのかご興味がある際、以下の note もご覧ください。