Но как такое может быть, есть DevOps Handbook, самый авторитетный источник.
Там есть целый раздел, посвященный мифам о DevOps, зачем писать статью? Ну а дело в том, что, на мой взгляд, эта книга не только объясняет методологию, но и местами ее продает. А раздел о мифах в нем именно такой, и содержит мифы, которые авторы хотели бы опровергнуть, а не те, которые популярны в реальности.
Здесь я попытался описать мифы, которые циркулируют в реальном мире и с которыми мне приходилось иметь дело, объясняя методологию своим слушателям.
1. DevOps применим к вам
Нет, DevOps не для всех.Этот миф появился на первом месте, потому что некоторые из отцов-основателей постепенно продвигали его.
Например, Джин Ким и его соавторы в The DevOps Handbook почему-то забывают упомянуть, что DevOps не для всех, но спекулируют на его универсальной применимости.
Оцените цитату (я выделил проблемные места курсив ): «…в настоящее время имеется огромное количество доказательств того, что описанные выше проблемы случаются почти везде , и что решения, связанные с DevOps, применимы практически повсеместно.
Или так: «В почти каждый В ИТ-организации существует внутренний конфликт между разработкой и ИТ-операциями, который создает нисходящую спираль.
» Нет, есть масса ИТ-организаций, для которых всё это не работает вообще или частично, и даже таких, где это неприменимо.
Есть организации, которые вообще не имеют отдела ИТ-операций или производственной среды.
Например, организации, которые занимаются консалтингом.
Часто у них может быть отдел поддержки, который обеспечивает соблюдение соглашений об уровне обслуживания, но у них может его вообще не быть: например, фирмы, которые внедряют Wordpress, или консультанты, которые проводят тестирование безопасности.
Есть ИТ-организации без отдела разработки.
Многие хостинговые компании являются такими организациями.
У них все может быть устроено довольно сложно, но весь софт может быть как чужой «из коробки», так и «облачным», или написанным внешними консультантами.
Джон Олспо пишет более осторожно (но, Джон, зачем ты это пишешь?): « Независимо от того, в какой отрасли вы работаете или какой продукт или услугу предоставляет ваша организация.
, такой образ мышления первостепенен и необходим для выживания для каждого лидера бизнеса и технологий.
” Извините, что критикую ваших консультантов, но это неправда.
Считаете ли вы, что DevOps как образ мышления — самое важное при строительстве мостов и туннелей? Тогда у меня есть отличный мост, который вы можете купить.
2. DevOps может вам помочь
Предположим, что DevOps в принципе можно в какой-то степени внедрить для вашей бизнес-функции.Однако DevOps может оказаться вам бесполезен.
За все нужно платить:
- Внедрение DevOps потребует перестройки вашей организации, что может оказаться длительным и рискованным мероприятием;
- ресурсы необходимо будет инвестировать в изменение технической практики;
- и, что наиболее важно, непрерывная доставка потребует дополнительных затрат за каждую новую функцию каждый день.
Внедрить DevOps для веб-проекта в небольшой компании совсем не сложно, а сама по себе техническая экосистема DevOps в рамках разработки браузера Chrome огромна и чудовищно сложна.
Может случиться так, что сама природа вашего бизнеса не предполагает особой выгоды от DevOps. Например, вы производите компьютерные игры со значительным бюджетом.
Вы сможете быстро выпустить новую версию после проблем с 1.0.0. Будут ли ваши пользователи терпеть проблемы и воздерживаться от удаления игры до выхода версии 1.0.1? Или, может быть, вы пишете программное обеспечение для ядерного реактора, где цена ошибки слишком высока.
Непрерывная доставка не имеет практического смысла там, где нет возможности время от времени «переживать» ошибки.
Короче говоря, если такие товары, как:
- короткое время выхода на рынок (Time to Market, TTM),
- быстрое автоматизированное развертывание с низким уровнем риска,
- постоянное наличие текущего релиз-кандидата,
- плавный и непрерывный поток работы
3. DevOps подходит только интернет-компаниям
Один из основных докладов Джона Олспо «10 развертываний в день» был посвящен потребностям 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 — это достаточно формализованный Agile, который, как известно, подходит не всем.
Гораздо большему количеству команд было бы полезно использовать несколько иную версию Agile, учитывая специфику команд и бизнеса.
DevOps больше похож на Agile, чем на Scrum. Подумайте об этом: «производственная» структура DevOps — это бережливое производство.
С Lean то же самое — понятно, что применять этот набор подходов можно, но нельзя ожидать единого подхода «сделай один раз», «сделай два» для всех с общей конечной точкой.
Как бизнес, как бережливое производство.
То же самое и с DevOps.
6. Никаких других специалистов, кроме специалистов DevOps, не требуется.
Даже если допустить, что такие «универсалы» могут существовать, многие специальности требуют многих лет на освоение, а затем постоянного обучения, чтобы не потерять квалификацию: сетевики, программисты, специалисты по обеспечению качества и т. д. Кроме того, некоторые виды деятельности требуют разного мышления.
Мы все знаем, что тестирование чего-то разработчиками и наличие специализированных специалистов по тестированию — это совершенно разные вещи.
Привлекать разных специалистов к совместной работе, чтобы они максимально помогали своими знаниями и опытом — вот что значит DevOps, а не переименовывать одну из специальностей, например, администраторов, в DevOps-инженеров.
7. DevOps заменяет существующие подходы и инструменты управления продуктами.
Новый консультант – новая методология – новая жизнь? Совсем не обязательно.
Во-первых, возможно, DevOps вам просто не подходит. Во-вторых, DevOps — это не что-то, что начинается с нуля.
Да, DevOps — это общий термин, описывающий ряд управленческих и технических подходов, используемых вместе.
Но большинство этих подходов вовсе не новы; они приходят, как минимум, даже не с заводов Тойоты, а с заводов GM и Ford. Скажем, если вы давно внедрили Lean и используете «сквозной» Канбан для всех задач, от формулирования требований до запуска в производство, то, возможно, DevOps уже внедрен процентов на 50, а если у вас еще есть CD , то на 80 процентов.
Давно ли и продуктивно команда разработчиков использует Scrum с недельным циклом? Не нужно ничего ломать.
Вы можете жить с еженедельным циклом доставки, это законно.
У вас может быть недельный цикл разработки и время выхода на рынок (TTM) в неделю, или вы можете выпустить продукт за 17,6 секунды, но иметь цикл разработки и TTM в 2 месяца.
Может показаться, что подход непрерывной доставки фундаментально противоречит передовым практикам в сфере ИТ, безопасности и тому подобного.
Это не совсем беспочвенные подозрения, и DevOps определенно имеет свои пределы.
Однако вы можете попытаться разбить системы так, чтобы обеспечить соблюдение требований в тех частях системы, которые редко изменяются.
Если соответствие является внутренним, возможно, пришло время отойти от механического утверждения и перекладывания ответственности и сформулировать реалистичные требования? В любом случае весь объём накопленных знаний, а не только DevOps, поможет лучше организовать работу.
Есть и другие
На этом я завершаю свой краткий обзор мифов о DevOps, которые не циркулируют в реальности.В следующий раз я опишу популярные заблуждения, которые хоть и не ошибочны, но имеют в себе долю истины.
С какими мифами или намеренно распространяемыми заблуждениями о DevOps вы сталкивались? Теги: #Управление разработкой #DevOps #Управление продуктом #управление командой #управление продуктом #непрерывная поставка #разработка программного обеспечения #разработка программного обеспечения #работа в команде
-
Гипервизор Против Руткитов: Как Это Работает
19 Oct, 24 -
Новое В Учете Суммовых И Курсовых Разниц
19 Oct, 24 -
Мессенджер Вконтакте Врёт
19 Oct, 24
