Skip to content
Tech

デプロイ済みサービスがスキーママイグレーションに耐えられるかを確認する前に、マイグレーションが実行されてしまうのはなぜか?

83

機会

本番データベースにスキーマ変更をプッシュすると、現在稼働中のサービスバージョンが新しい形式を読み書きできるかをどのツールも検証する前にマイグレーションが実行される。削除されたカラムや名前変更されたフィールドは古いポッドのドレインが完了する前にデータベースに反映され、ロールバックでスキーマは復元できてもその間に新バージョンが書き込んだデータは復元できない。ORMツールはdiffからSQLを生成するが、デプロイトポロジー、並行するサービスバージョン、ライブの読み書きパターンについては何もモデル化しない。チームはwikiやトライバルナレッジに記録されたエクスパンド・コントラクトの手順で補っているが、ツールによる強制はされていない。順序を誤った一つのステップが、昨年だけで複数サービスにまたがるカスケード障害と、記録に残る450万ドルのインシデントを引き起こした。

重要な理由

ライブサービストポロジーをモデル化した事前互換性チェックがあれば、デプロイにおける最もリスクの高いステップを、適用する前に論理的に検証できるものに変えることができる。

機会をどう評価するか

Opportunity Scoreは測定値ではなく、私自身の見解です。どれほど痛みを伴うか、どれほど頻繁に影響を与えるか、そして今日時点で解決策がいかに少ないか。スコアが高いほど、構築する価値が高いと私は考えています。

深刻度9/10

それが現れたときにどれほどの痛みをもたらすか。

頻度8/10

実際にどれほど頻繁に人々がそれに直面するか。

ホワイトスペース7/10

今日時点で、それに対する優れたツールがいかに少ないか。

解決する価値のある問題をもっと見る