EffectiveDevOps #1 - Speaker Deck

Slide 1

Slide 1 text

Effective DevOps #1 2018.11.8

Slide 2

Slide 2 text

本⽇の内容第Ⅰ部 devopsとは何か 1章. ⼤局を⾒る 2章. devopsとは何か 3章. devopsの歴史 4章. 基本的な⽤語と概念(4.4まで) 2

Slide 3

Slide 3 text

1章. ⼤局を⾒るストーリーの価値私たちはそれぞれ⾃分⾃⾝の考えを考える。共有するのは概念だ。スティーブン・トゥールミン『Human Understanding』 3

Slide 4

Slide 4 text

リンのストーリー運⽤の仕事は好きだが、職場の理解不⾜オンラインのdevopsコミュニティに参画、活⼒を得た転職、運⽤の世界でキャリアを積み、「devops」チームの共同作業を経験ストーリーはコミュニティとして共有し、学習、成⻑するためのもの 4

Slide 5

Slide 5 text

ジェニファーのストーリー⾃分への技術⼒へのチームの依存問題知⾒共有を優先することで⻑期的にチーム/個⼈にとって良い結果に結びつけた devopsの価値は、ストーリーを共有し、コラボレーションを通じて問題を解決し、コミュニティを強化すること 5

Slide 6

Slide 6 text

私たちのストーリー私たちは、異なる視点から毎⽇様々な経験を積み重ねている経験はほかの⼈たちに教訓を与えるストーリーの共有で終わらず、新しいアイデアを試そう試したことのなかで機能するもの、しないものを判別できるようになれば、⾼度な実験を始められるようになる 6

Slide 7

Slide 7 text

2章. devopsとは何か思考の⽅法であり、仕事の⽅法である⽂化的なフレームワークだストーリーを共有し、共感を育み、個⼈とチームが効果的かつ永続的に⼒を出せるようにする 7

Slide 8

Slide 8 text

ストーリーの共有の効果チーム内の透明性が増し、チーム内に信頼が⽣まれるダメージの⼤きいミスをする前に、それを防ぐ⽅法を同僚に伝えられる新しい問題の解決に使える時間が増え、イノベーションが促進される 8

Slide 9

Slide 9 text

devops共同体明確に定義された⽬標を共有するその場その場でコミュニケーションをとる理解をダイナミックに調整、修正する 9

Slide 10

Slide 10 text

3章. devopsの歴史 10

Slide 11

Slide 11 text

1946 オペレータとしての開発者 1961 ソフトウェアエンジニアリングの始まり 1961 グローバルなコミュニティの始まり 1964 プロプラエタリソフトウェアと標準化の登場 1979 ネットワークの時代 1995 アプリケーションとウェブの時代 2001 ソフトウェア開発⼿法の発展 2006 オープンソースソフトウェアとプロプライエタリサービス 2008 アジャイルインフラストラクチャ 2009 DevOpsDaysの始まり 11

Slide 12

Slide 12 text

Slide 13

Slide 13 text

3章. devops歴史のまとめ歴史を振り返ると、⼈とプロセスではなく、結果を重視する傾向が⾒える⼈とプロセスを重視すると、「なぜ」「どのように」仕事をするかを改善することが重視されるようになる「何」から「なぜ」への転換は、私たちに仕事が持つ意味と⽬的を確⽴する⾃由と信頼を与える devopsの導⼊によって、専⾨化を競い合うのではなく、互いの協⼒と協調を重視し職種を越えて⼈とプロセスを重視するようになった 13

Slide 14

Slide 14 text

4章. 基本的な⽤語と概念 (4.4まで) 4.1. ソフトウェア開発⼿法 4.2. 運⽤⼿法 4.3. システム⼿法 4.4. 開発、リリース、デプロイの諸概念 14

Slide 15

Slide 15 text

4.1. ソフトウェア開発⼿法開発の仕事を別々のフェーズに分割するプロセスのこと 4.1.1 ウォーターフォール 4.1.2 アジャイル 4.1.3 スクラム 15

Slide 16

Slide 16 text

4.1. ソフトウェア開発⼿法 4.1.1 ウォーターフォール最初の要件定義と設計に時間を割き、構造化される傾向 16

Slide 17

Slide 17 text

4.1. ソフトウェア開発⼿法 4.1.2 アジャイルプロセスやツールよりも個⼈と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。『アジャイルソフトウェア開発宣⾔』 http://agilemanifesto.org/iso/ja/manifesto.html 17

Slide 18

Slide 18 text

4.1. ソフトウェア開発⼿法 4.1.2 アジャイルのイメージ図 18

Slide 19

Slide 19 text

4.1. ソフトウェア開発⼿法 4.1.2 アジャイルとdevopsの関係共通点︓⼈、対話、コラボレーションを強調相違点︓devopsは開発者だけでなく、広い範囲のひとたちに影響。開発プロセスだけでなく、組織全体が適⽤の対象 19

Slide 20

Slide 20 text

4.1. ソフトウェア開発⼿法 4.1.3 スクラム開発チームが変化にすばやく対応する能⼒を最⼤化することに重点をおく開発⼿法変化︓プロジェクトの変化と顧客ニーズの変化の両⽅ 20

Slide 21

Slide 21 text

4.1. ソフトウェア開発⼿法 4.1.3 デイリースクラムチームメンバーがスプリントの⽬標を達成するために昨⽇何をしたか今⽇何をするか妨げとなるものは何か(困っていることはあるか) を報告 21

Slide 22

Slide 22 text

4.1. ソフトウェア開発⼿法 4.1.3 スクラムマスターの役割チームの⾃⼰組織化を⽀援する仕事の調整を助けるチームが前進できるように障害を取り除くプロダクトオーナーやステークホルダーを巻き込んで、何をもって「完成」なのか、現在の進捗がどうなのかについて共通理解を持てるようにする 22

Slide 23

Slide 23 text

4.2. 運⽤⼿法 ITや運⽤の仕事も分割したり構造化したりできる。 4.2.1 ITIL 4.2.2 COBIT 23

Slide 24

Slide 24 text

4.2. 運⽤⼿法 4.2.1 ITIL (Information Technology Infrastracture Library) ITサービス管理のためのプラクティス集プロセス、⼿順、タスク、チェックリストなどを解説した5冊の書籍からなる ITILは攻めより守りに⽴つことが多い。使っている企業はより⼤胆な計画と顧客重視の姿勢を取り⼊れたほうがよいステファン・マン 24

Slide 25

Slide 25 text

4.2. 運⽤⼿法 4.2.2 COBIT(Control Objectives for Information and Related Technology) I情報と技術のガバナンスと管理のフレームワーク 5つの原則 1. ステークホルダーのニーズにこたえる 2. 企業全体をカバーする 3. ひとつに統合されたフレームワークを適⽤する 4. 包括的なアプローチを実現する 5. ガバナンスとマネジメントを分離する 25

Slide 26

Slide 26 text

4.3. システム⼿法参考資料ドネラ・メドウズ『Thinking in Systems』(システム思考) リチャード・クック博⼠『How Complec Systems Fail』(システムはどのようにして失敗するのか) 26

Slide 27

Slide 27 text

4.3. システム⼿法 4.3.1 リーン＝顧客価値の最⼤化とムダの最⼩化リーン思考の5原則価値バリューストリームフロープル完全性 27

Slide 28

Slide 28 text

4.3. システム⼿法 4.3.1 リーンリーン⽣産におけるムダ仕掛かりの仕事余分な機能学習のやり直し不要な引継ぎ遅れ⽋陥 28

Slide 29

Slide 29 text

4.3. システム⼿法 4.3.1 リーンリーンIT,リーンソフトウェア開発におけるムダソフトウェアの不要な機能通信遅延アプリケーションの応答の遅さ⾼圧的で官僚主義的なプロセス 29

Slide 30

Slide 30 text

4.3. システム⼿法 4.3.1 リーンリーンソフトウェア開発の⽅法⼤別して以下の2⽅法ツールを通じたムダの除去に重点を置くもの作業のフローの改善に重点を置くもの(The Toyota Way) いずれも⽬標は同じだが、アプローチのちがいによって結果にも違いが出ることがある 30

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

4.4. 開発、リリース、デプロイの諸概念 4.4.1 バージョン管理︓ファイルに対する変更記録に使⽤対象ソースコード、アセット、ドキュメントできることコミット、⽐較、マージ、過去リビジョン復元共同作業をしやすくする 32

Slide 33

Slide 33 text

4.4. 開発、リリース、デプロイの諸概念 4.4.2 テスト駆動開発︓テストコードを先に書くメリット新しい機能を明確に定義できるコードが⾏うべきことがはっきりする開発者のフィードバックループが短縮される⾃分が書くコードに対して責任をもつようになる「責任の共有」「開発サイクルの時間短縮」は devops⽂化の重要な要素のひとつ 33

Slide 34

Slide 34 text

4.4. 開発、リリース、デプロイの諸概念 4.4.3 アプリケーションのデプロイ︓リリースのプロセスリリースのプロセス計画作成、実⾏、保守必要なことシステムに対する変更の考慮 eg.)アプリケーションを動かすのに必要な依存部分をインフラ⾃動化を使って構築⾼品質のソフトウェアを実現する 34

Slide 35

Slide 35 text

4.4. 開発、リリース、デプロイの諸概念 4.4.4 継続的インテグレーション(CI) 開発者が書いたコードとマスターを頻繁に統合するプロセスやること⾃動テストの実⾏テスト結果をもとに問題点の素早い特定と修正メリットリグレッション(影響)を起こした変更を⾒つけやすくなる 35

Slide 36

Slide 36 text

4.4. 開発、リリース、デプロイの諸概念 4.4.5 継続的デリバリー(CD)︓CIの⼀歩先新たな変更をしても⾃動テストが結合できる変更をデプロイ可能にする⾃動テストとCIを活⽤して、ソフトウェアを頻繁にリリースできるようにする 36

Slide 37

Slide 37 text

4.4. 開発、リリース、デプロイの諸概念 4.4.6 継続的デプロイ(同じくCDと呼ばれる) 変更を本番環境にデプロイするプロセスやることテストや結果検証の仕組みの⽤意本番環境に実際にデプロイメリット⾃分の仕事の結果が⾒えるのが早くなる -> 職務、仕事に対する満⾜感アップ -> パフォーマンスの向上顧客のもとに製品を早く届けることができる -> 顧客満⾜度を上げることにつながる 37

Slide 38

Slide 38 text

4.4. 開発、リリース、デプロイの諸概念 4.4.7 MVP(実⽤最⼩限の製品) Minimum Viable Product︓ 製品のアイデアを確かめるために、必要最⼩限の労⼒で製品のプロトタイプを作る考え⽅ ︓100%完全な製品を開発してからユーザに届ける ︓コンセプトの核となる部分のために機能を減らす、⾼度な設定を省略する 38