Эффективный DevOps: 6 способов прокачать команду и себя

Виктор Ведмич

System Engineering Team Leader, EPAM

До сих пор бытует представление, что DevOps — это такой продвинутый сисадмин, который знает больше остальных сисадминов. На самом деле, DevOps — Development Operations — это культура процессов разработки. Сюда входит всё: как вы ставите приоритеты, какие технологии используете, как взаимодействуете с заказчиками и т.д.

Цель DevOps — максимально быстро доставить продукт. Причём продукт, который работает так, как нужно заказчику.

Я тружусь в команде EPAM почти 10 лет и хочу поделиться с вами принципами и подходами, которых мы придерживаемся в процессе разработки.

Постоянная обратная связь от клиента

Говорить «чем больше развёртываний, тем лучше» — это как говорить «чем больше строчек кода, тем лучше».

Весь мир использует Continuous Delivery — подход, при котором программное обеспечение производится короткими итерациями. Но инженеры часто забывают о том, что сам бизнес должен быть включён в процесс. CD не будет полным, если вы не добьётесь постоянной обратной связи — работает ли продукт так, как нужно клиенту? Новые функции востребованы? Помогают ли они в решении бизнес-задач?

Мы всегда предупреждаем клиентов, как часто будет проходить демо продукта. Даже если изменили «цвет одной кнопки» — обязательно покажем это на ближайшей встрече и аргументируем своё решение. Такой подход позволяет выискивать проблемы в интеграции намного раньше и решать их ещё на стадии разработки.

Чем раньше вы выявите ошибку, тем меньше времени потратите на её исправление. А это значит, что ваша компания сэкономит ресурсы — время сотрудников, серверные мощности и т.д.

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

Success Delivery

Какой прок в частых развёртываниях, если продукт работает нестабильно? Другой наш принцип — success delivery (успешная доставка продукта). Если во время или после развёртывания ничего не работает или работает плохо, то у клиента возникнет много вопросов. Так что success delivery напрямую влияет на доверие к вам.

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

Если говорить о подходах, то упомяну Blue-green deployment. В одном из моих проектов подход позволил и уменьшить количество ошибок, и сократить время доставки (с 4 часов до 30 минут).

Blue-green deployment — это создание копии продукта с новыми функциями рядом с предыдущей версией, на том же сервере. В нужный момент вы просто переключаете клиента со старой версии на новую. Прелесть паттерна в том, что если в новой версии что-то не работает, то можно сделать «свитч» обратно.

Другой подход: Canary deployment. При его использовании мы даём только 5% нагрузки на новую версию, и 95% — на старую, а затем оцениваем, как пользователи взаимодействуют с новым функциями и как система справляется с нагрузкой. Раньше Canary deployment можно было делать только на дорогостоящих девайсах, сегодня подход могут использовать все.

Максимально быстрая обратная связь для разработчика

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

А если я сделал коммит и тут же увидел сообщение, что что-то сломалось, то могу быстро вернуться в контекст и всё исправить.

Поэтому мы должны предоставлять очень быструю обратную связь, в идеале — через несколько секунд. Конечно, не всегда получается так быстро. Наши рамки — не более 5–10 минут. Это то время, за которое человек не успеет переместить фокус.

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

Не гонитесь за автоматизацией

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

Любая затрата должна окупаться. Если я потрачу на автоматизацию 160 часов, а сама задача обычно занимает 5 минут в месяц — пусть лучше она останется «ручной».

Конечно, иногда дело не только в ROI. Другой случай — задача большая, сложная, её трудно будет повторить. Тут автоматизация оправдана, она выступает в роли документации.

Или, например, автоматизация работы с облачным провайдером. Если мы понимаем, что проект большой и мы будем часто вручную работать с провайдером, есть смысл автоматизировать. А если заказчику срочно нужен MVP, чтобы проверить спрос, мы готовы сработать «некрасиво», вручную.

Предлагайте внедрять новые технологии

Мы не делаем технологии ради технологий, но всегда сообщаем клиенту, если что-то можно значительно улучшить.

Для начала клиент должен осознать проблему. Я, как эксперт в этой сфере, вижу проблему и сообщаю её клиенту, затем предлагаю решение и аргументирую свой подход.

Бывает, что клиент не готов инвестировать в решение и просит оставить как есть. В таком случае мы всё равно можем внедрять эту технологию, но уже в своё свободное время. Некоторые технологии сильно облегчают работу нам самим, так что оно того стоит.

На старте карьеры я работал с клиентом, у которого была не очень хорошая мониторинговая система. Мы предложили внедрить Zabbix, но он отказался, потому что не хотел тратить ресурсы. Постепенно мы развивали технологию на некоторых частях проекта сами, потому что это было удобно. В какой-то момент клиент увидел серьёзную выгоду и попросил внедрить Zabbix на всей платформе.

Не DevOps-специалисты, а delivery-команда

Над продуктом всегда работает delivery-команда. Такая команда отвечает за конечную доставку продукта, а не за какую-то часть работы. Слово «Delivery-менеджер» мы не придумали сами, оно уже существовало на рынке.

В практике EPAM delivery-менеджер — всегда технарь и, как правило, бывший разработчик. Даже если сейчас он не пишет код, то способен сделать code review.

Он знает, как устроены приложения, платформы и их компоненты изнутри. Может координировать архитектурные и технологические решения. Это не значит, что человек работает во всех этих ролях одновременно, но он понимает основы и может организовать команду.

Что касается delivery-команды, то это комбинация людей с правильными скиллами. Сюда может войти бизнес-аналитик, QA-тестировщик, UX-дизайнер, разработчики с нужным стеком и т.д. Команды каждый раз подбираются индивидуально в зависимости от проекта, подбором занимаются сами delivery-менеджеры.

Как правило, delivery-менеджер развивает специализацию на какой-то индустрии, будь то финансы, электронная торговля или сфера путешествий, и следит за её трендами. Поэтому delivery-менеджер ценен для заказчика — он понимает рынок и может предложить решения, которых не было в техническом задании, но которые выгодны для бизнеса.

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

Как развиваться в DevOps

Я участвовал во многих спорах, с чего нужно начать своё развитие в DevOps. Мне кажется, главное — база, фундаментальные знания, которые, к сожалению, часто отсутствуют у молодого поколения.

Знание сетей

У моего заказчика была интересная ситуация: при построении внутренней сети неопытные системные инженеры выбрали абсолютно случайный диапазон IP-адресов. И так получилось, что эти адреса совпадали с диапазоном, который использует AWS. Это серьёзная ошибка, для решения пришлось настроить маршрутизацию, проделать очень много работы. Если бы те инженеры хорошо понимали работу сетей, они не допустили бы таких катастрофических промахов.

Полезные ресурсы по теме:

• Учебный курс Андрея Созыкина «Компьютерные сети» (бесплатный курс по компьютерным сетям с серией коротких видео);
• Лекция Виктора Ашика «Сети и протоколы + Виртуализация».
• Лекция Виктора Ашика «Сети и протоколы» (видео-уроки о работе сетей, протоколах, устранении неполадок в сети, IP адресации и др.).
• В. Г. Олифер, Н. А. Олифер «Компьютерные сети, принципы, технологии, протоколы» 2-е издание (базовый учебник по компьютерным сетям).
• Э. Таненбаум, Д. Уэзеролл «Компьютерные сети» 5-е издание (книга по современным сетевым технологиям).

Операционные системы

Кто бы что ни говорил про контейнеры, но понимание ядра операционных систем остаётся актуальным даже в 2020 году. Windows или Linux — тут каждый выбирает, что ему ближе.

Полезные ресурсы по теме:

• Курс Microsoft 20410D — Windows Server 2012 R2. Установка и настройка (подробный курс по Windows Server 2012 R2).
• Введение в Linux (знакомство с операционной системой Linux и её базовыми возможностями).
• Эви Немет, Гарт Снайдер, Трент Хейн, Бэн Уэйли «Unix и Linux. Руководство системного администратора» (Unix и Linux. Руководство системного администратора).

Скриптинг

Это Python, Bash, Powershell. Нужно уметь автоматизировать рутинные задачи.

Полезные ресурсы:

• Scratch – Imagine, Program, Share (позволяет в игровой форме освоить базовые понятия программирования).
• Brad Miller and David Ranum «Problem Solving with Algorithms and Data Structures using Python» (интерактивный учебник по основам алгоритмизации и структур данных).
• CS50 на русском. Гарвардский курс по основам программирования.

Облачный провайдер

Я рекомендую начать с одного: Azure, AWS или Google Cloud. А дальше использовать CICD инструменты, например, Jenkins — нестареющая классика. Потом смотреть в сторону контейнеризации: Docker и Kubernetes.

Полезные ссылки:

• Introduction to Containers.
• Deploying and Scaling Microservices with Docker and Kubernetes.

Ещё несколько ресурсов, которые мне нравятся:

• Подкаст «Радио-Т» — каждую неделю здесь обсуждают последние околокомпьютерные новости.
• Linux Academy — классный проект. Он недешёвый, но ребята делают качественный контент.
• W3Schools Online Web Tutorials (общая информация о большинстве аспектов веб-программирования).
• CMTV [Грани Hi-Tech] (видео по самым разнообразным технологиям).

Как учиться

Мне сильно помогает Social Learning — когда ты учишься не один, а с кем-то. Это, во-первых, мотивирует не бросать, а во-вторых, ты знакомишься с разными точками зрения и подходами к одной проблеме. Сейчас готовлюсь к экзамену Certified Kubernetes Administrator. И готовлюсь не один, а вместе с коллегами. Мы встречаемся два раза в неделю по вечерам и разбираем кейсы. Экзамен хорош тем, что программа уже разложена по полочкам, притом ты сразу понимаешь, как это использовать на практике.

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