Дата-центры OVH

Как и все участники ИТ-сектора, 14 мая 2019 года компания OVH была проинформирована об уязвимостях системы безопасности после обнаружения аппаратных уязвимостей на процессорах Intel.

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


Эти сбои обозначаются как RIDL, Fallout или ZombieLoad и включают в себя следующие векторы атаки:

• CVE-2018-12126 [выборка данных буфера микроархитектурного хранилища (MSBDS)]
• CVE-2018-12130 [выборка данных микроархитектурного буфера заполнения (MFBDS)]
• CVE-2018-12127 [микроархитектурная выборка данных порта нагрузки (MLPDS)]
• CVE-2019-11091 [микроархитектурная выборка данных без кэшируемой памяти (MDSUM)]

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

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

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

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

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

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

• Windows: support.microsoft.com/en-us/help/4072698/windows-server-speculative-execution-side-channel-vulnerabilities-prot
• Linux Red Hat: access.redhat.com/security/vulnerabilities/mds
• Ubuntu: blog.ubuntu.com/2019/05/14/ubuntu-updates-to-mitigate-new-microarchitectural-data-sampling-mds-vulnerabilities

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

us.ovhcloud.com/products/servers/infrastructure-servers

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

• значительно быстрее запросы с обновлением Lucene, более эффективное использование файловой системы, а также в отношении журналов — новые функции, такие как сортировка;
• новый дополнительные параметры запроса: композитное агрегирование, диапазон IP типы полей и т.д.

Это обновление будет происходить по вашим услугам 18 июня 2019 между 11 утра и 5 вечера В течение этого периода, короткое время простоя и задержки во время запроса к базе данных, как ожидается.

Вы можете следить за ходом выполнения этой задачи по следующей ссылке: travaux.ovh.net/do=details&id=38457

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

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

Наша «Kibana как услуга» обновляется и будет немедленно быть совместимы с новым протоколом.

Dedicated документация доступна с перечислением точек внимания и в зависимости от вашего случая, возможные изменения, требующие, чтобы быть сделаны вами: docs.ovh.com/gb/en/logs-data-platform/upgrade_to_es_6/
На этой странице перечислены, среди прочего, изменения в функциональности и API в этой новой версии: новые обязательные поля в заголовке, более жесткие логические значения и т.д.

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

Команда OVH Журналы Data Platform
Документация: docs.ovh.com/gb/en/logs-data-platform/
Сообщество Hub: community.ovh.com/c/platform/data-platforms

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

Мы начали с разделения проблемы на четыре основных этапа:

• Сбор информации
• Хранилище данных
• Аналитика данных
• Визуализация / действия
• Сбор информации

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


Какие данные собирать?
На современных серверах BMC (Board Management Controller) позволяет нам контролировать обновления прошивки, перезагрузки и т. Д. Этот контроллер не зависит от системы, работающей на сервере. Кроме того, BMC дает нам доступ к датчикам для всех компонентов материнской платы через шину I2C. Протокол, используемый для связи с BMC, является протоколом IPMI, доступным через LAN (RMCP).

Что такое IPMI?

• Интеллектуальный интерфейс управления платформой.
• Возможности управления и мониторинга независимо от операционной системы хоста.
• Под руководством INTEL, впервые опубликована в 1998 году.
• Поддерживается более чем 200 поставщиками компьютерных систем, такими как Cisco, DELL, HP, Intel, SuperMicro

Зачем использовать IPMI?

• Доступ к аппаратным датчикам (температура процессора, температура памяти, состояние шасси, питание и тд.)
• Нет зависимости от ОС (то есть решение без агента)
• Функции IPMI, доступные после сбоя ОС / системы
• Ограниченный доступ к функциям IPMI через пользовательские привилегии

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


Akka Мы решили построить наш сборщик данных IPMI на платформе Akka. Akka — это инструментарий с открытым исходным кодом и среда выполнения, упрощающая создание параллельных и распределенных приложений на JVM.

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

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

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

API REST определен для связи со сборщиком данных двумя способами:

• Чтобы отправить конфигурации
• Получить информацию о контролируемых серверах

Узел кластера работает на одной JVM, и мы можем запустить один или несколько узлов на выделенном сервере. Каждый выделенный сервер, используемый в кластере, помещается в VRAC OVH. Пул шлюза IPMI используется для доступа к BMC каждого сервера, а связь между шлюзом и сборщиком данных IPMI защищена соединениями IPSEC.



Хранилище данных
Метрики OVH Конечно, мы используем сервис метрик OVH для хранения данных! Перед сохранением данных сборщик данных IPMI объединяет метрики, квалифицируя каждый датчик. Окончательное имя метрики определяется объектом, которому принадлежит датчик, и базовой единицей значения. Это облегчит процессы последующей обработки и визуализации / сравнения данных.

Каждый коллектор IPMI центра обработки данных передает свои данные на сервер оперативного кэша Metrics с ограниченным временем хранения. Вся важная информация сохраняется на сервере OVH Metrics.


Аналитика данных
Мы храним наши метрики в warp10. Warp 10 поставляется с языком сценариев временного ряда: WarpScript, который делает аналитику мощной, чтобы легко манипулировать и обрабатывать (на стороне сервера) наши собранные данные.

Мы определили три уровня анализа для мониторинга работоспособности серверов:

• Простая пороговая метрика на сервер.
• Используя службу метрических циклов OVH, мы объединяем данные по стойке и по комнате и вычисляем среднее значение. Мы устанавливаем порог для этого среднего значения, это позволяет обнаруживать стойки или общий отказ помещения в системе охлаждения или системы электропитания.
• Служба MLS OVH выполняет обнаружение аномалий в стойках и помещениях, прогнозируя возможное развитие метрик в зависимости от прошлых значений. Если значение метрики находится за пределами этого шаблона, возникает аномалия.

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


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

При обсуждении концепций DevOps и инфраструктуры как кода быстро появляются инструменты, разработанные HashiCorp. С помощью Terraform HashiCorp предлагает простой способ автоматизации предоставления инфраструктуры как в общедоступных облаках, так и локально. Terraform имеет долгую историю развертывания и управления ресурсами публичного облака OVH. Например, вы можете найти полное руководство по GitHub. В этой статье мы сосредоточимся на использовании Terraform для взаимодействия с другим решением OVH: Private Cloud.


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

www.ovh.com/fr/blog/private_cloud_and_hashicorp_terraform_part1/

После того, как Advance, встань!
Диапазон Rise предлагает наши самые доступные по цене неокрашенные серверов. На основе Xeon платформа Intel, они гарантируют эффективные машины. Эти выделенные серверы также имеют пропускную способность 500 Мбит / с, и наши анти-DDoS, чтобы обеспечить оптимальную защиту. Они идеально подходят для размещения своих веб — сайтов для ваших потребностей в области виртуализации или для профессиональных приложений.
www.ovh.com/fr/serveurs_dedies/rise/


приглашение вебинар
Вторника, 30 Апрель 2019
Узнайте, как удовлетворить потребности вашего бизнеса
Наш эксперт представит преимущества принять выделенные серверы, наши голые новости металла, наш тренерский и как выбрать серверы, чтобы убедиться, что вы «облако готово!»
www.ovh.com/fr/events/el1164-ovh-webinar-nouvelle-gamme-serveurs-dedies-au-service-vos-besoins-metier


новая архитектура
Облако Базы данных
Воспользуйтесь сверхбыстрым хранение
Мы предлагаем новый способ хранения высокой скорости, на основе технологии NVMe SSD для костей v управляемых баз данных. Получите производительность до 10 раз на операции чтения и записи, по сравнению с предыдущими предложениями, и по той же цене!
www.ovh.com/fr/cloud/cloud-databases/


решение Здоровье
Найти нас на выставке HIT
Давайте поговорим о вашей информационной системе здравоохранения (HIS)
С 21 по 23 мая 2019 года, мы даем вам встречу в Paris Expo на стенде Q79. Вместе с нашим партнером VMware, мы сообщим Вам о решениях принять для размещения SIS в совершенно безопасной инфраструктуре.
www.ovh.com/fr/events/el1190-hit-salon-professionnel-leader-lit-sante

Служба OVH Managed Kubernetes предлагает вам полностью управляемый кластер, в котором вы выбираете выбранные рабочие узлы в каталоге постоянной производительности виртуальной машины OVH Public Cloud. В настоящее время мы изучаем лучший способ добавить поддержку для работников графических процессоров и «голого металла» (без виртуализации), чтобы вы могли смешивать и подбирать виртуальные машины для еще более специализированных и мощных конфигураций. Помогите нам сформировать новые функции нашего предложения Kubernetes, ответив на короткий опрос (рассказывающий о ваших потребностях в оборудовании и программном обеспечении, ваших конкретных случаях использования ...), и у вас будет возможность получить доступ к закрытой бета-версии в течение лета.
labs.ovh.com/gpu-baremetal-kubernetes-nodes

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



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

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

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

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

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

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

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

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

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

Архитектура Prescience и рабочие процессы машинного обучения


По сути, платформа Prescience основана на технологиях с открытым исходным кодом, таких как Kubernetes для операций, Spark для обработки данных и Scikit-learn, XGBoost, Spark MLlib и Tensorflow для машинного обучения. Большая часть разработок Prescience заключалась в объединении этих технологий. Кроме того, все промежуточные выходы системы, такие как предварительно обработанные данные, этапы преобразования или модели, сериализуются с использованием технологий и стандартов с открытым исходным кодом. Это предотвращает привязку пользователей к Prescience в случае необходимости использования другой системы.

Взаимодействие пользователей с платформой Prescience стало возможным благодаря следующим элементам:

• пользовательский интерфейс
• клиент Python
• REST API

Давайте рассмотрим типичный рабочий процесс и дадим краткое описание различных компонентов…

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

CSV, отраслевой стандарт
Паркет, который довольно крутой (плюс автоматически документированный и сжатый)
Временной ряд, благодаря OVH Observability, работает на Warp10
Необработанные данные, предоставляемые каждым из этих источников, редко используются как есть в алгоритмах машинного обучения. Алгоритмы обычно ожидают, что числа будут работать. Поэтому первый шаг рабочего процесса выполняется компонентом Parser. Единственная задача Parser — обнаруживать типы и имена столбцов, в случае простых текстовых форматов, таких как CSV, хотя источники Parquet и Warp10 содержат схему, что делает этот шаг спорным. После ввода данных анализатор извлекает статистику, чтобы точно ее охарактеризовать. Полученные данные вместе со статистикой хранятся в нашей серверной памяти хранилища — Public Cloud Storage, работающей на OpenStack Swift.

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

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

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

Байесовская оптимизация


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

• Модель в холодном состоянии. Оптимизатор возвращает набор настроек по умолчанию для контроллера
• Контроллер распределяет начальные конфигурации по кластеру учащихся
• По завершении начальных конфигураций контроллер сохраняет результаты
• Оптимизатор запускает вторую итерацию и обучает модель на основе доступных данных.
• На основе полученной модели оптимизатор выводит лучших претендентов, которые можно попробовать. Рассматривается как их потенциальная эффективность, так и объем информации, который она предоставит для улучшения модели выбора.
• Контроллер распределяет новый набор конфигураций по кластеру и ждет новой информации, a.k.a вновь оцененных конфигураций. Конфигурации оцениваются с использованием K-кратной перекрестной проверки, чтобы избежать переоснащения.
• Когда доступна новая информация, запускается новая итерация оптимизации, и процесс начинается снова на шаге 4
• После предварительно определенного числа итераций оптимизация останавливается

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

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

Модель сервировки
На этом этапе модель обучается и экспортируется и готова к обслуживанию. Последний компонент платформы Prescience — это обслуживание Prescience. Это веб-сервис, который использует PMML и сохраненные модели и предоставляет REST API поверх. Поскольку преобразования экспортируются вместе с моделью, пользователь может запросить вновь развернутую модель, используя необработанные данные. Прогнозы теперь готовы к использованию в любом приложении.

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

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

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

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

Разработка Prescience проводится командой служб машинного обучения. MLS состоит из четырех инженеров машинного обучения: Маэль, Адриен, Рафаэль и я. Командой руководит Гийом, который помог мне спроектировать платформу. Кроме того, в команду входят два исследователя данных, Оливье и Клемент, которые занимались внутренними случаями использования и предоставили нам обратную связь, и, наконец, Лоран: студент CIFRE, работающий над многоцелевой оптикой.