Що містить «Перетворення DevOps»?

Деякі консалтингові компанії просувають послугу під назвою "DevOps Transformation". Кілька великих компаній говорять про цю тему на конференціях та зустрічах по всьому світу.

Що означає таке «перетворення DevOps»? Як це виглядає в діючих умовах, як для успішних перетворень, так і невдалих.

Мені потрібно поставити свою відповідь на це питання в контексті того, що таке DevOps, точніше в рамках DevOps перетворень, до яких я входив, DevOps є власником повного життєвого циклу розробки програмного забезпечення. Усі практики на діаграмі є важливою частиною DevOps, і вони дозволяють і підтримувати як системне мислення, так і посилення циклів зворотного зв'язку .

Однак ключовим диференціатором між CI / CD та DevOps є фактична робота програмного забезпечення у виробничому середовищі, де воно може доставляти цінність своїм клієнтам та бізнесу, який він обслуговує.

Як консультант, який бере участь у трансформації DevOps або веде за собою, у мене в голові такі аспекти:

• Культура : Як Дейв абсолютно справедливо вказувала на культуру безперервного експериментування і навчання має вирішальне значення для успіху будь-якого перетворення. З точки зору DevOps це зводиться до того, як ми вирощуємо культуру, яка підтримує обрану модель DevOps, цією моделлю може бути "Ви будуєте це, ви запускаєте її", або це може бути більше за принципами Інженерної практики надійності веб- сайтів Google. .

• Операційна модель : Це частина ділової пропозиції, яка формулює, як організація буде отримувати цінність, як правило, шляхом артикуляції людей, процесів та інструментів, які використовуються між собою на високому рівні. Без діючої моделі ви не маєте основи того, як організація переймає практику, яку визначає культура, це, в свою чергу, призводить до недостатньої чіткості та розбіжності в поведінці.

• Повітряна обкладинка рівня C : Ми часто працюємо в якості консультантів, що працюють в рамках програм трансформації, робити кардинальні зміни в тому, як працює бізнес. Ви збираєтеся засмучувати людей, а деяким людям зміни не сподобаються - важливо, щоб у вас було "повітряне покриття" зверху, щоб змінити речі і рухатися вперед.

Після високого рівня важливо знайти те, що реально можна доставити:

1. Почніть по можливості якнайменше, в ідеалі, як тільки у вас є люди, які розуміють культуру, ескіз операційної моделі та викуп від керівників створюють "Мінімальний життєздатний проект", не намагайтеся кипіти океан, вводячи DevOps до тисячі аудиторій. Поставте досягнуту мету:
   • Автоматизуйте створення інфраструктури з Продукту X.
   • Автоматизуйте доставку продукту X в Azure в усіх середовищах.
   • Підтримка з боку аутсорсера Y команді з розвитку в Лондоні.
   • Створіть набір тестів навколо нашої ризикованої функції та запустіть їх у постійній інтеграції.
2. Чудово, що у вас є певний успіх під вашим поясом. Настав час почати випікати це в більше команд, додати ще пару команд у суміш і розпочати їх. Не бійтеся запропонувати "Підтримку білих рукавичок" спочатку, щоб допомогти їм у переході; їм буде потрібно багато триматися за руки протягом найближчих тижнів і місяців.
3. Зараз у вас є декілька ранніх усиновителів, які слідують за новим способом роботи; у вас є якась критична маса, саме час почати євангелізувати роботу, яку ви робите для широкої аудиторії:
   • Проводьте регулярні сеанси шоу- казок і попросіть ранніх усиновителів продемонструвати, наскільки вони успішні.
   • Запропонуйте сеанси випуску, щоб дозволити іншим частинам організації вивчити, як вони можуть працювати на вашій команді.
   • Увімкніть створення спільнот практичної діяльності, орієнтуючись на конкретні дисципліни: постійне впровадження, автоматизоване тестування, ділове спілкування, управління ризиками, моніторинг та оповіщення тощо.

4. Залишайте курс і закривайте трансформацію, перебуваючи на борту решти організації. Зрозумійте взаємозв'язок між циклом галаслів Gartner та життєвим циклом усиновлення . Підготуйтеся до того, що програма "Трансформація" потрапить у "корито розчарування", дотримуйтесь курсу та не помічайте кінцевої мети.

   

Для більш глибокого вивчення кінцевої точки прочитайте « Переправу прірви» Джеффрі А. Мура . Я міг би буквально написати книгу про те, як здійснити трансформацію DevOps, однак до моменту її закінчення, ймовірно, більше не було б роботи з перетворення DevOps.

DevOps має тенденцію до розбиття на три основні аспекти:

Культура Культура
DevOps підкреслює високий рівень довіри, співпраці та спілкування між усіма зацікавленими сторонами, особливо Dev, Ops та безпекою. Природна напруженість і конкуренція між цими групами створює тертя, а часто і дисфункцію. DevOps - це, мабуть, перш за все, вирівнювання зусиль між цими командами.

Процес
DevOps процеси розвитку вирівнювати близько до процесів Agile. Опсам рекомендується скористатися спритними методами, щоб краще підходити до зусиль Dev. Процеси, узгоджені DevOps, розроблені для підтримки високошвидкісних та швидких циклів зворотного зв'язку протягом життєвих циклів розробки / доставки. Безперервна інтеграція, безперервна доставка та постійне вдосконалення (kaizen) - основні напрямки процесу DevOps.

Технологія
DevOps не є інструментом, але підтримується інструментами. Існує ціла сім'я інструментів, що підтримують цілий спектр областей, включаючи постійну інтеграцію, управління джерелами та управління життєвим циклом додатків.

"Перетворення DevOps" має стосуватися елементів усіх трьох, але не обов'язково всіх однаково одночасно. Існує природний прогрес і "критичний шлях" до трансформації. Аргумент може бути зроблений, наприклад, що DevOps залежить від певної форми Agile практики, принаймні в межах команди / груп розвитку. Проблеми з культурою, можливо, потребуватимуть вирішення, перш ніж інвестувати кошти в інструментарій.

Список літератури:
Культура: https://www.andykelk.net/devops/using-the-westrum-typology-to-measure-culture
Technology: https://xebialabs.com/periodic-table-of-devops-tools/