DevOps, инженеры и сообщество

Работа в стиле DevOps совсем не похожа на классическую waterfall-разработку — процессы другие и инструменты другие. То, что его должны реализовывать другие инженеры, тоже очевидно. При этом DevOps пытаются делать через простое переименование системных администраторов в DevOps-инженеров. Что это за зверь — непонятно. Каждая компания придумывает для себя свою версию DevOps-инженера. Между тем инженерные практики DevOps требуют от инженеров новых навыков, другого взгляда на вещи, других компетенций. Это обычно называют «культурой» с некоторым оттенком религии, но культура — это всегда набор правил и навыков, без которых нельзя ничего сделать.

В нашем докладе мы разберем, какие в DevOps есть роли и схемы взаимодействия между ними, какие навыки и новые практики надо освоить инженерам, чтобы DevOps-процесс начал работать, и что бывает, когда они эти навыки не осваивают. Навыкам можно учить, можно распространять через сообщество — в этом важность сообщества, а не только в прикольном времяпрепровождении. Ключ к распространению культуры — сообщество.

Transcript

1. DevOps, Инженеры и сообщества
2. Александр Титов Кирилл Толкачёв
3. DevOops в Питере
4. DevOps для туристов
5. С Я.Картами всё проще *это не реклама
6. Туристу нужно ориентироваться...
7. Местным хорошо известны тонкости
8. VS
9. В 10 Раз лучше VS
10. Как DevOps заводится в вашей компании?
11. Хм, ничего нового Важный начальник Кто-то смелый и решительный Ммм... Им нужно что то новенькое?
12. Котел с Хренью Домыслы Враки Сейчас я им приготовлю...
13. Котел с Хренью Домыслы Враки Проверенное старое Сейчас я им приготовлю...
14. Котел с Хренью Домыслы Враки Проверенное старое Не пригодилось Сейчас я им приготовлю...
15. Скорость! Качество! Антихрупкость!
16. Кто внедряет?
17. C* Кто внедряет?
18. C* Кто внедряет? M*
19. C* Кто внедряет? M* IT
20. C-Level C*
21. C-Level C* Как???!
23. C-Level Курильщика DevOps
24. Таблицы половозрелости Используется Jenkins да Уровень 1 Пишутся тесты да Уровень 1 Автоматизирована доставка да Уровень 2 Еще что-то нет Уровень 2 Еще что-то сложное нет Уровень 3 ... нет ... ... нет Уровень 90
25. да Уровень 1 да Уровень 1 да Уровень 2 нет Уровень 2 нет Уровень 3 нет ... нет Уровень 90
26. C-Level - Нужна другая стратегия Должны: - Понимать и разбираться - Разбираться в технологическом процессе (понимать, почему одна компания может “быстрее” другой)
27. А нужно был разбираться
28. Что умеем делать Чему нужно учиться
29. Сильные и слабые стороны компании
30. квалификация кадров Сложность бизнеса
31. При чём тут DevOps?
32. При чём тут DevOps? У нас же трансформация
33. При чём тут DevOps? У нас же трансформация Светлое будущее там
34. Рост талантов 1. Нанимать хороших/лучших специалистов 2. Обучать существующих - Новые навыки - Улучшение старых
35. Кого нанимать-то? И как нанимать в условиях отсутствия таковых
36. Почему бы нам не нанять DevOps`a?
37. А следом и — 2х Аджайлов — 1го Вотерфола?
38. А следом и — 2х Аджайлов — 1го Вотерфола? — и наверно стоит нанять ТДД!
39. © @abashev DevOps как слава КПСС → Вообще не человек
40. Чему обучать-то?
41. Колодцы Исследование БТ ТЗ Разработка Тестирование Внедрение и сопровождение Технолог Разработчик Тестировщик Администратор Проектный менеджер Аналитик Колодцы/Silos
42. Туман войны
43. Туман войны В жизни
44. Туман колодцев
45. М Парк Kubernetes Озеро Docker Туман колодцев
46. Распространение опыта На яндекс картах вы видите только те районы, где побывали
47. Как объединить людей Достаём себя из колодца
48. Скопление знаний Wiki Общий Docker image DevOops
49. “Яндекс карта” – внутри компании 1. Если кто то уже выучил кубернетес, то другим уже достаточно посмотреть на карту 2. Карта с двумя разными значками на одном объекте (spring vs guice). В разных колодцах разные значки
50. М Улица Ansible Туман колодцев
51. М М Парк Kubernetes Улица Ansible Озеро Docker Туман колодцев
52. Единый словарь М М М М
53. Единый словарь М М М М
54. Единый словарь М М М М
55. Единый словарь М М М М М N — подходящих решений для бизнеса
56. Технологическая платформа + Навигация Общий словарь
57. Технологическая платформа + =
58. Технологическая платформа компании Переход от ролей к платформе и связям внутри компании Выравнивать людей не получится – но можно сплотить вокруг чего то Мысль про развитие платформы и процесса как конкурентного преимущества - Время, которое нужно для создания платформы для выходна на уровень производительности Х – конкурентной преимущество - Скорость производство – то как этим преимуществом можно воспользовать
59. Навык навигации Единая точка влияния
60. Навык навигации Единая точка влияния
61. Навык навигации Единая точка влияния Ценности Компании
62. Навык навигации DevOps культа – обязанности 1. понимать структуру компании 2. ценности компании 3. использовать это для решения проблем 4. использовать это для развития процессов ! Необходимо влиять и на технологии и на процесс ! Так же и технологии внутри компании, призваны помогать, как Я.Карты туристу, но не заменяют знания и умения
63. А кто нужен чтобы сделать это? (Diversity) - Нужно привести людей с разными взглядами на проблемы - На конференции все роли представлены в программе
65. SRE Технологический стэк
66. SRE Технологический стэк ...
67. SRE Технологический стэк ... ...
68. Infrastructure Engineer - Построение инфраструктуры, которое дает приложению память, процессор и сетевую связность так, чтобы все работало и было безопасно - Понимать и разбираться в железе, сетях, низкоуровневых стеках Задача - Сделать PaaS и предоставить IaaS внутрии компании
69. Infrastructure Engineer MEM CPU DISK NET LB APM APM
70. Infrastructure Engineer MEM CPU DISK NET LB APM APM Сервис обеспечения доступа (API) PaaS IaaS SaaS
71. Infrastructure Engineer MEM CPU DISK NET LB APM APM API доступа PaaS IaaS SaaS
72. Infrastructure Engineer MEM CPU DISK NET LB APM APM Сервис обеспечения доступа (API) PaaS IaaS SaaS
73. Service Engineer - Почему не иметь JVM инженера если у нас везде Java - Почему не иметь NGINX инженера если у нас везде Nginx Должен - Супер классно разбираться в конкретном инструменте
74. Service Engineer Технологический стэк ...
75. Service Engineer Технологический стэк ...
76. Service Engineer Технологический стэк ... ... ...
77. - Описывает в коде продукт, а не пишет алгоритмы - Думает как тестировать, мониторить, как код работает в продакшене Должен - Понимать бизнес-пользу и делать все, чтобы она была донесена Продуктовый разработчик
78. Продуктовый разработчик Сервис обеспечения доступа (API) Технологический стэк
79. Продуктовый разработчик Сервис обеспечения доступа (API) Технологический стэк
80. Человек - вирус
81. Итоговый профиль человека
82. Никто не откажется от помощи
83. Никто не откажется от помощи Но это требует доверия
84. Почему вы пришли на конференцию? - Вы решили, что опыт спикеров вам будет полезен, и решили довериться
85. Местным хорошо известны тонкости
87. Плавание в Нидерландах
88. Не плачь, херачь
89. Сообщество и DevOps
90. Сообщества - Митапы - Конференции - Внутренние митапы - Habrahabr
91. Сообщества - Митапы
92. Сообщества - Митапы - Конференции
93. Сообщества - Митапы - Конференции - Внутренние митапы - Habrahabr
94. Делай свое сообщество!
95. Выводы 1. Глубину конкретных знаний и способность ориентироваться совмещай + =
96. Выводы 1. Глубину конкретных знаний и способность ориентироваться совмещай 2. Информацию распространяй, сообщество строй + =
97. Выводы 1. Глубину конкретных знаний и способность ориентироваться совмещай 2. Информацию распространяй, сообщество строй 3. Колодцы внутри компании и вне ломай + =
98. Список литературы The Art Of Scalability Google SRE Servant Leadership Netflix Culture: Freedom And Responosibility Netflix Culture
99. QA 99 Не пишите в резюме DevOps Инженер @tolkv @osminog