Обея за изграждане и индустриализиране на ИТ процес

анимирано изображение на процесите в дигитална среда

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

Автор: Томас Делини, Лийн треньор, Operae Partners

По време на неотдавнашен опит в международна застрахователна компания обучих и подкрепих няколко екипа, докато работеха за ускоряване на доставката на ъпгрейд на сървъра за приложения. Общо четири екипа от шест до девет души бяха натоварени да се справят с остаряването на сървъра чрез актуализиране на операционни системи (OS) и бази данни (DB) и чрез криптиране на данни (файлове, таблици и т.н.).

Екипите бяха съставени от вътрешни клиенти (представители на бизнеса), мениджър на ИТ проекти, архитекти, анализатори на бази данни, оператори, специалисти по сигурността и външни консултанти. ИТ системата на тази голяма компания включва няколко хиляди сървъра и основната цел на проектите за ъпгрейд беше да осигурят тяхната стабилност, наличност и сигурност. Тези проекти бяха стартирани за първи път преди няколко години, но бяха спирани и рестартирани много пъти. Последният тласък за завършване на актуализациите и гарантиране на съответствието на сървърите влезе в рамките на законодателството около GDPR.

За да се ускори доставката на актуализациите и да се даде възможност за силно сътрудничество между различните отдели на компанията, беше решено да се създаде стая Обея и екипите да работят в този контекст. В тази голяма стая имаше седем панела: Визия, Глас на клиента, Продукт, Макро план, Микро план, KPI и Непрекъснато подобрение.

Илюстрация на седемте панела Обея, от Едмонд Нгуен в Operae Partners

Илюстрация на седемте панела Обея, от Едмонд Нгуен в Operae Partners

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

След това обаче бързо разбрах, че екипите не разполагат с достатъчно ясно разбиране за стъпките, които са необходими за справяне с остаряването на сървъра. По-конкретно, не е постигнато съгласие относно процеса и относно това кой е отговорен за каква част от него. Нещата бяха още по-малко ясни, когато влязохме в подробностите за всяка дейност, времето за изпълнение на всяка стъпка (например колко време отнема криптирането на 1TB на MariaDB и какво е въздействието върху производителността на четене и запис), необходимите предпоставки и роли и отговорности. Всеки имаше своя гледна точка за действията, които трябваше да извърши. Екипите не са имали глобален преглед на процеса, нито са се споразумели за взаимодействието при различни дейности.

Стъпка 1 – Обучение за ръчно доставяне на първия „минимален изпълним продукт“

Вместо да се впускам в безкрайна диаграма RACI (Responsible Accountable Consult Informed), аз помолих екипите да използват лепящи се бележки, за да представят на стената макро стъпките, за които се съгласиха поне по принцип. Именно в този „минималистичен“ контекст проведохме първата си седмична среща в Обея с четирите основни екипа (съставени от ИТ специалисти и оперативни хора, които се обединяват, за да си сътрудничат за подобряване на сигурността на системите). Всеки екип беше воден от ръководител на ИТ и главен инженер (хората, които моето менторство трябваше да подкрепя най-пряко).

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

Първият ни MVP беше умишлено прост: един сървър на Redhat, хостван на една физическа машина. Целта беше да се достави за две седмици (10 работни дни).

Въз основа на този MVP, екипите продължиха да конструират панелите Продукт, Макроплан (месеци и седмици) и Микроплан (ден за ден) с подкрепата на главния инженер. Резултатът беше „визуална пътна карта“, която представляваше продукта, който трябва да бъде доставен, и стъпките, необходими за неговото доставяне, които екипите бяха съгласували.

Минималният изпълним продукт # 1 беше доставен един месец по-късно. Първият сървър беше готов, но с две седмици закъснение. С хиляди сървъри за ъпгрейд, ние знаехме, че това е само началото. За да подобрим следващия си MVP, решихме да интервюираме вътрешния клиент (представител на бизнеса), за да идентифицираме неизпълнени очаквания. Отзивите бяха, че тази първа итерация е доста трудоемка: той е бил помолен да спре и рестартира сървъра шест пъти, за да се актуализира системата, което е повлияло на услугата за крайните потребители, а също така е трябвало да извърши четири различни тестови сесии след всеки ъпгрейд. В крайна сметка сървърът не беше достъпен общо четири дни, което се отрази негативно на потребителите по време на тестовите сесии.

На ниво екип, както лесно може да се види от Спагети диаграмата по-долу, имаше много трудности и препятствия. Спагети диаграмите са много полезни, за да покажат ненужните стъпки, през които се налага да преминат хората по време на изпълнението на даден процес. В тази първа итерация на MVP имаше известно напрежение и несъгласие (въпросът дори беше ескалиран до мениджърите в даден момент) относно изискванията за операцията по актуализиране, както и върху точните средства, който да се използват за комуникация на изискванията (напр. имейл или тикет, PDF или Word документ и т.н.).

Спагети диаграма: Обмен между различни хора (всеки оцветен квадрат) за подготовка на операцията

Спагети диаграма: Обмен между различни хора (всеки оцветен квадрат) за подготовка на операцията
+ 200 изпратени имейла, 4 управленски ескалации, 6 семинари лице в лице.

През първия месец екипът се справи с 37 проблема (12 решени и 25 в ход), използвайки цикъла PDCA (Plan Do Check Act), истинската движеща сила на непрекъснатото подобрение в Обея. Всеки цикъл/итерация се записва на седмия панел на стената. PDCA развива експертния опит на членовете на екипа, прави ги автономни в решаването на проблеми и премахва пречките за подобрение един по един. След това всяко подобрение се споделя с останалата част от екипа на седмичната среща на основния екип.

Въпреки всички тези трудности и „умерено доволен“ вътрешен клиент, екипът беше успял да достави първия си сървър, да постигне първоначален успех и да научи много в процеса (с много място за по-нататъшно усъвършенстване). По-специално екипът успя да:

  • Проектира първа версия на процеса, с шест основни стъпки и дузина дейности за всяка стъпка и измерване на времето, прекарано в ключовите стъпки. Този процес, разбира се, беше показан в Обея.
  • Измисли четири работни стандарта (в Лийн перспектива) за ключови операции, включващи списък с предварителни условия (версии, дата на последно рестартиране на сървъра и т.н.), изчерпателен списък със задачи за изпълнение, ключовата точка и причината, поради която тази задача е необходима: спиране на базата данни, архивиране на таблици, команда за криптиране на таблици с ключ и т.н.
  • Създаде три контролни списъка – как да се уверим, че данните са криптирани, условия преди стартиране на тестовете за натоварване, необходими целеви дискови пространства въз основа на текущия размер.
  • Въведе сметки за въздействието на криптирането на данни върху производителността на четене и запис, върху размера на файловите системи и др.

Стъпка 2 – Ускорение на доставката и подобряване на удовлетворението

Горд с този успех, но с твърдото намерение да се подобри със следващата итерация, екипът се зае със създаването на втори MVP на процеса на актуализация на сървъра. Тази версия имаше 10 виртуализирани сървъра (първият MVP имаше такъв) на два физически сървъра. Компанията си е поставила за цел две седмици да я изпълни.

Започнахме с изграждането на продукта на стената на Обея, за да може целият екип да е наясно с обхвата на проекта и да успее в рамките на двуседмичния срок. Създадохме панел с различните виртуални машини (VM), бази данни, физически сървъри, версии на OS / Middleware, размери на табличното пространство. Тогава екипът откри, че две бази данни, инсталирани на един от четирите сървъра, не са в обхвата на MVP # 2: те имаха приложение в различна част на бизнеса. Следователно беше необходимо да се изключат и да информира бизнеса, когато сървърите са спрени/рестартирани.

Като се започне от работата, която свърши с MVP # 1, екипът изгради подобрена версия на процеса на актуализация на сървъра, която е свързана с общо поемане на определени дейности, за да се намали натоварването на бизнеса (например при изключване и рестартиране на бази данни и фази на приемане) и премахване на ненужните стъпки (като започване на извършване на корекции на място). Поуките от опита с MVP # 1 все още са ясни в съзнанието на екипа, а A3 листовете на много PDCA все още висят по стените!

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

MVP

Екипът представи на панела за макропланове в Обея последните две важни стъпки от две седмици за доставяне на MVP # 2 и се договори за операциите, които ще се извършват всеки ден, както е изброено в панела за Микроплан: подготовка на скриптове, предоставяне на технически изискания, подготовка на тестовете за натоварване (като стрес тестове, симулиращи голям брой потребители), планиране на обхвата на интервенция, бизнес тестове след операцията. Всеки знаеше какво действие трябва да извърши, какъв е очакваният резултат и на какъв стандарт или контролен списък може да разчита.

За удовлетворение на вътрешния клиент, екипът успя да достави MVP # 2 навреме. Процесът беше подобрен, тествани бяха различни стандарти и изготвени контролни списъци. Те също така скриптираха (написаха специфичен код за команди) някои от операциите, които преди това бяха извършвани ръчно, като операцията за криптиране на данни. Член на екипа коментира: „Спряхме да бутаме проекти като вагони във влак и започнахме да ги дърпаме от гледна точка на клиентите.“

Те обаче срещнаха и редица проблеми. Например скриптът изтри Портфейла, съдържащ някои кодове за достъп до операционната система, което означаваше, че е необходима преработка, за да се поправи Портфейла и да се вземе предвид архивирането. Двата сървъра, изключени от проекта на втория MVP, бяха частично засегнати.

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

Заключение

Екипът безспорно е разработил индивидуален опит и е научил много за процеса на доставка. Обея е много полезен за подпомагане на хората да си сътрудничат по-ефективно за обща цел. (Един от членовете на екипа каза: „Голямата добавена стойност на Обея беше способността да описва и споделя експлицитните и имплицитни знания на всеки човек, които трябва да бъдат извлечени.“) Интензивните сесии за решаване на проблеми, в които участваха, им позволиха да изпитат непрекъснато подобрение от първа ръка.

За да постигнат очакваното време на такта, темпото, зададено от клиента, ще трябва да станат още по-бързи със следващата си итерация – MVP # 3: целта им е да доставят 10 сървъра на ден. Това ще бъде възможно само с напълно индустриализиран процес, със стандарти за осигуряване на постоянни нива на качество и набор от стабилни и добре дефинирани стъпки, които не струват повече, отколкото би трябвало. Ясно е, че екипът ще трябва да въведе поток на изтегляне, за да разкрие проблемите, които се нуждаят от решаване, и да хвърли светлина върху ненужните дейности, които могат да бъдат отстранени.

Томас Делини - Лийн треньор във Operae Partners

АВТОР: Томас Делини
Томас Делини е Лийн треньор във Operae Partners във Франция.

Споделете тази статия и с други заинтересовани
– Благодарим Ви за подкрепата: