İç otomasyon kapsamını takip eden bir web uygulaması nasıl tasarlanır ve inşa edilir: metrikler, veri modeli, entegrasyonlar, pano UX'i ve uyarılar.

Bir şeye başlamadan önce, kuruluşunuz içinde “otomasyon kapsamı”nın ne anlama geldiğini yazın. Aksi takdirde pano, farklı ekiplerin farklı yorumladığı alakasız sayıların karışımına dönüşür.
Ölçtüğünüz birimleri seçerek başlayın. Yaygın seçenekler:
v1 için birincil tanımı seçin, sonra ekleyebileceğiniz ikincil türleri not edin. Onay gerektiren "kısmen otomatik" adımlar gibi kenar durumlarda açık olun.
Farklı kitleler farklı sorular sorar:
5–10 “ön soru” yazın ve bunları ürün gereksinimi gibi ele alın.
Birincil çıktıları tanımlayın: görünürlük (ne var), önceliklendirme (sonra ne otomatikleştirilmeli), hesap verilebilirlik (kimin sorumluluğunda), ve trend takibi (iyileşiyor mu?).
v1 için net sınırlar koyun. Örnekler: “Henüz kaliteyi puanlamayacağız”, “Zaman tasarrufunu ölçmeyeceğiz”, veya “Sadece CI tabanlı testleri dahil edeceğiz, yerel script'ler değil.”
Son olarak, başarının neye benzeyeceğine karar verin: tutarlı benimseme (haftalık aktif kullanıcılar), yüksek veri tazeliği (ör. 24 saat içinde güncellemeler), daha az kör nokta (kritik sistemler için kapsam haritalaması) ve ölçülebilir takip (sahipler atandı ve boşluklar ay bazında azalıyor).
Otomasyon kapsamını ölçmeden önce, “otomasyon kanıtının” nerede olduğunu bilmeniz gerekir. Çoğu kuruluşta otomasyon, farklı zamanlarda ve farklı ekiplerce benimsenen araçlara dağınık halde yaşar.
Pragmatik bir envanterle başlayın: Hangi sinyaller bir etkinliğin otomatik olduğunu kanıtlar ve bunları nereden alabiliriz?
Tipik kaynaklar: CI pipeline'ları (build/test job'ları), test framework'leri (unit/integration/E2E sonuçları), iş akışı araçları (onaylar, deploy'lar, ticket geçişleri), runbook'lar (script'ler ve belgelenmiş prosedürler) ve RPA platformları. Her kaynak için daha sonra bağlayabileceğiniz bir tanımlayıcı yakalayın (repo, servis adı, environment, takım) ve saklayacağınız “kanıt”ı belirtin (job çalıştırması, test raporu, otomasyon kuralı, script yürütmesi).
Sonra, “ne olması gerektiğini” tanımlayan kayıt sistemlerinizi listeleyin: repo barındırma, issue tracker ve CMDB/servis kataloğu. Bu kaynaklar genellikle servislerin, sahiplerinin ve kritikliğinin otoriter listesini sağlar—kapsamı hesaplamak için aktivite saymaktan daha önemlidir.
Her kaynağı en az kırılgan alım yöntemiyle eşleştirin:
Rate limitler, kimlik doğrulama yöntemleri (PAT, OAuth, servis hesapları), saklama pencereleri ve bilinen veri kalitesi sorunlarını (yeniden adlandırılmış servisler, tutarsız isimlendirme, eksik sahipler) kaydedin.
Son olarak, her connector için (isteğe bağlı olarak her metrik için) kaynak güvenilirlik skoru planlayın; böylece kullanıcılar bir sayının “yüksek güven” mi yoksa “en iyi çaba” mı olduğunu görebilir. Bu, yanlış kesinlikten kaçınır ve connector geliştirmelerini önceliklendirir.
Faydalı bir kapsam panosu, neyi otomatikleştirmeyi amaçladığınızı ve gerçekte son zamanlarda çalışanın ayıran bir veri modeliyle başlar. Bunları karıştırırsanız, otomasyon bayat olsa bile rakamlar iyi görünebilir.
Bu yapı taşlarıyla başlayın:
Birincil raporlama düzeyini seçin ve buna sadık kalın:
Birden fazla görünümü sonra destekleyebilirsiniz, ancak ilk sürümünüzün bir “gerçek kaynak” seviyesi olmalı.
Refaktörlere dayanacak ID'ler kullanın:
Görüntüleme adlarını düzenlenebilir olarak ele alın, kimlik olarak değil.
Pratik bir desen:
Bu şablonla şu soruları yanıtlayabilirsiniz: “Ne kapsanmalı?”, “Ne bunu kapsadığını iddia ediyor?” ve “Gerçekte ne çalıştı?”.
Aşağıları yakalayın:
last_seen_at (asset hâlâ mevcut)\n- last_run_at, last_failure_at\n- last_reviewed_at (birinin iddiayı doğruladığı zaman)Tazelik alanları, tartışma olmadan "kapsanmış ama bayat" öğeleri vurgulamayı kolaylaştırır.
Kapsam metrikleri belirsizse her grafik tartışma konusu olur. Yönetici özetleri için bir ana metrik seçin, sonra takımlar için ayrıntılı kırılımlar ekleyin.
Çoğu kuruluş şu seçeneklerden birini tercih eder:
Yine de üçünü de gösterebilirsiniz, ama hangi metrik "başlık" olduğunu açıkça belirtin.
Takımların öğeleri tutarlı puanlaması için açık kurallar yazın:
Kuralları ölçülebilir yapın. İki kişi aynı öğeyi aynı şekilde puanlayamıyorsa tanımı netleştirin.
Risk, iş etkisi, çalışma sıklığı ve zaman tasarrufu gibi girdiler için küçük tamsayı skalaları (1–5) kullanın. Örnek: weight = risk + impact + frequency.
Bir öğeyi “otomatik” saymak için şu tür kanıtlar şart olsun:
Bu, kapsamı özbildirimden gözlemlenebilir bir sinyale çevirir.
Puanlama kurallarını ve örnekleri tek bir ortak sayfada toplayın (panodan bir bağlantı olarak). Tutarlı yorumlama, trendlerin güvenilir olmasını sağlar.
Bir dahili otomasyon kapsam uygulaması en iyi anlamda sıkıcı olmalı: işletmesi kolay, değişiklik yapması kolay ve sayıların nereden geldiği konusunda şeffaf. Genellikle basit bir “API + veritabanı + pano” yapısı, gerçekten ihtiyaç duyulana kadar dağıtık bir sistemden daha iyidir.
Ekip zaten destekliyorsa onu seçin. Yaygın bir temel şuna benzer:
İlk dahili sürümde daha hızlı ilerlemek isterseniz, bir "hızlı kodlama" yaklaşımı işe yarayabilir: örneğin Koder.ai, yapılandırılmış bir spesifikasyondan bir React pano ile Go + PostgreSQL backend üretebilir; ekip sohbetle yinelemeye devam ederken tam kaynak kodu dışa aktarımı ve geleneksel dağıtımı korur.
Basit bir sistemde bile sorumlulukları ayırın:
Temel varlıklar (takımlar, servisler, otomasyonlar, kanıtlar, sahipler) için ilişkisel tablolar kullanın. Trendler (zaman içindeki çalıştırmalar, haftalık kapsama) için ya:
kullanın.
Birden fazla takım uygulamayı paylaşacaksa erken org_id/team_id alanları ekleyin. Bu, izinleri sağlar ve liderlik “tek bir pano ama segmentlenmiş” istediğinde acı verici göçleri önler.
dev/staging/prod çalıştırın ve verinin nasıl hareket edeceğini tanımlayın:
Arayüzü gezinmeyi kolay hale getirmek için daha fazla bilgi almak isterseniz, bkz. /blog/design-dashboard-ux.
Bir kapsam panosu hızlıca bir "gerçek kaynağı" haline gelir; bu yüzden erişim kontrolü ve veri işleme grafiklerden en az önemli hale gelir. Basit başlayın, ama güvenliğin daha katı hale gelebilmesi için yeniden yazmayı gerekli kılmayacak şekilde tasarlayın.
Şirketiniz zaten SSO'ya sahipse, baştan buna entegre olun (OIDC genellikle en kolay; SAML büyük kuruluşlarda yaygın). Hızlı bir dahili lansman gerekiyorsa, kimlik başlıkları enjekte eden mevcut bir iç auth proxy'nin arkasında başlamak kabul edilebilir; sonra natif SSO'ya geçin.
Hangi yolu seçerseniz seçin, kimliği kalıcı bir kullanıcı anahtarına (email değişebilir) normalize edin. Minimum bir kullanıcı profili saklayın ve grup/takım üyeliğini talep edildiğinde alın.
Küçük bir rol kümesi tanımlayın ve yetkilendirmeyi UI ile API'de tutarlı kılın:
Scope bazlı izinleri (takım/servis) "süper kullanıcı" yerine tercih edin; riskleri azaltır ve darboğazları önler.
Kapsam kanıtları genellikle CI loglarına, olay ticket'larına veya dahili dokümanlara bağlantılar içerir. Bu URL'lere ve ham loglara erişimi kısıtlayın. Doğrulama için ihtiyacınız olanı saklayın (ör. build ID, zaman damgası, kısa durum özeti) tam logu veritabanına kopyalamayın.
Kapsam iddialarına veya meta verilere yapılan her manuel düzenleme bir denetim kaydı oluşturmalı: kim neyi ne zaman ve neden değiştirdi (serbest metin neden). Son olarak, çalışma geçmişi ve kanıt için bir saklama politikası belirleyin—ne kadar süreyle saklanacağı ve eski kayıtların mevcut kapsam hesaplamalarını bozmadan güvenli şekilde nasıl silineceğini tanımlayın.
Bir kapsam panosu, bir kişinin üç soruyu bir dakikadan kısa sürede cevaplayabildiğinde başarır: Durumumuz nasıl? Ne değişiyor? Sırada ne var? UX'i bu kararlara göre değil, veri kaynaklarına göre değil tasarlayın.
İlk ekranı basit bir genel görünüm yapın:
Etiketleri düz dille tutun (“Yakın zamanda otomatik” "kanıt tazeliği" yerine), teknik durumları yorumlama zorunluluğu yaratmayın.
Her genel metrikten kullanıcıların bir servis/süreç sayfasına tıklayarak “ne” ve “ne tarafından” sorularına cevap bulmasını sağlayın:
Her satır/kart, sayının arkasındaki “neden”i içermeli: kanıt bağlantısı, sahip, son çalışma durumu ve açık bir sonraki eylem (“job'u tekrar çalıştır”, “sahip ata”, “eksik kanıt ekle”).
Kuruluşun çalışma biçimine uyan filtreler sunun:
Filtre durumunu görünür ve paylaşılabilir (URL parametreleri) tutun, böylece biri "Prod + Tier-1 + son 14 gün" gibi bir bağlantıyı kolayca paylaşabilir.
Uzun dökümanlar yerine satır içi tanımlar kullanın:
Entegrasyonlar, kapsam uygulamanızın işe yaramasını sağlar. Amaç, CI veya test araçlarının her özelliğini yansıtmak değil—çalışan, ne zaman çalıştığı, neyi kapsadığı ve kimin sahibi olduğu gibi tutarlı gerçekleri çıkarmaktır.
Öncelikle otomasyon sinyali üreten sistemlerle başlayın: CI (GitHub Actions, GitLab CI, Jenkins), test çalıştırıcılar (JUnit, pytest) ve kalite araçları (coverage raporları, linters, security taramaları).
Bir konektör minimum uygun yükü almalı (veya webhook ile almalı):
Konektörleri idempotent yapın: tekrarlanan çekmeler çoğalma yaratmamalı.
Bazı kapsam boşlukları kasıtlıdır (miras sistemler, üçüncü taraf kısıtları, askıya alınmış girişimler). Hafif bir “istisna” kaydı sağlayın ve bunun için gerekli olsun:
Bu, kalıcı kör noktaları önler ve liderlik görünümünü doğru tutar.
Farklı kaynaklar nadiren aynı isimlendirmeyi kullanır: biri “payments-service”, diğeri “payments” veya repo slug kullanabilir.
Normalizasyon kuralları oluşturun erken:
Çünkü her downstream metrik buna bağımlıdır.
service_aliases, repo_aliases gibi alias tabloları getirin; bunlar birçok dış adı tek bir kanonik varlığa eşler. Yeni veri geldiğinde önce kanonik ID'ye, sonra alias'lara eşleştirin.
Eğer yeni ad eşleşmezse, yönetici onayına sunulmak üzere birleştirme önerileri (örn. “payments-api” “payments-service” gibi görünüyor) üretin.
Her kaynağın en son çalışma zaman damgasını kontrol eden periyodik bir iş planlayın ve bayat olanları işaretleyin (örn. 7 günde CI çalışması yok). Bunu UI'da gösterin ki düşük kapsam eksik veriden kaynaklanmasın.
Bir pano faydalıdır, ancak uyarılar ve hafif iş akışları ilginç veriyi sürekli iyileştirmeye dönüştürür. Amaç basit: doğru zamanda doğru kişiyi, eylem için yeterli bağlamla bilgilendirmek.
Küçük ama yüksek sinyalli bir uyarı setiyle başlayın:
Her uyarı ilgili drill-down görünümüne doğrudan bağlantı içermeli (ör. /services/payments?tab=coverage veya /teams/platform?tab=owners) ki insanlar arama yapmak zorunda kalmasın.
Tek beden herkese uyan eşiklerden kaçının. Takımların şu gibi kurallar belirlemesine izin verin:
Bu, sinyallerin anlamlı kalmasını ve uyarı yorgunluğunu azaltır.
Uyarıları mevcut kanallara (email, Slack) gönderin; içerikte: ne değişti, neden önemli ve sahibi olsun. Gerçek zamanlı uyarıların yanında bir haftalık özet ekleyin:
Uyarıları görev gibi ele alın: onaylama, atanma ve durum (aç/triage/çözüldü) imkanları verin. Kısa bir yorum izi (“PR #1234 ile düzeltildi”) raporlamayı güvenilir kılar ve aynı sorunların sessizce tekrar ortaya çıkmasını engeller.
Bir izleme panosu hızlı hissettirir çünkü API, UI'nin gerçekten sorduğu soruları yanıtlar—tarayıcının onlarca çağrıyı birleştirmesini gerektirmez. İlk olarak minimal, pano-odaklı bir API yüzeyiyle başlayın, sonra pahalı olanları önceden hesaplayan arka plan işlerini ekleyin.
İlk sürümü temel ekranlara odaklayın:
GET /api/services (takım, dil, seviye gibi filtreler)\n- Kapsam özeti: GET /api/services/{id}/coverage (genel skor + ana kırılımlar)\n- Kanıt çalıştırmaları: GET /api/services/{id}/evidence?status=passed&since=...\n- Meta güncelleme (sahip, etiket, durum): PATCH /api/services/{id}Yanıtları pano için anında render edilecek şekilde tasarlayın: service adı, sahip, son kanıt zamanı ve mevcut skor gibi bilgileri tek bir payload içinde verin; ekstra lookup zorunlu kılmayın.
Listeler ve detay tablolar hep sayfalı olsun (limit + cursor). Sık kullanılan endpoint'ler için API katmanında (veya paylaşılan bir cache'te) filtreler ve çağıranın erişim kapsamına göre anahtarlanmış önbellekleme ekleyin.
Büyük kanıt taraması gerektiren sorgular (örn. “takım bazında kapsam”) için gecelik rollup'lar önceden hesaplayın. Rollup'ları ayrı bir tabloda veya materialized view'da saklayın ki okumalar basit ve öngörülebilir olsun.
Trendler, günlük anlık görüntüler saklandığında en kolayıdır:
GET /api/services/{id}/trend?days=90 gibi endpoint'ler sunar.Anlık görüntüler, tarihsel metrikleri her sayfa yüklemesinde yeniden hesaplamaktan kaçınır ve “tazelik”i kolayca çizelgelemeyi sağlar.
Toplu onboarding için:
POST /api/import/services (CSV yükleme)\n- GET /api/export/services.csvYazma zamanında doğrulama kuralları uygulayın: gerekli sahip, izin verilen durum değerleri ve mantıklı zaman damgaları (gelecek tarihli kanıtları reddet). Kötü veriyi erken reddetmek, özellikle rollup'lar tutarlı girdilere bağlı olduğunda ilerideki kafa karışıklığını önler.
Bir kapsam panosu yalnızca insanlar ona güvenirse faydalıdır. Dağıtım ve operasyonu ürünün bir parçası olarak ele alın: öngörülebilir sürümler, net sağlık sinyalleri ve bir şey bozulduğunda basit kurtarma.
Bir dahili uygulama için düşük yük ve hızlı yineleme hedefleyin.
Koder.ai gibi bir platform kullanıyorsanız, kaynak-kod dışa aktarımı ve dağıtım/host iş akışlarından erken yararlanın, böylece uygulamanız standart promote, review ve rollback uygulamalarını takip eder.
Güvenilir sinyaller almak için karmaşık bir yığına gerek yok:
Otomatik veritabanı yedekleri ve uygun bir saklama politikası kurun.
Runbook'ları dokümante edin:
Biraz operasyon disiplini, kapsamın tahmine dayalı hale gelmesini engeller.
Bir izleme uygulaması ancak ekipler ona güvenip kullanırsa yardımcı olur. Yayılımı bir ürün lansmanı gibi ele alın: küçük başlayın, net sahiplik tanımlayın ve düzenli güncelleme ritmi oluşturun.
Onboarding hafif ve tekrarlanabilir olsun:
İyi bir hedef: “ilk pano görünümü 30 dakika içinde” olsun; haftalar süren bir yapılandırma projesi olmasın.
İki ritim oluşturun:
Kurallar beklenmedik şekilde değişirse kapsam puanları siyasi hale gelir. Küçük bir yönetişim grubu (genellikle Eng Productivity + Security/Quality) tanımlayın; bu grup:
Değişiklikleri basit bir değişiklik günlüğünde yayınlayın (ör. /docs/scoring-changelog).
Benimsemeyi şu metriklerle ölçün: aktif kullanıcılar, izlenen servisler ve tazelik uyumu (güncel kanıta sahip servis sayısı). Bu metrikleri yinelemeyi yönlendirmek için kullanın: daha iyi ağırlıklandırma, daha zengin kanıt türleri ve ek konektörler—her zaman ekiplerin manuel işini azaltan geliştirmeleri önceliklendirin.
Eğer iç öğrenimlerinizi kamuya da paylaşmaya karar verirseniz, geliştirme notlarınızı ve şablonlarınızı standartlaştırmayı düşünün: Koder.ai kullanan ekipler, geliştirme iş akışları hakkında içerik oluşturarak veya başkalarını yönlendirerek kredi kazanabilir; bu, dahili araçlara devamlı yatırım için fon sağlayabilir.
Otomasyon kapsamı, kuruluşunuzun "otomatik olarak yapılan iş" ile manuel olan arasındaki ölçüm şeklinde tanımladığı şeydir. Karışıklığı önlemek için v1'de birincil bir ölçüm birimi seçin (örneğin: süreçler, gereksinimler/kontroller, test takımları veya runbook'lar) ve onay gerektiren "kısmen otomatik" adımlar gibi kenar durumlar için net kurallar yazın.
İyi bir tanım, iki kişinin aynı öğeyi aynı şekilde puanlayacağı bir tanımdır.
Kullanıcıların yanıtlaması gereken 5–10 ana soruyu yazarak başlayın; bunları ürün gereksinimi gibi ele alın. Yaygın örnekler:
Farklı kitleler (QA, Operasyon, liderlik) farklı bakış açılarına ihtiyaç duyar; v1'in hangi kitleye öncelik vereceğini belirleyin.
Otomasyonun “kanıt” olarak kabul edildiği kaynakları ve "ne olması gerektiğini" tanımlayan yetkili kayıt sistemlerini envanterleyin.
Bir kayıt sistemi olmadan yalnızca aktiviteyi sayabilirsiniz; tam hedef kümesini bilmeden kapsamı güvenilir şekilde hesaplayamazsınız.
Her kaynağa göre en az kırılgan yöntemi seçin:
Ayrıca connector kısıtlarını (rate limit, kimlik doğrulama, saklama penceresi) belgeleyin ki kullanıcılar veri tazeliğini ve güvenirliğini anlayabilsin.
Metrikleri yanıltıcı olmaktan korumak için niyeti, iddiaları ve kanıtı ayırın.
Pratik bir model:
“Kağıt üstünde kapsam”u önlemek için tazelik zaman damgalarını ve kanıt kurallarını kullanın.
Yaygın alanlar:
last_seen_at (varlık hâlâ mevcut)last_run_at, last_failure_atlast_reviewed_at (birinin iddiayı doğruladığı zaman)Sonra şöyle bir kural uygulayın: "Son 30 günde N başarılı çalıştırma varsa otomatik sayılır." Bu, "var" olmayı "son zamanlarda çalışıyor" olmaktan ayırır.
Bir ana gösterge metriği seçin ve puanlama kurallarını açıkça yazın.
Yaygın başlık seçenekleri:
Ağırlıkları basit tutun (örneğin 1–5) ve "otomatik / kısmen otomatik / manuel" tanımlarını somut örneklerle belgelendirin.
Adları erken normalleştirin ve yeniden adlandırmalar/çoğalmalar için açık yollar sağlayın.
Pratik adımlar:
service_aliases, repo_aliases gibi alias tablolar ekleyin.Bu, aynı verinin birden çok kez sayılmasını ve ekip yeniden yapılandırdığında tarihsel trendlerin bozulmasını engeller.
Mümkünse SSO (OIDC/SAML) ile başlayın; hızlı bir iç lansman gerekiyorsa kimlik başlıkları enjekte eden bir auth proxy arkasında başlamak kabul edilebilir. Küçük bir rol seti tanımlayın ve yetkilendirmeyi UI ile API'de tutarlı hale getirin:
Hassas kanıtları dikkatle yönetin: tam logları kopyalamak yerine build ID, zaman damgası ve kısa bir durum özeti saklayın. Manuel düzenlemeler için kim/ne/nerede/neden şeklinde bir denetim kaydı tutun ve çalıştırma geçmişi için saklama politikası belirleyin.
Uyarıları eyleme dönüştürülebilir yapın ve küresel gürültüden kaçının.
Yüksek sinyalli uyarı tipleri:
Eşikleri takım/servis bazında ayarlamaya izin verin (farklı "eskime" pencereleri ve paging kuralları). Uyarılar ilgili drill-down sayfasına derin bağlantı içermeli ve onaylama/atanma/durum (aç/triage/çözüldü) desteklenmelidir ki işler kapansın.
Ayrıca sahiplik (takım/kişi) ve kalıcı kimlikler ekleyin ki yeniden adlandırmalar geçmişi bozmasın.