SLA'nın sizi kurtaracağını düşünmeyi bırakın. Sakinleşmek ve sahte bir güvenlik duygusu yaratmak için gereklidir.

SLA'nın sizi kurtaracağını düşünmeyi bırakın. Sakinleşmek ve sahte bir güvenlik duygusu yaratmak için gereklidir.

“Hizmet düzeyi sözleşmesi” olarak da bilinen SLA, müşteri ile hizmet sağlayıcı arasında, müşterinin hizmet açısından ne alacağına ilişkin bir garanti sözleşmesidir. Aynı zamanda tedarikçinin hatasından dolayı kesinti yaşanması durumunda tazminat ödenmesini de öngörmektedir. Temelde SLA, bir veri merkezinin veya barındırma sağlayıcısının, potansiyel bir müşteriyi kendisine mümkün olan her şekilde nazik davranılacağına ikna etmesini sağlayan bir kimlik bilgisidir. Sorun şu ki, SLA'ya istediğiniz her şeyi yazabilirsiniz ve bu belgede yazılan olaylar çok sık gerçekleşmez. SLA, bir veri merkezi seçiminde bir kılavuz olmaktan uzaktır ve kesinlikle ona güvenmemelisiniz.

Hepimiz belirli yükümlülükler getiren bir tür anlaşmalar imzalamaya alışkınız. SLA bir istisna değildir; genellikle hayal edilebilecek en gerçekçi olmayan belgedir. Muhtemelen daha işe yaramaz olan tek şey, "ticari sır" kavramının gerçekten mevcut olmadığı yargı bölgelerinde NDA'dır. Ancak tüm sorun, SLA'nın müşterinin doğru tedarikçiyi seçmesine yardımcı olmaması, yalnızca gözlere toz atmasıdır.

Barındırıcılar, halka gösterdikleri SLA'nın herkese açık sürümünde çoğunlukla ne yazar? İlk satır, barındırıcının "güvenilirliği" terimidir - bunlar genellikle% 98 ila 99,999 arasındaki sayılardır. Aslında bu rakamlar pazarlamacıların güzel bir icadıdır. Bir zamanlar, barındırmanın genç ve pahalı olduğu ve bulutların uzmanlar için sadece bir rüya olduğu (aynı zamanda herkes için geniş bant erişiminin olduğu) barındırma çalışma süresi göstergesi son derece çok önemliydi. Artık tüm tedarikçiler artı veya eksi aynı ekipmanı kullandığında, aynı omurga ağlarında oturduğunda ve aynı hizmet paketlerini sunduğunda, çalışma süresi göstergesi kesinlikle önemsizdir.

"Doğru" bir SLA var mı?

Elbette SLA'nın ideal versiyonları var, ancak hepsi standart olmayan belgelerdir ve müşteri ile tedarikçi arasında manuel olarak kaydedilip sonuçlandırılır. Üstelik bu tür SLA, çoğunlukla hizmetlerden ziyade bir tür sözleşmeli iş ile ilgilidir.

İyi bir SLA neleri içermelidir? TLDR'yi açıklamak gerekirse, iyi bir SLA, iki kuruluş arasındaki ilişkiyi düzenleyen ve taraflardan birine (müşteriye) süreç üzerinde maksimum kontrol sağlayan bir belgedir. Yani gerçek dünyada işler nasıl yürüyor: Küresel etkileşim süreçlerini anlatan, taraflar arasındaki ilişkileri düzenleyen bir belge var. Sınırları, kuralları belirler ve her iki tarafın da sonuna kadar kullanabileceği bir nüfuz aracı haline gelir. Böylece, doğru SLA sayesinde müşteri, yükleniciyi kararlaştırıldığı gibi çalışmaya zorlayabilir ve bu, yüklenicinin aşırı aktif bir müşterinin sözleşmeyle haklı gösterilmeyen "istekleriyle" mücadele etmesine yardımcı olur. Şöyle görünüyor: "SLA'mız şunu söylüyor, buradan çıkın, her şeyi anlaştığımız gibi yapıyoruz."

Yani "doğru SLA" = "hizmetlerin sağlanması için yeterli bir sözleşme" ve durum üzerinde kontrol sağlar. Ancak bu ancak “eşit olarak” çalışıldığında mümkündür.

Sitede yazılanlarla gerçekte sizi bekleyenler farklı şeylerdir

Genel olarak, daha fazla tartışacağımız her şey tipik pazarlama hileleri ve bir dikkat testidir.

Popüler yerli barındırma sağlayıcılarını ele alırsak, bir teklif diğerinden daha iyidir: 25/8 destek, %99,9999999 sunucu çalışma süresi, en azından Rusya'da bir grup kendi veri merkezi. Lütfen veri merkezleriyle ilgili noktayı unutmayın, buna biraz sonra geri döneceğiz. Bu arada, ideal hata toleransı istatistiklerinden ve sunucusu hala "%0,0000001 hata" kapsamına girdiğinde bir kişinin neyle karşı karşıya kaldığından bahsedelim.

%98 ve üzeri göstergelerle herhangi bir düşüş istatistiksel hatanın eşiğinde bir olaydır. Çalışma ekipmanı ve bağlantısı ya vardır ya da yoktur. %50 “güvenilirlik” derecesine sahip bir hosting sağlayıcıyı (kendi SLA’sına göre) tek bir sorun yaşamadan yıllarca kullanabilir veya %99,99 iddiasında olan adamlarla ayda bir birkaç gün “başarısız olabilirsiniz”.

Düşme anı geldiğinde (ve bir gün herkesin düşeceğini hatırlatırız), müşteri "destek" adı verilen dahili bir kurumsal makineyle karşı karşıya kalır ve hizmet sözleşmesi ve SLA gün ışığına çıkar. Bu ne anlama geliyor:

  • Büyük olasılıkla, ilk dört saatlik kesinti boyunca hiçbir şey sunamayacaksınız, ancak bazı ev sahipleri kaza anından itibaren tarifeyi (tazminat ödemesi) yeniden hesaplamaya başlıyor.
  • Sunucunun uzun bir süre kullanılamaması durumunda tarifenin yeniden hesaplanması için talepte bulunabilirsiniz.
  • Bu da sorunun tedarikçinin kusurundan kaynaklanması şartıyla.
  • Sorununuz üçüncü bir şahıstan (otoyolda) kaynaklandıysa, o zaman "kimse suçlanamaz" gibi görünür ve sorunun çözülmesi sizin şansınıza bağlıdır.

Ancak, mühendislik ekibine asla erişemeyeceğinizi anlamak önemlidir; çoğu zaman, gerçek mühendisler durumu düzeltmeye çalışırken sizinle iletişim kuran ilk destek hattı tarafından durdurulursunuz. Tanıdık geliyor?

Burada pek çok kişi sizi bu tür durumlardan koruyacak gibi görünen SLA'ya güveniyor. Ancak aslında şirketler nadiren kendi belgelerinin sınırlarını aşar veya kendi maliyetlerini en aza indirecek şekilde durumu tersine çevirebilirler. Bir SLA'nın birincil görevi, dikkati dağıtmak ve öngörülemeyen bir durum durumunda bile "her şeyin yoluna gireceğine" ikna etmektir. SLA'nın ikinci amacı, ana kritik noktaları iletmek ve hizmet sağlayıcıya manevra alanı, yani bir arızayı tedarikçinin "sorumlu olmadığı" bir şeye atfetme yeteneği vermektir.

Aynı zamanda, büyük müşteriler aslında SLA kapsamındaki ücretlendirmeyi hiç umursamıyorlar. “SLA tazminatı”, ekipmanın aksama süresiyle orantılı olarak tarife dahilinde para iadesidir ve bu, potansiyel parasal ve itibar kayıplarının %1'ini dahi asla karşılamaz. Bu durumda müşteri için sorunların bir an önce çözülmesi bir tür “tarife yeniden hesaplamasından” çok daha önemlidir.

“Dünyadaki birçok veri merkezi” endişe kaynağı

Bir hizmet sağlayıcıda çok sayıda veri merkezinin bulunması durumunu ayrı bir kategoriye koyduk, çünkü yukarıda açıklanan bariz iletişim sorunlarının yanı sıra, bariz olmayan problemler de ortaya çıkıyor. Örneğin, servis sağlayıcınızın "kendi" veri merkezlerine erişimi yoktur.

Son yazımızda Affiliate program türleri hakkında yazdık ve “Beyaz Etiket” modelinden bahsettik.Bunun özü, diğer insanların kapasitelerinin kendi kisvesi altında yeniden satılmasıdır. Birçok bölgede "kendi veri merkezlerine" sahip olduğunu iddia eden modern barındırma sahiplerinin büyük çoğunluğu Beyaz Etiket modelini kullanan satıcılardır. Yani İsviçre, Almanya veya Hollanda'daki koşullu veri merkeziyle fiziksel olarak hiçbir ilgileri yoktur.

Burada son derece ilginç çarpışmalar ortaya çıkıyor. Hizmet sağlayıcıyla olan SLA'nız hala çalışıyor ve geçerlidir, ancak tedarikçinin bir kaza durumunda durumu bir şekilde radikal bir şekilde etkilemesi mümkün değildir. Kendisi, güç raflarının yeniden satış için satın alındığı veri merkezi olan kendi tedarikçisine bağımlı bir konumdadır.

Bu nedenle, yalnızca sözleşmede ve SLA'da güvenilirlik ve hizmetle ilgili güzel ifadelere değil, aynı zamanda hizmet sağlayıcının sorunları hızlı bir şekilde çözme becerisine de değer veriyorsanız, doğrudan tesis sahibiyle çalışmalısınız. Aslında bu, doğrudan veri merkeziyle doğrudan etkileşimi içerir.

Birçok DC aslında bir şirkete ait olabilirken neden seçenekleri değerlendirmiyoruz? Aslında bu türden çok az şirket var. Bir, iki, üç küçük veri merkezi veya bir büyük veri merkezi mümkündür. Ancak yarısı Rusya Federasyonu'nda ve ikincisi Avrupa'da olmak üzere bir düzine DC neredeyse imkansız. Bu, tahmin edebileceğinizden çok daha fazla bayi firmanın olduğu anlamına gelir. İşte basit bir örnek:

SLA'nın sizi kurtaracağını düşünmeyi bırakın. Sakinleşmek ve sahte bir güvenlik duygusu yaratmak için gereklidir.
Google Cloud hizmeti veri merkezlerinin sayısını tahmin edin. Avrupa'da bunlardan sadece altı tane var. Londra, Amsterdam, Brüksel, Helsinki, Frankfurt ve Zürih'te. Yani tüm ana otoyol noktalarında. Çünkü veri merkezi pahalıdır, karmaşıktır ve çok büyük bir projedir. Şimdi Moskova'nın herhangi bir yerindeki "Rusya ve Avrupa çapında bir düzine veri merkezine" sahip barındırma şirketlerini hatırlayın.

Beyaz Etiket programında ortakları olan iyi tedarikçiler elbette yok, yeterli sayıda var ve en üst düzeyde hizmet veriyorlar. Aynı tarayıcı penceresi aracılığıyla AB ve Rusya Federasyonu'nda aynı anda kapasite kiralamayı, ödemeyi döviz cinsinden değil ruble cinsinden kabul etmeyi vb. mümkün kılıyorlar. Ancak SLA'da açıklanan durumlar meydana geldiğinde, onlar da sizin gibi durumun rehineleri haline gelirler.

Bu bize, tedarikçinin organizasyon yapısını ve yeteneklerini anlamadığınız takdirde SLA'nın faydasız olduğunu bir kez daha hatırlatır.

Sonucu ile bu

Sunucu çökmesi her zaman hoş olmayan bir olaydır ve herkesin, her yerde başına gelebilir. Sorun, durum üzerinde ne kadar kontrol sahibi olmak istediğinizdir. Artık piyasada çok fazla doğrudan kapasite tedarikçisi yok ve büyük oyunculardan bahsedersek, o zaman nispeten konuşursak, Avrupa çapında bir düzineden Moskova'da erişebileceğiniz yalnızca bir DC'ye sahipler.

Burada her müşteri kendisi için karar vermelidir: Şu anda rahatlığı mı seçeceğim yoksa Rusya veya Avrupa'da kabul edilebilir bir konumda, ekipmanımı yerleştirebileceğim veya kapasite satın alabileceğim bir veri merkezi aramak için zaman ve çaba mı harcayacağım. İlk durumda, şu anda piyasada bulunan standart çözümler uygundur. İkincisinde terlemeniz gerekecek.

Öncelikle hizmet satıcısının tesisin/veri merkezinin doğrudan sahibi olup olmadığının tespit edilmesi gerekmektedir. Beyaz Etiket modelini kullanan birçok satıcı, durumlarını gizlemek için ellerinden geleni yapar ve bu durumda bazı dolaylı işaretlere bakmanız gerekir. Örneğin, “Avrupa DC'lerinin” tedarikçi şirketin adından farklı bazı özel adları ve logoları varsa. Veya bir yerlerde “ortak” kelimesi geçiyorsa. Ortaklar = Vakaların %95'inde Beyaz Etiket.

Daha sonra, şirketin yapısına aşina olmanız veya daha iyisi ekipmana şahsen bakmanız gerekir. Veri merkezleri arasında gezi uygulaması veya en azından kendi web sitesinde veya blogunda gezi makaleleri yeni değil (böyle yazdık) zaman и iki), fotoğraflar ve ayrıntılı açıklamalarla veri merkezleri hakkında konuştukları yer.

Birçok veri merkeziyle ofise kişisel bir ziyaret ve DC'ye mini bir gezi düzenleyebilirsiniz. Orada düzenin derecesini değerlendirebilirsiniz, belki mühendislerden biriyle iletişim kurabilirsiniz. Aylık 300 RUB karşılığında bir sunucuya ihtiyacınız varsa kimsenin size üretim turu yapmayacağı açıktır, ancak ciddi bir kapasiteye ihtiyacınız varsa satış departmanı sizinle tanışabilir. Mesela bu tür geziler yapıyoruz.

Her durumda sağduyu ve iş ihtiyaçları kullanılmalıdır. Örneğin, dağıtılmış bir altyapıya ihtiyacınız varsa (sunucuların bir kısmı Rusya Federasyonu'nda, bir kısmı AB'de), Beyaz Etiket kullanan Avrupa DC'leri ile ortaklığı olan hosterların hizmetlerini kullanmak daha kolay ve daha karlı olacaktır. modeli. Tüm altyapınız tek bir noktada, yani tek bir veri merkezinde yoğunlaşacaksa tedarikçi bulmaya biraz zaman ayırmanızda fayda var.

Çünkü tipik bir SLA büyük olasılıkla size yardımcı olmayacaktır. Ancak bayi ile değil tesis sahibi ile çalışmak olası sorunların çözümünü önemli ölçüde hızlandıracaktır.

Kaynak: habr.com

Yorum ekle