Bir sabah, üretim ERP’sinde faturalama modülünde hiç dokunmadığım bir bölümden “memory exhausted” hatası aldığımı gördüm. İlk aklıma gelen, “Acaba birisi benim koduma dokundu da mı patladı?” oldu. Ancak, detaylı incelediğimde sorunun kendi yazdığım kodda değil, sunucudaki bir Python bağımlılığının cgroup memory limit’ini tetiklemesinden kaynaklandığını fark ettim. Bu durum, yazılım geliştiricisi olarak sadece kod yazmanın ve kendi uzmanlık alanıma odaklanmanın bazen ne kadar yetersiz kalabileceğini bir kez daha yüzüme vurdu.
Bu tür senaryolarla defalarca karşılaştım: harika yazılmış, optimize edilmiş bir kod parçasının, altta yatan sistem veya ağ altyapısı nedeniyle beklendiği gibi çalışmaması. Yazılımda derinlemesine uzmanlaşmak elbette çok değerli; ancak, etrafındaki ekosistemi anlamadan, yazılan kodun gerçek dünyadaki davranışını ve performansını tam olarak tahmin etmek veya sorunları hızla çözmek imkansız hale geliyor. Bu yazıda, yazılım uzmanlığının neden tek başına yeterli olmadığını ve bir geliştiricinin neden daha geniş bir perspektife sahip olması gerektiğini kendi deneyimlerimle anlatacağım.
Sadece Kod Yazmak Neden Yeterli Değil?
Sadece kod yazmak, bir orkestranın enstrümanlarından birini çalmak gibidir; tek başına harika bir performans sergileyebilirsin, ancak senfoninin tamamı için diğer enstrümanları ve şefin vizyonunu anlaman gerekir. Bir uygulamanın performansı, güvenliği veya kararlılığı çoğu zaman kodun ötesindeki faktörlere bağlıdır.
Benim tecrübelerimde, birçok kez bir performans sorununun ya da beklenmedik bir hatanın kökeni, doğrudan uygulama kodu içinde değil, işletim sistemi konfigürasyonlarında, veritabanı ayarlarında veya ağ gecikmelerinde gizliydi. Örneğin, production ortamında yanıt süreleri belirgin şekilde artan bir API servisi üzerinde çalıştığımda, ilk başta kendi FastAPI kodumu ve SQL sorgularımı inceledim. Fakat sorunun kaynağının, sunucudaki bir başka sürecin işlemci kaynaklarını aşırı tüketmesi ve benim uygulamanın cgroup limit’lerine takılması olduğunu buldum. Kod mükemmel olsa bile, kaynak yönetimi yanlış yapıldığında uygulama “yavaş” olarak algılanır. Bu yüzden bir yazılımcının, kodunun hangi ortamda çalıştığını, hangi kaynakları tükettiğini ve bu kaynakların nasıl yönetildiğini bilmesi kritik önem taşıyor.
Sistem ve Network Bilgisinin Önemi
Yazdığımız her satır kod, bir işletim sistemi üzerinde çalışır ve genellikle bir ağ üzerinden başka servislerle iletişim kurar. Dolayısıyla, bu altyapıyı anlamadan, uygulamanın davranışını tam olarak kavramak veya sorunları etkili bir şekilde gidermek imkansızdır.
Bir keresinde, bir müşteri projesinde VPN üzerinden bağlanan kullanıcıların uygulamanın belirli bölümlerine erişiminde sürekli kesintiler yaşandığını raporladılar. Uygulama loglarında herhangi bir hata görünmüyordu, benim backend tarafım sağlıklı yanıt veriyordu. Problemin aslında network katmanında olduğunu, özellikle de VPN gateway’indeki MTU (Maximum Transmission Unit) ayarlarının, kullanıcıların internet servis sağlayıcılarının MSS (Maximum Segment Size) ayarlarıyla uyumsuz olmasından kaynaklandığını tespit ettim. Bu tür bir sorunu, sadece uygulama koduna bakarak bulmak imkansızdı; ağ paketlerini incelemek ve TCP el sıkışmasını anlamak gerekiyordu. Aynı şekilde, Linux servislerini systemd unit’leri ile yönetirken, Type=notify ile Type=simple arasındaki farkları bilmek, servis bağımlılıklarını doğru kurmak veya cgroup limit’lerini ayarlamak, uygulamanın kararlılığı ve güvenilirliği açısından hayati önem taşır. Ağ segmentasyonu, VLAN tagging ve firewall politikalarının uygulamanın erişilebilirliğini ve güvenliğini nasıl etkilediğini anlamak da bir yazılımcı için olmazsa olmazdır.
Veritabanı Optimizasyonu ve Mimarisi Gözden Kaçan Bir Alan mı?
Çoğu kurumsal uygulamanın kalbi bir veritabanıdır. Yazdığınız kod ne kadar optimize olursa olsun, eğer veritabanı yavaşsa veya yanlış yapılandırılmışsa, tüm uygulama performansı bundan olumsuz etkilenir. Maalesef, birçok yazılımcı ORM’lerin (Object-Relational Mappers) arkasına saklanarak veritabanı detaylarından uzak durmayı tercih eder, bu da gelecekte ciddi sorunlara yol açabilir.
Bir üretim ERP’si üzerinde çalışırken, özellikle raporlama ve büyük veri sorgularında performans sorunları yaşıyorduk. Problemin kaynağı, N+1 sorguları veya basit JOIN eksiklikleri değildi; daha çok PostgreSQL’in index stratejilerinin yetersiz kalması ve connection pool ayarlarının yanlış olmasıydı. B-tree, GIN ve BRIN index’lerinin hangi senaryolarda daha verimli çalıştığını bilmek, EXPLAIN ANALYZE çıktılarını doğru yorumlamak ve vacuum süreçlerini optimize etmek, uygulamanın genel yanıt süresini belirgin şekilde iyileştirdi. Ayrıca, PostgreSQL WAL bloat gibi durumlar, disk alanının hızla tükenmesine ve veritabanının yavaşlamasına neden olabilir; bu da doğrudan yazılımcının “kodum nerede çalışıyor?” sorusunun bir parçasıdır. Veritabanı replikasyon mekanizmalarını (logical vs. physical) ve read replica routing’i anlamak, uygulamanın ölçeklenebilirliği için kritik öneme sahiptir. Optimistik mi yoksa pesimistik kilitleme mi kullanılmalı, transaction outbox pattern’i ne zaman uygulanmalı gibi mimari kararlar, doğrudan veritabanı bilgisi gerektirir.
Güvenlik, Yalnızca Bir Eklenti mi?
Güvenlik, bir yazılım projesinde “sonradan eklenen” bir özellik değil, tasarımın en başından itibaren entegre edilmesi gereken temel bir katmandır. Sadece uygulama katmanındaki güvenlik açıklarına odaklanmak, genellikle büyük resmi kaçırmak anlamına gelir.
Benim deneyimimde, application-level security (örneğin JWT/OAuth2 kullanımı, API’larda rate limiting ve SQL injection mitigasyonu) ne kadar iyi olursa olsun, altta yatan sistem veya ağ katmanındaki zayıflıklar tüm sistemi riske atabilir. Örneğin, bir sunucunun kernel module blacklist kurallarının zayıf olması veya fail2ban gibi araçların yanlış yapılandırılması, SSH brute-force saldırılarına karşı kapıları açık bırakabilir. Bir keresinde, geliştirilmekte olan bir uygulamanın test ortamına yapılan sızma girişimini, uygulamanın kendisindeki bir açıktan değil, sunucudaki eski bir bağımlılığın CVE’sini hedef alan bir exploit üzerinden tespit ettim. Bu tür durumlar, auditd alt sistemini kullanma, SELinux veya AppArmor profilleri oluşturma ve dosya bütünlük izleme gibi sistem güvenliği pratiklerinin önemini gösterir. Ayrıca, ağ tarafında DHCP snooping, Dynamic ARP Inspection (DAI) ve IP source guard gibi switch hardening tekniklerinin, uygulamanın çalıştığı ortamı nasıl daha güvenli hale getirdiğini bilmek, bir yazılımcının güvenlik perspektifini derinleştirir. ZTNA (Zero Trust Network Access) mimarileri ve egress kontrolü gibi kavramlar, sadece ağ yöneticilerinin değil, yazılımcıların da anlaması gereken konulardır.
İş Akışlarını ve Kurumsal Süreçleri Anlamak
Yazılım geliştirme, çoğu zaman belirli bir iş problemini çözmek veya bir kurumsal süreci otomatikleştirmek için yapılır. Bu nedenle, sadece teknik detaylara odaklanmak ve iş akışlarını anlamamak, geliştirilen ürünün gerçek ihtiyacı karşılamamasına veya yanlış önceliklendirmelere yol açabilir.
Bir üretim ERP’sinde çalışırken, “satın al”, “üret”, “sevk” ve “fatura” gibi temel iş akışlarını derinlemesine anlamak zorundaydım. Operatör ekranlarını tasarlarken, sahadaki bir operatörün gerçekten neye ihtiyacı olduğunu, hangi bilginin anlık olarak kritik olduğunu ve hangi adımların en verimli şekilde sıralanması gerektiğini bilmeden, sadece teknik olarak “doğru” bir arayüz tasarlamak yetersiz kalırdı. Örneğin, gecikmiş sevkiyat raporlarının bazen yanlış bilgi vermesinin nedeni, veritabanı performansından çok, üretim hattındaki veri giriş süreçlerindeki bir tutarsızlıktan veya farklı departmanların kullandığı sistemler arasındaki entegrasyon eksikliğinden kaynaklanabiliyordu. Yazılım mimarisi kararları (monolith vs. microservice, event-sourcing vs. CQRS), çoğu zaman teknik gereksinimlerden ziyade organizasyonel akışların ve iş birimlerinin bağımsızlık düzeylerinin bir yansımasıdır. Bir yazılımcı olarak, iş birimleriyle yakın çalışmak, onların sorunlarını dinlemek ve yazılımın bu süreçleri nasıl daha iyi destekleyebileceğini anlamak, sadece kod yazmaktan çok daha fazlasını gerektirir.
Problem Çözme Yaklaşımı: Geniş Bakış Açısı ve Debugging
Bir problemle karşılaştığımda, ilk dürtüm genellikle kodumu kontrol etmek olur. Ancak, 20 yıllık tecrübem bana gösterdi ki, bu dar bakış açısı çoğu zaman sorun çözme sürecini uzatır ve gerçek kök nedeni gözden kaçırmamıza neden olur. Geniş bir bakış açısı, özellikle dağıtık sistemlerde debugging yaparken vazgeçilmezdir.
Bir keresinde, kendi yan ürünümün backend’inde beklenmedik bir CPU patlaması ve ardından OOM-killed hatası aldım. Uygulama logları sadece “process killed” diyordu ve daha fazla detay vermiyordu. İlk başta kendi yazdığım bir sleep(360) komutunun polling-wait yerine aktif beklemeye neden olduğunu düşünerek kodu düzeltmeye çalıştım. Ancak, journald loglarını ve cgroup raporlarını incelediğimde, aslında farklı bir sürecin, benim tahmin etmediğim bir zaman diliminde yoğun kaynak tüketimi yaparak benim container’ımı tetiklediğini gördüm. Bu durum, sadece kodu değil, tüm sistemi ve çevresini anlamanın ne kadar kritik olduğunu bir kez daha kanıtladı. Observability (metrikler, loglar, trace’ler) uygulamak, ancak bu verileri geniş bir bağlamda yorumlayabilmekle anlam kazanır. Bir yazılımcı olarak, sadece kendi kodumun çıktısını değil, aynı zamanda işletim sistemi metriklerini, ağ trafiğini, veritabanı performansını ve diğer bağımlılıkların durumunu da izleyebilmek ve yorumlayabilmek, sorunları çok daha hızlı teşhis etmemi sağlıyor. SLO (Service Level Objective) ve error budget yönetimi gibi operasyonel kavramlar da yine bu geniş bakış açısıyla anlam kazanıyor.
Sonuç: T-Şekilli Bir Uzmanlık Yolculuğu
Yazılımda uzmanlaşmak elbette çok değerli; ancak, tek başına yeterli değil. Bir yazılımcı olarak, sadece bir programlama dilini veya bir framework’ü derinlemesine bilmek yerine, T-şekilli bir uzmanlık geliştirmenin çok daha faydalı olduğunu kendi tecrübelerimle gördüm. Yani, bir alanda (örneğin backend geliştirme) derinlemesine bilgiye sahip olurken, aynı zamanda sistem yönetimi, network, veritabanı, güvenlik ve iş süreçleri gibi diğer alanlarda da geniş bir anlayışa sahip olmak.
Bu geniş bakış açısı, sadece sorunları daha hızlı çözmenizi sağlamakla kalmaz, aynı zamanda daha dirençli, ölçeklenebilir ve güvenli sistemler tasarlamanıza da olanak tanır. Bir üretim ERP’sinde karşılaştığım bir entegrasyon hatasını, bir VPS’te yaşadığım disk yangını sorununu veya bir Android spam uygulamamda Play Store yayınlama sürecindeki bir metadata reject’ini çözebilmemde, her zaman bu bütünsel yaklaşım bana yardımcı oldu. Kendi kendinize Linux komutlarını kurcalamak, bir veritabanının EXPLAIN ANALYZE çıktılarını incelemek veya basit bir ağ topolojisi kurmak gibi pratik deneyimler, bir yazılımcının ufkunu inanılmaz derecede genişletir. Unutmayın, yazdığınız kod bir vakumda çalışmıyor; o, büyük bir ekosistemin sadece bir parçası. Bu ekosistemi ne kadar iyi anlarsanız, yazdığınız kodun etkisi de o kadar büyük olur.