Барлығы әзірлеу және тестілеу, персоналды оқыту, мотивацияны арттыру процестері туралы айтады, бірақ қызмет көрсетудің бір минуттық тоқтап қалуы орасан зор ақшаны қажет ететін кезде бұл процестер жеткіліксіз. Қатаң SLA бойынша қаржылық операцияларды жүзеге асырған кезде не істеу керек? Теңдеуден әзірлеу мен тестілеуді алып тастап, жүйелеріңіздің сенімділігі мен ақауларға төзімділігін қалай арттыруға болады?
Келесі HighLoad++ конференциясы 6 жылдың 7 және 2020 сәуірінде Санкт-Петербургте өтеді. Мәліметтер мен билеттер . 9 қараша, 18:00. HighLoad++ Мәскеу 2018, Дели + Колката залы. Тезистер және .
Евгений Кузовлев (бұдан әрі – ЕК): - Достар, сәлем! Менің атым Кузовлев Евгений. Мен EcommPay компаниясынанмын, нақты бөлімше - EcommPay IT, компаниялар тобының АТ бөлімі. Ал бүгін біз тоқтап қалулар туралы - оларды болдырмау туралы, егер оны болдырмау мүмкін болмаса, олардың салдарын қалай азайтуға болатыны туралы сөйлесетін боламыз. Тақырып келесідей баяндалған: «Бір минут тоқтап қалу 100 000 доллар тұратын кезде не істеу керек»? Алға қарасақ, санымыз салыстырмалы.
EcommPay IT не істейді?
Біз кімбіз? Неге мен сенің алдыңда тұрмын? Неліктен бұл жерде саған бірдеңе айтуға құқығым бар? Және бұл жерде не туралы толығырақ сөйлесеміз?
EcommPay компаниялар тобы халықаралық эквайер болып табылады. Біз төлемдерді бүкіл әлем бойынша өңдейміз - Ресейде, Еуропада, Оңтүстік-Шығыс Азияда (Бүкіл әлем бойынша). Бізде 9 кеңсе, барлығы 500 қызметкер бар және олардың жартысынан сәл азы IT мамандары. Біз не істесек те, ақша табамыз да, өзіміз істедік.
Біз өз өнімдерімізді өзіміз жаздық (және бізде олардың көпшілігі бар – біздің ірі IT өнімдер қатарында шамамен 16 түрлі құрамдас бөліктер бар); Біз өзіміз жазамыз, өзімізді дамытамыз. Ал қазір біз күніне миллионға жуық транзакцияны жүзеге асырамыз (миллион деп айту дұрыс шығар). Біз өте жас компаниямыз – жасымызға небәрі алты жаста.
6 жыл бұрын жігіттер бизнеспен бірге келген кезде осындай стартап болды. Оларды идея біріктірді (ойдан басқа ештеңе жоқ), біз жүгірдік. Кез келген стартап сияқты біз жылдамырақ жүгірдік... Біз үшін сапаға қарағанда жылдамдық маңызды болды.
Бір сәтте біз тоқтап қалдық: біз бұдан былай бұл жылдамдықпен және сапада өмір сүре алмайтынымызды түсіндік және алдымен сапаға назар аудару керек. Осы сәтте біз дұрыс, ауқымды және сенімді болатын жаңа платформа жазуды шештік. Олар бұл платформаны жазуды бастады (олар инвестициялауды, әзірлеуді, тестілеуді бастады), бірақ бір сәтте олар әзірлеу мен тестілеу бізге қызмет көрсету сапасының жаңа деңгейіне жетуге мүмкіндік бермегенін түсінді.
Сіз жаңа өнім жасайсыз, оны өндіріске енгізесіз, бірақ бәрібір бір жерде бір нәрсе дұрыс емес. Ал бүгін біз жаңа сапа деңгейіне қалай жетуге болатыны туралы сөйлесетін боламыз (біз оны қалай орындадық, тәжірибеміз туралы), даму мен тестілеуді теңдеуден алып тастаймыз; біз жұмыс істеуге болатын нәрсе туралы сөйлесетін боламыз - қандай операция өзі жасай алады, сапаға әсер ету үшін тестілеуге не ұсына алады.
Тоқтаулар. Операция туралы бұйрықтар.
Әрқашан негізгі ірге тасы, біз бүгін нақты айтатын нәрсе - тоқтап қалу. Қорқынышты сөз. Егер бізде бос уақыт болса, біз үшін бәрі жаман. Біз оны көтеру үшін жүгіріп жатырмыз, админдер серверді ұстап тұр - Құдай сақтасын, олар сол әнде айтылғандай. Бұл туралы бүгін сөйлесетін боламыз.
Біз көзқарастарымызды өзгерте бастағанда, біз 4 өсиетті қалыптастырдық. Мен оларды слайдтарда көрсеттім:
Бұл өсиеттер өте қарапайым:
- Мәселені тез анықтаңыз.
- Одан тезірек құтылыңыз.
- Себебін түсінуге көмектесіңіз (кейінірек әзірлеушілер үшін).
- Және тәсілдерді стандарттау.
Сіздердің назарларыңызды No2 тармаққа аударғым келеді.Біз проблеманы шешпейміз, құтыламыз. Шешім қабылдау екінші дәрежелі. Біз үшін ең бастысы - пайдаланушы бұл мәселеден қорғалған. Ол кейбір оқшауланған ортада болады, бірақ бұл орта онымен байланыста болмайды. Шындығында, біз проблемалардың осы төрт тобын (кейбіреулері толығырақ, кейбіреулері азырақ) қарастырамыз, мен сізге нені қолданатынымызды, шешімдерде қандай тәжірибеміз бар екенін айтамын.
Ақауларды жою: олар қашан болады және олармен не істеу керек?
Бірақ біз тәртіпсіз бастаймыз, біз No2 тармақтан бастаймыз - проблемадан қалай тез құтылуға болады? Мәселе бар - біз оны түзетуіміз керек. «Бұл туралы не істеуіміз керек?» - негізгі сұрақ. Мәселені қалай шешуге болатыны туралы ойлана бастағанда, біз өзімізге кейбір талаптарды әзірледік, олар ақауларды жою үшін орындалу керек.
Осы талаптарды тұжырымдау үшін біз өзімізге сұрақ қоюды жөн көрдік: «Қашан бізде қиындықтар туындайды?» Мәселелер төрт жағдайда орын алады:
- Аппараттық ақау.
- Сыртқы қызметтер сәтсіз аяқталды.
- Бағдарламалық құрал нұсқасын өзгерту (бірдей орналастыру).
- Жарылыс жүктемесінің өсуі.
Біз алғашқы екеуі туралы айтпаймыз. Аппараттық құралдың ақаулығын өте оңай шешуге болады: сізде барлығы қайталануы керек. Егер бұл дискілер болса, дискілерді RAID жүйесінде жинау керек; егер бұл сервер болса, серверді көшіру керек; егер сізде желілік инфрақұрылым болса, желілік инфрақұрылымның екінші көшірмесін беруіңіз керек, яғни сіз оны аласыз және оны қайталаңыз. Ал егер бірдеңе сәтсіз болса, сіз резервтік қуатқа ауысасыз. Бұл жерде бұдан артық бірдеңе айту қиын.
Екіншісі – сыртқы қызметтердің істен шығуы. Көпшілік үшін жүйе мүлде проблема емес, бірақ біз үшін емес. Біз төлемдерді өңдейтіндіктен, біз пайдаланушы (өз картасының деректерін енгізетін) мен банктер, төлем жүйелері (Visa, MasterCard, Mira және т.б.) арасында тұратын агрегатормыз. Біздің сыртқы қызметтеріміз (төлем жүйелері, банктер) сәтсіздікке ұшырайды. Бұған біз де, сіз де (егер сізде мұндай қызметтер болса) әсер ете алмайды.
Сонда не істеу керек? Мұнда екі нұсқа бар. Біріншіден, егер мүмкін болса, бұл қызметті қандай да бір жолмен көшіру керек. Мысалы, мүмкін болса, біз трафикті бір қызметтен екіншісіне ауыстырамыз: мысалы, карталар Сбербанк арқылы өңделді, Сбербанкте проблемалар туындады - біз трафикті [шартты түрде] Райффайзенге аударамыз. Біз жасай алатын екінші нәрсе - сыртқы қызметтердің сәтсіздігін тез байқау, сондықтан есептің келесі бөлімінде жауап беру жылдамдығы туралы айтатын боламыз.
Шындығында, осы төртеуінен біз бағдарламалық жасақтама нұсқаларының өзгеруіне ерекше әсер ете аламыз - орналастыру контекстінде және жүктеменің жарылғыш өсуі жағдайында жағдайды жақсартуға әкелетін әрекеттерді орындаймыз. Шындығында, біз солай істедік. Міне, тағы бір шағын ескерту ...
Осы төрт мәселенің бірнешеуі бұлт болған жағдайда бірден шешіледі. Егер сіз Microsoft Azhur, Ozone бұлттарында болсаңыз немесе Яндекс немесе Пошта арқылы біздің бұлттарды пайдалансаңыз, кем дегенде аппараттық құралдың ақаулығы олардың мәселесіне айналады және аппараттық құралдың ақаулығы жағдайында сіз үшін бәрі бірден жақсы болады.
Біз аздап дәстүрлі емес компаниямыз. Мұнда бәрі «Кубернет» туралы, бұлттар туралы айтады - бізде «Кубернет» де, бұлттар да жоқ. Бірақ бізде көптеген деректер орталықтарында аппараттық құралдардың сөрелері бар және біз осы жабдықта өмір сүруге мәжбүрміз, біз бәріне жауапты болуға мәжбүрміз. Сондықтан біз осы тұрғыда сөйлесетін боламыз. Мәселен, проблемалар туралы. Алғашқы екеуі жақшадан шығарылды.
Бағдарламалық құрал нұсқасын өзгерту. Негіздер
Біздің әзірлеушілеріміз өндіріске қол жеткізе алмайды. Неге бұлай? Бізде PCI DSS сертификаты бар және біздің әзірлеушілердің «өнімге» кіруге құқығы жоқ. Болды, кезең. Мүлдем. Сондықтан әзірлеу жауапкершілігі құрастыруды шығаруға ұсынған кезде дәл аяқталады.
Біздің екінші негізіміз, ол да бізге көп көмектеседі, бірегей құжатсыз білімнің болмауы. Сізге де солай болады деп үміттенемін. Өйткені бұлай болмаса, сізде қиындықтар болады. Бұл бірегей, құжатсыз білім қажет уақытта қажетті жерде болмаған кезде проблемалар туындайды. Сізде белгілі бір құрамдас бөлікті қалай орналастыру керектігін білетін бір адам бар делік - адам жоқ, ол демалыста немесе ауырып жатыр - міне, сізде проблемалар бар.
Ал біз жеткен үшінші негіз. Біз оған ауырсыну, қан, көз жасы арқылы келдік - біз кез келген құрастыруымызда қателер жоқ болса да, қателер бар деген қорытындыға келдік. Біз мұны өзіміз шештік: бірдеңені орналастырғанда, бірдеңені өндіріске енгізгенде, бізде қателер бар құрылым болады. Біз жүйеміз қанағаттандыратын талаптарды қалыптастырдық.
Бағдарламалық құрал нұсқасын өзгертуге қойылатын талаптар
Үш талап бар:
- Біз орналастыруды тез арада қайтаруымыз керек.
- Сәтсіз орналастырудың әсерін барынша азайтуымыз керек.
- Және біз параллельді жылдам орналастыруға қабілетті болуымыз керек.
Дәл осы ретпен! Неліктен? Өйткені, біріншіден, жаңа нұсқаны орналастыру кезінде жылдамдық маңызды емес, бірақ сіз үшін бірдеңе дұрыс болмаса, тез кері оралу және минималды әсер ету маңызды. Бірақ егер сізде өндірісте нұсқалар жинағы болса, ол үшін қате бар (көк емес, орналастыру болған жоқ, бірақ қате бар) - сіз үшін кейінгі орналастыру жылдамдығы маңызды. Бұл талаптарды орындау үшін не істедік? Біз келесі әдістемеге жүгіндік:
Бұл жақсы белгілі, біз оны ешқашан ойлап тапқан емеспіз - бұл Көк/Жасыл орналастыру. Бұл не? Қолданбалар орнатылған серверлердің әрбір тобы үшін сізде көшірме болуы керек. Көшірме «жылы»: онда трафик жоқ, бірақ бұл трафикті кез келген уақытта осы көшірмеге жіберуге болады. Бұл көшірме алдыңғы нұсқаны қамтиды. Орналастыру кезінде сіз кодты белсенді емес көшірмеге шығарасыз. Содан кейін сіз трафиктің бір бөлігін (немесе барлығын) жаңа нұсқаға ауыстырасыз. Осылайша, трафик ағынын ескі нұсқадан жаңасына ауыстыру үшін сізге тек бір әрекетті орындау қажет: сіз жоғары ағындағы теңгерімді өзгертуіңіз керек, бағытты өзгертуіңіз керек - бір жоғарыдан екіншісіне. Бұл өте ыңғайлы және жылдам ауысу және жылдам кері қайтару мәселесін шешеді.Мұнда екінші сұрақтың шешімі минимизация болып табылады: сіз трафиктің бір бөлігін ғана жаңа жолға, жаңа кодпен жолға жібере аласыз (мысалы, 2%). Ал бұл 2% 100% емес! Сәтсіз орналастыру салдарынан трафиктің 100% жоғалтсаңыз, бұл қорқынышты; егер сіз трафиктің 2% жоғалтсаңыз, бұл жағымсыз, бірақ қорқынышты емес. Сонымен қатар, пайдаланушылар мұны байқамайды да, өйткені кейбір жағдайларда (барлығы емес) бір пайдаланушы F5 пернесін басқаннан кейін басқа жұмыс нұсқасына ауысады.
Көк/Жасыл орналастыру. Маршрутизация
Дегенмен, бәрі де қарапайым емес «Көк/Жасыл орналастыру»... Біздің барлық компоненттерді үш топқа бөлуге болады:
- бұл фронтенд (клиенттер көретін төлем беттері);
- өңдеу ядросы;
- төлем жүйелерімен жұмыс істеуге арналған адаптер (банктер, MasterCard, Visa...).
Және бұл жерде бір нюанс бар - нюанс сызықтар арасындағы маршруттауда жатыр. Егер сіз трафиктің 100% ауыстырсаңыз, сізде мұндай проблемалар болмайды. Бірақ егер сіз 2% ауыстырғыңыз келсе, сіз сұрақтар қоя бастайсыз: «Мұны қалай жасауға болады?» Ең қарапайым нәрсе алға қарай: Round Robin-ті nginx-те кездейсоқ таңдау арқылы орнатуға болады және сізде 2% солға, 98% оңға. Бірақ бұл әрқашан қолайлы емес.
Мысалы, біздің жағдайда пайдаланушы жүйемен бірнеше сұраныспен әрекеттеседі. Бұл қалыпты жағдай: 2, 3, 4, 5 сұраулар – сіздің жүйелеріңіз бірдей болуы мүмкін. Егер сіз үшін пайдаланушының барлық сұраулары бірінші сұрау түскен жолға түсуі маңызды болса немесе (екінші тармақ) пайдаланушының барлық сұраулары коммутатордан кейін жаңа жолға келеді (ол пайдаланушының сұрауымен ертерек жұмыс істей бастаған болар еді) жүйе, коммутатор алдында), - онда бұл кездейсоқ бөлу сізге сәйкес келмейді. Содан кейін келесі опциялар бар:
Бірінші нұсқа, ең қарапайымы, клиенттің негізгі параметрлеріне негізделген (IP Hash). Сізде IP бар және оны IP мекенжайы бойынша оңнан солға бөлесіз. Содан кейін мен сипаттаған екінші жағдай сіз үшін жұмыс істейді, орналастыру орын алған кезде, пайдаланушы сіздің жүйеңізбен жұмыс істей бастады және орналастыру сәтінен бастап барлық сұраулар жаңа жолға өтеді (айталық, дәл солай).Егер қандай да бір себептермен бұл сізге сәйкес келмесе және пайдаланушының бастапқы, бастапқы сұрауы келген желіге сұрау жіберу керек болса, сізде екі нұсқа бар...
Бірінші нұсқа: сіз ақылы nginx+ сатып ала аласыз. Жабысқақ сеанстар механизмі бар, ол пайдаланушының бастапқы сұрауы бойынша пайдаланушыға сеанс тағайындайды және оны сол немесе басқа жоғары ағынмен байланыстырады. Сеанс мерзімі ішінде барлық кейінгі пайдаланушы сұраулары сеанс жарияланған жоғары ағынға жіберіледі.Бұл бізге сәйкес келмеді, өйткені бізде әдеттегі nginx болды. Nginx+ жүйесіне ауысу қымбат емес, бұл біз үшін біршама ауыр болды және өте дұрыс емес. Мысалы, «Sticks Sessions» біз үшін жұмыс істемеді, себебі «Sticks Sessions» «Не-немесе» негізінде маршруттауға рұқсат бермейді. Онда сіз «Sticks Sessions» не істейтінімізді көрсете аласыз, мысалы, IP мекенжайы немесе IP мекенжайы және cookie файлдары немесе кейінгі параметр бойынша, бірақ «Не-немесе» бұл жерде күрделірек.
Сондықтан біз төртінші нұсқаға келдік. Біз nginx-ті стероидтерге алдық (бұл ашықтық) - бұл соңғы сценарийлерді қосуға қосымша қолдау көрсететін дәл сол nginx. Сіз соңғы сценарийді жаза аласыз, оған «ашық демалыс» бере аласыз және бұл соңғы сценарий пайдаланушы сұрауы келгенде орындалады.
Және біз, шын мәнінде, осындай сценарий жаздық, өзімізге «openresti» орнаттық және бұл сценарийде біз «Немесе» біріктіру арқылы 6 түрлі параметрді сұрыптаймыз. Бір немесе басқа параметрдің болуына байланысты біз пайдаланушы бір немесе басқа бетке, бір жолға немесе басқаға келгенін білеміз.
Көк/Жасыл орналастыру. Артылықшылықтар мен кемшіліктер
Әрине, оны біршама жеңілдетуге болатын шығар («Жабысқақ сеанстарды» қолданыңыз), бірақ бізде бір транзакцияны бір өңдеу аясында пайдаланушы ғана емес, бізбен әрекеттесетін осындай нюанс бар... Бірақ төлем жүйелері де бізбен өзара әрекеттеседі: транзакцияны өңдегеннен кейін (төлем жүйесіне сұрау жіберу арқылы) біз салқындату хабарламасын аламыз.
Айталық, егер біздің схемамызда пайдаланушының IP-мекен-жайын барлық сұрауларда жібере алсақ және пайдаланушыларды IP-мекен-жайына қарай бөле алсақ, онда біз бірдей «Visa» деп айтпаймыз: «Досым, біз сондай ретро компаниямыз, біз сияқтымыз. халықаралық болу үшін (веб-сайтта және Ресейде)... Бізге қосымша өрісте пайдаланушының IP мекенжайын беруіңізді сұраймыз, сіздің хаттамаңыз стандартталған»! Олардың келіспейтіні анық.
Сондықтан бұл бізге көмектеспеді - біз ашықтық жасадық. Тиісінше, маршруттау арқылы біз келесідей нәрсе алдық:Көк/Жасыл орналастырудың сәйкесінше мен айтқан артықшылықтары мен кемшіліктері бар.
Екі кемшілігі:
- маршруттаумен алаңдау керек;
- екінші негізгі кемшілігі – шығын.
Сізге екі есе көп серверлер қажет, сізге екі есе көп операциялық ресурстар қажет, осы бүкіл хайуанаттар бағын ұстау үшін екі есе көп күш жұмсау керек.
Айтпақшы, артықшылықтардың арасында мен бұрын айтпаған тағы бір нәрсе бар: сізде жүктеме өскен жағдайда резерв бар. Егер сізде жүктеменің қарқынды өсуі болса, сізде пайдаланушылар саны көп болса, сіз жай ғана екінші жолды 50-ден 50-ге дейін таратуға қосасыз - және сіз көбірек серверлерге ие болу мәселесін шешкенше кластеріңізде бірден x2 серверлері болады.
Жылдам орналастыруды қалай жасауға болады?
Біз азайту және жылдам кері қайтару мәселесін қалай шешуге болатыны туралы айттық, бірақ сұрақ қалады: «Қалай жылдам орналастыру керек?»
Мұнда қысқа және қарапайым.- Сізде CD жүйесі болуы керек (Үздіксіз жеткізу) - онсыз өмір сүре алмайсыз. Егер сізде бір сервер болса, қолмен орналастыруға болады. Бізде бір жарым мыңға жуық сервер және бір жарым мың тұтқалар бар, әрине - біз жай ғана орналастыру үшін осы бөлменің көлеміндегі бөлімді отырғыза аламыз.
- Орналастыру параллель болуы керек. Егер орналастыру дәйекті болса, онда бәрі нашар. Бір сервер қалыпты, сіз күні бойы бір жарым мың серверді орналастырасыз.
- Тағы да, жеделдету үшін бұл енді қажет емес шығар. Орналастыру кезінде жоба әдетте құрастырылады. Сізде веб-жоба бар, алдыңғы бөлік бар (сіз сол жерде веб-пакет жасайсыз, сіз npm-ді құрастырасыз) және бұл процесс, негізінен, қысқа мерзімді - 5 минут, бірақ бұл 5 минут сыни болыңыз. Сондықтан, мысалы, біз мұны істемейміз: біз осы 5 минутты алып тастадық, артефактілерді орналастырамыз.
Артефакт дегеніміз не? Артефакт - барлық құрастыру бөліктері аяқталған құрастырылған құрылыс. Біз бұл артефакті артефакт қоймасында сақтаймыз. Бір кездері біз осындай екі қойманы пайдаландық – бұл Nexus, ал қазір jFrog Artifactory.Біз бастапқыда «Nexus» қолдандық, өйткені біз бұл тәсілді java қолданбаларында қолдана бастадық (ол оған жақсы сәйкес келді). Содан кейін олар PHP-де жазылған кейбір қосымшаларды сол жерге қояды; және «Nexus» енді жарамсыз болды, сондықтан біз барлығын дерлік артифакторизациялай алатын jFrog Artefactory таңдадық. Біз тіпті осы артефакт репозиторийінде серверлер үшін жинайтын өзіміздің екілік пакеттерімізді сақтайтын жағдайға жеттік.
Жарылыс жүктемесінің өсуі
Біз бағдарламалық құрал нұсқасын өзгерту туралы айттық. Бізде келесі нәрсе - жүктеменің жарылғыш өсуі. Бұл жерде, мүмкін, жүктің жарылғыш өсуі дұрыс емес ...
Біз жаңа жүйені жаздық – бұл қызмет көрсетуге бағытталған, сәнді, әдемі, барлық жерде жұмысшылар, барлық жерде кезек, барлық жерде асинхрония. Ал мұндай жүйелерде деректер әртүрлі ағындар арқылы ағып кетуі мүмкін. Бірінші транзакция үшін 1-ші, 3-ші, 10-шы жұмысшы, екінші транзакция үшін - 2-ші, 4-ші, 5-ші жұмысшы қолданылуы мүмкін. Ал бүгін, айталық, таңертең сізде алғашқы үш жұмысшыны пайдаланатын деректер ағыны бар, ал кешке ол күрт өзгереді және барлығы қалған үш жұмысшыны пайдаланады.
Міне, сіз қандай да бір түрде жұмысшыларды масштабтауыңыз керек, сіз өзіңіздің қызметтеріңізді қандай да бір түрде масштабтауыңыз керек, бірақ сонымен бірге ресурстардың толып кетуіне жол бермеуіңіз керек.
Біз өз талаптарымызды анықтадық. Бұл талаптар өте қарапайым: Қызметті ашу, параметрлеу болуы - мұндай масштабталатын жүйелерді құру үшін барлығы стандартты, тек бір нүктеден басқа - ресурс амортизациясы. Біз серверлер ауаны жылыту үшін ресурстарды амортизациялауға дайын емеспіз деп айттық. «Консулды» алдық, жұмысшыларымызды басқаратын «Номадты» алдық.Неліктен бұл біз үшін проблема? Сәл артқа шегінейік. Біздің артымызда 70-ке жуық төлем жүйесі бар. Таңертең трафик Сбербанк арқылы өтеді, содан кейін, мысалы, Сбербанк құлады, біз оны басқа төлем жүйесіне ауыстырамыз. Сбербанкке дейін бізде 100 жұмысшы болды, содан кейін басқа төлем жүйесіне 100 жұмысшыны күрт көбейту керек. Ал мұның бәрі адамның қатысуынсыз болғаны құптарлық. Өйткені адамның қатысуы болса, онда тәулік бойы жұмыс істейтін инженер болуы керек, ол мұнымен ғана айналысуы керек, өйткені 24 жүйе артта қалған кезде мұндай сәтсіздіктер үнемі орын алады.
Сондықтан біз ашық IP бар Nomad-қа қарап, өзіміздің Scale-Nomad - ScaleNo деп жаздық, ол шамамен келесі әрекеттерді орындайды: ол кезектің өсуін бақылайды және динамикаға байланысты жұмысшылар санын азайтады немесе көбейтеді. кезекте. Біз мұны жасаған кезде: «Мүмкін біз оны ашатын шығармыз?» деп ойладық. Содан кейін олар оған қарады - ол екі тиын сияқты қарапайым болды.
Әзірге біз оны ашқан жоқпыз, бірақ кенеттен есептен кейін, сізге мұндай нәрсе керек екенін түсінгеннен кейін, сізге қажет болса, менің байланыстарым соңғы слайдта - маған жазыңыз. Кем дегенде 3-5 адам болса, демеушілік көрсетеміз.
Бұл қалай жұмыс істейді? Қарап көрейік! Алға қарасақ: сол жағында біздің мониторингтің бір бөлігі бар: бұл бір жол, жоғарғы жағында оқиғаны өңдеу уақыты, ортасында транзакциялар саны, төменгі жағында жұмысшылар саны.Қарап тұрсаңыз, бұл суретте қате бар. Жоғарғы диаграммада диаграммалардың бірі 45 секундта бұзылды - төлем жүйелерінің бірі төмендеді. Бірден трафик 2 минут ішінде әкелінді және жұмысшылар жоқ басқа төлем жүйесінде кезек өсе бастады (біз ресурстарды пайдаланбадық - керісінше, біз ресурсты дұрыс шығардық). Біз жылытқымыз келмеді - ең аз сан, шамамен 5-10 жұмысшы болды, бірақ олар шыдай алмады.
Соңғы графикте «дөңес» көрсетілген, бұл жай ғана «Skaleno» бұл соманы екі есе көбейткенін білдіреді. Содан кейін, график сәл төмендеген кезде, ол оны аздап қысқартты - жұмысшылардың саны автоматты түрде өзгертілді. Бұл нәрсе осылай жұмыс істейді. Біз №2 тармақ туралы айттық - «Себептерден қалай тез арылуға болады».
Бақылау. Мәселені қалай тез анықтауға болады?
Енді бірінші мәселе «Мәселені қалай тез анықтауға болады?» Бақылау! Біз кейбір нәрселерді тез түсінуіміз керек. Біз нені тез түсінуіміз керек?
Үш нәрсе!- Біз өз ресурстарымыздың өнімділігін тез түсініп, түсінуіміз керек.
- Біз сәтсіздіктерді тез түсініп, бізге сыртқы жүйелердің жұмысын бақылауымыз керек.
- Үшінші тармақ - логикалық қателерді анықтау. Бұл жүйе сіз үшін жұмыс істеп тұрған кезде, барлық көрсеткіштер бойынша бәрі қалыпты, бірақ бірдеңе дұрыс емес.
Мен сізге бұл жерде керемет ештеңе айтпайтын шығармын. Мен Капитан Обвиус боламын. Біз нарықта не бар екенін іздедік. Бізде «қызықты хайуанаттар бағы» бар. Бұл қазір бізде бар хайуанаттар бағының түрі:
Біз Zabbix-ті аппараттық құралдарды бақылау, серверлердің негізгі көрсеткіштерін бақылау үшін пайдаланамыз. Біз дерекқор үшін Okmeter қолданамыз. Біз «Графана» және «Прометейді» алғашқы екеуіне сәйкес келмейтін барлық басқа көрсеткіштер үшін қолданамыз, кейбіреулері «Графана» және «Прометей», ал кейбіреулері «Графана» «Инфлюкс» және Telegraf.Бір жыл бұрын біз New Relic-ті қолданғымыз келді. Керемет нәрсе, ол бәрін жасай алады. Бірақ оның қолынан бәрі келеді, ол соншалықты қымбат. Біз 1,5 мың серверге жеткенде, сатушы бізге келіп: «Келесі жылға келісім жасасайық», - деді. Біз бағаға қарап, жоқ, олай жасамаймыз дедік. Қазір біз New Relic-тен бас тартамыз, бізде New Relic бақылауында шамамен 15 сервер қалды. Бағасы мүлдем жабайы болып шықты.
Біз өзіміз іске асырған бір құрал бар - бұл Debugger. Басында біз оны «Баггер» деп атаған едік, содан кейін бір ағылшын мұғалімі өтіп бара жатып, қатты күліп, оны «Debagger» деп өзгертті. Бұл не? Бұл жүйенің «қара жәшігі» сияқты әрбір құрамдас бөлікте 15-30 секунд ішінде құрамдастың жалпы өнімділігі бойынша сынақтарды өткізетін құрал.
Мысалы, егер сыртқы бет (төлем парағы) болса, ол оны жай ғана ашып, оның қалай көрінетінін қарайды. Егер бұл өңделсе, ол сынақ «транзакцияны» жібереді және осы «транзакцияның» келгеніне көз жеткізеді. Егер бұл төлем жүйелерімен байланыс болса, біз сәйкесінше сынақ сұрауын жібереміз және бізде бәрі жақсы екенін көреміз.
Мониторинг үшін қандай көрсеткіштер маңызды?
Біз негізінен нені қадағалаймыз? Біз үшін қандай көрсеткіштер маңызды?
- Жауап беру уақыты / фронттардағы RPS - бұл өте маңызды көрсеткіш. Ол бірден сізге бірдеңе дұрыс емес деп жауап береді.
- Барлық кезектердегі өңделген хабарламалар саны.
- Жұмысшылар саны.
- Негізгі дұрыстық көрсеткіштері.
Соңғы нүкте – «бизнес», «бизнес» метрикасы. Егер сіз бірдей нәрсені бақылағыңыз келсе, сіз үшін негізгі көрсеткіштер болып табылатын бір немесе екі көрсеткішті анықтауыңыз керек. Біздің көрсеткіш – өткізу қабілеттілігі (бұл сәтті транзакциялар санының транзакцияның жалпы ағынына қатынасы). Егер 5-10-15 минут аралықта бірдеңе өзгерсе, бұл бізде проблемалар бар дегенді білдіреді (егер ол түбегейлі өзгерсе).
Бұл біздің тақталарымыздың бірінің мысалы болып табылады:
Сол жақта 6 график бар, бұл жолдарға сәйкес - жұмысшылар саны және кезектердегі хабарламалар саны. Оң жақта – RPS, RTS. Төменде бірдей «бизнес» көрсеткіші берілген. Ал «бизнес» метрикасында біз екі ортаңғы графикте бірдеңе дұрыс емес екенін бірден байқаймыз... Бұл біздің артымызда тұрған, құлаған тағы бір жүйе.Екіншіден, бізге сыртқы төлем жүйелерінің құлдырауын бақылау керек болды. Мұнда біз OpenTracing-ті алдық – бөлінген жүйелерді қадағалауға мүмкіндік беретін механизм, стандарт, парадигма; және ол аздап өзгерді. Стандартты OpenTracing парадигмасы біз әрбір жеке сұрау үшін із құрайтынымызды айтады. Бұл бізге қажет емес және біз оны жиынтық, жинақтау ізіне орадық. Біз артымыздағы жүйелердің жылдамдығын бақылауға мүмкіндік беретін құрал жасадық.
График төлем жүйелерінің бірі 3 секундта жауап бере бастағанын көрсетеді - бізде проблемалар бар. Сонымен қатар, бұл нәрсе проблемалар басталған кезде, 20-30 секунд аралықта әрекет етеді.Ал бар бақылау қателерінің үшінші класы – логикалық бақылау.
Шынымды айтсам, мен бұл слайдқа не салу керектігін білмедім, өйткені біз нарықта бізге сәйкес келетін нәрсені ұзақ уақыт іздедік. Ештеңе таппадық, сондықтан өзіміз істеуге тура келді.
Логикалық бақылау дегенді қалай түсінемін? Елестетіп көріңізші: сіз өзіңізді жүйе жасайсыз (мысалы, Tinder клоны); Сіз оны жасадыңыз, оны іске қостыңыз. Табысты менеджер Вася Пупкин оны телефонына қойды, сол жерде бір қызды көреді, оны ұнатады ... және қызға ұқсамайды - сол бизнес орталығының күзетшісі Михаличке ұқсас. Менеджер төменге түседі де: «Мына күзетші Михалич оған неге сонша күлімсірейді?» деп таңғалады.Мұндай жағдайларда... Біз үшін бұл жағдай сәл басқаша естіледі, өйткені (мен жаздым) бұл жанама түрде қаржылық шығынға әкелетін беделді жоғалту. Біздің жағдайымыз керісінше: біз тікелей қаржылық шығындарға ұшырауымыз мүмкін - мысалы, егер біз транзакция сәтті орындалса, бірақ ол сәтсіз болды (немесе керісінше). Мен бизнес көрсеткіштерін пайдалана отырып, уақыт өте келе сәтті транзакциялар санын қадағалайтын өз құралымды жазуға тура келді. Нарықта ештеңе таппадым! Дәл осы ойды жеткізгім келді. Нарықта мұндай мәселені шешетін ештеңе жоқ.
Бұл мәселені қалай тез анықтауға болатыны туралы болды.
Орналастыру себептерін қалай анықтауға болады
Біз шешетін мәселелердің үшінші тобы - мәселені анықтағаннан кейін, одан құтылғаннан кейін дамудың, тестілеудің себебін түсініп, бұл туралы бірдеңе жасау жақсы болар еді. Тиісінше, біз тексеруіміз керек, бөренелерді көтеруіміз керек.
Егер журналдар туралы айтатын болсақ (негізгі себебі - журналдар), біздің журналдарымыздың негізгі бөлігі ELK Stack-те - барлығында дерлік бірдей. Кейбіреулер үшін ол ELK-де болмауы мүмкін, бірақ егер сіз гигабайтпен журналдарды жазсаңыз, ерте ме, кеш пе ELK-ге келесіз. Біз оларды терабайтпен жазамыз.
Бұл жерде мәселе бар. Біз оны түзеттік, пайдаланушы үшін қатені түзеттік, онда не бар екенін қазып, Кибанаға көтерілдік, транзакция идентификаторын сол жерге енгіздік және осындай аяқ киім алдық (көп көрсетеді). Бұл аяқ киімде мүлдем ештеңе анық емес. Неліктен? Иә, себебі қай бөлік қай жұмысшыға, қай бөлікке жататындығы белгісіз. Сол кезде біз траксинг қажет екенін түсіндік - мен айтқан бірдей OpenTracing.Біз бір жыл бұрын осылай ойладық, нарыққа назар аудардық, сонда екі құрал болды - «Zipkin» және «Jaeger». «Жагер» шын мәнінде «Зипкиннің» идеялық мұрагері, идеялық мұрагері. Зипкинде бәрі жақсы, тек ол жинақтауды білмейді, ізге журналдарды қалай қосуды білмейді, тек уақыт ізі. Ал «Джагер» мұны қолдады.
Біз «Jager» қарадық: қолданбаларды аспаптауға болады, сіз Api тілінде жаза аласыз (ол кезде PHP үшін Api стандарты мақұлданбаған - бұл бір жыл бұрын болды, бірақ қазір ол бекітілген), бірақ сонда мүлдем клиент болмады. «Жарайды» деп ойладық және өз клиентімізді жаздык. Біз не алдық? Бұл шамамен келесідей көрінеді:
Jaeger бағдарламасында әрбір хабар үшін аралықтар жасалады. Яғни, пайдаланушы жүйені ашқан кезде әрбір кіріс сұранысы үшін бір немесе екі блокты көреді (1-2-3 – пайдаланушыдан түсетін кіріс сұраулар саны, блоктар саны). Пайдаланушыларға жеңілдету үшін біз журналдар мен уақыт ізіне тегтерді қостық. Сәйкесінше, қате болған жағдайда, біздің қолданба журналды сәйкес Қате тегімен белгілейді. Қате тегі бойынша сүзуге болады және қатесі бар осы блокты қамтитын аралықтар ғана көрсетіледі. Кеңістікті кеңейтетін болсақ, бұл келесідей болады:
Аралықтың ішінде іздердің жиынтығы бар. Бұл жағдайда бұл үш сынақ ізі, ал үшінші із қате орын алғанын айтады. Сонымен бірге, мұнда біз уақыт ізін көреміз: бізде жоғарғы жағында уақыт шкаласы бар және біз осы немесе басқа журналдың қандай уақыт аралығында жазылғанын көреміз.Сәйкесінше, біз үшін де жақсы болды. Біз өз кеңейтімді жаздық және біз оны аштық. Егер сіз трассамен жұмыс істегіңіз келсе, PHP-де «Jager» бағдарламасымен жұмыс істегіңіз келсе, біздің кеңейтім бар, олар айтқандай пайдалануға қош келдіңіз:
Бізде бұл кеңейтім бар - бұл OpenTracing Api клиенті, ол php-кеңейтімі ретінде жасалған, яғни оны жинап, жүйеге орнату керек. Бір жыл бұрын басқа ештеңе болған жоқ. Енді құрамдас бөліктерге ұқсас басқа клиенттер бар. Бұл сізге байланысты: құрамдастарды композитордың көмегімен шығарасыз немесе кеңейтімді пайдаланасыз.Корпоративтік стандарттар
Біз үш өсиет туралы сөйлестік. Төртінші өсиет – тәсілдерді стандарттау. Бұл не туралы? Бұл туралы:
Неліктен бұл жерде «корпоративтік» сөзі бар? Біз үлкен немесе бюрократиялық компания болғандықтан емес, жоқ! Мен бұл жерде «корпоративтік» сөзін әрбір компанияның, әрбір өнімнің, соның ішінде сізде де өз стандарттары болуы керек деген мағынада қолданғым келді. Бізде қандай стандарттар бар?
- Бізде орналастыру ережелері бар. Біз онсыз ешқайда қозғалмаймыз, мүмкін емес. Біз аптасына шамамен 60 рет орналастырамыз, яғни біз үнемі дерлік орналастырамыз. Сонымен қатар, бізде, мысалы, орналастыру ережелерінде жұма күні орналастыруға тыйым салынған - негізінен, біз орналастырмаймыз.
- Біз құжаттаманы талап етеміз. Бірде-бір жаңа компонент, егер ол үшін құжаттама болмаса, өндіріске енбейді, тіпті ол біздің RnD мамандарының қолынан шыққан болса да. Біз олардан қолдану нұсқауларын, мониторинг картасын және осы компоненттің қалай жұмыс істейтінін, ақаулықтарды жою жолын көрсететін дөрекі сипаттаманы (бағдарламашылар жаза алатындай) талап етеміз.
- Біз мәселенің себебін емес, мәселені шешеміз - мен айтқан. Біз үшін пайдаланушыны проблемалардан қорғау маңызды.
- Бізде рұқсаттар бар. Мысалы, егер біз екі минут ішінде трафиктің 2%-ын жоғалтсақ, оны тоқтап тұрған уақыт деп есептемейміз. Бұл негізінен біздің статистикаға кірмейді. Егер ол пайыздық немесе уақытша болса, біз қазірдің өзінде санаймыз.
- Ал біз әрқашан өлгеннен кейін жазамыз. Бізде қандай жағдай болса да, өндірісте біреудің өзін дұрыс ұстамаған кез келген жағдайы өлгеннен кейін көрініс табады. Постмортем - бұл сізге не болғанын, егжей-тегжейлі уақытты, оны түзету үшін не істегеніңізді және (бұл міндетті блок!) болашақта мұның алдын алу үшін не істейтініңізді жазатын құжат. Бұл міндетті және кейінгі талдау үшін қажет.
Тоқтау уақыты не болып саналады?
Мұның бәрі неге әкелді?Бұл (бізде тұрақтылыққа қатысты белгілі бір проблемалар болды, бұл клиенттерге де, бізге де сәйкес келмеді) соңғы 6 айда тұрақтылық көрсеткіші 99,97 болды. Бұл өте көп емес деп айта аламыз. Иә, бізде ұмтылатын нәрсе бар. Бұл көрсеткіштің жартысына жуығы - бұл біздің емес, біздің веб-қосымшалар брандмауэрінің тұрақтылығы, ол біздің алдымызда тұрған және қызмет ретінде пайдаланылады, бірақ клиенттер бұл туралы ойламайды.
Түнде ұйықтауды үйрендік. Ақырында! Алты ай бұрын біз алмадық. Нәтижелері бар осы жазбада мен бір ескертпе айтқым келеді. Кеше түнде ядролық реакторды басқару жүйесі туралы тамаша хабар шықты. Егер осы жүйені жазған адамдар мені ести алатын болса, «2% бос уақыт емес» туралы айтқанымды ұмытыңыз. Сіз үшін 2% - екі минут болса да тоқтап қалу!
Бар болғаны! Сіздің сұрақтарыңыз.
Балансерлер және дерекқорды тасымалдау туралы
Көрермендер сауалы (бұдан әрі – Б): – Қайырлы кеш. Осындай админ есеп бергеніңізге көп рахмет! Сіздің балансерлеріңіз туралы қысқаша сұрақ. Сізде WAF бар екенін айттыңыз, яғни менің түсінуімше, сіз қандай да бір сыртқы балансизаторды қолданасыз ...
EK: – Жоқ, біз өз қызметтерімізді теңгерімші ретінде пайдаланамыз. Бұл жағдайда WAF біз үшін тек DDoS қорғау құралы болып табылады.
Q: – Балансшылар туралы бірер сөз айта аласыз ба?
EK: – Жоғарыда айтқанымдай, бұл ашық серверлер тобы. Бізде қазір тек қана жауап беретін 5 резервтік топ бар... яғни тек қана ашық режимде жұмыс істейтін сервер, ол тек трафикті проксиге жібереді. Тиісінше, біз қаншалықты ұстайтынымызды түсіну үшін: қазір бізде бірнеше жүз мегабит тұрақты трафик ағыны бар. Олар төтеп береді, өздерін жақсы сезінеді, тіпті өздерін қыспайды.
Q: – Сондай-ақ қарапайым сұрақ. Міне, көк/жасыл орналастыру. Мысалы, дерекқорды тасымалдаумен не істейсіз?
EK: - Жақсы сұрақ! Қараңыз, Көк/Жасыл орналастыруда бізде әр жол үшін бөлек кезектер бар. Яғни, жұмысшыдан жұмысшыға берілетін оқиға кезегі туралы айтатын болсақ, көк жолға және жасыл жолға бөлек кезектер бар. Егер біз дерекқордың өзі туралы айтатын болсақ, онда біз оны мүмкіндігінше әдейі тарылттық, барлығын іс жүзінде кезекке ауыстырдық; дерекқорда біз тек транзакциялар дестесін сақтаймыз. Біздің транзакциялар стегі барлық жолдар үшін бірдей. Осы контексте дерекқормен: біз оны көк және жасыл деп бөлмейміз, өйткені кодтың екі нұсқасы да транзакциямен не болып жатқанын білуі керек.
Достар, менің де сіздерді ынталандыратын шағын сыйлығым бар - кітап. Мен оны ең жақсы сұрақ үшін марапаттауым керек.
Q: - Сәлеметсіз бе. Есеп үшін рахмет. Сұрақ мынау. Сіз төлемдерді бақылайсыз, сіз байланысатын қызметтерді қадағалайсыз ... Бірақ сіздің төлем парағыңызға адам қандай да бір жолмен кіріп, төлем жасаған және жоба оған ақша салғанын қалай бақылайсыз? Яғни, маржанттың қолжетімді екенін және сіздің кері қоңырауыңызды қабылдағанын қалай бақылайсыз?
EK: – Бұл жағдайда біз үшін «Саудагер» төлем жүйесі сияқты сыртқы қызмет болып табылады. Біз сатушының жауап беру жылдамдығын бақылап отырамыз.
Мәліметтер базасын шифрлау туралы
Q: - Сәлеметсіз бе. Менде аздап байланысты сұрағым бар. Сізде PCI DSS сезімтал деректері бар. Мен PAN кодтарын аудару қажет кезекте қалай сақтайтыныңызды білгім келді? Сіз шифрлауды қолданасыз ба? Және бұл екінші сұраққа әкеледі: PCI DSS сәйкес, өзгерістер (әкімшілерді жұмыстан шығару және т.б.) болған жағдайда мәліметтер базасын мерзімді түрде қайта шифрлау қажет - бұл жағдайда қолжетімділік не болады?
EK: - Керемет сұрақ! Біріншіден, біз PAN нөмірлерін кезекте сақтамаймыз. Бізде PAN-ды кез келген жерде анық түрде сақтауға құқығымыз жоқ, сондықтан біз арнайы қызметті пайдаланамыз («Кадемон» деп атаймыз) – бұл бір ғана әрекетті орындайтын қызмет: ол хабарламаны енгізу ретінде қабылдайды және жібереді. шифрланған хабарды шығарады. Біз бәрін осы шифрланған хабарламамен сақтаймыз. Тиісінше, кілттің ұзындығы килобайттан төмен, сондықтан бұл маңызды және сенімді.Q: – Қазір сізге 2 килобайт керек пе?
EK: – Кеше ғана 256 болған сияқты... Ал, басқа қайда?!
Сәйкесінше, бұл бірінші. Екіншіден, бар шешім, ол қайта шифрлау процедурасын қолдайды - шифрлайтын «палубаларды» беретін екі жұп «кекс» (кілттер) бар (кілт – кілттер, dek – шифрлайтын кілттердің туындылары) . Егер процедура басталса (бұл 3 айдан ± кейбіріне дейін жүйелі түрде жүреді), біз «торттардың» жаңа жұбын жүктеп аламыз және біз деректерді қайта шифрлаймыз. Бізде барлық деректерді алып тастайтын және оларды жаңа жолмен шифрлайтын бөлек қызметтер бар; Деректер шифрланған кілттің идентификаторының жанында сақталады. Тиісінше, деректерді жаңа кілттермен шифрлаған кезде, біз ескі кілтті жоямыз.
Кейде төлемдерді қолмен жасау керек...
Q: – Яғни, қандай да бір операция үшін ақшаны қайтару келсе, оны бұрынғы кілтпен шешесіз бе?
EK: - Ия.
Q: – Сосын тағы бір шағын сұрақ. Қандай да бір сәтсіздік, құлау немесе оқиға орын алған кезде транзакцияны қолмен итеру қажет. Ондай жағдай бар.
EK: - Иә, кейде.
Q: – Бұл деректерді қайдан аласыз? Әлде бұл қоймаға өзіңіз барасыз ба?
EK: – Жоқ, әрине, бізде қолдау көрсету интерфейсі бар бэк-офис жүйесі бар. Егер транзакцияның қандай күйде екенін білмесек (мысалы, төлем жүйесі күту уақытымен жауап бергенге дейін), біз априориді білмейміз, яғни соңғы мәртебені тек толық сенімділікпен тағайындаймыз. Бұл жағдайда транзакцияны қолмен өңдеу үшін арнайы мәртебеге береміз. Таңертең, келесі күні қолдау көрсету төлем жүйесінде осындай және осындай транзакциялардың қалғаны туралы ақпаратты алған бойда, олар оларды осы интерфейсте қолмен өңдейді.
Q: – Бір-екі сұрағым бар. Олардың бірі - PCI DSS аймағының жалғасы: олардың схемасын қалай тіркеуге болады? Бұл сұрақ әзірлеуші журналдарға кез келген нәрсені қоюы мүмкін болғандықтан! Екінші сұрақ: түзетулерді қалай шығаруға болады? Дерекқордағы тұтқаларды пайдалану - бір нұсқа, бірақ тегін жылдам түзетулер болуы мүмкін - бұл жерде қандай процедура бар? Ал үшінші сұрақ РТО, РПО-ға қатысты болса керек. Сіздің қолжетімділігіңіз 99,97 болды, төрт тоғызға жуық, бірақ мен түсінгендей, сізде екінші деректер орталығы, үшінші деректер орталығы және бесінші деректер орталығы бар... Оларды қалай синхрондауға, қайталауға және басқалардың бәрін жасауға болады?EK: – Біріншіден бастайық. Бірінші сұрақ журналдар туралы болды ма? Журналдарды жазған кезде бізде барлық құпия деректерді жасыратын қабат болады. Ол маскаға және қосымша өрістерге қарайды. Тиісінше, біздің журналдар қазірдің өзінде бүркенген деректермен және PCI DSS тізбегімен шығады. Бұл тестілеу бөліміне жүктелетін тұрақты жұмыстардың бірі. Олар әрбір тапсырманы, соның ішінде олар жазған журналдарды тексеруі керек және бұл әзірлеушінің бірдеңе жазбағанын бақылау үшін кодты қарау кезіндегі тұрақты тапсырмалардың бірі. Бұны кейінгі тексерулерді ақпараттық қауіпсіздік бөлімі аптасына бір рет жүйелі түрде жүргізеді: соңғы күннің журналдары іріктеліп алынады және барлығын тексеру үшін тест-серверлерден арнайы сканер-анализатор арқылы іске қосылады.
Түзетулер туралы. Бұл біздің орналастыру ережелеріне енгізілген. Бізде түзетулер туралы бөлек тармақ бар. Біз түзетулерді қажет болған кезде тәулік бойы қолданамыз деп есептейміз. Нұсқа құрастырылғаннан кейін, ол іске қосылғаннан кейін, бізде артефакт болған кезде, бізде қолдау қызметінен қоңырау шалу бойынша кезекші жүйелік әкімші бар және ол қажет болған кезде оны орналастырады.«Төрт тоғыз» туралы. Біз қазір қол жеткізген көрсеткішке шынымен қол жеткіздік және біз оған басқа дата-орталықта ұмтылдық. Қазір бізде екінші деректер орталығы бар және біз олардың арасында бағытты бастаймыз және деректер орталығын кросс-репликациялау мәселесі шын мәнінде маңызды емес мәселе. Біз оны бір уақытта әртүрлі құралдарды қолданып шешуге тырыстық: біз бірдей «Тарантуланы» қолдануға тырыстық - бұл біз үшін жұмыс істемеді, мен сізге бірден айтамын. Сондықтан біз «сендерге» қолмен тапсырыс беруді аяқтадық. Шын мәнінде, біздің жүйедегі әрбір қолданба деректер орталықтары арасында асинхронды түрде қажетті «өзгерту – орындалды» синхрондауды іске қосады.
Q: – Екіншісін алсаң, үшіншісін неге алмадың? Өйткені әлі ешкімнің миы жоқ...
EK: – Бірақ бізде бөлінген ми жоқ. Әрбір қосымшаны мультимастер басқаратындықтан, сұраныстың қай орталыққа келгені бізге маңызды емес. Егер біздің деректер орталықтарының бірі істен шықса (біз бұған сенеміз) және пайдаланушы сұрауының ортасында екінші деректер орталығына ауысса, біз бұл пайдаланушыны жоғалтуға дайынбыз; бірақ бұл бірлік, абсолютті бірлік болады.
Q: - Қайырлы кеш. Есеп үшін рахмет. Өндірісте кейбір сынақ транзакцияларын орындайтын отладчик туралы айттыңыз. Бірақ сынақ транзакциялары туралы айтып беріңізші! Ол қаншалықты тереңге барады?
EK: – Ол бүкіл компоненттің толық циклінен өтеді. Құрамдас үшін сынақ транзакциясы мен өндірістік транзакция арасында ешқандай айырмашылық жоқ. Бірақ логикалық тұрғыдан алғанда, бұл жүйедегі тек сынақ транзакциялары орындалатын жеке жоба.
Q: -Оны қай жерден кесіп жатырсың? Мұнда Core жіберілді...
EK: – Біз бұл жағдайда сынақ транзакциялары үшін «Кордың» артында тұрмыз... Бізде маршруттау деген бар: «Кор» қай төлем жүйесіне жіберу керектігін біледі - біз жалған төлем жүйесіне жібереміз, ол жай ғана http сигналын береді және бар болғаны.
Q: – Айтыңызшы, өтінішіңіз бір үлкен монолитте жазылған ба, әлде оны кейбір сервистерге, тіпті микросервистерге бөлдіңіз бе?
EK: – Бізде монолит жоқ, әрине, бізде сервистік бағдарлама бар. Біздің қызметіміз монолиттерден жасалған деп әзілдейміз - олар шынымен де өте үлкен. Оны микросервис деп атау қиын, бірақ бұл бөлінген машиналар жұмысшылары жұмыс істейтін қызметтер.
Сервердегі қызмет бұзылса...
Q: – Олай болса келесі сұрағым бар. Бұл монолит болса да, сіз әлі де сізде осы жедел серверлердің көпшілігі бар екенін айттыңыз, олардың барлығы негізінен деректерді өңдейді және мәселе: «Лездік серверлердің немесе қолданбалардың біреуі бұзылған жағдайда, кез келген жеке сілтеме , оларда қол жеткізуді басқарудың қандай да бір түрі бар ма? Олардың қайсысы не істей алады? Қандай ақпарат алу үшін кімге хабарласуым керек?
EK: - Иә, сөзсіз. Қауіпсіздік талаптары өте күрделі. Біріншіден, бізде ашық деректер қозғалысы бар, ал порттар тек трафик қозғалысын алдын ала болжайтын порттар. Егер құрамдас дерекқормен (мысалы, Мускулмен) 5-4-3-2 арқылы байланысса, оған тек 5-4-3-2 ғана ашық болады, ал басқа порттар мен басқа трафик бағыттары қолжетімді болмайды. Сонымен қатар, сіз біздің өндірісімізде шамамен 10 түрлі қауіпсіздік циклі бар екенін түсінуіңіз керек. Қолданба қандай да бір түрде бұзылған болса да, Құдай сақтасын, шабуылдаушы серверді басқару консоліне кіре алмайды, өйткені бұл басқа желілік қауіпсіздік аймағы.Q: – Бұл тұрғыда маған қызығы, сізде қызметтермен белгілі бір келісім-шарттарыңыз бар – олар не істей алады, қандай «әрекеттер» арқылы бір-бірімен байланыса алады... Ал қалыпты ағымда кейбір нақты қызметтер кейбіреулерін сұрайды. қатар, екіншісінде «әрекеттер» тізімі. Олар қалыпты жағдайда басқаларға жүгінбейтін сияқты және олардың басқа да жауапкершіліктері бар. Егер олардың біреуі бұзылса, ол сол қызметтің «әрекеттерін» бұза алады ма?..
EK: - Мен түсінемін. Қалыпты жағдайда басқа сервермен байланысқа мүлде рұқсат етілсе, иә. SLA келісім-шартына сәйкес, біз сізге тек алғашқы 3 «әрекетке» рұқсат етілгенін және 4 «әрекетке» рұқсат етілмегеніңізді бақыламаймыз. Бұл біз үшін артық болуы мүмкін, өйткені бізде схемалар үшін 4 деңгейлі қорғаныс жүйесі бар. Біз өзімізді ішкі жағынан емес, контурлармен қорғағанды жөн көреміз.
Visa, MasterCard және Сбербанк қалай жұмыс істейді
Q: – Мен пайдаланушыны бір деректер орталығынан екіншісіне ауыстыру туралы мәселені түсіндіргім келеді. Менің білуімше, Visa және MasterCard 8583 екілік синхронды хаттаманы пайдалана отырып жұмыс істейді және ол жерде араласулар бар. Мен білгім келді, енді біз ауысуды айтамыз – бұл тікелей «Visa» және «MasterCard» немесе төлем жүйелеріне дейін, өңдеуден бұрын ба?
EK: - Бұл қоспалар алдында. Біздің қоспаларымыз бір деректер орталығында орналасқан.
Q: – Дөрекі сөзбен айтқанда, сізде бір байланыс бар ма?
EK: – «Visa» және «MasterCard» - иә. Visa және MasterCard, мысалы, қоспалардың екінші жұбын алу үшін бөлек келісім-шарттар жасау үшін инфрақұрылымға айтарлықтай күрделі инвестицияларды қажет ететіндіктен. Олар бір дата орталығында сақталған, бірақ Құдай сақтасын, Visa және MasterCard-қа қосылуға арналған микстері бар біздің дата орталығымыз өліп қалса, Visa және MasterCard-пен байланысымыз жоғалады...
Q: – Оларды қалай резервтеуге болады? Мен Visa негізінен бір ғана қосылуға мүмкіндік беретінін білемін!
EK: – Жабдықтарды өздері жеткізеді. Қалай болғанда да, ішінде толықтай артық құрал-жабдықтар алдық.
Q: – Демек, стенд олардың Connects Orange компаниясынан екен?..
EK: - Ия.
Q: – Бірақ бұл жағдай туралы не айтасыз: егер сіздің деректер орталығыңыз жоғалып кетсе, оны қалай пайдалана аласыз? Әлде көлік қозғалысы тоқтай ма?
EK: - Жоқ. Бұл жағдайда біз трафикті жай ғана басқа арнаға ауыстырамыз, бұл, әрине, біз үшін қымбатырақ және клиенттеріміз үшін қымбатырақ болады. Бірақ трафик біздің Visa, MasterCard-қа тікелей қосылуымыз арқылы емес, шартты Сбербанк арқылы өтеді (өте асыра сілтеп).
Сбербанк қызметкерлерін ренжіткен болсам, кешірім сұраймын. Бірақ біздің статистика бойынша, ресейлік банктер арасында Сбербанк жиі құлайды. Сбербанкте бірдеңе бұзылмай өтпейді.
Кейбір жарнамалар 🙂
Бізбен бірге болғандарыңызға рахмет. Сізге біздің мақалалар ұнайды ма? Қызықты мазмұнды көргіңіз келе ме? Тапсырыс беру немесе достарыңызға ұсыну арқылы бізге қолдау көрсетіңіз, , Сіз үшін біз ойлап тапқан бастапқы деңгейдегі серверлердің бірегей аналогы: (RAID1 және RAID10, 24 ядроға дейін және 40 ГБ DDR4 дейін қол жетімді).
Dell R730xd Амстердамдағы Equinix Tier IV деректер орталығында 2 есе арзан ба? Тек осында Нидерландыда! Dell R420 - 2x E5-2430 2.2 ГГц 6C 128 ГБ DDR3 2x960 ГБ SSD 1 Гбит/с 100 ТБ - 99 доллардан бастап! туралы оқыңыз
Ақпарат көзі: www.habr.com