Оперативният директор на портала Banki.ru Андрей Николски говори на миналогодишната конференция относно осиротелите услуги: как да идентифицирате осиротели в инфраструктурата, защо осиротелите услуги са лоши, какво да правите с тях и какво да правите, ако нищо не помогне.
Под разреза е текстова версия на доклада.
Здравейте колеги! Казвам се Андрей, ръководя операции в Banki.ru.
Имаме големи услуги, това са такива монолитни услуги, има услуги в по-класически смисъл и има много малки. С моята работническо-селска терминология казвам, че ако една услуга е проста и малка, значи е микро, а ако не е много проста и малка, значи е просто услуга.
Плюсове на услугите
Бързо ще прегледам предимствата на услугите.
Първият е мащабирането. Можете бързо да направите нещо в услугата и да започнете производство. Получили сте трафик, клонирали сте услугата. Имате повече трафик, клонирали сте го и живеете с него. Това е добър бонус и по принцип, когато започнахме, за нас се смяташе, че е най-важно защо правим всичко това.
Второ, изолирано развитие, когато имате няколко екипа за разработка, няколко различни разработчици във всеки екип и всеки екип разработва своя собствена услуга.
При екипите има един нюанс. Разработчиците са различни. И има напр. . За първи път видях това с Максим Дорофеев. Понякога хората снежинки са в едни отбори, а не в други. Това прави различните услуги, използвани в компанията, малко неравномерни.
Вижте снимката: това е добър разработчик, има големи ръце, може много. Основният проблем е откъде идват тези ръце.
Услугите позволяват използването на различни езици за програмиране, които са по-подходящи за различни задачи. Някои услуги са в Go, други са в Erlang, други са в Ruby, нещо е в PHP, нещо е в Python. Като цяло можете да се разширите много широко. Тук също има нюанси.
Архитектурата, ориентирана към услуги, е предимно за devops. Тоест, ако нямате автоматизация, няма процес на внедряване, ако го конфигурирате ръчно, вашите конфигурации могат да се променят от екземпляр на услугата на екземпляр и трябва да отидете там, за да направите нещо, тогава сте в ада.
Например, имате 20 услуги и трябва да разположите на ръка, имате 20 конзоли и едновременно натискате „enter“ като нинджа. Не е много добре.
Ако имате услуга след тестване (ако има тестване, разбира се) и все още трябва да я завършите с файл, така че да работи в производството, също имам лоши новини за вас.
Ако разчитате на конкретни услуги на Amazon и работите в Русия, тогава преди два месеца също сте имали „Всичко наоколо гори, аз съм добре, всичко е готино“.
Използваме Ansible за автоматизиране на внедряването, Puppet за конвергенция, Bamboo за автоматизиране на внедряването и Confluence, за да опишем по някакъв начин всичко.
Няма да се спирам подробно на това, защото докладът е по-скоро за практики на взаимодействие, а не за техническо изпълнение.
Например имахме проблеми, когато Puppet на сървъра работи с Ruby 2, но някои приложения са написани за Ruby 1.8 и те не работят заедно. Нещо се обърква там. И когато трябва да стартирате няколко версии на Ruby на една машина, обикновено започвате да имате проблеми.
Например, ние даваме на всеки разработчик една платформа, на която има приблизително всичко, което имаме, всички услуги, които могат да бъдат разработени, така че той да има изолирана среда, да я разбива и да я изгражда както иска.
Случва се да имате нужда от специално компилиран пакет с поддръжка за нещо там. Доста е трудно. Слушах доклад, в който изображението на Docker тежи 45 GB. В Linux, разбира се, е по-просто, там всичко е по-малко, но все пак няма да има достатъчно място.
Е, има противоречиви зависимости, когато една част от проекта зависи от библиотека от една версия, друга част от проекта зависи от друга версия и библиотеките изобщо не са инсталирани заедно.
Имаме сайтове и услуги в PHP 5.6, срам ни е от тях, но какво да правим? Това е нашият единствен сайт. Има сайтове и услуги на PHP 7, има още, не се срамуваме от тях. И всеки разработчик има своя собствена база, където той щастливо вижда.
Ако пишете в компания на един език, тогава три виртуални машини на разработчик звучат нормално. Ако имате различни езици за програмиране, тогава ситуацията се влошава.
Имате сайтове и услуги на това, на това, след това още един сайт за Go, един сайт за Ruby и някои други Redis отстрани. В резултат на това всичко това се превръща в голямо поле за опора и през цялото време част от него може да се счупи.
Затова заменихме предимствата на езика за програмиране с използването на различни рамки, тъй като PHP рамките са доста различни, имат различни възможности, различни общности и различна поддръжка. И можете да напишете услуга, така че вече да имате нещо готово за нея.
Всеки сервиз разполага със собствен екип
Основното ни предимство, изкристализирало в продължение на няколко години, е че всеки сервиз разполага със собствен екип. Това е удобно за голям проект, можете да спестите време за документация, мениджърите познават добре своя проект.
Можете лесно да изпращате задачи от поддръжката. Например, застрахователната услуга се развали. И веднага екипът, който се занимава със застраховане, отива да го оправи.
Нови функции се създават бързо, защото когато имате една атомна услуга, можете бързо да завинтите нещо в нея.
И когато прекъснете услугата си, а това неизбежно се случва, вие не засягате услугите на други хора и разработчиците от други екипи не идват при вас с парченца и казват: „Да, да, не прави това.“
Както винаги, има нюанси. Имаме стабилни отбори, мениджърите са приковани към отбора. Има ясни документи, мениджърите следят внимателно всичко. Всеки екип с мениджър има няколко услуги и има определена точка на компетентност.
Ако екипите са плаващи (ние също понякога използваме това), има добър метод, наречен „звездна карта“.
Имате списък с услуги и хора. Звездичка означава, че лицето е експерт в тази услуга, книга означава, че лицето изучава тази услуга. Задачата на лицето е да смени книжката със звездичка. И ако нищо не е написано пред услугата, тогава започват проблеми, за които ще говоря по-нататък.
Как се появяват услугите сираци?
Първият проблем, първият начин да получите осиротяла услуга във вашата инфраструктура е да уволните хора. Случвало ли се е на някой бизнес да спазва крайните срокове, преди задачите да бъдат оценени? Понякога се случва крайните срокове да са кратки и просто да няма достатъчно време за документация. „Трябва да предадем услугата на производство, след което ще я добавим.“
Ако екипът е малък, се случва да има един разработчик, който пише всичко, останалите са в процес на работа. „Написах основната архитектура, нека добавим интерфейсите.“ След това по някое време мениджърът например си тръгва. И през този период, когато управителят е напуснал и все още не е назначен нов, самите разработчици решават къде отива услугата и какво се случва там. И както знаем (нека се върнем няколко слайда назад), в някои екипи има хора снежинки, понякога лидер на екип снежинки. След това той напуска и получаваме услуга за сираци.
В същото време задачите от поддръжката и от бизнеса не изчезват; те се озовават в изоставането. Ако е имало някакви архитектурни грешки по време на разработването на услугата, те също се озовават в неизпълнените задачи. Обслужването бавно се влошава.
Как да разпознаем сирак?
Този списък добре описва ситуацията. Кой научи нещо за тяхната инфраструктура?
Относно документираните заобикалки: има услуга и като цяло работи, има две страници ръководство за работа с нея, но никой не знае как работи вътре.
Или, например, има някакъв вид съкращаване на връзки. Например, в момента имаме три средства за съкращаване на връзки, използвани за различни цели в различни услуги. Това са само последствията.
Сега аз ще бъда капитанът на очевидното. Какво трябва да се направи? Първо, трябва да прехвърлим услугата на друг мениджър, друг екип. Ако лидерът на вашия екип все още не е напуснал, тогава в този друг екип, когато разберете, че услугата е като сирак, трябва да включите някой, който разбира поне нещо от нея.
Основното нещо: трябва да имате процедурите за прехвърляне, написани с кръв. В нашия случай обикновено наблюдавам това, защото имам нужда всичко да работи. Мениджърите имат нужда да бъдат доставени бързо и какво ще се случи с тях по-късно вече не е толкова важно за тях.
Следващият начин да направите сирак е „Ще го направим на външни изпълнители, ще бъде по-бързо и след това ще го предадем на екипа.“ Ясно е, че всеки има някакви планове в отбора, завой. Често бизнес клиент си мисли, че аутсорсингът ще направи същото като техническия отдел, който компанията има. Въпреки че мотиваторите им са различни. В аутсорсинга има странни технологични решения и странни алгоритмични решения.
Например, имахме услуга, която имаше Сфинкс на различни неочаквани места. По-късно ще ви кажа какво трябваше да направя.
Възложителите имат собствени рамки. Това е просто чист PHP с копиране и поставяне от предишен проект, където можете да намерите всякакви неща. Скриптовете за внедряване са голям недостатък, когато трябва да използвате някои сложни Bash скриптове, за да промените няколко реда в някакъв файл, и тези скриптове за внедряване се извикват от някакъв трети скрипт. В резултат на това променяте системата за внедряване, избирате нещо друго, хоп, но услугата ви не работи. Защото там беше необходимо да се поставят още 8 връзки между различни папки. Или се случва хиляда записа да работят, но сто хиляди вече не работят.
Ще продължа да съм капитан. Приемането на изнесена услуга е задължителна процедура. На някой случвало ли му се е да пристигне изнесен сервиз и да не го приемат никъде? Това не е толкова популярно, разбира се, като услуга за сираци, но все пак.
Услугата трябва да се провери, услугата трябва да се прегледа, паролите трябва да се сменят. Имахме случай, когато ни предоставиха услуга, има админ панел „if login == 'admin' && password == 'admin'...”, пише го направо в кода. Седим и мислим, а хората пишат това през 2018 г.?
Тестването на капацитета за съхранение също е необходимо нещо. Трябва да погледнете какво ще се случи със сто хиляди записа, дори преди да пуснете тази услуга някъде в производство.
Не трябва да е срам да изпратите услуга за подобрение. Когато кажете: „Няма да приемем тази услуга, имаме 20 задачи, направете ги, тогава ще приемем“, това е нормално. Съвестта ви не трябва да бъде наранена от факта, че назначавате управител или че бизнесът пилее пари. Тогава бизнесът ще харчи повече.
Имахме случай, когато решихме да изнесем пилотен проект.
Беше доставен навреме и това беше единственият критерий за качество. Ето защо направихме друг пилотен проект, който вече дори не беше пилотен. Тези услуги бяха приети и чрез административни средства те казаха, ето вашия код, ето екипа, ето вашия мениджър. Услугите всъщност вече започнаха да носят печалба. В същото време всъщност те все още са сираци, никой не разбира как работят, а мениджърите правят всичко възможно да се отрекат от задачите си.
Има още една страхотна концепция – партизанско развитие. Когато някой отдел, обикновено маркетинговият отдел, иска да тества хипотеза и поръчва цялата услуга да бъде изнесена. Започва да се влива трафик в него, затварят документите, подписват документи с изпълнителя, влизат в експлоатация и казват: „Пичове, имаме услуга тук, вече има трафик, носи ни пари, да го приемем.“ Ние си казахме: „Опа, как е възможно това.“
И друг начин да получите услуга-сирак: когато някой екип внезапно се окаже зареден, ръководството казва: „Нека прехвърлим услугата на този екип към друг екип, той има по-малко натоварване.“ И тогава ще го прехвърлим на трети отбор и ще сменим мениджъра. И накрая отново имаме сираче.
Какъв е проблемът със сираците?
Кой не знае, това е боен кораб Wasa, издигнат в Швеция, известен с факта, че потъна 5 минути след изстрелването. И кралят на Швеция, между другото, не е екзекутирал никого за това. Построен е от две поколения инженери, които не са знаели как да строят такива кораби. Естествен ефект.
Корабът можеше да потъне, между другото, по много по-лош начин, например, когато царят вече се возеше на него някъде в буря. И така, той се удави веднага, според Agile е добре да се провалиш рано.
Ако се провалим рано, обикновено няма проблеми. Например, по време на приемането е изпратено за преразглеждане. Но ако се провалим още в производството, когато се инвестират пари, тогава може да има проблеми. Последствия, както ги наричат в бизнеса.
Защо услугите за сираци са опасни:
- Услугата може внезапно да се повреди.
- Сервизът се ремонтира дълго време или изобщо не се ремонтира.
- Проблеми с безопасността.
- Проблеми с подобрения и актуализации.
- Ако важна услуга се повреди, репутацията на компанията страда.
Какво да правим с услугите за сираци?
Ще повторя какво да правя отново. Първо трябва да има документация. 7 години в Banki.ru ме научиха, че тестерите не трябва да вярват на думата на разработчиците, а операциите не трябва да вярват на думата на всички. Трябва да проверим.
Второ, необходимо е да се напишат диаграми на взаимодействие, защото се случва услугите, които не са много добре приети, да съдържат зависимости, за които никой не е казал. Например, разработчиците инсталираха услугата на своя ключ към някои Yandex.Maps или Dadata. Изчерпахте безплатния си лимит, всичко е счупено и изобщо не знаете какво се е случило. Всички подобни рейкове трябва да бъдат описани: услугата използва Dadata, SMS, нещо друго.
Трето, работа с технически дълг. Когато правите някакви патерици или приемате услуга и казвате, че нещо трябва да се направи, трябва да сте сигурни, че е направено. Защото тогава може да се окаже, че малката дупка не е толкова малка, и ще пропаднете през нея.
С архитектурни задачи имахме история за Сфинкса. Една от услугите използва Sphinx за въвеждане на списъци. Просто пагиниран списък, но се индексираше отново всяка вечер. Беше сглобен от два индекса: единият голям се индексираше всяка вечер, а имаше и малък индекс, който беше завинтен към него. Всеки ден, с 50% вероятност за бомбардировка или не, индексът се срива по време на изчислението и нашите новини спряха да се актуализират на главната страница. Първо бяха необходими 5 минути за повторно индексиране на индекса, след това индексът нарасна и в един момент започна да отнема 40 минути за повторно индексиране. Когато изрязахме това, въздъхнахме с облекчение, защото беше ясно, че ще мине още малко време и нашият индекс ще бъде преиндексиран на пълен работен ден. Това ще бъде провал за нашия портал, няма новини в продължение на осем часа - това е, бизнесът спря.
План за работа с осиротяла услуга
Всъщност това е много трудно да се направи, защото devops е свързано с комуникация. Искате да сте в добри отношения с колегите си и когато ударите колегите и мениджърите си по главата с разпоредби, те може да имат противоречиви чувства към тези хора, които правят това.
В допълнение към всички тези точки има още нещо важно: конкретни хора трябва да отговарят за всяка конкретна услуга, за всеки конкретен раздел от процедурата по внедряване. Когато няма хора и трябва да привлечеш други хора, които да проучат цялата тази материя, става трудно.
Ако всичко това не помогна и вашата осиротяла услуга все още е сирак, никой не иска да я поеме, документацията не е написана, екипът, който е бил извикан в тази услуга, отказва да направи каквото и да било, има прост начин - да повторите всичко
Тоест взимате наново изискванията за услугата и пишете нова услуга, по-добра, на по-добра платформа, без странни технологични решения. И вие мигрирате към него в битка.
Имахме ситуация, когато взехме услуга на Yii 1 и осъзнахме, че не можем да я развием по-нататък, защото ни свършиха разработчиците, които могат да пишат добре на Yii 1. Всички разработчици пишат добре на Symfony XNUMX. Какво да правя? Разпределихме време, разпределихме екип, разпределихме мениджър, пренаписахме проекта и плавно прехвърлихме трафика към него.
След това старата услуга може да бъде изтрита. Това е любимата ми процедура, когато трябва да вземете и изчистите някаква услуга от системата за управление на конфигурацията и след това да преминете и да видите, че всички автомобили в производство са били деактивирани, така че разработчиците да нямат никакви следи. Хранилището остава в Git.
Това е всичко, за което исках да говоря, готов съм да обсъдя, темата е holivar, много са плували в нея.
Слайдовете казват, че сте унифицирали езиците. Пример беше преоразмеряването на снимки. Наистина ли е необходимо да се ограничава стриктно до един език? Тъй като преоразмеряването на изображението в PHP всъщност може да се направи в Golang.
Всъщност това не е задължително, както всички практики. Може би в някои случаи дори е нежелателно. Но трябва да разберете, че ако имате технически отдел в компания от 50 души, 45 от тях са PHP специалисти, други 3 са devops, които познават Python, Ansible, Puppet и нещо подобно, и само един от тях пише на някакъв вид език. някаква услуга за преоразмеряване на изображения на Go, след което, когато тя напусне, експертизата си отива с нея. И в същото време ще трябва да потърсите специфичен за пазара разработчик, който знае този език, особено ако е рядък. Тоест от организационна гледна точка това е проблемно. От гледна точка на devops, няма да трябва просто да клонирате някакъв готов набор от ръководства, които използвате за разгръщане на услуги, но ще трябва да ги напишете отново.
В момента изграждаме услуга на Node.js и това ще бъде само платформа наблизо за всеки разработчик с отделен език. Но ние седяхме и си мислехме, че играта си заслужава свещта. Тоест, това е въпрос, върху който трябва да седнете и да помислите.
Как наблюдавате услугите си? Как събирате и наблюдавате регистрационни файлове?
Събираме логове в Elasticsearch и ги поставяме в Kibana и в зависимост от това дали е производствена или тестова среда, там се използват различни колектори. Някъде Дървосекач, другаде нещо друго, не помня. И все още има места в някои услуги, където инсталираме Telegraf и снимаме някъде другаде отделно.
Как да живеем с Puppet и Ansible в една и съща среда?
Всъщност сега имаме две среди, едната е Puppet, другата е Ansible. Ние работим за хибридизирането им. Ansible е добра рамка за първоначална настройка, Puppet е лоша рамка за първоначална настройка, защото изисква практическа работа директно върху платформата, а Puppet осигурява конвергенция на конфигурацията. Това означава, че платформата се поддържа в актуално състояние и за да може ансибилизираната машина да се поддържа актуална, трябва да изпълнявате книги за игри на нея през цялото време с известна честота. Това е разликата.
Как поддържате съвместимост? Имате ли конфигурации както в Ansible, така и в Puppet?
Това е нашата голяма болка, поддържаме съвместимост с ръцете си и мислим как да продължим от всичко това някъде сега. Оказва се, че Puppet пуска пакети и поддържа някои връзки там, а Ansible, например, пуска кода и коригира най-новите конфигурации на приложението там.
Презентацията беше за различни версии на Ruby. Какво решение?
Сблъскахме се с това на едно място и трябва да го държим в главите си през цялото време. Просто изключихме частта, работеща на Ruby, която беше несъвместима с приложенията, и я оставихме отделна.
Тази година конференция ще се проведе на 7 декември в Технополис. Заявки за доклади приемаме до 11 ноември. с нас, ако искате да поговорим.
Регистрацията за участници е отворена, присъединете се към нас!
Източник: www.habr.com