DevOps カルチャを育むための推奨事項

Azure Well-Architected フレームワークのオペレーショナル エクセレンスに関するチェックリストの次の推奨事項を対象とします。

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

主要な設計戦略

Well-Architected フレームワークの推奨プラクティスに従って運用されるワークロードは、結束、責任、継続的な学習、改善という DevOps カルチャの導入から始まります。 チーム メンバーはそれぞれの専門知識を持ち寄り、ワークロード運用の特定の領域に重点を置くことができます。 ただし、チーム全体として、必要に応じて外部チームからのサポートを受けながら、日常のタスク、必要に応じたタスク、および緊急のタスクを独自に管理できる必要があります。 チームは組織全体の要件の範囲内で作業し、知識の共有を重視する考え方を用いて他のチームと協力しなければなりません。

次の推奨事項は、チームに DevOps プラクティスを導入および実装して、ワークロードの運用を最適化し、組織に価値を付加するのに役立ちます。

相互尊重を促進する

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

相互尊重は、非難のない文化を促進します。 問題が発生した場合、ワークロード チームは、責任を負わせてチームの結束力に影響を与えるのではなく、共同で所有権を持ち、改善する方法を見出すべきです。

明確な役割と責任を確立する

チームは、自分たちの作業に価値を見出すことで、ワークロードに対して所有権と責任を持つようになります。 ワークロード チームは最終的に、ワークロードの運用に対してエンド ツー エンドの責任を負います。 ワークロード運用の特定の側面に外部サービスが必要になる場合もありますが、チームは他のチームと協力し、すべての機能が正常に完了することを保証する責任があります。 サービスのサポートにどの程度関与しているかにかかわらず、ワークロード チーム のメンバーは、ワークロードをサポートするすべての機能を自分の責任と考えなければなりません。 この考え方は、所有権に対する共通意識を強化するのに役立ちます。

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

継続的な学習に取り組む

ワークロード チームの利点を生かすためにイネーブルメント チームを活用します。 一部の組織には、プラットフォーム チーム、アーキテクチャ レビュー ボード、クラウド センター オブ エクセレンスなどのイネーブルメント チームがあります。 これらのチームは、設計とプロセスの一貫性を確保するために、すべてのワークロード チームが従う必要がある標準を提供します。 ワークロード チームは、イネーブルメント チームとオープンなコミュニケーションをとり、協力してプロセスを改善し、知識を共有できるようにします。 オープンなコミュニケーションを通じて、チームの継続的な学習と改善のマインドセットをサポートします。

互いに学び合い、部門を超えたチームを育成します。 メンバー全員が自分の部門のスペシャリストであり、他のすべての部門のジェネラリストとなるようにチーム構造を確立し、チーム メンバーが必要に応じて互いをサポートできるようにします。 部門横断的にすることは、チーム メンバーが互いの専門知識を認め合い、ワークロード全体の複雑さを理解するのに役立ちます。

継続的な最適化に注力する

ビジネス、規制、その他の要件を理解し、それらをプラクティスに統合します。 ワークロード チームは他のことと無関係に活動するわけではありません。 チームは、活動するビジネス、業界、および地理的リージョンによって適用される要件に従います。 ワークロード チームのメンバーが、従うべき要件と、それらの要件を満たさない場合に生じる結果を理解していることを確認してください。

必要な機能を明確に対象としたテスト メカニズムを統合することによって、要件に確実に準拠できるようにプラクティスを積極的に適応させます。 組織によっては、ワークロードに対してある程度のガバナンスが課される場合があります。 ビジネスで標準化されている要件をガードレールとして使用して、適切に運用されていることを確認します。

チームと標準運用手順を定期的にレビューして、改善点に関する議論を促進します。 ワークロードのライフサイクル全体を通じて、すべての標準運用手順を継続的にレビューして改善する必要があるという哲学を育むことで、現状に満足することを避け、革新的な思考を奨励します。 チーム メンバーがいつでも改善に関する意見を述べられる雰囲気がある必要があります。 ただし、一緒に手順をレビューする時間を確保して、全員が改善すべき領域について考え、各自のアイデアについて集中的に議論できるようにしてください。

安全な実験を受け入れます。 チーム メンバーに対してサンドボックス環境へのアクセスを許可し、実験のための時間をスプリントに組み込むようにします。 チーム メンバーが具体的なメリットをもたらす機能またはコンポーネントを発見したときに、新しい機能をワークロードに統合する方法を定義する標準を文書化します。 新しい機能が安全なデプロイ プラクティスに沿ったものであることを確認してください。

考慮事項

役割と責任を厳密に定義すると、一部のチーム メンバーは自分の責任範囲外の機能を実行するときに、不快感を感じる可能性があります。 チームの構造についてチームとオープンで率直な話し合いを行い、必要に応じ調整を行ってください。

Azure ファシリテーション

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

関連リンク

• DevOps リソース センター
• 安全なデプロイ プラクティス

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

レコメンデーションの完全なセットを参照してください。