Связаться с редакцией
DevOps нельзя покорить раз и навсегда
Дата публикации:
20.01.2020
Посетителей:
148
Просмотров:
138
Время просмотра:
2.3
Чем отличаются DevOps и Enterprise DevOps?
Когда приобретать DevOps-решения не имеет смысла?
Зачем ИТ-подразделения регулярно пугают бизнес, если это уже не работает?
Сейчас на рынке неразбериха, и каждый думает о DevOps так, как хочет. Например, в моем понимании недавно появившийся термин DevSecOps избыточен, поскольку DevOps и так включает в себя безопасность. Скорее всего, его появление связано с необходимостью подчеркнуть, что безопасность является важной составляющей процесса.
Для меня DevOps — методология работы. В нее входят 3 составляющие: процессы, технологии и люди. К сожалению, не всем на рынке это понятно. Люди думают, что достаточно внедрить технологии, немного почитать о гибких методиках разработки — и это уже DevOps.
DevOps не вершина горы, покорив которую, можно расслабиться. Это путь, который выбирает компания, и важно понимать, что методологию придется постоянно совершенствовать.
Обучение людей тоже часть DevOps. Будьте готовы к тому, что как новых, так и существующих сотрудников, возможно, придется переучивать.
Существуют DevOps и Enterprise DevOps, их стоит различать. DevOps отлично подходит стартапам с небольшой командой и одним-двумя продуктами, которые нужно быстро вывести на рынок. В больших компаниях эта методология не выстрелит: слишком много связанных между собой решений и команд, кто-то работает по Scrum, кто-то — по Kanban, у всех разные инструменты. Для таких «зоопарков» и существует Enterprise DevOps с его стандартизацией. Например, команда работает над небольшим модулем документооборота, на который завязано множество систем. Именно использование Enterprise DevOps обеспечивает выход релизов и внесение изменений в эту систему без негативного влияния на смежные решения.
Обучение людей — тоже часть DevOps. Будьте готовы к тому, что новых сотрудников придется переучивать и встраивать в команду.
Обеспечивать DevOps можно с помощью проприетарных продуктов и решений Open Source.
Технологии Open Source отлично автоматизируют DevOps. Характерный пример — Jenkins.
При этом решения с открытым исходным кодом — далеко не панацея. Есть несколько распространенных мифов относительно Open Source:
Безопасность. Я часто слышу мнение, что в случае Open Source можно залезть в исходный код и легко в нем разобраться. Но делал ли кто-нибудь это на практике? Не уверен — там же тысячи строк кода. И точно так же я не уверен в том, что в нем нет бэкдоров или просто ошибок, которые никто еще не нашел.
Удобство работы. Open Source пишется гиками для гиков, так что у этих решений не самые удобные интерфейсы. В основном это командная строка или конфигурационные файлы, и разобраться в них непросто.
Функциональность. Процессы вокруг решений Open Source необходимо выстраивать самостоятельно. Бизнесу придется холить и лелеять человека, который будет этим заниматься. Если он уйдет из компании, работа просто остановится.
DevOps и Time-to-Market
Если лояльность клиентов падает, нужно ускорять Time-to-Market для своих продуктов. В В2С это давно поняли и стараются реагировать максимально оперативно. Вспомните, сколько клиентов привлек «Альфа-банк», когда запустил удобное мобильное приложение и сократил время фидбэка на обращения пользователей. В2В-сегмент пока отстает, но рано или поздно мы все равно к этому придем.
Ускорение Time-to-Market не стоит начинать с внедрения DevOps-инструментов. Сначала нужно понять, как реорганизовать работу компании. Какими бы эффективными ни были инструменты, пользоваться ими будут люди, а они не любят изменения. Важно донести до сотрудников, почему переход на новую методологию необходим.
Нет смысла приобретать DevOps-инструменты, не понимая, что именно вы хотите сделать с их помощью. Нужно начинать с road-map (куда и как компания будет двигаться) и только потом выбирать конкретные решения.
Основная выгода от перехода на DevOps — повышение скорости и гибкости разработки. В водопадной модели тестировщики, разработчики и эксплуатация не дружат между собой. В DevOps они становятся одной командой и учатся договариваться. Это заметно ускоряет разработку. К тому же у вас появляется возможность быстро менять планы, подстраиваться под реалии рынка и требования заказчика.
Разработка ПО — это экосистема, все элементы которой должны функционировать слаженно. Так что DevOps можно сравнить с дирижером в симфоническом оркестре.
В водопадной модели тестировщики, разработчики и эксплуатация не дружат между собой. В DevOps они становятся одной командой и учатся договариваться. Это заметно ускоряет разработку.
Почему ИТ пора перестать пугать бизнес
ИТ всегда считались сервисной и очень затратной функцией. Бизнес зачастую не понимал, что почта, телефон и CRM «не падают с неба», а требуют отдельных вложений. Тогда айтишники нашли простой, но неправильный выход — пугать непонятными цифрами, терминами, проблемами с безопасностью и скоростью работы. Сначала это помогало, но теперь бизнес ждет возврата инвестиций, детального объяснения, что и зачем приобретается, где можно сэкономить.
Взаимоотношения бизнеса и ИТ напрямую влияют на Time-to-Market. Если бизнес принимает стратегические решения о развитии, не учитывая ИТ-составляющую, в лучшем случае будут просто завалены сроки этого проекта. Ведь нужно как минимум создать/клонировать/масштабировать ИТ-инфраструктуру. В худшем — все заработает в срок, но с такими «падениями» и проблемами с безопасностью, что лучше было бы вообще не запускаться.
У ИТ все еще нет четкой связи с бизнесом. Конечно, бывают исключения, есть замечательные примеры того, как бизнес и ИТ гармонично взаимодействуют. Но, увы, в большинстве случаев они продолжают говорить на разных языках — на технологическом и денежном. Из-за этого бизнес зачастую считает, что магазин за один день построить нельзя, а переконфигурировать множество ИТ-систем — можно.
Есть распространенное заблуждение: если работало вчера, будет работать и завтра. Из-за этого бизнес не видит смысла вкладываться в ИТ. Бюджеты режутся, и ИТ-директор встает перед выбором: купить что-то новое (железо, ПО, услуги), оплатить поддержку системы или обучить сотрудников. Как думаете, что он выберет? Вряд ли обучение. К сожалению, распространенный ответ на вопросы ИТ-специалистов о повышении квалификации таков: «Поучитесь по документации, обучение надо заслужить». Хотя стоило бы оглянуться даже не на 40, а хотя бы на 10 лет назад, чтобы понять, как изменились технологии. И скорость изменений продолжает расти.
Руководитель крупного проектного бизнеса после разговора со мной сказала: «Оказывается, все можно объяснить по-человечески». До этого она успела уволить трех ИТ-директоров, потому что они сыпали непонятными терминами. Бизнес не хочет знать о петабайтах, процессорах и пропускной способности сети, для него гораздо важнее понимать, какую выгоду принесут инвестиции в ИТ.
