DevOps の考慮事項
この記事では、Azure ランディング ゾーンの DevOps に関する考慮事項と推奨事項について説明します。
DevOps とは
DevOps とは、開発 (dev) と操作 (ops) に継続的な価値を提供する人、プロセス、テクノロジの結合です。 DevOps アプローチでは、組織が効率的かつ大規模に運用できるように、反復可能なプロセスを作成するチームのコラボレーションが奨励されます。
Azure ランディング ゾーンのコンテキストにおいて、DevOps は次のような領域で Azure ランディング ゾーンのライフサイクル管理全体を担当するチームをガイドするフレームワークになります。
- 自律性とガバナンスの適切なバランスを実現するために、他のチームとの境界を自己整理して定義する方法
- Azure ランディング ゾーンアーキテクチャの設計を継続的に進化させる方法 (コンウェイの法則)
- 設計されたアーキテクチャの実装を計画、優先度付け、反復する方法
- Azure ランディング ゾーン コードのバージョン コントロール、継続的インテグレーションと継続的デプロイを実装する方法
- 所有しているシステムとプラットフォームのインシデントを操作および対応する方法
- Azure ランディング ゾーンのプロビジョニングと自己復旧に適用する自動化のレベル
- アジャイルで結果指向の方法で組織内の他のチームと共同作業する方法
- セキュリティ、品質、ユーザー中心主義、継続的な学習の生成文化を創造する方法
クラウド運用モデルをレビューする際に行う決定は、DevOps フレームワークの使用方法に影響を与える場合があります。
DevOps の設計に関する考慮事項
DevOps フレームワークを定義するか、組織の DevOps とクラウド導入戦略に合わせます。 DevOps の定義と、チームが従う必要がある原則とプラクティスを含めます。 DevOps 戦略をビジネス戦略に結び付ける必要があります。
チームが自身の DevOps のパフォーマンスを向上させることができるメトリックを確立します。 高パフォーマンスのチームは、仮説を使用して自身のアイデアをテストし、それを測定して仮説がどのように機能するかを確認し、必要に応じて変更を加えます。 DevOps の最終的な意図は、デプロイの頻度、変更を適用する平均時間、低下したサービスを復元する時間などの側面を改善することです。 最終的に全体的なビジネス パフォーマンスに影響を与えるように、これらすべてのメトリックを設計する必要があります。
チームが現在のスキルに基づいて最初に実装する必要がある DevOps プラクティスを決定し、チームが DevOps メトリックを改善するのに役立つ新しいプラクティスを段階的に適用するためのロードマップを設計します。 エンジニアリング機能とリソースへの投資が不可欠です。
チームが DevOps プラクティスの実装に使用する必要がある DevOps ツールチェーンを決定します。 異なる種類の DevOps エコシステムによって Azure ランディング ゾーンまたはワークロード デプロイの複雑さが増すシナリオを回避するために、ツールが全体的な DevOps 戦略と一致していることを確認します。
実装した DevOps プラクティスと DevOps ツールが Azure ランディング ゾーンの設計に与える影響を評価します。
チームのスキルを継続的に成長させる準備計画を作成します。 DevOps モデルの包括的アプリケーションでは、機能する DevOps チームはすぐには確立されません。
組織の DevOps 戦略とクラウド運用モデルに最適なチーム トポロジを決定し、チーム間の明確な境界、責任、依存関係を確立します。
Azure ランディング ゾーンを担当するチームが組織内の他のチームと協力して、設計と実装の更新、インシデントの解決、依存関係の最小化、ビジネスの優先順位との整合を図るための新しい Azure ランディング ゾーン要件をキャプチャする方法を決定します。
DevOps の推奨事項
以降のセクションには、組織内で DevOps フレームワークを実装するのに役立つ推奨事項が含まれています。
DevOps フレームワークを定義する
DevOps フレームワークを確立するには、既に使用可能なフレームワークを使用して、定義済みの一連の実証済みプラクティスから始めることを検討してください。
Microsoft DevOps Resource Center には、次のような Azure ランディング ゾーンのライフサイクル管理に適応できる豊富な定義、プラクティス、機能が用意されています。
Microsoft DevOps Dojo は、4 つの基本的な柱と 8 つの機能に基づいて構築された DevOps 分類を確立します。
Azure ランディング ゾーン管理の DevOps プラクティスを定義する
Azure ランディング ゾーンに関する次の DevOps プラクティスを検討してください。
- Azure ランディング ゾーンの開発ライフサイクルをコードとして管理する方法を確認します。
- DevOps 領域の Azure ランディング ゾーンのセキュリティに関する考慮事項を確認します。
DevOps 実装体験を計画する
DevOps 実装体験を定義し、組織のクラウド導入計画に合わせます。
- 次の領域でチームの現在地を特定します。
- 組織のクラウド導入計画を使用して、チームに必要なモデルを定義します。
- 組織のトランスフォーメーションのタイムラインに合わせて反復的および増分モードで目的のモデルを実装するための反復的なロードマップを確立します。
必要な DevOps メトリックを実装する
チームの DevOps パフォーマンスを測定するために使用するメトリックを特定します。 メトリックを使用して、ビジネス成果に結び付くチームの望ましい習慣を促進します。 チームがアクティビティに対する影響を測定できるようにメトリックを確立します。 透明性によって信頼が促進され、組織の目標との整合性が促進されるため、主要なメトリックが全員に表示されるようにします。
ビジネスへの影響を改善するために DevOps のパフォーマンスを測定するメトリックの例には、次のものがあります。
ビジネス成果:
- 目標と主要な結果をツールとして使用して、チームを "アウトプット" の考え方から離れ、"成果" の考え方に移行させます。 たとえば、Azure にデプロイされたポリシーの数よりもコンプライアンス評価を向上させたワークロードの数を使用できます。
- 顧客またはエンド ユーザーの満足度。 例としては、ネット プロモーター スコア (NPS)、アンケート、インタビューなどがあります。
- ビジネスの成長。 例としては、収益性の向上、収益の増加、新しい収益源の取得などがあります。
- 人のメトリック。 例としては、Employee Net Promoter Score (eNPS)、利用率、リテンション期間、満足度などがあります。
- コスト。 たとえば、コストの削減を使用できます。
ソフトウェア配信のパフォーマンス:
- 変更のリードタイム: バグ修正、新機能、または他の変更が、アイデアから開発を経て、運用環境に配置されるまでにかかる時間。
- デプロイの頻度: 運用環境に対するコード変更の 1 日あたりのデプロイ。
- 平均復元時間: インシデントが発生した後に運用環境でサービスを復元するのにかかる時間。
- 変更の失敗率: 失敗につながる運用環境に対する変更 (構成の変更など) の割合。
品質:
- 欠陥のエスケープ率: エンド ユーザーによって識別された欠陥の数。
- 計画外の作業または再作業: 計画外の作業または再作業に費やされた時間の割合。
- アクティブなバグ: まだ修正されていないバグの数。
- コードの正常性: 単体テストが行われていないコードの割合。
DevOps テクノロジ エコシステムを定義する
Azure ランディング ゾーンのライフサイクルを管理するために選択した DevOps ツールチェーンは、次に影響します。
- DevOps の原則とプラクティスを実装するための戦略
- DevOps ライフサイクルのセキュリティに関する考慮事項
- Azure ランディング ゾーンのライフサイクル管理の全体的なアーキテクチャ設計
前に定義した DevOps フレームワークを使用して、各 DevOps プロセスに使用するツールを特定します。 チームのニーズに最も適した DevOps テクノロジを選択しますが、組織全体で標準化を実現しながら、DevOps エコシステムの複雑さや異種性を回避できるバランスを見つけます。
さまざまな DevOps ステージにわたる DevOps テクノロジの例を次に示します。
- 計画: Atlassian Jira、Atlassian Trello、Azure Boards、GitHub
- 継続的インテグレーション (CI) とテスト: Atlassian Bitbucket、Azure Repos、GitHub Repos、npm、NuGet、Selenium、SmartBear Cucumber、SonarSource SonarQube、Zed Attack Proxy
- 継続的デリバリー (CD): Atlassian Bamboo、Azure Pipelines、GitHub Actions、Jenkins、Octopus Deploy、Perforce Puppet、RedHat Ansible
- コードとしてのインフラストラクチャ: Bicep、Pulumi、Terraform
- ブートストラップ: ArgoCD GitOps、Flux GitOps、Progress Chef、PowerShell Desired State Configuration (DSC)
- 操作: Azure Automation、Azure Monitor、CISCO Splunk、Grafana、Microsoft Power BI
- コラボレーションとフィードバック: Atlassian Confluence、Azure DevOps Wikis、GitHub Discussions、GitHub Wikis、Microsoft Teams、Slack、Stack Overflow
次の図は、Azure DevOps ツールチェーンを選択した DevOps フレームワークの例を示しています。
次の図は、Azure DevOps と GitHub ツールチェーンを選択した DevOps フレームワークの例を示しています。
次のステップ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示