Директор операција портала Банки.ру Андреј Николски говорио је на прошлогодишњој конференцији о услугама сирочади: како идентификовати сирочад у инфраструктури, зашто су услуге сирочади лоше, шта да се ради са њима и шта да се ради ако ништа не помогне.
Испод реза налази се текстуална верзија извештаја.
Здраво колеге! Моје име је Андреј, руководим операцијама у Банки.ру.
Имамо велике услуге, то су такве монолитне услуге, постоје услуге у класичнијем смислу, а има и веома малих. У својој радничко-сељачкој терминологији кажем да ако је нека услуга проста и мала, онда је микро, а ако није баш једноставна и мала, онда је само услуга.
Предности услуга
Брзо ћу прећи преко предности услуга.
Први је скалирање. Можете брзо да урадите нешто на сервису и покренете производњу. Добили сте саобраћај, клонирали сте услугу. Имате више саобраћаја, клонирали сте га и живите са тим. Ово је добар бонус и, у принципу, када смо почињали, сматрало се да је за нас најважније зашто све ово радимо.
Друго, изоловани развој, када имате неколико развојних тимова, неколико различитих програмера у сваком тиму и сваки тим развија сопствену услугу.
Код тимова постоји нијанса. Програмери су различити. А постоје нпр. . Први пут сам ово видео код Максима Дорофејева. Понекад су људи са пахуљицама у неким тимовима, а не у другим. Ово чини различите услуге које се користе у компанији помало неуједначеним.
Погледајте слику: ово је добар програмер, има велике руке, може много. Главни проблем је одакле долазе ове руке.
Услуге омогућавају коришћење различитих програмских језика који су погоднији за различите задатке. Неки сервиси су у Го-у, неки у Ерлангу, неки у Руби-у, нешто у ПХП-у, нешто у Питхон-у. Генерално, можете се проширити веома широко. И овде има нијанси.
Сервисно оријентисана архитектура се првенствено односи на девопс. То јест, ако немате аутоматизацију, нема процеса имплементације, ако га конфигуришете ручно, ваше конфигурације могу да се мењају од инстанце услуге до инстанце, и морате да одете тамо да бисте нешто урадили, онда сте у паклу.
На пример, имате 20 сервиса и морате да их примените ручно, имате 20 конзола и истовремено притискате „ентер“ као нинџа. Није баш добро.
Ако имате сервис након тестирања (ако постоји тестирање, наравно), а још увек треба да га завршите са фајлом да би радио у продукцији, имам и лоше вести за вас.
Ако се ослањате на одређене Амазонове услуге и радите у Русији, онда сте пре два месеца такође имали „Све около гори, добро сам, све је у реду“.
Користимо Ансибле да аутоматизујемо примену, Пуппет за конвергенцију, Бамбоо да аутоматизујемо примену и Цонфлуенце да некако све то опишемо.
Нећу се задржавати на овоме детаљно, јер је извештај више о пракси интеракције, а не о техничкој имплементацији.
На пример, имали смо проблема где Пуппет на серверу ради са Руби 2, али неке апликације су написане за Руби 1.8, а оне не раде заједно. Ту нешто пође по злу. А када треба да покренете више верзија Руби-а на једној машини, обично почињете да имате проблема.
На пример, сваком програмеру дајемо платформу на којој се налази отприлике све што имамо, сви сервиси који се могу развити, тако да он има изоловано окружење, може да га разбије и изгради како хоће.
Дешава се да вам треба неки посебно састављен пакет са подршком за нешто тамо. Прилично је тешко. Слушао сам извештај где Доцкер слика има 45 ГБ. У Линуку је, наравно, једноставније, тамо је све мање, али ипак неће бити довољно простора.
Па, постоје конфликтне зависности, када један део пројекта зависи од библиотеке једне верзије, други део пројекта зависи од друге верзије, а библиотеке се уопште не инсталирају заједно.
Имамо сајтове и сервисе у ПХП 5.6, стидимо их се, али шта да радимо? Ово је наш један сајт. На ПХП 7 постоје сајтови и сервиси, има их више, не стидимо их се. И сваки програмер има своју базу у којој радо види.
Ако пишете у компанији на једном језику, три виртуелне машине по програмеру звучи нормално. Ако имате различите програмске језике, онда се ситуација погоршава.
Имате сајтове и услуге на овом, на овоме, затим још једну локацију за Го, једну локацију за Руби и још неки Редис са стране. Као резултат, све ово се претвара у велико поље за подршку, а све време нешто од тога може да се поквари.
Стога смо предности програмског језика заменили употребом различитих оквира, пошто су ПХП оквири прилично различити, имају различите могућности, различите заједнице и различиту подршку. И можете написати услугу тако да већ имате нешто спремно за њу.
Свака служба има свој тим
Наша главна предност, која се искристалисала током неколико година, је што свака служба има свој тим. Ово је згодно за велики пројекат, можете уштедети време на документацији, менаџери добро познају свој пројекат.
Можете лако да пошаљете задатке из подршке. На пример, служба осигурања се покварила. И одмах екипа која се бави осигурањем иде да то поправља.
Нове функције се брзо креирају, јер када имате једну атомску услугу, можете брзо да уврнете нешто у њу.
А када покварите свој сервис, а то се неизбежно дешава, нисте утицали на услуге других људи, а програмери са деловима из других тимова вам не притрчавају и кажу: „Ма, немој то да радиш“.
Као и увек, постоје нијансе. Имамо стабилне тимове, менаџери су приковани за тим. Постоје јасни документи, менаџери све помно прате. Сваки тим са менаџером има неколико услуга, а постоји и одређена тачка компетенције.
Ако тимови плутају (ми то понекад користимо), постоји добар метод који се зове „мапа звезда“.
Имате списак услуга и људи. Звездица значи да је особа стручњак за ову услугу, књига значи да особа студира ову услугу. Задатак особе је да замени књигу за звездицу. А ако ништа не пише испред сервиса, онда почињу проблеми о којима ћу даље говорити.
Како се појављују услуге сирочади?
Први проблем, први начин да добијете услугу сирочад у вашој инфраструктури је отпуштање људи. Да ли је неко икада имао посао да испуни рокове пре него што су задаци процењени? Понекад се дешава да су рокови тесни и једноставно нема довољно времена за документацију. „Морамо да предамо услугу производњи, а онда ћемо је додати.
Ако је тим мали, дешава се да постоји један програмер који све пише, остали су у крилима. „Написао сам основну архитектуру, хајде да додамо интерфејсе.“ Онда у неком тренутку менаџер, на пример, одлази. И током овог периода, када је менаџер отишао, а нови још није именован, програмери сами одлучују куда иде услуга и шта се тамо дешава. И као што знамо (вратимо се неколико слајдова уназад), у неким тимовима постоје људи пахуљица, понекад вођа тима пахуља. Онда он даје отказ, а ми добијамо услугу сирочади.
У исто време, задаци из подршке и из пословања не нестају; Ако је било архитектонских грешака током развоја сервиса, оне такође завршавају у заостатку. Услуга се полако погоршава.
Како препознати сироче?
Ова листа добро описује ситуацију. Ко је ишта научио о њиховој инфраструктури?
О документованим заобилазницама: постоји услуга и, генерално, ради, има упутство од две странице о томе како се ради са њим, али нико не зна како ради унутра.
Или, на пример, постоји нека врста скраћивача линкова. На пример, тренутно имамо три скраћивача линкова који се користе за различите сврхе у различитим услугама. Ово су само последице.
Сада ћу бити капитен очигледног. Шта треба учинити? Прво, треба да пребацимо услугу другом менаџеру, другом тиму. Ако ваш тимски вођа још није дао отказ, онда у овај други тим, када схватите да је услуга као сироче, треба да укључите некога ко се бар нешто разуме у то.
Главна ствар: морате имати крвљу написане процедуре преноса. У нашем случају то обично пратим, јер ми је потребно да све ради. Менаџерима је потребно да се брзо испоручи, а шта ће им се касније десити више им није толико важно.
Следећи начин да направите сироче је „Урадићемо то са спољним ангажовањем, биће брже, а онда ћемо то предати тиму.“ Јасно је да сви имају неке планове у тиму, преокрет. Често пословни клијент мисли да ће спољни сарадник урадити исту ствар као техничко одељење које компанија има. Иако су им мотиватори различити. У оутсоурцингу постоје чудна технолошка решења и чудна алгоритамска решења.
На пример, имали смо сервис који је имао Сфингу на разним неочекиваним местима. Рећи ћу ти касније шта сам морао да урадим.
Аутсорсери имају оквире који су сами написали. Ово је само голи ПХП са цопи-пасте из претходног пројекта, где можете пронаћи разне ствари. Скрипте за примену су велики недостатак када треба да користите неке сложене Басх скрипте да промените неколико редова у некој датотеци, а те скрипте за примену позива нека трећа скрипта. Као резултат тога, мењате систем распоређивања, бирате нешто друго, хоп, али ваша услуга не ради. Јер тамо је било потребно ставити још 8 веза између различитих фолдера. Или се дешава да хиљаду плоча ради, а сто хиљада више не ради.
Наставићу да будем капитен. Прихватање спољне услуге је обавезна процедура. Да ли је некоме икада стигла спољна услуга и нигде није примљен? Ово, наравно, није толико популарно као услуга сирочад, али ипак.
Сервис треба проверити, сервис прегледати, лозинке променити. Имали смо случај када су нам дали услугу, постоји админ панел „иф логин == 'админ' && пассворд == 'админ'...”, то пише директно у коду. Седимо и размишљамо, а људи пишу ово у 2018?
Тестирање капацитета складиштења је такође неопходна ствар. Треба погледати шта ће се десити на сто хиљада плоча, чак и пре него што ову услугу негде ставите у производњу.
Не би требало да буде срамота у слању услуге ради побољшања. Када кажете: „Нећемо прихватити ову услугу, имамо 20 задатака, урадите их, па ћемо прихватити“, то је нормално. Вашу савест не би требало да боли чињеница да постављате менаџера или да посао расипа новац. Посао ће тада више трошити.
Имали смо случај када смо одлучили да ангажујемо пилот пројекат.
Испоручено је на време и то је био једини критеријум квалитета. Зато смо направили још један пилот пројекат, који више није био ни пилот. Ове услуге су прихваћене, а административним путем су рекли, ево ти шифре, ево тима, ево ти менаџера. Услуге су заправо већ почеле да остварују профит. Истовремено, они су, у ствари, још увек сирочад, нико не разуме како раде, а менаџери дају све од себе да се одрекну својих задатака.
Постоји још један сјајан концепт - развој гериле. Када неко одељење, обично одељење за маркетинг, жели да тестира хипотезу и наручи да се целокупна услуга ангажује. Саобраћај почиње да се улива у њега, затварају документе, потписују документе са извођачем, пуштају у рад и кажу: „Друже, имамо ту службу, већ има саобраћаја, доноси нам новац, хајде да прихватимо“. Били смо као, "Опа, како је то могуће."
И још један начин да добијете услугу сироче: када се неки тим изненада преоптерети, управа каже: „Хајде да пребацимо услугу овог тима на други тим, он има мање оптерећење.“ А онда ћемо то пребацити у трећи тим и променити менаџера. И на крају опет имамо сироче.
Шта је проблем са сирочади?
Ко не зна, ово је бојни брод Васа подигнут у Шведској, познат по томе што је потонуо 5 минута након поринућа. А краљ Шведске, иначе, није никога погубио за ово. Градиле су га две генерације инжењера који нису знали како да направе такве бродове. Природни ефекат.
Лађа је могла потонути, иначе, и на много гори начин, на пример, када је краљ већ возио на њему негде у олуји. И тако, он се одмах удавио, према Агиле-у је добро пропасти рано.
Ако не успемо рано, обично нема проблема. На пример, током прихватања послат је на ревизију. Али ако не успемо већ у производњи, када се уложи новац, онда може бити проблема. Последице, како их у послу зову.
Зашто су услуге сирочади опасне:
- Услуга се може изненада прекинути.
- Сервису је потребно много времена да се поправи или се уопште не поправља.
- Безбедносни проблеми.
- Проблеми са побољшањима и ажурирањима.
- Ако се важна услуга поквари, репутација компаније пати.
Шта радити са услугама сирочади?
Поновит ћу шта да радим поново. Прво, мора постојати документација. 7 година на Банки.ру ме је научило да тестери не треба да верују програмерима, а да операције не треба да верују свима. Морамо да проверимо.
Друго, потребно је написати дијаграме интеракције, јер се дешава да сервиси који нису баш добро примљени садрже зависности о којима нико није рекао. На пример, програмери су инсталирали услугу на свој кључ неких Иандек.Мапс или Дата. Истекао си слободан лимит, све је покварено, а ти уопште не знаш шта се догодило. Све такве грабље морају бити описане: сервис користи податке, СМС, нешто друго.
Треће, рад са техничким дугом. Када урадите неку врсту штака или прихватите услугу и кажете да нешто треба да се уради, морате да се уверите да је то учињено. Јер онда се може испоставити да мала рупа није тако мала, па ћете пропасти кроз њу.
Уз архитектонске задатке, имали смо причу о Сфинги. Један од сервиса користио је Спхинк за унос листа. Само листа са страницама, али је поново индексирана сваке ноћи. Састављен је од два индекса: један велики индексирао се сваке вечери, а постојао је и мали индекс који је био причвршћен за њега. Сваког дана, са 50% вероватноће да ће се бомбардовати или не, индекс је падао током израчунавања, а наше вести су престајале да се ажурирају на главној страници. Прво је било потребно 5 минута да се индекс поново индексира, затим је индекс порастао, а у неком тренутку је почело да треба 40 минута да се поново индексира. Када смо ово прекинули, одахнули смо, јер је било јасно да ће проћи још мало времена и наш индекс ће бити поново индексиран за пуно радно време. Ово ће бити промашај за наш портал, осам сати нема вести - то је то, посао је стао.
План за рад са службом за сирочад
У ствари, ово је веома тешко урадити, јер се девопс односи на комуникацију. Желите да будете у добрим односима са својим колегама, а када ударите своје колеге и менаџере преко главе прописима, они могу имати супротстављена осећања према људима који то раде.
Поред свих ових тачака, постоји још једна важна ствар: одређени људи морају бити одговорни за сваку конкретну услугу, за сваки одређени део процедуре распоређивања. Када нема људи и морате привући неке друге људе да проуче целу ову ствар, постаје тешко.
Ако све ово није помогло, а ваш сервис за сирочад је и даље сироче, нико не жели да га преузме, документација није написана, тим који је позван у овај сервис одбија да уради било шта, постоји једноставан начин - поновити све .
Односно, поново преузимате захтеве за услугу и пишете нову услугу, бољу, на бољој платформи, без чудних технолошких решења. А ти мигрираш на то у борби.
Имали смо ситуацију када смо узели сервис на Иии 1 и схватили да не можемо даље да га развијамо, јер нам је понестало програмера који би могли добро да пишу на Иии 1. Сви програмери добро пишу на Симфони XNUMX. Шта да радим? Доделили смо време, доделили тим, доделили менаџера, преписали пројекат и глатко пребацили саобраћај на њега.
Након овога, стари сервис се може избрисати. Ово је мој омиљени поступак, када треба да узмете и очистите неки сервис из система за управљање конфигурацијом и онда прођете и видите да су сви аутомобили у производњи онемогућени, тако да програмерима не остане никакав траг. Репозиторијум остаје у Гиту.
Ово је све о чему сам желео да причам, спреман сам за дискусију, тема је холивар, многи су пливали у њој.
Слајдови су рекли да сте ујединили језике. Пример је била промена величине слика. Да ли је заиста потребно стриктно ограничити на један језик? Зато што би се промена величине слике у ПХП-у заправо могла урадити у Голангу.
У ствари, то је опционо, као и све праксе. Можда је у неким случајевима чак и непожељно. Али морате схватити да ако имате техничко одељење у компанији од 50 људи, 45 њих су ПХП специјалисти, још 3 су девопи који знају Питхон, Ансибле, Пуппет и тако нешто, а само један од њих пише у неком нека врста језика Го слике, онда када оде, стручност иде уз то. А у исто време, мораћете да потражите програмера специфичног за тржиште који зна овај језик, посебно ако је реткост. Односно, са организационе тачке гледишта, ово је проблематично. Са тачке гледишта девопс-а, нећете морати само да клонирате неки готов сет приручника који користите за примену услуга, већ ћете морати да их пишете изнова.
Тренутно градимо услугу на Ноде.јс, а ово ће бити само платформа у близини за сваког програмера са посебним језиком. Али седели смо и мислили да је игра вредна свеће. Односно, ово је питање за вас да седите и размислите.
Како надгледате своје услуге? Како прикупљате и надгледате дневнике?
Сакупљамо логове у Еластицсеарцх-у и стављамо их у Кибану, а у зависности од тога да ли је у питању производно или тестно окружење, тамо се користе различити колектори. Негде Дрвосеча, негде нешто друго, не сећам се. И још увек постоје места у одређеним сервисима где инсталирамо Телеграф и снимамо негде другде посебно.
Како живети са Пуппет-ом и Ансибле-ом у истом окружењу?
У ствари, сада имамо два окружења, једно је Пуппет, друго је Ансибле. Радимо на томе да их хибридизујемо. Ансибле је добар оквир за почетно подешавање, Пуппет је лош оквир за почетно подешавање јер захтева практични рад директно на платформи, а Пуппет обезбеђује конвергенцију конфигурације. То значи да се платформа одржава у ажурном стању, а да би ансибилизована машина била ажурирана, потребно је да на њој стално покрећете плаибоокс са одређеном фреквенцијом. То је разлика.
Како одржавате компатибилност? Да ли имате конфигурације у Ансиблеу и Пуппет-у?
Ово је наша велика мука, одржавамо компатибилност рукама и размишљамо како да сада негде да одемо даље. Испоставило се да Пуппет развија пакете и тамо одржава неке везе, а Ансибле, на пример, избацује код и прилагођава најновије конфигурације апликације.
Презентација је била о различитим верзијама Руби-а. Какво решење?
Са овим смо се сусрели на једном месту, и то морамо стално да држимо у глави. Једноставно смо искључили део који је радио на Руби-у који није компатибилан са апликацијама и држали га одвојеним.
Овогодишња конференција одржаће се 7. децембра у Технополису. Пријаве за извештаје примамо до 11. новембра. нас ако желите да говорите.
Пријаве за учеснике су отворене, придружите нам се!
Извор: ввв.хабр.цом