В своём докладе мы расскажем о том, что значит DevOps для нас, и как мы его готовим в большой организации со всеми её ограничениями, проблемами и челленджами как с технической, так и менеджерской точек зрения. Поделимся наработанным уникальным опытом в непростых вопросах: а зачем банку вообще нужен DevOps? как поставить более-менее правильные цели и продать это себе, своим коллегам, начальнику и бизнесу? Какие метрики нужно поставить, и попробуем разобраться есть ли в метриках счастье? Покажем, какие метрики были для нас окошком в Нарнию, и что в итоге получилось, расскажем про трансформацию людей и те инженерные практики, которые мы применяем (парная работа, тотальный кодинг, TDD, Infrastructure as a Code, API самообслуживания и т.д.), ответим на вопросы о том, что это за команда DevOps: какие грабли точно подстерегают нас, и как не наступать на них
3. DISCLAIMER
Наше мнение может не совпадать с официальной
позицией нашего работодателя, начальника,
коллег или других специалистов. Все
представленные в докладе цифры и факты
вымышлены, любые совпадения случайны. Всё, что
вы узнаете в этом докладе, вы можете
использовать на свой страх и риск. За все ваши
действия ответственность несёте только вы сами.
Мы настоятельно рекомендуем после выхода из
зала развидеть всё, что вы дальше увидите.
4. High-performing IT
organizations experience
60 times fewer failures and
recover from failure 168 times
faster than their
lower-performing peers. They
also deploy 30 times more
frequently with 200 times
shorter lead times.
10. DevOps
для бизнеса
● Значительно сократить
time-to-market
● Повысить качество
инженерных решений в
продуктах
● Сократить стоимость
внедрения, эксплуатации и
поддержки
12. Что у нас уже получилось
Было
несколько дней
Низкая степень
автоматизации
Неэффективные
процессы
Вжух и
пара часов
Автоматизированная
установка и
верификация ПО
Время от окончания стадии разработки до
открытия функциональности для клиентов
19. История одной команды:
от менеджеров к инженерам
Кучка
евангелистов
Про идею!
Менеджеры,
Архитекторы …
Про как и куда!
Разработчики,
Тестировщики
Пробуем и улучшаем!
Команда
Берем и делаем!
21. Жесткая
специализация
Выполнение однотипной работы
каждый день
Изучение смежных
областей и
инструментов
Помощь другим участникам команды в
эффективном выполнение их работы
Автоматизация
своих действий
Использование инструментов и
практик для уменьшения рутины
Инженерный
подход
Непрерывное улучшение
инструментов и практик
Путь к инженерии
26. Правильные
метрики
● нацелены на бизнес
○ время доставки
○ lead time
● нацелены на качество
○ количество дефектов
○ time budget
● нацелены на
удовлетворенность
○ NPS внутри команд
○ NPS клиентов
27. Наш вариант
Метрика 01.2016 07.2016
План проекта
на 12.2016
Факт 01.2017
Время доставки до
клиента от завершения
разработки
3-10д 2д 3 часа 2,5 часа
Длительность реализации 30д 10д 5д 3д
Время восстановления
после аварии 30-40 мин 20 мин 5 мин 0*
Длительность исправления
критических дефектов N/A 1,5д 1д 0*
Количество багов на релиз 4-5 3 1 0,16
Процент неудавшихся
внедрений N/A 0,9 % 0,7 % 0 %
// указаны календарные дни
31. DEV QA DEPLOYANALISYS SUPPORT
QA SUPPORTDELIVERY
ANALISYS
DEV
QA
Слияние аналитики,
разработки и внедрения
Доставка ПО - часть
разработки
Единые инструменты и
практики для команды
Нагрузочное тестирование
как R&D
Тестирование начинается
до разработки
Уменьшение рисков за счёт
атомарности внедрений
Непрерывный мониторинг
состояния системы
Эффективная обратная связь
команде
Тестирование на «живых»
клиентах
Перманентное ОПЭФокус на своём участке работы
Фокус на доставке ценности клиенту
Трансформация
32. Изменение сознания (dev)
• Мой коТ работает на
моей машине
• Я написал инструкцию
админам
• Я что-то сделал, пусть
тестировщик тестирует
• Мой код работает у
клиента
• Я написал скрипт
развёртывания ПО
• Я должен написать
тесты
33. Изменение сознания (ops)
• Мне дали инструкцию
как выкладывать
продукт
• У вас ошибка в
инструкции
• У меня есть документ
как настраивать сервера
• Я написал скрипт
выкладки продукта
• У нас баг в скрипте
• У меня есть скрипт,
который настраивает
сервера
34. Правильная
трактовка
● Developers - это вся
команда, которая работает
над ускорением доставки
ценности клиенту
● Operations - это всё та же
команда, которая работает
над тем, чтобы ценность не
только доставлялась, но и
работала прилично
66. Правило
неизменно
● Developers - это вся команда,
работает над ускорением
доставки ценности клиенту
● Operations - это всё та же
команда, работает, чтобы
ценность не только
доставлялась, но и работала
прилично
● Клиенту безразличны
Ваши технологии
67. Изменение сознания (devops)
• Ваш фреймворк - старьё
• Лучше не трогать, а то
рванет
• У нас же тут оплаченная
поддержка от …..(некого
Enterprise)
• Скрестил ужа с ежом -
работает!
• Я тут автоматизировал
это и вот это, работает!
• Что за поддержка? Мы и
сами можем шевелить
усами
68. - Сёма, посмотрите на эти
мозолистые руки!
- Этот человек совсем не хочет
учиться автоматизировать
…...
72. Время от окончания стадии
разработки до открытия
функциональности для
клиентов
Было
~1 день
Низкая степень
автоматизации
Неэффективные
процессы
Что у нас уже получилось
Вжух и
~5 мин
Автоматизированная
установка и
верификация ПО
Время от окончания стадии
разработки до раскатки в тест
Было
~20 дней
Вжух и будет*
~5 дней
Что у нас в планах
79. Три составляющие DevOps
Мировоззрение - определяет
образ жизни и мышления людей,
подталкивает делать вещи
правильно
Архитектура - определяет
эффективность, степень боли и
трудозатраты
Инструменты и практики - дают
техническую возможность
реализации наших хотелок
Выводы
80. Выводы
DevOps - это:
● про ускорение доставки
ценности клиенту
● не человек, не отдел и дело
даже не в разработчиках и
сопровождении
● про людей, которые умеют
программировать и решать
задачи на инженерном, а не
процессном уровне