Web seminerinin sesi zayıf olduğundan onu yazıya döktük.
Adım Medvedev Eduard. Bugün SRE'nin ne olduğundan, SRE'nin nasıl ortaya çıktığından, SRE mühendislerinin hangi çalışma kriterlerine sahip olduğundan, biraz güvenilirlik kriterlerinden, biraz da izlenmesinden bahsedeceğim. Zirvelerde yürüyeceğiz, çünkü bir saat içinde pek bir şey söyleyemezsiniz, ancak ek inceleme için materyaller vereceğim ve hepimiz sizi bekliyoruz. . Ocak ayının sonunda Moskova'da.
Öncelikle SRE'nin ne olduğundan bahsedelim - Site Güvenilirliği Mühendisliği. Ve nasıl da ayrı bir konum, ayrı bir yön olarak ortaya çıktı. Her şey, geleneksel geliştirme çevrelerinde Dev ve Ops'un tamamen farklı iki ekip olması ve genellikle tamamen farklı iki hedefe sahip olmasıyla başladı. Geliştirme ekibinin hedefi yeni özellikler sunmak ve işletmenin ihtiyaçlarını karşılamaktır. Operasyon ekibinin amacı her şeyin çalıştığından ve hiçbir şeyin bozulmadığından emin olmaktır. Açıkçası, bu hedefler birbiriyle doğrudan çelişiyor: her şeyin çalışması ve hiçbir şeyin bozulmaması için yeni özelliklerin mümkün olduğunca az sunulması. Bu nedenle, şu anda DevOps olarak adlandırılan metodolojinin çözmeye çalıştığı birçok iç çatışma var.
Sorun şu ki, DevOps'un net bir tanımına ve DevOps'un net bir uygulamasına sahip değiliz. 2 yıl önce Yekaterinburg'da bir konferansta konuşmuştum ve şimdiye kadar DevOps bölümü “DevOps Nedir” raporuyla başlıyordu. 2017 yılında Devops neredeyse 10 yaşında ama biz hâlâ ne olduğunu tartışıyoruz. Ve bu, Google'ın birkaç yıl önce çözmeye çalıştığı çok tuhaf bir durum.
2016 yılında Google, Site Güvenilirliği Mühendisliği adlı bir kitap yayınladı. Ve aslında SRE hareketi bu kitapla başladı. SRE, DevOps paradigmasının belirli bir şirkette özel bir uygulamasıdır. SRE mühendisleri sistemlerin güvenilir şekilde çalışmasını sağlamaya kararlıdır. Çoğunlukla geliştiricilerden, bazen de güçlü bir geliştirme geçmişine sahip yöneticilerden geliyorlar. Ve sistem yöneticilerinin yaptığını yapıyorlar, ancak kod açısından sistemin geliştirilmesi ve bilgisi konusunda güçlü bir altyapı, bu kişilerin rutin idari işlere değil, otomasyona eğilimli olmasına yol açıyor.
SRE ekiplerinde DevOps paradigmasının, yapısal sorunları çözen SRE mühendislerinin bulunmasıyla hayata geçirildiği ortaya çıktı. İşte insanların 8 yıldır bahsettiği Dev ve Ops arasındaki bağlantının aynısı. Bir SRE'nin rolü, yeni gelenlerin SRE haline gelmemesi açısından mimarınkine benzer. Kariyerlerinin başında olan insanlar henüz herhangi bir deneyime sahip değiller, gerekli bilgi birikimine sahip değiller. Çünkü SRE, tam olarak neyin ve ne zaman ters gidebileceğine dair çok ince bir bilgi gerektirir. Bu nedenle burada kural olarak hem şirket içinde hem de dışında biraz deneyime ihtiyaç vardır.
SRE ile devops arasındaki farkın açıklanıp açıklanmayacağını soruyorlar. Az önce tarif edildi. SRE'nin organizasyon içindeki yerinden bahsedebiliriz. Ops'un hâlâ ayrı bir departman olduğu bu klasik DevOps yaklaşımının aksine SRE, geliştirme ekibinin bir parçasıdır. Ürün geliştirmede yer alırlar. Hatta SRE'nin bir geliştiriciden diğerine geçen bir rol olduğu bir yaklaşım bile var. Kod incelemelerine örneğin UX tasarımcıları, geliştiricilerin kendileri ve bazen ürün yöneticileriyle aynı şekilde katılırlar. SRE'ler aynı seviyede çalışır. Bunları onaylamamız gerekiyor, bunları gözden geçirmemiz gerekiyor, böylece SRE her dağıtım için şunu söyleyecektir: "Tamam, bu dağıtım, bu ürün güvenilirliği olumsuz etkilemeyecek. Ve eğer öyleyse, o zaman kabul edilebilir sınırlar dahilinde. Bu konuyu da konuşacağız.
Buna göre, SRE'nin yasayı değiştirme konusunda veto hakkı vardır. Ve genel olarak bu, SRE'nin yanlış uygulanması durumunda bir tür küçük çatışmaya da yol açar. Site Güvenilirliği Mühendisliği hakkındaki aynı kitapta, bir tane bile değil, birçok bölüm bu çatışmaların nasıl önleneceğini anlatıyor.
SRE'nin bilgi güvenliğiyle nasıl ilişkili olduğunu soruyorlar. SRE doğrudan bilgi güvenliğiyle ilgili değildir. Temel olarak büyük şirketlerde bu, bireyler, test uzmanları ve analistler tarafından yapılır. Ancak SRE ayrıca güvenliği etkileyen bazı operasyonların, bazı taahhütlerin, bazı dağıtımların ürünün kullanılabilirliğini de etkileyebileceği anlamında onlarla etkileşime girer. Bu nedenle, SRE bir bütün olarak analistler de dahil olmak üzere güvenlik ekipleri de dahil olmak üzere tüm ekiplerle etkileşime sahiptir. Bu nedenle SRE'lere esas olarak DevOps'u uygulamaya çalışırken ihtiyaç duyulur, ancak aynı zamanda geliştiricilerin üzerindeki yük de çok büyük olur. Yani, geliştirme ekibinin kendisi artık Operasyonlardan da sorumlu olmaları gerektiği gerçeğiyle baş edemiyor. Ve ayrı bir rol var. Bu rol bütçede planlanmıştır. Bazen bu rol ekibin büyüklüğüne göre belirlenir, ayrı bir kişi ortaya çıkar, bazen geliştiricilerden biri olur. Takımda ilk SRE bu şekilde ortaya çıkıyor.
SRE'den etkilenen sistemin karmaşıklığı, operasyonun güvenilirliğini etkileyen karmaşıklık gerekli ve tesadüfidir. Gerekli karmaşıklık, bir ürünün karmaşıklığının yeni ürün özelliklerinin gerektirdiği ölçüde artmasıdır. Rastgele karmaşıklık, sistemin karmaşıklığının artması ancak ürün özelliğinin ve iş gereksinimlerinin bunu doğrudan etkilememesidir. Ya geliştiricinin bir yerde hata yaptığı ya da algoritmanın optimal olmadığı ya da özel bir ihtiyaç olmadan ürünün karmaşıklığını artıran bazı ek ilgi alanlarının ortaya çıktığı ortaya çıktı. İyi bir SRE her zaman bu durumu ortadan kaldırmalıdır. Yani, rastgele ekleme nedeniyle zorluğun arttığı herhangi bir taahhüt, herhangi bir dağıtım, herhangi bir çekme isteği engellenmelidir.
Soru şu; neden ekibe çok fazla bilgi sahibi bir sistem yöneticisi olan bir mühendisi işe almıyorsunuz? Bize mühendis rolündeki bir geliştiricinin en iyi personel bulma çözümü olmadığı söylendi. Mühendis rolündeki bir geliştirici her zaman en iyi personel alımı çözümü olmayabilir, ancak buradaki önemli nokta, Ops ile ilgilenen bir geliştiricinin otomasyon konusunda biraz daha istekli olması, uygulamaya koymak için biraz daha fazla bilgi ve beceri setine sahip olmasıdır. bu otomasyon. Ve buna göre, yalnızca bazı belirli operasyonlar için gereken süreyi, yalnızca rutini değil, aynı zamanda MTTR (Ortalama Kurtarma Süresi, kurtarma süresi) gibi önemli iş parametrelerini de azaltıyoruz. Böylece, buna da biraz sonra değineceğiz, organizasyon için para biriktirmiş oluyoruz.
Şimdi SRE'nin çalışma kriterlerinden bahsedelim. Ve her şeyden önce güvenilirlikle ilgili. Küçük şirketlerde, start-up'larda insanlar genellikle hizmet iyi yazılırsa, ürün iyi ve doğru yazılırsa çalışacağını, bozulmayacağını varsayarlar. İşte bu, iyi kod yazıyoruz, bu yüzden kırılacak bir şey yok. Kod çok basit, kırılacak hiçbir şey yok. Bunlar testlere ihtiyacımız olmadığını söyleyenlerle hemen hemen aynı kişiler, çünkü bakın bunlar üç VPI yöntemi, neden burada kırılalım?
Bunların hepsi yanlış elbette. Ve bu insanlar pratikte bu tür kodlar tarafından sıklıkla ısırılıyor çünkü işler bozuluyor. Bazen işler en öngörülemeyen şekillerde bozulur. Bazen insanlar hayır diyor, bu asla olmayacak. Ve bu her zaman olur. Bu yeterince sık olur. İşte bu yüzden hiç kimse %100 kullanılabilirlik için çabalamıyor çünkü %100 kullanılabilirlik asla gerçekleşmiyor. Bu normdur. Bu nedenle, bir hizmetin kullanılabilirliğinden bahsettiğimizde daima dokuzlardan bahsederiz. 2 dokuzlu, 3 dokuzlu, 4 dokuzlu, 5 dokuzlu. Bunu kesinti süresine çevirirsek, örneğin 5 dokuz, o zaman bu yılda 5 dakikadan biraz fazla kesinti süresidir, 2 dokuz, 3,5 günlük kesinti süresidir.
Ancak bir noktada POI'de, yatırım getirisinde bir azalma olduğu açıktır. İki dokuzludan üç dokuzluya geçiş, 3 günden fazla daha az kesinti anlamına gelir. Dört dokuzdan beşe geçmek, aksama süresini yılda 47 dakika azaltır. Ve iş açısından bunun kritik olmayabileceği ortaya çıktı. Ve genel olarak gerekli güvenilirlik teknik bir konu değil, her şeyden önce bir iş meselesidir, bir ürün meselesidir. Ürünü kullananlar için ne düzeyde bir kesinti kabul edilebilir, ne bekliyorlar, ne kadar ödüyorlar, örneğin ne kadar para kaybediyorlar, sistem ne kadar para kaybediyor.
Burada önemli bir soru, geri kalan bileşenlerin güvenilirliğinin ne olduğudur. Çünkü 4 dokuzluk güvenilirliğe sahip bir akıllı telefonda 5 ile 2 dokuz arasındaki fark görünmeyecektir. Kabaca söylemek gerekirse, hizmetinizdeki bir akıllı telefonda yılda 10 kez bir şey bozulursa, büyük olasılıkla 8 kez işletim sistemi tarafında bir arıza meydana geldi. Kullanıcı buna alışkındır ve yılda bir kez daha buna dikkat etmeyecektir. Artan güvenilirliğin ve artan kârın bedelini ilişkilendirmek gerekir.
Sadece SRE ile ilgili kitapta 4 dokuzludan 3 dokuzluya çıkmanın güzel bir örneği var. Kullanılabilirlikteki artışın %0,1'den biraz daha az olduğu ortaya çıktı. Hizmetin geliri yıllık 1 milyon dolar ise gelir artışı 900 dolardır. Kullanılabilirliği dokuz kat artırmanın bize maliyeti yılda 900 dolardan azsa, bu artış mali açıdan anlamlı olacaktır. Eğer yılda 900 dolardan fazlaya mal oluyorsa, bunun artık bir anlamı yok çünkü gelirdeki artış, işgücü maliyetlerini ve kaynak maliyetlerini telafi etmiyor. Ve bize 3 dokuzluk yeterli olacak.
Bu elbette tüm isteklerin eşit olduğu basitleştirilmiş bir örnektir. Ve 3 dokuzdan 4 dokuza çıkmak yeterince kolay ama aynı zamanda örneğin 2 dokuzdan 3'e çıkmak zaten 9 bin dolarlık bir tasarruf, finansal açıdan mantıklı olabilir. Doğal olarak gerçekte kayıt talebinin başarısız olması sayfanın görüntülenmemesinden daha kötüdür, taleplerin farklı ağırlıkları vardır. İş açısından tamamen farklı bir kriterleri olabilir, ancak yine de, kural olarak, bazı belirli hizmetlerden bahsetmiyorsak, bu oldukça güvenilir bir yaklaşımdır.
Hizmet için bir mimari çözüm seçerken SRE'nin koordinatörlerden biri olup olmadığı yönünde bir soru aldık. Mevcut altyapıya entegrasyon açısından diyelim ki stabilitesinde bir kayıp olmasın. Evet, SRE'ler, çekme istekleri, taahhütler, sürümler gibi mimariyi, yeni hizmetlerin tanıtılmasını, mikro hizmetleri, yeni çözümlerin uygulanmasını etkiler. Neden daha önce dedim ki tecrübe lazım, vasıf lazım. Aslında SRE, herhangi bir mimari ve yazılım çözümündeki engelleyici seslerden biridir. Buna göre, bir mühendis olarak bir SRE, her şeyden önce, bazı belirli kararların güvenilirliği, istikrarı nasıl etkileyeceğini anlamalı, aynı zamanda anlamalı ve bunun iş ihtiyaçlarıyla nasıl ilişkili olduğunu ve hangi bakış açısıyla kabul edilebilir ve kabul edilebilir olduğunu da anlamalıdır. hangisi değil.
Bu nedenle artık sadece SRE'de geleneksel olarak SLA (Hizmet Seviyesi Anlaşması) olarak tanımlanan güvenilirlik kriterlerinden bahsedebiliriz. Büyük olasılıkla tanıdık bir terim. SLI (Hizmet Seviyesi Göstergesi). SLO (Hizmet Düzeyi Hedefi). Hizmet Seviyesi Anlaşması belki de sembolik bir terimdir, özellikle de ağlarla, sağlayıcılarla ve barındırmayla çalıştıysanız. Bu, tüm hizmetinizin performansını, cezaları, hatalara ilişkin bazı cezaları, ölçümleri, kriterleri açıklayan genel bir sözleşmedir. Ve SLI, kullanılabilirlik metriğinin kendisidir. Yani SLI ne olabilir: hizmetin yanıt süresi, yüzde olarak hata sayısı. Bir çeşit dosya barındırma ise bant genişliği olabilir. Tanıma algoritmaları söz konusu olduğunda gösterge, örneğin cevabın doğruluğu bile olabilir. SLO (Hizmet Seviyesi Hedefi), sırasıyla SLI göstergesinin, değerinin ve süresinin birleşimidir.
Diyelim ki SLA bu şekilde olabilir. Hizmet yıl boyunca %99,95 oranında mevcuttur. Veya 99 kritik destek bildirimi üç ayda bir 3 saat içinde kapatılacaktır. Veya sorguların %85'i her ay 1,5 saniye içinde yanıt alacaktır. Yani yavaş yavaş hata ve başarısızlıkların oldukça normal olduğunu anlamaya başlıyoruz. Bu kabul edilebilir bir durum, bunu planlıyoruz, hatta bir dereceye kadar da buna güveniyoruz. Yani SRE, hata yapabilen, hatalara normal şekilde yanıt vermesi gereken ve bunları dikkate alması gereken sistemler oluşturur. Ve mümkün olduğunda, hataları, kullanıcının ya fark etmeyeceği ya da fark edeceği şekilde ele almaları gerekir, ancak her şeyin tamamen çökmeyeceği bir tür geçici çözüm vardır.
Örneğin, YouTube'a bir video yüklerseniz ve YouTube bunu hemen dönüştüremiyorsa, video çok büyükse, format optimal değilse, o zaman doğal olarak istek zaman aşımı ile başarısız olmaz, YouTube 502 hatası vermez. , YouTube şöyle diyecek: “Her şeyi oluşturduk, videonuz işleniyor. Yaklaşık 10 dakika sonra hazır olacak." Bu, örneğin ön uç geliştirmeden aşina olduğunuz, eğer bunu daha önce yaptıysanız, zarif bozulma ilkesidir.
Güvenilir, hatalı, beklentilerle çalışmak için çok önemli olan bundan sonra bahsedeceğimiz terimler MTBF ve MTTR'dir. MTBF, arızalar arasındaki ortalama süredir. MTTR Ortalama İyileşme Süresi, ortalama iyileşme süresi. Yani, hatanın tespit edildiği andan itibaren, hatanın ortaya çıktığı andan hizmetin tamamen normal çalışmaya döndürüldüğü ana kadar ne kadar zaman geçti. MTBF esas olarak kod kalitesi üzerinde çalışılarak düzeltilir. Yani SRE’lerin “hayır” diyebilmesidir. Ve tüm ekibin şunu anlaması gerekiyor ki, SRE "hayır" dediğinde bunu zararlı olduğu için ya da kötü olduğu için değil, aksi takdirde herkes acı çekeceği için söylüyor.
Yine, sık sık bahsettiğim kitapta bile diğer geliştiricilerin SRE'den nefret etmeye başlamamalarını nasıl sağlayacağıma dair pek çok makale, pek çok yöntem, pek çok yol var. Öte yandan MTTR, SLO'larınız (Hizmet Seviyesi Hedefi) üzerinde çalışmakla ilgilidir. Ve çoğunlukla otomasyondur. Çünkü örneğin SLO'muz çeyrek başına 4 dokuzluk çalışma süresidir. Bu, 3 ayda 13 dakikalık kesintiye izin verebileceğimiz anlamına geliyor. Ve MTTR'nin 13 dakikadan fazla olamayacağı ortaya çıktı. 13 dakika içinde en az 1 kesintiye yanıt verirsek bu, çeyrek için bütçenin tamamını zaten tükettiğimiz anlamına gelir. SLO'yu kırıyoruz. Bir kazaya tepki vermek ve durumu düzeltmek için 13 dakika bir makine için çok uzun bir süre olsa da bir insan için çok kısadır. Çünkü bir kişinin uyarı almasına, tepki vermesine, hatayı anlamasına kadar zaten birkaç dakika var. Bir kişi bunu nasıl düzelteceğini, tam olarak neyi düzelteceğini, ne yapacağını anlayana kadar bu birkaç dakika daha sürer. Ve aslında, sunucuyu yeniden başlatmanız veya yeni bir düğüm yükseltmeniz gerekse bile, manuel olarak MTTR zaten yaklaşık 7-8 dakikadır. Süreci otomatikleştirirken MTTR sıklıkla bir saniyeye, bazen de milisaniyeye ulaşır. Google genellikle milisaniyelerden bahsediyor ancak gerçekte elbette her şey o kadar da iyi değil.
İdeal durumda SRE'nin işini neredeyse tamamen otomatikleştirmesi gerekir çünkü bu, MTTR'yi, metriklerini, tüm hizmetin SLO'sunu ve buna bağlı olarak iş kârını doğrudan etkiler. Süre aşılırsa SRE'nin hatalı olup olmadığı sorulur. Neyse ki suçlanacak kimse yok. Ve bu, bugün konuşmayacağımız, balmeless postmortem adı verilen ayrı bir kültür, ancak Slurm'da analiz edeceğiz. Bu çok ilginç ve üzerinde çokça konuşulabilecek bir konudur. Kabaca konuşursak, eğer üç ayda bir ayrılan süre aşılırsa, o zaman herkesin bir kısmı suçludur, bu da herkesi suçlamanın üretken olmadığı anlamına gelir, bunun yerine belki kimseyi suçlamayalım, durumu düzeltelim ve sahip olduğumuz şeyle çalışalım. Tecrübelerime göre bu yaklaşım çoğu takıma, özellikle de Rusya'ya biraz yabancı geliyor ama mantıklı ve çok işe yarıyor. Bu nedenle yazının ve literatürün sonunda bu konuyla ilgili okuyabileceğiniz tavsiyelerde bulunacağım. Veya Slurm SRE'ye gelin.
Açıklamama izin ver. Çeyrek başına SLO süresi aşılırsa, kesinti süresi 13 dakika değil 15 dakika ise bunun sorumlusu kim olabilir? Elbette SRE hatalı olabilir çünkü açıkça kötü bir taahhüt veya dağıtım gerçekleştirdi. Veri merkezi yöneticisi bazı planlanmamış bakımlar yapmış olabileceği için bunun sorumlusu olabilir. Bunun sorumlusu veri merkezi yöneticisiyse, SLO üzerinde anlaşmaya varırken bakımı hesaplamamaktan da Ops'taki kişi sorumlu olacaktır. Bu, yöneticinin, teknik direktörün veya veri merkezi sözleşmesini imzalayan ve veri merkezi SLA'sının gerekli kesinti süresi için tasarlanmadığına dikkat etmeyen birinin hatasıdır. Buna göre bu durumun sorumlusu biraz da olsa herkestir. Bu da, bu durum için özellikle kimseyi suçlamanın bir anlamı olmadığı anlamına geliyor. Ama elbette düzeltilmesi gerekiyor. Bu yüzden postmortemler var. Ve örneğin GitHub'un otopsilerini okursanız ve bu her zaman çok ilginç, küçük ve her özel durumda beklenmedik bir hikayeyse, kimsenin suçlunun bu belirli kişi olduğunu söylemediğini değiştirebilirsiniz. Suç her zaman belirli eksik süreçlere yüklenir.
Bir sonraki soruya geçelim. Otomasyon. Diğer bağlamlarda otomasyondan bahsettiğimde genellikle, bir görevi otomatikleştirmek için gerçekte tasarruf ettiğinizden daha fazla zaman harcamadan ne kadar süre çalışabileceğinizi söyleyen bir tabloya atıfta bulunurum. Bir engel var. İşin püf noktası, SRE'ler bir görevi otomatikleştirdiğinde, yalnızca zamandan tasarruf etmekle kalmıyor, aynı zamanda paradan da tasarruf sağlıyor çünkü otomasyon MTTR'yi doğrudan etkiliyor. Adeta tükenebilir bir kaynak olan çalışanların ve geliştiricilerin moralini kurtarıyorlar. Rutini azaltırlar. Ve otomasyonun zaman maliyetleri açısından bir anlam ifade etmediği görülse bile, tüm bunların iş ve sonuç olarak iş üzerinde olumlu bir etkisi var.
Aslında neredeyse her zaman öyledir ve SRE rolünde bir şeyin otomatikleştirilmemesi gereken çok az durum vardır. Şimdi hata bütçesi, yani hata bütçesi denilen şeyden bahsedeceğiz. Aslında, sizin için her şey kendiniz için belirlediğiniz SLO'dan çok daha iyiyse, bunun da pek iyi olmadığı ortaya çıktı. Bu oldukça kötü çünkü SLO yalnızca alt sınır olarak değil aynı zamanda yaklaşık üst sınır olarak da çalışıyor. Kendinize %99 kullanılabilirlik SLO'su belirlediğinizde ve aslında %99,99'a sahip olduğunuzda, işe hiç zarar vermeyecek denemeler için bir miktar alanınız olduğu ortaya çıkıyor çünkü bunu hep birlikte kendiniz belirlediniz ve siz bu alan kullanılmaz. Hatalar için bir bütçeniz var ve sizin durumunuzda bu da tüketilmiyor.
Bununla ne yapacağız? Kelimenin tam anlamıyla her şey için kullanıyoruz. Üretim koşullarında test yapmak, performansı etkileyebilecek yeni özelliklerin kullanıma sunulması, sürümler, bakım ve planlı kesintiler için. Bunun tersi kural da geçerlidir: Bütçe tükenirse yeni bir şey yayınlayamayız çünkü aksi takdirde SLO'yu aşmış oluruz. Bütçe zaten tükendi, performansı olumsuz etkiliyorsa bir şeyi yayınladık, yani bu başlı başına doğrudan SLO'yu artıran bir tür düzeltme değilse, o zaman bütçenin ötesine geçiyoruz ve bu kötü bir durum analiz edilmesi, otopsi yapılması ve muhtemelen bazı süreç düzeltmeleri yapılması gerekiyor.
Yani, hizmetin kendisi iyi çalışmıyorsa ve SLO harcanıyorsa ve bütçe deneylere değil, bazı sürümlere değil, kendi başına harcanıyorsa, o zaman bazı ilginç düzeltmeler yerine, ilginç özellikler yerine, ilginç sürümler yerine. Herhangi bir yaratıcı çalışma yerine, bütçeyi yeniden düzene sokmak için aptalca düzeltmelerle uğraşmak veya SLO'yu düzenlemek zorunda kalacaksınız ve bu da çok sık gerçekleşmemesi gereken bir süreç.
Bu nedenle, hatalar için daha fazla bütçemizin olduğu bir durumda herkesin ilgilendiği ortaya çıktı: hem SRE hem de geliştiriciler. Geliştiriciler için hatalar için büyük bir bütçe, sürümler, testler ve denemelerle ilgilenebileceğiniz anlamına gelir. SRE'ler için hatalar için bir bütçe ayırmak ve o bütçeye girmek, doğrudan işlerini iyi yaptıkları anlamına gelir. Bu da bir tür ortak çalışmanın motivasyonunu etkiliyor. Geliştiriciler olarak SRE'lerinizi dinlerseniz, iyi işler için daha fazla alana ve çok daha az rutine sahip olursunuz.
Üretimdeki deneylerin büyük ekiplerde SRE'nin oldukça önemli ve neredeyse ayrılmaz bir parçası olduğu ortaya çıktı. Ve buna genellikle kaos mühendisliği denir ve bu, Chaos Monkey adlı bir yardımcı programı yayınlayan Netflix ekibinden gelir.
Chaos Monkey, CI/CD hattına bağlanır ve üretim sırasında sunucuyu rastgele çökertir. Yine SRE yapısında çöken bir sunucunun kendi içinde kötü olmadığı, beklenen bir durumdan bahsediyoruz. Ve eğer bütçe dahilinde ise kabul edilebilir ve işletmeye zarar vermez. Tabii ki, Netflix'in yeterli sayıda yedek sunucusu, yeterli çoğaltması var, böylece tüm bunlar düzeltilebilir ve böylece kullanıcı bir bütün olarak farkına bile varmaz ve dahası, hiç kimse herhangi bir bütçe için bir sunucudan ayrılmaz.
Netflix bir süredir bu tür yardımcı programlardan oluşan bir pakete sahipti; bunlardan biri olan Chaos Gorilla, Amazon'un Erişilebilirlik Alanlarından birini tamamen kapatıyor. Ve bu tür şeyler, neyin neyi etkilediği, neyin neye bağlı olduğu tam olarak belli olmadığında, öncelikle gizli bağımlılıkları ortaya çıkarmaya yardımcı olur. Ve eğer bir mikro hizmetle çalışıyorsanız ve belgeler tam olarak mükemmel değilse, bu size tanıdık gelebilir. Ve yine, bu, aşamalandırmada yakalayamayacağınız koddaki hataları yakalamanıza çok yardımcı olur, çünkü yük ölçeğinin farklı olması, yük düzeninin farklı olması, ekipmanın farklı olması nedeniyle herhangi bir aşamalandırma tam olarak kesin bir simülasyon değildir. ayrıca büyük olasılıkla diğer. Pik yükler de beklenmedik ve öngörülemez olabilir. Ve yine bütçeyi aşmayan bu tür testler, altyapıdaki aşamalandırmanın, otomatik testlerin, CI / CD hattının asla yakalayamayacağı hataları yakalamaya çok iyi yardımcı olur. Ve bunların hepsi bütçenize dahil olduğu sürece, hizmetinizin oraya düşmesinin bir önemi yok, her ne kadar çok korkutucu görünse de, sunucunun çökmesi, tam bir kabus. Hayır, bu normal, bu iyi, bu hataları yakalamaya yardımcı oluyor. Bütçeniz varsa harcayabilirsiniz.
S: Hangi literatürü önerebilirim? Sonunda listeleyin. Çok fazla literatür var, birkaç rapor önereceğim. Nasıl çalışır ve SRE, kendi yazılım ürünü olmayan veya çok az gelişme gösteren şirketlerde çalışır mı? Örneğin ana faaliyetinin yazılım olmadığı bir kuruluşta. Ana faaliyetin yazılım olmadığı bir kuruluşta SRE, diğer her yerde olduğu gibi tamamen aynı şekilde çalışır, çünkü bir kuruluşta, geliştirilmemiş olsa bile yazılım ürünlerini de kullanmanız, güncellemeleri yayınlamanız, değiştirmeniz gerekir. altyapıyı büyütmeniz, ölçeklendirmeniz gerekiyor. Ve SRE'ler bu süreçlerdeki olası sorunları belirlemeye ve tahmin etmeye ve bir miktar büyüme başladıktan ve iş ihtiyaçları değiştikten sonra bunları kontrol etmeye yardımcı olur. Çünkü en azından birkaç sunucunuz varsa ve en azından bir miktar büyüme elde etmeniz bekleniyorsa, SRE'ye sahip olmak için yazılım geliştirmeyle uğraşmanıza kesinlikle gerek yoktur.
Aynı şey küçük projeler ve küçük organizasyonlar için de geçerli çünkü büyük şirketlerin bütçesi ve deneme alanı var. Ancak aynı zamanda tüm bu deney meyveleri her yerde kullanılabilir, yani SRE elbette Google'da, Netflix'te, Dropbox'ta göründü. Ancak aynı zamanda küçük şirketler ve yeni kurulan şirketler zaten yoğunlaştırılmış materyalleri okuyabilir, kitap okuyabilir, raporları izleyebilir. Bunu daha sık duymaya başlıyorlar, spesifik örneklere bakıyorlar, bence sorun değil, gerçekten faydalı olabilir, buna bizim de ihtiyacımız var, harika.
Yani, bu süreçleri standartlaştırmaya yönelik tüm ana çalışmalar sizin için zaten yapılmıştır. Size, SRE'nin özel olarak şirketinizdeki rolünü belirlemek ve yine daha önce açıklanan tüm bu uygulamaları fiilen uygulamaya başlamak kalıyor. Yani küçük şirketler için faydalı prensiplerden SLA, SLI, SLO'nun tanımı her zaman budur. Yazılımla ilgilenmiyorsanız, bunlar dahili SLA'lar ve dahili SLO'lar, yani hatalar için dahili bir bütçe olacaktır. Bu neredeyse her zaman ekip içinde ve işletme içinde bazı ilginç tartışmalara yol açar, çünkü altyapıya, bir tür ideal süreçlerin organizasyonuna harcadığınız paranın, ideal boru hattının gereğinden çok daha fazla olduğu ortaya çıkabilir. Ve BT departmanında sahip olduğunuz bu 4 dokuzluya artık gerçekten ihtiyacınız yok. Ama aynı zamanda zaman harcayabilir, bütçeyi hatalar için başka bir şeye harcayabilirsiniz.
Buna göre izleme ve izlemenin organizasyonu her büyüklükteki şirket için faydalıdır. Ve genel olarak, hataların kabul edilebilir olduğu, bütçenin olduğu, Hedeflerin olduğu bu düşünce tarzı, yine 3 kişilik startuplardan başlayarak her büyüklükteki şirket için faydalıdır.
Bahsedilecek teknik nüansların sonuncusu izlemedir. Çünkü SLA, SLI, SLO'dan bahsediyorsak bütçeye uyup uymadığımızı, Hedeflerimize uyup uymadığımızı ve nihai SLA'yı nasıl etkilediğimizi izlemeden anlayamayız. İzlemenin şu şekilde gerçekleştiğini o kadar çok gördüm ki; bir değer var; örneğin sunucuya gelen isteğin süresi, ortalama süre ya da veritabanına gelen isteklerin sayısı. Bir mühendisin belirlediği bir standardı var. Metrik normdan saparsa bir e-posta gelir. Kural olarak bunların hepsi kesinlikle işe yaramaz, çünkü bir kişinin öncelikle bunları her zaman yorumlaması, yani metriğin değerinin şu anlama gelip gelmediğini belirlemesi gerektiğinde, bu kadar çok uyarıya, izlemeden gelen çok sayıda mesaja yol açar. bazı eylemlere ihtiyaç var. İkincisi, aslında kendisinden herhangi bir işlem yapılması gerekmediğinde tüm bu uyarıları fark etmeyi bırakıyor. Bu iyi bir izleme kuralıdır ve SRE uygulandığında ilk kural, bildirimin yalnızca eylem gerektiğinde gelmesi gerektiğidir.
Standart durumda olayların 3 düzeyi vardır. Uyarılar var, biletler var, kayıtlar var. Uyarılar, hemen harekete geçmenizi gerektiren herhangi bir şeydir. Yani her şey bozuldu, hemen düzeltmeniz gerekiyor. Biletler gecikmeli işlem gerektiren şeylerdir. Evet, bir şeyler yapmanız gerekiyor, manuel olarak bir şeyler yapmanız gerekiyor, otomasyon başarısız oldu, ancak bunu önümüzdeki birkaç dakika boyunca yapmanıza gerek yok. Günlükler eylem gerektirmeyen her şeydir ve genel olarak işler iyi giderse kimse onları okumaz. Günlükleri yalnızca geriye dönüp baktığımızda bir şeyin bir süredir bozulduğunu ve bundan haberimizin olmadığını anladığımızda okumanız gerekecektir. Yoksa biraz araştırma mı yapmak gerekiyor? Ancak genel olarak herhangi bir işlem gerektirmeyen her şey günlüklere gider.
Tüm bunların bir yan etkisi olarak, hangi olayların eylem gerektirdiğini tanımlamışsak ve bu eylemlerin ne olması gerektiğini iyi tanımlamışsak, bu eylemin otomatikleştirilebileceği anlamına gelir. Yani ne olur. Alarmdan çıkıyoruz. Haydi eyleme geçelim. Bu eylemin açıklamasına gidiyoruz. Daha sonra otomasyona geçiyoruz. Yani herhangi bir otomasyon, bir olaya verilen tepkiyle başlar.
İzlemeden Gözlemlenebilirlik adı verilen bir terime geçiyoruz. Ayrıca son birkaç yıldır bu kelimenin etrafında bir miktar abartı var. Ve çok az insan bunun bağlam dışında ne anlama geldiğini anlıyor. Ancak asıl mesele, Gözlemlenebilirliğin sistem şeffaflığı için bir ölçü olmasıdır. Bir şeyler ters giderse, tam olarak neyin yanlış gittiğini ve o anda sistemin durumunun ne olduğunu ne kadar çabuk belirleyebilirsiniz. Kod açısından: hangi işlev başarısız oldu, hangi hizmet başarısız oldu. Örneğin dahili değişkenlerin, konfigürasyonun durumu neydi? Altyapı açısından bu, hatanın hangi erişilebilirlik bölgesinde meydana geldiği ve herhangi bir Kubernetes'iniz varsa, hatanın hangi pod'da meydana geldiği ve pod'un durumunun ne olduğudur. Buna göre Gözlemlenebilirliğin MTTR ile doğrudan ilişkisi vardır. Hizmetin Gözlemlenebilirliği ne kadar yüksek olursa, hatayı tanımlamak o kadar kolay olur, hatayı düzeltmek o kadar kolay olur, hatayı otomatikleştirmek o kadar kolay olur, MTTR o kadar düşük olur.
Tekrar küçük şirketlere dönersek, ekip büyüklüğünün nasıl ele alınacağı ve küçük bir ekibin ayrı bir SRE'yi işe alması gerekip gerekmediği şu anda bile sorulmaktadır. Bundan biraz önce bahsetmiştik. Bir startup'ın veya örneğin bir ekibin gelişiminin ilk aşamalarında bu hiç de gerekli değildir çünkü SRE bir geçiş rolü haline getirilebilir. Bu da takımı biraz canlandıracak çünkü en azından biraz çeşitlilik var. Ayrıca insanları, büyümeyle birlikte genel olarak SRE'nin sorumluluklarının çok önemli ölçüde değişeceği gerçeğine hazırlayacak. Bir kişiyi işe alırsanız elbette bazı beklentileri vardır. Ve zamanla bu beklentiler değişmeyecek ama gereksinimler çok değişecek. Bu nedenle, SRE'nin nasıl işe alınacağı erken aşamalarda oldukça zordur. Kendinizinkini büyütmek çok daha kolaydır. Ama düşünmeye değer.
Belki de tek istisna, çok katı ve iyi tanımlanmış büyüme gereksinimlerinin olduğu zamandır. Yani, bir startup söz konusu olduğunda bu, yatırımcıların bir tür baskısı olabilir, aynı anda birkaç kez büyüme için bir tür tahmin olabilir. O halde bir SRE'yi işe almak temelde haklı çünkü haklı gösterilebilir. Büyüme gereksinimlerimiz var, böyle bir büyümeyle hiçbir şeyin bozulmayacağı gerçeğinden sorumlu olacak bir kişiye ihtiyacımız var.
Bir soru daha. Geliştiriciler testleri geçen bir özelliği birkaç kez kestiğinde, ancak üretimi bozduğunda, tabanı yüklediğinde, diğer özellikleri bozduğunda ne yapılmalı, hangi işlemin uygulanacağı. Buna göre, bu durumda, ortaya çıkan hatalar için bütçedir. Ve bazı hizmetler, bazı özellikler halihazırda üretimde test ediliyor. Yalnızca az sayıda kullanıcıda, ancak zaten üretimde olan bir özellik dağıtıldığında, ancak zaten bir şey kırılırsa, örneğin tüm kullanıcıların yüzde yarımı için yine de gereksinimleri karşılayacağı beklentisiyle, bu kanarya olabilir. hatalar için bütçe. Buna göre evet bir hata olacak, bazı kullanıcılar için her şey bozulacak ama bunun normal olduğunu zaten söylemiştik.
SRE araçlarıyla ilgili bir soru vardı. Yani, SRE'lerin kullanıp diğer herkesin kullanmayacağı belirli bir şey var mı? Aslında, oldukça uzmanlaşmış bazı yardımcı programlar var; örneğin yükleri simüle eden veya kanarya A/B testi yapan bazı yazılımlar var. Ancak temel olarak SRE araçları, geliştiricilerinizin zaten kullandığı şeydir. Çünkü SRE doğrudan geliştirme ekibiyle etkileşime giriyor. Ve eğer farklı araçlarınız varsa, senkronizasyonun zaman aldığı ortaya çıkıyor. Özellikle SRE'ler büyük ekipler halinde çalışıyorsa, birden fazla ekibin bulunabileceği büyük şirketlerde, şirket çapında standardizasyon burada çok faydalı olacaktır, çünkü 50 ekip 50 farklı yardımcı program kullanıyorsa bu, SRE'nin hepsini bilmesi gerektiği anlamına gelir. Ve elbette bu asla olmayacak. Ve işin kalitesi, en azından bazı ekiplerin kontrol kalitesi önemli ölçüde azalacak.
Webinarımız sona yaklaşıyor. Bazı temel şeyleri anlatmayı başardım. Elbette SRE ile ilgili hiçbir şey bir saatte anlatılamaz ve anlaşılamaz. Ancak umarım bu düşünce tarzını, ana kilit noktaları aktarmayı başarmışımdır. Ve sonra, eğer ilgileniyorsanız, konuyu derinlemesine incelemek, kendi başınıza öğrenmek, bunun başka insanlar tarafından, diğer şirketlerde nasıl uygulandığına bakmak mümkün olacak. Ve buna göre Şubat ayı başlarında Slurm SRE'de bize gelin.
Slurm SRE, şu anda bahsettiğim konu hakkında konuşacağım üç günlük yoğun bir kurstur, ancak çok daha derinlemesine, gerçek vakalarla, pratikle, tüm yoğun kurs pratik çalışmaya yöneliktir. İnsanlar takımlara ayrılacak. Hepiniz gerçek vakalar üzerinde çalışacaksınız. Buna göre Booking.com eğitmenlerimiz Ivan Kruglov ve Ben Tyler var. Google'dan, San Francisco'dan harika bir Eugene Barabbas'ımız var. Ben de sana bir şey söyleyeceğim. Bu yüzden bizi ziyaret ettiğinizden emin olun.
Yani bibliyografya. SRE'de referanslar var. aynı kitapta veya daha doğrusu Google tarafından yazılan SRE hakkında 2 kitapta. Bir diğeri Şartların ve uygulamalarının biraz daha ayrıntılı olduğu yer. Sonraki 3'ü farklı şirketlerdeki SRE'ye ilişkin raporlardır. Birinci - , bu Google'dan Ben Trainer'ın açılış konuşması. Saniye - . Üçüncüsü yine . Dördüncü rapor 5 ülkede yalnızca 190 kilit SRE çalışanına sahip olan. Tüm bunlara bakmak çok ilginç çünkü DevOps'un farklı şirketler ve hatta farklı ekipler için çok farklı anlamlar ifade etmesi gibi, SRE'nin de benzer büyüklükteki şirketlerde bile çok farklı sorumlulukları var.
Kaos mühendisliğinin ilkelerine ilişkin 2 bağlantı daha: , . Ve sonunda Harika Listeler serisinin 3 listesi var. yaklaşık ve hakkında . SRE'deki liste inanılmaz derecede büyük, hepsini incelemeye gerek yok, yaklaşık 200 makale var. Oradan kapasite planlaması ve suçsuz ölüm sonrası hakkında makaleler almanızı şiddetle tavsiye ederim.
İlginç yazı:
Bunca zaman beni dinlediğiniz için teşekkür ederim. Umarım bir şeyler öğrenmişsindir. Umarım daha fazlasını öğrenmek için yeterli materyaliniz vardır. Ve görüşürüz. İnşallah şubatta.
Web seminerinin sunuculuğunu Eduard Medvedev gerçekleştirdi.
Not: Okumayı sevenler için Eduard bir referans listesi verdi. Pratikte anlamayı tercih edenler, .
Kaynak: habr.com