HighLoad++, Evgeniy Kuzovlev (EcommPay IT): Bir dakikalık kesintinin maliyeti 100000 ABD doları olduğunda ne yapılmalı?

Herkes geliştirme ve test süreçlerinden, personelin eğitilmesinden, motivasyonun arttırılmasından bahsediyor ancak bir dakikalık hizmet kesintisi çok büyük paralara mal olduğunda bu süreçler yeterli olmuyor. Katı bir SLA kapsamında finansal işlemler gerçekleştirdiğinizde ne yapmalısınız? Geliştirme ve testleri denklemden çıkararak sistemlerinizin güvenilirliğini ve hata toleransını nasıl artırabilirsiniz?

Bir sonraki HighLoad++ konferansı 6 ve 7 Nisan 2020'de St. Petersburg'da gerçekleştirilecek. Detaylar ve biletler bağlantı. 9 Kasım 18:00. HighLoad++ Moskova 2018, Delhi + Kalküta salonu. Tezler ve tanıtım.

Evgeniy Kuzovlev (bundan böyle – AT): - Arkadaşlar, merhaba! Adım Kuzovlev Evgeniy. EcommPay şirketindenim, özel bir bölüm, şirketler grubunun BT bölümü olan EcommPay IT'dir. Ve bugün kesinti sürelerinden, bunlardan nasıl kaçınılacağından, önlenemiyorsa sonuçlarının nasıl en aza indirileceğinden bahsedeceğiz. Konu şu şekilde ifade ediliyor: “Bir dakikalık kesintinin maliyeti 100$ olduğunda ne yapılmalı?” Geleceğe baktığımızda rakamlarımız birbirine yakın.

EcommPay BT ne yapar?

Biz Kimiz? Neden burada önünüzde duruyorum? Neden sana burada bir şey söyleme hakkım var? Peki burada daha detaylı olarak nelerden bahsedeceğiz?

EcommPay şirketler grubu uluslararası bir satın alma kuruluşudur. Ödemeleri dünyanın her yerinde işliyoruz - Rusya, Avrupa, Güneydoğu Asya'da (Dünyanın Her Yerinde). 9 ofisimiz var, toplamda 500 çalışanımız var ve bunların yaklaşık yarısından biraz azı bilişim uzmanı. Yaptığımız her şeyi, para kazandığımız her şeyi kendimiz yaptık.

Tüm ürünlerimizi kendimiz yazdık (ve bunlardan oldukça fazla sayıda var - büyük BT ürünleri serimizde yaklaşık 16 farklı bileşen var) kendimiz yazdık; Kendimiz yazıyoruz, kendimizi geliştiriyoruz. Ve şu anda günde yaklaşık bir milyon işlem gerçekleştiriyoruz (milyonlarca demek muhtemelen doğru yoldur). Oldukça genç bir şirketiz; yalnızca altı yaşındayız.

6 yıl önce adamlar işe geldiğinde böyle bir girişimdi. Bir fikir etrafında birleştiler (fikirden başka bir şey yoktu) ve biz kaçtık. Her startup gibi biz de daha hızlı koştuk... Bizim için hız, kaliteden daha önemliydi.

Bir noktada durduk; artık bir şekilde o hızda ve o kalitede yaşayamayacağımızı ve önce kaliteye odaklanmamız gerektiğini anladık. Şu anda doğru, ölçeklenebilir ve güvenilir yeni bir platform yazmaya karar verdik. Bu platformu yazmaya başladılar (yatırım yapmaya, geliştirmeye, test etmeye başladılar), ancak bir noktada geliştirme ve test etmenin yeni bir hizmet kalitesi seviyesine ulaşmamıza izin vermediğini fark ettiler.

Yeni bir ürün yapıyorsunuz, üretime koyuyorsunuz ama yine de bir yerlerde bir şeyler ters gidecek. Ve bugün yeni bir kalite seviyesine nasıl ulaşacağımızı (bunu nasıl başardık, tecrübelerimiz hakkında), geliştirme ve test etmeyi denklemden çıkaracağız; operasyon için nelerin mevcut olduğu, operasyonun kendi başına neler yapabileceği, kaliteyi etkilemek için teste neler sunabileceği hakkında konuşacağız.

Arıza süreleri. Operasyon emirleri.

Her zaman ana temel taşı, bugün aslında konuşacağımız şey kesintidir. Korkunç bir kelime. Eğer kesintimiz varsa, bizim için her şey kötüdür. Yükseltmek için koşuyoruz, yöneticiler sunucuyu tutuyor - Tanrı korusun, o şarkıda dedikleri gibi düşmesin. Bugün bunun hakkında konuşacağız.

Yaklaşımlarımızı değiştirmeye başladığımızda 4 emir oluşturduk. Bunları slaytlarda sundum:

Bu emirler oldukça basittir:

• Sorunu hızlı bir şekilde tanımlayın.
• Ondan daha da hızlı kurtulun.
• Nedeninin anlaşılmasına yardımcı olun (daha sonra geliştiriciler için).
• Ve yaklaşımları standartlaştırın.

2. noktaya dikkatinizi çekmek isterim. Biz sorunu çözmüyor, ortadan kaldırıyoruz. Karar vermek ikinci plandadır. Bizim için öncelikli olan kullanıcının bu sorundan korunmasıdır. İzole edilmiş bir ortamda var olacak ama bu ortamın onunla hiçbir teması olmayacak. Aslında bu dört sorun grubunu ele alacağız (bazıları daha ayrıntılı, bazıları daha az ayrıntılı), size ne kullandığımızı, çözümlerde ne gibi deneyimlere sahip olduğumuzu anlatacağım.

Sorun Giderme: Ne zaman oluyorlar ve bu konuda ne yapmalı?

Ama sıra dışı başlayacağız, 2 numaralı noktayla başlayacağız - problemden nasıl hızlı bir şekilde kurtulabiliriz? Bir sorun var; bunu düzeltmemiz gerekiyor. “Bu konuda ne yapmalıyız?” - asıl soru. Sorunu nasıl çözeceğimizi düşünmeye başladığımızda kendimiz için sorun gidermenin uyması gereken bazı gereksinimler geliştirdik.

Bu gereksinimleri formüle etmek için kendimize şu soruyu sormaya karar verdik: "Ne zaman sorun yaşarız?" Ve ortaya çıktığı gibi sorunlar dört durumda ortaya çıkıyor:

• Donanım arızası.
• Dış hizmetler başarısız oldu.
• Yazılım sürümünün değiştirilmesi (aynı dağıtım).
• Patlayıcı yük artışı.

İlk ikisinden bahsetmeyeceğiz. Bir donanım arızası oldukça basit bir şekilde çözülebilir: her şeyin kopyasını almanız gerekir. Bunlar disk ise disklerin RAID’de birleştirilmesi gerekir; bu bir sunucu ise sunucunun kopyalanması gerekir; ağ altyapınız varsa ağ altyapısının ikinci bir kopyasını temin etmeniz yani onu almanız ve çoğaltın. Ve eğer bir şeyler başarısız olursa yedek güç moduna geçersiniz. Burada daha fazla bir şey söylemek zor.

İkincisi ise dış hizmetlerin başarısızlığıdır. Çoğu kişi için sistem hiç sorun değil ama bizim için öyle değil. Ödemeleri işlediğimiz için, (kart verilerini giren) kullanıcı ile bankalar, ödeme sistemleri (Visa, MasterCard, Mira vb.) arasında duran bir toplayıcıyız. Dış hizmetlerimiz (ödeme sistemleri, bankalar) başarısız olma eğilimindedir. Ne biz ne de siz (bu tür hizmetleriniz varsa) bunu etkileyemeyiz.

O zaman ne yapmalı? Burada iki seçenek var. Öncelikle imkanınız varsa bu hizmeti bir şekilde çoğaltmalısınız. Örneğin, eğer yapabiliyorsak, trafiği bir hizmetten diğerine aktarıyoruz: örneğin, kartlar Sberbank aracılığıyla işlendi, Sberbank sorunlar yaşıyor - trafiği [şartlı olarak] Raiffeisen'e aktarıyoruz. Yapabileceğimiz ikinci şey, dış servislerin arızasını çok çabuk fark etmektir ve bu nedenle raporun bir sonraki bölümünde yanıt hızından bahsedeceğiz.

Aslında bu dördünden, özellikle yazılım sürümlerinin değişimini etkileyebiliriz; dağıtımlar bağlamında ve yükteki patlayıcı büyüme bağlamında durumun iyileşmesine yol açacak eylemler gerçekleştirebiliriz. Aslında biz de öyle yaptık. Yine küçük bir not...

Bu dört sorundan birçoğu, eğer bir bulutunuz varsa, hemen çözülür. Microsoft Azhur, Ozone bulutlarındaysanız veya bulutlarımızı Yandex veya Mail'den kullanıyorsanız, en azından bir donanım arızası onların sorunu haline gelir ve bir donanım arızası bağlamında sizin için her şey hemen yoluna girer.

Biz biraz alışılmışın dışında bir şirketiz. Burada herkes "Kubernet'lerden", bulutlardan bahsediyor - ne "Kubernet'lerimiz" ne de bulutlarımız var. Ancak birçok veri merkezinde raflar dolusu donanımımız var ve bu donanımla yaşamaya zorlanıyoruz, her şeyin sorumluluğunu üstlenmek zorunda kalıyoruz. Dolayısıyla bu bağlamda konuşacağız. Yani sorunlar hakkında. İlk ikisi parantezlerden çıkarıldı.

Yazılım versiyonunun değiştirilmesi. Üsler

Geliştiricilerimizin üretime erişimi yok. Nedenmiş? Sadece PCI DSS sertifikalıyız ve geliştiricilerimizin "ürüne" girme hakkı yok. İşte bu, nokta. Kesinlikle. Bu nedenle, geliştirme sorumluluğu tam olarak geliştirmenin yapıyı yayınlanmak üzere gönderdiği anda sona erer.

Bize çok yardımcı olan ikinci temelimiz ise benzersiz, belgelenmemiş bilginin bulunmamasıdır. Umarım sizin için de aynısı olur. Çünkü eğer durum böyle değilse sorun yaşarsınız. Bu benzersiz, belgelenmemiş bilgi, doğru zamanda, doğru yerde bulunmadığında sorunlar ortaya çıkacaktır. Diyelim ki belirli bir bileşenin nasıl konuşlandırılacağını bilen bir kişi var - o kişi orada değil, tatilde ya da hasta - işte bu, sorunlarınız var.

Ve geldiğimiz üçüncü temel. Acıyla, kanla, gözyaşlarıyla bu noktaya geldik; yapılarımızdan herhangi birinin hatasız olsa bile hatalar içerdiği sonucuna vardık. Buna kendimiz karar verdik: Bir şeyi dağıttığımızda, bir şeyi üretime aldığımızda hatalı bir yapıya sahip oluyoruz. Sistemimizin karşılaması gereken gereksinimleri oluşturduk.

Yazılım sürümünü değiştirme gereksinimleri

Üç gereksinim vardır:

• Dağıtımı hızlı bir şekilde geri almamız gerekiyor.
• Başarısız bir dağıtımın etkisini en aza indirmeliyiz.
• Ve paralel olarak hızla konuşlandırabilmeliyiz.
  Tam olarak bu sırayla! Neden? Çünkü her şeyden önce yeni bir sürümü dağıtırken hız önemli değil, ancak bir şeyler ters giderse hızlı bir şekilde geri dönüp minimum etki elde etmek sizin için önemlidir. Ancak üretimde bir hata olduğu ortaya çıkan bir dizi sürümünüz varsa (birdenbire dağıtım olmadı, ancak bir hata var) - sonraki dağıtımın hızı sizin için önemlidir. Bu talepleri karşılamak için ne yaptık? Aşağıdaki metodolojiye başvurduk:

  
  
  Oldukça iyi biliniyor, onu hiçbir zaman icat etmedik - bu Mavi/Yeşil konuşlandırmadır. Ne olduğunu? Uygulamalarınızın kurulu olduğu her sunucu grubu için bir kopyaya sahip olmanız gerekir. Kopya "sıcak": üzerinde trafik yok, ancak her an bu trafik bu kopyaya gönderilebilir. Bu kopya önceki sürümü içerir. Dağıtım sırasında kodu etkin olmayan bir kopyaya dağıtırsınız. Daha sonra trafiğin bir kısmını (veya tamamını) yeni sürüme geçirirsiniz. Bu nedenle, trafik akışını eski versiyondan yenisine değiştirmek için yalnızca bir işlem yapmanız gerekir: yukarı akıştaki dengeleyiciyi değiştirmeniz, yönü bir yukarı akıştan diğerine değiştirmeniz gerekir. Bu çok kullanışlıdır ve hızlı geçiş ve hızlı geri alma sorununu çözer.

  Burada ikinci sorunun çözümü minimizasyondur: Trafiğinizin yalnızca bir kısmını yeni bir hatta, yeni kodlu bir hatta gönderebilirsiniz (örneğin %2 olsun). Ve bu %2 %100 değil! Başarısız bir dağıtım nedeniyle trafiğinizin %100'ünü kaybettiyseniz bu korkutucudur; trafiğinizin %2'sini kaybettiyseniz bu hoş olmayan bir durumdur ancak korkutucu değildir. Dahası, kullanıcılar büyük olasılıkla bunu fark etmeyeceklerdir, çünkü bazı durumlarda (hepsinde değil) aynı kullanıcı F5'e basarak başka bir çalışan sürüme yönlendirilecektir.

  Mavi/Yeşil konuşlandır. Yönlendirme

  Ancak her şey o kadar basit değil "Mavi/Yeşil konuşlandırma"... Tüm bileşenlerimiz üç gruba ayrılabilir:

  • bu ön uçtur (müşterilerimizin gördüğü ödeme sayfaları);
  • çekirdek işleme;
  • Ödeme sistemleriyle (bankalar, MasterCard, Visa...) çalışmak için adaptör.

  Ve burada bir nüans var; nüans, çizgiler arasındaki yönlendirmede yatıyor. Trafiğin %100'ünü değiştirirseniz bu sorunları yaşamazsınız. Ancak %2'yi değiştirmek istiyorsanız şu soruyu sormaya başlarsınız: "Bunu nasıl yapmalı?" En basit şey basittir: nginx'te Round Robin'i rastgele seçimle kurabilirsiniz ve solda %2, sağda %98'iniz vardır. Ancak bu her zaman uygun değildir.

  Örneğin bizim durumumuzda bir kullanıcı birden fazla istekle sistemle etkileşime giriyor. Bu normaldir: 2, 3, 4, 5 istek; sistemleriniz aynı olabilir. Ve eğer tüm kullanıcı isteklerinin ilk isteğin geldiği satıra gelmesi veya (ikinci nokta) tüm kullanıcı isteklerinin geçişten sonra yeni satıra gelmesi sizin için önemliyse (daha önce çalışmaya başlamış olabilir) sistem, geçişten önce), - o zaman bu rastgele dağıtım sizin için uygun değildir. Daha sonra aşağıdaki seçenekler vardır:

  
  
  En basit olan ilk seçenek, istemcinin temel parametrelerine (IP Hash) dayanmaktadır. Bir IP'niz var ve bunu IP adresine göre sağdan sola bölersiniz. O zaman anlattığım ikinci durum sizin için işe yarayacaktır, dağıtım gerçekleştiğinde, kullanıcı zaten sisteminizle çalışmaya başlayabilir ve dağıtım anından itibaren tüm istekler yeni bir satıra (örneğin aynı satıra) gidecektir.

  Herhangi bir nedenle bu size uymuyorsa ve kullanıcının ilk isteğinin geldiği hatta istek göndermeniz gerekiyorsa, o zaman iki seçeneğiniz var...
  İlk seçenek: ücretli nginx+ satın alabilirsiniz. Kullanıcının ilk isteği üzerine kullanıcıya bir oturum atayan ve onu bir veya başka bir yukarı akışa bağlayan bir Yapışkan oturum mekanizması vardır. Oturum süresi boyunca sonraki tüm kullanıcı istekleri, oturumun yayınlandığı aynı yukarı akışa gönderilecektir.

  Bu bize uymadı çünkü zaten normal nginx'imiz vardı. Nginx+'a geçmek pahalı olduğu anlamına gelmiyor, sadece bizim için biraz acı vericiydi ve pek de doğru değildi. Örneğin "Çubuk Oturumları", "Çubuk Oturumları"nın "Ya-veya" temeline dayalı yönlendirmeye izin vermemesi gibi basit bir nedenden dolayı bizim için işe yaramadı. Burada "Çubuk Oturumları"nın ne yapacağını örneğin IP adresi veya IP adresi ve çerezler veya posta parametresi ile belirtebilirsiniz, ancak "Ya-veya" burada daha karmaşıktır.

  Bu nedenle dördüncü seçeneğe geldik. Nginx'i steroidlerle aldık (bu openresty) - bu aynı nginx, ayrıca son komut dosyalarının dahil edilmesini de destekliyor. Son bir komut dosyası yazabilir, ona “açık dinlenme” verebilirsiniz ve bu son komut dosyası, kullanıcı isteği geldiğinde yürütülecektir.

  Ve aslında böyle bir script yazdık, kendimizi “openresti” olarak belirledik ve bu scriptte 6 farklı parametreyi “Or” bitiştirerek sıraladık. Bir veya başka bir parametrenin varlığına bağlı olarak, kullanıcının şu veya bu sayfaya, şu veya bu satıra geldiğini biliyoruz.

  Mavi/Yeşil konuşlandır. Avantajlar ve dezavantajlar

  Elbette, bunu biraz daha basit hale getirmek muhtemelen mümkündü (aynı "Yapışkan Oturumları" kullanın), ancak aynı zamanda öyle bir nüansa da sahibiz ki, yalnızca kullanıcı bizimle bir işlemin tek bir işlenmesi çerçevesinde etkileşime girmiyor... Ancak ödeme sistemleri de bizimle etkileşime giriyor: İşlemi gerçekleştirdikten sonra (ödeme sistemine bir talep göndererek) bir bekleme süresi alıyoruz.
  Ve diyelim ki, devremiz içinde tüm isteklerde kullanıcının IP adresini iletebilir ve kullanıcıları IP adresine göre bölebilirsek, o zaman aynı “Visa”yı söylemeyeceğiz: “Dostum, biz çok retro bir şirketiz, öyle görünüyor ki uluslararası olmak (web sitesinde ve Rusya'da)... Lütfen bize ek bir alanda kullanıcının IP adresini verin, protokolünüz standartlaştırılmıştır”! Aynı fikirde olmayacakları açıktır.

  
  
  Bu nedenle bu bizim için işe yaramadı - açık dinlenme yaptık. Buna göre yönlendirmeyle şöyle bir şey elde ettik:

  Mavi/Yeşil Dağıtımın buna göre bahsettiğim avantajları ve dezavantajları vardır.

  İki dezavantaj:

  • yönlendirmeyle uğraşmanız gerekir;
  • ikinci ana dezavantaj masraftır.

  İki kat daha fazla sunucuya ihtiyacınız var, iki kat daha fazla operasyonel kaynağa ihtiyacınız var, tüm bu hayvanat bahçesini korumak için iki kat daha fazla çaba harcamanız gerekiyor.

  Bu arada avantajlar arasında daha önce bahsetmediğim bir şey daha var: Yükün artması durumunda rezerviniz oluyor. Yükte büyük bir artış varsa, çok sayıda kullanıcınız varsa, o zaman ikinci satırı 50'den 50'ye kadar dağıtıma dahil edersiniz ve daha fazla sunucuya sahip olma sorununu çözene kadar kümenizde hemen x2 sunucunuz olur.

  Hızlı dağıtım nasıl yapılır?

  Minimize etme ve hızlı geri alma sorununu nasıl çözeceğimizi konuştuk ama şu soru hala ortada: "Hızlı bir şekilde nasıl konuşlandırılır?"

  
  
  Burada kısa ve basit.

  • Bir CD sisteminiz (Sürekli Teslimat) olmalıdır; onsuz yaşayamazsınız. Bir sunucunuz varsa manuel olarak dağıtabilirsiniz. Yaklaşık bir buçuk bin sunucumuz ve bir buçuk bin tanıtıcımız var elbette - sadece konuşlandırmak için bu odanın büyüklüğünde bir departmanı yerleştirebiliriz.
  • Dağıtım paralel olmalıdır. Dağıtımınız sıralıysa, her şey kötü demektir. Bir sunucu normaldir, tüm gün bir buçuk bin sunucuyu konuşlandıracaksınız.
  • Tekrar ediyorum, hızlanma için bu muhtemelen artık gerekli değildir. Dağıtım sırasında proje genellikle oluşturulur. Bir web projeniz var, bir ön uç kısmı var (orada bir web paketi hazırlıyorsunuz, npm'yi derliyorsunuz - buna benzer bir şey) ve bu süreç prensip olarak kısa ömürlüdür - 5 dakika, ancak bu 5 dakika eleştirel ol. Bu yüzden örneğin bunu yapmıyoruz: Bu 5 dakikayı kaldırdık, eserleri dağıtıyoruz.

    Bir eser nedir? Bir eser, tüm montaj parçalarının zaten tamamlanmış olduğu, monte edilmiş bir yapıdır. Bu eseri eser deposunda saklıyoruz. Bir zamanlar bu tür iki depo kullanıyorduk - Nexus'tu ve şimdi jFrog Artifactory.Başlangıçta “Nexus”u kullandık çünkü bu yaklaşımı java uygulamalarında uygulamaya başladık (buna çok yakıştı). Daha sonra PHP ile yazılmış bazı uygulamaları oraya koydular; ve “Nexus” artık uygun değildi ve bu nedenle neredeyse her şeyi yapay hale getirebilen jFrog Artefactory'yi seçtik. Hatta sunucular için topladığımız kendi ikili paketlerimizi bu yapı deposunda saklayacak noktaya geldik.

  Patlayıcı yük artışı

  Yazılım sürümünün değiştirilmesinden bahsettik. Bir sonraki şey yükte patlayıcı bir artış. Burada, muhtemelen yükün patlayıcı bir şekilde büyümesini kastediyorum, pek de doğru bir şey değil...

  Yeni bir sistem yazdık; hizmet odaklı, modaya uygun, güzel, her yerde işçiler, her yerde kuyruklar, her yerde asenkron. Ve bu tür sistemlerde veriler farklı akışlardan akabilir. İlk işlem için 1., 3., 10. işçi, ikinci işlem için ise 2., 4., 5. işçi kullanılabilir. Ve bugün, diyelim ki, sabah ilk üç işçiyi kullanan bir veri akışınız var ve akşam dramatik bir şekilde değişiyor ve her şey diğer üç işçiyi kullanıyor.

  Ve burada, işçileri bir şekilde ölçeklendirmeniz gerektiği, hizmetlerinizi bir şekilde ölçeklendirmeniz gerektiği, ancak aynı zamanda kaynak şişkinliğini de önlemeniz gerektiği ortaya çıktı.

  
  
  İhtiyaçlarımızı belirledik. Bu gereksinimler oldukça basittir: Hizmet keşfi, parametrelendirme olması - bu tür ölçeklenebilir sistemler oluşturmak için her şey standarttır, tek nokta - kaynak amortismanı dışında. Sunucuların havayı ısıtması için kaynakları amorti etmeye hazır olmadığımızı söyledik. “Konsolos”u aldık, işçilerimizi yöneten “Göçebe”yi aldık.

  Bu bizim için neden sorun oluyor? Biraz geriye gidelim. Artık arkamızda 70’e yakın ödeme sistemi var. Sabah trafik Sberbank'tan geçiyor, sonra örneğin Sberbank düştü ve biz onu başka bir ödeme sistemine geçiriyoruz. Sberbank'tan önce 100 çalışanımız vardı, bundan sonra başka bir ödeme sistemi için 100 çalışanımızı keskin bir şekilde artırmamız gerekiyor. Ve tüm bunların insan katılımı olmadan gerçekleşmesi arzu edilir. Çünkü insan katılımı varsa, 24/7 orada oturan bir mühendisin olması gerekir, sadece bunu yapması gerekir, çünkü 70 sistem arkanızdayken bu tür arızalar düzenli olarak meydana gelir.

  Bu nedenle, açık IP'ye sahip olan Nomad'a baktık ve yaklaşık olarak aşağıdakileri yapan kendi şeyimiz olan Scale-Nomad - ScaleNo'yu yazdık: kuyruğun büyümesini izler ve dinamiklere bağlı olarak çalışan sayısını azaltır veya artırır. kuyruktan. Bunu yaptığımızda şöyle düşündük: “Belki kaynak olarak açabiliriz?” Sonra ona baktılar; iki kopek kadar basitti.

  Şu ana kadar açık kaynak yapmadık ama rapordan sonra birdenbire böyle bir şeye ihtiyacınız olduğunu fark ettikten sonra ihtiyacınız varsa, son slaytta iletişim bilgilerim var - lütfen bana yazın. En az 3-5 kişi olursa sponsor oluruz.

  
  
  Nasıl çalışır? Hadi bir göz atalım! İleriye baktığımızda: sol tarafta izlememizin bir parçası var: bu bir satır, üstte olayın işlenme zamanı, ortada işlem sayısı, altta çalışan sayısı.

  Eğer bakarsanız bu resimde bir aksaklık var. En üstteki grafikte grafiklerden biri 45 saniye içinde çöktü; ödeme sistemlerinden biri çöktü. Hemen 2 dakika içinde trafik getirildi ve işçinin olmadığı başka bir ödeme sisteminde kuyruk büyümeye başladı (kaynakları kullanmadık - tam tersine kaynağı doğru şekilde imha ettik). Isınmak istemedik; minimum sayıda, yaklaşık 5-10 işçi vardı, ancak başa çıkamadılar.

  Son grafikte bir "tümsek" görülüyor, bu da "Skaleno"nun bu miktarı ikiye katladığı anlamına geliyor. Daha sonra grafik biraz düştüğünde biraz azalttı; çalışan sayısı otomatik olarak değişti. Bu iş böyle yürüyor. 2 numaralı noktadan bahsettik - "Sebeplerden hızlı bir şekilde nasıl kurtuluruz?"

  İzleme. Sorun hızlı bir şekilde nasıl tespit edilir?

  Şimdi ilk nokta “Sorunu hızlı bir şekilde nasıl tespit edebiliriz?” İzleme! Bazı şeyleri hızla anlamamız gerekiyor. Hangi şeyleri hızlı bir şekilde anlamalıyız?

  
  
  Üç şey!

  • Kendi kaynaklarımızın performansını hızlı bir şekilde anlamalı ve anlamalıyız.
  • Arızaları hızla anlamalı ve dışımızdaki sistemlerin performansını izlemeliyiz.
  • Üçüncü nokta mantıksal hataların belirlenmesidir. Bu, sistemin sizin için çalıştığı zamandır, tüm göstergelere göre her şey normaldir, ancak bir şeyler ters gider.

  Muhtemelen sana burada o kadar harika bir şey söylemeyeceğim. Ben Kaptan Açıkça olacağım. Piyasada ne var diye baktık. Bir “eğlenceli hayvanat bahçemiz” var. Şu anda sahip olduğumuz hayvanat bahçesi türü:

  
  
  Donanımı izlemek, sunucuların ana göstergelerini izlemek için Zabbix'i kullanıyoruz. Veritabanları için Okmeter kullanıyoruz. İlk ikisine uymayan diğer tüm göstergeler için “Grafana” ve “Prometheus” kullanıyoruz, bazıları “Grafana” ve “Prometheus”, bazıları ise “Influx” ve Telegraf ile “Grafana” kullanıyoruz.

  Bir yıl önce New Relic'i kullanmak istiyorduk. Harika bir şey, her şeyi yapabilir. Ama her ne kadar her şeyi yapabilse de çok pahalıdır. 1,5 bin sunucu hacmine ulaştığımızda bir satıcı yanımıza gelerek “Gelecek yıl için anlaşma yapalım” dedi. Fiyatına baktık ve hayır bunu yapmayacağız dedik. Artık New Relic'ten vazgeçiyoruz, New Relic'in gözetiminde kalan 15'e yakın sunucumuz kaldı. Fiyatın kesinlikle çılgın olduğu ortaya çıktı.

  Ve kendi uyguladığımız bir araç var - bu Hata Ayıklayıcı. İlk başta buna "Bagger" adını verdik ama sonra yanımızdan geçen bir İngilizce öğretmeni çılgınca güldü ve adını "Debagger" olarak değiştirdi. Ne olduğunu? Bu, aslında sistemin bir "kara kutusu" gibi her bir bileşen üzerinde 15-30 saniye içinde bileşenin genel performansı üzerinde testler çalıştıran bir araçtır.

  Örneğin harici bir sayfa (ödeme sayfası) varsa, onu açar ve nasıl görünmesi gerektiğine bakar. Eğer bu işleniyorsa test amaçlı bir “işlem” gönderir ve bu “işlem”in geldiğinden emin olur. Eğer bu ödeme sistemleriyle bir bağlantı ise, mümkün olan her yerde test talebini ateşliyoruz ve her şeyin yolunda olup olmadığını görüyoruz.

  İzleme için hangi göstergeler önemlidir?

  Esas olarak neyi izliyoruz? Hangi göstergeler bizim için önemlidir?

  
  

  • Cephelerde tepki süresi/RPS çok önemli bir göstergedir. Hemen sende bir sorun olduğunu söylüyor.
  • Tüm kuyruklardaki işlenen iletilerin sayısı.
  • Çalışan sayısı.
  • Temel doğruluk ölçütleri.

  Son nokta ise “iş”, “iş” ölçüsüdür. Aynı şeyi izlemek istiyorsanız sizin için ana gösterge olan bir veya iki metriği tanımlamanız gerekir. Ölçütümüz verimdir (bu, başarılı işlem sayısının toplam işlem akışına oranıdır). 5-10-15 dakika arayla onda bir şeyler değişiyorsa (kökten değişiyorsa) sorun yaşıyoruz demektir.

  Bizim için neye benzediği panolarımızdan birinin bir örneğidir:

  
  
  Sol tarafta 6 grafik var, bu çizgilere göre - çalışan sayısı ve kuyruklardaki mesaj sayısı. Sağ tarafta – RPS, RTS. Aşağıda aynı “işletme” metriği bulunmaktadır. Ve “iş” metriğinde, ortadaki iki grafikte bir şeylerin ters gittiğini hemen görebiliyoruz… Bu, arkamızda duran, çökmüş bir sistemden başka bir şey değil.

  Yapmamız gereken ikinci şey dış ödeme sistemlerinin çöküşünü izlemekti. Burada, dağıtılmış sistemleri izlemenize olanak tanıyan bir mekanizma, standart, paradigma olan OpenTracing'i ele aldık; ve biraz değiştirildi. Standart OpenTracing paradigması, her bir istek için bir izleme oluşturduğumuzu söylüyor. Buna ihtiyacımız yoktu ve bunu bir özet, toplama izine tamamladık. Arkamızdaki sistemlerin hızını takip etmemizi sağlayan bir araç yaptık.

  
  
  Grafik bize ödeme sistemlerinden birinin 3 saniye içinde yanıt vermeye başladığını gösteriyor - sorun yaşıyoruz. Üstelik bu şey sorunlar başladığında 20-30 saniye aralıklarla tepki verecek.

  Ve mevcut izleme hatalarının üçüncü sınıfı mantıksal izlemedir.

  Dürüst olmak gerekirse, bu slaytta ne çizeceğimi bilmiyordum çünkü uzun süredir piyasada kendimize uygun bir şey arıyorduk. Hiçbir şey bulamadık, bu yüzden bunu kendimiz yapmak zorunda kaldık.

  
  
  Mantıksal izleme ile ne demek istiyorum? Peki, hayal edin: kendinize bir sistem yapıyorsunuz (örneğin bir Tinder klonu); başardın, başlattın. Başarılı yönetici Vasya Pupkin bunu telefonuna koyar, orada bir kız görür, ondan hoşlanır... ve benzerleri kıza gitmez - aynı iş merkezinden güvenlik görevlisi Mikhalych'e gider. Müdür aşağıya iniyor ve merak ediyor: "Bu güvenlik görevlisi Mikhalych neden ona bu kadar hoş gülümsüyor?"

  Böyle durumlarda... Bize bu durum biraz farklı geliyor çünkü (yazdım) bu dolaylı olarak maddi kayıplara yol açan bir itibar kaybıdır. Bizim durumumuz tam tersi: Doğrudan mali kayıplara maruz kalabiliriz - örneğin, bir işlemi başarılı olarak gerçekleştirdik ancak başarısız olduysa (veya tam tersi). İş göstergelerini kullanarak zaman içindeki başarılı işlemlerin sayısını takip eden kendi aracımı yazmam gerekiyordu. Piyasada hiçbir şey bulunamadı! Aktarmak istediğim fikir tam olarak buydu. Piyasada bu tür sorunları çözecek hiçbir şey yok.

  Bu, sorunun hızlı bir şekilde nasıl tespit edileceğiyle ilgiliydi.

  Dağıtım nedenleri nasıl belirlenir

  Çözdüğümüz üçüncü grup problemler ise problemi tespit ettikten, ondan kurtulduktan sonra geliştirmenin, test etmenin nedenini anlayıp bu konuda bir şeyler yapmak iyi olacaktır. Buna göre araştırmamız lazım, logları kaldırmamız lazım.

  
  
  Günlüklerden bahsediyorsak (ana sebep günlüklerdir), günlüklerimizin büyük kısmı ELK Stack'tedir - neredeyse herkeste aynısı vardır. Bazıları için ELK'de olmayabilir ama günlükleri gigabayt cinsinden yazarsanız er ya da geç ELK'ye geleceksiniz. Bunları terabayt cinsinden yazıyoruz.

  
  
  Burada bir sorun var. Bunu düzelttik, kullanıcı için hatayı düzelttik, orada ne olduğunu kazmaya başladık, Kibana'ya tırmandık, işlem kimliğini oraya girdik ve bunun gibi bir ayak örtüsü elde ettik (çok şey gösteriyor). Ve bu ayak örtüsünde kesinlikle hiçbir şey net değil. Neden? Evet çünkü hangi parçanın hangi işçiye ait olduğu, hangi parçanın hangi bileşene ait olduğu belli değil. Ve o anda izlemeye ihtiyacımız olduğunu fark ettik; bahsettiğim OpenTracing'in aynısı.

  Bunu bir yıl önce düşündük, dikkatimizi pazara çevirdik ve orada iki araç vardı: "Zipkin" ve "Jaeger". “Jager” aslında böyle bir ideolojik varis, “Zipkin”in ideolojik halefidir. Zipkin'de her şey yolunda, ancak nasıl toplanacağını bilmiyor, günlükleri ize nasıl dahil edeceğini bilmiyor, sadece zaman takibini yapıyor. Ve “Jager” bunu destekledi.

  “Jager”a baktık: uygulamaları enstrümantize edebilirsiniz, Api'de yazabilirsiniz (ancak o zamanlar PHP için Api standardı onaylanmamıştı - bu bir yıl önceydi, ancak şimdi zaten onaylandı), ama orada kesinlikle müşteri değildi. “Tamam” diye düşündük ve kendi müşterimizi yazdık. Ne elde ettik? Bu kabaca şuna benziyor:

  
  
  Jaeger'de her mesaj için aralıklar oluşturulur. Yani kullanıcı sistemi açtığında her gelen istek için bir veya iki blok görmektedir (1-2-3 - kullanıcıdan gelen istek sayısı, blok sayısı). Kullanıcıların işini kolaylaştırmak için günlüklere ve zaman takiplerine etiketler ekledik. Buna göre bir hata durumunda uygulamamız günlüğü uygun Error etiketiyle işaretleyecektir. Hata etiketine göre filtreleyebilirsiniz ve yalnızca bu bloğu içeren ve hatalı olan aralıklar görüntülenecektir. Açıklığı genişletirsek şöyle görünür:

  
  
  Açıklığın içinde bir dizi iz var. Bu durumda bunlar üç test izidir ve üçüncü iz bize bir hatanın oluştuğunu bildirir. Aynı zamanda burada bir zaman izi görüyoruz: Üstte bir zaman ölçeğimiz var ve şu veya bu günlüğün hangi zaman aralığında kaydedildiğini görüyoruz.

  Buna göre işler bizim açımızdan iyi gitti. Uzantımızı kendimiz yazdık ve açık kaynaklı hale getirdik. İzleme ile çalışmak istiyorsanız, PHP'de "Jager" ile çalışmak istiyorsanız, dedikleri gibi, bizim uzantımız var, kullanıma hoş geldiniz:

  
  
  Bu uzantıya sahibiz - OpenTracing Api için bir istemcidir, php uzantısı olarak yapılmıştır, yani onu birleştirip sisteme yüklemeniz gerekecektir. Bir yıl önce farklı bir şey yoktu. Artık bileşenlere benzeyen başka istemciler de var. Burada karar size kalmış: Ya bileşenleri bir besteciyle dışarı pompalarsınız ya da uzantıyı kullanırsınız.

  Kurumsal standartlar

  Üç emirden bahsettik. Dördüncü emir yaklaşımları standartlaştırmaktır. Bu ne hakkında? Bununla ilgili:

  
  
  Neden burada “kurumsal” kelimesi geçiyor? Büyük veya bürokratik bir şirket olduğumuz için değil, hayır! Siz de dahil olmak üzere her firmanın, her ürünün kendine has standartları olması gerektiği bağlamında kurumsal kelimesini burada kullanmak istedim. Hangi standartlara sahibiz?

  
  

  • Dağıtım düzenlemelerimiz var. O olmadan hiçbir yere gitmiyoruz, yapamayız. Haftada yaklaşık 60 kez konuşlandırıyoruz, yani neredeyse sürekli konuşlandırıyoruz. Aynı zamanda, örneğin konuşlandırma düzenlemelerinde Cuma günü konuşlandırmalara ilişkin bir tabu var - prensip olarak konuşlandırmıyoruz.
  • Belgelere ihtiyacımız var. Ar-Ge uzmanlarımızın kaleminden doğmuş olsa bile, tek bir yeni bileşen bile dokümantasyon yoksa üretime geçmiyor. Onlardan dağıtım talimatlarına, bir izleme haritasına ve bu bileşenin nasıl çalıştığına ve sorunun nasıl giderileceğine dair (programcıların yazabileceği şekilde) kaba bir açıklama talep ediyoruz.
  • Sorunun nedenini değil, daha önce söylediğim sorunu çözüyoruz. Kullanıcıyı sorunlardan korumak bizim için önemlidir.
  • İzinlerimiz var. Örneğin, iki dakika içinde trafiğin %2'sini kaybedersek bunu kesinti olarak değerlendirmiyoruz. Bu aslında istatistiklerimize dahil değildir. Yüzde olarak daha fazla ya da geçici ise zaten sayıyoruz.
  • Ve biz her zaman ölüm sonrası yazılar yazarız. Başımıza ne gelirse gelsin, üretimde birinin anormal davrandığı herhangi bir durum otopsiye de yansıyacaktır. Otopsi, başınıza ne geldiğini, ayrıntılı bir zamanlamayı, bunu düzeltmek için ne yaptığınızı ve (bu zorunlu bir engellemedir!) gelecekte bunun olmasını önlemek için ne yapacağınızı yazdığınız bir belgedir. Bu, sonraki analizler için zorunludur ve gereklidir.

  Kesinti süresi ne olarak kabul edilir?

  
  
  Bütün bunlar neye yol açtı?

  Bu da son 6 ayda istikrar göstergemizin 99,97 olmasına yol açtı (istikrar konusunda bazı sorunlarımız vardı, bu ne müşterilerimize ne de bize yakışıyordu). Bunun çok fazla olmadığını söyleyebiliriz. Evet, çabalamamız gereken bir şey var. Bu göstergenin yaklaşık yarısı bizim değil, önümüzde duran ve hizmet olarak kullanılan web uygulaması güvenlik duvarımızın kararlılığıdır, ancak müşteriler bunu umursamıyor.

  Gece uyumayı öğrendik. Nihayet! Altı ay önce bunu yapamıyorduk. Ve sonuçların yer aldığı bu notta bir not düşmek istiyorum. Dün gece nükleer reaktörün kontrol sistemi hakkında harika bir rapor vardı. Bu sistemi yazanlar beni duyabiliyorsa lütfen “%2 kesinti değildir” dediğimi unutun. Sizin için %2, iki dakika bile olsa kesintidir!

  Bu kadar! Sorularınız.

  
  

  Dengeleyiciler ve veritabanı geçişi hakkında

  Dinleyicilerin sorusu (bundan sonra – B olarak anılacaktır): – İyi akşamlar. Böyle bir yönetici raporu için çok teşekkür ederiz! Dengeleyicileriniz hakkında kısa bir soru. WAF'ınız olduğundan bahsetmişsiniz, yani anladığım kadarıyla bir tür dış dengeleyici kullanıyorsunuz...

  : – Hayır, hizmetlerimizi dengeleyici olarak kullanıyoruz. Bu durumda WAF bizim için yalnızca bir DDoS koruma aracıdır.

  In: – Dengeleyiciler hakkında birkaç söz söyleyebilir misiniz?

  : – Daha önce de söylediğim gibi bu, openresty'deki bir sunucu grubudur. Artık özel olarak yanıt veren 5 yedek grubumuz var... yani, yalnızca openresty çalıştıran bir sunucu, yalnızca trafiği proxy olarak yönetir. Buna göre ne kadar tuttuğumuzu anlamak için: Artık birkaç yüz megabitlik düzenli bir trafik akışımız var. Başa çıkıyorlar, kendilerini iyi hissediyorlar, hatta kendilerini yormuyorlar.

  In: – Ayrıca basit bir soru. İşte Mavi/Yeşil dağıtım. Örneğin veritabanı geçişlerinde ne yaparsınız?

  : - İyi soru! Bakın Mavi/Yeşil dağıtımda her hat için ayrı kuyruklarımız var. Yani işçiden işçiye iletilen olay kuyruklarından bahsediyorsak mavi hat ve yeşil hat için ayrı kuyruklar bulunmaktadır. Veritabanının kendisinden bahsediyorsak, onu kasıtlı olarak mümkün olduğunca daralttık, her şeyi pratik olarak kuyruklara taşıdık; veritabanında yalnızca bir işlem yığınını saklıyoruz. Ve işlem yığınımız tüm satırlar için aynıdır. Bu bağlamda veri tabanını mavi ve yeşil olarak ayırmıyoruz çünkü kodun her iki versiyonunun da işlemde ne olduğunu bilmesi gerekiyor.

  Arkadaşlar, sizi teşvik edecek küçük bir ödülüm de var: bir kitap. Ve en iyi soru ödülü bana verilmeli.

  In: - Merhaba. Rapor için teşekkürler. Soru şudur. Ödemeleri izliyorsunuz, iletişim kurduğunuz hizmetleri izliyorsunuz... Peki bir kişinin bir şekilde ödeme sayfanıza gelmesini, ödeme yapmasını ve projenin ona para yatırmasını nasıl izlersiniz? Yani, yürüyüşe çıkan kişinin müsait olup olmadığını ve geri aramanızı kabul edip etmediğini nasıl izleyeceksiniz?

  : – Bu durumda bizim için “Satıcı”, ödeme sistemiyle tamamen aynı harici hizmettir. Satıcının tepki hızını izliyoruz.

  Veritabanı şifreleme hakkında

  In: - Merhaba. Biraz ilgili bir sorum var. PCI DSS'ye duyarlı verileriniz var. PAN'ları aktarmanız gereken kuyruklarda nasıl sakladığınızı bilmek istedim. Herhangi bir şifreleme kullanıyor musunuz? Bu da ikinci soruya yol açıyor: PCI DSS'ye göre, değişiklik durumunda (yöneticilerin görevden alınması vb.) veritabanını periyodik olarak yeniden şifrelemek gerekir - bu durumda erişilebilirliğe ne olur?

  
  
  : - Harika soru! Öncelikle PAN'ları kuyruklarda saklamıyoruz. Prensip olarak PAN'ı herhangi bir yerde açık biçimde saklama hakkımız yok, bu nedenle özel bir hizmet kullanıyoruz ("Kademon" diyoruz) - bu yalnızca tek bir şey yapan bir hizmettir: giriş olarak bir mesaj alır ve gönderir. şifrelenmiş bir mesaj yayınladı. Ve her şeyi bu şifreli mesajla saklıyoruz. Buna göre anahtar uzunluğumuz kilobaytın altında, bu da ciddi ve güvenilir bir durum.

  In: – Şimdi 2 kilobayta mı ihtiyacınız var?

  : – Sanki daha dün 256'ydı... Peki başka nerede?!

  Buna göre bu ilk. İkincisi, mevcut çözüm, yeniden şifreleme prosedürünü destekliyor - şifreleyen "desteler" veren iki çift "kek" (anahtar) var (anahtarlar anahtarlardır, dekler şifreleyen anahtarların türevleridir) . Ve eğer prosedür başlatılırsa (3 aydan ± bazılarına kadar düzenli olarak gerçekleşir), yeni bir çift "kek" indiririz ve verileri yeniden şifreleriz. Tüm verileri söküp yeni bir şekilde şifreleyen ayrı hizmetlerimiz var; Veriler, şifrelendiği anahtarın tanımlayıcısının yanında saklanır. Buna göre veriyi yeni anahtarlarla şifrelediğimizde eski anahtarı sileriz.

  Bazen ödemelerin manuel olarak yapılması gerekir...

  In: – Yani, eğer bir işlem için para iadesi gelmişse, yine de eski anahtarla şifresini çözecek misiniz?

  : - Evet.

  In: – Sonra küçük bir soru daha. Bir tür arıza, düşme veya olay meydana geldiğinde işlemin manuel olarak gerçekleştirilmesi gerekir. Böyle bir durum var.

  : - Evet bazen.

  In: – Bu verileri nereden alıyorsunuz? Yoksa bu depolama tesisine kendiniz mi gidiyorsunuz?

  : – Hayır, elbette desteğimiz için bir arayüz içeren bir tür arka ofis sistemimiz var. İşlemin hangi durumda olduğunu bilmiyorsak (örneğin, ödeme sistemi zaman aşımı ile yanıt verene kadar), a priori bilemeyiz, yani nihai durumu yalnızca tam güvenle atarız. Bu durumda işleme, manuel işleme için özel bir durum atarız. Ertesi gün sabah, destek bu tür işlemlerin ödeme sisteminde kaldığı bilgisini alır almaz bu arayüzde manuel olarak işleme koyar.

  
  
  In: – Birkaç sorum var. Bunlardan biri PCI DSS bölgesinin devamıdır: Devrelerini nasıl kaydedersiniz? Bu sorunun nedeni geliştiricinin günlüklere herhangi bir şey koymuş olabilmesidir! İkinci soru: düzeltmeleri nasıl kullanıma sunarsınız? Veritabanındaki tanıtıcıları kullanmak bir seçenektir, ancak ücretsiz düzeltmeler olabilir; buradaki prosedür nedir? Ve üçüncü soru muhtemelen RTO, RPO ile ilgilidir. Kullanılabilirliğiniz 99,97'ydi, neredeyse dört dokuz, ama anladığım kadarıyla ikinci bir veri merkeziniz, üçüncü bir veri merkeziniz ve beşinci bir veri merkeziniz var... Bunları nasıl senkronize edersiniz, kopyalarsınız ve diğer her şeyi nasıl yaparsınız?

  : - İlkiyle başlayalım. İlk soru günlüklerle ilgili miydi? Günlükleri yazdığımızda tüm hassas verileri maskeleyen bir katmana sahibiz. Maskeye ve ek alanlara bakıyor. Buna göre loglarımız zaten maskelenmiş verilerle ve bir PCI DSS devresiyle çıkıyor. Bu, test departmanına verilen düzenli görevlerden biridir. Yazdıkları günlükler de dahil olmak üzere her görevi kontrol etmeleri gerekir ve bu, geliştiricinin bir şey yazmadığını kontrol etmek için kod incelemeleri sırasında olağan görevlerden biridir. Bunun müteakip kontrolleri bilgi güvenliği departmanı tarafından yaklaşık haftada bir kez düzenli olarak gerçekleştirilir: son güne ait günlükler seçici olarak alınır ve her şeyi kontrol etmek için test sunucularından özel bir tarayıcı-analizörden geçirilir.
  Düzeltmeler hakkında. Bu, dağıtım düzenlemelerimize dahildir. Düzeltmelerle ilgili ayrı bir maddemiz var. Düzeltmeleri ihtiyaç duyduğumuzda günün her saatinde dağıttığımıza inanıyoruz. Sürüm derlendiği anda, çalıştırıldığı anda, bir yapıtımız olur olmaz, destekten gelen bir çağrı üzerine bir sistem yöneticimiz görev başında oluyor ve gerektiği anda onu devreye alıyor.

  "Dört dokuzlu" hakkında. Şu anda ulaştığımız rakama gerçekten ulaştık ve başka bir veri merkezinde bunun için çabaladık. Artık ikinci bir veri merkezimiz var ve bunlar arasında yönlendirme yapmaya başlıyoruz ve veri merkezleri arası çoğaltma konusu gerçekten de önemsiz olmayan bir soru. Bunu aynı anda farklı yöntemlerle çözmeye çalıştık: aynı "Tarantula" yı kullanmaya çalıştık - bizim için işe yaramadı, hemen söyleyeceğim. Bu yüzden "sens"i manuel olarak sipariş ettik. Aslında sistemimizdeki her uygulama, veri merkezleri arasında gerekli olan “değiştir – yapıldı” senkronizasyonunu asenkron olarak çalıştırmaktadır.

  In: – İkinciyi aldıysanız üçüncüyü neden alamadınız? Çünkü henüz kimsenin beyni bölünmüş değil...

  : – Ama Bölünmüş Beynimiz yok. Her uygulama bir multimaster tarafından çalıştırıldığı için talebin hangi merkeze geldiği bizim için önemli değil. Veri merkezlerimizden biri arızalanırsa (buna güveniyoruz) ve bir kullanıcı talebinin ortasında ikinci veri merkezine geçersek, bu kullanıcıyı kaybetmeye hazırız; ama bunlar birimler olacak, mutlak birimler.

  In: - İyi akşamlar. Rapor için teşekkürler. Üretimde bazı test işlemlerini yürüten hata ayıklayıcınızdan bahsettiniz. Ama bize test işlemlerinden bahsedin! Ne kadar derine gidiyor?

  : – Tüm bileşenin tam döngüsünden geçer. Bir bileşen için test işlemi ile üretim işlemi arasında hiçbir fark yoktur. Ancak mantıksal açıdan bakıldığında bu, sistemdeki yalnızca test işlemlerinin yürütüldüğü ayrı bir projedir.

  In: -Nerede keseceksin? İşte Core gönderdi...

  : – Test işlemleri için bu durumda “Kor”un arkasındayız… Yönlendirme diye bir şeyimiz var: “Kor” hangi ödeme sistemine gönderim yapacağını biliyor - sadece http sinyali veren sahte bir ödeme sistemine gönderiyoruz ve bu kadar.

  In: – Lütfen söyleyin bana, başvurunuz tek parça halinde mi yazıldı, yoksa onu bazı hizmetlere ve hatta mikro hizmetlere mi böldünüz?

  : – Bizim monolitimiz yok elbette, hizmet odaklı bir uygulamamız var. Hizmetimizin yekpare taşlardan yapıldığına dair şaka yapıyoruz - bunlar gerçekten oldukça büyük. Buna mikro hizmetler demek zor ama bunlar dağıtılmış makinelerin çalışanlarının faaliyet gösterdiği hizmetlerdir.

  Sunucudaki hizmet tehlikeye girerse...

  In: – O zaman bir sonraki sorum var. Tek parça bile olsa, yine de bu anlık sunucuların çoğuna sahip olduğunuzu, hepsinin temelde veri işlediğini söylediniz ve soru şu: "Anlık sunuculardan veya bir uygulamadan birinin tehlikeye atılması durumunda, herhangi bir bireysel bağlantı , bir çeşit erişim kontrolü var mı? Bunlardan hangisi ne yapabilir? Hangi bilgi için kiminle iletişime geçmeliyim?

  
  
  : - Evet kesinlikle. Güvenlik gereksinimleri oldukça ciddidir. Birincisi, açık veri hareketlerimiz var ve bağlantı noktaları yalnızca trafik hareketini önceden öngördüğümüz bağlantı noktalarıdır. Bir bileşen veritabanıyla (örneğin Muskul ile) 5-4-3-2 aracılığıyla iletişim kurarsa, yalnızca 5-4-3-2 ona açık olacak ve diğer bağlantı noktaları ve diğer trafik yönleri kullanılamayacaktır. Ayrıca üretimimizde yaklaşık 10 farklı güvenlik döngüsünün bulunduğunu da anlamalısınız. Ve uygulamanın bir şekilde güvenliği ihlal edilmiş olsa bile, Allah korusun, saldırgan sunucu yönetim konsoluna erişemeyecektir çünkü burası farklı bir ağ güvenlik bölgesidir.

  In: – Ve bu bağlamda bana daha ilginç gelen şey, hizmetlerle belirli sözleşmelerinizin olması, ne yapabilecekleri, hangi “eylemler” yoluyla birbirleriyle iletişim kurabilecekleri… Ve normal bir akışta, bazı belirli hizmetler bazı taleplerde bulunuyor. satır, diğer tarafta “eylemlerin” listesi. Normal bir durumda başkalarına yönelmiyor gibi görünüyorlar ve başka sorumluluk alanları var. Bunlardan birinin güvenliği ihlal edilirse, o hizmetin "eylemlerini" bozabilecek mi?..

  : - Anladım. Normal bir durumda başka bir sunucuyla iletişime izin veriliyorsa, o zaman evet. SLA sözleşmesine göre, yalnızca ilk 3 "eylem"e izin verildiğini ve 4 "eylem"e izin verilmediğini izlemiyoruz. Bu muhtemelen bizim için gereksizdir, çünkü prensip olarak devreler için zaten 4 seviyeli bir koruma sistemimiz var. Kendimizi iç kısımlardan ziyade dış hatlarla savunmayı tercih ediyoruz.

  Visa, MasterCard ve Sberbank nasıl çalışır?

  In: – Bir kullanıcıyı bir veri merkezinden diğerine geçirme konusunda bir noktaya açıklık getirmek istiyorum. Bildiğim kadarıyla Visa ve MasterCard 8583 ikili senkron protokolünü kullanarak çalışıyor ve orada karışımlar var. Ve bilmek istedim, şimdi geçiş yapmayı kastediyoruz – doğrudan “Visa” ve “MasterCard” mı yoksa ödeme sistemlerinden önce mi, işlemden önce mi?

  : - Bu mikslerden önce. Karışımlarımız aynı veri merkezinde bulunmaktadır.

  In: – Kabaca söylemek gerekirse tek bir bağlantı noktanız var mı?

  : – “Visa” ve “MasterCard” - evet. Çünkü Visa ve MasterCard, örneğin ikinci bir karma çifti elde etmek için ayrı sözleşmeler yapmak için oldukça ciddi altyapı yatırımları gerektiriyor. Tek bir veri merkezinde rezerve edilmişler ama eğer Allah korusun, Visa ve MasterCard'a bağlanmak için karmaların olduğu veri merkezimiz ölürse, o zaman Visa ve MasterCard ile bağlantımız kesilir...

  In: – Nasıl rezerve edilebilirler? Visa'nın prensipte yalnızca tek bir bağlantıya izin verdiğini biliyorum!

  : – Ekipmanı kendileri sağlıyorlar. Her durumda, içeride tamamen yedekli ekipman aldık.

  In: – Yani stand Connects Orange'dan mı?..

  : - Evet.

  In: – Peki ya şu durumda: Veri merkeziniz kaybolursa onu kullanmaya nasıl devam edebilirsiniz? Yoksa trafik mi duruyor?

  : - HAYIR. Bu durumda trafiği başka bir kanala geçireceğiz ki bu da doğal olarak bizim için daha pahalı, müşterilerimiz için daha pahalı olacak. Ancak trafik Visa, MasterCard ile doğrudan bağlantımızdan değil, koşullu Sberbank (çok abartılı) üzerinden geçecek.

  Sberbank çalışanlarını rahatsız ettiysem çılgınca özür dilerim. Ancak istatistiklerimize göre Rus bankaları arasında en çok Sberbank düşüyor. Sberbank'ta bir şeylerin ters gitmediği bir ay bile geçmiyor.

  
  
  

  Bazı reklamlar 🙂

  Bizimle kaldığın için teşekkürler. Yazılarımızı beğeniyor musunuz? Daha ilginç içerik görmek ister misiniz? Sipariş vererek veya arkadaşlarınıza tavsiye ederek bize destek olun, Geliştiriciler için bulut VPS'si 4.99 ABD dolarından başlayan fiyatlarla, sizin için bizim tarafımızdan icat edilen benzersiz bir giriş seviyesi sunucu analoğu: 5$'dan başlayan fiyatlarla VPS (KVM) E2697-3 v6 (10 Çekirdek) 4GB DDR480 1GB SSD 19Gbps hakkındaki tüm gerçekler veya bir sunucu nasıl paylaşılır? (RAID1 ve RAID10, 24 adede kadar çekirdek ve 40 GB'a kadar DDR4 ile mevcuttur).

  Amsterdam'daki Equinix Tier IV veri merkezinde Dell R730xd 2 kat daha mı ucuz? Sadece burada 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV 199$'dan Hollanda'da! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99$'dan! Hakkında oku Altyapı şirketi nasıl kurulur? Bir kuruş için 730 Euro değerinde Dell R5xd E2650-4 v9000 sunucuların kullanımı ile sınıf?

Kaynak: habr.com