CLI verisini kişi bazına indirmek neden önemli?
Bir organizasyonda Copilot kullanımını izlemek, açık konuşayım, sadece “kaç kişi kullandı” sorusuyla bitmiyor. Asıl mesele, kimin gerçekten komut satırında çalıştığını, kimin henüz o tarafa geçmediğini ve hangi ekiplerin biraz dürtülmeye ihtiyaç duyduğunu görmekte. GitHub’ın bu güncellemesi tam da buraya dokunuyor; artık organization report içinde kişi bazında CLI aktivitesi çıkıyor. Güzel haber.
Yani, Ben bunu ilk okuduğumda aklıma hemen 2024’te bir finans müşterisinde yaptığımız Copilot yayılımı geldi. Ekiplerin yarısı VS Code tarafında rahattı ama terminal tarafında resmen sessizdi. O zaman elimizde per-user CLI görünürlüğü olsaydı, enablement oturumlarını çok daha nokta atışı planlardık. Hani bazı raporlar vardır ya, bakınca hoş durur ama iş görmez; bu öyle değil. Bu özellik baya iş görüyor.
Aslında mesele biraz da yönetim meselesi. Enterprise’da araç dağıtmak kolay; zor olan, o aracın nerede yaşadığını görmek. GitHub Copilot CLI için gelen bu per-user kırılım, admin’e şu üç şeyi aynı anda veriyor: kullanım sinyali, tüketim paterni ve sürüm dağılımı. Yani hem teknik tarafta hem operasyonel tarafta elinizi rahatlatıyor (bizzat test ettim). Sade ama etkili.
Yeni raporda neler var?
GitHub bu sürümle organization seviyesindeki CLI metriklerini tamamlamış oldu. Daha önce enterprise-level, user-level ve organization-level metrikler vardı; şimdi organisation report içinde kullanıcı bazlı detay da geliyor. Hele bir de de 1 günlük ve 28 günlük raporlar üzerinden bakabilmek güzel olmuş. Çünkü bazı kullanımlar günlük patlıyor ama ay ortalamasına vurunca kayboluyor… işte o boşluğu kapatıyor.
| Gösterge | Ne anlatıyor? | Neden önemli? |
|---|---|---|
used_cli |
Kullanıcının CLI aktivitesi olup olmadığını gösteriyor | Kim aktif, kim değil hemen anlaşılıyor |
| Sessiyon sayısı | Kaç oturum açılmış | Benimsenme seviyesini ölçüyor |
| Istek sayısı | Kullanıcı başına kaç istek atılmış | Gerçek kullanım yoğunluğunu veriyor |
| Tüketilen token miktarı | Maliyet ve kapasite planlama için kritik | |
| İşin ne kadar “ağır” yürüdüğünü gösteriyor | Anomali yakalamaya yardım ediyor | |
| Son bilinen CLI versiyonu | Kullanıcının hangi sürümde kaldığını gösteriyor | Sürüm farkını hızlıca yakalatıyor |
Bence en değerli satır son bilinen sürüm bilgisi. Çünkü kurumsalda asıl dertlerden biri upgrade rollout’tür. Bir ekip yeni sürüme geçer, diğer ekip eski sürümde kalır, sonra bir bakarsınız destek konusu uzamış… Ben bunu 2023’te bir telekom projesinde yaşadım; PowerShell ve otomasyon araçlarında sürüm farkı yüzünden üç hafta boyunca gereksiz alarm topladık. Aynı hikâye burada da yaşanabilir, hatta bazen daha sessiz olur. Azure ile Spring Testlerinde Docker Kullanınca Ne Değişiyor? yazımızda bu konuya da değinmiştik.
Sahada bana ne anlattı?
Küçük ekipte olay daha basit
Küçük bir startup ortamında bu tür raporlar genelde hızlı aksiyon aldırır. Mesela beş geliştiricili bir ekipte bir kişi CLI’yi sık kullanıyorsa ve diğerleri hiç dokunmuyorsa, konu teknoloji eksikliği değil çoğu zaman alışkanlık oluyor. Ben geçen yıl İzmir’deki küçük bir SaaS ekibine danışmanlık verirken benzer bir tablo gördüm; terminalden çalışan iki kişi tüm avantajı topluyordu, geri kalan ekip işe GUI tarafında oyalanıyordu. Bu konuyla ilgili PowerShell 7.6 Neden Geç Geldi? Perde Arkası ve Dersler yazımıza da göz atmanızı tavsiye ederim.
Ve işler burada ilginçleşiyor. Bu konuyla ilgili GitHub Codespaces’ta Veri Yerleşimi: Kurumsalda Ne Değişti? yazımıza da göz atmanızı tavsiye ederim.
Böyle durumlarda per-user görünürlük çok işe yarıyor çünkü eğitim ihtiyacını netleştiriyorsunuz. Kimseyi suçlamadan, “bak şimdi” diyorsunuz; şu gruba kısa bir demo lazım, şu gruba da biraz kullanım senaryosu göstermek yeterli olabilir. Basit gibi duruyor ama sahada fark yaratıyor. GitHub’da Açık Kaynak Tedarik Zincirini Korumak: Benim Sahada Gördüklerim yazımızda bu konuya da değinmiştik.
Enterprise’da işe başka dertler çıkıyor
Büyük organizasyonda konu biraz daha çetrefilli oluyor (inanın bana). Bir bankacılık projesinde Logosoft tarafında yürüttüğümüz çalışma sırasında şunu net gördük: bazı ekipler Copilot’u deniyor ama standardize etmiyor. Kimisi legacy branch üzerinde kalıyor, kimisi yeni version’a geçmemiş oluyor, kimisi de güvenlik politikası nedeniyle çekingen davranıyor. Bu konuyla ilgili Python Eklentisinde Mart 2026: Hız, Arama ve Küçük Sürprizler yazımıza da göz atmanızı tavsiye ederim.
E tabii burada iş sadece adoption değil; yönetişim de devreye giriyor (şaşırtıcı ama gerçek). Per-user session count ile token tüketimi birlikte bakıldığında hangi takımın gerçek yoğunluk yarattığı görülüyor. FinOps açısından bu çok kıymetli çünkü lisans veya tüketim kararlarını havadan vermiyorsunuz artık.
Kurumsalda iyi ölçülmeyen şey yönetilemez hâle gelir. CLI aktivitesini kullanıcı bazında görmek de tam olarak bunun önüne geçiyor.
Sürüm dağılımı niye kritik hâle geldi?
Şimdi gelelim en pratik tarafa: last known CLI version bilgisi neden önemli? Çünkü tooling dünyasında eski sürüm çoğu zaman sessiz sorun demek. Çalışıyor gibi görünür ama yeni feature yoktur, telemetry eksik olur ya da policy uyumsuzluğu çıkar. AZ-500 hazırlığı yaparken buna çok kafa yormuştum; güvenlik kadar envanterin güncel olması da önemliydi.
Bir arkadaşım Ankara’da orta ölçekli bir yazılım evinde benzer şekilde rollout yaptıktan sonra fark etti ki geliştiricilerin yaklaşık üçte biri güncelleme almamıştı bile… Sebep basitmiş: otomatik kurulum script’i bir düşüneyim… macOS makinelere ulaşmamış bileydi sanırım? Neyse, detay orada saklanıyordu. Ufak gibi görünen şey bütün resmî bozabiliyor.
- Aynı komutu farklı sürümlerde çalıştırınca davranış değişebilir.
- Ekiplerin destek yükü artar.
- Saha geri bildirimi sağlıklı olmaz çünkü herkes aynı zeminde değildir.
Maliyet ve enablement tarafında nasıl okunmalı?Bence bu raporu sadece teknik ekip okumamalı; platform ekibiyle birlikte FinOps ya da operasyon ekibi de bakmalı.
Token toplamları ile average tokens per request birleşince garip desenleri yakalayabiliyorsunuz.
Mesela bir kullanıcı az istek atıp aşırı token tüketiyorsa orada büyük prompt’lar ya da yanlış kullanım olabilir.
Peki neden? Çünkü sayı tek başına pek konuşmaz; yan yana gelince laf açılıyor.
Açık konuşayım,
ben böyle metriklerde çoğu zaman iki uç ararım:
biri fazla iyimser yorumdur,
diğeri gereksiz paniktir.
Bu veri ikisini de törpülüyor ama sihir değil tabii…
hâlâ yorum gerekiyor (ve insan gözü).
Geçen ay Dublin’de görüştüğümüz bir enterprise müşteride bunu dashboard’a koyduk;
ilk hafta herkes heyecanlandı ama ikinci hafta asıl sorunun eğitim olduğu ortaya çıktı.
Tam da öyle.
# Basit yorumlama yaklaşımı
if used_cli and avg_tokens_per_request > threshold:
flag = "Yüksek yogunluk"
elif not used_cli:
flag = "Enablement adayi"
else:
flag = "Normal"
Bana göre en iyi kullanım şekli ne?Neyse uzatmayalım:
bu metriği tek başına KPI yapmayın derim.
En iyi senaryo şöyle olur:
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
- Kullanıcı bazlı adoption haritası çıkarın.
- Sürüm dağılımını haftalık takip edin.
- Lisans veya pilot genişletmesini buna göre planlayın.
- Düşük kullanım görülen takımlara kısa demo ve örnek komut seti verin.
Yani, Ben olsam özellikle DevOps. Platform mühendisliği ekiplerini ayrı değerlendiririm çünkü onların CLI kullanımı ile ürün geliştirme ekibinin kullanımı aynı olmayabiliyor.
Bir dakika,
şunu da ekleyeyim:
eğer org içinde güvenlik veya compliance baskısı varsa session ve request sayılarını tek başına iyi-kötü diye okumayın;
bağlam şarttır.
Mesela bazı ekipler intentionally düşük kullanır çünkü hassas repolarda dikkatlidirler…
Bu kadar mı?
Değil tabii,
ama ana fikir burada zaten belli oluyor.
Yukarıda bahsettiğim o olay var ya,
işte onun çözümü biraz buradan geçiyor.
Siz ne dersiniz?
Denediniz mi hiç?
Burada gözden kaçırılmaması gereken eksiklerBütün güzelliğine rağmen birkaç eksik de var gibi duruyor.
İlk olarak raporların içgörüsü güçlü ama açıklama katmanı hâlâ ham hissediliyor olabilir;
yani veri var ama yorumu sizin yapmanız gerekiyor.
İkinci olarak benim beklentim biraz daha ileri seviye segmentasyondu — departman bazlı kırılım gibi.
Üçüncü olarak büyük organizasyonda veri hacmi artınca dashboard’ın sade kalması zorlaşabilir.
Bu konuda %100 emin değilim ama sanırım GitHub ileride bunu role-based ya da team-based kırılımlarla daha zengin hâle getirecek…
Sıkça Sorulan Sorular
Pergpective? GitHub Copilot CLI usage metrics per-user olarak kimler için açık?Organization admin’ler için açık görünüyor. Admin’ler hem bireysel aktiviteyi hem de toplu raporları inceleyebiliyor.”
`used_cli` alanı tam olarak neyi gösterir?`used_cli`, ilgili kullanıcının CLI aktivitesi olup olmadığını belirtir.” Eğer false işe kullanıcı o rapor aralığında terminal tarafında aktif görünmüyordur.”
Kişi bazlı metrikler maliyet takibine yardım eder mi?Evet, eder. Mesela session count. Token usage birlikte okunursa takım veya kullanıcı bazındaki tüketim desenleri daha net görülür.”
Sürüm bilgisini niye takip etmeliyim?Eh, Cünkü eski sürümler hem uyumluluk hem de rollout planlama açısından risk yaratabilir.” Son bilinen versiyon bilgisiyle hangi ekiplerin güncel kalmadığını hızlıca görürsünüz.”
Kaynaklar ve İleri Okuma
Kişi bazlı metrikler maliyet takibine yardım eder mi?Evet, eder. Mesela session count. Token usage birlikte okunursa takım veya kullanıcı bazındaki tüketim desenleri daha net görülür.”
Sürüm bilgisini niye takip etmeliyim?Eh, Cünkü eski sürümler hem uyumluluk hem de rollout planlama açısından risk yaratabilir.” Son bilinen versiyon bilgisiyle hangi ekiplerin güncel kalmadığını hızlıca görürsünüz.”
Kaynaklar ve İleri Okuma
Kaynaklar ve İleri Okuma
“
İçeriği paylaş:
İlgili Yazılar
📬 Bu yazıyı faydalı buldunuz mu?
Azure, DevOps ve bulut teknolojileri hakkında güncel içerikler için beni takip edin!
Yorum gönder