Bulut hizmetinde en sık yaşanan yanlış anlama sınırın nerede olduğuyla ilgili. Bir kesinti yaşandığında ilk soru neredeyse her zaman aynı: buna kim bakacak. Bu sayfa o soruyu kesinti anında değil, sözleşme aşamasında cevaplamak için var. Aşağıdakiler sözleşme metni değildir; kapsamınız ve seçtiğiniz model imzaladığınız hizmet sözleşmesinde tanımlanır, çelişki halinde sözleşme hükümleri geçerlidir.
İki hizmet modeli
İki model üzerinden çalışıyoruz ve hangisini istediğinizi sözleşme aşamasında netleştiriyoruz. Aradaki fark altyapının nerede bittiği değil; her iki modelde de veri merkezi, ağ, donanım ve sanallaştırma katmanı bizde. Fark, işletim sistemi ve onun üzerindeki katmanlara kimin baktığı.
Yönetilen
İşletim sistemi kurulumu ve güncellemeleri, izleme, yedeklerin kontrolü ve arıza anında müdahale bizde. Kendi sistem yöneticisi olmayan ya da ekibini asıl işine ayırmak isteyen şirketler bu modeli seçiyor. Pratik karşılığı şu: bir diskin dolmaya yaklaştığı alarmı gece yarısı biz alıyoruz, siz durumu sabah raporda okuyorsunuz.
SLA politikamızın varsayılan kapsamı da bu modeldir. Sözleşmede aksi belirtilmedikçe hizmet seviyesi taahhütleri yönetilen hizmetler için geçerlidir.
Yönetilmeyen
Sunucuyu kurup size teslim ediyoruz. İşletim sistemi, uygulama ve güvenlik yamalarının sorumluluğu sizde kalıyor; altyapı, ağ ve donanım katmanı yine bizim sorumluluğumuzda. Kendi sistem yöneticisi olan, kendi yapılandırma standardı bulunan ekipler bunu tercih ediyor.
Bu modelde dikkat edilmesi gereken bir nokta var: işletim sistemi ya da uygulama katmanındaki bir sorun yüzünden hizmetiniz erişilemez hale geldiğinde geçen süre çalışma süresi hesabına girmez. Bu, SLA politikasının taahhüt dışı durumlar bölümünde yazılı. Yönetilmeyen modeli seçmek maliyeti düşürebilir ama kesinti riskinin bir kısmını da size aktarır.
Katman katman sorumluluk
Tablodaki Ortak satırlarında iş birlikte yürüyor: kararı siz veriyorsunuz, uygulamayı biz yapıyoruz ya da tam tersi. Örneğin geri yüklemede hangi ana dönüleceğine siz karar verirsiniz, işlemi biz yürütürüz.
| Katman | Yönetilen | Yönetilmeyen |
|---|---|---|
| Veri merkezi, enerji, soğutma, fiziksel güvenlik | DevUps | DevUps |
| Ağ omurgası ve donanım | DevUps | DevUps |
| Sanallaştırma katmanı ve yedekli küme | DevUps | DevUps |
| Yedekleme altyapısı ve değiştirilemez saklama | DevUps | DevUps |
| Geri yükleme talebinin açılması ve noktanın seçimi | Ortak | Müşteri |
| Altyapı katmanı güvenlik duvarı politikası | DevUps | DevUps |
| İşletim sistemi kurulumu ve güvenlik yamaları | DevUps | Müşteri |
| Çalışma zamanı ve orta katman yazılımları | Ortak | Müşteri |
| Altyapı izleme ve alarm | DevUps | DevUps |
| Uygulama içi izleme ve log | Ortak | Müşteri |
| Uygulama kodu ve bağımlılıkları | Müşteri | Müşteri |
| Uygulama verisi ve içeriği | Müşteri | Müşteri |
| Kullanıcı hesapları ve yetkilendirme | Müşteri | Müşteri |
| Veri sınıflandırması ve KVKK yükümlülükleri | Müşteri | Müşteri |
Tablo her durumu kapsamaz. Bir sorunun hangi katmandan kaynaklandığı ilk anda belli olmayabilir; uygulama yavaşlığının diskten mi sorgudan mı geldiği çoğu zaman bakmadan anlaşılmaz. Böyle durumlarda kaynağı birlikte arıyoruz ve fatura tartışmasını sonraya bırakıyoruz. Sınırın kimde olduğu, sorunun çözülmesini geciktiren bir gerekçe değil.
Veri her iki modelde de sizde
Tablonun en çok gözden kaçan satırı bu: veri, her iki modelde de müşteride. KVKK terminolojisiyle söylersek verinin sorumlusu sizsiniz, biz veri işleyen konumundayız. Bu ayrımın ayrıntısı KVKK aydınlatma metnimizde yazılı.
Pratik karşılığı şu: hangi verinin toplandığına, ne kadar saklanacağına ve kimin erişeceğine siz karar veriyorsunuz. Biz o verinin durduğu altyapının çalışır, yedekli ve yedeklenmiş olmasından sorumluyuz. Yedekler ayrı bir depolama sisteminde, belirlenen saklama süresi boyunca değiştirilemez biçimde tutulur; sisteminize fidye yazılımı bulaşsa dahi yedekler silinemez veya şifrelenemez.
Ancak yedeğin var olmasıyla geri dönülebilir olması aynı şey değil. Hangi sistemin hangi sıklıkla yedekleneceği ve kabul edilebilir veri kaybının ne olduğu sözleşmede tanımlanır. Bu değerleri birlikte kararlaştırıyoruz, çünkü hangi verinin kaç dakikalık kaybının kabul edilebilir olduğunu sizin işiniz belirler.
Sınırın pratikte anlamı
Sınır asıl bir arıza anında önem kazanıyor. Bir düğüm arızalandığında sunucularınız kümedeki diğer düğümlerde çalışmaya devam eder ve bu bizim tarafımızda kalan bir iştir; senaryoyu planlı tatbikatlarla, sistem gerçek yük altındayken test ediyoruz. Buna karşılık uygulamanız bir dağıtım sonrası hata verdiğinde işin başladığı yer sizin tarafınız. Bu ayrımın nasıl kurulduğunu sanal sunucu hizmetimizde daha ayrıntılı anlattık.
Kubernetes tarafında sınır biraz daha ince çiziliyor. Control plane bizde olduğunda cluster'ın kendi sağlığı, etcd yedeği ve sürüm yükseltmeleri bizim işimiz; namespace içindeki deployment'lar, kaynak limitleri ve uygulama yapılandırması sizde kalıyor. Kapsamın nasıl belirlendiğini Kubernetes cluster yönetimi sayfasında bulabilirsiniz; etcd yedeğinin neden ayrıca ele alınması gerektiğini de etcd yedekleme ve kurtarma yazısında ölçümlerle anlattık.
Yanıt süreleri, olay önceliklendirme ve destek kanalları için destek ve hizmet seviyeleri sayfasına, taahhüt metninin tamamı için SLA politikamıza bakabilirsiniz.