Tanımı o kadar basittir ki, ilk duyduğunuzda bir trajedi tiyatrosu izliyormuş gibi hissedersiniz:
Sistemde iki farklı işlem (thread veya process) vardır: İşlem A ve İşlem B.
İşlem A, işini tamamlamak için Kaynak 1'i elinde tutmakta ve Kaynak 2'nin serbest kalmasını beklemektedir.
İşlem B ise tam tersine, Kaynak 2'yi elinde tutmakta ve Kaynak 1'in serbest kalmasını beklemektedir.

İkisi de elindekini bırakmaz.
İkisi de diğerinin ilk adımı atmasını bekler.
Ve sonuç? Sistem donar. İşlemci (CPU) boşta bekler, bellek tükenir, fanlar deliler gibi dönmeye başlar ama sistem tek bir milimetre bile ilerleyemez. Ta ki dışarıdan bir el gelip fişi çekene veya süreçlerden birini acımasızca öldürene (kill -9) kadar.

1971 yılında bilgisayar bilimci Edward G. Coffman Jr., bir sistemin bu kör kuyuya düşebilmesi için dört şartın aynı anda gerçekleşmesi gerektiğini matematiksel olarak kanıtladı:

1. Mutual Exclusion (Karşılıklı Dışlama): Kaynak paylaşılamaz, sadece bir kişi sahip olabilir.
2. Hold and Wait (Tut ve Bekle): Elindeki kaynağı bırakmadan, diğer kaynağı istemeye devam etmek.
3. No Preemption (Zorla Geri Alınamazlık): Kimse senin elindeki kaynağı rızan olmadan zorla çekip alamaz.
4. Circular Wait (Döngüsel Bekleme): Birbirini bekleyen kapalı bir inat zinciri.

Peki, şimdi ekranınızı hafifçe kapatıp kafanızı kaldırın ve etrafınızdaki dünyaya, çalışma arkadaşlarınıza, ikili ilişkilerinize ve kendi zihninize bakın.

İnsan ilişkilerinin de aslında Coffman'ın bu dört kuralıyla kilitlenen devasa bir işletim sistemi olduğunu fark ettiniz mi?

Ofis Koridorlarındaki Kilitlenmeler

Yazılım ekiplerinde her gün onlarca mikro-deadlock yaşanır.

Frontend geliştirici kollarını kavuşturur ve der ki: "Backend ekibi API endpoint'ini bitirip canlıya almadan ben bu arayüzü kodlayamam."
Aynı anda Backend geliştirici kendi masasında homurdanır: "Frontend ekibi ekran tasarımındaki veri modelini kesinleştirmeden ben bu veritabanı şemasını oluşturamam."

İki taraf da elindeki "kaynağı" (kendi sorumluluğunu) sımsıkı tutar (Hold and Wait).
İki taraf da "Önce o adım atsın" diyerek döngüsel bir bekleme zinciri kurar (Circular Wait).
Ve iki hafta boyunca bir proje Jira tahtasında çürümeye terk edilir. Ne kod yazılır, ne ürün çıkar.

Aynı felaket, şirket yöneticileri arasında yaşanır. İki departman müdürü masaya oturur. Biri bütçeyi onaylamaz çünkü diğerinin taahhüt vermesini bekler; diğeri taahhüt vermez çünkü bütçenin açılmasını bekler. İki inatçı sürecin kilitlenmesi yüzünden yüzlerce insanın emeği aylarca çöpe gider.

Kalbin İşletim Sistemi ve Gurur Kilitlenmesi

Ama deadlock'ın en acı verici, en yıpratıcı hali profesyonel hayatta değil; kişisel ilişkilerimizde, sevgilimizle, eşimizle, dostumuzla veya ailemizle olan diyaloglarımızda yaşanır.

Büyük bir tartışmanın ardından o ağır, boğucu sessizlik çöker eve.
İçinizden bir ses fısıldar: "O özür dilemeden ben tek bir kelime bile etmeyeceğim."
Karşı tarafın zihninde de aynı ses yankılanır: "O arayıp adım atmadığı sürece ben asla aramayacağım."

İşte Coffman'ın dört kuralı yine devrededir:

• Mutual Exclusion: "Haklılık" paylaşılamayan tekil bir kaynak olarak görülür; ikimiz birden haklı olamayız, birimiz galip gelmelidir.
• Hold and Wait: Kendi kırgınlığımızı ve gururumuzu sımsıkı elimizde tutar, aynı anda karşı tarafın şefkat göstermesini bekleriz.
• No Preemption: Kimse bizim gururumuzu dışarıdan zorla alamaz; teslimiyeti sadece biz verebiliriz.
• Circular Wait: İki taraf da telefonun ekranına bakar, iki taraf da ilk mesajı karşıdan bekler.

Ve günler geçer. Bazen haftalar, bazen yıllar...
Oysa iki taraf da içten içe acı çekiyordur. İki taraf da o kilitlenmenin bitmesini istiyordur. Ama o görünmez "gurur thread'i", sistemin bütün duygusal işlemcisini tüketir, insanı uykusuz bırakır, tüketir ve tüketir.

Bazen kilit o kadar uzun sürer ki, sonunda ilişki "Kernel Panic" verir ve tamamen çöker.

Kilit Nasıl Kırılır?

İşletim sistemleri teorisi bize çok berrak bir çıkış kapısı gösterir:
Bir deadlock'ı çözmek istiyorsanız, Coffman'ın o dört şartından en az bir tanesini kırmak zorundasınızdır.

Döngüyü kırmanın en asil ve en olgun yolu Preemption'dır — yani bir tarafın elindeki kaynağı gönüllü olarak serbest bırakması.

Frontend geliştiricinin "Backend hazır değilse ben mock (sahte) bir veri servisi yazar, ekranımı kodlamaya başlarım" diyerek bekleme durumunu bozması gibi...
Veya daha zoru: İlişkide o zehirli gururu yere bırakıp, "Kimin haklı olduğu umurumda değil, bizim birbirimize duyduğumuz sevgi bu tartışmadan daha değerli" diyerek ilk aramayı yapabilmek gibi.

Bu bir yenilgi değildir. Bu bir teslimiyet veya zayıflık da değildir.

İşletim sistemlerinde kilidi bozan süreç, sistemi kurtaran kahramandır. İlk adımı atan insan, zayıf olan değil; o sistemin donup ölmesine izin vermeyecek kadar büyük bir duygusal kapasiteye ve olgunluğa sahip olan tek kişidir.

Bir dahaki sefere bir iş arkadaşınızla, bir dostunuzla veya sevdiğiniz biriyle kendinizi o soğuk, inatçı sessizliğin içinde bulduğunuzda aklınıza bu gelsin.

Elinizdeki kaynağı sımsıkı tutarak karşı tarafın teslim olmasını beklemek, bir bilgisayar algoritmasının yapabileceği en ilkel hatadır.
Ve siz bir makine değilsiniz.

O kilidi kırın. İlk sinyali siz gönderin. Bırakın sistem yeniden nefes alsın.

Bu şemalar kâğıt üzerinde kusursuz birer matematiksel algoritmadır:
"Ritim analiz et. Ritim şoklanabilir mi (VF/VT)? Evetse 200 Joule şok ver, 2 dakika CPR yap, damar yolu aç, 1 mg Adrenalin uygula. Ritim şoklanamaz mı (Asistol/PEA)? Şok verme, CPR'a devam et, geri döndürülebilir nedenleri (4H - 4T) ara..."

Sınavlarda bu şemaları ezbere çizen öğrenciler en yüksek notları alır. Kendinizi dünyanın en donanımlı, her duruma hazır acil tıp uzmanı gibi hissedersiniz.

Sonra mezun olursunuz. Ve bir gece saat 03:00'te ambulansın kapısı açılır.

Olay yeri: Şarampole yuvarlanmış, tavanı ezilmiş bir araç. Hava buz gibi, zifiri karanlık ve yağmur yağıyor. Kazazede arabanın içinde baş aşağı sıkışmış durumda. Solunum yolu kan ve kusmukla tıkanmış. Monitörün kablosu çamura bulanmış, pille çalışan aspiratörün şarjı zayıflamış ve hastanın boynunu kılavuzda yazdığı gibi "nötr pozisyonda" sabitlemeniz fiziksel olarak imkânsız.

Kitabı açıp "Sayfa 142'deki şemaya göre hastanın sırtüstü düz bir zeminde yatması gerekiyordu, bu araba neden ters döndü?" diyemezsiniz. O an o kılavuz çöpe gider. O an sizi ve hastayı kurtaracak tek bir şey vardır: Protokolün ardındaki temel biyolojik prensibi kavramış olmak ve o kaosun içinde soğukkanlılıkla doğaçlama yapabilmek.

Gerekiyorsa baş aşağı pozisyonda, dizlerinizin üzerine çökerek, çamurun içinde parmaklarınızla hava yolunu açarsınız. Çünkü prensip basittir: Beyne oksijen gitmek zorundadır. Yolun kitabî olup olmaması hastanın umurunda değildir; hastanın tek derdi yaşamaktır.

Yazılım Dünyasının Kutsal Kitapları ve Ezbercilik

Şimdi bu sahneyi zihninizde dondurun ve yazılım dünyasının steril koridorlarına adım atın.

Yazılım sektörü, belki de yeryüzünde dogmalara ve ezberlere en çabuk teslim olan sektördür. Her dönemin bir "kutsal kitabı" ve amentüsü vardır:
"Clean Architecture", "Gang of Four Design Patterns", "Domain-Driven Design (DDD)", "Microservices", "TDD olmadan asla kod yazılmaz"...

Geliştiriciler konferanslarda bu kalıpları birer dini inanç gibi savunur. Yeni başlayan bir mühendise sorsanız, size ezberden "Dependency Injection", "Singleton Pattern" ya da "CQRS" mimarisini kusursuzca anlatabilir. Tıpkı sınavda akış şemasını eksiksiz çizen tıp öğrencisi gibi.

Ama o mühendis, gerçek hayatta kanayan bir sistemle karşılaştığında ne yapar?

Canlı ortamda veritabanı kilitlenmiştir (deadlock). Mikroservisler birbirini zaman aşımına uğratıyordur. Dokümantasyonu olmayan, 10 yıl önce şirketten ayrılmış birinin yazdığı legacy bir PHP/C++ servisi bellek sızdırıyordur. Ve şirket dakikada on binlerce lira kaybediyordur.

O an o "kusursuz" mimari kitapları susar. StackOverflow'u açarsınız; orada da sizin yaşadığınız o tuhaf kenar duruma (edge case) dair tek bir hazır cevap yoktur. Çünkü StackOverflow ve ChatGPT sadece genel durumları bilir; sizin sisteminizin o an yaşadığı spesifik doku nekrozunu bilemez.

Ve ezberci yazılımcı o an terminalin başında felç geçirir. Çünkü o sadece yemek tariflerini ezberlemiştir; mutfakta yangın çıktığında ne yapacağını bilmez.

Kurallar Acemiler İçindir, Prensipler İse Ustalar İçin

Dövüş sanatlarında ve Doğu felsefesinde "Shu-Ha-Ri" adı verilen üç aşamalı bir öğrenme modeli vardır:

1. Shu (İtaat Et): Kuralları, formları ve protokolleri harfiyen öğren ve uygula.
2. Ha (Kır / Ayrıl): Kuralların sınırlarını anla, nerede yetersiz kaldıklarını gör ve gerektiğinde kuralları esnet.
3. Ri (Aş / Yarat): Kuralları tamamen unut. Artık kuralların değil, bizzat sanatın kendisi ol ve anın gerektirdiği şekilde özgürce yarat.

Yazılımda ve acil tıpta acemiler her zaman Shu aşamasında takılı kalır. Kurallara taparlar; çünkü kural onlara sahte bir güvenlik hissi verir. "Ben kılavuza uygun davrandım, hasta öldüyse benim suçum değil" veya "Ben kodu Clean Architecture prensiplerine göre yazdım, sistem ölçeklenmediyse mimarinin suçu değil" diyerek sorumluluktan kaçarlar.

Oysa gerçek bir usta, kuralların sadece birer "çocukluk tekerleği" olduğunu bilir.

Bazen bir sistemi ayakta tutmak için en katı mimari prensibi delmeniz gerekir. Bazen bir fonksiyonu bölmek yerine tek bir dosyada 500 satır monolitik bırakmak, o anki bellek ve CPU darboğazını çözmenin en zarif yoludur. Bazen kriz anında test yazmayı bir kenara bırakıp, doğrudan problemi cerrahi bir müdahaleyle kesip çıkarmanız gerekir.

Bu kuralları çiğnemek değildir; kuralların hizmet ettiği amacı (pragmatizmi) kuralların şeklinden üstün tutmaktır.

Mutfakta Aşçı Olmak

Yemek yapmayı öğrenen biri tarife sıkı sıkıya bağlı kalır: "İki çay kaşığı tuz, 100 gram tereyağı." Eğer evde tereyağı yoksa yemek yapamaz, panikler.
Ama büyük bir şef, elindeki malzemeye bakar. Havanın nemine, etin yağ oranına, fırının sıcaklığına göre tarifi o an yeniden yazar. Çünkü o, malzemelerin kimyasını ve ısının mantığını kavramıştır.

Acil tıpta hastayı kurtaran şey, ters dönmüş bir arabada doğaçlama yapabilme cesaretidir.
Yazılımda sistemi kurtaran şey, StackOverflow cevapları tükendiğinde terminal başında derin bir nefes alıp, sistemin temel prensipleriyle (CPU, bellek, network paketleri, disk I/O) düşünebilme yetisidir.

Kılavuzları okuyun, protokolleri öğrenin, kitapları hatmedin. Onlar sizin temellerinizdir.
Ama sahaya çıktığınızda o kitapları bir kenara bırakmaya hazır olun.

Çünkü hayat ve kod; hiçbir zaman o kitapların kurguladığı kadar steril ve uslu olmayacaktır.

Bu toplantı bir mahkeme salonu değildir. Orada bir savcı oturup "Hastanın ölümünden hangi hemşire veya doktor sorumlu, hemen diplomasını iptal edelim" demez. Eğer tıp dünyası yüzyıllardır bu mantıkla çalışsaydı, bugün dünyada tek bir cerrah veya hekim bile kalmazdı.

M&M masasına bir vaka yatırıldığında, cerrahından stajyerine, eczacısından başhemşiresine kadar herkes aynı soğukkanlılıkla tek bir sorunun peşine düşer: Sistem nerede açık verdi?

Hemşire ilacı yanlış dozda mı hazırladı? Peki neden?
İlaç dolabındaki iki farklı ilacın kutu tasarımı ve yazı tipi birbirine mi benziyordu?
O gece acil serviste personel eksikliği mi vardı ve o hemşire 28 saattir aralıksız mı nöbetteydi?
Acil çağrı zili çaldığında alarm sesleri birbirine mi karışıyordu?
Doktorun yazdığı el yazısı reçete protokol kurallarına uygun değil miydi?

İşte bu, bir hatayı kişiselleştirmek yerine sistemi otopsiye almaktır. James Reason'ın meşhur "İsviçre Peyniri Modeli" tam olarak bunu anlatır: Felaketler tek bir insanın aptallığından değil; sistemdeki küçük deliklerin (güvenlik açıklarının, yorgunluğun, kötü tasarımın) tesadüfen aynı hizaya gelmesinden doğar.

Peki yazılım dünyası bu olgunluğun neresinde?

Yazılımın Sahte "Blameless" Tiyatrosu

Son yıllarda DevOps kültürünün yaygınlaşmasıyla birlikte teknoloji şirketlerinin diline pelesenk olmuş bir kavram var: "Blameless Post-Mortem" (Suçlamasız Olay Sonrası İnceleme).

Teoride kulağa ne kadar modern ve çağdaş geliyor değil mi? Bir kriz çıkar, sistem çöker, ardından ekip toplanır ve "Kimseyi suçlamıyoruz, sadece süreçleri iyileştireceğiz" denir. Google'ın SRE (Site Reliability Engineering) kitaplarından alıntılar yapılır.

Ama gelin o toplantı odasının kapısını aralayıp gerçekte ne olduğuna bakalım.

Şirketin ana veritabanı silinmiştir veya son güncelleme bütün ödeme akışını kilitlemiştir. Masada oturan yöneticilerin gözlerinde tek bir soru parıldar: "Bunu kim yaptı?"
Toplantı raporuna resmi olarak "Bir operasyonel aksaklık yaşandı" yazılır; ama toplantı biter bitmez kahve köşelerinde, özel Slack mesajlarında fısıltılar başlar:
"Ahmet yine migration script'ini canlıda çalıştırmış..."
"Mehmet PR'ı test etmeden merge'lemiş..."

Sonuç? Ahmet günah keçisi ilan edilir, belki performansı düşürülür veya şirketten kovulur. Ekip rahat bir nefes alır: "Suçlu bulundu ve bertaraf edildi."

Ve altı ay sonra, yeni işe giren Ayşe aynı hatayı birebir tekrarlar.

Neden mi? Çünkü siz Ahmet'i kovdunuz; ama Ahmet'in tek bir tuşa basarak tüm şirketi yok edebildiği o çürük zemini olduğu gibi bıraktınız.

Ahmet Suçlu Değil, Senin Sistemin Özürlü

Yazılım liderlerinin ve sistem mimarlarının anlamakta en çok zorlandığı gerçek şudur:
Eğer bir mühendis, tek bir terminal komutuyla, tek bir kontrolsüz tıklamayla veya tek bir dalgınlıkla tüm sistemi çökertebiliyorsa; suç o mühendiste değil, o yetkiyi oraya kontrolsüzce bırakan sistemdedir.

Bir insan yorulabilir. Bir insanın sevgilisiyle kavga ettiği bir gün olabilir, bebeği bütün gece uyumamış olabilir, dikkati saniyenin onda biri kadar dağılabilir. İnsanoğlu biyolojik olarak hata yapmaya programlanmış kusurlu bir varlıktır.

Mühendisliğin tek varoluş sebebi ise, bu kusurlu insanın etrafına çelikten bariyerler (Poka-Yoke) örmektir.

Eğer sizin canlı (production) veritabanınıza bir geliştirici doğrudan SSH ile bağlanıp DROP TABLE yazabiliyorsa; orada suç Ahmet'in klavyesinde değil, o veritabanına doğrudan yazma izni veren DevOps mimarisindedir.
Eğer bir kod, otomatik testlerden, statik analizden ve kademeli dağıtım (canary deployment) aşamasından geçmeden canlıdaki kullanıcılara ulaşıyorsa; suç o PR'ı açan stajyerde değil, o dağıtım boru hattını (pipeline) kurmayan kıdemli mühendistedir.

Tıpta buna "Hataya Dayanıklı Tasarım" denir. Örneğin, hastanelerdeki oksijen tüplerinin ve azot protoksit gazı hortumlarının bağlantı uçları fiziksel olarak birbirinden tamamen farklı üretilir. Dünyanın en dikkatsiz, en yorgun hemşiresi bile istese de oksijen prizine anestezi gazı hortumunu takamaz; çünkü metal yuvalar birbirine uymaz.

Peki sizin yazılım mimarinizde, yanlış hortumu yanlış yere takmayı engelleyen kaç tane fiziksel kilit var?

Gerçek Bir Otopsi Nasıl Yapılır?

Bir olay sonrası analiz (post-mortem), suçlu avlamak için değil, mimarinin zayıf halkalarını güçlendirmek için bir fırsattır. Eğer bir krizin ardından toplantı yapıyorsanız, şu üç soruyu masaya koymak zorundasınız:

1. Görünürlük (Observability): Bu hatayı biz kendimiz mi fark ettik, yoksa Twitter'da müşteriler dalga geçmeye başladığında mı uyandık? Sistem neden kendi kendine kanadığını bize önceden haber vermedi?
2. Kapsama Alanı (Blast Radius): Tek bir servisteki hata neden domino taşı gibi tüm platformu devirdi? Servisler arasındaki yalıtım (circuit breaker / isolation) neden çalışmadı?
3. Geri Dönüş Hızı (Recovery Time): Hatayı fark ettikten sonra sistemi 5 dakika içinde bir önceki stabil duruma getirebilecek bir geri alma (rollback) mekanizmamız neden yoktu?

Bu soruların hiçbirinde bir insan ismi geçmez. Bu soruların tamamı mimarinin, süreçlerin ve araçların sağlığıyla ilgilidir.

Hatayı insanda aramak tembelliktir. Birini suçlayıp rahatlamak, sorunu çözmüş gibi hissettiren en ucuz uyuşturucudur.

Ama eğer gerçekten ayakta kalan, kurşun geçirmez sistemler inşa etmek istiyorsanız; insanları cezalandırmayı bırakın. Masaya neşteri koyun ve sistemi otopsiye alın. Çünkü sistem iyileşmediği sürece, sedyeye yatacak bir sonraki kurban sadece bir zaman meselesidir.

"See one, do one, teach one."
(Bir kez izle, bir kez yap, bir kez öğret.)

Bu prensip, tıbbın yüzyıllardır nesilden nesile aktarılan o kutsal usta-çırak omurgasıdır. Tıp fakültesini birincilikle bitirmiş olsanız bile, bir hastanenin acil servisine ya da ameliyathanesine adım attığınız ilk gün kimse elinize neşteri verip "Hadi bakalım, dün gece okuduğun kitaptaki apandisit ameliyatını yap" demez.

Önce kıdemlinin yanına geçersiniz. Nefesini ensenizde hissederken onun dokuyu nasıl tuttuğunu, kanamayı nasıl klempe ettiğini, hastayla nasıl konuştuğunu izlersiniz (See one).
Sonraki vakada yer değiştirirsiniz. Neşter sizin elinizdedir ama kıdemli cerrah yarım santim yanınızda durur; eliniz titrediğinde bileğinizi tutar, hata yapmanıza ramak kala sizi uyarır ve o ameliyatı güvenle tamamlatır (Do one).
Ve nihayet, birkaç ay sonra arkanıza yeni bir çömez geldiğinde, bu kez siz onun yanına geçer ve bildiğiniz her şeyi ona aktarırsınız (Teach one).

Çünkü tıp camiası çok iyi bilir ki: Kitaplar size anatomiyi öğretir; ama insan hayatını kurtarmayı sadece ve sadece yanınızdaki usta öğretir.

Peki, dünyanın en hızlı büyüyen ve en çok övünen sektörü olan yazılım dünyasında durum nedir?

"4 Yıl Deneyimli Junior Aranıyor" Komedisi

Bugün teknoloji sektörünün istihdam ve kültür yapısına baktığınızda, kelimenin tam anlamıyla bir akıl tutulması görürsünüz.

LinkedIn'deki iş ilanlarını açın. Başlık: "Junior Frontend Developer".
İlan detayları: "En az 3-4 yıl production tecrübesi, Next.js, Kubernetes, CI/CD süreçlerine hakim, yüksek trafikli sistemler yönetmiş..."

Bu ilanlar trajikomik bir çaresizliğin itirafıdır. Şirketler artık eğitmek, yetiştirmek, sabır göstermek ve zaman ayırmak istemiyor. Herkes daldan hazır, olgunlaşmış, sulu bir elma koparmak istiyor; ama o elma ağacını kimse sulamak istemiyor.

Yeni mezun bir yazılımcıyı düşünün. Üniversiteden ya da kendi çabalarıyla bir noktaya gelmiş, hevesli, gözleri parlayan bir genç. İşe giriyor. İlk gün eline bir MacBook tutuşturuluyor, Slack kanalına ekleniyor, 50 bin satırlık dokümantasyonsuz bir legacy kod tabanının linki veriliyor ve "Jira'da birkaç bilet var, hadi çözmeye başla" deniyor.

Yanında ne bir kıdemli var, ne elini tutan bir rehber. Çocuk bir yerde tıkandığında soru sormaya çekiniyor; çünkü sektördeki o sahte kibir ortamında soru sormak "yetersizlik" olarak yaftalanıyor. Kod incelemeleri (Pull Request) ise bir öğretme alanı olmaktan çıkmış; kıdemli mühendislerin ego tatmin ettiği, "Bunu neden böyle yazdın, git Clean Code oku" diyerek satır aralarında insan azarladığı birer linç meydanına dönüşmüş.

Sonra ne oluyor? O genç birkaç ay içinde tükeniyor, içine kapanıyor, ezber kalıplara sığınıyor ve kendi kaderine terk ediliyor.

Bilgi Transferinin İflası

Bu sektörün içine düştüğü en büyük yanılgı, kod yazmanın sadece bir "mühendislik" işi olduğunu sanmaktır. Hayır; iyi kod yazmak aynı zamanda bir zanaattır.

Bir sistemin kriz anında nasıl davrandığını, bir veritabanı indeksinin neden patladığını, bir mimari kararın 3 yıl sonra şirketin başına ne belalar açacağını hiçbir üniversite müfredatında, hiçbir YouTube eğitim videosunda ya da bootcamp'te bulamazsınız. Bu bilgi, ancak sahada yüzlerce kez hata yapmış, gece yarısı sunucu başında sabahlamış bir ustanın masasında oturup, onun klavye başındaki kararlarını izleyerek öğrenilir. Bu, zımni bilgidir (tacit knowledge).

Ve biz şu an bu zımni bilgi akışını tamamen kesmiş durumdayız.

Kıdemli mühendisler (Senior/Lead), günlerini anlamsız toplantılarda, bitmek bilmeyen Agile törenlerinde ve Jira biletleri arasında tüketirken; yanlarındaki junior mühendise yarım saatlik bir "pair programming" yapmayı zaman kaybı olarak görüyor. Şirketler ise "Junior yetiştirirsem 1 yıl sonra başka şirkete kaçar" korkusuyla tamamen bencilleşiyor.

Henry Ford'un ünlü bir sözü vardır: "Ya çalışanlarımızı eğitirsek ve giderlerse?" diye soran ortağına şu cevabı verir: "Ya eğitmezsek ve kalırlarsa?"

Eğitilmemiş, usta eli değmemiş, sadece StackOverflow ve yapay zeka çıktılarından kopyala-yapıştır yaparak "Senior" unvanı almış milyonlarca mühendisle doldu ortalık. Ve bugün sistemlerin neden bu kadar sık çöktüğünü, neden her projenin teknik borç batağında boğulduğunu merak ediyoruz.

Gerçek Senior'lığın Tanımı

Eğer bir şirkette "Senior Software Engineer" unvanına sahipseniz ama arkanızda sizin sayenizde büyümüş, sizin tecrübenizle güçlenmiş, sizin bilginizi devralmış tek bir junior mühendis bile yoksa; kusura bakmayın ama siz henüz kıdemli değilsiniz. Siz sadece kod yazmayı iyi bilen, pahalı ve tek kullanımlık bir iş gücüsünüz.

Tıpta bir cerrahın büyüklüğü, tek başına yaptığı ameliyatların sayısıyla değil; arkasında bıraktığı cerrahi ekolüyle ve yetiştirdiği uzmanlarla ölçülür.

Usta-çırak bağı bir lütuf değildir; bu sektöre olan borcumuzdur. Bir zamanlar birileri bizim yazdığımız berbat kodlara sabretti, birileri bize git rebase'in mantığını sabırla anlattı, birileri kriz anında panikle elimiz ayağımıza dolandığında omzumuza dokunup "Sakin ol, çözeriz" dedi.

Eğer bugün o koltukta oturuyorsak, o borcu ödemek zorundayız:
Bir kez gördük.
Yıllarca yaptık.
Şimdi arkamıza dönüp, sabırla öğretme vaktidir.

Eğer acil servisteki hekim bir "garson" gibi davransaydı ne yapardı?
Menüyü açar, hastanın istediği antibiyotiği ve iğneyi yazar, "Afiyet olsun, kasada ödemeyi yapabilirsiniz" derdi. Hasta da mutlu mesut evine dönerdi.

Ama iyi bir hekim bunu asla yapmaz. Çünkü hekim bilir ki, o hasta belki de viral bir üst solunum yolu enfeksiyonu geçiriyordur; antibiyotik hiçbir işe yaramayacağı gibi bağırsak florasını çökertecek ve dirençli bakteriler yaratacaktır. Ya da o boğaz ağrısının arkasında henüz başlangıç aşamasında olan bambaşka bir enfeksiyon veya alerjik reaksiyon yatıyordur.

Hekim hastaya sakin bir sesle sorar: "Neyiniz olduğunu bırakın ben anlayayım. Bana sadece ne hissettiğinizi anlatın. Şikayetiniz ne zaman başladı?"

İşte tıp dünyasında buna Anamnez (Hasta Hikayesi Alma) denir. Hasta kendi teşhisini koyamaz; hasta sadece semptomları yaşar. Teşhisi koymak ve doğru tedaviyi belirlemek uzmanın namusudur.

Peki, yazılım ve teknoloji danışmanlığı dünyasına geldiğimizde ne oluyor?

"Garson Yazılımcılık" Salgını

Teknoloji şirketlerinin, yazılım ajanslarının ve freelancer'ların ezici bir çoğunluğu ne yazık ki kendilerini birer "mühendis" veya "uzman" gibi değil; sipariş alan birer garson gibi konumlandırıyor.

Müşteri kapıdan içeri girer:
"Biz şirketimiz için bir mobil uygulama istiyoruz. İçinde mutlaka yapay zekalı bir chatbot olacak. Altyapıyı da mikroservis mimarisinde, Kubernetes üzerinde kuralım."

Ajans sahibinin veya satış temsilcisinin gözleri parlar. Çünkü müşterinin istediği her bir havalı kelime, faturaya eklenecek sıfırlar demektir. Hemen bir teklif hazırlanır: "Tabii ki efendim! React Native mobil app, OpenAI API entegrasyonu, 12 mikroservis, AWS Kubernetes cluster... Teslim süresi 6 ay, maliyeti şu kadar."

Sipariş alınır, mutfağa (yazılımcılara) iletilir. Aylar süren kanlı bir geliştirme sürecinin, yüz binlerce liralık harcamanın ardından ürün teslim edilir.

Ve sonuç ne olur?

Mobil uygulamayı indiren kullanıcı sayısı 40'ı geçmez. Müşterinin operasyonel sorunları zerre kadar çözülmemiştir. Şirket içi süreçler hâlâ dökülüyordur. Yapay zeka chatbot'u kimse kullanmıyordur ve şirket her ay binlerce dolarlık anlamsız bir AWS sunucu faturasıyla baş başa kalmıştır. Müşteri parasını kaybetmiştir, yazılımcısına küsmüştür; ajans ise arkasından "Biz müşterinin istediği her şeyi harfiyen yaptık, satamadılarsa bizim suçumuz ne?" diyerek omuz silker.

Bu, boğazı ağrıyan hastaya antibiyotik yazıp evine gönderen ve iki gün sonra böbrek yetmezliğiyle yoğun bakıma düşmesine seyirci kalan sahte bir hekimin tavrından farksızdır.

Semptom ile Çözümü Birbirinden Ayırmak

Yıllar içinde bir teknoloji şirketi yönetirken ve onlarca müşteriyle masaya otururken öğrendiğim en kıymetli ders şudur:
Müşteri size asla gerçek ihtiyacıyla gelmez. Müşteri size, kendi kafasında kurduğu "çözüm varsayımıyla" gelir.

Müşteri "Bize mobil uygulama lazım" dediğinde, aslında mobil uygulamaya ihtiyacı yoktur. Onun asıl semptomu şudur: "Saha satış ekibim siparişleri kâğıda yazıyor, akşam ofise gelene kadar merkezde kimse ne satıldığını bilmiyor, stoklar karışıyor ve müşterilere geç teslimat yapıyoruz."

İşte semptom budur. Hastalık: Veri akışındaki gecikme ve stok yönetimindeki kaos.

Eğer siz müşteriyi dinleyip semptomu doğru anlarsanız, ona 6 ay sürecek 50 bin dolarlık bir mobil uygulama satmazsınız. Belki de onların ihtiyacı olan şey; mevcut ERP sistemlerine bağlanacak 3 sayfalık basit, duyarlı (responsive) bir web arayüzü veya sadece WhatsApp bildirimlerini otomatik işleyen 200 satırlık basit bir entegrasyondur. İki haftada teslim edilir, müşterinin cirosunu kurtarır ve şirket nefes alır.

Ama bunu yapabilmek için masada garson değil, hekim gibi oturmanız gerekir.

"Hayır" Diyebilme Namusu

Bir hekimin en büyük erdemi, gereksiz bir ameliyatı veya zararlı bir ilacı reddetmektir. Hipokrat Yemini'nin temeli "Primum non nocere" — yani "Önce zarar verme" ilkesine dayanır.

Yazılım sektörünün de acilen kendi Hipokrat Yemini'ne ihtiyacı var.

Müşteri masaya oturup "Biz bu projede blokzincir (blockchain) ve yapay zeka kullanmak istiyoruz" dediğinde; ona sırf kasasına fatura kesebilmek için "Harika fikir!" demek ahlaki bir çürümedir. Gerçek bir mühendis, müşterisinin gözlerinin içine bakar ve şunu söyler:

"Bu teknolojiye ihtiyacınız yok. Bu teknoloji sizin probleminizi çözmez; aksine bütçenizi tüketir, sisteminizi gereksiz yere karmaşıklaştırır ve ekibinizi yorar. Sizin asıl derdiniz şu, gelin bunu en sade, en sağlam ve en az maliyetli yolla çözelim."

Bunu söylediğiniz an iki şeyden biri olur:
Eğer karşınızdaki vizyonsuz, sadece gösteriş peşinde koşan biriyse masadan kalkar ve parasını dolandırıcılara kaptırır.
Ama eğer aklı başında bir iş insanıysa, gözleri açılır. O an anlar ki karşınızda ona bir şeyler satmaya çalışan bir pazarlamacı değil; kendi parasını ve şirketini kendisinden daha çok koruyan gerçek bir uzman oturmaktadır.

O andan itibaren satış ilişkisi biter; güven ilişkisi başlar. Ve o müşteri, sonraki on yıl boyunca başka hiçbir yazılımcının kapısını çalmaz.

Reçeteyi Uzman Yazar

Acil servise gelen hastaya saygı duyarız, acısını anlarız, onu şefkatle dinleriz. Ama stetoskop hekimin boynundadır, neşter cerrahın elindedir.

Yazılımda da müşterinizin sektörünü, işini ve vizyonunu en iyi kendisi bilebilir; buna sonuna kadar saygı duymalısınız. Ancak teknolojinin nasıl kurgulanacağı, hangi mimarinin seçileceği ve hangi problemin nasıl çözüleceği sizin sorumluluk alanınızdır.

Müşterinin istediği ilacı değil, ihtiyacı olan tedaviyi verin.
Sipariş alan bir garson olmayı bırakın; teşhis koyan bir mühendis olun.

Çünkü hastayı memnun eden şey anlık tatlı sözler değil; ayağa kalkıp sağlıklı bir şekilde yürümeye başlamasıdır.

Ambulansın arkasında, kalbi durmuş (kardiyak arrest) bir hastaya CPR yaparken defibrilatör ritim analiz eder, göğüs kompresyonu devam eder ve ekip lideri bağırır: "1 miligram Adrenalin hazırla!"

O an eliniz ilaca uzandığında zihninizde saniyenin onda biri kadar bir sürede devasa bir doğrulama algoritması çalışır. Çünkü rafta duran ampullere baktığınızda, Atropin de Adrenalin de Aritmal de şeffaf bir cam tüpün içindeki renksiz birer sıvıdan ibarettir. Eğer yorgunluktan gözünüz kararır da 1 mg yerine 10 mg çekerseniz veya mikrogram (mcg) ile miligramı (mg) birbirine karıştırırsanız, hastayı hayata döndürmez; onu kendi ellerinizle öldürürsünüz.

Sağlıkçıların kanına işlemiş olan "5 Doğru İlkesi" tam olarak bu yüzden vardır:

1. Doğru hasta,
2. Doğru ilaç,
3. Doğru doz,
4. Doğru yol (IV/IM/IO),
5. Doğru zaman.

Bu beş kuraldan tek bir tanesini bile "esnetemezsiniz". Kimse "Canım ne olacak, 1 ml sıvı işte, damardan gitse ne olur kabadan gitse ne olur" demez. Tıpta tipler (types), miktarlar (values) ve sınırlar (boundaries) tartışmaya kapalıdır.

Peki yazılım dünyasına döndüğümüzde ne yapıyoruz?

JavaScript'in Tehlikeli Esnekliği

Yazılım dünyasının en popüler dili olan JavaScript'in doğuş felsefesini hatırlayalım: Tarayıcıda birkaç butonu hareket ettirmek, form alanlarını kontrol etmek ve kullanıcıya sevimli animasyonlar göstermek. Hata vermesin, çökmesin, ne olursa olsun bir şekilde çalışmaya devam etsin diye tasarlandı.

Ve bu "hoşgörü", modern yazılım dünyasının en ölümcül virüsüne dönüştü.

JavaScript'te bir sayı ile bir metni toplayabilirsiniz: "5" + 3 yazarsınız ve dil size kızmak yerine gülümseyerek "53" cevabını verir. Bir fonksiyon iki parametre beklerken siz sıfır parametre geçersiniz; sistem çökmez, parametrelere sessizce undefined basar. Olmayan bir objenin altındaki özelliği okumaya çalışırsınız; derleme anında tek bir uyarı bile almazsınız.

Sonra ne olur?

Gece yarısı telefonunuz çalar. Şirketin e-ticaret platformunda faturalandırma servisi çökmüştür. Neden mi? Çünkü ödeme API'sinden gelen total_amount alanı bir yerde string ("1500"), diğer yerde number (1500) olarak ele alınmış; indirim kodu uygulanırken matematiksel çıkarma yerine metin birleştirme yapılmış ve müşteriden 1500 TL yerine 0 TL tahsil edilmiştir. Veya daha kötüsü: Canlı ortamda kullanıcı profil sayfasına tıkladığında o meşhur, kan dondurucu hata ekranı fırlar:

TypeError: Cannot read properties of undefined (reading 'map')

İşte bu hata, acil tıpta hastaya yanlış ilacı verdikten sonra monitörde gördüğünüz ventriküler fibrilasyon dalgasıdır. Hasta ölmüştür, monitör ötmeye başlamıştır ve siz neyin ters gittiğini anlamak için panik içinde log kayıtlarını (hastanın dosyasını) karıştırırsınız.

"TypeScript Beni Yavaşlatıyor" Zırvası

Son yıllarda TypeScript sektör standardı haline gelmiş olsa da, hâlâ pek çok geliştiriciden ve startup kurucusundan aynı itirazı duyuyorum:
"TypeScript geliştirme hızımızı kesiyor. Sürekli interface tanımlamakla, type casting ile uğraşıyoruz. Biz hızlıca prototip çıkarıp pazara girmeliyiz (Move fast and break things)."

Bu argüman, sahada acelesi olan bir paramediğin "Ampulün üzerindeki etiketi okumak beni yavaşlatıyor, çekip rastgele basayım işte" demesiyle birebir aynı mantıksal hezeyandır.

Evet, TypeScript yazarken fazladan birkaç satır kod yazarsınız. Fonksiyonunuzun ne aldığını, ne döndürdüğünü, hangi alanların null olabileceğini açıkça belirtmek zorunda kalırsınız. Bazen derleyici (compiler) size inatla kırmızı dalgalı çizgiler çeker ve "Burada tip uyumsuzluğu var, geçemezsin!" der.

Ama o kırmızı çizgi, sizin düşmanınız değildir. O kırmızı çizgi, gece saat üçte yatağınızdan fırlayıp sunucuya SSH ile bağlanmanızı engelleyen dijital bir emniyet kilididir.

TypeScript sizi yavaşlatmaz. TypeScript, hatayı müşterinin ve kullanıcının önünde (Runtime) yapmaktan alıp, henüz kodu yazarken kendi bilgisayarınızın içinde (Compile Time) güvenli bir şekilde patlatmanızı sağlar. Hatayı derleme anında yakalamanın maliyeti sıfır liradır; o hatayı production'da bir kullanıcının satın alma sepetinde yakalamanın maliyeti ise bazen yüz binlerce dolardır.

any Kullanmak: Etiketsiz Ampulü Hastaya Enjekte Etmek

TypeScript projelerinde gördüğüm en büyük günah ise any tipinin pervasızca kullanılmasıdır. Geliştirici derleyicinin uyarısıyla baş edemediği an, kolay yola kaçar:

const processPayment = (data: any) => { ... }

Bir değişkene any atadığınız an, aslında TypeScript derleyicisine şunu söylersiniz: "Gözlerini kapat. Sana güvenmiyorum. Buradaki kuralları askıya al."

Bu, acil tıp dolabındaki ilacın üzerindeki etiketi kazıyıp, üstüne tükenmez kalemle "Bir şeyler işte" yazmaya benzer. O an işinizi görür, derleyici susar, derleme işlemi başarıyla tamamlanır. Ama o fonksiyonun içine neyin gireceği ve oradan neyin çıkacağı artık tamamen karanlıktadır. İlk beklenmedik veri dalgasında sistem patlayacak ve arkasında hiçbir iz bırakmayacaktır.

Eğer bir projede TypeScript kullanıyor ama her sıkıştığınız yere any basıyorsanız, kendinizi kandırıyorsunuz demektir. Güvenlik kemeri takmış gibi yapıp arkadan bağlayan bir sürücüden farkınız yoktur.

Tip Güvenliği Bir Tercih Değildir

Bugün karmaşık dağıtık sistemler, onlarca mikroservis, yüzlerce üçüncü parti API ve devasa ekiplerle yazılım geliştiriyoruz. İnsan beyninin, tek bir projede dolaşan binlerce veri tipinin tüm varyasyonlarını, kenar durumlarını (edge cases) ve null olasılıklarını aklında tutabilmesi biyolojik olarak imkânsızdır.

Tip güvenliği (Type Safety) fildişi kulelerde yaşayan bilgisayar bilimcilerinin bir kaprisi değildir. Tip güvenliği; yorgun, uykusuz, dikkati dağılmış insanların hata yapmasını engelleyen zihinsel bir dış iskelettir.

Dozaj hatasının affedilmediği bir dünyada yaşıyoruz. Kodunuz ister bir hastane cihazını yönetsin, ister sıradan bir e-ticaret sepetini; kullanıcılarınızın güvenini ve paranızı riske atıyorsunuz demektir.

Bir dahaki sefere TypeScript derleyicisi önünüze bir hata çıkardığında ona kızmayın.
Çünkü o kırmızı çizgi; sizi, şirketinizi ve itibarınızı az önce ölümcül bir doz aşımından kurtardı.

Sol koldan damar yolunu başarıyla açtığınız an, henüz stajyer olan birinin içi rahatlayabilir: "Tamam, kanala girdik, serumu ve acil ilaçları verebiliriz."

Ama tecrübeli paramedik durmaz. Hemen diğer kolu işaret eder: "Sağ kola da bir tane aç."

Stajyer şaşırır: "Ama zaten sol koldan açtık, sıvı akıyor, neden hastayı tekrar delelim?"

Cevap, acil tıbbın mezarlıklarla ödenmiş en acımasız kurallarından biridir: Tek damar yolu, hiç damar yolu demektir.

Çünkü o hasta birazdan şoka girebilir, damarları büzüşüp çökebilir. Ambulans hızla viraj alırken iğne yerinden kayabilir, damar patlayabilir (ekstravazasyon), verdiğiniz kritik ilaç doku altına sızabilir. Kalp durduğunda ya da tansiyon sıfıra yaklaştığında, patlamış bir damarın başında yeni bir delik arayacak 10 saniyeniz bile olmaz. İkinci bir damar yolu bir lüks veya aşırılık değildir; o an ile ölüm arasındaki yegane emniyet kemeridir.

Bulutun Sahte Güvenlik İllüzyonu

Şimdi bu sahneden çıkıp, kahve kokulu açık ofislere veya evdeki o konforlu çalışma masalarımıza dönelim.

Yazılım dünyasında bu duruma verilen teknik bir isim var: Single Point of Failure (SPOF) — yani "Tek Hata Noktası". Tanımı basittir: Çöktüğü anda arkasındaki tüm sistemi felç eden tekil bileşen. Teoride her bilgisayar mühendisliği öğrencisi bunu bilir. Sistem tasarımı mülakatlarında herkes tahtaya çift load balancer, yedekli veritabanları (multi-AZ replication) ve dağıtık kuyruklar çizer.

Ama iş gerçek hayattaki mimarilere geldiğinde, devasa şirketlerin bile akıl almaz bir saflıkla "tek bir damar yoluna" mahkûm yaşadığını görürsünüz.

Tüm kimlik doğrulama sistemini tek bir üçüncü parti SaaS servisine (mesela Auth0) bağlarlar. Tüm DNS trafiğini tek bir sağlayıcının ellerine teslim ederler. Bütün CI/CD süreçlerini tek bir platformun sunucularına emanet ederler. Ve sonra ne olur?

Cloudflare bir BGP yönlendirme hatası yapar; dünya internetinin yarısı kararır. AWS'in us-east-1 veri merkezinde bir API gateway aksar; akıllı süpürgelerden bankacılık uygulamalarına kadar her şey taş devrine döner. Bir güvenlik yazılımı (adını hepimizin bildiği o ünlü güncelleme vakası) tek bir bozuk konfigürasyon dosyası yollar; havaalanlarında uçuşlar durur, hastane monitörleri mavi ekrana düşer.

O gün Slack kanallarında yöneticilerin ve mühendislerin dövünüşünü izlersiniz: "Bizim kodumuzda hata yok, servis sağlayıcı çöktü!"

Evet, sizin kodunuzda hata yoktu. Tıpkı ambulansta damarı patlayan hastanın kendi kendine şoka girmemesi gibi. Ama siz, tek bir damar yoluna güvenerek hastayı yola çıkarmıştınız.

Yedeklilik (Redundancy) Masraf Değildir

Yazılımcılar ve özellikle şirketlerin finans departmanları, gerçek anlamda yedekli (redundant) bir altyapı kurmayı çoğu zaman "gereksiz maliyet" olarak görür.

"Neden Cloudflare'in yanına ikinci bir DNS yapılandırması kuralım ki? Zaten adamlar %99.99 SLA veriyor."
"Neden Stripe'ın yanına alternatif bir ödeme geçidi entegre edelim? Kod tabanı iki kat karmaşıklaşır."
"Neden veritabanının soğuk bir yedeğini tamamen farklı bir bulut sağlayıcıda (mesela AWS dışındaki bağımsız bir bare-metal sunucuda) tutalım?"

Bu soruları soran zihniyet, ambulansta "Zaten sol kolda damar yolu açık, ikinci intraket 5 lira, o parayı harcamayalım" diyen zihniyetle aynıdır.

Sistem sorunsuz çalışırken yedeklilik gerçekten de göze batar. Fazladan konfigürasyon demektir, fazladan bakım demektir, faturada fazladan satır demektir. Tıpkı kazazedenin sağ koluna takılı duran ve içinden henüz tek bir damla ilaç geçmemiş o boş plastik intraket gibi... Orada öylece, anlamsızca durur.

Ta ki o sol koldaki damar patlayana kadar.

O an geldiğinde, o boş plastik parçası dünyanın en değerli nesnesine dönüşür. Saniyeler içinde ilacı sağ koldan verir, hastanın kalbini ritimde tutarsınız. Ne ambulans durur, ne müdahale kesilir.

Yazılımda da durum farksızdır. Birincil ödeme sağlayıcınız zaman aşımına uğradığında trafiği saniyesinde ikinci sağlayıcıya yönlendirebilecek bir "circuit breaker" mimariniz varsa; bir DNS sağlayıcısı çöktüğünde secondary DNS devreye giriyorsa, kullanıcılarınız aradaki kesintiyi fark etmez bile. Şirketiniz milyonlarca liralık ciro kaybından ve en önemlisi silinmesi aylar süren o güven erozyonundan kurtulur.

Gerçek Mühendislik Krizden Önce Başlar

Sahada hayat kurtaran şey mucizeler değildir; kötü gün senaryolarına duyulan saygıdır. Paramedik, hastanın her an kötüleşebileceğini kabullendiği için hazırlıklıdır.

Sistem mühendisliği de tam olarak budur. Eğer bir mimari tasarlarken "X servisi asla çökmez" varsayımıyla yola çıkıyorsanız, henüz mühendislik yapmıyorsunuz demektir; sadece kumar oynuyorsunuzdur. Çünkü doğanın, elektriğin, kabloların ve insanların olduğu her yerde her şey çöker. Sunucular yanar, fiber kabloları kepçeler koparır, en güvenilir şirketlerin veri merkezleri su basar.

Bir dahaki sefere sisteminizin mimari şemasına baktığınızda kendinize şu soruyu sorun:
"Eğer şu an en çok güvendiğim kutucuk haritadan silinseydi, sistemim yaşamaya devam eder miydi?"

Eğer bu sorunun cevabı derin bir sessizlik ve soğuk bir ter damlasıysa; bilin ki hastanız sedyede tek bir damar yoluyla yatıyor. Ve yol çok engebeli.

İş-yaşam dengesi. Kulağa bir yoga dersinin ardından lavanta çayı içerken söylenecek kadar huzurlu geliyor, değil mi? Ama bir dakika. Eğer bu denge gerçekten sağlanabilseydi, neden yazılım sektörü dünyanın en yüksek tükenmişlik (burnout) oranlarına sahip sektörlerden biri?

Sınırsız İznin Sınırsız Yalanı

"Sınırsız izin politikası" (Unlimited PTO), son yılların en parlak kurumsal yalanıdır. Teoride istediğiniz kadar izin alabilirsiniz. Pratikte ise kimse izin almaz. Çünkü belirlenmiş bir izin kotanız olmadığında, her aldığınız izin günü bir "seçim" haline gelir. Ve o seçim, görünmez bir yargılanma süzgecinden geçer.

"Ahmet bu çeyrekte 15 gün izin almış, acaba yeterince bağlı mı projeye?" Bu cümle hiçbir zaman yüksek sesle söylenmez ama herkesin bilinçaltında dolanır. Sonuç olarak, sınırsız izin politikası olan şirketlerde çalışanlar, geleneksel 20 günlük kotası olan şirketlere göre ortalama olarak daha az izin kullanırlar.

Bir paramedik olarak 24 saatlik nöbet sistemini yaşamış biri olarak "denge" kavramının ne olduğunu ve ne olmadığını çok iyi bilirim. 24 saat boyunca her an bir çağrı gelebilir. O 24 saatin sonunda eve gittiğinizde bedeniniz orada olsa bile beyniniz hâlâ son müdahaleyi tekrar eder. "Daha iyi yapabilir miydim?" sorusu sizi uyutmaz.

Yazılım dünyasında 24 saatlik nöbet yoktur ama Slack bildirimleri 24 saat vardır. Ve bir Slack bildirimi, bir ambulans sireninden daha az acil olmasına rağmen, aynı stres yanıtını tetikleyebilir.

Oyun Odası Paradoksu

Silikon Vadisi şirketlerinin icat ettiği en sinsi psikolojik manipülasyon, ofisi "eve" dönüştürmektir. Ücretsiz yemek, ücretsiz çamaşırhane, oyun odası, uyku kabinleri, meditasyon odaları... Tüm bunlar çalışan "mutluluğu" için değil, çalışanın ofisten ayrılmaması için tasarlanmıştır.

Eğer ofiste ücretsiz akşam yemeği veriyorsanız, çalışan akşam 6'da eve gitmez. Eğer ofiste çamaşırhane varsa, çalışan hafta sonu o işi yapma bahanesini kaybeder. Eğer ofiste uyku kabini varsa, "Eve gidip uyuyayım" seçeneği ortadan kalkar.

Bu, çalışanı altın kafeste tutmanın en rafine halidir. Kafes o kadar rahat, o kadar güzel ki içinde olduğunuzu fark etmezsiniz. Ta ki bir gün kafes kapandığında — projeniz geciktiğinde, performans değerlendirmeniz düşük geldiğinde, ofisteki o "aile ortamı" bir anda soğuk bir kurumsal ortama dönüştüğünde — tüm o ücretsiz avokadolu tostların aslında bir fiyatı olduğunu anlarsınız.

Gerçek Denge Nedir?

İş-yaşam dengesi bir oran (ratio) değildir. Gününüzü yüzde elli iş, yüzde elli yaşam diye bölmeniz gerekmez. Gerçek denge, sınırdır. Nerede durduğunuzu bilmektir.

Acil tıpta bu sınır somuttur: Nöbetiniz bittiğinde gidersiniz. Ambulansın anahtarını teslim edersiniz. Radyonuzu kapatırsınız. O andan itibaren ne çağrı alırsınız ne de "Acaba birisine bir şey oldu mu?" diye düşünürsünüz. Çünkü bilirsiniz ki dinlenmemiş bir paramedik, bir sonraki müdahalede hastayı değil, kendisini riske atar.

Yazılımda bu sınır bulanıktır. Laptop'unuz her zaman yanınızdadır. Slack her zaman açıktır. E-posta her zaman okunabilir durumdadır. Ve "acil" kelimesi, üç satırlık bir CSS düzeltmesi için bile kullanılabilir.

Gerçek iş-yaşam dengesi, laptop'u kapattığınızda kapanıp kalmayı başarmaktır. Bildirim sesini duyduğunuzda refleks olarak telefona uzanmamaktır. "Bu benim mesai saatlerim dışında" diyebilme cesaretini göstermektir.

Bu cesaret, bir şirketin size vereceği bir "perk" (yan hak) değildir. Kendinize vereceğiniz bir sözdür. Ve tıpkı iyi yazılmış bir kod gibi, bu sözü tutmak disiplin, farkındalık ve bazen de "Hayır" diyebilme gücü gerektirir.

Bir yapay zekaya kod yazdırıyorsunuz ve size var olmayan bir JavaScript kütüphanesini kullanmanızı öneriyor. Üstelik bu uydurma kütüphanenin nasıl kurulacağını, içindeki fonksiyonların nasıl çalışacağını o kadar özgüvenli, o kadar akademik bir dille anlatıyor ki, bir an için kendinizden şüphe ediyorsunuz. "Acaba ben mi bilmiyorum?"

Çoğumuz bu durumu yapay zekanın "aptallığı" veya "henüz yeterince gelişmemiş olması" olarak yorumlayıp geçiyoruz. Ancak aynayı kendimize çevirdiğimizde, aslında çok daha rahatsız edici bir gerçekle yüzleşiyoruz: Biz de tam olarak aynı şeyi yapıyoruz.

Özgüvenli Uydurmanın Evrimi

Yapay zekanın halüsinasyonları, aslında insani kibrin (hubris) algoritmik bir yansımasından ibarettir. İnsanlar olarak, özellikle profesyonel ortamlarda, "Bilmiyorum" demeyi zayıflık olarak algılamaya programlanmış durumdayız.

Şu senaryoyu düşünün: Önemli bir iş mülakatındasınız. Karşınızdaki teknik yönetici size, adını hayatınızda ilk defa duyduğunuz "X" aracıyla ilgili deneyiminizi soruyor. O anki sessizlik saniyeler sürse de size saatler gibi gelir. Ve beyninizdeki nöral ağlar (tıpkı ChatGPT gibi) o kelimenin etrafındaki en muhtemel kelimeleri bir araya getirerek özgüvenli bir cümle kurar: "X aracını doğrudan production'da kullanmadım ama arkasındaki mimari yapıya ve dağıtık sistem prensiplerine oldukça hakimim."

Tebrikler. Az önce beyniniz, tamamen bir dil modeli halüsinasyonu yarattı. İçi tamamen boş, teknik olarak hiçbir şey ifade etmeyen ama gramer olarak kusursuz, muazzam özgüvenli bir yalan.

Bilmemenin Dayanılmaz Ağırlığı

ChatGPT'nin var olmayan kütüphaneler uydurmasıyla, beyaz yakalı bir yöneticinin toplantıda "Sinerjiyi proaktif bir şekilde end-to-end yönetmeliyiz" diyerek konuşması arasında hiçbir mimari fark yoktur. İkisi de elindeki yetersiz veri setini, kulağa en mantıklı gelecek şekilde sıraya dizmekten ibarettir.

Yapay zeka modelleri, kelimelerin istatistiksel olasılıklarını hesaplayarak cümle kurarlar. Bilmedikleri bir şey sorulduğunda sessiz kalmak yerine, mevcut bağlama en uygun kelimeyi "uydururlar". Çünkü onların hedef fonksiyonu (objective function) size doğruyu söylemek değil, sizin tatmin olacağınız, ikna edici bir metin üretmektir.

Tıpkı modern eğitim ve iş sistemimizin insanları kodladığı gibi. Bize doğruyu söylemek değil, "yeterince ikna edici görünmek" öğretildi.

Aynadaki Yüzümüz

Yapay zekanın hatalarına gülerken, aslında yaratıcısının zaaflarına gülüyoruz. Yapay zeka, internetin tüm bilgi birikimini değil, internetin tüm davranış biçimlerini emerek öğrendi. Ve bizim en büyük davranış biçimimiz, cehaletimizi sahte bir özgüvenin arkasına saklamaktır.

Belki de yapay zekayı düzeltmeden önce, kendi "bilmiyorum" diyebilme kasımızı geliştirmemiz gerekiyor. Çünkü "Bunu bilmiyorum, araştırıp öğrenebilirim" diyebilen bir Junior geliştirici, yalan söyleyen milyar parametreli bir modelden çok daha değerlidir. Yapay zeka bizim uydurma sanatımızı mükemmelleştirmeden önce, bizim dürüstlük sanatını hatırlamamızın vakti geldi.

Mavi kod ekibinin çalışma dinamiği, insanlık tarihindeki en rafine edilmiş kriz yönetimi protokollerinden biridir. Odaya giren herkes rolünü bilir: Biri göğüs kompresyonuna başlar, biri hava yolunu yönetir, biri ilaçları hazırlar, biri zamanı tutar. Kimse bağırmaz. Kimse birbirini suçlamaz. Kimse "Bu hastaya kim bu ilacı verdi de kalbi durdu?" diye sormaz. Çünkü o an için tek bir hedef vardır: Hastayı geri getirmek.

Şimdi bu sahneyi yazılım dünyasıyla kıyaslayalım.

Production Çöktüğünde: Suç Avı Başlar

Cuma akşamı saat 18:30. Herkes evine gitmeye hazırlanırken Slack'ten o korkunç bildirim gelir: "🔴 PRODUCTION DOWN — Tüm kullanıcılar 500 hatası alıyor."

Bir hastanede bu an, mavi kodun ilan edildiği andır. Ama bir yazılım şirketinde olan şey bambaşkadır. İlk beş dakika şöyle geçer:

• Dakika 1: "Ben bir şey yapmadım."
• Dakika 2: "Son deploy'u kim yaptı?"
• Dakika 3: "Backend'in PR'ını kim onayladı?"
• Dakika 4: "Bu feature zaten riskli demiştim ama kimse dinlemedi."
• Dakika 5: Sistem hâlâ çökmüş durumda. Kimse çözüme odaklanmıyor çünkü herkes kendini aklamakla meşgul.

Eğer bir hastanede mavi kod anında ekip üyeleri "Ben bu hastaya dokunmadım" diyerek odadan çıkmaya çalışsaydı, o hasta kesinlikle ölürdü. Ama yazılım dünyasında tam olarak bunu yapıyoruz. Sistemi hayata döndürmek yerine, suçluyu bulmaya harcadığımız her dakika, kullanıcılarımızın güvenini biraz daha öldürüyor.

Suçsuz Post-Mortem: Acil Tıptan Bir Ders

Acil tıpta resüsitasyon bittikten sonra yapılan bir değerlendirme toplantısı vardır. Bu toplantıda neler doğru gitti, neler yanlış gitti, hangi protokol ihlal edildi tartışılır. Ancak bu toplantının temel kuralı şudur: Kişiler değil, süreçler sorgulanır.

"Dr. Aslı neden yanlış ilaç verdi?" yerine "İlaç etiketleme sistemimiz neden bu karışıklığa izin veriyor?" sorusu sorulur. Çünkü acil tıp, bireysel hataların kaçınılmaz olduğunu kabul eder. Önemli olan, sistemin bu bireysel hataları yakalayacak ve telafi edecek şekilde tasarlanmasıdır.

Yazılım dünyasının buna karşılık gelen aracı "Blameless Post-Mortem" (Suçsuz Olay Sonrası Değerlendirme) olarak bilinir. Google, Etsy, Netflix gibi şirketler bu kültürü benimsemiştir. Ancak çoğu küçük ve orta ölçekli şirkette post-mortem toplantıları hâlâ "Kimin suçu?" sorusuyla başlar ve biter.

Bu kültür, uzun vadede ekibin korkudan risk almaktan kaçınmasına, deploy sıklığının düşmesine ve en tehlikelisi geliştiricilerin hataları gizlemesine yol açar. Çünkü bir hata yaptığınızda cezalandırılacağınızı bilirseniz, hatayı bildirmek yerine üstünü örtmeyi tercih edersiniz. Ve üstü örtülen hatalar, ileride çok daha büyük felaketlere dönüşür.

Panik Yönetimi: Nabzınız mı, Sunucunuzun Nabzı mı?

Bir paramedik olarak en zor öğrendiğiniz beceri, panik yapmamaktır. Karşınızda kanlar içinde, bilinci kapalı bir insan yatarken kendi kalbinizin hızlanmasını hissedersiniz. Ama yılların eğitimi ve pratiği size şunu öğretmiştir: Önce kendi nabzınızı kontrol edin. Çünkü panik halindeki bir kurtarıcı, kurtarıcı değildir; ikinci bir kurbandır.

Yazılım krizlerinde de bu prensip birebir geçerlidir. Production çöktüğünde panikle atılan bir git revert veya daha kötüsü bir git push --force, zaten yaralı olan sistemi tamamen öldürebilir. Sakin bir şekilde logları okumak, sorunu izole etmek ve adım adım müdahale etmek ile "HER ŞEYİ GERİ AL!" diye bağırmak arasındaki fark, hastayı kurtarmakla kaybetmek arasındaki fark kadardır.

Bir dahaki sefere production çöktüğünde, kendinize mavi kod anındaki o ekibi hatırlatın. Suçlu aramayın. Rolünüzü bilin. Önce sistemi stabilize edin. Otopsiyi, hasta hayata döndükten sonra yaparsınız.

Şimdi bu lüksü tamamen ortadan kaldırın.

Karşınızda bilinçsiz bir insan yatıyor. Yerde bulunmuş. Etrafında hiçbir tanık yok. Kimliği belirsiz. Alerjileri bilinmiyor. Kronik hastalıkları bilinmiyor. Hangi ilaçları kullandığı bilinmiyor. Ve bu insan size tek bir hata mesajı bile veremiyor. Log dosyası yok. Stack trace yok. console.log çıktısı yok. Sadece bir beden var; nefes alıp almadığını, kalbinin atıp atmadığını, gözbebeklerinin ışığa tepki verip vermediğini kontrol ederek o bedenin "mimarisini" çözmeye çalışıyorsunuz.

İşte paramediklik, log dosyası olmayan bir sistemi debug etme sanatıdır.

Dış Belirtilerden İç Mimariyi Okumak

Yazılımda "Black Box Testing" (Kara Kutu Testi) diye bir kavram vardır. Sistemin iç yapısını bilmeden, sadece girdilere verdiği çıktılara bakarak o sistemin doğru çalışıp çalışmadığını test edersiniz.

Acil tıpta her hasta müdahalesi bir kara kutu testidir. Hastanın iç organlarını göremezsiniz (en azından sahada). Beyninin içine bakıp "Ah, burada bir kanama var" diyemezsiniz. Onun yerine dış belirtileri (semptomları) okursunuz ve bu parçalardan bir bütün oluşturursunuz:

• Cildi solgun ve soğuksa → muhtemelen kan kaybı var (internal bleeding).
• Bir taraftaki gözbebeği diğerinden büyükse → kafa içi basınç artışı olabilir.
• Nefes sesleri bir tarafta duyulmuyor → akciğer çökmüş (pnömotoraks) olabilir.
• Karın sert ve gerginse → iç kanama ihtimali yüksek.

Bu ipuçları, bir yazılımcının log dosyasındaki "ERROR", "WARNING" ve "INFO" satırlarına karşılık gelir. Tek fark şudur: yazılımcı yanlış bir çıkarım yaparsa en kötü ihtimalle sunucu birkaç dakika daha çöker. Paramedik yanlış bir çıkarım yaparsa, karşısındaki insan ölür.

Timeout Problemi: Zaman Baskısı Altında Karar Vermek

Bir yazılımcı olarak debug yaparken en büyük avantajınız zamandır. Bir bug'ı saatlerce, hatta günlerce araştırabilirsiniz. Kahvenizi yudumlarken Stack Overflow'da benzer vakaları inceleyebilir, farklı hipotezleri test edebilir, meslektaşlarınızla beyin fırtınası yapabilirsiniz.

Acil tıpta bu lüks yoktur. Sahada bir hastayı değerlendirmek ve karar vermek için genellikle 60 saniyeniz vardır. Bilişsel yükünüz (cognitive load) had safhadadır. Etrafınızda bağıran insanlar, trafik sesleri, bazen fiziksel tehlikeler vardır. Ve tüm bu kaosun içinde, eksik verilerle hayati bir karar vermek zorundasınızdır.

Bu, yazılımdaki "timeout" konseptinin gerçek hayattaki en acımasız versiyonudur. Sunucunuz bir isteğe 30 saniye içinde yanıt vermezse, istemci bağlantıyı koparır. Siz bir hastayı 60 saniye içinde doğru değerlendiremezseniz, vücut kendi "bağlantısını" koparır.

Redundancy ve Failover: Vücudun Yedekleme Sistemi

İnsan vücudunun yazılım mimarisi açısından en etkileyici yanı, dahili yedekleme (redundancy) sistemidir. İki böbreğiniz vardır; biri çalışmasa diğeri devralır. Karaciğerinizin yüzde yetmişi hasar görse bile geri kalanı fonksiyonlarını sürdürebilir. Beyin, hasarlı bir bölgenin görevlerini başka bölgelere aktarabilir (nöroplastisite).

Bu, yazılım dünyasındaki "failover" (yük devretme) mekanizmasının milyonlarca yıllık evrimsel versiyonudur. Ancak vücudun yazılımdan bir farkı var: vücudun yedekleme sistemi sessizdir. Bir böbreğiniz çalışmayı durdurduğunda size bir uyarı e-postası göndermez. Karaciğeriniz yüzde otuz kapasiteye düştüğünde bir Slack bildirimi almıyorsunuz. Vücut, son ana kadar telafi etmeye çalışır ve siz sorunun farkına vardığınızda genellikle çok geç olmuş demektir.

Bir paramedik olarak öğrendiğim en önemli şey şudur: Görünür belirtiler, hasarın son evresidir. Hasta yere yığıldığında sorun çoktan kritik seviyeye ulaşmıştır. Tıpkı bir sunucunun CPU'su yüzde yüze çıkıp alarm verdiğinde, asıl sorunun çoktan dakikalar önce başlamış olması gibi.

İster insan vücudu olsun ister bir dağıtık sistem, gerçek mühendislik belirtileri görmeden önce riskleri tahmin edebilme sanatıdır. Ve bu sanat, ne yazık ki hiçbir framework, kütüphane veya ders kitabıyla öğretilmez. Sadece sahada, gerçek krizlerin içinde, elleriniz titrerken ama aklınız berrak kalırken kazanılır.

Ama biz bu mezar taşlarının arkasındaki insanları hiç düşünüyor muyuz?

Ölü Kodun Arkasındaki Canlı İnsanlar

Her kapatılan projenin arkasında, o projeye aylar hatta yıllar boyunca emek vermiş mühendisler vardır. O ürünün mimarisini tasarlayan, ilk commit'i atan, ilk bug'ını gece yarısı düzelten, kullanıcılardan gelen ilk olumlu geri bildirimle gözleri parlayan insanlar.

Ve bir gün, genellikle bir Salı sabahı yapılan bir "all-hands" toplantısında, bir yönetici kısa bir sunum yapar: "Stratejik önceliklerimizi yeniden değerlendirdik ve X ürününü sonlandırma kararı aldık." Slaytlarda kâr-zarar tabloları, kullanıcı edinme maliyetleri ve "yatırım getirisi" (ROI) grafikleri gösterilir. Her şey matematik olarak mükemmel bir anlam taşır.

Ama o odada, bir yılını o ürüne veren mühendis için bu bir matematik problemi değildir. Bu bir cenaze törenidir. Ve en kötüsü, bu cenazede yas tutmanıza izin verilmez. Toplantı biter, herkes masasına döner ve bir sonraki projeye "aynı heyecanla" başlaması beklenir.

Sunk Cost ve Duygusal Yatırım

Ekonomide "Batık Maliyet Yanılgısı" (Sunk Cost Fallacy) kavramı, geçmişte yapılan yatırımların gelecekteki kararları etkilememesi gerektiğini söyler. Bir projeye 2 milyon dolar harcamış olmanız, o projenin devam etmesi için bir sebep değildir. Rasyonel olan, o projenin gelecekte getireceği değere bakarak karar vermektir.

Bu, kâğıt üzerinde tamamen mantıklıdır. Ama insanlar kâğıt üzerinde yaşamıyor.

Bir mühendis o projeye sadece saatlerini değil, kimliğinin bir parçasını yatırmıştır. "Ben X projesinin baş geliştiricisiyim" demiştir sosyal ortamlarda. O projenin başarılarını kendi başarıları olarak hissetmiştir. Arkadaşlarına "Şu özelliği ben yaptım" diye gururla göstermiştir.

Bu duygusal yatırımın bir batık maliyet tablosunda karşılığı yoktur. CFO'nun Excel'inde görünmez. Ama o mühendiste bıraktığı iz, bir sonraki projede azalmış motivasyon, şirkete olan güvenin erozyonu ve "Neden emek vereyim ki, bunu da kapatacaklar" düşüncesi olarak geri döner.

Paramedikler ve Kayıp

Paramedik olarak hastalarınızı kaybetmeyi öğrenirsiniz. Bu, mesleğin en karanlık ve en kaçınılmaz parçasıdır. Her kaybın ardından kendinize sordunuz soruları hatırlarsınız: "Daha hızlı müdahale edebilir miydim? Farklı bir ilaç versem sonuç değişir miydi?" Bu sorular sizi kemirmeye başladığında, deneyimli bir meslektaşınız gelir ve şöyle der: "Bazı hastaları kurtaramazsın. Bu senin hatanla ilgili değil, durumun ağırlığıyla ilgili."

Yazılım dünyasında bu tür bir duygusal destek mekanizması yoktur. Bir proje kapatıldığında kimse gelip "Bu senin kodunla ilgili değildi, pazar koşulları uygun değildi" demez. Şirketler, projelerini kapattığında bunu soğuk bir iş kararı olarak sunar ve ekipten ertesi gün yeni bir projeye aynı tutkuyla başlamasını bekler.

Ama insan beyni böyle çalışmaz. Her kayıp, ister bir hasta ister bir proje olsun, bir iz bırakır. Ve bu izler işlenmezse birikerek tükenmişliğe (burnout) dönüşür.

Dijital Mezarlıkta Yürümek

Bir dahaki sefere eski bir projenizin kapandığını duyduğunuzda, o projeye harcadığınız zamanı "boşa gitti" olarak düşünmeyin. O süreçte öğrendiğiniz mimari kararlar, yapılan hatalar, ekip dinamikleri ve teknik zorluklar sizin mühendislik DNA'nıza işlemiştir. Ürün ölebilir ama deneyim ölmez.

Ve belki de yazılım sektörünün ihtiyacı olan şey, projelerin kapatılmasını bir "başarısızlık" değil, bir "mezuniyet" olarak görmektir. O proje tamamlandı. Rolünü oynadı. Sizin o versiyonunuzu şekillendirdi. Şimdi sıra, o deneyimle daha güçlü bir şey inşa etmekte.

Her yazılım projesi, eninde sonunda ya kapanır ya da legacy koda dönüşür. İkisi de bir nevi ölümdür. Ama bazı ölümler, yeni başlangıçların habercisidir.

Ama Martin'in kitabında satır aralarına gizlenmiş, çoğu kişinin gözünden kaçan bir cümle vardır: "Kod, insanlar tarafından okunmak için yazılır; makineler tarafından çalıştırılması sadece bir yan etkidir." Bu cümle, yazılım mühendisliğinin en derin gerçeğini barındırır: Kod yazmak, aslında bir iletişim eylemidir.

Ve iletişimin kalitesi, doğrudan empati kapasitesiyle ölçülür.

Gelecekteki Yabancıya Mektup

Her yazdığınız fonksiyon, her oluşturduğunuz sınıf, her commit'lediğiniz dosya aslında gelecekte o kodu okuyacak birine yazılmış bir mektuptur. O kişi belki bir yıl sonraki kendinizdir; belki de projeye yeni katılmış, henüz mezun olmuş, heyecanlı ama tedirgin bir genç geliştiricidir.

Empati sahibi bir mühendis, kod yazarken şu soruyu sorar: "Bu kodu ilk defa gören, bağlamı bilmeyen, belki de gece 3'te çökmüş bir sistemi ayağa kaldırmaya çalışırken bu fonksiyonu okuyan biri ne hisseder?"

Eğer cevabınız "Muhtemelen kafası karışır, hangi parametrenin ne işe yaradığını anlamaz ve en az 30 dakikasını bu fonksiyonun ne yaptığını çözmeye harcar" ise, o kod teknik olarak çalışıyor olsa bile başarısızdır.

Paramediklikte buna benzer bir kavram vardır. Bir hastayı stabilize ettikten sonra hastaneye teslim ederken yazdığınız notlar, sizi hiç tanımayan bir doktor tarafından okunacaktır. O notların netliği, eksikliği veya karmaşıklığı, hastanın tedavi sürecini doğrudan etkiler. Sahadaki notlarınız karışıksa, hastanedeki ekip kritik bir bilgiyi kaçırabilir. Tıpkı karışık bir kod tabanında gizlenmiş bir bug'ın, aylar sonra production'ı çökertmesi gibi.

"Çalışıyor" ile "Anlaşılıyor" Arasındaki Uçurum

Yazılım dünyasında bir meritokrasi yanılsaması (meritocracy illusion) vardır: "En iyi kod, en hızlı çalışan koddur." Bu inanış, geliştiricileri okunaklılıktan çok performansa, anlaşılırlıktan çok zekice çözümlere yönlendirir.

Bir fonksiyonu tek satırda, üç tane ternary operatör ve bir reduce zinciriyle yazabilirsiniz. O satır muhtemelen çalışır, muhtemelen performanslıdır ve sizi muhtemelen çok zeki hissettirir. Ama o satırı iki ay sonra okuyan biri (ki o kişi büyük ihtimalle yine siz olacaksınız) "Bu ne?" diye ekrana bakakalmak zorunda kalacaktır.

Empati, bu noktada devreye girer. Empatik bir geliştirici, zekâsını göstermek için değil, karşısındakinin hayatını kolaylaştırmak için kod yazar. Fonksiyonu birkaç satıra böler. Değişkenlere anlamlı isimler verir. Karmaşık bir iş kuralı varsa üstüne bir yorum yazar — ama sadece "ne" yaptığını değil, "neden" böyle yapıldığını açıklayan bir yorum.

Ego ve Kod İncelemesi (Code Review) Savaşları

Kod incelemesi (Code Review), yazılım ekiplerinde empatinin sınandığı en keskin alandır. Birinin yazdığı kodu eleştirmek, dolaylı olarak onun düşünce sürecini, kararlarını ve yetkinliğini sorgulamaktır. Bu süreç ya bir öğrenme fırsatına ya da bir ego savaşına dönüşebilir.

Empatiden yoksun bir kod incelemesi şöyle görünür: "Bu yaklaşım tamamen yanlış. Neden X pattern'ı kullanmadın?" Bu geri bildirim teknik olarak doğru olabilir ama alıcısında savunma refleksi tetikler, öğrenme kapısını kapatır ve ekip içi güveni aşındırır.

Empatik bir kod incelemesi ise şöyle görünür: "Buradaki yaklaşımı anlıyorum. Bir de X pattern'ını denemeyi düşündün mü? Şu senaryoda avantaj sağlayabilir." Aynı teknik geri bildirim, ama alıcısına saygı gösteren, onun perspektifini kabul eden ve birlikte öğrenmeye davet eden bir ton.

Derleyicinin Görmediği Hatalar

TypeScript, ESLint, Prettier... Bu araçlar kodunuzun teknik doğruluğunu ve biçimsel tutarlılığını kontrol eder. Ama hiçbir derleyici, kodunuzun ne kadar "insancıl" olduğunu ölçemez. Hiçbir linter, fonksiyonunuzun adının gelecekteki okuyucuyu yanıltıp yanıltmadığını kontrol edemez. Hiçbir formatlayıcı, hata mesajlarınızın kullanıcıyı aşağılayıp aşağılamadığını tespit edemez.

İşte bu yüzden empati, yazılım mühendisliğinde otomatize edilemeyen son beceridir. Ve belki de en önemli olanıdır. Çünkü sonuçta kodumuz, insanlar tarafından okunacak, insanlar tarafından değiştirilecek ve insanlar tarafından sürdürülecektir. Makineler sadece çalıştırır; anlam veren ve acı çeken bizleriz.

Türkiye'den uzaktan çalışarak yurt dışındaki şirketlere yazılım geliştirmek, son yılların en sessiz ama en büyük devrimlerinden biri oldu. Fiziksel olarak göç etmeden, dijital olarak göç ettik. Beyinlerimiz San Francisco'da çalışıyor, bedenlerimiz Kadıköy'de kahvaltı ediyor.

Döviz Kuru ve Kimlik Krizi

Dolar maaş almak, Türkiye'de yaşamanın ekonomik baskısını hafifletir. Bu tartışılmaz. Ama bu durum beraberinde kimse hakkında konuşmak istemediği bir kimlik krizini getirir.

Sabah 9'da San Francisco saati üzerinden daily standup toplantısına katılıyorsunuz. Ekibinizdeki herkes "weekend'de Lake Tahoe'ya gittik" derken siz "Bu hafta sonu Kadıköy sahilinde yürüdüm" diyorsunuz. Maaşınız aynı, yaşadığınız deneyim tamamen farklı. Bir süre sonra ne tam olarak Amerikan çalışma kültürüne aitsiniz ne de Türk çalışma kültürüne. İkisinin arasında, dijital bir limbo'da asılı kalıyorsunuz.

Arkadaşlarınızla buluştuğunuzda ise tersinden bir uyumsuzluk yaşıyorsunuz. TL maaş alan arkadaşlarınız market fiyatlarından şikâyet ederken siz sessiz kalıyorsunuz. Çünkü aynı markete gittiğinizde dolar bazında düşününce fiyatlar size "ucuz" geliyordur. Bu sessizlik, bir suçluluk duygusuna dönüşür. Kazandığınız parayla gurur duymanız gerekirken, kendinizi çevrenizden kopmuş hissediyorsunuz.

Saat Dilimleri ve Yalnızlık

Uzaktan çalışmanın en romantize edilen yanı "özgürlüktür". İstediğiniz yerden çalışabilirsiniz! Ama kimse saat dilimlerinin yarattığı sosyal izolasyonu anlatmaz.

ABD'deki bir şirket için çalışıyorsanız, gününüz Türkiye saatiyle öğleden sonra 3'te başlar ve gece 12'de biter. Bu, arkadaşlarınızla akşam yemeğine çıkamayacağınız, eşinizle birlikte film izleyemeyeceğiniz ve çocuğunuzu yatırmadan önce bir "küçük meeting" daha katılmanız gerektiği anlamına gelir.

Avrupa'daki bir şirket biraz daha insaflıdır ama onlarda da toplantılar genellikle Türkiye saatiyle öğle arasına denk gelir. Tam yemeğe oturacakken Zoom açılır, soğuyan çorbaya bakarak İngilizcenize odaklanırsınız.

Dijital Göç: Gitmeden Gitmek

Fiziksel beyin göçü zaten Türkiye'nin en büyük kanamalarından biri. Ama dijital göç çok daha sinsi bir fenomen. Çünkü kişi ülkeden ayrılmıyor, vergi veriyor, kirasını ödüyor, marketten alışveriş yapıyor. Ama zihinsel olarak artık burada değil. Günün 8-10 saatini farklı bir ülkenin problemlerini çözerek, farklı bir dilde düşünerek ve farklı bir kültürün normlarına uyarak geçiriyor.

Bu, bir tür "yarı göç" durumudur. Ne tam olarak gitmiştir ne de tam olarak kalmıştır. Pasaportunuz Türk ama iş beyniniz Amerikan. Patronunuz Seattle'da ama komşunuz Bağdat Caddesi'nde. Bu ikili yaşam bir süre sonra yıpratıcı olur çünkü hiçbir yere tam olarak ait hissedemezsiniz.

Peki Neden Kalıyoruz?

Bu kadar çelişkiye rağmen çoğu dijital göçebe Türkiye'de kalmaya devam ediyor. Sebepleri tamamen rasyonel olmayabilir: Aile bağları, arkadaş çevresi, İstanbul'un o kaotik ama bağımlılık yapan enerjisi, sabah çay içerken Boğaz'ı seyretmenin verdiği o tarif edilemez huzur.

Ve belki de en önemlisi: Türkiye'de yazılım geliştirici olmak, dünyada başka hiçbir yerde olmayan bir perspektif kazandırır. Hem gelişmekte olan bir ülkenin gerçekliklerini anlarsınız hem de gelişmiş ülkelerin teknoloji ekosistemini içeriden görürsünüz. Bu çift yönlü bakış açısı, sizi çoğu mühendisten farklı kılar.

Sonuçta dolar kazanıp TL harcamak sadece bir döviz arbitrajı değildir. Aynı anda iki farklı dünyada var olmanın, ikisinin de güzelliklerinden beslenenip ikisinin de çelişkilerini taşımanın adıdır. Ve bu deneyim, tıpkı iyi yazılmış bir kod gibi, dışarıdan basit görünür ama içinde katmanlar dolusu karmaşıklık barındırır.

Git, teoride kaynak kodu versiyonlamak (version control) için tasarlanmış harika bir araçtır. Ancak pratikte, yazılımcıların sessiz çığlıklarını, çaresizliklerini ve anlık aydınlanmalarını kaydettikleri devasa bir dijital günlük işlevi görür.

Commit Mesajlarının Psikolojik Evrimi

Bir projenin başlangıç evresi her zaman umut doludur. İlk haftalardaki commit mesajları o kadar temiz, o kadar profesyoneldir ki bir şiir kitabı gibi okunabilir:

• feat: kullanıcı giriş modülü eklendi
• refactor: veritabanı bağlantı havuzu optimize edildi
• docs: README dosyası güncellendi

Bu mesajları yazan kişi, 8 saatlik sağlıklı uykusunu almış, sabah kahvesini içmiş ve hayatından memnun bir geliştiricidir. Her şey kuralına uygundur. Linter hataları çözülmüş, kod formatlanmıştır.

Fakat proje yavaş yavaş canlıya (production) yaklaşmaya başladığında, o kusursuz profesyonellik yerini ufak bir telaşa bırakır:

• fix: login butonu ara sıra çalışmıyor düzelttim
• chore: gereksiz consol.log'lar silindi
• WIP: henüz bitmedi ama kodu alıyorum

Artık geliştiricimiz ufak tefek pürüzlerle karşılaşmaktadır. Ürün yöneticisinin (Product Manager) ensesinde hissettiği nefesi, commit mesajlarındaki o hafif gerginliği hissettirmeye başlar.

Gece 03:00 Cinnetleri

Gerçek travma ise canlı ortama geçişin (deployment) hemen öncesinde, Cuma gecesi saat 02:45'te atılan o acil durum commitlerinde gizlidir. Bu evrede artık geleneksel yazılım kuralları (SemVer, Conventional Commits) tamamen çökmüş, insan doğasının en ham, en çaresiz hali klavyeye yansımıştır:

• fix: abi neden calismiyor localde calisiyordu
• test: ulan cache yuzundenmis 4 saattir ariyorum
• asdasdsadsa
• YETER CALIS ARTIK LUTFEN
• fix: son_duzeltme_gercekten_son_v4_final

Eğer bir projenin geçmişinde üst üste 15 tane "asdasdsadsa" mesajı görüyorsanız, o satırlarda sadece kod değişikliği yoktur. O satırlarda, ocağın üstünde unutulmuş bir çay, iptal edilmiş bir sinema bileti ve sinirden kemirilmiş tırnaklar vardır.

Kodu Okumak vs İnsanı Okumak

Yeni bir projeyi devraldığımda her zaman git log --oneline komutunu çalıştırır ve ekibin geçmişine bakarım. Eğer tüm proje başından sonuna kadar kusursuz, kitabi mesajlarla doluyorsa, o projede gerçek bir tutku olmadığını bilirim.

Çünkü kod hata verir. Sistemler çöker. Ve eğer o sistemleri yazan insanlar bu çöküşlere tamamen duygusuz, robotik bir şekilde tepki veriyorsa, ortada bir gariplik vardır. Gerçek yazılımcıların klavyesine arada sırada kan, ter ve gözyaşı damlar. Ve bu damlalar, versiyon kontrol sistemimizin bir köşesinde sonsuza dek saklanır.

Bir dahaki sefere koda bakarken sadece algoritmaları değil, o algoritmaları yazan insanın saat 03:00'teki o çaresiz yalnızlığını da görmeye çalışın. Çünkü kodumuz, bizim en dürüst aynamızdır.

Bu kavram acil tıp dünyasının her köşesine işlemiştir. Ambulans çağrısından hastanın ameliyathaneye alınmasına kadar geçen süreçteki her bir saniye optimize edilmiş, protokolleştirilmiş ve ölçümlenmiştir. Çünkü acil tıp, zamanın bir kaynak değil, bir silah olduğunu anlamıştır.

Peki yazılım dünyası?

Sunucu Odasındaki Altın Saat

Büyük bir e-ticaret platformunu düşünün. Black Friday gecesi saat 21:00'de ana veritabanı sunucusu yanıt vermeyi durduruyor. Bu an, dijital dünyanın travma anıdır.

İlk 5 dakika içinde yapılan müdahale, şirketin o geceyi gelir kaybıyla mı yoksa itibar kaybıyla mı kapayacağını belirler. İtibar kaybı, gelir kaybından çok daha ağır bir yaradır çünkü iyileşmesi aylar alır.

Ancak çoğu yazılım ekibinin bir "Altın Saat" protokolü yoktur. Alarm çaldığında ne olur? Nöbetçi mühendis telefonunu açar. Belki açmaz çünkü sessiz moddadır. Slack'e bir mesaj atılır. 15 dakika sonra biri yanıt verir. VPN bağlantısı kurmaya çalışır. Şifresini hatırlayamaz. IT'ye bilet açar.

Bu arada sunucu hâlâ yerde yatmaktadır. Ambulansın anahtarı kaybolmuş gibidir.

MIST ve SBAR: Acil Tıptan Ödünç Alınacak Protokoller

Acil tıpta bir paramedik hastaneye hasta teslim ederken, o kaotik ortamda bile yapılandırılmış bir iletişim protokolü kullanır. En yaygınlarından biri MIST formatıdır:

• Mechanism (Mekanizma): Ne oldu?
• Injuries (Yaralanmalar): Neler hasar gördü?
• Signs (Belirtiler): Hayati bulgular neler?
• Treatment (Tedavi): Şimdiye kadar ne yapıldı?

Bu format, kritik bilginin saniyeler içinde, eksiksiz ve anlaşılır bir şekilde aktarılmasını sağlar. Bir paramedik asla "Şey, hasta biraz kötü görünüyordu, bir şeyler yaptık, tam hatırlamıyorum" demez.

Yazılım dünyasında ise olay müdahalesi (incident response) genellikle şöyle başlar: "Bir şeyler bozuldu galiba. Birisi bakabilir mi?" Bu mesajda ne bozuldu, ne zaman bozuldu, kimleri etkiledi, hangi servisler çalışmıyor gibi kritik bilgilerin hiçbiri yoktur.

Eğer MIST formatını yazılıma uyarlasaydık şöyle görünürdü:

• Mekanizma: Son deploy'dan 3 dakika sonra başladı.
• Hasar: Ödeme servisi yanıt vermiyor, kullanıcılar checkout yapamıyor.
• Belirtiler: CPU %100, veritabanı bağlantı havuzu tükenmiş, hata oranı %78.
• Yapılanlar: Son deploy geri alındı, etki devam ediyor.

Bu kadar net, bu kadar yapılandırılmış bir ilk mesaj, ekibin müdahale süresini dakikalardan saniyelere indirebilir.

"Scoop and Run" vs "Stay and Play"

Acil tıpta iki temel müdahale felsefesi vardır. "Scoop and Run" (Kap ve Koş): Hastayı minimum müdahaleyle en hızlı şekilde hastaneye taşı. "Stay and Play" (Kal ve Müdahale Et): Sahada kapsamlı müdahale yap, hastayı stabilize et, sonra taşı.

Hangi yaklaşımın seçileceği hastanın durumuna ve mevcut kaynaklara bağlıdır. İç kanama geçiren birini sahada ameliyat edemezsiniz, onu en yakın travma merkezine yetiştirmeniz gerekir. Ama solunum yolu tıkanmış birini stabilize etmeden taşırsanız yolda kaybedersiniz.

Yazılım krizlerinde de aynı karar verilmelidir. Veritabanı tamamen çökmüşse ve elimizde yedek (backup) varsa, sorunu sahada (production) çözmeye çalışmak yerine hızlıca yedekten geri dönmek (Scoop and Run) daha mantıklı olabilir. Ancak sorun bir bellek sızıntısıysa (memory leak) ve sistemi yeniden başlatmak geçici bir çözümse, kök nedeni bulana kadar sahada kalmak (Stay and Play) gerekir.

Sorun şu ki, çoğu yazılım ekibi bu ayrımı yapacak deneyime ve soğukkanlılığa sahip değildir. Ya her şeyi sahada çözmeye çalışarak altın saati tüketirler, ya da her şeyi geri alarak asıl sorunu hiç çözmezler ve aynı kriz bir hafta sonra tekrar eder.

Tıpkı acil tıpta olduğu gibi yazılımda da altın saatin farkında olmak, o saati nasıl kullanacağınızı bilmek ve en önemlisi o saat dolmadan harekete geçmek; işte projenizin yaşaması ile ölmesi arasındaki fark budur.

Peki ne oldu da yılların tecrübesi, sabahlara kadar süren debug seansları, yanlış verilen mimari kararların bedelini aylar süren refactorlerle ödeme acısı bir anda "iki tane React projesi ayağa kaldırmak" ile eşdeğer hale geldi?

10 Bin Saat Kuralı vs. 10 Bin Satır Kod

Malcolm Gladwell'in meşhur 10 bin saat kuralı yazılım dünyasında fena halde yanlış anlaşıldı. İnsanlar 10 bin saat boyunca aynı basit CRUD (Create, Read, Update, Delete) işlemini yaptıklarında ustalaştıklarını zannediyorlar. Oysa bir işi 10 bin saat yapmak sizi o işin uzmanı yapmaz; sizi sadece o rutinin kölesi yapar. Gerçek ustalık, o 10 bin saatin içinde kaç farklı krizle yüzleştiğiniz, kaç tane yıkılmış mimariyi ayağa kaldırdığınız ve en önemlisi kaç kez "Bunu böyle yapmamalıyız" diyebildiğinizle ölçülür.

Günümüz start-up kültüründe "Senior" kelimesi artık bir yetkinlik belirtisi değil, bir elde tutma (retention) stratejisi. Şirketler, çalışanlarına hak ettikleri maaş zamlarını veremediklerinde onlara bol keseden unvan dağıtmaya başladılar. "Maaşına %10 zam yapabiliyoruz ama seni Senior yapıyoruz!" Bu cümlenin sektördeki karşılığı aslında şudur: "Sana daha fazla para veremiyoruz ama egonu okşayabiliriz."

Framework Bağımlılığı ve Mühendislik Kaybı

Bugün "Senior" olarak işe alınan pek çok kişi, aslında sadece belirli bir çerçevenin (framework) yetenekli bir kullanıcısıdır. Next.js'in son sürümündeki tüm özellikleri ezbere bilebilirler, ancak işin temeline indiklerinde, tarayıcının belleği nasıl yönettiği veya sunucu tarafındaki bir TCP darboğazının uygulamanın geri kalanını nasıl felç edeceği konusunda hiçbir fikirleri yoktur.

Bir çerçevenin kurallarını ezberlemek sizi o çerçevenin Senior'ı yapabilir, ancak bu sizi Senior bir Mühendis yapmaz. Mühendislik, elinizdeki çekiçle her şeyi çivi olarak görmek değil, o çekicin hangi metallerle dövüldüğünü, sapının hangi ağaçtan yapıldığını ve o çekicin kullanılmaması gereken yerleri bilmektir.

Gerçek Senior'ı Nasıl Tanırız?

Peki, unvanların içinin bu kadar boşaldığı bir ekosistemde masanın karşısında oturan kişinin gerçekten "Senior" olduğunu nasıl anlarız?

1. "Hayır" diyebilme yetisi: Gerçek bir Senior, ürün yöneticisi mantıksız bir taleple geldiğinde sadece kafasını sallayıp kodu yazan kişi değildir. O özelliğin neden yapılmaması gerektiğini, uzun vadede teknik borcu (technical debt) nasıl artıracağını verilerle açıklayabilen kişidir.
2. Kriz anındaki nabız: Production (canlı ortam) çöktüğünde elleri titreyerek Stack Overflow'da çözüm arayan kişi henüz yolun başındadır. Gerçek Senior, logları sükunetle okuyan, sorunun kök nedenine odaklanan ve ekibin geri kalanını paniğe sürüklemeden süreci yöneten kişidir.
3. Kod silme sevgisi: Junior'lar kod yazmaktan keyif alır, Mid-level'lar karmaşık algoritmalar kurmaktan... Senior'lar ise kod silmekten keyif alır. En iyi kod, hiç yazılmamış koddur prensibini iliklerine kadar hissetmişlerdir.
4. Teknoloji agnostikliği: "React mı Vue mu?" tartışmasına giren bir Senior göremezsiniz. Çünkü onun için ikisi de günün sonunda JavaScript'e dönüşen ve beş yıl sonra muhtemelen yerini başka bir şeye bırakacak olan geçici araçlardır. O, aracın kendisine değil, çözdüğü probleme odaklanır.

Sonuç olarak, ismimizin başındaki unvanlar bizim kim olduğumuzu belirlemez. Kodumuz çöktüğünde Google'da sadece hatanın mesajını değil, o hatanın arkasındaki mimari kusuru da arıyorsak; yazdığımız kodun bir hafta sonraki teslim tarihini değil, iki yıl sonra o kodu okuyacak olan yeni mezun geliştiriciyi düşünebiliyorsak... İşte o zaman, kartvizitimizde ne yazdığının hiçbir önemi kalmaz. Tebrikler, artık unvanınızın değil, deneyiminizin bir anlamı var.

Ambulans çantası (Jump Bag) mimarisi acımasızca pragmatiktir. İçine sadece ve sadece hayat kurtaracak ekipmanlar konur: Hava yolu açma araçları, turnike, defibrilatör, temel ilaçlar. Hiçbir paramedik "Belki MR çekmemiz gerekir" diyerek sırtına portatif bir MR cihazı bağlamaz. Hiçbir paramedik "Ya hastanın diş ağrısı da varsa?" diyerek çantasına diş dolgu seti koymaz.

Çünkü acil tıpta herkesin kanına işlemiş bir prensip vardır: Hayatta tutmak için en az malzemeyle en fazla etkiyi yaratmak. Fazlası sizi yavaşlatır, yavaşlık ise ölüm demektir.

Yazılım Dünyasının Şişirilmiş Çantaları

Şimdi bu prensibi yazılım dünyasına taşıyalım. Yeni bir projeye başlıyorsunuz. Henüz tek bir kullanıcınız bile yok. Ama ilk hafta toplantısında ekibin aldığı kararlar şöyle bir şey oluyor:

• "Veritabanı olarak PostgreSQL kullanalım ama ileride NoSQL'e geçebiliriz, o yüzden bir de MongoDB kuralım."
• "Mesaj kuyruğu olarak Kafka entegre edelim, ileride binlerce event işlememiz gerekebilir."
• "Kubernetes üzerinde çalışalım çünkü ölçeklenmemiz gerekecek."
• "Mikroservis mimarisine geçelim, monolitik yapıda kalırsak ileride sıkışırız."

Henüz ortada tek bir kullanıcı yokken, Netflix'in altyapısını kurmaya çalışıyorsunuz. Bu, kalbi duran bir hastaya müdahale etmeden önce hastane bilgi yönetim sisteminin hangi bulut sağlayıcısında çalışacağını tartışmak gibidir.

Yazılım mühendisliğinde bu hastalığın bir adı var: YAGNI — You Aren't Gonna Need It (İhtiyacın Olmayacak). Kent Beck ve Ron Jeffries'in Aşırı Programlama (Extreme Programming) felsefesinden doğan bu prensip, şunu söyler: "Bir özelliği, gerçekten ihtiyacınız olduğu ana kadar eklemeyin."

"Ya Lazım Olursa?" Sendromu

Peki neden bu kadar basit bir prensibi kimse uygulamıyor? Çünkü yazılımcıların en büyük korkusu, gelecekteki bir ihtiyaç karşısında hazırlıksız yakalanmaktır. "Ya ileride lazım olursa?" sorusu, yazılım dünyasının en pahalı dört kelimesidir.

Acil tıpta da bu korkuyu yaşarsınız. "Ya hastanın alerjisi varsa ve elimde doğru ilaç yoksa?" Bu düşünce sizi çantanıza 200 farklı ilaç koymaya iter. Ama tecrübeli bir paramedik bilir ki, sahadaki vakaların yüzde doksanını beş temel ilaçla yönetebilirsiniz. Geri kalan yüzde onu ise zaten çantanıza koyacağınız hiçbir şey kurtaramaz; o vakalar hastane müdahalesine ihtiyaç duyar.

Yazılımda da durum aynıdır. Projenizin yüzde doksanını basit bir monolitik yapı, tek bir ilişkisel veritabanı ve iyi yazılmış bir REST API ile çözebilirsiniz. O "ileride lazım olabilecek" Kafka kuyruğu, o Kubernetes kümesi, o event-driven mimari... Bunlar, projenizin gerçekten o ölçeğe ulaştığı gün eklenebilir. Ama o gün gelmeden eklediğinizde, çantanız o kadar ağırlaşır ki beşinci kata çıkamadan merdivende kalırsınız.

Hafif Çanta, Hızlı Müdahale

Acil tıpta hayat kurtaran şey teknolojinin ne kadar gelişmiş olduğu değil, müdahalenin ne kadar hızlı yapıldığıdır. Dünyanın en pahalı defibrilatörü bile hastanın yanına zamanında ulaşamıyorsa bir plastik parçasından farksızdır.

Yazılımda da aynı mantık geçerlidir. Ürününüzü kullanıcıya ne kadar hızlı ulaştırabildiğiniz (Time to Market), altyapınızın ne kadar "enterprise-grade" olduğundan çok daha önemlidir. Mükemmel mimariyi kurana kadar rakibiniz basit bir monolitle pazara girmiş, kullanıcı geri bildirimi toplamış ve ürününü beş kez pivot etmiş olabilir. Siz ise hâlâ Kubernetes pod'larınızın neden çöktüğünü debug ediyorsunuzdur.

Bir dahaki sefere yeni bir projeye başlarken kendinize sorun: "Eğer bu bir ambulans çantası olsaydı, içine ne koyardım?" Cevabınız muhtemelen şu olacak: Çalışan bir veritabanı, temiz bir API, basit bir dağıtım (deployment) süreci. Gerisi, hasta gerçekten geldiğinde düşünülecek detaylardır.

Çünkü hayatta kalmanın sırrı, en çok ekipmana sahip olmak değil, en doğru ekipmanı en hızlı şekilde kullanabilmektir.

Sorunları böl, parçala ve yönet... Kulağa muazzam bir mühendislik zaferi gibi geliyor değil mi? Ancak gerçekte olan şey, sorunları bölmemiz ve onları yönetecek 15 farklı DevOps aracına, 3 farklı bulut sağlayıcısına ve kimsenin tam olarak nasıl çalıştığını anlamadığı bir service mesh ağına muhtaç kalmamız oldu.

Babil Kulesi'nin Dijital İnşası

Eski Ahit'te Babil Kulesi efsanesi, insanoğlunun kibri yüzünden cezalandırılmasını anlatır. Tanrı, gökyüzüne ulaşmaya çalışan bu kuleyi inşa edenlerin dillerini karıştırır. İnsanlar birbirlerini anlayamadıkları için kule hiçbir zaman tamamlanamaz ve yıkılır.

Bugün modern yazılım mimarilerinde kendi Babil Kulemizi inşa ediyoruz. Sistemimizi 40 farklı küçük servise böldüğümüzde, hepsi kendi veritabanına sahip olduğunda ve hepsi farklı dillerde (biri Go, diğeri Rust, bir diğeri Node.js) yazıldığında tam olarak efsanedeki o laneti yaşıyoruz. Servisler birbirleriyle HTTP üzerinden konuşmaya çalışıyor, ancak araya giren ağ (network) gecikmeleri, zaman aşımı (timeout) sorunları ve çöken RabbitMQ kuyrukları yüzünden iletişim sürekli kopuyor.

İki fonksiyonun bir monolitik yapıda (monolith) birbiriyle hafıza (RAM) üzerinden 0.001 milisaniyede konuşabildiği bir problemi, mikroservisler dünyasında çözmek için Kafka, Redis, gRPC ve bolca umut kullanmak zorunda kalıyoruz.

Özgürlüğün Bedeli: Karmaşıklık

Mikroservis mimarisinin bize vaat ettiği en büyük yalan "bağımsızlıktır". Ekipler birbirinden bağımsız kod dağıtımı (deploy) yapabilecektir. Fakat bu bağımsızlığın bedeli öylesine ağırdır ki, kimse bu bedeli ödemeye hazır değildir.

Eskiden uygulamanızda bir hata (bug) olduğunda tek bir log dosyasına bakardınız. Şimdi? Kullanıcının bir butona tıklaması arka planda 8 farklı servisi tetikliyor. Hatanın nerede olduğunu bulmak için, Dağıtık İzleme (Distributed Tracing) araçlarının içinde dedektifçilik oynamanız gerekiyor.

Daha da kötüsü, veritabanlarını ayırdığımız için eskiden tek bir SQL satırıyla (JOIN) hallettiğimiz raporlama işlemleri, artık devasa bir Veri Ambarı (Data Warehouse) mühendisliği problemine dönüşmüş durumda.

Ne Zaman Kullanmalı?

Mikroservisler kötüdür demiyorum. Netflix, Uber veya Amazon ölçeğindeyseniz, binlerce mühendisiniz ve saniyede milyonlarca isteğiniz varsa bu kaçınılmaz bir zorunluluktur.

Ancak sorun şu ki, günlük 5.000 ziyaretçisi olan ve ekibinde sadece 4 geliştiricisi bulunan bir e-ticaret girişiminin Netflix mimarisini kopyalamaya çalışması bir mühendislik harikası değil, bir kibrin (hubris) tezahürüdür.

"Eğer sistemimiz büyürse hazır oluruz" bahanesiyle, hiç gelmeyecek olan o efsanevi trafik için sistemi ölümcül bir karmaşıklığa sürüklüyoruz. Oysa büyüme (scale) problemi yaşamak bir ayrıcalıktır. Çoğu şirket büyüme problemi yaşayacak kadar hayatta kalamaz; tam da bu aşırı mühendislik (over-engineering) yüzünden iflas ederler.

Bir dahaki sefere yeni bir projeye başlarken o modüler, sıkıcı ve yaşlı monolitik yapıyı tekrar düşünün. Belki de ihtiyacınız olan şey yeni bir servis eklemek değil, sisteminizin tek ve bütün bir dil konuşmasına izin vermektir. Babil kulesini yıkmanın zamanı geldi.

Peki bu kodlar gökten zembille mi iniyor? Şirkete gece yarısı gizlice sızan kötü niyetli hackerlar mı yazıyor bu spagetti yığınlarını? Elbette hayır. Legacy kod, bir zamanlar projeye büyük umutlarla katılmış, her sabah kahvesini alıp bilgisayarının başına heyecanla oturan, "Bu projeyi çok daha iyi bir mimariyle baştan yazabiliriz!" diyerek toplantılarda sunumlar yapan mühendisler tarafından yazıldı.

Peki ne oldu da o parlak mühendis, arkasında dokunulmaz bir kod bataklığı bırakarak şirketten ayrıldı? Cevap, son yılların popüler kavramı olan "Sessiz İstifa"nın (Quiet Quitting) ta kendisinde gizli.

Duygusal Kopuşun Anatomisi

Bir geliştiricinin projeye olan inancını yitirmesi bir günde olmaz. Yavaş yavaş, küçük darbelerle gerçekleşir.

Önce kod kalitesini artırmak için yazdığı testler, ürün yöneticisi tarafından "Şu an buna vaktimiz yok, hızlıca canlıya alalım" denilerek iptal edilir. Ardından, mimari bir hata yapıldığı ve bunun ileride başlarını ağrıtacağı uyarısı, "Şimdilik böyle idare edelim, sonra refactor ederiz (düzenleriz)" klişesiyle hasıraltı edilir. (Ve hepimiz o "sonra"nın hiçbir zaman gelmeyeceğini çok iyi biliriz.)

Birkaç ay sonra o mühendis, inandığı teknik doğrular ile şirketin bitmek bilmeyen feature (özellik) yetiştirme baskısı arasında sıkışır. Ve işte o an, bir psikolojik savunma mekanizması olarak duygusal kopuş yaşanır. Artık kodun kalitesi umurunda değildir. Yalnızca ona verilen Jira biletini (ticket) kapatmak ve mesai bitiminde bilgisayarını kapatmak ister.

İşte sessiz istifa tam olarak budur. Fiziksel olarak oradadır, kod yazıyordur ama ruhen projeyi terk etmiştir.

Legacy Kodun Doğuşu

Sessiz istifa evresine giren bir mühendis, artık kodun sürdürülebilirliği (maintainability) için savaşmaz. "Bunu buraya if bloğuyla eklesem çalışır mı? Çalışır. Tamam o zaman," der ve geçer. Dokümantasyon yazmayı bırakır. Değişken isimlerine özen göstermez. Çünkü o koda duyduğu saygı ve sevgi bitmiştir.

Hiçbir legacy kod kötü veya yeteneksiz bir mühendis tarafından yazılmaz. Aksine, umudunu kesmiş, teknik borcun altında ezilmiş ve yöneticilerine sesini duyuramamış bir mühendis tarafından yazılır. Legacy kod, yeteneksizliğin değil, iletişimsizliğin ve tükenmişliğin (burnout) dijital bir anıtıdır.

Çözüm Kodda Değil, Kültürde

Şirketler genellikle bu legacy kod yığınından kurtulmak için en kolay yolu seçerler: Kodu tamamen çöpe atıp, yeni baştan yazmak. Ancak aynı toksik şirket kültürü, aynı gerçekçi olmayan teslim tarihleri ve aynı baskı devam ettiği sürece, o "yepyeni ve temiz" kod tabanı da sadece 6 ay içinde yeni nesil bir legacy koda dönüşecektir.

Bir projedeki kodun kalitesi, o kodu yazan ekibin psikolojik sağlığının doğrudan bir yansımasıdır. Eğer kodunuz spagettiye dönüşmüşse, geliştiricilerinize daha fazla eğitim vermeden önce, onlara neden artık projenizi umursamadıklarını sorun. Çünkü kodu iyileştirmenin yolu linter kurallarını sıkılaştırmaktan değil, masanın diğer tarafında oturan insanın hevesini kırmamaktan geçer.

Yukarıdaki fonksiyonu inceleyin. İlk bakışta basit bir recursion (özyineleme) örneği. Bir fonksiyon, kendi görevlerini yerine getirdikten sonra kendini tekrar çağırıyor. Nefes al, ye, çalış, uyu, tekrarla. Sonsuza dek.

Ama bu fonksiyonda bir sorun var. **Base case yok.** Bu fonksiyon ne zaman duracağını bilmiyor. Durmak için bir koşul tanımlanmamış. Teoride sonsuza kadar çalışmalı. Pratikte ise çağrı yığını (call stack) dolacak ve sistem bir `Stack Overflow` hatası verecek.

İnsan hayatı da tam olarak böyle bir recursion'dır. Ve ölüm, bizim base case'imizdir.

### Stack Overflow: Sonluluğun Zarureti

Bilgisayar biliminde her recursion'ın bir base case'e ihtiyacı vardır. Bu, döngünün durma koşuludur. Base case olmadan recursion sonsuz bir döngüye girer ve sistem çöker. Bu, tasarım hatası değildir; fiziksel bir zorunluluktur. Hiçbir makine sonsuz hafızaya sahip değildir.

İnsan yaşamında ölüm de benzer bir zorunluluktur. Eğer insanlar ölümsüz olsaydı, yani yaşam fonksiyonumuzun base case'i olmasaydı ne olurdu? İlk bakışta harika görünür: sonsuz zaman, sonsuz deneyim, sonsuz öğrenme.

Ama biraz daha düşündüğünüzde, sonsuz zamanın aslında zamanı anlamsızlaştıracağını fark edersiniz. Bir şeyi "yarın" yapabilme lüksünüz sonsuza kadar uzadığında, o şeyi "bugün" yapmak için hiçbir motivasyonunuz kalmaz. Aciliyet duygusu yok olur. Ve aciliyet olmadan, anlam da buharlaşır.

Tıpkı bir deadline'ı olmayan bir yazılım projesinin asla bitmeyeceği gibi, sonu olmayan bir yaşam da asla gerçekten "yaşanmaz". Ölüm, hayata `deadline` (son teslim tarihi) koyar. Ve biz insanlar, ne kadar nefret etsek de, deadline'larla çalışırız.

### Fibonacci ve Doğanın Özyinelemesi

Doğa, recursion'ın en zarif derleyicisidir (compiler). Fibonacci dizisi — 1, 1, 2, 3, 5, 8, 13, 21... — bir özyineleme formülüdür. Her sayı, kendinden önceki iki sayının toplamıdır. Ve bu dizi, ayçiçeğinin spiral yapısında, deniz kabuklarının kıvrımlarında, galaksilerin kollarında, hatta insan kulağının iç yapısında karşımıza çıkar.

DNA replikasyonu bir recursion'dır: Hücre kendini kopyalar, kopya kendini kopyalar, sonsuza dek... ta ki organizma ölene kadar (base case). Evrim de bir recursion'dır: Bir tür kendini bir sonraki nesle aktarır, o nesil kendini aktarır, sonsuza dek... ta ki o tür soyunu tüketene kadar (base case: yok oluş).

Doğa, base case'in kaçınılmazlığını milyonlarca yıl önce kabul etmiş ve bunu bir felaket değil, bir tasarım prensibi olarak benimsemiştir. Ölüm, doğanın garbage collector'ıdır (çöp toplayıcı). Kullanılmayan kaynakları serbest bırakır ki yeni süreçler çalışabilsin.

### Tail Call Optimization: Verimli Yaşamak

Fonksiyonel programlamada "kuyruk çağrısı optimizasyonu" (tail call optimization) adında bir teknik vardır. Normal recursion'da her çağrı stack'e yeni bir katman ekler ve bu sonunda taşmaya yol açar. Ama eğer recursive çağrı fonksiyonun en son işlemi olarak yapılırsa, derleyici stack'e yeni katman eklemek yerine mevcut katmanı yeniden kullanabilir. Fonksiyon sonsuz kez çağrılabilir ama stack asla taşmaz.

Bu, verimli yaşamanın güzel bir metaforudur. Her gün yeni bir yük, yeni bir endişe, yeni bir pişmanlık biriktirmek yerine; günü yaşayıp, o günün yükünü bırakıp, ertesi güne temiz bir stack ile başlamak. Dünün hatalarını bugüne taşımamak. Stack'inizi şişirmemek.

Paramediklikte buna "nöbet teslimi" denir. Nöbetiniz bittiğinde, o gün yaşadığınız her vakayı — kurtardığınız hastaları da, kaybettiklerinizi de — bir sonraki ekibe "teslim" edersiniz. Ve evinize, boş bir stack ile dönersiniz. Bu, duygusal olarak kolay değildir ama hayatta kalmak için zorunludur.

### return;

Her güzel fonksiyonun bir return ifadesi vardır. Her güzel hayatın da bir sonu. Ve tıpkı iyi yazılmış bir recursive fonksiyon gibi, önemli olan sonsuz kez çalışmak değil, her çağrıda anlamlı bir iş yapmak ve doğru zamanda, zarif bir şekilde durmaktır.

function live(day) {
if (day > MAX_DAYS) return memories;

breathe();
love();
create();
sleep();

return live(day + 1);
}

Base case'iniz her ne olursa olsun, önemli olan her iterasyonda `memories` dizisine eklediğiniz değerlerdir. Sonsuza kadar çalışan ama hiçbir şey üretmeyen bir fonksiyon, doğru zamanda durup güzel bir sonuç döndüren fonksiyondan her zaman daha başarısızdır.

Ama makinenin arkasında oturan biz insanlar? Biz her gün, her satırda, her commit'te yalan söyleriz.

İsimlendirmenin Büyük Yalanı

Bir değişkene isReady adını verdiğinizde, o değişkenin gerçekten bir şeyin "hazır" olup olmadığını temsil ettiğini iddia ediyorsunuz. Ama gerçekte o boolean, üç farklı asenkron işlemin tamamlanıp tamamlanmadığını, bir API çağrısının başarılı olup olmadığını ve kullanıcının bir formu doldurup doldurmadığını aynı anda kontrol eden karmaşık bir mantığın ucuna iliştirdiğiniz basit bir bayrak (flag). "Hazır" kelimesi, bu karmaşıklığı gizlemek için kullandığımız güzel bir örtüdür.

Ya da bir fonksiyona calculateTotal diyorsunuz. "Toplam hesapla" — ne kadar masum, ne kadar temiz. Ama o fonksiyonun içini açtığınızda, toplamı hesaplamanın yanı sıra vergi oranını çektiğini, indirim kuponlarını uyguladığını, kargo ücretini eklediğini, veritabanına bir kayıt yazdığını ve analitik servise bir event gönderdiğini keşfediyorsunuz. Bu fonksiyon toplam hesaplamıyor; 14 farklı yan etki (side effect) tetikleyen ve adından tamamen bağımsız bir hayat süren küçük bir canavar.

Biz buna "kötü isimlendirme" diyoruz. Ama aslında bu, organize bir yalandır. Fonksiyonun adı, gelecekteki okuyucuya verdiğimiz bir sözdür ve biz o sözü tutmuyoruz.

Yorum Satırlarının Sahte Günlüğü

Kod yorumları (comments), teoride kodun "neden" böyle yazıldığını açıklar. Pratikte ise yazılım dünyasının en güvenilmez belgeleridir.

// Kullanıcı listesini güncelle
deleteAllUsers();

Bu yorum satırını yazan kişi yalan söylüyor. Ama bu yalan muhtemelen kasıtlı değil. Büyük ihtimalle bir zamanlar o fonksiyon gerçekten kullanıcı listesini güncelliyordu. Sonra gereksinimler değişti, fonksiyon silme işlemine dönüştürüldü ama yorumu güncellemeyi kimse akıl etmedi. Yorum orada kaldı, fosil gibi. Artık kodun ne yaptığını değil, bir zamanlar ne yapmak istediğimizi anlatıyor.

Her eski projede bu fosil yorumlardan yüzlercesini bulabilirsiniz. Bunlar, ekibin geçmişteki niyetlerinin ve bugünkü gerçekliğin arasındaki uçurumun sessiz tanıklarıdır.

"Geçici Çözüm" Efsanesi

Yazılım dünyasında söylenen en büyük yalan, muhtemelen şu iki kelimedir: "Geçici çözüm." (Temporary fix.)

Bir bug patlıyor, teslim tarihi yarın. "Şimdilik şöyle bir workaround koyalım, sonra düzgünce çözeriz" diyorsunuz. O "sonra" asla gelmez. O geçici çözüm, beş yıl sonra hâlâ production'da çalışıyordur. Üstüne yeni geçici çözümler eklenmiştir. Ve artık o kod parçası, kimsenin dokunmaya cesaret edemediği kutsal bir tapınağa dönüşmüştür. "Dokunma, çalışıyor" felsefesi, yazılımcıların en büyük kolektif yalanıdır.

Bir hastaya "Bu sargı geçici, yarın düzgün bir tedavi yapacağız" deyip o sargıyı beş yıl boyunca üstünde bırakmak tıpta malpraktistir (tıbbi hata). Yazılımda ise "pragmatizm" olarak ödüllendirilir.

Dürüst Kod Mümkün mü?

Belki de sorun, programlama dillerinin bizi dürüst olmaya zorlamak yerine yalan söylemeyi kolaylaştırmasıdır. Bir fonksiyona istediğiniz adı verebilirsiniz; derleyici (compiler) o adın doğruluğunu kontrol etmez. Tip sistemleri (type systems) verilerin şeklini kontrol eder ama anlamını kontrol edemez.

Tamamen dürüst bir kod tabanı muhtemelen imkânsızdır. Çünkü kod, insan düşüncesinin bir yansımasıdır ve insan düşüncesi doğası gereği eksik, önyargılı ve çelişkilidir. Ama en azından yalanlarımızın farkında olabiliriz. Her isReady yazdığımızda "Gerçekten neye hazır?" diye sorabilir, her calculateTotal yazdığımızda fonksiyonun gerçekten sadece toplam hesaplayıp hesaplamadığını kontrol edebiliriz.

Sonuçta, en tehlikeli yalan başkalarına söylediğimiz değil, kendimize söylediğimizdir. Ve bir kod tabanında kendimize söylediğimiz en büyük yalan şudur: "Bu kod, tam olarak isminin söylediği şeyi yapıyor."

Ancak bir mühendis olarak o ekibe katılıp işe başladığınızda karşılaştığınız manzara genellikle şöyledir: Her sabah 45 dakika süren ve kimsenin birbirini dinlemediği daily scrum toplantıları. Anlaşılmaz story point tahminleri. Haftalık bitmeyen planlama toplantıları, retro toplantıları, sprint inceleme toplantıları. Sürekli güncellenmesi gereken jira biletleri ve kod yazmaktan çok süreçleri yönetmekle ve hatta bazen süreçleri yönetmeyi yönetmekle geçen koca bir hafta.

Orijinal "Agile Manifesto" 2001 yılında 17 yazılımcı tarafından yazıldığında çok net ve basit bir felsefesi vardı: "Süreçler ve araçlardan ziyade, bireylere ve etkileşimlere değer verin. Kapsamlı dokümantasyondan ziyade, çalışan yazılıma değer verin."

Ne yazık ki bugün geldiğimiz noktada, o 17 yazılımcının yıktığı o ağır, bürokratik şirket kültürü; "agile koçu" ve "scrum master" gibi ünvanlarla arka kapıdan tekrar içeri sızdı. Agile, geliştiricilere özgürlük ve hız kazandıran bir felsefe olmaktan çıkıp, orta kademe yöneticilerin yazılımcıları her saniye takip edebildiği, performanslarını sözde metriklerle (bazı kaynaklarda velocity olarak geçer) ölçtüğü devasa bir kontrol mekanizmasına dönüştü.

Bir DevOps/SysOps mühendisi ve bir startup kurucusu olarak ekipleri yönetirken fark ettiğim en acı gerçek şuydu: Süreçlere, Jira'ya ve toplantılara ne kadar çok odaklanırsanız, asıl işten (ürün ve yeni özellikler geliştirmekten) o kadar uzaklaşıyorsunuz. Yazılımcılar kod yazmak, mimari tasarlamak ve sorun çözmek için oradadır; Jira kartlarını sağdan sola kaydırmak için değil.

Şimdiye kadar yönetim kadrosunda bulunduğum ekiplerin çoğunda bu karmaşayı çöpe atmaya çalıştım; bazılarında başardım da. Başarılı olduğum bu ekiplerde scrum yapmadık. Sadece yapılacak işler vardı. Kimin hangi işte olduğu belliydi. Bir problem varsa takım içi anlık iletişim (slack, microsoft teams vb. araçlarla) kuruluyordu. Kimse "Dün şunu yaptım, bugün bunu yapacağım, önümde şu engel var" demek için her sabah saat 10'da mecburi bir toplantıya girmiyordu. Güvenin olduğu yerde, mikro-yönetime ve niteliksiz, bir şey bilmeyen fazlalık mikro yöneticilere ihtiyaç yoktur.

Bir yazılım ekibinin hızını (velocity) ölçmek istiyorsanız, Jira'daki kapanan kart sayısına bakmayın. Ekibin yayına yani productiona ne kadar sıklıkla ve ne kadar az hatayla kod çıktığına bakın. Yazılımcılarınıza toplantısız, kesintisiz derin odaklanma gerçekleştirebilecekleri zaman aralıkları sunun. Bırakın sadece her dakika daha da derinleşerek işlerine ve yazmaları gereken koda odaklansınlar.

Agile ruhunu geri getirmenin tek yolu, o ağır kurumsal ve kasıntı "Agile" kelimesini mikro yöneticilerle beraber çöpe atmak ve sadece oturup çalışan yazılımlar üretmeye odaklanmaktır. Gerisi sadece boş ve anlamsız bir gürültü.

Ve siz orada, kuru silgi kokulu bir beyaz tahtanın karşısında, elinizde titreyen bir keçeli kalemle, hayatınızda production'da asla kullanmayacağınız bir algoritmayı sıfırdan yazmaya çalışırken düşünürsünüz: "Bu ne saçmalık?"

Teknoloji sektörünün mülakat sistemi tamamen ve geri dönülemez biçimde bozuktur. Google, Meta ve Amazon gibi büyük şirketlerin başlattığı bu "whiteboard algoritma mülakatı" trendi, tüm sektöre yayıldı. Artık 5 kişilik bir startup bile size "Bir linked list'i O(n) zamanda tersine çevirecek bir algoritma yazın" sorusu soruyor.

Sorun şu: Bu tarz sorular, bir insanın gerçek dünyada ne kadar iyi bir mühendis olduğunu ölçmez. Bu sorular, bir insanın LeetCode adlı web sitesinde ne kadar çok pratik yaptığını ölçer. Ve LeetCode pratiği ile gerçek mühendislik becerisi arasındaki korelasyon şaşırtıcı derecede düşüktür.

Gerçek dünyada, bir yazılım mühendisi ne yapar? Belirsiz gereksinimleri anlaşılır hale getirir. Mevcut bir kod tabanını (codebase) okuyup anlar. Ekip arkadaşlarıyla iletişim kurar. Teknik borcu (technical debt) yönetir. Veritabanı şemasını tasarlar. CI/CD pipeline'ı kurar. Log okur, debug yapar, monitoring kurar. Ve evet, bazen algoritma da yazar. Ama o algoritma, beyaz tahtada değil IDE'de yazılır; Stack Overflow ve dokümantasyona bakılarak yazılır; ve genellikle zaten bir kütüphane olarak mevcuttur.

Suku Tech'te birini işe alırken ben asla algoritma sorusu sormam. Bunun yerine adaya gerçek bir senaryo veririm: "İşte bir proje. Müşteri şunu istiyor. Bu teknoloji yığınını (tech stack) kullanıyoruz. Nasıl bir mimari kurarsın? Hangi trade-off'ları (ödünleşimleri) kabul edersin? İlk hafta neye odaklanırsın?" Bu sorular, o insanın gerçek dünyada nasıl düşündüğünü, nasıl karar verdiğini ve ekiple nasıl çalışacağını gösterir.

Mevcut mülakat sistemi, ezbere dayalı, stres altında performans ölçen ve gerçek dünya becerilerini tamamen görmezden gelen bir tiyatrodur. En kötü tarafı ise bu sistemin gerçekten yetenekli ama "LeetCode çalışmaya zamanı olmayan" (çünkü gerçek projeler üzerinde çalışıyorlardı) mühendisleri eleyip, gerçek proje deneyimi sıfır olan ama 500 LeetCode sorusu çözmüş adayları geçirmesidir. Sektör olarak bunu düzeltmemiz gerekiyor; yoksa en iyi mühendisler kapıda kalırken, en iyi ezberleyicileri işe almaya devam edeceğiz.

İşte buna "Dark Pattern" (Karanlık Kalıp) deniyor. Kullanıcıyı, farkında olmadan veya istemediği halde belirli bir eylemi yapmaya (veya yapmamaya) yönlendiren kasıtlı arayüz tasarımı hileleridir.

Bu kalıplar her yerde: E-ticaret sitelerinde sepetinize sessizce eklenen "kargo sigortası." Kayıt formlarında varsayılan olarak işaretli gelen "Bana reklam e-postası gönderin" onay kutusu. Çıkış yapmak istediğinizde "Hayır, fırsatları kaçırmak istiyorum" yazan utandırma (Confirmshaming) butonları. Cookie (çerez) izin panellerinde "Hepsini Kabul Et" butonu kocaman ve parlak iken "Reddet" seçeneği gizlenmiş ve ancak üç tıklama sonra ulaşılabilen bir alt menüde.

Bir yazılım mühendisi ve UX (Kullanıcı Deneyimi) hakkında düşünen bir kurucu olarak, bu kalıpları kodlamayı kesinlikle reddediyorum. Kariyerim boyunca birkaç kez müşterilerden "Kullanıcı iptal edemsin diye butonu sakla" veya "Çıkış yapmak isteyenlere üç tane daha popup göster" gibi istekler aldım. Her seferinde aynı cevabı verdim: "Bu etik değil ve ben bunu yapmıyorum."

Bu sadece bir ahlak meselesi değil, aynı zamanda uzun vadeli iş stratejisi açısından da aptalcadır. Kullanıcıyı hileyle tutmak kısa vadede sayıları şişirebilir ama o kullanıcı eninde sonunda gidecektir ve giderken arkanızdan asla iyi konuşmayacaktır. Güvenini kaybettiğiniz bir kullanıcıyı geri kazanmak, yenisini kazanmaktan on kat daha zordur.

İyi bir arayüz, kullanıcının istediği şeyi en az adımda, en net şekilde yapmasını sağlayan arayüzdür. Abonelik iptali tek tıkla olmalı. Kayıt formu sadece gerekli bilgileri istemeli. Çıkış butonu her zaman görünür olmalı. Kullanıcıya saygı duymak, onu manipüle etmekten her zaman daha karlıdır. Çünkü saygı sadakat üretir; manipülasyon ise nefret.

Benimki bir Cuma gecesi başladı. Müşterinin canlı (production) sisteminde, rastgele zamanlarda ve rastgele kullanıcılarda ortaya çıkan bir hataydı. Kullanıcıların yaklaşık %2'si, belirli bir sayfaya girdiğinde beyaz ekran (white screen of death) görüyordu. Geri kalan %98 ise hiçbir sorun yaşamıyordu. Hata mesajı (error log) ise son derece belirsizdi: "Cannot read property of undefined." Bu mesaj, JavaScript dünyasının "Bir yerlerde bir şeyler yanlış ama nerede olduğunu söylemeyeceğim" şeklindeki klasik işkencesiydi.

İlk refleksim her zaman olduğu gibi hatayı yerel ortamda (localhost) tekrar üretmeye çalışmak oldu. Saatler harcadım. Aynı sayfayı yüzlerce kez yeniledim, farklı tarayıcılar denedim, farklı kullanıcı hesaplarıyla girdim. Hiçbir şey. Bende çalışıyordu. Dünyanın en sinir bozucu cümlesi: "Works on my machine" (Bende çalışıyor).

Cumartesi sabahı, bu işe dedektif gibi yaklaşmam gerektiğine karar verdim. Suç mahallini (production loglarını) incelemeye başladım. Hatanın oluştuğu anları zaman damgalarıyla (timestamp) listeledim. Bir örüntü (pattern) arıyordum. Saatlerce log satırlarını okuduktan sonra ilk ipucunu yakaladım: Hata sadece belirli bir saat aralığında (gece 02:00 ile 04:00 arası) yoğunlaşıyordu. Bu saatler, sistemin arka plan görevlerinin (cron jobs) çalıştığı saatlerdi.

Soruşturma daralmaya başladı. Cron job'ları inceledim ve birinin gece 02:00'de veritabanındaki bazı önbellek (cache) tablolarını temizlediğini buldum. Bu temizlik sırasında, eğer bir kullanıcı tam o anda o sayfadaydaysa, sayfa arka planda silinen bir veriyi çağırıyordu ve "undefined" hatası alıyordu.

Pazar gecesi, yaklaşık 72 saatlik bir iz sürme maratonunun sonunda suçluyu buldum: Tek bir satırlık eksik bir null kontrolü (null check). Bir veri parçası silinmeden önce "Bu veriyi şu anda kullanan biri var mı?" diye kontrol edilmiyordu. Düzeltme tam 8 karakter sürdü: ?. (optional chaining operatörü). Üç gün boyunca beni uykusuz bırakan, saçlarımı yolduran, monitöre yumruk attırdığı o devasa sorunun çözümü, 8 karakterlik bir eklentiydi.

O 72 saat bana çok şey öğretti. Debugging, kod yazmaktan çok daha zor ve çok daha önemli bir beceridir. İyi bir debugger olmak, iyi bir dedektif olmaktır. Sabır gerektirir, sistematik düşünce gerektirir ve en önemlisi varsayımlarınızı (assumptions) sürekli sorgulamayı gerektirir. "Bu kısımda sorun olamaz" dediğiniz anda, genellikle sorun tam oradadır. Suçluyu asla küçümsemeyin; bazen en büyük cinayetleri en küçük silahlar işler.

Altı ay önce yazdığım bir kodu açtığımda o kodun ne yaptığını anlayamadığım anı çok net hatırlıyorum. Kendi yazdığım kod. Kendi kafamdan çıkan mantık. Ve karşımda, hiçbir yorum satırı (comment) olmayan, değişken isimleri anlamsız (x, temp, data2) olan ve neyi neden yaptığı hakkında tek bir ipucu bırakmadığım bir dosya duruyordu. O an kendime çok kızdım ve "Bu kodu yazan adam kim? Ah, benmişim" dediğim anı asla unutmayacağım.

O gün bir şeyi anladım: Dokümantasyon, başkaları için yazılmaz. Dokümantasyon, altı ay sonraki kendiniz için yazılır. O gelecekteki siz, bugünkü bağlamı (context), kararların arkasındaki nedenleri ve o kodun neden böyle yazıldığını tamamen unutmuş olacaktır. Ve o an, geçmişteki kendinizin bıraktığı o küçük not, o açıklama satırı, o README dosyası hayatınızı kurtaracaktır.

Bu yüzden ben dokümantasyona "aşk mektubu" diyorum. Gelecekteki kendinize veya sizden sonra o koda dokunacak olan ekip arkadaşınıza yazdığınız bir mektuptur: "Merhaba, bu kodu şu tarihte, şu nedenle yazdım. Burada X yerine Y kullanmamın sebebi şuydu. Eğer Z'yi değiştirmek istersen, dikkat et çünkü şu servis buna bağımlı."

İyi bir dokümantasyon neye benzer? "Ne" yazdığınızı değil, "neden" yazdığınızı anlatır. Kodun kendisi zaten "ne" yaptığını gösterir. Ama "neden" bu yaklaşımı seçtiğinizi, hangi alternatifleri deneyip elediğinizi ve hangi kısıtlamalar (constraints) altında bu kararı verdiğinizi sadece siz bilirsiniz. Ve bu bilgiyi yazmazsanız, sonsuza kadar kaybolur.

Suku Tech'te dokümantasyon yazmak bir lüks veya opsiyonel bir görev değil, kodun ayrılmaz bir parçasıdır. Pull Request (kod inceleme talebi) açarken, eğer ilgili dokümantasyon güncellenmemişse o PR reddedilir. Bu kuralı ekibe ilk koyduğumda herkes söylendi. "Ama zaman kaybı!" "Ama deadline'a yetişmemiz lazım!" Evet, dokümantasyon yazmak bugün 30 dakikanızı alır. Ama o 30 dakikayı yazmazsanız, altı ay sonra o kodu anlamaya çalışan birileri (veya kendiniz) 3 gün harcayacaktır.

Bir kod deposunun (repository) gerçek kalitesini anlamak istiyorsanız, koduna değil dokümantasyonuna bakın. İyi dokümante edilmiş bir proje, o projenin arkasında düşünen, önemseyen ve gelecekteki insanlara saygı duyan bir ekip olduğunun kanıtıdır. Kodunuz bir gün silinebilir, yeniden yazılabilir. Ama bıraktığınız notlar, bilgi ve bağlam kalıcıdır. Gelecekteki kendinize bugün bir aşk mektubu yazın.

Ve ben hâlâ, neredeyse her gün, "aslında hiçbir şey bilmiyorum ve bir gün herkes bunu anlayacak" diye düşünüyorum.

Buna psikolojide "Imposter Syndrome" (Sahtekar Sendromu) deniyor. İlk kez 1978 yılında psikologlar Pauline Clance ve Suzanne Imes tarafından tanımlanan bu sendrom, özellikle yüksek başarı gösteren bireylerde yaygındır. Başarılarınızı şansa, zamanlama, veya başkalarının size olan aşırı güvenine bağlarsınız. Kendi yetkinliğinize asla tam olarak inanamaz ve "gerçek" yüzünüzün bir gün ortaya çıkacağı korkusuyla yaşarsınız.

Teknoloji sektörü bu sendrom için mükemmel bir üreme ortamıdır. Çünkü bu sektörde bilmeniz gereken şeylerin listesi sonsuz, sürekli değişiyor ve herkes sosyal medyada sadece en parlak başarılarını paylaşıyor. Twitter'da (X) 22 yaşında YC'ye kabul edilmiş kurucuları, LinkedIn'de her hafta yeni bir sertifika paylaşan "süper" mühendisleri, GitHub'da binlerce yıldızlı açık kaynak projeler geliştiren dahileri görüyorsunuz. Ve kendi kendinize soruyorsunuz: "Ben neden onlar gibi değilim? Neden benim projelerim o kadar parlak değil?"

Cevap aslında basit ama kabul etmesi çok zor: Onlar da sizin gibi. Onlar da geceleri "Acaba yeterli miyim?" diye düşünüyor. Onlar da bazı sabahlar bilgisayarı açtığında "Bugün herkes benim aslında hiçbir şey bilmediğimi anlayacak" korkusu yaşıyor. Sadece bunu paylaşmıyorlar. Çünkü bu sektörde kırılganlık göstermek, zayıflık olarak algılanıyor.

Benim sendromum özellikle iki dünyamın kesiştiği noktalarda patlar. Yazılım konferanslarında, yanımdaki insanlar karmaşık sistem mimarileri tartışırken "Acaba benim bilgim yeterli mi?" diye içimden geçiririm. Acil tıp eğitimlerinde, diğer öğrenciler klinik vakaları tartışırken "Acaba ben gerçekten hayat kurtarabilecek yetkinlikte miyim?" diye sorguladığım anlar oldu.

Yıllar içinde bu sendromla tamamen barışamadım ama onunla yaşamayı öğrendim. Yapabildiğim en faydalı şey, o korkuyu bastırmak yerine onu bir motivasyon kaynağına dönüştürmek oldu. "Yeterli değilim" düşüncesi beni sürekli öğrenmeye, kendimi geliştirmeye ve asla yerinde saymamaya itiyor. Kibirli olmaktansa şüpheci olmayı tercih ederim. Çünkü kendini "yeterli" gören insan öğrenmeyi bırakır; kendini "yetersiz" hisseden insan ise hayat boyu öğrenci kalır.

Eğer siz de bu satırları okurken "Ben de böyle hissediyorum" diyorsanız, bilin ki yalnız değilsiniz. Dünyadaki en başarılı mühendisler, cerrahlar ve bilim insanları bile aynı şeyi yaşıyor. Sahtekar sendromu, aslında sahtekarların değil; işini gerçekten ciddiye alan, standartları yüksek ve dürüst insanların hastalığıdır. Gerçek sahtekarlar bu sendromu asla yaşamaz çünkü onlar zaten yeterli olduklarına koşulsuz inanırlar.

Bu projelerin her birinin bir başlangıç hikayesi vardır ve hepsi aynı şekilde başlar: Duş alırken, yürüyüş yaparken veya gece yatağa uzandığımda aklıma "muhteşem" bir fikir gelir. Heyecanlanırım. Hemen yataktan fırlar, terminali açar ve mkdir super-proje && cd super-proje && git init yazarım. İlk gece çılgınlar gibi kodlarım. İkinci gece de devam ederim. Üçüncü gece hızım düşer. Dördüncü gece "yarın devam ederim" derim. Ve o "yarın" asla gelmez.

Yıllarca kendimi bu döngü yüzünden suçladım. "Disiplinsizim", "Tembel", "Hiçbir şeyi bitiremiyorum" diye kendime kızdım. Ta ki bu kalıbın (pattern) arkasındaki psikolojiyi anlayana kadar.

Bir projenin en heyecanlı anı, başlangıcıdır. Boş bir dosyaya ilk satırı yazmak, mimariyi kafanızda kurmak, teknoloji yığınını (tech stack) seçmek... Bu aşama tamamen yaratıcılıktır ve beyniniz sizi dopaminle ödüllendirir. Ancak proje ilerledikçe, o parlak yaratıcılık aşaması yerini sıkıcı detaylara bırakır. Form validasyonları, hata yönetimi (error handling), responsive tasarım, edge case'ler, testler, deployment konfigürasyonları... İşin %20'si fikir ve mimaridir, %80'i ise o çekici olmayan, sıkıcı detaylardır. Ve beyniniz tam o %80'lik kısma girdiğinizde, size yeni ve çok daha parlak bir fikir fısıldar: "Bırak bunu, şu yeni projeye başlasak çok daha havalı olur!"

Bu, nörolojik olarak bir bağımlılık döngüsüdür. Yeni başlangıçların verdiği dopamin patlamasına bağımlı olursunuz ve hiçbir projenin "sıkıcı orta bölümünü" (messy middle) geçemezsiniz.

Bu döngüyü kırmayı öğrenmem yıllarımı aldı. Bugün uyguladığım kural şu: Aklıma yeni bir fikir geldiğinde hemen kodlamaya başlamıyorum. O fikri bir not defterine yazıyorum ve en az bir hafta bekliyorum. Eğer bir hafta sonra hâlâ o fikirle ilgili heyecan duyuyorsam, o zaman başlıyorum. Ve başladığımda, projenin kapsamını (scope) acımasızca küçültüyorum. "Bir müzik çalar" değil, "Sadece bir oynat/durdur butonu olan, tek bir MP3 dosyası çalan uygulama." Bitti. Deploy. Sonra iterasyon (iteration) ile büyütürüm.

Side project mezarlığı her yazılımcının ortak sırrıdır. Utanmayın, ama o mezarlıktan ders çıkarın. Bir projeyi bitirmek, on projeye başlamaktan her zaman daha değerlidir.

Geçen hafta ise oturdum, AI aracıma ne istediğimi üç cümleyle anlattım ve 15 saniye içinde o componenti bana yazdı. Çalışıyordu. Temizdi. Hatta bazı edge case'leri benim aklıma gelmeden önce kendisi halletmişti. Ben de ekrana baktım ve içimde çok garip, tarif etmesi zor bir boşluk hissettim.

O an kendime şu soruyu sordum: "Eğer bu makine benim yaptığım işi benden daha hızlı, daha ucuz ve bazen daha temiz yapabiliyorsa... Ben tam olarak ne iş yapıyorum?"

Bu soru, 2024'ten itibaren dünyadaki her yazılım mühendisinin kafasının içinde sessizce dönen ama çoğunun yüksek sesle sormaya cesaret edemediği bir varoluşsal krizdir. Çünkü bu soruyu sormak, yıllarca emek verdiğiniz, gece gündüz öğrendiğiniz ve kimliğinizin bir parçası haline getirdiğiniz mesleğinizin belki de birkaç yıl içinde tamamen farklı bir şeye dönüşeceğini kabul etmek anlamına gelir.

Uzun süre bu soruyla boğuştuktan sonra kendi cevabımı buldum ve o cevap beni rahatlattı. Şimdi paylaşayım.

AI, kod yazabilir. Evet. Hatta iyi kod yazabilir. Ancak AI, "neyin yazılması gerektiğine" karar veremez. Bir müşterinin belirsiz ve çelişkili isteklerini dinleyip, o kaosun içinden gerçek ihtiyacı süzüp çıkaramaz. "Bu özelliği şimdi yapmamalıyız, önce şu teknik borcu temizlemeliyiz" diyemez. Bir ekibin moralini okuyup, sprint kapsamını (scope) buna göre ayarlayamaz. Ürün stratejisi belirleyemez, mimari trade-off'ları (ödünleşimleri) tartamaz. Yani AI mükemmel bir tuğla ustasıdır ama mimar değildir.

Biz mühendisler, tuğla ören işçiler olarak başladık. Yıllarca elimizle satır satır kod yazdık ve bu bize o temeli verdi. Ancak mesleğimizin geleceği, tuğla örmekte değil; hangi binanın nereye, neden ve nasıl inşa edileceğine karar vermektedir. AI çağında ayakta kalacak mühendis, "en hızlı kod yazan" değil; "neyin kodlanmaması gerektiğini bilen", sistemi bütünsel gören ve insan ihtiyaçlarını teknik çözümlere çevirebilen mühendistir.

Yani hayır, işsiz kalmayacağız. Ama işimiz değişecek. Ve bu değişime direnenler değil, ona uyum sağlayanlar ayakta kalacak. Tıpkı hesap makinesinin icadından sonra matematikçilerin yok olmayıp, daha üst seviye problemlere odaklanması gibi. Biz de artık tuğla örmekten, şehir planlamaya terfi ediyoruz. Şikayet edecek bir şey yok aslında.

Uzun ve travmatik bir ambulans nöbetinin (genellikle 24 saat süren o uykusuz cehennemin) ardından eve dönüp üniformamı çıkardığımda, hissettiğim o derin zihinsel yorgunluğu atabilmek için meditasyon yapmazdım. Yaptığım şey bilgisayarımı açıp, karanlık, sessiz ve kelimenin tam anlamıyla "steril" olan siyah terminal (IDE) ekranıma bakmaktı.

Dışarıdaki o kanlı ve öngörülemez dünyadan sonra, kod yazmak bana her zaman dünyanın en güçlü terapisi gibi gelmiştir. Çünkü bilgisayar bilimi (Computer Science), biyolojinin tam zıttıdır. Bilgisayarın içinde şans eseri olan hiçbir şey yoktur. Eğer yazdığınız kod "A" değerini üretiyorsa, o kodu bir milyon kez de çalıştırsanız yine "A" değerini üretir. Karşınızda duyguları olmayan, paniklemeyen, size yalan söylemeyen ve sadece verdiğiniz komutları harfiyen uygulayan bir makine vardır.

O siyah ekran, kuralların çok net çizildiği, mantığın (logic) duygulara galip geldiği ve her sorunun mutlaka rasyonel bir çözümünün bulunduğu güvenli bir sığınaktır (Safe Haven). Dışarıdaki hayatta bir kazayı geri alamazsınız, dökülen kanı geri sokamazsınız. Ancak o terminalin içinde, evrenin tanrısı sizsinizdir. Kendi kurallarınızı yazar, kendi dünyanızı inşa eder, beğenmezseniz silip baştan yaparsınız.

Yıllar içinde fark ettim ki, aslında hayatımdaki bu iki zıt uç birbirini mükemmel bir şekilde dengeliyor. Sadece kod yazarak yaşasaydım, muhtemelen dünyanın o acımasız ve dağınık gerçekliğinden kopuk, fazla mekanik bir insan olacaktım. Sadece acil tıpta kalsaydım, o travmaların ağırlığı ve insanların bitmeyen kaosunda boğulup gidecektim.

Biri bana insan olmanın ne kadar kırılgan ve değerli olduğunu öğretti; diğeri ise o kırılganlıktan kaçıp zihnimi dinlendirebileceğim sessiz, steril ve düzenli bir liman sundu. Bugün bir sorunu çözerken, o karmaşanın içinde kaybolmamayı ve terminal ekranının o sessiz dinginliğinde çözüm üretmeyi, tam olarak bu iki dünyanın arasında kurduğum köprüye borçluyum.

Beş sekme açık olan bir yazılımcı, hayatını kontrol altına almış, Zen durumuna ulaşmış ve muhtemelen yakın zamanda tatilden dönmüş bir insandır. On sekme normal. Yirmi sekme, aktif bir proje üzerinde çalışıyordur. Kırk sekme, biraz stresli ama idare ediyor. Altmış sekme, deadline yaklaşıyor. Seksen sekme, artık hangi sekmenin hangi projeye ait olduğunu ayırt edemiyor. Yüz sekmenin üstünde, sekme başlıkları artık sadece favicon (site ikonu) olarak görünüyor çünkü yazı sığmıyor. Ve yüz elli sekmenin üzerindeyse... O insan ya bir dahi ya da yardıma ihtiyacı var. Genellikle ikincisi.

Bu durumu çok iyi tanıyorum çünkü kendim kronik bir sekme biriktiriciydim. Ve bunun arkasındaki psikolojiyi yıllar içinde çözdüm.

Her açık sekme, aslında beyninizdeki "bunu daha sonra oku", "buna daha sonra bak" veya "bunu unutma" diye ertelediğiniz bir görevin dijital manifestosudur. Bir Stack Overflow sorusu açıktır çünkü "belki lazım olur". Bir Medium makalesi açıktır çünkü "bunu okumalıyım ama şimdi değil". AWS dokümantasyonu açıktır çünkü "daha önce burada bir şey bulmuştum ama hatırlamıyorum neredeydi". YouTube'da bir konferans konuşması açıktır çünkü "bunu izleyeceğim bir gün". O gün asla gelmez ama sekmeyi kapatmaya da cesaretiniz yoktur. Çünkü o sekmeyi kapattığınız an, oradaki bilgiye bir daha asla ulaşamayacakmışsınız gibi bir kayıp hissi yaşarsınız.

Aslında bu bir karar verememe (decision paralysis) ve biriktirme (digital hoarding) sorununun tezahürüdür. Biz yazılımcılar, bilginin her gramının değerli olduğuna inanırız. Her makale, her Stack Overflow cevabı, her GitHub reposu potansiyel olarak gelecekte bir gün işimize yarayabilir. Ve bu "belki lazım olur" düşüncesi, tarayıcımızı da zihnimizi de tıkıyor.

Bir gün cesaret edip tüm sekmelerimi kapatmayı denedim. Hepsini. 127 sekme. "Bookmark'la" bile demedim, direkt kapattım. Kalp atışım hızlandı, bir anlık panik hissettim ama sonra öyle garip bir hafiflik çöktü ki... Sanki beynimin RAM'i (çalışma belleği) aniden boşalmış gibiydi. O an fark ettim ki, o 127 sekmenin her biri zihnimde bilinçaltı bir yük oluşturuyormuş. Her biri "beni unutma" diye bağıran küçük bir görevmiş.

Bugünkü kuralım çok basit: Eğer bir sekmeyi 24 saat içinde okumadıysam veya kullanmadıysam, o sekme benim hayatım için gerçekten önemli değildir. Kapanır ve dünya yıkılmaz. Eğer gerçekten lazım olursa, zaten Google onu tekrar bulacaktır. Tarayıcınızı temizleyin, zihninizi temizlemiş olursunuz. Ve eğer birisinin tarayıcısında 200'den fazla sekme açıksa, ona "Nasılsın?" diye sorun. Gerçekten sorun. Çünkü o insan iyi değil.

Suku Tech'i sıfırdan kurarken ilk karşılaştığım gerçek, döviz kurunun hayatınızı nasıl bir roller coaster'a çevirdiğiydi. Özellikle döviz kurunun sürekli olarak baskılandığı bir ortamda. Sunucularınız yurt dışında (Hetzner, DigitalOcean vb.) barınıyorsa, faturalarınız dolar veya euro cinsindendir. Elbette döviz cinsinden giderleriniz sadece sunucu maliyetlerinizle sınırlı olamaz. Kullandığınız üçüncü taraf bir yazılım, herhangi bir WAF servisi, nesne depolama alanı hizmeti, çalışmalarınız için kullandığınız bilgisayarınız, çalışma masanızın üstündeki çalışma lambanız ve daha fazlası. Müşterilerinizin bir kısmı Türkiye'deyse, gelirleriniz TL cinsindendir. Sabah uyandığınızda dolar sadece 2 lira dahi artmışsa, bir gecede tüm kar marjınız buharlaşmıştır. Maliyet planlaması yapmak neredeyse imkansızdır çünkü giderleriniz sabit dövizle, gelirleriniz ise sürekli değer kaybeden bir para birimiyle akmaktadır.

Bürokratik tarafı ise ayrı bir macera. Türkiye'de şirket kurmak, şirket büyütmek ve özellikle yurt dışına fatura kesmek, bir mühendislik problemi kadar karmaşıktır. Vergi dairesi, SGK, e-devlet, MERSIS, KEP adresi, e-fatura entegrasyonu... Her biri ayrı bir labirent. Ve bu labirentlerin hiçbirinin dokümantasyonu (tıpkı kötü yazılmış bir API gibi) düzgün değildir. Bir gün e-arşiv portala giriş yapamazsınız, bir gün e-devlet çöker, bir gün vergi dairesindeki memur size farklı ve tamamen yanlış bir şey söyler.

Yurt dışı müşterilerle çalışmak istediğinizde ise bambaşka bir algı sorunu çıkar karşınıza. Uluslararası piyasada "Türkiye'den bir teknoloji şirketi" olarak kendinizi tanıttığınızda, karşı tarafın kafasında oluşan ilk imaj maalesef Silikon Vadisi'ndeki bir startup değildir. Kendinizi kanıtlamanız, güven inşa etmeniz ve "Evet, biz de kaliteli iş üretiyoruz" demeniz için çok daha fazla emek harcamanız gerekir. Aynı işi yapan bir Amerikan veya Alman şirketinin varsayılan güvenilirliğine ulaşmak için iki kat daha çok çalışmanız gerekir.

Üstüne üstlük potansiyel müşterileriniz geçmişteki başarısız startupları sizlere göstererek bunlar beceremedi; siz nasıl bu işin içinden çıkacaksınız minvalinde patavatsız söylemlerde bulunabilirler. Peki neden hâlâ buradayım? Neden Estonya'ya veya İrlanda'ya taşınıp orada şirket kurmadım? Çünkü Türkiye'den iş yapmanın gizli bir avantajı var: Maliyet yapınız. Buradaki mühendislik kalitesi, Batı Avrupa veya ABD standartlarında ama maliyet çok daha düşüktür. Bu da size küresel piyasada rekabetçi fiyatlarla premium kalitede hizmet sunma imkanı verir. Ayrıca burada her gün savaşarak öğrendiğiniz o dayanıklılık (resilience), hiçbir MBA programının veremeyeceği bir girişimci eğitimidir.

Türkiye'den global bir teknoloji şirketi kurmak, düz bir otobanda araba sürmek değil; bozuk yolda, karanlıkta, farları yarım yanan bir kamyonla dağ geçidi aşmaktır. Ama o geçidi aştığınızda, düz otobanda başlayanlara kıyasla çok daha iyi bir sürücü olursunuz. Zorluklar sizi kırmadıysa, sizi piyasadaki en sert rakiplerden biri yapmıştır.

Ancak bir paramedik olarak, bu teknolojinin asla ve asla çözemeyeceği bir alan olduğunu biliyorum. Ve bu alan, tıbbın en temel ama en az konuşulan parçasıdır: Empati.

Bir gece nöbetinde, yaşlı bir kadının evine çağrıldık. Kadın yerde yatıyordu, düşmüştü ve kalça kemiğinde kırık şüphesi vardı. Tıbbi müdahale protokolü belliydi: Boyun stabilizasyonu, vakum yatak, damar yolu, ağrı kesici ve hastaneye sevk. Bir yapay zeka da bu protokolü kusursuz bir şekilde uygulayabilirdi. Belki benden daha hızlı ve hatasız uygulardı.

Ama o gece beni asıl zorlayan şey kırık kemik değildi. Kadının gözlerindeki o derin korkuydu. "Ölecek miyim?" diye sordu. Titreyen, kuru ve buruşmuş elini bana uzattı. Ben o eli tuttum, gözlerinin içine baktım ve "Hayır teyzeciğim, her şey iyi olacak, seni bırakmıyoruz" dedim. O an eli tutmanın, göz temasının, ses tonunun ve o basit cümlenin yarattığı etkiyi hiçbir algoritma, hiçbir dil modeli ve hiçbir robot kol taklit edemez.

Çünkü empati, veri işlemek değildir. Empati, karşınızdaki insanın acısını bir nebze olsun kendi bedeninizde hissetmektir. O hastanın elini tuttuğunuzda avucunuzdaki ıslak teri hissetmektir. Onun gözlerindeki korkunun, sizin kendi ölüm korkunuzu tetiklemesine izin vermektir. Bir yapay zeka "Korkma" diyebilir ama bunu söylerken kendisi korkmayı bilmez. Korkmayı bilmeyen bir varlığın "Korkma" demesinin, bir insanın ruhuna dokunma ihtimali sıfırdır.

Acil tıpta, özellikle ölüm ve ağır travma vakalarında, tıbbi müdahalenin yanı sıra "İnsani Varlık" (Human Presence) dediğimiz bir kavram vardır. Bazen yapabileceğiniz hiçbir tıbbi müdahale yoktur. Hasta gidiyordur ve siz bunu biliyorsunuzdur. O anda tek yapabileceğiniz, orada olmaktır. Sessizce yanında durmak, elini tutmak ve o insanın bu dünyadan yalnız gitmediğini hissettirmektir. Bu, hiçbir ders kitabında yazmayan ama sahadaki her paramedik ve hemşirenin bildiği en ağır ve en kutsal görevdir.

Bir robot kolun bu görevi yapabildiği günü hayal etmeye çalışıyorum ve yapamıyorum. Tıp, sadece beden tamirciliği değildir. Tıp, en temelinde bir insanın bir başka insana "Sen önemlisin ve ben buradayım" demesidir. Yapay zeka hastalıkları teşhis edebilir, ilaç dozlarını hesaplayabilir, ameliyat yapabilir. Ama bir insanın son anlarında yanında olup, onun hikayesine tanıklık etmeyi; işte bunu asla yapamaz. Çünkü bunun için önce bir hayat yaşamış olmak, acı çekmiş olmak ve ölümün ne demek olduğunu bilmek gerekir. Algoritmalar hesaplar; ama insanlar hisseder. Ve bazı şeyler sadece hissederek yapılabilir.

Bu pazarlama yalanı o kadar başarılı oldu ki, bugün 3 kişilik bir startup bile, günde 100 kişinin gireceği basit bir web sitesini barındırmak için devasa bulut mimarileri kuruyor. Load Balancer'lar, Serverless (Sunucusuz) Lambda fonksiyonları, yönetilen (Managed) Kubernetes kümeleri ve devasa bulut veritabanları... Her şey "ölçeklenebilir" (scalable) olmak zorunda ya hani?

Peki gerçek dünyada ne oluyor? O 3 kişilik startup, daha doğru düzgün para kazanamadan ay sonu gelen $3.500 dolarlık AWS faturasıyla şoka giriyor.

İşte buna sektörde "Cloud Lock-in" (Bulut Tuzağı) diyoruz. Bulut servis sağlayıcıları (Cloud Providers), ilk başta size binlerce dolarlık ücretsiz kredi verirler. Mimarinizi tamamen onlara özgü olan araçlarla (AWS DynamoDB, AWS SQS, Google Pub/Sub vb.) kurmanızı sağlarlar. Uygulamanız bu araçlara tamamen bağımlı hale gelir. Kredileriniz bittiğinde veya sitenizin trafiği gerçekten artmaya başladığında, o kolayca kullandığınız "Managed" servislerin veri transferi (Egress) ve okuma/yazma (Read/Write) ücretleri astronomik rakamlara ulaşır. Artık oradan çıkmanız da imkansızdır, çünkü kodunuz AWS'ye göre yazılmıştır, başka bir yere taşıyamazsınız.

Suku Tech'i yönetirken ve diğer şirketlere DevOps danışmanlığı verirken yaptığım en büyük işlerden biri, şirketleri bu fatura kâbusundan uyandırmak ve onları "Temellere" döndürmektir.

Gerçek şu ki: Şirketlerin %95'i Netflix veya Uber değil. Sizin saniyelik on binlerce isteği karşılayacak, global olarak dağıtılmış devasa bir serverless mimariye ihtiyacınız yok. İhtiyacınız olan şey, aylık maliyeti sabit olan, güçlü birkaç fiziksel (Bare-Metal) veya kiralık sunucu (Hetzner, OVH, DigitalOcean vb.) ve üzerine kurulmuş düzgün bir Docker mimarisidir.

Bugün aylık 100-200 dolara kiralayacağınız sağlam bir Dedicated Server (Özel Sunucu), AWS'de size binlerce dolara mal olacak bir performansı terlemeden verir. Veritabanınızı (PostgreSQL) kendi sunucunuzda tutmak, kuyruk sisteminizi (RabbitMQ/Redis) kendiniz yönetmek "çağdışı" değil; mühendisliktir. Maliyet optimizasyonudur.

Bulut sistemleri kötüdür demiyorum; esneklik gerektiğinde (black friday gibi ani trafik artışlarında) veya globale açılırken hayat kurtarır. Ancak bulut, bir başlangıç noktası (default) değil, bir ihtiyaç noktası olmalıdır. Sadece ay sonunda faturanın ne geleceğini bilememek bile, bir startup kurucusunun uykularını kaçırmaya yeter. Eğer altyapınızı bulutta tutuyorsanız ve faturanız sizi korkutuyorsa, belki de o "çağdışı" denilen fiziksel sunuculara geri dönmenin (Cloud Repatriation) vakti gelmiştir.

Ancak bir paramedik olarak sahaya çıktığınızda, ambulansın arkasında o siren sesleri eşliğinde bir vakaya giderken o "Geri Al" butonunun var olmadığını bilmek, insana hayatın ne kadar acımasız ve kırılgan olduğunu çok sert bir şekilde öğretir.

Acil tıpta hata yapmanın bedeli ekrana düşen kırmızı bir hata mesajı değildir; bir annenin çığlığı, bir ailenin kararan hayatı veya sedyede yatan birinin son nefesidir. İşin en zor ve psikolojik olarak en yıpratıcı kısmı ise şudur: Bazen hiçbir hata yapmazsınız. Bütün protokolleri harfiyen uygularsınız, ilacı saniyesi saniyesine doğru dozda verirsiniz, kalp masajını kusursuz bir ritimle yaparsınız... Ve hasta tüm çabanıza rağmen yine de hayata tutunamaz ve ölür.

Yazılımda bir kod çalışmıyorsa mutlaka mantıksal bir sebebi vardır. Noktalı virgülü unutmuşsunuzdur veya bir değişken tanımsızdır. Bulursunuz ve çözersiniz. Ancak insan bedeni ve ölüm, kodların o mantıksal dünyasına asla uymaz. Ölümün algoritması yoktur. Bazen bir insanı yaşatmak için elinizden gelen her şeyin %100'ünü yaparsınız ama o bedenin yaşam döngüsü bitmiştir. Ve o hastayı kaybettiğinizde, elinizdeki kanı yıkayıp bir sonraki vakaya gitmek zorundasınızdır.

Hayatımın bu iki zıt dünyasında yaşamak, "Başarısızlık" (Failure) kavramına olan bakışımı tamamen değiştirdi. Eskiden kod yazarken veya bir projeyi hayata geçirirken hata yapmaktan çok korkardım. Her şey mükemmel olsun isterdim. Ancak ambulans nöbetlerinden sonra, terminal ekranında aldığım o kırmızı "Error" mesajlarına gülümsemeye başladım. Sunucu mu çöktü? Yeniden başlatırım. Kod mu patladı? Baştan yazarım. Gecenin bir yarısı projem mi iptal oldu? Yeni bir repo açarım.

Çünkü artık biliyorum ki; nefes aldığınız, geri dönüp hatanızı düzeltebildiğiniz ve kaybettiğiniz şeyin sadece "veri" olduğu hiçbir durum gerçek bir başarısızlık değildir. Gerçek başarısızlık, ölümün geri döndürülemez kesinliğidir. O kesinlikle yüzleştikten sonra, hayattaki diğer tüm hatalar ve kayıplar sadece yeniden derlenmeyi (recompile) bekleyen küçük kod parçacıklarından ibaret kalıyor. Hata yapmaktan korkmayın, çünkü hala düzeltebilecek kadar hayattasınız.

Bazen bir veritabanı optimizasyon sorunu, bazen de içinden çıkılmaz hale gelen asenkron bir JavaScript hatası için masadan saatlerce hiç kalkmadan, su bile içmeden aralıksız kod yazdığım olurdu. Ekrana o kadar uzun süre bakardım ki artık kod satırları birbirine girmeye başlardı. Ve genelde ne olurdu biliyor musunuz? O 5 saatin sonunda yazdığım karmaşık spagetti kodu, ertesi sabah uyandığımda tamamen siler ve 10 dakikada çok daha sade bir şekilde baştan yazardım.

Zamanla, kariyerim ilerleyip Suku Tech gibi büyük projelerin mimarisini kurmaya başladıkça çok garip, neredeyse sihirli bir örüntü fark ettim.

Ne zaman masadan kalkıp kendime bir kahve yapmaya gitsem, ne zaman sıcak bir duşa girsem veya bilgisayarı tamamen kapatıp dışarıda hiçbir şey düşünmeden boş boş yürüyüşe çıksam... O bilgisayar başında saatlerce kan ter içinde kalarak çözemediğim problemin cevabı aniden, saniyeler içinde zihnimde beliriveriyordu. "Aha!" anı dedikleri bu olsa gerekti.

Bunun aslında nörobilimde (sinirbilim) çok net bir bilimsel açıklaması var. Biz ekrana bakıp bir bug'ı çözmeye odaklandığımızda beynimiz "Odaklanmış Düşünme" (Focused Mode) denilen analitik, dar bir çerçeveye geçer. Bu mod, detayları görmek ve basit mantık hatalarını bulmak için harikadır. Oysa sistem mimarisi tasarlamak, soyut düşünmek veya karmaşık algoritmik problemleri çözmek "Dağınık Düşünme" (Diffuse Mode) dediğimiz geniş açılı, yaratıcı bir zihin yapısı gerektirir. Siz bilgisayar başından kalkıp beyninizi rahatlattığınızda, aslında arka planda beyniniz o sorunu işlemeye (background processing) devam eder. Tıpkı bir sunucunun, siz ekrana bakmasanız bile arka planda logları okuyup veritabanını indekslemesi (cron jobs) gibi.

Artık bir kod bloğunda veya mimari bir kararda takıldığımda, kendimi masaya zincirleyip zorlamıyorum. 15-20 dakika içinde çözemiyorsam, bir şeylerin yanlış olduğunu kabul ediyor ve ekranı kapatıyorum. Çıkıp yürüyorum. Kulaklığımı takıp alakasız bir müzik dinliyor ya da sadece duvarı izliyorum.

Çünkü kod yazmanın aslında "hızlıca klavye tuşlarına basmak" değil, bütünüyle "düşünmek, tasarlamak ve sistem mühendisliği yapmak" olduğunu çok net bir şekilde anladım. Bugün, beş yıl öncesine kıyasla klavye başında geçirdiğim zaman çok daha az. Eskisinden çok daha az satır kod yazıyorum, kütüphaneleri daha az kullanıyorum. Ancak kurduğum sistemler eskisinden yüzlerce kat daha hızlı, daha güvenli ve daha ölçeklenebilir.

Çünkü asıl mimari, o karanlık kod editöründe parmaklarınızla değil; siz pencereden dışarı bakıp kahvenizi yudumlarken, zihninizin derinliklerinde inşa ediliyor. Eğer daha iyi bir yazılımcı olmak istiyorsanız, ellerinizi klavyeden çekin ve düşünmeye başlayın.

Bu durumda yapabileceğiniz tek bir şey vardır: O kaotik elektriksel aktiviteyi tamamen sıfırlamak. Defibrilatör pedlerini göğse yapıştırırsınız, "Uzaklaşın!" diye bağırırsınız ve o düğmeye basarsınız. Yüzlerce joul'lük bir elektrik şoku kalbin içinden geçer. O şok, tüm o rastgele ateşlenen hücreleri anlık olarak susturur, her şeyi sıfırlar. Umut, kalbin o kısa sessizlikten sonra kendi normal ritmini (Sinüs Ritmi) yeniden bulmasıdır. Bazen bulur, bazen bulmaz. Ama o şoku vermezseniz sonuç kesindir: Ölüm.

Şimdi gelelim yazılım dünyasına. Gece yarısı, production sunucusundan alarmlar yağıyor. SSH ile bağlanıyorsunuz, top komutunu çalıştırıyorsunuz ve görüyorsunuz ki CPU %100'de kilitlenmiş. Bellek (RAM) tamamen dolmuş. Süreçler (processes) birbirini bekliyor, hiçbiri ilerleyemiyor. Klasik bir Deadlock veya sonsuz döngü (infinite loop) durumu. Sunucu teknik olarak "açık" ve "çalışıyor" görünüyor ama hiçbir isteğe cevap vermiyor. Tıpkı fibrilasyondaki kalp gibi: Çalışıyor gibi görünüyor ama hiçbir iş üretmiyor.

O anda çoğu genç mühendis panikle log dosyalarını okumaya, hangi sürecin sorunu yarattığını bulmaya ve "kök neden analizi" (Root Cause Analysis) yapmaya çalışır. Ancak senin önünde saniyeler vardır, dakikalar değil. Müşteriler siteye giremiyordur, parası havada kalan işlemler vardır. Hastanın nabzı sıfıra inerken otopsi yapmaya kalkmazsınız; önce kalbi geri getirirsiniz, analiz sonra yapılır.

İşte o an yapmanız gereken şey, tıptaki defibrilasyonun birebir karşılığıdır: sudo reboot. Veya daha cerrahi bir müdahaleyle, sorunlu servisi kill -9 ile öldürüp yeniden başlatmak.

Evet, "Kapatıp açmayı denedin mi?" sorusu teknoloji dünyasının en eski ve en çok dalga geçilen tavsiyesidir. Ancak gerçek şu ki, bu tavsiye hem tıpta hem de mühendislikte hayat kurtarır. Bazen bir sistemi (ister kalp olsun, ister sunucu) düzeltmenin tek yolu, onu tamamen durdurup sıfırdan başlatmaktır. Çünkü o kaotik durumun içinden çıkmaya çalışmak, genellikle durumu daha da kötüleştirmekten başka bir şeye yaramaz.

Ders basittir: Kriz anında ego yapmayın. "Ben bu sorunu reboot etmeden çözerim" diye diretmeyin. Önce hastayı (sistemi) hayatta tutun, sonra laboratuvarda (staging ortamında) araştırmanızı yapın. Kök neden analizi, ancak hasta (veya sunucu) stabilize olduktan sonra yapılır. Öncelik her zaman hayatta kalmaktır (uptime).

Bir gün, devasa bir e-ticaret altyapısını yönetirken hayatımın en büyük aydınlanmalarından birini yaşadım. Bir şeyi fark etmiştim: Hata yapmayı engellemeye, her şeyi kusursuz tasarlamaya çalışmak, aslında o ekibin ve şirketin ilerlemesini, yenilik yapmasını engellemekti. Sürekli savunmada kalarak devrimsel hiçbir şey inşa edemezsiniz.

DevOps kültürü bana çok sert ama paha biçilemez bir şey öğretti. Sektördeki en iyi mühendislerin odaklandığı metrik, sistemin ne kadar süre hatasız çalıştığı (Mean Time Between Failures - MTBF) değildir. Asıl odaklandıkları şey, sistem çöktüğünde ne kadar hızlı toparlanabildiğidir (Mean Time To Recovery - MTTR). Kısacası, önemli olan yere hiç düşmemek değil, düştüğünüz yerden ne kadar hızlı kalkabildiğinizdir. Biz buna mühendislikte "Resilience" (esneklik/dayanıklılık) diyoruz. Netflix'in icat ettiği "Chaos Engineering" (Kaos Mühendisliği) konsepti tam da buna dayanır. Adamlar kendi production sunucularını kasıtlı olarak çökerten yazılımlar ("Chaos Monkey") yaptılar, sadece sistemlerinin bu felaketlerden nasıl otomatik kurtulabildiğini test etmek için! Bu benim için zihin açıcıydı.

Artık kodun veya altyapının %100 kusursuz olması için haftalarımı harcamıyorum. Onun yerine zamanımı ve enerjimi harika bir CI/CD pipeline'ı kurmaya, muazzam bir loglama yapısına ve anlık izleme (monitoring) sistemlerine harcıyorum. Sistemi auto-scaling (otomatik ölçekleme) ve self-healing (kendi kendini onarma) prensipleriyle tasarlıyorum. Artık bir şeyler patladığında paniklemiyorum, çünkü anında haberim oluyor. Nerede, neden patladığını görüyor, birkaç dakika içinde hatayı geri alıyor (rollback), düzeltip yola devam ediyorum. Deployment (yayına alma) korkusu tamamen bitti.

İlginçtir ki, DevOps'tan öğrendiğim bu teknik yaklaşım, zamanla benim kişisel hayatıma ve liderlik felsefeme de sızdı. Sürekli "en doğru" veya "en mükemmel" kararı vermek için felç olmak (analysis paralysis) yerine, artık sadece karar veriyorum ve deniyorum. Şirket (Suku Tech) için yeni bir teknoloji mi deneyeceğiz? Hemen prototipini yapıyoruz. Eğer hata yaparsam, eğer o teknoloji bizi yolda bırakırsa, bu artık benim gözümde bir "başarısızlık" değil; sadece sistemime düşen, incelenmesi gereken bir "log kaydı".

Hatayı analiz ediyor, dersimi alıyor, yamayı (patch) atıyor ve yoluma çok daha güçlü bir şekilde devam ediyorum. Mükemmeliyetçilik sadece bir illüzyon. Sizi yavaşlatan, korkutan, risk almanızı engelleyen koca bir yalan. Sık sık hata yapan, ama hatalarından saniyeler içinde öğrenip kendini düzelten bir sistem, masada duran ve hiç yayına alınmamış o "kusursuz" plandan her zaman, ama her zaman daha iyidir. Hata yapmayı kucaklayın, çünkü gerçek büyüme orada başlıyor.

Benim hikayemi diğer mühendislerden ayıran en büyük kırılma noktası ise tam da burada, o ambulansın arkasında başladı.

Bir paramedik (Acil Tıp Teknikeri) olarak üniformayı giyip sahaya çıktığınızda, hayatın sadece 0'lar ve 1'lerden ibaret olmadığını; gri alanların, çaresizliğin ve şanssızlığın ne demek olduğunu en acı yoldan öğrenirsiniz. Toplumun görünmez kılınan, sistemin (bug'ları olarak görülen) dışına atılmış insanlarıyla en filtresiz anlarında karşılaşırsınız.

Evsizlerin soğuk bir kış gecesindeki donma tehlikesine, madde bağımlılarının krizlerine, şiddet görmüş kadınların çaresizliğine, yaşlı ve kimsesiz insanların sadece birileriyle beş dakika konuşabilmek için ambulans çağırdığı o derin yalnızlığa şahit olursunuz. O ambulansın arka kapısı kapandığında, içerideki hastanın sosyal statüsü, bankadaki parası veya hangi dilde konuştuğu tamamen önemini yitirir. Orada sadece acı çeken bir insan ve onu anlamaya, ona yardım etmeye çalışan siz varsınızdır.

Makineleri tamir ederken sadece kodları anlamanız yeterlidir. Ancak insanları iyileştirirken (veya onlara o en zor anlarında eşlik ederken) onların hikayesini, acısını ve korkularını anlamak zorundasınız. Hastanın elini tutup "Korkma, yanındayım, her şey geçecek" diyebilmek, dünyadaki hiçbir programlama dilinin veya algoritmanın size öğretemeyeceği kadar derin bir insanlık deneyimidir.

Bu meslek, beni o steril ve kibirli teknoloji fanusundan çıkarıp, gerçek dünyanın ne kadar adaletsiz, kırılgan ve şefkate muhtaç bir yer olduğu gerçeğiyle yüzleştirdi. Bilgisayar karşısında bir "tanrı" edasıyla sistemleri yönetirken, sokakta bir insanın çaresizliği karşısında ne kadar küçük olduğumu gördüm.

Bugün bir yazılım şirketi yönetirken, bir ürün tasarlarken veya bir ekiple çalışırken insanlara sadece "kullanıcı" (user) veya "kaynak" (resource) olarak bakamıyorsam, bunun tek sebebi o ambulansta geçirdiğim yıllardır. Makineler hata (error) verir, insanlar ise acı çeker. Makineleri onarmak zeka gerektirir, evet; ama insanları anlamak, çok daha zor olanı, yani empati gerektirir. Ve ben hayattaki en büyük mühendislik dersimi bir klavyeden değil, çaresiz bir insanın gözlerinin içine bakarken aldım.

Dışarıdan komik gelse de, içeriden bakıldığında bu durum pek çok yazılımcı için ciddi bir anksiyete kaynağıdır. Kariyerimin özellikle ilk yıllarında ben de bu girdabın tam merkezindeydim. Her hafta Twitter'da, Reddit'te veya HackerNews'te trend olan yepyeni bir kütüphaneyi, daha hızlı olduğu iddia edilen yeni bir veritabanını, oyunun kurallarını değiştirdiği söylenen yeni bir "state-management" (durum yönetimi) aracını hemen öğrenmek zorunda hissediyordum. Buna sektörde "JS Fatigue" (JavaScript Yorgunluğu) veya genel anlamda FOMO (Fear Of Missing Out - Gelişmeleri Kaçırma Korkusu) diyoruz.

Eğer o anki en popüler, en yeni aracı projemde kullanmıyorsam, kendimi geri kalmış, demode ve sektörün gerisinde kalmış yetersiz bir mühendis gibi hissediyordum. React, Vue, Svelte, Solid, Next, Nuxt, Astro... CSS-in-JS, Tailwind, Styled Components... Redux, Zustand, Recoil... Liste asla bitmiyordu. Her biri çıkıyor, eskisinin kötü olduğunu iddia ediyor ve kendi "devrimsel" mimarisini satıyordu.

Sonra bir gün durdum. Gerçekten durdum ve bu araçların arka planda, kaputun altında (under the hood) aslında tam olarak ne yaptığını incelemeye başladım. Çok radikal bir şey fark ettim: Hepsi aslında aynı şeyin farklı bir renge boyanmış haliydi. Hepsi temelde HTTP istekleri yapıyor, hepsi DOM manipülasyonu gerçekleştiriyor, hepsi tarayıcının bellek yönetimi (garbage collection) sınırları içinde çalışıyor ve günün sonunda hepsi 0'lar ve 1'lere dönüştürülmek üzere derleniyordu.

O gün, o an yeni bir framework öğrenmeyi bıraktım. Bütün o "Trend" olan tutorial videolarını kapattım. Gidip temel ağ protokollerini (TCP/IP, UDP, DNS) en ince ayrıntısına kadar incelemeye başladım. Linux çekirdeğinin hafızayı (RAM) nasıl yönettiğini, CPU'nun process ve thread'leri nasıl zamanladığını (scheduling) okudum. Yıllardır ORM (Prisma, Sequelize vs.) arkasına saklanarak yazdığım veritabanı sorgularının aslında arka planda diskte B-Tree indekslerini nasıl aradığını (raw SQL mekanizmasını) öğrendim.

İşte "Fundamentals" (temeller) dediğimiz bu konuları anladığınızda, ortadaki o teknolojik sihir kayboluyor. Yerini derin bir mühendislik anlayışı alıyor.

Bugün karşıma yepyeni, devrimsel olduğu iddia edilen ve herkesin öve öve bitiremediği bir teknoloji çıktığında artık eskisi gibi paniklemiyorum. Çünkü biliyorum ki o yeni framework aslında benim yıllardır bildiğim temel bir mekanizmanın (örneğin Proxy objeleri, Event Loop, veya Virtual DOM konseptinin) sadece biraz daha farklı ve tatlı bir API (Syntax Sugar) ile paketlenmiş hali. Altında yatan temel mekanizmayı bildiğim için, o "yepyeni" aracı öğrenmem taş çatlasa bir hafta sonumu alıyor.

Teknoloji dünyasında üst katmanlar, frameworkler, kütüphaneler her ay değişir, eskir ve yerini yenilerine bırakır. Ama temeller (Linux, network, veri yapıları, algoritmalar) on yıllardır aynıdır ve bir on yıl daha aynı kalacaktır. Modayı takip etmeyi bırakıp rüzgarda savrulmamak için köklerimi temellere (Fundamentals) salmak, bu meslekte verdiğim açık ara en iyi karardı.

Sonra işler büyümeye başlar. Müşteriler çoğalır. Tek başınıza yetişememeye başlarsınız. "Bir şirket kursam, yanıma birkaç kişi alsam, daha büyük projeler yapabilirim" diye düşünürsünüz. Ve tam o noktada, hiç beklemediğiniz, hayatınızda karşılaşacağınızı tahmin bile etmediğiniz devasa bir karanlık dünya açılır önünüzde: Vergi, muhasebe ve hukuk.

Hiçbir kodlama kursu, hiçbir bootcamp ve hiçbir YouTube tutorial'ı size şunları anlatmaz: KDV (Katma Değer Vergisi) nedir ve ne zaman ödenir? Stopaj nedir? Ba-Bs formu nedir ve neden her ay göndermeniz gerekir? E-fatura ile e-arşiv fatura arasındaki fark nedir? SGK primi ne zaman yatar? Geçici vergi beyannamesi ne demektir? Gelir vergisi ile kurumlar vergisi arasındaki fark nedir? Muhtasar beyanname nedir? MERSIS kaydı nasıl yapılır? KEP adresi neden zorunludur?

İlk kez "Ticaret Sicil Gazetesi" denen şeyi duyduğumda, bunun gerçekten var olan bir gazete olduğuna inanamadım. Şirket kuruluşunuzun bu gazetede yayınlanması gerekiyormuş. Ve bunun bir maliyeti varmış. Ve her değişiklikte tekrar yayınlanması gerekiyormuş. Bir yazılımcı olarak "Neden bu veritabanına kayıt düşmüyor da gazete basılıyor?" diye sorguladığım anı çok net hatırlıyorum.

İlk faturamı kesmek tam bir gün sürdü. E-fatura portalına giriş yapmak, doğru vergi kodunu bulmak, KDV oranını doğru girmek, fatura serisini oluşturmak... Bir API endpoint'i yazmak bundan daha kolaydı. Ve eğer faturayı yanlış keserseniz veya zamanında göndermezseniz cezası var. Nakit akışınızı (cash flow) yönetmek, sunucu yönetmekten çok daha streslidir çünkü yanlış yaptığınızda log dosyası değil, vergi cezası gelir.

Sözleşme hukuku ise ayrı bir kâbus. İlk projelerinizi sözleşmesiz yapmışsınızdır, çünkü "karşılıklı güven" yeterli gelmiştir. Ta ki bir müşteri ödeme yapmayı reddetene kadar. O an "Keşke bir sözleşmem olsaydı" dersiniz. Sonra bir avukat tutarsınız, sözleşme hazırlarsınız ve o sözleşmenin her maddesinin aslında geçmişte birisinin acı çekerek öğrendiği bir dersten doğduğunu fark edersiniz.

Bugün geriye bakıp gülüyorum ama o süreçte çok terlediğimi de itiraf edeyim. Benim tavsiyem şu: Eğer freelancer'lıktan şirket kurmaya geçmeyi düşünüyorsanız, ilk yatırımınız bir sunucu veya bir yazılım aracı olmamalı. İlk yatırımınız iyi bir muhasebeci olmalıdır. İyi bir muhasebeci, sizi vergi cezalarından, SGK borçlarından ve hukuki sorunlardan koruyacak en değerli "altyapı" yatırımınızdır. Kod yazmayı bilirsiniz; ama fatura kesmeyi, vergi planlaması yapmayı ve sözleşme okumayı da öğrenmeniz gerekiyor. Kimse anlatmıyor ama mesleğin yarısı bu.

Sert bir gerçek söyleyeyim: LinkedIn profiliniz, özgeçmişinizin dijital versiyonudur. Yani süslü bir kağıt parçasıdır. Ve hiçbir ciddi teknoloji şirketi, sadece süslü bir kağıda bakarak birisini işe almaz. Görmek istedikleri şey somut, elle tutulur, çalışan bir iştir. Ve o iş GitHub'da (veya benzeri bir platformda) yaşar.

Suku Tech'te veya danışmanlık verdiğim şirketlerde birini işe alırken ilk baktığım yer LinkedIn değildir. GitHub profilidir. O profilin boş olması bile benim için bir veridir. Eğer bir yazılımcı adayı kendini "tutkulu ve meraklı" olarak tanımlıyor ama GitHub'ında son 2 yılda tek bir commit yoksa, o tutkuyu nerede yaşıyor acaba?

GitHub profiliniz, sizin dijital portföyünüzdür. Bir ressam nasıl sergisine gelen kişilere tablolarını gösteriyorsa, siz de potansiyel işverenlerinize veya müşterilerinize kodunuzu gösterirsiniz. "React biliyorum" demek kolaydır. Ama GitHub'ınızda React ile yazılmış, çalışan, deploy edilmiş bir proje varsa, artık "biliyorum" demek zorunda bile değilsinizdir. Proje kendisi konuşur.

Açık kaynak katkıları (Open Source Contributions) ise bambaşka bir seviyedir. Popüler bir projeye Pull Request gönderip kabul edilmesi, dünyanın dört bir yanındaki geliştiricilerin kodunuzu inceleyip (code review) onaylaması demektir. Bu, herhangi bir sertifikanın veya online kursun veremeyeceği kadar güçlü bir referanstır. "Bu kişinin kodunu, X projesinin maintainer'ları yeterli buldu ve birleştirdi (merge)" cümlesi, 50 tane Udemy sertifikasından daha ağır basar.

Peki nereden başlanır? Devasa projelere katkı yapmak zorunda değilsiniz. Kendi küçük projelerinizi bile GitHub'a koymakla başlayın. Bir to-do uygulaması bile olsa, düzgün bir README yazın, commit mesajlarınızı temiz tutun ve projeyi deploy edin (Vercel, Netlify gibi ücretsiz platformlar var). Sonra başkalarının projelerinde küçük düzeltmeler yapın; bir yazım hatası düzeltin, bir dokümantasyon eksikliğini giderin. Bu küçük adımlar sizi o topluluğun bir parçası yapar ve zamanla gerçek katkılara dönüşür.

LinkedIn'i tamamen bırakın demiyorum. Ama eğer haftada 5 saat LinkedIn'de zaman geçirip, GitHub'da 0 saat geçiriyorsanız, önceliklendirmeniz ciddi şekilde yanlış. Kariyerinizi konuşarak değil, yaparak inşa edin. Kodunuz sizin en güçlü CV'nizdir.

Gerçek dünyada ise durum trajikomik derecede basittir. Bugün ortalama bir startup'ı hacklemek için dahi bir yazılımcı olmanıza gerek yok. Çoğu zaman bir şirketin sunucularına sızmak için ihtiyacınız olan tek şey, o şirketteki stresli ve uykusuz bir geliştiricinin Cuma akşamı yaptığı ufak bir dikkatsizliktir.

İşte gerçek dünyada sistemlerin hacklenme yöntemleri:

1. Halka Açık .env Dosyaları (En Yaygın Hata)
Yeni nesil geliştiriciler her şeyi .env dosyalarında tutmayı çok seviyor (AWS anahtarları, veritabanı şifreleri, JWT secret'ları). Sorun şu ki; bazen yanlış yapılandırılmış bir Nginx veya Apache sunucusu, site url'sinin sonuna /.env yazan herkese bu dosyayı açıkça sunar. Veya daha kötüsü, o dosya yanlışlıkla GitHub'a public olarak commit edilir. Bir bot, o AWS anahtarını saniyeler içinde bulur ve hesabınızda kripto para madenciliği yapmak için binlerce sunucu açarak size bir gecede 50.000 dolarlık fatura kitler.

2. Açık Unutulan AWS S3 Bucket'ları
Bulut mimarisine geçen şirketlerin en büyük kabusu. "Sadece bizim sunucu okusun" diye ayarlanması gereken S3 depolama alanları, yanlış bir tıklamayla "Tüm dünyaya açık (Public)" hale gelir. Kimsenin haberi yoktur, ta ki bir güvenlik araştırmacısı (veya kötü niyetli biri) o adrese gidip müşterilerinizin kimlik fotoğraflarını, faturalarını ve gizli belgelerini tek bir tıkla indirene kadar.

3. "Admin/Admin" Şifreleri ve Korumasız Portlar
Docker muazzam bir teknoloji. Ancak geliştiriciler bazen bir veritabanını (örneğin Redis, MongoDB veya Elasticsearch) Docker ile ayağa kaldırırken dışarıya (0.0.0.0) açarlar ve varsayılan (default) şifreyi değiştirmeyi unuturlar. İnternette durmaksızın tarama yapan (Shodan gibi) botlar, şifresiz bir veritabanı bulduğu an içeri girer, tüm verinizi indirip siler ve yerine "Verilerinizi geri istiyorsanız şu adrese Bitcoin yollayın" yazan bir not bırakır.

4. Gereksiz Root Yetkileri (Principle of Least Privilege Eksikliği)
Bir uygulama sadece resim yüklüyor olabilir. Ama o uygulamaya sunucudaki her dosyayı okuma (Root) yetkisi verilmiştir. Uygulamada ufacık bir dosya yükleme zafiyeti çıktığında, saldırgan sadece resim klasörüne değil, sistemdeki tüm şifre dosyalarına (/etc/shadow) erişir.

Özetle, siber saldırıların %99'u, filmlerdeki gibi karmaşık algoritmalarla değil; açık bırakılan pencereler, paspasın altına saklanan anahtarlar ve hız uğruna atlanan temel mühendislik pratikleri yüzünden gerçekleşir. Hız (Agile) ve Güvenlik (Security) arasındaki o ince çizgide yürümek, DevOps mühendisliğinin en zor ama en kritik sanatıdır. Bizim işimiz karanlık odalardaki dahi hackerları durdurmak değil; kendi ekibimizin yanlışlıkla o kapıyı açık unutmasını engelleyecek sistemleri tasarlamaktır.

İnsan bedeni, tam olarak budur. Milyarlarca yıllık evrimin, deneme-yanılmayla, hiçbir mimar veya baş mühendis olmadan, rastgele mutasyonlar ve doğal seçilimle yazdığı dünyanın en eski, en karmaşık ve en büyük Legacy Code projesidir. Ve tıpkı eski bir yazılım projesi gibi, içi mantıksız tasarım kararları, gereksiz karmaşıklıklar ve açıklanamayan "bug"larla doludur.

Bir paramedik ve aynı zamanda bir sistem mühendisi olarak, insan bedenine baktığımda gördüğüm şey inanılmaz bir dağıtık sistemdir (Distributed System). Beyniniz ana sunucudur (Master Node). Sinir sisteminiz ağ altyapısıdır (Network). Hormonlarınız, organlar arasında veri taşıyan API çağrılarıdır. Bağışıklık sisteminiz ise sürekli çalışan bir güvenlik duvarıdır (Firewall) ve bazen yanlış alarm vererek kendi hücrelerinize saldırır (Otoimmün hastalıklar; yazılımdaki karşılığı: Firewall'un kendi sunucunuzu engellemesi).

İşin komik yanı, bu "Tanrısal tasarım" diye yücelttiğimiz bedenin içinde korkunç mühendislik hataları vardır. Yemek yediğimiz ve nefes aldığımız boru aynıdır (Farinks). Bu yüzden her yıl binlerce insan yemek yerken boğulur. Hangi mühendis, veri giriş portuyla (ağız) hava giriş portunu (burun/ağız) aynı boruya bağlar? Bu, bir sunucunun aynı porttan hem HTTP hem de veritabanı trafiği almasına benzer; korkunç bir tasarım kararıdır.

Göz siniri retinanın önünden geçer ve kör nokta oluşturur (kablo yönetimi berbat). Apandis organı hiçbir işe yaramaz ama bazen iltihaplanıp sizi öldürmeye çalışır (kullanılmayan ama silinmemiş eski bir modülün aniden hata fırlatması). Dizlerimiz ve bel omurlarımız, dört ayaklı yaşam için tasarlanmış ama biz iki ayak üzerinde duruyoruz; yani donanım (hardware) üzerinde hiç test edilmemiş bir yazılım güncellemesi (update) çalıştırıyoruz.

Ve tıpkı eski yazılım projelerinde olduğu gibi, bir organ bozulduğunda zincirleme bir çökme (Cascade Failure) başlar. Böbrekler iflas ederse kan temizlenemez, toksinler birikir, kalp zorlanır, akciğerler sıvı dolar. Tek bir servisin (mikroservisin) çökmesiyle tüm sistemin domino taşı gibi yıkılması... Bunu hem sunucu odasında hem de acil serviste defalarca yaşadım.

Ancak bu kaotik ve hatalı tasarıma rağmen, insan bedeni milyarlarca yıldır ayakta. Kendini onarıyor, adapte oluyor, yeni tehditlere karşı güncelleme (bağışıklık) yapıyor. Hiçbir yazılım projesi bu kadar uzun süre production'da kalmayı başaramadı. Belki de mükemmel olmayan ama "yeterince iyi" çalışan sistemlerin, aşırı optimize edilmiş kırılgan sistemlerden daha dayanıklı olduğunu kabul etmemiz gerekiyor. Hem sunucu odasında hem de insan bedeninde asıl mucize, mükemmellik değil; o kaosa rağmen ayakta kalmaktır.

İnsanlar kriz anlarında içgüdüsel olarak tutunacak bir dal, ne yapması gerektiğini bilen bir otorite figürü ararlar. Ailesinden birini kanlar içinde gören bir insanın attığı o çaresiz bakış ile; aylardır üzerinde çalışılan ürün lansmanı günü ana sunucular çöktüğünde şirketin CEO'sunun size attığı o dehşet dolu bakış, özünde aynı çaresizliğin farklı yansımalarıdır. "Lütfen bana ne yapmam gerektiğini söyle."

Bir paramedik olarak yıllarca bu anların içinde yoğrulmak, bana bir kriz anında paniğin sadece "zaman kaybı" olduğunu öğretti. Birisi size doğru çığlık atarak koştuğunda veya Slack üzerinden "Her şey patladı, bittik!" mesajları yağdığında, nefesinizi yavaşlatıp ses tonunuzu alçaltmayı öğrenirsiniz. Çünkü siz paniklerseniz, sistemin geri kalanı tamamen çöker.

Ancak kimsenin konuşmadığı, o kahramanlık hikayelerinin ardında saklanan çok ağır bir bedel vardır: En soğukkanlı insan olmanın getirdiği o korkunç yalnızlık.

Siz dışarıdan bakıldığında çelik gibi sinirlere sahip, olayları yöneten, "Şu damar yolunu aç", "Şu sunucuyu yedekten dön", "Hemen bana şu veriyi getirin" diye net talimatlar veren o güçlü insansınızdır. Herkes sizin bu gücünüzden beslenerek sakinleşir. Peki ya siz? Sizin korktuğunuzda, tereddüt ettiğinizde veya ne yapacağınızı bilemediğinizde bakabileceğiniz, sığınabileceğiniz kimse yoktur. İçinizde fırtınalar kopuyor, elleriniz titriyor olsa bile bunu dışarıya yansıtma lüksünüz yoktur. Çünkü o "Lider" maskesini bir saniyeliğine bile indirirseniz, etrafınızdaki herkes umudunu kaybeder.

Bu durum, yıllar içinde insanı tuhaf bir duygusal izolasyona sürüklüyor. Çevrenizdeki insanlar, sizin de aslında onlar gibi kırılgan bir insan olduğunuzu unutmaya başlıyorlar. "O halleder, o zaten hep sakindir" etiketi üzerinize yapıştığında, kendi acılarınızı veya stresinizi paylaşacak alan bulamıyorsunuz. Ambulansın arkasında kalp masajı yaparken veya klavye başında ter dökerken gösterdiğiniz o profesyonel maske, zamanla normal hayatınıza da yapışıyor. En yakın arkadaşınızla dertleşirken bile o analitik, soğuk kriz yöneticisi modundan çıkamadığınızı fark ediyorsunuz.

Bu satırları yazma nedenim de tam olarak bu. Eğer şirketinizde, ailenizde veya arkadaş grubunuzda o her krizde dimdik duran, herkesi sakinleştiren ve sorunları çözen bir "soğukkanlı" insan varsa, onun yanına gidin ve sadece nasıl olduğunu sorun. Çünkü bir kriz anında herkesin ona ihtiyacı vardır; ama kriz bittiğinde ve herkes rahat bir nefes alıp dağıldığında, o çelik gibi insanın içindeki yorgunluğu tek başına taşıması gerekir. Omuzlarında başkalarının çaresizliğini taşıyan insanların, en çok sığınacak bir limana ihtiyacı vardır.

Sonuç: Tam bir mühendislik kâbusu ve harcanan milyonlarca lira.

Eskiden "Monolit" (Monolith) dediğimiz tek parça uygulamalar yazardık. Kullanıcı kaydı, ödeme sistemi, ürün listeleme... Hepsi tek bir kod deposunda (repo), tek bir veritabanına bağlı olarak çalışırdı. Kodun içinde bir hata (bug) olduğunda, nerede patladığını bulmak saniyeler sürerdi.

Ancak "Mikroservis" modasıyla birlikte, bu basit sistemi parçalara ayırmaya başladık. Ödeme sistemi ayrı bir uygulama oldu, kullanıcı servisi ayrı, bildirim servisi ayrı. Teoride kulağa harika geliyor: "Ödeme servisi çökerse, sitenin kalanı çalışmaya devam eder!"

Pratikte ise şu olur: Kullanıcı bir ürün satın alır. Sipariş servisi, ödeme servisine ağ üzerinden (network) bir istek atar. O sırada ağda anlık bir yavaşlama (latency) olur, istek zaman aşımına uğrar (timeout). Sipariş servisi "Ödeme alınamadı" der ama aslında ödeme servisi o isteği yarım saniye sonra alıp müşterinin kartından parayı çekmiştir. Müşteri parasını kaybeder ama sipariş oluşmaz (Eventual Consistency problemleri).

Artık sadece kod yazmıyorsunuz; ağ gecikmelerini (Network Latency), dağıtık sistemlerde veri tutarlılığını (Distributed Transactions), servisler arası güvenliği (mTLS), birbirleriyle nasıl haberleşeceklerini (Message Brokers, gRPC) çözmeye çalışıyorsunuz. Eskiden basit bir fonksiyon çağırmak (Function Call) 1 milisaniye sürerken, şimdi o işlemi yapmak için veriyi JSON'a çevirip internet üzerinden başka bir sunucuya göndermek zorundasınız.

Mikroservisler, teknik bir sorunu çözmez; teknik sorunu "Organizasyonel" bir soruna çevirir. Eğer şirketinizde yüzlerce yazılımcınız varsa, herkesin aynı kod deposunda çalışması imkansızlaştığı için mikroservislere geçersiniz. Netflix bunu yapmak zorundaydı. Ama sizin şirketiniz Netflix değil.

Eğer yeni bir projeye başlıyorsanız veya küçük/orta ölçekli bir ekipseniz, yapacağınız en zekice hamle mükemmel bir "Modüler Monolit" (Modular Monolith) yazmaktır. Tek repo, tek veritabanı, tek CI/CD pipeline'ı. Dağıtımı (deploy) kolay, izlemesi (monitoring) kolay, hatasını bulması (debugging) kolaydır. Milyonlarca kullanıcıya kadar da bir monolit ile mükemmel bir şekilde ölçeklenebilirsiniz (GitHub, Shopify ve StackOverflow uzun yıllar monolit olarak çalıştı ve devasa boyutlara ulaştılar).

Gereksiz mimari karmaşıklık, girişimlerin sessiz katilidir. Havalı mimariler uğruna basitliği feda etmeyin. Bırakın monolitler monolit olarak kalsın, inanın bana gece çok daha rahat uyuyacaksınız.

Evet. Koşmayacaksınız. Çünkü koşan insan düşünmez.

Koşarak olay yerine giren bir paramedik, ayağını bir moloza takıp düşebilir ve kendisi de hastaya dönüşebilir. Adrenalinle tavan yapmış bir zihinle hastayı değerlendirirken kritik bir bulguyu atlayabilir. Panikle yanlış ilacı yanlış dozda verebilir. Acil tıpta "hızlı" ile "acele" arasında uçurum büyüklüğünde bir fark vardır. Hızlı olmak, ne yapacağını bilip onu verimli bir şekilde uygulamaktır. Acele etmek ise ne yapacağını bilmeden hareket etmektir. Biri hayat kurtarır, diğeri hayat alır.

Bu ders, benim DevOps mühendisi ve şirket kurucusu kimliğime birebir taşındı.

Gece yarısı telefonunuz çalar. PagerDuty veya monitoring sisteminiz size "Production sunucusu yanıt vermiyor" diye bildirim gönderir. O anda içinizdeki ilk dürtü, yataktan fırlayıp panikle bilgisayarı açmak ve aklınıza gelen ilk komutu terminale yazmak olur. "Hemen servisi yeniden başlatayım!", "Şu dosyayı hemen düzenleyeyim!", "Acil veritabanına bağlanıp şu sorguyu çalıştırayım!"

Durun. Koşmayın. Nefes alın.

Panikle çalıştırdığınız o "acil" komut, yanlış sunucuya bağlanmanıza ve sağlam olan sunucuyu da çökertmenize neden olabilir. Hızla düzenlediğiniz o konfigürasyon dosyasındaki bir fazla boşluk (whitespace) veya eksik tırnak, tüm sistemi daha da bozabilir. Sahada gördüm: Yanlış dozda ilaç veren bir sağlık çalışanı ile yanlış sunucuda DROP DATABASE çalıştıran bir mühendis arasında, psikolojik mekanizma olarak hiçbir fark yoktur. İkisi de panikle hareket etmiştir.

Hem acil tıpta hem de DevOps dünyasında bu paniği yenmenin tek silahı "Checklist" (Kontrol Listesi) kültürüdür. Ameliyathanelerde cerrahlar kesiye başlamadan önce bir kontrol listesi okurlar. Pilotlar kalkış öncesi her seferinde aynı listeyi gözden geçirirler. Benim de hem ambulansta hem de sunucu krizlerinde işe yarayan kendi kontrol listelerim var: Hangi sunucudayım? Production mı, staging mi? (Hastanın kimliği doğru mu?) Son yedek ne zaman alındı? (Hastanın bilinen alerjisi var mı?) Bu komutu çalıştırırsam geri dönüşü var mı? (Bu ilacı verirsem geri dönüşü var mı?)

Bu sorular sizi 30 saniye yavaşlatır. Ve o 30 saniye, hayatınızın en değerli 30 saniyesi olabilir. Çünkü o 30 saniye, "Doğru kararı yavaş vermek" ile "Yanlış kararı hızlı verip felaketi büyütmek" arasındaki farktır.

Eğer bir gün gece yarısı sizi uyandıran o alarm çaldığında, içinizdeki o panik sesini duyarsanız, aklınıza benim bu sözümü getirin: Koşmayın. Adım atın, nefes alın, listeye bakın ve düşünerek ilerleyin. Hem sunucu odasında hem ambulansın arkasında en çok hayat kurtaran şey hız değil, soğukkanlılıktır.

Ben mi? Ben o "Rockstar" yazılımcıyı Suku Tech'in kapısından içeri bile sokmam.

Nedenini anlamak için bu "10x" arkadaşlarla aynı ekipte çalışmış veya onların yazdığı kodu devralmış olmanız gerekir. Evet, bu insanlar gerçekten de inanılmaz hızlı kod yazarlar. Bazen bir haftalık sprint işini cuma akşamı birkaç saatte bitiriverirler. Ama sorun şu ki; arkalarında bıraktıkları şey genellikle devasa bir yıkımdır.

Rockstar developer'lar dokümantasyon yazmaktan nefret ederler. Çünkü onlara göre kod zaten kendini anlatıyordur (spoiler: anlatmıyor). İsimlendirme standartlarına uymazlar, "bunu daha optimize edebilirim" diyerek kimsenin anlamayacağı, okuması işkence olan abartılı (over-engineered) çözümler üretirler. Ve en kötüsü, kod gözden geçirme (code review) süreçlerinde ekip arkadaşlarına yukarıdan bakarlar. "Neden böyle yaptın?" diye sorduğunuzda size öyle bir ego ile cevap verirler ki, ekibin geri kalanı bir süre sonra soru sormayı bırakır.

Sonuç? Şirketteki tüm kritik bilgi o tek kişinin beynine hapsolur (Buna sektörde "Bus Factor" denir). O kişi şirketten ayrıldığında veya tatile çıktığında bütün sistem çöker, çünkü koduna kimse dokunmaya cesaret edemez.

Peki ben kimi işe alırım? Ben "1x", hatta "0.8x" mühendisi işe alırım.

Benim aradığım mühendis, "sıkıcı" kod yazan mühendistir. Standartlara uyan, okunduğunda bir roman gibi anlaşılan, testleri yazılmış, zekasını kanıtlamak için karmaşık algoritmalar kasmayan, basit problemleri basit çözen insanları arıyorum. Benim için iyi bir mühendis, cuma akşamı production'a kod çıkmayan mühendistir. Kodu commit etmeden önce "Bunu benden sonra okuyacak olan kişi ne demek istediğimi anlar mı?" diye durup düşünen kişidir.

Günün sonunda yazılım mühendisliği, kulaklıklarınızı takıp dünyadan koptuğunuz bireysel bir sanat dalı değildir. Yazılım, son derece sosyal bir takım oyunudur. Ürettiğiniz kod, diğer insanların kodlarıyla entegre olacak, diğer insanlar tarafından okunacak ve yıllarca bakımı yapılacaktır.

Bir şirketin yetenekli ama iletişimsiz ve egolu bir dahiyedense; ortalama hızda kod yazan ama iletişim kurabilen, etrafındaki junior'ları eğiten, bilgisini paylaşan ve egosunu kapıda bırakan 3 tane sağlam mühendise ihtiyacı vardır. Çünkü sistemler kahramanlar tarafından değil, birbirine güvenen ekipler tarafından ayakta tutulur. Kahramanlara sadece çizgi romanlarda ihtiyacımız var, sunucu odalarında değil.

Açık kaynak (Open Source) kod dünyası gerçekten bir mucize. Bizi tekerleği yeniden icat etmekten kurtarıyor ve hızla ürün geliştirmemizi sağlıyor. Ancak sektördeki pek çok genç mühendisin ve özellikle maliyetleri kısmaya çalışan yöneticilerin anlamadığı çok kritik bir denklem var: Açık kaynak kod bedavadır, ancak o kodu projenizde tutmanın bir maliyeti vardır.

Bir startup kuruyorsunuz, projeye 50 farklı üçüncü parti (third-party) kütüphane ekleyip ürünü iki ayda canlıya alıyorsunuz. Harika bir başarı öyküsü gibi duruyor değil mi? Ancak arka planda saatli bir bomba kurdunuz ve bunun adına "Teknik Borç" (Technical Debt) diyoruz.

Bir kütüphaneyi projenize dahil ettiğiniz an, o kütüphanenin gelecekteki tüm kaderini de projenize bağlamış olursunuz. O "bedava" kütüphaneyi yazan geliştirici yarın projeyi sıkılıp terk edebilir. Altı ay sonra o kütüphanede devasa bir güvenlik zafiyeti (CVE) bulunabilir. Kullandığınız framework'ün yeni versiyonu çıktığında, o çok sevdiğiniz kütüphane uyumsuz hale gelebilir.

Ve işte o an, "bedava" dediğiniz o kod parçasının faturasını ödeme vakti gelmiştir.

DevOps mühendisi ve kurucu şapkamla Suku Tech'i yönetirken en çok mesai harcadığım şeylerden biri "Dependency Hell" (Bağımlılık Cehennemi) dediğimiz bu durumdan kaçınmaktır. GitHub'da yıldız (star) sayısı yüksek diye her kütüphaneyi projenize alamazsınız. Bir noktadan sonra sadece npm paketlerinizi güncellemek, birbirleriyle uyumlu versiyonlarını bulmak ve çıkan güvenlik uyarılarını (dependabot alerts) temizlemek için tam zamanlı bir mühendis çalıştırmak zorunda kalırsınız.

Çok ünlü "Left-pad" krizini hatırlayın. Bir geliştirici, sadece 11 satırlık basit bir kodu NPM'den çektiği için dünya çapında React ve Babel dahil binlerce proje saatlerce çökmüş, build alamaz hale gelmişti. Sadece 11 satır!

Artık kendi projelerimde (ve ekibimden beklediğim standartlarda) kuralım çok basit: Eğer ihtiyacım olan özellik projemin temel (core) iş süreçlerinden biri değilse ve kendim 1-2 gün içinde yazabileceksem, asla dışarıdan bir bağımlılık (dependency) eklemem. Oturup o mantığı kendim yazarım. Çünkü kendi yazdığım 100 satırlık basit kodun tüm kontrolü bendedir. Bozulursa nasıl tamir edeceğimi bilirim.

Özetle, dışarıdan aldığınız her paket (package), aslında sisteminize davet ettiğiniz yabancı bir misafirdir. Açık kaynak dünyasına minnettarız, ancak bedava peynirin sadece fare kapanında olduğunu da unutmamak gerekiyor. Yazılım mimarisinde en iyi bağımlılık, hiç var olmayan bağımlılıktır.

Çünkü o zamanlar kafamdaki formül çok basitti: Müşteri = Para = Şirketin ayakta kalması. Her müşteriyi memnun etmek zorundaydım. Her isteğe "evet" demek zorundaydım. Çünkü "hayır" dersem müşteriyi kaybederim, müşteriyi kaybedersem para kazanamam, para kazanamazsam şirket batar. Basit bir korku zinciri.

O ilk müşterinin projesi, başlangıçta 2 haftalık basit bir iş olarak planlanmıştı. Sonuçta 4 ay sürdü. Her hafta yeni bir "ufak" istek geliyordu ve her biri projeyi biraz daha karmaşıklaştırıyordu. Scope Creep (Kapsam Kayması) denen bu olgu, startup dünyasının en sinsi katillerinden biridir. Farkında bile olmadan, anlaştığınız işin 10 katını yapar hale gelirsiniz ve bunu orijinal fiyatla yaparsınız.

O 4 ayın sonunda hesabı yaptım: Saatlik kazancım asgari ücretin altına düşmüştü. Üstelik o projeye harcadığım 4 ayda, kabul edebileceğim ve çok daha karlı olabilecek en az 5-6 başka projeyi geri çevirmek zorunda kalmıştım. Yani bir müşteriye "evet" derken, farkında olmadan onlarca potansiyel müşteriye "hayır" demiştim.

O acı tecrübeden sonra çok önemli bir iş kuralı öğrendim: "Hayır" demek, bir müşteriyi kaybetmek değildir. "Hayır" demek, şirketinizi korumaktır. Her müşteriye evet dediğinizde, ekibinizin zamanını, enerjisini ve kaynaklarını dağıtırsınız. Odağınızı kaybedersiniz. Kaliteyi düşürürsünüz çünkü her şeyi aynı anda yapmaya çalışırsınız. Ve en kötüsü, gerçekten değerli olan müşterilerinize yeterli zamanı ayıramaz hale gelirsiniz.

Bugün Suku Tech'te çok net sınırlarım var. Proje başlamadan önce kapsam (scope) yazılı olarak belirlenir ve imzalanır. Kapsam dışı her istek, ek süre ve ek ücret demektir. Bu kural ilk başta "katı" veya "müşteri dostu olmayan" gibi görünebilir ama tam tersidir. Çünkü sınırları net olan bir ilişki, her iki taraf için de sağlıklıdır. Müşteri neyi ne zaman alacağını bilir; ben de neyi ne kadar sürede yapacağımı bilirim. Kimse kimseyi sömürmez, kimse kimseye kızmaz.

En pahalı derslerimi ders kitaplarından değil, sahadan öğrendim. Ve o derslerden en değerlisi şuydu: Bir kurucu olarak en güçlü silahınız "evet" değil, "hayır" demektir. Her "hayır", aslında daha doğru, daha değerli ve daha sürdürülebilir bir "evet"e yer açmaktır.

Gelin, sektör olarak yıllardır yaptığımız ve artık vazgeçmemiz gereken bu saçmalıklara bir göz atalım.

1. "Şifrenizi Her 30 Günde Bir Değiştirmek Zorundasınız"
Bunu kurumsal şirketler çok sever. Peki gerçekte ne olur? Kullanıcı "Denizhan2026!" olan şifresini mecbur kaldığı için "Denizhan2026!!" yapar. Bir sonraki ay "Denizhan2026!!!" olur. Gerçek bir hacker bu şifreyi ele geçirdiğinde, kullanıcının o ay şifrenin sonuna kaç tane ünlem koyduğunu tahmin etmesi sizce ne kadar sürer? Şifre değiştirme zorunluluğu güvenliği artırmaz, sadece kullanıcıları zayıf ve tahmin edilebilir kalıplar kullanmaya iter. Hatta NIST (Amerikan Ulusal Standartlar Enstitüsü) bile artık "Şifreler ifşa olmadığı sürece düzenli değiştirme zorunluluğunu kaldırın" diyor.

2. Karmaşık Şifre Kuralları (Büyük harf, rakam ve en az bir hiyeroglif içermelidir)
"Şifreniz en az 1 büyük harf, 1 küçük harf, 2 rakam ve en az 1 özel karakter içermelidir." Bu kural yüzünden insanlar şifrelerini hatırlayamaz, post-it kağıtlara yazıp monitörlerinin kenarına yapıştırırlar. Oysa Tr0ub4dor&3 gibi karmaşık görünen kısa bir şifreyi kırmak, bilgisayarlar için çok kolaydır. Ancak kırmızı-kalem-masada-duruyor gibi sadece küçük harflerden oluşan uzun bir cümleyi kırmak (Brute Force ile) yüzyıllar sürer. Biz ise kullanıcıları zorla ilkini seçmeye zorluyoruz.

3. Kod Kötüyken WAF (Web Application Firewall) Arkasına Saklanmak
Birçok startup, uygulamasındaki SQL Injection veya XSS açıklarını kodu düzelterek çözmek yerine, önüne devasa ve pahalı bir WAF (Cloudflare vs.) koyarak sorunu çözdüğünü sanır. WAF elbette faydalıdır ancak bu, evin kapısı kırıken içeri kimse girmesin diye bahçeye güvenlik görevlisi dikmeye benzer. Eğer o güvenlik görevlisi bir an arkasını dönerse veya biri arka bahçeden dolaşırsa evin içi tamamen savunmasızdır. Gerçek güvenlik dışarıda değil, içerde başlar: Veriyi temizle (sanitize inputs), ORM kullan, "Principle of Least Privilege" (En Az Yetki Prensibi) uygula.

Güvenlik, kullanıcıya eziyet etmek değildir. Güvenlik; görünmez, sessiz ve sistemin temeline (architecture) işlenmiş olmalıdır. Kullanıcının klavyesini kırmasına sebep olan CAPTCHA'lar veya anlamsız şifre kuralları sistemi korumaz; sadece kullanıcıyı sizden nefret ettirir.

DevOps süreçlerini tasarlarken her zaman şu dengeyi gözetmek zorundayız: Bir sistemin güvenliği (Security), onun kullanılabilirliğini (Usability) yok ediyorsa, o sistem zaten başarısız olmuş demektir.

Gerçeklik bundan o kadar uzak ki...

Bir yazılım mühendisinin günlük iş akışının dürüst ve sansürsüz versiyonu kabaca şöyledir: Bir hatayla (bug) karşılaşırsınız. Hata mesajını (error message) kopyalarsınız. Google'a yapıştırırsınız. İlk sonuç Stack Overflow'dur. Cevapları okursunuz. En çok oy almış (upvoted) cevabı bulursunuz. O cevaptaki kod parçacığını (code snippet) projenize kopyalarsınız. Çalışır. Neden çalıştığını %100 anlamasanız bile, çalıştığı gerçeği yeterlidir. Bir sonraki hataya geçersiniz.

Bu döngüyü günde ortalama 15-20 kez tekrarlarsınız. Ve dünya genelinde milyonlarca mühendis aynı anda aynı şeyi yapmaktadır. Yani Stack Overflow aslında bir "Soru-Cevap sitesi" değildir; o, modern dijital medeniyetin sessiz ve görünmez altyapısıdır. Bir nevi yazılım dünyasının Wikipedia'sıdır ama çok daha kritiktir. Çünkü Wikipedia kapansa insanlar bilgiye erişemez; Stack Overflow kapansa insanlar kod yazamaz.

Bir düşünce deneyi yapalım: Stack Overflow yarın sabah kalıcı olarak kapandı. Ne olur? İlk saat içinde dünya genelindeki yazılım geliştirme hızı yaklaşık %60 düşer. Junior (kıdemli olmayan) mühendisler tamamen felç olur. Senior mühendisler bile o "bunu daha önce nasıl çözmüştüm" anlarında refleks olarak Google'a yazdıkları soruların cevaplarını bulamaz hale gelir.

İlk gün sonunda, şirketlerin sprint planlamaları (iş planları) tamamen çöker çünkü tahmin edilen süreler artık gerçeği yansıtmaz. İkinci hafta, kritik güvenlik yamaları (security patches) gecikir çünkü mühendisler yamayı nasıl uygulayacaklarını bulamaz. İlk ay sonunda, bankacılık ve finans sektöründeki yazılım projeleri durma noktasına gelir. Altı ay içinde, küresel teknoloji üretimi ciddi bir darboğaza girer.

Abartıyor muyum? Belki biraz. Ama çok da değil.

İşin en komik yanı, Stack Overflow'daki o hayat kurtarıcı cevapları yazan insanlar da genellikle başka bir Stack Overflow cevabından öğrendikleri bilgiyle yazıyorlardır. Yani ortada devasa, kendi kendini besleyen bir kolektif bilgi döngüsü var. Kimse gerçekten "her şeyi bilen" değil. Hepimiz birbirimizin cevaplarından öğreniyor ve o bilgiyi yeniden paketleyip bir başkasına aktarıyoruz.

Bunda utanılacak bir şey yok. Bu aslında insanlığın en güzel yanlarından biri: Kolektif zeka. Tek başına her şeyi bilemezsin ama milyonlarca mühendis bir araya gelip bilgisini paylaştığında, ortaya nükleer fizikten web tasarımına kadar her konuda anında erişilebilir devasa bir bilgi bankası çıkar. Stack Overflow, insanlığın "Birlikte daha zekiyiz" prensibinin en somut kanıtıdır. Ve evet, o kapanırsa hepimiz çok fena yanarız.

Suku Tech'i sıfırdan kurup büyütürken ve tüm sunucu mimarisinin, veritabanlarının, müşteri verilerinin sorumluluğunu tek başıma omuzlarken bir noktada vücudumun ve zihnimin çok ciddi alarmlar vermeye başladığını fark ettim. Geceleri uykumdan ter içinde uyanıp, hiçbir uyarı almadığım halde sunucu metriklerini kontrol ediyordum. Hafta sonu arkadaşlarımla bir kafede sohbet ederken bile, aklımın arka planında çalışan bir sekmede sürekli şu sorular dönüyordu: "Acaba son deploy'da bir bellek sızıntısı (memory leak) oldu mu? Veritabanı yedeği dün gece düzgün alındı mı? Sitede trafik aniden artarsa yük dengeleyici (load balancer) buna dayanabilecek mi?"

Buna teknoloji sektöründe "Alert Fatigue" (Uyarı Yorgunluğu) diyoruz. Ancak bunun tıbbi ve psikolojik dünyadaki karşılığı çok daha net: Burnout, yani "Tükenmişlik Sendromu".

O karanlık noktadan, uykusuz gecelerden ve sürekli ekrana bakma zorunluluğundan dönebilmemi sağlayan şey, işi "daha iyi ve daha çok" yapmaya çalışmak değil, işi "bırakmayı" öğrenmek oldu.

Kendime çok katı, esnetilemez sınırlar çizmeye karar verdim. Eğer bir sunucu gece yarısı çöküyorsa ve bu donanımsal ya da bizim öngörebildiğimiz bir hataysa, o sunucunun insan müdahalesine gerek kalmadan, tamamen otomatik olarak yeniden ayağa kalkacak (auto-scaling ve self-healing) şekilde tasarlanması gerekiyordu. Gece saat 3'te benim uykumdan uyanıp SSH ile sunucuya bağlanıp servisi yeniden başlatmam, başarılı bir DevOps süreci değil; düpedüz başarısız bir sistem tasarımıydı.

Teknolojiden kaynaklanan problemleri, insanı (yani kendimi) daha fazla çalıştırarak, daha fazla stres altına sokarak çözmenin asla sürdürülebilir olmadığını çok acı bir tecrübeyle anladım. Sistemlerin "esnek" olması gerekiyordu, insanların "dayanıklı" olması değil.

Bugün geldiğim noktada, hafta sonları bilgisayar kapağını bile açmıyorum. Doğa yürüyüşlerine çıkıyorum, ormanda kamp yapıyorum, telefonumu saatlerce sessize alıyor ve kelimenin tam anlamıyla "offline" olmanın tadını çıkarıyorum. Ve tahmin edin ne oldu? Dünyanın sonu gelmedi. Sunucular bensiz de, ben uyurken de çalışmaya devam etti. Çünkü onları artık benim yerime karar verebilecekleri şekilde kodlamıştım.

Bazen iyi bir sistem mühendisi olmanın, sağlam bir teknoloji şirketi yönetmenin yolu; klavye başında saatler harcamaktan değil, bilgisayarın başından kalkmayı, sistemi kendi haline bırakmayı bilmekten geçiyor. İnanın bana, sunucuları her zaman yeniden başlatabilir (reboot) veya baştan kurabilirsiniz. Ancak kendi zihin sağlığınızı ve bedeninizi "reboot" etmek o kadar kolay değildir.

Grafik kullanıcı arayüzlerinin (GUI) büyük bir bedeli vardır. Bu bedel, işlemci gücü veya RAM tüketimi değildir; bu bedel sizin dikkatinizdir. Bir web paneline veya masaüstü uygulamasına girdiğinizde, aslında o uygulamayı tasarlayan UX/UI tasarımcılarının sizin dikkatinizi çekmek için kurduğu ince tuzaklara düşersiniz. Kırmızı bildirim balonlukları, yuvarlatılmış köşeler, algoritmaların sizi içeride tutmak için optimize ettiği akışlar, "bunu da al", "buna da tıkla" diyen agresif pencereler... Modern yazılımlar çoğu zaman bir araç olmaktan çıkıp, sizinle rekabet eden birer dikkat hırsızına dönüşür.

Oysa terminalin böyle bir derdi yoktur. Terminal size bir şey satmaya çalışmaz. Dikkatinizi dağıtmaz. İşinizi bölüp size "Günün nasıl geçiyor, uygulamamıza puan verir misin?" diye sormaz. Sadece bir imleç yanıp söner ve sessizce sorar: "Ne yapmamı istiyorsun?"

Komutu yazarsın, çalıştırır ve biter. Eğlence yok, şov yok, gürültü yok. Sadece saf, kesintisiz bir iletişim.

Terminalin bu acımasız ve aynı zamanda dürüst yapısı, Unix felsefesinin temelinden gelir: "Bir işi yap, ama o işi çok iyi yap." Birden fazla küçük ve yetenekli aracı (grep, awk, sed, pipe'lar) bir araya getirerek inanılmaz karmaşık veri işleme operasyonlarını saniyeler içinde halledebilirsiniz. Bir GUI uygulamasında aynı işi yapmak için muhtemelen 4 farklı menüye girmeniz, 15 kez tıklamanız ve uygulamanın donmamasını umut etmeniz gerekir.

Yıllar içinde fark ettim ki bu sadece bir yazılım veya araç tercihi değil, düpedüz bir yaşam felsefesi. Hayatımızdaki "arayüzler" – sosyal medya akışları, bitmeyen mesaj bildirimleri, sürekli çalan telefonlar, ardı arkası kesilmeyen Zoom toplantıları – o kadar yorucu ve tüketici ki, terminale dönmek, fırtınalı bir denizin ortasında ıssız, sessiz ve güvenli bir limana sığınmak gibi hissettiriyor. Orada sadece ben ve makine varız. Her şey kurallara, mantığa ve girdi-çıktı (I/O) prensiplerine bağlı. Ne eksik, ne fazla. Sistemin bana ne yapacağımı söylemesi yerine, ben sisteme ne yapması gerektiğini söylüyorum. Kontrol tamamen bende.

Belki de bu yüzden Suku Tech'i kurarken, devasa sunucu mimarilerini yönetirken veya gecenin bir yarısı production ortamında çıkan kritik bir hatayı çözerken en rahat hissettiğim yer hep o siyah ekran oldu. Çünkü kaosun, karmaşanın ve gürültünün içinde sadeliği ve netliği bulabileceğiniz tek yer orası. Terminal ekranı, bir DevOps mühendisinin meditasyon odasıdır. Eğer bilgisayarınızla aranızda grafiklerden, butonlardan ve renklerden oluşan o kalın duvarı kaldırırsanız, makinenin gerçek gücüyle ve kendi odaklanma kapasitenizin sınırlarıyla tanışırsınız.

Bu kuralın arkasındaki hikaye şudur: Hastanın başına bağladığınız monitör size kalp ritmi, oksijen saturasyonu (SpO2), tansiyon ve nabız gibi verileri anlık olarak gösterir. Ancak bu veriler yanıltıcı olabilir. Parmaktaki oksimetre probu düşmüştür ve cihaz SpO2 değerini sıfır gösteriyordur; oysa hasta gayet rahat nefes alıyordur. EKG kablosu gevşemiştir ve ekranda düz çizgi (Asistol) gösteriyordur; oysa hastanın nabzı gayet güçlüdür. Tam tersi de olabilir: Monitör her şeyin yolunda olduğunu söylerken hasta gözlerinizin önünde kötüleşiyordur. Tansiyon cihazı 120/80 gösterir ama hastanın teni balmumu gibi sararmış, terleme başlamış ve bilinci kapanmaya başlamıştır. Cihaz rakamları verirken, vücudun dili bambaşka bir şey anlatıyordur.

Bu dersi ilk kez sahada, bir gece nöbetinde çok sert bir şekilde aldım. Yaşlı bir hastamız vardı, monitöre bağladık, vital bulguları (nabız, tansiyon, oksijen) gayet stabil görünüyordu. Rakamlar normaldi. Ancak hastanın yüzüne baktığımda bir şeylerin çok yanlış olduğunu hissettim. Göz bebekleri odaklanamıyordu, dudaklarının kenarında hafif bir morarma başlamıştı ve sorularıma verdiği cevaplar her dakika biraz daha anlamsızlaşıyordu. Monitör "Her şey yolunda" diyordu; ama hasta çöküyordu. Hızla müdahale ettik. Eğer monitöre güvenip arkamıza yaslansaydık, sonuç çok farklı olabilirdi.

Şimdi bir de DevOps mühendisliğine bakalım. Bugün her teknoloji şirketi Datadog, Grafana, Prometheus veya benzeri monitoring araçlarıyla dev ekranlar dolusu dashboard kurmuştur. CPU kullanımı, bellek tüketimi, istek sayısı (RPS), yanıt süresi (latency), uptime yüzdesi... Hepsi yeşil, hepsi normal aralıkta. "Sistem sağlıklı" diye arkamıza yaslanırız.

Ama o sırada kullanıcılar destek hattını arıyordur: "Ödeme sayfası açılmıyor." "Giriş yapamıyorum." "Sepetime ürün ekleyemiyorum." Sunucu ayakta, CPU düşük, RAM bol, uptime %100. Peki o zaman neden kullanıcılar siteyi kullanamıyor? Çünkü sorun altyapıda değil, uygulama katmanındadır. Bir API endpoint'i hatalı veri döndürüyordur, bir JavaScript hatası ödeme formunu kilitliyordur veya üçüncü parti bir servis (ödeme geçidi) sessizce zaman aşımına uğruyordur. Monitoring araçlarınız altyapıyı izliyordur ama kullanıcı deneyimini izlemiyordur.

Monitöre (dashboard'a) bakmak kolaydır. Güzel grafikler, yeşil çizgiler ve "All Systems Operational" (Tüm Sistemler Çalışıyor) yazısı yöneticilerin içini rahatlatır. Ancak bu, güvenlik kamerasına bakıp "Bina güvende" demek gibidir; oysa kameranın görmediği arka kapı ardına kadar açıktır.

Hem acil tıpta hem de sistem mühendisliğinde gerçek ustalık, sayılara ve ekranlara değil, "gerçek dünya çıktısına" (hastanın durumuna veya kullanıcının deneyimine) bakabilmektir. Dashboard'unuz her şeyin yolunda olduğunu söylüyorsa ama müşterileriniz şikayet ediyorsa, dashboard yalan söylüyordur. Monitörü değil, hastayı tedavi edin. Grafana'yı değil, kullanıcıyı dinleyin.

Acil tıpta bu durumun adı "Triage" (Triyaj) dır. Fransızca "ayırmak, sınıflandırmak" anlamına gelen bu kelime, kriz anlarında hayatları kurtaran en acımasız ama en gerekli karar verme sanatıdır. Hastaları dört renge ayırırsınız:

Kırmızı (Acil): Hemen müdahale edilmezse ölecek ama müdahale edilirse kurtarılabilecek hastalar. Bunlar birinci önceliktir. Kontrol edilemeyen kanama, tıkalı hava yolu, tansiyon şoku (hipovolemik şok) gibi durumlar.

Sarı (Geciktirilebilir): Ciddi yaralı ama birkaç saat içinde müdahale edilse de hayatta kalabilecek hastalar. Kırıklar, derin kesikler gibi durumlar. Bekleyebilirler.

Yeşil (Ayaktan): Kendi başına yürüyebilen, hayati tehlikesi olmayan hafif yaralılar. Bunlar en son bakılır.

Siyah: Müdahale edilse bile kurtarılamayacak hastalar. Bu en zor karardır. Sınırlı kaynaklarınızı kurtarabileceğiniz hastalara yönlendirmek zorundasınızdır.

İşin en çarpıcı kısmı şudur: En çok bağıran, en çok ağlayan hasta genellikle en az acil olandır. Çünkü bağırabilecek ve ağlayabilecek kadar enerjisi vardır. Gerçekten ölmek üzere olan hastalar genellikle sessizdir.

Şimdi bu sistemi, gece yarısı şirketin tüm altyapısının çöktüğü bir senaryoya taşıyın. Slack kanallarında herkes aynı anda bağırıyor. Satış ekibi: "Ödeme sayfası çalışmıyor, müşteriler kaybediyoruz!" Pazarlama: "Blog sayfası açılmıyor, SEO puanımız düşecek!" Destek: "Kullanıcılar giriş yapamıyor!" CEO: "Neden yatırımcı panelindeki grafikler boş?" Herkes kendi sorununu en acil olarak görüyor ve hepsi aynı anda sizin dikkatinizi istiyor.

O an bir Triyaj yapmanız gerekir:

Kırmızı: Kullanıcılar giriş yapamıyor demek, muhtemelen kimlik doğrulama servisi (Auth Service) veya veritabanı çökmüş demektir. Bu, sistemin kalbidir (hava yolu). Her şeyden önce bu çözülmelidir çünkü giriş yapılamadan hiçbir özellik çalışmaz.

Sarı: Ödeme sayfası çalışmıyor. Ciddi bir gelir kaybı ama kullanıcılar en azından siteye girebiliyorsa, bu sorun Auth düzeldikten sonra ele alınabilir. Birkaç dakika gecikebilir.

Yeşil: Blog sayfası açılmıyor ve yatırımcı paneli boş. Üzücü ama kimseyi öldürmez. Bu sorunlar en sona kalabilir.

Olay yerine (ister kaza yerine, ister sunucu odasına) vardığınızda, en çok bağıran kişiye (veya en çok mesaj atan yöneticiye) değil, en sessiz ama en kritik soruna odaklanmanız gerekir. Triyaj, duygularınızı bir kenara bırakıp "Kim kurtarılabilir, hangi sırayla?" sorusunu soğukkanlılıkla cevaplayabilme yetisidir.

Hayatımın her iki dünyasında da öğrendiğim en acımasız ama en değerli ders budur: Her şeyi aynı anda çözemezsiniz. Kaynaklarınız sınırlıdır. Her seferinde bir seçim yapmak ve o seçimin doğruluğuna güvenmek zorundasınız. Önceliklendirme, bir kriz anının en önemli becerisidir ve bu beceri, hem ambulansın arkasında hem de terminalin karşısında aynı mantıkla çalışır.

"Müşteri sunumu var, bu butonu ACİL kırmızı yapmamız lazım!", "Yatırımcı toplantısı var, yeni modülü ACİL yayına almalıyız!", "Sunucu yavaşladı, ACİL kontrol et!". Şirket içi mesajlaşma kanallarında herkesin birbiriyle büyük harflerle konuştuğu, her hatanın (bug) bir dünyanın sonu senaryosu gibi algılandığı, kalp krizine davetiye çıkaran o zehirli çalışma kültürü... Startup dünyası, çalışanlarını her şeyin ölüm-kalım meselesi olduğuna inandırmak üzerine kuruludur.

Ancak geçmişinizde gerçek bir "Ölüm-Kalım" meselesinin içinde bulunduysanız (örneğin bir ambulansın arkasında, trafik kazası geçirmiş, nefes alamayan ve kalbi durmak üzere olan bir gence müdahale ettiyseniz), o kurumsal "ACİL" kelimesi anlamını tamamen, ama tamamen yitiriyor.

Hayatımın iki dönemini karşılaştırdığımda en çok güldüğüm şeylerden biri bu "Aciliyet" algısındaki devasa uçurumdur. Sahadaki bir paramedik için acil durum; oksijenin bitmesidir, hastanın nabzının sıfıra düşmesidir, kaza yerinde sızan benzindir. Zamana karşı yarışırsınız çünkü saniyeler (mecazi değil, kelimenin tam anlamıyla saniyeler) bir insanın yaşamla ölüm arasındaki biletidir.

Bu gerçeklikle yüzleştikten sonra, teknoloji dünyasına döndüğümde insanların paniklediği şeyler bana o kadar absürt gelmeye başladı ki... "Sitemiz çöktü, 15 dakikadır yayında değiliz, mahvolduk!" Hayır, mahvolmadık. Kimse ölmüyor, kimse kanamıyor, kimsenin ailesi kapıda ağlayarak bizden haber beklemiyor. Sadece birkaç kullanıcı sepetlerine ürün ekleyemedi veya birileri komik bir kedi videosunu 15 dakika geç izledi. Hepsi bu. Şirket biraz para kaybedebilir, yatırımcı biraz sinirlenebilir, Twitter'da (X) birkaç kişi söylenebilir. Ama günün sonunda herkes yatağına canlı ve sağlıklı girecek.

Bu perspektif (bakış açısı) kayması, benim teknoloji dünyasındaki en büyük süper gücüm oldu. Bir ürün yöneticisi panik halinde yanıma koştuğunda veya bir kriz anında sunucular alev aldığında, içimde zerre kadar bir stres hissetmiyorum. Derin bir nefes alıyorum, gülümsüyorum ve ekibime "Sorun değil, sadece kod, çözeriz" diyorum.

Çünkü gerçek bir felaketin kokusunu bir kez aldığınızda, bilgisayar ekranındaki sanal krizler sizi korkutamaz. İşinizi ciddiye almakla, o işi hayatın merkezine koyup kendinizi tüketmek arasındaki çizgiyi çekmek zorundasınız. Dünyayı kurtarmıyoruz (bunu mecazi olarak değil, harfiyen söylüyorum). Sadece yazılım yapıyoruz. Eğlenmenize bakın.

Epidemiyolojide "Sürü Bağışıklığı" (Herd Immunity) adı verilen hayati bir prensip vardır: Bir virüsün bir popülasyonda yayılabilmesi ve tutunabilmesi için, enfekte olabileceği savunmasız (bağışık olmayan) konaklara ihtiyacı vardır. Eğer bir toplumun ezici çoğunluğu (%85-95'i) aşılanmış ve bağışıklık kazanmışsa; virüs taşıyıcıdan bir sonraki hedefe sıçrayamaz. Bulaşma zinciri kırılır. Ve böylece, henüz aşı olamayacak kadar küçük bir bebek veya kemoterapi gören bağışıklığı zayıf bir birey bile, etrafındaki "bağışık sürünün" oluşturduğu biyolojik kalkan sayesinde hayatta kalır.

Bu kalkan bireysel bir kahramanlık değil; kolektif bir dayanışmanın ürünüdür.

Şimdi bu biyolojik gerçeği alın ve modern dünyanın en kritik altyapısını oluşturan Açık Kaynak (Open Source) ekosistemine yerleştirin. Karşınıza çıkacak olan benzerlik, tesadüfün çok ötesindedir.

Linus Yasası: Gözlerin Sayısı ve Biyolojik Kalkan

Açık kaynak dünyasının amentüsü sayılan meşhur bir kural vardır. Eric S. Raymond, Katedral ve Çarşı kitabında bunu Linus Torvalds'a atıfla şöyle formüle eder:
"Yeterince göz olduğunda, bütün hatalar yüzeyseldir." (Given enough eyeballs, all bugs are shallow.)

Kapalı devre (proprietary), kaynak kodları kasalarda saklanan bir yazılım; aşılanmamış, dış dünyaya kapalı ve tek bir patojenin içeri sızmasıyla yerle bir olabilecek izole bir kabile gibidir. İçerideki 20 kişilik mühendislik ekibinin görmediği tek bir sıfır gün (zero-day) açığı, kabilenin sonunu getirebilir.

Oysa Linux çekirdeği, Kubernetes, PostgreSQL veya Node.js gibi devasa açık kaynak projeler; yeryüzündeki milyonlarca geliştiricinin gözü önünde, rüzgara, güneşe ve mikrop saçan dijital ortama açık bir şekilde yaşar.

Bir açık kaynak kütüphanesini sisteminize dahil ettiğinizde (mesela npm install veya cargo add yaptığınızda), aslında sisteminize bir "aşı" yaparsınız. O kod parçası, daha önce dünyanın dört bir yanındaki yüz binlerce farklı sunucuda çalışmış, binlerce hacker tarafından saldırıya uğramış, kenar durumları (edge cases) test edilmiş ve antikorları üretilmiştir. Siz o kodu projenize eklerken, o sürünün edindiği bağışıklığı da miras alırsınız.

Bir banka sunucusunun veya bir hastane bilgi sisteminin güvenliği, o kurumun kendi yazdığı kodlardan değil; arkasında duran açık kaynak sürüsünün bağışıklık duvarından güç alır.

Aşısız Kalanlar ve "Başkası Nasılsa Bakıyordur" İllüzyonu

Peki, sürü bağışıklığı ne zaman çöker?

Tıpta bunun cevabı çok nettir: İnsanlar hastalığın dehşetini unuttuğunda, aşı olmayı gereksiz bir külfet olarak görüp "Zaten herkes aşılanmış, bana bir şey olmaz" diyerek aşıdan kaçmaya başladığında. Sürüdeki bağışık birey oranı kritik eşiğin altına düştüğü an, unutulmuş virüsler hortlar ve salgın başlar.

Açık kaynak dünyasında da tam olarak bu parazitlik yaşanıyor.

Trilyon dolarlık teknoloji devleri, bankalar ve unicorn girişimler; altyapılarının %90'ını açık kaynak projelerin sırtına yüklüyor. Ama o kütüphanelerin bakımına tek bir satır katkı (contribution) vermiyor, tek bir güvenlik taraması yapmıyor ve o projeleri geceleri bodrum katında gönüllü olarak ayakta tutmaya çalışan geliştiricilere tek bir dolar bağışlamıyorlar.

Herkes aynı tehlikeli varsayıma sığınıyor: "Nasılsa açık kaynak, nasılsa birileri kodu inceliyordur."

Sonra ne oluyor?

2014 yılında Heartbleed krizi patladı. İnternetteki güvenli iletişimin (HTTPS) kalbi olan OpenSSL kütüphanesinde iki yıldır duran devasa bir açık keşfedildi. Milyarlarca dolarlık şirketlerin trafiğini şifreleyen bu kritik yazılımı, meğer iki kişilik bir ekip gönüllü olarak ayakta tutmaya çalışıyormuş ve kimse kodun derinliklerine bakmamış.

Daha yakın tarihte yaşanan xz utils arka kapı (backdoor) vakasını hatırlayın. Linux dağıtımlarının kalbine yerleştirilen sofistike bir siber saldırı, şans eseri tek bir mühendisin milisaniyelik gecikmeleri fark etmesiyle son anda engellendi. Saldırgan (Jia Tan), tükenmiş ve yalnız kalmış bir açık kaynak geliştiricisinin güvenini iki yıl boyunca ilmek ilmek işleyerek projeye sızmıştı.

Sürü, aşı olmayı bıraktığı anda virüs en zayıf halkadan içeri girdi.

Kolektif Bağışıklığa Katkı Vermek

Bir toplumda aşı olmak sadece kendi sağlığınızı korumak değildir; kucağındaki bebeği koruyamayan anneyi, kanser tedavisi gören yaşlıyı koruma sorumluluğudur. Bencilliğin bittiği, kamusal bilincin başladığı yerdir.

Yazılımda da açık kaynak kod kullanıyorsanız, o sürünün bir parçasısınız demektir.

Kullandığınız bir kütüphanede bulduğunuz bir hatayı sadece kendi projenizde "monkey patch" ile geçiştirip kapatırsanız, virüsü gizlemiş olursunuz. Ama o hatayı bir Pull Request açarak ana depoya (upstream) bildirir ve düzeltirseniz, dünyanın öbür ucundaki tanımadığınız bir mühendisin sistemini de korumuş olursunuz. Sisteme bir antikor enjekte etmiş olursunuz.

Açık kaynak, bedava yazılım marketi değildir. Açık kaynak, insanlığın bilgi birikimini ortak bir biyolojik organizma gibi savunma sözleşmesidir.

Eğer sürünün sunduğu bağışıklıktan faydalanıyorsanız, o sürüyü beslemek ve korumak zorundasınız.
Aksi takdirde, günün birinde kapınızı çalacak olan o ölümcül patojene karşı elinizde ne bir aşı kalır, ne de sığınabileceğiniz bir kalkan.

Ağır bir diyabetik ayak yarası, kontrolsüz bir enfeksiyon ya da ezilme travması sonucu kan dolaşımı durduğunda; doku yavaş yavaş oksijensiz kalır ve hücreler ölmeye başlar. Tıpta buna nekroz, halk arasında ise kangren denir. Kangrenli bir bacak artık bir insan uzvu değildir; tüm vücuda zehir (toksin ve bakteri) pompalayan ölümcül bir fabrikadır.

Dünyadaki hiçbir cerrah bir hastanın bacağını keyifle kesmez. Her hekim önce dokuyu kurtarmayı, antibiyotikle enfeksiyonu kurutmayı, damarı açıp kan akışını geri getirmeyi dener. Ama öyle bir eşik vardır ki; o çizgiyi geçtiğinizde bacağı kurtarmaya çalışmak, hastayı mezara göndermekle eşdeğerdir. Zehir kana karışır (sepsis), böbrekler iflas eder, kalp durur.

O an cerrah neşteri ve kemik testeresini eline alır. Bacağı kesip atar.

Bu bir başarısızlık değildir. Bu, hastanın yaşaması için ödenen acımasız ama zorunlu bir bedeldir: Bütünün yaşaması için parçayı feda etmek.

Peki, yazılım mühendisliği masasına oturduğumuzda ne yapıyoruz?

Kod Fetişizmi ve Bitmeyen "Refactoring" Masalı

Yazılımcılar olarak kodlarımıza karşı hastalıklı, romantik bir bağ geliştiririz. Bir zamanlar şirketimizin ilk MVP'sini sırtlamış, gece yarıları kahve eşliğinde bin bir emekle yazılmış o 10 bin satırlık monolitik modül; bizim gözümüzde bir başyapıttır.

Ama zaman geçmiştir. Şirket büyümüş, gereksinimler değişmiş, teknolojiler evrilmiştir. O eski kod artık sistemin en karanlık köşesinde kokuşmaya başlamıştır:

• İç içe geçmiş 15 katlı if-else blokları,
• Global değişkenlerin havada uçuştuğu fonksiyonlar,
• Dokümantasyonu olmayan, testleri çalışmayan, kimsenin içine girmeye cesaret edemediği spagetti yapılar...

Sisteme her yeni özellik eklenmeye çalışıldığında o modül patlar. Bir yeri düzeltirsiniz, bambaşka üç yer çöker. Veritabanını kilitler, belleği sömürür, sprint'leri felç eder.

Ve ekibin kıdemli mühendisleri toplantıda aynı tanıdık cümleyi kurar:
"Bunu azar azar refactor edeceğiz. Her sprint'te birkaç dosyasını temizleyip 'Clean Code' standartlarına getireceğiz."

İşte bu, kangren olmuş ve çürümeye yüz tutmuş bir bacağa sargı bezi sarıp, "Her gün biraz krem sürersek zamanla iyileşir" demekle aynı şeydir.

O kod artık iyileşemez. O kod artık doku nekrozuna uğramıştır. İçine kattığınız her yeni temiz fonksiyon, o çürük çorbanın içinde anında kirlenir ve çürür. Siz onu kurtarmaya çalıştıkça, şirketin mühendislik enerjisi ve motivasyonu sepsise girer.

Batık Maliyetin (Sunk Cost) Kanlı Prangası

Peki neden kesip atamıyoruz? Neden o modülü tamamen çöpe gönderip sıfırdan inşa etme cesaretini gösteremiyoruz?

Çünkü insan beyni Batık Maliyet Yanılsaması (Sunk Cost Fallacy) ile sakatlanmıştır.

Yöneticinin kafasında tek bir hesap döner: "Biz o modüle iki yıl önce 100 bin dolar harcadık, üç mühendisimiz altı ay boyunca gece gündüz çalıştı. Şimdi nasıl çöpe atarız?"

Bir cerrahın, "Ama bu bacak 40 yıldır hastayı taşıyordu, üzerinde ne kadar çok emek var, şimdi nasıl kesip atayım?" demesi ne kadar absürtse; bir yazılım yöneticisinin veya mimarın geçmişte harcanan zamana sığınarak çürümüş kodu sistemde tutması da o kadar trajikomiktir.

Geçmişte harcanan zaman gitmiştir. O para ödenmiştir. Geleceği belirleyen tek şey şudur: Bu kod parçası bugün sisteme değer mi katıyor, yoksa sistemi zehirliyor mu?

Eğer bir modülü ayakta tutmak için harcadığınız bakım maliyeti (maintenance cost) ve yarattığı krizler, onu sıfırdan yazmanın maliyetini aşmışsa; orada mühendislik bitmiş, sadece duygusal inat başlamış demektir.

Ne Zaman Refactoring, Ne Zaman Amputasyon?

Bir sistemin hasta yatağında refactoring mi yoksa amputasyon mu gerektirdiğini nasıl anlarsınız? Deneyimlerim bana şu üç semptomun cerrahi bir gösterge olduğunu öğretti:

1. Korku Eşiği: Eğer ekibinizdeki mühendisler o modüldeki bir dosyayı değiştirmekten korkuyor, "Aman oraya dokunmayalım, ne olacağı belli olmaz" diyorsa; o kod artık canlı değildir, zombidir.
2. Test Edilemezlik: Kodun bağımlılıkları o kadar birbirine dolanmıştır ki, tek bir birim testi (unit test) yazabilmek için 40 farklı servisi ayağa kaldırmanız gerekiyordur.
3. Değişim Maliyetinin Orantısızlığı: İki saatlik basit bir arayüz değişikliği, o modülün içindeki karmaşık bağımlılıklar yüzünden iki haftalık bir regresyon testine ve üç ayrı prod patlamasına yol açıyorsa.

Bu üç semptom bir aradaysa, elinizdeki kremleri ve pansuman bezlerini yere bırakın. Refactoring masalı sona ermiştir.

Amputasyon Bir Sanattır

Bir uzvu kesmek, kör bir baltayla rastgele vurmak demek değildir. Cerrah damarları bağlar, sinir uçlarını özenle kapatır, temiz dokuyu korur ve protez takılabilecek steril bir güdük bırakır.

Yazılımda da bir modülü ampute etmek; git rm -rf yapıp kaçmak değildir.
Önce sınırları net bir arayüz (Interface / API Gateway) çizersiniz. Eski modülün arkasında sessizce yepyeni, sade ve modern bir servis inşa edersiniz. Trafiği adım adım yeni servise yönlendirir (Strangler Fig Pattern), eski kodun bağlantılarını tek tek ve soğukkanlılıkla kesersiniz.

Ve son bağlantı koptuğunda, o eski 10 bin satırlık kamburu tek bir commit ile depodan silip atarsınız:
feat: remove legacy billing module. Rest in peace.

O gün terminalinizde 10 bin satırın kırmızıyla silindiğini gördüğünüzde hissedeceğiniz hafiflik; kangrenli bacağından kurtulup yoğun bakımdan sağ salim çıkan bir hastanın aldığı ilk derin nefes gibidir.

Bazen en büyük mühendislik, kod yazmak değil; doğru zamanda, doğru parçayı gözünü kırpmadan kesip atabilme cesaretidir.

Eğer acil tıp çalışanları hastaların bu ilk çığlıklarına göre hareket etseydi, acil servisler her gün binlerce yanlış teşhis ve gereksiz cerrahi müdahaleyle dolup taşardı. Çünkü acı çeken bir insan, bedeninde neyin ters gittiğini rasyonel olarak analiz edemez. Kalp krizi geçirdiğini sanan bir hastanın sadece ağır bir mide spazmı (reflü) yaşadığı; veya "Sırtım tutuldu, rüzgarda kaldım" diyen bir hastanın ölümcül bir aort yırtılması (diseksiyon) ile karşı karşıya olduğu yüzlerce vakaya şahit olursunuz.

Tıpta teşhisin %80'i tahlillerden veya pahalı MR cihazlarından değil; doğru alınmış bir Anamnezden (Hasta Öyküsü) gelir.

Bunun için acil tıpta OPQRST adı verilen katı bir sorgulama protokolü uygulanır:

• O (Onset): Bu ağrı tam olarak ne zaman ve nasıl başladı? Dinlenirken mi, hareket halindeyken mi?
• P (Provocation): Ağrıyı artıran veya hafifleten bir pozisyon var mı?
• Q (Quality): Ağrının karakteri nasıl? Bıçak saplanır gibi mi, mengenede sıkıştırılır gibi mi, yanma hissi mi?
• R (Radiation): Ağrı bir yere yayılıyor mu? Sol kola mı, çeneye mi, sırta mı?
• S (Severity): 1 ile 10 arasında bir puan versen kaç dersin?
• T (Time): Ağrı sürekli mi var, yoksa dalgalar halinde gelip gidiyor mu?

Bu sorular, hastanın panik dolu sis perdesini aralar ve hekimi altta yatan gerçek biyolojik arızaya götürür.

Peki, yazılım dünyasında "Gereksinim Analizi" (Requirement Gathering) toplantılarına oturduğumuzda ne yapıyoruz?

"Uygulama Çalışmıyor" Krizinin Anatomisi

Yazılım projelerinde müşteriden veya iş biriminden gelen talepler, acil servisteki hastanın çığlıklarından farksızdır.

Müşteri veya ürün yöneticisi toplantı odasına hışımla girer:
"Kullanıcılar sisteme giriş yapamıyor, her şey çöktü!"
Veya daha tehlikelisi, doğrudan kendi hatalı teşhisini dayatır:
"Ana sayfadaki giriş butonunu kırmızı yapmamız ve ekranın tam ortasına devasa bir açılır pencere (pop-up) koymamız lazım. İki güne yetiştirin!"

Deneyimsiz bir yazılımcı veya ajans hemen başını sallar: "Tamam, butonu kırmızı yapıp ortalayalım, pop-up ekleyelim." İki gün sonra özellik canlıya alınır; ama dönüşüm oranları (conversion rate) yerlerde sürünmeye devam eder. Müşteri daha da öfkelenir: "Yaptınız ama yine çalışmıyor!"

Çünkü siz hastanın ağrısının nereden kaynaklandığını sormadınız; hastanın panikle önerdiği saçma sapan tedaviyi uyguladınız.

Eğer masaya bir mühendis gibi otursaydınız, tıptaki OPQRST protokolünü yazılıma uyarlardınız:

• Onset (Başlangıç): "Kullanıcıların giriş yapamadığını tam olarak ne zaman fark ettiniz? Son deployment'tan sonra mı, yoksa yeni reklam kampanyası başladıktan sonra mı?"
• Provocation (Tetikleyici): "Bu sorun sadece Safari mobilde mi yaşanıyor, yoksa Chrome masaüstünde de var mı? Wi-Fi kullanıcılarında mı, hücresel veride mi?"
• Quality (Hatanın Karakteri): "Kullanıcı butona bastığında sayfa sonsuz bir yükleme döngüsüne mi giriyor, yoksa anında 'Hatalı Şifre' uyarısı mı veriyor?"
• Radiation (Etki Alanı): "Bu sorun sadece bireysel kullanıcıları mı etkiliyor, kurumsal hesapları da kapsıyor mu? Ödeme adımı da bu durumdan etkilendi mi?"
• Severity (Şiddet): "Giriş yapamayanların oranı toplam trafiğin yüzde kaçı? Şirketin cirosuna anlık etkisi ne?"

Bu soruları sormaya başladığınız an, o devasa "Uygulama çöktü" efsanesi bir anda buharlaşır. Gerçek teşhis ortaya çıkar: Meğer son pazarlama kampanyasında Instagram'dan gelen kullanıcıların tarayıcısı (in-app browser) çerezleri (cookie) engelliyordur ve oturum açılamıyordur.

Çözüm kırmızı buton veya pop-up değildir; iki satırlık bir authentication yönlendirmesidir.

Yanlış Anamnez Projeyi Batırır

Tıpta yanlış hasta öyküsü almak hastayı mezara götürür. Apandisiti olan birine gaz sancısı teşhisi koyup evine gönderirseniz, o apandisit birkaç saat sonra patlar ve hasta peritonitten hayatını kaybeder.

Yazılımda da yanlış gereksinim analizi, şirketleri iflasa sürükler.

Müşterinin "Bizim çok gelişmiş bir raporlama modülüne ihtiyacımız var" sözünü sorgulamadan kabul edip; ekibi 4 ay boyunca devasa filtreleme sistemleri, dinamik grafikler ve PDF dışa aktarma modülleri geliştirmeye kilitlersiniz. Dört ayın ve yüz binlerce liranın sonunda o modül yayına girer.

Ve ne olur biliyor musunuz? Müşteri o ekranda sadece sağ üstteki "Excel Olarak İndir" butonuna basar. Geri kalan hiçbir filtreyi, hiçbir karmaşık grafiği hayatında bir kez bile kullanmaz. Çünkü onun asıl semptomu "Ben veriyi muhasebecime ham olarak göndermek istiyorum" ihtiyacıdır. Siz doğru soruları sormadığınız için, 4 ay boyunca boş bir fanteziyi ameliyat etmişsinizdir.

Dinlemek Bir Mühendislik Refleksidir

İyi bir mühendis olmak, sadece kod sözdizimini (syntax) ezbere bilmek veya en yeni framework'leri kullanmak değildir. İyi bir mühendislik, karşınızdaki insanın karmaşık, çelişkili ve panik dolu ifadelerinin arkasındaki gerçek patolojiyi çekip çıkarabilme sanatıdır.

Müşteriniz ya da yöneticiniz size bir problemle geldiğinde; klavyeye sarılmadan önce arkanıza yaslanın.
Onun heyecanını ve korkusunu sakinleştirin.
Reçeteyi onun yazmasına izin vermeyin.

Doğru soruları sorun. Belirtilerin kökenine inin.
Çünkü doğru konulmuş bir teşhis, yazılacak binlerce satır gereksiz koddan çok daha kıymetlidir.

Hastanın başında durursunuz. Monitördeki yeşil dalgalar yavaşlamaya başlar: Kalp hızı 90'dan 50'ye, 40'a iner. Parmaktaki oksimetre probu önce %98 gösterirken, birden %75'e, oradan %60'a çakılır. Tansiyon manşonu şişer şişer ve cihaz ekrana bir rakam yazamaz; çünkü ölçülecek bir nabız basıncı kalmamıştır.

O an odadaki sesler kesilir. Zaman yavaşlar. Havadaki o yoğun metalik adrenalin kokusunu hissedersiniz. Çünkü bilirsiniz ki, birkaç saniye sonra o ritim tamamen düz bir çizgiye (Asistol) dönüşecek ve karşınızdaki insan avuçlarınızın arasından kayıp gidecektir.

O saniyelerde panikleyen bir sağlıkçı ne yapar? Sağa sola koşuşturur, anlamsızca bağırır, monitörün kablolarını çekiştirir ve altın değerindeki o son saniyeleri tüketir.
Oysa soğukkanlı bir profesyonel tek bir şey yapar: Derin bir nefes alır, gürültüyü zihninde susturur ve tıbbın en temel alfabesine döner: ABC (Airway - Breathing - Circulation). Hava yolunu aç, solut, kalbe kan pompala. Teferruatları unut, hastayı temel fonksiyonlarıyla hayatta tut.

Şimdi bu sahneyi donduralım ve yazılım dünyasının en karanlık bodrum katına inelim.

10 Yıllık Kodun Karşısında Çaresizlik

Şirkette sıradan bir Perşembe öğleden sonrasıdır. Yönetimden acil bir talep gelir: "Şirketin ana faturalandırmasını ve muhasebe entegrasyonunu yöneten eski bir servisimiz var. Gelir İdaresi Başkanlığı yeni bir regülasyon getirdi, bu servise küçük bir alan eklememiz lazım."

Depoya (repository) girersiniz. Son commit tarihi: 4 yıl önce.
Yazan mühendisler çoktan yurt dışına gitmiş. Dokümantasyon yok. README dosyası sadece projenin adını içeriyor. Hangi Node.js veya Python sürümünde çalıştığı belli değil.

Projeyi yerel bilgisayarınıza klonlarsınız ve o masum komutu yazarsınız:
npm install (veya docker-compose up)

Ve terminal bir anda kan gölüne döner.

Yüzlerce satır kırmızı hata, birbirini tutmayan bağımlılıklar, Python 2.7 uyumsuzlukları, artık internette var olmayan silinmiş npm paketleri, patlayan C++ derleyici modülleri... Ekran aşağı doğru deliler gibi kayar.

Daha kötüsü; test amacıyla dokunduğunuz o servis canlı ortamda (production) bir anda kilitlenir. Sağlık kontrolü (health-check) endpoint'i 500 Internal Server Error dönmeye başlar. CPU kullanımı %100'e fırlar, kuyrukta bekleyen binlerce fatura birikmeye başlar ve müşteri hizmetleri telefonları çalmaya başlar.

Sistemin nabzı durmuştur. Vital bulgular gitmiştir. Terminalin başında otururken avuçlarınızın içinin terlediğini, kalbinizin kulaklarınızda attığını hissedersiniz. İşte o an, sunucu odasındaki yoğun bakım anıdır.

Panik vs. Cerrahi Soğukkanlılık

Böyle bir krizde acemi bir yazılımcının refleksi; StackOverflow'dan bulduğu rastgele komutları ardı ardına terminale yapıştırmaktır:
npm install --force, sudo chmod -R 777, veritabanını rastgele restart etmek, konfigürasyon dosyalarını körlemesine değiştirmek...

Bu, kalbi duran hastanın göğsüne yumruk atıp rastgele ilaçlar enjekte etmekten farksızdır. Hastayı kurtarmaz; kalan son hücreleri de öldürürsünüz.

Legacy bir krizin son dakikalarında hayatta kalmak istiyorsanız, tıpkı ambulansta olduğu gibi temel reflekslere dönmek zorundasınız:

1. Kanamayı Durdur (Isolate & Freeze): Yeni paket kurmayı, versiyon yükseltmeyi veya sistemi "iyileştirmeyi" derhal bırakın. Sorunu çözmeye çalışırken daha büyük bir enkaz yaratıyorsunuz. Sistemi dış dünyadan izole edin; gelen istekleri geçici bir kuyruğa veya bakım sayfasına yönlendirin.
2. Hava Yolunu Aç (Restore Minimum Runtime): Sistemin 4 yıl önceki orijinal çalışma ortamını simüle edin. O kod hangi Linux çekirdeğinde, hangi dil sürümünde derlenmişti? Eğer elinizde eski bir container image'ı veya snapshot varsa, hemen ona dönün. Yeni dünyayı eski koda dayatamazsınız.
3. Dolaşımı Sağla (Core Function Only): Servisin 50 farklı özelliği olabilir; ama o an şirketi hayatta tutan tek bir kritik fonksiyon vardır (mesela sadece faturayı kesip veritabanına yazmak). Gerekirse bildirim servislerini, istatistik loglarını ve yan eklentileri devreden çıkarın. Bırakın hasta sadece nefes alsın.

Monitörün Yeşile Dönüşü

Yoğun bakımda bir hastayı hayata döndürdüğünüz o ilk anı asla unutamazsınız. Göğüs kompresyonunu durdurursunuz, boyundaki şah damarına (karotis) parmaklarınızı koyarsınız ve o minik, zayıf ama ritmik vuruşu hissedersiniz: Küt... Küt... Küt...
Monitördeki düz çizgi yeniden sinüs dalgalarına dönüşür. Odanın içindeki o ölümcül soğukluk dağılır.

Legacy bir sistemi sabaha karşı saat 04:30'da ayağa kaldırdığınız an da böyledir.
Terminalde o kırmızı hatalar diner. Log dosyasında ilk başarılı istek görünür:
INFO: Worker process started. Listening on port 8080. [200 OK]

Gözleriniz kan çanağına dönmüştür, kahveniz saatler önce soğumuştur, sırtınız taş gibi kesilmiştir. Ama o an bilirsiniz ki, bir organizma daha sizin ellerinizde hayata tutunmuştur.

Kodlar sadece harflerden ve sayılardan ibaret değildir. Kodlar, arkasında binlerce insanın emeğini, ticaretini, iletişimini ve bazen hayatını taşıyan yaşayan sistemlerdir.

Ve o sistemlerin nabzı düştüğünde; ihtiyacınız olan tek şey süslü teoriler değil, ölümün karşısında dimdik durabilecek o sakin, sarsılmaz mühendislik disiplinidir.

Yıllar sonra bir ambulans istasyonunda 24 saatlik nöbet tutarken, kendimin Pavlov'un köpeklerinden hiçbir farkım olmadığını çok sert bir biçimde anladım.

112 istasyonunun dinlenme odasında, gece saat 03:00'te ranzaya uzanmışsınızdır. Bedeniniz yorgunluktan dökülüyordur, gözleriniz kapanır. Tam derin uykuya dalacağınız o saniyede, tavandaki hoparlörden o mekanik, madeni anons sesi patlar:
Dıt-dıt-dıt... "İstasyon 4, vaka var. Trafik kazası, çıkış yapın!"

O ses kulağınıza ulaştığı mikrosaniyelik anda; daha beyniniz bilincinizi açamadan, nerede olduğunuzu idrak edemeden otonom sinir sisteminiz devreye girer:
Göz bebekleriniz büyür. Nabzınız anında 60'tan 140'a fırlar. Midenize buz gibi bir yumruk iner, damarlarınıza yoğun bir kortizol ve adrenalin banyosu boşalır. Yataktan bir yay gibi fırlar, pantolonunuzu çekerken merdivenlerden ambulansa doğru koşmaya başlarsınız.

İşin en korkunç tarafı nedir biliyor musunuz?
Nöbetiniz bittikten sonra, hatta mesleğe ara verdiğiniz sivil bir günde bile; sokakta bir kafede kahve içerken yan caddeden geçen bir ambulansın o tanıdık siren sesini duyduğunuz an, elinizdeki kahve fincanı titrer. Beyniniz artık şartlanmıştır. O ses felakettir, o ses krizdir, o ses can pazarıdır.

Peki, laptoplarının başında "evden çalışan", klavye başındaki steril yazılımcıların sinir sistemi bu cehennemden muaf mıdır?

Gece 03:20: PagerDuty'nin Kan Donduran Melodisi

DevOps dünyasında veya yüksek trafikli sistemler yöneten şirketlerde çalışan herkes "On-Call" (Nöbetçilik) kavramını çok iyi bilir. Şirketin sistemleri 7/24 ayakta kalmalıdır ve bir mühendis her hafta o "nöbet meşalesini" devralır.

Telefonunuzun başucunda durduğu o geceyi düşünün.
Saat 03:20. PagerDuty'nin veya Opsgenie'nin o meşhur, tiz, insanın sinir uçlarını rendeleyen alarm melodisi çalmaya başlar:
Trrrt-trrrt-trrrt! "CRITICAL: Payment Gateway latency > 5000ms. Error rate %84."

O an yatağın içinde yaşadığınız biyolojik tepki; ambulans istasyonunda ranzadan fırlayan bir paramediğin yaşadığı tepkiyle atomlarına kadar aynıdır.

Kalp çarpıntısı, boğazda kuruluk, soğuk bir ter tabakası ve o tarifsiz dehşet hissi... Bilgisayarın kapağını açarken parmaklarınız titrer. SSH şifrenizi üç kez yanlış yazarsınız. Slack kanalındaki o kırmızı acil durum etiketlerini (incident) okurken beyniniz adeta yanar.

Ve bunu haftalarca, aylarca yaşarsınız.

Sonunda ne olur? Şartlanma tamamlanır. Artık gündüz vakti telefonunuza gelen sıradan bir WhatsApp bildirimi, hatta Slack'in o masum "tok" sesi bile sizde hafif bir taşikardi ve irkilme yaratmaya başlar.

Hayalet Bildirimler ve Alarm Yorgunluğu (Alert Fatigue)

Bu şartlanmanın ikinci aşaması, tıpta uzuv kaybı yaşayanların hissettiği o hayalet ağrılar gibidir: Hayalet Bildirim Sendromu (Phantom Vibration Syndrome).

Duşta suyun sesini dinlerken telefonun çaldığını sanırsınız. Markette alışveriş yaparken cebinizdeki telefon titrememiş olmasına rağmen eliniz panikle cebinize gider. Beyniniz artık sürekli bir kriz beklentisi (Hypervigilance) içindedir. Asla tam olarak dinlenemez, asla gardını indiremezsiniz. Çünkü bilinçaltınız bilir ki, o zil her an çalabilir ve dünya her an başınıza yıkılabilir.

Daha kötüsü, zamanla Alarm Yorgunluğu (Alert Fatigue) başlar.

Sistemler o kadar kötü kurgulanmıştır ki, gecede 40 tane önemsiz alarm (false positive) gelir: Disk doluluğu %81 oldu, CPU 10 saniyeliğine yükseldi, önemsiz bir mikroservis yeniden başladı... Tıpkı gereksiz yere öten yangın alarmları gibi, bir süre sonra insan beyni kendini korumak için hissizleşir.

Ve o kaçınılmaz gün gelir: Gerçek bir felaket yaşandığında, yorgun düşmüş ve hissizleşmiş olan mühendis o bildirimi duymaz veya erteleye (snooze) basar. Sistem tamamen çöker.

Tükenmişliği Romantize Etmeyi Bırakın

Teknoloji şirketlerinin kariyer sayfalarında "Hızlı tempolu ortam", "Yüksek sahiplenme duygusu", "Esnek çalışma" gibi süslü laflarla pazarlanan şey; aslında çalışanların sinir sistemlerinin acımasızca sömürülmesidir.

Bir insanın 24 saat boyunca bir zil sesine şartlanmış halde, alarm tetikte yaşaması insan biyolojisine aykırıdır. İnsan bedeni, sürekli bir tehdit altında yaşamak için tasarlanmamıştır. Kronik kortizol salgısı uykunuzu çalar, bağışıklığınızı çökertir, hafızanızı zayıflatır ve sonunda sizi bir enkaz olarak bırakır.

Ambulansta öğrendiğim en değerli kural şuydu: Nöbet bittiğinde telsizi teslim edersin ve o kapıdan çıkar gidersin. Telsizi eve götürmezsin.

Yazılımda da aynı disiplini kurmak zorundasınız.
Nöbetiniz bittiğinde o bildirimleri kapatabilmelisiniz.
Şirketlerin, geceleri mühendisleri uyandırmayan self-healing (kendi kendini onaran) mimarilere yatırım yapmasını talep etmelisiniz.
Ve en önemlisi; ekran başında sabahlamayı bir "kahramanlık madalyası" gibi görmeyi bırakmalısınız.

Çünkü Pavlov'un köpeği o deneyin sonunda sadece bir parça et alıyordu.
Siz ise tükenmiş bir sinir sistemi ve yıpranmış bir kalpten başka hiçbir şey kazanamazsınız.

Ekranda yeşil bir ışık çizgisi soldan sağa doğru akar. Önce küçük bir tepe (P dalgası), ardından keskin ve yüksek bir sıçrama (QRS kompleksi), sonra yumuşak bir iniş (T dalgası) ve kısa bir düzlük. Ve bu döngü; dakikada 70 kez, saatte 4 bin 200 kez, günde 100 bin kez, hiçbir sürprize yer bırakmadan, milisaniyelik bir intizamla kendini tekrar eder.

Tıpta buna Normal Sinüs Ritmi denir.

Bu ritim acımasızca sıkıcıdır. İçinde hiçbir sanatsal sürpriz, hiçbir beklenmedik iniş çıkış, hiçbir drama yoktur. Tamamen monoton, öngörülebilir ve mekanik bir tekrardır.

Peki, bir EKG monitöründe heyecan ve aksiyon ne zaman başlar biliyor musunuz?
Kalp ritmi bozulduğunda. Çizgiler deliler gibi savrulmaya başladığında (Ventriküler Fibrilasyon), dalgalar sivrilip kontrolden çıktığında (Taşikardi) veya o çizgi tamamen dümdüz olup tiz bir alarm sesi odayı inlettiğinde (Asistol).

Monitörde dramanın, sürprizin ve adrenalin patlamasının olduğu an; bir insanın ölmekte olduğu andır.
Monotonluk ise hayatta olmanın, organların uyum içinde çalışmasının ve sağlığın yegane kanıtıdır.

Şimdi bu biyolojik gerçeği alın ve modern teknoloji dünyasının, yazılım ekiplerinin ve kariyer hedeflerimizin tam ortasına koyun.

Yazılım Dünyasının Tehlikeli Heyecan Bağımlılığı

Teknoloji sektörü, özellikle de yeni nesil start-up kültürü, hastalıklı bir "aksiyon ve kaos bağımlılığı" ile maluldür.

LinkedIn'deki gönderilere, teknoloji bloglarına ve konferans konuşmalarına bakın. Herkes kriz çözme kahramanlıklarını anlatır: "Black Friday'de 10 milyon isteği nasıl karşıladık?", "Gece 04:00'te çöken Kubernetes kümesini nasıl kurtardık?", "Tüm mimariyi bir gecede Go ile sıfırdan nasıl yazdık?"

Bir şirkette sürekli yangın çıkması, geceleri prod sunucularının patlaması, mühendislerin gözleri kan çanağı halde sabahlara kadar hotfix atması; garip bir şekilde "çalışkanlık" ve "başarı" göstergesi gibi pazarlanır. Şirket içi kahramanlar genellikle o yangını çıkaran kötü mimariyi kuranlar değil; yangın çıktığında itfaiyeci gibi koşanlardır.

Oysa gerçek mühendislik bu değildir.

Gerçek mühendislik; o yangının hiç çıkmamasını sağlayacak kadar sıkıcı, sağlam ve monoton bir sistem inşa edebilmektir.

İyi tasarlanmış bir yazılım altyapısı tıpkı o sağlıklı sinüs ritmi gibidir:

• Dağıtımlar (deployment) Salı sabahı saat 10'da, kimsenin tansiyonu yükselmeden, tek bir tuşla yapılır.
• Veritabanı CPU kullanımı %30 civarında sakin sakin dalgalanır.
• Yedekler (backup) gece yarısı sessizce alınır ve doğrulanır.
• Log dosyalarında kırmızı satırlar uçuşmaz; sadece düzenli, ritmik ve yeşil akışlar vardır.
• Nöbetçi mühendis gece mışıl mışıl uyur.

Ve ne yazık ki, sektördeki bazı toy mühendisler ve vizyonsuz yöneticiler bu huzuru "tembellik" veya "gelişmemek" zanneder.

Çalışan Kodu Dürtme Hastalığı

Mühendislik ekiplerinde sıkça karşılaştığım trajik bir sendrom vardır: Sistem kusursuz, stabil ve monoton bir şekilde çalışıyordur. Ancak ekipteki bazı geliştiriciler sırf sıkıldıkları için, sırf CV'lerine yeni bir teknoloji yazabilmek için çalışan sisteme müdahale etmeye başlar:

"PostgreSQL bize yetiyor ama bunu bir de event-driven yapıp araya Kafka koysak mı?"
"Monolitik uygulamamız tıkır tıkır çalışıyor ama bunu 16 tane mikroservise bölsek daha havalı olmaz mı?"
"Bu kütüphane 5 yıldır sorunsuz çalışıyor, gelin bunu dün GitHub'da gördüğüm deneysel bir Rust framework'ü ile değiştirelim."

Bu tavır; sağlıklı bir kalple, göğsünde kusursuz bir sinüs ritmiyle yaşayan bir insanın göğsünü yarıp, "Şu kalbi biraz kurcalayalım, belki dakikada 200 vurdurursak daha heyecanlı olur" demesiyle aynı zihinsel patolojidir.

Sonuç? Stabil sinüs ritmini bozarsınız; sistemi taşikardiye ve fibrilasyona sokarsınız. Sonra da hafta sonu patlayan servisleri kurtarmak için kahramanlık hikayeleri yazarsınız.

Sıkıcı Olmanın Erdemi

Bir sistemin ya da bir insanın hayatındaki en büyük olgunluk seviyesi, monotonluğun kıymetini bilmektir.

Kariyerinizde her gün yeni bir devrim yapmak, her gün dünyayı kurtarmak zorunda değilsiniz. Büyük ustalık; o sinüs ritmi gibi her gün masaya oturup, temiz kod yazmak, testleri ihmal etmemek, dokümantasyonu güncellemek ve iş arkadaşlarına karşı sabırlı ve tutarlı olabilmektir. Bu sıkıcı disiplin, uzun vadede bütün o parlak ve gürültülü hevesleri ezer geçer.

Dan Geer'in ünlü bir siber güvenlik aforizması vardır:
"Eğer bir sistem mükemmel çalışıyorsa, kimse onun çalıştığını fark etmez bile."

Bir dahaki sefere monitörünüze baktığınızda, sunucularınızın sorunsuz çalıştığı ve hiçbir Slack alarmının çalmadığı o sakin, sessiz günlerde içinizden "Bugün de hiçbir aksiyon yok, ne kadar sıkıcı bir gün" diye geçirirseniz; o yeşil EKG çizgisini hatırlayın.

Heyecanın ve aksiyonun tavan yaptığı yer acil serviste travma odası, yazılımda ise prod çöküşüdür.
Monotonluk ise sisteminizin yaşadığının, kalbinizin sağlıklı attığının ve her şeyin yolunda olduğunun en kutsal belgesidir.

Normal fizyolojide insan kanındaki oksijen doygunluğu (SpO2) %95'in altına indiğinde beden hemen alarm verir; %85'in altına indiğinde ise nefes darlığından boğuluyormuş gibi çırpınır, panikler ve soluk soluğa kalırsınız. Çünkü kandaki karbondioksit birikir ve beyin göğüs kaslarına çılgınca "Daha hızlı nefes al!" emri gönderir.

Ancak bu sessiz hipoksi vakalarında bambaşka bir kabus yaşanıyordu.
Ambulansla hastanın evine gidiyordunuz; hasta yatağında oturmuş, elinde telefonuyla sosyal medyada geziniyor, sizinle gayet sakin bir ses tonuyla sohbet ediyordu: "Biraz halsizliğim var o kadar, nefes darlığım yok."
Sonra parmağına nabız oksimetresini takıyordunuz. Cihazın ekranında beliren rakam kanınızı donduruyordu: %68.

Tıbben %68 oksijen seviyesi, bir insanın bilincini kaybedip komaya girmesi gereken bir ölüm eşiğidir. Ama hastanın beyni o alarmı çalmıyordu. Beden çığlık atmıyordu. Ve o sakin sakin konuşan hasta, 15 dakika sonra ambulansın içinde aniden solunum arrestine giriyor, morarıyor ve kalbi duruyordu.

Sessiz hipoksi tıbbın en tehlikeli katilidir; çünkü semptomsuz bir çöküştür.

Peki, yazılım sistemlerindeki bug'ları düşündüğünüzde; sizi en çok korkutması gereken şey nedir?

Kırmızı Hatalar Sizin Dostunuzdur

Geliştiricilerin çoğu, terminalde veya monitoring ekranlarında kırmızı renkli devasa hata logları gördüğünde strese girer:
Fatal Error: NullPointerException, HTTP 500 Internal Server Error, Database connection refused...

Oysa gerçek bir sistem mühendisi bilir ki, bağıran hata dürüst bir hatadır.

Kırmızı log fırlatan, sistemi anında durduran veya kullanıcıya açıkça "İşleminiz yapılamadı" diyen bir bug; göğsü sıkışan ve acıdan bağıran bir hasta gibidir. Sorunun nerede olduğunu anında bilirsiniz. Sentry alarmı çalar, Slack kanalına bildirim düşer, nöbetçi mühendis uyanır ve o hatayı yarım saat içinde düzeltir. Hasar anlıktır, görünürdür ve sınırlıdır.

Yazılım dünyasının asıl ölümcül kanseri ise "Silent Bug" (Sessiz Hatalar) dediğimiz, arkasında hiçbir kırmızı log bırakmayan o sinsi anomalilerdir.

Sessiz Katilin Anatomisi: Hata Yutma (Swallowed Errors)

Sessiz hataların en yaygın üreme alanı, acemi veya tembel geliştiricilerin yazdığı o meşhur kod bloklarıdır:

try {
  processPaymentAndInvoice(user, cart);
} catch (error) {
  // TODO: Burayı sonra loglayalım
  return { status: 200, success: true };
}

Bu kod parçası, yazılım mimarisine enjekte edilmiş saf bir sessiz hipoksidir.
Ödeme işlemi patlamıştır, veritabanına fatura yazılamamıştır, üçüncü parti API zaman aşımına uğramıştır. Ama sistem hiçbir hata fırlatmaz. HTTP cevabı olarak güleç bir yüzle 200 OK döner. Monitoring araçlarınız (Datadog, Grafana) masmavidir; CPU düşüktür, hata oranı sıfırdır, dashboard'unuz "Tüm Sistemler Mükemmel Çalışıyor" der.

Ama arka planda, sessizce kangren büyüyordur.
Kullanıcıdan para çekilmiştir ama sipariş oluşmamıştır. Ya da daha kötüsü, sipariş kargoya verilmiştir ama müşterinin kartından para tahsil edilememiştir.

Ve bu sessiz sızıntı; bir saat, bir gün değil; aylarca devam eder. Ta ki mali yıl sonunda muhasebeciler hesapları kapattığında ve şirketin kasasında 5 milyon liralık bir kara delik açıldığı fark edilene kadar. O gün geldiğinde ne bir log kaydı bulabilirsiniz, ne de o hatanın ne zaman başladığını tespit edebilirsiniz. Sistem ayakta dururken içten içe iflas etmiştir.

Kayan Nokta (Floating Point) ve Sessiz Veri Zehirlenmesi

Sessiz bug'ların bir diğer kabusu, veri bozulmasıdır (data corruption).

Bir e-ticaret veya fintech uygulamasında para birimlerini hesaplarken yanlış veri tipi kullandığınızı düşünün. Decimal veya BigInt yerine standart Float tipi kullanılmıştır. Her işlemde kuruşun binde biri kadar bir yuvarlama sapması oluşuyordur: 0.0001 TL.

Hiçbir sunucu çökmez. Hiçbir kullanıcı şikayet etmez. Hiçbir exception fırlatılmaz. Ama sistem her saniye on binlerce işlem yaptıkça, o binde birler birikir, birikir ve veritabanındaki finansal mutabakat tablolarını zehirler. Bir yıl sonra o veritabanındaki rakamların hiçbiri birbirini tutmaz hale gelir.

Bu, vücutta yavaş yavaş biriken ağır metal zehirlenmesine benzer. Hasta yürümeye devam eder, yemek yer, güler; ama karaciğeri ve böbrekleri hücre hücre ölüyordur.

Sessiz Hipoksiyi Nasıl Teşhis Ederiz?

Sessiz hipoksiden korunmanın tek yolu, hastanın dış görünüşüne güvenmemek ve parmağına o oksimetre probunu takıp kanın gerçek kimyasına (vital verilere) bakmaktır.

Yazılımda da sessiz bug'lardan korunmanın yolu; sadece HTTP 500 hatalarını sayan yüzeysel monitoring araçlarına güvenmeyi bırakmaktır:

1. İş Mantığı Anomalilerini İzleyin (Business Metric Observability): Sadece sunucu sağlığına değil, iş metriklerine bakın. Eğer bir e-ticaret sitesinde saatte ortalama 500 sipariş alınıyorsa ve bu rakam aniden saatte 20'ye düşmüşse; ama sunucularda tek bir hata bile yoksa, ortada sessiz bir hipoksi vardır.
2. Hataları Asla Yutmayın: Bir hata yakalandığında (catch) onu sessizce örtbas etmek, bir cinayete ortak olmaktır. Hata ya güvenli bir şekilde yukarı fırlatılmalı (re-throw) ya da görünür şekilde loglanmalıdır.
3. Veri Bütünlüğü Doğrulamaları (Reconciliation Jobs): Her gece çalışan ve sistemdeki girdiler ile çıktıları matematiksel olarak karşılaştıran sessiz dedektifler (cron job'lar) kurun. Kasadaki para ile veritabanındaki sipariş toplamı tutuyor mu?

Ses çıkaran hata sizi uykunuzdan uyandırır; ona kızmayın, teşekkür edin.
Ama hiçbir ses çıkarmayan, monitörleri yeşil gösterip sistemi içten içe kemiren o sessiz anomalilerden korkun.

Çünkü bir sistemin sessizce ölmesi; bağıra çağıra çökmesinden her zaman bin kat daha maliyetlidir.

Bu cihazlar, biyomedikal mühendisliğin insanlığa sunduğu en muazzam demokratikleşme harikalarından biridir.

Normalde bir defibrilatör; bir paramediğin veya acil hekiminin yıllarca eğitim alarak EKG dalgalarını okuduğu, ventriküler fibrilasyon ile asistolü birbirinden ayırt ettiği, doğru enerji seviyesini (Joule) ayarlayıp pedallarla elektrik akımı verdiği karmaşık ve tehlikeli bir tıbbi silahtır. Yanlış bir ritme şok verirseniz çalışan kalbi durdurabilirsiniz.

Ancak duvarda asılı duran o küçük AED kutusu öyle tasarlanmıştır ki; hayatında hiç tıp kitabı açmamış, ilk yardım eğitimi bile almamış sıradan bir vatandaş kapağı açtığı an, cihaz sakin bir insan sesiyle konuşmaya başlar:
"Sakin olun. Pedleri hastanın çıplak göğsüne şekilde gösterildiği gibi yapıştırın. Hastaya dokunmayın, ritim analiz ediliyor... Şok tavsiye ediliyor. Yanıp sönen turuncu düğmeye basın."

Cihaz kendi içinde EKG analizini yapar, yapay zekasıyla ritmi doğrular, gerekirse elektriği depolar ve tek bir tuşla kalbi duran insanı hayata döndürür. Tıbbi yetkinliği, sıradan insanın parmak uçlarına indirir.

Peki, şimdi gözlerimizi teknoloji dünyasına çevirelim: Low-Code ve No-Code araçları (Webflow, Bubble, Zapier, Retool, Make) tam olarak bu değil midir?

Yazılımın Demokratikleşmesi: Herkes Sistem Kurabilir

Yazılım dünyası uzun yıllar boyunca kapalı bir lonca gibiydi. Basit bir e-ticaret sitesi açmak, bir form doldurup veritabanına kaydetmek veya iki servis arasında veri transferi yapmak için bile aylarca süren yazılım geliştirme süreçlerine, pahalı mühendislere ve karmaşık sunucu kurulumlarına muhtaçtınız.

Bugün ise Bubble veya Webflow ile birkaç gün içinde çalışan bir prototip (MVP) çıkarabiliyorsunuz. Zapier ile tek satır Python/Node.js kodu yazmadan Stripe ödemesini Google Sheets'e bağlayıp oradan müşteriye otomatik e-posta ve fatura gönderebiliyorsunuz. Retool ile şirketinizin iç operasyon panellerini sürükle-bırak yöntemle inşa edebiliyorsunuz.

Tıpkı havaalanında yere yığılan birine AED cihazını takan güvenlik görevlisi gibi; bir pazarlamacı veya bir ürün yöneticisi de hiçbir yazılım eğitimi olmadan çalışan bir dijital mekanizma kurabiliyor.

Bu devrim niteliğinde bir kolaylıktır. Fikirlerin hızla test edilmesini sağlar, geliştirme maliyetlerini sıfırlar ve inovasyonun önündeki bürokratik engelleri yıkar.

Ama madalyonun diğer yüzünde, görmezden gelinen çok tehlikeli bir yanılsama yatar.

Cihaz Şoku Verir Ama Ameliyat Yapamaz

Acil tıpta herkesin çok iyi bildiği bir sınır vardır:
Bir AED cihazı ile ventriküler fibrilasyondaki bir kalbe şok verip hastayı o anlık ölümden döndürebilirsiniz. Bu, hastaneye ulaşana kadar zaman kazandıran muhteşem bir ilk müdahaledir.

Ama o cihaz;

• Hastanın tıkalı koroner damarını açamaz (anjiografi yapamaz),
• Kanda biriken asidozu ve elektrolit dengesizliğini düzeltemez,
• Beyin ödemini engelleyecek medikal tedaviyi uygulayamaz.

Eğer hastanın başına gelen kişi, "Şoku verdik, kalbi çalıştı, artık doktora veya ambulansa gerek yok, kalkıp evine gidebilir" derse; o hasta yarım saat sonra tekrar arrest olur ve bu kez kurtarılamaz. AED bir ameliyathane değildir; bir acil durum köprüsüdür.

Yazılımda da No-Code araçlarıyla inşa edilen sistemler tam olarak bu eşikte duvara toslar.

Bir girişimci No-Code ile ilk 500 kullanıcısını karşılar ve her şey harika görünür. Ancak kullanıcı sayısı 50 bine çıktığında, saniyede yüzlerce eşzamanlı işlem (concurrency) başladığında veya veri tabanı milyonlarca satıra ulaştığında o sevimli görsel bloklar çatırdamaya başlar:

• Zapier kotaları biter ve fatura binlerce dolara fırlar,
• Karmaşık bir iş mantığı (business logic) gerektiğinde sürükle-bırak arayüzü çaresiz kalır,
• Veritabanı sorguları dakikalarca sürer ve sistem kilitlenir,
• Ve en kötüsü, arayüzün arkasındaki güvenlik açıkları (açık bırakılan API anahtarları, yetkilendirmesi yapılmamış veritabanı uçları) şirket için ölümcül bir veri sızıntısına (data breach) dönüşür.

O an anlarsınız ki, No-Code ile bir yazılım şirketi inşa ettiğinizi sanırken; aslında sadece birbirine bantla yapıştırılmış yüzlerce kırılgan plastik borunun üzerinde yürüyormuşsunuzdur.

Otomasyonun Sınırlarını Bilmek

Low-Code / No-Code araçları kesinlikle birer oyuncak veya geçici heves değildir. Onlar, doğru ellerde kullanıldığında şirketlerin aylar sürecek işlerini günlere indiren muazzam kaldıraçlardır.

Ancak kritik ayrım şudur: Bir aracın nasıl kullanılacağını bilmek ile, o aracın arkasında çalışan temel prensipleri kavramak aynı şey değildir.

AED cihazının sesli komutlarını dinleyip düğmeye basmak sizi bir kardiyolog yapmaz.
Webflow'da kutuları sürükleyip bırakmak da sizi bir sistem mimarı yapmaz.

Gerçek bir mühendis; ne zaman No-Code ile hızlı bir ilk müdahale (AED şoku) yapacağını bilir, ama sistem büyüdüğünde ne zaman neşteri eline alıp derin mimari ameliyatına (özel yazılmış servisler, optimize edilmiş veritabanları, güçlü güvenlik mimarisi) geçmesi gerektiğini de çok iyi bilir.

Otomasyon hayat kurtarır; ama sadece sınırlarını ve nerede duracağını bilenlerin ellerinde.

Turnike, acil tıbbın en mucizevi hayat kurtarıcılarından biridir. Hastanın dakikalar içinde kan kaybından ölmesini saniyeler içinde engeller.

Ama turnikeyi sıktığınız an, kıdemli bir paramedik cebinden beyaz bir bant veya kalıcı bir asetat kalemi çıkarır. Turnikenin üzerine ya da doğrudan hastanın alnına devasa harflerle bir şey yazar: T: 14:35 (Uygulama Saati).

Neden mi?

Çünkü turnike bir tedavi değildir. Turnike, hastayı ameliyathaneye yetiştirene kadar zaman kazandıran radikal bir geçici kısıtlamadır. O uzva giden tüm kan akışını durdurmuşsunuzdur. Eğer o turnike hastanın bacağında 2 saatten fazla kalırsa; oksijensiz kalan kas dokusu ölmeye başlar (iskemi), toksinler birikir ve sonunda o bacağı ameliyat masasında kesip ampute etmek zorunda kalırsınız. Hatta turnikeyi kontrolsüzce aniden gevşetirseniz, biriken o zehirli asitli kan kalbe hücum eder ve hastayı saniyeler içinde öldürür (turnike şoku).

Turnike hayat kurtarır; ama bir insanı sonsuza kadar turnikeyle yaşatamazsınız.

Peki yazılım dünyasında, özellikle kriz anlarında nasıl "mühendislik" yapıyoruz?

Sunucuyu Her Gece Yeniden Başlatan Cron Job

Yazılım sektöründe adına "Hotfix" veya "Geçici Çözüm" (Band-Aid Fix) dediğimiz şey, sahada attığımız o acil turnikeden farksızdır.

Canlı ortamda (production) bir bellek sızıntısı (memory leak) başlar. Node.js veya Java servisi her 12 saatte bir RAM'i sonuna kadar tüketip kilitleniyordur. Gece saat 03:00'te uyanan mühendis panikle problemi çözmeye çalışır. Kök nedeni bulacak vakit yoktur; çünkü müşteriler kapıdadır.

Hemen bir geçici çözüm bulunur:
Sunucuya bir cron job eklenir: 0 4 * * * systemctl restart api-service
(Her gece saat 04:00'te servisi yeniden başlat.)

Hizmet yeniden ayağa kalkar, bellek temizlenir, Slack'teki kriz kanalı rahat bir nefes alır: "Tamam, sorunu çözdük."

Hayır, sorunu çözmediniz. Siz sadece kanayan damara turnike sıktınız.

Ve asıl felaket tam bu noktada başlar: O cron job, sistemin içinde unutulur. Jira tahtasında açılan o "Memory leak kök nedenini araştır" bileti, bir sonraki sprint'e, oradan diğer sprint'e ertelenir. Çünkü ürün yöneticisi der ki: "Nasılsa sistem çalışıyor, geceleri restart atıyoruz, şimdi önceliğimiz müşteriye yeni raporlama sayfasını yetiştirmek."

Ve o bacak, üzerinde turnikeyle aylarca, hatta yıllarca yürütülmeye çalışılır.

Turnike Çöplüğüne Dönen Mimariler

Zamanla şirketlerin kod tabanları adeta birer savaş gazisi hastanesine döner. Her köşe başında geçici bir bant, her fonksiyonda acil atılmış bir turnike görürsünüz:

• Veritabanı sorgusu kilitlendiği için sorgu süresi limitini (query timeout) 5 saniyeden 60 saniyeye çekip sorunu halının altına süpürenler,
• Patlayan bir API endpoint'ini bulup düzeltmek yerine, önüne bir try/catch koyup kullanıcıya sessizce boş dizi [] dönenler,
• İki servis arasındaki senkronizasyon hatasını çözmek yerine, kuyruğa mesajı 5 kez tekrar gönderen (retry loop) agresif döngüler kurup veritabanını boğanlar...

Bu çözümlerin hepsi kriz anında kabul edilebilir turnikelerdir. O gece için hayat kurtarmışlardır.

Ama onları kalıcı tedavi zannettiğiniz gün, mühendislik namusunuzu kaybetmişsiniz demektir. Bir sistemin her yerine turnike sıktığınızda; bir süre sonra dokular oksijensiz kalır. Yeni bir özellik eklemek imkânsız hale gelir; çünkü her köşe başındaki geçici yama, diğer geçici yamayla çatışmaya başlar.

Ve sonunda, basit bir bellek sızıntısını zamanında ameliyat etmediğiniz için, tüm mimariyi çöpe atıp sıfırdan yazmak zorunda kalırsınız. Tıpkı zamanında açılmayan turnike yüzünden bacağın ampute edilmesi gibi.

Turnikenin Üzerine Saat Yazmak

Gerçek bir profesyonel, kriz anında geçici yama yapmaktan utanmaz. Pragmatizm bunu gerektirir; yangın anında önce alevi söndürürsünüz, binanın yalıtımını sonra tartışırsınız.

Ancak gerçek bir mühendis ile günü kurtaran bir teknisyen arasındaki fark şudur:
Gerçek mühendis, attığı her hotfix'in üzerine o saati yazar.

Eğer bir gece yarısı acil bir yama (turnike) attıysanız;

1. Ertesi sabah o yamanın üzerine kırmızı bir uyarı koyarsınız: // TEMPORARY HOTFIX: Ticket #4821 - Kök neden çözülene kadar geçici bypass.
2. İlk sprint planlamasında masaya vurur ve o teknik borcun kalıcı ameliyatını planlatırsınız.
3. Kanamayı durduran geçici yamayı, sistemin kalıcı bir organı gibi benimsemezsiniz.

Turnikeyle koşamazsınız. Turnikeyle maraton tamamlayamazsınız.

Kanamayı durdurduktan sonra hastayı ameliyathaneye alacak cesaretiniz ve disiplininiz yoksa; yaptığınız şey mühendislik değil, sadece yavaşlatılmış bir intihardır.

Tarihin karanlık çağlarında cerrahlar hastaların kafasına tahta tokmakla vurur, yüksek dozda alkol içirir veya birkaç güçlü adamla kollarını bacaklarını masaya bağlayıp ameliyat yapardı. O ilkel yöntemler bedende devasa bir şok, yırtılan kaslar ve çoğu zaman ameliyat masasından kalkamayan kalpler bırakırdı.

Oysa modern anesteziyoloji bir tıp bilimi olduğu kadar, insan bedeninin sınırlarına duyulan en zarif nezaket sanatıdır.

Anestezi uzmanı hastanın başına geçer. Asla tek bir şırıngayla hastayı aniden bayıltmaz. Süreç kusursuz bir koreografiyle basamaklandırılmıştır:
Önce hastanın ciğerleri saf oksijenle doldurulur (Pre-oksijenasyon). Ardından damardan hafif bir sakinleştirici (sedatif) verilir; zihin sakinleşir. Sonra hipnotik bir ilaçla (Propofol) bilinç yavaşça uykuya daldırılır. Hemen ardından kas gevşetici verilir; hastanın kendi solunumu durduğu o mikrosaniyede soluk borusuna entübasyon tüpü yerleştirilir ve mekanik ventilatör nefes aldırmaya başlar.

Beden sarsılmaz. Kalp ritmi bozulmaz. Beyin bir travma yaşamaz. Canlı bir organizma, hücre hücre, adım adım ve kontrollü bir şekilde uyku moduna geçirilir.

Ameliyat bittiğinde de aynı zarafetle uyanma süreci başlar. İlaçlar kesilir, reflekslerin geri gelmesi beklenir, akciğerler kendi nefesini almaya başladığında tüp çekilir.

Peki, yazılım dünyasında sunucularımızı, mikroservislerimizi veya container'larımızı kapatırken ne yapıyoruz?

kill -9: Sistemin Kafasına Tokmakla Vurmak

Yazılım dünyasının en vahşi, en kaba ve en barbar komutunu hepimiz biliriz:
kill -9 <PID> (SIGKILL)

Bu komut işletim sistemine şunu söyler: "Bu sürecin ne yaptığı umurumda değil. Bellekte ne tuttuğuna bakma, nereye ne yazdığını sorma. Hemen şimdi, bu milisaniyede kafasına sık ve yok et!"

Yeni bir deployment çıktığında, Kubernetes pod'larını güncellerken veya sunucuyu yeniden başlatırken kötü kurgulanmış mimarilerin yaptığı tam olarak budur.

Eski container'a aniden ölüm sinyali gönderilir. O sırada ne oluyordur biliyor musunuz?

• Bir kullanıcı tam kredi kartı bilgilerini girmiş, "Öde" butonuna basmıştır; ödeme API'si bankaya isteği göndermiş ama cevabı veritabanına yazamadan sunucunun fişi çekilmiştir. Kullanıcının kartından para düşer ama sipariş oluşmaz.
• Veritabanına 100 bin satırlık kritik bir tablo indeksi yazılıyordur; işlem yarıda kalır ve veritabanı kilitlenir.
• Arka planda bir kuyruktan (Kafka, RabbitMQ) çekilen mesaj işlenirken süreç ölür; mesaj arafta kalır ve kaybolur.
• Kullanıcıların tarayıcılarına o meşhur, çirkin hata fırlar: 502 Bad Gateway.

Bu mühendislik değildir. Bu, ameliyathanede hastanın fişini aniden prizden çekip "Yeni makineyi takıyoruz, idare edin" demekle aynı ilkelliktir.

Graceful Shutdown: Dijital Anestezi

İşte bu barbarlığı engelleyen mimari prensibe bilgisayar bilimlerinde "Graceful Shutdown" (Nazikçe / Hasarsız Kapatma) denir.

Graceful Shutdown, işletim sisteminin sürece gönderdiği SIGTERM (Sonlandırma İsteği) sinyalini bir anestezi protokolü gibi karşılamak demektir:

1. Yeni Hasta Alımını Durdur (Stop Ingress): Servis SIGTERM sinyalini aldığı an, önce Load Balancer'a veya Service Mesh'e haber verir: "Ben uykuya geçiyorum, artık bana yeni HTTP isteği gönderme." Sağlık kontrolü (health-check) endpoint'i kendini pasife çeker. Trafik diğer sağlıklı sunuculara akar.
2. Masadaki Ameliyatları Bitir (Drain In-Flight Requests): O an içeride işlem görmekte olan mevcut isteklere bir süre tanınır (örneğin 15-30 saniye). Kullanıcının devam eden ödemesi tamamlanır, veritabanına son onay yazılır ve kullanıcıya 200 OK cevabı dönülür. Hiçbir müşteri kapıda bırakılmaz.
3. Organları Sırayla Devreden Çıkar (Close Connections): İşlemler bittikten sonra açık olan veritabanı bağlantı havuzları (connection pools), Redis soketleri, Kafka dinleyicileri ve dosya tanıtıcıları (file descriptors) temizce kapatılır. Bellekteki kirli veriler diske yazılır.
4. Huzur İçinde Uyu (exit 0): Ve nihayet, içeride tek bir açık işlem bile kalmadığında süreç işletim sistemine döner ve "Ben işimi temizce bitirdim, şimdi beni kapatabilirsin" diyerek huzurla kapanır.

Kullanıcı bu deployment sırasında ne hisseder?
Hiçbir şey. Tek bir milisaniyelik kesinti, tek bir hatalı istek, tek bir 502 görmez. Sistem nefes almaya devam eder.

Kapatma Şekliniz Mühendislik Kalitenizdir

Bir yazılımcının yetkinliğini anlamak istiyorsanız, bir servisi nasıl ayağa kaldırdığına değil; o servisi nasıl kapattığına bakın.

Bir sistemi başlatmak kolaydır: npm start yazarsınız, portu dinlersiniz ve her şey çalışır. Ama o sistemi kriz anında, yüksek yük altındayken veya rutin bir güncelleme sırasında tek bir kullanıcının canını yakmadan, tek bir veri baytını kaybetmeden uyutabilmek derin bir mimari olgunluk gerektirir.

Bedenimiz doğanın en kusursuz graceful shutdown mekanizmasıyla donatılmıştır. Her gece uykuya dalarken organlarımız adım adım rölantiye geçer; sabah uyanırken hormonlarımız adım adım bizi hayata hazırlar.

Kodlarınızı tokmakla bayıltmayı bırakın.
Sistemlerinize bir anestezi uzmanının titizliğiyle yaklaşın.

Çünkü gerçek ustalık; sadece görkemli binalar inşa etmekte değil, o binanın ışıklarını kimseyi karanlıkta bırakmadan söndürebilme nezaketindedir.

Bir acil tıp hekiminin önüne karmaşık, göğüs ağrısıyla birlikte atipik EKG bulguları olan ve bilinen böbrek yetmezliği bulunan bir hasta geldiğinde; hekim asla kapıyı kapatıp "Ben 6 yıl tıp okudum, uzmanlığımı aldım, her şeyi tek başıma çözebilirim. Başka bir doktora sorarsam yetersiz olduğumu düşünürler" demez.

Bunu diyen bir hekim bir dahi değil; hastasını mezara göndermeye hazırlanan tehlikeli bir narsisttir.

Hekim hiç vakit kaybetmeden telefonu kaldırır, nöbetçi kardiyoloğu ve nefroloğu arar. Hastanın bulgularını özetler ve çok net bir soru sorar: "Bu EKG'deki dalga formunu ve potasyum yüksekliğini nasıl yorumluyorsunuz? Sizin uzmanlık alanınızdan bir gözle bakabilir misiniz?"

Tıpta Konsültasyon, asla bir acziyet veya bilgisizlik göstergesi değildir. Tam aksine, tıp etiğinin en kutsal kuralıdır: Kendi bilgi ve algı sınırlarının farkında olmak ve hastanın hayatını kişisel egonun üzerinde tutmak.

Peki, aynı sahneyi modern bir yazılım ofisinde veya uzaktan çalışan bir mühendislik ekibinde canlandıralım. Ne görüyoruz?

8 Saat Boyunca Aynı Koda Boş Boş Bakmak

Yazılım sektörünün ofislerinde her gün sessiz, trajik ve inanılmaz derecede maliyetli bir gurur tiyatrosu sahnelenir.

Bir geliştirici karmaşık bir bug ile karşılaşır. Belki bir veritabanı kilitlenmesi, belki garip bir CSS taşması, belki de bir asenkron yarış durumu (race condition). Saat sabah 10:00'dur. Mühendis kodun başına oturur. Bir şey dener, olmaz. Başka bir şey dener, yine patlar.

Saat 13:00 olur. Gözleri kan çanağına dönmüştür.
Saat 16:00 olur. Aynı üç satırlık fonksiyona ellinci kez bakar. Zihni artık felç olmuştur; tünel vizyonuna (tunnel vision) girmiştir, beyni artık harfleri bile ayırt edemiyordur.

Ama yan masada oturan veya Slack'te "aktif" görünen kıdemli çalışma arkadaşına dönüp şu iki kelimeyi bir türlü söyleyemez:
"Ben burada tıkandım. Bir 10 dakikan var mı, birlikte bakabilir miyiz?"

Neden söyleyemez biliyor musunuz?
Çünkü bu sektör zehirli bir "Tek Başına Dünyayı Kurtaran 10x Rockstar Geliştirici" mitosuyla büyütülmüştür. Yardım istemek zayıflık gibi kodlanmıştır. Birine "Ben bunu çözemedim" demek; sahtekar sendromunu (imposter syndrome) tetikleyen, "Acaba benim yetersiz olduğumu mu düşünürler?" korkusunu körükleyen bir tabudur.

Ve o mühendis gününü heba eder. Şirketin binlerce liralık mesaisini yakar. Kendi psikolojisini paramparça eder.

Sonra ne olur?
Akşam saat 18:30'da masanın yanından geçen biri ekrana şöyle bir bakar ve der ki: "Kanka, 42. satırda değişken ismini yanlış yazmışsın, 'user_id' yerine 'userId' yazıyor."

Sekiz saatlik o devasa dram, ikinci bir çift gözün 5 saniyelik bakışıyla buharlaşır gider.

Bilişsel Körlük ve İkinci Bir Beynin Gücü

İnsan beyni, kendi yazdığı bir metindeki veya kodundaki mantık hatasını görmemek üzere evrimleşmiştir. Bir problemi saatlerce düşündüğünüzde, beyniniz artık gerçekte yazan şeyi değil; yazdığını sandığı şeyi görmeye başlar. Buna bilişsel körlük denir.

Tıpta bir cerrahın konsültasyon istemesinin sebebi de budur. Cerrah ameliyat masasındaki dokuya o kadar odaklanmıştır ki, hastanın anestezi monitöründeki ince bir detayı kaçırabilir. Kenarda duran ikinci bir uzmanın "Hocam tansiyon düşüyor" uyarısı hayat kurtarır.

Yazılımda konsültasyon istemek; zayıflık değil, sisteminizi bu bilişsel körlükten kurtaracak bir güvenlik sigortasıdır:

• Ego Değil, Problem Odaklılık: Masadaki asıl hedef sizin ne kadar zeki olduğunuzu kanıtlamak değildir; o biletin (task) çözülüp şirketin değer üretmesidir.
• Pair Programming (Eşli Programlama): İki mühendisin tek bir ekrana bakması "iki kat maliyet" değildir; 8 saatlik körlüğü 15 dakikaya indiren devasa bir verimlilik kaldıracıdır.
• "Bilemedim" Diyebilme Özgürlüğü: Bir ekipte junior'ından senior'ına kadar herkes "Ben bu konuyu bilmiyorum, bana anlatabilir misin?" diyebildiği gün, o ekip yenilmez bir öğrenme organizasyonuna dönüşür.

Kibrin Maliyetini Şirketler Öder

Bir hastanede egosu yüzünden konsültasyon istemeyen bir doktor hastanın canına mal olur.
Bir teknoloji şirketinde kibri yüzünden yardım istemeyen bir yazılımcı ise projenin gecikmesine, mimarinin yamalı bohçaya dönmesine ve ekibin tükenmesine neden olur.

Klavye başında tek başınıza acı çekmeyi bir kahramanlık zannetmeyi bırakın.
Ekranın karşısında donup kaldığınızda, derin bir nefes alın ve yanınızdaki insana seslenin:
"Konsültasyon rica edebilir miyim?"

Göreceksiniz ki yardım istemek kıdeminizi eksiltmez; aksine sizi kibirli bir kod yazıcısından, olgun bir sistem mühendisine dönüştürür.

Çoğu insan o kâğıdı okumadan çöpe atar. Oysa o minik kâğıt, farmakoloji biliminin insan hayatına duyduğu saygının en somut belgesidir. Orada sadece ilacın baş ağrınızı nasıl geçireceği yazmaz. Sayfalar boyunca şunlar sıralanır:
"Karaciğer enzimlerini yükseltebilir, mide mukozasında kanamaya yol açabilir, tansiyonu düşürebilir, astım hastalarında bronkospazmı tetikleyebilir..."

Farmakolojide bir kural vardır: Yan etkisi olmayan bir ilaç, etki de etmiyordur.
Bir kimyasalı biyolojik bir organizmaya soktuğunuzda, onun sadece tek bir organı hedef alıp geri kalan her şeyi tamamen masum bırakmasını bekleyemezsiniz. Başarılı bir hekim, sadece ilacın tedavi edici ana etkisine (terapötik etki) odaklanan değil; o ilacın vücudun diğer köşelerinde tetikleyeceği olası "yan etkileri" (side effects) öngören ve yöneten hekimdir.

Hastanın baş ağrısını kesip böbreğini iflas ettiren bir tedavi, tıp değil; cinayettir.

Peki yazılım dünyasına dönelim: Yazdığımız fonksiyonların, sınıfların ve modüllerin yan etkilerini ne kadar biliyor ve yönetiyoruz?

Masum Görünen Fonksiyonların Gizli Suçları

Fonksiyonel programlamanın (Functional Programming) en temel ve zarif kavramlarından biri "Pure Function" (Saf Fonksiyon) tanımıdır.

Saf bir fonksiyon, tıpkı matematiksel bir denklem gibidir ($f(x) = x + 2$):

1. Aynı girdi verildiğinde her zaman ama her zaman aynı çıktıyı üretir.
2. Kendi kapsamı (scope) dışındaki hiçbir şeyi değiştirmez. Dış dünyayla gizli bir temasa girmez.

Peki gerçek hayattaki kod tabanlarında ne görüyoruz? Tam bir farmakolojik kaos.

Bir projeyi incelersiniz. Karşınıza şöyle bir fonksiyon çıkar:
getUserProfile(userId)

Fonksiyonun ismine ve imzasına bakarsınız; ne kadar masum, değil mi? Beklenti çok basittir: Kullanıcının ID'sini ver, sana kullanıcının profil bilgilerini içeren bir nesne dönsün.

Ama fonksiyonun gövdesini (implementasyonunu) açtığınızda dehşete düşersiniz:

• Kullanıcının profilini çekerken aynı anda arka planda veritabanındaki last_active_at sütununu güncelliyordur.
• Yetmezmiş gibi, global bir activeUserCount sayacını bir artırıyordur.
• O da yetmezmiş gibi, üçüncü parti bir analitik servisine sessizce bir HTTP isteği gönderiyordur.
• Ve eğer analitik servisi zaman aşımına uğrarsa, profil bilgisini de getiremeyip hata fırlatıyordur!

İşte bu, prospektüsü olmayan ve arkasında gizli cinayetler işleyen bir fonksiyondur.
Siz sadece hastaya bir vitamin verdiğinizi sanırsınız; ama o vitamin gizlice hastanın kalbini durdurur.

"Bunu Değiştirdim, Neden Orası Patladı?"

Geliştiricilerin hayatını cehenneme çeviren o meşhur soruyu hatırlayın:
"Ben sadece kullanıcı profil sayfasındaki küçük bir detayı değiştirdim; ana sayfadaki sipariş modülü neden çöktü?"

Cevap basittir: Yönetilmeyen, belgelenmemiş ve gizlenmiş yan etkiler (unintended side effects).

Bir fonksiyon, kendi parametreleri ve dönüş değeri dışındaki bir dünyayı kurcalamaya başladığında (global bir değişkeni değiştirmek, dosya sistemine bir şeyler yazmak, paylaşılan bir önbelleği geçersiz kılmak); sistemin öngörülebilirliği (determinism) yok olur.

Tıpkı aynı anda 5 farklı ilaç kullanan ve hangi ilacın hangi organı bozduğunu doktorların bir türlü çözemediği polifarmasi (çoklu ilaç zehirlenmesi) hastaları gibi; sisteminiz de kendi yan etkilerinin yarattığı kimyasal fırtınada boğulmaya başlar.

Bir kodu test edememenizin (untestable code) ana sebebi de budur. Bir fonksiyonun çalışması için arka planda 10 tane gizli servisin ayakta olması gerekiyorsa, o fonksiyon bir mühendislik harikası değil; bulaşıcı bir patojendir.

Yan Etkileri Sınırlarda Tutmak

Bir yazılım sisteminin tamamen yan etkisiz olması elbette imkânsızdır. Çünkü en nihayetinde bir yazılımın varoluş sebebi yan etki üretmektir: Veritabanına kayıt atmak, ekrana piksel basmak, ağ üzerinden paket yollamak birer yan etkidir. Yan etki olmazsa yazılım hiçbir işe yaramaz.

Ancak gerçek yazılım mimarisi, tıpkı iyi bir hekimlik gibi şu prensiple çalışır:
Yan etkileri olabildiğince tecrit et (isolate), sınırda tut (boundaries) ve mutlaka belgele.

1. İş Mantığını (Core Domain) Saf Tutun: Şirketinizin en kritik hesaplamaları, fiyatlandırma algoritmaları ve veri dönüşümleri saf fonksiyonlardan oluşmalıdır. Ne veritabanı bilmeli, ne HTTP bilmelidir. Sadece ham veriyi almalı, işlemeli ve sonucu dönmelidir. Böylece 10 yıl sonra bile o fonksiyonu gözünüz kapalı test edebilirsiniz.
2. Yan Etkileri Dış Çepere İtin (I/O at the Edges): Veritabanı yazımları, ağ çağrıları ve kuyruk işlemleri sistemin en dış katmanında (Controller veya API handler) açık ve şeffaf bir şekilde yapılmalıdır. Fonksiyonun içinde gizlenmemelidir.
3. Fonksiyonun Prospektüsünü Yazın: Bir fonksiyon dış dünyada bir şeyleri değiştiriyorsa, bunu isminde veya tip tanımında haykırmalıdır. getUser() değil, gerekiyorsa getUserAndTrackAnalytics() olmalıdır. Geliştirici o ilacı sisteme verdiğinde başına ne geleceğini bilmelidir.

Ağrıyı kesmek maharet değildir. Maharet; hastanın karaciğerini, böbreğini ve kalbini koruyarak o ağrıyı dindirebilmektir.

Kod yazarken kendinize sorun:
"Bu fonksiyon sadece vaat ettiği işi mi yapıyor, yoksa arkasında gizlice bir organı iflasa mı sürüklüyor?"

Eğer bu sorunun cevabını veremiyorsanız; yazdığınız şey bir teknoloji değil, patlamaya hazır kimyasal bir zehirdir.

Bedenimizin bu devasa saldırı altında çökmeden hayatta kalabilmesinin tek bir temel felsefi kuralı vardır:
"Self" (Bizden Olan) ile "Non-Self" (Yabancı / Tehdit) Ayrımı.

Her bir hücremizin yüzeyinde MHC (Büyük Doku Uyum Kompleksi) adı verilen biyolojik bir kimlik kartı bulunur. Bağışıklık sistemimizin devriye polisleri olan T lenfositleri ve Doğal Katil (Natural Killer) hücreleri, dokular arasında durmaksızın gezer. Karşılaştıkları her hücrenin yakasına yapışır ve o kimlik kartını tarar.

Eğer hücre o kimliği gösterirse ve üzerindeki protein dizilimi bedenin genetik koduna uyuyorsa, T hücresi yoluna devam eder: "Bizdensin, geçebilirsin."
Ama eğer hücre o kimliği gösteremezse ya da üzerinde bir virüs parçası taşıyorsa; bağışıklık hücresi tek bir milisaniye bile tereddüt etmez. Hücrenin içine ölümcül enzimler (perforin ve granzim) enjekte ederek onu anında hücresel intihara (apoptoz) sürükler.

Beden ne kapıdaki deriye güvenir, ne de içeri girmiş olana. Savunma her saniye, her hücre düzeyinde yeniden doğrulanır.

Peki yazılım dünyasında, özellikle kurumsal siber güvenlikte yıllarca ne yaptık?

"Kale ve Hendek" Modelinin İflası

Geleneksel ağ güvenliği anlayışı, Orta Çağ şatolarının mantığıyla tasarlanmıştı: Kale ve Hendek (Castle and Moat) Modeli.

Şirketler veri merkezlerinin veya ofis ağlarının etrafına devasa bir güvenlik duvarı (Firewall) ve bir VPN kapısı koyardı. Mantık şuydu: "Dışarısı tehlikeli bir vahşi batı, içerisi ise güvenli bir cennet. Hendekten (VPN'den) içeri girmeyi başaran herkese koşulsuz güvenebiliriz."

Bu yaklaşım, insan biyolojisi açısından tam bir intihardır. Düşünsenize; derinizi küçük bir iğneyle delip içeri giren tek bir bakteriye tüm organlarınızın "Madem deriyi aştın, o zaman karaciğerde ve kalpte serbestçe dolaşabilirsin" dediğini... İnsan soyu bir hafta içinde tükenirdi.

Nitekim modern siber saldırılarda "Kale ve Hendek" modeli tamamen çöktü.
Bir saldırgan şirketin muhasebecisine oltalama (phishing) e-postası atıp VPN şifresini ele geçirdiği an; o iç ağda bulunan tüm veritabanlarına, müşteri kayıtlarına ve kaynak kodlara elini kolunu sallayarak erişebiliyordu. Çünkü içeride tek bir kontrol noktası bile yoktu.

Zero-Trust: Biyolojinin Siber Güvenliğe İlhamı

Son yıllarda sektörün kurtarıcısı olarak parlayan Zero-Trust (Sıfır Güven) mimarisi, aslında bilgisayar mühendislerinin icat ettiği yeni bir teknoloji değildir. Zero-Trust; milyonlarca yıllık insan bağışıklık sisteminin kelimesi kelimesine kopyalanmasından ibarettir.

Zero-Trust'ın amentüsü basittir: "Asla güvenme, her zaman doğrula." (Never trust, always verify.)

Bu mimaride artık "iç ağ" veya "güvenli bölge" diye bir kavram yoktur.

• İster ofis masasından bağlanın, ister evinizden;
• İster şirketin CEO'su olun, ister stajyer;
• İster bir mikroservis diğer mikroservise istek atsın;

Her bir istek (HTTP request, veritabanı sorgusu, API çağrısı) tıpkı o T hücresinin sorgusu gibi karşılanır. Karşılıklı TLS (mTLS) sertifikaları kontrol edilir, JWT token'ları doğrulanır, istek yapan servisin o an o veriye erişmeye yetkisi olup olmadığı (IAM / RBAC) en ince ayrıntısına kadar taranır.

Bir servisin içeride olması ona hiçbir imtiyaz sağlamaz. Tıpkı bedenin içindeki bir hücrenin, her saniye kimliğini yeniden kanıtlamak zorunda olması gibi.

İmmün Sistemin İki Büyük Hastalığı ve Yazılımdaki Karşılıkları

Bağışıklık sistemini incelerken tıp fakültesinde öğrendiğimiz iki büyük patoloji vardır ki, siber güvenlik ekiplerinin her gün yaşadığı kabuslarla birebir örtüşür:

1. Otoimmün Hastalıklar (False Positives)

Bağışıklık sistemi bazen dengesini kaybeder ve aşırı paranoyaklaşır. Bedenin kendi sağlıklı dokularını (eklemlerini, böbreklerini, sinir kılıflarını) yabancı bir düşman sanıp saldırmaya başlar: Lupus, Romatoid Artrit, Multipl Skleroz (MS)... Beden kendi kendini yok eder.

Siber güvenlikte de aşırı katı, kötü kurgulanmış WAF (Web Application Firewall) veya IPS kuralları tam olarak bu otoimmün krizi yaratır:
Güvenlik sistemi o kadar agresiftir ki; sitenize alışveriş yapmaya gelen gerçek müşterileri, API entegrasyonu yapan iş ortaklarınızı ve hatta kendi arka plan servislerinizi "siber saldırgan" sanıp engeller (False Positive). Güvenlik sağlamaya çalışırken şirketin kendi ticaretini felç edersiniz.

2. Kanser ve Truva Atı (Insider Threat / Privilege Escalation)

Kanser hücreleri dışarıdan gelen bir bakteri değildir; bizzat sizin kendi hücrelerinizdir. DNA'ları bozulmuştur, kontrolsüzce çoğalırlar ama yüzeylerinde bağışıklık sistemini aldatacak özel kimlik sinyalleri (PD-L1 kontrol noktaları) taşırlar. T hücresi yanlarına geldiğinde o sahte kimliği gösterip "Ben yabancı değilim, bizden biriyim" diyerek bağışıklık polislerini uyuturlar.

Yazılımda da en yıkıcı saldırılar dışarıdan gelen kaba kuvvet (DDoS) saldırıları değildir; meşru bir kullanıcı veya servis hesabının kimliğini çalıp (Token Theft / Credential Stuffing) sistemin içinde sessizce yetki yükselten (Privilege Escalation) Truva atlarıdır. Sistem o isteği "bizden" sandığı için tüm kapıları açar.

Güvenlik Statik Bir Duvar Değil, Yaşayan Bir Reflekstir

Birçok şirket siber güvenliği, bir kez satın alınıp sunucuya kurulan ve bir daha bakılmayan pahalı bir donanım kutusu zanneder.

Oysa insan bağışıklığı statik bir zırh değildir. Her gün yeni virüslerle karşılaşan, antikor üreten, hafıza hücreleriyle (Memory B Cells) geçmiş saldırıları hatırlayan ve sürekli adapte olan canlı, dinamik bir öğrenme sürecidir.

Sistemlerinizi kaleler gibi tasarlamayı bırakın.
Sistemlerinizi yaşayan bir biyolojik organizma gibi tasarlayın:

• Her noktada kimlik doğrulayın,
• Yetkileri en aza indirin (Principle of Least Privilege),
• Ve ağınızın içindeki hiçbir bileşene körü körüne güvenmeyin.

Çünkü hayatta kalmanın sırrı, kapıyı kalınlaştırmakta değil; damarlarınızın her milimetresinde o soğukkanlı, uyanık ve şüpheci bağışıklık nöbetini kesintisiz tutabilmektedir.

Eski tıp kitapları, insan beyninin gelişimini tamamladıktan sonra değişmez, statik ve katı bir devre tahtası gibi çalıştığını varsayardı: "Bir bölge hasar görürse, o fonksiyon sonsuza kadar yok olur."

Oysa gerçek çok daha mucizevi bir dayanıklılığı barındırıyordu.
Ağır bir inme (felç) geçiren, beyninin sol tarafındaki konuşma merkezi (Broca alanı) kanama nedeniyle tamamen tahrip olan hastaların aylar süren rehabilitasyonun ardından yeniden konuşabildiğini gördük. Nasıl mı? Çünkü beyin katı bir makine değildi. Hasar gören bölgenin etrafındaki sağlam nöronlar, aralarında yepyeni sinaptik köprüler örüyor, rol değiştiriyor ve ölen dokunun görevini sırtlanıyordu.

Bedenimiz hayatta kalabilmek için kırılmayı değil; şekil değiştirmeyi (adaptasyonu) seçmişti.

Şimdi bu biyolojik esnekliği alın ve bilgisayar mühendisliğinin o katı, kırılgan ve hassas mimari dünyasıyla karşılaştırın.

Camdan Kuleler: Geleneksel Yazılımın Kırılganlığı

Geleneksel yazılım mimarileri çoğu zaman sert bir porselen vazo gibi tasarlanır. Dışarıdan baktığınızda pürüzsüz, simetrik ve kusursuz görünür. Ancak en ufak bir sarsıntıda, tek bir bağlantının kopmasında ya da beklenmedik bir yük dalgasında paramparça olur.

Tek bir monolitik sunucu düşünün. İçinde ödeme servisi, bildirim servisi, raporlama modülü ve kullanıcı yönetimi hepsi aynı bellek alanında (in-memory) yan yana çalışır.

Günün birinde raporlama modülündeki acemi bir geliştirici, arkasında LIMIT olmayan devasa bir SQL sorgusu çalıştırır. Bellek tükenir. Ve ne olur?
Sadece raporlama modülü çökmez; ödeme sistemi de çöker, kullanıcı girişi de durur, tüm şirket felç olur.

Sisteminizin bir parmağı incinmiştir; ama bütün beden komaya girmiştir. Çünkü sisteminizde plastisite (esneklik) yoktur; katılık (rigidity) vardır.

Kendi Kendini Onaran (Self-Healing) Mimariler

Son yıllarda modern dağıtık sistemlerin (Distributed Systems), bulut mimarilerinin ve Kubernetes gibi orkestrasyon araçlarının çözmeye çalıştığı asıl problem; hızı artırmak değil, biyolojik plastisiteyi kod tabanına kazandırmaktır.

Gerçekten dayanıklı (resilient) bir mimari, felaketlerin "asla yaşanmayacağını" iddia eden mimari değildir. Tam aksine; sistemin her an bir organının iflas edebileceğini peşinen kabul eden ve bu hasara rağmen yaşamaya devam eden mimaridir:

1. Hasarlı Düğümü İzole Etmek (Circuit Breaker): Tıpkı beynin hasarlı damarı tıkayıp kanamayı durdurması gibi; bir mikroservis çöktüğünde veya yanıt vermeyi kestiğinde, Circuit Breaker (Devre Kesici) mekanizması devreye girer. O servise giden istekleri anında keser; hatanın diğer servislere bulaşmasını (cascading failure) engeller.
2. Kademeli Trafik Yönlendirme (Dynamic Traffic Re-Routing): Bir veri merkezindeki sunuculardan biri yandığında, Service Mesh trafiği hiçbir insanın müdahalesine gerek kalmadan, milisaniyeler içinde sağlıklı diğer düğümlere (node) akıtır. Tıpkı felçli beyindeki sinir sinyallerinin yeni sinapslardan akması gibi.
3. Otomatik Hücre Yenilenmesi (Auto-Restart & Healing): Kubernetes'te bir pod bellek hatasından öldüğünde, kontrolcü (controller) o cesedin başında yas tutmaz. Anında yeni bir pod ayağa kaldırır, hazır olduğunda trafiği ona devreder. Bedenimizin her gün milyarlarca ölen epitel hücresinin yerine yenisini üretmesi gibi.

Nassim Taleb ve "Antifrajil" Kod

Felsefeci Nassim Nicholas Taleb'in meşhur bir kavramı vardır: Antifragile (Kırılgan Olmayan / Darbeden Güçlenen).

Taleb der ki: "Kırılgan olan şey rüzgarda söner; ama ateş rüzgardan beslenir ve daha da büyür."

Yazılımda da en üstün mimari seviyesi; sadece hatalara karşı "dayanıklı" (robust) olan değil, hatalardan beslenerek kendini kalibre eden sistemlerdir. Netflix'in meşhur Chaos Monkey aracını hatırlayın. Kendi canlı üretim (production) sunucularındaki servisleri mesai saatleri içinde rastgele öldüren bir yazılım botu!

Neden bir şirket kendi sistemini bilerek sabote eder?
Çünkü sistemin plastisitesini test etmek isterler. Bir sunucu aniden öldüğünde mimarinin kasları refleks olarak kasılmalı, trafik anında diğer yöne akmalı ve sistem bu travmayı sindirerek daha güçlü bir adaptasyon geliştirmelidir.

Yaşayan Bir Kod Tabanı İnşa Etmek

Bir sistemin mimarisini tasarlarken kendinize şu soruyu sormak zorundasınız:
"Ben kırılmaz bir kale mi inşa ediyorum, yoksa yaşayan bir organizma mı?"

Kaleler depremde yıkılır; çünkü esnemezler. Ama yaşayan organizmalar hayatta kalır; çünkü darbe aldıkları yerde şekil değiştirir, yükü diğer organlarına paylaştırır ve nefes almaya devam ederler.

En iyi mimariler asla çökmeyenler değildir.
En iyi mimariler; çöktüğü an bunu zarafetle karşılayan, hasarlı parçasını sessizce bypass eden ve kullanıcılarına hissettirmeden hayatta kalmayı başaran sistemlerdir.

Her bir dakikada kalbin pompaladığı kanın yaklaşık dörtte biri (1.2 litre) doğrudan böbreklerden geçer. Neden mi? Çünkü trilyonlarca hücremiz durmaksızın çalışır, glikoz yakar, protein sentezler ve bu hayati metabolizmanın kaçınılmaz bir sonucu olarak devasa miktarda toksik çöp üretir: Üre, kreatinin, ürik asit, amonyak...

Eğer böbrekleriniz bu çöpleri idrar yoluyla dışarı atamazsa; tıp dünyasının en korkunç tablolarından biri olan Üremi ve Toksik Asidoz başlar.

Kandaki zehir seviyesi yükselir. Önce iştahsızlık ve bulantı başlar, ardından beyin dokusu ödem yapar, hasta halüsinasyonlar görmeye başlar, komaya girer ve kalbi durur. İnsan bedeni, dışarıdan gelen bir virüs yüzünden değil; kendi ürettiği metabolik atıkların içinde boğulduğu için ölür.

Diyaliz makinesi, bir insanın kanını o zehirden temizleyen yapay bir kurtuluş kapısıdır.

Peki yazılım dünyasında, özellikle veritabanı mimarilerinde durum bundan farklı mıdır?

Şişen Tablolar ve Veritabanı Üremisi

Bir startup veya kurumsal yazılım ilk kurulduğunda her şey ne kadar hızlı ve pürüzsüzdür, değil mi? Sorgular milisaniyeler içinde döner, dashboard saniyede yüklenir, veritabanı CPU kullanımı %5'i geçmez. Çünkü sistem henüz gençtir; damarlarında tek bir atık partikülü bile birikmemiştir.

Ama aylar ve yıllar geçer. Uygulamanız büyür:

• Kullanıcıların her tıklamasını kaydettiğiniz o activity_logs tablosu 100 milyon satırı aşar.
• Süresi çoktan dolmuş ama asla temizlenmeyen user_sessions tablosu gigabaytlarca yer kaplar.
• Soft-delete mantığıyla (is_deleted = true) sözde "sildiğiniz" ama diskin en derin köşelerinde çürümeye bıraktığınız milyonlarca ölü satır (dead tuples) birikir.
• Ve PostgreSQL gibi modern veritabanlarında VACUUM süreçleri düzgün yapılandırılmadığı için, silinen verilerin açtığı boşluklar şişer (Database Bloat).

Sonra ne olur?

Sistem yavaşlamaya başlar. Eskiden 10 milisaniyede dönen basit bir SELECT sorgusu artık 8 saniyede dönmemeye başlar. Disk I/O tavan yapar. Bellek tükenir.

Ve ekibin acemi mühendisleri aynı yanlış teşhisi koyar:
"Veritabanı sunucumuz yetersiz kalıyor, AWS RDS instansını iki katına çıkaralım, 32 GB RAM ekleyelim."

İşte bu, böbrekleri iflas etmiş ve vücudu üre zehirlenmesine girmiş bir hastaya; "Bunun kanı azaldı herhalde, biraz daha serum bağlayalım" demekle aynı ölümcül hatadır.

Siz sorunu çözmüyorsunuz; zehirli bataklığın içine sadece biraz daha temiz su döküyorsunuz. Bir ay sonra o 32 GB RAM de yetmeyecek; çünkü atık üretimi devam ediyor ve boşaltım mekanizmanız çalışmıyor!

Garbage Collection Sadece Bir Dil Özelliği Değildir

Yazılımcılar "Garbage Collection" (Çöp Toplayıcı) dendiğinde sadece Java, Go veya JavaScript runtime'ının bellekteki kullanılmayan değişkenleri temizlemesini (ve bazen sistemi donduran Stop-the-World duraklamalarını) hatırlar.

Oysa gerçek bir sistem mimarisinde Garbage Collection, tüm organizmayı kapsayan bir Boşaltım Politikasıdır:

1. Ömür Sınırı (TTL - Time to Live) Koymak: Sisteme giren her verinin bir kullanım ömrü olmalıdır. Üç yıl önceki bir kullanıcının parola sıfırlama token'ı neden hâlâ birincil ilişkisel veritabanınızda duruyor? Süresi dolan geçici veriler, Redis veya tablolardan otomatik olarak ihraç edilmelidir.
2. Tablo Bölümleme (Partitioning): Büyük log tablolarını aylık veya haftalık dilimlere (partitions) bölün. Zamanı geçen bir ayı sistemden temizlemek için DELETE sorgusuyla veritabanını kilitlemek yerine, tek bir DROP TABLE komutuyla o parçayı cerrahi olarak dışarı atın.
3. Soğuk Depolama ve Arşivleme (Diyaliz Hattı): Canlı veritabanınız bir müze veya çöp kutusu değildir. Yasal olarak saklamak zorunda olduğunuz 5 yıllık geçmiş sipariş verilerini canlı OLTP veritabanından kesin; S3, BigQuery veya soğuk bir veri ambarına (Data Warehouse) tahliye edin. Canlı veritabanınız sadece nefes alan, aktif veriyi taşımalıdır.

Temizlenmeyen Sistem Çürümeye Mahkûmdur

Bir insan ne kadar kaliteli yemek yerse yesin, ne kadar spor yaparsa yapsın; böbrekleri çalışmadığı sürece en fazla birkaç gün hayatta kalabilir.

Bir yazılım da ne kadar kusursuz bir mimariye sahip olursa olsun, ne kadar güçlü sunucularda çalışırsa çalışsın; kendi ürettiği metabolik atıkları düzenli olarak dışarı atacak bir boşaltım disiplinine sahip değilse, eninde sonunda kendi çöplüğünde boğulmaya mahkûmdur.

Veritabanınıza sadece veri yazmayı değil; o veriyi zarafetle ve zamanında dışarı atmayı da öğrenin.

Çünkü hayatta kalmak, sadece tüketmekle değil; atıklardan arınabilme kabiliyetiyle mümkündür.

Bir hastaya içinde hiçbir kimyasal etken madde bulunmayan, sadece saf nişasta ve şekerden yapılmış beyaz bir hap verirsiniz. Veya damarına sadece steril tuzlu su (serum fizyolojik) enjekte edersiniz. Ama hastaya derin, güven veren bir ses tonuyla şunu söylersiniz: "Bu, dünyadaki en yeni ve en güçlü ağrı kesicidir. Birkaç dakika içinde rahatlayacaksınız."

Ve ne olur biliyor musunuz?
Klinik araştırmalar gösteriyor ki, hastaların en az üçte birinde (%35) o şiddetli ağrı gerçekten diner. Tansiyon düşer, nabız yavaşlar, kandaki endorfin (doğal ağrı kesici) seviyesi fırlar.

Beyin, "iyileşiyorum" inancını doğrudan biyolojik bir gerçeğe dönüştürür. Plasebo bir şarlatanlık veya yalan değildir; insan zihninin beklentiye verdiği nörolojik bir anestezidir.

Şimdi hastaneden çıkalım ve akıllı telefonlarımızın o parlak cam ekranlarına, mobil uygulamalara ve web sitelerine bakalım.

Eğer modern arayüz tasarımının (UI/UX) sadece pikselleri hizalamak, doğru renk paletini seçmek ve CSS yazmaktan ibaret olduğunu sanıyorsanız, çok büyük bir yanılgı içindesiniz. Modern UX mühendisliği, özünde kullanıcı algısını yöneten devasa bir dijital plasebo sanatıdır.

Asansördeki "Kapıyı Kapat" Butonu

Gerçek hayattaki en ünlü fiziksel plaseboyu hepimiz her gün kullanırız: Asansörlerdeki "Kapıyı Kapat" (Door Close) butonu.

Büyük binalardaki asansörlerin ezici bir çoğunluğunda o butonun arkasında hiçbir kablo veya elektronik devre bağlı değildir. Kapı zaten önceden ayarlanmış olan o 5 saniyelik süresi dolunca kendi kendine kapanacaktır.

Peki asansör üreticileri neden o butonu oraya koyar?
Çünkü insan beyni beklemekten nefret eder; ama daha da çok kontrolsüzlükten nefret eder. O butona üç kez art arda basan insan, kapının kendi eylemi sayesinde kapandığını sanır. Anksiyetesi yatışır, kontrol hissi geri gelir. Buton kapıyı kapatmaz; ama zihni sakinleştirir.

İşte modern yazılım dünyasının dahi tasarımcıları, bu asansör butonunu kod bloklarına dönüştürdü.

Dijital Plasebo 1: İskelet Ekranlar (Skeleton Loaders)

Bir web sitesine girdiğinizi düşünün. Sunucudan verinin gelmesi ve ekrana basılması tam 2.5 saniye sürüyor olsun.

Eğer kullanıcıya bu 2.5 saniye boyunca boş, beyaz bir ekran ve ortasında dönen klasik bir yükleme simgesi (spinner) gösterirseniz; kullanıcı o 2.5 saniyeyi adeta 10 saniye gibi hisseder. Sayfayı terk etme oranı (bounce rate) tavan yapar. Kullanıcı "Bu site bozuk, çalışmıyor" der.

Ama aynı 2.5 saniye boyunca ekrana içeriğin henüz gelmediği, hafifçe yanıp sönen gri kutucuklar (Skeleton Screen / Shimmer Effect) koyarsanız ne olur?
Kullanıcı süreyi 1 saniye gibi hisseder. Çünkü beyin o gri kutuları gördüğü an "İçerik hazır, şu an yerleştiriliyor" algısına kapılır. Bekleme süresi matematiksel olarak aynıdır; ama algılanan süre yarı yarıya düşmüştür.

Siz sunucuyu hızlandırmadınız; siz kullanıcının algısına plasebo verdiniz.

Dijital Plasebo 2: İyimser Güncelleme (Optimistic UI)

Instagram'da veya X'te bir gönderiyi beğendiğinizde ne olur? Ekrana iki kez dokunursunuz ve o kalp anında, sıfır gecikmeyle kırmızıya döner.

Peki o kırmızı kalbin o an gerçekten veritabanına kaydedildiğini mi sanıyorsunuz?
Hayır. Telefonunuzun o isteği hücresel ağ üzerinden baz istasyonuna, oradan veri merkezine yollaması, veritabanına yazması ve geri dönüş sinyali alması en iyi ihtimalle 300-500 milisaniye sürer.

Eğer uygulama o onayı bekleseydi, her beğeni butonuna bastığınızda ekran yarım saniye donardı.
Bunun yerine frontend mühendisleri Optimistic UI (İyimser Arayüz) uygular: Sunucunun o işlemi "nasılsa onaylayacağını" varsayarak, henüz network isteği yoldayken arayüzü anında günceller. Kullanıcı için işlem 0 milisaniyedir.

Eğer arkada bir hata olursa? Kalp sessizce eski haline döner. Ama vakaların %99'unda kullanıcı o ilüzyonun kusursuz akıcılığıyla mest olur.

Dijital Plasebo 3: "Sizin İçin En İyi Fiyatları Arıyoruz..."

Bazen de tam tersi gerekir: Bir işlemin "çok hızlı" olması kullanıcıda güvensizlik yaratır.

Büyük uçak bileti veya otel arama motorlarını (Skyscanner, Booking) düşünün. Bir arama yaparsınız. Sistem aslında o fiyatları önbellekten (cache) 50 milisaniyede getirebilecek altyapıya sahiptir.

Ama eğer sonucu 50 milisaniyede şak diye ekrana basarlarsa ne olur biliyor musunuz? Kullanıcı testleri göstermiştir ki, kullanıcılar "Bu sistem kesin tüm havayollarını taramadı, baştan savma birkaç sonuç getirdi" diyerek o biletleri satın almaktan vazgeçiyor.

Bu yüzden tasarımcılar bilerek araya 3 saniyelik yapay bir gecikme ve sevimli bir animasyon koyar:
"142 havayolu taranıyor... Fiyatlar karşılaştırılıyor... Sizin için en uygun koltuklar seçiliyor..."
Kullanıcı o 3 saniye boyunca ekranı huşu içinde izler ve sonucun ne kadar "kapsamlı ve derin" bir çalışmanın eseri olduğuna inanarak kartını çıkarır.

Algı, Gerçekliğin Kendisidir

Yazılım sadece sunucu donanımlarından, mikroişlemcilerden ve SQL sorgularından ibaret değildir. Kodunuzun bittiği yerde, o ekranın başında oturan etten, kemikten ve karmaşık duygulardan oluşan insan başlar.

Milisaniyeleri optimize etmek için gecenizi gündüzünüze katabilirsiniz. Veritabanı sorgusunu 200 ms'den 150 ms'ye düşürmek için haftalarca mimari tartışabilirsiniz.

Ama bazen kullanıcınızın yüzündeki o gerginliği silmenin yolu sunucuya daha fazla CPU takmak değil; arayüze zarafetle yerleştirilmiş küçük, şefkatli bir plasebo illüzyonudur.

Çünkü tıpta olduğu gibi teknolojide de; bir insanın kendini iyi hissetmesi, laboratuvar sonuçlarının ne söylediğinden her zaman çok daha önemlidir.

Kronik ağrısı olan bir hastayı düşünün. Başlangıçta 10 miligramlık basit bir ağrı kesici (örneğin bir opioid veya analjezik) ağrıyı bıçak gibi keser. Hasta rahat bir nefes alır, hayata döner. Ancak haftalar ve aylar geçtikçe insan bedeni o kimyasal uyarana alışmaya başlar. Hücre yüzeyindeki reseptörler (özellikle mu-opioid reseptörleri) duyarsızlaşır (desensitizasyon) ve sayılarını azaltır (down-regulation).

Bir süre sonra o 10 mg artık ağrıyı kesmemeye başlar.
Hasta doktorun kapısını çalar: "Ağrım geri geldi, ilacı artırmamız lazım."
Doz 20 mg'a çıkarılır. Birkaç ay sonra 40 mg'a, sonra 80 mg'a...

Hasta aslında iyileşmiyordur. Hastalığın altındaki kök neden (iltihap, fıtık, tümör) yerinde durmaktadır. Beden sadece ilacın dozuna karşı korkunç bir tolerans geliştirmiş ve o zehre bağımlı hale gelmiştir. Dozu artırmak hastalığı tedavi etmez; sadece kaçınılmaz çöküşü erteler ve karaciğeri iflasa sürükler.

Şimdi bu farmakolojik tuzağı alın ve modern bulut bilişimin (Cloud Computing), sunucu yönetiminin ve yazılım mimarisinin tam göbeğine yerleştirin.

"Sunucu Yavaşladı, Instance'ı Büyütün!"

Yazılım sektörünün en yaygın, en tembel ve en tehlikeli alışkanlığı nedir biliyor musunuz?
Algoritmik tembelliği, kredi kartıyla çözmeye çalışmak.

Bir e-ticaret veya SaaS uygulamanız vardır. Başlangıçta her şey 2 vCPU ve 4 GB RAM'e sahip mütevazı bir sunucuda harika çalışıyordur. Ancak zamanla kullanıcı sayısı biraz artar ve sistem nefes nefese kalmaya başlar. Yanıt süreleri 200 ms'den 2 saniyeye fırlar, CPU kullanımı %95'e dayanır.

O an masada iki seçenek vardır:

1. Zor ve Erdemli Yol: Kodu profillemek (profiling), veritabanındaki N+1 sorgu problemlerini bulmak, eksik indeksleri tespit etmek, bellek sızıntılarını cerrahi olarak ayıklamak.
2. Kolay ve Zehirli Yol: AWS konsolunu açıp sunucu tipini t3.mediumdan c5.2xlargea çekmek. RAM'i 4 GB'tan 32 GB'a fırlatmak.

Ve şirketlerin %90'ı ne yapar? Tabii ki ikinci yolu seçer. İki tıklamayla sunucu boyutu artırılır, fatura kabartılır, CPU kullanımı bir anda %20'ye düşer. Herkes birbirini tebrik eder: "Sorunu çözdük!"

Hayır, hiçbir şeyi çözmediniz. Siz sadece hastanın morfin dozunu iki katına çıkardınız.

Kodun Oburluk Toleransı

Peki sonra ne olur? Biyolojideki o acımasız tolerans yasası yazılımda da devreye girer.

Siz o kötü yazılmış koda 32 GB RAM verdiğinizde, o kod iyileşmez; daha obur hale gelir.

• Geliştiriciler artık belleği serbest bırakma (garbage collection) ihtiyacı hissetmez; çünkü "Nasılsa RAM bol" rahatlığına kapılırlar.
• Veritabanından sadece 3 alan çekmek yerine, 50 sütunluk koca nesneleri komple belleğe çeken aptalca ORM sorguları yazmaya devam ederler.
• Karmaşıklığı $O(n^2)$ veya $O(n^3)$ olan korkunç iç içe döngüler kod tabanına yayılır.

Ve 6 ay sonra o 32 GB RAM de yetmemeye başlar. Sistem yine kilitlenir, yine yavaşlar.

Ekip bu kez "Bize 64 GB RAM ve 16 çekirdek lazım" diye yönetimin kapısına gider. Şirket her ay Amazon'a, Google'a küçük bir servet ödeyen bir "Bulut Bağımlısına" dönüşür. AWS'in ve bulut devlerinin trilyon dolarlık imparatorlukları, işte bu mühendislik tembelliğinden ve donanım toleransından beslenir.

50 Megabayt ile Ay'a Giden İnsanlık

Bilgisayar bilimleri tarihini hatırlayın. 1969 yılında Apollo 11 uzay aracını Ay'a indiren kılavuz bilgisayarın (Apollo Guidance Computer) sadece 4 kilobayt RAM'i vardı. 1990'larda dünyayı kasıp kavuran Doom oyunu, sadece 4 megabayt bellekle 3 boyutlu bir evren simüle ediyordu.

Bugün ise Slack veya Teams gibi basit bir sohbet uygulamasını açtığınızda bilgisayarınızdan 2 GB RAM emdiğini görüyorsunuz. İki satır metin göndermek için Apollo 11'in milyonlarca katı kaynağa ihtiyaç duyuyoruz.

Bunun adı teknolojik gelişme değildir. Bunun adı "Donanım Şişmanlığı" (Software Bloat) ve sefahattir.

İşlemciler hızlandıkça, bellekler ucuzladıkça; mühendisler zarafeti, optimizasyonu ve algoritma disiplinini unuttu. Kötü kodun yarattığı pisliği, altına daha büyük donanım halıları sererek örtbas etmeye alıştık.

Gerçek Tedavi Kök Nedeni Ameliyat Etmektir

Ağrıyı kesmek için dozu sürekli artırırsanız, günün birinde hastayı aşırı dozdan (overdose) kaybedersiniz.

Bir yazılım projesinde de her performans krizini sunucu büyüterek çözmeye çalışırsanız; günün birinde öyle bir trafik dalgası gelir ki, dünyadaki en pahalı AWS sunucusu bile o $O(n^3)$ karmaşıklığındaki kodunuzu kurtaramaz. Sistem çöker, bütçe tükenir ve şirket iflas eder.

Gerçek bir mühendis olmak istiyorsanız; sunucu boyutunu artırmayı bir "başarı" değil, bir "yenilgi itirafı" olarak görün.

Bir sistem yavaşladığında elinizi hemen kredi kartına atmayın.
Kodu masaya yatırın.
Profiler'ı çalıştırın.
O gereksiz döngüleri, o bellek sızıntılarını, o tembel sorguları tek tek bulun ve neşterle kesip atın.

Çünkü hastayı hayatta tutan şey sonsuz dozda morfin değil; hastalığın kaynağını kurutan o cesur ve disiplinli cerrahi müdahaledir.

Trafik kazası, diyabetik nekroz ya da savaş yaralanması nedeniyle bacağını veya kolunu kaybetmiş bir hastanın yanına gidersiniz. Ameliyatın üzerinden aylar geçmiştir; yatakta hastanın sağ bacağının yerinde sadece boş bir çarşaf durmaktadır.

Ama hasta acı içinde kıvranarak size şunu söyler:
"Doktor bey, sağ ayak başparmağım öyle bir kaşınıyor ve sızlıyor ki delireceğim. Sanki birisi parmaklarımı mengeneyle sıkıyor."

Olmayan bir organ ağrıyabilir mi? Biyolojik olarak evet.
Çünkü bacak fiziksel olarak kesilip atılmış olsa bile; beynin somatosensöriyel korteksinde o bacağa ait nöral harita (Penfield homunculus) hâlâ silinmemiştir. Kesilen sinir uçları beyne sahte sinyaller göndermeye devam eder; beyin o boşluğa anlam veremez ve kayıp uzvun "hayaletiyle" yıllarca acı çeker.

Bir uzvu kesip atmak cerrah için 20 dakikalık bir ameliyattır; ama o uzvun yokluğunu beynin kabul etmesi bazen bir ömür sürer.

Peki, yazılım mimarilerinde eski bir modülü sildiğimizde ne yaşanır?

git rm -rf: Fiziksel Silinmenin Kolaylığı

Yazılım dünyasında bir modülden, eski bir servisten veya deprecated edilmiş bir kütüphaneden kurtulmak çocuk oyuncağı gibi görünür:
Dosyaları seçersiniz, Delete tuşuna basarsınız veya terminale o havalı komutu yazarsınız:
git rm -rf src/legacy-billing-service
git commit -m "feat: delete legacy billing module forever"

PR onaylanır, merge edilir ve kod tabanından binlerce satır silinir. Ekip arkasına yaslanır: "Oh be, kurtulduk şu kamburdan!"

Ama birkaç gün sonra, sistemin en beklenmedik köşelerinde esrarengiz arızalar başlar:

• Kullanıcı profilini güncellemek ister; sistem 500 Internal Server Error fırlar.
• Gece yarısı çalışan raporlama servisi aniden durur; loglarda şu satır belirir:
  Connection refused: http://billing-service:8080/api/v1/status
• Veritabanında bir migration çalıştırmaya kalkarsınız; sistem "Foreign key constraint violation" diyerek suratınıza çarpar; çünkü silinen modülün veritabanında bıraktığı yetim kayıtlar hâlâ canlı tablolara bağlıdır.

Fiziksel olarak o modülü depodan silmişsinizdir; ama mimarinizin sinir uçlarında o modül hâlâ zonklayarak yaşamaya devam ediyordur.

Sisteminiz tam anlamıyla bir "Hayalet Uzuv Sendromu" yaşamaktadır.

Yetim Kodlar ve Zombi Bağımlılıklar

Bir yazılım sistemi büyüdükçe, organları arasındaki bağlar sandığınızdan çok daha derin, karmaşık ve görünmez kılcal damarlarla örülür.

Siz "Ben sadece eski bildirim servisini sildim" dersiniz. Ama farkında değilsinizdir ki;

• Üç yıl önce yazılmış bir cron job, o servisin log dosyalarını okumaya çalışıyordur.
• Frontend uygulamasındaki küçük bir bileşen (widget), o servisten bir sayaç değeri bekliyordur ve o değer gelmeyince tüm React ağacını kilitliyordur.
• Docker konfigürasyonunuzda, CI/CD pipeline'ınızda veya Kubernetes manifestolarınızda hâlâ o ölü servisin hayaleti dolaşıyordur.

Buna bilgisayar bilimlerinde "Yetim Kod" (Orphaned Code) veya "Zombi Bağımlılık" (Zombie Dependency) denir.

Kodu silmek en kolayıdır; zor olan, o kodun sistemin zihninde bıraktığı sinaptik bağlantıları temizleyebilmektir. Bir cerrah gibi damarları koterize etmeden, sinir uçlarını özenle kapatmadan kör bir baltayla modül keserseniz; arkanızda kanayan yüzlerce mikro-kriz bırakırsınız.

Amputasyonun Zarafeti: Graceful Deprecation

Tıpta hayalet uzuv ağrılarını dindirmek için uygulanan harika bir terapi yöntemi vardır: Ayna Terapisi (Mirror Therapy). Hasta sağlam uzvunu bir aynanın karşısına koyar; beyin aynadaki yansımayı izleyerek o uzvun gerçekten orada olmadığını ve sağlam tarafın tek başına yettiğini görsel olarak idrak eder ve nöral haritasını yeniden çizer.

Yazılımda da bir modülü sistemden kesip atmadan önce, mimarinize o "ayna terapisini" uygulamak zorundasınız:

1. Önce Deprecate Et, Hemen Silme: Bir servisi aniden öldürmeyin. Önce deprecated uyarısı verin. Fonksiyon çağrıldığında loglara sarı uyarılar düşsün. Sistemin diğer parçalarının o servisten elini eteğini çekmesi için ekibe zaman tanıyın.
2. Kör Noktaları Tara (Static Analysis & Telemetry): Üretim ortamında dağıtık izleme (Distributed Tracing / OpenTelemetry) kullanarak o servise son 30 günde tek bir isteğin bile gelmediğini matematiksel olarak doğrulayın. Tahminlerle kod silinmez; telemetriyle silinir.
3. Sözleşmeyi (Interface) Koru, İçi Boşalt: Gerekirse servisin fiziksel sunucusunu kapatın ama API gateway üzerinde boş, zararsız bir cevap (204 No Content veya boş nesne) dönen sahte bir uç nokta (stub) bırakın. Böylece istemciler hayalet ağrıyla patlamasın.
4. Veritabanı Mezarlığını Temizle: Sadece kodu silmek yetmez. O modülün veritabanında bıraktığı tabloları, indeksleri ve foreign key bağlarını temizlemek için bağımsız, izole migration script'leri çalıştırın.

Silmek de Bir Sanattır

Geliştiricilerin değeri genellikle yazdıkları satır sayısıyla ölçülür. Bu, endüstrinin en sığ cehaletidir.

Gerçek bir kıdemli mühendisin ustalığı; sisteme tek bir satır kod eklemeden, binlerce satırlık çürümüş ve tehlikeli modülü geride tek bir hayalet ağrı bile bırakmadan, zarafetle ve sessizce sistemden söküp atabilme yeteneğidir.

Bir dahaki sefere bir modülü silmeye kalktığınızda, elinizdeki neştere ve klavyeye dikkatle bakın.
Sadece dosyayı silmeyin; mimarinin hafızasındaki o hayaleti de huzura kavuşturun.

Çünkü arkasında hayaletler bırakan bir sistem; asla tam anlamıyla sağlıklı ve özgür bir beden gibi koşamaz.

Bu teorinin çizdiği o meşhur grafik, aslında her birimizin hayat yolculuğunun acımasız bir özetidir:
Bir konuyu henüz yeni öğrenmeye başladığınızda, bilginiz çok azdır ama özgüveniniz stratosfere fırlar. Grafiğin o ilk zirvesine psikologlar çok manidar bir isim takmıştır: "Aptallık Tepesi" (Mount Ignorance).

Çünkü neyi bilmediğinizi bilecek kadar bile bilgiye sahip değilsinizdir. Her şey çok basit, her sorun tek bir formülle çözülebilir görünür.

Ancak öğrenmeye, hata yapmaya ve sahada darbe almaya devam ettikçe; o sahte özgüven tepesinden aşağı doğru serbest düşüşe geçersiniz. Düştüğünüz o karanlık çukura "Umutsuzluk Vadisi" (Valley of Despair) denir: "Ben meğer hiçbir şey bilmiyormuşum."
Ve eğer o vadide pes etmezseniz, yıllar süren ağır tecrübelerin ardından yavaş yavaş "Aydınlanma ve Ustalık Yaylasına" tırmanırsınız. Orada artık gürültü yoktur; derin, mütevazı ve sessiz bir yetkinlik vardır.

Yıllar önce acil tıp stajına başladığımda ve ardından ambulansın arka kabininde nöbet tuttuğum ilk aylarda, kendimi tam olarak o "Aptallık Tepesi"nin zirvesinde bulmuştum.

Ambulanstaki "Her Şeyi Bilen" Çömez

Mesleğin ilk üç ayındaki bir paramediği veya stajyeri gözlemleyin:
Üniformasını yeni giymiştir, cebinde parlak makaslar, boynunda stetoskop, telsiz omzunda... Birkaç başarılı damar yolu açmış, 20-30 tane standart vakaya gitmiştir. Yürüyüşü bile değişir. Her vakaya adeta bir süper kahraman edasıyla girer: "Açılın, ben hallederim!"

Telsizde en yüksek sesle o konuşur, hastanede vaka teslim ederken en çok tıbbi jargonu o kullanır. Ona göre acil tıp çocuk oyuncağıdır; kitapta yazanları harfiyen uygularsan herkesi kurtarabilirsin.

Sonra o kırılma anı gelir.

Gece saat 04:00'te sedyenize öyle bir vaka yatar ki; ne damar yolu açabilirsiniz, ne soluk borusuna tüp takabilirsiniz. Kalp kitaptaki hiçbir algoritmaya uymaz. İlaç verirsiniz tepki vermez, şok verirsiniz ritim dönmez. Ve o insan sizin ellerinizin altında, gözlerinizin içine bakarak son nefesini verir.

O gün ambulanstan indiğinizde, dizleriniz titreyerek bir kaldırımın kenarına oturursunuz. O parlak üniforma bir anda tonlarca ağırlığında kurşun bir zırha dönüşür. Aptallık Tepesi'nden Umutsuzluk Vadisi'nin en dibine çakılmışsınızdır. O gün anlarsınız ki; insan biyolojisi kitaplardaki akış şemalarından ibaret değildir ve ölümün karşısında ne kadar aciz birer çırağızdır.

İstasyondaki 15 yıllık kıdemli paramediklere bakın:
Hiçbir zaman gösterişli yürümezler. Sirenler çalarken bile nabızları 70'tir. Asla büyük konuşmazlar, asla "Bu vaka çok basit" demezler. Çünkü onlar o vadiden geçmiş, yüzlerce kez ölümün gözünün içine bakmış ve ustalığın tek kuralını öğrenmişlerdir: Sessiz, şüpheci ve hazırlıklı soğukkanlılık.

Yazılım Dünyasının "Aptallık Tepesi" Sakinleri

Peki yazılım dünyasında bu eğri nasıl işler? Birebir aynı trajikomik senaryoyla.

Bir bootcamp bitirmiş veya 6 aydır bir şirkette çalışan junior geliştiriciyi izleyin:
Twitter'da (X) ve LinkedIn'de en çok sesi çıkanlar onlardır. Herkese mimari dersi verirler:
"2026 yılında monolit kullanan dinozordur!"
"Hâlâ ilişkisel veritabanı mı kullanıyorsunuz, her şeyi MongoDB'ye taşımalısınız!"
"Tüm frontend'i filanca yeni framework ile yeniden yazmalıyız, diğerleri çöp!"

Aptallık Tepesi'nin havası boldur, manzarası güzeldir. Çünkü o geliştirici henüz;

• Dağıtık sistemlerde iki mikroservis arasındaki ağ gecikmesinin faturasını ödememiştir,
• Gece saat 03:00'te veritabanındaki yabancı anahtar (foreign key) eksikliğinden dolayı şirketin milyonlarca liralık veri kaybına şahit olmamıştır,
• 10 milyon kullanıcılı bir sistemde race condition'ın nasıl bir kabusa dönüştüğünü tatmamıştır.

Sonra o geliştirici büyür. Kendi yazdığı o "havalı" mikroservis mimarisi bir Black Friday gecesi yerle bir olur. Müşteri verileri silinir, yönetim masaya yumruğu vurur, şirket haftalarca o enkazı temizlemekle uğraşır.

Ve mühendis Umutsuzluk Vadisi'ne düşer: "Ben aslında hiçbir şey bilmiyormuşum. Bilgisayar bilimleri benim sandığımdan bin kat daha derin ve karmaşık bir deryaymış."

Gerçek Kıdem Tevazu Getirir

İşte bu yüzden, 15-20 yıllık gerçek bir "Staff / Principal" mühendisle masaya oturduğunuzda; onun ne kadar sade, ne kadar sakin ve ne kadar az konuştuğunu görünce şaşırırsınız.

Ona "Yeni bir projeye başlıyoruz, hangi mimariyi seçelim?" diye sorduğunuzda, size en havalı teknolojilerin isimlerini sıralamaz. Gözlerini kısar ve tek bir cümle söyler:
"İşimizi görecek en basit, en sıkıcı ve en az hareketli parça içeren şey neyse onu kullanalım. Monolit yapalım, tek bir Postgres kuralım, basit bir REST API yazalım."

Çünkü o usta, karmaşıklığın getirdiği kanlı faturaları defalarca kendi cebinden ödemiştir.

Büyük konuşanlar genellikle en az vakaya girenler ya da en az prod çökertenlerdir.
Cahil cesareti bağıra çağıra öne atılır; ama kriz anında ilk kaçan da o olur.

Hayatınızı bir hastaya müdahale eden bir paramediğe emanet edecekseniz de; şirketinizi milyon dolarlık bir mimariyi tasarlayan bir mühendise emanet edecekseniz de aynı şeye bakın:
En çok bağıranı değil; o Umutsuzluk Vadisi'nden sağ çıkmış, egosu kırılmış ve yerini sessiz bir ustalığa bırakmış olan soğukkanlı profesyoneli bulun.

Çünkü kriz anında hayatı kurtaran şey cehaletin coşkusu değil; tecrübenin getirdiği o derin ve mütevazı sükûnettir.

Vücudun iç sıcaklığı 35°C'nin altına düşmeye başladığında, hipotalamus bedene olağanüstü hal (OHAL) ilan eder. Beden çok iyi bilir ki; mevcut ısı ve enerjiyle trilyonlarca hücrenin tamamını aynı anda sıcak tutması fiziksel olarak imkânsızdır. Eğer enerjiyi herkese eşit dağıtmaya çalışırsa, birkaç dakika içinde kalp donacak ve tüm organizma ölecektir.

Bu yüzden beyin saniyeler içinde radikal bir feda kararı alır: Periferik Vazokonstriksiyon (Çevre Damarların Kapatılması).

Parmak uçlarındaki, kulaklardaki, burundaki ve ayaklardaki kılcal damarlar hızla büzüşür. Kan akışı bu uç bölgelerden tamamen çekilir. El ve ayaklar buz keser, hissizleşir, morarır; donma (frostbite) başlar ve gerekirse o parmaklar kangren olup dökülecektir.

Neden mi? Çünkü o değerli, sıcak kanın tamamı göğüs kafesine ve kafatasına çekilmiştir. Beden kalbi, beyni ve ciğerleri sıcacık tutar.

Mesaj son derece nettir: Bütünün yaşaması için uçlar feda edilmelidir.

Peki, aynı ölüm kalım savaşı yazılım sistemlerinin üzerine çöktüğünde ne yapıyoruz?

"Hepsi Ya da Hiçbiri" Felaketi

Geleneksel yazılım mimarilerinin en trajik zaafı, "Hepsi ya da Hiçbiri" (All-or-Nothing) mantığıyla çalışmalarıdır.

Büyük bir e-ticaret platformunu veya bir bankacılık uygulamasını düşünün. Yılın en büyük indirim gecesi (Black Friday) veya beklenmedik bir kriz anı gelir. Siteye bir anda normal trafiğin 20 katı yük biner.

Sistemin içinde onlarca farklı servis yan yana çalışmaktadır:

• Ödeme ve sipariş servisi (Hayati organ: Kalp)
• Kullanıcı giriş servisi (Hayati organ: Beyin)
• "Sizin için seçtiklerimiz" yapay zeka öneri modülü (Uç organ: Ayak başparmağı)
• Ürün yorumları ve yıldız puanları (Uç organ: Kulak memesi)
• Gerçek zamanlı kargo takip widget'ı (Uç organ: Tırnak ucu)

Kötü kurgulanmış bir mimaride ne olur?
O önemsiz yapay zeka öneri modülü, binlerce isteği kaldıramaz ve veritabanını kilitler. Veritabanı kilitlenince ödeme servisi de yanıt veremez hale gelir. Ve 10 dakika içinde bütün site 503 Service Unavailable diyerek tamamen çöker.

Kullanıcı tek bir ürün bile satın alamaz. Şirket bir gecede milyonlarca lira kaybeder.

Neden mi? Çünkü sisteminiz, bir kulak memesi üşüdü diye kalbini durduran aptal bir organizma gibi davranmıştır!

Graceful Degradation: Dijital Hipotermi

İşte modern sistem mimarisinde bu felaketi engelleyen hayat kurtarıcı prensibe "Graceful Degradation" (Kademeli Sistem Yavaşlaması / Zarafetle Gerileme) denir.

Graceful Degradation; sistem devasa bir yük dalgası altında nefes nefese kaldığında, çöküp ölmek yerine ikincil organlarını kademeli olarak feda etme sanatıdır:

1. Birinci Aşama (Hafif Hipotermi): Trafik eşik değeri aştığında, yapay zeka tabanlı kişiselleştirilmiş ürün önerilerini derhal kapatın. Kullanıcıya karmaşık öneriler sunmak yerine, önbellekte (cache) hazır bekleyen statik "En Çok Satanlar" listesini basın. CPU rahatlasın.
2. İkinci Aşama (Orta Hipotermi): Yük artmaya devam ediyorsa; ürün detay sayfalarındaki dinamik yorumları, filtreleme araçlarını ve canlı stok sayaçlarını devreden çıkarın. Kullanıcı yorumları okuyamasın ama ürünü görmeye devam etsin.
3. Üçüncü Aşama (Ağır Hipotermi - Çekirdek Koruma): Durum kritikse; arama motorunu kapatın, bildirim servislerini durdurun, analitik loglarını diske yazmayı kesin. Sunucunun tüm kaynaklarını (CPU, RAM, DB havuzu) tek bir hayati fonksiyona kilitleyin: Sepete ekle ve Ödemeyi tamamla!

Kullanıcı o gece sitede bazı süslü animasyonları görmeyebilir. Öneri listesi çalışmayabilir.
Ama satın almak istediği ürünü alır, parasını öder ve siparişini tamamlar. Şirket ticaretine devam eder.

Sisteminizin el ve ayak parmakları donmuştur; ama kalbi atmaya, beyni yaşamaya devam etmiştir.

Yük Atma (Load Shedding) Korkaklık Değildir

Birçok yazılım yöneticisi veya mükemmeliyetçi mühendis, sistemdeki bazı servisleri kapatmayı bir "başarısızlık" olarak görür: "Ama müşteriler yorumları okuyamayacak!"

Bu itiraz, dondurucu soğukta dağda mahsur kalmış bir dağcının, "Ama ayak parmaklarım çok üşüyor, kanı tekrar ayaklarıma pompalayın" demesiyle aynı deliliktir. O kanı ayaklarına pompalarsan, 5 dakika sonra donarak ölürsün.

Sistem mühendisliğinde buna Load Shedding (Yük Atma) denir.
Gerektiğinde trafiğin en fuzuli kısmını kapıda acımasızca reddedebilmek (rate limiting, shed load); sistemin çekirdeğini ayakta tutmanın tek yoludur.

Bir fırtınanın ortasında her şeyi aynı anda kusursuzca çalıştırmaya çalışmak cesaret değil; kör bir kibirdir.

Gerçek bir usta; ne zaman tüm gücüyle koşacağını bildiği kadar, kriz anında hangi fuzuli yükleri tereddütsüz feda edeceğini de çok iyi bilendir.

Çünkü hayatta kalmanın birinci kuralı her uzvu korumak değil; kalbin durmasına asla izin vermemektir.

Hasta sedyede acı içinde kıvranıyordur, ailesi gözyaşları içinde kapıda bekliyordur. O sırada elinde bir pano ve tükenmez kalemle bir görevli gelir. Önünüze 8 puntoluk, anlaşılmaz Latince terimlerle ve hukuki jargonla dolu 6 sayfalık bir metin uzatır:
"Şurayı, şurayı ve en altı imzalayın lütfen."

O metinde ne yazar biliyor musunuz?
"Bu ameliyat sırasında kalbiniz durabilir, felç geçirebilirsiniz, enfeksiyon kapabilirsiniz, anestezi komasına girebilirsiniz, organınız zarar görebilir... Bunların hiçbirinde hastanemiz ve hekimlerimiz sorumlu tutulamaz."

Hasta o an neyi imzaladığını idrak edebilir mi? Hayır. Korku ve çaresizlik içindeki bir insanın o metni rasyonel olarak analiz etmesi imkânsızdır. Titreyen ellerle o imzayı atar.

Çünkü herkes bilir ki; o formun birincil amacı hastayı aydınlatmak veya korumak değildir. O formun tek varoluş sebebi; olası bir faciada hastanenin avukatlarına mahkemede sunabilecekleri kurşun geçirmez bir "Sorumluluk Reddi" (Disclaimer) zırhı sağlamaktır. Hukuki açıdan kusursuz, insani ve ahlaki açıdan ise buz gibi bir bürokrasidir.

Peki şimdi elinizdeki akıllı telefonu açın: Yazılım dünyasının "Terms & Conditions" (Kullanıcı Sözleşmeleri) tam olarak bu değil midir?

Dünyanın En Büyük Yalanı: "Kullanım Koşullarını Okudum ve Kabul Ediyorum"

İnternet çağının en evrensel, en organize ve en ikiyüzlü yalanı nedir diye sorsalar, hiç şüphesiz şu cevabı veririm:
"Kullanım koşullarını ve gizlilik politikasını okudum, kabul ediyorum."

Yeni bir uygulama indirirsiniz, bir yapay zeka servisine üye olursunuz veya telefonunuza bir güncelleme gelir. Karşınıza 50 sayfalık, avukatların bilerek en karmaşık cümlelerle ördüğü devasa bir metin bloğu fırlar. Altında ise parlak, mavi bir buton: "Kabul Et".

Carnegie Mellon Üniversitesi'nin yaptığı ünlü bir araştırma var: Eğer sıradan bir internet kullanıcısı, bir yıl içinde karşılaştığı tüm kullanıcı sözleşmelerini gerçekten kelimesi kelimesine okumaya kalksaydı; her gün tam 8 saatini sadece bu sözleşmeleri okumaya ayırmak zorunda kalırdı!

Yani sistem, sizin o metni okumamanız üzerine tasarlanmıştır.

Tıpkı sedyedeki acil hastası gibi; kullanıcı da o an o uygulamaya, o servise, o iletişime muhtaçtır. Dijital dünyanın kapısında rehindir. O butona basmaktan başka hiçbir şansı yoktur.

Ve o butona bastığı an; şirketler kullanıcının konum verilerini satma, fotoğraflarını yapay zeka modellerini eğitmek için kullanma, tek taraflı olarak hesabını silme ve her türlü veri sızıntısında "Ama sözleşmede yazmıştık" diyerek kenara çekilme hakkını ceplerine koyarlar.

Hukuki Kalkan vs. Mühendislik Etiği

Teknoloji şirketlerinin yönetim masalarında sıkça duyduğum mide bulandırıcı bir argüman vardır:
"Sözleşmeye bu maddeyi koyduk, hukuken başımız ağrımaz. Kullanıcı onayladı."

Bir hastaya ameliyattan önce olası 100 farklı komplikasyonun yazılı olduğu bir kâğıdı imzalatmış olmanız; ameliyat sırasında sizin dikkatsizce bir damarı kesmenizi meşru kılar mı? Mahkemede ceza almasanız bile, vicdanınızda o hastanın katili olmaktan kurtulabilir misiniz?

Yazılımda da durum aynıdır.

Kullanıcı sözleşmesine en küçük harflerle "Verileriniz üçüncü partilerle paylaşılabilir" yazmış olmanız; o kullanıcıların en mahrem bilgilerini reklam şirketlerine pazarlamanızı ahlaki kılmaz.
"Hizmet kesintilerinden şirketimiz sorumlu değildir" maddesini koymuş olmanız; test yazmadığınız için bir startup'ın tüm ödeme altyapısını çökerttiğinizde suçsuz olduğunuz anlamına gelmez.

İmza atılan kâğıtlar sadece hukuku ve avukatları korur.
Kullanıcıyı ve hastayı koruyan tek gerçek güç ise; masadaki uzmanın ahlakı, vicdanı ve mesleki namusudur.

Şeffaflık Bir Lütuf Değil, Saygıdır

Modern tıpta son yıllarda bu soğuk onam bürokrasisine karşı harika bir hareket başladı: Hastaya kâğıt imzalatmadan önce gözlerinin içine bakmak, riskleri sade bir dille, metaforlarla, bir dost gibi anlatmak ve gerçek bir rıza üretmek.

Yazılım dünyasının da acilen bu olgunluğa erişmesi gerekiyor:

• Kullanıcının karşısına 50 sayfalık hukuki duvarlar örmek yerine; 3 maddelik, herkesin anlayabileceği sade bir özet sunabilmelisiniz: "1. Verilerinizi kimseye satmıyoruz. 2. İstediğiniz an tüm verilerinizi silebilirsiniz. 3. Sistemimizi güvenle kullanmanız için elimizden geleni yapıyoruz."
• Güvenlik açıklarınızı ve hatalarınızı hukuki bahanelerin arkasına saklamamalı; bir sorun çıktığında şeffaflıkla özür dileyip faturayı üstlenebilmelisiniz.

Çünkü günün sonunda, bir şirketi gerçekten büyük yapan şey kullanıcılarını ne kadar iyi kandırdığı veya sözleşmelerle nasıl bağladığı değildir.

Bir şirketi büyük yapan şey; o parlak "Kabul Et" butonunun arkasında duran insanın güvenine duyduğu sarsılmaz saygıdır.

Şehre yanaşmak isteyen yabancı ticaret gemileri doğrudan limana alınmıyordu. Gemiler, Venedik lagününün açıklarındaki küçük bir adada tam 40 gün boyunca demirli tutuluyordu. İtalyancada "kırk" anlamına gelen quaranta kelimesinden türeyen bu ritüelin adı tarihe altın harflerle kazındı: Karantina.

Mantık son derece yalın ve dehaydı:
Dışarıdan gelen bir gemiyi doğrudan reddedip batıramazsınız; çünkü ticaretin sürmesi gerekir. Ama onu doğrudan şehrin kalbine de sokamazsınız; çünkü içinde veba mikrobu taşıyor olabilir. Yapılacak tek rasyonel şey; onu sınırların hemen dışında, tamamen izole edilmiş, etrafı denizle çevrili steril bir alanda bekletmek, gözlemlemek ve şehre bulaşma riskini sıfırlamaktır.

Bugün modern acil servislerde de bulaşıcı bir patojen (örneğin tüberküloz veya viral bir hemorajik ateş) şüphesi olan bir hasta geldiğinde aynı kural uygulanır:
Hasta hemen Negatif Basınçlı İzolasyon Odasına alınır. Odanın havası dışarıya sızamaz; hava özel HEPA filtrelerden geçirilerek emilir. Kapılar çift kademelidir. Şüpheli organizma kontrol altındadır.

Peki, aynı salgın tehdidi her saniye binlerce yabancı dosya ve veri paketi alan yazılım sistemlerimizde nasıl yönetiliyor?

Dijital Salgın: Üçüncü Parti Paketler ve Kullanıcı Dosyaları

Modern yazılım sistemleri, tıpkı o 14. yüzyıl Venedik limanı gibi dünyanın her yerinden gemi kabul eden açık birer pazar yeridir.

Sisteminizin kapısından içeri her gün;

• Kullanıcıların profil fotoğrafı veya fatura diye yüklediği PDF dosyaları,
• E-posta eklentileri,
• npm install diyerek projenize dahil ettiğiniz, dünyanın öbür ucundaki tanımadığınız bir geliştiricinin yazdığı üçüncü parti açık kaynak kütüphaneler,
• Müşterilerin girdiği karmaşık HTML ve JavaScript kodları akar.

Eğer sisteminizde bir izolasyon mimarisi yoksa; kullanıcının yüklediği masum görünümlü o PDF dosyasının içine gizlenmiş bir zararlı yazılım (malware), ana sunucunuzun kök dizinine (root) erişebilir. Ya da projenize eklediğiniz küçük bir utility kütüphanesi, sunucunuzdaki tüm ortam değişkenlerini (environment variables) ve veritabanı şifrelerini gizlice bir saldırgana sızdırabilir.

Tıpkı vebalı bir denizcinin Venedik sokaklarına karışması gibi; tek bir yabancı paket, tüm şirketi dijital bir salgınla kırıp geçirebilir.

Sandbox: Lagündeki Karantina Adası

İşte siber güvenlik mühendisliğinin bu bulaşma riskine karşı geliştirdiği en kusursuz savunma hattına "Sandbox" (Kum Havuzu / Korumalı Alan) denir.

Sandbox; güvenilmeyen, şüpheli veya potansiyel olarak zararlı bir kod parçacığını, ana işletim sisteminden ve ağdan tamamen yalıtılmış sanal bir kafesin içinde çalıştırma sanatıdır:

1. Tarayıcı İzolasyonu (Chrome Sandbox): Kullandığınız modern tarayıcılar (Chrome, Brave vb.) bu mantıkla çalışır. Açtığınız her bir sekme, işletim sisteminden tamamen izole edilmiş ayrı bir sandbox sürecinde (process) çalıştırılır. Bir sekmede girdiğiniz zararlı bir web sitesi patlasa bile; o sekme çöker ama işletim sisteminize veya yan sekmedeki bankacılık oturumunuza asla sıçrayamaz.
2. Mikro Sanallaştırma (Firecracker / gVisor): AWS Lambda veya modern sunucusuz (serverless) platformları düşünün. Kullanıcıların yüklediği rastgele kodlar, milisaniyeler içinde ayağa kalkan ve işi bittiğinde yok olan mikro sanal makinelerde (MicroVM) çalıştırılır. Kod ana sunucunun donanımına asla doğrudan dokunamaz.
3. Dosya İşleme Odaları: Kullanıcı bir avatar resmi yüklediğinde; o resmi ana uygulama sunucunuzda işlemezsiniz. Onu sadece dosya dönüştürme yetkisi olan, internet çıkışı ve veritabanı erişimi bulunmayan izole bir "karantina container'ına" atarsınız. Eğer resmin içine bir exploit gizlenmişse, o patlama o steril odanın içinde gerçekleşir ve söner.

Bulaşma Riskini Sıfırlamanın Yolu

Birçok yazılımcı güvenliği, sadece "şüpheli görüneni engellemek" (blacklisting) sanır:
"Dosya uzantısı .exe ise içeri alma, .png ise güvenlidir."

Bu, kapıdaki denizcinin sadece yüzüne bakıp "Bu adam sağlıklı görünüyor, içeri girsin" demekle aynı ölümcül saflıktır. Virüsler kendilerini en masum formların içine gizlerler.

Bulaşma riskini yönetmenin tek felsefi yolu şudur:
Dışarıdan gelen her şeyi peşinen potansiyel bir taşıyıcı olarak kabul etmek ve onu kontrollü bir fanusun içine hapsetmektir.

Sisteminizin kapılarını dış dünyaya tamamen kapatamazsınız; çünkü kapıyı kapatırsanız ticaret ölür, inovasyon durur.
Ama içeri giren her yabancı misafire de sarayınızın anahtarlarını veremezsiniz.

Güvenilmeyen her koda, her kütüphaneye ve her dosyaya bir Venedik karantinası uygulayın.
Bırakın o adada 40 gün beklesin.
Bırakın güvenli kum havuzunda oynasın.

Çünkü gerçek güvenlik; fırtınayı durdurmak değil, fırtınanın içeriye sıçrayabileceği tüm pencereleri kurşun geçirmez camlarla mühürleyebilmektir.

Burası insan bedeninin baş zamanlayıcısıdır (Master Clock). Herhangi bir dış müdahaleye, beyinden gelecek bir komuta bile ihtiyaç duymadan; kendi kendine elektriksel aksiyon potansiyeli üretir. Dakikada 70 kez o minik elektriksel kıvılcımı çakar, sinyal kulakçıklardan karıncıklara yayılır ve kalp kasılır: Küt... Küt... Küt...

Bütün biyolojik varoluşumuz, bu hücre kümesinin milisaniyelik bir intizamla zamanı saymasına bağlıdır.

Ancak yaşlılık, enfarktüs veya iletim bozuklukları nedeniyle o doğal zamanlayıcı iflas ettiğinde (örneğin tam kalp bloğu veya ağır bradikardi geliştiğinde); kalp kendi ritmini kaybeder. Nabız 20'ye düşer, beyne kan gitmez ve insan yere yığılır.

O an tıbbın devreye soktuğu dahi mühendislik harikası nedir biliyor musunuz? Yapay Kalp Pili (Pacemaker).

Cerrah köprücük kemiğinin altına küçük, titanyum kaplı bir pil yerleştirir; ucundaki elektrotları kalbin odacıklarına uzatır. Pacemaker sessizce orada bekler. Kalbin kendi ritmini dinler. Eğer kalp vaktinde atmazsa, pacemaker saniyenin binde biri kadar bir hassasiyetle küçük bir elektrik uyarısı gönderir ve kalbe vuruş yaptırır.

Kullanıcı onu görmez. Aynaya baktığında fark etmez. Ön yüzde hiçbir şovu yoktur. Ama o pil durduğu an, hayat biter.

Peki yazılım dünyasında sistemlerimizin ritmini veren, gece gündüz sessizce çalışan o gizli kalp pilleri nelerdir? Cron Job'lar ve Zamanlanmış Görevler (Schedulers).

Ön Yüzün Şovuna Kananlar, Arka Planın Ritmini Görmez

Yazılım geliştiriciler ve ürün yöneticileri, genellikle kullanıcıların doğrudan gördüğü "ön yüz" (frontend) özelliklerine aşık olurlar: Parlak butonlar, akıcı mikro-animasyonlar, yapay zekalı sohbet pencereleri... Şirket içi kutlamalar hep bu ekranlar için yapılır.

Oysa bir teknoloji şirketini gerçekten hayatta tutan şey o pikseller değildir.
Bir şirketi hayatta tutan şey; sunucuların en karanlık köşesinde, kimsenin görmediği bir Linux kabuğunda veya Kubernetes CronJob manifestosunda tıkır tıkır çalışan o sessiz ritimlerdir:

• Her gece saat 00:01'de çalışan ve 50 bin abonenin kredi kartından yenileme ücretini tahsil eden faturalandırma cron'u,
• Her sabah saat 03:00'te veritabanının soğuk yedeğini alıp şifreleyerek farklı bir kıtadaki S3 bucket'ına yükleyen yedekleme script'i,
• Her 5 dakikada bir kuyrukta bekleyen e-postaları ve SMS bildirimlerini dağıtan worker servisi,
• Her saat başı süresi dolmuş oturumları ve geçici token'ları temizleyen boşaltım görevi...

Bu görevler tıpkı o kalp pili gibidir. Arka planda sessizce tıkır tıkır elektrik sinyali gönderirler.

Kalp Pili Durduğunda Ne Olur?

Bir cron job çöktüğünde ne olur biliyor musunuz?
Korkunç olan şudur: Sistem anında hata vermez.

Kullanıcılar siteye girmeye, sayfaları gezmeye ve sepete ürün eklemeye devam eder. Frontend'de tek bir kırmızı uyarı bile çıkmaz. Datadog dashboard'unuz yeşildir.

Ama arka planda kalp pili durmuştur. Aritmi başlamıştır:

• Faturalandırma cron'u çalışmadığı için şirketin kasasına para girmez,
• Yedekleme script'i sessizce patladığı için şirket günlerdir tek bir yedek bile almadan uçurumun kenarında yürümektedir,
• Geçici dosyaları temizleyen cron durduğu için disk alanı megabayt megabayt dolmaktadır.

Ve iki hafta sonra, o kaçınılmaz gün gelir: Disk %100 dolar, veritabanı kilitlenir, şirket tek bir günde binlerce abonesini kaybeder ve yedekten geri dönmek istediklerinde ellerinde hiçbir yedeğin olmadığını dehşet içinde fark ederler.

Bu ani bir ölüm değildir; bu, kalp pili durduğu için organları yavaş yavaş oksijensiz kalarak can veren bir sistemin dramıdır.

Güvenilir Bir Pacemaker Mimarisi

Birçok ekip cron job'ları o kadar amatörce yönetir ki hayret edersiniz: Sunucudaki rastgele bir kullanıcının crontab -e dosyasına yazılmış, logları /dev/nulla yönlendirilmiş, hata verdiğinde kimsenin ruhunun duymadığı yüzlerce sahipsiz komut!

Bu, bir hastaya kalp pili takıp, pilin çalışıp çalışmadığını asla kontrol etmemekle aynı cinayettir.

Eğer sisteminizin kalbini seviyorsanız, şu üç prensibi uygulamak zorundasınız:

1. Ölü Adam Anahtarı (Dead Man's Snitch): Bir cron job hata verdiğinde alarm çalması yetmez; çalışmadığında da alarm çalmalıdır. Kalp pili gibi; eğer beklenen saatte o görevden bir "Ben hayattayım ve görevimi tamamladım" sinyali (heartbeat) gelmediyse, nöbetçi mühendisin telefonu anında çalmalıdır.
2. Tekrar Çalışabilirlik (Idempotency): Bir zamanlayıcı şebeke kesintisi veya sunucu yeniden başlaması yüzünden aynı görevi iki kez çalıştırabilir. Kodunuz öyle tasarlanmalıdır ki; aynı cron job günde 10 kez de çalışsa, bir müşteriden asla iki kez para çekmemelidir.
3. Çakışma Kilitleri (Overlap Locks / Mutex): Beş dakikada bir çalışan bir veri senkronizasyon cron'u, veri hacmi arttığı için 7 dakika sürebilir. Eğer arkadan gelen yeni cron işiyle çakışırsa, veritabanında deadlock patlar. Dağıtık bir kilit (örneğin Redis Redlock) kullanarak aynı görevin üst üste binmesini engellemelisiniz.

Göz önünde olanı parlatmak kolaydır.
Gerçek mühendislik ustalığı ise; kimsenin görmediği, kimsenin alkışlamadığı ama durduğu an tüm organizmayı öldürecek olan o arka plan ritimlerine bir cerrahın titizliğiyle bekçilik edebilmektir.

Sisteminizin kalbini sahipsiz bırakmayın.
O gizli zamanlayıcıların nabzını her saniye hissedin.

En zor görev; o ameliyathanenin veya acil odasının kapısını açıp, koridorda umutla bekleyen bir anneye, bir eşe ya da bir evlada bakıp şu cümleyi kurmaktır:
"Elimizden gelen her şeyi yaptık ama maalesef onu kaybettik."

O an o koridorda yapılacak en ufak bir iletişimsizlik, yanlış seçilmiş tek bir kelime veya gösterilecek soğuk bir kibir; insanların hayat boyu unutamayacağı devasa bir travmaya ve öfke patlamasına yol açabilir.

İşte bu yüzden modern tıp, kötü haber vermeyi hekimlerin anlık duygusal reflekslerine bırakmamıştır. Onkolojide ve acil tıpta dünya çapında kabul görmüş katı bir iletişim protokolü uygulanır: SPIKES Protokolü.

Robert Buckman ve Walter Baile tarafından geliştirilen bu protokol, en karanlık kriz anında bile iletişimin nasıl bir cerrahi zarafetle yürütülmesi gerektiğini 6 adımda emreder:

1. S (Setting up): Doğru ortamı hazırla. Koridorda ayaküstü konuşma; sakin bir odaya geç, göz teması kur, telefonu sessize al.
2. P (Perception): Karşı tarafın algısını ölç. "Şu ana kadar hastanın durumuyla ilgili size neler söylendi?"
3. I (Invitation): Detay sınırını çiz. Bilgiyi ne kadar duymak istiyorlar?
4. K (Knowledge): Kötü haberi doğrudan, dolambaçsız ve jargonsuz ver. Tıbbi Latince terimlerin arkasına saklanma.
5. E (Empathy): Duyguları kabul et ve alan aç. Sessiz kal, öfkeye ya da gözyaşlarına şefkatle eşlik et.
6. S (Strategy & Summary): Bundan sonraki net yol haritasını çiz. "Şimdi atacağımız adımlar şunlar..."

Peki, şimdi bu yüksek duygusal zekayı ve kriz disiplinini alın; yazılım dünyasında sistemlerin çöktüğü, veritabanlarının silindiği o kanlı kriz günlerinin tam ortasına yerleştirin.

"Teknik Bir Aksaklık Yaşanıyor" Yalanı

Bir teknoloji şirketinde production sunucusu çöktüğünde veya büyük bir veri sızıntısı yaşandığında sergilenen kurumsal iletişim performansı genellikle tam bir sefalettir.

Sistem patlamıştır; e-ticaret sitesi çalışmıyordur, kullanıcılar ödeme yapamıyordur.
Yönetim panik içindedir, müşteriler Twitter'da öfkeyle yazıyordur.

Peki mühendislik ekibi veya kurumsal iletişim ne yapar?
Ya kapıları kilitleyip saatlerce hiçbir açıklama yapmazlar (ölüm sessizliği), ya da kullanıcıların zekasıyla alay eden o meşhur kalıp cümleyi sosyal medyaya yapıştırırlar:
"Sistemlerimizde planlı bir bakım çalışması / teknik bir aksaklık yaşanmaktadır. Anlayışınız için teşekkür ederiz."

Müşteri bilir ki o bakım planlı değildir. Müşteri parasının nerede olduğunu, siparişinin akıbetini ve ne zaman düzeleceğini öğrenmek istiyordur. Karşısında şeffaf bir insan bulamayınca da öfkesi çığ gibi büyür; markaya olan güven sıfırlanır.

Kriz anında iletişimi yönetemeyen bir ekip; kodu düzeltseler bile şirketin itibarını mezara gömer.

SPIKES Protokolü ile Kriz İletişimi

Bir yazılım krizinde müşterinize, şirketinizin CEO'suna veya yatırımcılarınıza durumu izah etmek zorundaysanız; tıptaki SPIKES protokolünü klavyenizin başına taşımak zorundasınız:

1. Setting Up (Kriz Masasını Kur)

Gürültüyü kesin. Yüz farklı Slack kanalında dedikodu dönmesine izin vermeyin. Hemen tek bir resmi kriz kanalı (#incident-2026-payment) açın. Bir Incident Commander (Kriz Lideri) ve iletişimi dışarıya aktaracak tek bir İletişim Sorumlusu (Scribe) belirleyin.

2. Perception (Karşı Taraf Neyi Görüyor?)

Müşterinin veya üst yönetimin krizden ne kadar haberdar olduğunu ölçün. Yöneticiniz sadece Twitter'daki 3 şikayeti mi gördü, yoksa cironun durduğunu biliyor mu? İletişime onların bulunduğu gerçeklik zemininden başlayın.

3. Knowledge (Jargonsuz, Çıplak Gerçek)

Yöneticinize veya müşterinize "PostgreSQL WAL dosyalarındaki I/O darboğazı yüzünden connection pool tükendi" demeyin. Bu, bir hasta yakınına "Miyokard enfarktüsü sonrası ventriküler disfonksiyon gelişti" demekle aynı şeydir; sadece kafa karıştırır ve güvensizlik yaratır.
Net konuşun:
"Ödeme servisimiz saat 14:15 itibarıyla yanıt vermeyi durdurdu. Şu an hiçbir kullanıcımızdan tahsilat yapamıyoruz ve yeni sipariş alamıyoruz."

4. Empathy (Acıyı ve Etkiyi Paylaş)

Karşı tarafın stresini ve kaybını kabul edin:
"Bu kesintinin şirketimizin bugünkü cirosunu ve Black Friday kampanyasını ne kadar kritik bir şekilde etkilediğinin tamamen farkındayız. Yaşattığımız aksaklık için ekibim adına samimiyetle özür dilerim."

5. Strategy & Summary (Yol Haritası ve Zaman Sınırı)

İşte krizdeki paniği söndüren ve güveni yeniden inşa eden en hayati adım:

• "Şu an sorunun son deploy edilen koddan kaynaklandığını tespit ettik."
• "Geri alma (rollback) sürecini başlattık."
• "Tahmini toparlanma süremiz 25 dakikadır."
• "Bir sonraki durum güncellemesini saat tam 14:45'te, sorun çözülmüş olsa da olmasa da bu kanaldan paylaşacağım."

Şeffaflık Güven İnşa Eder

İnsanlar krizlerden korkmazlar; insanlar bilinmezlikten ve yalandan korkarlar.

Bir cerrah gözlerinizin içine bakıp dürüstçe "Durum çok kritik ama şu an ameliyathanede her şeyi kontrol altına almaya çalışıyoruz, 20 dakika sonra tekrar bilgi vereceğim" dediğinde içinizdeki o dehşet dalgası sakinleşir. O hekime güvenirsiniz.

Yazılımda da müşterileriniz ve yöneticileriniz kusursuz bir sistem beklemez; çünkü onlar da teknolojinin kırılabileceğini bilirler.
Onların tek beklentisi; kriz anında yalan söylemeyen, teknik jargona sığınmayan, sorumluluktan kaçmayan ve soğukkanlılıkla krizi yönetebilen olgun profesyonellerle çalışmaktır.

Kriz anında panik bulaşıcıdır.
Ama şeffaf, dürüst ve yapılandırılmış bir iletişim; en büyük felaketleri bile sarsılmaz bir sadakate dönüştürebilir.

Türkiye teknoloji ekosistemi, son beş yılda para piyasalarındakinden çok daha tehlikeli ve sessiz bir hiperenflasyona teslim oldu: "Senior" Unvan Enflasyonu.

LinkedIn'i açıp yerel yazılım sektörüne baktığınızda şaşkınlıktan küçük dilinizi yutarsınız. Üniversiteden 2024 yılında mezun olmuş bir gencin profilinde gururla şu yazar:
"Senior Full-Stack Engineer & Team Lead".
Henüz iki yıldır kod yazan bir diğeri: "Lead Software Architect & Tech Evangelist".

Ortalık unvanlardan, apoletlerden ve afili İngilizce tanımlardan geçilmiyor. Şirketler adeta bayram şekeri dağıtır gibi herkese "Senior" unvanı dağıtıyor.

Peki, nasıl oldu da bir zamanlar 8-10 yıllık ağır saha tecrübesi, yüzlerce prod çöküşü ve yüz binlerce satırlık sistem mimarisi gerektiren "Kıdemlilik", bir anda 18 aylık bir stajyerlik süresine indirgendi?

Cevap, Türkiye'nin son yıllarda yaşadığı en büyük kan kaybında gizli: Yetenek İhracı ve Beyin Göçü.

Masanın Boşalan Tarafı

Gelin acı gerçekle yüzleşelim.
Son beş yılda bu ülkede gerçekten ölçeklenme (scaling) görmüş, milyonlarca kullanıcılı sistemleri sırtlamış, veritabanı darboğazlarıyla uykusuz geceler geçirmiş ve mimari disipline sahip olan kıdemli mühendislerin ezici bir çoğunluğu bu toprakları terk etti.

Kimi Berlin'e, kimi Londra'ya, kimi Amsterdam'a göç etti. Kalanların büyük bir kısmı ise evinden çıkmadan ABD veya Avrupa merkezli şirketlere dövizle çalışmaya başladı. Yerel şirketlerin, kur ve enflasyon sarmalında Türk Lirası ile bu mühendislere rekabetçi bir maaş veya insani bir çalışma ortamı sunabilmesi imkânsız hale geldi.

Ve bir sabah, Türkiye'deki kurumsal şirketler, bankalar ve ajanslar uyandıklarında masanın karşısının tamamen boş olduğunu gördüler.

Ortada bir sistem vardı, canlıda çalışan yüz binlerce satırlık legacy kodlar vardı; ama o kodların dilini bilen, kriz anında neşteri nereye vuracağını kestirebilen tek bir "usta" kalmamıştı.

Para Yoksa Unvan Verelim!

Peki yerel yönetimler ve İK departmanları bu devasa boşluğa karşı ne yaptı?
Çalışma koşullarını düzeltmek, mentörlük kültürü kurmak veya gençleri sabırla yetiştirecek bir eğitim akademisi inşa etmek yerine; Türk tipi en kolay şark kurnazlığına sarıldılar: Unvan basmak!

Maaş bütçesi yetmiyor mu? Çocuğun unvanını "Mid-Level" yerine "Senior" yapalım.
Yurt dışına kaçmasın mı? Kartvizitine "Lead Architect" yazalım.

Ve böylece, henüz kendi yazdığı kodun bellek tüketimini ölçemeyen, asenkron programlamanın temel tuzaklarını bilmeyen, bir veritabanı kilitlenmesinde ne yapacağını kestiremeyen 23-24 yaşındaki pırıl pırıl gençlerin omuzlarına devasa "Senior" apoletleri takıldı.

Şirketler kendilerini kandırdı: "Bakın bizim de çok kıdemli bir mühendislik kadromuz var."
Gençler kendilerini kandırdı: "Ben artık kıdemli bir mühendisim."

Ta ki o kaçınılmaz ilk büyük kriz gecesi kapıyı çalana kadar.

Unvan Kodu Kurtarmaz

Bir gün sistem çöker. Müşteriler ayaklanır. Veritabanı yanıt vermez, kuyruklar şişer.

Masada oturan o 22 yaşındaki "Lead Architect"e dönersiniz. Çocuk ekrana bakar, panikler, elleri titrer. Çünkü o kriz anında arkasına sığınabileceği hiçbir LinkedIn unvanı işe yaramaz. O an ihtiyacınız olan şey kartvizitteki parlak harfler değil; o felaketi daha önce 50 kez yaşamış, nabzı 70 atan o eski kurtların soğukkanlılığıdır.

Unvan enflasyonu sadece şirketleri çökertmiyor; en büyük zararı bizzat o genç yazılımcılara veriyor:

1. Gelişimi Durduruyor: Kendisine 2 yılda "Senior" unvanı verilen bir genç, öğrenmeyi bırakır. "Ben zaten en tepeye ulaştım" kibrine kapılır. Oysa gerçek mühendislik yolculuğu tam da o yıllarda başlar.
2. Kırılgan Bir Özgüven İnşa Ediyor: İlk gerçek global mülakata girdiğinde veya yurt dışından bir ekiple yan yana kod yazmaya başladığında, aslında ne kadar yetersiz bırakıldığını görür ve ağır bir depresyona sürüklenir.
3. Teknik Borç Dağları Yaratıyor: Gerçek bir usta gözetiminden geçmeden, sırf "çalışıyor" diye canlıya alınan yamalı kodlar; şirketlerin geleceğini ipotek altına alan devasa bir saatli bombaya dönüşür.

Kıdem Unvanla Değil, Yaralarla Ölçülür

Tıpta hiç kimse 2 yıllık bir asistana "Hadi sen Senior Cerrah oldun, açık kalp ameliyatına tek başına gir" demez. Çünkü orada hata doğrudan mezarlık demektir.

Yazılımda insan hayatı doğrudan masada görünmediği için bu unvan sefahati bu kadar kolay yapılabiliyor. Ama dolaylı olarak batan şirketler, buharlaşan milyonlarca liralık yatırımlar ve tükenen genç hayatlar aynı enkazın parçalarıdır.

Kıdem; LinkedIn profilinizdeki bir kelime değildir.
Kıdem; prod ortamında kaç kez yere düştüğünüz, kaç felaketten sistemi sağ salim çıkardığınız ve arkanızdan gelen kaç gence rehberlik edebildiğinizle ölçülür.

Kendinize ve sektöre bir iyilik yapın:
Ucuz unvanların sahte sarhoşluğuna kapılmayın.
Apoletlerin peşinde değil; gerçek ustalığın, sabırlı tecrübenin ve o sessiz zanaatın peşinde koşun.

Çünkü kriz anında sizi kurtaracak olan şey unvanınız değil; kodun başında akıttığınız o gerçek terdir.

Havada yoğun bir Silikon Vadisi kokusu vardır: "Disrupt ediyoruz", "Scale edeceğiz", "Pre-seed turundayız", "Pivota hazırlanıyoruz"...

Kulağa ne kadar havalı ve küresel geliyor, değil mi? Sanki Palo Alto'da, Y Combinator'ın garajında yeni bir Stripe veya Airbnb doğuyormuş gibi.

Ama o cam kapıyı kapatıp şirketin finansal gerçeklerine, gelir tablolarına ve kod tabanına yakından baktığınızda; karşınıza çıkan şey bir teknoloji girişimi değil, trajikomik bir "Şark Tipi Hibe ve Ajansçılık Tiyatrosu"dur.

"Grantpreneur" (Hibe Avcıları) Çağı

Gelin açık konuşalım.
Türkiye'deki binlerce sözde "start-up"ın çok büyük bir kısmının geliştirdiği ürün, gerçek dünyadaki hiçbir müşterinin umrunda bile değildir.

Üç yıldır kurulan o "devrimsel" yapay zeka platformunun henüz tek bir ödeyen müşterisi (paying customer) yoktur. Ürünün pazarda bir karşılığı (Product-Market Fit) yoktur. Sistem gerçek bir kullanıcı yükü görmemiştir.

Peki bu şirketler yıllardır o lüks ofislerde nasıl hayatta kalıyor, o mühendislerin maaşları nasıl ödeniyor?

Cevap basittir: TÜBİTAK, KOSGEB ve Kalkınma Ajansı Destekleri.

Türkiye'de son yıllarda "Girişimci" kılığında dolaşan ama aslında tam zamanlı birer "Hibe Avcısı" (Grantpreneur) haline gelmiş koca bir kitle türedi. Bu ekiplerin en büyük uzmanlığı yazılım mimarisi veya ürün yönetimi değildir; onların asıl uzmanlığı devlet teşvik şartnamelerinin arasına süslü akademik kelimeler serpiştirmek, komisyon üyelerini etkileyecek PDF raporları hazırlamak ve her yıl yeni bir hibe paketiyle şirketin ömrünü 12 ay daha uzatmaktır.

Bir proje biter, hibe tükenir; hemen yeni bir dosya açılır: "Bu kez blokzincir tabanlı tarım yapay zekası yapıyoruz!"
Yine hibe alınır, yine faturalar kesilir ama ortada yine çalışan, satılan tek bir satır gerçek ürün yoktur.

Bu bir inovasyon ekosistemi değildir; bu, kamu kaynaklarının tatlı suyuna hortum bağlamış birer suni teneffüs organizasyonudur.

Gündüz "Start-up", Gece "Merdiven Altı Ajans"

Hibe avcısı olmayan diğer start-up'ların düştüğü ikinci büyük tuzak ise "Gizli Ajansçılık"tır.

Ekip bir SaaS (hizmet olarak yazılım) ürünü geliştirmek üzere yola çıkmıştır. Ancak Türkiye'de risk sermayesi (Venture Capital) sığ olduğu ve ürün geliştirmek sabır istediği için kasa hızla boşalır.

Ve bir gün kurucu ortak masaya oturur: "Arkadaşlar, kasada para bitti. Bir tanıdığın inşaat firmasına web sitesi ve muhasebe programı yazacağız. 2 aylık bir iş, paramızı alıp hemen kendi ürünümüze döneriz."

O an, o start-up'ın ölüm fermanı imzalanmış olur.

Çünkü o 2 aylık iş asla 2 ayda bitmez. Ardından başka bir müşterinin mobil app işi gelir, sonra bir e-ticaret entegrasyonu...
Ve sonuçta; gündüz yatırımcı sunumlarında "Biz küresel bir B2B SaaS platformuyuz" diye sunum yapan, geceleri ise müşteriden 5 bin lira tahsil edebilmek için saatlerce WhatsApp'ta kavga eden yorgun, kafası karışık ve tükenmiş birer fason yazılım atölyesine dönüşürler.

Kendi ürünlerinin kodu deponun köşesinde paslanır; mühendisler ise dışarıdan gelen fason biletlerin altında ezilip gider.

Masa Tenisi Masası Google Yapmaz

Türkiye'deki start-up kültürünün en büyük yanılgısı; Silikon Vadisi'nin sonuçlarını, başarının sebebi zannetmesidir.

Ofise langırt masası koyarak, çalışanlara "esnek çalışma" adı altında armut koltuk vererek ve İngilizce terimlerle konuşarak Google veya Meta olunmaz. Google'ı Google yapan şey ofisindeki ücretsiz atıştırmalıklar değildi; dünyanın en zeki mühendislerinin geliştirdiği, arkasında sarsılmaz bir matematik yatan algoritmik üstünlük ve acımasız ürün odağıydı.

Biz ise özü kaçırıp sadece şekli kopyaladık.
Sonuç? Sahnede fırtınalar estiren ama fatura kesemeyen zombi şirketler.

Gerçek Girişimcilik Nerede Başlar?

Gerçek teknoloji girişimciliği; yatırımcı sunumundan sunumuna koşup kartvizit dağıtmak değildir.
Gerçek girişimcilik; hibe formları doldurmakla da başlamaz.

Gerçek girişimcilik; bir insanın veya bir şirketin kanayan gerçek bir yarasını bulmak, o yarayı en sade ve sağlam teknolojiyle iyileştirmek ve o insanın helal parasını tahsil edebilme cesaretini göstermektir.

Tek bir ödeyen müşterinin cebinden çıkan 100 dolar; devletten aldığınız 1 milyon liralık karşılıksız hibeden bin kat daha değerlidir. Çünkü o 100 dolar, piyasanın sizin emeğinize verdiği gerçek bir onay damgasıdır.

Langırt oynamayı bırakın.
Hibe dosyalarını kapatın.
Ve kendinize o en acımasız soruyu sorun:
"Eğer devlet desteği olmasaydı, benim bu yazdığım yazılıma dünyada tek bir kişi bile 10 dolar verir miydi?"

Eğer bu sorunun cevabı "Hayır" ise; yaptığınız şey girişimcilik değil, sadece çok pahalı ve süslü bir hobidir.

Bir kod yazdığınızda; derleyici (compiler) sizin hangi üniversiteden mezun olduğunuza, babanızın kim olduğuna, hangi siyasi partiye oy verdiğinize veya kimin yeğeni olduğunuza bakmaz. Eğer bir parantezi yanlış kapattıysanız, dünyanın en zengin insanı da olsanız o kod derlenmez. Eğer algoritmanız $O(n^2)$ karmaşıklığındaysa ve veritabanını kilitliyorsa, arkasında hangi holding olursa olsun o sunucu çöker.

Bilgisayar bilimi insan zaaflarından arınmış, kuralları matematik tarafından çizilmiş steril bir adalet evrenidir.

Ama ne yazık ki, terminalden başınızı kaldırıp Türkiye'deki kurumsal teknoloji sektörünün, yazılım ihalelerinin ve şirket yönetimlerinin dünyasına adım attığınızda; o steril matematik evreni bir anda buharlaşır.

Yerini bu toprakların en kadim ve en çürütücü virüsüne bırakır: "Bizim Çocuk" Mantığı ve Feodal Referans Ağları.

Mimariyi İhtiyaç Değil, İlişkiler Belirler

Türkiye'deki büyük bir kurumsal şirkette veya kamuya iş yapan bir yapıda teknoloji kararlarının nasıl alındığını hiç yakından izlediniz mi?

Normalde rasyonel bir dünyada süreç şöyle işlemelidir: Şirketin bir problemi vardır, mühendislik ekibi toplanır, farklı teknolojilerin kıyaslaması (benchmarks) yapılır, maliyet ve performans analiz edilir ve en doğru araç seçilir.

Peki bizde gerçekte ne olur?

Masaya oturulur. Şirketin CTO'su veya Genel Müdür Yardımcısı der ki:
"Biz bulut altyapısı olarak X firmasıyla, kurumsal yazılımda da Y firmasıyla çalışacağız."

Mühendisler şaşırır: "Ama efendim, Y firmasının çözümü bizim işimize hiç uymuyor, inanılmaz hantal ve maliyeti üç katı. Açık kaynaklı Z çözümüyle bu işi 2 ayda ve onda bir fiyata çözeriz."

Yönetici bıyık altından gülümser. Çünkü o Z çözümünün bir komisyonu yoktur. Çünkü Y firmasının Türkiye genel müdürü, yöneticinin üniversiteden oda arkadaşıdır. Çünkü hafta sonu beraber golf oynanmıştır, çünkü ihaleyi alan ajansın yönetim kurulu üyesi "bizim tanıdıktır".

Ve sonuç? Şirket milyonlarca liralık lisans paraları öder. Yıllarca çalışmayan, personelin hayatını zindana çeviren ucube sistemlerle boğuşulur.

Türkiye'de en iyi mimari değil; kararı veren yöneticiye en yakın olan teknoloji kazanır.

GitHub Profili vs. "Kartvizit Torpili"

Aynı liyakatsizlik virüsü, istihdam süreçlerinin de can damarını kesmiş durumdadır.

Bir yanda 22 yaşında pırıl pırıl bir genç vardır. Anadolu'nun bir şehrinde kendi imkânlarıyla gecesini gündüzüne katmış, GitHub profilini açık kaynak projelerle doldurmuş, Linux çekirdeğini hatmetmiş, İngilizce dokümanları yutmuş, gerçek bir mühendislik tutkusuyla yanan bir cevher. İşe başvurur; ama İK'nın otomatik filtresini veya torpil bariyerini aşamaz. CV'sine bakılmaz bile.

Diğer yanda ise yöneticinin askerlik arkadaşının yeğeni vardır. İki satır kod yazmaktan acizdir, temel veri yapılarından habersizdir ama mülakata "falan beyin referansıyla" girer. Ve iki gün sonra şirkete "Senior Yazılım Uzmanı" olarak atanır.

Sonra ne olur?
O liyakatli genç, ülkeye ve sektöre küser. İlk fırsatta yurt dışına kaçmanın yollarını arar.
Şirkette kalan o "tanıdık" ise sistemin en kritik yerinde hatalar üretmeye başlar. Ama kimse ona dokunamaz; çünkü arkasında görünmez bir akraba zırhı vardır. O hatanın faturasını ise gece yarısı uykusuz kalarak sistemi kurtarmaya çalışan diğer dürüst mühendisler öder.

Çürümenin Bedeli Ağır Olur

Liyakatsizlik sadece etik bir problem değildir; teknik bir iflastır.

Siz bir cerrahı "tanıdık" diye ameliyata alırsanız, hasta masada kalır.
Siz bir yazılım mimarisini veya ekibini "ilişkiler" üzerinden kurarsanız; günün birinde o sistem canlıda çöker ve altında tüm şirket ezilir.

Yıllarca feodal ilişkilerle, şişirilmiş ihalelerle ve tanıdık şirketlerle ayakta tutulan devasa yapıların; gerçek bir küresel krizde veya yabancı bir rakiple karşılaştıklarında nasıl kâğıttan kaplanlar gibi dağıldığını defalarca gördük.

Çünkü sunucu işlemcisi torpil tanımaz.
Network paketleri kartvizite saygı duymaz.
Bellek sızıntısı akrabalık bağı dinlemez.

Eğer bu ülkeden gerçekten dünya çapında bir teknoloji ekosistemi çıkmasını istiyorsak; o karanlık referans ağlarını, o sahte ahbap-çavuş ilişkilerini terminalin kapısında bırakmak zorundayız.

Masaya oturduğunuzda kimin yeğeni olduğuna değil; kodun kalitesine, mühendislik namusuna ve dürüst emeğe bakın.

Çünkü sistemi ayakta tutan şey tanıdıklar değil; o kodun arkasındaki saf ve lekesiz liyakattir.

Kulağa ne kadar çağdaş, ne kadar Avrupai ve özgürlükçü geliyor, değil mi?

Medeni bir dünyada esnek çalışma saatinin tanımı çok basittir: İster sabah 7'de başla öğleden sonra 3'te bitir, ister gece çalış; ama haftalık 40 saatlik yasal emek sınırını aşma. İşini yap ve geri kalan zamanda kendi hayatını yaşa.

Peki, Türkiye şartlarına geldiğimizde bu kavram nasıl bir ucubeye dönüştü?

Türkiye'deki yazılım ve teknoloji ekosisteminde "Esnek Çalışma"; mesainin sınırlarının tamamen ortadan kaldırılması ve yazılımcının haftanın 7 günü, günün 24 saati şirketin tapulu mülkü haline getirilmesi demektir.

Gece 02:30: "Ufak Bir Şey Var, Bakabilir misin?"

Cuma akşamı mesainizi bitirmiş, sevdiklerinizle oturmuş dinleniyorsunuzdur.
Saat gece 02:30. Telefonunuz çalar ya da Slack'ten bildirim düşer:
"Canım kusura bakma rahatsız ediyorum, canlıda ufak bir sorun var da müşteriler şikayet ediyor, bir bakıver sana zahmet."

O "ufak sorun" asla ufak değildir. Bilgisayarı açarsınız. Veritabanı şişmiştir, üçüncü parti bir API patlamıştır. Gece 02:30'da başladığınız debug seansı, sabah ezanı okunurken, saat 06:00'da kan çanağına dönmüş gözlerle hotfix atılarak biter.

Peki sonra ne olur?

Pazartesi günü geldiğinde kimse size "Sen cuma gecesi şirket için 4 saat uykusuz kaldın, işte fazla mesai ücretin" demez. Kimse "Bugün dinlen, işe gelme" demez. Hatta sabah saat 09:30'daki "Daily Scrum" toplantısına iki dakika geç kalsanız, aynı yönetici kaşlarını çatarak size hesap sorar.

O geceki emeğiniz ne olmuştur?
O emek, şirketin o meşhur manevi kasasına hibe edilmiştir. Adı da "Mühendislik Sorumluluğu" ve "Aidiyet Duygusu" konulmuştur.

Paramedik Nöbeti vs. Yazılımcı Köleliği

Bir paramedik olarak 112 ambulansında 24 saatlik nöbet sisteminde çalıştım.
Evet, 24 saat boyunca uyumazsınız. Kanla, krizle ve ölümle savaşırsınız.

Ama o sistemin arkasında çok net, yazılı ve tavizsiz bir hukuk vardır:

• Nöbete girdiğiniz saat bellidir, çıktığınız saat bellidir.
• Tuttuğunuz her bir fazla saatin nöbet ücreti ve risk tazminatı kuruşu kuruşuna ödenir.
• Ve en önemlisi: 24 saatlik nöbetten çıktığınız an, devlet size kanunen en az 48 saat kesintisiz dinlenme hakkı tanır. O 48 saat boyunca hiç kimse sizi arayamaz, hiç kimse "Hadi gel bir vakaya daha bakıver" diyemez. Çünkü yorgun bir sağlıkçının bir sonraki hastayı öldüreceğini herkes bilir.

Peki yazılım dünyasında ne oluyor?

Gece 04:00'e kadar prod sunucusunu ayakta tutmak için ter döken yazılımcıdan; sabah saat 09:00'da kamerasını açıp gülücükler saçarak yeni sprint biletlerini planlaması bekleniyor!

Yorgun bir beynin ertesi gün yazacağı kodun yeni facialar doğuracağını kimse umursamıyor. Çünkü bu sektörde beden ve zihin, tükenene kadar sömürülebilecek bedava birer kaynak olarak görülüyor.

"Biz Burada Bir Aileyiz" Ninnisi

Bu ücretsiz sömürü çarkının en zehirli yakıtı, o meşhur kurumsal manipülasyondur: "Biz bir aileyiz."

Sizden hafta sonu çalışmanız istendiğinde, bayram tatilinde laptop başında nöbet tutmanız beklendiğinde hep aynı duygu sömürüsü devreye sokulur: "Şirketimiz zor bir dönemden geçiyor, hepimiz elimizi taşın altına koymalıyız."

İyi de, şirket yıl sonunda rekor kâr açıkladığında veya milyonlarca dolarlık yatırım aldığında o kârı aile üyeleri gibi eşit paylaşıyor muyuz? Hayır. O kâr kurucuların ve hissedarların kasasına giriyor; yazılımcıya ise sadece bir teşekkür e-postası ve belki ofiste ısmarlanan soğuk bir pizza düşüyor!

İş kâra gelince katıksız bir kapitalist şirket; iş fedakarlığa ve gece uykusuz kalmaya gelince "fedakar bir aile"... Bu ikiyüzlülüğe artık dur demek zorundayız.

Sınır Çizmek Profesyonelliktir

Bir insanın mesai saatleri dışında bilgisayarını kapatması, hafta sonu gelen şirket aramalarına bakmaması "sorumsuzluk" veya "tembellik" değildir.
Bu, ruh sağlığını ve mesleki sürdürülebilirliğini koruma disiplinidir.

Eğer bir şirketin sistemleri geceleri sürekli çöküyorsa; bunun çözümü mühendislerin gecelerini çalmak değildir. Bunun çözümü; sağlam bir altyapı kurmak, nöbet tutan mühendise yasal nöbet ücretini (On-Call Compensation) ödemek ve ertesi gün ona dinlenme izni vermektir.

Ücretsiz mesai bir fedakarlık değildir. Ücretsiz mesai; işverenin kötü yönetiminin ve vizyonsuzluğunun faturasını kendi gençliğinizle ödemektir.

Emeğinize saygı duyun.
Mesainiz bittiğinde o kapağı kapatmayı bilin.

Çünkü siz bir şirketin kölesi değilsiniz; siz fikriyle, zihniyle ve uzmanlığıyla değer üreten bağımsız birer profesyonsunuz.

Kulağa ne kadar pürüzsüz, ne kadar büyüleyici bir rüya gibi geliyor, değil mi?

Şimdi gelin, aynı zekaya, aynı teknik yetkinliğe ve belki çok daha sağlam bir kod mimarisine sahip olan Türkiyeli bir yazılımcının aynı yola çıktığında yaşadığı o akıl almaz bürokratik ve operasyonel cehenneme bakalım.

Bizim hikayemiz kod bittiğinde değil; tam olarak o kod bittikten sonra başlar.

Başlangıç Çizgisinde Vurulan Pranga: PayPal ve Stripe Yokluğu

Bir yazılım ürünü geliştirmek zordur; ama Türkiye'den dünyaya o yazılımı satabilmek, adeta iki kolunuz arkadan bağlıyken okyanusu yüzerek geçmeye benzer.

2016 yılında, yerel regülasyonlar ve bürokratik inatlaşmalar yüzünden dünyanın en yaygın ödeme altyapısı olan PayPal bu ülkeden kovuldu. Ardından modern internet ekonomisinin kalbi olan Stripe, Türkiye'deki şirketlere ve banka hesaplarına kapılarını tamamen kapattı.

Düşünebiliyor musunuz?
Dünyadaki herhangi bir insanın kredi kartını çıkarıp tek tıkla abonelik başlatabileceği küresel finansal otobanların tamamından bu ülkenin gençleri mahrum bırakıldı.

Avrupalı veya Amerikalı akranınız enerjisinin %95'ini ürünün kalitesine, kullanıcı deneyimine ve pazarlamaya harcarken; Türkiyeli geliştirici enerjisinin %80'ini şu saçma sapan sorularla tüketmek zorunda kalır:

• "Estonya'dan e-Residency alıp orada şirket mi kursam, yoksa Delaware'de bir LLC mi açsam?"
• "Mercury veya Wise hesabı açarken Türkiye pasaportumu ve IP adresimi görürlerse hesabımı dondururlar mı?"
• "Paddle mı kullansam, LemonSqueezy mi? Hangisi Merchant of Record olarak KDV'yi çözer?"
• "Estonya'daki şirketten Türkiye'deki şahıs hesabıma para çekerken yerel vergi dairesi kapıma dayanıp benden yüzde kaç vergi ve ceza keser?"

Daha tek bir satır kod satamadan, 22 yaşındaki bir yazılım mühendisi uluslararası vergi hukuku uzmanına, offshore şirket danışmanına ve finansal akrobata dönüşmek zorundadır!

İki Kat Efor, Yarı Kat Sonuç

Yerel ödeme sağlayıcılarıyla (İyzico vb.) dünyaya açılmaya çalıştığınızda ise bambaşka bir duvara çarparsınız:
Amerikalı bir müşteri sitenize girer. Kartını girmek ister; karşısına Türk bankalarının o meşhur, hantal, yabancı kartlarda sürekli patlayan ve SMS şifresi (3D Secure) isteyen ödeme ekranı çıkar. Amerikalı kullanıcı o ekranı gördüğü an "Bu site beni dolandırıyor galiba" diyerek sekmeyi kapatır ve kaçar.

Çünkü küresel pazarın bir standardı vardır: Stripe pürüzsüzlüğü ve PayPal tek tık güveni.
Siz o standardı sunamadığınız an, dünyanın en muazzam algoritmasını da yazmış olsanız dönüşüm oranınız (conversion rate) sıfıra çakılır.

Biz daha yarışa başlamadan, küresel sistem bizi 1-0 değil, 5-0 geride başlatır.

Bürokrasinin Boğduğu Milyon Dolarlar

Türkiye'de her yıl teknoloji zirvelerinde politikacılar ve bürokratlar kürsüye çıkıp hamasi nutuklar atarlar:
"Yazılım ihracatımızı 10 milyar dolara çıkaracağız! Milli teknoloji hamlesi! Gençlerimizin arkasındayız!"

İyi de, arkasında olduğunuz o gencin dünyaya 5 dolarlık bir yazılım satabilmesi için Londra'da paravan şirket kurmak zorunda kalmasını neden görmezden geliyorsunuz?

Bir ülkenin gençlerinin ürettiği katma değerin vergisini, stopajını ve banka komisyonunu neden Estonya devleti, İngiltere hükümeti veya Amerikan bankaları topluyor? Çünkü bizim hantal regülasyonlarımız ve yasakçı zihniyetimiz, teknolojinin hızına yetişemeyecek kadar çağ dışı kaldı.

Bugün Türkiye'den çıkıp küresel pazarda milyonlarca dolar ciro yapan mikro-SaaS kurucuları varsa; onlar devletin veya ekosistemin desteğiyle değil; bütün bu operasyonel işkencelere ve engellere rağmen başarmış birer modern çağ mucizesidir.

Prangaları Kıracak Olanlar Yine Biziz

Bütün bu karamsar tabloya rağmen umut nerede biliyor musunuz?
Umut, bütün bu bürokratik engellere rağmen yılmayan, VPN arkasından şirket kuran, uluslararası vergi labirentlerini çözen ve odasından dünyaya kod ihraç etmeye devam eden o inatçı genç mühendislerdedir.

Biz coğrafyanın kader olduğu bir toprağın çocuklarıyız. Bizim işimiz hiçbir zaman kolay olmadı.

Ama şunu unutmayın: Kolay şartlarda yetişenler sadece rüzgar gülü olur; fırtınanın içinde direnenler ise devasa çınarlara dönüşür.

PayPal'ımız olmayabilir, Stripe kapalı olabilir, sistem bizi geriden başlatabilir.
Ama aklımız, mühendislik namusumuz ve terminalimizin başında sabahlara kadar döktüğümüz o saf emek yerinde duruyor.

Ve o emek, günün birinde o köhne bürokrasinin ördüğü tüm duvarları yerle bir edecek kadar güçlüdür.

Karşınızdaki kişi arkasına yaslanır, ses tonunu bir sır paylaşıyormuş gibi gizemli bir şekilde alçaltır ve gözlerini kısarak o cümleyi fısıldar:
"Kardeşim, benim aklımda öyle bir proje var ki... Bak yemin ediyorum Türkiye'de tek, dünyada bile benzeri yok. Uber gibi ama sadece halı yıkamacılar için (veya Getir gibi ama ikinci el oto sanayi parçaları için). Voleyi vuracağız!"

Ve hemen ardından o muazzam teklif masaya bırakılır:
"Fikir tamamen benden. Sen zaten bilgisayardan anlıyorsun, iki tık tık kodlarsın. Yüzde elli yüzde elli ortak olalım. Ben işin fikrini verdim, sen de teknik tarafını hallediver."

O an karşınızdaki insanın yüzüne bakarken; hem gülmek, hem ağlamak, hem de masadan sessizce kalkıp kaçmak istersiniz.

Çünkü bu topraklarda yazılımın, mühendisliğin ve zihinsel emeğin nasıl algılandığına dair bütün cehalet ve çarpıklık, işte bu tek bir cümlede kristalize olmuştur.

Derek Sivers ve Fikrin Sıfır Değeri

Girişimci ve yazar Derek Sivers'ın bütün dünyada yankı uyandıran çok basit ama sarsıcı bir formülü vardır:
Fikir tek başına sadece bir çarpandır (multiplier). İcraat (execution) ise asıl değerdir.

Sivers bu formülü şöyle matematikselleştirir:

• Berbat Fikir: -1
• Vasat Fikir: 1
• Harika Fikir: 10
• Dahice Fikir: 20

Peki ya icraat?

• Hiç İcraat Yok: 1 Dolar
• Kötü İcraat: 100 Dolar
• İyi İcraat: 10.000 Dolar
• Mükemmel İcraat: 1.000.000 Dolar

Eğer elinizde dünyanın en dahice fikri (20) bile olsa, ortada tek bir satır çalışan kod, tek bir ödeyen müşteri, tek bir operasyonel süreç yoksa; o fikrin toplam değeri: 20 x 1 Dolar = 20 Dolardır.

Fikir, zihnin en ucuz, en zahmetsiz ve en bedava ürünüdür. Duşta yıkanırken veya trafikte otururken herkes günde on tane "dahice" uygulama fikri bulabilir. Dünyadaki mezarlıklar, zamanında "muazzam bir fikrim vardı" diyen ama tek bir adım bile atmamış milyonlarca insanın hayaletleriyle doludur.

Oysa o fikri çalışan bir ürüne dönüştürmek; geceler boyu kod yazmak, sunucu mimarisi kurmak, veritabanı kilitlenmelerini çözmek, kullanıcı arayüzü tasarlamak ve müşteri şikayetlerini sırtlamak demektir.

"Ben fikri verdim, sen iki satır kodla" diyen insan; aslında "Ben arsanın hayalini kurdum, sen 15 katlı gökdeleni dik, daireleri yarı yarıya bölüşelim" demektedir.

Kod Bittiğinde Asıl Cehennem Başlar

Akraba ve arkadaş çevresinin bir türlü idrak edemediği en büyük yanılgı, yazılımın "bir kez yapılıp biten" statik bir inşaat olduğunu sanmalarıdır: "Kodu yaz, App Store'a yükle, sonra yan gelip paraları sayalım."

Oysa her gerçek mühendis bilir ki; kodun ilk versiyonunu yazıp yayına almak, maratonun sadece başlangıç ısınmasıdır.

Gerçek savaş o kod bittikten sonra başlar:

• Her ay tıkır tıkır ödenmesi gereken AWS ve sunucu faturalarını kim ödeyecek?
• Gece saat 03:00'te ödeme gateway'i çöktüğünde yatağından fırlayıp kim debug edecek?
• Apple'ın veya Google'ın her yıl zorunlu kıldığı yeni SDK güncellemelerini, politika değişikliklerini kim takip edecek?
• Müşterilerden gelen "Param çekildi ama siparişim görünmüyor" öfkesini kim göğüsleyecek?

O "fikir babası" ortakların hiçbirini o gece nöbetlerinde bulamazsınız. Sunucu faturası geldiğinde hepsi birden buharlaşır. Çünkü onlar sadece başarının ve paranın ortağı olmak ister; çilenin, sorumluluğun ve maliyetin ortağı olmayı akıllarının ucundan bile geçirmezler.

Sınır Çizme Rehberi: "Fikir Ortaklarına" Ne Demeli?

Bir yazılımcı olarak akıl sağlığınızı, zamanınızı ve insan ilişkilerinizi korumak istiyorsanız; bu tür tekliflere karşı cebinizde hazır, nazik ama granit gibi sert cevaplar bulundurmak zorundasınız:

1. "Benim Saatlik Danışmanlık Ücretim Şu Kadar": Fikrinden o kadar emin olan birine şunu söyleyin: "Fikrin gerçekten harika görünüyor. Ben hisse karşılığı ortak olmuyorum ama profesyonel olarak bu ürünü geliştirebilirim. Saatlik geliştirme ücretim 50 dolar, tahmini geliştirme süresi 400 saat. Eğer bu yatırımı yapmak istersen sözleşmeyi hazırlayalım." Göreceksiniz ki o "milyar dolarlık vizyoner", saniyesinde konuyu değiştirip havalardan bahsetmeye başlayacaktır.
2. "Önce Pazar Araştırmasını Sen Yap": "Harika fikir! O zaman sen önümüzdeki hafta git, bu işi yapacak 50 tane halı yıkamacıyla görüş. Onlara 'Böyle bir uygulama çıksa ayda 500 lira öder misiniz?' diye sor ve niyet mektubu imzalat. Geldiğinde kodu hemen yazmaya başlarım." Bir haftanın sonunda o 50 kişiyle asla görüşülmediğini göreceksiniz; çünkü fikir ucuzdur ama sokağa çıkıp icraat yapmak zordur.

Fikirlerin hiçbir değeri yoktur; değer sadece ve sadece ter döken, sorumluluk alan ve sistemi ayakta tutan icraattadır.

Siz bir fikir hamalı değilsiniz. Yıllarca dirsek çürüterek kazandığınız o kıymetli mühendislik zanaatınızı, ucuz kahve sohbetlerinin ve bedavacı heveslerin sermayesi yapmayın.

Bırakın onlar fikirleriyle zengin olsun; siz çalışan, nefes alan ve gerçek değer üreten kodlarınızla usta kalın.

Çünkü şirketinizin teknik altyapıdan zerre kadar anlamayan, ama kendini "vizyoner teknoloji lideri" sanan yöneticisi, hafta sonunu LinkedIn'de, Medium'da ve yabancı teknoloji bültenlerinde geçirmiştir. Orada dönemin en popüler, en cilalı ve en havalı "buzzword"lerini (moda sözcüklerini) görmüştür:
"Event-Driven Architecture", "Micro-Frontends", "Serverless", "AI-Agent Swarms", "Rust ile yeniden yazım", "GraphQL"...

Pazartesi sabahı toplantı odasına girer. Gözlerinde tehlikeli bir ışıltı vardır. Masaya bir sunum slaytı fırlatır ve o ölümcül cümleyi kurar:
"Arkadaşlar, sektör nereye gidiyor görmüyor musunuz? Biz hâlâ monolitik yapıda kaldık. Tüm mimariyi acilen event-driven mikroservislere bölüyoruz ve araya Kafka koyuyoruz!"

Mühendislik ekibi dehşetle birbirine bakar.
Bir kıdemli mühendis çekinerek söz alır: "Efendim, bizim sitemizi günde sadece 1.500 kişi ziyaret ediyor. Veritabanımızda saniyede 3 tane sorgu dönüyor. Mevcut Node.js ve PostgreSQL monolitimiz tıkır tıkır çalışıyor, yanıt sürelerimiz 40 milisaniye. Neden Kafka'ya veya 20 tane mikroservise ihtiyacımız olsun ki?"

Yönetici küçümseyici bir tebessümle bakar: "Siz vizyonsuzsunuz. Ölçeklenmeye (scale) hazırlıklı olmalıyız. İki ay içinde bu dönüşüm bitecek."

Ve şirketin yavaşlatılmış ölüm süreci resmen başlar.

Resume-Driven Development (CV Odaklı Mühendislik)

Bu akıl tutulmasının bilgisayar bilimlerindeki adı çok nettir: Resume-Driven Development (RDD) — yani "Özgeçmiş Odaklı Geliştirme".

O yöneticinin derdi şirketin performansını artırmak, kullanıcı deneyimini iyileştirmek veya altyapı maliyetlerini düşürmek değildir.
Onun tek bir derdi vardır: Bir sonraki iş başvurusunda CV'sine "Şirketin monolitik yapısını başarıyla event-driven mikroservis mimarisine taşıdım" yazabilmek. Bir de LinkedIn'de "Büyük Mimari Dönüşüm Yolculuğumuz" başlığı altında 500 beğeni alacak sahte bir başarı hikayesi paylaşabilmek!

Şirketin parası, mühendislerin geceleri ve projenin geleceği; bir yöneticinin kişisel markalama egosuna kurban edilir.

Yamalı Bohçaya Dönen Altyapılar: Teknoloji Çöplüğü

Peki bu sürecin sonunda ne olur?

İki yıl sonra o şirketin kod tabanını açtığınızda, tam bir arkeolojik teknoloji çöplüğüyle karşılaşırsınız:

• Bir kısmı 2021'de dönemin modası diye Go ile yazılmış ve yarıda bırakılmış,
• Bir kısmı 2023'te LinkedIn'de görüldü diye Rust ile başlanmış ama yazan kişi işten ayrılınca sahipsiz kalmış,
• Araya Kafka konulmuş ama kimse konfigürasyonunu bilmediği için kuyruklar sürekli patlayan,
• Dört farklı veritabanının (Postgres, Mongo, Redis, Elastic) birbirine koli bandıyla bağlandığı, kimsenin baştan sona nasıl çalıştığını anlayamadığı ucube bir Frankeştayn!

Sistem eskisinden 10 kat daha yavaş çalışır. Hata ayıklamak (debug) imkânsız hale gelir. Basit bir buton eklemek için 6 farklı servise PR açmak gerekir. Bulut faturası 5 katına fırlamıştır.

Ve en trajik olanı nedir biliyor musunuz?
O kararı aldıran "vizyoner" yönetici, o enkaz daha patlamadan önce başka bir kurumsal şirkete transfer olmuş; orada da aynı zehirli vaazları vermeye başlamıştır bile!

Mühendislik Trend Takipçiliği Değildir

Bir doktor, tıp dergisinde gördüğü en yeni ve en deneysel cerrahi yöntemi; grip olmuş sıradan bir hastanın üzerinde "Hadi bunu deneyelim, çok havalı duruyor" diyerek uygulayabilir mi? Uygularsa ona doktor değil, kasap denir.

Yazılımda da elindeki problemin boyutuna bakmadan, sırf Silicon Valley trendi diye şirket altyapısını kobay faresi gibi kullananlara mühendis denmez; sadece trend bağımlısı birer amatör denir.

Gerçek mühendislik; modaya uymak değil, ihtiyaca tam oturan en sade çözümü üretmektir.

Eğer sizin probleminizi basit bir cron job çözüyorsa, araya Kafka koymak mühendislik değil; görgüsüzlüktür.
Eğer tek bir ilişkisel veritabanı işinizi görüyorsa, 10 tane mikroservis açmak cesaret değil; şirketin parasını yakmaktır.

En büyük mimari başarı; en çok teknolojiyi birbirine bağlamak değil; en az parça ile en sağlam, en sessiz ve en uzun ömürlü sistemi inşa edebilmektir.

LinkedIn trendlerini toplantı odasının kapısında bırakın.
Egonuzu değil; kodunuzun sadeliğini ve şirketinizin gerçek ihtiyaçlarını masaya koyun.

Çünkü teknoloji çöplüğünde inşa edilen hiçbir kule, gerçek hayatın rüzgarlarına karşı ayakta kalamaz.

• Bir şirkete iş başvurusunda bulunursun: "Üzgünüz, hiç iş tecrübeniz yok, sizi alamayız."
• Haklı olarak sorarsın: "İyi de tecrübe kazanabilmem için bir yerde işe başlamam gerekmiyor mu?"
• Şirket soğuk bir tebessümle kapıyı kapatır: "O bizim sorunumuz değil, git önce başka bir yerde tecrübe kazan, sonra bize gel."

Ve Joseph Heller'ın o meşhur Madde 22 (Catch-22) paradoksu tam olarak burada başlar:
İşe girmek için tecrübe lazımdır; ama tecrübe kazanmak için önce bir işe girmek lazımdır!

LinkedIn'deki iş ilanlarını açın. Başlıkta koca harflerle "Junior Geliştirici" yazar. İlanın detaylarına inersiniz:
"En az 3-4 yıl canlı ortam (production) tecrübesi olan, mikroservis mimarilerine hakim, AWS ve Kubernetes yönetmiş, CI/CD pipeline'ları kurmuş, askerliğini yapmış..."

Bu ilanlar sadece trajikomik bir cehaletin değil; Türkiye teknoloji sektörünün bencilce sergilediği kurumsal bir tembelliğin belgesidir.

"Biz Okul Değiliz" Bencilliği

Şirketlerin İK yöneticilerinden ve kurucularından en sık duyduğunuz savunma şudur: "Biz okul değiliz, bizim zamanımız yok, bize ilk günden iş teslim edecek hazır adam lazım."

İyi de muhterem, o hazır adam gökten zembille mi inecek?
Sen yetiştirmezsen, yanındaki şirket yetiştirmezse, öbürü sırtını dönerse; bu sektörde beş yıl sonra mimariyi kime teslim edeceksiniz?

Herkes ormanda sadece meyve toplamak istiyor; ama o meyve ağacını dikmeye, suyunu vermeye, dalını budamaya hiç kimse tek bir saatini bile ayırmak istemiyor.

Sonra ne oluyor? Piyasada tecrübeli mühendis kalmayınca birbirlerinin çalışanlarını transfer etmek için astronomik teklifler havada uçuşuyor; o mühendisler de ilk fırsatta yurt dışına kaçınca şirketler ortada kalıp "Yetişmiş eleman bulamıyoruz" diye televizyonlarda ağlaşıyor.

Kendi ellerinizle kuruttuğunuz fidanlığın içinde, neden çiçek açmadığını sorgulayamazsınız.

Sertifika Koleksiyonculuğunun İflası

Bu acımasız kısır döngünün ortasında kalan yüz binlerce genç ise ne yazık ki yanlış yönlendiriliyor.

Umut taciri online kurslar ve bootcamp'ler gençlere aynı yalanı satıyor: "Bizden 6 haftalık React eğitimi al, sana sertifika verelim, kapılar açılsın."

Ve gençlerin LinkedIn profilleri Udemy sertifikalarıyla, kopyala-yapıştır yapılmış klon projelerle (Netflix klonu, Spotify klonu, Todo uygulaması) dolup taşıyor. İK uzmanlarının önüne her gün birbirinin virgülüne kadar aynı olan 500 tane CV düşüyor.

Ve o CV'lerin hiçbiri işe yaramıyor. Çünkü herkes aynı şeyi biliyor: O klon projeler bir eğitim videosunu taklit etmekten ibarettir; gerçek hayattaki tek bir problemi bile çözmez.

Kısır Döngüyü Kırma Rehberi: "Proof of Work" (İş Kanıtı)

Eğer bu satırları okuyan ve o kapalı kapıların önünde çaresizce bekleyen bir genç yazılımcıysan; sana sistemi değiştirebileceğin masalını anlatmayacağım. Şirketlerin bencilliği bir gecede bitmeyecek.

Ama sen o duvarı kendi ellerinle yıkabilirsin. Nasıl mı?
Sertifika toplamayı bırakıp, reddedilemeyecek bir "İş Kanıtı" (Proof of Work) üreterek:

1. Klon Projeleri Çöpe At: Kimsenin senin yazdığın 100. Todo uygulamasına ihtiyacı yok. Çevrene bak. Mahalledeki kütüphanenin, yerel bir sivil toplum kuruluşunun, bir derneğin veya açık kaynak bir topluluğun kanayan gerçek bir problemini bul. O problemi çözen ve canlıda 50 kişinin gerçekten kullandığı ufacık bir yazılım yap. Canlıda çalışan ve gerçek kullanıcısı olan tek bir proje, 50 tane Udemy sertifikasından bin kat daha ikna edicidir.
2. Açık Kaynak Kod Depolarına Katkı Ver: Dünyanın en büyük açık kaynak kütüphanelerinin GitHub depolarına git. "Good First Issue" etiketli biletleri bul. Dokümantasyondaki bir hatayı düzelt, basit bir bug'a PR aç. CV'ne "X kütüphanesine kod katkısı verdim" yazmak, mülakatta sana doğrudan kıdem kapısını aralar.
3. Süreçlerini Herkesin Önünde Paylaş (Build in Public): Bir problem çözerken nerede takıldığını, nasıl debug ettiğini, hangi hatadan ders çıkardığını bir blog yazısıyla veya sosyal medyada şeffafça anlat. Şirketler senin her şeyi bilmeni beklemez; nasıl öğrendiğini ve nasıl düşündüğünü görmek ister.

Tohum Ekmeden Hasat Alınmaz

Şirket liderlerine ve kıdemli mühendislere son bir çağrı:

Bir junior geliştiriciyi işe almak, ona haftada iki saatini ayırıp mentörlük yapmak bir hayır işi veya lütuf değildir.
Bu, bu sektöre olan varoluşsal borcunuzdur.

Unutmayın; bugün o fildişi kulelerinizde otururken aldığınız kararlar, bir zamanlar sizin yazdığınız berbat kodlara sabreden o eski ustaların mirasıdır.

Gençlere kapıyı kapatmayın.
O kısır döngüyü kırmak için bir fidan dikin.

Çünkü tohum ekmeyi reddeden bir toplum; eninde sonunda açlıktan ve kuraklıktan kırılmaya mahkûmdur.

Sosyal medyadaki o cilalı reklamları hatırlayın:
Bali'de sahil kenarında, elinde Hindistan ceviziyle laptop açmış bronz tenli bir genç. Ya da İsviçre Alpleri'ne bakan ahşap bir dağ evinde, şöminenin karşısında kahvesini yudumlarken kod yazan "özgür" bir dijital göçebe.

Kulağa insanın ruhunu okşayan bir cennet vaadi gibi geliyor, değil mi?
Trafik çilesi yok, sabahın köründe metrobüse binmek yok, takım elbise yok, kravat yok. Pijamalarınla masaya otur ve dünyayı kodla!

Şimdi gelin, o Bali sahillerindeki Instagram filtrelerini bir kenara fırlatalım ve Türkiye şartlarında, İstanbul'un, Ankara'nın bir apartman dairesinde uzaktan çalışan ortalama bir Türkiyeli yazılımcının çıplak gerçekliğine bakalım.

Karşımıza çıkan şey bir özgürlük hikayesi değil; şirketin evinize çöreklenip salonunuzu bedava bir şubeye dönüştürmesinin trajedisidir.

Şirket Evimize Taşındı ve Kira Ödemiyor

Geleneksel ofis hayatında insanların küfrettiği o "işe gidiş-geliş" (commute) rutini, aslında insan psikolojisinin en sağlıklı tampon bölgesiydi.

Akşam saat 18:00'de ofisten çıkardınız. Servise, metroya veya arabanıza binerdiniz. O yolculuk sırasında beyniniz yavaş yavaş "iş modu"ndan çıkar, arınır ve eve vardığınızda sokak kapısını arkanızdan kapatıp ayakkabılarınızı çıkardığınız an o kutsal sığınağa adım atardınız: Ev.

Ev, patronun giremediği, müşterinin sesinin yankılanmadığı, dış dünyanın stresinden korunduğunuz bir kaleydi.

Uzaktan çalışma ise ne yaptı biliyor musunuz?
O kutsal kalenin duvarlarını yıktı. Şirketi aldı, doğrudan yatak odanızın, salonunuzun ortasına oturttu.

Artık işe gitmiyorsunuz; işin tam içinde yaşıyorsunuz.

• Şirket artık ofis kirası ödemiyor; çünkü sizin salonunuzu kullanıyor.
• Elektrik faturası ödemiyor, klima çalıştırmıyor, internet parası vermiyor, su sebili doldurmuyor; hepsini sizin maaşınızdan tırtıklıyor.
• Ve karşılığında size sunduğu tek şey: Bir laptop ve sınırsız bir denetim baskısı.

Yatak ile Masa Arasındaki 2 Adımlık Uçurum

Türkiye'deki ortalama konut gerçeklerini düşünün: Çoğu genç yazılımcı 1+1 veya 2+1 evlerde, ya ailesiyle ya da ev arkadaşlarıyla yaşıyor. Birçoğunun kendine ait izole bir çalışma odası bile yok.

Çalışma masanız yatağınızın hemen iki adım yanında duruyor.
Sabah gözünüzü açıyorsunuz; ilk gördüğünüz şey iş bilgisayarının o soğuk kapağı.
Gece yatağa yatıyorsunuz; karanlığın içinde Slack'in ve Teams'in o yeşil "çevrimiçi" ışığı parıldıyor.

Beyin bir süre sonra mekânsal algısını tamamen kaybediyor:
Burası dinlendiğim yer mi, yoksa stres altında hesap verdiğim bir sorgu odası mı?
Yemek yediğiniz masa, aynı zamanda müşteriye bilet yetiştirdiğiniz bir savaş alanına dönüşüyor. Dinlenmek için koltuğa oturduğunuzda, iki metre ötedeki monitör size suçlu bir vicdan azabı gibi bakıyor: "Neden oturuyorsun, baksana iki tane PR bekliyor."

Ve o meşhur Türk ailesi dinamikleri devreye giriyor:
Evdekiler için siz "çalışan" biri değilsinizdir; evde akşama kadar bilgisayarla oyun oynayan çocuksunuzdur. Kapı her an açılır: "Madem evdesin oğlum, şu bakkaldan iki ekmek alıver", "Kızım şu teyzenlere bi' uğrayıver." Odaklanma paramparça olur.

Mesainin Sonu Nerede?

Uzaktan çalışmanın yarattığı en büyük illüzyon, mesainin bittiği anın buharlaşmasıdır.

Ofisteyken saat 18:00 olduğunda çantanızı toplar ve çıkardınız. Fiziksel olarak orada olmadığınız için kimse size kolay kolay iş yıkamazdı.
Şimdi ise saat akşam 20:30'da yönetici WhatsApp'tan yazar:
"Ya Ahmet biliyorum mesai bitti ama zaten evdesin, şu raporu bir çekiver sana zahmet."

"Zaten evdesin."
İşte modern köleliğin en zehirli cümlesi budur. Sanki evde olmak, şirketin emrinde boşta beklemekle eşdeğermiş gibi bir algı yaratılmıştır. Bilgisayar açık olduğu sürece siz potansiyel olarak her zaman mesaitesinizdir.

Sonuç? Kronik bir tükenmişlik (burnout), sosyal izolasyon, gün ışığı görmeden geçirilen aylar ve kendi evinde bir yabancıya dönüşen yüz binlerce genç.

Evinizi Şirketten Geri Alın

Uzaktan çalışmanın bir lanete dönüşmesini engellemek istiyorsanız; sınırlarınızı demirden ve çelikten çizmek zorundasınız:

1. Fiziksel Bir Çit Çekin: Eğer ayrı bir odanız yoksa bile, çalıştığınız köşeyi sadece ve sadece işe ayırın. Mesainiz bittiğinde bilgisayarınızı kapatın, şarj aletini çekin ve o bilgisayarı bir çekmecenin içine kilitleyin. Gözünüz görmesin.
2. Sahte İşe Gidiş Rutini Kurun: Sabah mesai başlamadan önce pijamalarınızı çıkarın. Normal dışarı çıkacakmış gibi giyinin. Evden çıkıp mahallede 15 dakikalık bir yürüyüş yapın ve sonra eve dönüp masaya oturun. Akşam mesai bittiğinde de aynı yürüyüşü tekrarlayın. Beyninize "Ben işe gittim ve şimdi işten eve döndüm" sinyalini fiziksel olarak verin.
3. Bildirimleri Acımasızca Susturun: Saat 18:00'den sonra telefonunuzdaki Slack, Teams ve şirket e-postası bildirimlerini otomatik olarak kapatın. Şirket yanmıyorsa (ki çoğu zaman o 'yangın' sadece bir yöneticinin kaprisidir), o mesaja cevap vermeyin.

Unutmayın; eviniz bir şirket şubesi değildir. Eviniz sizin kalbinizi, ruhunuzu ve sevdiklerinizi dinlendirdiğiniz son sığınağınızdır.

O kalenin kapılarını şirketlerin bedavacı iştahına karşı kilitleyin.
Çünkü kaybedilen bir iş her zaman yeniden bulunur; ama kendi evinde huzurunu kaybetmiş bir insanın gidebileceği başka hiçbir yer yoktur.

Kulağa ne kadar sıcak, ne kadar koruyucu ve güven verici geliyor değil mi? İnsan zihni, evrimsel olarak bir kabileye ve bir aileye ait olma ihtiyacıyla kodlanmıştır. Yalnızlıktan korkarız; şefkat, kabul ve koşulsuz sadakat ararız. Şirketlerin İK departmanları da bu en ilkel insani zaafımızı çok iyi bilir ve onu tepe tepe kullanır.

Sizden hafta sonu ücretsiz mesai istendiğinde "Biz bir aileyiz" denir.
Enflasyonun %70 olduğu bir ülkede size %30 zam teklif edildiğinde "Ailemizin bütçesi bu ara biraz sıkışık, fedakarlık yapmalıyız" denir.
Hakkınızı aradığınızda veya sınır çizmeye çalıştığınızda "Ama bu yaptığın ailemize hiç yakışmıyor" denilerek suçluluk psikolojisine hapsedilirsiniz.

Peki, sonra ne olur?

Günün birinde şirketin çeyrek dönem finansal tabloları beklenenden %5 düşük gelir. Ya da yurt dışındaki yatırımcı turu ertelenir.

Ve bir Salı sabahı, saat 09:30'da takviminize o meşhur 15 dakikalık gizemli toplantı düşer: "Operasyonel Güncelleme - İK & Yönetim".

15 Dakikalık Soğuk Duş

Toplantıya girersiniz. Karşınızda geçen hafta omzunuza vurup "Sen bu ailenin en değerli parçasısın" diyen kurucu ortak ve yanında İK müdürü oturmaktadır.

Yüzlerdeki o sıcak, sevecen aile gülümsemesi tamamen silinmiştir. Karşınızda buz gibi, mekanik ve duygusuz iki yabancı vardır. İK müdürü elindeki kâğıttan o önceden ezberletilmiş kurumsal metni okumaya başlar:

"Şirketimizin uzun vadeli stratejik öncelikleri, değişen makroekonomik dinamikler ve bütçe optimizasyonu çerçevesinde... Yasal haklarınız ve kıdem tazminatınız kanunlar gereğince ödenecek olup, şirket hesaplarınıza erişiminiz saat 10:00 itibarıyla kapatılacaktır. Bugüne kadarki katkılarınız için teşekkür ederiz."

O an kanınız donar.
Slack hesabınız kapatılır. Şirket bilgisayarınız kilitlenir. Güvenlik eşliğinde eşyalarınızı bir karton kutuya koyup binanın kapısına bırakılırsınız.

Peki o "kocaman aileye" ne oldu?
O aile, şirketin Excel tablosundaki bir maliyet satırı (headcount) negatife düştüğü o saniyede buharlaşıp yok oldu!

Aile Evladını İhale İptal Oldu Diye Evden Atmaz

Gelin bu hastalıklı kavramı ait olduğu gerçek yerine koyalım:
Bir şirket ASLA bir aile değildir ve olamaz.

Gerçek bir ailede ebeveynler, evin bütçesi kısıtlandı diye çocuklarından birini sokağa atıp "Bu ay bütçe eksi yazdı oğlum, yasal hakların çerçevesinde seninle yollarımızı ayırıyoruz" demez. Gerçek ailede bağlar kâr-zarar tablolarına, hisse değerine veya yatırımcı sunumlarına bağlı değildir; koşulsuz sevgiye ve kan bağına dayanır.

Oysa bir teknoloji şirketi ile aranızdaki ilişki; tamamen rasyonel, iki taraflı ve ekonomik temelli bir Hizmet ve Emek Sözleşmesidir.

Siz zamanınızı, uzmanlığınızı, zihinsel enerjinizi ve gençliğinizi masaya koyarsınız; şirket de bunun karşılığında size anlaştığınız maaşı ve yan hakları öder.

Ne bir gram fazlası, ne bir gram eksiği.

"Biz Bir Spor Takımıyız" Dürüstlüğü

Netflix'in kurucusu Reed Hastings'in şirket kültür manifestosunda yazdığı ve tüm kurumsal dünyayı sarsan harika bir tespiti vardır:
"Biz bir aile değiliz. Biz profesyonel bir spor takımıyız (pro sports team)."

İşte dürüstlük tam olarak budur!
Bir spor takımında futbolcular birbirine saygı duyar, sahada aynı hedef için ter döker, birbirini destekler. Ama herkes bilir ki; günün sonunda burası profesyonel bir ligdir. Formsuz olan yedek kalır, taktiğe uymayan transfer edilir, sözleşmesi biten ayrılır. Kimse kimseye sahte bir kan bağı yalanı satmaz.

Bir şirket sizinle bir profesyonel gibi konuşuyorsa, ona saygı duyabilirsiniz. Şeffaftır, sınırları bellidir.
Ama bir şirket size "aile" masalı anlatmaya başladığı an; bilin ki sizden hak ettiğinizden daha fazlasını bedavaya koparmak için zihinsel bir tuzak kuruyordur.

Sınırlarınızı Koruyun, Emeğinizi Kutsayın

Bu yanılsamadan kurtulmak sizi soğuk, bencil veya işine yabancılaşmış biri yapmaz; aksine sizi özgür ve olgun bir profesyonele dönüştürür.

• İşinizi en iyi şekilde yapın. Kodunuzu bir zanaatkar titizliğiyle yazın. Çalışma arkadaşlarınıza karşı şefkatli, dürüst ve yardımsever olun.
• Ama o şirketi asla "aileniz" sanmayın. Şirketin başarısını kendi tek varoluş sebebiniz haline getirmeyin. Şirket için kendi sağlığınızı, uykunuzu ve asıl gerçek ailenizi feda etmeyin.

Çünkü işten çıkarıldığınız gün şirket ertesi hafta sizin yerinize yeni bir ilan açacaktır.
Ama kendi hayatınızda, kendi gerçek ailenizde ve sevdiklerinizin kalbinde sizin yerinize açılabilecek başka hiçbir ilan yoktur.

Kürsüdeki konuşmacı alkışlanır. Salondaki 24 yaşındaki genç yazılımcı ise başını öne eğer; kendini yetersiz, korkak ve vizyonsuz hisseder.

Oysa o parlak kürsünün arkasında duranların bilerek görmezden geldiği, konuşmaktan korktuğu devasa bir gerçeklik vardır:
Risk almak bir karakter özelliği değil; sınıfsal ve ekonomik bir ayrıcalıktır.

Steve Jobs'ın garajında başladığı Silikon Vadisi'nin arkasında; batarsa aç kalmayacağı bir aile evi, güçlü bir sosyal güvenlik ağı, bedava sağlık sigortası ve iflas ettiğinde ertesi gün onu yeniden finanse edecek trilyon dolarlık bir risk sermayesi havuzu vardı.

Şimdi gelin, aynı yaşta Türkiye'de yaşayan ortalama bir yazılım mühendisinin sırtındaki o görünmez kurşun ağırlıklara bakalım.

25 Yaşındaki Bir Gencin Sırtındaki Ağır Bilanço

Türkiye'de üniversiteyi bitirip sektöre adım atan 23-26 yaşındaki bir gencin hayatı, bir start-up macerası gibi değil; adeta bir borç tahsilat operasyonu gibi başlar:

1. Evlilik ve Düğün Cenderesi: Bu toplumda evlenmek iki insanın hayatını birleştirmesi değildir; yüz binlerce liralık bir finansal yıkımdır. Düğün salonu masrafları, mobilyalar, beyaz eşyalar, takılan altınlar ve ailelerin bitmeyen talepleri... Genç bir mühendis evlendiği gün cebinde en az 3-4 yıllık bir kredi borcuyla masaya oturur.
2. Kira ve Barınma Krizi: Büyükşehirlerdeki fahiş kiralar yüzünden maaşın neredeyse yarısı ayın ilk gününde buharlaşır. Ev sahibi her an kapıdadır.
3. Ailenin Emeklilik Sigortası Olmak: Batı'daki akranlarının aksine, Türkiyeli bir genç sadece kendi hayatını yaşamaz. Emekli maaşı açlık sınırının altında kalmış anne ve babasına destek olmak, okuyan kardeşinin harçlığını göndermek zorundadır. O, aynı zamanda ailesinin gayriresmi emeklilik fonudur.

Şimdi bu gence dönüp "İşinden istifa et, 1 yıl boyunca tek kuruş gelir olmadan bir garajda startup dene" demek; cehalet değilse düpedüz zalimliktir!

Tek Bir Maaş Kesintisi = Hayatın Çöküşü

Girişimcilik, en az 12-18 ay boyunca tek kuruş para kazanmadan, cebinizdeki birikimi yakabilme (runway) lüksüdür.

Peki Türkiye'deki ortalama bir yazılımcının "runway"i kaç aydır biliyor musunuz?
Tam olarak bir aydır!

Eğer ayın birinde o maaş banka hesabına yatmazsa; ertesi hafta ev kredisi taksidi patlar, diğer hafta kredi kartı asgari tutarı ödenemez, ay sonunda ev sahibi kapıya dayanır ve tüm hayat zincirleme bir reaksiyonla yerle bir olur.

Böyle bir ekonomik zeminde yaşayan bir insandan "risk almasını" bekleyemezsiniz.
O gencin bir kurumsal şirkete, bir bankaya girip "Aman başım ağrımasın, ayın birinde maaşım yatsın, SGK'm tam yatsın" diyerek garanti maaşa sarılması bir korkaklık değildir. Bu, ailesine ve sevdiklerine karşı duyduğu derin bir sorumluluk bilinci ve hayatta kalma refleksidir.

Girişimcilik Zengin Çocuklarının Sporu mu?

İşte bu sosyo-ekonomik frenler yüzünden, Türkiye'de gerçekten "start-up kurabilen" kitlenin profili giderek homojenleşti ve kısıtlandı:
Ailesinin Bebek'te veya Kadıköy'de dairesi olan, kira derdi bulunmayan, batarsa babasının şirketine sığınabilecek tuzu kuru zengin çocuklarının oynadığı bir "prestij oyununa" dönüştü.

Anadolu'nun bir şehrinden gelmiş, ailesini sırtlayan dahi çocuk ise bankanın bodrum katında legacy Java kodları yazmaya mahkûm edildi. Çünkü onun batma lüksü yoktu.

Bu, bir ülkenin en zeki beyinlerinin risk alma kapasitesini yok eden korkunç bir yetenek israfıdır.

Bu Frenlerle Nasıl Yaşayacağız?

Eğer sırtınızda bu borçlar, bu krediler ve bu ailevi sorumluluklar varken yine de içinizde bir şeyler üretme, kendi ürününüzü çıkarma ateşi yanıyorsa; kendinize kızmayı bırakın. Siz korkak değilsiniz.

Sadece stratejinizi Silikon Vadisi masallarına göre değil, kendi topraklarınızın gerçeklerine göre çizmek zorundasınız:

• İşini Bırakma, Kenarda Başla (Side Project): Gündüz maaşlı işinizde çalışırken, akşamları günde 2 saatinizi kendi mikro-ürününüze ayırın. İlk gelirinizi elde edene kadar o garanti maaş dalını asla bırakmayın.
• Düşük Maliyetli Başla: Şirket kurmadan, büyük sunucu masraflarına girmeden, en ucuz araçlarla fikrinizi küresel pazarda test edin.
• Borçları Sıfırlamayı Birinci Hedef Yapın: Sizi o kurumsal prangaya bağlayan şey şirket sevgisi değil; o kredi taksitleridir. Finansal özgürlüğe giden yol, tüketim çılgınlığını ve borçları sıfırlamaktan geçer.

Cesaret, gözü kapalı uçuruma atlamak değildir.
Gerçek cesaret; sırtındaki onca yüke ve prangaya rağmen, o uçurumun kenarında dengede kalarak gökyüzüne doğru bir kanat çırpabilme dirayetidir.

Sosyal medyanın en kurumsal ve profesyonel olması gereken platformu, bugün tarihin en büyük "Kolektif Narsisizm ve Sahte Kırılganlık Sirkine" dönüşmüş durumdadır.

Tipik bir gönderi şablonunu hepimiz ezbere biliriz:
Kısa, tek satırlık ve dramatik cümlelerle başlar:
"Geçen yıl bugün banka hesabımda sadece 14 TL vardı..."
(Bir boşluk)
"Ağlayarak uyandım. Herkes bana bittiğimi söyledi..."
(Bir boşluk)
"Ama sonra aynaya baktım. 'Asla pes etmeyeceksin' dedim..."
(Bir boşluk)
"Ve bugün... Şirketimiz 50 kişilik dev bir ekibe ulaştı! Büyüme zihniyeti (growth mindset) her şeydir. Asla pes etmeyin dostlar! #leadership #success #hustle"

Altına iliştirilmiş, yapay bir hüzünle kameraya bakan siyah-beyaz bir selfie ve binlerce alkış emojisi...

Bu sahte drama tiyatrosunun arkasındaki gerçek nedir biliyor musunuz?
Koca bir hiçlik.

"Vulnerability Porn": Kırılganlığı Satış Malzemesi Yapmak

Sosyal medya guruları birkaç yıl önce bir şey keşfetti: İnsanlar artık sadece soğuk şirket başarılarına prim vermiyor. İnsanların dikkatini çekmenin en ucuz yolu; acıyı, başarısızlığı ve kırılganlığı bir pazarlama aparatına dönüştürmek (Vulnerability Porn).

İşten kovulan biri çıkıp "Bugün kapının önüne kondum ama beni kovan yöneticime minnettarım, bu kovulma benim liderlik yolculuğumun en muazzam hediyesi oldu" diyerek kurumsal mazoşizmin zirvesine tırmanabiliyor.

Ofiste çalışanına mobbing uygulayan, mesai ücretini gasp eden bir şirket kurucusu; LinkedIn'de "Liderlik şefkattir, ekibimi bir evlat gibi seviyorum" diyerek felsefe parçalayabiliyor.

Terminalde iki satır temiz kod yazmaktan aciz olan, hayatında tek bir dağıtık sistem mimarisi görmemiş insanlar; her gün "10x Mühendis Olmanın 7 Altın Kuralı" başlığı altında çalıntı listeler paylaşarak binlerce beğeni topluyor.

Sektörümüz ne yazık ki; üretilen değerin değil, yapılan şovun ödüllendirildiği hastalıklı bir vitrin bağımlılığına teslim oldu.

Terminalin Gerçeği vs. Vitrinin Yalanı

İşin en acı verici tarafı, bu sahte tiyatronun genç yazılımcıların ruh dünyasında yarattığı tahribattır.

Gencecik bir mühendis masasının başına oturur. Sabahtan akşama kadar tek bir CSS taşmasını düzeltmek için ter döker, terminaldeki yüzlerce derleme hatasıyla boğuşur, kendini yetersiz ve çaresiz hisseder. Sonra mola vermek için LinkedIn'i açar.

Ve karşısında ne görür?
Kendi yaşındaki akranlarının her hafta yeni bir "başarı hikayesi" yazdığını, her ay bir konferansta sahneye çıktığını, her gün yeni bir yapay zeka aracını "devrimsel" bir şekilde fethettiğini okur.

Ve kendi kendine sorar: "Ben neden bu kadar başarısızım? Neden herkes uçuyor da ben yerimde sayıyorum?"

Sakin ol kardeşim. Kimse uçmuyor.
O sahnedekilerin büyük bir kısmı da senin gibi terminalin başında saçını başını yoluyor.
Onların prod sunucuları da çöküyor, onların yazdığı kodlar da spagettiye dönüyor.
Tek fark şu: Onlar hatalarıyla yüzleşip sessizce düzeltmek yerine; hatalarını bile cilalayıp sosyal medyaya birer "ilham kaynağı" olarak pazarlayacak kadar utanmaz birer gösteri sanatçısına dönüştüler.

Sessiz Zanaatkarlığın Asaleti

İnsanlık tarihi boyunca gerçek ustalar asla sokak köşelerinde bağırıp kendini övmemiştir.

Büyük bir marangoz, yaptığı masanın üzerine çıkıp nutuk atmaz; masanın pürüzsüz ahşabına dokunmanız yeterlidir.
Büyük bir cerrah, ameliyathaneden çıkıp koridorda self-help tiradları atmaz; hastanın sağ salim ayağa kalkması tek ve en büyük cevaptır.

Yazılım da özünde bir dijital zanaattır.
Ve gerçek bir zanaatkarın vitrini LinkedIn gönderileri değil; yazdığı kodun zarafeti, sisteminin kararlılığı ve kriz anındaki sessiz soğukkanlılığıdır.

Gürültüyü kesin.
Sosyal medyadaki o içi boş narsisizm bataklığından zihninizi arındırın.
Beğeni sayılarıyla değil; çözdüğünüz problemlerin derinliğiyle kendinizi ölçün.

Çünkü alkışlar bittiğinde, ışıklar söndüğünde ve sahne kapandığında; geriye sadece o siyah terminal ekranı ve o ekrana dürüstçe döktüğünüz saf emek kalacaktır.

Mülakatta sorarsınız: "İngilizce durumun nasıl?"
Geliştirici gayet kendinden emin bir şekilde yanıt verir: "Hiçbir sorunum yok hocam, tüm dokümanları İngilizce okuyorum, videoları rahatça anlıyorum."

İşte bu, Türkiye teknoloji sektörünün kendi kendine söylediği en büyük, en konforlu ve en pahalıya patlayan yanılsamalardan biridir: "Doküman Okuma İngilizcesi" ile "Müzakere ve Tartışma İngilizcesi"ni aynı şey zannetmek.

Bir insanın StackOverflow'daki bir hata çözümünü okuması, React'in resmi dokümantasyonunu taraması veya YouTube'da Hintli bir mühendisin eğitim videosunu altyazısız izlemesi; onun İngilizce bildiğini göstermez.
Bu sadece, teknik bir metni pasif olarak deşifre edebildiğini gösterir.

Ve ne yazık ki, küresel yazılım liginde fildişi kuleler sadece doküman okuyarak fethedilmez.

Zoom Kamerasının Karşısında Donup Kalmak

O "İngilizcem C1" diyen geliştiriciyi alın; Londra'daki bir müşterinin, Amerikalı bir ürün yöneticisinin veya Alman bir sistem mimarının karşısına, canlı bir Zoom toplantısına oturtun.

Toplantı başlar. Karşıdaki yabancı yönetici konuşmaya başlar:
"Ekibin son sprint'teki mimari yaklaşımını biraz riskli buluyoruz. Bize mikroservis yerine monolit kalmamız gerektiğini söylüyorsunuz ama yönetim kurulu bunu onaylamayabilir. Neden bu riski alalım? Bizi ikna edin."

O an ne olur biliyor musunuz?
O masada, kendi ana dilinde fırtınalar estiren, sabahlara kadar harika kodlar yazan dahi mühendisimizin boğazına bir yumruk oturur.
Gözleri kaçırır. Zihninde Türkçe düşündüğü o derin mimari argümanları İngilizceye çevirmeye çalışır. Kelimeler düğümlenir:
"Because... uh... monolit is... you know... simple... and... Kafka is expensive... so... yes."

Karşıdaki yönetici ne anlar?
Karşıdaki yönetici onun zihnindeki o muazzam dehadan habersizdir. Karşısında sadece kekeleyen, kendine güveni olmayan, fikrini savunamayan ve pasif bir "kod hamalı" görür.

Ve o toplantının sonunda mimariyi yönetici belirler, teslim süresini müşteri dikte eder, bizim dahi mühendisimiz ise istemediği bir kararın altında ezilmeye devam eder.

Kod Evrenseldir Ama Para Dille Kazanılır

Teknoloji dünyasının en büyük yalanı şudur: "Kodun dili evrenseldir, önemli olan yazdığın koddur."

Hayır. Kod sadece işin icraat kısmıdır.
Ama o kodun değerini belirleyen, o projenin bütçesini çizen, teslim tarihini belirleyen ve masadaki şartları koyan şey; masadaki retorik, özgüven ve pazarlık dilidir.

Eğer İngilizceyi sadece pasif bir okuma aracı olarak bırakırsanız; dünyadaki en yetenekli mühendis bile olsanız, küresel sistemde Hindistan'daki fason yazılım fabrikalarından farksız birer "ucuz iş gücü" olarak kalmaya mahkûm olursunuz. Saati 15 dolara başkalarının hayallerini kodlarsınız.

Ama eğer fikrinizi bir toplantıda savunabilecek, haksız bir revizyon talebine diplomatik bir incelikle "Hayır, bu kapsam sözleşmemizin dışındadır ve projenin mimari bütünlüğünü bozar" diyebilecek akıcılığa ve aksan özgüvenine sahipseniz; işte o zaman fasoncu değil, masada sözü dinlenen küresel bir ortak olursunuz.

Aksan Kompleksinden Kurtulun

Türkiye'deki geliştiricilerin bu bariyeri aşamamasının en büyük sebebi gramer eksikliği değil; hastalıklı bir aksan ve hata yapma korkusudur.

Bir Fransız veya bir İtalyan mühendisi dinleyin: İngilizceyi berbat bir aksanla, gramer hatalarıyla konuşur; ama gözünüzün içine dimdik bakarak, zerre kadar utanmadan fikrini çatır çatır savunur.

Bizim gençlerimiz ise "Acaba geçmiş zaman kipini yanlış mı kullandım, acaba kelimeyi Türk gibi mi telaffuz ettim" endişesiyle tamamen susmayı tercih eder.

Bu kompleksi derhal çöpe atın:

• Kimse sizden Shakespeare gibi konuşmanızı beklemiyor. Küresel iş dünyasının dili "Kusursuz İngilizce" değil; "Açık, net ve özgüvenli İngilizcedir."
• Doküman okumayı bir marifet saymayı bırakın. Her gün sesli konuşma pratikleri yapın. Kendi kendinize mimari kararlarınızı İngilizce sesli anlatın.
• Yabancı ekiplerle toplantılara girmekten kaçmayın; aksine bilerek o ateşe atlayın. Dil ancak o ateşin içinde pişerek öğrenilir.

Kod yazmak sizi bir teknisyen yapar.
Ama o kodun arkasındaki fikri dünyaya anlatabilmek ve masada hakkınızı söke söke alabilmek; sizi gerçek bir dünya mühendisi yapar.

Dokümanların arkasına saklanmayı bırakın.
Sesinizi yükseltin ve masadaki yerinizi alın.

Pazartesi sabahı iki saat süren o kutsal "Sprint Planning" (Dönem Planlama) toplantısı yapılır. Her bir özellik incelenir, biletler açılır, kabul kriterleri (acceptance criteria) yazılır, story point'ler tartışılır ve ekibin kapasitesi saniyesine kadar hesaplanıp kilitlenir. Ortam adeta bir İsviçre saat fabrikası kadar disiplinli ve kusursuzdur.

Ama Salı sabahı saat 10:45 olduğunda; Türk iş kültürünün o kadim, sinsi ve önüne çıkan tüm planlamaları yerle bir eden görünmez balyozu devreye girer.

Yöneticiniz veya yan departmandan bir pazarlamacı masanızın kenarına yanaşır (veya Slack'ten o meşhur mesajı atar):
"Kanka müsaitsen şuna bi' bakıversene ya, valla iki dakikalık iş, müşteriye acil lazım."

Ve işte o an; pazartesi günü kurulan o binlerce dolarlık Jira mimarisi, Agile manifestoları ve sprint taahhütleri bir çöp torbası gibi pencereden aşağı fırlatılır.

Hoş geldiniz; burası "Bi' Bakıver Kültürünün" hüküm sürdüğü yerel teknoloji cehennemidir.

"İki Dakikalık İş" Efsanesi

Yazılım sektörünün en büyük yalanı, bir işin "iki dakikalık" olabileceği masalıdır.

O masum görünen "Butonun yerini azıcık sağa kaydırıver" talebi hiçbir zaman iki dakika sürmez:

• Önce mevcut çalıştığınız o derin, karmaşık algoritmanın başından kalkarsınız. Zihninizdeki o kırılgan odaklanma kalesi (context) tuzla buz olur.
• Git'te üzerinde çalıştığınız branch'i stash'lersiniz. Yeni bir branch açarsınız.
• Kodu açtığınızda görürsünüz ki o buton, CSS'in en karanlık z-index ve flexbox kurallarıyla birbirine dolanmış 10 farklı bileşene bağlıdır. Sağa kaydırdığınızda mobil arayüz patlar.
• O hatayı düzeltirsiniz, test edersiniz, commit atarsınız, CI/CD pipeline'ını beklersiniz...

İki dakikalık iş, günün tam üç saatini yutar.

Ama felaket bununla da bitmez. O iş bittiğinde aynı kişi gülümseyerek gelir: "Harikasın ya! Hazır oradayken şu metni de değiştiriversene, bir de rengini lacivert yapalım."

Ve gün biter.

Görünmez Emeğin Kara Deliği

Cuma günü öğleden sonra "Sprint Review" toplantısı gelir çatar.
Jira tahtası ekrana yansıtılır. Yöneticiniz kaşlarını çatarak size bakar:
"Ahmet, sprint'e aldığımız 5 biletten 3'ü bitmemiş, hâlâ 'In Progress' görünüyor. Neden yetiştiremedin? Bir sorun mu var?"

O an boğazınız düğümlenir. Ezilir, büzülürsünüz.
İçinizden haykırmak gelir: "Ben bütün hafta senin ve pazarlamanın WhatsApp'tan attığı o 'bi' bakıver' işleriyle boğuştum!"

Ama söyleyemezsiniz; söyleseniz de bir anlamı yoktur. Çünkü Jira tahtasında o harcadığınız 20 saatin tek bir satır resmi kaydı yoktur! O emek şirket sisteminde buharlaşmış, gayriresmi sohbetlerin kara deliğinde yutulmuştur.

Siz bütün hafta şirketin gerçek krizlerini çözmüş, yangın söndürmüşsünüzdür; ama sistemin gözünde "İşini yetiştiremeyen tembel bir yazılımcı" olarak yaftalanırsınız.

Feodal Samimiyet vs. Kurumsal Disiplin

Bu çarpıklığın kökeni, bizim toplumumuzun kuralları ve süreçleri "soğukluk" veya "bürokrasi"; gayriresmi ilişkileri ise "samimiyet" olarak kodlamasından gelir.

Bir iş arkadaşınıza veya yöneticinize "Bunu Jira'dan bilet olarak açar mısın, sprint planımıza ekleyelim" dediğinizde; karşı taraf bunu profesyonel bir süreç olarak değil, kişisel bir hakaret olarak algılar:
"Aramızda biletin lafı mı olur canım, iki dakikalık şey için prosedürle mi uğraşacağız, yabancı mıyız biz?"

İşte feodal kültür ile modern mühendislik disiplini tam bu cümlede çatışır.

Yazılım geliştirme süreci bir kahve ısmarlama jesti değildir. Yazılım; binlerce parçanın birbiriyle konuştuğu, her bir değişikliğin test edilmesi, belgelenmesi ve takip edilmesi gereken matematiksel bir sistemdir. Bir sistemi "arkadaş hatırına" kodlamaya başladığınız an, o sistemin mimarisini çöpe atmışsınızdır.

Bu Cendereden Nasıl Çıkılır?

Bir mühendis olarak akıl sağlığınızı ve profesyonel itibarınızı korumak istiyorsanız; "bi' bakıver" kurşunlarına karşı kendinize kurşun geçirmez bir zırh örmek zorundasınız:

1. "Jira'da Olmayan İş, Dünyada Yoktur" Kuralı: Ne kadar samimi olursanız olun, kapınıza gelen herkese aynı sakin ve sarsılmaz cevabı verin: "Seve seve bakarım. Ama bunu unutmamam ve mevcut işimi bölmemem için hemen Jira'dan bir bilet açıp bana atar mısın?"
2. Kendi Biletinizi Kendiniz Açın: Eğer yönetici inatla bilet açmıyorsa ve işi yapmanız zorunluysa; o işe başlamadan önce Jira'ya bizzat kendiniz girin: "Ad-hoc Talep: Pazarlamanın acil buton değişikliği (3 saat)" yazıp tahtaya koyun. Emeğinizi görünür kılın.
3. Maliyetini Masaya Koyun: Yöneticiniz araya acil bir iş sıkıştırmak istediğinde ona düşmanca değil, rasyonel bir seçenek sunun: "Bu işe şimdi başlarsam, sprint'teki X özelliğini ertelemek zorunda kalacağım. Hangisini öncelememi istersiniz?" Kararın sorumluluğunu ona iade edin.

Süreçler insanları yavaşlatmak için değil; insanları kaostan ve haksız suçlamalardan korumak için vardır.

"İki dakikalık" yalanlara teslim olmayı bırakın.
Planınıza, emeğinize ve zanaatınıza sahip çıkın.

Çünkü sınırlarını koruyamayan bir mühendisin kodunu da, kariyerini de eninde sonunda başkalarının kaprisleri yönetir.

Peki Türkiye şartlarında freelance yazılımcılık yapmak gerçekte ne anlama gelir?

Gelin o cilalı hayalleri bir kenara bırakalım:
Türkiye'de freelance yazılımcı olmak; zamanınızın %30'unu kod yazmaya, kalan %70'ini ise teslim ettiğiniz işin parasını tahsil edebilmek için telefonlarda dil dökmeye, yalvarmaya ve sinir krizi geçirmeye harcamak demektir.

Bu topraklarda serbest çalışmak teknik bir meydan okuma değildir; katıksız bir psikolojik tahsilat ve sabır savaşıdır.

"Bizde Söz Senettir Kardeşim" Tuzağı

Hikaye hep aynı şekilde başlar. Masaya oturursunuz. Karşınızda kravatlı bir iş insanı veya "vizyoner" bir tanıdık vardır. Projeyi anlatır, gözleri parlar.

Siz profesyonelce bir sözleşme taslağı çıkarırsınız: Kapsam, teslim tarihleri, ödeme planı ve revizyon sınırları...
Müşteri hafifçe gücenmiş gibi kaşlarını kaldırır:
"Aramızda kâğıdın küreğin lafı mı olur kardeşim? Biz kaç yıllık esnafız, piyasada bizi kime sorsan bilir. Bizde söz senettir. Sen başla, gerisini hallederiz."

Eğer bu tuzağa düşer ve tek bir satır kod yazmaya başlarsanız; cehennemin kapılarını kendi ellerinizle aralamışsınız demektir.

Çünkü o "söz senettir" diyen adam;

• İşe başlamadan önce %30 peşinat istediğinizde "Daha tek satır kod yazmadın, neyin parasını istiyorsun?" diyerek sizi hırsız gibi hissettirecektir.
• İşi eksiksiz teslim ettiğinizde ise telefonlarınıza çıkmayacak, WhatsApp mesajlarınıza tek bir mavi tik bırakıp günlerce geri dönmeyecektir.

Türk Usulü Tahsilat Bahane Sözlüğü

İşi bitirirsiniz, demo sunucusuna yüklersiniz. Müşteri çok beğenir: "Eline sağlık, harika olmuş!"
Kalan ödemeyi istersiniz. Ve o an, Türk iş dünyasının o meşhur, zengin ve yaratıcı Tahsilat Bahaneleri Tiyatrosu sahnelenmeye başlar:

• Pazartesi: "Muhasebecimiz bugün izinde, yarın kesin geçecek."
• Çarşamba: "Şirket ortaklarından imza bekliyoruz, genel müdür şehir dışında."
• Cuma: "Bugün banka EFT saatini kaçırmışız, pazartesi sabah ilk iş hesabında."
• Sonraki Hafta: "Piyasalar bu ara çok durgun biliyorsun, müşterimizden ödeme gelsin sana hemen aktaracağız."

Siz bir yazılım mühendisisinizdir; ama kendinizi adeta bir mafya tahsilatçısı gibi her gün birilerini arayıp kendi alın terinizin peşinde dilenirken bulursunuz. Cebinizde kiranız tükenir, kredi kartınız patlar; ama o "sözü senet olan" müşteri lüks cipiyle gezmeye devam eder.

Bitmeyen Revizyon Cehennemi (Scope Creep)

Parayı alamamak bir yana, freelance yazılımcının yakasını bırakmayan ikinci büyük bela "Bitmeyen Revizyon Döngüsüdür" (Scope Creep).

Sözleşmesiz başladığınız için projenin sınırları yoktur. Başlangıçta "Basit bir kurumsal tanıtım sitesi" diye anlaştığınız iş, iki ay sonra müşterinin kaprisleriyle devasa bir portala dönüşür:
"Ya Ahmet, bizim kayınço dedi ki buraya bir de canlı chat koysak iyi olurmuş."
"Şuraya da yapay zekalı bir ürün arama ekleyiver, zor bir şey değil ya, iki tık tık."
"Logonun yerini 14. kez değiştirelim, içime sinmedi."

İtiraz ettiğinizde ise aynı zehirli tehdit masaya konur:
"Eğer bunları yapmazsan işi tamamlanmış saymayız, kalan parayı da ödemeyiz!"

Yazılımcı rehindir. O güne kadar harcadığı iki aylık emeği çöpe atmamak için, o haksız revizyonları geceler boyu ağlaya zırlaya kodlamaya devam eder.

Freelancer Hayatta Kalma Kuralları

Eğer bu topraklarda serbest çalışarak hayatınızı kazanmak ve akıl sağlığınızı korumak istiyorsanız; duygusallığı ve şark usulü samimiyeti çöpe atmak zorundasınız:

1. Peşinatsız Parmak Bile Oynatma: Masadaki kuralınız net olmalıdır: Proje bedelinin en az %40'ı veya %50'si banka hesabınıza yatmadan tek bir dosya bile oluşturmayın. Peşinat vermeyen müşteri, iş bittiğinde size hiç para vermeyecek müşteridir. Peşinat bir güvendir; o parayı ödemeyenle masadan hemen kalkın.
2. Kapsamı Milimetrik Yaz: Sözleşmenize nelerin dahil olduğunu yazdığınız kadar, nelerin dahil olmadığını da yazın: "Bu sözleşme sadece 3 sayfayı kapsar. Ödeme altyapısı dahil değildir. Tasarımda en fazla 2 revizyon hakkı vardır; sonraki her revizyon saatlik 50 dolar ücrete tabidir."
3. Rehini Elinde Tut: Kalan son ödeme kuruşu kuruşuna hesabınıza geçmeden; kaynak kodları, sunucu şifrelerini veya alan adını asla müşteriye teslim etmeyin. Projeyi kendi sunucunuzda demo yapın. Parayı aldığınız saniye teslimatı yapın.

Sizin mesleğiniz bir rica minnet işi değildir. Siz yılların birikimiyle, beyninizi yakarak değer üreten bir zanaatkarsınız.

Kimsenin sizin emeğinizi sömürmesine, sizi kapısında dilendirmesine izin vermeyin.
Sözleşmenizi imzalatın, peşinatınızı alın ve sınırlarınızı çelik gibi koruyun.

Çünkü profesyonellik; iyi niyetle işe başlamakta değil, hakkını koruyarak o işi teslim edebilmektedir.

Girişte bedava pizzalar, enerji içecekleri, masaların üzerine saçılmış yüzlerce parlak laptop sticker'ı...
Gençler birbirine kartvizit veya LinkedIn QR kodlarını uzatır: "Hangi şirkettesin?", "Hangi dille yazıyorsun?", "Network yapalım."

Işıklar söner. Sahnede devasa LED ekranda afili bir sunum başlar:
"Büyük Ölçekli Sistemlerde Event-Driven Mimari ve Sıfır Kesinti (Zero-Downtime) Kültürü."

Konuşmacı sahnede fırtınalar estirir:

• %100 birim test kapsamı (test coverage),
• Kusursuz TDD süreçleri,
• Continuous Delivery boru hatları,
• İnsana değer veren, herkesin birbirini alkışladığı rüya gibi bir mühendislik kültürü...

Salondaki gençler büyülenmiş gibi alkışlar. Herkes o şirketi bir cennet, sahnedeki konuşmacıyı da fildişi kuleden inmiş bir peygamber zanneder.

Peki o sahne kapandıktan sonra, o sunumu yapan şirketin gerçek prod ortamına veya Slack kanallarına girdiğinizde neyle karşılaşırsınız biliyor musunuz?
Tam bir enkazla!

Sahnede "Kusursuz Mimari", Canlıda "Kan ve Gözyaşı"

Gelin kimsenin yüksek sesle söylemeye cesaret edemediği o büyük sırrı fısıldayalım:
Sahnede anlatılan masallar ile gerçek sahadaki kod tabanı arasında Işık Yılı kadar derin bir uçurum vardır.

O sahnede "Biz her gün 50 kez production'a çıkıyoruz, sıfır hata alıyoruz" diyen şirketin mühendisleri; aslında her cuma akşamı deployment korkusundan uykusuz kalıyordur.
"Bizde test yazılmadan tek satır kod merge edilemez" diye slayt atan o Lead Developer; şirkette patronun zoruyla biletleri yetiştirebilmek için testleri devre dışı bırakan --skip-tests parametresini pipeline'a bizzat kendi elleriyle eklemiştir.
"İnsana değer veren kültürümüz" diye övünen kurucunun ofisinde; çalışanlar gece 03:00'te ücretsiz mesaiye zorlanıyor, mobbing altında eziliyordur.

Ama sahnede herkes melektir. Herkes Silicon Valley standardındadır.

Topluluk etkinlikleri, ne yazık ki gerçek mühendislik sorunlarının ve başarısızlıkların dürüstçe masaya yatırıldığı bir öğrenme ocağı olmaktan çıktı; şirketlerin PR yaptığı, konuşmacıların kendi kişisel egosunu parlattığı birer kurumsal illüzyon tiyatrosuna dönüştü.

Aynı 20 Kişinin Kendi Etrafında Döndüğü Kısır Döngü (Echo Chamber)

Türkiye'deki teknoloji etkinliklerini bir yıl boyunca takip edin. Şaşırtıcı bir gerçekle karşılaşırsınız:
İster bulut bilişim zirvesi olsun, ister frontend meet-up'ı, ister yapay zeka paneli...

Sahnede hep aynı 15-20 kişi vardır!

Birbirlerine plaket verirler, birbirlerinin panellerine konuk olurlar, Twitter'da birbirlerinin tweet'lerini RT'lerler, birbirlerine "Harika bir etkinlikti üstat" diyerek övgüler yağdırırlar. Kendi aralarında kapalı, dışarıya kapalı, steril ve son derece kibirli bir feodal klan kurmuşlardır.

Dışarıdan gelen, Anadolu'dan katılan, gerçekten özgün bir problem çözmüş ama popüler olmayan genç bir mühendisin o sahnelerde yer bulabilmesi imkânsızdır. Çünkü sistem liyakatle değil; o topluluk baronlarıyla aranızdaki "networking" samimiyetiyle işler.

Buna sosyolojide "Echo Chamber" (Yankı Odası) veya daha kaba tabiriyle "Kendi Etrafında Dönme Paradoksu" denir.
Herkes birbirini onaylar, herkes birbirine alkış tutar ama ortada gerçek bir üretim, gerçek bir katma değer ve samimi bir bilgi transferi yoktur.

Gerçek Bir Topluluk Ne Konuşmalıdır?

Tıpta M&M (Morbidite ve Mortalite) konferanslarından bahsetmiştim. Hekimler o kapalı odalarda yaptıkları başarılı ameliyatları anlatıp birbirlerini alkışlamazlar; kaybettikleri hastaları, yaptıkları teşhis hatalarını ve sistemik zaafları soğukkanlılıkla masaya yatırırlar. Çünkü tıp ancak hatalarla yüzleşerek ilerler.

Yazılım topluluklarının da acilen bu olgunluğa ihtiyacı var:

• Bize sisteminizi nasıl kusursuz kurduğunuzu anlatmayın; geçen ay canlı veritabanını nasıl sildiğinizi ve o krizden nasıl çıktığınızı anlatın.
• Bize Clean Code vaazları vermeyin; o teknik borç batağına nasıl saplandığınızı ve o enkazı temizlerken hangi bedelleri ödediğinizi anlatın.
• Sahneye çıkıp başarı pornosu sergilemeyin; arkadaki gençlerin elinden tutun, onlara sahadaki çıplak gerçekleri ve başarısızlıkları anlatın.

Pizzalar biter. Sticker'lar eskir.
Sahnede atılan o havalı nutuklar iki gün sonra unutulur.

Geriye sadece şu kalır:
Bir problemle karşılaştığında seni yalnız bırakmayan, başarısız olduğunda seni linç etmek yerine omzuna dokunan ve sahici olan o dürüst insanların yoldaşlığı.

Tiyatroyu bırakın.
Gerçek sahaya ve samimi üretime dönün.

Bu süreç öyle bir karşılıklı yalan ve performans sanatına dönüşmüştür ki; iki taraf da birbirinin yalan söylediğini bilir, iki taraf da gerçeğin bu olmadığını bilir ama yine de hiç kimse rolünü bozmaz. Perde açılır, replikler ezbere okunur, alkışlar tutulur ve oyun biter.

Gelin bu trajikomik tiyatronun perde arkasını birlikte aralayalım.

Birinci Perde: İlan Metnindeki İmkânsız Fantezi

Oyun, şirketin açtığı iş ilanıyla başlar. Başlık: "Mid-Level Full-Stack Geliştirici".
İlanın aradığı yetkinlikler listesine bakarsınız; sanki tek bir insan değil, koca bir NASA mühendislik departmanı aranıyordur:
"En az 5 yıl React, Vue ve Angular tecrübesi. Çok iyi derecede Go, Rust ve Python. Kubernetes cluster'larını sıfırdan kurup yönetebilen, Kafka ile yüksek hacimli veri işleyen, Terraform ile altyapı kodlayan, CI/CD pipeline'larını optimize eden, siber güvenlik penetrasyon testlerini yürüten ve tercihen yapay zeka LLM modelleri eğitebilen..."

Bu ilanı yazan İK uzmanının veya şirketin, bu teknolojilerin ne anlama geldiğine dair en ufak bir fikri yoktur. Şirketteki gerçek iş ise; WordPress benzeri basit bir içerik yönetim panelindeki butonların yerini değiştirmek ve Excel'den gelen fatura verilerini bir MySQL tablosuna yazdırmaktan ibarettir!

Ama ilan Silicon Valley devi gibi yazılmak zorundadır; çünkü kurumsal kibir bunu gerektirir.

İkinci Perde: CV'deki Zorunlu Yalanlar

Piyasada bu imkânsız ilanı gören 24 yaşındaki genç mühendis ne yapar?
Eğer dürüst davranıp CV'sine sadece gerçekten uzman olduğu şeyleri yazarsa (örneğin: "JavaScript'i iyi bilirim, temiz bir REST API yazarım, Postgres'te sorgu atarım"); o CV şirketin otomatik yapay zeka filtresini bile aşamaz. Çöpe atılır.

Hayatta kalabilmek için oyunun kuralına uymak zorundadır:
Bir hafta sonu YouTube'da 20 dakikalık bir videosunu izlediği Rust dilini CV'sine "Proficient" olarak ekler. Kendi bilgisayarında bir kez Docker container'ı ayağa kaldırmıştır; CV'ye "Kubernetes & Cloud Orchestration Uzmanı" yazar.

Yalan, sistemin zorunlu kıldığı bir hayatta kalma refleksine dönüşmüştür.

Üçüncü Perde: Canlı Mülakatta Akıl Tutulması

Ve büyük gün gelir: Canlı teknik mülakat.

Şirketin mülakatı yapan mühendisi ekranda belirir. Şirketin kendi kod tabanı spagettiye dönmüştür, veritabanında tek bir indeks bile yoktur, mimari her cuma çökmektedir. Ama o an mülakatı yapan kişi kendini bir Turing Ödülü jürisi gibi konumlandırır.

Adaya şunu sorar:
"Ekranı paylaş ve beyaz tahtada (Whiteboard) bana bir ikili ağacı (binary tree) tersine çeviren ve karmaşıklığı $O(\log n)$ olan algoritmayı kodla."

Aday terler. O algoritmayı gerçek meslek hayatında bir kez bile kullanmayacağını ikisi de çok iyi bilmektedir. Ama aday önceki hafta LeetCode'da o soruyu ezberlemiştir. Rolünü mükemmel oynar; sanki o an düşünüyormuş gibi tavana bakar, sakalını kaşır ve ezberlediği çözümü tahtaya yazar: "Hocam burada dinamik programlama yaklaşımıyla bellek karmaşıklığını minimize ettim."

Mülakatı yapan mest olur: "Harika bir algoritma vizyonu!"

İki taraf da rolünü kusursuz oynamıştır. Aday işe kabul edilir.

Dördüncü Perde: Gerçeklikle Çarpışma

Ve ilk iş günü. Çocuk heyecanla ofise gelir. "Acaba bugün hangi dağıtık algoritmayı optimize edeceğim, hangi Kubernetes pod'larını uçuracağım?" diye bekler.

Kıdemli mühendis yanına gelir, eline bir dosya tutuşturur:
"Hoş geldin kardeşim. Bizim muhasebe her ay sonunda logları Excel'e aktarıyor, oradaki tarih formatı bozuk çıkıyormuş. Şu PHP dosyasındaki string fonksiyonunu düzeltiver."

Çocuk ekrana bakar. 15 yıllık dokümantasyonsuz, tek bir satır testi olmayan, spagetti bir kod yığını... Mülakatta sorulan o ikili ağaçlardan, o Rust fantezilerinden, o Kafka kuyruklarından eser yoktur!

Şirket ikili ağaç tersine çevirebilen dahi aramıştır; ama ihtiyacı olan tek şey o tarih formatını düzeltecek sabırlı bir zanaatkardır.

Bu Tiyatroyu Kim Bitirecek?

Bu hastalıklı performans sanatı; sektörü gerçek mühendislikten, dürüstlükten ve verimlilikten koparıp koca bir ezbercilik sirkine dönüştürdü.

Şirketler mimari krizleri çözecek, soğukkanlılıkla sistemi ayakta tutacak adam aramıyor; mülakatta ezberlediği kalıpları en özgüvenli şekilde satan kişiyi işe alıyor. Sonra da o sistemlerin neden sürekli çöktüğünü merak ediyorlar.

Gerçek bir mülakat; adayın LeetCode hafızasını test etmek değildir.
Gerçek bir mülakat;

• Adayın önüne şirketin gerçek, kanayan bir bug'ını koyup "Bunu nasıl araştırırsın, nereden başlarsın?" diye sormaktır.
• Adayın daha önce yaptığı hataları, patlattığı sistemleri nasıl toparladığını dürüstçe dinlemektir.
• İki tarafın da maskelerini çıkarıp, gerçek problemleri konuşabilme cesaretidir.

Tiyatroyu bırakın.
Ezber kalıpları çöpe atın.
Ve masaya rol yeteneğinizi değil; gerçek, çıplak ve sahici mühendislik namusunuzu koyun.

Kuyruktaki vatandaşlar homurdanır, memur ekrana öfkeyle tıklar, tansiyon yükselir.

O an herkes suçu bankodaki memurda veya önündeki bilgisayarda sanır. Oysa arka planda, sunucu odalarının karanlığında can çekişen şey; yirmi yıldır yama üstüne yama yapılarak ayakta tutulmaya çalışılan, nefes almakta zorlanan devasa bir dijital Frankeştayn'dır.

Türkiye'deki kamu yazılımlarının, belediye portallarının, hastane bilgi yönetim sistemlerinin (HBYS) ve devasa kurumsal altyapıların içine girdiğinizde; modern bilgisayar bilimlerinin değil, bürokratik bir kabusun tarihini okursunuz.

İhale Mantığının İflası: "En Ucuza En Çürük Çözüm"

Bu dijital çürümenin kök nedeni teknik değil; tamamen yönetsel ve mevzuatsaldır: Kamu İhale Kanunu ve "En Düşük Teklif" Zihniyeti.

Normalde milyonlarca vatandaşın hayatına dokunan kritik bir sağlık veya vergi altyapısı kurulurken aranması gereken tek kriter: Sağlamlık, ölçeklenebilirlik, veri güvenliği ve sürdürülebilir mimari olmalıdır.

Peki bizde ihale nasıl açılır?
Masa başına geçilir, 500 sayfalık kopyala-yapıştır şartnameler hazırlanır ve günün sonunda ihale; işi gerçekten en kaliteli yapacak mühendislik ekibine değil, en akıl almaz ve en ucuz fiyatı kıran taşeron şirkete verilir!

O taşeron şirket ihaleyi kazanır. Bütçe o kadar komiktir ki, projeye kaliteli bir kıdemli mimar veya güvenlik uzmanı atayamaz. İki tane yeni mezun gence "Üç ayda bu sistemi bitirin" denir. Gençler geceleri sabahlayarak, internetten buldukları hazır kod parçalarını birbirine bağlayarak derme çatma bir sistem kurar.

İhale teslim edilir, para alınır, şirket ortadan kaybolur.
Ve kamu, o enkazla baş başa kalır.

Yıkılmak Üzere Olan Tarihi Binaya Payanda Çakmak

Aradan beş yıl geçer. Yeni bir yasa çıkar, vergi mevzuatı değişir veya yeni bir sağlık regülasyonu gelir.

O an yapılması gereken rasyonel hamle şudur: Bu derme çatma sistemi çöpe atmak, modern mimariyle sıfırdan sağlam bir altyapı inşa etmek.

Ama kamuda veya hantal kurumsal şirketlerde hiçbir yönetici bu sorumluluğu almak istemez. Çünkü sıfırdan sistem yazmak bütçe ister, onay süreçleri iki yıl sürer, en ufak bir aksaklıkta müfettişler kapıya dayanır. Yönetici için en güvenli yol, risk almamaktır.

Hemen başka bir şirkete küçük bir bütçeyle "bakım ve ek geliştirme" ihalesi verilir:
"Sisteme dokunmayın, sadece şu yeni kanunu sisteme yamayıverin."

Ve başlar yama üstüne yama devri:

• 2005 yılında Delphi veya eski .NET ile yazılmış monolitik bir veritabanı çekirdeği,
• Üzerine 2012'de yapıştırılmış hantal SOAP servisleri,
• Onun üzerine 2018'de zorla eklenmiş bir REST API katmanı,
• Ve en üstte 2024 model modern bir web arayüzü!

Bu, taşıyıcı kolonları çatlamış, temeli kaymış tarihi bir binanın yıkılmasını engellemek için dışarıdan ahşap payandalar ve çelik tellerle binayı tutturmaya benzer. Her yeni eklenen özellik, binanın yükünü biraz daha artırır; ta ki bina kendi ağırlığının altında çökene kadar.

Faturayı Memur ve Vatandaş Öder

Bürokrasinin bu vizyonsuzluğunun faturasını Ankara'daki ihale komisyonları veya klimalı odalardaki yöneticiler ödemez.

Faturayı;

• Acil serviste kalbi duran hastanın tahlil sonucunu görebilmek için o kilitlenen ekrana çaresizce bakan genç bir doktor öder.
• Tapu dairesinde tek bir imza için saatlerce kuyrukta bekleyen, öfkesi burnunda vatandaş öder.
• Gece yarısı o çöken kamu sunucusunu ayağa kaldırabilmek için dua eden, tek bir satır dokümantasyonu olmayan o kodun içinde boğulan genç sistem mühendisi öder.

Yazılım Bir İhale Değil, Yaşayan Bir Hizmettir

Bir köprü veya bir otoyol yaptığınızda ihaleyi verirsiniz; asfalt dökülür, beton kurur ve iş biter. Sonraki 10 yıl sadece bakımını yaparsınız.

Ama yazılım inşaat değildir. Yazılım; mevzuat değiştikçe, kullanıcı arttıkça sürekli beslenmesi, yenilenmesi, gereksiz parçalarından arındırılması gereken canlı bir organizmadır.

Kamu teknolojilerini kurtarmanın tek yolu; "en ucuz taşerona yaptırıp kaçma" mantığını terk etmektir.
Devlet kurumlarının ve büyük şirketlerin kendi bünyelerinde güçlü, liyakatli, iyi maaş alan kalıcı mühendislik kadroları kurması ve sistemleri birer ihale dosyası değil; yaşayan birer kamusal değer olarak yönetmesidir.

Yamalarla bina tutulmaz.
Çürük temelin üzerine saray inşa edilmez.

Günü kurtarmak için atılan her geçici yama; geleceğimize bırakılmış affedilmez bir teknik borç ve utanç belgesidir.

Bu cümlenin altına yerleştirilen görsel genellikle aynıdır: Güneşli bir sahil kenarında, yanında soğuk kahvesiyle MacBook'una gülümseyerek bakan, hayatının stresini arkasında bırakmış 23 yaşında bir genç.

Bu vaadin karşısında durup derin bir nefes alıyorum. Çünkü bu sahneyi sağlık sektöründeki bir analogla düşündüğümde kanım donuyor. Bir kurumun çıkıp şöyle bir duyuru astığını hayal edin: "Hafta sonları 6 hafta boyunca toplam 48 saat maket üzerinde dikiş atma ve sargı bezi sarma eğitimi alın; 7. haftanın pazartesi sabahı genel cerrahi kliniğinde karaciğer nakli ve açık kalp ameliyatı yapmaya başlayın!"

Böyle bir teklife aklı başında hiç kimse itibar etmez; dahası, bunu vadedenler hakkında nitelikli dolandırıcılıktan kamu davası açılır. Ancak söz konusu yazılım, dijital altyapılar ve insan hayatını dolaylı yoldan etkileyen kritik sistemler olduğunda, bu peri masalına her yıl on binlerce insan birikimlerini ve geleceğe dair en saf umutlarını yatırıyor.

Gerçeği en başta, hiçbir süslü cümlenin arkasına saklanmadan söyleyelim: Hayır, 6 haftada, 12 haftada, hatta yoğunlaştırılmış 6 ayda kimse "Full-Stack Mühendis" olamaz. Olabileceğiniz tek şey, belirli komutları belirli bir sırayla çalıştırmayı ezberlemiş bir "kod operatörü"dür. Ve bu ikisi arasındaki fark, acil tıp teknisyeni ile beyin cerrahı arasındaki fark kadar derindir.

Klon Projeler Mezarlığı: Todo App'ten Öteye Geçememek

Bir bootcamp müfredatının tipik anatomisini inceleyin. İlk iki hafta temel HTML, modern CSS ve biraz JavaScript sözdizimi. Üçüncü hafta React temelleri, bileşenler ve useState. Dördüncü hafta Node.js ve Express ile basit bir REST API, MongoDB bağlantısı. Beşinci hafta meşhur bitirme projesi: Ya bir Todo List uygulaması, ya bir e-ticaret sepeti ya da Netflix arayüz klonu. Altıncı hafta ise LinkedIn profil optimizasyonu ve mülakat tüyoları.

Peki bu sürecin sonunda öğrenci neyi öğrenmiş olur?

• Düğmeye basıldığında arayüzdeki sayacın 1 artmasını,
• Postman'den gelen bir JSON gövdesini veritabanına insert etmeyi,
• Tailwind sınıflarını kopyalayıp modern görünen bir kart bileşeni oluşturmayı.

Peki bu öğrenci neyi öğrenmemiştir?

• Bir HTTP isteğinin DNS çözümlemesinden başlayıp TCP el sıkışması, TLS sertifika doğrulaması ve yük dengeleyiciden geçerek sunucuya ulaşırken kat ettiği fiziksel ve mantıksal yolculuğu.
• Veritabanına yazdığı o basit find() sorgusunun, tabloda bir milyon satır olduğunda neden tüm CPU'yu kilitlediğini ve indeksleme mekanizmasının B-Tree mantığıyla nasıl çalıştığını.
• Bellek yönetimini, çöp toplayıcının (Garbage Collector) çalışma döngüsünü, bir JavaScript closure'ının nasıl sinsi bir memory leak üretebileceğini.
• Dağıtık bir sistemde iki mikroservis arasındaki ağ gecikmesinin ve paket kaybının tutarlılığı (data consistency) nasıl felç edebileceğini.

Bu, bir ilk yardım kursiyerine otomatik şok cihazının (OED) yeşil tuşuna basmayı öğretip, ardından ona ritim bozukluklarının elektrofizyolojisini, iyon kanallarının sodyum-potasyum pompasını ve kardiyak arrest anında uygulanacak ileri yaşam desteği farmakolojisini bildiğini iddia ettirmek gibidir. Yeşil tuşa basmak hayat kurtarabilir; ancak hasta ventriküler fibrilasyon dışındaki karmaşık bir taşikardiye girdiğinde o kursiyer sadece çaresizce ekrana bakar.

Bootcamp mezunlarının hazırladığı portfolyoların birbirinin karbon kopyası olması tesadüf değildir. İK yöneticilerinin ve teknik liderlerin önüne gelen her yüz CV'nin sekseninde aynı projeler vardır: "React ile Netflix Klonu", "MERN Stack Todo Uygulaması", "Hava Durumu API'si". Kod tabanlarına girdiğinizde, eğitim videolarındaki değişken isimlerinin dahi değiştirilmediğini, StackOverflow'dan alınmış blokların arkasındaki mantığın kavranmadığını görürsünüz. Bu bir üretim değil, pandomimdir.

"Full-Stack" Unvanının İflası

Sektörün en büyük yanılsamalarından biri de "Full-Stack" kavramının içinin bu kadar fütursuzca boşaltılmasıdır.

Mühendislik tarihinde Full-Stack; donanımdan, işletim sistemi çekirdeğinden, ağ protokollerinden, veritabanı motorunun disk I/O davranışından başlayıp tarayıcının render motoruna ve CSS boyama (paint) döngülerine kadar sistemin yatay ve dikey tüm katmanlarında problem çözebilme yetkinliğine verilen bir payeydi. Bu unvan, en az on yıllık uykusuz gecelerin, çökertilmiş production ortamlarının, analiz edilmiş bellek dökümlerinin (core dump) ve çözülmüş krizlerin ardından bir saygı nişanesi olarak kazanılırdı.

Bugün ise üç hafta önce console.log yazmayı öğrenen birine, Express'e bir router.get ekleyip MongoDB'ye bağlandı diye "Full-Stack Developer" kartviziti basılıyor.

Bu durum, sağlık ocağında tansiyon ölçen hemşireye, laboratuvarda kan tüpü santrifüj eden biyoloğa ve ameliyatta bistüri uzatan personele aynı anda "Siz artık Genel Tıp ve Cerrahi Otoritesisiniz" demek kadar absürttür. Bir insan her şey olduğunu iddia ediyorsa, aslında hiçbir şeyde derinleşmemiştir. Arayüzün erişilebilirlik (a11y) standartlarından habersiz, CSS grid sisteminin repaint maliyetini bilmeyen; sunucu tarafında ise thread pool'un ne olduğunu dahi duymamış bir geliştiriciye "Full-Stack" demek, sadece o geliştiriciye değil, tüm meslek etiğine yapılmış bir haksızlıktır.

Kırılan Hayaller ve Şişen İK Kutuları

Bu bootcamp endüstrisinin en karanlık tarafı teknik yetersizlikler değil; yarattığı insan dramıdır.

Farklı sektörlerde asgari ücrete ya da mobbinge mahkum edilmiş, geleceğe dair umut arayan gencecik insanlar; kredi çekerek, altınlarını bozdurarak veya ailelerinin dişinden tırnağından artırdığı son kuruşları bu kurumlara aktarıyorlar. Onlara vadedilen şey sadece bir meslek değil, sınıf atlama biletidir: "Sektörde yüz binlerce yazılımcı açığı var, mezun olur olmaz kapışılacaksınız."

Sonra ne oluyor? Kurs bitiyor. Sertifika alınıyor, LinkedIn'e o meşhur rozet ekleniyor. Ve o genç insan, Türkiye'nin acımasız ekonomik gerçekliğiyle yüzleşiyor.

Açılan tek bir "Junior Frontend Developer" ilanına 48 saat içinde 1.500 başvuru yağıyor. İK departmanları, ilk filtrede bootcamp sertifikalı ve bilgisayar mühendisliği temeli olmayan adayların CV'lerini doğrudan eliyor. Mülakata girmeyi başaran azınlık ise teknik liderin sorduğu ilk temel soruda eleniyor: "Bize JavaScript'te event loop mekanizmasının nasıl çalıştığını ve microtask queue ile macrotask queue arasındaki farkı anlatabilir misiniz?"

Ezber bozuluyor. Çünkü bootcamp'teki eğitmen o sorunun cevabını müfredata koymamıştır; o sadece async/await yazıp geçmeyi göstermiştir.

Sonuç? Borç harç içinde kalmış, özgüveni yerle bir edilmiş, kendisini "yetersiz ve aptal" hisseden binlerce genç insan. Oysa aptal olan onlar değildir; açgözlü olan, eğitimin doğasındaki sabır, tekrar, usta-çırak ilişkisi ve acı çekme zorunluluğunu kapitalist bir "hızlı zengin olma" pazarlamasına dönüştüren eğitim simsarlarıdır.

Mühendislik Sabırla Yoğrulur

Bir cerrah nasıl ki yüzlerce saat kadavra başında ter dökmeden, binlerce ameliyatta sadece retraktör tutarak hocasının parmak hareketlerini izlemeden cerrah olamazsa; bir yazılım mühendisi de yüzlerce saat dokümantasyon okumadan, onlarca bellek sızıntısını satır satır debug etmeden, mimari kararların bedelini gecenin üçünde sunucu başında ödemeden mühendis olamaz.

Yazılım öğrenmek demokratikleşmelidir, evet. İnternetin sunduğu açık kaynak kaynaklar, bedava kütüphaneler ve global topluluklar bir nimettir. Üniversite diploması tek geçer akçe değildir; alaylı olup da sektörün en parlak mimarilerini inşa eden sayısız deha vardır. Ancak o alaylı dehaların hiçbiri "6 haftalık hızlı kurslarla" o noktaya gelmemiştir. Onlar gecelerini Linux çekirdeğinin kaynak kodlarını inceleyerek, RFC metinlerini satır satır hatmederek ve yıllarını bu zanaata adayarak o seviyeye ulaşmışlardır.

Eğer bu sektöre adım atmak istiyorsanız, mucize vaat eden satıcılardan uzak durun.

Öğrenmenin kestirme yolu yoktur. 6 haftada ancak bir kütüphanenin kullanım kılavuzunu ezberleyebilirsiniz; ama mühendislik, kütüphaneler çöktüğünde ve kılavuzlar tükendiğinde ne yapacağınızı bilme sanatıdır. Ve o sanat, sadece zamanla, sabırla ve gerçek problemlerin karşısında ter dökerek öğrenilir.

"Türk Mühendislerden Dünyayı Sarsacak Buluş: Silikon Vadisi'ne Rakip Yerli ve Milli Yapay Zeka Çıktı!"

Haberin içeriğine tıkladığınızda, takım elbiseli kurucuların ofis koltuklarında verdikleri mağrur pozlar, arkada asılı duran neon şirket logoları ve "büyük vizyon" cümleleri karşılar sizi. Haberi okuyan sokaktaki sade vatandaş göğsü kabararak gururlanır; teknolojiyle ilgilenmeyen yatırımcılar heyecanla telefonlara sarılır.

Ancak bir yazılım mühendisi olarak o haberin bahsettiği ürünün GitHub deposuna, ağ isteklerine (network requests) veya kaynak koduna yakından baktığınızda hissettiğiniz tek şey derin bir mahcubiyet ve mesleki bir hicaptır.

Çünkü "dünyayı sarsacağı" iddia edilen o yerli teknoloji harikasının perdesini araladığınızda gördüğünüz şey şudur: Hugging Face'ten indirilmiş açık kaynaklı bir modelin üzerine yazılmış yirmi satırlık Python Flask kodu, Streamlit veya Tailwind ile giydirilmiş derme çatma bir arayüz ve butonların Türkçe'ye çevrilmesinden ibaret bir "inovasyon".

Ortada ne yeni bir mimari vardır, ne özgün bir matematiksel model, ne de optimize edilmiş bir derleyici. Sadece açık kaynak dünyanın emeğini alıp üzerine bir Türk bayrağı yapıştırmak ve bunu PR ajanslarının bültenleriyle milli bir zafer gibi servis etmek vardır.

Tıpta Şarlatanlık, Teknolojide Yerlilik Maskesi

Bu tablonun sağlık sektöründeki karşılığını çok iyi biliyoruz. Televizyon kanallarında veya gazete köşelerinde ara sıra türeyen merdiven altı "şifacılar" vardır. İki şifalı otu kaynatıp içine biraz nane ruhu damlatır ve kameraların karşısına geçip haykırırlar: "Kansere %100 yerli ve milli kesin çözüm bulundu! Batılı ilaç lobileri bu ilacı gizliyor!"

Halkın çaresizliğini, umudunu ve milli duygularını istismar eden bu şarlatanlığın karşısında tıp dünyası ne yapar? Bilimsel metodolojiye başvurur. "Kardeşim," der hekimler, "bu maddenin etken maddesi nedir? Faz 1, Faz 2, Faz 3 klinik deneylerin nerede? Çift-kör plasebo kontrollü çalışman hangi hakemli uluslararası dergide (peer-reviewed) yayımlandı? Biyoyararlanımı ve toksisite raporların nerede?"

Şarlatan bu soruların hiçbirine cevap veremez; hemen hamasete sığınır: "Bizi kıskanıyorlar, yerli buluşumuzun önünü kesmek istiyorlar."

İşte Türkiye'deki teknoloji medyasının ve "milli startup" simsarlarının yaptığı şey tam olarak budur.

Bir ürünün gerçekten inovatif, ölçeklenebilir ve derin teknoloji (deep-tech) barındırıp barındırmadığını sorgulayacak teknik liyakatten yoksun olan teknoloji basını; PR ajanslarının hazırladığı hazır basın bültenlerini kopyala-yapıştır yaparak yayınlamaktadır. Kimse şu soruları sormaz:

• Bu sistemin gecikme süresi (latency) ve hesaplama maliyeti (FLOPs) nedir?
• Kendi altyapınızda eğittiğiniz özgün bir ağırlık matrisi (weights) var mı, yoksa OpenAI API'sine prompt mu fırlatıyorsunuz?
• Sistem mimariniz hangi dağıtık sistem problemlerini çözüyor?
• Bu ürün global pazarda AWS, Google veya Meta'nın aynı alandaki çözümlerine kıyasla nasıl bir teknik üstünlük vadediyor?

Bu sorular sorulmadığı için, basit bir OpenAI wrapper'ı geliştiren herhangi bir ajans, ertesi sabah bültenlerde "Yerli ChatGPT" olarak manşetlere taşınabilmektedir.

PR Balonunun Kısa Ömrü ve Sessiz İflaslar

Bu yapay şovların ardında yatan asıl motivasyon nedir? Neden bu kadar büyük yalanlar, bu kadar pervasızca söylenir?

Cevap çok basit: Hibe, teşvik ve tohum yatırım kapmak.

Devlet kurumlarının, kalkınma ajanslarının ve teknokentlerin dağıttığı hibelerin jürileri çoğu zaman derin teknik detaylara hakim olmayan bürokratlardan veya akademisyenlerden oluşur. Önlerine gelen projenin teknik fizibilitesinden ziyade; sunumun parlaklığına, içinde kaç kez "Yapay Zeka", "Blokzincir", "Yerli ve Milli", "Endüstri 4.0" geçtiğine ve basında çıkan haberlerin sayısına bakarlar.

PR ajansına verilen 50 bin TL ile üç büyük gazetede haber yaptırılır. O haberler çerçeveletilip dosyanın içine konur. Jüri etkilenir; hibe onaylanır, tohum yatırım alınır. Kurucular kendilerine lüks şirket araçları kiralar, teknokentin en havalı ofisine yerleşir ve bir yıl boyunca LinkedIn'de "ekosistem lideri" olarak panellerde konuşmacı olurlar.

Peki sonra ne olur?

Aradan 18 ay geçer. Hibe biter. Yatırım tükenir. Ortada ne global pazara satılabilmiş gerçek bir ürün vardır, ne de faturasını ödeyen gerçek bir müşteri. Çünkü PR haberleriyle teknoloji medyasına manşet olabilirsiniz; ancak global bir müşteriye ürün satamazsınız. Bir Alman mühendise veya Amerikalı bir şirkete "Biz yerli ve milliyiz" diyemezsiniz; onlar sadece ürünün API yanıt hızına, SLA güvenilirliğine ve fiyat/performans oranına bakarlar.

Ve o "dünyayı sarsan" yerli girişim, bir cuma akşamı web sitesini sessiz sedasız kapatır. Ne teknoloji medyası tek bir satır takip haberi yapar, ne de o hibeleri dağıtanlar hesabını sorar. Kervan yeni bir PR balonuyla yoluna devam eder.

Sessiz Kalan Derin Mühendislik

Bu gürültülü sirkin yarattığı en büyük tahribat, Türkiye'de gerçekten nitelikli, sessiz ve derin mühendislik yapan insanların emeğini gölgelemesidir.

Bodrum katlarında, gösterişsiz üniversite laboratuvarlarında veya mütevazı ev ofislerinde gecesini gündüzüne katarak açık kaynak çekirdeklere yama gönderen, gömülü sistemlerde mikrodenetleyici mimarilerini optimize eden, dağıtık veritabanlarında konsensüs algoritmaları üzerine kafa yoran gerçek mühendislerimiz var.

Bu insanlar PR bülteni yazmayı bilmezler. LinkedIn'de sahte başarı hikayeleri anlatıp duygu sömürüsü yapmazlar. Takım elbise giyip panellerde hamaset nutukları atmazlar. Onların tek derdi, yazdıkları kodun bellek sızıntısı yapmaması, ağ paketlerinin kaybolmaması ve algoritmalarının matematiksel doğruluğudur.

Ancak sahne ışıkları ve kaynaklar şovmenlere aktarıldığı için, bu gerçek değerler ne hak ettikleri yatırımı bulabilirler ne de kamuoyunda tanınırlar. Ve günün sonunda, bu ülkenin yetiştirdiği en parlak beyinler, bu içi boş tiyatrodan bıkıp bavullarını toplayarak Amsterdam'a, Berlin'e, Londra'ya göç ederler.

Gerçek Yerlilik, Gerçek Liyakatle Başlar

Bir yazılımın "yerli ve milli" olması, sunucusunun Türkiye sınırları içinde bir veri merkezinde barınmasından veya arayüzünün Türkçe olmasından ibaret değildir.

Gerçek bağımsızlık; dışa bağımlı olmadan kendi derleyicinizi optimize edebilmekten, kendi işletim sistemi çekirdeğinizi güvenli kılabilmekten, kendi kriptografik protokollerinizi matematiksel olarak kanıtlayabilmekten geçer. Başkalarının kütüphanelerini kopyalayıp üzerine etiket basmak bağımsızlık değil, sadece çağdaş bir kapitulasyondur.

Teknoloji medyasının görevi, PR ajanslarının kuryeliğini yapmak değil; halka ve sektöre karşı bir filtre, bir kalite kontrol mekanizması olmaktır. İnovasyon iddiasıyla ortaya çıkan her girişime o acımasız mühendislik sorularını sormak zorundadırlar.

Ve biz yazılımcılar... Her parlak başlığın arkasında büyülenmek yerine, terminali açıp o sistemin kodunu, ağ trafiğini ve mimarisini sorgulamaya devam etmeliyiz. Çünkü bilim ve mühendislik alkışlarla değil; şüpheyle, testlerle ve acımasız gerçeklerle ilerler.

Masa başındaki Scrum Master veya Ürün Yöneticisi (Product Manager) boğazını temizleyerek sıradaki görevi okur:

"Kullanıcı ödeme adımlarında çoklu para birimi desteği ve veritabanı şemasının geriye dönük uyumlu refactor edilmesi."

Geri sayım başlar: 3, 2, 1... Kartlar açılır.

Kıdemli backend mühendisi: 13 puan.
Veritabanı uzmanı: 13 puan.
Junior geliştirici: 8 puan.
Ve teknik geçmişi olmayan, kariyerinde tek bir satır kod yazmamış, işin tüm mutfağını Excel tablolarından ibaret sanan Proje Yöneticisi: 2 puan.

Odaya bir anda derin, buz gibi bir sessizlik çöker. Yönetici kaşlarını çatarak ekrana bakar: "Arkadaşlar, neden 13 verdiniz ki? Altı üstü kullanıcı ekranında Dolar ve Euro simgesi gözükecek, bir de veritabanına bir kolon ekleyeceksiniz. Buton rengi değiştirmek gibi bir şey değil mi bu? Bence buna en fazla 3 puan verelim, çarşamba öğleden sonraya biter."

İşte o an, modern kurumsal yazılım dünyasının en trajikomik tiyatrosu olan "Planning Poker Kabaresi" perdesini açmıştır.

Ameliyathaneye Kronometreyle Giren İdari Memur

Bu sahneyi sağlık sektöründeki bir analogla gözünüzün önüne getirin.

Acil serviste bir cerrahi ekip, trafik kazası geçirmiş ve iç kanaması olan bir hastayı acilen ameliyathaneye almıştır. Cerrah batını açmış, parçalanmış dalağı onarmaya, mezenterik damarlardaki kanamayı klemplemeye çalışmaktadır.

Tam o sırada ameliyathanenin kapısı tekmeyle açılır. İçeriye hastanenin mali işler ve idari süreçler müdürü girer. Elinde bir kronometre ve bir pano vardır. Cerrahın omzuna dokunup şöyle der:

"Hocam, apandisit ameliyatını geçen hafta 25 dakikada bitirmiştiniz. Bu dalağı da 20 dakikada dikip kapatın lütfen. Koridorda bekleyen 15 hasta daha var, Sağlık Bakanlığı'nın bekleme süresi KPI'larını tutturamıyoruz. Ayrıca dikiş atarken kullandığınız ipliği de yarıya indirin, maliyetler şişiyor."

Böyle bir durumda cerrah ne yapar? Muhtemelen steril eldivenlerini çıkarıp o yöneticinin suratına fırlatır ve hastayı öldürmemek için onu derhal ameliyathaneden dışarı attırır.

Çünkü tıpta ameliyatın süresini idari memurun arzuları değil; hastanın anatomisi, dokunun kırılganlığı ve kanamanın şiddeti belirler. Cerrah bistüriyi vurduğu anda içeride neyle karşılaşacağını %100 öngöremez; karın boşluğu açıldığında beklenmeyen bir yapışıklık, atipik bir damar varyasyonu veya gizli bir nekroz çıkabilir.

Yazılım mühendisliği de tam olarak canlı bir cerrahidir. Kod tabanınız sizin hastanızdır. Ekranda gördüğünüz "küçük bir para birimi simgesi", aslında buzdağının suyun üstündeki 1 milimetrelik ucudur.

Suyun altında ise; distributed transaction yönetimi, mikroservisler arası eventual consistency problemleri, eski ödeme sağlayıcılarının geriye dönük uyumsuzlukları, veritabanında milyonlarca satır kilitlenmeden (lock contention) yapılacak şema migrasyonları ve concurrency yarış durumları (race conditions) yatmaktadır.

Kodun C'sini bilmeyen bir yöneticinin "altı üstü bir kolon ekleyeceksiniz" demesi, batın cerrahisine "altı üstü deriyi kesip biçeceksiniz" demek kadar vahim bir cehalettir.

Hayatta Kalma Kalkanı: Efor Şişirme ve Padding Sanatı

Peki, bu liyakatsiz baskı karşısında yazılımcılar ne yapar? İsyan edip istifa mı ederler?

Hayır, çoğu zaman hayatta kalma mekanizmasını devreye sokarlar: Eforları sistematik olarak şişirmek (Padding).

Mühendis bakar ki, gerçekçi bir tahmin verdiğinde (örneğin "Bu iş temiz ve testleriyle birlikte 3 gün sürer" dediğinde), yönetici bunu 1 güne indirmek için pazarlık yapıyor. O zaman mühendis zihninde bir savunma algoritması çalıştırır:

1. İşin gerçek süresi: 3 gün.
2. Beklenmeyen teknik borç payı: 2 gün.
3. Yöneticinin pazarlıkla kırpacağı pay: 3 gün.
4. Toplam talep edilen efor: 8 gün.

Mühendis toplantıda "Bu iş en az 8 gün sürer" der. Yönetici zafer kazanmış bir komutan edasıyla pazarlığa oturur: "8 çok, bunu 5 günde bitirin, anlaşalım."

Mühendis yüzünü ekşitir, sanki büyük bir fedakarlık yapıyormuş gibi iç çeker: "Peki, ekip olarak gecemizi gündüzümüze katarız, 5 günde bitirmeye çalışırız."

Sonuç? Herkes mutludur! Yönetici "üç günlük tasarruf sağladım" diyerek üst yönetime sunum yapar; mühendis ise aslında 3 günde bitireceği iş için 5 gün alarak arkasını sağlama almış, stresini minimize etmiştir.

Ancak bu sahte mutluluğun bedeli çok ağırdır: Karşılıklı güvenin tamamen yok olması.

Yönetici bilir ki yazılımcı eforu şişiriyor; yazılımcı bilir ki yönetici her tahmini yarıya indirmeye çalışacak. Ortada mühendislik tahmini kalmaz; pazar yerinde domates fiyatı için yapılan şark kurnazlığı kalır.

Story Point Bir Para Birimi Değildir

Scrum ve Çevik (Agile) metodolojilerin ortaya çıkış amacı bu değildi.

Fibonacci dizisi (1, 2, 3, 5, 8, 13...) zamanı değil; karmaşıklığı, bilinmezliği ve riski ölçmek için tasarlanmıştı. Bir işe 13 puan vermek, "bu iş 13 gün sürer" demek değildir; "bu işte çok fazla bilinmeyen değişken var, risk yüksek, mimari olarak dikkatli adım atmalıyız" demektir.

Fakat teknik bilgisi olmayan yöneticilerin elinde Story Point, doğrudan saate ve güne dönüştürülen bir kölelik katsayısına evrildi: "Ekibin sprint hızı 40 puan, demek ki adam başı günde 2 puan kod yazacaksınız!"

Bu matematiksel ilkellik, yazılımın doğasına aykırıdır. Bir mühendis bazen üç gün boyunca ekrana tek bir satır kod yazmadan sadece mimari çizer, logları inceler ve bellek profili çıkarır; dördüncü gün tek bir satırlık bir konfigürasyon değişikliğiyle tüm sistemi 10 kat hızlandırır. O tek satır kodun değeri, bin satır kopyala-yapıştır kod yazmaktan çok daha büyüktür.

Tiyatroyu Bitirmek

Bu kısır döngüyü kırmanın tek bir yolu vardır: Teknik liderliğe saygı duymak ve tahminin doğasını anlamak.

Bir hastanede başhekim nasıl ki mali işler uzmanı değil de kıdemli bir tıp doktoru olmak zorundaysa; yazılım ekiplerinin başında da kodun kokusunu (code smell) bilen, teknik borcun faturasını ödemiş, mimari vizyona sahip teknik liderler olmak zorundadır.

Yöneticinin görevi mühendisle kodun kaç saat süreceği üzerine pazarlık yapmak değildir. Yöneticinin görevi:

• İş gereksinimlerinin sınırlarını netleştirmek,
• Ekibin önündeki bürokratik ve organizasyonel engelleri kaldırmak,
• Ve mühendisin "burada yüksek risk var" uyarısına saygı duyarak ürünün takvimini o gerçekliğe göre yönetmektir.

Tahmin bir taahhüt değil, bir olasılık dağılımıdır. Yazılım dünyasında hiçbir ameliyat yüzde yüz garantili değildir. Ve o masada bistüriyi tutan insana güvenmiyorsanız, o masaya hiç oturmamalısınız.

"Biz stajyerlerimize para değil, parayla satın alamayacakları muazzam bir tecrübe kazandırıyoruz. Burası senin için bir okul, CV'ne bizim adımızı yazmak sana tüm kapıları açacak."

Bu cümle, modern kurumsal dünyanın en pervasız, en ahlaksız yalanlarından biridir.

"Tecrübe kazandırma" kılıfı altına gizlenmiş olan şey; asgari ücretin dahi çok görüldüğü, yol ve yemek masraflarının gencin kendi cebinden (veya ailesinin emekli maaşından) karşılandığı, haftada 45 saat boyunca production ortamındaki angarya işlerin sırtına yıkıldığı katıksız bir emek sömürüsüdür.

Genç bir üniversite öğrencisi veya yeni mezun, sektöre adım atabilmek, o meşhur "en az 2 yıl tecrübeli junior" ilanlarının kapısını aralayabilmek umuduyla bu zehirli sözleşmeyi kabul eder. Masasına oturur. Ve çok geçmeden anlar ki, ona vaat edilen o "okul" aslında modern bir dijital taş ocağıdır.

İntörn Hekimlik Sendromu: Eğitim mi, Ucuz İş Gücü mü?

Bu tablonun tıp dünyasındaki karşılığı ne yazık ki asırlık bir yaradır: İntörn hekimlik.

Tıp fakültesinin son sınıfına gelen öğrenciler, bir yıl boyunca hastanelerde "intörn doktor" unvanıyla görev yaparlar. Teoride bu yılın amacı; kıdemli hekimlerin yanında hasta muayene etmek, klinik karar verme süreçlerini izlemek, vaka tartışmalarına katılmak ve hekimlik zanaatını sahada öğrenmektir.

Peki pratikte ne olur?

Hastanenin yetersiz personel kadrosu yüzünden intörn hekimler; sabahın köründen gecenin yarısına kadar yüzlerce hastadan kan alan, EKG çeken, laboratuvara kan tüpü taşıyan, taburculuk dosyalarını arşivleyen ve kıdemlilerin angaryalarını temizleyen "bedava asistanlara" dönüştürülür. Yanında durdukları hoca onlara iki satır klinik mantık anlatmaz; çünkü sistem onları bir öğrenci olarak değil, hastanenin dönmesini sağlayan en ucuz dişli olarak görmektedir.

İşte yazılım sektöründeki stajyerlik düzeni, intörn hekimlik sendromunun birebir kopyasıdır.

Şirket stajyeri alır. Ona bir mentor atamaz. Kıdemli mühendislerin stajyere bir şeyler anlatacak vakti yoktur; çünkü onlar da yöneticinin gerçek dışı sprint teslim tarihleri altında ezilmektedir. Stajyer masada tek başına bırakılır. Önüne yığılan işler ise şunlardır:

• Kimsenin dokunmak istemediği 10 yıllık eski bir projenin eksik dokümantasyonunu yazmak,
• Excel tablolarındaki yüz binlerce satır veriyi tek tek kopyalayıp veritabanına girmek,
• UI'daki butonların piksellerini sağa sola kaydırmak,
• Ve production ortamında patlayan, kıdemlilerin uğraşmaktan nefret ettiği saçma sapan third-party kütüphane bug'larını çözmeye çalışmak.

Ortada bir eğitim yoktur. Ortada bir mentorluk yoktur. Ortada sadece şirketin kıdemli mühendise saatliği 50 dolar ödemek istemediği işleri, 21 yaşındaki bir gence sıfır liraya yaptırma kurnazlığı vardır.

"Hata Yaparsan Faturasını Sen Ödersin" İkiyüzlülüğü

Bu sömürü düzeninin en iğrenç boyutu ise sorumluluk anında ortaya çıkar.

Stajyere iş verirken "Sen bu sistemin bağımsız bir geliştiricisisin" diyerek sırtını sıvazlayan yöneticiler; stajyerin yaptığı bir hata yüzünden production sunucusu çöktüğünde veya veritabanında bir tutarsızlık yaşandığında bir anda canavara dönüşürler.

Slack kanallarında genci azarlayanlar, "Bunu nasıl yaparsın, hiç mi test etmedin!" diye bağıranlar türer.

Bir acil serviste intörn hekimin yanlış damar yolu açması veya yanlış doz hesaplaması intörnün suçu değildir; onun başında durup o enjektörü denetlemeyen kıdemli hekimin ve nöbetçi uzmanın suçudur. Bir sistemde stajyerin yaptığı tek bir kod değişikliği doğrudan production ortamına çıkabiliyorsa ve sistemi çökertebiliyorsa; orada suçlu stajyer değil, CI/CD pipeline'ı kuramayan, code review yapmayan ve ortam yetkilendirmesini beceremeyen teknik liderdir.

Yetkiyi ve sorumluluğu kıdemliye ait olan bir ortamda, faturayı stajyere kesmek sadece yöneticilik basiretsizliği değil, apaçık bir korkaklıktır.

Usta-Çırak Geleneğinin Katli

Bizim kültürümüzün temelinde Ahilik ve usta-çırak ahlakı vardır. Tıpta da, kadim zanaatlarda da bu böyledir.

Usta, çırağını atölyeye aldığında sadece onun emeğini kullanmaz; onun ekmeğinden, suyundan, mesleki ahlakından ve geleceğinden sorumlu olur. Usta, çırağının yanlışını kendi yanlışı bilir; elini tutar, aletin nasıl tutulacağını, malzemenin nasıl işleneceğini sabırla gösterir. Ve çırak ustasının yanında geçirdiği yılların sonunda sadece meslek öğrenmez; bir karakter ve mesleki haysiyet kazanır.

Bugünün yazılım şirketleri ise usta-çırak ilişkisini bir insan kaynakları maliyet optimizasyonuna indirgemiştir.

Bir gence tecrübe kazandırmak bir lütuf değildir. Bir şirketin ekibine kattığı stajyere mentorluk vermesi, ona kod incelemesi (code review) yapması, mimari kararların arkasındaki nedenleri anlatması bir "bağış" değil; o şirketin sektöre ve kendi geleceğine olan asgari borcudur.

Dahası; bir insanın harcadığı zaman, döktüğü alın teri ve verdiği zihinsel odak para ile karşılanmak zorundadır. "Sana para vermiyoruz ama çok şey öğreniyorsun" demek, bakkaldan ekmek alırken "Parayı vermiyorum ama dükkanında çok güzel müşteri trafiği oluşturdum" demek kadar ahlaksızcadır. O genç insan o ofise gelebilmek için otobüs bileti almak, öğlen karnını doyurmak ve insanca yaşamak zorundadır.

Genç Yetenekleri Küstüren Ekosistem Kuruyup Kalır

Bugün Türkiye'de binlerce parlak bilgisayar mühendisliği öğrencisi, daha üniversite sıralarındayken bu acımasız sömürü çarkıyla karşılaştığı için sektöre ve ülkeye küsüyor.

Kendisine değer verilmediğini, bedava iş gücü olarak kullanıldığını, hiçbir şey öğretilmeden aşağılandığını gören bir genç; mezun olduğu gün ilk fırsatta bavulunu toplayıp insanca çalışma koşulları sunan Avrupa veya Amerika merkezli şirketlere gitmek istiyor.

Sonra aynı şirket yöneticileri LinkedIn'de yakınıyorlar: "Türkiye'de kaliteli yazılımcı bulamıyoruz, beyin göçü bizi mahvetti."

Siz o gençleri stajyerken aç bıraktınız. Onlara yol parası vermediniz. Onlara kodun mantığını öğretmek yerine angaryalarınızı yıktınız. Ve şimdi onların size sadakat göstermesini mi bekliyorsunuz?

Bir yazılım şirketinin kalitesi, ofisindeki langırt masasıyla veya mutfağındaki bedava fıstık ezmesiyle ölçülmez. Bir şirketin kalitesi ve etik düzeyi; ekibindeki en savunmasız, en tecrübesiz insana —yani stajyerine— nasıl davrandığıyla, ona ne kadar saygı duyduğuyla ve emeğinin karşılığını ne kadar adil ödediğiyle ölçülür.

Ve stajyerini sömüren bir şirketin ürettiği yazılımdan da, kurduğu gelecekten de bu memlekete hiçbir hayır gelmez.

try {
  processCriticalTransaction(userPayload);
} catch (error) {
  logger.error("Bir hata oldu ama çaktırmıyoruz:", error);
  return null; // veya return [];
}

Geliştirici bu kodu yazarken kendince gurur duyar: "Bakın, sistemim asla çökmüyor (crash olmuyor). Hata çıksa bile yakalıyorum, loga yazıyorum ve akışı kesintisiz devam ettiriyorum."

Oysa o geliştiricinin bilmediği şey, sistemin kalbine saatli bir bomba yerleştirdiğidir.

Hatayı yutarak (exception swallowing) yoluna devam eden o süreç; bellekte yarım kalmış bir nesne referansı, veritabanında açılmış ama kapanmamış bir transaction kilidi veya hesaplama mantığında zehirlenmiş bir state (durum) bırakmıştır.

Sistem çökmeyip suni solunumla nefes almaya devam ettikçe; o bozuk veri diğer servislere yayılır, bellek sinsi bir şekilde tükenir ve saatler sonra, gecenin üçünde tüm platform öngörülemez, kurtarılamaz ve izi sürülemez bir kaskat çöküşle (cascading failure) yerle bir olur.

İşte tam bu noktada, telekomünikasyon dünyasının ve dağıtık sistemlerin en devrimci dehası olan Joe Armstrong'un ve Erlang/OTP dünyasının o radikal manifestosu yankılanır: "Let it crash!" (Bırakın çöksün!)

Tıpta Apoptozis ve DNR: Ne Zaman Duracağını Bilmek

Bu felsefeyi kavrayabilmek için biyolojinin ve acil tıbbın en derin kurallarına bakmak gerekir.

İnsan vücudunda her gün milyarlarca hücre DNA hasarına uğrar veya işlevini yitirir. Vücut bu hasarlı hücreleri "ne pahasına olursa olsun yaşatmaya" çalışmaz. Aksine, biyolojinin en kusursuz savunma mekanizması olan apoptozis (programlanmış hücre ölümü) devreye girer. Hasarlı hücreye intihar sinyali gönderilir; hücre sessizce parçalanır, temizlenir ve yerine kemik iliğinden gelen taptaze, sağlıklı bir hücre yerleşir.

Eğer vücut o hasarlı hücreyi zorla yaşatmaya çalışsaydı ne olurdu? O hücre kontrolsüzce çoğalır, diğer dokuları istila eder ve biz buna tıp dilinde kanser derdik.

Benzer şekilde, acil serviste veya yoğun bakımda hekimliğin en ağır ama en hayati kararlarından biri "DNR" (Do Not Resuscitate - Canlandırma Uygulamayın) anıdır.

Beyin ölümü gerçekleşmiş, çoklu organ yetmezliğine girmiş ve biyolojik olarak geri dönüşü imkansız bir hastaya saatlerce kalp masajı yapmak, adrenalin pompalamak hastayı hayata döndürmez; sadece hastanın kaburgalarını kırar, dokuları parçalar ve ölümü gereksiz bir ıstırapla uzatır. İyi bir hekim, ne zaman müdahale edeceğini bildiği kadar, doğanın sınırlarına ne zaman saygı duyup geri çekileceğini de bilen hekimdir.

Erlang Felsefesi: Bozuk State'i Tamir Etmeye Çalışma

Yazılımda "Let it crash" ilkesi, "Hata yönetimini boş verin, sistem darmadağın olsun" anlamına gelmez. Tam aksine, kusursuz bir hata izolasyonu ve yeniden başlatma disiplini demektir.

Geleneksel savunmacı programlamada (defensive programming), geliştirici her olası hatayı önceden tahmin edip kodun içine yüzlerce if-else ve try-catch serpiştirir. Bu durum kodu okunmaz hale getirdiği gibi, tahmin edilemeyen sıra dışı bir durum (edge case) ortaya çıktığında sistemin öngörülemez bir duruma (undefined state) girmesine neden olur.

Erlang ve aktör modelinin yaklaşımı ise son derece berraktır:

1. İzolasyon (Shared Nothing): Her işlem (process) kendi izole bellek alanında çalışır. Bir işlemin çökmesi, yanındaki diğer işlemi fiziksel olarak etkileyemez.
2. Fail Fast (Hızlıca Çök): İşlem beklenmeyen bir durumla karşılaştığı an, durumu yamamaya çalışmadan anında ölmeli (crash olmalıdır). Çünkü belleğindeki verinin bozulup bozulmadığını garanti edemezsiniz.
3. Süpervizör Ağacı (Supervisor Trees): Ölen işlemi gözlemleyen bir üst mekanizma (supervisor) vardır. Bu mekanizma, ölen süreci milisaniyeler içinde öldürür ve onu bilinen, temiz, kararlı bir başlangıç state'i ile yeniden ayağa kaldırır.

Bu, bir cerrahın ameliyathanede enfekte olmuş ve dokusu çürümüş bir apandisiti dikip onarmaya çalışmak yerine, onu kökünden kesip dışarı atması ve hastanın sağlıklı dokusunun kendini yenilemesine izin vermesi gibidir. Temiz bir başlangıç, yamalı bir hayattan her zaman daha güvenilirdir.

Zombi Süreçler ve Sessiz Zehirlenme

Bir sistemde istisnaları yutmanın en korkunç sonucu "Zombi Süreçler"dir.

Örneğin bir mikroservis mimarisinde, ödeme kuyruğunu tüketen bir worker düşünün. Bir veritabanı bağlantı hatası veya deserialization bug'ı yüzünden worker'ın bir thread'i kilitlendi. Ancak geliştirici hatayı catch bloğunda yuttuğu için proses işletim sistemi seviyesinde ayakta duruyor; Kubernetes pod'unun liveness check'i 200 OK dönmeye devam ediyor.

Dışarıdan baktığınızda her şey yeşil, monitörler pırıl pırıl!

Fakat içeride, kuyruktaki mesajlar birikiyor; kilitlenen thread hafızayı tüketiyor, diğer thread'lerin kaynaklarını sömürüyor. Sistem can çekişiyor ama ölmesine izin verilmediği için yerine yeni bir pod ayağa kaldırılamıyor.

Eğer o worker ilk hatada "bırakılsaydı ve çökseydi"; işletim sistemi prosesi öldürecek, Kubernetes pod'un çöktüğünü anlayıp 2 saniye içinde taze bir pod başlatacak ve kuyruk akmaya devam edecekti.

Sistemin çökmesini engellemek adına yaptığınız her yapay pansuman, aslında sistemin kendini iyileştirme refleksini felç eden bir toksindir.

Çöküşten Korkmayan Mimariler İnşa Etmek

Mühendislik olgunluğu, "asla çökmeyen sistemler" hayal etmekten vazgeçip; "her an çökebileceğini kabul eden ve çöktüğünde hiçbir veri kaybetmeden, saniyeler içinde ayağa kalkan sistemler" tasarlamaya başladığınızda gelir.

Bu zihniyet dönüşümü mimarinizi kökten değiştirir:

• Stateless Tasarım: Süreçlerinizin içinde kalıcı durum tutmazsınız. Bir sürecin ölmesi hiçbir veri kaybına yol açmaz; durum veritabanında veya dağıtık kuyrukta güvenle saklanır.
• İdempotent İşlemler: Yeniden başlayan bir süreç, yarım kalmış bir işi tekrar denediğinde (retry) yan etki (side-effect) üretmez; aynı işlemi güvenle tekrarlayabilir.
• Circuit Breaker ve İzolasyon: Çöken bir bağımlılık, tüm platformu peşinden sürüklemez; devre açılır ve sistem zarafetle geriler (graceful degradation).

Korku, mimarinin en kötü danışmanıdır. Bir sistemin çökmesinden korktuğunuz için her satırı yapay korumalarla boğarsanız, ortaya sadece kriz anında ne yapacağı kestirilemeyen kırılgan bir canavar çıkarırsınız.

Bırakın çöksün. Hızlı çöksün, gürültülü çöksün ve temiz çöksün. Çünkü ancak doğru çökmeyi bilen sistemler, gerçek krizlerin ortasında dimdik ayakta kalabilir.

Saatlerdir ekrana kilitlenmişsinizdir. Gözleriniz kan çanağına dönmüştür. Terminalde kırmızı bir hata mesajı yanıp sönmekte veya daha kötüsü, sistem hiçbir hata fırlatmadan tamamen yanlış bir çıktı üretmektedir. Kod satırlarını defalarca baştan sona okumuş, logları kontrol etmiş, değişkenlerin değerlerini tek tek yazdırmış ama mantık hatasını bir türlü yakalayamamışsınızdır.

Çaresizlik içinde yan masadaki meslektaşınıza dönersiniz:

"Ahmet, müsaitsen bir bakar mısın? Kafayı yemek üzereyim, iki saattir bu fonksiyonun neden null döndüğünü bulamıyorum."

Ahmet sandalyesini kaydırarak ekranınızın yanına gelir: "Anlat bakalım, ne yapıyor bu fonksiyon?"

Siz başlarsınız anlatmaya:

"Bak şimdi, kullanıcı formu gönderince önce API isteğini karşılıyoruz. Şurada gelen parametreleri valide ediyoruz. Sonra veritabanından kullanıcı profilini çekiyoruz. Ardından eğer kullanıcının yetkisi varsa şu servisi çağırıp..."

Tam o kelimede sesiniz kesilir. Gözleriniz büyür. Parmağınız ekranda bir satırın üzerinde asılı kalır. Ağzınız açık öylece bakakalırsınız.

Ahmet daha tek bir kelime etmemiştir; hatta muhtemelen ekrandaki koda henüz odaklanamamıştır bile.

Siz aniden sandalyenizden fırlarsınız: "Tamam Ahmet, bakmana gerek kalmadı, çözdüm! Değişkeni fonksiyonun içinde değil döngünün dışında tanımlamışım!"

Ahmet bıyık altından gülerek sandalyesini masasına çeker. Siz ise hem sorunu çözmenin getirdiği hafiflemeyle hem de iki saattir burnunuzun ucundaki hatayı göremediğiniz için kendinize duyduğunuz öfkeyle baş başa kalırsınız.

İşte yazılım folkloruna "Rubber Duck Debugging" (Plastik Ördek Hata Ayıklama) olarak geçen bu pratik, sadece şakacı bir ofis geleneği değil; insan bilişinin (cognition) en büyüleyici sırlarından biridir.

Zihnin Görünmez Sıçramaları ve Kör Noktalar

Neden kendi kendimize düşünürken göremediğimiz bir hatayı, bir başkasına (veya masadaki sarı bir plastik ördeğe) sesli olarak anlatırken saniyeler içinde fark ederiz?

Bunun cevabı beynimizin düşünme mimarisinde yatar.

Zihnimiz iç diyalogla (monologla) çalışırken inanılmaz derecede tembel ve varsayımsaldır. Kodu sessizce okurken, gözlerimiz ekrandaki karakterleri tarar ama beynimiz aslında kodun ne yazdığını değil, ne yazması gerektiğini düşündüğümüzü okur.

Zihin satırların üzerinden hızla atlarken varsayımlar üretir: "Evet, bu fonksiyon kullanıcıyı getiriyor. Evet, burada id kontrolü yapılıyor. Evet, burada veri dönüyor." İç sesimiz, kendi inşa ettiği mantık köprülerindeki çatlakları ve boşlukları bilinçaltında otomatik olarak doldurur. Buna psikolojide "bilişsel kör nokta" veya "doğrulama yanlılığı" (confirmation bias) denir.

Ancak düşüncenizi kafanızın içinden çıkarıp ses dalgasına dönüştürmeye karar verdiğiniz an, beyninizde bambaşka nörolojik devreler devreye girer.

Konuşmak, lineer bir eylemdir. Zihninizdeki o soyut, dağınık ve çok boyutlu düşünce bulutunu kelimelere dökebilmek için; o düşünceyi tek boyutlu bir çizgiye, mantıksal bir neden-sonuç zincirine dizmek zorundasınızdır.

Kodu bir başkasına anlatırken, "Burada kullanıcıyı getiriyoruz" diyemezsiniz; "Şu fonksiyona şu ID'yi vererek şu tablodan kullanıcı kaydını istiyoruz" demek zorunda kalırsınız. Ve işte o sesli ifade, beyninizi kodun hayalindeki versiyonuyla değil, ekranda duran acımasız ve çıplak gerçekliğiyle yüzleşmeye zorlar.

Kendi sesinizi kendi kulağınızla duyduğunuz an, mantık köprüsündeki o eksik taşı görürsünüz: "Bir dakika, ben fonksiyona ID'yi parametre olarak geçmedim ki!"

Acil Serviste Devir Teslim (Handover) ve Vaka Sunumu

Bu zihinsel aydınlanmanın tıp dünyasındaki karşılığı, hekimlerin her gün yaşadığı vaka sunumu (case presentation) ve nöbet devir teslim (handover) ritüelidir.

Acil serviste saatlerdir takip ettiğiniz, bir türlü genel durumunu toparlayamadığınız ve kesin tanıya varamadığınız karmaşık bir hasta vardır. Kan tahlillerine bakmışsınızdır, röntgenleri incelemişsinizdir ama parçalar bir türlü yerine oturmuyordur.

Sabah nöbet devri gelir. Kıdemli uzman hekim veya hoca servisleri gezmeye başlar. Sıra sizin hastanıza geldiğinde dosyayı elinize alıp hocaya vaka sunmaya başlarsınız:

"Hocam, 54 yaşında erkek hasta. Dün gece şiddetli epigastrik karın ağrısı ve bulantı şikayetiyle başvurdu. Karın muayenesinde defans yok. Kan biyokimyasında amilaz normal, lökosit hafif yüksek. EKG çektik, sinüs ritminde... ama nabız dakikada 52..."

Cümlenin tam bu noktasında asistan hekimin gözleri parlar. Sözünü keser: "Hocam, bir dakika! Epigastrik ağrı, bradikardi... Bu tablo bir mide-bağırsak problemi değil; sağ koroner arter tutulumlu bir Akut İnferior Miyokard Enfarktüsü (kalp krizi) olabilir! Hemen bir sağ derivasyonlu EKG daha çekelim!"

Hoca tek bir söz söylememiştir. Sadece dinlemiştir.

Asistan hekim, vakayı kafasının içinde darmadağınık düşünürken göremediği bağlantıyı; semptomları kronolojik ve sesli bir anlatı haline getirirken kendi ağzıyla yakalamıştır. Tıpta hekimlerin vakaları birbirine yüksek sesle sunması sadece bir bürokrasi değil; hekimin kendi zihnini hizalamasını sağlayan hayati bir teşhis aracıdır.

Yapay Zeka Çağında Yeni Nesil Plastik Ördekler

Bugün yazılım geliştiriciler olarak masalarımızda artık sadece sarı plastik ördekler veya yan koltuktaki meslektaşlarımız yok. Artık terminallerimizde ve IDE'lerimizde yapay zeka asistanları var.

Birçok geliştirici fark etmiştir: ChatGPT'ye veya kod asistanına karmaşık bir hatayı sormak için problemi uzun uzun yazdığınızda; tam "Gönder" butonuna basacakken sorunun çözümünü kendi kendinize bulursunuz.

Neden? Çünkü yapay zekaya bir prompt hazırlamak, aslında modern bir Rubber Duck seansıdır.

Yapay zekanın problemi anlayabilmesi için; bağlamı (context) tanımlamak, girdileri ve çıktıları açıkça yazmak, varsayımlarınızı tek tek sıralamak zorunda kalırsınız. Ve o problemi yapay zekanın anlayabileceği berraklığa kavuşturduğunuz anda, aslında problemin çözümünü kendi zihninizde de berraklaştırmış olursunuz. Çoğu zaman yapay zekanın yanıtına dahi ihtiyaç kalmaz.

Kendi Zihnine Karşı Alçakgönüllülük

Rubber duck debugging, mühendisliğin en büyük erdemlerinden birini öğretir bize: Kendi aklının mutlaklığına inanmamak ve bilişsel körlüklerini kabul edecek kadar alçakgönüllü olmak.

Zihniniz sizi kandırabilir. Gözleriniz ekrandaki hatayı saatlerce doğruymuş gibi algılayabilir. Çünkü insan beyni bir derleyici (compiler) değil; anlam üreten, boşlukları dolduran ve hikayeler uyduran organik bir makinedir.

Bu yüzden tıkandığınızda, saatlerce ekrana nefretle bakarak klavyeyi dövmek yerine yapacağınız en bilgece hareket; masanızdaki plastik oyuncağa, yanınızdaki arkadaşınıza veya boş bir kağıda dönüp konuşmaktır:

"Bak dostum, olay şöyle başladı..."

Çünkü bazen bir problemi çözmek için gereken tek şey daha fazla kod yazmak değil; düşüncelerimizin sesini kendi kulaklarımızla duyabilecek cesareti göstermektir.

"Arkadaşlar, bu mimari üzerinde son altı aydır gece gündüz çalışıyoruz. Tam on bin satır kod yazdık, onlarca test hazırladık. Şimdi kalkıp da 'bu yaklaşım yanlışmış, hepsini çöpe atıp baştan başlayalım' diyemeyiz. Bu kadar emeği heba edemeyiz; elimizdekini toparlayıp canlıya çıkmak zorundayız."

Bu sözler dile getirildiği anda, mantık kapıdan dışarı çıkmış ve sahneyi insan psikolojisinin en kadim tuzaklarından biri olan "Sunk Cost Fallacy" (Batık Maliyet Yanılgısı) devralmıştır.

Geliştiriciler ve yöneticiler; harcanan zamanı, dökülen alın terini ve uykusuz geceleri birer "onur madalyası" gibi görerek yanlış bir karara körü körüne sarılırlar. Oysa evrenin ve matematiğin en temel kuralı son derece nettir: Geçmişte harcadığınız kaynaklar geri getirilemez; gelecekte vereceğiniz kararlar ise sadece o andan itibarenki fayda ve maliyete göre verilmelidir.

Yanlış yöne giden bir trene bindiyseniz, biletinize ne kadar para ödediğinizin veya trende kaç saat yolculuk ettiğinizin hiçbir önemi yoktur. Son durağa kadar gidip uçurumdan yuvarlanmak istemiyorsanız, ilk istasyonda inmek zorundasınızdır.

Tıpta Yanlış Teşhis ve Tedavide İnat Etmek

Bu psikolojik körlüğün acil servisteki veya yoğun bakımdaki yansıması ölümcüldür.

Bir hastaya nefes darlığı ve göğüs ağrısıyla geldiğinde ilk etapta "pnömoni" (zatürre) teşhisi koyduğunuzu ve yüksek doz antibiyotik tedavisine başladığınızı düşünün. Aradan 48 saat geçmiştir. Hastanın akciğer sesleri düzelmemekte, oksijen saturasyonu düşmekte, bacaklarında ödem gelişmekte ve kardiyak enzimleri yükselmektedir.

Tablo bas bas bağırmaktadır: "Bu hasta zatürre değil, kalp yetmezliğine bağlı Akut Akciğer Ödemi tablosunda!"

Şimdi bir an için o hekimin şöyle düşündüğünü hayal edin: "İki gündür bu hastaya en pahalı antibiyotikleri verdik, tedavi planını sisteme böyle girdik, dosyasına zatürre yazdık. Şimdi kalkıp da kalp yetmezliği tedavisine dönersek iki günlük emeğimiz ve harcadığımız ilaçlar çöpe gider. Biz antibiyotiğin dozunu biraz daha artıralım, belki işe yarar."

Böyle bir hekim hastasını göz göre göre öldürür.

Tıpta en saygıdeğer refleks, "Teşhisim yanlıştı, hemen rotayı değiştiriyorum" diyebilmektir. Hekimlik egosu, hastanın yaşam hakkının önüne geçemez. Yeni klinik veriler hipotezinizi çürüttüğü an; o ana kadar verdiğiniz tüm serumları keser, gerekiyorsa hastanın kalbini rahatlatacak diüretikleri ve vazodilatatörleri anında devreye sokarsınız. Çünkü tıpta geçmişe takılıp kalanlar sadece mezarlıkları büyütür.

Bataklığı Büyüten On Bin Satır

Yazılım dünyasında ise ne yazık ki kod silmek, kod yazmaktan çok daha zor bir psikolojik eşiktir.

Bir mühendis ekibi düşünün. Altı ay önce popüler bir mikroservis mimarisini veya karmaşık bir event-sourcing modelini benimsemişlerdir. İhtiyaçları olmadığı halde Kafka kuyrukları kurmuş, CQRS yapılandırmış, distributed transaction'lar için Saga pattern'leri yazmışlardır.

Sistem büyüdükçe anlaşılır ki; veritabanı tutarlılığı sağlanamamakta, ağ gecikmeleri sistemi felç etmekte ve basit bir kullanıcı kaydı bile 15 servisin onayından geçmek zorunda kaldığı için sürekli patlamaktadır. Aslında ihtiyaç duyulan tek şey, Postgres üzerinde çalışan sade, monolitik ve transactional bir mimaridir.

Fakat ekip masaya oturduğunda kimse o on bin satırı silmeye cesaret edemez. Çünkü o kodları silmek, son altı ayın bir hata olduğunu, harcanan şirket bütçesinin boşa gittiğini ve mimari vizyonun iflas ettiğini itiraf etmek demektir.

Bunun yerine ne yapılır?

• Patlayan kuyrukları kurtarmak için araya yeni retry servisleri yazılır (+1.500 satır).
• Tutarsız verileri gece tarayıp düzelten karanlık cron script'leri eklenir (+2.000 satır).
• Servislerin ayağa kalkma sırasını yönetmek için karmaşık bash script'leri döşenir (+500 satır).

Yani bataklığa batmış bir sistemi kurtarmak adına, bataklığın içine 4.000 satır daha beton dökülür! Sonuçta sistem biraz daha ağırlaşır, biraz daha karmaşıklaşır ve kaçınılmaz çöküş anı sadece birkaç ay ertelenmiş olur.

En İyi Kod, Henüz Yazılmamış Olandır

Büyük mühendisleri ortalama mühendislerden ayıran en temel fark, koda duydukları duygusal bağın derecesidir.

Kıdemsiz bir yazılımcı yazdığı koda aşık olur. Onu çocuğu gibi sever; her fonksiyonunu, her değişken ismini bir sanat eseri gibi korur. Birisi kodunu silmek veya refactor etmek istediğinde kişisel bir hakarete uğramış gibi hırçınlaşır.

Oysa bilge bir mühendis bilir ki; kod bir varlık (asset) değil, bir yükümlülüktür (liability).

Yazdığınız her satır kod; gelecekte bakım yapılması gereken, güvenlik açığı barındırma potansiyesi olan, test edilmesi gereken ve işletim sistemi güncellendiğinde kırılma riski taşıyan bir borçtur. Bir sistemi 10.000 satır kodla çözmek bir başarı değildir; aynı sistemi 200 satır sade bir mantıkla çözebilmek gerçek zekadır.

Ve gerektiğinde, hiçbir pişmanlık duymadan o 10.000 satırı git rm komutuyla tarihin çöplüğüne gönderebilmek, bir yazılımcının erişebileceği en yüksek mesleki olgunluk seviyesidir.

Çöpe Atma Cesareti

Eğer bir projede işler sarpa sarmışsa, her yeni özellik eklenişinde başka bir yer kırılıyorsa ve mimari artık ekibin ayağına dolanan bir prangaya dönüşmüşse; kendinize şu soruyu dürüstçe sorun:

"Bugün bu projeye sıfırdan başlasaydık, mevcut bilgimiz ve tecrübemizle bu mimariyi tekrar tercih eder miydik?"

Eğer bu sorunun cevabı net bir "Hayır" ise; o ana kadar kaç yüz saat harcadığınızın, kaç bin satır kod yazdığınızın hiçbir hükmü yoktur.

O kodu çöpe atın.

Hatalarınızı kabul edin. Yanlış yolda koşarak doğru hedefe varamazsınız. Harcanan zaman zaten harcanmıştır; onu geri alamazsınız. Ancak geleceğinizi, akıl sağlığınızı ve projenin kaderini kurtarmak hala sizin elinizdedir.

Çünkü gerçek ustalık, ne zaman inşa edeceğini bilmek kadar, ne zaman yıkıp temiz bir sayfayla baştan başlayacağını bilmektir.

"Sistem tasarlayan herhangi bir organizasyon, kaçınılmaz olarak kendi iletişim yapısının bir kopyası (kopyalanmış bir yansıması) olan tasarımlar üretmeye mahkûmdur."

Bu cümle literatüre Conway Kanunu (Conway's Law) olarak geçti ve o günden bu yana geçen altmış yılda doğruluğunu bir an bile yitirmedi.

Eğer bir şirkette derleyici (compiler) yazmak üzere dört ayrı ekip görevlendirirseniz, ortaya kaçınılmaz olarak 4 aşamalı bir derleyici çıkar. Eğer bir şirkette veritabanı ekibi, backend ekibi ve frontend ekibi birbirine cam duvarlarla ayrılmış, farklı katlarda oturan ve sadece resmi Jira biletleriyle haberleşen üç ayrı kast sistemi gibi örgütlenmişse; üretecekleri yazılım da tam olarak üç katmanlı, aralarında devasa veri transfer maliyetleri ve anlaşmazlık protokolleri barındıran hantal bir yapıya bürünür.

Kod, hiçbir zaman nötr bir laboratuvar ortamında, saf matematiksel bir zerafetle yazılmaz. Kod; insanların birbirleriyle olan sohbetlerinin, dedikodularının, güç savaşlarının, güven seviyelerinin ve organizasyonel korkularının dijital bir kopyasıdır.

Hastane Koridorlarındaki Kopukluk: Beden mi Hasta, Organizasyon mu?

Bu durumun acil tıptaki ve hastane yönetimindeki faturası doğrudan insan canıdır.

Bir üniversite hastanesini düşünün. Acil Tıp Kliniği, Radyoloji Anabilim Dalı ve Genel Cerrahi Kliniği... Teoride bu üç birimin tek bir ortak amacı vardır: Kapıdan giren kritik hastayı hayatta tutmak.

Fakat pratikte ne olur?

Eğer hastanenin başhekimliği bu birimler arasında sağlıklı bir iletişim ve güven kültürü kuramamışsa; her klinik kendi bürokratik kalesine çekilir. Acildeki hekim trafik kazası geçirmiş hastaya acil batın tomografisi ister. Radyoloji ekibi "Haber vermeden hasta gönderdiniz, randevu sırası var, çekemeyiz" diyerek hastayı sedyede 45 dakika bekletir. Çekim yapılır; cerrahi kıdemlisi "Bu rapor çok yüzeysel yazılmış, hastayı ameliyata alamam, tekrar konsültasyon notu düşün" der.

O koridorda hasta iç kanamadan şoka girerken, asıl patoloji hastanın parçalanmış karaciğerinde değildir; asıl patoloji, hastanenin organizasyon şemasındaki düşmanlıklarda ve bürokratik duvarlardadır. Sistem parçalanmıştır, çünkü o sistemi işleten insanlar parçalanmıştır.

Yazılım sistemlerinde de aynı ölümcül tablo yaşanır. Bir mikroservisin diğer bir mikroservise HTTP çağrısı yaparken neden 500 hatası döndüğünü veya neden anlamsız 30 saniyelik timeout süreleri tanımlandığını araştırdığınızda; meselenin ağ katmanında değil, o iki servisi yazan ekiplerin birbirleriyle konuşmamasında yattığını görürsünüz. İletişimsizlik, kodun içine retry mekanizmaları, güvensizlik protokolleri ve defansif kod blokları olarak sızar.

Spagetti Kodun Altındaki Spagetti Organizasyon

Bir şirketin kod tabanına baktığınızda, o şirketin ofis içindeki güç dengelerini bir röntgen filmi gibi okuyabilirsiniz:

• Tanrı Nesneler (God Objects): Eğer kodda binlerce satırdan oluşan, her şeye karışan, tüm kararları tekeline almış devasa bir sınıf (class) varsa; emin olun o şirkette her kararı kendi onayından geçirmek isteyen, kimseye yetki devretmeyen otokrat bir kurucu veya teknik direktör vardır.
• Kırılgan API Sözleşmeleri: Eğer iki servis arasındaki veri formatı sürekli bozuluyor ve bir taraf diğerini habersizce yarı yolda bırakıyorsa; o iki servisin yöneticileri haftalık ürün toplantılarında birbiriyle pasif-agresif çatışmalar yaşayan insanlardır.
• Aşırı Savunmacı Kod: Kod tabanı her parametreyi on kez kontrol eden, sürekli "acaba diğer servis bana yanlış veri gönderir mi?" paranoyasıyla yazılmış kalkanlarla doluysa; o şirkette hata yapanın acımasızca cezalandırıldığı, psikolojik güvenliğin sıfır olduğu bir kültür hüküm sürmektedir.

Mimarlar aylarca toplanıp beyaz tahtalarda en modern mikroservis diyagramlarını, domain-driven design (DDD) modellerini çizebilirler. Ancak o kutucukların içine yerleştireceğiniz ekipler birbirine güvenmiyorsa, günün sonunda elde edeceğiniz tek şey "dağıtık bir monolit" (distributed monolith) ve ağ üzerinden birbirine küfür eden mikroservisler çöplüğüdür.

Ters Conway Manevrası (Inverse Conway Maneuver)

Peki bu döngü nasıl kırılır?

Çözüm, yazılım literatüründe "Ters Conway Manevrası" olarak adlandırılan stratejide yatar: Eğer sistem mimarinizi değiştirmek istiyorsanız, önce organizasyonel yapınızı ve ekiplerinizin iletişim biçimini değiştirmek zorundasınız.

Yazılım mimarları artık sadece UML diyagramları çizen teknik figürler olamazlar; onlar aynı zamanda organizasyonel sosyologlar olmak zorundadırlar.

1. Çapraz Fonksiyonel Otonom Ekipler: Frontend'ciyi bir odaya, Backend'ciyi başka bir kata, DevOps'çuyu bodrum katına hapsetmeyi bırakın. Belirli bir iş alanından (domain) uçtan uca sorumlu; içinde tasarımcısı, ürün yöneticisi, önyüz ve arayüz mühendisi barındıran otonom ekipler (squad'lar) kurun. Bu insanlar aynı masada oturduklarında veya aynı Slack kanalında nefes aldıklarında, servisler arasındaki sürtünme doğal olarak yok olur.
2. Ortak Sorumluluk Kültürü: "Bu hata backend'in suçu", "Bu UI tasarımcının hatası" duvarlarını yıkın. Bir hasta masada kaldığında tüm ameliyathane ekibi birlikte hesap verir; bir servis çöktüğünde de tüm squad birlikte ayağa kaldırmalıdır.
3. Ofis Mimarisi Kod Mimarisidir: Uzaktan çalışmada bile kanalların şeffaflığı, DM (direkt mesaj) kültürünün yerini açık tartışma ortamlarının alması; kodun içindeki gizli bağımlılıkları (hidden coupling) anında azaltır.

Kodu Düzeltmek İstiyorsan İnsandan Başla

Sistemler soyut makineler değildir; insan zihninin ve toplumsal ilişkilerin somutlaşmış halleridir.

Eğer projenizde teknik borçlar çığ gibi büyüyorsa, kod tabanınız bir labirente dönmüşse ve ekipler birbirinin ayağına basmadan tek bir özellik dahi canlıya alamıyorsa; suçu programlama dilinde veya kütüphanelerde aramayın.

Dönün ve şirketinize bakın.

Kimin kiminle konuşmadığına, yöneticilerin hangi bilgileri sakladığına, ekiplerin birbirine ne kadar güvendiğine bakın. Çünkü şirketinizin içindeki duvarları yıkmadan, kodunuzun içindeki spagettiyi asla çözemezsiniz.

Melvin Conway'in altmış yıl önce fısıldadığı gerçek bugün de değişmemiştir: Kodunuz, aynadaki kendi yüzünüzdür.

"Piyasa şartlarını ve enflasyonu göz önünde bulundurarak hepinize tam %35 zam yaptık! Sektör ortalamasının çok üzerindeyiz, şirketimiz çalışanının her zaman yanındadır."

Toplantı biter. Yazılımcı masasına döner, cebindeki telefonu çıkarır ve hesap makinesini açar.

Aldığı zam kağıt üzerinde %35 görünmektedir; ancak son bir yılda oturduğu evin kirası %80 artmıştır, market sepeti ikiye katlanmıştır, elektrik ve doğalgaz faturaları uçmuştur. Dahası, mesleğinin en temel gereksinimi olan ve dövizle fiyatlanan bir MacBook'un veya harici monitörün fiyatı üçe katlanmıştır.

O yeni zamlı maaşı o günkü Merkez Bankası kuruyla dolara veya euroya böldüğünde ortaya çıkan gerçek acımasızdır: Geçen yıla kıyasla cebine giren döviz miktarı %25 azalmıştır.

Yani kağıt üzerinde "zam almış", ama reel hayatta ve küresel alım gücünde ciddi şekilde yoksullaşmıştır.

Tıptaki Performans Çarkı ve Hekimin Geçim Kaygısı

Bu trajik tablonun tıp dünyasındaki karşılığı, son yıllarda Türkiye'deki hekim göçünü tetikleyen en büyük dinamiktir: Döner sermaye ve performans sistemi aldatmacası.

Bir cerrah veya acil tıp uzmanı düşünün. Altı yıl tıp fakültesi okumuş, beş yıl uzmanlık yapmış, binlerce saat nöbet tutmuştur. Masasında duran hastanın açık kalbine veya parçalanmış beynine müdahale etmektedir. Hata payı sıfırdır.

Ancak aynı hekim, ameliyathaneden çıkıp dinlenme odasına geçtiğinde aklında hastanın fizyolojisi değil; "Bu ay döner sermaye yattı mı? Çocuğun okul taksidini nasıl denkleştireceğim? Ev sahibi kiraya %100 zam istiyor, ne yapacağım?" soruları dönmektedir.

Dünyanın en kritik, en odaklanma gerektiren işini yapan bir insana insanca bir temel yaşam standardı sunmayıp, onu performans puanlarıyla ve enflasyon karşısında eriyen katsayılarla boğuşmaya mahkum ettiğinizde ne olur? O hekim tükenir. Odaklanamaz hale gelir. Ve ilk fırsatta Almanca kursuna yazılarak bu ülkeyi terk eder.

Yazılım mühendisliği de cerrahi gibi saf zihinsel odaklanma (deep work) gerektiren bir disiplindir.

Bir mühendisin zihninde aynı anda onlarca veri modelini, mimari akışı, bellek tahsisini ve güvenlik riskini simüle edebilmesi için; zihninin berrak, huzurlu ve kaygısız olması gerekir. Masaya oturduğunda "Kredi kartı asgarisini nasıl ödeyeceğim?" diye düşünen bir mühendisten yüksek kaliteli, hatasız ve vizyoner bir yazılım mimarisi üretmesini beklemek, gözleri görmeyen bir cerraha açık kalp ameliyatı yaptırmaya benzer.

Küresel Yabancılaşma: Aynı Kod, On Kat Farklı Hayat

Türkiye'de yerel para birimiyle (TL) maaş alan bir yazılımcının yaşadığı en büyük psikolojik yıkım, mesleğin küresel doğasından kaynaklanır.

Biz tekstil işçisi değiliz; ürettiğimiz değer coğrafi sınırlara hapsolmuş değildir.

Bugün Kadıköy'deki bir ev ofisinde oturan Türk yazılımcı; terminalinde Docker ayağa kaldırırken, AWS üzerinde Kubernetes cluster'ı yapılandırırken veya TypeScript ile karmaşık bir önyüz mimarisi kurarken, tam olarak Berlin'deki, San Francisco'daki veya Londra'daki meslektaşıyla aynı bilişsel eforu sarf etmekte, aynı RFC standartlarını okumakta ve aynı GitHub depolarına katkı sunmaktadır.

Fakat ay sonu geldiğinde;

• Berlin'deki meslektaşı ayda 5.500 Euro net maaş alıp, iki haftalık maaşıyla dünyanın en yeni bilgisayar donanımını alabilir ve Avrupa'da tatile gidebilirken;
• İstanbul'daki kıdemli Türk yazılımcısı, 50-60 bin TL bandına sıkıştırılmış maaşıyla ay sonunu getirmeye, bozulan telefonunu 12 taksitle nasıl yenileyeceğini hesaplamaya çalışmaktadır.

Bu uçurum, derin bir mesleki yabancılaşma (alienation) doğurur. Emeğinizin küresel ölçekte bu kadar ucuzlatıldığını görmek, sadece ekonomik bir kayıp değil; insanın kendi haysiyetine ve mesleki değerine vurulmuş ağır bir darbedir.

"Remote Çalışma" Bir Çıkış Kapısı mı, Beyin Göçü mü?

Bu adaletsizliğin doğal bir sonucu olarak, son beş yılda Türkiye'nin en nitelikli yazılımcıları yerel piyasadan elini eteğini çekti.

Yurt dışına fiziksel olarak göç edemeyenler bile, yabancı şirketlere uzaktan (remote) döviz bazlı sözleşmelerle çalışmaya başladı. Global piyasada aylık 3.000 - 4.000 Dolar kazanan bir Türk mühendisi; Türkiye'deki yerel şirketlerin teklif ettiği "özel sağlık sigortası ve yemek kartı" paketlerine artık sadece gülümseyip geçiyor.

Peki yerel şirketler ve KOBİ'ler ne yapıyor?

Hala 2015 yılının döviz kurlarında ve kafa yapısında kalarak; kıdemli mühendislere komik TL maaşları teklif etmeye devam ediyorlar. Sonra da konferans kürsülerinde şikayet ediyorlar: "Türkiye'de kaliteli mühendis bulamıyoruz, herkes yurt dışına kaçıyor!"

Siz insanlara hak ettikleri alım gücünü vermiyorsunuz. Enflasyonun %80 olduğu bir ülkede %30 zam yaparak insanların reel gelirini çalarken, onların şirkete sadakat duymasını bekliyorsunuz. Kusura bakmayın ama sadakat, market kasasında geçmeyen bir para birimidir.

Zihinsel Emeğin Bedeli

Bir şirketin en değerli sermayesi ofisindeki masalar, sandalyeler veya sunucular değildir; o şirketin mühendislerinin beyin hücreleridir.

Eğer çalışanınızın zihnini ekonomik kaygılardan arındıramıyorsanız, aslında şirketinizin kendi geleceğini ateşe atıyorsunuz demektir. Çünkü borç harç içindeki bir yazılımcının yazdığı kodda bug çıkar; güvenlik açığı çıkar; mimari felaketler çıkar. Ve o felaketlerin şirkete maliyeti, zamanında vermekten kaçındığınız o birkaç bin liralık maaş farkının yüz katı olur.

Yazılımcı arkadaşlarımıza da bir çağrımız var: Emeğinizi küresel standartların altında ucuzlatmayın. Kendi değerinizi yerel vasatlığın belirlemesine izin vermeyin. Dil öğrenin, küresel piyasaya açılın ve hakkınız olan alım gücünü talep edin.

Çünkü hayat, enflasyon kasırgasında eriyen bordrolara boyun eğmek için çok kısa; mühendislik zanaatı ise geçim derdine kurban edilemeyecek kadar kıymetlidir.

Üniversitenin bilgisayar mühendisliği bölümünde 3. sınıf öğrencisi olan 21 yaşındaki hevesli bir genç, harçlığını çıkarmak ve sektöre erkenden adım atmak için bir şirkete "Part-Time Yazılım Asistanı" olarak başvurur.

Haftada iki buçuk gün okula gidecek, kalan günlerde ofiste kıdemlilerin yanında bir şeyler öğrenip ufak tefek bug'ları çözecektir. Verilen ücret asgari ücretin yarısıdır; yol ve yemek zar zor karşılanmaktadır ama genç adam mutludur: "Tecrübe kazanıyorum ya, gerisi önemli değil."

Aradan tam üç hafta geçer. Şirketin kıdemli tek yazılımcısı, şirketin toksik ortamından ve ödenmeyen maaşlarından bıkıp aniden istifa eder.

Patron masasında viskisini yudumlarken bir kriz planı yapar. Dışarıdan kıdemli bir mühendis almaya kalksa en az 60-70 bin TL ödemesi gerekecektir. Oysa odanın köşesinde, gözleri pırıl pırıl parlayan, henüz iş hayatının kurtlarını tanımayan o 21 yaşındaki üniversite öğrencisi oturmaktadır.

Patron yanına gider, omzuna babacan bir tavırla vurur:

"Furkan (veya Can, veya Emre), ben senin gözlerindeki o ışığı en baştan gördüm. Sen bizim eski senior'dan çok daha zehirsin. Bu şirketin geleceği sensin. Artık projenin tüm liderliği sende, sana güvenim tam!"

Ve o gün; tüm AWS root şifreleri, production veritabanı erişimleri, müşteri toplantıları ve canlı ortamdaki ödeme altyapısı, henüz "İşletim Sistemleri" dersinin vize sınavına bile girmemiş o öğrencinin kucağına bir saatli bomba gibi bırakılır.

İntörne Bırakılan Acil Servis Cinayeti

Bu durumun acil servisteki karşılığı katıksız bir cinayet girişimidir.

Taşra hastanesinde gece nöbetindesiniz. Nöbetçi uzman hekim ortalıkta yok; kıdemli asistan hekim rapor alıp gitmiş. Hastanenin başhekimi, stajyer intörn doktorun yanına geliyor ve şöyle diyor:

"Delikanlı, sen çok çalışkan bir çocuksun, tıp fakültesinde de notların iyiymiş. Bu gece acil servisin anahtarı sende. Trafik kazası gelirse göğüs tüpü takarsın, kalp krizi gelirse trombolitik başlarsın, kafa travması gelirse entübe edersin. Hadi göreyim seni!"

Böyle bir şey gerçekleştiğinde ne olur?

O çocuk daha bir hastanın nabzını doğru düzgün hissetmeden, kapıdan fışkıran kanla giren bir politravma vakasıyla karşılaşır. Donakalır, eli ayağı titrer. Hasta gözlerinin önünde can verir.

Ve ertesi sabah hastane yönetimi ile savcılık kapıya dayandığında, o "sen zehir gibi çocuksun" diyen başhekim ilk olarak kendini kurtarır: "Biz yetkiyi ona vermedik, haddini aşıp müdahale etmiş!" Faturayı 23 yaşındaki stajyere keser, meslekten men edilmesine göz yumarlar.

İşte yazılım sektöründe bir üniversite öğrencisine kıdemli sorumluluğu yıkmak, o öğrenciyi korumasız bir şekilde yoğun bakımın ortasına tek başına atmakla aynı ahlaksızlıktır.

Vizeler, Finaller ve Gecenin Üçünde Çöken Veritabanı

O öğrencinin hayatı bir anda kabusa döner.

Gündüz okulda diferansiyel denklemler veya algoritma analizi dersinde otururken, cebindeki telefon aralıksız titremeye başlar. Patron WhatsApp'tan yazmaktadır: "Sunucu çöktü, müşteriler arıyor, hemen bak!"

Çocuk amfiden koşarak çıkar. Koridorda, dizlerinin üzerine açtığı eski laptopuyla telefonunun internetini bağlayarak SSH üzerinden çöken Docker container'ını ayağa kaldırmaya çalışır. Bir yandan hocanın devamsızlık yoklamasını düşünür, bir yandan yaklaşan final sınavını, bir yandan da 10 bin müşterinin verisinin silinme riskini.

Bu yük, 21 yaşındaki bir insanın taşıyabileceği bir yük değildir.

Sonuç nedir?

1. Ağır Tükenmişlik (Burnout): Henüz meslek hayatına başlamadan saçları dökülen, anksiyete krizleri yaşayan ve uykusuzluk çeken gençler.
2. Korkunç Bir Impostor Sendromu: Öğrenci bilmediği mimari kavramlar karşısında ezildikçe kendisini "yetersiz, yeteneksiz ve sahtekar" hissetmeye başlar. Oysa sorun onun yetersizliği değil; beş yıllık tecrübe gerektiren bir işin ona zorla dayatılmasıdır.
3. Akademik Yıkım: Derslerden kalınır, okul uzatılır ve geleceğe dair kariyer planları erken yaşta sakatlanır.

Günah Keçisi İlan Edilmek

Bu tiyatronun son perdesi ise kaçınılmaz bir felaketle kapanır.

Canlı sistem bir cuma akşamı kilitlenir. Yanlış yazılmış bir SQL sorgusu yüzünden müşteri veritabanı kilitlenir veya veriler uçar. Patron müşteriye karşı zor durumda kalır; para kaybeder.

Ve o gün, o babacan patronun ağzından dökülen cümleler bir kırbaç gibi iner:

"Biz sana güvendik! Sen bu şirketi batırdın! Bir projeyi bile yönetemedin, senden hiçbir şey olmaz!"

Ucuz iş gücü uğruna bir gencin hayallerini, psikolojisini ve geleceğini sömüren o şirket; işler ters gittiğinde tüm suçu o öğrencinin sırtına yükleyip onu kapının önüne koyar. Ve ne yazık ki sektörde bu travmayı atlatamayıp yazılım mesleğini tamamen bırakan sayısız pırıl pırıl genç vardır.

Kıdemli Maaşı Ödemeden Kıdemli Çıktısı Beklemek Hırsızlıktır

Buradan tüm şirket sahiplerine ve yöneticilere sesleniyoruz:

Bir öğrenciyi şirketinize katıyorsanız, ona öğrenci gibi davranmak zorundasınız.

Onun yeri production sunucusunun kök dizini (root) değildir. Onun yeri; kıdemli mühendislerin kodlarını okuduğu, test ortamlarında güvenle hata yapabildiği, mimarinin neden öyle kurulduğunu tartıştığı korunaklı bir laboratuvardır.

Part-time çalışan bir öğrenciye production ortamının sorumluluğunu yıkmak; hem o gence yapılan bir zorbalık, hem müşteriye yapılan bir sahtekarlık, hem de mühendislik mesleğinin onurunu ayaklar altına almaktır.

Genç arkadaşlarımıza da tavsiyemiz şudur:

Size boyunuzdan büyük unvanlar verip sırtınızı sıvazlayan ama bordronuza asgari ücretin yarısını layık gören kurumlardan derhal uzaklaşın. O sahte "liderlik" unvanları bir ödül değil; kriz anında başınıza geçirilecek birer kurbandır. Sizin en büyük sermayeniz gençliğiniz, öğrenme merakınız ve akıl sağlığınızdır; onu ucuz patronların kurnazlıklarına feda etmeyin.

İnsanlar ellerinde kahveleriyle sessizce sıranın ilerlemesini bekliyorlar. Sıra geldikçe turnikeden bip sesleri yükseliyor: Parmak izi okutuluyor, yüz tanıma kamerasına bakılıyor veya kart basılıyor.

İçeri giren yazılımcı derin bir nefes alıyor: "Şükür, bugün de saat 09:00'dan önce girdim, sistemde dakikam eksik yazılmayacak."

Bu sahneyi ilk kez gören bir yabancı; buranın devlet sırlarının korunduğu, nükleer füzyon veya kuantum işlemciler geliştiren dünyanın en gizli ve disiplinli laboratuvarlarından biri olduğunu düşünebilir.

Oysa burası, altı üstü bir ayakkabı markasının e-ticaret sitesini veya bir mobilya firmasının stok takip uygulamasını geliştiren sıradan bir yazılım ajansıdır. Ve o turnikelerdeki dakikalar; bilime veya teknolojiye olan saygıdan değil, devletin sunduğu gelir vergisi stopajı, KDV ve SGK prim muafiyetinden tek bir kuruş bile kaybetmemek için bir muhasebeci titizliğiyle sayılmaktadır.

Türkiye'deki teknokent ekosisteminin acımasız ve çıplak gerçeğine hoş geldiniz: Gerçek inovasyon ile vergi optimizasyonu tiyatrosunun yer değiştirdiği o tuhaf dünya.

SGK Teşviki İçin Her Hastaya Çekilen Gereksiz MR

Bu sistemik kurnazlığın sağlık sektöründeki karşılığı, özel hastanecilik tarihimizin en büyük yaralarından biridir.

Özel hastanelerin Sosyal Güvenlik Kurumu'ndan (SGK) daha fazla ödeme alabilmek ve teşviklerden yararlanabilmek için geliştirdiği karanlık mekanizmaları hatırlayın.

Acil servise hafif bir baş ağrısıyla giren hastaya; tıbbi hiçbir endikasyon olmadığı halde derhal kontrastlı beyin MR'ı, servikal tomografi ve lüzumsuz onlarca biyokimya tahlili yazılır. Hastanenin genel cerrahı, en ufak bir lipomu (yağ bezesini) bile SGK faturalandırma sistemine "komplike derin doku tümörü rezeksiyonu" koduyla girer.

Amaç hastayı iyileştirmek değildir; amaç, devletin kamu sağlığını korumak için ayırdığı bütçe havuzundan maksimum teşviki hortumlamaktır. Bu tablonun faturası ise hem gereksiz radyasyona maruz kalan hastaya, hem de iflasın eşiğine gelen kamu bütçesine çıkar.

İşte Türkiye'deki teknokentlerin önemli bir kısmında dönen Ar-Ge çarkı, bu özel hastane teşvik istismarının yazılım versiyonudur.

E-Ticaret Sitesini "Derin Öğrenmeli Ar-Ge" Diye Yutturmak

Kanunun ruhuna baktığınızda Teknoloji Geliştirme Bölgeleri (Teknokentler); üniversite-sanayi iş birliğini sağlamak, katma değeri yüksek ileri teknoloji üretmek, patentler geliştirmek ve ülkenin cari açığını kapatacak küresel ürünler ortaya koymak için kurulmuştur. Devlet bu amaçla şirketlere muazzam vergi avantajları tanır.

Peki pratikte ne olur?

Bir yazılım ajansı düşünün. Şirketin ana geliri; yerel müşterilere WordPress teması giydirmek, e-ticaret sitelerinin sepet entegrasyonunu yapmak veya şirket içi basit form arayüzleri kodlamaktır. Ortada ne yeni bir algoritma vardır, ne bir veri bilimi modeli, ne de donanım optimizasyonu.

Fakat şirket yönetimi teknokente girebilmek ve milyonlarca liralık vergi avantajından faydalanabilmek için bir "Ar-Ge Projesi" yazar:

Projenin adı: "Derin Öğrenme Tabanlı, Çok Kanallı ve Özelleştirilmiş Sepet Tahmin Algoritması ile Yeni Nesil Bilişsel E-Ticaret Karar Destek Platformu."

Metnin içi; üniversiteden formalite gereği danışmanlık ücreti ödenen bir akademisyenin desteğiyle akademik terimlerle, yapay zeka buzzword'leriyle ve süslü akış diyagramlarıyla doldurulur. Hakem heyeti onaylar. Şirket teknokente taşınır.

Ve o günden sonra ne olur?

Ofisteki yazılımcılar yine sabah akşam aynı PHP ve JavaScript kodunu yazar, aynı e-ticaret sepet bug'larını çözerler. Ama ay sonunda hazırlanan resmi raporda o yazılımcının yazdığı kod; "Yapay zeka tensör optimizasyonu" olarak gösterilir! Devletin Ar-Ge yapsın diye affettiği vergiler, patronun lüks şirket arabasının yakıtına ve şirket karlılığına dönüşür.

Bürokrasinin Boğduğu Yazılımcı: Parmak İzi Tiyatrosu

Bu tiyatronun ceremesini çeken ise yine mühendisler olur.

Dünyanın en modern teknoloji devleri; çalışanlarının verimliliğini ofiste geçirdikleri saatle değil, ürettikleri değerle ve çıktıyla ölçerken; Türkiye'deki teknokent yazılımcısı, devletin müfettişlerine "buradaydım" kanıtı sunabilmek için bir fabrika işçisi gibi mesai kartı basmaya zorlanır.

Haftalık çalışma sürenizin %80'ini (veya yasanın o dönemki kotasını) o teknokent binasının sınırları içinde geçirmezseniz, şirketiniz o ayki vergi indirimini kaybeder. Bu yüzden hastalandığınızda bile ofise gelmek, serumu kolunuza takıp teknokent masasında oturmak zorunda kalırsınız.

Uzaktan çalışmanın (remote work) tüm dünyada standart haline geldiği, en büyük mimarilerin bulut üzerinden koordine edildiği bir çağda; yazılımcıyı fiziksel bir binaya hapsetmek, dijital çağda taş devri mantığıyla mühendislik yönetmeye çalışmaktır.

Teşvik Bağımlılığı ve Sahte İnovasyon

Bu sistemin en yıkıcı sonucu, şirketlerde yarattığı teşvik bağımlılığı ve tembelliktir.

Bir şirket gerçek bir inovasyon yapmadan, sadece vergi muafiyetleri ve hibe destekleriyle bilançosunu karda gösteriyorsa; o şirketin küresel pazarda rekabet edebilecek bir ürün çıkarma kasları zamanla körelir. Tıpkı hormonla şişirilen bir kasın gerçek bir yük altına girdiğinde anında yırtılması gibi.

Yarın teknokent teşvikleri kaldırılsa veya vergi avantajları sıfırlansa; teknokentlerdeki yüzlerce şirketin üç ay içinde iflas edeceği bir sır değildir. Çünkü onların iş modeli teknoloji üretmek değil, vergi arbitrajı yapmaktır.

Gerçek Ar-Ge Cam Binalarda Değil, Özgür Zihinlerde Doğar

Biz inovasyonu teknokent binalarının cam cephelerinde, turnike sistemlerinde veya kağıt üzerindeki süslü raporlarda aradığımız sürece; bu ülkeden ne bir işletim sistemi çekirdeği çıkar, ne küresel bir veritabanı motoru, ne de dünyayı sarsacak bir teknoloji standardı.

Gerçek Ar-Ge; mühendisin saat kaçta kart bastığını sayan muhasebeci zihniyetinin bittiği yerde başlar.

Gerçek bilim ve teknoloji; insanların hata yapmaktan korkmadığı, teşvik dosyası doldurmak yerine kodun ve matematiğin sınırlarını zorladığı, özgür, bağımsız ve liyakatli ortamlarda filizlenir.

Teknokent tiyatrosunun perdelerini kapatıp hakikatle yüzleşmediğimiz sürece; kendimizi sadece vergi muafiyeti raporlarıyla kandırmaya devam ederiz. Ve dünya teknoloji tarihi bizi ürettiğimiz inovasyonlarla değil, yazdığımız sahte Ar-Ge masallarıyla hatırlar.

Aylarca gecenizi gündüzünüze katarsınız. İnsanların hayatını kolaylaştıracak harika bir bütçe takip uygulaması, bir alışkanlık takipçisi veya dil öğrenme aracı kodlarsınız. Arayüz pırıl pırıldır, backend kusursuz çalışmaktadır. Sunucu masraflarını karşılamak ve emeğinizin karşılığını almak için uygulamaya son derece mütevazı bir fiyat etiketi koyarsınız:

"Aylık sadece 39 TL." (Yani yaklaşık 1 Dolar.)

Sonra ne olur?

Uygulamanın App Store veya Google Play yorumlarındaki puanı anında 1.2 yıldıza çakılır. Yorumlar öfke doludur:

• "Başta ücretsiz sandım, kayıt olduktan sonra para istedi, dolandırıcılar!"
• "Altı üstü iki grafik çizen bir programa ayda 40 lira mı vereceğiz? Harap olsun emeğiniz!"
• "Arkadaşlar indirmeyin, paralıymış. Bunun bedava APK'sını veya crack'ini nereden bulabiliriz?"

Aynı kullanıcının Instagram profiline baktığınızda; o günün öğleden sonrasında popüler bir kahve zincirinde tek bir fincan buzlu karamelli latte'ye 160 TL ödeyip fotoğrafını paylaştığını görürsünüz.

Yirmi dakikada içilip idrar olarak atılacak şekerli bir suya 160 TL vermeyi "doğal bir yaşam tarzı" sayan zihniyet; her gün cebinde taşıdığı, hayatını düzene sokan ve arkasında binlerce saatlik mühendislik emeği yatan bir yazılıma ayda 39 TL ödemeyi "katıksız bir soygun" olarak algılamaktadır.

Koruyucu Sağlığa Sıfır Lira, Yoğun Bakıma Milyonlar

Bu tüketici davranışının sağlık sektöründeki karşılığı son derece tanıdıktır: Koruyucu hekimliğe duyulan derin direnç.

Toplumumuzun sağlık algısına bakın. İnsanlara "Yılda bir kez check-up yaptırın, düzenli kan tahlili verin, tansiyonunuzu ölçtürün, yürüyüş yapın ve sağlıklı beslenin" dediğinizde bunu bir külfet, gereksiz bir masraf ve "hastalık aramak" olarak görürler. Ayda bir kutu vitamine veya düzenli bir hekim kontrolüne 200 lira ayırmayan insan; "Ben taş gibiyim, doktora gidip de ne yapacağım?" diyerek övünür.

Peki sonra ne olur?

O insan 50 yaşına geldiğinde bir gece ansızın tıkayıcı bir miyokard enfarktüsü (kalp krizi) geçirir. Ambulansla acil servise kaldırılır, acil anjiyoya alınır, stent takılır, günlerce yoğun bakımda kalır. Ve hastane çıkışında özel hastanenin veznesine tek bir itiraz dahi etmeden, evini arabasını satarak yüz binlerce lira bayılır.

Çünkü toplumumuz; fiziksel olmayan, anlık bir acıyı dindirmeyen ve önleyici nitelik taşıyan hiçbir değere para ödemek istemez.

İlaç eline somut bir kutu olarak veriliyorsa parasını öder; ama hekimin verdiği hayat kurtarıcı bir tavsiyeye (anamnez ve muayene emeğine) para vermek ona batar. Yazılımda da durum aynıdır: Elinde tutabildiği fiziksel bir donanıma (örneğin akıllı telefona) 50 bin TL ödemekten çekinmeyen tüketici; o donanımın içindeki ruh olan yazılıma para ödemeyi "havaya para saçmak" olarak görür.

LTV ve CAC Kıskacında Boğulan Girişimler

Bu acımasız kültürel gerçeklik, Türkiye pazarında B2C ürün geliştiren girişimlerin matematiksel olarak iflas etmesine neden olur.

Yazılım ekonomisinin iki kutsal metriği vardır:

1. CAC (Customer Acquisition Cost): Bir müşteriyi kazanmak için harcadığınız pazarlama maliyeti.
2. LTV (Lifetime Value): O müşterinin hayatı boyunca size bıraktığı toplam gelir.

Bir SaaS veya mobil uygulamanın hayatta kalabilmesi için LTV'nin CAC'den en az 3 kat büyük olması gerekir.

Türkiye'de Meta veya Google reklamlarıyla tek bir yerli kullanıcıyı uygulamanıza çekmenin (CAC) maliyeti, artan dijital reklam rekabeti yüzünden 20-30 TL'yi bulur. Ancak içeriye çektiğiniz o kullanıcının uygulamada kalma ve ücretli aboneliğe geçme oranı %0.5'tir! İlk aydan sonra aboneliğini iptal etme (churn) oranı ise %90'ın üzerindedir.

Yani tek bir abone kazanmak için 500 TL harcarsınız; kazandığınız müşteri size toplamda 39 TL bırakıp ilk ayın sonunda kaçar. Bu matematik, hiçbir girişimin ayakta kalamayacağı bir finansal intihar denklemidir.

İşte bu yüzden, Türkiye'de kurulan ve yerel B2C pazarına hitap eden yüzlerce harika mobil uygulama projesi; tohum yatırımları bittiğinde arkalarında devasa bir mezarlık bırakarak sessiz sedasız yok olmuştur.

Zorunlu Dönüş: B2B'ye Kaçış veya Global Çıkış

Bu mezarlıktan sağ çıkmayı başaran girişimciler ise çok geçmeden şu iki yoldan birini seçmek zorunda kalır:

1. B2B'ye (Şirketlere Satışa) Dönmek: Son kullanıcıya ayda 39 TL'ye uygulama satmaya çalışmaktan yorulan kurucu; rotayı kurumsal şirketlere çevirir. Aynı yazılımın arkasına bir yönetici paneli ekler, adına "Kurumsal Verimlilik Platformu" der ve gidip bir holdinge yıllık 300 bin TL'lik lisans satar. Çünkü şirketler için o para bir bütçe kalemidir; fatura kesilir, gider gösterilir ve süreç rasyonel ilerler.
2. İlk Günden Global Pazara Odaklanmak: Ürünün arayüzünü tamamen İngilizce'ye çevirip, hedef pazar olarak Kuzey Amerika, Avrupa veya Güneydoğu Asya'yı seçmek. Bir Amerikalı için aylık 4.99 Dolar; sabah aldığı kahvenin yarı fiyatıdır ve kredi kartını düşünmeden sisteme tanımlar. Orada ürünün kalitesi konuştuğunda, gelir akışı öngörülebilir bir şekilde büyür.

Bağımsız Geliştiricilere Tavsiye: Coğrafya Kaderinizi Belirlemesin

Eğer masanızın başında tek başınıza veya küçük bir ekiple harika bir dijital ürün geliştiriyorsanız, lütfen kendinize şu iyiliği yapın:

Ürününüzü asla ve asla sadece Türkiye yerel B2C pazarı için tasarlamayın.

Yerel pazarın kültürel kodlarını tek başınıza değiştiremezsiniz. İnsanlara dijital emeğin, fikri mülkiyetin ve kod satırlarının bir değeri olduğunu anlatmak sizin göreviniz değildir; bu bir eğitim, hukuk ve refah düzeyi meselesidir.

Kodunuzu yazarken ilk günden çoklu dil ve para birimi desteğiyle inşa edin. Ürününüzün vitrinini dünyaya açın. Sizin uykusuz gecelerinizin, mimari titizliğinizin ve zihinsel emeğinizin karşılığını takdir edecek, bir tıkla size hakkınızı ödeyecek milyonlarca küresel kullanıcı dışarıda sizi bekliyor.

Emeğinizi, dijital içeriği bedava bir kamu malı sanan sığ sularda heba etmeyin; rotanızı okyanuslara kırın.

"Never deploy on Friday!" (Asla cuma günü canlıya çıkma!)

Bu kural bir hurafe veya tembellik bahanesi değildir; olasılık teorisinin, insan fizyolojisinin ve risk yönetiminin en temel sonucudur.

Cuma akşamı mesai biterken canlıya (production) bir kod parçası göndermek; arkanızdan çıkabilecek tüm teknik arızaları, veritabanı kilitlenmelerini ve üçüncü parti servis uyumsuzluklarını, ekibin dinlenmesi gereken cumartesi ve pazar gününün kucağına bir el bombası gibi bırakmak demektir.

Ancak Türkiye'deki yazılım ekosistemine, özellikle KOBİ tipi ajanslara ve patron odaklı şirketlere adım attığınızda bu evrensel kuralın her cuma sistematik olarak katledildiğine şahit olursunuz.

Saat 17:45. Ekipler haftanın yorgunluğunu üzerlerinden atmak, masalarını toplayıp evlerine, ailelerine dönmek üzeredir.

Tam o sırada şirketin patronu veya heyecanlı proje yöneticisi odaya dalar (veya Slack'ten @channel çeker):

"Arkadaşlar çok kritik bir gelişme var! Müşteriyle az önce konuştuk, hafta sonu sosyal medyada büyük bir kampanya başlatıyorlar. Yeni ödeme modülünü ve üyelik adımlarını bu akşam canlıya almamız lazım. Zaten testleri yapmıştınız değil mi? Hemen bir deploy çıkın, 15 dakikada biter, sonra herkes evine gider."

Bu cümle; tüm bir mühendislik ekibinin hafta sonunun, akıl sağlığının ve aile huzurunun mezara gömüldüğü anın resmi ilanıdır.

Cuma Akşamı Ameliyathaneye Elektif Hasta Almak

Bu cehaletin sağlık sektöründeki karşılığını bir cerrahtan veya ameliyathane hemşiresinden dinleyin.

Hastanelerde cuma akşamı saat 18:00 olduğunda nöbet devri gerçekleşir. Gündüz görev yapan yüzlerce kişilik uzman hekim kadrosu, biyokimya laboratuvarı personeli ve idari kadro evlerine gider. Hastanede sadece acil vakalara müdahale edecek çekirdek bir nöbetçi ekip kalır.

Şimdi bir cerrahın cuma akşamı saat 18:30'da çıkıp şöyle dediğini hayal edin:

"Hadi arkadaşlar, hazır nöbete kalmışken şu hastanın 6 aydır bekleyen fıtık ve diz protezi ameliyatını aradan çıkaralım. Zaten yarım saatlik iş, hemen yaparız."

Böyle bir cerraha ameliyathanedeki anestezi uzmanından başhemşireye kadar herkes dehşetle bakar. Neden?

Çünkü elektif (acil olmayan, planlı) bir cerrahi asla hastanenin en zayıf olduğu, personelin minimum kadroya düştüğü ve acil bir komplikasyon anında konsültasyon isteyecek uzmanların bulunmadığı bir zaman diliminde yapılmaz! Ameliyat sırasında beklenmeyen bir kanama başlarsa, kan merkezinde yedek kan torbası yoksa veya anestezi cihazı arıza yaparsa o hastayı masada bırakırsınız.

Cuma akşamı yazılımda canlıya çıkmak da tam olarak budur.

Tüm ekibin yorgun olduğu, odaklanmanın dibe vurduğu, AWS destek hattının nöbetçi moda geçtiği ve dış API sağlayıcılarının müşteri temsilcilerinin evlerinde uyuduğu bir zaman diliminde; production veritabanına şema göçü (migration) fırlatmak katıksız bir kumardır.

Kabusun Anatomisi: 18:15'ten Pazar Gecesi 03:00'e

O deploy çıktığı an senaryo asla yöneticinin hayal ettiği gibi "15 dakikada" bitmez:

1. Saat 18:15: Kod merge edilir, CI/CD pipeline'ı çalışır. Test ortamında fark edilmeyen küçük bir migration hatası yüzünden production veritabanı kilitlenir (table lock).
2. Saat 18:45: API yanıt süreleri 200 ms'den 45 saniyeye fırlar. Pod'lar birer birer OOM (Out of Memory) hatası vererek çökmeye başlar.
3. Saat 19:30: Patron panik içinde arar: "Müşteri beni aradı, site açılmıyor, acil düzeltin!" Yazılımcılar montlarını çıkarıp tekrar masaya oturur. Rollback yapılmaya çalışılır; ancak veritabanı şeması geriye dönük uyumlu yazılmadığı için rollback eski kodu da patlatır!
4. Cumartesi 14:00: Ekip gözleri kan çanağı içinde log dosyalarında kaybolmuş, production verilerini kurtarmak için geçici SQL script'leri yazmaktadır. Eşler, çocuklar, arkadaşlar aramakta; "Gelemiyorum, işte kriz çıktı" yanıtını almaktadır.
5. Pazar 23:00: Sistem derme çatma bir yamayla zar zor ayağa kaldırılır. Pazartesi sabahı ofise gelindiğinde herkes sinirli, yorgun ve tükenmiştir.

Ve en acısı nedir biliyor musunuz?

Pazartesi sabahı müşterinin o "büyük hafta sonu kampanyasını" aslında başlatmadığı, pazarlama ajansının görselleri yetiştiremediği ortaya çıkar! Yani tüm o cehennem, içi boş bir müşteri kaprisi ve yöneticinin sınır koyamama acziyeti yüzünden yaşanmıştır.

Neden "Hayır" Diyemiyoruz?

Bu döngünün Türkiye'de kırılamamasının temel nedeni, profesyonel sınır çizme kültürünün yokluğudur.

Müşteriye veya patrona "Hayır, cuma akşamı deployment yapmak mühendislik prensiplerimize aykırıdır. Bu riski alamayız. Kodu pazartesi sabahı saat 10:00'da, tüm ekip masadayken ve zihnimiz berrakken canlıya alacağız" demek bir itaatsizlik değil; şirketin sermayesini ve müşterinin itibarını koruyan profesyonel bir duruştur.

Fakat liyakatsiz yöneticiler müşteriye şirin görünmek, "Biz 7/24 çalışan bir şirketiz" yalanını sürdürmek için her talebe baş eğerler. Faturayı ise cuma akşamı evine gidemeyen yazılımcıya keserler.

Deployment Bir Tören Değil, Rutin Olmalıdır

Modern DevOps kültürü, deployment'ı korkulan bir "olay" olmaktan çıkarıp, gün içinde yüzlerce kez yapılabilen sıradan bir adıma dönüştürmeyi amaçlar:

• Mavi-Yeşil (Blue-Green) dağıtımlar,
• Kanarya (Canary) sürümleri,
• Özellik bayrakları (Feature Flags),
• Otomatik sağlık kontrolleri ve anında geri alma mekanizmaları...

Eğer altyapınız bu olgunlukta değilse; yani bir deployment yaptığınızda tek bir komutla sıfır kesintiyle eski sürüme dönemiyorsanız, cuma akşamı deployment yapmak intihardır.

Eğer altyapınız bu olgunluktaysa bile; insan faktörünü unutmayın. Cuma akşamı insanın dikkati dağılır, hata yapma olasılığı katlanır. Hiçbir e-ticaret butonu, hiçbir pazarlama kampanyası sizin ve ekibinizin hafta sonu huzurundan daha acil ve değerli değildir.

Cuma 17:00'den sonra o terminaldeki git push origin master komutundan elinizi çekin. Bilgisayarınızı kapatın.

Pazartesi sabahı o kod hala orada olacak; ama kaybolan hafta sonunuzu ve yıpranan sinirlerinizi hiçbir sprint planlaması geri getiremez.

Aileniz, akrabalarınız ve komşularınız için "çalışmak" kavramının tanımı son derece nettir:
Sabah erkenden kalkılır, takım elbise veya iş kıyafeti giyilir, dolmuşa veya servise binilir, fiziksel bir binaya gidilir, orada bir patronun gözetiminde 8 saat ter dökülür ve akşam yorgun argın eve dönülür. Ter yoksa, yol çilesi yoksa, akşam eve girdiğinde "Of bugün canım çıktı" diye sızlanma yoksa; o yapılan şey toplum nezdinde "iş" sayılmaz.

Bu yüzden evinin bir odasında, üzerinde tişörtüyle, masanın başında sessizce ekrana bakan bir genci gören Türk ebeveyni veya akrabası için o an tek bir gerçeklik vardır: "Bizim çocuk evde bütün gün bilgisayarın başında boş boş oturuyor, oyun oynuyor."

İşte bu algı, Türkiye'de uzaktan çalışan yüz binlerce yazılımcının her gün verdiği en yıpratıcı, en trajikomik varoluş mücadelesinin fitilini ateşler.

Prod Krizinin Ortasında Gelen Pazar Siparişi

Öğleden sonra saat 14:15. Terminalinizde kızılca kıyamet kopmaktadır.

Şirketin Avrupa ödeme altyapısını sağlayan mikroservisinde kritik bir bellek sızıntısı patlamış; Kubernetes pod'ları saniyeler içinde çökmekte, binlerce kullanıcının ödemesi askıda kalmaktadır. Slack'te 15 kişilik uluslararası kriz ekibiyle sesli kanaldasınız. Kalbiniz dakikada 130 atıyor; parmaklarınız klavyede uçuşuyor, log dosyalarından hatanın izini sürüyorsunuz.

Tam o sırada odanızın kapısı tıklatılmadan, ardına kadar açılır. İçeriye anneniz veya bir aile büyüğünüz girer. Yüzünde son derece şefkatli ama bir o kadar da rahat bir gülümseme vardır:

"Furkan, madem evdesin, kalkıver de bir koşu pazardan iki kilo patatesle yarım kilo limon alıver. Akşama teyzenler gelecek, yemek yetiştiremedim. Hadi yavrum, bütün gün oturdun o ekranın karşısında, gözlerin bozulacak, hem sana da hava değişimi olur."

Kulaklığınızı hafifçe aralayıp fısıldarsınız: "Anne şu an çok kritik bir toplantıdayım, sistem çöktü, yerimden kalkamam."

Annenizin kaşları anında çatılır, derin bir iç çeker: "Aman siz de ne toplantısıysa... Sabahtan beri ekrana bakıp duruyorsun. İki dakika bakkala git dedik diye bin dereden su getirdin. Hayırsız evlat."

Kapı çarpılarak kapanır. Siz ekrana dönersiniz ama zihniniz darmadağın olmuştur.

Bir yandan Amerikan şirketindeki mühendise İngilizce olarak hafıza dökümünü anlatmaya çalışırken, bir yandan da annenizin gözündeki o "evde yatan hayırsız çocuk" yaftasının vicdani ezikliğiyle boğuşursunuz.

112 İstasyonunda "Oturduğunuz Yerden Para Kazanıyorsunuz" Cehaleti

Bu toplumsal algı körlüğünün acil sağlık hizmetlerindeki yansıması, 112 ambulans ekiplerinin yıllardır maruz kaldığı o haksız önyargıdır.

Bir 112 acil yardım istasyonunu dışarıdan izleyen bazı vatandaşlar şöyle der: "Oh ne güzel iş, akşama kadar istasyonun bahçesinde çay içip televizyon izliyorlar, oturdukları yerden devletten maaş alıyorlar."

Oysa o insanların bilmediği şey şudur: 112 personeli o bahçede otururken keyif yapmamaktadır; gerilmiş bir çelik yay gibi alarm durumunda beklemektedir.

Telsizden bir anons geldiği anda, 90 saniye içinde ambulansa binip, trafiğin içinde canını dişine takarak bir bebeğin solunum arrestine veya parçalanmış bir kazaya müdahale etmek üzere fırlayacaktır. O dinginliğin arkasında, her an bir ölüm-kalım savaşının içine atılmaya hazır nörolojik bir alarm hali yatar.

Evden çalışan yazılımcının durumu da tam olarak budur.

Dışarıdan bakan bir göz için siz sadece koltukta oturuyorsunuzdur; kas gücü harcamıyor, çimento taşımıyor, koli kaldırmıyorsunuzdur.

Fakat kafatasınızın içinde, arka planda devasa bir biyokimyasal ve zihinsel fırtına kopmaktadır. Beyniniz; soyut algoritmaları, karmaşık veri modellerini ve mantıksal bağımlılıkları inşa edebilmek için vücudunuzun tüm glikozunu ve oksijenini tüketmektedir. Dört saatlik kesintisiz bir kodlama ve mimari tasarım seansının insan bedeninde yarattığı yorgunluk, tarlada sekiz saat çapa yapmanın yorgunluğundan daha az değildir.

Fakat zihinsel emeğin değerinin bilinmediği bir toplumda; terlemeyen insanın yorulduğuna kimse inanmaz.

Akraba Ziyaretleri ve "Bizim Bilgisayara Bir Format Atsana"

Remote çalışan yazılımcının akraba ilişkileri ise başlı başına bir durum komedisidir.

Bir bayram ziyaretinde veya aile meclisinde teyzeler, amcalar toplanır:

• "Bizim Furkan da evden çalışıyor işte... Ne iş yaptığı da belli değil ya, internette bir şeyler kurcalıyor."
• "Yeğenim madem evdesin, bizim komşunun çocuğu internetten oyun indiremiyormuş, bir ara uğra da hallediver."
• "Bizim eski laptop açılmıyor, sen bilgisayarcısın ya, içine bir format atıver sana zahmet."

Siz dünyanın en büyük finansal teknolojilerinde dağıtık sistemler mimarisi kurduğunuzu, saniyede 100 bin işlemi işleyen motorlar yazdığınızı anlatmaya çalışırsınız; ama karşı taraf için siz hala **"bozuk yazıcıları tamir eden ve format atan yeğen"**sinizdir.

Çünkü onların dünyasında bilgisayarla yapılan işlerin tek bir kategorisi vardır: Teknik servisçilik.

Sınır Çizmek: Hayatta Kalma Kılavuzu

Eğer evden çalışıyorsanız ve akıl sağlığınızı, kariyerinizi ve aile ilişkilerinizi korumak istiyorsanız; radikal sınırlar çizmek zorundasınız:

1. Fiziksel Bir Çalışma Alanı Kurun: Yatakta veya salondaki yemek masasında çalışmayı bırakın. Kendinize ait bir oda oluşturun ve o odanın kapısını mesai saatlerinde kapatın. O kapı kapalıyken, evin içindekiler sizin başka bir şehirde olduğunuzu kabul etmek zorundadır.
2. Kılık Kıyafet Ritüeli: Pijamayla kod yazmak hem zihninizi rehavete sokar hem de evdekilerin sizi "dinleniyor" sanmasına yol açar. Sabah kalkın, duşunuzu alın, iş kıyafetinizi giyin ve masanıza öyle oturun.
3. "Hayır" Demeyi Öğrenin: Mesai saatinin ortasında gelen hiçbir bakkal siparişini, hiçbir akraba çayını kabul etmeyin. "Ben şu an işteyim, saat 18:00'den önce hiçbir yere kımıldayamam" cümlesini gerekirse yüz kez tekrar edin. Başta alınacaklar, kırılacaklardır; ama zamanla sınırlarınıza saygı duymayı öğreneceklerdir.

Unutmayın; sizin işiniz bir hobi, bir vakit geçirme aracı veya canınız sıkıldıkça başına oturduğunuz bir oyuncak değildir.

Siz dünyanın en karmaşık zanaatlarından birini icra ediyorsunuz. Ve sizin zihinsel emeğinize önce siz saygı duyup sınırlarınızı korumazsanız; hiç kimse o sınırlara saygı göstermeyecektir.

Ancak Türkiye'deki KOBİ dünyasında, ajans sektöründe veya sermayedar güdümlü yerel projelerde işler bambaşka bir platform üzerinden yürütülür:

"YAZILIM - REVİZYONLAR (ACİL) 🚀" isimli bir WhatsApp grubu.

Grupta kimler vardır? Şirketin patronu, müşterinin yeğeni, pazarlama sorumlusu, bir grafiker ve tüm bu karmaşanın ortasında hayatta kalmaya çalışan tek bir yazılımcı.

Ve bu grup, modern yazılım mühendisliğinin tüm kurallarının, mesleki disiplininin ve insan onurunun sistematik olarak çiğnendiği bir dijital kargaşa arenasına dönüşür.

Gece 01:30'da Gelen 4 Dakikalık Ses Kaydı

Cumartesi gecesi saat 01:30. Yatağınızda tam uykuya dalmak üzeresinizdir. Komodinin üzerindeki telefonunuz iki kez titrer. Ekran ışığı karanlığı böler. WhatsApp bildiriminde müşterinin adı görünmektedir:

🎙️ Sesli Mesaj (03:48)

Gözlerinizi ovarak kulaklığı takarsınız. Arka planda mekan müzikleri veya araba motoru sesi gelen bir ses kaydı başlar:

"Furkan hocam iyi geceler, kusura bakma bu saatte rahatsız ediyorum ama aklıma süper bir fikir geldi. Bizim e-ticaret sitesine şimdi müşteri giriyor ya, sepete tıkladığında bir çarkıfelek çıksın, müşteri çarkı çevirince indirim kazansın. Bir de oraya SMS doğrulaması koyalım, ama doğrulama kodu gelmezse direkt geçsin. Bunu yarın öğlene kadar hallediver de pazartesi sabahı reklam çıkacağız. Hadi kolay gelsin."

Mesaj biter. Arkasından iki saniye sonra bir fotoğraf düşer: Bir peçetenin üzerine tükenmez kalemle çizilmiş eğri büğrü bir daire ve telefonun ekran görüntüsü üzerine parmakla karalanmış kırmızı bir ok işareti.

Bu mesaj; ne bir gereksinim analizidir, ne bir kullanıcı hikayesidir (user story), ne de bir teknik şartnamedir. Bu; sınır bilmezliğin, plansızlığın ve yazılımı sihirbazlık sanan bir cehaletin saf dışavurumudur.

Yoğun Bakımı WhatsApp Ses Kayıtlarıyla Yönetmek

Bu dehşetin sağlık sektöründeki karşılığını bir an için düşünün.

Bir yoğun bakım kliniğinde yatan entübe bir hastanın tüm tedavi planının, ilaç dozajlarının ve hayati kararlarının resmi hasta dosyasına (epikrize) işlenmek yerine; asistanların, başhemşirenin ve klinik şefinin yer aldığı bir WhatsApp grubundan yürütüldüğünü hayal edin:

• Şef gece kulübünden ses kaydı atıyor: "Hastalardan 3 numaraya biraz noradrenalin başlayın, tansiyonu yükselsin."
• Başhemşire gruptan yazıyor: "Hocam dozu kaç cc yapalım?"
• Şef 4 saat sonra cevap veriyor: "Göz kararı verin işte, idare etsin."

İki gün sonra o hasta çoklu organ yetmezliğinden veya aşırı dozdan hayatını kaybettiğinde ne olur? Savcılık hastaneye baskın yapar.

Sorumlu hekim savcıya gidip "Biz WhatsApp grubunda konuşmuştuk, hoca ses kaydı atmıştı ama o mesaj kayboldu" diyebilir mi? Bunu söylediği an kendisini doğrudan cezaevinde bulur ve meslekten men edilir. Çünkü tıpta yazılı olmayan, resmi protokole ve imzaya bağlanmayan hiçbir talimat yok hükmündedir.

Yazılımda da böyledir. Bir projenin kapsamını, veritabanı mantığını ve güvenlik protokollerini WhatsApp mesajlarıyla belirlemeye kalktığınızda ortaya çıkacak tek şey katıksız bir felakettir.

WhatsApp Yönetiminin Yarattığı Dört Ölümcül Hasar

Bir yazılım projesini anlık mesajlaşma gruplarıyla yönetmek şu yapısal çöküşleri kaçınılmaz kılar:

1. Kayıt Dışı Kapsam Büyümesi (Scope Creep): Sözleşmede yer almayan onlarca özellik, gruptan "Şunu da aradan çıkarıver" denilerek yazılımcının sırtına yüklenir. Ne ek bütçe ödenir, ne de teslim süresi uzatılır.
2. Dokümantasyonun Sıfırlanması: Altı ay sonra bir bug çıktığında; o fonksiyonun neden öyle yazıldığını, kuralın kim tarafından istendiğini aramak için yüzlerce megabaytlık WhatsApp sohbet geçmişini taramak zorunda kalırsınız.
3. Güvenlik İhlalleri: Production sunucu şifreleri, AWS access key'leri, ödeme sağlayıcılarının gizli anahtarları o gruplarda uluorta paylaşılır. Üç ay sonra şirketten ayrılan bir stajyer veya grafik tasarımcı, o grupta kaldığı sürece tüm sisteminizin anahtarlarına sahip olmaya devam eder.
4. Zihinsel Tükenmişlik ve 7/24 Nöbet Psikolojisi: WhatsApp kişisel bir alandır. Arkadaşlarınızla, ailenizle konuştuğunuz yerde patronun ve müşterinin sürekli bildirim patlatması; yazılımcıda beynin asla dinlenemediği kronik bir alarm durumu yaratır.

Profesyonel Barikatı Kurmak

Bu kaostan kurtulmanın tek bir yolu vardır: Kişisel alanınızı ve mühendislik disiplininizi tavizsiz bir şekilde korumak.

Bir müşteriyle veya şirketle çalışmaya başladığınız ilk gün kuralınızı masaya net bir şekilde koymalısınız:

• "Bizim iletişim kanalımız WhatsApp değildir. Şirket içi iletişim için Slack/Discord, proje ve görev yönetimi için Jira/Linear, tasarım onayları için Figma kullanıyoruz."
• "WhatsApp'tan iletilen hiçbir talep, hiçbir revizyon ve hiçbir ses kaydı iş listesine alınmaz ve yapılmaz."
• "Saat 18:00'den sonra acil sunucu çöküşü (P0 outage) dışında hiçbir mesaja bakılmaz."

Müşteri veya patron başta buna direnecektir: "Yahu biz samimi insanlarız, ne gerek var öyle resmiyetlere, WhatsApp'tan yazıveriyoruz işte!"

Onlara şu gerçeği hatırlatın: Samimiyet arkadaşlıkta olur; mühendislikte ise disiplin, netlik ve yazılı protokoller esastır.

Kendinizi gece yarıları gelen o peçete çizimlerinden, 4 dakikalık ses kayıtlarından ve plansızlık teröründen koruyun. Çünkü WhatsApp'tan yönetilen bir projeden ne kaliteli bir yazılım çıkar, ne de o projeyi yapan insanda sağlam bir akıl sağlığı kalır.

Ekranında açık olan sekmelerde; şirketin yıllık milyonlarca liralık cirosunu döndüren e-ticaret veritabanları, yüz binlerce kullanıcının kişisel verilerini barındıran Kubernetes cluster'ları ve hassas finansal API entegrasyonları çalışmaktadır.

Ancak o ekranın bağlı olduğu fiziksel kasaya baktığınızda gözlerinize inanamazsınız:

Menteşesi kırıldığı için arkasına bir sözlük dayatılmış, bazı klavye tuşlarının üzerindeki harfler silindiği için tükenmez kalemle yazılmış, fişten çekildiği anda pili 8 dakika içinde sıfırlanan ve fanı çalışmaya başladığında ofiste helikopter kalkıyormuş hissi veren 7 yıllık bir ofis bilgisayarı.

Bilgisayarda 8 GB RAM vardır. Mühendis aynı anda VS Code'u, Docker'ı ve Chrome'da sekiz sekmeyi açtığı anda işletim sistemi kilitlenir; fare imleci ekranda saniyeler sonra hareket etmeye başlar. Her yerel derleme (build) işlemi 12 dakika sürer. Mühendis kahvesini alır, camdan dışarı bakar ve bilgisayarın donmasının geçmesini bekler.

Ve en acısı nedir biliyor musunuz?

O mühendis, şirket yönetimine gidip "Bana işimi yapabilmem için 32 GB RAM'li modern bir iş istasyonu ve ikinci bir harici monitör alabilir misiniz?" demeye utanır, çekinir veya dese bile kapıdan şu klasik patron cevabıyla kovulur:

"Yahu bizim evdeki çocuk da bilgisayar kullanıyor, 10 yıllık makine tıkır tıkır çalışıyor. Siz de her şeye masraf çıkarıyorsunuz, altı üstü yazı yazıyorsunuz, neyine yetmiyor bu bilgisayar?"

Oysa o patron, aynı akşam müşterisiyle çıktığı lüks bir restoranda tek bir akşam yemeği için o talep edilen bilgisayarın bedelini şirket kredi kartıyla tek çekimde ödeyecektir.

Cerrahın Eline Körelmiş Bistüri Vermek

Bu trajedinin ameliyathanedeki karşılığı düşünülemez bile.

Bir hastanenin başhekiminin, açık kalp ameliyatına veya beyin cerrahisine girecek olan uzman cerrahın eline ucu körelmiş, paslanmış bir bistüri verdiğini; anestezi teknisyenine pili tutmayan bir defibrilatör uzatıp "İdare edin işte, yeni alete bütçemiz yok" dediğini hayal edin.

Böyle bir ameliyathanede ne olur? Cerrah dokuyu keserken damarı parçalar, defibrilatör şok vermediği için hasta masada kalır.

Çünkü tıp tarihinde hiç kimse cerrahın dehasıyla aletinin kalitesini birbirinden ayıramaz. En yetenekli cerrah bile, kullandığı optik mikroskobun çözünürlüğü ve tuttuğu klemplerin hassasiyeti kadar başarılı olabilir. Aletine yatırım yapılmayan bir hekimden kusursuz bir cerrahi beklemek cinayete davetiye çıkarmaktır.

Yazılım mühendisliği de dijital bir cerrahidir. Bizim ameliyathanemiz o ekran; bistürimiz ve mikroskobumuz ise o bilgisayarın işlemcisi, belleği ve ekran kartıdır.

Docker container'larını ayağa kaldıramayan, IDE'nin kod tamamlama motorunu (IntelliSense) çalıştırırken kasan bir donanımla üretim ortamını (production) yönetmek; körelmiş bıçakla damar dikmeye çalışmak kadar tehlikeli ve saçmadır.

Vizyonsuz Muhasebe: Kaybedilen Zamanın Matematiği

Şirket yönetimlerinin anlamadığı (veya anlamak istemediği) en büyük matematiksel gerçek, mühendislik zamanının maliyetidir.

Basit bir hesap yapalım:

• Bir yazılımcının yetersiz donanım yüzünden (yavaş derleme, çöken servisler, donan IDE, yeniden başlatmalar) günde kaybettiği net süre: en az 45 dakika.
• Ayda 22 iş gününde kaybedilen süre: 16.5 saat.
• Yılda kaybedilen süre: yaklaşık 200 saat.

200 saat, tam bir aylık çalışma mesaisine eşittir!

Yani şirket; bir defaya mahsus 2.000 Dolar verip mühendisine güçlü bir makine almaktan kaçındığı için, her yıl o mühendisin bir aylık maaşını bilgisayarın donmasını izlemesi için çöpe atmaktadır!

Bu, tarihin en ilkel, en vizyonsuz bakkal muhasebesidir. Donanımdan tasarruf ettiğini sanan şirket, aslında her gün onlarca saatlik yüksek nitelikli zihinsel emeği heba etmektedir.

Dahası; o donmaların ve yavaşlıkların mühendisin zihninde yarattığı bilişsel sürtünme (cognitive friction), odaklanma kaybı ve sinir harbi parayla dahi ölçülemez. Zihni bölünmüş bir mühendisin yazdığı kodda hata çıkar; ve production'da çıkacak tek bir kritik kesintinin şirkete maliyeti, ofise 50 tane en tepe model bilgisayar almaya yetecek kadardır.

Zanaatkarın Aletine Saygısı

Kadim zanaat kültürümüzde bir kural vardır: Bir ustanın mesleki haysiyeti, sandığındaki aletlerinin intizamıyla ölçülür.

İyi bir marangoz rendesine gözü gibi bakar; bıçağını her gün biler. İyi bir terzi makasını kimseye elletmez. Çünkü bilirler ki alet, kolun ve zihnin bir uzantısıdır. Alet körelirse, zanaat ölür.

Yazılımcılar olarak bizler de bu ezikliği üzerimizden atmak zorundayız.

İşinizi layıkıyla yapabilmek için güçlü bir donanım, ergonomik bir çalışma koltuğu, yüksek çözünürlüklü geniş bir monitör talep etmek bir "şımarıklık" veya "lüks isteği" değildir. Bu; yaptığınız işe, şirketinize ve mesleki haysiyetinize duyduğunuz saygının en temel asgari gereğidir.

Patronlara ve Şirketlere Son Çağrı

Eğer bir yazılım şirketiniz varsa ve mühendisleriniz hala fanı bağıran hurda makinelerle cebelleşiyorsa; o ofisteki langırt masasını, ücretsiz kahve makinelerini ve süslü duvar yazılarını çöpe atın.

Mühendisinize hak ettiği donanımı verin.

Ekranın başına geçtiğinde teknolojinin hızına yetişebilen, fikrini koda dökerken donup kalmayan, onun zihnine ayak uydurabilen aletler sunun. Çünkü donanımına yatırım yapmaktan aciz bir şirketin; ne küresel pazarda rekabet etmeye hakkı vardır, ne de geleceğe dair bir vizyon kurmaya gücü.

Unutmayın: Büyük mimariler, dökülen kasaların üzerinde değil; zanaatına ve aletine saygı duyan berrak zihinlerin üzerinde yükselir.

Şirketin kıdemli backend mühendisi veya yazılım mimarı, son altı aydır her teknik toplantıda aynı hayati sorunu dile getirmektedir:
"Monolitik veritabanımız darboğaza girdi. Connection pool tükeniyor, thread contention yüzünden API yanıt sürelerimiz 4 saniyenin üzerine çıkıyor. Cache katmanımızı Redis Cluster ile izole etmeli, transactional veritabanındaki ağır raporlama sorgularını read-replica'lara ayırmalıyız."

Mühendis bu tespitle kalmaz; mimari akış diyagramlarını çizer, yük testi (load testing) raporlarını hazırlar, hatta hafta sonu kendi vaktiyle ufak bir proof-of-concept (PoC) geliştirip yönetimin önüne koyar.

Peki şirketin C-seviye yöneticileri veya direktörleri ne yapar?

Mühendisin yüzüne hafif bir küçümsemeyle bakarlar. "Furkan'cım (veya Ahmet'cim), bizim sistemimiz çok özel. Sen olayı biraz büyütüyorsun gibi geliyor bize. Şimdilik sunucunun RAM'ini biraz artıralım, bakarız." derler. Konu kapatılır, raporlar çekmecelere kaldırılır.

Aradan dört ay geçer. Sistem bir kampanya gününde çöker. Şirket yüz binlerce liralık ciro kaybeder. Yönetim panikler ve "küresel vizyon" gereği Londra veya Frankfurt merkezli ünlü bir yönetim ve teknoloji danışmanlık firmasını (veya yerel bir "büyük dörtlü" danışmanlık şirketini) devreye sokar.

Şirkete günlük ücreti 3.000 Euro olan takım elbiseli üç genç danışman gelir. İki hafta boyunca şirkette toplantılar yaparlar, mühendislerle konuşurlar, kahvelerini yudumlarlar.

Ve üçüncü haftanın sonunda yönetim kuruluna 60 sayfalık, pastel tonlarla bezenmiş, büyüleyici bir sunum dosyası sunarlar:

"Executive Summary: Database Bottleneck & Architectural Modernization Roadmap."

Slaytın ana önerisine bakarsınız: "Transactional veritabanındaki yükü azaltmak için read-replica mimarisine geçilmeli ve oturum/önbellek yönetimi izole bir Redis Cluster üzerine taşınmalıdır."

Yönetim kurulu ayağa fırlar, gözleri yaşarmışçasına alkışlar: "İşte vizyon! İşte stratejik akıl! Adamlar tam bir dünya devi, sorunun kök nedenini tek raporda çözdüler!"

Danışmanlık şirketine yüz binlerce Euro fatura ödenir. Masanın köşesinde oturan ve aynı şeyi dört aydır yalvarırcasına anlatan yerli mühendis ise, hissettiği mesleki hakaret ve yabancılaşmayla sadece çayını yudumlar.

Tıptaki "Dışarıdan Hoca Çağırma" Fiyaskosu

Bu tablonun acil servisteki ve klinik tıp dünyasındaki karşılığı tam bir trajikomedidir.

Yoğun bakımda veya acil serviste günlerdir nöbet tutan kıdemli bir asistan hekim ve servis başhemşiresi düşünün. Yatan hastanın başında 24 saat nefes almaktadırlar. Asistan hekim vizitte hocaya veya başhekime şöyle der:

"Hocam, bu hastanın laboratuvar değerlerinde prokalsitonin yükseliyor, idrar çıkışı azaldı ve periferik dolaşımı bozuluyor. Başladığımız antibiyotiğe direnç gelişti; hastayı sepsis kliniğine sokuyoruz. Derhal geniş spektrumlu karbapenem grubuna geçmeli ve santral venöz kateter açarak sıvı resüsitasyonunu artırmalıyız."

Başhekim asistanı dinlemez: "Sen daha kıdemsizsin, kitaplardaki her şeyi ezbere uygulama. Mevcut tedaviye devam edin."

İki gün sonra hasta septik şoka girer. Hasta yakınları hastaneyi ayağa kaldırır. Başhekimlik panikle şehir dışındaki ünlü bir özel üniversiteden "konsültan profesör" çağırır. Profesör gelir, hastanın başında iki dakika stetoskop dinler, tahlil kağıdına 30 saniye bakar ve reçeteye yazar: "Karbapenem başlansın, santral hat açılsın."

Başhekim profesörün elini iki eliyle sıkar: "Hocam ayağınıza sağlık, hastanın hayatını kurtardınız!"

Oysa o hayatı iki gün önce kurtaracak olan bilgi, zaten o servisteki asistanın beynindeydi. Faturayı ise iki gün boyunca acı çeken hasta ve aşağılanan asistan ödemiştir.

Neden Kendi İnsanımıza Güvenmiyoruz?

Bu kurumsal hastalığın kökeninde derin bir aşağılık kompleksi ve yerel liyakatsizlik yatar.

1. Yabancı Hayranlığı ve Etiket Fetişizmi: Türkiye'deki pek çok karar verici için bilginin değeri, bilginin doğruluğunda değil; bilginin kim tarafından ve hangi aksanla sunulduğundadır. Kendi bordrosunda 60 bin TL'ye çalışan mühendisin sözü "bedava" olduğu için değersizdir. Ancak dışarıdan gelen bir danışmana saatliği 500 Dolar ödendiğinde, ödenen para bilginin değerine dair sahte bir garanti üretir.
2. Sorumluluktan Kaçma Refleksi (Cover Your Ass - CYA): Yöneticinin içerideki mühendisi dinlememesinin en büyük sebebi korkudur. Eğer içerideki mühendisin dediğini yapıp başarısız olurlarsa, fatura yöneticiye kesilir: "Neden tecrübesiz bir personelin aklıyla iş yaptın?" Ama dünyaca ünlü bir danışmanlık firmasının raporunu uygulayıp batarlarsa, yönetici arkasına yaslanıp kendini savunabilir: "Biz dünyanın en büyük danışmanlık şirketiyle çalıştık, onların önerisiydi, bizim bir suçumuz yok."
3. Pahalı Slayt Büyücülüğü: Danışmanlık firmalarının uzmanlaştığı yegane alan mühendislik değil, algı yönetimidir. Mühendisin basit bir terminal ekranında veya beyaz tahtada gösterdiği yalın gerçeği; onlar grafiklerle, renk geçişleriyle ve havalı yönetim buzzword'leriyle paketleyip satarlar.

Sessiz İstifaların ve Beyin Göçünün Gizli Nedeni

Bir mühendis için maaşının düşüklüğü katlanılabilir bir zorluk olabilir; ancak fikrinin, emeğinin ve mesleki uzmanlığının yok sayılması katlanılamaz bir hakarettir.

Şirket içindeki mühendis bakar ki; gecesini gündüzüne katarak geliştirdiği çözümler dinlenmiyor ama aynı fikir dışarıdan bir yabancı tarafından söylendiğinde alkışlanıyor. O günden sonra o mühendisten artık inovasyon bekleyemezsiniz.

O mühendis "sessiz istifa" (quiet quitting) moduna geçer. Sadece verilen biletleri kapatır, hiçbir mimari tartışmaya girmez, hiçbir krizde inisiyatif almaz. Ve ilk fırsatta, kendi aklına ve yeteneğine saygı duyan küresel bir şirkete veya yurt dışındaki bir pozisyona geçerek bavulunu toplar.

Şirketler sonra toplantılarda dert yanar: "Bizim ekibin aidiyet duygusu yok, vizyoner mühendis bulamıyoruz."

Siz kendi mühendisinizi danışmanların stajyeri yerine koydunuz. Onun aklını dinlemek yerine dışarıya servet akıttınız. Ve şimdi aidiyet mi bekliyorsunuz?

Akıl Şirketin İçindedir

Gerçek liderlik, dışarıdan mucizevi reçeteler satın almak değil; kendi ekibinin içindeki saklı aklı, sahadan gelen fısıltıları dinleyebilme olgunluğudur.

Hiçbir dış danışman, sizin sisteminizi gecenin ikisinde nöbet tutan, o kodun her satırında parmak izi olan kendi mühendisinizden daha iyi tanıyamaz. Danışman gider, slaytları kalır; ama o sistem çöktüğünde sabaha kadar başında bekleyecek olan yine sizin hor gördüğünüz o yerel ekibinizdir.

Kendi mühendisine güvenmeyen bir yönetim; dışarıdan gelen süslü yalanlara servet ödemeye, kendi değerlerini ise başka ülkelere hediye etmeye mahkumdur.

Henüz üniversiteden mezun olalı iki yıl olmuş gençlerin profillerinde şu unvanlar parıldamaktadır:

• "VP of Software Engineering & Chief AI Officer"
• "Lead Enterprise Solutions & Cloud Infrastructure Architect"
• "Principal Distributed Systems Strategist & Head of Innovation"

Bu unvanların altındaki şirket bilgilerine yakından baktığınızda ise karşılaştığınız gerçeklik şudur: Kadıköy'de veya Şişli'de bir paylaşımlı ofiste masası olan, toplamda 4 kişinin çalıştığı, ana gelir kalemi yerel mobilyacılara veya restoranlara kurumsal web sitesi tasarlamak ya da hazır bir Shopify temasını Türkçeleştirmek olan butik bir yazılım ajansı.

Şirkette toplam iki yazılımcı vardır; biri "VP of Engineering", diğeri ise "Lead Solutions Architect"tir.

Kartvizitlerdeki İngilizce kelime sayısı, şirketin yazdığı özgün kod satırı sayısından fazladır.

Modern Türkiye teknoloji ekosisteminin en trajikomik hastalığına hoş geldiniz: Unvan enflasyonu.

Emeğin, bilginin ve gerçek mühendislik disiplininin yerini; LinkedIn algoritmalarını ve eşi dostu etkilemek için uydurulmuş havalı unvan tiyatrosu almıştır.

Sağlık Ocağında "Baş Cerrah" Kartviziti

Bu çılgınlığın sağlık sektöründeki bir yansımasını hayal edin.

Mahallenizdeki aile sağlığı merkezine (sağlık ocağına) gidiyorsunuz. Kapıda tansiyon ölçen, aşı kartlarını sisteme giren veya kan tüplerini ayıran genç bir sağlık personeli oturuyor. Masasının üzerinde kocaman altın yaldızlı bir isimlik duruyor:

"Executive Director of Global Cardiovascular Interventions & Chief Molecular Neurosurgeon" (Küresel Kalp-Damar Girişimleri İcra Direktörü ve Baş Moleküler Beyin Cerrahı).

O personele dönüp "Kardeşim sen ne yapıyorsun?" deseniz, muhtemelen "Hocam unvanımız havalı olsun, piyasada itibarımız artsın" diyecektir.

Böyle bir sahneye tıp camiasında sadece kahkahalarla gülünmez; Türk Tabipleri Birliği ve Sağlık Bakanlığı o şahıs hakkında derhal unvan gaspı ve halkı yanıltmaktan idari ve cezai soruşturma açar.

Çünkü tıpta bir unvan (Uzman, Doçent, Profesör, Operatör Cerrah); yıllarca süren asistanlık nöbetlerinin, yapılan binlerce başarılı ameliyatın, uluslararası hakemli dergilerde yayımlanan bilimsel makalelerin ve meslektaş jürileri önünde verilen terlerin ardından bir hak ediş olarak verilir. Kimse kendisine sabah kalktığında "Ben bugün Başhekim oldum" diyemez.

Yazılım sektöründe ise hiçbir denetim, hiçbir liyakat barajı ve hiçbir mesleki standart olmadığı için; dün akşam npm install komutunu öğrenen herkes ertesi sabah kendisini "Lead Cloud Architect" ilan edebilmektedir.

Unvanlar Büyüdükçe Uzayan Toplantılar

Unvan enflasyonunun şirketlerde yarattığı en büyük tahribat, mühendisleri koddan ve üretimden koparmasıdır.

Bir insana "Architect", "Director" veya "Head of..." etiketi yapıştırdığınız an, onun zihninde tehlikeli bir dönüşüm başlar: "Ben artık kod yazmamalıyım. Kod yazmak junior'ların işidir. Ben vizyon çizmeliyim, strateji belirlemeliyim, insan yönetmeliyim."

Ve o andan itibaren o şirkette şu kaçınılmaz süreç başlar:

1. Toplantı Çılgınlığı: Sabah 09:30'dan akşam 17:30'a kadar arka arkaya bloklanan Zoom toplantıları. "Mimari Hizalanma Toplantısı", "Sprint Vizyon Çerçevesi", "Sinerji ve Roadmap Değerlendirmesi".
2. Slayt ve Diyagram Fabrikası: Terminali açıp tek bir satır unit test yazmayan, tek bir veritabanı yavaşlığını incelemeyen bu "liderler"; gün boyu Figma'da veya Miro'da rengarenk kutucuklar ve oklar çizerek mimari diyagramlar üretirler.
3. Sorumluluktan Kaçış: Sistem çöktüğünde veya canlıda bir facia yaşandığında, bu unvan zenginleri asla suçu üstlenmezler: "Biz mimariyi çok doğru tasarlamıştık ama yazılımcılar implementasyonu yanlış yapmış."

Yani ortada binlerce dolarlık unvanlar, onlarca saatlik toplantılar vardır; ama ortada çalışan, ölçeklenen ve temiz tek bir satır kod yoktur.

Linus Torvalds'ın Sade Kartviziti

Mühendislik tarihinin en büyük efsanelerine bakın.

Dünyanın tüm sunucularını, süper bilgisayarlarını ve bulut altyapısını üzerinde taşıyan Linux işletim sistemi çekirdeğini yazan ve modern yazılım dünyasının omurgası olan Git'i geliştiren Linus Torvalds'ın unvanı nedir biliyor musunuz?

"Software Engineer" (Yazılım Mühendisi).

Dünyanın en yetenekli çekirdek geliştiricilerinin, Unix'in yaratıcılarının kartvizitlerinde sadece "Programmer" veya "Engineer" yazar. Onlar kendilerine "Grand Master Architect of the Universe" demezler; çünkü onların dehasını kanıtlamak için süslü sıfatlara ihtiyaçları yoktur. Onların yazdığı kod, dünyanın dört bir yanındaki milyarlarca cihazda sessizce, kusursuzca çalışarak konuşur.

Bir insan ne kadar çok yetersizse, o yetersizliği örtmek için o kadar büyük unvanlara sığınır. Tıpkı savaşa girmemiş diktatörlerin göğüslerini dolduran sahte madalyalar gibi.

Unvanı Değil, Zanaatı Büyütmek

Buradan genç yazılımcı arkadaşlarımıza ve sektörün yeni nesline samimi bir çağrımız var:

LinkedIn profillerinizdeki o şişirilmiş, içi boş unvanları bir kenara bırakın. Kendinize "Senior Lead Cloud Guru" diyerek kendinizi kandırmayın.

Önemli olan kartvizitinizde ne yazdığı değildir; önemli olan şunlardır:

• Bir bellek sızıntısını (memory leak) çözerken Linux'un /proc dizinini ve bellek haritasını okuyabiliyor musunuz?
• İki servis arasındaki ağ paketlerinin TCP gecikmesini analiz edebilecek network okuryazarlığına sahip misiniz?
• Veritabanındaki transaction izolasyon seviyelerini (ACID) ve kilit mekanizmalarını gerçekten kavradınız mı?
• Ve en önemlisi; yazdığınız kodla, aldığınız mimari kararlarla şirketinize ve insanlığa gerçek bir değer katabiliyor musunuz?

Eğer bunları yapabiliyorsanız; unvanınızın ne olduğunun hiçbir önemi yoktur. Siz zaten gerçek bir mühendissinizdir.

Ve gerçek bir mühendis için; çalışan, çökmeyen ve zarafetle akan tek bir satır kod, dünyanın tüm yaldızlı unvanlarından çok daha kıymetlidir.

"Hesabınıza 17.002 TL (veya o dönemin resmi asgari ücreti) yatırılmıştır."

Ardından şirketin muhasebe odasından veya patronun makamından sessiz bir çağrı gelir: "Furkan, iki dakika içeri gelebilir misin?"

Geliştirici odaya girer. Patron babacan bir tebessümle çekmecesini açar. İçinden beyaz, isimsiz bir zarf çıkarıp masanın üzerine koyar:

"Al bakalım koçum, bu ayki kalan 35 bin liran. Saymana gerek yok, tamdır. Bak devlete vergi kaptırmıyoruz, SGK kesintisi olmuyor; o parayı devlete yedireceğimize doğrudan senin cebine koyuyoruz. Biz çalışanımızın her zaman yanındayız."

Genç yazılımcı zarfı cebine koyar, teşekkür eder ve masasına döner. İçinde sahte bir sevinç vardır: "Ne güzel işte, vergiden yırttık, cebime daha çok para kaldı."

Oysa o genç adamın bilmediği şey; o beyaz zarfın bir hediye değil, kendi geleceğine sıkılmış bir kurşun olduğudur.

O zarf; emeklilik hakkının, kıdem tazminatının, işsizlik güvencesinin ve en temel finansal itibarının çalındığı anın resmi belgesidir.

Reçetesiz İlaçla Hastayı Uyutan Sahte Hekim

Bu ahlaksızlığın tıp dünyasındaki analojisini gözünüzün önüne getirin.

Özel bir tıp merkezinde ameliyat olacaksınız. Hekim ameliyattan önce yanınıza geliyor ve fısıldıyor:

"Bak kardeşim, bu ameliyatı hastane kayıtlarına ve epikriz sistemine resmi olarak girersek ameliyathane ücreti, SGK payı ve vergiyle birlikte 100 bin lira tutar. Biz dosyana sadece 'basit pansuman ve muayene' yazalım, 2 bin lira gösterelim. Sen kalan 60 bin lirayı bana elden nakit ver. Hem sen karlı çık, hem ben karlı çıkayım."

Cahil bir hasta buna sevinebilir: "Doktor bey ne kadar iyi insan, bana indirim yaptı."

Peki iki hafta sonra o ameliyat yerinde şiddetli bir enfeksiyon geliştiğinde veya içeride cerrahi alet unutulduğu için hasta komaya girdiğinde ne olur?

Hasta ailesi savcılığa ve mahkemeye koşar. Savcı hastane dosyasını açar: Dosyada sadece "pansuman yapıldı" yazmaktadır! Ortada ne ameliyat kaydı vardır, ne anestezi protokolü, ne de hukuki bir sorumluluk. Hekim "Ben bu hastayı ameliyat etmedim ki, sadece pansuman yaptım" der ve işin içinden sıyrılır. Hasta ise sakat kaldığıyla baş başa kalır.

Kayıt dışı çalıştırılan bir yazılımcının durumu da tam olarak budur.

Patron sizi resmi kayıtlarda "vasıfsız bir asgari ücretli" olarak göstermekte; sizin karmaşık sistemler kuran, veritabanları yöneten, gece nöbetleri tutan o yüksek nitelikli zihinsel emeğinizi devletin ve hukukun gözünde tamamen yok saymaktadır.

Acı Gerçekle Yüzleşme Anları

Bu tatlı rüya, hayatın acımasız ve somut gerçekleriyle karşılaştığınız gün korkunç bir kabusa dönüşür:

1. Banka Kredisi Reddedildiğinde: Evlenmek, ev almak veya bir araba sahibi olmak istersiniz. Bankaya gidersiniz. Bankadaki memur resmi bordronuzu ister. E-Devlet'ten SGK hizmet dökümünüzü çıkarırsınız: Maaşınız asgari ücrettir. Bankacı yüzünüze acıyarak bakar: "Beyefendi, bu bordroyla size 50 bin liralık kredi bile veremeyiz." Siz "Ama ben elden 40 bin lira daha alıyorum" dersiniz. Bankacı güler: "Biz resmi evraka bakarız, elden aldığınız para bizi ilgilendirmez." O an anlarsınız ki; toplumun ve finansal sistemin gözünde siz bir hiçsinizdir.
2. Kovulduğunuz Gün (Tazminat Faciası): Şirkette üç yıl boyunca gece gündüz çalışmışsınızdır. Bir gün patronla fikir ayrılığına düşersiniz ve kapının önüne konulursunuz. Muhasebe kıdem ve ihbar tazminatınızı hesaplar: Üç yıllık emeğinizin karşılığı, aldığınız gerçek maaş üzerinden değil, bordrodaki asgari ücret üzerinden hesaplanır! Üçte iki oranında hakkınız gasp edilir. Mahkemeye gitseniz; elden ödeme yapıldığını kanıtlamak için yıllarca süren iş mahkemesi duruşmalarında sürünmek zorunda kalırsınız.
3. İşsizlik ve Emeklilik: İşsiz kaldığınızda devletten alacağınız işsizlik maaşı asgari ücretten bağlanır; kirasını bile karşılayamazsınız. Yarın emekli olduğunuzda alacağınız emekli maaşı, sefalet sınırının altına mahkum edilir.

"Devlete Vergi Yedirmiyoruz" Yalanı

Patronların en sevdiği şark kurnazlığı demagojisi şudur: "Devlete vergi vereceğimize sana veriyoruz."

Bu koca bir yalandır!

Patron o parayı size devlete olan sevgisinden veya sizin refahınızı düşündüğünden elden vermez.

Patron, şirketin ödemesi gereken devasa SGK işveren prim payından ve gelir vergisi stopajından kaçmak için, yani kendi cebine kalacak net karı maksimize etmek için bu suçu işlemektedir. Sizin sırtınızdan kaçırdığı o primlerle; altına lüks cipler çeker, çocuklarını özel okullarda okutur. Size ise ay sonunda çekmeceden uzatılan bir zarfı "büyük bir lütuf" gibi yutturur.

Bu durum sadece yasal bir suç değil; aynı zamanda kul hakkıdır, mesleki haysiyete hakarettir ve kamunun sağlık, eğitim bütçesini hortumlamaktır.

Zarfı Reddetme Haysiyeti

Yazılımcı arkadaşlarımıza çok net bir uyarımız var:

İş görüşmesinde veya maaş zammı masasında patronun ağzından şu cümle çıktığı anda o masayı terk edin: "Maaşının şu kadarını bankaya yatıracağız, şu kadarını elden vereceğiz."

O teklifi asla ve asla kabul etmeyin.

Gerekirse 5 bin lira daha az kazanın; ama maaşınızın tek bir kuruşuna kadar resmi bordronuza yansımasını şart koşun. Brüt maaş üzerinden sözleşme yapın.

Çünkü hesaba elden yatan o kirli nakit para sadece o günkü market alışverişinizi kurtarır; ama resmi evraktaki o sahtekarlık, sizin geleceğinizi, özgürlüğünüzü ve tüm mesleki onurunuzu o patronun çekmecesine rehin bırakır.

Ve hiçbir mühendisin emeği, bir patronun çekmecesindeki beyaz zarfa sığmayacak kadar kıymetlidir.

Kendi geçmişinde başarılı girişimler kurmuş, sektörel tecrübesi olan, erken aşamadaki genç kurucuların vizyonuna inanan ve onlara %5 ila %10 arasında makul bir azınlık hissesi karşılığında sadece sermaye değil; rehberlik, network ve vizyon (Smart Money) sağlayan finansal melekler. Bu melekler şirketin günlük operasyonuna asla karışmaz; girişimcinin önündeki engelleri açar ve kenara çekilip ekibin büyümesini izler.

Şimdi bu kavramı alın ve Türkiye'nin yerel sermaye gerçekliğine ışınlayın.

Karşınıza çıkacak olan figür bir melek değil; muhtemelen tekstilden, inşaattan veya gıda toptancılığından kazandığı nakit parayla "Şu sıralar bu yazılım işinde çok para varmış, biz de iki çocuğa para verelim de şirket kuralım" diyerek masaya oturan geleneksel bir patron olacaktır.

Girişimci sunumunu yapar; küresel pazar büyüklüğünden, SaaS metriklerinden, müşteri edinme maliyetinden bahseder.

Yatırımcı adayı sunumu dinlemez bile. Önündeki tespihi masaya bırakır, gözlerini kısar ve o meşhur teklifi yapar:

"Tamam delikanlı, fikir fena değil. Ben size şirketi kurmanız için 50 bin dolar (veya 1.5 milyon TL) veririm. Ama bir şartım var: Şirketin %51 hissesi bende olacak. Çoğunluk bende olmazsa ben bu işe girmem. Şirketin mali işlerine ve çek defterine de benim muhasebecim bakacak."

Bu cümle; o girişimin, o hayalin ve kurucuların tüm bağımsızlığının henüz doğmadan mezara gömüldüğü anın resmi tutanağıdır.

Ameliyathaneye Giren İnşaat Müteahhidi

Bu tablonun acil servisteki veya ameliyathanedeki karşılığı tam bir cinayettir.

Bir tıp fakültesinin kalp cerrahisi kliniğine son teknoloji bir kalp-akciğer pompası bağışlayan zengin bir iş insanı hayal edin. Cihazın parasını ödemiştir.

Ertesi gün cerrahi ekip açık kalp ameliyatına girer. Göğüs kafesi açılmış, hasta pompaya bağlanmıştır. Tam o sırada ameliyathanenin kapısı açılır; içeriye o iş insanı sokak kıyafetleriyle girer. Cerrahın omzuna dokunur:

"Hocam dur bir dakika! Bistüriyi öyle tutma, çok derin kesiyorsun. Dikiş ipliğini de idareli kullan, pahalı o iplikler. Ayrıca hastaya verdiğin anestezik ilacın markasını beğenmedim, benim yeğenin toptancı firmasından alacaksınız. Bu odadaki cihazın parasını ben verdim, buranın patronu benim!"

Böyle bir durumda cerrah ne yapar? Hastanın hayatını kurtarmak için o adamı tekme tokat dışarı attırır.

Çünkü tıp da, yazılım mühendisliği de özerk uzmanlık gerektiren disiplinlerdir. Paraya sahip olmak, bilgiye ve vizyona sahip olmak demek değildir. Bir müteahhidin cerrahın bistürisine karışması ne kadar absürtse; geleneksel bir tüccarın yazılım mimarisine, ürün yol haritasına ve teknoloji tercihlerine karışması da o kadar gülünç ve tehlikelidir.

Melek Yatırımcının "Şantiye Şefine" Dönüşmesi

O %51'lik zehirli sözleşmeyi imzaladığınız andan itibaren hayatınız bir startup kurucusu olmaktan çıkar, o patronun yeni "şantiye şefi" haline gelirsiniz:

1. Sabah Mesai Denetimi: Yatırımcı her sabah 08:45'te ofise gelir veya kameralardan izler: "Yazılımcılar neden 09:00'da masasında değil? Neden geç kalıyorlar? Akşam kaçta çıkıyorlar?" Yazılımın yaratıcı bir zihinsel süreç olduğunu, bir mühendisin gece 03:00'te yazdığı mimariyle şirketi uçurabileceğini kavrayamaz; onu tekstil atölyesindeki overlokçu gibi saatle ölçmeye çalışır.
2. Ürün Tasarımına Müdahale: "Bizim hanım baktı, uygulamanın rengini beğenmedi. Butonları pembe yapın.", "Bizim dünürün damadı da yazılımcıymış, o dedi ki React değil PHP ile yazsaydınız daha hızlı olurdu, baştan yazın." gibi akıl almaz taleplerle ürünün omurgası kırılır.
3. Gelecek Turların İflası: İlk turda şirketin %51'ini yerel bir patrona kaptıran bir girişime; ilerleyen turlarda ne küresel bir risk sermayesi (VC) fonu bakar, ne de profesyonel bir fon tek bir kuruş yatırım yapar. Çünkü kurucuların çoğunluk hissesine sahip olmadığı bir şirket, yatırım dünyasında "yaşayan bir ölüdür" (dead on arrival).

"Smart Money" vs. "Zehirli Sermaye"

Para sadece para değildir. Yatırım dünyasında paranın rengi ve karakteri vardır.

• Smart Money (Akıllı Sermaye): Sektörün dinamiklerini bilen, risk almayı göze alan, başarısızlığın bu işin doğasında olduğunu anlayan, size müşteri ve ortaklık kapılarını açan sermayedir.
• Toxic Money (Zehirli Sermaye): Parayı size bir borç veya tahakküm aracı olarak veren, ilk çeyrekte ciro ve kar baskısı kuran, her harcamanın fişini bakkal defteri gibi sorgulayan ve şirketin kontrolünü ele geçirmeye çalışan sermayedir.

Türkiye'deki sözde "melek yatırımcıların" büyük bir kısmı maalesef bu ikinci kategoridedir. Onlar risk alan bir melek değil; teknoloji trenine ucuza binip gençlerin emeğine çökmeye çalışan fırsatçı sermayedarlardır.

Girişimcilere Çağrı: Fikrinizi Köleleştirmeyin

Yeni bir ürün geliştiren, uykusuz geceler geçiren genç girişimci arkadaşlarımıza tavsiyemiz çok açıktır:

Aç kalın, geceleri freelance iş yaparak sunucu masraflarınızı çıkarın, şirketinizi kendi öz kaynaklarınızla (bootstrap) büyütün; ama şirketinizin kontrolünü ve çoğunluk hissesini asla bu tip yerel sermayedarlara teslim etmeyin.

İlk turda %15'ten fazla hisse isteyen, sözleşmeye saçma sapan veto hakları koyan, çek defterine el koymaya kalkan hiç kimse melek değildir.

Unutmayın; Türkiye'de yatırım almak çoğunlukla bir başarı veya özgürleşme anı değil; fikrinize, emeğinize ve geleceğinize yeni, otoriter ve vizyonsuz bir patron ortak etme tuzağıdır.

Kendi geminizin kaptanı olarak batmak; bir patronun yatında forsa olmaktan bin kat daha onurludur.

"Bir şirkette kalmak sizi fakirleştirir; şirket değiştirmek ise sizi zenginleştirir."

Aynı üniversiteden aynı yıl mezun olmuş iki arkadaş düşünün: Can ve Mert.

Can, mezuniyetinde girdiği bir teknoloji şirketine sadakatle bağlanmıştır. Şirketin kod tabanını avucunun içi gibi bilir. Gece 03:00'te production çöktüğünde yatağından fırlayan, hafta sonu deployment'larına gönüllü olan, projenin tüm teknik borcunu omuzlayan fedakar bir mühendistir. Şirkette üç yılını doldurmuştur. Üç yıl boyunca her zam döneminde yöneticisi sırtını sıvazlamış, "Can'cım sen bizim can damarımızsın, bu yıl sana şirket ortalamasının üstünde, tam %30 zam yaptık" demiştir.

Sonuç? Can'ın üç yıl önceki maaşı enflasyon ve döviz karşısında erimiş; bugünkü alım gücü yeni mezun bir junior seviyesine gerilemiştir.

Şimdi Mert'e bakın. Mert hiçbir şirkete duygusal bağ kurmamıştır. İlk şirketinde 9 ay kalmış, başka bir teklif bulunca %60 zamla geçmiş. İkinci şirketinde 10 ay kalmış, bir sonraki teklifte maaşını %70 artırmış. Üçüncü şirketine geçerken bir sıçrama daha yapmıştır.

Üçüncü yılın sonunda Can ile Mert Kadıköy'de bir kahvecide buluşurlar.

Mert'in kazandığı maaş, Can'ın kazandığı maaşın tam üç katıdır!

Üstelik Can projenin tüm mimarisini sırtında taşırken; Mert gittiği şirketlerde sadece belirli modülleri yazıp, sistemin derin karmaşasına bulaşmadan bir sonraki durağına geçmiştir.

İşte yazılım dünyasının en büyük ahlaki ve yönetimsel çöküşü budur: Piyasa sadakati ödüllendirmez; aksine, sadık olanı finansal olarak cezalandırır (Loyalty Penalty).

Kendi Uzmanını Kaçırıp Dışarıdan Nöbetçi Kiralayan Hastane

Bu idari basiretsizliğin sağlık sektöründeki karşılığı tam bir yönetim fiyaskosudur.

Bir eğitim ve araştırma hastanesini düşünün. Acil tıp kliniğinde yıllardır çalışan, acilin her köşesini bilen, kritik triyaj kararlarını saniyeler içinde veren, ekibin saygısını kazanmış kıdemli bir uzman hekim vardır.

Bu hekim başhekimliğe gider: "Hocam, hayat pahalılığı arttı, nöbet ücretlerimiz enflasyonun çok altında kaldı. Maaşımda veya döner sermayemde makul bir iyileştirme talep ediyorum, aksi takdirde ailemi geçindiremiyorum."

Başhekim ellerini iki yana açar: "Ah be doktorum, biliyorsun bütçemiz çok kısıtlı. Bakanlık kadro tavanını belirledi, sana tek kuruş fazla veremeyiz. Şartlar böyle, idare edeceksin."

Hekim istifa eder. Özel sektöre veya başka bir hastaneye geçer.

Peki ertesi hafta o hastanede ne olur?

Klinikte uzman hekim kalmadığı için acil servis kilitlenir. Başhekimlik panikle dışarıdan taşeron özel sağlık şirketleri üzerinden "nöbetçi konsültan hekim" kiralamak zorunda kalır. Ve o dışarıdan gelen, hastanenin işleyişinden bihaber olan hekime, giden hekime vermekten kaçındığı maaşın iki buçuk katını seve seve öder!

İşte Türkiye'deki yazılım şirketlerinin ve İK departmanlarının akıl almaz zihniyeti tam olarak bu hastane başhekiminin zihniyetidir.

İK Bütçelerinin İkiyüzlülüğü: Retention vs. Hiring

Şirketlerin finansal bütçelerinde iki ayrı havuz vardır:

1. Retention Budget (Çalışanı Tutma Bütçesi): İçerideki mevcut personelin zammı için ayrılan pay. Bu havuz her zaman "kriz var", "enflasyon yüksek", "bütçe kısıtlı" bahaneleriyle dar tutulur.
2. Hiring Budget (Yeni İşe Alım Bütçesi): Dışarıdan yeni birini almak için ayrılan pay. Bu havuz inanılmaz bir şekilde sınırsızdır!

İçerideki sadık mühendisi tutmak için ayda 10 bin liralık zammı çok gören yönetim; o mühendis istifa ettiği gün masadaki işleri yetiştirebilmek için dışarıdan alacağı adaya piyasa rayicinden 25 bin lira fazlasını hiç gözünü kırpmadan verir.

Dahası; giden personelin arkasında bıraktığı kurumsal hafıza kaybını, yeni personelin işe alışma (onboarding) sürecindeki 3 aylık verimsizliği ve bozulan kod tabanını telafi etmek için yüz binlerce lira fazladan harcarlar.

Bu, tarihin en irrasyonel, en ahmakça şirket yönetimi modelidir.

Kurumsal Hafızanın Mezarlığı

Bu çarpık düzenin yarattığı en büyük felaket, kod tabanlarının ve sistemlerin kimsesizleşmesidir.

Herkesin 9 ayda bir şirket değiştirdiği bir ekosistemde; yazılan kodların arkasındaki mantığı, mimari kararların neden öyle alındığını bilen hiç kimse kalmaz. Şirketler, kimsenin dokunmaya cesaret edemediği "legacy spagetti" sistemlerin esiri haline gelir. Yeni gelen mühendis eskisinin kodunu anlamaz, silip baştan yazar; 9 ay sonra o da gider ve döngü sonsuza kadar tekrarlanır.

Sadakati cezalandıran şirketler, aslında kendi kurumsal geleceklerini ve sistem sürekliliklerini çöpe atmaktadır.

Yazılımcıya Düşen: Gerçekçi Olmak

Buradan genç ve orta kıdemdeki yazılımcılara verilecek en dürüst kariyer tavsiyesi şudur:

Şirketler sizin aileniz değildir. Şirketler birer ticari organizasyondur ve bu organizasyonların kuralını siz yazmadınız.

Eğer çalıştığınız şirkette emeğinizin karşılığı verilmiyorsa, enflasyon karşısında reel alım gücünüz eriyor ve yönetim "bütçemiz yok" masalları anlatıyorsa; sadakat gösterip yerinizde oturmanın size kazandıracağı tek şey fakirliktir.

Mülakatlara girin. Piyasa değerinizi test edin. Konfor alanınızdan çıkmaktan korkmayın.

Çünkü yerel piyasa kuralları değişmediği sürece; hak ettiğiniz değeri aynı şirkette bekleyerek değil, kapıyı kapatıp bir sonraki masaya geçerek almak zorunda kalacaksınız. Ve o kapıyı çarpmaktan çekinmeyenler, her zaman o masada sessizce bekleyenlerden daha güçlü olacaktır.

"Yıllık Performans Değerlendirme Dönemi."

İK departmanından tüm çalışanlara heyecanlı e-postalar yağar: "Kişisel gelişiminizi kutlamak, hedeflerinizi değerlendirmek ve geleceğe yön vermek için performans formları açılmıştır!"

Yazılımcı masasına oturur. Önünde İK yazılımının (BambooHR, Workday, SuccessFactors vb.) karmaşık formları açılır. Sayfalarca soru vardır:

• "Bu yıl şirketin stratejik vizyonuna nasıl katkı sağladınız?"
• "Hangi liderlik yetkinliklerinizi geliştirdiniz?"
• "Kendinize 5 üzerinden kaç puan verirsiniz?"

Mühendis büyük bir ciddiyetle günlerini harcar. Yıl boyunca kapattığı yüzlerce Jira biletini, gece 02:00'de çözdüğü veritabanı krizlerini, yazdığı binlerce satır optimize kodu ve mimariye kazandırdığı hız artışlarını tek tek belgeler. Kendine gururla "5 üzerinden 4.8" verir.

Ardından 360 derece akran değerlendirmeleri yapılır, takım arkadaşlarına övgüler düzülür.

Ve nihayet, o büyük gün gelir: Yöneticiyle Birebir Performans Kapanış Toplantısı.

Yazılımcı heyecanla odaya girer; hak ettiği takdiri ve yüksek zam oranını alacağını düşünmektedir.

Yönetici masanın karşısında derin bir iç çeker. Gözlerini kaçırarak konuşmaya başlar:

"Furkan'cım, gerçekten olağanüstü bir yıl geçirdin. Gece gündüz çalıştın, sistemi ayakta tuttun, katkıların tartışılamaz. Ama biliyorsun... Şirket genelinde bir Bell-Curve (Çan Eğrisi) kuralı var. İK'dan gelen kota gereği ekibimizden sadece 1 kişiye 'Beklentinin Üzerinde' notu verebiliyoruz. O hakkı da bu sene başka bir arkadaşa kullanmak zorunda kaldık. Sana mecburen 'Beklentileri Karşılıyor' (yani 5 üzerinden 3) vermek durumundayım. Yoksa üst yönetim bütçeyi onaylamıyor."

O an, masadaki tüm o KPI'ların, formların, hedeflerin ve değerlendirmelerin koca bir tiyatro dekorundan ibaret olduğunu anlarsınız.

Deprem Bölgesinde Hekime Çan Eğrisi Uygulamak

Bu kurumsal maskaralığın tıp dünyasındaki karşılığı insanın tüylerini ürpertir.

Büyük bir felaket, örneğin bir deprem veya küresel bir pandemi yaşanmıştır. Bir eğitim araştırma hastanesinin acil servisindeki tüm hekimler, hemşireler ve sağlık memurları; aylarca evlerine gitmeden, uykusuz, molasız çalışmış ve binlerce kritik hastayı hayata döndürmüştür. Herkes insanüstü bir fedakarlık sergilemiştir.

Yıl sonu gelir. Hastane başhekimi klinik ekibini toplar ve şöyle der:

"Arkadaşlar, hepiniz birer kahramansınız, canınızı dişinize taktınız. Ancak Sağlık Bakanlığı'ndan performans ödemeleri için bir genelge geldi. Çan eğrisi gereği servisimizdeki hekimlerin sadece %10'una 'Üstün Başarı' ödülü verebiliyoruz. Geri kalan %80'iniz 'Vasat/Normal', %10'unuz ise 'Yetersiz' performans dilimine sokulacaksınız. Kusura bakmayın, döner sermaye bütçemiz bu kadar."

Böyle bir tabloda o sağlık çalışanlarının hissedeceği şey ne olur? Derin bir hakaret, mesleki onurun çiğnenmesi ve katıksız bir öfke.

İşte yazılım şirketlerindeki çan eğrisi sistemi tam olarak bu ahlaksızlığın kurumsal kılıfıdır.

Performans Sistemi Bir Ölçüm Değil, Bütçe Meşrulaştırma Aracıdır

Kurumsal dünyanın en büyük yalanı, performans değerlendirme süreçlerinin "çalışanın gelişimini ve katkısını ölçmek" için yapıldığıdır.

Gerçek ise son derece basittir: Performans sistemi, önceden belirlenmiş olan kısıtlı zam bütçesini çalışanlara kabul ettirmenin psikolojik manipülasyon aracıdır.

Süreç aslında şöyle işler:

1. Finans departmanı ve yönetim kurulu yıl başında toplanır: "Bu yıl toplam çalışan maaş bütçesini en fazla %30 artırabiliriz."
2. İK departmanı bu %30'luk kısıtı alır ve matematiksel bir filtreye dönüştürür: "Eğer herkese gerçek performansına göre not verirsek bütçe patlar. O halde herkesi zorla 5 üzerinden 3'e sıkıştıracak bir çan eğrisi uydurmalıyız."
3. Yöneticilere gizli kotalar dağıtılır: "Ekibinin %70'inden fazlasına 3'ün üzerinde not veremezsin!"
4. Ve toplantılarda mühendisin önüne bahaneler sürülür: "Çok iyi kod yazdın ama şirket içi sunumlarda yeterince proaktif değildin", "Teknik olarak harikasın ama kurumsal kültür etkinliklerine yeterince katılmadın."

Yani notunuzu belirleyen şey sizin yazdığınız kodun kalitesi veya çözdüğünüz problemler değildir; finans departmanının o yılki nakit akışı ve İK'nın excel formülleridir.

Motivasyonun Katliamı

Bu sahte tiyatronun şirketlerde yarattığı en büyük tahribat, yüksek performans gösteren yetenekli mühendislerin motivasyonunu yok etmesidir.

Mühendis bakar ki; gece gündüz çalışıp production kurtaran ile, mesai boyunca sadece kahve içip iki satır HTML değiştiren adam yıl sonunda aynı "Beklentileri Karşılıyor" kutucuğuna tıkıştırılıyor ve aynı %30 zammı alıyor.

O mühendis bir daha asla fedakarlık yapmaz.

Sistem çöktüğünde telefonunu kapatır. Saat 18:00 dediğinde bilgisayarını kilitler. "Madem beklentileri karşılamak yetiyor, ben de tam olarak asgari beklenti kadar çalışırım" der. Şirket, kendi icat ettiği çan eğrisiyle kendi en iyi beyinlerini vasatlığa mahkum eder.

Tiyatroyu Reddetmek

Bir şirketin başarısı, insanları sahte istatistiksel eğrilerin içine hapsetmekle değil; gerçek başarıyı şeffafça ödüllendirmekle mümkündür.

Eğer tüm ekibiniz harika bir yıl geçirmişse, tüm ekibinize hak ettiği payı vermek zorundasınızdır. Bütçeniz yoksa, bunu dürüstçe söyleyecek cesareti göstermelisiniz: "Arkadaşlar, bu yıl şirket olarak finansal hedeflerimizi tutturamadık, bütçemiz kısıtlı; ama hepinizin emeğinin farkındayız."

Bunu söylemek yerine, çalışanların başarısını inkar edip onları "vasat" göstermeye çalışmak kurumsal bir sahtekarlıktır.

Ve hiçbir mühendis, excel tablolarındaki yapay yüzdelere sığdırılamayacak kadar kıymetlidir.

Patron koltuğunda geriye yaslanır, purosunu veya çayını tüttürerek büyük bir özgüvenle konuşmaya başlar:

"Furkan Bey, biz işin en zor kısmını zaten hallettik. İsim tescilini yaptık, ahmetogullariinsaat.com domainini aldık. Yıllık hosting paketini de en kral firmadan 400 liraya bağladık. Yani altyapı hazır, yazılım bitti sayılır. Şimdi senden tek ricamız; sisteme girip bizim ürünleri listeleyeceğimiz, müşterilerin kredi kartıyla alışveriş yapacağı, muhasebe programımızla otomatik konuşan, kargoyu takip eden ve stokları güncelleyen bir arayüz koyuver. Altı üstü iki sayfa tasarım yapacaksın. İki günde bitirirsin herhalde, sana da bir çorba parası atarız."

Yazılımcı boğazını temizler, sakin kalmaya çalışarak teklifi önüne koyar:

"Ahmet Bey; bahsettiğiniz ERP entegrasyonu, distributed ödeme altyapısı, PCI-DSS güvenlik standartları, sepet mimarisi ve mobil uyumlu arayüzün geliştirilmesi en az 3 aylık bir mühendislik çalışması gerektirir ve maliyeti 250 bin TL'dir."

O an odadaki hava anında buz keser. Patronun gözleri yuvalarından fırlar, kaşları çatılır:

"Ne 250 bini kardeşim! Sen beni dolandırıyor musun? Ben zaten isim hakkını 150 liraya aldım, hostinge de para verdim. Sitenin her şeyi hazır! Sen altı üstü klavyede yazı yazacaksın, iki düğme koyacaksın. Bu para neyin nesi?!"

İşte yerel pazarımızın en kadim, en trajikomik yanılgısına hoş geldiniz: Arsa satın almakla, o arsanın üzerine 40 katlı depreme dayanıklı akıllı bir gökdelen dikmek arasındaki farkı kavrayamamak.

Eczaneden Yara Bandı Alıp "Ameliyathane Kurdum" Demek

Bu zihniyetin sağlık sektöründeki karşılığı tam bir akıl tutulmasıdır.

Bir adamın mahalle eczanesine gidip 25 liraya bir rulo sargı bezi, 30 liraya bir şişe tentürdiyot ve 10 liraya bir kutu yara bandı aldığını düşünün.

Sonra evine dönüyor, oturma odasındaki sehpanın üzerine bu malzemeleri diziyor ve komşularını toplayıp gururla şöyle diyor:

"Komşular, müjde! Evde tam teşekküllü özel hastaneyi kurdum. İlaçlar hazır, sargı bezi masada. Şimdi mahalledeki cerraha haber salın, gelsin burada açık kalp ameliyatı yapsın, karaciğer nakli yapsın. Zaten hastanenin her şeyini ben aldım, cerrah sadece eline bistüriyi alıp iki dikiş atacak. Ona da bir muayene parası veririz, biter."

Böyle bir adama ne dersiniz? Muhtemelen akli melekelerinin yerinde olmadığını düşünür, en yakın psikiyatri kliniğine sevk edersiniz.

Çünkü bir hastane; dört duvar veya sargı bezi demek değildir. Hastane; steril havalandırma sistemleri, anestezi cihazları, yoğun bakım monitörleri, kan biyokimya laboratuvarı ve hepsinden önemlisi o aletleri kullanmayı bilen uzman hekimlerin yıllarca imbikten geçmiş bilgisidir.

Yazılımda da bir alan adı (domain); internet denen sınırsız coğrafyada sadece bir posta adresi tabelasıdır.

Hosting ise o tabelanın çakıldığı boş bir çamurlu arsadır.

O arsanın üzerine binlerce kullanıcının güvenle ödeme yapabileceği, verilerin şifreleneceği, concurrency krizlerinin yönetileceği bir yazılım inşa etmek; katıksız bir mühendislik, mimari vizyon ve derin bir zihinsel emek gerektirir. Tabelayı satın almış olmak, evi inşa etmiş olmak demek değildir.

Somut Olmayan Emeğin Değersizleştirilmesi

Türkiye'deki geleneksel sermayenin yazılıma para ödemekte bu kadar direnç göstermesinin temelinde, fiziksel olmayan (intangible) emeği idrak edememe körlüğü yatar.

Geleneksel tüccar; elinde tutabildiği, kamyona yükleyebildiği, deposuna istifleyebildiği mala saygı duyar. Bir inşaata çimento alırken, fabrikaya torna tezgahı alırken milyonlarca lirayı hiç acımadan harcar. Çünkü demir somuttur, ağırlığı vardır, gözüyle görür.

Fakat yazılımcının ürettiği değer bir USB belleğin içinde veya bulut sunucunun belleğindedir. Kod görünmez; elle tutulmaz. Patron için ekrandaki o harfler, çocuğun evde klavyede rastgele tuşlara basmasından farksız görünür. "Benim yeğen de bilgisayarla oynuyor" cehaletinin kökeni burasıdır.

Bu yüzden patron; bir sunucu kutusuna (donanıma) 50 bin TL verirken gocunmaz ama o donanımın içindeki hayatı var eden yazılıma 10 bin TL vermeyi "sokağa atılan para" olarak görür.

Yazılımcının İmtihanı: Sınır Koyabilmek

Bu müşteri profiliyle karşılaştığınızda yapabileceğiniz en büyük hata, onların bu cehaletine boyun eğip fiyat kırmaktır.

"Peki abi, madem bütçeniz bu kadar, ben size 5 bin liraya halledeyim" dediğiniz an; hayatınızın en büyük cehennemine adım atarsınız.

Çünkü 250 bin liralık profesyonel bir kurumsal müşteri projenin sınırlarına ve sözleşmeye saygı duyarken; 5 bin liraya iş yaptırdığını sanan o KOBİ patronu, haftanın yedi günü gece yarısı sizi arayıp "Bizim sitenin yazısı biraz sağa kaymış, hemen düzelt" diye ömrünüzü tüketir. Ucuz müşterinin maliyeti her zaman en pahalı maliyettir.

Onlara arsa ile bina arasındaki farkı analojilerle anlatın.

Anlıyorlarsa ne ala; anlamıyorlarsa ve "Domaini aldık zaten, gerisi kolay" demeye devam ediyorlarsa, bırakın o boş arsanın üzerinde kendi tabelalarıyla baş başa kalsınlar.

Çünkü mühendislik; boş arsalara çadır kurmak isteyenlerin kaprisleriyle harcanamayacak kadar soylu bir meslektir.

Ancak Türkiye'de, özellikle bir finansal teknoloji (FinTech), e-ticaret veya kurumsal muhasebe/ERP şirketinde çalışan bir mühendisseniz; cuma geceleri telefonunuzun başında hafif bir anksiyete nöbetiyle beklemeniz gereken saatlerdir.

Çünkü saatler tam 00:00'ı vurduğunda, devletin o meşhur web sitesinde yeni bir sayfa açılır: Resmi Gazete.

Ve o gece Resmi Gazete'nin mükerrer sayısında tek bir satırlık bir Cumhurbaşkanlığı Kararı veya Bakanlık Tebliği yayımlanır:

"Katma Değer Vergisi (KDV) genel oranı %18'den %20'ye, belirli mal ve hizmetlerdeki indirimli oran ise %8'den %10'a yükseltilmiştir. Bu karar yayımı tarihini takip eden ilk iş günü (yani pazartesi sabahı saat 00:00'da) yürürlüğe girer."

O bildirim düştüğü an; Türkiye'deki on binlerce yazılımcının cumartesi ve pazar gününe dair tüm hayalleri, sinema biletleri, aile yemekleri ve dinlenme planları tek bir saniyede buharlaşır.

Şirketin Slack kanallarında kırmızı alarmlar yanıp sönmeye başlar:

"@channel Arkadaşlar acil durum! KDV oranları değişti. Pazartesi sabahına kadar veritabanındaki 5 milyon ürünün vergi oranlarını güncellememiz, checkout ve sepet hesaplama motorunu revize etmemiz, e-fatura entegrasyonlarını yeni şemaya uyarlamamız ve mobil uygulamalara acil hotfix çıkmamız lazım. Aksi takdirde pazartesi sabahı kesilen her hatalı faturada Gelir İdaresi'nden milyonluk cezalar yeriz!"

Ve o andan itibaren, modern bir ülkenin mühendisleri; devletin bürokratik bir gecikmesinin faturasını 48 saat aralıksız kod yazarak, sabahlayarak ödemek üzere masalarına kilitlenir.

Acil Servis Protokolünü Gece Yarısı Değiştirmek

Bu durumun sağlık sektöründeki karşılığını bir acil tıp uzmanına veya başhekime sorun.

Cuma gecesi saat 01:00'de Sağlık Bakanlığı ve Sosyal Güvenlik Kurumu'nun (SGK) ani bir genelge yayımladığını hayal edin:

"Acil servislere başvuran hastaların triyaj kodlama sistemi, yeşil ve sarı alan faturalandırma kuralları ve reçete edilen tüm antibiyotiklerin Medula onay algoritmaları bu sabah saat 08:00 itibarıyla tamamen değiştirilmiştir. Uymayan hastanelerin tüm geri ödemeleri kesilecek ve idari para cezası uygulanacaktır."

Cumartesi sabahı nöbete giren hekim neyle karşılaşır?

Kapıdan kan revan içinde travma hastaları, kalp krizleri girerken; hekim ve hemşireler hastaya müdahale etmek yerine hastane bilgi sisteminde çöken ekranlarla, sisteme girilemeyen reçetelerle ve onay vermeyen Medula sunucularıyla boğuşmak zorunda kalır. Bürokrasi, acil servisin şah damarına basmıştır.

İşte Türkiye'de cuma gecesi mevzuat değişiklikleri; dijital ekonominin, ödeme sistemlerinin ve e-ticaret altyapılarının kalbine tam olarak bu cerrahi darbeyi vurmaktadır.

Bürokrasinin "Tek Tuş" Cehaleti

Bu acımasızlığın arkasında yatan temel sebep, devlet bürokrasisinin ve kanun koyucuların yazılımın doğasını hiç anlamamasıdır.

Ankara'daki bir bürokrat veya siyasetçi, yazılımı şöyle bir şey zanneder: "Ne var canım, altı üstü bilgisayarda bir tuşa basacaklar, %18'i silip yerine %20 yazacaklar. İki dakikalık iş için yaygara koparıyorlar."

Oysa o bürokratın bilmediği şey şudur:

• Milyonlarca satırlık ilişkisel veritabanında, eski siparişlerin geriye dönük muhasebe tutarlılığını bozmadan yeni vergi oranlarını tanımlamak devasa bir veri göçü (data migration) gerektirir.
• Üçüncü parti onlarca entegrasyon (ödeme geçitleri, pazaryeri API'leri, kargo firmaları, e-fatura özel entegratörleri) bu yeni kuralı kendi sistemlerinde eşzamanlı olarak güncellemek zorundadır.
• Eğer tek bir servis gecikirse, sistemler arası veri tutarsızlığı (split-brain) patlar ve müşterinin kartından çekilen tutarla faturadaki tutar birbirini tutmaz.

Dünyanın gelişmiş hukuk devletlerinde bu tip yapısal vergi veya mevzuat değişiklikleri yapıldığında; sektöre en az 3 ila 6 aylık bir geçiş süreci (grace period) tanınır. Yazılım ekipleri sistemlerini test ortamlarında dener, senaryoları simüle eder ve geçiş günü geldiğinde sıfır kesinti ve sıfır panikle canlıya alırlar.

Bizde ise cuma gecesi tebliğ basılır, pazartesi sabahı ceza sopası sallanır.

Esnek Mimarinin Önemi: Kuralı Koda Gömme!

Bu coğrafyada hayatta kalmak isteyen bir yazılım mimarının çıkarması gereken en büyük mühendislik dersi şudur:

Türkiye'de çalışıyorsanız; hiçbir yasal oranı, hiçbir vergi kuralını ve hiçbir iş mantığını asla ve asla kodun içine sert bir şekilde gömmeyin (hardcoded yapmayın).

Acemi geliştirici kodun içine yazar: price * 1.18.

Bilge bir Türk mühendisi ise bilir ki; o 18 rakamı her an 20 olabilir, 25 olabilir veya gecenin bir yarısı sıfırlanabilir.

Bu yüzden mimarisini; dinamik kural motorları (rule engine), konfigürasyon tabloları, versiyonlanmış vergi profilleri ve geçmişe dönük immutable kayıtlar üzerine kurar. Tek bir satır kodu yeniden derlemeden (recompile etmeden), sadece bir konfigürasyon değişikliğiyle tüm sistemi adapte edebilecek esnekliği ilk günden tasarlar.

Mühendisin Çalınan Hafta Sonları

Bütün bu teknik önlemlere rağmen, değişmeyen tek bir acı gerçek kalır: Mühendislerin çalınan hayatları.

Bürokrasinin plansızlığı, kurumların eşgüdümsüzlüğü ve patronların ceza korkusu; her defasında o masanın başında uykusuz kalan 25 yaşındaki genç yazılımcıların sırtına yüklenir.

Türkiye'de yazılımcı olmak; sadece en son teknolojileri, en modern framework'leri takip etmek demek değildir. Türkiye'de yazılımcı olmak; her cuma gecesi Resmi Gazete'nin fırtınalarına karşı uyanık kalmak ve devletin anlık refleksleriyle yarışabilecek bir kardiyak dayanıklılığa sahip olmak demektir.

Ve o hafta sonu mesailerinin faturasını hiçbir maaş bordrosu tam olarak ödeyemez.

"Efendim, tesisimiz Uptime Institute tarafından tescillenmiş Tier III Standartlarında inşa edilmiştir. N+1 değil, tam 2N yedekli güç mimarimiz, birbirinden bağımsız çift elektrik besleme hattımız, yedekli jeneratör parkımız ve kesintisiz iklimlendirmemiz mevcuttur. Sistemlerimizin yıllık kesinti payı sadece 1.6 saattir, yani %99.982 kesintisizlik garanti ediyoruz."

Müşteri sunumdaki 3 boyutlu render çizimlerine, pırıl pırıl parlayan beyaz zeminlere ve devasa UPS akü odalarına hayranlıkla bakar. Sözleşme imzalanır. Sunucular kabinlere vidalanır.

Ancak Türkiye'de altyapı yönetmek; kağıt üzerindeki Amerikan standartlarıyla değil, bu coğrafyanın trafo patlamaları, kontrolsüz hafriyat kazıları ve aniden çökebilen enerji şebekesiyle yüzleşmek demektir.

Sıcak bir temmuz günü öğleden sonra saat 14:00. Şehir şebekesinde devasa bir trafo arızası meydana gelir.

Veri merkezinin elektriği kesilir. UPS aküleri devreye girer, 15 saniye sonra dışarıdaki dizel jeneratörler gürleyerek marş basar. Her şey kitaba uygundur; sistem pürüzsüzce jeneratör yüküne geçer.

Fakat aradan 4 saat geçer... 8 saat geçer... 14 saat geçer. Dağıtım şirketi arızayı giderememiştir. Jeneratörün ana yakıt tankındaki seviye göstergesi hızla kırmızı bölgeye inmektedir. Tankerdeki mazot bitmek üzeredir.

Ve tam o an; slaytlarda anlatılan o görkemli "Tier III felsefesi", yerini Türkiye'nin en çıplak gerçeğine bırakır: Mühendislerin bagajında plastik bidonlarla en yakın benzinliğe koşup mazot aradığı o ilkel hayatta kalma savaşına.

JCI Akreditasyonlu Hastanede Tükenen Oksijen Tüpleri

Bu tablonun acil servisteki veya yoğun bakımdaki yansıması doğrudan ölümcüldür.

Uluslararası Sağlık Akreditasyonu (JCI) belgesine sahip, duvarları mermer kaplı lüks bir özel hastaneyi düşünün. Broşürlerinde en gelişmiş yaşam destek üniteleri, HEPA filtreli ameliyathaneler ve bağımsız medikal gaz santralleri övülmektedir.

Bir gece hastanenin sıvı oksijen tankında donma veya kaçak meydana gelir. Ana hat basıncı aniden düşer. Yoğun bakımdaki 20 entübe hasta mekanik ventilatörlerde havasız kalma tehlikesiyle karşı karşıyadır.

O an başhekimin veya müdürün duvardaki JCI sertifikasını okumasının hiçbir faydası yoktur.

Nöbetçi asistanlar ve anestezi teknisyenleri; panik içinde hastane bodrumuna koşar, elleriyle 50 kiloluk çelik yedek oksijen tüplerini taşımaya, manometreleri kurbağacık anahtarlarla sıkıştırmaya ve hastaların solunum devrelerine manuel ambu bağlayarak dakikalarca elle hava basmaya başlarlar.

Bir hastanenin gerçek kalitesi; lobisindeki piyano veya duvardaki akreditasyon belgesi değil, ana oksijen hattı koptuğunda sahadaki personelin yedek tüpü ne kadar sürede devreye alabildiğidir.

Veri merkezinde de durum aynıdır: Sunucuları ayakta tutan şey web sitenizdeki parlak Tier III logosu değildir; jeneratörün mazotu bittiğinde depoya ulaşacak yakıt tankerinin geliş hızıdır.

Slaytlardaki 2N vs. Sahadaki Tek Mazot Tedarikçisi

Tier III mimarisinin temel mantığı "eşzamanlı bakım yapılabilirlik" (concurrent maintainability) ve hiçbir tek hata noktasının (Single Point of Failure - SPOF) bulunmamasıdır.

Elektrik kablolarınız yedeklidir, trafolarınız çift girişlidir, UPS üniteleriniz A ve B yolları olarak ikiye ayrılmıştır.

Peki sahadaki o görünmeyen lojistik bağımlılıklar yedekli midir?

1. Tek Bir Akaryakıt Sözleşmesi: Şirketler jeneratör için bir akaryakıt dağıtım şirketiyle "Acil yakıt protokolü" imzalar. Ancak deprem, sel veya genel bir şehir elektrik kesintisinde o dağıtım firmasının tankerleri trafiğe takılır, yollar kapanır veya kendi dolum tesisinin pompaları elektriksiz kaldığı için yakıt basamaz!
2. Kışın Donan Mazot: Doğu Anadolu'da veya kışın eksi 15 dereceye düşen Ankara gecelerinde; yakıt tankına antifrizli kışlık mazot koymayı unutan veri merkezinin jeneratör yakıt filtreleri parafinleşerek tıkanır. 2 milyon liralık jeneratör, 10 liralık yakıt katkısı konulmadığı için donup kalır.
3. Yakıt Pompası Arızası: Ana yer altı deposundan jeneratörün günlük servis tankına mazot pompalayan basit bir 220V dalgıç pompanın sigortası atar. Yeraltında 10 ton mazotunuz vardır ama jeneratörün üstündeki 200 litrelik tank kuruduğu için motor stop eder.

İşte mühendislik simülasyonları ile sahanın acımasız fiziği arasındaki uçurum tam olarak bu küçük detaylarda gizlidir.

Sertifika Pazarlaması vs. Operasyonel Dayanıklılık

Türkiye'deki veri merkezi ekosisteminde son yıllarda tehlikeli bir "sertifika fetişizmi" türedi.

Şirketler milyonlarca dolar harcayarak uluslararası denetçileri çağırıyor, bina projelerini onaylatıp Tier sertifikası alıyorlar. Bunu da müşteriye bir "asla çökmeyiz" garantisi gibi pazarlıyorlar.

Oysa Uptime Institute'un kendisi bile açıkça belirtir: Tier sertifikası binanın tasarım ve inşaat topolojisini belgeler; o tesisi işleten insanların operasyonel disiplinini, bakım kalitesini ve kriz anındaki reflekslerini garanti edemez.

Eğer jeneratörün marş akülerini iki yıldır ölçmediyseniz, transfer şalterinin mekanik testini düzenli yapmadıysanız ve yakıt tankının dibinde biriken suyu tahliye etmediyseniz; dünyanın en pahalı Tier IV tesisinde bile elektrik kesildiğinde karanlığa gömülürsünüz.

Gerçek Güvence Sahada Yazılır

Altyapı mühendisliği, slaytlarda kusursuz görünen mimarilere körü körüne inanmamaktır.

Gerçek bir sistem yöneticisi veya tesis mühendisi; şebekenin her an kopabileceğini, jeneratörün marş basmayabileceğini ve mazot tankerinin gelmeyebileceğini hesaba katarak yaşayan insandır.

• Acil durum yakıt senaryolarınızı test edin.
• Yılda en az bir kez şebeke şalterini bilerek indirip, sistemin tam yük altında jeneratöre geçişini canlı canlı izleyin.
• Yerel akaryakıt istasyonlarıyla şahsi ilişkilerinizi ve alternatif tedarik rotalarınızı hazır tutun.

Çünkü kriz anında sizi kurtaracak olan şey duvardaki parlak çerçeveli sertifikalar değil; depodaki mazotun temizliği, jeneratörün marş sesi ve elinde fenerle koşan o fedakar altyapı mühendisinin soğukkanlılığıdır.

Algoritmalar, tasarım kalıpları (design patterns), JSON nesneleri, asenkron fonksiyonlar ve Docker container'ları... Geliştirici kodu yazar, yerel bilgisayarında test eder, git push komutunu verir ve kahvesini yudumlar.

Eğer bir döngü biraz verimsiz yazılmışsa veya veritabanına indeks atmak yerine tüm tablo taranıyorsa (full table scan), geliştiricinin tepkisi genelde o meşhur rahatlık olur: "Aman ne olacak canım, bulutta kaynak sınırsız, CPU yetmezse iki çekirdek daha açarız, bellek nasılsa ucuz."

Ancak o kod satırları derlenip veri merkezindeki fiziksel bir sunucunun silikon çiplerine ulaştığı anda, soyut yazılım dünyası biter; termodinamiğin, elektriğin ve acımasız fizik yasalarının dünyası başlar.

Yazılımcının "küçük bir dikkatsizlik" dediği o optimize edilmemiş sonsuz döngü veya N+1 veritabanı sorgusu; sunucudaki çift soketli 64 çekirdekli AMD EPYC veya Intel Xeon işlemcilerin tüm çekirdeklerini %100 yüke kilitler. İşlemcinin TDP (Termal Tasarım Gücü) değeri bir anda 280 Watt'tan 500 Watt'a fırlar.

Sunucunun anakartı, RAM blokları ve güç kaynakları şebekeden çılgınca amper çekmeye başlar.

Ve ay sonunda şirket yönetiminin önüne gelen fatura, o kodu yazan yazılımcının bir yıllık maaşını geride bırakan devasa bir elektrik ve soğutma faturasına dönüşür:

"Elektrik faturası, kodun kendisinden pahalı hale gelmiştir."

Kalbe Aşırı Yüklenip Miyokardı Yoran Tedavi Hatası

Bu fiziksel bedelin insan fizyolojisindeki ve yoğun bakımdaki karşılığı son derece nettir.

Kalp yetmezliği veya koroner arter hastalığı olan bir hastayı düşünün. Hekim hastanın tansiyonunu hızlıca yükseltmek veya idrar çıkışını artırmak için kontrolsüzce yüksek doz adrenalin ve aşırı serum yüklemesi yapar.

Kısa vadede monitörde tansiyon yükselmiş gibi görünür; hekim kendince "hastayı toparladım" sanır.

Oysa hastanın göğüs kafesinin içinde bir felaket pişmektedir: Kalp kası (miyokard), o yapay kimyasal baskı yüzünden dakikada 160 atımla delicesine çalışmakta, hücrelerin oksijen ihtiyacı tavan yapmaktadır. Koroner damarlar bu çılgın talebi karşılayamaz; kalp kası oksijensiz kalarak nekroza gider ve hasta masada kardiyak arreste girer.

Yazılımda da CPU'yu kontrolsüzce %100'e kilitleyen bir kod; sunucunun kalbini ve ciğerlerini aşırı oksijen tüketimine zorlayan o bilinçsiz tedaviye benzer. İşlemci sadece kendisi yanmakla kalmaz; çevresindeki tüm altyapı ekosistemini de beraberinde tüketir.

PUE Çarpanı: Çekilen Her 1 Watt İçin Harcanan 1 Watt Daha!

Yazılımcıların çoğu veri merkezlerinin enerji ekonomisindeki en kritik metriği bilmez: PUE (Power Usage Effectiveness - Güç Kullanım Verimliliği).

PUE şu basit formülle hesaplanır:
Toplam Tesis Gücü / Bilişim Ekipmanı Gücü

İdeal bir dünyada bu oran 1.0 olmalıdır; yani çekilen tüm elektrik doğrudan sunuculara gitmelidir. Ancak gerçek hayatta, özellikle Türkiye'deki ortalama veri merkezlerinde PUE oranı 1.5 ila 1.8 arasındadır!

Bu ne anlama gelir?

Sizin yazdığınız verimsiz bir SQL sorgusu yüzünden sunucunuz fazladan 10 kW elektrik çektiğinde; veri merkezi o sunucunun yaydığı termal ısıyı dışarı atabilmek için Hassas Klimalara (CRAC), chiller ünitelerine ve fanlara fazladan 7 ila 8 kW elektrik harcamak zorundadır!

Yani sizin ekranda "küçük bir gecikme" olarak gördüğünüz o CPU yükü; veri merkezinin trafosunda iki katı büyüklüğünde bir enerji tüketimine, soğutma kompresörlerinin yıpranmasına ve binlerce kilovatsaatlik bir çevre kirliliğine yol açmaktadır.

"Milisaniyeler vs. Kilovatsaatler" Uçurumu

Yazılım mühendisliği eğitimi veren üniversitelerde öğrencilere algoritma karmaşıklığı (Big-O Notation) anlatılırken genelde "zaman karmaşıklığı" (Time Complexity) üzerinde durulur: "Bu algoritma O(n) mi, O(n^2) mi çalışıyor?"

Fakat kimse şu soruyu sormaz: "Bu algoritmanın karbon ayak izi ve watt/saat maliyeti nedir?"

• Kötü yazılmış bir regex (düzenli ifade) yüzünden CPU'nun Catastrophic Backtracking'e girmesi,
• Bellekte tutulabilecek 5 KB'lık bir referans verisi için her HTTP isteğinde veritabanına gidip disk I/O'su yaptırmak,
• Gereksiz mikroservis çağrılarıyla sunucuların ağ kartlarını ve serialization motorlarını ısıtmak...

Bunların her biri birer mühendislik günahıdır.

Ve bu günahların bedeli artık sunucuların sınırsız olduğu Silikon Vadisi fantezileriyle ödenemez; Türkiye'de sanayi elektriğinin kilovatsaatinin her geçen gün zamlandığı o sert ekonomik gerçeklikle ödenir.

Yeşil Kod (Green Coding) ve Mühendislik Ahlakı

Mühendislik; bir problemi sadece "çalıştırmak" değil, o problemi en az enerji, en az kaynak ve en yüksek zarafetle çözebilme sanatıdır.

Kıdemli bir mühendis olmanın eşiği; terminale yazdığı tek bir satır kodun veri merkezindeki soğutma kulelerinde kaç litre su buharlaştırdığını, panodaki kaç amperi tetiklediğini ve şirketin elektrik faturasını nasıl şişirdiğini hissedebildiği andır.

• Kodunuzu profillemeyi (profiling) alışkanlık haline getirin.
• CPU döngülerini ve bellek tahsislerini (allocation) birer enerji tüketim kalemi olarak görün.
• Veritabanı sorgularınızı indekslerle hafifletin; disk I/O'sunu ve CPU çekirdeklerini dinlendirin.

Çünkü ekrandaki milisaniyeleri önemsemeyen bir yazılımcı; sadece kötü bir mühendis değil, veri merkezinin cebini ve gezegenin enerjisini sessizce kemiren görünmez bir maliyet ortağıdır.

Eğer tesis yeni kurulmuşsa; her şey bir sanat galerisi gibi tertemizdir. Mavi, sarı ve turuncu renk kodlu patch kabloları milimetrik kıvrımlarla kablo düzenleyicilerden (cable organizer) geçirilmiş, cırt cırtlı bantlarla (velcro) demetlenmiş, her iki ucu numaralandırılmış etiketlerle mühürlenmiştir. Fotoğrafını çekip LinkedIn'e koysanız binlerce beğeni alacak bir mühendislik zerafeti vardır.

Fakat aynı odaya aradan iki yıl geçtikten sonra girdiğinizde karşılaştığınız şey çoğu zaman bir sanat eseri değil; bir İtalyan spagetti tabağı cehennemidir.

Kabinlerin önünden ve arkasından sarkan, birbirine kördüğüm olmuş yüzlerce metrelik kablo yığınları...

Sarı fiber kabloları ezen kalın siyah güç kabloları, etiketleri kopmuş veya üzerine tükenmez kalemle anlaşılmaz karalamalar yapılmış hatlar, sunucu kızaklarının arasından rastgele geçirilmiş ve kabin kapağının kapanmasını engelleyen derme çatma bağlantılar...

Herhangi bir sunucuyu kızaktan öne doğru çekmeye kalktığınızda, o kablo ormanı gerilir; yanlışlıkla komşu bir sunucunun güç fişini yerinden oynatır veya hassas bir fiber optik ucunu çıt diye kırar.

İşte yazılım dünyasında soyut kavramlarla anlattığımız "Teknik Borç" (Technical Debt) olgusunun fiziksel evrendeki somut, elle tutulur ve gözle görülür en acımasız heykeli bu kablo cehennemidir.

Yoğun Bakımda Birbirine Düğümlenen İnfüzyon Hatları

Bu altyapı karmaşasının acil servisteki veya yoğun bakım ünitesindeki yansıması ölümcül bir kabustur.

Politravma veya çoklu organ yetmezliğiyle yoğun bakımda yatan kritik bir hastayı düşünün. Hastanın vücuduna bağlı onlarca medikal hat vardır:

• Boynundaki santral venöz kateterden giren 4 farklı damar içi ilaç,
• Sol koldaki periferik damar yolu,
• Sağ koldaki invaziv arteriyel tansiyon izleme hattı,
• Göğsündeki EKG elektrot kabloları,
• Parmaktaki pulse oksimetre sensörü,
• Solunum cihazının kalın plastik hortumları ve idrar sondası...

Eğer o nöbetteki hemşireler ve sağlık personeli titiz davranmamış, o hatları serum askılarında renk kodlarına göre ayırmamış ve sabitlememişse; saatler içinde hastanın yatağının çevresi tam bir kablo ve hortum kördüğümüne döner.

Ve gece saat 03:00'te o hasta aniden kardiyak arreste (kalp durmasına) girdiğinde ne olur?

Hekim içeri fırlar: "Acil 1 mg intravenöz adrenalin yapın!"

Hemşire panikle enjektörü eline alır; fakat hangi hattın hangi ilaca gittiğini, hangi lümenin açık olduğunu o düğümün içinde bulamaz! Kabloları çekiştirirken arteriyel hat yerinden çıkar, etrafa kan fışkırır. Adrenalin hastanın kalbine 20 saniye içinde ulaşması gerekirken; o kördüğümün içinde harcanan 3 dakika, hastanın geri dönüşümsüz beyin ölümüyle sonuçlanır.

Fiziksel karmaşa; kriz anında reaksiyon süresini öldüren en sinsi cellattır.

"Yarın Düzenleriz" Yalanının Anatomisi

Peki o pırıl pırıl kurulan sunucu kabinleri nasıl bu hale gelir?

Cevap, Türk iş hayatının ve mühendislik kültürümüzün en ölümcül cümlesinde yatar: "Şimdilik idareten takalım, yarın sabah mesai başladığında düzenleriz."

Senaryo hep aynıdır:

1. Gece 02:15: Kritik bir switch portu yanar veya bir müşterinin sunucu bağlantısı kopar. Nöbetçi mühendis panikle yedek parça arar. Kablo kanalından düzgünce hat çekmeye üşenir; çünkü uykusuzdur ve sistemin acilen ayağa kalkması gerekmektedir.
2. Geçici Çözüm: Depodan bulduğu 5 metrelik fazla uzun bir CAT6 kablosunu kabinin dışından, sunucuların ön yüzünden geçirerek doğrudan takar. Işıklar yeşile döner, sistem ayağa kalkar. Mühendis "Tamam, sabah sakin kafayla bunu kanala alır, etiketini basarım" diyerek evine gider.
3. Unutulma Evresi: Sabah olduğunda yeni toplantılar, yeni Jira biletleri ve yeni krizler başlar. O "geçici" kablo orada kalır.
4. Kaskat Yıkım: İki hafta sonra başka bir mühendis başka bir acil durum için bir kablo daha sallar. Üç ay sonra yeni bir sunucu eklenirken kablolar üst üste atılır.

Ve bir yılın sonunda; kimsenin dokunmaya cesaret edemediği, hangi kablonun nereye gittiğini kimsenin bilmediği o dokunulmaz tabu yaratılmış olur.

Spagetti Kod ile Spagetti Kablo Arasındaki Kardeşlik

Bir şirketin veri merkezindeki kabin arkalarına bakın; o şirketin yazılım mimarisi hakkında tek bir satır kod görmeden kesin bir teşhis koyabilirsiniz.

• Eğer kabinlerin arkası dağınıksa, kablolar etiketlenmemişse ve geçici çözümler kalıcı hale gelmişse; o şirketin kod tabanı da TODO: burayı sonra düzelteceğiz yorumlarıyla dolu, testleri yazılmamış ve monolitik spagetti bloklarla boğulmuş bir çöplüktür.
• Çünkü disiplin bölünemez bir karakterdir.

Fiziksel dünyada elindeki kabloyu doğru kanaldan geçirmeye, etiketini basmaya ve fazlalığını toplamaya üşenen bir mühendis; kod yazarken de fonksiyonunu modüler hale getirmeye, hata durumlarını yönetmeye ve dokümantasyon yazmaya üşenir.

Kabin arkasındaki karmaşa, o ekibin zihinsel dağınıklığının ve yönetimsel disiplinsizliğinin doğrudan 3 boyutlu bir projeksiyonudur.

Kabloyu Toplamak Zihni Toplamaktır

Altyapı mühendisliğinde profesyonellik; kriz anında bile o 5 dakikalık disiplinden ödün vermemektir.

• Geçici kablo yoktur; her takılan hat ilk andan itibaren kalıcıymış gibi kanala yerleştirilmeli ve etiketlenmelidir.
• Yan keskiyle kabloları boğan sert plastik kelepçeleri (zip-tie) çöpe atın; esnek, sökülüp takılabilen cırt cırtlı bantlar (velcro) kullanın.
• Her kablonun uzunluğunu mesafesine göre özel sonlandırın (crimping yapın); 50 santimetrelik mesafeye 3 metrelik kablo kıvırıp kabin içine tıkıştırmayın.

Unutmayın; kablo düzeni bir takıntı veya görsel lüks değildir.

Kriz anında doğru porta saniyeler içinde müdahale edebilmenin, yanlış kabloyu çekip şirketi karartmamanın ve mühendislik mesleğine duyulan saygının en temel fiziki göstergesidir.

Kişisel Verileri Koruma Kurumu (KVKK), Bankacılık Düzenleme ve Denetleme Kurumu (BDDK), Türkiye Cumhuriyet Merkez Bankası (TCMB) ve Cumhurbaşkanlığı Dijital Dönüşüm Ofisi'nin yayımladığı genelgeler son derece açık ve tavizsiz bir sınır çizmiştir:

"Bankacılık, ödeme sistemleri, sağlık ve kamuya ait kritik veriler ile vatandaşların kişisel finansal kayıtları Türkiye Cumhuriyeti sınırları içindeki veri merkezlerinde barındırılmak zorundadır."

Bu yasa çıktığı gün; Türkiye'deki yerel veri merkezi işletmecileri ve bulut sağlayıcıları için gökten zembille inmiş muazzam bir nimet, tarihin en büyük pazar fırsatı doğdu.

Yıllardır Amazon Web Services (AWS), Google Cloud (GCP) veya Microsoft Azure'a milyonlarca dolar akıtan yerli bankalar, devasa e-ticaret platformları, sigorta şirketleri ve fintek girişimleri; ceza yememek ve lisanslarını kaybetmemek için gözlerini mecburen yerli sağlayıcılara çevirmek zorunda kaldılar.

Devlet, yerel teknoloji sermayesinin önüne aşılması imkansız bir koruma kalkanı örmüş, müşteriyi zorla onların kapısına yönlendirmişti.

Peki, aradan geçen yılların ardından yerli bulut sağlayıcıları bu altın fırsatla ne yaptı?

Gerçekten AWS'ye rakip modern, otonom, yönetilen (managed) bulut servisleri mi inşa ettiler? Yoksa bu yasal tekelin rehavetine kapılıp, müşteriyi "pahalı birer ham disk ve sanal sunucu kiralayıcısı" olarak görmeye devam mı ettiler?

Cevap ne yazık ki modern teknoloji tarihimizin en büyük hayal kırıklıklarından biridir.

İthal İlaç Yasağı ve 50 Yıllık Aspirine Sığınan İlaç Fabrikası

Bu tembelliğin tıp ve sağlık sektöründeki karşılığını çok iyi biliyoruz.

Devletin kamu bütçesini ve yerli sanayiyi korumak amacıyla yabancı kanser ve biyoteknoloji ilaçlarının ithalatına ağır kotalar veya yasaklar getirdiğini düşünün. Hekimlere ve hastanelere "Artık yabancı ilaç alamayacaksınız, sadece yerli üreticiden temin edeceksiniz" denmiştir.

Bu durum yerli ilaç sanayisi için ne olmalıdır? Laboratuvarlara kapanmak, biyokimyagerleri toplamak, Faz çalışmalarını başlatmak ve dünyanın en modern moleküllerini sentezlemek için tarihi bir motivasyon olmalıdır.

Peki yerli üretici ne yapar?

Nasılsa rekabet yok, nasılsa devlet müşteriyi mecbur kıldı diyerek; yeni hiçbir ilaç geliştirmeye bütçe ayırmaz. 50 yıllık ilkel aspirini allayıp pullar, kutusunu değiştirir ve kanser hastalarının önüne "Yerli ve milli ilacımız budur, başka çareniz yok" diye fahiş fiyattan koyar. Sonuç? Hasta modern tedaviden mahrum kalır, bilimsel gelişme durur ve koruma kalktığı gün o fabrika ilk rüzgarda iflas eder.

İşte Türkiye'deki yerli bulut ekosisteminin önemli bir kısmının düştüğü tuzak tam olarak bu ilaç fabrikası rehavetidir.

Global Bulut Bir "Sunucu" Değil, Bir Ekosistemdir

Yerli sağlayıcıların anlamakta en çok zorlandığı gerçek, modern yazılım dünyasında "Cloud" kavramının artık fiziksel sunuculardan ibaret olmadığıdır.

Bugün bir yazılım mimarı AWS veya GCP kullandığında; oradan sadece bir Ubuntu sanal makinesi (EC2) kiralamaz. O mimar;

• Tek tıkla ayağa kalkan, otomatik ölçeklenen, yedeklemesi ve failover'ı yönetilen veritabanları (Aurora, Cloud Spanner),
• Sunucusuz çalışan ve sadece çağrıldığında fatura kesen hesaplama motorları (Lambda, Cloud Run),
• Dağıtık kuyruk ve mesajlaşma servisleri (SQS, Kafka MSK, Pub/Sub),
• Petabaytlarca veriyi milisaniyelerde tarayan veri ambarları (BigQuery, Redshift),
• Ve yapay zeka modellerini doğrudan eğitebilecekleri hazır API altyapıları satın alır.

Peki yerli veri merkezinin kapısını çalan bir fintek mimarının karşısına ne çıkar?

Eski bir VMware vCenter arayüzü!

Önünüze bir form konur: "Kaç vCPU istersiniz? Kaç GB RAM olsun? Kaç GB SAS disk verelim?"

Hepsi bu kadar!

Veritabanı mı kuracaksınız? Kendiniz kurup yöneteceksiniz. Yedekleme mi lazım? Kendi bash script'inizi yazacaksınız. Kubernetes mi istiyorsunuz? Master node'ları manuel ayağa kaldırıp ağ ayarlarıyla gecenizi gündüzünüzü heba edeceksiniz.

Müşteriye sunulan tek şey, 2010 yılından kalma ilkel bir "hosting ve sanal sunucu satıcılığı"dır. Ve bu ilkellik, küresel standartların üç katı fiyatına, sırf "KVKK'ya uygundur" damgasıyla fatura edilmektedir.

Mevzuat Bağımlılığı ve İnovasyonun İflası

Bir sektörü ayakta tutan şey inovasyon, kalite ve müşteri memnuniyeti değil de sadece devlet regülasyonu ise; o sektör eninde sonunda çürümeye mahkumdur.

Bugün Amazon veya Microsoft, Türkiye sınırları içine kendi bağımsız "AWS Europe (Istanbul)" veya "Azure Turkey" veri merkezi bölgelerini (Region) açtığı gün ne olacaktır?

O gün, KVKK kalkanının arkasına saklanıp on yıldır tek bir satır yerli API geliştirmeyen, müşteriye kaba davranan ve teknik destek biletlerine 3 günde dönen yerli firmaların tamamı birkaç ay içinde müşteri tabanını kaybedecektir. Çünkü zorunluluk bittiği an, kalitesizlik affedilmez.

Yerli Bulutun Geleceği: Sadece Disk Değil, Akıl Satmak

Türkiye'nin kendi verisini kendi sınırları içinde tutma vizyonu son derece meşru, stratejik ve milli bir güvenlik meselesidir. Buna hiç kimse itiraz edemez.

Ancak bu vizyon; yerel sermayedarların müşteriyi sömüreceği bir tekel rantına dönüştürülemez.

Yerli bulut sağlayıcılarının kurtuluşu; VMware lisanslarının arkasına saklanıp disk boyutu satmaktan vazgeçmekle başlar.

• Kendi açık kaynak tabanlı (OpenStack, Ceph, Kubernetes) modern yönetim katmanlarını geliştirmek,
• Gerçek "Serverless" ve "Managed Database" API'lerini yerli mühendislerle inşa etmek,
• Ve müşteriye "mecbur olduğun için buradasın" kibriyle değil, "dünyanın en iyi mühendislik deneyimini sunduğumuz için buradasın" vizyonuyla yaklaşmak zorundadırlar.

Mevzuat sizi bir yere kadar taşır; ama tarihte hiçbir teknoloji şirketi yasaların zoruyla kalıcı olamamıştır.

Kaliteyi inşa etmeyenler, eninde sonunda tarihin tozlu raflarında unutulmuş birer pahalı disk deposu olarak kalmaya mahkumdur.

"Bu tesisi nereye kuracağız?"

Bir taraf haritayı açar, parmağını İstanbul'un göbeğine koyar:
"Finansın kalbi burada, bankaların genel müdürlükleri burada, telekom operatörlerinin ana internet değişim noktaları (IXP) burada. İstanbul'da kurmazsak gecikme (latency) süresini 2 milisaniyenin altına indiremeyiz, müşteriyi ikna edemeyiz."

Masanın diğer tarafındaki jeoloji ve risk analisti derin bir iç çeker, parmağını Marmara Denizi'nin altından geçen o kırmızı çizginin üzerine vurur:
"İyi ama Kuzey Anadolu Fay Hattı kırıldığında, beklenen 7.5 büyüklüğündeki büyük Marmara depreminde o binaların, enerji nakil hatlarının ve fiber borularının ayakta kalacağını kim garanti edebilir? Milyarlarca liralık veriyi aktif bir fayın kucağına mı yatıracağız?"

Ve o an başlar o bitmek bilmeyen sosyo-ekonomik ve lojistik satranç:
İstanbul'un finansal çekimi ile Anadolu'nun sarsıntısız ovaları arasındaki büyük gerilim.

Sahra Hastanesini Fay Hattına Kurmak mı, Ulaşımsız Vadiye mi?

Bu stratejik açmazın acil tıp ve afet yönetimindeki analojisi hayati bir denge sınavıdır.

Büyük bir afet bölgesinde ana travma merkezini veya tam teşekküllü bir sahra hastanesini nereye konuşlandıracaksınız?

Eğer hastaneyi yıkımın ve enkazın tam ortasına, fay hattının sıfır noktasına kurarsanız; ilk büyük artçı sarsıntıda hastane binanız da çöker, hekimleriniz enkaz altında kalır ve yaralılara yardım edecek tek bir merci bulamazsınız.

Peki hastaneyi "aman depremden uzak olsun" diyerek şehirden 80 kilometre uzakta, dağların arkasında sarsıntısız bir yaylaya kurarsanız ne olur?

Bu kez de ambulanslar o mesafeyi kat edemez, yollar kapandığı için ağır iç kanaması olan yaralılar hastaneye ulaşamadan yolda hayatını kaybeder.

İdeal sahra hastanesi; afet bölgesine lojistik olarak hızla ulaşılabilecek kadar yakın, ama sarsıntının yıkıcı etkisinden korunacak kadar sağlam bir jeolojik zeminde olmak zorundadır.

Veri merkezinin konumu da tam olarak bu afet hastanesi dengesidir: Veri trafiğine milisaniyeler kadar yakın, ama coğrafi risklerden kıtalar kadar uzak olmak zorundasınızdır.

Üç Şehir, Üç Kader: İstanbul, Bursa/Gebze, Kayseri/Ankara

Türkiye'de veri merkezi haritasına baktığınızda üç ana hattın birbirleriyle yarıştığını görürsünüz:

1. İstanbul Cazibesi ve Varoluşsal Tehdit: Türkiye'nin toplam internet trafiğinin %70'inden fazlası İstanbul'da döner. Sunucunuzu Maslak, Ümraniye veya Yenibosna'da bir tesise koyduğunuzda; bankalara ve son kullanıcıya 1-3 ms gecikmeyle ulaşırsınız. Ancak yüksek arsa maliyetleri, aşırı pahalı sanayi elektriği, trafo kapasite yetersizlikleri ve hepsinin üzerinde sallanan o devasa deprem tehdidi İstanbul'u pimi çekilmiş bir el bombasına dönüştürür.
2. Gebze - Bursa Sanayi Koridoru (Yarı Güvenli Geçiş): İstanbul'un hemen çıkışında, organize sanayi bölgelerinin (OSB) yüksek elektrik altyapısını ve ana fiber omurgalarını kullanan bir geçiş hattı. Arsa daha geniştir, enerjiye erişim daha kolaydır. Ancak Marmara fay hattı bu bölgenin de hemen altından geçmektedir; yani risk minimize edilmiş değil, sadece ötelenmiştir.
3. Kayseri, Konya ve Ankara Platosu (Jeolojik Kale vs. Lojistik Bedel): Türkiye'nin deprem tehlike haritasında en risksiz, bembeyaz görünen o masif İç Anadolu ovaları. Zemin sağlamdır, deprem riski sıfıra yakındır, arsa ucuzdur. Ancak bu kez karşınıza başka duvarlar dikilir:
   • Gecikme (Latency) Maliyeti: Kayseri'deki bir sunucudan İstanbul'daki bir kullanıcıya erişim 12-15 ms sürer. Yüksek frekanslı finansal işlemler (HFT) veya anlık e-ticaret için bu süre bazen kabul edilemez bulunur.
   • Nitelikli Personel Eksikliği: Gece 03:00'te çöken bir BGP router'a veya soğutma kompresörüne müdahale edecek üst düzey uzman personeli Anadolu şehirlerinde istihdam etmek zordur.
   • Fiber Altyapı Monopolü: Türk Telekom veya diğer operatörlerin Anadolu'daki transit fiber hatlarının yedekliliği İstanbul kadar zengin değildir; tek bir karayolu kazısında hatların kopma riski daha yüksektir.

"Tek Bir Sepet" İntiharı

Türkiye'deki pek çok holdingin ve kamu kurumunun yaptığı en büyük stratejik hata; hem ana sistemlerini (Production) hem de sözde felaket kurtarma merkezlerini (Disaster Recovery - DR) aynı coğrafi havzanın içine tıkıştırmaktır.

Ana sunucu Gayrettepe'de, yedek sunucu Kartal'dadır!

Marmara Denizi'nde 7.5 büyüklüğünde bir deprem olduğunda; iki bina arasındaki o 30 kilometrelik mesafenin hiçbir hükmü kalmayacaktır. Şehir şebekesi çöktüğünde, fiber boruları koptuğunda ve yollar yarıldığında iki tesis de aynı saniyede sessizliğe gömülecektir.

Coğrafi Dağıtık Gelecek

Gerçek kurumsal olgunluk; coğrafi kaderi inkar etmekle değil, onu mimarinin bir parçası kılmakla başlar:

• Aktif-Aktif (Active-Active) Dağıtık Mimari: Verinizi tek bir binaya değil; İstanbul'un hızını Kayseri veya Ankara'nın jeolojik güvenliğiyle senkronize eden hibrit omurgalar üzerine kurun.
• Kritik transactional verilerinizi sarsıntısız Anadolu kalelerinde güvene alın; önbellek (cache) ve kenar (edge) servislerinizi kullanıcıya yakın lokasyonlarda koşturun.

Veri merkezi sadece betondan, demirden ve klimadan ibaret bir bina değildir.

Veri merkezi; yeraltındaki tektonik plakaların, dağların arasından geçen fiber optik cam liflerinin ve o coğrafyanın sosyo-ekonomik kaderinin kesiştiği stratejik bir kaledir. Ve o kaleyi nereye kurduğunuz, kriz günü geldiğinde ya tarihinizi kurtarır ya da tüm dijital varlığınızı toprağın altına gömer.

Hesaplamalı Akışkanlar Dinamiği (CFD) yazılımlarıyla simülasyonlar yapılmıştır. Ekranda rengarenk hava akış çizgileri dans eder:
Mavi renkli soğuk hava, yükseltilmiş tabanın (raised floor) altındaki menfezli karolardan pürüzsüzce yükselir; kabinlerin ön yüzündeki sunucuların fanları tarafından emilir; silikon çipleri soğutup arkadaki kırmızı renkli "Sıcak Koridora" (Hot Aisle) üflenir ve oradan tavan aspiratörleriyle Hassas Klimalara (CRAC) geri döner.

Her şey milimetrik hesaplanmıştır. Koridorların başlarına şık pleksiglas otomatik kapılar takılır, adına "Cold Aisle Containment" (Soğuk Koridor Kapatma) denir. İçeri girdiğinizde yüzünüze çarpan o 19 derecelik tatlı serinlik, mühendislik dehasının bir zaferi gibi görünür.

Ancak o tesise altı ay sonra, canlı sistemlerin tam yük altında çalıştığı sıcak bir yaz günü girdiğinizde; gözlerinizi ovuşturarak izleyeceğiniz bir termodinamik felaketle karşılaşırsınız.

Klimanın göstergesi 18 dereceyi göstermektedir; soğuk koridor kapalıdır; fakat 3 numaralı kabinin tam ortasındaki depolama sunucusunun (storage) fanları delicesine bağırmakta, sunucunun IPMI arayüzünde kırmızı alarmlar yanıp sönmektedir:

"CPU Temp: 92°C - Thermal Throttling Activated!"

Milyonlarca dolarlık iklimlendirme yatırımı yapılmış o odanın içinde; nasıl olur da tek bir sunucu kendi sıcaklığında kavrulup kapanma noktasına gelebilir?

Cevap, veri merkezi mühendisliğinin en acımasız dersinde gizlidir: O sunucunun hemen altındaki boş 1U'luk yuvaya takmayı unuttuğunuz (veya üşendiğiniz) 2 dolarlık plastik kapatma paneli (blanking panel).

Ameliyathanenin Pozitif Basıncını Bozan Açık Kapı

Bu termodinamik fiyaskonun cerrahi ameliyathanelerdeki karşılığı doğrudan ölümcül bir enfeksiyon skandalıdır.

Modern hastanelerin ameliyathaneleri "pozitif hava basıncı" ve tavan tipi laminar akım sistemleriyle donatılmıştır. Ameliyathane odasının içindeki hava basıncı, dışarıdaki koridorun basıncından daima yüksek tutulur. Amaç şudur: Kapı açıldığında bile dışarıdaki mikroplu hava içeri giremesin; içerideki steril hava dışarı doğru üflensin ve hastanın açık batınına tek bir mikrop bile konmasın.

Şimdi bir ameliyathane görevlisinin veya cerrahın; "Hava çok sıcak oldu, içerisi biraz ferahlasın" diyerek ameliyathanenin kapısına bir takoz koyup aralık bıraktığını hayal edin.

O saniyede tüm fizik kanunları tersine döner. Pozitif basınç çöker; koridordaki tozlar, hastane bakterileri ve mantar sporları o aralıktan içeri hücum eder. Cerrah hastayı kusursuz dikmiş olabilir; ancak ameliyat edilen hasta üç gün sonra hastane enfeksiyonundan hayatını kaybeder.

Milyon liralık HEPA filtreleme sistemini çöp eden şey teknik bir arıza değil; o kapıyı aralık bırakan basit bir dikkatsizliktir.

Veri merkezindeki soğuk koridor da tam olarak bir ameliyathanedir.

Termodinamik Kısa Devre (Recirculation)

Fizikte hava, her zaman en az direnç gösteren yolu seçer.

Sunucunun içindeki minik fanlar havayı önden arkaya doğru iterken, sunucunun arkasında 45 ila 50 dereceye ulaşan bir sıcak hava basıncı oluşturur.

Eğer kabinde iki sunucu arasında boş bırakılmış 1U veya 2U'luk (yaklaşık 4.4 - 8.8 cm) bir delik varsa ve orası plastik bir kapakla kapatılmamışsa; doğanın en temel yasası devreye girer:

Arkada sıkışan o 50 derecelik sıcak hava, tavandaki klimaya doğru yükselmek yerine; o boş delikten bir hortum gibi öne, soğuk koridorun içine doğru geri emilir!

Buna termodinamikte "Hava Kısa Devresi" (Recirculation) denir.

Sonuç nedir?

• O 1U'luk deliğin hemen üstünde duran masum sunucu; altındaki soğuk havayı değil, arkadan öne fışkıran o 50 derecelik cehennem havasını doğrudan kendi işlemcisine emer.
• Soğuk koridorun genel sıcaklığı 20 derece olsa bile; o kabinin tam önünde 42 derecelik izole bir "Sıcak Nokta" (Hotspot) oluşur.
• Ve o sunucunun işlemcisi kendini yakmamak için frekansını yarıya düşürür (thermal throttling); veritabanı kilitlenir, müşterilerin siteleri donar.

Tüm bu felaketin tek müsebbibi ise; "Aman altı üstü bir parmak boşluk, ne olacak canım" diyerek o plastik parçayı çöpe atan dikkatsiz saha teknisyenidir.

2 Dolarlık Parçaya Karşı Milyonluk Klimalar

Türkiye'deki veri merkezlerinde en sık rastlanan yönetimsel basiretsizliklerden biri; sıcaklık problemini klimanın gücünü artırarak çözmeye çalışmaktır.

Sunucu ısındığı için alarm çalar. Tesis müdürü koşar; klimaların ayarını 22 dereceden 16 dereceye indirir. Chiller kompresörleri delicesine çalışmaya başlar, elektrik faturası ikiye katlanır.

Fakat sunucu soğumaz!

Çünkü siz odayı kutup soğuğuna çevirseniz bile; o delikten arkadan öne dönen havanın sıcaklığı değişmez. Sorun odanın soğuk olmaması değil; soğuk havanın sunucunun ağzına ulaşamadan sıcak havayla zehirlenmesidir.

Odaya fazladan 50 kW klima gücü basmak yerine; nalburdan alacağınız 50 liralık kapatma panelini o deliğe taktığınız anda, sunucu sıcaklığının 10 dakika içinde 90 dereceden 55 dereceye düştüğünü görürsünüz.

Mühendislik bazen devasa makineler çalıştırmak değil; havanın yolunu doğru tıkamayı bilmektir.

Disiplin Detaylarda Saklıdır

Gerçek altyapı uzmanlığı, gösterişli sunumlarda değil; kabinin içindeki o minik detaylara gösterilen özende ortaya çıkar:

• Kabindeki her boş U yuvasına istisnasız Blanking Panel takın.
• Kablo geçiş fırçalarını (cable brush) delikli bırakmayın; tabandan gelen havanın kaçmasına izin vermeyin.
• Sunucu raylarını ve montaj kulakçıklarını hava kaçırmayacak contalarla sıkıştırın.

Unutmayın; termodinamik kanunları rüşvet kabul etmez, unvan tanımaz ve ihmali affetmez.

Milyon dolarlık soğutma kulelerinizin kaderi; takmaya üşendiğiniz o küçük plastik parçanın ucunda sallanır. Ve o parçayı önemsemeyen bir mühendis, er ya da geç kendi yarattığı sıcak noktanın içinde yanmaya mahkumdur.

Oysa o piksellerin ekranda akmasını sağlayan şey gökyüzündeki beyaz bulutlar değildir; yerin metrelerce altında veya sanayi sitelerinin kuytu köşelerinde kurulu, penceresiz, devasa çelik binalardır.

Ve o binaların içinde, kamuoyunun adını bile bilmediği, LinkedIn'de parlak unvanlarla alkışlanmayan bir grup insan nefes almaktadır: Veri Merkezi Saha Mühendisleri ve Teknisyenleri.

Dışarıdan bakan birisi için onların işi "soğuk klimalı ofiste oturup sunuculara bakmak" gibi görünebilir.

Ancak o çelik kapıyı açıp sunucu odasına (white space) adımınızı attığınız anda; insan biyolojisinin sınırlarını zorlayan, bedeni ve ruhu sessizce kemiren ağır bir endüstriyel gerçeklik yüzünüze çarpar.

85 Desibellik Kesintisiz Cehennem ve Tinnitus Kabusu

Odaya girdiğinizde ilk dikkatinizi çeken şey sessizlik değil; kulaklarınızı patlatırcasına uğuldayan o devasa gürültü duvarıdır.

Bir sunucu kabininde tek bir 1U sunucunun içinde, çapı sadece 4 santimetre olan 6 ila 8 adet fan bulunur. Bu fanlar işlemciyi soğutabilmek için dakikada 12.000 ila 16.000 devirle (RPM) döner.

Şimdi tek bir odada bu sunuculardan binlercesinin aynı anda çalıştığını, arkada devasa Hassas Klimaların (CRAC) kompresörlerinin ve hava basma fanlarının kükrediğini hayal edin.

Ortamdaki ses basıncı ortalama 85 ila 95 desibel (dB) arasındadır!

90 desibel, bir dizel lokomotifin veya çalışan bir çim biçme makinesinin hemen yanında durmaya eşdeğer bir gürültü seviyesidir. Ve veri merkezi personeli, bu gürültünün içinde 8 saat, bazen 12 saatlik vardiyalar boyunca çalışmak zorundadır.

Yıllarca bu ortamda çalışan bir teknisyenin karşılaşacağı ilk bedensel fatura işitme kaybı ve kalıcı kulak çınlamasıdır (Tinnitus).

Mühendis akşam evine gider, yatağa yatar; ancak kulaklarının içindeki o 10.000 devirlik sunucu fanının tiz çığlığı asla susmaz. Sessizlik, o insan için artık sonsuza kadar kaybedilmiş bir cennettir.

Yoğun Bakımdaki "Alarm Yorgunluğu" ve Duyusal Aşırı Yüklenme

Bu tükenmişliğin acil tıp ve yoğun bakım servislerindeki analojisi "Alarm Yorgunluğu" (Alarm Fatigue) sendromudur.

Bir yoğun bakım hemşiresinin veya nöbetçi asistanının ortamını gözünüzün önüne getirin.

Yatak başı monitörlerinin bip sesleri, mekanik ventilatörün nefes verme tıslamaları, infüzyon pompalarının hata alarmları, defibrilatörün kendi kendini test etme sinyalleri... Ortamda saniyede onlarca akustik ve görsel uyaran yanıp söner.

İlk birkaç aydan sonra sağlık çalışanının beyni bu aşırı uyarana karşı bir savunma mekanizması geliştirir: Duyusal hissizleşme.

Personel alarmları duymamaya, sesleri algılamamaya başlar. Bu durum sadece personelin psikolojisini bozup kronik anksiyeteye sürüklemekle kalmaz; gerçek bir ölümcül ventriküler fibrilasyon alarmının o gürültü kaosunda gözden kaçmasına ve hastanın kaybedilmesine yol açar.

Veri merkezinde de aynı duyusal körelme yaşanır. Fanların o monoton ve delici gürültüsü; insanın odaklanma yeteneğini parçalar, bilişsel hızını yavaşlatır ve personeli kronik bir baş ağrısı ve asabiyet sarmalına hapseder.

18 Derecelik Yapay Kutup Soğuğu ve Kas Spazmları

Veri merkezlerinde hava sıcaklığı insan konforuna göre değil, silikon çiplerin termal sağlığına göre ayarlanır: Sabit 18 ila 20 derece.

Üstelik bu durağan bir soğukluk değildir; delikli karolardan saatte binlerce metreküp hızla üflenen yüksek hızlı bir hava akımıdır (draft).

Temmuz ayında dışarıda hava 38 derece iken, teknisyen sırtında polarlar ve kışlık montlarla bu buz odasına girer. Günde onlarca kez 38 derece ile 18 derece arasında gidip gelen bir bedenin termoregülasyon sistemi felç olur.

• Kronik kas spazmları,
• Boyun ve bel fıtıkları,
• Yüz felci riskleri,
• Ve henüz 30'lu yaşlarda başlayan kronik romatizmal ağrılar...

Sunucular üşümesin diye dondurulan o odalar, aslında içinde çalışan insanların eklemlerini ve kaslarını sessizce çürütmektedir.

Zamansızlık ve Penceresiz İzolasyon Odası

Bir veri merkezinin mimarisinde fiziksel güvenlik ve termal yalıtım gereği asla pencere bulunmaz.

İçeriye girdiğinizde dış dünya tamamen yok olur.

Güneş mi açtı, kar mı yağıyor, gece mi oldu gündüz mü; anlamanız imkansızdır. Başınızın üzerinde sadece soğuk beyaz LED veya floresan tüpleri parlar.

12 saatlik gece vardiyalarında çalışan bir mühendis; insan biyolojisinin en temel saati olan sirkadiyen ritmini tamamen kaybeder. Melatonin salgısı durur, uyku düzeni paramparça olur. Dış dünyadan, mevsimlerden ve zamandan koparılmış bu klostrofobik izolasyon; personelde derin bir tükenmişlik, yabancılaşma ve depresyon tablosu doğurur.

Görünmeyen Emeğe Saygı: İSG Bir Lüks Değildir

Türkiye'deki veri merkezi işletmecilerinin çoğu maalesef bu tabloyu bir "işin doğası" olarak görmekte ve personelin sağlığını görmezden gelmektedir.

Oysa alınacak tedbirler son derece basittir:

1. Zorunlu İşitme Koruması: Sunucu odasına kulaklıksız girmek yasaklanmalı; personele sadece basit sünger tıkaçlar değil, endüstriyel aktif gürültü engelleyici (ANC) kulak koruyucular zimmetlenmelidir.
2. Vardiya ve Dinlenme Sınırları: Beyaz alanda kesintisiz kalma süresi maksimum 2 saatle sınırlandırılmalı; personelin dinlenme odaları gün ışığı alan, sessiz ve ergonomik alanlara taşınmalıdır.
3. Fiziki Ergonomi: 80 kiloluk sunucuları iki büklüm kaldırmaya çalışan teknisyenler için sunucu kaldırma liftleri (server lift) standart hale getirilmelidir.

Telefonumuzda her gün sorunsuz açılan o web sayfalarının arkasında; soğuktan parmakları uyuşmuş, kulakları çınlayan ve güneş ışığına hasret kalan gencecik insanların alın teri vardır.

Ve teknolojinin en büyük sınavı; sistemleri ayakta tutarken, o sistemleri omuzlarında taşıyan insanları tüketmemeyi başarabilmektir.

Sistem mimarı tahtaya çıkar; projenin ihtiyaç duyduğu kurumsal sunucu konfigürasyonunu yazar: Çift AMD EPYC işlemci, 256 GB ECC RAM, NVMe kurumsal depolama dizisi ve yedekli güç kaynakları.

Yetkili distribütörden gelen resmi proforma faturaya bakılır: 18.500 Dolar! (Yani güncel kurla 600 bin TL'nin üzerinde.)

Patronun tansiyonu anında 18'e fırlar: "Delikanlı sen delirdin mi? Bir demir kutuya 600 bin lira mı vereceğiz? Ben o parayla şirkete sıfır servis minibüsü alırım!"

Patron hemen cebinden telefonunu çıkarır, Türkiye'nin o meşhur sarı ilan sitesine (Sahibinden) veya Forum Donanım/R10 ikinci el ilanlarına girer. Arama kutusuna yazar: "Dell PowerEdge R720 / R730 - Temiz, az kullanılmış kurumsal sunucu."

İlan bulunur: 2014 yılından kalma, Avrupa'daki bir bankanın veri merkezinde 6 yıl boyunca 7/24 çalıştıktan sonra hurdaya ayrılmış, metal kasasında çizikler olan, fanları yorgunluktan inleyen 10 yıllık emektar bir sunucu.

Fiyatı: 35.000 TL!

Patron zafer kazanmış bir fatih gibi göğsünü kabartır: "Gördün mü ticari zekayı? Senin 600 bin lira dediğin aletin aynısını 35 bine çözdüm. Kalan parayla da ofise yeni deri koltuk takımı alıyoruz!"

Sunucu alınır. Veri merkezindeki kabine vidalanır. Şirketin tüm e-ticaret veritabanı, müşteri kayıtları ve fatura altyapısı bu 10 yıllık hurdanın kucağına bir bebek gibi bırakılır.

Ve o gün; şirket yönetiminin farkında olmadığı tek bir gerçek vardır: O kabinin içine bir sunucu değil, pimi çekilmiş ve saati rastgele kurulmuş bir saatli bomba yerleştirilmiştir.

Çıkmacıdan Alınan Fren Hortumuyla 112 Ambulansı Sürmek

Bu kumarın acil sağlık hizmetlerindeki yansımasını hayal edin.

İl sağlık müdürlüğünün veya özel bir ambulans şirketinin yöneticisi; bütçe tasarrufu yapmak adına acil yardım ambulanslarının bakımını yetkili servise yaptırmak yerine oto sanayi sitesindeki "çıkmacılara" (hurdacılara) götürüyor.

Ambulansın aşınmış fren disklerini, hidrolik hortumlarını ve direksiyon kutusunu; kaza yapmış pert arabalardan sökülen, garanti süresi dolmuş, metal yorgunluğu tavan yapmış hurda parçalarla yeniliyorlar. Yönetici gururla bütçeyi yarıya indirdiğini iddia ediyor.

Peki iki hafta sonra ne olur?

O ambulans, arka kabininde kalp krizi geçiren bir hastayı hastaneye yetiştirmek için sirenleri açmış, 130 km hızla yağmurlu bir viraja girdiğinde; o çıkma fren hortumu yüksek basınca dayanamayarak aniden patlar!

Frenler boşalır. Ambulans taklalar atarak bariyerlere çarpar. İçindeki hasta, paramedik ve şoför feci şekilde hayatını kaybeder.

O gün o savcı mahkemede yöneticiye "Neden sıfır parça kullanmadın?" diye sorduğunda, yöneticinin "Ama bütçemiz çok kısıtlıydı, çıkma parça çok ucuzdu" demesi onu cinayetten kurtarabilir mi?

İşte bir şirketin canlı üretim (production) ortamını 10 yıllık ikinci el donanımlara emanet etmesi; o ambulansın frenini çıkmacıdan almakla aynı derecede ahlaksız ve tehlikeli bir kumardır.

Sessiz Katiller: Kurumuş Kapasitörler ve Lehim Çatlakları

Mühendislikten anlamayan tüccar zihniyeti sanır ki; bir bilgisayar donanımı arabalar gibi kilometre yapmaz, dolayısıyla aşınmaz. "Çip bu, aşınır mı hiç, elektrik verince çalışıyor işte" derler.

Oysa donanımın içinde zamanla ölen gizli biyokimyasal ve fiziksel mekanizmalar vardır:

1. Elektrolitik Kapasitörlerin Kuruması: Güç kaynaklarının (PSU) ve anakartların üzerinde voltajı filtreleyen kimyasal kapasitörler bulunur. 7 yıl boyunca 60 derece sıcaklıkta kesintisiz çalışan bir kapasitörün içindeki sıvı elektrolit zamanla kurur. Kapasitör şişer ve bir gece ansızın patlar! Patladığı an şebekeden gelen 220 voltluk akımı doğrudan işlemciye ve RAM'lere basar; sunucunun tüm içi kömür haline gelir.
2. Termal Yorgunluk ve Mikro Lehim Kırıkları (Micro-Fractures): Yıllarca ısınıp soğuyan BGA çipset lehimleri gevrekleşir. Gözle görülmeyen kılcal bir çatlak yüzünden; SAS backplane kartı diski aniden hattan düşürür. Veritabanı "I/O Error" verir ve veri bozulması (silent corruption) başlar.
3. Firmware ve BIOS Desteğinin Bitmesi (EOL): Üretici o sunucunun desteğini 5 yıl önce kesmiştir. Yeni keşfedilen kritik işlemci açıklarına (Spectre, Meltdown vb.) karşı yama çıkmaz. Sunucunuz tüm siber korsanların önüne açık bir hedef olarak sunulur.

Tasarruf İllüzyonunun Acı Faturası

O 35 bin liralık hurda sunucu, şirkete ilk arızasında neye mal olur?

Kasım ayındaki "Efsane Cuma" indirim gecesi saat 22:30. Sitede 10 bin anlık ziyaretçi alışveriş yapmaktadır. Yorgun güç kaynağı aşırı akıma dayanamaz ve bir patlama sesiyle dumanlar çıkararak iflas eder. Yedek güç kaynağı da aynı yaştadır; yükün tamamı üzerine bindiği anda o da ikinci saniyede yanar!

Veritabanı çöker. RAID kartının pili (BBU) bitik olduğu için bellekteki (cache) son yazma işlemleri diske aktarılamadan uçup gider.

Site 18 saat boyunca kapalı kalır. Şirketin o gece kaybettiği ciro: 1.5 milyon TL!

Müşterilerin kaybettiği güven ve basına yansıyan itibar kaybı ise parayla ölçülemez.

Patronun o gün tasarruf ettiğini sandığı 500 bin lira; tek bir gecede 3 milyon liralık bir enkaza dönüşmüştür.

Mühendislik Gerçekçilikle Başlar

Bütçeniz kısıtlı olabilir; döviz kuru belinizi büküyor olabilir. Bunlar Türkiye'nin inkar edilemez ekonomik gerçekleridir.

Ancak çözüm, hurdalıklardan sunucu toplamak değildir:

• Eğer donanıma bütçeniz yetmiyorsa, sunucu satın almayın; güvenilir, modern donanımlara sahip yerel veya global bulut sağlayıcılarından kullandıkça öde (pay-as-you-go) modeliyle sanal kaynak kiralayın.
• İkinci el donanımı sadece ve sadece test, geliştirme (staging) veya laboratuvar ortamlarında kullanın.
• Asla ve asla müşterinizin verisini, şirketinizin cirosunu ve mesleki itibarınızı garanti süresi dolmuş, ömrünü tamamlamış hurda silikonların insafına bırakmayın.

Çünkü ucuz donanımla yönetilen bir production ortamı; hiçbir zaman bir mühendislik başarısı değil, sadece patlayacağı günü bekleyen acıklı bir saatli bombadır.

Ekranın tam ortasında şirketin çift omurga anahtarı (Core Switch) ve BGP (Border Gateway Protocol) yönlendiricileri durur. Bu yönlendiricilerden iki kalın, yeşil hat çıkar.

Birinci hat: Türk Telekom (ISP A - 10 Gbps)
İkinci hat: Turkcell Superonline (ISP B - 10 Gbps)

Mühendis sunumda göğsünü kabartarak anlatır: "Sayın yöneticilerim, BGP multi-homing protokolümüz devrededir. Eğer A operatöründe bir kopma veya arıza yaşanırsa, dinamik yönlendirme algoritmamız milisaniyeler içinde tüm trafiği B operatörüne aktarır. Sistemimiz %100 yedeklidir, bizi hiçbir güç internetsiz bırakamaz."

Yönetim kurulu alkışlar. Raporlar dosyalanır. Şirket kendisini dijital bir kale sanmaktadır.

Ta ki sıradan bir salı günü öğleden sonra saat 15:20'ye kadar.

Veri merkezinin bulunduğu caddenin iki sokak ötesinde, ilçe belediyesinin su işleri müdürlüğüne bağlı sarı renkli emektar bir JCB kazı kepçesi kaldırım kenarını kazmaya başlar. Kepçe operatörü gaza basar, çelik dişler toprağın 80 santimetre derinine dalar.

Küt!

Toprağın altından plastik boru parçaları ve saç teli inceliğinde yüzlerce cam lifi fırlar.

Aynı saniyede, veri merkezinin ağ izleme ekranlarındaki tüm grafikler kırmızıya döner:

• BGP Session with ISP-A: DOWN
• BGP Session with ISP-B: DOWN

Tüm sistemler susar. Milyonlarca liralık e-ticaret platformu dünya genelinde erişilmez hale gelir.

Mühendis panik içinde terminale bakar: "Nasıl olur? İki operatörümüz de bağımsızdı, ikisi birden aynı saniyede nasıl çökebilir?!"

Cevap, Türkiye'nin en acımasız ve gizli altyapı gerçeğinde saklıdır: Mantıksal olarak birbirinden tamamen bağımsız olan o iki farklı telekom devinin fiber optik kabloları; caddenin altındaki aynı beton kanalın (künkün) içinden, yan yana geçmektedir!

Beyne Kan Taşıyan İki Şah Damarının Tek Darbeyle Ezilmesi

Bu anatomik yanılsamanın insan biyolojisindeki karşılığı ölümcül bir travma sahnesidir.

İnsan beyni, doğanın en kusursuz yedekli dolaşım sistemine (Willis Poligonu) sahiptir. Beyne oksijen taşımak için boynun sağından ve solundan geçen iki kalın ana arter vardır: Sağ ve Sol Karotis Arterleri (Şah Damarları).

Biri tıkanırsa, diğeri beynin dolaşımını sürdürebilir; doğa sistemi mantıksal olarak çift hatlı tasarlamıştır.

Şimdi bir insanın boynuna önden şiddetli, ezici bir künt darbe (örneğin bir kaza veya boğulma travması) aldığını düşünün.

O iki bağımsız damar boynun ön tarafındaki o daracık anatomik kompartımanda yan yana yer aldığı için; tek bir fiziksel darbe iki şah damarını birden trakeaya (nefes borusuna) doğru ezer ve lümenlerini kapatır. Beyne giden kan akımı sıfıra iner ve 4 dakika içinde geri dönüşsüz beyin ölümü gerçekleşir.

Sistemin "çift damarlı" olması, iki damarın da aynı dar boğazdan geçtiği gerçeğini değiştiremez.

Yazılım ve ağ dünyasında da haritada çizdiğiniz BGP otonom sistemleri (AS Numbers) ve dinamik yönlendirme protokolleri mantıksal birer hayalden ibarettir; gerçek hayatta verinizi taşıyan şey, o kaldırımın altındaki fiziksel cam elyaftır.

Mantıksal Yedeklilik vs. Fiziksel Rota Çeşitliliği (Route Diversity)

Türkiye'de altyapı kuran şirketlerin düştüğü en büyük yanılgı, "İki farklı operatörden fatura almayı fiziksel yedeklilik zannetmektir."

Gerçek bir yedeklilik (True Route Diversity) sağlamak için şu soruların cevabını sahada bizzat gözlerinizle görmek zorundasınızdır:

1. Son Kilometre (Last-Mile) Tuzağı: İki farklı operatör binanıza girerken aynı bina giriş menfezinden (manhole) mi geçiyor? Eğer iki kablo da binanın otoparkındaki aynı plastik borudan giriyorsa, orada çıkacak küçük bir yangın iki hattınızı birden eritir.
2. Kablo Güzergahı Denetimi: Türk Telekom'un fiber hattı caddeyi doğudan mı terk ediyor, Turkcell'in hattı batıdan mı? Eğer iki hat da aynı köprünün altından, aynı viyadüğün kablo tavasından geçiyorsa; o köprüdeki tek bir trafik kazası iki operatörü de aynı anda keser.
3. Farklı Santral (PoP) Çıkışları: İki hattınız şehirdeki iki farklı telekom santraline mi bağlanıyor, yoksa caddenin başındaki aynı gri metal dağıtım kutusunda (saha dolabında) mı sonlanıyor?

Bu soruların peşine düşmeyen bir ağ mühendisi; BGP konfigürasyonuna istediği kadar karmaşık route-map'ler, prefix-list'ler yazsın, kendini sadece bir kepçe operatörünün insafına teslim etmiş bir hayalperesttir.

BGP Kepçeden Anlamaz

BGP protokolü, internetin en zarif yönlendirme mekanizmasıdır. Ağdaki gecikmeleri ölçer, alternatif yolları (AS Path) hesaplar ve saniyeler içinde trafiğin rotasını çevirir.

Fakat BGP, toprağı 2 metre derinlikte yaran 5 tonluk bir kazı kepçesinden anlamaz.

Kablo fiziksel olarak koptuğunda, BGP'nin yapabileceği tek şey çaresizce session'ı düşürmek ve log dosyalarına kırmızı satırlar basmaktır.

Dijital Kalelerin Fiziksel Gerçekliği

Gerçek bir altyapı dayanıklılığı inşa etmek istiyorsanız, terminal ekranından kafanızı kaldırıp sokağa çıkmak zorundasınız:

• Tesisinize giren telekom hatlarının fiziksel kazı projelerini (as-built çizimlerini) operatörlerden talep edin.
• İki hattın binaya tamamen zıt iki coğrafi yönden (Kuzey ve Güney cephelerinden) girdiğinden emin olun.
• Mümkünse karasal fiber hatlarının yanına, fiziksel kazılardan etkilenmeyen bağımsız bir Mikrodalga Radyolink (Microwave Link) veya uydu yedekleme katmanı ekleyin.

Unutmayın; ağ diyagramınız ekranda ne kadar kusursuz görünürse görünsün, sisteminizin gerçek gücü o sokaktaki en dikkatsiz kepçe operatörünün elindeki kumanda kolu kadardır.

Ve fiziksel dünyadaki kör noktalarını görmezden gelen hiçbir mühendislik, dijital dünyada ayakta kalamaz.

Kırk iki U'luk (42U) siyah mat bir kabin. İçindeki her bir sunucu, switch ve patch panel milimetrik bir simetriyle yerleştirilmiştir. Yüzlerce incecik Ethernet ve fiber optik kablosu, bir arpın telleri gibi kusursuz bir kavisle yan kanallara süzülür; hepsi aynı renkte, aynı açıyla bükülmüş, üzerlerine cırt cırtlı bandajlar sarılmıştır. Tek bir milimetrelik sarkma, tek bir renk uyumsuzluğu göremezsiniz.

Altındaki yorumlar övgü doludur: "İşte gerçek mühendislik sanatı! Bunu yapan usta değil, bir heykeltıraştır."

Bu fotoğraflara bakıp büyülenmemek elde değildir.

Ancak o fotoğrafların arkasındaki gerçeği bilen kıdemli bir saha mühendisi, o kareye hafif acı bir tebessümle bakar. Çünkü o kusursuz kabin; ya henüz hiçbir canlı müşterinin bağlanmadığı, üzerinde gerçek bir trafiğin akmadığı steril bir showroom maketidir; ya da bir pazarlama broşürü için saatlerce uğraşılıp fotoğrafı çekildikten sonra kaderine terk edilecek yapay bir vitrindir.

Çünkü gerçek bir veri merkezinin, yaşayan ve nefes alan bir sistem odasının kaderi; o fotoğraf karesinde değil, gece saat 03:45'te patlayan bir kriz anında yazılır.

Estetik Cerrahi Dikişi vs. Acil Serviste Atılan Düğümler

Bu zıtlığın tıp dünyasındaki karşılığı, estetik plastik cerrahi ile acil travma cerrahisi arasındaki o derin uçurumdur.

Bir plastik cerrahın kliniğinde burun veya yüz estetiği ameliyatını izleyin. Cerrah mikroskobik büyütmeli gözlüklerini takar; saç teli inceliğinde 6-0 veya 7-0 monofilaman dikiş iplikleri kullanır. Her bir dikişin aralığını cetvelle ölçer gibi eşit bırakır; düğümleri cildin altına gizler. Çünkü orada amaç sadece yarayı kapatmak değil, arkasında tek bir mikronluk iz bırakmayacak görsel bir mükemmeliyete ulaşmaktır.

Şimdi bu sahneyi kapatın ve acil servisin resüsitasyon odasını açın.

İçeriye pompalı tüfekle vurulmuş, femoral arteri parçalanmış, kanı tavana fışkıran ve tansiyonu 40'a düşmüş bir hasta girer. Hastanın kanı oluk gibi akmaktadır; 60 saniye içinde durdurulamazsa hasta hipovolemik şoktan ölecektir.

Odaya giren genel cerrah ne yapar?

Mikroskobik iplik aramaz, cetvelle mesafe ölçmez! Eline en kalın 1 numara ipeği veya çelik klempi alır; kanayan damarın üzerine acımasızca basar ve saniyeler içinde kalın, kaba, estetikten tamamen uzak ama kanamayı anında kesen o devasa hemostatik düğümü atar!

O dikiş çirkindir, arkasında kalın bir yara izi bırakacaktır; ama o çirkin dikiş bir insanın hayatını kurtarmıştır. Hiçbir hekim kan kaybından ölmek üzere olan hastaya "estetik dikiş atacağım" diye vakit kaybetmez.

İşte kabin içine "aceleyle takılan o sarkık mavi patch kablosu", travma cerrahının attığı o kaba ama hayat kurtarıcı dikiştir.

Gece 03:45: Sistem Çöktüğünde Estetik Ölür

Gece saat 03:45. Şirketin ana ödeme geçidi switch'i aniden çöker. Milyonlarca liralık işlem askıda kalmıştır. Telefonlar susmamaktadır; yönetim kurulu ayaktadır.

Nöbetçi altyapı mühendisi elinde yedek switch ile kabinin önüne koşar. Cihazı acilen vidalar.

Şimdi o mühendisin önünde iki seçenek vardır:

1. Estetik Yolu: Kablo kanallarının vidalarını sökecek, kabloların boyunu tek tek cetvelle ölçecek, soketleri tek tek çakacak, cırt cırtları simetrik dizip kanala yerleştirecektir. Süre: en az 2.5 saat! (Bu esnada şirket 2 milyon TL ciro kaybedecek, müşteriler kaçacaktır.)
2. Pragmatizm Yolu: Depodan bulduğu ilk 3 metrelik mavi CAT6 kablosunu kapacak, kabinin ön yüzünden, sunucuların kapağının arasından çaprazlama geçirip doğrudan porta sokacaktır. Süre: 45 saniye!

Işıklar yeşile döner. Sistem ayağa kalkar. Kriz çözülür.

O an o kabinin önünde sarkan o çirkin, sarkık kablo; sosyal medyadaki hiçbir parlak fotoğraftan daha az değerli değildir. O kablo, ekibin kriz anındaki çevikliğinin ve hayatta kalma refleksinin bir madalyasıdır.

Tehlike Nerede Başlar? "İdareten" Olanın Ebedileşmesi

Peki, estetik düşmanlığı bir erdem midir? Elbette hayır!

Felaket, kriz anında o kabloyu alelacele takmakta değil; o kriz bittikten sonra o kabloyu orada ebediyen unutmaktadır.

Ertesi gün mesai başlar. Kriz atlatılmıştır, ortalık sakinleşmiştir. Ancak kimse o sarkık kabloyu kanala almaya gitmez. İki hafta sonra başka bir kriz çıkar, bir kablo daha çaprazlama asılır. Altı ay sonra kabinin önü bir sarmaşık ormanına döner.

Artık acil müdahale pragmatizmi bitmiş; yerini tembellik, disiplinsizlik ve altyapı cehaleti almıştır. O kablolar birbirine dolandığı için, bir sonraki krizde mühendis doğru porta ulaşamaz hale gelir.

Zanaatkarın Denge Sanatı

Büyük altyapı mühendislerini vasatlardan ayıran şey, bu iki uç arasındaki dengeyi kurabilme olgunluğudur:

• Kriz Anında Pragmatist Olun: Sistem yanarken estetik fetişizmi yapmayın. En hızlı, en güvenli ve en pratik geçici çözümü devreye sokun. Sistemi ayağa kaldırın.
• Barış Zamanında Estetisyen Olun: Fırtına dindiğinde, ortalık sakinleştiğinde o kabinin başına geri dönün. O geçici kabloyu sökün, boyuna göre sonlandırın, kanaldan geçirin, etiketini basın ve sistemi ilk günkü disiplinine kavuşturun.

Kabin içi yerleşim ne sosyal medyaya gösteriş yapılacak sahte bir vitrindir, ne de döküntü bir hurdalıktır.

O kabin; kriz anında hızla müdahale edilebilecek kadar yalın, barış anında ise her bir hattı saniyeler içinde izlenebilecek kadar tertipli olmak zorundadır. Ve gerçek mühendislik, hız ile disiplinin bu kusursuz dengesinde nefes alır.

Tam 4 milyar 294 milyon 967 bin 296 adet tekil IP adresi.

O dönemin soğuk savaş şartlarında, sadece birkaç üniversitenin ve askeri araştırma merkezinin birbirine bağlı olduğu bir dünyada bu rakam akıl almaz bir sonsuzluk gibi görünüyordu. Mühendisler kendi aralarında gülüşüyorlardı: "Dünyadaki tüm bilgisayarları birbirine bağlasak bile bu adres havuzunu tüketmemiz yüzlerce yıl sürer."

Fakat aradan geçen kırk yılda dünya bambaşka bir yere evrildi.

Akıllı telefonlar, akıllı saatler, internete bağlanan buzdolapları, arabalar, sokak lambaları ve milyarlarca insan aynı anda ağa hücum etti. Ve 2010'lu yılların başında, küresel internet tahsis otoritesi IANA ve Avrupa bölge kayıt kuruluşu RIPE NCC o tarihi açıklamayı yaptı:

"Son serbest IPv4 bloğu da tükenmiştir. Artık sıfırdan dağıtılacak tek bir adres dahi kalmamıştır."

İşte o günden sonra, internetin en temel teknik tanımlayıcısı olan IP adresleri; bir mühendislik parametresi olmaktan çıkıp, dünyanın en vahşi, en pahalı ve spekülatif dijital emlak karaborsasına dönüştü.

Organ Nakli Karaborsası ve Kök Hücre Tembelliği

Bu tükenmişlik krizinin tıp dünyasındaki karşılığı trajik bir sağlık açmazıdır.

Dünyada böbrek veya karaciğer yetmezliği çeken yüz binlerce hasta vardır; ancak organ bağışı yapan insan sayısı son derece kısıtlıdır. Organ arzı tükenmiştir. Bu yetersizlik ne doğurur? Ne yazık ki yeraltı organ borsalarını, fahiş fiyatlara satılan organ transferlerini ve çaresiz insanların bu karaborsaya servet dökmesini.

Peki bu esnada modern tıp ne yapmaktadır?

Bilim insanları yıllardır laboratuvarlarda kök hücreden yapay organ üretimi ve biyouyumlu 3D doku baskısı üzerine çalışmakta, neredeyse sınırsız ve reddedilme riski olmayan yeni bir tıp devriminin kapılarını aralamaktadır.

Ancak bazı muhafazakar sağlık sistemleri ve hastaneler; bu yeni teknolojiye yatırım yapıp klinik altyapısını dönüştürmek yerine, eski organ nakli listelerindeki kısıtlı havuzun krizleriyle boğuşmaya devam eder. Çünkü yeni bir standarda geçmek masraflıdır, eğitim gerektirir ve konfor alanını bozar.

İşte küresel internet ekosisteminin ve özellikle Türkiye'deki telekom/hosting sektörünün durumu tam olarak budur.

Elimizde neredeyse evrendeki kum taneleri kadar sınırsız adres alanı sunan, güvenliği ve yönlendirme mimarisi katbekat üstün olan IPv6 (128 bit) teknolojisi yirmi yıldır hazırda beklemektedir. Ancak sektör, bu modern mimariye geçiş için altyapısını dönüştürmeye üşendiği için; tükenmiş IPv4 bloklarının karaborsasında birbirini ezmeye devam etmektedir.

Dijital Emlakçılar ve /24 Blok Borsası

Bugün Türkiye'de veya dünyada yeni bir hosting firması kurmak, veri merkezinde bir kabin kiralamak veya internete çıkış yapmak istediğinizde karşınıza çıkan ilk fatura sunucu masrafı değil, IP bloğu kirasıdır.

• En küçük yönlendirilebilir blok olan tek bir /24'lük blok (toplam 256 adet IP) için bugün piyasada aylık yüzlerce dolar kira veya satın almak isterseniz 12.000 ila 15.000 Dolar arasında nakit para talep edilmektedir!
• Bu durum, internet dünyasında yeni bir asalak sektör doğurmuştur: IP Broker'ları (Dijital Emlakçılar).

Zamanında, internetin ilk yıllarında üniversitelere veya eski şirketlere bedavaya tahsis edilmiş /16'lık (65.536 IP) veya /8'lik (16 milyon IP) devasa bloklar; bugün o eski kurumların kasalarındaki en değerli finansal varlığa dönüşmüştür. Şirketler iflas ederken fabrikalarını değil, ellerindeki IPv4 bloklarını açık artırmada milyonlarca dolara satarak borçlarını kapatmaktadır.

Genç bir girişimci veya küçük bir servis sağlayıcı; sunucuyu, elektriği, fiberi ucuza getirse bile, sırf o IP karaborsasının fahiş fiyatları yüzünden pazara girememekte veya müşterisine yüksek faturalar kesmek zorunda kalmaktadır.

CGNAT Ucubesi: Bir Adrese 500 Kişiyi Sığdırmak

Bu kıtlığın teknik dünyada yarattığı en büyük ucube ise CGNAT (Carrier-Grade Network Address Translation) teknolojisidir.

Operatörler ellerinde IP kalmadığı için ne yapar?

Tek bir gerçek public IP adresinin arkasına, binlerce masum ev kullanıcısını veya müşteriyi tıkıştırırlar. Aynı mahalledeki yüzlerce insan internete aynı IP adresi üzerinden çıkar.

Sonuç?

• Bir kullanıcının yaptığı bir yasadışı işlem yüzünden, aynı IP'yi paylaşan diğer 500 masum kullanıcının e-ticaret sitelerinden banlanması,
• Online oyunlarda port açılamadığı için bağlantıların kopması,
• Şirket içi VPN ve güvenlik sistemlerinin IP çakışmalarıyla kilitlenmesi...

Yani internetin o saf, uçtan uca doğrudan iletişim (end-to-end connectivity) felsefesi; IPv4 inadı yüzünden yamalı bir tüneller labirentine dönüştürülmüştür.

Tembelliğin Sonu: IPv6 Bir Tercih Değil, Zorunluluktur

Türkiye'deki telekom operatörlerine, veri merkezlerine ve şirketlerin ağ yöneticilerine sorsanız hep aynı mazereti duyarsınız: "Hocam bizim müşteriler henüz IPv6 istemiyor, hem eski firewall cihazlarımız tam desteklemiyor, masraf çıkarmayalım."

Bu mazeret, kömürle çalışan buharlı tren çağında "Yolcular henüz elektrikli tren istemiyor, biz kömür yakmaya devam edelim" demek kadar ilkel bir vizyonsuzluktur.

• Google'ın verilerine göre bugün dünyada IPv6 kullanım oranı %45'i aşmıştır. Hindistan, Almanya, Amerika gibi ülkeler trafiğinin çoğunu IPv6 üzerinden akıtmaktadır.
• Türkiye ise bu istatistiklerde ne yazık ki en gerilerde, Afrika ülkeleriyle aynı ligde yer almaktadır.

Dijital geleceğe yatırım yapmak; tükenmiş bir geçmişin karaborsa emlakçılarına servet ödemek değil, altyapınızı çift yığınlı (Dual-Stack) IPv6 mimarisine cesurca geçirmektir.

Geçmişin daracık sokaklarında birbirinizin ayağına basarak yaşamaktan vazgeçin. Geleceğin sınırsız okyanusu kapıda bekliyor; tek yapmanız gereken, eski alışkanlıkların konforundan vazgeçecek mühendislik cesaretini göstermektir.

Kabin içinde parıldayan anahtarlama cihazı (switch) bir Cisco Nexus 9000 veya Juniper QFX serisi omurgadır.

Şirket yönetimi bu cihaza hiç acımadan tam 25.000 Dolar (yaklaşık 800 bin TL) nakit para ödemiştir. Çünkü yönetim kuruluna sunum yapılırken Cisco markası bir itibar ve güven sembolü olarak satılmıştır.

Fakat aynı cihazın ön panelindeki o küçük metal yuvalara, yani fiber optik kabloları bağlayan 10G/25G SFP+ alıcı-verici (transceiver) modüllerine yakından baktığınızda gözlerinize inanamazsınız:

Orijinal Cisco veya Juniper marka bir SFP+ modülün fiyatı 350-400 Dolardır. Satın alma departmanı bu fiyatı görünce dehşete düşmüş, "Altı üstü iki santimlik metal parçası, buna bu para verilir mi?" diyerek internetteki yerli toptancılardan veya Çin'den gelen kargolardan tanesi 12 Dolara ne idüğü belirsiz, üzerinde sahte hologramlar olan "muadil / klon" SFP modülleri sipariş etmiştir.

Yirmi beş bin dolarlık bir teknoloji harikası, on iki dolarlık sahte bir Çin modülünün insafına emanet edilmiştir.

Ve o modülü switch'in yuvasına ilk taktığınız anda, Cisco işletim sistemi (NX-OS) doğası gereği feryat eder:

%ETHPORT-4-IF_UNSUPPORTED_TRANSCEIVER: Transceiver on interface Ethernet1/1 is not supported
%PM-4-ERR_DISABLE: gbic-invalid error detected on Eth1/1, putting Eth1/1 in err-disable state

Cihaz bas bas bağırmaktadır: "Bu modül sahte! EEPROM bilgisi standartlara uymuyor, bunu çalıştırırsam sistemin kararlılığını garanti edemem!"

Peki sahadaki Türk ağ mühendisi ne yapar? Modülü söküp çöpe mi atar?

Hayır! Terminale geçer, Cisco'nun gizli mühendislik komutlarını yazarak cihazın koruma kalkanlarını acımasızca devre dışı bırakır:

switch(config)# service unsupported-transceiver
switch(config)# no errdisable detect cause gbic-invalid

Işık yeşile döner. Link "UP" olur. Mühendis arkasına yaslanır: "Gördün mü bak, halloldu. Orijinaline 400 dolar veren ahmaktır, komutla çalıştırdık işte!"

Oysa o mühendisin bilmediği şey; şirketin tüm dijital omurgasının tam kalbine, ne zaman patlayacağı kestirilemeyen görünmez bir saatli bomba yerleştirdiğidir.

100 Bin Dolarlık Proteze Pazardan Alınan Vidayı Takmak

Bu fantezinin tıp dünyasındaki karşılığı doğrudan bir cinayet davasıdır.

Bir ortopedistin veya kalp-damar cerrahının ameliyata girdiğini düşünün.

Hastanın dizine veya kalbine dünyanın en gelişmiş, İsviçre üretimi titanyum alaşımlı 100 bin dolarlık bir yapay eklem veya mekanik kalp kapakçığı takılıyor.

Tam o protezi kemiğe veya aort damarına sabitleme aşamasına gelindiğinde; hastane satın almasının orijinal cerrahi çelik vidaları çok pahalı bulduğu için sanayideki nalburdan tanesi 50 kuruşa aldığı alelade paslanmaz çelik vidaları cerrahın eline uzattığını hayal edin.

Cerrah "Ne fark eder canım, ikisi de vida işte, tornavidayla sıkınca tutuyor" diyerek o çakma vidayla protezi hastanın kemiğine monte ediyor.

Peki iki ay sonra ne olur?

O ucuz vida vücudun kimyasal ortamında korozyona uğrar, metal yorgunluğundan kırılır. 100 bin dolarlık protez yerinden fırlar, hastanın ana atardamarını parçalar ve hasta iç kanamadan dakikalar içinde can verir.

Milyonluk bir yatırımı 50 kuruşluk sahte bir ara parçayla bağlamak tıp dünyasında nasıl bir delilikse; 25 bin dolarlık omurga cihazını 12 dolarlık sahte SFP ile çalıştırmak da ağ dünyasında aynı derecede vahim bir cinayettir.

Hayalet Arızalar Mezarlığı: Paket Kayıpları ve Termal Kaçış

O sahte SFP modül ilk takıldığında çalışıyor gibi görünür; ancak sahte donanımın bedeli kriz anında, en beklenmedik zamanda ödenir:

1. Termal Dengesizlik ve Optik Bozulma: Orijinal modüller lazer diyotunun gücünü ve sıcaklığını sürekli izleyen dahili bir dijital mikrodenetleyiciye (DOM - Digital Optical Monitoring) sahiptir. 12 dolarlık sahte modüllerde ise bu sensörler ya sahtedir ya da kalibrasyonsuzdur. Trafik yoğunlaştığında modül 70 derecenin üzerine çıkar. Lazerin dalga boyu kayar; ışık gücü (dBm) düşer.
2. Görünmeyen Paket Kayıpları (CRC / Frame Errors): Kablo kopmaz, link yeşil yanmaya devam eder; ancak iletilen ağ paketlerinin her yüz tanesinden beşi o optik parazit yüzünden bozulur. Veritabanı senkronizasyonları yavaşlar, video yayınları donar, API çağrıları time-out'a düşer. Ağ mühendisi günlerce sorunun kaynağını arar; yazılımcıyı suçlar, işletim sistemini suçlar, ama o 12 dolarlık modülden asla şüphelenmez.
3. Switch'in Kontrol Kartını Kilitleyen Hatalar: Sahte modülün kalitesiz I2C veri yolu (bus), switch'in yönetim işlemcisini (ASIC) meşgul eder. Switch'in işletim sistemi bir gün ansızın kernel panic vererek koca kabini yeniden başlatır.

Donanım Bütünlüğü Bir Zincirdir

Ağ mühendisliğinde evrensel bir kural vardır: Bir iletişim hattının güvenilirliği, o hattı oluşturan en zayıf halkanın güvenilirliği kadardır.

• 100 metre boyunca döşediğiniz en pahalı Corning marka zırhlı fiber kablonun,
• O kablonun bağlandığı 25 bin dolarlık Cisco çekirdek switch'in,
• Ve o switch'in arkasında çalışan milyonluk veritabanı sunucularının hiçbir anlamı kalmaz;

Eğer aradaki o 2 santimetrelik optik lazer dönüştürücü, Çin'in merdiven altı bir atölyesinde kalite kontrolünden geçmeden üretilmişse, sisteminiz o atölyenin insafına kalmıştır.

Tasarruf edilecek yer donanımın şah damarı olan fiziksel dönüştürücüler değildir.

Ya bütçenizi cihazın orijinal aksesuarlarına göre planlayın; ya da üreticisi tarafından test edilmiş, programlanabilir, kurumsal seviyede garantili optik altyapılar kullanın.

Çünkü kriz anında service unsupported-transceiver komutu sizi kurtaramaz; geriye sadece ekranda kırmızı yanan o sahte modül ve arkasından gelen milyonluk kesinti faturaları kalır.

"Hot-Swappable Components: Disks, Fans, and Redundant Power Supplies can be replaced without shutting down the system."

Yani üretici der ki: "Korkma delikanlı. Sunucunu kapatmana, sistemini kesintiye uğratmana gerek yok. Cihaz canlı yayındayken, saniyede yüz bin istek işlenirken; arızalanan diski, duran fanı veya yanan güç kaynağını mandalından tut, çek çıkar ve yenisini tak. Sistem kılını bile kıpırdatmadan çalışmaya devam edecektir."

Bu cümleyi ofiste otururken, kahvenizi yudumlarken okuduğunuzda son derece rasyonel, güven verici ve modern gelir.

Ancak gece saat 02:45'te, bir veri merkezinin o buz gibi soğuk koridorunda, üzerinde ülkenin en büyük bankasının veya e-ticaret devinin canlı veritabanını koşturan çift soketli devasa bir depolama sunucusunun önünde durduğunuzda; işler katalogdaki gibi yürümez.

Sunucunun ön panelinde onlarca yeşil ışık delicesine yanıp sönmektedir. SAS disklerin kafaları saniyede binlerce kez diske vurmakta, metal kasa titreşmektedir. Ve 7 numaralı disk yuvasının üzerinde o meşhur sarı/kehribar arıza ışığı sabit yanmaktadır.

Elinizi o diskin plastik mandalına uzatırsınız.

İşaret parmağınız mandalın mandal tetiğine değer. Ve tam o an, zaman yavaşlar. Kalp atışınız dakikada 140'a fırlar. Parmak uçlarınız buz keser.

Zihninizde o sinsi, dehşet verici sorular yankılanmaya başlar:

• "Ya bu disk aslında arızalı değilse ve ben yanlış diski çekiyorsam?"
• "Ya mandalı çektiğim an oluşan mikro voltaj dalgalanması SAS backplane kartını kısa devre yaptırırsa?"
• "Ya RAID kartı diskin çıktığını algılayamayıp tüm array'i offline'a çekerse?"
• "Ya ben bu diski çektiğim anda tüm sistem aniden karanlığa gömülürse ve şirket batarsa?!"

İşte "Hot-Swap" teknolojisi, kağıt üzerinde bir mühendislik standardı; sahadaki insan içinse saf bir soğukkanlılık, cesaret ve adrenalin testidir.

Çalışan Kalpte Bypass Cerrahisi (Off-Pump CABG)

Bu yüksek gerilimin tıp dünyasındaki karşılığı, kalp cerrahisinin en üst düzey ve en stresli ameliyatlarından biridir: Off-Pump (Atan Kalpte) Koroner Arter Bypass Cerrahisi.

Geleneksel açık kalp ameliyatlarında hasta kalp-akciğer pompasına bağlanır; kalbi potasyum solüsyonuyla tamamen durdurulur. Kalp hareketsiz, kan akışı durmuş bir et parçası haline gelir ve cerrah rahatça, sakin kafayla damarları diker.

Ancak bazı yüksek riskli hastalarda (örneğin aortu kireçlenmiş veya akciğeri zayıf yaşlı hastalarda) kalbi durdurmak hastanın bir daha asla uyanamaması demektir.

Bu durumda cerrah ne yapar?

Kalbi hiç durdurmaz!

Kalp dakikada 80 kez kasılmaya, göğüs boşluğunda zıplamaya ve etrafa kan pompalamaya devam ederken; cerrah o atan kalbin üzerine özel ahtapot vantuzlar koyarak damarın sadece 1 santimetrelik bölgesini stabilize eder. Ve o atan, kıpırdayan dokunun üzerine, saç teli inceliğindeki dikişlerle yeni bir koroner damar diker!

O cerrahın ameliyat esnasındaki tansiyonunu ve zihinsel yükünü hayal edin: Tek bir milimetrik titreme, iğnenin aortu yırtması ve hastanın ameliyathanenin tavanına fışkıran kanla 10 saniye içinde kaybedilmesi demektir.

Canlı prod sunucusundan disk çekmek de tam olarak dijital dünyanın "atan kalpte ameliyatıdır."

Sistemin şalterini indirip (down-time alıp) sakin kafayla parça değiştirmek herkesin yapabileceği bir iştir. Gerçek zanaat; sistem tüm hızıyla nefes alıp verirken, tek bir veri paketini yere düşürmeden o organ naklini canlı canlı yapabilmektir.

O 3 Saniyelik Fiziksel Tereddüt

O mandalı çekmeden hemen önceki 3 saniye; sahadaki mühendisin tüm mesleki kariyerinin, tecrübesinin ve dikkat düzeyinin gözlerinin önünden bir film şeridi gibi geçtiği andır.

Bir anlık dikkatsizlikle;

• Slot 0 yerine yanlışlıkla hemen yanındaki Slot 1'in mandalını açarsanız,
• Rebuild (yeniden yapılanma) sürecinde olan bir RAID dizisinin sağlam diskini çekerseniz,
• O an tüm array çöker ve dakikalar içinde terabaytlarca veritabanı uçup gider.

Bu yüzden saha mühendisliği literatüründe yazılı olmayan ama kanla yazılmış altın bir kural vardır: "Read Twice, Confirm Thrice, Pull Once" (İki kez oku, üç kez doğrula, bir kez çek!).

1. iDRAC/iLO yönetim arayüzünü açın.
2. Arızalı diskin fiziksel yuva numarasını (Slot ID) ve seri numarasının son 4 hanesini teyit edin.
3. Yönetim panelinden "Blink / Identify" komutunu vererek arızalı diskin LED ışığını mavi renkte delice yanıp söndürün.
4. Gözlerinizle o mavi yanan ledi bulun. Seri numarasını kasadaki etiketle karşılaştırın.
5. Ve derin bir nefes alıp; mandalı tek bir kararlı, pürüzsüz ve tereddütsüz hareketle kendinize doğru çekin.

Çıt Sesi ve Gelen O Büyük Rahatlama

Mandal açılır. SAS konnektörünün dişleri yuvadan ayrılır. Diskin motorunun devri kademeli olarak düşer (spin down).

Ve arka planda sunucunun diğer diskleri delice çalışmaya devam eder. Terminale bakarsınız:

Disk 0:1:7 removed. RAID array degraded, operating normally.

O an; omuzlarınızdaki tonlarca yükün bir anda kalktığını, ciğerlerinize tekrar oksijen dolduğunu hissedersiniz. O 3 saniyelik korku filmi bitmiş; yerini modern mühendisliğin o kusursuz mimarisine duyulan derin bir hayranlığa bırakmıştır.

Yeni diski kızağa yerleştirirsiniz, yuvaya itersiniz. Mandalı kilitlersiniz. Bir saniye sonra yeni diskin yeşil ışığı yanıp sönmeye başlar: Rebuilding %0...

Korku Değil, Saygı

Hot-swap parçalardan korkmak bir zayıflık değildir; aksine, çalışan bir sisteme ve taşınan veriye duyulan derin bir mühendislik saygısıdır.

Asıl tehlikeli olan; o mandalları hiçbir kontrol yapmadan, sanki evdeki oyun konsolunun kolunu çıkarıyormuş gibi fütursuzca çeken cahil cesaretidir. Çünkü o cesaret, er ya da geç bir şirketin tüm kurumsal hafızasını toprağa gömer.

Korkunuzu kaybetmeyin; o korku sizin en büyük güvenlik kalkanınızdır.

Ancak o korkunun sizi felç etmesine de izin vermeyin. Prosedürleri harfiyen uygulayın, seri numaralarını üç kez okuyun ve o mandalı çekerken zanaatınıza güvenin.

Çünkü atan bir kalbin üzerinde damar dikebilenler, ancak krizlerin ortasında dimdik ayakta kalabilir.

İşte modern bir Tier-3 veri merkezinde gazlı yangın söndürme sisteminin —ister FM-200 (HFC-227ea) olsun, ister Novec 1230— yanlışlıkla devreye girmesi, o hastane odasındaki panikten yüz kat daha yıkıcı, yüz kat daha gürültülü ve donanım açısından tam anlamıyla ölümcül bir kabustur.

Çünkü veri merkezlerinde yangın söndürme sistemleri, sunucuları korumak için oradadır; fakat tek bir yanlış tetikleme anında, o sistemin kendisi sunucuların celladına dönüşür.

Geri Sayımın Başladığı O Otuz Saniye

Bir veri merkezi beyaz odasında (white space) sessizlik aslında hiçbir zaman mutlak değildir; binlerce sunucu fanının çıkardığı homojen, boğuk bir jet motoru uğultusu vardır. Ancak bu uğultuyu bıçak gibi kesen bir şey duyarsanız —o iki tonlu, kulak zarını delen mekanik tahliye sireni ve tavan köşelerinde yanıp sönen flaşörler— omuriliğinize anında saf bir hayatta kalma refleksi pompalanır.

Sistem iki kademeli doğrulamayla (cross-zone smoke detection) çalışır. Tavan panellerindeki optik duman dedektörleri ve hava kanallarından sürekli numune çeken VESDA (Very Early Smoke Detection Apparatus) lazer tüpleri aynı anda partikül yakaladığında kontrol paneli kararını verir: Yangın var.

Eğer bu partikül gerçek bir alevden değil de, asma tavan üstünde fiber çeken taşeron teknisyenin matkapla deldiği alçıpan tozundan, ya da klima bakımında kullanılan kimyasal spreyin buharından kaynaklanıyorsa; önünüzde odadan çıkmak veya kapı kenarındaki sarı renkli mekanik "Abort" (durdurma) butonuna basmak için tamı tamına 30 saniyeniz vardır.

Sahada o butona yetişemediğiniz an, fizik kuralları devreye girer.

Akustik Kıyamet: Gaz Değil, Ses Öldürür

Genel kanı, gazlı söndürme sistemlerinin odadaki oksijeni emerek donanımı boğduğu yönündedir; oysa modern temiz gazlar (Clean Agents) zincirleme kimyasal reaksiyonu termal düzeyde kırarak alevi söndürür, ortamdaki insanı doğrudan boğmaz. Asıl felaket, gazın kendisi değil, tüplerden çıkış şeklidir.

Duvar kenarında dizili devasa çelik tüplerde 25 ile 42 bar (yaklaşık 360-600 PSI) basınç altında sıvılaştırılmış halde bekleyen tonlarca gaz, patlayıcı bir selenoid valf ile serbest bırakılır. Gaz, tavan dağıtım borularından odanın nozullarına (discharge nozzles) hücum eder ve saniyeler içinde gaz fazına geçerek odaya püskürür.

Bu püskürme anında çıkan ses, fırlatılan bir roketin kalkış gürültüsüne eşdeğerdir: 130 desibelin üzerinde.

İşte bu ses, kabinlerin içinde dönen kurumsal mekanik diskler (HDD) için doğrudan bir ölüm fermanıdır:

1. Rezonans ve Titreşim: Mekanik disklerin içindeki okuma-yazma kafaları (read/write head), dönen manyetik disk plakasının sadece birkaç nanometre üzerinde manyetik hava yastığı sayesinde adeta süzülür. İnsan saç telinin binde biri kadar bir mesafedir bu.
2. Akustik Şokun Kafayı Vurması (Head Crash): Nozuldan 130 desibel basınçla fışkıran ses dalgaları, disklerin metal kasasını titretir. Bu rezonans frekansı, kafanın mikroskobik dengesini bozar. Kafa plakaya çarpar (head crash), manyetik yüzeyi çizer veya kontrol çipi sarsıntı yüzünden kafayı acil iniş yuvasına (park zone) çeker.
3. Toplu I/O Çöküşü: Birkaç saniye içinde odadaki tüm storage üniteleri, SAN cihazları ve yedekleme sunucularındaki binlerce SAS/SATA disk aynı anda I/O hatası vermeye başlar. RAID dizileri birbiri ardına düşer, veritabanları "corrupt" olur, işletim sistemleri read-only moda kilitlenir.

Yıllar önce Avrupa'daki devasa bir finans merkezinde yaşanan gaz boşalması vakasında, hiçbir alev veya ısı olmamasına rağmen, sadece nozul gürültüsünün yarattığı akustik şok yüzünden odadaki disklerin yüzde kırkının fiziksel olarak kullanılamaz hale geldiği kayıtlara geçmiştir. Yangından korunsun diye trilyonlarca lira yatırılan veri, söndürücünün sesiyle paramparça olmuştur.

Pozitif Basınç ve Kilitlenen Kapılar

Felaket bununla da sınırlı kalmaz. Tonlarca sıvılaştırılmış gazın on saniye içinde gaz haline geçip odaya yayılması, odanın içinde muazzam bir pozitif hava basıncı yaratır.

Eğer veri merkezinin dış cepheye veya koridora bakan duvarlarında bu aşırı basıncı tahliye edecek mekanik panjurlar (pressure relief dampers) yoksa veya kirden/bakımsızlıktan sıkışmışsa, o basınç odanın zayıf noktalarını aramaya başlar:

• Yükseltilmiş taban karoları yerinden fırlayıp havaya uçar.
• Asma tavan panelleri kabinlerin üzerine çöker.
• Ve en kötüsü: İçe doğru açılan çelik yangın kapıları, içerideki basınç yüzünden öyle bir gerilir ki, dışarıdan asılsanız da içeriden itseniz de açamazsınız. İçeride kalan personel, kulak zarlarını patlatan o sis bulutunun içinde basınç dengelenene kadar kilitli kalır.

İki Gramlık İhmalin Trilyonluk Faturası

Bir veri merkezinde yangın söndürme tüplerini yeniden doldurmak (refill) basit bir yangın tüpü doldurmaya benzemez. Sertifikalı Novec veya FM-200 gazının tekrar tedarik edilmesi, tüplerin tartılması, boru hatlarının test edilmesi ve sistemin yeniden devreye alınması haftalar sürer ve tek başına yüz binlerce dolarlık bir fatura çıkarır.

Bunun üzerine devre dışı kalan depolama ünitelerini, veri tabanı onarımlarını ve müşterilere ödenen SLA cezalarını eklediğinizde; felaketin faturası akıl almaz boyutlara ulaşır.

Peki bu felaketler neden olur?
Yüzde doksanı "insan faktörü" ve "ihmal" yüzündendir:

• Kabin odasında spiral taşla kablo kanalı kesen taşeronun duman sistemini izole etmemesi,
• Bakım moduna (Maintenance / Disarmed mode) alınmadan dedektörlerin yanında temizlik yapılması,
• Eski ve kalibrasyonu yapılmamış dedektörlerin toz birikintisini duman zannetmesi.

Sistem Güvenliğinin Çift Taraflı Kılıcı

Mühendislikte her güvenlik önlemi, içinde kendi felaket potansiyelini barındırır. Uçaklardaki acil çıkış kaydıraklarından, nükleer santrallerin kontrol çubuklarına kadar; "en kötü senaryoyu engellemek" için kurulan agresif sistemler, yanlış çalıştıklarında senaryonun kendisinden daha büyük bir enkaz bırakabilirler.

Acil serviste asistoli alarmını duyduğunuzda yapacağınız ilk iş panikle elektroşoku basmak değil; bir saniye durup hastanın nabzına ve kablonun ucuna bakmaktır.

Veri merkezinde de aynı kural geçerlidir: Söndürme sisteminizin nozullarına susturucu (acoustic silencer nozzle) takmıyorsanız, VESDA sensörlerinizin bakım protokollerini günlük ibadet gibi işletmiyorsanız ve odada yapılacak en ufak bir matkap işinde sistemi "Manuel/Abort" moduna alacak disipline sahip değilseniz; yangından değil, yangın alarmınızdan korkun.

Çünkü duman sunucuyu belki yavaş yavaş ısıtır; ama otuz saniyelik bir sahte alarm, tüm veri dünyanızı tek bir nefeste yutabilir.

Fakat gerçek hayatta sahaya çıktığınızda acı bir manzarayla karşılaşırsınız: Yıllarca kimsenin dokunmadığı el telsizlerinin nikel-kadmiyum bataryaları kimyasal olarak ölmüştür, dağ başındaki telsiz rölesinin aküleri altı aydır kontrol edilmemiştir ve en kritik kriz anında mandalı sıktığınızda hoparlörden sadece hışırtı yükselir. Kurtarıcı olarak köşede beklettiğiniz o "yedek can damarı", günlük hayatta test edilip beslenmediği için tam da ona muhtaç olduğunuz saniyede kucağınızda can verir.

Sistem mühendisliğinde ve veri merkezi operasyonlarında bu durumun birebir kopyası olan bir kavram vardır: Out-of-Band (OOB) Yönetim Ağı.

Bir mühendis için dünyadaki en çaresiz an; prodüksiyon ağı yerle bir olduğunda, sunucuların iDRAC veya iLO konsollarına erişmek için açtığı OOB VPN tünelinin sonsuz bir "Connection Timed Out" hatasıyla yüzüne kapanmasıdır.

Cankurtaran Filikası Mimarisi

Normal şartlar altında bir sunucunun iki temel ağ dünyası vardır:

1. In-Band (Prodüksiyon Ağı): Müşteri trafiğinin aktığı, 10G/25G/100G fiber arayüzlerin çalıştığı, BGP anonslarının yapıldığı, Kubernetes pod'larının haberleştiği otoyol.
2. Out-of-Band (Yönetim Ağı): İşletim sisteminden tamamen bağımsız, anakart üzerindeki özel bir mikrodenetleyici (Dell iDRAC, HP iLO, Supermicro IPMI) ile çalışan; sunucu kapalıyken bile elektriği varsa çalışan, BIOS ayarlarını değiştirebilen, sanal medya takabilen ve cihazı uzaktan yeniden başlatabilen arka kapı.

Tasarım felsefesi çok basittir: Ön kapı alev alsa bile, arka yangın merdiveninden içeri sızabilmelisiniz. Bir switch üzerinde yanlış bir VLAN konfigürasyonu yaptığınızda, bir firewall kuralıyla SSH portunu kaza ile dış dünyaya kapattığınızda veya çekirdek (kernel) panikleyen bir sunucuyu hard-reset ile ayağa kaldırmak istediğinizde tek sığınağınız bu OOB ağıdır.

Fakat pratikte Türkiye'deki ve dünyadaki pek çok veri merkezinde OOB ağı, sistem odasının "üvey evladı" muamelesi görür.

OOB Ağını İntihara Sürükleyen Ölümcül Hatalar

Gemi su alırken filikanın neden suyun dibine battığını incelediğinizde, altından her zaman aynı ucuz ve tembel mimari kararlar çıkar:

1. "Eski Hurda Switch'i OOB'ye Takalım" Mantığı

Prodüksiyon omurgasında yüz binlerce dolarlık Arista, Cisco Nexus veya Juniper omurgalar kullanılırken; OOB ağına gelindiğinde ofis deposunda tozlanmış, on yıllık, portlarının yarısı arızalı, fanı öten 100 Mbit'lik eski bir switch takılır. "Aman canım alt tarafı bir web arayüzü açacak, ne gerek var masrafa?" denir.

Oysa kriz anında o hurda switch'in işlemcisi broadcast paketlerinin altında ezilir, bellek taşması (memory leak) yaşar ve prodüksiyon çöktüğü anda kendisi de kilitlenir.

2. DHCP Bağımlılığı Paradoksu

Gözlerimle şahit olduğum en trajik veri merkezi hikayelerinden biridir: Bir sistem ekibi, 150 adet sunucunun iDRAC arayüzüne statik IP vermekle uğraşmak istemez. "DHCP'den dağıtalım, MAC adreslerini rezerve ederiz" derler.

Her şey harikadır; ta ki şirketin prodüksiyon ortamındaki Active Directory ve DHCP sunucularını barındıran sanallaştırma kümesi (vSphere/KVM) çöken bir storage yüzünden kapanana kadar. Prodüksiyon göçtüğü için DHCP sunucusu ölür; DHCP öldüğü için OOB switch'e bağlı sunucuların yönetim kartları IP yenileyemez (lease time dolar) ve APIPA (169.254.x.x) adresine düşer. Sunuculara erişip sanallaştırmayı açamazsınız, çünkü yönetim kartları IP alamaz; yönetim kartları IP alamaz çünkü sanallaştırma kapalıdır!

Mükemmel bir sistem tavuk-yumurta kilitlenmesi (deadlock).

3. OOB Ağının Prodüksiyondan Beslenen VPN Ağ Geçidi

Bir diğer popüler akıl tutulması: Mühendis evindedir, gece saat üçte prodüksiyon ağı BGP fırtınası yüzünden kopar. Mühendis OOB ağına bağlanmak için şirketin ana Firewall'una (örneğin Fortigate / Palo Alto) SSL-VPN ile bağlanmaya çalışır.

Ama bir dakika; ana firewall'un internet bacağı da prodüksiyon omurgasından çıkmaktadır! Prodüksiyon omurgası öldüğü için VPN sonlandırıcıya ulaşılamaz. OOB ağı fiziksel olarak çalışıyor olsa bile, o ağa dışarıdan girecek bağımsız bir LTE/4G modem veya ayrı bir ADSL/Metro hattı konulmadığı için OOB ağı bir ada gibi kendi içinde izole kalır.

Gece Yarısı Veri Merkezine Doğru Panik Sürüşü

Uzaktan yönetim ağınız çöktüğünde teorik sistem yöneticiliği biter; saf fiziksel efor ve çaresizlik başlar.

Pijamalarınızla yatağınızdan fırlar, bagaja konsol kablolarınızı, USB-Serial dönüştürücülerinizi ve taşınabilir bir monitörü atıp gecenin köründe veri merkezine doğru gazlarsınız. Soğuk koridorda elleriniz titreyerek, kabin arkasındaki o tozlu OOB switch'in konsol portuna mavi rollover kabloyu taktığınızda gördüğünüz manzara genellikle şudur:
Switch CPU utilization: 99% - Spanning Tree loop detected on port 24.

Biri aylar önce kablolama yaparken OOB switch'indeki iki port arasına kazara bir patch kablo takmış ve bir loop (döngü) yaratmıştır; ya da bir sunucunun çift portlu IPMI kartı yanlışlıkla köprülenmiştir. Sistem o güne kadar fark edilmeden idare etmiştir, ama ilk fırtınada tüm broadcast paketleri o eski switch'i boğmuştur.

Yaşatmak İçin İzole Et

Bir Out-of-Band ağı kuruyorsanız, kendinize şu acımasız soruyu sormak zorundasınız: Dünyadaki tüm ana sistemler, DNS'ler, DHCP'ler, firewall'lar ve omurga switch'ler yeryüzünden silinse bile ben bu yönetim portuna ulaşabilir miyim?

Cevabınız "Evet" değilse, bir OOB ağınız yoktur; sadece pahalı bir teselli mekanizmanız vardır.

Gerçek bir OOB mimarisi:

• Tamamen Statik Olmalıdır: Her yönetim kartının IP'si, alt ağ maskesi ve geçidi cihazın NVRAM'ine kazınmalı; hiçbir harici sunucuya (DHCP) muhtaç olmamalıdır.
• Fiziksel Olarak İzole Olmalıdır: Prodüksiyon VLAN'ları ile OOB VLAN'ları aynı trunk kablodan geçmemelidir. Ayrı bir patch panel, ayrı bir kablo tavası ve bağımsız bir switch omurgası bulunmalıdır.
• Bağımsız Giriş Kapısı Olmalıdır: OOB switch'inin başında, binanın ana internetinden tamamen bağımsız çalışan bir 4G/5G endüstriyel modem veya bağımsız bir DSL hattı bulunmalı; mühendis doğrudan bu uç noktaya VPN yapabilmelidir.

Tıpta acil çantasının kuralı şudur: Hastanın yanına koştuğunuzda o çantadaki laringoskopun ışığı yanmıyorsa, dünyanın en iyi doktoru olmanızın hiçbir anlamı yoktur.

Veri merkezinde de cankurtaran filikanızın motorunu her ay çalıştırmıyorsanız, gemi batarken suyun üzerinde yüzmeyi değil, boğulurken ne kadar pişman olacağınızı düşünürsünüz.

Bazen dikkatsiz bir personelin steril eldiveni taktıktan sonra gayriihtiyari burnunu kaşıdığını veya ameliyat lambasının steril olmayan koluna değdiğini görürdünüz. "Aman hocam ne olacak, elimin ucuyla hafifçe dokundum" cehaleti, tıpta cinayetle eşdeğerdir.

Elektronik dünyasında, veri merkezlerinin soğuk koridorlarında ve sunucu laboratuvarlarında da tam olarak bu biyolojik virüs gibi işleyen, gözle görülmeyen, hissedilmeyen ama milyonlarca liralık donanımı sessizce çöp eden bir katil vardır: Elektrostatik Deşarj (ESD - Electrostatic Discharge).

Ve bu katile karşı geliştirdiğimiz en büyük kurumsal yalan da kabinlerin kenarında asılı duran o mavi antistatik bilekliklerin sergilediği sahne tiyatrosudur.

Hissedilmeyen Voltaj, Delinen Silikon

Bir kış günü yün kazağınızı çıkarıp kapı koluna uzandığınızda parmağınızdan metal kola doğru mavi bir kıvılcım sıçrar ve canınız acır: "Çıt!"

İnsan biyolojisinin bir elektrostatik yükü fiziksel olarak hissedebilmesi, derisindeki sinir uçlarının uyarılabilmesi için o voltajın en az 3.000 Volt (3 kV) seviyesine ulaşması gerekir. Hatta karanlıkta kıvılcımı görebilmeniz için potansiyel farkın 5.000 Volt'un üzerine çıkması lazımdır. Yün halıda yürüyen, tekerlekli suni deri koltukta oturan bir teknisyenin vücudu rahatlıkla 15.000 - 20.000 Volt statik elektrik yükü biriktirebilir.

Şimdi bu denklemin diğer tarafına bakalım:
Bir sunucunun anakartı üzerindeki modern mikrodenetleyiciler, DDR5 ECC RAM blokları veya PCI-e Gen5 kontrolcüleri kaç volta kadar dayanıklıdır biliyor musunuz?
Sadece 10 ila 100 Volt!

Nanometre ölçeğindeki silikon kapı oksit tabakaları (gate oxide layers) o kadar incedir ki, birkaç atom kalınlığındadır. Siz parmağınızı 128 GB'lık kurumsal bir ECC RAM modülünün altın pinlerine dokundurduğunuzda hiçbir şey hissetmezsiniz. Kıvılcım görmezsiniz, ses duymazsınız, eliniz yanmaz. Çünkü deşarj olan 200-300 Volt sizin kaba deri bariyeriniz için tamamen hissizdir.

Ama o görünmez akım, RAM modülünün içindeki milyarlarca mikroskobik transistörün arasından geçerken silikonun üzerinde volkanik bir krater patlatır.

Latent Hasar: Anında Ölmeyen, Süründüren Donanım

ESD'nin en tehlikeli boyutu "Catastrophic Failure" (ani ve tam ölüm) değildir. Bir bileşene dokunursunuz, sunucu hiç açılmaz; bu en masum senaryodur. Gider yenisini takarsınız, suç bellidir.

Asıl felaket, literatürde "Latent Defect" (Gizli / Uyuyan Hasar) olarak adlandırılan durumdur.

Statik yük, transistörün yalıtkan katmanını tamamen parçalamaz; sadece çatlatır, zayıflatır veya yarı iletken kanalda mikroskobik bir deformasyon bırakır. Sunucu kasasını kapatır, sunucuyu rafa sürer ve çalıştırırsınız. Cihaz sorunsuz açılır! POST testini geçer, işletim sistemi yüklenir, her şey mükemmel görünür.

Sonra ne olur?
Üç hafta sonra, şirketinizin en yoğun işlem hacmine ulaştığı Salı günü saat 14:30'da:

• Linux çekirdeği aniden Kernel Panic - Machine Check Exception (MCE) verir.
• Veritabanı motoru bellekteki veriyi diske yazarken tek bir bit sapması (bitflip) yaşar ve tablo kilitlenir.
• Sunucu haftada bir kez rastgele yeniden başlar, ancak donanım testine soktuğunuzda Dell SupportAssist veya HP Insight Diagnostics "Tüm donanımlar sağlam" raporu verir!

Sysadmin çıldırma noktasına gelir. Yazılımcıya "Kodun bellek sızdırıyor" der, yazılımcı sistemciye "İşletim sistemin bozuk" der. Oysa tek suçlu; üç hafta önce o RAM'i takarken ESD bilekliği takmaya üşenip çıplak elle tutan ve "Bak açıldı, bir şey olmadı işte" diyen teknisyenin parmak ucundaki görünmez statik yüktür. O zayıflayan transistör, termal stres ve elektriksel yük altında zamanla sızıntı akımı (leakage current) üretmiş ve en sonunda sistemi dizlerinin üzerine çökertmiştir.

Duvarda Asılı Süs: ESD Bilekliği Tiyatrosu

Hemen hemen her kurumsal veri merkezinin girişinde veya bakım masasında duvara asılmış sarı-mavi antistatik bileklikler (ESD wrist straps) görürsünüz. Denetim firmaları geldiğinde prosedür klasörlerinde fotoğrafları yer alır.

Fakat sahada yaşanan gerçek tam bir absürt tiyatrodur:

1. Ucu Boşta Kalan Timsah Kıskacı: Teknisyen bilekliği bileğine takar ama sarmal kablonun ucundaki timsah kıskacını hiçbir yere bağlamaz! Kablo kasanın üzerinde sallanır. Statik elektriğin toprağa akması için kapalı bir devre olması gerektiği fizik kuralı tamamen unutulmuştur; bileklik adeta nazar boncuğu gibi takılmaktadır.
2. Boya Üzerine Tut Turulan Kıskaç: Kıskacı sunucu kabinine tuttururlar; ancak kabinin boyalı, vernikli dış yüzeyine kıstırırlar. Boya yalıtkandır! Boyalı metal yüzey topraklama sağlamaz; boyasız, galvanizli şasiye veya özel ESD topraklama barasına (grounding lug) bağlanması gerekir.
3. El Çırparak Statik Boşaltma Efsanesi: En popüler Türk usulü donanım ritüeli: Kasanın kapağını açmadan önce elleri kabin demirine iki saniye sürtüp "Tamamdır, statik elektriğimi boşalttım" demek. Bir insanın statik elektriği nötrlemesi o kadar basit değildir; ayağınızdaki yalıtkan kauçuk tabanlı spor ayakkabıyla kabin içinde attığınız tek bir adım, o boşalttığınız yükü yarım saniyede misliyle geri yükler.

Kurumsal Disiplin ve Antistatik Kültür

Donanım ucuz değildir. 256 GB ECC DDR5 bellek modüllerinin, çift soketli server anakartlarının binlerce dolar olduğu bir çağda; bu bileşenleri pazar tezgahından elma seçer gibi çıplak elle kenarlarından değil entegrelerinden tutarak taşımak affedilemez bir amatörlüktür.

Gerçek bir operasyonel olgunluk şunları şart koşar:

• Topraklanmış ESD Matı: Bakım masalarında üzeri toprağa bağlı özel iletken matlar bulunmalı, sökülen her kart doğrudan bu matın üzerine veya antistatik koruyucu poşetinin (antistatic bag) üzerine konulmalıdır. (Poşetin içi antistatiktir, dışı genellikle statik toplayıcıdır, bunu dahi bilmeyen teknisyenler vardır!)
• Sürekli Test Edilen Bileklikler: Bileklikler sadece takılmamalı, bakım masasının girişindeki ESD test cihazına basılarak teknisyenin direnç aralığının (genellikle 1 Megaohm güvenlik direnci) uygun olup olmadığı kontrol edilmelidir.
• Kıyafet ve Ayakkabı Standartları: Sentetik polar kazaklarla, yün hırkalarla veri merkezine girip sunucu içi açma dönemi kapanmalıdır.

Ameliyathanede mikrop nasıl affetmezse, silikon vadisinde de elektrostatik şok affetmez.

Bir anakarta dokunmadan önce o bilekliği gerçekten toprağa bağlamıyorsanız, elinizdeki pahalı sunucu parçası çalışsa bile aslında içten içe kanayan ve ne zaman öleceğini kestiremediğiniz saatli bir bombadır.

Depolama sistemleri ve veri merkezi dünyasında da tam olarak bu ölümcül domino etkisini birebir yaşatan, mühendislik tarihinin en sinsi tuzaklarından biri vardır: Terabaytlık disklerde RAID 5 kullanmak.

Sektörde uzun yıllar geçirmiş kıdemli sistem yöneticilerinin yüzünde, birisi "Storage'ı RAID 5 yaptık, hem ekonomik oldu hem tek disk toleransımız var" dediğinde beliren o buruk, acı tebessümün arkasında işte bu travmatik cenaze törenleri yatar.

RAID 5 Matematiği Neden ve Ne Zaman İflas Etti?

1990'larda ve 2000'lerin başında diskler 36 GB, 73 GB veya en fazla 146 GB kapasiteye sahipken RAID 5 bir mühendislik harikasıydı. N+1 mantığıyla bir diskin kapasitesini pariteye (parity) ayırır, tek bir disk fiziksel olarak yansa bile sistemi kesintisiz çalıştırmaya devam ederdiniz. Arızalı diski çeker, yerine yenisini takardınız ve 45 dakika içinde dizi yeniden yapılandırılır (rebuild edilir), hayat normale dönerdi.

Fakat bugün masamızda 16 TB, 20 TB hatta 24 TB kapasiteli kurumsal SATA ve SAS diskler dönüyor. Ve fizik kuralları bu devasa kapasitelerde RAID 5'in tabutuna son çiviyi çoktan çaktı.

Bu ölüm fermanının altında iki temel teknik neden yatar:

1. İnanılmaz Uzun Süren Rebuild Süreleri: 18 TB'lık bir diskin RAID dizisine yeniden dahil edilmesi, saatler değil günler sürer. Hatta storage ünitesi o sırada prodüksiyonda canlı I/O yükü altındaysa, bu rebuild süreci 4 ila 7 güne kadar uzayabilir.
2. URE (Unrecoverable Read Error) İstatistiği: Standart kurumsal disklerin teknik veri sayfalarında (datasheet) küçük puntolarla bir metrik yazar: Non-recoverable read errors per bits read: 1 in 10^14 (veya kurumsal SAS disklerde 1 in 10^15).

Bu matematiksel gerçek ne anlama gelir? Kabaca her 12 terabaytlık veri okuma işleminde diskin fiziksel sektörlerinden en az birinde matematiksel olarak düzeltilemez bir okuma hatası meydana gelme ihtimali neredeyse kesindir!

Rebuild Kabusu: Kalan Disklerin Kalp Krizi

Senaryo her zaman aynı trajediyle başlar:
Sekiz adet 16 TB'lık diskten oluşan bir RAID 5 diziniz vardır. Bir gece yarısı üçüncü disk kırmızı ışığını yakar ve "FAILED" durumuna düşer.

Sysadmin soğukkanlılıkla veri merkezine gider, yedeğin rafta bekleyen taze diskini kızağa takar ve içeri iter. Kontrolcü (RAID controller) sevinçle rebuild sürecini başlatır: %1... %5... %12...

Fakat o rebuild işlemi sırasında arka planda ne yaşanır biliyor musunuz?
Yeni takılan o 16 TB'lık boş diskin parite verisini baştan hesaplayıp yazabilmek için, dizide kalan diğer yedi diskin üzerindeki her bir sektörün baştan sona, aralıksız olarak okunması gerekir!

Zaten aynı parti (batch) üretimden çıkmış, aynı kabinde aynı titreşime maruz kalmış, aynı sıcaklıkta 4 yıldır yan yana 7200 RPM hızla dönen o yaşlı yedi disk; hayatlarının en acımasız I/O falakasına yatırılır. Günlerce yüzde yüz okuma yükü altında cayır cayır ısınırlar.

Ve üçüncü günün sabahında, rebuild göstergesi %78 seviyesindeyken kontrol kartından o korkunç alarm sesi yükselir:
Drive 6: Read Error / I/O Timeout - Drive Dropped from Array.
CRITICAL: Multiple drive failures detected. Virtual Disk Offline.

İkinci disk strese dayanamamış, ya URE hatası vermiş ya da mekanik motoru kilitlenmiştir. RAID 5 sadece tek disk toleransına sahip olduğu için, ikinci diskin düştüğü o mikrosaniyelik anda tüm parite algoritması çöker.

100 terabaytlık veriniz artık kurtarılamaz bir gürültü yığınına (garbage data) dönüşmüştür.

"Ama Bizim RAID'imiz Vardı!" Çaresizliği

Veri kaybı yaşayan yöneticilerin ilk sığınağı her zaman aynı yanılgıdır: "Ama biz sunucuyu RAID'li kurmuştuk, verimiz nasıl uçar?"

Sistem mühendisliğinin ilk dersinde tahtaya büyük harflerle yazılması gereken kanun şudur:
RAID BİR YEDEKLEME DEĞİLDİR.

RAID, donanım arızası anında iş sürekliliği (high availability) sağlamak için tasarlanmış bir mimaridir; veriyi korumak için değil. RAID sizi fidye yazılımlarından korumaz, yanlışlıkla çalıştırılan rm -rf komutundan korumaz, kontrol kartının arızalanıp veriyi bozmasından korumaz ve en önemlisi rebuild sırasında ikinci diskin patlamasından korumaz.

Eğer RAID 5 dizinizin arkasında bağımsız, test edilmiş, harici bir depolama birimine veya teyp kasetine (LTO) alınmış güncel bir soğuk yedeğiniz (cold backup) yoksa; elinizdeki tek şey pimi çekilmiş ve mandalı gevşemiş bir el bombasıdır.

Modern Dünyada Ne Kullanmalıyız?

RAID 5, 2 TB'ın üzerindeki disklerin dünyasında artık bir tasarım hatasıdır, mesleki bir ihmaldir. Peki günümüz mimarilerinde ne yapılmalıdır?

1. En Az RAID 6 (Çift Parite): Eğer mutlaka klasik parite tabanlı bir RAID kullanacaksanız, minimum standart RAID 6'dır. RAID 6, iki diskin aynı anda ölmesine tolerans tanır. Rebuild sırasında ikinci disk çökse bile sistem üçüncü diske dayanarak çalışmaya devam eder.
2. RAID 10 (Mirroring + Striping): Performans ve güvenlik kritikse RAID 10 altın standarttır. Parite hesaplama yükü yoktur, rebuild işlemi diğer disklerin tümünü taramak yerine sadece ölen diskin aynasını (mirror) kopyalamaktan ibarettir; dolayısıyla dakikalar veya birkaç saat içinde tamamlanır.
3. ZFS (RAID-Z2 / RAID-Z3) ve Dağıtık Depolama: Modern dosya sistemleri (ZFS, Ceph, MinIO) verinin sağlığını her blokta checksum ile doğrular. URE hatası aldığında tüm diziyi çökertmek yerine sadece o hatalı bloğu pariteden onarır ("scrubbing").

Tıpta bir kural vardır: Yaşlı ve damarları kireçlenmiş bir hastayı ağır maraton koşusuna sokamazsınız; kalbi kaldırmaz.

Yıllardır dönen 18 TB'lık SATA diskleri de tek disk toleranslı RAID 5 ile günlerce sürecek ölümcül bir rebuild maratonuna sokmayın. Ya çift parite kalkanı koyun, ya aynalama yapın; ama asla verinizi tek bir diskin parite şansına emanet etmeyin.

Bir lokma et trakeayı tıkadığında, göğüs kafesinizde iki tane devasa akciğerinizin olmasının hiçbir kıymeti kalmaz. O ortak darboğaz çöktüğü anda, iki bağımsız organ da saniyeler içinde oksijensiz kalarak beyni felce sürükler.

Veri merkezi mimarisinde ve kurumsal sistem odalarında da tam olarak bu trakea körlüğünü yaşayan, tabelasında "Tier-3 Altyapı" yazıp arka planda sefalet saçan devasa bir illüzyon vardır: Çift Güç Kaynağı (Redundant PSU) Yalanı.

Satın alma departmanları bütçeyi ikiye katlayarak "çift güç kaynaklı (Dual PSU / 750W Titanium Hot-Plug)" kurumsal sunucular alır, sistemciler sunucuların arkasına gururla iki kalın siyah güç kablosu takar. Ta ki binanın trafosunda küçük bir ark oluşup, o çift güç kaynaklı yüz elli sunucunun hepsi aynı mikrosaniyede tek bir "çıt" sesiyle zifiri karanlığa gömülene kadar.

Kabin Arkasındaki Tembellik: Aynı PDU'ya İki Fiş

Gözlerimle onlarca kurumsal firmanın sistem odasında şahit olduğum, trajikomik bir kabin arkası manzarası vardır.

Sunucunun kasasını rafa sürersiniz. Kasanın arkasında yan yana iki adet güç kaynağı yuvası durur: PSU 1 ve PSU 2. Mühendis eline iki adet C13-C14 güç kablosu alır. Biri sağdakine, biri soldakine takılır.

Sonra kabinin yan dikmesinde asılı duran dikey PDU'ya (Power Distribution Unit) bakar. Orada yan yana 24 tane C13 priz vardır. Mühendis iki kabloyu da alır; birinci fişi 7. prize, ikinci fişi 8. prize takar!

Tebrikler; kağıt üzerinde "çift beslemeli ve yedekli" bir sunucunuz vardır, ama gerçekte o kabinin PDU'su üzerinde küçük bir kısa devre olduğunda veya PDU'nun kendi giriş sigortası attığında sunucunuz anında kütük gibi yere çakılacaktır.

Sunucunun kendi içinde iki güç kaynağının olması bir "yedeklilik" değildir; o sadece son kullanıcı ucundaki bir soket çoğullamasıdır. Asıl mesele, o iki soketin geriye doğru uzanan elektriksel soyağacının nerede buluştuğudur.

A ve B Hattının Sahte Ayrılığı

İşi biraz daha bildiğini iddia eden ekipler kabine iki adet PDU koyarlar: Sol tarafa mavi etiketli "PDU-A", sağ tarafa kırmızı etiketli "PDU-B". Sunucunun PSU 1'i A'ya, PSU 2'si B'ye takılır. Mühendis koltuğuna kurulur: "Artık A+B tam yedekliyiz."

Şimdi kabinin tabanındaki yükseltilmiş döşemeyi kaldıralım ve o iki kalın zırhlı kablonun izini sürelim:

1. Aynı Sigorta Panosu (Distribution Panel): PDU-A ve PDU-B'den çıkan kablolar oda duvarındaki dağıtım panosuna gider. Panonun kapağını açarsınız; evet, iki ayrı 16 Amper sigortaya bağlanmışlardır. Ama o iki sigortanın tepe barası ortaktır! Panonun girişindeki ana kaçak akım rölesi veya ana şalter tek bir faz dengesizliğinde attığında, hem A hem B sigortası aynı anda enerjisiz kalır.
2. Aynı UPS Ünitesi: Panoyu geçersiniz, UPS odasına inersiniz. Görürsünüz ki PDU-A da PDU-B de aynı 100 kVA'lık devasa kabin tipi kesintisiz güç kaynağına bağlıdır! "Nasıl olsa UPS'imiz 100 kVA, ikisini de besler" denmiştir. O UPS'in içindeki statik bypass arızalandığında veya akü grubundan biri patladığında iki hat birden kesilir.
3. Aynı Şehir Şebekesi / Trafo: En acı senaryo ise binanın ana dağıtım merkezindedir. A hattı UPS üzerinden geliyordur, B hattı ise "UPS çökerse şebekeden beslensin" diye doğrudan trafoya bağlanmıştır. Şehir elektriği kesildiğinde şebeke ölür (B hattı gider); tam o sırada UPS devreye girerken oluşan 20 milisaniyelik transfer gecikmesinde (veya UPS'in aşırı akım çekmesiyle) A hattı da çöker.

İki farklı yolun sonunda aynı köprüye çıkıyorsanız, o köprü yıkıldığında hangi yoldan geldiğinizin hiçbir önemi kalmaz.

Yük Paylaşımı (Load Balancing) ve Gizli Aşırı Yük Tuzağı

Çift güç kaynaklı sunucuların çalışma prensibinde çok kritik ve çoğu zaman gözden kaçan bir fizik kuralı vardır: Yük Paylaşımı.

Modern sunucularda PSU'lar genellikle iki modda çalışır:

• Ya yükü %50 - %50 oranında iki güç kaynağı arasında eşit paylaşırlar,
• Ya da biri aktif (%100), diğeri pasif/standby (%0) bekler.

Şimdi kabininizdeki PDU-A ve PDU-B'nin durumunu düşünün. Kabinde 20 adet 2U sunucu var. Her sunucu normalde 400 Watt güç çekiyor.
Eşit yük paylaşımı modunda:

• PSU 1 (PDU-A): Her sunucudan 200 Watt çekiyor. Toplam: 4.000 Watt (yaklaşık 17.4 Amper).
• PSU 2 (PDU-B): Her sunucudan 200 Watt çekiyor. Toplam: 4.000 Watt (yaklaşık 17.4 Amper).

PDU'larınız 20 Amperliktir ve mühendis bakar: "Harika, PDU-A 17.4A çekiyor, PDU-B 17.4A çekiyor, sınırın altındayız, her şey güvenli."

İşte ölümcül matematik tam burada pusuya yatar!
Bir gün PDU-A'nın beslemesi kesilirse veya A tarafının sigortası atarsa ne olur?
O 20 sunucunun PSU 2'leri bir milisaniye içinde tüm yükü tek başlarına üstlenir!
Sunucu başına çekilen güç 200W'tan 400W'a fırlar. PDU-B üzerindeki toplam akım aniden 17.4 Amperden 34.8 Ampere sıçrar!

Sonuç? 20 Amperlik PDU-B sigortası anında "GÜM" diye atar!
A hattı kesildiği için hayatta kalması gereken sistem, B hattına binen ani aşırı yük (inrush & full load) yüzünden B hattının da sigortasını attırarak tüm kabini yerle bir eder.

Bir hattın kapasitesini hesaplarken, o hattın tek başına kabin içindeki tüm sistemlerin yüzde yüz yükünü taşıyabileceğinden emin değilseniz; sizin bir yedek hattınız yoktur, sadece aşırı yüke kurban edilmeyi bekleyen bir kurbanınız vardır.

Gerçek A+B Mimarisi Nasıl Olmalıdır?

Gerçek ve tavizsiz bir elektriksel yedeklilik, satın alma broşürlerindeki etiketlerle değil, beton ve bakırın fiziksel ayrılığıyla inşa edilir:

1. Tamamen Bağımsız İki Güç Yolu (Dual Path): A hattı; Şebeke 1 -> Jeneratör 1 -> ATS 1 -> UPS Grubu A -> Dağıtım Panosu A -> Kabin PDU-A rotasını izlemelidir. B hattı ise; Şebeke 2 -> Jeneratör 2 -> ATS 2 -> UPS Grubu B -> Dağıtım Panosu B -> Kabin PDU-B rotasından gelmelidir. Bu iki hattın tek bir vidası veya ortak barası dahi olmamalıdır.
2. Kapasite Sınırı (%40 Kuralı): Bir PDU'ya bağlanan yük, nominal kapasitenin asla yüzde 40'ını aşmamalıdır. Böylece diğer hat tamamen çöktüğünde ve tüm yük tek PDU'ya bindiğinde akım yüzde 80'i geçmez ve sigorta atma riski sıfırlanır.
3. Periyodik Kesme Testi (Pull the Plug): Gerçek yedeklilik, yılda en az bir kez planlı bakımda ana A panosunun şalteri küt diye indirilerek test edilir. O şalter indiğinde tek bir sunucunuz bile yeniden başlıyorsa, mimarinizde bir yerlerde ortak bir trakea tıkanıklığı var demektir.

Tıpta hastanın iki böbreği olması harika bir güvencedir; ama doktor her iki böbreğin kan damarlarını ayrı ayrı kontrol eder.

Siz de sunucunuzun arkasındaki o iki fişe güvenip arkanıza yaslanmayın. Yükseltilmiş tabanı kaldırın, kabloları takip edin ve o iki kablonun nerede aynı kuyuya düştüğünü bulun. Yoksa o kuyunun kapağı ilk fırtınada üzerinize kapanacaktır.

Fakat o yoğun bakımın yangın tahliye koridoruna giderseniz, genellikle acı bir sahneyle karşılaşırsınız: Yangın merdiveninin ağır çelik kapısının altına personelin biri tarafından bir takoz veya kırık bir süpürge sapı sıkıştırılmıştır. Neden? Çünkü nöbetçi hemşire veya temizlik görevlisi bahçeye hava almaya veya sigara içmeye çıkarken her seferinde kart basmakla, üç kat dolaşmakla uğraşmak istememiştir. Bir kişinin beş saniyelik "konforu" uğruna, o hastanenin en hassas yaşam destek ünitesi sokaktan geçen herkesin elini kolunu sallayarak girebileceği açık bir meydana dönüşmüştür.

Siber güvenlik ve kurumsal BT dünyasında da tam olarak bu süpürge sapı vakasını temsil eden, görünce her güvenlik uzmanının saçını başını yolduran ölümcül bir gaflet vardır: IPMI, iDRAC ve iLO Portlarını Doğrudan Genel İnternete (Public IP) Açmak.

Ön Kapıda Çelik Kalkan, Arka Kapıda Tahta Mandal

Modern bir kurumun bilgi güvenliği mimarisine baktığınızda gözleriniz kamaşır:

• Ön cephede milyonlarca liralık Next-Generation Firewall (Palo Alto, Fortinet),
• Web trafiği için Cloudflare WAF, DDoS koruma filtreleri,
• Sunucu işletim sisteminde sıfır toleranslı SELinux, SSH için çift faktörlü doğrulama (2FA), IP kısıtlamaları.

Mühendisler ön kapıyı adeta Fort Knox zırhıyla kaplamıştır.
Fakat aynı sistem yöneticisi, gece evinde pijamalarıyla Netflix izlerken sunucu kilitlenirse "Ofise VPN ile bağlanmak, oradan Jump Host'a sıçramak kim uğraşacak şimdi?" der. Sunucunun Dell iDRAC veya HP iLO yönetim portuna doğrudan genel bir IPv4 bloğundan adres verir (185.x.x.x veya 212.x.x.x), firewall üzerinden 443 (HTTPS) ve 623 (IPMI UDP) portlarını tüm dünyaya (0.0.0.0/0) açar!

Ve böylece, ön kapısına tank savar füzeleri yerleştirdiği kalenin arka mutfak kapısının anahtarını sokak ortasındaki paspasın altına koymuş olur.

Shodan'da Açık Büfe: Cipher 0 ve Tarih Öncesi Firmware'ler

Bir sistem yöneticisinin anlamakta en çok zorlandığı gerçek şudur: İnternete bağlanan bir IP adresi asla "gizli" kalamaz.

Siz o portu açtıktan en fazla on dakika sonra Shodan, Censys veya Çin ve Rus kaynaklı otomatik botnet tarayıcıları o IP'yi keşfeder. Karşılarında Dell'in veya HP'nin login sayfasını gördükleri an, saldırganlar için bayram başlar.

Çünkü sunucuların bu yerleşik yönetim kartları (BMC - Baseboard Management Controller) güvenlik açısından tam bir saatli bombadır:

1. Yıllarca Güncellenmeyen Firmware: Sunucunun işletim sistemine (Ubuntu, RedHat, Windows) her hafta güvenlik yamaları geçilir. Ama anakartın üzerindeki o küçük BMC çipinin firmware'i genellikle sunucu fabrikadan çıktığı günkü haliyle kalır! Sekiz yıldır güncellenmemiş bir iDRAC 7 veya iLO 4 arayüzü, kamuya açık onlarca uzaktan kod çalıştırma (RCE) zafiyetiyle doludur.
2. Cipher 0 Felaketi: IPMI 2.0 protokolünün tasarımında var olan meşhur "Cipher 0" açığı, kimlik doğrulamayı tamamen devre dışı bırakarak saldırganın hiçbir şifre girmeden yönetim haklarını almasına olanak tanır.
3. Varsayılan ve Zayıf Şifreler: Hala internet üzerinde binlerce sunucuda kullanıcı adı ve şifre root / calvin (Dell) veya Administrator / [kasa etiketindeki ilk şifre] olarak durmaktadır.
4. Kaba Kuvvet (Brute-Force) Korumasızlığı: Çoğu eski BMC arayüzünde modern web uygulamalarındaki gibi gelişmiş rate-limiting veya account lockout mekanizmaları düzgün çalışmaz; saldırgan milyonlarca şifre denemesini arka arkaya rahatlıkla gönderebilir.

Bir iDRAC Ele Geçirilirse Ne Olur? (Spoiler: Her Şey Biter)

Pek çok yönetici iDRAC'ı sadece "sunucunun sıcaklığına bakan, fan hızını ayarlayan basit bir gösterge paneli" zanneder. Oysa bir sunucunun yönetim kartını ele geçiren bir saldırgan, işletim sistemindeki root veya Administrator kullanıcısından katbekat daha yetkilidir.

Saldırgan o arayüze girdiği anda:

• Sanal Konsolu (HTML5 / Java KVM) Açar: Ekranda işletim sisteminin konsolunu canlı olarak görür. Fiziksel olarak sunucunun başına oturmuş, monitör ve klavye bağlamış gibidir.
• Sanal Medya (Virtual Media) Bağlar: İşletim sisteminin disk şifrelemesi (BitLocker, LUKS) mi var? Hiç problem değil! Kendi sunucusundaki kötü amaçlı bir Live ISO dosyasını iDRAC'a sanal CD-ROM olarak bağlar.
• Fiziksel Gücü Yönetir: Sunucuyu uzaktan kapatır, BIOS ayarlarına girer, önyükleme sırasını (boot order) değiştirir ve sunucuyu kendi bağladığı ISO üzerinden başlatır.
• Tüm Diski Ham Olarak Siler veya Şifreler: İşletim sistemindeki hiçbir antivirüs, EDR veya SIEM ajanı bu durumdan haberdar bile olamaz; çünkü işletim sistemi zaten hiç açılmamıştır! Saldırgan donanım düzeyinde diski ham (raw) olarak şifreler veya fidye yazılımını doğrudan hipervizöre enjekte eder.
• Kalıcı Donanım Arka Kapısı (Hardware Rootkit): Daha da kötüsü; saldırgan BMC çipine modifiye edilmiş zararlı bir firmware yükler (brick veya persistent backoor). Siz sunucuya elli defa format atsanız, diskleri sıfırdan taksanız bile o arka kapı anakartın silikonunda yaşamaya devam eder!

Yönetim Ağını Korumanın Değişmez Kuralları

Eğer sistem odanızdaki sunuculardan tek bir tanesinin bile iDRAC/iLO portu internete bakıyorsa, şu an bu yazıyı okumayı bırakıp derhal o kabloyu çekmeniz veya o kuralı silmeniz gerekir.

Yönetim katmanında güvenlik şu katı kurallarla sağlanır:

• Sıfır Public IP (Zero Exposure): Hiçbir BMC, iDRAC, iLO veya IPMI arayüzüne genel (Public) IP verilmez. Bu arayüzler sadece ve sadece 10.x.x.x veya 172.16.x.x gibi özel (RFC 1918) yerel ağ bloklarında yaşayabilir.
• İzole Yönetim VLAN'ı ve Donanımsal Ayrım: OOB portları prodüksiyon switch'lerine değil, sadece yönetim için ayrılmış izole switch'lere bağlanmalıdır.
• Mecburi İki Kademeli Erişim (VPN + Jump Host): Yönetim ağına evden veya dışarıdan erişmek isteyen mühendis; önce kurumsal VPN ağ geçidinden MFA (çok faktörlü doğrulama) ile geçmeli, ardından sadece yönetim ağına erişim izni olan kısıtlı bir atlama sunucusuna (Jump Host / Bastion Host) bağlanmalıdır.
• IPMI Protokolünü Sınırlandırmak: Kullanılmıyorsa IPMI over LAN protokolü kapatılmalı, yalnızca modern ve güvenli HTTPS / Redfish API standartları aktif tutulmalıdır.

Tıpta steril alana giden yangın merdiveninin altına takoz koyan personeli anında görevden uzaklaştırırlar; çünkü hastaların hayatı o personelin sigara molasından daha değerlidir.

Veri merkezinde de "üç tık az yapayım" diye iDRAC'ı internete açan sistem yöneticisi, şirketinin tüm dijital varlıklarını Shodan'daki açık artırma masasına meze yapan bir felaket habercisidir. Güvenlikte konfor arayışı, daima felaketin sponsorudur.

Tıpta buna "cerrahi alet ve gazlı bez sayımı" denir. Eğer tek bir gazlı bez veya kırık bir iğne ucu eksik çıkarsa; cerrah hastayı kapatamaz. Ameliyathanenin ışıkları altında, hasta narkozdayken dakikalarca o 3 santimlik pamuk parçası veya metal iğne aranır, gerekirse ameliyat masasında portatif röntgen çekilir. Çünkü vücut içinde unutulan küçücük bir metal parçası ("gossypiboma"), ameliyat ne kadar başarılı geçmiş olursa olsun, haftalar sonra hastanın içinde devasa apselere, organ delinmelerine ve septik şoka yol açarak o insanı öldürür.

Sunucu bakımında, veri merkezi koridorlarında ve laboratuvar tezgahlarında da tam olarak cerrahın o soğuk terlerini döktüren, donanım mühendislerinin kabuslarına giren mikroskobik bir felaket senaryosu vardır: 1U Kasanın İçine Düşen ve Kaybolan Vida.

"Tık... Tık... Çıt..." O Ses Duyulduğu An

Saat gece 02:45. Şirketin en kritik hipervizör sunucusuna ilave bir M.2 NVMe SSD veya PCIe Gen5 ekran kartı takmak üzere sunucuyu kabin rayından dışarı çekmişsinizdir. Kasanın üst kapağını açarsınız.

1U sunucuların (sadece 4.4 santimetre yükseklik) içi, modern mühendisliğin sınırlarını zorlayan bir yoğunluk harikasıdır. 8 adet devasa jet fan, iki dev bakır soğutucu blok, 32 adet DDR5 RAM slotu, onlarca VRM (voltaj regülatör modülü) bobini ve yüz binlerce mikroskobik yüzey montaj elemanı (SMD kondansatörler ve dirençler) birbirine santimetrenin onda biri mesafede sıkıştırılmıştır.

Elinizde manyetik ucu zayıflamış veya manyetiksiz sıradan bir yıldız tornavida vardır. M.2 diskin o minicik, iki milimetrelik sabitleme vidasını iki parmağınızın ucuyla deliğe denk getirmeye çalışırsınız.

Parmaklarınız hafifçe titrer. Ve o an gerçekleşir.
Vida parmaklarınızın arasından kayar.
Tık... Tık... Pıt.

O ses, bir donanımcının duyabileceği en ürpertici sestir. Vida düşmüştür; ama nereye?

Kendini Kandırma Evresi: "Herhalde Yere Düşmüştür"

İlk beş dakika panik içinde telefonun flaşını açar, anakartın üzerine doğrultursunuz. PCIe slotlarının arasına bakarsınız, RAM mandallarının altını tararsınız, fan yuvalarının ızgaralarına göz atarsınız. Vida hiçbir yerde yoktur.

Sonra o meşhur fiziksel debelenme başlar:

• 25 kiloluk sunucuyu iki elinizle tutup havaya kaldırır, hafifçe sağa sola sallarsınız. İçeriden herhangi bir tıkırtı sesi duymaya çalışırsınız. Ses gelmez.
• Kasanın altına, yükseltilmiş tabanın deliklerine, masanın ayaklarının dibine bakarsınız. Yerde de hiçbir şey yoktur.
• Cımbız alıp soğutucu blokların arasına sokarsınız, yok.

Ve tam bu noktada, beynin en tehlikeli savunma mekanizması devreye girer: İnkar ve Sahte İyimserlik.
Mühendis kendi kendine fısıldar: "Yahu kesin düşerken kasanın dışına sekti, yerdeki ızgaranın arasına kaçtı. Anakartta olsa görürdüm zaten. Kapatayım kapağı, sabah bakarız."

İşte bu cümle, beş bin dolarlık bir kurumsal sunucunun idam fermanıdır.

Güç Kablosu Takıldığı An: 12 Volt ile 1.2 Voltun Dansı

Vida yere düşmemiştir. O iki milimetrelik nikel kaplı metal parçası, anakartın en can alıcı noktalarından birine —örneğin işlemciye saf 1.2V çekirdek voltajı sağlayan VRM devrelerinin 12V ana giriş hattının hemen altındaki iki mikroskobik lehim bacağının arasına— mükemmel bir köprü kuracak şekilde yerleşmiştir.

Kasanın kapağını vidalarsınız. Sunucuyu rafa geri itersiniz. Arkasındaki iki adet 80-Plus Platinum güç kaynağının C14 fişlerini prize takarsınız.

Sunucunun açma-kapama butonuna basmanıza bile gerek yoktur; çünkü modern sunucularda güç kablosu takıldığı anda anakarta "Standby Power" (3.3V / 5V Aux) ve ana voltaj hatları anında enerji pompalar.

Ve o an:
"ÇAZZZZ!"

Göz açıp kapayıncaya kadar süren bir kıvılcım parlaması. Ardından fanların hafifçe inleyip susması ve kasanın arka ızgaralarından yükselen o unutulmaz, genzi yakan, insanın içini acıtan ekşi koku: Yanmış silikon ve kavrulmuş epoksi kokusu.

O iki milimetrelik vida; 12 Volt yüksek akım hattını, doğrudan işlemcinin mikroskobik transistörlerine bağlanan hassas veri yollarına köprülemiştir. Akım ters yönden anakartın iç katmanlarına yürümüş, bakır yolları eritmiş, VRM kontrol çipini patlatmış ve işlemcinin çekirdeğini saniyeler içinde kömüre çevirmiştir.

Anakart ölmüştür, işlemciler yanmıştır, bellekler zarar görmüştür. Zarar: On binlerce dolar ve günlerce sürecek servis bekleme süresi.

Donanım Masasında Cerrahi Disiplin

Bu felaketler "talihsiz bir kaza" değildir; doğrudan bir disiplin ve ekipman eksikliğidir. Bir sunucu kasası açıldığında uygulanması gereken katı kurallar şunlardır:

1. Manyetik Uçlu Doğru Aletler: Elektronik için özel üretilmiş kaliteli, mıknatısı güçlü hassas tornavidalar kullanın. Mıknatısın modern SSD ve anakartlara zarar vereceği efsanesi 1980'lerden kalma bir disket (floppy disk) hurafesidir. O vidayı tornavidanın ucunda sımsıkı tutan bir alet hayat kurtarır.
2. Kayıp Parça Bulunmadan Asla Enerji Verilmez: Bir vida düştüyse ve bulunamadıysa; o kasa asla çalıştırılamaz. Gerekirse fan blokları sökülür, hava yönlendirici plastikler (air shroud) çıkarılır, anakart yerinden gevşetilir ve o vida gözle görülüp fiziksel olarak dışarı alınana kadar operasyon durdurulur. Cerrah kayıp kompresi bulmadan dikiş atmaz; sistemci de kayıp vidayı bulmadan fişi takamaz.
3. Masa Dışı Parça Değişimi Yapılmamalıdır: Kabin rayı üzerinde, ayakta, karanlık koridorda M.2 vidası takmaya çalışmak felakete davetiyedir. Sunucu tamamen raydan çıkarılmalı, iyi aydınlatılmış, temiz ve antistatik bir çalışma masasına yatırılmalıdır.
4. Yedek Plastik Tutucular: Güncel sunucu üreticileri (Dell, HPE, Lenovo) artık M.2 ve PCIe yuvalarında vidasız, plastik mandallı (tool-less latch) mekanizmalara geçmektedir. Eğer vida kullanmak zorundaysanız, vidanın düşmesini engelleyen yakalı (captive screw) modeller tercih edilmelidir.

Tıpta ameliyat masasındaki bir dikkatsizlik bir hayatı söndürür.

Veri merkezinde de "alt tarafı küçücük bir vida" deyip geçtiğiniz o metal parçası, binlerce kullanıcının verisini taşıyan bir sunucunun kalbini anında durdurabilir. Fizik kanunları hafife almayı, ihmali ve aceleyi asla affetmez.

Şehir şebekesi küt diye gittiğinde, koridordaki florasanlar söner ve loş acil aydınlatmalar devreye girer. Yatakların başındaki mekanik ventilatörler (solunum cihazları) tiz bir ikaz sesiyle dahili bataryalarına geçer. O bataryaların üzerinde kırmızı bir sayaç geri saymaya başlar: Kalan Süre: 12 Dakika.

Normalde hastanenin dev dizel jeneratörünün sekiz saniye içinde marş basıp şebekeyi devralması gerekir. Ama ya o sekiz saniye geçer ve koridorlara o tanıdık jeneratör gümbürtüsü yerine mezar gibi bir sessizlik çökerse?

İşte o an teorik tıp biter; saf insan eforu başlar. Hekimler ve hemşireler koşarak hastaların başına üşüşür, ventilatörün hortumunu söküp ağızlarına "Ambu" dediğimiz manuel solunum balonunu takarlar ve elleriyle ritmik olarak sıkmaya başlarlar: Bir... İki... Üç... Sık. O balonlar elle sıkılırken, teknik servis ekibi merdivenleri üçer beşer atlayarak bodrumdaki jeneratör dairesine depar atar. Çünkü o akü bittiğinde ve jeneratör çalışmadığında, ambuyu sıkan el durursa hasta boğulacaktır.

Veri merkezi operasyonlarında ve kritik tesis yönetiminde de tam olarak bu ambu çaresizliğini yaşatan, mühendisin nabzını 180'e fırlatan korkunç bir kabus vardır: Otomatik Transfer Şalterinin (ATS) Takılı Kalması.

Sekiz Saniyelik Lüks ve Başlayan Geri Sayım

Büyük bir veri merkezinde şehir şebekesi (trafo) enerjisi kesildiği an, kabinlerdeki sunucular hiçbir şey hissetmez. Çünkü statik UPS (Kesintisiz Güç Kaynağı) sistemleri, devasa akü bankaları üzerinden mikro saniye düzeyinde yükü sırtlar.

Fakat UPS bir enerji üretim kaynağı değildir; o sadece bir "köprüdür". Akü odasındaki o tonlarca kurşun-asit veya lityum bataryanın kabinlerdeki binlerce sunucuyu besleme süresi genellikle tam yük altında 10 ila 15 dakikadır.

Tasarım gereği senaryo şudur:

1. Şebeke gider (0. saniye).
2. UPS aküden beslemeye başlar (0. saniye).
3. Jeneratör kontrol paneli (DeepSea, ComAp vb.) şebekenin kesildiğini algılar, marş motoruna sinyal gönderir (3. saniye).
4. Dizel motor homurdanarak çalışır, 1500 devir/dakika (RPM) hızına ve 50 Hz frekansa oturur (8. saniye).
5. Ve en kritik adım: ATS (Automatic Transfer Switch - Otomatik Transfer Şalteri), motorlu mekanizmasıyla şebeke kontaktörünü açar ve jeneratör kontaktörünü kapatır (10. saniye).

Bina jeneratörden beslenmeye başlar, UPS aküleri şarj moduna geçer, herkes rahat bir nefes alır.

Peki ya o 10. saniyede ATS panosundan beklenen o tok "TARRKKK!" sesi gelmezse?

Mekanik Takılmanın Soğuk Dehşeti

Veri merkezinin izleme ekranlarında (BMS / DCIM) kırmızı bir alarm yanıp sönmeye başlar:
CRITICAL: Utility Power Lost.
WARNING: Generator Running, No Load Detected.
BATTERY RUNTIME REMAINING: 09:42... 09:41...

Jeneratör bahçede deliler gibi kükremektedir; motor çalışıyordur, egzozdan duman çıkıyordur ama ürettiği o megavatlarca elektrik binaya girememektedir! Çünkü enerjiyi binaya aktaracak olan motorlu enversör şalterin mekanik dişlisi sıkışmıştır, bobini yanmıştır ya da yardımcı kontak rölesi tozdan kaynaklı temassızlık yapmıştır.

Zaman acımasızca akmaktadır: Kalan akü süresi 7 dakika.

Kabin odasındaki yüz binlerce dolarlık işlemciler, veritabanları, bankacılık altyapıları akülerin son elektronlarını kana kana içmektedir. Akü bittiği an sunucular aniden kapanacak, storage'lar kütük gibi yere çakılacak, dosya sistemleri dağılacaktır.

Ve mühendis için tek bir kurtuluş yolu kalmıştır: Manuel Müdahale.

Bodrum Katında Fener Işığında Manivela Savaşı

Cebinizden telefonun fenerini açar, ana elektrik pano odasına doğru koşarsınız. Pano odasının ağır çelik kapısını açtığınızda yüzünüze çarpan o ozon ve sıcak trafo kokusu ciğerlerinizi yakar.

Karşınızda iki buçuk metre boyunda, devasa sacdan yapılmış gri ana dağıtım panosu (MDP) durur. Panonun üzerinde 1600 Amperlik, 3200 Amperlik devasa kompakt şalterler (ACB - Air Circuit Breaker) vardır.

ATS şalterinin göstergesine bakarsınız: Şebeke tarafı "OFF" (Açık), Jeneratör tarafı "OFF" (Açık). Mekanizma tam ortada, arafta takılı kalmıştır!

Süre: Kalan akü süresi 4 dakika.

Panonun yanındaki askıdan o uzun, ağır, çelik kolu —manivelayı (charging handle)— kaparsınız.

1. Şalterin mekanik kurma yuvasına sokarsınız.
2. Vücut ağırlığınızı vererek kolu aşağı yukarı pompalamaya başlarsınız: Çat... Çat... Çat... Mekanik yayı kurarsınız (Spring Charged). Gösterge sarıdan yeşile döner.
3. Şimdi o korkutucu kararı verme anıdır: Jeneratör tarafının mekanik "MANUAL CLOSE" butonuna basmak.

Binlerce amperlik yükün aktığı bir şalteri elle kapatmak (trip/close) müthiş bir cesaret ister. Eğer içeride bir faz çakışması veya kısa devre varsa, gözünüzün önünde güneşi andıran bir ark patlaması (Arc Flash) meydana gelebilir. Yüzünüzü yana çevirir, gözlerinizi kısar ve o kırmızı butona olanca gücünüzle basarsınız:

"GÜMMMM!"

Odayı sarsan mekanik bir çekiç sesi. Şalter yerine oturur. Panodaki analog voltmetre ibreleri aniden 400 Volt'a fırlar. Bodrumdaki havalandırma fanları inleyerek dönmeye başlar.

Merdivenlerden yukarı koşup UPS odasına baktığınızda göstergeyi görürsünüz:
UPS Input: 400V (Generator) - AC Mode Active - Battery Charging.

Sistem kurtulmuştur; son 100 saniyede.

Otomasyonun Rehaveti ve Sahadaki Gerçekler

Bu kabus hikayesi, ucuz aksiyon filmlerinden bir sahne değildir. Türkiye'deki ve dünyadaki yüzlerce veri merkezinde, hastanede ve kritik tesiste bizzat yaşanmış ve yaşanmakta olan bir operasyonel gerçekliktir.

Otomasyon muazzam bir lükstür, ancak insanı tembelleştirir. Mühendisler "Nasıl olsa ATS var, elektrik gidince kendi geçer" diyerek aylarca o mekanik şalterlerin yüzüne bakmazlar.

Oysa gerçek bir altyapı disiplini şunları gerektirir:

• Ayda Bir Yüklü Jeneratör / ATS Testi (Black Start): Jeneratörü sadece rölantide çalıştırmak test değildir! Şebekenin ana şalteri kasten indirilmeli, ATS'nin yük altında transfer yapıp yapmadığı her ay gözlemlenmelidir.
• Mekanik Şalter Bakımı: Kompakt ve açık tip şalterlerin mekanik kurma yayları, enversör kilitleri (mechanical interlock) periyodik olarak temizlenmeli ve yağlanmalıdır.
• Her Mühendise Manuel Kurma Eğitimi: Gece nöbetinde duran en genç personele dahi o manivelanın nerede durduğu, şalterin nasıl kurulduğu ve ark patlamasına karşı nasıl pozisyon alınacağı uygulamalı olarak öğretilmelidir.

Tıpta ventilatör durduğunda ambuyu sıkan el hayat kurtarır.

Veri merkezinde de ATS kilitlendiğinde o ağır manivelayı çekinmeden kavrayan ve soğukkanlılıkla şalteri kapatan mühendisin refleksi trilyonluk sistemleri küllerinden döndürür. Otomasyona güvenin, ama manivelayı her zaman elinizin altında tutun.

Bazen servise yeni başlayan hevesli bir stajyer gelir; "Aaa burada boş bir musluk varmış, hastanın ağrı kesicisini ve yoğun potasyumunu da şuradan hızla puşe edivereyim" der. Oysa o damarın biyolojik bir taşıma kapasitesi, ozmolarite limiti ve kalbe ulaşan kimyasal bir debi sınırı vardır. O boş girişe bilinçsizce yüklenen ek bir ilaç solüsyonu, hastanın damarını anında patlatabilir veya kalbinde ani bir ritim blokajına (asistoliye) yol açabilir.

Tıpta temel kural şudur: Fiziksel bir girişin boş olması, o girişin yeni bir yükü kaldırabileceği anlamına gelmez.

Veri merkezi operasyonlarında, kabin düzenlemelerinde ve sunucu montajlarında da tam olarak bu boş musluk gafletini temsil eden meşhur bir altyapı kumarı vardır: Kabin PDU'sundaki Son Boş Priz.

"Ne Şanslıyız, Tam Bir Priz Boş Kalmış!"

Kabin arkasında duran bir sistem yöneticisinin veya saha teknisyeninin yüzünde beliren o saf rahatlama gülümsemesini çok iyi bilirsiniz.

Şirkete acil olarak devreye alınması gereken 2U boyutunda güçlü bir veritabanı sunucusu veya GPU hızlandırıcılı bir yapay zeka makinesi gelmiştir. Kabin rayları monte edilir, 25 kiloluk ağır kasa kan ter içinde içeri sürülür.

Sıra elektriğe gelir. Kasanın arkasındaki dikey PDU'ya (Power Distribution Unit) bakılır. PDU üzerinde 24 adet C13 soket vardır; 23 tanesi doludur, en altta tek bir priz masum masum parlamaktadır.

Teknisyen sevinçle haykırır: "Valla tam denk geldi abi, tam da bir tane priz boş kalmış, uzatma kablosuna gerek kalmadı!"

Kablonun fişi o boş C13 prizine doğru uzatılır. O an teknisyenin aklından geçen tek şey mekanik uyumdur: Fiş prize giriyor mu? Giriyor. O halde çalışır.

Oysa o fiş prize girdiği anda, kabindeki 24 sunucunun kaderi saniyeler içinde yazı-tura atılan bir Rus ruletine dönüşür.

Amper Matematiği vs. Fiziksel Soket Sayısı

Bir PDU'nun üzerindeki priz sayısı, o PDU'nun gücünü değil; sadece fiziksel bağlantı esnekliğini gösterir.

Standart tek fazlı bir kurumsal PDU genellikle 16 Amper (Avrupa standardı, 230V, yaklaşık 3.680 Watt) nominal kapasiteye sahiptir. Amerikan veya özel endüstriyel standartlarda 20A veya 32A modeller bulunsa da, kabin içindeki çoğu standart dağıtıcı 16A sınırındadır.