Пятого ноября 2021 года, конечно же это была пятница, мы выкатили обновление по нескольким гемам:
минорная версия Ruby on Rails
Ruby Sentry client
http клиенты
Puma
Devise
OmniAuth Ruby client
Mongoid
несколько других гемов по тестам.
Однако, что-то пошло не так. Мы заметили странные ошибки Stripe в Airbrake, затем в нашем аккаунте Stripe мы увидели это:
Здравствуйте, дорогие друзья.
Сегодня хочу поделиться историей из жизни, как было устроено хранилище DWH в Tele2 до внедрения КХД (EDW). А в следующих статьях рассказать, как внедрялись ETL-инструменты, EDW и BI решения в Tele2.
Поступил я в ИТ подразделение Tele2 в 2012 в отдел по системам отчетности. На тот момент в компании уже было создано хранилище DWH, на котором уже крутилось много процессов по предоставлению отчетности и не только.
Немного по поводу технического стека, который там использовался на тот момент. Для хранилища использовалась Оракловая база объемом 60-100 Тб сервер T4-4 c оперативой под 1 Тб. Туда загружались данные из различных источников. Но основными из них были 4 оракловые биллинговые базы, которые были по сути платформой тарификации. И был отдел ЕРЦ (Единый расчетный центр), который занимался поддержкой этих баз и предоставлением сервисов. Разделение этих баз было по макрорегионам. Причина: слишком большие объемы. Т.е если абонент звонит, скажем, из Московской сим-карты то и расчет стоимости звонка производится в соответствующем биллинге.
Авиакомпания продает билеты через сеть собственных и независимых агентов и партнеров, сотрудничает со всеми участниками рынка: агенты, тревел-порталы, туристические операторы. Клиентами являются как индивидуальные путешественники, так и корпоративные клиенты. Для стимулирования продаж у авиакомпании есть несколько систем вознаграждений и программ лояльности для агентов и клиентов. Появлялись они в разное время, инициированы разными департаментами авиакомпании и учет по каждой программе ведется независимый.
Как следствие, получить сводную картину по затратам и эффективности всех систем лояльности было довольно проблематично, т.к. это делалось в ручном режиме.
Введение же единых метрик и правил учета позволило не только этот процесс автоматизировать и получить аналитику в режиме реального времени, но и планировать развитие отдельных инструментов лояльности с учетом эффективности системы в целом.
Мы разработали конструктор условий вознаграждений, по сути биллинговую систему, которая позволяет сконфигурировать любое условие для каждой из программ и просчитать общую экономику систем лояльности на основе архивных данных о продажах (или оказанных услугах) за прошлые периоды.
Читать полностью »
