Усі розповідають про процеси розробки та тестування, навчання персоналу, підвищення мотивації, але цих процесів мало, коли хвилина простою сервісу коштує космічних грошей. Що робити, коли ви проводите фінансові транзакції під жорсткий 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 років тому це був такий стартап, коли прийшли хлопці разом із бізнесом. Вони були об'єднані ідеєю (більше нічого не було, крім ідеї) і ми побігли. Як і будь-який стартап, ми бігли швидше… Для нас була важливіша швидкість, а не якість.
Якоїсь миті ми зупинилися: усвідомили, що ми вже не можемо з тією швидкістю і з тією якістю якось жити і нам потрібно робити насамперед саме якість. У цей момент ми вирішили написати нову платформу, яка буде правильною, масштабованою, надійною. Цю платформу почали писати (почали вкладати, розвивати розробку, тестування), але в якийсь момент зрозуміли, що технологія, тестування не дозволяють вийти на новий рівень якості сервісу.
Ви робите новий продукт, ви його виставляєте на продакшн, але десь щось піде не так. І сьогодні ми поговоримо про те, як вийти на новий якісний рівень (у нас як це вийшло, про наш досвід), виносячи за дужки розробку та тестування; ми поговоримо про те, що доступно для експлуатації – що експлуатація може зробити сама, що вона може запропонувати тестуванню, щоб вплинути на якість.
Даунтайми. Заповіді до експлуатації.
Завжди основний наріжний камінь, про що ми сьогодні, власне, говоритимемо – даунтайм. Страшне слово. Якщо у нас стався даунтайм – у нас все погано. Ми біжимо піднімати, адмін сервер тримають - дай бог не впаде, як у тій пісні співається. Ось про це ми сьогодні поговоримо.
Коли ми почали змінювати свої підходи, ми сформували чотири заповіді. Вони у мене представлені на слайдах:
Ці заповіді досить прості.
- Швидко виявити проблему.
- Ще швидше її позбутися.
- Допомогти зрозуміти причину (потім, для розробників).
- І стандартизувати підходи.
Зверну вашу увагу на пункт № 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, і ви по IP-адресі розділяєте направо-ліворуч. Тоді у вас спрацює другий описаний мною випадок, коли стався деплой, користувач вже міг почати працювати з вашою системою, і з моменту деплою всі запити підуть на нову лінію (на ту саму, скажімо).Якщо це з якихось причин вам не підходить і вам треба обов'язково надсилати запити на ту лінію, куди надійшов первинний, інітний запит користувача, тоді у вас є два варіанти.
Перший варіант: ви можете взяти платний nginx+. Там є механізм Sticky sessions, який при первинному запиті користувача виставляє користувачеві сесію та прив'язує її до того чи іншого апстріму. Усі наступні запити користувача в рамках терміну життя сесії вирушать на той самий апстрім, куди було виставлено сесію.Нам це не підійшло, тому що в нас уже був звичайний nginx. Переходити nginx+ - не те щоб це дорого, просто це було для нас дещо боляче і не дуже правильно. «Стики сешнс» для нас, наприклад, не спрацювали з тієї простої причини, що «Стики сешнс» не дають змоги роутити за ознакою «Або-або». Там можна задати, що ми «Стики сешнс» робимо, наприклад, по айпішнику або по айпішнику і по куках або постпараметру, а ось «Або-або» - там вже складніше.
Тому ми дійшли четвертого варіанту. Ми взяли nginx на "стероїдах" (це openresty) - це такий же nginx, який додатково підтримує включення в себе last-скриптів. Ви можете написати last-скрипт, підсунути цьому «опенресті», і цей ластскрипт виконуватиметься, коли прийде запит користувача.
І ми написали, власне, такий скриптик, поставили собі «опенресті» і в цьому скрипті перебираємо 6 різних параметрів конкатенації «Або». Залежно від того чи іншого параметра, ми знаємо, що користувач прийшов на одну сторінку або на іншу, на одну лінію або на іншу.
Blue/Green deploy. Гідності й недоліки
Звичайно, можна було, напевно, зробити трохи простіше (ті ж «Стики сешнс» використовувати), але у нас є ще такий нюанс, що з нами не тільки користувач взаємодіє в рамках одного процесингу однієї транзакції… Але з нами взаємодіють ще платіжні системи: ми, після того, як процесуємо транзакцію (надправивши запит до платіжної системи), отримуємо кулбек.
І припустимо, якщо всередині нашого контуру ми можемо прокинути IP-адресу користувача у всіх запитах і на основі IP-адреси користувачів розділяти, то ми не скажемо тієї ж «Візі»: «Чуваки, ми така ось ретро-компанія, ми начебто міжнародна (на сайті і в Росії)… А прокиньте нам, будь ласка, IP-адресу користувача додатково в додаткове поле, ваш протокол стандартизований»! Зрозуміло, вони не погодяться.
Тому для нас це не підійшло – ми зробили 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?
ЕК: - Так.
В: - А ось як у цьому випадку: якщо у вас дата-центр пропадає, як далі використовувати? Чи просто трафік зупиняється?
ЕК: – Ні. Ми в цьому випадку просто переключимо трафік на інший канал, який, природно, буде дорожчим нам, дорожчим клієнтам. Але трафік піде не через наше пряме підключення до «Візи», «МайстерКарду», а через умовний «Сбербанк» (дуже перебільшено).
Я дико вибачаюсь, якщо я зачепив співробітників Ощадбанку. Але, за нашою статистикою, з російських банків «Сбербанк» падає найчастіше. Не минає місяця, щоб у Ощадбанку щось не відвалилося.
Небагато реклами 🙂
Дякую, що залишаєтеся з нами. Вам подобаються наші статті? Бажаєте бачити більше цікавих матеріалів? Підтримайте нас, оформивши замовлення або порекомендувавши знайомим, , унікальний аналог entry-level серверів, який був винайдений нами для Вас: (Доступні варіанти з RAID1 і RAID10, до 24 ядер і до 40GB DDR4).
Dell R730xd вдвічі дешевше в дата-центрі Equinix Tier IV в Амстердамі? Тільки в нас у Нідерландах! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – від $99! Читайте про те
Джерело: habr.com