# Apa Itu Metrik DORA? Panduan untuk Platform Engineer

URL: https://upstreamapi.com/id/journal/apa-itu-metrik-dora
Type: blog
Locale: id
Published: 2026-10-03
Updated: 2026-10-03

---

> Metrik DORA adalah lima ukuran software delivery: change lead time, deployment frequency, failed recovery time, change fail rate, dan rework rate. Panduan lengkap untuk SRE dan platform engineer.

Apa itu metrik DORA? Ini adalah lima ukuran untuk delivery software: lead time untuk perubahan, deployment frequency, failed deployment recovery time, change fail rate, dan deployment rework rate. Tiga metrik pertama menjelaskan throughput, dua terakhir menjelaskan instability. Bersama-sama mereka memberi tahu seberapa cepat perubahan mencapai production dan seberapa sering perubahan itu menyebabkan masalah. Digunakan dengan baik, metrik ini menunjukkan bottleneck. Digunakan dengan buruk, metrik ini menjadi kartu laporan yang dipelajari tim untuk dimanipulasi.

## Dari mana angka-angka berasal, dan mengapa istilah ini tetap bertahan

Platform lead duduk di review kuartalan. CTO bertanya satu pertanyaan: apakah kita ship lebih cepat dari tahun lalu, dan apakah kita breaking lebih sedikit? Tanpa vocabulari bersama, jawabannya adalah tumpukan anekdot. Metrik DORA ada untuk menggantikan anekdot dengan empat atau lima angka yang bisa didapat dari sistem yang sudah kita jalankan.

Nama berasal dari DevOps Research and Assessment, program riset yang menghabiskan bertahun-tahun mensurvei tim engineering dan menghubungkan praktik delivery mereka dengan outcomes organisasi. Sekarang bagian dari Google Cloud, dan findings dipublikasikan setiap tahun dalam program [DORA research](https://dora.dev/research/). Buku Accelerate mempopulerkan empat metrik awal. Framework telah direvisi sejak itu, dan revisi itu lebih penting daripada yang diakui oleh sebagian besar blog.

Bagian yang sering hilang: metrik ini tidak pernah dimaksudkan sebagai leaderboard. Mereka muncul dari penemuan statistik. Tim yang mendapat skor baik pada kecepatan juga mendapat skor baik pada stability. Kecepatan dan keamanan bukan tradeoff, mereka bergerak bersama. Ini adalah klaim tentang korelasi across banyak tim, bukan target untuk tim kita.

## Lima metrik, didefinisikan seperti engineer on-call yang mendefinisikannya

Definisi terkini di [panduan official DORA metrics](https://dora.dev/guides/dora-metrics/) terbagi menjadi dua grup. Bacanya dengan service spesifik dalam pikiran, karena setiap definisi jatuh dalam kesalahan jika diterapkan ke "perusahaan".

**Change lead time.** Waktu dari commit hingga commit itu berjalan di production. Bukan dari ticket dibuka, dan bukan dari pull request diapprove. Dari commit ke prod. Jika pipeline memakan waktu empat puluh menit dan release train berangkat pada hari Kamis, lead time kita didominasi oleh hari Kamis.

**Deployment frequency.** Seberapa sering ship ke production. Bisa hitung deployments dalam periode atau ukur gap di antara mereka. Service yang deploy sebelas kali sehari dan service yang deploy sekali sebulan adalah binatang yang berbeda, dan averaging mereka menyembunyikan keduanya.

**Failed deployment recovery time.** Berapa lama waktu untuk recover ketika deployment menyebabkan masalah yang memerlukan intervensi. Ini dulu disebut mean time to restore, dan perubahan nama itu disengaja. Ini hanya hitung incidents yang disebabkan oleh perubahan kita sendiri, bukan outage cloud provider pada hari Selasa.

**Change fail rate.** Bagian deployment yang memerlukan intervensi segera setelahnya: rollback, hotfix, forward fix yang dipush dengan cepat. Sepuluh deployment, dua di antaranya reverted, change fail rate dua puluh persen.

**Deployment rework rate.** Bagian deployment yang tidak direncanakan, dipicu oleh production incident daripada oleh roadmap work. Ini adalah penambahan terbaru, dan itu catch sesuatu yang change fail rate lewatkan: tim yang tidak pernah rollback tetapi menghabiskan setengah minggu ship emergency patches.

![Stopwatch resting on a server rack panel, a picture of lead time](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/02c796-i1.webp)

## Throughput versus instability: mengapa tidak pernah baca satu metrik sendiri

Tiga metrik pertama adalah throughput. Dua terakhir adalah instability. Pengelompokan itulah seluruh poinnya.

Jika hanya perhatikan throughput, akan celebrate tim yang deploy empat puluh kali sehari dan quietly revert seperempat dari mereka. Jika hanya perhatikan instability, akan reward tim yang ship sekali sebulan dengan spotless record, karena tidak ada yang ubah apa pun. Setiap single metrik punya cara murah untuk improve yang membuat sistem lebih buruk.

Deployment frequency naik ketika split deploy menjadi lima empty deploy. Change fail rate turun ketika stop count hotfix sebagai failure. Lead time shrink ketika redefine start dari clock. Ini adalah Goodhart's law melakukan apa yang selalu dilakukan: ketika measure menjadi target, itu berhenti menjadi good measure. Panduan official list ini first di antara warning, dan ini adalah yang bite paling keras.

Jadi working rule adalah pairs. Baca lead time next to change fail rate. Baca deployment frequency next to rework rate. Move dalam satu direction tanpa matching story di yang lain adalah signal untuk look closer, bukan win untuk announce.

Benchmark circulate di setiap vendor deck, dan mereka adalah trap. Reported pattern dari recent DORA reports adalah consistent dalam shape: strongest cluster tim deploy on demand, dengan lead time under sehari, dan recover dari failed deployment dalam under satu jam. Slowest cluster sit dalam weeks-to-months range di keduanya.

Angka-angka itu useful untuk satu hal: calibrating intuisi tentang apa yang possible. Mereka poor sebagai target. Service pembayaran dengan mandatory audit gate tidak akan match situs marketing, dan seharusnya tidak mencoba. Panduan official adalah explicit bahwa hanya compare similar application atau service, dan bahwa harus aim untuk improvement terhadap baseline sendiri daripada competition antara tim.

Mulai dengan median sendiri. Ukur untuk sebulan sebelum set goal apa pun. Angka pertama hampir selalu memalukan, dan itu fine. Baseline yang memalukan adalah baseline yang benar-benar dipercaya.

## Bagaimana instrument mereka tanpa build data platform

Sebagian besar tim overbuild ini. Tidak perlu warehouse project. Perlu empat timestamp dan satu flag.

Timestamp: commit merged ke main branch, build finished, deployment started dalam production, deployment finished. Flag: apakah deployment kemudian reverted, hotfixed, atau diikuti oleh unplanned deploy dalam defined window.

Berikut sketch minimal dalam TypeScript. Ini take list deployment record dan return angka yang matter.

`type Deploy = {
  service: string;
  committedAt: Date;
  deployedAt: Date;
  failed: boolean;       // reverted, hotfixed, atau manual intervention
  unplanned: boolean;    // triggered oleh incident, bukan oleh roadmap work
  recoveredAt?: Date;    // set ketika failed adalah true
};

const median = (xs: number[]) => {
  const s = [...xs].sort((a, b) => a - b);
  return s.length ? s[Math.floor(s.length / 2)] : 0;
};

export function doraSummary(deploys: Deploy[], days: number) {
  const leadHours = deploys.map(
    d => (d.deployedAt.getTime() - d.committedAt.getTime()) / 36e5,
  );
  const failures = deploys.filter(d => d.failed);
  const recoveryMins = failures
    .filter(d => d.recoveredAt)
    .map(d => (d.recoveredAt!.getTime() - d.deployedAt.getTime()) / 6e4);

  return {
    leadTimeHoursP50: median(leadHours),
    deploysPerDay: deploys.length / days,
    changeFailRate: failures.length / Math.max(deploys.length, 1),
    recoveryMinutesP50: median(recoveryMins),
    reworkRate: deploys.filter(d => d.unplanned).length / Math.max(deploys.length, 1),
  };
}`Dua decision dalam snippet itu carry berat. Pertama, pakai median, bukan mean. Satu bad week dengan three-day recovery akan wreck average dan tell nothing tentang typical Tuesday. Kedua, compute semuanya per service. Aggregate ke tim atau department hanya setelah look di service di bawahnya.

Bagian sulit bukan codenya. Bagian sulit adalah flag `failed`. Seseorang harus decide apa yang count sebagai failure, write turun, dan apply dengan cara yang sama setiap waktu. Jika incident tracker kita link incident ke deployment yang disebabkan mereka, dapat ini hampir free. Jika tidak, mulai di sana.

![Industrial breaker panel with one red lever pulled, a picture of a failed change](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/f8caad-i2.webp)

Pertanyaan tooling datang setelah pertanyaan data. Sudah own sebagian besar raw data. Git host punya commit time. CI punya build dan deploy event. Incident tool punya failure. Kerjanya adalah joining mereka pada shared deployment identifier.

Platform observability adalah natural place untuk overlay deployment marker di atas error rate dan latency, jadi bisa see mana deploy yang preceded yang spike.

Jika lebih prefer keep stack open dan self-hosted, dashboard layer di atas database sendiri deployment event buat same job dengan lower cost, dengan lebih plumbing di sisi kita.

Ada juga category tooling yang read repository dan delivery history kita dan surface risk, seperti hotspot di mana code churn dan past defect cluster. Tidak akan replace empat timestamp, tetapi explain mengapa satu service punya high change fail rate ketika neighbor tidak.

Caution pada buy apa pun di sini. Dashboard yang show angka tidak sama dengan tim yang act di mereka. Jika tidak ada yang own recovery time chart, buy nicer chart change nothing.

## Lever yang benar-benar move setiap angka

Metrik adalah diagnosis. Perawatan ada di tempat lain, dan itu berbeda untuk setiap satu.

Untuk lead time, look di waiting, bukan working. Pull selusin recent change dan mark di mana setiap satu sit idle: awaiting review, awaiting build slot, awaiting release window. Di kebanyakan tim idle time outweigh coding time beberapa kali. Smaller pull request dan review service-level expectation beat apa pun pipeline tuning.

Untuk deployment frequency, lever adalah batch size. Smaller change lebih mudah review, lebih mudah reason tentang, dan lebih mudah revert. Trunk-based development dan feature flag exist untuk let merge unfinished work safely, yang bagaimana decouple deploying dari releasing.

Untuk change fail rate, lever adalah berapa banyak blast radius yang bisa see sebelum whole fleet. Rollout yang expose satu persen traffic, watch error rate terhadap SLO, dan halt pada breach turn would-be incident menjadi non-event. Itu gap antara failed deployment dan failed change yang tidak ada orang lain di tim perhatikan.

Untuk recovery time, lever adalah revert. Jika fix tercepat adalah rollback, maka recovery time berapa cepat detect masalah plus berapa cepat press button. Automating revert pada threshold breach cut human dari first ten minute. Pada jam 3 pagi itu matter lebih dari apa pun runbook.

Untuk rework rate, lever adalah upstream. Angka tinggi berarti incident generate deployment. Look di service mana yang produce emergency patch, dan read post-mortem mereka sebagai set daripada one di satu waktu.

## Apa perubahan ketika AI menulis lebih banyak kode kita

Recent DORA research point di sesuatu yang uncomfortable untuk siapa pun yang sell coding assistant. Assistant speed up low-level task, tetapi gain tidak clearly carry through ke lead time atau change fail rate. Lebih banyak kode yang ditulis per jam bukan sama dengan lebih banyak value delivered per minggu.

Jika apa pun, volume lebih besar generated change push pressure ke review dan ke delivery pipeline kita. Bigger batch hurt stability, dan review capacity tidak scale dengan typing speed. Watch change fail rate dan rework rate dengan close di bulan setelah tim adopt assistant. Jika lead time jatuh tetapi rework climb, tidak dapat faster, move cost.

![Notebook with hand-drawn trend charts for a team retrospective](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/30e093-i3.webp)

## Bagaimana menggunakan mereka dalam retro tanpa break tim

Inilah yang bekerja dalam praktik. Put trend line di screen untuk last quarter dan ask satu pertanyaan: apa yang berubah di sini, dan mengapa? Jangan ask siapa. Goal adalah hypothesis tentang system, bukan verdict tentang person.

Tiga habit keep angka honest.

Pertama, tidak pernah put di individual performance review. Moment metrik attach ke name, orang optimize metrik, dan data berhenti describe reality.

Kedua, pair setiap angka dengan story. Spike dalam recovery time adalah satu incident dengan name dan post-mortem. Read post-mortem sebelum read chart.

Ketiga, change satu hal di satu waktu. Jika adopt feature flag, shrink pull request, dan automate rollback dalam bulan yang sama, tidak akan pernah learn yang mana move needle.

Skip maturity-model slide yang sort org ke tier dan hand trophy. Worth effort bukan: satu halaman per service, diupdate monthly, list lima angka, value bulan sebelumnya, dan satu kalimat tentang apa yang berubah.

Suppose had sembilan puluh hari data bersih di satu service, dan saw change fail rate creeping naik sementara deployment frequency stay flat. Di mana look first: ukuran change, kualitas review, atau visibility yang have ke rollout saat masih small? Jawaban say lebih banyak tentang delivery system daripada apa pun benchmark.

## FAQ

### Apa itu metrik DORA?

Metrik DORA adalah lima ukuran untuk mengukur kecepatan dan stabilitas software delivery: change lead time, deployment frequency, failed deployment recovery time, change fail rate, dan deployment rework rate.

### Siapa yang membuat metrik DORA?

Metrik DORA berasal dari DevOps Research and Assessment, program riset yang dikembangkan selama bertahun-tahun untuk mensurvei dan menganalisis praktik engineering tim berkinerja tinggi. Program ini sekarang bagian dari Google Cloud.

### Bagaimana cara mengimplementasikan metrik DORA?

Implementasi memerlukan empat timestamp (commit, build finish, deployment start, deployment finish) dan satu flag (failed/unplanned). Data bisa dikumpulkan dari Git, CI, dan incident tracker yang sudah dijalankan.

### Mengapa membaca metrik DORA secara berpasangan?

Karena setiap metrik bisa dimanipulasi. Dengan membaca throughput dan stability berpasangan, tim bisa mendeteksi apakah improvement benar atau hanya perubahan metrik yang menyembunyikan masalah lebih dalam.

### Apa perbedaan antara change fail rate dan rework rate?

Change fail rate mengukur deployment yang memerlukan intervensi segera (rollback, hotfix). Rework rate mengukur deployment yang tidak direncanakan, dipicu oleh incident. Rework rate menangkap masalah yang fail rate lewatkan.

### Bagaimana benchmark DORA digunakan dengan benar?

Benchmark DORA seharusnya hanya digunakan untuk kalibrasi intuisi, bukan sebagai target. Sebaiknya compare dengan baseline tim sendiri sebelumnya, bukan dengan tim lain atau industri standar.