g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

Alibaba e-ticaret arıza delme sisteminin yönetişim, gri sürüm, arıza tatbikatı, tasarımı ve pratik deneyimine güvenerek

Yazar Zhongting

Düzenle Xiaozhi

Alibaba 2016 yılında, hataları sisteme senaryo bazlı bir şekilde yatırmak, hataları çevrimiçi olarak aktif bir şekilde yeniden izlemek ve alarmları izleme, mevcut sınırlama bozulması, hata geçişi, felaket kurtarma stratejileri ve hata işlemenin etkinliğini doğrulamak için bir arıza prova sistemi geliştirdi. Bu makale, klasik arıza türlerini tartışacak, arızaların nedenlerini analiz edecek, çözümler önerecek, arıza delme sisteminin tasarımını ve gelişimini tanıtacak ve arıza tatbikatlarının ilkelerini ve deneyimlerini ortaya koyacaktır.

Not: Bu makale, Ali teknik uzmanı Zhong Ting tarafından QCon Beijing 2017'de yapılan bir konuşmadan derlendi ve Ali teknik kamu hesabının izniyle yeniden basıldı.

Önüne yaz

Bu makalede paylaşılan içerik esas olarak arıza yönetimi ile ilgilidir. Hepimizin bildiği gibi, hata yönetiminin kendisi nispeten büyük bir konudur ve neredeyse tüm operasyon ve bakım, Ar-Ge ve hata operasyon yönetimi pozisyonlarını içerir.Tuhaf bir hata, operasyonları ve ürün yöneticilerini de içerebilir. Arızanın acısı ve gözyaşlarından bahsetmişken, 45 dakikanın başlangıcı bile bitirmediğine inanıyorum. Bugünkü paylaşım, esas olarak başarısızlığın özüne geri dönmek ve başarısızlığın nedeninin perspektifini kesmekle ilgilidir. Ortaya çıkarılabilecek bazı metodolojik ve evrensel yöntemler olup olmadığına bakın. Umarım herkese yardımcı olabilir.

Önce kendimi tanıtın, benim adım Zhou Yang ve benim adım Zhongting. 2011 yılında Alibaba'nın kontak stabilitesi teknolojisi alanına katıldı ve stabilite ürünleri için bazı araştırma ve geliştirme çalışmaları yapmaya başladı.Aynı zamanda HTTPS dönüşümü, e-ticaret işlem bağlantısı yükseltme gibi bazı yapısal gelişim promosyon çalışmalarını da üstlenecek. 2015 yılında Double 11 büyük promosyonuna başladık.Paylaşımlı iş departmanının büyük tanıtımından sorumlu kişi olarak Double 11'in istikrarını sağladık. Ayrıca çifte 11 özel kuvvet unvanı olan çifte 11 yaşlı A'yı da kazandı.

Paylaşılan İşletme Departmanı, mevcut herkes için nispeten yeni olabilir. Başka bir deyişle, herkes ürünleri, işlemleri, üyelikleri, teklifleri, incelemeleri ve ara katman yazılımlarını bilmeli, bu Double 11'deki en zorlu zincirlerden biridir. Sağda, Double 11 işinin zirvesinden sonra ara katman yazılımı çekirdek savaş odası üyelerinin grup fotoğrafı var. 2016'dan bu yana, çalışmanın odak noktası normal istikrarın kesinliği olmuştur ve bugünün paylaşımı da esas olarak içeriğin bu kısmı etrafında yapılmaktadır.

Dağıtık sistemler genellikle hata yönetimi ve teknolojik gelişime dayanır

Önce bir soru sorayım, Taobao'nun hangi koşullar altında düştüğünü düşünürdünüz? Pek çok kişinin bu soruya dikkat ettiğine inanıyorum, ancak çoğu kişi kesin bir cevap veremez. Çünkü görünüşte basit olan bu soru gerçekten cevaplanması o kadar kolay görünmüyor. Bugünkü paylaşım, önce bu soruyu herkes için cevaplamaya çalışayım.

"Basit" bir sayfayla başlayalım. Bu sayfaya ürün ayrıntıları sayfası adı verilir. Çoğu kişi için bu sayfa, Taobao'da bir siparişi tamamlamak için ilk adımıdır. Ürün detay sayfasının misyonu, ürün bilgilerini rezervasyon yapmadan herkese göstermek, herkesin ilgisini uyandırmak, satın alma veya toplama işlemini tamamlaması için herkesi yönlendirmektir. Bilgi gösterimi açısından, ürün ayrıntıları sayfası gerçekten çok basit bir sayfadır.

Ürün detay sayfası uygulamasının arka plan mimarisine bir göz atalım. Ürün detay sayfası, Ali'nin ilk statik uygulamalarından biridir. Ürün başlığı, resim bilgileri, satış özellikleri kombinasyonu vb. Gibi görüntüleyiciyle ilgisi olmayan bilgiler doğrudan önbelleğe girilir ve indirimler, envanter, lojistik ve hizmetler gibi kullanıcıyla ilgili diğer dinamik bilgiler asenkron aramalarla statik olarak doldurulur. Sayfa çerçevesinden sonra. Bir sayfada karar vermek için yeterli bilgiyi görüntülemek ve kullanıcının satın alma isteğini teşvik etmek için, ayrıntılı arka uç, birçok hizmet uygulamasına dayanmalı ve yeterli bilgiyi toplamalıdır. Onlar kadar az, yüzlerce kadar. Bu açıdan bakıldığında ürün detay sayfası Ali'nin güvendiği en karmaşık uygulamalardan biridir.

İnternet işinin temel özelliklerinden biri, iş yinelemesinin çok hızlı olması, her gün yeni taleplerin olması, her hafta yeni sürümlerin olması ve her yıl büyük yeniden düzenlemelerin olmasıdır.Her değişiklik bir duruma yol açabilir. Sistem kullanıcıya ne kadar yakınsa, aşağı akış hizmetlerinden o kadar fazla etkilenecektir. Öyleyse sadece merak etmiyoruz, ayrıntılar için, Alinin en karmaşık uygulaması, bazı durumlar aşağı akış olduğunda sisteme ne oluyor? İki deneyi inceleyelim:

Deney 1: Arka uç indirimleri, envanter ve lojistiğin başarısız olduğunu varsayarak, ürün ayrıntıları sayfasının performansını gözlemleyelim.

İlk bakışta bir sorun yok gibi görünüyor. Sadece sayfanın yenilendiğini hissediyorum. Belki de şiddet içeren bilgi çağında, böylesine taze ve zarif bir sayfaya bakarken, hala biraz karanlık ve soğukkanlı.

Herkesin Deney 1'e tepkisini gözlemlemek için yerinde iki anket yapıldı. Soruşturma 1 ayrıntılar sayfasının hatalı olduğunu düşünen öğrenciler içindir, lütfen ellerini kaldırın. Sonuç olarak, olay yerinde kimse elini kaldırmadı (olay yerindeki atmosfer hala nispeten soğuk olabilir); 2. Anket, herkesten hatayı bulmasını istemektir.İki detay sayfası arasında kaç fark vardır? Bu sefer bir kız doğru cevabı verdi (aynı zamanda Electronics Industry Press tarafından Ali'nin Double 11 teknolojisinin evrimiyle ilgili yayınlanan "All in Double 11" kitabını da sundu).

Karşılaştırmasız bir zararı yoktur, toplamda 6 fark vardır. İşlevsel açıdan bakıldığında, bu kesinlikle bir hata sayfasıdır. Ancak, kullanıcı deneyimi ve iş açısından bakıldığında, bu bilgilerin eksikliği malların satın alınmasını etkilemez ve temel kullanıcı deneyimini etkilemez. Yine iyi görünüyor mu? Biraz karışık, değil mi? Bir süre uğraşıyorsun, hadi ikinci deneyi yapalım.

Deney 2: Ürün detaylarındaki "ürün" ile ilgili bir sorun olduğunda ürün detaylarına ne olacak?

Detaylar hala bu detaylar, ancak ürün detayları yanlış detaylar haline geldi. İlk sayfa: Üzgünüz, görüntülediğiniz ürün artık bulunamadı. Erişim yönteminiz yanlış olabilir. Örneğin, bazı parametreler URL'de eksik olabilir veya arka planda gerçek bir sorun olabilir, bu da kullanıcılar için nispeten nazik bir yöntemdir. İkinci sayfa: Web sitesinde bir sorun olması mümkündür. Bunun daha olası nedeni, arka ucun zaman aşımını makul bir şekilde işlememesi ve ön ucun anormal olmasına neden olmasıdır. Ama dürüst olmak gerekirse, bu sayfayı nadiren görüyorum. Olursa, temelde çok ciddi bir kazadır.

Yukarıdaki iki deney aracılığıyla, herkesin bugün tanıtacağımız "güçlü ve zayıf bağımlılık" kavramı hakkında bazı belirsiz duygulara sahip olması gerektiğine inanıyorum. Algısal bir bakış açısına göre, aşağı akış bağımlı hizmetlerle ilgili bir sorun olduğunda, mevcut sistem etkilenecektir.Kullanıcıları güçlü bir bağımlılık hissettiren şey güçlü bağımlılık ve hissetmeyen şey zayıf bağımlılıktır.

Ancak bu tanım yeterince katı değildir çünkü kullanıcı erişimi olmadığında bunun bir hata olmadığı söylenemez. Bu nedenle, onu rasyonel bir bakış açısıyla da tanımlamamız gerekiyor: birincisi, ne olması gerektiği, ikincisi, ana iş alanı ve son olarak kayıp getirip getirmediği. Temel iş süreçlerini veya sistem kullanılabilirliğini etkilemeyen bağımlılıklar zayıf bağımlılıklar olarak adlandırılabilir ve bunun tersi güçlü bağımlılıklardır.

Son olarak, güçlü ve zayıf bağımlılığın ne olduğunu net bir şekilde açıkladı, öyleyse güçlü ve zayıf bağımlılık yönetişimi yapmanın anlamı nedir? Bağımlılık modelinin dışında güçlü ve zayıf yönlere bakmak pek mantıklı değil. Sıkı bir bağımlılık modeli üç bileşen içermelidir: ilişki, akış ve güç.

Bağımlılık, bağımlılığın yönünü, kime bağlı olduğumu ve bana kimin bağlı olduğunu tanımlar. Trafik, her uygulamanın, hizmetin ve yöntemin kaç kez çağrıldığını, güç ise bağımlılığın sıkılığının derecesini tanımlar. Yönetişime güvenmek, bilimsel yollarla ilişkiler, akışlar ve güçlü yönler hakkında sürekli ve istikrarlı bir şekilde veri elde etmektir. Güçlü ve zayıf bağımlılıklar esas olarak aşağıdaki senaryolara uygulanabilir:

Sistem dönüşümü ve kabulü: Dağıtılmış sistemler için, en azından mevcut uygulamanın, işlemin kilitlenmesi, sık FullGC, yüksek yük gibi, çalışma durumunda güvendiğim sistemin arızalanması nedeniyle, ne zaman ve ne zaman kullanılabilirlik sorunlarına yol açmaması sağlanmalıdır. Zemin, kanamayı hızla durdurma özelliğine sahiptir.
Mevcut sınır ve sürüm düşürme referansı: Zayıf bağımlılıklar için genel olarak mevcut sınır veya otomatik sürüm düşürme stratejileri yapılandırılır.Beyin fırtınası veya deneysel değerler aracılığıyla ayarlamaya kıyasla, aşağı akış için zaman aşımı gibi gerçek başarısızlık testlerinde ince ayar yapmak daha iyidir Bu durumda, iş parçacığı havuzu akım sınırına bağlı olarak kaç değerin doldurulması gerektiğini deneylerden geçebiliriz.
Uygulama başlatma sırası: İdeal olarak, uygulama başlangıcı sıfıra bağımlı başlatma olmalıdır. Ancak yapılamayacağı bazı durumlar vardır. Bu nedenle, bağımlı uygulama başlatma sırası da gerçek zamanlı dikkat gerektirir. Özellikle yeni bir IDC ve bir bilgisayar odası oluştururken, örümcek ağı benzeri bağımlılıklar en iyi sistem aracılığıyla elde edilir.
Başarısızlığın temel nedeninin yeri: Arka plan sisteminin arızası genellikle üst katmanın iş başarısızlığı ile kendini gösterir. Arıza işleme, bir saniyeden fazla rekabet etme ihtiyacını vurgular ve güç ve zayıflığa iyi bir bağımlılık, sistem otomasyonu teşhisi için çok yararlıdır.
Bağımlı kapasite değerlendirmesi: Normal çağrı bağlantısı altındaki sistem kapasitesinin değerlendirilmesi gerekir.Zayıf bir bağımlılık kapandığında, genel kapasitenin değişip değişmediği.

Arka plan hakkında konuştuktan sonra, nihayet güçlü ve zayıf bağımlılığın teknik uygulamasından bahsedebilirim. Alibaba'da, güçlü ve zayıf bağımlılığın teknolojik evrimi bir bütün olarak üç aşamaya ayrılmıştır ve her aşamada çözümün doğuşunun kendine özgü geçmişi ve iş zorlukları vardır. Şimdi geriye dönüp baktığımızda, o zaman teknolojinin sınırlamalarını ve atılımlarını da görebiliriz.

Taobao'nun teknoloji geliştirme tarihine aşina olan öğrenciler, 2008'de Ali'nin büyük bir taş sisteminden bir hizmet sistemine dönüşümü tamamlayan Caishi kod adlı bir projeyi tamamladığını biliyor. İş ve geliştirme modellerinde büyük gelişmeler oldu, ancak ağ bağımlılığı da birçok sorunu beraberinde getirdi. Bu çağın temel özellikleri şunlardır: sık karşılaşılan başarısızlıklar, teknik fikirler ve yöntemler sonuç odaklıdır, biraz daha pürüzlüdür, sonuçların doğruluğu neredeyse tolere edilebilir.

Bağımlı hataları simüle etmek için üç teknik vardır: kod değiştirme + serbest bırakma, uzaktan Hata Ayıklama + yeniden başlatma ve bazı kabuk komut işlemlerini gerçekleştirmek için makinede oturum açma. Avantajı, esnek olması ve belirli bir etki derecesine ulaşabilmesidir; dezavantajı, maliyetin yüksek olması ve ortamın istikrarını etkilemesidir.Test yaptığınızda, diğer insanlar çalışamaz durumdadır ve bu da verimliliği etkiler. Ek olarak, bu aşamada, dağıtılmış bağlantı izleme teknolojisi henüz başlamadığından, bağımlılık hatalarını simüle ederken bazı ana bilgisayarlar veya bazı hizmetler genellikle gözden kaçar. Hatanın tanecikliği nispeten kabadır.Bazı Linux komutları için, hepsi ana bilgisayar seviyesindedir.

Ali, esas olarak çevrimiçi olmadan önce entegrasyon testleri için bir dizi günlük ortama sahiptir. Çevre üzerindeki etkiyi en aza indirmek için. Hizmet sürümünü değiştirerek bağımsız bir test ortamı oluşturuyoruz. 2011'in ikinci yarısında, ilk sürümü yapmaya başladığımda, Taobao'nun 12 çekirdek uygulamasının günlük ortamını oluşturduğumu hatırlıyorum. Sayısız çukur ve saf fiziksel çalışma vardı. Eşi benzeri görülmemişti ve gelecek yoktu.

Bu ortamdan birkaç kez geçtim ve sonuçları çekirdek iş TL'ye gönderdim. Herkes çok heyecanlandı ve yönetmenin bir yolunu bulmuş gibi görünüyordu. Bununla birlikte, çevresel operasyon ve bakım ilişkilendirme sorunları, geliştirme makinelerinde parazit sorunları, iş anlayışı ve test ayrıntı sorunları gibi yeni sorunlar hızla ortaya çıktı, bu nedenle uzun süre test etme kapsamı temel işlem bağlantısı ile sınırlıydı.

İkinci aşamanın özü, birinci aşamanın sıkıntılı noktalarından başlayarak, insan maliyeti ve çevre sorunlarını çözmek için verimliliği artırmaktır. Bu aşamadan sonra temelde manuel yöntemlerden kurtulabilirsiniz ve verimlilik büyük ölçüde iyileştirilir.

Bu aşama aynı zamanda Selenium'un daha yaygın olarak kullanıldığı, kullanıcı davranışlarının önceden kaydedilip test komut dosyalarına dönüştürülebildiği ve her adımın sorun incelemesini kolaylaştırmak için ekran görüntüleriyle kaydedilebildiği bazı test tekniklerini de tanıtır.

Bu süreçte Alibaba'nın ara katman teknolojisi bir ölçüde gelişti ve kullanıcı erişim zincirlerini seri bağlayabilen dağıtılmış izleme teknolojisi ortaya çıktı ve sorun giderme etkinliği bir ölçüde artırıldı. Aynı zamanda, Nginx, mesajlaşma, dağıtılmış hizmet çağırma, dağıtılmış veritabanı, yumuşak yük ve yapılandırma merkezi gibi tüm ara yazılımlar, kullanıcı trafik işaretleme, izleme ve yönlendirme kontrolünü desteklemek için dönüştürüldü. Yukarıda bahsedilen teknolojik ilerlemeye dayanarak, çevre konularında çok büyük atılımlar olacaktır.

Dahili olarak biz buna ikinci ortam diyoruz. Temel ilkesi, belirli bir işletmenin alt kümesi olan temel ortama dayalı olarak bazı küçük ortamları dinamik olarak ayırt etmektir. Projeler birbirinden bağımsızdır ve birbirini aramayacaktır, sadece bağımlı hizmetler mevcut olmadığında temel ortamın hizmetlerine erişeceklerdir. Veritabanı ve önbellek paylaşılır.

Bu aşamada artık kodun servis versiyonunu değiştirmemiz gerekmiyor.Her sürümden sonra, kodun versiyonu otomatik olarak tutarlı tutulabilir, işletim ve bakım maliyeti düşürüldü, wild servislerin müdahalesi de hafifletildi ve insan müdahalesi çok önemli. az. Ancak yine de çözülmesi gereken bazı sorunlar var:

Birincisi, ikinci ortamın yönlendirme stratejisi kullanıcıya bağlıdır, bu da bazı yapılandırmaların önceden yapılması gerektiği anlamına gelir; ikincisi, alan adında ikinci gibi öneklerle bazı kısıtlamalar ve test yolundaki URL'ler gibi düşük yeniden kullanım oranı sorunu vardır. Tam olarak çözülmedi; üçüncü olarak, testin tanecikliği hala çok kaba, makine özel olarak kullanılıyor ve büyük ölçekte tanıtıldığında makinenin maliyeti ve kullanım durumu operasyonunun maliyeti hala yüksek; dördüncüsü, başarısızlık senaryosu eksik ve yalnızca temel ortamda var olan hizmetler simüle edilemez Hatalar, örneğin: veritabanı hatası, önbellek hatası vb.

2014 yılında düşünce tarzımız büyük bir atılım yaptı. Artık çevrenin ve dış araçların iyileştirilmesi ile meşgul değiliz, güçlü ve zayıf bağımlılığın temel kısmına geri dönüyoruz. Bu, iş etkisi ve sistem tasarımıdır. Yalnızca kod tasarımı ve işle ilgili olan ve dış çevre ile ilgisi olmayan bir çözümü gerçekleştirmek mümkün mü?

Bu dönemde iki temel fikir veya çıkarım var:

Sonuç 1: İstediğimiz şey aşağı akış bağımlılığının başarısızlığıdır, aşağı akış hizmet sağlayıcısının başarısızlığı değil. Tüketici, aşağı havzanın arızalı olduğunu hissettiği sürece. Bu perspektiften, ürün ayrıntıları güçlü ve zayıf bağımlılıklar için test edilecekse, kendiniz oynadığınız sürece düzinelerce aşağı akış uygulamasını fırlatmanıza gerek yoktur.
Sonuç 2: Ayrı bir ortam inşa etmemizin nedeni, arızanın kapsamını kontrol etmektir. Daha sonra düşüncemizi değiştirebiliriz, yani sadece başarısız olmak üzere olan istekleri etkileriz ve diğer iş trafiği bırakılır. Hedefe ulaşabilir mi? Esasen iş trafiği için bir tarama kabiliyetidir.

Yukarıdaki fikirlerle, ilk soru, kullanıcı isteklerine nasıl müdahale edileceğidir? Kullanıcı isteklerini yakalamak ve kullanıcı dönüşümünün maliyetini en aza indirmek, hiçbir şey ara yazılımdan daha uygun değildir. Her evrensel uzaktan arama arabirimi, yaygara yapmak için bir noktadır ve ara katman yazılımındaki iş sisteminin değiştirilmesine gerek yoktur.

Bir sonraki sorun, başarısızlık kuralları ve iş kimliğidir. Kullanıcı isteklerinin girişini işaretlemeyi ve başarısızlık kuralları eklemeyi düşündük. Ancak, gönderi isteklerinin, eşzamansız js isteklerinin, zamanlanmış görevlerin vb. Nispeten büyük dönüşüm maliyetlerine sahip olduğunu gördük ve Güvenlik riskleri. Bu nedenle, bağımlı eklentilere doğrudan hata kuralları yayınlamak için bir sunucu eklenir.

Arıza eklentisi, trafik + iş tanımlamasının arama durdurulması yoluyla hangi talebin etkilendiğini benzersiz bir şekilde belirler ve ardından bir arızayı simüle etme etkisini elde etmek için arıza kuralı aracılığıyla bir istisna veya zaman aşımı enjekte edip etmeyeceğine karar verir. Eklentinin genişletilebilir tasarımı nedeniyle, varsayılan olarak birden fazla hata senaryosunu aynı anda enjekte edebiliriz ve eklenti ayrıca, isteği etkileyen ayrıntılı bilgileri analiz için sunucuya eşzamansız olarak rapor eder.

Teorik olarak, yukarıda bahsedilen şema aracılığıyla, iş akışı girdisi açısından hiçbir gereksinimimiz yok. İnsanların spontan test davranışları veya makinelerin test davranışları konusunda herhangi bir kısıtlama yoktur. Yalnızca mevcut test senaryosu birikiminin yeniden kullanımını en üst düzeye çıkarmak ve otomasyon derecesini artırmak için, güçlü ve zayıf bağımlı sunucularla iletişimi kapsayacak şekilde bir dizi kullanım durumu ek açıklaması tasarladık. Arıza kurallarının yayınlanması ve kaldırılmasını tamamlamak için Junit'in yaşam döngüsünün özelliklerini kullanın.

Herhangi bir test durumu, 20 saniye içinde güçlü ve zayıf bir bağımlı test senaryosuna dönüştürülebilir. Sonuç çıktısı açısından, güçlü ve zayıf bir bağımlılık algılama sürecini ve test senaryosunda yer alan bağlantıların bağımlılık değişikliklerini ayrıntılı olarak gösterecektir. Bu aşamada, güçlü ve zayıf bağımlılık gerçekten görece bir kilometre taşı versiyonuna ulaştı. 2014'ten başlayarak, güçlü ve zayıf bağımlılık da Double 11 sırasında yapılması gereken yatay bir proje haline geldi.

Aşağıdakiler, güçlü ve zayıf bağımlılık ek açıklamaları ve bağımlılık sistemleri örnekleridir:

Genel olarak, teknolojik evrime dayanan güçlü ve zayıf yönlerin tüm tarihi, aralıksız veri doğruluğu, istikrar, maliyet ve verimlilik arayışı ve bunlar arasında dinamik bir denge sağlamaktır.

Arıza tatbikatları için temel ilkeler ve en iyi sistem tasarımı uygulamaları

Hepimizin bildiği gibi 2017 barışçıl değildi ve sektörde birçok büyük başarısızlık yaşandı.

1 Mart 2017'de, Virginia'daki veri merkezi arızalandı ve Amazon S3 hizmeti, binlerce çevrimiçi hizmeti doğrudan etkileyen yüksek bir hata oranına sahipti; 31 Ocak 2017'de, GibLab öğrencilerinin çevrimiçi veritabanı değiştiğinde , Ani bir durumla karşılaştı. Operasyonel hatalar nedeniyle, tüm üretim veri tabanı yanlışlıkla silindi ve 6 saatlik veri kaybedildi;

Şubat 2017'de, ağ bağlantısını test etmek için sıklıkla kullanılan yerli bir arkadaş şirketi de başarısız oldu.Sanayi ve Bilgi Teknolojileri Bakanlığı hızla ilgilendi ve ilgili şirketlerle acilen görüştü. Aynı zamanda, BAT gibi önemli İnternet şirketlerinin dersten ders çıkarmasını zorunlu kılmak için bir acil durum bildirimi yayınlandı ve sektör bir kargaşa içindeydi.

Şu anda, bir şirket özellikle sakin görünüyordu ve bu Netflix'ti. Netflix, küresel bir çevrimiçi film kiralama sağlayıcısıdır ve temel işi tamamen AWS'ye dayanmaktadır. Haberlere göre, Netflix, Amazon başarısız olduğunda, "arızaya dayanıklı" bir altyapıya sahip oldukları için hızla normale dönebilir. İhtiyacımız olan bir şeye benziyor.

Daha fazla araştırmadan sonra, arızaya dayanıklı altyapının arkasında bir maymun ordusu olduğu keşfedildi.

2012 gibi erken bir tarihte, Netflix Chaos Monkey'i piyasaya sürdü. Örnekleri rastgele öldürmek için kullanılır.Resmi verilere göre şimdiye kadar 65.000 düğüm öldürüldü. Test stratejileri de daha ilgi çekicidir: çalışma saatleri boyunca üretim ve test ortamlarında çalıştırın, test sisteminin sağlamlığını hedefleyin, yedek personeli eğitin ve kurtarmayı daha kısa, hızlı ve otomatik hale getirin; Latency Monkey'in işlevi bir makine talebinde bulunmak veya Daha yavaş geri dönün, sistemin performansını gözlemleyin; Chaos Gorilla'nın yeteneği bir bilgisayar odası, iş felaket toleransının makro doğrulaması ve kurtarma yetenekleridir. Netflix'in Monkey Corps'u piyasaya sürmesinin nedeni, uzun zaman önce bulut arızalarından muzdarip olmalarıdır, bu nedenle içgüdü, bulut tesislerinin güvenilmez olması ve yazılım düzeyinde felaket toleransını doğrulamak için delinmeleri gerektiğidir.

Eski bir filozof bir zamanlar "hiç kimse aynı nehre iki kez adım atmadı" demişti, çünkü ne bu nehir ne de bu insan farklıdır. Başarısızlıklar benzerdir: Arızanın zamanı ve yeri ve akış hızı üzerindeki etkisi, başarısızlıkla uğraşan insanlarla tam olarak aynı olamaz. Bu açıdan bakıldığında, hata yönetiminin kendisi yanlış bir önermedir ve geçmişte belirli bir zamanda bir sorunu çözmektedir.

Bununla birlikte, programcının bakış açısından (buna Tanrı'nın bakış açısından demeye alışkınım), herhangi bir başarısızlığın nedeni tespit edilebilir.Aynı nedenin neden olduğu tekrarlanan başarısızlıklardan kaçınmak, her programcının izlemesi gereken hedeftir. E-ticaret tarihte pek çok tipik başarısızlıkla karşılaştı. Başarısızlıkların tekrarlanmasını önlemek için Alibaba bir dizi "arızaya dayanıklı" altyapı da oluşturdu.

27 Mayıs 2015'te, fiber optik kesinti sorunu ve Alipay'in büyük ölçekli bir kesinti süresi nedeniyle şirket bir sonuca vardı: herhangi bir altyapı, üretim sistemi ve herhangi bir süreçte sorunlar olabilir ve büyük felaketler tarafından doğrulanmış bir felaket kurtarma tesisi yoktur. Hepsi holigan. Farklı yerlerde yaşam kalitesini doğrulamak için kod adı Huhuhu olan bir üretim baskını projesi başlatıldı.

2012 yılında, işlemin şehir içi canlı aksiyonunun tamamlanmasının ardından, ağ bağlantısı kesme tatbikatı olarak da adlandırılan şehir içi felaket kurtarma tatbikatı başlatıldı. Aynı şehirdeki bir bilgisayar odası kapatıldığında çekirdek sistemin hala normal şekilde çalıştığını doğrulayın.

2011 yılında, bağımlılıkların neden olduğu sistem arızalarını önceden keşfetmeyi umarak güçlü ve zayıf bağımlılıkları yönetmeye ve inşa etmeye başladık.Sistemin kod adı EOS (kaynak eski Yunan mitolojisinde şafak tanrıçasıdır ve anlambilim kaotik bağımlılıkları çözebilir. ).

Bu üç parçanın ve Netflix'in Maymun Birliğinin temelde işlevsel olarak kıyaslandığı görülebilir. Hatasız ve endişesiz olması gerekmez mi? Cevap kesinlikle hayır.

İdeal doludur, gerçeklik çok zayıftır. Çeşitlendirilmiş iş senaryoları ve giderek karmaşıklaşan teknik mimarisi nedeniyle, Alibaba çeşitli hatalarla karşılaşacaktır.Akışlı ortam hizmetlerinin hata yönetimi ile karşılaştırıldığında, hata yönetiminin zorluğu da birkaç adımda artmaktadır.

Daha önce tanıtılan güçlü ve zayıf bağımlılık ve felaket kurtarma çalışmaları, başarısızlıkların yalnızca bir kısmını kapsayabilir. Genel arızanın bir ön resmini yaparsanız, genel arıza IaaS katmanına, PaaS katmanına ve SaaS katmanına bölünebilir.Her katmanın birçok hata tetikleyici nedeni ve belirtisi olabilir. Bu yüzden pek çok tür karmaşık hata için kalp sersemletilmelidir. Onu nasıl yeniden üretiriz ve bu kadar çok karmaşık başarısızlıktan nasıl kaçınırız?

Üç cisim sistemine aşina olan öğrenciler "boyutsallığı azaltma saldırısı" terimini duymuş olmalılar. Boyutluluğu küçültelim ve hataya başka bir açıdan bakalım:

Herhangi bir arıza, IaaS katmanı gibi bir donanım ve PaaS veya SaaS gibi bir yazılım arızası olmalıdır. Ve donanım arızaları olgusunun yazılım arızaları olgusuna yansıtılması gerektiği gibi bir kural var.
Arıza tek bir makineye veya dağıtılmış sistemlerden birine ait olmalıdır Dağıtılmış arızalar tek makine arızalarını içerir.
Tek bir makinenin veya aynı modelin arızalanması için, sistem perspektifinden, arıza mevcut süreçte bir arıza olabilir, örneğin: FullGC, CPU'nun yükselmesi; diğer işlemlerin aniden belleği ele geçirmesi, mevcut sistemin anormal olmasına neden olması gibi işlem dışı arıza. .
Aynı zamanda, insan hatası veya yanlış süreçten kaynaklanabilecek bir tür başarısızlık olabilir, bugün bu bölüme odaklanmayacağız.

Bu başarısızlık modeline herhangi bir arıza dahil edilebilir. Bu modelle, arızaları simüle eden bir matkap sistemi tasarlamaya başlayabiliriz.

Bu yüzden dahili olarak, kod adı "Büyük Bilge'nin Dönüşü" adlı bir proje başlattık, proje adı "arıza tatbikatı" ve taşınan ürün MonkeyKing. MonkeyKing, Çin Maymun Kralı anlamına gelir. Monkey King'in yüksek güç becerilerine (Ateş Gözü Güzel Altın, Yetmiş İki Değişiklik) ve son derece asi ruhuna değer verir ve istikrarı sağlamak için yenilikçi bir fikir kullanmayı umar.

Sistem uygulamamız da yukarıda tartışılan hata modeli etrafında tasarlanmıştır:

İşletim sistemi katmanı hatası eklentisi, donanım katmanı hatalarını ve tek makinedeki işlem dışı hataları simüle etmek için istemci makineye yerleştirilir.
Uygulama sürecindeki hatalar için, bir eklenti hatası eklentisi sağlanır veya kullanıcılar hata API'mize göre kendi uygulamalarını yapabilir.
Dağıtılmış hatalar için, hatanın kapsamı IP'ye göre sunucu tarafından kontrol edilir.
Veritabanları gibi çeşitli nedenlerle ulaşılamayan bazı uygulamalar için. Hata servis erişimi için hatalı üçlü uygulama standardı sağlıyoruz.

Yukarıdaki yöntemle, teknik arıza modeli temelde kapsanmaktadır.

Geçen yılki Double 11'de, arıza tatbikatlarının uygulama senaryoları esas olarak şekildeki birkaç senaryoya uygulandı. İş akışı ve basınç ölçüm akışının tepe değerine göre 4 bölüme ayrılabilir. Özel durumlar aşağıdaki gibidir:

Planın geçerliliği: Önceki plan testinde çevrimiçi olarak herhangi bir sorun yoktu, bu nedenle test sonuçları beklentileri karşılasa bile, kazalar olabilir ancak olay gizlidir.
İzleme alarmı: alarmın mevcut olup olmadığı, uyarı mesajının doğru olup olmadığı, alarmın 5 dakika mı yoksa yarım saat mi etkili olduğu, alarmı alan kişinin aktarılıp aktarılmadığı, cep telefonunun gecikmiş olup olmadığı vb. Kontrol edilebilecek noktalardır.
Arıza tekrarı: Arızanın takip eyleminin gerçekten etkili olup olmadığı ve tamamlanma kalitesi yalnızca kapalı döngüyü tamamlamak için yeniden üretilebilir ve doğrulanabilir. Bir bozulma eğilimi olup olmadığını görmek için, meydana gelen arızalar da zaman zaman uygulama için çıkarılmalıdır.
Mimari afet tolerans testi: afet toleransı için var olan yöntemlerin zamanındalığı ve etkileri, örneğin aktif-yedek anahtarlama, yük dengeleme ve trafik zamanlaması ve afet toleransı yöntemlerinin kendilerinin ne kadar sağlam olduğu.
Parametre ayarı: akım sınırlama stratejisi ayarı, alarm eşiği, zaman aşımı değeri ayarı vb.
Hata modeli eğitimi: Hedeflenen bir şekilde bazı hatalar oluşturun ve hata konumu için sistem için veri oluşturun.
Hata baskınları ve ortak tatbikatlar: Ekibi Mavi Ordu ve Kızıl Ordu aracılığıyla eğitin, birlikleri savaş yoluyla toplayın ve DevOps yeteneklerini iyileştirin.

Arıza tatbikatı beyanı: Hataları senaryoya dayalı bir şekilde çökeltin, hataları kontrol edilebilir bir maliyetle çevrimiçi olarak simüle edin, böylece sistemler ve mühendisler barış zamanında daha pratik fırsatlara sahip olur ve sistemlerin, araçların, süreçlerin ve personelin ilerlemesini hızlandırın.

Gelecek hakkında:

Arıza tatbikatının takip çalışması esas olarak şu yönlere odaklanacaktır: tatbikatın normalizasyonu, arızanın standardizasyonu ve tatbikatın zekası. Büyük terfiden önce iyileştirici eğitim yerine kararlılığı ve ilerlemeyi sağlamak için normalleştirilmiş matkapları kullanın; daha fazla arıza senaryosu zenginleştirin, minimum arıza senaryolarını ve işleme yöntemlerini tanımlayın; mimari ve iş analizine dayalı akıllı matkaplar, endüstri arızası tatbikat çözümlerini hızlandırın .

QCon Beijing 2017 Küresel Yazılım Konferansı'nda yapılan paylaşım, Ali'nin arıza önlemenin teknik ayrıntılarını ilk kez ortaya koyuyor.Herkesin iletişimi ve değişimine hoş geldiniz. Yüksek kullanılabilirlik alanları oluşturmakla ilgileniyorsanız veya bulut ürün geliştirme konusunda deneyiminiz varsa ve kapsayıcı teknoloji yapma ve ticari değer yaratma hırsınız varsa, lütfen zhongting.zy@taobao.com adresine e-posta gönderin.

yazar hakkında

Zhou Yang, Huaming Zhongting, Alibaba teknik uzmanı. 2011 yılında Alibaba ara katman yazılımına ve yüksek kullanılabilirlikli mimari ekibine katıldı. Kararlı ürünlerin ve mimari yükseltmenin araştırma ve geliştirilmesinde görev aldı. İnşaat, Ali'nin yüksek kullanılabilirlikli ürün sisteminin 1.0'dan 3.0'a kadar geliştirme sürecine tanık oldu ve mimari ve istikrar konusunda zengin deneyim biriktirdi. 2015 yılında, paylaşılan işletme departmanının büyük promosyon başbakanı olarak, büyük bir terfi ve normal istikrar garantisinden sorumluydu.

Bugünün Tavsiyesi

Okumak için aşağıdaki resme tıklayın