В больших компаниях обычно существует пропасть между людьми, которые делают, и людьми, которые сопровождают сделанное. Разные компетенции, разные области знаний, разная ответственность за функционирование продукта не позволяют компании эффективно разрабатывать и внедрять уникальные решения, вовремя менять часть технологического стека или весь стек целиком. Людям становится не интересно и сложно разбираться со старыми наработками, а внедрение новых сопровождается закостенелостью стандартов и инертностью компании. В рамках доклада будут рассмотрены следующие вопросы: - что сегодня помогает закладывать нужные оси вариативности в архитектуру? - как отделить и подружить разработку, внедрение и сопровождение? - как замотивировать людей быть эффективными, использовать удобные инструменты? - как дать людям свободу в их выборе и разделять ответственность за полученный результат? а также в программе: - Docker - микросервисы - закон трёх букв

1. Хипстеры в энтерпрайзе
Хи́пстер, хипстеры — появившийся в США в 40-х годах
термин, образованный от жаргонного “to be hip”, что
переводится приблизительно как “быть в теме”

2. @tolkv
2

3. @aatarasoff
3

4. Все события и персонажи вымышлены.
Любое сходство с реальными событиями и
именами случайно.
Discalimer
4

5. Это про нас
5

6. План
6
● Капитанская часть
● Что такое хорошо?
○ и что такое плохо?
● Что со всем этим делать?
● Результат
● Q&A

7. Люди говорят:
Надо быть гибким
7

8. Эволюция везде
8

9. Дано
9

10. Найди себя
Manager
DBA BA
UXDeveloper QA
Operations
10

11. Колодцы
Manager
DBA BA
UXDeveloper QA
Operations
11

12. 12

13. Пример №0: департамент версионирования
13

14. 14

15. Внедряем Agile
15

16. Слепые пятна после второго прихода
Manager
DBA BA
UXDeveloper QA
Operations
16

17. А что если не летит?
17

18. Проблема последней мили
Lead Time
Full Delivery Time
Cycle Time Cycle Time
18

19. Нас спасут инженерные практики
19

20. Чёрная дыра инженерных практик
Инженерные практики
20

21. Слагаемые успеха
Инструменты
Архитектура
и технологии
Инженерный подход
21

22. График хуяфик
22

23. Пример №1: унылость тестирования
23

24. Пример №1: унылость тестирования
?
24

25. Пример №1: унылость тестирования
25

26. Пример №1: унылость тестирования
26

27. Пример №2: инструменты не для всех
Spec by Example
Word/PDF
Код + тесты
IDE
Тест-кейсы
HP ALM
Developer
QA
BA
27

28. Пример №3: всё не так
v.2014-12-31.1.0.1.1 v.2015-01-10.1.0.1.2
Настройки в установку.2015-01-10.v2
28

29. Инженерный подход (Dev)
Мой код работает на моей
машине
Я написал инструкцию
админам
Я что-то сделал, пусть
тестировщик тестирует
Мой код работает у
клиента
Я написал скрипт
развёртывания ПО
Я должен написать тесты
29

30. Инженерный подход (Ops)
Мне дали инструкцию как
выкладывать продукт
У вас ошибка в инструкции
У меня есть документ как
настраивать сервера
Я написал скрипт
выкладки продукта
У нас баг в скрипте
У меня есть скрипт,
который настраивает
сервера
30

31. Преодолеваем отставание
31

32. Как это сделать? Принцип огораживания
32

33. Как это сделать? Принцип огораживания
33

34. Как это сделать? Принцип огораживания
34

35. Как это сделать? Domain Driven Design
35

36. Три типа разделения
по языкам/технологиям
по типам источников данных
по командам
36

37. Trade-Off: Принцип LSD
- L языков программирования
- S в среднем фреймворков на язык
- D типов источников данных
complexity = L * S * D
37

38. Простой такой пример
- три языка программирования
- два в среднем фреймворка на язык
- семь типов источников данных
- legacy WS, mongo db
- хранимые процедуры, JDBC-templates
- elasticsearch, neo4j
- мишкина база
complexity = 3 * 2 * 7 = 42 (!) 38

39. Чем нельзя жертвовать?
min (L * S * D) -> ?
39

40. Закон трёх букв
min (L * S * D) -> max (D)
40

41. Какие инструменты вам помогут?
Docker
???
???
41

42. Docker
Инкапсуляция имплементации
Унификация и стандартизация
Изоляция ресурсов
42

43. Docker глазами разработчика
43

44. Docker глазами саппорта: stressless архитектура
44

45. Так зачем Docker в энтерпрайзе?
45
Уменьшает уровень беспокойства у саппорта
Развязывает руки команде разработки

46. Какие инструменты вам помогут?
Docker
API
???
46

47. API на примере Docker-а
FROM docker.moscow.alfaintra.net/java8
MAINTAINER aatarasov@alfabank.ru
ADD payments-api.tar /
ENTRYPOINT ["/payments-
api/bin/payments-api.sh"]
EXPOSE 8080
docker run -P --name payments-api docker.moscow.alfaintra.net/payments-api:0.0.1
47
docker pull
docker run
docker logs
docker stop
docker start

48. API на пример Ansible-а
48

49. Какие инструменты вам помогут?
Docker
API
Mesos Ecosystem
49

50. 50

51. 51

52. О чём мы не хотим беспокоиться?
о серверах
о кластерах
о бюрократии
52

53. Apache Mesos
53
Кратко о возможностях:
● масштабируй
● изолируй
● управляй
● мониторь

54. Профит
Упрощение архитектуры: единый интерфейс для
управления ресурсами
Автоматизация: никто не любит быть разбуженным
посреди ночи - придаем свойство самовосстановления
своим системам
Эффективность: динамическое распределение
ресурсов с гарантированной изоляцией
API самообслуживания: прямой доступ к ресурсам для
команды разработки
54

55. Выводы
55
Manager
DBA
BA
UX
Developer QA
Operations
Software Engineer

56. Выводы
56

57. И на ход ноги
Не забывайте про закон трёх букв
min (L * S * D) -> max (D)
57

58. 58
Спасибо! Будем рады ответить на ваши вопросы.
@tolkv
@aatarasoff

59. 59

60. Выводы
Многие компании сделали ставку на инженеров
и не прогадали
Мы можем бояться дальше, а можем дать им ресурсы
и возможность творить
Но не дать сотворить “чудо” конечно же :)
60

61. Культурный выход
Из рюмочной выходят культурно
Воспитывайте культуру
61

62. Научный, сука, подход
Agile -> Гипотеза -> MVP -> feedback
DevOps -> Deployment Iteration -> Analyze Feedback -> Impove Standards
62

63. Тут нужно технически
В нашей культуре:
- свобода и ответсвенность
- DevOps ready architecture
63

64. Private PaaS
64

65. Кто в компании делает ПО
администраторы?
менеджеры?
может быть поддержка?
65

66. Rise of Software Engineers
66

67. А что нужно этим ребятам?
зарплата :)
свобода в принятии решений
67

68. Им НЕ нужно
беспокоиться о серверах
кластерах
бюрократии
68

69. Им важно
- им важны ресурсы
- memory
- cpu
- hdd
- io …
- Потому что только их они и умеют потреблять
69

70. Как результат
- Инженерная культура и свой собственны PAAS/IAAS
70

71. Как это сделать? На что обращать внимание
Архитектура это и про:
Итеративность изменений
Тестируемость
Конфигурируемость
Возможность автоматизации
71

72. Людям нужна свобода действий
Но:
Слишком много свободы - плохо
Не бывает свободы без ответственности
Люди должны быть к этому готовы
Свобода выбора - это очень тяжело
72

73. Проблемы сопровождения программного обеспечения
legacy-приложения
гетерогенные закрытые платформы
work-on-my-machine софт
постоянная борьба с пожарами
консервативные и перегруженные процессы
73