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

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

Протестируй меня полностью кому и зачем нужен внутренний пентест

21.07.2020 10:07:42 | Автор: admin

Опаснее всего враг, о котором не подозреваешь.
(Фернандо Рохас)

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

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

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

Важно: в этом посте речь идет о Windows-сетях с использованием Active Directory.

Кто и что проверяет


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

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

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

Как это происходит


Тестирование безопасности внутренней инфраструктуры проходит в несколько этапов:


Вот пример того, как в реальности проходил подобный внутренний пентест в рамках одного из наших проектов:
сначала мы выявили общие файловые ресурсы, на которых располагались веб-приложения;
в одном файле конфигурации обнаружили пароль пользователя SA (Super Admin) к базе данных MS SQL;
с помощью встроенной в MS SQL утилиты sqldumper.exe и процедуры xp_cmdshell получили дамп процесса LSASS, через подключение к СУБД:
из процесса извлекли пароль пользователя с привилегиями доменного администратора.

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

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


Кто заходит в инфраструктуру


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

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

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

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

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

Кому все это нужно


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

Автор: Дмитрий Неверов, эксперт по анализу защищенности, Ростелеком-Солар
Подробнее..

Ещё один шаг в сторону open source как и почему мы внедрили Arenadata DB

22.04.2021 10:12:30 | Автор: admin

Привет, Хабр! Меня зовут Станислав Маскайкин, я архитектор аналитических систем ВТБ. Сегодня я расскажу о том, почему мы перевели нашу систему подготовки отчётности с Oracle SuperCluster на российскую Arenadata DB. Как мы выбирали решение, почему не взяли чистый опенсорс, а также о некоторых результатах такой миграции под катом.

Зачем нужен был переход?

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

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

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

Исторически ВТБ24 был ориентирован на работу с физическими лицами, ВТБ на работу с юридическими лицами, а Банк Москвы на работу и с первыми, и со вторыми.

На момент объединения этих банков обязательная отчётность формировалась в следующих системах:

  1. Единое хранилище данных (ЕХД) хранилище данных Банка Москвы, реализованное на SuperCluster M8 и ETL-инструменте Informatica Power Center.

  1. Система подготовки отчётности хранилище данных ВТБ24, реализованное на Oracle SuperCluster M8 с программным обеспечением Diasoft Flextera BI. Данные для этой системы готовились в другом хранилище корпоративном хранилище данных (КХД), реализованном на СУБД Teradata и ETL-инструменте SAS Data Integration. КХД, в свою очередь, получало данные из оперативного хранилища данных, реализованного на Oracle SuperCluster M8. А туда они реплицировались из автоматизированных банковских систем при помощи инструмента Oracle Golden Gate.

  1. Корпоративное информационное хранилище хранилище данных ВТБ, реализованное на Oracle Exadata X8-2 и ETL-инструменте Informatica Power Center.

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

Это привело к ещё двум большим проблемам:

  1. Увеличилось время получения данных, что часто приводило к срыву сроков предоставления информации.

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

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

Ещё один момент: многие компоненты нашей инфраструктуры, такие как Oracle SuperCluster, на котором у нас реализована большая часть аналитического ландшафта, попали под End of life. Они были сняты с поддержки производителем и больше не развивались, т.е. обновление необходимо было в любом случае.

Проблема окончания поддержки коснулась не только системы подготовки отчётности, но и озера данных на платформе Oracle Big Data Appliance. К тому моменту а происходило все в 20182019 годах сотрудники ВТБ уже в полной мере оценили data-driven подход и потребляли достаточно много данных. Поэтому с точки зрения бизнеса банка система была критичной. Т.е. перед нами стояла более глобальная задача масштабов всей инфраструктуры.

Параллельно в объединённом ВТБ началась масштабная цифровая трансформация, охватившая все уровни IT, начиная от создания новых ЦОДов и объединения сетей, и заканчивая унификацией автоматизированных банковских систем и созданием омниканальной платформы для фронтальных решений. Всё это кардинально меняло внутренний IT-ландшафт банка.

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

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

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

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

Мы выделили 6 компонентов технологического ядра:

  1. Управление данными.

  2. Управление качеством данных.

  3. Управление доступом.

  4. Аналитические справочники.

  5. Корректировки.

  6. ETL Framework.

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

Ядром платформы данных является СУБД, на которой реализовывается хранилище данных. Далее расскажу об этом подробнее.

Выбор новой платформы

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

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

Мы рассматривали всех крупнейших производителей подобных решений: Oracle Exadata, Teradata, Huawei. Оценили отечественные разработки практически все, что есть на рынке. Нам показался интересным опенсорс, тем более для банка это не первый заход в тему открытого исходного кода.

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

При выборе платформы мы учитывали следующие критерии:

  • функциональность

  • качество поддержки

  • отсутствие санкционных рисков

  • возможность гибкого масштабирования

  • надёжность

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

  • наличие Road Map развития платформы и возможность на него влиять

  • стоимость владения совокупные затраты на программно-аппаратный комплекс на горизонте 10 лет (TCO5).

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

В итоге по совокупности факторов мы выбрали Arenadata DB.

Тестирование платформы

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

В итоге нами были проведены следующие проверки.

  • Функциональное тестирование:

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

  • Отказоустойчивость и отключение компонентов:

  • Отключение дисковых устройств на уровне БД для проверки стабильности работы кластера.

  • Отключение питания одного блока питания на серверах для проверки стабильности работы кластера.

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

  • Совместимость со средствами резервного копирования банка:

    • Проведение цикла резервного копирования и восстановления БД на СРК Veritas Netbackup:

      • Полное резервное копирование БД

      • Инкрементальное резервное копирование БД

      • Восстановление БД

  • Управление и качество работы системы:

    • Перезагрузка кластера: фиксация успешного выполнения процедуры перезагрузки.

    • Мониторинг и управление: субъективная балльная оценка от 0 до 5.

    • Генерация тестового отчёта: прогон запроса изсистемы подготовки отчётности в Arenadata DB для анализа качества результата генерируемого отчёта результаты выполнения отчёта должны быть идентичны.

  • Нагрузочное тестирование:

    • Скорость загрузки данных

  • Интеграционное тестирование:

    • Интеграция с ПО Infomatica Power Center

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

    • Интеграция с QlikView 12.

Результаты тестирования

В ходе тестирования кластера Arenadata DB показал высокую производительность как на синтетических тестах, так и на реальных нагрузках.

Ниже приведено сравнение скорости выполнения запросов по сравнению с текущим Oracle Super Cluster T5-8.

Тестирование проводил системный интегратор IBS Platformix.

Скорость выполнения синтетического запроса Jmeter (сек)

Arenadata DB (сек.)

Oracle (сек.)

160.3

1291

Кластер показал высокую скорость загрузки данных через ETL-инструмент Informatica Power Center: 200 Мбит/с.

В ходе тестирования была также осуществлена интеграция с основными BI-инструментами, используемыми в Банке ВТБ (Oracle BI и QlikView), и протестирован их функционал.

В QlikView на простейших SQL-запросах протестированы соединение с БД и выборка данных с последующей загрузкой в модель BI-инструмента.

Результаты выполнения представлены в таблице ниже.

Тест 1

Тест 2

Драйвер

ODBC PostgreSQL35W

ODBC PostgreSQL35W

Запрос

select * from user.test1

// 3 коротких поля

select e.* from dds.accounts e

where

e.entry_dt ='2019-02-03'

-and e.partition_source_system_cd ='00006'

and e.src_deleted is null

Строк

20480000

45 920

Затраченное время

0:58

2:59

Скорость загрузки в модель, строк в сек.

353103

257

При выполнении тестов была замечена особенность: получение первых строк данных из БД происходило с задержкой примерно в 23 секунды. После этого скорость выборки данных из БД и их доставки в QlikView становилась очень высокой.

Предположительно данная особенность связана c неоптимальной настройкой коннектора.

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

Цель теста

Предварительные условия

Процедура

Результат

Тестирование отказа диска с данными

Отказ диска эмулируется физическим извлечением диска или логическим отключения дискового уст-ва из работающего сервера.

Подключиться к серверу

Провести процедуру unmount для физического диска

Проверить доступность данных

Данные доступны

Тестирование отказа кэширующего диска

Отказ диска эмулируется физическим извлечением диска или логическим отключения дискового устройства из работающего сервера

Подключиться к серверу

Провести процедуру unmount для физического диска

Проверить доступность данных

Данные доступны

(Отказ кэширующего диска не приводит к потере данных)

Тестирование включения кластера после эмуляции аварии

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

Подключиться к серверу

Выполнить SQL запрос

Выключить 1 ноду

Перезапустить выполнение SQL

Данные получены при повторном SQL запросе

Благодарю Дениса Степанова и Никиту Клименко, экспертов IBS Platformix, за предоставленные результаты тестирования.

Сбор отчётности как пилот

Наша цель это миграция на Arenadata DB всех существующих хранилищ банка ВТБ.

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

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

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

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

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

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

Поскольку мы уже видим результаты и детали взаимодействия, около полугода назад стартовал наш основной проект - миграция на продукты Arenadata центрального единого хранилища данных и озера данных. Помимо Arenadata DB, мы используем Arenadata Streaming на базе Apache Kafka и Arenadata Hadoop на базе Apache Hadoop. В ближайшее время первые результаты пойдут в продакшен.

Целевая архитектура платформы данных к концу 2022 годаЦелевая архитектура платформы данных к концу 2022 года

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

Подробнее..

Recovery mode От стартапа до тысяч серверов в десятке ЦОД. Как мы гнались за ростом Linux инфраструктуры

03.07.2020 20:16:17 | Автор: admin
Если ваша IT инфраструктура растёт слишком быстро, вы рано или поздно столкнётесь с выбором линейно увеличивать людские ресурсы на её поддержку или начинать автоматизацию. До какого-то момента мы жили в первой парадигме, а потом начался долгий путь к Infrastructure-as-Code.



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

В целом, можно сказать, что наша команда поставляет для компании 2 продукта. Первый это инфраструктура. Почта должна ходить, DNS работать, а контроллеры домена пускать вас на сервера, которые не должны падать. IT ландшафт компании огромен! Это business&mission critical системы, требования по доступности некоторых 99,999. Второй продукт сами сервера, физические и виртуальные. За существующими нужно следить, а новые регулярно поставлять заказчикам из множества подразделений. В этой статье я хочу сделать акцент на том, как мы развивали инфраструктуру, которая отвечает за жизненный цикл серверов.

Начало пути

В начале пути наш стек технологий выглядел так:
ОС CentOS 7
Контроллеры домена FreeIPA
Автоматизация Ansible(+Tower), Cobbler


Всё это располагалось в 3х доменах, размазанных на нескольких ЦОДах. В одном ЦОД офисные системы и тестовые полигоны, в остальных ПРОД.

Создание серверов в какой-то момент выглядело так:



В шаблоне VM CentOS minimal и необходимый минимум вроде корректного /etc/resolv.conf, остальное приезжает через Ansible.

CMDB Excel.

Если сервер физический, то вместо копирования виртуальной машины на него устанавливалась ОС с помощью Cobbler в конфиг Cobbler добавляются MAC адреса целевого сервера, сервер по DHCP получает IP адрес, а дальше наливается ОС.

Поначалу мы даже пытались делать какой-то configuration management в Cobbler. Но со временем это стало приносить проблемы с переносимостью конфигураций как в другие ЦОД, так и в Ansible код для подготовки VM.

Ansible в то время многие из нас воспринимали как удобное расширение Bash и не скупились на конструкции с использованием shell, sed. В общем Bashsible. Это в итоге приводило к тому, что, если плейбук по какой-либо причине не отрабатывал на сервере, проще было удалить сервер, поправить плейбук и прокатить заново. Никакого версионирования скриптов по сути не было, переносимости конфигураций тоже.

Например, мы захотели изменить какой-то конфиг на всех серверах:

  1. Изменяем конфигурацию на существующих серверах в логическом сегменте/ЦОД. Иногда не за один день требования к доступности и закон больших чисел не позволяет применять все изменения разом. А некоторые изменения потенциально деструктивны и требуют перезапуск чего-либо от служб до самой ОС.
  2. Исправляем в Ansible
  3. Исправляем в Cobbler
  4. Повторяем N раз для каждого логического сегмента/ЦОД

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

  • Рефакторинг ansible кода, конфигурационных файлов
  • Изменение внутренних best practice
  • Изменения по итогам разбора инцидентов/аварий
  • Изменение стандартов безопасности, как внутренних, так и внешних. Например, PCI DSS каждый год дополняется новыми требованиями

Рост инфраструктуры и начало пути

Количество серверов/логических доменов/ЦОД росло, а с ними количество ошибок в конфигурациях. В какой-то момент мы пришли к трём направлениям, в сторону которых нужно развивать configuration management:

  1. Автоматизация. Насколько возможно, нужно избегать человеческого фактора в повторяющихся операциях.
  2. Повторяемость. Управлять инфраструктурой намного проще, когда она предсказуема. Конфигурация серверов и инструментов для их подготовки должна быть везде одинаковой. Это так же важно для продуктовых команд приложение должно гарантированно после тестирования попадать в продуктивную среду, настроенную аналогично тестовой.
  3. Простота и прозрачность внесения изменений в configuration management.

Осталось добавить пару инструментов.

В качестве хранилища кода мы выбрали GitLab CE, не в последнюю очередь за наличие встроенных модулей CI/CD.

Хранилище секретов Hashicorp Vault, в т.ч. за прекрасное API.

Тестирование конфигураций и ansible ролей Molecule+Testinfra. Тесты идут намного быстрее, если подключаете к ansible mitogen. Параллельно мы начали писать собственную CMDB и оркестратор для автоматического деплоя (на картинке над Cobbler), но это уже совсем другая история, о которой в будущем расскажет мой коллега и главный разработчик этих систем.

Наш выбор:

Molecule + Testinfra
Ansible + Tower + AWX
Мир Серверов + DITNET(Собственная разработка)
Cobbler
Gitlab + GitLab runner
Hashicorp Vault




Кстати про ansible роли. Сначала она была одна, после нескольких рефакторингов их стало 17. Категорически рекомендую разбивать монолит на идемпотентные роли, которые можно потом запускать отдельно, дополнительно можно добавить теги. Мы роли разбили по функционалу network, logging, packages, hardware, molecule etc. А вообще, придерживались стратегии ниже. Не настаиваю на том, что это истина в единственной инстанции, но у нас сработало.

  • Копирование серверов из золотого образа зло!

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

    1. Оставьте /etc/sysctl.conf пустым, настройки должны лежать только в /etc/sysctl.d/. Ваш дефолт в один файл, кастом для приложения в другой.
    2. Используйте override файлы для редактирования systemd юнитов.
  • Шаблонизируйте все конфиги и подкладывайте целиком, по возможности никаких sed и его аналогов в плейбуках
  • Рефактория код системы управления конфигурациями:

    1. Разбейте задачи на логические сущности и перепишите монолит на роли
    2. Используйте линтеры! Ansible-lint, yaml-lint, etc
    3. Меняйте подход! Никакого bashsible. Нужно описывать состояние системы
  • Под все Ansible роли нужно написать тесты в molecule и раз в день генерировать отчёты.
  • В нашем случае, после подготовки тестов (которых больше 100) нашлось около 70000 ошибок. Исправляли несколько месяцев.


Наша реализация

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



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

Вариантов создания серверов тоже много. Мы в итоге выбрали кастомные скрипты на питоне. А для CI ansible:

- name: create1.yml - Create a VM from a template  vmware_guest:    hostname: "{{datacenter}}".domain.ru    username: "{{ username_vc }}"    password: "{{ password_vc }}"    validate_certs: no    cluster: "{{cluster}}"    datacenter: "{{datacenter}}"    name: "{{ name }}"    state: poweredon    folder: "/{{folder}}"    template: "{{template}}"    customization:      hostname: "{{ name }}"      domain: domain.ru      dns_servers:        - "{{ ipa1_dns }}"        - "{{ ipa2_dns }}"    networks:      - name: "{{ network }}"        type: static        ip: "{{ip}}"        netmask: "{{netmask}}"        gateway: "{{gateway}}"        wake_on_lan: True        start_connected: True        allow_guest_control: True    wait_for_ip_address: yes    disk:      - size_gb: 1        type: thin        datastore: "{{datastore}}"      - size_gb: 20        type: thin        datastore: "{{datastore}}"

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

  • 17 ansible-ролей для настройки сервера. Каждая из ролей предназначена для решения отдельной логической задачи (логирование, аудит, авторизация пользователей, мониторинг и т.д.).
  • Тестирование ролей. Molecule + TestInfra.
  • Собственная разработка: CMDB + Оркестратор.
  • Время создания сервера ~30 минут, автоматизировано и практически не зависит от очереди задач.
  • Одинаковое состояние/именование инфраструктуры во всех сегментах плейбуки, репозитории, элементы виртуализации.
  • Ежедневная проверка состояния серверов с генерацией отчётов о расхождениях с эталоном.

Надеюсь мой рассказ будет полезен тем, кто в начале пути. А какой стек автоматизации используете вы?
Подробнее..

Как мы автоматизировали весь жизненный цикл серверов

15.07.2020 18:16:18 | Автор: admin

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



В нашей компании, как и в любой другой, существуют свои регламенты и бизнес-процессы. Один из них это тот, по которому мы создаем сервера или стенд серверов по заявке Jira ServiceDesk. У сервера есть функциональный администратор, т.е. владелец. У серверов также имеется статус (Тестовый, Продуктивный, UAT и т.д.). Из-за статусов и других характеристик сервера должны находится в своем сегменте, датацентре, датасторе, сети и прочее. А значит, чтобы создать сервер сначала требуется: создать сервер в VMware, задать ему имя, ip, dns и другие немаловажные параметры, а потом уже прокатить ansible-playbook.


История развития


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


Для учета серверов мы использовали excel-файл. Для учета ip использовали phpIPAM https://phpipam.net/. phpIPAM open source продукт для учета адресным пространством. Еще некоторая информация могла находиться в самой системе мониторинга. Количество серверов насчитывалось не более 700.


В нашем отделе сотрудники отвечают за разные задачи: одни занимаются Виртуализацией и СХД, другие Windows, а мы Linux. Также есть отдел, где находятся сетевые инженеры и администраторы БД.


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


1) Требовалось узнать в каком датацентре, датасторе, сети и прочее
2) Создать сервер в требуемом сегменте через Vcenter
3) Прогнать bash-скрипты и некоторые ansible-playbookи
4) Добавить корректные данные о сервере в excel-файл
5) Добавить ip в phpIPAM
6) Закрыть заявку, если она была


Через некоторое время стало понятно, требуется создавать все больше и больше серверов. И мы стали искать варианты систем для хранения информации и учета серверов.
На просторах интернета таких систем немало. Даже в phpIPAM можно хранить информацию о серверах. Но в таких системах неудобно смотреть и анализировать состояние серверов в разрезе. В них не было необходимых полей и связей, нет фильтров по полям как в excel, нет четкого разграничения прав на редактирование и просмотр определенных серверов.
Мне тогда нравился Python, и я хотел сделать что-то на Django. Поэтому решил написать свою CMDB для нужд отдела и компании. После ее создания мы решили автоматизировать процесс создания и настройки серверов. Что получилось? Об этом далее


Мир серверов


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



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



Кроме хранения данных о серверах Мир серверов имеет функционал:


  • Разграничение прав доступа на просмотр и редактирование данных (по департаменту, по управлению, по отделу)
  • Удобный просмотр серверов в табличном виде, фильтр по любым полям, показ/скрытие полей
  • Разнообразные оповещения по почте
  • Актуализация информации о серверах
  • Ежедневный сбор данных о серверах и хранение для аналитики по ресурсам систем


  • Поиск и сравнение установленных приложений на серверах


Интеграция Мира серверов с другими системами:
1) Автоматическое обновление ip в phpIPAM
2) Выполнение заявок Jira ServiceDesk на предоставление нового сервера (стенда серверов) через Мир серверов
3) Просмотр расположения физического сервера и правильность заполнения информации в системе dcTrack (https://www.sunbirddcim.com/)
1) Передача информации о серверах через REST API для Zabbix и других систем мониторинга
2) Передача информации о ПО установленного на серверах через REST API для нужд ИБ
3) Синхронизация владельцев серверов из 1С и Active Directory для получения ФИО, рабочей почты, принадлежность к подразделению, статусе сотрудника. Надо написать, что такие данные требуется для разграничения прав, а также для автоматического оповещения владельцев серверов о ряде событий, связанных с их серверами.


DitNet


Наша инфраструктура на данный момент имеет более 10 ЦОД. Из этого понятно, что Мир серверов не сможет в любом сегменте создать и настроить сервер из-за понятных требований PCI-DSS.
Поэтому при выполнении заявок на предоставление сервера мы формируем json с данными, которые требуется для создания в среде VMware. Передача json реализована через защищенный rsync или ftps зависит от сегмента.
Надо заметить, что наш отдел провел очень большую работу. Убрали bashsible, переработали ansible на идемпотентные роли для настройки серверов, настроили molecule (https://molecule.readthedocs.io/), унифицировали все артефакты VMware и много чего другого. Стандартизация артефактов VMware потребовалась по большей части для серверных подсетей во всех ЦОДах (у нас их уже больше 900).
Как пример:
Раньше Distributed Switch мог называться test2, а теперь 192.168.1.0|24_test2. Данное переименование требовалось, чтобы можно было на этапе формирования json сделать матчинг подсетей из phpIPAM и VMware.


Выполнение заявок по предоставлению серверов:
1) DitNet ежедневно или по запросу собирает все артефакты из VMware (кластеры, датасторы, сети, шаблоны и т.д). Упаковывает всю информацию в json и отправляет в Мир серверов
2) Мир серверов принимает данные и наполняет данные БД артефактами VMware
3) В Мире серверов имеется страница, которая обращается к Jira ServiceDesk и по jql-запросу получает список заявок на предоставление серверов со статусом Очередь. На этой странице исполнитель заполняет таблицу артефактами VMware и другими ресурсами (Рис. Ниже). Часть данных автоматически заполняется данными, которые были указаны в заявке.



4) После заполнения и нажатия кнопки Сотворить, заявка меняет статус в Jira ServiceDesk В работе
5) В этот момент Мир серверов формирует json с данными о создании ВМ (артефакты, dns, ip и т.д.) и перекладывает его в папку для своего сегмента (определяется по домену сервера)
6) Каждый DitNet в своем сегменте запрашивает данные из своей папки и обогащает данными таблицу с серверами на установку. В БД имеются дополнительные поля с информацией по статусу установки (по умолчанию: готов к установке)
7) На DitNet каждые 5 минут отрабатывает Celery beat, который по статусу установки определяет количество серверов, которые требуется установить и настроить
8) Celery worker запускает несколько последовательных задач:
a. Создает сервер в VMware (используем библиотеку pyvmomi)
b. Скачиваем или обновляем проект gitlab по настройке сервера
c. Запускается Ansible-playbook (используем данный гайд https://docs.ansible.com/ansible/latest/dev_guide/developing_api.html)
d. Запускается Molecule
e. Отправка почты исполнителю и Миру серверов о статусе выполнения
9) После каждой задачи проверяется статус. Если все задачи выполнены оповещаем исполнителя с сформированной ссылкой для закрытия заявки Jira ServiceDesk. Если какая-нибудь из задач провалилась, то оповещаем исполнителя с логом Vmware или Ansible.


Что еще умеет Ditnet на данный момент:


  • Собирает все данные и ресурсы со всех серверов. Для данной задачи мы используем Ansible с модулем setup. На хостах кроме локальных фактов используем также кастомные. Перед каждым запуском формируем инвентарь для Windows и Linux.
  • Собирает информацию SNMP о физических серверах. Сканируем определенные подсети и получаем серийный номер, версию BIOS, версия IPMI и т.д.
  • Собирает информацию о группах серверов в Freeipa (HBAC, SUDO правила), о группах в Active Directory. Для сбора и контроля ролевой модели доступа пользователей к информационным системам
  • Переустановка серверов
  • А еще там на заднем фоне котики. Рисунок ниже:


Вся информация, которую собирает DitNet, отправляется в Мир серверов. А там уже и проходит вся аналитика и актуализация данных о серверах.


Как мы обновляемся


В данный момент над Миром серверов и DitNet тружусь уже не только я. Нас уже три человека.
Весь исходный код хранится в наших Gitlab для удобной параллельной разработки. В каждом из проектов имеется свой Ansible-playbook, который запускает Gitlab CI и обновляет приложение. Pipeline:



По pipeline видно, что не хватает unit-тестов. Но, думаю, мы в скором будущем это исправим.
Также Ansible-playbook можно запустить через Ansible Tower (AWX) на новых серверах, если требуется новая инсталляция.
В случае с DitNet мы используем docker, чтобы доставлять нужные библиотеки во все сегменты. Он описан docker-compose. А docker-compose services завернуты в systemd.


Планируется в будущем


  • Автоматическое выполнение заявок на установку серверов без исполнителя
  • Плановое автоматическое обновление серверов
  • Добавление в Мир серверов сущности СХД и автоматический сбор данных
  • Сбор информации с физических серверов о всех комплектующих для отправки в Мир серверов для контроля ЗИПа серверов
  • Автоматическое оповещение об уходе из компании владельца сервера для последующей привязки серверов к будущему владельцу
  • Продолжение интеграции с другими системами компании
    и много еще интересного!

P.S. Спасибо за Ваше время! Критика и комментарии приветствуются!

Подробнее..

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

05.10.2020 20:08:11 | Автор: admin


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

Компания, которая написала, занималась аналитикой данных. Ежедневно она обрабатывала тысячи запросов. К нам они пришли со словами: ребят, у нас есть ClickHouse и мы хотим автоматизировать его настройку и установку. Хотим Ansible, Terraform, Докер и чтобы это все хранилось в гите. Хотим кластер из четырех нод по две реплики в каждой.

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

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

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

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

Он объявил, что нам нужен второй кластер Кликхауса. И отныне мы будем писать данные на два кластера основной и бэкапный. Я ему говорю, мол, Лёня, выйдет не бэкап а активная реплика. И если данные начнут теряться на продакшене, на твоем бэкапе будет то же самое.

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

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

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


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

Все это выяснилось очень-очень болезненно. А самое обидное, это было в мой день рождения.



Пятница, вечер. Я забронировал столик в любимом винном баре и позвал корешей.

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

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

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

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

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

Вот так я не сказал. Вместо этого достал ноут и принялся за работу.

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

Остановили запись, посчитали число ивентов, которые там лежат за день. Закинули еще данных, от которых не записалась только треть. Три шарды по 2 реплики. Вставляешь 100.000 строк 33.000 не записываются.

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

Что происходило на самом деле никто не понимал.


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

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

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

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

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

К 6 утра я пересоздал таблицу заново, и данные начали заливаться. Все заработало без потерь.



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


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

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

Мне хотелось справедливости. Я откопал переписку и приложил всех скриншотами, где Леонид со всей силы заставляет делать такой бэкап, какой был сделан. Их СТО встал на нашу сторону после моего телефонного звонка. После свою вину признал и Леня.

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

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



Это была самая стремная встреча в моей карьере. Мой союзник от клиента СТО не смог найти время. На встречу я ехал к боссу и Лёне.

Раз за разом я прокручивал в голове наш возможный диалог. Умудрился приехать сильно заранее, за полчаса. Начался нервяк, я выкурил сигарет 10. Я понимал, всё я, нахрен, один. Я не смогу их переубедить. И шагнул в лифт.

Пока поднимался, так чиркал зажигалкой, что сломал ее.

В итоге Лёни на встрече не оказалось. И мы отлично обо всем поговорили с главным! Сергей рассказал мне про свою боль. Он хотел не автоматизировать Кликхаус он хотел, чтобы запросы работали.

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

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

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

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



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

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

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

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

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

Собственно, на этом мы и расстались сделали, что смогли.



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

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

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

P.S. Так что, если у вас есть вопросы по вашей инфраструктуре, смело оставляйте заявку.

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

VMworld 2020 щеночки, кубики и Рене Зеллвегер

16.10.2020 20:06:22 | Автор: admin

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

Год перемен

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

Крис Вольф, вице-президент VMware, ввел новое значение термина выносливость применительно к бизнес-сообществу: теперь это не просто способность справляться с повышенными нагрузками, но и умение адаптироваться к меняющимся условиям, сохраняя свою целостность. Девиз VMworld 2020 Когда мы вместе, все становится возможным (Together, Anything is Possible).

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

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

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

VMware SASE Platform

Первый продукт, о котором мы сегодня расскажем, VMware SASE Platform. Задача решения обеспечить сотрудников компаний инструментами сетевой безопасности в любом месте, где бы они ни находились. VMware SASE Platform базируется на VMware SD-WAN массиве, состоящем из более чем 2700 облачных узлов в 130 точках входа.

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

  • Непосредственно VMware SD-WAN.

  • Cloud Access Service Broker (CASB), Secure Web Gateway (SWG) и удаленная изоляция браузера.

  • VMware NSX Stateful Layer 7 Firewall.

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

  • Edge Network Intelligence машинное обучение используется для предиктивного анализа и обеспечения безопасности как конечных пользователей, так и IoT-устройств.

Наряду с VMware SASE Platform стоит поговорить и о других инновациях компании.

VMware Workspace Security Remote

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

VMware NSX Advanced Threat Prevention

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

Также было анонсировано несколько новых решений из сетевого портфеля VMware:

  • VMware Container Networking with Antrea продукт для управления сетевым взаимодействием контейнеров в виртуальной среде.

  • NSX-T 3.1 расширение возможностей маршрутизации на базе API, автоматизированное развертывание процессов с помощью Terraform Provider.

  • VMware vRealize Network Insight 6.0 проверка и контроль качества сети на базе модели ее работы.

VMware Carbon Black Cloud Workload

Решение было анонсировано в виде планируемой технологии еще в прошлом году. Его задача обеспечение безопасности виртуальных машин на vSphere.

Кроме того, в VMware vCenter теперь будут встроенные инструменты для визуализации рисков, подобные тем, что уже есть в Carbon Black Cloud.

Также в планах компании представление отдельного модуля Carbon Black Cloud для защиты рабочих нагрузок Kubernetes.

VMware Workspace Security VDI

VMware Workspace ONE Horizon и VMware Carbon Black Cloud интегрированы в единое решение. Решение использует поведенческий анализ для защиты от вымогателей и бесфайловых вредоносов. В VMware vSphere оно доступно через VMware Tools. Больше нет необходимости устанавливать и настраивать агенты безопасности отдельно.

Приоритеты в мультиоблачности

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

Azure VMware Solution

Компания уже оставила заметный след в таких крупных публичных облаках, как AWS, Azure, Google Cloud, IBM Cloud и Oracle Cloud.

Azure VMware Solution позволит бизнесу сэкономить за счет гибридного использования Azure, интеграции с Microsoft Office 365 и других нативных сервисов Azure.

VMware Cloud on AWS

Новые возможности появились и в VMware Cloud on AWS. Среди них:

  • VMware Cloud Disaster Recovery.

  • Поддержка VMware Tanzu.

  • VMware Transit Connect.

  • Улучшения в области автоматизации: расширение поддержки vRealize Operations, Cloud Automation, Orchestrator, Log Insight and Network Insight support.

  • Расширенные возможности HCX: vMotion с поддержкой репликации, локальная маршрутизация для мигрированных ВМ, а также группировка миграция.

Project Monterey

Без сомнения, это один из самых интересных проектов VMware из числа анонсированных на VMworld 2020. Фактически, Project Monterey логическое продолжение технологии Project Pacific для инфраструктуры VMware Cloud Foundation, только теперь с акцентом на железо.

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

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

  • Унифицированные операции для всех типов ПО, включая bare-metal ОС.

  • Возможность изоляции приложений без уменьшения их производительности благодаря применению модели Zero-trust security.

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

VMware vRealize AI

Еще в 2018 году сообществу был представлен Project Magna. На минувшей конференции основной функционал проекта стал доступен в качестве VMware vRealize AI. Решение использует обучение с подкреплением для самонастройки производительности приложений. Оптимизация кэша чтения и записи в средах vSAN с помощью vRealize AI позволила на 50% повысить производительность операций ввода-вывода, включающих чтение и запись.

Inside the Tanzu Portfolio

С серьезными новостями покончено, и мы переходим к развлекательному контенту. В рамках сессии Inside the Tanzu Portfolio была продемонстрирована короткая романтическая комедия, включавшая кадры с актрисой Рене Зеллвегер. Эксперты VMware решили, что игровой формат позволит продемонстрировать новые возможности Tanzu и немного развлечет зрителей, подключившихся к конференции онлайн. Разумеется, воспринимать эту трансляцию на 100% серьезно не стоит это не академический материал, а простое объяснение портфеля решений, составляющих Tanzu.

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

Virtual Data Therapy PuppyFest

Компания Commvault, золотой партнер компании VMware, продемонстрировала полусерьезный ролик о защите данных под слоганом Dont let your data go to the dogs Не допустите, чтобы ваши данные пошли псу под хвост.

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

Что же в итоге?

VMworld 2020, без преувеличения, знаковое событие на технологической арене. Если бы оно не состоялось, это значило бы, что у нашего мира начались по-настоящему тяжелые дни. Но, как оптимистично заявляет Пэт Гелсингер, CEO VMware, игра продолжается. Новые трудности подстегивают нас на создание новых способов борьбы с ними. Жизнь идет своим чередом пандемия понемногу отступит, а багаж знаний и опыта, накопленный за месяцы изоляции, останется с нами и послужит надежным подспорьем для создания чего-то нового, крутого и интересного.

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


По традиции скажем: оставайтесь на связи и обязательно послушайте выпуски нашего подкаста IaaS без прикрас, посвященные VMworld 2020. На Яндекс Музыке, Anchor и YouTube доступны:

  • VMworld 2020: Генеральная сессия, мультиоблака и стратегия VMware

  • VMworld 2020: Стратегия безопасности, SD-WAN, SASE и будущее сетей

  • VMworld 2020: Kubernetes, Tanzu Portfolio и что нового в vSphere 7

Подробнее..

Перевод - recovery mode Прогнозы на 2021 год технологии и клиентоориентированность помогают бизнесу выйти из кризиса

03.12.2020 12:07:50 | Автор: admin


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

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

В этом году, когда аналитики компании подготовили 30 отчетов Forrester с прогнозами (требуется клиентский доступ), возникло четкое представление о молниеносном развитии технологий. 2021 год станет годом, когда каждая компания а не только те 15% фирм, что уже были подкованы цифровыми технологиям удвоит свой опыт, операции, продукты и новые экосистемы. Это однозначно означает, что должен настать момент инвестирования в некую новую технологию, не использованную ранее. Но покуда пандемия все еще реальна, а бюджеты на 2021 год повсеместно анализируются, важно досконально изучить и извлечь все преимущества и ценность технологии существующей и, наконец, израсходовать все неиспользованные возможности.

Итак, вот лишь некоторые из прогнозов Forrester на 2021 год:

1. В ЦЕЛОМ CIO БУДУТ ТРАТИТЬ МЕНЬШЕ ОБЧНОГО НО ОХОТНО ДОВЕРЯТСЯ ОБЛАЧНМ ПЛАТФОРМАМ ДЛЯ ПОВШЕНИЯ СКОРОСТИ И АДАПТИВНОСТИ


По прогнозам Forrester, после нескольких лет стремительного роста расходов на информационных технологии, в связи с пандемией COVID-19, в 2021 техноинвестиции в США упадут на 1,5% на 135 миллиардов долларов меньше пика расходов 2019 года. Вместе с тем ИТ-директора продолжат увеличивать расходы своих компаний на облачные технологии, безопасность и риски, сети и мобильность, в том числе испытывающие трудности фирмы, стремящиеся совершить скачок и получить преимущество, выходя из пандемии.

2. ДИРЕКТОРА ПО МАРКЕТИНГУ БУДУТ КОНТРОЛИРОВАТЬ ВЕСЬ ЖИЗНЕННЙ ЦИКЛ КЛИЕНТА


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

3. СТЕПЕНЬ РАСПРОСТРАНЕННОСТИ УДАЛЕННОЙ РАБОТ ВРАСТЕТ НА 300% ОТ УРОВНЯ ПРЕ-ПАНДЕМИИ


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

4. НОРМАТИВНО-ПРАВОВАЯ ДЕЯТЕЛЬНОСТЬ, СВЯЗАННАЯ С НАРУШЕНИЕМ КОНФИДЕНЦИАЛЬНОСТИ СОТРУДНИКОВ, УДВОИТСЯ


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

5. НЕ ДОВЕРЯЙ, ВСЕГДА ПРОВЕРЯЙ: АЗИАТСКО-ТИХООКЕАНСКИЙ РЕГИОН, НАКОНЕЦ, ПРИМЕТ КОНЦЕПЦИЮ ZERO TRUST


Принятие модели безопасности Zero Trust (прим. ред.: Zero Trust архитектурная модель под девизом Не доверяй, всегда проверяй, созданная Forrester в 2009 году для более интеллектуального и стратегического повышения уровня безопасности в организациях) в Азиатско-Тихоокеанском регионе отстает от мировых конкурентов, но стремительное ускорение внедрения облачных технологий и взрывной рост удаленной работы, а также изменение нормативных требований и поведения потребителей делают его готовым к изменениям. По крайней мере, одно правительство в Азиатско-Тихоокеанском регионе примет концепцию Zero Trust уже в 2021 году.

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

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

В борьбе синих и красных победа присуждается радужным! Или все-таки не присуждается? Ну противостояние-то хоть было?

20.12.2020 16:19:50 | Автор: admin


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

На протяжении месяца мы с вами являемся свидетелями всевозможных Benchmark тестов, обсуждений, прогнозов, а порою и откровенных срачей между сектами последователей/хейтеров упомянутых выше корпораций. Особой пикантности ситуации предает тот факт, что в этот раз Apple смогла задеть не только чувства верующих от Intel, Apple и AMD, к разборкам также подключились еще два не менее буйных лагеря свидетелей архитектуры ARM/x86. Ведь основным мотивом отказа от использования в своих МасBook продукции синих стала не банальная интрижка на стороне у красных, а радикальный уход процессоров М1 на совершенно отличную от х86 архитектуру ARM, что само по себе уже чревато самыми интересными последствиями.

Так все таки кто кого? Кто на коне, а кого ждет скорое забвение? Станет ли Apple законодателем моды на ARM процессоры в полноценных рабочих станциях со своим all-in в процесорную систему Apple Silicon, или мир еще не готов к столь радикальным переменам? О всем этом и не только пойдет далее речь в статье.

Легкая предыстория


Забегая немного вперед можно констатировать, что действительно наибольшее число революций в разработке и производстве процессоров произошло в 60-70х годах ХХ столетия. Первый центральный процессор в нашем современном их понимании Intel 4004, впервые объединивший в себе возможность исполнять логический и арифметические функции, первый 8-битный процессор Intel 8006, который в том числе, впервые, дал возможность пользователям ЭВМ работать с буквенной кодировкой, и конечно же легендарный Intel 8086 разработанная под него архитектура набора команд дала название архитектуре х86, на база которой и сегодня выпускают свои прорывные решения Intel и AMD. Да собственно и сами вышеупомянутые компании, с их противостоянием, также берут свое начало из конца 60-х, как ушедшие в свободный полет птенцы из общего гнезда одного из основателей кремневой долины Fairchild Semiconductor International Inc.


Вероломная восьмерка в скором будущем присутствующие здесь люди создадут Intel и AMD

Несколько иной от х86 подход к набору команд внутри центрального процессора породил архитектуру ARM, однако и она не является достижение последних десятилетий. Первые рабочие станции на ARM увидели свет в первой половине 80-х. Архитектура, с первых лет своего существования, зарекомендовала себя как крайне эффективная, ответить же на вопрос: Почему мы увидели полноценную рабочую станцию от Apple на ARM только сейчас? довольно сложно. Во-первых полноценным компьютером на базе ARM процессора стал ПК из семейства Acorn Archimedes еще в далеком 1987 году, а во-вторых станет ли новинка от Apple действительно эффективным решением, в отличии от своих ARM предшественников, это все еще уравнение с целым рядом неизвестных.

AMD и Intel: враги, конкуренты, или вовсе партнеры?


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



С первых дней своего существования Intel и AMD шли рука об руку и скорее дополняли друг друга нежели соперничали. Подписав с Intel крос-лицензионное соглашение на использование взаимных патентов, представленный в 1975 году процессор от команды AMD Am9080, был точной копией Intel 8086. По сути и все дальнейшее развитие собственной процессорной продукции у коллектива AMD всегда попадало в фарватер Intel. Улучался тех процесс, усовершенствовался набор команд, вводились изменения в компоновку железной составной, однако в принципиальных вопросах построения самой архитектуры процессора никаких разногласий у конкурирующих флагманов ИТ-рынка никогда не возникало. Давайте лишь вспомним, что кроме широко известных сейчас архитектур под х86 и ARM CISC и RISC, существуют VLIW, EPIC, SIMD, MIMD и многие другие. Разбор особенностей всех этих архитектур, и споры об их реальной эффективности это тема для отдельной дискуссии но тот факт, что ни Intel ни AMD до их пор не представили сколько либо конкурентного решения на базе процессоров ARM, уже сейчас завоевавших абсолютное лидерство на рынке носимой электроники, вызывает откровенное недоумение. Недоумение, если воспринимать двух вышеупомянутых ИТ-гигантов как действительно конкурентов.

Общее прошлое, взаимовыгодная работа на развитие и продвижение х86 совместимой архитектуры синими и красными точно также как и интеграции их продукции со сторонними производителями железа и программного продукта весьма показательны. К всему вышеупомянутому стоит еще добавить и о прямых финансовых вливаниях Intel в стан смертельного конкурента. В 2009 году, после длительных судовых разбирательств, по результатам решения антимонопольной комиссии ЕС, Intel без лишних сожалений, согласился выплатить AMD компенсацию в размере 1,25 миллиарда долларов. Можно долго спорить на сколько сильно синие провинились перед свободным рынком и персонально AMD занимаясь демпингом ( к слову о дороговизне решений от Intel ), и незаконно использовали некоторые патенты красных, однако феноменальная сумма выплаченная компании в период ее не самых лучших времен говорит о многом.


Котировки акций AMD на фондовой бирже по годам. До триумфального появления Ryzen еще долгих 7 лет, а жить-то как-то надо сейчас

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

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

АRM М1 от Apple не первая ласточка


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

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


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

История с производством, в начале 90-х, ПК на базе ARM процессоров Acorn Archimedes показало, что многомиллиардный бизнес это не только разговор о фактической продуктивности систем для конечного потребителя. Инстинкт самосохранения у существующих производителей однозначно победил, вследствие чего Intel с AMD и далее продолжили развивать свою архитектуру, а ARM процессорам пришлось перекачивать на слаборазвитый, малобюджетный, не слишком перспективный ( в те далекие времена ) рынок портативной электроники. В тоже время для Intel и AMD стало очевидным, что набор исполнительных инструкций используемый для функционирования их архитектуры х86, в большинстве реальных задач, проигрывает набору инструкций RISC, применяемый в ARM процессорах, и он должен быть модернизирован в сторону конкурента. По истечению 30 лет работы над ошибками два ИТ-гиганта смогли добиться результата при котором оставшись формально правообладателями и единственными производителями процессоров х86, фактически, оптимизировали исполнение инструкций внутри процессора по образу и подобию конкурента на RISC.

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


А в это время на просторах СНГ все еще дрались за шанс половить яйца на Электроника ИМ-02

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

Первой и самой главной проблемой первых ПК на базе всевозможных процессорных архитектур, на заре становления цифровой эры, являлась слабая программная поддержка. Простыми словами вы могли создать самый прелестный процессор с самой совершенной архитектурой, однако не имея за собой огромных капиталовложений в разработку и продвижение ПО на базе вашего продукта вы были обречены на забвение. Собственно это и случилось с Acorn Archimedes в 90-х. Тем более, что как конкурент х86 в конце концов была не так уж и плоха.

Имея солидный бюджет, а что еще не менее важно колоссальный опыт в разработке ПО, Microsoft решил, что в 2012 году мир готов к новым ПК. Имея за плечами опыт разработки ПО под мобильные ARM решения Windows Mobile, со всеми его потомками Windows Phone вплоть до Windows 10 Mobile, Surface так и не смог завоевать хоть сколько-либо видимой доли рынка. Попытки создать единую программную платформу для носимых гаджетов и ПК, покупка в 2011 году за 8,5 миллиардов долларов Skype, кооперация, а потом и покупка в 2014 году за 6 миллиардов долларов Nokia, сложно рассчитываемые инвестиции в сопутствующие сервисы типа OneDrive увенчались полнейшим фиаско Мелкомягких. Почему все эти титанические усилия оказался провальными вопрос довольно спорный. С одной стороны сумасшедшая инерция архитектуры х86, плюс посредственная производительность встраиваемых в Surface процессоров NVIDIA Tegra 3, в то время как автономность гаджета возрасла весьма незначительно, если сравнивать с конкурентами от Intel. С другой стороны был выбран не слишком удачный/новый процессор под систему, да и по отзывам пользователей откровенно плохая оптимизация ПО под железо превращала работу с ним в перманентное мучение, очевидно это был сырой продукт.


А ведь идея была хорошая

Apple третий переход


Объявленная на крайней презентации Apple революция, с переходом MacBook на процессоры новой архитектуры, для корпорации стала действительно революцией, хотя и не первой. Даже тот факт, что в Купертино уже более 10 лет используют ARM архитектуру в процессорах для своих мобильных устройствах не умиляет размера события. Почему для радужных это действительно революция становится понятным если взглянуть на ту модель бизнеса которую исповедуют радужные. Apple это не про гаражные поделки на коленке, компания реализует комплексные решения на базе собственной экосистемы. Если в 1994 году уход от процессоров IBM на новую перспективную архитектуру PowerPC был еще достаточно рядовым событием, не столь травмирующим приверженцев бренда, то в 2005 году выбор в пользу процессоров от Intel стал уже настоящим вызовом и проверкой на прочность самой компании. Смягчить переход помог разработанный в строжайшей секретности программный комплекс Rosetta по сути динамический транслятор бинарного кода, позволяющий на лету преобразовывать код приложений PowerPC для работы под Intel. Это решение позволило адаптировать и легко использовать программы изначально не совместимые с новой системой.


Гладко было на бумаге, да забыли про овраги

Озвученный третий переход на новую ARM архитектуру в нынешнем 2020 году очевидно станет еще тем квестом, в чем уверен мы с вами еще не раз убедимся, однако встроенный в новую ОС эмулятор Rosseta 2, в теории, должен решить большинство проблем связанных с использованием не адаптированного ПО под новые радужные процессоры. Хотя позитивный опыт предыдущего перехода и вселяет оптимизм, однако уже сейчас понятно, что новым процессорам M1 ближайший год-два придется вывозить на себе все тягости и лишения переходного периода пока App store не обзаведется достойным набором приложений под новую архитектуру.

Выводы


Презентация новых процессоров от Apple, это однозначно то не многое из позитива который принес нам незабвенный 2020 год. Возможно еще не все оценили масштаб данного события, однако со временем его размер будет становится все более очевидным. Фактически в 2020 году мы получили третьего полноценного игрока на рынке высокопродуктивной процессорной техники, который неоднократно показывал присутствие необходимых знаний и умений добиваться успеха в поставленных задачах. Ближайшие несколько лет станут несомненно решающими не только для Apple, с их ва-банком на ARM, но и явно подпортят кровь так крепко обосновавшимся на ниве производства процессоров компаниям Intel и AMD.

Уже сейчас мы видим как MacBook с номинально более производительным и энергоэффективным М1 стоит дешевле идентичного аппарата на процесcоре Intel i5. Неужели на смену внутрикланновой конкуренции наконец-то придет настоящая борьба за клиента? Клиента у которого наконец-то появится альтернатива застойным тик-так-так-так инновационным процессорам из 2014 года от Intel и изделиям от их заграничного филиала AMD с порою откровенно сырыми, не оптимизированными продуктами. Я уверен не мало профессиональных комментаторов с легкостью расставят точки над I в этой не такой уж простой, как казалось бы на первый взгляд, теме. Всем же остальным предлагаю запастись попкорном и наблюдать за тем куда нас приведет кривая дорога технического прогресса.



Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

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

09.03.2021 18:08:33 | Автор: admin

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

Я Хамзет Шогенов, архитектор облачной платформы Mail.ru Cloud Solutions, расскажу о системах хранения данных, доступных на нашей платформе, подробно остановлюсь на их технических характеристиках и оптимальных вариантах использования.

Типы дисков, которые вы можете использовать в облаке

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

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

Особенности облачных (блочных) дисков:

  1. Есть определенная гарантированная производительность в единицу времени на единицу объема хранения данных, выражаемая в операциях на диске в секунду (IOPS, пропускная способность).

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

  3. Возможность создания снапшотов и образов (шаблонов) дисков.

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

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

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

Отличия облачных (блочных) дисков от других облачных систем хранения данных:

  • Масштабирование производится вручную.

  • Уменьшение размера существующего диска недоступно: потребуется пересоздание.

  • Доступ возможен из любой зоны доступности (AZ), но ресурс локализован в одной AZ. Размещение диска и виртуальной машины в разных ЦОДах не рекомендуется, хотя это и возможно.

  • Непригодны для одновременного доступа при работе как с блочным устройством.

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

На нашей платформе поддерживаются несколько типов дисков: HDD, SSD, SSD High IOPS и Low Latency NVMe. Вначале рассмотрим характеристики, которые будут общими для всех дисков, затем остановимся более подробно на каждом из них.

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

Общие характеристики для всех типов облачных дисков

  1. Capacity. Рекомендуемый максимальный размер диска 2 Тб.

  2. Масштабирование. Вручную через веб-консоль управления облаком или OpenStack CLI (Command Line Interface). Возможно только увеличение размера диска. Уменьшение недоступно, так как подобная процедура может негативно сказаться на работе файловой системы и целостности данных.

  3. Доступность. Гарантируется SLA, общий для облака, 99,95%.

  4. Бэкапы и восстановление. Для всех дисков поддерживаются снапшоты и резервные копии. Создание снапшотов доступно через консоль управления облаком и OpenStack CLI. Создание бэкапов возможно через встроенный механизм MCS либо с использованием сторонних решений наших партнеров: Acronis и VMware Backup & Replication. Встроенный механизм хорош интеграцией с облачной платформой, сохранением бэкапов в S3, что дешевле, и платой только за хранение данных. Однако в этом случае нет возможности восстановления данных в ту же виртуальную машину и восстановления отдельных файлов.

  5. Границы доступности. Ресурс локализован в рамках одной зоны доступности (AZ, Availability Zone). Чтобы избежать потенциального снижения производительности работы, при создании диска, подключаемого к существующему инстансу, рекомендуется выбирать зону доступности инстанса.

  6. Безопасность. Доступ к данным ограничен механизмами изоляции ресурсов (различные Namespace) проекта.

  7. Механизм расчета стоимости. Цена определяется запрошенным объемом диска. При изменении размера стоимость автоматически пересчитывается.

Диски HDD

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

Характеристики, специфичные для HDD

Показатель

Значение

IOPS (количество операций в секунду на 2 Тб пространства)

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

Throughput (пропускная способность на 2 Тб пространства при размере блока 1М)

Показатель SLA для чтения 250 Мб/с, для записи 100 Мб/с.

Поведение при выходе физического оборудования из строя

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

Диски SSD

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

Характеристики, специфичные для SSD

Показатель

Значение

IOPS (количество операций в секунду на 2 Тб пространства)

Показатель SLA для чтения 100016 000, для записи 500-8000.

Throughput (пропускная способность на 2 Тб пространства, при размере блока 1М)

Показатель SLA для чтения и записи 400 Мб/с.

Поведение при выходе физического оборудования из строя

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

Диски High IOPS SSD

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

Характеристики, специфичные для High IOPS SSD

Показатель

Значение

IOPS (количество операций в секунду на 2 Тб пространства)

Показатель SLA для чтения 10 00045 000, для записи 500030 000.

Throughput (пропускная способность на 2 Тб пространства, при размере блока 1М)

Показатель SLA для чтения и записи 500 Мб/с.

Поведение при выходе физического оборудования из строя

Может случиться временная недоступность данных, сами данные не теряются. Необходимо дополнительно позаботиться о реализации отказоустойчивости на уровне приложения (application-aware). С лучшими практиками по созданию отказоустойчивых приложений можно ознакомиться по ссылке.

Low Latency NVMe

Сверхбыстрые диски с минимальными задержками, доступные на высокочастотных конфигурациях ВМ. Самые производительные и дорогие. Этому классу хранения соответствуют физические диски NVMe. Используются там, где важно обеспечить минимальные задержки: высокопроизводительные СУБД, аналитика, кэш.

Характеристики, специфичные для Low Latency NVMe

Показатель

Значение

IOPS (количество операций в секунду на 2 Тб пространства)

Показатель SLA для чтения 10 00075 000, для записи 5000-50 000.

Throughput (пропускная способность на 2 Тб пространства, при размере блока 1М)

Показатель SLA для чтения 1200 Мб/с, для записи 900 Мб/с.

Latency (задержка)

SLA максимум 0,5 мс. Устойчивы к отказу сети, виртуальная машина с такими дисками максимально близка к bare metal.

Поведение при выходе физического оборудования из строя

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

Объектные хранилища S3 еще один тип хранения данных в облаке

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

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

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

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

  1. S3 HotBox предназначен для хранения горячих данных с частым доступом. В первую очередь это онлайн-сервисы с повышенной нагрузкой, работа которых требует хранения и раздачи контента: потоковая раздача мультимедиа, хостинг статических сайтов, хранилища для Backend-платформ. Могут также использоваться для анализа данных в Big Data, Data Mining и так далее. В HotBox хранение дороже, а исходящий трафик дешевле, входящий трафик не тарифицируется.

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

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

Что хорошего в S3-хранилище:

  • Неограниченный объем хранимых данных (петабайты).

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

  • Разграничение доступа за счет ACL и префиксных ключей.

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

  • Стабильная скорость раздачи любых объектов независимо от числа одновременных обращений.

  • Автоматическое и виртуально неограниченное масштабирование.

  • Возможность настройки Webhooks для автоматической обработки при создании/удалении объектов (например, автообработка фото и видео).

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

  • У S3 нет понятия зоны доступности: это глобальный сервис. Его доступность обеспечивается из пяти ЦОД MCS.

  • Наименьшая стоимость среди всех типов облачных хранилищ.

Основное отличие S3-хранилища от других облачных (блочных) систем хранения блочные хранилища предназначены для использования виртуальными машинами и представляются как диски, а объектное хранилище доступно только по HTTP.

Основные особенности S3

  1. Capacity. Нет ограничений на общий объем можно хранить петабайты данных. В одном хранилище может быть до 25 бакетов, размер одного бакета произвольный. Число объектов в одном бакете не ограничено свыше 1 млрд. Для конкретных объектов действуют следующие рейт-лимиты: 32 ГБ для обычного файла, 320 ТБ для multipart.

  2. IOPS (количество операций в секунду). Действуют следующие рейт-лимиты: для обычных запросов 500 запросов в секунду, 10 млн запросов в день, для запросов на листинг 15 запросов в секунду, 10 млн запросов в день.

  3. Throughput (пропускная способность). Поддерживается скорость передачи объектов 1 Гбит/с. Для быстрой доставки контента хранилище S3 можно интегрировать с сетью доставки контента (CDN, Content Delivery Network), имеющей более 400 точек присутствия во всем мире и емкость канала 1,5 ТБит/с.

  4. Масштабирование. Размер S3 не ограничен. Масштабирование происходит вверх и вниз автоматически, без дополнительных настроек со стороны пользователя.

  5. Доступность. Гарантируется SLA, общий для облака 99,95%. Надежность хранения при этом составляет 99,99999%.

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

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

  8. Границы доступности. Возможен доступ из всех зон доступности региона, а также из любого места в интернете с использованием URL объектов.

  9. Протоколы доступа. S3 API. Главная особенность решения от MCS полная совместимость с API S3.

  10. Безопасность. Обеспечивается за счет списков управления доступом (ACL, Access Control Lists) и префиксных ключей. На уровне каждого бакета можно определять, кто может создавать, удалять и перечислять объекты в нем. При организации внешнего доступа вне облака можно использовать HTTPS.

  11. Механизм расчета стоимости. Оплачивается за фактически использованные ресурсы и рассчитывается посекундно. Тарифный план зависит от типа выбранного хранилища: HotBox, IceBox или Glacier.

Файловые хранилища в облаке

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

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

Преимущества файловых хранилищ:

  • Есть возможность как увеличения, так и уменьшения размера хранилища.

  • Есть возможность создания снапшотов.

  • Оптимальный вариант хранения для Legacy-приложений, требующих протокола SMB/NFS.

  • Поддерживаются большим количеством классических систем.

Недостатки файловых хранилищ:

  • Масштабирование производится вручную.

  • Одновременный доступ ограничен полосой пропускания стандартного сетевого интерфейса.

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

Основные характеристики файловых хранилищ

  1. Capacity. Рекомендуемый максимальный размер хранилища 2 Тб. Максимальный размер файла не больше запрошенного размера хранилища.

  2. IOPS (количество операций в секунду на 2 Тб пространства). Так как файловое хранилище базируется на дисках HDD, показатель SLA будет тем же: для чтения 3002400, для записи 150800.

  3. Throughput (пропускная способность на 2 Тб пространства, при размере блока 1М). Аналогично, как для HDD: для чтения 250 Мб/с, для записи 100 Мб/с.

  4. Масштабирование. Проводится вручную через web-консоль управления облаком или OpenStack CLI (Command Line Interface). В отличие от облачных дисков возможно как увеличение, так и уменьшение размера файлового хранилища.

  5. Доступность. Гарантируется SLA, общий для облака, 99,95%.

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

  7. Бэкапы и восстановление. Возможно создание снапшотов, бэкапирование из веб-консоли недоступно. Механизмы те же, что и для облачных дисков.

  8. Границы доступности. Доступ осуществим из сетей, которые имеют возможность маршрутизации IP-пакетов с сетью, где размещено файловое хранилище.

  9. Протоколы доступа. Подключить файловое хранилище к инстансам проекта можно по протоколам CIFS (SMB v3) или NFS.

  10. Безопасность. Доступ к файловым хранилищам осуществляется только из виртуальных машин внутри проекта (Namespace) MCS. При этом дается возможность настроить правила доступа к хранилищу в зависимости от IP клиента.

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

Как выбрать облачную систему хранения с учетом потребностей компании: основные критерии

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

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

При выборе S3 необходимо дополнительно определить частоту доступа к данным и выбрать соответствующий тип хранилища: HotBox, IceBox или Glacier.

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

В порядке возрастания производительности диски можно расположить следующим образом: HDD, SSD, SSD High IOPS, Low Latency NVMe. Если требуется обеспечить минимальную задержку, Low Latency NVMe будет лучшим выбором, так как для этого типа диска определено SLA на данный показатель 0,5 мс.

Методы доступа к данным, используемые в классических приложениях (в первую очередь протоколы доступа, так как контроль над интерфейсами напрямую заказчику недоступен). Очень часто при переносе Legacy-приложений клиентов в облако требуется обеспечить конкретные, уже используемые ими протоколы. Конечно, обновление систем возможно, но, как правило, требует дополнительных затрат. В таких случаях выбор облачного хранилища полностью зависит от требований переносимого ПО. Например, файловые хранилища чаще всего выбирают, когда необходимы протоколы SMB/NFS. И это стало в свое время основной причиной того, почему у нас появилось файловое хранилище как сервис.

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

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

Для файловых хранилищ и обычных дисков цена определяется запрошенным объемом ресурсов. При этом цена дисков возрастает по мере увеличения их производительности: HDD, SSD, SSD High IOPS, Low Latency NVMe. Рекомендуем выбирать тот тип диска, который при достаточной для вас производительности будет дешевле всего, так как в дальнейшем при необходимости его можно будет изменить на лету.

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

Упрощенная схема выбора облачного хранилища

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

Система хранения данных

Типичные сценарии использования

S3 Glacier

Массивные данные (от 100 Тб) с очень редким доступом: бэкапы, архивы, журналы, системные сообщения, логи.

S3 IceBox

Данные с редким доступом: архивы корпоративных файлов, годовая/месячная отчетность, документы маленьких рабочих групп, бэкапы, системные сообщения, lоg-файлы.

S3 HotBox

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

Файловое хранилище

Файловые хранилища, воссоздание схемы Legacy-приложения, общее персистентное хранилище данных для групп контейнеров.

HDD

Файловые хранилища, загрузочные разделы.

SSD

СУБД, телеметрия, очереди сообщений, загрузочные разделы.

SSD High IOPS

СУБД, аналитика, телеметрия. С большими требованиями к производительности, чем у SSD, но меньшими, чем у Low Latency NVMe.

Low Latency NVMe

Высокопроизводительные СУБД, аналитика, кэш.

Расчет необходимой производительности облачной системы хранения при переносе Legacy-приложений

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

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

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

  2. Настройте и запустите процесс снятия метрик на исходном сервере:

    • количество потребляемых ядер;

    • потребляемая частота CPU;

    • количество операций ввода/вывода в секунду;

    • задержки чтения/записи на дисках;

    • эффективность использования ОЗУ.

  3. Подготовьте синтетические данные для нагрузочного тестирования.

  4. Создайте тестовый стенд, выделив на нем минимальное достаточное количество ресурсов в соответствии с расчетами. Расчеты стоит осуществлять с учетом фактического потребления ресурсов в часы наиболее высокой нагрузки. Далее, используя показатели из SLA MCS, пересчитать на ресурсы MCS.

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

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

  7. При успешном тестировании можно производить миграцию и начинать промышленную эксплуатацию.

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

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

Например, возможна следующая комбинация блочных дисков: для ОС использовать HDD, СУБД построить с использованием SSD High IOPS, а для кэша взять Low Latency NVMe. S3 в такую схему можно подключить для размещения медиаконтента (картинок и видео) с возможностью внешнего доступа или для хранения резервных копий.

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

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

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

Вариант комбинации облачных дисков на примере построения инфраструктуры для интернет-магазина с использованием кластера Kubernetes и хранилища S3

Итоговое сравнение облачных систем хранения данных

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

Показатель/Система хранения данных

HDD

SSD

SSD High IOPS

Low Latency NVMe

Файловое хранилище

S3

Тип хранилища

Блочное

Блочное

Блочное

Блочное

Файловое

Объектное

Размер хранилища

Рекомендуемый размер 2 Тб

Рекомендуемый размер 2 Тб

Рекомендуемый размер 2 Тб

Рекомендуемый размер 2 Тб

Рекомендуемый размер 2 Тб

Не ограничен

Максимальный размер файла

Размер диска

Размер диска

Размер диска

Размер диска

Размер хранилища

32 ГБ для обычного файла, 320 ТБ для multipart

IOPS read SLA(на 2 Тб пространства)

300 2400

1 000 16 000

10 000 45 000

10 000 75 000

300 2400

Действуют рейт-лимиты: для обычных запросов 500 запросов/с, 10 000 000 запросов/день для запросов на листинг 15 запросов/с, 10 000 000 запросов/день

IOPS write SLA(на 2 Тб пространства)

150 800

500 8000

5000 30 000

5000 50 000

150 800

Latency SLA

Не предусмотрен SLA

Не предусмотрен SLA

Не предусмотрен SLA

Максимум 0,5 мс

Не предусмотрен SLA

Не предусмотрен SLA

Throughput read SLA(на 2 Тб пространства и размер блока 1 М)

250 Мб/c

400 Мб/c

500 Мб/c

1200 Мб/c

250 Мб/c

Обеспечивается скорость до 1 ГБит/c. При интеграции с CDN: 1,5 ТБит/с

Throughput write SLA(на 2 Тб пространства и размер блока 1 М)

100 Мб/c

400 Мб/c

500 Мб/c

900 Мб/c

100 Мб/c

Масштабирование

Вручную за счет увеличения размера диска

Вручную за счет увеличения размера диска

Вручную за счет увеличения размера диска

Вручную за счет увеличения размера диска

Вручную за счет увеличения/уменьшения размера хранилища

Виртуально не ограничена

Доступность:

  • SLA

  • Поведение при выходе физического оборудования из строя

99,95%

99,95%

99,95%

99,95%

99,95%

99,95%Надежность хранения 99,99999%

Без прерывания обслуживания, данные не теряются (за счет двойных и тройных репликаций)

Без прерывания обслуживания, данные не теряются (за счет двойных и тройных репликаций)

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

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

Сервис доступен при выходе из строя оборудования, но выход его компонентов из строя ведет к прерыванию сервиса

Без прерывания обслуживания, данные не теряются

Бэкапы и восстановление

Резервные копии, снапшоты

Резервные копии, снапшоты

Резервные копии, снапшоты

Резервные копии, снапшоты

Снапшоты

Георепликация данных, в планах версионность объектов

Границы доступности

Из любой AZ, но ресурс локализован в одной AZ

Из любой AZ, но ресурс локализован в одной AZ

Из любой AZ, но ресурс локализован в одной AZ

Из любой AZ, но ресурс локализован в одной AZ

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

MultiAZ, глобальный

Протоколы доступа

Неприменимо

Неприменимо

Неприменимо

Неприменимо

Ethernet, SMB/NFS

S3 API

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

Доступ ограничивается namespace проекта

Доступ ограничивается namespace проекта

Доступ ограничивается namespace проекта

Доступ ограничивается namespace проекта

Доступ ограничивается namespace проекта, можно настроить доступ по IP клиента

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

Ценообразование

За выделенные ресурсы

За выделенные ресурсы

За выделенные ресурсы

За выделенные ресурсы

За выделенные ресурсы

За фактически использованные ресурсы

Что еще почитать по теме:

  1. Работа с объектным S3-хранилищем Mail.ru Cloud Solutions как с файловой системой.

  2. Принципы организации объектных хранилищ.

  3. Все обновления облачных хранилищ и другие новости наших облачных сервисов в нашем телеграм-канале.

Подробнее..

Уроки Symbian OS фиаско топ менеджеров, колосс на глиняных ногах, или неотвратимость бытия?

11.04.2021 10:22:11 | Автор: admin


Страшно представить как летит время, но 1 января 2021 года стало уже 7 с того момента, когда корпорация Nokia прекратила поддержку Symbian OS. В 2014 году разработчики ОС окончательно поставили крест на еще недавнем монополисте в сегменте мобильных операционных систем. Как такое вообще возможно? Всего за 2-3 года из абсолютного лидера превратится в безусловного аутсайдера полностью утратив рынок новых девайсов и еще через пару лет стать официально похороненной платформой.

Как-то полемизируя с коллегой о жизненном цикле ПО прозвучала фраза, что как и любой живой организм программы также имеют свои стадии рождения, становления и конечно же смерти. Более того, развивая свою мысль мой оппонент утверждал, что благодаря интенсификации технологического прогресса, с каждым новым десятилетием этот жизненный цикл программных продуктов сокращается. При некоторой очевидной схожести процессов протекающих в цифровом мире и мире живой природы, все же на сколько корректно такое сравнение? По сути, если оценить статистику распространенности ИТ-сервисов в мире, за последние лет 30, можно констатировать, что мы с вами стали свидетелями грандиозных, по своим масштабам, взлетов и падений. То, о чем 20 лет назад можно было услышать лишь в курилках кремневой долины, через 10 лет покоряет мир. То, что еще 10 лет назад казалось вечным и непоколебимым сейчас валяется в руинах. Если мой коллега действительно прав в своих аналогиях, в каком мире мы окажемся через 10 лет? Реальность где OS Android скатилась к околонулевой доле рынка, а ее официальная поддержка прекратилась и осуществляется сообществом маргиналов-олдфагов, а корпорация Apple тем временем продала свое мобильное подразделение и занялась выпуском микроволновок.

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

Детство Symbian


Хотя Symbian OS долгое время ассоциировалась с телекоммуникационным гигантом Nokia, а в конце своего жизненного пути и вообще стала его частью, сама платформа уходит корнями в далекие 80-е. Именно в 1980 году, в Британии, была создана компания Psion PLC, которой в недалеком будущем будет суждено поучаствовать в развитии зарождающегося направления мировой ИТ-индустрии персональные цифровые ассистенты, или в более привычной для нас с вами интерпретации носимая электроника. Начав с разработки программного обеспечения для существующих ЭВМ, вскоре компания начала выпускать и собственные девайсы. Имея уже определенный опыт разработки ПО на начальных этапах это были игры и офисные приложения, руководство Psion решило, что для следующего шага в развитии компании необходимо создавать собственную операционную систему. С конца 80-х в Psion началась интенсивная работа над созданием программой платформы SIBO ( SIxteen Bit Organiser ), и соответственно на ее базе OS EPOC. Менее чем через 10 лет после этих событий в 1998 году, мир узнал о создании Symbian OS, а фактически состоялся ребрендинг уже успешно существующего продукта OS EPOC32. Во времена всеобщего хаоса стандартов, огромного количества локальных производителей оборудования и ПО, именно творению Psion PLC ( точнее ее дочерней компании Symbian Ltd. ) будет суждено захватить мир носимых гаджетов, но почему?


Одно из наиболее удачных решений от британской компании Psion Series 5. Именно на этом КПК ковалось будущее самой популярной ОС среди смартфонов нулевых

Естественно, толчком для массового внедрения в наши с вами гаджеты Symbian послужило решение о кооперации компаний Ericsson, Nokia, Motorola наиболее крупных производителей портативной электроники в середине 90-х. Причин по которым выбор производителей пал на малоизвестную Британскую компанию сразу несколько и они весьма существенны. Прежде всего Symbian был разработан под ARM совместимую микропроцессорную архитектуру ( архитектура разработанная, между прочим, также Британской компанией ARM Limited ), благодаря новым процессорам стало возможным создавать энергоэффективные, компактные процессоры так сильно востребованные в носимой электронике. Также немаловажным фактором было, что во всем хаосе существующих тогда ОС, фактически не существовало абсолютно удовлетворяющих заказчиков программных решений для только-только зарождающегося форм-фактора портативных гаджетов и соответсвенно компании так или иначе столкнулись бы с необходимостью глубокой доработки имеющихся платформ. Третий фактор касается существующих ОС. Состоянием на 1998 год уже существовала мобильная платформа Windows CE, и она вполне могла бы удовлетворить двум предыдущим пунктам, однако пребывая в статусе абсолютного монополиста, в сфере создания и распространения ПО, Microsoft выдвинул столь кабальные требования по лицензионному соглашению к будущим партнерам, что гиганты производства телекоммуникационного оборудования просто вынуждены были отказаться от сотрудничества с Microsoft. Не так давно Билл Гейтс сознался журналистам, что допущенные 20 лет назад ошибки в продвижении его мобильной операционной системы Windows Mobile, породили гегемонию Android OS и стоили ему $400 миллиардов недополученной прибыли. Ну и конечно решающей причиной в появлении Symbian стали размеры самих компаний Ericsson, Nokia, Motorola. Данный конгломерат банально мог себе позволить вкладывать огромные ресурсы в перспективное направление разработки собственной ОС, и тут малоизвестная но перспективная Psion PLC подошла как нельзя лучше.


Ericsson R380 хотя и был первым смартфоном под управлением Symbian, пальма первенства среди смартфонов, еще с 1992 года, принадлежит IBM Simon

Хотя OS EPOC32 и появилась еще в 1994, первый смартфон под управлением ее производной Symbian OS, увидел мир только в ноябре 2000 года. Это был Ericsson R380. Система оказалась весьма удачной. По сути, Symbian являлась гибридом вычислительной архитектуры общего назначения и набором компонентов необходимых для функционирования смартфона. В ядре ОС были реализованы все современные на тот момент функции, от управления памятью и поддержки многозадачности, до промежуточного ПО позволяющего работать с мобильными сетями, графикой, поддерживать интернет протоколы, пользовательский интерфейс, управление телефонными вызовами и многое другое без чего и сейчас сложно представить полноценный смартфон. Также платформа позволяла использовать приложения на основе языков программирования Java и C++, являющиеся весьма прорывными для своего времени.



Становление


Хотя исходный код своей платформы Symbian Ltd. откроет аж в 2010 году, что по мнению многих экспертов отрасли стало слишком запоздалым решением, в начале нулевых закрытое ПО было вполне обыденным делом. В то время рынок создания программ сторонними разработчиками был крайне ограничен, и скорее нес больше рисков для конечного потребителя нежели преимуществ. Кроме того, при формальной закрытости платформы, количество партнеров принимающих участие в жизни Symbian было весьма внушительным. В разные годы в проект были вовлечены, кроме уже озвученных, еще и Samsung, Sharp, Fujitsu, LG, Sony, Panasonic, а также целый ряд более мелких компаний, что позволяло постоянно развивать и усовершенствовать перспективную платформу.



Все это вроде как звучит прекрасно, но если посмотреть более детально на сложившуюся картину, мы увидем довольно парадоксальную действительность. Все вышеназванные кампании если и были в чем-то партерами, то исключительно ситуационными, на прилавках магазинов все они чрезвычайно остро конкурировали друг с другом. В погоне за индивидуальностью, почти сразу, производители гаджетов причастных к Symbian Ltd. начали создавать свои собственные оболочки, что поддерживались телефонами с Symbian OS. В то время как Японские производители внедряли MOAP ( Mobile Oriented Applications Platform ), Финский производитель Nokia продвигал собственную линейку Series 60/80/90, Sony Ericsson и Motorola отдавали предпочтение UIQ (User Interface Quartz). Подобное положение вещей хотя и было весьма удобным, подарив унифицированную программную платформу с возможностью ее поверхностной кастомизации, в тоже время заложило мину замедленного действия под всей ОС. Поскольку собственные программные доработки компаний не могли носить фундаментальный характер и все равно базировались на Symbian, особенно важным было принимать решения по ее непосредственному развитию, а заниматься подобными вещами в купе с заядлыми конкурентами по цеху весьма непростое занятие. Ведь у каждой компании было свое виденье рынка и необходимого направления развития для ОС.



Еще одной сильной стороной Symbian являлось то, что используемый под нее программный интерфейс основывался на С++, что в свою очередь позволяло создавать под платформу современные, функциональные приложения. Чего уже говорить об играх написаных на Java, в том числе благодаря которым смартфоны так плотно вошли в нашу жизнь. И все бы было очень радужно, если бы не еще один нюанс. Унаследовав из 80-х от EPOC специфическую структуру оболочки, Symbian OS была довольно требовательна к квалификации программистов писавшим под нее ПО. Вместо поиска решений проблемы упростить разработку, в 2004 году руководство Symbian, в погоне за безопасностью разрабатываемых под ОС приложений еще больше усложнила жизнь разработчикам. Под благим предлогом борьбы с вирусами, спамом и другим вредоносным кодом встраиваемым в приложения, технические перепоны и усилившаяся бюрократия еще больше отвернули рядовых программистов от Symbian OS. До тех пор пока платформа была закрытой, и разработкой приложений под нее занимались крупные компании, эти сложности были не столь уж и критическими и они не могли помешать операционной системе бурно захватывать рынок. Однако, со временем, когда общий тренд в разработке ПО изменился на максимальную открытость и вовлечение как можно большего числа программистов, более простые программные интерфейсы у конкурентов Android, iOS и Windows Mobile стали существенно популярнее среди нового поколения разработчиков, тем самым еще больше маргинализируя Symbian.

Зрелость


Феноменальные 73% от всех установленных ОС на смартфонах это вершина пути Symbian OS. Конечно, остается довольно дискуссионным вопрос первопричин такого успеха. С одной стороны, надо отдать должное весьма функциональной и удовлетворяющей всем вызовам времени ОС, а с другой немаловажным фактором ее распространенности стали те великолепные смартфоны Nokia на которых она была предустановлена. Если сейчас, в основном, работа над дизайном смартфона сводится к тому как бы сделать менее броской монобровь с ее динамиком и фронтальной камерой, в нулевых смартфоны обладали индивидуальностью. Выдвижные клавиатуры, раскладушки, сенсорные, сенсорные с клавиатурой, камерофоны, слайдеры и все это разнообразие выпускалось одновременно, не редко еще и одним производителем! Бесспорным лидером среди производства носимой электроники была конечно же Nokia. Крайне агрессивная политика проводимая компанией по захвату всех возможных сегментов рынка мобильных гаджетов стала немаловажным фактором в распространении Symbian OS. Благодаря конкурентным решениям от Nokia, охватывающим как бюджетных потребителей, так и премиум сегмент, существующие тогда альтернативы Symbian OS Palm OS, Windows Phone, Black Berry OS, зачастую проигрывали своему звездному конкуренту именно по железу. Black Berry OS долгое время ставилась только на нишевые смартфоны из премиум сегмента, Windows Mobile долгое время позиционировался как ОС для Карманных ПК и планшетов, в свою очередь разработчики Palm OS хоть вовремя и переориентировали свою платформу под нужды сотовых операторов, однако выпускаемые под этой ОС смартфоны вряд ли могли тягаться с флагманами от той же Nokia.


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

Достигнув своего пика развития в 2007-2008 годах, чисто внешне, казалось, что Symbian это навсегда. Купающаяся в лучах славы Nokia все больше концентрировала в своих руках власть над Symbian Ltd., тем самым уменьшая разногласия между партнерами, вкладывала в разработку ПО баснословные ресурсы. Рассредоточенные по всему миру подрядчики работали над созданием более адекватного API, допиливали саму платформу, как для своего времени создавали выдающиеся сервисы, чего только стоит картографическая служба OVI Maps. Чисто внешне, ни что не предвещало беды.


В нулевых названием компании Nokia нередко подменяло название мобильного телефона как такового

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

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

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

Нет никакой вероятности, что у Apple что-то получится на рынке телефонов Эд Кулиган, руководитель компании Palm.

Менее помпезно чем iPhone, но в том же 2008 году, миру был представлен еще один гаджет HTC Dream. Его дизайн был не столь прогрессивный как у яблочного коллеги, но его особенностью стало то, что он был первый серийный смартфон под управлением операционной системы Android.


У фанатов iPhone новый год начинается в первых числах сентября

Кончина


Уверен, если порыться в закромах то многие из нас смогут отыскать старый, но еще работающий смартфон на базе Symbian. Недавно колупаясь в своей старенькой Nokia С6-01, с установленной на ней Symbian OS Belle, словил себя на мысли, что это все еще довольно актуальный смартфон. Хотя и выглядящие весьма архаично, но от того не менее функциональные приложения Skype, WhatsApp, Facebook, Viber, WeChat, JAVA DM Reader, Translate, QuickOffice, Youtube все еще исправно работают!



Крах самой распространенной мобильной ОС в мире был стремителен. Фактическим временем смерти для Symbian OS стал 2012, ведь именно в этом году мир увидел последний выпущенный под этой ОС смартфон Nokia 808 PureView. Весьма интересный и однозначно современный продукт, но ничего изменить он уже не мог. Ситуация была предрешена, ведь всего за 4 года с момента выхода Android OS, доля Symbian OS уже составляла не более 6% от рынка, в то время как его оппонент контролировал около 60%.

Принятое компанией Nokia решение окончательно похоронить свою операционную систему было настолько же неожиданным, насколько и прогнозируемым. Решение менеджмента финского гиганта Nokia, об отказе от дальнейшей работы над Symbian OS и переход на перспективную платформу Windows Mobile прозвучало еще в 2011 году, почти за год до того как был выпущен Nokia 808 PureView, что уже само по себе не предвещало для него ничего хорошего. В 2010 году о планах выйти из Symbian Ltd заявили восточные партнеры по Symbian Ltd Samsung и Sony Ericsson. Последние переориентировали свою продукцию на ОС под управлением Android. Но многие все равно до последнего не верили, что так любимая ОС просто канет в лету.

Эпитафия


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

Концепция Android, как открытой платформы, в 2000 году была невостребована, и не несла ничего хорошего кроме рисков, но уже в 2010 году стала решающим фактором в конкурентной борьбе. Стоит также вспомнить, что магазин Google Play, всего за год своего существования, вмещал более чем 100 000 приложений, в то время как OVI Store, под Symbian, к этому времени мог похвастатся всего 10 000 наименований, и со временем этот разрыв только рос. В тоже время пример Apple показал, что закрытая платформа в открытом мире это не приговор. Создай разработчики Symbian вовремя удобные инструменты для работы над приложениями сторонним программистам, плюс реализовав вменяемую систему материального поощрения последних и OVI Store также ломился бы от всевозможных приложений.


Кроме лидерства в количестве приложений, уже в 2011 году выторг App Store перевалил за $1 миллиард долларов, оставив далеко позади всех конкурентов

Концепция iPhone состоящая в единовластном управлении своим продуктом, состоянием на 2000 год, очевидно так же не привела бы Symbian к успеху. Подобную модель, в то время, отыгрывала Black Berry, история которой также далека от хеппи-энда. То огромное количество ресурсов которое требуется для создания своей закрытой среды по плечу, пожалуй, только избранным компаниям. Ведь кроме огромных материальных затрат и колоссального опыта в производстве ПО и девайсов, корпорация Apple обладает еще и жесткой вертикально интегрированной структурой. Каждый раз когда в Купертино демонстрируют новый продукт, он так или иначе идет в дополнение к уже существующему миру вещей и сервисов от Apple. Утверждать, что в 1998 году Nokia смогла бы самостоятельно осилить разработку и внедрение своего уникального продукта весьма опрометчиво. Со временем, набравшись опыта и обладая немалыми финансами, в партнерстве с Microsoft, финны попробуют наверстать упущенное презентовав свой первый смартфон под управлением Windows Phone Nokia Lumia 610, но как мы знаем и эта попытка потерпела фиаско. Провал был спровоцирован, в том числе, нарастающими внутренними проблемами в самой Nokia. За годы безбедного существования компания утратила былую эффективность и была уже неспособна успешно вывести на рынок новый продукт, еще и в условиях разгоревшейся внутренней реорганизации проводимой новым СЕО Стивеном Элопом.

Не менее интересно сложились судьбы компаний причастных к Symbian Ltd Nokia, Ericsson, Motorola, Sony, Samsung. На данный момент единственной действительно успешной из них оказалась Samsung. До массового прихода на рынок мобильных гаджетов китайских торговых марок, Samsung удерживал пальму первенства среди проданных смартфонов с предустановленным Android, по сути повторив ассоциативную связку Symbian=Nokia. Благодаря наилучшему в своих девайсах соотношению цена/качество, они задавили всех своих Андроидных конкурентов ведя борьбу в равных условиях единой для всех ОС. Более того Корейская компания стала на столько успешной в создании OLED панелей, что сейчас производит около 93% всех подобных экранов в мире, и для компании уже не так важно на какой смартфон будет установлена эта панель и под какой ОС он работает.


И кто теперь действительно лидер в мире смартфонов?

Одно можно сказать действительно точно нет ничего вечного под солнцем, и соответсвенно жизненные циклы рождения и смерти также присущи таким не материальным вещам как ПО. Однако как и в мире осязаемых вещей продолжительность этой жизни и ее качество зависит в первую очередь от вовремя принятых правильных решений, а потом уже от времени и рока судьбы. Весьма вероятно, что мы могилы бы сейчас жить в мире где все еще доминирует Symbian OS, а OS Android так и загнулась на уровне перспективного стартапа. Если задать вопрос, кто будет править балом мобильных ОС, скажем, лет через 10? Ответ на него мы с вами однозначно сможем дать, пожалуй, лет так через 10. Может быть именно в этот самый момент идет интенсивная работа над очередным убийцей Андроида? И на этот раз новая ОС действительно сможет в ближайшие несколько лет вклинится в противостояние Android-iOS. Возможно, этот процесс будет форсирован политическим фактор, ведь тот факт, что существующие мобильные ОС, как собственно и десктопные, в данные момент крайне зависимы от политических решений принимаемых одной единственной страной, тоже весьма неоднозначный. В любом случае, мы с вами, будем пристально следить за всем происходящим, в столь непредсказуемом и переполненном взлетами и падениями мире ИТ.



Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Maincubes Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

Война миров во вселенной IoTIoE доколе?

12.04.2021 10:16:29 | Автор: admin


Казалось бы еще не так давно вошедшая в наш разговорный обиход аббревиатура IoT Internet of Things, на данный момент, как оказываться, безвозвратно устарела. На смену интернету вещей все чаще приходит сокращение IoE -Internet of Everything, и это не просто жонглирование словами. Ведь, если ранее ставилась задача объединит, главным образом через интернет, в единую систему всевозможные предметы окружающие нас, то в наше время более актуальной стала необходимость создания целых экосистем, которые должны собирать, обрабатывать и выдавать необходимую пользователю информацию. Интернет всего это попытка собрать в одном флаконе гаджеты, интернет, сбор и анализ данных, беспрецедентно глубокое взаимодействие с пользователем. То, что еще лет 20 назад казалось пределом мечтаний умный дом, платежные терминалы, портативные коммуникаторы, сейчас уже повседневная реальность. Новая задача, которую перед нами ставит современность это интеграция всевозможных приложений и человека, объединение воедино разрозненного мира разных гаджетов и не менее обильного количества программных оболочек, так любезно создаваемых производителями этих самых гаджетов.

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

Отрицание




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

Интересный жизненный цикл прошли смартфоны. В то время, когда на заре становления мобильной эры среди производителей техники был откровенный хаос, проявившийся наиболее наглядно в формах и конфигурациях портов и ОС когда каждый производитель жаждал создать свой уникальный разъем, как под зарядку так и под передачу данных с устройства. Долгое время производители также не видели в этом никакой проблемы. Со временем, после внедрения единых стандартов связи IrDA, Bluetooth, WiFi, а также создания универсального порта на базе USB, казалось бы, мир должен был вздохнуть с облегчением. Но не тут-то было. В 2007 году вышел iPhone. И тут сложно сказать, что сподвигнуло корпорацию на продвижение своих собственных разъемов. Слабая распространенность micro USB в 2007 году? Более прогрессивный нежели конкуренты представленного в 2012 году Lightning? Инерция в сегменте носимых гаджетов, после начала повсеместного внедрения перспективной технологии USB Type-C в 2014 году? Чего уже говорить о разброде и шатании в рядах оперативных систем под которыми работали все эти гаджеты?


Рассвет конкуренции выпал на 2010-2011 года. Исходом противостояния стало всецелое доминирование Android и iOS. У Symbian OS явно что-то пошло не так

Гнев


Абсолютно не удивительно слышать негодование рядовых юзеров об отсутствии универсальной совместимости создаваемой производителями техники, как на физическом так и на программном уровне. Однако, в любом случае, никто вас не тянет в тот же Apple store за покупкой нового iPhone, если вас так уж не устраивают установленные на нем разъемы, или ОС. Но вот что делать с 5-тю и более мессенджерами, с 8-ю и более социальными сетями, с 8-ю платежными системами, активным пользователем которых, с ужасом, как-то заметил мне приходится быть? И тут разговор уже идет не следствии моего суверенного выбора, а констатация печального факта жизненной необходимости.

Сложно забыть тот чувство счастья когда мне довелось установить на ПК первый свой мессенджер ICQ. Объединив в единое онлайн-сообщество всех моих друзей, и просто знакомых, эта платформа вывела всех нас на новый уровень коммуникации. Однако, время шло и был QIP, Skype, WeChat, Viber, WhatsApp, Telegram, Zoom далее пошли социальные сети, которые с определенного момента также начали дублировать функции мессенджеров, VK, OК, Facebook, Twitter, Instagram, LinkedIn, Google+ и каждое из названных приложений устанавливалось не от праздного интереса. И тут, собственно, беда не столько в существовании большего числа социальных платформ, каждая из которых однозначно ориентируется на свой сегмент рынка, проблема заключалась в невозможности оперировать единым аккаунтом и невозможности собрать на единой площадке весь свой круг общения. То что еще недавно дарило столько радости и счастья сейчас доставляет лишь дискомфорт отбирая кучу времени и внимания.


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

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

Торг


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


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

В данный момент, фактически, мировая ИТ-индустрия поделена между двумя платформами Android и iOS. Если создаваемое вами ПО не поддерживается минимум одной из этих платформ забудьте в принципе о какой либо финансовой успешности вашего продукта. Альтернативные платформы, потенциально готовые стать основой для IoT/IoE, создаваемая в рамках импортозамещения теми же китайцами Harmony OS, на сегодняшний день не могут создать полноценную конкуренцию лидерам. И дело тут не в слабой технической реализации альтернативных проектов. Программные продукты от Microsoft, в свое время лидера по распространенности ОС, с каждым годом теряют свои позиции, даже не смотря на то, что более 20 лет компания занимается разработкой и продвижением своего детища Windows, на те же самые мобильные платформы. Но как показала практика просто хорошего продукта мало, ПО должно более глубоко интегрироваться с окружающим нас миром.


Времена новые, но уловки остаются старые. За окном был 2020 год

Депрессия


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



И самое тут удивительное то, что альтернативы сложившемуся положению вещей не виднеется даже на горизонте. К примеру, те же самые разработчики Harmony OS, авторитетно заявили, что рассматривают ее исключительно как план Б на случай отключения поддержки Android для производителей техники из Поднебесной. Даже всесильные китайцы, со своими неограниченными материальными и человеческими ресурсами, признают невозможность полноценной конкуренции своего продукта в современном мире. Такая же андерграундная альтернатива, лидерам ИТ-рынка, как использование KaiOS, SIRIN OS, Ubuntu Touch, Tizen OS, Аврора ОС для среднестатистического пользователя, фактически, является повседневной болью и унынием, ведь все они имеют узконаправленный функционал и не отвечают требованиям нового мира IoE.


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

Принятие


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


За 11 лет из более двух десятков социальных сетей в лидерах остались только пять. К чему мы придем еще через 11 лет? Тенденция очевидна

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

Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Maincubes Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробнее..

Мониторинг в ЦОДе как мы меняли старую BMS на новую. Часть 4

20.04.2021 16:13:49 | Автор: admin

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

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

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

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

В этой части мы поделимся практическим опытом настройки нашей системы мониторинга работы ЦОДа.

Немного теории

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

А телеизмерение, как нетрудно догадаться, это цифровое значение какого-либо параметра, например 220 Вольт или 10 Ампер.

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

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

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


Когда какое-то устройство требует индивидуальных настроек у требуемой переменной, мы применяем специальную отметку Только для этого устройства. Теперь переменная стала индивидуальной для одного конкретного устройства, имеет свою уставку и не влияет на другие одноименные переменные.

Дополнительно в самих устройствах есть собственные заводские уставки. Например, в PDU с завода настроено распознавание аварийной ситуации на превышение тока в 32А. В случае ее срабатывания от PDU поступит оповещение о типе аварии Overload Alarm. И это совсем другая переменная, не связанная с переменной OutputCurrent, настроенной в BMS.

Пример заводских настроек уставок внутри PDU:


Итак, мы перечислили основной функционал для настройки системы мониторинга.

Как же правильно настроить это пианино? Давайте рассмотрим задачи по порядку.

Чего мы хотим добиться

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

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

Этап 1. Определение нужных и ненужных переменных у каждого устройства

Обычно к каждому устройству идет так называемая карта переменных, на основании которой инженером-наладчиком создается драйвер. Его задача указать системе мониторинга, в каком именно регистре получаемых данных находится нужная переменная. Например, в регистре 1 протокола опроса устройства находится информация о режиме работы двигателя System_on_fun, а в регистре 2 о режиме работы компрессора Compressor_1.

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

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

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

  • Чем больше опрашивается переменных, тем выше вероятность сбоя опроса. Особенно это актуально для устройств, подключенных по шлейфу (например, через шлюз по протоколу MODBUS). Это приводит к получению состояний нет данных (Н/Д) или обрыв связи, то есть фактически устройство периодически выпадает из мониторинга.

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

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



Заводские уставки внутри устройств по нашему опыту на начальном этапе лучше не трогать (конечно, если они не сообщают вам уже об аварии). Однако на каждой тренировке по конкретному оборудованию следует напоминать сотрудникам о наличии уставок и в самом устройстве, и в BMS. Это в будущем поможет дежурным точно понимать, что именно является причиной аварийного сообщения.

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

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

Этап 2. Минимизация ложных и неинформативных сообщений

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

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

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

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

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

Для оптимизации количества сообщений при переходе на ДГУ следует:

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

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

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

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

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

Например, нам потребовалось наблюдение за 4-5 переходами для приемлемой настройки новой BMS. Чтобы проанализировать внеплановый процесс перехода, мы делали запись экрана системы мониторинга, так как важно наблюдать аварийные сообщения не в архиве событий, а анализировать появление аварий в динамике оперативной сводки.

Этап 3. Дополнительные советы из нашего опыта

1.На экранах дежурной смены не должно быть лишней индикации в цветах аварийных сообщений.

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

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

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

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

2. С осторожностью используйте SMS-оповещения.

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

3. Настраивайте дублирование сообщений об авариях через мессенджер.

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

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

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

4. Группируйте сообщения в мессенджерах.

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

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

5. Ярко выделяйте в интерфейсе сообщение о пропадание связи с сервером.

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

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


6.Подключайте к мониторингу как можно больше систем.

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

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

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

Тем самым снижается риск пресловутого человеческого фактора. Пример тестового сигнала ПОЖАР в системе BMS ЦОДа, подключенного через сухие контакты.


Подведем итоги нашей 4-серийной истории

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

Пройдя довольно трудный и длинный путь, мы получили:

  • быструю и стабильную систему мониторинга, которая на данный момент контролирует более 2500 устройств и обсчитывает около 10000 виртуальных датчиков;
  • резервирование системы на платформе облачных решений Linхdatacenter в Санкт-Петербурге и Москве;
  • доступ к системе из любой точки мира через веб-интерфейс, с дополнительной отправкой сообщений из системы на любые мессенджеры, что позволило сократить максимальное время информирования персонала об аварии до 1 минуты;
  • ощутимую экономию, так как система обошлась в разы дешевле аналогов, легко масштабируется и не требует платы за лицензии для устройств или пользователей;
  • надежное решение, которое позволило нам не только улучшить собственные процессы, но и предложить новый коммерческий продукт нашим заказчикам гибко настраиваемую и масштабируемую систему мониторинга.
Подробнее..

Исследование актуальных потребностей IT-служб

28.04.2021 16:12:49 | Автор: admin

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

Цели и задачи

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

Методология

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

Всего в опросе приняли участие более 200 руководителей IT-служб различных отраслей экономики.

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

Результаты исследования

В ситуации пандемии многие компании и, соответственно, IT-службы перешли на удалённый или гибридный формат работы.

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

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

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

Некоторые компании отметили увеличение активности в сегменте b2c, что также повлияло на работу IT-служб.

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

Более половины респондентов ответили, что сбои в работе корпоративных сервисов происходят менее раза в месяц.

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

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

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

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

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

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

Затраты на IT-инфраструктуру компании сочли оптимальными почти 45% опрошенных. При этом около половины участвующих в опросе представителей отрасли здравоохранения сообщили, что не считают затраты оптимальными в полной мере.

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

ИТОГИ И РЕКОМЕНДАЦИИ

Обобщив полученные данные, мы сделали выводы о том, что:

  • за 2020 год произошел существенный рост нагрузки на IT;

  • проблемы при сбоях решаются преимущественно внутренними сотрудниками;

  • немногим менее половины организаций теряли данные после сбоев;

  • аудиты и тесты систем проводятся не регулярно;

  • скорость и качество решения задач своими силами удовлетворительные;

  • больше половины организаций планируют проекты в области разработки, оптимизации/модернизации IT.

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

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

  • повышение квалификации сотрудников IT-служб с помощью обучения или привлечение внешних экспертов для проведения совместных сложных работ.

Кроме этого

  • при планировании миграции на open source необходимо обратить внимание на сложность работ и провести обследование на возможность такой миграции, составить план миграции и согласовать с бизнесом "окно" простоя;

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

  • возможно, стоит также обратить внимание на реализацию проектов по схеме Agile и/или микросервисной архитектуры.

Итоги исследования мы представили на вебинаре, с видео-записями которого можно ознакомиться на нашем Youtube-канале.

Подробнее..

Интернет в Афганистане на острие перемен

10.05.2021 12:10:00 | Автор: admin

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

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

Ничто ни предвещало беды

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

На фотографии изображены студентки кабульского политехнического института - представительницы типичной кабульской молодежи 70-хНа фотографии изображены студентки кабульского политехнического института - представительницы типичной кабульской молодежи 70-х

Сейчас это может звучать дико, но в 70х годах центрально-азиатская республика была довольно светской и открытой к новым идеям и технологиям. На фоне военного противостояния Ирана и Ирака, Пакистана и Индии, в условиях подогреваемого на этой почве у соседей религиозного фанатизма Афганистан выглядел как некий островок стабильности и созидательного труда. Особую роль в развитии страны сыграл СССР, и это тоже без всякого сарказма. Мало кто сейчас помнит, что до того как развязать в Афганистане полномасштабную войну северный сосед на протяжении 20 лет вкладывал в него миллиарды рублей, что собственно в дальнейшем и послужило одним из мотивов к предоставления военной помощи "братскому государству". Начиная с конца 50х годов советские специалисты прокладывали дороги, строили трубопроводы и гидроэлектростанции, пробивали в скалах тоннели и возводили дома в сейсмически активной стране. Особой гордостью советской помощи братскому народу Афганистана стал КПИ - Кабульский Политехнический Институт, который открыл свои двери для будущих инженеров в 1963 году. Аж до самого 1979 года учебное заведение, создание фактически с нуля, в основном комплектовалось советскими преподавателями. По истечению многих лет и событий, даже сейчас, институт существует и все еще несет отпечаток былой дружбы народов.

Афганская сторона впервые принимает генерального секретаря товарища Хрущева Н.С. 1955 год.Афганская сторона впервые принимает генерального секретаря товарища Хрущева Н.С. 1955 год.

При всех внушительных объемах советской помощи не стоит забывать и про британское влияние на регион в целом. Крупные землевладельцы, местная аристократия были знакомы с европейской культурой и ее техническими достижениями не только посредством общения с британской администрацией, а и непосредственно путешествуя в Европу и США. В этом контексте можно лишь напомнить, что нынешний президент Республики Афганистан - Ашраф Гани Ахмадзай, получал высшее образование в США, а к 1983 году и вообще заслужил звание доктора наук при Колумбийском Университете. В следствии борьбы за центральную Азию, в 60-70х годах, также как и СССР, "империалисты" вкладывала не малые ресурсы в развитие Афганистана. Именно на средства США была проведена модернизация и возведены новые корпуса главного учебного заведения страны - Кабульского Университета. Эти подарки должны были нивелировать нарастающее влияние СССР показав обществу капиталистический путь развития, гражданам страны где все более и более укоренялись идеи социализма.

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

На фотографии красуються бортпроводницы компании Ariana Afganistan Airlines. Кабул начало 70-хНа фотографии красуються бортпроводницы компании Ariana Afganistan Airlines. Кабул начало 70-х

Катастрофа

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

В 70-х годах Афганистан был частью мировых коммуникационных сетей, находясь в Кабуле вы могли легко позвонить в Москву, Лондон, Нью-Йорк. Во многом страна была куда более открытой и демократической нежели несущие ей свободу, равенство и братство интернациональные должники. В таких условиях появление интернета в стране не упиралось в какие то либо технические, политические барьеры и было чисто делом времени. Ввод советских войск естественно нарушил весь мирный ход вещей. Вместо короткой победоносной операции СССР получил полномасштабную партизанскую войну, щедро подпитываемую ресурсами "из за океана", и загряз в стране на долгих 10 лет. Это стало настоящей катастрофой для национальной инфраструктуры Афганистана. Бывшие благодетели не просто приложились к уничтожению материальной базы страны, противостояние двух сверхдержав породило куда более ужасное явление - моджахедов. То что еще недавно жило в самых далеких уголках сознания, то что проповедовали самые отшибленные муллы в самых удаленных от цивилизации аулах вышло на свет и заняло доминирующую позицию в обществе. Вчерашние молодые и прогрессивные студенты в момент оказались перед делимой - либо они вынуждены покидать свою родину в поисках мирной жизни, либо они вливаются в ряды религиозных экстремистов щедро спонсируемых и вооружаемых ЦРУ. Финальный мазок в этой картине вакханалии насилия, в 1989 году, поставило решении о выводе советских войск из страны. На первый взгляд окончание войны и вывод вооруженных сил оккупанта должно было принести мир и новую эру благополучия на многострадальную афганскую землю, но перемены принесли только новые беды.

Советский воин должен стойко переносить все тяготы и лишения военной службыСоветский воин должен стойко переносить все тяготы и лишения военной службы

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

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

Более чем на 9 лет мировое сообщество закрыло глаза на все бесчинства Талибана в огромном 30 миллионном государствеБолее чем на 9 лет мировое сообщество закрыло глаза на все бесчинства Талибана в огромном 30 миллионном государстве

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

До прихода в 2001 году на афганскую землю объединенных вооруженных сил под эгидой NATO, за 9 лет правления талибы оставили после себя выжженную землю.

С чистого листа

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

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

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

Централью часть Афганистана составляют неприступные горы Гиндукуш. Высота наивысшей горы Ношак составляет 7492 мЦентралью часть Афганистана составляют неприступные горы Гиндукуш. Высота наивысшей горы Ношак составляет 7492 м

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

Не смотря на мусульманские традиции и крепко засевший в наших головах стереотип афганской женщины - наглухо замотанной в бурку, требование полностью скрывать лицо девушкам старше 8 лет существовало в Афганистане только на протяжении короткого периода узурпации талибами власти с 1992 по 2001 годНе смотря на мусульманские традиции и крепко засевший в наших головах стереотип афганской женщины - наглухо замотанной в бурку, требование полностью скрывать лицо девушкам старше 8 лет существовало в Афганистане только на протяжении короткого периода узурпации талибами власти с 1992 по 2001 год

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

Протяженность национальной ИТ-кольцевой составляет более 2500 км. В 2007 году она объединила наиболее населенные города Афганистана и позволила населению страны впервые получить доступный интернетПротяженность национальной ИТ-кольцевой составляет более 2500 км. В 2007 году она объединила наиболее населенные города Афганистана и позволила населению страны впервые получить доступный интернет

Хотя первый оператор мобильной связи в стране и появился уже в 2002 году, вплоть до 2007 года стоимость доступа к интернету, да как и к мобильной сети вообще, была просто заоблачной. По оценкам представителей рынка тогда цена "входного билета" для пользователя GSM связи составляла не менее $500 - покупка мобильного, SIM карты, первый месячный взнос. На данный момент весь этот пакет стоит менее $100 и это при том, что операторы покрыли своими сетями более 70% территории страны. Появление полноценной оптики стало для Афганистана поистине революционным событием. На базе новой инфраструктуры были создан целый ряд новых телефонных компаний, провайдеров домашнего интернета, что позволило впервые за три десятка лет простым людям связаться со своими родственниками не только внутри страны, а и за рубежом. Сейчас цена самого дешевого проводного интернета составляет около $10 в месяц. За более-менее удовлетворительный канал можно выложить и до $100.

Помесячная цена на не лимитированные пакеты проводного интернета с гарантированной скоростью в 1Мбит/с для г.КабулПомесячная цена на не лимитированные пакеты проводного интернета с гарантированной скоростью в 1Мбит/с для г.Кабул

Халяльный интернет

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

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

Надежда на будущее

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

Количество в тоннах производимого в Афганистане опиума по годамКоличество в тоннах производимого в Афганистане опиума по годам

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

Пригород КабулаПригород Кабула

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

Особенностью Афганистана является высокая концентрация населения в городах. Так в городской агломерации Кабула проживает около 4.5 миллиона людей. Данная специфика особо способствует внедрению интернета в странеОсобенностью Афганистана является высокая концентрация населения в городах. Так в городской агломерации Кабула проживает около 4.5 миллиона людей. Данная специфика особо способствует внедрению интернета в стране

Немного рекламы

Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым,облачные VPS для разработчиков от $4.99,уникальный аналог entry-level серверов, который был придуман нами для Вас:Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер?(доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Maincubes Tier IV в Амстердаме?Только у нас2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199в Нидерландах!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - от $99!Читайте о томКак построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?

Подробнее..

Разбиваем монолит на микросервисы

30.06.2020 08:17:02 | Автор: admin

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



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


Итак, ваша организация решила разбить старый, добрый монолит на микросервисы. Почему? Ясного ответа никто дать как правило не может, но в целом все начинают описывать как им плохо живется с монолитом. Да, релизные циклы действительно очень зацеплены за разные команды. А почему вы думаете, что в МСА по-другому? Кто-то говорит, что микросервисы гораздо лучше масштабируются. Ну можно сделать и так, а вам зачем это? Нет, может и надо, но вы понимаете зачем или просто подсмотренную фразу используете? Говорят, каждый микросервис гораздо менее требователен к ресурсам: памяти, базе данных и т.д. Ну и что? У вас деньги на сервера иссякли? Бизнес ценность-то в чем?
Коллеги, я не хочу сказать, что у МСА нет преимуществ. Эти преимущества есть. Но я хочу сказать, что какие бы цели вы ни ставили при старте проекта разбивки, вы их скорее всего ставите неправильно и никогда не достигните. Не достигните просто потому, что реализацией проекта у вас будут заниматься те люди, которые довели до состояния бездарно написанного кода ваш монолитный проект. При этом все подходы при реализации МСА настолько отличаются от монолитной, насколько телефонная лапша 20-го века отличается от сетевых технологий нынешнего 21-го века. И аналогия здесь действительно очень удачная. ТФоП доставляет в квартиру одну телефонную линию. Обрыв на любом участке линии приводит к выходу ее из строя. Сетевые технологии динамичны и позволяют строить альтернативные маршруты. Даже выход из строя 60% всей сетевой инфраструктуры страны в результате ядерной войны, не приведет к отказу оставшихся сетей.


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


А сейчас разберем повсеместно встречающиеся ошибки при развитии микросервисной системы предприятия.


  1. Отказ от изменений бизнес-процессов
    Говорят, что любой бизнес реализует в коде свои бизнес-процессы. И, если вы 20 лет до этого строили свои бизнес-процессы на базе вашей монолитной архитектуры, то любая ваша попытка внедрить МСА будет заведомо обречена на провал. Просто потому, что для этого требуется менять бизнес-процессы.Пример? Сколько стадий согласования вопроса у вас существует в организации? Так вот, в микросервисной команде число таких стадий приближается к нулю. Подавляющее большинство вопросов решается внутри команды, реализующей микросервис. Команда не обязана выносить на корпоративный уровень вопросы о языке, на котором будет написан микросервис. Одни могут выбрать Java, а другие Python. Вы может быть даже сейчас не поверите, но этот вопрос является полностью в компетенции команды. И это потому, что в случае каких-то проблем, микросервис проще ПЕРЕПИСАТЬ, чем ПОДДЕРЖИВАТЬ.
    По моему опыту, разработка простейшего микросервиса при нормально поставленном производстве занимает неделю работы двух джунов, включая бюрократию по выводу его в пром, т.е. обходится компании, включая различные накладные расходы, примерно в 50-100 тыс. руб. Если у вас только аналитика занимает месяц работы 3 команд, то у вас нет никакой МСА в организации, вы опять скатываетесь в лютую монолитчину.
  2. Поручить руководство проектам опытным монолитчикам
    После того как вы отказались от модернизации своих бизнес-процессов, совершенно логичным является то, что вы поручаете новый проект очень опытному человеку, который показал себя с лучшей стороны и вообще знает все ваши бизнес-процессы. Возможно кто-то вам и нудел, что на старые проблемы должен взглянуть новый опытный человек, но вы отмахнулись от него как от глупой назойливой мухи. И вот он. Ваш новый/старый руководитель разработки на проекте. Не удивляйтесь, что результат будет тем же, что и раньше и даже хуже. Когда в МСА начинают применяться монолитные решения, ни к чему хорошему это не приведет. Именно в этот самый момент вы подписали смертный приговор вашему пилоту. Возможно, вы даже наберете опытных людей, которые уже сожрали стаю собак на микросервисных проектах, но это вас не спасет, просто потому что их начальник слушать не будет. Просто потому что у него мозги не заточены под МСА, а советы других он будет воспринимать как чудовищную глупость.
  3. Архитектура разрабатывается архитекторами без опыта разработки
    Вот сидит такой архитектор, который за свою жизнь не написал ни строчки кода и выдает распоряжения разработчикам. Очень часто, разработчики оказываются более квалифицированными чем он сам, но он как наполеончик отдает распоряжения. Распоряжения конечно же глупые. Примеры этих распоряжений смотрите дальше.
  4. Повторить функционал монолитной системы.
    Ну это же логично: надо сначала полностью воспроизвести то, что уже есть, а потом двигаться дальше. Воспроизвести все баги и костыли, все то дерьмо, от которого годами плюются разработчики.
    Мне одно не понятно: с чего эти архитекторы взяли, что потом кто-то даст денег на рефакторинг? Т.е. вы копируете вашу морально устаревшую систему, не привносите ничего положительного с точки зрения функционала и с этим 20 летним старьем вы будете жить еще как минимум 10 лет до следующего рефакторинга.
  5. Переиспользование кода
    Любой монолитчик знает, что код надо переиспользовать. Если сделал функцию User::toString, то в рамках МСА ее сейчас нужно выделить в отдельный микросервис и все 1000 других микросервисов будут ломиться к ней для сериализации каждого юзера. То, что первый же сбой в микросервисе положит всю систему в монолитах же такого не было.

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


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


  1. Проанализируйте свой предыдущий опыт, составьте список того, что считаете удачным, а что вам следует пересмотреть. Проведите опрос клиентов, пускай они запросят необходимые изменения в функционале. Ваша цель путем одного мелкого и ювелирно точного рефакторинга достичь нескольких бизнесовых целей. Ваша цель не переписывать одно и то же 10 раз, а создавать бизнес-продукт, который будет приносить деньги. Вы не просто должны сделать копию легаси-системы, а должны построить новейшую систему, которая выведет вас на передовой край ИТ отрасли. Зачем вам эти старые костыли?
  2. Пересмотрите свои бизнес-процессы. Если у вас любой agile всегда скатывается к жесткому водопаду, если согласования и аналитика занимают месяцы, то ваше производство ПО требует кардинальной модернизации. А для этого нужно ...
  3. найти специалиста с большим опытом разработки микросервисных систем. Пускай он не посвящен в ваши бизнес-процессы, но этот новый человек посмотрит на ваши застарелые проблемы свежим взглядом и даст действительно ценные рекомендации. Кроме того, только человек с реальным опытом микросервисной разработки способен предусмотреть те подводные камни, которые вам встретятся. Ваш опытный монолитчик только все запорет.
  4. Легаси-разработчики это ваш резерв, который в новой разработке сможет выступить ценным экспертным звеном. Но люди, которые пилили монолит в виде костылей, ни в коем случае не должны стать костяком разработки микросервисной системы и определять ее архитектуру. Монолитчиков должна ждать стажировка под руководством людей с опытом построения микросервисных систем. И главное что ждет монолитчиков это жесткий слом мозга и полная перестройка мышления.
  5. Каждый микросервис это не просто мелкая функция бэкенда. Это полный цикл разработки бизнес-функции. Одна команда полностью должна нести ответственность за всю разработку этой бизнес-функции как на фронтенде, так и в базе данных. Как только вы начинаете делегировать часть разработки другим командам, вы тут же начинаете погрязать в интеграциях. Интеграции в МСА это еще более дорого, ненадежно и неэффективно чем в монолите. Необходимо снижать их количество. В качестве микросервиса вполне нормально выбрать CRUD для какой-то сущности, например, сущности клиентского договора. Это нормально, если команда предоставит как бэкенд, так и фронтенд-микросервис (или библиотеку) для работы с договорами: список, создать, обновить, удалить. Главное это чтоб команда несла полную ответственность за то как эта функция будет работать на сайте и в мобилах.
  6. Не нужно заниматься фанатизмом при внедрении микросервисной архитектуры. При правильной микроархитектуре сервисов, вы сами решаете в какой форме выпустить приложение: в монолитной, микросервисной или бессерверной архитектуре. Ожидайте, что ваша бизнес-постановка может измениться в любой момент и вы должны с легкостью реализовать изменения. Гибкая разработка это то что просто без лишней болтовни должно реально применяться на всех уровнях.
  7. С недоверием относитесь к переиспользованию функционала. Наоборот, любой функционал должен дублироваться. Ваш выигрыш 10 гигабайт дисковой памяти никого не впечатлит, если справочник, который используют 30 микросервисов будет остановлен из-за сбоя, приведя к каскадному отключению всей микросервисной системы. Микросервисы должны КУПИРОВАТЬ сбои сторонних сервисов, а не усиливать их. И этот принцип это главная проблема для монолитчиков. После 20 лет работы с реляционными БД, после десятилетий опыта нормализации таблиц и структур данных в приложениях, очень сложно приучить себя к мысли, что дублирование, репликация, шардирование, денормализация это нормально и полезно для проекта, а переиспользование и нормализация это потенциально сбойные места, готовые положить всю систему.
  8. И вообще, что произойдет после сбоя одного из модулей? Вы просто должны моделировать все такие сбои и штатно обрабатывать их. Каскадное отключение всей системы это лишь один из сценариев. Неприятностей может быть много. Это в монолите все компоненты находятся в одном Jar-нике. В МСА каждый микросервис отделен ненадежными и компроментируемыми сетевыми коммуникациями. Это не плохо и не страшно. Это надо просто держать в голове при разработке и предусматривать сценарии разрыва этих коммуникаций.
  9. Если вы очень любите Spring, Hibernate и OracleDB, то скорее всего вы никогда не сможете построить надежную и быструю микросервисную систему. Spring был изобретен в годы становления монолитной архитектуры. Это огромный монстр, который даже в функции простого Hello World превратится в jar-файл размером в сотни мегабайт. Просто старт такого приложения растягивается на минуты. И эти гигабайты бессмысленного цифрового мусора будут пожирать ваши серверные ресурсы 24x7x365. Oracle, Postgres, MySQL это все жуткое старье, которое было построено из расчета, что база данных должна крутиться на одном сервере. Да, время идет и все эти базы данных обзавелись средствами масштабирования, но до сих пор они в этом вопросе совершенно неуклюжи и ненадежны. Существуют целые классы баз данных (NoSQL, NewSQL), которые создавались в парадигме Big Data, High Availability, распределенное хранение и т.д. И эти ораклы с постгресами с ними просто не способны конкурировать по надежности и скорости работы. Все эти крутые спринги, ораклы и хайбернейты это наследие уходящей эпохи монолита. Эпоха микросервисов и облачных функций это быстрый старт приложений при возникновении нагрузки, отсутствие состояний для высокой масштабируемости и безжалостная выгрузка всех приложений и ресурсов, которые в данный момент не нужны и лишь бессмысленно расходуют оперативную память.

Заключение.


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


Подробнее..

Убрать скрытые поборы для американский сетей широкополосного доступа готовят новый план развития

03.05.2021 14:08:04 | Автор: admin

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

Фотография: Oscar Schnell. Источник: Unsplash.comФотография: Oscar Schnell. Источник: Unsplash.com

Что происходит

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

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

Борьба за сети

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

Фотография: Nadine Shaabana. Источник: Unsplash.comФотография: Nadine Shaabana. Источник: Unsplash.com

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

Регулирование рекламы

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

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

Что дальше

Пока предложения находятся на стадии обсуждения и детализации, поэтому оценить последствия от их внедрения достаточно сложно. Однако стремление к устранению так называемого цифрового разделениямежду средним классом и малообеспеченными гражданами из пригородов и отдаленных уголков страны очевидно. Последних, так или иначе, постараются снабдить новыми возможностями для работы и получения образования, и в текущей обстановке высокоскоростная связь может выступить ключевым фактором. В The American Jobs Plan планы на это счет сравнивают с запуском электрификации страны в 1936-м году.

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


Дополнительное чтение:


Подробнее..

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

03.05.2021 18:11:31 | Автор: admin

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

Фотография: Oscar Schnell. Источник: Unsplash.comФотография: Oscar Schnell. Источник: Unsplash.com

Что происходит

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

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

Борьба за сети

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

Фотография: Nadine Shaabana. Источник: Unsplash.comФотография: Nadine Shaabana. Источник: Unsplash.com

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

Регулирование рекламы

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

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

Что дальше

Пока предложения находятся на стадии обсуждения и детализации, поэтому оценить последствия от их внедрения достаточно сложно. Однако стремление к устранению так называемого цифрового разделениямежду средним классом и малообеспеченными гражданами из пригородов и отдаленных уголков страны очевидно. Последних, так или иначе, постараются снабдить новыми возможностями для работы и получения образования, и в текущей обстановке высокоскоростная связь может выступить ключевым фактором. В The American Jobs Plan планы на это счет сравнивают с запуском электрификации страны в 1936-м году.

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


Дополнительное чтение:


Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru