Neyse ki, Site Güvenilirlik Mühendisliği Google'da dahili olarak geliştirildiğinden ve yalnızca son zamanlarda daha geniş bir topluluğa girmeye başladığı için oldukça iyi tanımlanmıştır. Ne olduğunu değil , ama, web işlemleri (- netlik eksikliği bir örneği olarak, sorunuzun içinde her ikisini de kullanmak ya da "sistem yönetim") 'dir. Bunlardan birinin ne olduğundan tamamen emin olmadığınız zaman iki şey arasındaki farkları tartışmak zor.
Ama maceracı bir adamım, bu yüzden denemek istiyorum.
Çok geleneksel mağazalarda, geliştiriciler ve sistem yöneticileri birbirlerinden çok sessizdir. Devs bir uygulama oluşturur, ardından kodları işlenir tamamlanmaz işlerinin tamamlandığını düşünün. Sistem yöneticileri yapı yapay nesnelerini alır (bu, yorumlanmış bir dilse sadece kod olabilir) ve bunu üretim sunucularına dağıtır. Uygulamanın sorunsuz çalışmasını sağlamak ve genel olarak üretim ortamını yönetmek sistem yöneticilerinin görevidir. Ancak, performans sorunları genellikle uygulamadaki mimari sorunlardan kaynaklanır; sistem yöneticileri uygulamanın ne yaptığını bilmek için programlama bilgisine sahip değildir ve geliştiriciler uygulamanın üretim trafiği ile üretim topolojisinde nasıl davrandığını bilmez, bu nedenle hiç kimse sorunu çözmek için kendileri tarafından donatılmamıştır.
Buna ek olarak, geliştiriciler genellikle yeni özellikleri ne kadar hızlı üretebileceklerine karar verirken, sistem yöneticileri uygulamanın üretimde ne kadar sık ara verdiğine karar verilir. Değişim, kırılmanın önde gelen nedenlerinden biri olduğu için, bu iki departmanı birbiriyle çelişiyor - işi ve insanlara zarar veren eski bir rekabet.
Bir noktada, geliştirici merkezli bazı şirketler bu kadar rahatsız oldular ve "NoOps" uygulamaya başladılar - operasyon departmanlarını ve onlarla birlikte gelen algılanan barikatları ortadan kaldırdılar. Gerçekte, bu, geliştiricilerin operasyon rollerini üstlendiği, ancak eski unvanlarını koruduğu anlamına geliyordu.
Gelen NoOps çevreleyen bir tartışma , John Allspaw ardından Etsy Teknik Operasyonlar Başkan Yardımcısı ve bir editör saygın Web Operasyon kitabında , Etsy de şu açıdan rolleri tanımlanmış:
Etsy Operations şunlardan sorumludur:
- Kesintilere yanıt vermek, çağrı alır
- İkaz sistemleri eşiği, tasarımı
- Mimari tasarım ve inceleme
- Metrik koleksiyonu oluşturma
- Uygulama yapılandırması
- Altyapı oluşturma / yönetimi
Etsy Development şunlardan sorumludur:
- Kesintilere yanıt vermek, çağrı alır
- İkaz sistemleri eşiği, tasarımı
- Mimari tasarım ve inceleme
- Metrik koleksiyonu oluşturma
- Uygulama yapılandırması
- Halka açık kod gönderme
Bu listelerin hiçbiri kapsamlı değil, eminim orada bir şey eksik. Etsy Ops üretime dönük uygulama değişiklikleri yapmış olsa da, bunlar çok az ama gerçektir (ve bazen oldukça derindir). Etsy Dev Şef'i değiştirirken, az ama gerçekler. Sorumluluklarda çok fazla çakışma varsa neden fark edebilirsiniz? Alan adı uzmanlığı ve arka planı. Pek çok Devs, TCP yavaş başlatmanın nasıl çalıştığı hakkında derin bilgiye sahip değildir, ancak Ops çalışır. Pek çok Ops, sıralama veya alaka düzeyi algoritmaları hakkında kapsamlı bilgiye sahip değildir, ancak Dev bunu yapar. Dev, kabul edilebilir bir doğrulukla kaynak kullanımını hızlı bir şekilde tahmin etme konusunda yılların deneyimine sahiptir. Dev, iş yükü seçeneklerini tüm katmanlara1-7 dağıtmanın avantaj ve dezavantajlarının farkında olmayabilir, belki sadece 7'de Ops yapar. Varlık-ilişki modellemesi bir geliştiriciye doğal gelebilir, ops olmayabilir. Sonunda, her ikisi de tüm katmanlarda ve katmanlarda Bizans başarısızlık senaryolarının ve esneklik modellerinin çeşitli formlarına çözümler keşfediyorlar.
Dünyasında, geliştiriciler ve operasyon mühendisleri benzer üst düzey beceri setlerine ve sorumluluklara sahipti; farklı oldukları yerde uzmanlıkları vardı. Farklı uzmanlıkları, sorunları çözmek için birlikte çalışmalarını teşvik etti ve ortak temel düzey becerileri, onlara bunu yapacakları bir dil verdi.
Bu genellikle çoğu durumda aldığım web işlemlerinin tanımıdır. Bu yüzden devam edeceğiz.
Peki, Site Güvenilirlik Mühendisliği nedir?
Google SRE kitabı, SRE'nin tanımıyla ... ve sonra başka bir kitapla ... açılır ve ardından rolü ve özellikleri kapsayan bir kitabın tamamını tanımlamaya devam eden bir bölüm harcar. Bir kuruluşta geliştirildiğinde bile, işi üzerinde anlaşılan tek bir tanımlamaya yoğunlaştırmanın zor olduğu görülmektedir.
Başlamak için, Ben Traynor'un Google'a katıldığı ve ilk Site Güvenilirlik Mühendisliği ekibi olanı kurduğu 2003 yılına geri dönmemiz gerekiyor. Birkaç paragraf önce 2010'ların başında olduğumuzu hatırlayın; ancak 2003 yılında, sektör hala doğal şey olarak sysadmin / geliştirici bölünmesine dayanıyordu. Bu yüzden Ben, bir yazılım mühendisi bir operasyon ekibi oluşturduğunda SRE'nin ne olacağını söylediğinde, bu, iki dünyanın şu anda göründüğünden çok daha radikal bir erimesiydi.
Önsözde verilen tanım, üç kelimenin her birini ayrı ayrı vurgular:
- Mühendislik - problemleri çözmek için bilgisayar bilimi ve mühendislik kavramlarının kullanımı
- Güvenilirlik - sistemleri daha ölçeklenebilir, daha güvenilir ve daha verimli hale getirmeye odaklanma
- Hizmet - SRE'lerin ağa bağlı hizmetlerden sorumlu olduğunu vurgulayan "site" nin daha sonraki evrimi
Giriş bölümünde, Site Güvenilirlik Mühendisliği ilkeleri şöyle sıralanmaktadır:
- Mühendisliğe kalıcı bir odaklanma sağlamak - sık sayfalardan ve diğer "zahmetten" kaçınmak için önleyici önlemler almak
- Bir hizmetin SLO'sunu ihlal etmeden maksimum değişiklik hızını ikna etmek - kendi yüzlerce kelime cevabına kolayca sahip olabilen, ancak çok fazla soruna neden olmadıkları sürece geliştiricilerin değişiklik yapmasına yardımcı olmak için kabaca özetlenen bir konu
- İzleme - işler yanlış gittiğinde otomatik uyarılar
- Acil durum müdahalesi - bir şeyleri bozulduğunda düzeltme
- Değişim yönetimi
- Kapasite planlaması
- Sağlama
- Verimlilik ve performans - sağlayarak bir hizmet gerçekleştirdiği en beklenen seviyeye - darboğazla kullanıcılara zarar verir, ancak aşırı kapasite masraf
Site Güvenilirlik Mühendisliğini modern Web Operasyonlarının özel bir alt kümesi olarak sınıflandırırdım. Bir SRE kuruluşu, büyük ölçüde her şeyi otomatize etmeye odaklanır , bu da oldukça büyük şirketlerde sadece uygun maliyetli bir dereceye kadar. Hata bütçeleri gibi fikirler yalnızca hizmetinizde çok fazla istek olduğunda işe yarayabilir, aksi takdirde ayrıntı düzeyini kaybedersiniz (daha küçük bir hizmet için belirli bir hata, dakikaya bağlı olarak isteklerinizin% 0-20'sini etkileyebilir). Güvenlik gibi ilgili alanlar SRE tanımında yer almamaktadır çünkü gerçek SRE ekiplerine sahip olacak kadar büyük şirketlerin güvenlik için özel ekipleri vardır.
SRE programı, Google tarafından tanımlandığı şekliyle, Google'ın özel ihtiyaçları için geliştirilmiş ve başka yerlerde uygulanamayan web operasyonlarıdır.
Ancak, Site Güvenilirlik Mühendisliği son zamanlarda daha geniş endüstri kullanımında genişlemektedir. Çok daha küçük bir şirkette çalışmama ve iş tanımım John Allspaw'un 2012 Etsy web ops tanımına çok iyi uymasına rağmen şu anki iş unvanım bir SRE. Teorim şu ki, tek bir alanın evrimini desteklemek için bir kısayol olarak başlıklar boyunca ilerliyoruz:
- Sistem yöneticileri olarak başladık .
- Daha sonra web siteleri bir "şey" haline geldikçe, iş ilanları , web'de uzmanlaşmış sistem yöneticilerini genel ofis BT'sini de işleyenlerden ayırmak için web operasyon mühendislerine başvurmaya başladı .
- Daha sonra DevOps'un web ops iş yükünü azaltmak için programlama kullanarak rahat olanları ayırması gerekiyordu.
- Ancak DevOps, net bir tanım eksikliğinden dolayı karıştıkça, çağrı destekli üretim hizmetlerini arayan kişileri aradığımızı belirtmek için Site Güvenilirlik Mühendisliği'ni kabul ettik.
Peki bir sysadmin ve bir SRE arasındaki fark nedir? Ünvanlarını aldıkları yıl. Geleneksel operasyonlar ve saha güvenilirliği mühendisliği arasındaki fark nedir? SRE sadece yeni araçlar (merhaba, kaplar!) Kullanarak ops'un mevcut enkarnasyonudur ve ağa bağlı programlar daha büyük ve daha önemli hale geldikçe, bir mühendisin daha fazlasını yapmasına izin veren uygulamalara daha fazla odaklanılmaktadır .