Некоторое время назад мы решили проанализировать опыт, который накопили за последние годы проектов в DevOps-методологии. Мы развивались вместе с рынком и сейчас настало время зафиксировать лучшие практики, чтобы спланировать дальнейшее развитие. В этой статье поделимся своим видением, в каких направлениях мы будем двигаться, какие инструменты и навыки развивать.
Разные компании могут вкладывать разное значение в 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 работает не на технологиях, а на процессах. Поэтому самое важное – это чтобы специалисты в компании понимали свою роль в конвейере разработки, чтобы границы между разными отделами рисовались пунктиром.
В этом случае продукты будут разрабатываться быстрее потому, что на производственных линиях не будет медленных участков. А используемые технологии будут только помогать налаженным процессам.