# Platform Engineering Nedir ve Ne Zaman Değer Yaratır? URL: https://upstreamapi.com/tr/journal/platform-engineering-nedir Type: blog Locale: tr Published: 2026-09-19 Updated: 2026-09-19 --- > Platform engineering, dahili geliştirici platformu (IDP) inşa etme ve işletme disiplinidir. Ekip yapısı, golden path, DORA metrikleri ve yatırımın işe yarayıp yaramadığını inceler. ## Platform Engineering Nedir ve Ne Zaman Değer Yaratır? Platform engineering, ürün ekiplerine altyapıyı doğrudan yönetmek zorunda kalmadan production'a giden yapılandırılmış bir yol sunan dahili geliştirici platformu (IDP) oluşturma ve işletme disiplinidir. Platform engineering nedir sorusuna kısa cevap: DevOps değil, DevOps pratiklerini self-servis araçlara dönüştüren özel bir ekip topolojisi. Mid-2026 itibarıyla bu terim aylık yaklaşık 18.000 kez aranıyor. Bu rakam sektörün nerede durduğunu anlatıyor: pek çok mühendis hala bu disiplinin DevOps'un yeni bir etiketi mi, SRE'lerin terfi mi, yoksa gerçek bir organizasyonel değişim mi olduğunu tartışıyor. Üçüncü seçenek doğru. Bu bir başlangıç kılavuzu değil. CI/CD'yi tanımlamıyoruz, Kubernetes'i sıfırdan anlatmıyoruz. Bu yazı platform mühendisleri, SRE lead'ler ve platform yatırımını CTO'ya gerekçelendirmesi gereken teknik yöneticiler için bir harita. ## Platform Engineering, DevOps'un Yeni Etiketi Değil Bu ayrım kritik ve operasyonel olarak önemli. DevOps bir pratikler bütünü ve kültürel normlar kümesidir. Platform engineering ise bir ekip topolojisi olup bir ürüne sahiptir. İkisi birbirinin yerine geçemez. DevOps kültürü, geliştiricilerin kendi deployment'larını sahiplenmesini, değişikliklerini production'a kadar takip etmesini teşvik eder. Bu doğru ve vazgeçilmezdir. Ancak 20 mühendisli bir organizasyonda bu, sağlıklı öz-disiplinle yönetilebilir. 100 mühendiste darboğaza dönüşür. Platform ekibi, bu sorumluluğu ölçekte uygulanabilir kılan makineyi inşa eder: CI/CD pipeline şablonları, deployment soyutlamaları, observability stack'leri, secrets yönetimi, maliyet koruyucuları. Bunların hepsini uygulama ekiplerinin self-servis arayüzler aracılığıyla tükettiği dahili bir ürün olarak sunar. 20 mühendisli bir organizasyonda bu ayrım akademik kalır. Bu gerçektir. 80 mühendiste ise altyapı bilgisinin bir ya da iki ops kişisinde birikmesi ile her ekibin ticket açmak zorunda kalmadan kullanabildiği döşenmiş bir yol arasındaki farka dönüşür. Fark ölçülebilir ve somuttur. SRE ile ilişkisi rekabetçi değil, tamamlayıcıdır. SRE, sistemlerin production'da nasıl davrandığını iyileştirir. Platform engineering, organizasyonların yazılım gönderme eylemini nasıl ölçeklendirdiğini iyileştirir. Pratikte pek çok platform ekibi SRE geçmişinden çıkar; SRE'lerin üretim sistemlerine uyguladığı SLO tabanlı güvenilirlik mühendisliği genellikle platform deployment gate'lerine ve otomatik rollback mantığına doğrudan kodlanır. Platform engineering'i DevOps'tan ayıran somut örnek şudur: bir DevOps kültüründe her ekip kendi CI/CD pipeline'ını yönetir. Bu esnektir ama tekrardır. Platform engineering yaklaşımında tek bir ekip bu pipeline'ı şablon olarak sunar; uygulama ekipleri şablonu benimser ve kendi ihtiyaçlarına göre özelleştirir. Tekrar eden çalışma platformda bir kez yapılır, tüm ekipler faydasını görür. ## İç Geliştirici Platformu (IDP): İçinde Gerçekte Ne Var? IDP tek bir araç değildir. Tipik olarak şunlardan oluşan bir sistem bileşimidir: - Bir deployment mekanizması (Kubernetes, serverless çalışma ortamı veya bunların üzerine inşa edilmiş yönetimli bir soyutlama) - Önceden onaylanmış yapılandırmalarla CI/CD pipeline şablonları - Kapsamlı erişim ve otomatik döndürme özellikli bir secrets yöneticisi - Servis türüne göre önceden yapılandırılmış dashboard'larla observability stack'i (metrikler, loglar, trace'ler) - Neyin nerede çalıştığını ve kimin sorumlu olduğunu belgeleyen bir servis kataloğu - 2026 itibarıyla fiili standart haline gelen Backstage gibi bir developer portal, tüm bunları tek arayüzden erişilebilir kılar Kritik tasarım kararı soyutlama düzeyidir. Ham Kubernetes'i açığa çıkarırsanız, geliştiriciler zamanlarını Helm chart debug'lamakla harcar. Fazla soyutlarsanız, standart dışı workload'lara yanıt verme kapasitenizi yitirirsiniz. Bu tuzağa düşmek kolaydır ve maliyeti yüksektir. Platform ekibinin görevi, kullanım senaryolarının yüzde seksenini değişiklik gerektirmeden karşılayan soyutlama düzeyini bulmaktır. Soyutlamanın altına inmesi gereken ekipler için kaçış kapısını belgelemek de aynı derecede önemlidir. Bu kaçış kapısı her seferinde platform ekibi onayı değil, yazılı gerekçe gerektirmelidir. Ölçeklenebilirlik ile kaos arasındaki fark tam olarak budur. Servis kataloğu çoğu zaman gözden kaçan bir bileşendir. Hangi servisin kimin sorumluluğunda olduğunu, hangi ekibin bakımını üstlendiğini ve servisin hangi bağımlılıklara sahip olduğunu merkezi olarak belgeleyen bir katalog, özellikle gece yarısı incident sırasında kritik hale gelir. Backstage bu ihtiyacı karşılayan en yaygın açık kaynak çözüm olarak öne çıkıyor. IDP tasarımında en sık görülen hata, platformu mevcut araçların toplamı gibi sunmaktır. Gerçek bir IDP, araçları değil iş akışlarını soyutlar. Bir geliştirici yeni bir mikroservis başlatmak istediğinde platform ona araçlar listesi değil, tamamlanmış bir iş akışı sunar: depo oluşturma, CI/CD yapılandırma, secrets enjeksiyonu ve ilk dashboard kurulumu tek bir adımda gerçekleşir. ![Platform engineering mimarisi ve IDP bileşenleri](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/29154c-inline1.webp) ## Platform Ekibi Ne Zaman Gerçek Değer Yaratır? Pratisyen verileri genellikle 30 ila 80 mühendisi dönüm noktası olarak işaret eder. 30'un altında ek yük haklı çıkarılamaz; bileşenler uygulama ekipleri tarafından yönetilebilir durumdadır. 80'in üzerinde özel bir platform ekibi yapısal bir zorunluluk haline gelir, bir tercih değil. Uyarı sinyali faturadan önce gelir. Uygulama ekiplerinin sprint kapasitesinin yüzde yirmisinden fazlasını kendi ürünleriyle ilgisi olmayan ortak altyapı sorunlarına harcadığı an budur: izinler, ağ yapılandırması, secrets döndürme, CI/CD debug. Üretkenliğin gerçekten acı çekmeye başladığı nokta tam burası. Bu noktayı geçtikten sonra platform yatırımı artık bir seçim değil, yapısal bir ihtiyaçtır. Platform ekibinin etki alanı sadece araçlarla sınırlı değildir. Deployment süreçlerindeki bilgi asimetrisi de bir sorundur: bir servisi production'a göndermek için gerekli adımları yalnızca birkaç kıdemli mühendis biliyorsa, bu bilgi herkese açık ve belgelenmiş bir süreçten çok kişisel uzmanlığa dönüşmüş demektir. Platform ekibi bu bilgiyi kod ve otomasyon aracılığıyla demokratikleştirir. ## Altın Yol (Golden Path): Zorunluluk mu, Lüks mü? Altın yol, platform ekibinin oluşturduğu ve sürdürdüğü, kod'dan production'a uzanan taraflı ve önceden test edilmiş güzergahtır. Varsayılan olarak güvenlik taraması, uyumluluk kontrolleri ve observability yapılandırmasını üstlenir. Ekipler, belgelenmiş kaçış kapıları aracılığıyla altın yoldan sapabilir; ancak sapmayı yazılı olarak gerekçelendirmeleri beklenir. Platform ekibi yaygın sapmaları çeyreklik olarak gözden geçirir ve hangilerini altın yola dahil edeceğine karar verir. Operasyonel değer şuradan gelir: ekiplerin production'da çalışan standart bir servis başlatmak için altyapı ekibine bağımlı olmadığı bir gün. Self-servis, ticket kuyruğu yerine geçer. Bu ayrımı yaşayan ekipler, deployment sıklığının ölçülebilir biçimde arttığını ve değişiklik hata oranının düştüğünü görür. Altın yolun en önemli özelliği, kullanımı keyfi değil tercih edilen bir seçim haline getirmesidir. Zorla dayatılmış bir standart uyumsuzluğa yol açar. İyi tasarlanmış bir altın yol ise ekiplerin çoğunun doğal olarak tercih ettiği, en az dirençli güzergahtır. ## DORA Metrikleri: Platform Ekibi Neyi Gerçekten Etkiler? Platform ekipleri için birincil kaldıraçlar deployment sıklığı ve değişiklik hata oranıdır. Deployment sıklığı doğrudan etkilenir: yapılandırılmış ve otomatize edilmiş bir pipeline ile ekip, haftada bir deployment'tan günde beşe geçebilir. Bu geçiş otomatik değildir; ancak altyapı engelleri ortadan kalktığında mümkün hale gelir. Değişiklik hata oranı da etkilenir: SLO ihlali üzerine otomatik rollback, insan müdahalesini beklemeden hataları yakalar ve geri alır. MTTR (ortalama kurtarma süresi) da platformdan doğrudan etkilenir. Hangi servisin ne zaman bozulduğunu izleyebileceğiniz düzgün yapılandırılmış observability olmadan, gece üçte PagerDuty uyarısı alan mühendis tahmin oyunu oynar. Platform o observability altyapısını sağlarsa, MTTR doğrudan kısalır. Gece üçte düşünmek istemezsiniz. Bir düğmeye basmak istersiniz. Değişiklik için teslim süresi her iki yönde gidebilir. Platform süreç ek yükü getiriyorsa uzar, kaldırıyorsa kısalır. Her iki sonuç da mümkündür; ölçün. Geniş kapsamlı mühendislik analizleri, iyi işleyen bir platform ekibine sahip organizasyonlarda deployment sıklığının ortalama birkaç kat arttığını, değişiklik hata oranının ise önemli ölçüde gerilediğini gösteriyor. Bu rakamlar bir araç değişiminden kaynaklanmıyor; süreç sahipliğinin ve otomasyon kapsama oranının değişmesinden geliyor. ![DORA metrikleri ve platform engineering performans göstergeleri](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/fc0645-inline2.webp) ## Inner Platform Effect: Kaçınılması Gereken Yapısal Tuzak Inner platform effect, bir platform ekibinin soyutlamalarını her olası dahili kullanım senaryosunu karşılayacak biçimde aşırı genelleştirmesi ve sonuçta soyutladığı altyapıdan daha yavaş ve kullanması daha zor bir sistem üretmesidir. Bu bir özellik değil, bir başarısızlık modudur. Tanı koymak kolaydır: platform ekibi öncelikle platform genelinde kabiliyetler inşa etmek yerine tek seferlik isteklere yanıt veriyorsa, ekip servis moduna kaymış demektir. Bu kaymanın önemi nedir? Servis modundaki bir platform ekibi bir darboğaçtan başka bir şey değildir. Yarattığı altyapı karmaşıklığını biraz farklı bir biçimde tekrar üretir. Korunma yolu nettir: platform ekibi, hangi isteklerin tek seferlik servis talebi olduğunu ve hangilerinin platform genelinde kabiliyete dönüşmesi gerektiğini düzenli olarak gözden geçirmelidir. Platform roadmap'i bu ayrıma dayanmalıdır. İkisini karıştırmak ölçeği engeller ve ekibi kalıcı darboğaca dönüştürür. Bu tuzaktan kaçınmanın pratik yolu, uygulama ekiplerinin geri bildirimini dönüştürecek net bir kanal açmaktır. Çeyreklik platform kullanım değerlendirmeleri, hangi özelliklerin gerçekten kullanıldığını ve hangi sürtünme noktalarının devam ettiğini ortaya koyar. Platform roadmap'ini bu veriye göre önceliklendirmek, ekibin servis moduna sürüklenmesini önler. ## Series B'de Platform Ekibi Nasıl Görünür? Tipik yapı 3 ila 6 mühendistir: mimari yönüne sahip bir platform lead veya staff engineer, altyapı ya da dağıtık sistemler geçmişine sahip 2 ila 4 senior mühendis, platformun kendisi için tanımlanmış SLA'lar ve uygulama ekibi lead'leriyle düzenli temas noktaları. Ekip, yalnızca altyapı uptime'ıyla değil, uygulama ekibi sonuçlarıyla ölçülür: deployment sıklığı, MTTR, planlanmamış altyapı çalışmasına harcanan zaman. Bu ölçüm yaklaşımı kritiktir. Platform ekibinin değerini altyapı odaklı metriklerle ölçmek, ekibin asıl misyonunu gizler. Çoğu Series B şirketinde platform ekibi tam anlamıyla bağımsız değildir. Uygulama ekipleriyle haftalık touchpoint'ler, platform kullanımına ilişkin geri bildirim döngüleri ve çeyreklik roadmap paylaşımları ekibin izolasyona girmesini engeller. ## Platform Yatırımının Gerçekten İşe Yarayıp Yaramadığını Nasıl Anlarsınız? Bunu ölçmek için bir başlangıç noktasına ihtiyacınız var. Platform ekibini kurmadan önce şu soruların yanıtını kayıt altına alın: Uygulama ekipleri sprint kapasitelerinin yüzde kaçını altyapı sorunlarına harcıyor? Ortalama bir deployment ne kadar sürüyor? Son üç ayda kaç kez production'da elle revert yapıldı? Bu sayılar altı ay sonra iyileşmiş görünüyorsa platform yatırımı işliyor demektir. Kötüleşmiş veya değişmemişse, ya soyutlama düzeyinin yanlış olduğunu ya da platform ekibinin servis moduna kayıp kaymadığını araştırın. Veri varsa tartışma biter. Platform engineering'in özü basittir: ürün ekiplerinin kendi ürünlerine odaklanabileceği bir ortam yaratmak. Bu ortamı inşa etmek, sürdürmek ve ölçmek platform mühendislerinin işidir. Geri kalanı ayrıntıdır. Verilerle başlayın, verilerle takip edin. Post-mortem'larınıza bakın; kaç tanesinde altyapı yapılandırması veya deployment süreci bir katkıda bulunan faktör olarak yer alıyor? Bu oran düşükse platform ekibi değer katıyor demektir. Hala yüksekse, görev tamamlanmadı. Yeterince açık bir metrik. ## FAQ ### Platform engineering ile DevOps arasındaki fark nedir? DevOps, ekiplerin yazılımlarını geliştirmeden production'a kadar sahiplenmesini teşvik eden bir pratikler ve kültürel prensipler kümesidir. Platform engineering bir ekip topolojisidir: özel bir ekip, DevOps pratiklerini self-servis araçlara kodlayan bir dahili geliştirici platformu (IDP) inşa eder ve işletir. DevOps ekiplere ne yapmaları gerektiğini söyler. Platform engineering, ekiplerin bunu yarı zamanlı altyapı mühendisi olmadan yapabilmesi için altyapıyı inşa eder. ### İç geliştirici platformu (IDP) nedir? IDP, platform ekibinin dahili kullanım için oluşturduğu ve sürdürdüğü araçlar, iş akışları ve soyutlamalar kümesidir. Tipik olarak deployment pipeline'ları, servis kataloğu, secrets yöneticisi, önceden yapılandırılmış dashboard'larla observability stack'i ve bir developer portal içerir. Amaç, ürün ekiplerine her ekipte derin altyapı bilgisi gerektirmeden production'a giden bir yol sunmaktır. ### Bir mühendislik organizasyonu ne zaman özel bir platform ekibi kurmalı? Çoğu pratisyen verisi, 30 ila 80 mühendisi bir kırılma noktası olarak gösterir. 30'un altında ek yük haklı çıkarılamaz. 80'in üzerinde özel bir platform ekibi yapısal bir zorunluluk haline gelir. Öncü sinyal, uygulama ekiplerinin sprint kapasitesinin yüzde yirmisinden fazlasını ürünleriyle ilgisi olmayan ortak altyapı sorunlarına, yani izinlere, ağa, secrets döndürmeye ve CI/CD debug'a harcadığı andır. ### Platform ekipleri hangi DORA metriklerini doğrudan etkiler? Deployment sıklığı ve değişiklik hata oranı birincil kaldıraçlardır. İyi yönetilen bir platform ekibi, SLO ihlali üzerine otomatik rollback aracılığıyla MTTR'yi de kısaltır; bu, olay tespiti ile çözüm arasındaki süreyi azaltır. Değişiklik için teslim süresi ise platformun getirdiği veya kaldırdığı süreç ek yüküne göre her iki yönde hareket edebilir. ### Altın yol (golden path) nedir? Altın yol, platform ekibinin oluşturduğu ve sürdürdüğü, kod'dan production'a uzanan taraflı ve önceden test edilmiş güzergahtır. Varsayılan olarak güvenlik taraması, uyumluluk kontrolleri ve observability yapılandırmasını üstlenir. Ekipler altın yoldan sapabilir; ancak sapmayı yazılı olarak gerekçelendirmeleri beklenir. Platform ekibi yaygın sapmaları çeyreklik olarak gözden geçirir ve hangilerini altın yola dahil edeceğine karar verir. ### Inner platform effect nedir? Inner platform effect, bir platform ekibinin soyutlamalarını aşırı genelleştirerek soyutladığı altyapıdan daha yavaş ve kullanması daha zor bir sistem üretmesidir. Bir özellik değil, başarısızlık modudur. Tanı: platform ekibi platform genelinde kabiliyetler yerine öncelikle tek seferlik isteklere yanıt veriyorsa, servis moduna kaymış demektir. ### Platform engineering ile SRE nasıl ilişkilidir? SRE, sistemlerin production'da nasıl davrandığını iyileştirir. Platform engineering, organizasyonların yazılım gönderme eylemini nasıl ölçeklendirdiğini iyileştirir. Pratikte pek çok platform ekibi SRE geçmişinden çıkar; SRE'lerin üretim sistemlerine uyguladığı SLO tabanlı güvenilirlik mühendisliği, platform deployment gate'lerine ve otomatik rollback mantığına doğrudan kodlanır.