Трудно е да се хвана основното, когато говорим за 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 като начин за ускоряване на доставката на приложения в продукция чрез изграждане и прилагане на автоматизирани процеси“, казва Джай Шнайп (Jai Schniepp), директор на платформите DevOps в застрахователната компания Liberty Mutual. „Но за мен това е много по-фундаментална концепция. DevOps дава на разработчиците правомощия да владеят приложенията или определени части от софтуера, да ги стартират и управляват доставката от начало до край. DevOps елиминира объркването относно отговорността и води всички участници в процеса към създаването на автоматизирана и управляема от разработчика инфраструктура.“
3. DevOps – това е сътрудничество при създаването и доставката на приложения
„По-просто казано, DevOps е подход към производството и доставката на софтуер, при който всички работят заедно“, отбелязва Гур Стаф, президент и ръководител на направление автоматизация на цифровия бизнес в компанията BMC.
4. DevOps – това е конвейер
„Конвейерната сборка е възможна само ако всички части пасват една на друга“.
„Сравнил бих DevOps с конвейер за сглобяване на автомобили“, продължава Гур Стаф. „Идеята е предварително да се проектират и изработят всички части така, че след това да могат да се сглобят без индивидуално подгонване. Конвейерната сборка е възможна само ако всички части пасват една на друга. Тези, които проектират и произвеждат двигателя, трябва да помислят как ще го закрепят към каросерията или рамката. Онези, които произвеждат спирачките, трябва да помислят за колелата и така нататък. По същия начин трябва да бъде и със софтуера.
Разработчикът, който създава бизнес логиката или потребителския интерфейс, трябва да помисли за базата данни, която съхранява информацията за клиентите, за средствата за сигурност, които защитават потребителските данни, както и за начина, по който всичко това ще работи, когато услугата започне да обслужва голяма, възможно и многомилионна аудитория от потребители.
„Да накараш хората да работят заедно и да мислят за онези части от работата, които извършват другите, а не да се съсредоточават изключително върху собствените си задачи – вот най-голямото препятствие, което трябва да бъде преодоляно. Ако успееш, имаш отлични шансове за цифрова трансформация“ – добавя Гур Стаф.
5. DevOps – това е правилната комбинация от хора, процеси и автоматизация
Джейн Гролл (Jayne Groll), изпълнителен директор на Института DevOps, предложи отлична аналогия за обяснение на DevOps. Според нея, „DevOps е като кулинарна рецепта, в която има три основни категории съставки: хора, процеси и автоматизация. Повечето от тези съставки могат да бъдат взети от други области и източници: Lean, Agile, SRE, CI/CD, ITIL, лидерство, култура, инструменти. Тайна на DevOps, както и на всяка добра рецепта, е как правилно да съчетаеш пропорциите и да смесиш тези съставки, за да увеличиш скоростта и резултатността на работата при създаването и пускането на приложения“.
6. DevOps – това е когато програмистите работят като екип от Формула-1
„Състезанието не се планира от старта към финала, а обратното – от финала към старта“.
„Говорейки за това, какво да очакваме от инициативата DevOps, давам за пример състезателен отбор на NASCAR или Формула-1“, – казва Крис Шорт (Chris Short), главен мениджър по маркетинга на облачни платформи в Red Hat и издател на бюлетина DevOps’ish. – „При ръководителя на такъв отбор има една цел: да заеме възможно най-добрата позиция на финала, имайки предвид ресурсите на отбора и предизвикателствата, с които е изправен. При това състезанието не се планира от старта към финала, а обратното – от финала към старта. Първо се поставя амбициозна цел, а след това се определят начините за постигане на нея. След това те се разбиват на подзадачи и се делегират на членовете на екипа“.
«През цялата седмица преди състезанието екипът усъвършенства пит-стопа. Занимава се със силови и кардио тренировки, за да бъде в форма в изтощителния ден на състезанията. Упражнява съвместни действия при решаване на всякакви проблеми, които могат да възникнат по време на състезанието. По подобен начин, екипът на разработчиците трябва да тренира уменията за често издаване на нови версии. При наличие на такива умения и ясна система за сигурност, стартирането на нови версии в продукция също се случва по-често. В контекста на тази философия, увеличаването на скоростта означава увеличаване на безопасността», – казва Шорт.
«Става въпрос не за това да правим „правилните неща“, – добавя Шорт, – а за това да премахваме възможно най-много пречки, които стоят на пътя към желаните резултати. Сътрудничете и се адаптирайте с оглед на обратната връзка, която получавате в реално време. Бъдете готови за аномалии и работете за повишаване качеството, за да минимизирате тяхното влияние върху напредъка към целта. Това е, което ни очаква в света на DevOps».
Как да мащабираме DevOps: 10 съвета от експерти
Просто DevOps и масовият DevOps са абсолютно различни неща. Ще ви разкажем как да преодолеете бариерите на пътя от първото към второто.
За много организации пътят към DevOps започва лесно и приятно. Създават се малки екипи с висок дух, старите процеси се заменят с нови и първите успехи не закъсняват.
Уви, това е само фалшив блясък, илюзия за напредък, както казва Бен Гринил (Ben Grinnell), управляващ директор и ръководител на сектора за цифрови технологии на консултантската компания North Highland. Ранните победи, разбира се, вдъхват надежда, но не помагат да се постигне крайната цел, а именно масово прилагане на DevOps в организацията.
Лесно е да се види, че в резултат се формира култура на разделение на „ние“ и „те“.
«Често организациите стартират такива иновационни проекти, смятайки, че ще прокарат пътя към масовото DevOps, без да се замислят дали другите ще искат и могат да последват този път», обяснява Бен Гриннел. – „Екипите, които реализират подобни проекти, обикновено се събират от самоуверени „варяги“, които вече са правили нещо подобно на други места, но са новаци във вашата организация. При това им се дава възможност да нарушават и разрушават правилата, които остават задължителни за всички останали. Лесно е да се види, че в резултат се формира култура на разделение на „ние“ и „те“, която пречи на предаването на знания и умения.”
„И този културен проблем е само една от причините, поради които DevOps е трудно да бъде мащабиран. DevOps екипите се сблъскват с увеличаване на изключително техническите трудности, характерни за бързо развиващите се компании, които залагат на ИТ технологии“, казва Стив Нюман (Steve Newman), основател и председател на борда на компанията Scalyr.
„В съвременния свят услугите се променят веднага, щом се появи нужда. Постоянно реализирането и внедряването на нови функции е разбира се чудесно, но координирането на този процес и решаването на възникнали проблеми е истинска болка, добавя Стив Нюман. – „В много бързо растящи организации инженерите в крос-функционални екипи се борят за запазване на възможността да следят промените и произтичащите от тях каскадни ефекти на ниво зависимости. Освен това, инженерите определено не се радват, когато ги лишат от тази възможност и в резултат им става по-трудно да разберат същността на възникналите проблеми.”
Как да преодолеем описаните по-горе трудности и да преминем към масово прилагане на DevOps в голяма организация? Експертите призовават да запазите търпение, дори ако крайната ви цел е да ускорите цикъла на разработка на софтуер и бизнес процесите.
1. Помнете, че за промени в културата е нужно време
Джейн Гролл (Jayne Groll), изпълнителен директор на Института 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 за първи път. И помнете, че тези хора се различават значително от пионерите.“
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
