本番稼働チェックリスト

本番環境の施設でパートナー連携を有効にする前に、このチェックリストを使用してください。

Partner Console の設定

  • パートナープロフィールの入力が完了している。
  • ロゴの URL、Web サイト、カテゴリ、説明が正確である。
  • データのリンク方法(Direct Link または Linking Identifier)が設定されている。
  • 少なくとも 1 つの実際の施設で施設のリンクがテスト済みである。
  • 適切な種類のキーを使用している。
    • 非破壊的な書き込みテストには Dryrun。
    • データを安全に利用するには Read-only。
    • 本番データに影響を与える準備ができた場合にのみ Live。

認証とキーの管理

  • シークレットキーはサーバー側にのみ保存されている。
  • キーがクライアントサイドのアプリケーション、モバイルアプリ、公開リポジトリ、サポートチケットに埋め込まれていない。
  • キーのローテーションと失効がテスト済みである。
  • 各環境でどのキーが使用されているかをチームが把握している。

データの検証

  • 呼び出すすべてのエンドポイントで必須フィールドが含まれている。
  • 施設識別子が設定済みのリンク方法と一致している。
  • お使いのシステムの ID が安定しており、同期ごとに変わらない。
  • 大規模なインポートが、ドキュメントに記載された上限内のバッチに分割されている。
  • バッチ内の失敗した項目を特定して再送信できる。

エンドポイントのテスト

リリース前に、連携が依存するすべてのエンドポイントをテストしてください。

  • 組織と施設を読み取れる。
  • 会員を保存、更新できる。
  • 会員プラン、アクセスゾーン、アクセス時間が正しく同期される。
  • チェックインが受け付けられ、お使いのシステムと関連付けることができる。
  • レポートのスナップショットで、想定どおりのレポート期間と指標が使用されている。
  • 該当する場合、ドア/ゲートコントローラーのフローが実際のハードウェアでテスト済みである。

Access Time Window の準備

連携で Access Time Windows を提供する場合:

  • 絶対的なウィンドウと週次のウィンドウの例が、プロデューサー認定チェックリストに合格している。
  • エポックが引用符なしの整数(Unix 秒)であり、[from, to) の境界が正確にテスト済みである。
  • UTC の既定値、連携独自の IANA タイムゾーン、関連する夏時間の切り替えが検証済みである。
  • 永続的で単調増加する 1 つの会員/ソースのリビジョンストリームによって、差分更新、照合、再試行が調整されている。
  • 省略、完全な置き換え、冪等、競合、古いデータ、明示的な [] の各動作をオペレーターが理解している。
  • default を含むすべての scope_key に承認済みの Performance Hub のマッピングがあり、不明なキーが拒否側に倒れることがテスト済みである。
  • 連携で想定される更新の頻度、ソースデータの最大経過時間、ソースデータが古い場合の動作、アラートが設定されている。
  • 上流からの取得に失敗しても、空または部分的なスナップショットが送信されないことが確認済みである。
  • ステージングでのストリームの収束、キャンセル/失効、物理ドアでの開始/終了の境界が、合意した目標を満たしている。
  • 通常のルールと恒久的な許可がフォールバック経路として機能することが検証済みであり、ウィンドウによってユーザーの無効化、blockAllAccess、メンテナンス、ジオフェンスが回避されない。

アクセスコントロールの準備

アクセスコントロールの連携の場合:

  • Performance Hub を呼び出す前に、お使いのシステムがアクセスの判断を行う。
  • 連携で device_offline、maintenance_mode_active、unlock_confirmation_timeout を処理している。
  • タイムアウトは解錠が確認されなかったことを意味する、とオペレーターが理解している。
  • 返された event_id と command_id がログに保存されている。
  • 施設のスタッフ向けに、手動でのフォールバック手順が用意されている。

エラー処理と再試行

  • 400、401、403、404、409、422 のレスポンスは、むやみに再試行せず、オペレーターまたはサポートチームに通知される。
  • 429、500、502、503、504 のレスポンスでは、バックオフを伴う上限付きの再試行ロジックを使用している。
  • 失敗が繰り返されると、お使いのシステムでアラートが作成される。
  • 連携が失敗したレコードを通知なしに破棄することがない。

可観測性

  • ログに、エンドポイント、タイムスタンプ、施設識別子、ソースレコード ID、リクエストの結果、レスポンス本文が含まれている。
  • サポートチームが会員 ID、施設 ID、チェックイン ID、解錠イベント ID で検索できる。
  • 失敗した同期を再実行または照合する手段がある。

本番リリース

  • Performance Hub が本番環境へのアクセスを確認している。
  • 少なくとも 1 つの本番環境の施設で連携が有効になっている。
  • 本番用のキーが有効である。
  • 運用担当者と技術担当者の連絡先が最新である。
  • お客様向けにサポート手順が文書化されている。

これらのチェックが完了すると、設定した連携が Performance Hub のコアプラットフォーム内にある Performance Hub パートナーディレクトリに表示されます。