DORA-метрики, внедрение Maturity Matrix , мониторинг и автоматизация с Ansible — DevOps Meetup

• Александр Кириллов, технический директор компании Врон, приветствует участников.  

• Компания занимается разработкой коммерческих проектов и предоставляет услуги DevOps как сервис.  

• В программе четыре доклада по DevOps, включая процессы и инструменты.  

• Игорь Курочкин, эксперт в компании Энейбблинг Тим, рассказывает о своем опыте в DevOps.  

• Он узнал о метриках из книги Аксель Рейд "Ускоряйся".  

• Игорь помогает компаниям проводить аудит DevOps и улучшать качество продуктов.  

• Обсуждение недавнего отчета о состоянии DevOps в России от компании Экспресс 42.  

• Игорь разочарован снижением метрик по сравнению с предыдущим годом.  

• Недостаток данных для анализа и гипотез.  

• Недостаток данных по опыту участников опроса.  

• Опытные специалисты могут лучше понимать метрики и процессы.  

• Молодые специалисты могут не понимать терминов и не видеть всей картины.  

• Необходимость открытых данных для анализа и проверки гипотез.  

• Пример компании Дора, которая публикует модели исследований.  

• Важность бенчмаркинга для крупных компаний.  

• Участие компаний реального сектора в аналитических отчетах.  

• Диджитализация и участие в ИТ-мероприятиях.  

• ИТ-подразделения становятся центрами инноваций и снижения затрат.  

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

• Игорь предполагает, что компании реального сектора знакомы с Дора и используют ее подходы.  

• Рекомендация посмотреть доклад Арины Гончаренко о метриках DORA.  

• Представление рекламной интеграции от партнера Lamoda Tech.  

• Lamoda Tech включает более 100 внутренних систем для обработки заказов.  

• В компании работает более 700 человек и более 300 микросервисов.  

• Используются современные технологии, такие как Helm и Kubernetes.  

• Переход на Open Source решения, улучшение мониторинга и трейсинга.  

• Работа с нагрузкой, прогнозирование и тестирование.  

• Унификация стандартов сборки и улучшение тестовых стендов.  

• Важность командной работы и регулярных встреч.  

• Приглашение прослушать доклад Арины Гончаренко о внедрении DORA метрик.  

• DORA метрики помогают оценить качество проекта.  

• Четыре ключевых показателя: скорость и качество.  

• Google выкупила DORA и продолжила исследование.  

• Отказ от использования платного решения GitLab.  

• Определение заинтересованной команды и внутренних процессов.  

• Разработка приложения на Python с использованием GitLab GraphQL API.  

• Метрики скорости и качества, включая кастомные метрики.  

• Визуализация метрик с помощью Grafana и Prometheus.  

• Анализ трех кейсов: ухудшение показателей, улучшение и успешные кейсы.  

• Рекомендации по улучшению процессов и бенчмаркинг проектов.  

• Использование DORA метрик для улучшения процессов и выявления проблем.  

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

• Призыв к обратной связи и вопросам.  

• Метрики необходимы команде разработки для улучшения процессов.  

• Метрики помогают понять, как новые процессы влияют на текущую картину.  

• Проект начался с изучения статьи на Хабре и книги по DevOps.  

• Команда уже имела некоторые процессы, но добавили шаблонизацию для веток.  

• Результаты показали, что метрики могут быть полезны для рекомендаций.  

• Метрики можно собирать открыто, это не влияет на репрезентативность данных.  

• Метрики помогают оценить текущее состояние проекта.  

• Результаты метрик могут быть разными, от элитных до лоу-проектов.  

• Планируется публикация статьи на Хабре и Гитхабе для переиспользования.  

• Тема: внедрение Maturity Matrices для улучшения разработки.  

• Maturity Matrices помогает аудировать процессы разработки.  

• Проблемы: отсутствие плана развития, непрозрачность процессов, непонимание ценообразования.  

• Внешний аудит можно провести своими силами.  

• Maturity Matrices помогает в переходе от стартапа к среднему бизнесу.  

• Подходы: DORA, DORA Core, DORA Radar, DORA Maturity, Gartner, Axencher.  

• Внедрение началось в августе 2023 года.  

• Опыт использования Maturity Matrices в других компаниях.  

• Maturity Matrices позволяет аудировать и улучшать продукты и процессы разработки.  

• В проекте 11 этапов, которые будут рассмотрены.  

• Статьи на Хабре и Гитхабе содержат полное описание матрицы.  

• Первый этап - сбор списка продуктов.  

• Определение количества продуктов и их характеристик.  

• Оценка продуктов как одного или нескольких.  

• Важность взаимодействия с тестированием и разработкой.  

• Определение ресурсов команды, включая тестирование и разработку.  

• Важность понимания внутренних и внешних ресурсов.  

• Упоминание ролей, таких как архитекторы и аналитики.  

• Корректировка концепта для конкретной компании.  

• Упрощение метрик для ускорения внедрения.  

• Важность общего концепта и блоков.  

• Описание блоков, связанных с разработкой, тестированием и сопровождением.  

• Важность процессов и взаимодействия команд.  

• Учёт безопасности и интеграции продуктов.  

• Создание единого языка для команды.  

• Описание процессов и инструментов.  

• Важность методологии и правил игры.  

• Использование классической модели зрелости.  

• Уровни зрелости: нулевой, базовый, средний, продвинутый, максимальный.  

• Важность визуальной градации и метрик.  

• Пересмотр применимых метрик для новой компании.  

• Важность визуальной градации для аудита.  

• Метрики: покрытие модульными тестами, время на сборку, подготовка тестового окружения.  

• Аудит требует значительных затрат нервных клеток и сопротивления команды.  

• Важно уметь отвечать на вопросы о необходимости аудита и согласовывать ресурсы.  

• В среднем и крупном бизнесе требуется поддержка топ-менеджмента.  

• Сопротивление нужно переводить в конструктивное русло.  

• Важно иметь вехи аудита для отслеживания прогресса.  

• Целевой уровень может меняться в зависимости от новых технологий и решений.  

• Необходимы поддержка и помощь от менеджеров и специалистов.  

• Важно планировать и согласовывать работы, включая ресурсы и сроки.  

• Необходимо уметь защищать свои предложения перед бизнесом.  

• Внедрение должно быть задокументировано и передано в разработку.  

• Контроль работ включает статусы, уточнения по срокам и календари.  

• Реаудит проводится раз в полгода для отслеживания изменений.  

• Внедрение матрицы зрелости продуктов увеличивает прозрачность.  

• Появляется процесс контроля развития продукта и его стоимости.  

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

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

• Важно оценивать результаты на основе метрик и качественного использования.  

• Успешное внедрение должно приводить к улучшению качества кода и снижению количества багов в продакшн.  

• Начинайте с пилота и сторонников.  

• Не масштабируйте сразу на всю компанию.  

• Полноценное внедрение может занять полтора месяца.  

• Важно иметь стратегию развития продуктов и систем.  

• Внедрение метрик помогает понять текущее состояние компании.  

• Метрики полезны как для улучшения, так и для понимания текущего состояния.  

• Прозрачность важна для бизнеса и ИТ-отделов.  

• Лучше делать аудит самостоятельно, если есть компетенции.  

• Внешние эксперты могут быть независимыми, но требуют контроля.  

• Внутренние аудиты могут вызвать сопротивление.  

• Важно использовать инструменты для сбора и анализа метрик.  

• Инструменты помогают визуализировать данные и защищать результаты перед руководством.  

• Инструментальный контроль важен для управления эффективностью сотрудников.  

• Перед внедрением метрик необходимо провести аудит.  

• Для аудита нужна минимальная команда, включая контролирующий орган или инициатора.  

• Внедрение требует инвестиций и времени ключевых специалистов.  

• В команде должны быть минимум три роли: тестирование, разработка и архитекторы.  

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

• Важно иметь методологию оценки фичей и багов.  

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

• Важно понимать, почему возникают проблемы и как их устранить.  

• Результаты аудита могут быть выложены на GitHub для улучшения и переиспользования.  

• Российские компании, такие как Флат Экспресс и Райффайзенбанк, активно внедряют метрики.  

• В крупных компаниях часто нет единого регламента для внедрения метрик.  

• Необходимы фиксированные регламенты для стандартизации процессов.  

• Обсуждение необходимости ГОСТов для внедрения метрик.  

• Анонс следующей серии о практическом применении подходов.  

• Призыв подписаться на канал для продолжения обсуждения.  

• Представление спикера Чаки Омарова из компании Ртелапс.  

• Обсуждение опыта реализации фонда антибауралей в компании.  

• Проблемы с качеством кода и необходимость стандартизации ролей.  

• Никаких ручных правок, все через Ansible.  

• Использование P20 для написания ролей.  

• Одна роль должна выполнять одну задачу.  

• Отдельные роли для базовой настройки ОС, дисков, ElasticSearch, Kibana.  

• Поддержка нескольких операционных систем и версий ПО.  

• Роли должны быть импотентами и покрываться тестами.  

• Роли обеспечивают установку и настройку ПО.  

• Обновление ПО не всегда автоматизируется, иногда делается вручную.  

• Удаление ПО не реализуется в ролях.  

• Роль как класс, плейбуки как реализация.  

• Роли описывают общие принципы развертывания ПО.  

• Плейбуки задают частные параметры и настройки.  

• Важность документации для поддержки ролей.  

• Роли хранятся в Gitlab, каждая роль имеет своего мейтейнера.  

• Изменения проходят этапы согласования и тестирования.  

• Роли именуются по назначению с использованием приставок.  

• Использование семантического версионирования.  

• Переменные хранятся в ролях и инвентаре.  

• Использование инструмента Molecule для динамического создания и удаления объектов конфигурации.  

• Возможность повторного запуска тестов без создания тестовых машин.  

• Использование зависимостей для тестирования ролей.  

• Пример с ролью закипера и кластером кафки.  

• Редко используются возможности сайт-эффектов молекулы.  

• Использование gitflow для внесения изменений.  

• Тестирование изменений перед слиянием в мастер.  

• Уведомления для заинтересованных лиц о новых версиях ролей.  

• Отведение отдельной ветки для обновления роли.  

• Тестирование на dev и test средах.  

• Изменение только варсов в продакшн среде.  

• Инфраструктурные роли: настройка безопасности и логирования.  

• Роли для сервисов: настройка кафки, постгреса и т.д.  

• Конфигурации для сервисов: управление топиками, пользователями и т.д.  

• Запрет на написание собственного кода.  

• Обучение и поддержка сотрудников.  

• Более 70 хорошо написанных ролей для нескольких ОС.  

• Устранение ошибок и улучшение качества кода.  

• Быстрый ченч див и применение изменений.  

• Использование лучших практик и концепций DevOps.  

• Использование системы тикетов для отслеживания изменений.  

• Прозрачность и простота процесса утверждения.  

• Обсуждение и проверка кода в рамках тикета.  

• Пробелы в коде могут влиять на структуру, что вызывает сложности у разработчиков.  

• Некоторые коллеги могут не использовать линтинг или отключать его.  

• Важно объяснять важность линтинга и чистоты кода, чтобы избежать негативных реакций.  

• Разбитое окно в здании может привести к разрушению всего здания.  

• Чистый и лаконичный код важен для предотвращения проблем в будущем.  

• Разработчики часто пренебрегают глубоким ревью кода, что может привести к ошибкам.  

• Конечное ревью кода проводится командой, включая руководство.  

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

• В компании выстроено единое инфополе, что помогает улучшать код.  

• Внутри компании образовалось комьюнити, радеющее за качество кода.  

• Это помогает тиражировать лучшие практики в другие команды.  

• Важно изначально писать код качественно, даже если это требует времени.  

• Компания работает с различными дистрибутивами Linux, включая старые и новые версии.  

• Некоторые системы поддерживаются только на старых версиях, но это не мешает их использованию.  

• Windows-машины также используются, но их количество ограничено.  

• Компания создала фонд ролей, напоминающий функционал Ansible Galaxy.  

• Документация и репозитории хранятся в GitLab.  

• Процесс актуализации документации включает писательский долг.  

• Компания поддерживает старые и новые версии Ansible для различных операционных систем.  

• Некоторые роли переписаны под новые версии, что требует обновления пакетов.  

• Старые версии Ansible могут работать на старых системах, но это не всегда оптимально.  

• В компании есть отдел, который проводит стресс-тесты на инфраструктуре.  

• Большинство ролей переписано и упаковано в Docker.  

• Основная роль для управления приложениями теперь использует Docker Compose.  

• Централизация данных может влиять на доставку чувствительных данных в инфраструктуру.  

• Компания прорабатывает тему централизованного хранения паролей и управления ими.  

• Инструмент для централизованного хранения секретов интегрируется с Ansible.  

• Конфигурация хранится в инвентарях, а не в ролях.  

• Пароли хранятся в ссылках, а не в открытом виде.  

• Это делает работу с Ansible более безопасной и похожей на современные инструменты для работы с инфраструктурой.  

• В Kubernetes операторы и среда выполнения могут быть скомпрометированы.  

• Контейнеризированные среды не являются отдельными виртуальными машинами.  

• Ansible позволяет безопасно хранить секреты на выделенных частях инфраструктуры.  

• Доклад стимулирует компании разработать централизованный подход к управлению ролями и инфраструктурой.  

• Переход к обсуждению мониторинга и observability.  

• Мониторинг инфраструктуры и приложений — масштабная тема.  

• Доклад будет разделен на три акта.  

• В стартапах часто отсутствует мониторинг.  

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

• Важно понимать, что скрывается за метриками и телеметрией.  

• Первый столп — логи, данные о поведении приложения.  

• Логи могут быть в разных форматах, включая JSON и стек трейсы.  

• Второй столп — трейсы, данные о запросах и их контексте.  

• Третий столп — метрики, данные о производительности и состоянии системы.  

• Мониторинг требует значительных ресурсов и времени.  

• Логи и метрики часто не интегрируются должным образом.  

• Метрики часто не дают достаточного контекста для принятия решений.  

• Запросы к Prometheus требуют высокого уровня навыков.  

• Метрики без контекста бесполезны.  

• Логи занимают много места и требуют структурирования.  

• Логи можно структурировать и извлекать метрики.  

• Использование аналитических баз данных, таких как ClickHouse.  

• Вендоры могут предложить решения для обсервабилити.  

• Обсервабилити требует глубокого понимания системы.  

• Важно обучать разработчиков работе с логами.  

• Использование различных форматов логов для разных целей.  

• Проблемы обсервабилити должны решаться командой.  

• Линейное руководство и разработчики должны работать вместе.  

• Важно учитывать потребности разработчиков и инфраструктурные аспекты.  

• Опираться на работы экспертов в области обсервабилити.  

• Подкасты и книги могут быть полезными ресурсами.  

• Важно продолжать учиться и развиваться в этой области.  

• Серробилити инженеринг выделилась в отдельную дисциплину.  

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

• Брендон Грег больше фокусируется на перфомансе, а не на стратегии.  

• Обсервабилити требует стратегического подхода.  

• Автор доклада делится своими выводами и личным путешествием в обсервабилити.  

• Вопрос о том, приведут ли новые инструменты к автоматизации анализа логов и метрик.  

• Инструменты, которые отсекают ложные гипотезы, будут наиболее ценными.  

• Автоматизация анализа метрик и логов на базе четкой логики.  

• Вопрос о стоимости и масштабируемости таких инструментов.  

• Появление интеллектуальных систем управления инфраструктурой.  

• Помощники для команд разработки в развитии обсервабилити.  

• Стартапы в области инцидент-менеджмента для быстрого устранения инцидентов.  

• Баланс между ценностью логов и их стоимостью.  

• Призыв к участникам делиться опытом работы с метриками и журналами.  

• Завершение этапа и ожидание продолжения.  

• Обсуждение состояния DevOps в России на 2024 год.  

• Ожидание новых статей и анализов рынка.  

• Призыв подписываться на канал и оставлять комментарии.