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

1. без булшита
DevOps

2. Кто мы?
/aatarasoff
/aatarasoff
habrahabr.ru/aatarasoff
developerblog.info
/myfoxicus
/myfoxicus

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.

5. 2015 2016 2017

6. Зачем вообще вам DevOps?
6

7. Быть крутым?
7

8. Всё автоматизировать?
8

9. Получить должность?
9

10. DevOps
для бизнеса
● Значительно сократить
time-to-market
● Повысить качество
инженерных решений в
продуктах
● Сократить стоимость
внедрения, эксплуатации и
поддержки

11. Мы знаем как делать DevOps
11

12. Что у нас уже получилось
Было
несколько дней
Низкая степень
автоматизации
Неэффективные
процессы
Вжух и
пара часов
Автоматизированная
установка и
верификация ПО
Время от окончания стадии разработки до
открытия функциональности для клиентов

14. Мы знаем как его не делать
14

15. Антипаттерн #1
Человек-DevOps

16. А#1. Следствие #1
Отдел DevOps

17. А#1. Следствие #2
Департамент DevOps

18. А#1. Следствие #3
Выделенный инженер
DevOps

19. История одной команды:
от менеджеров к инженерам
Кучка
евангелистов
Про идею!
Менеджеры,
Архитекторы …
Про как и куда!
Разработчики,
Тестировщики
Пробуем и улучшаем!
Команда
Берем и делаем!

20. Эволюция

21. Жесткая
специализация
Выполнение однотипной работы
каждый день
Изучение смежных
областей и
инструментов
Помощь другим участникам команды в
эффективном выполнение их работы
Автоматизация
своих действий
Использование инструментов и
практик для уменьшения рутины
Инженерный
подход
Непрерывное улучшение
инструментов и практик
Путь к инженерии

22. Антипаттерн #2
Таблицы
половозрелости
<KPI и метрики>

23. Метрики
1. Автоматизация
2. Аварии
3. Стабильность
4. Удовлетворенность
6. Lead time
5. Баги 7. Фин модель

24. Команда /
Что смотрим
Сборка на сервере Установка в бой
Укушенные
скрамом
Утомленные
канбаном

25. Неправильные
метрики
● “красно-зеленые” таблицы
● нацелены на разработку или
сопровождение
● не учитывают ценность для
бизнеса

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 %
// указаны календарные дни

28. Антипаттерн #3 DevOps - это только
про "dev" и "ops"

29. Неправильная
трактовка
● Dev = developers
(разработчики)
● Ops = operations
(админы, саппорт)

30. ?

31. DEV QA DEPLOYANALISYS SUPPORT
QA SUPPORTDELIVERY
ANALISYS
DEV
QA
Слияние аналитики,
разработки и внедрения
Доставка ПО - часть
разработки
Единые инструменты и
практики для команды
Нагрузочное тестирование
как R&D
Тестирование начинается
до разработки
Уменьшение рисков за счёт
атомарности внедрений
Непрерывный мониторинг
состояния системы
Эффективная обратная связь
команде
Тестирование на «живых»
клиентах
Перманентное ОПЭФокус на своём участке работы
Фокус на доставке ценности клиенту
Трансформация

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

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

34. Правильная
трактовка
● Developers - это вся
команда, которая работает
над ускорением доставки
ценности клиенту
● Operations - это всё та же
команда, которая работает
над тем, чтобы ценность не
только доставлялась, но и
работала прилично

35. Поймай
Скрам-мастера
Убеди
Продуктолога
● Developers - это вся
команда, которая работает
над ускорением доставки
ценности клиенту

36. Антипаттерн #4 КоТ пишут только
разработчики и
точка

37. Инженерные
практики
Непрерывная доставка ПО
Всё есть код:
- документация
- тестирование
- доставка и развёртывание
Парная работа,
кроссфункциональность

41. Все ходы записаны
Ссылки на артефакты:
- документация
- отчёт по
тестированию

42. <——— Интеграционные
тесты
<——— Сборка
завершена
<——— Деплой в тест

43. Инженерные
практики
Непрерывная доставка ПО
Всё есть код:
- документация
- тестирование
- доставка и развёртывание
Парная работа,
кроссфункциональность

44. Аналитик Разработчик Тестировщик

45. == Переводы между своими счетами
(получение списка лимитов)
Схема:
[plantuml,"a2a-limits", "png"]
----------
include::diagrams/a2a-limits.puml[]
----------
Параметры ответа метода
/search#POST
include::{snippets}/success/response-
fields.adoc[]
Пример ответа метода /search#POST
include::{snippets}/success/http-resp
onse.adoc[]

46. == Переводы между своими счетами
(получение списка лимитов)
Схема:
[plantuml,"a2a-limits", "png"]
----------
include::diagrams/a2a-limits.puml[]
----------
Параметры ответа метода
/search#POST
include::{snippets}/success/response-
fields.adoc[]
Пример ответа метода /search#POST
include::{snippets}/success/http-resp
onse.adoc[]

47. == Переводы между своими счетами
(получение списка лимитов)
Схема:
[plantuml,"a2a-limits", "png"]
----------
include::diagrams/a2a-limits.puml[]
----------
Параметры ответа метода
/search#POST
include::{snippets}/success/response-
fields.adoc[]
Пример ответа метода /search#POST
include::{snippets}/success/http-resp
onse.adoc[]

48. == Переводы между своими счетами
(получение списка лимитов)
Схема:
[plantuml,"a2a-limits", "png"]
----------
include::diagrams/a2a-limits.puml[]
----------
Параметры ответа метода
/search#POST
include::{snippets}/success/response-
fields.adoc[]
Пример ответа метода /search#POST
include::{snippets}/success/http-resp
onse.adoc[]

49. void "Верни ошибку 400, если в заголовке не указан customerID"() {
when:
def response = mockMvc.perform( post("/limits/search")
.header("applicationId", "spockTest"))
then:
response.andExpect( status().isUnauthorized()))
}

50. api-pipeline-template.groovy

51. //checkout and definition stage
node('build') {
// Mark the code checkout 'stage'
stage 'Checkout'
git credentialsId: 'jenkins-git',
url: "${git_url}/${repo}.git"
// Mark build 'stage'
stage 'Build'
sh ('./gradlew clean dockerBuild final')
}
//next steps

52. //checkout and definition stage
node('build') {
// Mark the code checkout 'stage'
stage 'Checkout'
git credentialsId: 'jenkins-git',
url: "${git_url}/${repo}.git"
// Mark build 'stage'
stage 'Build'
sh ('./gradlew clean dockerBuild final')
}
//next steps

53. //checkout and definition stage
node('build') {
// Mark the code checkout 'stage'
stage 'Checkout'
git credentialsId: 'jenkins-git',
url: "${git_url}/${repo}.git"
// Mark build 'stage'
stage 'Build'
sh ('./gradlew clean dockerBuild final')
}
//next steps

54. //checkout and definition stage
node('build') {
// Mark the code checkout 'stage'
stage 'Checkout'
git credentialsId: 'jenkins-git',
url: "${git_url}/${repo}.git"
// Mark build 'stage'
stage 'Build'
sh ('./gradlew clean dockerBuild final')
}
//next steps

55. //checkout and definition stage
node('build') {
// Mark the code checkout 'stage'
stage 'Checkout'
git credentialsId: 'jenkins-git',
url: "${git_url}/${repo}.git"
// Mark build 'stage'
stage 'Build'
sh ('./gradlew clean dockerBuild final')
}
//next steps

56. //checkout and definition stage
node('build') {
// Mark the code checkout 'stage'
stage 'Checkout'
git credentialsId: 'jenkins-git',
url: "${git_url}/${repo}.git"
// Mark build 'stage'
stage 'Build'
sh ('./gradlew clean dockerBuild final')
}
//next steps

58. и это тоже код

59. jobs.each { job ->
pipelineJob("${basePath}/${job}") {
//define SCM
definition {
cps {
script(readFileFromWorkspace('some_script.groovy'))
sandbox()
}
}
}
}

60. jobs.each { job ->
pipelineJob("${basePath}/${job}") {
//define SCM
definition {
cps {
script(readFileFromWorkspace('some_script.groovy'))
sandbox()
}
}
}
}

61. Инженерные
практики
Непрерывная доставка ПО
Всё есть код:
- документация
- тестирование
- доставка и развёртывание
Парная работа,
кроссфункциональность

63. АналитикРазработчик
Тестировщик
Единые инструменты
• git
• IDE (IDEA/ATOM)
• Asciidoctor
• Spock Framework
Совместные практики
• приёмочное тестирование
• TDD (разработка тестов)
• BDD (разработка авто-
тестов)
Совместные практики
• приёмочное тестирование
• TDD (проработка тест-кейсов)
• BDD (сценарии авто UI-
тестирования)
Совместные практики
• TDD (проработка тест-кейсов)
• документация
• нефункциональное
тестирование

64. Manager
DBA
BA
UX
Developer QA
Operations
Software Engineer

65. Антипаттерн #5
DevOps невозможно
делать на "старых"
технологиях

66. Правило
неизменно
● Developers - это вся команда,
работает над ускорением
доставки ценности клиенту
● Operations - это всё та же
команда, работает, чтобы
ценность не только
доставлялась, но и работала
прилично
● Клиенту безразличны
Ваши технологии

67. Изменение сознания (devops)
• Ваш фреймворк - старьё
• Лучше не трогать, а то
рванет
• У нас же тут оплаченная
поддержка от …..(некого
Enterprise)
• Скрестил ужа с ежом -
работает!
• Я тут автоматизировал
это и вот это, работает!
• Что за поддержка? Мы и
сами можем шевелить
усами

68. - Сёма, посмотрите на эти
мозолистые руки!
- Этот человек совсем не хочет
учиться автоматизировать
…...

69. А#5. Trade-off #1
Архитектура влияет
на трудозатраты

70. ?

71. А#5. Trade-off #2
Выше головы
не прыгнешь

72. Время от окончания стадии
разработки до открытия
функциональности для
клиентов
Было
~1 день
Низкая степень
автоматизации
Неэффективные
процессы
Что у нас уже получилось
Вжух и
~5 мин
Автоматизированная
установка и
верификация ПО
Время от окончания стадии
разработки до раскатки в тест
Было
~20 дней
Вжух и будет*
~5 дней
Что у нас в планах

73. Антипаттерн #6
DevOps - это
долго и дорого

74. Кто такой ШВЖ и зачем он вам?

77. Антипаттерн #7 Мы точно знаем
как делать

78. Они все тоже знают, как делать ...

79. Три составляющие DevOps
Мировоззрение - определяет
образ жизни и мышления людей,
подталкивает делать вещи
правильно
Архитектура - определяет
эффективность, степень боли и
трудозатраты
Инструменты и практики - дают
техническую возможность
реализации наших хотелок
Выводы

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

81. Выводы
Ставьте правильные метрики, но
не забывайте, что метрики всего
лишь метрики

82. DevOps – Agile с другого конца

84. СПАСИБО!

85. Ваши вопросы
/aatarasoff
/aatarasoff
habrahabr.ru/aatarasoff
developerblog.info
/myfoxicus
/myfoxicus