DevOps カルチャを促進するための推奨事項

この Azure Well-Architected Framework オペレーショナル エクセレンスチェックリストの推奨事項に適用されます。

OE:01 ワークロード チーム メンバーの特殊化を決定し、ワークロードを設計、開発、デプロイ、運用するための堅牢な一連のプラクティスに統合して、仕様に合わせます。 チーム メンバーは、意思決定と責任を明確にし、継続的な改善と最適化を評価し、継続的な学習を組み込む責任のないカルチャを採用する必要があります。

このガイドでは、ワークロードに DevOps の原則とプラクティスを実装するための推奨事項について説明します。 DevOps カルチャを育てることは、共有所有権、相互尊重、およびワークロード チームの高品質な作業に対する感謝の基盤を構築するのに役立ちます。 Devops カルチャは、高パフォーマンスのチームが存在するシステムで成功するためのテンプレートを提供します。

主要な設計戦略

Well-Architected Framework の推奨プラクティスに従って動作するワークロードは、まとまり、責任、継続的な学習、改善という DevOps カルチャの導入から始まります。 チーム メンバーは独自の専門知識を持ち、ワークロード操作の特定の領域に焦点を当てる場合があります。 ただし、チーム全体は、必要に応じて外部チームからのサポートを受けて、日常的なタスク、必要に応じて緊急タスクを個別に管理できる必要があります。 チームは、全体的な組織要件内で作業し、共有された知識を評価する考え方を使用して他のチームと共同作業する必要があります。

次の推奨事項は、ワークロードの運用を最適化し、organizationに価値を追加するために、チームで DevOps プラクティスを採用して実装するのに役立ちます。

相互尊重を促進する

チームは、相互尊重に基づいて倫理規定を使用して運用する必要があります。 チームの全員が、チームに価値をもたらす専門知識を持っています。 個々の能力をチーム文化の中核的な理念として認識することで、安全な場所から会話を開始できます。 個人は、ワークロードの運用に関する正直な意見を提供し、敬意を持って扱うことができると感じる必要があります。

互いに敬意を払うことで、非難のない文化が育まれます。 問題が発生した場合、ワークロード チームは、責任を割り当ててチームのまとまりに影響を与えるのではなく、共同作業の所有権を取得し、改善する方法を見つける必要があります。

チームのロールと責任

チームは、作業を大切にするときに、ワークロードの所有権と責任を負います。 ワークロード チームは最終的に、ワークロードの運用に対してエンドツーエンドの責任を負います。 ワークロード操作の特定の側面には外部サービスが必要な場合もありますが、チームは他のチームと共同作業を行い、すべての機能が正常に完了したことを確認する責任があります。 ワークロード チーム のメンバーは、サービスのサポートにどれだけ関与しているかに関係なく、ワークロードをサポートするすべての機能を自分の責任と見なす必要があります。 この考え方は、所有権の常識を強化するのに役立ちます。

チームの役割と意思決定の責任を明確に定義します。 チームの意思決定は可能な限り民主的である必要がありますが、意思決定が効率的に行われるように構造化する必要があります。 状況に関して異なる意見がある場合は、提示された証拠に基づいて最終的な決定を下す責任を誰かが負う必要があります。 チームの決定はワークロード全体に影響を与える可能性があるため、最終的な決定に同意しない場合でも、意思決定プロセス全体を通じて、個人が聞き取りと評価を受けることは重要です。

継続的な学習と改善

ワークロード チームの利点に対して有効化チームを使用します。 一部の組織には、プラットフォーム チーム、アーキテクチャ レビュー ボード、クラウド センター オブ エクセレンスなどの有効化チームがあります。 これらのチームは、設計とプロセスの一貫性を確保するために、すべてのワークロード チームが従う必要がある標準を提供します。 ワークロード チームが有効化チームとオープンなコミュニケーションを取り、プロセスを改善し、知識を共有するために共同作業を行えるようにします。 オープンコミュニケーションを通じて、チームの継続的な学習と改善の考え方をサポートします。

相互に学習して、部門間のチームを開発します。 チーム メンバーが必要に応じて互いにサポートし合えるように、すべてのユーザーが自分の機能の専門家であり、他のすべての機能のジェネライナリストであるチーム構造を確立します。 クロス機能は、チーム メンバーが互いの専門知識に対する評価を深めるのに役立ち、ワークロード全体の複雑さを理解するのに役立ちます。

最適化へのコミットメント

ビジネス、規制、その他の要件を理解し、それらをプラクティスに統合します。 ワークロード チームは、バキュームで動作しません。 チームは、お客様が事業を行うビジネス、業界、および地理的リージョンによって適用される要件の対象となります。 ワークロード チーム のメンバーが、従う必要がある要件と、それらの要件を満たさなくて失敗した結果を理解していることを確認します。

特に必要な機能をターゲットとするテスト メカニズムを統合することで、要件に準拠するようにプラクティスを事前に調整します。 organizationは、ワークロードに対してある程度のガバナンスを課す可能性があります。 ビジネスがガードレールとして標準化する要件を使用して、適切に運用していることを確認します。

チームと標準の運用手順を定期的に確認して、改善の領域に関するディスカッションを促進します。 すべての標準的な運用手順をワークロード ライフサイクル全体にわたって継続的に見直し、改善する必要があるという理念を育てることで、自己満足を避け、革新的な思考を促進します。 チーム メンバーは、いつでも改善について意見を出す権限を与えられていると感じる必要があります。 ただし、全員が改善の領域について考え、自分のアイデアに焦点を当てた議論を行うスペースが確保されるように、手順を一緒にレビューする時間を確保してください。

安全な実験を受け入れる。 チーム メンバーにサンドボックス環境へのアクセス権を付与し、実験を可能にするためにスプリントに時間が組み込まれるようにします。 チーム メンバーが具体的な利点を提供する関数またはコンポーネントを検出したときに、新しい機能をワークロードに統合する方法を定義するドキュメント標準。 新しい機能が 安全なデプロイプラクティスと一致するように注意してください。

考慮事項

ロールと責任を厳密に定義すると、一部のチーム メンバーが責任を負わない機能を実行しているときに、一部のチーム メンバーに不快感を与える可能性があります。 チームの構造についてチームとオープンで正直な話し合いを行い、必要に応じて調整を行うことができます。

Azure ファシリテーション

Microsoft は、専用の DevOps リソース センターで DevOps カルチャに関する広範なドキュメントを公開しています。

オペレーショナル エクセレンスチェックリスト

推奨事項の完全なセットを参照してください。