HighLoad++, Яўген Кузаўлёў (EcommPay IT): што рабіць, калі хвіліна прастою каштуе $100000

Усё расказваюць пра працэсы распрацоўкі і тэсціравання, навучання персаналу, павышэнне матывацыі, але гэтых працэсаў мала, калі хвіліна прастою сэрвісу каштуе касмічных грошай. Што рабіць, калі вы праводзіце фінансавыя транзакцыі пад жорсткі SLA? Як павысіць надзейнасць і адмоваўстойлівасць вашых сістэм, выносячы за дужкі распрацоўку і тэсціраванне?

Наступная канферэнцыя HighLoad++ пройдзе 6 і 7 красавіка 2020 гады ў Санкт-Пецярбургу. Падрабязнасці і білеты па спасылцы. 9 лістапада, 18:00. HighLoad++ Moscow 2018, зала «Дэлі + Калькута». Тэзісы і прэзентацыя.

Яўген Кузаўлёў (далей - ЕК): - Сябры, прывітанне! Мяне клічуць Кузаўлёў Яўген. Я з кампаніі EcommPay, канкрэтнае падраздзяленне - EcommPay IT, айці-падраздзяленне групы кампаній. І сёння мы з вамі пагаворым аб даунтаймах - аб тым, як іх пазбегнуць, аб тым, як мінімізаваць іх наступствы, калі пазбегнуць не атрымаецца. Тэматыка заяўлена такая: «Што рабіць, калі хвіліна прастою каштуе 100 000 долараў»? У нас, забягаючы наперад, лічбы параўнальныя.

Чым займаецца EcommPay IT?

Хто мы такія? Чаму я тут перад вамі стаю? Чаму я маю права вам тут нешта расказваць? І пра што пагаворым тут больш падрабязна?

Група кампаній EcommPay - гэта міжнародны эквайр. Мы працэсім плацяжы па ўсім свеце - у Расіі, Еўропе, у Паўднёва-Усходняй Азіі (All Around the World). У нас 9 офісаў, 500 супрацоўнікаў усяго і прыкладна крыху менш за палову сярод іх – гэта IT-спецыялісты. Усё, што мы робім, усё, на чым мы зарабляем грошы, мы зрабілі самі.

У нас усе нашы прадукты (а іх у нас дастаткова шмат – у лінейцы вялікіх IT-прадуктаў у нас каля 16 розных кампанентаў) мы напісалі самі; мы самі пішам, мы самі развіваем. І на дадзены момант мы праводзім каля мільёна транзакцый у дзень (мільёны - напэўна, так будзе правільна сказаць). Мы маладая кампанія дастаткова - нам усяго каля шасці гадоў.

6 гадоў таму гэта быў такі стартап, калі прыйшлі хлопцы разам з бізнесам. Яны былі аб'яднаныя ідэяй (больш нічога не было, акрамя ідэі), і мы пабеглі. Як і любы стартап, мы беглі хутчэй… Для нас была важнейшая хуткасць, а не якасць.

У нейкі момант мы спыніліся: усвядомілі, што мы ўжо не можам з той хуткасцю і з той якасцю неяк жыць і нам трэба рабіць у першую чаргу менавіта якасць. У гэты момант мы прынялі рашэнне напісаць новую платформу, якая будзе правільнай, якая маштабуецца, надзейнай. Гэтую платформу пачалі пісаць (пачалі ўкладваць, развіваць распрацоўку, тэсціраванне), але ў нейкі момант зразумелі, што распрацоўка, тэсціраванне не дазваляюць выйсці на новы ўзровень якасці сэрвісу.

Вы робіце новы прадукт, вы яго выстаўляеце на прадакшн, але ўсё роўна недзе нешта пойдзе не так. І сёння мы пагаворым аб тым, як выйсці на новы якасны ўзровень (у нас як гэта атрымалася, пра наш вопыт), выносячы за дужкі распрацоўку і тэсціраванне; мы пагаворым пра тое, што даступна эксплуатацыі - што эксплуатацыя можа зрабіць сама, што яна можа прапанаваць тэсціраванню, каб паўплываць на якасць.

Даўнтаймы. Запаведзі эксплуатацыі.

Заўсёды асноўны краевугольны камень, пра што мы сёння, уласна, будзем казаць - даунтайм. Страшнае слова. Калі ў нас здарыўся даунтайм - у нас усё дрэнна. Мы бяжым паднімаць, адміны сервер трымаюць - дай бог не ўпадзе, як у той песні спяваецца. Вось аб гэтым мы сёння пагаворым.

Калі мы пачалі мяняць свае падыходы, мы сфарміравалі 4 запаведзі. Яны ў мяне прадстаўлены на слайдах:

Гэтыя запаведзі дастаткова простыя:

• Хутка выявіць праблему.
• Яшчэ хутчэй ад яе пазбавіцца.
• Дапамагчы зразумець прычыну (потым, для распрацоўшчыкаў).
• І стандартаваць падыходы.

Звярну вашу ўвагу на пункт № 2. Мы пазбаўляемся праблемы, а не вырашаем яе. Вырашыць - гэта другасна. Для нас першасна тое, што карыстач агароджаны ад гэтай праблемы. Яна будзе існаваць у нейкім ізаляваным асяроддзі, але гэтае асяроддзе ніяк не будзе з ім кантактаваць. Уласна, мы з вамі пройдземся па гэтых чатырох групах праблем (па нейкіх падрабязней, па нейкіх менш падрабязна), я раскажу, што мы выкарыстоўваем, які ў нас адпаведны вопыт у рашэннях.

Устараненне праблем: калі яны здараюцца і што з імі рабіць?

Але пачнем мы не па парадку, пачнем мы з пункта № 2 - як хутка пазбавіцца ад праблемы? Ёсць праблема - нам яе трэба ўхіліць. "Што нам з гэтым рабіць?" - асноўнае пытанне. І калі мы пачалі думаць аб тым, як ухіліць праблему, мы для сябе выпрацавалі некаторыя патрабаванні, якім ухіленне праблем павінна вынікаць.

Каб гэтыя патрабаванні сфармуляваць, мы вырашылі сабе задаць пытанне: "А калі ў нас здараюцца праблемы"? І праблемы, як высветлілася, сустракаюцца ў чатырох выпадках:

• Апаратная няспраўнасць.
• Збой вонкавых сэрвісаў.
• Змена версіі ПЗ (той самы дэплой).
• Выбухны рост нагрузкі.

Пра першыя дзве мы з вамі размаўляць не будзем. Апаратная няспраўнасць вырашаецца дастаткова проста: у вас павінна быць усё дубляванае. Калі гэта дыскі - дыскі павінны быць сабраны ў RAID, калі гэта сервер - сервер павінен быць дубляваны, калі ў вас сеткавая інфраструктура - вы павінны паставіць другую копію сеткавай інфраструктуры, гэта значыць вы бераце і дублюеце. І калі ў вас нешта адмаўляе, вы пераключаецеся на рэзервовыя магутнасці. Тут больш нешта сказаць складана.

Другое - гэта збой знешніх сэрвісаў. Для большасці сістэма гэта ўвогуле не праблема, але не для нас. Так як мы працэсім плацяжы, то мы такі агрэгатар, які стаіць паміж карыстальнікам (які ўводзіць свае картачныя дадзеныя) і банкамі, плацёжнымі сістэма ("Віза", "МайстарКард", "Міру" таго ж). Вонкавым нашым сэрвісам (плацежным сістэмам, слоікам) уласціва збаіць. Паўплываць ні мы, ні вы (калі ў вас ёсць такія сэрвісы) на гэта не можам.

Што тады рабіць? Тут варыянту два. Па-першае, калі вы можаце, вы павінны задубліраваць гэты сэрвіс нейкім чынам. Напрыклад, мы, калі можам, перакідаем трафік з аднаго сэрвісу на іншы: працэсілі, напрыклад, карты праз "Ашчадбанк", у "Ашчадбанка" праблемы - мы перакладаем трафік [умоўна] на "Райффайзен". Другое, што мы можам зрабіць - гэта вельмі хутка заўважыць збой знешніх сэрвісаў, і таму мы пагаворым аб хуткасці рэакцыі ў наступнай частцы дакладу.

Па факце з гэтых чатырох мы можам канкрэтна паўплываць на змену версій ПЗ - зрабіць дзеянні, якія прывядуць да паляпшэння сітуацыі ў кантэксце дэплоеяў і ў кантэксце выбуховага росту нагрузкі. Уласна, мы гэта і зрабілі. Тут, зноў жа, маленькая рэмарка...

З гэтых чатырох праблем некалькі вырашаюцца адразу, калі ў вас ёсць воблака. Калі вы знаходзіцеся ў аблоках "Майкрасофт Ажур", "Азон", выкарыстоўваеце нашы аблокі, ад "Яндэкса" ці "Мэйла", то як мінімум апаратная няспраўнасць становіцца іх праблемай і ў вас адразу ўсё становіцца добра ў кантэксце апаратнай няспраўнасці.

Мы - трошачкі нестандартная кампанія. Тут усе кажуць пра «Кубернетс», пра аблокі - у нас няма ні «Кубернетса», ні аблокаў. У нас затое ёсць стойкі з жалезам у мностве дата-цэнтраў, і на гэтым жалезе мы вымушаны жыць, мы вымушаны адказваць за гэта ўсё. Таму ў гэтым кантэксце будзем размаўляць. Такім чынам, пра праблемы. Першыя дзве вынеслі за дужкі.

Змена версіі ПЗ. Базісы

У нас распрацоўшчыкі не маюць доступу да прадакшна. Чаму так? А проста мы сертыфікаваны па PCI DSS, і ў нас распрацоўшчыкі проста не маюць права лазіць у «прод». Усё, кропка. Зусім. Таму адказнасць распрацоўкі заканчваецца роўна ў той момант, калі распрацоўка перадала білд на рэліз.

Другі наш базіс, які ў нас ёсць, які таксама нам моцна дапамагае - гэта адсутнічаюць унікальныя недакументаваныя веды. Я спадзяюся, у вас таксама. Таму што, калі гэта не так - у вас узнікнуць праблемы. Праблемы ўзнікнуць тады, калі гэтыя ўнікальныя недакументаваныя веды не будуць прысутнічаць у патрэбны час у патрэбным месцы. Дапушчальны, у вас адзін чалавек ведае як дэплоіць пэўны кампанент - чалавека няма, ён у адпачынку або захварэў - усё, у вас праблемы.

І трэці базіс, да якога мы дашлі. Мы прыйшлі да яго праз боль, кроў, слёзы - мы прыйшлі да таго, што любы наш білд змяшчае памылкі, нават калі ён без памылак. Мы для сябе так вырашылі: калі мы нешта дэплоім, калі мы нешта коцім у прод - у нас білд з памылкамі. Мы сфарміравалі патрабаванні, якім наша сістэма павінна задавальняць.

Патрабаванні да змены версіі ПЗ

Гэтых патрабаванняў тры:

• Мы павінны хутка адкаціць дэплой.
• Мы павінны мінімізаваць уплыў няўдалага дэплою.
• І мы павінны мець магчымасць хутка паралельна задэплоіравацца.
  Менавіта ў такім парадку! Чаму? Таму што, у першую чаргу, пры дэплоі новай версіі ўсё роўна хуткасць, але вам важна, калі нешта пайшло не так, хутка адкаціцца і аказаць мінімальны ўплыў. Але калі ў вас ёсць набор версій на прадакшне, для якіх высветлілася, што там змяшчаецца памылка (як снег на галаву, дэплою не было, але памылка змяшчаецца) - вам важная хуткасць дэплою наступнага. Што мы зрабілі, каб задаволіць гэтыя патрабаванні? Мы звярнуліся да такой метадалогіі:

  
  
  Яна досыць вядомая, мы не вынайшлі ні разу гэта Blue/Green deploy. Што гэта такое? У вас для кожнай групы сервераў, на якіх стаяць вашыя прыкладанні, вашы аплікацыі, павінна быць копія. Копія "цёплая": на ёй няма трафіку, але ў любы момант гэты трафік на гэтую копію можна пусціць. Гэтая копія змяшчае папярэднюю версію. І ў момант дэплою вы выкочваеце код на неактыўную копію. Потым пераключаеце частку трафіку (ці ўвесь) на новую вэрсію. Тым самым, для таго каб змяніць струмень трафіку са старой версіі на новую, вам трэба зрабіць толькі адно дзеянне: вам трэба ў апстрыме памяняць балансавальнік, памяняць кірунак – з аднаго апстрыму на іншы. Гэта вельмі зручна і вырашае праблему хуткага пераключэння, хуткага адкату.

  Тут жа вырашэнне другога пытання - мінімізацыя: вы можаце пусціць на новую лінію, на лінію з новым кодам толькі частка вашага трафіку (няхай, напрыклад, 2%). І гэтыя 2% - яны не 100%! Калі ў вас страцілася 100% трафіку пры няўдалым дэплоі - гэта страшна, калі ў вас страціла 2% трафіку - гэта непрыемна, але гэта не страшна. Мала таго, карыстачы нават, хутчэй за ўсё, гэтага не заўважаць, таму што ў некаторых выпадках (не ва ўсіх) адзін той жа карыстач, націснуўшы F5, ён трапіць на іншую, якая працуе версію.

  Blue/Green deploy. Роўтынг

  Пры гэтым не ўсё так проста "Блю/Грын дэплоеем"… Усе нашы кампаненты можна падзяліць на тры групы:

  • гэта фронтэнд (аплатныя старонкі, якія бачаць нашы кліенты);
  • ядро працэсінгу;
  • адаптар для працы з аплатнымі сістэмамі (банкі, «МайстарКард», «Візу»…).

  І тут ёсць нюанс - нюанс заключаецца ў роўтынгу паміж лініямі. Калі вы проста пераключаеце 100% трафіку, у вас гэтых праблем няма. Але калі вы хочаце пераключыць 2%, у вас пачынаюцца пытанні: "А як гэта зрабіць?" Самае простае, у ілоб: вы можаце па выпадковым выбары, Round Robin у nginx'е наладзіць, і ў вас 2% налева, 98% направа. Але гэта не заўсёды падыходзіць.

  У нас, напрыклад, карыстач узаемадзейнічае з сістэмай не адным запытам. Гэта нармальна: 2, 3, 4, 5 запытаў - у вас сістэмы могуць быць такія ж. І калі вам важна, каб усе запыты карыстальніка прыйшлі на тую ж самую лінію, на якую прыйшоў першы запыт, або (другі момант) усе запыты карыстальніка прыйшлі на новую лінію пасля пераключэння (працаваць ён мог пачаць раней з сістэмай, да пераключэння), – тады гэтае выпадковае размеркаванне вам не падыходзіць. Тады ёсць наступныя варыянты:

  
  
  Першы варыянт, самы просты - на аснове базавых параметраў кліента (IP Hash). У вас ёсць IP, і вы па айпішніку падзяляеце направа-налева. Тады ў вас спрацуе другі апісаны мною выпадак, калі адбыўся дэплой, карыстач ужо мог пачаць працаваць з вашай сістэмай, і з моманту дэплою ўсе запыты пайдуць на новую лінію (на тую ж самую, скажам).

  Калі гэта па нейкіх прычынах вам не падыходзіць і вам трэба абавязкова дасылаць запыты на тую лінію, куды прыйшоў першасны, інітны запыт карыстальніка, тады ў вас ёсць два варыянты…
  Першы варыянт: вы можаце ўзяць платны nginx+. Тамака ёсць механізм Sticky sessions, які пры першасным запыце карыстача выстаўляе карыстачу сесію і прывязвае яе да таго ці іншага апстрыму. Усе наступныя запыты карыстальніка ў рамках тэрміну жыцця сесіі адправяцца на той жа апстрым, куды была выстаўлена сесія.

  Нам гэта не падышло, таму што ў нас ужо быў nginx звычайны. Пераходзіць nginx+ - не тое каб гэта дорага, проста гэта было для нас некалькі балюча і не вельмі правільна. «Стыкі сешнс» для нас, напрыклад, не спрацавалі па тым простым чынніку, што «Стыкі сешнс» не даюць магчымасці раўціць па прыкмеце «Ці-або». Там можна задаць, што мы «Стыкі сешнс» робім, напрыклад, па айпішніку ці па айпішніку і па куках ці па постпараметры, а вось «Ці-або» - там ужо складаней.

  Таму мы дашлі да чацвёртага варыянту. Мы ўзялі nginx на "стэроідах" (гэта openresty) - гэта такі ж nginx, які дадаткова падтрымлівае ўключэнне ў сябе last-скрыптоў. Вы можаце напісаць last-скрыпт, падсунуць гэтаму «апенрэсці», і гэты ластскрыпт будзе выконвацца, калі прыйдзе запыт карыстальніка.

  І мы напісалі, уласна, такі скрыптык, паставілі сабе «апенрэсці» і ў гэтым скрыпце перабіраем 6 розных параметраў па канкатэнацыі «Або». У залежнасці ад наяўнасці таго ці іншага параметру, мы ведаем, што карыстач прыйшоў на адну старонку ці на іншую, на адну лінію ці на іншую.

  Blue/Green deploy. Добрыя якасці і недахопы

  Вядома, можна было, напэўна, зрабіць крыху прасцей (тыя ж «Стыкі сешнс» выкарыстоўваць), але ў нас ёсць яшчэ такі нюанс, што з намі не толькі карыстальнік узаемадзейнічае ў рамках аднаго працэсінгу адной транзакцыі… Але з намі ўзаемадзейнічаюць яшчэ плацежныя сістэмы: мы, пасля таго як працэсім транзакцыю (адправіўшы запыт у плацежную сістэму), атрымліваем кулбэк.
  І дапусцім, калі ўсярэдзіне нашага контуру мы можам пракінуць айпішнік карыстальніка ва ўсіх запытах і на аснове айпішніка карыстальнікаў падзяляць, то мы не скажам той жа «Візе»: «Чувакі, мы такая вось рэтра-кампанія, мы накшталт міжнародная (на сайце і ў Расіі)… А пракіньце нам, калі ласка, айпішнік карыстальніка дадаткова ў дадатковае поле, ваш пратакол стандартызаваны»! Зразумелая справа, яны не пагодзяцца.

  
  
  Таму для нас гэта не падышло - мы зрабілі openresty. Адпаведна, з роўтынгам у нас атрымалася вось так:

  У «Блю/Грын дэплою» ёсць, адпаведна, добрыя якасці, пра якія я сказаў, і недахопы.

  Недахопу два:

  • вам трэба затлумляцца з роўтынгам;
  • другі асноўны недахоп - гэта выдаткі.

  Вам трэба ў два разы больш сервераў, вам трэба ў два разы больш аперацыйных рэсурсаў, вам трэба марнаваць у два разы больш сіл на падтрыманне ўсяго гэтага заапарка.

  Дарэчы, сярод добрых якасцяў - яшчэ адна рэч, аб якой я да гэтага не згадаў: у вас ёсць рэзерв у выпадку росту нагрузкі. Калі ў вас выбухны рост нагрузкі, на вас паваліла вялікая колькасць карыстачоў, тыя вы проста ўключаеце другую лінію ў размеркаванне 50 на 50 - і ў вас адразу х2 сервераў у вашым кластары, пакуль вы не вырашыце праблему наяўнасці сервераў яшчэ.

  Як зрабіць хуткі дэплой?

  Мы пагаварылі, як вырашыць праблему мінімізацыі і хуткага адкату, але пытанне застаецца: "А як хутка дэплаіцца"?

  
  
  Тут коратка і ўсё проста.

  • У вас павінна быць CD-сістэма (Continuous Delivery) - без яе нікуды. Калі ў вас адзін сервер, вы можаце задэплоіравацца ручкамі. У нас сервераў прыкладна паўтары тысячы і ручкамі паўтары тысячы, зразумелая справа - мы можам пасадзіць аддзел памерам з гэтую залу, толькі каб дэплоіць.
  • Дэплой павінен быць раўналежным. Калі ў вас дэплой паслядоўны, тое ўсё дрэнна. Адзін сервер - нармальна, паўтары тысячы сервераў вы будзеце дэплоіць ўвесь дзень.
  • Ізноў жа, для паскарэння, гэта ўжо неабавязкова, мусіць. Пры десплоее звычайна выконваецца зборка праекту. Ёсць у вас вэб-праект, ёсць фронтэнд-частка (вы там робіце вэб-пак, npm збіраеце - нешта такое), і гэта гэты працэс у прынцыпе нядоўгі - хвілін 5, але гэтыя 5 хвілін могуць быць крытычнымі. Таму мы, напрыклад, так не робім: мы гэтыя 5 хвілін прыбралі, мы дэплоім артэфакты.

    Што такое артэфакт? Артэфакт - гэта сабраны білд, у якім ужо выканана ўся зборачная частка. Гэты артэфакт мы захоўваем у сховішчы артэфактаў. Такіх сховішчаў мы ў свой час выкарыстоўвалі два - гэта быў Nexus і цяпер jFrog Artifactory). «Нексус» мы першапачаткова выкарыстоўвалі таму, што пачалі гэты падыход практыкаваць у java-прыкладаннях (ён добра пад гэта падыходзіў). Потым туды ж засунулі частку прыкладанняў, якія напісаны PHP; і «Нексус» ужо не падыходзіў, і мы таму абралі jFrog Artefactory, які ўмее артыфактарыць практычна ўсё. Мы дашлі нават да таго, што ў гэтым сховішчы артэфактаў захоўваем уласныя бінарныя пакеты, якія мы для сервераў збіраем.

  Выбухны рост нагрузкі

  Пагаварылі аб змене версіі ПЗ. Наступнае, што ў нас ёсць - гэта выбухны рост нагрузкі. Тут я, мусіць, разумею пад выбухным ростам нагрузкі не зусім правільную рэч…

  Мы напісалі новую сістэму - яна сервисоориентированная, модная прыгожая, усюды воркеры, усюды чаргі, усюды асінхроннасць. І ў такіх сістэмах дадзеныя могуць ісці па розных flow. Для першай транзакцыі могуць быць задзейнічаны 1-й, 3-й, 10-ы воркер, для другой транзакцыі - 2-й, 4-й, 5-й. І сёння, дапусцім, з раніцы ў вас ідзе струмень дадзеных, які задзейнічае першыя тры воркера, а ўвечар рэзка змяняецца, і ўсё задзейнічае іншыя тры воркера.

  І тут атрымліваецца так, што вам трэба неяк маштабаваць воркеры, трэба неяк маштабаваць вашыя сэрвісы, але пры гэтым не дапусціць раздзіманні рэсурсаў.

  
  
  Мы вызначылі для сябе патрабаванні. Гэтыя патрабаванні досыць простыя: каб там быў Service discovery, параметрызацыя - усё стандартна для пабудовы такіх якія маштабуюцца сістэм, акрамя аднаго пункта - гэта амартызацыя рэсурсаў. Мы сказалі, што мы не гатовыя рэсурсы амартызаваць, каб серверы паветра грэлі. Мы ўзялі "Консул", мы ўзялі "Номад", які кіруе нашымі воркерамі.

  Чаму для нас гэта праблема? Давайце крыху назад адкачуся. За намі стаіць зараз у раёне 70 плацежных сістэм. З раніцы трафік ідзе праз "Ашчадбанк", потым "Ашчадбанк" упаў, напрыклад, і мы яго пераключаем на іншую плацежную сістэму. У нас працавала 100 воркераў да "Ашчадбанка", а пасля гэтага нам трэба рэзка падняць 100 воркераў для іншай плацежнай сістэмы. І гэта ўсё пажадана, каб адбывалася без чалавечага ўдзелу. Таму што, калі чалавечы ўдзел - там 24/7 павінен сядзець інжынер, які павінен толькі гэтым і займацца, таму што такія збоі, калі 70 сістэм за табой, адбываюцца рэгулярна.

  Таму мы паглядзелі на "Номад", у якога ёсць адкрыты IP і напісалі сваю штуку Scale-Nomad - ScaleNo, якая робіць прыкладна наступнае: яна сочыць за ростам чаргі і памяншае або павялічвае колькасць воркераў у залежнасці ад дынамікі змены чаргі. Калі зрабілі, мы падумалі: «Можа яе заапенсорсіць?» Потым на яе паглядзелі - яна простая, як дзве капейкі.

  Да гэтага часу мы яе апенсарсіць не сталі, але калі раптам у вас пасля дакладу, пасля ўсведамлення, што вам патрэбна такая штука, з'явіцца неабходнасць у ёй, у апошнім слайдзе ёсць мае кантакты - напішыце мне, калі ласка. Калі набярэцца хаця б 3-5 чалавек - мы яе заапенсарсім.

  
  
  Як гэта працуе? Давайце паглядзім! Забягаючы наперад: з левага боку ёсць кавалачак нашага маніторынгу: гэта адна лінія, зверху - час апрацоўкі падзей, у сярэдзіне - колькасць транзакцый, знізу - колькасць воркераў.

  Калі паглядзець, на гэтым малюнку ёсць збой. На верхнім графіку адзін з графікаў вылецеў за 45 секунд - адна з плацежных сістэм легла. Тут жа быў прыведзены трафік за 2 хвіліны і пайшоў рост чаргі на іншай плацежнай сістэме, дзе не было воркераў (мы не ўтылізавалі рэсурсы - наадварот, утылізавалі рэсурс карэктна). Мы не хацелі грэць - там была мінімальная колькасць, каля 5-10 воркераў, але яны не спраўляліся.

  На апошнім графіку бачны "горб", які як раз кажа аб тым, што "Скалена" падняў гэтую колькасць у два разы. І потым, калі графік крыху апусціўся, ён крыху паменшыў - колькасць воркераў было зменена ў аўтаматычным рэжыме. Вось так гэтая штука працуе. Пагаварылі аб пункце № 2 - "Як хутка пазбаўляцца ад прычын".

  Маніторынг. Як хутка выявіць праблему?

  Цяпер першы пункт - "Як хутка выявіць праблему?" Маніторынг! Мы мусім хутка разумець пэўныя рэчы. Якія рэчы мы мусім хутка разумець?

  
  
  Тры рэчы!

  • Мы мусім хутка разумець і хутка разумець працаздольнасць нашых уласных рэсурсаў.
  • Мы павінны хутка разумець выйсце са строю, маніторыць працаздольнасць сістэм, якія для нас з'яўляюцца знешнімі.
  • Трэці пункт - выяўленне лагічных памылак. Гэта калі сістэма працуе ў вас, па ўсіх паказчыках усё нормы, але адбываецца нешта не так.

  Тут я, напэўна, мала што раскажу такога крутога. Пабуду капітанам Відавочнасць. Мы шукалі, што ёсьць на рынку. У нас склаўся "вясёлы заапарк". Вось такі заапарк у нас зараз склаўся:

  
  
  У нас "Забікс" выкарыстоўваецца для маніторынгу "жалеза", для маніторынгу асноўных паказчыкаў сервераў. "Акметар" мы выкарыстоўваем для баз дадзеных. "Графану" і "Праметэй" мы выкарыстоўваем для ўсіх астатніх паказчыкаў, якія не падышлі пад першыя два, прычым частка - з "Графанай" і "Праметэем", частка - "Графана" з "Інфлюкс" і Telegraf.

  Год таму мы хацелі выкарыстоўваць New Relic. Класная штука, яна ўмее ўсё. Але наколькі яна ўсё ўмее, настолькі яна і дарагая. Калі мы выраслі да аб'ёму ў 1,5 тысячы сервераў, да нас прыйшоў вендар, сказаў: "Давайце заключаць дамову на наступны год". Мы паглядзелі на цану, што не, мы так рабіць не будзем. Цяпер мы ад "Нью-Рэліка" адмаўляемся, у нас каля 15 сервераў засталося пад маніторынгам "Нью-Рэліка". Кошт аказаўся зусім дзікім.

  І ёсць адзін інструмент, які мы рэалізавалі самі - гэта Debugger. Спачатку мы яго назвалі «Багер», але потым прайшоў у нас настаўнік ангельскай, дзіка засмяяўся, і пераназвалі на «Дэбагер». Што гэта такое? Гэта прылада, які па факце ў 15-30 секунд на кожным кампаненце, як "чорная скрыня" сістэмы, запускае тэсты на агульную працаздольнасць кампанента.

  Напрыклад, калі знешняя старонка (плацежная старонка) - ён проста яе адкрывае і глядзіць, як яна павінна выглядаць. Калі гэта працэсінг, ён куляе тэставую "транзаку" - глядзіць, каб гэтая "транзака" дайшла. Калі гэта сувязь з аплатнымі сістэмамі - мы адпаведна куляем тэставы запыт, дзе можам, і глядзім, што ў нас усё добра.

  Якія паказчыкі важныя для маніторынгу?

  Што мы маніторым у асноўным? Якія паказчыкі для нас важныя?

  
  

  • Response time / RPS на франтах - вельмі важны паказчык. Ён адразу адказвае, што ў вас нешта ня так.
  • Колькасць апрацаваных паведамленняў ва ўсіх чэргах.
  • Колькасць воркераў.
  • Асноўныя метрыкі карэктнасці.

  Апошні пункт - "бізнэсавы", "бізнэсавая" метрыка. Калі вы хочаце тое ж самае маніторыць, вам трэба вызначыць адну-дзве метрыкі, якія для вас з'яўляюцца асноўнымі паказчыкамі. У нас такая метрыка - гэта праходнасць (гэта стаўленне колькасці паспяховых транзакцый да агульнай плыні транзакцый). Калі ў ёй нешта мяняецца на інтэрвале 5-10-15 хвілін - значыць, у нас ёсць праблемы (калі кардынальна мяняецца).

  Як гэта ў нас выглядае - прыклад аднаго з нашых бордаў:

  
  
  З левага боку - 6 графікаў, гэта адпаведна па лініях - колькасць воркераў і колькасць паведамленняў у чэргах. З правага боку - RPS, RTS. Знізу - тая самая метрыка "бізнэсавая". І на «бізнэсавай» метрыцы ў нас адразу бачна, што нешта пайшло не так на двух сярэдніх графіках… Гэта якраз упала чарговая сістэма, якая стаіць за намі.

  Другое, што нам трэба было зрабіць - гэта сачыць за падзеннем знешніх плацежных сістэм. Тут мы ўзялі OpenTracing - механізм, стандарт, парадыгма, якая дазваляе трасаваць размеркаваныя сістэмы; і яго крыху змянілі. Стандартная OpenTracing-парадыгма гаворыць аб тым, што мы будуем трасіроўку кожнага асобнага запыту. Нам гэта было не трэба, і мы гэта загарнулі ў трасіроўку сумарную, агрэгацыйную. Зрабілі інструмент, які нам дазваляе адсочваць хуткасць сістэм, якія стаяць за намі.

  
  
  Графік паказвае нам, што адна з плацежных сістэм стала адказваць за 3 секунды - у нас з'явіліся праблемы. Пры гэтым гэтая штука зрэагуе, калі праблемы пачаліся, на інтэрвале 20-30 секунд.

  І трэці клас памылак маніторынгу, якія ёсць - гэта маніторынг лагічны.

  Шчыра кажучы, не ведаў, што на гэтым слайдзе намаляваць, бо мы шукалі доўга на рынку тое, што нам падыдзе. Нічога не знайшлі, таму прыйшлося рабіць самім.

  
  
  Што я маю на ўвазе пад маніторынгам лагічным? Ну, уявіце сабе: вы робіце сабе сістэму (напрыклад, клон "Тындэра"); вы яе зрабілі, запусцілі. Паспяховы менеджэр Вася Пупкін паставіў яе сабе на тэлефон, бачыць там дзяўчыну, лайкае яе… а лайк сыходзіць не дзяўчыне - лайк сыходзіць ахоўніку Міхалычу з гэтага ж бізнэс-цэнтра. Мэнэджар спускаецца ўніз, а потым здзіўляецца: «А чаму гэты ахоўнік Міхалыч яму так прыемна ўсміхаецца»?

  У такіх сітуацыях… Для нас гэтая сітуацыя гучыць крыху па-рознаму, таму што (я пісаў) гэта такая рэпутацыйная страта, якая ўскосна вядзе да страт фінансавых. У нас сітуацыя зваротная: мы прамыя фінансавыя страты можа панесці - напрыклад, калі мы правялі транзакцыю як паспяховую, а яна была няўдалай (ці наадварот). Прыйшлося напісаць уласны інструмент, які адсочвае па бізнес-паказчыках колькасць паспяховых транзакцый у дынаміцы на часовым інтэрвале. Не знайшлі нічога на рынку! Я менавіта гэтую думку хацеў данесці. Для вырашэння такога кшталту задач на рынку нічога няма.

  Гэта было да пытання аб тым, як хутка выявіць праблему.

  Як вызначыць прычыны дэплою

  Трэцяя група задач, якія мы вырашаем - гэта пасля таго, як мы праблему выявілі, пасля таго, як мы яе пазбавіліся, добра было б зразумець прычыну для распрацоўкі, для тэставання і нешта з гэтым зрабіць. Адпаведна, нам трэба даследаваць, трэба падняць логі.

  
  
  Калі мы гаворым пра логі (асноўная прычына - логі), асноўная частка логаў у нас у ELK Stack - практычна ва ўсіх так. У кагосьці, можам, не ў ELK, але калі вы пішыце логі гігабайтамі, то рана ці позна прыйдзеце да ELK. Мы пішам іх тэрабайтамі.

  
  
  Тут ёсьць праблема. Мы пафіксілі, выправілі для карыстальніка памылку, пачалі раскопваць, што ж там было такое, залезлі ў «Кібану», увялі там id-шнік транзакцыі і атрымалі вось такую ​​анучу (паказвае шмат). І ў гэтай парцянцы незразумела нічога роўным лікам. Чаму? Ды таму што незразумела, якая частка ставіцца да якога воркера, якая частка ставіцца да якога кампанента. І ў гэты момант мы зразумелі, што нам патрэбная трасіроўка – тая самая OpenTracing, пра якую я казаў.

  Падумалі мы гэта год таму, звярнулі свой погляд у бок рынку, і там аказалася два інструменты – гэта "Зіпкін" (Zipkin) і "Егер" (Jaeger). «Егер» - гэта па факце такі ідэалагічны спадчыннік, ідэалагічны прадаўжальнік «Зіпкіна». У "Зіпкіне" ўсё добра, акрамя таго, што ён не ўмее агрэгаваць, не ўмее ўключаць у трасіроўку логі, толькі трасіроўку часу. А "Егер" гэта падтрымліваў.

  Паглядзелі на «Егера»: можна інструментаваць прыкладанні, можна пісаць у Api (стандарт Api для PHP на той момант, праўда, не быў зацверджаны - гэта год таму, а цяпер ужо зацверджаны), аб абсалютна не было кліента. "Окей", – падумалі мы, і напісалі ўласны кліент. Што ў нас атрымалася? Вось прыкладна так гэта выглядае:

  
  
  У "Егеры" на кожнае паведамленне ствараюцца span'ы. Гэта значыць, калі карыстальнік адкрывае сістэму, ён бачыць адзін ці два блокі на кожны ўваходны запыт (1-2-3 – колькі ўваходзяць запытаў ад карыстальніка было, столькі і блокаў). Для таго каб карыстачам было лягчэй, да логаў і часавай трасіроўцы мы дадалі тэгі. Адпаведна, у выпадку памылкі наша дадатак прамаркіруе лог адпаведным тэгам Error. Можна адфільтраваць па тэгу Error і вывядуцца толькі спаны, якія змяшчаюць гэты блок з памылкай. Вось як гэта выглядае, калі мы разгорнем span:

  
  
  Унутры спану ёсць набор трэйсаў. У дадзеным выпадку гэта тры тэставыя трэйсы, і трэці трэйс кажа нам пра тое, што адбылася памылка. Пры гэтым тут жа мы бачым часовую трасіроўку: у нас зверху - часовая шкала, і мы бачым, на якім часовым інтэрвале ў нас той ці іншы лог быў запісаны.

  Адпаведна, у нас зайшло выдатна. Мы напісалі ўласнае пашырэнне, і мы яго заапенсорсілі. Калі вы захочаце працаваць з трасіроўкай, калі вы захочаце працаваць з «Егерам» на мове PHP - ёсць наша пашырэнне, welcome to use, як гаворыцца:

  
  
  У нас гэтае пашырэнне - гэта кліент для працы OpenTracing Api, зроблена як php-extention, гэта значыць вам яго трэба будзе сабраць і падкласці сістэму. Год таму не было нічога іншага. Цяпер з'явіліся яшчэ іншыя кліенты, якія як кампаненты. Тут справа ваша: альбо вы кампозерам выпампоўваеце кампаненты, альбо вы карыстаецеся extention up to you.

  Карпаратыўныя стандарты

  Пра тры запаведзі пагаварылі. Чацвёртая запаведзь - гэта стандартаваць падыходы. Пра што гэта? Гэта прыкладна пра гэта:

  
  
  Чаму тут слова "карпаратыўныя"? Не таму што мы вялікая ці бюракратычная кампанія, не! Слова "карпаратыўная" я тут жадаў ужыць у кантэксце таго, што ў кожнай кампаніі, у кожнага прадукта гэтыя стандарты павінны быць свае, і ў вас у тым ліку. Якія стандарты ёсць у нас?

  
  

  • У нас ёсць рэгламент дэплоеяў. Мы без яго нікуды не рухаемся, не можам. Дэплоім мы парадку 60 раз у тыдзень, гэта значыць у нас дэплоі адбываюцца практычна пастаянна. Пры гэтым у нас ёсць, напрыклад, у рэгламенце дэплоеяў табу на дэплоі ў пятніцу - прынцыпе, мы не дэплоім.
  • У нас абавязковая дакумэнтацыя. Ніводны новы кампанент у нас не пападае ў прод, калі на яго няма дакументацыі, нават калі гэта народжана пад пяром нашых RnD-шнікаў. Мы патрабуем ад іх інструкцыю па дэплоі, карту маніторынгу і прыкладнае апісанне (ну, як праграмісты могуць напісаць) таго, як гэты кампанент працуе, як яго блукаць.
  • Мы вырашаем не прычыну праблемы, а праблему - тое, пра што я ўжо казаў. Для нас важна засцерагчы карыстальніка ад праблем.
  • У нас ёсць допускі. Напрыклад, мы не лічым даунтаймам, калі мы на працягу двух хвілін страцілі 2% трафіку. Гэта ў прынцыпе не пападае ў нашу статыстыку. Калі больш у працэнтных суадносінах або часовых, мы ўжо лічым.
  • І мы заўсёды пішам постмартэмы. Каб у нас ні здарылася, любая сітуацыя, калі павяла сябе не штатна на прадакшне, яна будзе адлюстравана ў патсмартэме. Постмартэм - гэта дакумент, у якім вы пішыце, што ў вас адбылося, падрабязны таймінг, што вы зрабілі для выпраўлення і (гэта абавязковы блок!) што вы зробіце, каб такога не дапусціць у будучыні. Гэта абавязкова неабходна для наступнага аналізу.

  Што лічыць даунтаймам?

  
  
  Да чаго гэта ўсё прывяло?

  Гэта прывяло да таго, што (у нас былі пэўныя праблемы са стабільнасцю, гэта не задавальняла ні кліентаў, ні нас) за апошнія 6 месяцаў наш паказчык стабільнасці склаў 99,97. Можна сказаць, што гэта ня вельмі шмат. Так, нам ёсць да чаго імкнуцца. З гэтага паказчыка прыкладна палова - гэта стабільнасць як бы не наша, а нашага web application firewall, які перад намі стаіць і выкарыстоўваецца як сэрвіс, але кліентам на гэта ўсё роўна.

  Мы навучыліся спаць па начах. Нарэшце! Паўгода таму мы не ўмелі. І на гэтай ноце з вынікамі мне хочацца зрабіць адну рэмарачку. Учора ўвечар быў цудоўны даклад пра сістэму кіравання ядзерным рэактарам. Калі мяне чуюць людзі, якія пісалі гэтую сістэму - калі ласка, забудзьцеся аб тым, што я казаў пра "2% - гэта не даунтайм". Для вас 2% — гэта даунтайм, нават калі на дзве хвіліны!

  На гэта ўсё! Вашыя пытанні.

  
  

  Аб балансавальнікаў і міграцыі з базы дадзеных

  Пытанне з аўдыторыі (далей - У): - Добры вечар. Дзякуй вялікі за такі адмінскі даклад! Пытанне кароценькае, на тэму вашых балансавальнікаў. Вы абмовіліся, што ў вас ёсць WAF, гэта значыць, як я разумею ў якасці балансавальніка вы карыстаецеся нейкі знешні…

  ЕК: - Не, у якасці балансавальніка мы выкарыстоўваем свае сэрвісы. У дадзеным выпадку WAF з'яўляецца для нас выключна прыладай абароны ад DDoS.

  У: - А можна пару слоў аб балансавальнікі?

  ЕК: – Як я ўжо сказаў, гэта група сервераў у openresty. Іх у нас зараз 5 груп рэзерваваных, якія адказваюць выключна… гэта значыць сервер, на якім стаіць выключна openresty, ён толькі праксіруе трафік. Адпаведна, для разумення, колькі мы трымаем: у нас зараз штатны паток трафіку - гэта некалькі сотняў мегабіт. Яны спраўляюцца, ім добра, нават не напружваюцца.

  У: - Таксама простае пытанне. Вось ёсць Blue/Green deployment. А што вы робіце, напрыклад, з міграцыямі з базы даных?

  ЕК: - Добрае пытанне! Глядзіце, мы ў Blue/Green deployment'а ў нас ёсць асобныя чэргі на кожную лінію. Гэта значыць, калі мы гаворым аб чэргах падзей, якія перадаюцца ад воркера да воркера, там асобныя чэргі на blue-лінію і на green-лінію. Калі мы гаворым аб самой базе дадзеных, то мы знарок яе звузілі, як маглі, пераклалі ўсё практычна ў чарзе, у базе дадзеных у нас толькі стэк транзакцый захоўваецца. І стэк транзакцый у нас адзіны для ўсіх ліній. З базай дадзеных у дадзеным кантэксце: мы яе на blue і green не падзяляем, таму што абодва варыянты кода павінны ведаць, што адбываецца з транзакцыяй.

  Сябры, у мяне ёсць яшчэ такі маленькі прыз, каб вас падштурхнуць - кніжка. І мне яе трэба ўручыць за самае лепшае пытанне.

  У: - Добры дзень. Дзякуй за даклад. Пытанне такое. Вы маніторыце плацяжы, вы маніторыце сэрвісы, з якімі вы маеце зносіны… Але як вы маніторыце так, што чалавек нейкім чынам прыйшоў на вашу плацежную старонку, выканаў аплату, а праект яму залічыў грошы? Гэта значыць, як вы маніторыце тое, што marchant даступны і прыняў ваш callback?

  ЕК: – «Мерчант» для нас у дадзеным выпадку з'яўляецца сапраўды такім жа вонкавым сэрвісам, як і плацежная сістэма. Мы маніторым хуткасць адказу "мерчанта".

  Аб шыфраванні базы дадзеных

  У: - Добры дзень. У мяне крыху побач пытанне. У вас адчувальныя дадзеныя па PCI DSS. Жадаў пазнаць, як вы ў чэргах захоўваеце PAN'ы, у якія вам неабходна пракідваць? Ці выкарыстоўваеце якое шыфраванне? І адгэтуль якое вынікае другое пытанне: па PCI DSS неабходна перыядычна перашыфроўваць базу ў выпадку змен (звальненне адмінаў і гэтак далей) – як у гэтым выпадку адбываецца з даступнасцю?

  
  
  ЕК: - Выдатнае пытанне! Па-першае, мы ў чэргах не захоўваем PAN'ы. Мы не маем права захоўваць PAN дзе-небудзь у адкрытым выглядзе, у прынцыпе, таму мы выкарыстоўваем спецыяльны сэрвіс (мы яго называем «Кейдэмон») - гэта сэрвіс, які робіць толькі адно: ён прымае на ўваход паведамленне і аддае паведамленне зашыфраванае. І мы гэтым зашыфраваным паведамленнем усё і захоўваем. Адпаведна, даўжыня ключа ў нас пад кілабайт, каб гэта было прамы сур'ёзна і надзейна.

  У: - Цяпер ужо 2 кілабайта трэба?

  ЕК: – Накшталт яшчэ ўчора было 256… Ну куды яшчэ?!

  Адпаведна, гэта першае. А па-другое, рашэнне, якое ёсць, яно падтрымлівае працэдуру перашыфроўкі - там дзве пары "кекаў" (ключоў), якія даюць "дэкі", якія зашыфроўваюць (key - гэта ключы, dek - гэта вытворныя ад ключоў, якія зашыфроўваюць). І ў выпадку ініцыяцыі працэдуры (праходзіць рэгулярна, ад 3 месяцаў да ± нейкіх) мы загружаем новую пару "кекаў", і ў нас адбываецца перашыфроўка дадзеных. У нас ёсць асобныя сэрвісы, якія ўсе дадзеныя выдзіраюць, шыфруюць па-новаму; у дадзеных побач захоўваецца ідэнтыфікатар ключа, якім яны зашыфраваны. Адпаведна, як толькі мы дадзеныя шыфраваны новымі ключамі, мы старыя ключ выдаляем.

  Часам плацяжы трэба праводзіць уручную…

  У: - Гэта значыць, калі прыйшоў вяртанне па нейкай аперацыі, то расшыфруеце пакуль старым ключом?

  ЕК: - Так.

  У: - Тады яшчэ адно маленькае пытанне. Калі адбываецца нейкі збой, падзенне, інцыдэнт, то неабходна праціснуць транзакцыю ў ручным рэжыме. Бывае такая сытуацыя.

  ЕК: - Так, бывае.

  У: - Адкуль вы бераце гэтыя дадзеныя? Ці вы самі ходзіце ручкамі ў гэтае сховішча?

  ЕК: - Не, ну зразумелая справа - у нас ёсць нейкая бэк-офіс-сістэма, якая змяшчае інтэрфейс для нашага саппорта. Калі мы не ведаем, у якім статусе транзакцыя (напрыклад, пакуль плацежная сістэма таймаўтам не адказала) - мы апрыёры не ведаем, гэта значыць мы фінальны статус прысвойваем толькі пры поўнай упэўненасці. У гэтым выпадку мы транзакцыю звальваем у спецыяльны статус на ручную апрацоўку. З раніцы, на наступны дзень, як толькі сапарт атрымлівае інфармацыю, што ў плацёжнай сістэме засталіся вось такія транзакцыі, яны ўручную іх апрацоўваюць у гэтым інтэрфейсе.

  
  
  У: - У мяне пара пытанняў. Адзін з іх - працяг зоны PCI DSS: як вы выносіце логі іх контуру? Такое пытанне таму, што распрацоўшчык у логі мог пакласці што заўгодна! Другое пытанне: як вы выкочваеце хотфіксы? Ручкамі ў базе - гэта адзін варыянт, але могуць быць free hot-fix'ы - якая там працэдура? І трэцяе пытанне, мусіць, злучаны з RTO, RPO. У вас даступнасць была 99,97, амаль чатыры дзявяткі, але я так разумею, што ў вас і другі дата-цэнтр, і трэці дата-цэнтр, і пяты дата-цэнтр… Як вы займаецеся іх сінхранізацыяй, рэплікацыяй, усім астатнім?

  ЕК: - Давайце пачнем з першага. Першае пытанне пра лагі было? У нас, калі пішуцца логі, стаіць праслойка, якая ўсе сенсітыўныя дадзеныя маскіруе. Яна па масцы глядзіць і па дадатковых палях. Адпаведна, у нас логі выходзяць з ужо замаскіраванымі дадзенымі і контурам PCI DSS. Гэта адна з рэгулярных задач, якая ставіцца ў віну аддзелу тэставання. Яны абавязаны кожную задачу правяраць у тым ліку на тыя логі, якія яны пішуць, і гэта - адна з рэгулярных задач пры код-рэўю, для таго каб кантраляваць, што распрацоўшчык нешта не запісаў. Наступная праверка гэтага ажыццяўляецца рэгулярна аддзелам інфармацыйнай бяспекі прыкладна раз у тыдзень: выбарачна бяруцца логі за апошні дзень, і яны праганяюцца праз спецыяльны сканер-аналізатар з тэставых сервераў, каб правяраць гэта ўсё.
  Пра hot-fix'ы. Гэта ўключана ў нас у рэгламент дэплояў. У нас асобна вынесены пункт пра хотфіксы. Мы лічым, што мы хотфіксы дэплоім кругласутачна тады, калі нам гэта трэба. Як толькі версія сабрана, як толькі яна прагнаная, як толькі ў нас ёсць артэфакт - у нас паднімаецца дзяжурны сістэмны адміністратар па званку з саппорта, і ён дэплоіты гэта ў той момант, калі гэта неабходна.

  Пра "чатыры дзявяткі". Тая лічба, якая ў нас зараз ёсць, па-сапраўднаму яна была дасягнута, і мы да яе імкнуліся яшчэ на адным дата-цэнтры. Цяпер у нас з'явіўся другі дата-цэнтр, і мы пачынаем роўціць паміж імі, і пытанне кроса дата-цэнтр рэплікацыі - гэта сапраўды пытанне нетрывіяльнае. Мы спрабавалі вырашыць яго ў свой час рознымі сродкамі: спрабавалі выкарыстоўваць той жа “Тарантул” – у нас не зайшло, адразу кажу. Таму мы прыйшлі да таго, што які робіцца замова «сэнсу» уручную. У нас кожнае прыкладанне па факце ў асінхронным рэжыме неабходнай сінхранізацыі "change - done" ганяе паміж дата-цэнтрамі.

  У: - Калі ў вас з'явіўся другі, то чаму не з'явіўся трэці? Бо Split-brain яшчэ ніхто…

  ЕК: – А ў нас няма «Спліт-брэйну». З-за таго, што кожны дадатак у нас ганяе мультымайстар, нам не важна, у які цэнтр прыйшоў запыт. Мы гатовы да таго, што, у выпадку, калі ў нас адзін дата-цэнтр упаў (мы на гэта закладваемся) і ў сярэдзіне запыту карыстальніка пераключыў на другі дата-цэнтр, мы гатовы страціць гэтага карыстальніка, сапраўды; але гэта адзінкі будуць, абсалютныя адзінкі.

  У: - Добры вечар. Дзякуй за даклад. Вы расказвалі пра свой дэбагер, які ў прадакшне ганяе нейкія тэставыя транзакцыі. А вось раскажыце пра тэставыя транзакцыі! Як глыбока яно сыходзіць?

  ЕК: - Яно праходзіць поўны цыкл усяго кампанента. Для кампанента няма адрозненняў паміж тэставай транзакцыяй і баявой. А з пункта гледжання логікі гэта проста нейкі асобны праект у сістэме, на якім толькі тэставыя транзакцыі ганяюцца.

  У: – А дзе вы яе адсякаеце? Вось Core адправіў…

  ЕК: – Мы за “Каром” у дадзеным выпадку для тэставых транзакцый… У нас ёсць такое паняцце, як роўтынг: “Кор” ведае ў якую плацежную сістэму трэба адправіць – мы адпраўляем у фэйкавую плацежную сістэму, якая проста http-адбіўку дае і ўсё.

  У: - Скажыце, калі ласка, а ў вас прыкладанне напісана адным велізарным маналітам, ці вы рэзалі яго на нейкія сэрвісы ці нават мікрасэрвісы?

  ЕК: - У нас не маналіт, вядома, у нас сэрвіс-арыентаванае прыкладанне. У нас жарт, што ў нас сэрвіс з маналітаў – яны сапраўды дастаткова вялікія. Мікрасэрвісамі назваць гэтую мову не паварочваецца ад слова зусім, але гэта менавіта сэрвісы, усярэдзіне якіх працуюць воркеры размеркаваных машын.

  Калі сэрвіс на серверы скампраметаваны…

  У: - Тады ў мяне наступнае пытанне. Нават калі б гэта быў маналіт, вы ўсё роўна сказалі, што ў вас ёсць шмат гэтых instant-сервераў, усе яны ў прынцыпе апрацоўваюць дадзеныя, і пытанне такое: «У выпадку кампраметацыі аднаго з instant-сервераў альбо прыкладанні, якога-небудзь асобнага звяна , у іх ёсць нейкі кантроль доступу? Хто з іх што можа рабіць? Да каго звяртацца, за якімі дадзенымі?

  
  
  ЕК: - Так, несумненна. Патрабаванні бяспекі дастаткова сур'ёзныя. Па-першае, у нас адкрытыя рухі дадзеных, і парты толькі тыя, па якіх мы загадзя мяркуем рух трафіку. Калі кампанент мае зносіны з базай дадзеных (скажам, з "Муськулем") па 5-4-3-2, яму будуць адкрыты толькі 5-4-3-2, і іншыя парты, іншыя напрамкі руху трафіку не будуць даступныя. Акрамя гэтага трэба разумець, што ў нас у прадакшні існуе каля 10 розных контураў бяспекі. І нават калі скампраметавана было прыкладанне нейкім чынам, крый божа, то зламыснік не зможа атрымаць доступ да кансолі кіравання серверам, таму што гэта іншая сеткавая зона бяспекі.

  У: – А мне ў дадзеным кантэксце больш цікавы момант, што ў вас жа ёсць нейкія кантракты з сэрвісамі – што яны могуць рабіць, праз якія "экшны" яны могуць звяртацца адзін да аднаго… І ў нармальным flow нейкія пэўныя сэрвісы запытваюць нейкі шэраг, пералік «экшнаў» на іншым. Да іншых яны як бы не звяртаюцца ў нармальнай сітуацыі і іншыя зоны адказнасці ў іх. Калі ж адзін з іх будзе кампраметаваны, ці зможа ён тузануць "экшны" таго сэрвісу?

  ЕК: - Я разумею. Калі ў нармальнай сітуацыі з іншым серверам камунікацыя наогул была дазволена, то - так. Па SLA-кантракту мы не маніторым, што табе дазволеныя толькі першыя 3 "экшна", а 4 "экшна" табе не дазволеныя. Гэта, мусіць, для нас залішне, таму што ў нас дык вось 4-узроўневая сістэма абароны ў прынцыпе для контураў. Мы аддаем перавагу абараняцца контурамі, а не на ўзроўні вантроб.

  Як працуюць Visa, MasterCard і "Ашчадбанк"

  У: – Я хачу ўдакладніць момант наконт пераключэння карыстальніка з аднаго дата-цэнтра на іншы. Наколькі я ведаю, «Віза» і «МайстарКард» працуюць па бінарным сінхронным пратаколе 8583, там стаяць міксы. І хацеў даведацца, зараз маецца на ўвазе пераключэнне - гэта непасрэдна «Віза» і «МайстарКард» ці да плацежных сістэм, да працэсінгаў?

  ЕК: - Гэта да міксаў. Міксы ў нас стаяць у адным дата-цэнтры.

  У: - Грубіянска кажучы, у вас адна кропка падлучэння?

  ЕК: – “Візе” і “МайстарКарду” – так. Проста таму, што «Віза» і «МайстарКард» патрабуюць дастаткова сур'ёзных укладанняў у інфраструктуру для заключэння для заключэння асобных кантрактаў для атрымання другой пары міксаў, напрыклад. Яны рэзерваваныя ў рамках аднаго дата-цэнтра, але калі ў нас, крый божа, здохне дата-цэнтр, дзе стаяць міксы для падлучэння да «Візы» і «МайстарКардаў», то сувязь з «Візай» і «МайстарКардаў» у нас будзе страчана…

  У: - Як яны могуць быць рэзерваваныя? Я ведаю, што «Віза» дазваляе толькі адзін канэкт трымаць у прынцыпе!

  ЕК: - Яны самі пастаўляюць абсталяванне. Ва ўсякім разе, нам прыйшло абсталяванне, якое ўсярэдзіне жалезна рэзервавана.

  У: - Гэта значыць стойка ад іх Connects Orange?..

  ЕК: - Так.

  У: - А вось як у гэтым выпадку: калі ў вас дата-цэнтр знікае, як далей выкарыстоўваць? Ці проста трафік спыняецца?

  ЕК: - Не. Мы ў гэтым выпадку проста пераключым трафік на іншы канал, які, натуральна, будзе даражэйшым за нас, даражэйшым кліентам. Але трафік пойдзе не праз нашае прамое падлучэнне да «Візы», «МайстарКарду», а праз умоўны «Ашчадбанк» (вельмі ўвыдатнена).

  Я дзіка прашу прабачэння, калі я закрануў супрацоўнікаў «Ашчадбанка». Але па нашай статыстыцы з расійскіх банкаў "Ашчадбанк" падае часцей за ўсё. Не праходзіць месяца, каб у "Ашчадбанка" што-небудзь не адвалілася.

  
  
  

  Крыху рэкламы 🙂

  Дзякуй, што застаяцеся з намі. Вам падабаюцца нашыя артыкулы? Жадаеце бачыць больш цікавых матэрыялаў? Падтрымайце нас, аформіўшы замову ці парэкамендаваўшы знаёмым, хмарныя VPS для распрацоўшчыкаў ад $4.99, унікальны аналаг entry-level сервераў, які быў прыдуманы намі для Вас: Уся праўда аб VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps ад $19 ці як правільна дзяліць сервер? (даступныя варыянты з RAID1 і RAID10, да 24 ядраў і да 40GB DDR4).

  Dell R730xd у 2 разы танней у дата-цэнтры Equinix Tier IV у Амстэрдаме? Толькі ў нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТБ ад $199 у Нідэрландах! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – ад $99! Чытайце аб тым Як пабудаваць інфраструктуру корп. класа c ужываннем сервераў Dell R730xd Е5-2650 v4 коштам 9000 еўра за капейкі?

Крыніца: habr.com