[Quip] Quip の災害復旧ポリシーについて

アップタイムと障害からの復旧は、当社の成功にとって極めて重要です。お客様は可能な限り高い可用性を期待しており、当社のポリシーと行動は、顧客データに対して可能な限り高いアップタイムと可用性を確保することを目指しています。

危機対応

重大な本番環境またはセキュリティの問題が発生した場合、社内のオンコールエスカレーション手順に従い、目標応答時間は15分です。

情報セキュリティの問題については、オンコールの運用担当者へのエスカレーションに加えて、直ちにCEOまたはエンジニアリング責任者にエスカレーションされます。

重大なセキュリティまたは本番環境の問題が発生した後、DevOpsチームが問題の事後検証を実施し、オンコールおよびエンジニアリングスタッフがレビューします。問題が顧客データに関連する場合、レビューの結果は対象のお客様と共有されます。

詳細については、情報セキュリティポリシーを参照してください。

顧客データの復元

Quipは、すべてのユーザーデータの複数のオフサイトバックアップを保持しています。増分バックアップ（5分以内のもの）と日次スナップショットの両方を維持しています。

バックアップポリシーと顧客データの可用性の詳細については、バックアップポリシーを参照してください。

サイト全体は、任意のバックアップ（増分またはスナップショット）から復元できます。

災害復旧

サービス停止や災害に対応するため、多層システムを実装しています。

1. システム上のすべてのフロントエンドには複数のレプリカがあるため、単一のフロントエンドがサイトを利用できなくすることはありません。

2. すべてのデータベースは複数のインスタンスにシャーディングされているため、単一の顧客またはデータの問題がすべてのお客様に対してサイトを利用できなくすることはありません（例：分離）。

3. システム上のすべての重要な読み取りは、別のデータセンターにあるセカンダリデータベースへのトランザクション的に一貫性のあるフェイルオーバー読み取りです。これにより、単一のデータセンターでの短期的なサービス提供の問題がデータへのアクセスに影響を与えません。

4. すべてのデータベースはマルチAZ RDSデータベースであり、リージョンでの利用不能または停止が発生した場合に自動的にフェイルオーバーします。

5. 複数のアベイラビリティゾーンにわたるRDSの障害によりRDSサービスが利用できなくなった場合、Quip独自のセカンダリレプリカサーバーに手動でフェイルオーバーします。これらは独立したインスタンスであり、通常のRDSシステムの完全な停止に耐えることができます。

6. RDSと当社独自の独立したセカンダリインスタンスの両方で壊滅的な障害が発生した場合は、スナップショットまたは増分バックアップから新しい一連のデータベースサーバーに復元します。

上記の災害復旧システムでは、ステップ1から5は10分未満で完了できます。5つの層すべてで障害が発生した場合、最終的なステップ6は約1時間で完了できます。

継続的な復旧テスト

復旧システムが適切に維持され、機能することを確認するため、運用チームは上記のフェイルオーバー手順を四半期ごとにテストします。

上記のシステムをさらにテストするため、「災害復旧」モードで実行される別の社内Quipサーバーセットを維持しています。これらの内部テストサーバーは、プライマリデータベースの停止をシミュレートします。これらのサーバーを定期的（週次から月次）にテストし、サイトがプライマリDBの停止に耐えながら、すべてのユーザーデータを提供し続けられることを確認します。

手順のレビュー

すべての災害復旧システムと手順は、Quipの運用担当者によって四半期ごとにレビューされます。

すべての災害復旧ポリシーは、エンジニアリング責任者によって四半期ごとにレビューおよび更新されます。