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

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

Бесплатная бухгалтерия для одинокого ИП миф или реальность?

23.09.2020 14:17:26 | Автор: admin


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

Какие задачи возникают?


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

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

  • Выставление счетов клиентам и ведение первичной бухгалтерской документации (договоры, акты и т.д.);
  • Финансовый учет и взаимодействие с банками (получение выписок и формирование платежных документов);
  • Правильное совмещение различных режимов налогообложения, например, в случае использования патентов;
  • ККМ и работа с кассой, если в бизнесе вращаются наличные деньги и/или принимаются платежи (наличными и по карте) от физических лиц;
  • Движение товаров и склад;
  • Своевременная уплата налогов и взносов за себя с правильным заполнением всех реквизитов в платежных документах;
  • Ведение КУДиР;
  • Формирование и сдача декларации по УСН (раз в год);
  • Сдача форм в Росстат (по требованию).

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

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

Какие решения предлагает рынок?


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

  • Коробочная версия 1С: Предприятия для малого бизнеса (конфигурация Упрощенка и вот это все). Стоит продукт на первый взгляд недорого, но купить и забыть это не про 1С, потому что на низком старте уже стоит франчайзи с доильным аппаратом в виде договора ИТС. Одинокому ИП он вроде бы не нужен, но иначе не получишь обновлений через портал. За локальную версию 1С платить придется регулярно, смиритесь;
  • Облачная бухгалтерия 1С: ФРЕШ БизнесСтарт или другая конфигурация. Хороший вариант, если у вас есть наемные работники и выделенный (приходящий) бухгалтер, но для одинокого ИП он может оказаться чрезмерным. Из недостатков стоит отметить только необходимость хранить свои данные в чужом облаке и регулярно вносить абонентскую плату, размер которой зависит от набора используемых услуг;
  • Облачная бухгалтерия банка или специализированный бухгалтерский онлайн-сервис. Отдельный сервис закрывает все задачи ИП, но стоит довольно дорого. Предлагаемые банками решения можно получить вместе с расчетно-кассовым обслуживанием, но только на платных тарифах. Как правило возможности бухгалтерии от кредитной организации ограничены, хотя для мелких ИП их будет достаточно. С другой стороны, на рынке появились неплохие бесплатные тарифы на РКО (без бухгалтерии), поэтому отдавать деньги банку за обслуживание счета нет никакой нужды;
  • 1С: ПРЕДПРИЯТИЕ в аренду на виртуальном сервере RuVDS. Этот вариант объединяет преимущества первых двух без их недостатков. Данные будут храниться на VDS клиента, а не в общем облаке. При этом работа пользователей с программой не отличается от локальной, а договор на ИТС для получения обновлений заключать не требуется. Цена довольно демократичная, но если ИП работает сам-один, она может показаться высокой. При наличии наемников, бухгалтеров и сложных бизнес-процессов это лучшее на наш взгляд предложение;
  • Бесплатная версия 1С: Предприятия для iOS/iPadOS и Android. Мобильное приложение решает практически все задачи мелкого ИП, но не умеет интегрироваться с ККМ и системами ЭДО. К тому же учет ведется только на смартфоне или планшете. За продвинутые возможности (включая работу на десктопе через браузер) все равно придется платить, приобретая подписку на облачные решения 1С (все тот же БизнесСтарт);
  • Свободно распространяемые бухгалтерские программы и системы ERP. Сообществу разработчиков СПО похвастать особо нечем. Был когда-то отечественный продукт Ананас, но его поддержка давно прекращена. Иностранные системы сложны в настройке и не учитывают в полной мере специфику российского бухучета.
  • Условно-бесплатные отечественные программные продукты для Windows. Если возможностей мобильной версии 1С: Предприятия вам не хватает, а за настольную или облачную бухгалтерию платить не хочется, стоит остановиться на этом варианте. Учет и отчетность у мелкого одинокого ИП не особенно сложны, поэтому альтернативные продукты заслуживают внимания.

Как сэкономить?


Конкурентов у 1С: Предприятия довольно много. Есть различные системы ERP для крупных компаний, а также простые решения для малого бизнеса. Последние чаще всего условно-бесплатны: покупать придется дополнительные возможности и/или поддержку. Особенно радует, что эти программы можно не только скачать и установить, но и обновлять даром. Вот далеко не полный список альтернатив 1С: ИП УСН 2, Инфо-предприятие, Бизнес Пак и Своя Технология. В смысле функциональности они уступают решениям лидера рынка, но работать с альтернативными программами людям без бухгалтерского образования проще. Для теста мы выбрали первые два варианта за оптимальное сочетание возможностей бесплатной версии, удобства использования, частоты обновлений и стоимости коммерческих лицензий.

Как развернуть?


Условно-бесплатные бухгалтерские программы не особо требовательны к ресурсам и работают даже на Windows XP. Развернуть их можно на локальном компьютере или недорогом виртуальном сервере. Преимущества второго варианта в отсутствии необходимости приобретать и обслуживать оборудование и возможности получить доступ к системе из любой точки планеты, где есть интернет. Используя VDS, нетрудно организовать и многопользовательскую удаленную работу, если вдруг возникнет такая потребность. Дорогие тарифы для этого не требуются: мы проводили все тесты на машине с минимальной конфигурацией и Windows Server 2012.



Дальше нужно скачать выбранный дистрибутив и установить его на виртуальный сервер.

Начнем с ИП УСН 2. Для работы программе потребуется также .NET Framework 2.0 или выше. При годовом обороте до 1 млн. рублей ее можно использовать бесплатно, а при более высоком лицензия стоит 1000 рублей в год. Пользователю доступны функции финансового учета (банковские и кассовые операции), работа с первичными документами, автоматический расчет налогов и взносов, подготовка налоговой отчетности и другие возможности, включая интеграцию с системами ЭДО и банк-клиентом, конструктор договоров и разнообразные справочники. Поддерживается только режим УСН 6% без наемных работников. После запуска программа регулярно проверяет наличие обновлений на сайте разработчика.



Возможности бухгалтерии Инфо-Предприятия гораздо шире, к тому же разработчик предлагает и другие продукты, а в бесплатную поставку входит налоговый учет для разных режимов налогообложения (ОРН, УСН, УСН на основе патента, ЕСХН, ЕНВД), работа с первичными документами, финансовый учет, взаимодействие с банками и касса. Также бесплатно доступен модуль Зарплата, кадровый учет, внутренние отчеты и многомерная аналитика. В бесплатной версии нет возможностей многопользовательской работы, программирования на встроенном языке, а также некоторых дополнительных функций и интеграции с другими продуктами разработчика для комплексной автоматизации предприятия. Детальное сравнение версий доступно на сайте.



Мы посмотрели одну простую программу для ИП на УСН 6% без сотрудников и одну продвинутую разработку, подходящую и для более крупного бизнеса. Вывод прост: в России есть актуальные учетные системы, которыми можно пользоваться бесплатно. Сделаны они неплохо, но чтобы определиться с выбором, предпринимателям лучше развернуть программы самостоятельно. Для тестов рекомендуем использовать наш виртуальный сервер )

Если тема заинтересует читателей блога, мы изучим ее более детально. За кадром осталось немало интересного: интеграция запущенного на VDS бухгалтерского приложения с системами юридически значимого ЭДО, дистанционная сдача отчетности, работа с ККМ и т.д.



Подробнее..

Sysmon теперь может записывать содержимое буфера обмена

21.09.2020 16:09:27 | Автор: admin
О релизе 12 версии Sysmon сообщили 17 сентября на странице Sysinternals. На самом деле в этот день вышли также новые версии Process Monitor и ProcDump. В этой статье я расскажу о ключевом и неоднозначном нововведении 12 версии Sysmon типе событий с Event ID 24, в который логируется работа с буфером обмена.



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

Новое событие содержит следующие поля:

Image: процесс, данные из которого были записаны в буфер обмена.
Session: сеанс, в котором выполнилась запись в буфер обмена. Это может быть system(0)
при работе в интерактивном или удаленном режиме и т.д.
ClientInfo: содержит имя пользователя сеанса, а в случае удаленного сеанса исходное имя хоста и IP-адрес, если эти данные доступны.
Hashes: определяет имя файла, в котором был сохранен скопированный текст (аналогично работе с событиями типа FileDelete).
Archived: статус, был ли сохранен текст из буфера обмена в архивной директории Sysmon.

Пара последних полей вызывают тревогу. Дело в том, что с версии 11 Sysmon может (при соответствующих настройках) сохранять разные данные в свою архивную директорию. Например, Event ID 23 логирует в себя события по удалению файлов и может их сохранять всё в той же архивной директории. К имени файлов, созданных в результате работы с буфером обмена, добавляется тег CLIP. Сами файлы содержат точные данные, которые были скопированы в буфер обмена.

Так выглядит сохраненный файл
image

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

Так выглядит установка Sysmon с соответствующей настройкой архивной директории:
image

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

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

Подведем итог возможностей Sysmon по работе с буфером обмена.

Фиксируются:

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

Не фиксируются:

  • Копирование/вставка файлов с/на локальную виртуальную машину;
  • Копирование/вставка файлов через RDP
  • Вредоносная программа, захватывающая ваш буфер обмена, записывает только в сам буфер обмена.


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

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

Чтобы узнать подробнее про InTrust, прочитайте наши предыдущие статьи или оставьте заявку в форме обратной связи.

Как снизить стоимость владения SIEM-системой и зачем нужен Central Log Management (CLM)

Включаем сбор событий о запуске подозрительных процессов в Windows и выявляем угрозы при помощи Quest InTrust

Как InTrust может помочь снизить частоту неудачных попыток авторизаций через RDP

Выявляем атаку вируса-шифровальщика, получаем доступ к контроллеру домена и пробуем противостоять этим атакам

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows (популярная статья)

А кто это сделал? Автоматизируем аудит информационной безопасности
Подробнее..

Зона доступа 30 способов, которые позволят разблокировать любой смартфон. Часть 1

21.09.2020 16:09:27 | Автор: admin


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

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


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

Насколько обычная блокировка экрана мобильного устройства препятствует извлечению специалистами данных из него, говорит тот факт, что ФБР США заплатило крупную сумму за разблокировку iPhone террориста Сайеда Фарука, одного из участников теракта в калифорнийском городе Сан-Бернардино [1].

Методы разблокировки экрана мобильного устройства


Как правило, для блокировки экрана мобильного устройства используется:

  1. Символьный пароль
  2. Графический пароль

Также для разблокировки экрана ряда мобильных устройств могут использоваться методы технологии SmartBlock:

  1. Разблокировка по распознаванию отпечатка пальца
  2. Разблокировка по распознаванию лица (технология FaceID)
  3. Разблокировка устройства по распознаванию радужной оболочки глаза

Социальные методы разблокировки мобильного устройства


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

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

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

  • при введении десяти неправильных паролей на мобильных устройствах компании Apple данные пользователя могут быть стерты. Это зависит от настроек безопасности, которые установил пользователь;
  • на мобильных устройствах под управлением операционной системы Android может быть использована технология Root of Trust, которая приведет к тому, что после введения 30 неправильных паролей данные пользователя буду либо недоступны, либо стерты.

Способ 1: cпроси пароль


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

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

Способ 2: подгляди пароль


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

Вариантом данного метода является использование записей камер видеонаблюдения, на которых запечатлен владелец, разблокирующий устройство с помощью графического пароля [2]. Описанный в работе Cracking Android Pattern Lock in Five Attempts [2] алгоритм, путем анализа видеозаписей, позволяет предположить варианты графического пароля и разблокировать устройство за несколько попыток (как правило, для этого нужно сделать не более пяти попыток). Как утверждают авторы, чем сложнее графический пароль, тем проще его подобрать.

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

Способ 3: найди пароль


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


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

Способ 4: отпечатки пальцев (Smudge attack)


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


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

Способ 5: искусственный палец


Если устройство может быть разблокировано по отпечатку пальца, а исследователь имеет образцы отпечатков рук владельца устройства, то на 3D-принтере можно изготовить трехмерную копию отпечатка пальца владельца и использовать ее для разблокировки устройства [3]:


Для более полной имитации пальца живого человека например, когда датчик отпечатка пальца смартфона еще детектирует тепло 3D-модель надевается (прислоняется) к пальцу живого человека.

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

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

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

Способ 6: рывок (Mug attack)


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

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

Способ 7: ошибки в алгоритмах управления устройством


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

Примером подхода к разблокировке мобильных устройств, выпущенных ранее 2016 года, является разряд батареи. При низком заряде устройство разблокируется и предложит изменить настройки питания. При этом надо быстро перейти на страницу с настройками безопасности и отключить блокировку экрана [5].

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

Способ 8: уязвимости в сторонних программах


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

Примером подобной уязвимости может быть похищение данных из iPhone Джеффа Безоса, основного владельца Amazon. Уязвимость в мессенджере WhatsApp, проэксплуатированная неизвестными, привела к краже конфиденциальных данных, находившихся в памяти устройства [6].

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

Рекомендация по защите: Нужно обновлять не только ОС, но и прикладные программы, которыми вы пользуетесь.

Способ 9: корпоративный телефон


Корпоративные мобильные устройства могут быть разблокированы системными администраторами компаний. Так, например, корпоративные устройства Windows Phone привязываются к аккаунту Microsoft Exchange компании и могут быть разблокированы ее администраторами. Для корпоративных устройств Apple существует сервис Mobile Device Management, аналогичный Microsoft Exchange. Его администраторы также могут разблокировать корпоративное iOS-устройство. Кроме того, корпоративные мобильные устройства можно скоммутировать только с определенными компьютерами, указанными администратором в настройках мобильного устройства. Поэтому без взаимодействия с системными администраторами компании такое устройство невозможно подключить к компьютеру исследователя (или программно-аппаратному комплексу для криминалистического извлечения данных).

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

Способ 10: информация из сенсоров


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

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

Способ 11: разблокировка по лицу


Как и в случае с отпечатком пальца, успех разблокировки устройства с использованием технологии FaceID зависит от того, какие сенсоры и какой математический аппарат используются в конкретном мобильном устройстве. Так, в работе Gezichtsherkenning op smartphone niet altijd veilig [8] исследователи показали, что часть исследуемых смартфонов удалось разблокировать, просто продемонстрировав камере смартфона фотографию владельца. Это возможно, когда для разблокировки используется лишь одна фронтальная камера, которая не имеет возможности сканировать данные о глубине изображения. Компания Samsung после ряда громких публикаций и роликов в YouTube была вынуждена добавить предупреждение в прошивку своих смартфонов. Face Unlock Samsung:


Более продвинутые модели смартфонов можно разблокировать, используя маску или самообучение устройства. Например, в iPhone X используется специальная технология TrueDepth [9]: проектор устройства, с помощью двух камер и инфракрасного излучателя, проецирует на лицо владельца сетку, состоящую из более чем 30 000 точек. Такое устройство можно разблокировать с помощью маски, контуры которой имитируют контуры лица владельца. Маска для разблокировки iPhone [10]:


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

Рекомендация по защите: не используйте разблокировку по фото только системы с полноценными сканерами лица (FaceID у Apple и аналоги на Android-аппаратах).

Основная рекомендация не смотреть в камеру, достаточно отвести взгляд. Если даже зажмурить один глаз шанс разблокировать сильно падает, как и при наличии рук на лице. Кроме того, для разблокировки по лицу (FaceID) дается всего 5 попыток, после чего потребуется ввод кода-пароля.

Способ 12: использование утечек


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


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

Способ 13: типовые пароли блокировки устройств


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

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


Как видно на скриншоте части рабочего окна программы UFED Physical Analyzer, устройство заблокировано достаточно необычным PIN-кодом fgkl.

Не стоит пренебрегать иными устройствами пользователя. Например, анализируя пароли, сохраненные в кэше веб-браузера компьютера владельца мобильного устройства, можно понять принципы генерации паролей, которых придерживался владелец. Просмотреть сохраненные пароли на компьютере можно с помощью утилиты компании NirSoft [11].

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

Рекомендация по защите: используйте везде разные, уникальные пароли.

Способ 14: типовые PIN-коды


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

Если ничего не помогает можно воспользоваться следующей информацией: исследователи провели анализ и нашли наиболее популярные PIN-коды (приведенные PIN-коды покрывают 26,83% всех паролей) [12]:

PIN Частота, %
1234 10,713
1111 6,016
0000 1,881
1212 1,197
7777 0,745
1004 0,616
2000 0,613
4444 0,526
2222 0,516
6969 0,512
9999 0,451
3333 0,419
5555 0,395
6666 0,391
1122 0,366
1313 0,304
8888 0,303
4321 0,293
2001 0,290
1010 0,285
Применение данного перечня PIN-кодов к заблокированному устройству позволит разблокировать его с вероятностью ~26%.

Рекомендация по защите: проверьте свой PIN-код по таблице выше и, даже если он не совпал, все равно смените его, потому что 4 цифры это слишком мало по меркам 2020 года.

Способ 15: типовые графические пароли


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

Простые паттерны [14]:


Паттерны средней сложности [14]:


Сложные паттерны [14]:



Список самых популярных графических паттернов по версии исследователя Jeremy Kirby [15].
3>2>5>8>7
1>4>5>6>9
1>4>7>8>9
3>2>1>4>5>6>9>8>7
1>4>7>8>9>6>3
1>2>3>5>7>8>9
3>5>6>8
1>5>4>2
2>6>5>3
4>8>7>5
5>9>8>6
7>4>1>2>3>5>9
1>4>7>5>3>6>9
1>2>3>5>7
3>2>1>4>7>8>9
3>2>1>4>7>8>9>6>5
3>2>1>5>9>8>7
1>4>7>5>9>6>3
7>4>1>5>9>6>3
3>6>9>5>1>4>7
7>4>1>5>3>6>9
5>6>3>2>1>4>7>8>9
5>8>9>6>3>2>1>4>7
7>4>1>2>3>6>9
1>4>8>6>3
1>5>4>6
2>4>1>5
7>4>1>2>3>6>5

На некоторых мобильных устройствах, помимо графического кода, может быть установлен дополнительный PIN-код. В этом случае, если не удается подобрать графический код, исследователь может кликнуть на кнопку Доп.PIN-код (дополнительный PIN-код) после ввода неправильного графического кода и попытаться подобрать дополнительный PIN-код.

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

Способ 16: буквенно-цифровые пароли


Если на устройстве можно использовать буквенно-цифровой пароль, то в качестве кода блокировки владелец мог использовать следующие популярные пароли [16]:

  • 123456
  • password
  • 123456789
  • 12345678
  • 12345
  • 111111
  • 1234567
  • sunshine
  • qwerty
  • iloveyou
  • princess
  • admin
  • welcome
  • 666666
  • abc123
  • football
  • 123123
  • monkey
  • 654321
  • !@#$%^&*
  • charlie
  • aa123456
  • donald
  • password1
  • qwerty123

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

Способ 17: облачные или локальные хранилища


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

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

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

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

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

Например, после террористического акта в Пенсоконе копии данных, хранящихся в iCloud, были переданы ФБР. Из заявления Apple:

В течение нескольких часов, после первого запроса ФБР, 6 декабря 2019 года, мы представили широкий спектр информации, связанной с расследованием. С 7 по 14 декабря мы получили шесть дополнительных юридических запросов и в ответ предоставили информацию, включая резервные копии iCloud, информацию об аккаунте и транзакциях для нескольких учетных записей.

Мы отвечали на каждый запрос незамедлительно, зачастую в течение нескольких часов, обмениваясь информацией с офисами ФБР в Джексонвилле, Пенсаколе и Нью-Йорке. По запросам следствия было получено много гигабайт информации, которую мы передали следователям. [17, 18, 19]

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

Способ 18: Google-аккаунт


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

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

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

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

Если устройство в момент исследования не подключено к интернету (например, SIM-карта заблокирована или на ней недостаточно денег), то подобное устройство можно подключить к Wi-Fi по следующей инструкции:

  • нажать иконку Экстренный вызов
  • набрать *#*#7378423#*#*
  • выбрать Service Test Wlan
  • осуществить соединение с доступной Wi-Fi-сетью [5]

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

Способ 19: гостевой аккаунт


На мобильных устройствах под управлением операционной системы Android 5 и выше может быть несколько аккаунтов. Для доступа к данным дополнительного аккаунта может отсутствовать блокировка PIN-кодом или графическим кодом. Для переключения нужно кликнуть на иконку аккаунта в правом верхнем углу и выбрать другой аккаунт:


Для дополнительного аккаунта доступ к некоторым данным или приложениям может быть ограничен.

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

Способ 20: специализированные сервисы


Компании, занимающиеся разработкой специализированных криминалистических программ, в том числе предлагают услуги по разблокировке мобильных устройств и извлечению данных из них [20, 21]. Возможности подобных сервисов просто фантастические. С помощью них можно разблокировать топовые модели Android- и iOS-устройств, а также устройства, находящиеся в режиме восстановления (в которое устройство переходит после превышения количества попыток неправильного ввода пароля). Недостатком данного метода является высокая стоимость.

Фрагмент веб-страницы сайта компании Cellebrite, где описывается, из каких устройств они могут извлечь данные. Устройство может быть разблокировано в лаборатории разработчика (Cellebrite Advanced Service (CAS)) [20]:


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

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

P.S. Об этих кейсах, инструментах и многих других полезных фишках в работе компьютерного криминалиста эксперты Лаборатории Group-IB рассказывают в рамках обучающего курса Digital Forensics Analyst. После прохождения 5-дневного или расширенного 7-дневного курсов выпускники смогут эффективнее проводить криминалистические исследования и предовтращать киберинциденты в своих организациях.

P.P.S. Остросюжетный Telegram-канал Group-IB об информационной безопасности, хакерах, APT, кибератаках, мошенниках и пиратах. Расследования по шагам, практические кейсы с применением технологий Group-IB и рекомендации, как не стать жертвой. Подключайтесь!

Источники
  1. ФБР нашло хакера, готового взломать iPhone без помощи Apple
  2. Guixin Yey, Zhanyong Tang, Dingyi Fangy, Xiaojiang Cheny, Kwang Kimz, Ben Taylorx, Zheng Wang. Cracking Android Pattern Lock in Five Attempts
  3. Дактилоскопический датчик Samsung Galaxy S10 удалось обмануть с помощью отпечатка пальца, напечатанного на 3D-принтере
  4. Dominic Casciani, Gaetan Portal. Phone encryption: Police 'mug' suspect to get data
  5. Как разблокировать телефон: 5 способов, которые работают
  6. Дуров назвал причиной взлома смартфона Джеффа Безоса уязвимость в WhatsApp
  7. Датчики и сенсоры современных мобильных устройств
  8. Gezichtsherkenning op smartphone niet altijd veilig
  9. TrueDepth в iPhone X что это, принцип работы
  10. Face ID в iPhone X обманули с помощью 3D-печатной маски
  11. NirLauncher Package
  12. Анатолий Ализар. Популярные и редкие PIN-коды: статистический анализ
  13. Мария Нефедова. Графические ключи так же предсказуемы, как пароли 1234567 и password
  14. Антон Макаров. Обход графического пароля на Android-устройствах www.anti-malware.ru/analytics/Threats_Analysis/bypass-picture-password-Android-devices
  15. Jeremy Kirby. Unlock mobile devices using these popular codes
  16. Андрей Смирнов. 25 самых популярных паролей в 2019 году
  17. Мария Нефедова. Конфликт между властями США и компанией Apple из-за взлома iPhone преступника усугубляется
  18. Apple responds to AG Barr over unlocking Pensacola shooter's phone: No.
  19. Law Enforcement Support Program
  20. Cellebrite Supported Devices (CAS)

Подробнее..

Opennebula. Короткие записки

20.09.2020 18:23:47 | Автор: admin


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

И так, как видим многие облачные провайдеры работают на kvm и делают внешнюю обвязку для управления машинами. Ясно что крупные хостеры пишут свои обвязки для облачной инфраструктуры, тот же YANDEX например. Кто то использует openstack и делает обвязку на этой основе SELECTEL, MAIL.RU. Но если у вас есть свое железо и небольшой штат специалистов, то обычно выбирают что-то из готового VMWARE, HYPER-V, есть бесплатные лицензии и платные, но сейчас не про это. Поговорим про энтузиастов это те, кто не боится предложить и попробовать новое, несмотря на то, что в компании явно дали понять Кто это потом будет после тебя обслуживать, А мы это что ли в прод потом выкатим? Страшно. Но ведь можно для начала применять данные решения в условиях тестового стенда и если всем понравится, то можно поднять вопрос о дальнейшем развитии и использовании в более серьезных средах.

Также вот ссылка на доклад www.youtube.com/watch?v=47Mht_uoX3A от активного участника развития данной платформы.

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

И так, приступим. Мне как системному администратору важны следующие пункты, без которых я вряд ли буду использовать данное решение.

1. Повторяемость установки

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

2. Мониторинг

Будем мониторить саму ноду, kvm и opennebula. Благо уже есть готовое. Про мониторинг linux хостов есть масса вариантов, тот же заббикс или node exporter кому что больше нравится на данный момент определяю так, что мониторинг системных метрик (температура там где она может измеряться, консистентность дискового массива), через zabbix, а то что касается приложений через экспортер в прометей. По мониторингу kvm например можно взять проект github.com/zhangjianweibj/prometheus-libvirt-exporter.git и поставить запуск через systemd, вполне хорошо работает и показывает метрики kvm, также есть готовый dashboard grafana.com/grafana/dashboards/12538.

Например, вот мой файл:

/etc/systemd/system/libvirtd_exporter.service[Unit]Description=Node Exporter[Service]User=node_exporterExecStart=/usr/sbin/prometheus-libvirt-exporter --web.listen-address=":9101"[Install]WantedBy=multi-user.target

И так у нас 1 экспортер, надо второй для мониторинга самой opennebula, использовал такой github.com/kvaps/opennebula-exporter/blob/master/opennebula_exporter

Можно добавить в обычный node_exporter для мониторинга системы следующее.

В файле по node_exporter меняем старт таким образом:

ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collector

Создаем директорию mkdir -p /var/lib/opennebula_exporter

bash скрипт представленный выше сначала проверяем работу через консоль, если показывает то что надо (если выдает ошибку то ставим xmlstarlet), копируем его в /usr/local/bin/opennebula_exporter.sh

Добавляем в крон задание на каждую минуту:

*/1 * * * * (/usr/local/bin/opennebula_exporter.sh > /var/lib/opennebula_exporter/textfile_collector/opennebula.prom)


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



(видно что тут я сделал overcommit cpu, ram)

Для тех кто любит и использует заббикс, есть github.com/OpenNebula/addon-zabbix

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

К логированию, пока особо не приступал. Как самый простой вариант, это добавить td-agent на парсинг директории /var/lib/one с регулярными выражениями. Например, файлик sunstone.log подходит под regexp nginx и другие файлики, которые показывают историю обращений с платформой какой в этом плюс? Ну например мы можем явно отслеживать количество Error, error и быстрее отследить, где и на каком уровне есть неисправность.

3. Резервные копии

Есть также платные допиленные проекты например sep wiki.sepsoftware.com/wiki/index.php/4_4_3_Tigon:OpenNebula_Backup. Тут мы должны понимать, что просто бэкапить образ машины, в данном случае совсем не то, ведь наши виртуальные машины должны работать с полной интеграцией (тот же контекст файлик, в котором описываются настройки сети, имя vm и кастомные настройки для ваших приложений). Поэтому тут определяемся что и как будем бэкапить. В некоторых случаях лучше делать копии того, что находится в самой vm. И возможно надо бэкапить только один диск от данной машины.

Например мы определились, что все машины запускаются с persistent images следовательно почитав docs.opennebula.io/5.12/operation/vm_management/img_guide.html

значит сначала с нашей vm можем выгрузить образ:

onevm disk-saveas 74 3 prom.qcow2Image ID: 77Смотрим, под каким именем он сохранилсяoneimage show 77/var/lib/one//datastores/100/f9503161fe180658125a9b32433bf6e8   И далее копируем куда нам необходимо. Конечно, так себе способ. Просто хотел показать, что используя инструменты opennebula можно строить подобные решения.


Также в просторах сети нашел интересный доклад и есть еще такой открытый проект, но тут только под qcow2 хранилище.

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

4. Удобство использования

В данном пункте опишу те проблемы с которыми столкнулся я. Например, по образам, как мы знаем есть persistent при монтировании этого образа к vm, все данные записываются в этот образ. А если non-persistent, то копируется образ на хранилище и данные пишутся в то что скопировалось от исходного образа так работают заготовки шаблонов. Неоднократно сам себе делал проблемы тем, что забыл указать persistent и 200 гб образ копировался, проблема в том, что наверняка данную процедуру отменить нельзя, надо идти на ноду и прибивать текущий процесс cp.

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

И тут приходит пониманием, почему opennebula каждый новый инстанс нумерует новым id, например в том же proxmox создал vm с id 101, удалил ее, потом вновь создаешь и id 101. В opennebula такого не будет, каждый новый инстанс будет создаваться с новым id и в этом есть своя логика например, очистка старых данных или не успешных инсталляций.

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

5. Максимальная простота

Конечно тут чем дальше идешь, тем меньше становится тех, кто будет понимать тебя.

В условиях моего стенда 3 ноды с nfs хранилищем все работает в порядке. Но если проводить эксперименты на отключение энергии, то например при запуска snapshot и отключении питания ноды, у нас сохраняются настройки в БД, что есть snapshot, а по факту его нет (ну мы же все понимаем, что исходно записал в sql базу о данном действии, но сама операция прошла не успешно). Плюс в том, что при создании снимка формируется отдельный файлик и есть родитель, следовательно в случае проблем и даже если через gui не работает, мы можем забрать qcow2 файлик и восстановится отдельно docs.opennebula.io/5.8/operation/vm_management/vm_instances.html

По сетям, к сожалению не все так просто. Ну по крайне мере проще чем в openstack, я использовал только vlan (802.1Q) вполне работает, но если вы из template network сделайте изменения в настройках, то данные настройки не применяться на уже работающих машинах т.е. надо удалить и добавить сетевую карту, тогда новые настройки применяться.

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

6. Дополнительные плагины и установки

Ведь как мы понимаем облачная платформа может управлять не только kvm, но и vmware esxi. К сожалению пула с Vcenter у меня не оказалось, если кто пробовал напишите.

В поддержке других облачных провайдеров заявлено docs.opennebula.io/5.12/advanced_components/cloud_bursting/index.html
AWS, AZURE.

Также пробовал прикрутить Vmware Cloud от селектел, но ничего не получилось в общем забил т.к. Много факторов, а писать в тех.поддержку хостинг провайдера нет смысла.

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

7. Положительный опыт использования и дебаг ошибок

Хотел поделится своими наблюдениями по поводу работы, часть описал выше, хочется написать побольше. Действительно, вероятно не я один, кто сначала думает, что эта не та система и вообще тут все костыльно как с этим вообще работают? Но потом приходит понимание и что все вполне логично. Конечно всем не угодить и некоторые моменты требуют доработок.

Например, простая операция копирования образа диска с одного datastore на другой. В моем случае есть 2 ноды с nfs, отправляю образ копирование идет через frontend opennebula, хотя все мы привыкли к тому, что данные должны копироваться напрямую между хостами в той же vmware, hyper-v мы привыкли именно к этому, но тут по другому. Тут другой подход и другая идеология, и в 5.12 версии убрали кнопку migrate to datastore переносится только сама машина, но не хранилище т.к. подразумевается централизованное хранилище.

Далее популярная ошибка с разными причинами Error deploying virtual machine: Could not create domain from /var/lib/one//datastores/103/10/deployment.5 Ниже будет топ, что надо посмотреть.

  • Права на образ для пользователя oneadmin;
  • Права для пользователя oneadminдля запуска libvirtd;
  • А правильно ли смонтирован datastore? Иди и проверь путь на самой ноде, возможно что то отвалилось;
  • Неправильно сконфигурированная сеть, вернее на frontend стоит в настройках сети, что в качестве основного интерфейса для vlan стоит br0, а на ноде прописано bridge0 надо чтобы было одинаково.

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

8. Документация, сообщество. Дальнейшее развитие

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

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

Сообщество, активное. Публикует много готовых решений, которые вы можете использовать в своих установках.

На данный момент с 5.12 изменились некоторые политики в компании forum.opennebula.io/t/towards-a-stronger-opennebula-community/8506/14 будет интересно узнать, как будет развиваться проект. В начале я специально указал некоторых поставщиков, которые используют свои решения и то что предлагает индустрия. Четкого ответа что использовать вам, конечно же нет. Но для небольших организаций поддержка своего маленького частного облака может обойтись не так дорого, как это кажется. Главное, точно знать, что это вам нужно.

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

Есть хороший чатик t.me/opennebula активно помогают и не отправляют искать решение проблемы в гугл. Присоединяйтесь.
Подробнее..

Cloudflare и Internet Archive сделают сайты доступными даже в случае проблем с хостингом

21.09.2020 12:22:00 | Автор: admin

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

Для того, чтобы исключить подобные проблемы в будущем, Internet Archive объединил усилия с Cloudflare. Сайты, которые обслуживаются при помощи этого сервиса, станут участниками программы Cloudflare Always Online. Эти сайты будут синхронизироваться с базой данных Архива интернета, благодаря чему всегда будут доступны для пользователей.

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

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

Архив интернета предоставляет специальные условия для сайтов, которые являются участниками программы Cloudflare Always Online. Их копии будут регулярно сохраняться в базе сервиса с периодичностью в 5-30 дней.

На данный момент в Internet Archive доступно около 330 млрд копий различных ресурсов. Число только зарегистрированных пользователе больше 10 млн человек. Благодаря Архиву интернета пользователи могут ознакомиться с сайтами, которые уже не существуют. Есть и возможность оценить ранние версии самых разных интернет-ресурсов.

Кроме сайтов, сервис сохраняет и мультимедиа-контент, включая музыку. Еще Internet Archive сохраняет книги, что недавно вызвало недовольство правообладателей. Сразу четыре коммерческих издательства потребовали удалить цифровые копии полутора миллионов книг с проекта Открытая библиотека. Проект Открытая библиотека работает с 2006 года. В 2020 году из-за пандемии коронавируса Архив Интернета объявил о расширении проекта: с 31 марта пользователи могут скачивать любые книги неограниченное количество раз.

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

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

Подробнее..

Дорожная карта миграции почты IBM NotesDomino в Exchange и Office 365

22.09.2020 08:08:59 | Автор: admin
image


Переход с IBM Notes на Microsoft Exchange или Office 365 дает весомое количество преимуществ для организации, но сам проект миграции выглядит пугающе и не совсем понятно с чего нужно начинать миграцию. Сам Exchange не включает собственные инструменты для полной миграции или установления сосуществования Notes и Exchange. Фактически, выполнение некоторых задач миграции и сосуществования невозможно без сторонних продуктов. В этой статье мы опишем семь ключевых шагов, которые необходимо выполнить в соответствии с лучшими практиками и нашим опытом проведения успешных миграций.

Успешная миграция включает следующие шаги:

  1. Предварительная оценки миграции.
  2. Установление сосуществования Notes и Exchange.
  3. Планирование оптимальной точности миграции.
  4. Обеспечение максимальной эффективности миграции.
  5. Запуск пробной миграции.
  6. Планирование времени миграции, для минимизации влияния на организацию.
  7. Запуск миграции и отслеживание ее прогресса.

В этой статье мы разберем как подготовиться к миграции и выполнить ее при помощи двух решений от Quest Coexistence Manager for Notes и Migrator for Notes to Exchange. Под катом некоторые подробности.

Шаг 1: Предварительная оценка миграции


Проведение инвентаризации текущей среды


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

  • Сколько существуют доменов Notes и серверов Domino?
  • Сколько у вас почтовых ящиков? Сколько из них не используются?
  • Сколько места на дисках занимают файлы основной почты? Сколько в архивах? Сколько в локальных репликах?
  • Где находятся архивы?
  • Сколько пользователей используют шифрование? Зашифрованный контент нужно перенести?
  • Сколько личных папок существует в окружении?
  • Какие пользователи используют ссылки на документы? Сколько пользователей получили ссылки от других пользователей и приложений?
  • Сколько данных вы собираетесь переносить? Например, вы хотите перенести данные только за последние полгода.
  • Будут ли перенесены нативные архивы в персональные архивы Exchange или в файлы *.pst Outlook?
  • Каковы ограничения полосы пропускания? Сколько данных можно перенести в
    определенный промежуток времени?
  • Какой объем хранилища потребуется после миграции?

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


Нужно тщательно спланировать проект, чтобы свести к минимуму простои и минимизировать потерю производительности.

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

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

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

Прежде чем начать миграцию, нужно определить критерии для измерения успеха. В частности, нужно понимать, что неразумно ожидать 100% переноса данных. Не у каждого типа элемента Notes есть эквивалент в Exchange (Active Mail самый вопиющий пример). Следовательно, реальность такова что не все элементы в Notes будут существовать в Exchange после миграции. Достижимая и измеримая цель 95% элементов перенесено для 95 процентов почтовых ящиков. Измерение и документирование результатов имеют решающее значение для обеспечения успеха миграции, а настоящие результаты возможны только если были определены критерии успешности в самом начале проекта миграции электронной почты.

Шаг 2: установление сосуществования Notes и Exchange


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

Разработка стратегии сосуществования


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

Переход с Notes на Exchange и Office 365 требует планирования миграции почтовых ящиков и приложений одновременно. Должна поддерживаться текущая функциональность приложений Notes для всех пользователей независимо от их текущей почтовой платформы. Как пользователи, перешедшие на Exchange и Office 365, они должны иметь доступ и использовать приложения Notes в рамках существующих рабочих процессов. Эта возможность должна сохраняться до тех пор, пока приложения Notes перенесутся на SharePoint или другую платформу.

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

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

Шаг 3: Планирование оптимальной точности миграции


Планирование перехода с Notes на Exchange или Office 365 требует понимания ряда конкретных различий между платформами.

Адреса электронной почты


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

Структура папки


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

Локальные реплики и архивы


В целях контроля затрат на хранение и лучшего управления ростом объема данных, многие организации устанавливают квоты на почтовые ящики. Непреднамеренным следствием этой политики часто бывает увеличение количества и размера архивов. Эти дополнительные данные источники должны быть оценены и вопрос их миграции стоит рассмотреть во время планирования миграции. Можно предоставить пользователям компонент самообслуживания, который даст им перенести только важные данные. Для оптимизация хранилища Exchange мы рекомендуем использовать другой продукт Quest Archive Manager for Exchange, в нем есть, в частности, полезный функционал по дедупликации вложенных файлов, аналог DAOS в Notes.

ACL и делегирование


Разрешенные списки для контроля доступа (ACL) и делегирование ключевые элементы для операционной в среде Notes, они также имеют решающее значение для защиты целостности. В результате важно точно преобразовать связанные права и права доступа к эквивалентным правам в Exchange Server и Office 365. В идеале сделать это автоматически, что ускорит процесс и исключит человеческую ошибку. Чтобы поддержать эффективность защиты информационных активов организации, ACL и преобразование делегирования должно быть выполнено одновременно с почтовыми данными. Некоторые организации пытаются назначить эквивалентные права вручную или с помощью скриптов, после завершения переноса данных. Однако, такой подход может негативно повлиять на производительность и добавить пробелы в безопасность данных организации.

Собственное содержание Notes


Тот самый Active Mail. Еще одна распространенная проблема, когда миграция с IBM Notes встречается с большим количеством форматированного текста. Exchange и Office 365 не поддерживают интегрированные таблицы с вкладками, кнопки, сохраненные формы и другой проприетарный контент в Notes. В результате вам потребуется либо подготовиться к потере этой функциональности или инвестировать в решение для миграции, способное преобразовать эти элементы в формат, который может быть перенесен. Скажем сразу, что решения от Quest такое никак не конвертируют и могут разве что перенести такие письма в виде вложений, чтобы пользователь мог их потом открыть через клиент Notes.

Группы и личные адресные книги


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

Взаимодействие с приложениями Notes


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

Ресурсы и почтовые базы данных


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

  • Создания ресурсных почтовых ящиков в целевой среде;
  • Переноса данных из базы данных резервирования в Exchange;
  • Обеспечения того, чтобы пользователи обеих систем могли сотрудничать и использовать ресурсы в Notes и Exchange.

Шаг 4: обеспечение максимальной эффективности миграции


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

Архитектура миграционного решения


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

Процесс миграции


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

Гибкость и самообслуживание


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

Шаг 5: запуск пробной миграции


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

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

Определение объема пилотной миграции


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

Выбор данных и систем


В процессе пилотной миграции важно использовать боевые данные и боевые системы. Это очень важно по некоторым причинам:

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

Установление ожиданий


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

Шаг 6: планирование времени миграции для минимизации влияния на организацию


Группировка пользователей


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

Сроки миграции


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

Шаг 7: запуск миграции и отслеживание ее прогресса


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

Заключение


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

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

Статья на Хабр: Миграция IBM Lotus Notes/Domino в Microsoft Exchange

Quest Migrator for Notes to Exchange на сайте Gals

Quest Coexistence Manager for Notes на сайте Gals

Quest Migrator for Notes to Exchange на сайте Quest

Quest Coexistence Manager for Notes на сайте Quest
Подробнее..

Внедрение CICD и DevOps в Enterprise (в нашем случае Ростелеком)

22.09.2020 12:22:19 | Автор: admin

Тема до сих пор весьма хайповая, и админы, добавляющие в свои резюме словечко DevOps, автоматически рассчитывают на +100К к зарплате. Но мы не про это. Мы хотим рассказать про то, как Ростелеком ИТ внедряет CI/CD & DevOps в энтерпрайзовый ИТ-ландшафт и тяжелые монолитные Legacy-системы.

Первая часть нашего руководства будет про Почему, зачем, как получить на это денег от бизнеса и как получается внедрять CI/CD в десятки проектных команд очень большой компании. Это интересная практическая информация для руководителей ИТ-подразделений и лидов. Вторая часть статьи сугубо инженерная, с описанием прикладных подходов, инструментов и реализаций в зависимости от типа и технологического статуса проекта. И третий блок будет про процесс внедрения в рамках Karma Framework в круге. Поехали!

Ретро. Как всё начиналось

Примерно за год ИТ-разработка Ростелекома в определенном периметре выстроила современную инфраструктуру, основанную на микросервисной архитектуре с развертыванием в кластере OpenShift. Эту инфру мы потом назвали Платформой Цифровых Продуктов, далее ПЦП. Мы позже подробнее опишем состав ПЦП.

Внедрение ПЦП позволило существенно перестроить работу некоторых команд, которые были лоцированы в одном структурном подразделении, с одной точкой управления. Это важно, так как у нас получилось создать в определенной степени технологический и методологический анклав и выстроить новые практики, которые отличаются от остальной корпорации вплоть до того, что мы не поддержали промышленный корпоративный стандарт, и проекты, запускавшиеся в ПЦП, выводились в продакшн на конечных юзеров, но не передавались в общую эксплуатацию. По сути это означает, что продукты НЕ падали вообще и были вне контура эксплуатации. Но с СБ ИТ все договоренности мы имели и нужные мероприятия делали. Плюс несколько команд начали работать в продуктовом подходе по Agile. Разумеется, это стало возможным на определенном классе продуктов и сервисов, что мы запускали. В основном это были относительно легкие фронтовые и middleware-решения, которые легко создавались на основе микросервисов и быстро запускались web-проекты, но с интеграциями в глубокий корпоративный бэкенд. Часть функционала и интеграции запиливались в микросервисы, которые могли использовать другие проекты. Тем не менее, для большой корпорации это был космос оказывается, за 3-6 месяцев можно развернуть для конечных пользователей довольно большой проект или сервис с интеграцией в общий ИТ-ландшафт, опробовать бизнес-гипотезы и модели или просто включить в продуктовую линейку и возможности для клиентов. Сноска для понимания стартаперов: в больших компаниях со множеством региональных биллингов на миллионы людей раньше нельзя было взять и просто за 3-6 месяцев запустить на всю клиентскую базу новый продукт или сервис. Обычно успехом считалось, что это время уходит только на согласование бюджета и ТЗ. А продукт в коде появлялся не ранее чем через год. Еще здесь стоит заметить, что любой стартап через пару лет становится легаси ))

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

И вот тут-то оказалось, что массы это разнокалиберные монолитные легаси-системы глубокого залегания порой циклопического масштаба и набора функционала с историей, уходящей вглубь веков. Класс систем типа АСР, CRM, аналитические системы, хранилища тарифных планов, системы ордеринга в общем, чудный мир OSS/BSS. И вся наша микросервисная архитектура, весь наш DevOps, OpenShift и CI/CD как попытка научить стадо слонов синхронному плаванию. Причем как чисто технологически, так и коммуникационно. Примерно полгода у нас ушло на исследование: насколько вообще применим пусть не микросервисный, а хотя бы компонентный инфраструктурный подход к монолитным системам. Еще сложнее оказалось объяснить и вовлечь ИТ-хэдов проектов и команд в исследование на тему как и главное зачем распиливать на компоненты ядро, где вся логика зашита, например, в пакеты Oracle. Ну допустим. А далее эстафета достигает, достигает, достигает бизнес-заказчиков. И бизнес задает главный вопрос жизни, вселенной и всего такого а зачем мы будем платить за архитектурный рефакторинг систем, которые и так работают?

Аээ 42!

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

Вот на этом этапе и возникают докладчики на DevOps-конференциях с заявлениями, что в энтерпрайзе все это не летит.

Практики внедрения CI/CD&DevOps в Ростелекоме

Не то чтобы мы самые умные или упоротые. Но мы все же решили посмотреть, что есть за горизонтом событий. Даа, мало, мало огня, мы хотим еще немного больше. Горит в Ростелекоме внутренний огонь!

Начали с простых внутрикорпоративных докладов и митапов для различных проектных ИТ-команд и для инхаус-бизнес-заказчиков. Это не дало результат с точки зрения конкретных внедрений CI/CD & практик DevOps в проекты за периметром ПЦП. Но когда ты этим занимаешься больше года, то повестка начинает проникать даже в весьма консервативные команды и дальние регионы компании. Дискурс меняется, и вдруг некоторые коллеги начинают козырять словом Kubernetes как своим! Это определенно шаг вперед.

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

Следующим шагом стала попытка организовать гильдии девопсеров. Это горизонтально организованный коммуникационный формат, где различные проектные команды обмениваются опытом и практиками внедрения DevOps и CI/CD. Различные гильдии были созданы и по другим ИТ-специализациям. Формат какое-то время успешно поработал в части дальнейшего проникновения актуальных практик в различные ИТ-команды. Десятки DevOps-инженеров Ростелекома объединились и выносили задачки и свой опыт в общее тематическое инфополе. Но в итоге данный формат затух. Прежде всего потому, что сложно самоподдерживать мотивацию без целеполагания, оформленного в роадмап. Второй веской причиной затухания гильдий стало то, что этот формат без обязательств так и не позволил на системном уровне внедрять CI/CD в большие проекты и легаси-системы. Как ни крути, но не DevOps-инженеры принимают решения о переформатировании всего технологического и релизного цикла разработки или о рефакторинге.

Примерно за три года миссионерской работы знание и принимаемость темы DevOps и CI/CD в компании вышли за порог отрицания. Проделанная работа в итоге начала все же приводить к тому, что по крайней мере IT-команды стали экспериментировать и что-то использовать из инструментов интеграции и развёртывания, особенно в части тестирования и работы с git. И, наконец, мы начали пробовать внедрять CI/CD на некоторых системах тяжелого класса с монолитным ядром в БД и легаси-кодом, которые оказались по разработке в прямом операционном управлении.

Важный кейс и настоящий профит от ПЦП, от сложившегося подхода к архитектуре, разработке и набора инструментов мы получили для сетапа самого яркого огонька в корпоративном ИТ в России 2020 это экосистемы. Концепция цифровых экосистем с кросс-связанностью и кросс-сервисами по всей продуктовой линейке отлично приземляется на микросервисную архитектуру. И у нас уже была готовая инфраструктура, откуда стали быстро расти экосистемные ростки Ростелекома. А что требуется для таких стейтмент-терминов как цифровая экосистема? Правильно quick win. Чайки, налетайте!

Несмотря на заметные результаты, как ни странно, целевое дело пошло на проектах, которые начинали делать не мы, и проекты пришли к нам в Центр Компетенции digital-разработки Ростелеком ИТ в тяжелом нестабильном состоянии. До 90% ресурса команд уходило на багфикс и латание дыр. Техдолг уходил за горизонт полугода. О функциональном развитии можно было забыть. При этом системы были чрезвычайно важны и нужны бизнесу. Вот здесь и случились прорывы. Возвращаясь к вопросу бизнеса: Зачем мы будем платить за архитектурный рефакторинг систем, которые и так работают?. А вот если системы еле ворочаются и критикал-баги зашкаливают, то разговор с бизнесом из томного превращается в конструктив. У вас как у ИТ-разработки появляется возможность найти у бизнеса понимание, что для сохранения жизнеспособности систем и затем их развития нужно не перепиливать все с нуля (на больших системах часто это вообще невозможно по технологическим или бюджетным причинам), а начать внедрять DevOps и CI/CD процессы с параллельным архитектурным рефакторингом, и начинать нужно с особенно критичных мест в системе и оптимизации релизного цикла. А внедрять можно даже в рамках существующего ресурса команды и бюджета. Мы, например, брали на себя коммиты, что через 3 месяца сократим затраты ресурса команды проекта на багфикс с состояния более 50% AS IS, в котором мы получили проект, до приемлемых в среднем по индустрии менее 20%. При том практически без роста бюджета и состава команды.

В общем, если вы хотите внедрить в энтерпрайзовую легаси-систему DevOps и CI/CD процессы, отдайте ее условным индусам. Верните ее потом себе назад в ужасном состоянии, и у вас появится возможность все исправить модными штучками! Шутка))

Что в итоге сработало. Круги и Karma Framework

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

Но реальный системный результат дало использование формата кругов в рамках Karma Framework. Поскольку Ростелеком ИТ не внешний вендор (тоже важный момент, кстати), а инхаус-разработчик в группе компаний ПАО Ростелеком, то мы работаем не за маржинальность, а за карму. Это не абстракция, а финансовая модель, помноженная на ключевые ценности. И, следуя фундаментальным ценностям, таким как открытость, честность, доверие и партнерство между ИТ и бизнес-заказчиками, мы как ИТ зарабатываем карму, или другими словами свою репутацию и лояльность бизнеса, стараясь делать продукты качественно, быстро и за адекватные бюджеты. Для последнего, собственно, и нужны Devops & CI/CD, с точки зрения технологий и процессов.

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

В нашем случае предназначение Круга DevOps стало очень простым: внедрить подходы Devops и практики CI/CD на корпоративном масштабе во множество проектных команд и сделать это технологическим промышленным стандартом.

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

А пока же эту бизнесовую по сути часть темы резюмируем двумя блоками обоснования и ответом на вопрос, зачем нужно внедрять Devops&CI/CD и платить за это. Плюс несколько ключевых поинтов.

Для бизнеса:

  1. Ускорить Time-2-market вывода продукта в целом или обновлений по линейному развитию легаси.

  2. Экономия. Оплатить внедрение Devops&CI/CD и потратить N бюджета, чтобы на горизонте получить экономию в деньгах Y больше N. Или получить прибавку производительности команды, и это окупит N, а потом пойдет время чистоганом. Реальные горизонты наступления эффектов в энтерпрайзе 612 месяцев. Бывает, что и за пару месяцев на проектах с нулевой зрелостью CI/CD можно окупить потраченный ресурс команды.

  3. Сократить расходы на оплату ресурса команды, уходящего на багфиксы. В среднем по индустрии на зрелых проектах бизнес готов мириться с 20% затрат на саппорт на третьей ЛТП от бюджета развития. В целевом сокращается до 10%, а иногда уходит почти в ноль. И бизнес получает больше функционального развития.

  4. Гораздо более стабильные продукты и системы. Это автоматически ведет к росту бизнес-маркеров типа NPS, экономии на 1-2 линиях, колл-центрах и т.д.

  5. Нормализация работы и коммуникации бизнеса с ИТ. Исчезновение ментальных дисбалансов на темы Кто кому должен и кто плохо работает.

Для ИТ:

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

  2. Частью идеологии DevOps является перестроение многих процессов как технологических, так и административных. Можно за счет нового технологического инструментария и настроек существенно менять формат работы с эксплуатацией и бизнесом и перестать тратить много сил на ПМИ/ПСИ, документацию, которой невозможно пользоваться, согласования в СЭДах и прочий мартышкин труд и бюрократию. Потому что снимаются риски потери контроля, многие вопросы зон ответственности и нестабильной работы системы.

  3. Разработчики занимаются программированием и кодом, творчеством, а не разбором инцидентов и поиском их причин. Вообще, внедрение CI/CD влечет за собой повышение квалификации команды и более точного состояния, когда каждый специалист занимается своим делом.

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

  5. Все нормальные айтишники хотят делать хорошие качественные продукты. Все хотят заниматься производительным трудом на благо продукту и использовать современные стеки и технологии. В энтерпрайзе это делать тяжелее. И внедрение Devops&CI/CD позволяет подкормить профессиональную совесть качественным нектаром.

Важные моменты:

  1. CI/CD начинается до технологического цикла. Мы рассматриваем CI/CD как процесс, который начинается с идеи в горнилах бизнеса. И важно операционные процессы с бизнесом выстроить так, чтобы сырые идеи не залетали в разработку, чтобы бизнес внутри себя договаривался, что конкретно и в каком порядке пойдет в разработку. По сути это качественная работа с бэклогом, чтобы он всегда был полон на пару месяцев вперед и приоритезирован.

  2. Devops&CI/CD можно внедрять на любом уровне зрелости продукта и команды. Целый ряд вещей вообще не технологического порядка, а логистического и операционного. Часть инструментов и подходов можно внедрить очень дешево во всех смыслах. Даже в старых, тяжелых легаси-системах.

  3. Devops&CI/CD не является синонимом Agile и вполне работает в классическом ватерфоле и фикспрайсовых моделях. Отдельные инструменты и подходы вполне можно использовать: ту же автоматизацию сборки, автотесты, Unit-тестирование, правильную настройку git(а) можно внедрять хоть где.

Однако, CI/CD наиболее эффективен в связке со Scrum или Канбан. По сути, это объединение продвинутых операционной и технологической методик работы с ИТ-конвейером. У нас есть несколько кейсов такого рода. И мы увидели большие перспективы наложения на Канбан-доску с ее этапами разработки, матрицы действий и инструментов CI/CD. Здесь просто золотая жила. И мы уже делаем оригинальный фреймворк о том, как поженить Devops&CI/CD с Канбан. В следующих частях темы Devops&CI/CD в энтерпрайзе мы расскажем и том, как устроена наша Платформа Цифровых Продуктов, и о том, как работают круг и фреймворк внедрения Devops&CI/CD в разные классы систем и проектов.

Ждите новостей от Ростелеком ИТ!

Подробнее..

Экспансия скоростных проходов на мировом рынке турникетов

22.09.2020 18:18:39 | Автор: admin
Скоростные проходы турникеты с распашными или раздвижными створками в настоящее время уверенно лидируют на мировом рынке турникетов, демонстрируя стабильный рост. Недавние исследования британского аналитического агентства IHS Markit прогнозируют увеличение их доли рынка на 7% в течение ближайших 5 лет.



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

Комфортный бесконтактный проход



Скоростные проходы PERCo ST-01 в ЖК Мосфильмовский

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

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

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

Высокая пропускная способность



Скоростные проходы PERCo ST-01 в аэропорту Красноярска

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

Простота интеграции с дополнительным оборудованием


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

Одним из главных трендов рынка систем контроля доступа сегодня является распознавание лиц. Среднегодовой рост объема рынка таких систем оценивается аналитиками в 20%. Распознавание лиц широко применяется на объектах массового пребывания людей: в аэропортах, на вокзалах и стадионах. В последнее время технология распознавания лиц становится все более востребованной в связи с пандемией Covid-19 благодаря бесконтактному принципу идентификации.

По данным компании Sita Air Transport IT Insights, до 2021 системы на базе распознавания лиц будут тестировать и внедрять 77% аэропортов и 71% авиалиний. Уже сегодня такие решения используются в крупнейших аэропортах США, Австралии, Гонконга, Нидерландов. Скоростные проходы могут быть дополнены специальными кронштейнами для интеграции с терминалами распознавания лиц. Для проверки документов без участия сотрудников объекта скоростные проходы оборудуют терминалами распознавания документов.



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

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

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

Основные мировые производители скоростных проходов


Согласно исследованию Marketwatch в 2020 году, в рейтинг ведущих мировых производителей турникетов входят следующие компании:

  • Digicon
  • Centurion Systems
  • PERCo
  • Saela
  • Turnstar
  • Manusa
  • Smarter Security
  • Cominfo
  • Meesons
  • Controlled Access
  • AKTUEL
  • TiSO
  • Dormakaba Group
  • Boon Edam
  • Kaba Gallenschuetz
  • Hayward Turnstiles
  • Godrej Security Solutions
  • Fastlane Turnstiles
  • Gunnebo
  • Alvarado
  • Axess
  • DaoSafe

В рейтинге из 20 компаний PERCo является единственным российским брендом. Продукция компании экспортируется в 90 стран мира. В нашем обзоре мы рассмотрим скоростные проходы компаний Digicon, PERCo, Manusa, Alvarado, Dormakaba, Cominfo, Fastlane Security, Gunnebo, Boon Edam.

Digicon (Бразилия)



Скоростные проходы DGate в офисе корпорации Furnas

Линейка скоростных проходов бразильского производителя Digicon сегодня представлена моделями Slide и DGate. Slide турникеты с раздвижными створками, выполненными из стекла и нержавеющей стали. Ширина прохода составляет 500 или 900 мм. Турникеты снабжены 16 оптическими датчиками для контроля прохода. DGate AW турникеты с раздвижными створками, DGate SW турникеты с распашными створками. Ширина прохода составляет 500 или 900 мм. Корпус выполнен из нержавеющей стали, створки из оргстекла или поликарбоната. Контроль прохода осуществляется с помощью 12 оптических датчиков.

Турникеты DGate могут быть интегрированы со сканерами штрих-кодов, считывателями карт доступа HID /Mifare и сканерами отпечатков пальцев. Боковые панели и крышки турникетов DGate могут быть исполнены в различных цветах в соответствии с потребностями заказчика.
В случае экстренной ситуации или пропадании электропитания створки турникетов Slide и DGate открываются автоматически.

Турникеты Digicon установлены, в частности, на нескольких станциях метрополитена Рио-де-Жанейро и на проходных производственной и электроэнергетической корпорации Furnas.

PERCo (Россия)



Скоростные проходы ST-02 в аэропорту Внуково

На текущий момент линейка скоростных проходов PERCo представлена моделями ST-01 и ST-02 в различных модификациях.

Скоростной проход ST-01 оснащен распашными створками. Ширина прохода может составлять 650, 900 и 1000 мм. Высота перекрытия 1010 и 1300 мм. Материалом исполнения крышек может служить закаленное стекло, нержавеющая сталь, закаленное стекло со вставками из нержавеющей стали.

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

Простота интеграции дополнительного оборудования позволяет адаптировать скоростные проходы под задачи различных объектов. В прибалтийской сети кинотеатров Cinamon для удобства зрителей при предъявлении билетов скоростные проходы оборудованы стеклом- подставкой для еды и напитков. В индийском подразделении банка Goldman Sachs скоростные проходы дополнены стойкой со сканером отпечатков пальцев.

Скоростной проход ST-02 отличают раздвижные створки. Ширина зоны прохода также может варьироваться в зависимости от модификации. Характеристики данной модели аналогичны ST-01: пропускная способность 60 человек в минуту, инфракрасные датчики для безопасного прохода и предотвращения проникновения нескольких человек одновременно, автоматическая разблокировка при экстренной ситуации или пропадании электропитания.

Благодаря своим потребительским свойствам скоростные проходы ST-02 были выбраны для установки на проходной крупнейшего в России центра автоматизированного управления воздушным движением, расположенного в аэропорту Внуково, Москва. Высокая пропускная способность скоростных проходов ST-02 позволяет эффективно организовать контроль доступа в условиях интенсивного потока людей персонал МЦ АУВД работает в шесть смен. 11 скоростных проходов ST-02 установлены в московском офисе компании Яндекс. В соответствии с растущим мировым спросом на скоростные проходы, линейка PERCo вскоре пополнится новой моделью скоростных проходов ST-11. Скоростные проходы ST-11 оптимально подходят для использования в условиях ограниченного пространства благодаря компактным размерам.

Fastlane Security (Великобритания)



Скоростные проходы Fastline Glassgate в офисе компании Sports Direct

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

В линейке есть турникеты в корпусе из нержавеющей стали, турникеты со стеклянными боковыми панелями, также варьируются высота створок и ширина зоны прохода. Ширина зоны прохода, в зависимости от конкретной модели, может составлять 660, 914, 1100 и 1200 мм. Высота перекрытия от 805 до 1800 мм. Пропускная способность составляет 60 человек в минуту.

Скоростные проходы Fastline Glassgate оснащены 18 оптическими датчиками для контроля зоны прохода. При чрезвычайной ситуации створки турникетов раздвигаются автоматически. Турникеты могут быть оснащены встроенными считывателями, также считыватели можно установить дополнительно. Среди мест, где установлены Fastline Glassgate: Мировой торговой центр в Нью-Йорке, университете Notre Dame в Индиане, офис компании Sports Direct в Лондоне.

Boon Edam (Нидерланды)



Скоростные проходы Lifeline Speedlane в офисном центре The River Building

Американский производитель выпускает две линейки скоростных проходов: турникеты с распашными створками Lifeline Speedlane и турникеты с раздвижными створками Speedlane, а также безбарьерную модель Speedlane Open.

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

Скоростные проходы выполнены из стекла и нержавеющей стали. Ширина зоны прохода модели Speedlane Compact может составлять 510 или 910 мм, высота перекрытия от 980 до 1800 мм. У турникетов. Lifeline Speedlane ширина зоны прохода варьируется от 500 до 915 мм. Высота перекрытия может быть увеличена по запросу. Также в зависимости от потребностей заказчика турникеты могут быть окрашены в цвета каталога RAL и брендированы. Например, в лондонском офисном центре The River Building установлены скоростные проходы с распашными створками.

Alvarado (США)



Скоростные проходы SU5000 в здании администрации штата Мичиган

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

Пропускная способность SU5000 составляет до 30 человек в минуту. Турникеты поддерживают работу со считывателями RFID / NFC идентификаторов и штрих-кодов, а также могут быть интегрированы с билетными системами. Ширина прохода может составлять 723 или 926 мм, высота перекрытия 1165 или 1749 мм. Турникеты SU5000 установлены, в частности, в здании администрации штата Мичиган, США, сети магазинов Walmart и на многих других объектах.

Dormakaba (Швейцария)



Скоростные проходы Argus в аэропорту Минска

Швейцарский производитель выпускает три модели скоростных проходов, объединенных в линейку Argus: Argus 40, Argus 60 и Argus 80. Все модели выполнены в алюминиевых корпусах с распашными створками и могут быть окрашены в один из 12 предложенных цветов. Турникеты оснащены оптическими датчиками для контроля зоны прохода. Турникеты Argus 60 и Argus 80 также имеют подсветку зоны прохода и горизонтальную систему цветовой завесы.

Ширина прохода может составлять 650, 900, 915 и 1000 мм. Высота перекрытия 990, 1200, 1400, 1600 или 1800 мм. Скоростные проходы Argus могут быть интегрированы с дополнительным оборудованием: считывателями карт доступа, сканерами штрих-кодов и отпечатков пальцев, терминалами распознавания лиц. Например, турникеты Argus со сканерами штрих-кодов установлены в аэропорту Минска, Беларусь.

Gunnebo (Швеция)




В линейке Gunnebo присутствуют скоростные проходы с распашными и раздвижными створками.
Турникеты с распашными створками представлены в стандартной серии SpeedStile FL и компактной серии SpeedStile FLs. Серия SpeedStile FLs включает турникеты SpeedStile FLs BA/EV длиной 1200 мм, 1400 мм и 1800 мм и турникеты SpeedStile FLs DS длиной до 1800 мм.

В серии SpeedStile FL доступны турникеты с различной высотой перекрытия: 1000, 1200, 1800 мм. Также предусмотрена увеличенная ширина прохода 900 мм. Турникеты обеих линеек выполнены из нержавеющей стали и стекла. Пропускная способность турникетов обеих серий составляет 40 человек в минуту. В случае чрезвычайной ситуации створки остаются в текущем положении. Опционально турникет может быть оснащен аккумулятором, позволяющим автоматически открыть створки в случае отключения питания.

Скоростные проходы с раздвижными створками представлены моделями SpeedStile BP и SpeedStile FP. SpeedStileBP турникеты со створками высотой 900 мм, SpeedStileFP турникеты со створками высотой 1200 или 1800 мм. Корпуса обеих моделей выполнены из нержавеющей стали и окрашенного пластика. Турникеты SpeedStile доступны в нормально-открытой и нормально-закрытой версиях. Контроль прохода осуществляется 6 инфракрасными датчиками для нормально-закрытой версии и 14 датчиками для нормально-открытой версии. Турникеты Gunnebo установлены на транспортных и развлекательных объектах, в бизнес-центрах и на предприятиях.

Manusa (Испания)



Cкоростные проходы Express Gate в спа-центре Spalas

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

При отключении электропитания или экстренной ситуации створки открываются автоматически. Турникеты интегрируются со считывателями карт доступа, отпечатков пальцев, терминалами распознавания лиц. Турникеты Express Gate установлены в университетских кампусах, отелях, на проходных предприятий.

Cominfo (Чехия)



Скоростные проходы Easygate в БЦ Dominion Tower

Чешская компания Cominfo производит турникеты с распашными и раздвижными створками под общим названием Easygate. Новая модель турникеты Easygate Superb изготовлены из нержавеющей стали и стекла и могут быть окрашены в различные цвета. Доступен различный вид отделки: матовая, полированная или бронзовая нержавеющая сталь. Верхняя панель турникета может быть окрашена в выбранный цвет. Турникеты оснащены 24 парами оптических сенсоров в верхней и нижней части турникета. Данная модель имеет световую и звуковую индикацию прохода.

Турникеты оборудованы встроенным считывателем карт доступа и картоприемником. Возможна интеграция со сканерами штрих-кодов и отпечатков пальцев. Ширина зоны прохода может составлять 550, 650 или 920 мм. Высота перекрытия 990 и 1800 мм. Турникеты Cominfo установлены, в частности, в БЦ Dominion Tower (Москва), БЦ Flow Building (Прага), офисе Siemens в Нидерландах.
Подробнее..

Выбираем недорогой CDN. Обзор сервисов и тарифов

23.09.2020 12:10:47 | Автор: admin
Подключить CDN для ускорения загрузки сайта рекомендует чуть ли не каждый инструмент по оптимизации. Беглый поиск показывает, что услугу предоставляют не менее десятка крупных сервисов, однако лишь у немногих можно найти действительно доступные тарифы.

После небольшого ресерча наш рейтинг недорогих CDN провайдеров возглавили BunnyCDN, BelugaCDN и OVH. Сравним их предложения.




BunnyCDN


Сайт: https://bunnycdn.com

По нашей оценке самый конкурентоспособный игрок на рынке недорогих CDN. Тарифы от $0.01/GB по факту потребления без необходимости покупать какую-либо месячную подписку. Есть вариант купить супердешевый план Volume в 7 точках присутствия за $0.005/GB

Огромная география точек присутствия (POP), включая Россию. Для попробовать сходу и без лишних вопросов дают 1ТБ трафика на 14 дней.

Достоинства:

  • 42 точки присутствия в 28 странах на всех континентах, включая Россию
  • отличный интерфейс администратора, вот прям не хотелось выходить
  • есть собственный Wordpress плагин
  • находится в ЕС, если кому важен GDPR


Недостатки*:

  • стоимость трафика для POP в Африке и Южной Америке



BelugaCDN


Сайт: https://belugacdn.com

Второй популярный лоукостер на рынке доставки контента с ценой $0.01/GB, плюс можно дополнительно сэкономить при покупке месячных пакетов трафика.

Здесь по дефолту доступны всего 9 так называемых superPOP, которые есть только в Европе и США. У сервиса есть 30-дневный пробный период, но нужно ввести номер кредитки, поэтому будьте внимательны, чтобы не было потом лишних списаний.

Достоинства:

  • есть свой плагин для Grafana
  • Anti-DDoS по умолчанию


Недостатки*:

  • 9 superPOP на 2 континентах: Европа и США
  • для trial периода хотят номер кредитки



OVH


Сайт: https://www.ovh.com

Пакетные тарифы на CDN от известного французского хостера сравнимы с ценами рассмотренных ранее сервисов только при заказе больших объемов трафика.

Для услуги заявлено всего 3 точки присутствия, что для сетей доставки контента кажется весьма необычным. В таких случаях может быть оптимальнее и дешевле собрать свой CDN на базе VPS или выделенных серверов. Бесплатного пробного периода у OVH нет.

Достоинства:

  • крупная европейская хостинг-компания со своей инфраструктурой
  • Anti-DDoS из коробки


Недостатки*:

  • небольшое число точек присутствия
  • покупка только фиксированного объема трафика (1ТБ, 10ТБ, 100ТБ, и т.д.)
  • нет бесплатного пробного периода

Итоги


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

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


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

Вернуть пропавший скутер, или история одного IoT мониторинга

23.09.2020 20:15:33 | Автор: admin

Год назад мы запустили пилотную версию промо проекта по децентрализованному прокату электроскутеров.


Изначально проект назывался Road-To-Barcelona, позже стал Road-To-Berlin (отсюда встречающиеся на скриншотах R2B), а в итоге и вовсе был назван xRide.


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


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


Пользователь устанавливал iOS или Android приложение на телефон, подходил к понравившемуся ему скутеру, после чего телефон и скутер устанавливали peer-to-peer соединение, происходил обмен ETH и пользователь мог начать поездку включив скутер через телефон. По завершении поездки так же можно было провести оплату поездки за счет эфира из кошелька пользователя на телефоне.


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


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



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


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


Что и зачем мониторить: скутеры, инфраструктура, зарядки?


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


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


Скутеры


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


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


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


Конечно, необходимо также проверять что происходит с нашими Hardware компонентами:


  • работает ли Bluetooth?
  • работает ли сам GPS модуль?
    • так же у нас была проблема с тем, что GPS мог отсылать неверные координаты и "залипать", а определить это можно было только на уровне дополнительных проверок на скутере,
      и нотифицировать поддержку как можно скорее для устранения проблемы

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


Hardware



Что же представляла наша "железная" часть?
Учитывая максимально сжатые сроки и необходимость быстрого прототипирования мы выбрали для себя максимально простой для реализации и подбора компонентов вариант Raspberry Pi.
Помимо самого Rpi мы имели кастомную борду (которые мы сами разработали и заказывали в Китае для ускорения процесса сборки конечного решения) и набор компонентов реле (для включения/выключения скутера), считыватель заряда батареи, модем, антенны. Все это было компактно укомплектовано в специальную коробочку "xRide box".


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


Docker? Plain linux? и деплой


Вернемся к мониторингу, итак Raspberry что же мы имеем?


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


К сожалению, довольно быстро стало ясно что Docker на RPi хоть и работает, но дает достаточно много накладных расходов, в частности по энергопотреблению.


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


Второй причиной стала одна из библиотек наших партнеров на Node.js (sic!) единственный компонент системы, который не был написан на Go/C/C++.
Авторы библиотеки не успели вовремя предоставить рабочую версию на любом из "нативных" языков.
Мало того, что нода сама по себе не является самым элегантным решением для низкопроизводительных девайсов, так еще и сама библиотека была весьма прожорлива по ресурсам.


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


OS


В итоге, качестве ОС мы, опять же, избрали самый простой вариант и использовали Raspbian (сборка Debian для Pi).
Весь наш софт мы пишем на Go, поэтому и основной hardware-агент модуль в нашей системе мы также написали на Go.
Именно он и отвечает за работу с GPS, Bluetooth, считывание заряда, включение скутера, итд.


Деплой

Тут же встал вопрос о необходимости реализации механизма доставки обновлений на девайсы (OTA) как обновлений самого нашего агента/приложения, так и обновления самой ОС/"прошивки"
(так как новые версии агента могли требовать обновлений ядра или компонентов системы, библиотек итд).


После довольно долгого анализа рынка выяснилось, что существует довольно много решений для доставки обновлений на девайс.
От относительно простых утилит, по большей части ориентированных на обновление/dual-boot вроде swupd/SWUpdate/OSTree до полноценных платформ вроде Mender и Balena.


В первую очередь мы решили, что нас интересуют именно end-to-end решения, поэтому выбор сразу пал на платформы.
Самым Balena была исключена ввиду того, что фактически использует тот же самый Docker внутри своего balenaEngine.
Но отмечу, что несмотря на это, в конечном итоге мы постоянно использовали их продукт Balena Etcher для флеша прошивок на SD карты простая и крайне удобная утилита для этого.


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


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


Ansible

Самым простым решением в нашей ситуации оказалось использование Ansible. Пары playbook'ов для начала было вполне достаточно.
Суть их сводилась к тому, что мы просто подключались с хоста (CI сервер) по ssh к нашим расберри и разливали на них обновления.


В самом начале все было просто нужно было находиться в единой сети с устройствами, разливка шла через Wi-Fi.
В офисе просто находилось десяток тестовых малинок, подключенных к одной сети, каждое устройство имело статический IP адрес так же указанный в Ansible Inventory.


Именно Ansible доставлял наш мониторинг-агент на конечные устройства


3G/LTE


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


В реальности у скутеров вообще не может быть никакого соединения кроме мобильного 3G/LTE (и то не постоянно).
Это накладывает сразу много проблем и ограничений, вроде низкой скорости соединения и нестабильной связи.


Но самое главное в 3G/LTE сети мы не можем просто надеяться на статичный IP присвоенный в сети.
Это частично решается некоторыми провайдерами SIM карт, есть даже специальные симки предназначенные для IoT устройств со статическими IP адресами. Но мы не имели доступа к таким SIM картам и не могли использовать IP адреса.


Конечно, были идеи делать некую регистрацию IP адресов aka service discovery где-то вроде Consul, но от подобных идей пришлось отказаться,
так как у нас в тестах IP адрес мог меняться слишком часто, что приводило к большой нестабильности работы.


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


VPN


В качестве решения этой проблемы мы выбрали VPN а конкретно Wireguard.


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



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


Облачные ресурсы


Последнее необходимо отслеживать наши облачные сервисы и БД, так как для них мы используем Kubernetes, в идеале чтобы разворачивание мониторинга в кластере было максимально простым. В идеале с использованием Helm, так как для деплоя, мы в большинстве случаев используем его. И, само собой, для мониторинга облака нужно использовать те же решения, что и для самих скутеров.


Дано


Фуф, вроде с описанием разобрались, давайте составим список того, что нам было нужно в итоге:


  • Быстрое решение, так как мониторить необходимо уже во время процесса разработки
  • Объем/количество нужно множество метрик
  • Сбор логов обязателен
  • Надежность данные критически важны для успеха запуска
  • Нельзя использовать pull модель нужен push
  • Нужен единый мониторинг не только железа, но и облака

Конечная картинка выглядела примерно так



Выбор стека


Итак, перед нами встал вопрос выбора стека для мониторинга.


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


Существует огромное множество решений для мониторинга,
начиная полноценными системами вроде Nagios, icinga или zabbix и заканчивая уже готовыми решениями по Fleet management.



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


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


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


(B)ELK?


Первое решение, которое реально рассматривалось широко известный ELK стек.
На самом деле он должен называться BELK, ведь начинается все с Beats https://www.elastic.co/what-is/elk-stack



Конечно, ELK это одно из самых известных и мощных решений в области мониторинга, а уж в сборе и обработке логов, так и самое.


Мы подразумевали, что ELK будет использоваться для сбора логов и, так же как долговременное хранилище метрик полученных из Prometheus.
Для визуализации можно использовать Grafan'у.


На самом деле, свежий ELK стек умеет собирать метрики и самостоятельно (metricbeat), Kibana так же умеет показывать их.


Но все-таки изначально ELK вырос из логов и пока функционал метрик имеет ряд серьезных недостатков:


  • Значительно медленнее Prometheus
  • Интегрируется в куда меньшее количество мест чем Prometheus
  • Сложно настроить алертинг по ним
  • Метрики занимают большое количество места
  • Настройка дашбордов с метриками в Kiban'е значительно сложнее Grafan'ы

В общем, метрики в ELK тяжелые и пока не такие удобные как в других решениях, которых сейчас на самом деле значительно больше чем просто Prometheus: TSDB,
Victoria Metrics, Cortex итд итп. Конечно, очень бы хотелось иметь сразу полноценное all-in-one решение, но в случае с metricbeat выходило слишком много компромиссов.


Да и у самого ELK стека есть ряд непростых моментов:


  • Он тяжелый, порой даже очень, если у вас собирается довольно большое количество данных
  • Его нужно "уметь готовить" скалировать его необходимо, но делается это нетривиально
  • Урезанная бесплатная версия в бесплатной версии нет нормального алертинга, на момент выбора не было и аутентификации

Надо сказать, что в последнее время с последним пунктом стало получше и помимо вывода в open-source X-pack (в том числе аутентификация) начала меняться сама модель прайсинга.
Но на момент, когда мы собирались разворачивать это решение, алертинга не было совсем.
Возможно, можно было попробовать собрать что-то с использованием ElastAlert или других community решений, но все же решили рассмотреть другие альтернативы.


Loki Grafana Prometheus


На данный момент неплохим решением может быть сборка стека мониторинга на основе чисто Prometheus как поставщика метрик,
Loki для логов, а для визуализации можно использовать все ту же Grafana.
К сожалению, на момент старта прода пилота проекта (сентярбь-октябрь 19ого года) Loki еще находился в бета версии 0.3-0.4,
а на момент старта разработки и вовсе не мог рассматриваться как produtcion решение.


Я пока не имею опыта реального использования Loki в серьезных проектах, но могу сказать, что Promtail (агент для сбора логов) здорово работает как для bare-metal, так и для подов в kubernetes.


TICK


Пожалуй, наиболее достойной (единственной?) полнофункциональной альтернативой ELK стеку сейчас можно назвать только TICK стек Telegraf, InfluxDB, Chronograf, Kapacitor.



Я опишу все компоненты ниже более подробно, но в целом идея такая:


  • Telegraf агент для сборки метрик
  • InfluxDB база данных метрик
  • Kapacitor обработчик метрик в реальном времени для алертинга
  • Chronograf веб панель для визуализации

Для InfluxDB, Kapacitor и Chronograf есть официальные helm чарты, которые мы использовали для их разворачивания.


Надо отметить, что в свежей версии Influx 2.0 (beta) Kapacitor и Chronograf стали частью InfluxDB и больше не существуют отдельно


Telegraf



Telegraf это очень легковесный агент для сбора метрик на конечной машине.
Он умеет мониторить огромное количество всего, от nginx до
сервера minecraft.


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


  • Быстрый и легкий (написан на Go)
    • Ест минимальное количество ресурсов
  • Push метрик по умолчанию
  • Собирает все необходимые метрики
    • Системные метрики без каких-либо настроек
    • Хардварные метрики вроде информации с датчиков
    • Очень легко добавлять собственные метрики
  • Много плагинов "из коробки"
  • Собирает логи

Так как push метрик был для нас необходим, все остальные преимущества были более чем приятными дополнениями.


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


Telegraf вообще отличный агент для сборки метрик, даже если вы не используете весь остальной ICK стек.
Многие скрещивают его и с ELK и с различными другими time-series базами по удобству, так как он умеет писать метрики почти куда угодно.


InfluxDB



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


InfluxDB тоже написан на Go и работает, по ощущениям, значительно быстрее в сравнении с ELK на нашем (не самом мощном) кластере.


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


Недостатки $$$ или скалирование ?

У TICK стека есть только один обнаруженный нами недостаток он дорогой. Даже очень.


А что есть в платной версии, чего нет в бесплатной?


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


А именно поднять кластер с High availability можно только в Enterprise версии.


Хотите полноценное HA нужно либо платить, либо городить какие-нибудь костыли. Есть пара решений сообщества например influxdb-ha похоже на грамотное решение, но написано что не подходит для продакшена, а так же
influx-spout простое решение с прокачкой данных через NATS (его тоже придется скалировать, но это решаемо).
Жаль, но оба они, похоже, заброшены нет свежих коммитов, предположу, что дело в скором ожидаемом выходе новой версии Influx 2.0 в которой многое будет иначе (пока информации о скалировании в ней нет).


Официально для бесплатной версии существует Relay фактически это примитивное HA, но только посредством балансировки,
так как все данные будут писаться во все инстансы InfluxDB за load balancer'ом.
У него есть некоторые недостатки вроде потенциальных проблем с перезаписью точек и необходимости создавать базы для метрик заранее
(что при обычной работе с InfluxDB происходит автоматически).
К тому же шардирование не поддерживается, это означает дополнительные накладные расходы на дуплицированные метрики (и обработка и хранение),
которые могли вам быть не нужны, но разделить их возможности нет.


Victoria Metrics?


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



Time-series баз немало, но наиболее подающая надежды Victoria Metrics, у нее целый ряд плюсов:


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

Мы не собирались строить полностью кастомный стек на основе Victoria и основная надежда была на то, что мы сможем воспользоваться ею как drop-in заменой для InfluxDB.


К сожалению, это невозможно, несмотря на то, что поддерживается протокол InfluxDB, это работает только для записи метрик "наружу" доступно только Prometheus API,
а значит натравить Chronograf на нее не получится.
Более того, для метрик поддерживаются только числовые значения (мы использовали строковые значения для кастомных метрик об этом в разделе админка).
Очевидно, по той же причине VM не может хранить логи, как это делает Influx.


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


Выбор базы

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


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


  • Нам очень нравился функционал TICK стека целиком
  • Мы уже успели его развернуть и оно отлично работало
  • Сроки поджимали и не оставалось много времени тестировать другие варианты
  • У нас не ожидалось такой большой нагрузки

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


Со стеком и базой решили теперь об остальных компонентах TICK стека.


Kapacitor



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


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


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



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


В Influx 2.0 Kapacitor стал частью DB


Chronograf



Я повидал много различных UI решений для мониторинга, но могу сказать, что по функционалу и UX ничто не сравнится с Chronograf'ом.


Начинали мы использовать TICK стек, как ни странно, с Grafan'ой в качестве веб-интерфейса.
Описывать ее функционал не буду, всем известны ее широкие возможности по настройке всего что угодно.


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


Пожалуй, основное удобство работы с Chronograf в том, что вы можете смотреть внутренности вашей InfluxDB через Explore.


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


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


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


Так выглядит то самое окно запросов:


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


Ну и конечно же, Chronograf максимально удобен для просмотра логов. Выглядит это так:



По умолчанию Influx логи заточны под использование syslog и поэтому в них есть важный параметр severity.


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


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


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


Аутентификация


Отдельно стоит упомянуть то, что Chronograf поддерживает OAuth и OIDC в качестве аутентификации.
Это очень удобно, так как позволяет легко прикрутить его к вашему серверу и сделать полноценное SSO.


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


Админка


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


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


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


Один из уже упомянутых плюсов Influx возможность легко создавать свои собственные метрики.
Это позволяет использовать его для огромного множества сценариев.
Мы старались записывать туда всю полезную информацию: заряд батареи, состояние замка, работоспособность датчиков, bluetooth, GPS, множество других healthcheck'ов.
Все это мы и отображали на админ панели.


Конечно, самым главным критерием для нас было состояние работы скутера фактически Influx проверяет это сам и показывает в разделе Nodes "зелеными лампочками".
Делается это функцией deadman мы использовали ее же для понимания работоспособности нашей коробочки и отсылки тех самых алертов в Slack.


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


Да и вообще так было веселее. Постоянно звучали фразы вроде "Ребята Смитерс умер!"



Строковые метрики


Важно, что InfluxDB позволяет хранить не только числовые значения, как в случае с Victoria Metrics.


Казалось бы, это не так важно ведь если не считать логов, любые метрики можно хранить в виде чисел (всего лишь добавить маппинг для известных состояний своего рода enum)?


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


В результате API зарядок было далеко от идеала, но основной проблемой было то, что мы не всегда могли понять их состояние.
Тут на помощь и пришел Influx. Мы просто-напросто записывали приходящий нам строковый status в поле базы InfluxDB без изменений.


Какое-то время туда попадали только значения вида "online" и "offline", на основе чего у нас в админке отображалась информация,
а в Slack приходили уведомления. Однако в какой-то момент туда стали попадать так же значения вида "disconnected".
Как позже выяснилось, этот статус высылался однократно после потери связи, если зарядка не могла установить соединение с сервером после какого-то количества попыток.


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


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



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


Очень сильно нам это пригодилось, когда мы разыскивали скутер (смотри выводы в конце).


Мониторинг инфраструктуры


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



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


Из того что мы хотели бы проверять в облаке, это:


  • Базы данных
  • Keycloak
  • Микросервисы

Так как все наши облачные сервисы находятся в Kubernetes, то было бы неплохо собирать информацию и о его состоянии.
К счастью, Telegraf "из коробки" может собирать огромное количество метрик о состоянии Kubernetes кластера, а Chronograf сразу предлагает для этого красивые дашборды.


Мы следили в основном за работоспособностью подов и потреблением памяти. В случае падения алерты в Slack.


Для отслеживания подов в Kubernetes есть два пути: DaemonSet и Sidecar.
Оба способа подробно описаны в этом блог посте.
Мы использовали Telegraf Sidecar и помимо метрик собирали логи подов.
В нашем случае с логами пришлось повозится. Несмотря на то что Telegraf умеет вытаскивать логи из Docker API, мы хотели иметь единообразный сбор логов с нашими конечными устройствами и настраивали для этого syslog для контейнеров. Возможно, это решение не было красивым, но нареканий в его работе не было и логи хорошо отображались в Chronograf'e.


Мониторить мониторинг???

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


Выводы


Какие выводы мы сделали по результатам пилота?


Как можно делать мониторинг


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


Производительность

Основная проблема TICK стека в бесплатной версии отсутствие возможностей по скалированию. Для нас это не стало проблемой.


Мы не собирали точных данных/цифр о нагрузке, но мы собирали данные с примерно 30и скутеров одновременно.
Каждый из них собирал более трех десятков метрик. Одновременно собирались логи с устройств. Сбор и отправка данных происходили каждые 10 секунд.


Важно отметить, что спустя полторы недели пилота, когда основную массу "детских болячек" удалось исправить и самые важные проблемы уже были решены,
нам пришлось снизить частоту отправки данных на сервер до 30и секунд. Это стало необходимо, потому что трафик на наших LTE SIM картах начал быстро таять.
Основную массу трафика съедали логи, сами метрики даже с 10и-секундным интервалом практически не тратили его.


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


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


TICK идеально для небольших-средних проектов

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


Если у вас нет тысяч подов или сотен машин даже один инстанс InfluxDB прекрасно справится с нагрузкой.
В некоторых случаях вас может устроить Influx Relay как примитивное решение по High Availability.


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


Если же вы не уверены в ожидаемой нагрузке на сервисы мониторинга, или у вас гарантированно есть/будет очень "тяжелая" архитектура бесплатную версию TICK стека использовать я бы не порекомендовал.
Конечно, простым решением было бы приобретение InfluxDB Enterprise но тут я не могу как-то прокомментировать, так как сам не знаком с тонкостями. Кроме того, что это очень дорогои точно не подойдет для мелких компаний.


В таком случае, на сегодняшний день, я бы порекомендовал посмотреть в сторону сбора метрик через Victoria Metrics и логов с помощью Loki.
Правда, снова оговорюсь, что Loki/Grafana значительно менее удобны (в виду своей большей универсальности) чем готовый TICK, но зато они бесплатны.


Важно: вся описанная здесь информация актуальна для версии Influx 1.8, в данный момент вот-вот должен выйти в релиз Influx 2.0.
Пока не довелось попробовать его в боевых условиях и сложно делать выводы об улучшениях, точно еще лучше стал интерфейс, упростилась архитектура (без kapacitor и chronograf),
появились темплейты ("киллер фича" можно отслеживать игроков в Fortnite и получать нотификации когда твой любимый игрок выигрывает партию). Но, к сожалению, в данный момент в версии 2 нет ключевой вещи, по которой мы выбрали первую версию нет сбора логов.
Этот функционал в Influx 2.0 тоже появится, но каких-либо сроков, даже примерных, найти не удалось.


Как не нужно делать IoT платформы (теперь)


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


Конечный результат и та платформа на основе Ansible + TICK + WireGuard, которую мы собрали самостоятельно нас полностью устраивает. Но на сегодняшний день, я бы порекомендовал внимательней посмотреть на Balena прежде чем пытаться собрать свою IoT платформу самим.


Потому что, в конечном итоге она умеет делать большую часть того, что мы делали, при этом OpenBalena бесплатна, а код открыт.
Оно уже умеет не просто рассылать обновления, но и VPN там уже вшит и заточен под использование в IoT среде.


А совсем недавно они и вовсе выпустили свою Hardware, которая легко подключается в их экосистему.


Эй, а что с пропавшим скутером?


Итак скутер, "Ральф", бесследно исчез.
Мы сразу побежали смотреть карту в нашей "админке", с данными GPS метрик из InfluxDB.


Благодаря данным мониторинга, мы легко определили, что парковку скутер покинул около 21:00 прошлого дня, проехал где-то полчаса до какого-то района и был запаркован до 5и утра рядом с каким-то немецким домом.
После 5и утра данных мониторинга не поступало это означало либо полный разряд дополнительной батареи, либо злоумышленник догадался-таки извлечь умную начинку из скутера.
Несмотря на это, по тому адресу, где находился скутер все же была вызвана полиция. Скутера там не оказалось.
Однако владелец дома тоже был этому удивлен, так как он действительно вчера вечером приехал на этом скутере из офиса домой.


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


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

Подробнее..

I want to break free. Обзор беспроводной DECT гарнитуры Snom A170

24.09.2020 08:13:47 | Автор: admin
Доброго дня, коллеги.
Прошлой статьей мы завершили цикл обзоров на настольные телефоны, предлагаем теперь поговорить о гарнитурах, предоставляемых нашей компанией. Начнем с модели DECT-гарнитуры Snom A170. Посмотрите краткое видео о гарнитуре и приступайте к чтению!



Стандарт DECT


А почему собственно DECT?, наверняка спросит нас читатель. Давайте рассмотрим стандарт DECT в целом и его преимущества и недостатки по сравнению с другими возможными вариантами.
DECT (англ. Digital Enhanced Cordless Telecommunication) технология беспроводной связи на частотах 18801900 МГц. Технология, на данный момент очень широко распространена в решениях беспроводных домашних и офисных телефонов, а также беспроводных гарнитур. Популярность DECT для передачи голоса обусловлена несколькими факторами:

  • Стандарт DECT изначально предназначен именно для передачи голоса и используется только с этой целью. Это означает что нет необходимости думать о приоритизации трафика или загруженности частотного диапазона, его будут занимать исключительно устройства для передачи голоса.
  • Дальность действия. Дальность действия устройств, работающих по данному протоколу, ограничена в первую очередь мощностью передатчика. Максимальная мощность по данному стандарту ограничена 10 мВт, что дает возможность разнесения приемного и передающего устройства до 300 м в прямой видимости и до 50 метров в помещениях. Переключения между источниками сигнала при этом осуществляются быстрее чем в том же Wi-Fi, не позволяя пользователю услышать, что переключение произошло. Говоря о дальности действия нельзя сказать, что она принципиально больше, чем у конкурирующих технологий, но радиус действия источника сигнала DECT достаточно большой, чтобы обеспечить пользователю свободу перемещений или построить сеть на основе множества источников сигнала, покрыв значительную площадь.
  • Количество каналов. А значит и количество одновременно работающих устройств. Стандарт DECT подразумевает наличие 10 частотных радиоканалов, казалось бы, немного. Но каждый из частотных каналов подразделяется на 12 временных каналов, давая в сумме больше сотни каналов для передачи голоса.

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

Распаковка и комплектация


Перейдем теперь к рассмотрению самой DECT-гарнитуры.



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



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



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



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

  • Кабель USB-Mini USB для подключения к ПК
  • Кабель RJ9-RJ9 для передачи аудио между телефоном и гарнитурой
  • Специализированный кабель EHS для подключения к телефонам Snom
  • Кабель EHS для подключения к стандартизированному разъему

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

Дизайн


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



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



Остальное управление гарнитурой осуществляется с базовой станции. Базовая станция гарнитуры выглядит также современно и элегантно.



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



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



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

Функционал и эксплуатация


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



С телефоном же все еще проще подключаем гарнитуру в соответствующие разъемы и начинаем пользоваться. Для переключения между устройствами мы используем клавиши PC и PHONE на базовой станции. При нажатии клавиши загорается зеленым ее индикатор и можно пользоваться гарнитурой в удобных нам целях.
Максимальное расстояние между гарнитурой и базой в процессе эксплуатации 50 метров. Этого более чем достаточно, чтобы чувствовать себя свободно в пределах достаточно просторного офиса и заметно больше, чем может дать Bluetooth гарнитура.
Качество передаваемого и принимаемого гарнитурой звука на высоте. Естественно, для прослушивания музыки желательно включить широкополосный режим на базовой станции. В этом случае вы не заметите разницы в сравнении с проводными гарнитурами, но сможете спокойно перемещаться по помещению.



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

Подведем итог


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

Как управлять облачной инфраструктурой с помощью Terraform

24.09.2020 10:22:34 | Автор: admin

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

Обо всем подробно и в три этапа:

1. Terraform описание, преимущества и составляющие

Terraform это IaC (Infrastructure-as-Code) инструмент для построения и управления виртуальной инфраструктурой с помощью кода .

В работе с инструментом мы отметили несколько преимуществ:

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

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

  • Возможность описывать большинство популярных облачных платформ. Вы можете использовать инструмент от Amazon и Google Cloud, до частных платформ на базе VMware vCloud Director, предлагающих услуги в рамках IaaS, SaaS и PaaS решений.

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

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

"Террариум" Terraform

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

Providers (провайдеры).

В Terraform практически любой тип инфраструктуры можно представить в качестве ресурса. Связь между ресурсами и платформой API обеспечивается providers модулями, которые позволяют создавать ресурсы в рамках определённой платформы, например, Azure или VMware vCloud Director.

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

Resources (описание ресурсов).

Описание ресурсов позволяет управлять компонентами платформы, например виртуальными машинами или сетями.

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

Provisioners.

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

Переменные Input и Output.

Input переменные входные переменные для любых типов блоков.

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

States (состояния).

States-файлы хранят информацию о конфигурации ресурсов платформы провайдера. При первом создании платформы никаких сведений о ресурсах нет и перед любой операцией Terraform обновляет состояние с реальной инфраструктурой уже описанных ресурсов.

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

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

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

2. Создание инфраструктуры

Составляющие разобрали, теперь с помощью Terraform мы поэтапно создадим инфраструктуру с тремя виртуальными машинами. Первая с установленным прокси-сервером nginx, вторая с файловым хранилищем на базе Nextcloud и третья с CMS Bitrix.

Писать код и исполнять его мы будем на примере нашего облака на VMware vCloud Director. У нас пользователи получают учётную запись правами Organization Administrator, если вы используете учетную запись с теми же правами в другом облаке VMware, то сможете воспроизвести код из наших примеров. Поехали!

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

mkdir project01

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

Для описания компонентов нашей инфраструктуры, мы создали следующие файлы:

Список файлов.

main.tf - описание параметров для виртуальной среды - виртуальные машины, виртуальные контейнеры;

network.tf - описание параметров виртуальной сети и правил NAT, Firewall;

variables.tf - список переменных, которые используем;

vcd.tfvars - значения переменных проекта для модуля VMware vCloud Director.

Язык конфигурации в Terraform является декларативным и порядок блоков не имеет значения, кроме блоков provisioner, т.к. в этом блоке мы описываем команды для выполнения при подготовке инфраструктуры и они будут выполнятся по порядку.

Структура блоков.

<BLOCK TYPE> "<BLOCK LABEL>" "<BLOCK LABEL>" {

# Block body

<IDENTIFIER> = <EXPRESSION> # Argument

}

Для описания блоков используется собственный язык программирования HCL (HashiCorp Configuration Language), возможно описывать инфраструктуру и с помощью JSON. Подробнее о синтаксисе можно прочитать на сайте разработчика.

Конфигурация переменной окружения, variables.tf и vcd.tfvars

Сначала создадим два файла, которые описывают список всех используемых переменных и их значений для модуля VMware vCloud Director. Первым создадим файл variables.tf.

Cодержимое файла variables.tf.

variable "vcdorguser" {

description = "vCD Tenant User"

}

variable "vcdorgpassword" {

description = "vCD Tenant Password"

}

variable "vcdorg" {

description = "vCD Tenant Org"

}

variable "vcdorgvdc" {

description = "vCD Tenant VDC"

}

variable "vcdorg_url" {

description = "vCD Tenant URL"

}

variable "vcdorgmaxretrytimeout" {

default = "60"

}

variable "vcdorgallowunverifiedssl" {

default = "true"

}

variable "vcdorgedgename" {

description = "vCD edge name"

}

variable "vcdorgcatalog" {

description = "vCD public catalog"

}

variable "vcdtemplateoscentos7" {

description = "OS CentOS 7"

default = "CentOS7"

}

variable "vcdorgssdsp" {

description = "Storage Policies"

default = "Gold Storage Policy"

}

variable "vcdorghddsp" {

description = "Storage Policies"

default = "Bronze Storage Policy"

}

variable "vcdedgelocalsubnet" {

description = "Organization Network Subnet"

}

variable "vcdedgeexternalip" {

description = "External public IP"

}

variable "vcdedgelocalipnginx" {}

variable "vcdedgelocalipbitrix" {}

variable "vcdedgelocalC11Cnextcloud" {}

variable "vcdC12Cexternal_network" {}

Значения переменных, которые мы получаем от провайдера.
  • vcd_org_user - имя пользователя с правами Organization Administrator,

  • vcd_org_password - пароль пользователя,

  • vcd_org - название организации,

  • vcd_org_vdc - название виртуального дата-центра,

  • vcd_org_url - API URL,

  • vcd_org_edge_name - название виртуального маршрутизатора,

  • vcd_org_catalog - название каталога с шаблонами виртуальных машин,

  • vcd_edge_external_ip - публичный IP-адрес,

  • vcd_edge_external_network - название внешней сети,

  • vcd_org_hdd_sp - название политики хранения HDD,

  • vcd_org_ssd_sp - название политики хранения SSD.

И вводим свои переменные:

  • vcdedgelocalipnginx - IP-адрес виртуальной машины с NGINX,

  • vcdedgelocalipbitrix - IP-адрес виртуальной машины с 1С: Битрикс,

  • vcdedgelocalipnextcloud - IP-адрес виртуальной машины с Nextcloud.

Вторым файлом создаем и указываем переменные для модуля VMware vCloud Director в файле vcd.tfvars: Напомним, что в нашем примере мы используем собственное облако mClouds, если вы работаете с другим провайдером уточните значения у него.

Содержимое файла vcd.tfvars.

vcdorgurl = "https://vcloud.mclouds.ru/api"

vcdorguser = "orgadmin"

vcdorgpassword = "*"

vcd = "org"

vcdorgvdc = "orgvdc"

vcdorgmaxretrytimeout = 60

vcdorgallowunverifiedssl = true

vcdorgcatalog = "Templates"

vcdtemplateos_centos7 = "CentOS7"

vcdorgssdsp = "Gold Storage Policy"

vcdorghddsp = "Bronze Storage Policy"

vcdorgedgename = "MCLOUDS-EDGE"

vcdedgeexternalip = "185.17.66.1"

vcdedgelocalsubnet = "192.168.110.0/24"

vcdedgelocalipnginx = "192.168.110.1"

vcdedgelocalipbitrix = "192.168.110.10"

vcdedgelocalipnextcloud = "192.168.110.11"

vcdedgeexternal_network = "NET-185-17-66-0"

Сетевая конфигурация, network.tf.

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

Схема сети для создаваемой Terraform платформыСхема сети для создаваемой Terraform платформы

Создаем виртуальную организационную сеть с названием net_lan01, шлюзом по умолчанию: 192.168.110.254, а также с адресным пространством: 192.168.110.0/24.

Описываем виртуальную сеть.

resource "vcdnetworkrouted" "net" {

name = "netlan01"

edgegateway = var.vcdorgedgename

gateway = "192.168.110.254"

dns1 = "1.1.1.1"

dns2 = "8.8.8.8"

staticippool {

startaddress = "192.168.110.1"

end_address = "192.168.110.253"

}

}

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

Описываем правила для доступа VM в интернет.

resource "vcdnsxvfirewallrule" "fwinternetaccess" {

edgegateway = var.vcdorgedgename

name = "Internet Access"

source {

gatewayinterfaces = ["internal"]

}

destination {

gatewayinterfaces = ["external"]

}

service {

protocol = "any"

}

dependson = [vcdnetworkrouted.net]

}

Установив зависимость, что после обработки блока vcdnetworkrouted.net мы приступаем к конфигурации блока vcdnsxvfirewallrule, с помощью dependson. Используем эту опцию, так как некоторые зависимости могут быть распознаны неявно в конфигурации.

Далее создадим правила разрешающее доступ к портам из внешней сети и указываем наш IP-адрес для подключения по SSH к серверам. Любой пользователь сети Интернет имеет доступ к портам 80 и 443 на веб-сервере и пользователь с IP-адресом 90.1.15.1 имеет доступ к портам SSH виртуальных серверов.

Разрешаем доступ к портам из внешней сети.

resource "vcdnsxvfirewallrule" "fwnatports" {

edgegateway = var.vcdorgedgename

name = "HTTPs Access"

source {

gatewayinterfaces = ["external"]

}

destination {

gateway_interfaces = ["internal"]

}

service {

protocol = "tcp"

port = "80"

}

service {

protocol = "tcp"

port = "443"

}

dependson = [vcdnetworkrouted.net]

}

resource "vcdnsxvfirewallrule" "fwnatadminports" {

edgegateway = var.vcdorgedgename

name = "Admin Access"

source {

ipaddresses = [ "90.1.15.1" ]

}

destination {

gatewayinterfaces = ["internal"]

}

service {

protocol = "tcp"

port = "58301"

}

service {

protocol = "tcp"

port = "58302"

}

service {

protocol = "tcp"

port = "58303"

}

depends_on = [vcdnetworkrouted.net]

}

Создаём правила Source NAT для доступа в сеть Интернет из облачной локальной сети:

Описываем правила Source NAT.

resource "vcdnsxvsnat" "snatlocal" {

edgegateway = var.vcdorgedgename

networktype = "ext"

networkname = var.vcdedgeexternalnetwork

originaladdress = var.vcdedgelocalsubnet

translatedaddress = var.vcdedgeexternalip

dependson = [vcdnetwork_routed.net]

}

И в завершении конфигурации сетевого блока добавляем правила Destination NAT для доступа к сервисам из внешней сети:

Добавляем правила Destination NAT.

resource "vcd_nsxv_dnat" "dnat_tcp_nginx_https" { edge_gateway = var.vcd_org_edge_name network_name = var.vcd_edge_external_network network_type = "ext"

description = "NGINX HTTPs"

original_address = var.vcd_edge_external_ip original_port = 443

translated_address = var.vcd_edge_local_ip_nginx translated_port= 443 protocol = "tcp"

depends_on = [vcd_network_routed.net]}resource "vcd_nsxv_dnat" "dnat_tcp_nginx_http" { edge_gateway = var.vcd_org_edge_name network_name = var.vcd_edge_external_network network_type = "ext"

description = "NGINX HTTP"

original_address = var.vcd_edge_external_ip original_port = 80

translated_address = var.vcd_edge_local_ip_nginx translated_port= 80 protocol = "tcp"

depends_on = [vcd_network_routed.net]

}

Добавляем правило NAT для трансляции портов к SSH-серверу под Nginx.

resource "vcd_nsxv_dnat" "dnat_tcp-nginx_ssh" { edge_gateway = var.vcd_org_edge_name network_name = var.vcd_edge_external_network network_type = "ext"

description = "SSH NGINX"

original_address = var.vcd_edge_external_ip original_port = 58301

translated_address = var.vcd_edge_local_ip_nginx translated_port= 22 protocol = "tcp"

depends_on = [vcd_network_routed.net]

}

Добавляем правило NAT для трансляции портов к SSH-серверу с 1С-Битрикс.

resource "vcd_nsxv_dnat" "dnat_tcp_bitrix_ssh" { edge_gateway = var.vcd_org_edge_name network_name = var.vcd_edge_external_network network_type = "ext"

description = "SSH Bitrix"

original_address = var.vcd_edge_external_ip original_port = 58302

translated_address = var.vcd_edge_local_ip_bitrix translated_port= 22 protocol = "tcp"

depends_on = [vcd_network_routed.net]

}

Добавляем правило NAT для трансляции портов к SSH-серверу с Nextcloud.

resource "vcd_nsxv_dnat" "dnat_tcp_nextcloud_ssh" { edge_gateway = var.vcd_org_edge_name network_name = var.vcd_edge_external_network network_type = "ext"

description = "SSH Nextcloud"

original_address = var.vcd_edge_external_ip original_port = 58303 translated_address = var.vcd_edge_local_ip_nextcloud translated_port= 22 protocol = "tcp"

depends_on = [vcd_network_routed.net]

}

Конфигурация виртуальной среды main.tf

Как мы и планировали в начале статьи, создадим три виртуальные машины. Они будут подготовлены с помощью "Guest Customization". Сетевые параметры пропишем согласно указанным нами настройками, а пароль от пользователя генерируется автоматически.

Опишем vApp в котором будут находится виртуальные машины и их конфигурацию.

Конфигурация виртуальных машинКонфигурация виртуальных машин

Создадим контейнер vApp. Чтобы мы могли сразу же подключить vApp и ВМ к виртуальной сети также добавляем параметр depends_on:

Создаем контейнер

resource "vcd_vapp" "vapp" { name = "web" power_on = "true" depends_on = [vcd_network_routed.net]

}

Создадим виртуальную машину с описанием

resource "vcd_vapp_vm" "nginx" {

vapp_name = vcd_vapp.vapp.name

name = "nginx"

catalog_name = var.vcd_org_catalog

template_name = var.vcd_template_os_centos7

storage_profile = var.vcd_org_ssd_sp

memory = 8192

cpus = 1

cpu_cores = 1

network {

type = "org"

name = vcd_network_routed.net.name

is_primary = true

adapter_type = "VMXNET3"

ip_allocation_mode = "MANUAL"

ip = var.vcd_edge_local_ip_nginx

}

override_template_disk {

bus_type = "paravirtual"

size_in_mb = "32768"

bus_number = 0

unit_number = 0

storage_profile = var.vcd_org_ssd_sp

}

}

Основные параметры в описании VM:

  • name - имя виртуальной машины,

  • vappname - название vApp в который добавить новую ВМ,

  • catalogname / templatename - название каталога и название шаблона виртуальной машины,

  • storageprofile - политика хранения по умолчанию.

Параметры блока network:

  • type - тип подключаемой сети,

  • name - к какой виртуальной сети подключить ВМ,

  • isprimary - основной сетевой адаптер,

  • ipallocation_mode - режим выделения адреса MANUAL / DHCP / POOL,

  • ip - IP-адрес для виртуальной машины, укажем вручную.

Блок override_template_disk:

  • sizeinmb - размер boot-диска для виртуальной машины

  • storage_profile - политика хранения для диска

Создадим вторую VM с описанием файлового хранилища Nextcloud

resource "vcd_vapp_vm" "nextcloud" {

vapp_name = vcd_vapp.vapp.name

name = "nextcloud"

catalog_name = var.vcd_org_catalog

template_name = var.vcd_template_os_centos7

storage_profile = var.vcd_org_ssd_sp

memory = 8192

cpus = 1

cpu_cores = 1

network {

type = "org"

name = vcd_network_routed.net.name

is_primary = true

adapter_type = "VMXNET3"

ip_allocation_mode = "MANUAL"

ip = var.vcd_edge_local_ip_nextcloud

}

override_template_disk {

bus_type = "paravirtual"

size_in_mb = "32768"

bus_number = 0

unit_number = 0

storage_profile = var.vcd_org_ssd_sp

}

}

resource "vcd_vm_internal_disk" "disk1" {

vapp_name = vcd_vapp.vapp.name

vm_name = "nextcloud"

bus_type = "paravirtual"

size_in_mb = "102400"

bus_number = 0

unit_number = 1

storage_profile = var.vcd_org_hdd_sp

allow_vm_reboot = true

depends_on = [ vcd_vapp_vm.nextcloud ]

}

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

Пояснения по блоку vcdvminternaldisk:

  • bustype - тип дискового контроллера

  • sizeinmb - размер диска

  • busnumber / unitnumber - место подключения в адаптере

  • storage_profile - политика хранения для диска

Опишем последнюю VM на Битрикс

resource "vcd_vapp_vm" "bitrix" {

vapp_name = vcd_vapp.vapp.name

name = "bitrix"

catalog_name = var.vcd_org_catalog

template_name = var.vcd_template_os_centos7

storage_profile = var.vcd_org_ssd_sp

memory = 8192

cpus = 1

cpu_cores = 1

network {

type = "org"

name = vcd_network_routed.net.name

is_primary = true

adapter_type = "VMXNET3"

ip_allocation_mode = "MANUAL"

ip = var.vcd_edge_local_ip_bitrix

}

override_template_disk {

bus_type = "paravirtual"

size_in_mb = "81920"

bus_number = 0

unit_number = 0

storage_profile = var.vcd_org_ssd_sp

}

}

Обновление ОС и установка дополнительных скриптов

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

Рассмотрим как обновить ОС и запустить установочный скрипт CMS Bitrix с помощью provisioner блока.

Сначала выполним установку пакетов обновления CentOS.

resource "null_resource" "nginx_update_install" {

provisioner "remote-exec" {

connection {

type = "ssh"

user = "root"

password = vcd_vapp_vm.nginx.customization[0].admin_password

host = var.vcd_edge_external_ip

port = "58301"

timeout = "30s"

}

inline = [

"yum -y update && yum -y upgrade",

"yum -y install wget nano epel-release net-tools unzip zip" ]

}

}

}

Обозначение составляющих:

  • provisioner "remote-exec" - подключаем блок удаленного "провижининга"

  • В блоке connection описываем тип и параметры для подключения:

  • type - протокол, в нашем случае SSH;

  • user - имя пользователя;

  • password - пароль пользователя. В нашем случае указываем на параметр vcdvappvm.nginx.customization[0].admin_password, который хранит сгенерированный пароль от пользователя системы.

  • host - внешний IP-адрес для подключения;

  • port - порт для подключения, который ранее указывали в настройках DNAT;

  • inline - перечисляем список команд, которые будут вводится. Команды будут введены по порядку, как и указано в этой секции.

Как пример, дополнительно выполним скрипт установки 1С-Битрикс. Вывод результата выполнения скрипта будет доступен во время выполнения плана. Для установки скрипта, сначала опишем блок:

Опишем установку 1С-Битрикс.

provisioner "file" {

source = "prepare.sh"

destination = "/tmp/prepare.sh"

connection {

type = "ssh"

user = "root"

password = vcd_vapp_vm.nginx.customization[0].admin_password

host = var.vcd_edge_external_ip

port = "58301"

timeout = "30s"

}

}

provisioner "remote-exec" {

inline = [

"chmod +x /tmp/prepare.sh", "./tmp/prepare.sh"

]

}

И сразу же опишем обновление Битрикс.

Пример провижининга 1С-Битрикс.

resource "null_resource" "install_update_bitrix" {

provisioner "remote-exec" {

connection {

type = "ssh"

user = "root"

password = vcd_vapp_vm.bitrix.customization[0].admin_password

host = var.vcd_edge_external_ip

port = "58302"

timeout = "60s"

}

inline = [

"yum -y update && yum -y upgrade",

"yum -y install wget nano epel-release net-tools unzip zip",

"wget http://repos.1c-bitrix.ru/yum/bitrix-env.sh -O /tmp/bitrix-env.sh",

"chmod +x /tmp/bitrix-env.sh",

"/tmp/bitrix-env.sh"

]

}

}

Важно! Скрипт может не сработать, если не отключить заранее SELinux! Если вам требуется подробная статья по установке и настройке CMS 1С-Битрикс с помощью bitrix-env.sh, оо вы можете воспользоваться нашей статьей в блоге на сайте.

3. Инициализация инфраструктуры

Инициализация модулей и плагиновИнициализация модулей и плагинов

Для работы мы используем простой джентельменский набор: лэптоп с ОС Windows 10 и дистрибутив с официального сайта terraform.io. Распакуем и проинициализируем с помощью команды: terraform.exe init

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

  1. Выполняем команду - terraform plan -var-file=vcd.tfvars.

  2. Получаем результат - Plan: 16 to add, 0 to change, 0 to destroy. То есть по этому плану будет создано 16 ресурсов.

  3. Запускаем план по команде - terraform.exe apply -var-file=vcd.tfvars.

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

Получение данных для подключения

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

output "nginxpassword" {

value = vcdvappvm.nginx.customization[0].adminpassword

}

И следующий вывод сообщает нам пароль от созданной виртуальной машины:

Outputs: nginx_password = F#4u8!!N

В итоге мы получаем доступ к виртуальным машинам с обновлённой операционной системой и предустановленными пакетами для нашей дальнейшей работы. Все готово!

Но что если у вас уже есть существующая инфраструктура?

3.1. Работа Terraform с уже существующей инфраструктурой

Всё просто, вы можете импортировать текущие виртуальные машины и их vApp контейнеры с помощью команды import.

Опишем ресурс vAPP и виртуальную машину.

resource "vcd_vapp" "Monitoring" {

name = "Monitoring"

org = "mClouds"

vdc = "mClouds"

}

resource "vcd_vapp_vm" "Zabbix" {

name = "Zabbix"

org = "mClouds"

vdc = "mClouds"

vapp = "Monitoring"

}

Следующий шаг, это выполнить импорт свойств ресурсов vApp в формате vcdvapp.<vApp> <org>.<orgvdc>.<vApp>, где:

  • vApp - имя vApp;

  • org - название организации;

  • org_vdc - название виртуального дата-центра.

Импорт свойств ресурса vAPPИмпорт свойств ресурса vAPP

Выполним импорт свойств ресурсов VM в формате: vcdvappvm.<VM> <org>.<orgvdc>.<vApp>.<VM>, в котором:

  • VM - имя VM;

  • vApp - имя vApp;

  • org - название организации;

  • orgvdc - название виртуального дата-центра.

Импорт прошел успешно

C:\Users\Mikhail\Desktop\terraform>terraform import vcd_vapp_vm.Zabbix mClouds.mClouds.Monitoring.Zabbix

vcd_vapp_vm.Zabbix: Importing from ID "mClouds.mClouds.Monitoring.Zabbix"...

vcd_vapp_vm.Zabbix: Import prepared!

Prepared vcd_vapp_vm for import

vcd_vapp_vm.Zabbix: Refreshing state... [id=urn:vcloud:vm:778f4a89-1c8d-45b9-9d94-0472a71c4d1f]

Import successful!

The resources that were imported are shown above. These resources are now inyour Terraform state and will henceforth be managed by Terraform.

Теперь мы можем посмотреть на новый импортированный ресурс:

Импортированный ресурс

> terraform show

...

# vcd_vapp.Monitoring:

resource "vcd_vapp" "Monitoring" {

guest_properties = {}

href = "https://vcloud.mclouds.ru/api/vApp/vapp-fe5db285-a4af-47c4-93e8-55df92f006ec"

id = "urn:vcloud:vapp:fe5db285-a4af-47c4-93e8-55df92f006ec"

ip = "allocated"

metadata = {}

name = "Monitoring"

org = "mClouds"

status = 4

status_text = "POWERED_ON"

vdc = "mClouds"

}

# vcd_vapp_vm.Zabbix:

resource "vcd_vapp_vm" "Zabbix" {

computer_name = "Zabbix"

cpu_cores = 1

cpus = 2

expose_hardware_virtualization = false

guest_properties = {}

hardware_version = "vmx-14"

href = "https://vcloud.mclouds.ru/api/vApp/vm-778f4a89-1c8d-45b9-9d94-0472a71c4d1f"

id = "urn:vcloud:vm:778f4a89-1c8d-45b9-9d94-0472a71c4d1f"

internal_disk = [

{

bus_number = 0

bus_type = "paravirtual"

disk_id = "2000"

iops = 0

size_in_mb = 122880

storage_profile = "Gold Storage Policy"

thin_provisioned = true

unit_number = 0

},

]

memory = 8192

metadata = {}

name = "Zabbix"

org = "mClouds"

os_type = "centos8_64Guest"

storage_profile = "Gold Storage Policy"

vapp_name = "Monitoring"

vdc = "mClouds"

customization {

allow_local_admin_password = true

auto_generate_password = true

change_sid = false

enabled = false

force = false

join_domain = false

join_org_domain = false

must_change_password_on_first_login = false

number_of_auto_logons = 0

}

network {

adapter_type = "VMXNET3"

ip_allocation_mode = "DHCP"

is_primary = true

mac = "00:50:56:07:01:b1"

name = "MCLOUDS-LAN01"

type = "org"

}

}

Теперь точно готово - мы закончили с последним моментом (импорт в существующую инфраструктуру) ирассмотрели все основные моменты работы с Terraform.

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

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

Подробнее..

Дружим ELK и Exchange. Часть 2

24.09.2020 18:11:15 | Автор: admin


Я продолжаю свой рассказ о том, как подружить Exchange и ELK (начало тут). Напомню, что эта комбинация способна без колебаний обрабатывать очень большое количество логов. На это раз мы поговорим о том, как наладить работу Exchange с компонентами Logstash и Kibana.

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

Установка


Состоит из двух этапов:
Установка и настройка пакета OpenJDK.
Установка и настройка пакета Logstash.

Установка и настройка пакета OpenJDK
Пакет OpenJDK необходимо скачать и распаковать в определённую директорию. Затем путь до этой директории необходимо внести в переменные $env:Path и $env:JAVA_HOME операционной системы Windows:



Проверим версию Java:

PS C:\> java -versionopenjdk version "13.0.1" 2019-10-15OpenJDK Runtime Environment (build 13.0.1+9)OpenJDK 64-Bit Server VM (build 13.0.1+9, mixed mode, sharing)

Установка и настройка пакета Logstash


Файл-архив с дистрибутивом Logstash скачайте отсюда. Архив нужно распаковать в корень диска. Распаковывать в папку C:\Program Files не стоит, Logstash откажется нормально запускаться. Затем необходимо внести в файл jvm.options правки, отвечающие за выделение оперативной памяти для процесса Java. Рекомендую указать половину оперативной памяти сервера. Если у него на борту 16 Гб оперативки, то ключи по умолчанию:

-Xms1g-Xmx1g

необходимо заменить на:

-Xms8g-Xmx8g

Кроме этого, целесообразно закомментировать строку -XX:+UseConcMarkSweepGC. Подробнее об этом тут. Следующий шаг создание конфигурации по умолчанию в файле logstash.conf:

input { stdin{}} filter {} output { stdout { codec => "rubydebug" }}

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

PS C:\...\bin> .\logstash.bat -f .\logstash.conf...[2019-12-19T11:15:27,769][INFO ][logstash.javapipeline    ][main] Pipeline started {"pipeline.id"=>"main"}The stdin plugin is now waiting for input:[2019-12-19T11:15:27,847][INFO ][logstash.agent           ] Pipelines running {:count=>1, :running_pipelines=>[:main], :non_running_pipelines=>[]}[2019-12-19T11:15:28,113][INFO ][logstash.agent           ] Successfully started Logstash API endpoint {:port=>9600}

Logstash успешно запустился на порту 9600.

Финальный шаг установки: запуск Logstash в виде сервиса Windows. Это можно сделать, например, с помощью пакета NSSM:

PS C:\...\bin> .\nssm.exe install logstashService "logstash" installed successfully!

Отказоустойчивость


Сохранность логов при передаче с исходного сервера обеспечивается механизмом Persistent Queues.

Как работает


Схема расположения очередей в процессе обработки логов: input queue filter + output.

Плагин input получает данные от источника логов, записывает их в очередь и отправляет источнику подтверждение получения данных.

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

Настройка


Регулируется ключами в файле C:\Logstash\config\logstash.yml:

queue.type: (возможные значения persisted и memory (default)).
path.queue: (путь до папки с файлами очередей, которые по умолчанию хранятся в C:\Logstash\queue).
queue.page_capacity: (максимальный размер страницы очереди, значение по умолчанию 64mb).
queue.drain: (true/false включает/выключает остановку обработки очереди перед выключением Logstash. Не рекомендую включать, потому что это прямо скажется на скорости выключения сервера).
queue.max_events: (максимально число событий в очереди, по умолчанию 0 (не ограничено)).
queue.max_bytes: (максимальный размер очереди в байтах, по умолчанию 1024mb (1gb)).

Если настроены queue.max_events и queue.max_bytes, то сообщения перестают приниматься в очередь при достижении значения любой из этих настроек. Подробнее про Persistent Queues рассказано тут.

Пример части logstash.yml, отвечающей за настройку очереди:

queue.type: persistedqueue.max_bytes: 10gb

Настройка


Конфигурация Logstash обычно состоит из трёх частей, отвечающих за разные фазы обработки входящий логов: приём (секция input), парсинг (секция filter) и отправка в Elastic (секция output). Ниже мы подробнее рассмотрим каждую из них.

Input


Входящий поток с сырыми логами принимаем от агентов filebeat. Именно этот плагин мы и указываем в секции input:

input {  beats {    port => 5044  }}

После такой настройки Logstash начинает прослушивать порт 5044, и при получении логов обрабатывает их согласно настройкам секции filter. При необходимости можно канал получения логов от filebit завернуть в SSL. Подробнее о настройках плагина beats написано тут.

Filter


Все интересные для обработки текстовые логи, которые генерирует Exchange, имеют csv-формат с описанными в самом файле логов полями. Для парсинга csv-записей Logstash предлагает нам три плагина: dissect, csv и grok. Первый самый быстрый, но справляется с парсингом только самых простых логов.
Например, следующую запись он разобьёт на две (из-за наличия внутри поля запятой), из-за чего лог будет разобран неправильно:

,"MDB:GUID1, Mailbox:GUID2, Event:526545791, MessageClass:IPM.Note, CreationTime:2020-05-15T12:01:56.457Z, ClientType:MOMT, SubmissionAssistant:MailboxTransportSubmissionEmailAssistant",

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

filter {  if "IIS" in [tags] {    dissect {      mapping => {        "message" => "%{date} %{time} %{s-ip} %{cs-method} %{cs-uri-stem} %{cs-uri-query} %{s-port} %{cs-username} %{c-ip} %{cs(User-Agent)} %{cs(Referer)} %{sc-status} %{sc-substatus} %{sc-win32-status} %{time-taken}"      }      remove_field => ["message"]      add_field => { "application" => "exchange" }    }  }} 

Конфигурация Logstash позволяет использовать условные операторы, поэтому мы в плагин dissect можем направить только логи, которые были помечены filebeat тэгом IIS. Внутри плагина мы сопоставляем значения полей с их названиями, удаляем исходное поле message, которое содержало запись из лога, и можем добавить произвольное поле, которое будет, например, содержать имя приложения из которого мы собираем логи.

В случае с логами трэкинга лучше использовать плагин csv, он умеет корректно обрабатывать сложные поля:

filter {  if "Tracking" in [tags] {    csv {      columns => ["date-time","client-ip","client-hostname","server-ip","server-hostname","source-context","connector-id","source","event-id","internal-message-id","message-id","network-message-id","recipient-address","recipient-status","total-bytes","recipient-count","related-recipient-address","reference","message-subject","sender-address","return-path","message-info","directionality","tenant-id","original-client-ip","original-server-ip","custom-data","transport-traffic-type","log-id","schema-version"]      remove_field => ["message", "tenant-id", "schema-version"]      add_field => { "application" => "exchange" }    }}

Внутри плагина мы сопоставляем значения полей с их названиями, удаляем исходное поле message (а также поля tenant-id и schema-version), которое содержало запись из лога, и можем добавить произвольное поле, которое будет, например, содержать имя приложения из которого мы собираем логи.

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

Числовые поля будут распознаны как текст, что не позволяет выполнять операции с ними. А именно, поля time-taken лога IIS, а также поля recipient-count и total-bites лога Tracking.
Стандартный временной штамп документа будет содержать время обработки лога, а не время записи его на стороне сервера.
Поле recipient-address будет выглядеть одной стройкой, что не позволяет проводить анализ с подсчётом получателей писем.

Настало время добавить немного магии в процесс обработки логов.

Конвертация числовых полей


Плагин dissect имеет опцию convert_datatype, которую можно использовать для конвертации текстового поля в цифровой формат. Например, так:

dissect {    convert_datatype => { "time-taken" => "int" }  }

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

Для логов трэкинга аналогичный метод convert лучше не использовать, так как поля recipient-count и total-bites могут быть пустыми. Для конвертации этих полей лучше использовать плагин mutate:

mutate {  convert => [ "total-bytes", "integer" ]  convert => [ "recipient-count", "integer" ]}

Разбиение recipient_address на отдельных получателей


Эту задачу можно также решить с помощью плагина mutate:

mutate {  split => ["recipient_address", ";"]}

Изменяем timestamp


В случае с логами трэкинга задача очень просто решается плагином date, который поможет прописать в поле timestamp дату и время в нужном формате из поля date-time:

date {  match => [ "date-time", "ISO8601" ]  timezone => "Europe/Moscow"  remove_field => [ "date-time" ]}

В случае с логами IIS нам будет необходимо объединить данные полей date и time с помощью плагина mutate, прописать нужную нам временную зону и поместить этот временной штамп в timestamp с помощью плагина date:

mutate {   add_field => { "data-time" => "%{date} %{time}" }  remove_field => [ "date", "time" ]}date {   match => [ "data-time", "YYYY-MM-dd HH:mm:ss" ]  timezone => "UTC"  remove_field => [ "data-time" ]}

Output


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

output {  elasticsearch {    hosts => ["127.0.0.1:9200", "127.0.0.2:9200"]    manage_template => false    index => "Exchange-%{+YYYY.MM.dd}"  }}

Итоговая конфигурация


Итоговая конфигурация будет выглядеть следующим образом:

input {  beats {    port => 5044  }} filter {  if "IIS" in [tags] {    dissect {      mapping => {        "message" => "%{date} %{time} %{s-ip} %{cs-method} %{cs-uri-stem} %{cs-uri-query} %{s-port} %{cs-username} %{c-ip} %{cs(User-Agent)} %{cs(Referer)} %{sc-status} %{sc-substatus} %{sc-win32-status} %{time-taken}"      }      remove_field => ["message"]      add_field => { "application" => "exchange" }      convert_datatype => { "time-taken" => "int" }    }    mutate {       add_field => { "data-time" => "%{date} %{time}" }      remove_field => [ "date", "time" ]    }    date {       match => [ "data-time", "YYYY-MM-dd HH:mm:ss" ]      timezone => "UTC"      remove_field => [ "data-time" ]    }  }  if "Tracking" in [tags] {    csv {      columns => ["date-time","client-ip","client-hostname","server-ip","server-hostname","source-context","connector-id","source","event-id","internal-message-id","message-id","network-message-id","recipient-address","recipient-status","total-bytes","recipient-count","related-recipient-address","reference","message-subject","sender-address","return-path","message-info","directionality","tenant-id","original-client-ip","original-server-ip","custom-data","transport-traffic-type","log-id","schema-version"]      remove_field => ["message", "tenant-id", "schema-version"]      add_field => { "application" => "exchange" }    }    mutate {      convert => [ "total-bytes", "integer" ]      convert => [ "recipient-count", "integer" ]      split => ["recipient_address", ";"]    }    date {      match => [ "date-time", "ISO8601" ]      timezone => "Europe/Moscow"      remove_field => [ "date-time" ]    }  }} output {  elasticsearch {    hosts => ["127.0.0.1:9200", "127.0.0.2:9200"]    manage_template => false    index => "Exchange-%{+YYYY.MM.dd}"  }}

Полезные ссылки:

How to install OpenJDK 11 on Windows?
Download Logstash
Elastic uses depricated option UseConcMarkSweepGC #36828
NSSM
Persistent Queues
Beats input plugin
Logstash Dude, where's my chainsaw? I need to dissect my logs
Dissect filter plugin
Conditionals
Mutate filter plugin
Date filter plugin
Elasticsearch output plugin
Подробнее..

Конфигурация корпоративного мобильного приложения с помощью AppConfig

25.09.2020 16:06:58 | Автор: admin
Если вы администратор в компании, где есть внутреннее мобильное приложение, неважно для чего будь то обычный мессенджер или почта, или что-то особенное наподобие сканера штрих-кодов рано или поздно перед вами встанет задача удаленной настройки и менеджмента приложений. Прописать конкретный id или адрес сервера во всех телефонах можно при помощи костылей, но есть и готовое решение де-факто уже стандарт, который можно использовать совместно с одной из существующих EMM/UEM-платформ (Enterprise Mobile Management/Unified Endpoint Management).

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



Постановка задачи


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

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

Обычно, при внедрении централизованных систем мы сталкиваемся с двумя задачами:

  1. Первичное подключение устройства к системе. Тут всё достаточно просто, уже давно существуют стандартные инструменты для этого: Knox Mobile Enrollment, Android Zero Touch и Android Enterprise Enrollment (EMM-токен, QR-коды и пр.)
  2. Первичная настройка необходимых корпоративных приложений. Этот момент гораздо сложнее, так как у разных приложений совершенно разные параметры и настройки, и знать их все заранее невозможно

Общая схема решения


В качестве решения второй задачи существует механизм AppConfig, это не инициатива какой-то единичной компании, а действующая конвенция нескольких вендоров. Его суть кратко такова: разработчик реализует в своем мобильном приложении почте, мессенджере, клиенте видеосвязи и т.д. поддержку управляемых конфигураций (Managed Configurations), настраиваемых под конкретного пользователя. Разработчик решает, какие именно параметры в приложении можно задавать извне (идентификатор, имя пользователя, адрес сервера). Через корпоративный Google Play эти параметры попадают в EMM-систему. А она уже позволяет создавать управляемые конфигурации и удаленно назначать их определенным устройствам и пользователям.

Чтобы узнать, реализован ли такой функционал в конкретном приложении:

  • Перейдите в корпоративный Google Play.
  • Найдите нужное приложение.
  • Если оно поддерживает управляемые конфигурации, то под названием увидите значок Это приложение можно настроить удаленно:



Общий процесс выглядит так:

  1. Разработчик добавляет поддержку управляемых конфигураций в свое приложение. В файле схемы XML он указывает параметры, настраиваемые удаленно, и в коде приложения обеспечивает развертывание этих параметров. Затем выкладывает приложение в корпоративный Google Play.
  2. EMM-система предоставляет интерфейс для администратора, через который XML-схема извлекается из приложения в Google Play при помощи iframe.
  3. Администратор вводит значения параметров, которые должны оказаться на корпоративных устройствах. После этого EMM-система передает конфигурацию в Google Play.
  4. Google Play обновляет приложение на всех корпоративных устройствах в соответствии с новой конфигурацией.



Процесс адаптации корпоративного мобильного приложения к AppConfig

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



Для поля Email address вводим $emailaddress$, а для имени пользователя User name задаем $username$ (эти переменные будут подставляться динамически, в зависимости от конкретного пользователя).

Как разработчику добавить поддержку AppConfig в свое приложение?


Предположим, что мы разрабатываем мобильное приложение, в котором настраиваемый параметр адрес сервера. Согласно рекомендациям Google, разработчик должен:

  1. Найти файл ресурсов XML, который обычно находится в папке проекта res/xml. В нем информация о всех настраиваемых параметрах, которая потом попадает в EMM-систему через Google Play APIs.

    <?xmlversion="1.0"encoding="utf-8"?><restrictionsxmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android"><restriction android:key="address"android:title="@string/title" android:restrictionType="string" android:description="@string/description" android:defaultValue="sampleaddress"/> </restrictions>
    
  2. Явно указать файл app_restrictions.xml в манифесте вашего приложения внутри тега application.

    <application android:allowBackup="true" android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:roundIcon="@mipmap/ic_launcher_round" android:supportsRtl="true" android:theme="@style/AppTheme"> <meta-dataandroid:name="android.content.APP_RESTRICTIONS" android:resource="@xml/app_restrictions"/>
    
  3. Реализовать обработку события ACTION_APPLICATION_RESTRICTIONS_CHANGED в коде приложения. Это шаг гарантирует, что приложение получит новое значение, определенное администратором.

    IntentFilterrestrictionFilter=newIntentFilter(Intent.ACTION_APPLICATION_RESTRICTIONS_CHANGED);BroadcastReceiverrestrictionReciever=newBroadcastReceiver(){@OverridepublicvoidonReceive(Contextcontext,Intentintent){BundleappRestrictions=restrictionsManager.getApplicationRestrictions();/*Fetchthevaluesofmanagedapplicationconfigurationfromthisbundleandtakeactioninyourappaccordingly.*/}};
    


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


Приложение до и после получения конфигурации с сервера

Как администратору сконфигурировать приложение через консоль Knox Manage?


Чтобы задать управляющие конфигурации, администратору нужно добавить само приложение через Knox Manage (KM) из корпоративного магазина Google Play, либо загрузить его со своего компьютера, как Managed Google Play Private (тогда публикация в корпоративный Google Play необязательна). Для задания новой конфигурации:

  1. В KM открываем вкладку Group, выбираем группу, привязанную к вашему устройству и нажимаем кнопку Application

  2. Теперь выбираем ваше приложение и нажимаем Assign

  3. В качестве Target Device выбираем Android Enterprise. Нажимаем на кнопку Set Configuration.

  4. Если вы все сделали правильно и ваше приложение имеет поддержку AppConfig, то KM заполнит нужные параметры значениями. Просто вводим адрес сервера (не забываем ввести имя конфигурации) и нажимаем кнопку Save.

  5. Нажимаем кнопку Assign, чтобы загрузить новую конфигурацию на устройство.

  6. Нажимаем OK для подтверждения.


Если приложение запущено, и разработчик корректно реализовал поддержку AppConfig, то приложение получит новый адрес сервера, заданный в консоли KM.


Приложение с введенным через консоль KM адресом сервера

Конфигурируем не только приложения, но и само устройство


В какой-то момент разработчики задумались: а что, если мы хотим настраивать не только приложения, но и параметры самого устройства аналогичным способом? OEMConfig это новый стандарт для отправки конфигураций приложениям, написанным производителями устройств. Отправка производится посредством той же самой схемы в XML-формате. Этому стандарту следуют изготовители оборудования Android, что позволяет предоставить администраторам дополнительные возможности управления устройством. Так, на смартфонах Samsung с поддержкой Knox существует решение Knox Service Plugin (KSP), его можно загрузить из Google Play. Но об этом мы поговорим в другой раз.

Итог


  • Используйте AppConfig для поддержки управляемых конфигураций вашими приложениями. Это довольно просто реализовать, а главное может быть реально полезным.
  • Cоздавайте новую конфигурацию и отправляйте ее на устройства большого числа пользователей при помощи EMM-системы (в нашем примере Knox Manage).
  • Как можно меньше костылей, пользуйтесь готовыми решениями и стандартными способами!


Дополнительные источники по теме:



Автор: Павел Лепеев,
Engineer, B2B Pre/Post Sales
Business Development Team
Samsung R&D Institute Russia
Подробнее..

Зеленые практики как дата-центры за границей и в России снижают негативное воздействие на природу

25.09.2020 16:06:58 | Автор: admin

Дата-центры потребляют 3-5% всего электричества планеты, а в некоторых странах, например в Китае, этот показатель достигает 7%. Электричество нужно центрам обработки данных в режиме 24/7, чтобы обеспечивать бесперебойную работу оборудования. В результате работа ЦОД провоцирует выбросы парникового газа в атмосферу, а по уровню негативного воздействия на природу их можно сравнить с авиаперелетами. Собрали последние исследования, чтобы выяснить, как дата-центры влияют на окружающую среду, можно ли это изменить и существуют ли подобные инициативы в России.

Согласно последнему исследованию компании Supermicro, экосознательные дата-центры, внедряющие зеленые решения, могли бы снизить влияние на окружающую среду на 80%. А сохраненная электроэнергия поддерживать освещение всех казино Лас-Вегаса в течение 37 лет. Но на данный момент лишь 12% дата-центров мира можно назвать зелеными.

Отчет Supermicro основан на опросе 5000 представителей IT-индустрии. Выяснилось, что 86% опрошенных в целом не задумываются о воздействии дата-центров на окружающую среду. А социальная ответственность и оценка энергоэффективности предприятия волнует лишь 15% руководителей центров обработки данных. В основном отрасль концентрируется на целях, связанных с обеспечением отказоустойчивости работы, а не энергоэффективности. Хотя фокусироваться на последнем дата-центрам выгодно: среднестатистическое предприятие может сэкономить до $38 млн на энергоресурсах.

PUE


PUE (Power Utilization Efficiency) это показатель оценки энергоэффективности центра обработки данных. Мера была утверждена членами консорциума The Green Grid в 2007 году. PUE отражает отношение электрической энергии, потребляемой дата-центром, к энергии, которая расходуется непосредственно оборудованием ЦОД. Так, если дата-центр получает из сети 10 МВт мощности, а все оборудование держится на 5 МВт, показатель PUE будет составлять 2. Если разрыв в показаниях снизится, а до оборудования будет доходить большая часть электроэнергии, коэффициент будет стремиться к идеальному показателю единице.

В августовском докладе Global Data Center Survey от организации Uptime Institute (среди респондентов 900 операторов центров обработки данных) средний мировой коэффициент PUE оценили на уровне 1,59. В целом, показатель варьируется на этом уровне с 2013 года. Для сравнения, в 2013 году PUE составил 1,65, в 2018 1, 58, а в 2019 1, 67.


Несмотря на то, что показатель PUE не является достаточно честным для сопоставления различных дата-центров и географических регионов, такие сравнительные таблицы Uptime Institute составляет.


Несправедливость сравнения связана с тем, что некоторые центры обработки данных находятся в худших климатических условиях. Так, для охлаждения условного дата-центра в Африке нужно гораздо больше электроэнергии, чем ЦОД, расположенному на севере Европы.

Логично, что самыми энергетически неэффективными являются дата-центры в Латинской Америке, Африке, на Ближнем Востоке и части Азиатско-Тихоокеанского региона. Самыми образцовыми по PUE-показателю стали Европа и регион, объединяющий США и Канаду. К слову, и респондентов в этих странах больше 95 и 92 ЦОД-провайдеров, соответственно.

В исследовании также оценивались дата-центры России и стран СНГ. Правда, в опросе приняли участие лишь 9 респондентов. PUE отечественных и соседских ЦОД составил 1,6.

Как понизить PUE


Естественное охлаждение


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

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

Кроме того, дата-центр может размещаться у водоема в таком случае воду из него может использовать для охлаждения ЦОД. К слову, по прогнозам Stratistics MRC, к 2023 году стоимость рынка технологий жидкостного охлаждения достигнет $4,55 млрд. Среди его видов выделяют иммерсионное охлаждение (погружение оборудования в иммерсионное масло), адиабатическое охлаждение (в основе технология испарения, используется в ЦОД Facebook), теплообменное (теплоноситель нужной температуры поступает непосредственно к стойке с оборудованием, удаляя избытки тепла).

Больше о фрикулинге и о том, как он работает в Selectel

Мониторинг и своевременная замена оборудования


Повысить энергоэффективность также поможет правильное использование мощностей, которыми располагает дата-центр. Уже приобретенные серверы должны либо работать на задачи клиентов, либо не потреблять энергию во время простоя. Один из способов контролировать ситуацию использовать ПО для управления инфраструктурой. Например, систему Data Center Infrastructure Management (DCIM). Такое ПО автоматически перераспределяет нагрузку на серверы, отключает незадействованные устройства и дает рекомендации по скорости работы вентиляторов холодильных установок (опять же, для экономии энергии на излишнем охлаждении).

Важная часть повышения энергоэффективности ЦОД своевременное обновление оборудования. Устаревший сервер чаще всего уступает по производительности и ресурсоемкости новому поколению. Поэтому для понижения PUE рекомендовано обновлять оборудование как можно чаще некоторые компании делают это каждый год. Из исследования Supermicro: оптимизированные циклы обновления оборудования позволят сократить объем электронных отходов более чем на 80% и повысить производительность ЦОД на 15%.


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

Меньше физических серверов больше виртуальных машин


Компания VMware подсчитала, что переход на виртуальные серверы в ряде случаев снижает электропотребление на 80%. Это объясняется тем, что размещение большего количество виртуальных серверов на меньшем числе физических машин логично сокращает затраты на обслуживание железа, охлаждение и питание.

Эксперимент компаний NRDC и Anthesis показал, что замена 3 000 серверов на 150 виртуальных машин экономит $2 млн на электричестве.

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

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

Зеленые на практике


Количество дата-центров в мире выросло с 500 000 в 2012 году до более 8 млн. Цифры потребляемой ими электроэнергии удваиваются каждые четыре года. Выработка необходимого дата-центрам электричества напрямую связана с объемом выбросов углерода, который образуется в результате сгорания ископаемого топлива.

Ученые из Открытого Университета Великобритании подсчитали, что дата-центры производят 2% мировых выбросов CO2. Это примерно столько же, сколько выбрасывают крупнейшие авиакомпании мира. По данным исследования GreenPeace 2019 года, чтобы обеспечить электричеством 44 дата-центра в Китае, в 2018 году энергостанции выбросили в атмосферу 99 млн тонн CO.


Крупные мировые лидеры, такие как Apple, Google, Facebook, Akamai, Microsoft, берут на себя ответственность за негативное воздействие на природу и стараются уменьшать его, используя зеленые технологии. Так, генеральный директор Microsoft Сатья Наделла рассказал о намерении компании к 2030 году достигнуть отрицательного уровня эмиссии углерода, а к 2050 году полностью устранить последствия выбросов за все время с момента основания компании в 1975 году.

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

Kolos


Источник
Дата-центр, расположенный в коммуне Балленген (Норвегия), позиционирует себя как ЦОД, работающий на 100% возобновляемой энергии. Так, для обеспечения работы оборудования используются вода для охлаждения серверов, водяные и ветряные электрогенераторы. К 2027 году дата-центр планирует выйти за пределы 1000 МВт электрической мощности. Сейчас Kolos экономит 60% электроэнергии.

Next-Generation Data


Источник
Британский дата-центр обслуживает такие компании, как телекоммуникационный холдинг BT Group, IBM, Logica и другие. В 2014 году NGD заявил, что достиг идеального показателя PUE единицу. К максимальной энергоэффективности ЦОД приблизили солнечные батареи, расположенные на крыше дата-центра. Впрочем, тогда эксперты подвергли сомнению несколько утопичный результат.

Swiss Fort Knox


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

Equinix AM3


Источник
Дата-центр, расположенный в Амстердаме, использует в своей инфраструктуре охладительные башни Aquifer Thermal Energy Storage. Их прохладный воздух понижает температуру горячих коридоров. Кроме того, в ЦОД используются жидкостные системы охлаждения, а отработанная нагретая вода идет на отопление Амстердамского университета.

Что в России


Исследование Центры обработки данных 2020 компании CNews выявило рост количества стоек у крупнейших российских провайдеров услуг дата-центров. В 2019 году рост составил 10% (до 36,5 тыс), а в 2020 году число стоек может увеличиться еще на 20%. ЦОД-провайдеры обещают поставить рекорд и предоставить к услугам заказчиков в этом году еще 6961 стойку.

По оценке CNews, энергоэффективность применяемых решений и оборудования для обеспечения работоспособности ЦОД находятся на очень низком уровне на 1 Вт полезной мощности приходится до 50% непроизводственных затрат.

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

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

Самые распространенные способы проявления экосознательности отечественных ЦОД:

  1. Переход на более энергоэффективные способы охлаждения оборудования (системы фрикулинга и жидкостного охлаждения);
  2. Утилизация оборудования и косвенных отходов дата-центров;
  3. Восполнение негативного воздействия дата-центров на природу через участие в экологических акциях и инвестирование в экопроекты.


Кирилл Малеванов, технический директор Selectel


На сегодняшний показатель PUE дата-центров Selectel составляет 1,25 (ДЦ Дубровка в Ленинградской области) и 1,151,20 (ДЦ Берзарина-2 в Москве). Мы следим за коэффициентом и стремимся использовать более энергоэффективные решения по охлаждению, освещению и другим аспектам работы. Современные серверы сейчас потребляют примерно одинаковое количество энергии, доходить до крайности и бороться за 10Вт смысла нет. Однако в плане оборудования, которое обеспечивает работу дата-центров, подход меняется мы смотрим и на показатели энергоэффективности.

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

Seleсtel пошел дальше и запустил программу Зеленый Selectel. Теперь компания будет ежегодно высаживать одно дерево за каждый работающий в дата-центрах компании сервер. Первую массовую высадку леса компания осуществила 19 сентября в Московской и Ленинградской областях. Всего было посажено 20 000 деревьев, которые в будущем смогут вырабатывать до 200 000 000 л кислорода в год. На этом акции не закончатся, в планах реализовывать зеленые инициативы на протяжении года. О новых акциях можно узнавать на сайте Зеленый Selectel и в Telegram-канале компании.

Подробнее..

Эльбрус VS Intel. Сравниваем производительность систем хранения Аэродиск Восток и Engine

28.09.2020 06:06:32 | Автор: admin


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


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


Мы в Аэродиске люди практичные, поэтому пошли самым простым и понятным (для нас) путем: протестировать, зафиксировать результаты и только потом делать выводы. В итоге мы провели довольно большое количество тестов и обнаружили ряд особенностей работы Эльбруса 8С архитектуры e2k (в том числе, и приятных) и, конечно же, сравнили это с аналогичными СХД на процессорах Intel Xeon архитектуры amd64.


Кстати, более подробно о тестах, результатах и о будущем развитии СХД на Эльбрусах мы поговорим на нашем очередном вебинаре "ОколоИТ" 15.10.2020 в 15 00. Зарегистрироваться можно по ссылке ниже.


РЕГИСТРАЦИЯ НА ВЕБИНАР


Тестовый стенд


Мы создали два стенда. Оба стенда состоят из сервера с Linux-ом, подключенного через 16G FC-коммутаторы к двум котроллерам СХД, в которой установлено 12 SAS SSD 960 ГБ дисков (11,5 ТБ сырой емкости или 5,7 ТБ полезной емкости, если используем RAID-10).


Схематично стенд выглядит следующим образом.



Стенд 1 e2k (Эльбрус)


Конфигурация оборудования следующая:


  • Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
  • Коммутатор FC 16 G 2 шт.
  • СХД Аэродиск Восток 2-Э12 (2xЭльбрус 8С (8 cores, 1,20Ghz), 32 GB DDR3, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Стенд 2 amd64 (Intel)


Для сравнения с аналогичной конфигурации на e2k использовалась похожая конфигурация СХД с похожим процессором по характеристикам на amd64:


  • Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
  • Коммутатор FC 16 G 2 шт.
  • СХД Aerodisk Engine N2 (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 32 GB DDR4, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Важное замечание: используемые в тесте процессоры Эльбрус 8С поддерживают оперативную память только DDR3, это конечно плохо, но не долго. Эльбрус 8СВ (в наличие его у нас пока нет, но скоро будет) поддерживает DDR4.


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


Для генерации нагрузки мы использовали популярную и проверенную временем программу Flexible IO (FIO).


Обе СХД сконфигурированы согласно нашим же рекомендациям по настройке, исходя из требований к высокой производительности на блочном доступе, поэтому используем дисковые пулы DDP (Dynamic Disk Pool). Чтобы не искажать результаты тестирования, на обеих СХД отключаем, компрессию, дедупликацию и RAM-кэш.


Созданы 8 D-LUN-ов в RAID-10 по 500 ГБ, каждый, суммарный полезный объём составляет 4 ТБ (т.е. примерно 70% от возможной полезной емкости данной конфигурации).


Выполняться будут основные и популярные сценарии использования СХД, в частности:


первые два теста эмулируют работу транзакционной СУБД. В этой группе тестов нам интересны IOPS-ы и задержка.


1) Случайное чтение маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 100%/0%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Full Random


2) Случайная запись маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Full Random


вторые два теста эмулируют работу аналитической части СУБД. В этой группе тестов нам также интересны IOPS-ы и задержка.


3) Последовательное чтение маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 100%/0%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential


4) Последовательная запись маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential


третья группа тестов эмулирует работу потокового чтения (пример онлайн трансляции, восстановление резервных копий) и потоковой записи (пример видеонаблюдение, запись резервных копий). В этой группе тестов нам уже интересны не IOPS-ы, а MB/s и также задержка.


5) Последовательное чтение большими блоками 128k
a. Размер блока = 128k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential


6) Последовательная запись большими блоками 128k
a. Размер блока = 128k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential


Каждый тест будет длиться один час без учета времени прогрева массива в 7 минут.


Результаты тестов


Результаты тестов сведены в две таблицы.


Эльбрус 8С (СХД Аэродиск Восток 2-Э12)



Intel Xeon E5-2603 v4 (СХД Аэродиск Engine N2)



Результаты получились крайне интересные. В обоих случаях мы хорошо утилизировали процессорные мощности СХД (70-90% утилизации), и при таком раскладе явно бросаются в глаза плюсы и минусы обоих процессоров.


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


Если говорить о случайной нагрузке небольшими блоками, то:


  • с точки зрения случайного чтения Intel, безусловно, впереди Эльбруса, разница в 2 раза;
  • с точки зрения случайной записи однозначно ничья, оба процессора показали примерно равные и достойные результаты.

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


  • и при чтении, и при записи Intel существенно (в 2 раза) опережает Эльбрус. При этом, если у Эльбруса показатель IOPS ниже чем у Intel, но выглядит достойно (200-300 тысяч), то с задержками явная проблема (они в три раза выше чем у Intel). Вывод, текущая версия Эльбруса 8С очень не любит последовательные нагрузки небольшими блоками. Явно есть над чем работать.

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


  • оба процессора показали примерно равный результат в MB/s, но есть одно НО. Показатели задержек у Эльбруса в 10 (в десять, Карл!!!) раз лучше (т.е. ниже), чем у аналогичного процессора от Intel (0,4/0,5 ms против 5,1/6,5 ms). Вначале мы подумали, что это глюк, поэтому мы перепроверили результаты, сделали повторный тест, но повторный тест показал ту же картину. Это серьезное преимущество Эльбруса (и архитектуры e2k в целом) перед Intel (и, соответственно, архитектуры amd64). Будем надеяться, что этот успех получит дальнейшее развитие.

Есть ещё одна интересная особенность Эльбруса, на которую внимательный читатель может обратить внимание, посмотрев на таблицу. Если взглянуть на разницу показателей чтения и записи у Intel, то во всех тестах чтение опережает запись в среднем примерно на 50%+. Это норма, к которой все (в том числе и мы) привыкли. Если посмотреть на Эльбрус, то показатели записи значительно ближе к показателям чтения, чтение опережает запись, как правило, на 10 30%, не более.


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


Выводы и ближайшее будущее


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


Intel сильно превзошел Эльбрус в случайном чтении небольшими блоками, а также в последовательном чтении и записи небольшими блоками.


При случайной записи небольшими блоками оба процессора показывают равные результаты.


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


Кроме того, Эльбрус в отличии от Intel, одинаково хорошо справляется как с нагрузками чтения, так и с нагрузками записи, в то время как у Intel чтение всегда значительно лучше записи.
Исходя из полученных результатов можно сделать вывод о применимости систем хранения данных Аэродиск Восток на процессоре Эльбрус 8С в следующих задачах:


  • информационные системы с преобладанием операций записи;
  • файловый доступ;
  • онлайн-трансляции;
  • видеонаблюдение;
  • резервное копирование;
  • медиа-контент.

Коллективу МЦСТ есть ещё над чем работать, но результат их работы виден уже сейчас, что, конечно, не может не радовать.


Данные тесты проводились на ядре Linux для e2k версии 4.19, на текущий момент в бета-тестах (в МЦСТ, в Базальт СПО, а также у нас, в Аэродиске) находится ядро Linux 5.4-e2k, в котором, кроме всего прочего, серьезно переработан планировщик и много оптимизаций под скоростные твердотельные накопители. Также специально для ядер ветки 5.х.х АО МЦСТ выпускает новый компилятор LCC версии 1.25. По предварительным результатам, на том же процессоре Эльбрус 8С, собранное новым компилятором новое же ядро, окружение ядра, системные утилиты и библиотеки и, собственно, ПО Аэродиск ВОСТОК позволит получить ещё более значительный прирост производительности. И это без замены оборудования на том же процессоре и с теми же частотами.


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


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


Эльбрус уже сейчас показывает хорошие результаты, если сравнивать его с процессорами amd64 среднего уровня. До верхних в линейке моделей серверных процессоров Intel или AMD 8-ке Эльбруса, конечно, далеко, но она туда и не целилась, для этого будут выпущены процессоры 16С и 32С. Вот тогда и поговорим.


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


В этот раз у нас в гостях будет заместитель генерального директора компании МЦСТ, Константин Трушкин. Записаться на вебинар можно по ссылке ниже.


РЕГИСТРАЦИЯ НА ВЕБИНАР


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

Подробнее..

Перевод DataHub универсальный инструмент поиска и обнаружения метаданных

28.09.2020 12:18:44 | Автор: admin

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


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


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


Масштабирование метаданных


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


С момента нашего первого выпуска WhereHows в 2016 году, в отрасли наблюдается растущий интерес к повышению продуктивности специалистов по обработке данных с помощью метаданных. Например, инструменты, разработанные в этой области, включают Dataportal AirBnb, Databook Uber, Metacat Netflix, Amundsen Lyft и совсем недавно Data Catalog от Google. В LinkedIn мы также были заняты расширением объема сбора метаданных для новых вариантов использования при сохранении конфиденциальности. Однако мы пришли к выводу, что у WhereHows были фундаментальные ограничения, которые не позволяли удовлетворить наши растущие потребности в метаданных. Вот то, что мы смогли узнать во время работы с масштабированием WhereHows:


  1. Push лучше, чем pull: хотя получение метаданных непосредственно из источника кажется наиболее простым способом сбора метаданных. Более масштабируемым является использование отдельных поставщиков метаданных для передачи информации в центральный репозиторий через API или сообщения. Такой подход на основе push также обеспечивает более своевременное отображение новых и обновленных метаданных.
  2. Общее лучше, чем конкретное: WhereHows категорически придерживается мнения о том, как должны выглядеть метаданные для набора данных или задания. Это приводит к упрямому API, модели данных и формату хранения. Небольшое изменение модели метаданных приведет к каскаду необходимых изменений вверх и вниз по стеку. Он был бы более масштабируемым, если бы мы разработали общую архитектуру, не зависящую от модели метаданных, которую она хранит и обслуживает. Это, в свою очередь, позволило бы нам сосредоточиться на адаптации и развитии строго самоуверенных моделей метаданных, не беспокоясь о нижних уровнях стека.
  3. Онлайн так же важен, как и офлайн. После того, как метаданные собраны, естественно необходимо проанализировать эти метаданные, чтобы извлечь из них пользу. Одно из простых решений сбросить все метаданные в автономную систему, такую как Hadoop, где можно выполнять произвольный анализ. Однако вскоре мы обнаружили, что одной только поддержки автономного анализа недостаточно. Есть много вариантов использования, таких как управление доступом и обработка конфиденциальности данных, для которых необходимо запрашивать последние метаданные в Интернете.
  4. Взаимоотношения действительно важны. Метаданные часто передают важные взаимосвязи (например, происхождение, владение и зависимости), которые обеспечивают мощные возможности, такие как анализ воздействия, объединение данных, повышение релевантности поиска и т. д.
  5. Многоцентровая вселенная: мы поняли, что недостаточно просто моделировать метаданные, сосредоточенные вокруг одного объекта (набора данных). Существует целая экосистема данных, кода и человеческих сущностей (наборы данных, специалисты по обработке данных, команды, код, API микросервисов, показатели, функции ИИ, модели ИИ, информационные панели, записные книжки и т. Д.), Которые необходимо интегрировать и связать через единый граф метаданных.

Встречайте DataHub


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


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


Модульный интерфейс


Веб-приложение DataHub это то, как большинство пользователей взаимодействуют с метаданными. Приложение написано с использованием Ember Framework и работает на среднем уровне Play. Чтобы сделать разработку масштабируемой, мы используем различные современные веб-технологии, включая ES9, ES.Next, TypeScript, Yarn with Yarn Workspaces, а также инструменты качества кода, такие как Prettier и ESLint. Уровни представления, управления и данных разделены на пакеты, так что определенные представления в приложении построены на основе композиции соответствующих пакетов.


Структура обслуживания компонентов


Применяя модульную инфраструктуру пользовательского интерфейса, мы создали веб-приложение DataHub как серию связанных компонентов, согласованных по функциям, которые сгруппированы в устанавливаемые пакеты. Эта архитектура пакета использует в основе Yarn Workspaces и надстройки Ember и разбита на компоненты с использованием компонентов и сервисов Ember. Вы можете думать об этом как о пользовательском интерфейсе, который построен с использованием небольших строительных блоков (например, компонентов и сервисов) для создания более крупных строительных блоков (например, надстроек Ember и пакетов npm / Yarn), которые при объединении в конечном итоге составляют веб-приложение DataHub .


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


Взаимодействие с DataHub


На самом высоком уровне интерфейс обеспечивает три типа взаимодействия: (1) поиск, (2) просмотр и (3) просмотр / редактирование метаданных. Вот несколько примеров скриншотов из реального приложения:








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


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


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


Обобщенная архитектура метаданных


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


  1. Моделирование: моделируйте все типы метаданных и отношений в удобной для разработчиков манере.
  2. Прием: прием большого количества изменений метаданных в любом масштабе как через API, так и через потоки.
  3. Обслуживание: обслуживайте собранные необработанные и производные метаданные, а также множество сложных запросов к метаданным в любом масштабе.
  4. Индексирование: индексируйте метаданные в масштабе, а также автоматически обновляйте индексы при изменении метаданных.

Моделирование метаданных


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


  1. Метаданные это также данные: для моделирования метаданных нам нужен язык, который по крайней мере так же многофункциональн, как те, которые используются для моделирования данных общего назначения.
  2. Метаданные распределены: нереально ожидать, что все метаданные поступают из одного источника. Например, система, которая управляет списком управления доступом (ACL) набора данных, скорее всего, будет отличаться от той, которая хранит метаданные схемы. Хорошая среда моделирования должна позволять нескольким командам независимо развивать свои модели метаданных, одновременно представляя единое представление всех метаданных, связанных с объектом данных.

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


Чтобы продемонстрировать, как использовать Pegasus для моделирования метаданных, давайте рассмотрим простой пример, проиллюстрированный следующей измененной диаграммой сущностей-отношений (ERD).



Пример содержит три типа сущностей Пользователь, Группа и Набор данных представленных синими кружками на диаграмме. Мы используем стрелки для обозначения трех типов отношений между этими объектами, а именно OwnedBy, HasMember и HasAdmin. Другими словами, группа состоит из одного администратора и нескольких членов пользователя, которые, в свою очередь, могут владеть одним или несколькими наборами данных.


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


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


Чтобы смоделировать пример в Pegasus, мы переведем каждую из сущностей, отношений и аспектов метаданных в отдельный файл схемы Pegasus (PDSC). Для краткости мы включим сюда только по одной модели из каждой категории. Во-первых, давайте взглянем на PDSC для объекта User:


{  "type": "record",  "name": "User",  "fields": [    {      "name": "urn",      "type": "com.linkedin.common.UserUrn",    },    {      "name": "firstName",      "type": "string",      "optional": true    },    {      "name": "lastName",      "type": "string",      "optional": true    },    {      "name": "ldap",      "type": "com.linkedin.common.LDAP",      "optional": true    }  ]}

Каждая сущность должна иметь глобально уникальный идентификатор в форме URN, который можно рассматривать как типизированный GUID. Сущность User имеет атрибуты, включая имя, фамилию и LDAP, каждое из которых соответствует необязательному полю в записи пользователя.


Далее следует модель PDSC для отношения OwnedBy:


{  "type": "record",  "name": "OwnedBy",  "fields": [    {      "name": "source",      "type": "com.linkedin.common.Urn",    },    {      "name": "destination",      "type": "com.linkedin.common.Urn",    },    {      "name": "type",      "type": "com.linkedin.common.OwnershipType",    }  ],  "pairings": [    {      "source": "com.linkedin.common.urn.DatasetUrn",      "destination": "com.linkedin.common.urn.UserUrn"    }  ]}

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


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


{  "type": "record",  "name": "Ownership",  "fields": [    {      "name": "owners",      "type": {        "type": "array",        "items": {          "name": "owner",          "type": "record",          "fields": [            {              "name": "type",              "type": "com.linkedin.common.OwnershipType"            },            {              "name": "ldap",              "type": "string"            }          ]        }      }    }  ]}

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


Получение метаданных


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


API DataHub основан на Rest.li, масштабируемой строго типизированной сервисной архитектуре RESTful, широко используемой в LinkedIn. Поскольку Rest.li использует Pegasus в качестве определения интерфейса, все модели метаданных, определенные в предыдущем разделе, могут использоваться дословно. Прошли те времена, когда требовалось преобразование нескольких уровней моделей от API до хранилища API и модели всегда будут синхронизироваться.


Ожидается, что для приема на основе Kafka производители метаданных будут генерировать стандартизированное событие изменения метаданных (MCE), которое содержит список предлагаемых изменений конкретных аспектов метаданных, введенных с помощью соответствующего URN объекта. Схема для MCE находится в Apache Avro, но автоматически создается из моделей метаданных Pegasus.


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


В LinkedIn мы склонны больше полагаться на поток Kafka из-за слабой связи, которую он обеспечивает между производителями и потребителями. Ежедневно мы получаем миллионы MCE от различных производителей, и ожидается, что их объем будет расти экспоненциально только по мере того, как мы расширяем объем нашей коллекции метаданных. Чтобы построить конвейер приема потоковых метаданных, мы использовали Apache Samza в качестве нашей платформы обработки потоковой информации. Задание Samza приема специально разработано, чтобы быть быстрым и простым для достижения высокой пропускной способности. Он просто преобразует данные Avro обратно в Pegasus и вызывает соответствующий API Rest.li для завершения приема.



Обслуживание метаданных


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


  1. Документно-ориентированные запросы
  2. Графические запросы
  3. Сложные запросы, включающие соединения
  4. Полнотекстовый поиск

Для этого DataHub необходимо использовать несколько типов систем данных, каждая из которых специализируется на масштабировании и обслуживании ограниченных типов запросов. Например, Espresso это база данных NoSQL LinkedIn, которая особенно хорошо подходит для масштабируемого документально-ориентированного CRUD. Точно так же Galene может легко индексировать и обслуживать полнотекстовый поиск в Интернете. Когда дело доходит до нетривиальных запросов к графам, неудивительно, что специализированная графовая БД может выполнять на порядки лучше, чем реализации на основе СУБД. Однако оказывается, что структура графа также является естественным способом представления отношений внешнего ключа, позволяя эффективно отвечать на сложные запросы соединения.


DataHub дополнительно абстрагирует базовые системы данных с помощью набора общих объектов доступа к данным (DAO), таких как DAO ключ-значение, запрос DAO и поиск DAO. После этого реализация DAO для конкретной системы данных может быть легко заменена, без изменения какой-либо бизнес-логики в DataHub. В конечном итоге это позволит нам открыть DataHub с открытым исходным кодом с эталонными реализациями для популярных систем с открытым исходным кодом, в то же время используя все преимущества проприетарных технологий хранения LinkedIn.



Еще одно ключевое преимущество абстракции DAO стандартизированный сбор данных об изменениях (CDC). Независимо от типа базовой системы хранения данных, любая операция обновления через DAO ключ-значение автоматически генерирует событие аудита метаданных (MAE). Каждый MAE содержит URN соответствующего объекта, а также изображения до и после определенного аспекта метаданных. Это позволяет использовать лямбда-архитектуру, в которой MAE могут обрабатываться как пакетами, так и потоками. Подобно MCE, схема MAE также автоматически генерируется из моделей метаданных.


Индексирование метаданных


Последний недостающий элемент головоломки конвейер индексации метаданных. Это система, которая объединяет модели метаданных и создает соответствующие индексы в графической БД и поисковой системе для облегчения эффективных запросов. Эти бизнес-логики фиксируются в форме построителя индексов и построителей графиков и выполняются как часть задания Samza, обрабатывающего MAE. Каждый разработчик зарегистрировал свой интерес к конкретным аспектам метаданных в задании и будет вызван с соответствующим MAE. Затем построитель возвращает список идемпотентных обновлений, которые будут применяться к БД индекса поиска или графа.


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



Заключение и с нетерпением жду


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


DataHub работает в LinkedIn в течение последних шести месяцев. Каждую неделю его посещают более 1500 сотрудников, которые поддерживают поиск, обнаружение и различные рабочие процессы для конкретных действий. График метаданных LinkedIn содержит более миллиона наборов данных, 23 системы хранения данных, 25 тысяч показателей, более 500 функций искусственного интеллекта и, что наиболее важно, всех сотрудников LinkedIn, которые являются создателями, потребителями и операторами этого графика.


Мы продолжаем улучшать DataHub, добавляя в продукт больше интересных пользовательских историй и алгоритмов релевантности. Мы также планируем добавить встроенную поддержку GraphQL и использовать язык Pegasus Domain Specific Language (PDL) для автоматизации генерации кода в ближайшем будущем. В то же время мы активно работаем над тем, чтобы поделиться этой эволюцией WhereHows с сообществом разработчиков ПО с открытым исходным кодом, а после публичного выпуска DataHub мы сделаем объявление.

Подробнее..

Дата-центры, экология и ресурсы как российские и зарубежные компании стараются стать зеленее

28.09.2020 14:11:21 | Автор: admin

Дата-центры потребляют 3-5% всего электричества планеты, а в некоторых странах, например в Китае, этот показатель достигает 7%. Электричество нужно центрам обработки данных в режиме 24/7, чтобы обеспечивать бесперебойную работу оборудования. В результате работа ЦОД провоцирует выбросы парникового газа в атмосферу, а по уровню негативного воздействия на природу их можно сравнить с авиаперелетами.

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

Согласно последнему исследованию компании Supermicro, экосознательные дата-центры, внедряющие зеленые решения, могли бы снизить влияние на окружающую среду на 80%. А сохраненная электроэнергия поддерживать освещение всех казино Лас-Вегаса в течение 37 лет. Но на данный момент лишь 12% дата-центров мира можно назвать зелеными.

Отчет Supermicro основан на опросе 5000 представителей IT-индустрии. Выяснилось, что 86% опрошенных в целом не задумываются о воздействии дата-центров на окружающую среду. А социальная ответственность и оценка энергоэффективности предприятия волнует лишь 15% руководителей центров обработки данных. В основном отрасль концентрируется на целях, связанных с обеспечением отказоустойчивости работы, а не энергоэффективности. Хотя фокусироваться на последнем дата-центрам выгодно: среднестатистическое предприятие может сэкономить до $38 млн на энергоресурсах.

PUE


PUE (Power Utilization Efficiency) это показатель оценки энергоэффективности центра обработки данных. Мера была утверждена членами консорциума The Green Grid в 2007 году. PUE отражает отношение электрической энергии, потребляемой дата-центром, к энергии, которая расходуется непосредственно оборудованием ЦОД. Так, если дата-центр получает из сети 10 МВт мощности, а все оборудование держится на 5 МВт, показатель PUE будет составлять 2. Если разрыв в показаниях снизится, а до оборудования будет доходить большая часть электроэнергии, коэффициент будет стремиться к идеальному показателю единице.

В августовском докладе Global Data Center Survey от организации Uptime Institute (среди респондентов 900 операторов центров обработки данных) средний мировой коэффициент PUE оценили на уровне 1,59. В целом, показатель варьируется на этом уровне с 2013 года. Для сравнения, в 2013 году PUE составил 1,65, в 2018 1, 58, а в 2019 1, 67.


Несмотря на то, что показатель PUE не является достаточно честным для сопоставления различных дата-центров и географических регионов, такие сравнительные таблицы Uptime Institute составляет.


Несправедливость сравнения связана с тем, что некоторые центры обработки данных находятся в худших климатических условиях. Так, для охлаждения условного дата-центра в Африке нужно гораздо больше электроэнергии, чем ЦОД, расположенному на севере Европы.

Логично, что самыми энергетически неэффективными являются дата-центры в Латинской Америке, Африке, на Ближнем Востоке и части Азиатско-Тихоокеанского региона. Самыми образцовыми по PUE-показателю стали Европа и регион, объединяющий США и Канаду. К слову, и респондентов в этих странах больше 95 и 92 ЦОД-провайдеров, соответственно.

В исследовании также оценивались дата-центры России и стран СНГ. Правда, в опросе приняли участие лишь 9 респондентов. PUE отечественных и соседских ЦОД составил 1,6.

Как понизить PUE


Естественное охлаждение


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

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

Кроме того, дата-центр может размещаться у водоема в таком случае воду из него может использовать для охлаждения ЦОД. К слову, по прогнозам Stratistics MRC, к 2023 году стоимость рынка технологий жидкостного охлаждения достигнет $4,55 млрд. Среди его видов выделяют иммерсионное охлаждение (погружение оборудования в иммерсионное масло), адиабатическое охлаждение (в основе технология испарения, используется в ЦОД Facebook), теплообменное (теплоноситель нужной температуры поступает непосредственно к стойке с оборудованием, удаляя избытки тепла).

Больше о фрикулинге и о том, как он работает в Selectel

Мониторинг и своевременная замена оборудования


Повысить энергоэффективность также поможет правильное использование мощностей, которыми располагает дата-центр. Уже приобретенные серверы должны либо работать на задачи клиентов, либо не потреблять энергию во время простоя. Один из способов контролировать ситуацию использовать ПО для управления инфраструктурой. Например, систему Data Center Infrastructure Management (DCIM). Такое ПО автоматически перераспределяет нагрузку на серверы, отключает незадействованные устройства и дает рекомендации по скорости работы вентиляторов холодильных установок (опять же, для экономии энергии на излишнем охлаждении).

Важная часть повышения энергоэффективности ЦОД своевременное обновление оборудования. Устаревший сервер чаще всего уступает по производительности и ресурсоемкости новому поколению. Поэтому для понижения PUE рекомендовано обновлять оборудование как можно чаще некоторые компании делают это каждый год. Из исследования Supermicro: оптимизированные циклы обновления оборудования позволят сократить объем электронных отходов более чем на 80% и повысить производительность ЦОД на 15%.


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

Меньше физических серверов больше виртуальных машин


Компания VMware подсчитала, что переход на виртуальные серверы в ряде случаев снижает электропотребление на 80%. Это объясняется тем, что размещение большего количество виртуальных серверов на меньшем числе физических машин логично сокращает затраты на обслуживание железа, охлаждение и питание.

Эксперимент компаний NRDC и Anthesis показал, что замена 3 000 серверов на 150 виртуальных машин экономит $2 млн на электричестве.

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

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

Зеленые на практике


Количество дата-центров в мире выросло с 500 000 в 2012 году до более 8 млн. Цифры потребляемой ими электроэнергии удваиваются каждые четыре года. Выработка необходимого дата-центрам электричества напрямую связана с объемом выбросов углерода, который образуется в результате сгорания ископаемого топлива.

Ученые из Открытого Университета Великобритании подсчитали, что дата-центры производят 2% мировых выбросов CO2. Это примерно столько же, сколько выбрасывают крупнейшие авиакомпании мира. По данным исследования GreenPeace 2019 года, чтобы обеспечить электричеством 44 дата-центра в Китае, в 2018 году энергостанции выбросили в атмосферу 99 млн тонн CO.


Крупные мировые лидеры, такие как Apple, Google, Facebook, Akamai, Microsoft, берут на себя ответственность за негативное воздействие на природу и стараются уменьшать его, используя зеленые технологии. Так, генеральный директор Microsoft Сатья Наделла рассказал о намерении компании к 2030 году достигнуть отрицательного уровня эмиссии углерода, а к 2050 году полностью устранить последствия выбросов за все время с момента основания компании в 1975 году.

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

Kolos


Источник
Дата-центр, расположенный в коммуне Балленген (Норвегия), позиционирует себя как ЦОД, работающий на 100% возобновляемой энергии. Так, для обеспечения работы оборудования используются вода для охлаждения серверов, водяные и ветряные электрогенераторы. К 2027 году дата-центр планирует выйти за пределы 1000 МВт электрической мощности. Сейчас Kolos экономит 60% электроэнергии.

Next-Generation Data


Источник
Британский дата-центр обслуживает такие компании, как телекоммуникационный холдинг BT Group, IBM, Logica и другие. В 2014 году NGD заявил, что достиг идеального показателя PUE единицу. К максимальной энергоэффективности ЦОД приблизили солнечные батареи, расположенные на крыше дата-центра. Впрочем, тогда эксперты подвергли сомнению несколько утопичный результат.

Swiss Fort Knox


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

Equinix AM3


Источник
Дата-центр, расположенный в Амстердаме, использует в своей инфраструктуре охладительные башни Aquifer Thermal Energy Storage. Их прохладный воздух понижает температуру горячих коридоров. Кроме того, в ЦОД используются жидкостные системы охлаждения, а отработанная нагретая вода идет на отопление Амстердамского университета.

Что в России


Исследование Центры обработки данных 2020 компании CNews выявило рост количества стоек у крупнейших российских провайдеров услуг дата-центров. В 2019 году рост составил 10% (до 36,5 тыс), а в 2020 году число стоек может увеличиться еще на 20%. ЦОД-провайдеры обещают поставить рекорд и предоставить к услугам заказчиков в этом году еще 6961 стойку.

По оценке CNews, энергоэффективность применяемых решений и оборудования для обеспечения работоспособности ЦОД находятся на очень низком уровне на 1 Вт полезной мощности приходится до 50% непроизводственных затрат.

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

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

Самые распространенные способы проявления экосознательности отечественных ЦОД:

  1. Переход на более энергоэффективные способы охлаждения оборудования (системы фрикулинга и жидкостного охлаждения);
  2. Утилизация оборудования и косвенных отходов дата-центров;
  3. Восполнение негативного воздействия дата-центров на природу через участие в экологических акциях и инвестирование в экопроекты.


Кирилл Малеванов, технический директор Selectel


На сегодняшний показатель PUE дата-центров Selectel составляет 1,25 (ДЦ Дубровка в Ленинградской области) и 1,151,20 (ДЦ Берзарина-2 в Москве). Мы следим за коэффициентом и стремимся использовать более энергоэффективные решения по охлаждению, освещению и другим аспектам работы. Современные серверы сейчас потребляют примерно одинаковое количество энергии, доходить до крайности и бороться за 10Вт смысла нет. Однако в плане оборудования, которое обеспечивает работу дата-центров, подход меняется мы смотрим и на показатели энергоэффективности.

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

Seleсtel пошел дальше и запустил программу Зеленый Selectel. Теперь компания будет ежегодно высаживать одно дерево за каждый работающий в дата-центрах компании сервер. Первую массовую высадку леса компания осуществила 19 сентября в Московской и Ленинградской областях. Всего было посажено 20 000 деревьев, которые в будущем смогут вырабатывать до 200 000 000 л кислорода в год. На этом акции не закончатся, в планах реализовывать зеленые инициативы на протяжении года. О новых акциях можно узнавать на сайте Зеленый Selectel и в Telegram-канале компании.

Подробнее..

Автоматизация бизнеса начинаем разбираться

28.09.2020 14:11:21 | Автор: admin
Помните старый мультфильм про Нехочуху? Ленивый мальчишка попал в страну великого Нехочухи, где большинство действий выполняли роботы. Надо сказать, мультипликаторы изобразили безрадостную картину автоматизации: человек внутри роботизированных процессов распадается как личность и теряет навыки социальной адаптации. Это идёт явно вразрез с любимым нами Электроником, который как раз проповедует ценность соединения автоматизации и человеческого начала. Что-то нас в философию занесло.

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


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

Определения автоматизации не существует?


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

Пусть для начала будет так. Автоматизация бизнеса это совокупность работающих средств (программ и устройств), обеспечивающих минимизацию рутины, оптимизацию трудовых и производственных ресурсов с целью наращивания продуктивности и эффективности всех бизнес-процессов. Звучит неплохо. Однако как автоматизация может быть совокупностью средств? Это процесс. Ага, например, автоматизация это внедрение программ и установка устройств Стоп. А есть ли жизнь после внедрения? Конечно, эксплуатация. Ок, подходим к новому определению: Автоматизация бизнеса это процесс внедрения и эксплуатации совокупности работающих средств (программ и устройств), обеспечивающих минимизацию рутины, оптимизацию трудовых и производственных ресурсов с целью наращивания продуктивности и эффективности всех бизнес-процессов. Куда ни шло, можно принять за рабочее, но всё равно остаются вопросы: а если нет оформленных бизнес-процессов, а если нет производственного ресурса и т.д.

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

В теории, в идеальном мире автоматизация бизнеса и автоматизация бизнес-процессов равнозначные понятия, потому что в бизнесе всё есть процесс, который можно дискретизировать, разложить на подпроцессы и этапы и описать. Но в реальном мире в компаниях есть масса активностей, не попадающих под определение бизнес-процесса, сами процессы неоптимизированы или отсутствуют вовсе, а вся работа ведётся стихийно. Поэтому в задачи автоматизации неожиданно попадает огромный подготовительный этап, в коде которого нужно проанализировать, описать и подготовить бизнес-процессы.
Мы приняли решение: для всех, кто пришёл с Хабра и оставил заявку в форме, бесплатный анализ бизнес-процессов компании будет доступен всегда. Это работа наших экспертов, связанная с анализом вашего бизнеса с последующей выработкой рекомендаций и обычно она стоит от 15 000 рублей, но нам для науки хвоста не жалко Хабра ничего не жалко. Записывайтесь, мы с вами свяжемся, назначим время (это займёт далеко не 15 минут) и обсудим бизнес-процессы вашей компании или проблемы с бизнес-процессами. Общение с экспертом не накладывает на вас никаких обязательств.

Какой бизнес нужно автоматизировать?


Любой.

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

  • Экономия одна из ключевых целей автоматизации. Вложившись в программное обеспечение, компании используют его либо для увеличения производительности труда, либо для сокращения затрат. Таким образом, компания как минимум экономит время и деньги на изменении структуры сделок и продаж, увеличивая при этом оборот и прибыль. Чтобы автоматизация оказалась откровенно убыточной, нужно просто забросить купленную программу и забыть о потраченных деньгах.
  • Упорядочить и ускорить бизнес-процессы ключевая задача автоматизации. Сокращение времени на каждую операцию, определение чётких этапов, ответственных и сроков делает процесс эффективным, прозрачным и отлаженным. Чёткое распределение задач между сотрудниками минимизирует человеческий фактор и сокращает связанные с ним риски.
  • Увеличение прозрачности бизнеса в целом важная цель. Автоматизация помогает сотрудникам работать с клиентами и друг с другом в единой информационной системе и не конфликтовать на переделе клиентов и следовать индивидуальным KPI; клиентам получать своевременное и качественное обслуживание; руководителю видеть реальные результаты работы сотрудников. Такая прозрачность не только формирует позиционирование компании, но и ведёт к росту выручки благодаря исключению конфликтов и лояльности клиентов, а также стандартизации процессов (стандартный, фиксированный бизнес-процесс признак надёжной компании).

Что можно автоматизировать в бизнесе?


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

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

Группа процессов


Вид и особенности автоматизации


Управляющие бизнес-процессы, которые включены в стратегический менеджмент и управление организацией. CRM, ERP, системы управления проектами, аналитические системы. Рабочее место руководителя предполагает полный доступ к данным компании, расширенную аналитику, возможности делегирования и перераспределения задач.
Операционные процессы совокупность процессов, составляющих основную деятельность компании. Это как раз то, что мы с вами делаем на работе: производство, разработка, маркетинг, продажи, поддержка и т.д. CRM, ERP, системы управления проектами, ECM, WMS, САПР, АСТПП и прочие специализированные системы. Должны быть либо универсальными (все подразделения в одной информационной системе), либо интегрированными между собой.
Поддерживающие процессы процессы, которые решают внутренние задачи организации: системное администрирование, ITSM, бухгалтерский учёт, логистика и т.д. Специализированное ПО, которое может быть интегрировано с предыдущей группой или работать самостоятельно (1С, тикет-системы, логистические маршрутные системы, М2М и т.д.)
Упомянутые активности с высоким человеческим фактором. Программы для управления и подбора персонала, корпоративные порталы, чаты, мессенджеры и т.д. Те программы, которые облегчают работу, геймифицируют процессы, унифицируют коммуникацию, но при этом не исключают человеческий фактор в тех процессах, где он решающий.

Что даёт автоматизация бизнесу?


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


Это вообще про весь российский бизнес. Только большинство пока на стадии отрицания

Автоматизация упорядочивает, налаживает оперативную работу и управление задачами. Все сотрудники (причём совершенно не важно, удалённые или офисные) работают в едином информационном пространстве АСУ (PM, ERP, CRM), координируют свои действия, получают и делегируют задачи, видят свои задания внутри проектов и бизнес-процессов, распределяют свою нагрузку во времени. Руководителю больше не нужно вызывать каждого к себе и разжёвывать задачи достаточно поставить их в системе и проконтролировать выполнение. Вся оперативная работа ведётся в единой системе и любой сотрудник может получить доступ к данным в рамках своих компетенций, а также запросить доступ или выгрузку данных, если в этом есть необходимость. Вне автоматизации всё это представляет собой сплошную стихийную коммуникацию, в которой несложно забыть, ошибиться или просто незаметно не выполнить задачу.

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

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

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

Прежде всего нужно выбрать правильные процессы для автоматизации:

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

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

Как измерить эффективность автоматизации?


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

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

Что может стать показателем эффективности внедрения системы автоматизации в малом и среднем бизнесе:

  • время, затрачиваемое на операцию или процесс если в результате автоматизации оно сократилось, значит, всё сделано правильно;
  • продолжительность сделки: она может не измениться, но сокращение цикла сделки и цикла продаж очевидно хороший знак;
  • метрики KPI отличный инструмент для измерения эффективности автоматизации: сравнивая показатели сотрудников в динамике, можно увидеть, как они изменились и по вектору изменений судить о результатах или принимать меры для корректировки работы сотрудников в АСУ (например, в CRM);
  • количество жалоб или обращений в службу поддержки после внедрения автоматизации поток жалоб должен сократиться за счёт того что менеджеры не будут допускать части ошибок в работе с клиентами (таких как простроченные контакты, забытые письма и документы, пропущенные звонки и т.д.).

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

Один из рабочих методов оценивать по стоимости бизнес-процесса или трудозатратам каждого сотрудника. Рассмотрим на примере.

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

Менеджер Вася тратит на всю эту цепочку примерно 8 рабочих дней, но не целиком, а в среднем по 2 часа в день (встреча длиннее, звонок короче и т.д.). Итого Вася потратил 16 часов на этого клиента. Из них самые длинные этапы: встреча (ничего не поделаешь, её не учитываем), подсчёт товара на складе и общение с логистом (2 часа), подготовка КП (1 час), подготовка договора (2 часа), подготовка закрывающих документов (1 час). Итого 6 часов оперативной работы с документами и складом. Час работы Васи обходится работодателю в 400 рублей (чистые васины + налоги и соцстрах), то есть эта вот работа 2400 рублей. Не очень много, если учесть, что заказ будет большим. Пусть наш Вася больше ничего в компании не делает, только флешки с нанесением продаёт корпам, значит, за месяц он может обслужить 10 клиентов. То есть оперативная работа Васи обойдётся в 24 000, в год 264 000 (1 месяц он в отпуске).

А теперь представим, что в компании есть CRM, в которой отображаются остатки на складе в режиме реального времени, включены шаблоны КП и договоров, есть печатные формы всей закрывающей документации. Васе не нужно перепечатывать и копипастить наименования, считать цены и стоимость, искать скидки, вбивать реквизиты, искать логиста и перебирать виды флешек по коробочкам он всё это видит в CRM и заполняет документы в 10-20 кликов, выбирая точные наименования, условия скидок, услуги и т.д., отсылая всё это из почты в CRM клиенту. При самой низкой сноровке он потратит 1 час, то есть в 6 раз меньше. И компании в год его оперативная возня обойдётся в 44 000? Нет, больше потому что Вася сможет обслужить гораздо больше клиентов. То есть накладные расходы на сделку сократятся, а количество сделок вырастет. В масштабах даже небольшого рекламного агентства это прямо норм.

Смоделируем: рынок конкурентный, не безграничный и Вася смог обслужить в среднем в месяц по 15 клиентов. По старой схеме компания бы за его рутину заплатила 396 000 рублей (11 месяцев * 15 клиентов * 2400 рублей). По новой схеме с CRM 66 000 рублей. При этом 1 лицензия CRM на Васю стоила примерно 16 000 рублей навсегда, без аренды (представим, что компания купила единоразово 10 лицензий RegionSoft CRM Professional Plus). То есть чисто экономия на части процесса (на малой части!) уже окупает лицензию сотрудника. А ведь ещё и автоматизирован дорогой логист, склад и проч. То есть стоимость бизнес-процесса благодаря автоматизации становится ниже. А мы с вами ещё не посчитали увеличение дохода за счёт прибывших клиентов, на которых у Васи стало хватать времени.
А теперь вернёмся к вопросу экономического эффекта от внедрения системы автоматизации. Можно провести расчёт для каждого этапа всех процессов в компании и каждого задействованного сотрудника в конечном итоге получится примерный эффект. Только не забывайте, что для оценки стоимости владения системой вам понадобится рассчитать интегральный показатель совокупной стоимости владения (Total Cost of Ownership, TCO), который включает затраты, связанные с приобретением, внедрением и эксплуатацией АСУ; а стоимость сотрудника и часа его работы следует рассчитывать не по чистой заработной плате, а по ФОТу, социальным затратам, косвенным затратам (оргтехника, содержание офиса, интернет и т.д.)

Не забывайте, что ТСО для облачных систем нужно умножать на количество используемых месяцев и он будет постоянно расти за счёт периодических платежей, а для десктопных систем ТСО чаще состоит из единовременного платежа за лицензии (ну или рассрочки), стоимости доработки, поддержки и обновлений. Иногда компании выгоднее иметь ТСО хоть и больше, но распределённым во времени для таких компаний мы, например, и для десктопной RegionSoft CRM предлагаем аренду с возможностью выкупа ПО после 7 месяцев аренды и кучей других бонусов.

Кстати, о CRM.

Средства автоматизации бизнеса


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

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

Как выбрать средство автоматизации?


Есть два основных пути выбрать систему автоматизации бизнеса.

  1. Приобрести готовое решение у вендора (разработчика) и провести профессиональное внедрение. В конечном итоге это быстрее, дешевле и легче: на рынке представлено такое количество решений, что можно найти что угодно, от систем автоматизации автосервиса, систем автоматизации учебных курсов и салонов красоты до крупных решений автоматизации завода. Вы выиграете по срокам, точности внедрения, корректности обучения и сможете довольно быстро приступить к работе в новой плоскости.
  2. Разработать систему самостоятельно и самостоятельно же внедрить. По состоянию на 2020 год это, конечно, путь самурая и не факт, что в конце не будет харакири. Долгий, сложный процесс с подбором стека технологий и исполнителей, затянутыми сроками, откровенными кидками от нанятых разработчиков и т.д. Сложно придумать сферу, которой бы подошёл этот вариант. Разве что вы форкнете какой-нибудь опенсорс, сделаете кастомную отраслевую версию и решите стать ИТ-компанией, внедряющей этот софт. Это куда ни шло. А трата времени на собственную разработку, когда вокруг есть всё, сильно смахивает на потребность собрать себе своими руками автомобиль из холодильника Саратов и движка от Феррари по фану, круто, но безумно дорого и проблематично в эксплуатации.

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

CRM как частный случай автоматизации бизнеса


CRM-система один из самых популярных инструментов автоматизации малого и среднего бизнеса. И если раньше CRM-система автоматизировала только отдел продаж и немножечко маркетинг, то сейчас большинство современных решений на рынке представляют собой универсальные бизнес-комбайны. Например, наша редакция RegionSoft CRM Enterprise Plus уже фактически полноценная ERP и может в одной программе: автоматизировать продажи, управление проектами, задачами, KPI, работу с первичными документами, включает в себя почту, телефонию, мультивалютный учёт, логистику, складской учёт, кассовый учёт, многопередельное производство, механизм расчётов, имеет более 100 типовых отчётов, различные конструкторы и, конечно, механизм автоматизации бизнес-процессов. А кроме этого, раз в 2-3 года выходят мажорные релизы, которые добавляют самые востребованные функции к уже существующим. Вся эта история называется сквозной автоматизацией самым безопасным и удобным способом автоматизации, когда практически вся компания может работать в одной информационной среде.

CRM-система на сегодняшний день это базовый элемент автоматизации, понятный и остро необходимый, особенно в кризис, особенно для распределённой команды. Да что там говорить необходимый всегда!

Однако, выбирая CRM, как и любое другое средство автоматизации, нужно помнить о трёх главных правилах:

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

По разным оценкам экспертов, уровень автоматизации российских компаний составляет где-то от 10 до 15%. Это очень мало. Да и своими глазами мы можем видеть, как, например, доставка Перекрёстка приезжает при терминалах, чековых машинах, всё отлажено и работает как часы, а ресторан в центре города только недавно перестал выдавать рукописные чеки, бронь так до сих пор записана на меловой доске; как небольшие ИТ-компании вкладываются в автоматизацию всего и вся, чтобы быть впереди, а серьёзные торговые компании вручную заполняют счета и акты Эти перекосы обусловлены и национальными особенностями, и недоверием к технологиям, и переживаниям за себя в пространстве отечественной экономики. Но факт остаётся фактом: с автоматизированным бизнесом живётся гораздо лучше, безопаснее и устойчивее. Всё остальное надуманные оправдания.


У нас действует акция Осень вступает в свои права вы можете купить RegionSoft CRM на очень хороших условиях:

  1. Для тех, кто покупает сразу (100% предоплата) предоставляется скидка в размере 15% от цены стандартного прайс-листа.
  2. Для тех, кто покупает в рассрочку- беспроцентная рассрочка на 3 равных платежа, по 1 платежу в месяц, при условии совокупной стоимости лицензий от 38 000 руб.
  3. Подписка вместо покупки предоставляется скидка в размере 30% при оплате подписки на 3 месяца. Минимальная стоимость подписки составляет 3400 рублей в месяц (без учёта скидки).

А ещё мы здорово работаем удалённо: устанавливаем, внедряем, обучаем, поддерживаем. Звоните или оставляйте заявку онлайн-демонстрация бесплатная, подробная и интересная.



Мультик про Нехочуху, если вы вдруг не олд и не бумер:

Подробнее..

Эволюция ИТ от локальных серверов до managed services

28.09.2020 16:10:09 | Автор: admin

За последние 30 лет ИТ-индустрия и подход к предоставлению ИТ-услуг изменились кардинально. Попробуем проследить основные этапы этой эволюции.

Эволюция Managed IT наглядноЭволюция Managed IT наглядно

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

1990-е: зарождение аутсорсинга

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

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

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

2000-е: появление управляемых сервисов

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

В то же время начали появляться хостинг-провайдеры, которые сдавали в аренду аппаратные мощности в дата-центрах (co-location). Обслуживание инфраструктуры провайдеры брали на себя.

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

Еще один маркер: появление прикладных корпоративных приложений в облаке SaaS. Первопроходцем стала компания Salesforce, разработчик CRM-платформы, которая существует и поныне. Здесь уже клиенты не задумывались о том, чтобы поддерживать инфраструктуру для функционирования корпоративного ПО этим занимался поставщик.

2010-е: становление MSP

Компании, которые раньше были ИТ-консультантами, стали предлагать, если буквально, управляемые ИТ-услуги (managed IT). Они набирали в команду специалистов разных квалификаций от системных администраторов до разработчиков, чтобы предоставлять полный набор услуг: настройку, администрирование и мониторинг ИТ-сервисов. Чем большим количеством сервисов управлял такой провайдер (Managed Service Provider MSP), тем он был успешнее.

Важная особенность: аутсорсинг у MSP стал уже преимущественно удаленным.

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

2020: зрелость managed IT

На Западе индустрия управляемых ИТ-услуг полностью созрела и стала доминирующей сервисной моделью в ИТ. В России, по нашим наблюдениям, этот процесс отстает лет на 5.

Отметим главные особенности рынка managed IT.

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

  • Инфраструктура и сервисы передаются в ведение MSP, который управляет и мониторит сервисы онлайн.

  • Главная метрика для MSP не количество часов, которые отработал инженер, а должный уровень доступности сервиса, прописанный в SLA.

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

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

  • Капитальные затраты на ИТ сменились на операционные на ежемесячные платежи. Компаниям стало проще планировать ИТ-бюджет.

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

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

Managed IT в России

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

Компаний, ИТ-сервисы которых застряли в 19902000-х, конечно, с каждым годом меньше. Российский рынок ИТ медленно, но верно движется в сторону managed services модели предоставления ИТ-услуг, которая, как нам кажется, наиболее адекватна реальности.

Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru