「The DevOps ハンドブック 理論・原則・実践のすべて」を読んで
今までは立ち上げのプロジェクトが多く、初めからCI/CDやIaCなどをやろう、となるようなところいたのですが、今いるところはそういうわけでもなく、そもそもなんでやるんだっけということとDevOpsってどういうことなんだっけ、ということに対して理解を深めようと思い、この本を読むことにしました。
この本を読んで現時点で感じたことをつらつらと書いていこうかなと思います。
ちなみにですが、自分はマネージャーでもなくリーダーでもなく、ただのメンバーです。
また、アジャイルやリーンなどといった言葉が出てくるのですが簡単な説明があるので、そのあたりの前提知識がなくても読み進めることができるので読みやすいなと感じました。
序章
序章ではDevOpsを導入することにより解決できる問題が説明されていて、この後の各章で出てくる話のイメージがつきやすいなと思いました。
この本を読む前から、サービスの機能をどれだけ早く、そしてセキュアにデプロイできるか、顧客からのフィードバックが得られるか、ということが重要だと思っていましたが、この本でも早いスピードで実験を繰り返して、市場での競争優位を得ることで、勝利をつかむことができるだろうといったことが書かれています。
また、開発と運用の間で、目標が違うことにより対立関係が生まれてしまうことに触れていて、本書では以下のように書かれていました。
ほとんどすべてのIT組織では、開発とIT運用の間に根深い対立があり、それが悪循環を引き起こして、新製品、新機能の市場投入がどんどん遅れ、品質が劣化の一途をだとり、アウテージが増えている。
市場の変化への対応は、本番環境にできる限り早く機能と変更をデプロイするという形で開発が担当することが多い。それに対し、IT運用は、本番環境を危険にさらすような変更が本番環境に入り込みにくく、あるいはまったく入り込まないようにして、安定していて信頼できる、セキュアなITサービスを顧客に提供することを責務とする。
このことから目標をどうおくかがDevOpsをやっていくうえでキーになっていて、目標を立てる上で気を付けなければいけないところなんじゃないかなと思いました。
自分は組織の目標を立てる立場ではないですが、マネージャー層に対して意見を言ったり、インプットにしてもらうことはできるんじゃないかなとふんわりと思っています。
第1部
第1部はDevOpsの行動原理、主要原則である「3つの道」についての説明がされています。
- フロー
- 顧客にすばやく価値を送り届けるために、開発から運用への作業の流れを速くスムースにするために必要なこと
- フィードバック
- 今まで以上に安全で回復力のあるシステムを構築するために、スピーディかつ頻繁に品質の高い情報を作り出して伝える
- 継続的な学習と実験
- 変化する環境にすばやく自動的に適応する能力を身に着けるために、成功と失敗から学び、うまく機能しないアイディアがどれかを見きわめ、うまく機能するアイディアを発展させる
この章で思ったのは、以下のように書かれているところがあって
何か問題を起こしたときにアンドンの日もを引っ張っても非難されず、むしろそうすることが推奨されるような文化を作る必要がある。
問題が起きてアンドンの引っ張られたら、私たちは一丸となってその問題の解決にあたり、問題が解決されるまで新しい仕事を初めてはならない。
インシデントが起きた時にはからなず事後に非難なしのポストモーテムを実施するとよい。
何かアクションすることに対して不安などがない状態、心理的安全性がある組織にはよい改善が生まれるのかなと思いました。
第2部
第2部はDevOpsをするにはどこから始めたらいいのか、誰を巻き込むのか、などといったことが書かれています。
自分がもし今の組織でDevOpsをやろうと思ったら、新しいソフトウェアサービスを開発するプロジェクトで、新しもの好きなグループから始めて、それから徐々に全体へ展開できるようにしていければいいのかなと思いました。
また、今の組織はこの本で出てくる職能指向の組織になっていてコミュニケーションコスト大きかったりやリードタイムが生まれています。
かといって、各開発チームに運用要員を入れられるほど人がいるわけでもないので、「連絡担当」をおいて開発の「儀式」に参加するのがいいのかなと思いました。
また、運用の仕事について可視化されていないので、以下の状況があるんではないか思っています。
開発チームは、それぞれの仕事をプロジェクトボードやカンバンボードで可視化することが多い。それなのに、そういったボードに、本番環境でアプリケーションの実行を成功させるためにしなければならない運用の仕事が示されていることはかなりまれだ。しかし、顧客価値が実際に生まれるのは本番環境なのである。そのため、運用の仕事が差し迫った危機になるまで、必要な運用の仕事に気づかず、納期を守れなくなりそうになったり、本番環境をアウテージ（システム停止）に陥れたりすることが起きるのである。
そこもうまいこと変えていければと思っています。
ほかにも、全員の日常業務としてのテスト、運用、セキュリティと以下のように書かれているところがあり、そうなってくれると顧客に価値を届ける早さが上がるのかなと思いました。
パフォーマンスの高い組織では、チームのすべてのメンバーが共通の目標を目指している。品質、可用性、セキュリティは、独立した部門の仕事ではなく、全員の日常業務の一部である。
そのため、日々の最優先課題は、顧客のための機能を開発したりデプロイしたりすることであったり、深刻度1の本番インシデントを解決することであったりする。あるいは、同僚のコード変更をレビューしたり、本番サーバーに緊急セキュリティパッチをあてたり、同僚生産性を上げるために改良を加えたりすることが必要とされる日もあるかもしれない。
第3部
第3部では開発から運用への仕事のフローを早くして、それを維持するために必要な技術的実践が紹介されています。
CI/CDや自動テストだったりIaCの話、テストを並列化して高速に回す、ユニットテストだけじゃなくて、受入テストとか非機能要件テストもテストスイートに統合する、といったことやローリスクのリリースができるアーキテクチャをどのように作るかといったことが書かれています。
正直、今までやってきた中で知識としては知ってましたが、本に書かれてた通りきれいにできたものはそう多くないですね。。。
ほかの章もそうなのですが、各章、どういう利点があってこれをやるのかということが書いてあって、参考になるなと思いました。
この章の中では次の文章が印象に残りました。
本番に近い環境で動作することの確認も含めて「完成」と言うように開発の「完成」の定義を変える
今まで、ユニットテストをしてプルリクをだしてマージされたらタスクを完了にする、といったことが多く、本番に上げる前にほかの機能と合わせて確認するといったことをしていました。
本番に近い環境で確認するまでをタスクとすることで、本番デプロイの時にほとんどの問題が解決されているという状態になっていて、デプロイのリスクが低くできるなと思いました。
第4部
第4部では運用から開発へ継続的でスピーディなフィードバックをするために必要な技術的実践が紹介されています。
サービスが本番環境で正しく動作していることを確認できることや問題が起きた時にどこに問題があるのかを早くわかるようにするために、モニタリング、ロギングを行い、すばやいフィードバックを得ることで、ソフトウェア開発のライフサイクルの早い段階で問題が解決されるようになる。
それとともにシステムのメトリクスだけではなく、ビジネス指標もフィードバックが得られるようにしておくと、製品についての仮説をすばやく検証できるようになる。
そしてそれらの指標を日常業務の一部として生み出せるようにすると。
正直、自分の今までの経験上、どういう指標が必要なのか最初からはわからなくて、とりあえずで作ることが多かったのですが、そこからアップデートしていく、それを簡単に、やろうと思ったらすぐできる環境だったり仕組みだったりが必要なんだなと思いました。
これ実現するために、これまでの章の早いフローが必要になってくると。
また、この章では収集したデータを分析するための統計の話ものっていて、このあたりの知識はまるでないので勉強するための参考になりそうだなと思いました。
第5部
第5部ではできる限りスピーディかつ頻繁に低コストで学習する機会を作り出す実践が紹介されています。
誤りを犯した時に、その詳細を話しても安全だと感じるようなら、エンジニアたちは進んで説明責任を果たすだけでなく、社内のほかの人々が将来同じ過ちを繰り返さないようにするための取り組みに熱心に力を傾けるだろう。これが組織的な学習を生み出す。一方、そのエンジニア
を罰するなら、障害のメカニズム、病理、仕組みを理解するために必要な詳細情報を誰も提供しようとしなくなるだろう。そうすると、同じ過ちは間違いなく繰り返されることになる。
この文化を形成するために非難なしのポストモーテムが効果的で、そしてできる限り広い範囲にポストモーテムを公表することでそこから多くの人が学習できるようになるといったことが書かれています。
確かに失敗から学べることは多いと思いますし、以前にこんなことがあったんだということもわかるようになるし、このポストモーテムという文化は個人的に好きです。
ほかにも、学習という話から、システムの回復力をつけるために、本番環境にエラーを注入する、といったいわゆるカオスエンジニアリングの話が出てきます。
システムが適切な設計、アーキテクチャになっているか、本番環境にエラーを注入することを日常業務に取り入れることで、そこから学習する文化を作る、と言ってることはわかるんですが、そこまでできるほどうまくできるのかといった感じがしてしまいます。。。
ここの章ではチャットボットを使ってオートメーションをするといった話が出てくるのですが、以下の利点が挙げられていました。
- 何が起きているかを全員を目にする。
- 職場に新しく入ってきたエンジニアが日常業務のようすを見て、やり方を知ることができる。
- ほかの人たちが助け合っているところを見た人たちは、自分も助けを求めるようになる。
- 組織的な学習が加速され、蓄積される。
チャットボットの導入はしたことなくて、チャットから実行できるのは便利だなぐらいの認識でしかなかったのですが、確かにこれはいいなと思ったので積極的にとりいれていこうかなと思いました。
自分の経験上、技術的負債を返済するのってなかなか手を付けれないことがしばしば。
そこに対して技術的負債を返済する儀式を制度化するっていう考え方はいいなと思いました。
「ある週のまる1日、うちの部では技術的負債を返済する時間にする」とかをマネージャーにやってみるのはどうかと打診するのはありかなと。
第6部
第6部では開発と運用の日常業務にセキュリティ管理を組み込んで、セキュリティをすべてのエンジニアの毎日の職務の一部にする方法が紹介されています。
デプロイパイプラインをセキュアに保つことや、静的分析をしたり、セキュリティに関するアプリケーションのログを収集したりと、技術的なことは書いてあるのですが、監査人やコンプラ責任者の人たちとやっていくにはどうすればいいのだろうかということが疑問に残りました。
最後に
と各章ごとに感じたことを書いていったのですが、DevOpsを導入するときにかなり参考になるなあと思いました。
ただ、自分自身、ツールを導入すること、フローを取り入れること、といった、手段が目的化してしまうことがこれまでにあったりもしたので、そこに気を付けてやらねばなと。
また、売上をあげることが会社にとってプラスだと思うので、開発目線の問題だけではなくて、ビジネス的な目標を達成するには、みたいなところも考えらながらやっていければなと思いました。
そして、組織を一気に変えることはなかなか難しいと思うので、自分の関わるところから、ちょっとずつ小さく試してみようかなと思いました。
