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

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

2019'dan bu yana adli bilişim ve yazılım mühendisliği; yüksek hacimli kurumsal sistemler, Java/Spring, Oracle, C/C++, Python, veri akışı mühendisliği, Apache NiFi, yapay zeka, ses ve görüntü işleme, sistem performansı ve güvenilirliği.

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.

Kurumsal Yazılım Mimarileri ve Yüksek Hacimli Veri İşleme

Java ve Spring Boot ile yüksek hacimli kurumsal arka uç ve servis yazılımları geliştiriyorum. Bu sistemlerin mühendisliği, HTTP isteklerinin işlenmesinin yanında eşzamanlı görevler, veri erişimi, süreklilik ve hata toleransı gereksinimlerini kapsar. Ç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 sistemlerinin başarımı, tüm bileşenlerin birlikte oluşturduğu uçtan uca çalışma davranışıyla değerlendirilir. 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.

Veri Akışı Mühendisliği ve Apache NiFi

Veri akışı yönetiminde, işleme aşamalarının birbirinden ayrılması, veri kökeninin izlenebilmesi, kaynak tüketiminin sınırlandırılması ve işlem sözleşmelerinin açık tanımlanması üzerinde çalışıyorum. Apache NiFi bu kavramları FlowFile, ProcessSession, kuyruk, ilişki, controller service ve veri kökeni mekanizmaları üzerinden ele alan açık kaynaklı bir platformdur.

Java ile NiFi Custom Processor geliştirme çalışmalarında Processor API, PropertyDescriptor, ilişki tanımları, onTrigger() yaşam döngüsü, FlowFile içerik akışları, ProcessSession işlem bütünlüğü, kaynak sınırlandırma, geri basınç ve hata yönlendirme başlıklarını birlikte değerlendiriyorum. Özel işlemci tasarımında sınırlı bellek kullanımı, eşzamanlı çalışmanın doğruluğu ve tekrar işleme sırasında yan etkilerin denetimi temel ölçütlerdir.

Bu konunun yazılım geliştirme boyutu, kamuya açık Java ile NiFi Özel İşlemci Geliştirme makalemde bağımsız teknik çerçevede açıklanmıştır. Anlatım, herhangi bir kurumsal veri akışı veya özel işleme mimarisi hakkında teknik açıklama niteliği taşımaz.

Analitik Veri Sistemleri ve ClickHouse

Yüksek hacimli ve sürekli veri üreten sistemlerde ClickHouse ile sütun yönelimli analitik veri işleme üzerinde çalışıyorum. Bu çalışmalar telemetri ve olay verilerinin çözümlenmesini, günlük (log) analizini, anomali algılamayı ve yapay zeka uygulamalarına yönelik analitik veri hazırlamayı kapsamaktadır. Veri alım kapasitesi, sorgu gecikmesi, veri tazeliği, sıkıştırma, toplulaştırma maliyeti ve kaynak tüketimi, iş yükünün gereksinimlerine göre birlikte değerlendirilmektedir.

Gerçek Zamanlı ve Sürekli Çalışan Servis Mimarileri

Gerçek zamanlı sistemler için temel ölçüt, tanımlı işlemlerin öngörülebilir zaman sınırlarında tamamlanmasıdır. Ö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.

Güvenilirlik, servis sürekliliğinin yanında kuyruk kararlılığını, zaman sınırlarını ve veri işleme bütünlüğünü de kapsar. 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 ve Spring Boot ile Eşzamanlı İşlem Yönetimi

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ı ile sistem kapasitesi arasındaki ilişki, kaynak sınırları ve iş yükünün niteliği üzerinden belirlenir. 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 İşlem Bütünlüğü

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.

SQL sorguları sonuç doğruluğu, yürütme planı ve kaynak maliyetiyle birlikte değerlendirilir. 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 ve repository soyutlamaları altında oluşan sorgu ve işlem maliyetleri doğrudan ölçülmelidir. 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 Planlaması

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 Yüksek Başarımlı Veri İş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.

Optimizasyon kararlarını ilgili darboğazın ölçülmesi, kontrollü değişiklik ve karşılaştırmalı doğrulama aşamalarına dayandırı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.

Paralel İşleme ve Heterojen Hesaplama Mimarileri

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.

CPU ve GPU karşılaştırmalarında veri büyüklüğü, paralelleştirme potansiyeli, bellek bant genişliği ve aktarım maliyeti birlikte değerlendirilir. İş 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.

GPU Tabanlı Model Çıkarımı ve Kaynak Yönetimi

Heterojen hesaplama çalışmalarımı daha yakın dönemde NVIDIA L40S üzerinde konuşma tanıma çıkarımıyla sürdürdüm. CTranslate2/faster-whisper tabanlı iş akışlarında hesaplama hassasiyeti, GPU belleği, eşzamanlı çıkarım, CPU tarafındaki ön işleme, segmentasyon ve model çalışma zamanını tek bir kapasite probleminin ayrı bileşenleri olarak ele alıyorum.

GPU hesaplama kapasitesi, ön işleme, G/Ç ve işlem kuyruklarıyla birlikte uçtan uca kapasite modelinin bir bileşenini oluşturur. Ses çözme ve yeniden örnekleme, VAD, segmentasyon, kuyrukta bekleme, G/Ç, yeniden deneme ve sonuç birleştirme uçtan uca gecikmeye ayrı ayrı katkı yapar. Bu nedenle gerçek zamanlı konuşma tanımada kapasite mühendisliği yaklaşımında RTF'yi çıkarım aşamasının oranı olarak ölçüyor, sürdürülebilir servis kapasitesini ise kuyruk ve kaynak paylaşımıyla birlikte değerlendiriyorum.

Yapay Zeka Sistemlerinin Uçtan Uca Mühendisliği

Yapay zeka tabanlı yazılım sistemlerini; veri edinimi, ön işleme, model çıkarımı, sonuçların doğrulanması, kaynak tahsisi, iş zamanlama ve hata toleransı aşamalarından oluşan bütünleşik bir mühendislik problemi olarak değerlendiriyorum. Model kalitesi, bu aşamaların veri sözleşmeleri ve çalışma zamanı davranışıyla birlikte ele alınmaktadır.

Ön işleme doğruluğu, modelin uygulama düzeyindeki başarımını doğrudan etkiler. Kuyrukta bekleme süresi, CPU üzerinde yürütülen veri hazırlama işlemleri ve GPU kaynaklarının paylaşımı uçtan uca gecikme ve sürdürülebilir işlem kapasitesini belirleyen ayrı maliyet bileşenleridir.

Değerlendirmelerimde model çıkarım gecikmesi ile toplam işlem gecikmesini; modelin birim zamandaki işlem kapasitesi ile bütün sistemin sürdürülebilir kapasitesini ayrı ölçütler olarak kullanıyorum. Tokenizer, model sürümü, veri dönüştürme parametreleri ve çalışma zamanı bağımlılıkları, çıktıların karşılaştırılabilirliği açısından birlikte sürümlendirilir.

Güvenilir yapay zeka entegrasyonu; veri bütünlüğü, kaynak kullanım sınırları, yeniden üretilebilir deney tasarımı ve alan uzmanının değerlendirmesini destekleyen sonuç sunumuyla bütünlük kazanır.

Kaynak Temelli Analitik ve Deterministik İşlem Yönlendirme

Doğal dil arayüzü bulunan bir analitik sistemde her soruyu çalışma zamanında bir büyük dil modeline göndermek zorunlu değildir. Şeması ve yetki sınırı belirli sorularda kesin eşleme ve örüntü kurallarıyla başlayan, alan dilini ve kısa bağlamı kullanan, gerektiğinde sınırlandırılmış retrieval ve bulanık eşlemeye geçen deterministik bir yönlendirme hattı daha denetlenebilir olabilir. Bu tür bir hattı RAG ve kaynak bağlı yanıt tasarımı ile aynı problem ailesi içinde ele alıyorum.

Yönlendirme kararının yalnız niyeti değil, adayın gerçekten çalıştırılabilir olup olmadığını da sınaması gerekir. Gerekli bağlamın bulunması, kullanıcının erişim kapsamı, veri anlık görüntüsünün güncelliği ve üretilen sorgunun izinli biçimde kalması ayrı kontrollerdir. Güven düşükse sistemin tahmin yürütmek yerine açıklama istemesi veya yanıt vermekten kaçınması daha güvenlidir.

Metin kanıtında kaynak kimliği ve sınırlı özgün pasaj korunmalıdır; sonradan üretilen özet kanıtın yerini almamalıdır. Grafik analitiğinde de benzer bir sınır vardır: bağlı bileşen, köprü, eklem noktası, karşılıklılık veya yol gibi yapısal ölçüler gözlenen ilişki yapısını açıklar, fakat tek başına nedensellik ya da örgütsel anlam kanıtlamaz. Bu ayrım, analitik yardımcının akıcı cevap üretmesinden daha önemli bir doğruluk sınırıdır.

Otomatik Konuşma Tanıma Sistemleri

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ı, Kuyruk Kuramı ve Kapasite Analizi

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.

Adli Ses İşleme ve Konuşmacı Analizi

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.

Bilgisayarlı Görü ve Yüz Analizi

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.

Çoklu Ortam Verilerinin Ön İşlenmesi

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 Veri İşleme ve Veri Kökeni İzlenebilirliği

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.

Veri Kazıma ve Özel Dosya Biçimlerinin Analizi

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 ve Davranış Analizi

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 Adli Analizi ve PCAP İşleme

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.

NetworkMiner ve benzeri ağ adli bilişim yazılımlarının kaynak kodu, protokol ayrıştırıcıları ve veri işleme mimarileri üzerinde araştırma ve geliştirme çalışmaları yürütüyorum. PCAP tabanlı adli inceleme bileşenlerinin tasarımı ve geliştirilmesi kapsamında paketlerin protokol katmanlarına ayrıştırılması, TCP oturumları ile UDP akışlarının ilişkilendirilmesi, TCP veri akışlarının yeniden oluşturulması, uygulama katmanı mesajlarının çözümlenmesi ve ağ trafiğinden dosya ile üst veri artefaktlarının çıkarılması konularını ele alıyorum.

Yazılım geliştirme ve doğrulama süreçlerinde eksik veya sırası değişmiş paketler, yeniden iletimler, örtüşen TCP segmentleri, protokol farklılıkları ve hatalı biçimlendirilmiş girdiler değerlendirilir. Büyük yakalama dosyalarının artımlı işlenmesi, sınırlandırılmış bellek kullanımı, zaman damgalarının tutarlılığı ve özgün paketlerle türetilmiş oturum veya dosya artefaktları arasındaki kaynak ilişkisi; doğruluk, performans ve yeniden üretilebilirlik yönünden incelenir. Şifreli haberleşmede değerlendirme, yakalamadan gözlemlenebilen protokol ve üst veri özelliklerinin sınırları içerisinde tutulur.

Kriptografik Yöntemler 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.

Hata Toleransı ve Kontrollü Yeniden Deneme

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 Bütünlüğü 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.

Sistem Ölçümü ve Performans Değerlendirmesi

Kritik sistemlerde gözlemlenebilirlik, ölçütlerin açık tanımlanmasına ve sorumlu kaynakla ilişkilendirilmesine dayanır. 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 İşlem Yönetimi ve Tekrarlanabilirlik

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 Gereksinimlerinin Değerlendirilmesi

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 Teknik Uygunluk

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 Eğitim, Araştırma ve Bilimsel Yayınlar

2019 yılında başlayan kurumsal yazılım mühendisliği çalışmalarım devam ederken, adli bilişim ve siber güvenlik alanlarındaki lisansüstü eğitimlerimi de sürdürerek tamamladım. Gazi Üniversitesi Adli Bilişim ve Marmara Üniversitesi Siber Güvenlik yüksek lisans programları, sistem geliştirme deneyimimi dijital delil, veri bütünlüğü, bilişim hukuku, ağ güvenliği ve güvenli yazılım geliştirme konularında akademik olarak destekledi.

Aynı mesleki dönem içerisinde yürüttüğüm bilimsel yayın çalışmaları iki kitap bölümüyle sonuçlandı. Hüseyin Çakır ile birlikte hazırladığım Nesnelerin İnterneti ve Adli Bilişim bölümü 2021 yılında, Nursel Yalçın ile birlikte hazırladığım Görüntü ve Ses İşleme bölümü 2022 yılında yayımlandı. Bu çalışmalar, adli bilişim, yapay zeka, görüntü işleme ve ses işleme alanlarını kuramsal ve uygulamalı bakış açılarıyla ele almaktadır.

Bilgisayar mühendisliği, mekatronik mühendisliği ve işletme eğitimleriyle birlikte değerlendirildiğinde, lisansüstü çalışmalarım ve kitap bölümlerim mühendislik uygulamalarını çok disiplinli bir akademik temele bağlamaktadır. Kamuya açık teknik makalelerimde sistem güvenilirliği, algoritma tasarımı, kapasite modelleme ve doğrulanabilir veri işleme konularını kurumsal uygulamalardan bağımsız, genel mühendislik modelleri ve kaynaklarla açıklıyorum.

Kurumsal Gizlilik ve Bilgi Paylaşımının Kapsamı

Mesleki çalışmalara ilişkin kamuya açık bilgiler, paylaşılabilir mühendislik disiplinleri ve genel teknik yöntemlerle sınırlıdır. Kurum içi proje tanımları, uygulama kaynak kodları, iş akışları, operasyonel ölçümler, veri kümeleri, ağ ve sistem topolojileri, yetkilendirme düzenleri ve güvenlik yapılandırmaları kurumun bilgi güvenliği ilkeleri kapsamında korunmaktadır.

Teknik örnekler bağımsız, kuramsal veya kamuya açık kaynaklardan türetilen bağlamlarda sunulmaktadır. Ölçüm ve performans konuları açıklanırken gerçek kurumsal kapasite veya iş yükleri yerine matematiksel ilişkiler, yöntemler ve açıkça tanımlanan ölçüm kavramları kullanılmaktadır.

Mühendislik Yöntemi ve Tasarım İlkeleri

Yazılım mühendisliği çalışmalarımda problemin sınırlarını belirleme, ölçülebilir gereksinim oluşturma, darboğazları kaynak düzeyinde inceleme ve değişikliklerin etkisini tekrarlanabilir testlerle doğrulama yöntemlerini uyguluyorum. Mimari kararların değerlendirilmesinde algoritmik karmaşıklık, eşzamanlılık modeli, bellek ve G/Ç maliyeti, gecikme dağılımı ile hata sonrası toparlanma davranışı birlikte ele alınır.

Oracle veri erişiminden ses işleme ve GPU tabanlı model çıkarımına kadar farklı disiplinlerde, doğrulanmış işlevsel davranışın korunması ve kaynak kullanımının öngörülebilir hâle getirilmesi temel tasarım ilkelerimdir.