DORA metrikleri nedir ve yazılım teslimatını nasıl ölçer

DORA metrikleri nedir? Yazılım teslimatını gerçek verilerle ölçmek

DORA metrikleri yazılım teslimatının beş ölçüsüdür: commit'ten production'a kadar geçen süre, deployment sıklığı, başarısız deployment'tan kurtulma süresi, başarısız deployment oranı ve plansız deployment oranı. İlk üç metrik işlem hızını, son ikisi istikrarsızlığı tanımlar. Beraber ele alındığında, değişikliklerin production'a ne kadar hızlı ulaştığını ve bu değişikliklerin ne sıklıkla sorun yarattığını gösterirler. Doğru kullanıldığında, darboğazı işaret ederler. Yanlış kullanıldığında, takımınızın oyunu öğrendiği bir rapor kartı haline gelirler.

Özet

DORA metrikleri, sürekli dağıtım yapan platform mühendisleri ve SRE'ler için teslimat hızı ve istikrarlılığını objektif bir şekilde izlemek üzere tasarlanmıştır. Change lead time, deployment frequency, failed deployment recovery time, change fail rate ve deployment rework rate'i ölçerek, ekipler üretim ortamında gerçekten neler olup bittiğini anlayabilir. Metrikler her zaman çiftler halinde okunmalıdır: hız bir tarafa, istikrar bir tarafa. Sadece hızı izlemek, sık sık başarısız olan deploymentleri görmemenizi sağlayabilir; sadece istikrarlılığı izlemek ise hiç deploy etmeyen ekipleri ödüllendirebilir. Doğru enstrümantasyon dört zaman damgası ve bir başarısızlık bayrağıyla basit ve ucuz tutulabilir.

Sayılar nereden gelir ve neden bu terimler kaldı

Bir platform lideri üç ayda bir gözden geçirmede oturur. CTO bir soru sorar: geçen yıldan daha hızlı mı sevk ediyoruz ve daha az mı kırıyoruz? Ortak bir sözcük dağarcığı olmadan, cevap anekdotlar yığınıdır. DORA metrikleri anekdotları zaten çalıştırdığınız sistemlerden çekebileceğiniz dört veya beş sayıyla değiştirmek için vardır.

Ad DevOps Araştırması ve Değerlendirmesinden gelir. Bu araştırma programı yıllar boyunca mühendislik takımlarını araştırdı ve teslimat uygulamalarını örgütsel sonuçlarla ilişkilendirdi. Şimdi Google Cloud'un bir parçasıdır ve bulgular her yıl yayımlanır. Accelerate kitabı orijinal dördünü popüler hale getirdi. Çerçeve o zamandan beri revize edilmiştir ve bu revizyon çoğu blog yazısından daha önemlidir.

Kaybolan kısım şudur: metrikler hiçbir zaman bir lider tablosu olarak amaçlanmamıştır. İstatistiksel bir bulgudan çıktılar. Hız konusunda iyi puan alan takımlar istikrar konusunda da iyi puan aldı. Hız ve güvenlik bir ödünleşme değildi, beraber hareket ettiler. Bu birçok takım arasında korelasyon hakkında bir iddia, sizin takımınız için bir hedef değildir.

Beş metrik, bir üzerinde nöbet tutan mühendis gibi tanımlanmış

Resmi DORA metrikleri rehberindeki mevcut tanımlar iki gruba ayrılır. Bunu belirli bir hizmet aklınızda tutarak okuyun, çünkü her tanım "şirket" için uygulanırsa parçalanır.

Change lead time. Bir commit'ten bu commit'in production'da çalışması arasındaki süre. Ticket'in açılmasından değil, pull request'in onaylanmasından değil. Commit'ten prod'a. Pipeline'ınız kırk dakika sürüyorsa ve release train'iniz Perşembeleri çıkıyorsa, lead time'ınız Perşembenin hakimiyetindedir.

Deployment frequency. Production'a ne sıklıkta sevk edersiniz. Deploymentları bir dönem içinde sayabilir veya aralarındaki boşluğu ölçebilirsiniz. Günde on bir kez deploy eden bir hizmet ile ayda bir kez deploy eden bir hizmet farklı hayvanlardır ve onları ortalaması her ikisini de gizler.

Failed deployment recovery time. Bir deployment sorun yarattığında ve müdahale gerektiğinde kurtulmak ne kadar sürer. Buna mean time to restore denilirdi ve yeniden adlandırma kasıtlıdır. Yalnızca kendi değişikliğinizin neden olduğu olayları sayar, Salı günü bulut sağlayıcısı kesintisini değil.

Change fail rate. Deploymentların kaçta kaçının sonrasında hemen müdahale gerektirir: bir rollback, hotfix, hızlı push forward fix. On deployment, ikisi geri döndü, %yirmi change fail rate.

Deployment rework rate. Deploymentların kaçta kaçı plan dışı, yol haritası işi yerine incident'e tetiklenen. Bu yeni ektir ve change fail rate'in kaçırdığı bir şeyi yakalar: hiçbir zaman rollback yapmayan ancak haftasının yarısını acil patch göndererek harcayan takım.

Hız versus istikrar: neden asla bir metriği tek başına okumadığınız

İlk üç metrik işlem hızıdır. Son ikisi istikrarsızlıktır. Gruplandırma tüm noktadır.

Sadece hızı izlerseniz, günde kırk kez deploy eden ve sessizce dörtte birini geri döndüren bir takımı kutlayacaksınız. Sadece istikrarlılığı izlerseniz, ayda bir kez temiz rekorla sevk eden bir takımı ödüllendireceksiniz çünkü kimse hiçbir şeyi değiştirmez. Her metriğin sistemi kötüleştiren ucuz bir iyileştirme yolu vardır.

Deployment frequency, bir deploy'u beş boş deploy'a bölündüğünde artar. Change fail rate, hotfix'leri arıza olarak saymayı durdurduğunuzda düşer. Lead time, saatin başlangıcını yeniden tanımladığınızda küçülür. Bu Goodhart'ın yasasının hep yaptığı şeydir: ölçü bir hedef olduğunda, iyi bir ölçü olmaktan çıkar. Resmi rehber bunu uyarılar arasında ilk sırada listeler ve en sert şekilde ısırır.

Yani çalışan kural çiftlerdir. Lead time'ı change fail rate'in yanında okuyun. Deployment frequency'yi rework rate'in yanında okuyun. Bir yöndeki bir hareket, diğerinde eşleşen bir hikaye olmadan, daha yakından bakmayı işaret eder, duyuracak bir kazanç değildir.

Benchmarklar her satıcı slaytında dolaşır ve bir tuzaktır. Son DORA raporlarından bildirilen desen şekil açısından tutarlıdır: en güçlü takım kümesi on demand deploy eder, lead time bir gün altında ve başarısız deployment'dan bir saat altında kurtulur. En yavaş küme hafta-ay aralığında her ikisinde de oturur.

Bu rakamlar bir şey için kullanışlıdır: sezginizi mümkün olanlar hakkında kalibre edin. Hedef olarak zayıftırlar. Zorunlu audit gate'i olan ödeme hizmeti pazarlama sitesiyle eşleşmeyecek ve eşleşmeye çalışmamalıdır. Resmi rehberlik açık: sadece benzer uygulamaları veya hizmetleri karşılaştırmalısınız ve takımlar arasında rekabete karşı kendi baseline'ınıza karşı iyileşmeyi hedeflemelisiniz.

Kendi median'ınızla başlayın. Herhangi bir hedef belirlemeden önce bir ay boyunca ölçün. İlk sayı neredeyse her zaman utanç vericidir ve bu iyidir. Sizi gerçekten rahatsız eden bir baseline, gerçekten güvenebileceğiniz bir baseline'dır.

Bilgi yoklamadan enstrüman basit tutun

Çoğu takım bunu aşırı yapar. Bir warehouse projesi gerekmez. Dört zaman damgası ve bir bayrak gerekir.

Zaman damgaları: ana şubeye commit merge edildi, build bitti, production'da deployment başladı, deployment bitti. Bayrak: deployment'ın daha sonra geri döndürülüp döndürülmediği, hotfix'lendiği veya tanımlanmış bir pencere içinde plan dışı deploy izlemesi yapılıp yapılmadığı.

TypeScript'te minimal bir taslak. Deployment kayıtları listesini alır ve önemli olan sayıları döndürür.

type Deploy = {
  service: string;
  committedAt: Date;
  deployedAt: Date;
  failed: boolean;       // reverted, hotfixed, or manual intervention
  unplanned: boolean;    // triggered by an incident, not by roadmap work
  recoveredAt?: Date;    // set when failed is 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),
  };
}

Bu snippet'teki iki karar ağırlığı taşır. Birincisi, ortalama yerine medyan kullanır. Üç günlük kurtulma süresi olan bir kötü hafta ortalamayı mahvedecek ve tipik bir Salı hakkında hiçbir şey söylemeycektir. İkincisi, her şeyi hizmet başına hesaplar. Sadece altındaki hizmetlere baktıktan sonra takım veya departman olarak bir araya getirin.

Zor kısım kod değildir. Zor kısım failed bayrağıdır. Birinin ne olarak sayılacağını tanımlaması, yazması ve her seferinde aynı şekilde uygulaması gerekir. Incident tracker'ınız incident'leri neden olduğu deployment'a bağlarsa, bunu neredeyse ücretsiz olarak alırsınız. Yapmıyorsa, başlayın.

Tool sorusu veri sorusundan sonra gelir. Zaten çoğu ham verisinin sahibisiniz. Git host'unuz commit zamanlarına sahiptir. CI'nız build ve deploy event'lerine sahiptir. Incident tool'unuz arızalarına sahiptir. İş, onları paylaşılan bir deployment tanımlayıcısında bir araya getirmektir.

Observability platform'ları deployment marker'larını error rate'leri ve latency'nin üstüne bindirmek için doğal bir yerdir, böylece hangi deploy'un hangi spike'ı önceden aldığını görebilirsiniz.

Stack'i açık ve self-hosted tutmayı tercih ederseniz, deployment event'lerinizin kendi veritabanı üzerine bir dashboard layer aynı işi daha düşük maliyetle ve daha fazla plumbing'iniz tarafında yapar.

Ayrıca, repository'lerinizi ve teslimat geçmişini okuyan ve risk ortaya çıkaran bir araç kategorisi vardır, örneğin kod churn'un ve geçmiş kusurların cluster olduğu hotspot'lar. Dört zaman damgasının yerini almayacak, ama neden bir hizmet komşularından yüksek change fail rate'a sahip olduğunu açıklar.

Buraya bir şey satın almak konusunda bir uyarı. Sayıları gösteren bir dashboard, onlar üzerinde hareket eden takım ile aynı değildir. Kimse kurtulma süresi tablosunun sahibi değilse, daha güzel bir grafik satın almak hiçbir şeyi değiştirmez.

Her sayıyı gerçekten hareket ettiren kaldıraçlar

Metrikler bir tanıdır. Tedavi başka bir yerde ve her biri için farklıdır.

Lead time için, çalışmayı değil, beklemeyi arayın. Son bir düzine değişikliği çekin ve her birinin nerede boş oturduğunu işaretleyin: review bekliyor, build slot bekliyor, release window bekliyor. Çoğu takımda boş zaman kodlama zamanının birkaç katını aşar. Daha küçük pull request'ler ve bir review service-level expectation, pipeline tuning'ten daha iyidir.

Deployment frequency için kaldıraç batch boyutudur. Daha küçük değişiklikler gözden geçirmesi daha kolay, akıl yürütmesi daha kolay, geri döndürülmesi daha kolay. Trunk-based development ve feature flag'ler bitmemiş işi güvenli bir şekilde merge etmenizi sağlamak için vardır; bu, deployment'ı release'ten ayırmanızı sağlar.

Change fail rate için kaldıraç, push yapmadan önce gördüğünüz blast radius ne kadardır. Trafik yüzde birini açığa çıkaran, bir SLO'ya karşı error rate'i izleyen ve ihlalde durduran bir rollout, olacak bir incident'i bir non-event'e dönüştürür. Bu başarısız deployment ile takım dışında kimsenin fark etmediği başarısız değişiklik arasındaki boşluktur.

Recovery time için kaldıraç revert'tir. En hızlı düzeltme rollback ise, recovery time sorunun ne kadar hızlı tespit edilmesi artı düğmeye ne kadar hızlı basılması olur. Threshold ihlalinde revert'i otomatikleştirmek, ilk on dakika içinde insanı çıkarır. Saat 3'te bu herhangi bir runbook'tan daha önemlidir.

Rework rate için kaldıraç upstream'dir. Yüksek bir sayı incident'lerin deployment ürettiği anlamına gelir. Acil patch'leri hangi hizmetlerin ürettiğine bakın ve post-mortem'lerini bir set olarak birer birer değil okuyun.

AI daha fazla code yazarken ne değişir

Son DORA araştırması, herhangi bir coding assistant satanlar için rahatsız edici bir şeye işaret eder. Asistan'lar düşük seviye task'ları hızlandırır, ancak kazançlar clearly lead time'a veya change fail rate'a taşımıyor. Saat başına daha fazla yazılan kod, hafta başına teslim edilen daha fazla değer ile aynı değildir.

Varsa bile, üretilen değişikliklerin daha büyük hacmi review'a ve teslimat pipeline'ına baskı uygular. Daha büyük batch'ler istikrarlılığa zarar verir ve review kapasitesi typing hızıyla ölçeklemez. Takım bir asistan'ı benimsedikten sonraki aylarda change fail rate'ınızı ve rework rate'ınızı yakından izleyin. Lead time düşerse ancak rework tırmanırsa, daha hızlı olmadınız, maliyeti hareket ettirdiniz.

Onları bir retro'da kullanmak takımınızı kırmadan

İşte pratikte çalışan. Son çeyrek için trend line'ları ekrana koyun ve bir soru sorun: burada ne değişti ve neden? Kim sorusu sorma. Hedef bir sistem hakkında bir hipotez, bir kişi hakkında bir karar değildir.

Üç alışkanlık sayıları dürüst tutar.

Birincisi, hiçbir zaman onları bireysel performans değerlendirmelerine koymayın. Metrik bir ad'a takıldığı anda, insanlar metriği optimize eder ve verileriniz gerçekliği tanımlamaktan çıkar.

İkincisi, her sayıyı bir hikaye ile eşleştirin. Kurtulma zamanında bir spike, bir ad'ı ve bir post-mortem'i olan bir incident'tir. Tabloyu okumadan önce post-mortem'i okuyun.

Üçüncüsü, bir defada bir şeyi değiştirin. Aynı ayda feature flag'ları benimserseniz, pull request'leri küçültürseniz ve rollback'leri otomatikleştirirseniz, asla hangi biri ibreyi hareket ettirdiğini öğrenmeyeceksiniz.

Sizin org'ınızı katmanlara ayıran ve trof dağıtan maturity model slide'ı atlayın. Bunun yerine değer: hizmet başına bir tek sayfa, aylık olarak güncellenen, beş sayıyı, önceki ayın değerini ve ne değiştiğinin bir cümlesi listeleyen.

Son olarak, doksan günlük temiz veriye ve bir hizmetete sahip olduğunuzu ve change fail rate'ın yükseldiğini gördüğüzü ama deployment frequency düz kaldığını farz edin. Nerede ilk bakmak: değişikliklerin boyutu, review'un kalitesi veya rollout'un hala küçük olması sırasında sahip olduğunuz görünürlük? Cevabınız herhangi bir benchmark'tan daha fazla teslimat sistemi hakkında söyler.