8章 業務時間外のデプロイ

デプロイがおおごとになっているのは、デプロイ戦略に何か深刻な問題があることを示している場合が多いです。

耳が痛い。そして「おおごと」にしないために何が出来るのか、ここから先が楽しみです (hayase)

業務時間外のデプロイは、組織を守るためとして正当化されがちなアンチパターンです。このパターンを採用しても問題の根本解決にはならず、単なる対症療法にしかなりません。

最近マネージャーから無意味に「何故時間外にやらない」を言われるのは減った気はしつつ、現場レベルでまだまだ「説明にしにくいから」と時間外を選んでしまう(マネージャーに注意されそうと思ってしまう)ケースがあるように見えている。(98lerr)

8.1　苦労話

ソフトウェアのビジネスを考えると、新機能は基本的に在庫のようなものです。

作ってる間は、倉庫にあるのと同じ。小さくリリースしようとかの説明でどれだけの金銭を産むかの絵を描くのもよく見るけれど、この例えが伝わりやすい人もいそうなので覚えておきたい。(98lerr)

同意です (hayase)

システムリプレイスだと小さく始めにくいよね

大急ぎの機能

リリースが大きくなるということは、リリースの頻度が低くなるということです。チームは、次のリリースサイクルに間に合わせるために、機能を大急ぎでリリースに含める可能性があります。

リリース機会が少なく、すぐにリリースできない故に急がないといけないという皮肉な例として面白い。(98lerr)

8.2　デプロイのレイヤ

デプロイについて考えるとき、私はレイヤで考えることにしています。

機能、フリート、アーティファクト、データベースを分解して考えるのは大事だけれど、8.1の「リリースの詰め込み」が発生してると、ここを分ける話が蔑ろになることもあると思う。(98lerr)

https://scrapbox.io/files/65dc05ff30aaa400246a6d9e.png

8.3　デプロイを日常的に行う

しかし、環境を構成する方法は同じに保ち、違いとしてはパフォーマンスに特化したチューニングを施さないといった程度にとどめるべきです。

コスト節約したくなる一方、本番前をケチった結果、本番リリース時に想定しない動きが起きたりとか、あるいは本番前環境のケチった構成特有の問題が起きてそれが本番では再現しない説明に追われたりとか起きると後悔しかない。(98lerr)

フォーカスするべきはアーキテクチャ的に同じ環境を実現することです。

ここを考慮した上でケチったことの問題が起きたなら、それは設計想定外の動きなので良い学びと言えそう(98lerr)

些細な環境の違いは、すぐに積み重なってしまいます。

コードの品質と同じで、少しの妥協が次々に状況を悪化させますよね(hayase)

合成トランザクションは優れた選択肢であり、その環境を本番環境に近づけることを目指すものです。しかし、これがテストに関する悩みを解決する万能薬であると考えてはいけません。

ハッピーパスしか見ないことのほか、過去に合成トランザクションのアクセスログがノイズになった(アクセス先が連携しているシステムが合成監視を想定していなかった)ケースもあったので、事前調整も必要なのだと学んだ時があった。(98lerr)

8.4　頻繁に行うことで恐怖心を減らす

恐怖心が貯水池のようなもので、測定できるものだと考えてみてください。リリースの間の時間が長くなればなるほど、恐怖心はこの貯水池に蓄積されていきます。

デプロイパイプライン作っても、半年動かさない、一年動かさないと動かすことが怖くなる。(98lerr)

オンコール対応を委託した際に「障害頻度が少なすぎて対応を学ぶ機会が少ないから受けられない」と断られた時があった。(98lerr)

8.5　リスクを減らして恐怖心を減らす

開発チームがユニットテストを多く作成していることを確認してください。もしテストがほとんどないのであれば、ハックデイを提案すると良いでしょう。

この状態になってる時点で、wbsから遅れてるからハックデイ作る暇ないと言われそう。とはいえ、あらかじめ日を決めておくと「ハックデイにテスト書けばいいや」でテスト書かない習慣を作りそう。週次とかで投票でハックデイ開催有無を決めるくらいのバランスが良い？(98lerr)

これを月に 2、3 回行えば、あっという間に優れたテスト群ができあがります。

上とも関連しますが、そんなに「優れた」テストスイートができるものでしょうか。現状追認で作る(作らざるをえない)テストスイートが、それほど良いものになるとは、直感的には信じづらいのですが(hayase)

あとからテスト足すのは辛いので、随時やりたいですよね(98lerr)

ここで追認の辛い思い出を持って、次からは随時テストかこう！になったら、チームとしていい成長になれるかもしれない。

発見が難しいエッジケースのせいで、チームは自動化を停滞させてしまうのです。自動化は完璧でなければならない、と考えるのは誤った二分法であり、組織のあらゆるレベルでこの考え方と戦う必要があります。

悪魔の証明のように、ダメな理由から考えてそれを理由に進まないケースは無意識にもあると思う。一度一呼吸しやる場合やらない場合の両面から俯瞰して見る習慣が大事。(98lerr)

+1(hayase)

複雑すぎる自動化で誰も手を出せなくなる、は不幸だけれど、このケースのようにテストを足していくのは効果的なのでは。

自動化によってリリースに関する不確実性を完全に取り除くことはできません。しかし、その不確実性をあなたや組織が許容できる範囲まで減らすことは可能です。

自動化する前に読みたい言葉。 AIとかもだけれど、やったら作業がなくなるじゃなくて、支援者として捉えたい。先日CSPO研修受けた中で、 AI(mob AI)もdriver やnavigaterと並ぶ役割と定義してたのが面白かった。(98lerr)

「あなたや組織が許容できる範囲」を認識できているかが問われているのだな、と思いました (hayase)

8.6　デプロイプロセスの各レイヤでの失敗への対応

デプロイに対する恐怖は、デプロイに失敗した場合に変更を元に戻すのにかかる労力にも関係しています。

正常系優先でスピード優先で作った時、大体この失敗した時の手動戻しが作った人しかできないになり、気づけば作った人以外誰も触りたがらないものになる印象がある。何ができるか以上にトラブったらどう直せるかが大事と思うこともあります。(98lerr)

5章でも取り上げましたが、よく使われる選択肢に機能フラグがあります。新しい機能を機能フラグの裏側に配置します。機能フラグがオフの場合、元のコードパスが実行されます。しかし機能フラグがオンになっていると新しいコードパスが実行されます。フラグはデフォルトでOFFに設定するべきです。

まだ個人的に考えに馴染めていない。何でもかんでも機能フラグ切り替えでなくてもいいと思うときもあって、使い分けが考えられてない。(98lerr)

例として接続先のAPIバージョンが変わるなどで大きく仕様が変わる時、機能フラグで新旧両方のロジックをかくと結構冗長になったりする印象。if文の制御方法とかの実装方法の問題とも思いますが。(98lerr)

将来の状態と現在の状態を比較する必要性は、機能を計画する段階から考慮しておきましょう。

なにをどう改善したいのかを、最初から明確にして測れるようにしろ……という教訓ですね(hayase)

ほとんどすべての測定は不完全なものです。時には、何かを測定するという行為そのものが、その物の振る舞いを変えてしまうことがあります。これは観察者バイアスと呼ばれる認知バイアスの1つです。

測定を繰り返そう、改善していこうって前提だとうまくいきやすい？ 半年に1回のリリースで測定ロジックを仕込まないと、とか思ったら完璧な測定は何かに延々と時間を使って考えてしまいそう/しまう。(98lerr)

測定を目的化するな……ということにも通じそうです (hayase)

ロードバランサの背後でサーバをグループ化することで、どのサーバ（またはフリート）がトラフィックを受け取るかを変更できます。

これがブルーグリーンデプロイの定義だとすると、私は理解を間違えていたのかも……(hayase)

アンパンマンの頭的な入れ替え(かつ古い頭に戻せる)を、ブルーグリーンだと思ってたところありました。(98lerr)

ここの表現だと、カナリアリリース的って捉えてたものの感じがしました。(10%, 20%...と切り替える) (98lerr)

次のリリースでは、古いカラムをDROPし、新しいカラムだけが残る。

これがちゃんとできず、使わないカラムが残ったテーブルが (hayase)

8.7　デプロイアーティファクトの作成

パッケージ管理ツールを使うという選択肢

この本はパッケージマネージャを推しているのですね。サーバサイドだと、いまどきはコンテナイメージにする方がよさそうに思いました。クライアントサイドでも， snapcraft とかがありますし (hayase)

今ではこういった複数のOSを1つの環境で動かすといったことはしていないでしょう。個人的にFPMが強力だと感じているのは、1つのインタフェースを覚えるだけで済む点です。もし私の次の職場がDebian GNU/Linuxを使っている会社だったとしても、DEBを作成するための構文を新たに学ぶ必要はありません。

知らなかった。(98lerr)

構成管理ツールを使用している企業ではデプロイアーティファクトとの対立が生じます。ユーザーの作成やディレクトリの作成などの処理をいつデプロイアーティファクトに任せ、いつ構成管理ツールに任せるべきでしょうか？　それは構成管理の戦略に大きく左右されます。

書いてある通りサーバ周りまでとコードでの境界、またはIaCで作った環境ごとアーティファクトにと思ってたので、この対立を考えられてなかった。(98lerr)

手動でのサーバ更新が前提にあると、この対立が引っ掛かってくるんですね。(98lerr)

彼らはこれまで、各サーバに対して7ページに及ぶ手順を実行していたわけですから。完璧ではありませんが、パッケージを使うことによってステップ数が大幅に減り、エラーが発生しにくくなり、デプロイやロールバックの両方を驚くほど迅速に行うことができるようになりました。

作業者の集中力の面でも、こうした整理は大事にしたい。(98lerr)

もし構成管理ツールを使用しているのであれば（使用しているべきですが）、たとえばRPMパッケージによってインストールされた設定ファイルを構成管理ツールで置き換えるという別の選択肢があります。

環境変数としてのKVS、外から期待する内容ご見える点も含めて嬉しい。設定ファイルばら撒きだと、どこかに古いの配られてないかの恐怖があったので。(98lerr)

8.8　デプロイパイプラインの自動化

全体的に、オンプレミスのサーバが固定であって、仮想化せずに使う場面が、うっすらと前提になってる感じがします。構成管理ツールを使うことを推奨しているので、仮想化してないということはないと思うんですが……。

もしロールバックが必要になったとしても、パッケージ管理プロセスによってある程度は容易になります。yum downgradeコマンドを使用すると、アプリケーションを以前のバージョンにロールバックできます。

これ信用できず、怖くて、あまり手順に入れたくない気持ちが強いです。vm使えるなら、新しいマシンを立てたい。(98lerr)

+1 (hayase)

8.9　本章のまとめ

●恐怖心はリリースサイクルを遅くする主な要因です。

●リスクが軽減され、正常な状態への復帰が迅速かつ十分に理解されているときには恐怖心は軽減されます。

● ステージング環境は本番環境とまったく同じにはなりません。それを前提に計画しなければなりません。

●OS のパッケージ管理機能はデプロイアーティファクトを作成するのに最適な方法です。

●データベースの変更は常に追加的に行い、2 つのリリースを経るべきです。1 回目のリリースで新しいカラムを追加し、2 回目のリリースで古いカラムを削除します。

●デプロイパイプラインの自動化は段階的に進めましょう。

みんなからのコメント

原著も2020なので、dockerの話が出てきそうなのに出てこない。

仮想化前提でいけそうなのに

ここでの構成管理ツールは？

anibleやchefが前提なら、インスタンス作り直して欲しいけれど、そういう感じじゃない。

機能フラグ推しなのもあって、新しいのか古いのかよくわからない感じも。

12factor appに落ち着くけれど、それができない時の考え方として見直したい

スタートフルなものとか

ライセンス問題が引っ掛かるか

つらい

実践する/伝えるためのハードルはなにか？

「恐怖心」がどこから来るものなのか。ビジネスサイドからのプレッシャーだと、解決が難しいようにも思う。

インプレースアップデートから逃げられない世界だと、この章が話してる悩みと向き合わないといけない。

一緒に使うと良さそうなプラクティスやマインドセットはなにか？

ハードルの乗り越え方はなにか？実践/伝える方法はなにか？

どれくらい効果がありそうか？