Роборука

Привет.

Собрал игрушку, делюсь с вами.

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

Каждая тяга «сухожилие» сделаны из 2мм стальной проволоки, на кончике просверлены, и крепится в пальце проволокой от скрепки. Саморезы 2.5мм 16мм (причем при сборке пальцев укорачивал) покупал в Леруа.

3Д модели лежат тут.

Изначально хотел сделать пальцы более «человечные», и печатать за раз целиком палец (печатал HIPS), но в итоге не получилось, склеились у меня детали. Разрезал каждый палец чтобы печатать по отдельности, но сборка получалась сложной. Были и другие варианты, в том числе и с шприцами, точнее с них я и начинал. Были и из металла. С мягкими сухожилиями и резинками для возврата в разогнутое положение. Не все 3Д модели остались, поудалял за ненадобностью.

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

Никакого отношения к протезам не имеет!

ссылка на оригинал статьи https://habr.com/ru/post/490424/

Новостной агрегатор за две недели

18 ноября Telegram запустил соревнование по кластеризации данных: Data Clustering Contest. Нужно было за две недели сделать свой новостной агрегатор. Ограничения, которые были установлены в этом соревновании отпугнули кучу людей, но не меня и моих коллег. Я расскажу от том, каким путём мы прошли, какие выборы сделали и с какими сложностями столкнулись. Решение, которое мы заслали в соревнование обрабатывало 1000 документов за 3,5 секунды, занимало 150 Мб, заняло 6 место на публичном голосовании и 3 место в итоговых результатах. Мы допустили много ошибок, из-за которых не заняли место повыше, большинство из них сейчас исправлены. Весь код и все модели можно найти в репозитории. Все скрипты для обучения моделек перенесены на Colab.

Топ из публичного голосования
Топ из публичного голосования

Задача

Официальное описание соревнования лежит здесь.

Там 5 подзадач:

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


Подзадачи конкурса в порядке выполнения

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

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

Ограничения:

  • максимальный вес архива с решением: 200 Мб (а позже 1.5 Гб)
  • минимум 1000 документов в минуту
  • 2 недели со старта до конца соревнования
  • запускается через бинарник на Debian GNU/Linux 10.1, можно устанавливать любые пакеты для этой конфигурации

Ограничение на скорость довольно слабое, 1000 документов в минуту можно получить практически для любой системы, кроме совсем уж тяжёлых и неповоротливых моделей. Главным тут является ограничение на вес архива: изначальные 200 Мб отсекали многие свежие наработки в области обработки естественных языков, в том числе почти любые предобученные векторы (готовые word2vec, fasttext, GloVe, для русского тут) и предобученные ULMFiT/ELMo/BERT. Это не означает, что их вообще нельзя использовать. Их нужно было бы учить с нуля с урезанным числом параметров или дистиллировать текущие модели, что за 2 недели та ещё задачка.

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

Выбор стека

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

Я знаю, что некоторые писали на Go, и это, вероятно, хороший выбор. Мы же люди привычные к C++, к тому же многие библиотеки для машинного обучения вроде как имеют версии под него, поэтому мы остановились на нём. При этом никто не мешает обучать модели на Питоне, что мы тоже сделали. Использовали C++11, выше не брали из-за зависимостей.

C точки зрения NLP, мы решили застрять в 2016 году и ограничиться FastText’ом. Могли бы застрять и ещё раньше, используя только TF-IDF, но это, как ни парадоксально, было бы даже сложнее и, скорее всего, не так эффективно. FastText — это такой word2vec с добавкой из буквенных n-грамм, которые позволяют ему получать осмысленные векторы для слов не из словаря. Предобученная ELMo для русского весит 197 Мб, предобученный BERT — 632 Мб, поэтому это неподходящие варианты для этого соревнования (по крайней мере так было в начале). Кроме того, FastText доступен под C++ и без проблем статически линкуется.

По-хорошему нам бы нужен был хороший токенизатор. Но лёгких решений на момент соревнования как будто бы не было, в итоге мы просто делили по пробелам (что неправильно, не делайте так!). Уже после контеста мы нашли токенизатор из OpenNMT, и сейчас его используем. Его главная особенность в том, что он поддерживает и C++, и Python, а значит не будет никакой разницы между обучением и применением. А ещё он достаточно быстрый.

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

У нас была мысль попробовать использовать какой-нибудь фреймворк для глубокого обучения: TensorFlow, Torch, MXNet. “TensorFlow написан на C++, это будет легко” — думали мы. Во-первых, это легко до тех пор, пока вы не попытаетесь его статически влинковать. Во-вторых, итоговый бинарник банально не влезет в 200 Мб. Есть ещё Tensorflow Lite, но до него уже руки не дошли. Примерно такие же разочарования ждали нас со всеми фреймворками.

Поэтому мы решили делать проще и перемножать матрицы самостоятельно. Естественно, мы не настолько сумасшедшие люди, чтобы перемножать их полностью самостоятельно. Тут мы большого сравнения библиотек не делали, взяли Eigen, который был на слуху и делал свою работу без нареканий. Для обучения использовали Keras, потому что у нас простая модель, без кастомных слоёв и лоссов, иначе бы использовали Torch (его и использовали в более поздних экспериментах). Плюс тут сыграли личные предпочтения одного из участников команды.

В итоге вышло так:

  • Применение: C++, FastText, OpenNMTTokenzer, Eigen
  • Обучение: Python, FastText, OpenNMTTokenzer, Keras

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

Решение

Для определения языка использовали готовую модель от команды FastText’а почти без изменений.

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

Для определения категорий собрали разметку в Толоке. Собирали обучающую и тестовую выборку. Для этого написали инструкцию, завели обучение, экзамен и ханипоты. Обучающая выборка собиралась с перекрытием 3 и согласованностью 2/3, тестовая с перекрытием 5 и согласованностью 4/5. Скрипты для агрегации умеют считать согласованность толокеров, она вполне приличная. К примерам на английском добавляли машинный перевод на русский. Потратили 60$ на всё. Данных получилось не очень много, для русского языка было 327 примеров в тестовой разметке и 1176 примеров в обучающей, категории были не сбалансированы. Для хорошей разметки стоило бы потратить в 3-4 раза больше денег.

Кроме нашей разметки, использовали категории из внешних датасетов. Для русского брали категории и теги Ленты, для английского BBC и News categories. При этом категории из этих внешних датасетов нужно было отобразить в категории соревнования.

Посчитав размеры на коленке, решили сделать свои предобученные FastText векторы. Предобучали на части данных из соревнования и на открытых новостных корпусах: Лента и РИА для русского; BBC, All the news, News categories для английского. Так сделано, чтобы словарь и сама модель не были завязаны на конкретный временной период.

На разметке обучили классификатор через supervised режим FastText’а с использованием предобученных векторов и заданного размера классификатора (опции семейства autotune). Supervised режим — это просто линейная модель над усреднением всех векторов слов, можно было бы сделать сложнее, и в этом месте получить качество чуть лучше.

Классификаторы
Данные для обучения классификаторов категорий

Для хорошей кластеризации принципиально нужны 2 вещи: хорошие векторы и хороший алгоритм. В качестве векторов сначала пробовали просто усреднение векторов всех слов текста, получалось не очень. В итоге учили линейную сиамскую сеть над усреднением (а также покомпонентным минимумом и максимумом) векторов слов на задаче предсказания следующего кусочка текста. То есть брали доступные тексты, делили их пополам, над каждой половинкой делали линейный слой с связанными весами, делали скалярное произведение получившихся векторов, а потом домножали на циферку и прогоняли через сигмоиду. Использовали логлосс, в качестве единиц брали половинки одного текста. А в качестве ноликов левую половинку от одного текста, а правую — от хронологически предшествующего текста того же источника (такие вот hard-negative примеры). Вот таким способом получились уже более адекватные (на глаз) векторы. Ещё адекватнее было бы делать более сложную архитектуру половинок и использовать triplet loss. Модель строили и учили на Keras’е, но ничего не мешало это делать и на Torch’е. Веса линейного слоя экспортировали в применялку через обычный текстовый файлик.

Модель для обучения векторов
Модель обучения векторов для кластеризации

Ежели вы спросите, а как бы мы это делали, если бы ограничений не было, так тут всё просто. Тут применимы все модели, которые обычно используют для определения парафраз, например дообученный BERT. Это бы работало, будь у нас разметка. А вот в наивном unsupervised варианте я бы ставил на ELMo. Более того, с ELMo у нас есть эксперимент.

В качестве алгоритма взяли SLINK: агломеративную кластеризацию за O(n^2) и вычислением расстояния как минимума между точками двух кластеров. У такого способа есть свои недостатки, самый главный из них — подклейка по транзитивности: первая точка склеивается со второй, вторая с третей, а в итоге первая и третья в одном кластере, хотя сами по себе далеко друг от друга.

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

При этом O(n^2) для всех документов за месяц — это слишком долго. Есть несколько вариантов решения этой проблемы, нам известны два: отбор кандидатов и склейка. Мы пошли вторым путём, отсортировали по времени весь массив входных документов и разбили на чанки из 10000 документов с перехлёстом в 2000 документов. Кластеризовали чанки по отдельности, по перехлёсту склеивали. Это работает только потому, что вряд ли далеко отстоящие по времени документы принадлежат одному кластеру.

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

Ранжировали кластера тоже по 3 факторам: свежести, весу источника, размеру кластера.

Ошибки

  1. Опечатались в названии одной из категорий.
  2. Неправильно выбрали процентиль для “текущего” момента времени, из-за чего на первом английском тестовом датасете вперёд выходили документы из “будущего”.
  3. Плохо обучили категории для английского, из-за чего была низка полнота для некоторых категорий, в частности для науки.
  4. Не парсили вложенные теги, из-за чего тексты некоторых документов были неполными.
  5. При обучении линейного преобразования для векторов кластеризации мы изначально использовали только тексты из датасетов соревнования, из-за чего модель хуже обобщала, и много кластеров распадалось.
  6. Закрутили в точность порог кластеризации
  7. В некоторых местах некорректно обращались с числами с плавающей запятой, из-за чего немного разъехалось ранжирование документов внутри кластера и ранжирование кластеров.
  8. Использовали std::sort вместо std::stable_sort, из-за чего получались невоспроизводимые результаты.
  9. Не сделали нормальную токенизацию сразу, из-за чего потеряли пару процентов точности в категоризации и немного в качестве кластеризации.
  10. Не написали тесты вовремя, из-за чего произошла часть из описанных выше ошибок.

Итоги

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

Чего же не хватает этой штуке до полноценного новостного агрегатора?

Во-первых, rss-качалки или любого другого способа получить документы на вход. Telegram в этом плане очень сильно считерил — вероятно всё, что проходит через его Instant View, сохраняется у него же на серверах. Данные соревнования получены именно таким образом. Вопрос о правовом статусе таких действий остаётся открытым.

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

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

На текущую версию можно посмотреть вот тут, на версию с контеста вот тут.

ссылка на оригинал статьи https://habr.com/ru/post/487324/

Как построить ЦОД Tier IV по схеме N + 1

Системы ИБП с изолированно-параллельной шиной (IP-Bus) – ответ разработчиков на рост мощностей дата-центров. В мире уже построено много ЦОДов с IP-Bus, в том числе с сертификатом Tier IV Uptime Institute. К таким решениям присматриваются и российские заказчики.

В практике строительства ЦОДов наблюдается устойчивый тренд на их укрупнение. В мире появились объекты мощностью 100 МВт. Россия так же не остается в стороне, хотя и следует в данном направлении с некоторой задержкой. Еще 10 лет назад в нашей стране крупным считался дата-центр мощностью 5 МВт, а сегодня несколько ведущих операторов заявили о планах строительства объектов на 2000 и более стоек, что соответствует энергопотреблению 15 МВт и выше.

Для организации инженерных систем большой мощности, как показала мировая практика, наиболее целесообразной с экономической точки зрения является схема с параллельным N+x (N+1, N+2…) подключением устройств. Причем, единичная мощность самых больших в мире установок ИБП — динамических, которые можно применять в таких решениях, ограничивается мощностью (и стоимостью) самых больших дизельных двигателей, используемых для работы с ИБП.

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

  • Низковольтные установки можно применять только в системах до 5 МВт. Это связано как с ограничениями по доступным номиналам низковольтных комплектных устройств (6300 А), так и с высокими токами короткого замыкания, значения которых могут превышать 150 кА.
  • Решения на средневольтном напряжении, дающие возможность строить системы свыше 5 МВт, увеличивают стоимость энергосистемы и не всегда устраивают заказчиков в части эксплуатации.
  • Общие компоненты системы – входная и выходная шины, байпас – являются общими точками отказа.


Схема N + N (2N), отвечающая уровню отказоустойчивости Tier IV Uptime Institute, дает возможность путем строительства отдельных энергомодулей уйти от основных недостатков классических параллельных систем. Но такой подход обладает другими очевидными недостатками:

  • 100%-ное дублирование оборудования, т.е. высокие капитальные затраты;
  • большая занимаемая площадь;
  • максимальный уровень загрузки – 50% (на практике – не выше 40%);
  • высокие затраты на эксплуатацию.

В силу указанных причин конфигурация N + N (2N) редко применяется для объектов мощностью свыше 10 МВт.

В 2005 г. было найдено решение, позволившее при сохранении основного преимущества параллельной схемы – оптимального числа модулей ИБП в схеме N + x – реализовать на практике системы мощностью до 20 МВт, оставаясь на низком напряжении 0,4 кВ. Это решение, получившее название конфигурация с изолированно-параллельной шиной (IP-Bus), отвечает самому высокому уровню отказоустойчивости (Tier IV Uptime Institute). В основе идеи IP-Bus – использование кольцевой шины для соединения отдельных модулей ИБП, каждый из которых изолирован с помощью дросселя (рис. 1).

image
Рис.1. Изолированно-параллельное включение ИБП

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

  • позволяет перераспределять активную мощность между ИБП – модуль ИБП с меньшей нагрузкой «помогает» другим модулям, передавая избыток мощности через IP-шину (рис. 2);
  • обеспечивает бесперебойное электроснабжение нагрузки в случае отключения ИБП для сервисных работ или при аварии (рис. 3, рис. 4);
  • замедляет обмен реактивными токами между установками ИБП, за счет импедансов дросселей, так что отпадает необходимость в управлении реактивной мощностью внутри системы.

  • эффективно ограничивает токи короткого замыкания в различных сценариях КЗ (рис. 5).

    Благодаря возможности естественного распределения нагрузки без какого-либо внешнего управления системы IP-Bus, как правило, реализуются в конфигурациях с резервированием N + х (N + 1, N + 2…). Сокращение количества избыточных ИБП до минимума позволяет обеспечить загрузку установок ИБП в системе на высоком уровне — свыше 70%, что делает такие системы очень энергоэффективными.

<img src="" alt=«image»/>
Рис. 2. Пример распределения нагрузки в системе из 16 установок ИБП

В отличие от «прямой» параллельной конфигурации, в системе IP-Bus каждая установка ИБП управляет своим напряжением на выходе независимо от других – отсутствует централизованное устройство управления и исключается общая точка отказа. Если предположить, что поток мощности от одного ИБП по какой-либо причине внезапно пропадает, его нагрузка остается подключенной к IP-Bus с помощью IP-дросселя, который теперь работает в качестве резервного источника питания. При таком сценарии нагрузка будет автоматически и бесперебойно получать питание из шины IP-Bus (см. рис. 3).


Рис. 3. Пример резервирования системы при отказе/выключении одной установки ИБП

На практике шина IP-Bus обычно выполняется в виде кольца, как показано на рис. 4. Второй сегмент IP-Bus, зачастую называемый возвратной шиной (Return-Bus), играет роль резервного источника для нагрузок, позволяя напрямую подключать их к IP-Bus через отдельные выключатели – своего рода байпасы, что обеспечивает номинальное напряжение на нагрузке даже в аварийных ситуациях или при выполнении сервисных работ. Такие байпасы не являются общей точкой отказа, поскольку в начальный момент времени, пока не замкнется байпас, нагрузка бесперебойно продолжает получать питание от шины IP-Bus через IP дроссель как сказано выше.


Рис. 4 Пример работы нагрузки №2 напрямую от резервной шины IP Bus

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

При коротком замыкании на стороне нагрузки ИБП (см. рис. 5) воздействие такого замыкания на всю систему относительно незначительно в силу того, что остающиеся в работе нагрузки изолированы от ИБП посредством двух последовательно включенных дросселей. С другой стороны, ток КЗ, отдаваемый ИБП на общую IP-шину, ограничен сопротивлением IP-дросселя. Поэтому изменения в напряжении на не пострадавших нагрузках незначительны и остаются в безопасной области кривой ITI (CBEMA).


Рис. 5. Пример распределения и величин токов КЗ в системе IP-Bus при КЗ на шине питания нагрузки, подключенной к ИБП 2

В случае короткого замыкания на шине IP-Bus, между точкой КЗ и ИБП или нагрузкой расположен только один IP-дроссель. Поэтому провал напряжения на нагрузках при таком сценарии будет намного больше, по сравнению со случаем КЗ в системе распределения нагрузки. При низком переходном сопротивлении ИБП начальное падение напряжения на нагрузке составит 30%. Для чувствительных блоков питания серверов, в соответствии с кривой ITI (CBEMA), такое падение напряжения допустимо в течение максимум 500 мс. Применение сегментированной направленной защиты, специально адаптированной к требованиям системы IP-Bus, позволяет очищать КЗ на шине IP-Bus в течение 60 мс путем выборочной изоляции очага КЗ и одновременно позволяет той части системы IP-Bus, на которую это непосредственно не влияет, оставаться полностью работоспособной.

Система IP Bus состоит из нескольких установок ИБП, количество которых определяется заданным уровнем резервирования N+x и включает следующие основные компоненты: ИБП с устройством накопления энергии, IP-дроссель для подключения установки ИБП к IP-шине и выключатели, необходимые для безопасной работы системы.

На рис. 6 показан один из вариантов системы IP Bus на базе роторного ИБП.

Элементы системы:

1. Внешняя сеть
2. Шина IP-Bus
3. Возвратная шина IP-Return-Bus
4. Роторный ДИБП с маховиком
5. ДГУ на длительный перерыв сети (опционально)
6. IP-дроссель
7. Обходной переключатель
8. IP-выключатели
9. Нагрузка


Рис. 6. Пример системы IP-Bus с применением роторного ИБП Piller UNIBLOCK и внешнего ДГУ с «нижним» включением

Согласно практическому опыту компании Piller, динамические ИБП с маховиками (рис. 6) в качестве устройств хранения резервной энергии являются идеальным решением для систем IP Bus поскольку кинетические накопители в составе ДИБП могут работать в режиме как мгновенного поглощения энергии, так и мгновенного разряда, что важно для стабилизации рабочих параметров системы IP-Bus при изменениях нагрузки.

Кроме того, мотор-генераторы в составе ДИБП обладают способностью поставлять высокие токи КЗ – до 20 х Inom, что позволяет системам IP-Bus за очень которое время справляться с очисткой КЗ, не подвергая соседние нагрузки негативным воздействиям короткого замыкания.
Статические ИБП с аккумуляторными батареями имеют ограниченные возможности мгновенно отдавать и принимать большие токи, а кроме того, токи КЗ самих ИБП относительно невысоки. По этим причинам решения IP-Bus на статических ИБП – это скорее эксперименты, и в действующих ЦОДах они практически не встречаются.

Первая в мире система IP-Bus была реализована в 2007 г. для ЦОДа мощностью 36 МВт в Эшберне (Вирджиния, США). На объекте были установлены две отдельные системы IP-Bus, каждая из которых включает 16 ИБП Piller UNIBLOCK UBT 1670 кВА с маховиками в конфигурации 14 + 2. На случай длительных пропаданий внешней сети каждый ДИБП резервируется отдельным дизельным генератором 2810 кВА с «нижним включением», который работает как на нагрузки бесперебойного, так и гарантированного электропитания
После успеха реализации первой системы IP-Bus такая конфигурация стала быстро набирать популярность в индустрии ЦОДов. Очередной важной вехой в развитии и признании технологии IP-Bus стало получение австралийским ЦОДом NEXTDC B2 с системой электропитания IP-Bus N + 1 сертификата Tier IV Design & Facility Uptime Institute в сентябре 2017 г.

Российский рынок ЦОДов только входит в этап строительства крупных объектов мощностью свыше 10 МВт. По результатам первых расчетов концепций и бюджетных оценок решений IP-Bus на нескольких проектах ЦОДов в России (в диапазоне мощностей 5—15 МВт) можно сделать следующие выводы. В сравнении с конфигурацией 2N на статических ИБП решения IP-Bus на базе ДИБП не дороже в начальных капитальных затратах, дают выигрыш 30—60% в занимаемой площади, более чем на 50% выгоднее по стоимости владения (ТСО) на отрезке 10 лет. В сравнении с распределенно-резервной конфигурацией N + 1 (DR 3/2, 4/3), реализуемой как на статических, так и на динамических ИБП, решения IP-Bus на базе ДИБП не дороже в начальных капитальных затратах (для ЦОДов мощностью 10 МВт и более), дают выигрыш 20—50% в занимаемой площади, выгоднее на 50% по ТСО на отрезке 10 лет.

Таким образом, уверен, что внедрение систем IP-Bus в российских ЦОДах – лишь вопрос времени.

ссылка на оригинал статьи https://habr.com/ru/post/490434/

Тотальный контроль или свободный график? Введение в корпоративную мобильность

Мобильный телефон в рабочем процессе – это зло или благо? Гаджет позволяет сотруднику оперативнее решать задачи? Или помогает работодателю жестче контролировать подчиненного? Создает креативную обстановку? Или напрягает в 23:00 сообщениями в мессенджере и письмами? Способствует утечке корпоративных секретов или, наоборот, дает страховку от неожиданностей? 

Что такое корпоративная мобильность, каково текущее ее состояние и в чем история этого понятия, разбираемся с нашими партнерами из Научно-испытательного института систем обеспечения комплексной безопасности (НИИ СОКБ).


Источник

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

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

В рамках данной статьи мы затронем тему корпоративной мобильности и рассмотрим её с различных точек зрения — не только маркетинговых и управленческих, но и с позиции «полевого» сотрудника.  

Чтобы сделать повествование более предметным, мы взяли интервью у наших коллег из НИИ СОКБ, которые имеют большой опыт в подобного рода проектах и готовы поделиться примерами, историями и наблюдениями из своей практики (теория теорией, но в жизни всё всегда сложнее и интереснее ).

НИИ СОКБ специализируется на обеспечении комплексной безопасности и охраны труда, а также является разработчиком SafePhone – решения для централизованного управления мобильными устройствами, приложениями, контентом и коммуникациями в организации. Мы пообщались с главным инженером НИИ СОКБ Олегом Ассуром о том, что такое корпоративная мобильность и какие решения существуют в этой области.

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

«Мобильной» тематикой мы занимаемся достаточно давно (уже более 10 лет — можно сказать, стояли у истоков), поэтому в становлении данного IT-направления мы участвовали с самого начала.

Более-менее заметно «мобильные» начали проявляться в «лихие 2000-е» (сами устройства, конечно, существовали и раньше, но это была штучная история, которая не имела массового характера). Тогда они использовались в основном для совершения звонков и пересылки текстовых сообщений. Сотрудникам они выдавались с комментарием: «Чтоб всегда был на связи, и не вздумай звонить в Америку!». Уже существовали «умные телефоны» (привычное сейчас «смартфон» звучало достаточно футуристично), но они не играли большой роли в корпоративной среде, и в большинстве компаний сотрудники продолжали использовать для своей работы привычные им компьютеры.

Переломный момент, на мой взгляд, произошёл в середине нулевых, и связан он с двумя событиями: покупкой в 2005 году Google Android, Inc. с последующим запуском одноимённой платформы и анонсом в 2007 первого iOS-устройства (тогда ещё с iPhone OS). Обе эти платформы сразу предлагали богатый функционал помимо звонков и SMS и быстро начали вытеснять классические кнопочные телефоны.

Естественно, счастливые обладатели этих устройств начали использовать их и в работе: иногда с одобрения руководства, иногда «подпольно». Это привело к возникновению тенденции, при которой устройство постепенно накапливает важную корпоративную информацию (подключили почту – появилась конфиденциальная корпоративная переписка, разрешили доступ к CRM – к переписке добавился список клиентов и т.д.). Потеря или кража гаджета становится всё более значимым риском для компании. Именно в этот момент и начинается история систем централизованного управления корпоративной мобильностью, в том числе и нашей платформы SafePhone.

Какова роль мобильного устройства в бизнесе в настоящий момент?

Сегодня мобильное устройство – настоящий кухонный комбайн, который может выполнять множество разных функций. На мобильных устройствах есть полноценные офисные пакеты (а это, наверное, основной инструмент для 90% сотрудников компаний). Хотя стоит отметить, что такой сценарий использования ограничен, а ПК всё-таки остаются основным средством работы с документами. 


Источник: Broadcom

Вообще, сейчас наблюдается интересная картина. С момента зарождения IT считалось, что для полноценной работы сотрудникам нужен настоящий, большой компьютер или ноутбук, но обязательно с полноценным x86-процессором. Попытки сдвинуть эту ситуацию с мёртвой точки всегда упирались в железобетонный аргумент из серии: «у нас есть системы, работающие только под DOS (Windows 95/98, Java 5 — нужное подчеркнуть), вы всё нам поломаете». Надо понимать, что корпоративная среда достаточно консервативна (программисты на COBOL до сих пор востребованы).

Первые подвижки начались с повсеместного внедрения виртуализации и появления VDI (Virtual desktop infrastructure). Внезапно выяснилось, что работать с Legacy-системами можно вообще с любого устройства, лишь бы было защищенное подключение к сети. Сеть, кстати, долгое время и была сдерживающим фактором для развития данной технологии, но, похоже, что и это ограничение скоро будет снято. С появлением нового поколения 5G, не в последнюю очередь благодаря Samsung, предоставляющих связь на скоростях от 1 Гбит/с, через мобильную сеть можно с минимальной задержкой «прогонять» фактически любые корпоративные  типы данных (документы, звук, видео хорошего разрешения). Ещё одним следствием такого «ускорения» также является всеобщая тенденция отказа от «толстых клиентов». Большинство современных бизнес-систем имеет нормальный веб-интерфейс, многие в дополнение к этому выпускают мобильного клиента или мобильную версию веб-интерфейса (которую также можно «завернуть» в приложение с помощь Progressive Web App).

Таким образом, получается, что сейчас, по сути, ничто не мешает работать только на смартфоне или планшете. Это, конечно, пока некоторая перспектива (помним про консерватизм ), но её реализация уже не за горами.

Т.е. получается, что мобильные устройства в будущем могут заменить классические ПК в корпоративной среде?

Постепенно бизнес уходит от системных блоков в сторону чего-то более мобильного. Сначала это были достаточно громоздкие пятикилограммовые лэптопы, работавшие на батарее не более полутора часов (старожилы вспомнят страшные выпирающие части расширенной батареи, которые давали один час к работе и полкило к весу), потом мы перешли на ультрапортативные ноутбуки весом 1,5-1,7 килограмм и временем работы шесть – семь часов, а сейчас уже повсеместно распространены аппараты меньше одного килограмма с 12 часами автономной работы. 

Параллельно с этой «миниатюризацией» обычных компьютеров идёт «увеличение» смартфонов. Сегодняшний телефон обладает достаточно впечатляющими характеристиками: тот же S20 в своей топовой редакции имеет на борту 16ГБ памяти и восьмиядерный процессор, что даже для полноразмерных ноутбуков достаточно прилично.

Конечно, самый главный вопрос – это софт. Тут всё неоднозначно. Многие производители пробовали адаптировать десктопный интерфейс к использованию в мобильном окружении (touch, сравнительно небольшие экраны и прочие атрибуты мобильности), но идеальных решений пока, к сожалению, нет: возвращаемся к той самой пресловутой консервативности; никто не будет переписывать интерфейс на Delphi двадцатилетней давности. Вместе с тем в нативные мобильные приложения гораздо проще добавить поддержку «резиновых»/перетаскиваемых окошек, что, собственно говоря, и сделала компания Google в Android Nougat. Если интересен пример такого подхода, то можно обратить внимание на Samsung DeX.

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

Как внедрение мобильных технологий влияет на рабочий процесс?

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


Источник: Dilbert, перевод наш

Классически мобильность подразумевает подход «работай, где тебе удобно» (не путать с «работай постоянно» ). Концептуально это означает, что сотрудник может выполнять свои обязанности, не обязательно находясь на рабочем месте, но и будучи в командировке или, например, дома. И делать это он будет так же эффективно, как и в офисе. Помимо этого, упрощаются внутрикорпоративные процедуры: заказать справку 2НДФЛ или согласовать заявление на отпуск можно нажатием одной кнопки на своём смартфоне.

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

Ещё одним стимулом для сотрудников может служить предоставление мобильного устройства. На практике в компаниях распространены различные модели, от предоставления корпоративного гаджета с возможностью персонального использования смартфона (Corporate Owned, Personally Enabled, COPE), до персонального смартфона или планшета с рабочими приложениями (Bring Your Own Device, BYOD). Кстати, BYOD ведет свое происхождение от достаточно известной для тусовщиков аббревиатуры BYOB – bring your own beer – то есть «приходить со своим алкоголем» в описании вечеринки.


Человек, который перепутал BYOD с BYOB. Источник: Timo Elliott

Также возможны некоторые промежуточные варианты, при которых сотрудник может выбрать себе рабочее устройство с частично корпоративной оплатой и перспективой перехода гаджета в собственность через некоторое время (Choose Your Own Device, CYOD).

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

Что такое управление корпоративной мобильностью, и зачем это нужно?

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

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

На заре отрасли выбор всегда делался в сторону ограничений. Это порождало курьёзные ситуации. Сотруднику в качестве поощрения давали возможность установить на своё устройство корпоративную почту. Делалось это с условием применения всех правильных политик безопасности и установки агента для мониторинга потенциальных угроз. Этот агент безальтернативно устанавливал 12-значный цифро-букво-символьный пароль (в особенно изысканных случаях там был ещё словарь запрещённых комбинаций и ограничение по ротации паролей) на всё устройство и начинал собирать всю доступную ему информацию. Помучившись так неделю (при каждой попытке прочитать SMS нужно вводить этот самый пароль), пользователь со злостью удалял почту и забывал про это «поощрение» как страшный сон.


Источник: Dilbert, перевод наш

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

Существует большое количество аббревиатур для систем управления корпоративной мобильностью — MDM, EMM, UEM. Расскажите в двух словах, в чем их различие и как это укладывается в единую концепцию?

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

Mobile Device Management (MDM) – термин, появившийся в конце 1990-х – начале 2000-х, обозначает системы, которые отвечают за управление жизненным циклом мобильных устройств. Под этим обычно понимают следующий функционал:

  • инвентаризация устройств,
  • настройка параметров ОС,
  • управление подключением и отключением устройств от системы (provisioning and deprovisioning) 

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

  • Mobile Application Management (MAM) – управление приложениями.
  • Mobile Identity (MI) – управление учётными данными и доступом.
  • Mobile Content Management (MCM) – управление контентом.

К середине 2010-х данный набор стал стандартом для рынка, и уже не было смысла делить решения на отдельные модули. Тогда появился термин Enterprise Mobility Management (EMM), который обозначал совокупность MDM, MAM, MI и MCM. Данное изменение было зафиксировано отчётом Gartner, опубликованным в 2014 году.

Далее возникла тенденция, о которой мы говорили раньше. Мобильные устройства стали точно таким же рабочим местом, как и классические десктопы и лэптопы, и стало понятно, что управлять ими нужно в едином контуре: больше нет деления на стационарное и мобильное. Это было отправной точкой для появления нового термина Unified Endpoint Management (UEM). Появление UEM было зафиксировано в отчёте Gartner 2018 года.

Источник: ITSMDaily

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

Мы обсудили историю и теорию, давайте перейдём к практическим вопросам. Как теперь мобильное рабочее место может появиться на предприятии? Поделитесь, пожалуйста, опытом в данной сфере.

Любое внедрение – это всегда комплексная история, и двух одинаковых проектов не бывает. Но попробуем сформулировать некоторые общие моменты.

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

Руководство в данном случае может выбрать две стратегии: поддержать (начинанию даётся «зелёный свет», и инициируется проект) или запретить. В последнем случае аргументацией является большой риск утечки («потеряет финансовую отчётность» или «конкуренты подсмотрят в метро через плечо»). Как показывает практика, такой подход не очень конструктивен. Даже если мобильные устройства строго запрещать, сотрудники всё равно будут их использовать «подпольно». Можно применять административные меры (выговоры, взыскания, санкции), но и это не всегда гарантирует 100% результат. И даже если подобного рода ограничения обоснованы, всегда найдётся сотрудник, который нарушит все запреты, и вот именно один этот случай будет иметь колоссальные последствия. Самой правильной стратегией, на наш взгляд, является старый добрый принцип: «не можешь победить – возглавь». Даже более опасная контролируемая среда во много раз лучше бесконтрольной.

Сначала это, как правило, почта (возможность «забирать» её мобильным клиентом), далее идут документы и различные рабочие системы (корпоративный портал, ERP, CRM и пр.). После «укоренения» технологии (когда становится отчётливо понятна тенденция), проектирование внутренних сервисов уже идёт с расчётом на их использование на различных платформах (в т. ч. мобильных).

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

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

  •  Проведение аудита и обследование текущего состояния инфраструктуры до начала внедрения. Это может быть мониторинговое ПО, установленное на конечные устройства с согласия пользователей и собирающее статистику по используемым приложениям и посещаемым сетевым ресурсам. Важна максимальная открытость и корректность в вопросах соблюдения анонимности и неприкосновенности частной жизни сотрудника. Конечная цель данной активности — получить комплексную картину текущей ситуации, а не выявить нарушителей. Хорошо работают разъяснительные семинары с наглядной демонстрацией функционала мониторингового ПО и вовлечение в процесс сбора статистики руководства.
  • Обратная связь. Важно понимать, что происходит с проектом на стороне конечных пользователей. Это может дать ценную информацию об особенностях работы системы и положительно сказывается на отношении сотрудников. Форматы обратной связи могут быть различны: от очных встреч с обсуждением текущих проблем до некоторого опросника, возможно, анонимного, т.к. не все готовы свободно делиться своими впечатлениями. 
  • Рассчитывать ресурсы на итеративный процесс разработки и внедрения. Всё учесть на этапе старта проекта невозможно, поэтому всегда нужно закладывать дополнительные ресурсы на доработку. Многие при внедрении этого не учитывают, из-за чего проекты обрываются где-то в середине.

Два главных вопроса, которые всегда задают при внедрении:

  •  «Я ставлю систему на своё личное устройство, работодатель может читать мои файлы/переписку и будет следить за мной»

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


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

  •  «ИТ-специалист тратит 10 минут на настройку одного корпоративного устройства. Получается, что наш парк в 300 устройств он будет настраивать неделю, больше вообще ничего не делая. Это невозможно»

    Если решать эту задачу «в лоб», то цифры получаются примерно такие (всё, конечно, сильно зависит от каналов связи и других внешних условий). Но есть и альтернативные подходы. В семействе Samsung Knox есть микросервис, называющийся Knox Mobile Enrollment (KME), который позволяет при первом подключении к сети «из коробки» устанавливать на устройство клиент управления и передавать ему настройки для подключения к серверу. Пользователю при этом не требуется совершать никаких действий. Таким образом мы можем существенно сократить участие IT в процедуре развёртывания. Из приятного – сервис бесплатный и он интегрирован в нашу систему.

Давайте теперь поговорим про безопасность. Бытует мнение, что устройства на Android не могут использоваться в корпоративной среде. В качестве основных аргументов приводят недостаточную безопасность и управляемость. Так ли это? Что говорит ваш опыт? 

Это стереотип, но он достаточно устойчивый. Особенно печально, что его влиянию подвержены не только простые пользователи, но и некоторые работники IT и информационной безопасности. 
Нет, сейчас ОС Android достаточно безопасна и очень распространена в корпоративном сегменте. Об этом говорит недавнее исследование, проведённое компанией IDC. Согласно нему 78% мобильных устройств, использующихся в различных компаниях по всему миру, работают под управлением ОС Android.

Отдельно про защищённость устройств Samsung. Согласно последнему рейтингу Gartner, платформа Knox получила рейтинг «strong» в 27 из возможных 30 позиций, что является одним из самых высоких результатов (примечание Samsung: более подробно про платформу Knox мы рассказывали в данной статье).

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

  • Data-at-rest (хранение и работа с данными). Сюда входят те виды угроз, которые связаны с «существованием» данных на конечном устройстве. Примеры:
    • Кража данных. Как мы уже проговаривали, самая большая ценность корпоративного устройства – это данные на нём. Ими нужно управлять даже после потери или кражи устройства. Тут хорошая практика – использование корпоративного контейнера со строгой парольной политикой (возможно, двухфакторной аутентификацией – биометрия плюс пароль). Также правильным подходом является настройка автоматической реакции на подозрительные действия пользователя (несколько некорректных попыток ввода пароля или попытки компрометации устройства). В случае потери или кражи обязательно должна быть возможность заблокировать устройство на очень низком уровне так, чтобы восстановление его работоспособности было невозможно.

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

  • Data-in-transit (передача данных). Сюда включаются все угрозы, связанные с передачей данных. Тут могут быть следующие примеры:
    • Незащищённый трафик. Публичные Wi-Fi точки доступа бывают полезны по время командировок или когда вы далеко от рабочего места, но нужно поработать с большим объёмом данных. При этом, к сожалению, нельзя гарантировать, что канал безопасен, и его не отслеживают злоумышленники. Для борьбы с данным типом угроз обычно используют VPN с автоматической активацией по запуску определённых приложений.

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

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

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

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

В принципе, это очевидные запросы. Но реализовать их удаётся не всегда в силу ограниченных возможностей разных платформ. В своё время в решении данных задач нам очень помог Knox Platform For Enterprise — разновидность платформы Knox для корпоративных задач. KPfE — это набор инструментов (SDK, утилиты, веб-сервисы и аппаратные механизмы устройств), расширяющий возможности стандартной ОС Android в части управления и мониторинга. Удобно, что для использования функционала не обязательно писать много кода, есть вариант использования Knox Service Plugin, который настраивается с помощью OEMConfig (стандартный механизм Android for Enterprise).

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

Напоследок хотелось бы поговорить про российский рынок. Есть ли у проектов, реализованных у нас в стране, какая-то специфика?

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

Ярчайшим примером таких предубеждений является облако. Часто заказчики категорически отказываются от использования этого подхода, аргументируя решение отсутствием доверия к безопасности и надёжности подобных систем. Эта точка зрения, на наш взгляд, сегодня уже неактуальна. «Облачный» не значит «ненадёжный» и «небезопасный». Это доказывается опытом многих крупных компаний, доверивших облакам существенную часть своих бизнес-процессов — Netflix, Spotify, и целый ряд других. 

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

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

(от автора) Мы надеемся, что нам удалось развеять некоторые «страшилки», и уж по крайней мере теперь станет ясно, что в жизни всё несколько сложнее, чем в этом комиксе:


Источник: Dilbert

Задавал вопросы:
Владимир Карачаров,
Manager, B2B Pre/Post Sales
Business Development Team
Samsung R&D Institute Russia

Отвечал:
Олег Ассур, 
Главный инженер
НИИ СОКБ

ссылка на оригинал статьи https://habr.com/ru/company/samsung/blog/490436/

Контролируем сеть с помощью Raspberry Pi

Привет, Хабр! Представляю вашему внимаю перевод статьи из журнала APC.
""
Безопасность сети – неотъемлемое условие для обеспечения целостности ваших данных и аппаратного оборудования. Несомненно, брандмауэр на маршрутизаторе и средства защиты ПО необходимы, однако, чтобы знать больше о том, что происходит в сети, нужно иметь инструмент для её наблюдения и контроля.
Может показаться, что средство для мониторинга сети, которое бы посылало сигналы компьютеру о попытке взлома, является лишь элементом сюжета фантастического фильма, однако такой инструмент имеет место в реальности. По сути это означает, что вы можете быстро узнать, когда устройства, находящиеся в пределах вашей сети, были отключены от Интернета (например, приложения для умного дома или Интернет вещей), и обнаружить неавторизованное подключение к своему роутеру или сетевому аппаратному обеспечению. Всё, что вам потребуется, это одноплатный компьютер Raspberry Pi и программа Nagios.
Программа Nagios, как и одноплатный компьютер Raspberry Pi, доступна в нескольких версиях. Для простоты понимания здесь будут рассмотрены два варианта инсталляции программы: создание образа диска и ручная установка на текущую ОС.
NEMS (Nagios Enterprise Monitoring Server) — корпоративный контрольный сервер Nagios, он устанавливается на Raspberry Pi и доступен по ссылке: bit.ly lxf253nems. Для него потребуется карта памяти ёмкостью по меньшей мере 16 Гб, но лучше всего выбрать 32 Гб. Для работы рекомендуется использовать Raspberry Pi 3B+, хотя подойдёт любая версия, кроме Raspberry Pi1 Model A и Raspberry Pi Compute Module. Заметьте, что пакет NEMS может быть загружен только через BitTorrent. Однако другие образы диска Nagios находятся в свободном доступе. После загрузки пакета используйте инструмент создания образа диска и записи файлов IMG на SD карту.
Как только NEMS будет готов к запуску на одноплатном компьютере, подсоедините Raspberry Pi к роутеру через кабель Ethernet. И хотя сервер может работать через Wi-Fi, Ethernet всё же является более надёжным средством для мониторинга сети. Вставьте SD-карту, запустите Raspberry Pi и дождитесь завершения настройки NEMS. В процессе произойдёт автоматическое изменение размера файловой системы, так что начальная загрузка продлится дольше, чем обычно. С помощью протокола безопасной оболочки (SSH) подключитесь к NEMS, используя nemsadmin в качестве имени пользователя и пароля.
Затем впишите команду:

sudo nems-init

После этого начнётся установка NEMS. На данном этапе нужно будет выполнить региональную настройку, выбрать способ кодировки, создать аккаунт и добавить e-mail адрес, на который будут приходить уведомления. Для этого в браузере на рабочем столе откройте ссылку nems.local (или используйте IP-адрес Raspberry Pi), чтобы начать настройку.

Ручная инсталляция

В качестве альтернативы можно установить Nagios вручную на любую операционную систему для Raspberry Pi, например, Raspbian. Чтобы добиться лучших результатов, начните с чистой инсталляции ОС, затем запустите SSH-сеанс. Для этого сначала обновите базы данных:
sudo apt update && sudo apt upgrade
Перезагрузите устройство:

sudo reboot

Затем установите Nagios:

sudo apt install nagios3

Дождитесь появления диалогового окна, чтобы создать учётную запись администратора, создайте и запишите пароль, потому что он понадобится вам позже. Данный процесс не займёт много времени. После этого вы получите доступ к Nagios с другого устройства через IP-адрес 192.168.1.10/nagios3. Используйте логин nagiosadmin и пароль, созданный раннее, когда потребуется.

Мониторинг сети

После инсталляции Nagios на Raspberry Pi вы получите готовую к запуску систему непрерывного мониторинга. Осталось только настроить её под ваши нужды. Если программа была установлена вручную, то хост-узел конфигурируется через терминал. Для этого нужно создать файл настройки. Для примера, назовём его monitor.cfg:

sudo nano /etc/nagios3/ conf.d/monitor.cfg

Добавьте в него сведения об устройстве, которое вы хотите отслеживать. Допустим, у вас имеется сервер Minecraft на Raspberry Pi. Введите следующие команды:

define host {
use generic-host
host_name minecraft
alias minecraft
address 192.168.1.22
}

Команда generic-host здесь является темплейтом. Его можно найти в папке generic-host_nagios2.cfg. Темплейты используются для экономии времени при создании установки для сеанса текущего контроля на устройстве. Для этого вам нужно лишь создать множественные записи, основанные на заданном определении и поменять host_name (имя вычислительного узла), alias (дополнительное имя), и address (IP-адрес) устройства, за которым вы хотите наблюдать.
Нажмите Ctrl-X, чтобы сохранить изменения и выйти, затем перезагрузите Nagios:
sudo service nagios3 reload
Если в процессе настройки возникли проблемы, то нужно проверить сервер на наличие ошибок с помощью команды:

sudo /usr/sbin/nagios3 -v / etc/nagios3/nagios.cfg

Она проверит правильность файлов конфигурации. После этого не забудьте перезагрузить Nagios.
Как правило, мониторинг сети осуществляется через браузер. Вкладку можно оставлять открытой на неопределённое время. Дистанционное наблюдение также можно запустить на рабочем столе Raspberry Pi через VNC (система управления удалённым компьютером).
Помимо терминала, Nagios настраивается через веб-браузер. Вам нужно лишь открыть меню настройки и конфигуратор NEMS, а затем добавить описание узла с теми же учётными данными, которые требовались для ручной установки, и необходимые уведомления.
Используйте раздел меню «Отчёты», чтобы следить за работой Nagios. Внешняя часть программы может быть представлена в двух версиях: модернизированный пользовательский интерфейс Adagios и созданный несколько лет назад интерфейс Nagios Core. Оба они полностью пригодны для работы.
Возможности Nagios велики, так что стоит потратить время на то, чтобы ознакомиться с функционалом программы, добавить устройства, проверить журналы сетевой активности, включить визуализацию и т. д. Если вы используете NEMS, то легко можете настроить хост-узел посредством интерфейса браузера таким же образом.
Вот и всё – ваш Raspberry Pi с установленной Nagios готов для мониторинга сети. Он будет работать в фоновом режиме и оповестит вас о любой проблеме с подключением оборудования и подозрительной активности в пределах вашей сети.

ссылка на оригинал статьи https://habr.com/ru/post/490446/