HighLoad++, Евгений Кузовлев (EcommPay IT): какво да правим, когато минута престой струва $100000

Всички говорят за процесите на разработка и тестване, обучаване на персонала, повишаване на мотивацията, но тези процеси са недостатъчни, когато всяка минута престой на услугата струва космически суми. Какво да правите, когато извършвате финансови транзакции при строги 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. Ние отстраняваме проблема, а не го решаваме. Да решим е второстепенно. За нас е основно това, че потребителят е защитен от този проблем. Той ще съществува в някаква изолирана среда, но тази среда няма да контактува с него. Всъщност, ще преминем през тези четири групи проблеми (по някои по-подробно, по някои по-малко подробно), и ще разкажа какво използваме, какъв е нашият опит в решенията.

Отстраняване на проблеми: когато се случват и какво да правим с тях?

Но нека да започнем не с реда, а от точка № 2 – как бързо да се отървем от проблема? Имаме проблем – трябва да го решим. „Какво да правим с това?“ – основният въпрос. И когато започнахме да мислим как да разрешим проблема, ние формулирахме някои изисквания, които решаването на проблемите трябва да следва.

За да формулираме тези изисквания, решихме да си зададем въпроса: „Кога ни се случват проблеми?“ И проблемите, както се оказа, възникват в четири случая:

• Апаратурана неизправност.
• Проблеми с външни услуги.
• Промяна на версията на софтуера (този толкова споменаван деплой).
• Внезапно увеличение на натоварването.

За първите две няма да говорим. Апаратурана неизправност се решава доста лесно: всичко трябва да бъде дублирано. Ако става въпрос за дискове – дисковете трябва да бъдат в RAID, ако е сървър – сървърът трябва да бъде дублиран, ако имате мрежова инфраструктура – трябва да поставите второ копие на мрежовата инфраструктура, тоест просто я дублирате. И ако нещо откаже, преминавате на резервните мощности. Тук е трудно да се каже още нещо.

Второто – това е проблем с външни услуги. За повечето системи това всъщност не е проблем, но не и за нас. Тъй като обработваме плащания, ние сме агрегатор, който стои между потребителя (който въвежда данните на картата си) и банките, платежните системи („Виза“, „МастърКард“, „Мира“ и т.н.). На нашите външни услуги (платежни системи, банки) понякога се случват проблеми. Нито ние, нито вие (ако имате такива услуги) можем да повлияем на това.

Какво да правим тогава? Има два варианта. Първо, ако е възможно, трябва да дублирате тази услуга по някакъв начин. Например, ние, ако можем, пренасочваме трафика от една услуга на друга: например, обработвахме карти през „Сбербанк“, ако „Сбербанк“ има проблеми – пренасочваме трафика [условно] към „Райфайзен“. Второто, което можем да направим – е много бързо да забележим сбоя на външните услуги, затова ще говорим за скоростта на реакция в следващата част на доклада.

Всъщност от тези четири можем конкретно да повлияем на смяната на версиите на софтуера – да предприемем действия, които ще подобрят ситуацията в контекста на деплоймънтите и в контекста на експлозивния ръст на натоварването. Всъщност, ние го направихме. Тук, отново, малка забележка…

От тези четири проблема, някои от тях се решават веднага, ако имате облак. Ако сте в облаците на „Майкрософт Ажур“, „Озон“, използвате нашите облаци от „Яндекс“ или „Мейл“, то поне хардуерната неизправност става тяхна работа и при вас веднага всичко е наред в контекста на хардуерната неизправност.

Ние сме малко нестандартна компания. Тук всички говорят за „Кубернетс“, за облаци – ние нямаме нито „Кубернетс“, нито облаци. Затова имаме сървъри с хардуер в множество дата-центрове, и на този хардуер сме принудени да живеем, принудени сме да отговаряме за всичко това. Затова в този контекст ще говорим. И така, за проблемите. Първите две оставяме настрана.

Смяна на версията на софтуера. Основи

При нас разработчиците нямат достъп до производствения процес. Защо е така? Просто ние сме сертифицирани по PCI DSS и разработчиците просто нямат право да се намесват в „прод“. И това е точка. Напълно. Затова отговорността на разработката приключва точно в момента, в който разработката предаде билд на релийз.

Вторият наш основен принцип, който също ни помага много – е отсъствието на уникални недокументирани знания. Надявам се, че и при вас е така. Защото, ако не е – ще срещнете проблеми. Проблеми ще възникнат, когато тези уникални недокументирани знания не са налични в нужния момент на нужната място. Например, ако един човек знае как да деплойва конкретен компонент – този човек не е на разположение, в отпуск или е болен – всичко, имате проблеми.

И третият принцип, до който стигнахме. Стигнахме до него през болка, кръв, сълзи – стигнахме до това, че всеки наш билд съдържа грешки, дори и да е без грешки. Ние решихме: когато деплойваме нещо, когато пускаме нещо в продукция – нашият билд съдържа грешки. Формулирахме изисквания, на които нашата система трябва да отговаря.

Изисквания за смяна на версията на софтуера

Тези изисквания са три:

• Трябва бързо да отменим деплой.
• Трябва да минимизираме влиянието на неуспешния деплой.
• И ние трябва да можем бързо да направим паралелен деплой.
  С точно такъв ред! Защо? Защото, на първо място, при деплоя на нова версия скоростта не е най-важното, но е важно, ако нещо се обърка, да можем бързо да се върнем и да окажем минимално влияние. Но ако имате набор от версии в продукция, за които е установено, че съдържат грешки (както където е паднал сняг, не е имало деплой, но все пак има грешка) – важна е скоростта на последващия деплой. Какво направихме, за да удовлетворим тези изисквания? Прикладохме следната методология:

  
  
  Тя е доста известна, ние не я изобретихме – това е Blue/Green деплой. Какво е това? За всяка група сървъри, на които стоят вашите приложения, трябва да имате копия. Копията е „топла”: на нея няма трафик, но в момента трафикът може да бъде насочен към това копие. Тази копия съдържа предишната версия. И в момента на деплоя вие пускате кода на неактивната копия. След това пренасочвате част от трафика (или всичко) към новата версия. По този начин, за да промените потока на трафика от старата версия към новата, ви е нужно само едно действие: трябва да промените балансировача в апстрима, да смените посоката – от един апстрим на друг. Това е много удобно и решава проблема с бързото пренасочване и бързото връщане.

  Тук е решението и на втория въпрос – минимизация: можете да насочите към новата линия, линията с новия код, само част от вашия трафик (например, 2%). И тези 2% не са 100%! Ако загубите 100% от трафика при неуспешен деплой – това е страшно, докато ако загубите 2% от трафика – това е неприятно, но не е страшно. Освен това, потребителите вероятно дори няма да забележат, защото в някои случаи (не във всички) един и същ потребител, натискайки F5, може да попада на друга, работеща версия.

  Blue/Green деплой. Роутинг

  Обаче, не всичко е толкова просто с „Блу/Грийн деплоя”… Всички наши компоненти могат да бъдат разделени на три групи:

  • това е фронтенд (платежни страници, които виждат нашите клиенти);
  • ядро на обработката;
  • адаптер за работа с платежни системи (банки, „МастърКард”, „Виза”…).

  И тук има нюанс – нюансът е в маршрутизацията между линиите. Ако просто прехвърлите 100% от трафика, няма да имате тези проблеми. Но ако искате да прехвърлите 2%, започват въпросите: «Как да го направим?» Най-простият вариант, директно: можете да настроите случайно разпределение, Round Robin в Nginx, и ще имате 2% – наляво, 98% – надясно. Но това не винаги е подходящо.

  При нас, например, потребителят взаимодейства със системата не с един запит. Това е нормално: 2, 3, 4, 5 запита – вашите системи може да са също такива. И ако е важно за вас всички запити на потребителя да идват на същата линия, на която е дошъл първият запит, или (вторият момент) всички запити на потребителя да отидат на нова линия след прехвърляне (работата му е могла да започне по-рано със системата, преди прехвърлянето), – тогава случайното разпределение не е подходящо. Имаме следните опции:

  
  
  Първата опция, най-простата – на базата на основните параметри на клиента (IP Hash). Имате IP, и по айпишника разделяте наляво-надясно. Тогава ще сработи вторият описан от мен случай, когато се е извършила деплой, потребителят вече е могъл да започне работа с вашата система, и от момента на деплоя всички запити ще отидат на новата линия (на същата, да кажем).

  Ако това по някакви причини не ви е подходящо и трябва задължително да изпращате запитвания на същата линия, откъдето е дошъл първоначалният инитен запит на потребителя, тогава имате два варианта…
  Първата опция: можете да вземете платен nginx+. Там има механизъм Sticky sessions, който при първоначалния запит на потребителя задава сесия на потребителя и я свързва с определен апстрийм. Всички последващи запити на потребителя в рамките на жизнения цикъл на сесията ще бъдат изпратени на същия апстрийм, където е зададена сесията.

  Това не ни подхожда, защото вече имахме обикновен nginx. Преходът към nginx+ – не е точно, че е скъпо, просто беше малко болезнено за нас и не съвсем правилно. „Sticky sessions“ за нас, например, не сработиха точно поради простата причина, че „Sticky sessions“ не дават възможност да се маршрутизира по критерия „Или-или“. Там може да се зададе, че правим „Sticky sessions“, например, по айпишника или по айпишника и по бисквитки, или по параметри на поста, но „Или-или“ – вече е по-сложно.

  Следователно, стигнахме до четвъртия вариант. Взехме nginx на 'стероиди' (това е openresty) – същият nginx, който допълнително поддържа включването на last-скриптове. Можете да напишете last-скрипт, да го предоставите на 'опенрест', и този last-скрипт ще се изпълни, когато постъпи заявка от потребителя.

  И написахме такъв скрипт, инсталирахме 'опенрест' и в този скрипт обхождаме 6 различни параметра чрез конкатенация на 'или'. В зависимост от наличието на определен параметър, знаем дали потребителят е дошъл на една или на друга страница, на една или на друга линия.

  Blue/Green деплой. Предимства и недостатъци

  Разбира се, можеше и да се направи малко по-просто (да използваме същите 'Стики сешнс'), но имаме още един нюанс, че не само потребителят взаимодейства с нас в рамките на една транзакция… Взаимодействат и платежните системи: след като обработим транзакцията (изпращайки заявка до платежната система), получаваме кулбек.
  И да кажем, ако вътре в нашия контур можем да проследим IP адреса на потребителя във всички заявки и на базата на IP адреса да разделяме, то не можем да кажем на 'Виза': 'Хора, ние сме такава ретро-компания, ние сме международна (на сайта и в Русия)… А моля, предайте ни допълнително IP адреса на потребителя в допълнително поле, вашият стандартизиран протокол'! Разбира се, те няма да се съгласят.

  
  
  Затова това не ни подхождаше – направихме openresty. Следователно, с маршрутизацията се получи така:

  'Блу/Грийн деплой' има, съответно, предимства, за които споменах, и недостатъци.

  Има два недостатъка:

  • трябва да се занимавате с маршрутизация;
  • вторият основен недостатък – разходите.

  Трябва ви два пъти повече сървъри, два пъти повече операционни ресурси, два пъти повече усилия за поддържане на всичките тези системи.

  Между прочим, среди преимуществ есть еще одна вещь, о которой я ранее не упоминал: у вас есть резерв в случае увеличения нагрузки. Если у вас происходит резкий рост потребностей, и к вам приходит множество пользователей, вы просто подключаете вторую линию с распределением 50 на 50 — и у вас сразу в два раза больше серверов в вашем кластере, пока вы не решите проблему нехватки серверов.

  Как осуществить быстрый деплой?

  Мы обсудили, как справиться с проблемой минимизации и быстрого отката, но остается вопрос: «Как быстро деплоиться?»

  
  
  Здесь все кратко и просто.

  • У вас должна быть система CD (Continuous Delivery) – без нее никак. Если у вас один сервер, вы можете деплоиться вручную. У нас около полутора тысячи серверов, и вручную это сделать невозможно, понятное дело – нам нужен отдел размером с этот зал только для деплоя.
  • Деплой должен быть параллельным. Если у вас последовательный деплой, это плохо. Один сервер – нормально, а вот с полутора тысячами серверов вы будете деплоить целый день.
  • Снова, чтобы ускорить процесс, это, пожалуй, уже не обязательно. При деплое обычно выполняется сборка проекта. У вас есть веб-проект, есть фронтенд-часть (вы у себя делаете веб-пак, собираете через npm – что-то в этом духе), и этот процесс в принципе недолгий – около 5 минут, но эти 5 минут могут быть критически важны. Поэтому, например, мы так не делаем: мы упростили процесс и деплоим артефакты.

    Что такое артефакт? Артефакт – это собранный билд, в котором уже выполнена вся сборочная работа. Этот артефакт мы храним в хранилище артефактов. Раньше мы использовали два таких хранилища – это был Nexus и сейчас jFrog Artifactory. Мы изначально выбрали Nexus, потому что начали практиковать этот подход в Java-приложениях (он хорошо подходил для этого). Затем мы также начали использовать его для некоторых приложений, написанных на PHP; и Nexus уже не подходил, поэтому мы выбрали jFrog Artifactory, который способен управлять практически всем. Мы даже пришли к тому, что в этом хранилище артефактов храним собственные бинарные пакеты, которые создаем для серверов.

  Резкий рост нагрузки

  Мы обсудили изменение версии программного обеспечения. Следующее, что нас интересует, это резкий рост нагрузки. Здесь я, вероятно, подразумеваю под резким ростом нагрузки не совсем то, что стоит понимать...

  Създадохме нова система – тя е насочена към услуги, модерен дизайн, навсякъде работници, навсякъде опашки, навсякъде асинхронност. В такива системи данните могат да преминават по различни потоци. За първата транзакция могат да бъдат ангажирани 1-ви, 3-ти, 10-ти работник, за втората транзакция – 2-ри, 4-ти, 5-ти. И днес, например, сутринта имате поток от данни, който ангажира първите три работника, а вечерта изведнъж се променя и всичко ангажира други три работника.

  И тук става така, че трябва да мащабирате работниците, трябва да мащабирате вашите услуги, но при това да не допуснете изтичане на ресурси.

  
  
  Определихме изискванията си. Тези изисквания са достатъчно прости: трябва да има Service discovery, параметризация – всичко стандартно за изграждане на такива масштабируеми системи, с едно изключение – амортизация на ресурсите. Казахме, че не сме готови да амортизираме ресурси, за да топлим въздуха на сървърите. Взехме 'Consul', взехме 'Nomad', който управлява нашите работници.

  Защо е проблем за нас? Нека се върнем малко назад. Зад нас в момента стоят около 70 платежни системи. Сутрин трафикът преминава през 'Sberbank', после 'Sberbank' спира, например, и ние го пренасочваме към друга платежна система. Работили сме с 100 работника до 'Sberbank', а след това трябва да повишим рязко 100 работника за друга платежна система. И е желателно всичко това да се случва без човешка намеса. Защото, ако има човешка намеса – там 24/7 трябва да седи инженер, който да се занимава само с това, защото такива повреди, когато имате 70 системи зад вас, стават регулярно.

  Затова погледнахме на 'Nomad', който има открит IP и написахме нашия инструмент Scale-Nomad – ScaleNo, който прави нещо такова: следи за растежа на опашката и намалява или увеличава броя на работниците в зависимост от динамиката на промените в опашката. Когато го направихме, помислихме: 'Може да го направим с отворен код?' После го погледнахме – той е прост, като две стотинки.

  Все още не сме го направили с отворен код, но ако след доклада, след осъзнаването, че ви трябва такова нещо, възникне нужда от него, на последния слайд има моите контакти – пишете ми, моля. Ако се съберат поне 3-5 човека – ние ще го направим с отворен код.

  
  
  Как работи? Нека да разгледаме! В интерес на времето: отляво има част от нашето наблюдение: това е една линия, отгоре - времето за обработка на събития, в средата - броя на транзакциите, отдолу - броя на работниците.

  Ако погледнем, на тази картинка има срив. На горния график един от графиците е изтекъл за 45 секунди - една от платежните системи се е сринала. Веднага след това е приведен трафик за 2 минути и започна ръст на опашката в другата платежна система, където нямаше работници (ние не изразходвахме ресурсите - обратно, изразходвахме ресурса правилно). Не искахме да затопляме - там имаше минимално количество, около 5-10 работника, но те не се справяха.

  На последния график се вижда „гърб“, който точно показва, че „Скалено“ е увеличил това количество два пъти. А след това, когато графикът малко е спаднал, той е намалил малко - количеството работници е било променено в автоматичен режим. Ето как работи това нещо. Говорехме за точка № 2 - „Как бързо да се отървем от причините“.

  Наблюдение. Как бързо да идентифицираме проблема?

  Сега първата точка - „Как бързо да идентифицираме проблема?“ Наблюдение! Ние трябва бързо да разберем определени неща. Какви неща трябва да разберем бързо?

  
  
  Три неща!

  • Трябва бързо да разберем и да осъзнаем работоспособността на нашите собствени ресурси.
  • Трябва бързо да разберем излизането от строя, да наблюдаваме работоспособността на системите, които са външни за нас.
  • Третата точка - идентифициране на логически грешки. Това е, когато системата работи за вас, по всички показатели всичко е нормално, но нещо не е наред.

  Тук, вероятно, няма да кажа нищо особено вълнуващо. Ще бъда капитан Очевидност. Търсехме какво има на пазара. У нас се събра „весел зоопарк“. Ето какъв зоопарк имаме в момента:

  
  
  Ние използваме „Заббиx“ за наблюдение на „желязото“, за наблюдение на основните показатели на сървърите. „Окметер“ използваме за бази данни. „Графана“ и „Прометей“ използваме за всички останали показатели, които не попадаха в първите две, като част от тях - с „Графаната“ и „Прометея“, част - „Графана“ с „Инфлюксом“ и Telegraf.

  Преди година искахме да използваме New Relic. Страхотен инструмент, той прави всичко. Но колкото много прави, толкова е и скъп. Когато увеличихме обема си до 1500 сървъра, дойде при нас доставчика и каза: „Да сключим договор за следващата година“. Погледнахме цената и решихме, че няма да го направим. Сега се отказваме от „Ню Релик“, остава ни около 15 сървъра под мониторинг на „Ню Релик“. Цената се оказа напълно нелепа.

  Имаме и един инструмент, който реализирахме сами – това е Debugger. Първоначално го нарекохме „Баггер“, но след това дойде нашият учител по английски, смяха се жестоко и го прекръстихме на „Дебаггер“. Какво представлява? Това е инструмент, който за 15-30 секунди на всеки компонент, като „черна кутия“ на системата, стартира тестове за обща работоспособност на компонента.

  Например, ако е външна страница (платежна страница) – просто я отваря и гледа как трябва да изглежда. Ако е обработка, прави тестова „транзакция“ – проверява, че тази „транзакция“ е достигнала. Ако е връзка с платежни системи – съответно пращаме тестово запитване, където можем, и проверяваме, че всичко е наред.

  Какви показатели са важни за мониторинг?

  Какво мониторим основно? Какви показатели са важни за нас?

  
  

  • Време за отговор / RPS на фронтовете – много важен показател. Той веднага показва, че нещо не е наред.
  • Брой обработени съобщения във всички опашки.
  • Брой работни единици.
  • Основни метрики за коректност.

  Последната точка – „бизнесова“, „бизнесова“ метрика. Ако искате да мониторите същото, трябва да определите една-две метрики, които са основни показатели за вас. При нас такава метрика е пропускливостта (отношението на успешните транзакции към общия поток транзакции). Ако в нея нещо се променя в интервала от 5-10-15 минути – значи имаме проблеми (ако кардинално се променя).

  Как изглежда това при нас – пример от един от нашите бордове:

  
  
  Отляво се виждат 6 графики, свързани съответно с линиите – броя на работниците и броя на съобщенията в опашките. Отдясно – RPS, RTS. Отдолу – същата бизнес метрика. И на бизнес метриката веднага можем да видим, че нещо не е наред на двете средни графики... Това е поредната система, която падна и е зад нас.

  Второто нещо, което трябваше да направим, беше да следим за падането на външните платежни системи. Тук използвахме OpenTracing – механизъм, стандарт, парадигма, която позволява трасировка на разпределени системи; и малко го променихме. Стандартната OpenTracing парадигма гласи, че изграждаме трасировка на всяка отделна заявка. Това не беше нужно за нас, затова го обгърнахме в обобщаваща, агрегационна трасировка. Създадохме инструмент, който ни позволява да следим скоростта на системите зад нас.

  
  
  Графиката показва, че една от платежните системи започна да отговаря за 3 секунди – имаме проблеми. При това тази система ще реагира, когато проблемите започнат, в интервала от 20 до 30 секунди.

  И третият клас мониторинг грешки, които съществуват – това е логическият мониторинг.

  Честно казано, не знаех какво да нарисувам на този слайд, защото дълго търсихме на пазара нещо, което да ни подойде. Нищо не намерихме, затова се наложи да направим сами.

  
  
  Какво имам предвид под логически мониторинг? Представете си: правите система (например, клонинг на "Тиндер"); направили сте я, пуснали сте я. Успешният мениджър Вася Пупкин я инсталира на телефона си, вижда там момиче, харесва я... а харесването не отива при момичето – харесването отива при охранителя Михалич от същия бизнес център. Мениджърът слиза надолу и след това се учудва: "Защо този охранител Михалич му се усмихва толкова приятно?"

  В такива ситуации… За нас тази ситуация звучи малко по-различно, защото (както писах) това е такава репутационна загуба, която индиректно води до финансови загуби. При нас ситуацията е обратна: можем да понесем директни финансови загуби – например, ако проведем транзакция като успешна, а тя е била неуспешна (или обратното). Пришло се е до написването на собствен инструмент, който следи по бизнес показатели броя на успешните транзакции в динамика на времеви интервал. Не намерихме нищо на пазара! Именно тази идея исках да изразя. За решаване на такъв вид задачи на пазара няма нищо.

  Това беше по въпроса как бързо да се идентифицира проблемът.

  Как да се определи причината за деплоя

  Третата група задачи, които решаваме – след като идентифицираме проблема, след като се отървем от него, е хубаво да разберем причината за разработката, за тестването и да направим нещо с това. Съответно, трябва да проведем изследване, трябва да вдигнем логовете.

  
  
  Ако говорим за логовете (основната причина – логовете), основната част от логовете ни е в ELK Stack – при почти всички е така. У някои, може, не е в ELK, но ако пишете логове в гигабайти, рано или късно ще стигнете до ELK. Ние пишем в терабайти.

  
  
  Тук има проблем. Поправихме, коригирахме грешка за потребителя, започнахме да копаем, какво е станало, влезохме в Kibana, въведохме там id-то на транзакцията и получихме такъв дълъг списък (показва много). И в този дълъг списък няма абсолютно никаква яснота. Защо? Защото не е ясно коя част принадлежи на кой работник, коя част принадлежи на кой компонент. И в този момент осъзнахме, че ни е нужна трасировка – именно OpenTracing, за който говорих.

  Помислихме за това преди година, обърнахме погледа си към пазара, и там се оказаха два инструмента – Zipkin и Jaeger. Jaeger е всъщност идеологически наследник, идеологически продължител на Zipkin. В Zipkin всичко е хубаво, освен това, че не може да агрегира, не може да включва логове в трасировката, само трасировка на времето. А Jaeger поддържа това.

  Погледнахме на "Егеря": можем да инструментализираме приложения, можем да пишем в API (стандартът API за PHP тогава не беше утвърден – това беше преди година, а сега вече е утвърден), но изобщо нямаше клиент. "Добре", помислихме си, и написахме собствен клиент. Какво получихме? Ето как изглежда:

  
  
  В "Егера" за всяко съобщение се създават спанове. Тоест, когато потребителят отваря системата, той вижда един или два блока за всяко входящо запитване (колкото входящи запитвания от потребителя е имало, толкова блока). За да улесним потребителите, добавихме етикети към логовете и времевия трасер. Съответно, в случай на грешка, нашето приложение маркира лога с етикета Error. Може да се филтрира по етикета Error и ще се покажат само спановете, които съдържат този блок с грешка. Ето как изглежда, ако развием спана:

  
  
  Вътре в спана има набор от трасета. В случая това са три тестови траса, и третият трас казва, че е възникнала грешка. При това, тук също виждаме времевата трасировка: отгоре – времева линия, и виждаме в какъв времеви интервал е записан конкретният лог.

  Съответно, ни се получи отлично. Написахме собствено разширение и го направихме с отворен код. Ако искате да работите с трасировката, ако искате да работите с "Егерем" на PHP – имаме нашето разширение, заповядайте да го ползвате, както се казва:

  
  
  Нашето разширение – това е клиент за работа с OpenTracing API, направено като php-екстенция, тоест ще трябва да го съберете и внедрите в системата. Преди година нямаше нищо друго. Сега се появиха и други клиенти, които са компоненти. Тук зависи от вас: или с composer изтегляте компонентите, или използвате разширението – изборът е ваш.

  Корпоративни стандарти

  Говорихме за трите заповеди. Четвъртата заповед е да се стандартизират подходите. За какво става дума? Това е приблизително за това:

  
  
  Защо тук се използва думата "корпоративни"? Не защото сме голяма или бюрократична компания, не! Думата "корпоративна" исках да използвам в контекста на това, че всяка компания, всеки продукт трябва да имат свои стандарти, и вие също. Какви стандарти имаме ние?

  
  

  • Имаме регламент за деплой. Без него не можем да се движим. Деплойваме около 60 пъти седмично, тоест имаме практически постоянни деплои. В регламента например, имаме табу за деплои в петък – принципно, не се деплойваме.
  • Документацията при нас е задължителна. Нито един нов компонент не попада в продукция, ако няма документация, дори и да е създаден от нашите RnD специалисти. Изискваме от тях инструкции за деплой, карта за мониторинг и ориентировъчно описание (както програмистите могат да го напишат) на как работи компонентът и как да го отстраним при проблем.
  • Ние решаваме не причината на проблема, а самия проблем – за което вече говорих. За нас е важно да защитим потребителя от проблеми.
  • Имаме допуски. Например, не смятаме за даунтайм, ако за две минути сме загубили 2 % от трафика. Това принципно не попада в нашата статистика. Ако процентът или времето е по-голямо, вече го смятаме.
  • И ние винаги пишем постмортеми. Каквото и да се случи, всяка ситуация, в която нещо се е държало нештатно на продукцията, ще бъде отразена в постмортема. Постмортемът е документ, в който описвате какво е станало, подробен тайминг, какво сте направили, за да го поправите и (това е задължителен раздел!) какво ще направите, за да не допуснете такова нещо в бъдеще. Това е задължително, необходимо за последващ анализ.

  Какво да считаме за даунтайм?

  
  
  Какво е довело до всичко това?

  Това доведе до факта, че (имахме определени проблеми със стабилността, което не удовлетворяваше нито клиентите, нито нас) през последните 6 месеца нашият показател за стабилност беше 99,97. Може да се каже, че не е много. Да, имаме към какво да се стремим. От този показател приблизително половината е стабилността, която не е наша, а на нашия web application firewall, който е пред нас и се използва като услуга, но на клиентите не им пука.

  Научихме се да спим спокойно през нощта. Най-накрая! Преди шест месеца не можехме. И на тази нота, във връзка с резултатите, искам да направя едно уточнение. Вчера вечерта имаше страхотна лекция за системата за управление на ядрен реактор. Ако ме чуват хора, които са писали тази система – моля, забравете за това, което казах за "2% – не е даунтайм". За вас 2% е даунтайм, дори и да е за две минути!

  В това всичко! Вашите въпроси.

  
  

  За балансировачите и миграцията от базата данни

  Въпрос от публиката (по-долу – В): – Добър вечер. Благодаря ви много за такава административна презентация! Въпросът е кратък, относно вашите балансировачи. Вие споменахте, че имате WAF, т.е. както разбирам, за балансировач използвате някакъв външен…

  ЕК: – Не, за балансировач използваме собствените си услуги. В случая WAF е за нас изключително инструмент за защита от DDoS.

  В: – Може ли да кажете няколко думи за балансировачите?

  ЕК: – Както вече споменах, това е група сървъри в openresty. В момента имаме 5 резервирани групи, които отговарят изключително… тоест, сървърът, на който стои само openresty, единствено проксира трафика. Съответно, за да разберете колко трафик поддържаме: сега имаме постоянен поток трафик – десетки мегабити. Те се справят, чувстват се добре, дори не се напрягат.

  В: – Също прост въпрос. Има Blue/Green deployment. Какво правите, например, с миграциите от базата данни?

  ЕК: – Добър въпрос! Вижте, при Blue/Green deployment имаме отделни опашки за всяка линия. Тоест, ако говорим за опашки събития, които се предават от worker на worker, те имат отделни опашки за синята линия и за зелената линия. Ако говорим за самата база данни, ние умишлено я сузихме, колкото можем, почти всичко прехвърлихме в опашки, в базата данни имаме само стек с транзакции. И стекът с транзакции е единен за всички линии. За базата данни в този контекст: не я разделяме на синя и зелена, защото и двата варианта на кода трябва да знаят какво се случва с транзакцията.

  Приятели, имам още един малък приз, за да ви мотивирам – книга. И трябва да я връча за най-добрия въпрос.

  В: – Здравствуйте. Благодаря за доклада. Въпросът е такъв. Мониторите плащанията, мониторите услугите, с които комуникирате… Но как мониторите, че човек по някакъв начин е дошъл на вашата платежна страница, извършил е плащане, а проектът му е зачислил парите? Тоест как мониторите, че merchant е на разположение и е приел вашия callback?

  ЕК: – „Merchant“ за нас в случая е точно такъв външен сервиз, както и платежната система. Ние мониторим скоростта на отговора на „мерчанта“.

  За криптиране на базата данни

  В: – Здравейте. Имам един близък въпрос. Имате ли чувствителни данни съгласно PCI DSS? Исках да попитам как съхранявате PAN-овете в опашките, през които трябва да преминават? Използвате ли някакво криптиране? И свързаният втори въпрос: съгласно PCI DSS е необходимо периодично да се прекриптира базата в случай на промени (например напускане на администратори) – как става с достъпността в този случай?

  
  
  ЕК: – Чудесен въпрос! Първо, ние не съхраняваме PAN-ове в опашките. Нямаме право да съхраняваме PAN в открит вид, затова използваме специална услуга (наричана от нас „Кейдемон“) – тя прави само едно: приема входящо съобщение и връща криптирано такова. Всички данни съхраняваме с това криптирано съобщение. Дължината на ключа ни е около един килобайт, за да бъде достатъчно сигурно и надеждно.

  В: – Вече нужен ли е 2 килобайта?

  ЕК: – Ами вчера беше 256... Къде още да отидем?!

  Това е първото. Второ, решението, което имаме, поддържа процедура за прекриптиране – там има два комплекта „кека“ (ключове), които дават „декове“, които криптират (key – това са ключовете, dek – производните от ключовете, които криптират). При инициация на процедурата (която се провежда редовно, от 3 месеца до ± някакви) зареждаме нов комплект „кека“ и извършваме прекриптиране на данните. Имаме отделни услуги, които извличат всички данни, криптират ги наново; до данните се съхранява идентификатор на ключа, с който са криптирани. След като данните са криптирани с новите ключове, старите ключове се изтриват.

  П понякога плащанията трябва да се извършват ръчно...

  В: – Тоест, ако дойде възстановяване на някаква операция, ще декриптирате с стария ключ?

  ЕК: – Да.

  В: – Тогава още един малък въпрос. Когато се случи някакъв срив, авария, инцидент, е необходимо да се прокара транзакцията на ръка. Имало е такава ситуация.

  ЕК: – Да, случва се.

  В: – От къде получавате тези данни? Или сами се разхождате и ръчно в това хранилище?

  ЕК: – Не, разбира се, имаме определена система за бек офис, която съдържа интерфейс за нашата поддръжка. Ако не знаем какъв статус има транзакцията (например, докато платежната система не е отговорила с таймаут) – в принципе не знаем, т.е. задаваме финален статус само при пълна увереност. В този случай присвояваме транзакцията в специален статус за ръчна обработка. На сутринта, на следващия ден, веднага щом поддръжката получи информация, че в платежната система остават определени транзакции, те ги обработват ръчно в този интерфейс.

  
  
  В: – Имам няколко въпроса. Един от тях е продължението на зоната PCI DSS: как извеждате логовете им от контур? Такъв въпрос, защото разработчикът може да е оставил каквото и да било в логовете! Вторият въпрос е: как правите хотфиксове? Ръчно в базата – това е един вариант, но може да има и безплатни хотфиксове – каква е процедурата? И третият въпрос, вероятно, е свързан с RTO, RPO. Имате наличност от 99,97, почти четири деветки, но разбирам, че имате и втори център за данни, трети център за данни, пети център за данни... Как се занимавате с тяхната синхронизация, репликация, всичко останало?

  ЕК: – Нека започнем с първия. Първият въпрос беше за логовете? Когато се пишат логовете, имаме прослойка, която маскира всичките чувствителни данни. Тя гледа по маската и по допълнителните полета. Съответно, логовете ни излизат с вече замаскирани данни и контур от PCI DSS. Това е една от редовните задачи, възложени на отдела за тестване. Те са задължени да проверяват всяка задача, включително и за логовете, които пишат, и това е една от редовните задачи при ревю на кода, за да се контролира, че разработчикът не е записал нещо. Последващата проверка се извършва редовно от отдела за информационна сигурност приблизително веднъж седмично: вземат се произволно логовете от последния ден и те преминават през специален сканер-анализатор от тестовите сървъри, за да проверят всичко.
  Относно hot-fix’ите. Това е включено в нашия регламент за деплоиране. Имаме отделен пункт за хотфиксовете. Считаме, че деплойваме хотфиксове денонощно, когато е необходимо. След като версията е събрана, след като е тествана, след като имаме артефакт – на повикване от поддръжката се обажда дежурният системен администратор и деплойва това в момента, когато е нужно.

  Относно „четирите девятки“. Цифрата, която имаме в момента, наистина е постигната и ние я стремим още в един от нашите дата центрове. Сега имаме втори дата център и започваме да маршрутизираме между тях, а въпросът за крос дата центровата репликация е наистина нетривиален. Опитвали сме да го решим по различни начини: пробвали сме да използваме същия „Тарантул“ – не проработи, веднага казвам. Затова стигнахме до извода, че правим поръчка на „сенса“ ръчно. Всичките ни приложения действат в асинхронен режим на необходимата синхронизация „промяна – готово“ между дата центровете.

  В: – Ако имате втори, защо не имате трети? Защото Split-brain още никой не…

  ЕК: – А при нас няма „Сплит-брейн“. Понеже всяко приложение поддържа мулти-мастър, не ни е важно в кой център е постъпило искането. Готови сме на ситуация, при която ако един дата център падне (на това разчитаме) и в средата на потребителското искане прехвърлим на втория дата център, можем да загубим този потребител, наистина; но това ще бъдат единици, абсолютни единици.

  В: – Добър вечер. Благодаря за доклада. Разказвате за вашия дебъгър, който в продукция провежда тестови транзакции. А може ли да разкажете повече за тестовите транзакции! Как дълбоко стига това?

  ЕК: – То минава през целия цикъл на компонента. За компонента няма разлика между тестова транзакция и реална. От логическа точка на гледна точка, това е просто отделен проект в системата, в който се провеждат само тестови транзакции.

  В: – А къде я отсявате? Ето, Core изпрати…

  ЕК: – Следим за „Кора“ в случая на тестовите транзакции… Имаме такова понятие, като маршрутизиране: „Кор“ знае в коя платежна система трябва да изпрати – ние изпращаме в фалшива платежна система, която просто дава http-отбивка и всичко.

  В: – Кажете ли, моля, приложението ви написано ли е като един огромен монолит, или го разрязахте на различни услуги или дори микросервизи?

  ЕК: – При нас не е монолит, разбира се, имаме приложение, ориентирано към услуги. Имаме шега, че имаме услуга от монолити – действително са доста големи. Не можем да го наречем микросервизи, но това са именно услуги, в рамките на които работят работници на разпределени машини.

  Ако услугата на сървъра е компрометирана...

  В: – Тогава имам следващия въпрос. Дори ако това беше монолит, вие все пак казахте, че имате много от тези instant-сървъри, всички те по принцип обработват данни, и въпросът е такъв: "В случай на компрометиране на един от instant-сървърите или приложението, каквото и да е отделно звено, имат ли те някакъв контрол на достъпа? Кой от тях какво може да прави? Към кого да се обърне, за какви данни?"

  
  
  ЕК: – Да, несъмнено. Изискванията за сигурност са доста сериозни. Първо, имаме открити движения на данни, а портовете са само тези, през които предварително предвиждаме движение на трафик. Ако компонент комуникира с базата данни (да кажем, с 'Мускил'), по 5-4-3-2, му ще бъдат отворени само 5-4-3-2, а други портове и направления на движение на трафик няма да бъдат достъпни. Освен това, трябва да разберем, че в продукцията имаме около 10 различни контури на сигурност. И дори ако приложението е компрометирано по някакъв начин, не дай боже, нападателят няма да може да получи достъп до консолата за управление на сървъра, защото това е друга мрежова зона на сигурност.

  В: – А мен в този контекст ме интересува повече моментът, че имате определени договори с услугите – какво могат да правят, през какви "екшъни" могат да се обръщат един към друг... И в нормалния поток някои определени услуги запитват определен набор от "екшъни" от другата. Към другите те не се обръщат в нормална ситуация, и имат различни области на отговорност. Ако обаче един от тях бъде компрометиран, ще може ли да извика "екшъни" на тази услуга?

  ЕК: – Разбирам. Ако при нормална ситуация с друг сървър комуникацията е разрешена, да. Според SLA договора, ние не следим дали имаш разрешени само първите 3 „екшъна”, а 4-тия ти е забранен. Това вероятно е излишно за нас, тъй като имаме 4-степенна система за защита на контурите. Предпочитаме да се защитаваме чрез контурите, а не на ниво вътрешности.

  Как работят Visa, MasterCard и „Сбербанк”

  В: – Искам да уточня момента относно прехвърлянето на потребителя от един дата-център на друг. Доколкото знам, „Виза” и „Мастеркард” работят с бинарния синхронен протокол 8583, там има миксове. Исках да разбера, сега става ли въпрос за прехвърляне – това е директно „Виза” и „Мастеркард”, или преди платежните системи, към процесорите?

  ЕК: – Това е преди миксовете. Миксовете ни са в един дата-център.

  В: – В груби линии, имате ли една точка на свързване?

  ЕК: – За „Виза” и „Мастеркард” – да. Просто защото „Виза” и „Мастеркард” изискват значителни инвестиции в инфраструктура за сключване на отделни договори за получаване на втори комплект миксове, например. Те са резервирани в рамките на един дата-център, но ако, не дай Боже, дата-центъра, където са миксовете за свързване с „Виза” и „Мастеркард”, се провали, то свързването с „Виза” и „Мастеркард” ще бъде загубено...

  В: – Как могат да бъдат резервирани? Знам, че „Виза” разрешава да се поддържа само един конект принципно!

  ЕК: – Те сами доставят оборудването. Във всеки случай, получихме оборудване, което е резервирано на железен принцип.

  В: – Тоест, шкафът от техните Connects Orange?..

  ЕК: – Да.

  В: – А как става в този случай: ако вашият дата-център изчезне, как да продължите да го използвате? Или просто трафикът спира?

  ЕК: – Не. В този случай просто ще пренасочим трафика към друг канал, който, естествено, ще бъде по-скъп за нас и за клиентите. Но трафикът няма да минава през нашето пряко свързване с „Виза”, „Мастеркард”, а през условния „Сбербанк” (много опростено).

  Дълбоко се извинявам, ако съм засегнал служителите на „Сбербанк”. Но според нашата статистика от руските банки, „Сбербанк” пада най-често. Не минава месец без нещо да се провали при „Сбербанк”.

  
  
  

  

  Малко реклама 🙂

  Благодарим ви, че оставате с нас. Харесвате ли нашите статии? Искате ли да виждате повече интересни материали? Подкрепете ни, като направите поръчка или препоръчате на познати, облачни VPS за разработчици от $4.99, уникален аналог на entry-level сървъри, който е създаден от нас за вас: Цялата истина за VPS (KVM) E5-2697 v3 (6 ядра) 10GB DDR4 480GB SSD 1Gbps от $19 или как да делите правилно сървър? (с налични опции за RAID1 и RAID10, до 24 ядра и до 40GB DDR4).

  Dell R730xd на половин цена в дата центъра Equinix Tier IV в Амстердам? Всичко това само при нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100TB от 199 $ в Нидерландия! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от 99 $! Чете се за това Как да построим инфраструктура от корпоративен клас с помощта на сървъри Dell R730xd E5-2650 v4 на стойност 9000 евро за малко пари?

Източник: habr.com