До этого мы уже запускали Гидру в крупных компаниях, поэтому когда к нам незадолго до Нового года обратился белорусский оператор Космос-ТВ (дочка российского АКАДО Телеком), предоставляющий услуги доступа в интернет и цифрового эфирного и кабельного ТВ для 300 тысяч человек в Минске и области, это никого особенно не смутило.

Забеспокоились мы, когда клиент без тени сомнения заявил о том, что миграция на Гидру должна быть завершена уже в мае 2016 года. Получалось, что на все работы нам оставалось около трех месяцев, а ведь еще было необходимо утрясти все юридические и организационные моменты. При этом наша внутренняя Ванга предсказывала по опыту сотни прошлых внедрений, что с учетом всех проволочек с документами, организации тестовых стендов и подготовки выгрузки из старого биллинга, такой проект должен был занять около 1,5 лет. Нам предстояло перенести данные нескольких сотен тысяч абонентов, настроить управление доступом к услугам цифрового кабельного ТВ с CAS Irdeto, цифрового эфирного ТВ и доступа в Интернет по технологиям Ethernet и DOCSIS 2.0 и 3.0.

После долгих уговоров заказчик перенес дедлайн на июль — однако сдвигать его дальше ни за что не соглашался, объясняя это тем, что первого числа этого месяца в Белоруссии должна была пройти деноминация национальной валюты (о том, как мы к ней готовились, читайте в этом материале).

Казалось бы, это пусть и редкая, но не столь страшная операция, чтобы настолько сокращать сроки — однако выяснилось, что архитектура старого биллинга «Космоса» не позволяла перейти на новую валюту правильно. Поэтому у компании просто не было выбора.

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

Деноминация стала важнейшим фактором, который побудил нас стремиться завершить проект по внедрению нового биллинга как можно быстрее. Сами понимаете, проводить деноминацию гораздо проще сразу для новой системы, чем сначала делать это для старой, а затем мигрировать данные. Поэтому мы даже не рассматривали для себя возможности не успеть завершить проект — если честно, у нас не было никакого плана Б.
— Андрей Желябовский, начальник отдела информационных технологий «Космос-ТВ»

Несмотря на то, что мы приняли правила игры, было очевидно — успеть сделать все «от и до» в заявленные сроки не выйдет, поэтому мы оптимизировали план работ, выделив в нем критически важные задачи — миграцию данных, настройку платежного шлюза, провижининга, RADIUS-сервера и личного кабинета абонента — и те, которые можно реализовать уже после основного запуска.

Сразу стало ясно, что нам придется проявлять куда большую гибкость, чем обычно. К примеру, традиционно мы ведем проекты по внедрению в нашей проектной системе (о ней мы рассказывали здесь) — это дисциплинирует заказчиков и позволяет сразу видеть, на каком этапе застопорилась та или иная задача. Это минимизирует число просьб «скинуть документик на почту», уменьшая зоопарк используемых инструментов коммуникации. Такой «асинхронный» режим общения позволяет нашим инженерам эффективнее использовать свое рабочее время, но для отдельно взятого клиента это не всегда удобно.

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

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

К примеру, в начале внедрения мы обычно предоставляем заказчикам требования к инфраструктуре, которую нужно подготовить для корректной работы биллинга. Когда «железо» доступно, начинаются активные работы. Здесь же выяснилось, что заказанные для биллинга серверы будут поставляться в течение пары месяцев — совершенно неприемлемая задержка. Поэтому мы оперативно развернули виртуальные машины для создания среды для внедрения, с тем чтобы потом перенести конфигурацию на рабочий сервер заказчика.

Кроме того, нам пришлось несколько изменить организацию работ. Обычно наши инженеры задействованы в нескольких проектах сразу, но в этот раз более эффективной оказалась схема, при которой за «Космосом» были закреплены несколько инженеров, которые занимались только внедрением Гидры для этого оператора.

Уже в ходе работ выяснилось, что наши инженеры и специалисты заказчика не всегда говорят на одном языке. В буквальном смысле — часто одни и те же понятия трактовались совершенно по-разному, что приводило к недопониманию и задерживало работу. Когда стало ясно, что такими темпами успеть к деноминации не получится, мы с заказчиком договорились: его инженеры приедут к нам в офис и целую неделю проведут «в обнимку» с нашими.

Философия Гидры в корне отличалась от того, с чем мы сталкивались ранее. Нам было очень сложно понять, как данные из нашего старого биллинга представить в понятиях новой системы. Настоящий слом мозга — то, что раньше называлось одним образом, теперь называется и делается по-другому. Общение по скайпу и почте не могло решить эту проблему. Приехать к нам сотрудники «Латеры» не смогли, так что нам пришлось самим отправиться к ним в гости. — Андрей Желябовский, начальник отдела информационных технологий «Космос-ТВ»

Как выяснилось, это было важнейшее решение, определившее конечный успех проекта — за пару дней плотной работы в офисе «Латеры» нам удалось проделать объём работ, который планировалось «закрыть» за два-три месяца.

В итоге к моменту запуска было сделано около 80% от всех запланированных по проекту работ — этого оказалось достаточно для запуска Гидры в «голом» варианте — пока без автоматизации бизнес-процессов в Гидре OMS, управления наряд-заказами в Planado и прочих полезных вещей. С 1 по 4 июля мы завели все основные биллинговые процессы Гидры. В перод запуска инженеры работали в круглосуточном режиме.

Нам сыграло на руку, что в начале июля по всей стране на протяжении четырех дней не работали банки. Мы заранее предупредили абонентов о том, что с 1 по 4 июля платежи приниматься не будут, попросив оплатить услуги заранее. Так что мы получили дополнительное время на перенос всех процессов из старого биллинга в новый.

Покончив с описанием организационных вопросов, поговорим о решении возникавших технических задач. Для начала опишем общую схему работы провайдера.

Абоненты подключаются к сети оператора по двум схемам — либо по технологии DOCSIS, либо Metro Ethernet. В качестве BRAS использовалось оборудование MiktoTik и Cisco. Значительных особенностей в реализации не было, можно разве что отметить тот факт, что DOCSIS-модемам нужно было выдавать адрес файла с конфигурацией по DHCP и перезагружать модем при смене IP-адреса. При этом в случае Cisco аутентификация происходила по IP-адресу, а для MikroTik — по MAC-адресу. Для управления DOCSIS-оборудованием мы настроили в провижининге Гидры события для сброса сессий и перезагрузки модемов.

Для управления CAS Irdeto инженеры заказчика предоставили нам специальный скрипт, который имел два входных параметра — идентификатор карты и список подключенных пакетов ТВ-каналов. Если последний параметр оказывался пустым, то требовалось отключить все пакеты.

Взаимодействие с платежными системами проходило также с помощью предоставленного заказчиком скрипта, который проводил платежи напрямую через API Гидры. Единственное, что нам пришлось здесь сделать — создать для этого скрипта специальный пакет, который принимал параметры в нужном формате, а затем передавал вызовы для процедур ядра.

При миграции мы столкнулись и с некоторыми трудностями. Например, согласно нашей схеме, оборудование является модемом, а компонент — оконечное оборудование, которое подключено к порту модема. Проблема здесь в том, что разработанный нами инструмент для автоматизации миграции (о нем мы рассказывали ранее) изначально умел мигрировать лишь один компонент оборудования, поэтому потребовалось создание дополнительных скриптов, расширяющих его функциональность.

В ходе работ мы сталкивались с недостаточной производительностью системы миграции для конкретной схемы данных «Космоса», поэтому мы его оптимизировали с помощью «советов» (hints) SQL-оптимизатора, пары новых индексов и такой-то матери. Благодаря этому получилось сделать больше миграций и лучше поработать над качеством загружаемых в Гидру данных.

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

Также было непросто разобраться с миграцией скидок, которые предоставляются абонентам в рамках различных программ лояльности. Здесь нужно было не просто мигрировать скидку из старого биллинга в Гидру, но корректно учесть и ее период действия. Штатной возможности миграции скидок в наших инструментов не было, поэтому пришлось ее доработать и ввести дополнительные приказы по скидкам в Гидре.

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

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

• Нет ничего невозможного, но у всего есть цена — мы согласились на радикальное сокращение сроков проекта и выдержали их, и даже те работы, что будут сдвинуты во времени, мы все равно завершим раньше срока, указанного в договоре. Однако, столь высокий темп работы приводит к возрастанию рисков надежности и безопасности, что также необходимо понимать. Кроме того, в самое ответственное время проекта инженерам заказчика пришлось вести часть бизнес-процессов в полуручном режиме — в том числе, такие важные, как подключение нового абонента.
• Общение нужно оптимизировать — мы всегда ведем общение с заказчиком в собственной проектной системе. Но проект с «Космос-ТВ» показал, что иногда живое общение лучше всяких систем помогает быстро решать важные вопросы — особенно на начальных стадиях совместной работы. Главное здесь не забывать письменно фиксировать все договоренности, тогда никаких проблем не будет.
• Работа на пределе может приносить очень хорошие результаты на разовых проектах — этот проект тяжело дался нашим инженерам, и в разговорах они подчеркивают, что работать в таком режиме всегда ни за что не хотели бы. Но нельзя не сказать, что несмотря на общие затраты, вызванные необходимостью соблюдения жестких сроков (например, оплата сверхурочных инженерам «Латеры» и компании-заказчика и премий по итогам проекта), нам удалось добиться очень хорошего результата. Режим «форсаж», при котором мы намеренно «сжигали» больше ресурсов, чем обычно, привел очень мощной отдаче — мы сами не ожидали от себя такой эффективности.
• Самое главное: ничего бы не вышло без хорошо мотивированного заказчика с целеустремленным руководством и грамотными инженерами.