∞ Эффективный DevOps: как прокачать команду?

Главные цели и задачи DevOps

Активное сотрудничество всех заинтересованных в развитии проекта сторон позволяет добиться следующих результатов:

• повысить частоту развертываний;
• ускорить выход продукта на рынок;
• уменьшить частоту отказов в новых выпусках;
• уменьшить время выполнения между исправлениями;
• увеличить среднее время восстановления.

Что делает команду DevOps эффективной

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

1. Предоставление обратной связи о сбоях (и их причинах) на этапе сборки для оперативного исправления проблем разработчиками. Возможность давать постоянную обратную связь сокращает время, необходимое для устранения проблем на позднем этапе. Этот процесс также известен как непрерывная интеграция (CI).
2. Максимальная автоматизация конвейера сборки и выпуска. Таким образом, ручные усилия сводятся к минимуму, сборки/развертывания становятся организованными, что ускоряет процесс предоставления результата заказчику.
3. Управление инфраструктурой (управление серверами на любом этапе, QA, pre-production и production) – еще один аспект, в котором инженер DevOps играет жизненно важную роль. Когда облачные сервисы, вроде AWS, используются все чаще, делать это намного проще, но управление инфраструктурой остается обязанностью инженера DevOps.

Чтобы организовать команду и сделать ее эффективной необходимо следующее:

1. Чтобы бизнес-требования организации и общее видение соответствовали целям команды DevOps. Так команда сосредоточится на конкретных бизнес-целях, а не будет просто выполнять рутинные задачи.
2. Выбрать подходящие инструменты. Инновационный набор инструментов и своевременное внедрение стека технологий поможет команде поддерживать эффективность.
3. Измерять эффективность команды. Например:

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

Советы от ведущего DevOps-специалиста

Об эффективных способах прокачки команды DevOps нашему корреспонденту рассказал Александр Крылов, Lead DevOps ПАО СК «Росгосстрах».

О принципах

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

В случае, если это бизнес-критичный функционал, для него дополнительно настраивается логирование и алертинг. Это мы проносим через культуру DevOps по всему циклу CI/CD, по необходимости, встраивая в pipeline автотесты и систему репортинга по ним, чтобы наблюдать за каждой итерацией прохождения этих тестов. Поэтому, в процессе разработки мы руководствуемся одним простым принципом – здравым смыслом.

О прокачке культуры DevOps в организации и среди команд

Для прокачки культуры DevOps в организации и среди команд существуют направления:

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

2. В случае крупных достижений или сложных внедрений, мы организовываем серию семинаров внутри команд. Например, успешно внедрили новую технологию, приготовили ее на базе какой-либо системы/проекта и начинаем масштабировать.

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

3. В компании существует матрица зрелости. О ней я упоминал в выступлении на конференции DevOps Live 2020 с темой «Построение мониторинга в дружбе с DevOps. Унификация процессов».

В концепт матрицы входит оценка системы по ряду блоков и критериев, например, тестирование или разработка. После оценки системы с лидами команд разработки и тестирования, принимается решение по тем или иным работам. Для бизнеса они обосновываются, как повышение уровня матрицы зрелости с последующим профитом, например, ускорение поставки кода в продакшн за счет внедрения CI/CD. Результатом этих работ является повышение зрелости систем и масштабирование практик DevOps в компании.

О внедрении новых стеков технологий

Регулярная активность компании – NAP, что расшифровывается, как Next Action Plan. Суть NAP – это обсуждение инициатив, например, по оптимизации процессов путем внедрения какой-либо утилитки.

Участник команды вносит в таблицу инициативу, после этого обсуждается ее целесообразность, и инициатива принимается, либо не принимается. В случае успеха назначается пилот технологии и ответственный за ее внедрение на примере решения одного кейса, который «болит». После этого проходит демонстрация решения этого кейса с использованием новой технологии. Если инициатива всех устраивает, мы ее внедряем и масштабируем. Путь усложняется, если внедрение требует денег.

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

Об ошибках в работе DevOps

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

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

Как развиваться в DevOps начинающему и опытному специалисту

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

По самому же DevOps, рекомендую прочесть:

• The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations;
• «Проект "Феникс". Роман о том, как DevOps меняет бизнес к лучшему»‎.

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

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

Выводы

Все больше организаций планируют внедрение DevOps. Высокие зарплаты и большое количество вакансий подтверждают этот тезис. Наиболее ощутимое преимущество – быстрая доставка программного обеспечения без ущерба для качества. Этой цели не удастся достичь без трансформации процесса разработки и принятия культуры DevOps, поэтому так важно продвигать ее среди сотрудников. Это приведет к фундаментальным культурным изменениям и модификации устаревших методов программирования. Тесное сотрудничество команды DevOps и согласованность между средами разработки, тестирования и производства сделает IТ-инфраструктуру компании более гибкой и эффективной.

Хочу научиться программировать с нуля, но не знаю, с чего начать. Что делать?

Можно учиться самостоятельно (долго) или пойти на курсы с преподавателями (быстро). Плюс нужно учитывать, что джунов много, конкуренция выше и работодатели повышают порог вхождения при найме на работу. Чтобы получить актуальные знания, мы в proglib.academy запустили курсы:

• Основы программирования на Python.
• Профессия Python-разработчик.
• Алгоритмы и структуры данных.
• Математика для Data Science.
• Профессия Data Science.
• Frontend Basic: принцип работы современного веба.
• Профессия Фронтенд-разработчик.
• Обработка естественного языка. Полный курс.

На подходе еще больше 10 курсов для взрослых и детей.