Директор з експлуатації порталу Banki.ru Андрій Нікольський розповів на минулорічній конференції про сервіси-сироти: як впізнати сироту в інфраструктурі, чим погані сервіси-сироти, що з ними робити, і як бути, якщо нічого не допомагає.
Під катом текстова версія доповіді.
Вітаю колеги! Мене звуть Андрій, я керую експлуатацією у компанії Banki.ru.
У нас є великі сервіси, це такі монолітосервіси, є сервіси більш класичному розумінні, є зовсім маленькі. Я у своїй робітничо-селянській термінології говорю, що якщо сервіс простий і маленький, то він мікро, а якщо він не дуже простий і не маленький, то він просто сервіс.
Плюси сервісів
Пробігу швиденько по плюсах сервісів.
Перше – масштабування. Ви можете швидко зробити щось на сервісі та стартувати у продакшн. У вас приїхав трафік, ви схиляли сервіс. У вас приїхав ще трафік, ви ще схилювалися і з цим живете. Це хороший бонус, і, в принципі, коли ми розпочинали, він вважався у нас найважливішим, навіщо ми взагалі все це робимо.
По-друге, ізольована розробка, коли у вас є кілька команд розробки, кілька різних розробників у кожній команді, і кожна команда пиляє якийсь свій сервіс.
Із командами виникає нюанс. Розробники бувають різні. І існують, наприклад, . Я вперше побачив це у Максима Дорофєєва. Іноді люди-сніжинки є в деяких командах, а в деяких їх немає. Це робить різні послуги, які використовуються в компанії, трохи нерівномірними.
Подивіться на картинку: це хороший розробник, у нього великі руки, він може багато робити. Головна проблема – звідки ці руки ростуть.
Сервіси дають можливість використовувати різні мови програмування, які більше підходять для різних завдань. Якийсь сервіс на Go, якийсь на Erlang, якийсь на Ruby, на PHP, щось на Python. Загалом можна розгорнутися дуже широко. Тут також є нюанси.
Сервіс-орієнтована архітектура – це насамперед про devops. Тобто якщо у вас немає автоматизації, немає процесу деплою, якщо ви налаштовуєте руками, у вас конфігурації можуть змінюватися від інстансу сервісу до інстансу, і вам доводиться туди ходити щось робити, то ви в пеклі.
Наприклад, у вас є 20 сервісів, і вам потрібно деплоїти руками, у вас 20 консолей, і ви одночасно тиснете enter, як ніндзя. Це не дуже добре.
Якщо у вас сервіс після тестування (якщо є тестування, звичайно), і треба ще допиляти напилком, щоб він працював у продакшені, у мене теж для вас погані новини.
Якщо ви покладаєтеся на специфічні послуги Амазона і працюєте при цьому в Росії, то два місяці тому у вас теж було «Все навколо горить, i'm fine, все класно».
Ми використовуємо Ansible для автоматизації розгортання, Puppet для збіжності, Bamboo для автоматизації деплою, Confluence для того, щоб якось описувати.
Докладно на цьому зупинятись не буду, бо доповідь скоріше про практики взаємодій, а не про технічну реалізацію.
У нас бували, наприклад, проблеми, що Puppet на сервері працює з Ruby 2, а якась програма написана під Ruby 1.8, і разом вони не працюють. Там якийсь одвірок трапляється. А коли вам треба на одній машині тримати кілька версій Ruby, у вас зазвичай починаються проблеми.
У нас, наприклад, кожному розробнику ми видаємо майданчик, на якому є приблизно все, що маємо, всі сервіси, які можна розробляти, щоб у нього було ізольоване оточення, він міг ламати його і будувати, як йому хочеться.
Буває, потрібен якийсь спеціально скомпільований пакет із підтримкою чогось там. Це досить жорстко. Я послухав доповідь, де докер-образ важить по 45 Гб. У лінуксі, звичайно, простіше, там менше все, але все одно, ніяких місць не вистачить.
Ну і бувають суперечливі залежності, коли у вас один шматок проекту залежить від бібліотеки однієї версії, інший шматок проекту від іншої версії, а бібліотеки разом не ставляться взагалі ніяк.
У нас є сайти та сервіси на PHP 5.6, нам за них соромно, але що робити. Це у нас один майданчик. Є сайти та сервіси на PHP 7, їх більше, за них нам не соромно. І у кожного розробника є своя база, де він радісно пиляє.
Якщо ви пишете в компанії однією мовою, то три віртуалки на розробника це нормально звучить. Якщо у вас різні мови програмування, то ситуація стає гіршою.
У вас з'являються сайти та сервіси на цьому, на цьому, потім ще один майданчик для Go, один майданчик для Ruby, ще якийсь Redis збоку. У результаті все це перетворюється на велике поле для підтримки, і весь час щось із цього може ламатися.
Тому ми замінили плюшки мови програмування на використання різних фреймворків, оскільки фреймворки на PHP досить різні, вони мають різні можливості, різне комьюніті, різна підтримка. І можна писати сервіс так, щоб у вас було щось готове під нього.
Кожен сервіс має свою команду
Наш головний плюс, який викристалізувався за кілька років, — кожен сервіс має свою команду. Це зручно для великого проекту, можна заощадити час на документації, менеджери добре знають свій проект.
Завдання з підтримки можна добре закидати. Наприклад, зламався страхування. І одразу команда, яка займається страхуванням, йде лагодити.
Швидко робляться нові фічі, тому що коли у вас один якийсь атомарний сервіс, у нього можна оперативно щось вкрутити.
І коли ви зламали свій сервіс, а це неминуче трапляється, ви не зачепили чужі сервіси, і до вас не вдаються розробники з бітами з інших команд і не кажуть: Ай-ай, не треба так.
Як завжди є нюанси. У нас стабільні команди, до команди менеджери прибиті цвяхами. Є чіткі документи, менеджери щільно за цим усім стежать. У кожної команди з менеджером є кілька сервісів, і є конкретна точка компетенції.
Якщо команди плаваючі (таке також у нас іноді використовується), є хороший метод, який називається «зоряна карта».
У вас є список сервісів та людей. Зірочка означає, що людина - експерт у цьому сервісі, книга означає, що людина вивчає цей сервіс. Завдання людини - поміняти книжечку на зірочку. А якщо навпроти сервісу нічого не написано, то починаються проблеми, про які я далі розповідатиму.
Як з'являються сервіси-сироти?
Перша проблема, перший спосіб отримати у себе в інфраструктурі сервіс-сироту — це звільнення людей. У когось бувало, коли з бізнесу прилітають терміни до того, як оцінили завдання? Іноді буває, що терміни жорсткі, і на документацію просто не вистачає часу. «Треба здавати сервіс у продакшн, потім допишемо».
Якщо команда невелика, то буває, що в ній один розробник, який пише все, інші на підхваті. "Я написав основну архітектуру, ти давай інтерфейси накидай". Потім колись менеджер, наприклад, йде. І в цей період коли менеджер пішов, а нового ще не призначили, розробники самі вирішують, куди сервіс рухається, що там відбувається. А як ми знаємо (повернемося на кілька слайдів назад), у деяких командах є люди-сніжинки, іноді сніжинка-тимлід. Потім він звільняється і ми отримуємо сервіс-сироту.
При цьому завдання від підтримки та бізнесу нікуди не подіються, вони осідають у беклозі. Якщо при розробці сервісу були якісь архітектурні помилки, вони також осідають у беклозі. Сервіс повільно деградує.
Як упізнати сироту?
Цей перелік непогано описує ситуацію. Хто дізнався у себе щось в інфраструктурі?
Про задокументовані work-around'и: є сервіс і загалом він працює, у нього є мануал на дві сторінки, як з ним працювати, але як він працює всередині, ніхто не знає.
Або, наприклад, є якийсь скорочувач посилань. У нас, наприклад, зараз у ході три скорочувачі посилань для різних цілей у різних сервісах. Це наслідки саме.
Тепер я буду капітаном очевидність. Що потрібно робити? По-перше, треба передати сервіс іншому менеджеру, іншій команді. Якщо у вас тимлід ще не звільнився, то до цієї іншої команди, коли ви розумієте, що сервіс схожий на сироту, треба включати когось, хто хоч щось у ньому розуміє.
Головна річ: у вас мають бути написані кров'ю процедури передачі. У нашому випадку, стежу за цим я зазвичай, тому що мені треба, щоб це все працювало. Менеджерам треба, щоб це було швидко здано, а що з ним потім буде, їм уже не так важливо.
Наступний спосіб зробити сироту — Зробимо на аутсорсі, так буде швидше, а потім передамо в команду. Зрозуміло, що всі мають якісь плани в команді, черга. Часто бізнес-замовник вважає, що на аутсорсері зроблять так само, як і техвідділ, який є в компанії. Хоча мотиватори мають різні. На аутсорсі бувають дивні технологічні рішення та дивні алгоритмічні рішення.
У нас, наприклад, був сервіс, у якому був Sphinx у різних несподіваних місцях. Я пізніше розповім, що довелося зробити.
У аутсорсерів бувають самописні фреймворки. Це просто голий PHP з копіпастом із попереднього проекту, де можна знайти всяке. Великі милиці в деплой-скриптах, коли вам потрібно якимись складними Bash-скриптами поміняти кілька рядків у якомусь файлі, при цьому ці деплой-скрипти викликаються якимось третім скриптом. У результаті ви міняєте систему деплою, вибираєте щось інше, хоп, а у вас сервіс не працює. Бо там треба було ще 8 посилань поставити між різними татками. Або буває, що тисяча записів працює, а сто тисяч уже нема.
Продовжу капітанити. Приймання сервісу з аутсорсу – це процедура, яка є обов'язковою. У кого бувало, що сервіс із аутсорсу приїжджає, а його нікуди не приймають? Це не так, звичайно, популярно, як сервіс-сирота, але все ж таки.
Сервіс треба перевіряти, сервіс треба рев'юїти, треба міняти паролі. У нас був випадок, коли нам підкинули сервіс, там адмінка «if login == 'admin' && password == 'admin'…», прямо в коді написано. Ми сидимо та думаємо, і це пишуть люди у 2018 році?
Тестування обсягу сховища теж потрібна штука. Потрібно дивитися, що буде на сто тисяч записах, ще до того, як ви цей сервіс кудись у продакшн пустите.
Надсилати сервіс на доопрацювання має бути не соромно. Коли ви кажете: "Ми цей сервіс не приймемо, у нас є 20 завдань, зробіть їх, тоді приймемо", це нормально. Совість не повинна хворіти від того, що ви підставите менеджера чи бізнес витратить гроші. Бізнес потім більше витратить.
Ми мали випадок, коли ми вирішили зробити пілотний проект на аутсорсі.
Він був зданий вчасно, і це був єдиний критерій якості. Тож зробили ще один пілотний проект, уже навіть не зовсім пілотний. Ці сервіси прийняли, адміністративними способами сказали, ось ваш код, ось команда, ось ваш менеджер. Сервіси вже реально почали приносити прибуток. При цьому вони залишилися, як і раніше, сиротами, ніхто не розуміє, як вони працюють, і менеджери всіляко від їхніх завдань відхрещуються.
Є ще одне чудове поняття — партизанська технологія. Коли якийсь відділ, як правило, це відділ маркетингу, хочуть перевірити гіпотезу і замовляють сервіс цілком на аутсорсі. На нього починає литися трафік, вони закривають документи, підписують акти з підрядником, приходять в експлуатацію та кажуть: «Чуваки, у нас тут є сервіс, на ньому вже є трафік, він нам приносить гроші, давайте його приймати». Ми такі: "Опа, як же так".
І ще один спосіб отримання сервісу-сироти: коли якась команда раптом виявляється навантаженою, керівництво каже: «Давайте ми передамо сервіс цієї команди іншій команді, у неї менше навантаження». А потім передамо третій команді, і менеджера поміняємо. І, зрештою, у нас знову сирота.
У чому проблема із сиротами?
Хто не знає, це піднятий у Швеції лінійний корабель Wasa, відомий тим, що він потонув за 5 хвилин після спуску на воду. І король Швеції, до речі, нікого за це не стратив. Він будувався двома поколіннями інженерів, які вміли будувати такі кораблі. Закономірний ефект.
Корабель міг потонути, до речі, набагато гірше, наприклад, коли на ньому вже їхав би король кудись у шторм. А так, потонув одразу, аджайлом це добре — провалитися рано.
Якщо ми провалилися рано, зазвичай проблем не буває. Наприклад, під час приймання відправили на доопрацювання. А якщо ми провалилися вже у продакшені, коли вкладено гроші, то можуть бути проблеми. Наслідки, як їх називають у бізнесі.
Чим небезпечні сервіси-сироти:
- Сервіс може зламатися раптово.
- Сервіс довго лагодиться або не лагодиться взагалі.
- Проблеми із безпекою.
- Проблеми з доопрацюваннями та оновленнями.
- Якщо ламається важливий сервіс, страждає репутація компанії.
Що робити із сервісами-сиротами?
Ще раз повторю, що робити. По-перше, має бути документація. 7 років у Banki.ru мене навчили, що тестувальники не повинні вірити на слово розробникам, а експлуатація не повинна вірити на слово всім. Треба перевіряти.
По-друге, треба писати схеми взаємодій, тому що буває, що послуги, які прийняті не дуже добре, містять залежності, про які ніхто не сказав. Наприклад, розробники поставили сервіс на свій ключ до якихось Яндекс.Карт або до Dadata. У вас скінчився безкоштовний ліміт, все зламалося, і ви не знаєте, що сталося взагалі. Всі такі граблі повинні бути описані: у сервісі використовується Dadata, Sms, ще щось.
По-третє, робота з техборгом. Коли ви робите якісь милиці або приймаєте сервіс і кажете, що щось треба зробити, треба стежити, щоб це робили. Тому що потім може виявитися, що маленька ямка не така маленька, і ви туди провалитеся.
З архітектурними завданнями у нас була історія про Sphinx. В одному із сервісів Sphinx використовувався для того, щоб вводити списки. Просто список із пагінацією, але при цьому він переіндексувався щоночі. Він був зібраний з двох індексів: один індексувався щоночі великий, і був ще маленький індекс, який до нього прикручувався. Щодня, з ймовірністю 50% або бомбанет, або ні, при викладанні індекс бився, і новини у нас переставали оновлюватися на головній сторінці. Спочатку це було 5 хвилин, поки індекс переіндексувався, потім індекс розрісся, і якоїсь миті він почав переіндексуватися 40 хвилин. Коли ми це випилили, ми зітхнули з полегшенням, бо було зрозуміло, що мине ще трохи часу, і в нас індекс буде переіндексуватись повний робочий день. Це буде фейл для нашого порталу, вісім годин немає новин — все бізнес став.
План роботи із сервісом-сиротою
Насправді це дуже важко робити, бо девопс — це про спілкування. Хочеться бути у добрих стосунках зі своїми колегами, а коли ти колег та менеджерів б'єш регламентами по голові, вони можуть відчувати суперечливі почуття до тих людей, які так роблять.
Крім всіх цих пунктів, є ще важлива штука: за кожний конкретний сервіс, за кожну конкретну ділянку процедури деплою повинні відповідати конкретні люди. Коли людей немає і доводиться залучати якихось інших людей, вивчати всю цю справу стає важко.
Якщо все це не допомогло, і сервіс-сирота у вас, як і раніше, залишився сиротою, його ніхто не хоче до себе брати, документація не пишеться, команда, яку в цей сервіс закликали, відмовляється щось робити, є простий спосіб — все переробити .
Тобто ви берете вимоги до сервісу заново і пишете новий сервіс, найкращий, на найкращій платформі, без дивних технологічних рішень. І мігруєте на нього у бою.
У нас була ситуація, коли ми взяли сервіс на Yii 1 і зрозуміли, що ми не можемо його далі розвивати, тому що у нас скінчилися розробники, які вміють добре писати на Yii 1. Усі розробники добре пишуть на третьому Symfony. Що робити? Виділили час, виділили команду, виділили менеджера, переписали проект і плавно переключили на нього трафік.
Після цього старий сервіс можна видалити. Це моя улюблена процедура, коли із системи управління конфігураціями треба взяти і вичистити якийсь сервіс і потім пройтися подивитися, щоб усі тачки на продакшені були погашені, щоб розробники ніяких слідів не залишилися. Репозиторій у гіті залишається.
Це все, про що я хотів розповісти, готовий подискутувати, тема холіварна, багато хто в ній плавав.
На слайдах було те, що ви уніфікували мови. Як приклад був ресайзинг картинок. А чи справді потрібно жорстко до однієї мови? Тому що ресайз картинки на PHP, можна було дійсно і на Golang зробити.
Насправді це необов'язково, як і всі практики. Можливо, в якихось випадках навіть небажано. Але треба розуміти, що якщо у вас у компанії 50 осіб техвідділ, з них 45 — PHP-шники, ще 3 — девопси, які вміють у Python, Ansible, Puppet і що-небудь таке, і тільки один із них пише на якому- небудь Go сервіс ресайзу картинок, то, коли він йде, експертиза йде разом з ним. І при цьому вам потрібно буде шукати специфічного на ринку розробника, який знає цю мову, особливо якщо вона рідкісна. Тобто, з організаційної точки зору, це проблемно. З погляду девопса, вам потрібно не просто схиляти якийсь готовий набір плейбуків, які ви використовуєте для того, щоб розгортати сервіси, а доведеться писати їх заново.
Ми зараз пиляємо сервіс на Node.js, і це буде якраз майданчик поряд для кожного розробника з окремою мовою. Але ми посиділи подумали, що гра коштує свічок. Тобто тут питання на посидіти та подумати.
Як ви моніторите ваші сервіси? Як збираєте та відстежуєте логи?
Логи ми збираємо в Elasticsearch і кладемо в Kibana, а залежно від того, продакшн це чи тестові середовища, там використовуються різні збирачі. Десь Lumberjack, десь ще щось, я вже не пам'ятаю. І є ще деякі місця у певних сервісах, де ми ставимо Telegraf та куляємо ще кудись окремо.
Як жити з Puppet та Ansible в одному середовищі?
Насправді, у нас зараз два середовища, одне – Puppet, інше Ansible. Ми працюємо над тим, щоб їх гібридизувати. Ansible – це гарне середовище для початкового налаштування, Puppet – це погана штука для початкового налаштування, тому що вимагає роботи руками безпосередньо з майданчиком, і Puppet забезпечує збіжність конфігурації. Це означає, що майданчик сам себе підтримує в актуальному стані, а для того, щоб ансибльована машина підтримувалася в актуальному стані, потрібно на ньому постійно ганяти плейбуки з якоюсь періодичністю. Ось така різниця.
Як ви підтримуєте сумісність? У вас є конфіги і в Ansible, і Puppet?
Це наш великий біль, ми підтримуємо сумісність руками і думаємо, як зараз від усього цього кудись перейти. У нас виходить, що Puppet накочує пакети і підтримує там якісь посилання, а Ansible у нас, наприклад, накочує код і підганяє свіжі конфіги додатків.
У презентації було про різні версії Ruby. Яке рішення?
Ми в одному місці з цим зіткнулися, і нам доводиться весь час пам'ятати. Ми просто вимкнули ту частину, яка працювала на тому Ruby, який був несумісний із додатками, і тримали її окремо.
Цього року конференція пройде 7 грудня у «Технополісі». До 11 листопада ми приймаємо заявки на доповіді. нам, якщо ви бажаєте виступити.
Реєстрація для учасників відкрита, приєднуйтесь!
Джерело: habr.com