Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DORA State of DevOps как подход к технологическ...

DORA State of DevOps как подход к технологической DevOps-трансформации

DevOps Moscow meetup: Команды и трансформация, 17-12-2019
Рашид Галиев (Raiffeisen)

В своем докладе я расскажу про организацию DORA и ежегодный отчет State of DevOps, коснусь основных выводов, которые были сделаны в отчете 2019 года. А также расскажу, как мы в Райффайзенбанке используем предлагаемый подход для проведения технологической ИТ-трансформации.

DevOps Moscow

December 17, 2019
Tweet

More Decks by DevOps Moscow

Other Decks in Technology

Transcript

  1. Рашид Галиев В Raiffeisenbank работаю руководителем группы внедрения инженерных практик

    DevOps в команде, которая занимается трансформацией всего банка - ACCELERATION TEAM. Ранее я работал в Сбербанке и участвовал в технологической трансформации в качестве эксперта по методологии DevOps, инженерным практикам и инструментам визуализации данных. Мы внедрили практики DevOps в производственный цикл более 300 систем и 1500 команд.
  2. 4 Key Metrics Aspects of Software Delivery Performance Elite High

    Medium Low Lead time for changes - среднее время от коммита до прода Менее чем один день От одного дня до одной недели От одной недели до одного месяца От одного месяца до шести месяцев Deployment frequency - частота внедрений в прод По запросу (несколько внедрений в день) От одного раза в день до одного раза в неделю От одного раза в неделю до одного раза в месяц От одного раза в месяц до одного раза в шесть месяцев Change failure rate - доля неуспешных внедрений в прод 0-15% 0-15% 0-15% 46-60% Mean time to restore service - время восстановления сервиса при аварии Менее чем за час Менее одного дня Менее одного дня От одной недели до одного месяца
  3. State of DevOps 2019 • В основе технологической трансформации лежит

    быстрая, надежная и безопасная ДОСТАВКА изменений • Лучшие стратегии для масштабирования DevOps строятся с помощью формировании СООБЩЕСТВ внутри организации • Использование ОБЛАЧНЫХ ТЕХНОЛОГИЙ является характерной чертой самых производительных команд • Хорошая ПРОИЗВОДИТЕЛЬНОСТЬ помогает улучшить баланс между работой и личной жизнью сотрудников, а также СОКРАТИТЬ количество случаев ПРОФЕССИОНАЛЬНОГО ВЫГОРАНИЯ • Наличие прозрачного и понятного ПРОЦЕССА УПРАВЛЕНИЯ ИЗМЕНЕНИЯМИ позволяет согласовывать изменения быстрее и более предсказуемо, а также СНИЖАЕТ УРОВЕНЬ связанного с этим СТРЕССА
  4. How to… технические практики дающие МАКСИМАЛЬНЫЙ ЭФФЕКТ • Слабосвязанная архитектура

    • Прозрачный процесс реализации изменений • Поддерживаемость кода • Использование облачных сервисов • Тестирование аварийного восстановления Организационный уровень • Непрерывная интеграция • Автоматизированное тестирование • Автоматизация развертывания • Мониторинг • Trunk-based Development Командный уровень Оба уровня: командный и организационный
  5. How to… стратегии для DevOps-трансформации Хорошо работает Плохо работает •

    Учебный центр • “Большой взрыв” • Проверка концепции без продолжения • Сообщества по практикам • Подход “Снизу вверх” • Проверка концепции с последующим тиражированием
  6. Трансформация в Raiffeisenbank Процессы Инженерные практики Цель: 100% трансформирующихся команд

    соответствуют критериям Elite performers Продукт Инженерные практики
  7. Метрики в Raiffeisenbank Deployment frequency Change failure rate Mean time

    to restore Lead time for changes 1st level VCS SAST UT Autobuild Repository AD Dev AT Dev AD Test AT Test AD Preview AT Preview AD Prod 2st level 3st level Metric 1 Metric 2 Metric 3 Metric N Metric 1 Metric 2 Metric 3 Metric N Metric 1 Metric 2 Metric 3 Metric N Metric 1 Metric 2 Metric 3 Metric N Metric 1 Metric 2 Metric 3 Metric N Metric 1 Metric 2 Metric 3 Metric N Metric 1 Metric 2 Metric 3 Metric N Metric 1 Metric 2 Metric 3 Metric N Metric 1 Metric 2 Metric 3 Metric N Metric 1 Metric 2 Metric 3 Metric N
  8. О чем надо подумать • ЗООПАРК ИНСТРУМЕНТОВ - сложно получать

    данные из нецентрализованных инструментов без интеграции между друг другом • ОТСУТСТВИЕ ЕДИНОГО СПРАВОЧНИКА продуктовых команд – нет мастер данных, непонятен процесс актуализации и источники • НЕ ИЗМЕРИМОСТЬ ПРОЦЕССОВ из-за отсутствия данных, например есть кто работает на физических досках, нужно единое поле данных • ДОСТУП К ДАННЫМ в ПРОД средах – контуры, безопасность и т.д. • ИЗМЕНЕНИЕ ПРОЦЕССОВ – может быть необходимо для измерений, например частично ручной процесс инцидент-менеджмента • РУЧНЫЕ ОПЕРАЦИИ могут не содержать необходимые данные для мониторинга и измерений и не будут попадать на дашборды