Hələ də inkişaf, test prosesi, işçi təlimi, motivasiya artırma haqqında danışılır, amma xidmətin bir dəqiqə dayanmasının kosmik qiyməti olduğu yerdə bu proseslər yetərli olmur. Maliyyə tranzaksiyaları sərt SLA altında həyata keçiriləndə nə etmək lazımdır? Sistemlərinizin etibarlılığını və dayanıqlığını necə artırmaq olar, inkişaf və testdən kənar qaldığınızda?
Növbəti HighLoad++ konfransı 2020-ci ilin 6 və 7 aprelində Sankt-Peterburqda keçiriləcək. Ətraflı məlumat və biletlər üçün . 9 noyabr, saat 18:00. HighLoad++ Moscow 2018, "Deli + Kalkutta" zalı. Tezis və .
Yevgeniy Kuzovlev (daha sonra - YK): – Dostlar, salam! Mənim adım Kuzovlev Yevgeniy. EcommPay-dənəm, konkret bölmə – EcommPay IT, qrupun IT bölməsi. Bugün sizinlə dayanma vaxtları haqqında danışacağıq - onlardan necə qaçmaq olar, necə minimalizasiya etmək olar, əgər qaçmaq mümkün deyilsə. Temamız belədir: "Bir dəqiqə dayanma qiyməti 100,000 dollar olanda nə etməliyik"? Bizim, əvvəlcədən, rəqəmlərimiz müqayisə olunandır.
EcommPay IT nə ilə məşğuldur?
Biz kimik? Niyə burada dayanmışam? Sizə burada nəyi danışmağa haqqım var? Burada daha detallı nədən danışacağıq?
EcommPay qrup şirkətləri – beynəlxalq acquire-dir. Biz dünyada - Rusiyada, Avropada, Cənub-Şərqi Asiyada (All Around the World) ödənişləri işləyirik. Bizim 9 ofisimiz, 500 işçimiz var, onlardan təxminən yarısı IT mütəxəssisləridir. Etdiyimiz hər şey, qazandığımız pullar üçün etdiyimiz hər şey, özümüz tərəfindən yaradılıb.
Bütün məhsullarımız (onları kifayət qədər çoxdur - geniş IT məhsulları xəttində təxminən 16 müxtəlif komponentimiz var) özümüz tərəfindən yazılıb; özümüz yazırıq, özümüz inkişaf etdiririk. Hazırda gündə təxminən bir milyon tranzaksiya keçiririk (milyonlar – bəlkə, belə demək daha doğrudur). Biz gənc bir şirkətik - yalnız altı yaşımız var.
6 il əvvəl bu bir startap idi, iş adamları ilə birlikdə gəliblər. Onlar bir ideya ilə birləşdirilmişdilər (başqa heç nə yox idi, yalnız ideya), və başladıq. Hər bir startapda olduğu kimi, biz daha sürətlə irəlilədik... Bizim üçün sürət daha vacib idi, keyfiyyət yox.
Bir anlıq dayandıq: anladıq ki, artıq bu sürətlə və keyfiyyətlə yaşaya bilmirik, keyfiyyətə diqqət yetirməliyik. Bu an yeni, düzgün, miqyaslana bilən, etibarlı bir platforma yazmaq qərarına gəldik. Bu platformanı yazmağa başladıq (inkişafa, test etməyə qoymağa başladıq), lakin bir müddət sonra anladıq ki, inkişaf və test yeni xidmət keyfiyyətinə keçməyə imkan vermir.
Yeni bir ürün geliştiriyorsunuz, onu üretime sunuyorsunuz, ancak her an bir terslik olabilir. Bugün, yeni bir kaliteli seviyeye nasıl ulaşacağımızı, geliştirme ve test aşamalarını bir kenara bırakarak, deneyimlerimiz üzerinden konuşacağız; kullanımda nelerin mevcut olduğuna ve mevcut olanın kaliteyi nasıl etkileyebileceğine değineceğiz.
Downtime. Kullanım ilkeleri.
Bugün bahsedeceğimiz temel taşlardan biri downtime, yani kesinti. Korkutucu bir kelime. Eğer bir kesinti yaşarsak, her şey kötüye gider. Hemen müdahale ediyoruz, sistem yöneticileri sunucuyu ayakta tutuyor; inşallah düşmez, dediği gibi şarkıda. İşte bugünkü konumuz bu.
Yaklaşımlarımızı değiştirmeye başladığımızda, dört ilke oluşturduk. Bunlar slaytlarda bizimle beraber.
Bu ilkeler oldukça basit:
- Sorunu hızlıca tespit et.
- Sorundan daha hızlı kurtul.
- Nedeni anlamada yardımcı ol (sonrasında, geliştiricilere).
- Ve yaklaşımları standart hale getir.
2. maddeye dikkat çekmek istiyorum. Sorunu ortadan kaldırıyoruz, çözmüyoruz. Çözümlemek ikincil. Bizim için öncelikli olan, kullanıcının bu sorunla karşılaşmamasıdır. Sorun, izole bir ortamda var olacaktır, ama bu ortam, kullanıcıyla hiçbir şekilde etkileşimde bulunmayacak. Aslında, bu dört sorun grubunu (bazılarını daha ayrıntılı, bazılarını daha az ayrıntılı) geçeceğiz ve kullandığımız yöntemlerden, çözümlerimizle ilgili deneyimlerimizi paylaşacağım.
Sorun giderme: Ne zaman meydana gelirler ve ne yapmalıyız?
Ancak sırayla başlamayalım, 2. maddeden başlayalım – sorunu hızlıca nasıl ortadan kaldırabiliriz? Bir sorun var – bunu çözmeliyiz. "Bununla ne yapmalıyız?" – temel soru. Sorunu ortadan kaldırmaya odaklandığımızda, bunun için bazı gereksinimler geliştirdik.
Bu gereksinimleri tanımlamak için kendimize şu soruyu sorduk: "Ne zaman sorunlar yaşıyoruz?" Problemlerin, dört durumda ortaya çıktığı anlaşıldı:
- Donanım arızası.
- Dış hizmetlerdeki aksaklık.
- Yazılım versiyonu değişikliği (o meşhur dağıtım).
- Yükte patlayıcı bir artış.
İlk iki konuda konuşmayacağız. Donanım arızası oldukça basit bir şekilde çözülür: her şey yedeklenmiş olmalıdır. Eğer disklerse, diskler RAID’de toplanmalıdır, eğer sunucuysa, sunucu yedeklenmelidir. Eğer ağ altyapınız varsa, ikinci bir kopyasını kurmalısınız; yani alıp yedekleme yapmalısınız. Ve eğer bir şey arızalanırsa, yedek güçlere geçersiniz. Burada söylemek zor bir şey değil.
İkincisi – xarici xidmətlərin çöküşüdür. Çoxları üçün bu sistem problemi deyil, lakin bizim üçün belə deyil. Biz ödənişləri işlədərək, müştəri (kart məlumatlarını daxil edən) və banklar, ödəniş sistemləri («Visa», «MasterCard», «Mir») arasında duran bir agregatoruq. Xarici xidmətlərimiz (ödəniş sistemləri, banklar) çöküş üçün meyllidir. Bunun üçün nə biz, nə də siz (əgər sizin belə xidmətləriniz varsa) təsir edə bilmirik.
Onda nə etməliyik? Burada iki seçim var. Birincisi, əgər edə bilirsinizsə, bu xidməti hər hansı şəkildə təkrarlamalısınız. Məsələn, əgər edə bilsək, biz bir xidmətdən digərinə trafik yönləndiririk: məsələn, «Sberbank» vasitəsi ilə kartları işlədirdik, «Sberbank»da problemlər var – trafikimizi [şərti olaraq] «Raiffeisen»ə yönləndiririk. İkincisi, xarici xidmətlərin çöküşünü çox sürətli şəkildə aşkar etməyi bacarırıq və bu səbəbdən reaksiyanın sürətindən növbəti hissədə danışacağıq.
Faktiki olaraq bu dörd problemdən yalnız birinin versiyalarının dəyişdirilməsinə konkret şəkildə təsir edə bilərik – vəziyyəti yaxşılaşdıran hərəkətlər edə bilərik kontekstdə yerləşdirilmələr və artan yükün kontekstində. Əslində, biz bunu etdik. Burada, yenə də, kiçik bir qeyd…
Bu dörd problemdən bir neçəsi bir anda həll olunur, əgər bulud sisteminiz varsa. Əgər siz «Microsoft Azure», «Ozon» buludlarında yerləşirsinizsə, bizim «Yandex» və ya «Mail.ru» buludlarını istifadə edirsinizsə, o zaman ən azı avadanlıq nasazlığı onların problemi olur və siz dərhal avadanlıq nasazlığı kontekstində hər şeyin yaxşılaşmasını görürsünüz.
Biz – bir az qeyri-standart şirkətik. Burada hər kəs «Kubernetes»dən, buludlardan danışır – bizim isə nə «Kubernetes», nə də buludlar var. Lakin bizim bir çox data mərkəzlərində avadanlıqları olan rəflərimiz var, və bu avadanlıqlarla yaşamağa məcburuq, biz bunun hamısına cavabdehik. Buna görə də bu kontekstdə danışacağıq. Beləliklə, problemlərə keçək. İlk iki problemi nəzərə almadıq.
Proqram təminatının versiyasının dəyişdirilməsi. Bazalar
Bizim inkişaf etdiricilərimizin istehsal mühitinə giriş icazəsi yoxdur. Niyə belədir? Çünki biz PCI DSS üzrə sertifikatlaşdırılmışıq və inkişaf etdiricilərimizin «prod»a giriş icazəsi yoxdur. Həmin bu. Tamamilə. Buna görə də inkişafın məsuliyyəti məhz inkişafın buildu buraxılış üçün verdiği anda bitir.
İkinci bazamız, bizim bir problemi daha asan həll etməyimizə kömək edən – xüsusi qeydə alınmamış biliklərin olmamasıdır. Ümid edirəm ki, sizdə də belədir. Çünki, əgər belə deyilsə – probleminiz olacaq. Problemlər o zaman yaranacaq ki, bu unikal qeydə alınmamış biliklər lazım olan vaxtda lazım olan yerdə olmayacaq. Tutaq ki, bir nəfər spesifik komponentin yerləşdirilməsi qaydasını bilir – o insan yoxdur, istirahətdədir və ya xəstədir – bütün, probleminiz var.
Və biz gəldiyimiz üçüncü əsas. Biz buna ağrı, qan, gözyaşları ilə gəldik – biz anladıq ki, hər bir sistemimizdə səhvlər var, hətta o, səhvsizdirsə də. Biz özümüz üçün belə qərara gəldik: bir şey göndərdikdə, istehsala çıxardığımızda – bizim sistemimizdə həmişə səhvlər var. Biz sistemimizin yerinə yetirməli olduğu tələbləri müəyyən etdik.
Proqram təminatının versiyasını dəyişdirmək üçün tələblər
Bu tələblər üçdür:
- Biz sürətlə göndərimi geri çevirə bilmirik.
- Biz uğursuz göndərimin təsirini minimuma endirməliyik.
- Və biz eyni zamanda tez bir zamanda yeni versiyanı yayımlaya bilməliyik.
Tam olaraq belə bir sıraya! Niyə? Çünki, ilk növbədə, yeni versiyanı yayımlarkən sürət əhəmiyyətli deyil, ancaq əgər hər şey səhv olarsa, verməyi sürətlə geri çevirmək və minimum təsir göstərmək vacibdir. Ancaq əgər istehsalda bir sıra versiyalar varsa və orada bir səhv aşkar olunubsa (heç olmasa, göndərilmə olmadı, amma səhv var) – onda bizə sonrakı göndərmə sürəti vacibdir. Biz bu tələbləri yerinə yetirmək üçün nə etdik? Belə bir metodologiyaya müraciət etdik:
Bu, kifayət qədər tanındır, biz heç bir şey icad etmədik – bu, Blue/Green göndərməsidir. Bu nə deməkdir? Hər bir server qrupuna, tətbiqlərinizin olduğu serverlər üçün bir nüsxə olmalıdır. "İsti" bir nüsxə: onun üzərində trafik yoxdur, lakin istənilən an bu trafik bu nüsxəyə yönəldilə bilər. Bu nüsxə əvvəlki versiyanı ehtiva edir. Və göndərim vaxtı kodu aktiv olmayan nüsxəyə yayırıq. Sonra ya bütün trafik, ya da bir hissəsini yeni versiyaya yönləndirirsiniz. Beləliklə, köhnə versiyadan yeni versiyaya trafik axınını dəyişmək üçün yalnız bir tədbir görmək lazımdır: yuxarı axında balanslaşdırıcıyı dəyişməli, istiqaməti – bir yuxarı axından digərinə dəyişdirməlisiniz. Bu, çox rahatdır və sürətli keçid, sürətli geri dönüş problemi həll edir.Burada ikincil sualın – minimallaşdırmanın həlli də var: siz yeni xəttə, yeni kod xəttinə yalnız trafikinizin bir hissəsini (məsələn, 2%) yönləndirə bilərsiniz. Və bu 2% - 100% deyil! Əgər siz uğursuz göndərimdə 100% trafik itirmisinizsə – bu dəhşətdir, əgər siz 2% trafik itirmişsinizsə – bu narahatdır, lakin bu dəhşət deyil. Məlum olan, istifadəçilər bunu, ehtimal ki, başa düşməyəcəklər, çünki bəzi hallarda (hamısında deyil) eyni istifadəçi, F5 düyməsi ilə, işləyən digər versiyaya düşəcək.
Blue/Green göndərmə. Yönləndirmə
Bu arada, "Blue/Green göndərmə" o qədər də sadə deyil... Bütün komponentlərimizi üç qrupa ayıra bilərik:
- bunlar ön tərəfdir (müştərilərimizin gördüyü ödəmə səhifələri);
- emal mərkəzi;
- ödəmə sistemləri ilə işləmək üçün adapter (banklar, "MasterCard", "Visa"...)
Və burada bir nüans var - nüans xətlərin arasındakı yönləndirmə ilə bağlıdır. Əgər siz sadəcə 100% trafikə keçid etsəniz, bu problemlərlə qarşılaşmazsınız. Ancaq 2%-i keçirmək istəsəniz, suallar yaranır: «Bunu necə edim?» Ən sadə variant, açıq şəkildə: təsadüfi seçim edə bilərsiniz, nginx-də Round Robin qura bilərsiniz, və 2% - solda, 98% - sağda olacaq. Ancaq bu hər zaman uyğun olmur.
Bizim sistemdə, məsələn, istifadəçi sistemi bir sorğu ilə deyil, birdən çox sorğu ilə qarşılıqlı fəaliyyət göstərir. Bu düzgündür: 2, 3, 4, 5 sorğu – sizin sistemləriniz də belə ola bilər. Və əgər sizin üçün önəmli olarsa ki, istifadəçinin bütün sorğuları eyni xətə, ilk sorğunun gələndən sonra gəlsin, ya da (ikinci nöqtə) istifadəçilərinizin bütün sorğuları keçid edildikdən sonra yeni çizgiyə gəlsin (işə başlamış ola bilərlər), - bu halda təsadüfi bölüşdürmə sizin üçün uyğun deyil. Onda sizdə aşağıdakı variantlar var:
Birinci variant, ən sadə – müştərinin əsas parametrləri əsasında (IP Hash). Sizin IP-niz var, və siz IP-nə əsaslanaraq sağa-sola bölüşdürürsünüz. O zaman sizin mənim təsvir etdiyim ikinci hal işləyəcək, istifadəçi artıq sizin sisteminizlə işləməyə başlamışdı, və yerləşdirmədən sonra bütün sorğular yeni xətə (eyni xəttə, deyək ki) yönləndiriləcək.Əgər bu sizə hansısa səbəblərə görə uyğun deyilsə və mütləq ilkin istifadəçi sorğusunun keçdiyi xəttə yönləndirmək lazımdırsa, onda sizin iki variantınız var...
Birinci variant: siz pullu nginx+-ı götürə bilərsiniz. Orada Sticky sessions mexanizmi var, bu ilkin istifadəçi sorğusu zamanı istifadəçiyə bir sessiya təyin edir və onu həmin yanlara bağlayır. İstifadəçinin sessiyanin ömrü ərzində gələ biləcək bütün sorğuları həmin yanlara yönləndiriləcək.Bu bizə uyğun gəlmədi, çünki bizim artıq adi nginx var idi. Nginx+-a keçmək, baha deyil, sadəcə bizə bir az ağrılı və çox düzgün görünmürdü. Məsələn, bizim üçün «Sticky sessions» işləmədi, çünki «Sticky sessions» «Ya yaxud-da» meyarına görə yönləndirməyə imkan vermir. Orada müəyyən edə bilirsiniz ki, «Sticky sessions» ya IP-yə, ya IP-yə və çərəzlərə, ya da post parametrinə əsaslanır, ancaq «Ya yaxud-da» olduğunda artıq çətindi.
Buna görə biz dördüncü variantdan istifadə etməyə qərar verdik. Biz nginx-i «steroidlərdə» (bu openresty-dir) götürdük - bu, əsas nginx-dir, lakin əlavə olaraq son skriptlərin daxil edilməsini dəstəkləyir. Siz son skript yaza bilər, bu «openresty»-ə təqdim edə bilərsiniz, və bu son skript istifadəçi sorğusu gələndə icra olunacaq.
Və biz, əslində, belə bir skript yazdıq, özümüzə "openresty" quraşdırdıq və bu skriptdə "Və ya" ilə 6 fərqli parametrin kombinasiya edilməsi ilə işləyirik. Müxtəlif parametrlərin mövcudluğuna əsasən, istifadəçinin hansı səhifəyə gəldiyini, hansı xətə gəldiyini bilirik.
Blue/Green dağıtımı. Üstünlükləri və çatışmazlıqları
Əlbəttə, bəlkə də, bir az daha sadə etmək olardı (məsələn, eyni "Sticky sessions" istifadə etməklə), lakin bizim üçün belə bir nüans da var ki, yalnız istifadəçi bizimlə bir tranzaksiyanın emalında qarşılıqlı əlaqədə deyil... Eyni zamanda, ödəniş sistemləri ilə də qarşılıqlı əlaqə var: biz tranzaksiyanı emal etdikdən sonra (ödəniş sisteminə sorğu göndərdikdən sonra) geridönmə alırıq.
Və farz edək ki, bizim kontur içində istifadəçinin IP adresini bütün sorğularda ötürə bilsək və IP adresinə əsaslanaraq bölə bilsək, o zaman biz "Visa"ya deməyəcəyik: "Dostlar, biz həqiqətən retro bir şirkətik, beynəlxalqıq (saytımızda və Rusiyada)... Bütün bunlarla birlikdə, zəhmət olmasa, istifadəçinin IP adresini əlavə bir sahədə verin, sizin standart protokolunuzdur!". Aydındır ki, onlar razılaşmayacaqlar.
Buna görə də bu bizim üçün uyğun olmadı - biz openresty etdik. Buna görə də, routingimiz belə oldu:"Blue/Green dağıtımı"nın müvafiq üstünlükləri var, dediyim kimi, və çatışmazlıqları.
İki çatışmazlıq var:
- siz routing ilə məşğul olmalısınız;
- ikinci əsas çatışmazlıq - xərclərdir.
Siz iki dəfə daha çox serverə ehtiyac duyursunuz, sizə iki dəfə daha çox əməliyat resursları lazımdır, bütün bu heyvanat bağını saxlamaq üçün iki dəfə daha çox enerji sərf etməlisiniz.
Qeyd edim ki, üstünlüklər arasında – bir şey daha var, bunun haqqında əvvəllər danışmamışdım: yük artımı halında rezerviniz var. Yükünüz partlayıcı şəkildə artarsa, çoxsaylı istifadəçilər sizə hücum edərsə, siz sadəcə ikinci xətləri 50-yə 50 bölüşdürürsünüz - və eyni anda clusterinizdə 2 dəfə daha çox serveriniz olur, problemi həll edənə qədər.
Sürətli dağıtımı necə etmək olar?
Biz minimallaşdırma və sürətli geri dönmə problemini necə həll etdiyimizi danışdıq, amma sual qalır: "Sürətli necə dağıtmalıyıq"?
Burada qısa və hər şey sadədir.- Sizin CD sistemi (Continuous Delivery) olmalıdır - onsuz heç yerdə mümkün deyil. Əgər bir serveriniz varsa, əllə dağıda bilərsiniz. Bizdə təxminən min beş yüz server var və əllə beş yüzü, aydın məsələdir - biz bu zal qədər bir şöbəni sadəcə dağıtmaq üçün yığa bilərik.
- Dağıtım paralel olmalıdır. Əgər dövriyyə ardıcıl olarsa, hər şey pisdir. Bir server - normaldır, min beş yüz serveri bir gün ərzində dağıtdığınız zaman.
- Yenə də, sürətləndirmək üçün, bəlkə, bu artıq lazım deyil. Dağıtma zamanı adətən layihə yığılıb hazırlanır. Sizdə web layihəsi var, front-end hissəsi var (oradakı web paketi, npm yığma – nəsə belə), və bu proses əsasən uzun sürmür – 5 dəqiqə, amma bu 5 dəqiqə kritik ola bilər. Buna görə biz, məsələn, bunu etməyin: bu 5 dəqiqəni aradan qaldırdıq, artefaktları yayımlayırıq.
Artefakt nədir? Artefakt – bütün yığma hissəsini tamamlayan bir yığımdır. Bu artefaktı artefakt anbarında saxlayırıq. Belə anbarlardan iki ədəd istifadə etdik – biri Nexus, hal-hazırda isə jFrog Artifactory. "Nexus"-u ilkin olaraq istifadə etmişdik, çünki bu yanaşmanı Java proqramlarında praktika etməyə başlamışdıq (o, buna yaxşı uyğundur). Sonra oraya PHP-də yazılmış bəzi tətbiqetmələri də əlavə etdik; və "Nexus" artıq uyğun gəlmirdi, buna görə də jFrog Artifactory-ni seçdik, hansı ki, demək olar ki, hər şeyi artefakt edir. Hətta bu artefakt anbarında serverlər üçün yığdığımız öz binar paketlərimizi də saxlayırıq.
Partlayıcı yük artımı
Soya proqram versiyasını dəyişməkdən danışdıq. İndi bizim üçün olan şey – partlayıcı yük artımı. Burada, yəqin ki, partlayıcı yük artımını tam olaraq düzgün başa düşmürəm...
Biz yeni bir sistem yaratdıq – xidmət yönümlüdür, dəbdəbəli və gözəl, hər yerdə işçilər, hər yerdə növbələr, hər yerdə asinxronluq. Belə sistemlərdə məlumatlar müxtəlif axınlar üzrə gedə bilir. İlk tranzaksiya üçün 1-ci, 3-cü, 10-cu işçi, ikinci tranzaksiya üçün isə 2-ci, 4-cü, 5-ci işçi istifadə oluna bilər. Bu gün, məsələn, səhər sizin üç işçi ilə məlumat axını gedir, amma axşam birdən dəyişir və hamısı başqa üç işçini işə salır.
Və burada belə olur ki, siz işçiləri necəsa yaymalısınız, xidmətlərinizi necəsa yaymalısınız, amma eyni zamanda resursların şişməsinə imkan verməməlisiniz.
Biz tələblərimizi müəyyən etdik. Bu tələblər kifayət qədər sadədir: orada xidmət aşkar etmə, parametrizə olunma olmalıdır – bunlar belə ölçülə bilən sistemlərin qurulması üçün standartdır, bir şərtlə – bu, resurs amortizasiyasıdır. Biz dedik ki, resursların amortizasiyasına hazır deyilik ki, serverlər boş yer qızdırsın. Biz "Consul"-u, "Nomad"-ı götürdük ki, bu da işçilərimizi idarə edir.Niyə bu bizim üçün problemdir? Gəlin bir az geri dönək. İndi arxamızda təxminən 70 ödəmə sistemi var. Səhər trafik «Sberbank» vasitəsilə gedir, sonra «Sberbank»ın nasaz olması halında, məsələn, onu başqa bir ödəmə sisteminə yönləndiririk. «Sberbank»a qədər 100 işçi çalışırdı, lakin sonra biz digər ödəmə sisteminə görə 100 işçini birdən artırmalıyıq. Və bütün bunların insan iştirakı olmadan baş verməsi arzu edilir. Çünki insan iştirakı olarsa, 24/7 mühəndis oturmalı və yalnız bu işlə məşğul olmalıdır, çünki arxanızda 70 sistem olduğu zaman belə qırılmalar mütəmadi olaraq baş verir.
Buna görə də, açıq IP-si olan «Nomad»a baxdıq və özümüzün Scale-Nomad - ScaleNo adlı bir sistem yaraddıq, bu sistem aşağıdakı kimi işləyir: sıralanmanın böyüməsini izləyir və işçi sayını sıra dinamikasına uyğun olaraq artırır və ya azaldır. Yarandıqda düşündük: «Bunu açıq mənbəyə köçürək?» Sonra ona baxdıq - o, iki qəpik qədər sadədir.
Hələlik açıq mənbəyə keçməmişik, amma əgər konfransdan sonra, bu cür bir şeyə ehtiyacınızın olduğunu başa düşdükdən sonra, onun üçün ehtiyac yaranarsa, son slaydda mənim əlaqə məlumatlarım var - xahiş edirəm mənə yazın. Əgər ən azı 3-5 nəfər toplanarsa – biz bunu açıq mənbəyə köçürəcəyik.
Bu necə işləyir? Gəlin baxaq! İrəlidən xəbərləri: sol tərəfdə monitorinqimizin bir hissəsi var: bu bir xəttdir, yuxarıda – hadisələrin emal vaxtı, ortada – əməliyyatların sayı, aşağıda – işçilərin sayı.Əgər bu şəkilə baxsaq, orada bir qırılma var. Yuxarıdakı qrafikdə 45 saniyə ərzində bir qrafik düşdü – biri ödəmə sistemlərindən çıxış etdi. Burada 2 dəqiqə ərzində trafik göstərildi və başqa bir ödəmə sistemində, işçilərin olmadığı yerdə, sıra artmağa başladı (biz resursları düzgün işlətmədik – əksinə, resursları düzgün istifadə etdik). Biz istəmədik ki, sistem qızsın – orada minimal sayda, təxminən 5-10 işçi var idi, lakin onlar öhdəsindən gələ bilmədilər.
Son qrafikdə görünən «şiş» dəqiq olaraq göstərir ki, «Sqaleno» bu sayı iki dəfə artırdı. Və sonra, qrafik bir az aşağı düşdükdə, o, bir az azaltdı – işçi sayı avtomatik rejimdə dəyişdirildi. Beləliklə, bu sistem işləyir. 2-ci bənd haqqında danışdıq - «Səbəbləri necə tez aradan qaldırmaq olar».
Monitorinq. Problemi necə tez tapmaq olar?
İndi birinci bənd – «Problemi necə tez tapmaq olar?» Monitorinq! Biz müəyyən şeyləri tez başa düşməliyik. Hansı şeyləri tez başa düşməliyik?
Üç şey!- Biz öz resurslarımızın işləkliyini tez başa düşməliyik.
- Biz sistemlərin, bizim üçün xarici olanların, nasazlığını tez başa düşməli və onların işləkliyini monitorinq etməliyik.
- Üçüncü nöqtə - məntiqi xətaların aşkarlanması. Sistem bütün göstəricilər baxımından düzgün işləyir, amma bir şey düzgün getmir.
Burada, bəlkə də, çox maraqlı bir şey danışmayacağam. Bütün bunların kapitanı olduğumu hiss edirəm. Bazar haqqında araşdırma apardıq. Bizim "şən zoopark"ımız yaranıb. İndi belə bir zooparkımız var:
Biz "Zabbix"i "hardware" monitoringi üçün, serverlərin əsas göstəricilərinin monitorinqi üçün istifadə edirik. "Okmeter"i bazalar üçün istifadə edirik. "Grafana" və "Prometheus"u qalan göstəricilər üçün istifadə edirik, hansılar ki, birincil iki üçün uyğun gəlmir, bir hissəsi - "Grafana" ilə "Prometheus", digər hissəsi - "Grafana" ilə "Influx" və Telegraf.Bir il əvvəl, New Relic-dən istifadə etmək istədik. Çox gözəl bir şeydir, hər şeyi edə bilir. Amma nə qədər hər şeyi edə bilirsə, bir o qədər də bahadır. 1500 server həcminə çatanda, bizə bir satıcı gəldi, dedi: "Gəlin, gələn il üçün müqavilə bağlayaq." Biz qiymətə baxdıq və dedik ki, yox, belə etməliyik. İndi "New Relic"dən imtina edirik, bizdə "New Relic" monitorinqində təxminən 15 server qalıb. Qiymət tamamilə dəhşətli oldu.
Və bir alət var ki, biz onu özümüz inkişaf etdirmişik – bu, Debugger-dir. Əvvəlcə biz onu "Bugger" adlandırdıq, amma sonra ingilis dili müəllimimiz gəldi, gülməkdən yerlərdə yuvarlandı və onu "Debugger" adlandırdıq. Bu nədir? Bu, əslində 15-30 saniyə ərzində hər bir komponentdə, sistemin "qara qutusu" kimi, komponentin ümumi işləkliyini sınaqdan keçirən bir alətdir.
Məsələn, əgər xarici səhifə (ödəmə səhifəsi) varsa - o sadəcə onu açır və necə görünməsi lazım olduğunu yoxlayır. Əgər bu bir prosessingdirsə, o, test tranzaksiyasını yerinə yetirir – bu "tranzaka"nın uğurla yerinə yetirildiyinə baxır. Əgər ödəniş sistemləri ilə əlaqədirsə - uyğun olaraq test sorğusunu göndəririk və hər şeyin qaydasında olub-olmadığına baxırıq.
Monitorinq üçün hansı göstəricilər önəmlidir?
Biz əsasən nəyi monitorinq edirik? Bizim üçün hansı göstəricilər önəmlidir?
- Cavab vaxtı / RPS ön hissələrdə - çox önəmli bir göstəricidir. Bu, dərhal sizdə nəyinsə səhv olduğunu bildirir.
- Bütün növbələrdə emal olunan mesajların sayı.
- Worker-ların sayı.
- Düzgünlüyü təmin edən əsas metrikalar.
Son nöqtə - "biznes" göstəricisi. Əgər siz eyni şeyi monitorinq etmək istəyirsinizsə, sizə bir və ya iki əsas mətrikanı müəyyənləşdirmək lazımdır ki, onlar sizin üçün əsas göstəricilər hesab olunsun. Bizim belə bir göstəricimiz var - bu, keçidlikdir (uğurlu tranzaksiyaların ümumi tranzaksiyalar axınlarına olan nisbətidir). Əgər bu göstəricidə 5-10-15 dəqiqə ərzində nələrsə dəyişirsə - deməli, bizdə problemlər var (gərgin dəyişirsə).
Bu necə görünür - bizim panellərimizdən birinin nümunəsi:
Sol tərəfdə - 6 qrafik var, bu da xətlərin sayını - işçilərin sayı və gözləmə növbələrindəki mesajların sayı göstərir. Sağa isə - RPS, RTS. Aşağıda - məhz o biznes göstəricisi var. Və biznes göstəricisində dərhal görünür ki, iki orta qrafikdə bir şey yanlış gedir... Bu, arxamızda olan sistemin birinin çökməsidir.İkinci etməli olduğumuz şey - xarici ödəniş sistemlərinin çökməsini izləmək idi. Burada OpenTracing götürdük - bu, paylanmış sistemləri izləməyə imkan verən bir mexanizm, standart, paradigma; və bunu bir az dəyişdirdik. Standart OpenTracing-paradigması deyir ki, biz hər bir ayrı sorğunun izini çəkirik. Bu, lazım deyildi, ona görə də bunu cəm izləminə, agregasiyaya çevirərək etdik. Bizə arxamızda olan sistemlərin sürətini izləməyə imkan verən bir alət yaratdıq.
Qrafik bizə göstərir ki, bir ödəniş sistemi 3 saniyəyə cavab verməyə başladı - bizdə problemlər yarandı. Bu arada, bu şey problem başlayanda 20-30 saniyəlik intervalda reaksiya verəcək.Və monitorinqin üçüncü sinfi səhvləri var - bu, məntiqi monitorinqdir.
Həqiqətən, bu slaydda nə çəkəcəyimi bilmir idim, çünki bazarda bizim üçün uyğun olanı uzun müddət axtardıq. Heç nə tapa bilmədik, buna görə də özümüz etməyə məcbur olduq.
Mən məntiqi monitorinq dedikdə nəyi nəzərdə tuturam? Yaxşı düşünün: siz özünüz üçün bir sistem yaradırsınız (məsələn, Tinder-in klonu); onu hazırlayıb işə saldınız. Uğurlu menecer Vasya Pupkin onu telefonuna qoyur, orada qız görür, ona bəyənmə (like) düyməsini sıxır... ancaq bəyənmə qızı deyil, bu eyni biznes mərkəzindəki mühafizəçi Mixayl üçün gedir. Menecer aşağı düşür və sonra düşünür: "Niyə bu mühafizəçi Mixayl ona bu qədər xoş gülür?"Belə situasiyalarda... Bizim üçün bu vəziyyət bir az fərqli səslənir, çünki (mən yazmışdım) bu, dolayısıyla maliyyə itkilərinə səbəb olan reputasiya itkisidir. Bizim vəziyyətimiz tərsdir: biz birbaşa maliyyə itkiləri yaşaya bilərik - məsələn, əgər bir əməliyyatı uğurlu olaraq keçirtdiksə, amma o uğursuz olub (ya da əksinə). Öz biznes göstəricilərimizə görə uğurlu əməliyyatların sayını dinamik şəkildə izləməyə imkan verən bir alət yazmalı olduq. Bazarda heç nə tapa bilmədik! Mən məhz bu düşüncəni çatdırmaq istədim. Belə əməkdaşlıq məsələlərinə bazarda heç bir şey yoxdur.
Bu, problemi necə tez aşkar etmək haqqında olan suala cavabdır.
Deplonun səbəblərini necə müəyyən etmək olar
Həll etdiyimiz üçüncü tapşırıqlar qrupu - bu, problemi müəyyən etdikdən sonra, ondan qurtulduqdan sonra, inkişaf etdirmək, test etmək və bununla bağlı bir şey etmək üçün səbəbləri anlamaq lazımdır. Buna görə də biz araşdırmalıyıq, logları toplamalıyıq.
Məlumatları güncəllədiyimiz zaman, loglardan (əsas səbəb loglardır) ELK Stack-də logların əksəriyyəti - demək olar ki, hamı üçün eynidir. Bəziləri ELK-də olmaya bilər, amma əgər siz logları gigabaytlarla yazırsınızsa, bir zaman gələcək mütləq ELK-yə keçəcəksiniz. Biz onları terabaytlarla yazırıq.
Burada bir problem var. Biz istifadəçi üçün bir xətanı düzəltdik, nə olduğunu açmağa başladıq, "Kibana"-ya daxil olduq, orada əməliyyatın id-sini daxil etdik və belə bir nəticə əldə etdik (çox şey göstərir). Və bu nəticədə dəqiq heç nə başa düşülmür. Niyə? Çünki hansı hissənin hansı işçi ilə bağlı olduğu, hansı hissənin hansı komponentlə bağlı olduğu aydın deyil. Və bu an biz başa düşdük ki, bizə izləmə lazımdır - açıqladığım o OpenTracing.Bir il əvvəl bunu düşündük, bazara nəzər saldıq və orada iki alət var idi - "Zipkin" və "Jaeger". "Jaeger" əslində "Zipkin"-in ideoloji varisidir. "Zipkin"-də hər şey yaxşıdır, yalnız o, logları yığmaq üçün və vaxt izləməsini birgə istifadə etməyə uyğun deyil. Amma "Jaeger" bunu dəstəkləyir.
"Jaeger"-ə baxdıq: tətbiqləri alətləyə bilərik, API-yə yazmaq olur (PHP üçün standart API o dövrdə, əslində, hələ təsdiqlənməmişdi - bu bir il öncədir, amma indi təsdiqlənib), lakin əslində müştəri yox idi. "Yaxşı," - dedik, öz müştərimizi yazdıq. Nəticəmiz belə görünür:
"Jaeger"-də hər bir mesaj üçün span'lar yaradılır. Yəni, istifadəçi sistemə daxil olanda, o, hər giriş sorğusu üçün bir və ya iki blok görür (1-2-3 - istifadəçidən olan giriş sorğularının sayı qədər blok var). İstifadəçilərin işini asanlaşdırmaq məqsədilə loglara və zaman izləməsinə etiketlər əlavə etdik. Nəticədə, xətanın baş verdiyi halda, tətbiqimiz logu müvafiq Error etiketi ilə işarələyəcək. Error etiketinə görə filtr eləyə bilərik və yalnız bu xətanı əks etdirən span'lar çıxacaq. Span açdığımızda bunu belə görürük:
Span daxilində bir sıra izlər var. Bu halda, üç test izimiz var və üçüncü iz bizə xətanın baş verdiyini bildirir. Eyni zamanda burada zaman izləməsini də görürük: yuxarıda - zaman cədvəli var və biz həmin logun hansı zaman aralığında yazıldığını görürük.Müvafiq olaraq, uğurlu oldu. Öz genişləndirməmizi yazdıq və onu açıq qaynaq etdik. Əgər siz izləmə ilə işləmək istəyirsinizsə, əgər siz PHP-də "Jaeger" ilə işləmək istəyirsinizsə - bizim genişləndirməmiz var, istifadə etməyə dəvət edirik.
Bizim bu genişlənməmiz OpenTracing API üçün müştəri, php-extention kimi hazırlanmışdır; yəni bunu toplamağınız və sistemə əlavə etməyiniz lazım olacaq. Bir il əvvəl başqa heç nə yox idi. İndi isə komponent kimi digər müştərilər də ortaya çıxdı. Buradakı seçim sizindir: ya komponetləri composer ilə yükləyirsiniz, ya da genişlənmədən istifadə edirsiniz, bu sizin ixtiyarınızdadır.Korporativ standartlar
Üç əmr haqqında danışdıq. Dördüncü əmr – yanaşmaları standartlaşdırmaq. Bu nə deməkdir? Bu təxminən budur:
Niyə burada «korporativ» sözü var? Biz böyük və ya bürokratik bir şirkət olduğumuz üçün deyil, yoxsa! «Korporativ» sözünü burada istifadə etmək istədim, çünki hər bir şirkət və hər bir məhsul üçün bu standartların özünə məxsus olması gərəkdir və sizdə də olmalıdır. Bizim hansı standartlarımız var?- Bizim nəqliyyat sənədimiz var. Bu olmadan heç yerə irəliləyə bilmirik, edə bilmirik. Həftədə təxminən 60 dəfə yayımlanırıq, yəni yayımlanmalarımız demək olar ki, davamlıdır. Bununla birlikdə, misal üçün, yayımlarımızda cümə günü yayımlama qadağası var – prinsipcə, biz yayımlamırıq.
- Bizdə sənədləşdirmə mütləqdir. Heç bir yeni komponent bizim istehsalımıza düşmür, əgər onun üçün sənəd yoxdur, hətta əgər bu bizim RnD mütəxəssislərimizin əlindən çıxıbsa. Biz onlardan yayımlama təlimatı, monitorinq xəritəsi və (bax, proqramçılar necə yaza bilər) bu komponentin necə işlədiyinə, necə troubleshoot ediləcəyinə dair təqribi bir açıqlama tələb edirik.
- Biz problemi deyil, problemlərin səbəbini həll edirik – artıq dediyim şey. Bizim üçün istifadəçini problemlərdən qorumaq vacibdir.
- Bizdə müəyyən parametrlər var. Məsələn, iki dəqiqə ərzində 2 % trafik itirsək, bunu texniki fasilət kimi qəbul etmirik. Bu, bizim statistikamıza daxil olmur. Əgər yüzdəlik və ya zaman baxımından daha çox olarsa, o zaman hesablayırıq.
- Və biz həmişə postmortemlər yazırıq. Nə baş verməsindən asılı olmayaraq, istehsalda qeyri-adi davranış nümayiş etdirən hər bir hadisə postmortemdə əks etdiriləcək. Postmortem – nə baş verdiyini, detallı zamanlamanı, düzəltmək üçün nə etdiyinizi və (bu mütləq bir blokdur!) gələcəkdə bunun baş verməməsi üçün nə edəcəyinizi yazdığınız bir sənəddir. Bu mütləqdir, sonrakı analizi üçün vacibdir.
Texniki fasilət nə hesab olunur?
Bu hər şey nəyə gətirib çıxardı?Bu, (bizim üçün müəyyən dayanıqlıq problemləri oldu, bu nə müştəriləri, nə də bizi qane etmirdi) son 6 ayda dayanıqlığımızın göstəricisi 99,97-nin tərkibindədir. Demək olar ki, bu, çox deyil. Bəli, hələ də irəliləməliyik. Bu göstəricidən təxminən yarısı – bizim web application firewallımızın dayanıqlığıdır ki, bu da bizim önümüzdədir və bir xidmət kimi istifadə olunur, lakin müştərilərə bu, fərq etməz.
Biz gecələri yatmağı öyrənmişik. Nəhayət ki! Altı ay əvvəl öyrənməmişdik. Və bu nəticələrdən bir qeyd etmək istəyirəm. Dünən axşam təsirli bir təqdimat oldu, nüvə reaktorunun idarəetmə sistemi haqqında. Əgər məni eşidən bu sistemi yazan insanlar varsa – xahiş edirəm, "2%-dıq, bu, dayandırma deyil" dediyimi unutmayın. Sizlər üçün 2% dayandırmadır, hətta iki dəqiqə olsa belə!
Bütün bunlar! Suallarınız var mı?
Balanslayıcılardan və verilənlər bazasından köçürmə
Auditoriyadan sual (əvvəl – S): – Salam. Belə bir idarəetmə təqdimatı üçün çox təşəkkür edirəm! Suallara qısa, balanslayıcılarınızla bağlı. Siz dediniz ki, sizdə WAF var, yəni, mən başa düşdüyümə görə, balanslayıcı kimi hansısa xarici bir sistemdən istifadə edirsiniz...
EK: – Xeyr, balanslayıcı kimi öz xidmətlərimizi istifadə edirik. Burada WAF bizim üçün yalnız DDoS-dan qorunma alətidir.
A: – Balanslayıcılar haqqında biraz danışa bilərsinizmi?
EK: – Daha əvvəl dediyim kimi, bu, openresty-dəki serverlər qrupudur. Hazırda 5 qruplaşıb, yalnız... yəni, openresty-nin olduğu server sadəcə trafiki yönləndirir. Beləliklə, nə qədər tutduğumuzu başa düşmək üçün: hal-hazırda standart trafik axınımız bir neçə yüz meqabitdir. Onlar buna idarə edir, hətta heç yorulmur.
A: – Yine də sadə bir sual. Blue/Green yerleşimi var. Bəs verilənlər bazasından köçürməyə nə edirsiniz?
EK: – Yaxşı sualdır! Baxın, Blue/Green yerleşimində hər bir xətt üçün ayrı növbələrimiz var. Yəni, işçi-dən işçiyə ötürülən hadisə növbələri varsa, orada blue-xətt və green-xətt üçün ayrı növbələr var. Verilənlər bazası ilə danışsaq, onu bilinçli şəkildə daraltdıq, demək olar ki, hər şeyi növbələrə köçürdük, verilənlər bazasında yalnız tranzaksiya yığını saxlanılır. Və tranzaksiya yığını hər xətt üçün eynidir. Verilənlər bazası kontekstində: biz onu blue və green arasında bölmürük, çünki hər iki kod variantı tranzaksiyaların nə olduğunu bilməlidir.
Dostlar, sizi motivasiya etmək üçün burada bir kiçik mükafat var – kitab. Və bu mükafatı ən yaxşı sual üçün təqdim etməliyəm.
A: – Salam. Təqdimat üçün təşəkkür edirəm. Sualım belədir. Siz ödənişləri izləyirsiniz, sizinlə əlaqə saxlayan xidmətləri izləyirsiniz... Amma siz necə izləyirsiniz ki, bir insan bir şəkildə sizin ödəniş səhifənizə düşüb, ödənişi edib və layihəyə pulunu köçürdü? Yəni, siz necə izləyirsiniz ki, merchant əlçatan olub və sizin callbackinizi qəbul edib?
EK: – Bizim üçün "merchant" burada ödəniş sistemi qədər xarici bir xidmət olaraq çıxış edir. Biz "merchant"ın cavab sürətini izləyirik.
Verilənlər bazasının şifrələnməsi haqqında
A: – Salam. Bir az yan sualım var. Sizdə PCI DSS üzrə həssas məlumatlar var. Maraqlıdır, siz növbələrdə PAN-ları necə saxlayırsınız ki, sizə ötürməyiniz lazım olur? Hər hansı bir şifrələmə istifadə edirsinizmi? Və buna bağlı ikinci sual: PCI DSS-ə əsasən dəyişikliklər baş verdikdə (administrativ şəxslərin işdən çıxması və s.) dövri olaraq verilənlərin yenidən şifrələnməsi zəruridir – bu halda əlçatanlıq necə olur?
EK: – Gözəl sualdır! İlk növbədə, biz növbələrdə PAN-ları saxlamırıq. Bizim açıq şəkildə PAN-ları harada isə saxlamağa hüququmuz yoxdur, buna görə xüsusi bir xidmət istifadə edirik (biz onu «Keydemon» adlandırırıq) – bu xidmət yalnız bir şeyi yerinə yetirir: o, daxil olan mesajı qəbul edir və şifrələnmiş mesajı təqdim edir. Biz də bu şifrələnmiş mesajla hər şeyimizi saxlayırıq. Buna uyğun olaraq, bizim açar uzunluğu bir kilobayt civarındadır ki, bu da ciddi və etibarlı olsun.A: – İndi artıq 2 kilobayt lazımdır?
EK: – Sanki dünən 256 idi… Haraya daha da istifadə edirsiniz?!
Buna görə də, bu birincisidir. İkincisi, mövcud olan həll proseduru yenidən şifrələməni dəstəkləyir – orada iki cüt «kek» (açar) var, hansı ki, «dek»lər verir, bunlar da şifrələyir (açar – bu açarlardır, dek – bu açarlardan alınan məhsulardır ki, şifrələyir). Və prosedurun başladılması zamanı (müntəzəm baş verir, 3 aydan bir ± bəzi) biz yeni bir cüt «kek» yükləyirik və bizim verilənlərin yenidən şifrələnməsi baş verir. Bizim ayrı xidmətlərimiz var, bunlar bütün verilənləri götürür, yeni şəkildə şifrələyir; verilənlərin yanında, onların hansı açarla şifrələndiyini göstərən bir identifikator var. Beləliklə, biz verilənləri yeni açarlarla şifrələdiyimiz an, köhnə açarları silirik.
Bəzən ödənişləri əl ilə etməli olursunuz...
A: – Yəni əgər bir əməliyyat üzərində geri dönmə baş verirsə, o zaman köhnə açarla şifrələnmiş məlumatı açarsınız?
EK: – Bəli.
A: – Sonra bir kiçik sual daha. Hər hansı bir nasazlıq, çökmə, hadisə baş verəndə, əməliyyatı əl ilə yönləndirmək lazım gəlir. Belə bir vəziyyət olur.
EK: – Bəli, belə olur.
A: – Siz bu verilənləri haradan alırsınız? Yoxsa siz özünüz əllə bu anbaraya girirsiniz?
EK: – Xeyr, aydındır ki, bizim bir növ backend sistemi var ki, bu da bizim dəstək üçün interfeys təqdim edir. Əgər biz əməliyyatın hansı statusda olduğunu bilmiriksə (məsələn, ödəniş sistemi cavab vermədiyi zaman) – biz ilk növbədə bilmirik, yəni son statusu tam əminliklə yalnız məlumat alındıqda təyin edirik. Bu halda, biz əməliyyatı xüsusi bir statusa keçiririk əl ilə işlənmək üçün. Səhər, növbəti gün, dəstək ödəniş sistemində hansı əməliyyatların qaldığını öyrənən kimi, onlar bunu əl ilə bu interfeysdə işləyirlər.
A: – Mənim bir neçə sualım var. Onlardan biri PCI DSS zonasının davamıdır: siz agent, qeydləri necə çıxarırsınız? Bu sualı soruşmağımın səbəbi, inkişaf etdirici qeydlərə istənilən məlumatı qoymağına görədir! İkinci sual: hotfix-ləri necə tətbiq edirsiniz? Baza ilə əl ilə tətbiq etmək bir variantdır, amma pulsuz hotfix-lər də ola bilər – orada hansı prosedur var? Və üçüncü sual bəlkə də RTO, RPO ilə bağlıdır. Sizin mövcudluğunuz 99,97-dır, demək olar ki, dörd doqquz, amma anladığım qədəri ilə sizin ikinci data mərkəziniz, üçüncü data mərkəziniz və beşinci data mərkəziniz var... Siz onların sinxronizasiyası, replikasiyası və bütün bunlarla necə məşğul olursunuz?EK: – Gəlin birinci ilə başlayaq. Birinci sual qeydlərlə bağlı idi? Bizim, qeydlər yazılarkən, bütün həssas məlumatları maskalayacaq bir qat var. O, maskaya baxır və əlavə sahələri gözdən keçirir. Beləliklə, bizim qeydlər artıq maskalanmış məlumatlarla və PCI DSS konturuyla çıxır. Bu, test bölməsinə tapşırılan müntəzəm vəzifələrdən biridir. Onlar hər bir vəzifəni, yazdığı qeydlər də daxil olmaqla, yoxlamaqla məcburdurlar və bu, kod nəzərdən keçirmə zamanı müntəzəm bir vəzifədir ki, inkişaf etdiricinin nəsə yazmadığına nəzarət edilsin. Bu, hər həftə təxminən bir dəfə informasiya təhlükəsizliyi bölməsi tərəfindən mütəmadi olaraq həyata keçirilir: sonuncu gün üçün qeydlər seçməklə götürülür və xüsusi skaner-analizator vasitəsilə test serverlərindən keçirilib yoxlanılır.
Hotfix-lər haqqında. Bu, bizim depolama qaydalarımıza daxil edilib. Bizim hotfix-lər üçün ayrıca bir maddəmiz var. Biz hesab edirik ki, biz hotfix-ləri tələbat olduğu zaman günün 24 saatı tətbiq edirik. Versiya toplandığı andan, keçdiyi andan etibarən, artefaktımız olduğu andan, növbətçi sistem administratoru dəstəkdən zənglə çağırılır və lazım olduğu anda bunu tətbiq edir.Dörd doqquz haqqında. Lazım olan o rəqəm hazırda bizim üçün gerçəkdən əldə olunub və biz bunu bir data mərkəzində hədəfləyirdik. İndi ikinci data mərkəzimiz var və onların arasında yönləndirməyə başlayırıq və data mərkəzləri arasında replikasiya məsələsi gerçəkdən mürəkkəbdir. Biz bunu o vaxtlar müxtəlif yollarla həll etməyə çalışmışdıq: eyni 'Tarantul'-u istifadə etməyə çalışdıq – bu, bizdə baş tutmadı, dərhal deyirəm. Buna görə də, biz 'sensanı' əl ilə sifariş etməyə gəldik. Hər bir tətbiq faktik olaraq asinxron rejimdə tələb olunan 'dəyişiklik - başa çatdı' sinxronizasiyasını data mərkəzləri arasında yerinə yetirir.
A: – Sizdə ikinci varsa, niyə üçüncüsü yoxdur? Çünki Split-brain hələ heç kim...
EK: – Bizdə "Split-brain" yoxdur. Hər bir tətbiqimizin multimaster ilə işlədiyi üçün sorğunun hansı mərkəzə gəldiyi bizim üçün əhəmiyyətli deyil. Biz bir data mərkəzimizin baş verməsi halında (bunu gözləyirik) istifadəçinin sorğusunu ikinci data mərkəzinə keçirdiyimizə hazırıq və bu müştərini itirmək riskini qəbul edirik, həqiqətən; lakin bu, çox az sayda, tamamilə az olacaq.
A: – Axşamınız xeyir. Hesabat üçün təşəkkürlər. Siz, istehsalda bəzi test tranzaksiyaları həyata keçirən debuqgerinizdən danışdınız. Bəs, test tranzaksiyaları haqqında danışın! Onlar nə dərəcədə dərin getməyi təmin edir?
EK: – Bu, komponentin tam dövrünü keçir. Komponent üçün test tranzaksiyası ilə real arasında fərq yoxdur. Mantiq baxımından bu, sistem daxilində yalnız test tranzaksiyalarının həyata keçirildiyi ayrı bir layihədir.
A: – Bəs siz onu harada kəsirsiniz? Core göndərdi…
EK: – Biz bu halda test tranzaksiyaları üçün "Core" ilə birlikdəyik… Bizim belə bir anlayışımız var, necə ki, yönləndirmə: "Core" hansı ödəniş sisteminə göndərməli olduğunu bilir – biz bunu yalnış ödəniş sisteminə göndəririk, o da sadəcə http-nin geri dönüşünü təmin edir və bu qədər.
A: – Zəhmət olmasa, tətbiqiniz böyük bir monolit formada yazılıb, yoxsa siz onu bəzi xidmətlərə və ya hətta mikro xidmətlərə parçaladınız?
EK: – Bizdə, əlbəttə ki, monolit yoxdur, biz xidmətə əsaslanan bir tətbiqimiz var. Bizdə belə bir zarafat var ki, xidmətlərimiz monolitlərdən ibarətdir – onlar həqiqətən kifayət qədər böyükdür. Mikro xidmətlər adlandırmaq bu dildə tamamilə doğru deyil, lakin bu, içində yayılmış maşınların işçi qüvvələrinin fəaliyyət göstərdiyi xidmətlərdir.
Əgər serverdəki xidmət kompromitasiya olunubsa…
A: – Onda mənim növbəti sualım. Hətta əgər bu monolit olsaydı, siz yenə dediniz ki, sizin bir çox instant-serverlərinizi var, hər biri, əslində, məlumatları emal edir və sual belədir: "Biridir instant-serverlərin və ya tətbiqin, ayrı bir bağlantının kompromitasiya olunma halında, onlarda hər hansı bir giriş nəzarəti varmı? Kim nə edə bilər? Harada məlumat üçün müraciət edilməlidir?
EK: – Bəli, şübhəsiz. Təhlükəsizlik tələbləri olduqca ciddi. Birincisi, açıq məlumat axınlarımız var və portlar yalnız əvvəlcədən təxmin etdiyimiz trafik hərəkətləri üçün açıqdır. Əgər komponent məlumat bazası ilə (götürək "MySQL" ilə) 5-4-3-2 nömrələri vasitəsilə əlaqə saxlayırsa, ona yalnız 5-4-3-2 açılacaq, digər portlar, digər trafik hərəkətləri əlçatan olmayacaq. Bundan əlavə, başa düşmək lazımdır ki, bizim istehsalda təxminən 10 müxtəlif təhlükəsizlik axını mövcuddur. Hətta əgər tətbiq bir şəkildə kompromitləşsə, Tanrı qorusun, o halda da hücum edən şəxs serverin idarəetmə konsoluna giriş əldə edə bilməyəcək, çünki bu, başqa bir təhlükəsizlik şəbəkə zonasındadır.A: – Mənim bu kontekstdə daha çox maraqlandıran məsələ, sizin bəzi xidmətlərlə müqavilələrinizin olmasıdır - onlar bir-birinə hansı "fərdi" müraciətləri həyata keçirə bilərlər… Və normal axında bəzi xidmətlər digərinə müəyyən bir "fərdi" siyahısı tələb edir. Onlar normal vəziyyətdə digərinə müraciət etmir və onların məsuliyyət bölgələri fərqlidir. Əgər onlardan biri kompromit olarsa, digəri ilə "fərdi" müraciət edə biləcəkmi?..
EK: – Anlayıram. Əgər normal vəziyyətdə digər serverlə əlaqə tamamilə icazəlidirsə, bəli. SLA müqaviləsinə əsasən, yalnız ilk 3 "fərdi" icazə verilib, 4-cü "fərdi" icazə verilmədiyi barədə monitorinq aparmırıq. Bizim üçün bu, bəlkə də artıqdır, çünki bizdə əsasən konturlar üçün 4 pilləli mühafizə sistemimiz var. Biz konturlar səviyyəsində müdafiə etməyi üstün tuturuq, yoxsa iç təbəqələrdə.
Visa, MasterCard və "Sberbank" necə işləyir
A: – Mən istifadəçini bir data mərkəzindən başqa birinə keçirmək məsələsini dəqiqləşdirmək istəyirəm. Bildiyimə görə, "Viza" və "MasterCard" 8583 ikili sinxron protokolu ilə işləyir, orada mikslər var. İndisə keçidin konkret "Viza" və "MasterCard"-la, yoxsa ödəmə sistemlərinə, prosessinqə aid olduğunu öyrənmək istəyirəm?
EK: – Bu mikslərə aiddir. Mikslərimiz bir data mərkəzindədir.
A: – Qabaqcadan desək, sizdə bir qoşulma nöqtəsi var?
EK: – "Viza" və "MasterCard" üçün – bəli. Sadəcə onlar "Viza" və "MasterCard" üçün ayrı müqavilələr bağlamaq üçün kifayət qədər ciddi investisiyalara ehtiyac duyurlar. Onlar bir data mərkəzi daxilində rezervləşdirilib, ancaq əgər, tanrı eləməsin, həmin data mərkəzi ölürsə, "Viza" və "MasterCard"-la əlaqəni itirəcəyik...
A: – Onlar necə rezervləşdirilə bilər? Mən bilirəm ki, "Viza" əsasən yalnız bir bağlantı saxlamağa icazə verir!
EK: – Onlar öz avadanlıqlarını təqdim edirlər. Hər halda, bizə daxil olan avadanlıq tam təminatlıdır.
A: – Yəni onların Connects Orange-dan olan ştand?
EK: – Bəli.
A: – Bəs bu halda: əgər sizin data mərkəziniz yox olursa, necə istifadə etməyə davam edəcəksiniz? Yoxsa sadəcə trafiki dayandırırsınız?
EK: – Xeyr. Bu halda, biz sadəcə trafiki başqa bir kanala yönləndirəcəyik, hansı ki, bizim üçün, müştərilərimiz üçün daha baha başa gələcək. Amma trafik bizim "Viza", "MasterCard"-a birbaşa qoşulma ilə deyil, şərti "Sberbank" vasitəsilə (çox şişirdilmiş formada) yönləndiriləcək.
Bağışlayıram, əgər "Sberbank" işçilərini narahat etmişəmsə. Ancaq bizim statistikamıza görə, Rus bankları arasında "Sberbank" tez-tez çökür. "Sberbank"-da bir ayda nəyinsə işdən çıxmağı baş vermir.
Bir az reklam 🙂
Bizimlə qaldığınız üçün təşəkkür edirik. Bizim məqalələrimizi bəyənirsiniz? Daha maraqlı materiallar görmək istəyirsiniz? Bizi dəstəkləyin, sifariş verərək və ya tanışlarınıza tövsiyə edərək. , Sizin üçün icad etdiyimiz bənzərsiz entry-level serverlərin analoqu: (RAID1 və RAID10 ilə variantlar, 24 nüvəyə qədər və 40GB DDR4-a qədər mövcuddur).
Dell R730xd, Amsterdamdakı Equinix Tier IV data mərkəzində iki dəfə ucuz? Yalnız bizdə Niderlandda! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — 99 $-dan! Bunun haqqında oxuyun
Mənbə: habr.com
