HighLoad++, Evgeny Kuzovlev (EcommPay IT): bir dəqiqəlik fasilə 100000 dollara başa gələndə nə etməli

Hər kəs inkişaf və sınaq prosesləri, kadr hazırlığı, motivasiyanın artırılması haqqında danışır, lakin xidmətin bir dəqiqəlik dayanması kosmik pula başa gələndə bu proseslər kifayət etmir. Ciddi SLA altında maliyyə əməliyyatları apararkən nə etməli? Mötərizədə inkişaf və sınaqdan çıxararaq sistemlərinizin etibarlılığını və nasazlığa dözümlülüyünü necə artırmaq olar?

Növbəti HighLoad++ konfransı 6 və 7 aprel 2020-ci il tarixlərində Sankt-Peterburqda baş tutacaq. Təfərrüatlar və biletlər əlaqə. 9 noyabr, saat 18:00. HighLoad++ Moskva 2018, Dehli + Kolkata Zalı. Abstraktlar və təqdimat.

Evgeni Kuzovlev (bundan sonra AK adlandırılacaq): - Dostlar, salam! Mənim adım Yevgeni Kuzovlevdir. Mən EcommPay-dənəm, xüsusi bölmə EcommPay IT, şirkətlər qrupunun İT bölməsidir. Və bu gün fasilələr haqqında danışacağıq - onlardan necə qaçınmaq, onlardan qaça bilmirsinizsə, nəticələrini necə minimuma endirmək barədə. Mövzu belədir: “Bir dəqiqəlik fasilə 100 dollara başa gələndə nə etməli”? Gələcəyə baxsaq, saylarımız müqayisə oluna bilər.

EcommPay IT nə edir?

Biz kimik? Mən niyə burada sənin qarşında dayanmışam? Niyə burada sənə bir şey deməyə haqqım var? Və burada daha ətraflı nə haqqında danışacağıq?

EcommPay şirkətlər qrupu beynəlxalq ekvayerdir. Biz bütün dünyada - Rusiyada, Avropada, Cənub-Şərqi Asiyada (Bütün Dünyada) ödənişləri emal edirik. Bizim 9 ofisimiz, ümumilikdə 500 işçimiz var və onların təxminən yarısından bir qədər azı İT mütəxəssisləridir. Etdiyimiz hər şeyi, pul qazandığımız hər şeyi özümüz etmişik.

Bizim bütün məhsullarımız var (və onların kifayət qədər çoxu var - böyük İT məhsulları xəttində təxminən 16 müxtəlif komponentimiz var) özümüz yazdıq; özümüz yazırıq, özümüzü inkişaf etdiririk. Hal-hazırda biz gündə təxminən bir milyon əməliyyat edirik (milyonlarla - yəqin ki, belə demək düzgün olardı). Biz kifayət qədər gənc şirkətik – cəmi altı yaşımız var.

6 il əvvəl uşaqlar bizneslə birlikdə gələndə belə bir başlanğıc idi. Onları bir ideya birləşdirdi (ideyadan başqa heç nə yoxdu) və biz qaçdıq. Hər hansı bir başlanğıc kimi, biz də daha sürətli qaçdıq... Bizim üçün sürət keyfiyyətdən daha vacib idi.

Nə vaxtsa dayandıq: anladıq ki, biz artıq o sürət və keyfiyyətlə nədənsə yaşaya bilmərik və ilk növbədə keyfiyyətlə məşğul olmalıyıq. O anda düzgün, genişlənən, etibarlı olacaq yeni bir platforma yazmağa qərar verdik. Bu platformanı yazmağa başladılar (investisiya etməyə, inkişaf etdirməyə, sınaqdan keçirməyə başladılar), lakin bir anda inkişaf və sınaqların xidmət keyfiyyətinin yeni səviyyəsinə çatmağa imkan vermədiyini başa düşdülər.

Siz yeni məhsul istehsal edirsiniz, onu istehsala qoyursunuz, amma yenə də haradasa nəsə səhv gedir. Və bu gün biz yeni keyfiyyət səviyyəsinə necə çatmaq barədə danışacağıq (bunu necə etdik, təcrübəmiz haqqında), inkişaf və sınaqları mötərizədən çıxararaq; biz istismar üçün nəyin mövcud olmasından danışacağıq - istismarın özü nə edə bilər, keyfiyyətə təsir etmək üçün sınaqlara nə təklif edə bilər.

Kesintilər. Əməliyyat əmrləri.

Həmişə bu gün həqiqətən danışacağımız əsas təməl daşı - dayanma vaxtı. Dəhşətli söz. Əgər boş vaxtımız varsa, hər şey bizim üçün pisdir. Qaldırmağa qaçırıq, adminlər server tutur - Allah eləməsin ki, o mahnıda oxunur. Bu gün danışacağımız şey budur.

Biz yanaşmalarımızı dəyişməyə başlayanda 4 əmr formalaşdırdıq. Onlar slaydlarda təqdim olunur:

Bu əmrlər olduqca sadədir:

• Problemi tez müəyyənləşdirin.
• Ondan daha tez qurtulun.
• Səbəbini anlamağa kömək edin (daha sonra tərtibatçılar üçün).
• və yanaşmaları standartlaşdırmaq.

Diqqətinizi 2 nömrəli məqama cəlb edim. Problemi həll etmirik, aradan qaldırırıq. Qərar vermək ikinci dərəcəlidir. Bizim üçün əsas odur ki, istifadəçi bu problemdən qorunsun. Bəzi təcrid olunmuş mühitdə mövcud olacaq, lakin bu mühit heç bir şəkildə onunla təmasda olmayacaq. Əslində, biz bu dörd problem qrupundan keçəcəyik (bəziləri üçün daha ətraflı, bəziləri üçün daha az təfərrüatlı), sizə nədən istifadə etdiyimizi, həll yollarında hansı təcrübəmiz olduğunu söyləyəcəyəm.

Problemlərin həlli: onlar nə vaxt baş verir və onlarla nə etməli?

Ancaq sıradan başlayacağıq, 2 nömrəli nöqtədən başlayacağıq - problemdən necə tez qurtulmaq olar? Bir problem var - onu düzəltmək lazımdır. "Bununla nə edək?" - əsas sual. Problemi necə həll edəcəyimizi düşünməyə başlayanda özümüz üçün bəzi tələblər hazırladıq ki, problemlərin aradan qaldırılmasına əməl edilməlidir.

Bu tələbləri formalaşdırmaq üçün özümüzə sual vermək qərarına gəldik: “Bizim nə vaxt problemimiz var”? Və məlum oldu ki, problemlər dörd halda baş verir:

• Aparat çatışmazlığı.
• Xarici xidmətlərin uğursuzluğu.
• Proqram versiyasının dəyişdirilməsi (eyni yerləşdirmə).
• Partlayıcı iş yükü.

İlk ikisi haqqında danışmayacağıq. Aparat nasazlığı olduqca sadə şəkildə həll olunur: hər şeyin təkrarlanması lazımdır. Bunlar disklərdirsə - disklər RAID-də yığılmalıdır, bu serverdirsə - server dublikat edilməlidir, əgər şəbəkə infrastrukturunuz varsa - şəbəkə infrastrukturunun ikinci nüsxəsini qoymalısınız, yəni götürməlisiniz və dublikat. Və bir şey sizə uğursuz olarsa, ehtiyat imkanlara keçirsiniz. Burada daha çox söz demək çətindir.

İkincisi, xarici xidmətlərin uğursuzluğudur. Əksəriyyət üçün sistem heç də problem deyil, amma bizim üçün deyil. Ödənişləri emal etdiyimiz üçün biz istifadəçi (kart məlumatlarını daxil edən) və banklar, ödəniş sistemləri (Visa, MasterCard, Mira) arasında dayanan bir aqreqatoruyuq. Xarici xidmətlərimiz (ödəniş sistemləri, banklar) uğursuzluğa düçar olur. Nə biz, nə də siz (belə xidmətləriniz varsa) buna təsir edə bilməz.

Onda nə etməli? Burada iki variant var. Birincisi, əgər bacarırsınızsa, bu xidməti bir şəkildə təkrarlamalısınız. Məsələn, bacarsaq, trafiki bir xidmətdən digərinə köçürürük: biz, məsələn, Sberbank vasitəsilə kartları emal etdik, Sberbankın problemləri var - biz trafiki [şərti olaraq] Raiffeisen-ə köçürürük. Edə biləcəyimiz ikinci şey, xarici xidmətlərin uğursuzluğunu çox tez hiss etməkdir və buna görə də hesabatın növbəti hissəsində cavab sürəti haqqında danışacağıq.

Əslində, bu dördündən biz proqram versiyalarının dəyişməsinə xüsusi təsir göstərə bilərik - yerləşdirmə kontekstində və yükün partlayıcı artması kontekstində vəziyyətin yaxşılaşmasına səbəb olacaq tədbirlər həyata keçirək. Əslində, biz bunu etdik. Yenə də kiçik bir qeyd...

Buludunuz varsa, bu dörd problemdən bir neçəsi dərhal həll olunur. Əgər siz Microsoft Azhur, Ozon buludlarındasınızsa, Yandex və ya Mail-dən buludlarımızı istifadə edin, onda heç olmasa bir hardware nasazlığı onların probleminə çevrilir və avadanlıq nasazlığı kontekstində hər şey dərhal yaxşılaşır.

Biz bir az qeyri-standart şirkətik. Burada hamı Kubernetlərdən, buludlardan danışır - bizdə Kubernetlər və buludlar yoxdur. Digər tərəfdən, bir çox data mərkəzlərində dəmirli rəflərimiz var və biz bu dəmirlə yaşamağa məcburuq, bütün bunlara görə məsuliyyət daşımağa məcburuq. Ona görə də bu kontekstdə danışacağıq. Beləliklə, problemlər haqqında. İlk ikisi mötərizədə qoyulub.

Proqram versiyasının dəyişdirilməsi. əsaslar

Tərtibatçılarımızın istehsala çıxışı yoxdur. Niyə belədir? Ancaq biz sadəcə PCI DSS sertifikatına sahibik və tərtibatçılarımızın sadəcə olaraq “məhsul”a dırmaşmaq hüququ yoxdur. Bütün nöqtə. Bütün. Buna görə də, inkişafın məsuliyyəti, inkişafın quruluşun buraxılması üçün təhvil verildiyi anda başa çatır.

Sahib olduğumuz və bizə çox kömək edən ikinci əsasımız unikal sənədsiz biliklərin olmamasıdır. Ümid edirəm ki, siz də eyni şeyi edirsiniz. Çünki belə deyilsə, bəladasınız. Bu unikal, sənədsiz bilik lazımi anda, lazımi yerdə olmadıqda problemlər yaranır. Tutaq ki, müəyyən bir komponenti necə yerləşdirməyi bilən bir adamınız var - heç bir insan yoxdur, o, tətildədir və ya xəstədir - bu qədərdir, probleminiz var.

Gəldiyimiz üçüncü əsas. Biz buna ağrı, qan, göz yaşları ilə gəldik - belə nəticəyə gəldik ki, hər hansı bir quruluşumuz səhvsiz olsa belə, səhvlər ehtiva edir. Bunu özümüz üçün qərara aldıq: nəyisə yerləşdirəndə, nəyisə istehsala köçürəndə səhvləri olan bir quruluşumuz olur. Sistemimizin təmin etməli olduğu tələbləri formalaşdırmışıq.

Proqram təminatının təkmilləşdirilməsi tələbləri

Bu tələblərdən üçü var:

• Yerləşdirməni tez bir zamanda geri qaytarmalıyıq.
• Uğursuz yerləşdirmənin təsirini minimuma endirməliyik.
• Və biz tez paralel olaraq yerləşdirməyi bacarmalıyıq.
  Bu sıra ilə! Niyə? Çünki, ilk növbədə, yeni versiyanı yerləşdirərkən sürət vacib deyil, amma nəsə səhv olarsa, tez geri dönmək və minimal təsir göstərmək sizin üçün vacibdir. Ancaq səhv olduğu ortaya çıxan bir sıra istehsal versiyalarınız varsa (məsələn, yerləşdirmə yox idi, lakin səhv var) - sonrakı yerləşdirmə sürəti sizin üçün vacibdir. Bu tələblərə cavab vermək üçün nə etdik? Aşağıdakı metodologiyaya müraciət etdik:

  
  
  Bu, çox yaxşı məlumdur, biz onu heç vaxt icad etməmişik - bu, Mavi/Yaşıl yerləşdirmədir. Bu nədir? Tətbiqlərinizin yerləşdiyi hər bir server qrupu üçün bir nüsxəniz olmalıdır. Nüsxə "isti"dir: üzərində trafik yoxdur, lakin istənilən vaxt bu trafik bu nüsxəyə göndərilə bilər. Bu nüsxədə əvvəlki versiya var. Və yerləşdirmə zamanı kodu aktiv olmayan bir nüsxəyə yayırsınız. Sonra trafikin bir hissəsini (və ya hamısını) yeni versiyaya keçirin. Beləliklə, trafik axınını köhnə versiyadan yenisinə dəyişdirmək üçün yalnız bir hərəkət etməlisiniz: yuxarı axındakı balanslaşdırıcını dəyişdirməlisiniz, istiqaməti dəyişdirməlisiniz - bir yuxarıdan digərinə. Bu, çox rahatdır və sürətli keçid, sürətli geri çəkilmə problemini həll edir.

  Burada ikinci sualın həlli minimuma endirmədir: siz trafikinizin yalnız bir hissəsini yeni xəttə, yeni kodlu xəttə (məsələn, 2%) yerləşdirə bilərsiniz. Və bu 2% 100% deyil! Uğursuz yerləşdirmə zamanı trafikinizin 100%-ni itirmisinizsə, bu, qorxulu, trafikinizin 2%-ni itirdiyiniz halda, bu, xoşagəlməzdir, lakin qorxulu deyil. Üstəlik, istifadəçilər çox güman ki, bunu hiss etməyəcəklər, çünki bəzi hallarda (hamısında deyil) eyni istifadəçi F5 düyməsini basaraq başqa, işləyən versiyaya keçəcək.

  Mavi/Yaşıl yerləşdirmə. Marşrutlaşdırma

  Eyni zamanda, hər şey o qədər də sadə deyil "Mavi / Yaşıl Yerləşdirmə" ... Bütün komponentlərimizi üç qrupa bölmək olar:

  • bu front-enddir (müştərilərimizin gördüyü ödəniş səhifələri);
  • emal nüvəsi;
  • ödəniş sistemləri ilə işləmək üçün adapter (banklar, MasterCard, Visa ...).

  Və burada bir nüans var - nüans xətlər arasındakı marşrutlaşdırmada yatır. Əgər sadəcə trafikin 100%-ni dəyişsəniz, bu probleminiz olmayacaq. Ancaq 2% dəyişdirmək istəyirsinizsə, suallar verməyə başlayırsınız: "Bunu necə etmək olar?" Ən sadəsi, alında: təsadüfi seçimlə Round Robin-i nginx-də qura bilərsiniz və sizdə 2% sol, 98% sağ var. Amma bu həmişə işləmir.

  Ölkəmizdə, məsələn, istifadəçi birdən çox sorğu ilə sistemlə əlaqə qurur. Bu normaldır: 2, 3, 4, 5 sorğu - sistemləriniz eyni ola bilər. Və sizin üçün vacibdirsə, bütün istifadəçi sorğularının ilk sorğunun gəldiyi eyni xəttə gəlməsi və ya (ikinci an) bütün istifadəçi sorğularının keçiddən sonra yeni bir xəttə gəlməsi (o, sistemlə daha əvvəl işləməyə başlaya bilərdi. keçid), - onda bu təsadüfi paylama sizin üçün uyğun deyil. Sonra aşağıdakı variantlar var:

  
  
  Birinci seçim, ən sadəsi, müştərinin əsas parametrlərinə (IP Hash) əsaslanır. Sizin IP-niz var və onu IP ünvanı ilə sağdan sola ayırırsınız. Sonra təsvir etdiyim ikinci hal sizin üçün işləyəcək, yerləşdirmə baş verdikdə, istifadəçi artıq sisteminizlə işləməyə başlaya bilər və yerləşdirmə anından etibarən bütün sorğular yeni bir xəttə keçəcək (eyni birinə, deyək ki) .

  Əgər nədənsə bu sizə uyğun gəlmirsə və ilkin, init istifadəçi sorğusunun gəldiyi xəttə sorğu göndərməlisinizsə, onda iki seçiminiz var ...
  Birinci seçim: ödənişli nginx+ ala bilərsiniz. İstifadəçinin ilkin tələbi ilə istifadəçini seansa məruz qoyan və onu bu və ya digər yuxarı axınla bağlayan Sticky sessions mexanizmi mövcuddur. Sessiya müddəti ərzində bütün sonrakı istifadəçi sorğuları sessiyanın məruz qaldığı eyni yuxarı axına gedəcək.

  Bu, bizə uyğun deyildi, çünki bizim artıq adi nginximiz var idi. Nginx+-a keçid o qədər də baha başa gəlmir, sadəcə olaraq bizim üçün bir az ağrılı oldu və çox da düzgün deyildi. Məsələn, “Stick Sessions” bizim üçün sadə səbəbə görə işləmədi ki, “Sticks Sessions” “Ya-ya da” əsasında marşrutlaşdırmağa icazə vermir. Orada nə etdiyimizi "Stick Sessions", məsələn, IP ünvanı və ya IP ünvanı və kukilər və ya post-parametrlə təyin edə bilərsiniz, lakin "Ya-ya da" artıq orada daha çətindir.

  Ona görə də dördüncü varianta gəldik. Steroidlərdə nginx götürdük (bu açıqdır) - bu eyni nginxdir, əlavə olaraq son skriptlərin daxil edilməsini dəstəkləyir. Siz son skript yaza, onun içinə "açıqlıq" qoya bilərsiniz və istifadəçi sorğusu daxil olduqda həmin sonuncu skript yerinə yetiriləcək.

  Və biz, əslində, belə bir skript yazdıq, özümüzə bir "açıqlıq" təyin etdik və bu skriptdə "Və ya" birləşdirərək 6 müxtəlif parametrləri sıralayırıq. Bu və ya digər parametrin mövcudluğundan asılı olaraq, istifadəçinin bu və ya digər səhifəyə, bu və ya digər sətirə gəldiyini bilirik.

  Mavi/Yaşıl yerləşdirmə. Yaxşı və pis tərəfləri

  Əlbəttə ki, bunu bir az daha sadələşdirmək mümkün idi (eyni "Stick Sessions" istifadə edin), lakin bizdə hələ də elə bir nüans var ki, bir əməliyyatın bir emalı çərçivəsində nəinki istifadəçi bizimlə əlaqə saxlamır ... Lakin ödəniş sistemləri də bizimlə qarşılıqlı əlaqədə olur: biz əməliyyatı icra etdikdən sonra (ödəniş sisteminə sorğu göndərməklə) geri dönüş alırıq.
  Tutaq ki, əgər konturumuzun daxilində istifadəçinin İP ünvanını bütün sorğulara ata bilsək və istifadəçiləri İP ünvanına əsasən ayıra bilsək, o zaman eyni “Viza”ya deməyəcəyik: “Dostlar, biz belə retro şirkətik, biz bir növ beynəlxalq (saytda və Rusiyada) ... Və əlavə sahəyə istifadəçinin IP ünvanını bizə göndərin, protokolunuz standartlaşdırılıb! Təbii ki, razı olmayacaqlar.

  
  
  Ona görə də bu, bizə yaraşmadı - açıq-saçıqlıq etdik. Buna görə, marşrutlaşdırma ilə biz bunu belə aldıq:

  Blue / Green Deploy müvafiq olaraq qeyd etdiyim üstünlüklərə və mənfi cəhətlərə malikdir.

  İkinci çatışmazlıq:

  • marşrutlaşdırma ilə məşğul olmalısan;
  • İkinci əsas çatışmazlıq qiymətdir.

  Sizə iki dəfə çox server lazımdır, iki dəfə çox əməliyyat resursu lazımdır, bütün bu zooparkı saxlamaq üçün iki dəfə çox səy sərf etməlisiniz.

  Yeri gəlmişkən, üstünlüklər arasında - daha əvvəl qeyd etmədiyim bir şey: yükün artması halında ehtiyatınız var. Əgər partlayıcı yük artımınız varsa, çoxlu sayda istifadəçi üzərinizə düşübsə, onda siz sadəcə olaraq 50-dən 50-yə qədər paylamaya ikinci sətri daxil edirsiniz - və daha çox serverə sahib olmaq problemini həll edənə qədər dərhal klasterinizdə x2 serverlər var. .

  Tez yerləşdirməni necə etmək olar?

  Minimumlaşdırma və tez geri qaytarma problemini necə həll etmək barədə danışdıq, amma sual qalır: "Necə tez yerləşdirmək olar"?

  
  
  Bu qısa və sadədir.

  • CD-sisteminiz olmalıdır (Daimi Çatdırılma) - onsuz, heç yerdə. Bir serveriniz varsa, tutacaqları yerləşdirə bilərsiniz. Təxminən min yarım serverimiz və bir yarım min tutacaqımız var, əlbəttə ki, biz bu zalın ölçüsündə bir şöbə tikə bilərik, sadəcə yerləşdirmək üçün.
  • Yerləşdirmə paralel olmalıdır. Ardıcıl yerləşdirməniz varsa, hər şey pisdir. Bir server yaxşıdır, bütün gün bir yarım min server yerləşdirəcəksiniz.
  • Yenə də sürətləndirmək üçün bu artıq lazım deyil, məncə. Desploy adətən layihəni qurur. Sizin veb layihəniz var, ön hissə var (orada veb-paket düzəldirsiniz, npm yığırsınız - buna bənzər bir şey) və bu proses, prinsipcə, qısamüddətlidir - 5 dəqiqə, lakin bu 5 dəqiqə ola bilər. tənqidi. Buna görə də, məsələn, biz bunu etmirik: bu 5 dəqiqəni çıxardıq, artefaktları yerləşdiririk.

    Artefakt nədir? Artefakt, bütün montaj hissəsinin artıq tamamlandığı yığılmış bir quruluşdur. Biz bu artefaktı artefakt anbarında saxlayırıq. Biz eyni anda iki belə repozitoriyadan istifadə etdik - bu Nexus idi, indi isə jFrog Artifactory).Biz ilkin olaraq Nexus-dan istifadə etdik, çünki bu yanaşmanı java proqramlarında tətbiq etməyə başladıq (bunun üçün çox uyğun idi). Sonra PHP-də yazılmış bəzi proqramlar ora qoyuldu; və Nexus artıq uyğun deyildi və buna görə də biz demək olar ki, hər şeyi artifaktura edə bilən jFrog Artefactory-ni seçdik. Hətta belə nəticəyə gəldik ki, serverlər üçün topladığımız bu artefakt anbarında öz binar paketlərimizi saxlayırıq.

  Partlayıcı yük artımı

  Proqram versiyasının dəyişdirilməsi haqqında danışdıq. Bizdə olan növbəti şey yükün partlayıcı artmasıdır. Burada, yəqin ki, yükün partlayıcı böyüməsinin tamamilə düzgün bir şey olmadığını başa düşürəm ...

  Biz yeni sistem yazdıq - xidmət yönümlüdür, moda gözəldir, işçilər hər yerdədir, növbələr hər yerdədir, asinxroniya hər yerdədir. Və belə sistemlərdə məlumatlar müxtəlif axınlarla gedə bilər. Birinci əməliyyat üçün 1-ci, 3-cü, 10-cu işçi, ikinci əməliyyat üçün 2-ci, 4-cü, 5-ci işçi cəlb oluna bilər. Və bu gün, deyək ki, səhər siz ilk üç işçidən istifadə edən bir məlumat axınınız var, axşam isə o, kəskin şəkildə dəyişir və hər şey digər üç işçidən istifadə edir.

  Və burada belə çıxır ki, siz birtəhər işçilərin miqyasını artırmalısınız, xidmətlərinizi bir şəkildə miqyaslandırmalısınız, lakin eyni zamanda resursların şişməsinə imkan verməməlisiniz.

  
  
  Biz tələblərimizi müəyyən etmişik. Bu tələblər olduqca sadədir: Xidmət kəşfinə, parametrləşdirməyə sahib olmaq - bu cür genişlənə bilən sistemlərin qurulması üçün hər şey standartdır, bir nöqtə istisna olmaqla - bu, resursun köhnəlməsidir. Dedik ki, serverlərin havanı qızdırması üçün resursları amortizasiya etməyə hazır deyilik. Konsulu götürdük, işçilərimizi idarə edən Nomad götürdük.

  Niyə bu bizim üçün problemdir? Gəlin bir az geriyə qayıdaq. İndi arxamızda 70-ə yaxın ödəniş sistemi var. Səhər saatlarında trafik Sberbankdan keçir, sonra Sberbank, məsələn, düşdü və biz onu başqa bir ödəniş sisteminə keçirik. Sberbankdan əvvəl 100 işçimiz var idi və bundan sonra başqa bir ödəniş sistemi üçün 100 işçini kəskin şəkildə artırmalıyıq. Və bütün bunların insan iştirakı olmadan baş verməsi arzu edilir. Çünki insan iştirakı varsa, orada mühəndis 24/7 oturmalıdır, yalnız bunu etməlidir, çünki arxanızda 70 sistem olanda belə nasazlıqlar müntəzəm olaraq baş verir.

  Buna görə də, ictimai IP-yə malik olan Nomad-a baxdıq və öz Scale-Nomad şeyimizi - ScaleNo yazdıq, bu da belə bir şey edir: növbənin böyüməsini izləyir və dinamikasından asılı olaraq işçilərin sayını azaldır və ya artırır. növbə. Bunu edəndə düşündük: "Bəlkə açıq mənbə olmalıdır?" Sonra ona baxdılar - o, iki qəpik kimi sadədir.

  İndiyə qədər mənbəni açmamışıq, amma hesabatdan sonra belə bir şeyə ehtiyacınız olduğunu başa düşdükdən sonra birdən ehtiyacınız varsa, sonuncu slaydda mənim əlaqələrim var - mənə yazın. Ən azı 3-5 nəfər olsa, mənbə açacağıq.

  
  
  Bu necə işləyir? Gəlin nəzər salaq! İrəliyə baxırıq: sol tərəfdə monitorinqimizin bir hissəsi var: bu bir xəttdir, yuxarıda hadisələrin işlənməsi vaxtı, ortada əməliyyatların sayı, aşağıda işçilərin sayı.

  Baxsanız, bu şəkildə bir səhv var. Üst diaqramda qrafiklərdən biri 45 saniyə ərzində çökdü - ödəniş sistemlərindən biri sıradan çıxdı. Dərhal 2 dəqiqəyə trafik gətirildi və işçinin olmadığı başqa ödəniş sistemində növbə artmağa başladı (resurslardan istifadə etmədik - əksinə, resursdan düzgün istifadə etdik). Biz qızdırmaq istəmirdik - minimum sayı, təxminən 5-10 işçi var idi, amma öhdəsindən gələ bilmədilər.

  Son qrafikdə, sadəcə olaraq, "Scaleno"nun bu məbləği ikiqat artırdığını söyləyən "donqar"ı görə bilərsiniz. Və sonra, qrafik bir qədər aşağı düşəndə, onu bir qədər azaldıb - işçilərin sayı avtomatik olaraq dəyişdirildi. Bu iş belə işləyir. 2 nömrəli nöqtə haqqında danışdıq - "Səbəblərdən necə tez qurtarmaq olar".

  Monitorinq. Problemi necə tez müəyyənləşdirmək olar?

  İndi ilk məqam - "Problemi necə tez müəyyən etmək olar?" Monitorinq! Bəzi şeyləri tez başa düşməliyik. Tez başa düşməyimiz lazım olan şeylər hansılardır?

  
  
  Üç şey!

  • Biz öz resurslarımızın sağlamlığını tez dərk etməli və tez başa düşməliyik.
  • Biz uğursuzluğu tez başa düşməliyik, bizə xaric olan sistemlərin işinə nəzarət etməliyik.
  • Üçüncü məqam məntiqi səhvlərin müəyyən edilməsidir. Bu, sistem sizin üçün işlədiyi zaman, bütün göstəricilərə görə, hər şey yaxşıdır, amma bir şey səhv gedir.

  Burada, yəqin ki, çox gözəl olduğunu söyləməyəcəm. Mən Kapitan Obvious olacağam. Bazarda nə olduğunu axtarırdıq. Əyləncəli zooparkımız var. İndiki zooparkımız budur:

  
  
  Biz Zabbix-dən avadanlıqları izləmək, serverlərin əsas göstəricilərini izləmək üçün istifadə edirik. Verilənlər bazası üçün istifadə etdiyimiz "Okmeter". İlk ikisinə uyğun gəlməyən bütün digər göstəricilər üçün "Qrafana" və "Prometey"dən istifadə edirik və onlardan bəziləri - "Qrafana" və "Prometey", bəziləri - "Influx" və Teleqraf ilə "Grafana".

  Bir il əvvəl biz New Relic istifadə etmək istəyirdik. Əla şeydir, o hər şeyi edə bilər. Amma hər şeyi bildiyinə görə, o, çox bahalıdır. Həcmi 1,5 min serverə çatanda bizə bir satıcı gəldi və dedi: "Gələn bir il üçün müqavilə bağlayaq". Qiymətə baxdıq ki, yox, belə etməyəcəyik. İndi biz New Relic-dən imtina edirik, New Relic monitorinqi altında təxminən 15 serverimiz qalıb. Qiymət tamamilə həddindən artıq idi.

  Özümüz həyata keçirdiyimiz bir vasitə var - bu Debugger. Əvvəlcə ona “Bagger” deyirdik, amma sonra ingilis dili müəllimimiz yanımızdan keçib, çılğın güldü və adını “Debugger” qoydu. Bu nədir? Bu, əslində, sistemin "qara qutusu" kimi hər bir komponentdə 15-30 saniyə ərzində komponentin ümumi performansı üçün testləri işə salan bir vasitədir.

  Məsələn, əgər xarici səhifə (ödəniş səhifəsi) - o, sadəcə açır və necə görünməli olduğunu görür. Əgər bu emal edilirsə, o, sınaq "əməliyyatını" işə salır - çatmaq üçün bu "əməliyyatı" axtarır. Əgər bu ödəniş sistemləri ilə əlaqədirsə, biz buna uyğun olaraq test sorğusu göndəririk və görürük ki, bizdə hər şey yaxşıdır.

  Hansı göstəricilərə nəzarət etmək vacibdir?

  Biz əsasən nəyə nəzarət edirik? Hansı göstəricilər bizim üçün vacibdir?

  
  

  • Cəbhələrdə cavab müddəti / RPS çox vacib bir göstəricidir. Dərhal cavab verir ki, sizdə bir şey səhvdir.
  • Bütün növbələrdə işlənmiş mesajların sayı.
  • İşçilərin sayı.
  • Əsas düzgünlük ölçüləri.

  Sonuncu nöqtə “biznes”, “biznes” metrikasıdır. Eyni şeyi izləmək istəyirsinizsə, sizin üçün əsas göstəricilər olan bir və ya iki ölçü müəyyən etməlisiniz. Bizdə belə bir metrik var - bu, ötürmə qabiliyyətidir (bu, uğurlu əməliyyatların sayının əməliyyatların ümumi axınına nisbətidir). Əgər 5-10-15 dəqiqə ərzində onda nəsə dəyişirsə, deməli problemimiz var (əgər kəskin şəkildə dəyişirsə).

  Bu, bizim üçün necə görünür - lövhələrimizdən birinin nümunəsi:

  
  
  Sol tərəfdə - 6 qrafik, müvafiq olaraq, xətlər boyunca - işçilərin sayı və növbələrdəki mesajların sayı. Sağ tərəfdə - RPS, RTS. Aşağıda eyni "biznes" metrikası var. Və "biznes" metrikasında iki orta qrafikdə bir şeyin səhv getdiyini dərhal görə bilərik ... Bu, arxamızda qalan başqa bir sistemdir.

  Bizim etməli olduğumuz ikinci şey xarici ödəniş sistemlərinin düşməsini izləmək idi. Burada biz OpenTracing-i götürdük - paylanmış sistemləri izləməyə imkan verən mexanizm, standart, paradiqma; və bir az dəyişdirilib. Standart OpenTracing paradiqması deyir ki, biz hər bir fərdi sorğu üçün iz qururuq. Buna ehtiyacımız yox idi və biz onu bir xülasə, toplama izinə bükdük. Biz arxamızdakı sistemlərin sürətini izləməyə imkan verən bir alət hazırladıq.

  
  
  Qrafik bizə ödəniş sistemlərindən birinin 3 saniyə ərzində cavab verməyə başladığını göstərir - problemlərimiz var. Eyni zamanda, bu şey problemlər başlayanda, 20-30 saniyə aralığında reaksiya verəcəkdir.

  Və mövcud olan monitorinq xətalarının üçüncü sinfi məntiqi monitorinqdir.

  Düzünü desəm, bu slaydda nə çəkəcəyimi bilmirdim, çünki uzun müddətdir bazarda bizə uyğun olan bir şey axtarırdıq. Heç nə tapa bilmədik, ona görə də özümüz etməli olduq.

  
  
  Məntiqi monitorinq dedikdə nəyi nəzərdə tuturam? Yaxşı, təsəvvür edin: özünüzü bir sistem edirsiniz (məsələn, Tinder-in klonu); etdin, işə saldın. Müvəffəqiyyətli menecer Vasya Pupkin telefonuna qoydu, orada bir qız görür, onu bəyənir ... və buna bənzər şey qıza deyil - bənzəri eyni biznes mərkəzindən mühafizəçi Mixaliçə gedir. Menecer aşağı enir və sonra təəccüblənir: “Bu mühafizəçi Mixaliç niyə ona belə xoş gülümsəyir”?

  Belə vəziyyətlərdə... Bizim üçün bu vəziyyət bir az fərqli səslənir, çünki (yazmışam) bu, dolayısı ilə maddi itkilərə səbəb olan elə bir reputasiya itkisidir. Bizim vəziyyətimiz əksinədir: biz birbaşa maliyyə itkiləri ilə üzləşə bilərik - məsələn, əgər biz əməliyyatı uğurlu hesab etdiksə, lakin uğursuz oldu (və ya əksinə). Mən biznes göstəricilərinə əsaslanaraq bir zaman intervalında dinamikada uğurlu əməliyyatların sayını izləyən öz alətimi yazmalı oldum. Bazarda heç nə tapmadı! Mənim çatdırmaq istədiyim də məhz budur. Bazarda belə problemləri həll edəcək heç nə yoxdur.

  Bu, problemi necə tez müəyyənləşdirmək məsələsi ilə bağlı idi.

  Yerləşdirmənin səbəblərini necə müəyyənləşdirmək olar

  Həll etdiyimiz üçüncü qrup tapşırıqlar problemi müəyyən etdikdən sonra, ondan qurtulduqdan sonra inkişafın səbəbini, sınaqdan keçirilməsini başa düşmək və bununla bağlı nəsə etmək yaxşı olardı. Buna görə araşdırmamız, logları yüksəltməmiz lazımdır.

  
  
  Əgər loglardan danışırıqsa (əsas səbəb loglardır), ELK Stack-də bizdə olan logların əsas hissəsi - demək olar ki, hər kəsdə var. Bəzilərində ELK olmaya bilər, amma logları gigabaytla yazsanız, gec-tez ELK-a gələcəksiniz. Biz onları terabaytlarla yazırıq.

  
  
  Burada problem var. Biz düzəltdik, istifadəçi üçün səhvi düzəltdik, orada nə olduğunu qazmağa başladıq, Kibana qalxdıq, orada əməliyyat id-sini daxil etdik və belə bir ayaq örtüyü aldıq (çox şey göstərir). Və bu ayaq paltarında tamamilə heç bir şey aydın deyil. Niyə? Bəli, çünki hansı hissənin hansı işçiyə, hansı hissənin hansı komponentə aid olduğu aydın deyil. Və o anda başa düşdük ki, bizə izləmə lazım idi - mənim haqqında danışdığım eyni OpenTracing.

  Bir il əvvəl bu barədə düşündük, gözümüzü bazara çevirdik və orada iki alət var idi - Zipkin və Jaeger. “Ovçu” əslində belə bir ideoloji varisdir, “Zipkin”in ideoloji davamçısıdır. "Zipkin"də hər şey qaydasındadır, bir başqa, o, necə toplamaq lazım olduğunu bilmir, izə logları necə daxil etməyi bilmir, yalnız zaman izi. Və Jaeger bunu dəstəklədi.

  Jaeger-ə baxdıq: proqramları alət edə bilərsiniz, Api-də yaza bilərsiniz (o vaxt PHP üçün Api standartı təsdiqlənməmişdi - bir il əvvəl idi, amma indi artıq təsdiq edilmişdir), lakin tamamilə var idi. müştəri yoxdur. “Yaxşı” deyə düşündük və öz müştərimizi yazdıq. Nə əldə etdik? Bu belə görünür:

  
  
  Jaeger-də hər mesaj üçün aralıqlar yaradılır. Yəni istifadəçi sistemi açanda hər daxil olan sorğu üçün bir və ya iki blok görür (1-2-3 - istifadəçidən nə qədər daxil olan sorğu olub, bu qədər blok). İstifadəçilər üçün bunu asanlaşdırmaq üçün biz qeydlərə və vaxt izlərinə teqlər əlavə etdik. Müvafiq olaraq, xəta baş verərsə, tətbiqimiz jurnalı müvafiq Səhv etiketi ilə qeyd edəcəkdir. Siz Xəta etiketi ilə süzgəcdən keçirə bilərsiniz və yalnız səhvi olan bu bloku ehtiva edən aralıqlar göstəriləcək. Aralığı genişləndirsək, belə görünür:

  
  
  Aralığın içərisində bir sıra izlər var. Bu halda bunlar üç sınaq izidir və üçüncü iz bizə xətanın baş verdiyini bildirir. Eyni zamanda, burada bir zaman izi görürük: üstümüzdə zaman şkalası var və bu və ya digər jurnalın hansı vaxt intervalında qeydə alındığını görürük.

  Buna uyğun olaraq, yaxşı iş görmüşük. Biz öz genişləndirməmizi yazdıq və biz onu açıq mənbə ilə açdıq. Əgər izləmə ilə işləmək istəyirsinizsə, PHP-də “Huntsman” ilə işləmək istəyirsinizsə, bizim genişlənməmiz var, necə deyərlər, istifadə etməyə xoş gəlmisiniz:

  
  
  Bizdə bu genişlənmə var - bu, php-uzantısı kimi hazırlanmış OpenTracing Api üçün müştəridir, yəni siz onu yığıb sistemə yerləşdirməli olacaqsınız. Bir il əvvəl başqa heç nə yox idi. İndi komponentlər kimi olan digər müştərilər də var. Bu sizin ixtiyarınızdadır: ya komponentləri bəstəkar kimi endirirsiniz, ya da özünüzə qədər uzantıdan istifadə edirsiniz.

  Korporativ standartlar

  Biz üç əmr haqqında danışdıq. Dördüncü əmr yanaşmaları standartlaşdırmaqdır. Söhbət nədən gedir? Söhbət bundan gedir:

  
  
  Niyə burada "korporativ" sözü var? Ona görə yox ki, biz böyük və ya bürokratik şirkətik, yox! Mən burada “korporativ” sözünü o kontekstdə işlətmək istərdim ki, hər bir şirkətin, hər bir məhsulun öz standartları, o cümlədən sizin standartlarınız olmalıdır. Bizdə hansı standartlar var?

  
  

  • Yerləşdirmə cədvəlimiz var. Onsuz heç yerə köçə bilmərik, edə bilmərik. Biz həftədə təxminən 60 dəfə yerləşdiririk, yəni demək olar ki, daim yerləşdiririk. Eyni zamanda, bizdə, məsələn, yerləşdirmə qaydalarında, cümə günü yerləşdirmələr üçün bir tabu var - prinsipcə, biz yerləşdirmirik.
  • Bizə sənəd lazımdır. Heç bir sənəd yoxdursa, heç bir yeni komponent istehsala girmir, hətta bizim RnD-shnikov qələmi altında doğulsa da. Biz onlardan yerləşdirmə təlimatlarını, monitorinq xəritəsini və bu komponentin necə işlədiyini, nasazlığı aradan qaldırmağın təxmini təsvirini (yaxşı, proqramçılar necə yaza bilər) tələb edirik.
  • Biz problemin səbəbini deyil, problemi həll edirik - artıq dediyim şey. İstifadəçini problemlərdən qorumaq bizim üçün vacibdir.
  • İcazələrimiz var. Məsələn, iki dəqiqə ərzində trafikin 2%-ni itirmişiksə, bunu dayanma vaxtı hesab etmirik. Bu, prinsipcə, statistikamıza daxil deyil. Faiz və ya müvəqqəti olaraq daha çox olarsa, biz artıq nəzərə alırıq.
  • Və biz həmişə postmortemlər yazırıq. Başımıza gələn nə olursa olsun, istehsalatda özünü anormal aparan hər hansı bir vəziyyət potsmortemdə öz əksini tapacaq. Postmortem sizə baş verənləri, ətraflı vaxtı, onu düzəltmək üçün nə etdiyinizi və (bu, məcburi blokdur!) Gələcəkdə bunun qarşısını almaq üçün nə edəcəyinizi yazdığınız bir sənəddir. Bu əlavə təhlil üçün vacibdir.

  İstirahət vaxtı nə hesab olunur?

  
  
  Bütün bunlar nəyə gətirib çıxardı?

  Bu, son 6 ayda sabitlik balımızın 99,97 olması ilə nəticələndi (bizim bəzi sabitlik problemlərimiz var idi, bu, müştərilər və ya bizə uyğun gəlmədi). Deyə bilərik ki, bu çox deyil. Bəli, səy göstərməli olduğumuz bir şey var. Bu göstəricinin təxminən yarısı sabitlikdir, sanki bizim deyil, qarşımızda dayanan və xidmət kimi istifadə edilən, lakin müştərilərin buna əhəmiyyət verməyən veb tətbiqi firewallıdır.

  Gecələr yatmağı öyrəndik. Nəhayət! Altı ay əvvəl bacarmadıq. Nəticələrlə birlikdə bu qeyddə bir qeyd etmək istəyirəm. Dünən gecə nüvə reaktorunun idarəetmə sistemi ilə bağlı gözəl hesabat var idi. Bu sistemi yazan insanlar məni eşidirsə, lütfən, “2% boş vaxt deyil” haqqında dediklərimi unut. Sizin üçün iki dəqiqəlik olsa belə, 2% dayanma vaxtıdır!

  Hamısı budur! Suallarınız.

  
  

  Balanslaşdırıcılar və verilənlər bazası miqrasiyası haqqında

  Tamaşaçıların sualı (bundan sonra - B): - Axşamınız xeyir. Belə bir admin hesabatına görə çox sağ olun! Qısa bir sual, balanslaşdırıcılarınız haqqında. Siz qeyd etdiniz ki, sizin WAF var, yəni başa düşdüyüm kimi, balanslaşdırıcı kimi bəzi xarici istifadə edirsiniz ...

  EC: – Xeyr, biz balanslaşdırıcı kimi öz xidmətlərimizdən istifadə edirik. Bu halda, WAF bizim üçün eksklüziv olaraq DDoS qoruma vasitəsidir.

  IN: – Balansçılar haqqında bir neçə söz deyə bilərəmmi?

  EC: - Dediyim kimi, bu, açıq şəkildə olan serverlər qrupudur. İndi eksklüziv olaraq cavab verən 5 lazımsız qrupumuz var ... yəni yalnız açıqlığın quraşdırıldığı server, o, yalnız trafiki etibar edir. Müvafiq olaraq, nə qədər tutduğumuzu başa düşmək üçün: indi müntəzəm trafik axınımız var - bu, bir neçə yüz meqabitdir. Onlar öhdəsindən gəlirlər, yaxşıdırlar, hətta gərginləşmirlər.

  IN: - Həm də sadə bir sual. Budur Mavi/Yaşıl yerləşdirmə. Məsələn, verilənlər bazası köçürmələri ilə nə edirsiniz?

  EC: - Yaxşı sual! Baxın, biz Mavi/Yaşıl yerləşdirmədəyik, hər bir xətt üçün ayrıca növbələrimiz var. Yəni, işçidən işçiyə ötürülən hadisə növbələrindən danışırıqsa, mavi xətt və yaşıl xətt üçün ayrıca növbələr var. Əgər verilənlər bazasının özündən danışırıqsa, onda biz onu bacardığımız qədər bilərəkdən daraltdıq, hər şeyi praktiki olaraq növbələrə keçirdik, yalnız əməliyyat yığınını verilənlər bazasında saxlayırıq. Və bizim əməliyyat yığınımız bütün xətlər üçün eynidir. Bu kontekstdə verilənlər bazası ilə: biz onu mavi və yaşıl rəngə ayırmırıq, çünki kodun hər iki versiyası əməliyyatla nə baş verdiyini bilməlidir.

  Dostlar, sizi həvəsləndirmək üçün başqa kiçik bir mükafatım var - kitab. Ən yaxşı sual üçün onu sizə verməliyəm.

  IN: - Salam. Hesabat üçün təşəkkür edirik. sual budur. Siz ödənişlərə nəzarət edirsiniz, ünsiyyət qurduğunuz xidmətlərə nəzarət edirsiniz... Bəs siz necə nəzarət edirsiniz ki, bir şəxs hansısa yolla sizin ödəniş səhifənizə gəlib, ödəniş edib və layihə ona pul köçürüb? Yəni marchantın əlçatan olmasına və geri zənginizi qəbul etməsinə necə nəzarət edirsiniz?

  EC: - Bu halda bizim üçün "Tacir" ödəniş sistemi ilə tamamilə eyni xarici xidmətdir. Biz tacirin cavab sürətinə nəzarət edirik.

  Verilənlər bazası şifrələməsi haqqında

  IN: - Salam. Bir az sualım var. Həssas PCI DSS məlumatınız var. Bilmək istərdim ki, PAN-ları keçməli olduğunuz növbələrdə necə saxlayırsınız? Siz hansı şifrələmədən istifadə edirsiniz? Və beləliklə, aşağıdakı ikinci sual: PCI DSS-ə görə, dəyişikliklər (inzibatçıların işdən çıxarılması və s.) halında verilənlər bazasını vaxtaşırı yenidən şifrələmək lazımdır - bu halda əlçatanlıq necə baş verir?

  
  
  EC: - Əla sual! Birincisi, biz PAN-ları növbələrdə saxlamırıq. Prinsipcə, PAN-ı hər hansı bir yerdə saxlamaq hüququmuz yoxdur, buna görə də xüsusi xidmətdən istifadə edirik (biz onu “Kademon” adlandırırıq) - bu, yalnız bir şeyi edən bir xidmətdir: giriş olaraq bir mesaj alır və verir. şifrəli mesaj. Və biz hər şeyi bu şifrələnmiş mesajla saxlayırıq. Müvafiq olaraq, bir kilobaytın altındakı açar uzunluğumuz var ki, o, birbaşa ciddi və etibarlı olsun.

  IN: - İndi sizə 2 kilobayt lazımdır?

  EC: - Deyəsən dünən 256 var idi ... Yaxşı, başqa harada ?!

  Müvafiq olaraq, bu, birincidir. İkincisi, mövcud olan həll, yenidən şifrələmə prosedurunu dəstəkləyir - şifrələyən "göyərtələri" verən iki cüt "keks" (açarlar) var (açar açarlar, dek şifrələyən açarların törəmələridir). Prosedurun başlanması halında (mütəmadi olaraq, 3 aydan ± bəzilərinə qədər baş verir), biz yeni bir cüt "keks" yükləyirik və məlumatları yenidən şifrələyirik. Bütün məlumatları çıxaran, onları yeni şəkildə şifrələyən ayrıca xidmətlərimiz var; məlumatların yanında onun şifrələndiyi açarın identifikatoru saxlanılır. Müvafiq olaraq, məlumatları yeni açarlarla şifrələyən kimi köhnə açarı silirik.

  Bəzən ödənişləri əl ilə etmək lazımdır...

  IN: - Yəni hansısa əməliyyat üçün qayıdış gəlibsə, o zaman hələlik onu köhnə açarla deşifrə edin?

  EC: - Bəli.

  IN: “Sonra daha bir kiçik sual. Bir növ uğursuzluq, düşmə, insident baş verdikdə, əməliyyatı əl rejimində itələmək lazımdır. Belə bir vəziyyət var.

  EC: - Bəli, bəzən.

  IN: - Bu məlumatları haradan əldə edirsiniz? Yoxsa sən özün qələmlə bu anbara girirsən?

  EC: - Xeyr, yaxşı, əlbəttə - bizim dəstəyimiz üçün interfeysi ehtiva edən bir növ bek-ofis sistemimiz var. Əgər əməliyyatın hansı vəziyyətdə olduğunu bilmiriksə (məsələn, ödəniş sistemi fasilə ilə cavab verənə qədər), biz apriori bilmirik, yəni yekun statusu yalnız tam əminliklə təyin edirik. Bu halda biz əməliyyatı əl ilə emal üçün xüsusi statusa atırıq. Səhər, ertəsi gün, dəstək belə və belə əməliyyatların ödəniş sistemində qalması barədə məlumat alan kimi, onları bu interfeysdə əl ilə emal edirlər.

  
  
  IN: - Bir-iki sualım var. Onlardan biri PCI DSS zonasının davamıdır: onların dövrələrinin qeydlərini necə çıxarmaq olar? Belə bir sual, çünki tərtibatçı qeydlərə hər hansı bir şey qoya bilər! İkinci sual: düzəlişləri necə yayırsınız? Verilənlər bazasında tutacaqlar - bu bir seçimdir, lakin pulsuz qaynar düzəlişlər ola bilər - orada prosedur nədir? Üçüncü sual isə yəqin ki, RTO, RPO ilə bağlıdır. Əlçatanlığınız 99,97 idi, demək olar ki, dörd doqquz, amma başa düşdüyüm kimi, sizin ikinci məlumat mərkəziniz, üçüncü məlumat mərkəziniz və beşinci məlumat mərkəziniz var ... Onları necə sinxronlaşdırırsınız, təkrarlayır və başqa hər şeyi?

  EC: - Birincidən başlayaq. İlk sual loglarla bağlı idi? Qeydlər yazıldıqda, bütün həssas məlumatları maskalayan bir təbəqəmiz var. O, maskaya və əlavə sahələrə baxır. Müvafiq olaraq, qeydlərimiz artıq maskalanmış məlumatlar və PCI DSS dövrəsi ilə çıxır. Bu, sınaq şöbəsinə verilən müntəzəm tapşırıqlardan biridir. Onlardan hər bir tapşırığı, o cümlədən yazdıqları qeydləri yoxlamaq tələb olunur və bu, tərtibatçının bir şey yazmadığını yoxlamaq üçün kod nəzərdən keçirərkən müntəzəm tapşırıqlardan biridir. Bunun sonrakı yoxlanışı informasiya təhlükəsizliyi şöbəsi tərəfindən mütəmadi olaraq həftədə bir dəfə həyata keçirilir: sonuncu gün üçün jurnallar seçmə qaydada götürülür və hamısını yoxlamaq üçün test serverlərindən xüsusi skaner-analizator vasitəsilə idarə olunur.
  Qaynar düzəlişlər haqqında. Bu, yerləşdirmə qaydalarımıza daxildir. Düzəlişlər haqqında ayrıca maddəmiz var. Biz inanırıq ki, biz ehtiyac duyduğumuz zaman gecə-gündüz düzəlişləri yerləşdiririk. Versiya qurulan kimi, işə salınan kimi, artefaktımız olan kimi - dəstəkdən zəng edən növbətçi sistem administratorumuz var və o, lazım olan anda onu yerləşdirir.

  "Dörd doqquz" haqqında. İndi əldə etdiyimiz rəqəm həqiqətən əldə edildi və biz daha bir məlumat mərkəzində buna çalışırdıq. İndi bizim ikinci məlumat mərkəzimiz var və biz onlar arasında marşrut keçirməyə başlayırıq və məlumat mərkəzinin çarpaz replikasiyası məsələsi həqiqətən də əhəmiyyətsiz bir məsələdir. Biz bunu bir anda müxtəlif vasitələrlə həll etməyə çalışdıq: eyni Tarantuladan istifadə etməyə çalışdıq - bu, bizim üçün işləmir, dərhal deyirəm. Ona görə də biz “hiss”in sırasını əllə etdiyimizə gəldik. Hər bir tətbiqimiz var, əslində, məlumat mərkəzləri arasında lazımi sinxronizasiyanın asinxron rejimində "dəyişiklik - tamamlandı" sürücüləri.

  IN: - Əgər ikinciniz varsa, üçüncüsü niyə görünmədi? Çünki bölünmüş beyin hələ heç kim deyil ...

  EC: "Ancaq bizdə bölünmüş beyin yoxdur." Hər bir proqram multimaster işlətdiyinə görə sorğunun hansı mərkəzə gəlməsi bizim üçün heç bir əhəmiyyət kəsb etmir. Biz məlumat mərkəzlərimizdən birinin qəzaya uğraması (biz buna güvənirik) və istifadəçinin sorğusunun ortasında ikinci məlumat mərkəzinə keçəcəyi halda, həqiqətən də bu istifadəçini itirməyə hazırıq; lakin bunlar vahidlər, mütləq vahidlər olacaq.

  IN: - Axşamınız xeyir. Hesabat üçün təşəkkür edirik. Siz istehsalda bəzi sınaq əməliyyatlarını həyata keçirən sazlayıcınız haqqında danışdınız. Test əməliyyatları haqqında bizə məlumat verin! Nə qədər dərinə gedir?

  EC: “Bu, bütün komponentin tam dövründən keçir. Komponent üçün sınaq əməliyyatı ilə döyüş əməliyyatı arasında heç bir fərq yoxdur. Məntiq nöqteyi-nəzərindən bu, sistemdə yalnız test əməliyyatlarının təqib edildiyi ayrı bir layihədir.

  IN: - Onu haradan kəsirsən? Əsas göndərildi...

  EC: – Sınaq əməliyyatları üçün bu halda “Kor”un arxasındayıq... Bizdə marşrutlaşdırma kimi bir şey var: “Kor” hansı ödəniş sisteminə göndəriləcəyini bilir – biz onu sadəcə http-beat verən saxta ödəniş sisteminə göndəririk və bu da o.

  IN: - Zəhmət olmasa deyin, ərizəniz bir nəhəng monolitdə yazılıb, yoxsa onu hansısa xidmətlərə, hətta mikroservislərə ayırmısınız?

  EC: - Bizdə monolit yoxdur, təbii ki, xidmət yönümlü tətbiqimiz var. Bizdə bir zarafat var ki, monolitlər xidmətimiz var - onlar həqiqətən kifayət qədər böyükdürlər. Mikroservislər onu dil adlandırmaq üçün ümumiyyətlə sözdən dönmür, lakin bunlar paylanmış maşınların işçilərinin işlədiyi xidmətlərdir.

  Əgər serverdə xidmət pozulubsa...

  IN: “Onda növbəti sualım var. Monolit olsa belə, siz yenə də deyirdiniz ki, sizdə bu ani serverlərin çoxu var, onlar hamısı prinsipcə məlumatları emal edir və sual budur: “Əgər ani serverlərdən biri və ya proqram pozulubsa, onlar hər hansı fərdi keçid edir. bir növ giriş nəzarəti varmı? Onlardan hansı nə edə bilər? Kimə müraciət etməli, hansı məlumat üçün?

  
  
  EC: - Bəli, mütləq. Təhlükəsizlik tələbləri olduqca ciddidir. Birincisi, açıq məlumat trafikimiz var və yalnız trafik trafikini nəzərdə tutduğumuz portlar. Komponent verilənlər bazası ilə (məsələn, Muskul) 5-4-3-2 vasitəsilə əlaqə qurarsa, ona yalnız 5-4-3-2 açıq olacaq və digər portlar, digər trafik istiqamətləri mövcud olmayacaq. Bundan əlavə, istehsalımızda təxminən 10 müxtəlif təhlükəsizlik döngəsinin olduğunu başa düşməlisiniz. Tətbiq hər hansı bir şəkildə pozulsa belə, Allah qorusun, təcavüzkar server idarəetmə konsoluna daxil ola bilməyəcək, çünki bu, fərqli bir şəbəkə təhlükəsizlik zonasıdır.

  IN: - Və bu kontekstdə məni daha çox maraqlandıran məqam budur ki, sizin xidmətlərlə hansısa müqaviləniz var - onlar nə edə bilər, hansı "hərəkətlər" vasitəsilə bir-biri ilə əlaqə saxlaya bilər... Və normal bir axın içində bəzi xüsusi xidmətlər tələb olunur. bəziləri sıra, digərində isə "hərəkətlər" siyahısı. Normal vəziyyətdə başqalarına müraciət etmirlər və onların başqa məsuliyyət sahələri var. Onlardan biri güzəştə gedərsə, o, həmin xidmətin “hərəkətlərini” çəkə biləcəkmi? ..

  EC: - Mən başa düşürəm. Normal vəziyyətdə başqa bir serverlə ünsiyyətə ümumiyyətlə icazə verilibsə, bəli. SLA müqaviləsinə əsasən, biz nəzarət etmirik ki, yalnız ilk 3 "fəaliyyət"ə icazə verilir və 4 "fəaliyyət"ə icazə verilmir. Bu, yəqin ki, bizim üçün lazımsızdır, çünki artıq sxemlər üçün prinsipcə 4 səviyyəli mühafizə sistemimiz var. Biz daxili səviyyədə deyil, konturlarla müdafiə etməyə üstünlük veririk.

  Visa, MasterCard və Sberbank necə işləyir

  IN: - İstifadəçinin bir məlumat mərkəzindən digərinə keçməsi ilə bağlı məsələyə aydınlıq gətirmək istəyirəm. Bildiyimə görə, "Visa" və "MasterCard" 8583 binar sinxron protokol üzərində işləyir, orada qarışıqlar var. Bilmək istədim, indi keçidi nəzərdə tuturam - bu, birbaşa "Visa" və "MasterCard"dır, yoxsa ödəniş sistemlərinə, emallara?

  EC: - Qarışıqlardan asılıdır. Bir məlumat mərkəzində qarışıqlarımız var.

  IN: – Kobud desək, bir əlaqə nöqtəniz varmı?

  EC: - "Visa" və "MasterCard" - bəli. Məhz ona görə ki, "Visa" və "MasterCard", məsələn, ikinci cüt qarışıq üçün ayrıca müqavilələr bağlamaq üçün infrastruktura kifayət qədər ciddi investisiyalar tələb edir. Onlar eyni data mərkəzinin daxilində qorunub saxlanılıb, lakin əgər Allah eləməsin, data mərkəzimiz ölürsə, burada Visa və MasterCard-a qoşulmaq üçün qarışıqlar var, onda Visa və MasterCard ilə əlaqəmiz itmiş olacaq...

  IN: Onları necə rezerv etmək olar? Mən bilirəm ki, "Visa" prinsipcə yalnız bir əlaqə saxlamağa imkan verir!

  EC: “Avadanlıqları özləri verirlər. İstənilən halda içəridə ironiya ilə qorunan avadanlıq aldıq.

  IN: – Yəni stend onların Connects Orange-dandır...?

  EC: - Bəli.

  IN: - Və bu halda necə: məlumat mərkəziniz yox olarsa, ondan necə istifadə etməyə davam edə bilərsiniz? Yoxsa nəqliyyatın hərəkəti dayandırılıb?

  EC: - Yox. Bu halda biz sadəcə olaraq trafiki başqa kanala keçirəcəyik ki, bu da təbii ki, bizim üçün, müştərilər üçün daha baha olacaq. Ancaq trafik Visa, MasterCard ilə birbaşa əlaqəmizdən deyil, şərti Sberbank vasitəsilə (çox şişirdilmiş) keçəcək.

  Sberbank işçilərini incitmişəmsə, çox üzr istəyirəm. Ancaq statistikamıza görə, Rusiya bankları arasında ən çox Sberbank düşür. Bir ay keçmir ki, Sberbank-da bir şey düşməsin.

  
  
  

  Bəzi reklamlar 🙂

  Bizimlə qaldığınız üçün təşəkkür edirik. Məqalələrimiz xoşunuza gəlirmi? Daha maraqlı məzmun görmək istəyirsiniz? Sifariş verməklə və ya dostlarınıza tövsiyə etməklə bizə dəstək olun, developers üçün bulud VPS 4.99 dollardan, Sizin üçün bizim tərəfimizdən icad edilmiş giriş səviyyəli serverlərin unikal analoqu: VPS (KVM) E5-2697 v3 (6 nüvəli) 10GB DDR4 480GB SSD 1Gbps haqqında 19 dollardan bütün həqiqət və ya serveri necə paylaşmaq olar? (RAID1 və RAID10, 24 nüvəyə qədər və 40 GB DDR4 ilə mövcuddur).

  Dell R730xd Amsterdamdakı Equinix Tier IV məlumat mərkəzində 2 dəfə ucuzdur? Yalnız burada 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV 199$-dan başlayan qiymətlərlə Hollandiyada! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollardan! haqqında oxuyun İnfrastruktur korporasiyasını necə qurmaq olar. bir qəpik üçün 730 avro dəyərində Dell R5xd E2650-4 v9000 serverlərinin istifadəsi ilə sinif?

Mənbə: www.habr.com