Looker core instance 削除時の 7日間保持

Looker のリリースノートでは、Looker (Google Cloud core) instance を削除した際、完全削除前に 7日間 trash へ移る変更が示されました。誤削除や復旧手順に関わる運用変更です。

要点

• Looker (Google Cloud core) instance を削除すると、即時完全削除ではなく 7日間 trash に移るようになりました。
• 管理者にとっては、誤削除からの復旧余地が増える一方、削除完了までの状態管理が必要になります。
• 既存の削除手順、権限、監査、コスト、データ保持ポリシーを確認する必要があります。

今回のリリースノートで語られていること

今回の Looker release notes は、Looker (Google Cloud core) instance の削除挙動に関する変更を示しています。インスタンスを削除した場合、すぐに完全削除されるのではなく、7日間 trash に移動してから完全削除されるという内容です。BI基盤では、インスタンス削除は影響が大きい操作です。ダッシュボード、モデル、接続、権限、スケジュール配信、埋め込み利用、監査ログなどが関係するため、誤操作や手順ミスが起きたときの復旧余地は重要です。

7日間の trash 保持は、管理者にとって安全網になります。誤って削除した場合や、削除後に依存システムへの影響が見つかった場合、完全削除までの間に復旧や確認の余地が生まれます。一方で、削除操作が「すぐに消えた」とは言えなくなるため、データ保持、コスト、コンプライアンス、内部承認の観点では、trash 期間を含む手順へ更新する必要があります。完全削除がいつ起きるか、trash 中のインスタンスに誰がアクセスできるか、復元できる範囲は何かを確認したいです。

実務では、削除手順書と権限設計の見直しが必要です。本番インスタンス、検証インスタンス、不要になったプロジェクト環境で同じ削除プロセスを使ってよいか、削除申請と承認にどの証跡を残すか、復元判断を誰が行うかを決めておくと安全です。Looker をGoogle Cloud coreとして運用しているチームは、この変更を単なる便利機能ではなく、インスタンスライフサイクル管理の変更として扱うべきです。削除前の依存関係確認、trash 期間中の復元判断、完全削除後の証跡保管までをひとつの手順にしておくと、誤操作時の対応が明確になります。

今回のリリースノートが関係する人

Looker (Google Cloud core) を管理するBI管理者、Google Cloud 管理者、インスタンス削除や環境整理を担当するデータプラットフォームチームに関係します。

実務で確認したいポイント

• trash 期間中の復元可否、アクセス権限、完全削除のタイミングを確認する。
• 本番・検証環境の削除申請、承認、監査ログ、復元判断を手順に入れる。
• データ保持ポリシーやコスト管理上、trash 期間をどう扱うか整理する。

結局、今回のリリースノートをどう読むべきか

Looker core instance の 7日間保持は、誤削除リスクを下げる一方で、削除状態の管理を増やします。管理者は、削除手順を trash 前提へ更新したいです。