At The Beginning…

В начале 2000-х на рынок автоматизации телеком-компаний в России зашли иностранные игроки. Системы западных вендоров были очень дорогими и недоступными не только среднему рынку, но и большинству крупных компаний. Отечественные решения на тот момент были менее продвинутыми, но это было время, когда нужно было перенимать опыт и создавать системы, не уступающие западным аналогам.

Мы хотели быть такими же крутыми и технологичными, как западные вендоры, но более универсальными и доступными по цене среднему бизнесу, так появилась идея создания новой компании, способной справиться с этой задачей. Зарегистрировали её в декабре 2005. Костяк команды сложился из выходцев из компаний-вендоров биллингов и ведущих интеграторов того периода.

В первой команде было всего 6 человек. Жесткой специализации не было, все занимались смежными задачами. Растили команду внедрения, выполняли не более 1-2 проектов одновременно. Один проект на тот момент мог длиться год, приходилось дописывать много функционала.

Мы разработали ядро BSS системы, стали заключать договора с клиентами и расширять функционал. Начала расти наша линейка продуктов. Потом стали заниматься компонентами OSS для взаимодействия с сетевым оборудованием и внешними системами.

Клиент-серверная архитектура и веб-интерфейс

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

Нагрузка на биллинг у клиентов росла. Мы были на рынке уже несколько лет и доверие наших потенциальных клиентов приводило нам все более крупные сети. Приходил клиент с миллионом абонентов и нам казалось, что медленно мы работаем, надо быстрее. Занимались оптимизацией. Приходили клиенты с 5 миллионами абонентов – ситуация повторялась, снова садились за оптимизацию. Развитие было непрерывным.

У нас есть статья про юзабилити интерфейсов — «Интерфейс для облачных сервисов в сегменте B2B: между красотой и утилитарностью» – почитайте, если интересна эта тема.

Собственный ЦОД

Железо для разработки изначально стояло в офисе компании, без специально выделенного помещения. 5-7 серверов на начальном этапе – обычные системные блоки.

Через год после начала работы мы начали наводить порядок. Перенесли системники в отдельное помещение, начали обустраивать его. Получилась маленькая офисная серверная.

Компания росла, с ней росла и серверная. Появилось нормальное серверное оборудование. Мы меняли офисы и серверная переезжала вместе с нами. Каждый раз в новом офисе выделяли помещение, оборудовали его, подводили питание, вентиляцию, организовывали систему пожаротушения, ставили промышленные кондиционеры. В таком режиме мы прожили лет 7.

В 2012 году был очередной переезд и нам повезло. Мы заехали в помещение, которое раньше занимал банк и там уже было специально оборудованное помещение серверной – это первый раз, когда нам не пришлось самим ее строить.

Важно, что в нашем офисном ЦОД мы никогда не хранили данные клиентов. У операторов связи, наших основных клиентов, достаточно развиты свои IT-службы, есть свои ЦОДы, узлы связи. У крупных операторов связи обязательно три контура для критичных информационных систем типа биллинга.

Так что до «эпохи» SaaS тестирование можно было достаточно легко проводить максимально близко к реальным данным на тестовом контуре самого оператора. Мы проводили внутреннее тестирование релиза в своем офисном ЦОДе, затем накатывали его на тестовый контур оператора.

Но несмотря на возможности тестирования в контуре оператора, для своей локальной лаборатории нам приходилось закупать оборудование и ставить софт максимально приближенный к тому, что использовался у наших клиентов. Что популярно у операторов связи, того же типа оборудование мы закупаем и для себя.

В разное время закупали серверы Supermicro, оборудование HP, DELL, в последнее время HUAWEY и железо отечественных производителей. Мы остаемся в рамках х86-архитектуры, так что иногда даже сами популярные поставщики предоставляли какое-то оборудование для тестов. Порой по результатам проверки мы выкупали тестовые стенды. С точки зрения серверных ОС мы всегда были Linux-ориентированными.

Организационные изменения

К 2008 выросла наша команда, в этот момент тимлид разрабов вырастает в архитектора системы, создается отдел продаж, поддержка, растет R&D. Постепенно мы налаживали партнерские отношения с интеграторами, они тоже начали продавать/внедрять нашу систему. Росли потребности в поддержке, обучении клиентов и партнеров, у нас появлялись новые бизнес-начинания и идеи для расширения линейки продуктов.

Сейчас нас 70 человек, в процессе взросления мы пережили 3 достаточно крупных перестройки организационной структуры, и несколько экономических кризисов. Линейка предлагаемых нами продуктов позволяет полностью автоматизировать современного оператора связи. С 2019 года мы вышли на международный рынок и продвигаем наши продукты совместно с иностранными интеграторами.

Новая рыночная ниша 2.0

5 лет назад начали появляться запросы от малого бизнеса – “у вас решение хорошее, но тяжелое и дорогое в поставке”. Мы стали думать, что с этими запросами делать. Плюс в то время массово появлялись проекты по модели SaaS, и мы решили не отставать.

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

Так что можно сказать что в году 2014-2015 мы создали новое подразделение и стали двигаться в сторону SaaS, параллельно реализовывая пилотный проект по предоставлению доступа к BSS-сервисам в облаке.

Виртуализируем и переносим во внешний дата-центр IT-инфраструктуру

В первую очередь мы пробовали развернуть сервис у себя в офисном ЦОД, но получив 2-3 аварии и рекламации в пилотных проектах (это при том, что электричество и связь качественно резервировались), мы поняли, что по независящим от нас причинам мы все же не сможем обеспечить заявленное качество работы SaaS.

Работа с боевыми базами клиентов и содержание их на наших мощностях – это высокая ответственность за непрерывность работы и доступность сервисов. Разница по требованиям, которые мы предъявляли к надежности собственной лаборатории, тестового окружения и внутренним сервисам очень большая. Нельзя работать и выполнять требования SLA перед клиентом, если какие-нибудь строители перебили оптику около здания или возникают перебои с электричеством – сотрудники клиента не могут войти в информационную систему, возникают простои и штрафы, риски слишком высоки.

Плюс в 2014 мощностей собственного ЦОДа в офисе нам становится недостаточно. Требуются очередные капитальные вложения в апгрейд железа, чтобы выполнять нагрузочное тестирование высокопроизводительных систем входящих в линейку продуктов, вести параллельную разработку нескольких продуктов, обеспечивать тестовое окружение для разных релизов, поддерживать нормальную работу смежных сервисов – багтрекеров, сервис деска и т.д.

Сначала мы переехали в дата-центр, где нам пообещали, что будет в ближайшее время проведена сертификация по Tier III, дали нам гарантийное письмо. По деньгам предложение было интересным, и мы согласились.

Арендовали в дата-центре место, завезли свои стойки и серверы, подключили к инфраструктуре. Переезд осуществляли с остановкой сервисов, заранее предупредили клиентов, выбрали время минимальной нагрузки и ночью оперативно перевезли. В первую очередь вынесли в дата-центр все коммерческие сервисы, чтобы обеспечить максимальную надежность для клиентов, а затем часть своей внутренней инфраструктуры.

К сожалению, надежды оправдались не полностью – почти за два года нахождения в нашем первом внешнем дата-центре сертификация по Tier III ЦОДом так и не была получена, а мы имели 4 аварии за 2 года. Поэтому мы приняли решение о смене дата-центра.



Подыскали современный сертифицированный по Tier III дата-центр и заново запустили процедуру переезда с учетом предыдущего опыта. Понравились дополнительные услуги дата-центра по переезду – помощь со специализированным транспортом для перевозки серверных стоек, грузчики, готовность обеспечить доступ в машинные залы во внеурочное время. В этот раз качество услуг было на хорошем уровне. За несколько лет работы в этом новом дата-центре серьезных аварий не было, что нас радует и позволяет бесперебойно обеспечивать доступ клиентам к нашим SaaS-решениям.

Простое сравнение без оглядки на конкретное оборудование — помещения под собственный ЦОД в офисе нам обходились дешевле, чем аренда под такое же количество стоек в дата-центре. Фактически стоимость размещения и аренды облака в дата-центре обходится дороже, чем «самопальный» офисный ЦОД, но надежность перевешивает. Сейчас относительные цены в дата-центрах снизились из-за роста конкуренции и баланс расходов постепенно смещается.

Виртуальный ЦОД для нашего SaaS-биллинга

После переезда в Tier III дата-центр мы стали растить мощности своего виртуального ЦОДа по мере увеличения количества корпоративных клиентов, которых мигрировали в виртуальную инфраструктуру и появления новых клиентов, использовавших наше облако для размещения биллинга и PRM-систем. Затраты на дата-центр полностью заменили собой вложения в капитальную IT-инфраструктуру нашего офисного ЦОДа.

Среди корпоративных клиентов первым заехал в наше облако в новом дата-центре достаточно крупный MVNO оператор. Сейчас в наших SaaS живет более 20 компаний с ёмкостью базы примерно в 500 тысяч абонентов.

С точки зрения тестирования новых бизнес-идей облако дата-центра очень удобно – можно на пару месяцев увеличить мощности или организовать отдельную виртуальную среду. Протестировали, если не зашло, то просто свернули бизнес-прототип, откатили изменения и отказались от дополнительных мощностей. То же самое при нагрузочном тестировании – берем на короткий промежуток времени большие мощности в аренду и радуемся. Не нужно нести капитальные расходы на закупку оборудования.

В текущий момент мы сертифицированы для построения биллинга на сетях до 25 000 000 номеров/абонентов. Серверную часть разворачиваем в Linux/UNIX окружении на x86-архитектуре. Клиентская часть может быть развернута на любой современной ОС, где запускаются современные популярные веб-браузеры. Базы данных могут быть использованы Oracle и PostgreSQL.

Естественно, что нагрузка может сильно отличаться в зависимости от функционала. В жизни нужно закладывать запас, ориентироваться на пики нагрузки, наращивать мощность по мере усложнения расчетов и роста объемов обрабатываемых данных с оборудования. В ситуации, когда возможна сильная динамика изменения количества абонентов в большую сторону(например, приобретение и поглощение других операторов), выигрышно смотрится возможность использовать гибкость современного ЦОД.

Как работаем сейчас и советы по переезду во внешние дата-центры

Раньше биллинг при покупке выбирали айтишники, сейчас все чаще этим занимается бизнес, маркетологи, продавцы, а IT занимается поддержкой и обслуживанием, минимальным контролем, чтобы не впарили ерунду. А критерии выбора айтишниками и маркетологами очень сильно отличаются, в том числе в плане визуального восприятия информационной системы.

Текущая версия нашей платформы — 3.2. Первая версия была в 2005-2006 годах. Вторая – 2006-2014. Третья – с 2014. Мы стараемся не оказаться в ловушке устаревания технологических решений — обновляем используемые инструменты разработки и оценки производительности, постоянно допиливаем веб-интерфейс. Там, где это целесообразно, мы расширяем стек применяемых технологий. В части решений сейчас используются Tarantool, PostgreSQL, Hazelcast. И мы постоянно ищем новые перспективы. Это накладывает ряд требований к используемому оборудованию и возможности гибкого его переконфигурирования.

В текущий момент мы можем порекомендовать крупным компаниям обратить внимание на гибридную схему, когда задействованы одновременно физические серверы и облако дата-центра. Например, все, что относится к БД, работает на конкретном выделенном оборудовании, а хорошо распараллеливаемые и виртуализируемые процессы отдаются в облако дата-центра.

Георезервирование – обязательное требование крупных операторов. Сейчас для части наших клиентов мы поддерживаем работу с тремя дата-центрами в разных частях нашей большой страны. Данный подход позволяет предоставить клиенту максимальную отказоустойчивость выбранного клиентом сервиса.

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

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

Если хотите поделиться своими историями по переносу вашей инфраструктуры в виртуальное окружение, во сколько это вам обошлось по деньгам, какие системные или специфические требования есть у вашего софта/сервисов и как они пережили миграцию во внешние дата-центры – добро пожаловать в комментарии. Всегда интересно, как другие решали схожие задачи :)