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

1. DevOps
трансформация
Альфа-Банка
Исанин Антон
api.alfabank.ru
learn.alfabank.ru

2. План доклада
1) зачем DevOps ? мы и без этого неплохо зарабатываем…
2) в чём проблема устроить DevOps в корпорации ?
3) опыт Альфа-Банка с DevOps, планы и резюме
4) секция “Вопросы и ответы”
10 мин
10 мин
15 мин
10 мин

3. Визитка
Исанин Антон
разработал стратегию развития DevOps в Альфа-Банке
работаю в Альфа-Банке с 2006 года
руководитель центра качества
Мы верим, что свобода — ключевая ценность современного
человека.
Объединяя неравнодушных людей, их опыт и энергию, мы
помогаем вам быть свободнее в поступках и мечтах. ​​​​​​
Альфа-Банк:

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

5. Насколько нужен DevOps
банку?

6. Может ли CIO убить Банк ?
Может быстро убить:
Может медленно убить:
переведёт на цикл обновлений
раз в полгода/год
заморозит все изменения

7. В итоге кто-нибудь позаботится
о несчастной организации

8. DevOps от страха?

9. Нет. Ещё мы хотим денег
Хотим
денег
Повысить
тарифы
Проблема Варианты решения
Создать
полезную
услугу
Плохой вариант Хороший вариант

10. Давайте “хороший вариант”!

11. Есть проблема…

12. Водопадная проблема
Делаем медленно, делаем ненужное
180 дней разработать 180 дней внедрить

13. Давайте делать быстро и
нужные людям вещи !
идея !

14. DevOps:
быстрая доставка изменений!
фокус на рынке,

15. Что нам даст DevOps?
DEV OPS
1) Быстрые и частые релизы
2) Качество и стабильность
3) Свобода и правильная архитектура
4) Автоматизация
DevOps
Движение к цели короткими и частыми
релизами
Автоматизация тестирования, практики Test
everything, ответственность за пром.
Максимально устраняются внешние помехи на
пути доставки продукта на рынок
Максимальная автоматизация рутины, дизайн
процессов: “human by exception”
Будем часто изменения делать
Качество будет высокое
Архитектура будет правильная
Автоматизируем рутину

16. С чего начать ?
DEV OPS
“Небизнес”
“Бизнес”
4 000 чел
20 000 чел 1 000 чел1 000 чел
Люди Технологии
Много людей, все люди заняты чем-то полезным ,
очень много коммуникации
Много систем, все системы делают что-то
полезное

17. Схема такая:
Топ
Мидл
Персонал
1. Стратегия
2. Deliverables
3. Живой пример
1. Disruptive-шок
2. Возможность адаптации
1. Возможность обучения
2. Возможность адаптации

18. Почему DevOps Disruptive ?
Потому что мир “большого ИТ” не будет больше прежним:
заявки, регламенты, ручная работа – всё в прошлом
Элементарная автоматизация установки обновлений в тестовые среды
даёт 20-кратный выигрыш по скорости выполнения процедуры

19. Проблемы запуска DevOps в корпорации
1) Требуется работать со всеми end-to-end, от “бизнеса” до “support”
2) Начинается всё с архитектуры с высокой связностью систем – ”спагетти”
3) Менеджмент (топ и мидл) должен поверить в то, что DevOps всё изменит
4) Над продуктовой культурой превалирует проектная :
“сдал проект и забыл”
5) Люди в командах не приучены к самостоятельности

20. В какой-то момент придётся заняться
“отстрелом зомби”
Нам потребовалось ~ полгода, чтобы увидеть,
что люди начали изменяться (а кто-то не начал)

21. Опыт Альфа-Банка с DevOps

22. 2015 год – всё началось с серьёзной аварии
Прочее
Oracle Exadata
Шина IBM WBI
10% Spring
boot/ docket
Приложения на iSeries
платформе включая АБС Банка
Монолитные
приложения
Монолитные приложения
Монолитные
приложения
1%
Монолитные приложения
Boom !
После установки
обновления кредитный
конвейер стал на полдня.
Мы не смогли выдать около
20 тыс кредитов, упустили
выгоду…
задумались, что-то
происходит неправильно

23. Анализ проблемы с командой конвейера
Внешняя
разработка
1) ставим 300 изменений в год – нормальный темп
2) автоматизация не нужна, потому что все этапы проходят быстро:
за полдня можно всё поставить, автоматизация экономически не выгодна
3) есть проблема в качестве кода – много дефектов, это бы как-то полечить, но внешняя
разработка…
Банк
15
мин
120
мин
15
мин
15
мин
15
мин
Оценка командой своих действий:
“полдня” до промсреды
Банк

24. Смотрим, что в реальности
Внешняя разработка Берём дату выкладки поставки в
хранилище поставок
Промышленная среда
Берём дату установки поставки в
промышленную среду из HPE SM
Date_Start
Date_Finish
Date_Finish Date_Start Delivery_Time
Время доставки изменения в
промышленную среду от момента сборки

25. Видим очень длительную доставку изменений
Поставка может гулять по
Банку 190 дней,
прежде чем доберётся до
production
80
180
280
Днейнатестизапусквпром

26. Решили сделать автоматизацию /
модернизацию
Внешняя
разработка
Банк Банк
“полгода” до промсреды
Здесь решили сделать
сквозной автомат

27. Деплой в тест сократился в 18 раз
Было: время от 90 минут
до 3 дней и более Стало: 5 минут
Что делать с людьми, которые
раньше делали деплой ???Стало: Jenkins, Ansible,
Python, Ruby:
Было: регламент,
заявка, человек

28. 2016 год: стратегия и внутренние продажи
Невероятно!
Современные технологии
напрочь разрывают старые
процессы!
Требуется переосмысление
стратегии развития!

29. Есть проблема… Waterfall не стал лучше…
от автоматизации доставка
быстрее не стала…
80
180
280
Днейнатестизапусквпром

30. Waterfall
Scrum
Выбираем перспективные команды
Рекламируем “новые
технологии”: обучаем Ansible,
показываем Jenkins, Cucumber.
Product owners задаём вопрос:
“а есть ли у тебя pipeline в
production? ”
pipeline в production 2016:
Автосборка Автодеплой
тест
Автотест Автодеплой
нагрузка
Авто
нагрузка
Автодеплой
пром

31. Как команды делают приёмочные тесты ?
Все команды пишут приёмочные
тесты на Cucumber

32. Почему Cucumber – это хорошо?
1) Написал тест по-русски в txt файле
Дано : Зашли пользователем “Anton”
Затем: Проверили корректность авторизации на
портале
И ввели в поле “Основной поиск” значение “FIO Fizik”
2) Запустил Cucumber
Error нет обработчика на фразу ”Зашли
пользователем”
3) Написал обработчик на фразу
”Зашли пользователем”4) Запустил Cucumber
Error нет обработчика на фразу
”Проверили корректность авторизации
на портале ”
Cucumber помогает писать framework

33. Автонагрузка
Можно вызвать
HPE Performance Center
Можно вызвать JMeter с
Cucumber скриптами
По результатам теста вызвать веб-сервис для анализа
вектора результатов, чтобы перейти на следующий этап

34. Что получилось:
Команда, разработавшая продукт с
нуля, научилась доставлять
изменения в пром за 1 день
Претензии клиентов
Открытие счета ЮЛ
Команда, уже работавшая без
непрерывной доставки, научилась
доставлять изменения в пром не
более чем за 5 дней

35. 2017 год: мы продолжали раскатывать автоматику

36. Увидели, что есть проблемы, которые
автоматика не решает

37. Проблема #1: Нет настоящих совместных
команд
А что есть ?
1) Есть OPS в команде и помогающие ему люди из OPS вне команды,
ведь “все системы связаны между собой”
2) Есть 1 OPS на 4 разных команды “сидит рядом, удобно”
3) Есть “платформенный OPS”

38. Почему плохо без совместных команд ?
Плохо потому что:
1) команда не отвечает за доступность своего решения
2) OPS забивает бэклог команды непонятными дефектами
3) OPS жалуется, что его не понимают, команда реприоритизирует
критичность дефектов выявленные в проме и т.д.
Команда OPS
4) В процессе доставки ценности есть люди несфокусированные
на доставке ценности

39. Проблема #1: Решение
1) Админ полноправный участник команды
2) Шарить админа на несколько команд нельзя
4) Никакой “группы поддержки” вне команды
3) Ответственность за доступность решения у всех участников
команды одинаковая
5) Админ выявил дефект в проме – должен написать на него автотест

40. Проблема #2 Scrum-Waterfall
Команда сидит вместе , но образует маленький waterfall
Команда

41. Почему плохо scrum-waterfall?
Плохо потому что:
1) убивает командную ответственность
2) убивает совместную работу
3) нет фокуса на клиента и рынок
4) команда и Product Owner плохо друг друга понимают

42. Проблема #2: Решение
3 Amigo:
3) Перейти к штучной работе
4) Работать в формате 3 Amigo
1) Функциональное подчинение участников команды PO
2) Единый KPI на всех, нет персональных KPI

43. Ответственность команды: карточка PO
команда оценивается целиком, а не отдельные участники

44. Что изменяется в коммуникации?
3 Amigo Структура обсуждения user story:
Product
Owner
Аналитик
Тестировщик Разработчик
1) как удовлетворить потребность
клиента без доработки
2) разработка решения по живой
спецификации
3) демонстрация и
совершенствование решения
Ориентация на клиента, обсуждение идёт вокруг клиента

45. Живая спецификация = Acceptance Test Driven Dev

46. Как это влияет на автотесты?
Был автотест на Cucumber
Какое отношение к реальной
потребности клиента это имеет?

47. Пишем спецификацию по-человечески
Стал автотест на Cucumber
ется
руко
вод
ител
ь
отде
лен
ия.
@el
sam
orod
ova
@
Дан
о
Руко
вод
ител
ь
отде
лен
ия
захо
дит
на
порт
ал
SFA.
Зате
м
Чер
ез
пои
ск
на
порт
але
нахо
дит
кли
ента
ФЛ.
Это написано на “человеческом языке”, понятно какую потребность
клиента закрывает.
Product Owner и все участники команды работают с одним “живым
документом”

48. Повышается уровень абстракции в описании
Обработчик до Обработчик после
Далее Тестировщик с Разработчиком
договариваются как описывать LoginPage
через PageObject
Увеличивается объём коммуникации разработчик –
тестировщик

49. Проблема #3: архитектурный контроль и
безопасность зависли в техническом бэклоге

50. Проблема#3 решается автоматизацией
pipeline в production 2016:
Автосборка Автодеплой
тест
Автотест Автодеплой
нагрузка
Авто
нагрузка
Автодеплой
пром
pipeline в production 2017:
Автосборка Автодеплой
тест Автотест
Автодеплой
нагрузка
Авто
нагрузка
Автодеплой
пром
Автотест
безопас-ти
Арх-ный
контроль
прототип прототип

51. Прототип архитектурный контроль
{
"description": "Поиск ФИО клиента в стоп-листах",
"realizationName": "WSCustomerTerrorism#Check",
"supplierSystem": “Система 1",
"recipientSystem": “Система 2,
"supplierConnectionType": "ODBC/JDBC",
"recipientConnectionType": "SOAP/HTTP",
"integrationPlatform": "WAS",
"interactionType": "синхронный",
"interactionMode": "Чтение/получение данных",
"isEsbService": false,
"businessData": "Будет определено",
"visionSGSANumber": "12345"
}
Веб-сервис на python-е, который документирует изменения
архитектуры

52. Что ещё?

53. 2017 год: планирование совместных команд

54. Набор devops-практик, которые нам интересны
Chaos Monkey, ChatOps и т.д. – существует много
полезных практик, которые нужно развивать

55. Текущая стратегия развития
Автоматизация Коммуникация Архитектура

56. Вопросы и ответы
api.alfabank.ru
learn.alfabank.ru