Методология DevOps у всех на слуху уже много лет. Различные организации пробуют внедрить DevOps, но сталкиваются с трудностями. В этой статье мы поговорим о тех типовых ошибках, которые допускают руководители компаний, когда пытаются внедрить DevOps.

Начнем с того, что большинство проблем при внедрении DevOps происходят не из-за сбоев в работе инструментов. То есть, они происходят из-за неправильных методов, коротких путей и неверных решений, выбранных при внедрении процессов DevOps.

Не только про технику

Самая большая ошибка, которую допускает абсолютное большинство руководителей, это относиться к DevOps как к набору инструментов. Обычно, менеджеры прочитав несколько статей, посвященных внедрению DevOps делают для себя выводы, что это просто набор инструментов, которые необходимо развернуть в своей инфраструктуре.

К примеру, можно внедрить связку Docker + Kubernetes + Jenkins и получить готовый DevOps. На самом деле здесь все несколько сложнее. DevOps это процесс, а не просто набор программного обеспечения. В случае, если мы внедряем только инструменты, у нас отсутствует как сам процесс, так и владельцы отдельных инструментов. Кроме того, нет фокуса на надежности работы всех инструментов, как единого целого – конвейера.

Отдельная, большая проблема при внедрении процессов DevOps это отсутствие сотрудничества между различными подразделениями. К примеру, разработчики пишут код, тестировщики затем тестируют получившееся приложение. Но между этими подразделениями нет тесного взаимодействия, в результате чего периодически происходят человеческие ошибки, когда разработчики отдают на тест не ту версию, или тестировщики применяют тесты не ко всему покрытию. Аналогичная ситуация и с взаимодействием разработчик с операционными подразделениями, которые собственно и сопровождают решение в продуктиве. Типичная история: приложение периодически падает, при этом поддержка винит во всем разработчиков, считая, что код плохо написан, в свою очередь разработчики считают, что в продуктиве решение сопровождается неправильно, что и приводит к сбоям. И все эти подразделения не могут между собой договориться.

Еще одной серьезной проблемой является автоматизация ради автоматизации, или автоматизация без понимания. Здесь многие компании зачастую пытаются автоматизировать не все процессы, которые необходимы или же не самые нужные. Так при наличии автоматизированного конвейера сборки у нас может не быть системы контроля версий и сохранение предыдущих версий осуществляется самим разработчиками вручную. Или же отсутствие автоматизированного тестирования ПО. Тестировщики вручную проводят все тесты периодически допуская ошибки.

Здесь наиболее правильным подходом является понимание того, что методология DevOps это прежде всего про процессы. Недостаточно только внедрить ряд технических решений, необходимо выстроить процессы взаимодействия между подразделениями, участвующими в разработке и внедрении ПО, привить понятие общей ответственности за выполняемую работу, продумать какие именно процессы и как нужно автоматизировать.

Что главнее инструменты или результат?

Важно понимать, что инструменты хотя и поддерживают DevOps, но они не определяют его. Очень часто при выборе инструментов, с помощью которых предполагается реализовывать DevOps, компании исходят не из решаемой задачи, а из того, какие инструменты им знакомы, доступны и т. д.

Например, в организации имеется экспертиза по продуктам Майкрософт. В итоге все решения разрабатываются под операционные системы соответствующего семейства с помощью инструментов от того же вендора. В последствии это приводит к тому, что разработчик сталкивается с различными трудностями (совместимостью, лицензионными ограничениями, требованиями по импортозамещению и т. д.) и вынужден тратить значительные средства на переделку своего решения.

Гораздо лучше было бы перед началом разработки провести анализ имеющихся на рынке инструментов и совместить их с теми требованиями, которые предъявляются к будущему решению. Да, при этом возможно придется обучить или нанять соответствующих специалистов, однако, как правило, это лучше, чем пытаться подстроить решение под имеющиеся инструменты и компетенции.

Отсутствие мониторинга

“Мы добавим мониторинг позже” – эту фразу можно часто услышать от разработчиков. Новые фичи, захват рынка, обогнать конкурентов – в этой технологической гонке мониторинг быстро превращается в тот самый технический долг, о котором так не любит вспоминать менеджмент.

В результате сбои остаются незамеченными, пользователи (а еще лучше, если руководство) первыми сообщают о возникших в работе приложения проблемах. Мы не можем заранее предвидеть возможные сбои, во время инцидентов у нас нет видимости и анализ первопричин выполняется слишком медленно.

Как следствие мы получаем не только высокую стоимость устранения сбоев, но и удар по репутация разрабатываемого решения. Никто не хочет, чтобы на рынке его продукт считали дырявым и глючным.

Здесь в качестве рекомендаций можно предложить отслеживать с первого дня работы продукта такие параметры, как: задержки при обращении к компонентам, частоту ошибок, объем трафика, загрузку процессора и памяти, диска, исправность используемых сторонних служб и т. д.

А если оповещений слишком много

Мониторинг предполагает уведомление операционной команды в случае инцидента. Нам мало просто отслеживать состояние компонентов, нам необходимо своевременно уведомлять ответственных специалистов в случае инцидента. Это достаточно очевидно.

Но возможна и обратная ситуация – оповещений слишком много. Обычно подобные проблемы возникают у безопасников, которые получают большое количество уведомлений о ложных срабатываниях. Однако и в мире ИТ подобное не редкость. Среди различных не очень нужных событий мы рискуем пропустить уведомления о действительно важных. Кроме того, если мы создаем инциденты по каждому из событий, то инциденты в свою очередь требуют принятия действий по расследованию и закрытию.

Если у нас слишком много не критичных инцидентов, то это приводит к дополнительной нагрузке на специалистов по сопровождению, как следствие к снижению качества их работы и профессиональному выгоранию.

Как при отсутствии уведомлений, так и при их избыточности, можно дать один и тот же совет: для начала определитесь с тем, какие именно инциденты для вас наиболее важны и постройте процесс работы с ними. Не критичные инциденты необходимо отсеивать. Настройте мониторинг таким образом, чтобы уведомления создавались только по наиболее важным событиям. Не забывайте об использовании инструментов визуализации, позволяющих повысить эффективность мониторинга всех систем. 

Все вручную

А часто ли вам приходится вносить изменения в настройки с помощью kubectl, или по SSH, или просто с помощью текстового редактора. В результате внесенное изменение нигде не отслеживается и наш DevOps снова рискует дать сбой, например в случае, если нам необходимо будет развернуть ту же конфигурацию для нашего решения на другом стенде. Ручные изменения нигде не будут задокументированы, в результате чего, приложение после нового развертывания будет работать не так, как мы ожидали.

Здесь хорошим решением является использование системы контроля версий, например Git для хранения не только исходного кода, но и конфигурации приложения, манифестов Kubernetes и т.д.

Помимо прочего, система контроля версий позволяет в любой момент времени откатиться к предыдущим версиям конфигурации, что бывает очень полезно в случае сбоев при обновлениях.

Заключение

Методология DevOps это не только (и в определенной степени не столько) про технику, сколько про процессы и взаимодействие между подразделениями и людьми. Внедряя DevOps мы должны понимать, как будет выстраиваться взаимодействие разработчиков, тестировщиков и сопровождения. Должно быть разделение ответственности за результат и понимание общих целей между всеми командами. Также важно построить процессы мониторинга и работы с инцидентами и не забывать о необходимости использования систем контроля версий. Тогда внедрение DevOps будет по настоящему эффективным и полезным для всей компании.

Когда DevOps в компании сводится к набору инструментов, проблема обычно не в Kubernetes и не в Jenkins, а в том, что никто не управляет процессом целиком. Курс DevOps Lead (управление командой девопс) как раз про этот уровень: как выстраивать работу команды, договариваться между разработкой, тестированием и сопровождением, читать технический контекст проекта и отвечать не только за стек, но и за результат.

Чтобы узнать больше о формате обучения и познакомиться с преподавателями, приходите на бесплатные уроки:

  • 12 марта в 20:00. «Командные конфликты – кто виноват и что делать?». Записаться

  • 23 марта в 20:00. «Джедай или Ситх? Собираем идеального руководителя команды DevOps». Записаться

Полный список бесплатных уроков марта смотрите в дайджесте.