Трудно да се улови същността, говорейки за DevOps? Ние събрахме ярки аналогии, ударни формулировки и съвети от експерти, които ще помогнат да достигнете до същността дори и без специализирани познания. В края на материала - бонус: собственото DevOps на служителите на Red Hat.
Терминът DevOps възникна преди 10 години и премина от хаштаг в Туитър до мощно културно движение в ИТ, истинска философия, която насърчава разработчиците да постигат резултати по-бързо, да експериментират и да напредват методично. DevOps стана неразривно свързан с концепцията за цифрова трансформация. Но както често се случва с ИТ термини, през десетилетие DevOps се обогати с множество определения, тълкувания и заблуди по отношение на него.
Затова, когато става въпрос за DevOps, често чуваме въпроси като: "Това същото ли е като agile? Или това е някаква специална методология? Или просто още един синоним на думата 'сътрудничество'?"
DevOps включва множество различни концепции (непрекъсната доставка, непрекъсната интеграция, автоматизация и т.н.), затова може да е трудно да се изведе същността, особено когато темата ви вълнува. Въпреки това, умението да се обобщава е много полезно, независимо дали се опитвате да предадете идеите си на ръководството или просто разказвате за работата си на семейството или приятели. Затова сега оставяме настрана терминологичните нюанси на DevOps и се фокусираме върху цялостната картина.
Какво е DevOps: 6 определения и аналогии
Помолихме специалисти да обяснят същността на DevOps възможно най-просто и кратко, за да стане ценността му ясна на читатели с всякакво ниво на техническа подготовка. В резултат на тези беседи избрахме най-ярките аналогии и ударни формулировки, които ще ви помогнат да изградите разказа си за DevOps.
1. DevOps – това е културно движение
„DevOps – това е културно движение, в рамките на което двете страни (разработчици на софтуер и специалисти по експлоатация на ИТ системи) признават, че софтуерът не носи реална полза, докато не започне да бъде използван от някого: клиенти, потребители, служители – не е от значение“, смята Евелина Ерлих (Eveline Oehrlich), старши аналитик-изследовател в Института DevOps. „Затова и двете страни съвместно осигуряват бърза и качествена доставка на софтуер“.
2. DevOps – това е това, което дава власт на разработчиците
«DevOps предоставява на разработчиците правомощия да управляват приложенията, да ги стартират и да управляват доставката от начало до край»
«Обикновено DevOps се разглежда като начин за ускоряване на доставката на приложения в продукция чрез изграждане и прилагане на автоматизирани процеси», казва Джай Шнайп, директор по платформите DevOps в застрахователната компания Liberty Mutual. «Но за мен това е нещо много по-фундаментално. DevOps предоставя на разработчиците правомощия да управляват приложения или определени части от софтуера, да ги стартират и да управляват доставката от начало до край. DevOps премахва неразборията с отговорността и води всички участници в процеса към създаване на автоматизирана и управляема от разработчика инфраструктура».
3. DevOps е сътрудничество при създаване и доставка на приложения
«Просто казано, DevOps е такъв подход към производството и доставката на софтуер, при който всички работят заедно», отбелязва Гур Стаф, президент и ръководител на направлението автоматизация на цифровия бизнес в компанията BMC.
4. DevOps е конвейер
«Конвейерната сглобка е възможна само ако всичките детайли пасват един на друг».
«Бих сравнил DevOps с конвейер за сглобяване на автомобили», продължава Гур Стаф. «Идеята е предварително да се проектират и изработят всички детайли, за да могат след това да бъдат сглобени без индивидуална настройка. Конвейерната сглобка е възможна само ако всичките детайли пасват един на друг. Тези, които проектират и изработват двигателя, трябва да помислят как да го закрепят за каросерията или рамката. Тези, които изработват спирачките, трябва да помислят за колелата и т.н. В същия дух трябва да бъде и софтуерът.
Разработчикът, създаващ бизнес логиката или потребителския интерфейс, трябва да помисли за базата данни, съ храняваща информацията за клиентите, за средствата за сигурност, които предпазват потребителските данни, а също и за това как всичко това ще функционира, когато услугата започне да обслужва голяма, възможно дори многомилионна аудитория от потребители».
„Да накараме хората да сътрудничат и да помислят за частите от работата, които другите извършват, вместо да се концентрират исключительно върху собствените си задачи – това е най-голямата пречка, която трябва да се преодолее. Ако успеете, имате отлични шансове за цифрова трансформация“, добавя Гур Стаф.
5. DevOps – правилната комбинация от хора, процеси и автоматизация
Джейн Гролл, изпълнителен директор на Института DevOps, предложи отлична аналогия за обяснение на DevOps. По нейните думи: „DevOps е като кулинарна рецепта, в която има три основни категории съставки: хора, процеси и автоматизация. Повечето от тези съставки могат да бъдат взети от други области и източници: Lean, Agile, SRE, CI/CD, ITIL, лидерство, култура, инструменти. Тайна на DevOps, както и на всяка добра рецепта, е как правилно да се подберат пропорции и да се смеси тези съставки, за да се увеличи скоростта и ефективността при създаването и пускането на приложения.“
6. DevOps – когато програмистите работят като отбор от Формула-1
„Гонката не се планира от старта до финала, а обратно, от финала до старта.“
„Говорейки за това, какво да очакваме от инициативата DevOps, давам пример с гоночен екип NASCAR или Формула-1“, казва Крис Шорт, главен маркетинг мениджър на облачните платформи Red Hat и издател на бюлетина DevOps’ish. „Целта на ръководителя на такъв екип е да постигне максимално възможно място на финала, като се вземат предвид ресурсите, с които разполага екипът, и предизвикателствата, на които е бил подложен. При това гонката не се планира от старта до финала, а обратно, от финала до старта. Първо се поставя амбициозна цел, след което се определят пътищата за нейното постигане. След това тези пътища се разбиват на подзадачи и се делегират на членовете на екипа.“
„Цялата седмица преди състезанието, екипът усъвършенства пит-стопа. Занимава се със силови и кардиотренировки, за да бъде в форма в изтощителния ден на състезанието. Отработва съвместните действия при решаване на всякакви проблеми, които могат да възникнат по време на състезанието. По подобен начин екипът на разработчиците трябва да тренира уменията си за често пускане на нови версии. С наличието на такива умения и добре изградената система за сигурност, пускането на нови версии в продукция също става по-често. В рамките на тази философия, увеличаването на скоростта означава увеличаване на сигурността”, казва Шорт.
„Работата не е в това да правим 'правилните неща', добавя Шорт, а в това да отстраняваме колкото се може повече неща, които пречат на желаните резултати. Сътрудничете и се адаптирайте, като взимате предвид обратната връзка, която получавате в реално време. Бъдете готови за аномалии и работете за повишаване на качеството, за да сведете до минимум влиянието им върху напредъка към целта. Именно това ни очаква в света на DevOps“.
Как да мащабирате DevOps: 10 съвета от експерти
Просто DevOps и масовият DevOps са коренно различни неща. Ще разкажем как да преодолеете бариерите по пътя от първото към второто.
За много организации пътят към DevOps започва лесно и приятно. Създават се малки пасионарни екипи, стари процеси се заменят с нови и първите успехи не закъсняват.
За съжаление, това е само фалшив блясък, илюзия за напредък, както казва Бен Гринел, управляващ директор и ръководител на направление цифрови технологии в консултантската фирма North Highland. Ранните победи, разбира се, дават надежда, но не помагат за постигане на крайната цел - именно масовото използване на DevOps в организацията.
Лесно е да се види, че в резултат на това се формира култура на разделение на 'ние' и 'те'.
Често организациите стартират такива иновационни проекти, вярвайки, че те ще отворят пътя към масовия DevOps, без да се замислят дали другите ще искат и могат да тръгнат по същия път, – обяснява Бен Гринел. – Отборите, които реализират такива проекти, обикновено се съставят от самоуверени „варяги“, които вече са правили нещо подобно на други места, но са новаци във вашата организация. В същото време, те са насърчавани да нарушават и разрушават правилата, които остават задължителни за всички останали. Лесно е да се види, че в резултат се формира култура на разделение на „ние“ и „те“, която възпрепятства предаването на знания и умения.
„И този културен проблем е само една от причините, поради които DevOps е трудно да се мащабира. Отборите DevOps се сблъскват с растежа на строго техническите предизвикателства, характерни за бързоразвиващите се компании, които залагат на ИТ технологии“, – казва Стив Нюман, основател и председател на борда на компания Scalyr.
„В съвременния свят услугите се променят моментално, щом се появи нужда. Непрекъснатото реализиране и внедряване на нови функции, разбира се, е чудесно, но координирането на този процес и отстраняването на възникващите проблеми е истинска болка, – добавя Стив Нюман. – В много бързо развиващи се организации инженерите в състава на кросфункционални отбори се сблъскват с трудности да запазят възможността да проследят промените и каскадните ефекти на нива на зависимостите. Освен това, инженерите не са никак щастливи, когато бъдат лишени от тази способност и в резултат им е по-трудно да разберат същината на възникналите проблеми.“
Как да преодолеем описаните по-горе трудности и да преминем към масово използване на DevOps в големи организации? Експертите призовават да се запаси търпение, дори ако вашата крайна цел е да ускори цикъла на разработката на софтуер и бизнес процесите.
1. Помнете, че за промени в културата е необходимо време.
Джейн Гролл, изпълнителен директор на Института DevOps: „Според мен, разширението на DevOps трябва да бъде толкова постепенно и итеративно, колкото и agile-разработката (и в равна степен да засяга културата). В Agile и DevOps акцентът е поставен върху малките екипи. Но с нарастващия брой и интеграция на тези екипи, все повече хора прилагат нови работни методи, а следствие на това възниква мащабна културна трансформация.“
2. Посветете достатъчно време на планирането и избора на платформа
Еран Кинсбрюнер (Eran Kinsbruner), водещ технически евангелист на компанията Perfecto: „За да заработи мащабирането, екипите DevOps в началото трябва да се научат да комбинират традиционните процеси, инструменти и умения, а след това бавно да развиват всяка отделна фаза на DevOps и да я стабилизират. Всичко започва с внимателно планиране на потребителските истории (user story) и потоците за създаване на стойност (value stream), след което настъпва етапът на писане на софтуер и контрол на версиите с използване на trunk-based development или други подходи, най-подходящи за сливане и разделяне на кода.“
„Следващият етап е интеграцията и тестването, където вече е необходима мащабируема платформа за автоматизация. И тук е важно за екипите DevOps да изберат правилната платформа, която да отговаря на нивото им на умения и крайни цели на проекта.
Следващата фаза – разгръщането в производствена среда, трябва да бъде изцяло автоматизирано с използване на инструменти за оркестрация и контейнери. Важно е да имате виртуализирани среди на всички етапи на DevOps (симулатор на производствена среда, среда за контрол на качеството и самата производствена среда) и винаги да използвате за тестове само най-новите данни, за да получите актуални заключения. Анализът трябва да бъде интелигентен и способен да обработва големи данни с бърза и ефективна обратна връзка.“
3. Освободете отговорността от привкус на вина
Гордон Хафф (Gordon Haff), евангелист на RedHat: „Създаването на система и атмосфера, които позволяват и насърчават експериментите, дава възможност за реализиране на т. нар. успешни провали в agile-разработката на софтуер. Това не означава, че никой не носи отговорност за провалите. Всъщност става още по-лесно да се определи отговорник, тъй като „да бъдеш отговорен“ вече не означава „да бъдеш виновен за инцидент“. Тоест същността на отговорността качествено се променя. Четири фактора стават изключително важни: мащабите на провала, подходите, производствените процеси и стимулите“. (Повече за тези фактори можете да прочетете в статията на Гордън Хафф „DevOps уроци: 4 аспекта на здравите експерименти“.)
4. Разчистете пътя напред
Бен Грининг (Ben Grinnell), управител и ръководител на цифровите технологии в консултантската фирма North Highland: „За да постигнете мащабиране, препоръчвам заедно с проектите-новатори да стартирате програма за „разчистване на пътищата“. Целта на тази програма е да премахне отпадъците, които остават след новаторите в DevOps, като остарели правила и подобни неща, за да остане пътят напред свободен“.
„Дайте на хората организационна подкрепа и ускорете комуникацията, която излиза далеч извън групата на новаторите, широко празнувайки успехите на новите работни методи. Обучавайте хората, които са ангажирани в следващата вълна от DevOps проекти и се притесняват, защото използват DevOps за първи път. И не забравяйте, че тези хора се различават значително от новаторите“.
5. Направете инструментите по-демократични
Стив Нюман (Steve Newman), основател и председател на борда на компанията Scalyr: „Инструментите не трябва да се крият от хората и те трябва да бъдат относително лесни за усвояване от всеки, който е готов да отдели време за това. Ако достъпът до логовете е предоставен само на трима души, „сертифицирани“ да работят с някакъв инструмент, ще имате винаги максимум три души, които могат да се справят с конкретния проблем, дори ако имате много голяма изчислителна среда. С други думи, тук възниква тясно място, което може да доведе до сериозни (за бизнеса) последици“.
6. Създайте идеални условия за работа на екипа
Том Кларк (Tom Clark), ръководител на Common Platform в телекома ITV: «Можете да правите каквото си искате, но не всичко наведнъж. Затова поставяйте големи цели, започвайте от малки стъпки и напредвайте с бързи итерации. С времето ще изградите репутация на екип, който успява, и другите ще искат да използват вашите методи. Не се стремете да изградите високоефективен екип. Вместо това осигурете идеални условия за работа, и ефективността ще дойде сама».
7. Не забравяйте за закона на Конвей и канбан дъските
Логан Дейгл (Logan Daigle), директор по доставка на софтуер и стратегия DevOps в CollabNetVersionOne: «Важно е да осъзнаваме последствията от закона на Конвей. В свободния ми превод този закон гласи, че продуктите, които създаваме, и процесите, които използваме, включително DevOps, са организирани така, както е нашата организация».
«Ако в организацията има висока степен на разединение, а управлението на софтуерното планиране, проектиране и пускане непрекъснато преминава от ръка на ръка, ефектът от мащабирането ще бъде нулев или недълговечен. Обратно, ако организацията формира крос-функционални екипи около продукти, финансирани с фокус върху пазара, шансът за успех значително нараства».
«Още един важен аспект на мащабирането е да се визуализират на канбан дъските всички дейности, които са в процес на изпълнение (WIP, work in progress). Когато в организацията има място, където хората могат да виждат такива неща, това силно стимулира сътрудничеството, което оказва положително влияние върху мащабирането».
8. Търсете стари белези
Манюъл Паис (Manuel Pais), консултант по DevOps и съавтор на книгата «Team Topologies»: «Изнасянето на практиките по DevOps извън самите Dev и Ops и опитът да се приложат към други функции едва ли може да се нарече оптимален подход. Определено ще донесе определен ефект (например, чрез автоматизация на ръчното управление), но може да се постигне много повече, ако започнем с разбиране на процесите на доставка и обратна връзка».
«Ако в ИТ системата на организацията има стари белези – процедури и механизми за управление, които са внедрени след предишни инциденти, но са загубили актуалност (поради смяна на продукти, технологии или процеси), то те определено трябва да бъдат премахнати или изгладени, а не автоматизирани неефективни или ненужни процеси».
9. Не създавайте варианти на DevOps
Антъни Едуардс (Antony Edwards), директор по производството в компания Eggplant: «DevOps е много неясен термин, затова всяка екип получава свой вариант наDevOps. И няма нищо по-лошо от това, когато в организацията се появят 20 разновидности наDevOps, които не могат да координират добре своите действия. Не може всяка от трите разработки да има свой, уникален интерфейс между разработката и управлението на продукта. Както не може продуктите да имат свои уникални очаквания по отношение на обработката на обратната връзка при прехвърлянето в симулатор на производствена среда. В противен случай никога няма да успеете да мащабиратеDevOps».
10. Пропагандирайте стойността на DevOps за бизнеса
Стив Нюман (Steve Newman), основател и председател на борда на компанията Scalyr: «Работете върху признаването на стойността на DevOps. Научете се и не се колебайте да разказвате за ползите от това, което правите. DevOps спестява невероятно време и средства (просто помислете: по-малко престои, по-кратко средно време за възстановяване), и екипите на DevOps трябва постоянно да подчертават (и пропагандират) важността на тези инициативи за успеха на бизнеса. Така ще можете да разширите кръга на адептите и да усиливате влиянието на DevOps в организацията».
БОНУС
На На 13 септември ще дойде наш собствен DevOps – да, при Red Hat, като производител на софтуер, имаме собствени DevOps екипи и практики.
Нашият инженер Марк Биргер, който работи по разработването на услуги за вътрешна автоматизация за други групи в цялата организация, на чист български език ще разкаже собствената си история – как екипът за DevOps на Red Hat мигрира приложения от виртуални среди Hat Virtualization, управлявани от Ansible в пълноценен контейнерен формат на платформата OpenShift.
Но и това не е всичко:
След като организациите преместят работните натоварвания в контейнери, традиционните методи за мониторинг на приложенията може да не проработят. Във втория отчет ще обясним нашата мотивация да променим начина на регистриране и ще покажем продължението на пътя, който ни е отведел до съвременните методи на водене на журнали и мониторинг.
Източник: habr.com
