DevOps bakım hizmetinde en sık yaşanan sorun teknik araç eksikliği değil, bir olay anında “kim neyi yapacak?” sorusunun cevapsız kalmasıdır. Altyapı sağlayıcısı sunucuyu izlerken uygulama ekibi deploy’dan sorumlu olabilir; yedek alınsa bile geri yükleme onayını iş birimi vermek zorunda kalabilir. Yazılı bir sorumluluk matrisi; bakım kapsamını, SLA’yı, eskalasyonu ve rollback kararını aynı operasyon modelinde birleştirir.

SLA tek başına bakım kapsamını açıklamaz

SLA çoğu zaman yanıt süresi ve hizmet erişilebilirliğiyle sınırlı okunur. Oysa production sisteminin sağlıklı işletilmesi; işletim sistemi, ağ, firewall, container platformu, veritabanı, uygulama, CI/CD, DNS, SSL, yedekleme ve üçüncü taraf servislerden oluşur. “Sunucu yönetimi dâhil” ifadesi bu katmanların hangisini kimin yönettiğini söylemez.

Bu nedenle SLA’nın yanında hizmet kataloğu ve RACI benzeri bir sorumluluk matrisi bulunmalıdır. Her operasyon için işi yapan, nihai kararı veren, görüşü alınan ve bilgilendirilen taraf yazılmalıdır. Küçük ekiplerde aynı kişi birkaç rolü üstlenebilir; önemli olan rolün olay anında belirsiz kalmamasıdır.

Katmanlara göre sorumlulukları ayırın

İlk adım altyapıyı teknik katmanlara bölmektir. Her katman için rutin bakım, olay müdahalesi, değişiklik onayı ve geri dönüş sorumlusu ayrı yazılabilir:

• Altyapı: sanal sunucu, disk, ağ, temel erişim ve kaynak kapasitesi.
• İşletim sistemi: güvenlik yamaları, kullanıcılar, SSH/RDP, servis yönetimi ve loglar.
• Platform: Docker/Kubernetes, ingress, registry, secret dağıtımı ve cluster bileşenleri.
• Veri katmanı: veritabanı, replikasyon, yedek, PITR, restore testi ve kapasite.
• Uygulama: kod, bağımlılıklar, migration, feature flag ve uygulama davranışı.
• Dağıtım hattı: build, test, artifact, onay kapısı ve deploy kimlik bilgileri.
• Gözlemleme: metrik, log, trace, alarm eşiği, nöbet ve bildirim kanalı.
• İş sürekliliği: RPO/RTO kararı, felaket senaryosu ve geri dönüş kabulü.

Bir katmanın yönetiliyor olması diğerinin otomatik olarak kapsama girdiği anlamına gelmez. Örneğin veritabanı servisi ayakta olabilir fakat hatalı bir uygulama migration’ının geri alınması uygulama ekibinin onayını gerektirebilir.

SLA, SLO ve operasyon penceresini ayırın

SLA sözleşmesel hizmet hedefini, SLO ekiplerin işlettiği ölçülebilir hedefi, bakım penceresi ise planlı değişikliğin yapılabileceği zamanı tanımlar. Bu kavramları tek cümlede birleştirmek yanlış beklenti yaratır. Örneğin ilk yanıtın 15 dakika olması sorunun 15 dakikada çözüleceği anlamına gelmez.

Her öncelik seviyesi için olay örneği, bildirim kanalı, ilk yanıt hedefi, durum güncelleme sıklığı ve eskalasyon noktası yazılmalıdır. Kritik seviye; tam erişim kaybı, veri bütünlüğü riski veya aktif güvenlik olayı gibi somut koşullarla tanımlanmalıdır. Tek kullanıcının kozmetik hatasıyla tüm müşteriyi etkileyen kesinti aynı öncelikte ele alınmamalıdır.

Bakım modelinde dört değişiklik sınıfı

Değişiklikleri risk ve onay ihtiyacına göre sınıflandırmak süreci hızlandırır:

• Standart değişiklik: Daha önce uygulanmış, düşük riskli, dokümante edilmiş ve önceden onaylı işlem.
• Normal değişiklik: Etki analizi, test, bakım penceresi ve açık onay gerektiren işlem.
• Acil değişiklik: Devam eden kesinti veya güvenlik riski nedeniyle hızlandırılmış onayla yapılan müdahale.
• Uygulama değişikliği: Kod, şema veya ürün davranışını değiştiren ve ürün sahibinin kabulünü gerektiren işlem.

Her sınıf için gerekli kanıtlar önceden belirlenmelidir. Standart değişiklikte otomatik test yeterli olabilirken veritabanı şema değişikliğinde geri dönüş süresi, uyumluluk ve veri dönüşümü ayrıca incelenmelidir.

Rollback kararı kime ait?

Rollback planının bulunması, kararın otomatik olduğu anlamına gelmez. Teknik ekip hata oranındaki artışı görebilir; ancak geri dönüş veri kaybı veya iş süreci etkisi yaratıyorsa ürün sahibi ya da veri sorumlusu karar vermelidir. Bu nedenle değişiklik kaydında rollback yetkilisi ve karar eşiği açıkça yazılmalıdır.

Ölçülebilir eşikler; sağlık kontrolü başarısızlığı, hata oranı, p95 gecikme, kuyruk birikimi veya kritik iş akışının çalışmaması olabilir. “Sorun olursa geri döneriz” ifadesi yeterli değildir. Geri dönüşün kaç dakika süreceği, hangi verinin etkileneceği ve ileri yönlü düzeltmenin daha güvenli olup olmadığı değişiklikten önce değerlendirilmelidir.

Yedek sorumluluğunu dört parçaya bölün

“Yedek alınıyor” maddesi operasyonel olarak eksiktir. En az dört ayrı sorumluluk bulunur: yedek politikasını belirlemek, işi çalıştırmak, başarısını izlemek ve geri yüklemeyi doğrulamak. RPO ile RTO kararını iş sahibi vermeli; teknik ekip bu hedeflerin uygulanabilirliğini ve maliyetini açıklamalıdır.

Replikasyon veya yüksek erişilebilirlik yedek değildir. Bozuk veri, yanlış silme ya da hatalı migration replikalara taşınabilir. Sorumluluk matrisi; snapshot, dosya yedeği, veritabanı backup/PITR, saklama, erişim anahtarı ve restore tatbikatını ayrı satırlar hâlinde göstermelidir.

Eskalasyon zinciri nasıl kurulmalı?

Eskalasyon yalnız “bir üst yöneticiyi aramak” değildir. Teknik eskalasyon daha uzman bir ekibi, operasyonel eskalasyon kaynak/öncelik kararını, ticari eskalasyon ise sözleşme veya müşteri etkisini yönetir. Kritik bir olayda bu üç yol paralel ilerleyebilir.

Nöbetçi kişilerin adı yerine rol ve güncel iletişim kanalı tutulmalıdır; kişi değiştiğinde plan geçersiz kalmamalıdır. Erişim için tek kişinin hesabına bağımlı olunmamalı, acil erişim yöntemi ve kayıt altına alma kuralı belirlenmelidir. Olay boyunca tek bir zaman çizelgesi ve karar kaydı tutulması, sonradan kök neden analizini kolaylaştırır.

Aylık bakım toplantısında sorulacak sorular

• Envanter ve sorumluluk sahibi değişti mi?
• Yaklaşan işletim sistemi, panel, runtime veya veritabanı güncellemeleri neler?
• Son ayın alarm gürültüsü ve gerçek olayları ne gösteriyor?
• Yedekler çalıştı mı; geri yükleme örneği doğrulandı mı?
• Kapasite trendi ve maliyet riski hangi katmanda artıyor?
• Açık güvenlik bulgularının sahibi ve hedef tarihi belli mi?
• Rollback planı olmayan planlı değişiklik var mı?
• SLA raporundaki ölçüm kaynağı ve istisnalar açıklanabiliyor mu?

Sorumluluk matrisini nasıl canlı tutarsınız?

Matris bir kez hazırlanıp arşive kaldırılmamalıdır. Yeni servis, ekip değişikliği, sağlayıcı geçişi veya mimari güncelleme olduğunda ilgili satırlar revize edilmelidir. Üç ayda bir masa başı olay senaryosu çalıştırmak, kâğıt üzerindeki rollerin gerçekten uygulanabildiğini gösterir. Senaryoda alarmı kimin gördüğü, production erişiminin kimde olduğu, iş sahibinden kararın nasıl alındığı ve durum güncellemesinin hangi kanaldan paylaşıldığı zaman ölçülerek denenmelidir.

Belge sürümü, son gözden geçirme tarihi ve her rolün yedeği görünür olmalıdır. Ayrılan personelin hesabına, süresi dolmuş iletişim bilgisine veya tek bir uzman bilgisine bağlı süreçler operasyon riskidir. Tatbikatta bulunan eksikler için sahip ve hedef tarih atamak, sorumluluk matrisini denetlenebilir bir iyileştirme aracına dönüştürür.

Bakım kapsamı teklif öncesinde netleşmeli

Sağlıklı bir DevOps hizmeti, sınırsız ve belirsiz destek vaadi değil; ölçülebilir kapsam, doğru iletişim ve kanıtlanmış operasyon üretir. Mevcut altyapınızın bakım, izleme, yedekleme, deployment ve olay müdahalesi sorumluluklarını çıkarmak için Narweb DevOps Hizmeti sayfasını inceleyebilirsiniz. Kapsam ve teknik öncelikleri birlikte değerlendirmek için iletişime geçin.