История за внедряване, която повлия на всичко

Врагове на реалността от 12f-2

В края на април, докато Белите пешеходци обсаждаха Winterfell, ни се случи нещо по-интересно; направихме необичайно внедряване. По принцип ние непрекъснато пускаме нови функции в производство (както всички останали). Но този беше различен. Мащабът беше такъв, че всички потенциални грешки, които бихме могли да направим, биха засегнали всички наши услуги и потребители. В резултат на това пуснахме всичко по план, в рамките на планирания и обявен период на престой, без последствия за продажбите. Статията е за това как постигнахме това и как всеки може да го повтори у дома.

Сега няма да описвам архитектурните и техническите решения, които взехме, нито как работи всичко. Това са по-скоро бележки в полетата за това как се случи едно от най-трудните внедрявания, което наблюдавах и в което участвах пряко. Не претендирам за изчерпателност или технически подробности, може би те ще се появят в друга статия.

Фон + каква функционалност е това?

Изграждаме облачна платформа Облачни решения на Mail.ru (MCS), където работя като технически директор. И сега е време да добавим IAM (Управление на самоличността и достъпа) към нашата платформа, която осигурява унифицирано управление на всички потребителски акаунти, потребители, пароли, роли, услуги и др. Защо е необходим в облака е очевиден въпрос: цялата потребителска информация се съхранява в него.

Обикновено такива неща започват да се изграждат в самото начало на всякакви проекти. Но исторически нещата са били малко по-различни в MCS. MCS е изграден в две части:

• Openstack със собствен модул за оторизация Keystone,
• Hotbox (S3 хранилище), базирано на проекта Mail.ru Cloud,

около които след това се появиха нови услуги.

По същество това бяха два различни вида разрешение. Освен това използвахме някои отделни разработки на Mail.ru, например общо съхранение на пароли за Mail.ru, както и самонаписан openid конектор, благодарение на който SSO (оторизация от край до край) беше осигурено в панела Horizon на виртуални машини (собствен потребителски интерфейс на OpenStack).

Създаването на IAM за нас означаваше да свържем всичко в една система, напълно наша собствена. В същото време няма да загубим никаква функционалност по пътя, но ще създадем основа за бъдещето, която ще ни позволи прозрачно да я прецизираме без рефакторинг и да я мащабираме по отношение на функционалността. Също така в началото потребителите имаха модел за подражание за достъп до услуги (централен RBAC, ролеви контрол на достъпа) и някои други малки неща.

Задачата се оказа нетривиална: python и perl, няколко бекенда, независимо написани услуги, няколко екипа за разработка и администратори. И най-важното, има хиляди потребители на живо в системата за бойно производство. Всичко това трябваше да се напише и най-важното да се разгърне без жертви.

Какво ще пуснем?

Най-грубо казано, за около 4 месеца подготвихме следното:

• Създадохме няколко нови демона, които обединиха функции, които преди това работеха в различни части на инфраструктурата. На останалите услуги беше предписан нов бекенд под формата на тези демони.
• Написахме собствено централно хранилище на пароли и ключове, достъпно за всички наши услуги, което може да бъде свободно модифицирано според нуждите ни.
• Написахме 4 нови бекенда за Keystone от нулата (потребители, проекти, роли, присвояване на роли), които всъщност замениха неговата база данни и сега действат като едно хранилище за нашите потребителски пароли.
• Научихме всички наши услуги на Openstack да отиват в услуга за правила на трета страна за своите политики, вместо да четат тези политики локално от всеки сървър (да, така работи Openstack по подразбиране!)

Такава голяма преработка изисква големи, сложни и най-важното синхронни промени в няколко системи, написани от различни екипи за разработка. Веднъж сглобена, цялата система трябва да работи.

Как да внедрите такива промени и да не го прецакате? Първо решихме да погледнем малко в бъдещето.

Стратегия за внедряване

• Би било възможно продуктът да бъде пуснат на няколко етапа, но това ще увеличи времето за разработка три пъти. Освен това за известно време щяхме да имаме пълна десинхронизация на данните в базите данни. Ще трябва да напишете свои собствени инструменти за синхронизиране и да живеете с множество хранилища за данни дълго време. И това създава голямо разнообразие от рискове.
• Всичко, което можеше да се подготви прозрачно за потребителя, беше направено предварително. Отне 2 месеца.
• Позволихме си престой за няколко часа - само за потребителски операции за създаване и промяна на ресурси.
• За работата на всички вече създадени ресурси престоят беше неприемлив. Планирахме, че по време на внедряването ресурсите трябва да работят без прекъсване и да влияят на клиентите.
• За да намалим въздействието върху нашите клиенти, ако нещо се обърка, решихме да пуснем в неделя вечерта. По-малко клиенти управляват виртуални машини през нощта.
• Предупредихме всички наши клиенти, че през периода, избран за внедряване, управлението на услугата няма да бъде достъпно.

Отклонение: какво е внедряване?

<внимание, философия>

Всеки IT специалист може лесно да отговори какво е rollout. Инсталирате CI/CD и всичко автоматично се доставя в магазина. 🙂

Разбира се това е вярно. Но трудността е, че със съвременните инструменти за автоматизиране на доставката на код се губи разбирането за самото внедряване. Как забравяш за епичността на изобретяването на колелото, когато гледаш съвременния транспорт. Всичко е толкова автоматизирано, че внедряването често се извършва без разбиране на цялата картина.

И цялата картина е такава. Разпространението се състои от четири основни аспекта:

1. Доставка на код, включително промяна на данни. Например техните миграции.
2. Връщането на кода е способността да се върнете назад, ако нещо се обърка. Например чрез създаване на резервни копия.
3. Време на всяка операция за пускане/връщане назад. Трябва да разберете времето на всяка операция от първите две точки.
4. Засегната функционалност. Необходимо е да се оценят както очакваните положителни, така и възможните отрицателни ефекти.

Всички тези аспекти трябва да бъдат взети под внимание за успешно внедряване. Обикновено се оценява само първата или в най-добрия случай втората точка и след това внедряването се счита за успешно. Но третото и четвъртото са още по-важни. На кой потребител би му харесало, ако внедряването отне 3 часа вместо минута? Или ако нещо ненужно бъде засегнато по време на внедряването? Или прекъсването на една услуга ще доведе до непредвидими последици?

Акт 1..н, подготовка за освобождаване

Първоначално се сетих да опиша накратко нашите срещи: целият екип, неговите части, купища дискусии по кафенета, спорове, тестове, брейнсторминг. Тогава си помислих, че е излишно. Четири месеца разработка винаги се състои от това, особено когато не пишете нещо, което може да се доставя постоянно, а една голяма функция за жива система. Което засяга всички услуги, но нищо не трябва да се променя за потребителите, освен „един бутон в уеб интерфейса“.

Нашето разбиране за това как да внедрим се промени от всяка нова среща и то доста значително. Например, щяхме да актуализираме цялата ни база данни за фактуриране. Но изчислихме времето и осъзнахме, че е невъзможно да направим това в разумен срок за внедряване. Отне ни почти допълнителна седмица, за да разделим и архивираме базата данни за таксуване. И когато очакваната скорост на внедряване все още не беше задоволителна, поръчахме допълнителен, по-мощен хардуер, където цялата база беше влачена. Не че не искахме да направим това по-рано, но текущата нужда от внедряване ни остави без възможности.

Когато един от нас имаше съмнения, че внедряването може да повлияе на наличността на нашите виртуални машини, прекарахме седмица в провеждане на тестове, експерименти, анализ на код и получихме ясното разбиране, че това няма да се случи в нашата продукция и дори най-съмнителните хора се съгласиха с тази.

Междувременно момчетата от техническата поддръжка проведоха свои собствени независими експерименти, за да напишат инструкции за клиенти относно методите на свързване, които трябваше да се променят след пускането. Те работиха върху потребителския UX, подготвиха инструкции и предоставиха лични консултации.

Ние автоматизирахме всички операции по внедряване, които бяха възможни. Всяка операция беше скриптирана, дори и най-простите, и непрекъснато се провеждаха тестове. Те спореха за най-добрия начин да изключат услугата - да пропуснат демона или да блокират достъпа до услугата със защитна стена. Създадохме контролен списък с екипи за всеки етап от внедряването и го актуализирахме постоянно. Начертахме и постоянно актуализирахме диаграма на Гант за цялата работа по внедряването, с времена.

И така…

Последният акт, преди да излезе

...време е за разгръщане.

Както се казва, едно произведение на изкуството не може да бъде завършено, а само да се работи върху него. Трябва да положите усилие на волята, разбирайки, че няма да намерите всичко, но вярвайки, че сте направили всички разумни предположения, предвидили сте всички възможни случаи, затворили сте всички критични грешки и всички участници са направили всичко по силите си. Колкото повече код разгръщате, толкова по-трудно е да се убедите в това (освен това всеки разбира, че е невъзможно да се предвиди всичко).

Решихме, че сме готови за внедряване, когато се убедихме, че сме направили всичко възможно, за да покрием всички рискове за нашите потребители, свързани с неочаквани ефекти и прекъсвания. Тоест всичко може да се обърка освен:

1. Засяга (свещена за нас, най-ценна) потребителска инфраструктура,
2. Функционалност: използването на нашата услуга след въвеждането трябва да бъде същото, както преди.

Разточване

Две ролки, 8 не пречат

Ние вземаме престой за всички заявки от потребители за 7 часа. В момента имаме както план за внедряване, така и план за връщане назад.

• Самото внедряване отнема приблизително 3 часа.
• 2 часа за тестване.
• 2 часа - резерв за евентуално връщане назад на промените.

За всяко действие е съставена диаграма на Гант, колко време отнема, какво се случва последователно, какво се прави паралелно.

Част от разпространена диаграма на Гант, една от ранните версии (без паралелно изпълнение). Най-ценният инструмент за синхронизация

Всички участници имат определена роля в внедряването, какви задачи изпълняват и за какво отговарят. Опитваме се да доведем всеки етап до автоматизъм, да го разгърнем, да го върнем обратно, да съберем обратна връзка и да го разгърнем отново.

Хроника на събитията

И така, 15 души дойдоха на работа в неделя, 29 април, в 10 часа. Освен ключовите участници, някои дойдоха просто да подкрепят отбора, за което им благодаря.

Също така си струва да споменем, че нашият тестер на ключове е на почивка. Невъзможно е да се разпространи без тестване, ние проучваме опциите. Една колежка се съгласи да ни тества от почивката, за което получава огромни благодарности от целия екип.

00:00 часа. Спри се
Спираме потребителски заявки, окачваме табела с надпис техническа работа. Мониторингът пищи, но всичко е нормално. Проверяваме дали не е паднало нищо друго освен това, което е трябвало да падне. И започваме работа по миграцията.

Всеки има разпечатан план за разгръщане точка по точка, всеки знае кой какво прави и в кой момент. След всяко действие проверяваме времената, за да сме сигурни, че не ги превишаваме и всичко върви по план. Тези, които не участват директно в пускането на настоящия етап, се подготвят, като пуснат онлайн играчка (Xonotic, тип 3 quacks), за да не пречат на колегите си. 🙂

02:00 часа. Разточени
Приятна изненада - завършваме внедряването час по-рано, поради оптимизацията на нашите бази данни и миграционни скриптове. Общият вик „разтъркаля се!“ Всички нови функции са в производство, но засега само ние можем да ги видим в интерфейса. Всички влизат в режим на тестване, сортират ги в групи и започват да виждат какво се е случило в крайна сметка.

Не се получи много добре, разбираме това след 10 минути, когато нищо не е свързано или работи в проектите на членовете на екипа. Бърза синхронизация, изразяваме проблемите си, определяме приоритети, разделяме се на екипи и преминаваме към отстраняване на грешки.

02:30 часа. Два големи проблема срещу четири очи
Откриваме два големи проблема. Разбрахме, че клиентите няма да видят някои свързани услуги и ще възникнат проблеми с партньорските акаунти. И двете се дължат на несъвършени скриптове за миграция за някои крайни случаи. Трябва да го поправим сега.

Ние пишем заявки, които записват това, с поне 4 очи. Тестваме ги по време на предварителна продукция, за да сме сигурни, че работят и няма да счупят нищо. Можете да се търкаляте. В същото време провеждаме нашите редовни интеграционни тестове, които разкриват още няколко проблема. Всички са малки, но и те трябва да се ремонтират.

03:00 часа. -2 проблема +2 проблема
Двата предишни големи проблема са отстранени, както и почти всички дребни. Всички тези, които не са заети с корекции, работят активно в своите акаунти и докладват какво са открили. Приоритизираме, разпределяме между екипите и оставяме некритичните неща за сутринта.

Провеждаме тестовете отново, те откриват два нови големи проблема. Не всички правила за услугата са пристигнали правилно, така че някои потребителски заявки не преминават оторизация. Плюс нов проблем с партньорските сметки. Да се ​​втурнем да търсим.

03:20 часа. Спешна синхронизация
Отстранен е един нов проблем. За втория организираме спешна синхронизация. Разбираме какво се случва: предишната корекция отстрани един проблем, но създаде друг. Правим почивка, за да разберем как да го направим правилно и без последствия.

03:30 часа. Шест очи
Разбираме какво трябва да бъде крайното състояние на базата, така че всичко да върви добре за всички партньори. Пишем заявка с 6 очи, разгръщаме я в предварителна продукция, тестваме я, разгръщаме я за производство.

04:00 часа. Всичко работи
Всички тестове преминаха, не се виждат критични проблеми. От време на време нещо в екипа не работи за някого, реагираме своевременно. Най-често алармата е фалшива. Но понякога нещо не пристига или отделна страница не работи. Седим, оправяме, оправяме, оправяме. Отделен екип стартира последната голяма функция - таксуването.

04:30 часа. Точка от която няма връщане
Точката, от която няма връщане, наближава, тоест времето, когато, ако започнем да се връщаме назад, няма да изпълним времето за престой, което ни е дадено. Има проблеми с билинга, който знае и записва всичко, но упорито отказва да отписва пари от клиенти. Има няколко грешки на отделни страници, действия и състояния. Основната функционалност работи, всички тестове преминават успешно. Решаваме, че внедряването е извършено, няма да се върнем назад.

06:00 часа. Отворено за всички в потребителския интерфейс
Поправени грешки. Някои, които не се харесват на потребителите, са оставени за по-късно. Ние отваряме интерфейса за всички. Продължаваме да работим по таксуването, в очакване на обратна връзка от потребителите и резултати от мониторинг.

07:00 часа. Проблеми със зареждането на API
Става ясно, че малко погрешно сме планирали натоварването на нашия API и тествахме това натоварване, което не можа да идентифицира проблема. В резултат на това ≈5% от заявките са неуспешни. Да се ​​мобилизираме и да търсим причината.

Таксуването е упорито и също не иска да работи. Решаваме да го отложим за по-късно, за да извършим промените по спокоен начин. Тоест всички ресурси се натрупват в него, но отписванията от клиенти не преминават. Разбира се, това е проблем, но в сравнение с общото внедряване изглежда маловажен.

08:00 часа. Коригирайте API
Пуснахме корекция за товара, грешките изчезнаха. Започваме да се прибираме.

10:00 часа. всичко
Всичко е оправено. При наблюдението е тихо и при клиентите екипът постепенно заспива. Таксуването остава, утре ще го възстановим.

След това през деня имаше внедрявания, които коригираха регистрационни файлове, известия, кодове за връщане и персонализации за някои от нашите клиенти.

И така, внедряването беше успешно! Може, разбира се, да е по-добре, но направихме изводи какво не ни достига, за да постигнем съвършенство.

Общо

По време на 2 месеца активна подготовка за внедряването бяха изпълнени 43 задачи с продължителност от няколко часа до няколко дни.

По време на разпространение:

• нови и променени демони - 5 броя, заместващи 2 монолита;
• промени в базите данни - засегнати са всичките ни 6 бази данни с потребителски данни, направени са изтегляния от три стари бази данни към една нова;
• напълно преработен интерфейс;
• количество изтеглен код - 33 хиляди реда нов код, ≈ 3 хиляди реда код в тестове, ≈ 5 хиляди реда код за миграция;
• всички данни са непокътнати, нито една виртуална машина на клиент не е повредена. 🙂

Добри практики за добро внедряване

Те ни насочиха в тази трудна ситуация. Но най-общо казано е полезно да ги следвате по време на всяко внедряване. Но колкото по-сложно е внедряването, толкова по-голяма е ролята, която играят.

1. Първото нещо, което трябва да направите, е да разберете как внедряването може или ще засегне потребителите. Ще има ли престой? Ако е така, какъв е престой? Как ще се отрази това на потребителите? Кои са възможните най-добри и най-лоши сценарии? И покриване на рисковете.
2. Планирайте всичко. На всеки етап трябва да разбирате всички аспекти на внедряването:
   • доставка на кодове;
   • връщане на код;
   • време на всяка операция;
   • засегната функционалност.
3. Играйте през сценариите, докато всички етапи на внедряването, както и рисковете при всеки от тях станат очевидни. Ако имате някакви съмнения, можете да си направите почивка и да разгледате отделно съмнителния етап.
4. Всеки етап може и трябва да бъде подобрен, ако помага на нашите потребители. Например, това ще намали времето за престой или ще премахне някои рискове.
5. Тестването за връщане е много по-важно от тестването за доставка на код. Необходимо е да се провери дали в резултат на връщането системата ще се върне в първоначалното си състояние и потвърдете това с тестове.
6. Всичко, което може да бъде автоматизирано, трябва да бъде автоматизирано. Всичко, което не може да бъде автоматизирано, трябва да бъде написано предварително на лист за измама.
7. Запишете критерия за успех. Каква функционалност трябва да е налична и по кое време? Ако това не се случи, изпълнете план за връщане назад.
8. И най-важното – хората. Всеки трябва да е наясно какво прави, защо и какво зависи от действията му в процеса на внедряване.

И с едно изречение, с добро планиране и разработка можете да пуснете всичко, което искате, без последствия за продажбите. Дори нещо, което ще засегне всичките ви услуги в производството.

Източник: www.habr.com