外部サービス障害への備え｜代替手段を先に決める
決済やログインに外部サービスを組み込むと、自社で変更していないのに機能が止まる場面がある。発注者が知りたいのは障害を起こ…
text: HYPE編集部
エンジニアの記事一覧へ決済やログインに外部サービスを組み込むと、自社で変更していないのに機能が止まる場面がある。発注者が知りたいのは障害を起こした会社の名前だけではなく、その間の申込や問い合わせをどう扱うかだ。依存先を把握し、切替時の権限と復旧後の照合まで設計しておくと、緊急時の判断を短くできる。
依存先を機能ごとに洗い出す
決済、認証、メール配信、地図、画像配信、フォーム、オンライン会議など、制作物が外部に頼る地点を図にする。名前だけではなく停止時に利用者が何を失うかを書く。共有ライブラリを含む実装依存と、担当者が使う業務ツールを分けて棚卸しする。
管理台帳にはサービス名だけでなく、止まる機能と代替時の窓口を書く。単一の認証基盤を複数サイトで共有しているなら、個々のサイトでは軽微でも会社全体での影響は大きい。依存関係の地図は更新担当を決める。
依存関係の洗い出しと信頼性設計の考え方は、Google Cloud Architecture Centerにも整理されています。
止まった場合の事業影響を順位づける
問い合わせフォームの停止と管理画面の一部機能停止では、売上に影響する経路が異なる。影響する顧客、代替できる手作業、復旧まで許せる時間を発注者と確認し、技術的な深刻度だけで順番を決めない。
売上機会が止まる機能を優先する一方、データ消失や安全性への影響も別軸で判定する。申込数が少ない時間帯でも個人情報が漏れる可能性なら優先度は下がらない。事業判断者が承認する順番を決める。
運用の外部委託を考えるなら、依存先の監視と顧客連絡が保守範囲に含まれるかを契約前に確認する。 公開や納品の環境を整えるなら、レンタルサーバー エックスサーバーのようなレンタルサーバーも候補になります。
代替案は契約・権限まで確認する
別の配信サービス名を控えるだけでは切り替えられない。利用申請、送信元ドメインの設定、APIキーの保管、個人情報の移転可否まで事前に整理する。未契約のサービスは即時利用可能と書かず、準備が必要な候補として区別する。
代替先の利用規約やデータ保管地域を未確認のまま緊急導入しない。共有アカウントでログインできるか、請求先は誰か、顧客への説明が必要かを事前に確認する。候補と使用可能な手段を混同しない。
切り戻し条件も設計する
障害時に一時的な手入力で受け付けた注文を、復旧後にそのまま自動同期すると二重登録が起こりうる。識別子、受付履歴、照合担当を決め、通常運用へ戻す前に差分を確認する。
手入力へ切り替えた注文は、元の取引と照合できる番号を必ず持たせる。復旧後に自動処理が走ると二重請求のリスクがあるため、差分検査を終えるまで反映を留保するルールも必要だ。
臨時受付を支える業務ツールは、識別番号の発行と復旧後の照合のしやすさで評価したい。 帳簿づくりまで見据えるなら、マネーフォワード クラウド確定申告のようなクラウド確定申告も役立ちます。
連絡文は依存先の責任論を避ける
外部ベンダー側の障害と分かっても「自社は悪くない」だけでは顧客の判断材料にならない。現在できること、できないこと、次の更新予定と代替窓口を示す。未確認の復旧時刻は断定せず、公式ステータスへの案内を添える。
外部ベンダーを責める文面は、顧客がいま取るべき行動を伝えない。利用できない操作、回避方法、次回案内の目安を整理する。復旧時刻が不明なら推測して約束せず、更新時刻だけを伝える。
障害情報の公表や連絡の作法は、JPCERTコーディネーションセンターの公開情報も参考になります。
切り替え訓練で机上の案を検証する
用意した代替フォームがモバイル画面で表示されない、通知先が古い担当者になっている、といった不具合は訓練で見つかる。小さな範囲で受付からデータ回収まで通し、切り替えに要する手順を更新する。
机上の手順書では権限不足を見落としやすい。実際に担当者が予備の連絡経路を使い、必要な設定を変更できるか検証する。切替テストで顧客データを移さず、テスト環境で手順だけ試す工夫もできる。
切替訓練の手順を整理する教材なら、責任者が不在の場面まで想定した演習が役立つ。 体系立てて学びたい場合は、Webスキルを学ぶオンラインスクール デイトラのようなオンラインスクールも選択肢になります。
障害への備えの基本は、IPA「日常における情報セキュリティ対策」でも確認事項として挙げられています。
費用と顧客体験の両方で判断する
冗長化は常に最善とは限らない。追加料金だけでなく管理負荷、データの分散、障害時の誤操作リスクを比較する。許容停止時間が長い業務は手動運用を採用するなど、予算と必要な可用性を釣り合わせる。
有料の代替契約を用意するべきかは、停止で失う売上と顧客の信頼、運用負荷を分けて考える。予備サービスにも障害はありうるので、同じ基盤に依存していないかを調べておきたい。
責任分界を保守契約に明記する
サービスの選定、アカウント管理、障害検知、利用者通知、代替操作の実行を誰が受け持つか曖昧にしない。特に営業時間外の対応や追加費用を確認しておけば、実際の停止時に依頼主との認識違いが減る。
保守契約には外部サービス自体の復旧保証を含めない一方、利用状況の確認、顧客連絡、代替案の実行をどこまで引き受けるかを明記する。責任分界が曖昧だと障害時に費用の交渉から始まってしまう。
判断に使う比較表
| 確認する場面 | 実際に見ておく材料 |
|---|---|
| 依存先を機能ごとに洗い出す | 決済、認証、メール配信、地図、画像配信、フォーム、オンライン会議など、制作物が外部に頼る地点を図にする |
| 代替案は契約・権限まで確認する | 別の配信サービス名を控えるだけでは切り替えられない |
| 連絡文は依存先の責任論を避ける | 外部ベンダー側の障害と分かっても「自社は悪くない」だけでは顧客の判断材料にならない |
| 費用と顧客体験の両方で判断する | 冗長化は常に最善とは限らない |
案件での使い方
例えば予約フォームが外部認証に依存している場合、ログイン障害時の画面に問い合わせ先を表示するだけでは十分とは限らない。会員情報を確認できない状態で予約を受け付けてよいか、受け付けた情報をどこに保管するか、復旧後に重複をどう防ぐかを決める必要がある。代替手順は業務フローと一緒に検証したい。
サービス障害の案内では、公式ステータスページの更新を待つ姿勢と、自社の状況を調べる行為を混同しない。外部側が復旧と発表しても、自社の連携設定やキューに残った処理が正常とは限らない。利用者が実際に操作を完了できることを確認してから、通常運用への復帰を告知する。
発注者との保守相談では、代替案にかかる維持費だけを比較しない。事前の権限管理、切替判断の承認者、復帰時のデータ照合を含めれば運用作業が見える。平時の準備費を払わずに障害時だけ即時対応を要求する契約は、関係者の期待をずらしやすい。
代替連絡窓口を設けるなら、受付できる内容の範囲も明らかにする。通常フォームで取得していた項目を無理にメールへ書かせると、取り扱う個人情報が増えるおそれがある。平時に必要最小限の受付方法を設計する方がよい。
代替策の価値は「切り替えられる」と言うことではなく、顧客対応を止めずに済むかで決まる。維持費をかける場所と手作業で受ける場所を事業優先度に沿って選ぶ。
運用時に確認したいこと
代替手段を導入しない判断にも理由が必要だ。業務の一部を停止して顧客へ待機を案内する方が、個人情報の転送や注文の二重登録を避けられる場合もある。切替の可否を単純な二択にせず、限定運用、受付停止、再開の条件を整理しておくと緊急対応が現実的になる。
最後の確認
切替手順を更新したときは、古い案内文や古い受付フォームが残っていないかも確認する。複数の代替窓口が同時に動くと、顧客から同じ申し込みが繰り返し送られることがある。障害中に扱った申込をどの窓口で集約するか決めることは、復旧後の照合作業を減らす。担当者は切替開始時刻と終了時刻を控え、影響を受けた取引を後から追える状態にしたい。
出典
CTA
仕事の取り方や単価の決め方で迷ったら、HYPEへご相談ください。→ お問い合わせはこちら
※本記事にはプロモーションを含みます。
合わせて読みたい
つくる人の仕事のヒントを、週1で
新しい記事と、学び・案件のヒントをメールでお届けします。
RECOMMEND
注目のコンテンツ
