У производства было сравнение на этапе аналитики по ТТХ разных альтернативных решений. Кроме ТТХ также рассматривался вопрос текущей доступности лицензирования. В статье затронули сравнение тестовых проговнов с Redis. Невозможно было включить все сравнения в 1 статью, не в этом задача была. Про то, что в чистом виде Postgres не везде подойдет в предлагаемой роли - безусловно, факт. Там есть какие вопросы порешать. Приведенный опыт больше подходит на успешный proof of concept. Если концепт подходящий, то дальше уже можно углубляться в поиски или реализацию движков хранения и прочие вопросы.
Эти решения в начале были в группах кандидатов, но отсеялись по ходу:
Aerospike не подошел по лицензионной политике.
KeyDB и RocksDB не использовали ранее, но варианты интересные. Но так как скорость не стояла во главе угла, надо было удержаться в рамках "не хуже CB" и желательно без экспериментов (критичный узел критичного продукта, короткие сроки).
Tarantool хорош, мы его даже успешно тестировали. Но его выбор будет означать хоть и незначительный, но vendor-lock (все же это сервер приложений и под него нужна отдельная реализация серверной логики на стороне кластера TNT). Нам же хотелось получить абстрактный источник key-value данных, который на стороне приложения можно менять малой кровью через адаптеры.
NORD имеет ряд специальных доработок, в основном в части информационной безопасности и удобства эксплуатации.
К примеру: - Администратор может задавать и контролировать сложность паролей пользователей; - Доступно хранение истории паролей с настраиваемой глубиной; - Планировщик заданий с гибким расписанием и возможностью запуска в нескольких БД.
1. Цель данной статьи — рассказать в целом о разработке новой платформы Nexign Mediation, о возможностях ее использования в разных сферах, об общих принципах настройки и поддержки, не акцентируя внимания на обработке определенных типов данных.
Упомянутый в статье CDR — это только частный случай из телекома, так как он, на данный момент, ближе всего к компании. Но в целом платформа может собирать и обрабатывать любые данные внутри поддерживаемых форматов, назовем их xDR.
Кроме всего прочего, Nexign Mediation собирает и обрабатывает данные по NetFlow.
Что касается IDR — то это записи регистрации абонентских данных, которые приходят в запросе по DIAMETER с оборудования. Для этого у нас есть другой продукт, который занимается онлайн-сбором данных по DIAMETER, в этой статье мы его не упоминаем.
2. Платформа Nexign Mediation спроектирована в "открытом" виде, биллингистам не составит труда быстро научиться с ней работать: отслеживать её состояние, модифицировать сценарии и добавлять новые, поддерживать НСИ и расписание запусков сценариев, проводить аналитику по отчетам о принятых данных, работать с ошибками, делать сверку и т.д. Все действия разграничены разными правами и фиксируются аудитом.
К тому же, в помощь для настройки, мы поставляем набор из тестовых сценариев с примерами настройки разных парсеров и обработки в целом, которые можно использовать как шаблон при создании собственных сценариев. Также есть пакет подробной документации по работе с продуктом.
3. У нас есть наработки по инструментам миграции, но миграция миграции рознь и для каждого оператора ее длительность будет отличаться по времени, связано это время с типом реализации старых конфигураций и настроек обработчиков.
Под "быстрым запуском" имеется ввиду время без миграции. Продукт можно запустить за несколько часов или даже минут с предустановленными настройками (бекап), например, если речь о новой площадке. Обновление продукта также проходит достаточно быстро — за несколько минут.
4. Мы разобрали несколько протоколов, к которым у нас был доступ (Alcatel, Ericsson, Nokia, ZTE…), и нашли, что их можно описать в общем виде следующим образом:
· Присутствует или нет «не-ASN1» заголовок, и длина заголовка задана фиксировано или внутри самого заголовка.
· Весь файл — единая ASN1-структура, или последовательный их список.
· Если единая ASN1-структура, то искомый список xDR надо искать либо по указанному тегу, либо просто сместиться на указанное число тегов внутрь.
· Если это список готовых xDR, то: а. они могут быть разделены на блоки указанной длины и с указанным разделителем (0x00, 0xFF); b. может быть несколько байт, которые надо пропускать; c. может быть сложная структура, для которой следует спуститься вниз на несколько элементов или брать только элементы внутри заданного тега.
В целом, таких правил оказалось достаточно, чтобы описать все встретившиеся нам типы ASN1-кодирования. Ну а после декодирования, получив уже просто список деревьев с параметрами, можно их мапить на результирующий плоский список. Нюансов в CSV мы не встретили (кроме разного вида разделителей), а с BinaryOffset были аналогичные вопросы, как и с ASN1, и решались аналогично.
5. Это, конечно, не сущность БД и не протокол. Это некая программная реализация, состоящая из объектов пакетов с метаданными, шины данных для их передачи, и потоковой реализации, вызывающей интерфейсы акторов в нужный момент.
6. Да, можно запустить на нужном количестве серверов, в том числе виртуальных.
7. В разных ЦОД’х один кластер запустить не получится. Это по большей части ограничение используемого PostgreSQL, так что если его выйдет запустить Active-Active в нескольких ЦОД’х — то можно попробовать.
8. Конфигурация хранится в служебной БД (postgres, oracle), прозрачно экспортируется/импортируется через XML-ки. Каждый оператор (актор) — одна строка таблицы. При редактировании мы пишем в БД новые данные и в исторические таблицы — изменения. Бэкап выполняется как на уровне БД, так и, для удобства работы на нескольких площадках (ПРОМ/тестовые зоны), через автоматический экспорт через файловую систему: измененные сценарии сбрасываются на диск и там попадают под контроль git. Соответственно, поставка сценариев тоже идет через xml-ки, которые автоматически читаются с диска в БД.
Nexign Nord — это система управления базами данных (СУБД) на платформе PostgreSQL. Nexign Nord отличается улучшенными характеристиками безопасности и удобства эксплуатации. Чуть подробнее о продукте расскажем в статье через несколько недель.
Если вы хотите составить собственное мнение о Nexign Nord, то рекомендуем попробовать продукт бесплатно.
Часть ребят выполнили тестовое, потому что им было интересно получить фидбек по нему, а на собеседование не были готовы прийти.
Вместе с тем, у нас действительно довольно высокие требования к навыкам и общему инженерному уровню кандидатов.
Зависит от команды, но обычно в ходе собеседования обсуждаем вопросы технического характера, даем небольшие задания. И, конечно, рассказываем о компании, о проекте, о задачах, команде, отвечаем на все вопросы.
Мы поделились опытом, может, кому-то это будет интересно.
Заголовок взяли яркий, т.к. и проект сам по себе яркий)
Подробностей сейчас не так много, но в перспективе сможем рассказать механику более детально и разобрать тестовые.
Да, это верно: мы ищем людей которым интересно работать, решать задачи. В ответ мы предлагаем комфортные условия, работу в команде с профессионалами, достойную оплату, перспективы развития, расширенный соцпакет и прочие «плюшки».
RnD занимается продуктовой (не сервисной!) разработкой на основе анализа потребностей рынка. Т.е. мы знаем какой продукт будет нужен нашем клиентам завтра и уже сегодня его создаем. Мы отрабатываем наиболее актуальные тенденций и используем современные методологии и технологии в разработке. Работа над новыми продуктами отвязывает от какого-то определённого шаблона разработки. Инициативность и креатив поощряются, разработчики свободны в выборе конкретных паттернов и механизмов реализации требуемого функционала, к их мнению прислушиваются, оно важно. Каждый потенциально способен подать идею, которая пойдёт в разработку и будет использована для создания продукта, которым будут пользоваться миллионы.
Нашим инженерам должно быть важно не просто написать некий код по тех.заданию и получить за это деньги (хотя это безусловно важно), но мы хотим чтобы каждому человеку в нашей команде было интересно работать над продуктом. Что может мотивировать сильнее, чем интересная задача?
В разных компаниях разные ожидания и требования к специалистам, в т.ч. и к Junior. В нашей компании смотрят на потенциал и желание развиваться в выбранной специализации.
Телеком-вендоры сталкиваются с тем, что многие молодые IT-специалисты считают OSS/BSS зрелыми решениями. Перспективная молодежь опасается, что в этих контурах не предвидится революций или интересного развития. Мы хотим уверить читателей, что это совершено не так – места для самореализации и подвига у нас вполне достаточно!
Операторы дают вендорам другую обратную связь. Они говорят, что людей, пользующихся только услугами связи, все меньше. Все заинтересованы, чтобы рынок digital-услуг развивался.
У производства было сравнение на этапе аналитики по ТТХ разных альтернативных решений. Кроме ТТХ также рассматривался вопрос текущей доступности лицензирования. В статье затронули сравнение тестовых проговнов с Redis. Невозможно было включить все сравнения в 1 статью, не в этом задача была. Про то, что в чистом виде Postgres не везде подойдет в предлагаемой роли - безусловно, факт. Там есть какие вопросы порешать. Приведенный опыт больше подходит на успешный proof of concept. Если концепт подходящий, то дальше уже можно углубляться в поиски или реализацию движков хранения и прочие вопросы.
Эти решения в начале были в группах кандидатов, но отсеялись по ходу:
Aerospike не подошел по лицензионной политике.
KeyDB и RocksDB не использовали ранее, но варианты интересные. Но так как скорость не стояла во главе угла, надо было удержаться в рамках "не хуже CB" и желательно без экспериментов (критичный узел критичного продукта, короткие сроки).
Tarantool хорош, мы его даже успешно тестировали. Но его выбор будет означать хоть и незначительный, но vendor-lock (все же это сервер приложений и под него нужна отдельная реализация серверной логики на стороне кластера TNT). Нам же хотелось получить абстрактный источник key-value данных, который на стороне приложения можно менять малой кровью через адаптеры.
Нет, за основу мы взяли логику pg_cron и переработали его под запуск на неограниченном количестве БД.
NORD имеет ряд специальных доработок, в основном в части информационной безопасности и удобства эксплуатации.
К примеру:
- Администратор может задавать и контролировать сложность паролей пользователей;
- Доступно хранение истории паролей с настраиваемой глубиной;
- Планировщик заданий с гибким расписанием и возможностью запуска в нескольких БД.
В новых продуктах стараемся сразу всё писать по уму :)
.
1. Цель данной статьи — рассказать в целом о разработке новой платформы Nexign Mediation, о возможностях ее использования в разных сферах, об общих принципах настройки и поддержки, не акцентируя внимания на обработке определенных типов данных.
Упомянутый в статье CDR — это только частный случай из телекома, так как он, на данный момент, ближе всего к компании. Но в целом платформа может собирать и обрабатывать любые данные внутри поддерживаемых форматов, назовем их xDR.
Кроме всего прочего, Nexign Mediation собирает и обрабатывает данные по NetFlow.
Что касается IDR — то это записи регистрации абонентских данных, которые приходят в запросе по DIAMETER с оборудования. Для этого у нас есть другой продукт, который занимается онлайн-сбором данных по DIAMETER, в этой статье мы его не упоминаем.
2. Платформа Nexign Mediation спроектирована в "открытом" виде, биллингистам не составит труда быстро научиться с ней работать: отслеживать её состояние, модифицировать сценарии и добавлять новые, поддерживать НСИ и расписание запусков сценариев, проводить аналитику по отчетам о принятых данных, работать с ошибками, делать сверку и т.д. Все действия разграничены разными правами и фиксируются аудитом.
К тому же, в помощь для настройки, мы поставляем набор из тестовых сценариев с примерами настройки разных парсеров и обработки в целом, которые можно использовать как шаблон при создании собственных сценариев. Также есть пакет подробной документации по работе с продуктом.
3. У нас есть наработки по инструментам миграции, но миграция миграции рознь и для каждого оператора ее длительность будет отличаться по времени, связано это время с типом реализации старых конфигураций и настроек обработчиков.
Под "быстрым запуском" имеется ввиду время без миграции. Продукт можно запустить за несколько часов или даже минут с предустановленными настройками (бекап), например, если речь о новой площадке. Обновление продукта также проходит достаточно быстро — за несколько минут.
4. Мы разобрали несколько протоколов, к которым у нас был доступ (Alcatel, Ericsson, Nokia, ZTE…), и нашли, что их можно описать в общем виде следующим образом:
· Присутствует или нет «не-ASN1» заголовок, и длина заголовка задана фиксировано или внутри самого заголовка.
· Весь файл — единая ASN1-структура, или последовательный их список.
· Если единая ASN1-структура, то искомый список xDR надо искать либо по указанному тегу, либо просто сместиться на указанное число тегов внутрь.
· Если это список готовых xDR, то: а. они могут быть разделены на блоки указанной длины и с указанным разделителем (0x00, 0xFF); b. может быть несколько байт, которые надо пропускать; c. может быть сложная структура, для которой следует спуститься вниз на несколько элементов или брать только элементы внутри заданного тега.
В целом, таких правил оказалось достаточно, чтобы описать все встретившиеся нам типы ASN1-кодирования. Ну а после декодирования, получив уже просто список деревьев с параметрами, можно их мапить на результирующий плоский список. Нюансов в CSV мы не встретили (кроме разного вида разделителей), а с BinaryOffset были аналогичные вопросы, как и с ASN1, и решались аналогично.
5. Это, конечно, не сущность БД и не протокол. Это некая программная реализация, состоящая из объектов пакетов с метаданными, шины данных для их передачи, и потоковой реализации, вызывающей интерфейсы акторов в нужный момент.
6. Да, можно запустить на нужном количестве серверов, в том числе виртуальных.
7. В разных ЦОД’х один кластер запустить не получится. Это по большей части ограничение используемого PostgreSQL, так что если его выйдет запустить Active-Active в нескольких ЦОД’х — то можно попробовать.
8. Конфигурация хранится в служебной БД (postgres, oracle), прозрачно экспортируется/импортируется через XML-ки. Каждый оператор (актор) — одна строка таблицы. При редактировании мы пишем в БД новые данные и в исторические таблицы — изменения. Бэкап выполняется как на уровне БД, так и, для удобства работы на нескольких площадках (ПРОМ/тестовые зоны), через автоматический экспорт через файловую систему: измененные сценарии сбрасываются на диск и там попадают под контроль git. Соответственно, поставка сценариев тоже идет через xml-ки, которые автоматически читаются с диска в БД.
Nexign Nord — это система управления базами данных (СУБД) на платформе PostgreSQL. Nexign Nord отличается улучшенными характеристиками безопасности и удобства эксплуатации. Чуть подробнее о продукте расскажем в статье через несколько недель.
Если вы хотите составить собственное мнение о Nexign Nord, то рекомендуем попробовать продукт бесплатно.
Форматов, которые требуют больше времени, пока не будет.
Вместе с тем, у нас действительно довольно высокие требования к навыкам и общему инженерному уровню кандидатов.
Заголовок взяли яркий, т.к. и проект сам по себе яркий)
Подробностей сейчас не так много, но в перспективе сможем рассказать механику более детально и разобрать тестовые.
Операторы дают вендорам другую обратную связь. Они говорят, что людей, пользующихся только услугами связи, все меньше. Все заинтересованы, чтобы рынок digital-услуг развивался.