Продолжаем рассказ о методологиях разработки в области больших данных, используемых в «МегаФоне» (первая часть статьи).
здесь ).
Каждый день приносит нам новые проблемы, которые требуют новых решений.
Поэтому методы организации разработки постоянно совершенствуются.
Как мы работаем сейчас
Непрерывная доставка
Практическое внедрение Канбана означает результаты с чрезвычайно быстрой обратной связью.
Этим требованиям отвечает концепция непрерывной доставки (CD), которую можно визуализировать в виде конвейера: 
Принятая нами методология разработки предполагает очень короткие периоды итераций.
По этой причине конвейер CD максимально автоматизирован: все три этапа тестирования проводятся без вмешательства человека на сервере непрерывной интеграции.
Он принимает все изменения, внесенные на этапе «Разработка», применяет их, запускает тесты, а затем выдает отчет об успешности тестирования.
Последний этап, «Развертывание», также выполняется автоматически в тестовых средах разработчиков, но для развертывания в пользовательских средах требуется человеческая команда.
Если говорить об одном приложении (например, о создании простого сайта), то процесс создания компакт-диска не вызывает никаких затруднений.
Но в случае разработки платформы ситуация меняется: платформа может иметь множество различных применений.
Еще сложнее будет протестировать все изменения при создании платформы обработки данных: для получения точных результатов потребуется загрузить пару десятков терабайт данных.
Это значительно удлиняет цикл непрерывной интеграции, поэтому его необходимо разделить на более мелкие задачи и протестировать на небольших объемах данных.
Товары для доставки
Что именно поставляется в рамках процесса CD : • Обычные процессы, выполняемые в Hadoop ( ЭТЛ ).• Аналитические услуги в режиме реального времени.
• Интерфейсы для потребителей результатов аналитики.
Типичное бизнес-требование охватывает все три комплекта поставки: необходимо наладить регулярные и онлайновые (реальные) процессы, а также обеспечить доступ к результатам — создать интерфейсы.
Разнообразие интерфейсов существенно усложняет процесс разработки; все они требуют обязательного тестирования в рамках процесса CD. Непрерывная интеграция Тестируемость продукта — одно из основных требований методологии CD. Для этого мы создали инструментарий, позволяющий автоматически тестировать элементы поставки на машине разработчика, на сервере непрерывной интеграции и в среде приемочного тестирования.
Например, для процессов, разработанных на языке программирования Апачская свинья , мы разработали плагин maven, который позволяет локально тестировать сценарии, также написанные на Apache Pig, как если бы они выполнялись в большом кластере.
Это позволяет существенно сэкономить время.
Мы также разработали собственный установщик.
Он выполнен в виде DSL -основанный на языке классный и позволяет очень просто и четко указать, куда нужно отправить каждый предмет доставки.
Вся информация о доступных средах — тестовой, предварительной и рабочей — хранится в созданном нами сервисе конфигурации.
Эта служба является исполнительным посредником между установщиком и средой.
После развертывания элементов поставки проводится автоматическое приемочное тестирование.
В ходе этого процесса моделируются все возможные действия пользователя: перемещение курсора мыши, переход по ссылкам в интерфейсах и на веб-страницах.
То есть проверяется корректность работы системы с точки зрения пользователя.
По сути, бизнес-требования четко фиксируются в форме приемочных тестов.
Товары доставки также подлежат автоматическому нагрузочному тестированию.
Его цель – продемонстрировать соответствие требованиям к производительности.
У нас для этого созданы специальные условия.
Следующий шаг — статистический анализ качества кода на предмет стиля и типичных ошибок кодирования.
Код должен быть корректным с точки зрения компилятора и не должен содержать логических ошибок, плохих имен и других недостатков стиля.
Все разработчики следят за качеством кода, но в нашей отрасли применение такого анализа к результатам не является стандартным шагом.
Инфраструктура После успешного завершения тестирования начинается этап развертывания.
В процессе отправки объектов поставки в промышленную эксплуатацию контроль происходит автоматически, без вмешательства человека.
Наш серверный парк состоит из более чем 200 машин; система используется для управления конфигурациями сервера Кукольный .
Достаточно физически установить сервер в стойку, указать системе управления среду для подключения и роль сервера, а дальше все происходит автоматически: загрузка всех настроек, установка ПО, подключение к кластеру, запуск соответствующих серверных компонентов.
на желаемую роль.
Такой подход позволяет подключать и отключать серверы десятками, а не по отдельности.
Мы используем простую конфигурацию среды : • Рабочие серверы (рабочие узлы) в виде обычных «аппаратных» машин.
• Облако виртуальных машин для различных утилитарных задач, не требующих большого количества энергии.
Например, управление метаданными, хранилище артефактов, мониторинг.
Благодаря такому подходу утилитарные задачи не занимают мощности физических серверов, а коммунальные службы надежно защищены от сбоев; виртуальные машины перезапускаются автоматически.
Однако производственные серверы — не единственные точки отказа, их можно безболезненно заменить или перенастроить.
Часто можно услышать о платформах, где при построении кластеров упор делается на облачную экосистему.
Но использование облака для решения «тяжелых» аналитических задач с большими объемами данных менее экономически эффективно.
Используемая нами схема построения среды экономит затраты на инфраструктуру, поскольку обычная невиртуальная машина более эффективно выполняет операции ввода-вывода с локальных дисков.
Каждая среда состоит из части облака виртуальных машин и ряда производственных серверов.
У нас также есть тестовые среды на виртуальных машинах по требованию, которые временно развертываются для решения определенных проблем.
Эти машины можно даже создать на локальной машине разработчика.
Для автоматического развертывания виртуальных машин мы используем приложение Бродяга .
Помимо изолированных программных программ для разработчиков, мы поддерживаем три важные среды.
: • Средой приемочного тестирования является UAT. • Среда для нагрузочного тестирования – Производительность.
• Промышленная среда - Производство.
Переключение производственных серверов из одной среды в другую занимает считанные часы.
Это простой процесс, требующий минимального вмешательства человека.
Для мониторинга используется распределенная система.
ганглии , логи агрегируются в Elastic, для оповещения — Нагиос .
Вся информация отображается на видеостене, состоящей из больших телевизоров, управляемых микрокомпьютерами Raspberry Pi. Каждый из них отвечает за отдельный фрагмент общего большого изображения.
Эффективное и очень доступное решение: на информационной панели отображается общая наглядная картина состояния среды и процесса непрерывной доставки.
Одного взгляда достаточно, чтобы получить точную информацию о том, как идет процесс разработки и как сервисы себя чувствуют в производственной эксплуатации.
Метрики
Объем данных, которые мы обрабатываем, превышает 500 000 сообщений в секунду.На 50 000 из них система реагирует менее чем за секунду.
Накопленная база данных для анализа занимает около 5 петабайт, в будущем она вырастет до 10 петабайт. Каждый сервер отправляет в среднем 50 показателей в минуту для мониторинга.
Количество индикаторов, по которым отслеживаются и сигнализируются допустимые параметры, составляет более 1600.
Использование результатов анализа
Большие данные — бесценный источник информации: превращая цифры в знания, вы можете разрабатывать новые продукты для подписчиков, улучшать существующие и быстро реагировать на изменения ситуации или, например, моделей поведения пользователей.Вот лишь несколько примеров из довольно большого списка применимости Big Data: • Геопространственный анализ распределения сетевой нагрузки: где, как и почему увеличивается сетевая нагрузка.
• Поведенческий анализ устройств в сотовой сети.
• Динамика появления новых устройств.
В частности, мы используем результаты анализа больших данных при радиопланировании и модернизации собственной сетевой инфраструктуры.
Также мы создали ряд сервисов, предоставляющих различную аналитику в режиме реального времени.
Для открытого рынка мы (впервые на российском телекоммуникационном рынке!) в ноябре 2013 года запустили геопространственный сервис для анализа городских потоков, включая пешеходов и общественный транспорт. В мире существует лишь несколько примеров таких коммерческих услуг, не основанных на GPS.
Команда
Отдельно расскажем немного о нашей команде.Помимо команды R&D, которая занимается непосредственно разработкой сервисов, у нас есть отдел DevOps, который отвечает за работоспособность всех решений.
Они вместе с клиентами участвуют в процессе постановки задач и предлагают свои улучшения для каждой из услуг.
Они также устанавливают требования к качеству и функциональности разработок, участвуют в тестировании и приемке.
Подробнее об этом направлении вы можете прочитать здесь .
О нашем московском офисе не раз писали в различных изданиях (например, здесь ), но следует отметить, что разработчики, DevOps и аналитики работают на расстоянии друг от друга): в Москве, Нижнем Новгороде и Екатеринбурге.
Чтобы процесс не пострадал, мы используем множество платных и бесплатных инструментов, которые значительно облегчают жизнь каждому.
Нам очень помогает Слабый для коммуникации как внутри команды разработчиков, так и с подрядчиками.
Сейчас это вообще модный хипстерский тренд, но как инструмент общения он очень и очень хорош.
Кроме того, мы перешли на внутренний GitLab и интегрировали все процессы с Jira и Confluence. Для всех офисов внедрены единый стандарт разработки, единые правила оформления задач, единый подход к обеспечению сотрудников оборудованием и другими вещами, необходимыми для работы.
С течением времени мы сталкиваемся со все большим количеством проблем.
Поэтому наша команда пополняется новыми профессионалами, способными принести пользу в самых разных сферах.
Работа с большими данными в крупном операторе связи — интересная и амбициозная задача.
И мы с оптимизмом смотрим в будущее – впереди нас ждет много интересного.
P.S. НА ТЕХ ЖЕ РЕЛЬСАХ Дочерние компании РЖД получили в пользование тестовую версию разработанного «МегаФоном» сервиса анализа пассажиропотоков.
Это инструмент, который помогает определить размер и подробные характеристики транспортного рынка.
Коммерческий запуск проекта ожидается в 2016 году.
Сервис «МегаФона» позволяет РЖД управлять пассажиропотоком: мотивировать людей приобретать билеты на тот или иной маршрут, анализировать снижение или рост уровня продаж и заполняемости вагонов.
Анализ полученной информации позволяет оперативно вносить коррективы: варьировать цены на билеты (например, делая их привлекательными как в определенное время суток, так и в «низкий» сезон), оптимизировать расписание поездов (добавлять дополнительные поезда в часы пик и, наоборот, убрать те, которые не используются поездами, востребованными в определенное время).
Например, сервис «МегаФон» проанализировал маршрут Москва-Волгоград-Москва во время майских праздников этого года: спрос увеличился на 6,8% по сравнению с аналогичным периодом прошлого года.
При этом сервис показал, что потеря постоянных клиентов на маршруте Москва-Волгоград за последний год составила 8,3%.
«МегаФон» подсчитал, что транспортные компании России тратят на подобные исследования более 1,2 млрд руб.
ежегодно.
При этом сами компании могут собирать лишь часть доступных им данных, а сервис сотового оператора позволяет увидеть всю картину рынка в целом, благодаря чему оператор связи увеличивает свою долю на рынке.
общий рынок пассажирских перевозок на 1,5–2%.
А это миллиарды рублей.
Теги: #мегафон #Большие данные #scrum #картирование историй #управление проектами #Разработка сайтов #Большие данные
-
Distr 3: По С Пятидюймовых Дискет
19 Oct, 24 -
Инвестируйте В Точки, А Не В Линии
19 Oct, 24 -
Isa Не Прощает Ошибок
19 Oct, 24 -
Опрос Пользователей Игрового Linux
19 Oct, 24
