Директорот за операции на порталот Banki.ru Андреј Николски зборуваше на минатогодишната конференција за услугите за деца без родители: како да се идентификува сираче во инфраструктурата, зошто услугите за сираци се лоши, што да се прави со нив и што да се прави ако ништо не помага.
Под резот е текстуална верзија на извештајот.
Здраво колеги! Јас се викам Андреј, раководам со операции на Banki.ru.
Имаме големи сервиси, тоа се такви монолитни услуги, има услуги во покласична смисла, а има и многу мали. Во мојата работничко-селанска терминологија велам дека ако услугата е едноставна и мала, тогаш е микро, а ако не е многу едноставна и мала, тогаш е само услуга.
Добрите страни на услугите
Брзо ќе ги разгледам предностите на услугите.
Првиот е скалирање. Можете брзо да направите нешто на услугата и да започнете со производство. Добивте сообраќај, ја клониравте услугата. Имате повеќе сообраќај, го клониравте и живеете со него. Ова е добар бонус и, во принцип, кога почнавме, ни се сметаше за најважно, зошто го правиме сето ова.
Второ, изолиран развој, кога имате неколку развојни тимови, неколку различни програмери во секој тим и секој тим развива своја услуга.
Кај тимовите има нијанса. Програмерите се различни. И има, на пример, . Ова првпат го видов со Максим Дорофеев. Понекогаш луѓето со снегулки се во некои тимови, а не на други. Ова ги прави различните услуги што се користат низ компанијата малку нерамномерни.
Погледнете ја сликата: ова е добар развивач, има големи раце, може многу. Главниот проблем е од каде доаѓаат овие раце.
Услугите овозможуваат користење на различни програмски јазици кои се посоодветни за различни задачи. Некои услуги се во Go, некои во Erlang, некои во Ruby, нешто во PHP, нешто во Python. Во принцип, можете да се проширите многу широко. Тука има и нијанси.
Сервисно ориентирана архитектура првенствено се однесува на devops. Односно, ако немате автоматизација, нема процес на распоредување, ако го конфигурирате рачно, вашите конфигурации може да се менуваат од пример на услуга до пример, и мора да одите таму за да направите нешто, тогаш сте во пеколот.
На пример, имате 20 услуги и треба да се распоредите рачно, имате 20 конзоли и истовремено притискате „ентер“ како нинџа. Не е многу добро.
Ако имаш сервис после тестирање (ако има тестирање, се разбира), а сепак треба да го завршиш со датотека за да работи во продукција, имам и лоши вести за тебе.
Ако се потпирате на специфични услуги на Амазон и работите во Русија, тогаш пред два месеци имавте и „Сè наоколу гори, добро сум, сè е кул“.
Ние користиме Ansible за автоматизирање на распоредувањето, кукла за конвергенција, Bamboo за автоматизирање на распоредувањето и Confluence за некако да го опишеме сето ова.
Нема да се задржувам на ова детално, бидејќи извештајот повеќе се однесува на практиките на интеракција, а не на техничката имплементација.
На пример, имавме проблеми каде Puppet на серверот работи со Ruby 2, но некоја апликација е напишана за Ruby 1.8 и тие не работат заедно. Нешто не е во ред таму. И кога треба да извршите повеќе верзии на Ruby на една машина, обично почнувате да имате проблеми.
На пример, на секој развивач му даваме платформа на која има приближно сè што имаме, сите услуги што можат да се развијат, за да има изолирана средина, да може да ја скрши и да ја гради како што сака.
Се случува да ви треба некој специјално компајлиран пакет со поддршка за нешто таму. Тоа е доста тешко. Слушнав извештај каде што сликата на Docker тежи 45 GB. Во Linux, се разбира, тоа е поедноставно, сè е помало таму, но сепак, нема да има доволно простор.
Па, постојат конфликтни зависности, кога еден дел од проектот зависи од библиотека на една верзија, друг дел од проектот зависи од друга верзија, а библиотеките воопшто не се инсталирани заедно.
Имаме сајтови и сервиси во PHP 5.6, се срамиме од нив, но што да правиме? Ова е нашата единствена страница. Има сајтови и сервиси на PHP 7, ги има повеќе, не се срамиме од нив. И секој развивач има своја база каде што со задоволство гледа.
Ако пишувате во компанија на еден јазик, тогаш три виртуелни машини по развивач звучат нормално. Ако имате различни програмски јазици, тогаш ситуацијата се влошува.
Имате сајтови и услуги на ова, на ова, потоа друга страница за Go, една локација за Руби и некои други Redis на страна. Како резултат на тоа, сето ова се претвора во големо поле за поддршка и цело време дел од него може да се скрши.
Затоа, ги заменивме придобивките од програмскиот јазик со употреба на различни рамки, бидејќи PHP рамки се сосема различни, тие имаат различни способности, различни заедници и различна поддршка. И можете да напишете услуга, така што веќе имате нешто подготвено за тоа.
Секоја услуга има свој тим
Нашата главна предност, која се кристализираше во текот на неколку години, е тоа што секој сервис има свој тим. Ова е погодно за голем проект, можете да заштедите време на документација, менаџерите добро го знаат нивниот проект.
Можете лесно да поднесувате задачи од поддршката. На пример, услугата за осигурување се расипа. И веднаш тимот што се занимава со осигурување оди да го поправи.
Новите функции се создаваат брзо, затоа што кога имате една атомска услуга, можете брзо да навртувате нешто во неа.
И кога ќе ја прекинете вашата услуга, а тоа неизбежно се случува, вие не влијаевте на услугите на другите луѓе, а програмерите со делови од други тимови не доаѓаат кај вас и не ви велат: „О, не го прави тоа“.
Како и секогаш, има нијанси. Имаме стабилни тимови, менаџерите се приковани за тимот. Има јасни документи, менаџерите внимателно следат сè. Секој тим со менаџер има неколку услуги и има одредена точка на компетентност.
Ако тимовите лебдат (исто така понекогаш го користиме ова), постои добар метод наречен „мапа на ѕвезди“.
Имате список на услуги и луѓе. Ѕвездичка значи дека лицето е експерт за оваа услуга, книга значи дека лицето ја проучува оваа услуга. Задачата на лицето е да ја смени брошурата со ѕвездичка. И ако ништо не е напишано пред сервисот, тогаш започнуваат проблемите, за кои ќе зборувам понатаму.
Како се појавуваат услугите за сираци?
Првиот проблем, првиот начин да добиете услуга за сираци во вашата инфраструктура е да отпуштите луѓе. Дали некогаш некој бизнис ги исполнува роковите пред да се проценат задачите? Понекогаш се случува роковите да се тесни и едноставно да нема доволно време за документација. „Треба да ја предадеме услугата на производство, а потоа ќе ја додадеме“.
Ако тимот е мал, се случува да има еден развивач кој пишува сè, а останатите се во крилата. „Ја напишав основната архитектура, ајде да ги додадеме интерфејсите“. Тогаш во одреден момент менаџерот, на пример, заминува. И во овој период, кога менаџерот си замина и се уште не е назначен нов, самите програмери одлучуваат каде оди услугата и што се случува таму. И како што знаеме (да се вратиме неколку слајдови наназад), во некои тимови има луѓе со снегулки, понекогаш води тим од снегулки. Потоа тој дава отказ, а ние добиваме услуга за сираци.
Во исто време, задачите од поддршката и од бизнисот не исчезнуваат, тие завршуваат во заостанатиот дел. Доколку имало некакви архитектонски грешки при развојот на услугата, тие исто така завршуваат во заостанатото. Услугата полека се влошува.
Како да препознаете сирак?
Оваа листа добро ја опишува ситуацијата. Кој научи нешто за нивната инфраструктура?
За документираните решенија: има услуга и, генерално, работи, има прирачник на две страници како да се работи со него, но никој не знае како работи внатре.
Или, на пример, постои некој вид скратувач на врски. На пример, во моментов имаме три скратувачи на врски кои се користат за различни намени во различни услуги. Ова се само последиците.
Сега ќе бидам капетан на очигледното. Што треба да се направи? Прво, треба да ја пренесеме услугата на друг менаџер, друг тим. Ако лидерот на вашиот тим сè уште не се откажал, тогаш во овој друг тим, кога ќе разберете дека услугата е како сирак, треба да вклучите некој што разбира барем нешто за тоа.
Главната работа: мора да ги имате процедурите за трансфер напишани со крв. Во нашиот случај, јас обично го надгледувам ова, бидејќи ми треба сето тоа за да функционира. На менаџерите им е потребно брзо да се испорача, а што ќе се случи со него подоцна веќе не им е толку важно.
Следниот начин да се направи сираче е „Ќе го направиме тоа преку аутсорсинг, ќе биде побрзо, а потоа ќе му го предадеме на тимот“. Јасно е дека секој има некакви планови во тимот, пресврт. Често деловниот клиент мисли дека аутсорсерот ќе го направи истото како и техничкиот оддел што го има компанијата. Иако нивните мотиватори се различни. Има чудни технолошки решенија и чудни алгоритамски решенија во аутсорсингот.
На пример, имавме услуга која имаше Сфинкс на различни неочекувани места. Подоцна ќе ви кажам што требаше да направам.
Нарачателите имаат само-напишани рамки. Ова е само гол PHP со copy-paste од претходниот проект, каде што можете да најдете секакви работи. Скриптите за распоредување се голем недостаток кога треба да користите некои сложени Bash скрипти за да промените неколку линии во некоја датотека, а овие скрипти за распоредување се повикуваат со некоја трета скрипта. Како резултат на тоа, го менувате системот за распоредување, избирате нешто друго, скокате, но вашата услуга не работи. Затоа што таму требаше да се стават уште 8 врски помеѓу различни папки. Или се случува илјада плочи да работат, но сто илјади повеќе да не работат.
Ќе продолжам да бидам капитен. Прифаќањето на аутсорсинг услуга е задолжителна процедура. Дали некој некогаш имал аутсорсинг услуга да пристигне и да не биде прифатен никаде? Ова не е толку популарно, се разбира, како услуга за сирачиња, но сепак.
Треба да се провери услугата, да се прегледа услугата, да се сменат лозинките. Имавме случај кога ни дадоа услуга, има административен панел „ако се најавите == 'администратор' && лозинка == 'админ'...“, пишува право во кодот. Седиме и размислуваме, а луѓето го пишуваат ова во 2018 година?
Тестирањето на капацитетот за складирање е исто така неопходна работа. Треба да погледнете што ќе се случи на сто илјади плочи, дури и пред да ја ставите оваа услуга некаде во производство.
Не треба да има срам да се испрати услуга за подобрување. Кога ќе кажете: „Нема да ја прифатиме оваа услуга, имаме 20 задачи, направете ги, тогаш ќе прифатиме“, тоа е нормално. Совеста не треба да ве боли поради тоа што поставувате менаџер или дека бизнисот троши пари. Бизнисот тогаш ќе потроши повеќе.
Имавме случај кога решивме да нарачаме пилот проект.
Беше испорачан навреме, а тоа беше единствениот критериум за квалитет. Затоа направивме уште еден пилот проект, кој веќе не беше ни навистина пилот. Овие услуги беа прифатени, и преку административни средства рекоа, еве ви го кодот, еве го тимот, еве го вашиот менаџер. Услугите всушност веќе почнаа да остваруваат профит. Во исто време, всушност, тие сè уште се сираци, никој не разбира како работат, а менаџерите даваат се од себе за да се одречат од нивните задачи.
Постои уште еден одличен концепт - герилски развој. Кога некој оддел, вообичаено одделот за маркетинг, сака да тестира хипотеза и наредува аутсорсинг на целата услуга. Сообраќајот почнува да се влева во него, ги затвораат документите, потпишуваат документи со изведувачот, влегуваат во функција и велат: „Други, тука имаме услуга, веќе има сообраќај, ни носи пари, ајде да прифатиме“. Бевме како: „Опа, како може тоа да биде“.
И уште еден начин да се добие услуга за сираци: кога некој тим одеднаш ќе се најде натоварен, раководството вели: „Да ја пренесеме услугата на овој тим на друг тим, тој има помал товар“. А потоа ќе го пренесеме на трет тим и ќе го смениме менаџерот. И на крајот повторно имаме сирак.
Што е проблемот со сирачињата?
Кој не знае, ова е борбениот брод Васа подигнат во Шведска, познат по тоа што потона 5 минути по лансирањето. И кралот на Шведска, патем, не погуби никого за ова. Го изградиле две генерации инженери кои не знаеле како да градат такви бродови. Природен ефект.
Бродот можеше да потоне, патем, на многу полош начин, на пример, кога кралот веќе се возел на него некаде во бура. И така, веднаш се удави, според Агил, добро е да се пропадне рано.
Ако не успееме рано, обично нема проблеми. На пример, за време на прифаќањето беше испратен на ревизија. Но, ако веќе не успееме во производството, кога се вложуваат пари, тогаш може да има проблеми. Последици, како што се нарекуваат во бизнисот.
Зошто услугите за сирачиња се опасни:
- Услугата може ненадејно да се прекине.
- Сервисот трае долго време за да се поправи или воопшто не се поправа.
- Безбедносни проблеми.
- Проблеми со подобрувања и ажурирања.
- Ако некоја важна услуга се расипе, угледот на компанијата страда.
Што да се прави со услугите за сирачиња?
Ќе повторам што да правам повторно. Прво, мора да има документација. 7 години на Banki.ru ме научија дека тестерите не треба да го прифаќаат зборот на програмерите, а операциите не треба да го слушаат зборот на сите. Треба да провериме.
Второ, потребно е да се напишат дијаграми за интеракција, бидејќи се случува услугите кои не се многу добро примени да содржат зависности за кои никој не кажа. На пример, програмерите ја инсталираа услугата на нивниот клуч за некои Yandex.Maps или Datata. Снемавте бесплатен лимит, сè е скршено и воопшто не знаете што се случило. Сите такви гребла мора да бидат опишани: услугата користи податоци, СМС, нешто друго.
Трето, работа со технички долг. Кога правите некакви патерици или прифаќате услуга и велите дека нешто треба да се направи, треба да бидете сигурни дека тоа е направено. Затоа што тогаш може да испадне дека малата дупка не е толку мала и ќе паднете низ неа.
Со архитектонски задачи имавме приказна за Сфингата. Една од услугите користеше Sphinx за внесување списоци. Само пагинирана листа, но таа беше повторно индексирана секоја вечер. Се составуваше од два индекса: по еден голем се индексираше секоја вечер, а имаше и мал индекс што се навртуваше на него. Секој ден, со 50% веројатност за бомбардирање или не, индексот паѓаше за време на пресметката, а нашите вести престанаа да се ажурираат на главната страница. На почетокот беа потребни 5 минути за повторно да се индексира индексот, потоа индексот порасна, а во одреден момент почна да трае 40 минути за повторно да се индексира. Кога го прекинавме ова, здивнавме, бидејќи беше јасно дека ќе помине уште малку време и нашиот индекс повторно ќе се индексира со полно работно време. Ова ќе биде неуспех за нашиот портал, осум часа нема новости - тоа е тоа, работата запре.
План за работа со служба за сираци
Всушност, ова е многу тешко да се направи, бидејќи devops е за комуникација. Сакате да бидете во добри односи со вашите колеги, а кога ќе ги удирате колегите и менаџерите по глава со прописи, тие може да имаат конфликтни чувства кон оние луѓе кои го прават тоа.
Покрај сите овие точки, има уште една важна работа: конкретни луѓе мора да бидат одговорни за секоја конкретна услуга, за секој конкретен дел од процедурата за распоредување. Кога нема луѓе и треба да привлечеш некои други луѓе, да ја проучуваш целата оваа работа, станува тешко.
Ако сето ова не помогна, а вашата услуга за сирачиња е сè уште сираче, никој не сака да ја преземе, документацијата не е напишана, тимот што бил повикан во оваа услуга одбива да стори ништо, постои едноставен начин - да се повтори сè.
Односно, ги преземате барањата за услугата одново и пишувате нова услуга, подобра, на подобра платформа, без чудни технолошки решенија. И мигрирате во неа во битка.
Имавме ситуација кога земавме услуга на Yii 1 и сфативме дека не можеме да ја развиваме понатаму, бидејќи останавме без програмери кои можеа добро да пишуваат на Yii 1. Сите програмери пишуваат добро на Symfony XNUMX. Што да се прави? Одвоивме време, доделивме тим, доделивме менаџер, го преработивме проектот и непречено го префрливме сообраќајот кон него.
По ова, старата услуга може да се избрише. Ова е мојата омилена процедура, кога треба да земете и исчистите некоја услуга од системот за управување со конфигурации, а потоа да поминете и да видите дека сите автомобили во производство се оневозможени, за да не останат траги на програмерите. Складиштето останува во Git.
Ова е сè за што сакав да зборувам, подготвен сум да разговарам, темата е холивар, многумина пливаа во неа.
Слајдовите кажаа дека ги обединивте јазиците. Пример беше промената на големината на сликите. Дали е навистина потребно строго да се ограничи на еден јазик? Бидејќи промената на големината на сликата во PHP, всушност, може да се направи во Golang.
Всушност, тоа е опционално, како и сите практики. Можеби, во некои случаи, тоа е дури и непожелно. Но, треба да разберете дека ако имате технички оддел во компанија од 50 луѓе, 45 од нив се специјалисти за PHP, други 3 се devops кои знаат Python, Ansible, Puppet и нешто слично, а само еден од нив пишува во некои некој вид јазик.некоја услуга за промена на големината на сликата Go, а потоа кога ќе замине, стручноста оди со неа. И во исто време, ќе треба да барате развивач специфичен за пазарот кој го знае овој јазик, особено ако е редок. Односно, од организациски аспект ова е проблематично. Од гледна точка на devops, нема да треба само да клонирате некои готови сет на книги за играње што ги користите за распоредување услуги, туку ќе треба да ги напишете одново.
Во моментов градиме услуга на Node.js и ова ќе биде само платформа во близина за секој развивач со посебен јазик. Но, седевме и мислевме дека играта вреди за свеќата. Односно, ова е прашање за кое треба да седите и да размислите.
Како ги следите вашите услуги? Како ги собирате и надгледувате дневниците?
Во Elasticsearch собираме трупци и ги ставаме во Кибана, а во зависност од тоа дали се работи за производствени или тест околини, таму се користат различни колектори. Некаде дрвосечач, некаде на друго нешто, не се сеќавам. Сè уште има некои места во одредени сервиси каде што инсталираме Телеграф и снимаме на друго место одделно.
Како да се живее со Кукла и Ансибл во иста средина?
Всушност, сега имаме две средини, едната е кукла, другата е Ансибл. Работиме на нивна хибридизација. Ansible е добра рамка за почетно поставување, Puppet е лоша рамка за почетно поставување бидејќи бара практична работа директно на платформата, а Puppet обезбедува конфигурација на конвергенција. Ова значи дека платформата се одржува во ажурирана состојба, а за да може ансибилизираната машина да биде ажурирана, треба постојано да пуштате книги за репродукција на неа со одредена фреквенција. Тоа е разликата.
Како ја одржувате компатибилноста? Дали имате конфигурации и во Ansible и во Puppet?
Ова е нашата голема болка, ја одржуваме компатибилноста со рацете и размислуваме како да продолжиме од сето ова некаде сега. Излегува дека Puppet објавува пакети и одржува некои врски таму, а Ansible, на пример, го објавува кодот и ги прилагодува најновите конфигурации на апликациите таму.
Презентацијата беше за различни верзии на Руби. Какво решение?
Ова го сретнавме на едно место и мораме постојано да го чуваме во нашите глави. Едноставно го исклучивме делот што работеше на Ruby кој беше некомпатибилен со апликациите и го задржавме одвоено.
Конференцијата оваа година ќе се одржи на 7 декември во Технополис. Пријавите за пријави примаме до 11 ноември. нас ако сакате да зборуваме.
Пријавувањето за учесници е отворено, придружете ни се!
Извор: www.habr.com