Ар бир адам иштеп чыгуу жана тестирлөө, персоналды окутуу, мотивацияны жогорулатуу процесстери жөнүндө айтышат, бирок кызматтын бир мүнөт токтоп калуусу эбегейсиз сумманы талап кылганда бул процесстер жетишсиз. Катуу SLA боюнча финансылык операцияларды жүргүзгөндө эмне кылуу керек? Иштеп чыгууну жана сыноону теңдемеден чыгарып, системаларыңыздын ишенимдүүлүгүн жана катага чыдамдуулугун кантип жогорулатуу керек?
Кийинки HighLoad++ конференциясы 6-жылдын 7 жана 2020-апрелинде Санкт-Петербургда өтөт. Толук маалымат жана билеттер . 9-ноябрь, саат 18:00. HighLoad++ Москва 2018, Дели + Колкута залы. Тезистер жана .
Евгений Кузовлев (мындан ары – ЕК): - Достор, салам! Менин атым Кузовлев Евгений. Мен EcommPay компаниясынанмын, белгилүү бир бөлүм - EcommPay IT, компаниялар тобунун IT бөлүмү. Ал эми бүгүн биз токтоп калуулар жөнүндө сүйлөшөбүз - аларды кантип болтурбоо керек, эгерде аны болтурбоо мүмкүн болбосо, алардын кесепеттерин кантип азайтуу керек. Тема төмөнкүчө айтылат: "Бир мүнөт токтоп калуу 100 000 доллар турганда эмне кылуу керек"? Алдыга карай турган болсок, биздин сандар салыштырмалуу.
EcommPay IT эмне кылат?
Биз кимбиз? Эмне үчүн мен сенин алдыңда турам? Эмне үчүн бул жерде сага бир нерсе айтууга укугум бар? Бул жерде кененирээк эмне жөнүндө сүйлөшөбүз?
EcommPay компаниялар тобу эл аралык эквайер болуп саналат. Биз төлөмдөрдү бүткүл дүйнө боюнча - Россияда, Европада, Түштүк-Чыгыш Азияда (Бардык дүйнө жүзү боюнча) иштетебиз. Бизде 9 офис бар, бардыгы болуп 500 кызматкер, болжол менен алардын жарымынан бир аз азы IT адистери. Биз эмне кылганыбыздын, акча тапканыбыздын баарын өзүбүз жасаганбыз.
Биз өзүбүздүн бардык өнүмдөрүбүздү жаздык (жана бизде алар абдан көп – биздин чоң IT продуктулар линиясында 16га жакын ар түрдүү компоненттер бар) өзүбүздүн; Өзүбүздү өзүбүз жазабыз, өзүбүз өнүктүрөбүз. Ал эми учурда биз күнүнө бир миллионго жакын транзакцияларды ишке ашырабыз (миллиондор, балким, бул туура жол). Биз бир топ жаш компаниябыз - биз болгону алты жаштабыз.
6 жыл мурун жигиттер бизнес менен бирге келгенде ушундай стартап эле. Аларды идея бириктирди (идеядан башка эч нерсе жок), биз чуркадык. Ар кандай стартаптардай эле биз ылдамыраак чуркадык... Биз үчүн ылдамдык сапаттан да маанилүү болчу.
Кайсы бир учурда биз токтоп калдык: биз мындан ары кандайдыр бир жол менен мындай ылдамдыкта жана сапат менен жашай албасыбызды түшүндүк жана биринчи кезекте сапатка көңүл буруубуз керек. Ушул тапта биз туура, масштабдуу жана ишенимдүү боло турган жаңы платформа жазууну чечтик. Алар бул платформаны жаза башташты (алар инвестициялоону, иштеп чыгууну, тестирлөөнү баштады), бирок кайсы бир учурда алар иштеп чыгуу жана тестирлөө бизге кызмат көрсөтүүнүн сапатынын жаңы деңгээлине чыгууга мүмкүндүк бербегенин түшүнүштү.
Сиз жаңы буюм жасайсыз, аны өндүрүшкө киргизесиз, бирок баары бир бир жерде бир нерсе туура эмес болуп калат. Ал эми бүгүн биз жаңы сапат деңгээлине кантип жетүүгө болот (биз муну кантип жасаганбыз, тажрыйбабыз жөнүндө), өнүгүүнү жана тестирлөөнү теңдемеден алып чыгып сүйлөшөбүз; биз операцияга эмне бар экендиги жөнүндө сүйлөшөбүз - кандай операция өзү жасай алат, сапатка таасир этиш үчүн тестирлөөгө эмне сунуш кыла алат.
токтоп калуулар. Операциянын буйруктары.
Ар дайым негизги пайдубал, биз бүгүн иш жүзүндө сүйлөшө турган нерсе - токтоп калуу. Коркунучтуу сөз. Эгерде бизде токтоп калсак, анда бардыгы биз үчүн жаман. Аны көтөрөбүз деп чуркап жатабыз, админдер серверди кармап турушат - Кудай сактасын, ошол ырда айткандай, кулап кетпесин. Бул тууралуу бүгүн сүйлөшөбүз.
Биз мамилебизди өзгөртө баштаганда, биз 4 осуятты түздүк. Мен аларды слайддарда көрсөттүм:
Бул осуяттар абдан жөнөкөй:
- Көйгөйдү тез аныктаңыз.
- Андан да тезирээк кутулуңуз.
- Себебин түшүнүүгө жардам бериңиз (кийин, иштеп чыгуучулар үчүн).
- Жана ыкмаларды стандартташтыруу.
2-пунктуна көңүлүңүздөрдү бурат элем.Биз маселени чечпей, арылтып жатабыз. Чечим экинчи орунда турат. Биз үчүн, биринчи кезекте, колдонуучу бул көйгөйдөн корголгон. Ал кээ бир обочолонгон чөйрөдө болот, бирок бул чөйрө аны менен эч кандай байланышы болбойт. Чынында, биз көйгөйлөрдүн ушул төрт тобун карап чыгабыз (айрымдары майда-чүйдөсүнө чейин, кээ бирлери азыраак), мен сизге эмнени колдонуп жатканыбызды, чечимдерде кандай тиешелүү тажрыйбабыз бар экенин айтып берем.
Көйгөйлөрдү чечүү: алар качан болот жана алар менен эмне кылуу керек?
Бирок биз тартипсиз баштайбыз, No2 пункттан баштайбыз – көйгөйдөн кантип тез кутулабыз? Маселе бар - биз аны оңдообуз керек. "Бул жөнүндө эмне кылышыбыз керек?" - негизги суроо. Жана биз көйгөйдү кантип чечүү жөнүндө ойлоно баштаганда, биз өзүбүз үчүн айрым талаптарды иштеп чыктык, аларды чечүү жолдору сакталышы керек.
Бул талаптарды формулировкалоо үчүн биз өзүбүзгө суроо берүүнү чечтик: "Бизде качан көйгөйлөр бар?" Ал эми көйгөйлөр, белгилүү болгондой, төрт учурда пайда болот:
- Аппараттык камсыздоо катасы.
- Тышкы кызматтар ишке ашкан жок.
- Программанын версиясын өзгөртүү (ошол эле жайылтуу).
- Жарылгыч жүктүн өсүшү.
Биз биринчи экөө жөнүндө сүйлөшпөйбүз. Аппараттык камсыздоонун бузулушун жөнөкөй эле чечсе болот: сизде бардыгы кайталанган болушу керек. Эгерде бул дисктер болсо, дисктер RAIDде чогултулушу керек; эгерде бул сервер болсо, сервер дубликацияланышы керек; эгерде сизде тармактык инфраструктура болсо, тармактык инфраструктуранын экинчи көчүрмөсүн беришиңиз керек, башкача айтканда, сиз аны алып, аны кайтала. Ал эми бир нерсе иштебей калса, резервдик кубатка өтөсүз. Бул жерде дагы бир нерсе айтуу кыйын.
Экинчиси, тышкы кызматтардын иштебей калышы. Көпчүлүк үчүн система такыр эле көйгөй эмес, бирок биз үчүн эмес. Биз төлөмдөрдү иштетип жаткандыктан, биз колдонуучу (анын картасынын маалыматтарын киргизген) менен банктардын, төлөм системаларынын (Visa, MasterCard, Mira ж.б.) ортосунда турган агрегаторбуз. Биздин тышкы кызматтарыбыз (төлөм системалары, банктар) иштебей калат. Биз да, сиз да (эгерде сизде мындай кызматтар болсо) буга таасир эте албайт.
Анда эмне кылуу керек? Бул жерде эки вариант бар. Биринчиден, эгер мүмкүн болсо, бул кызматты кандайдыр бир жол менен кайталашыңыз керек. Мисалы, мүмкүн болсо, биз трафикти бир кызматтан экинчи кызматка которобуз: мисалы, карталар Сбербанк аркылуу иштетилген, Сбербанк көйгөйлөргө туш болуп жатат - биз трафикти [шарттуу түрдө] Райффайзенге өткөрөбүз. Биз кыла турган экинчи нерсе - тышкы кызматтардын иштебей калганын тез эле байкап калуу, ошондуктан биз отчеттун кийинки бөлүгүндө жооп берүү ылдамдыгы жөнүндө сүйлөшөбүз.
Чындыгында, бул төртөөнүн ичинен биз программалык камсыздоонун версияларынын өзгөрүшүнө өзгөчө таасир эте алабыз - жайылтуу контекстинде жана жүктөмдүн жарылуучу өсүшүнүн контекстинде абалдын жакшырышына алып келе турган чараларды көрөбүз. Чынында, биз ушундай кылганбыз. Бул жерде дагы бир кичинекей эскертүү ...
Бул төрт маселенин бир нечеси, эгер сизде булут болсо, дароо чечилет. Эгерде сиз Microsoft Azhur, Ozone булуттарында болсоңуз, же Яндекс же Почтадан биздин булуттарды колдонсоңуз, анда жок дегенде аппараттык камсыздоонун бузулушу алардын көйгөйүнө айланат жана аппараттык камсыздоонун бузулушунун контекстинде сиз үчүн баары дароо жакшы болуп калат.
Биз бир аз салттуу эмес компаниябыз. Бул жерде баары "Кубернет" жөнүндө, булуттар жөнүндө айтып жатышат - бизде "Кубернет" да, булуттар да жок. Бирок бизде көптөгөн маалымат борборлорунда жабдыктардын стеллаждары бар жана биз бул жабдыкта жашоого аргасызбыз, биз анын бардыгы үчүн жоопкерчиликтүү болууга аргасызбыз. Ошондуктан биз ушул контекстте сүйлөшөбүз. Ошентип, көйгөйлөр жөнүндө. Биринчи экөө кашаадан чыгарылды.
Программанын версиясын өзгөртүү. Базалар
Биздин иштеп чыгуучулардын өндүрүшкө мүмкүнчүлүгү жок. Эмнеге андай? Бул жөн гана биз PCI DSS тастыкталган, жана биздин иштеп чыгуучулар жөн гана "продукцияга" кирүүгө укугу жок. Болду, мезгил. Таптакыр. Ошондуктан, иштеп чыгуу үчүн жоопкерчилик, иштеп чыгуу курууну чыгарууга тапшырган учурда аяктайт.
Биздин экинчи негизибиз, бул бизге көп жардам берет, уникалдуу документсиз билимдин жоктугу. Сен үчүн да ошондой болот деп үмүттөнөм. Анткени андай болбосо, сизде көйгөйлөр болот. Бул уникалдуу, документтештирилбеген билим керектүү убакта керектүү жерде болбогондо көйгөйлөр пайда болот. Келгиле, сизде белгилүү бир компонентти кантип жайгаштырууну билген бир адам бар дейли - адам жок, ал эс алууда же ооруп жатат - ушуну менен, сизде көйгөйлөр бар.
Ал эми биз келген үчүнчү негиз. Биз ага азап, кан, көз жаш аркылуу келдик – биздин түзүмдөрдүн кайсынысы болбосун, катасыз болсо да, каталарды камтыйт деген жыйынтыкка келдик. Биз муну өзүбүз чечтик: бир нерсени жайылтканда, бир нерсени өндүрүшкө киргизгенде, бизде каталар бар. Биздин система канааттандырууга тийиш болгон талаптарды түздүк.
Программанын версиясын өзгөртүү үчүн талаптар
Үч талаптар бар:
- Биз тез арада жайгаштырууну артка кайтарышыбыз керек.
- Биз ийгиликсиз жайгаштыруунун таасирин азайтышыбыз керек.
- Жана биз тез арада параллелдүү жайгаштыра алышыбыз керек.
Дал ушундай тартипте! Неге? Себеби, биринчиден, жаңы версияны жайылтууда ылдамдык маанилүү эмес, бирок сиз үчүн бир нерсе туура эмес болуп калса, тез арада артка жылып, минималдуу таасирге ээ болуу маанилүү. Бирок, эгерде сизде өндүрүштө версиялар топтому бар болсо, анда ката бар экени аныкталды (көк жерден, жайылтуу болгон эмес, бирок ката бар) - кийинки жайылтуунун ылдамдыгы сиз үчүн маанилүү. Бул талаптарды аткаруу үчүн биз эмне кылдык? Биз төмөнкү методологияга кайрылдык:
Бул абдан белгилүү, биз аны эч качан ойлоп тапкан эмеспиз - бул Көк/Жашыл жайгаштыруу. Бул эмне? Колдонмоңуз орнотулган серверлердин ар бир тобу үчүн сизде көчүрмө болушу керек. Көчүрмө "жылуу": анда трафик жок, бирок каалаган учурда бул трафик ушул көчүрмөгө жөнөтүлүшү мүмкүн. Бул көчүрмөдө мурунку версия бар. Жана жайылтуу учурунда сиз кодду активдүү эмес көчүрмөгө чыгарасыз. Андан кийин сиз трафиктин бир бөлүгүн (же бардыгын) жаңы версияга которосуз. Ошентип, трафиктин агымын эски версиядан жаңысына өзгөртүү үчүн бир гана иш-аракетти аткаруу керек: жогорку агымдагы балансизаторду алмаштыруу, багытты өзгөртүү - бир өйдө агымдан экинчи агымга. Бул абдан ыңгайлуу жана тез которуу жана тез артка кайтаруу маселесин чечет.Бул жерде экинчи суроонун чечими – минимизациялоо: сиз трафиктин бир бөлүгүн гана жаңы линияга, жаңы код менен сапка жөнөтө аласыз (мисалы, 2%). Жана бул 2% 100% эмес! Эгерде сиз трафиктин 100%ын ийгиликсиз жайгаштыруунун айынан жоготсоңуз, бул коркунучтуу; эгерде сиз трафиктин 2% жоготсоңуз, бул жагымсыз, бирок коркунучтуу эмес. Андан тышкары, колдонуучулар муну байкабай калышы мүмкүн, анткени кээ бир учурларда (баары эмес) бир эле колдонуучу F5 баскычын басып, башка жумушчу версияга өтүп кетет.
Көк/Жашыл жайгаштыруу. Маршрутизация
Бирок, баары ушунчалык жөнөкөй эмес "Blue/Green deploy"... Биздин бардык компоненттерди үч топко бөлүүгө болот:
- бул frontend (кардарларыбыз көргөн төлөм барактары);
- иштетүү өзөгү;
- төлөм системалары менен иштөө үчүн адаптер (банктар, 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 дарегин кошумча талаага бериңиз, сиздин протоколуңуз стандартташтырылган”! Алар макул болбой турганы анык.
Ошондуктан, бул биз үчүн эч кандай натыйжа берген жок - биз ачык-айкындык кылдык. Демек, багыттоо менен биз төмөнкүдөй нерсени алдык:Blue/Green Deployment, демек, мен айткан артыкчылыктарга жана кемчиликтерге ээ.
Эки кемчиликтери:
- сиз маршрутизация менен убара болушуңуз керек;
- экинчи негизги кемчилик чыгаша болуп саналат.
Сизге эки эсе көп серверлер керек, эки эсе көп оперативдүү ресурстар керек, бул зоопаркты бүтүндөй кармап туруу үчүн эки эсе көп күч жумшашыңыз керек.
Айтмакчы, артыкчылыктардын арасында мен мурда айтпаган дагы бир нерсе бар: жуктун есушуне карата резерв бар. Эгерде сизде жүктөөдө жарылуучу өсүш болсо, анда колдонуучулардын саны көп болсо, анда сиз жөн гана экинчи сапты 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/7 инженер отурушу керек, ал муну менен гана алектениши керек, анткени 70 система артыңызда турганда, мындай бузулуулар дайыма болуп турат.
Ошондуктан, биз ачык IP бар Nomadды карап чыктык жана өзүбүздүн нерсени жаздык, Scale-Nomad - ScaleNo, ал болжол менен төмөндөгүлөрдү аткарат: ал кезектин өсүшүн көзөмөлдөйт жана динамикага жараша жумушчулардын санын азайтат же көбөйтөт. кезекте. Биз муну жасаганда: "Балким аны ача алабызбы?" Анан алар аны карап калышты - ал эки тыйындай жөнөкөй эле.
Азырынча биз аны ача элекпиз, бирок күтүлбөгөн жерден отчеттон кийин, сизге ушундай нерсе керек экенин түшүнгөндөн кийин, сизге керек болсо, менин байланыштарым акыркы слайдда - мага жазыңыз. Жок дегенде 3-5 адам болсо демөөрчүлүк кылабыз.
Бул кандай иштейт? Келгиле, карап көрөлү! Алдыга карасак: сол жагында биздин мониторингдин бир бөлүгү бар: бул бир сызык, жогоруда окуяны иштетүү убактысы, ортосунда транзакциялардын саны, ылдыйда жумушчулардын саны.Эгер карасаңыз, бул сүрөттө ката бар. Жогорку диаграммада диаграммалардын бири 45 секунданын ичинде кыйрады - төлөм системаларынын бири түшүп кетти. Ошол замат 2 мүнөттүн ичинде трафик киргизилип, жумушчу жок башка төлөм системасында кезек көбөйө баштады (ресурстарды пайдаланган жокпуз – тескерисинче, ресурсту туура тескөөбүз керек). Биз жылытууну каалабадык - минималдуу сан, болжол менен 5-10 жумушчу бар болчу, бирок алар туруштук бере алышкан жок.
Акыркы графикте "өркөч" көрсөтүлгөн, бул жөн гана "Skaleno" бул сумманы эки эсеге көбөйткөн дегенди билдирет. Анан график бир аз төмөндөгөндө, аны бир аз кыскартты - жумушчулардын саны автоматтык түрдө өзгөрдү. Бул нерсе ушундай иштейт. Биз №2 пункт жөнүндө сүйлөштүк - "Себептерден кантип тез арылуу керек."
Мониторинг. Көйгөйдү кантип тез аныктоого болот?
Эми биринчи пункт "Маселени кантип тез аныктоо керек?" Мониторинг! Биз кээ бир нерселерди тез түшүнүшүбүз керек. Эмнени тез түшүнүшүбүз керек?
Үч нерсе!- Биз өзүбүздүн ресурстарыбыздын натыйжалуулугун тез түшүнүшүбүз жана түшүнүшүбүз керек.
- Биз каталарды тез түшүнүшүбүз керек жана бизге тышкы системалардын иштешин көзөмөлдөшүбүз керек.
- Үчүнчү пункт логикалык каталарды аныктоо болуп саналат. Бул система сиз үчүн иштеп жатканда, бардык көрсөткүчтөр боюнча бардыгы нормалдуу, бирок бир нерсе туура эмес болуп жатат.
Мен, балким, бул жерде сонун эч нерсе айтпайм. Мен капитан Айкын болом. Базарда эмне бар экенин издедик. Бизде "көңүлдүү зоопарк" бар. Бул бизде азыр зоопарктын түрү:
Биз Zabbixти аппараттык камсыздоону көзөмөлдөө, серверлердин негизги көрсөткүчтөрүн көзөмөлдөө үчүн колдонобуз. Биз маалымат базалары үчүн Okmeter колдонобуз. Биз биринчи экөөнө туура келбеген бардык башка көрсөткүчтөр үчүн "Графана" жана "Прометейди" колдонобуз, кээ бирлери "Графана" жана "Прометей", ал эми кээ бирлери "Графана" менен "Инфлюкс" жана Телеграф.Бир жыл мурун биз 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". «Жагер» чындыгында ушундай идеялык мураскер, «Зипкиндин» идеялык улантуучусу. Зипкинде баары жакшы, болгону топтоштурганды билбегени, логдорду трассага киргизүүнү билбейт, болгону убакыт изи. Ал эми "Жагер" муну колдоду.
Биз "Жагерди" карадык: сиз приложенияларды түзө аласыз, Apiде жаза аласыз (ошол убакта PHP үчүн Api стандарты бекитилген эмес - бул бир жыл мурун болгон, бирок азыр ал бекитилген), бирок ал жерде такыр эле кардар болгон эмес. "Макул" деп ойлоп, өзүбүздүн кардарыбызды жаздык. Биз эмне алдык? Бул болжол менен ушундай көрүнөт:
Jaegerде ар бир билдирүү үчүн аралыктар түзүлөт. Башкача айтканда, колдонуучу системаны ачканда, ал ар бир кирүүчү суроо-талап үчүн бир же эки блокту көрөт (1-2-3 - колдонуучудан келген суроо-талаптардын саны, блоктордун саны). Колдонуучуларга жеңилдетүү үчүн, биз журналдарга жана убакыт издерине тегдерди коштук. Демек, ката болгон учурда, биздин колдонмо журналды тийиштүү Ката теги менен белгилейт. Ката теги боюнча чыпкалай аласыз жана катасы бар бул блокту камтыган аралыктар гана көрсөтүлөт. Бул аралыкты кеңейтсек, мындай болот:
Аралыктын ичинде издердин топтому бар. Бул учурда, бул үч сыноо изи болуп саналат, ал эми үчүнчү из бизге ката болгонун айтат. Ошол эле учурда, бул жерде биз убакыттын изин көрөбүз: бизде убакыт шкаласынын жогору жагында бар жана биз тигил же бул журнал кайсы убакыт аралыгында жазылганын көрөбүз.Ошого жараша биз үчүн да иш жакшы өттү. Биз өзүбүздүн кеңейтүүбүздү жаздык жана аны ачтык. Эгерде сиз трасса менен иштегиңиз келсе, PHPде “Jager” менен иштегиңиз келсе, анда биздин кеңейтүү бар, алар айткандай, колдонууга кош келиңиз:
Бизде бул кеңейтүү бар - бул OpenTracing Api үчүн кардар, ал php-кеңейтүү катары жасалган, башкача айтканда, аны чогултуп, системага орнотуу керек болот. Бир жыл мурун башкача эч нерсе болгон эмес. Азыр компоненттерге окшош башка кардарлар бар. Бул жерде сизден көз каранды: же сиз компоненттерди композитор менен чыгарасыз, же сиз кеңейтүүнү колдоносуз.Корпоративдик стандарттар
Биз үч осуят жөнүндө сүйлөштүк. Төртүнчү осуят ыкмаларды стандартташтыруу. Бул эмне жөнүндө? Бул тууралуу:
Эмне үчүн бул жерде "корпоративдик" деген сөз бар? Биз чоң же бюрократиялык компания болгондуктан эмес, жок! Мен бул жерде “корпоративдик” деген сөздү ар бир компаниянын, ар бир продукттун өзүнүн стандарттары, анын ичинде сиз да болушу керек деген контекстте колдонгум келди. Бизде кандай стандарттар бар?
- Бизде жайгаштыруу эрежелери бар. Биз алсыз эч жакка көчпөйбүз, мүмкүн эмес. Биз жумасына 60 жолу жайгаштырабыз, башкача айтканда, биз дээрлик дайыма жайгаштырабыз. Ошол эле учурда, бизде, мисалы, жайгаштыруу эрежелеринде жума күнү жайылтууга тыюу салынган - негизинен, биз жайгаштырбайбыз.
- Биз документтерди талап кылат. Бир дагы жаңы компонент өндүрүшкө кирбейт, эгерде ал үчүн документтер жок болсо, ал биздин RnD адистеринин калеминен жаралган болсо да. Биз алардан жайылтуу боюнча инструкцияларды, мониторинг картасын жана бул компоненттин кандайча иштээрин, аны чечүү жолдорун болжолдоону (программисттер жаза тургандай) талап кылабыз.
- Биз маселенин себебин эмес, көйгөйдү чечебиз - мен буга чейин айтканымды. Колдонуучуну көйгөйлөрдөн коргоо биз үчүн маанилүү.
- Бизде уруксаттар бар. Мисалы, биз эки мүнөттүн ичинде трафиктин 2% жоготсок, аны токтоп калуу деп эсептебейбиз. Бул негизи биздин статистикага кирбейт. Эгерде ал пайыздык же убактылуу көп болсо, биз буга чейин эле эсептейбиз.
- Ал эми биз ар дайым өлүмдөн кийин жазабыз. Бизге кандай гана жагдай болбосун, кимдир бирөө өндүрүштө өзүн анормалдуу алып жүргөн бардык жагдайлар өлгөндөн кийин чагылдырылат. Постмортем - бул сизге эмне болгонун, деталдуу убакытты, аны оңдоо үчүн эмне кылганыңызды жана (бул милдеттүү блок!) келечекте муну болтурбоо үчүн эмне кыла турганыңызды жаза турган документ. Бул милдеттүү жана кийинки талдоо үчүн зарыл.
Эмне токтоп калуу деп эсептелет?
Мунун баары эмнеге алып келди?Бул (бизде туруктуулук боюнча белгилүү бир көйгөйлөр бар болчу, бул кардарларга да, бизге да туура келген жок) акыркы 6 айда биздин туруктуулук көрсөткүчүбүз 99,97 болгонуна алып келди. Бул өтө көп эмес деп айта алабыз. Ооба, биз умтула турган нерсебиз бар. Бул көрсөткүчтүн жарымына жакыны туруктуулук, биздики эмес, биздин веб тиркемелердин брандмауэри, ал биздин алдыбызда турат жана кызмат катары колдонулат, бирок кардарлар буга маани беришпейт.
Түнкүсүн уктаганды үйрөндүк. Акыры! Алты ай мурун биз кыла алган жокпуз. Ал эми жыйынтыктар менен бул жазуу боюнча, мен бир эскертүү айткым келет. Кечээ кечинде ядролук реакторду башкаруу системасы жөнүндө эң сонун билдирүү болду. Бул системаны жазган адамдар мени уга турган болсо, сураныч, "2% иштебей калуу эмес" жөнүндө айтканымды унутуп коюңуз. Сиз үчүн эки мүнөт болсо да 2% иштебей калуу!
Баары болду! Сиздин суроолоруңуз.
Балансерлер жана маалымат базасынын миграциясы жөнүндө
Угуучулардын суроосу (мындан ары – Б): – Кутмандуу кеч. Ушундай админ отчету үчүн чоң рахмат! Сиздин балансерлер жөнүндө кыска суроо. Сизде WAF бар деп айттыңыз, башкача айтканда, мен түшүнгөндөй, кандайдыр бир тышкы балансизаторду колдоносуз...
EK: – Жок, биз баланстоочу катары кызматтарыбызды колдонобуз. Бул учурда, WAF биз үчүн бир гана DDoS коргоо куралы болуп саналат.
IN: – Балансчылар жөнүндө бир нече сөз айта аласызбы?
EK: – Жогоруда айткандай, бул ачык-айкын серверлердин тобу. Азыр бизде 5 резервдик топ бар, алар эксклюзивдүү жооп беришет... башкача айтканда, эксклюзивдүү ачык режимде иштеген сервер, ал трафикти гана проксилейт. Демек, биз канча кармап турганыбызды түшүнүү үчүн: бизде азыр бир нече жүз мегабиттик трафиктин агымы бар. Алар туруштук беришет, өздөрүн жакшы сезишет, атүгүл өздөрүн чыңдабайт.
IN: – Ошондой эле жөнөкөй суроо. Бул жерде Көк/Жашыл жайгаштыруу. Мисалы, маалымат базасын көчүрүү менен эмне кыласыз?
EK: - Жакшы суроо! Караңыз, Көк/Жашыл жайылтууда бизде ар бир сап үчүн өзүнчө кезектер бар. Башкача айтканда, эгерде биз жумушчудан жумушчуга өтүүчү иш-чара кезеги жөнүндө сөз кыла турган болсок, анда көк линия жана жашыл линия үчүн өзүнчө кезек бар. Эгерде биз маалымат базасынын өзү жөнүндө сөз кыла турган болсок, анда биз аны мүмкүн болушунча атайылап тарытып, бардыгын иш жүзүндө кезекке жылдырдык; маалымат базасында биз транзакциялардын стектерин гана сактайбыз. Жана биздин транзакциялар стек бардык линиялар үчүн бирдей. Бул контекстте маалымат базасы менен: биз аны көк жана жашыл деп бөлбөйбүз, анткени коддун эки версиясы транзакция менен эмне болуп жатканын билиши керек.
Достор, менин дагы сиздерге түрткү бере турган кичинекей сыйлыгым бар - китеп. Ал эми эң жакшы суроо үчүн мага сыйлык бериш керек.
IN: - Салам. Отчет үчүн рахмат. Суроо мына ушунда. Сиз төлөмдөрдү көзөмөлдөйсүз, сиз баарлашкан кызматтарды көзөмөлдөйсүз... Бирок, сиздин төлөм баракчаңызга адам кандайдыр бир жол менен келип, төлөм жүргүзгөн жана долбоор ага акча салганын кантип көзөмөлдөйсүз? Башкача айтканда, марчанттын жеткиликтүү экендигин жана сиздин кайра чалууну кабыл алганын кантип көзөмөлдөйсүз?
EK: – Бул учурда биз үчүн “Соодагер” – бул төлөм системасы сыяктуу эле тышкы кызмат. Биз соодагердин жооп берүү ылдамдыгын көзөмөлдөйбүз.
Маалыматтар базасын шифрлөө жөнүндө
IN: - Салам. Менде бир аз байланыштуу суроо бар. Сизде PCI DSS сезимтал маалыматтар бар. Мен сиз PAN'ды которуу үчүн кезекке кантип сактай турганыңызды билгим келди? Сиз кандайдыр бир шифрлөө колдоносузбу? Ал эми бул экинчи суроого алып келет: PCI DSS ылайык, маалыматтар базасын өзгөртүү (администраторлорду иштен алуу ж.б.) учурда мезгил-мезгили менен кайра шифрлөө зарыл - бул учурда жеткиликтүүлүк эмне болот?
EK: - Керемет суроо! Биринчиден, биз PANдарды кезекте сактабайбыз. Биз PANды так түрдө эч жерде сактоого укугубуз жок, ошондуктан биз атайын кызматты колдонобуз (биз аны “Кадемон” деп атайбыз) – бул бир гана нерсени аткарган кызмат: ал билдирүүнү киргизүү катары кабыл алат жана жөнөтөт. шифрленген билдирүү. Жана биз бардыгын ушул шифрленген билдирүү менен сактайбыз. Демек, биздин ачкычтын узундугу бир килобайттан төмөн, андыктан бул олуттуу жана ишенимдүү.IN: – Азыр сизге 2 килобайт керекпи?
EK: – Кечээ эле 256 болду окшойт... Кана, башка кайда?!
Ошого жараша бул биринчи. Экинчиден, бар болгон чечим, ал кайра шифрлөө процедурасын колдойт - эки жуп "кекс" (ачкычтар) бар, алар шифрлөөчү "палубаларды" берет (ачкыч - ачкыч, дек - шифрлөөчү ачкычтардын туундулары) . Ал эми процедура башталса (ал үзгүлтүксүз болуп турат, 3 айдан ± бир азга чейин), биз жаңы жуп "торттарды" жүктөп алып, маалыматтарды кайра шифрлейбиз. Бизде өзүнчө кызматтар бар, алар бардык маалыматтарды айрып, жаңы ыкма менен шифрлейт; Маалымат ал шифрленген ачкычтын идентификаторунун жанында сакталат. Демек, биз маалыматтарды жаңы ачкычтар менен шифрлегенден кийин, эски ачкычты жок кылабыз.
Кээде төлөмдөр кол менен жүргүзүлүшү керек...
IN: – Башкача айтканда, кандайдыр бир операция үчүн акчаны кайтаруу келип калса, аны эски ачкыч менен чечесизби?
EK: - Ооба.
IN: – Анда дагы бир кичинекей суроо. Кандайдыр бир ката, кулап же окуя болгондо, транзакцияны кол менен түртүү керек. Ондай жагдай бар.
EK: - Ооба кээде.
IN: – Бул маалыматты кайдан аласыз? Же бул сактоочу жайга өзүң барасыңбы?
EK: – Жок, албетте, бизде колдоо көрсөтүү үчүн интерфейсти камтыган бэк-офис системасы бар. Эгерде транзакция кандай статуста экенин билбесек (мисалы, төлөм системасы тайм-аут менен жооп бергенге чейин), биз априори билбейбиз, башкача айтканда, биз акыркы статусту толук ишеним менен гана ыйгарабыз. Бул учурда, биз кол менен иштетүү үчүн атайын статуска бүтүм дайындайбыз. Эртең менен, эртеси, колдоо кызматы төлөм системасында тигил же бул транзакциялар калганы тууралуу маалымат алаар замат, аларды бул интерфейсте кол менен иштетишет.
IN: – Менин бир эки суроом бар. Алардын бири PCI DSS зонасынын уландысы: алардын схемасын кантип каттайсыз? Бул суроо, анткени иштеп чыгуучу журналдарга каалаган нерсени киргизиши мүмкүн! Экинчи суроо: оңдоолорду кантип чыгарасыз? Берилиштер базасында туткаларды колдонуу бир вариант, бирок бекер оңдоолор болушу мүмкүн - ал жерде кандай процедура бар? Ал эми үчүнчү суроо RTO, RPO менен байланыштуу болсо керек. Сиздин жеткиликтүүлүгүңүз 99,97 болчу, дээрлик төрт тогуз, бирок мен түшүнгөндөй, сизде экинчи маалымат борбору, үчүнчү маалымат борбору жана бешинчи маалымат борбору бар ... Аларды кантип синхрондоштуруу, аларды кайталоо жана башка бардык нерселер бар?EK: - Биринчисинен баштайлы. Биринчи суроо журналдар жөнүндө болдубу? Биз журналдарды жазганда, бизде бардык купуя маалыматтарды жашырган катмар бар. Ал масканы жана кошумча талааларды карайт. Демек, биздин журналдар мурунтан эле маскаланган маалыматтар жана PCI DSS схемасы менен чыгат. Бул тестирлөө бөлүмүнө жүктөлгөн кезектеги милдеттердин бири. Алар ар бир тапшырманы, анын ичинде алар жазган журналдарды текшерүүгө милдеттүү жана бул иштеп чыгуучу бир нерсе жазбагандыгын көзөмөлдөө үчүн кодду карап чыгуу учурундагы кадимки тапшырмалардын бири. Муну кийинки текшерүүлөр маалыматтык коопсуздук бөлүмү тарабынан жумасына бир жолу үзгүлтүксүз жүргүзүлүп турат: акыркы суткадагы журналдар тандалып алынат жана бардыгын текшерүү үчүн тесттик серверлерден атайын сканер-анализатор аркылуу иштетилет.
Ыкчам оңдоолор жөнүндө. Бул биздин жайгаштыруу эрежелеринде камтылган. Бизде оңдоолор жөнүндө өзүнчө пункт бар. Биз тууралоолорду керек болгондо күнү-түнү орнотобуз деп ишенебиз. Версия чогултулгандан кийин, ал иштетилгенден кийин, бизде артефакт болгондон кийин, колдоо кызматынын чакыруусу боюнча бизде системалык администратор нөөмөттө турат жана ал аны керектүү учурда жайылтат."Төрт тогуз" жөнүндө. Бизде болгон көрсөткүч чындап эле жетишилди жана биз ага башка дата-борбордо аракет кылдык. Азыр бизде экинчи маалымат борбору бар жана биз алардын ортосунда каттам жасай баштайбыз жана маалымат борборлорунун кайчылаш репликациясы маселеси чындыгында анча маанилүү эмес маселе. Биз аны бир убакта ар кандай каражаттарды колдонуу менен чечүүгө аракет кылдык: биз бир эле "Тарантуланы" колдонууга аракет кылдык - бул биз үчүн жакшы болгон жок, мен сизге дароо айтып берем. Ошондуктан биз «сендерге» кол менен заказ берип бүттүк. Чынында, биздин тутумдагы ар бир тиркеме маалымат борборлорунун ортосунда зарыл болгон "өзгөртүү - аткарылган" синхрондоштурууну асинхрондуу түрдө жүргүзөт.
IN: – Экинчиси болсо, үчүнчүсүн эмнеге алган жоксуң? Анткени эч кимдин мээси жарала элек...
EK: – Бирок бизде Split Brain жок. Ар бир тиркеме мультимастер тарабынан башкарылгандыктан, сурам кайсы борборго келгени бизге маанилүү эмес. Эгерде биздин маалымат борборлорубуздун бири иштебей калса (биз буга ишенебиз) жана колдонуучунун суроо-талабынын ортосунда экинчи маалымат борборуна өтсө, биз бул колдонуучуну жоготуп коюуга даярбыз; бирок булар бирдиктер, абсолюттук бирдиктер болот.
IN: - Кайырлуу кеч. Отчет үчүн рахмат. Сиз өндүрүштө кээ бир сыноо транзакцияларын жүргүзгөн мүчүлүштүктөрдү оңдоочу жөнүндө айттыңыз. Бирок бизге сыноо транзакциялары жөнүндө айтып бериңиз! Канчалык тереңге барат?
EK: – Ал бүт компоненттин толук циклинен өтөт. Компонент үчүн сыноо бүтүмү менен өндүрүштүн ортосунда эч кандай айырма жок. Бирок логикалык көз караштан алганда, бул жөн гана тесттик транзакциялар ишке ашырылган системадагы өзүнчө долбоор.
IN: - Аны кайдан кесип жатасың? Бул жерде Core жөнөтүлдү ...
EK: – Тесттик транзакциялар үчүн бул учурда биз “Кордун” артында турабыз... Бизде маршруттоо деген нерсе бар: “Кор” кайсы төлөм системасына жөнөтүүнү билет - биз жасалма төлөм системасына жөнөтөбүз, ал жөн гана http сигналын берет жана баары болду.
IN: – Айтыңызчы, сиздин арызыңыз бир чоң монолитте жазылганбы же аны кандайдыр бир кызматтарга, атүгүл микросервистерге кесип салдыңызбы?
EK: – Бизде монолит жок, албетте, бизде сервиске багытталган колдонмо бар. Биздин кызмат монолиттерден жасалган деп тамашалайбыз - алар чындап эле абдан чоң. Аны микросервис деп айтуу кыйын, бирок бул бөлүштүрүлгөн машиналардын жумушчулары иштеген кызматтар.
Сервердеги кызмат бузулса...
IN: – Анда менин кийинки суроом бар. Бул монолит болгон күндө да, сиз дагы эле сизде ушул тез серверлердин көбү бар деп айттыңыз, алардын бардыгы негизинен маалыматтарды иштетет жана суроо: “Ыкчам серверлердин же тиркемелердин биринин компромисси болгон учурда, кандайдыр бир жеке шилтеме , аларда кандайдыр бир мүмкүнчүлүктү башкаруу барбы? Алардын кимиси эмне кыла алат? Кандай маалымат алуу үчүн кимге кайрылышым керек?
EK: - Ооба, албетте. Коопсуздук талаптары абдан олуттуу. Биринчиден, бизде ачык маалымат кыймылдары бар жана порттор биз трафиктин кыймылын алдын ала күткөн порттор. Эгерде компонент маалымат базасы менен (мисалы, Мускул менен) 5-4-3-2 аркылуу байланышса, ага 5-4-3-2 гана ачык болот жана башка порттор жана башка трафик багыттары жеткиликтүү болбойт. Мындан тышкары, биздин өндүрүштө 10го жакын ар кандай коопсуздук илмектери бар экенин түшүнүү керек. Тиркеме кандайдыр бир жол менен бузулган болсо да, Кудай сактасын, чабуулчу серверди башкаруу консолуна кире албайт, анткени бул башка тармактык коопсуздук зонасы.IN: – Жана бул контекстте мага көбүрөөк кызыгы, сиздин кызматтар менен кандайдыр бир келишимдериңиз бар – алар эмне кыла алат, кандай “иш-аракеттери” аркылуу бири-бири менен байланыша алат... Ал эми кадимки агымда кээ бир спецификалык кызматтар айрымдарды талап кылат. катар, экинчи жагынан "иш-аракеттердин" тизмеси. Алар кадимки кырдаалда башкаларга кайрылышпайт окшойт, жана башка жоопкерчилик чөйрөлөрү бар. Алардын бири компромисске кабылса, ал ошол кызматтын “иштерин” үзгүлтүккө учурата алабы?..
EK: - Мен түшүнөм. Эгерде кадимки кырдаалда башка сервер менен баарлашууга такыр уруксат берилген болсо, анда ооба. SLA келишимине ылайык, биз сизге биринчи 3 "аракетке" гана уруксат берилгендигине, ал эми 4 "аракетке" уруксат берилбегендигине көз салбайбыз. Бул биз үчүн ашыкча болушу мүмкүн, анткени бизде схемалар үчүн 4-деңгээлдүү коргоо системасы бар. Биз өзүбүздү ички денгээлде эмес, контурлар менен коргоону туура көрөбүз.
Visa, MasterCard жана Сбербанк кантип иштейт
IN: – Колдонуучуну бир маалымат борборунан экинчисине которуу боюнча бир жагдайды тактагым келет. Менин билишимче, Visa жана MasterCard 8583 бинардык синхрондуу протоколду колдонуу менен иштешет жана ал жерде аралашмалар бар. Мен билгим келди, азыр биз которуштурууну билдирет – бул түздөн-түз “Visa” жана “MasterCard”бы же төлөм системаларынан мурунбу, иштетүүдөн мурунбу?
EK: - Бул аралашмалар алдында. Биздин аралашмалар ошол эле маалымат борборунда жайгашкан.
IN: – Болжол менен айтканда, сизде бир эле байланыш барбы?
EK: – “Visa” жана “MasterCard” – ооба. Жөн гана Visa жана MasterCard, мисалы, экинчи жуп микстерди алуу үчүн өзүнчө келишимдерди түзүү үчүн инфраструктурага олуттуу инвестицияларды талап кылат. Алар бир маалымат борборунун ичинде сакталган, бирок, Кудай сактасын, Visa жана MasterCard менен туташуу үчүн аралашмалар бар биздин дата борборубуз өлүп калса, Visa жана MasterCard менен байланышыбыз үзүлүп калат...
IN: – Аларды кантип сактаса болот? Мен Visa бир гана байланышка уруксат берерин билем!
EK: – Жабдууларды өздөрү камсыздайт. Кандай болгон күндө да ичинде толук ашыкча болгон жабдууларды алдык.
IN: – Демек, стенд алардын Connects Orange компаниясынанбы?..
EK: - Ооба.
IN: – Бирок бул окуя тууралуу эмне айтууга болот: эгер сиздин дата борборуңуз жок болуп кетсе, аны кантип колдоно аласыз? Же трафик токтойбу?
EK: - Жок. Бул учурда биз трафикти жөн эле башка каналга которушат, бул, албетте, биз үчүн кымбатыраак жана биздин кардарлар үчүн кымбатыраак болот. Бирок трафик Visa, MasterCard менен түз байланышыбыз аркылуу эмес, шарттуу Сбербанк аркылуу (өтө апыртылган) өтөт.
Сбербанктын кызматкерлерин таарынткан болсом, кечирим сурайм. Бирок биздин статистикага ылайык, орус банктарынын арасында Сбербанк көбүнчө түшөт. Сбербанкте бир нерсе түшпөй, бир ай өтпөйт.
Кээ бир жарнамалар 🙂
Биз менен болгонуңуз үчүн рахмат. Биздин макалалар сизге жагабы? Көбүрөөк кызыктуу мазмунду көргүңүз келеби? Буйрутма берүү же досторуңузга сунуштоо менен бизди колдоңуз, , биз сиз үчүн ойлоп тапкан баштапкы деңгээлдеги серверлердин уникалдуу аналогу: (RAID1 жана RAID10 менен жеткиликтүү, 24 өзөккө чейин жана 40 ГБ DDR4 чейин).
Dell R730xd Амстердамдагы Equinix Tier IV маалымат борборунда 2 эсе арзанбы? Бул жерде гана Нидерландыда! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 доллардан! Жөнүндө окуу
Source: www.habr.com