Русский
Русский
English
Статистика
Реклама

It-инфраструктура

Обеспечение сетевой безопасности совместно с брокерами сетевых пакетов. Часть вторая. Активные средства безопасности

13.04.2021 20:10:28 | Автор: admin

В первой части мы рассказали про наиболее популярные пассивные средства ИБ, которые применяются для мониторинга и анализа трафика в сети. Возникает логичный вопрос: если системы умеют выявлять угрозы, то почему бы не блокировать их? Сегодня предлагаем Вам поговорить про активные средства ИБ, их применение и проблемы внедрения в современную сетевую инфраструктуру.

Активные средства безопасности

Средства активной безопасности, подключаемые в разрыв (in-line), не только обнаруживают угрозы, но и блокируют их в режиме реального времени. При внедрении активных средств специалисты сталкиваются с проблемами обеспечения отказоустойчивости сети, дальнейшей масштабируемости средств безопасности, а также с необходимостью уменьшения задержек передачи пакетов при увеличении объёма трафика в сети.

Среди наиболее популярных активных средств информационной безопасности остановимся на IPS, NGFW, SWG, AMP, DLP и Anti-DDoS, а также рассмотрим способы их развёртывания на базе Bypass и брокеров сетевых пакетов для обеспечения гарантированной безопасности сети.

Системы предотвращения вторжений (IPS)

Системы предотвращения вторжений (Intrusion Prevention Systems - IPS) это программные и аппаратные средства, предназначенные для обнаружения и предотвращения попыток несанкционированного доступа к конфиденциальным данным, повышения привилегий, использования уязвимостей программного обеспечения и вывода из строя компьютерных систем. Такие попытки вторжений осуществляются главным образом через Интернет или локальную сеть, могут иметь форму атак хакеров/инсайдеров или же быть результатом действий вредоносных программ.

IPS это логическая эволюция IDS. Однако если IPS заблокировала хороший трафик, который, как она подозревала, был плохим (ложное срабатывание), или же физически вышла из строя, нарушив целостность сети, то важные бизнес-процессы компании нарушатся. Таким образом, специалисты по ИБ должны тщательно выбирать и развёртывать IPS с большой осторожностью.

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

В России требования к системам обнаружения вторжений (под понятием СОВ подразумеваются как пассивные IDS системы, так и активные IPS системы) появились еще в 2011 году, тогда ФСТЭК России поделила СОВ на 6 классов защиты. Отличия между классами заключаются в уровне информационных систем и непосредственно информации, которая подлежит обработке (персональные данные, конфиденциальная информация, государственная тайна). Соответствие требованиям регулятора является важным фактором при выборе СОВ, в то же время это положительно сказывается на развитии отечественного рынка IPS/IDS решений.

В пространстве IPS решений представлены продукты следующих производителей: Positive Technologies, Код Безопасности, Smart-Soft, Info Watch, Инфотекс, Stonesoft, Trend Micro, Fortinet, Cisco, HP, IBM, Juniper, McAfee, Sourcefire, Stonesoft, Trend Micro, Check Point, Palo Аlto Networks.

Межсетевые экраны нового поколения (NGFW)

Межсетевые экраны нового поколения (Next-Generation Firewall - NGFW) это эволюция типовых межсетевых экранов с возможностью отслеживания состояния соединений. Поскольку всё большее число компаний сейчас используют онлайн-приложения и службы SaaS, то классический контроль портов и протоколов уже недостаточен для обеспечения эффективной сетевой безопасности. В отличие от предыдущего поколения, в новых устройствах добавлена тесная интеграция дополнительных возможностей, таких как встроенная глубокая проверка пакетов (DPI), предотвращение вторжений (IPS) и проверка трафика на уровне приложений (Web Application Firewall). Некоторые NGFW также включают проверку зашифрованного трафика TLS/SSL, фильтрацию веб-сайтов, управление пропускной способностью, QoS, антивирусную проверку и интеграцию со сторонними системами управления идентификацией (LDAP, RADIUS и Active Directory). Решения NGFW в скором времени заменят традиционные межсетевые экраны, предотвращая вторжения и контролируя приложения как по периметру, так и внутри сети.

Производители NGFW решений: UserGate, Континент, Huawei, Check Point, Сisco, Fortinet, McAfee, Palo Alto Networks и Sourcefire.

Шлюзы информационной безопасности (SWG)

Прокси-серверы с функциями информационной безопасности (Security Web Gateway SWG), также известные как веб-фильтры это программно-аппаратные комплексы (ПО + сервер), разработанные и оптимизированные для соблюдения политик веб-безопасности компании и контроля доступа пользователей к веб-сайтам. Веб-сайты, которые содержат вредоносное ПО или неприемлемый контент (например, порнографию или азартные игры), блокируются на SWG, тем самым повышая производительность труда сотрудников, ограничивая ответственность компании и защищая компьютерные устройства пользователей от вреда.

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

Производители SWG решений: Ростелеком-Солар, Smart-Soft, UserGate, ESET, Kaspersky, Sophos, TRENDmicro, Huawei, Blue Coat, Cisco, McAfee, Trustwave и Websense.

Advanced malware protection (AMP)

Традиционные решения безопасности, такие как системы предотвращения вторжений, антивирусные продукты и шлюзы информационной безопасности предназначены для обнаружения известных угроз и эксплойтов, нацеленных на определённые уязвимости операционных систем и приложений. Однако сегодня уязвимости нулевого дня (Zero-Day Exploit - атаки, нацеленные на уязвимости, для которых ещё не разработана защита) вызывают наибольшую озабоченность компаний и правительственных учреждений.

Для защиты от этих угроз существует категория решений сетевой безопасности - AMP (Advanced Malware Protection). Основная задача AMP проверка файла, пересылаемого через сетевое устройство и/или записываемого на конечное оборудование, на наличие вредоносного кода. Система AMP осуществляет ретроспективный анализ и обеспечивает защиту не только до момента атаки или во время атаки, но и после того, как атака прошла. Кроме того, это решение позволяет отследить все пути распространения файла и может заблокировать файл на уровне сети.

Производители AMP решений: Kaspersky, Malwarebytes, Cisco, Damballa, FireEye и Palo Alto Networks.

Системы предотвращения утечки данных (DLP)

Системы предотвращения утечки данных (Data Loss Prevention или Data Leakage Prevention - DLP) это программно-аппаратные комплексы (ПО + сервер), которые предназначены для обнаружения и предотвращения потенциальных нарушений конфиденциальности данных и личной информации (номера кредитных карт, номера телефонов, данные паспорта и т. д.) путём мониторинга данных в нескольких состояниях:

  • при использовании (Data-inUse) на рабочем месте пользователя

  • при передаче (Data-inMotion) в сети компании

  • при хранении (Data-atRest) на серверах и рабочих станциях компании

Производители DLP решений: InfoWatch, Инфосистемы Джет, SmartLine Inc, Гарда Технологии, Zecurion, Ростелеком-Солар, Falcongaze, Атом Безопастность, ESET, SearchInform, CoSoSys, Blue Coat, Check Point, Cisco (IronPort), Fidelis, McAfee, RSA, Verdasys, Symantec, Websense.

Системы предотвращения распределённого отказа в обслуживании (DDoS Protection, Anti-DDoS)

Системы предотвращения распределённого отказа в обслуживании (Distributed Denial of Service (DDoS) Protection или Anti-DDoS) это специализированные программно-аппаратные и программные средства, предназначенные для защиты веб-серверов/сайтов компании от распределённых атак типа Отказ в обслуживании.

Атака типа отказ в обслуживании (DoS) - это попытка одного компьютера сделать другой компьютер недоступным для его предполагаемых пользователей путём забивания его полосы пропускания и/или вычислительных ресурсов паразитным трафиком, часто через поток пакетов SYN или ICMP. Распределённый отказ в обслуживании (DDoS) это DoS-атака, инициируемая ботнетом (совокупностью компьютеров, называемых ботами, которые заражены зомби-агентами или троянами), обычно используется для атак на целевые веб-сайты. Все боты в данном ботнете запрограммированы на выполнение действий в точно согласованное время, как это предписано центральной системой управления и контроля (Сommand and Сontrol - С&C), управляемой преступником.

На предприятиях системы Anti-DDoS помогают выявлять и предотвращать DDoS-атаки путём использования проприетарных алгоритмов и оценки механизмов защиты.

Средства безопасности в этой области производят компании: DDOS-GUARD, СТОРМ СИСТЕМС, Variti, Гарда Технологии, Kaspersky, Inoventica Technologies, Qrator Labs, Akamai Technologies, CloudFlare, Imperva, Sucuri, F5 Networks, Arbor Networks, Cisco, Corero и VeriSign.

Типичные проблемы развёртывания систем сетевой безопасности

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

Кейс 1 Развёртывание нескольких копий активных средств безопасности для обработки трафика в современных высоконагруженных сетях 40G/100G

В настоящее время широко распространяются стандарты 40G/100G. Производители активных средств безопасности стараются не отставать и предлагают высокопроизводительные инструменты для обеспечения защиты сетей данных стандартов. К сожалению, далеко не все предлагаемые современные инструменты могут обработать трафик высоконагруженных сетей стандартов 40G/100G. А те немногие, которые способны, имеют высокую стоимость и делают это с ограничениями.

Задача: Сеть компании построена по стандарту 40G. Существующая система NGFW имеет интерфейсы 40G, но её производительности хватает только при нагрузке в сети до 30%. При повышении нагрузки в сети установленная NGFW уже не справляется и начинает терять трафик. Необходимо внедрить решение, которое будет обеспечивать работоспособность сети с использованием существующей активной системы NGFW и минимально возможными инвестициями.

Решение: Для решения данной задачи необходимы: брокер сетевых пакетов и дополнительная единица NGFW (в некоторых случаях даже менее производительная). Существующую и вновь приобретённую NGFW нужно подключить к брокеру сетевых пакетов, который, в свою очередь, подключить через Bypass к сети компании. Пакетный брокер будет балансировать получаемый из cети трафик на входы NGFW с сохранением целостности сессий и агрегировать трафик с выходов NGFW для дальнейшей передачи. Таким образом, нагрузка будет равномерно распределяться на две системы NGFW, что позволит поддерживать необходимую пропускную способность и быстродействие сети компании.

Кейс 2 Безопасное развёртывание нескольких активных средств безопасности последовательно

Многие компании для достижения более глубокой защиты корпоративной сети последовательно развёртывают несколько активных средств безопасности. Таким образом, прежде чем трафик из интернета попадёт в корпоративную сеть, он должен пройти через системы IPS, Firewall, SWG и др. и получить разрешение на дальнейшее распространение по сети. Для минимизации рисков простоя сети компании нуждаются в эффективном и безопасном способе последовательного развёртывания активных средств ИБ.

Задача: В компании, в сетевой инфраструктуре которой развёрнута система межсетевого экрана, планируется внедрить активные системы IPS и Anti-DDoS. При этом необходимо обеспечить бесперебойность работы сети при выходе из строя средств ИБ.

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

Кейс 3 Поддержка отказоустойчивых сетевых конфигураций и активных систем информационной безопасности

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

Отказоустойчивые сетевые архитектуры требуют избыточных компонентов сетевой инфраструктуры и дополнительных единиц активных средств ИБ. Чтобы избыточность свести к минимуму и в то же время обеспечить максимальную отказоустойчивость, необходимо проектировать сеть с использованием брокера сетевых пакетов и Bypass.

Задача: В компании поставлена задача по организации отказоустойчивой конфигурации сети с активными средствами ИБ. Необходимо обеспечить бесперебойное функционирование системы ИБ в случае отказа группы систем и/или одного из элементов группы. Построенный сегмент активных средств ИБ не должен влиять на работоспособность общей сетевой инфраструктуры компании. Также требуется предусмотреть возможность дальнейшей масштабируемости и повышения производительности активных систем ИБ без изменения общей конфигурации сети.

Решение: Все требования поставленной задачи выполняются с помощью использования брокера сетевых пакетов и Bypass для подключения активных средств ИБ. Такое решение позволит уменьшить избыточность компонентов сетевой инфраструктуры, а также обеспечить более высокую отказоустойчивость системы. Брокер сетевых пакетов может эффективно маршрутизировать трафик как через каждый последовательно подключённый активный инструмент, так и через группу активных инструментов с балансировкой нагрузки. Балансировка нагрузки позволяет равномерно распределять трафик между отдельными инструментами безопасности, тем самым обеспечивая их оптимальную загрузку и повышая отказоустойчивость сети. Если какой-либо инструмент выходит из строя, то брокер сетевых пакетов исключает его из последовательности и балансирует нагрузку на оставшиеся рабочие средства безопасности. Использование Bypass в данном случае аналогично первому кейсу и, при выходе из строя брокера сетевых пакетов, позволит сохранить целостность сети путём исключения последнего из схемы соединения. Подключение активных средств безопасности через брокер сетевых пакетов также позволяет осуществлять дальнейшую масштабируемость и внедрение новых систем ИБ с минимальными затратами и простой реализацией.


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

Резюмируя, хочется выделить преимущества применения брокеров сетевых пакетов:

  • Простота интеграции, надёжность и отказоустойчивость сети

  • Масштабируемость активных средств контроля трафика без усложнения топологии сети

  • Постоянный мониторинг доступности каждого активного устройства ИБ и различные сценарии реагирования на аварии

  • Один Bypass для нескольких активных средств

  • Вариативность пропускания трафика через активные системы ИБ

  • Простота внедрения новых решений в инфраструктуру

Подробнее..

5 причин не уходить из техподдержки во внедрение

15.04.2021 18:16:38 | Автор: admin

Привет, Хабр! Несмотря на то, что информационная безопасность и все, что связано с этой сферой, сейчас на хайпе, найти инженера технической поддержки по ИБ задача непростая. Еще больше ее усложняет расхожее мнение, что техподдержка только для джунов, а более опытные специалисты должны переходить в проектную деятельность. Чтобы развенчать этот миф, подробнее расскажем о профессии и возможностях, которые она открывает.

В сервисном департаменте STEP LOGIC на двух линиях технической поддержки работает более 50 специалистов. Сейчас они обслуживают порядка 150 сервисных контрактов это более 10 тыс. инцидентов в год. Первая линия поддержки проводит классификацию обращений заказчиков и если проблему можно решить по скрипту, то закрывает заявку своими силами. Если сделать это в течение первого часа не удается или требуются дополнительные компетенции, то инцидент передается на вторую линию поддержки, инженеры которой обладают более глубокими техническими знаниями и навыками.

Как сервисные партнеры нескольких крупных вендоров, мы имеем право оказывать услуги по технической поддержке оборудования от их имени. Например, при обслуживании оборудования Cisco наши специалисты решают до 80-90% проблем самостоятельно, за помощью к вендору мы обращаемся только при гарантийной замене или обнаружении программных ошибок. Для того, чтобы вендор авторизовал партнера на предоставление совместных услуг, в штате обязательно должны быть сертифицированные инженеры, имеющие CCIE или, как минимум, CCNP. Еще два обязательных условия прохождение ежегодных аудитов на соответствие уровня услуг, требования к которым схожи с лучшими практиками ITIL, и принцип оказания технической поддержки, основанный на практиках Cisco CX Specialization.

Конечно, оптимальное решение для компаний, у которых есть локальная задача поддержки оборудования конкретного вендора, это покупка его стандартных пакетов обслуживания. У того же Cisco, например, есть варианты на разный вкус и кошелек: контракты Cisco SMARTnet или расширенная версия Solution Support, Next Calendar Day, если нужна замена оборудования в выходной или праздничный день, профессиональные услуги вендора Advanced Services (AS) и Business Critical Services (BCS), если заказчику необходим дизайн сети. Но бизнесу, в котором требования постоянно меняются, зачастую удобнее работать с компанией, которая будет жить в конкретной инфраструктуре, понимать, как она построена, в чем ее плюсы и минусы, узкие места и иметь опыт работы с технологиями разных производителей. Востребованы наши услуги и в системах высокой критичности, где нужен высокий SLA с фиксированным временем решения и круглосуточный сервис. Совместное оказание услуг часто удобно и самому производителю, так как он может не держать большой штат поддержки и сосредоточиться на основном бизнесе, не переживая при этом об уровне сервиса.

В локдаун значительно увеличилось число запросов на организацию и сопровождение VPN-каналов, Next Generation Firewall, SIEM-систем, расследование инцидентов безопасности, поэтому остро встал вопрос расширения команды инженеров по информационной безопасности на вторую линию поддержки.

Коротко портрет потенциального кандидата можно описать так: инженер, который более года работал в поддержке безопасности с оборудованием ведущих ИБ-вендоров и хорошо разбирается в сетевых технологиях.

График работы предлагаем стандартный 8 часов 5 дней в неделю. Иногда по отделу назначаются дежурства. Если ночью появилась критичная проблема, то дежурному придется подключиться и разобраться с ней. Но есть и небольшой плюс ехать никуда не нужно, специалисту выдается доступ в систему, с помощью которого он может работать удалено. Собственно, поэтому мы и не зацикливались на Москве или области, а сразу расширили зону поиска на всю Россию.

Почему возникли проблемы

  • Небольшое число подходящих специалистов. Забив перечисленные выше параметры на hh.ru, мы видим чуть более 70 человек, находящихся сейчас в поиске работы. Если бы мы искали сотрудника в московский офис, то ситуация была бы еще хуже. Для сравнения, при поиске бухгалтера сайт выдает более 1000 подходящих резюме.

  • Специалисты, имеющие релевантный опыт работы, не хотят идти в техническую поддержку. 30% соискателей отказались еще на этапе приглашения. Наиболее частая причина желание работать на стороне производителя или заниматься проектной деятельностью. В определенный момент мы даже решили несколько снизить планку по знаниям, но потом пришли к неутешительному выводу, что приходящие на собеседование кандидаты не могут объяснить, чем файрвол отличается от маршрутизатора.

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

5 причин обратить внимание на вакансию инженера технической поддержки

  1. Быстрый горизонтальный рост компетенций

    Минимальные начальные требования для кандидатов знание сетевых технологий, основ информационной безопасности, шифрования, принципов работы межсетевого экрана и системы предотвращения вторжений. Кроме стандартных файрволов и VPN, инженеры техподдержки работают с такими классами решений как Next Generation Firewall, SIEM, Web Application Firewall, DLP, IPS/IDS, Identity/AccessManagement, IRP/SOAR, Threat Intelligence. Это помогает развиваться не по одному направлению предметной деятельности, а более широко. Наши специалисты детально изучают оборудование ведущих ИБ-вендоров, тестируют в лаборатории его новые версии.

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

  2. Возможность стать экспертом, так как нужно "копать" глубоко

    Работа инженера внедрения заканчивается после ввода проекта в эксплуатацию. Как сотрудники техподдержки, мы можем с уверенностью заявить, что все самое интересное на этом только начинается. Техническая поддержка это не только консультации клиентов по вопросам функционирования оборудования, удаленная диагностика и настройка, решение проблем, локализация и мониторинг аварий, но и совместная работа с вендором по устранению багов, разработка планов по развитию и миграции инфраструктуры. Недавно мы приняли участие в проекте по миграции, который стал для нас своеобразным челленджем. Немного предыстории: крупный российский банк для защиты периметра продолжительное время использовал межсетевые экраны Cisco ASA. За последний год объем трафика увеличился в несколько раз, и оборудование перестало с ним справляться. Заказчик закупил межсетевые экраны нового поколения Cisco Firepower и перед ним встала задача провести максимально бесшовную замену, так как инфраструктура критическая и должна работать 24х7. Необходимо было перенести с одной ОС на другую большое количество настроек: сотни интерфейсов, тысячи правил межсетевого экранирования, сотню VPN и сделать это в короткое окно работ. Была проведена комплексная работа, включающая в себя изменение настроек маршрутизации, трансляции NAT, редистрибуции и фильтрации тысяч маршрутов, учитывающая переходные процессы с целью минимизации возможных потерь трафика.

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

  3. Развить командные навыки работы и soft skills

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

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

  4. Научиться работать с технической документацией

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

  5. Усовершенствовать технический английский

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

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

  • эксперта по классу решений или технологии

  • менеджера/сервис-менеджера/product owner по продукту или услуге

  • руководителя нового направления/услуги

Однако, если судить, по нашему опыту, в большинстве случаев в инженеры идут по призванию. Эту профессию редко меняют, предпочитая наращивать компетенции и развиваться в рамках своей специальности.

Таким образом, если работа с оборудованием и устранение неполадок приносит радость, среди soft skills присутствует пресловутая коммуникабельность и клиентоориентированность, имеется стойкое желание развить свои технические знания и стать экспертом в конкретной области ИТ, то у вас есть веский повод обратить внимание на вакансию инженера технической поддержки.

Подробнее..

Что сегодня есть у Huawei для построения цифровых беспроводных офисов

13.04.2021 16:13:10 | Автор: admin
В этом посте мы обрисуем современные тенденции в построении беспроводных кампусов, рассмотрим сценарии и реальные кейсы цифровой трансформации корпсетей, а также покажем, как двум специалистам обслуживать сеть на 25 тыс. абонентов, включающую в себя 20 тыс. сетевых устройств.



Ещё недавно при проектировании IT-инфраструктуры большого офиса или целого здания приходилось выбирать между высокоскоростными проводными сетями передачи данных и удобными гибкими беспроводными решениями, пропускная способность которых, однако, часто огорчала. Стоило собраться в одном конференц-зале нескольким десяткам человек со своими гаджетами, как сеть Wi-Fi из-за всплеска трафика становилась практически неработоспособной. Кто был на любой отраслевой офлайн-конференции, не даст соврать.

С появлением Wi-Fi 6 и софта для управления SDN эти неудобства уходят в прошлое. Короткое видео ниже наглядно показывает, какие возможности дают беспроводные кампусы нового поколения, на примере одного из китайских офисов Huawei.



Итак, реальная беспроводная сеть с непрерывным роумингом, включающая в себя 20 тыс. устройств и обслуживающая 25 тыс. абонентов, управляется всего двумя (!) инженерами. Развёрнута она на базе самых современных технических решений Huawei, о которых и пойдёт речь сегодня.



Основа цифровой трансформации 2.0


В процессах цифровой трансформации сеть становится элементом, связывающим между собой людей и IT-сервисы. В практическом плане мы говорим о гаджетах, находящихся на уровне edge (носимых терминалах, смартфонах, устройствах AR/VR, датчиках IoT и пр.) и множеством способов взаимодействующих между собой, а также с облаком или ЦОДом.



Умные рабочие места без проводов


За 2020 и начало 2021 года многие полностью перенесли свою профессиональную деятельность в онлайн. И без возможности качественной беспроводной передачи данных, не в последнюю очередь мультимедийных, современные кампусы бессмысленны.

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

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



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



CloudCampus 2.0


Обеспечивать бизнесу передовые сетевые сервисы, одновременно эффективно решая возникающие в больших корпоративных сетях проблемы, помогает современное ПО. В Huawei подобные продукты создаются на основе концепции CloudCampus 2.0.

CloudCampus 2.0 включает в себя систему управления и мониторинга сети, построенную на базе SDN-контроллера iMaster NCE. Он берёт на себя всю работу по поддержанию функционирования сети, начиная с Zero Touch Provisioning (ZTP) и заканчивая автоматическим анализом неисправностей. Система построена на базе алгоритмов искусственного интеллекта, что позволяет ей с высокой вероятностью предсказывать состояния сети и проактивно устранять потенциальные точки отказа.

Немаловажно и что iMaster NCE посредством Northbound interface (NBI) легко интегрируется с вышестоящими решениями, в том числе от других вендоров. Это могут быть системы управления активами, учётом рабочего времени, гибким производством, автоматизированным складским оборудованием и др. Таким образом, сеть превращается в сервис, способный интегрироваться в любой IT- или IoT-комплекс.

Возможности CloudCampus 2.0 делятся на три основные группы.

Благодаря iMaster NCE сеть может функционировать в режиме умной эксплуатации, позволяющем оптимизировать работу с опорой на прогнозную аналитику и обнаруживать до 85% неисправностей с помощью ИИ.

С помощью Умной связи сеть быстро настраивается из единой консоли. Применение современных проводных коммутаторов и беспроводных точек доступа WiFi 6 даёт возможность строить конвергентный доступ в сеть для IoT-устройств.

Наконец, третий пункт можно условно назвать суперёмкостью, так как этот комплекс возможностей подразумевает достижение пропускной способности на уровне 10,75 Гбит/с на одну точку доступа.



В конце марта Huawei представила CloudCampus 3.0 и целый ряд новых решений, которые оптимальны для внедрения при реализации этой концепции. Среди прочего пополнение в семействе точек доступа AirEngine Wi-Fi 6 и умный маршрутизатор NetEngine AR8140, которые показывает пропускную способность до 20 Гбит/с (SD-WAN). Скоро мы расскажем в нашем хабраблоге о CloudCampus 3.0 во всех подробностях.


Wi-Fi 6 для гибкого производства


Современные беспроводные сети всё шире применяются и в инновационных индустиях, где они могут быть интегрированы в роботизированные комплексы гибкого производства.

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

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



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

Даже при использовании не таких уж древних технологий Wi-Fi 5 для эксплуатации подобного робота требуется отдельная точка доступа. А ведь есть ещё и роботы, перемещающиеся по производственной площади и тоже подключаемые к локальной сети. Обеспечить их работу с помощью проводных решений часто невозможно в принципе.

Уже сейчас беспроводная связь предыдущего поколения зачастую не позволяет надёжно подключать необходимое количество автоматизированных устройств и пропускать требуемый каждому из них поток трафика. В то же время одна точка доступа Huawei с поддержкой WiFi 6, демонстрирующая минимальные задержки и способная передавать свыше 10 Гбит данных в секунду, в состоянии поддерживать работу более десятка роботов оптического контроля.



Настоящая действующая линия гибкого производства для производства смартфонов Huawei P40 уже развёрнута на одном из заводов нашей компании. Особенность линии то, с какой частотой вносятся изменения в рабочие процессы, а именно до нескольких раз в неделю. Это стало возможным лишь благодаря широкому внедрению роботизированных комплексов, умеющих быстро подстраиваться под меняющиеся требования. Все эти комплексы подключены к беспроводной сети на базе топовых точек доступа AirEngine 8760-X1-PRO.

Поток данных от видеокамер роботов в сторону ЦОДа обрабатывается с применением алгоритмов искусственного интеллекта, а те, в свою очередь, делают выводы относительно того, насколько качественно выполняются те или иные технологические процессы.



70 миллисекунд для VR и AR


Ещё один тренд, поднимающий требования к пропускной способности беспроводной сети, распространение технологий виртуальной и дополненной реальности, в том числе за пределами индустрии.

Важной точкой роста технологий VR/AR в ближайшее время станет обучение, благо дети прекрасно осваивают сложные технические решения. А значит, грядёт и резкий рост спроса на соответствующие устройства, которым также потребуются широкие каналы связи.

Вместе с тем очевидно, что контент для шлемов VR/AR будет размещаться на серверах в ЦОДах: централизация ресурсов целесообразна экономически. Это неизбежно вызовет повышение требований к пропускной способности сетей.



Чуть подробнее остановимся на сетевой задержке, критически важной для VR/AR. В приложениях, где пользователи интенсивно взаимодействуют со средой и друг с другом, она не должна превышать рекомендованного значения 70 мс. Причём примерно 20 мс необходимо терминальному устройству на обработку действия пользователя, ещё столько же на формирование нового изображения в ЦОДе. Получается, на передачу данных в обе стороны по проводным и беспроводным сетям остаётся не более 3040 мс. Это вполне достижимо, если проводная сеть правильно сконфигурирована и демонстрирует показатели, близкие к максимально возможным (10 мс), а беспроводная сеть построена на современных технологиях WiFi 6 (10 мс).



Wi-Fi 6 для операционных офисов


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



Новые офисы обходятся минимальным количеством операционистов, в то время как количество услуг, предоставляемых автоматизированными системами, растёт и растёт. Привычные банкоматы соседствуют с куда более функциональными умными терминалами STM (Smart Teller Machine). С их помощью можно получить любую услугу, будь то выдача пластиковой карты или оформление договора на открытие счёта. Эти устройства способны собирать биометрические данные и сканировать документы, позволяют получить консультацию удалённого специалиста в режиме видеоконференции и пр.

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

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



Вот кейс из жизни. Одна из крупнейших компаний на российском финансовом рынке совместно с Huawei реализовала проект корпоративного учебного заведения, совмещённого с современным офисом и расположенного в отдельном многоэтажном здании.

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

При непосредственном участии Huawei была построена проводная сеть, связавшая между собой новейшие точки доступа стандарта Wi-Fi 6. И на базе беспроводной инфраструктура была развёрнута система управления кондиционированием помещений, плюс ко всему с ней интегрировали налаженную ранее систему видеонаблюдения (в дополнение к последней удалось развернуть систему видеоаналитики, позволяющую автоматически управлять освещением в помещениях).

Управление всеми этими системами было объединено в рамках диспетчерской, отвечающей также за эксплуатацию здания, обеспечение пожарной безопасности и пр.



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

***


Узнать больше о Wi-Fi 6 и технологиях Huawei вам помогут наши многочисленные вебинары: вот их расписание на ближайшие месяцы.
Подробнее..

Northrop Grumman запустила на орбиту уже вторую сервисную станцию, которая оживляет спутники связи без топлива

13.04.2021 18:11:50 | Автор: admin

Космическая индустрия продолжает развиваться, это касается не только пусков ракет, о чем мы недавно писали, но и спутников, включая спутники связи. Впереди планеты всей компания Northrop Grumman со своими роботизированными сервисными станциями MEV.

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

В чем проблема со спутниками?



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

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

Большинство спутников, которые отправляются на космическое кладбище, вполне функциональны и могли бы работать еще много лет. Но выхода обычно нет: топливо заканчивается, а космических орбитальных АЗС пока нет.

Решение от Northrop Grumman


АЗС нет, но зато появились сервисные станции с автономным запасом топлива, которые способны передвигать спутники с орбиты на орбиту. Это относительно новое решение от Northrop Grumman, которая впервые опробовала его в прошлом году.

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

MEV-1

25 февраля 2020 года на околоземной орбите сервисная станция MEV-1 впервые состыковалась с телекоммуникационным спутником Intelsat 901. Она оснащена электрическими движками, специально спроектированным механическим захватом и визуальной системой наблюдения для корректировки стыковки. У станции есть и запас топлива для того, чтобы выполнять маневры автономно или вместе со спутником, который нужно возродить.


MEV-1 состыковалась с отработавшим свой срок космическим аппаратом Intelsat 901 как раз на кладбище. Он работал с 2001 по 2016 годы. Получается, спустя пять лет он вновь вернулся к работе и компания сможет эксплуатировать его еще пять лет. После завершения этого срока MEV-1 снова отбуксирует спутник на вечный покой.


MEV-2

Вторая станция была запущена из космодрома Куру во Французской Гвиане в августе 2020 года. На то, чтобы подняться до расчетной орбиты, у MEV-2 ушло полгода. Ее основной целью был 17-летний спутник связи IS-10-02. На тот момент он находился на геостационарной орбите. Как и у предыдущего пациента, у него закончилось топливо, необходимое для совершения маневров. Если бы не станция, его тоже пришлось бы отправить на космическое кладбище.

12 марта 2021 года станция начала стыковочный процесс с IS-10-02. Это довольно долго, ведь нужно не только выполнить сложную стыковку, но и проверить работу систем. По словам одного из представителей проекта, все прошло хорошо, и теперь спутник связи сможет проработать еще около 5 лет, прежде чем его выведут из эксплуатации.


Стоимость изготовления и запуска сервисной станции пока что неизвестна, но, похоже, она вполне устраивает клиентов компании. Во всяком случае, вице-президент Intelsat заявил о том, что контракт с Northrop это win-win.


Как и MEV-1, вторая станция после завершения пятилетнего периода работы со своим спутником выведет его на внешнюю орбиту, отстыкуется и отправится к новому пациенту.

Что дальше?



Сейчас компания Northrop разрабатывает усовершенствованную версию спутниковой сервисной станции, которая получила название Mission Robotic Vehicle (MRV). По сравнению с MEV, MRV гораздо более продвинутая система. Она будет устанавливать на спутниках модули первой помощи, которые станут выполнять те же задачи, что и MEV. Каждый MRV сможет нести на себе 6 модулей, так что один запуск MRV это 6 возвращенных к жизни спутников, спасенных от забвения.

Подробнее..

Гиперконвергентная система AERODISK vAIR v2. Часть 1. Система виртуализации АИСТ

14.04.2021 06:04:04 | Автор: admin


Всем привет. Этой статьей мы начинаем знакомить вас с новой версией российской гиперконвергентной системы AERODISK vAIR v2, в частности, со встроенным гипервизором АИСТ, который сейчас получил возможность работать автономно от vAIR, используя внешние СХД.


Изначально мы хотели рассказать о функциональности новой версии vAIR в одной статье, но материала получилось очень много, и мы встали перед выбором: либо сократить материал, либо разбить его на три части. Мы выбрали второй вариант и разбили материал следующим образом:


  • Управление кластером и гипервизор АИСТ
  • Файловая система ARDFS
  • Аппаратные платформы, лицензирование и поддержка

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


Коротко об архитектуре. Основные отличия между первой и второй версией


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


Описывать полностью архитектуру с нуля мы рамках этой статьи не будем. Коснёмся лишь тех отличий, которые существуют в настоящий момент между первой и второй версией. Для более глубокого знакомства с изначальной архитектурой vAIR v1 рекомендуем ознакомиться с нашими предыдущими статьями на эту тему:



На уровне большой картинки на данный момент архитектура vAIR v2 выглядит следующим образом:



Ну а теперь переходим к деталям.


Косметические изменения


Незаметное внешнему глазу, но при этом важное и трудоемкое событие произошло в распределенной базе конфигураций (ConfigDB), которая отвечает за одновременное хранение конфигураций всех компонентов решения на всех нодах кластера. Мы полностью её переработали и, соответственно, оптимизировали. В итоге ConfigDB стала значительно стабильнее и минимизировала пожирание бесценных аппаратных ресурсов. Если говорить о цифрах, то за счёт переработки полезную производительность решения удалось увеличить примерно на 30%, что, очевидно, хорошо.


Стандартный блок данных, которым оперирует ARDFS, изменился с 4МБ до 64 МБ. Сделано это было также с целью увеличения производительности ввода-вывода.


Ещё одним маленьким, но приятным бонусом, который получился в результате оптимизации ARDFS и ConfigDB, стало снижение минимальных системных требований по количеству нод в кластере. Первая версия vAIR требовала не менее четырех нод, во второй-же версии начинать можно с трёх нод. Мелочь, но тоже приятно.


АИСТ покинул гнездо


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


Для справки: и АИСТ, и vAIR как два отдельных продукта прошли всю необходимую экспертизу регуляторов и, соответственно, добавлены во всех необходимые гос. реестры Минцифры и Роспатента, чтобы по-честному считаться российским ПО.


Чтобы не было путаницы, поясним. По факту АИСТ и vAIR не являются разными продуктами. Гипервизор АИСТ это составная и обязательная часть гиперконвергентной системы vAIR, при этом АИСТ может использоваться в качестве самостоятельного решения, а также АИСТ может всегда быть обновлен до полноценного vAIR-а.


Данное архитектурное изменение не только позволяет импортозаместить зарубежную виртуализацию на российских предприятиях, но и открывает ряд крайне полезных сценариев использования vAIR. Разберем их:


Сценарий 1. Просто гиперконвергент


Тут все просто. АИСТ используется как составная часть vAIR и работает с хранилищем ARDFS. Это то, что было в первой версии, и остается сейчас.



Виртуальные машины, сеть и хранилище работают в рамках одной отказоустойчивой аппаратной платформы (3 ноды+).


Сценарий 2. Просто виртуализация


Классическая серверная виртуализация. На локальные диски физических серверов устанавливается АИСТ, к АИСТу пригоняются сторонние СХД по файловым или блочным протоколам, и на базе этих СХД хранятся виртуальные машины.



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


Сценарий 3. Гибридный сценарий


Самый интересный сценарий. Мы одновременно с гиперконвергентом используем в качестве хранилища виртуальных машин сторонние СХД (например ENGINE или ВОСТОК :-)). Полезным является то, что к любой виртуалке, которая хранится на ARDFS, мы можем легко прицепить дополнительные виртуальные диски с СХД. И наоборот, к любой виртуалке, которая лежит на СХД, мы можем прицепить виртуальные диски с ARDFS. Это открывает очень много возможностей, начиная с задач постепенной и бесшовной миграции инфраструктуры между разными хранилищами, заканчивая полезным использованием старых СХД и серверов хранения, которые и выкинуть жалко, и подарить некому.



В итоге, когда мы пишем vAIR, мы имеем ввиду большой продукт в целом гиперконвергентную систему, которая включает в себя гипервизор АИСТ и файловую систему ARDFS. А если мы пишем АИСТ, то имеем в виду только компонент, который отвечает за серверную виртуализацию и виртуальную сеть. Чтобы внести ещё больше ясности, приводим ниже таблицу с разбивкой функционала по компонентам.



Обзор функционала. Что нового и для чего


Функции управления


Управление системой осуществляется при помощи web-консоли на русском языке (поддерживаются любые браузеры) или командной строки. Важной и полезной плюшкой является то, что за счёт распределённого хранения конфигураций для осуществления управления всем кластером можно подключиться к любой ноде по IP или DNS-имени. Специальных серверов управления разворачивать не нужно. При этом это не запрещено.


Предусмотрен сценарий развертывания управляющей виртуальной машины (УВМ), которая через RestfulAPI может осуществлять полноценное управление всем кластером.


Кстати RestfulAPI, как понятно выше, есть, он описан и работает (по нему будет отдельная статья). Его спокойно можно использовать для автоматизации операций и интеграции со смежными системами. К примеру, уже сейчас есть интеграция (и, кстати, есть внедрение в продуктив) с российским VDI-решением Термидеск, как раз реализованная на базе нашего API. Плюс ещё несколько продуктов вендоров-партнеров на подходе.


Для управления виртуальными машинами изнутри гостевой ОС используется на выбор два протокола: VNC (по умолчанию) или Spice. На уровне отдельных ВМ администратор может задавать разные варианты подключений.



Сам интерфейс разбит на несколько логических частей.


1) Основная область управления, в которой выполняются почти все операции



2) Основное меню, которое выдвигается наведением курсора



3) Панель действий, на которой отображаются доступные для выбранного объекта действия.



4) Панель задач, которая показывает, какие задачи выполняются или были выполнены над выбранным объектом, вызывается выбором объекта и последующим кликом по кнопке задачи.



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



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



Лирическое отступление: когда я эту функцию показал моему старому товарищу, который является тру-админом (то есть он админил системы в те славные времена, когда систем ещё не существовало) он воскликнул:
Вы нормальные там??!!! Нельзя админить серьезные системы через мобилу!!!
Хочу отметить, что во втором своём высказывании он, безусловно прав, лазить по серьезным кластерам через мобилку опасно, можно ткнуть не туда и всё как обычно упадёт, но всегда есть НО
Я напомнил ему ситуацию, в которую он попал несколько лет назад, когда потратил примерно 40 минут времени и 10 тонн мата на то, чтобы перезагрузить пару зависших виртуалок на известном гипервизоре, используя свой смартфон. Ноутбука у него с собой не было, а его заказчик с паром из ушей требовал устранить проблему здесь и сейчас.
Вспомнив об этом случае, мой товарищ тру-админ перестал сомневаться в нашей нормальности :-).

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


Гипервизор АИСТ


Не секрет, что в основе АИСТа лежит старый добрый KVM с libvirt-овой обвязкой. При этом наша реализация очень сильно доработана. Про годный веб-интерфейс, который управляет не только виртуализацией, но и сетью с хранилищем и который доступен, как с любой ноды, так и с управляющей ВМ, мы писали выше. Но это далеко не все доработки. Вот ещё несколько крайне достойных функций, которых в штатном KVM-е нет.


Отказоустойчивость виртуальных машин (HAVM) реализована классическим и понятным образом. Она может быть активна или неактивна для каждой виртуалки, а включается на этапе создания ВМ или в процессе её редактирования.



Если параметр HAVM активен, то в случае отказа ноды кластера, ВМ автоматически перезапуститься на другой ноде.


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



Для защиты данных на уровне ВМ, а также для большей гибкости администрирования предусмотрены мгновенные снимки и клоны (которые можно превратить в шаблоны ВМ соответственно). Важной доработкой и одновременно крайне большой радостью является то, что снэпшоты делаются на горячую (при работающей ВМ) и полностью поддерживают консистентность файловых систем гостевых ОС (Linux, Solaris, Windows, BSD) и ряда поддерживаемых СУБД (пока только PostgreSQL и MySQL). При этом с помощью RestfulAPI никто не мешает реализовать консистентные снимки для других систем внутри гостевой ОС самостоятельно.


Для внешнего хранения из коробки поддерживается NFS, то есть хранить виртуалки можно на распределенном хранилище ARDFS (доступно в vAIR) или на внешней СХД по протоколу NFS. Опционально предусмотрена поддержка блочных внешних СХД по протоколам iSCSI и FC.


Миграция виртуальных машин со сторонних гипервизоров


Миграция, причем неважно откуда и куда, всегда стоит особняком во всей ИТ-жизни. За время полутора лет эксплуатации нашими заказчиками первой версии vAIR они (и мы автоматически) регулярно сталкивались с проблемами миграции виртуальных машин со сторонних гипервизоров в АИСТ. Штатный конвертер KVM штука хорошая, но крайне капризная. Поэтому в vAIR v2 (и в АИСТе соответственно) мы предусмотрели человеческий конвертер ВМ из VMware/Hyper-V прямо в интерфейсе vAIR/АИСТ.



Для конвертации администратор выбирает шару NFS (пока только NFS), где лежат файлы виртуальных машин VMware или Hyper-V. Далее vAIR сам сканирует шару на наличие нужных ему файлов и формирует доступный список для миграции. Далее выбираем целевой пул ARDFS (или внешнюю СХД), то есть куда будем конвертировать, выбираем нужные файлы ВМ (можно несколько, они будут конвертироваться по очереди) запускаем и идём пить пиво.



Когда пиво выпито, новые, уже сконвертированные, виртуалки ждут нас уже внутри vAIR-а в выключенном состоянии.


Мониторинг и логирование


Функции мониторинга реализованы как локально, так и удаленно. Администратор может работать со счетчиками утилизации ресурсов CPU, RAM, сетевых интерфейсов и подсистемой ввода-вывода (IOPS, MB/s, latency), как на уровне отдельных нод, так и на уровне кластера в целом.



Всё то же самое доступно и для удаленной системы мониторинга на базе Grafana.



Для логирования и алертинга предусмотрен журнал событий (ноды, порты, физические диски (SMARTCTL), сенсоры, температура и т.п.) с разбивкой по категориям и возможностью оповещения по электронной почте. Опционально поддерживается SNMP.




Кроме описанных выше возможностей гипервизор АИСТ позволяет выполнять функционал, который мы считаем must have, поэтому сильно его разрисовывать не будем, а просто перечислим:


  • Обновление ПО без остановки и миграции виртуальных машин
  • Живая миграция ВМ, а в ближайшем будущем с возможностью динамичного распределения ресурсов (а-ля DRS)
  • Распределённые виртуальные коммутаторы с поддержкой VLAN-ов
  • Расширение кластера без остановки виртуальных машин
  • Автоподдержка (автоматическое оповещение производителя и заведение тикетов в тех. поддержку, при согласии заказчика, само собой)
  • Метрокластер (отдельная большая функция, которой мы посветим позже отдельную статью)

Детально ознакомиться с особенностями функционала можно в технической документации, которая есть у нас на сайте:


https://aerodisk.ru/upload/Datasheet_AIST_final_11042021.pdf


В завершение первой части


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


На подобные утверждения мы всегда задавали вопрос.


А эти компании сразу появились на свет с тысячей бородатых разрабов в толстых свитерах?

ИЛИ другой вариант


А вы когда родились вам сразу было 35 лет, у вас была машина, семья, дача, работа и образование? Это в комплекте вам врачи в роддоме выдавали?

В продолжении этой мысли позволим себе процитировать нашу же старую статью:


притча на эту тему.


Однажды странник попал в город, где шло грандиозное строительство. Мужчины ворочали большие камни под палящим солнцем. Что ты делаешь? спросил наш герой у одного из рабочих, который медленно тащил булыжник. Ты что, не видишь камни таскаю! зло ответил тот. Тут странник заметил другого рабочего, который волок телегу с большими камнями, и спросил: Что ты делаешь? Я зарабатываю на еду для своей семьи, получил он ответ. Странник подошел к третьему рабочему, который занимался тем же, но работал энергичнее и быстрее. Что делаешь ты? Я строю храм, улыбнулся тот.

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


В жизни это совсем не так. Практически всегда (за редким исключением), новый серьезный продукт создается небольшим коллективом до 10 человек (а обычно 2-3). При этом на этапе создания закладывается 80% всего функционала продукта. Далее продукт силами этого маленького коллектива выходит на рынок (или как-то еще громко заявляет о себе), и там его уже подхватывают инвесторы (фонды, холдинги или крупные производители).


Таким образом мы в свое время большую цель увидели и в большую идею поверили и время показало, что мы не ошиблись.


На этом мы завершаем первую часть цикла статей про vAIR v2. В следующей статье подробно расскажем о функционале файловой системы ARDFS.


Также в ближайшее время мы планируем организовать очередной вебинар ОколоИТ, где в прямом эфире поговорим про vAIR и все что его окружает. Тем вебинара есть несколько, от выбора темы зависит, кого мы позовём на вебинар. Поэтому мы хотим право выбора темы отдать в руки ИТ-сообщества и по этой причине запускаем голосование по темам следующего ОколоИТ.


Голосование доступно тут, на Хабре, а также в нашем телеграм-чате https://t.me/aerodisk


Всем спасибо за внимание, как обычно ждем конструктивной критики и интересных вопросов.

Подробнее..

Сам сломаю, сам и починю как я эпически нажал не туда на проде

14.04.2021 10:21:24 | Автор: admin
Привет, Хабр!

Про такие ошибки обычно говорить не принято, потому что во всех интеграторах работают только безгрешные небесноликие люди. У нас, как известно, на уровне ДНК отсутствует возможность ошибаться или быть неправыми.

Но я рискну. Надеюсь, мой опыт кому-то будет полезен. Есть у нас один крупный заказчик, онлайн-розница, которому мы полностью поддерживаем фабрику Cisco ACI. Своего админа, компетентного по этой системе, у компании нет. Сетевая фабрика это группа коммутаторов, которая имеет единый центр управления. Плюс ещё куча полезных фич, которыми очень гордится производитель, но в итоге, чтобы всё уронить, нужен один админ, а не десятки. И один центр управления, а не десятки консолей.

Начинается история так: заказчик хочет перенести на эту группу коммутаторов ядро всей сети. Такое решение обусловлено тем, что архитектура ACI, в которую собрана эта группа коммутаторов очень отказоустойчивая. Хотя это не типично и в целом фабрика в любом ЦОД не используется как транзитная сеть для других сетей и служит только для подключения конечной нагрузки (stub network). Но такой подход вполне имеет место быть, поэтому заказчик хочет мы делаем.

Дальше произошло банальное я перепутал две кнопки: удаления политики и удаления конфига фрагмента сети:

image

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

По порядку


Запрос заказчика звучал так: нужно было построить отдельные порт-группы под перенос оборудования непосредственно на эту фабрику.
Коллеги, просьба перенести настройки портов Leaf 1-1 101 и leaf 1-2 102, порты 43 и 44, на Leaf 1-3 103 и leaf 1-4 104, порты 43 и 44. К портам 43 и 44 на Leaf 1-1 и 1-2 подключён стек 3650, он пока не введён в эксплуатацию, переносить настройки портов можно в любое время.

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

Проблема в том, что на фабрике настройки этих порт-групп привязаны к отдельной сущности (которая возникает вследствие того, что фабрика управляется с контроллера). Этот объект называется port policy. То есть к группе портов, которые мы добавляем, нужно ещё сверху применить общую политику как сущность, которая будет управлять этими портами.
То есть нужно было сделать анализ, какие EPG используются на портах 43 и 44 на нодах 101 и 102 для того, чтобы собрать аналогичную конфигурацию на нодах 103-104. После анализа необходимых изменений я начал настраивать ноды 103-104. Для настройки нового VPC в существующей политике интерфейсов для нод 103 и 104 нужно было создать политику, в которую будут заведены интерфейсы 43 и 44.

И там есть в GUI один нюанс. Я создал эту политику и понял, что в процессе конфигурирования допустил незначительную ошибку, назвал её не так, как принято у заказчика. Это не критично потому что политика новая и ни на что не влияет. И мне эту политику нужно было удалить, поскольку изменения в неё уже внести нельзя (название не меняется) можно только удалить и заново политику создать.

Проблема в том, что в GUI есть иконки удаления, которые относятся к политикам интерфейса, а есть иконки, которые относятся к политикам коммутатора. Визуально они почти идентичны. И я вместо того, чтобы удалить политику, которую я создал, удалил всю конфигурацию для интерфейсов на коммутаторах 103-104:

image

Вместо удаления одной группы фактически удалил все VPC из настроек ноды, использовал delete вместо trashbin.

В этих каналах были VLAN, чувствительные для бизнеса. По сути дела, после удаления конфига я отключил часть сетки. Причём это было не сразу заметно, потому что фабрика управляется не через ядро, а у неё отдельный менеджмент-интерфейс. Меня не выкинуло сразу, не произошло какой-то ошибки на фабрике, поскольку действие было предпринято администратором. И интерфейс считает ну если вы сказали удалить, значит так надо. Никакой индикации ошибок не было. ПО решило, что идёт какая-то реконфигурация. Если админ удаляет профиль leaf, то для фабрики он перестаёт существовать и она не пишет ошибки о том, что он не работает. Он не работает потому что его целенаправленно удалили. Для ПО он и не должен работать.

В общем, ПО решило, что я Чак Норрис и точно знаю, что делаю. Всё под контролем. Админ не может ошибаться, и даже когда он стреляет себе в ногу это часть хитрого плана.

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

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

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

Восстановление фабрики


На восстановление фабрики с учётом всех звонков и сбора всех причастных ушло 30 минут.

Нашли другой VPN, через который можно зайти (это потребовало согласования с безопасниками), и я откатил конфигурацию фабрики в Cisco ACI это делается в два клика. Ничего сложного нет. Просто выбирается точка восстановления. Занимает это 1015 секунд. То есть на само восстановление ушло 15 секунд. Всё остальное время было потрачено на то, чтобы понять, как получить удалённое управление.

image

После инцидента


Ещё день мы разбирали логи и восстанавливали цепочку событий. Потом собрали звонок с заказчиком, спокойно изложили суть и причины инцидента, предложили ряд мер, чтобы свести к минимуму риски подобных ситуаций и человеческого фактора.
Договорились, что конфиги фабрики мы трогаем только в нерабочие часы: ночное и вечернее время. Проводим работы обязательно с дублирующим удалённым подключением (есть рабочие VPN-каналы, есть резервные). Заказчик получает от нас предупреждение и в это время наблюдает за сервисами.

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

Так же мы покопались глубже в ПО Cisco Network Assurance Engine (NAE), где нашли возможность сделать на фабрике ACI две простые, но очень важные вещи:

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

Если интересно больше деталей у нас завтра вебинар про внутреннюю кухню техподдержки, будем рассказывать, как всё устроено у нас и у вендоров. Ошибки тоже будем разбирать)
Подробнее..

Производительность RemoteFX, часть 1

14.04.2021 14:22:42 | Автор: admin

О технологии RemoteFX от Майкрософт, которая повышает качество работы в режиме удалённого рабочего стола, известно давно. В интернете хватает материалов, демонстрирующих её эффективность. Но большинство оценок носят качественный характер: "вот играем в %game_name%, fps в норме", "вот запустили 3D софт, как будто локально работает! Скриншот здесь, видео там".

В данном исследовании мы разберёмся, как перейти от "попугаев" к конкретным метрикам, чтобы количественно оценить эффективность технологии и объективно сравнить её использование с обычным режимом RDP.

Содержание
  • Кратко о RemoteFX

  • Конфигурация тестовой среды

    • Сервер

    • Клиент

  • Выбор показателей для измерений

  • Методика тестирования

    • Тест #1: ввод текста

    • Тест #2: ввод текста + 3D BenchMark

    • Тест #3: ввод текста + просмотр локальных видеофайлов

    • Тест #4: ввод текста + просмотр youtube-ролика

  • Обработка данных и построение графиков

  • Анализ результатов и наиболее интересные графики

    • Задержки при обработке ввода от пользователя

    • Частота кадров

    • Общие сетевые метрики

    • Загрузка центрального процессора

    • Загрузка видеокарты

  • Выводы

  • Что дальше

  • Список источников

  • Приложения

    • Переопределение групп сбора данных: _1_task_define.cmd

    • Принудительная остановка записи данных: _1_task_breake.cmd

    • Конвертация двоичных данных в CSV: blg2csv.cmd

    • Нормализация заголовков CSV: blg2csv.ps1

    • Jupiter Notebook: импорт данных

    • Jupiter Notebook: отрисовка одной метрики на диаграмму

    • Jupiter Notebook: отрисовка всех метрик на одной диаграмме

    • Диаграмма со всеми графиками

Кратко о RemoteFX

Традиционный RDP работает так, чтобы как можно больше работы по отрисовке окна удалённого рабочего стола переложить на клиента: по сети передаются графические примитивы и инструкции, которые должна выполнить клиентская видеокарта. Такой подход, в случае показа видео или использования интерфейса Windows Aero, требует поддержки со стороны клиента. Иначе вместо Aero будет использована упрощённая схема, а обработанный CPU сервера видеопоток передан клиенту в виде растровой графики, производительность отрисовки при этом может оказаться просто неприемлемой. Поэтому приходилось выбирать: либо использовать традиционный RDP только в связке с достаточно производительным клиентским железом, либо отказываться от сложной графики.

При включении RemoteFX клиенту по сети по прежнему передаются растровые кадры. Но есть два существенных отличия от традиционного RDP. Во-первых, вся подготовка и обработка графики перекладывается на GPU сервера, это происходит намного быстрее и разгружает CPU. А во-вторых, используется сжатие кадра, которое выполняет кодек RemoteFX. Это существенно снижает объём передаваемых по сети данных, тем самым разгружая канал связи. Это существенно снижает требования к клиентскому железу, но сохраняет достаточный уровень отрисовки и отзывчивости удалённого рабочего стола.

Конфигурация тестовой среды

Сервер

  • 2 vCPU Intel(R) Xeon(R) CPU E5-2696 v4 @ 2.20GHz

  • 8 GB RAM

  • GPU NVIDIA GRID M60-1Qб, Dedicated Memory 929 MB, Shared Memory 4095 MB

  • гостевая ОС Windows Server 2019 Standart x64 1809 (Version 10.0.17763.1577), DirectX 12

  • network in/out rate limit 50 Mbps

Клиент

  • Intel(R) Core(TM) i5-7600K CPU @ 3.80GHz, 3801 МГц, ядер: 4, логических процессоров: 4

  • 16 GB RAM

  • network in/out rate limit 100 Mbps

  • OS Windows 10 Pro 2004 (Version 10.0.19041.685), DirectX 12

  • настройки RDP-сеанса

    • 1920 x 1080 (32 bit) (32Hz)

    • на вкладке "Взаимодействие" выбрано "Локальная сеть (10 Мбит/с и выше)"

Выбор показателей для измерений

Качество и производительность удалённого рабочего стола нужно оценить с точки зрения как пользователя, так и потребления облачных ресурсов. Будем собирать данные о частоте кадров отрисовки, задержках отклика на ввод данных, сетевом трафике и загрузке CPU/GPU/RAM. Метрики выбраны с учётом официальныхрекомендаций по диагностике.

Замеры выполним с помощью стандартного средстваСистемный монитор. Для этого на каждый тест определим свой сборщик данных, который в течении двух минут будет каждую секунду фиксировать в двоичном blg-файле журнала показания счётчиков:

Показания
  • \Графика RemoteFX(*)\Качество кадра

  • \Графика RemoteFX(*)\Исходящих кадров в секунду

  • \Графика RemoteFX(*)\Входящих кадров в секунду

  • \Графика RemoteFX(*)\Среднее время кодирования

  • \Графика RemoteFX(*)\Коэффициент сжатия графических данных

  • \Графика RemoteFX(*)\Пропущено кадров в секунду у сервера недостаточно ресурсов

  • \Графика RemoteFX(*)\Пропущено кадров в секунду недостаточно сетевых ресурсов

  • \Графика RemoteFX(*)\Пропущено кадров в секунду у клиента недостаточно ресурсов

  • \Задержка ввода данных пользователем на сеанс(Max)\Максимальная задержка ввода

  • \Сведения о процессоре(_Total)\% загруженности процессора

  • \NVIDIA GPU(*)\% Video Decoder Usage

  • \NVIDIA GPU(*)\% Video Encoder Usage

  • \NVIDIA GPU(*)\% GPU Memory Usage

  • \NVIDIA GPU(*)\% GPU Usage

  • \NVIDIA GPU(*)\% FB Usage

  • \Сеть RemoteFX(*)\Потери

  • \Сеть RemoteFX(*)\Общая скорость отправки

  • \Сеть RemoteFX(*)\Общая скорость приема

  • \Сеть RemoteFX(*)\Скорость отправки TCP-данных

  • \Сеть RemoteFX(*)\Скорость отправки UDP-данных

  • \Сеть RemoteFX(*)\Общая скорость приема

  • \Сеть RemoteFX(*)\Скорость получения TCP-данных

  • \Сеть RemoteFX(*)\Скорость получения UDP-данных

  • \Сеть RemoteFX(*)\Пропускная способность текущего TCP-подключения

  • \Сеть RemoteFX(*)\Пропускная способность текущего UDP-подключения

  • \Память\% использования выделенной памяти

  • \Память\Доступно байт

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

Методика тестирования

Чтобы оценить эффективность использования выделенной видеокарты на облачным сервере, нужно провести две серии одинаковых тестов: до и после включения отрисовки удалённого рабочего стола на GPU.

В каждой серии выполним следующие тесты:

  1. ввод текста

  2. ввод текста + 3D BenchMark

  3. ввод текста + просмотр локальных видеофайлов

  4. ввод текста + просмотр youtube-ролика

Для оценки влияния теста на задержку обработки ввода от пользователя поверх основной программы открывается стандартныйБлокноти зажимается произвольная клавиша. Окно редактора на протяжении теста будет постоянной частью всех кадров, поэтому исказит результат в лучшую сторону. Чтобы снизить эффект, размер окна уменьшим до 122*156% 99% кадра будут меняться и визуально будет видно, что имитация активности пользователя работает.

Тест #1: ввод текста

В качестве тестоврекомендуется"использовать любые приложения, которые плотно работают с графикой (например, потоковое видео), приложения, использующие DirectX". Результаты первого теста, с точки зрения пользователя (частота кадров и задержка ввода), практически одинаковые. Поэтому строить графики и анализировать их нет особого смысла. Такой тест больше пригодится для диагностики RemoteFX.

Тест #2: ввод текста + 3D BenchMark

Выполнялся при помощи FurMark в полноэкранном режиме.

Тест #3: ввод текста + просмотр локальных видеофайлов

Локальные видеофайлы воспроизводились в Windows Media Player, равёрнутом на весь экран, без установки каких-либо дополнительных кодеков, по кругу в следущем порядке:

  1. "Ants carrying dead spider": 1920 x 1080, 10667 кбит/с, 19 секунд, 29.97 fps

  2. "Flying Through Forest 1": 1920 x 1088, 48072 кбит/с, 9 секунд, 25 fps

  3. "Low Angle Of Pedestrians Walking In Busy Street, Daytime": 4096 x 2160, 31721 кбит/с, 13 секунд, 25 fps

Единственным критерием отбора была динамичность ролика: видеоряд должен был как можно сильнее нагрузить кодек RemoteFX. Но ролик "Flying Through Forest 1" оказался в этом плане интересной находкой: выходной FPS заметно проседал, а входной от запуска к запуску был сильно выше или ниже среднего! Его влияние на различные метрики будет заметно на графиках, которые будут ниже.

Тест #4: ввод текста + просмотр youtube-ролика

В качестве youtube-теста был выбран чудесный ролик "Коста-Рика", который проигрывался в качестве1080p60в браузере Firefox, режим "киоск".

Обработка данных и построение графиков

Файлы журналов -blg- имеют двоичный формат: легко открываются в родной программе, графики всех счётчиков на одной шкале, можно выключать/включать/масштабировать/etc. Но чтобы работать с данными из нескольких файлов, нужно другое решение.

Сначалаконвертируем двоичные файлы в csv (см. Приложение)с помощью стандартной утилитыreglogиочистим их заголовки (см. Приложение).

Затем вJupiter-блокноте при помощи библиотекpandasиmatplotlibпрочитаемcsv (см. Приложение, Jupiter Notebook: импорт) ипостроимграфики (см. Приложение, Jupiter Notebook: одна метрика одна диаграмма).

Анализ результатов и наиболее интересные графики

Задержки при обработке ввода от пользователя

До включения групповых политик сильнее всего на обработке ввода сказалось проигрывание локальных видеофайлов: в среднем 45 мс при рекомендованных 33 мс.

Включение отрисовки через GPU в групповых политиках стабилизировало этот показатель во всех сценариях.

Частота кадров

После включения GPU ускорения ситуация явно становится лучше, особенно в 3D тесте. Результаты двух других тестов хоть и демонстрируют улучшение, но недостаточно: провалы на графиках соответствуют визуальным "рывкам" при просмотре.

Воспроизведение"Flying Through Forest 1"(1920 x 1088, 48072 кбит/с, 9 секунд, 25 fps): от запуска к запуску на вход кодека RеmoteFX поступало либо повышенное либо пониженное количество кадров. Возможно, причина в перекодировке из формата QuickTime, "лишних" 8 пикселях ширины кадра или битрейте.

"Коста-Рика"также вызвал "проседание" FPS у RemoteFX: его проигрывание в браузере в1080p60ложилось на центральный процессор. Возможно, он просто не успевал перекодировать из 60fps и подготовить нужный кадр для RemoteFX.

Общие сетевые метрики

При включении GPU ускорения происходит рост сетевого трафика, который зависит от сценария теста.

Видно, что самым тяжёлым для кодека RemoteFX опять оказался тот же самый видеофайл,"Flying Through Forest 1". Первый запуск этого теста, когда наблюдается провал входящих кадров, также видим скачки трафика до 60 Мбит/с и потери до 30% - 40%.

Загрузка центрального процессора

Включение GPU ускорения практически вдвое разгружает центральный процессор, за исключением youtube-теста. И даже здесь удалось уйти от периодической 100% загрузки.

Загрузка видеокарты

Возможно, разгадка странного поведения второго ролика кроется в графике 17: входящих для RemoteFX кадров было больше, когда видеокарта была больше загружена кодированием.

Выводы

В RDP протоколе частота кадров ограничена 30-ю кадрами в секунду. Со стороны сервера увеличить лимит FPSможно, но бессмысленно: на практике терминальная сессия перестала отрисовывать окно и реагировать на действия как раз при проигрывании"того самого"видеофайла :).

Итоги в цифрах:

  1. Частота кадров стабилизируется почти на максимально возможном для протокола уровне: 29-30 FPS в среднем вместо 25 или даже 15 FPS

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

  3. Заметно, на 20-50 %, разгружается центральный процессор

  4. Немного возрастает утилизация канала связи, на 3-6 Мбит/сек

  5. Утилизация GPU составила до 20%

Результат действительно очень хороший: RemoteFX значительно увеличивает качество работы в терминальной сессии плавность отрисовки окна и отклик на действия пользователя сравнимы с локальным режимом. Даже "тяжёлые" сценарии показывают в этом плане заметный прирост.

Тесты, конечно, носят искусственный характер: выбором способа нагрузки на кодек RemoteFX можно как "завалить" так и "подтянуть" его результаты. Возможно, более релевантным было бы проведение чего-то вроде "конфетти-теста",например, такого.

Что дальше

Так как на этом этапе тесты проводились для одной сессии и при включении лишь рекомендованных настроек, то далее имеет смысл протестировать производительность:

  • при одновременной работе нескольких пользователей

  • при включении в групповых политиках различных дополнительных настроек кодека

Список источников

Приложения

Переопределение групп сбора данных: _1_task_define.cmd
@echo offsetlocal EnableDelayedExpansion@REM для сбора используются счётчики, перечисленные в _1_counters.cfg@REM счётчики называются только на английском, на русском это просто описание@REM @REM запуск сбора данных:@REM    при каждом входе на удалённый рабочий стол исправить _1_counters.cfg:@REM    1)  посмотреть номер своей терминальной сессии консольной командой@REM        query session@REM    @REM    2)  вписать этот номер в _1_counters.cfg, например, RDP-Tcp 9@REM    @REM    3)  перерегистрировать сброщик запуском данного файла@REM @REM    4)  замер производительности производится запуском _2_task_run_X.cmd и длится 2 минуты@REM @REM удаление старого сборщика данныхlogman delete -n RemoteFX_1logman delete -n RemoteFX_2logman delete -n RemoteFX_3logman delete -n RemoteFX_4logman delete -n RemoteFX_5for /F "usebackq delims= " %%a IN (`query session ^| find "Administrator"`) DO (    set "x=%%a"    set "x=!x:~9,10!"    echo !x!    type NUL>_1_counters.cfg    echo ^\NVIDIA GPU^(^*^)^\%% Video Decoder Usage>>_1_counters.cfg    echo ^\NVIDIA GPU^(^*^)^\%% Video Encoder Usage>>_1_counters.cfg    echo ^\NVIDIA GPU^(^*^)^\%% GPU Memory Usage>>_1_counters.cfg    echo ^\NVIDIA GPU^(^*^)^\%% GPU Usage>>_1_counters.cfg    echo.>>_1_counters.cfg    echo ^\Processor Information^(_Total^)^\%% Processor Time>>_1_counters.cfg    echo.>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\Loss Rate>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\Current TCP Bandwidth>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\Current UDP Bandwidth>>_1_counters.cfg    echo.>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\Total Sent Rate>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\TCP Sent Rate>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\UDP Sent Rate>>_1_counters.cfg    echo.>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\Total Received Rate>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\TCP Received Rate>>_1_counters.cfg    echo ^\RemoteFX Network^(RDP-Tcp !x!^)^\UDP Received Rate>>_1_counters.cfg    echo.>>_1_counters.cfg    echo ^\RemoteFX Graphics^(^*^)^\Output Frames/Second>>_1_counters.cfg    echo ^\RemoteFX Graphics^(^*^)^\Input Frames/Second>>_1_counters.cfg    echo.>>_1_counters.cfg    echo ^\RemoteFX Graphics^(^*^)^\Frames Skipped/Second - Insufficient Server Resources>>_1_counters.cfg    echo ^\RemoteFX Graphics^(^*^)^\Frames Skipped/Second - Insufficient Network Resources>>_1_counters.cfg    echo ^\RemoteFX Graphics^(^*^)^\Frames Skipped/Second - Insufficient Client Resources>>_1_counters.cfg    echo ^\RemoteFX Graphics^(^*^)^\Frame Quality>>_1_counters.cfg    echo ^\RemoteFX Graphics^(^*^)^\Average Encoding Time>>_1_counters.cfg    echo ^\User Input Delay per Session^(Max^)^\Max Input Delay>>_1_counters.cfg    echo.>>_1_counters.cfg    echo ^\RemoteFX Graphics^(^*^)^\Graphics Compression ratio>>_1_counters.cfg    echo ^\NVIDIA GPU^(^*^)^\%% FB Usage>>_1_counters.cfg    @REM счётчик памяти не работает, сброс кэша счётчиков также не помог    @REM    https://docs.microsoft.com/ru-ru/troubleshoot/windows-server/performance/manually-rebuild-performance-counters    echo ^\Memory^\%% Committed Bytes In Use>>_1_counters.cfg    echo ^\Memory^\Available Bytes>>_1_counters.cfg)@REM и регистрация нового сборщикаlogman create counter -n RemoteFX_1 -f bin -max 10 -si 00:00:01 -rf 00:02:00 --v -o "%~dp0logs\test #1 void GPO X" -cf "%~dp0_1_counters.cfg"logman create counter -n RemoteFX_2 -f bin -max 10 -si 00:00:01 -rf 00:02:00 --v -o "%~dp0logs\test #2 3D GPO X" -cf "%~dp0_1_counters.cfg"logman create counter -n RemoteFX_3 -f bin -max 10 -si 00:00:01 -rf 00:02:00 --v -o "%~dp0logs\test #3 wmp GPO X" -cf "%~dp0_1_counters.cfg"logman create counter -n RemoteFX_4 -f bin -max 10 -si 00:00:01 -rf 00:02:00 --v -o "%~dp0logs\test #4 youtube GPO X" -cf "%~dp0_1_counters.cfg"logman create counter -n RemoteFX_5 -f bin -max 10 -si 00:00:01 -rf 00:02:00 --v -o "%~dp0logs\test #5 webGL GPO X" -cf "%~dp0_1_counters.cfg"@REM pause@REM exit
Принудительная остановка записи данных: _1_task_breake.cmd
@REM запускаем сбор данныхlogman stop RemoteFX_1logman stop RemoteFX_2logman stop RemoteFX_3logman stop RemoteFX_4logman stop RemoteFX_5
Конвертация двоичных данных в CSV: blg2csv.cmd
@echo off@REM смена кодировки нужна для powershell-скрипта "%~dpn0.ps1"chcp 65001@REM работаем в текущей папке скриптаcd "%~dp0logs"@REM включаем расширения для переопределения переменных в циклеsetlocal EnableDelayedExpansion@REM цикл по двоичным файлам мониторингаFOR /F "usebackq delims=." %%a IN (`dir *.blg /b`) DO (    set "blg=%%a.blg"    set "csv=%%a.csv"    @REM convert binary to csv    relog "!blg!" -f csv -o "!csv!" -y)@REM имена cmd и powershell скриптов должны совпадатьstart "%~dpn0.ps1" /WAIT /B pwsh.exe -Command "& {%~dpn0.ps1 -en:$False}"@REM справка reglog - утилиты работы с журналами производительности@REM https://docs.microsoft.com/ru-ru/windows-server/administration/windows-commands/relog
Нормализация заголовков CSV: blg2csv.ps1

Заголовки столбцов содержат различные уникальные данные (id терминальной сессии или оборудования), которые будут несовпадать из-за применения групповых политик и выхода-входа на терминальный сервер. Приводим к единому виду с помощью PowerShell-скрипта:

[CmdletBinding()]param (    [switch] $en       = $False  # substitute ru alias of counters by real en name)$WorkDir = $MyInvocation.MyCommand.Definition | Split-Path -Parent$LogsDir = Join-Path -Path $WorkDir -ChildPath 'logs'$EncodeFrom = [System.Text.Encoding]::GetEncoding(1251)$EncodeTo = New-Object System.Text.UTF8Encoding $False$names = @(    New-Object psobject -Property @{ 'ru' = 'Задержка ввода данных пользователем на сеанс(Max)\Максимальная задержка ввода' ; 'en' = 'User Input Delay per Session\Max Input Delay'}    New-Object psobject -Property @{ 'ru' = 'Графика RemoteFX\Входящих кадров в секунду' ; 'en' = 'RemoteFX Graphics\Input Frames/Second'}    New-Object psobject -Property @{ 'ru' = 'Графика RemoteFX\Исходящих кадров в секунду' ; 'en' = 'RemoteFX Graphics\Output Frames/Second'}    New-Object psobject -Property @{ 'ru' = 'Графика RemoteFX\Среднее время кодирования' ; 'en' = 'RemoteFX Graphics\Average Encoding Time'}    New-Object psobject -Property @{ 'ru' = 'Графика RemoteFX\Качество кадра' ; 'en' = 'RemoteFX Graphics\Frame Quality'}    New-Object psobject -Property @{ 'ru' = 'Графика RemoteFX\Коэффициент сжатия графических данных' ; 'en' = 'RemoteFX Graphics\Graphics Compression ratio'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Общая скорость отправки' ; 'en' = 'RemoteFX Network\Total Sent Rate'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Общая скорость приема' ; 'en' = 'RemoteFX Network\Total Received Rate'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Потери' ; 'en' = 'RemoteFX Network\Loss Rate'}    New-Object psobject -Property @{ 'ru' = 'Графика RemoteFX\Пропущено кадров в секунду  недостаточно сетевых ресурсов' ; 'en' = 'RemoteFX Graphics\Frames Skipped/Second - Insufficient Network Resources'}    New-Object psobject -Property @{ 'ru' = 'Графика RemoteFX\Пропущено кадров в секунду  у сервера недостаточно ресурсов' ; 'en' = 'RemoteFX Graphics\Frames Skipped/Second - Insufficient Server Resources'}    New-Object psobject -Property @{ 'ru' = 'Графика RemoteFX\Пропущено кадров в секунду  у клиента недостаточно ресурсов' ; 'en' = 'RemoteFX Graphics\Frames Skipped/Second - Insufficient Client Resources'}    New-Object psobject -Property @{ 'ru' = 'Сведения о процессоре(_Total)\% загруженности процессора' ; 'en' = 'Processor Information(_Total)\% Processor Time'}    New-Object psobject -Property @{ 'ru' = 'NVIDIA GPU\% GPU Usage' ; 'en' = 'NVIDIA GPU\% GPU Usage'}    New-Object psobject -Property @{ 'ru' = 'NVIDIA GPU\% GPU Memory Usage' ; 'en' = 'NVIDIA GPU\% GPU Memory Usage'}    New-Object psobject -Property @{ 'ru' = 'NVIDIA GPU\% Video Decoder Usage' ; 'en' = 'NVIDIA GPU\% Video Decoder Usage'}    New-Object psobject -Property @{ 'ru' = 'NVIDIA GPU\% Video Encoder Usage' ; 'en' = 'NVIDIA GPU\% Video Encoder Usage'}    New-Object psobject -Property @{ 'ru' = 'NVIDIA GPU\% FB Usage' ; 'en' = 'NVIDIA GPU\% FB Usage'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Пропускная способность текущего UDP-подключения' ; 'en' = 'RemoteFX Network\Current UDP Bandwidth'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Пропускная способность текущего TCP-подключения' ; 'en' = 'RemoteFX Network\Current TCP Bandwidth'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Скорость отправки UDP-данных' ; 'en' = 'RemoteFX Network\UDP Sent Rate'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Скорость получения UDP-данных' ; 'en' = 'RemoteFX Network\UDP Received Rate'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Скорость отправки TCP-данных' ; 'en' = 'RemoteFX Network\TCP Sent Rate'}    New-Object psobject -Property @{ 'ru' = 'Сеть RemoteFX\Скорость получения TCP-данных' ; 'en' = 'RemoteFX Network\TCP Received Rate'})$Heads = @()foreach ($f in Get-ChildItem -Path $LogsDir -File -Filter '*.csv'){    $FileContent = $f | Get-Content -Encoding $EncodeFrom    $HeadOrig = $FileContent[0]    # приводим заголовки к единому виду, убираем ненужное    # "\\TESTGPU\NVIDIA GPU(#0 GRID M60-1Q (id=1, NVAPI ID=513))\% GPU Memory Usage"    if ($HeadOrig -match '.*(?<hostname>\\\\[a-zA-Z0-9]*\\).*')    {        $HeadOrig = $HeadOrig.Replace($Matches['hostname'], '')    }    if ($HeadOrig -match '.*NVIDIA GPU(?<gpu>\(#[A-Z0-9 ]*-[A-Z0-9]* \(id=[0-9,]* NVAPI ID=[0-9]*\)\))')    {        $HeadOrig = $HeadOrig.Replace($Matches['gpu'], '')    }    # "\\TESTGPU\Графика RemoteFX(RDP-Tcp 55)\Входящих кадров в секунду"    if ($HeadOrig -match '.*(?<session>\(RDP-Tcp[ 0-9]*\)).*')    {        $HeadOrig = $HeadOrig.Replace($Matches['session'], '')    }    # "(PDH-CSV 4.0) (Russia TZ 2 Standard Time)(-180)"    if ($HeadOrig -match '.*(?<time>\(.*\) \(.*Time\)\([0-9 +-]*\))')    {        $HeadOrig = $HeadOrig.Replace($Matches['time'], 'Time')    }    if ($en)    {        $HeadOrig = ($HeadOrig -split '","') -replace '"', ''        foreach ($h in $HeadOrig)        {            if ($h -notin $names.ru) { continue }            $n = $names | Where-Object {$_.ru -eq $h}            $HeadOrig[($HeadOrig.IndexOf($h))] = $n.en  # $h = $n.en не работает        }        $HeadOrig = '"{0}"' -f ($HeadOrig -join '","')    }    $FileContent[0] = $HeadOrig  # перезапись заголовка    $FileContent | Out-File -Encoding $EncodeTo -FilePath $f.FullName    $Heads += $f.Name + $HeadOrig  # сохранение заголовка}# вывод заголовков столбцов в отдельный файл для доп. контроля порядка, названий и т.д.$Heads | Out-File -Encoding $EncodeTo -FilePath (Join-Path -Path $LogsDir -ChildPath 'heads.txt')
Jupiter Notebook: импорт данных
import pandas as pdimport matplotlib.pyplot as pltfrom matplotlib.ticker import EngFormatter  # для вывода форматированных единиц измеренияplt.rcParams['figure.max_open_warning'] = 30  # порог предупреждения при одновременном построении нескольких рисунков%matplotlib inline# импорт данных csv-файловt21 = pd.read_csv('./logs/test #2 3D GPO 1.csv', na_values=' ')t20 = pd.read_csv('./logs/test #2 3D GPO 0.csv', na_values=' ')  # , encoding='cp1251')t31 = pd.read_csv('./logs/test #3 wmp GPO 1.csv', na_values=' ')t30 = pd.read_csv('./logs/test #3 wmp GPO 0.csv', na_values=' ')t31_prev = pd.read_csv('./logs/test #3 wmp GPO 1 anomaly.csv', na_values=' ')t41 = pd.read_csv('./logs/test #4 youtube GPO 1.csv', na_values=' ')t40 = pd.read_csv('./logs/test #4 youtube GPO 0.csv', na_values=' ')# слияние результатов каждого теста: сначала рекомендованные GPO, потом default GPOt2 = pd.concat([t21, t20],           join='inner', axis=1)t3 = pd.concat([t31, t30, t31_prev], join='inner', axis=1)t4 = pd.concat([t41, t40],           join='inner', axis=1)# разные наборы для итерации и рисования в циклеdataframes = [t2, t3, t4]ax_titles = ['test #2: 3D benchmark', 'test #3: play 1080p video', 'test #4: play 1080p youtube video']legend = ['GPU acceleration', 'default', 'GPU, anomaly']img_sx, img_sy = 15, 5  # размеры одного ряда графиковfgs = [  # макет графиков  # yunit ед. изм., ylabel метка Y-оси, ydata колонка из датафрейма    {'yunit': 'ms',     'ylabel': 'Input Delay',            'ydata': 'Задержка ввода данных пользователем на сеанс(Max)\Максимальная задержка ввода'},    {'yunit': 'fps',    'ylabel': 'RemoteFX input FPS',     'ydata': 'Графика RemoteFX\Входящих кадров в секунду'},    {'yunit': 'fps',    'ylabel': 'RemoteFX output FPS',    'ydata': 'Графика RemoteFX\Исходящих кадров в секунду'},    {'yunit': 'bps',    'ylabel': 'Tx Speed',               'ydata': 'Сеть RemoteFX\Общая скорость отправки'},    {'yunit': 'bps',    'ylabel': 'Rx Speed',               'ydata': 'Сеть RemoteFX\Общая скорость приема'},    {'yunit': '%',      'ylabel': 'Tx / Rx Loss',           'ydata': 'Сеть RemoteFX\Потери'},    {'yunit': '%',      'ylabel': 'CPU Usage',              'ydata': 'Сведения о процессоре(_Total)\% загруженности процессора'},    {'yunit': '%',      'ylabel': 'GPU Usage',              'ydata': 'NVIDIA GPU\% GPU Usage'},    {'yunit': '%',      'ylabel': 'GPU Memory Usage',       'ydata': 'NVIDIA GPU\% GPU Memory Usage'},    {'yunit': '%',      'ylabel': 'GPU Decoder Usage',      'ydata': 'NVIDIA GPU\% Video Decoder Usage'},    {'yunit': '%',      'ylabel': 'GPU Encoder Usage',      'ydata': 'NVIDIA GPU\% Video Encoder Usage'},    {'yunit': 'ms',     'ylabel': 'Encoding Time',          'ydata': 'Графика RemoteFX\Среднее время кодирования'},    {'yunit': '%',      'ylabel': 'Frame Quality',          'ydata': 'Графика RemoteFX\Качество кадра'},    {'yunit': '%',      'ylabel': 'Compression: enc byte / in byte', 'ydata': 'Графика RemoteFX\Коэффициент сжатия графических данных'},    {'yunit': 'fps',    'ylabel': 'FPS Loss by network',    'ydata': 'Графика RemoteFX\Пропущено кадров в секунду  недостаточно сетевых ресурсов'},    {'yunit': 'fps',    'ylabel': 'FPS Loss by server',     'ydata': 'Графика RemoteFX\Пропущено кадров в секунду  у сервера недостаточно ресурсов'},    {'yunit': 'fps',    'ylabel': 'FPS Loss by client',     'ydata': 'Графика RemoteFX\Пропущено кадров в секунду  у клиента недостаточно ресурсов'},    {'yunit': '%',      'ylabel': 'GPU Framebufer Usage',   'ydata': 'NVIDIA GPU\% FB Usage'},    {'yunit': 'bps',    'ylabel': 'Tx Speed UDP',           'ydata': 'Сеть RemoteFX\Скорость отправки UDP-данных'},    {'yunit': 'bps',    'ylabel': 'Rx Speed UDP',           'ydata': 'Сеть RemoteFX\Скорость получения UDP-данных'},    {'yscale': 1000,    'yunit': 'bps', 'ylabel': 'Bandwidth UDP', 'ydata': 'Сеть RemoteFX\Пропускная способность текущего UDP-подключения'},    {'yunit': 'bps',    'ylabel': 'Tx Speed TCP',           'ydata': 'Сеть RemoteFX\Скорость отправки TCP-данных'},    {'yunit': 'bps',    'ylabel': 'Rx Speed TCP',           'ydata': 'Сеть RemoteFX\Скорость получения TCP-данных'},    {'yscale': 1000,    'yunit': 'bps', 'ylabel': 'Bandwidth TCP', 'ydata': 'Сеть RemoteFX\Пропускная способность текущего TCP-подключения'},]
Jupiter Notebook: отрисовка одной метрики на диаграмму
for i in range(len(fgs)):  # сколько метрик, столько рисунков (рядов диаграмм)    fig, axs = plt.subplots(1, 3, figsize=(img_sx, img_sy), sharex='col', sharey='row', gridspec_kw=dict(hspace=0, wspace=0, ))  # width_ratios=[1, 1, 1]    fig_name = fgs[i]['ydata'].split('\\')[1]    fig.suptitle(f'Рис. {i + 1:>2}. {fig_name}', fontsize=14)  #, color='grey')  # имя рисунка    fig.patch.set_facecolor('white')  # фон рисунка белый вместо прозрачного    axs[0].set(ylabel=fgs[i]['ylabel'])  # подпись Y-оси только на первых (левых) графиках из трёх    axs[2].yaxis.set_tick_params(labelleft=False, labelright=True, which='major')  # дублируем значения справа    for ax, d, title in zip(axs, dataframes, ax_titles):  # на каждый тест своя диаграмма        ax.plot(d.index.values, d[fgs[i]['ydata']] * (fgs[i].get('yscale', 1)))  # строим график        ax.set_title(title)  #, color='grey')  # заголовок диаграммы                ax.xaxis.set_tick_params(which='major', labelcolor='grey')  # подписи к X-шкале        ax.xaxis.set_major_formatter(EngFormatter(unit='s'))  # по X секунды        ax.yaxis.set_tick_params(which='major', labelcolor='grey')  # подписи Y-шкале        ax.yaxis.set_major_formatter(EngFormatter(unit=fgs[i]['yunit']))  # по Y у каждого графика своя ед. изм.        # расчёт средних и вывод в легенду диаграммы "на лету"        avg = [EngFormatter(places=0).format_eng(avg * (fgs[i].get('yscale', 1))) for avg in d[fgs[i]['ydata']].mean()]        lgn = [f'avg {m}{fgs[i]["yunit"]}, {l}' for l, m in zip(legend, avg)]        ax.legend(lgn, fontsize=8)  # отображение легенды графика        ax.grid(axis='y')  # горизонтальная сетка        ax.set_xlim(0,119)  # метка "120" засоряла график        if ax == axs[1]:  # выделяем аномалии на средней диаграмме            ax.axvline(x=15, linestyle=":", color='C0')            ax.axvline(x=58, linestyle=":", color='C0')            ax.axvline(x=101, linestyle=":", color='C0')        fig.tight_layout()  # (pad=0.4, w_pad=1.5, h_pad=30.0)
Jupiter Notebook: отрисовка всех метрик на одной диаграмме

Общая ось X на все графики: метрики тестов располагаются строго друг под другом - удобно сопоставлять разные метрики между собой.

# один рисунок  # plt.style.available  # plt.style.use('seaborn-whitegrid')fig, axs = plt.subplots(len(fgs), 3, figsize=(img_sx, img_sy * len(fgs)), sharex='col', sharey='row', gridspec_kw=dict(hspace=0.2, wspace=0))fig.patch.set_facecolor('white')  # фон рисунка белый вместо прозрачного# заголовки только вверху[ax.set_title(title) for ax, title in zip(axs[0], ax_titles)]  # ax.set_title(title, color='grey')for i in range(len(fgs)):    axs[i,0].set(ylabel=fgs[i]['ylabel'])    fig_name = fgs[i]['ydata'].split('\\')[1]    axs[i,1].set(xlabel=f'Рис. {i + 1:>02}. {fig_name}')    # axs[i,1].xaxis.label.set_color('grey')    axs[i,2].yaxis.set_tick_params(labelleft=False, labelright=True, which='major')    for ax, d, title in zip(axs[i], dataframes, ax_titles):        ax.plot(d.index.values, d[fgs[i]['ydata']] * (fgs[i].get('yscale', 1)))        ax.xaxis.set_tick_params(which='major', labelcolor='grey')  # подписи к X-шкале        ax.xaxis.set_major_formatter(EngFormatter(unit='s'))  # по X секунды        ax.yaxis.set_tick_params(which='major', labelcolor='grey')  # подписи Y-шкале        ax.yaxis.set_major_formatter(EngFormatter(unit=fgs[i]['yunit']))  # по Y у каждого графика своя ед. изм.        # расчёт средних и изменение легенды диаграммы "на лету"        avg = [EngFormatter(places=0).format_eng(avg * (fgs[i].get('yscale', 1))) for avg in d[fgs[i]['ydata']].mean()]        lgn = [f'avg {m}{fgs[i]["yunit"]}, {l}' for l, m in zip(legend, avg)]        ax.legend(lgn, fontsize=8)  # отображение легенды графика        ax.grid(axis='y')  # горизонтальная сетка        ax.set_xlim(0,119)  # метка "120" засоряла график        if ax == axs[i,1]:  # выделяем аномалии на средней диаграмме            ax.axvline(x=15, linestyle="--", color='C0')            ax.axvline(x=58, linestyle="--", color='C0')            ax.axvline(x=101, linestyle="--", color='C0')
Диаграмма со всеми графиками

Продолжение истории будет на следующей неделе. Спасибо за внимание!


Что ещё интересного есть в блогеCloud4Y

Частые ошибки в настройках Nginx, из-за которых веб-сервер становится уязвимым

Пароль как крестраж: ещё один способ защитить свои учётные данные

Тим Бернерс-Ли предлагает хранить персональные данные в подах

Подготовка шаблона vApp тестовой среды VMware vCenter + ESXi

Создание группы доступности AlwaysON на основе кластера Failover

Подписывайтесь на нашTelegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.

Подробнее..

Сюда Разработка Подлинная Java как работает AliExpress после переноса разработки в Россию

14.04.2021 16:05:26 | Автор: admin


Привет, Хабр! Меня зовут Анатолий Орлов, и я технический директор AliExpress Россия. Сервис доступен русскоязычным пользователям уже 11 лет, при этом офис компании в Москве открылся только пять лет назад, а локальная команда разработки появилась лишь в прошлом году. Ее главная задача адаптировать площадку, изначально заточенную на китайский лад, к реалиям Рунета и сделать ее понятнее и проще для русскоязычных пользователей.

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

Зачем вообще переносили разработку


Решение о переносе разработки в Россию было принято после создания совместного предприятия (СП), в котором приняли участие Alibaba, Mail.Ru Group, Мегафон и РФПИ. Сделано это было для того, чтобы развивать площадку в сфере электронной коммерции по правилам и законам российского рынка и для удобства российских пользователей и селлеров.



Это я

В последние годы русскоязычная часть AliExpress интенсивно развивалась и требовала больше ресурсов и фокуса. При этом российский бизнес для Alibaba Group в целом это слишком маленький сегмент в сравнении с любым китайским сервисом компании, так что получить ресурсы для проведения изменений было очень сложно. Когда разработка русскоязычной платформы не находится в России, то проекту нужно ждать своей очереди на ресурсы разработки. А учитывая, что очередь приоретизируется по объему рынка, пользователям Рунета приходилось ждать улучшений продолжительное время. Если же инженеры работали бы в России и постоянно занимались именно российским AliExpress, понимая, как делать продукт, востребованный здесь, это открыло бы больше простора для развития.

После создания СП ситуация сдвинулась в эту сторону, мы активно начали наращивать техническую команду. Так, если в январе 2020-го нас было около 40 человек, то в январе 2021 года число инженеров выросло почти до 400. Что же делают все эти люди?

Адаптация глобального сервиса под рунет


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

Инфраструктура AliExpress изначально не была рассчитана на то, что в будущем могут появиться проекты в разных странах, которые будут развиваться по правилам локального рынка и силами местных специалистов. Код писался китайскими разработчиками, с использованием удобных им инструментов, в том числе внутренних технологий Alibaba, которые трудно применять вне Китая. Например, может быть отличная технология с документацией только на китайском языке и требующая логина из двух иероглифов, чтобы начать с ней работу.



Фото: Олег Лозовой / РБК

Несмотря на то что одним из главных языков программирования во всей экосистеме является Java, почти всё окружение и инструменты проприетарны. Довольно часто встречаются форки популярных известных открытых решений, но в общем объеме инфраструктуры их не так много. Часто такие системы сильно допилены и имеют мало общего с исходным проектом. Например, у Alibaba есть чудесная технология MaxCompute, которая внешне почти неотличима от hadoop и, видимо, когда-то была форкнута от hadoop, но размеры кластеров, находящихся под ее управлением, таковы, что у разработчиков hadoop глаз бы задергался от зависти.

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

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

В китайской культуре принят непрямой feedback. Это когда собеседнику напрямую не указывают на недочеты в его работе, да еще и публично чтобы не расстроить и не унизить, а осторожно намекают. С пониманием обычно не возникает трудностей. К примеру, слово suggest (по-русски предлагать) для китайцев имеет другое значение. Если такое предложение исходит от руководителя следует воспринимать это как приказ, который нужно исполнить. В случае когда что-то изменить предлагает коллега из другой команды это означает довольно настойчивую просьбу.

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

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



Смена стека технологий, замена поискового движка, промо локальных продавцов

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

Часто вместо Java мы используем Kotlin, пишем отдельные сервисы на Go и .Net, применяем Kubernetes, GitLab, k8s, Prometheus, Grafana, Opsgenie и т. п.

При этом многие проекты Alibaba Group останутся в стеке, потому что они хорошие и/или нужные. Например, источником знаний о товарах кросс-бордера (то есть, которые можно купить у зарубежных поставщиков) всегда будет система Alibaba; мы можем написать свою, но заставить перейти туда 100 млн китайских селлеров будет довольно тяжело.

Одно из первых изменений: мы занялись заменой китайского движка поиска. Сейчас он отнюдь не всегда применим для русских запросов, например в некоторых местах поисковый запрос обрезается до 30 символов при этом посередине слова. На первый взгляд какой-то ужас, но для китайского движка это довольно логично, ведь там нет пробелов, а запросы длиной 30 символов (т. е. иероглифов) не встречаются в реальной жизни. На самом деле, поправить эту особенность несложно, но, когда дефектов много, более надёжным подходом будет сделать свой движок поиска. При всем этом технологически поисковая платформа Alibaba близка к state of art.

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



Фото: Олег Лозовой / РБК

Алгоритмы machine learning Alibaba заточены под продвижение товаров с наибольшим объёмом продаж, и закономерно возникает проблема курицы и яйца: российский сегмент платформы здесь не может конкурировать с Китаем, а в итоге местные продавцы не получают достаточных позиций в поиске. После ряда неудачных попыток и экспериментов нам удалось повысить позиции российских товаров, но система всё еще далека от идеала, мы будем её улучшать.

В итоге российская инженерная команда взяла на себя развитие сайта aliexpress.ru, российского мобильного приложения, и вскоре в сферу ее ответственности войдут и все остальные аспекты вроде программы лояльности.

Что дальше: полностью свой поиск, еще больше трафика локальным товарам, багфиксинг


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

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

Очевидно, что некоторые части системы AliExpress полностью локализовать не удастся никогда, но мы хотим добиться состояния, при котором для пользователя и селлера платформа будет максимально удобна, без ограничений. Мы будем активно этим заниматься и рассказывать о своем опыте в блоге на Хабре. Так что подписывайтесь и пишите в комментариях, о чем нам рассказать в следующих статьях.
Подробнее..

Обогащение данных что это и почему без него никак

15.04.2021 06:04:33 | Автор: admin

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

Сам термин "обогащение данных" это перевод англоязычного Data enrichment, который проводит аналогию между данными и... ураном. Точно так же, как промышленники насыщают урановую руду, увеличивая долю изотопа 235U, чтобы её можно было использовать (хочется надеяться, в мирных целях), в процессе обогащения данных мы насыщаем их информацией.

Обогащение данных это процесс дополнения сырых данных той информацией, которая в исходном виде в них отсутствует, но необходима для качественного анализа.

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

Заметим, что обогащение данных термин широкий, и получать данные из внешних источников можно весьма разнообразными способами. Например, представим бизнес-процесс регистрации нового клиента. Если в данных этого клиента отсутствует e-mail, то взаимодействие с внешним источником в этом случае может быть буквально следующим: взяли телефон, позвонили клиенту, узнали его e-mail. Получается, этот процесс может включать в себя такие совершенно не автоматизированные операции, как обычный телефонный разговор со всеми этими эс как доллар, "а" как русская. Это тоже можно считать обогащением данных, но данный пласт проблем в этой статье мы затрагивать не будем. Нас интересуют вполне конкретные случаи, когда данные хранятся в базе данных и именно БД служит внешним источником данных для обогащения.

Источниками сырых исходных данных могут быть:

  • Система кассовых платежей, которая отслеживает транзакции и отправляет в хранилище данных: время, id торговой точки, количество и стоимость купленного товара и т.д.

  • Логистическая система, которая отслеживает движение товара: id транспорта и его водителя, gps-координаты в заданные моменты времени, статус, маршрут и т.д.

  • Телеметрия с датчиков интернета вещей.

  • Система мониторинга инфраструктуры.

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

Таким образом, типовую задачу можно сформулировать следующим образом: на вход поступают данные вида <таймстамп, идентификатор источника, содержимое пакета>, а конечному потребителю требуется соединить (в смысле join) справочную информацию об источнике из хранилища данных с идентификатором источника из сырых данных.

Как обогащаем данные

Один из вариантов решения задачи сопоставления данных по расписанию запускать скрипты, которые подготовят подходящие для аналитиков представления. Например, это можно делать с помощью Apache Airflow. Но в любом случае потребуется ждать и сохранять данные из внешних источников.

Другой вариант использовать инструменты потоковой обработки данных. В этом случае нужно определиться, где же всё-таки хранить справочную информацию и что будет являться Single Source of Truth (SSOT), или единым источником истины для справочных данных. Если хранить справочные данные в хранилище, то к нему придется каждый раз обращаться, и это может быть накладным, так как к сетевым издержкам добавится ещё и обращение к диску. Вероятно, оптимальнее хранить справочную информацию в оперативной памяти или другом горячем хранилище, например, в Tarantool.

Мы, очевидно, отдаём предпочтению именно последнему варианту, и наша схема приобретает завершенный вид.

Она отличается от первой иллюстрации процесса обогащения данных тем, что появилась конкретика: процесс обогащения происходит на лету с помощью потокового обработчика, справочные данные хранятся в горячем хранилище (оперативной памяти).

Давайте посмотрим, какие плюсы и минусы мы получим, если возьмем за основу данную схему.

Преимущества потокового обогащения данных:

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

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

Недостатки:

  • Источник истины для справочной информации вынесен из надёжного дискового хранилища данных в менее надёжную оперативную память. При сбое это грозит потерей всех несинхронизированных данных.

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

Какие технологии используем

Что касается технологий, то мы выбираем более-менее устоявшиеся на рынке решения с открытым исходным кодом и хорошей документацией, учитывая совместимость.

Выбранный стек технологий:

  • Apache Kafka источник данных и брокер очередей;

  • Apache Spark потоковый обработчик данных;

  • Apache Ignite горячее хранение справочной информации;

  • Greenplum и Apache Hadoop хранилище данных.

В выборе Greenplum мы немного поступились совместимостью. Связать его со Spark не совсем тривиальная задача, для этого не существует стандартного open source коннектора (подробнее рассказывали в этой статье). Поэтому мы разрабатываем такой коннектор сами.

В остальном набор достаточно стандартный. Hadoop держим на всякий случай, например, чтобы использовать тот же Hive поверх HDFS вместо Greenplum.

Каждое из этих решений масштабируемо. Поэтому мы можем построить любую архитектуру, в зависимости от объемов справочной информации и ожидаемой пропускной способности.

Итак, вот окончательные очертания нашей схемы обогащения данных.

Версии, которые используем:

  • Apache Spark 2.4.6.

  • Apache Ignite 2.8.1.

  • Apache Kafka 2.4.1.

  • Greenplum 6.9.0.

  • Apache Hadoop 2.10.1.

Обращаю на это внимание, потому что от версий выбранных компонент зависит совместимость и возможность этих компонент взаимодействовать. Например, если нужно, чтобы Apache Spark писал данные в базу данных Greenplum, это может стать отдельной проблемой, и версии также будут важны. Наш коннектор на текущий момент работает именно со Spark v2, для Spark v3 его нужно отдельно дорабатывать.

Что в результате

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

Но есть и ограничения, связанные с тем, что source of truth, по сути, находится в оперативной памяти. Поэтому при редактировании справочной информации надо напрямую работать с Ignite через интерфейсы самого Ignite. Кроме этого, нужен аккуратный механизм синхронизации, чтобы кэш Ignite был персистентным. У Ignite есть собственный механизм для записи на диск, но все же Ignite больше ориентирован на работу в ОЗУ, поэтому для резервирования справочной информации в хранилище данных лучше использовать что-нибудь специально для этого предназначенное, например, Airflow.

Полезные ссылки, чтобы понять, как строить взаимодействие между Spark и Ignite и насколько это уже проработанный механизм:

Пользуясь случаем: мы расширяем отдел систем обработки данных. Если вам интересно заниматься с подобного рода задачами, пишите мне в личку, в телеграм @its_ihoziainov или на job@itsumma.ru с пометкой data engineering.

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

Подробнее..

WI-FI 6 ЧТО ЭТО? КАКИЕ СЕРВИС ПОДКЛЮЧАТЬ? СЦЕНАРИИ ИСПОЛЬЗОВАНИЯ (ЧАСТЬ 1)

15.04.2021 16:11:54 | Автор: admin

ЧТО ЖЕ ТАКОЕ WI-FI 6 И ЧЕМ ОН ЛУЧШЕ ПРОШЛХ ФОРМАТОВ

Резюме

Wi-Fi 6 (или802.11 ax) новый стандарт беспроводных сетей. Новый формат, который создавался с целью исправить баги прошлых стандартов. К 2021му году у WiFi накопилось достаточно нерешенных проблем.

  • Конфликт между точками Wi-Fi

  • Разрыв сигнала с точкой

  • Однопоточность сигнала. 1 сигнал 1 устройство

  • Энергопотребление

Wi-Fi 6 создавался для решения этих проблем.

ОТЛИЧИЯ WI-FI 6 ОТ СТАРХ ФОРМАТОВ

Новые технологии решают недостатки прошлых стандартов. Ниже подробный список.

MU-MIMO

Что решает:Проблема конфликта точек Wi-Fi

Как действует:у точки доступа/роутера может быть не одна антенна. Из-за большого количества антенн устройства могут конфликтовать друг с другом. Такие конфликты ведут к разрывам сигналов и сбоям обмена информации. MU-MIMO дает каждому устройству свою собственную антенну.

OFDMA

Что решает:Проблема однопоточности

Как действует:до выхода Wi-Fi 6 точки доступа отправляли пакеты данных по очереди. Если в сети было больше 5 устройств это могло нивелировать широкополосный интернет. OFDMA одновременно делит сигнал между всеми устройствами. Каждое устройство получает столько трафика, сколько требуется.

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

BSS COLORING

Что решает:Конфликт между точками / конечными устройствами

Как действует:Точка доступа окрашивает сеть. Устройства, которые подключаются к сети видят только свои точки доступа. Таким образом точка доступа отличает свои устройства от чужих, тем самым, решает проблему конфликта точек.

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

TARGET WAKE TIME (TWT)

Что решает:Энергопотребление

Как действует:как только точка перестает использоваться, она сразу переходит в режим ожидания. Если у конечных устройств нет постоянных фоновых процессов, экономия электроэнергии может достигать 90%.

Пример:Wi-Fi на складе затратнее, чем может казаться. Чтобы избежать интерференции сигнала из-за преград (стеллажи, полки, грузы) приходится увеличивать количество точек доступа. Конечные устройства используются только в момент погрузки/разгрузки и изменения положения товара, все остальное время сеть простаивает. Это неминуемо ведет к пустому расходу энергии. Для таких сценариев и создавался (TWT)

BEAM FORMING

Что решает:Разрыв сигнала с точкой

Как действует:Точка доступа направляет сигнал в сторону конечного устройства. Из-за преград сигнал может ослабевать или теряться.

Пример:В офисе может быть большое количество кабинетов. Ставить в каждом Wi-Fi точку экономически невыгодно, но и оставлять людей без сети, тоже не имеет смысла. Пара точек Wi-Fi 6 точек доступа могут закрыть потребность всего офиса.

Чуть более сложно, зато наглядно, это описано в видео. Кликай.

ЧТО УСТАНОВИТЬ ПОВЕРХ WI-FI 6

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

  • Маркетинг

  • Склад

  • Производство

  • Управление

  • Безопасность

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

МАРКЕТИНГ

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

Аналитика потребительских привычек

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

Профилирование клиента

На основании посещаемости маркетинговых зон, системы аналитики могут профилировать заказчика. Т е предоставлять рекламные акции, интересные только определенному профилю заказчика.

К примеру: женщине 30-45 лет, которая большую часть времени была возле магазинов мебели, могут быть интересна реклама товаров для дома и ремонта квартиры.

Wi-Fi ловушки

После того, как профиль посетителя создан можно отправлять ему актуальную рекламу и опросы. Специальное ПО позволяет рассылать рекламные уведомления или показывать промо ролики, при аутентификации в сеть.

СКЛАД

Решения Wi-Fi для склада полностью раскрываются только в паре с IOT устройствами. Склад всегда считается Серой зоной любого бизнеса из-за регулярных потерь/недочёта товаров. Для получения контроля над складом существует WMS решения

WMS (Warehouse Management System)

Такие системы позволяют вести учет и мониторить склад.

Возможности WMS систем:

  • Интеграция с CRM

  • Рекомендации к позиционированию грузов в рабочем пространстве

  • Интеграция со службами логистики

  • Управление человеческими ресурсами

В данном случае Wi-Fi является фундаментом, на котором будут размещаться такие решения.

УПРАВЛЕНИЕ

Целый массив решений помогает компаниям управлять персоналом.

Системы RTLS (Real-time Locating Systems) на базе Wi-Fi

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

Формирование корпоративных политик

Корпоративные политики могут мониторить трафик и регистрировать посещение сторонних сайтов и ресурсов. Если работник посещает сайт конкурента или биржи по поиску работы, система это зарегистрирует.

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

БЕЗОПАСНОСТЬ

Защищенный доступ к корпоративным сетям

Корпоративная Wi-Fi сеть может стать точкой атаки злоумышленников. Одного пароля на вход может быть недостаточно. ИБ решения на базе двухфакторной аутентификации добавляют трудностей злоумышленникам. Увеличение стоимости взлома является самым эффективным средством защиты.

Предиктивная аналитика угроз

У каждой кибер- угрозы есть признаки и сигнатуры. Для того чтобы находить вредоносное ПО внутри Wi-Fi сети инженеры придумали приложения для анализа угроз. Эти приложения подключаются к потоку данных и, с помощью нейронных сетей, анализируют поведение пользователей.

В СЛЕДУЮЩЕЙ ЧАСТИ

В следующей части мы обсудим готовые решения на базе WI-FI 6 для разных сценариев и типов и размеров кампаний

Подробнее..

Как мы развернули круглосуточную техническую поддержку с нуля всего за 1 год

15.04.2021 18:16:38 | Автор: admin

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

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

Начинаем с малого: ты, да я, да мы с тобой

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

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

Суббота и воскресенье? Работаем!

Через 2-3 месяца работы саппорта стало ясно, что клиентов и партнеров нужно поддерживать и по выходным. У бизнеса задачи не ограничиваются рабочей неделей, многие компании выполняют те либо иные задачи и тогда, когда все отдыхают.

В отделе технической поддержки на тот момент было уже 3 инженера и 1 тимлид. Задумались мы тогда и о круглосуточной поддержке, но эту идею пришлось отложить. Не потому, что организовать ее сложно, а потому, что это дорого.

Подсчитали, сколько еще людей нужно добрать, прокалькулировали связанные с расширением операционные расходы, посмотрели статистику звонков. Как оказалось, основной трафик идет по будням с 10:00 до 20:30, так что смысла оплачивать дополнительные 14 часов в день пока не было. Но вот субботу и воскресенье решили добавить.

Решение нашли быстро: недельный дежурный с дополнительной оплатой по выходным.

А теперь - диверсификация обязанностей

Компания росла, расширялся и отдел поддержки. Не очень быстро - к октябрю 2020 года количество сотрудников в нем достигло 6 человек. Это 1 тимлид и 5 инженеров.

Клиенты и партнеры саппортом были вполне довольны. Но задач, конечно, стало больше, увеличилось и их разнообразие. С течением времени мы стали замечать, что отдел сам по себе разделился на две части, как раз по типам решаемых задач. Условно это было разделение на "Help Desk" и на "мониторинг". Работа стала эффективнее, и мы уже официально разделили отдел на два подразделения:

  • Help Desk - 2 человека

  • Мониторинг - 3 человека

Единственное - тимлида разделить не удалось, поскольку он был один и не хотел, чтобы его делили. Пришлось оставить его как есть, с условием, чтобы он координировал работу всего отдела.

Задачи Help Desk:

  • Поддержка платформы и локализация ее проблем (ошибки API; кнопка работает не так, как должна; нет доступа и тд.).

  • Поддержка сервисов платформы и локализация проблем с ними (робот не звонит, вместо "привет" распознает "вечер, море, хочу в отпуск", тарабанит фразы как робот и становится не похож на человека).

  • Поддержка SIP-телефонии (сетевые проблемы телефонии).

  • Поддержка External API.

Задачи мониторинга:

  • Мониторинг сетевой инфраструктуры и своевременная реакция на возникающие проблемы (сервера, базы данных, сетевое оборудование).

  • Мониторинг коммерческого трафика и своевременная реакция на возникающие проблемы (прослушивание некоторого кол-ва звонков, отслеживание ключевых показателей проектов).

Спустя некоторое время оценили преимущества разделения:

  1. Специалисты саппорта прекрасно знали свои обязанности и не мешали друг другу.

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

  3. Задачи выстроились в стройную систему.

  4. Выходные можно закрывать без дежурного.

Последний пункт стоит немного пояснить. Дело в том, что на этом этапе мы отказались от дежурного в подразделении Help Desk. Вместо этого мы предложили подразделению мониторинга 7-часовой рабочий день по будням с тем, чтобы на выходные у сотрудников оставалось 10 дополнительных часов. Это решение обсуждалось вместе с сотрудниками, которые были не против. Схема простая: сначала один человек работает по 7 часов по будням и в выходные, потом второй, потом третий и так далее. Ну а затем - наша песня хороша, начинай сначала.

Ну привет, круглосуточная поддержка

Выше уже упоминалось, что круглосуточную поддержку мы не вводили, поскольку подавляющее большинство клиентов и партнеров обращались с вопросами в обычное время - с 10:00 до 20:30. Почему так? Все просто - те, с кем мы работали ранее, находились в одном с нами часовом поясе.

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

Сначала получалось так:

  1. Help Desk - c 9:00 до 18:00 по будням. Здесь пока что ничего не менялось.

  2. Мониторинг - 3 смены: 9:00-18:00 (2 человека), 14:00-21:00 (1 человек), 1:00-9:00 (1 человек, добрали позже из другого часового пояса на ГПХ).

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

Изначально выбирали из трех перспективных вариантов реализации полноценного круглосуточного саппорта:

  1. Три смены по 9 часов - утро, вечер, ночь.

  2. 2/2 по 12 часов

  3. Сутки через трое (Why not? как гипотеза подойдет)

По деньгам все варианты более-менее были равны, поэтому стали выбирать, исходя из потребностей и внешних факторов. Основных пунктов было четыре:

  1. Желание сохранить команду (многим не нравится сменный график, и в этом нельзя никого винить)

  2. Необходимость сделать оплату смен достойной (текучка кадров никому не нужна)

  3. Необходимость рассчитать количество сотрудников, которых нужно пригласить дополнительно.

  4. Поиск сотрудников.

Поразмыслив, мы решили оставить первый вариант - три смены по 9 часов. Почему так? Режим сутки через трое рассматривался просто как экзотичный вариант. Но работать 24 часа, а потом трое суток быть дома - на это соглашаются далеко не все, и это понятно. Суточные смены очень сложные.

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

Что было сразу, до глобального перехода на круглосуточную работу?

  1. Help Desk - 4 инженера.

  2. Мониторинг - 3 инженера + 1 инженер ночью.

Теперь решаем наши задачи:

Сохраняем команду - оставляем у всех все так, как есть сейчас. Пусть продолжают работу по стандартному графику - 9:00-18:00

Рассчитываем минимальное количество людей на смене - тут все зависит от нагрузки и трафика в вечер и ночь. В нашем случае достаточно по 1 человеку на ночную смену для каждого подразделения:

Итого нужно:

  1. Help Desk - 4 утро, 1 вечер, 1 ночь.

  2. Мониторинг - 3 утро, 1 вечер, 1 ночь.

После решения этой задачи приступаем уже к реализации. Набрасываем график с 18-20 обязательными сменами (естественно, его можно варьировать), чтобы был запас на больничные/отпуска и ребята могли добрать смен вплоть до 25+.

Где мы искали дополнительных сотрудников для вечерних и ночных смен? Да где и все, собственно - HH, Rabota, LinkedIn и др. Кстати, были даже попытки найти разработчиков на Tinder, но об этом уже в другой раз.

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

Подробнее..

Переход на ЮЗДО какие сложности нужно решить в первую очередь

15.04.2021 20:09:13 | Автор: admin

Переход на юридически значимый документооборот (ЮЗДО) при всем влиянии на эффективность бизнеса остается сложной процедурой: нужно учесть многие нюансы, в том числе законодательные, перенастроить процессы, согласовать действия с контрагентами. Важна тщательная подготовка самостоятельная или с помощью опытных консультантов.

Меня зовут Владислав Степанов, я специализируюсь на внедрении и консалтинге в сфере автоматизации документооборота в ИТ-компании КОРУС Консалтинг. Хочу поделиться опытом и рекомендациями по переходу компаний на электронный документооборот и рассказать о нюансах: проблемах роуминга, типизации, маршрутизации, комплектности и обработки документов.

Для начала определимся с терминологией. Электронный документооборот (или ЭДО) это любой обмен цифровыми копиями документов как внутри компании, так и вовне. Как только штат организации преодолевает условную отметку в 100+ человек, потребность в ЭДО начинает ощущаться все более остро. Разница между обычным документооборотом и юридически значимым (ЮЗДО) в характере файлов, которыми обмениваются стороны. В последнем случае документ можно привлекать для доказательства прав. Таким образом, ЮЗДО это разновидность ЭДО.

Использование автоматизированных систем для ЮЗДО в бизнесе постепенно увеличивается несмотря на ряд объективных сдерживающих факторов. Полностью перейти на электронный документооборот мешает отсутствие законодательных норм для некоторых типов документов, не прописано разделение зон ответственности при использовании электронной подписи (ЭП).

Есть и хорошая новость: определенные государственные инициативы (в частности, вступившие в силу с 1 января 2020 года поправки в 63 ФЗ об использовании ЭП), распространение удаленной работы, рост количества мобильных сотрудников и растущая цифровая зрелость бизнеса стимулируют переход на ЮЗДО.

Насколько глубоко компания распространит ЮЗДО на свои бизнес-процессы, зависит от многих факторов. В крупных организациях, по нашим оценкам, до 75% документов на данный момент могут быть полностью и успешно оцифрованы, но на практике этот показатель гораздо ниже. Часть контрагентов по-прежнему не хочет переходить в цифру, хотя среди крупных игроков доля выбравших ЭДО достигает 30-50%, а в некоторых случаях даже больше. Тем не менее даже эти контрагенты зачастую предпочитают использовать ЭДО для обмена только какой-то частью документов, например, финансовой первичкой. А некоторые, наоборот, готовы обмениваться по ЭДО только полными комплектами.

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

Выбор системы для ЮЗДО

Платформой для автоматизации документооборота могут выступать разные внутренние системы: единая ECM (Enterprise Content Management) или несколько решений (СЭД/ECM, ERP и др). Еще на стадии выбора учитывайте возможности масштабирования ЭДО в будущем. Инструментария уже установленной в компании системы электронного документооборота, которая всех полностью устраивает, в будущем может не хватить для какого-то определенного процесса. Сейчас он не используется, но как только потребность возникнет, придется выбирать дополнительное решение, а это сопряжено с новыми затратами как на лицензии, так и на поддержку. Поэтому систему сразу необходимо примерить на вырост.

При выборе одной или нескольких ИТ-систем стоит учесть, что при ЮЗДО у каждой должны быть установлены свои коннекторы к операторам ЭДО, внешним и внутренним центрам хранения сертификатов подписей. Необходимо оценить, какие именно инструменты потребуются и, исходя из этого, очертить круг подходящих решений. Вполне возможно, что для полноценной реализации ЮЗДО вам может потребоваться не одна СЭД/ECM-система, но и ERP, CRM и другие, в зависимости от процессов.

Выбор оператора ЭДО

Сегодня на рынке представлено не менее двух десятков операторов ЭДО, которые предлагают услуги маршрутизации внешних документов: Диадок, СБИС, СФЕРА Курьер, Такском, Калуга Астрал, Синердокс и другие. С точки зрения взаимодействия и выбора подходящего SLA, проще работать через единого оператора ЭДО. Но так только кажется.

На самом деле контрагенты компании обычно работают с разными операторами ЭДО. Чем больше у бизнеса партнёров, с которыми у него налажен документооборот, тем больше провайдеров ему придется вовлечь. Для обмена между операторами существует роуминг, но на данный момент в его реализации есть ряд сложностей.

  • Операторы по-разному настраивают роуминг: через запросы в личном кабинете, письма менеджеру, веб-формы, и все эти процедуры нужно проходить в ручном режиме.

  • Роуминг между операторами может занимать много времени, так как тех, кто подписал в рамках инициативы ассоциации разработчиков и операторов систем электронных услуг (РОСЭУ) интеграцию в один клик, пока немного. У прочих провайдеров настройка может растянуться на 10-15 дней и даже несколько месяцев.

  • Роуминг не предоставляет все возможности ЭДО. Например, из-за этого довольно часто процесс аннулирования документов не работает. Это касается и дополнительных функций, на которые дал согласие один оператор ЭДО, но передать другому их нельзя.

  • Существуют проблемы с наименованием документов (при роуминге используется транслитерация).

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

Не все операторы ЭДО работают с пакетами документов, которая необходима многим крупным компаниям.

Работа с контрагентами

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

Чтобы сделать выбор, нужно рассмотреть тех провайдеров, с которыми работает большинство контрагентов компании. Как правило, это СБИС, Диадок и Такском. Такую информацию даст опросник, рассылаемый клиентам/поставщикам: его можно составить как своими силами, так и с помощью консалтинговой компании. Он поможет выяснить, готов ли партнер перейти на ЭДО, что ему мешает и как можно помочь.

Если партнер принципиально готов работать в рамках ЭДО, определите, какими именно типами документов он будет с вами обмениваться. Если данная организация раньше никогда не работала с электронным документооборотом, нужно будет донести до неё потенциальную выгоду цифровизации процесса.

Крупные организации, как, например, Сбер или Магнит, могут себе позволить переход на ЭДО в уведомительном порядке, просто сделав его обязательным условием с оговоренной даты. Но если ваше влияние на рынке не столь велико, нужно будет договариваться с контрагентами и выделить на это время.

Нюансы работы с документами: типизация, маршрутизация, комплектность

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

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

Еще один важный вопрос связан с комплектностью первичных документов, присланных контрагентами. Речь идет о возможности разбирать комплекты, чтобы потом передавать их в определенные ИТ-системы, и собирать их из нескольких систем в единый пакет, подписывать и отправлять вовне.

Третья группа вопросов связана с большим объемом документооборота с контрагентами. Для них может быть реализована техническая подпись. Кроме того, важно прогнозировать рост объема документов в перспективе для того, чтобы заранее определить потребность в ресурсах для их обработки и хранения. Этот параметр также влияет на выбор класса систем ECM и расчет потенциальных затрат.

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

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

оцифровки и хранения внутри ИТ-системы всего архива. Это может быть сделано как в самой компании, так и передано на аутсорсинг.


Несмотря на большое количество нюансов внедрение ЮЗДО в компаниях продолжается. Работа с внешними консультантами позволяет сделать такой переход максимально безболезненным, учесть все тонкости и факторы. Если в организации уже есть ЭДО и/или ЮЗДО, специалисты помогут сделать их использование более эффективным и масштабировать решения.

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

Ведь в конечном счете задача перехода на ЮЗДО состоит не в том, чтобы усложнить процессы в бизнесе, а упростить их, ускорить прохождение процедур, способствовать росту операционной эффективности и прибыли. И все эти возможности заложены в саму идею ЭДО, но работают только в умелых руках.

Подробнее..

Перевод Apache Kafka скоро без ZooKeeper

16.04.2021 08:17:32 | Автор: admin

image


В основе Apache Kafka находится лог простая структура данных, которая использует последовательные операции, работающие в симбиозе с оборудованием. Эффективное использование дискового буфера и кэша процессора, prefetch, передача данных zero-copy и много других радостей все это благодаря построенной на логе структуре, которая славится своей эффективностью и пропускной способностью. Обычно эти преимущества, а еще базовая реализация в виде лога коммитов, первое, что люди узнают о Kafka.


Код самого лога составляет относительно малую часть всей системы. Гораздо больше занимает код, который отвечает за организацию партиций (т. е. логов) на множестве брокеров в кластере назначает лидеров, обрабатывает сбои и т. д. Этот код и делает Kafka надежной распределенной системой.


Раньше важной частью работы распределенного кода был Apache ZooKeeper. Он хранил самые важные метаданные системы: где находятся партиции, кто из реплик лидер и т. д. Поначалу эффективный и проверенный ZooKeeper действительно был нужен, но, по сути, это что-то вроде специфической файловой системы или API триггеров поверх согласованного лога. А Kafka это API pub/sub (издатель-подписчик) поверх согласованного лога. В результате пользователи настраивают, конфигурируют, мониторят, защищают и обдумывают взаимодействие и производительность между двумя реализациями лога, двумя сетевыми уровнями и двумя реализациями системы безопасности каждая со своими инструментами и хуками мониторинга. Все стало неоправданно сложно, поэтому решено было заменить ZooKeeper сервисом кворума прямо в самой Kafka.


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


image


Мы с Джейсоном, Колином и командой KIP-500 прогнали полный жизненный цикл сервера Kafka с созданием и потреблением сообщений и все без Zookeeper. Какая же красота!
Бен Стопфорд (Ben Stopford)


Рады сообщить, что ранний доступ к KIP-500 уже закоммичен в ствол и будет включен в предстоящий релиз 2.8. Впервые Kafka можно использовать без ZooKeeper. Мы называем это режимом Kafka Raft Metadata, сокращенно KRaft (читается крафт).


В этом релизе пока доступны не все фичи. Мы еще не поддерживаем ACL и другие транзакции или функции безопасности. Переназначение партиций и JBOD тоже не поддерживаются в режиме KRaft (надеемся, что они будут доступны в одном из релизов Apache Kafka в этом году). Так что контроллер кворума считаем экспериментальным и для прода пока не используем. В остальном преимуществ масса: деплоймент и обслуживание станут проще, всю Kafka можно запустить как один процесс, а на кластер помещается гораздо больше партиций (цифры см. ниже).


Контроллер кворума: консенсус на основе событий


Если запустить Kafka с новым контроллеров кворума, все задачи по метаданным, которые раньше выполнялись контроллером Kafka и ZooKeeper, ложатся на новый сервис, запущенный прямо в кластере Kafka. Контроллер кворума можно запустить на выделенном оборудовании, если этого требует ваш сценарий.



Внутри происходит много интересного. Контроллеры кворума используют новый протокол KRaft, чтобы точно реплицировать метаданные по всему кворуму. Протокол во многом напоминает ZooKeeper ZAB и Raft, но с важными отличиями например, что логично, он использует архитектуру на основе событий.


Контроллер кворума хранит свой стейт с помощью модели на основе событий, чтобы стейт-машину всегда можно было в точности воссоздать. Чтобы лог события, который хранит стейт (также называется топиком метаданных), не разрастался до бесконечности, периодически он обрезается с созданием снапшотов. Остальные контроллеры в кворуме фолловят активный контроллер и реагируют на события, которые он создает и сохраняет в свой лог. Если одна нода приостановлена во время разделения на партиции, например, она быстро догонит пропущенные события с помощью лога. Так мы существенно сокращаем период простоя и время восстановления системы в худшем сценарии.


image
Консенсус на основе событий


Раз протокол KRaft управляется событиями, в отличие от контроллера ZooKeeper контроллер кворума не загружает стейт из ZooKeeper, когда становится активным. При смене лидера у нового активного контроллера уже есть в памяти все закоммиченные записи метаданных. Более того, для отслеживания метаданных в кластере используется тот же механизм на основе событий, что и в протоколе KRaft. Задача, которую раньше обрабатывали RPC, теперь полагается на события и использует лог для коммуникации. Приятное последствие этих изменений (и изменений, которые были предусмотрены изначальным замыслом) Kafka теперь поддерживает гораздо больше партиций, чем раньше. Обсудим подробнее.


Увеличение масштаба Kafka до миллионов партиций


Максимальное число партиций в кластере Kafka определяется двумя свойствами: лимит партиций для ноды и лимит партиций для кластера. Сейчас на ограничение в кластере во многом влияет управление метаданными. Предыдущие KIP улучшили лимит для ноды, хотя и здесь нет предела совершенству. Масштабируемость в Kafka зависит от добавления нод. Здесь нам важен лимит для кластера, который определяет верхнюю границу масштабирования всей системы.


Новый контроллер кворума может обрабатывать гораздо больше партиций на кластере. Чтобы это проверить, можно провести такие же тесты, как в 2018 году, с помощью которых мы демонстрировали лимиты партиций в Kafka. Эти тесты измеряют время, которое требуется для завершения работы и восстановления. В старом контроллере это операция O (число партиций). Она устанавливает верхнюю границу числа партиций, которые сейчас поддерживает один кластер Kafka.


Предыдущая реализация, как рассказывалось в посте по ссылке, могла достигать 200K партиций. Ограничивающим фактором служило время, которое требовалось для переноса важных метаданных между внешним консенсусом (ZooKeeper) и внутренним управлением лидером (контроллер Kafka). С новым контроллером кворума обе роли выполняет один компонент. Подход на основе событий означает, что контроллер отрабатывает отказ почти моментально. Ниже приводятся цифры нашего тестирования для кластера с 2 млн партиций (в 10 раз больше предыдущего лимита):


image


Контроллер С контроллером ZooKeeper С контроллером кворума
Время контролируемой остановки (2 млн партиций) 135 сек 32 сек
Восстановление после неконтролируемой остановки (2 млн партиций) 503 сек 37 сек

Важно учитывать контролируемую и неконтролируемую остановку. Контролируемые остановки включают типичные рабочие сценарии, вроде rolling restart стандартная процедура развертывания изменений без потери доступности. Восстановление после неконтролируемой остановки важнее, потому что оно задает целевое время восстановления (RTO) системы в случае, скажем, неожиданного сбоя, например, на виртуальной машине или поде, или потери связи с дата-центром. Хотя эти цифры указывают на производительность всей системы, они напрямую определяют хорошо известное узкое место, которое возникает при использовании ZooKeeper.


Измерения для контролируемой и неконтролируемой остановки не сравниваются напрямую, потому что неконтролируемая остановка включает выбор новых лидеров, а контролируемая нет. Это расхождение введено специально, чтобы контролируемая остановка соответствовала изначальным тестам 2018 года.


Упрощение Kafka единый процесс


Kafka часто воспринимается как тяжеловес, и такой репутацией она во многом обязана сложностями с управлением ZooKeeper. Из-за этого для запуска проектов часто выбирают более легкую очередь сообщений, вроде ActiveMQ или RabbitMQ, а Kafka появляется на сцене только при разрастании масштаба.


Это печально, ведь Kafka дает удобную абстракцию на основе лога коммитов, которая одинаково хорошо подходит для маленьких рабочих нагрузок у стартапов и для бешеного трафика у Netflix или Instagram. А если вам нужна стриминговая обработка, без Kafka с абстракцией лога коммитов не обойтись, будь то Kafka Streams, ksqlDB или другой аналогичный фреймворк. Управлять двумя отдельными системами (Kafka и Zookeeper) сложно, поэтому пользователи выбирали между масштабированием и простотой.


Теперь можно получить все и сразу. Благодаря KIP-500 и режиму KRaft мы можем легко начать проект с Kafka или использовать его как альтернативу монолитным брокерам, вроде ActiveMQ или RabbitMQ. Благодаря легкости и единому процессу это подходящий вариант для ограниченных в ресурсах устройств. В облаке все еще проще. Управляемые сервисы, например, Confluent Cloud, все берут на себя. Не важно, собственный это будет кластер или управляемый, мы можем начать с малого, а потом расширять его вместе со своими рабочими нагрузками все в рамках одной инфраструктуры. Давайте посмотрим, как выглядит развертывание с одним процессом.


Испытываем Kafka без ZooKeeper


Новый контроллер кворума пока доступен в экспериментальном режиме, но, скорее всего, будет включен в релиз Apache Kafka 2.8. На что он способен? Самое крутое это, конечно, возможность создавать кластер Kafka с одним процессом, как в демо.


Конечно, если вам нужна очень высокая пропускная способность, и вы хотите добавить репликацию для отказоустойчивости, понадобятся еще процессы. Пока контроллер кворума на базе KRaft доступен только как Early Access, для критических рабочих нагрузок он не годится. В ближайшие месяцы мы будем добавлять недостающие фрагменты, моделировать протокол с помощью TLA+ и внедрять контроллер кворума в Confluent Cloud.


image


Но поэкспериментировать вы можете уже сейчас. См. полный README на GitHub.

Подробнее..

Внедрение process mining аудит процессов в два клика

16.04.2021 12:14:51 | Автор: admin

Современные компании активно используют process mining для поиска узких мест в своих бизнес-процессах. У многих из них сформировано понимание ценности этой технологии ее используют для поиска инсайтов в больших массивах информации. Такая аналитика очень актуальна для предприятий, начинающих роботизировать свои процессы. Process mining помогает выявить узкие места автоматизации и связать существующие разрозненные IT-системы в единое целое.

Оптимизация автоматизации

Обычно на предприятии используют одну основную платформу для автоматизации ключевых процессов. Это может быть, например, система SAP, которая умеет обрабатывать до нескольких миллионов событий чего вполне хватит для достаточно крупного холдинга с десятками тысяч сотрудников.

С помощью process mining можно проводить аудит автоматизированных процессов. Этот инструмент позволяет ускорить поиск путей для оптимизации и цифровизации бизнеса. И здесь большинству организаций не удается избежать главных барьеров цифровой трансформации. Самым распространенным является кадровый барьер, обуславливающий нежелание и неготовность сотрудников к изменениям. В этом случае хорошо структурированные и подкрепленные аналитикой данные, полученные с помощью process mining, помогают инициаторам роботизации показывать потенциальную полезность от использования RPA-систем.

Однако, отсюда же вытекает и основная сложность внедрения process mining с его помощью можно легко получить инсайты, но самые первые результаты и рекомендации выглядят очевидными, понятными и без привлечения ИИ. Например, process mining может показать точку в процессе, в которой документ долгое время ожидает ввода дополнительных данных от сотрудника. Такое узкое место может быть просто устранено роботом, который автоматически дополнит документ необходимыми данными. Подобная рекомендация может показаться простой и очевидной. Поэтому для неспециалистов ценность внедрения process mining сильно снижается, а инициаторам роботизации приходится постепенно идти от явных инсайтов к скрытым, постепенно раскрывая ценность использования process mining.

Первые шаги: тестирование и выбор платформы

Для тестирования работы и возможностей process mining лучше выбирать небольшие проекты. При выборе платформы для process mining важно учесть ряд критических факторов: гибкость системы, функциональность, возможность простой интеграции с разными системами и стоимость лицензий. Одним из интересных решений является UiPath Process Mining, в котором есть встроенный модуль ETL, для компаний, только начинающих внедрение process mining, это большое преимущество. Его наличие внутри решения сильно облегчает развертывание в IT-системах.

Внедрение process mining всегда сопряжено с проблемой подготовки данных, которую обычно решают созданием специального пула подготовленных данных, для которых нужен выделенный data-сервер. Это дорогое удовольствие. PM дает возможность избежать этого, выгружая данные на собственные сервера, что позволяет не тратить финансы на поддержание работы внешних серверов и зарплаты обслуживающему персоналу.

Трудности перевода

При внедрении process mining в работу компании обычно бывает две основных сложности. Первая большие объемы данных, которые нужно анализировать. Вторая долгая автоматизация и наличие большого количества legacy-систем. Обе эти проблемы приводят к тому, что данных внутри компании много, но их невозможно анализировать, потому что они находятся в несвязанных друг с другом системах или представлены большим набором менеджерских дашбордов.

Кроме того сами процессы в компании могут быть устроены очень сложно, хотя

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

Как мы видим процессКак мы видим процессЧто происходит на самом делеЧто происходит на самом деле

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

Как это выглядит цепочка действий в интерфейсе Process MiningКак это выглядит цепочка действий в интерфейсе Process Mining

Process mining помогает в десятки раз ускорить восстановление процессов и делать это всего в несколько кликов, в отличие от ручного режима. С process mining поиск узких мест и выявление отклонений в процессах происходит практически в автоматическом режиме. Появляется объективность и достоверность, когда данные говорят сами за себя. Отпадает потребность в интервью с пользователями процесса. Аналитика появляется как на самом общем уровне, так и на уровне максимальной детализации по каждому сотруднику:

Действия, отфильтрованные по конкретному сотрудникуДействия, отфильтрованные по конкретному сотруднику

Process mining это универсальный инструмент для специалистов по роботизации и внедрению RPA-решений. С его помощью становится удобно выявлять регулярные процессы с большим количеством повторений это потенциальные точки для будущей роботизации. Кроме того можно проводить непрерывный мониторинг критических показателей ключевых процессов. Не погружаясь в недра цифровых платформ, получать структурные и понятные данные на диаграмме процессов.

Подробнее..

Арт-специальности в GameDev, какие бывают и что необходимо знать

16.04.2021 14:07:36 | Автор: admin

Ребята всем привет!!!

Сегодня говорим о специальностях в GameDev. Сразу оговорюсь, мы здесь не будем рассматривать таких профессии, как гейм-дизайнер, арт-лид и прочие специальности более административной деятельности.

Речь пойдет о тех "бойцах первого эшелона", о тех кто оживляет игру и добавляет в неё красок, причем буквально. Игровой арт, в котором "варятся" художники, воплощает собой креатив, творчество и в тоже время определенный набор функций, необходимый для получения качественного игрового приложения.

CG очень увлекательная сфера деятельности, здесь есть, где найти себе приложение будь-то игры, кино, реклама или научная визуализация (Фото: https://cgmag.net)CG очень увлекательная сфера деятельности, здесь есть, где найти себе приложение будь-то игры, кино, реклама или научная визуализация (Фото: https://cgmag.net)

Игровой художник создает 2D и 3D-графику для визуализации видео игры: от пропосов (элементов интерьера сцены) и окружения (декораций) до спецэффектов, текстур, света, рендера и т.д. Зачастую профессия требует серьёзных знаний и навыков: понимания ракурсов съемки, физики, теории цвета и света, знание анатомии и программирования. Но при трудоустройстве, конечно же, всё решает портфолио и практика.

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

Концепт-артист (персонажник)

Это человек создает дизайн, его главная задача перенести на черновик то, как будет выглядеть персонаж. Прежде, чем создать персонажа важно понять, каким он будет, чтобы передать формы, черты, характер, условия жизни (причем иногда приходиться придумывать, так как многое в жизни не существует в реале. Приходится даже думать над тем как будет двигаться данный персонаж, какой режим сна и бодрствования у него, чем он питается и т.д.).

Работа концепт-артиста (концептера) предложить варианты персонажа (например), исходя из тех задания, как правило это серия однотипных объектов, но представленных в разном виде. (Фото: https://cgmag.net/)Работа концепт-артиста (концептера) предложить варианты персонажа (например), исходя из тех задания, как правило это серия однотипных объектов, но представленных в разном виде. (Фото: https://cgmag.net/)

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

Концепт-артист (окружение)

Он также занимается "отрисовкой", но уже объектов в сцене, он рисует все то, что так или иначе окружает персонажа в игре. Это могут быть самые разные локации от рынков, людных площадей, замков, башень, портов, городских больниц до лесов, пещер, океанов, инопланетных миров и других вселенных.

Так же очень часто данный специалист рисует задний фон для для всей сцены в целом, так называемый mate-paint. Кроме всего прочего он, работает так же как и раскадровщик, и иллюстратор и необходим, когда надо "разложить" игру по отдельным сценам и посмотреть как будет представлен сюжет в целом.

Концепт-артист не редко совмещает в себе умение рисовать все и вся и "персонажку" и окружение. Основным софтом используемым концептерами являются (http://personeltest.ru/aways/medium.com, Garry Potter and Deadly Shadows)Концепт-артист не редко совмещает в себе умение рисовать все и вся и "персонажку" и окружение. Основным софтом используемым концептерами являются (http://personeltest.ru/aways/medium.com, Garry Potter and Deadly Shadows)

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

Художники окружения Ведьмак 3: Дикая Охота работали над локациями вместе с 2D художниками, левел-дизайнерами, дизайнерами квестов и писателями, чтобы убедиться, что визуальная составляющая мира во всем поддерживала сюжет. - Михаль Жажиневски

Художник по моделям или 3D/2D-моделлер его задача создать высококачественные 3D/2D модели. У компаний в геймдеве есть высокий спрос на людей, которые могут сделать 3D-слепок орка или космодесантника. Здесь возможны также различные варианты "прокачки", если ты моделишь пропсы, архитектуру, танки, самолеты, роботов, летающие метла и прочее ты занимаешься Hard Surface моделированием. Если ты больше тяготеешь к созданию персонажей, различным живым существам, монстрам, феям, драконам, леприконам, рыцарям, очаровательным красоткам, тебе больше подойдет Organic/Personage моделинг.

Hard surface modeling, очень часто моделят тачки, самолеты, корабли ракеты и прочее (Фото: websoftex.ru)Hard surface modeling, очень часто моделят тачки, самолеты, корабли ракеты и прочее (Фото: websoftex.ru)

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

Коллизии это всегда появление артефактов в той или иной степени на финальной картинке (а это не приветствуется, все должно быть идеально). Процесс создания сетки в момент разработки модели называется топологией. Бывает так, что необходимо переделать сетку не меняя модели - это называется ретопологией а сам процесс создания самой модели называется скульптингом. Моделер, работает в Maya, 3dsMax, Blender, Z-Brrush, Marmoset, Houdini (если мы говорим о процедурном моделировании).

Персонажное моделирование, подразумевает знание анатомии в обязательном порядке (Фото: https://www.pinterest.ru)Персонажное моделирование, подразумевает знание анатомии в обязательном порядке (Фото: https://www.pinterest.ru)

Аниматор

Данный специалист "оживляет" персонажа, то есть он сначала разрабатывает систему рига (то есть настраивает скелет для персонажа) а затем придает необходимые движения персонажа посредством анимационных ключей, которые расставляются при том или ином нажатии кнопки.

Работа очень кропотливая и долгая, здесь учитывается анатомия персонажа, придумываются его движения и строятся зависимости. Труд таких людей очень ценится в любой игровой студии, поэтому выучиться на них никогда не поздно изучайте доступные программы по созданию анимаций, вроде Maya, Unity, Unreal и становитесь игровыми аниматорами.

Художник 2D/3D текстур

Данная "боевая" единица занимается текстурами для персонажей, объектов, окружения и различными поверхностями. Здесь особым плюсом будет если вы хорошо понимаете и любите работать с материалами и поверхностями. Они могу быть самыми различными: камень, лед, вода, лава, дерево, трава, кожа, огонь, металл и т.д.

Этот специалист работает над шейдингом (процессом создания текстуры в ее "широком" понимании) чем более детальнее и реалистичнее она будет, тем более качественной получится игра. Но не стоит забывать про системные ограничения. Так как, игры делаются для пользователей и разработчики заинтересованны что бы у конечного пользователя все "летало" на домашней машине.

Текстуры могут быть многослойными, матовыми, глянцевыми, прозрачными, полупрозрачными и т.д. тем самым передавая очень сложную фактуру поверхности. Создаются карты нормалей, отражений, бликов, прозрачности, степени преломления, искажений, псевдобьема, карты подповерхностного отражения света (SSS), карты диффузного света и т.д. Степень вложенности карт может быть любая, они могут по разному сочетаться и давать суммарную картинку со всеми "эффектами".

Приложения, с которыми работает данный специалист это Substance Designer, Substance Painter, Photoshop, Marmoset, Mari, Marvelous Designer, ZBrush, Fusion 360, UV Layout, Rizom UV, Maya, 3dsMax и т.д. Я перечисляю лишь то, что наиболее популярно в продакшене (по есть производстве).

Художник по освещению

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

Его/её задача найти баланс между светом и цветом. И расставить необходимые акценты по ходу развития сюжета игры. Также этот человек должен не только знать композиционные приемы расстановки света, но и уметь, подчас кодить. Так что, языки программирования здесь пригодятся. Художник по освещению работает, в том пакете, в котором ведется вся остальная разработка, это может быть Unity, Unreal, Cryengine.

Свет в играет играет важную роль, он придает тон и настроение всей сцене. (Фото: gdjob.pro)Свет в играет играет важную роль, он придает тон и настроение всей сцене. (Фото: gdjob.pro)

Художник визуальных эффектов

По-модному VFX-художник или эфыксер, в на сленге GameDev )). Этот персонаж, мой самый любимый, он сочетает в себе качества разработчика и художника. Он буквально "оживляет" любую часть игры. Будь-то порывы ветра, дождь, пыль или дым, даже искры орудий, в том числе стенобитных, дальнобойных и т.д.

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

Различают следующие виды симуляций:
- партикловая (симуляция частиц) сами по себе партиклы невесомы, но на них можно "навесить" небольшие спрайты или текстуры для создания эффектов огня или дыма, например;
- cимуляции частицами и флюидами здесь самих частиц может быть не так много, но более детальная проработка, например чего-то жидкого, вода, слизь, мед, смола, лава, а также любые сыпучие материалы и т.д.;
- симуляция разрушений - это касается любых разрушений и развалов чего-либо (обрушение скалы, падение огромной башни, разбитие стены и т.д.)
- волосы, шерсть, ткань - здесь название говорит само за себя;
- прочие "специальные" случаи которые не вошли в предыдущие, как правило этот пример RnD процесса (Research and Developmnet);

Все смотрится очень круто когда есть эффекты. (www.youtube.com, Grim Dawn)Все смотрится очень круто когда есть эффекты. (www.youtube.com, Grim Dawn)

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

VFX-художник великий финализатор. Он создает итоговый образ и завершает работу, которая прошла путь от концепта до моделирования и анимации. Антон Грицай

Эфыксер работает в том движке, в котором ведется разработка: Unity, Unreal, Cryengine. Кроме всего прочего, ему необходимо знать языки программирования CSharp, C++, Python. Также в обязательную программу входят Photoshop и системы контроля версий: Git, SourceTree. В связи с растущими требованиями рынка также высоко ценится знание Houdini, PopcornFX и т.д.

Художник-иллюстратор

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

Чтобы стать крутым спецом в игровой арт-индустрии требуются знания, навыки и постоянная их прокачка. Неплохо бы знать следующие вещи:

основы рисунка, работы с текстурой, объемами и светом;

чувствовать стиль и понимать, как аудитория воспримет тот или иной прием;

уметь читать техническую документацию;

выбирать инструменты со знанием дела;

много практиковаться, интересоваться работами других художников;

работать в команде, поскольку на конечный результат.

Подробнее..

Извилистые дороги корейских ОС, или Как Tizen OS и webOS к успеху шли

19.04.2021 12:12:03 | Автор: admin

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

Каким образом две мобильные ОС пережили эпоху глобального вымирания ознаменованного восхождением Android OS? Как так случилось, что платформы предназначенные для управления смартфонами оказались в телевизорах? Зачем корпорации LG и Samsung вдохнули вторую жизнь в угасающие Tizen OS и webOS? Какие перспективы у названных ОС совершить реванш на рынке портативных гаджетов и причем тут загадочная корейская душа? Об этом всем мы и поговорим далее в статье.

Коллеги по несчастью

Свой победоносный путь операционная система от Google - Android OS, начала в 2008 году. В это же самое время готовился к выходу в мир и первый смартфон под управлением webOS. К этому времени также мир увидела и iOS. Все эти молодые и перспективные ОС должны была вступит в бой за перераздел доли рынка дряхлеющей Symbian. С высоты сегодняшних дней реальность шансов на успех webOS многим может показаться весьма утопической, однако в то время это было далеко не так однозначно. Хотя webOS и был наиболее схож с Android OS, как в архитектуре ядра базирующемся в обоих случаях на Linux, так и в принципах проводимой политики максимальной открытости платформ, к 2009 году количество девайсов с предустановленным Android OS все еще было откровенно говоря мизерным. В то же время ОС на основе Symbian хотя и являлась монополистом на рыке мобильных ОС, но даже ее новоиспеченный владелец и главный клиент Nokia осознавала, что ОС морально устарела и замена платформы это лишь дело времени. Собственно доказательством последнего и стал активный передел рынка мобильных ОС, появлением новых и утратой позиций существующими ОС. Всего за два года детище Apple - iPhone под управлением iOS, отхватила впечатляющие 15% рынка мобильных девайсов.

Своевременная ставка корпораций Apple и Google на развитие своих магазинов во многом определила современное состояние рынка мобильных ОССвоевременная ставка корпораций Apple и Google на развитие своих магазинов во многом определила современное состояние рынка мобильных ОС

Хотя Tizen OS и не создавалась с нуля, но по многим параметрам это была действительно новая ОС. Возможно и не такая плохая и явно обладала шансами на жизнь, однако появилась она слишком поздно. Дело в том, что в Samsung озадачились разработкой собственной ОС в общем вовремя и с 2008 года успели выпустить более 20 моделей смартфонов под управлением собственной системы SHP ( Samsung Handset Platform ). Пришедшая на смену SHP операционная система Bada стала ее эволюционным развитием. Увидевшая мир аж в 2012 году Tizen OS для Samsung должна была стать уже скорее революционным развитием собственной платформы. Объединив усилия трех проектов LiMo, MeeGo, Bada новый программный продукт должен был вывести продажи смартфонов Samsung на качественно новый уровень, ведь целый ряд нововведений в ОС делал ее,опятже, чрезвычайно схожим с Android OS. Почему Tizen OS потерпела поражение на рынке смартфонов? Видимо по той самой причине, что и ряд других ОС Sailfish OS, Firefox OS, LiMo и тд. Все эти системы были достаточны подобны друг другу - политика развития в сторону открытости, упрощение жизни разработчикам ПО, кроссплатформенность, а это в свою очередь стало для них роковым фактором. Не сумев заинтересовать массового покупателя чем-то уникальным, новым в череде однотипных ОС победу одержала чуть более успешная Android OS, которая к слову также была далека от идеала в те далекие времена.

Имея такие разные биографии Tizen OS и webOS должно было объединить то, что они обе канут в лето вместе с множеством других ОС. Однако, связало их несколько другое обстоятельство.

Корейский гамбит

Удивительна история. Еще 50 лет тому назад Южная Корея являлась откровенно маргинальным, марионеточным государством. Как бы мы сейчас сказали - банановая республика. В тоже время КНДР довольно успешно строила плановую экономику советского типа. Даже еще в 70х годах большенство побегов к "оккупированному" соседу происходило именно с юга. Гонимые тотальной коррупцией и как следствие нищетой немало корейцев выбирали стабильность на "севере". Но мир не стоит на месте.

ВВП в долларах на душу населения по годам ВВП в долларах на душу населения по годам

Сейчас Южная Корея является лидером, а то и монополистом, в целого ряда важнейших секторов общемировой экономики. В разрезе ИТ невозможно не упомянуть о корпорациях Samsung и LG. Именно они то и сыграли главную роль в современном положении Tizen OS и webOS. В мире разделенном между адептами двух религий iOS и Android OS, само существование еще двух независимых, локально успешных платформ выглядит не менее интригующе как и существование коммунистической КНДР во всецело капиталистическом мире.

В 2012 году, когда webOS уже окончательно потерпела фиаско, а с ней разом и компания Palm, ситуацией как нельзя луче воспользовалась корейская корпорация LG выкупив все права на использование загибающейся ОС. Особенно подогревало интерес к этому приобретению то обстоятельство, что будучи довольно крупным производителем смартфонов LG мог бы вдохнуть новую жизнь во все еще весьма конкурентный продукт . Однако в планы корпорации вовсе не входило воскрешать из забвения павшего героя ведущего свою родословную еще из 90х. Проблема которую должна была решить покупка webOS состояла в отсутствии у LG собственной программной платформы для управления новомодными девайсами производимыми корпорацией. В свое время упустив из виду тот момент, что все чаще в названиях всевозможной техники появляется слово "Smart", LG столкнулась с необходимостью разработки с нуля собственного продукта, либо покупкой уже готового решения, для управления новомодными умными девайсами. Конечно оставался вариант пойти по пути мелких производителей и начать работу по адаптации к выпускаемой продукции Android OS, однако размеры компании, как и разнообразие выпускаемой номенклатуры товаров, диктовали необходимость создания собственной единой программой среды, которая должна была быть достаточно гибкой не только для уже существующей техники, а и для будущих перспективных разработок. Покупкой webOS остались довольны все, как получившее новые смыслы подразделение Palm так и оторвавшая за бесценок кучу патентов на полностью рабочий продукт корпорация LG.

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

Не смартфоном единым

Как-то довелось мне быть свидетелем повествования одного отставного военного инженера. Человек еще в 80х принимал участие в разработке "мозгов" межконтинентальных баллистических ракет. Поскольку основой безопасности страны советов были ядерные "щит и меч", внимание уделяемое разработке систем наведения, управления, принятия локальных решений "умными ракетами" было на самом высоком уровне. Со слов отставника, ресурсы выделяемые на эти программы лимитировались не более чем здравым смыслом, да и то не всегда. Но даже в таких "тепличных" условиях стоял целый ряд преград к достижению поставленных к ТТХ вооружения. Вызваны они были в первую очередь низким уровнем развития электронной компонентной базой. На то время в мире просто не существовало достаточно компактных, производительных ЭВМ для реализации всех предъявляемых к блоку управления "хотелок". Пытаясь увязать воедино уровень существующей электроники и предъявляемых требований единственным выходом для конструкторского бюро было максимально оптимизировать/упростить логику принятия решений встроенной ЭВМ. С одной стороны такая реализация изделия существенно повышала риск принятия системой управления ракеты неправильного решения, уже вовремя ее полета, что должно было приводить к провалу ее летного задания и включения системы самоликвидации, с другой стороны успешность поставленной задачи должна была достигаться за счет количества производимых запусков по выбранной цели, в общем-то достаточно рабочей системы.

В современном мире 5 нанометрового технологического процесса, где по вычислительным возможностям бюджетный смартфон превосходит суперкомпьютеры из 90х, задача по созданию максимально эффективного ПО не стоит так остро. Не ЦП, не встроенная память "железа" практически не лимитируют современные операционные системы, в то же время на первое место выходят такие вопросы к ОС как удобство использования, безопасность, универсальность, гибкость в настройке интерфейса. Как оказалось всем этим требованиям два новоиспеченных корейца вполне соответствуют.

Спектор техники с предустановленными Tizen OS и webOS весьма обширен. От упомянутых смартфонов, умных часов до фотоаппаратов, телевизоров, проекторов и холодильников. На сколько разумно, спросите вы, такое использование самой разной технике данных программных платформ? На этот вопрос может дать ответ тот коммерческий успех, который сопутствует сейчас компаниям. Обладая собственной ОС корейские корпорации не только успешно распространили свою продукцию на все континентах нашей планеты, но в значительной мере сохраняют "цифровой" суверенитет от не такой уж, как оказывается, "открытой платформы" - Android.

Неизвестно чего было больше в последних трениях между Huawei и Google политики или экономики, однако не имея сколько-то адекватной альтернативы используемой ОС и сервисам иже с нею, говорить в ближайшие несколько лет о технологическом доминировали китайских ИТ-гигантов просто не приходится.

Возможен ли "камбэк" в мир смартфонов?

В современном мире где 85% смартфонов работают под управлением Android OS, а оставшиеся 15% принадлежат iOS сложно представить появление нового успешного игрока. И дело тут не столько в "совершенстве" существующих операционных системах. Основная причина скорее лежит в плоскости отсутсвия необходимости в появлении новых ОС. Рынок мобильных программных платформ целиком и полностью удовлетворен существующими. Более того соотношение 15/85 между двумя современными монополистами также, скорее всего, существенно не изменится, даже в условиях появления новых игроков. Ведь, если более детально рассмотреть целевую аудиторию двух формальных конкурентов iOS и Android OS мы увидим, что она не слишком и конкурентна. И Google, и Apple "сожрали" своих истинных соперников еще лет 10 тому назад. Истинная борьба за клиента у iPhone развернулась, в свое время, с компанией BlackBerry, которая продвигала максимально защищенный продукт из премиум сегмента, в то время когда Symbian, Palm, Windows Mobile устанавливались в своей массе на абсолютно иного класса аппараты. Точно также и Android OS сражалась за наследие доживающей последние дни Symbian, в первую очередь, среди себе подобных открытых платформ.

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

На этом фоне остается напомнить лишь один нюанс. В свое время, глобальное доминирование Symbian было остановлено не количественными показателями конкурентов, а качественными изменениями потребностей рынка. Актуальность Symbian обнулил прежде всего технический прогресс позволивший выйти в мир смартфонам нового поколения. Первым тут был конечно же продукту от Apple, революционный iPhone - "бескнопочный" телефон . Не оценив вовремя всех угроз целый ряд многомиллиардных компаний потерпели огромные убытки и сошли с дистанции. В этой игре на вылет Nokia, как известно, стала абсолютным лидером. Может ли нас ожидать нечто подобное? Естественно.

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

Подробнее..

Recovery mode Вы нервно стоите на красный, хотя машин нет. Как сделать светофор умнее а проезжать и загруженные перекрестки быстрее?

19.04.2021 14:06:47 | Автор: admin

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


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

Адаптивный работаетна сравнительно простыхперекрестках, где правила и возможности переключения фаз совершенно очевидны.Адаптивное управлениеприменимо лишь там, где нет постоянной загрузки по всем направлениям, иначе ему просто не к чему адаптироваться нет свободных временных окон. Первые перекрестки на адаптивном управлении появились в США в начале 70-х годов прошлого века. К сожалению, до России они дошли только сейчас, их число по некоторым оценкам не превышает 3 000 по стране. (Часто под этим же названием понимаются обычные светофорные объекты, алгоритмы работ которых меняются в зависимости от времени суток и дней недели. С терминологией в Раше пока совсем плохо, здесь мы точно обсуждаем не адаптацию по времени.)

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

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

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

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

Нейросетевые светофорыи для распознавания объектов тоже используютнейронные сети,за счет этого они получают более информативную и супер точную картину происходящего. Эти мозги распознают любые образы в их любых положениях и поэтому более точно считают количество транспортных средств, делают это на гораздо большем расстоянии с одной камеры. Кроме этого,нейронные сетиопределяют качественный состав ТС как по типу, так и множеству других параметров. Например, длинная фура и быстрый Ferrari имеют совершенно разную манеру начала движения, что по-разному влияет на алгоритмы умного светофора. Даже постоянно забывающая трогаться на зеленый свет блондинка со знаком У на ТС постепенно включается в коэффициент поправки расчетов.Кроме того,нейронные сетиумеют распознавать и людей, что тоже очень важно ведь пешеходам тоже хочется пройти через дорогу. А такженейросетидиагностируют более сотни других объектов от детской коляски с велосипедами до чемоданов и оружия.

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

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

Разберем подробнее, где и за счет чего эти умные светофоры позволяют повысить пропускную способность:

Пример 1.Прилегающая к трассе второстепенная дорога.

Адаптивный светофор. Прилегающая к трассе второстепенная дорога.Адаптивный светофор. Прилегающая к трассе второстепенная дорога.

Когда проезжает одна машина в час из близлежащей деревеньки, так или иначе, мы обязаны пропустить её. Но для этого нам придется останавливать движение каждые 5 минут она не может ждать час. Если для пешехода достаточно повесить кнопку для включения зеленого, то у автомобиля такой возможности нет.

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

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

Пример 2.Городской перекресток в незагруженное время.

Нейросетевой светофорНейросетевой светофор

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

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

Никакими расписаниями этот вопрос не решить, обычная логика, которая есть в любом контроллере светофорных объектов, ошибется конкретно в этот день и в это время. Хотя ручные подстройки, конечно, ведутся и какой-то эффект они приносят. Ногораздо правильнее иметь обратную связь здесь и сейчас: если видеокамеры видят, где идет транспорт, то и включить надо зеленый в этом месте. Причем, заранее не заставляя тормозить.

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

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

Вы еще что-то хотели сказать:в ночное время надо включать мигающий желтый на всех перекрестках!- Пробовали, уже много десятков лет. Выяснили, что в нашей стране это очень опасно. Интернет просто забит роликами автогонок, никакие измерители скорости не останавливают ночных любителей разогнаться по городским дорогам до 300 км/час. В хлам превращаются не только автомобили, люди тоже переходят дороги по ночам.

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

Так сделано не потому, что мы как-то не признаем закон, мы так настроили наше оборудование в качестве задела на будущее. С нашей точки зрения жесткие ограничения скоростей, в принципе, не нужны. Кому с какой скоростью и в каком месте двигаться должен определять компьютер! Он всё просчитывает и выдает достаточно точное решение. Умный светофор должен останавливать только тех, чья скорость реально угрожает другим участникам движения. А ловить нарушителей другая тема, для этого есть специальные устройства.

Пример 3.Постоянно загруженный перекресток.

Нейросетевой светофорНейросетевой светофор

Здесь, наверно, каждому понятно, что подойдет тольконейросетевой светофор, потому что очевидной логики по переключению светофорных фаз просто нет: со всех сторон идет автотранспорт сплошным потоком, и кому дать приоритет?

Тем не менее, мы должны выделить какие-то временные фазы, у них есть длина. Сколько дать времени для проезда с севера на юг, чтобы прошло максимальное количество транспортных средств? Одну минуту, две, три? А может 569 секунд? Кто вот это должен сказать, какой-то очень умный человек или все-таки применить научный подход?

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

И вы сразу предлагаете: -Тогда надо дать максимально длинную фазу, чтобы не создавать частых пружин. Правильно это было бы, если у нас не было другого направления: с востока на запад. Оно тоже требует максимальную фазу. Эта игра у нас называется волки овцы: Те, кто едет волки, а стоят овцы.

И вы, уже не подумавши скажете: -Давайте всем дадим поровну! Допустим! Но сколько именно поровну? Ладно, договорились на 5 минут каждому. Но одно направление утыкается во второй перекресток, и ему эти 5 минут как мертвому припарка, оно встает уже через 3 минуты. Остальные две минуты перекресток просто забит еле двигающимися автомобилями. Мы теряем в скорости трафика, что тоже ведет к понижению пропускной способности.

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

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

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

И это только 30% повышения эффективности на загруженных всегда перекрестках. Самое интересное, что эту цифру легко довести до 60%, как вам такое? Не устали стоять в пробках?Хотите ездить в два раза быстрее?Здесь уже говорили, что самая затратная часть в этом процессе автотранспортная пружинка: на остановки и троганья уходит где-то ДО, а где-то БОЛЕЕ 50% времени. Что, если мы не будем останавливать больше половины автотранспорта? Если к нашему Умному светофору подключить соседние Умные светофоры, тонейронная сетьполучает ценную информацию: когда, где и на какой скорости движется поток, какой типа транспорта в каждом потоке, даже манеру вождения отдельных транспортных средств (помните блондинку, которую все объезжают?). Таким образом, мы уже можем убрать каждую вторую пружинку, а то и больше.

- Видим, что у вас появились и конструктивные предложения: -А что если и пред-предыдущие светофоры завести в общую систему? Совершенно верно,таким способом по Москве или Питеру можно ездить в разы быстрее!

А что сейчас? В больших городах построены шикарные центры АСУДД, в которых профессиональные специалисты (извините за тавтологию) управляют светофорными объектами. Они, конечно, не нажимают кнопку для каждой лампочки, но именно вручную выставляют режимы работы каждому светофору. В других городах и этого нет просто среднестатистическое расписание. Наверно, это круто для 30-х годов! Не сегодняшнего, а прошлого века, когда на улице стоял в будке регулировщик теперь его работа ведется удаленно.

Хотя, человек может обыграть компьютер в шахматы! В этой игре тоже миллион неизвестных. Наверно, в АСУДД работают профи. Но сколько существует гроссмейстеров на миллион людей, которые просто умеют играть в эту игру?Все-таки в 99,999999999999% выиграет компьютер.

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

В 3 раза повышается пропускная способность на загруженных перекрестках!

И снова вопрос: -Да, вы сделаете 3 участка, где транспорт будет летать, но весь этот поток упрется в четвертый уже не такой умный перекресток! Позвольте сразу не согласиться с фразой весь этот поток. Перегруженные перекрестки находятся в городах, обычно в их центрах, соответственно там много жилых домов, офисов, магазинов и прочих мест, куда едут люди. Т.е. за 3 участка не весть поток упрется в 4-ый перекресток, часть рассосется опять женейросетеваясистема управления может это легко рассчитать. К тому же за эту зеленую фазу мы исключаем приток других авто, т.е. мы можем заранее узнать максимальный объем ТС и соответственно вывести всех на такой участок дороги, который позволит создать приемлемую очередь перед обычным перекрестком. Т.е. заранее нужно выбирать длинные участки дорог перед старой версией светофоров.Никакого коллапса здесь не будет!

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

Внедрение Умных перекрестков.
Это самый простой с точки зрения технической реализации и самый сложный с точки зрения борьбы с технократией вопрос. Достаточно поставить 4 камеры во все направления даже на уже имеющиеся опоры и в большинстве случаев можно запускаться в работу. Главным элементом Умного перекрестка является программное обеспечение. Конечно, чем больше камер, тем выше эффективность, количество подбирается путем проектирования.

О самом сложном!
Сегодня везде уже стоят светофорные объекты прошлого века. Под них создана огромная инфраструктура с немалыми деньгами на обслуживание. Руководство регионов РФ само по себе технократично, а тут еще и передел рынка.

Есть и позитивная новость, Правительство РФ активно развивает Интеллектуальную транспортную систему, как минимум, на словах. Есть достаточно много Постановлений Правительства РФ для этого, более того выделяются деньги хотя бы поэтому Указу. Но, по нашему опыту, на местах настолько сильно сопротивляются прогрессу, что даже часто не осваивают эти средства, не смотря на то, что за это предусмотрено наказание.

Есть еще одна новость средней позитивности: Прогресс все равно придет! Было бы неправильно думать, что деньги выделяются просто так, правительственные круги активно двигают московские фирмы, которые занимаются поставкойадаптивных светофоров. И против Москвы сопротивляться сложно, она придет и снесет всех политиков региона. Но новость средняя, потому чтоадаптивное управление это прошлый век, оно уже 50 лет как используется в Штатах исегодня там меняется нанейросетевое.

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

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

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

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

Подробнее..

Итоговый проект для видеокурса и подкаст Проблемная Kafka

20.04.2021 08:05:05 | Автор: admin

Гостем подкаста The Art Of Programming стал спикер курса Слёрма по Kafka Александр Миронов, Infrastructure Engineer в Stripe. Тема выпуска Проблемная Kafka. Обсудили вопросы, часто возникающие при работе с Kafka: аудит входных данных, квоты, способы хранения данных, возможный даунтайм в консьюмер-группах и др.


Итоговый проект по Kafka


Релиз видеокурса от Александра Миронова и Анатолия Солдатова состоялся 7 апреля. Кроме заявленных тем мы добавили в курс итоговый проект: студентам нужно будет выполнить практическое задание под звёздочкой с применением знаний, полученных на курсе.


Мы добавили два варианта заданий из области разработки и из области администрирования. В первом варианте понадобится создать приложение для генерации real-time статистики продаж интернет-магазина, а во втором спасти кластер от хаоса.


Подробнее о курсе
Бесплатные материалы курса

Подробнее..

9 трендов развития унифицированных коммуникаций в 2021 году

20.04.2021 10:21:38 | Автор: admin

Многие бизнес-аналитики уверены, что даже после возврата общества и бизнеса к относительно нормальной жизни после пандемии COVID-19, рост рынка унифицированных коммуникаций уже не остановить. Конечно, трудностей не избежать, но уже сейчас очевидно, что за 2020 год и владельцы компаний, и рядовые сотрудники нашли немало преимуществ в дистанционном режиме работы.


Глобальное внедрение UCaaS


Один из главных трендов UC рост популярности UCaaS. Крупные компании делают инвестиции в унифицированные коммуникации как в готовую систему бизнес-коммуникаций. Это связано с тем, что UCaaS объединяет в облаке основные каналы и платформы связи (голос, видео, чат, электронную почту и пр.). По мнению экспертов, к 2024 году рынок UCaaS будет оцениваться примерно в $79 млрд.


UCaas-complete-guide.jpg

Растущее влияние технологий искусственного интеллекта


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


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




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

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




Больше облачных решений


Сегодня все большее число компаний использует облачные решения для хранения, обработки и передачи различных данных. Согласно исследованию, проведенному Nemertes в 2019 году, около 67% компаний используют облако как часть системы UC (треть из этого количества использует облачные решения для создания полнофункциональной системы бизнес-коммуникаций). Это заставляет поставщиков услуг искать возможности для партнерства и интеграции, создавая комплексные облачные решения.


Что касается российского рынка, несмотря на ограничения регуляторов и сложности, с которыми неизбежно сталкивается любая компания, взявшая курс на цифровизацию, в среднесрочной перспективе распространение облачных решений возрастет. Крупнейшие игроки рынка ожидают, что по итогам 2021 года продажи облачных решений в России вырастут на 25%.


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


Переход с аналоговых устройств на SIP


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


API и частные разработки


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


Рост числа отраслей-пользователей унифицированных коммуникаций


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


tele.png

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


На российском рынке появились такие телемедицинские сервисы, как совместный проект Здоровье Mail.ru и ONDOC, СберЗдоровье, решение для удаленного мониторинга состояния здоровья от Мегафон.


По мнению экспертов РАЭК, это связано не только с пандемией COVID-19, но и с готовящимися изменениями в законодательстве, которые стимулируют развитие этого рынка.




В частности, планируется определить режим использования обезличенных наборов данных о состоянии здоровья с целью создания алгоритмов и методов машинного обучения для систем поддержки принятия врачебных решений. В Москве уже с 01 июля 2020 года действует экспериментальный правовой режим, облегчающий использование обезличенных данных о состоянии здоровья для компаний-участников эксперимента. В ближайшее время ожидается выход постановления Правительства о проведении эксперимента по обеспечению удаленного взаимодействия медицинских работников с пациентами.
Источник: РАЭК, Тренды 2020 года: сбылись ли прогнозы?




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


Рост числа сценариев совместного использования различных устройств


В ближайшие несколько лет можно прогнозировать значительный рост сценариев взаимодействия различных устройств. Это связано с введением новых телекоммуникационных стандартов, таких как 5G и Wi-Fi 6, а также с развитием IoT. Для обеспечения межотраслевой совместимости потребуются новые технические, программные и аппаратные решения.


Выбор альтернативных каналов и инструментов коммуникации


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


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


BYOD.jpg

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


Геймификация


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


Заключение


По данным исследования РАЭК, НИУ ВШЭ и Microsoft (Новые акценты цифровой трансформации: как весна 2020 повлияла на российский бизнес), 54% российских предприятий и компаний, принявших участие в опросе, перешли на удаленный режим работы полностью или частично (до весны 2020 года менее 1%). 17% опрошенных в ходе исследования представителей российских компаний считают, что часть их персонала останется на удаленке. При этом полный переход на дистанционную работу пока останется исключением: лишь 2% участников исследования считают такую перспективу реалистичной.


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


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

Подробнее..

Мониторинг в ЦОДе как мы меняли старую BMS на новую. Часть 4

20.04.2021 16:13:49 | Автор: admin

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

Следующей задачей на пути развития системы стал вопрос ее настройки: как сделать так, чтобы работать с новой системой было удобно, а сама она была бы максимально информативной?

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

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

В этой части мы поделимся практическим опытом настройки нашей системы мониторинга работы ЦОДа.

Немного теории

Собираемые системой SCADA переменные делятся на телесигнализацию и телеизмерения учили меня когда-то в институте. И на самом деле ничего не поменялось: телесигнализация это состояние устройства, например, нет аварии, есть авария, открыт, закрыт и т. д.

А телеизмерение, как нетрудно догадаться, это цифровое значение какого-либо параметра, например 220 Вольт или 10 Ампер.

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

Аварии по показателю приоритетности обычно делятся на три основных типа: Красная, Желтая и Голубая. Красные аварии требуют немедленных действий сотрудников, Желтые о чем-то их предупреждают, Голубые чаще всего сообщают о каких-то некритичных событиях. Например, мы вывели Голубые аварии из сводки, которую видят дежурные, и используем их для мониторинга различных коммерческих параметров (превышение заказанной мощности). Отчеты по этим авариям направляются только менеджерам и не отвлекают дежурных.

Для удобства настройки однотипного оборудования переменные в разных устройствах, но с одним именем (например, OutputCurrent) имеют одинаковые настройки на всех устройствах системы. Если мы меняем уставку в одном месте она меняется везде.


Когда какое-то устройство требует индивидуальных настроек у требуемой переменной, мы применяем специальную отметку Только для этого устройства. Теперь переменная стала индивидуальной для одного конкретного устройства, имеет свою уставку и не влияет на другие одноименные переменные.

Дополнительно в самих устройствах есть собственные заводские уставки. Например, в PDU с завода настроено распознавание аварийной ситуации на превышение тока в 32А. В случае ее срабатывания от PDU поступит оповещение о типе аварии Overload Alarm. И это совсем другая переменная, не связанная с переменной OutputCurrent, настроенной в BMS.

Пример заводских настроек уставок внутри PDU:


Итак, мы перечислили основной функционал для настройки системы мониторинга.

Как же правильно настроить это пианино? Давайте рассмотрим задачи по порядку.

Чего мы хотим добиться

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

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

Этап 1. Определение нужных и ненужных переменных у каждого устройства

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

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

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

  • Лишние переменные загружают оперативную задачу системы мониторинга и увеличивают размер архива, система вынуждена обрабатывать и сохранять ненужные данные.

  • Чем больше опрашивается переменных, тем выше вероятность сбоя опроса. Особенно это актуально для устройств, подключенных по шлейфу (например, через шлюз по протоколу MODBUS). Это приводит к получению состояний нет данных (Н/Д) или обрыв связи, то есть фактически устройство периодически выпадает из мониторинга.

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

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



Заводские уставки внутри устройств по нашему опыту на начальном этапе лучше не трогать (конечно, если они не сообщают вам уже об аварии). Однако на каждой тренировке по конкретному оборудованию следует напоминать сотрудникам о наличии уставок и в самом устройстве, и в BMS. Это в будущем поможет дежурным точно понимать, что именно является причиной аварийного сообщения.

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

Делать это должен не наладчик системы, а сотрудник, понимающий работу системы, которую контролирует система мониторинга, желательно главный инженер или главный энергетик.

Этап 2. Минимизация ложных и неинформативных сообщений

Ложные срабатывания часто происходят из-за сбоев в опросе устройства. Если сетевая карта устройства не снабжена автономным питанием, то и сбой в опросе и реальное отключение питания будут отображаться как один тип аварии обрыв связи.

В этом случае надо разделить оборудование на критическое (например, PDU) и обычное (например, щиты вентиляции ЩУВ). Для обычного оборудования можно установить задержку на сигнал обрыв связи (например, 300 секунд) тогда большинство ложных обрывов будут игнорироваться.

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

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

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

Для оптимизации количества сообщений при переходе на ДГУ следует:

  • настроить на штатно появляющиеся во время перехода аварийные сигналы более длительные временные задержки, чем время появления питания от ДГУ. Например, установить задержку на сигнал обрыв связи щита вентиляции 300 секунд при штатном времени перехода на ДГУ 200 секунд.

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

  • проанализировать сообщения от ИБП при переходе на ДГУ и разделить их на нормальные с присвоением им желтого типа (например, констатация факта нет питания на вводе) и ненормальные (отключение батарейного автомата, которого быть не должно в любом режиме работы), с присвоением им красного типа.

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

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

Например, нам потребовалось наблюдение за 4-5 переходами для приемлемой настройки новой BMS. Чтобы проанализировать внеплановый процесс перехода, мы делали запись экрана системы мониторинга, так как важно наблюдать аварийные сообщения не в архиве событий, а анализировать появление аварий в динамике оперативной сводки.

Этап 3. Дополнительные советы из нашего опыта

1.На экранах дежурной смены не должно быть лишней индикации в цветах аварийных сообщений.

Пример из реальной практики. Один ЦОД заказал карту температурных потоков в серверной. Это 3D модель потоков воздуха с множеством температурных данных с датчиков. Получился вид северной с потоками воздуха где-то воздух был выделен зеленым, где-то желтым и красным (от самого холодного к самому горячему). При этом температуры воздуха везде в пределах нормы, а цвета применены только для наглядности отображения разницы температур в разных точках.

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

Наверное, дежурным объяснили, что на левом экране красное/желтое это нормально, а на правом экране эти же цвета сигнал к действию. Однако ясно, что такая практика очень серьезно увеличивает риск человеческого фактора.

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

2. С осторожностью используйте SMS-оповещения.

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

3. Настраивайте дублирование сообщений об авариях через мессенджер.

Это можно реализовать, например, через Microsoft Teams или Telegram. Сообщения об авариях будут приходить и вам, и дежурным, при этом телефон будет издавать звуки и вибрировать (чего нет при работе с системой через браузер).

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

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

4. Группируйте сообщения в мессенджерах.

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

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

5. Ярко выделяйте в интерфейсе сообщение о пропадание связи с сервером.

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

На скриншоте пример индикации о пропадании связи с сервером BMS, при этом отображаются неактуальные параметры работы оборудования.


6.Подключайте к мониторингу как можно больше систем.

Например, традиционно система пожарной сигнализации работает автономно, а ее панель висит на посту охраны.

Да, по сигналу ПОЖАР срабатывают автоматические алгоритмы работы систем, запускается система оповещения, но о появлении сигналов Неисправность или Внимание сотрудник охраны сообщает дежурным голосом.

Полноценно подключить к мониторингу такую систему очень сложно, но в такой системе легко настроить три релейных сигнала неисправность, внимание и пожар, а затем подключить их сухими контактами в модуль системы BMS.

Тем самым снижается риск пресловутого человеческого фактора. Пример тестового сигнала ПОЖАР в системе BMS ЦОДа, подключенного через сухие контакты.


Подведем итоги нашей 4-серийной истории

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

Пройдя довольно трудный и длинный путь, мы получили:

  • быструю и стабильную систему мониторинга, которая на данный момент контролирует более 2500 устройств и обсчитывает около 10000 виртуальных датчиков;
  • резервирование системы на платформе облачных решений Linхdatacenter в Санкт-Петербурге и Москве;
  • доступ к системе из любой точки мира через веб-интерфейс, с дополнительной отправкой сообщений из системы на любые мессенджеры, что позволило сократить максимальное время информирования персонала об аварии до 1 минуты;
  • ощутимую экономию, так как система обошлась в разы дешевле аналогов, легко масштабируется и не требует платы за лицензии для устройств или пользователей;
  • надежное решение, которое позволило нам не только улучшить собственные процессы, но и предложить новый коммерческий продукт нашим заказчикам гибко настраиваемую и масштабируемую систему мониторинга.
Подробнее..

Категории

Последние комментарии

© 2006-2021, personeltest.ru