Как да започнем трансформация на DevOps

Ако не разбирате какво е DevOps, ето една кратка шпаргалка. DevOps е набор от практики, които намаляват страховете на инженерите и съкращават броя на сривовете в производството на софтуер. Обикновено те също така съкращават времето за навлизане на пазара — периодът от идея до доставката на крайния продукт на клиентите, което позволява бърза реализация на бизнес експерименти..

Как да започнем DevOps трансформация? Накратко: избираме услуга, с която да започнем процеса, идентифицираме хората, които имат отношение към услугата, изграждаме Value Stream Map, създаваме временно екип, който да се занимава с трансформацията в началото, и му поставяме задача. Повтаряме цикъла необходимия брой пъти.

Подробен план за DevOps трансформация с примери и инструкции под кат — в разшифровката доклад Андрей Александров — на инженер от компанията Express42, която консултира прорастването на DevOps, ускорявайки този процес, защото вече е изградена карта на капаните. Ако смятате, че трансформацията не ви е необходима, или спецификата ви е такава, че практиките на DevOps не подхождат, — използвайте доклада като инструкция за търсене и отстраняване на ограничения.

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

Избор на услуга

Планът е начертан, започваме с първата стъпка — избор на услуга. Първият критерий — времето на живот: има стари услуги — legacy и нови. Може да започнете както от едните, така и от другите.

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

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

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

— Това е нова услуга! Там всичко беше просто, опитайте да направите нещо с нашата развалюха.

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

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

Има услуги, които представляват просто интерфейс за потребителите, например, прост сайт или мобилно приложение. Но има и сериозни неща като бекенд за таксуване. Ако нещо се обърка с таксуването — ще бъде сложно да се разбере. Тук също имаме избор.

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

Но дори и в този случай, не бих препоръчал така да се прави, защото, докато няма разбиране с какво да работите и в каква посока да се трансформира, взимането на критичен елемент и разклащането му — не е много добра идея. Затова в този случай предпочитаме да работим с интерфейс, чийто срив не е критичен.

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

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

От една страна, консерваторите — опитни хора: отдавна в компанията, разбират от а до я, но не знаят какви са практиките. От друга страна — инноваторите, които са чули нещо, но вероятно не работят в компанията от много време. С кого е по-добре да работим?

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

Логично е да изберем иноватори в екипа, тъй като консерваторите могат да подложат на изпитание новите идеи.

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

Имах случай, когато един от екипа ремонтираше всичко, което му попадне, защото това явно беше по-критично от това, което правим в момента. Даваме задача: да реализираме този фрагмент днес — не, на другия край на света има пожар, отиваме да го гасим. С такива хора е трудно да се работи.

Хората от екипа на консерваторите често игнорират задачите или ги отлагат до последния момент. А ако, о, Боже, вие случайно направите грешка и им зададете KPI за броя на изпълнените задачи, а част от тях не е включена в KPI, те изобщо няма да направят нищо. Всъщност, те ще бъдат прави, защото в такъв случай ще загубят бонуса си.

С иноватори е по-лесно — те са по-лоялни.. Те вече са чули нещо, искат да вървят напред, затова ще помагат. Нуждаем се от хора, които са готови да страдат в началото: ако услугата се променя, иноваториите ще понесат всички удари и неуспехи, като пионери. Инноваторите искат всичко ново и актуално, дори и да пострадат.

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

В заключение. Ако правим цялата трансформация в нашата компания сами, трябва да изберем: нова услуга, за предпочитане с прост интерфейс, за да не страдаме много от повредите, и екип от иноватори.

Ако имате възможност да поканите външен консултант, вместо нов – вземете стария сервиз, от който вече страдаме. Хората, които са работили по трансформациите достатъчно дълго в различни компании, са виждали различни случаи и вече разбират как да действат правилно и в каква посока да се движат.

Кой е замесен?

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

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

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

После ще се наложи да изградим Value Stream Map и без тези хора това не може да стане, защото само те заедно знаят пълната картина на това, което се случва. Един човек никога не може да знае всичко, което става със сервиза.

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

След това събираме всички тези хора от различни отдели в една стая и започваме да изграждаме Value Stream Map.

Изграждаме Value Stream Map.

Value Stream Map е схема или карта, която показва потока на стойности до клиента.Това е целият процес от генерирането на идея до нейното реализиране, включително всички междинни етапи и как стойността в крайна сметка достига до нашите клиенти.

Value Stream Map е необходима, за да визуализираме всички етапи на разработката,локализираме проблемите чрез измервания, налични в текущия процес, и започнем да ги отстраняваме, и да поставим началната цел.Това е мястото, където ще започнем да правим нещо реално.

Метрики

В литературата относно Value Stream Map са описани много различни метрики, но за начало ни трябват само три.

Lead Time — задържане/очакване. — времето, когато чакаме нещо. Например, тестерът чака, докато се освободи стенд за тестване, и през това време не може да прави нищо.

Value Added Time — време на полезна работа — времето, което сме изразходвали на определен етап, за да създадем крайна стойност за потребителя. Например, тестерът е стартирал своя тест и започва да проверява нещо. Това е времето на полезната работа, когато наистина правим нещо за продукта. Това е за което клиентите плащат — за качествен софтуер.

%C/A — процент на приета работа. Имаме един етап — разработка, втори етап — тестване. Колко функции тестерите са приели от разработчиците, и имаме този процент.

Приблизително така изглежда нашата карта.

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

С метриките обхващаме абсолютно всичките етапи.

Backlog — колко задачи са останали след като аналитиците са ги измислили.

Разработка — колко седмици разработчиците са чакали уточнения по задачите, стендове или оборудване — няма значение, но те чакат нещо. Например, 4 дни те реализират функция. Тук се появява метрика %C/A. Разработчиците са взели от Backlog само 80% от задачите. Те смятат, че за останалите 20% няма достатъчно ясни изисквания и са ги изпратили за доработка.

Тестване. На схемата LT е зададено 4 дни. Например, тестерите са чакали освобождаването на тестовия стенд, VA 2 дни те наистина тестват нещо, и %C/A = 40 %. — само 40 % от кода или функциите, които са изпратили разработчиците, тестерите са сметнали за адекватни. Всичко останало не им е харесало по някаква причина.

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

Единственото, което ще посъветвам — не вярвайте на хората, които ще съставят с вас Value Stream Map. Те представят колко време отнемат различни процеси, но тези оценки не винаги са верни, затова е по-добре да измервате сами.

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

Затова все пак ще трябва да извършите измервания сами, желателно не само веднъж, за да имате близка до реалността представа. В зависимост от Value Stream Map ще вземете решение откъде да започнете и какво да коригирате на първо място.

Временен екип

Много компании, които решават да внедрят DevOps, създават екип, но не временен, а съществуващ няколко години. Ако се обърнете към услугата DevOps apologize, в която са описани различни модели на организационна структура в DevOps, ще разберете, че това е антипатерн.

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

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

Затова, за да започнете, трябва да създадете временен екип. Тя ще просъществува временно половин година, максимум година, в зависимост от поставената задача, само за да премахне едно ограничение, което сме избрали. След това ще спре да съществува. Ако изберем следващата точка, в която ни боли силно, и разберем, че за нея също ни трябва отделен екип, тогава отново ще я създадем. Но на "постоянно" такива екипи не трябва да съществуват — тогава те само нарушават комуникацията и поемат изцяло различни задачи, само за да правят нещо. Тези задачи може изобщо да не са свързани с DevOps и с трансформация. Защо да не предадем тази задача на съществуващите отдели?

Защо е нужен времеви екип

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

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

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

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

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

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

Временният екип се занимава само с DevOps трансформация — премахване на ограниченията, които открихме, и нищо повече.

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

Обычно вземаме условно един разработчик, един тестировчик и един инженер — и заедно с тях измисляме решение, което позволява да живеем по различен начин.

Предпочитателно е тези хора да имат авторитет в организацията. Възможно е да се наложи да вземем един консерватор, макар и да не искаме. Ако имаме голяма компания, далеч не всички ще повярват в нашата намеса, а някой може да постави пречки, например, да не осигури стенд. Тук ще ни е нужен "авторитет" — уважаван човек с дълъг опит, който е спечелил добро отношение от колегите. Авторитетът на служителя в екипа ще улесни задачата и работата на временного екип. Хората ще мислят:

— Аха, този страхотен човек, когото всички познаваме и обичаме, се вписа — явно в DevOps има нещо, на което си струва да се погледне!

Поставяме цел

Събрали сме хора, избрали сме услуга, видяхме ограниченията, определихме на кои хора ще повлияем. Сега трябва да поставим цел и тя трябва да бъде ясно по SMART — всичко, както обичаме.

Специфична — конкретна.

Измерима — измерима. Това е много важна точка от SMART. Ако не можете да измерите нещо, не можете да го промените и да разберете какво и как сте направили по-добре или по-зле.

Постижима — постижима. Направете поправка за своята специфика. Ако сте предприятие с дълга история и голямо натоварване, което пуска версия на продукта веднъж годишно, няма да можете за половин година да достигнете до нови версии на продукта на всеки час. Така не става. Затова поставяйте реална цел, която е постижима в приемлив срок.

Релевантна — релевантна. Премахваме само онова ограничение, което наистина пречи на нашите текущи цели.

Ограничена във времето — ограничена по време. Ако няма срок — екипът ще се занимава с какво ли не: ще пробват 15 технологии вместо 3, ще пишат огромни доклади, ще провеждат безполезни изследвания, ще полира своята реализация до блясък, когато целта вече е постигната.

Целта вземаме именно чрез Value Stream Map — отново събираме всички хора и рисуваме. Но сега на базата на предишната Value Stream Map рисуваме това, което искаме да постигнем.

Определяме едно ограничение, което ще премахваме точно сега — с това ще се заеме екипът. За пример взех времето на очакване от готовия релиз до неговото внедряване в продукция — това е най-често срещаната пречка, за която хората се обръщат към консултанти.

На базата на това поставяме задача: искаме времето между готовия релиз и излизането в действие да е максимум един час.

Примери на задачи.

• Да съкратим Lead Time за тестване от 4 дни до 1 час.
• Да съкратим Value Added Time за тестване от 2 дни до 3 часа.
• Да съкратим Lead Time за деплой от 5 часа до 10 минути.
• Да увеличим C/A от 50% до 95%, т.е. да увеличим броя на функциите, които приемат тестерите, с други думи, да подобрим качеството на работата на разработчиците.

Примерите на задачи не са взети от въздуха — те са основани на измервания, които направихме, когато разработвахме Value Stream Map.

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

Кратко планиране

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

Например, често използваме подхода moving-moving, когато целият екип се събира в началото на всяка седмица, за да наброси в файл какво ще прави всеки. След една седмица отбелязваме: какво е направено и какво не, ако не е, защо, и мислим какво да направим след това.

Спринтовете позволяват навременна корекция на курса.

Опитваме нещо за седмица или две: технологии, подходи, методи на работа, след което отново измерваме и гледаме — с този подход стана ли по-добре или по-зле? Ако е по-зле, значи не сме на прав път, трябва да коригираме курса: да поставим друга задача, да вземем друга технология или да направим нещо друго. Кратките спринтове от 1-2 седмици позволяват да маневрираме и навреме да се оттегляме от лоши решения.

Споделяме успехите

Екипът постига успехи, малки или големи — не е важно, винаги има някакъв резултат. За този резултат трябва да знаят всички: както тези, които са свързани с DevOps, така и съседните отдели. В идеалния свят е желателно това да достигне до всички хора в компанията.

Защо? Ако искаме да трансформираме не част от компанията, да премахнем не едно ограничение, а всичките, за да стане компанията гъвкава, кодът бързо да достига до клиента и нищо да не се чупи, трябва всички да са лоялни към идеята за DevOps. Няма да можете да приложите подхода към услуги и екипи, които са категорично против.

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

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

Общо

Избираме услугата, като отправна точка — мястото, от което ще започнем промените в компанията. Идентифицираме всички, които имат някакво отношение към услугата и заедно с тях изграждаме Value Stream Map, измерваме и наблюдаваме, къде и какви ограничения съществуват.

Създаваме нова временна команда, която ще се занимава с поставената задача. На базата на измерванията и Value Stream Map изработваме нова карта, където обозначаваме ограничението, което ще решаваме. На базата на това ограничение поставяме задача, с която ще се занимава екипът. Задачата трябва да бъде необходимо SMART — конкретна, измерима, релевантна на текущите задачи и ограничена във времето.

Повтаряме процеса, докато не трансформираме абсолютно всички наши услуги до необходимия вид и не устраним всички ограничения.

Бонус. Полезни материали

За тези, които решиха да се занимават с DevOps самостоятелно.

Проектът „Феникс“

Оригиналното заглавие е „The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win“. Това е роман за DevOps — история за това как служител е станал началник на екип, който постоянно бил в трудна ситуация. На новия началник е поставена задачата:

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

„Проект „Феникс“. Роман за това как DevOps променя живота към по-добро“ — книга за всички ръководители, защото именно те вземат решения относно това, което се случва в компанията. Ако сте инженер или програмист и искате да видите движението и трансформацията в своята компания — купете книгата и я подарете на ръководството. Този роман обяснява всичко, а се чете бързо и лесно.

Ръководство за DevOps

Книгата е малко по-сложна. Излезе преди няколко години на английски под заглавието „The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations“, но сега вече има и на български. Това е истинският практически наръчник: как да извършвате измервания, какво представлява Value Stream Map и защо е нужен, накъде трябва да се движите, в какъв ред. Книгата е именно за тези, които искат всичко да направят сами. Най-важното е, че в нея има примери от опита на други компании.

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

Ускорете

Пълно заглавие: «Ускорете: Науката за Lean софтуер и DevOps: Създаване и разширяване на високопроизводителни технологични организации». Това е следващото ниво – хардкор. Книгата излезе миналата година, засега само на английски и е за изследвания. Авторите – Никол Форсгрън, Джез Хъмбъл и Джийн Ким – в продължение на много години прилагаха различни практики в различни компании и изследваха какви практики, как и на какво влияят.

Във втората глава, посветена на измерванията, се споменава картата на стойностните потоци, метрики, за които говорих, и много други, както и подробно е описан процесът на измервания. Авторите извършват измервания с помощта на въпросници и собствено проследяване на задачи. Подробно се обсъжда кои метрики е правилно да измервате, кои не си струва, човешките грешки в измерванията. Ако имате затруднения с измерванията, обърнете се към втората глава на книгата «Ускорете». Ако във вашия екип просто има много практики, но не е ясно кои практики да приложите сега, кои по-късно, кои действително работят и кои не – прочетете, в книгата всичко е описано.

Трансформацията е въпрос на кръстопътя на DevOps и управлението. Някъде в тази сфера на пресечените точки на разработка, експлоатация и тестване се намират темите, които се стремим да обсъждаме на DevOpsConf, същата интеграция е необходима и за създаването на качествен продукт – основната тема QaulityConf. Управление на фестивала РИТ++ са представени Whale Rider – означава, че за идеи за трансформация, всичко отива там. Присъединете се на 27 и 28 май, ще се интегрираме и трансформираме.

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