継続的な改善 - パターン

Well-Architected Operational Excellence (適切に設計された運用性) → 継続的改善の詳細

パターン

参照すべき場所外観
プラットフォーム | DORA✅ 導入頻度が追跡されます。最も変化の早いチームはオンデマンドで導入し、多くの場合は1日に複数回導入します。
プラットフォーム | DORA✅ 変更のリードタイムはコードコミットから本番リリースまでを測定します。サブ日のリードタイムは高パフォーマンスの配送を示し、サブ時間は卓越した能力を示します。
プラットフォーム | DORA✅ 変更失敗率は、修正が必要な本番インシデントの原因となったリリースの割合として追跡され、一貫して低く維持されます。
プラットフォーム | DORA✅ 失敗したリリースのリカバリ時間が測定されます。1 時間以内のリカバリは配信の成熟度を示します。
プラットフォーム | DORA✅ リリースのやり直し率は、本番インシデントに起因する計画外のリリースの比率として追跡されます。
プラットフォーム | DORA✅ 総計値はスループット (リードタイム、リリース頻度、リリース失敗回復時間) 要素と不安定性 (変更失敗率、再作業率) 要素に整理されます。
プラットフォーム | 評価指標✅ DORA 評価指標は継続的に測定され、経時的なトレンドが示され、絶対値よりも改善軌道が優先されます。
プラットフォーム | ダッシュボード✅ 評価指標は、組織全体に表示される運用ダッシュボードで追跡されるため、運用パフォーマンスに関する透明性が確保されます。

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | DORA⚠️ リリース頻度が低いと、チームが避けるリリースの問題点が反映され、リリース頻度が低いと各リリースのリスクが高まるという悪循環が発生する
プラットフォーム | DORA⚠️ 長いリードタイムは、過剰なプロセスオーバーヘッド、不十分な自動化、組織の機能不全を反映します。
プラットフォーム | DORA⚠️ 変更の失敗率が高いのは、テストが不十分であるか、リリースの検証が不十分であるか、適切な品質チェックが行われずに変更が急がれていることを反映する
プラットフォーム | DORA⚠️ リカバリ時間が長いのは、リリースの検証が不十分、自動ロールバックがない、本番インシデントの所有権が不明瞭であることを反映する
プラットフォーム | DORA⚠️ 高い再作業率は、緊急リリース、本番前テスト、リリース検証、または変更管理のギャップを示す本番インシデントが頻繁に発生することを示します。
プラットフォーム | 評価指標⚠️ 総計値は経時的なトレンドではなく、ある時点のスナップショットとして取得され、運用パフォーマンスが向上しているか低下しているかが非表示

パターン

参照すべき場所外観
プラットフォーム | プロセス✅ スプリントの振り返りが定期的 (毎スプリントまたは毎月) に行われ、危機を待つのではなく、反省のリズムが創出される
プラットフォーム | プロセス✅ 振り返りでは、参加とアクション可能な結果を促進する構造化された形式 (開始/停止/続行、マッド/サド/グラッド、タイムライン) を使用します。
プラットフォーム | プロセス✅ ファシリテーターがローテーションされ、1人の担当者がディスカッションを独占できない
プラットフォーム | プロセス✅ 遡及的インサイトは所有者と完了日を含む具体的なアクション項目に変換され、セッションあたりの改善数が少ない
プラットフォーム | プロセス✅ アクション項目の完了が遡及的に追跡され、チームがフォローアップの責任を負う
プラットフォーム | 運用✅ 運用レビューでは、四半期または月次で運用状況の集計を評価し、トレンドデータを調べて目的と比較します。
プラットフォーム | 運用✅ 業務レビューでは、機能開発に対抗できる業務改善作業のリソースを確保するためのリーダーシップを発揮
プラットフォーム | 運用✅ レビューには、ジャーニー別の目標に対する対応可能状況、パーセント別の遅延トレンド、重大度別のインシデント数 (検出と解決までの平均時間)、リリース頻度と成功率、オンコールページや待機時間などの運用負荷などの運用指標が含まれます。

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | プロセス⚠️ 遡及は規則的なリズムで起こるのではなく、危機を待つ
プラットフォーム | プロセス⚠️ 回顧展は長い議論を生むが、行動は起こらず、時間を浪費し、皮肉を育む
プラットフォーム | プロセス⚠️ アクション項目は所有者や完了日なしで定義されているため、改善が議論されますが、実装されることはありません。
プラットフォーム | プロセス⚠️ アクション項目の完了は遡及的に追跡されず、フォローアップは不明のままです。
プラットフォーム | 運用⚠️ オペレーションは、危機発生時のみ注意を引く目に見えないバックグラウンド作業として扱われ、定期的なオペレーションレビューは行われません。
プラットフォーム | 運用⚠️ 運用レビューではリーダーシップが欠けているため、リソースが割り当てられると機能開発で改善作業が失われる

パターン

参照すべき場所外観
プラットフォーム | 運用✅ 運用準備状況レビューでは、本番稼働開始前に新機能またはシステムが運用要件を満たしているかどうかを評価します。
プラットフォーム | 運用✅ 新しいソリューション、主要な機能、または運用上の影響を含むアーキテクチャの変更を本番環境で開始する前にレビューを実施します。
プラットフォーム | 運用✅ 実装が完了しているため、対応が遅すぎる運用上の懸念事項がなく、評価できるバランスの取れたレビュータイミング
プラットフォーム | 監視✅ レビューでは、十分な評価指標が測定され、障害シナリオのアラートが存在し、ダッシュボードに健全性の状況が表示されていることを確認します。
プラットフォーム | ドキュメント✅ このレビューでは、一般的な業務にランブックが存在し、アーキテクチャが回答者向けに文書化され、エスカレーション手順が明確であることを確認します。
プラットフォーム | リリース✅レビューでは、リリースが確実に実行され、ロールバック手順が存在し、ステージングでリリースが検証されていることを確認します。
プラットフォーム | パフォーマンス✅ このレビューでは、現実的な負荷でパフォーマンス目標が検証され、成長の余地があり、ガバナ制限のリスクが評価されることを確認します。
プラットフォーム | セキュリティ✅ レビューでは、セキュリティレビューが完了していること、監査要件を満たしていること、アクセス制御が要件を満たしていることを確認します。
プラットフォーム | 連動関係✅ このレビューでは、外部連動関係が特定されていること、インテグレーションパートナーにサービスレベル契約があること、連動関係の障害に対するフォールバック動作が存在することを確認します。
プラットフォーム | ガバナンス✅ 本番稼働開始はレビュー完了時にゲートされるため、運用上の懸念事項はベスト エフォートではなく導入要件になります。

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | ガバナンス⚠️ 新機能の運用準備状況評価なしで本番稼働が開始され、運用負債が蓄積され、将来の運用の卓越性がますます困難になる
プラットフォーム | 運用⚠️ レビューの実施が遅すぎるため、運用上の懸念がリリースを阻害し、修正をスキップするプレッシャーが生じる
プラットフォーム | ガバナンス⚠️ 運用準備状況は、リリース要件ではなく、ベストエフォート型として処理されます。

パターン

参照すべき場所外観
プラットフォーム | 文化✅ 心理的安全性により、問題、ミス、ヒヤリハットについて、罰を恐れずに正直に話し合うことができる
プラットフォーム | 文化✅ 心理的安全性は、責任のない死後に構築され、問題の発見を祝福し、自分の誤りについて話し合うことでリーダーシップのモデル化の脆弱性を祝福します。
プラットフォーム | 評価指標✅ メジャメントにより、業務評価指標、インシデントトレンド、DORAインジケーター、ユーザー満足度スコアで業務状態を可視化し、改善作業を客観的に優先順位付け
プラットフォーム | 運用✅ エンジニアリング能力は、業務改善、技術的負債の削減、ツーリングおよび自動化への投資のために意図的に確保されています。
プラットフォーム | 運用✅ フィードバックループは運用環境を設計上の意思決定に結び付け、インシデントはアーキテクチャの改善を促進し、監視は最適化を促進し、リリースの失敗はテストカバー率の向上を促進します。

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | 文化⚠️ 心理的安全性の欠如しているチームは、破滅的になるまで問題を隠蔽し、早期介入を妨げる
プラットフォーム | 運用⚠️ チームは業務改善のための時間がない機能にすべての業務量を費やし、技術的および業務的な負債を蓄積して最終的に危機対応を迫られる
プラットフォーム | 運用⚠️ 運用経験が設計にフィードバックされないため、同じ弱点が再発し、運用が改善されるどころか徐々に低下する