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

1. Мы все DevOps
Михаил Чинков

2. STAGE
4
STAGE
2
STAGE
1
STAGE
3
2017
Продвигаю DevOps в
tech-компаниях
2014
Работаю в Web
2016
Размышляю о
DevOps
2018
Продвигаю DevOps в
компаниях Берлина
О себе

3. Обзор доклада
1
2
3
Терминология
Метрики
Реальность
Будущее4

4. ТЕРМИНОЛОГИЯ
Почему DevOps это не инженер?

5. Инженер и DevOps
1
2
3
Я не DevOps-инженер
Я скорее Platform Engineer (хоть и DevOps-driven)
В этом зале нет DevOps-инженеров
Термин “DevOps-инженер” – диарея Digital-индустрии4

6. “DevOps is the way of building
software for technology
companies

7. Lean
акцент на доставке
ценности юзеру
Culture
фокус на людях и
коллаборация
Automation
делегирование
рутины в workflow
Measurement
обратная связь из
метрик
Как видят DevOps евангелисты
Sharing
обмен знаниями и
практическим опытом

8. Lean
акцент на доставке
ценности юзеру
Culture
фокус на людях и
коллаборация
Automation
делегирование
рутины в workflow
Measurement
обратная связь из
метрик
Как видят DevOps компании
Sharing
обмен знаниями и
практическим опытом

9. МЕТРИКИ
Как понять насколько мы DevOps?

10. Data-Driven Business как аналогия

11. DevOps Report by Puppet Labs
So-so
Medium
performers
Perfect
Elite
performers
Good
High
performers
Deployment frequency
Lead time for changes
Time to restore app
Bad
Low
performers
Change failure rate

12. 24 capabilities

13. 24 capabilities
01 | Version control
02 | Deployment automation
03 | Continuous integration
04 | Trunk-based development
05 | Test automation
06 | Test data management
07 | Shift left on security
08 | Continuous delivery
09 | Loosely-coupled architecture
10 | Empowered teams
11 | Customer feedback
12 | Value stream
13 | Working in small batches
14 | Team experimentation
15 | Change approval processes
16 | Monitoring
17 | Proactive notification
18 | WIP limits
19 | Visualizing work
20 | Westrum org. culture
21 | Supporting learning
22 | Collaboration among teams
23 | Job satisfaction
24 | Transformational leadership

14. Adidas DevOps Maturity Framework
https://github.com/adidas/adidas-devops-maturity-framework

15. Проблема стандартов
1
2
3
Фокус на “outputs”, а не на “outcomes”
“Outcomes” невозможно стандартизировать
Состояние DevOps определяет сама компания
Компания этого не понимает
Сложнее приоритизировать движение к DevOps
4
5

16. Почему мы все еще не DevOps?
РЕАЛЬНОСТЬ

17. Домены проблемы
Bloody
Enterprise
Messy
Startup
Медленное развитие организации, сложности со
сменой вектора в головах тысяч сотрудников
Отсутствие источника знаний, проблемы с
выделением ресурсов на трансформацию

18. Было

19. Getting shit done
1
2
3
Переписали инфраструктурный код
Запилили человеческий мониторинг
Запилили космический core для CI/CD
Развернули человеческий Staging и QA
Конечно, все в контейнерах и на Kubernetes
4
5

20. Стало

21. Что не так?
1
2
3
Высокие требования ко времени решения задачи
Технология масштабируема, человек – нет
Демотивация обмена знаниями
Проблемы коллаборации (выгорание/апатия)4

22. Как нам стать DevOps?
БУДУЩЕЕ

23. Цикл развития
STAGE
4
STAGE
2
STAGE
1
STAGE
3
Knowledge
Инженеры самостоятельно
запускают и чинят live-
сервисы
Blackbox
Никто не знает о том, как
работает инфра
Awareness
Инфраструктура
прозрачна и понятна
инженерам
Contribution
Инженеры по желанию
контрибьютят в core
иннфраструктуры

24. Идеальная схема

25. Empathy
Стремление к
быстрому response
Coaching
Воркшопы, парное
программирование
Confidence
Уверенность
инженера как цель
Platform Team
Documentation
Покрытие всех
аспектов инфры
Balance
Чередовать технологии,
процессы и культуру
Product Team
Самоорганизация,
roadmap, stakeholders
Checklists
Процесс как рутинная
повторяющаяся операция
Снаружи Внутри

26. “Закрыв все культурные и технические
гештальты, DevOps-трансформация в
компании будет учитывать обратную
связь от бизнес-метрик и метрик
платформы

27. Вопросы?
Contact Blog