# DORA ## 定義 DORA (DevOps Research and Assessment) は、ソフトウェアデリバリーとオペレーション能力のパフォーマンスを計測するための研究プログラムおよびフレームワークである。[[Nicole Forsgren]] らが 2014 年に創設し、毎年の「State of DevOps Report」でソフトウェアデリバリーのパフォーマンスと組織成果の相関を定量的に研究してきた。 ### 4 つのコアメトリクス 1. **Deployment Frequency(デプロイ頻度)**: どれだけ頻繁に本番へリリースするか。 2. **Lead Time for Changes(変更のリードタイム)**: コードのコミットから本番稼働・安定化までの時間。 3. **Change Failure Rate(変更失敗率)**: 本番に適用された変更のうちインシデントを引き起こす割合。 4. **Mean Time to Restore(MTTR)**: サービス障害からの回復時間。 ### SRE 文脈での適用(Forsgren 2026) [[Nicole Forsgren]] は SREcon26 で DORA を「SRE 自身のパイプラインの計測」として内側向きに適用することを提案した: - **Deployment Frequency**: SRE チームが変更イベントに対応する頻度——オペレーションテンポのベースライン。 - **Lead Time for Changes**: 変更マージから安定稼働まで——パイプライン速度はリスク入力となる。 - **Change Failure Rate**: 変更の何%がインシデントを引き起こすか——摩擦誘発エラーのシグナル。 - **MTTR**: ヘッドラインの出力指標だが、**摩擦はその上流の入力**である。 ## 横断的知見 - **DORA は開発者向けだけでなく SRE 自身にも適用できる**: Forsgren 2026 は、DORA が「SRE が支援する開発チームだけでなく SRE チーム自身の計測フレームワーク」であると主張する。SRE のツール・プロセスは DORA の変更失敗率と MTTR を直接悪化させる上流因子として捉えられる。(Source: [[@2026__SREcon26 Americas__The WTF Problem - Developer Experience as a Reliability Property]]) ## 未解決の問い - SRE チームが DORA を内側向きに適用するとき、「変更(change)」の定義は何か——コードリリースか、設定変更か、ランブック更新か。 - AI 支援開発によってデプロイ頻度が増加する場合、変更失敗率は指数的に増えるのか、それとも AI が生成コードの品質を高めて相殺するのか。 - DORA のエリート/高/中/低の 4 段階分類は SRE チームのオペレーション能力の分類にどう翻案できるか。 ## 関連 - フレームワーク: [[SPACE]] / [[MTWTF]] - 提案者: [[Nicole Forsgren]] - SRE 概念: [[SRE]] / [[インシデント管理]] / [[エラーバジェット]] - 関連 MOC: [[structures/SRE - MOC]] ## 出典 - [[@2026__SREcon26 Americas__The WTF Problem - Developer Experience as a Reliability Property]] — p.18 で DORA 4 指標を SRE 文脈で再解釈