皆で考えるDevOps
- 1. 皆で考えるDevOps
- 2. 話す事 ◉ なぜDevOpsなのか ◉ DevOpsてなに？ ◉ 俺たちのDevOps 2
- 3. 共有したい事 3
- 10. ◉ 多くの産業でコンピュータを 使う ○ コンピュータを使う仕事は 82/100 ○ プログラミングは13/100くら い 10 100の職業でどんな数学を使うのか１枚の表にまとめてみた https://readingmonkey.blog.fc2.com/blog-entry-625.html
- 13. 13 サブスクリプションモデル ◉ Amazon Prime , Netflix , Youtube Premium ◉ Slack , Office 365.G Suite ◉ GEはモノを売らずにサービスを売ることで、産業 機器界のエアビー、ウーバーをめざしている
- 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兆円逝く
- 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
- 28. DevOpsてなに？ 28
- 32. DevOpsによくある誤解 32 ◉ 始まりはDevとOpsの話でしたが、DevOpsの概 念とアイデアには全ての職能が含まれています ◉ 職責や職能が違うチーム同士がコミュニケーショ ンを改善し、目標のために共同作業するという考 えは、企業のどこにでも活用できる ◉ 最も効果的にDevOpsをやるには、セキュリティ、 QA、サポート、法務など全てを考慮に入れると 良い
- 34. DevOpsによくある誤解 34 ◉ DevOpsチームは必要でも十分でもない ◉ DevOpsチームが機能しているならそれは問題 ではない ◉ DevOpsは文化でありプロセスということを根付 かせていくのが大事 ◉ 『DevOps担当』がいて、その人に任せればいい やという考えも間違い
- 38. ◉ DevOpsは文化でありプry ◉ 自動化することで時間が節 約できるならOK ◉ 自動化は闇が深い 38 https://speakerdeck.com/opelab/20190306-operation- what-automation?slide=24
- 41. DevOpsによくある誤解 41 ◉ DevOpsは文化でry ◉ 1人の人間が開発とインフラの知識を有している 必要があるという認識は間違い ◉ 『DevOps担当』がいて、その人に任せればいい という考えも間違い
- 43. DevOpsのアンチパターン 43 ◉ 非難文化 ◉ サイロ化 ◉ ヒューマンエラー ◉ 根本原因分析
- 44. 44 4本の柱 ◉ コラボレーション ◉ アフィニティ ◉ ツール ◉ スケーリング
- 45. 45 コラボレーション
- 46. 46 コラボレーション ◉ 複数人での対話や教えあいを尊重し、結果に向 かってモノを作っていくプロセス ◉ flickrのDevとOpsの協力がDevOps運動の発端 ◉ チームのメンバーがそれぞれ協力して仕事をし ていけるか
- 47. 47 アフィニティ
- 49. 49 ツール
- 50. 50 ツール ◉ ツールは加速装置だが、自分らに合うかどうか の検証が重要 ◉ 価値、規範、組織構造の問題点を把握できてい ないと文化的な負債が増えて思わぬエラー要因 になる ◉ ツールに適切な投資をし、合わないツールを使 わないようにする
- 51. 51 スケーリング
- 52. 52 スケーリング ◉ 組織がライフサイクル全体で導入しなければな らないプロセス ◉ 組織の規模が違えば、技術的にも文化的にも考 慮する事が違ってくる ◉ 組織の成長や成熟、縮小に合わせて他の3つの 柱への取り組み方を変える必要がある
- 53. 53 雑なまとめ
- 54. 54 雑なまとめ ◉ 文化でありプロセス ◉ 目的のためにチームや組織の枠を超えてコラボ レーションしましょう ◉ そのために有効なツールがあれば使いましょう ◉ こうすればOKという正解はない。改善運動 ◉ 喧嘩とか、なすりつけ合いしてる場合ですか？暇 なの？
- 55. 俺たちのDevOps 55
- 58. 俺たちのDevOps 58
- 59. 俺たちのDevOps 59
- 60. 60 俺たちのDevOps ◉ 文化的な事はWinGと被ってる部分がある ◉ 1on1とか交流イベントもわりとやってる ◉ 組織的にも運用と開発が明確に分かれてない
- 62. 62 俺たちのDevOps ◉ 課題が見えてきたので取り組もう ○ 方針決め ○ バッチ監視方法策定 ○ ログの標準化 ○ デプロイ自動化 ○ 負荷テスト推進
- 63. 63 見えてきた部分（個人的見解 ◉ 運用と開発は分かれてないけど、事業部と開発 とインフラで分かれてる ○ 動きが部署の評価基準のみを満たすようになってな いか ○ 分かりやすい数値、状態に落とし込みすぎてないか （多くの場合、簡略化は何かを削ぎ落す ○ 間に落ちてるボールを拾うメリットはあるのか
- 64. 64 見えてきた部分（個人的見解 ◉ イケイケではない サービスもある ◉ コストを抑えて長くサービ スを提供する ◉ KPIに使ってる定規は適切 か とあるスタートアップの評価指標（メトリクス） https://www.slideshare.net/takaumada/startup-metrics-survive
- 66. “ NEXT ACTION 66
- 67. 67
- 71. 71 エモいチェックリスト ◉ カルチャ ◉ 開発 ◉ テスト ◉ Release ◉ 監視 ◉ 管理 https://bitbucket.org/willgateteamvietnum/devops-check-list/src/master/docs/checklist/dev-ops.md
- 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