Но как же так, есть же книга DevOps Handbook, самый авторитетный источник. В ней есть целый раздел, посвященный мифам о DevOps, зачем писать статью? Ну, дело в том, что, на мой взгляд, эта книжка не только объясняет методологию, но и местами её продаёт.
И раздел о мифах в ней — он такой, и содержит мифы, которые хотелось бы опровергнуть авторам, а не те, которые популярны в реальности. Тут же я постарался описать мифы, которые циркулируют в реальном мире, и с которыми мне приходилось сталкиваться, объясняя методологию своим слушателям.
1. DevOps к вам применим
Нет, DevOps подходит не всем. Этот миф идёт первым потому что некоторые отцы-основатели сами его исподволь продвигают.
Например, Gene Kim с соавторами в The DevOps Handbook как-то забывает упомянуть, что DevOps — он не для всех, зато спекулирует на тему его всеобщей применимости. Оцените цитату (я выделил проблемные части курсивом): “… there is now an overwhelming weight of evidence that the problems described above happen almost everywhere, and that the solutions associated with DevOps are nearly universally applicable.” Или вот: “In almost every IT organization, there is an inherent conflict between Development and IT Operations which creates a downward spiral ...”.
Да нет же, есть куча IT-организаций, для которых всё это совсем или частично не работает, если даже такие, где это неприменимо. Существуют организации, которые вообще не имеют отдела IT операций или продуктивной среды. Например, организации, которые занимаются консалтингом. Часто они могут иметь отдел поддержки, который обеспечивает соблюдение SLA, но могут и вовсе его не иметь: фирмы, которые внедряют Wordpress, например, или консультанты, которые занимаются тестированием безопасности. Есть IT — организации без отдела разработки. Многие хостинги — такие организации. У них всё может быть устроено довольно сложно, но весь софт может быть или чужим “коробочным”, или “облачным”, или написанным внешними консультантами.
Джон Оллспо пишет осторожнее (но Джон, зачем ты это пишешь?): “No matter what industry you are in, or what product or service your organization provides, this way of thinking is paramount and necessary for survival for every business and technology leader.”
Извините что врежу вашему консалтингу, ребята, но это не так. Верите что DevOps как способ мышления — важнейшая вещь при строительстве мостов и тоннелей? Тогда у меня есть отличный мост, который вы можете купить.
2. DevOps вам поможет
Будем считать что DevOps в принципе можно в какой-то мере реализовать для Вашей бизнес-функции. Однако, возможно, DevOps всё же не будет Вам полезен. За всё нужно платить:
- реализация DevOps потребует перестроить вашу организацию, это может быть долгим и рискованным мероприятием;
- нужно будет инвестировать ресурсы в перестройку технических практик;
- и, самое главное, непрерывная поставка потребует дополнительных затрат на каждую новую фичу, каждый день.
Разница в сложности реализации DevOps для разных моделей поставки ПО очень значительна. Совсем не трудно реализовать DevOps для веб-проекта в небольшой фирме, в то время как только техническая экосистема DevOps в рамках разработки браузера Chrome огромна и чудовищно сложна.
Может так случиться, что сама суть Вашего бизнеса не подразумевает большой пользы от DevOps. Например, вы выпускаете компьютерные игры с солидным бюджетом. Вы сможете быстро выпустить новую версию после проблем с 1.0.0. Будут ли Ваши пользователи терпеть проблемы и удерживать себя от удаления игры пока не выйдет версия 1.0.1? Или, может быть, Вы пишете софт для ядерного реактора, где цена ошибки слишком высока. Непрерывная поставка не имеет практического смысла там где нет возможности “пережить” ошибку время от времени.
Короче говоря, если такие блага, как:
- короткое время вывода на рынок (Time to Market, TTM),
- быстрое низкорисковое автоматизированное развертывание,
- постоянное наличие актуального релиз-кандидата,
- ровный и непрерывный поток работы
не способны оправдать цену, которую предстоит заплатить, то DevOps Вам ни к чему.
3. DevOps подходит только интернет-компаниям
Один из ключевых докладов “10 Deploys a Day” Джона Аллспо действительно был о нуждах Flickr — онлайн сервиса, и самые громкие истории успеха на самом деле произошли именно с онлайн-компаниями.
Однако, если у вас есть магазин, вы не должны переводить весь бизнес на DevOps, вы можете это сделать только с онлайн-подразделением. Если у Вас есть банк, Вам не обязательно переводить все функции на новую методологию, однако, вы можете получить преимущество, если переведете на новую методологию пользовательские интерфейсы личных кабинетов и рабочих мест.
В настоящий момент есть масса историй успеха “неонлайновых” компаний, которые перевели часть своих бизнес-функций на DevOps.
4. DevOps — штука техническая
Бытует мнение, что DevOps — это что-то, что делают разработчики там, админы, их руководители, одним словом, “технические люди”.
Несмотря на то, что без правильно реализованной технической части трудно себе представить эффективно внедренный DevOps, основное содержание DevOps как движения, связано с людьми.
Даже сверхбыстрое развёртывание не позволит драматически сократить Time to Market без переработки процессов для обеспечения сквозного потока задач и разделения знаний и ответственности, договоренностей с бизнесом и внутри команд.
Для того чтобы решить задачу встраивания качества недостаточно просто написать много каких-то тестов и собирать кучу телеметрии. Все эти меры должны быть глубоко понятны каждому ответственному за это члену команды, и, в идеале, должны как раз от них исходить. Всё это должно делаться с пониманием “зачем”, причём где нужно и сколько нужно.
Без научного подхода к работе, измерения результатов и проверки гипотез трудно представить те самые высокую эффективность и надежность, которые DevOps способен обеспечить.
Заметьте, что вышеперечисленное не является моментами чисто техническими, а скорее наоборот. И, как и в известном коане, действия без понимания тут также ничего не дадут.
5. Внедрить DevOps значит внедрить какой-то процесс или инструмент
Можно ли научиться следовать какой-то блок-схеме или установить какой-нибудь DevOps Server Ultimate 9000 — и дальше просто следовать наставлениям инструмента?
Для простоты начну с инструмента. Да, совсем без автоматизации внедрить DevOps на самом деле затруднительно, но всё же в большинстве случаев можно с той или иной степенью удобства и эффективности обойтись, скажем, Linux, git и bash. Будет ли это всегда максимально эффективно? Часто — нет. Будет ли работать? Да. Одну и ту же задачу с точки зрения DevOps можно решить совершенно разными способами. Иногда можно использовать Docker, но иногда можно решить вопрос постоянной фермой, Puppet и деплоем из git. Или реализовать то же самое в облаке, используя инструменты вендора. Хотите — используйте Jenkins, хотите — Bamboo, или, скажем, TeamCity, и в любом случае остаётся ещё GNU Make и чистые скрипты. Установить или купить все инструменты и ждать, что произойдет чудо — это как купить шикарный спортивный костюм, лучшие кроссовки на свете и ждать, когда Вам принесут олимпийское золото.
С процессом чуть сложнее. Давайте поговорим о Scrum. Scrum — это такой довольно формализованный Agile, который, как известно, подходит не всем. Гораздо большему числу команд подошёл бы какой-либо несколько иной вариант Agile, учитывающий специфику команд и бизнеса. Вот DevOps — это скорее как Agile, чем как Scrum. Подумайте, ведь “производственным” фреймворком для DevOps является Lean. С Lean ведь такая же штука — понятно, что Вы можете применять этот набор подходов, но какого-то единого для всех делай-раз, делай-два с общей конечной точкой ожидать не приходится. Какой бизнес, такой и Lean. Так же и с DevOps.
6. Не требуются другие специалисты помимо специалистов по DevOps
Даже если предположить, что могут существовать такие “специалисты широкого профиля”, многие специальности требуют потратить много лет на освоение и затем требуют постоянно ими заниматься чтобы не потерять квалификации: сетевики, программисты, специалисты по QA и т.д.
Помимо этого, некоторые виды деятельности требуют разного склада ума. Все мы знаем, что тестировать что-либо силами разработчиков и иметь специализированных специалистов по тестированию — совсем разные вещи.
Вовлекать разных специалистов в совместную работу чтобы они помогали своими знаниями и опытом как можно больше — вот что подразумевает DevOps, а не переименование одной из специальностей, например, админов, в DevOps-инженеров.
7. DevOps заменяет собой существующие подходы к управлению продуктом и инструменты
Новый консультант — новая методология — новая жизнь? Вовсе не обязательно. Во-первых, может быть DevOps Вам просто не подходит. Во-вторых DevOps — это не что-то, начатое с чистого листа. Да, DevOps — это зонтичный термин, который позволяет описать ряд управленческих и технических подходов, используемых вместе. Но большинство этих подходов совсем не новые, идут как минимум от заводов даже не Toyota, а GM и Ford.
Скажем, если вы давно внедрили Lean и используете “сквозной” Kanban для всех задач начиная от формулирования требований и заканчивая запуском на продакшн, то может быть DevOps уже у вас внедрен процентов на 50, а если у вас ещё и CD — то на 80.
Команда разработки использует Scrum с недельным циклом давно и продуктивно? Не нужно ничего ломать. Вы можете вполне жить с недельным циклом поставки, это законно. Можно иметь недельный цикл разработки и время вывода на рынок (TTM) неделю, а можно иметь возможность выкладывать за 17.6 секунд, но иметь цикл разработки и TTM 2 месяца.
Может показаться, что подход непрерывной поставки имеет фундаментальные противоречия с хорошими практиками в IT, безопасности и подобном. Это не совсем безосновательные подозрения, и у DevOps, определённо есть свои границы применимости. Однако, можно попытаться разбить системы таким образом, чтобы комплаенс сидел в редко изменяемых частях систем. Если комплаенс внутренний, может быть, наступил момент уйти от механического утверждения и перекладывания ответственности, и сформулировать реалистичные требования?
В любом случае, весь объем накопленных знаний, а не только DevOps, поможет лучше организовать работу.
Есть и другие
На этом я заканчиваю свой небольшой обзор мифов о DevOps, которые на циркулируют в реальности. В следующий раз я опишу популярные заблуждения, которые хоть и не неверны, но в которых есть доля истины.
А с какими мифами или умышленно насаждаемыми заблуждениями о DevOps сталкивались Вы?