Bu günə qədər Bitrix24 xidmətində yüzlərlə gigabit trafik yoxdur, nəhəng server parkı yoxdur (baxmayaraq ki, əlbəttə ki, mövcud olanlar kifayət qədərdir). Ancaq bir çox müştərilər üçün bu, şirkətdə işləmək üçün əsas vasitədir, bu, real biznes üçün kritik bir tətbiqdir. Buna görə də düşmək mümkün deyil. Bəs payız baş versə, amma xidmət o qədər tez "dirildi" ki, heç kim heç nə görmədi? Və işin keyfiyyətini və müştərilərin sayını itirmədən uğursuzluğu necə həyata keçirmək olar? Bitrix24-ün bulud xidmətlərinin direktoru Aleksandr Demidov, məhsulun mövcud olduğu 7 il ərzində rezervasiya sisteminin necə inkişaf etdiyi barədə bloqumuz üçün danışdı.
“SaaS şəklində Bitrix24-ü 7 il əvvəl işə saldıq. Əsas çətinlik, ehtimal ki, aşağıdakılar idi: SaaS şəklində ictimaiyyətə təqdim edilməzdən əvvəl bu məhsul sadəcə qutulu həll formatında mövcud idi. Müştərilər onu bizdən aldılar, öz serverlərində yerləşdirdilər, korporativ portal yaratdılar - işçilərlə ünsiyyət, faylların saxlanması, tapşırıqların idarə edilməsi, CRM üçün ümumi həll, hamısı budur. Və biz 2012-ci ilə kimi qərara gəldik ki, onu SaaS kimi işə salmaq, onu özümüz idarə edərək, nasazlığa dözümlülük və etibarlılığı təmin etmək istəyirik. Prosesdə təcrübə qazandıq, çünki o vaxta qədər bizdə sadəcə olaraq bu yox idi - biz yalnız proqram istehsalçısı idik, xidmət təminatçıları deyildik.
Xidməti işə salarkən başa düşdük ki, ən başlıcası, xidmətin nasazlıqlara qarşı dözümlülüyünü, etibarlılığını və daimi əlçatanlığını təmin etməkdir, çünki məsələn, sadə bir adi veb saytınız, mağazanız varsa və o, bir saat ərzində çökür və yatırsa, yalnız özünüz əziyyət çəkirsiniz, sifarişləri itirirsiniz, müştəriləri itirirsiniz, lakin müştərinizin özü üçün bu, onun üçün çox da vacib deyil. O, təbii ki, üzüldü, amma gedib başqa saytdan aldı. Və əgər bu, şirkət daxilindəki bütün işlərin, kommunikasiyaların, həll yollarının bağlı olduğu bir proqramdırsa, ən əsası istifadəçilərin etibarını qazanmaq, yəni onları ruhdan salmamaq və yıxılmamaqdır. Çünki içəridə bir şey işləməsə, bütün işlər qalxa bilər.
Bitrix.24 SaaS olaraq
İlk prototipi ictimaiyyətə təqdim edilməzdən bir il əvvəl, 2011-ci ildə yığdıq. Təxminən bir həftə ərzində yığdılar, baxdılar, bükdülər - hətta işləyirdi. Yəni forma daxil olmaq, portalın adını ora daxil etmək mümkün olub, yeni portal yerləşdirilib, istifadəçi bazası işə salınıb. Biz ona baxdıq, məhsulu prinsipcə qiymətləndirdik, söndürdük və bir il ərzində daha da təkmilləşdirdik. Çünki bizim böyük vəzifəmiz var idi: iki fərqli kod bazası yaratmaq istəmədik, ayrıca qutulu məhsulu, ayrı bulud həllərini dəstəkləmək istəmədik, bütün bunları bir kod daxilində etmək istədik.
O dövrdə tipik bir veb proqram bir növ php kodunun, mysql verilənlər bazasının işlədiyi, faylların yükləndiyi, sənədlərin, şəkillərin yükləmə qovluğuna yerləşdirildiyi bir serverdir - yaxşı, hamısı işləyir. Təəssüf ki, bununla bağlı kritik dərəcədə sabit veb xidmətini idarə etmək mümkün deyil. Orada paylanmış keş dəstəklənmir, verilənlər bazası replikasiyası dəstəklənmir.
Tələblərimizi tərtib etdik: bu, müxtəlif yerlərdə yerləşmək, replikasiyanı dəstəkləmək, ideal olaraq, müxtəlif coğrafi olaraq paylanmış məlumat mərkəzlərində yerləşmək qabiliyyətidir. Məhsulun məntiqini və əslində məlumatların saxlanmasını ayırın. Dinamik olaraq yükə görə ölçə bilmək, ümumiyyətlə statikanı çıxarmaq. Bu mülahizələrdən əslində məhsula olan tələblər formalaşdı ki, biz bunu cəmi bir ildir yekunlaşdırdıq. Bu müddət ərzində vahid olduğu ortaya çıxan bir platformada - qutulu həllər, öz xidmətimiz üçün - ehtiyac duyduğumuz şeylərə dəstək verdik. Məhsulun özü səviyyəsində mysql replikasiyasına dəstək: yəni kodu yazan tərtibatçı öz sorğularının necə paylanacağını düşünmür, o bizim api-dən istifadə edir və biz master və slave arasında yazı və oxu sorğularını düzgün paylaya bilirik. .
Biz müxtəlif bulud obyektlərinin saxlanması üçün məhsul səviyyəsində dəstək etdik: google yaddaşı, amazon s3, - plus, açıq stack swift üçün dəstək. Buna görə də, bu həm bir xidmət olaraq, həm də qutu həlli ilə işləyən tərtibatçılar üçün əlverişli idi: əgər onlar sadəcə iş üçün api-dən istifadə etsələr, faylın nəhayət harada, yerli olaraq fayl sistemində və ya fayl sistemində saxlanacağını düşünmürlər. obyekt fayl yaddaşına daxil olun.
Nəticədə, biz dərhal bütün məlumat mərkəzi səviyyəsində ehtiyat nüsxəsini çıxaracağımıza qərar verdik. 2012-ci ildə biz tamamilə Amazon AWS-də işə başladıq, çünki bu platforma ilə artıq təcrübəmiz var idi - öz saytımız orada yerləşdirilmişdi. Amazonun hər bölgəsində bir neçə əlçatanlıq zonasının olması bizi cəlb etdi - əslində (onların terminologiyasında) bir-birindən az və ya çox müstəqil olan və bizə bütün məlumat səviyyəsində rezerv etməyə imkan verən bir neçə məlumat mərkəzi. mərkəz: birdən uğursuz olarsa, verilənlər bazası master-master tərəfindən təkrarlanır, veb proqram serverləri qorunur və statik s3 obyekt yaddaşına köçürülür. Yük balanslaşdırılmışdır - o zaman Amazonun dirsəyi ilə, lakin bir az sonra öz balanslaşdırıcılarımıza gəldik, çünki bizə daha mürəkkəb məntiq lazım idi.
Nə istədilər, aldılar...
Təqdim etmək istədiyimiz bütün əsas şeylər - serverlərin özlərindəki nasazlığa dözümlülük, veb proqramlar, verilənlər bazası - hər şey yaxşı işləyirdi. Ən sadə ssenari: veb proqramlarından biri uğursuz olarsa, hər şey sadədir - onlar balansdan çıxarılır.
Uğursuz maşınların özünü qeyri-sağlam olaraq qeyd edən balanslaşdırıcı (sonra Amazonun dirsəkləri idi) onlarda yük paylamasını söndürdü. Amazon autoscaling işlədi: yük böyüdükdə, avtomatik miqyaslı qrupa yeni avtomobillər əlavə edildi, yük yeni avtomobillərə paylandı - hər şey yaxşı idi. Balanslaşdırıcılarımızla məntiq təxminən eynidir: proqram serverinə bir şey olarsa, ondan sorğuları silir, bu maşınları atırıq, yenilərini işə salırıq və işləməyə davam edirik. Sxem illər ərzində bir az dəyişdi, lakin işləməyə davam edir: sadə, başa düşüləndir və bununla bağlı heç bir çətinlik yoxdur.
Biz bütün dünyada işləyirik, müştəri yükünün pik hədləri tamamilə fərqlidir və yaxşı mənada sistemimizin hər hansı komponentlərində istənilən vaxt müəyyən xidmət işlərini həyata keçirə bilməliyik - müştərilər üçün nəzərəçarpacaq dərəcədə. Buna görə də, ikinci məlumat mərkəzinə yükü yenidən bölüşdürərək verilənlər bazasını bağlamaq imkanımız var.
Hamısı necə işləyir? - Trafiki işləyən məlumat mərkəzinə keçirik - əgər bu məlumat mərkəzində qəzadırsa, tamamilə, əgər bu hər hansı bir verilənlər bazası ilə planlaşdırdığımız işdirsə, o zaman bu müştərilərə xidmət göstərən trafikin bir hissəsini ikinci data mərkəzinə keçiririk, dayandırılmış replikasiyadır. Veb proqramları üçün yeni maşınlara ehtiyac olarsa, ikinci məlumat mərkəzinin yükü artdığından, onlar avtomatik olaraq işə düşəcəklər. İşi bitiririk, təkrarlama bərpa olunur və bütün yükü geri qaytarırıq. İkinci DC-də bəzi işləri əks etdirmək lazımdırsa, məsələn, sistem yeniləmələrini quraşdırın və ya ikinci verilənlər bazasında parametrləri dəyişdirin, onda ümumiyyətlə, eyni şeyi təkrar edirik, sadəcə digər istiqamətdə. Və əgər bu qəzadırsa, onda biz hər şeyi sadə edirik: monitorinq sistemində hadisələrin idarə edilməsi mexanizmindən istifadə edirik. Əgər bizim üçün bir neçə yoxlama işləyirsə və status kritik vəziyyətə düşərsə, bu işləyici işə salınır, bu və ya digər məntiqi yerinə yetirə bilən işləyici. Hər bir verilənlər bazası üçün biz onun üçün hansı serverin uğursuz olduğunu və əlçatmaz olduqda trafiki hara dəyişdirəcəyini yazdıq. Biz - tarixən baş verdiyi kimi - nagios və ya onun çəngəllərindən bu və ya digər formada istifadə edirik. Prinsipcə, demək olar ki, hər hansı bir monitorinq sistemində oxşar mexanizmlər var, biz hələ daha mürəkkəb bir şey istifadə etmirik, amma bəlkə nə vaxtsa edəcəyik. İndi monitorinq əlçatan olmamaqla işə salınır və nəyisə dəyişmək imkanına malikdir.
Hər şeyi rezerv etmişik?
Bizim ABŞ-dan çoxlu müştərimiz var, Avropadan çoxlu müştərimiz var, Şərqə daha yaxın olan çoxlu müştərilərimiz var - Yaponiya, Sinqapur və s. Əlbəttə ki, Rusiyada müştərilərin böyük bir hissəsi. Yəni iş bir rayondan uzaqdır. İstifadəçilər tez cavab istəyirlər, müxtəlif yerli qanunlara riayət etmək üçün tələblər var və hər bir regionda biz iki məlumat mərkəzi rezerv edirik, üstəlik bir neçə əlavə xidmət var ki, onlar yenə də bir regionda rahat şəkildə yerləşdirilir - bu regionda olan müştərilər üçün işləyirlər. REST işləyiciləri, avtorizasiya serverləri, ümumiyyətlə müştərinin işi üçün daha az kritikdirlər, kiçik bir məqbul gecikmə ilə onların üzərinə keçə bilərsiniz, ancaq təkəri yenidən kəşf etmək istəmirsiniz, onlara necə nəzarət etmək və onlarla nə etmək lazımdır. Buna görə də, biz mövcud həllərdən maksimum istifadə etməyə çalışırıq və əlavə məhsullarda bir növ səriştə inkişaf etdirməyək. Və haradasa dns səviyyəsində keçiddən istifadə edirik və xidmətin canlılığı eyni dns ilə müəyyən edilir. Amazon-da Route 53 xidməti var, lakin bu, sadəcə qeydlər edə biləcəyiniz dns deyil və bu, daha çevik və rahatdır. Onun vasitəsilə siz müştərinin haradan gəldiyini müəyyən etmək və ona müəyyən qeydlər vermək üçün istifadə etdiyiniz zaman geolokasiyalarla geo-paylanmış xidmətlər qura bilərsiniz - siz ondan uğursuzluq arxitekturası qurmaq üçün istifadə edə bilərsiniz. Eyni sağlamlıq yoxlamaları 53 nömrəli marşrutun özündə konfiqurasiya edilmişdir, siz nəzarət edilən son nöqtəni təyin edirsiniz, ölçüləri təyin edirsiniz, xidmətin "canlılığını" müəyyən etmək üçün hansı protokolları təyin edirsiniz - tcp, http, https; xidmətin canlı olub olmadığını müəyyən edən yoxlamaların tezliyini təyin edin. Və dns-in özündə nəyin əsas olacağını, nəyin ikinci dərəcəli olacağını, 53 nömrəli marşrut daxilində sağlamlıq yoxlaması işləyirsə, hara keçid edəcəyinizi təyin edirsiniz. Bütün bunları bəzi başqa alətlərlə də etmək olar, amma daha rahat olanı odur ki, biz onu quraşdırırıq. bir dəfə və sonra bu barədə heç düşünməyin, biz yoxlamaları necə edirik, necə dəyişirik: hər şey öz-özünə işləyir.
İlk "amma": 53-cü marşrutun özünü necə və necə bron etmək olar? Heç bilmirsən, birdən ona nəsə olur? Xoşbəxtlikdən, biz heç vaxt bu dırmıq üzərində addım atmamışıq, amma yenə də qarşımda bir hekayəm olacaq ki, niyə hələ də ehtiyata ehtiyacımız olduğunu düşündük. Burada əvvəlcədən özümüz üçün saman düzəldirik. Gündə bir neçə dəfə 53 nömrəli marşrutda mövcud olan bütün zonaların tam boşaldılmasını həyata keçiririk. Amazon API onları asanlıqla JSON-a göndərməyə imkan verir və biz onu çevirdiyimiz, konfiqurasiya şəklində yüklədiyimiz və təxmini desək, ehtiyat konfiqurasiyaya malik olduğumuz bir neçə ehtiyat serverimiz var. Bu halda, dns parametrləri məlumatlarını itirmədən onu tez bir zamanda əl ilə yerləşdirə bilərik.
İkinci "amma": Bu şəkildə hələ nə qorunmayıb? Balanslaşdırıcı! Müştərilərimizin bölgələrə görə bölgüsü çox sadədir. Bizim bitrix24.ru, bitrix24.com, .de domenlərimiz var - indi müxtəlif zonalarda işləyən 13 fərqli domen var. Biz aşağıdakılara gəldik: hər bölgənin öz balanslaşdırıcıları var. Beləliklə, şəbəkədə pik yükün harada olmasından asılı olaraq bölgələr üzrə paylamaq daha rahatdır. Bu, hər hansı bir balanslaşdırıcı səviyyəsində bir uğursuzluqdursa, o, sadəcə olaraq istismardan çıxarılır və dns-dən çıxarılır. Əgər balanslaşdırıcılar qrupunda hansısa problem yaranarsa, o zaman onlar başqa saytlarda qorunur və onlar arasında keçid eyni marşrutdan istifadə etməklə həyata keçirilir53, çünki qısa ttl səbəbindən keçid maksimum 2, 3, 5 dəqiqə ərzində baş verir.
Üçüncü "amma": hələ nə rezerv edilməyib? S3 düzgündür. Biz istifadəçilərlə saxladığımız faylları s3-də yerləşdirərək, bunun zireh deşici olduğuna və orada heç nə saxlamağa ehtiyac olmadığına ürəkdən inandıq. Ancaq tarix göstərir ki, hər şey fərqlidir. Ümumiyyətlə, Amazon S3-ü fundamental xidmət kimi təsvir edir, çünki Amazon özü S3-dən maşın şəkillərini, konfiqurasiyaları, AMI şəkillərini, snapshotları saxlamaq üçün istifadə edir... Və əgər s3 bu 7 ildə bir dəfə olduğu kimi düşsə, biz nə qədər bitrix24 olmuşuq. işləyəcək, hər şeyin bir dəstəsini çıxaracaq - virtual maşınların işə salınmasının əlçatmazlığı, api-nin uğursuzluğu və s.
Və S3 düşə bilər - bir dəfə oldu. Buna görə də, biz aşağıdakı sxemə gəldik: bir neçə il əvvəl Rusiyada ciddi obyekt ictimai depoları yox idi və biz özümüz üçün nəsə etmək variantını nəzərdən keçirdik ... Xoşbəxtlikdən, biz bunu etməyə başlamadıq, çünki bizdə olacaqdı. Bizdə olmayan ekspertizanın içinə qazılmış və yəqin ki, qarışmış olardıq. İndi Mail.ru-da s3-ə uyğun yaddaş var, Yandex-də və bir sıra digər provayderlərdə də var. Nəhayət, belə bir nəticəyə gəldik ki, birincisi, artıqlığa, ikincisi, yerli nüsxələrlə işləmək bacarığına sahib olmaq istəyirik. Müəyyən bir Rusiya bölgəsi üçün biz s3 ilə uyğun API olan Mail.ru Hotbox xidmətindən istifadə edirik. Tətbiq daxilində kodda heç bir ciddi təkmilləşdirməyə ehtiyacımız yox idi və biz aşağıdakı mexanizmi yaratdıq: s3-də obyektlərin yaradılması/silinməsi üzərində işləyən tetikleyiciler var, Amazon-un Lambda kimi bir xidməti var - bu icra ediləcək serversiz kodun işə salınmasıdır. yalnız müəyyən tetikleyiciler tetiklendiğinde.
Biz bunu çox sadə etdik: əgər trigger bizim üçün işləyirsə, obyekti Mail.ru yaddaşına köçürəcək kodu icra edirik. Yerli məlumat nüsxələri ilə işə tam başlamaq üçün bizə əks sinxronizasiya da lazımdır ki, Rusiya seqmentində olan müştərilər onlara daha yaxın olan yaddaşla işləyə bilsinlər. Mail öz deposunda tetikleyicileri tamamlamaq üzrədir - infrastruktur səviyyəsində tərs sinxronizasiya həyata keçirmək mümkün olacaq, lakin hələlik biz bunu öz kodumuz səviyyəsində edirik. Müştərinin hansısa faylı yerləşdirdiyini görsək, o zaman hadisəni kod səviyyəsində növbəyə qoyur, onu emal edirik və əks replikasiya edirik. Niyə pisdir: əgər məhsulumuzdan kənarda, yəni hansısa xarici vasitələrlə obyektlərimizlə bir növ işimiz varsa, bunu nəzərə almayacağıq. Ona görə də biz sona qədər gözləyirik ki, yaddaş səviyyəsində tetikler olacaq ki, kodu haradan icra etməyimizdən asılı olmayaraq, bizə çatan obyekt qarşı tərəfə kopyalansın.
Kod səviyyəsində hər bir müştəri üçün hər iki anbarımız var: biri əsas hesab olunur, digəri ehtiyatdır. Hər şey yaxşıdırsa, biz bizə daha yaxın olan anbarla işləyirik: yəni Amazonda olan müştərilərimiz S3 ilə, Rusiyada işləyənlər isə Hotbox ilə işləyirlər. Əgər bayraq işə salınarsa, o zaman uğursuzluq bizə qoşulmalıdır və biz müştəriləri başqa yaddaşa keçirik. Biz bu bayrağı müstəqil olaraq bölgəyə görə təyin edə bilərik və onları irəli və geri dəyişə bilərik. Praktikada bu hələ istifadə olunmayıb, lakin bu mexanizm təmin edilib və düşünürük ki, nə vaxtsa bu keçid bizə lazım olacaq və lazımlı olacaq. Artıq bir dəfə belə olub.
Oh, və Amazonunuz qaçdı ...
Bu aprel Rusiyada Telegram-ın bloklanmasının ildönümüdür. Bundan ən çox təsirlənən provayder Amazondur. Və təəssüf ki, bütün dünya üçün işləyən Rusiya şirkətləri daha çox əziyyət çəkdi.
Əgər şirkət qlobaldırsa və Rusiya onun üçün çox kiçik bir seqmentdirsə, 3-5% - yaxşı, bu və ya digər şəkildə, onları bağışlaya bilərsiniz.
Əgər bu, sırf Rusiya şirkətidirsə - əminəm ki, yerli olaraq yerləşdirilməlidir - yaxşı, sadəcə olaraq, istifadəçilərin özləri rahat, rahat olacaq, risklər daha az olacaq.
Bəs bu, qlobal miqyasda fəaliyyət göstərən bir şirkətdirsə və onun Rusiyadan və dünyanın hər yerindən təxminən bərabər sayda müştərisi varsa, necə? Seqmentlərin əlaqəsi vacibdir və onlar bir-biri ilə bu və ya digər şəkildə işləməlidirlər.
2018-ci ilin mart ayının sonunda Roskomnadzor ən böyük operatorlara məktub göndərdi ki, onlar Zello messencerini bloklamaq üçün bir neçə milyon Amazon IP-ni bloklamağı planlaşdırırlar. Məhz bu provayderlər sayəsində - onlar məktubu hər kəsə uğurla sızdırdılar və Amazon ilə əlaqənin dağılacağı anlayışı var idi. Cümə günü idi, çaxnaşma içində servers.ru-dan olan həmkarlarımızın yanına qaçdıq və dedik: "Dostlar, bizə Rusiyada olmayacaq, Amazonda deyil, məsələn, Amsterdamda olmayan bir neçə server lazımdır" Heç bir şəkildə təsir edə bilməyəcəyimiz bəzi son nöqtələr üçün, məsələn, eyni s3-ün son nöqtələri üçün heç olmasa bir şəkildə öz vpn və proksimizi oraya qoya bilmək üçün - yeni bir xidmət qaldırmağa və fərqli bir xidmət əldə etməyə cəhd edə bilməzsiniz. ip, hələ də ora çatmalıyıq. Bir neçə gün ərzində biz bu serverləri quraşdırdıq, onları qaldırdıq və ümumiyyətlə, bloklama başlayana qədər hazırlaşmışdıq. Maraqlıdır ki, RKN yüksələn şırınga və çaxnaşmaya baxaraq: "Xeyr, indi heç nəyə mane olmaq fikrində deyilik" dedi. (Ancaq bu, teleqramları bloklamağa başlayana qədərdir.) Dolama variantlarını quraraq və bloklamanın tətbiq olunmadığını başa düşərək, biz hər şeyi təhlil etməyə başlamadıq. Bəli, hər halda.
2019-cu ildə isə hələ də bloklanma şəraitində yaşayırıq. Dünən axşam baxdım: bir milyona yaxın ip bloklanmağa davam edir. Düzdür, Amazon demək olar ki, tamamilə blokdan çıxarılmışdı, zirvədə 20 milyon ünvana çatmışdı... Ümumiyyətlə, reallıq budur ki, əlaqə, yaxşı əlaqə olmaya bilər. Birdən. Bu, texniki səbəblərdən olmaya bilər - yanğınlar, ekskavatorlar, bütün bunlar. Və ya, gördüyümüz kimi, o qədər də texniki deyil. Buna görə də, böyük və böyük kimsə, öz AS-ləri ilə, yəqin ki, onu başqa yollarla idarə edə bilər - birbaşa əlaqə və digər şeylər artıq l2 səviyyəsindədir. Ancaq sadə versiyada, bizim kimi və ya daha kiçik, hər halda, başqa bir yerdə qaldırılmış, əvvəlcədən vpn, proxy konfiqurasiya edilmiş serverlər səviyyəsində ehtiyatınız ola bilər, bu seqmentlərdə konfiqurasiyanı tez bir zamanda onlara dəyişdirmək imkanı ilə. əlaqə baxımından kritikdir. Bu, Amazon blokları başlayanda bir dəfədən çox bizim üçün faydalı oldu, biz ən pis halda S3 trafikinə icazə verdik, lakin tədricən hamısı dağıldı.
Və bütün provayderi necə rezerv etmək olar?
Hal-hazırda, bütün Amazonun uğursuzluğu üçün bir ssenarimiz yoxdur. Rusiya üçün də oxşar ssenarimiz var. Rusiyada bir neçə sayta sahib olmağı seçdiyimiz bir provayder tərəfindən qəbul edildik. Və bir il əvvəl bir problemlə qarşılaşdıq: bunlar iki məlumat mərkəzi olsa da, provayderin şəbəkə konfiqurasiyası səviyyəsində onsuz da hər iki məlumat mərkəzinə təsir edəcək problemlər ola bilər. Və hər iki saytda əlçatmazlıq əldə edə bilərik. Təbii ki, belə də olub. Sonda içəridəki arxitekturaya yenidən baxdıq. Çox dəyişmədi, amma Rusiya üçün indi bir provayderdən deyil, iki fərqli saytdan olan iki saytımız var. Biri uğursuz olarsa, digərinə keçə bilərik.
Hipotetik olaraq, Amazon üçün başqa bir provayder səviyyəsində rezervasiya imkanını nəzərdən keçiririk; bəlkə Google, bəlkə başqası... Amma indiyə qədər biz təcrübədə müşahidə etmişik ki, Amazonda bir əlçatanlıq zonası səviyyəsində qəzalar varsa, o zaman bütün region səviyyəsində qəzalar olduqca nadirdir. Buna görə nəzəri olaraq Amazon deyil, Amazon rezervasiyası edə biləcəyimiz barədə bir fikrimiz var, amma praktikada hələ belə bir şey yoxdur.
Avtomatlaşdırma haqqında bir neçə kəlmə
Avtomatlaşdırma həmişə lazımdırmı? Burada Dunning-Kruger effektini xatırlatmaq yerinə düşər. X oxunda əldə etdiyimiz bilik və təcrübəmiz, y oxunda isə hərəkətlərimizə inam var. Əvvəlcə heç nə bilmirik və heç də əmin deyilik. Sonra bir az bilirik və meqa-inamlı oluruq - bu, "ağılsızlıq və cəsarət" şəkli ilə yaxşı təsvir olunan "axmaqlığın zirvəsidir". Onda biz artıq bir az öyrənmişik və döyüşə getməyə hazırıq. Sonra bir növ meqa-ciddi dırmıqla addımlayırıq, bir şey bildiyimiz zaman ümidsizlik vadisinə düşürük, amma əslində çox şey bilmirik. Sonra təcrübə qazandıqca özümüzə inamımız artır.
Müxtəlif qəzaların avtomatik olaraq müəyyən qəzalara keçməsi ilə bağlı məntiqimiz bu qrafikdə çox yaxşı təsvir edilmişdir. Başladıq - necə olduğunu bilmirdik, demək olar ki, bütün işlər əl ilə aparılırdı. Sonra başa düşdük ki, hər şeyə avtomat qoya bilərsən və dinc yatmaq olar. Və birdən biz meqa-rake addımlayırıq: yalan pozitiv bizim üçün işləyir və biz yaxşı mənada bunu etməməli olduğumuz halda trafiki irəli-geri dəyişirik. Nəticə etibarilə, replikasiya pozulur və ya başqa bir şey - bu, ümidsizlik vadisidir. Və sonra başa düşürük ki, hər şeyə ağıllı yanaşmaq lazımdır. Yəni, yanlış pozitivlərin mümkünlüyünü təmin edən avtomatlaşdırmaya etibar etmək məntiqlidir. Amma! Əgər nəticələr dağıdıcı ola bilərsə, onu həqiqətən də qəza olduğuna və lazımi hərəkətlərin əl ilə yerinə yetiriləcəyinə əmin olacaq növbətçi növbənin, növbətçi mühəndislərin mərhəmətinə buraxmaq daha yaxşıdır ...
Nəticə
7 ildir ki, bir şey düşəndə panika-çaxnaşma olmasından, heç bir problem olmadığını, yalnız tapşırıqların olduğunu, onların həll edilməli olduğunu və həll oluna biləcəyini başa düşməyə keçdik. Bir xidmət qurarkən ona yuxarıdan baxın, baş verə biləcək bütün riskləri qiymətləndirin. Onları dərhal görsəniz, artıqlığı və nasazlığa dözümlü infrastrukturun qurulması imkanını əvvəlcədən planlaşdırın, çünki uğursuz ola biləcək və xidmətin işləməməsinə səbəb olan hər hansı bir nöqtə mütləq bunu edəcəkdir. Sizə elə görünsə də, infrastrukturun bəzi elementləri mütləq uğursuz olmayacaq - məsələn, eyni s3, yenə də unutmayın ki, edə bilərlər. Ən azı nəzəri olaraq, bir şey baş verərsə, onlarla nə edəcəyiniz barədə bir fikrə sahib olun. Risk idarəetmə planına sahib olun. Hər şeyi avtomatik və ya əl ilə etmək barədə düşünəndə, riskləri qiymətləndirin: avtomatlaşdırma hər şeyi dəyişdirməyə başlasa, nə baş verəcək - bu, qəza ilə müqayisədə daha pis mənzərəyə səbəb olmayacaqmı? Ola bilsin ki, bir yerdə avtomatlaşdırmanın istifadəsi ilə həqiqi mənzərəni qiymətləndirəcək və bir şeyin yolda və ya “bəli, amma indi deyil” dəyişdirilməsinin lazım olub olmadığını başa düşəcək növbətçi mühəndisin reaksiyası arasında ağlabatan bir kompromisdən istifadə etməlisiniz.
Mükəmməllik və real qüvvələr arasında ağlabatan bir uzlaşma, nəhayət əldə edəcəyiniz sxemə sərf edə biləcəyiniz vaxt, pul.
Bu mətn Aleksandr Demidovun konfransdakı məruzəsinin əlavə və genişləndirilmiş variantıdır .
Mənbə: www.habr.com