みんなで考えるDevOps.pdf

Transcript

1. 皆で考えるDevOps
2. 話す事 ◉ なぜDevOpsなのか ◉ DevOpsてなに？ ◉ 俺たちのDevOps 2
3. 共有したい事 3
4. “ DevOps とは何か 今、何をしているのか 我々は何をすべきか 4
5. なぜDevOpsなのか 5
6. 釣りバカ日誌（第1作：1988年） 紙ベースで仕事 6
7. 釣りバカ日誌（第1作：1988年） たまにパソコンがある（何に使ってるかは近くのオジサンに聞いてください） 7
8. 釣りバカ日誌（釣りバカ日誌　新米社員 浜崎伝助：2017年） ノートPC一人1台 8
9. 半沢直樹（半沢直樹Ⅱ･エピソードゼロ： 2020年） 凄い人アピールの材料に Kubernetesが使われる 9
10. ◉ 多くの産業でコンピュータを 使う ◦ コンピュータを使う仕事は 82/100 ◦ プログラミングは13/100くら い 10 100の職業でどんな数学を使うのか１枚の表にまとめてみた https://readingmonkey.blog.fc2.com/blog-entry-625.html
11. 11 ソフトウェアが世界を飲み込む ◉ 世界の時価総額ランキングTOP10 ◉ ここ20年の変化として、モノを売る会社が減っ て、モノを持たずに儲ける会社が増えた https://finance-gfp.com/?p=2042 https://finance-gfp.com/?p=6595
12. 12 ソフトウェアが世界を飲み込む
13. 13 サブスクリプションモデル ◉ Amazon Prime , Netflix , Youtube Premium ◉ Slack , Office 365.G Suite ◉ GEはモノを売らずにサービスを売ることで、産業 機器界のエアビー、ウーバーをめざしている
14. 14 ソフトウェアが世界を飲み込む 上位に食い込んでる会社 は全てサブスクリプション 型のサービスを持っている
15. 15 LTVとCPA
16. 16 LTVとCPA ◉ マーケで使われがちな用語 ◉ LTV（Life Time Value） ◦ 顧客がサービスを使ううえで、生涯合計でどのくらい の額を使うか ◉ CPA（Cost per Acquisition） ◦ 顧客一人あたりの獲得費用 ◉ LTV × 粗利率 = 上限CPA （例：LTVが1000万で粗利が20%のサービスだと、800万 がCPAの上限）
17. 17 LTV＞CPA の場合 ◉ ガンガン営業すればめっちゃ儲かる ◉ サービスの規模拡大が容易であればあっという 間に5000兆円逝く
18. 18 規模の拡大が容易 ◉ コンピュータの性能が向上し、より多くの事を行 えるようになった ◉ さらにクラウドの普及でコンピュータ資源の調達 スピードが、数週間から数分になった
19. DevとSalesにとっても パッケージ開発/販売とは違う世界 ◉ 素早くリリース→素早く 改善 ◉ DevやSalesだけでは実 現できない ◉ 外的、内的要因から来 る変化に柔軟に対応 ◉ 売って終わりではない 19
20. DevとSalesにとっても パッケージ開発/販売とは違う世界 ◉ 変化し続ける力≒運用 に軸足が移ってきた ◉ 腕の見せ所はどこか ◉ エンジニアリング目線で の競合優位性 20
21. 21 DevOpsの誕生
22. 22 DevOpsの誕生 ◉ きっかけは2009年Velocityカンファレンスでの Flickrの登壇資料 ◉ DevとOpsで協力して1日10回デプロイできるよう にしたよ ◦ インフラの自動化 ◦ 共有バージョン管理 ◦ One step build and deploy ◦ 監視メトリクスの共有 ◦ etc
23. 23 DevOpsの誕生 ◉ 当時の資料は現在でも閲覧可能 https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
24. 24 ウェブオペレーション（2011年） https://www.oreilly.co.jp/books/9784873114934/
25. 25 ウェブオペレーション（2011年） https://www.oreilly.co.jp/books/9784873114934/
26. 26 ウェブオペレーション（2011年） https://www.oreilly.co.jp/books/9784873114934/
27. 27 DevOps本（2020年）
28. DevOpsてなに？ 28
29. 答えはいつも 心の中にあります 29
30. “ Devopsはものの考え方であり、 仕事の進め方である。 ストーリーを共有し、共感を育み、 効果的かつ永続的に力を出せるようにする。 そのためのフレームワークだ。 30
31. DevOpsによくある誤解 31 DevOpsって、開発とかイ ンフラの人達がやるんで しょ？
32. DevOpsによくある誤解 32 ◉ 始まりはDevとOpsの話でしたが、DevOpsの概 念とアイデアには全ての職能が含まれています ◉ 職責や職能が違うチーム同士がコミュニケーショ ンを改善し、目標のために共同作業するという考 えは、企業のどこにでも活用できる ◉ 最も効果的にDevOpsをやるには、セキュリティ、 QA、サポート、法務など全てを考慮に入れると 良い
33. DevOpsによくある誤解 33 ◦◦君！ 至急DevOpsチームを 作りなさい！
34. DevOpsによくある誤解 34 ◉ DevOpsチームは必要でも十分でもない ◉ DevOpsチームが機能しているならそれは問題 ではない ◉ DevOpsは文化でありプロセスということを根付 かせていくのが大事 ◉ 『DevOps担当』がいて、その人に任せればいい やという考えも間違い
35. DevOpsによくある誤解 35 DevOpsやりたいです どのツールを使えばいい ですか？
36. DevOpsによくある誤解 36 ◉ DevOpsは文化でありプロセス ◉ 確かにツールは効果的だが特定のツールが必 要という訳ではない
37. DevOpsによくある誤解 37 自動化する仕組み作った んで ばっちりDevOpsです！
38. ◉ DevOpsは文化でありプry ◉ 自動化することで時間が節 約できるならOK ◉ 自動化は闇が深い 38 https://speakerdeck.com/opelab/20190306-operation- what-automation?slide=24
39. 39 https://speakerdeck.com/opelab/20190306-operation-what-automation?slide=24
40. DevOpsによくある誤解 40 DevOpsやる事になった から、インフラも開発も運 用もできるDevOpsエンジ ニアを育成しなさい
41. DevOpsによくある誤解 41 ◉ DevOpsは文化でry ◉ 1人の人間が開発とインフラの知識を有している 必要があるという認識は間違い ◉ 『DevOps担当』がいて、その人に任せればいい という考えも間違い
42. DevOpsのアンチパターン 42
43. DevOpsのアンチパターン 43 ◉ 非難文化 ◉ サイロ化 ◉ ヒューマンエラー ◉ 根本原因分析
44. 44 4本の柱 ◉ コラボレーション ◉ アフィニティ ◉ ツール ◉ スケーリング
45. 45 コラボレーション
46. 46 コラボレーション ◉ 複数人での対話や教えあいを尊重し、結果に向 かってモノを作っていくプロセス ◉ flickrのDevとOpsの協力がDevOps運動の発端 ◉ チームのメンバーがそれぞれ協力して仕事をし ていけるか
47. 47 アフィニティ
48. 48 アフィニティ ◉ チーム間の関係を構築し、組織の共通目標を念 頭に置いて個々のチーム目標の違いを乗り越 え、共感を育て、他のチームの人からも学習する プロセス ◉ 組織間だけでなく企業間も越えてコミュニティを 形成していこう
49. 49 ツール
50. 50 ツール ◉ ツールは加速装置だが、自分らに合うかどうか の検証が重要 ◉ 価値、規範、組織構造の問題点を把握できてい ないと文化的な負債が増えて思わぬエラー要因 になる ◉ ツールに適切な投資をし、合わないツールを使 わないようにする
51. 51 スケーリング
52. 52 スケーリング ◉ 組織がライフサイクル全体で導入しなければな らないプロセス ◉ 組織の規模が違えば、技術的にも文化的にも考 慮する事が違ってくる ◉ 組織の成長や成熟、縮小に合わせて他の3つの 柱への取り組み方を変える必要がある
53. 53 雑なまとめ
54. 54 雑なまとめ ◉ 文化でありプロセス ◉ 目的のためにチームや組織の枠を超えてコラボ レーションしましょう ◉ そのために有効なツールがあれば使いましょう ◉ こうすればOKという正解はない。改善運動 ◉ 喧嘩とか、なすりつけ合いしてる場合ですか？暇 なの？
55. 俺たちのDevOps 55
56. “ DevOpsには本当の意味での 終わりはない。 共通理解をずっと維持しなが ら、絶えず刷新していかなけ ればならない。 56
57. “ DevOpsとは継続的な変化の プロセスに参加する事への誘 いであり、組織内のすべての チームにやってくる勝利への 感謝であり、虐待行為への明 確な拒絶である。 57
58. 俺たちのDevOps 58
59. 俺たちのDevOps 59
60. 60 俺たちのDevOps ◉ 文化的な事はWinGと被ってる部分がある ◉ 1on1とか交流イベントもわりとやってる ◉ 組織的にも運用と開発が明確に分かれてない
61. 61 俺たちのDevOps ◉ まずは我が身を振り返ろう
62. 62 俺たちのDevOps ◉ 課題が見えてきたので取り組もう ◦ 方針決め ◦ バッチ監視方法策定 ◦ ログの標準化 ◦ デプロイ自動化 ◦ 負荷テスト推進
63. 63 見えてきた部分（個人的見解 ◉ 運用と開発は分かれてないけど、事業部と開発 とインフラで分かれてる ◦ 動きが部署の評価基準のみを満たすようになってな いか ◦ 分かりやすい数値、状態に落とし込みすぎてないか （多くの場合、簡略化は何かを削ぎ落す ◦ 間に落ちてるボールを拾うメリットはあるのか
64. 64 見えてきた部分（個人的見解 ◉ イケイケではない サービスもある ◉ コストを抑えて長くサービ スを提供する ◉ KPIに使ってる定規は適切 か とあるスタートアップの評価指標（メトリクス） https://www.slideshare.net/takaumada/startup-metrics-survive
65. 65 https://www.slideshare.net/takaumada/startup-metrics-survive スタートアップは経済環境に合わせてその事業スピードを調整する必要があり、そのためにも メトリクスをうまく利用することが重要です。
66. “ NEXT ACTION 66
68. “ 5000兆円のために、事業 部、開発、インフラの役割分 担は残しつつも 一丸となって正解のない問題 にチャレンジする必要がある 68
69. “ エモいチェックリストを 作って たまに見直すようにしよう 69
70. 70 チェックリスト作ろう ◉ MS謹製のチェックリストを改変 ◦ チョット足して、Azureの固有名詞を変換 https://docs.microsoft.com/ja-jp/azure/architecture/checklist/dev-ops
71. 71 エモいチェックリスト ◉ カルチャ ◉ 開発 ◉ テスト ◉ Release ◉ 監視 ◉ 管理 https://bitbucket.org/willgateteamvietnum/devops-check-list/src/master/docs/checklist/dev-ops.md
72. “ このチェックリストは、DevOps のカルチャとプロセスを評価 するための出発点としてご利 用ください。 72
73. “ 全てを文字通りに実践する必 要はありませんし、何個できて いたら合格というモノでもあり ません。自組織の現状を見直 し、課題を洗い出すヒント集と して活用してください。 73
74. 74 エモいチェックリスト （カルチャ） ◉ 組織とチームとの間で業務上の整合性を確保す る ◦ 業務、開発、運用のすべてのチームが認識を共有す る必要があります。 ◉ イノベーションを起こそう ◦ イノベーションは一部の天才のひらめきではありませ ん。私たち凡人でも可能なプラクティスの結晶なので す。 https://bitbucket.org/willgateteamvietnum/devops-check-list/src/master/docs/checklist/dev-ops.md
75. 75 エモいチェックリスト （開発） ◉ 運用環境と同様の環境を開発者に提供する ◦ テスト データは、運用環境で使用されているデータと 矛盾がないようにしてください ◉ アプリケーションをインストルメント化して洞察を 得る ◦ Web アプリケーションのアプリケーションパフォーマン ス管理と使用状況を追跡できるようにしましょう https://bitbucket.org/willgateteamvietnum/devops-check-list/src/master/docs/checklist/dev-ops.md
76. 76 エモいチェックリスト （テスト） ◉ パフォーマンス テストを自動化してパフォーマン スの問題を早期に把握する ◦ 待ち時間、読み込み時間、リソース使用量など、各種 のメトリックに関して、許容できるパフォーマンス目標 を定義してください ◉ ビジネス継続性テストを実施する ◦ バックアップの回復とフェールオーバーを含む大規模 なビジネス継続性のテストを作成しよう https://bitbucket.org/willgateteamvietnum/devops-check-list/src/master/docs/checklist/dev-ops.md
77. 77 エモいチェックリスト （Release） ◉ すべての変更を文書化する ◦ いかに小さな変更でも必ず、明確な記録を残すように しましょう ◉ インフラストラクチャをイミュータブルにすることを 検討する ◦ 運用環境にデプロイした後にインフラストラクチャを変 更すべきではないという原則を身につけましょう https://bitbucket.org/willgateteamvietnum/devops-check-list/src/master/docs/checklist/dev-ops.md
78. 78 エモいチェックリスト （監視） ◉ ログとメトリクスを集計して相互に関連付ける ◦ 問題の全体像が把握できるようにデータを整理して 表示し、イベントが互いに関連している場合にはそれ が可能な限り明らかになるようにします ◉ アラートを定期的に見直す ◦ 鳴りっぱなしで対応していないアラートはありません か？アラートを定期的に見直すことでシステム構成に 新たな気付きを得られるかもしれません https://bitbucket.org/willgateteamvietnum/devops-check-list/src/master/docs/checklist/dev-ops.md
79. 79 エモいチェックリスト （管理） ◉ 運用マニュアルを用意する ◦ 文書が共有されることがきわめて重要となります。 各 自が持つ知識を提供し、共有するようチーム メンバー に奨励してください ◉ コードとしてのインフラストラクチャのアプローチ をプロビジョニングに採用する ◦ リソースのプロビジョニングに必要な手動による構成 は、できるだけ少なくしましょう https://bitbucket.org/willgateteamvietnum/devops-check-list/src/master/docs/checklist/dev-ops.md
80. 80 なんとなくまとめ ◉ まずは目的の共有 ◦ 組織とチームとの間で業務上の整合性を確 保する ◦ タテヨコで色んなチームがあります ◦ 「それは彼らには必要ない情報」などと勝手 にフィルタリングしてませんか？ ◦ Slackのチャンネルに無駄に鍵をかけてませ んか https://bitbucket.org/willgateteamvietnum/devops-check-list/src/master/docs/checklist/dev-ops.md
81. 81 なんとなくまとめ ◉ DevOpsチームはあってもなくてもいいです ◦ 良く分かんないことはDevOps ◦ チームが一丸となって5000兆円を目指せ て、それがやりやすい状態ならOK ◦ 「俺たちDevOps」などとイキる ◦ このまま行けばQAに近い感じになる https://bitbucket.org/willgateteamvietnum/devops-check-list/src/master/docs/checklist/dev-ops.md
82. 82 なんとなくまとめ ◉ チェックリストやEffective DevOpsを見て、「これ やってみようかな」と思って行動に移してくれれ ば最高です https://bitbucket.org/willgateteamvietnum/devops-check-list/src/master/docs/checklist/dev-ops.md
83. 答えはいつも 心の中にあります 83
84. “ DevOps とは何か 今、何をしているのか我々は 何をすべきか 84
85. 質問ある ? Thanks! 85