DevOps-стратегия технологичной компании в 2021 году

Разные компании могут вкладывать разное значение в DevOps, поэтому для начала пара слов о том, что этот подход означает для нас самих. Хотя мы в True Engineering в этом отношении не слишком оригинальны – наше видение DevOps такое же, как у Amazon, Microsoft и других мировых лидеров разработки.

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

• Ускорение сборки и деплоймента кода (CI/CD).
• Ускорение поставок конечному пользователю (Time-to-Market).
• Сокращение ручных процедур.
• Улучшение взаимодействия команд между собой, с заказчиком и другими участниками работы над продуктом.

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

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

Про подходы к ведению проектов мы уже писали:

• как мы создали единый шаблон проекта для всех команд;
• как и зачем переводили всю компанию на единый трекер в Azure DevOps;
• как наши PM-ы выстраивают проектную аналитику, чтобы держать руку на пульсе.

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

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

Инфраструктура

Команда спланировала постепенный перевод всех информационных систем на единые шаблоны. Этот процесс включает такие шаги, как:

• Унификация кластеров Kubernetes - приведение к одному шаблону, миграция на новые версии и создание обвязки с помощью Ansible, GlusterFS, ELK.
• Миграция репозитория с Nexus на Harbor для безопасной работы с контейнерами, управления доступом на основе политик безопасности, контроля проверок безопасности.
• Переключение бизнес метрик и алертинга с Zabbix на Prometheus
• Обновление сопутствующих систем - MinIO, Gitlab, Nuget, SonarQube, NexusProxy, HAProxy, PostgreSQL, MongoDB, InfluxDB.

Инструменты

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

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

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

Методология

Мы наработали практику по переводу продуктов на производственные Kubernetes-кластера.

У DevOps-команды есть отработанные планы и чек-листы по миграции проектов. Есть отработанная практика по коммуникациям с командами разработки и инженерами заказчика.

Есть набор инструментов, которые мы можем переиспользовать: шаблоны HELM - чартов, пайплайны Gitlab\TFS.

Отработана методика постановки на мониторинг и работа с различными экспортерами метрик.

Процессы

Чтобы все участники DevOps-команды были на одной волне, а новичкам было проще погрузиться в работу, мы оттаиваем ключевые моменты:

• Планирование – учим правильно планировать работы и затраты, учитывать возможные риски в коммуникациях и технических деталях решений;
• Коммуникации – учим правильно общаться с командами разработки и заказчиком, чтобы не отправленное вовремя письмо не вызвало проблем;
• Наставничество – накапливаем знания, управляем задачами и помогаем решать возникающие трудности;
• Дежурство – внедряем распределение задач и дежурство, чтобы один инженер не оказался погребён под заявками и сообщениями в личку. Вместо личных сообщений – дежурный чат, дежурство на инцидентах, чтобы решениями проблем периодически занимались все по очереди.

Люди

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

За последний год мы расширили команду DevOps-инженеров и выстроили пошаговый процесс, чтобы каждый новый специалист как можно быстрее вставал в строй. Этот курс молодого бойца включает:

• изучение книг и курсов;
• работу на тренажерах;
• сертификацию;
• и главное, практику на боевых проектах. 

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

Что мы имеем в результате

Всё в совокупности обеспечивает руководству компании, PM-ам и всем командам стратегическое видение – как эксперты True Engineering повышают свою компетенцию, как максимально эффективно использовать новые техники и правильно выстроить процесс работы. 

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

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