DevOps を「The DevOps ハンドブック」「Effective DevOps」「システム運用アンチパターン」で比較
msk概要
DevOps の書籍「The DevOps ハンドブック」 と「Effective DevOps」で解説されている DevOps を比較する。
mskDevOps とは
msk「The DevOps ハンドブック」
特に名言はされていないが、「3 つの道 DevOps を支える原則」として紹介されている。
「第 3 の道」が最終目標だとすると、「DevOps は継続的な学習と実験の文化を作り出すこと」が目標になる
3 つの道：DevOps を支える原則
- 第 1 の道：フローの原則
- 顧客にすばやく価値を送り届けるために、開発から運用への作業の流れを高速に実現する
- 第 2 の道：フィードバックの原則
- バリューストリームのあらゆるステージで、すばやくてコンスタントな右から左へのフィードバックフローを実現する原則
- 第 3 の道：継続的な学習と実験の原則
- 継続的な学習と実験の文化を作り出すことに着目する。これは個人が、コンスタントに知識を生み出し、それをチームや組織の知識に転化していくための原則
バリューストームと IT バリューストーム
バリューストーム
- 「企業が顧客の要求に応えるために着手する一連の活動」
- 「顧客に届ける商品やサービスを設計、生産し送り届けるために必要な一連の活動で、情報と素材の双方向なフローを含む」
IT バリューストーム
- （DevOpsでは）「ビジネス上の仮説を立案してから、顧客に価値を送り届ける技術サービスを生み出すまでの間に必要なプロセス」
DevOps が解決したい問題
- 根深く慢性的な対立
- 三幕構成の悪循環
- 悪循環がどこでも起きるのはなぜか
- 悪循環の人的経済的コスト
DevOps は、これらの問題を解決することにより、組織としての業績を引き上げ、ITのさまざまな職務（開発、QA、IT 運用、情報セキュリティなど）の目標を達成し、従事する人々の状態を改善する。
msk「Effective DevOps」
「Effective DevOps」で明確に書いてあった
devops とは何か
devops は文化運動だ。仕事にたいする個人の考え方を変え、仕事の多様性を尊重し、ビジネスが価値を実現するスピードを加速させる意識的なプロセスを支援し、社会的および技術的変化の効果を計測しようとしている。devops は思考の方法であり、仕事の方法である。個人と組織が持続可能な作業習慣を生み出し、維持していくことを可能にするためのものだ。devops は文化的なフレームワークだ。ストーリーを共有し、共感を育み、個人とチームが効果的かつ永続的に力を出せるようにする。
効果的な devops のための 4 本柱
- コラボレーション
- アフィニティ
- ツール
- スケーリング
| 項目 | 内容 |
|---|---|
| コラボレーション | 複数人で対話したり、教え合ったりすることを大切にしんがら、特定の結果に向かってものを作っていくプロセス |
| アフィニティ | チーム間の関係を構築し、組織の共通目標を念頭に置いて個々のチーム目標の違いを乗り越え、共感を育て、他のチームの人たちからも学習するプロセス |
| ツール | 加速装置。現在の文化と向かう先を踏まえて変化を推し進める |
| スケーリング | 組織がライフサイクル全体で導入しなければならないプロセスや軸に重点を置いている |
devops に対する誤解とアンチパターン
devops に対するよくある誤解
- devops に関係があるのは開発者とシステム管理者だけだ
- devops はチームである
- devops は肩書だ
- devops はウェブ系スタートアップだけの問題だ
- devops には認定資格が必要だ
mskGoogle の DevOps と SRE の定義
DevOps
IT 開発、運用、アーキテクチャ、ネットワーク、セキュリティのサイロを解消するために作られた、一連の慣行、ガイドライン、および文化
SRE
うまく機能することがわかった一連の慣行、それらの慣行に命を吹き込む信念、および仕事上の役割
Udemy の講座から引用
msk「SRE サイトリライアビリティエンジニアリング」での言及
「DevOps」という言葉は、2008 年の終わり頃から業界で使われ始め、本書の執筆時点（2016年初頭）の時点でも、その意味するところはいまだに固まっていません。その中核となるのは、システムの設計と開発の各フェーズにおいて IT に役割を持たせること、人手ではなく自動化に頼ること、運用タスクのエンジニアリングのプラクティスとツールを提供することなどであり、これらは SRE の方針やプラクティスの多くとも一致します。DevOps は、SRE の中核的な方針のいくつかを、幅広い組織、管理の構造、個人に対して一般化したものと捉えることもできるでしょう。同様に、SRE を DevOps に独特の拡張を少し加えたプラクティスと捉えることもできるでしょう。
msk「Lean と DevOps の化学」での言及
ソフトウェアがあらゆる種類の組織に変革と加速化をもたらしている。本書で推奨・解説するプラクティス（効果的、効率的な手法）やケイパビリティ（組織全体やグループとして保持する機能や能力）は、「DevOps」と呼ばれるソフトウェア開発手法をめぐる議論の中で生まれてきたもので、これが世界中のあらゆる業界を変えつつある。そもそも DevOps の手法は「安全で耐障害性が高く急速に進化できるスケーラブルな分散型システムを構築するためにはどうしたらよいのか」という難題を抱えた、少数の組織から生まれてきた手法である。競争力の維持を望む組織は、この難題の解決法を習得しなければならない。歴史が古く、何十年も前の旧式のテクノロジーに依存している大企業でも、本書で紹介する手法を最小すれば、デリバリ（ソフトウェア配信）の加速やコスト削減といった成果を得られるのである
msk「システム運用アンチパターン」
DevOps の歴史を踏まえた上で、下記の定義で紹介している。
DevOpsとは、ソフトウェア開発の考え方をほかの役割に適用するようなソフトウェア開発手法のことです。DevOpsでは、ソフトウェア開発のライフサイクルに関わるすべてのチームが責任を共有することを重視しています。従来は開発者中心であった業務を運用チームのメンバーが担い、開発チームのメンバーも同様の業務を行うことで、職能の垣根が低くなります。DevOpsという言葉は、開発（Dev）とIT運用（Ops）に関連するものとしてよく知られています。しかしこのアプローチはセキュリティ（DevSecOps）、QA、データベース運用、ネットワークなど、ほかのグループにも拡張できます。
mskDevOps を実践するために
msk「The DevOps ハンドブック」
以下は技術的に実践するためにどうすれば良いのかについて書かれたこと。
第 1 の道: フロー改善の技術的実践
- デプロイパイプラインの基礎を作る
- 高速で信頼性の高い自動テストを実現する
- 継続的な統合とテストを実現し、実践する
- ローリスクリリースを実現する自動化、手法、アーキテクチャ
第 2 の道: フィーバックの技術的実践
- 問題の発見、解決を実現するための基礎として遠隔測定のメカニズムを作る。
- 遠隔測定データを活用して、従来よりも問題をうまく予測し、目標を達成する
- ユーザーリサーチ、ユーザーからのフィードバックを生み出す
- ピアレビュー、ペアプログラミングを通じて作業品質を向上させるためのフィードバックを作り出す
第 3 の道: 継続的な学習と実験の技術的実践
- 安全を実現するジャストカルチャー（公正な文化）を確立する
- 本番環境にエラーを注入してシステムの回復力を鍛える
- ローカルな発見をグローバルな改善につなげる
- 組織的な改善と学習のための時間を確保する
msk「Effective Devops」
以下の、4 つの柱がある。
- コラボレーション
- アフィニティ
- ツール
- スケーリング
コラボレーション
コラボレーションの例
- 非同期でのコードレビュー
- ドキュメント作成
- 問題の更新とバグレポート
- その週に進んだ内容のデモ
- 定期的な状況報告
- ペア作業
賢いチームの特徴
- コミュニケーション
- 平等な参加
- 心の理論
アフィニティ
アフィニティは、個人、チーム、部門、企業の間の関係の強さの尺度。
チーム内の個人間の結びつき
- 共有する時間
- 関係の強度
- ストーリの相互共有
- 助け合い
ツール
ツールの話をするときには、ソフトウェアに目が行きがちだ。プログラミング言語、IDE、テキストエディター、シェル、構成管理ソリューション、チャットプログラムとしてどれを使うかといったことだ。しかし、ツールはソフトウェアにとどまらない。プロセスのなかで消耗せずに目標を達成するために役に立つものなら、基本的にそれらすべてがツールである。
- サーバーリフトは、データセンターでのサーバー設置作業をスピードアップし、作業中の負傷を減らす
- 小さくて軽いノート PC は、カンファレンスに出張するときや、データセンターでコンピューターを持ち歩くときの肉体的負担を軽減する
- ソフトウェア RAID ではなくハードウェア RAID を選択すると、コストは余分にかかるがバッテリーバックアップなどの機能が得られ、保守しやすくなる
次の目的のために使える。
- コミュニケーションの向上
- 境界線の設定
- devops 共同体の枠内での相互理解の回復
スケーリング
スケーリングが意味するもの
- 顧客ベースの拡大
- 収益の拡大
- 需要に合わせたプロジェクトやチームの拡張
- システムに割り振る人の割合や金額の維持、改善
- 競合他社よりも早い成長
組織のライフサイクル
2 つの視点から分析できる
- 内外からの圧力
- 組織の成長や衰退
msk「システム運用アンチパターン」
DevOps は 4 つの柱に支えられているとして紹介。
| 4 つの柱 | 詳細 |
|---|---|
| 文化 | 文化では、チームが活動する上での基準を変えることについて扱う。その基準とは、チーム間の新しいコミュニケーションパターンであったり、まったく新しいちーむ構造であったりする。文化をどう変えるかはその組織がどういった文化的な問題を抱えているかに左右される。 |
| 自動化 | 自動化とは、人的資本を平凡な作業から解放すること。自動化とは人的資本が安全かつ自律的に仕事ができるようにすること。自動化は組織内での仕事の進め方の文化をより強化するために使用されるべき |
| メトリクス | メトリクスは、物事がうまく機能しているかどうかを判断するために必要。エラーが発生していないことを確認するだけでは不十分。システムを評価する方法を強化するものとしてメトリクスは使われるべき |
| 共有 | 共有を重視する根底には、知識は自由であるべきだという考えがある。人間は誰かに教えるときに最もよく学びます。共有によって文化はより強化されていく。知識マネジメントは、より複雑なシステムを構築し続ける世界において非常に重要 |
本書では、DevOps のアンチパターンと解消方法の説明を行う。
| アンチパターン | 概要 |
|---|---|
| パターナリスト症候群 | 組織内の信頼が低いことの影響、ゲートキーパーがプロセスや変化のスピードに与える影響を検証、自動化による解決 |
| 盲目状態での運用 | 運用におけるシステムの可視化の必要性について説明、システムの理解・データ・メトリクスによって、システムが期待通りに機能しているかどうかを確認するプロセスを説明 |
| 情報ではなくデータ | データをどのように構造化し、どのように提示すれば、それを見る人にとってより有用なものになるか説明 |
| 最後の味付けとしての品質 | システムの品質を高めるには、システムのすべての構成要素の品質を保証する必要があるという点について説明 |
| アラート疲れ | アラートの作成をより慎重に行い、アラートの真の目的を理解 |
| 空の道具箱 | チームの役割や責務が拡大するにつれて、その役割を果たすためのツールに時間と労力を投資することが大事 |
| 業務時間外のデプロイ | デプロイプロセスにおける不安についてに加えて、不安をどうにかするのではなく、デプロイプロセスに対するアプローチを変えることによって、プロセスに安全性を持たせる方法について説明 |
| せっかくのインシデントを無駄にする | インシデントが起きたときに、そこからいかに学びを得るか |
| 情報のため込み | 情報を意図的に溜め込もうとするわけではないが、コミュニケーションやドキュメント共有の仕組みが適切でないため意図せずに情報が溜め込まれてしまうこと |
| 命じられた文化 | 組織文化は、スローガンや価値観の表明によってではなく、組織内で評価される（もしくは評価されない）行動・習慣・振る舞いによって形成される |
| 多すぎる尺度 | 目標設定と優先順位づけのプロセス |
mskDevOps について言及された記事
msk結論
今後必ず変化するが、一旦の結論を日付ごとに出していく。
msk2023/06/30 時点
DevOps は、「プロダクトの価値の提供を最速にすると同時に、継続的な学習と実験の文化を作り出すこと」である。
理由
- 主に「The DevOps ハンドブック」の内容に一番共感したから
- 組織的な強さは、以下の 2 つから生まれると思った
- IT バリューストリーム（価値を提供するまでの一連の活動）の最速化するための取り組み
- IT バリューストームのそれぞのフェーズにおける継続的な学習と実験
- これらは巷で紹介される以下の手段を、一括りにして DevOps なんだと考えている
- ビジネス KPI（価値）の明確化
- 自動化
- CI/CD
- ログとメトリクスの測定・分析
- チームビルディング
- アジャイル
- ドメイン駆動設計
- そして、「上記の内容を 1 つ取り組む=DevOps」であり「DevOps を推進する=上記の内容から選ぶ」なんだと考えている
msk一旦、クローズ。随時更新することがあれば記述する