- 017/24 operasyon haftada 168 saat kapsama gerektirir; iç ekip maliyetini hesaplarken nöbet ve yedek personeli ayrı kalem olarak ekleyin.
- 02Platform şirketiniz için bir iç ürünse kendi ekip daha güçlüdür; platform gerekli ama stratejik değilse yönetilen veya hibrit model daha uygun olabilir.
- 03Yönetilen hizmette altyapı, kod ve otomasyon müşterinin hesaplarında tutulursa sağlayıcı değişikliği daha kontrollü yapılır.
- 04Kubernetes sürüm serileri yaklaşık 14 ay desteklenir; cluster işletiminde yükseltme planı tek seferlik kurulumdan ayrı bir sorumluluktur.
Kısaca
Yönetilen DevOps hizmeti; 7/24 operasyon, farklı uzmanlıklar ve belirli bir hizmet seviyesi gerektiğinde avantajlıdır. Kendi ekip ise platformun ürünün parçası olduğu, mimari kararların içeride kalması gerektiği ve iç araçların stratejik olduğu yapılarda daha uygundur. Üretim operasyonunu haftanın 168 saati kapsayacak nöbet ve yedekleme düzenini içeride kurabiliyorsanız kendi ekip; kuramıyorsanız yönetilen veya hibrit modeli değerlendirin. Dynamis Teknoloji, Raff platformunu sıfırdan geliştiren ekip olarak kararı ekip sayısından önce sorumluluk sınırı ve devir planı üzerinden verir.
Kullanım durumuna göre hızlı karar
Kararı şirket büyüklüğü tek başına belirlemez. Üretim sorumluluğunun kimde olacağı, platformun ürüne ne kadar yakın olduğu ve erişim modeliniz daha güçlü sinyallerdir.
| Durumunuz | Uygun yaklaşım | Neden |
|---|---|---|
| Tek ürün, küçük teknik ekip, 7/24 beklentisi | Yönetilen veya hibrit hizmet | Nöbet, yükseltme ve rutin operasyonu ürün geliştirmeden ayırır |
| İçeride deneyimli DevOps mühendisi var ama tek kişi riski oluşuyor | Hibrit model | Mimari içeride kalır, operasyon yükü ekipler arasında paylaşılır |
| Platform şirketin rekabet avantajının parçası | Kendi platform ekibi | İç araçlar ve geliştirici deneyimi sürekli ürün kararı gerektirir |
| Üretim erişimi sıkı denetime tabi | Kendi ekip veya müşterinin hesabında yönetilen hizmet | Yetki sınırları, kayıt ve onay akışı şirket politikanızla uyumlu kalır |
| Kubernetes işletiliyor ve yükseltme takvimi sahipsiz | Yönetilen veya hibrit hizmet | Sürüm, güvenlik ve bakım işleri düzenli operasyon ister |
| Birden fazla ürün ekibi aynı ortak platformu kullanıyor | Kendi platform ekibi veya güçlü hibrit model | Platform artık tek projeden çok iç ürün haline gelir |
Yan yana karşılaştırma
İki model arasındaki temel fark araç seti değil, sahiplik modelidir. Aynı Kubernetes, CI/CD ve gözlemlenebilirlik bileşenleri iki tarafta da kullanılabilir; fark, kararın ve operasyon sorumluluğunun kimde olduğudur.
| Konu | Kendi DevOps ekibi | Yönetilen DevOps hizmeti |
|---|---|---|
| Ürüne yakınlık | Yüksek | Hizmet kapsamıyla sınırlı |
| Mimari karar | İç ekip verir | Müşteriyle birlikte tanımlanır |
| 7/24 olay müdahalesi | İç nöbet düzeni gerekir | Sözleşmede varsa sağlayıcı üstlenir |
| Bilgi devamlılığı | Ekip ve belge kalitesine bağlı | Sağlayıcı ekibi ve belge kalitesine bağlı |
| Uzmanlık genişliği | İşe alınan ekibin profiline bağlı | Sözleşmedeki uzmanlık kapsamına bağlı |
| İç geliştirici platformu | Uzun vadede güçlü sahiplik | Standart altyapı ve otomasyonda daha uygun |
| Erişim kontrolü | Tamamen şirket politikasında | Müşteri hesabında kurulursa şirket politikası korunabilir |
| Sağlayıcı değişimi | Yok | Devir planı ve altyapı sahipliği kritik |
| Maliyet modeli | Personel ve operasyon maliyeti | Hizmet bedeli ve iç sahiplik maliyeti |
Kendi ekibin kazandığı yerler
Kendi ekip, altyapı kararları ürün kararlarından ayrılamadığında güçlüdür. Platform ekibi uygulama mimarisini, yayın akışını, güvenlik ihtiyaçlarını ve geliştirici deneyimini aynı şirket bağlamında görür.
DORA, platform mühendisliğini yalnızca bir altyapı bilet kuyruğu olarak değil, geliştiricilere otomasyon ve self-service sağlayan iç ürün olarak tanımlar. 2025 araştırmasında kaliteli platformların geliştiricilerin bağımsız çalışmasını desteklediği, ancak kötü tasarlanmış platformların yeni darboğazlar oluşturabildiği vurgulanır.
Bu nedenle kendi ekibin en güçlü olduğu senaryo "bir DevOps mühendisi işe aldık" değildir. Ortak platformu kullanan birden fazla ürün ekibi, platform için net ürün sahipliği ve geliştirici geri bildirimi varsa iç platform ekibi anlamlı hale gelir.
Kendi ekip ayrıca şu durumlarda avantaj sağlar:
- Üretim mimarisi her gün ürün koduyla birlikte değişiyorsa
- Şirkete özel dağıtım, test veya veri iş akışları geliştiriyorsanız
- Altyapı kararları doğrudan ürün performansına veya müşteri deneyimine yansıyorsa
- Erişim yetkileri ve değişiklik onayları tamamen içeride kalmak zorundaysa
Bu avantajların bedeli operasyon sorumluluğudur. Olay müdahalesi, yama, sertifika yenileme, yedekleme testi ve sürüm yükseltme için ayrı sahipler tanımlanmadıysa "kendi ekip" yalnızca sahipliği değil, tek kişi riskini de içeride tutar.
Yönetilen hizmetin kazandığı yerler
Yönetilen hizmet, platformun şirket için gerekli olduğu ama ayrı bir iç ürün haline gelmediği yapılarda daha verimlidir. Amaç mimari sahipliği dışarı vermek değil, tekrar eden operasyonu ve nöbet yükünü tanımlı bir hizmet seviyesine bağlamaktır.
7/24 kapsama haftada 168 saattir. Bu sayı tek başına kaç kişi gerektiğini söylemez; çalışma saatleri, vardiya süresi, izin, tatil ve ikinci seviye destek politikası sonucu değiştirir. Ancak maliyet modelinde nöbeti ayrı kalem olarak hesaplamamak, iç ekibin gerçek yükünü eksik gösterir.
Dynamis, yönetilen hizmet kararında 7/24 kapsamanın haftada 168 saat olduğunu maliyet modelinin ayrı kalemi olarak ele alır.
Kubernetes kullanılan ortamlarda yükseltme işi de süreklidir. Kubernetes topluluğu aktif patch sürüm serilerini yaklaşık 14 ay destekler. Bu nedenle cluster kurulumu bir defalık proje değildir; yükseltme planı, test ve geri dönüş prosedürü operasyonun parçasıdır.
Dynamis, Kubernetes işlerinde yaklaşık 14 aylık sürüm desteğini yükseltme takvimine başlangıçta yazar.
Yönetilen hizmet şu alanlarda avantaj sağlar:
- Nöbet ve olay müdahalesinin sözleşmeyle tanımlanması
- Kubernetes, CI/CD, gözlemlenebilirlik ve yedekleme gibi farklı alanların tek operasyon planında toplanması
- Sürüm yükseltme ve bakım takviminin belirli bir ekibe atanması
- Tek kişide biriken operasyon bilgisinin runbook ve ortak süreçlerle dağıtılması
- Yeni iç ekip kurulurken geçiş dönemi için operasyon devamlılığı sağlanması
İki modelin de çözmediği sorunlar
Kötü sahiplik modeli, iki tarafta da kötü sonuç verir. İç ekip kurmak otomatik olarak daha hızlı teslimat sağlamaz; yönetilen hizmet almak da otomatik olarak operasyon riskini ortadan kaldırmaz.
DORA'nın güncel araştırması platform kalitesini kullanıcı odaklılık, self-service ve açık geri bildirimle ilişkilendirir. Platform ekibi yalnızca ticket alan bir ekip haline gelirse yeni darboğaz oluşur. Aynı sorun yönetilen hizmette de görülür: her küçük değişiklik sağlayıcı onayı bekliyorsa hizmet, ürün ekibinin hızını düşürür.
İki modelde de şu soruların cevabı yazılı olmalıdır:
- Üretime kim erişebilir?
- Bir olayda ilk müdahaleyi kim yapar?
- Mimari kararı kim onaylar?
- Yedekleme ve geri dönüş testinin sahibi kimdir?
- Sağlayıcı veya çalışan ayrılırsa sistem kime ve nasıl devredilir?
Dynamis'te devir planını üç varlıkla başlatıyoruz: erişim matrisi, runbook ve altyapı deposu.
Üç yıllık toplam maliyet formülle karşılaştırılır
Sabit bir "kendi ekip daha pahalı" veya "yönetilen hizmet daha ucuz" kuralı yoktur. Doğru karşılaştırma, iki modelde aynı sorumluluk kapsamını üç yıl boyunca fiyatlamaktır.
| Kalem | Kendi ekip | Yönetilen hizmet | Hibrit model |
|---|---|---|---|
| Personel | Tam zamanlı ekip maliyeti | İç hizmet sahibi | Daha küçük iç ekip |
| İşe alım ve işe alışma | Şirkete ait | Düşük veya yok | İç rol sayısına bağlı |
| 7/24 nöbet | İç ekipte planlanır | Sözleşmeye göre | Paylaştırılır |
| Araç ve lisanslar | Şirket öder | Sözleşmeye göre | Paylaştırılır |
| Yükseltme ve bakım | İç ekip zamanı | Sözleşmeye göre | Paylaştırılır |
| Dokümantasyon ve devir | İç süreç | Sözleşmede tanımlanmalı | İki taraf birlikte |
| Sağlayıcı bağımlılığı | Yok | Mimariye göre değişir | Daha düşük |
| Ürün bağlamı | En yüksek | İç sahip kadar | Yüksek |
Kendi ekip için üç yıllık hesap; tam yüklü personel maliyeti, işe alım, işe alışma, araçlar, nöbet ve yedek personel kalemlerini içerir. Yönetilen hizmet için aylık hizmet bedeline içeride kalacak ürün sahibi veya teknik sorumlunun zamanı eklenir. Hibrit modelde ise içeride mimari sahipliği tutup tekrar eden operasyonu dışarıda fiyatlarsınız.
Dynamis hizmet fiyatını makaleye sabitlemiyoruz. Güncel kapsam ve fiyatlandırma için DevOps hizmeti üzerinden değerlendirme yapılır.
Yönetilen hizmetten kendi ekibe geçiş baştan planlanır
İyi bir yönetilen hizmet, kendi ekibinizi kurmanızı zorlaştırmamalıdır. Geçiş planı sözleşme bittiğinde değil, sözleşme başında yazılmalıdır.
Üç kural bağımlılığı azaltır:
- Altyapı sizin hesabınızda dursun. Bulut hesabı, cluster, DNS, sertifikalar ve gözlemlenebilirlik kaynaklarının sahipliği sizde kalsın.
- Kod ve otomasyon sizin depolarınızda dursun. Terraform, manifestler, CI/CD tanımları ve runbook aynı erişim modeline bağlansın.
- Devir kriteri yazılı olsun. Erişim listesi, runbook, yedekleme prosedürü ve açık operasyon işleri teslim kalemleri olarak tanımlansın.
Dynamis'te yönetilen altyapıyı müşterinin kendi hesaplarında kurabilmemizin nedeni budur: sağlayıcı değişikliği yeni bir altyapı göçüne dönüşmemelidir.
Sık yapılan hatalar
Tek kişiyi ekip sanmak: İçeride bir DevOps mühendisi olması, nöbet ve yedekleme düzeninin kurulduğu anlamına gelmez. İzin, hastalık ve olay çakışması için yedek sorumluyu baştan tanımlayın.
Yönetilen hizmeti yalnızca aylık fiyata göre karşılaştırmak: Ucuz teklifin dışında kalan olay müdahalesi, yükseltme veya yedekleme işi daha sonra ayrı maliyet olur. Aynı kapsamı karşılaştırın.
Erişim modelini belirsiz bırakmak: Sağlayıcının hangi üretim kaynaklarına hangi yetkiyle gireceğini sözleşme ve teknik politika birlikte belirlemelidir.
Dokümantasyonu son aya bırakmak: Devir için gereken runbook ve altyapı kodu günlük operasyonun parçası değilse sözleşme sonunda eksik kalır.
Platformu ticket masasına çevirmek: DORA'nın platform mühendisliği yaklaşımında amaç geliştiricinin bağımsızlığını artırmaktır. İç veya dış ekip her değişikliği manuel onaya bağlıyorsa platform yeni bir darboğaz yaratır.
Önerimiz
Platform şirketiniz için bir iç ürünse, kendi platform ekibinizi kurun. Platform gerekli ama rekabet avantajınızın merkezinde değilse, yönetilen hizmet veya hibrit modelle operasyonu tanımlı sorumluluklara ayırın.
Kararı ekip sayısıyla değil üç soruyla verin: 7/24 operasyonu kim taşıyacak, mimari karar kimde kalacak ve hizmet bittiğinde altyapıyı kim devralacak? Bu üç soruya net cevap veremiyorsanız, organizasyon modeliniz henüz tamamlanmamıştır.
Dynamis'in DevOps hizmeti, müşterinin hesabında çalışan altyapı, yazılı erişim sınırları ve devir planı üzerine kurulabilir. Kubernetes tarafını ayrıca değerlendiriyorsanız Kubernetes'e geçiş rehberini inceleyin.
Sırada ne var
- Küçük ekip için Kubernetes: ne zaman fazla gelir?: yönetilen hizmet kararından önce platform karmaşıklığının küçük ekip için gerekli olup olmadığını değerlendirin.
- DevOps nedir? Yazılım ekipleri için nasıl çalışır?: ekip kurma kararından önce DevOps çalışma modelini, CI/CD ve production ownership yaklaşımını netleştirin.
- Kubernetes ekibi kurmak mı, operasyonu dış kaynak kullanmak mı?: genel DevOps build-vs-buy kararını Kubernetes production operasyonu özelinde detaylandırın.
- Kubernetes'e geçiş: 14 günde üretime hazır cluster planı: cluster işletiminin hangi operasyonları sürekli hale getirdiğini görün.
- AWS'den çıkış: maliyeti düşüren bulut göçü planı: bulut göçünde iç ekip ve sağlayıcı sorumluluğunu ayırın.
- Bulut sunucu mu, yönetilen altyapı mı?: yalnız VM satın almak ile sürekli production operasyonu dış kaynak kullanmak arasındaki farkı karşılaştırın.
- Yedek geri yükleme testi: aylık restore planı: yönetilen veya iç ekip modelinde restore testinin sahibini ve ölçülebilir RPO/RTO hedeflerini tanımlayın.
- 3-2-1 yedekleme kuralı: operasyon modelinden bağımsız olarak geri dönüş sorumluluğunu planlayın.
Kaynaklar
- DORA, Platform engineering capability
- DORA, Software delivery performance metrics
- Kubernetes, Patch releases and support period
Kaynaklar
- 1.DORA Platform engineering capabilityGoogle Cloud DORA · 2026-09-19
- 2.DORA software delivery performance metricsGoogle Cloud DORA · 2026-09-19
- 3.Kubernetes patch releases and support periodThe Kubernetes Authors · 2026-09-19
Sık sorulan sorular
İç ekibimiz varsa yönetilen hizmet gereksiz mi?
Hayır. İç ekip ürün ve mimari sahipliğini korurken yönetilen hizmet nöbet, yükseltme, gözlemlenebilirlik ve rutin operasyonu üstlenebilir. Sorumluluklar ve üretim erişimi sözleşmede açıkça ayrılmalıdır.
Yönetilen DevOps hizmetinde lock-in olur mu?
Sağlayıcı bağımlılığı kuruluma göre değişir. Dynamis'te altyapı müşterinin hesaplarında ve depolarında tutulabilir; erişim, dokümantasyon ve devir planı baştan yazılırsa hizmet değişikliği daha kontrollü yapılır.
Hangi durumda kendi DevOps ekibini kurmak daha doğru?
Platform yetkinliği ürününüzün parçasıysa, altyapı kararları her gün uygulama mimarisiyle birlikte değişiyorsa ve 7/24 operasyonu içeride sürdürebilecek nöbet ve yedekleme düzeniniz varsa kendi ekip daha uygundur.
DevOps mühendisi maliyeti nasıl hesaplanır?
Maaş ve işveren maliyetine işe alım, işe alışma, araçlar, eğitim, nöbet ve yedek personel maliyetini ekleyin. 7/24 kapsama haftada 168 saattir; gereken kişi sayısı çalışma ve nöbet politikanıza göre hesaplanmalıdır.
Yönetilen DevOps hizmeti neleri kapsar?
Kapsam sözleşmeye göre değişir. Tipik olarak Kubernetes işletimi, CI/CD, gözlemlenebilirlik, yedekleme, güvenlik yamaları, sürüm yükseltmeleri ve olay müdahalesi kapsanır; ürün kodunun sahipliği müşteride kalır.