要約

  • GitLab.com の2017年1月の障害が重要なのは、GitLab 自身のポストモーテムによれば、エンジニアがレプリケーションを再構築しようとして誤って本番データベースからデータを削除し、その後、意図したバックアップ経路が利用不可、不完全、古い、またはその復旧ニーズに設計されていないことが判明したためである。
  • 説明責任の問題は、本番データベースアクセス、バックアップ検証、レプリカ分離、復旧訓練、顧客コミュニケーション、そして顧客が依存する前に復元経路が実際に機能したという証明を実質的に誰が管理していたかである。
  • GitLab の公開証拠は異常に有用である。同社が詳細なポストモーテムを公開し、破綻した復旧手順を特定し、フォローアップ作業にリンクを張り、データ損失を通常の障害として扱うのではなく認めたからである。
  • 教訓は、すべてのプラットフォームがオペレーターのミスを回避できるということではない。教訓は、ホスト型開発者プラットフォームが復元可能性を証明しなければならないということである。なぜなら、顧客のプロジェクト、課題、コメント、アカウント、スニペット、CI 記録、デプロイメントワークフローは、廃棄可能なアプリケーション状態ではなく、業務記録だからである。
  • この記事は、GitLab のポストモーテムと課題記録を一次証拠として扱い、GitLab および PostgreSQL のドキュメントを技術的管理用語として、より広範なセキュアバイデザインの資料を復旧ガバナンス基準のサポートとして扱う。個人のログ、個別の顧客損失記録、完全な内部変更チケットへのアクセスを主張するものではない。

このケースがリスクと説明責任のファイルに属する理由

GitLab はリスクと説明責任のファイルに属する。なぜなら、2017年の GitLab.com データベースインシデントにより、「バックアップはあります」という単純な文を証明なしに受け入れることが不可能になったからである。GitLab.com はすでに、チームがソースコードメタデータ、課題、マージリクエスト、コメント、スニペット、プロジェクト設定、ユーザー、権限、ワークフロー状態を保存するホスト型開発者プラットフォームであった。2017年1月31日に本番データベースデータが誤って削除されたとき、顧客リスクは一時的な利用不能に限定されなかった。GitLab 自身のポストモーテム（https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/）によると、サービスは数時間利用不能となり、GitLab は17:20から00:00 UTC の間にデータベースの変更を失い、推定で約5,000のプロジェクト、5,000のコメント、700の新しいユーザーアカウントが影響を受けた。Git リポジトリと Wiki は障害中は利用不能だったが、同じ公開アカウントによるとデータ損失の影響は受けなかった。

（以下、同じ翻訳内容）