Директорът по експлоатация на портала Banki.ru Андрей Николски разказа на миналогодишната конференция за услуги-сироти: как да разпознаем сиротата в инфраструктурата, какво е лошото в услугите-сироти, какво да правим с тях и какво да правим, ако нищо не помага.
Под катa е текстовата версия на доклада.
Здравейте, колеги! Казвам се Андрей, ръководя експлоатацията в компанията Banki.ru.
Имаме големи услуги, това са монолитни услуги, имаме услуги в по-класическия смисъл, имаме и съвсем малки. В своята работническо-селска терминология казвам, че ако услугата е проста и малка, то тя е микро, а ако не е много сложна и не е малка, то тя е просто услуга.
Плюсове на услугите
Ще пробягам бързо през плюсовете на услугите.
Първото — мащабируемост. Можете бързо да направите нещо на услугата и да стартирате в продукция. Пристигна ви трафик, услугата е клонирана. Пристигна ви още трафик, клонирате отново и с това живеете. Това е добър бонус и в принципе, когато започнахме, това се смяташе за най-важното, защо всъщност правим всичко това.
На второ място, изолирано разработване, когато имате няколко екипа за разработка, различни разработчици в всеки екип и всеки екип създава своя собствена услуга.
С екипите възниква нюанс. Разработчиците са различни. И съществуват, например, . За първи път го видях при Максим Дорофеев. Понякога хората-снежинки съществуват в някои екипи, а в други ги няма. Това прави различните услуги, които се използват в компанията, малко неравномерни.
Вижте картинката: това е добър разработчик, има големи ръце, може да прави много неща. Основната проблема е откъде идват тези ръце.
Услугите дават възможност да се използват различни програмни езици, по-подходящи за различни задачи. Някоя услуга на Go, друга на Erlang, друга на Ruby, нещо на PHP, нещо на Python. Общо взето, можете да се разширите много широко. И тук също има нюанси.
Архитектурата, ориентирана към услуги, е преди всичко за devops. Тоест, ако нямате автоматизация, нямате процес на внедряване, ако настройвате ръчно, вашите конфигурации могат да се променят от инстанция на услуга до инстанция и ще трябва да ходите и да правите нещо там, то значи сте в ада.
Например, имате 20 услуги и трябва да ги разгръщате ръчно, имате 20 конзоли и едновременно натискате "enter", като нинджа. Това не е много добре.
Ако имате услуга след тестване (ако има такова), и трябва да я настроите допълнително, за да работи в продукция, имам също за вас лоши новини.
Ако разчитате на специфични услуги на Амазон и работите в Русия, тогава преди два месеца и вие бяхте в ситуация "Всичко гори около мен, аз съм добре, всичко е супер".
Използваме Ansible за автоматизация на разгръщането, Puppet за конвергенция, Bamboo за автоматизация на разгръщането, Confluence за документиране на всичко това.
Няма да се спирам подробно на това, защото докладът е по-скоро за практиките на взаимодействие, а не за техническа реализация.
Имахме например проблеми, когато Puppet на сървъра работи с Ruby 2, а някое приложение е написано за Ruby 1.8, и двамата не работят заедно. Случва се някаква грешка. А когато имате нужда на една машина да имате няколко версии на Ruby, обикновено започват проблеми.
Например, на всеки разработчик предоставяме платформа, на която има почти всичко, което имаме, всички услуги, които могат да се разработват, за да има изолирана среда, в която да може да я разваля и изгражда както иска.
Понякога е нужен специално компилиран пакет с поддръжка на нещо. Това е доста стръмно. Чух доклад, в който Docker образът е с размер 45 ГБ. В Linux, разбира се, е по-лесно, там всичко е по-малко, но все пак, няма да има достатъчно място.
Имаме противоречиви зависимости, когато част от проекта зависи от библиотека с една версия, а друга част от проекта от друга версия, и библиотеките нямат как да се инсталират заедно.
Имаме сайтове и услуги на 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, трябва всеки път да се изпълняват плейбуците с някаква периодичност. Ето такава е разликата.
Как поддържате съвместимост? Имате конфигурации и в Ansible, и в Puppet?
Това е нашата голяма болка, ние поддържаме съвместимост с ръце и мислим как да преминем от всичко това на друго място. Изглежда, че Puppet инсталира пакети и поддържа някакви връзки, а Ansible, например, инсталира код и адаптира нови конфигурации на приложенията.
В презентацията става въпрос за различни версии на Ruby. Какво решение има?
Срещнахме тази ситуация на едно място и постоянно трябва да я имаме предвид. Просто изключихме онова, което работеше на версията на Ruby, която не беше съвместима с приложенията, и я държахме отделно.
Тази година конференцията ще се проведе на 7 декември в "Технополиса". До 11 ноември приемаме заявки за доклади. на нас, ако искате да представите.
Регистрацията за участниците е отворена, присъединете се!
Източник: habr.com
