Ако не разбирате какво е 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 и защо е необходим, накъде да се движите и в какъв ред. Книгата е точно за тези, които искат да направят всичко сами. Най-важното е, че в нея има примери от опита на други компании.
Например, там се разказва как една компания създава Value Stream Map и осъзнава, че проблемът не е в продукта, а в това, че касиерът трябва да ходи от магазина до съседния офис, за да се възползва от продукта. Вместо да решават проблема с програмата, те просто купиха таблети на своите търговци и сега никой не ходи никъде, а всичко се извършва на работното място. Извод: Value Stream Map може да се прилага не само в софтуер, но и на всички процеси в организацията.
Accelerate
Пълно заглавие: «Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations». Това е следващото ниво — хардкор. Книгата излезе миналата година, засега само на английски и е за изследвания. Авторите — Nicole Forsgren, Jez Humble и Gene Kim — в продължение на много години прилагаха различни практики в различни компании и изследваха кои практики как и на какво влияят.
Във втората глава, посветена на измерванията, се споменава Value Stream Map, тези метрики, които нарекох, и множество други, както и подробно е описан процесът на измерване. Авторите провеждат измервания чрез問ник и самоотчет при проследяване на задачи. Подробно се разяснява кои метрики трябва да се измерват, кои не трябва, човешките грешки при измерванията. Ако имате трудности с измерванията, обърнете се към втората глава на книгата «Accelerate». Ако във вашия екип просто има много практики, но не е ясно кои практики да приложите сега, кои после, кои наистина действат и кои не — четете, в книгата всичко е описано.
Трансформацията е въпрос на пресечната точка между DevOps и управлението. Някои от темите в тази област включват разработки, експлоатации и тестирования, които се опитваме да обсъдите на , същата интеграция е необходима и за създаването на качествен продукт – основната тема на . Управлението на фестивала е представено — така че за идей за трансформация, всичко е там. Присъединявайте се на 27 и 28 май, ще се интегрираме и трансформираме.
Източник: habr.com
