[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -2,145 +2,183 @@
|
||||
id: wiki-2026-0508-dora-metrics
|
||||
title: DORA Metrics
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [dora, four-keys, accelerate-metrics]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-consolidated, technical-documentation]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [dora, devops, metrics, delivery-performance]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: sql
|
||||
framework: github-actions/grafana
|
||||
---
|
||||
|
||||
# [[DORA Metrics (소프트웨어 전달 성과 지표)|DORA Metrics (소프트웨어 전달 성과 지표]]
|
||||
# DORA Metrics
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
DORA(DevOps Research and Assessment) 지표는 소프트웨어 개발 조직의 전달(Delivery) 성능과 운영 효율성을 측정하는 글로벌 표준 기준입니다 [1]. 코드 리뷰의 속도와 효율성은 DORA 지표에 직결되며, 빠른 리뷰 주기를 유지하는 엘리트(Elite) 팀은 그렇지 않은 팀보다 50% 더 높은 딜리버리 성과를 보입니다 [2]. DORA 지표는 배포 빈도, 변경 리드 타임, 서비스 복구 시간, 변경 실패율의 4가지 핵심 지표를 통해 조직의 역량을 객관적으로 진단합니다 [3].
|
||||
## 매 한 줄
|
||||
> **"매 software delivery performance 의 매 4 numbers"**: deployment frequency, lead time for changes, change failure rate, mean time to restore (MTTR). 매 Forsgren/Humble/Kim "Accelerate" (2018) + 매 yearly DORA report 가 매 source-of-truth. 2026 의 매 5번째 metric (reliability) 의 official.
|
||||
|
||||
---
|
||||
## 매 핵심
|
||||
|
||||
> "엘리트 개발 팀의 성적표: 단순히 '얼마나 많이 만드는가'가 아니라, '얼마나 빠르고 안전하게 사용자에게 가치를 전달하는가'를 4가지 핵심 숫자로 입증하여 조직의 생산성 격차를 시각화하는 강력한 리트머스 시험지."
|
||||
### 매 the 4 (now 5)
|
||||
1. **Deployment Frequency (DF)** — production deploys per period. Elite: on-demand (multiple/day).
|
||||
2. **Lead Time for Changes (LT)** — commit → production. Elite: < 1 day.
|
||||
3. **Change Failure Rate (CFR)** — % deploys causing incident/rollback. Elite: 0–5%.
|
||||
4. **Mean Time to Restore (MTTR)** — incident detection → resolution. Elite: < 1 hour.
|
||||
5. **Reliability** (added 2021/2022 reports) — meeting/exceeding SLO targets.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **4대 핵심 지표 (Four Key Metrics):**
|
||||
1. **배포 빈도 (Deployment Frequency):** 코드가 프로덕션에 얼마나 자주 배포되는가? (엘리트 팀: 하루에 수회 이상) [3]
|
||||
2. **변경 리드 타임 (Lead Time for Changes):** 코드가 커밋된 후 프로덕션에 배포되기까지 걸리는 시간 (엘리트 팀: 1시간 미만) [3]
|
||||
3. **서비스 복구 시간 (Time to Restore Service):** 장애 발생 시 서비스가 복구되는 데 걸리는 시간 (엘리트 팀: 1시간 미만) [3]
|
||||
4. **변경 실패율 (Change Failure Rate):** 배포 후 장애나 수정이 필요한 비율 (엘리트 팀: 0~15%) [3]
|
||||
* **코드 리뷰 속도와의 상관관계:** 코드 리뷰 처리 속도는 소프트웨어 전달 성과를 결정짓는 핵심 요인입니다 [2]. 리뷰가 지연되면 리드 타임이 길어지고 병목이 발생하여 전체 생산성이 저하됩니다.
|
||||
* **엘리트 성과자(Elite Performers)의 실천 기준:**
|
||||
* **풀 리퀘스트(PR) 크기:** 인지 부하를 줄이기 위해 모든 PR을 400줄(LOC) 이하로 유지함 [3, 5].
|
||||
* **첫 리뷰 시간:** PR 생성 후 1시간 이내에 첫 리뷰가 수행됨 [5].
|
||||
* **리뷰 완료 시간:** 6시간 이내에 전체 리뷰 및 승인이 완료됨 [3, 5].
|
||||
* **품질 게이트 통합:** 코드 리뷰 체크리스트에 변경 사항이 배포 파이프라인이나 DORA 지표 측정에 미치는 영향을 점검하는 항목을 포함하는 것이 권장됩니다 [1].
|
||||
### 매 performance bands (2024 report)
|
||||
- **Elite** — frequent deploys, < 1 day LT, 0–5% CFR, < 1h MTTR.
|
||||
- **High** — weekly–monthly, 1 day–1 week, 0–10%, < 1 day.
|
||||
- **Medium** — monthly–6m, 1 week–1 month, 0–15%, < 1 week.
|
||||
- **Low** — < 6m, > 6m, > 64%, > 1 week.
|
||||
|
||||
---
|
||||
### 매 accelerators (capabilities)
|
||||
- Trunk-based development.
|
||||
- Continuous integration.
|
||||
- Test automation.
|
||||
- Loosely coupled architecture.
|
||||
- Generative culture (Westrum).
|
||||
- Database change automation.
|
||||
- Empowered teams.
|
||||
|
||||
DORA Metrics는 Google의 DevOps [[Research|Research]] and [[Assessment|Assessment]](DORA) 팀이 수천 개의 기업을 조사하여 정립한 소프트웨어 개발 및 배포 성과 측정 지표입니다.
|
||||
## 💻 패턴
|
||||
|
||||
1. **4대 핵심 지표**:
|
||||
* **Deployment Frequency (배포 빈도)**: 제품을 얼마나 자주 배포하는가? (속도)
|
||||
* **Lead Time for Changes (변경 리드 타임)**: 코드 커밋부터 배포까지 얼마나 걸리는가? (효율)
|
||||
* **Change Failure Rate (변경 실패율)**: 배포 실패로 인해 장애가 발생할 확률. (신뢰성)
|
||||
* **Failed Service Restoration Time (복구 소요 시간)**: 장애 발생 시 복구까지 걸리는 시간. (복구력)
|
||||
2. **왜 중요한가?**:
|
||||
* 속도와 안정성을 상충 관계(Trade-off)가 아닌, 상호 보완 관계로 정의하여 '엘리트 그룹'으로 가기 위한 정량적 목표 정책을 제시하기 때문임. ([[Efficiency|Efficiency]]와 연결)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **속도 vs 철저함:** 엘리트 기준(6시간 이내 완료)을 무리하게 추구할 경우, 코드 리뷰가 피상적으로 흐르거나 보안 결함을 놓칠 위험이 있습니다 [6, 7].
|
||||
* **니트피킹(Nit-picking)의 함정:** 사소한 스타일 교정에 집착하여 리뷰 시간을 지연시키면 리드 타임이 악화됩니다 [8]. 스타일 검사는 자동화 도구에 위임하고, 리뷰어는 아키텍처 및 핵심 로직에 집중하여 속도와 철저함의 균형을 맞춰야 합니다 [10].
|
||||
* **데이터 오염:** 지표 달성 자체에만 매몰되면 개발자가 PR을 인위적으로 쪼개거나 품질을 희생하는 등 수치가 실제 생산성을 대변하지 못하게 될 수 있습니다.
|
||||
|
||||
---
|
||||
|
||||
- **과거 데이터와의 충돌**: 과거에는 단순히 LOC(코드 라인 수)나 커밋 수 정책으로 개발자 성과를 측정했으나, DORA 정책은 '가치 전달의 흐름 정책(Flow)' 중심의 측정 정책이 조직의 성공과 직결됨을 증명함(RL Update).
|
||||
- **정책 변화(RL Update)**: 최근에는 4대 지표 정책에 '안정성 정책' 외에 '운영 효율성 정책'을 시각화하는 5번째 지표(Reliability)를 추가하여 서비스 가용성 정책을 더욱 정밀하게 관리하는 추세임. (Reliability와 연결)
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
* **Review-Speed Benchmarks**: DORA 데이터를 기반으로 리뷰 속도를 엘리트, 우수, 수용 가능 수준으로 구분하여 정량 평가하는 기준입니다.
|
||||
* **Pull Request Size Limits (PR 크기 제한**: 엘리트 등급의 리뷰 속도 달성을 위한 선제 조건으로, 리뷰어의 인지 부하를 최소화합니다.
|
||||
* **Automation in Code Review (코드 리뷰 자동화**: 기계적 검증을 자동화하여 인간 리뷰어가 고차원적 가치 창출(지식 공유 등)에 집중하게 돕습니다.
|
||||
* **Software Delivery Performance**: DORA 지표가 궁극적으로 측정하고자 하는 소프트웨어 전달 역량의 종합적 성과입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 지리적으로 분산된 글로벌 팀이 DORA의 '첫 리뷰 1시간 이내' 기준을 달성하기 위해 비동기 협업 및 알림(Notification) 시스템을 어떻게 최적화해야 하는가?
|
||||
* 리뷰 속도 단축을 위해 SAST와 같은 보안 도구가 CI/CD 파이프라인의 병목이 되지 않도록 스캔 정책을 어떻게 유연하게 설계해야 하는가?
|
||||
* 레거시 시스템 마이그레이션과 같이 PR을 작게 쪼개기 어려운 상황에서 DORA 지표의 속도 벤치마크를 어떻게 합리적으로 조정(Normalization)할 것인가?
|
||||
* DORA 지표 개선이 실제 비즈니스 가치(매출, 고객 만족도 등)로 연결되는 정량적 상관관계를 어떻게 입증할 수 있는가?
|
||||
* 코드 리뷰어 할당 알고리즘을 개선하여 특정 리뷰어에게 쏠리는 병목을 해소하고 팀 전체의 DORA 성과를 균등하게 높이는 방법은 무엇인가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** 모든 PR을 400 LOC 미만으로 분할하여 제출함으로써 리뷰어의 빠른 승인을 유도합니다 [3, 11].
|
||||
* **System Design:** 린팅, 포맷팅, 테스트 단계를 자동화하여 리뷰어가 기계적 결함 검토에 시간을 낭비하지 않도록 파이프라인을 설계합니다.
|
||||
* **Operation / Maintenance:** 주기적으로 '첫 리뷰까지 걸리는 시간'의 75백분위수를 추적하여 팀의 딜리버리 역량을 관리합니다 [13].
|
||||
* **Learning Path:** 신속한 응답 문화를 조성하고, 리뷰 피드백 루프 자체가 주니어 개발자의 성장을 돕는 교육 기회가 되도록 운영합니다.
|
||||
* **My Project Relevance:** 현재 팀의 평균 리드 타임과 배포 빈도 데이터를 추출하여 DORA 벤치마크와 비교 진단하고 병목 구간을 개선합니다.
|
||||
|
||||
### Adjacent Topics
|
||||
* **DevOps Culture**: DORA 지표가 효과를 발휘하기 위해 전제되어야 할 팀의 심리적 안전감과 실험 정신 등 문화적 측면으로 확장됩니다.
|
||||
* **Cycle Time (TTR**: PR 생성부터 병합까지의 전체 주기를 측정하고 관리하는 실무적 지표 체계입니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
---
|
||||
|
||||
- [[Efficiency|Efficiency]], [[Reliability|Reliability]], [[Scalability|Scalability]], Standard-Operating-Procedure, [[Management|Management]], [[Strategic-Planning|Strategic-Planning]]
|
||||
- **Category**: Elite, High, Medium, Low performers.
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
### Lead time SQL (GitHub + production deploy events)
|
||||
```sql
|
||||
-- 매 first commit in PR → production deploy 의 measure
|
||||
WITH deploys AS (
|
||||
SELECT service, deploy_id, deployed_at, sha
|
||||
FROM deployments WHERE environment = 'production'
|
||||
),
|
||||
commits AS (
|
||||
SELECT pr.merge_commit_sha AS sha, MIN(c.committed_at) AS first_commit_at
|
||||
FROM pull_requests pr JOIN commits c ON c.pr_id = pr.id
|
||||
GROUP BY pr.merge_commit_sha
|
||||
)
|
||||
SELECT d.service,
|
||||
PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM d.deployed_at - c.first_commit_at)) AS lt_p50_seconds,
|
||||
PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM d.deployed_at - c.first_commit_at)) AS lt_p95_seconds
|
||||
FROM deploys d JOIN commits c USING (sha)
|
||||
WHERE d.deployed_at > NOW() - INTERVAL '90 days'
|
||||
GROUP BY d.service;
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### GitHub Actions 의 deploy event emit
|
||||
```yaml
|
||||
- name: Record deployment
|
||||
if: success()
|
||||
run: |
|
||||
curl -X POST "$DORA_API/deployments" \
|
||||
-H "Authorization: Bearer $TOKEN" \
|
||||
-d "{\"service\":\"orders\",\"sha\":\"${{ github.sha }}\",\"environment\":\"production\",\"deployed_at\":\"$(date -u +%FT%TZ)\"}"
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Change failure (PagerDuty + deploy correlation)
|
||||
```ts
|
||||
async function changeFailureRate(service: string, days = 30) {
|
||||
const deploys = await db.deployments.count({ service, since: daysAgo(days) });
|
||||
const failedDeploys = await db.deployments.count({
|
||||
service, since: daysAgo(days),
|
||||
correlatedIncidentWithin: '4h', // 매 incident 가 deploy 후 4h 내 의 fail count
|
||||
});
|
||||
return failedDeploys / deploys;
|
||||
}
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### MTTR from PagerDuty
|
||||
```ts
|
||||
import { api } from '@pagerduty/pdjs';
|
||||
const pd = api({ token: process.env.PD_TOKEN! });
|
||||
const { data } = await pd.get('/incidents', {
|
||||
data: { since: daysAgo(30), service_ids: [SVC_ID], statuses: ['resolved'] },
|
||||
});
|
||||
const durations = data.incidents.map(i =>
|
||||
(new Date(i.resolved_at).getTime() - new Date(i.created_at).getTime()) / 1000);
|
||||
const mttr = durations.reduce((a,b)=>a+b,0) / durations.length;
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Four Keys (Google) on BigQuery
|
||||
```sql
|
||||
-- 매 https://github.com/dora-team/fourkeys 의 reference
|
||||
SELECT
|
||||
COUNTIF(event_type = 'deployment') AS deploys,
|
||||
AVG(TIMESTAMP_DIFF(deploy_time, first_commit_time, MINUTE)) AS lt_minutes,
|
||||
COUNTIF(failed) / NULLIF(COUNTIF(event_type = 'deployment'), 0) AS cfr,
|
||||
AVG(TIMESTAMP_DIFF(resolved_time, incident_time, MINUTE)) AS mttr_minutes
|
||||
FROM `project.four_keys.events_raw`
|
||||
WHERE deploy_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY);
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### Grafana dashboard panel (PromQL-style)
|
||||
```promql
|
||||
# Deployment frequency (deploys per day per service)
|
||||
sum by (service) (rate(deployments_total{env="production"}[7d])) * 86400
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
# Change failure rate
|
||||
sum by (service) (deployments_failed_total[30d])
|
||||
/ sum by (service) (deployments_total[30d])
|
||||
|
||||
# Lead time p50
|
||||
histogram_quantile(0.5, sum by (le, service) (rate(deploy_lead_time_seconds_bucket[30d])))
|
||||
```
|
||||
|
||||
### Reliability (SLO-aligned 5th metric)
|
||||
```ts
|
||||
// 매 service 의 SLO 의 meeting-or-exceeding 의 % of measurement windows
|
||||
const reliability = await prom.query(`
|
||||
(sum_over_time(slo_compliance{service="$svc"}[30d]) /
|
||||
count_over_time(slo_compliance{service="$svc"}[30d])) * 100
|
||||
`);
|
||||
```
|
||||
|
||||
### Anti-gaming guardrails
|
||||
```ts
|
||||
// 매 metric 의 isolated 의 game 가 가능 — pair 의 always 의 read
|
||||
const elite = (df > 1/day) && (lt < 1*day) && (cfr < 0.05) && (mttr < 1*hour);
|
||||
// 매 elite 가 X 만 high cfr 의 hide 의 X.
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Greenfield team | Adopt Four Keys (open source) on BigQuery |
|
||||
| GitHub-centric | dora-team/fourkeys + Cloud Run pipelines |
|
||||
| Multi-tool | LinearB / Sleuth / Faros AI / Jellyfish (SaaS) |
|
||||
| Self-host | Apache DevLake (LF AI) |
|
||||
| Enterprise governance | Faros + custom dashboards |
|
||||
|
||||
**기본값**: Apache DevLake (open source) or Four Keys reference impl; weekly review with team; show all 4 (5) together — never single metric.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[DevOps]] · [[Continuous-Delivery]]
|
||||
- 변형: [[SPACE-Framework]] · [[Engineering-Metrics]]
|
||||
- 응용: [[Trunk-Based-Development]] · [[Continuous-Integration]] · [[SRE]]
|
||||
- Adjacent: [[Accelerate-Book]] · [[Apache-DevLake]] · [[SLO-Engineering]] · [[Postmortem-Culture]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 metric definition explanation, 매 SQL/PromQL query authoring, 매 trend interpretation, 매 retrospective talking points generation.
|
||||
**언제 X**: 매 individual performance evaluation (DORA 의 team-level metric — never individual). 매 metric tuning to look good (gaming).
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Single metric optimization**: 매 deploy frequency 의 increase 만 → CFR explodes. 매 4 의 always 의 together 보기.
|
||||
- **Individual performance ranking**: 매 explicitly anti-pattern in DORA research. 매 team-level만.
|
||||
- **Vanity deploys**: 매 empty commits / config-only changes 의 count → meaningless.
|
||||
- **MTTR from "ticket close"**: 매 customer-impact end 의 measure, 매 ticket admin 가 X.
|
||||
- **Comparing teams in different domains**: 매 fintech vs internal tool 의 baselines 가 different.
|
||||
- **No deployment instrumentation**: 매 manual spreadsheet 가 X. 매 auto-emit deploy event.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Forsgren/Humble/Kim "Accelerate" 2018, Google DORA 2024 State of DevOps report, dora-team/fourkeys, Apache DevLake).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — DORA 4(5) metrics, queries, anti-patterns |
|
||||
|
||||
Reference in New Issue
Block a user