Platform mühendisliği hakkında her şey: Neden gerekli, nasıl kurulur ve başarı nasıl görünür

• İç mühendisleri kullanıcı olarak kabul edip iç ürünler kurup işleten örgütsel bir disiplin olarak, sadece DevOps’un yeniden markalanmasından ya da Kubernetes kümesi yönetiminden özünde farklı bir alan
• 2025 DORA raporuna göre kuruluşların %90’ı en az bir iç platformu devreye aldı ve platform kalitesi, yapay zeka araçlarının değer üretip üretmeyeceğini doğrudan öngören bir gösterge olarak öne çıktı
• Bulut ve açık kaynak sonsuz sayıda primitive sunarken her ekibin kendi pipeline’ını kurduğu "aşırı genelleme bataklığı(over-general swamp)" sorununu çözmek temel varlık nedeni
• Platformu gerçek bir ürün gibi ele almak ve medyan geliştirici için yazılım soyutlamaları, metadata registry ve operasyonel SLO’lar bulundurmak, başarının yapısal koşulu
• İyi bir platform, geliştiricinin varlığını unutacağı kadar doğal çalışır; kötü bir platformda yapay zeka araçları kaosu büyütür, iyi bir platformda ise throughput’u artırır

---

Platform mühendisliği neden var

• Aşırı genelleme bataklığı(Over-General Swamp)

  • Bulut ve OSS; kuyruklar, object store’lar, veritabanları, CI runner’ları, service mesh’ler gibi sonsuz primitive’ler sunduğunda her uygulama ekibi farklı seçimler yapmaya başlar
  • Bir yıl sonra tüm servisler, kendi deployment pipeline’ı, retry mantığı, izleme teamülleri ve hafifçe hatalı IAM binding’leri olan bir “glue code bataklığı”na dönüşür
  • Seçeneklerin patlaması ve daha yüksek operasyon beklentileri (7/24 çalışma, güvenlik, compliance, maliyet yönetimi), bu bataklığın iki nedeni
  • Gerçek bir landing zone projesinde 20 ekibin VPC, IAM ve bütçe uyarıları için neredeyse aynı Terraform modüllerini ayrı ayrı yeniden icat ettiği ve her birinin farklı hatalara sahip olduğu bir örnek var

• Platform mühendisliğinin fiilen yaptığı dört şey

  • Geliştiricinin gördüğü primitive’leri sınırlandırır ve yalnızca küratörlü biçimde kullanılmalarını sağlar
  • Tekrarlayan altyapı işlerini paylaşılan hizmetlere alarak uygulama başına glue code miktarını azaltır
  • Altta yatan primitive’ler değiştiğinde platform ekibi bunu bir kez ele alır ve geçiş maliyetini merkezileştirir
  • Geliştiricilerin Linux kernel uzmanı olmadan da kendi yaptıkları şeyi doğrudan işletebilmesini sağlar
  • DevOps, “geliştirici operasyonun sahibi olsun” demekti; platform mühendisliği ise “o operasyon için iyi araçları gerçek bir ürün olarak sunacağız” der
  • DORA 2025 yetkinlik sayfasında da bu yaklaşım, araç kategorisi değil sosyoteknik(sociotechnical) bir disiplin olarak tanımlanıyor

Beş sütun(Pillars)

• Küratörlü ürün yaklaşımı(Curated Product Approach)

  • Platformun neyi destekleyip neyi desteklemediğine kasıtlı olarak karar verir
  • Bir ekip Pub/Sub yerine Kafka istediğinde “doküman bağlantısı burada” demek yerine, “destek kapsamı ve nedeni, uymuyorsa çıkış yolu” açıklanır
  • Hayır demek de işin bir parçasıdır

• Yazılım tabanlı soyutlamalar(Software-Based Abstractions)

  • Platform bir wiki değil, yazılımın kendisidir; arayüzleri de API, CLI ve SDK’dır
  • Geliştirici yalnızca küçük bir deklaratif dosya yazarak production düzeyinde bir servisi provision edebilmelidir
  • CNCF çatısı altındaki Score projesi buna temsilî bir örnek; tek bir workload spec ile veritabanı, topic, service account ve deployment’ı otomatik provision eder
    • Geliştiricinin bunun arka planda Cloud SQL, Pub/Sub ya da Cloud Run olup olmadığını bilmesi gerekmez

• OSS özelleştirmesi ve metadata registry

  • Vanilla Argo CD ya da Backstage’i olduğu gibi kullanmak yerine, kuruma uygun eklentiler, varsayılan politikalar ve entegrasyonlarla işletmek gerekir
  • Metadata registry (service catalog) yoksa kimin neye sahip olduğu, bağımlılıkların nasıl olduğu ve gerçekte neyin çalıştığı anlaşılamaz
  • Backstage, bu katmanda fiilî standart OSS framework olarak öne çıkıyor; 270’ten fazla kuruluşta production’da çalışıyor
    • CNCF, Certified Backstage Associate ve Certified Cloud Native Platform Engineering Associate sertifikalarını başlattı
    • Backstage, Port, Cortex ya da başka bir araç kullanılsa da “hangi servislerin var olduğu, kimin sahip olduğu ve bağımlılıkların ne olduğu” için tek bir gerçek kaynak(single source of truth) gerekir

• Geniş kullanıcı tabanına hizmet

  • İç platformlar, sayıları az ama sesi çok çıkan müşterilere sahip olabilir; ancak amaç, medyan geliştiricinin medyan işini iyi desteklemektir
  • Sadece elit kullanıcılar için inşa edilirse, diğer ekipler platformu dolaşmaya başlar ve gölge platformlar ortaya çıkar

• Temel altyapı gibi işletmek

  • Platform düşerse şirket de düşer; bu yüzden 7/24 nöbet, gerçek SLO’lar, gerçek değişiklik yönetimi ve destek yükü kaçınılmazdır
  • Bu bir “araç” değil, “zemin(floor)” görevi görür; üzerine kurulan her şey zeminin dayanacağını varsayar

Ne zaman ve nasıl başlanır

• Platform ekibini çok erken kurmayın

  • 10 mühendisin olduğu ölçekte ihtiyaç platform ekibi değil, işbirliğidir(cooperation)
    • Birinin deployment script’lerini, diğerinin Terraform’u yönetmesi ve ortak teamüller belirlenmesi yeterlidir
  • 1-2 kişiyle çok erken ekip kurarsanız onlar bir ticket kuyruğuna dönüşür, organizasyonun geri kalanı da pasifleşir
  • Genellikle 50 mühendisten sonra, birden fazla deployment hedefi oluştuğunda ve “yeni servis nasıl deploy edilir” sorusunun cevabını kimse bilmediğinde ekip kurmak uygundur

• Mevcut altyapı organizasyonunu dönüştürme

  • Altyapı/SRE ekibini platform organizasyonuna dönüştürürken en zor kısım teknoloji değil, kültürdür
  • Altyapı sorumluları “olmaz” diyen kapı bekçisi rolüne alışkındır; platform sorumluları ise “kolay bir evet sunan kişiler” olmalıdır
    • Müşterilerle sık konuşmak
    • Yalnızca operatörleri değil, araç geliştirmeyi seven yazılım mühendislerini işe almak ve yetiştirmek
    • “Yeni cluster deploy etti” yerine “200 ekibi %5 daha hızlı hale getirdi” sonucunun takdir edildiği ödül sistemini güncellemek
  • Üzerine bir PM serpiştirip işi bitmiş saymak en yaygın başarısızlık biçimidir; bu da platform değil, tiyatro(theater) üretir

Platform ekibi kurmak

• Dört rol

  • Software Engineer: API, SDK, portal gibi platformun ürün yüzeyini kurar
  • Systems Engineer: Kubernetes, Linux, ağ, bulut control plane gibi temel primitive’lerde uzmandır
  • Reliability Engineer: operasyon kalitesi, nöbet, SLO ve observability’ye odaklanır
  • Systems Specialist: veritabanı, güvenlik, ağ gibi alanlarda derin uzmanlığa sahiptir
  • Yazılım odağı fazla olursa güzel görünen portallar gerçek yük altında çöker; sistem odağı fazla olursa sağlam cluster’ları kimse ticket açmadan kullanamaz

• İşe alım

  • İşe alımda müşteri empatisi(customer empathy) en öncelikli kriter olmalıdır
  • Hayal kırıklığı yaşamış bir uygulama geliştiricisiyle görüştükten sonra sorunu net biçimde anlayamayan bir mühendis uygun değildir
  • Empatisiz teknik mükemmeliyet, doğru ama kimsenin kullanmadığı platformlar üretir
  • Yazılım rolleri için aynı seviye matrisi kullanılabilir; ancak sistem uzmanlarının piyasa değeri ve becerileri yazılım mühendisi kariyer basamaklarına temiz biçimde oturmadığından esnek unvanlara izin verilmelidir

• Yöneticiler ve diğer roller

  • Harika bir platform mühendisliği yöneticisinde üç ortak özellik bulunur: gerçek platform işletme deneyimi, uzun soluklu çok çeyrekli projeleri dağıtıma alma deneyimi ve detay takıntısı
    • Platformlar detayları ödüllendirir; nadir görünüp atlanan %1’lik durumlar destek zamanının %80’ini tüketir
  • PM, teknik yazar, geliştirici savunucusu ve destek mühendisi önemlidir; ancak mühendislik ekibi yeterince olgunlaştıktan sonra işe alınmalıdır
  • 4 kişilik bir platform ekibine erken katılan bir PM, ancak yol haritası biçiminde bir sandalye olur

Platformun bir ürün olarak ele alınması

• İç müşteriler daha zordur

  • İç müşteriler, ayrılması zor captive kullanıcılardır; güçlü görüşlere ama zayıf ürün sezgisine sahiptirler
  • Ne istediklerini (want) söylerler ama bu çoğu zaman gerçekten ihtiyaç duydukları şeyden (need) farklıdır
  • Platformun kendi işlerini onlar adına yapmasını isterler; işlerini iyi yapmalarını sağlayacak araçları değil
  • Asıl backlog, onların yanında oturup tek bir değişikliği deploy etmek için kaç kez context switching yaptıklarını gözlemlemektir

• Keşif, yol haritası, başarısızlık modları

  • Platform keşfi A/B testiyle değil, pilot ile yapılır; uyumlu ekiplerle çalışılır ve gerçek deploy sonrasında lead time azalması ölçülür
  • Yol haritasının dört zaman ufku
    • Vision (çok yıllı): Platformun yönü
    • Strategy (yıllık): Bu yılın bahisleri
    • Goals and Metrics (çeyrekten yıla): Başarının tanımı
    • Milestones (çeyreklik): Fiilen deploy edilecek işler
  • Ekipleri sık sık çökerten başarısızlık modları
    • Migrasyon maliyetinin hafife alınması (her zaman tahminin 2-3 katı)
    • Kullanıcıların yeni özellikler için değişim bütçesinin abartılması
    • Asıl sorun istikrar olduğu halde özellik eklemeye odaklanılması
    • Mühendislik ekibinin büyüklüğüne kıyasla çok fazla PM olması (5 mühendise 2 PM varsa sorun vardır)

Platform operasyonu

• On-call bir seçenek değildir

  • Temel altyapı olarak işletildiği için 7/24 kapsama pazarlık konusu değildir
  • "Yapan işletir (you build it, you run it)" ilkesi burada da geçerlidir; bu bir ceza değil, bir geri bildirim döngüsüdür
  • Tek bir mühendis haftada birkaç kereden fazla page alıyorsa, takvimi değil sistemi düzeltmek gerekir
  • Tükenmiş platform mühendisleri kötü platformlar deploy eder

• Destek: işin gizli kalan yarısı

  • Konferanslarda neredeyse hiç ele alınmayan bu alan, platform mühendisliğinin kritik yarısıdır
  • Dört aşamalı çerçeve
    • Aşama 1: Destek seviyelerini resmileştirmek (P0 vs P3, yanıt süreleri vb.)
    • Aşama 2: Kritik olmayan desteği on-call'dan ayırmak; böylece "CronJob nasıl eklenir" sorusu birini uykusundan uyandırmaz
    • Aşama 3: Hacim bunu haklı çıkarıyorsa özel destek uzmanları işe almak
    • Aşama 4: Ölçeğe uygun bir mühendislik destek organizasyonu kurmak
  • Aşama 1 atlanırsa, mühendisler zamanlarının yarısını Slack DM'lerine yanıt vererek, kalan yarısını da şikayet ederek geçirir

• Operasyonel geri bildirim

  • SLO ve SLA zorunludur; error budget faydalıdır ama isteğe bağlıdır
  • Synthetic monitoring, kullanıcılar ticket açmadan önce başarısızlık modlarını yakalar
  • Operasyonel review, yeşil dashboard'lara hızlıca göz atmak değil, gerçek verinin incelenmesini zorunlu kılar
  • DORA 2025 verilerinde kullanıcı deneyimiyle en yüksek korelasyonu gösteren platform yeteneği, iş sonucu hakkında net geri bildirimdi — başarısızlık durumunda kullanıcı, tam olarak neyin başarısız olduğunu ve ne yapması gerektiğini bilmelidir

Planlama ve teslimat

• Uzun vadeli projeler teklif belgesi gerektirir

  • Migrasyon, yeniden mimarileme ve yeni control plane gibi platform projeleri çeyrekler sürer
  • İyi bir teklif belgesinin vazgeçilmezleri: çözülmek istenen sorun, faydalanacak kişiler, kapsam, açıkça kapsam dışı olanlar, başarının tanımı
  • Kod yazmadan önce önce belge yazılmalı, review alınmalı ve ardından somut milestone'ları olan bir uygulama planına dönüştürülmelidir
  • "Uzun süren yıpratıcı süreç (long slog)" başarısızlık modu — projenin yıllarca sürmesi ve kimsenin nedenini artık hatırlamaması — neredeyse her zaman bu adımın atlanmasının sonucudur

• Bottom-up yol haritası planlaması

  • Platform yol haritasındaki dört iş türü: KTLO (keep-the-lights-on), liderlik talimatları, kendi kararıyla yapılan sistem iyileştirmeleri, doğrudan müşteri talepleri
  • Sıralama yalnızca müşteri talebine göre yapılamaz; KTLO birinci, talimatlar ikinci sıradadır, geri kalanı için paydaşlarla dürüst tartışmalar gerekir

• İki haftada bir başarılar ve zorluklar (Biweekly Wins and Challenges)

  • Her iki haftada bir kısa bir belge yazın: nelerin deploy edildiği (başarılar), nelerin tıkandığı (zorluklar); kısa, açık ve abartısız olsun
  • Bunun aynı anda üç etkisi vardır: ekip ilerlemeyi net ifade eder, paydaşlara gerçek durumu aktarır, zorlukları erkenden görünür kılarak liderlik desteğini tetikler
  • Yalnızca başarıların yer aldığı bir belge, kimsenin güvenmediği bir belgedir; bu yüzden zorlukları atlamayın

Yeniden mimarileme ve migrasyon

• v2 yerine yeniden mimarileme

  • Platform eskidiğinde "hadi v2 yapalım" içgüdüsü neredeyse her zaman yanlış cevaptır
  • v2 projelerinin başarısız olma nedenleri: v1 yatırımının dondurulması, işin beklenenden uzun sürmesi, v2'nin migrasyon maliyetinin kaçınılan yeniden mimarileme maliyetinden yüksek olması
  • Mevcut platformun içinde yeniden mimarileme yapın, mümkün olduğunca uyumluluğu koruyun ve alt ortamlar, yavaş rollout'lar ve tranche bazlı migrasyonlardan yararlanın
  • Dört planlama aşaması
    • Nihai mimari hedefi büyük düşünerek belirleyin
    • Migrasyon maliyetini hesaba katın (her zaman 2-3 kat)
    • Sürekli yatırımı haklı çıkaracak 12 aylık kilit sonuçları belirleyin
    • Liderliğin onayını alın ve beklemeye hazır olun

• Güvenlik mimariseldir

  • Güvenliği sonradan eklemek imkansızdır; mimari, tasarım anından itibaren asgari yetki, izolasyon ve izlenebilirliği zorunlu kılmalıdır
  • Eğer tüm ekiplerin doğru IAM binding'lerini hatırlaması gereken bir platform varsa, sorun ekiplerde değil platformdadır

• Migrasyon: hafife alınan zor problem

  • En yaygın anti-pattern'ler
    • Tüm ekiplere panoya yapıştırılacak talimatlar ve bir son tarih verip kendi başlarına migrasyon yapmalarını istemek
    • Net bir onramp ve offramp olmadan yalnızca talimat vermek
    • İstisnai kullanım senaryolarının long tail'ini hafife almak
  • Kolay migrasyon mühendisliği yöntemleri
    • Kullanım metadata'sını izleyerek eski sürümü kullananları tam olarak belirlemek
    • Eğer 200 ekip migrasyon yapacaksa, script'i uygulama ekipleri değil platform ekibi yazmalıdır
    • Yeni sistemin eski API'yi kullandığı şeffaf migrasyon mimarisi tasarlamak
    • Yeni ekiplerin self-service kullanabilmesi için onramp'i açık biçimde belgelemek
  • Talimat (mandate) bir ya da iki kez işe yarar; sonrasında gürültüye dönüşür
  • Çoğu durumda en iyi yaklaşım, yeni yolu yeterince iyi hale getirip eski yolun doğal olarak sönmesini sağlamaktır

• Hizmetten kaldırma (Sunsetting)

  • Bir ürünü ortadan kaldırmaktan korkmayın
  • Yarı desteklenen 7 deployment sistemi yerine sağlam tek bir deployment sistemi üstündür; hizmetten kaldırma, olgun ekiplerin özelliğidir

Paydaş ilişkileri

• Güç-ilgi matrisi (Power-Interest Grid)

  • Paydaşları yetki (power) ve ilgi (interest) eksenlerinde haritalayın
    • Yüksek yetki, yüksek ilgi: Düzenli güncellemeler ve istişare
    • Düşük yetki, düşük ilgi: Durum sayfası yeterlidir
  • İlgisi düşük bir VP'ye Kubernetes upgrade ayrıntıları vererek ekibin zamanını boşa harcamayın

• Aşırı paylaşım olmadan iletişim

  • Şeffaf olun ama fazlasını yapmayın — kıdemli liderlerin bilmesi gereken şey, üç gRPC retry stratejisinin tartışması değil, milestone'lara ulaşılıp ulaşılmadığı ve risklerdir
  • 1:1 toplantıları dikkatli kullanın ve beklentileri, taahhütleri görünür bir yerde takip edin

• İlişkileri bozmadan hayır demek

  • "Bu özelliği eklersek migrasyon bir çeyrek gecikir ve bunun şirkete maliyeti $X olur" örneğinde olduğu gibi iş etkisini net biçimde ortaya koyun
  • "Tavizle evet", "hayır deyip bir yol önermek" ve bazen shadow platform'a izin vermek, kavga etmenin maliyetinden daha iyi olabilir
  • Bütçe döneminde talepleri kişi bazında değil, ekip ve yetkinlik bazında paketleyerek sunun; neyin azaltılacağı ve neyin korunacağı konusunda güçlü bir görüşünüz olsun — aksi halde finans ekibi sizin yerinize karar verir ve yanlış karar verir

Başarının görünümü

• Hizalanmış platform (Aligned)

  • Amaç hizası (neden var olduğu), strateji hizası (bahislerin ekipler arasında tutarlı olması) ve plan hizası (milestone çakışması olmaması) gerekir
  • Runtime ekibi tamamen Kubernetes isterken gözlemlenebilirlik ekibi tüm framework'leri desteklemeye çalıştığında hizalama bozulması ortaya çıkar
    • Bu durum çelişkili müşteri rehberleri, mükerrer işler ve arada sıkışıp kalan öfkeli geliştiriciler olarak görünür
    • Çözüm uzlaşı (consensus) değil, ilkelere dayalı liderliktir

• Güvenilen platform (Trusted)

  • Güven yavaş inşa edilir ve tek bir kötü migration ile kaybedilir
  • Güven; işletim biçiminden (arıza sırasında iletişim, verilen sözleri tutma), yatırım biçiminden (satılan büyük bahislerin gerçekten dağıtıma alınması) ve teslim önceliklerinden oluşur
  • "Aşırı bağlı platform (overcoupled platform)" örneği: Platforma gereğinden fazla özel mantık konur ve her değişiklik aylar sürer — çözüm daha fazla mühendislik değil, kapsama dair varsayımları sorgulamaktır
    • Bazen güven sorunu çok az şey yapmaktan değil, çok fazla şey yapmaktan kaynaklanır

• Karmaşıklığı yöneten platform

  • Yazılım karmaşıklığı kaçınılmazdır, ancak arızi karmaşıklık (accidental complexity) değildir
  • İndirgenemez problem karmaşıklığı ile zayıf insan koordinasyonunun, aynı sorunu iki kez çözen shadow platform'ların ve sınırsız büyümenin yarattığı arızi karmaşıklığı ayırt edin
  • Üç pratik kaldıraç
    • Büyümeyi kontrol edin: Her şeyi destekleyen bir platform hiçbir şeyi iyi destekleyemez; kapsamı açıkça tanımlayın
    • Ürün keşfini (product discovery) yalnızca neyin ekleneceğini değil, neyin durdurulacağını belirlemek için de kullanın
    • Shadow platform'ları yönetin: Ekipler paralel çözümler geliştiriyorsa bu, platformda gerçekten eksik bir şey olduğu ya da birilerinin alanı genişletmeye çalıştığı anlamına gelir — her iki duruma da müdahale etmek gerekir

• Sevilen platform (Loved)

  • Üç biçimi vardır
    • "Sadece çalışıyor" sevgisi: Kullanıcıların çoğu platformun farkında bile olmaz, deployment yapılır, CI geçer — sıkıcı olması en büyük övgüdür
    • "Büyü gibi" sevgi: Ayrı açıklama gerektirmeden bariz şekilde doğru davranan bir CLI komutu gibi küçük sevinçler
    • "Açıkça görülen" sevgi: Anket skorları, retention, organik benimseme ve platformun başka ekiplere tavsiye edilmesi
  • Platform seviliyorsa bütçe talep edildiğinde insanlar sizin yerinize mücadele eder; sadece tolere ediliyorsa tek bir kötü incident ile yerinin doldurulma riski doğar

Sahadaki öncelikler

• Sıfırdan başlarken ya da yeniden kurarken kabaca izlenecek sıra
  • 1. öncelik: Destek kapsamını belirleyin, belgeleyin ve savunun
  • 2. öncelik: Wiki yerine yazılım soyutlamalarına yatırım yapın (Score, Crossplane, şirket içi SDK'lar gibi gerçek API'leri olan yazılımlar)
  • 3. öncelik: Metadata registry kurun (Backstage vb. ile neyin nerede çalıştığını ve sahibinin kim olduğunu anlayın)
  • 4. öncelik: En çok ses çıkaran ekip için değil, ortanca ekip için inşa edin
  • 5. öncelik: SLO, on-call, destek katmanları gibi operasyonu birinci sınıf özellik olarak ele alın
  • 6. öncelik: Sistem yetkinliği kadar empati yeteneğine göre işe alım yapın
  • 7. öncelik: İki haftada bir sonuçlar ve zorluklar paylaşımı, şeffaf roadmap, dürüst paydaş yönetimi gibi acımasız iletişim
  • 8. öncelik: Gerekli olmayan şeyleri sonlandırın, birleştirin, reddedin
• DORA verileriyle tutarlı biçimde, platform kalitesi yapay zeka benimsenmesi dahil her şey için bir çarpandır — kötü bir platform yapay zeka araçlarının kaosu büyütmesine, iyi bir platform ise throughput'u artırmasına neden olur
• Roketi yapmadan önce zemini inşa etmeniz gerekir

[kalista22]

Bence iç iletişim her şeyden daha önemli.