Как Mail.Ru и AT Consulting перевели профили абонентов Beeline на Tarantool / А.Дроздов, Ю.Гейниш
1 like810 views
Документ описывает совместный проект mail.ru и at consulting по миграции профилей абонентов beeline на платформу tarantool, который ориентирован на высокую производительность и нагрузку. В процессе работы были выявлены проблемы с интеграцией данных, необходимостью адаптации архитектуры системы и доработкой сервисов, что повлияло на сроки и качество исполнения. Опыт, полученный в результате данного проекта, позволяет участникам улучшить поддержку и внедрение решений в сфере enterprise.
Как Mail.Ru и AT Consulting перевели профили абонентов Beeline на Tarantool / А.Дроздов, Ю.Гейниш
- 1. Как Mail.Ru и AT Consulting перевели профили абонентов Beeline на Tarantool Андрей Дроздов, Mail.Ru Group Юлия Гейниш, AT Consulting
- 2. Наш клиент миллионов активных абонентов 58+ 270+ тысяч корпоративных клиентов 300+ информационных систем и приложений 500+ различных продуктов и услуг 1000+ новых проектов в год
- 3. Цель клиента •Unified customer profile •Общий API для всех систем •Контроль нагрузок на источники •Версионирование данных •Входящая нагрузка 300000 TPS
- 4. Боль клиента
- 5. Решение
- 6. Зачем мы объединились? •Существующие решения не имели требуемого функционала или не обеспечивали нагрузку •Опыт создания highload систем •Опыт внедрения решений в Enterprise •Разделение рисков и работ
- 7. Как поделили задачи? • Сбор бизнес-требований • Совместное ТЗ и архитектура • Разработка data-ландшафта • Разработка discovery service • Тестирование бизнес логики • Запуск системы в production • Сбор технических требований • Совместное ТЗ и архитектура • Разработка платформы • Кастомизация open source решения • QA и решение технических проблем • Запуск системы в production
- 8. Влияние на результат • При запуске потребовались доработки discovery service и сервиса авторизации • Вывод: ключевую инфраструктуру нужно разрабатывать совместно
- 9. Архитектура системы IVR/SMS/USSD Social Nets WidgetsDesktops / WEBs Mobile Devices In-door digital Partners DIGITAL CHANNELS Step 1Step 2
- 10. Источники данных • Биллинг: абонентские данные • Препейд биллинг: абонентские данные • Регионы: принадлежность номера к региону • Продуктовый каталог: информация о продуктах • Личный кабинет: доступные услуги и тарифные планы • Платформа RBT: задолженность по услуге RBT • Возможно подключение новых источников
- 11. Все пошло не так • Для преобразования, «на лету», native данных в SID реализован особый коннектор, при этом клиентский интерфейс остался единым
- 12. Синхронизаторы • Слишком медленные источники данных оповещают об изменениях через синхронизатор
- 13. Инфраструктура • Для поддержания справочника в актуальном состоянии организована интеграция с системой мониторинга, для постоянного контроля доступности сервисов.
- 14. Ядро платформы
- 16. Лента сообщений
- 18. Пример задачи • «Добрый день, коллеги. Уже несколько часов наблюдаем медленные ответы клиентам от платформы, приоритет КРИТИЧЕСКИЙ» • Начали искать проблему в коде платформы, нужно было диагностировать все решение
- 19. Пример задачи •«Добрый день, коллеги. Просьба прислать ваши тест кейсы для анализа и передачи клиенту» •Ожидали документы, получили код
- 20. Почему так? • В интернет-компаниях другая модель управления рисками • В Enterprise компаниях начинают копать проблему со всех сторон и иногда описывают проблему без полной диагностики • Интегратор работает с множеством продуктов и времени проводить диагностику во всех продуктах сразу может не быть (SLA) • Вендор мыслит в терминах продукта • Интегратор мыслит в терминах решения
- 21. Правильный пример •«В решении наблюдаются проблемы c производительностью, нужно подтвердить, что компоненты платформы не являются источником. Просим подключить ваших экспертов к диагностике решения»
- 22. Разница в мышлении • Делаем решение, а не продукт • Минимизируем доработки смежных систем • Приоритет: time to market • Меньше дефектов - лучше • Делаем продукт, а не решение • Изменяем смежные системы • Приоритет: качество и производительность • Больше найденных дефектов – лучше
- 23. Хотелки • Клиент: • Больше функциональности в том же контракте • Интегратор: • Поддержка решения и управляемость • Вендор: • Качество и возможность создания универсальных компонент
- 24. Доработка ключевого компонента •За месяц до запуска заказчик попросил изменить логику работы с правами, что повлекло доработку сервиса авторизации и платформы
- 25. Влияние на результат •Изменения могли существенно повлиять на сроки проекта •Обе команды должны были доработать свои компоненты •В тестово-промышленную эксплуатацию выходили с заглушкой
- 26. Доработка платформы • Для корректной работы с сервисами биллинга нужно было добавить возможность обогащения данными из других источников
- 27. Влияние на результат • Влияние такой доработки на производительность и общее поведение системы не было проработано и протестировано в полном объеме • После запуска в продакшн пришлось столкнуться с рядом проблем
- 28. Чеклист вендора • Скорость реакции/решения вопросов проблем 2 и 3 уровня поддержки • Доступность и активность в консультациях по развитию • Готовность делиться экспертизой • Возможность кастомизации продукта • Готовность к постоянной коммуникации со всеми участниками процесса
- 29. Чеклист интегратора • Умение переводить с языка клиента на язык вендора • Готовность к решению спорных и конфликтных ситуаций • Опыт координации рабочего процесса команд • Готовность дать вендору возможность сконцентрироваться на технологиях • Готовность перенимать новые знания и менять подходы к разработке
- 30. Передача знаний • Опыт внедрения решений виртуализации данных и Tarantool • Lua • Avro schema • Эксплуатация Tarantool • IT процессы в телекомах • Подходы к работе в Enterprise • Подход к эксплуатации решений в Enterprise • Умение внедряться в бизнес- процессы других компаний
- 31. Влияние на результат • Поддержка 2 уровня выполняется командой AT Consulting. Команда DevOps в AT Consulting автоматизировала процесс эксплуатации решения • Настройки платформы, добавление новых источников и новых версий схем данных выполняются без привлечения вендора. • Mail.Ru получила огромный опыт работы в Enterprise и возможности для привлечения новых клиентов • В команде Tarantool сформировался отдел Solution Engineering для кастомизации Open Sourсe продукта под Enterprise заказчиков
- 32. Почему важен прототип? • Возможность пробовать любые идеи и проверять их за несколько минут • Большая часть автоматизации от прототипа пошла в боевую версию без изменений • MVP лучше прототипа «на выброс» • Вся разработка строилась итерациями от прототипа
- 33. Как было устроено тестирование?
- 34. Как было устроено тестирование?
- 35. Как было устроено тестирование?
- 36. Как было устроено тестирование?
- 37. С чем столкнулись после запуска? •Чем раньше был предложен и продуман тот или иной функционал, тем меньше проблем возникает после запуска •И наоборот…
- 38. Источники данных • Проблема: • Из-за возможности выполнять запросы во внешние источники, проявлялись проблемы с пиковой производительностью • Решение: • Мониторинг всех компонент системы, анализ и выявление узких мест • Мораль: • Без хорошего мониторинга мы бы не решили проблему • Как можно раньше нужно делать feature freeze
- 39. Крэши отдельных узлов кластера •Проблема: •Более свежая версия tarantool могла в редких случаях приводить к падению узла •Решение: •Отказоустойчивость внутри ЦОД •Реакция команды эксплуатации AT Consulting •Предоставление максимально подробного описания проблемы •Мораль: •Enterprise не должен отказываться от более современных и выгодных бизнесу решений, но это требует детальной проработки архитектуры
- 40. Итоги ✓В production с ноября 2016 года ✓Загружено ~100 млн абонентов ✓Подключено 6 источников ✓Производительность платформы: 300000 tps