運用目線で考える！開発と共に取り組むDevOpsのポイント

2022/12/22 JFrog Webinar
システム開発で「DevOps」に対する注目は高まっており、今日では「DevSecOps」のような開発(Dev)・運用(Ops)以外の要素を含めた考え方も出るようになってきました。DevOpsの導入を進めたいと考える企業も多くある中、開発側はさまざまな取り組みをする一方、運用側ではどのようなことから始めれば良いかわからないといった声も聞くようになっています。

このウェビナーで、今の現場を特に運用側を意識して振り返っていただきつつ、DevOpsを進める上で開発側・運用側それぞれが協調するにはどのようなことを行っていくべきか考えるきっかけにしていただきたいと思います。

Transcript

1. 運用目線で考える！ 開発と共に取り組むDevOpsのポイント 2022/12/22(木) 　JFrog Webinar
2. はじめに 2 Twitterが好きな方は #JFrog 公開後、本ウェビナーに ご登録いただいたメール宛に お知らせします #JFrog ぜひツイートをお願いします 本日の資料と動画は のちほど公開します！ Zoom機能で ぜひ、ご参加ください！ Q&A機能でご質問を 書き込んでください いつでも、何度でも！ チャットもご自由に お使いください ・ ご自身の現場のお話 ・ 賑やかしなど・・・ Q&A チャット
3. 自己紹介 3 ▪ Developer Advocate @ JFrog ▪ 「よしQ」と覚えていだけるとうれしいです ▪ 山形県鶴岡市からリモートワーク ▪ SIerでアプリケーション開発エンジニアやアーキテクト、ITコン サルなど経験 ▪ 提案〜要件定義〜設計・開発〜導入〜運用保守まで ▪ エンジニア目線で情報発信！ 佐藤 由久 SATO Yoshihisa @umekichi1984 @yoshiq-sato
4. アジェンダ 4 ▪ DevOpsとは ▪ 現状の現場を振り返る ▪ DevOpsを支える柱 (★) ▪ システム運用の取り組みポイント ▪ まとめ・Q&A ★: 事前のお知らせになかった内容
5. Ice Break 5 あるイベントでのアンケート結果。 Q. DevOpsの実践で感じている課題感や関心事はありますか？（自由記述） • 組織間でDevとOpsが別れている初期状態において、実施すべき行動はなにか • 組織の壁（異なる上司がメンバーを評価している） • 本開分離との整理方法 • 運用の自動化・省力化が重要と感じていても、なかなか手が回らず、手動での運用になっている • プロジェクトに取り入れても、運用側の負担が大きくなってしまう • バージョニングや耐障害性、エラー発生時のリカバリーなど • 開発後、リリースした後の監視や次の施策を打つ Ops領域に課題を感じている • OpsからDevへのフィードバック • 運用は外部に委託するという風土が残っている ※一部抜粋、表現の一部を変えているものがあります。 運用の面で困っている方が多い…。
6. 6 DevOpsとは
7. DevOpsとは 7 JFrog Platformのような ツールを導入して 開発・運用を 効率化すること ではない
8. DevOpsとは 8 顧客に価値を素早く届けるため 開発・運用が 協力する 文化的な姿勢・取り組み 言い方はさまざまあれど、 ・顧客に早く価値を届ける ・開発・運用が一体となって取り組む という点は概ね共通かな。
9. 開発と運用の対立？ 9 開発 運用 新しい機能をどんどん追加 し、 顧客に対して提供したい！ 開発したからリリースして！ 顧客に安定的にサービス提供 したい！ 変更することは安定へのリスク！ (組織の壁) どちらも顧客に価値を提供したいという想いは一緒だが、 果たすべき責任の違いと考え方の違いにより対立が起こることがある 早く障害のリカバリする ために、 原因調査したい！環境調べさせて！ いくら調査といっても、 本番環境を操作することで 稼働に影響が出してはいけない ！
10. 10 現状の現場を振り返る
11. そもそも... なぜ開発と運用を分ける必要があるのでしょう？ 11
12. 「専門性」による区別 12 運用担当 ＝ インフラ担当 開発担当 ＝ アプリ担当 サーバ/ネットワーク等のインフラに関する知識に特化 • アプリ要求にあったサーバやミドルウェアの設定 • 社内ポリシーに従ったネットワーク設定 • ハードウェアやアプリ以外のソフトウェアの運用保守 • サーバやネットワークのセキュリティ対策 ソフトウェア開発(プログラミングなど)に関する知識に特化 • 開発するシステムの要件定義（必要機能の洗い出し） • アプリロジックの設計と開発 • 処理の共通化による再利用性の向上 • UI/UXの検討と実装 システム開発・運用に必要な知識を分業的にして、それぞれの知識に特化して仕事ができるようにしている
13. 「開発フェーズ」による区別 13 運用担当 ＝ 運用・保守フェーズ担当 開発担当 ＝ (初期)開発フェーズ担当 既存機能の保守として不具合修正や機能拡張を行う • 一定コスト内でシステム障害時の対応や不具合修正、 ユーザ要望よる機能拡張を行う • コストが限られているため少人数で対応する • 初期開発時に整備された規約やツール、ドキュメントをベー スに対応する • 大規模な変更を伴う場合は、別コストとしてプロジェクトを切 り出し、初期開発同様に行う 主要機能の一気に作り上げる • 存在しない機能を必要なコストをかけて作り上げる • 開発規模によっては大勢のメンバーが関わる • 初期開発に必要な規約やツールを制定・整備する • 大規模な変更を行う場合はプロジェクト組成し、 運用・保守担当から変更部分を引き継いで開発する。 大規模な開発を行う際の、「開発」フェーズと「運用・保守」フェーズの区別
14. 「本開分離の原則」による区別 14 運用担当 ＝ 本番環境担当 開発担当 ＝ 開発環境担当 本番環境のシステムやデータに対するアクセス権を持つ • 必要な作業は依頼に基づいて対応 ◦ リリースや障害対応時のデータ取得やパッチ ◦ 手順書などの予め規定された作業実施する • 必要に応じて、開発担当への権限付与 ◦ 権限付与後も作業の監視を行う 開発環境のシステムやデータに対するアクセス権を持つ • 開発環境（＝本番の擬似環境）を使ったテスト・検証 ◦ テスト目的でのデータやアプリの改変が可能 ◦ 手順書などの依頼作業の検証 • 本番環境の利用が必要な場合は一時的な権限付与を依頼 ◦ 自由に使うことはできないので手順などを用意 ◦ 本番作業時は実施・チェックのように複数人で対応 IT内部統制への対応して、「本番環境のシステムやデータに対する不正行為の排除」を目的に分けている 本番 環境 開発 環境 結局のところ、 果たすべき責任によって分けられている。 チームが大きければ大きいほど分業してる？
15. システムを取り巻く環境の変化 15 モダンなシステム開発手法や考え方、周辺技術・ツールが進化してきている ▪ 開発を繰り返し行い、機能の拡張や改善を行なっていく考え方の広がり ◦ アジャイル開発、リーン ◦ CI/CD (継続的インテグレーション/継続的デプロイメント) ▪ インフラを扱う技術・ツールの変化 ◦ クラウド・コンピューティング ◦ コンテナ技術(Docker、Kubernatesなど) ◦ IaC (Infrastructure as Code) 新しい技術や考え方を踏まえたとき、 これまでの組織・取り組みは正しいと言えるでしょうか …？
16. 16 DevOpsを支える柱
17. DevOpsを支える柱 17 文化 ベスト プラクティス ツール ▪ DevOpsの形は１つではない ◦ 最終的にはすべて達成することを目指す（すべてを一気に取り入れる必要はない） ◦ 自分の組織にあった形で取り入れ、継続的に改善することが重要 この柱はJFrogの考え方で、 柱の考え方は諸説あります。
18. DevOpsを支える柱 18 文化 ▪ 開発・運用が１つのチームとして連携する ◦ 自動化、コミュニケーション、コラボレーションを促進する ▪ 試行錯誤しながら改善していく環境を作る ◦ 早い段階でのフィードバックと継続的な学習に重点を置く ▪ どのチームにも責任を果たすことを重んじて、何かあっても互いに非難しない ◦ 全力でやった結果失敗したことからは学びがある ◦ 失敗を非難するのではなく、改善に向かってどのようにしていくかを一緒に考える
19. DevOpsを支える柱 19 ベストプラクティス ▪ すべてをバージョン管理する ◦ ソースコードだけでなく、ビルド後に得られる実行形式のファイルや環境の設定ファイル、パラメータなど システムに関連するものはすべて管理し、履歴を追えるようにする ▪ インフラの変更もアジャイルに行う ◦ ソフトウェアだけでなく、インフラも同じように管理し、テストを通して品質を担保していく ▪ すべてを自動化する ◦ 手動実行によるミスやエラーの混入を防ぎ、スケールしやすい形にする ◦ CI/CDパイプラインの一部としてデプロイやテストなどを自動化していく ▪ CI/CDを取り入れる ◦ 開発から本番環境にリリースするまで、 CI/CDを用いて実行し、その過程で不具合が見つかってもリカバリを速やかに行 えるようにする ▪ 統一されたツール・プラットフォームを利用する ◦ 開発から本番まで、可能な限り同じツール、構成、ハードウェアリソースを利用する すべての企業・チームが同じベストプラクティ スを採用しているわけではない！ 良いソフトウェアをより早くリリースできれば、 この目標は達成していると言える
20. DevOpsを支える柱 20 ツール ▪ ソースコード管理（Gitなど） ▪ CI/CDパイプライン管理（JFrog Pipelines, Jenkins, Circle CIなど） ▪ テストツール（xUnit, Seleniumなど） ▪ 構成管理・デプロイツール（Docker, Terraform, Kubernates, Chefなど） ▪ バイナリ管理ツール（JFrog Artifactoryなど） ▪ 監視ツール（Zabbix, Nagiosなど) ▪ セキュリティ対策ツール（JFrog Xrayなど） ▪ コラボレーションツール（Slack, MS Teamsなどのチャットツール, Redmineなどのチケット管理ツール）
21. 21 システム運用の取り組みポイント
22. DevOpsの評価指標 22 パフォーマンス指標 高(High) 中(Medium) 低(Low) デプロイの頻度 本番環境へのデプロイ頻度（リリース頻度） 1日に複数回 1週間〜1ヶ月に1回 1〜6ヶ月に1回 変更のリードタイム コード変更完了から本番環境で実行されるまでの時間 1日〜1週間 1週間〜1ヶ月 1〜6ヶ月 サービスのリカバリ時間 本番環境でユーザ影響のある不具合が発生してから 復旧までに要する時間 1日以内 1日〜1週間 1週間〜1ヶ月 変更の失敗率 本番環境リリース後にサービス影響があり、 修正やロールバックなどの対応が必要となる割合 0〜15% 16〜30% 46〜60% 調査(*)による分布割合: 19 % 69 % 11 % *: Accelerate State of DevOps Report (2022年) https://cloud.google.com/devops/state-of-devops/ 顧客に対するサービス提供（ソフトウェアデリバリー）が DevOpsによりどの程度向上しているかを測る指標 高頻度でリリースしても、失敗率が低く、 リカバリも迅速に対応できる企業は存在する
23. システム運用の取り組みポイント 23 ▪ 評価指標から考えるポイント ◦ 積極的な変更・デプロイ（リリース）の一方で、失敗の可能性やリカバリ時間を考慮 ▪ 現状の業務から考えるポイント ◦ 本番環境の運用監視における確認指標 ◦ 障害発生時によく開発側から依頼を受ける確認箇所 ◦ インフラ構築技術のトレンド理解 ◦ セキュリティに対する備え (次ページで詳細) 障害時のリカバリが容易にできる仕組みを取り入れる 監視指標や状況を開発も参照可能となる仕組みを取り入れる インフラ構築のナレッジの適用可能性を検討する DevOpsの柱「文化」「ベストプラクティス」「ツール」を合わせて考えると考えやすい 例: ロールバックが必要時に対応可能となるようプロセスの整備、ツールを取り入れる 開発が自律的に取り掛れるようになるだけでなく、運用の理解にも繋がる クラウド活用やIaC導入等、より自動化可能となると、上記ポイントも取り組みやすい
24. セキュリティに対する構え 24 OSS脆弱性によるゼロデイ対策 ▪ 開発プロセスにOSS脆弱性などのセキュリティ対策の導入が 積極的に行われている ▪ OSS脆弱性は運用に入ってから発覚することも多くあり、 セキュリティに対する監視も重要 運用側も開発で何を使用しているかを理解することで、 初動を早く対応することが可能となる
25. JFrog Platformの活用例 25 監視、設定、管理者ダッシュボード インテリジェンスメトリクスの分析 すべてのソフトウェアパッケージと コンテナイメージを保存、管理 セキュリティとコンプライアンスの問題 解決 (OSS脆弱性・ライセンス問題のチェッ ク) クラウド、データセンターへ 安全なソフトウェア配布 デバイスフリートへの ソフトウェアデプロイ、運用、監視 エンドツーエンドの CI/CD自動化とオーケストレーション BUILD & TEST RELEASE DEPLOY VCS ソースコード リポジトリ On-premise and Hybrid Regional Sites Public Cloud Platforms IoT Edge
26. JFrog Platformの活用例 (Cont.) 26 VCS 開発チーム ①開発チームで 　複数メンバーの 　ソースコード開発 ③CIサービスがソースコードと、 　外部で配布されている依存する 　パッケージ(外部アーティファクト)を 　取得・ビルドしてアーティファクトを 　生成する ⑤QA担当者が 　QA実施し、 　問題なければ 　プロモーション処理 パッケージ配布元 外部アーティファクト QA担当者 アーティファクト 外部アーティファクト アーティファクト インター ネット ⑥運用チームが 　QA結果を受けて 　本番環境にデプロイ 　(リリース)する 運用担当者 ②開発チームが 　開発したコードを 　VCSに保管する アーティファクト リモート リポジトリ ローカルリポジトリ (本番用) ローカルリポジトリ (開発用) 脆弱性などのスキャン CIサービス アーティファクト管理 ※QA担当者の 　プロモーションにより 　本番用に自動コピー 　(メタデータ含む) ※ビルドにより生成 ※キャッシュ提供 　による高速化 ④アーティファクトを 　テスト環境にデプロイ アーティファクト アーティファクト テスト 環境 本番 環境 メタ データ メタ データ メタ データ アーティファクト: 　コードをビルドした結果得られる実行形式 メタデータ： 　ビルド環境の環境変数や利用しているOSS情報 ※OSSなど 開発だけでなく運用に入ってからも 継続的に脆弱性スキャンを実施 本番環境にデプロイすべきものが バージョン管理でき、 リカバリに使用 するものも簡単に特定可能
27. 27 まとめ
28. まとめ 28 ▪ DevOpsとは ◦ 顧客に価値を素早く届けるため、開発・運用が協力する文化的な姿勢・取り組み ▪ ツール導入すれば終わり、というものではない ◦ 立場の違いから対立することもあるが、コラボレーションによってそれを解決していく ▪ DevOpsを支える柱 ◦ 文化 ◦ ベストプラクティス ◦ ツール ▪ システム運用の取り組みポイント ◦ 評価指標や現在の業務から対応できそうな部分から検討する ▪ リカバリ方法、開発への情報共有、技術トレンドに対する過去ナレッジの適用可能性 ▪ OSS脆弱性対応のような、開発に関する情報を運用業務に用いる
29. ▪ DevOps ＝ 「顧客に価値を素早く届けるため、開発・運用が協力する文化的な姿勢・取り組み」 ◦ 開発〜運用に流れるプロセスで、ボトルネックになっているや改善できる部分はないか ◦ 運用側でも作業負荷が高く、効率化できることはないか ◦ 開発側がどのような方法で品質を高める活動をやっているか ◦ 運用側で引き継いだ時に開発側と同様の品質を高める活動は何ができるか ◦ 運用側で課題になっていることを開発側で解決できないか まずは「現状理解」と「開発側の理解」から 29 開発 運用 現状を理解し、課題を整理する 開発側がどんな開発をしているか理解し、 運用で取り入れたり、改善要望を共有する できることから始め、仲間を増やして継続的に改善していけるような取り組みをぜひ始めてみましょう！
30. よしQ会議 #02 のお知らせ 30 参加申込はこちらから：https://jfrog.connpass.com/event/269178/
31. 31 Thank you
32. 32 Q & A
33. 参考文献 33 • John Allspaw & Paul Hammond: 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr (Velocity 2009) https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr • JFrog: DevOpsとは https://jfrog.com/ja/devops-tools/what-is-devops/ • DevOps Research and Assessment(DORA): Accelerate State of DevOps Report https://cloud.google.com/devops/state-of-devops/ • Google Cloud: 2022年のAccelerate State of DevOps Reportを発表: セキュリティに焦点 https://cloud.google.com/blog/ja/products/devops-sre/dora-2022-accelerate-state-of-devops-report-now-out • • •