DevOps ve SRE'nin tüm ayrıntılarını tek bir makalede okuyun
İşletim ve bakımı bir disiplin olarak ele almak zordur.Sistemin nasıl çalıştırılacağına ilişkin genel sorun çözülmemiş olmasının yanı sıra, mevcut daha iyi fiili mücadele de çevreye büyük ölçüde bağımlıdır ve yaygın olarak kullanılmamaktadır. Çözülmemiş bir diğer sorun ise operasyon ve bakım ekibinin nasıl daha iyi yönetileceğidir. Bu sorunların ayrıntılı analizinin genellikle yöneylem araştırmasına adanmış araştırmalardan kaynaklandığı ve İkinci Dünya Savaşı sırasında Müttefik kuvvetlerin sürecini ve çıktılarını iyileştirmek için kullanıldığı düşünülmektedir.Aslında, binlerce yıldır, nasıl daha iyi olabileceğimizi düşünüyoruz. Operasyon
Bununla birlikte, bu kadar çaba ve düşünceye rağmen, özellikle bilgi teknolojisi ve yazılım çalışabilirliği alanlarında güvenilir üretim işletimi ve bakımını garanti etmek hala zordur.Örneğin, işletmeler açısından işletme ve bakım genellikle maliyet merkezleri olarak kabul edilir; mümkünse, Anlamlı iyileştirmeler yapmak daha da zordur.Bu yöntemin dar görüşlülüğü nedeniyle, geniş çapta anlaşılamamıştır, ancak onunla ilgili memnuniyetsizlik, BT'deki her şeyin nasıl organize edileceği konusunda bir devrimi tetiklemiştir. Bir dizi yaygın sorunu çözmeye çalışırken, bu sorunların iki çözümü vardır: DevOps ve SRE (Site Güvenilirliği Mühendisliği). Aslında düşündüğümüzden çok daha fazla benzerlikleri var
DevOps'un arkası
DevOps, BT geliştirme, çalıştırma ve bakım, ağ oluşturma ve güvenlik silolarını yıkmak için tasarlanmış gevşek bir uygulama, kılavuz ve kültür kümesidir. John Willis, Damon Edwards ve Jez Humble tarafından ortaklaşa yazılan CA (L) MS - kültür, otomasyon, yalın (yalın yönetim, sürekli teslimat gibi), ölçüm ve paylaşım anlamına gelir ve DevOps'un temel fikirlerinin kısaltmasıdır. Paylaşım ve işbirliği bu hareketin ön saflarında yer alır DevOps yönteminde, iyileştirin (genellikle otomasyon yoluyla), ardından sonuçları ölçün ve bu sonuçları iş arkadaşlarınızla paylaşın, böylece tüm organizasyon geliştirilebilir. Tüm CALMS ilkeleri bu destekleyici kültür tarafından kolaylaştırılır
DevOps, Agile ve diğer çeşitli iş ve yazılım mühendisliği tekniklerinin tümü, modern iş dünyasında nasıl iyi iş yapılacağına dair yaygın dünya görüşlerinin örnekleridir. DevOps düşüncesindeki herhangi bir öğe, temelde tasarım yoluyla elde edilen birbirinden kolayca ayrılamaz. Bununla birlikte, bazı temel fikirler nispeten bağımsız olarak tartışılabilir
Daha fazla ada yok (ahır etkisi)
İlk anahtar fikir: Artık ada yok. Bu fikre iki yanıt var:
Tarihte popüler, ancak artık eski moda bağımsız operasyonlar ve geliştirme ekipleri
Aslında, aşırı bilgi yalıtımı, tamamen kısmi optimizasyon teşvikleri ve işbirliği eksikliği, birçok durumda şirketler için çok kötüdür.
Kaza normaldir
İkinci temel fikir: Kazalar yalnızca bireysel izolasyonun sonucu değil, aynı zamanda işler kaçınılmaz olarak ters gittiğinde önlemlerin eksikliğinden kaynaklanıyor. Örneğin: kötü bir arayüz, stresli bir ortamda yanlış eylemlere neden olacaktır. Eğer (belirtilmemiş) bir hata durumu meydana gelirse, sistem hataları başarısızlığı kaçınılmaz hale getirir; kötü izleme, neyin yanlış gittiğini, bir sorun olduğunu bilmemizi engeller. Tüm geleneksel şirketler, hata yapıcıları ortadan kaldırmak ve cezalandırmak için kültürel içgüdüye sahiptir, ancak bunu yapmanın kendi sonuçları vardır: En bariz olanı, sorunun kafasını karıştırmak, gerçeği örtbas etmek ve diğerlerini suçlamak için motivasyonlar yaratmalarıdır; Yararsız bir dikkat dağıtıcıdır. Bu nedenle, arızalardan kurtarmayı hızlandırmaya odaklanmak, kazaları önlemekten daha anlamlıdır.
Değişiklikler kademeli olmalıdır
Üçüncü temel fikir: küçük ve sık değişiklikler daha iyidir. Değişim komitesi, radikal bir yaklaşım olan ana bilgisayar yapılandırmasını tamamen değiştirme planlarını tartışmak için ayda bir toplanır. Bununla birlikte, bu yaklaşım nadir değildir.Tüm değişiklikler deneyimli personel tarafından değerlendirilmeli ve etkili değerlendirme için gruplanmalıdır.Sonuç, en iyi uygulamaya az çok aykırıdır. Değişim risklidir, evet, ancak doğru yaklaşım, değişikliği olabildiğince bileşenlere veya birimlere bölmektir. Ardından, ürün, tasarım ve altyapı değişikliklerine dayalı olarak istikrarlı ve düşük riskli bir değişim hattı oluşturun. Küçük değişikliklerin otomatik testini ekleyen ve sorunlu değişiklikleri güvenilir bir şekilde geri alan bu strateji, bir değişim yönetimi yöntemi oluşturur: sürekli entegrasyon (CI) ve sürekli teslimat veya dağıtım (CD)
Araçlar ve kültür birbiriyle ilişkilidir
Araçlar ve kültür, DevOps'un önemli bir parçasıdır, özellikle de değişimin doğru yönetimini vurguladığında, değişim yönetimi oldukça spesifik araçlara dayanır. Ancak DevOps savunucuları, yeni çalışma yönteminin başarısının anahtarı olarak aracın kendisinden ziyade organizasyon kültürünü güçlü bir şekilde vurgulamaktadır. İyi bir kültür, bozuk aletler etrafında çalışmayı çözebilir, ancak bunun tersi nadiren uygulanabilir. Dediği gibi, kültür kahvaltı için strateji yiyor (kültürün etkisinin stratejinin çok ötesinde olduğu anlamına geliyor), işletim ve bakım gibi, kendini değiştirmek zordur.
Ölçüm önemlidir
Son olarak, ölçüm, siloların kırılması ve olay çözümü gibi genel iş bağlantılarında özellikle önemlidir. Her ortamda, olanların gerçekliğini belirlemek ve değişikliklerin beklendiği gibi yapılıp yapılmadığını doğrulamak için nesnel ölçümler kullanılır. Ve farklı işlevsel departmanların anlaşmaya varmaları için nesnel bir temel oluşturun (iş ve çağrı üzerine gibi diğer ortamlar için geçerlidir)
SRE'nin arka planı
Site Güvenilirliği Mühendisi (SRE), Google'ın mühendislikten sorumlu başkan yardımcısı Ben Treynor Sloss tarafından oluşturulan bir terimdir (ve ilgili iş rolü). Önceki bölümde söylediğimiz gibi DevOps, operasyonlar ve ürün geliştirme arasındaki tam döngü işbirliği hakkında bir dizi geniş ilkedir. SRE, bir iş rolü, bir dizi uygulama. DevOps bir felsefe ve çalışma yöntemiyse, SRE, DevOps tarafından açıklanan bazı fikirleri uygular ve "DevOps mühendisi" gibi iş veya rol tanımına daha yakındır. Bu nedenle, bir dereceye kadar SRE, DevOps'un gerçekleştirilmesidir. DevOps hareketinden farklı olarak DevOps hareketi, birden fazla şirketin liderleri ve uygulayıcıları arasındaki işbirliğinden kaynaklanıyordu. SRE yaygın bir şekilde popüler hale gelmeden önce, Google'ın SRE'si çevredeki şirketlerin kültürünün çoğunu miras aldı ve DevOps gibi kültürü vurgulamadı. Değişim
SRE aşağıdaki özel ilkelere sahiptir
İşletim ve bakım bir yazılım sorunudur
SRE'nin temel prensibi, iyi çalışma ve bakımın bir yazılım problemi olmasıdır. Bu nedenle, SRE bu sorunu çözmek için yazılım mühendisliği fikirlerini kullanmalıdır. Bu, süreç ve iş değişikliklerinden, iş mantığındaki tek başarısızlık noktalarını ortadan kaldırmak için yığını yeniden yazmak gibi benzer şekilde karmaşık ancak daha geleneksel yazılım sorunlarına kadar uzanan geniş bir alandır.
TİG'ler aracılığıyla yönetim (Hizmet Kalitesi Hedefleri)
SRE, ilk kitabımız "Site Güvenilirliği Mühendisliği" (Site Güvenilirliği Mühendisliği) 'de tartışıldığı gibi% 100 kullanılabilirlik sağlamaya çalışmayacaktır, bu birçok nedenden dolayı yanlış bir hedeftir. Bunun yerine, ürün ekibi ve SRE ekibi hizmet ve kullanıcı tabanı için uygun kullanılabilirlik hedefini seçer ve hizmeti bu SLO'ya yönetir. Böyle bir hedefi belirlemek, işletme departmanlarından güçlü bir işbirliği gerektirir. TİG'lerin kültürel çağrışımları da vardır: paydaşlar arasında işbirliğine dayalı bir karar olarak, TİG ihlalleri ekibi suçlanmadan çizim tahtasına geri getirecektir.
Günlük işleri azaltın
SRE için, her türlü manuel ve tekrarlayan işlem ve bakım görevleri iğrençtir. Bir makine istenilen operasyon ve bakım işlemlerini yapabiliyorsa, bunu sık sık yapmamız gerektiğine inanıyoruz. Bu fark ve değer diğer kuruluşlarda yaygın değildir ve bazı önemsiz görevler insan kaynaklarının tamamlamasını gerektirir. Google'daki SRE için önemsiz konular iş olarak yapılamaz. Operasyonel görevler için harcanan zaman, gerçekten proje üzerinde çalışmadığımız anlamına gelir - hizmeti nasıl daha güvenilir ve ölçeklenebilir hale getirebiliriz? Bununla birlikte, "üretim bilgeliği" operasyonları ve bakım görevlerini yerine getirmemiz için çok önemli yardım sağlar. Bu tür çalışmalar, sistemin gerçek zamanlı geri bildirimi belirlenerek gerçekleştirilebilir. Önemsiz konuların kaynağını belirleme ihtiyacı vardır, böylece bu görevler en aza indirilebilir ve hatta ortadan kaldırılabilir. Ancak, kendinizi kötü bir durumda çalışırken bulursanız, diğer mühendislerin desteklediğiniz hizmetlere aşina olabilmesi için yeni özellikleri ve değişiklikleri daha sık kullanmanız gerekebilir.
"Üretim Bilgeliği" nin Üretim Bilgeliği Açıklaması: Bu terimin kullanımı, gerçekte nasıl çalıştığı ve yazılımın nasıl tasarlanması gerektiği hakkında gerçekte izole olmaktan çok, çalıştığı üretim ortamından edindiğimiz bilgelik anlamına gelir. hizmet. Tüm olayların elde edilmesi ve iş emirlerini alan ekip, doğrudan gerçeklikle ilgilidir, bu da sistem tasarımı ve davranışı için daha iyi bilgi sağlayabilir.
İş otomasyonu
Bu alandaki asıl iş, hangi koşullarda neyin otomatikleştirileceğine ve nasıl otomatikleştirileceğine karar vermektir. Google'ın uygulamasında SRE: Ekip üyelerinin kalıcı değerli projeler üretmek yerine önemsiz şeylere harcadıkları zaman% 50 ile sınırlıdır. Pek çok insan bunu limitin üst sınırı olarak düşünür. Aslında, problemleri çözmek için mühendislik yöntemlerinin kullanılması, önemsiz görevleri defalarca yapmaktan çok daha yararlı olan açık bir ifade ve mekanizma olarak kabul edilir.
Otomasyon ve önemsiz şeyler hakkında düşündüğümüzde, temel ve nasıl çalıştığı sezgisel değildir. Zamanla, bir SRE ekibi otomatikleştirilebilen tüm hizmetleri otomatik hale getirecek ve geri kalanının otomatikleştirilmesi imkansız olacaktır (Murphy-Beyer etkisi). Bu, yapacak başka bir şey olmadıkça SRE ekibinin işine hakim olacaktır. Google ortamında, belirli sınırlara ulaşana kadar daha fazla hizmet ekleme eğilimindesiniz, hala% 50 mühendislik süresi var veya otomasyonda çok başarılısınız, tamamen farklı başka şeyler de yapabilirsiniz.
Başarısızlık maliyetini azaltarak hızla dolaşın
SRE'nin temel avantajlarından biri, güvenilirliği iyileştirmenin gerekli olmamasıdır, zaten gerçekleşmiş olsa bile, aslında ürün geliştirmenin çıktısını iyileştirir. neden? Genel arızalar için ortalama arıza süresini (MTTR) azaltmak, ürün geliştiricilerin yinelemeli hızını artıracaktır, çünkü mühendislerin sorun giderme sorunları için çok fazla enerji harcamasına gerek yoktur. Bu, ürün yaşam döngüsünün sonraki aşamalarında, düzeltilecek bir sorunun maliyetinin o kadar yüksek olduğu iyi bilinen bir olgudan kaynaklanmaktadır. SRE'ler, özellikle ürünün sonraki aşamalarında ortaya çıkan sorunları iyileştirmekten ve bunlarla başa çıkmaktan ve tüm şirkete fayda sağlamaktan sorumludur.
Sahipliği geliştiricilerle paylaşın
"Uygulama geliştirme" ve "üretim" (bazen Dev ve Ops olarak adlandırılır) arasındaki katı sınırlar tam tersi bir etkiye sahip olabilir. Sorumlulukların bölünmesini ve işletme ve bakım sınıflandırmasını, güç dengesizliklerine veya maaş farklılıklarına yol açacak maliyet merkezleri olarak görmek özellikle doğrudur.
SRE'ler, iş mantığı sorunları yerine üretim sorunlarına odaklanma eğilimindedir, ancak sorunları çözmek ve becerileri ürün geliştirme ekipleriyle paylaşmak için yazılım mühendisliği araçlarını kullandıkları için. Genel olarak konuşursak, SRE'lerin odaklandıkları hizmet kullanılabilirliği, gecikme süresi, performans, verimlilik, değişiklik yönetimi, izleme, acil durum müdahalesi ve kapasite planlaması konularında özel uzmanlıkları vardır. Bu özel beceriler (genellikle açıkça tanımlanmıştır), SRE'nin ürünler ve geliştirme ekipleri için teknik hizmetlerinin temelini oluşturur. İdeal olarak, ürün geliştirme ve SRE ekipleri teknoloji yığını ön uç, arka uç, kitaplık, depolama, çekirdek ve fiziksel makine konusunda bütünsel bir anlayışa sahiptir - hiçbir takım tek bir bileşene sahip olmayı kıskanmamalı
"Site Güvenilirliği Mühendisliği" kitabında açıkça belirtmedik: Google'da ürün geliştirme ekibi, hizmetlerinin varsayılan olarak sahibidir. SRE ilkesi hala tüm Google'a hizmeti nasıl yöneteceğini söylese de, SRE ilkesi her ikisidir Ne mevcut ne de garantili. SRE ekibinin sahiplik modeli ve ürün geliştirme ekibiyle işbirliği nihayetinde ortak bir modeldir.
İşlev veya konumdan bağımsız olarak aynı araçları kullanın
Araçlar, davranışın çok önemli bir belirleyicisidir. Google'ın ortamında, SRE birleşik bir kod tabanına, çeşitli yazılım ve sistem araçlarına ve son derece optimize edilmiş ve tescilli bir üretim yığınına sahip değilse çok saftır. Bu varsayımı DevOps ile paylaşıyoruz: Servis ekibi, organizasyondaki rollerine bakılmaksızın aynı servis araçlarını kullanmalıdır. Hizmetleri yönetmenin iyi bir yolu yoksa, bir araç SRE'ler tarafından kullanılır ve başka bir araç ürün geliştiricileri tarafından kullanılır.Farklı durumlarda, işlem farklıdır ve bu felaket olabilir. Ne kadar fazla anlaşmazlık olursa, şirket her bir aracı geliştirme çabasından o kadar az fayda sağlayacaktır.
DevOps ve SRE karşılaştırması
Yukarıda tartışılan ilkelerden, aralarında birçok ortak yön olduğunu görebiliriz:
Hem DevOps hem de SRE, sürekli iyileştirme için değişiklikleri kabul etmeye bağlıdır
İşbirliği, DevOps çalışmasının önü ve merkezidir ve etkili paylaşılan sahiplik modelleri ve ortaklıklar, SRE'nin işlemesi için gerekli koşullardır. DevOps gibi, SRE de kuruluşlar arasında paylaşılan güçlü bir değere sahiptir ve bu da ekipler arasındaki engelleri aşmayı kolaylaştırır.
Değişim için en iyi uygulama şudur: sürekli küçük ve sık değişiklikler Çoğu durumda, otomatik test ve uygulama gereklidir. Anahtar nokta, değişikliklerin kullanılabilirlik üzerindeki etkisinin özellikle SRE için önemli olmasıdır.
Doğru araçların kullanılması çok önemlidir ve araçlar eylemin kapsamını belirli bir ölçüde belirler. Bununla birlikte, bazı işlemleri gerçekleştirmek için belirli bir aracı kullanmaya çok fazla dikkat edemeyiz. Sistem yönetimi için API daha önemli bir yöntemdir
Metrikler hem DevOps hem de SRE için kritiktir. SRE için, SLO'lar (Hizmet Kalitesi Hedefleri) hizmetlerin iyileştirilip iyileştirilmeyeceğini belirler. Elbette, ölçüm standardı yoksa (ve ürün, altyapı / SRE ve iş arasında ekipler arası işbirliği), TİG olmayacaktır. DevOps için, ölçüm davranışı genellikle sürecin çıktısını, bir geri bildirim döngüsünün süresini vb. Anlamak için kullanılır. İster profesyonel ister felsefi bir bakış açısından, DevOps ve SRE veri odaklıdır
Üretim sunucularını yönetmenin acımasız gerçeği, ara sıra arızaların meydana gelmesidir ve nedenini söylemeniz gerekir. Hem SRE hem de DevOps suçsuzdur ve amaç anlamsız argümanları ortadan kaldırmaktır
Nihayetinde, DevOps veya SRE'nin uygulanması, her ikisi de tüm ekibin daha iyi çalışmasını sağlamak için birlikte çalışmanın belirli bir yolunu kullanmayı uman bütünsel bir davranıştır. DevOps ve SRE için daha iyi hız çıktı.
Gördüğünüz gibi DevOps ve SRE'nin birçok ortak noktası var. Bununla birlikte, önemli farklılıklar da vardır: DevOps bir anlamda daha geniş bir felsefe ve kültürdür. DevOps, belirli bir düzeyde nasıl çalışılacağı konusunda nispeten sessizdir. Örneğin, hizmetlerin yönetiminin nasıl ince ayar yapılacağını açıkça belirtmez, ancak daha geniş organizasyondaki engellerin nasıl kaldırılacağına odaklanır. Bu çok değerlidir.
Öte yandan, SRE'nin suçlama kapsamı nispeten dardır ve yetki kapsamı genel işten ziyade genellikle hizmet odaklıdır (son kullanıcı odaklı). Bu nedenle, sistemin verimli bir şekilde nasıl çalıştırılacağını çözmek için kendi bilgi çerçevesine (hata bütçesi gibi kavramlar dahil) sahiptir. SRE, bir meslek olarak teşvik hatalarına ve verimliliğe büyük önem vermesine rağmen, "örgütsel adalar" ve "bilgi engelleri" gibi konularda nispeten sessizdir. İş ihtiyaçları nedeniyle değil, geliştirilmiş operasyonel uygulamalar nedeniyle CI / CD'yi destekleyecektir. Veya başka bir deyişle, SRE, DevOps ile aynı şeylere inanır, ancak nedenler farklı olabilir
