В начале года в Хельсинки прошла первая официальная конференция RoboCon 2018, посвящённая инструменту автотестирования Robot Framework. И мы, мейнтейнеры группы автоматизации интеграционного и системного тестирования компании «Петер-Сервис», не могли такое событие пропустить. Потому что этот инструмент у нас в компании используется довольно широко: в частности, в нашей группе с помощью него реализован продукт TORS (Testing of Release Stands).

Гигантский рост абонентской базы в 20-е и 30-е годы прошлого века. Появление «межгорода». Распространение повременных соединений. И, наконец, приход сотовой связи как самый значительный рывок в развитии биллинговых систем. Мы расскажем об их эволюции на протяжении истории существования телефонной связи.

Мобильные операторы, предоставляя разнообразные сервисы, накапливают огромное количество статистических данных. Я представляю отдел, реализующий систему управления трафиком абонентов, которая в процессе эксплуатации у оператора генерирует сотни гигабайт статистической информации в сутки. Меня заинтересовал вопрос: как в этих Больших Данных (Big Data) выявить максимум полезной информации? Не зря ведь одна из V в определении Big Data — это дополнительный доход.

Я взялся за эту задачу, не являясь специалистом в исследовании данных. Сразу возникла масса вопросов: какие технические средства использовать для анализа? На каком уровне достаточно знать математику, статистику? Какие методы машинного обучения надо знать и насколько глубоко? А может лучше для начала освоить специализированный язык для исследования данных R или Python?

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

В наше время термин “BIG DATA” у всех на слуху. После появления в сети и в прессе многочисленных публикаций, связанных с обработкой «больших данных», интерес к этой теме постоянно растет. Все более широким спросом пользуются системы управления базами данных с
использованием технологии NoSQL. Всем понятно, что для построения систем “BIG DATA” необходимо располагать внушительными аппаратными ресурсами. Еще более важно уметь оптимально использовать вычислительные ресурсы системы и эффективно их масштабировать. Это неизбежно меняет подходы к построению систем обработки данных.

Ищут пожарные,
Ищет милиция...

Что такое «Mission critical communication»? Это связь, от надежности которой зависят жизни людей. Примеры служб, для которых такая связь нужна – это система-112, МЧС, силовые структуры (МВД, ФСБ, Министерство обороны). Также mission critical связь необходима в зоне чрезвычайных ситуаций и на объектах, аварии на которых могут принести разрушительные последствия: энергетика, химическая промышленность, общественный транспорт и т.п.
Mission critical сети связи строятся на основе стандартов профессиональной мобильной радиосвязи (ПМР). На данный момент есть два основных стандарта: TETRA (Terrestrial Trunked Radio) ETSI EN 300 392 и DMR (Digital Mobile Radio) ETSI 102 361. Не буду вдаваться в подробности (информация по этим стандартам доступна в сети), но у них, помимо достоинств, есть существенный недостаток: они заточены на голос, а скорость передачи данных и видео существенно ограничена. Хотя понятно, что возможность передать видео с места событий может иметь критичное значение. Что же делать?

Что такое облака, и когда имеет смысл строить облачные решения? И если строить, то какие платформы использовать? Нужно ли предоставлять клиентам облачные сервисы? А может, лучше использовать виртуализацию? И чем отличается виртуализация от облаков? Эти вопросы задают все IT и «не IT» компании: от крупных операторов связи до небольших стартапов. Давайте попробуем разобраться! В предыдущей статье мы рассмотрели понятия SDN и NFV. Возникает вопрос — если и то и другое связано с виртуализацией и сетями, то это получились облака? Ведь все мы прекрасно знаем, что облака — это виртуализация ресурсов где-то в сети. Я попробовал найти формальное определение облаков, но не нашел. Определения были расплывчаты и нечетки, как настоящие облака. И тогда у меня возникло чувство, что ОБЛАКАМ невозможно дать четкого определения, они как ЛЮБОВЬ, которую можно только описывать и характеризовать с разных сторон. Дальнейшее расследование подтвердило это предположение. Для начала нашел стандарт Cloud Computing, который разрабатывает NIST (National Institute of Standards and Technology). Он выделяет 3 измерения облачных сервисов:

Мы ищем тестировщиков. Каждая IT-компания рано или поздно сталкивается с необходимостью найма таких специалистов. Поиски идут долго и часто заканчиваются неудачно. Ничего не поделаешь: рынок сильно перегрет, хороших тестировщиков мгновенно разбирают. Наши ВУЗы пока не готовят инженеров по качеству. Получается, что тестировщик – это не диплом, а призвание, и прогнозировать рост числа кадров невозможно. А у нас «горят» проекты, нам срочно нужны люди. В таких условиях мы решились на крайнюю меру: воспитать этих людей с нуля. Так возникла идея школы тестировщиков в «Петер-Сервис».

В этой статье мы поделимся опытом обучения тестированию непрофильных специалистов.

В крупных организациях часто возникает необходимость прикрутить к JIRA какой-либо дополнительный функционал, которого нет в стандартной поставке: автоматизацию, интеграцию с другими системами и прочие кастомизации. Зачастую это решается сторонними плагинами, в Atlassian Market их огромное количество. Но что делать, если подходящего плагина нет? Очевидно, написать свой. Ещё один вариант для расширения — плагины, добавляющие возможность использовать свои скрипты в JIRA: ScriptRunner (Groovy), Jira Scripting Suite (SIL), JJupin (Jython).

В этой статье я расскажу о самом популярном и функциональном из них — ScriptRunner от Adaptavist.

Как скрыть от посторонних конфиденциальную информацию?
Самое простое – зашифровать.
В Интернет и Интранет-сетях шифрацией данных управляет протокол SSL/TLS.
Солдат спит, служба идет.
Однако иногда возникает необходимость выполнить обратное – расшифровать перехваченный трафик.
Это может потребоваться как для отладки работы приложений, так и для проверки подозрительной сетевой активности.
Или в целях изучения работы SSL/TLS (очевидные, вредоносные цели не обсуждаются).

Как и при каких условиях можно расшифровать дамп SSL/TLS трафика в Wireshark?
Попробуем разобраться.

Собственно, возник вопрос: а присутствуют ли всякие DBA_TAB_PARTITIONS и иные объекты словаря в SE One? Причина вопроса проста: код заточен на Oracle EE и использует эти представления. После установки обнаружилось, что данные объекты не только присутствуют, но и не пусты. Раз не пусты, то из этого вытекает, что создать сегментированные таблицы возможно, а раз так, то неплохо бы посмотреть, как это происходит.

Oracle кластер умер, да здравствует кластеризация!

_{Здесь и далее имеется в виду cluster хранения данных, а не Oracle Real Application Custer}

Проблематика

Большим информационным системам свойственно постоянное поступление различной информации, которая накапливается, обсчитывается и архивируется. Мы рассмотрим вариант структурированных данных, хранящихся на сервере RDBMS Oracle и в качестве примера возьмём таблицу, содержащую CDR записи (т.е. записи о вызовах) для абонентов оператора связи.
Данные о звонках поступают хаотично, т.е. не упорядоченно, как вы понимаете, по атрибутам абонентов. Все данные имеют свой жизненный цикл — оперативные, актуальные и архивные. Со временем частота обращений и требования по скорости доступа к данным меняются (т.е. падают). Т.о. записи годичной давности вполне можно хранить на медленных дисках, активные — на дисках с высокой скоростью доступа и без претензий на производительность операций записи, а вот вновь поступающим данным свойственно требование к максимально высокой скорости записи и чтения.

Все справедливо считают, что конструкция ORDER BY расходует ресурсы на проведение сортировки результата и в итоге мы должны получить результат несколько позже. Всегда ли это так?..

Как-то, анализируя дефект в разрабатываемом продукте, я наткнулся на архитектурную особенность менеджера памяти, который мы использовали. Дефект приводил к увеличению времени создания некоторых объектов. Особенность архитектуры заключалась в использовании паттерна Singleton при работе с менеджером памяти (далее X allocator). Схематично это выглядит так:


Рисунок 1 – Структурная схема работы X allocator

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

Не так давно мы пощупали немножко Juniper SRX, настроили его , и собрали отказоустойчивый кластер. Теперь начнем поднимать на нем «боевые» схемы, ради которых все и затевалось.
Например, соберем мысленно вот такую схему:


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

juniper — можжевельник (англ.)

Намедни в мои цепкие лапы попали два Juniper SRX 550. Попали не просто так, а для организации надежного ipsec и NAT-шлюза, а также OSPF-роутера. Ну а так как главное для нас — надежность, то именно с нее и начнем.

Для того, чтобы обеспечить отказоустойчивость сервисов, критично важные узлы обычно дублируют. Для ЦОДов это уже практически стандарт — N+N или хотя бы N+1. При этом устройства могут работать как независимо друг от друга, так и в кластере. Для обоих типов есть свои плюсы и минусы, но если нужен не просто роутинг/свитчинг, но нечто более «интеллектуальное» (например, те же NAT или IPSec), то без кластера тут точно не обойтись. Так что при плановом апгрейде в качестве замены Cisco 7201 рассматривались именно роутеры, способные работать в кластере. В связи с этим ASR 1k отправился лесом (как и ISR), ASA не рассматривалась (потому как готовить ее не умею), а VSS из Cat6503 — это уж слишком жирно и в плане цены, и в плане съедаемой электроэнергии.

Герой нашего рассказа. (Здесь и далее — картинки с официального сайта Juniper)

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

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

Первая мысль после перезагрузки роутера: какой-то шутник решил запустить очередную убер-программу. Ну, или чей-нибудь ноут сошел с ума – тоже бывает. Однако пристальное изучение трафика (netflow, прослушка tcpdump-ом на предмет хитрого бродкаста) ничего не дало. Более того, шторм-контроль на клиентских портах не срабатывал.

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