急なトラフィック急増や社会的な緊急事態が起きたとき、プロダクトの運用体制をどう切り替えるか。この判断で悩むSRE（サイト信頼性エンジニア）やインフラ担当者に向けて、今回はGoFundMeというクラウドファンディングプラットフォームの事例を手がかりに整理します。
GoFundMeは医療費や災害支援、政治的に注目度の高いキャンペーンまで、幅広い資金調達を扱う米国発のプラットフォームです。CEOのTim Cadogan氏は2020年3月、新型コロナウイルスの感染拡大が始まった直後にトップに就任しました。平時の運用と非常時の運用が同じシステム・同じ組織体制で回せるとは限らない、という論点がここにはあります。
どんな場面でこの判断が必要になるか
サービスが社会インフラ的な役割を持ち始めると、通常のキャパシティプランニング（想定負荷に基づく設備計画）だけでは足りなくなります。
たとえば大規模災害や社会的事件が起きた直後、特定のキャンペーンやページにアクセスが集中することがあります。平常時のオートスケーリング設定のままで耐えられるか、事前に判断基準を持っておく必要があります。
判断軸1: 負荷の性質が「予測可能」か「突発的」か
通常のセール・キャンペーンによるトラフィック増加は、事前にある程度予測できます。一方で社会的事件をきっかけにした急増は、発生タイミングも規模も読めません。
予測可能な負荷であれば、CDN（コンテンツ配信ネットワーク）のキャッシュ設定や事前のスケールアウトで対応できます。突発的な負荷には、オートスケーリングのしきい値を平常時より余裕を持たせて設定しておく判断が求められます。
判断軸2: システムの一部が「社会的な安全網」になっているか
GoFundMeでは医療費関連のキャンペーンが最も多いカテゴリだとCadogan氏は述べています。これは米国に限らず、GoFundMeが展開するすべての市場で共通しているとのことです。
公的な保険制度の隙間を民間サービスが実質的に埋めている場合、そのサービスのダウンタイムは単なる機会損失にとどまりません。利用者にとって「他に頼る手段がない」状況になっている可能性があるため、SLO（サービスレベル目標）の設定を通常のtoCサービスより厳しくする判断が必要になります。
判断軸3: 組織体制を平時型のまま維持するか、緊急対応型に切り替えるか
Cadogan氏がCEOに就任したのはパンデミック直後という、組織にとって最も混乱した時期でした。平時のプロダクト開発プロセスと、緊急時のインシデント対応プロセスは、必要な意思決定スピードが根本的に異なります。
平時はレビューやステージング環境での検証を経て段階的にリリースする体制が合理的です。緊急時はインシデント指揮官（Incident Commander）を立てて権限を一時的に集中させ、承認フローを簡略化する体制に切り替える判断が必要になります。
| 観点 | 平時運用 | 緊急対応運用 |
|---|---|---|
| スケーリング判断 | 予測ベースの事前スケール | しきい値に余裕を持たせた自動スケール |
| SLOの厳しさ | 通常のtoC水準 | 社会インフラ相当に引き上げ |
| 意思決定フロー | 通常のレビュー・承認 | インシデント指揮官への権限集中 |
| 組織の焦点 | 機能開発・成長 | 可用性・信頼性の維持 |
ケース別の推奨
自社サービスの一部機能が「他に代替手段がない」領域を担っているなら、その部分だけでもSLOを個別に設定し直す価値があります。GoFundMeにおける医療費カテゴリのように、社会的な緊急避難先として使われている機能があるかどうかを、まずはアクセスログとカテゴリ別の利用データで確認してみてください。
突発的な社会的イベントでアクセスが急増した経験が過去にあるなら、そのときのオートスケーリング設定・アラートのしきい値・インシデント対応の初動時間を振り返るのが次の一歩です。クラウドのモニタリングダッシュボード（AWSであればCloudWatch、GCPであればCloud Monitoringなど）で、過去のスパイク時のレイテンシとエラー率のログを確認し、現状の設定で同じ規模のスパイクに耐えられるかを試算してみましょう。
あえて見送るべき条件
すべてのサービスが緊急対応型の重い体制を常設する必要はありません。平常時のトラフィックパターンが安定しており、機能停止時の影響が限定的なら、緊急対応プロセスを常時維持するコストの方が見合わない場合があります。
また、組織規模が小さく専任のSREやインシデント指揮官を置けない場合、無理に大企業型の体制を模倣するより、クラウドプロバイダーのマネージドサービス（オートスケーリング・マネージドデータベースなど）に運用の一部を委ねる方が現実的な選択肢になります。
まとめ
GoFundMeの事例から読み取れるのは、サービスが社会的な安全網の役割を帯びた瞬間に、平時の運用基準では足りなくなるという構造です。
判断すべきは、自社サービスのどの機能が「代替手段のない」利用のされ方をしているか、そこにどれだけのSLOとインシデント対応体制を割り当てるかです。
まずは過去のアクセスログを見直し、突発的な負荷スパイクが発生した際の対応時間とエラー率を洗い出すところから始めてみてください。