継続的デリバリの計測方法

継続的デリバリを導入する場合、安定性とスループットを計測できる。このふたつのメトリクスは不確実性を減らし、どのようなやり方を拡大したり縮小したりするべきかについてより良い選択肢を提示し、継続的デリバリのプロセスを正しい方向に進めるのに役に立つ。

継続的デリバリのコンサルタントであるSteve Smith氏はLean Agile Scotland 2017で継続的デリバリを計測することについて話す予定だ。このカンファレンスはエジンバラで10月4日から10月6日に渡って開催される。

InfoQは氏にインタビューし、継続的デリバリを難しくする要因、継続的デリバリに役立つメトリクスについて、何を計測するか、イギリスの政府部門でメトリクスを使ったことから得られた学び、GoogleのSREのコンセプトである"エラー予算"と継続的デリバリの関連について、話を聞いた。

InfoQ: 継続的デリバリを難しくする要因は何でしょうか。

Steve Smith: 私はいつも、継続的デリバリをする人にはふたつのタイプがある、と言っています。これが難しいことだと理解している人とそこから目を背けている人です。継続的デリバリは難しいです。多くの技術を投入しようとしなければならないですし、組織的な変化を持ち込まなければならないからです。

自動のデータベースマイグレーションのような自動化された変更処理の部分が難しいのではありません。使うツールを選ぶのが難しいのでもありません。本当に使えないものを選ばなければ、ほとんどのツールは間違いなく使えます。組織特有の状況と制約の中でこのような変化を起こすことが難しいのです。継続的デリバリは組織によって異なります。このことを最初から認識しておく必要があります。

InfoQ: メトリクスは継続的デリバリにどのように役に立ちますか。

Smith: メトリクスがあると不確実性が減ります。より良い意思決定ができるようになります。導入プロセスが正しい方向に向かっているかどうかを理解する助けにもなります。

私は顧客にはImprovement Kataから始めることを推奨しています。これは働き方を反復的かつ漸進的に改善するためのサイクルを作ります。ビジョンを設定した場合、そこからどのくらい離れているのかはどうしたらわかるでしょうか。次の改善のマイルストンを作りたい場合、どのような目的のものを作れば良いのか、どうしたらわかるでしょうか。自動のデータベースマイングレーションのような実験的な変更をした場合、現在より良くなったことをどのようにして知ることができるでしょうか。

メトリクスはこのようなことに答えを与えてはくれません。しかし、どこに答えがあるかをガイドしてくれます。私は、2年半、イギリス政府部門で働いていました。継続的デリバリを実現するべく、60のチームが働いていました。メトリクスなしでは、私たちはどのチームが良くやっていて、どのチームに支援が必要で、どの施策を拡大し、どの施策を縮小するべきかわかりませんでした。私たちが使ったメトリクスはどのチームと話をする必要があるか、どんな話をするべきかを示してくれるものでした。

InfoQ: 何を計測するべきでしょうか。

Smith: 継続的デリバリはリリースプロセスの安定性とスピード改善を実現するためのものです。したがって、当たり前の答えになってしまいますが、安定性とスピードを計測すればいいのです。安定性もスピードも無形です。しかし、計測するのは難しくはありません。How To Measure Anythingという書籍で、Douglas Hubbard氏は解明の鎖を使って無形のものを計測する方法を示しています。形あるものを作り、同じものを表現する関連するメトリクスを作ります。

幸運なことに、計測方法はわかっています。年次のState Of DevOps ReportでNicole Forsgren氏、Jez Humble氏らは、企業が継続的デリバリのプロセスを導入することで安定性とスループットがどのように改善したかを計測しています。彼らは故障率と復旧時間で安定性を計測し、リードタイムと頻度でスループットを計測しています。私は2013年からお二人の仕事の大ファンです。お二人が使っている計測と、それをどのように継続的デリバリに関連させているかについて深く調べました。この計測方法は私のおすすめです。

InfoQ: 政府部門のメトリクスを使ってたことで何を学びましたか。

Smith:メトリクスなしで継続的デリバリを実践するのは、監視なしで運用をすることと似ていることを知りました。メトリクスがなければ、目隠しして空を飛ぶようなものです。どの変更が成功し、どの変更を拡大するべきか、どの変更が失敗し、できるだけ早く元に戻す必要があるか、を理解できません。

このイギリス政府部門では、各チーム、すべてのサービスのために安定性とスループットの指標を示す社内のウェブサイトを作成しました。それは、あらゆる種類の興味深い会話へのポインタと、問題へ洞察を与えました。たとえば、あるチームが短期間で展開の安定性を大幅に向上させました。私には、彼らが何をしたのかははっきりしていませんでした。唯一の小さな違いは、独自のカスタムログと監視ダッシュボードがあることでした。ダッシュボードJSONを抽出し、DSLを作成して同じJSONを生成し、全国のすべてのチームとサービスに配布しました。数週間以内に、複数のチームが、生産サービスの運営がより簡単になったと報告しました。このウェブサイトは興味深い会話を生み出します。また、普段は起きない問題に対する洞察を生み出します。例えば、チームが短い期間でデプロイの安定性を大幅に改善したとき、私は彼らがどんなことをしたのかがわかりませんでした。彼らにはカスタムのロギングとモニタリングダッシュボードがあったのです。私たちはそのダッシュボードのJSONを抽出し、同じJSONを生成するDSLを書いて、すべてのチームとサービスに展開しました。数週間後、複数のチームがプロダクション環境の運用が楽になったと報告してくれました。

InfoQ: GoogleのSREの"エラー予算"というコンセプトについてはどうお考えですか。継続的デリバリのメトリクスとどのような関連があるでしょうか。

Smith: Site Reliability Engineeringの書籍はとても素晴らしいです。興味深いことにBetsy Beyer氏を含む著者は信頼性をMTBFとMTTRの関数として定義しています。これは、継続的デリバリの安定性の定義、つまり、故障率と復旧時間の関数と同義です。

エラー予算も良いアイディアだと思います。私はいつも、プロダクトオーナーに運用の要件を定義し、その中にプロダクトの信頼性の要件を含めるようにアドバイスしています。この逆をリスクテイクの許容量として使うことは役に立つかもしれません。継続的デリバリを実践しているチームが同じようなことをしていたら面白いと思います。厳密にリリースの安定性とスループットを計測し、ある閾値を下回ったらプロダクションへの自動デプロイを止めているというチームです。静的な解析とOWASPのテストで過去のビルドをスコア化している企業もありました。過去の配置の安定性に基づいて実行する配置をスコア化をするというのは見たことがありませんが、良いと思います。