Kariyerimin en büyük ve en maliyetli hataları, bir kod satırında ya da yanlış bir network konfigürasyonunda gizli değildi. Aslında, en pahalı derslerimi, bir işe “evet” demenin ya da bir sorumluluğu üstlenmenin getirdiği dolaylı sonuçlardan aldım. Bir sistem mimarı olarak, keşke daha erken öğrenseydim diye düşündüğüm en önemli şeylerden biri buydu: her şeye yetişemezsin, ve yetişmeye çalışmak en büyük teknik borçtan bile daha fazla hasar verebilir.
Yıllardır sistemler ve ağlar arasında mekik dokurken, birçok karmaşık sorunla karşılaştım. PostgreSQL WAL bloat’larından tutun da, üretim ERP’sinde AI ile üretim planlama algoritmalarına kadar, teknik yığınların derinliklerine indim. Ancak, bu süreçte fark ettim ki, teknolojinin kendisi kadar, onu kullanan ve yöneten insanların iletişim şekli, beklentileri ve sınırları da bir o kadar kritik.
Her Şeye ‘Evet’ Demenin Bedeli
Yıllar içinde, birçok projede kendimi buldum. Özellikle bir üretim firmasının ERP’sini geliştirirken, her yeni talep geldiğinde, “evet, yaparız” demek adeta bir refleks haline gelmişti. Müşteri memnuniyeti, esneklik ve hızlı adaptasyon adına alınan bu kararlar, kısa vadede işe yarıyor gibi görünse de, uzun vadede projenin temel mimarisini ve ekibin enerjisini sinsi sinsi kemiriyordu.
Bu yaklaşım, SystemD unit’lerinin reliability sorunları gibi küçük aksaklıklardan, PostgreSQL’de partition stratejilerinin yetersiz kalmasına kadar birçok teknik probleme yol açtı. Her “evet”, aslında farkında olmadan yeni bir teknik borç, yeni bir bakım yükü ve en önemlisi, ekibin motivasyonunda bir düşüş demekti.
Teknik Borçtan Daha Ağır Bir Yük: İletişim Borcu
Çoğu zaman teknik sorunlarımızın kökeninde, aslında iletişim ve beklenti yönetimi eksikliği yatıyor. PostgreSQL’de N+1 sorgu sorunlarıyla boğuşurken, ORM’i suçlamak kolaydır. Ama çoğu zaman, bu sorunlar, iş biriminin ne istediğini tam olarak anlatamaması ya da bizim o isteği teknik olarak doğru anlayamamamızdan kaynaklanır.
Karmaşık BGP routing decisions ve VLAN tagging yapılandırmalarıyla uğraştığım kurumsal projelerde de gördüğüm şuydu: sistemin en büyük darboğazı çoğu zaman teknik değil, farklı departmanların ihtiyaçlarını ve önceliklerini doğru bir şekilde yansıtamayan, yetersiz bir iletişim zinciri oluyordu. Teknik mimari ne kadar sağlam olursa olsun, iletişimdeki aksaklıklar sistemi felç edebiliyordu.
Kendi Sınırlarımı Tanımak
Yıllar geçtikçe, kendi fiziksel ve mental sınırlarımı tanımam gerekti. Bir gece geç saatlerde, kendi yan ürünümün backend’inde Redis OOM eviction policy yüzünden sistem patladığında, aslında her şeyi tek başıma yapma ısrarımın bir bedeli olduğunu fark ettim. Bu durum, sadece teknik bir hatadan ibaret değildi; kendi sınırlarımı zorlamanın ve yardım istememenin bir sonucuydu.
Bu tür olaylar, bana sadece teknik çözümlerin değil, aynı zamanda kişisel zaman yönetimi, delege etme ve “hayır” diyebilme becerilerinin de bir sistem mimarının envanterinde olması gereken kritik yetkinlikler olduğunu öğretti. Bir sistemin sürdürülebilirliği, onu inşa eden ekibin sürdürülebilirliği ile doğru orantılıdır.
Pragmatizm ve Mükemmeliyetçilik Arasındaki Dans
Bir sistem mimarı olarak, her zaman en mükemmel çözümü ararız. Ancak saha deneyimim bana öğretti ki, bazen “yeterince iyi” olan çözüm, “mükemmel” olana ulaşmak için harcanacak zaman ve kaynak israfından çok daha değerlidir. Güvenlik için karmaşık bir SELinux profili oluşturmak yerine, çoğu senaryoda basit fail2ban kuralları ve doğru Nginx reverse proxy yapılandırması çok daha hızlı ve etkili bir koruma sağlar.
Örneğin, bir VPN topolojisi tasarlarken, sıfır-güven (Zero-Trust) mimarisinin tüm katmanlarını uygulamak ideal olsa da, mevcut altyapı ve bütçe kısıtlamaları altında, segmentasyon ve routing authentication gibi daha pragmatik adımlarla da önemli güvenlik iyileştirmeleri yapabildik. Mükemmeliyetçilik, bazen en büyük düşmanınız olabilir; pragmatizm ise sizi hedefe ulaştırır.
Yirmi yıllık bu yolculukta, teknik detayların ötesinde, insan ilişkileri, beklenti yönetimi ve kendi sınırlarımı bilmek gibi “soft skills” olarak adlandırılan alanların, bir sistem mimarının başarısında ne kadar kritik olduğunu öğrendim. Keşke kariyerimin başında bu dersleri almış olsaydım, belki de çok daha az “disk yangını” ya da “WAL rotation alarmı” ile karşılaşırdım.
Peki, senin kariyerinde keşke daha erken öğrenseydim dediğin en önemli ders neydi? Yorumlarda paylaşmaktan çekinme.