Claude Code ile log araması, özellik geçişleri ve veri kontrollerini çözmek için en az ayrıcalık ilkesini ve net güvenlik sınırlarını uygulayan dahili geliştirici araçları oluşturun.
logs search --service api --since 30m --text \"timeout\", sonuçlar için katı bir üst sınır ve net bir “erişim yok” mesajı ile.\n\n### Doğrulayabileceğiniz küçük artışlar isteyin\n\nÖnce bir iskelet isteyin: CLI bağlantısı, konfigürasyon yükleme ve stub'lanmış veri çağrısı. Sonra tam olarak bir özelliği tamamlanmış olarak isteyin (doğrulama ve hatalar dahil). Küçük diff'ler incelemeyi gerçek kılar.\n\nHer değişiklikten sonra ne değiştiğini ve nedenini yalın dille açıklamasını isteyin. Açıklama diff ile uyuşmuyorsa, durun ve davranışı ile güvenlik kısıtlarını yeniden ifade edin.\n\nDaha fazla özellik eklemeden önce testleri erken oluşturun. En azından mutlu yol, geçersiz girdiler (hatalı tarihler, eksik bayraklar), izin reddi, boş sonuç ve hız limiti veya arka uç zaman aşımı durumlarını kapsayın.\n\n## CLI vs web panosu: doğru arayüzü seçmek\n\nCLI ve dahili web panosu aynı problemi çözebilir, ama farklı şekillerde başarısız olurlar. Güvenli yolu en kolay yol yapan arayüzü seçin.\n\nCLI genelde hız önemliyken ve kullanıcı ne istediğini zaten bildiğinde en iyisidir. Ayrıca okuma işi akışına iyi uyar çünkü izinleri dar tutabilir ve kazara yazma eylemlerini tetikleyen butonlardan kaçınabilirsiniz.\n\nCLI, on-call sırasında hızlı sorgular, scriptler ve otomasyon, açık denetim izleri (her komut net olarak yazılır) ve düşük dağıtım yükü (tek bir binary, tek bir konfig) için güçlü bir tercihtir.\n\nWeb panosu ise paylaşılan görünürlük veya rehberli adımlar gerektiğinde daha iyidir. İnsanları zaman aralıkları, ortamlar ve önceden onaylanmış eylemler gibi güvenli varsayılanlara yönlendirerek hataları azaltabilir. Panolar takım çapında durum görünümleri, onay gerektiren korunmuş eylemler ve bir butonun ne yaptığını açıklayan yerleşik açıklamalar için de iyidir.\n\nMümkünse her ikisi için aynı backend API'yi kullanın. Kimlik doğrulama, hız limitleri, sorgu limitleri ve denetim kaydı o API'de olsun, UI'da değil. Böylece CLI ve pano farklı ergonomilere sahip istemciler olur.\n\nAyrıca nerede çalıştığına karar verin; çünkü bu riski değiştirir. Dizüstünde çalışan bir CLI token sızdırabilir. Bunu bir bastion hostta veya dahili bir kümede çalıştırmak maruz kalmayı azaltabilir ve loglama ile politika uygulamalarını kolaylaştırır.\n\nÖrnek: log arama için, on-call mühendisi son 10 dakikayı bir servis için çekiyorsa CLI harikadır. Bir olay odasında herkesin aynı filtrelenmiş görünümüne ihtiyaç varsa ve “postmortem için dışa aktar” gibi önceden onaylı bir eylem gerekiyorsa, pano daha iyidir.\n\n## Gerçekçi bir örnek: on-call için log arama aracı\n\nSaat 02:10 ve on-call bir rapor alır: “Pay tıklayınca bazen bir müşteri için başarısız oluyor.” Destek bir request ID içeren ekran görüntüsü göndermiş ama kimse log sistemine rastgele sorgular yapıp admin izinlerini kullanmak istemez.\n\nKüçük bir CLI bunu güvenli şekilde çözebilir. Anahtar, kapsamı dar tutmaktır: hatayı hızlıca bulmak, yalnızca gerekeni göstermek ve üretim verilerini değiştirmemek.\n\n### Minimal bir CLI akışı\n\nZaman sınırlarını zorlayan ve belirli bir tanımlayıcı gerektiren tek bir komutla başlayın. Bir request ID ve bir zaman penceresi zorunlu kılın, kısa bir pencere varsayılan olsun.\n\nbash\noncall-logs search --request-id req_123 --since 30m --until now\n\n\nÖnce bir özet döndürün: servis adı, hata sınıfı, sayım ve en iyi 3 eşleşen mesaj. Sonra kullanıcı açıkça genişletme istediğinde yalnızca o zaman tam log satırlarını yazdıran bir genişletme adımı sunun.\n\nbash\noncall-logs show --request-id req_123 --limit 20\n\n\nBu iki adımlı tasarım kazara veri dökümlerini önler. Ayrıca aracın güvenli-öncelikli bir yolu olduğu için incelemeleri de kolaylaştırır.\n\n### İsteğe bağlı takip eylemi (yazma yok)\n\nOn-call genellikle bir sonraki kişi için bir iz bırakmak ister. Veritabanına yazmak yerine, ticket notu yükü oluşturan veya olay sisteminde bir etiket uygulayan isteğe bağlı bir eylem ekleyin, ama asla müşteri kayıtlarına dokunmayın.\n\nEn az ayrıcalık için CLI salt-okunur bir log tokenı kullanmalı ve ticket veya etiket eylemi için ayrı, kapsamlı bir token olmalı.\n\nHer çalıştırma için bir denetim kaydı saklayın: kim çalıştırdı, hangi request ID, hangi zaman sınırları kullanıldı ve ayrıntılar genişletildi mi. Bu denetim kaydı bir şey ters gittiğinde veya erişim incelenmesi gerektiğinde güvenlik ağınızdır.\n\n## Güvenlik ve güvenilirlik sorunlarına yol açan yaygın hatalar\n\nKüçük dahili araçlar genellikle “sadece hızlı bir yardımcı” olarak başlar. İşte tam bu yüzden tehlikeli varsayılanlarla sonuçlanırlar. Güveni kaybetmenin en hızlı yolu bir kötü olaydır; örneğin bir aracın read-only olması gerekirken veri silmesi.\n\nEn sık görülen hatalar:\n\n- Araç sadece okumaya ihtiyaç duyduğu halde üretim veritabanına yazma erişimi verme ve sonra "dikkatli oluruz" varsayımı\n- Denetim izi atlanması, böylece sonradan kimin komut çalıştırdığını, hangi girdileri kullandığını ve neyin değiştiğini cevaplayamama\n- Serbest form SQL, regex veya ad-hoc filtrelere izin verip istemeden büyük tabloları veya logları tarayıp sistemleri çökertme\n\n- Ortamları karıştırmak; staging eylemlerinin production'a ulaşması çünkü konfigler, tokenlar veya base URL'ler paylaşılmış\n\n- Terminale, tarayıcı konsoluna veya loglara sır basmak ve sonra bu çıktının ticket ve sohbete kopyalandığını unutmak\n\nGerçekçi bir başarısızlık şöyle görünür: bir on-call mühendisi bir olay sırasında log-search CLI'sini kullanır. Araç herhangi bir regex kabul eder ve bunu log altyapısına gönderir. Pahalı bir desen saatlerce yüksek hacimli loglar üzerinde çalışır, maliyetleri fırlatır ve aramaları yavaşlatır. Aynı oturumda CLI debug çıktısında bir API tokenı yazdırır ve bu token kamuya açık bir olay dokümanına yapıştırılır.\n\n### Çoğu olayı önleyen daha güvenli varsayılanlar\n\nSalt-okunuru gerçek bir güvenlik sınırı olarak ele alın, bir alışkanlık değil. Ortam başına ayrı kimlik bilgileri kullanın ve her araç için ayrı servis hesapları oluşturun.\n\nBirkaç koruyucu çoğu işi yapar:\n\n- Ham SQL yerine izin verilen sorgular (veya şablonlar) kullanın, zaman aralıklarını ve satır sayılarını sınırlandırın\n- Her eylemi istek ID'si, kullanıcı kimliği, hedef ortam ve tam parametrelerle loglayın\n- Ortam seçimini zorunlu kılın, üretim için yüksek sesli onay gerektirin\n- Varsayılan olarak sırları kırpın ve debug çıktısını ayrıcalıklı bir bayrak olmadıkça devre dışı bırakın\n\nAracın tehlikeli bir şeyi tasarımsal olarak yapamaması durumunda, ekibiniz 03:00'te mükemmel dikkat beklemek zorunda kalmaz.\n\n## Aracı yayınlamadan önce hızlı kontrol listesi\n\nDahili aracınız gerçek kullanıcılara ulaşmadan (özellikle on-call için) önce onu bir üretim sistemi gibi ele alın. Erişim, izinler ve güvenlik sınırlarının gerçek olduğundan, ima edilmediğinden emin olun.\n\nErişim ve izinlerle başlayın. Birçok kaza "geçici" erişim kalıcı hale geldiği veya bir aracın zaman içinde sessizce yazma gücü kazandığı için olur.\n\n- Kimlik doğrulama ve offboarding: kimlerin giriş yapabileceğini, erişimin nasıl verildiğini ve birisi takım değiştirdiğinde aynı gün nasıl kaldırılacağını doğrulayın\n- Roller küçük kalsın: maksimum 2-3 rol tutun (viewer, operator, admin) ve her rolün ne yapabileceğini yazın\n- Varsayılan olarak salt-okunur: görüntüleme varsayılan yol olsun ve veriyi değiştirecek her şey için açık bir rol gerektirin\n- Sırların ele alınması: tokenları ve anahtarları depo dışı saklayın ve aracın bunları log veya hata mesajlarında asla yazdırmadığını doğrulayın\n- Acil erişim akışı: acil erişim gerekiyorsa, bunun zaman sınırlı ve loglanan bir yolunun olmasını sağlayın\n\nSonra yaygın hataları önleyen koruyucuları doğrulayın:\n\n- Riskli eylemler için onaylar: silme, backfill veya konfig değişiklikleri için yazılı onay gerektirin\n- Limitler ve zaman aşımı: sonuç boyutunu sınırlayın, zaman pencerelerini uygulayın ve sorguların sonsuza kadar çalışmasını önleyin\n- Girdi doğrulama: ID'leri, tarihleri ve ortam adlarını doğrulayın; “her yerde çalıştır” gibi görünenleri reddedin\n- Denetim logları: kimin ne zaman ve nereden ne yaptığını kaydedin; logları olay sırasında kolay aranabilir yapın\n- Temel metrikler ve hatalar: başarı oranı, gecikme ve en sık hata türlerini izleyin ki bozulma erken fark edilsin\n\nDeğişiklik kontrolünü diğer servislerde olduğu gibi yapın: eş kod incelemesi, tehlikeli yollar için birkaç odaklı test ve hızlı bir geri alma planı (aracı çabuk devre dışı bırakma yolu dahil).\n\n## Sonraki adımlar: güvenli şekilde kullanıma sunma ve geliştirmeye devam etme\n\nİlk sürümü kontrollü bir deney gibi ele alın. Bir takımla, bir iş akışıyla ve küçük bir gerçek görev setiyle başlayın. On-call için bir log arama aracı iyi bir pilot olur çünkü kazançları ölçebilir ve riskli sorguları hızla tespit edebilirsiniz.\n\nYayılımı öngörülebilir tutun: 3–10 kullanıcı ile pilot, staging'de başlama, en az ayrıcalık rolleri ile erişimi kısıtlama (paylaşılan tokenlar değil), net kullanım limitleri belirleme ve her komut veya buton tıklaması için denetim logları kaydetme. Konfigürasyon ve izin değişikliklerini hızla geri alabileceğinizden emin olun.\n\nAracın sözleşmesini yalın dille yazın. Her komutu (veya pano eylemini), izin verilen parametreleri, başarının neye benzediğini ve hataların ne anlama geldiğini listeleyin. İnsanlar çıktılar belirsiz olduğunda dahili araçlara güvenmeyi bırakır, kod doğru olsa bile.\n\nGeribildirim döngüsü ekleyin ve gerçekten kontrol edin. Hangi sorguların yavaş olduğunu, hangi filtrelerin yaygın olduğunu ve hangi seçeneklerin insanları şaşırttığını takip edin. Tekrarlanan geçici çözümler görüyorsanız, bu genellikle arayüzün güvenli bir varsayılanı eksik olduğunu gösterir.\n\nBakım için bir sahip ve bir program belirleyin. Kim bağımlılıkları güncelleyecek, kim kimlik bilgilerini döndürecek ve araç bir olay sırasında bozulduğunda kim aranacak karar verin. AI tarafından üretilen değişiklikleri de bir üretim servisi gibi inceleyin: izin farkları, sorgu güvenliği ve loglama.\n\nEkip sohbetine dayalı yinelemeyi tercih ediyorsanız, Koder.ai (koder.ai) küçük bir CLI veya pano oluşturmak, bilinen iyi durumların anlık görüntülerini tutmak ve bir değişiklik risk getirdiğinde hızlıca geri almak için pratik bir yol olabilir.