コンテンツに移動
リテール

2020 年の年末商戦のピークに備える: 指令室をバーチャルに

2020年11月5日
https://storage.googleapis.com/gweb-cloudblog-publish/images/war_room.max-2600x2600.jpg
Google Cloud Japan Team

※この投稿は米国時間 2020 年 10 月 24 日に、Google Cloud blog に投稿されたものの抄訳です。


小売業界が 2020 年の前例のない年末商戦を迎えようとしている中、デジタル化を志向しているのは買い物客だけではありません。商戦の指令室は従来、中心となる IT チームとビジネスチームが 1 つの大部屋に集まって、システムの稼働状態を保持し、ウェブサイトのクラッシュを防ぎ、在庫を確保する場所です。これも現在、COVID-19 のため様相を変えています。

リモートワークが浸透しているため、多くの小売業者にとって、2020 年の年末商戦の指令室は、多くのリビングルーム、ソファ、ガレージやキッチンに分散されることになります。このような大規模で注目度の高いイベントを 100% バーチャルに(リモートまたはデジタルで)管理することは、多くの人にとって初めて経験することです。

今年は特に多くのお客様に、Google のブラック フライデー / サイバー マンデー(BFCM)のホワイト グローブ サービスをご採用いただいています。Google は、指令室の 100% 仮想化を進める Macy’s、The Home Depot、Tokopedia などの小売業界のリーダー企業と連携しています。

構築した仮想指令室は、Google がサイト トラフィックと販売の増加に対応するうえで非常に重要な役割を担っています。これにより、迅速な対応を実現し、月間 1 億人以上のアクティブ ユーザーを満足させることが可能となっています。

Tokopedia エンジニアリング担当バイス プレジデント(テクニカル フェロー)Tahir Hashmi 氏

幸い、Google には経験がありました。Google は、大規模な商品のリリース、インシデントへの対応、独自のブラック フライデー / サイバー マンデー業務を行う際に、仮想指令室を長年にわたり運用してきました。ブラック フライデー / サイバー マンデーとさらなる年末商戦に向けた仮想指令室の準備、運用、評価のためのガイダンスを Google は作成済みです。Google の目的は、お客様がこの大切なピークイベントへの対応を過去と変わらずに、迅速かつ効率的に行うことができるようすることです。お客様のチームが Google のベスト プラクティスを利用して、今シーズンの不安定な消費者行動と、対応するシステムの需要をうまく管理しながら、システムの稼働を維持し格別なカスタマー エクスペリエンスを提供できるようサポートいたします。

ステップ 1: イベントに向けた準備

重要な情報の収集

多くのお客様のビジネスにとって、年間で最も大きく重要となるイベントを管理する準備を開始します。イベント中に必要になると思われるすべての情報を簡単に利用できる状態にし、明確にドキュメント化したうえで、指令室のすべてのメンバーがすばやくアクセスできるようにします。コミュニケーションには遅延が生じる可能性があることに留意する必要があります。単にチームメンバーのデスクに歩み寄り、質問をすれば成立するというものではありません。

コミュニケーション

まず、通常時のイベント管理と緊急事態やインシデント対応時の両方において使用する的確なコミュニケーション ツールとアプローチを決定します。グループやチーム単位で想定されるコミュニケーション方法(チャット チャネル、会議サービスなど)と、直接エスカレーションや説明などが必要となった場合のためにメンバー同士のコミュニケーション方法を規定します。このようなコミュニケーション方法はできる限り明確かつ簡単にします。それにより、すでに繁忙している時間帯に発生したインシデントを管理しなければならない場合などでも混乱を防ぐことができます。それぞれのバックアップ プランを検討してください。たとえば、選定したチャット プラットフォームがサービス停止に至った場合にどうするかについて検討します。

具体的なおすすめは、すべてのコミュニケーションにおいて日時のフォーマットを標準化することです。これは、チームが複数のタイムゾーンに分散している場合に特に重要です。コミュニケーションはできるだけ明瞭である必要があります。引き継ぎをしようとしているイベントについて説明する際に、自分とは異なるタイムゾーンにいる次の担当者に「自分の」タイムゾーンを基にして話を進めれば、さらなる混乱を生んで応答が遅れる可能性もあります。

コミュニケーションにおいてもう一つ重要なことは、メンバーが、誰かに尋ねなくても、必要とする情報を得られるようにすることです。そのためには、専用のステータス ページを作成して使用するか、「Google グループ」を使用することを検討してください。これにより、関連のモニタリングやロギング コンソールなど、イベントに関わるシステムの全般的な健全性が保たれ、その他の詳細情報へのリンクが提供されます。目標は、状況を確認する必要のあるメンバーが一目で情報を確認でき、追加のコミュニケーションの必要がないようにすることです。おすすめするのは、このページの特定の既知のオーナーを指定し、事前に規定されたスケジュールでページを更新する任務を割り当てることです。

期待値

次に、通常時と緊急時の連絡手段を含むスタッフ割り当て、役割、期待値が明確に定義されていることを確認します。イベントに関わるチームメンバーと必要時に直接連絡を取ることができる方法(通常は携帯電話やポケベル)をリストにしておきます。ローテーション体制を敷いている場合は、それを明確にドキュメント化し、イベント中の通常時とエスカレーション時における引き継ぎ方法について規範的なプランを作成します。どちらの場合でも、イベントにおける各チームや個人の役割および、通常の連絡手段ではなく緊急の連絡手段を使用する必要がある場合について明確にします。まだ作成していない場合は、「エスカレーション パス」について記載した明確なドキュメントを作成することが非常に有効です。このようにすると、問題が発生しても、適切なレベルの注意がその問題に向けられるため、イベント中に問題への対応が長期化してチームに過剰な負担がかかり、疲弊しきってしまうという事態を回避できます。

イベントの予想されるタイムラインを作成することも非常に重要です。イベントの開始日時、イベント開催中に発生する業務、終了する日時をできるだけ明確にドキュメント化します。

最後に、発生する可能性がある一般的なサービス停止という事態に対処するプランを作成しましょう。モニタリングによりサービス停止を検知できる状態になっていて、対応方法を策定済みであることを確認してください。たとえば、適切な人員を配置できる状態にあること(対応人員の数を増やすために迅速な資金調達が必要となる場合など)、必要時に直ちに判断を承認できる状態にあることを確認してください。

エンゲージメント

過去には、このようなイベントは専用の物理的なスペースで運営し、チームのエンゲージメントを保つために食事や娯楽などを供していたかもしれません。仮想環境において、シフト勤務中のチームメンバーの参画意欲を保つにはどうすればよいでしょうか?チームメンバーにサプライズでギフトカードや差し入れを送り、仮想環境での運営にあたるスタッフの士気を高めることを検討してください。

テスト運用の実施

準備を確実にする最善の方法は、シミュレーションを実施し、負荷がかかった際に仮想プロセスがどのように機能するかを確認することです。これにより、問題発生時にどの程度効率的に事態を解決できるかが分かり、何が起きても対処できるようになります。

このようなシミュレーションを準備するには、テストの対象と目標についてのスコープを的確に定めます。仮想に移行した指令室のこれらの側面を特にシミュレーションするには、分散したチーム間でどのように情報のやり取りをするかに焦点を当てます。通常時とエスカレーション時を想定してコミュニケーション ツールを使い、プライマリとセカンダリの両方のツールをテストしておきましょう。これにより、チームの使うツールが適切に構成され簡単に使用できる状態にあるか、使いやすさやアクセスについてイベント前に対処すべき問題がないか、イベント中に想定されるコミュニケーション方法は明確かを判断できます。

「通常」時、およびインシデント、緊急事態、エスカレーションなどが発生する非常時におけるイベントのタイムラインを検証するシミュレーションを実施してください。後者は、ウィール オブ ミスフォーチュン机上演習(テンプレート)と呼ばれることがあります。その目的はインシデント管理と対応テクニックの演習です。一方、前者は、作成したタイムラインが現実的であること、期待値が明確であり十分に理解されていること、チームが割り当てられた責任分担に基づいて行動できることに焦点を当てています。

最後に、イベントに備えて、「ライブ」テストを実施障害復旧テスト(DiRT)形式あるいはカオス エンジニアリングの手法にて、本番環境に実際の障害を導入)する方法、または非本番環境に大規模な負荷テストを実施する方法のいずれかを選択できます。いずれの場合でも、テストを実際のイベントのための練習として扱い、前段階で集めたすべての情報を対応のために利用することをおすすめします。

準備とテストの事後分析

準備とテストが終了したら、うまくいったこと、改善の余地がある点、指令室のプロセス自体を強化する方法などについて評価します。これは、どのような状況においても適応してイベントを継続できる能力を確保するために重要です。しかし、単に今年のイベントを準備するために必要な事柄だけに注目するのではなく、将来的にもより効率的にイベントを運営できるように長期的な改善点も把握するように努めてください。

テストから学んだことを活用してプランを改善します。発見した問題にはできるだけ早く対処してください。イベントまで続くエンジニアリング ワーク プランニングにおいて事後分析からのアクション アイテムに優先順位を付けます。コミュニケーションと情報のフローの問題は、このイベントをリモートで管理するチームの機能に特に大きな影響を与えるため、特別な注意を払ってください。

ステップ 2: イベント中

準備が完了し、ビッグイベントのときが来ました。すでに十分に準備を整えたので、次はイベントを円滑に運営することが目標です。ただし、リモートの共同作業により仮想指令室に影響を与える、いつもとは異なるコミュニケーション、アクティビティ ロギング、エスカレーション管理方法を必要とする主な要因に留意することが重要です。

コミュニケーション

仮想指令室運用中のコミュニケーションについては、その重要性を重ねて強調しなければなりません。厳格な手法での準備とそれによって確立したルールにより、サービス停止を解決する時間に差が出ます。

イベント期間中は、1 つのチャットルームを設けてコミュニケーション戦略の中心とします。実際にサービス停止が起きた場合に特定の問題に特化したチャットルームをすぐに追加できるようにします。たとえば、テクニカル チーム専用のチャットルームを設けることが非常に有効な場合があります。

コミュニケーション リードを 1 名任命します。 Google のインシデント管理トレーニングのなかで、大規模なサービス停止中にコミュニケーション リードを任命することは必須です。この担当者は、全員からの問い合わせを受け付けてあらゆる最新情報を提供し、チームメンバーがそれぞれの役割に専念できるようにします。すでに述べたように、コミュニケーション リードは、イベントの最新情報をすべて 1 か所にまとめた「イベント最新状況」ページを定期的に更新するとよいでしょう。

最後になりましたが、シフト引き継ぎ時の情報伝達について注意を払うことは特に大切です。最新状況のページとログを使用することにより、引き継ぎは楽になります。ただし、コミュニケーション リードや意思決定者のような役割のシフト引き継ぎの場合は、常に引き継ぎを受ける側(次のシフトの担当者)から確認を明確に得るようにします。準備フェーズにおいて作成した連絡先リストには、仮想指令室運用中の呼び出し待機のため、すべてのチームメンバーが記載されている必要があります。シフトを終えて引き継ぐチームは、現在のシフトと次のシフトのチームの人員情報について指令室に伝えるなどの引き継ぎ業務を行う必要があります。

ロギング

イベント中に起きたことを事後に簡単に振り返るために、回顧録や事後分析の報告を記す際には、起きたことをすべて記録するようにしてください。チャットルームは必ず履歴記録を有効にしておいてください。専任の記録者を任命しますが、すべてのメンバーが実施されたアクションと気づいた事柄を記録するようにしてください(その際は Google フォームを使うと便利です。テキスト フィールド 1 つという最もシンプルなフォームを設定し、タイムスタンプが記録されるようにします。情報は全員が入力するように促してください。重複する情報は後で削除できます)。

ステータスの更新には、必ず一定間隔を設定してください。特に何も起きなくても更新を行ってください。

エスカレーション

想定内の緊急事態と想定外の緊急事態に対処できるよう準備を整えます。指示を発する専任の意思決定者が 1 名のみ常に存在するようにします。同時に複数の人員が勝手な意思決定や方針変更ができるような状況では、事態を悪化させ、サービス停止が長引く可能性が高くなります。

現場でもリモートでも、サービス停止に対処する手順は重要で、ぜひ習得すべきです。インシデントに対応する手順を学習する場合は、SRE ブックのインシデントの管理のチャプター、およびフォローアップの SRE ワークブックのインシデントへの対応のチャプターから始めるとよいでしょう。

ステータス 3: イベント終了後

イベントが終了したら、プロセス全体の事後分析を実施します。収集するべき情報は、うまくいった点、うまくいかなかった点、運がよかった点の 3 つです。

これら 3 点のすべてについて、情報収集を行います。その際、誰かを非難する形にならないように注意してください。「X さんがそれをした」のような表現は避け、「それが行われた」のように表現します。監査証跡を付帯するには、コードや監査ログへのリンクを追加します。ただし、このドキュメントの目的はシステムの問題点と成功した点を強調することで、人を名指しすることではありません。

この事後分析は、仮想指令室自体についてに焦点を当てるべきです。事後分析には、イベント(例: 100 万ドルの収益獲得)と仮想指令室のオペレーションについてという 2 つのトピックをおすすめします。前述の 3 点を記載する際には、以下の内容を参考にしてください。

  • コミュニケーションはうまくいきましたか?何がいつ起きているかについてすべてのメンバーが把握していましたか?

  • サービス停止に陥った場合でも、通常のフローが適用されましたか?

  • 全員に適切な権限が与えられていましたか?

  • 何をいつ実施するべきかを全員が理解していましたか?

  • コミュニケーションはいろいろな媒体で行われましたか?あるいは 1 つのスペースで行われましたか?

  • ベンダー各社とのコミュニケーションはうまくいっていましたか?

  • 指令室は適切な期間運営されていたと思いますか?

  • 通常時にも応用できる教訓がありましたか?


イベントや指令室に関わったすべての人員が情報や意見を提供できるようにします。ただし、そのうちの 1 名をオーナーとしてください。全員が報告作成に参加したのちに、会社全体に公開し、全社員が仮想指令室の運営から学べるようにします。

事後分析の報告方法の詳細については、以下の資料をご覧ください。

上述のアプローチは難しいと思われるかもしれませんが、適切な手法に従い、組織としてのマインドセットを持っていれば、年末商戦で成功を収め、即応体制がありセキュリティの高い仮想指令室の土台を築くことができます。もちろん、Google Cloud チームがサポートいたします。ブラック フライデー / サイバー マンデーやその他の今後のイベントの準備の詳細、また一般的なリスク管理のベスト プラクティスについては、貴社内のテクニカル アカウント マネージャーまたは Google Cloud アカウント チームにお問い合わせください。


このブログ投稿に協力してくれた Yuri Grinshteyn(CRE サイト信頼性エンジニア)、Nat Welch(CRE サイト信頼性エンジニア)、Ahsan Khan(プログラム マネージャー)、Dan Tulovsky(CRE サイト信頼性エンジニア)、Fabian Elliott(テクニカル アカウント マネージャー)に感謝します。

-Google Cloud テクニカル アカウント マネージャー Nelly Wilson

投稿先