T.C. İçişleri Bakanlığı: Adli Bilişim Yazılım Mühendisi

2019'dan bu yana T.C. İçişleri Bakanlığı'nda Adli Bilişim Yazılım Mühendisi olarak görev yapıyorum. Bu dönem, önceki robotik, gömülü sistem, bilgisayarlı görü ve performans mühendisliği deneyimlerimin yüksek hacimli, uzun süre çalışan ve gerçek zaman gereksinimi bulunan kurumsal sistemlerle birleştiği mesleki çalışma alanımdır.

Çalışmalarım adli bilişim, yapay zeka, büyük ölçekli veri işleme, ses ve konuşma teknolojileri, görüntü işleme, tersine mühendislik, veri tabanı sistemleri ve performans mühendisliği eksenlerinde ilerliyor. Java/Spring Boot, C/C++, C#/.NET ve Python farklı katmanlarda kullandığım temel geliştirme ortamlarıdır; Oracle ağırlıklı ilişkisel veri sistemleri, Linux ve performans duyarlı native bileşenler de günlük mühendislik problemlerinin parçasıdır.

Kamuya açık mesleki anlatım; kurum içi proje adları, kod yapıları, tablo/şema ayrıntıları, veri kümeleri, sunucu veya ağ topolojileri, kullanıcı/yetki modelleri ve ayırt edici güvenlik ayrıntılarını içermez. Aşağıdaki bölümler paylaşılabilir problem sınıfları, mühendislik yöntemleri ve kişisel çalışma alanlarıyla sınırlıdır.

Büyük Ölçekli Kurumsal Yazılım Sistemleri

Java ve Spring Boot ile yüksek hacimli kurumsal arka uç ve servis yazılımları geliştiriyorum. Bu sistemlerde işin önemli bölümü bir HTTP isteğini alıp veri tabanına yazmaktan ibaret değildir. Çok sayıda eşzamanlı işlem, farklı veri kaynakları, uzun süre açık kalan servisler, hata sonrası toparlanma ve kullanıcı tarafında düşük gecikme beklentisi aynı mimari içinde ele alınmak zorundadır.

Üretim sistemlerinde bir bileşenin tek başına hızlı çalışması yeterli değildir. Veri tabanı bağlantısı bekleniyorsa CPU optimizasyonunun etkisi sınırlı kalabilir; dosya I/O'su kuyruğu dolduruyorsa daha fazla thread yalnız baskıyı artırabilir; ağ tarafında gecikme varsa uygulama katmanındaki küçük optimizasyonlar kullanıcı tarafından hissedilmeyebilir.

Bu nedenle sistemi uçtan uca ölçülebilir bir işlem hattı olarak ele alıyorum. Tasarım kararları latency, throughput, concurrency, kaynak sınırları ve hata davranışına göre veriliyor.

Gerçek Zamanlı ve Uzun Süre Çalışan Servisler

Gerçek zamanlı bir sistem için "hızlı" kelimesi tek başına yeterli değildir. Önemli olan gerekli işin öngörülebilir süre içinde tamamlanması ve sistem yük altında da davranışını koruyabilmesidir.

Uzun süre çalışan servislerde kısa süreli benchmark sonuçlarından daha farklı problemler ortaya çıkar: bağlantı havuzunun doygunluğu, bellek büyümesi, bekleyen kuyrukların kontrolsüz artışı, thread starvation, tekrar denemelerin yükü büyütmesi veya dış sistemlerdeki geçici sorunların bütün servisi etkilemesi gibi.

Bu nedenle kaynakların sınırsızmış gibi kullanıldığı tasarımlardan kaçınıyorum. Kuyruk, bağlantı, thread veya paralel görev sayısının kapasite sınırları olmalı; sistem doygunluğa yaklaştığında kontrollü biçimde geri basınç üretebilmeli ve bir arızanın etkisini mümkün olduğunca lokal tutabilmelidir.

Burada güvenilirlik yalnız "servis kapanmadı" anlamına gelmez. Sistem ayakta kalırken kuyruk gecikmesi sürekli büyüyorsa, kullanıcı talepleri zaman aşımına uğruyorsa veya arka planda veri birikiyorsa işlevsel olarak kararlı değildir.

Java, Spring ve Concurrency

Java/Spring tabanlı servislerde concurrency modelini yalnız kullanılan framework'e bırakmıyorum. İş yükünün CPU-bound mı I/O-bound mı olduğu, transaction süresi, veri tabanı bağlantı havuzu ve aynı anda çalışabilecek gerçek iş miktarı birlikte değerlendirilmelidir.

Thread sayısını artırmak kapasiteyi otomatik olarak artırmaz. Eğer dar kaynak veri tabanı bağlantısı veya dış servis ise daha fazla eşzamanlı istek yalnız daha uzun kuyruk oluşturabilir.

Java'nın güncel concurrency özellikleri, klasik thread pool'lar ve gerektiğinde virtual thread gibi araçları iş yükünün yapısına göre değerlendiriyorum. Ama teknoloji seçiminin önünde her zaman aynı soru var: hangi kaynak gerçekten sınırlı ve sistem yük altında nerede bekliyor?

Eşzamanlılık sorunlarında yalnız race condition değil, starvation, lock contention, yanlış timeout zinciri ve gereksiz context switching de sistem davranışını etkileyebilir. Bir problemi çözmek için kilit eklemek doğru olabilir; ancak kritik bölgede bekleyen thread sayısı ve kilidin tutulma süresi ölçülmeden bunun throughput üzerindeki maliyeti bilinemez.

Oracle, Veri Erişimi ve Transaction Sınırları

Oracle tabanlı kurumsal veri sistemleriyle uzun süre çalışmak, uygulama performansının önemli bölümünün veri erişimiyle ilişkili olduğunu açık biçimde gösterdi.

Bir SQL sorgusunun yalnız doğru sonuç üretmesi yeterli değildir. Yürütme planı, indeks kullanımı, cardinality tahmini, getirilen satır miktarı, transaction kapsamı, kilitlenme davranışı ve bağlantının ne kadar süre tutulduğu birlikte değerlendirilmelidir.

ORM veya repository kullanılması bu maliyeti ortadan kaldırmaz; yalnız soyutlar. Bu nedenle Java katmanındaki entity ve sorgu davranışını Oracle'ın gerçek yürütme modeliyle birlikte inceliyorum.

Transaction sınırlarını gereğinden büyük tutmak bağlantı havuzunu ve kilit sürelerini etkileyebilir. Çok küçük parçalamak ise atomiklik ve iş tutarlılığı problemleri doğurabilir. Buradaki hedef belirli bir framework kalıbını izlemek değil, iş biriminin gerçekten hangi noktada atomik olması gerektiğini belirlemektir.

Veri tabanı davranışında duplicate veya eski veri gibi gerçek dünya sorunlarını da "şemada olmaması gerekir" diyerek yok saymamak gerekir. Üretim sistemi, ideal veri modelinden çok fiilen bulunan veriyle çalışır. Bu nedenle okuma, sıralama, tekilleştirme ve hata modelinin mevcut veri gerçekliğine dayanması gerekir.

Bağlantı Havuzu ve Kapasite Yönetimi

Yüksek trafikli sistemlerde connection pool konfigürasyonu performansın kritik parçalarından biridir. Pool'u çok büyütmek veri tabanının kapasitesini artırmaz; aksine daha fazla eşzamanlı sorguyla contention oluşturabilir. Çok küçük pool ise uygulamada gereksiz bekleme yaratabilir.

Bu nedenle bağlantı havuzunu yalnız "maksimum kaç bağlantı?" sorusuyla ele almıyorum. Transaction süresi, sorgu latency'si, eşzamanlı iş sayısı, veri tabanı tarafındaki gerçek kapasite ve hata anındaki davranış birlikte düşünülmelidir.

Ayrıca havuz doygunluğu ile uygulama thread'lerinin davranışı birlikte ölçülmelidir. Bir kaynak tükendiğinde sonsuz bekleme yerine tanımlı timeout ve kontrollü hata davranışı sistemin güvenilirliğinin parçasıdır.

Pool metriklerini tek başına yorumlamak da yeterli değildir. Aktif bağlantı sayısı yüksekken sistem sağlıklı olabilir; önemli olan bekleyen istek, işlem süresi ve veri tabanı tarafındaki gerçek çalışma yüküdür.

C ve C++ ile Performans Duyarlı İşleme

Yoğun veri, sinyal veya medya işlemede daha açık bellek ve paralellik kontrolüne ihtiyaç duyulan durumlarda C ve C++ kullanıyorum. Buradaki amaç yalnız daha düşük seviyeli kod yazmak değil; SIMD, native kütüphaneler, bellek yerleşimi ve paralel yürütme üzerinde daha doğrudan kontrol sağlamaktır.

Performans optimizasyonunda algoritmik karmaşıklık ilk kontrol noktasıdır. Daha sonra bellek erişimi, allocation, kopyalama, cache davranışı ve paralel yürütme incelenir.

Bir optimizasyonu teorik olarak daha hızlı olduğu için üretime taşımıyorum. Önce darboğazın gerçekten ilgili kodda olduğunu ölçmek, sonra mümkün olduğunca tek değişkeni değiştirip sonucu yeniden ölçmek gerekir.

Düşük seviyede yapılan küçük bir optimizasyon, üst katmanda veri iki kez kopyalanıyorsa anlamsız olabilir. Aynı şekilde SIMD ile hızlanan bir döngü toplam sürenin küçük kısmını oluşturuyorsa kullanıcı tarafından fark edilmeyebilir. Amdahl yaklaşımının pratik karşılığı budur.

IBM POWER9, SIMD, OpenMP ve CUDA

Performans duyarlı adli bilişim ve yapay zeka çalışmalarında farklı işlemci mimarileri ve heterojen hesaplama sistemleriyle çalıştım. IBM POWER9 AC922 üzerindeki çalışmalarım, CPU tarafında AltiVec/VSX ve OpenMP ile GPU tarafında CUDA/Tesla V100 kullanımını aynı hesaplama ortamında değerlendirdiğim örneklerden biridir.

Burada performans sorusu "GPU mu CPU mu daha hızlı?" kadar basit değildir. İş yükünün veri boyutu, vectorization'a uygunluğu, bellek bant genişliği, CPU/GPU veri transferi ve eşzamanlı çalışan diğer süreçler sonucu değiştirebilir.

Bazı işler GPU'ya uygunken bazı küçük veya düzensiz işlerin CPU'da kalması daha düşük toplam gecikme sağlayabilir. Bu nedenle hesaplama mimarisini algoritmanın yapısına göre seçiyorum.

Farklı mimarilerde derleme ve bağımlılık davranışı da önemlidir. x86 üzerinde sorunsuz çalışan bir native bileşenin ppc64le veya farklı SIMD setinde aynı varsayımlarla çalışacağı kabul edilemez. Derleyici, ABI, kütüphane sürümü ve platform özelliği üretim davranışının parçasıdır.

Yapay Zeka Bir Model Dosyasından İbaret Değildir

Kurum içindeki yapay zeka çalışmalarında modeli bağımsız bir demo olarak ele almıyorum. Gerçek bir sistemde modelin önünde veri hazırlama, arkasında sonuç işleme vardır; ayrıca kuyruklama, doğrulama, kaynak paylaşımı ve hata yönetimi gerekir.

Model kalitesi yüksek olsa bile preprocessing hatalıysa üretim sonucu bozulabilir. Inference hızlı olsa bile kuyruğa giren işler uzun süre bekliyorsa kullanıcı gecikmesi yüksek kalır. GPU verimli kullanılıyor olsa bile CPU preprocessing yetişemiyorsa toplam throughput sınırlanabilir.

Bu nedenle yapay zeka bileşenlerini her zaman uçtan uca veri hattı içinde ölçüyorum. Modelin latency'si, end-to-end latency ile aynı değildir; model throughput'u da sistem throughput'u değildir.

Model sürümü, tokenizer veya preprocessing değişikliği gibi dışarıdan küçük görünen güncellemeler çıktıyı etkileyebilir. Bu nedenle model ve çevresindeki veri sözleşmesini birlikte sürümlendirmek önemlidir.

Otomatik Konuşma Tanıma

Konuşma tanıma uzun süredir çalıştığım alanlardan biridir. Ses dosyasını modele verip metni almak, üretim ASR sisteminin yalnız küçük bir bölümüdür.

Gerçek sistemlerde format doğrulama, kanal seçimi, örnekleme, ses etkinliği algılama, segmentasyon, model inference, zaman bilgisi, sonuç birleştirme ve hata yönetimi birlikte çalışır.

Uzun seslerde segment sınırı transcript kalitesini etkileyebilir. Çok kısa parçalar bağlam kaybı oluşturabilir; çok uzun parçalar gecikmeyi ve bellek kullanımını artırabilir. Konuşma başlangıç ve bitiş kararının birkaç yüz milisaniye kayması bile kullanıcı tarafından hissedilen latency'yi etkileyebilir.

Whisper mimarisi ve konuşma tanıma sistemleri üzerine teknik notlarımda model tarafını; üretim çalışmalarımda ise modelin çevresindeki segmentasyon ve sistem davranışını birlikte ele alıyorum.

Gerçek Zaman Katsayısı, Queueing ve Kapasite

ASR performansında RTF önemli bir ölçüdür; ancak tek başına sistem kapasitesi değildir. RTF < 1 tek bir akışın medyadan hızlı işlendiğini gösterebilir. Aynı anda çok sayıda iş geldiğinde queueing, GPU paylaşımı, CPU preprocessing ve I/O sistemin gerçek kapasitesini belirler.

Bu nedenle medya süresi ile işlem süresini ayrı ölçüyor, inference süresini kullanıcıya görünen uçtan uca latency ile karıştırmıyorum.

Bir model daha hızlı olabilir; fakat daha fazla bellek tüketiyorsa eşzamanlı çalışabilecek worker sayısını azaltabilir. Sistem seviyesinde doğru karar, tek inference benchmark'ından değil toplam kapasite ve gecikme hedefinden çıkar.

Kuyruk uzunluğu kadar en eski işin yaşı da önemlidir. Kuyruk sabit görünürken bazı uzun işlerin sürekli geriye itilmesi starvation üretebilir. Gerçek zamanlı ve tarihsel işlerin aynı FIFO içinde sınırsız birikmesi de güncel verinin gecikmesine neden olabilir.

Konuşmacı Tanıma ve Ses İşleme

Konuşma tanımanın yanında konuşmacı tanıma, ses iyileştirme ve genel sinyal işleme problemleri üzerinde çalışıyorum.

Konuşmacı tanımada özellik veya embedding kalitesi kadar segmentin gerçekten ilgili konuşmacıya ait olması, yeterli konuşma içermesi ve kanal/gürültü koşullarının değerlendirilmesi önemlidir. Yanlış segmentasyon, güçlü bir eşleştirme modelini dahi anlamsız hale getirebilir.

Ses iyileştirmede de hedef her zaman "sesi daha temiz duymak" değildir. Yapılan filtreleme sonraki ASR veya analiz algoritmasının kullandığı bilgiyi bozmamalıdır. Bir insan kulağına daha hoş gelen çıktı, model için daha doğru giriş olmak zorunda değildir.

Sinyal işleme çalışmalarında örnekleme frekansı, kanal yerleşimi, PCM gösterimi ve zaman referansı gibi ayrıntılar sistemler arasında açık bir sözleşmeye bağlanmalıdır. Zaman bilgisini farklı katmanlarda farklı biçimde hesaplamak segment ve oynatma hatalarına dönüşebilir.

Görüntü İşleme ve Yüz Tanıma

Görüntü işleme, yüz algılama ve yüz tanıma sistemleri de profesyonel çalışma alanlarım arasındadır. Burada detection, alignment, feature extraction / embedding, benzerlik ve karar eşiğini ayrı aşamalar olarak değerlendiriyorum.

Bir yüz tanıma modelinin benchmark doğruluğu, gerçek uygulamanın bütün performansını göstermez. Görüntü kalitesi, yüz boyutu, poz, ışık, detector hatası ve threshold seçimi sonuç üzerinde doğrudan etkilidir.

Benzerlik aramasında da indeksin yalnız hızlı olması yeterli değildir. Recall, bellek tüketimi, güncelleme maliyeti ve eşzamanlı sorgu davranışı birlikte değerlendirilmelidir.

Model veya indeks tasarımında false match ile missed match maliyeti aynı olmayabilir. Eşik seçimi teknik olarak tek bir "en iyi" değerden çok kullanım senaryosunun hata maliyetine bağlıdır.

Veri Hazırlama ve Medya İşleme

AI sistemlerinde veri hazırlamanın maliyeti sıklıkla modelin arkasında görünmez. Ses/video decode, kanal dönüştürme, yeniden örnekleme, kare çıkarma, ölçekleme veya normalizasyon gibi işler CPU ve I/O tüketir.

Python tarafında FFmpeg/OpenCV gibi araçlar ve native kütüphanelerle oluşturduğum veri hatlarında gereksiz dönüştürme ve kopyaları azaltmaya çalışıyorum. Aynı veriyi birden fazla kez decode etmek veya disk üzerinde geçici dosyaya gereksiz yere yazmak throughput'u ciddi biçimde etkileyebilir.

Streaming ile bütün veriyi belleğe almak arasında da bilinçli seçim yapılmalıdır. Büyük medya dosyalarında bounded buffer kullanımı hem bellek tüketimini hem failure recovery davranışını daha öngörülebilir hale getirebilir.

Adli Bilişimde Veri İşleme ve Provenance

Adli bilişim açısından bir algoritmanın sonucu kadar verinin nasıl işlendiği de önemlidir. Girdi kaynağı, dönüşümler, üretilen ara veriler ve sonuç arasındaki ilişki izlenebilir olmalıdır.

Adli analizde "aynı dosyayı verdim, farklı sonuç çıktı" kabul edilmesi zor bir durumdur. Model veya algoritma nondeterministic davranıyorsa bunun sınırları bilinmeli; sürüm, parametre ve çalışma ortamı kayıt altında tutulmalıdır.

Bu nedenle veri bütünlüğü ve yeniden üretilebilirlik, yalnız akademik deneylerde değil üretim adli bilişim yazılımlarında da tasarım kriteridir.

Provenance kaydı, kişisel veya operasyonel veriyi gereksiz yere çoğaltmak anlamına gelmemelidir. İzlenebilirlik ile veri minimizasyonu birlikte tasarlanmalıdır.

File Carving ve Özel Veri Biçimleri

File carving, ikili veri yapılarını çözümleme, özel dosya biçimlerini inceleme ve veri kurtarma çalışmalarım adli bilişim tarafının önemli parçalarıdır.

Burada yalnız bilinen header/footer imzalarını aramak her zaman yeterli değildir. Fragmentation, yanlış pozitifler, büyük dosyalar, veri bütünlüğü ve format içi yapısal doğrulama birlikte değerlendirilebilir.

Özel veya belgelenmemiş veri biçimlerinde dosyayı üreten uygulamanın davranışını gözlemlemek, örnekler arasında değişen byte bölgelerini karşılaştırmak ve alanların anlamını hipotezlerle çözümlemek gerekir.

Parser tasarımında bozuk veya kasıtlı olarak hazırlanmış girdiyi de hesaba katmak gerekir. Boyut alanına kör güvenmek, kontrolsüz allocation veya sınır dışı okuma gibi güvenilirlik ve güvenlik problemleri doğurabilir.

Tersine Mühendislik

Tersine mühendislik çalışmalarında statik ve dinamik yazılım analizi, dosya ve protokol davranışlarının çözümlenmesi ve gerektiğinde aynı davranışın farklı bir dil veya çalışma ortamında yeniden gerçekleştirilmesi üzerinde çalışıyorum.

Buradaki hedef her zaman binary'yi tamamen decompile etmek değildir. Çoğu zaman asıl ihtiyaç belirli bir girdiye karşı hangi çıktının üretildiğini, verinin nasıl kodlandığını veya bir protokol mesajının hangi alanlardan oluştuğunu anlamaktır.

Davranış odaklı yaklaşım, özellikle eski veya dokümantasyonu bulunmayan sistemlerle entegrasyonda daha verimli olabilir.

Reverse engineering sonucunda geliştirilen yeniden gerçekleme için test vektörleri önemlidir. Aynı girdide eski ve yeni uygulamanın çıktısını karşılaştırmak, gözlenen davranışın gerçekten korunup korunmadığını gösterir.

Ağ Trafiği ve PCAP Analizi

PCAP ve ağ trafiği analizi adli ve tersine mühendislik çalışmalarının başka bir boyutudur. Paketleri yalnız protocol analyzer ekranında tek tek okumak yerine akış, oturum ve mesaj yapısı olarak ele alıyorum.

Bir protokol standartsa dokümantasyonla karşılaştırmak mümkündür. Özel protokollerde ise tekrar eden alanlar, uzunluklar, sıra numaraları ve istek-cevap ilişkileri üzerinden yapı çıkarmak gerekir.

Ağ trafiğinin doğru yorumlanması için capture noktası ve zamanlama da önemlidir; görülmeyen paket "gönderilmedi" anlamına gelmeyebilir.

Yüksek hacimli capture dosyalarında bütün paketi nesneleştirerek bellekte tutmak yerine streaming veya indeksli yaklaşım gerekebilir. Analiz algoritmasının veri yapısı, dosya boyutuyla birlikte ölçeklenmelidir.

Kriptoloji ve Güvenli Veri İşleme

Kriptografik özetler, şifreleme, kimlik doğrulama ve erişim kontrolü çalışmalarımda güvenliği sonradan eklenen bir özellik olarak görmüyorum.

Hash bir şifreleme değildir; encryption bütünlük garantisi değildir; yetkilendirme ile kimlik doğrulama aynı problem değildir. Tasarım sırasında bu sınırları açık tutmak, ileride "güvenlik var" denilen fakat aslında yanlış primitive kullanan yapılardan kaçınmayı sağlar.

Anahtar, secret veya kurumsal güvenlik mekanizmalarının ayrıntıları kamuya açık içerikte yer almaz. Teknik yazılarımda yalnız genel güvenlik ilkeleri ve uygulanabilir mühendislik yöntemleri üzerinde duruyorum.

Güvenli veri işleme aynı zamanda log, hata mesajı ve geçici dosya gibi yan kanalları da kapsar. Ana veri şifreli olsa dahi debug log'u hassas bilgiyi açık biçimde tutuyorsa sistemin veri koruma sınırı kırılabilir.

Güvenilir Hata Yönetimi ve Retry

Dağıtık ve veri tabanı ağırlıklı sistemlerde her hata tekrar denenebilir değildir. Ağ kopması, timeout, transaction rollback, validation hatası veya yetki reddi aynı retry politikasına girmemelidir.

Özellikle yazma işlemlerinde sonuç belirsizse kör retry duplicate yan etki üretebilir. Idempotency, işlem anahtarı, bounded retry, backoff ve toplam zaman bütçesi bu nedenle hata yönetiminin parçasıdır.

Bu yaklaşımı kritik sistemlerde güvenli yeniden deneme tasarımı gibi kamuya açık teknik yazılarda genelleyerek ele alıyorum.

Retry'nin kendisi kapasite üretmez. Hedef sistem zaten doygunsa ek denemeler kuyruğu ve bağlantı baskısını büyütebilir. Retry ile backpressure ve circuit-breaker benzeri koruma mekanizmaları aynı failure modelinin parçalarıdır.

Dosya Sistemi, NFS ve Atomik Yayınlama

Uzun süre çalışan veri işleme sistemlerinde dosya sisteminin davranışı da uygulama mimarisinin parçasıdır. Bir dosyanın adı görünür hale geldi diye bütün verinin kalıcı olarak diske yazıldığı varsayılamaz; local filesystem ile NFS davranışı da aynı değildir.

Geçici dosyaya yazma, flush/sync, rename ve dizin kalıcılığı gibi ayrıntılar özellikle başka süreçlerin aynı çıktıyı okuyacağı pipeline'larda önemlidir.

Bu tür problemleri dosya işlemede atomik yayınlama gibi teknik notlarımda genel sistem mühendisliği seviyesinde ele alıyorum; kurum içi dosya yapıları veya operasyonel dizinler paylaşılmamaktadır.

Dosya yayınlama sözleşmesi idempotency ile de ilişkilidir. Aynı iş tekrar çalıştığında hedef dosyanın ne olacağı ve kısmi çıktının tüketici tarafından görülüp görülmeyeceği önceden belirlenmelidir.

Gözlemlenebilirlik ve Ölçüm

Kritik sistemde log sayısını artırmak gözlemlenebilirlik değildir. Hangi metriğin hangi soruyu cevapladığı belirli olmalıdır.

Latency dağılımı, throughput, queue depth, connection wait, error class, resource saturation ve işlem süresi gibi metrikleri sistem davranışını açıklamak için kullanıyorum. Ortalama değer tek başına tail latency veya ani doygunluğu gizleyebilir.

Aynı şekilde logların içerdiği veri de güvenlik ve gizlilik sınırına tabidir. Kişisel veya hassas veriyi debug kolaylığı için gereksiz yere loglamak doğru değildir.

Ölçümün kendisi de sistemi bozmayacak kadar düşük maliyetli olmalıdır. Hot path üzerinde aşırı ayrıntılı log veya yüksek cardinality metric üretmek gözlemlenebilirlik adına yeni performans problemi oluşturabilir.

Deterministik ve Tekrarlanabilir Davranış

Kritik sistemlerde aynı girdinin mümkün olduğunca aynı sonucu ve aynı yan etki modelini üretmesi önemlidir. Concurrency, rastgelelik, zaman bağımlılığı veya dış servis davranışı bunu zorlaştırabilir.

Bu nedenle deterministik sıralama, açık timeout, kontrollü retry, idempotent işlem ve sürüm bilgisi gibi mekanizmaları tasarımın doğal parçası olarak görüyorum.

AI sistemlerinde mutlak determinism her zaman mümkün olmayabilir; o durumda nondeterministic alanın neresi olduğu ve hangi toleransla kabul edildiği açık olmalıdır.

Testlerde de yalnız normal yol değil, timeout, partial input, duplicate data, kaynak doygunluğu ve yeniden başlatma gibi hata senaryoları değerlendirilmelidir. Kritik sistem güvenilirliği yalnız "happy path" testinden çıkarılamaz.

Performans ve Güvenilirlik Arasındaki Denge

En hızlı çözüm her zaman en iyi üretim çözümü değildir. Bir optimizasyon throughput'u artırırken memory footprint'i veya failure blast radius'u büyütebilir.

Benim için performans mühendisliği yalnız benchmark kazanmak değil, sistemin beklenen yük altında daha öngörülebilir çalışmasını sağlamaktır. Bu nedenle latency, throughput, kaynak tüketimi, hata davranışı ve bakım maliyetini birlikte değerlendiriyorum.

Gereksiz abstraction veya allocation hot path üzerinde maliyet oluşturuyorsa azaltırım; fakat kanıtlanmış doğru davranışı küçük bir hız kazancı için belirsiz hale getirmem.

Özellikle kritik sistemlerde deterministik ve anlaşılır bir çözümün, mikro benchmark'ta daha hızlı fakat operasyonel davranışı belirsiz bir yapıdan daha değerli olduğu durumlar vardır.

Teknoloji Seçiminde Pragmatizm

Java/Spring Boot, C/C++, C#/.NET ve Python'u birbirinin alternatifi olarak görmüyorum. Her biri farklı problem sınıflarında daha uygun olabilir.

Java büyük kurumsal servislerde güçlü concurrency ve ekosistem sağlar. C/C++ performans duyarlı ve native işlerde kontrol verir. Python AI ve veri işleme ekosisteminde geliştirme hızını artırır. C#/.NET masaüstü, analiz ve kullanıcı araçlarında güçlüdür.

Doğru mimari bu dilleri mümkün olduğunca az sayıda sınırla, veri kopyası ve operasyonel karmaşıklığı kontrol altında tutacak biçimde birleştirmektir.

Bir teknoloji yeni olduğu için değil, sistemin doğruluk, performans, bakım ve operasyon gereksinimini daha iyi karşıladığı için seçilmelidir.

Akademik ve Teknik Yazıyla İlişkisi

Mesleki çalışmalarım ile akademik/teknik yazılarımı birbirinden tamamen kopuk görmüyorum. Kamuya açık makalelerde kurum içi ayrıntı paylaşmadan, üretimde tekrar tekrar karşılaştığım genel mühendislik problemlerini kaynaklar ve yeniden üretilebilir örneklerle ele alıyorum.

Konuşma ve görüntü işleme üzerine akademik çalışmalarım, Görüntü ve Ses İşleme kitap bölümüm ve adli bilişim / siber güvenlik eğitimim üretim mühendisliği deneyimiyle aynı problem uzayının farklı katmanlarını besliyor.

Akademik kaynak bir kavramın nedenini ve sınırlarını verir; üretim deneyimi ise hangi varsayımın gerçek veri ve yük altında bozulduğunu gösterir. Teknik yazılarımda bu iki bilgi türünü birbirine karıştırmadan birlikte kullanmaya çalışıyorum.

Gizlilik Sınırı

Kurum içi proje adlarını, kesin operasyonel sayıları, veri kümelerini, şema/topoloji ayrıntılarını ve ayırt edici güvenlik bilgilerini yayımlamıyorum. Buna karşılık problem sınıfını, veri akışını, hata modelini, ölçüm yöntemini ve genellenebilir mühendislik kararını anlatmak çoğu teknik konuyu anlaşılır kılmak için yeterli oluyor.

Kamuya açık bir örneği genellerken gizli ayrıntının yerini uydurma bir ayrıntıyla doldurmuyorum; yalnızca tanımlayıcı kısmı çıkarıp teknik davranışı koruyorum. Böylece metin, çalışmanın gerçek mühendislik bağlamını taşırken kurum veya sistem hakkında gereksiz bilgi üretmiyor.

Mühendislik Yaklaşımım

2019'dan bu yana farklı diller, modeller ve altyapılar kullansam da sorun çözme biçimim büyük ölçüde aynı kaldı. Önce gözlenebilir semptomu tanımlıyor, darboğazın veya hata sınırının gerçekten nerede olduğunu ölçüyor, sonra mümkün olduğunca az değişkeni değiştirip sonucu yeniden karşılaştırıyorum.

Bu yaklaşım Oracle sorgusunda da ASR kuyruğunda da GPU kernel'inde de işe yarıyor. Benim için üretim optimizasyonunun temel ölçütü, kanıtlanmış doğru davranışı koruyarak sistemi daha öngörülebilir hale getirmektir.