型検査、テスト、静的解析が通っても、変更先の本番環境に十分な余裕があるとは限らない。たとえば、インデックスを作るSQL自体が正しくても、書き込みの多いテーブルでは作成中のロックが利用者に影響する。AIソフトウェアファクトリの検証ゲートには、差分の性質だけでなく、現在の本番環境でその差分が何を起こすかを調べる段階が必要になる。
Polylaneの本番影響レビューは、リポジトリとクラウド上のリソースを依存関係のグラフで結び、プルリクエストが影響しうるリソースを探す。変更差分、説明、コミット、対象リソースの設定とテレメトリを集め、変更を起点として特定の指標の悪化に至る因果関係を複数検討する。因果関係の各段階にはコードの行、設定値、ログ、メトリクスなどの根拠を付け、成立させる証拠と反証の両方を探す。
各因果関係は、本番データで裏付けられた「確認済み」、具体的だが証拠が足りない「可能性あり」、本番データによって起こりにくいと判断された「反証済み」に分けられる。Polylaneの実装では、確認済みの悪影響が一つでもあれば不合格となる。一方、「可能性あり」だけなら合格するため、合格を無害の証明と読み替えてはいけない。
この方法でレビュー結果を役立てるには、危険という判定だけで終えず、悪化する仕組み、その根拠、安全にするための変更を示す必要がある。記事の例では、書き込みのあるテーブルへの並行実行を指定しないインデックス作成が、作成中の書き込みを妨げると指摘し、並行実行による作成を提案している。これは本番境界の採否判断に使える証拠を作る作業である。
Polylaneは時系列予測も使い、対象リソースの過去の複数指標をまとめて予測する。ただし記事は、この機能を実験的なものと位置付け、効果を測定中としている。また、同社が報告する顧客あたり週2.3件の「防止した障害」は、危険の指摘後に変更が修正され、再審査に通ってマージされた件数を数える運用上の指標であり、修正前の変更が実際に障害を起こしたことを確かめた件数ではない。
https://polylane.com/blog/how-we-prevent-slop-from-hitting-prod/