Getting sh!t done in devops style — on TechTrain 2019

There is a huge amount of technologies, frameworks, methodologies, with help of which you can increase effectiveness. But nothing comes for free, let's see the real price of speed. How debts are created and who will have to pay for them, and we are not talking about classic technical debt — a patch in the code or lack of tests.

How to work without transferring debts to others? How to make decisions, aware of the consequences? Let's think about that together. Speakers, Maksim and Kirill will tell the practical experience and what they learned from it.

Transcript

1. Getting sh!t done
2. Getting sh!t done DevОps style
3. Дисклеймер Все, что будет здесь рассказано - это наш кумулятивный опыт и размышления на тему успешных и ошибочных решений.
4. Дисклеймер Все, что будет здесь рассказано - это наш кумулятивный опыт и размышления на тему успешных и ошибочных решений. Всегда стоит узнать про чужой опыт и послушать чужое мнение, но все услышанное надо анализировать на применимость в каждой конкретной ситуации.
5. Дисклеймер Все, что будет здесь рассказано - это наш кумулятивный опыт и размышления на тему успешных и ошибочных решений. Всегда стоит узнать про чужой опыт и послушать чужое мнение, но все услышанное надо анализировать на применимость в каждой конкретной ситуации. Используйте мозги и не впадайте в карго-культ - это самое главное.
6. Все истории вымышлены... ... но основаны на реальных событиях
7. Возможны проявления Капитана “Очевидность”
8. Возможны проявления Капитана “Очевидность” Но это нормально...
9. Почему мы рассказываем вдвоем?
10. Почему мы рассказываем вдвоем? Один умеет немного читать...
11. Почему мы рассказываем вдвоем? Один умеет немного читать... Другой немного писать...
12. @tolkv @lavcraft @gorelikoff @gorelikov В сумме больше 20 лет в IT
13. Проблематика
14. Забытые технологии предков - Кто приходил в новую компанию и видел тулы/бибилитеки/CI/CD которые вроде классные, но никто не знает как они работают?
15. Исторические слои - А кто приходил в команду и на вопрос что это за №;*;”№#! Получал ответ «Так исторически сложилось»?
16. Наркоманский технологический чемоданчик - Кто видел подобную систему: “У нас было 4 npm пакета, 75 jar`ов с библиотеками, 5 скриптов на перле, 3 на питоне и немного на баше, наполовину загруженный кластер кубернетеса, и целое море микросервисов на c#, go, rust, swift, dart.”
17. В чем причина подобных ситуации? Вася-разраб
18. Погоня за скоростью!!! Мне нужно закончить работу до 6 иначе не заплатят Вася-разраб
19. Иногда скорость - это данность Закончи к 6и вечера, у меня презентация Stakeholder
20. Stakeholder Я всё продал Давай в production
21. MVP Мы должны быть первыми! Stakeholder
22. В погоне быть первыми на рынке
23. В погоне быть первыми на рынке Недостаток автоматизации
24. В погоне быть первыми на рынке Недостаток автоматизации Костыли в коде ...
25. Это ужасно!
26. Это нормально
27. Будущие поколения нас проклянут!
28. Если они будут
29. MVP как покупка в кредит
30. Эйфория после запуска И ничего делать не нужно
31. Но коллекторы придут за долгом...
32. Если не к вам, то к тем, кто будет после вас
33. Если есть шанс, что этот мутант проживет чуть больше чем нужно...
34. … и его коснется кто-то кроме вас
36. Не перекладывай долги на других, если возможно Вася
37. А что такое Sh!t?
38. На вкус и цвет все фломастеры разные!
39. Stakeholder Сделали все быстро - красота
40. разработчик Быстро, но собрали из Sh!t
41. Ладно хоть денег заработали разработчик
42. Sh!t — то, за что разработчикам стыдно, но платят деньги
43. Компания пошла на взлёт Разработка идёт
44. Пора расти Нанимать людей, работы невпроворот
45. А кого же мы наняли CTO Backend Frontend Admin
46. Все неплохо...
47. Что у нас есть? Стабильный бэк
48. Что у нас есть? Стабильный бэк Быстрый фронт
49. Что у нас есть? Стабильный бэк Быстрый фронт Инфраструктура с мониторингом
50. Супер команда!
51. Супер продукт
52. ...но что-то идет не так
53. Быстрый фронт стабильно падает и мы узнаем об этом от клиентов
54. Стабильный бэк стабильно тормозит об этом пишут клиенты
55. Инфраструктура тормозит и стабильно падает, но мы узнаем об этом первыми :)
56. Как же так?
57. Команда супер наверняка все дело в технологиях!
58. Давайте посмотрим как мы выбирали технологии?
59. Инженерное сравнение технологий/подходов • Технология 1 • Технология 2 • Технология 3 • Технология 4
60. Инженерное сравнение технологий/подходов Мониторинг Стабильность Эксплуатация Обновление 1 1 1 1 Место в рейтинге
61. Инженерное сравнение технологий/подходов Мониторинг Стабильность Эксплуатация Обновление 1 3 1 1 Место в рейтинге
62. Инженерное сравнение технологий/подходов Мониторинг Стабильность Эксплуатация Обновление 1 3 4 2 Место в рейтинге
63. Инженерное сравнение технологий/подходов Мониторинг Стабильность Эксплуатация Обновление 1 2 1 1 3 4 3 3 4 3 4 4 2 1 2 2 Место в рейтинге
64. Инженерное сравнение технологий/подходов Мониторинг Стабильность Эксплуатация Обновление 1 2 1 1 3 4 3 3 4 3 4 4 2 1 2 2 Место в рейтинге
65. Инженерное сравнение технологий/подходов Телем Стаб Экспл Обнов 1 2 1 1 3 4 3 3 4 3 4 4 2 1 2 2
66. Инженерное сравнение технологий/подходов Телем Стаб Экспл Обнов 1 2 1 1 3 4 3 3 4 3 4 4 2 1 2 2
67. Инженерное сравнение технологий/подходов Телем Стаб Экспл Обнов 1 2 1 1 3 4 3 3 4 3 4 4 2 1 2 2
68. Мы все разные
69. Нужен общий фокус
70. Можно конечно попробовать совместить все лучшее Admin Backend Frontend
71. Но хорошо если у вас получится что-то такое Backend Frontend
72. А то ведь может и такое Fron@#$% Back%#$&
73. Надо договариваться о фокусе на каждом этапе жизни компании
74. Например, MVP - скорость разработки
75. Рост пользователей - производительность
76. Удержание пользователей - стабильность
77. Ну или конкретные SLA в цифрах но их должны знать все
78. Как держать фокус в тонусе – вывод №1 Чтобы фокус всей компании помещался в голову, нужно его простое «числовое» представление
79. Как держать фокус в тонусе – вывод №1 50ms request 1md feature 1h recovery time Чтобы фокус всей компании помещался в голову, нужно его простое «числовое» представление
80. Текущий SLA должен быть во всех головах команды
81. Текущий SLA должен быть во всех головах команды Особенно в условиях разработки на скорость
82. Телем Стаб Мндж Обнов 1 2 1 1 3 4 3 3 4 3 4 4 2 1 2 2 Фокус – лишь один сложность Количество фокусов 1 2 3
83. Телем Стаб Мндж Обнов 1 2 1 1 3 4 3 3 4 3 4 4 2 1 2 2 Каждому фокусу – своё время
84. Sh!t - это то, что появляется когда команда не договорилась куда тянуть продукт
85. Выводы №1 «Вектор скорости» → Чем быстрее нужно работать, тем чётче всем нужно двигаться в одном направлении
86. Вышли на рынок Разобрались с приоритетами
87. Ребятки, почему так медленно?
88. CI лагает Ребятки, почему так медленно?
89. frontend backend CI лагает БД не развернули Ребятки, почему так медленно?
90. frontend backend Админы ;№”#@! Админы ;№”#@! Ребятки, почему так медленно?
91. Ребятки, почему так медленно? frontend backend Админы ;№”#@! Админы ;№”#@! Мониторинг прода – важнее Admin
92. frontend backend Админы ;№”#@! Админы ;№”#@! Мониторинг прода – важнее Admin Agile Coach Ребятки, где ботлнеки? DevOps Consultant
93. Разобрались с узкими местами – админ Петя
94. Наймём Петя Заменителей
95. Так чтобы точно хватило
96. Теперь всё иначе Даже время осталось
97. В бэклоге нет задач для Админов?
99. Этож просто лендинг Тут чуть чуть подкрутить
100. Не вопрос Статика - Nginx логика - Lua Делов-то на час
101. lua nginx lua bash bash nginx lua html html bash cgi cgi
102. Инвестиции кончились
103. Нужно урезать штат
104. Админов не трожь!
105. Извините ребята, StoryPoint для вас нет
106. И это нормально!
107. Некоторое количество времени спустя
108. Нам нужен продающий лэндинг
109. Сейчас посмотрим, что там с лэндингом
110. lua nginx lua bash bash nginx lua html html bash cgi cgi
111. lua nginx lua bash bash nginx lua html html bash cgi cgi Василий посмотри на это
112. Какое изящное решение
113. nginx bash lua html cgi cgi
115. Sh!t - это когда вы не задумываетесь о проблемах на других слоях, от которых вы зависите
116. Sh!t - это когда в погоне за скоростью вы используете инструменты некорректно
117. Выводы №2 «Бутылочные горлышки» time amount sh!t time amount sh!t → С бутылочными горлышками бороться только вместе с командой → Не вынуждать людей принимать поспешные решение
118. Инвестиции вернулись
119. Наймем еще разработчиков
120. Сильно быстрее не стало
121. Что мы делаем когда все еще не хватает скорости?
122. Микросервисы!!!
123. Что могут дать микросервисы?
124. Что могут дать микросервисы? • Легко распараллеливать работу команд • Легко масштабировать • Архитектура системы получается более гибкой
125. Что могут дать микросервисы? • Легко распараллеливать работу команд • Легко масштабировать • Архитектура системы получается более гибкой • Свобода выбора технологий для нового сервиса...
126. Разработка...
127. Некоторое количество времени спустя
128. Нанимают первого Junior
129. Дают ему наставника
130. Новичек смотрит на зоопарк технологий
132. Он пытается скрывать эмоции, но так выглядит шок вперемешку с ужасом
133. Некоторое количество времени спустя
134. Пожалуйста остановитесь! CTO
135. Логичные доводы за логичную свободу - под определенные задачи лучше подходят определенные языки и технологии
136. Тут тонкая грань
137. Закон Конвэя
138. Закон Конвэя
139. Закон Конвэя
142. Так почему тонкая грань?
143. Свобода отвественность
144. Доводы “за” полную свободу - решаешь задачи с помощью того, что тебе нравится - новые возможности при поиске людей на рынке
145. Свобода зоопарка + Обратный закон Конвэя
146. Я тут фичу принёс
147. Я тут фичу принёс Фича, простая
148. Я тут фичу принёс. Нужно срочно сделать
149. Я тут фичу принёс. Нужно срочно сделать Ха, через 3дня забирай
150. Я тут фичу принёс. Нужно срочно сделать Фича, через 2 дня нужно сделать
151. Я тут фичу принёс. Нужно срочно сделать Хорошо
152. Спустя пару дней
153. Абстракции потекли
154. service service service service
155. service service service service Щас декомпозируем задачку
156. service service service service Щас декомпозируем задачку
157. Ruby Go Haskell Kotlin
158. service service service service
159. 2 недели спустя
160. Sh!t - это когда ставишь свою свободу выше чужих проблем в будущем
161. Выводы №3 «Свобода и последствия» time amount свобода time amount sh!t → Пользуясь свободой, задумывайся о том, какие последствия она принесет для других Отвественность
162. Теперь мы – корпорация
163. Нужно больше людей Срок Бюджет Качество Три всадника энтерпрайза
164. Опять нанимаем!
165. Опять нанимаем! У нас много планов
166. Опять нанимаем! У нас много планов и денег
167. Много новичков. Очень много
168. Много новичков. Очень много Нужно понижать порог входа
169. «Платформенная» команда Займётся этим
171. Сложно, новички не разберутся
172. Скроем сложность, пусть пишут только бизнес-логику
173. Inversion Of Control - cкрываем сложности в SDK
174. Core-команда создает SDK, плагины, библиотеки...
175. Перенос сложности Service code CI/CD Infrastructure сложность область
176. Перенос сложности Service code CI/CD Infrastructure сложность область Libraries
177. Перенос сложности Service code CI/CD Infrastructure сложность область Libraries
178. Перенос сложности Service code CI/CD сложность область Libraries Infrastructure
179. Sh!t – это когда перекидываешь сложность со своего слоя туда, где люди не готовы ее принять
180. Перенос сложности Service code CI/CD Infrastructure сложность область Libraries
181. Core-команды контроллирует весь процесс
182. Все под присмотром
183. Но с командой что то случилось
184. Ушли “играть” в другую команию
185. Попали в переделку
186. Спились
187. Это новичок
188. Он пытается скрывать эмоции, но так выглядит потерянность и непонимание
189. Компания вернулась в каменный век Почему?
190. Перенос сложности Service code CI/CD Infrastructure сложность область Libraries
191. Перенос сложности Service code CI/CD Infrastructure сложность область Libraries Призрачная сложность переноса
192. Перенос сложности Service code CI/CD Infrastructure сложность область Libraries Призрачная сложность переноса
193. ARTFMA Документация? Какая документация?
194. Передача знаний? Какая передача?
195. Передача знаний? Они все равно ничего не поймут
196. Не довёл до конца – сделал sh!t время amount sh!t
197. Sh!t - это когда ты спрятал что-то под коврик, но забыл об этом рассказать
198. Sh!t - это когда не доделал хорошее дело до конца и оно протухло после твоего ухода
199. Жизнь крутит – вертит
200. Но нужно терпеть и не вдаваться в крайности
201. Выводы • Делать sh!t – норма • Главное уметь с ним бороться
202. Когда вы в последний раз задумывались... А не sh!t ли я делаю
203. Вопросы @tolkv @lavcraft @gorelikoff @gorelikov
205. THE END
206. Ещё парочку историй?
207. Это конец. Дальше просто не вошедший контент
208. План перевыполнен Вы быстро закрываете задачи
209. Но кто разграебает проблемы?
210. Постойте, какие проблемы?
211. Я то молодец
212. Это всё эти
213. Это всё эти и эти
214. А эти отвечают Чо сказал криворукий?!
215. Хорошие плохие логи
216. Я ничего не понял и добавил немного логов
217. Я то молодец
218. Пришёл Вася из другого «отдела» Ты чо наделал Пёс?
219. Хорошие плохие логи
220. Хорошие плохие логи
222. Дыра в безопасности
223. В чем проблема? Кто виноват? И что делать?
224. Заплатка безопасности!