システムの段階リリースはいつ広げる？ 試験対象と観測の確認点
新機能を一部へ公開し、監視に異常はない。けれど、月末の請求はまだ一度も処理していない。そんな仮定で、次の公開範囲へ進めるでしょうか。利用者の割合だけでなく、通した業務、実行回数、新旧版の比較から、何を確かめられたのかを見ていきます。
この記事の目次
月末をまだ通していない「異常なし」をどう読むか
判断したいのは段階公開をするかしないかではなく、どの状態なら次の段階へ進み、どの状態なら止めるかである。受け手に代表性があり、意味のある指標を観測でき、戻せるなら段階公開で学ぶ。重要な経路を試せず、戻す操作がデータを壊すなら、拡大を急がない。小さく出すという手段を、確認の代用品にしない。
実行回数が少ないと、何を見逃し得るか
公開対象を1％にして一時間観測しても、その間に請求締めの処理が一度も実行されなければ、請求への影響は未観測のままだ。通した利用者数と、通した処理の種類を分けて数える。ここで問うのは戻し方の互換性ではなく、観測が変更の影響を含んでいるかである。
検出限界を計算してみる。一件ごとの失敗確率を0.1％、独立した100件、失敗を完全に検出できる条件と置くと、少なくとも一件見つかる確率は1−0.999の100乗＝約9.5％。1000件でも約63.2％だ。この条件計算は実際の障害確率を推定していないが、少数の「異常なし」が低頻度の不具合に弱い理由を示す。締め処理を通す試験や対象の分け方を変える案を、単に時間を延ばす案と比べたい。
新旧のデータをどう戻すかは戻し方と互換性で扱う。こちらの公開判定には、対象の処理、比較群、実行回数、未観測の場面を残す。未観測を「合格」へ置き換えない。
次に広げる相手と、未観測の業務を決める
最初の公開対象を社内の協力的な利用者だけにすると、報告を集めやすい一方、実際の顧客の入力や権限と違う。対象を大きくしすぎれば問題時の影響が増える。まず想定する利用者群と仕事の種類を書き出し、少数でも重要な経路を含められるかを検討する。頻度が低いが失敗時の損失が大きい処理は、自然に現れるのを待つだけでは足りない。隔離した環境で代表的なデータを用いて事前に試す。
それでも本番のすべてを再現できない。だから「この公開で何は見ていないか」を報告する。夜間だけ動くバッチ、月末の締め、外部の会社との通信、障害後の再送などが候補になる。ある段階で観測できなかった種類の仕事は、次の段階の拡大を正当化する証拠に含めない。検知の穴が大きいなら、単に対象割合を増やす前に試験の時間帯やデータを変える。
新旧版の違いと、受け取った案件の違いを分ける
Google SREのカナリア公開解説は、新旧版へ分けた実際のトラフィックを比べ、候補版のエラーが増えるかを見る方法を説明する。全体のエラー率だけでは、少数の候補版で起きた異常が薄まる。版別の応答、遅延、対象業務を分けて測る必要がある。ただし同章はGoogleの運用経験に基づく説明であり、どの会社でも一定の割合で必ず検出できるという実験結果ではない。
同章は、少数の問い合わせしか当たらない公開では多様な機能の不具合を見つけられず、夜間の低負荷では性能問題が出ない点も挙げる。監視の集計窓が公開時間より長ければ、古いエラーと新しい変更の影響を混ぜるかもしれない。段階公開の割合だけを議論せず、対象者、業務の種類、負荷、観測時間、比較用の旧版を設計する。
新旧版を比べるときの落とし穴
新しい版だけが難しい案件を受け取るなら、エラー率の差は変更そのものではなく案件の違いかもしれない。逆に新しい版を熟練した社内利用者だけが使えば、実際の顧客のつまずきを見逃す。可能なら同じ時間帯で似た業務を比べ、利用者群の違いを記録する。比較が難しいときは「旧版と同じだから安全」と断言せず、個別の成功と未検証範囲を示す。
公開中にシステム全体で障害が起きることもある。旧版でも同じエラーが増えたなら、新版固有の問題とは限らない。ただし共通基盤へ新機能の負荷が波及することもあるため、旧版のエラー増を完全に無関係と扱わない。どの変更が共有資源へ影響するか、データ構造やキャッシュも含めて関係を調べる。版ごとの監視と全体の監視は、片方だけでは足りない。
仮想例で公開の順番を変える
以下は仮想例であり、実在の障害ではない。社内検索画面の表示順を変える。結果は読むだけで、旧画面へ戻す操作が容易であり、部署や文書の種類をまたぐ試験群を用意できる。この場合は少数へ公開し、検索失敗、再検索、問い合わせを旧画面と比べながら広げられる。少数で学べる条件がそろっている。
条件を変える。給与計算の締めで使う新しい端数処理を公開する。月中の利用者へ小さく出しても、月末の本番条件を踏まない。計算結果は下流の振込ファイルへ進み、後から画面だけ戻しても修正できない。この場合、少数公開だけで合格にせず、代表的な締めデータを使う隔離試験、旧新の結果照合、問題が起きた際の手修正と停止経路を優先する。段階的に出すとしても、締めの一巡を見てから広げる。
広げる条件と、止める担当をそろえる
Microsoft Azureの安全な公開指針は、小さく広げることに加え、各段階の健康状態を確認し、異常が出たら公開を止めて復旧する設計を勧める。指針は合理的な管理方法を示すが、導入すれば事故が何％減るという数値は出していない。事前に観測する指標と停止の責任者を決めなければ、「様子を見ながら広げる」は運用者の勘に戻る。
復旧できる範囲も公開前に確認する。表示だけの変更は機能フラグで戻せる場合があるが、保存形式の変更や外部へ送った通知・請求は、画面を旧版へ戻すだけでは復旧できない。可逆な変更、補償を伴う復旧、戻せない変更を分け、戻せない部分には強い事前検証や人による確認を置く。
停止後の仕事も設計する
観測で異常を見つけたときに止められるよう、公開時間帯の当番と停止権限を決める。停止後の取引照合やデータの戻し方は、切戻しとデータ互換性で詳しく扱う。ここで決めたいのは、どの業務を観測できたら次の公開範囲へ進めるか、という条件である。
観測したことから、次の公開範囲を決める
運用者が見るべきものは技術エラーだけではない。処理が成功と表示されても、利用者がやり直す、後工程で差戻しになる、別の担当者へ電話して補うなら、公開の目的を達していない。公開前に「影響を受ける一件が完了する」までの追跡方法を決める。低頻度の重大事故は、小さな群と短い時間では観測できないと明記する。観測しなかったことを、起きないことと取り違えない。
拡大のたびに、三つの問いを確認したい。第一に、この段階で試した利用者と業務は次の段階を代表するか。第二に、旧版と比較できる品質・待ち・業務完了の信号はそろったか。第三に、異常を発見した時に誰が止め、何をどこまで戻せるか。どれかが空欄なら公開規模を保つか、先に試験設計を変える。
段階公開は、比較可能な信号を得られるときに影響範囲を抑える優れた方法だ。小さな群に重要な使い方が含まれず、データ変更が戻せない場合は、それだけで安全とは言えない。広げる判断を「何も起きなかった」に任せず、何を見て、何が見えず、失敗時にどこまで戻るかで決める。