はじめに
こちらの本を読んだが、基本全編「ああ、あるある…」と思いながら読んでいた。
DevOps を実施したいと考えている人だけではなく、開発のみを行う専任開発者にもぜひ読んで欲しいと個人的に思う。
今回、本書から個人的に開発者にぜひ理解して欲しい話題を個人的な見解を交えながら紹介したいと思う。
想定読者は「動くものは作れる」という開発者である。
最初に断っておくが、以下で紹介されている事項を知っても、直接的な利得（機能・速度）を得ることはできない。 しかし、これらの運用側面を知ることで、システム開発全体で実施可能なことが増えるため、運用担当者側から是非知って欲しいと思う点を紹介している。
デプロイを意識したコーディングとアーキテクチャ
主に第8章、業務時間外のデプロイから。
ここでは細かい Ops 業務というよりは、より具体的に健全なデプロイを行うための手法がまとめられているため、アーキテクチャレベルの設計業務を行う人であればぜひ読んで欲しい。
具体的には「ブルーグリーンデプロイメント」のための方法や、「データストアレベル」のロールバックを実現するための手法について書かれている。
ブルーグリーンデプロイメントを行う前提条件として、以下の３つが記載されている。
-
新旧のコード両方がDBのバージョンに対応していること
- バージョン 1 から 2 へアップグレードする場合、DBにも同様のバージョン 1 と 2 が存在し、それぞれのバージョンからエラーなく利用できること
- バックグラウンド処理の重複が起こらないような設計を行う、あるいは仕組みを作る
-
ローカルディスクに状態を保存しないようにする
- アップロードされたものは共有でマウントされている領域であったり、AWS の S3 のような領域に保持する
- セッションなどは外部の独立したデータストアに保持する
また、データストア（データベース）で複数のバージョンに対応できるようにするためのカラムの変更方式やルールの策定、データにバージョンを付与する方法など、より具体的な方法も説明されている。
「よし、ブルーグリーンデプロイをやろう！」と思ったり、偉い人から「最近はこういう方法で無停止更新できるんでしょ？」とか言われても、それがアプリケーションの作りによって不可能なことがあることが知識としてまとめられているため、より良いデプロイ作業を行うようにするために、是非専任開発者にも読んで欲しい内容であるため紹介した。
自動化のメンテナンスと企業文化
主に第2章、パターナリスト症候群、第7章、空の道具箱、および、第11章、命じられた文化から。
かつて働いていたところで、「もう自動化のための仕組みづくりは終わったから、運用メンバーだけ残して開発者は別の仕事してね」のようなことを言われたことがある。
-- 2.7. 継続的な改善に向けて、より引用
ただしこれが１回限りのものだとは決して思わないでください。 作成されたコードは新しいユースケースが発生するたびにメンテナンスやアップデートが必要になります。
当時の私はこう考えていたし、重要だということを信じていた。 しかし、結局別のところで仕事をすることになった。 こういった判断を行った結果、元居たチームは自動化のための開発戦力をほとんど失い、ほぼ全てを手動作業でしか解決しないチームになってしまった。
運用メンバーがちゃんと自動化のための動きを学びながらできる状態であれば、別段良かったかもしれない。 しかし、元のプロジェクトに対してそういった状況を軽視した判断が取られたことは事実である。
第11章の「文化」でも説明されている通り、私が感じていた「DevOps として継続して業務改善すべき」という自分の意見と、「あとは全部ただの運用者で回せるだろう」と判断した人では、そもそも想定しているレイヤー（事業的優先度と、プロジェクトに対する思い入れ）が違ったり、企業の文化価値観が違ったのだろうと納得することはできる。
運用プロセスは作って終わり、というほと単純なものではない。 運用に使うツールであっても、実体の変化に伴って 継続的に改善していく必要がある。 開発者であれば「自動化した」とはよく言っているとは思うが、それで終わりではなく、その 自動化したものにも続きがあり、継続的に付き合っていく必要がある、ということを知ってほしく、この内容を取り上げた。
オンコール (通常業務時間外当番)と運用可用性
6章のアラート疲れ、より。
開発者が作ったものを別の人が運用する、となると、当事者意識が低くなり、自身の作ったものが問題を引き起こしたとしても「じゃあ直せばいいや」と考えてしまい、実際に起こった問題のためにどれだけの労力が使われ、苦労を掛けたかが他人事になってしまいやすい。
もし自分が運用をするのであれば、そんな問題（特に夜間にアラートでたたき起こされたり、休日にいきなり呼び出しを喰らったり）から逃げるために、極力問題を排除する（つまり、運用を改善する）方向に力が働きやすい。
また、開発者としてデータに問題があった場合、「データがおかしい？ じゃあ、DB を書きかえればよいだろ」と解決策は簡単だと考えるかもしれない。 しかし、
- 例えば、ユーザーのパスワードをリセットする SQL を発行する場合、そのパスワードはハッシュ化されて保持されているはずであり、これをどのように得るのか？
- 例えば、あるデータを SQL で書き換えた時、その変更オペレーションが正常なものであることはどのように保証するか？ (監査観点)
といったユーザー観点での問題が発生していることに注意して欲しい。 この問題は 7章の 7.7.2. 安全のための設計、で説明されており、汎用的な問題である。
これらを自動化することは、一般的なユーザーに対する「機能」としては何も生み出していない。 しかし、システム運用者というユーザーの観点では、誤りがなくなる、作業がシステムを経由するため、変更したことがシステムに保持される（監査的に問題のない状態）で業務を行える、と言った付加価値を創出している。
専任開発者の場合、例えばデータベースもローカルに構築しており、そのデータの変更・削除も手軽に行えることから、これらの業務は極めて簡単な業務と思っているかもしれない。
しかし、そうではない。
開発者なら知っているデータ構造や関連も知らない状態で処理をする、というのは、それを本当にして良いか、という裏を取る必要があるし、万一失敗した場合にどこまで影響があるのか、ロールバックとして失敗前の状況に戻せるのか、といった非常に広い範囲の問題になってしまう。 これらを知るためにも、実際のオンコールへの開発者の参加によって当事者意識を高くしたり、一般ユーザー以外の管理ユーザーのユースケースを理解したりすることは、プロジェクト全体の改善となることを知ってほしく、取り上げた。
おわりに
本記事で紹介した内容は、書籍から適時内容を取り上げつつ、自身の経験・私見を踏まえて、運用者の立場から開発者に知って欲しいことを箇条書きとした。
これらの内容を見て興味が沸いた人は、是非書籍を読んで、より自身の開発哲学を深めて言って欲しいと思う。