[Перевод] DevOps — это культура, а не роль
Любая крупная компания или организация, так или иначе, связана с разработкой программного обеспечения и должна быть единым целым. Очень важно быть гибким и действовать быстро, при этом не жертвуя безопасностью и надежностью. Порой такое давление выливается в отмену или приостановку проекта. В этой ситуации DevOps пытается решить, как именно заставить разработчиков и специалистов других областей сотрудничать и как их объединить вокруг набора общих целей для того, чтобы в меньшие сроки предоставлять надежное программное обеспечение клиентам и конечным пользователям. Ключевые технические приемы, лежащие в основе DevOps, включают в себя стандартизацию инструментов и методологий для команд по разработке и эксплуатации ПО. К этим приемам часто относятся:
- Автоматизированное управление конфигурацией, тестированием и развертыванием приложений;
- Контроль версий для обеспечения совместной работы и откатов;
- CI для автоматизации сборки кода и обеспечения высокого уровня обратной связи за счет более частых выпусков ПО с меньшим риском.
DevOps — это культурный взгляд на то, как каждый сотрудник должен работать правильно. Однако в программно-определяемом мире возникает куча вопросов.
Как мы узнаем, что нашли лучшее решение? Как быстро мы сможем обновить продукт и внести правки?
DevOps стремится привлечь всех заинтересованных, вовлекая их в процесс совместной работы на ранних этапах. Достижение успеха с помощью DevOps начинается с понимания его ключевых преимуществ для бизнеса. Работа компании ускоряется, простои становятся меньше и количество проблем с безопасностью снижается.
Майкл Дилворт, руководитель отдела трансформации Agile и DevOps, сказал:
DevOps — это культура, а не роль! Все в компания должны заниматься DevOps, чтобы он работал.
Необходима поддержка со стороны руководства и участие тех, кто заинтересован в конечном продукте, а не только отделов разработки и эксплуатации.
Я хотел бы поделиться с вами интересными теориями и практиками, вычитанными в одном из разделов документации Puppet.
Создайте бизнес-кейс
Как и многих IT-лидеров, вас просят не только создавать и предоставлять больше продуктов и услуг, чем когда-либо прежде, но и делать это быстрее и качественнее, без ущерба для надежности и безопасности. Кажется, что DevOps действительно поможет. Но… вы можете столкнуться со скептицизмом, даже не начав по-настоящему его применять.
Как привести четкие и убедительные доводы в пользу DevOps, которые уменьшат страх и сделают из скептиков чемпионов?
Этот вопрос — отличное начало. Создание бизнес-кейса — важная часть успешного внедрения DevOps (особенно в крупных организациях). В выступлении на TED Talk Саймон Синек отмечает общий знаменатель великих лидеров и катализаторов позитивных изменений:
Люди верят не в то, что делают эти лидеры, а в то, почему они это делают.
Эта идея верна при формировании организационной заинтересованности в переходе к DevOps. Просто заявление «Теперь мы занимаемся DevOps» не привлечет людей. Вместо этого нужен убедительный ответ на вопрос «Почему вы занимаетесь DevOps?» Все клиенты хотят ускорить свою работу, не ставя под угрозу безопасность и стабильность своих систем — это цели, которые противоречат друг другу в традиционных организациях. Перед разработчиками стоит задача как можно быстрее внедрить новые функции в продукт. В то же время специалисты по эксплуатации оценивают время безотказной работы и производительность систем. В итоге эти команды становятся противниками, а не союзниками. Как результат, развертывание сопровождается задержками и ошибками.
Dev
Более быстрое развертывание и циклы обратной связи позволяют добиться того, чего, по сути, и хотят разработчики: код попадает с их ноутбуков в руки пользователей намного быстрее, а непрерывное развертывание обеспечивает быстрые итерации и улучшения. Мониторинг времени выполнения изменений во время ранних пилотных проектов — хорошее начало:
- Как быстро код с ноутбука разработчика попадает в рабочую среду?
- Как это соотносится с вашими предыдущими сроками выполнения заказов? (Вы автоматизировали процесс сборки? Сократили ли вы количество тикетов, необходимых для развертывания?)
- Как часто вы проводите развертывания?
- Стало ли оно проще и быстрее?
Ops
Команда эксплуатации выигрывает, когда разработчики тесно сотрудничают с ними. Полезно начать сотрудничество с согласования общей цепочки инструментов и перечня совместных работ двух групп по внедрению одних и тех же инструментов, используемых при разработке, тестировании и развертывании. Это побуждает разработчиков активнее заниматься развертыванием и устранением неполадок, разрушая старые барьеры и повышая как скорость, так и надежность. Мониторинг нескольких показателей подчеркнет успех всей деятельности:
- Время безотказной работы/время простоя;
- Показатель откатов;
- Среднее время восстановления в случае сбоя.
Начните с малого и растите за счет первых успехов.
Как же измерить влияние DevOps на проект? Начните с небольших конкретных задач и проектов. Этот подход оказался очень эффективным для Терри Поттс (научный сотрудник и CTO по программному обеспечению в Raytheon).
Вы не можете изменить всю структуру и подход к работе, но вы можете начать с того, чтобы несколько ваших подгрупп двигались в правильном направлении. Может быть полезно привлечь кого-то со стороны, чтобы автоматизировать несколько тестов или сборок и дать команде несколько примеров для дальнейшего развития.
Благодаря автоматизации сборки одна из команд Raytheon смогла перейти от двух процедур интеграции в месяц к 27 за одну ночь. Это большая победа одной инициативы, которая стала ещё одним аргументом в пользу внедрения DevOps в организацию.
Начните с малого — не рассчитывайте продать DevOps всем и сразу. На самом деле, привлекая небольшие группы с конкретными проектами, вы создаете представителей, которые могут спос обствовать продвижению DevOps в других подразделениях компании, создавая эффект мультипликатора. При построении своего бизнес-кейса вы также должны помнить о потенциальных препятствиях на пути к долгосрочному успеху DevOps.
