EffectiveDevOps #1

A Summary of the first 4 parts of "EffectiveDevOps", a book about DevOps published in 2018.

Transcript

1. Effective DevOps #1 2018.11.8
2. 本⽇の内容 第Ⅰ部 devopsとは何か 1章. ⼤局を⾒る 2章. devopsとは何か 3章. devopsの歴史 4章. 基本的な⽤語と概念(4.4まで) 2
3. 1章. ⼤局を⾒る ストーリーの価値 私たちはそれぞれ⾃分⾃⾝の考えを考える。 共有するのは概念だ。 スティーブン・トゥールミン『Human Understanding』 3
4. リンのストーリー 運⽤の仕事は好きだが、職場の理解不⾜ オンラインのdevopsコミュニティに参画、活⼒を得た 転職、運⽤の世界でキャリアを積み、「devops」チームの共 同作業を経験 ストーリーはコミュニティとして共有し、学習、成⻑するた めのもの 4
5. ジェニファーのストーリー ⾃分への技術⼒へのチームの依存問題 知⾒共有を優先することで⻑期的にチーム/個⼈にとって良い 結果に結びつけた devopsの価値は、ストーリーを共有し、コラボレーションを 通じて問題を解決し、コミュニティを強化すること 5
6. 私たちのストーリー 私たちは、異なる視点から毎⽇様々な経験を積み重ねている 経験はほかの⼈たちに教訓を与える ストーリーの共有で終わらず、新しいアイデアを試そう 試したことのなかで機能するもの、しないものを判別できる ようになれば、⾼度な実験を始められるようになる 6
7. 2章. devopsとは何か 思考の⽅法であり、仕事の⽅法である ⽂化的なフレームワークだ ストーリーを共有し、共感を育み、個⼈とチームが効果的か つ永続的に⼒を出せるようにする 7
8. ストーリーの共有の効果 チーム内の透明性が増し、チーム内に信頼が⽣まれる ダメージの⼤きいミスをする前に、それを防ぐ⽅法を同僚に 伝えられる 新しい問題の解決に使える時間が増え、イノベーションが促 進される 8
9. devops共同体 明確に定義された⽬標を共有する その場その場でコミュニケーションをとる 理解をダイナミックに調整、修正する 9
10. 3章. devopsの歴史 10
11. 1946 オペレータとしての開発者 1961 ソフトウェアエンジニアリングの始まり 1961 グローバルなコミュニティの始まり 1964 プロプラエタリソフトウェアと標準化の登場 1979 ネットワークの時代 1995 アプリケーションとウェブの時代 2001 ソフトウェア開発⼿法の発展 2006 オープンソースソフトウェアとプロプライエタリサービス 2008 アジャイルインフラストラクチャ 2009 DevOpsDaysの始まり 11
13. 3章. devops歴史のまとめ 歴史を振り返ると、⼈とプロセスではなく、結果を重視する 傾向が⾒える ⼈とプロセスを重視すると、「なぜ」「どのように」仕事を するかを改善することが重視されるようになる 「何」から「なぜ」への転換は、私たちに仕事が持つ意味と ⽬的を確⽴する⾃由と信頼を与える devopsの導⼊によって、専⾨化を競い合うのではなく、互い の協⼒と協調を重視し職種を越えて⼈とプロセスを重視する ようになった 13
14. 4章. 基本的な⽤語と概念 (4.4まで) 4.1. ソフトウェア開発⼿法 4.2. 運⽤⼿法 4.3. システム⼿法 4.4. 開発、リリース、デプロイの諸概念 14
15. 4.1. ソフトウェア開発⼿法 開発の仕事を別々のフェーズに分割するプロセスのこと 4.1.1 ウォーターフォール 4.1.2 アジャイル 4.1.3 スクラム 15
16. 4.1. ソフトウェア開発⼿法 4.1.1 ウォーターフォール 最初の要件定義と設計に時間を割き、構造化される傾向 16
17. 4.1. ソフトウェア開発⼿法 4.1.2 アジャイル プロセスやツールよりも個⼈と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 『アジャイルソフトウェア開発宣⾔』 http://agilemanifesto.org/iso/ja/manifesto.html 17
18. 4.1. ソフトウェア開発⼿法 4.1.2 アジャイルのイメージ図 18
19. 4.1. ソフトウェア開発⼿法 4.1.2 アジャイルとdevopsの関係 共通点︓⼈、対話、コラボレーションを強調 相違点︓devopsは開発者だけでなく、広い範囲のひとたちに 影響。開発プロセスだけでなく、組織全体が適⽤の対象 19
20. 4.1. ソフトウェア開発⼿法 4.1.3 スクラム 開発チームが変化にすばやく対応する能⼒を最⼤化すること に重点をおく開発⼿法 変化︓プロジェクトの変化と顧客ニーズの変化の両⽅ 20
21. 4.1. ソフトウェア開発⼿法 4.1.3 デイリースクラム チームメンバーがスプリントの⽬標を達成するために 昨⽇何をしたか 今⽇何をするか 妨げとなるものは何か(困っていることはあるか) を報告 21
22. 4.1. ソフトウェア開発⼿法 4.1.3 スクラムマスターの役割 チームの⾃⼰組織化を⽀援する 仕事の調整を助ける チームが前進できるように障害を取り除く プロダクトオーナーやステークホルダーを巻き込んで、何を もって「完成」なのか、現在の進捗がどうなのかについて共 通理解を持てるようにする 22
23. 4.2. 運⽤⼿法 ITや運⽤の仕事も分割したり構造化したりできる。 4.2.1 ITIL 4.2.2 COBIT 23
24. 4.2. 運⽤⼿法 4.2.1 ITIL (Information Technology Infrastracture Library) ITサービス管理のためのプラクティス集 プロセス、⼿順、タスク、チェックリストなどを解説した5冊 の書籍からなる ITILは攻めより守りに⽴つことが多い。使っている企業は より⼤胆な計画と顧客重視の姿勢を取り⼊れたほうがよ い ステファン・マン 24
25. 4.2. 運⽤⼿法 4.2.2 COBIT(Control Objectives for Information and Related Technology) I情報と技術のガバナンスと管理のフレームワーク 5つの原則 1. ステークホルダーのニーズにこたえる 2. 企業全体をカバーする 3. ひとつに統合されたフレームワークを適⽤する 4. 包括的なアプローチを実現する 5. ガバナンスとマネジメントを分離する 25
26. 4.3. システム⼿法 参考資料 ドネラ・メドウズ『Thinking in Systems』(システム思考) リチャード・クック博⼠『How Complec Systems Fail』(シス テムはどのようにして失敗するのか) 26
27. 4.3. システム⼿法 4.3.1 リーン ＝ 顧客価値の最⼤化とムダの最⼩化 リーン思考の5原則 価値 バリューストリーム フロー プル 完全性 27
28. 4.3. システム⼿法 4.3.1 リーン リーン⽣産におけるムダ 仕掛かりの仕事 余分な機能 学習のやり直し 不要な引継ぎ 遅れ ⽋陥 28
29. 4.3. システム⼿法 4.3.1 リーン リーンIT,リーンソフトウェア開発におけるムダ ソフトウェアの不要な機能 通信遅延 アプリケーションの応答の遅さ ⾼圧的で官僚主義的なプロセス 29
30. 4.3. システム⼿法 4.3.1 リーン リーンソフトウェア開発の⽅法 ⼤別して以下の2⽅法 ツールを通じたムダの除去に重点を置くもの 作業のフローの改善に重点を置くもの(The Toyota Way) いずれも⽬標は同じだが、アプローチのちがいによって結果にも 違いが出ることがある 30
31. 4.4. 開発、リリース、デプロイの諸概念 4.4.1 バージョン管理 4.4.2 テスト駆動開発 4.4.3 アプリケーションのデプロイ 4.4.4 継続的インテグレーション 4.4.5 継続的デリバリー 4.4.6 継続的デプロイ 4.4.7 MVP(実⽤最⼩限の製品) 31
32. 4.4. 開発、リリース、デプロイの諸概念 4.4.1 バージョン管理︓ファイルに対する変更記録に使⽤ 対象 ソースコード、アセット、ドキュメント できること コミット、⽐較、マージ、過去リビジョン復元 共同作業をしやすくする 32
33. 4.4. 開発、リリース、デプロイの諸概念 4.4.2 テスト駆動開発︓テストコードを先に書く メリット 新しい機能を明確に定義できる コードが⾏うべきことがはっきりする 開発者のフィードバックループが短縮される ⾃分が書くコードに対して責任をもつようになる 「責任の共有」「開発サイクルの時間短縮」は devops⽂化の重要な要素のひとつ 33
34. 4.4. 開発、リリース、デプロイの諸概念 4.4.3 アプリケーションのデプロイ︓リリースのプロセス リリースのプロセス 計画作成、実⾏、保守 必要なこと システムに対する変更の考慮 eg.)アプリケーションを動かすのに必要な依存部分を インフラ⾃動化を使って構築 ⾼品質のソフトウェアを実現する 34
35. 4.4. 開発、リリース、デプロイの諸概念 4.4.4 継続的インテグレーション(CI) 開発者が書いたコードとマスターを頻繁に統合するプロセス やること ⾃動テストの実⾏ テスト結果をもとに問題点の素早い特定と修正 メリット リグレッション(影響)を起こした変更を⾒つけやすくなる 35
36. 4.4. 開発、リリース、デプロイの諸概念 4.4.5 継続的デリバリー(CD)︓CIの⼀歩先 新たな変更をしても⾃動テストが結合できる 変更をデプロイ可能にする ⾃動テストとCIを活⽤して、ソフトウェアを頻繁にリリースできる ようにする 36
37. 4.4. 開発、リリース、デプロイの諸概念 4.4.6 継続的デプロイ(同じくCDと呼ばれる) 変更を本番環境にデプロイするプロセス やること テストや結果検証の仕組みの⽤意 本番環境に実際にデプロイ メリット ⾃分の仕事の結果が⾒えるのが早くなる -> 職務、仕事に対する満⾜感アップ -> パフォーマンスの向上 顧客のもとに製品を早く届けることができる -> 顧客満⾜度を上げることにつながる 37
38. 4.4. 開発、リリース、デプロイの諸概念 4.4.7 MVP(実⽤最⼩限の製品) Minimum Viable Product︓ 製品のアイデアを確かめるために、必要最⼩限の労⼒で製品のプ ロトタイプを作る考え⽅ ︓100%完全な製品を開発してからユーザに届ける ︓コンセプトの核となる部分のために機能を減らす、 ⾼度な設定を省略する 38