Tech
デプロイ済みサービスがスキーママイグレーションに耐えられるかを確認する前に、マイグレーションが実行されてしまうのはなぜか?
83
機会
本番データベースにスキーマ変更をプッシュすると、現在稼働中のサービスバージョンが新しい形式を読み書きできるかをどのツールも検証する前にマイグレーションが実行される。削除されたカラムや名前変更されたフィールドは古いポッドのドレインが完了する前にデータベースに反映され、ロールバックでスキーマは復元できてもその間に新バージョンが書き込んだデータは復元できない。ORMツールはdiffからSQLを生成するが、デプロイトポロジー、並行するサービスバージョン、ライブの読み書きパターンについては何もモデル化しない。チームはwikiやトライバルナレッジに記録されたエクスパンド・コントラクトの手順で補っているが、ツールによる強制はされていない。順序を誤った一つのステップが、昨年だけで複数サービスにまたがるカスケード障害と、記録に残る450万ドルのインシデントを引き起こした。
重要な理由
ライブサービストポロジーをモデル化した事前互換性チェックがあれば、デプロイにおける最もリスクの高いステップを、適用する前に論理的に検証できるものに変えることができる。
機会をどう評価するか
Opportunity Scoreは測定値ではなく、私自身の見解です。どれほど痛みを伴うか、どれほど頻繁に影響を与えるか、そして今日時点で解決策がいかに少ないか。スコアが高いほど、構築する価値が高いと私は考えています。
深刻度9/10
それが現れたときにどれほどの痛みをもたらすか。
頻度8/10
実際にどれほど頻繁に人々がそれに直面するか。
ホワイトスペース7/10
今日時点で、それに対する優れたツールがいかに少ないか。