厳格なリリース管理は悪か？

皆さんの組織ではどの様にリリース管理を行っているだろうか。変更承認委員会 (Chanve Advisory Board) のような厳格なリリース承認プロセスを通して実施しているだろうか。現場の裁量でリリース計画を立て、関係者に周知すればリリースできるだろうか。それとも、プロセスなどなく気の向くままにリリースをしているだろうか。

この記事では、あるべきリリース管理について、自分なりの考え方を話したいと思う。

CAB の予期せぬ副作用

ここで一つ非常に物議を醸し出すデータを提示したいと思う。CAB による厳格なリリース管理は、リリースの成功率に寄与しない。むしろ、障害発生時の復旧を遅くしてしまうというものである。

Nicole Forsgren らの書籍 Accelerate (邦題: Lean と DevOps の科学) では2014~2017 年にかけて実施された 23,000 件に渡る膨大な調査に基づき、システムのリリースに関して高いパフォーマンスを上げる組織と低いパフォーマンスに甘んじる組織について述べている。その中で著者らは以下の様に述べている。

We investigated further the case of approval by an external body to see if this practice correlated with stability. We found that external approvals were negatively correlated with lead time, deployment frequency, and restore time, and had no correlation with change fail rate.

LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)

これは厳格なリリース管理プロセスを運用している組織にとっては耳の痛い話だ。意味がないどころではない。逆効果というのである。これはどうしたことだろうか。

現場は変更を知っている

これはよく考えれば分かる話だ。現場は変更を知っている。変更がどこに影響しうるのか、そのリスクがどの程度か、正確に判断できるのは誰だろうか。第三者だろうか、それとも開発に携わった現場だろうか。答えは自明である。

一昔前のドラマから有名なフレーズを借りてくるのならば「変更は会議室で作られるのではない。現場で作られる」のである。どんなに賢い人材を配置したところで、現場に勝る判断をするのは本来難しいはずなのである。

変更管理は厳格であるべきだ。ただし現場の知恵によって

自分は、変更がうまく行っている組織とそうでない組織の両方で働いた経験がある。

変更がうまく行っている組織では、現場の知恵と力強いリーダーシップによって変更が実施されていた。リリース手順は厳しくピア・レビューで確認される。リスクの高い DDL は事前に DBA を巻き込み、変更手順の確認や実施時間の調整などが行われる。変更はまずカナリアにリリースされ、完全に自動化されたテストを実施し問題がないことが確認される。そして、問題がなければ本番環境にブルー・グリーンデプロイがなされる。100%ではないものの、リリースが失敗することは頻繁ではなかった。それ故に、事前にリリース計画を周知しておけば文句を言われることはなかった。

変更がうまく行っていない組織では、現場で変更とリスクをきちんと評価することができず、度々障害を引き起こしていた。他のシステムへの影響や依存関係を把握しないままリリースをしたり、重要な商売の途中でリスクの高い変更をして障害を引き起こしていた。次第に重厚な統制プロセスが求められていった。問題は、カナリア環境で実施される自動テストではなく、しばしば顧客からのクレームという形で検知された。

以上の経験を基にした自分の持論は以下の通りである。変更管理は厳格であるべきだ。ただし現場の知恵によって。

変更管理をビジネスやマネジメントから委任してもらうには信頼が必要になる。現場はリスク・コントロールや安全に変更を実施するための技術的な仕組みをリードし、信頼を勝ち取る必要がある。エンジニアとしての知恵と力量が試されるところである。もしこうした信頼を勝ち取ることができれば、組織は安定したリリースを実施し、障害が発生したとしても素早く復旧することができるだろう。加えて、継続的に新しい価値を顧客に提供できるようになるだろう。

原文:

yuichi-murata.medium.com