со 12f-2
На крајот на април, додека White Walkers го опседнуваа Винтерфел, ни се случи нешто поинтересно; направивме необично ширење. Во принцип, ние постојано воведуваме нови функции во производство (како и сите други). Но, оваа беше поинаква. Неговиот обем беше таков што сите потенцијални грешки што би можеле да ги направиме би влијаеле на сите наши услуги и корисници. Како резултат на тоа, воведовме сè според планот, во планираниот и најавениот период на застој, без последици по продажбата. Статијата е за тоа како го постигнавме ова и како секој може да го повтори дома.
Сега нема да ги опишам архитектонските и техничките одлуки што ги донесовме или да кажам како функционира сето тоа. Ова се прилично забелешки на маргините за тоа како се случи едно од најтешките пуштања, што го набљудував и во кое бев директно вклучен. Не тврдам комплетност или технички детали; можеби тие ќе се појават во друга статија.
Позадина + каква функционалност е ова?
Градиме облак платформа (MCS), каде што работам како технички директор. И сега е време да го додадеме IAM (Управување со идентитет и пристап) на нашата платформа, која обезбедува унифицирано управување со сите кориснички сметки, корисници, лозинки, улоги, услуги и многу повеќе. Зошто е потребно во облакот е очигледно прашање: сите кориснички информации се зачувани во него.
Обично таквите работи почнуваат да се градат на самиот почеток на какви било проекти. Но, историски работите беа малку поинакви во MCS. MCS беше изграден во два дела:
- Openstack со сопствен модул за авторизација Keystone,
- Hotbox (складирање S3) врз основа на проектот Mail.ru Cloud,
околу кои потоа се појавија нови услуги.
Во суштина, ова беа два различни типа на овластување. Плус, користевме некои посебни случувања на Mail.ru, на пример, општото складирање на лозинката Mail.ru, како и самонапишан openid конектор, благодарение на кој SSO (овластување од крај до крај) беше обезбедено во панелот Horizon на виртуелни машини (матичен OpenStack UI).
Да се направи IAM за нас значеше поврзување на сето тоа во еден единствен систем, целосно наш. Во исто време, нема да изгубиме ниту една функционалност на патот, туку ќе создадеме основа за иднината што ќе ни овозможи транспарентно да ја рафинираме без рефакторирање и да ја размериме во однос на функционалноста. Исто така, на почетокот, корисниците имаа пример за пристап до услугите (централен RBAC, контрола на пристап базирана на улоги) и некои други ситници.
Задачата се покажа како нетривијална: python и perl, неколку backends, независно напишани услуги, неколку развојни тимови и администратори. И што е најважно, има илјадници живи корисници на системот за борбено производство. Сето ова мораше да се напише и, што е најважно, да се испорача без жртви.
Што ќе испорачаме?
Многу грубо кажано, за околу 4 месеци го подготвивме следново:
- Создадовме неколку нови демони кои ги собраа функциите кои претходно работеа во различни делови од инфраструктурата. На останатите услуги им беше пропишан нов заднина во форма на овие демони.
- Напишавме сопствено централно складирање на лозинки и клучеви, достапни за сите наши услуги, кои можат слободно да се менуваат по потреба.
- Напишавме 4 нови позадини за Keystone од почеток (корисници, проекти, улоги, доделување улоги), кои, всушност, ја заменија нејзината база на податоци и сега делува како единствено складиште за нашите кориснички лозинки.
- Ги научивме сите наши услуги на Openstack да одат на услуга за политики од трета страна за нивните политики наместо да ги читаат овие правила локално од секој сервер (да, така функционира Openstack стандардно!)
Ваквата голема преработка бара големи, сложени и, што е најважно, синхрони промени во неколку системи напишани од различни развојни тимови. Откако ќе се склопи, целиот систем треба да работи.
Како да се воведат такви промени и да не се нафрли? Прво решивме да погледнеме малку во иднината.
Стратегија за воведување
- Би било можно производот да се испорача во неколку фази, но тоа би го зголемило времето на развој за три пати. Дополнително, одредено време би имале целосна десинхронизација на податоците во базите на податоци. Ќе треба да напишете свои алатки за синхронизација и да живеете со повеќе складишта на податоци долго време. И ова создава широк спектар на ризици.
- Сè што можеше транспарентно да се подготви за корисникот беше направено однапред. Беа потребни 2 месеци.
- Си дозволивме застој неколку часа - само за операциите на корисниците да создаваат и менуваат ресурси.
- За работата на сите веќе создадени ресурси, времето на застој беше неприфатливо. Планиравме дека за време на пуштањето во употреба, ресурсите треба да работат без прекини и да влијаат на клиентите.
- За да го намалиме влијанието врз нашите клиенти ако нешто тргне наопаку, решивме да се појавиме во недела навечер. Помалку клиенти управуваат со виртуелни машини ноќе.
- Ги предупредивме сите наши клиенти дека во периодот избран за пуштање во употреба, управувањето со услугите ќе биде недостапно.
Дигресија: што е rollout?
Секој ИТ специјалист може лесно да одговори што е тоа rollout. Инсталирате CI/CD, и сè автоматски се доставува до продавницата. 🙂
Секако дека ова е вистина. Но, тешкотијата е во тоа што со современите алатки за автоматизација на испорака на кодови, се губи разбирањето за самото воведување. Како заборавате на епитетот на пронајдокот на тркалото кога гледате на современиот транспорт. Сè е толку автоматизирано што објавувањето често се врши без да се разбере целата слика.
И целата слика е ваква. Распоредувањето се состои од четири главни аспекти:
- Испорака на код, вклучително и модификација на податоците. На пример, нивните миграции.
- Враќањето на кодот е способност да се вратите назад ако нешто тргне наопаку. На пример, преку создавање резервни копии.
- Време на секоја операција на воведување/враќање. Треба да го разберете времето на која било операција на првите две точки.
- Погодена функционалност. Неопходно е да се проценат и очекуваните позитивни и можни негативни ефекти.
Сите овие аспекти мора да се земат предвид за успешно пуштање во употреба. Обично се оценува само првата, или во најдобар случај втората, точка, а потоа се смета за успешна. Но третото и четвртото се уште поважни. На кој корисник би му се допаднало тоа ако објавувањето трае 3 часа наместо една минута? Или ако нешто непотребно е засегнато за време на пуштањето? Или прекинот на една услуга ќе доведе до непредвидливи последици?
Акт 1..н, подготовка за ослободување
Отпрвин мислев накратко да ги опишам нашите состаноци: целиот тим, неговите делови, купишта дискусии на кафе, расправии, тестови, бура на идеи. Тогаш мислев дека ќе биде непотребно. Четири месеци развој секогаш се состојат од ова, особено кога не пишувате нешто што може постојано да се испорачува, туку една голема карактеристика за жив систем. Што влијае на сите услуги, но ништо не треба да се менува за корисниците освен „едно копче во веб-интерфејсот“.
Нашето разбирање за тоа како да се прошири се менуваше од секој нов состанок, и тоа значително. На пример, требаше да ја ажурираме целата наша база на податоци за наплата. Но, го пресметавме времето и сфативме дека е невозможно да се направи ова во разумно време за пуштање во употреба. Ни требаше речиси дополнителна недела да ја распарчиме и архивираме базата на податоци за наплата. И кога очекуваната брзина на пуштање се уште не беше задоволителна, нарачавме дополнителен, помоќен хардвер, каде што беше влечена целата база. Не е дека не сакавме да го направиме ова порано, но сегашната потреба за воведување не остави без опции.
Кога некој од нас се сомневаше дека пуштањето во употреба може да влијае на достапноста на нашите виртуелни машини, поминавме една недела правејќи тестови, експерименти, анализа на кодот и добивме јасно разбирање дека тоа нема да се случи во нашето производство, па дури и најсомнителните луѓе се согласија со ова.
Во меѓувреме, момците од техничката поддршка спроведоа свои независни експерименти со цел да напишат упатства за клиентите за методите на поврзување, кои требаше да се променат по објавувањето. Тие работеа на кориснички UX, подготвуваа инструкции и даваа лични консултации.
Ги автоматизиравме сите можни операции за воведување. Секоја операција беше напишана, дури и наједноставните, а тестовите постојано се извршуваа. Тие се расправаа за најдобриот начин да се исклучи услугата - да се испушти демонот или да се блокира пристапот до услугата со заштитен ѕид. Создадовме листа за проверка на тимови за секоја фаза од пуштањето во употреба и постојано ја ажуриравме. Цртавме и постојано ажуриравме табела на Gantt за сите работи за воведување, со тајмингот.
И така…
Завршен чин, пред да се испушти
...време е да се појави.
Како што велат, уметничко дело не може да се заврши, само да се заврши со работа. Треба да вложите напори за волја, разбирајќи дека нема да најдете сè, но верувајќи дека сте ги направиле сите разумни претпоставки, предвидени за сите можни случаи, ги затворивте сите критични грешки и сите учесници направија се што можеа. Колку повеќе шифрирате, толку е потешко да се убедите во ова (покрај тоа, сите разбираат дека е невозможно да се предвиди сè).
Решивме дека сме подготвени да се појавиме кога бевме убедени дека направивме се што е можно за да ги покриеме сите ризици за нашите корисници поврзани со неочекувани влијанија и прекини. Тоа е, сè може да тргне наопаку освен:
- Влијае на (свето за нас, најскапоцената) корисничка инфраструктура,
- Функционалност: користењето на нашата услуга по воведувањето треба да биде исто како и пред него.
Тркалање надвор
Две се тркалаат, 8 не се мешаат
Ние одземаме време на прекин за сите барања од корисници 7 часа. Во моментов, имаме и план за воведување и план за враќање.
- Самото пуштање трае приближно 3 часа.
- 2 часа за тестирање.
- 2 часа - резерва за можно враќање на промените.
За секоја акција е направена гант-табела, колку време е потребно, што се случува последователно, што се прави паралелно.
Парче од табела на Gantt, една од раните верзии (без паралелно извршување). Највредната алатка за синхронизација
На сите учесници им е одредена улогата во пуштањето, кои задачи ги извршуваат и за што се одговорни. Ние се обидуваме да ја доведеме секоја фаза до автоматичност, да ја исфрлиме, да ја вратиме назад, да собираме повратни информации и повторно да ја објавиме.
Хроника на настаните
Така во недела на 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 илјади линии код за миграција;
- сите податоци се недопрени, ниту една виртуелна машина на клиент не е оштетена. 🙂
Добри практики за добро пуштање во употреба
Тие не водеа во оваа тешка ситуација. Но, општо земено, корисно е да ги следите при секое пуштање во употреба. Но, колку е покомплексно воведувањето, толку е поголема улогата што ја играат.
- Првото нешто што треба да направите е да разберете како пуштањето може или ќе влијае на корисниците. Дали ќе има застој? Ако е така, што е времето на застој? Како ова ќе влијае на корисниците? Кои се можните најдобри и најлоши сценарија? И покријте ги ризиците.
- Планирајте сè. Во секоја фаза, треба да ги разберете сите аспекти на имплементацијата:
- испорака на код;
- враќање на кодот;
- време на секоја операција;
- засегнатата функционалност.
- Играјте низ сценаријата додека не станат очигледни сите фази од пуштањето во употреба, како и ризиците во секоја од нив. Ако се сомневате, можете да одморите и одделно да ја испитате сомнителната фаза.
- Секоја фаза може и треба да се подобри доколку им помага на нашите корисници. На пример, ќе го намали времето на застој или ќе отстрани некои ризици.
- Тестирањето за враќање е многу поважно од тестирањето за испорака на код. Неопходно е да се провери дали како резултат на враќањето системот ќе се врати во првобитната состојба и да го потврдите тоа со тестови.
- Сè што може да се автоматизира треба да се автоматизира. Сè што не може да се автоматизира треба однапред да се напише на лист за измама.
- Запишете го критериумот за успех. Која функционалност треба да биде достапна и во кое време? Ако тоа не се случи, извршете план за враќање назад.
- И што е најважно - луѓе. Секој треба да биде свесен што прави, зошто и што зависи од неговите постапки во процесот на имплементација.
И во една реченица, со добро планирање и елаборација можете да исфрлите сè што сакате без последици по продажбата. Дури и нешто што ќе влијае на сите ваши услуги во производството.
Извор: www.habr.com