Важко вловити головне, говорячи про 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 і стабілізувати її. Все починається з ретельного планування історій користувача (userstory) і потоків створення цінності (valuestream), після чого настає етап написання ПЗ та контролю версій з використанням trunk-based development або інших підходів, найбільш підходящих для розгалуження та злиття коду».
«Потім слідує етап інтеграції та тестування, де вже потрібна масштабована платформа для автоматизації. І тут командам DevOps важливо вибрати правильну платформу, яка б відповідала їх рівню навичок і кінцевим цілям проекту.
Наступна фаза – розгортання у виробничому середовищі, і воно має бути повністю автоматизоване з використанням інструментів оркестрації та контейнерів. При цьому важливо мати віртуалізовані середовища на всіх етапах DevOps (симулятор виробничого середовища, середовище контролю якості і, власне, виробниче середовище) і завжди використовувати для тестів лише останні дані, щоб отримувати актуальні висновки. Аналітика має бути розумною і здатною обробляти великі дані зі швидким і дієвим зворотним зв'язком».
3. Позбавте відповідальності від присмаку провини
Гордон Хафф (Gordon Haff), євангеліст RedHat: «Створення системи та атмосфери, що дозволяє та заохочує експерименти, дозволяє реалізувати так звані успішні збої в agile-розробці ПЗ. Це не означає, що за збої ніхто більше не відповідає. Насправді, встановити відповідального стає навіть простіше, оскільки «бути відповідальним» більше не означає «стати винуватцем аварії». Тобто суть відповідальності якісно змінюється. При цьому вкрай важливими стають чотири фактори: масштаби збою, підходи, виробничі процеси та стимули». (Докладніше про ці фактори можна прочитати у статті Гордона Хаффа «DevOps lessons: 4 aspects of healthy experiments».)
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, workinprogress). Коли в організації з'являється місце, де люди можуть бачити такі речі, це сильно стимулює співпрацю, що позитивно впливає на масштабування».
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