Mühendislik Analitiği - teslimat ve geliştiriciler

Mühendislik Analitiği, AppArch’ın zaten topladığı veriyi (merge request’ler, taramalar, dağıtımlar, işler, olaylar) teslimat ölçütlerine çevirir. Her ekranda tek kural geçerli: ölçülemeyen bir sayı sıfır değil, ölçülmemiş olarak gösterilir ve yan yana gösterilen iki seri asla sebep-sonuç olarak sunulmaz.

Proje sağlık karnesi (/reports/health)

Platformun proje başına tuttuğu her skor tek kartta: ArchScan, ArchSecurity, Uyumluluk, Git Sağlığı ve SonarQube türevi skor (güvenilirlik, güvenlik ve sürdürülebilirlik notları A=100 … E=20 olarak eşlenir); her biri o aracın son 0-100 değeri, araç projeyi hiç değerlendirmediyse tire.

• Uzlaşı - mevcut kaynakların ortalaması, her zaman kaç kaynaktan olduğuyla birlikte (“3 kaynaktan”). Ağırlıklı bir endeks değildir, eksik kaynağı asla sıfır saymaz.
• Değerlendiren - her merceğin kaç projeye baktığı; tek kaynaklı yüksek bir uzlaşı tam olarak öyle okunur.
• Araçlar çelişiyor - ArchScan ile Sonar skorunun 20 puan ve üzeri ayrıştığı projeler, yönüyle birlikte (“Sonar daha cömert” / “Sonar daha sert”). Hangi aracın haklı olduğuna hüküm değil, bakılacak yer.
• Tüm mercekler yeşil - değerlendiren her kaynak 80 ve üzeri, en az iki kaynakla.
• Dış bulgular - proje başına açık GitLab ve SonarQube güvenlik bulguları (toplam, kritik, yüksek) ArchSecurity skorunun altında sayı olarak listelenir; uzlaşıya asla girmez. Bir kutu karttaki açık kritik bulguları toplar.
• Seçili dönemde proje başına ArchScan ve Sonar eğilim çizgileri, Sonar kalite kapısı, kapsam ve tekrar oranı, proje grubu filtresi.

MR Analizi (/reports/mr-insights)

Bağlı her projenin her merge request’i 30 dakikada bir eşitlenir: yazar, durum, açılış/merge/kapanış zamanları, kimin merge ettiği, boyut (ekleme, silme, değişen dosya) ve ilk inceleme zamanı.

• Haftalık çıktı - haftaya göre açılan, merge edilen ve kapanan.
• Risk listesi - boyut, kendi kendine merge, eksik onay ve eksik inceleme yorumuna göre puanlanan merge’ler; en yüksek puan önce.
• Belirtiler - büyük MR’lar, uzun inceleme beklemeleri, kendi kendine merge’ler, incelenmemiş merge’ler; her birinin arkasındaki sayılarla.
• Etkinlik ısı haritası - “iş ne zaman düşüyor”: izleyicinin kendi saat diliminde 7 gün x 24 saat, açılış ve merge birlikte. Yerel Pazartesi-Cuma 08:00-19:59 dışındaki merge’ler ayrıca sayılır; hüküm olarak değil, sorulacak soru olarak.
• İnceleme kapsamı - yorumları eşitlenmiş merge edilmiş MR’ların yazar dışından en az bir sayılan insan yorumu aldığı pay; kalanı sessizce merge edilmiştir. İnceleme yorumu kararlarını kullanır, teşekkür yorumları inceleme sayılmaz.

Onay sütunları yalnızca ArchPilot’un gördüğü MR’ları kapsar.

İnceleme yorumları (/reports/review-comments)

Eşitlenen her merge request’in insan yorumları MR’ın yanında saklanır (GitLab, GitHub, Bitbucket Cloud ve Azure DevOps; “2 commit eklendi” gibi sistem olayları ve ArchPilot’ın kendi yorumları hiç saklanmaz). Ekranın yanıtladığı soru gerçekten kim inceliyor; sayımı dürüst tutan şey her yorumdaki karardır:

• Karar yok - aksi söylenene kadar inceleme işi sayılır.
• İnceleme - gerçek yorum: soru, sorun, öneri, karar.
• Hariç - teşekkür, “tamam yaparız”, emoji gibi yanıtlar. Hiçbir sayıma girmez.

Kararı workspace sahibi ya da yöneticisi elle verir. Modül ayarları > ArchPilot > Karar bekleyen yorumları AI ile sınıflandır açıksa kurulumun AI sağlayıcısı karar verilmemiş yorumları 10 dakikada bir değerlendirir; yönetici kararının üzerine asla yazılmaz. Anahtar yalnızca kurulum yöneticisi bir AI sağlayıcısı yapılandırıp en az bir AI özelliğini açtıysa görünür. Sayfadaki AI kartı sınıflandırmanın bugüne kadarki maliyetini (çağrı, karara bağlanan yorum, giriş/çıkış jetonu) ve son çağrının ne yaptığını gösterir; yönetici Bekleyenleri şimdi sınıflandır ile hemen bir geçiş kuyruğa alabilir (en çok 40 yorum, iki sağlayıcı çağrısı). Sınıflandırma kurulumun AI anahtarından harcar ve asistan kotasından düşer.

Sayılan yorumlar MR Insights’taki İnceleme yorumları kutusunu ve Kim yorum yazıyor dağılımını, geliştirici profilindeki İnceleme yorumu değerini besler. MR yazarının kendi MR’ına yazdığı yorumlar listelenir ama verilen inceleme olarak sayılmaz.

AI Etkisi (/reports/ai-impact)

Kurulumun AI sağlayıcısının bu workspace için maliyeti - bulgu açıklamaları, asistan cevapları ve inceleme yorumu sınıflandırma çağrıları (giriş/çıkış jetonları, yeniden üretimler, kişi ve model başına; son ikisi workspace düzeyindedir ve yalnızca tüm projeler görünümünde sayılır) ile aynı haftalarda değişenler yan yana: ArchScan skoru, ArchPilot bulgu yoğunluğu, merge edilen özellik ve düzeltmeler. Sayfa dipnotu açıkça söyler: seriler birlikte gösterilir, nedensellik iddia edilmez.

DORA (/reports/dora)

Dört metrik de gösterilir; olay verisi gerektiren ikisi bir olay kaynağı bağlanana kadar boş kalır.

Metrik	Kaynak	Notlar
Dağıtım sıklığı	Katalog dağıtım olayları (Argo CD, Kubernetes, Flux)	Dağıtım zamanı webhook değil, 10 dakikaya kadar gecikmeli bir gözlemdir. Yalnızca Kubernetes okuyan kaynaklar commit değil imaj etiketi bildirir; izlenemez olarak sayılır.
Bekleme süresi	Merge zamanından (MR olguları) commit’i taşıyan dağıtıma	Ortam başına; eşleşmeyen revizyon bilinmiyordur, asla sıfır değil. Aşama kırılımı inceleme bekleme, incelemede ve çıkmayı bekleme’yi gösterir; ölçülmeyen iki aşama gri çizilir.
Hatalı değişiklik oranı	Aynı servisin dağıtımından sonraki bir saat içinde açılan olaylar	Zaman korelasyonu, neden kanıtı değil; sayfa bunu yazar.
Toparlanma süresi	Olay açılışından kapanışına	Aynı kaynak.

Elite/yüksek/orta/düşük bantları haftalık kadansın yaklaşığıdır ve gerçek sayının yanında durur, yerine geçmez. Aşama medyanları bağımsızdır; başlıktaki medyana toplanmaz.

İş akışı (/reports/issue-flow)

Jira bağlantısıyla işler 30 dakikada bir geri okunur ve akış her işin changelog’undan türetilir: new’dan ilk çıkış saati başlatır, done’a son giriş durdurur. Çıktı, döngü süresi, süren iş ve yaşlanma yedi alarmla raporlanır (WIP aşırı yükü, bayat süren iş, yaşlanan backlog, atanmamış süren iş, yeniden açılan, hata ağırlıklı, düşük akış kapsamı). Alt görevler çıktıdan hariçtir; her hikâyeyi altıya bölen takım altı kat hızlı görünmez.

Olay kaynakları

Dynatrace ve New Relic olayları çalışma alanına çekilir ve servislerle ada göre eşlenir. Eşleşmeyen olaylar sayılır ve gösterilir; bağlı olup hiç olay saklamamış platform ayrı bir uyarı alır, çünkü yanlış hesaba kapsanmış bir jeton kusursuz doğrulanıp hiçbir şey beslemez ve DORA bunu %0 hata oranı olarak okurdu.

Uyumluluk ve Git Sağlığı geçmişi (/reports/score-history)

İki skorun zaman içindeki seyri. Bir projenin haftalık değeri o haftaki son başarılı taramasıdır; genel çizgi o hafta taranan projelerin ortalamasıdır ve kaç proje olduğunu söyler. Taraması olmayan hafta boşluktur, ileri taşınmaz. Proje başına: son skor, dönem içindeki ilk ve son tarama arasındaki değişim, tarama sayısı ve eğilim çizgisi; kutularda güncel ortalama, ortalama değişim, iyileşen ve gerileyen proje sayısı.

Güvenlik bulgu eğilimi (/reports/security-trend)

GitLab ve SonarQube bulguları yaşam döngüsü olarak. Tespit tarihi sağlayıcınındır; bir eşitleme bulguyu artık açık görmediğinde (çözüldü ya da reddedildi) bulgu kapanmış sayılır. Sayfa bu iki tarihten haftalık ve kaynak bazında yeni, kapanan ve hafta sonundaki açık birikimi yeniden kurar; örnekleme değil, yeniden kurma olduğu için sayfa ilk açılmadan önceki haftalar da vardır. Kutular: şu an açık (kritiklerle), dönemde yeni ve kapanan, net değişim, medyan kapanma süresi. Kaynak ve proje tabloları. AppArch’ın kendi ArchSecurity taramaları koşu başına anlık görüntüdür, bu yaşam döngüsünün dışındadır.

ADR yaşam döngüsü (/reports/adrs)

Mimari kararlar süreç olarak: duruma göre sayılar, medyan yaşıyla açık teklifler, sonuca göre aylık kararlar, oluşturulmadan karara ortalama gün, kabul oranı, geçersiz kılınan kararlar, etiketler ve proje dağılımı. 30 günden eski teklifler en eski önce listelenir; kimsenin karar vermediği teklif, kendiliğinden verilmiş bir karardır.

Erişim ve katkı (/reports/developer-access)

Eşitlenen her geliştirici için: sağlayıcıya göre üyesi olduğu projeler, dönemde etkin olduğu projeler (MR açmış ya da sayılan inceleme yorumu yazmış) ve uyuyan üyelikler (etkinliksiz erişim). Tersi de var: sağlayıcının üye olarak listelemediği projelere katkı. Uyuyan erişim yalnızca MR’ları eşitlenen projelerde ölçülür; sayfa bunun kaç proje olduğunu söyler. Servis hesapları listelenir ama kutulara girmez.

Geliştiriciler (/developers)

Bağlı bir depoya dokunan herkes (üyeler ve MR yazarları) proje başına eşitlenir; yalnızca geliştirici eşitlemesi açık projelerde (varsayılan kapalı). Her geliştiricinin profili (/developers/{id}) dokunduğu projeleri, yazdığı MR’ları ve ArchPilot tabanlı inceleme skorunu gösterir. Botlar sağlayıcı sinyallerinden tespit edilip servis hesabı olarak işaretlenir; işaret elle konup kaldırılabilir, elle konan işaret eşitlemede asla ezilmez.

Gerekenler

• MR Analizi, ısı haritası ve geliştiriciler için pull request erişimli bir Git kimlik bilgisi.
• Dağıtım sıklığı ve bekleme süresi için bir dağıtım kaynağı (Argo CD, Kubernetes, Flux).
• İş akışı için Jira; hatalı değişiklik oranı ve toparlanma süresi için Dynatrace ya da New Relic.
• AI Etkisi, operatörün tanımladığı kurulum AI sağlayıcısını gerektirir (AI); çalışma alanına ait anahtar yoktur.