Teslimat sistemini ölçün
TamamlandıTeslimat akışını, kararsızlığı, hizmet sonuçlarını ve çabayı birlikte değerlendirin. Yapay zekânın etkisini değerlendirirken açık tanımlar kullanın.
Yayımlayan TaigaNasıl yazıyoruz?
Neler öğreneceksiniz?
- Teslimat performansını kod üretme faaliyetinden ayırt edin.
- Bir metriği olay tanımları ve kapsamıyla yorumlayın.
- Ölçümleri kişileri sıralamak yerine iyileştirme seçmek için kullanın.
Vermeniz gereken kararla başlayın
Ekip, yapay zekânın teslimatı iyileştirip iyileştirmediğini bilmek istiyor. Üretilen satırları saymak farklı soruyu yanıtlar. Metrik seçmeden önce yararlı sonucu ve kalite koşullarını tanımlayın.
Kurgusal dışa aktarma hizmetinde istenen sonuç, kabul edilen değişikliklerin daha az toplam çabayla güvenilir teslimatıdır. Hazırlığı, uygulamayı, incelemeyi, düzeltmeyi ve beklemeyi kaydedin. Başarısız olan veya terk edilen değişiklikleri dahil edin.
Sınırı açık tek hizmet kullanın. Deneysel web sitesini kritik ödeme hizmetiyle birleştirmek, ikisini de açıklamayan sayı üretebilir. Dönemleri veya ekipleri karşılaştırmadan önce bağlamı açıklayın.
Güncel tanımları kullanın
DORA’nın güncel teslimat modeli beş metrik içerir. Bunların kapsamı her özelliğin değeri veya kişinin katkısı değil, teslimat performansıdır. DORA metrik tanımları.
| Metrik | Ölçümün odağı |
|---|---|
| Değişiklik teslim süresi | Commit’ten üretime kadar geçen süre |
| Dağıtım sıklığı | Üretim dağıtımı sıklığı |
| Başarısız dağıtım sonrası kurtarma süresi | Başarısız dağıtımdan sonra kurtarma |
| Değişiklik hata oranı | Acil müdahale gerektiren dağıtımlar |
| Dağıtımda yeniden çalışma oranı | Üretim olaylarının neden olduğu plansız dağıtımlar |
Gösterge paneli başka tanım kullanabilir. Sonucu yorumlamadan önce okuyun. Taiga’nın güncel dağıtım belgeleri, sağlayıcı dağıtım kayıtlarından türetilen dört metriği açıklar. Kurtarma ölçümü, sonraki başarılı dağıtımı kullanır. Bu, her üretim olayının eksiksiz kaydı değildir. Taiga tanımları.
Kurgusal değişiklik dizisini inceleyin
Hizmetin bir ayda on iki dağıtım yaptığını varsayın. Sekizi planlı değişiklikleri teslim eder. Dördü önceki yayınların sorunlarını onarır. Sayı on ikidir, ancak bileşim önemlidir.
Sonraki ay ekip on dağıtım yapar: dokuz planlı değişiklik ve bir onarım. Daha az dağıtım, daha çok yararlı işle birlikte gerçekleşebilir. Bu sayılar yorumlamayı gösterir; performans karşılaştırma ölçütü değildir.
Dağılımı da inceleyin. Uzun bir inceleme beklemesi ortalamada kaybolabilir. Tek hatadan gelen kurtarma ölçümü, gelecekteki güvenilirlik için zayıf kanıttır. Gözlem sayısını ve önemli istisnaları raporlayın.
Akışı sonuçlarla birlikte değerlendirin
Teslimat değişikliklerinin kullanıcıları etkileyip etkilemediğini kontrol etmek için hizmet sinyallerini kullanın. Dışa aktarmalar daha sık başarısız oluyorsa daha hızlı pipeline yeterli değildir. Uygun SLO veya açıkça tanımlanmış başka sonuç ölçüsü kullanın. SLO rehberi.
İnceleme çabası ve yeniden çalışma, sonucu açıklamaya yardımcı olur. Yapay zekâ uygulama süresini kısaltıyor ancak büyük diff’ler üretiyorsa inceleme kısıta dönüşebilir. Ortamları edinmek günler sürüyorsa hızlı kodlama toplam teslimat süresini az etkileyebilir.
Gözlenen kısıtı ele alan bir iyileştirme seçin. Örneğin desteklenen test ortamı sağlayın veya değişiklik boyutunu küçültün. Ekibin zayıflatılmış kontrollerden kaynaklanan görünürdeki hız kazanımını tespit edebilmesi için dengeleyici kalite metriği tanımlayın.
Ölçümü yararlı tutun
PR sayısı veya üretilen kod üzerinden kişisel sıralamalardan kaçının. Bu ölçüler işi yapay biçimde bölmeyi, zor bakım işinden kaçınmayı veya inceleme çabasını çalışma arkadaşlarına aktarmayı ödüllendirebilir.
Sonucu, hizmetin tamamından sorumlu kişilerle inceleyin. Araçta, iş bileşiminde, ekipte ve ortamda neyin değiştiğini kaydedin. Öncesi-sonrası karşılaştırmasını, otomatik nedensellik kanıtı değil, sınırları olan kanıt olarak ele alın.
Amaç, sonraki kararı iyileştirmektir. Doğrulanmış iyileştirmeye yol açan küçük ve güvenilir ölçüm, anlamı üzerinde anlaşılmamış büyük gösterge panelinden daha yararlıdır.
On değişiklikle uygulama yapın
Bu ayrı kurgusal veri kümesi, on planlı değişikliği kaydeder. Tüm saatler, gösterilen tarihte UTC’dir. Boş düzeltme alanı, bu veri kümesinde düzeltme kaydedilmediği anlamına gelir.
| Değişiklik / tarih | İş başlar | Kod hazır | İnceleme başlar | Kabul edildi | Yayımlandı | Düzeltildi |
|---|---|---|---|---|---|---|
| C01 · 2026-09-14 | 08:00 | 08:45 | 09:15 | 09:30 | 10:00 | — |
| C02 · 2026-09-14 | 09:00 | 09:30 | 12:00 | 12:20 | 13:00 | — |
| C03 · 2026-09-15 | 08:00 | 09:00 | 09:15 | 09:40 | 10:00 | 15:00 |
| C04 · 2026-09-15 | 10:00 | 10:30 | 10:45 | 11:00 | 11:15 | — |
| C05 · 2026-09-16 | 08:00 | 09:00 | 13:00 | 13:30 | 14:00 | — |
| C06 · 2026-09-16 | 10:00 | 11:00 | 11:30 | 12:00 | 12:15 | — |
| C07 · 2026-09-17 | 08:00 | 08:30 | 09:00 | 09:20 | 09:30 | — |
| C08 · 2026-09-17 | 10:00 | 10:45 | 11:00 | 11:30 | 14:30 | — |
| C09 · 2026-09-18 | 08:00 | 08:30 | 09:00 | 09:30 | 10:00 | — |
| C10 · 2026-09-18 | 09:00 | 09:30 | 10:00 | 10:30 | 11:00 | 14:00 |
Kodun hazır olmasından incelemenin başlamasına, ardından kabulden yayına kadar geçen süreyi karşılaştırın. Görünen en uzun beklemeyi belirleyin. Önlenebilir demeden önce nedenini araştırın. Bu zaman damgaları etkin çabayı ölçmez veya olayın ne zaman başladığını belirlemez. Düzeltme yayını tek başına başarısız dağıtım sonrası kurtarma süresini ortaya koyamaz.
Kurgusal veri kümesini indirin (CSV)
Bekleme sürelerini kontrol edin
Yorumunuzu kontrol edin: C05 inceleme için dört saat bekler. C08 kabulden sonra yayına kadar üç saat bekler. Veri kümesi bu beklemeleri açıklamaz. Kapasiteyi, çalışma saatlerini, yayın politikasını ve bağımlılıkları sorun.
Alıştırmayı yapın
Bu dersteki on değişiklikli veri kümesini kullanın. Dağıtımı, başarısız değişikliği ve kurtarma olayını tanımlayın. Görünen en uzun beklemeyi bulun ve nedenini neyin ortaya koyacağını belirtin. Bir iyileştirme ve kalitenin kötüleştiğini gösterecek ölçü önerin.
Çalışma sayfasını indir (Markdown)Anladığınızı kontrol edin
Kaynaklar ve ek okumalar
- DORA: Software delivery performance metrics ↗
- Taiga docs: Deployments and metric definitions ↗
- Google SRE: Implementing SLOs ↗
Taiga'dan ilgili okumalar
Bu seçimi kaldırmak, bu tarayıcıda kaydedilmiş tüm ilerlemeyi siler.
İlerleme bu tarayıcıda kalır. Hesap ve takip yok.