Yönetilen DBA SLA Kontrol Listesi: Müdahale, Çözüm, Kapsam ve Eskalasyon

Yönetilen Database Administrator (DBA) hizmeti için SLA (Hizmet Düzeyi Sözleşmesi), tanımları kadar işe yarar. İmzalamadan önce sözleşmenin şunları ölçülebilir biçimde yazdığından emin olun: her önem seviyesinin ne anlama geldiği, müdahale ve çözüm saatlerinin ne zaman başlayıp durduğu, hangi saatlerin kapsandığı, kimin ne zaman eskale edildiği, RPO ve RTO’nun sahibinin kim olduğu, sağlayıcının hangi erişimi aldığı ve bunun nasıl denetlendiği, raporlarda ne alacağınız ve hizmetten nasıl çıkacağınız. Bunlardan biri “sonra belirlenecek” ise henüz bir SLA’nız yok demektir.

Bu yazı, tedarikçiden bağımsız bir alıcı kontrol listesidir. Sektör ortalamaları veya “tipik” müdahale süreleri vermez; çünkü bu rakamlar sizin sistemlerinize ve risk durumunuza bağlıdır. Bunun yerine neyin yazılması gerektiğini ve neyin sorulması gerektiğini listeler; rakamları işinize uygun şekilde siz doldurursunuz. Hâlâ sağlayıcı seçiyorsanız önce yönetilen SQL Server DBA hizmeti nasıl seçilir rehberimizle başlayın, sonra sözleşmeyi bu sayfayla gözden geçirin.

Müdahale Süresi, Çözüm Süresi ve Servisin Geri Getirilmesi: Üç Ayrı Taahhüt

SLA anlaşmazlıkları çoğu zaman bu sözcüklerin tanımsız bırakılmasıyla başlar. Her birini yazılı olarak netleştirin.

1. Önem Seviyesi Tanımları

Önem seviyeleri hangi sayacın geçerli olduğunu belirler; bu yüzden iş etkisi cinsinden yazılmalı ve bir olay sırasında tartışılmak yerine olaydan önce kararlaştırılmalıdır. Kendi ölçeğinizi kullanın; tablo, talep etmeniz gereken yapıyı gösterir, rakamlar size bırakılmıştır.

Önem seviyesi hakkında şunları sorun:

• Önem seviyesini kim belirler? Yalnızca sağlayıcı belirliyorsa buna itiraz edebileceğiniz bir yol gerekir. Uygulanabilir bir düzenleme, müşterinin seviyeyi belirlemesi, sağlayıcının ise gerekçesiyle değişiklik önerebilmesidir.
• Bir olay sırasında seviye değişebilir mi? Ne zaman yükseltildiğini veya düşürüldüğünü ve sayacın yeniden başlayıp başlamadığını tanımlayın.
• Üretim ve üretim dışı ortamlar farklı mı ele alınıyor? Genellikle öyle olmalı, ancak bunu açıkça yazın.
• Sağlayıcının kendi tespit ettiği uyarılar ne olacak? Proaktif tespitin, müşteri bildirimiyle aynı sayacı başlatıp başlatmadığına karar verin.

2. Sayaç Ne Zaman Başlar ve Durur?

Müdahale hedefleri aynı olan iki olay, sayaç kurallarına göre çok farklı davranabilir. Şunları belirtin:

• Başlangıç: talebin kaydedildiği, çağrının yanıtlandığı veya izleme uyarısının tetiklendiği an ve hangi kanallar üzerinden. Kritik sorunlar için telefon çağrısı şart mı, yoksa e-posta yeterli mi?
• Duraklatma: hangi durumların sayacı durdurduğu (örneğin sizin onayınızı veya erişiminizi beklemek) ve duraklatmayı kimin kaydettiği. Sınır olmazsa duraklatılmış sayaç gecikmeyi gizleyebilir.
• Durma: geri getirmeyi veya çözümü sizin mi sağlayıcının mı onayladığı ve hangi kanıtın gerektiği.
• Ölçüm: zaman damgaları için hangi sistemin esas alındığı ve bunu görüp göremediğiniz.

3. Kapsam Saatleri

“7/24” çok farklı anlamlara gelebilir. Ayrıntıları netleştirin:

• Saatler ve saat dilimi: kapsamın hangi saatleri ve hangi saat dilimini izlediği, iki ülkedeki resmi tatillerin nasıl ele alındığı.
• İzleme ve insan müdahalesi: 7/24 izleme, 7/24 DBA müdahalesi demek değildir. Uyarıları kimin izlediğini ve kimin harekete geçtiğini ayrı ayrı yazın.
• Önem seviyesine göre: kritik sorunlar 24 saat müdahale gerektirirken düşük seviyeli talepler yalnızca mesai saatlerinde ele alınabilir. Kapsamı önem seviyesi tablosuna yazın.
• Kanallar: telefon, talep portalı, sohbet veya e-posta; hangisinin hangi seviye için geçerli olduğu.
• İsimli kişiler veya havuz: isimli bir birincil mühendis ve yedeği olup olmadığı, bu kişi ulaşılamazken ne olacağı.
• Dil ve yetkinlik: destek dilleri ve kapsanan platformlar; örneğin belirli SQL Server sürümleri ve bulut hizmetleri.
• Sözleşme dışı işler: uygulama ayarlama, migrasyon veya aylık hizmetin dışında kalan projeler gibi işler ve bunların nasıl kapsamlandırıldığı.

4. Eskalasyon Yolu

Yazılmamış bir eskalasyon yolu, en kötü anda doğaçlama yapılır. Sözleşme şunları içermelidir:

• Seviyeler: ilk seviye mühendisten kıdemli DBA’ya, hizmet yöneticisine ve üst yönetim irtibatına kadar; iki tarafta da isimler veya roller ve telefon numaralarıyla.
• Tetikleyiciler: süreye bağlı tetikleyiciler (kararlaştırılan aralık sonunda güncelleme veya ilerleme olmaması) ve etkiye bağlı tetikleyiciler (önem seviyesinin yükselmesi, tekrarlayan hata). Her önem seviyesi için aralığı belirtin.
• Sizin tarafınız: ekibinizde kimin değişiklik onaylayabildiği, erişim verebildiği veya olayı kapatabildiği ve kendisi yokken yedeğinin kim olduğu.
• Büyük olay yönetimi: köprü veya çağrı açmanın tanımlı bir yolu, paydaşlarınıza kimin ne sıklıkla bilgi vereceği.
• Olay sonrası inceleme: kritik olaylar için, kararlaştırılan sürede teslim edilen, aksiyonları ve sahiplerini içeren yazılı kök neden analizi. SQL Server kesintisinin ilk 30 dakikası rehberimiz, müdahalenin kendisinin nasıl görünmesi gerektiğini gösterir.

5. RPO ve RTO: Kim Neye Sahip?

Recovery point objective (RPO) ne kadar veri kaybını göze alabileceğinizi, recovery time objective (RTO) ise ne kadar süre kapalı kalabileceğinizi ifade eder. Bir DBA hizmeti bunlara ulaşmanıza yardım edebilir, ancak mimarinin sağlayamayacağı rakamları taahhüt edemez. SLA her parçanın sahibini söylemelidir:

• Her veritabanı için RPO ve RTO’yu kim belirler? Sağlayıcının varsayılanı değil, her sistem için iş sahibi belirlemeli ve yazılı hale getirmelidir.
• Mekanizmaları kim tasarlar ve işletir? Yedekleme zamanlaması ve saklama süresi, log yedekleri, replikasyon veya availability group’lar ve failover prosedürleri.
• Testi kim yapar? Restore testlerinin sıklığı, kimin yaptığı ve sonucun size nasıl raporlandığı. Hiç geri yüklenmemiş bir yedek varsayımdır.
• Sağlayıcının kontrolü dışında olan nedir? Donanım, ağ, bulut platformu, depolama ve sizin uygulamanız. SLA, sağlayıcının yaptığı işi bağımlı olduğu şeylerden ayırmalıdır.
• Hedef kaçırılırsa sağlayıcı ne taahhüt eder? Yalnızca bir kredi değil, bir iyileştirme planı ve takvimi.

Teknik taraf için RPO, RTO, zamanlama ve test içeren SQL Server backup planı rehberimize bakın.

6. Erişim ve Güvenlik

Veritabanlarınıza erişimi olan bir DBA, verilerinize erişebilir. SLA’da veya ekindeki bir çizelgede şunlar yazmalıdır:

• En az yetki: kapsam için gereken asgari erişim, yükseltilmiş erişimi kimin ve ne kadar süreyle onayladığı.
• İsimli bireysel hesaplar: paylaşılan login yok; çok faktörlü kimlik doğrulama ve jump host veya VPN gibi kontrollü bir erişim yolu.
• Denetim kaydı: sağlayıcı faaliyetlerinin loglanması, logların ne kadar saklandığı ve sizin inceleyip inceleyemeyeceğiniz.
• Değişiklik kontrolü: değişikliklerin nasıl talep edildiği, onaylandığı, test edildiği ve geri alındığı, sağlayıcının onay almadan yapabileceği değişiklikler.
• Veri koruma: geçerli mevzuatın gerektirdiği yerde bir veri işleme sözleşmesi (örneğin KVKK veya GDPR), verilerin ve yedeklerin nerede saklandığı, hangi alt işleyicilerin kullanıldığı, bir ihlalin nasıl ve hangi sürede bildirileceği.
• Personel: sicil kontrolleri, gizlilik şartları ve sağlayıcının personeli değiştiğinde ne olacağı.
• Acil durum erişimi (break-glass): acil erişimin nasıl verildiği ve sonrasında nasıl gözden geçirildiği.

7. Proaktif İşlerin Kapsamı

Yalnızca olayları kapsayan bir SLA, olayları önleyen işleri dışarıda bırakır. Rutin işleri sıklığı ve tamamlandığının kanıtıyla birlikte listeleyin:

• Yedek izleme ve restore testleri
• Bütünlük kontrolleri (DBCC CHECKDB)
• Yama ve güncelleme planlaması; bakım pencerelerini kimin onayladığı dahil
• Performans incelemesi, index ve istatistik bakımı
• Kapasite ve büyüme incelemesi
• Güvenlik incelemesi ve yetki denetimleri

8. Raporlama ve Gözden Geçirme

Göremediğinizi yönetemezsiniz. Şunları belirtin:

• Rapor içeriği: önem seviyesine göre talepler, hedeflere karşı müdahale ve geri getirme süreleri, ihlaller ve nedenleri, yedek ve bütünlük kontrolü durumu, kapasite trendleri ve açık riskler.
• Sıklık ve biçim: örneğin aylık bir rapor ve bir hizmet gözden geçirme toplantısı, ayrıca her kritik olaydan sonra bir olay raporu.
• Veri erişimi: ham talep verilerini ve izleme geçmişini kendiniz okuyup okuyamayacağınız.
• Gözden geçirme sıklığı: hedeflerin, kapsamın ve risk listesinin ne sıklıkla yeniden ele alındığı ve SLA değişikliklerinin nasıl kararlaştırıldığı.

9. Yaptırımlar ve İstisnalar

• Yaptırımlar: bir hedef kaçırıldığında ne olacağı; hizmet kredisi, düzeltici eylem planı ve tekrarlayan veya ciddi ihlallerden sonra fesih hakkı gibi. Tek sonucun kredi olmadığını kontrol edin.
• İstisnalar: planlı bakım, sizin değişikliklerinizin yol açtığı sorunlar, üçüncü taraf veya bulut sağlayıcı kesintileri ve kapsam dışı uygulamalardaki sorunlar. İstisnalar açık uçlu değil, listelenmiş olmalıdır.
• Sorumluluk: veri kaybı veya güvenlik ihlalleri için sınırlar ve istisnalar; hukuk danışmanınızla gözden geçirin.

10. Çıkış ve Devir

Çıkışı tanımlamak için en iyi zaman imzadan öncesidir. Sözleşme şunları kapsamalıdır:

• Bildirim ve geçiş süresi: ne kadar sürdüğü ve bu sürede hizmet düzeylerinin geçerli olup olmadığı.
• Devir çıktıları: dokümantasyon, runbook’lar, script’ler, izleme yapılandırması, job ve zamanlama envanterleri ve güncel risk listesi; kullanabileceğiniz biçimlerde.
• Kimlik bilgileri ve erişim: sağlayıcı hesaplarının kaldırılması, paylaşılan sırların yenilenmesi ve yazılı teyit.
• Veri: sağlayıcının elindeki verilerinizin, yedeklerin ve logların iade edilmesi veya silinmesi; teyit ve takvimle.
• Bilgi aktarımı: devralan ekiple veya kendi personelinizle oturumlar ve maliyetini kimin üstleneceği.
• Kilitlenme olmaması: sağlayıcının kurduğu araçlar veya script’ler belgelenmeli ve devredilebilir ya da kaldırılabilir olmalıdır.

DBA SLA’sında Kırmızı Bayraklar

• Müdahale hedefleri var, ancak servisin geri getirilmesi veya çözüm taahhüdü yok.
• Önem seviyesini yalnızca sağlayıcı belirliyor veya iş etkisi olmadan yalnızca teknik terimlerle tanımlanmış.
• Kimin, hangi kanaldan müdahale ettiği belirtilmeyen “7/24”.
• Sahibi, testi veya kanıtı olmayan, hedef olarak tarif edilmiş RPO ve RTO.
• Paylaşılan hesaplar, denetim kaydı yokluğu veya veri koruma şartlarının olmaması.
• Yalnızca talep sayılarından oluşan aylık raporlar.
• Çıkış maddesi yok veya çıkış sağlayıcının iyi niyetine bağlı.

Kopyalayıp Kullanın: Kontrol Listesi

• İş etkisine göre tanımlanmış önem seviyeleri; sınıflandırmanın sahibi ve itiraz yolu
• Her önem seviyesi için yazılı müdahale, geri getirme ve çözüm hedefleri
• Sayacın başlama, duraklatma ve durma kuralları; zaman damgası kaynağının adı
• Kapsam saatleri, saat dilimi, tatiller, kanallar ve mesai dışında kimin müdahale ettiği
• İki tarafta da isimleri, tetikleyicileri ve aralıkları olan eskalasyon seviyeleri
• Büyük olay iletişimi ve olay sonrası rapor süresi
• Her veritabanı için RPO ve RTO; sahibi, tasarım sorumluluğu ve restore test takvimi
• En az yetki, isimli hesaplar, MFA, denetim logları ve değişiklik kontrolü
• Veri koruma şartları, alt işleyiciler ve ihlal bildirimi
• Sıklığı ve kanıtı belirtilmiş planlı proaktif işler
• Raporlar, gözden geçirme toplantıları ve temel verilere erişim
• Yaptırımlar, istisnalar ve fesih hakları
• Çıkış: bildirim, devir çıktıları, kimlik bilgilerinin kaldırılması ve veri iadesi

SSS

Aryasoft Yönetilen DBA SLA’larına Nasıl Yaklaşır?

Aryasoft olarak SLA’yı standart bir paket etrafında değil, sizin sistemleriniz etrafında yazmanızı öneririz: veritabanlarınızı iş etkisine göre sınıflandırın, her veritabanı için sahibiyle birlikte RPO ve RTO belirleyin, kapsamı ve eskalasyonu iki tarafta da isimlerle kararlaştırın ve raporları her ay birlikte gözden geçirin.

Kendi yönetilen DBA hizmetimiz de bu mantıkla kurgulandı: yalnızca kıdemli uzmanlar, aylık rapor ve zaman damgalı bulgular üreten HELT360 sağlık taramaları. Böylece iki taraf da yalnızca ticket sayısını değil, ortamın gerçek durumunu görür. Yönetilen veritabanı hizmetleri sayfamız hizmetimizin nasıl organize edildiğini anlatır; yönetilen SQL Server DBA hizmeti nasıl seçilir rehberimiz de imzadan önce sorulacak soruları kapsar.

Kaynaklar ve Yöntem

Bu kontrol listesi, yönetilen veritabanı hizmeti sözleşmesini gözden geçirmek için hazırlanmış pratik bir çerçevedir. Hiçbir sektör istatistiğine veya kıyaslamasına dayanmaz, bunlardan alıntı yapmaz ve önerilen müdahale veya çözüm süreleri vermez; doğru değerler sizin sistemlerinize ve risk durumunuza bağlıdır. Hukuki tavsiye değildir; nihai sözleşmeyi hukuk danışmanınıza inceletin.