Download to read offline
![[2021年3月11日] エンタープライズ・インフラ構築・運用でもDevOpsを活用しよう（CloudNative Days Spring 2021 ON...](https://cdn.slidesharecdn.com/ss_thumbnails/cndopresentation20210311-210228035404-thumbnail.jpg?width=640&height=640&fit=bounds)
皆で考えるDevOps
- 1.
- 2. 話す事 ◉ なぜDevOpsなのか ◉ DevOpsてなに？ ◉俺たちのDevOps 2
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10. ◉ 多くの産業でコンピュータを 使う ○ コンピュータを使う仕事は 82/100 ○プログラミングは13/100くら い 10 100の職業でどんな数学を使うのか１枚の表にまとめてみた https://readingmonkey.blog.fc2.com/blog-entry-625.html
- 11.
- 12.
- 13. 13 サブスクリプションモデル ◉ Amazon Prime, Netflix , Youtube Premium ◉ Slack , Office 365.G Suite ◉ GEはモノを売らずにサービスを売ることで、産業 機器界のエアビー、ウーバーをめざしている
- 14.
- 15.
- 16. 16 LTVとCPA ◉ マーケで使われがちな用語 ◉ LTV（LifeTime Value） ○ 顧客がサービスを使ううえで、生涯合計でどのくらい の額を使うか ◉ CPA（Cost per Acquisition） ○ 顧客一人あたりの獲得費用 ◉ LTV × 粗利率 = 上限CPA （例：LTVが1000万で粗利が20%のサービスだと、800万 がCPAの上限）
- 17. 17 LTV＞CPA の場合 ◉ ガンガン営業すればめっちゃ儲かる ◉サービスの規模拡大が容易であればあっという 間に5000兆円逝く
- 18.
- 19. DevとSalesにとっても パッケージ開発/販売とは違う世界 ◉ 素早くリリース→素早く 改善 ◉ DevやSalesだけでは実 現できない ◉外的、内的要因から来 る変化に柔軟に対応 ◉ 売って終わりではない 19
- 20. DevとSalesにとっても パッケージ開発/販売とは違う世界 ◉ 変化し続ける力≒運用 に軸足が移ってきた ◉ 腕の見せ所はどこか ◉エンジニアリング目線で の競合優位性 20
- 21.
- 22. 22 DevOpsの誕生 ◉ きっかけは2009年Velocityカンファレンスでの Flickrの登壇資料 ◉ DevとOpsで協力して1日10回デプロイできるよう にしたよ ○インフラの自動化 ○ 共有バージョン管理 ○ One step build and deploy ○ 監視メトリクスの共有 ○ etc
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32. DevOpsによくある誤解 32 ◉ 始まりはDevとOpsの話でしたが、DevOpsの概 念とアイデアには全ての職能が含まれています ◉ 職責や職能が違うチーム同士がコミュニケーショ ンを改善し、目標のために共同作業するという考 えは、企業のどこにでも活用できる ◉最も効果的にDevOpsをやるには、セキュリティ、 QA、サポート、法務など全てを考慮に入れると 良い
- 33.
- 34. DevOpsによくある誤解 34 ◉ DevOpsチームは必要でも十分でもない ◉ DevOpsチームが機能しているならそれは問題 ではない ◉DevOpsは文化でありプロセスということを根付 かせていくのが大事 ◉ 『DevOps担当』がいて、その人に任せればいい やという考えも間違い
- 35.
- 36.
- 37.
- 38. ◉ DevOpsは文化でありプry ◉ 自動化することで時間が節 約できるならOK ◉自動化は闇が深い 38 https://speakerdeck.com/opelab/20190306-operation- what-automation?slide=24
- 39.
- 40.
- 41. DevOpsによくある誤解 41 ◉ DevOpsは文化でry ◉ 1人の人間が開発とインフラの知識を有している 必要があるという認識は間違い ◉『DevOps担当』がいて、その人に任せればいい という考えも間違い
- 42.
- 43. DevOpsのアンチパターン 43 ◉ 非難文化 ◉ サイロ化 ◉ヒューマンエラー ◉ 根本原因分析
- 44. 44 4本の柱 ◉ コラボレーション ◉ アフィニティ ◉ツール ◉ スケーリング
- 45.
- 46. 46 コラボレーション ◉ 複数人での対話や教えあいを尊重し、結果に向 かってモノを作っていくプロセス ◉ flickrのDevとOpsの協力がDevOps運動の発端 ◉チームのメンバーがそれぞれ協力して仕事をし ていけるか
- 47.
- 48.
- 49.
- 50. 50 ツール ◉ ツールは加速装置だが、自分らに合うかどうか の検証が重要 ◉ 価値、規範、組織構造の問題点を把握できてい ないと文化的な負債が増えて思わぬエラー要因 になる ◉ツールに適切な投資をし、合わないツールを使 わないようにする
- 51.
- 52. 52 スケーリング ◉ 組織がライフサイクル全体で導入しなければな らないプロセス ◉ 組織の規模が違えば、技術的にも文化的にも考 慮する事が違ってくる ◉組織の成長や成熟、縮小に合わせて他の3つの 柱への取り組み方を変える必要がある
- 53.
- 54. 54 雑なまとめ ◉ 文化でありプロセス ◉ 目的のためにチームや組織の枠を超えてコラボ レーションしましょう ◉そのために有効なツールがあれば使いましょう ◉ こうすればOKという正解はない。改善運動 ◉ 喧嘩とか、なすりつけ合いしてる場合ですか？暇 なの？
- 55.
- 56.
- 57.
- 58.
- 59.
- 60. 60 俺たちのDevOps ◉ 文化的な事はWinGと被ってる部分がある ◉ 1on1とか交流イベントもわりとやってる ◉組織的にも運用と開発が明確に分かれてない
- 61.
- 62. 62 俺たちのDevOps ◉ 課題が見えてきたので取り組もう ○ 方針決め ○バッチ監視方法策定 ○ ログの標準化 ○ デプロイ自動化 ○ 負荷テスト推進
- 63. 63 見えてきた部分（個人的見解 ◉ 運用と開発は分かれてないけど、事業部と開発 とインフラで分かれてる ○ 動きが部署の評価基準のみを満たすようになってな いか ○分かりやすい数値、状態に落とし込みすぎてないか （多くの場合、簡略化は何かを削ぎ落す ○ 間に落ちてるボールを拾うメリットはあるのか
- 64. 64 見えてきた部分（個人的見解 ◉ イケイケではない サービスもある ◉ コストを抑えて長くサービ スを提供する ◉KPIに使ってる定規は適切 か とあるスタートアップの評価指標（メトリクス） https://www.slideshare.net/takaumada/startup-metrics-survive
- 65.
- 66.
- 67.
- 68.
- 69.
- 70.
- 71. 71 エモいチェックリスト ◉ カルチャ ◉ 開発 ◉テスト ◉ Release ◉ 監視 ◉ 管理 https://bitbucket.org/willgateteamvietnum/devops-check-list/src/master/docs/checklist/dev-ops.md
- 72.
- 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.
- 83.
- 84.
- 85.