Çok Lokasyonlu BT Operasyonunda Yerel Ekip ve Merkezi Uzmanlık Dengesi

Merkez ofiste çalışan bir uzman, uzak tesisteki sunucunun ekranını görebilir; fakat kabloyu, enerjiyi veya fiziksel alarmı yerinde kontrol edemez. Saha personeli ise cihazın yanında olmasına rağmen merkezi kimlik, yedekleme veya ağ standardında değişiklik yapacak bağlama sahip olmayabilir. Etkili operasyon bu iki yeteneği birbirinin alternatifi değil, aynı hizmet zincirinin parçaları olarak görür.

Temmuz 2026’da maden, tesis ve genel müdürlük benzeri farklı lokasyonlara sahip anonim bir kurum için görev dağılımını yeniden ele aldık. Amaç tüm yetkiyi merkezde toplamak veya her sahada tam uzman ekip kurmak değildi. Tekrarlanabilir yerel müdahale, merkezi standart, görünür bağımlılık ve gerektiğinde hızlı uzman eskalasyonu sağlayan dengeli bir model oluşturmaktı.

Sorunun ortaya çıkışı

Sunucu kurulumu merkez ekipteydi, ancak kurulumdan önce gerekli yerel veri hazırlığı ve fiziksel kontrol görevi açıkça atanmamıştı. Merkez işi bekliyor, saha ise talebin tamamen merkez tarafından yürütüldüğünü düşünüyordu. Benzer biçimde ağ kesintilerinde saha cihazların yanında olmasına rağmen hangi kontrolleri güvenle yapacağını bilmiyor, merkez de fiziksel durum bilgisi olmadan uzaktan teşhis yürütüyordu.

Ticket sistemi tek bir sorumlu gösteriyor, ardışık görevleri ve lokasyon bağımlılığını yansıtmıyordu. Yerel personel doğrudan farklı merkezi uzmanlara ulaşıyor, kayıt sonradan açılıyordu. Çözümler kişisel mesajlarda kaldığı için aynı arıza başka sahada yeniden araştırılıyordu. İzin, seyahat, yedek parça ve tedarikçi erişimi gibi saha gerçekleri hizmet sürelerinde hesaba katılmıyordu.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım uzaktan yönetim aracı varsa yerel BT ihtiyacının ortadan kalkacağıydı. Enerji, çevresel koşul, fiber, konsol ve donanım değişimi fiziksel müdahale gerektirir. Karşıt varsayım ise her lokasyonun kendi yöntemini seçmesinin daha hızlı olduğuydu. Kısa vadeli hız; farklı yapılandırma, eksik kayıt, yedekleme boşluğu ve uzman bulunamadığında uzun kesinti olarak geri dönebiliyordu.

Bir diğer belirti görevlerin unvana göre dağıtılmasıydı. “BT personeli yapar” ifadesi yeterli değildi; bazı işler iki kişiyle fiziksel güvenlik, bazıları değişiklik onayı, bazıları üretici sertifikası gerektiriyordu. Yerel ekip merkezi onayı bürokrasi, merkez ekip saha inisiyatifini kontrol kaybı olarak görmeye başladığında sorun organizasyonel hale geldi. Ortak hizmet hedefi yeniden kurulmalıydı.

Teknik analiz

Önce hizmet ve görev envanteri çıkarıldı: kullanıcı desteği, fiziksel kontrol, ağ, sunucu, kimlik, yedekleme, uygulama, güvenlik olayı ve tedarikçi koordinasyonu. Her görev için yapılma sıklığı, gerekli yetkinlik, uzaktan yapılabilirlik, fiziksel risk, ayrıcalık seviyesi ve müdahale süresi değerlendirildi. RACI yalnızca bölüm adlarını değil, görev başlangıcı ve teslim koşullarını gösterecek ayrıntıda hazırlandı.

Yerel ekip için güvenli ilk kontrol runbook’ları oluşturuldu. Runbook, belirtiyi doğrulama, fotoğraf veya log toplama, enerji ve bağlantı kontrolü, değişiklik yapmadan eskalasyon gibi sınırları içerdi. Merkezi ekip platform sağlığı, yapılandırma standardı, ayrıcalıklı değişiklik, yedekleme ve uzman teşhisten sorumlu oldu. Ticket alt görevleri bağımlı şekilde sıralandı; bir görev tamamlanmadan sonraki ekip yanlışlıkla başlamadı.

Uygulanan çözüm veya önerilen mimari

Katmanlı destek modeli kuruldu. Yerel ekip fiziksel doğrulama, standart kullanıcı işlemleri, onaylı parça değişimi ve kanıt toplama görevlerini yürüttü. Merkezi servis masası kaydı, önceliği ve iletişimi yönetti. Platform ekipleri ağ, sunucu, kimlik ve uygulama uzmanlığını sağladı; kritik olaylarda tek bir olay yöneticisi farklı ekipleri koordine etti. Tedarikçi çağrısı kurum içi sahipliği devretmedi.

Standart yapılandırmalar, envanter, ağ ve sistem dokümanları merkezi depoda rol bazlı tutuldu. Her saha için bağlantı tamamen kesildiğinde kullanılacak iletişim ve yerel çalışma prosedürü hazırlandı. Yedek parça sınıfları kritiklik ve tedarik süresine göre sahada veya merkezde konumlandırıldı. Eğitimler genel sunum yerine gerçek runbook uygulamalarıyla yapıldı; saha ekibinin geri bildirimi tasarım kararlarına taşındı.

Alternatifler ve karar gerekçesi

Tam merkezi model standardizasyon ve uzman yoğunluğu sağlar; uzak saha erişimi, fiziksel müdahale ve bağlantı kesintisinde yavaş kalabilir. Tam yerel model çeviklik ve saha bilgisi sunar; uzmanlık tekrarına, farklı standartlara ve sınırlı kariyer yedeğine yol açabilir. Hub-and-spoke yaklaşımında merkez platform ve yönetişimi, yerel ekip kontrollü uygulamayı sahiplenir. Kurumun coğrafyası için bu denge daha sürdürülebilir bulundu.

Dış kaynak saha desteği esnek kapasite ve geniş kapsama sağlayabilir; kurumsal bağlam, erişim güvenliği ve hizmet kalitesi sözleşmeyle dikkatle yönetilmelidir. Her lokasyonda kadrolu uzman bulundurmak kritik büyük sahalarda gerekebilir, küçük noktalarda verimsiz olabilir. Karar kullanıcı sayısından tek başına çıkarılmadı; iş kritiklik, ulaşım süresi, fiziksel risk, bağlantı güvenilirliği ve iş yükü birlikte değerlendirildi.

Güvenlik ve operasyonel riskler

Yerel müdahale için geniş yönetici hesabı vermek hızlı fakat risklidir. Rol bazlı, süreli ve kayıtlı erişim kullanılmalı; ortak hesaplardan kaçınılmalı, acil durum erişimi sonradan gözden geçirilmelidir. Runbook’lar gerçek parola, özel ağ ayrıntısı veya gereksiz güvenlik kuralı içermemelidir. Tedarikçi erişimi sponsor, amaç, süre, MFA ve oturum kaydıyla yönetilmeli; iş bitince kapatılmalıdır.

Tek bir merkezi uzmana bağımlılık izin veya kriz döneminde hizmeti durdurabilir. Yetkinlik matrisi, çapraz eğitim, nöbet ve güncel dokümantasyon bu riski azaltır. Yerel ekip güvenli çalışma sınırını aşmamalı; özellikle endüstriyel sahada BT müdahalesi fiziksel iş güvenliği prosedürlerine tabidir. KPI’lar yalnızca kapanış süresini değil tekrar açılma, eskalasyon kalitesi, doküman güncelliği ve kullanıcı etkisini ölçmelidir.

Çıkarılan Dersler

Kontrol Listesi

Personel tag’lerinden oluşan konum olayları merkezi uygulamada görünmeye başladığında teknik ekip sistemi çalışır kabul edebilir. Sözleşme ekine gelindiğinde ise “müşteri veri sorumlusudur, tedarikçi veri işleyendir” cümlesi tek başına yetersiz kalır. Uygulama üreticisi bulut telemetrisi alıyor, entegratör uzaktan destek veriyor ve başka bir sağlayıcı yedek tutuyorsa gerçek veri zinciri daha uzundur.

9 Temmuz 2026 tarihinde anonim bir endüstriyel IoT projesi için yaptığımız çalışmada hukuki unvanları varsayımla değil, fiili karar ve veri akışıyla eşleştirdik. Bu yazı hukuki görüş yerine geçmez; hukuk, bilgi güvenliği, operasyon ve tedarik ekiplerinin aynı soruları sormasını sağlayan pratik bir çerçevedir. Kesin yükümlülükler ilgili mevzuat ve sözleşme bağlamında uzmanlarla doğrulanmalıdır.

Sorunun ortaya çıkışı

Müşteri saha ihtiyacını tanımlıyor, üretici yazılımı sağlıyor, uygulayıcı cihazları kuruyor ve destek ekibi sisteme erişiyordu. Taslak DPA yalnızca iki taraf içerdiği için alt yüklenici, barındırma ve uzaktan destek rolleri görünmüyordu. Hangi tarafın hangi veri kategorisine eriştiği, veriyi ne kadar tuttuğu ve sözleşme bittiğinde nasıl sileceği açık değildi.

Personel kimliği ile tag eşleştirmesi işveren sisteminden geliyor, konum olayları IoT platformunda işleniyor ve raporlar başka kurumsal uygulamalara aktarılıyordu. Teknik mimari diyagramı cihaz bağlantısını gösterse de hukuki veri akışını göstermiyordu. Projenin canlıya geçiş tarihi yaklaşırken ihlal bildirimi, ilgili kişi talebi ve veri dışa aktarımı için kimin ne yapacağı cevaplanamıyordu.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım yazılım üreticisinin otomatik olarak veri sorumlusu olduğuydu. Rol, ürün sahipliğinden çok kişisel veri işleme amaç ve vasıtaları üzerindeki fiili karara bağlıdır. Başka bir yanlış varsayım verinin cihaz seri numarasından oluştuğu için kişisel olmadığıydı. Tag bir çalışanla eşleştirildiğinde ve konum/zaman olayı üretildiğinde veri bağlamı kişiyi belirlenebilir kılabilir.

DPA imzalanınca tüm yükümlülüklerin tamamlandığı düşüncesi de sorun yarattı. Sözleşmedeki silme süresi uygulamada bir iş akışına bağlanmamış, yedeklerden silmenin teknik sınırları açıklanmamıştı. Alt işleyen değişikliğinde bildirim yöntemi yoktu. Destek hesapları ortak kullanılıyor ve erişim kayıtları kişi bazında tutulamıyordu. Kâğıt üzerindeki kontrol, operasyonel karşılık bulmadığında güvence sağlamaz.

Teknik analiz

Önce veri envanteri oluşturuldu: personel kimliği veya takma kimlik, tag eşleştirmesi, zaman ve bölge olayı, araç ilişkisi, cihaz telemetrisi, destek kaydı ve kullanıcı günlükleri. Her veri için kaynak, amaç, işleme işlemi, erişen taraf, barındırma yeri, aktarım ve saklama süresi yazıldı. Bu tablo, taraf rollerini sözleşme başlığından daha doğru biçimde görünür kıldı.

Karar matrisiyle işleme amacını, zorunlu alanları, saklama süresini ve raporlama kullanımını kimin belirlediği incelendi. Yalnızca talimatla hizmet veren taraf veri işleyen olarak, kendi bağımsız amacı için karar alan faaliyet ise ayrıca değerlendirildi. Alt işleyen listesi, veri merkezleri, uzaktan destek konumları ve yedekleme zinciri doğrulandı. Hukuk ekibi teknik akışı bu envanter üzerinden yorumladı.

Uygulanan çözüm veya önerilen mimari

Müşteri tarafında işleme amacı ve saha politikası için hesap verebilir veri sahibi belirlendi. Teknoloji sağlayıcı ile uygulayıcının hangi faaliyetlerde talimatla hareket ettiği sözleşme ekinde ayrıştırıldı; onaylı alt işleyenler listeye alındı. DPO veya ilgili gizlilik irtibatı, güvenlik olay kontağı ve operasyon sorumlusu isim yerine rol bazında tanımlandı; personel değişiminde süreç kesilmedi.

Teknik mimaride veri minimizasyonu uygulandı. Gereksiz kimlik alanları IoT platformuna taşınmadı, rol bazlı erişim ve kişi bazlı yönetici hesapları kullanıldı. Saklama süreleri uygulama, rapor, log ve yedek için ayrı yapılandırıldı. İlgili kişi talebi, düzeltme, dışa aktarma ve sözleşme sonu silme senaryoları masa başı tatbikatla test edildi; mümkün olmayan adımlar şeffaf biçimde kayda alındı.

Alternatifler ve karar gerekçesi

Tüm veriyi müşteri ortamında tutmak aktarım zincirini sadeleştirebilir; üretici desteği, güncelleme ve yedekleme yine erişim yaratabilir. SaaS modelinde işletim kolaylığı ve ölçek sağlanabilir, fakat alt işleyen, veri konumu ve çıkış planı daha ayrıntılı incelenmelidir. On-premises etiketi tek başına hukuki rolü veya güvenliği belirlemediği için fiili erişim üzerinden değerlendirme yaptık.

Personel adını sistemde tutmak raporlamayı kolaylaştırır; takma kimlik kullanmak gereksiz ifşayı azaltır fakat yetkili eşleştirme hizmeti gerektirir. Operasyon ekranında açık kimliğin gerçekten gerekli olduğu roller ayrıştırılarak çoğu görünümde minimizasyon tercih edildi. Saklama süresini “sözleşme boyunca” bırakmak kolaydı; iş güvenliği, operasyon, talep ve yasal ihtiyaçlara göre veri türü bazında süre belirlemek daha savunulabilir oldu.

Güvenlik ve operasyonel riskler

Ortak destek hesapları, kontrolsüz uzak erişim ve üretim verisinin test ortamına kopyalanması başlıca risklerdir. Tedarikçi erişimi talep, onay, süre, MFA ve kayıtla yönetilmeli; testte anonim veya sentetik veri kullanılmalıdır. Güvenlik yükümlülükleri “uygun önlem alınır” gibi belirsiz ifadelerle bırakılmamalı; erişim, şifreleme, yama, yedek ve olay işbirliği sorumlulukları doğrulanabilir olmalıdır.

Sınır ötesi veri aktarımı yalnızca ana uygulama barındırmasına bakılarak değerlendirilemez; telemetri, destek, log analizi ve yedekleme de zincire dahildir. Alt işleyen değişiklikleri izlenmezse onaylı mimari fark edilmeden değişebilir. Sözleşme sonundaki silme belgesi teknik doğrulamayla desteklenmeli, yedeklerdeki gecikmeli silme açıklanmalıdır. Mevzuat değişiklikleri için dönemsel hukuk ve envanter gözden geçirmesi planlanmalıdır.

Çıkarılan Dersler

Kontrol Listesi

Yer altı personel ve araç takibi konuşulurken masa üzerindeki ilk çizim genellikle tag, okuyucu ve merkezi sunucudan oluşur. Sahaya inildiğinde tünel geometrisi, enerji noktaları, toz, nem, titreşim, haberleşme kesintileri ve vardiya akışı bu sade çizimi hızla değiştirir. Bir okuyucunun çalışması, ürettiği olayın operasyon açısından doğru ve zamanında olduğu anlamına gelmez.

Nisan-Temmuz 2026 döneminde ele aldığımız anonim bir saha çalışmasında projeyi cihaz kurulumu değil, operasyonel yetenek geliştirme programı olarak yönettik. Tag reader, hat başı bileşenleri, araç/personel tag’leri ve merkezi uygulama yalnızca teknik yapı taşlarıydı. İş güvenliği, saha operasyonu, altyapı, BT, insan kaynakları ve tedarikçi aynı kabul ölçütlerinde buluşmadan canlıya geçiş planlanmadı.

Sorunun ortaya çıkışı

Kurum, vardiya sırasında personel ve araçların belirlenmiş bölgelere giriş-çıkışını merkezi olarak görmek istiyordu. İlk kapsam cihaz adetleri üzerinden hazırlanmış, hangi iş kararının hangi konum hassasiyetine ve gecikme süresine ihtiyaç duyduğu yazılmamıştı. “Yer altında takip” ifadesi gerçek zamanlı koordinattan bölge bazlı geçiş olayına kadar farklı beklentiler yaratıyordu. Önce bu beklentiyi ölçülebilir kullanım senaryolarına çevirdik.

Saha keşfinde plan üzerindeki güzergâh ile fiili operasyonun farklı olduğu görüldü. Geçici çalışma alanları, hareket eden ekipmanlar, enerji kesintisi olasılığı ve bakım erişimi cihaz yerleşimini etkiliyordu. Merkezi sunucuya bağlantı için tek yol varsayılmış, bağlantı kesildiğinde olayların yerelde tutulup tutulmayacağı netleştirilmemişti. Projenin fiziksel, ağ ve uygulama bağımlılıkları tek takvimde görünmüyordu.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım üretici çizimindeki kapsamanın saha kabulü yerine geçeceğiydi. Kaya yapısı, tünel dönüşleri, metal ekipman, montaj yüksekliği ve hareketli araçlar radyo davranışını değiştirebilir. İkinci varsayım tag görülmüyorsa sorunun doğrudan tag arızası olduğuydu. Okuyucu enerjisi, anten, hat bileşeni, ağ yolu, zaman senkronizasyonu veya sunucu işleme kuyruğu aynı belirtiyi yaratabilir.

Bir başka belirti kullanıcıların ekranda gördüğü konumu kesin koordinat olarak yorumlamasıydı. Sistem bölge veya okuyucu geçişi mantığıyla çalışıyorsa gösterim de bu belirsizliği açıkça ifade etmelidir. “Anlık” sözcüğü de ölçülmemişti; olayın sahada oluşması ile ekranda görünmesi arasında kabul edilen gecikme tanımlanmayınca tedarikçi ve operasyon farklı başarı ölçütleri kullandı.

Teknik analiz

Kapsamayı masa başı tasarım, saha ölçümü ve pilot doğrulama olarak üç aşamaya böldük. Kritik geçiş noktaları, kaçış güzergâhları, girişler ve operasyon bölgeleri kullanım senaryosuna göre sınıflandırıldı. Her cihaz için enerji, montaj, çevresel dayanım, bakım erişimi ve iletişim bağımlılığı kaydedildi. Tek bir kapsama yüzdesi yerine kritik nokta tespit oranı, olay gecikmesi ve kesinti sonrası veri bütünlüğü ölçüldü.

Uçtan uca veri akışı tag’den okuyucuya, ara haberleşme bileşenine, saha ağına, merkezi uygulamaya ve API tüketicisine kadar izlendi. Cihaz ile sunucu saatlerinin güvenilir kaynaktan eşlenmesi olay sırasını korumak için kritik bulundu. Bağlantı kesintisinde tampon kapasitesi, tekrar gönderim, yinelenen kayıt ve kayıp olay davranışı test edildi. API alanları veri sahibi ve amaçla eşleştirildi.

Uygulanan çözüm veya önerilen mimari

Önce sınırlı fakat operasyon açısından temsilî bir pilot bölge seçildi. Okuyucu ve hat bileşenleri saha güvenliği kurallarına uygun monte edildi; enerji ve ağ yolları izlenebilir biçimde etiketlendi. Merkezi SmartFlow benzeri uygulama yedekleme, izleme ve zaman senkronizasyonu olan sunucu katmanında çalıştırıldı. Üretim ağına erişimler gerekli akışlarla sınırlandı ve uzaktan bakım ayrı onay sürecine bağlandı.

Pilot kabulü cihazın çevrimiçi görünmesine değil, tanımlı personel ve araç senaryolarının doğru olay üretmesine dayandı. Sonuçlar operasyon, iş güvenliği ve BT tarafından birlikte imzalandı. Yaygınlaştırma lokasyon paketlerine ayrıldı; her pakette saha hazırlığı, kurulum, test, eğitim ve as-built dokümantasyon tamamlanmadan sonraki bölgeye geçilmedi. API entegrasyonu pilot veri kalitesi doğrulandıktan sonra açıldı.

Alternatifler ve karar gerekçesi

Bölge bazlı RFID benzeri yaklaşım daha sade altyapı ve belirli geçiş noktalarında güvenilir olay sağlayabilir; sürekli ve hassas koordinat beklentisini karşılamaz. UWB gibi daha hassas çözümler daha yoğun altyapı, kalibrasyon ve maliyet gerektirebilir. Wi-Fi veya BLE tabanlı seçenekler mevcut altyapıdan yararlanabilir, ancak yer altı ortamında kapsama ve cihaz davranışı mutlaka sahada doğrulanmalıdır.

Tek seferde tüm sahaya yayılım takvimi kısaltıyor gibi görünür; tasarım hatasını çoğaltma ve operasyonu zorlayacak büyük değişiklik riski taşır. Pilot sonrası dalgalı yayılım daha uzun planlama gerektirir, fakat yerleşim standardını gerçek veriye göre geliştirir. Kullanım senaryosu bölge geçişi olduğu için teknoloji kararını pazarlama hassasiyetine değil, kabul edilen doğruluk ve bakım yapılabilirliğine bağladık.

Güvenlik ve operasyonel riskler

Konum olayları çalışan davranışı ve iş güvenliğiyle ilişkili kişisel veri oluşturabilir. Amaç, erişim rolleri, saklama süresi, çalışan bilgilendirmesi ve hukuki dayanak proje başında belirlenmelidir. Yönetim ekranları herkese açılmamalı, rapor dışa aktarımları izlenmeli ve testte gerçek kişi yerine kontrollü kimlikler kullanılmalıdır. API kimlikleri kod veya dokümana yazılmadan güvenli kasada tutulmalıdır.

Sistem tek başına hayat güvenliği sağlayan mekanizma olarak kabul edilmemelidir; kapsama veya bağlantı kesintisi mümkün olduğundan mevcut acil durum prosedürlerini tamamlamalıdır. Yanlış konumun operasyon kararına etkisi ve manuel doğrulama yöntemi yazılmalıdır. Cihaz arızası, enerji kesintisi, sunucu doluluğu ve zaman sapması için alarm ile müdahale sahibi bulunmalı; yedek parça ve saha erişimi planlanmalıdır.

Çıkarılan Dersler

Kontrol Listesi

Bir WordPress bağlantı sorunu incelenirken en hızlı yöntem olarak yapılandırma dosyasını açıp veritabanı parolasını ekip sohbetine göndermek önerilmişti. Bu yöntem sorunu kısa süreli çözebilirdi, fakat kalıcı bir sır birden fazla kontrolsüz kopyaya dönüşecekti. Asıl ihtiyaç parolayı “bulmak” değil, yetkili kişinin güvenli biçimde doğrulaması ve gerekiyorsa izlenebilir şekilde yenilemesiydi.

21 Temmuz 2026 tarihli çalışmada `wp-config.php` dosyasını yalnızca bağlantı ayarı olarak değil, WordPress güven sınırlarından biri olarak ele aldık. Dosya yolu, web sunucusu kullanıcısı, dağıtım yöntemi, yedek ve destek süreçleri birlikte incelendi. Aşağıdaki yaklaşım gerçek parola veya altyapı ayrıntısı paylaşmadan savunmacı işletim prensiplerine odaklanır.

Sorunun ortaya çıkışı

Site veritabanına bağlanamıyor, ancak ekipte hangi hesabın kullanıldığına dair güncel kayıt bulunmuyordu. Dosyaya erişebilen herkes parolayı okuyabiliyor, bazı eski yedeklerde de yapılandırmanın kopyaları yer alıyordu. Önceki bir hata ayıklama sırasında debug kayıtları web dizininde bırakılmıştı. Tek bağlantı sorunu, sır yaşam döngüsü ve dosya yönetişimi eksiklerini görünür hale getirdi.

Dosyanın sahipliği geçmiş kurulumlardan dolayı belirsizdi. Web sunucusunun yazma yetkisi bulunması güncellemeyi kolaylaştırıyor gibi görünse de uygulama açığında yapılandırmanın değiştirilmesi riskini artırıyordu. Öte yandan izinleri düşünmeden aşırı daraltmak siteyi erişilemez yapabilirdi. Doğru model işletim sistemi kullanıcısı, PHP çalışma biçimi ve dağıtım sorumluluğuna göre kurulmalıydı.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım dosyanın web tarayıcısından normalde görüntülenememesinin yeterli koruma olduğuydu. Yanlış sunucu yapılandırması, yedek uzantısı, dizin listeleme, yerel kullanıcı veya ele geçirilmiş eklenti farklı erişim yolları oluşturabilir. İkinci varsayım dosya izninde tek bir sayısal değerin her sunucu için doğru olduğuydu. Sahiplik ve servis modeli bilinmeden kopyalanan izin önerileri kesinti ya da gereksiz açıklık yaratabilir.

Salt anahtarlarının veritabanı parolasıyla aynı işlevi gördüğü de karıştırılıyordu. WordPress authentication salts mevcut oturum çerezlerinin güvenliğini etkiler; değiştirilmeleri kullanıcı oturumlarını geçersiz kılar. Veritabanı parolasının rotasyonu ise MySQL hesabı ile yapılandırmanın eş zamanlı güncellenmesini gerektirir. İki işlem farklı etki ve geri dönüş planlarıyla yürütülmelidir.

Teknik analiz

Dosyanın gerçek konumu, sembolik bağlantıları, sahibi, grubu ve erişim listeleri doğrulandı. Web sunucusunun dosyayı okuması gerekiyor, fakat olağan çalışma sırasında değiştirmesi gerekmiyordu. Üst dizin izinleri de kontrol edildi; yalnızca dosyayı daraltıp dizini geniş bırakmak yeterli değildir. Web sunucusu yapılandırmasının `.bak`, `.old` veya editör geçici dosyalarını sunmadığı doğrulandı.

Yapılandırmada veritabanı kimliği, salt anahtarları, debug ayarı ve tablo öneki gibi alanlar envantere alındı; değerler rapora kopyalanmadı. Kaynak kod deposu geçmişi ve dağıtım paketi sır sızıntısı açısından kontrol edildi. Debug logunun konumu, erişimi ve saklama süresi belirlendi. Yedeklerin dosyayı içerip içermediği ve kimlerin yedek ortamına erişebildiği ayrıca değerlendirildi.

# Değerleri ekrana dökmeden yalnızca sahiplik ve izinleri inceleyin.
stat /guvenli/yol/wp-config.php

# PHP sözdizimini kontrol edin; dosya içeriğini paylaşmayın.
php -l /guvenli/yol/wp-config.php

# İzin değişikliği vermeden önce web/PHP çalışma kullanıcısını doğrulayın.
# Ortama özel sahiplik bilinmeden körlemesine chmod/chown uygulamayın.

Uygulanan çözüm veya önerilen mimari

Dosyanın sahibi dağıtım sorumluluğundaki ayrı kullanıcı, okuma grubu ise yalnızca PHP servisinin gerekli kimliği olacak şekilde tasarlandı. Web sürecine yazma verilmedi. Kesin izin değeri ortama göre test edilerek belirlendi ve yapılandırma web kökü dışında desteklenen konuma taşınabiliyorsa bu seçenek değerlendirildi. Sunucu, yedek ve geçici uzantılı yapılandırma dosyalarını yayınlamayacak biçimde sertleştirildi.

Parolalar kurumun secret yönetim sürecinde üretildi; dosyaya dağıtım sırasında güvenli kanaldan verildi ve depoya yazılmadı. Rotasyonda yeni sınırlı hesap oluşturma, yapılandırmayı atomik güncelleme, sağlık testi ve eski hesabı iptal etme adımları uygulandı. Salt yenilemesi ayrı değişiklik olarak kullanıcı oturum etkisiyle planlandı. Erişim ve değişiklikler kişisel sırları göstermeden denetim kaydına alındı.

Alternatifler ve karar gerekçesi

Sırları doğrudan `wp-config.php` içinde tutmak WordPress’in yaygın ve basit modelidir; dosya güvenliği kritik hale gelir. Ortam değişkenleri veya harici secret manager merkezi rotasyon ve dağıtım sağlayabilir, fakat PHP sürecinde değerin nasıl sunulduğu, hata çıktıları ve eklenti uyumluluğu incelenmelidir. Yalnızca farklı yere taşımak, erişim kontrolleri değişmiyorsa sihirli bir koruma sağlamaz.

Dosyayı tamamen değişmez yapmak izinsiz değişikliği azaltabilir; otomasyon, güncelleme ve acil müdahale sürecini zorlaştırabilir. Web sunucusuna yazma vermek ise kolaylık karşılığında olay etkisini büyütür. Kontrollü dağıtım hesabı, salt okunur uygulama erişimi ve izlenen değişiklik süreci kurumun işletim biçimine daha uygun bulundu. Karar, geri dönüş testiyle doğrulandı.

Güvenlik ve operasyonel riskler

Dosya içeriğini ticket, ekran görüntüsü veya sohbetle paylaşmak geri alınması zor kopyalar üretir. Bir sırın açığa çıktığından şüpheleniliyorsa mesajı silmek yeterli değildir; parola ve ilgili anahtarlar planlı biçimde yenilenmelidir. Kaynak depo geçmişindeki sır da yalnızca son commit’ten kaldırılınca yok olmaz. Erişim anahtarları önce iptal edilmeli, geçmiş temizliği kontrollü yürütülmelidir.

Yanlış sahiplik ya da izin değişikliği site kesintisine yol açabilir. Önce mevcut durum kaydedilmeli, ikinci yönetim oturumu korunmalı ve sağlık testi hazırlanmalıdır. Debug açık kalırsa kişisel veri, sorgu veya dosya yolu loglara düşebilir. Yedekler şifrelenmeli, erişimleri sınırlandırılmalı ve saklama sonlarında güvenli silinmelidir. Dosya bütünlüğü uyarıları yetkili dağıtımlarla ilişkilendirilmelidir.

Çıkarılan Dersler

Kontrol Listesi

Yeni bir WordPress kurulumunda veritabanı bağlantısını hızla doğrulamak için yönetici hesabını kullanmak cazip gelebilir. Bir kurulumda bu geçici tercih kalıcı hale gelmiş, uygulama yapılandırmasında gereğinden geniş yetkili bir hesap bırakılmıştı. Site çalışıyordu; fakat uygulama ele geçirilirse aynı sunucudaki diğer veritabanları ve yönetim işlemleri de gereksiz biçimde risk altındaydı.

21-23 Temmuz 2026 arasında ele alınan çözümde WordPress’e özel veritabanı ve servis kimliği oluşturduk. Buradaki komutlar örnek adlar kullanır; gerçek parola, sunucu adresi veya topoloji içermez. Hedef yalnızca bağlantıyı çalıştırmak değil, hesabın nereden bağlanabileceğini ve hangi nesnede hangi işi yapabileceğini anlaşılır biçimde sınırlandırmaktır.

Sorunun ortaya çıkışı

WordPress kurulum ekranı veritabanına bağlanamıyor ve ekip farklı kullanıcılarla tekrar deniyordu. Root hesabıyla bağlantı sağlanınca sorun çözülmüş sayıldı. Oysa hata uygulama kullanıcısının yanlış host tanımı, eksik grant veya farklı kimlik doğrulama yöntemi olabilirdi. Geniş yetki kullanmak kök nedeni gizledi ve güvenlik borcu yarattı. Önce bağlantı kimliğinin tam olarak nasıl eşleştiğini anlamak gerekiyordu.

MySQL kullanıcıları yalnızca kullanıcı adından değil kullanıcı ve host birleşiminden oluşur. Aynı makinedeki `localhost`, bir konteyner ağı veya uzak uygulama sunucusu farklı hesap eşleşmeleri yaratabilir. Her yerden bağlantıya izin veren geniş host tanımı kolaylık sağlar; fakat ağ ve kimlik kısıtlarını zayıflatır. Uygulamanın gerçek çalışma konumuna uygun en dar kaynak seçilmeliydi.

İlk belirtiler ve yanlış varsayımlar

“Access denied” mesajı çoğu zaman yalnızca yanlış parola olarak yorumlanır. Gerçekte kullanıcı-host eşleşmesi, grant, parola eklentisi veya bağlantı soketi farklı olabilir. Diğer belirti komut satırından bağlantı başarılıyken WordPress’in başarısız olmasıydı. Test farklı işletim sistemi kullanıcısı, farklı host adı veya TCP yerine yerel soket kullanıyorsa uygulamanın yolunu temsil etmeyebilir.

Bir başka yanlış varsayım `GRANT ALL` ifadesinin sunucu genelinde verilmesi gerektiğiydi. WordPress kendi veritabanında kurulum ve güncelleme sırasında tablo yönetimi yapar; bunun için tüm MySQL sunucusunda yönetici olmasına gerek yoktur. Yetki kapsamı `uygulama_veritabani.*` ile sınırlandırılabilir. Üretim politikası daha sıkıysa eklenti ve çekirdek güncelleme yöntemi ayrıca planlanmalıdır.

Teknik analiz

Önce veritabanı adı, karakter seti ve collation seçimi doğrulandı. Ardından uygulamanın MySQL’e hangi host üzerinden bağlandığı belirlendi. Hesap yalnızca bu kaynaktan erişecek biçimde oluşturuldu ve yetkiler ilgili veritabanıyla sınırlandı. `SHOW GRANTS` çıktısı beklenen kapsamı doğrulamak için kullanıldı. Bağlantı testi WordPress servisinin kullandığı ağ yolu ve kimlikle yapıldı.

Hata incelemesinde uygulama logları geçici ve kontrollü biçimde etkinleştirildi; üretimde kullanıcıya ayrıntılı veritabanı hatası gösterilmedi. DNS, TCP bağlantısı, TLS gereksinimi, kullanıcı-host eşleşmesi ve veritabanı seçimi sırayla kontrol edildi. Başarılı testten sonra root kimliği yapılandırmadan çıkarıldı. Kullanılmayan deneme hesapları ve geniş grant’ler envanterden temizlendi.

-- Örnek adları ve güçlü parolayı kurumun secret süreciyle değiştirin.
CREATE DATABASE wp_app
  CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

CREATE USER 'wp_service'@'localhost'
  IDENTIFIED BY '<secret-manager-tarafindan-uretilen-parola>';

GRANT ALL PRIVILEGES ON wp_app.* TO 'wp_service'@'localhost';
SHOW GRANTS FOR 'wp_service'@'localhost';

-- FLUSH PRIVILEGES, CREATE USER ve GRANT ile yapılan modern değişikliklerde gerekmez.

Uygulanan çözüm veya önerilen mimari

Her WordPress örneği için ayrı veritabanı ve ayrı servis hesabı oluşturuldu. Hesap sunucu yönetimi, başka veritabanlarına erişim veya kullanıcı oluşturma yetkisi almadı. Uygulama ile veritabanı farklı sistemlerdeyse ağ güvenlik duvarı yalnızca gerekli kaynaktan veritabanı hizmetine erişime izin verdi. Veritabanı yönetim hesabı WordPress yapılandırmasında veya otomatik dağıtım çıktısında tutulmadı.

`wp-config.php` değerleri en dar dosya izinleriyle korundu ve dağıtım sürecinde gerçek sırların kaynak kod deposuna girmemesi sağlandı. Parola üretimi, dağıtımı, rotasyonu ve acil iptali için sahip belirlendi. Rotasyon çift hesap veya kontrollü bakım penceresiyle test edildi. Yedeklerin yapılandırma ve veritabanı sırlarını içerebileceği kabul edilerek aynı erişim standardı yedek ortamına uygulandı.

Alternatifler ve karar gerekçesi

Yerel MySQL aynı sunucuda basit işletim ve düşük ağ bağımlılığı sağlar; web sunucusu olayı veritabanı hizmetini de etkileyebilir. Ayrı veya yönetilen veritabanı yedekleme, ölçek ve görev ayrımı sunabilir; ağ, TLS, maliyet ve sağlayıcı işletimi getirir. Seçim site kritikliğine ve ekip kapasitesine bağlıdır. Her iki modelde de uygulamaya özel kimlik değişmeyen ilkedir.

WordPress’in çalışma zamanında daha dar SQL yetkileriyle işletilmesi teorik olarak saldırı yüzeyini azaltabilir. Ancak çekirdek ve eklenti güncellemeleri şema değişikliği gerektirdiğinde operasyon karmaşıklaşır. Kontrollü dağıtım hattı olan kurumlar kurulum ve runtime rollerini ayırabilir; küçük yapılarda ilgili tek veritabanıyla sınırlı yetki, güçlü dosya ve güncelleme kontrolleriyle daha sürdürülebilir olabilir.

Güvenlik ve operasyonel riskler

Parolanın terminal geçmişine, ticket’a, sohbet mesajına veya kaynak depoya yazılması en yaygın risklerdendir. Örnek komut gerçek sırla doğrudan ortak oturumda çalıştırılmamalı; kurumun güvenli secret yöntemi kullanılmalıdır. Hata ayıklama çıktıları bağlantı ayrıntısı gösterebilir ve iş bitince kapatılmalıdır. Veritabanı hizmeti gereksiz yere genel ağa açılmamalıdır.

Aşırı dar yetki güncelleme sırasında kesinti, aşırı geniş yetki ise olay etkisinin büyümesine yol açar. Değişiklikler test ortamında WordPress kurulum, eklenti güncelleme, medya kullanımı ve geri yükleme senaryolarıyla doğrulanmalıdır. Kullanılmayan hesaplar kapatılmalı, başarısız oturumlar izlenmeli ve yedekten dönüş düzenli denenmelidir. Hesap silmeden önce uygulama bağımlılığı envanterden kontrol edilmelidir.

Çıkarılan Dersler

Kontrol Listesi

Bir web sitesinin DNS kaydı proxy arkasına alındığında trafik WAF üzerinden geçiyor ve ilk bakışta origin sunucu görünmez hale geliyor. Ancak daha önceki DNS kayıtları, e-posta başlıkları, sertifika geçmişi veya başka bir servis aynı adresi işaret ediyorsa origin bulunabilir. Güvenlik duvarı herkesten web trafiği kabul ediyorsa saldırgan WAF denetimlerini atlayarak doğrudan uygulamaya ulaşabilir.

Temmuz 2026 tarihli değerlendirmede WordPress benzeri bir kurumsal siteyi yalnızca ön katmanda değil, origin sınırında da koruyacak yaklaşımı ele aldık. Gerçek alan adı, ağ adresi ve kural ayrıntıları bu anlatımda yoktur. Amaç belirli bir üreticiyi koşulsuz önermek değil; CDN/WAF ile sunucu güvenliği arasındaki paylaşılan sorumluluğu doğru kurmaktır.

Sorunun ortaya çıkışı

Site Cloudflare proxy arkasında ve WAF kuralları aktifti. Buna rağmen origin erişim kayıtlarında beklenmeyen doğrudan istekler görülüyordu. İnceleme, web sunucusunun genel internetten bağlantı kabul ettiğini gösterdi. WAF yalnızca kendi üzerinden geçen trafiği değerlendirebildiği için doğrudan bağlantıların hız sınırlama, bot yönetimi ve uygulama kurallarından geçmediği anlaşıldı.

Yönetim erişimi ile yayın trafiği de aynı ağ yolunu kullanıyordu. Sunucuya bakım yapmak için geniş izin bırakılmış, bu izin zaman içinde kalıcı hale gelmişti. Ayrıca TLS ayarı ziyaretçi ile edge arasını koruyor, edge ile origin arasındaki doğrulama yeterince güçlü değildi. Sorunu tek bir firewall kuralıyla değil, trafik türlerini ve güven sınırlarını yeniden tanımlayarak çözmek gerekiyordu.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım turuncu proxy simgesinin origin adresini kalıcı olarak gizlediğiydi. DNS değişikliği gelecekteki sorguları etkiler; geçmiş kayıtları veya aynı altyapıdaki başka servisleri silemez. İkinci varsayım yalnızca Host başlığını kontrol etmenin yeterli olduğuydu. Bu başlık istemci tarafından üretilebilir ve tek başına isteğin güvenilir proxy katmanından geldiğini kanıtlamaz.

Doğrudan origin denemesinde sitenin açılması önemli belirtiydi, fakat test kontrollü ve yetkili biçimde yapılmalıdır. Yanlış teşhislerden biri bütün bilinmeyen trafiği uygulama katmanında engellemenin yeterli sayılmasıdır. Ağ sınırında kısıtlama yoksa sunucu yine bağlantı yükünü taşır. Diğeri ise yönetim panelini WAF arkasına koymanın güçlü kimlik ve ayrı yönetim politikası ihtiyacını kaldırdığı düşüncesidir.

Teknik analiz

Trafiği ziyaretçi-edge, edge-origin ve yönetici-origin olarak üç akışa ayırdık. Yayın portlarında origin güvenlik duvarının yalnızca hizmet sağlayıcının yayımladığı ve otomatik güncellenen ağ aralıklarını kabul etmesi hedeflendi. Bu liste sabit bir blog yazısından kopyalanmadı; resmi kaynaktan doğrulanan değişiklik süreciyle yönetildi. IPv4 ve IPv6, yük dengeleyici ve sağlık kontrolü ihtiyaçları birlikte ele alındı.

TLS modu edge ile origin arasında şifreleme ve sertifika doğrulaması sağlayacak şekilde seçildi. Buna ek olarak authenticated origin pull veya eşdeğer karşılıklı doğrulama seçeneği değerlendirildi. Uygulamanın gerçek istemci adresini yalnızca güvenilir proxy başlığından alması, diğer kaynakların gönderdiği benzer başlıkları kabul etmemesi sağlandı. Erişim kayıtlarında edge kimliği ile origin isteği ilişkilendirildi.

# Dağıtıma özel adres veya kural vermeyen örnek politika mantığı:
# 1. Resmi sağlayıcı ağ listesini doğrulanmış kaynaktan alın.
# 2. Geçici bir yönetim oturumuyla erişimi kaybetmeye karşı geri dönüş hazırlayın.
# 3. Yayın portlarında yalnızca proxy ve gerekli sağlık kontrolü kaynaklarını kabul edin.
# 4. Yönetim erişimini ayrı VPN/zero-trust yoluna taşıyın.
# 5. Yetkili dış noktadan doğrudan origin erişiminin reddedildiğini doğrulayın.

Uygulanan çözüm veya önerilen mimari

Yayın trafiği Cloudflare edge üzerinden origin’e ulaştı; origin güvenlik duvarı web bağlantılarını doğrulanmış proxy kaynaklarıyla sınırladı. Uçtan uca doğrulanan TLS kullanıldı ve mümkün olan ortamda origin bağlantısı ek sertifika doğrulamasıyla güçlendirildi. Sunucunun varsayılan sanal host’u bilinmeyen alan adlarına içerik sunmadı. DNS kayıtları aynı origin’i gösteren gereksiz servisler açısından temizlendi.

Yönetim paneli ve sunucu bakımı yayın yolundan ayrıldı. Yönetici erişimi kimlik tabanlı özel erişim, MFA ve sınırlı yetkiyle sağlandı; genel internete yönetim servisi açılmadı. WAF kuralı, WordPress güvenliği, eklenti güncellemeleri ve yedekleme devam etti. Origin kısıtlamasının uygulama yamalarının veya güçlü kimlik doğrulamanın yerine geçmediği özellikle dokümante edildi.

Alternatifler ve karar gerekçesi

Yalnızca sağlayıcı IP aralıklarına izin vermek basit ve güçlü bir ağ kontrolüdür; ancak liste değişiklikleri, sağlık kontrolleri ve çoklu sağlayıcı kullanımı operasyon gerektirir. Tünel tabanlı bağlantı origin’de genel giriş ihtiyacını azaltabilir ve adres gizliliğini güçlendirebilir, buna karşılık ek agent, bağımlılık ve kapasite planı getirir. Mevcut işletim yetkinliğine göre iki yaklaşım da geçerli olabilir.

mTLS veya authenticated origin pull, kaynak doğrulamasını IP listesinin ötesine taşır; sertifika yaşam döngüsü dikkatli yönetilmezse kesinti yaratabilir. Uygulama başlığına dayalı gizli değer kolay uygulanır fakat sızma ve yanlış yapılandırma riski nedeniyle tek kontrol olmamalıdır. Katmanlı modelde ağ kısıtı, TLS doğrulama ve uygulama sertleştirme birbirini tamamladığı için tercih edildi.

Güvenlik ve operasyonel riskler

Yanlış firewall değişikliği gerçek kullanıcı trafiğini veya yönetim erişimini kesebilir. Kurallar aşamalı uygulanmalı, resmi kaynak listeleri doğrulanmalı, IPv6 unutulmamalı ve geri dönüş yöntemi değişiklikten önce test edilmelidir. Sağlayıcı durumunda sorun olduğunda origin’i geçici olarak herkese açmak hızlı görünse de WAF bypass riskini büyütür; önceden tanımlı süreli acil durum prosedürü kullanılmalıdır.

Origin adresinin geçmişte açığa çıkmış olabileceği kabul edilmelidir. Adres değişikliği yardımcı olabilir fakat kalıcı kontrol değildir. Loglar gerçek istemci verisi içerebileceği için erişim ve saklama sınırlandırılmalıdır. WAF olayları ile origin günlükleri birlikte izlenmeli; proxy dışı reddedilen isteklerdeki artış araştırılmalıdır. Yedek origin veya felaket kurtarma uç noktası da aynı koruma standardına dahil edilmelidir.

Çıkarılan Dersler

Kontrol Listesi

Bir yerel model sohbet ekranında iyi kod örnekleri ürettiğinde, dosyaları okuyup test çalıştıran ve değişiklik yapan bir geliştirme deneyiminin de kendiliğinden oluşacağı düşünülebiliyor. Denemede model güçlüydü, fakat masaüstü araç terminal çağrısını doğru yönetmiyor, çalışma dizinini ayırmıyor ve uzun görevlerde bağlamı kaybediyordu. Eksik parça model değil, agent sisteminin geri kalan katmanlarıydı.

17-20 Temmuz 2026 arasında Ollama, yönlendirilmiş API seçenekleri ve çeşitli masaüstü geliştirme arayüzlerini değerlendirirken modeli, agent runtime’ı, editörü ve araç izinlerini ayrı test ettik. Hedef, sınırsız komut çalıştıran bir otomasyon değildi. Geliştiricinin kontrolünü koruyan, değişiklikleri görünür kılan ve yerel modelin sınırlarını dürüstçe yöneten güvenli bir yardımcı deneyimiydi.

Sorunun ortaya çıkışı

Kullanıcı beklentisi doğal dille görev vermek, agent’ın depo yapısını anlaması, ilgili dosyaları değiştirmesi ve test sonucunu yorumlamasıydı. İlk kurulum yalnızca sohbet arayüzünü farklı bir LLM uç noktasına bağlamıştı. Model cevap üretiyor, ancak dosya araçları ve terminal protokolü uygulama tarafından sağlanmadığı için gerçek çalışma alanında işlem yapamıyordu. “Model desteklemiyor” teşhisi bu nedenle eksikti.

Başka bir istemci araç çağırabiliyor fakat modelin beklediği şema ile runtime’ın sunduğu şema uyuşmuyordu. Komut sonucunun kesilmesi, dosya kodlaması ve bağlam sınırı da kaliteyi etkiliyordu. Aynı model iki arayüzde farklı başarı gösterdi. Bu gözlem, değerlendirmeyi yalnızca benchmark puanından çıkarıp uçtan uca görev tamamlama ve güvenlik davranışına taşımamızı sağladı.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım tool calling etiketi olan her modelin bütün agent’larla uyumlu çalışacağıydı. Araç şeması, sohbet şablonu, durdurma belirteçleri ve yapılandırılmış çıktı davranışı farklı olabilir. İkinci varsayım büyük context window değerinin tüm depoyu güvenilir biçimde anlamaya yeteceğiydi. Gereksiz dosyalar bağlamı doldurur, ilgili bilgi gürültü içinde kaybolur ve maliyet ya da bellek tüketimi artar.

Başarı, birkaç etkileyici kod önerisiyle ölçülüyordu. Agent’ın yanlış dosyayı değiştirmesi, testi hiç çalıştırmadan tamamlandı demesi veya komut hatasını görmezden gelmesi değerlendirmede yer almıyordu. Ayrıca tam disk ve terminal erişiminin kullanım kolaylığı sağladığı varsayıldı. Oysa model hatası, kötü niyetli depo içeriği veya yanlış anlaşılmış talep bu geniş yetkiyi operasyonel riske dönüştürebilir.

Teknik analiz

Mimariyi dört parçaya ayırdık: LLM backend metin ve araç kararını üretir; agent runtime döngüyü, bağlamı ve araç sonuçlarını yönetir; IDE veya masaüstü arayüzü farkları gösterir ve onay alır; sandbox ise dosya, süreç ve ağ sınırını uygular. Bunlara model yönlendirme, sır saklama ve gözlem katmanı eklendi. Her arızanın hangi sınırda oluştuğu kayıtlarla incelendi.

Temsilî görev setinde tek dosya düzeltmesi, çok dosyalı yeniden düzenleme, test hatası analizi ve yalnızca inceleme görevleri kullanıldı. Başarı; doğru değişiklik, gereksiz dosya sayısı, test sonucu, kullanıcı onayı ve geri alınabilirlik ile ölçüldü. Modelin hızına ek olarak ilk planın kalitesi, araç çağrısı doğruluğu ve hatadan toparlanma değerlendirildi. Gizli anahtar içeren gerçek depolar test kapsamına alınmadı.

# Agent için örnek güvenli çalışma yaklaşımı
# 1. Temiz ve ayrı bir çalışma dalı oluşturun.
git switch -c ai-deneme

# 2. Değişiklikleri çalıştırmadan önce inceleyin.
git diff --check
git diff

# 3. Yalnızca projenin tanımlı test komutunu kullanıcı onayıyla çalıştırın.
# Agent'a yönetici yetkisi veya çalışma alanı dışı yazma izni vermeyin.

Uygulanan çözüm veya önerilen mimari

Yerel Ollama backend’i güvenilir bir agent runtime’a bağlandı ve çalışma alanı proje diziniyle sınırlandı. Varsayılan mod salt okuma ve planlama oldu; dosya değişikliği açık yetki, terminal komutları ise komut sınıfına göre onay istedi. Değişiklikler ayrı dalda ve diff üzerinden gösterildi. Test sonucu alınmadan agent’ın tamamlandı iddiası kabul edilmedi; başarısız test kullanıcıya eksiksiz raporlandı.

Model profilleri görev türüne göre ayrıldı. Hızlı gezinme ve küçük düzenlemeler yerel modelde, kapasiteyi aşan görevler ise veri sınıfı uygunsa önceden onaylı uzak sağlayıcıda çalıştırılabildi. Yönlendirme kararı kullanıcıya görünür tutuldu. Sistem istemleri, araç şemaları ve model sürümleri yapılandırma olarak versiyonlandı; böylece davranış değişikliği izlenebilir hale geldi.

Alternatifler ve karar gerekçesi

IDE eklentileri geliştiricinin mevcut akışına yakın ve fark incelemesinde güçlüdür; bağımsız masaüstü agent’lar daha geniş görev akışı sunabilir. Komut satırı agent’ları otomasyona uygundur fakat izinlerin görünürlüğü kullanıcı deneyimine bağlıdır. Seçim model puanından önce ekibin editör standardı, onay ihtiyacı, platform desteği ve günlük yönetim gereksinimine göre yapılmalıdır.

Tam yerel çözüm kodun ortamdan çıkmamasını kolaylaştırır, ancak küçük modeller karmaşık görevlerde daha fazla yönlendirme isteyebilir. Uzak API yüksek kapasite sağlayabilir; veri işleme, anahtar güvenliği, kota ve maliyet yönetimi gerektirir. Hibrit seçenek esnektir fakat yanlış yönlendirme riski taşır. Bu nedenle depo veya dosya sınıfına bağlı açık politika, kullanıcı göstergesi ve varsayılan yerel tercih benimsendi.

Güvenlik ve operasyonel riskler

Agent’ın okuduğu depo içeriği güvenilir komut değildir. Dokümana veya kaynak dosyaya yerleştirilmiş yönlendirmeler modeli yetki genişletmeye ikna edebilir; runtime sistem politikası bunları veri olarak ele almalıdır. Gizli dosyalar, kimlik depoları ve çalışma alanı dışındaki dizinler varsayılan olarak erişim dışı bırakılmalı; ağ çıkışı sadece görev için gerekli, onaylı hedeflerle sınırlandırılmalıdır.

Otomatik değişiklikler lisans, güvenlik, iş mantığı ve bağımlılık riski taşır. Kod incelemesi, statik analiz ve testler insan sorumluluğunun yerini almaz. Agent kayıtlarında kaynak kodun veya sırların gereksiz kopyaları tutulmamalıdır. Model, eklenti ve araç güncellemeleri davranışı değiştirebildiğinden kontrollü yayımlanmalı; olay halinde oturum, değişiklik ve onay izi incelenebilir olmalıdır.

Çıkarılan Dersler

Kontrol Listesi

Bir AI entegrasyonu haftalardır sorunsuz çalışırken aynı gün iki farklı hata üretmeye başladı. Bir çağrıda model artık mevcut olmadığı için 410, diğerinde yoğun istek nedeniyle 429 dönüyordu. İlk refleks her iki hatayı da kısa süre bekleyip yeniden denemekti. Bu yaklaşım 429 için bile dikkatli uygulanmalı; 410 içinse aynı isteği tekrarlamak yalnızca gecikme ve gereksiz trafik üretir.

20 Temmuz 2026 tarihli incelemede HTTP durum kodunu kullanıcıya gösterilecek mesajdan ayırıp uygulama davranışını hata sınıfına göre tasarladık. Model yaşam döngüsü, oran sınırı, kota, sağlayıcı geçişi ve güvenli kayıt birlikte ele alındı. Amaç hatayı gizlemek değil; işlemin güvenli biçimde sürdürülmesi veya açıkça durdurulması için öngörülebilir bir yol oluşturmaktı.

Sorunun ortaya çıkışı

Uygulamada model adı yapılandırmaya sabit yazılmıştı. Sağlayıcı modelin kullanım ömrünü tamamladığında API 410 Gone döndürdü ve bütün kullanıcılar aynı anda etkilendi. Başka bir iş akışında eş zamanlı belge özetleri kısa sürede istek sınırını doldurdu. 429 cevapları arttıkça istemciler hemen yeniden denedi ve yoğunluğu daha da büyüten bir tekrar fırtınası oluştu.

İki olay dışarıdan “AI cevap vermiyor” şeklinde görünüyordu, fakat müdahale biçimleri farklıydı. 410 yapılandırma ve yaşam döngüsü olayıydı; model kataloğunun güncellenmesi ve uyumluluk testi gerekiyordu. 429 kapasite ile akış kontrolü olayıydı; bekleme başlığı, kota penceresi, eş zamanlılık ve istek maliyeti analiz edilmeliydi. Tek genel hata yakalayıcı bu ayrımı görünmez yapmıştı.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım her 4xx yanıtın kullanıcı girdisinden kaynaklandığıydı. 410 servis sağlayıcının kaynak yaşam döngüsü kararını gösterebilir; 429 ise dakika başına istek, token, eş zamanlılık veya toplam kota sınırlarından biri olabilir. Yalnızca durum koduna bakıp hangi limitin aşıldığını anlamak mümkün değildir. Yanıt başlıkları, sağlayıcı hata gövdesi ve gözlem metrikleri birlikte değerlendirilmelidir.

İkinci varsayım fallback modelin kesintisiz ve eşdeğer sonuç vereceğiydi. Alternatif model farklı context sınırı, araç çağırma biçimi, güvenlik politikası, fiyatlandırma veya çıktı kalitesi taşıyabilir. Kullanıcıdan habersiz geçiş özellikle yapılandırılmış çıktı ve otomasyonda hataya yol açar. Fallback ancak uyumluluğu önceden test edilmiş görevlerde, sürüm ve sonuç görünürlüğü korunarak kullanılmalıdır.

Teknik analiz

Hata sınıflandırmasını kalıcı, geçici ve istemci kaynaklı olarak ayırdık. 410 kalıcı kabul edilerek devre kesici açıldı, sorumlu ekibe model ve uç nokta bilgisiyle alarm üretildi. 429 geçici sınıfta ele alındı; Retry-After varsa bu süreye uyuldu, yoksa üst sınırı ve rastgele sapması olan exponential backoff kullanıldı. Sonsuz deneme yerine görev türüne göre azami deneme ve zaman bütçesi belirlendi.

İstek, token, gecikme ve 429 oranları model ile iş akışı bazında izlendi. Toplu işler kuyruğa alınarak etkileşimli kullanıcılardan ayrıldı. Büyük istemler bölündü veya gereksiz bağlam azaltıldı. Model kataloğunda aktif, kullanımdan kalkacak ve kapalı durumları ile son destek tarihi tutuldu. Böylece sağlayıcı duyuruları üretim hatasına dönüşmeden önce test ve geçiş işi açılabildi.

// Güvenli örnek: sınırlı deneme, Retry-After ve rastgele sapma.
async function callWithBackoff(call, maxAttempts = 4) {
  for (let attempt = 0; attempt < maxAttempts; attempt++) {
    const response = await call();
    if (response.status === 410) throw new Error('MODEL_RETIRED');
    if (response.status !== 429) return response;

    const retryAfter = Number(response.headers.get('retry-after'));
    const waitMs = Number.isFinite(retryAfter)
      ? retryAfter * 1000
      : Math.min(1000 * 2 ** attempt + Math.random() * 250, 10000);
    await new Promise(resolve => setTimeout(resolve, waitMs));
  }
  throw new Error('RATE_LIMIT_RETRY_EXHAUSTED');
}

Uygulanan çözüm veya önerilen mimari

Uygulama ile sağlayıcı arasına ince bir model yönlendirme katmanı koyduk. İş akışları doğrudan değişken sağlayıcı adlarına değil, “hızlı özet” veya “yapılandırılmış analiz” gibi onaylı profil adlarına bağlandı. Her profil için birincil model, test edilmiş alternatif, context sınırı ve özellik gereksinimi tanımlandı. 410 alındığında profil devre dışı kalıyor, uygun fallback yoksa işlem anlaşılır mesajla duruyordu.

429 yönetiminde merkezi oran sınırlayıcı, öncelikli kuyruk ve eş zamanlılık sınırı kullanıldı. Etkileşimli çağrılar ile zamanlanmış toplu işler ayrı havuzlara alındı. Kullanıcıya ham sağlayıcı hatası yerine talebin sıraya alındığı veya daha sonra denenmesi gerektiği söylendi. Operasyon ekranında başarısızlık oranı, tüketim eğilimi, kuyruk yaşı ve model yaşam döngüsü alarmı birlikte izlendi.

Alternatifler ve karar gerekçesi

Her hatada başka modele geçmek erişilebilirliği artırabilir, ancak çıktı tutarlılığı ve maliyet kontrolünü zayıflatır. Hiç fallback kullanmamak davranışı öngörülebilir tutar fakat uygun işlerde gereksiz kesinti yaratır. Bu nedenle düşük riskli, test edilmiş iş akışlarında otomatik; kritik veya yapılandırılmış sonuçlarda kullanıcı onaylı ya da kontrollü geçiş tercih edildi. Model değişikliği her zaman telemetride görünür kaldı.

Kota artırmak 429 sıklığını azaltabilir, fakat kötü eş zamanlılık tasarımını ve gereksiz token kullanımını çözmez. Yalnızca istemci backoff’u da çok sayıda uygulama örneğinde yeterli olmayabilir. Merkezi kuyruk ile uygulama tarafı backoff’un birlikte kullanılması yükü dengeler. Birden fazla sağlayıcı seçeneği dayanıklılık sunar; veri işleme koşulları ve özellik uyumluluğu doğrulanmadan otomatik yönlendirme yapılmamalıdır.

Güvenlik ve operasyonel riskler

Hata ayıklama sırasında istemlerin tamamını, erişim anahtarlarını veya kullanıcı belgelerini loglamak ciddi veri riski yaratır. Kayıtlar korelasyon kimliği, durum kodu, model profili, süre ve güvenli hata sınıfıyla sınırlandırılmalıdır. Fallback sağlayıcısına geçiş veriyi farklı hukuki veya coğrafi koşullara taşıyabileceği için yalnızca önceden onaylanmış hedefler kullanılmalı, hassas veri sınıfları ayrı politika ile yönetilmelidir.

Kontrolsüz yeniden deneme maliyet artışı, çift işlem ve hizmet çökmesine yol açabilir. Devre kesici, toplam süre bütçesi, kuyruk sınırı ve iptal desteği bu nedenle önemlidir. Modelin emekliye ayrılması yalnızca teknik hata değil değişiklik yönetimi olayıdır; prompt, çıktı şeması ve güvenlik davranışı yeni modelde regresyon testinden geçmelidir. Sağlayıcı durum sayfası tek gözlem kaynağı olmamalıdır.

Çıkarılan Dersler

Kontrol Listesi

Yerel model denemeleri komut satırında başarılı olduğunda sıradaki doğal beklenti, çalışanların tarayıcıdan kullanabileceği sade bir arayüz oluyor. Bir pilotta Open WebUI kısa sürede kullanılabilir hale gelmişti; fakat sohbetlerin nerede tutulduğu, modele hangi ağ yolundan erişildiği ve güncellemede verinin korunup korunmayacağı sonradan soruldu. Teknik demo ile kurumsal servis arasındaki fark tam burada ortaya çıktı.

20 Temmuz 2026 tarihinde ele aldığımız mimaride Ollama model çalışma zamanı, Open WebUI kullanıcı katmanı ve Docker işletimi ayrı sorumluluk alanları olarak tasarlandı. Amaç internete açık bir deneme servisi oluşturmak değil; sınırlı kullanıcı grubuna, anonim test verileriyle başlayan ve güvenlik kontrolleri doğrulandıkça gelişen yönetilebilir bir yerel AI platformu kurmaktı.

Sorunun ortaya çıkışı

Windows iş istasyonunda Ollama modelleri çalışıyordu, ancak her kullanıcının komut satırı öğrenmesi ve model adlarını bilmesi beklenemezdi. Merkezi sohbet geçmişi, model seçimi ve belge yükleme gibi ihtiyaçlar doğdu. Docker Desktop üzerinde Open WebUI mantıklı bir arayüz seçeneğiydi. Buna karşın pilotun hangi kullanıcıya, hangi veriye ve hangi hizmet seviyesine sunulacağı tanımlanmadan yalnızca port yayınlamak riskliydi.

İlk tasarım görüşmesinde model sunucusu ile web konteyneri tek uygulama gibi konuşuluyordu. Oysa Ollama ağırlıkları yükleyip çıkarım yaparken Open WebUI kimlik, oturum, sohbet ve kullanıcı deneyimini yönetir. Docker ise paketleme ve çalışma ortamını sağlar. Sorun çıktığında hangi katmanın sorumlu olduğunu ayırabilmek için bile bu mimari sınırların açık yazılması gerekiyordu.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım, servis yerel bilgisayarda çalıştığı için yalnızca o bilgisayardan erişilebileceğiydi. Konteyner portunun tüm arayüzlere bağlanması veya güvenlik duvarı kuralı, hizmeti beklenenden geniş bir ağa açabilir. İkinci varsayım konteyner silinince yalnızca uygulamanın silineceğiydi; kalıcı volume tanımlanmamışsa kullanıcı ayarları ve sohbet kayıtları da kaybolabilir.

Bağlantı hatalarında da modelin bozuk olduğu düşünüldü. Asıl neden bazen konteyner içindeki “localhost” kavramının ana bilgisayarı değil konteynerin kendisini göstermesiydi. Windows, Docker ağı ve Ollama dinleme ayarı birlikte incelenmeden rastgele adres ve port değişiklikleri yapmak sorunu büyütebilirdi. Model listesi, servis sağlığı ve ağ yolu katman katman doğrulanmalıydı.

Teknik analiz

Akışı tarayıcıdan Open WebUI konteynerine, oradan Ollama API katmanına ve seçili modele kadar izledik. Her adım için dinlenen arayüz, ad çözümleme, güvenlik duvarı ve hata kaydı kontrol edildi. Sohbet verisi ile model dosyalarının aynı yerde tutulmadığı belirlendi. Bu ayrım yedekleme, kapasite ve silme taleplerinin doğru bileşende yönetilmesini sağladı.

Konteyner imajı sürümle sabitlendi, kalıcı veri için isimlendirilmiş volume kullanıldı ve yeniden başlatma davranışı belirlendi. Sağlık kontrolü yalnızca web sayfasının açılmasına değil, arayüzün model kataloğuna ulaşmasına göre düşünüldü. GPU ve RAM tüketimi Open WebUI’dan çok Ollama iş yüküyle ilişkili olduğundan kapasite ölçümleri model, context ve eş zamanlı oturum bazında kaydedildi.

# Örnek yalnızca yerel pilot içindir; güçlü kimlik ve ağ kısıtı ayrıca uygulanmalıdır.
docker volume create open-webui-data

docker run -d --name open-webui 
  --restart unless-stopped 
  -p 127.0.0.1:3000:8080 
  -v open-webui-data:/app/backend/data 
  ghcr.io/open-webui/open-webui:<onayli-surum>

# İmaj etiketini test edilmiş gerçek sürümle değiştirin; latest kullanmayın.

Uygulanan çözüm veya önerilen mimari

Pilot aşamada arayüz yalnızca ana bilgisayara bağlandı ve küçük bir kullanıcı grubuna kontrollü erişim sağlandı. Kurumsal yaygınlaştırma için TLS sonlandıran ters proxy, merkezi kimlik, rol bazlı model erişimi ve ağ segmentasyonu ayrı katman olarak önerildi. Ollama servisi doğrudan son kullanıcılara yayınlanmadı; yalnızca uygulama katmanının gerekli yoldan erişmesi hedeflendi.

Veri yaşam döngüsü ayrıca tasarlandı. Sohbet geçmişinin varsayılan saklama süresi, kullanıcı silme yöntemi, yönetici erişimi, yedekleme kapsamı ve belge yükleme kuralları açıklandı. Model güncellemesi kalite regresyonu yaratabileceği için onaylı model kataloğu tutuldu. Kullanıcı eğitiminde sistemin sınırları, doğrulama ihtiyacı ve hangi veri sınıflarının isteme yazılamayacağı anlatıldı.

Alternatifler ve karar gerekçesi

Komut satırı en az bileşenli yöntemdir ve teknik kullanıcıların kişisel denemeleri için uygundur; fakat kimlik, kullanım kolaylığı ve ortak yönetişim sınırlıdır. Masaüstü uygulamaları hızlı deneyim sunabilir, ancak merkezi politika ve sürüm yönetimi ürüne göre değişir. Open WebUI seçimi açık bir web katmanı ve çoklu model deneyimi sağladığı için yapıldı; her ortam için tek doğru olduğu iddia edilmedi.

Docker Desktop pilot için hızlı ve taşınabilir oldu. Sürekli, çok kullanıcılı hizmette Linux sunucu veya orkestrasyon platformu daha öngörülebilir işletim sağlayabilir; bunun karşılığında ek uzmanlık ve bakım gerekir. Bulut tabanlı arayüzler ölçek avantajı sunar, fakat veri yerleşimi ve sağlayıcı koşulları farklıdır. Karar, kullanıcı sayısı, veri sınıfı ve destek hedefiyle birlikte verilmelidir.

Güvenlik ve operasyonel riskler

En önemli risk, arayüzün kontrolsüz ağda yayınlanması ve kullanıcıların hassas doküman yüklemesidir. Varsayılan hesaplar kullanılmamalı, kayıt açma politikası sınırlandırılmalı ve yönetici rolleri ayrılmalıdır. Eklenti, araç ve dış web erişimi varsayılan olarak kapalı tutulmalı; etkinleştirilecekse veri çıkışı ile komut yetkileri ayrıca incelenmelidir. İmajlar güvenilir kaynaktan ve sabit sürümle alınmalıdır.

Operasyonda disk büyümesi, eski sohbetler, model indirmeleri ve loglar izlenmelidir. Ana bilgisayar yeniden başladığında servis sırası, Ollama erişimi ve sağlık alarmı test edilmelidir. Yedek yalnızca volume kopyalamak değildir; geri yükleme denenmeli ve kişisel veri saklama kuralları korunmalıdır. Arayüzün açılması hizmetin sağlıklı olduğu anlamına gelmediğinden örnek çıkarım testi izlemeye eklenmelidir.

Çıkarılan Dersler

Kontrol Listesi

Yerel yapay zekâ denemelerinde ilk soru genellikle “Bu bilgisayar kaç milyar parametreli model çalıştırır?” oluyor. Bir iş istasyonunda model gerçekten açılmış, fakat uzun belgelerde cevap süresi uzamış, bağlam büyüdüğünde GPU kullanımı değişmiş ve eş zamanlı kullanıcı düşünülünce deneyim sürdürülemez hale gelmişti. Teknik olarak çalışmak ile iş için kullanılabilir olmak aynı sonuç değildir.

17-20 Temmuz 2026 arasında Windows ve Ollama üzerinde yaptığımız değerlendirmede model adından önce kullanım profilini tanımladık. Kod yardımı, Türkçe metin özeti, görsel anlama ve araç çağırma farklı kalite ile kaynak beklentileri taşır. Amaç laboratuvar rekoru değil; veriyi kontrollü tutan, ölçülebilir ve desteklenebilir bir yerel AI hizmeti kurmaktı.

Sorunun ortaya çıkışı

Qwen ve Gemma sınıfındaki farklı modeller denenirken katalogdaki parametre sayısı ana seçim ölçütü yapılmıştı. Daha büyük modelin her görevde daha iyi olacağı kabul ediliyor, quantization düzeyi ile bağlam uzunluğunun bellek etkisi gözden kaçıyordu. Model dosyası GPU belleğine sığsa bile KV cache, çalışma zamanı payı, görüntü bileşeni ve işletim sisteminin kullandığı kaynaklar için yeterli boşluk kalmayabiliyordu.

İş beklentileri de tek listede toplanmıştı: doküman özetleme, kod üretimi, kurum içi soru-cevap, görsel analizi ve otomasyon. Oysa bir modelin Türkçe anlatımı güçlü olabilirken araç çağırma biçimi zayıf, başka bir model kodda iyi iken uzun bağlamda yavaş olabilirdi. Önce görevleri önem, veri hassasiyeti, beklenen doğruluk ve kabul edilebilir yanıt süresine göre ayırdık.

İlk belirtiler ve yanlış varsayımlar

İlk belirti GPU kullanımının bazı isteklerde yüksek, bazılarında beklenmedik biçimde düşük olmasıydı. Bu durum hemen sürücü arızası sanıldı. Gerçekte modelin bir bölümü sistem belleğine taşınıyor, uzun bağlam veya farklı quantization nedeniyle CPU-GPU paylaşımı değişiyordu. Token üretim hızı ile ilk token gecikmesi de tek metrik sanılmıştı; kullanıcı deneyiminde ikisi farklı etkiler yaratır.

“RAM iki katına çıkarsa hız iki katına çıkar” ve “daha düşük quantization her zaman kabul edilemez kalite verir” varsayımları da ölçümle doğrulanmadı. Sistem belleği modeli çalıştırmayı mümkün kılabilir, fakat GPU belleği darboğazını otomatik olarak çözmez. Quantization etkisi modele ve göreve göre değişir. Aynı örnek kümesiyle kalite, gecikme ve kaynak tüketimi ölçülmeden katalog bilgisine dayanmak güvenilir değildir.

Teknik analiz

Model ağırlıklarının yaklaşık bellek ihtiyacı parametre sayısı ve bit genişliğiyle tahmin edilebilir; ancak bu yalnızca başlangıçtır. Çalışma zamanı ek yükü, KV cache, context window, batch büyüklüğü ve eş zamanlı oturumlar ayrıca yer tüketir. VRAM dolduğunda katmanların RAM ve CPU tarafına taşınması kapasite sağlar, fakat veri yolu ve işlem hızı nedeniyle gecikmeyi artırabilir. Ölçüm bu nedenle gerçek istemlerle yapılmalıdır.

Test matrisine model sürümü, quantization, bağlam uzunluğu, GPU aktarım oranı, ilk token süresi, saniyedeki token, tepe VRAM/RAM ve görev kalitesi eklendi. Türkçe özet, teknik soru, güvenli kod inceleme ve uzun belge bulma gibi anonim örnekler sabitlendi. Vision ve tool desteği yalnızca katalogda var diye kabul edilmedi; arayüzün, şablonun ve agent katmanının bu yeteneği doğru kullanıp kullanmadığı da doğrulandı.

# Yalnızca yerel model envanteri ve çalışma durumunu gözlemleyin.
ollama list
ollama ps

# İşletim sisteminde GPU kullanımını üreticinin desteklenen aracıyla izleyin.
# Sonuçları aynı test metni ve aynı bağlam ayarıyla karşılaştırın.

Uygulanan çözüm veya önerilen mimari

Tek model yaklaşımı yerine kullanım profillerine göre küçük bir model kataloğu önerdik. Günlük hızlı işler için daha küçük ve dengeli quantize model, zor analiz için daha güçlü fakat kontrollü kullanılan model, görsel işler için ilgili yeteneği doğrulanmış ayrı seçenek tanımlandı. Varsayılan context gereksiz büyütülmedi; kullanıcıya görevine uygun profil sunuldu. Böylece donanım yükseltmeden önce mevcut kapasite daha verimli kullanıldı.

Ollama model sunumu ile web arayüzü ve erişim katmanı ayrı değerlendirildi. Kaynak ölçümleri merkezi kayda alınırken istem içeriği gereksiz yere loglanmadı. Kurumsal belge kullanımı için erişim kontrolü, saklama politikası ve RAG veri yetkileri model seçiminden bağımsız güvenlik gereksinimleri olarak ele alındı. Pilot sonuçları kabul eşiğini karşılamazsa donanım yatırımı somut ölçüme dayandırıldı.

Alternatifler ve karar gerekçesi

Tamamen yerel çalışma veri kontrolü ve çevrimdışı kullanım sağlar; buna karşılık ilk yatırım, enerji, bakım ve kapasite sınırı getirir. Bulut API seçenekleri ölçek ve güçlü modellere erişim sunabilir, ancak veri işleme koşulları, değişken maliyet, bağlantı ve sağlayıcı bağımlılığı değerlendirilmelidir. Hassas görevleri yerelde, uygun sınıftaki yoğun veya özel işleri onaylı hizmette çalıştıran hibrit yaklaşım birçok kurum için dengelidir.

Tek büyük GPU almak sade görünür; birden fazla kullanıcı, yüksek erişilebilirlik veya büyüme hedefinde iş istasyonu mimarisi kısa sürede sınır olabilir. CPU ağırlıklı çalışma düşük başlangıç maliyetiyle deneme sağlar fakat etkileşimli kullanımda yavaş kalabilir. Kararı en yüksek parametreye göre değil, hedef görevlerin yüzde kaçını kabul edilen kalite ve sürede karşıladığına göre vermek daha savunulabilir oldu.

Güvenlik ve operasyonel riskler

Yerel model kullanmak verinin otomatik olarak güvende olduğu anlamına gelmez. Web arayüzü, sohbet geçmişi, yüklenen belgeler, eklentiler ve yedekler ayrı veri yüzeyleridir. Servis yalnızca gerekli ağ alanından erişilmeli, güçlü kimlik doğrulama uygulanmalı, modeller ile konteynerler güvenilir kaynaklardan alınmalı ve güncellemeler önce test ortamında doğrulanmalıdır. Gizli anahtarlar istemlere veya model dosyalarına eklenmemelidir.

Model çıktıları doğru görünse de hatalı olabilir; özellikle yapılandırma, hukuk, insan kaynakları ve güvenlik kararlarında insan onayı gerekir. Araç çağıran modellerin dosya ve terminal izinleri varsayılan olarak sınırlandırılmalı, çalışma alanı ayrılmalı ve yıkıcı eylemler açık onaya bağlanmalıdır. Kaynak tükenmesi, disk büyümesi ve model sürümü değişikliğine karşı kapasite, yedekleme ve geri dönüş planı tutulmalıdır.

Çıkarılan Dersler

Kontrol Listesi