Билинг интернета что такое
Биллинг простыми словами
Биллинговая система. Что это?
Расчетные операции
В биллинговую систему заводится информация, на основании которой за определенный период обслуживания (как правило, расчетный период составляет один календарный месяц) оператор связи выставляет счет абоненту за потребление услуг связи. Что это за информация? Тарифы, стоимость минуты звонка в зависимости от направления (междугородняя и международная связь), стоимость интернет-трафика, стоимость подключенных ТВ-каналов и так далее. Кроме того, биллинг должен учитывать индивидуальные и общие скидки, акции, временное приостановление услуг по желанию абонента, налоговые начисления, дополнительные начисления и многое другое, что определяет для своего бизнеса оператор связи. Помимо этой информации, в биллинг поступают первичные тарификационные данные – информация обо всех звонках, совершаемых абонентами этого оператора связи и об объеме интернет-трафика. На основании всех этих данных биллинговая система рассчитывает стоимость своих услуг за расчетный период для каждого клиента и выставляет платежные документы.
Информационное обслуживание
Биллинговая система должна иметь удобный интерфейс для заведения и мониторинга всей необходимой информации: тарифы и тарифные планы, пакеты, опции, скидки, стоимость звонков в зависимости от направления и т.д.; уметь составлять отчеты; иметь возможность взаимодействовать с абонентами – рассылать документы, управлять событиями уведомления абонентами и многое другое.
Финансовое обслуживание
Автоматизированная система расчетов должна не только уметь корректно выставлять счета абонентам, но и обрабатывать поступившие платежи, разносить их по выставленным счетам, управлять дебиторской задолженностью абонентов, при необходимости взаимодействовать с бухгалтерскими программами.
В биллинговую систему заводится информация, на основании которой за определенный период обслуживания (как правило, расчетный период составляет один календарный месяц) оператор связи выставляет счет абоненту за потребление услуг связи. Что это за информация? Тарифы, стоимость минуты звонка в зависимости от направления (междугородняя и международная связь), стоимость интернет-трафика, стоимость подключенных ТВ-каналов и так далее. Кроме того, биллинг должен учитывать индивидуальные и общие скидки, акции, временное приостановление услуг по желанию абонента, налоговые начисления, дополнительные начисления и многое другое, что определяет для своего бизнеса оператор связи. Помимо этой информации, в биллинг поступают первичные тарификационные данные – информация обо всех звонках, совершаемых абонентами этого оператора связи и об объеме интернет-трафика. На основании всех этих данных биллинговая система рассчитывает стоимость своих услуг за расчетный период для каждого клиента и выставляет платежные документы.
Биллинговая система должна иметь удобный интерфейс для заведения и мониторинга всей необходимой информации: тарифы и тарифные планы, пакеты, опции, скидки, стоимость звонков в зависимости от направления и т.д.; уметь составлять отчеты; иметь возможность взаимодействовать с абонентами – рассылать документы, управлять событиями уведомления абонентами и многое другое.
Автоматизированная система расчетов должна не только уметь корректно выставлять счета абонентам, но и обрабатывать поступившие платежи, разносить их по выставленным счетам, управлять дебиторской задолженностью абонентов, при необходимости взаимодействовать с бухгалтерскими программами.
Это основные функции, которые должна уметь выполнять автоматизированная система расчетов.
Однако сейчас появляется все больше операторов связи, которые хотят обеспечить своим сотрудникам удобную работу с биллингом, взаимодействие разных отделов через единую систему, прозрачные расчеты с другими операторами связи, а своим абонентам не только качественную связь, но и дополнительные услуги, удобный личный кабинет, доступные варианты оплаты, индивидуальный подход и легкую коммуникацию с операторами.
Все эти требования, а также многие другие пожелания, легко обеспечиваются автоматизированной системой расчетов (АСР) Platex® — универсальной масштабируемой системой высшего функционального уровня. Она обеспечивает единое управление всеми бизнес-процессами между абонентами и операторами, независимо от типа услуг, технологии их предоставления, схемы тарификации, методов оплаты. Линейка продуктов, разработанная нашей компанией, дает возможность приобрести биллинговую систему и расширить ее функциональность, в случае необходимости, дополнительными модулями АСР Platex®. Кроме того, многофункциональная система комплексной автоматизации бизнес-процессов оператора связи, построенная на основе ядра программных продуктов линейки Platex®, позволит решить задачи, выходящие за рамки функциональности обычных биллинговых систем.
АСР Platex® совместима с продуктами компании «1С», интегрируется с различными платежными системами, соответствует всем требованиям государственных регулирующих органов, сертифицирована для применения в сетях электросвязи емкостью до 2,5 млн. абонентов.
Развитие биллинговых систем в телекоммуникациях
Биллинговые системы (от англ. bill — счет) обеспечивают расчет абонентской платы и выставление счетов по каждому абоненту, хранят полную информацию о тарифах и истории действий абонентов, помогают вести взаиморасчеты с другими поставщиками услуг.
Первая биллинговая система появилась 1868 г. и предназначалась для взаиморасчетов между операторами телеграфной связи. Тогда же начала набирать популярность система отложенного платежа или платежа по счету за фактически использованные товары и услуги, когда клиентам отправлялись счета с подробным описанием расчетов. Современные биллинговые системы для рынка телекоммуникаций начали появляться в 90-х годах XX века.
Первым оператором, у которого была установлена биллинговая система разработки Bercut, стал ОАО «Связьинформ», оказывавший услуги связи в Челябинской области. Система IN@Voice отвечала за прием платежей, выставление счетов, тарификацию голосовых вызовов, SMS и интернет-трафика.
С 2000 по 2002 гг. IN@Voice пополнил ИТ-ландшафт еще двух операторов связи: «СтавТелеСот» и «Мобиком-Кавказ». «СтавТелеСот» (сейчас принадлежит ПАО «ВымпелКом») охватывал 61% всей абонентской базы Ставропольского края. ЗАО «Мобиком-Кавказ», 100% дочернее предприятие ОАО «МегаФон», предоставлял услуги в Северо-Кавказском укрупненном регионе.
Биллинг решал несколько ключевых задач:
непрерывный учет затрат на предоставленные услуги связи;
Уже тогда биллинговая система Bercut позволяла не только выставлять счета за услуги связи, но тарифицировать трафик в режиме реального времени. Конечно, по сравнению с сегодняшним днем, функциональность была элементарной: биллинг мог принять платеж, отменить его и выставить счет абоненту.
Что же изменилось за эти годы в устройстве биллинговых систем и как это повлияло на мобильных операторов и абонентов?
Смена парадигмы продаж, когда в центре внимания оказались предпочтения клиентов, стала стимулом для создания новых ИТ-решений. Их целью стали получение и анализ данных о конечных потребителях и разработка продуктов, ориентированных на их потребности. Пожелания самого мобильного оператора отошли на второй план.
Первоначально все поставщики связи использовали офлайн-тарификацию, при которой сетевые устройства и биллинг обменивались специальными CDR-файлами. Списание денежных средств со счета абонента производилось по факту оказания услуг. Со временем абоненты становились более требовательными. Они хотели видеть, сколько средств у них на счете здесь и сейчас, так что системам пришлось учиться тарифицировать сессии в режиме реального времени.
С повышением доступности интернета возросло и количество типов трафика. Потребовалось адаптировать биллинг так, чтобы он мог тарифицировать отдельно, например, YouTube и WhatsApp или же наоборот — не тарифицировать их. Это позволило сделать пакеты услуг более удобными для абонентов, и пользователи мобильного интернета перестали переплачивать за трафик. В частности, появились такие продукты, как безлимитные мессенджеры.
Подход к списанию абонентской платы со временем тоже становился более гибким. Прежде биллинговая система списывала денежные средства со счета абонента раз в месяц, теперь частоту и периодичность списания можно было настраивать. Благодаря этому мобильные операторы смогли предложить абонентам удобные схемы оплаты, а абоненты перестали переплачивать за периоды, в которых они не пользовались услугами.
К примеру, если абонент подключает услугу 15 числа, плата за нее будет списана именно 15 числа следующего месяца. Ранее расчет абонентской платы производился с первого числа календарного месяца независимо от даты подключения услуги.
В разное время использовались различные методы списания абонентской платы. Они зависели от модели потребления услуг и целей мобильного оператора в тот или иной момент времени. Например, при кредитной схеме абонент вносил платеж по факту оказания определенного объема услуг. На смену этому некогда популярному методу пришел авансовый, при котором плата списывается в начале периода.
Когда-то биллинговая система рассчитывала и взимала плату только за фактические дни использования услуги. Потом абоненты стали платить ежемесячно, не задумываясь о том, пользуются они услугой или нет, появилась возможность масштабировать сумму абонентской платы в зависимости от длительности использования услуги.
К примеру, оператор предлагает подключить услугу, списание средств по которой производится первого числа за весь период (календарный месяц), но абонент подключает ее за неделю до окончания предыдущего месяца. В соответствии с настройками оператора, биллинговая система может принять решение масштабировать абонентскую плату, т.е. списать сумму только за 7 дней использования и таким образом сэкономить средства абонента.
Вся информация, которая требуется для корректного списания средств со счета абонента (тариф, период использования и пр.), хранится в биллинговой системе. IN@Voice анализирует данные и принимает решение о сроках и суммах списания.
Постепенно фокус внимания операторов связи сместился на клиентский опыт: в обиход вошли понятия Customer Experience и User Experience.
Customer Experience ― совокупность впечатлений клиента при взаимодействии с компанией, которая оказывает услугу или поставляет товар.
За совершение определенных действий или подключение конкретных услуг операторы стали предлагать абонентам дополнительные бонусы и скидки (т.н. «пряники»). Впервые начали появляться пакеты услуг (bundle).
Пятнадцать лет назад все находились на тарификации pay-as-you-go (PAYG), когда оплата производилась исходя из фактического потребления минут за определенный период. Например, в голосовой связи бесплатными сначала были 10 секунд разговора в минуте, затем 5 секунд, и многие абоненты для экономии средств старались уложиться в эти отрезки.
С появлением пакетных тарифных планов абоненты получали в рамках тарифного периода определенный объем трафика за фиксированную стоимость. Это избавило их от необходимости проверять баланс после каждого звонка; главным стало количество оставшихся ресурсов в пакете. Тарификация PAYG сменилась на bundle.
Активное развитие OTT-сервисов (англ. Over The Top — предоставление видеоуслуг через интернет) привело к тому, что операторы связи стали восприниматься исключительно как канал для передачи интернет-трафика. При этом борьба за абонентскую базу продолжалась, и требовались все более привлекательные решения для абонентов. Именно тогда впервые возникла идея переноса остатков с одного тарифного периода на другой. Чтобы предоставить абонентам такую возможность, необходимо было реализовать в IN@Voice определенные настройки. Именно развитие этой функциональности в дальнейшем позволило запустить уникальный для России продукт ― «Маркет Tele2», онлайн-площадку для продажи минут и гигабайтов из пакета услуг абонента.
Когда проникновение мобильной связи превысило 100% (к слову, в России оно сейчас составляет более 170%, т.е. едва ли не у каждого абонента есть две SIM-карты), пришло осознание, что емкость рынка заполнена и дальнейший рост совершается в профицит. В этой ситуации разумнее было направить силы на удержание существующих абонентов, нежели на привлечение новых. Тем более что причины, по которым абоненты могли желать сменить оператора, были. Одна из них — нередкие случаи ошибочного списания средств. Однако, ради сохранения привычного номера телефона, абоненты чаще всего были вынуждены смириться с неудобствами. 2013 год оказался революционным для российского телекома. Абоненты получили законодательное право сохранять свой номер телефона при смене оператора. Новая услуга получила название Mobile Number Portability (MNP).
Поставщикам мобильной связи, включая Tele2, пришлось искать технологическое решение, которое поддержало бы реализацию MNP. Bercut за рекордно короткие три месяца справился с задачей с помощью BSS-платформы IN@Voice. По данным Центрального НИИ связи, в январе-ноябре 2013 года 4 млн россиян сменили операторов с сохранением номера. Больше всего номеров (27%, т.е. более 1 млн) было перенесено на сети «Т2 РТК холдинга» (Tele2).
С отменой «мобильного рабства» стало ясно, что насыщение абонентской базы не является препятствием для ее роста: благодаря MNP абоненты получили возможность с легкостью переходить от одного оператора к другому. У операторов же появился дополнительный стимул для борьбы с оттоком. Дело в том, что, по законодательству, за каждым оператором закрепляется свой диапазон абонентских номеров. При переходе абонента к другому поставщику связи хост-оператор теряет номер и его номерная емкость уменьшается, что сказывается на доходах.
Потеря номерной емкости, высокая стоимость привлечения нового абонента ― причины, по которым поставщикам связи приходится бороться за своих клиентов. При этом стоимость удержания абонента значительно ниже стоимости привлечения нового, даже с учетом скидок. Понимание этого привело к тому, что операторы начали персонализировать свои продукты. Так появились новые сервисы:
тарифные планы-конструкторы, когда абонент может сам настроить необходимое количество трафика;
Подобные сервисы разрабатываются на биллинговой системе в связке с тарификационной платформой. Подход, при котором скидки, хранящиеся в IN@Voice, применяются единовременно ко всей абонентской базе, перестает быть востребованным, и функциональность биллинга развивается в сторону персонализированных предложений. При этом важно сохранить удобство администрирования, не утяжеляя объемы хранимой информации и не усложняя структуру системы. Ведь для того, чтобы в три клика создать одну услугу для одного абонента, крупному оператору, чья абонентская база достигает 80 млн абонентов, необходимо совершить 240 млн кликов.
Вместе с персональными скидками развивались и роуминговые предложения. Прежде нередко случалось так, что средства за пребывание в роуминге продолжали списываться на протяжении нескольких месяцев после возвращения абонента в домашнюю сеть. Это было связано с отсутствием онлайн-роуминга. Операции, произведенные пользователем в гостевой сети, записывались в TAP-файл (Transferred Account Procedure) и передавались в домашнюю сеть. Операторы связи обменивались TAP-файлами, взимали на их основании абонентскую плату, при этом каждый месяц вели взаиморасчеты между собой.
Со временем начал развиваться онлайн-роуминг по протоколу CAMEL. Это существенно упростило взаиморасчеты с абонентом и между поставщиками связи. Услуги перестали тарифицироваться по postpaid-методу: запрос на сервис стал приходить домашнему оператору непосредственно в тот момент, когда абонент совершал действие.
Казалось бы, еще совсем недавно абоненты получали картинки через SMS. Доставка такого контента осуществлялась с помощью CPА (Content Provider Access Platform) решений, которые обязательно интегрировались с биллингом. В Bercut для этого использовалась платформа организации доступа к партнерскому контенту — SPACE. SPACE решал задачу правильного доступа партнеров к биллингу и контролировал фрод.
За пару десятилетий партнерский контент сильно изменился. С появлением смартфонов и прямого доступа в интернет любой абонент может легко найти и скачать то, что ему интересно. Спрос сегодня определяют более комплексные предложения: подписки, услуги по проверке автоштрафов, ставки на спорт и другие сервисы.
В 2007 году появился iPhone. Apple стала первой компанией, которая исключила мобильного оператора из экосистемы общения
Когда-то совершить звонок без SIM-карты было невозможно, т.к. соединение шло через сеть GSM. Появление смартфона с учетной записью Apple ID, которая позволяла звонить через FaceTime или iMessage, оставило мобильных операторов в стороне. Стремительное развитие мессенджеров повлекло за собой удешевление интернет-трафика, а это в свою очередь привело к увеличению его потребления. Люди перешли на общение в мессенджерах через Wi-Fi.
В поисках дополнительных источников дохода поставщики связи обратились к партнерствам. Чтобы придать своим услугам дополнительную ценность, операторы стали внедрять в тарифные планы т.н. бенефиты: чашки кофе на фудкортах, книги в электронных библиотеках, подписки на онлайн-кинотеатры и платное видео. Это поставило перед IN@Voice новую задачу — вести учет и тарификацию партнерского контента и сервисов. Система должна была научится сообщать партнеру о том, что абонент подключил услугу, что с него списаны денежные средства или что он по какой-то причине заблокирован.
С развитием партнерских программ IN@Voice потребовался мощный API (Application Programming Interface), чтобы обеспечить удобство управления, регламентировать уровни доступа к биллингу и сохранить безопасность информации об абонентах. Развитие экосистем задействует множество продуктов в ИТ-ландшафте оператора (campaign management, личные кабинеты, m2m-платформы), которым требуется информация из биллинга. Поэтому API развивается и совершенствуется по сей день.
К биллинговой системе предъявляются серьезные требования по безопасности и хранению персональных данных об абонентах. Сохранность информации во многом контролируют мобильные операторы. Биллинговая система устанавливается на сервер в локальной сети оператора, что фактически исключает к ней доступ извне. Дополнительный уровень защиты обеспечивается установкой файрволов и строгим контролем доступа на основе ролевой модели, реализованной в Bercut IN@Voice. Она регламентирует набор полномочий, который необходим пользователю или группе пользователей для выполнения определенных рабочих задач. Оператор может настраивать права и роли в соответствии со своей политикой предоставления доступа. При этом все действия пользователей логируются, и служба безопасности оператора всегда может произвести полную проверку.
По-настоящему прорывным моментом для Bercut IN@Voice стало вынесение из архитектуры биллинга TAR@SCP — тарификационной платформы, которая отвечает за тарификацию всех сервисов оператора. Это позволило существенно упростить архитектуру IN@Voice, оптимально распределить процессы с точки зрения функциональности, ускорить разработку продуктов.
Bercut провел масштабирование IN@Voice и увеличил производительность системы. В рамках проекта были расширены возможности работы с подсистемами отчетности, в портфеле продуктов Bercut появилcя набор инструментов Business Intelligence & Analytics Suite ― для хранения, построения, оценки аналитических моделей и принятия эффективных управленческих решений. В 2014-2015 гг. Bercut произвел масштабную миграцию 13 млн абонентов с 20 сайтов «Ростелекома» в базу Tele2.
Пока альтернатив биллинговой системе не существует. Так или иначе любые продукты создаются мобильным оператором с использованием биллинга, а сеть только обеспечивает доступ абонентов. Так что, если оператору требуется вести учет абонентов, количества услуг, различных видов трафика или выставлять счета, стоит задуматься о приобретении IN@Voice. Для классического оператора биллинг ― неотъемлемая часть, которая отвечает за обеспечение ключевых бизнес-процессов.
Биллинг в большом проекте
Существуют разные способы «монетизировать» проект. Но у них есть одна общая составляющая ― то, как деньги переходят из кошелька пользователя на счет организации. Сегодня мы расскажем о том, как организован прием платежей в Badoo и что можно встретить на рынке платежных шлюзов. Сразу предупреждаем, что в статье вы не найдете конкретных цифр по обороту средств компании, но все остальное будет не менее интересно.
Что такое «биллинг»
Для нас биллинг ― это всё, что связано с получением денег от пользователей: конфигурация цен, страница приема платежей, непосредственно прием и обработка платежей, оказание оплаченных услуг, различные промоакции и, конечно же, мониторинг всего вышеописанного.
Изначально, как и во всех стартапах, у нас не было платных услуг. Первые серьезные шаги в сторону монетизации начались в далеком 2008 году, при том что официально сайт был запущен в 2006-м. Для экспериментов была выбрана Франция, а оплата принималась только через SMS. Сам прием платежей был организован на файлах. Каждый запрос записывался в отдельный файл, который затем перекладывался bash-скриптами из одной папки в другую, что означало смену статусов обработки. База данных использовалась только для учета успешно обработанных транзакций. Такая схема успешно проработала чуть больше года, после чего ее стало сложно поддерживать, и мы решили отказаться от файлов и переписать всё с использованием БД.
Разработка новой версии прошла достаточно быстро, так как стран, где были доступны платные услуги, было не много. Но она была рассчитана только на прием платежей через SMS, из-за этого у нас даже до сих пор сохранилось несколько забавных артефактов, например, поля MSISDN (номер телефона) и short code (короткий номер, на который отсылают платную SMS) в таблице обработанных платежей.
Сейчас мы принимаем платежи почти во всём мире. Каждую секунду пользователи пытаются что-то оплатить на сайте или в приложениях для всех популярных мобильных платформ. А если наложить это на карту, то получится картина «Вид на Землю из космоса ночью»:
У нас доступно около 50-ти способов оплаты, предоставляемых разными партнерами. Самые популярные ― это банковские карты, SMS & Direct billing и покупки в мобильных приложениях.
Среди них есть и экзотические, например, прямое списание со счета интернет-провайдера или оплата через городской телефон. А однажды нам поступил платеж через обычную почту!
Банковские платежи
Все платежные системы позволяют принимать платежи от своих пользователей. Такие прямые интеграции удобно делать, пока их не очень много и вы подключаете известные системы с отлаженными процессами. Но когда нужно выйти на локальные рынки, то начинают появляться проблемы. Поддерживать «зоопарк» разных API становится всё сложнее, отличаются требования регуляторов, популярная локальная платежная система может вообще отказаться работать с иностранными клиентами при низких оборотах, или подписание контракта и улаживание юридических проблем может затянуться на долгое время. Несмотря на такие сложности, локальные платежные системы могут вас приятно удивить своей конверсией. Например, Голландия, которую мы считали не очень перспективной, после подключения популярного в этой стране способа оплаты iDeal стала приносить на 30-40% больше денег.
Если есть спрос, будет и предложение. На рынке много компаний-агрегаторов, или, по-другому, платежных шлюзов (англ. payment gateway), целью которых является объединение всех популярных платежных систем, в том числе локальных, под единым API. Сделав одну такую интеграцию, мы получаем возможность принимать платежи через десятки платежных систем по всему миру. Можно даже не делать страницу оплаты на своем сайте, а воспользоваться уже готовой, предоставленной агрегатором, и подогнать под себя только дизайн. Особо продвинутые компании дают возможность загружать свои CSS- и JS-файлы, менять картинки, тексты переводов и даже зарегистрировать получившуюся страницу на вашем поддомене, например, payments.example.com. Это дает очень богатые возможности по «кастомизации», и у пользователя складывается ощущение, что он не покидает ваш сайт. У себя мы этой возможностью не пользуемся, так как одновременно работаем с несколькими агрегаторами, но для кого-то это может быть очень удобным решением.
Какой способ использовать ― прямую интеграцию или через агрегатора ― зависит в первую очередь от размера комиссии. Чем больше ваших клиентов пользуется платежной системой, тем выгоднее может оказаться сэкономить на комиссии и подключиться к ней напрямую. Второй важный фактор ― это качество API, удобство работы и стабильность. Здесь агрегаторы позволяют сгладить шероховатости, а иногда и предоставить более стабильный сервис, чем прямое подключение.
SMS-платежи
Особняком стоят платежи через SMS и прямые списания с баланса мобильного телефона. Они находятся под очень жестким контролем во многих странах, особенно в Европе. Локальные регуляторы или само государство могут предъявлять особые требования к тому, как должна выглядеть страница оплаты или каким должен быть текст отсылаемых SMS-сообщений. За изменениями подобных требований нужно следить и вовремя вносить изменения у себя на сайте. Так, например, в Бельгии есть правило, что короткий номер должен быть написан белым шрифтом на черном фоне, а рядом с ним должна быть указана его стоимость.
Технические детали
Badoo работает на связке PHP + MySQL, поэтому для обработки платежей мы используем те же технологии. Код выполняется на отдельной группе серверов, выделенной из общего пула. Внутри мы ее разделили еще на несколько логических подгрупп: cерверы для обработки входящих запросов, серверы для фоновых операций и сбора статистики, серверы баз данных, серверы для обработки платежей по банковским картам. Последние выделены в отдельную группу, потому что они должны соответствовать стандарту безопасности PCI DSS, разработанному при участии Visa, MasterCard, American Express, JCB и Discover для организаций, работающих или хранящих данные держателей банковских карт.
Для обработки платежей мы используем два сервера базы данных с MySQL от Percona, работающих в master-master репликации. Основная нагрузка идет только на один из них, второй используется для «горячей» замены в случае аварии или для подмены основного (на время его обслуживания, для запросов от системы мониторинга или сбора статистики).
После реализации API наступает этап тестирования. На Хабре уже были статьи о том, как выглядит наш процесс разработки и автоматизации. Но для биллинга есть некоторые особенности, связанные в основном с тем, что приходится тестировать не просто наш код, но и взаимодействие с агрегаторами. Очень удобно, если у них есть для этого тестовое окружение, которое полностью эмулирует реальный прием платежей. Если же его нет, мы делаем «заглушки», эмулирующие поведение агрегатора. Это упрощает нам ручное тестирование и позволяет писать автотесты, проверяющие весь процесс оплаты. Вот пример того, как выглядит одна из заглушек.
После тестового окружения нужно проверить, как всё будет работать в жизни, провести реальную оплату. Но для SMS-платежей часто приходится получать одобрение от регуляторов или операторов, а это может длиться несколько месяцев. Чтобы не выкладывать полуготовый код на продакшн-серверы, мы придумали такую вещь, как External Shot. Это наш обычный Shot, который представляет из себя директорию с веткой задачи и предназначен для ее тестирования на продакшн-серверах, но кроме локального домена он имеет дополнительный внешний адрес, по которому любой желающий может зайти и посмотреть сделанные изменения. Для безопасности такие «шоты» создаются не для каждой задачи, а только в тех случаях, когда действительно необходимо. Ссылки на них мы даем нашим партнерам, и они в любое время дня и ночи могут проверить сделанные изменения. Особенно это актуально для стран, расположенных в другом полушарии, с которым разница во времени может достигать 12 часов.
Поддержка и эксплуатация
После того как новая интеграция выкладывается на продакшн-серверы, наступает этап ее эксплуатации и поддержки. Техническая поддержка занимает примерно 60-70% нашего времени.
Сюда входит, во-первых, разбор жалоб от пользователей. Все простые ситуации решаются командой первой линии поддержки, она же переводит для нас жалобы с разных языков на английский. Поэтому к нам попадают только самые сложные случаи, действительно требующие внимания разработчиков.
Вторая составляющая технической поддержки ― это исправление ошибок или внесение изменений в существующие интеграции. Ошибки возникают по разным причинам. Например, из-за невнимательного чтения документации или пробелов в ней. Однажды вместо нее нам даже пришлось использовать логи чата с разработчиком агрегатора, потому что документация для их новой системы была еще не готова. Были случаи, когда агрегатор без уведомления менял протокол взаимодействия или его параметры. В другой раз банк-эквайер отключил наш шлюз, и пришлось в срочном порядке перенаправлять трафик в другое место. Как потом выяснилось, это был древний сервер из 80-х, который, по данным банка, вообще ничего не должен был обрабатывать. В общем, скучать не приходится, особенно если учитывать, что каждая минута простоя ― это недополученная прибыль.
Для решения подобных проблем мы пишем подробные логи работы приложения. Туда попадают не только ошибки, но и всё взаимодействие с системами агрегаторов или просто важные события, происходящие во время выполнения запросов. Каждый запрос имеет свой уникальный идентификатор, по которому можно найти все связанные с ним записи и восстановить ход его обработки. Это бывает особенно полезно, когда приходится разбираться с ошибками, с момента которых уже прошло несколько недель или месяцев.
Вот так организован биллинг в Badoo. Конечно, осталось еще много интересных тем, о которых мы планируем рассказать будущем, например мониторинг, сертификация PCI DSS и обработка платежей по банковским картам. Если есть вопросы или какие-то пожелания по теме будущих статей, добро пожаловать в комментарии.