Что происходит, когда сгорает диск в raid ?
Автоматически приходят системные уведомления от ОВХ
FailSpare event on /dev/md2:ns390332
Читать дальше →
FailSpare event on /dev/md2:ns390332
Читать дальше →
OVH привлек $ 327 млн
www.ovh.com/us/news/cp1662.to-accelerate-its-international-development-ovh-raises-327-million
Похоже будут создавать «облачка» в будущих годах.
Как выглядит Game линейка внутри
Вот такое там железо для начала
Добавляется особенность
Добавляется особенность
Протестировать сервер на 3 дня за 30 евро
www.ovh.ie/dedicated_servers/innovation-and-hardware/
Так же, у них все линейки можно купить на 1 неделю :)
Так же, у них все линейки можно купить на 1 неделю :)
Почему вы все еще управляете кластерами обработки данных?
Кластерные вычисления используются для распределения вычислительной нагрузки между группой компьютеров. Таким образом достигается более высокий уровень производительности и масштабируемости.
Apache Spark — это среда распределенных кластерных вычислений с открытым исходным кодом, которая намного быстрее предыдущей (Hadoop MapReduce). Это благодаря таким функциям, как обработка в памяти и ленивая оценка. Apache Spark — самый популярный инструмент в этой категории.
Механизм аналитики — это ведущая платформа для крупномасштабного SQL, пакетной обработки, потоковой обработки и машинного обучения. Для кодирования в Spark у вас есть возможность использовать разные языки программирования; включая Java, Scala, Python, R и SQL. Его можно запускать локально на одной машине или на кластере компьютеров для распределения задач.
Используя Apache Spark, вы можете обрабатывать свои данные на локальном компьютере или можете создать кластер для отправки любого количества заданий обработки.
Вы можете создать свой кластер с физическими компьютерами в локальной среде, с виртуальными машинами в хостинговой компании или с любым поставщиком облачных услуг. Имея собственный кластер, у вас будет возможность отправлять задания Spark в любое время.
Если вы обрабатываете огромный объем данных и ожидаете получить результаты в разумные сроки, вашего локального компьютера будет недостаточно. Вам нужен кластер компьютеров для разделения данных и обработки рабочих нагрузок — несколько компьютеров работают параллельно, чтобы ускорить выполнение задачи.
Однако создание и управление собственным кластером компьютеров — непростая задача. Вы столкнетесь с несколькими проблемами:
Создание кластера Apache Spark — сложная задача.
Во-первых, вам нужно создать кластер компьютеров и установить операционную систему, инструменты разработки (Python, Java, Scala) и т. Д.
Во-вторых, вам нужно выбрать версию Apache Spark и установить необходимые узлы (мастер и рабочие).
Наконец, вам необходимо соединить все эти узлы вместе, чтобы завершить работу над кластером Apache Spark.
В целом создание и настройка нового кластера Apache Spark может занять несколько часов.
Но если у вас есть собственный кластер, ваша работа еще далека от завершения. Ваш кластер работает хорошо? Каждый ли узел здоров?
Вот вторая проблема: справиться с болью управления кластером!
Вам нужно будет проверить состояние всех ваших узлов вручную или, желательно, установить инструменты мониторинга, которые сообщают о любых проблемах, с которыми могут столкнуться узлы.
Достаточно ли на узлах дискового пространства для новых задач? Одна из ключевых проблем, с которыми сталкиваются кластеры Apache Spark, заключается в том, что некоторые задачи записывают большой объем данных в локальное дисковое пространство узлов, не удаляя их. Дисковое пространство — распространенная проблема, и, как вы, возможно, знаете, нехватка дискового пространства исключает возможность выполнения большего количества задач.
Вам нужно запускать несколько заданий Spark одновременно? Иногда одно задание занимает все ресурсы ЦП и ОЗУ в вашем кластере и не позволяет другим заданиям запускаться и выполняться одновременно.
Это лишь некоторые из проблем, с которыми вы столкнетесь при работе с собственными кластерами.
Теперь о третьем испытании! Что может быть даже важнее, чем бесперебойная работа кластера?
Как вы уже догадались: безопасность. В конце концов, Apache Spark — это инструмент для обработки данных. И данные очень чувствительны.
Где в вашем кластере безопасность имеет наибольшее значение?
А как насчет связи между узлами? Связаны ли они с безопасным (и быстрым) соединением? У кого есть доступ к серверам вашего кластера?
Если вы создали свой кластер в облаке и работаете с конфиденциальными данными, вам необходимо решить эти проблемы путем защиты каждого узла и шифрования связи между ними.
Вот ваша четвертая задача: управление ожиданиями пользователей вашего кластера. В некоторых случаях это может быть менее сложной задачей, но не во всех.
Вы мало что можете сделать, чтобы изменить ожидания пользователей кластера, но вот типичный пример, который поможет вам подготовиться:
Ваши пользователи любят тестировать свои коды с разными версиями Apache Spark? Или им нужна последняя функция из последней ночной версии Spark?
Когда вы создаете кластер Apache Spark, вы должны выбрать одну версию Spark. Весь ваш кластер будет связан с ним, и это в одиночку. Это означает, что несколько версий не могут сосуществовать в одном кластере.
Итак, вам придется либо изменить версию Spark для всего кластера, либо создать еще один отдельный кластер. И, конечно же, если вы решите это сделать, вам нужно создать в кластере время простоя для внесения изменений.
И последний вызов: масштабирование!
Как получить максимальную выгоду от ресурсов кластера, за которые вы платите? Вы платите за свой кластер, но чувствуете, что используете его неэффективно? Ваш кластер слишком велик для ваших пользователей? Он работает, но в праздничные дни там нет рабочих мест?
Когда у вас есть обрабатывающий кластер — особенно если у вас много ценных ресурсов в кластере, за которые вы платите, — у вас всегда будет одна серьезная проблема: используется ли ваш кластер как можно более эффективно. Бывают случаи, когда некоторые ресурсы в вашем кластере простаивают, или когда вы выполняете только небольшие задания, которые не требуют количества ресурсов в вашем кластере. Масштабирование станет серьезной проблемой.
В OVHcloud мы создали новую службу данных под названием OVHcloud Data Processing (ODP) для решения всех проблем управления кластером, упомянутых выше.
Предположим, у вас есть некоторые данные для обработки, но у вас нет желания, времени, бюджета или навыков для решения этих проблем. Возможно, вы не хотите или не можете просить помощи у коллег или консультантов для создания кластера и управления им. Как вы все еще можете использовать Apache Spark? Здесь на помощь приходит служба ODP!
Используя ODP, вам нужно написать свой код Apache Spark, а все остальное сделает ODP. Он создаст одноразовый выделенный кластер Apache Spark в облаке для каждого задания всего за несколько секунд, а затем удалит весь кластер после завершения задания. Вы платите только за запрошенные ресурсы и только на время вычисления. Нет необходимости оплачивать часы работы облачных серверов, пока вы заняты установкой, настройкой кластера или даже отладкой и обновлением версии движка.
Когда вы отправляете свою работу, ODP создаст искровой кластер apache, посвященный этой работе, всего за несколько секунд. Этот кластер будет иметь количество ЦП и ОЗУ, а также количество рабочих, указанных в форме отправки задания. Все необходимое программное обеспечение будет установлено автоматически. Вам не нужно вообще беспокоиться о кластере, о том, как его установить, настроить или защитить. ODP сделает все это за вас.
Когда вы отправляете свою работу, управление и мониторинг кластера настраиваются и обрабатываются ODP. Все механизмы и инструменты ведения журналов и мониторинга будут установлены автоматически. У вас будет панель управления Grafana для мониторинга различных параметров и ресурсов вашей работы, а также у вас будет доступ к официальной панели инструментов Apache Spark.
Вам не нужно беспокоиться об очистке локального диска каждого узла, потому что каждое задание будет начинаться со свежих ресурсов. Следовательно, одно задание не может отложить другое задание, поскольку каждое задание имеет новые выделенные ресурсы.
ODP также позаботится о безопасности и конфиденциальности вашего кластера. Во-первых, все коммуникации между узлами Spark зашифрованы. Во-вторых, ни один из узлов вашей работы не доступен извне. ODP позволяет открывать только ограниченные порты для вашего кластера, так что вы по-прежнему можете загружать или передавать свои данные.
Когда дело доходит до использования нескольких версий Spark в одном кластере, ODP предлагает решение. Поскольку каждое задание обладает собственными выделенными ресурсами, каждое задание может использовать любую версию, которая в настоящее время поддерживается службой, независимо от любого другого задания, выполняющегося в то же время. При отправке задания Apache Spark через ODP вы сначала выбираете версию Apache Spark, которую хотите использовать. Когда сообщество Apache Spark выпустит новую версию, она скоро станет доступной в ODP, и вы также сможете отправить другое задание с новой версией Spark. Это означает, что вам больше не нужно постоянно обновлять версию Spark для всего кластера.
Каждый раз, когда вы отправляете задание, вам нужно будет точно определить, сколько ресурсов и рабочих вы хотите использовать для этого задания. Как было сказано ранее, каждое задание имеет свои собственные выделенные ресурсы, поэтому вы сможете выполнять небольшие задания вместе с гораздо более крупными. Такая гибкость означает, что вам никогда не придется беспокоиться о простаивающем кластере. Вы платите за ресурсы, которые используете, когда вы их используете.
Если вы хотите попробовать ODP, вы можете проверить: www.ovhcloud.com/en/public-cloud/data-processing/ или вы можете легко создать учетную запись на www.ovhcloud.com и выбрать « обработка данных »в разделе публичного облака. Также можно задать вопросы непосредственно от команды разработчиков в общедоступном канале Gitter ODP gitter.im/ovh/data-processing.
С ODP проблемы, связанные с запуском кластера Apache Spark, устраняются или упрощаются (мы по-прежнему мало что можем поделать с ожиданиями пользователей!). Вам не нужно беспокоиться о нехватке ресурсов, необходимых для обработки ваших данных, или необходимо создать, установить и управлять собственным кластером.
Сосредоточьтесь на своем алгоритме обработки, а остальное сделает ODP.
Apache Spark — это среда распределенных кластерных вычислений с открытым исходным кодом, которая намного быстрее предыдущей (Hadoop MapReduce). Это благодаря таким функциям, как обработка в памяти и ленивая оценка. Apache Spark — самый популярный инструмент в этой категории.
Механизм аналитики — это ведущая платформа для крупномасштабного SQL, пакетной обработки, потоковой обработки и машинного обучения. Для кодирования в Spark у вас есть возможность использовать разные языки программирования; включая Java, Scala, Python, R и SQL. Его можно запускать локально на одной машине или на кластере компьютеров для распределения задач.
Используя Apache Spark, вы можете обрабатывать свои данные на локальном компьютере или можете создать кластер для отправки любого количества заданий обработки.
Вы можете создать свой кластер с физическими компьютерами в локальной среде, с виртуальными машинами в хостинговой компании или с любым поставщиком облачных услуг. Имея собственный кластер, у вас будет возможность отправлять задания Spark в любое время.
Проблемы управления кластером
Если вы обрабатываете огромный объем данных и ожидаете получить результаты в разумные сроки, вашего локального компьютера будет недостаточно. Вам нужен кластер компьютеров для разделения данных и обработки рабочих нагрузок — несколько компьютеров работают параллельно, чтобы ускорить выполнение задачи.
Однако создание и управление собственным кластером компьютеров — непростая задача. Вы столкнетесь с несколькими проблемами:
Создание кластера
Создание кластера Apache Spark — сложная задача.
Во-первых, вам нужно создать кластер компьютеров и установить операционную систему, инструменты разработки (Python, Java, Scala) и т. Д.
Во-вторых, вам нужно выбрать версию Apache Spark и установить необходимые узлы (мастер и рабочие).
Наконец, вам необходимо соединить все эти узлы вместе, чтобы завершить работу над кластером Apache Spark.
В целом создание и настройка нового кластера Apache Spark может занять несколько часов.
Управление кластером
Но если у вас есть собственный кластер, ваша работа еще далека от завершения. Ваш кластер работает хорошо? Каждый ли узел здоров?
Вот вторая проблема: справиться с болью управления кластером!
Вам нужно будет проверить состояние всех ваших узлов вручную или, желательно, установить инструменты мониторинга, которые сообщают о любых проблемах, с которыми могут столкнуться узлы.
Достаточно ли на узлах дискового пространства для новых задач? Одна из ключевых проблем, с которыми сталкиваются кластеры Apache Spark, заключается в том, что некоторые задачи записывают большой объем данных в локальное дисковое пространство узлов, не удаляя их. Дисковое пространство — распространенная проблема, и, как вы, возможно, знаете, нехватка дискового пространства исключает возможность выполнения большего количества задач.
Вам нужно запускать несколько заданий Spark одновременно? Иногда одно задание занимает все ресурсы ЦП и ОЗУ в вашем кластере и не позволяет другим заданиям запускаться и выполняться одновременно.
Это лишь некоторые из проблем, с которыми вы столкнетесь при работе с собственными кластерами.
Безопасность кластера
Теперь о третьем испытании! Что может быть даже важнее, чем бесперебойная работа кластера?
Как вы уже догадались: безопасность. В конце концов, Apache Spark — это инструмент для обработки данных. И данные очень чувствительны.
Где в вашем кластере безопасность имеет наибольшее значение?
А как насчет связи между узлами? Связаны ли они с безопасным (и быстрым) соединением? У кого есть доступ к серверам вашего кластера?
Если вы создали свой кластер в облаке и работаете с конфиденциальными данными, вам необходимо решить эти проблемы путем защиты каждого узла и шифрования связи между ними.
Версия Spark
Вот ваша четвертая задача: управление ожиданиями пользователей вашего кластера. В некоторых случаях это может быть менее сложной задачей, но не во всех.
Вы мало что можете сделать, чтобы изменить ожидания пользователей кластера, но вот типичный пример, который поможет вам подготовиться:
Ваши пользователи любят тестировать свои коды с разными версиями Apache Spark? Или им нужна последняя функция из последней ночной версии Spark?
Когда вы создаете кластер Apache Spark, вы должны выбрать одну версию Spark. Весь ваш кластер будет связан с ним, и это в одиночку. Это означает, что несколько версий не могут сосуществовать в одном кластере.
Итак, вам придется либо изменить версию Spark для всего кластера, либо создать еще один отдельный кластер. И, конечно же, если вы решите это сделать, вам нужно создать в кластере время простоя для внесения изменений.
Эффективность кластера
И последний вызов: масштабирование!
Как получить максимальную выгоду от ресурсов кластера, за которые вы платите? Вы платите за свой кластер, но чувствуете, что используете его неэффективно? Ваш кластер слишком велик для ваших пользователей? Он работает, но в праздничные дни там нет рабочих мест?
Когда у вас есть обрабатывающий кластер — особенно если у вас много ценных ресурсов в кластере, за которые вы платите, — у вас всегда будет одна серьезная проблема: используется ли ваш кластер как можно более эффективно. Бывают случаи, когда некоторые ресурсы в вашем кластере простаивают, или когда вы выполняете только небольшие задания, которые не требуют количества ресурсов в вашем кластере. Масштабирование станет серьезной проблемой.
Решение OVHcloud для обработки данных (ODP)
В OVHcloud мы создали новую службу данных под названием OVHcloud Data Processing (ODP) для решения всех проблем управления кластером, упомянутых выше.
Предположим, у вас есть некоторые данные для обработки, но у вас нет желания, времени, бюджета или навыков для решения этих проблем. Возможно, вы не хотите или не можете просить помощи у коллег или консультантов для создания кластера и управления им. Как вы все еще можете использовать Apache Spark? Здесь на помощь приходит служба ODP!
Используя ODP, вам нужно написать свой код Apache Spark, а все остальное сделает ODP. Он создаст одноразовый выделенный кластер Apache Spark в облаке для каждого задания всего за несколько секунд, а затем удалит весь кластер после завершения задания. Вы платите только за запрошенные ресурсы и только на время вычисления. Нет необходимости оплачивать часы работы облачных серверов, пока вы заняты установкой, настройкой кластера или даже отладкой и обновлением версии движка.
Создание кластера ODP
Когда вы отправляете свою работу, ODP создаст искровой кластер apache, посвященный этой работе, всего за несколько секунд. Этот кластер будет иметь количество ЦП и ОЗУ, а также количество рабочих, указанных в форме отправки задания. Все необходимое программное обеспечение будет установлено автоматически. Вам не нужно вообще беспокоиться о кластере, о том, как его установить, настроить или защитить. ODP сделает все это за вас.
Управление кластером ODP
Когда вы отправляете свою работу, управление и мониторинг кластера настраиваются и обрабатываются ODP. Все механизмы и инструменты ведения журналов и мониторинга будут установлены автоматически. У вас будет панель управления Grafana для мониторинга различных параметров и ресурсов вашей работы, а также у вас будет доступ к официальной панели инструментов Apache Spark.
Вам не нужно беспокоиться об очистке локального диска каждого узла, потому что каждое задание будет начинаться со свежих ресурсов. Следовательно, одно задание не может отложить другое задание, поскольку каждое задание имеет новые выделенные ресурсы.
Безопасность кластера ODP
ODP также позаботится о безопасности и конфиденциальности вашего кластера. Во-первых, все коммуникации между узлами Spark зашифрованы. Во-вторых, ни один из узлов вашей работы не доступен извне. ODP позволяет открывать только ограниченные порты для вашего кластера, так что вы по-прежнему можете загружать или передавать свои данные.
Версия ODP Cluster Spark
Когда дело доходит до использования нескольких версий Spark в одном кластере, ODP предлагает решение. Поскольку каждое задание обладает собственными выделенными ресурсами, каждое задание может использовать любую версию, которая в настоящее время поддерживается службой, независимо от любого другого задания, выполняющегося в то же время. При отправке задания Apache Spark через ODP вы сначала выбираете версию Apache Spark, которую хотите использовать. Когда сообщество Apache Spark выпустит новую версию, она скоро станет доступной в ODP, и вы также сможете отправить другое задание с новой версией Spark. Это означает, что вам больше не нужно постоянно обновлять версию Spark для всего кластера.
Эффективность кластера ODP
Каждый раз, когда вы отправляете задание, вам нужно будет точно определить, сколько ресурсов и рабочих вы хотите использовать для этого задания. Как было сказано ранее, каждое задание имеет свои собственные выделенные ресурсы, поэтому вы сможете выполнять небольшие задания вместе с гораздо более крупными. Такая гибкость означает, что вам никогда не придется беспокоиться о простаивающем кластере. Вы платите за ресурсы, которые используете, когда вы их используете.
Как начать?
Если вы хотите попробовать ODP, вы можете проверить: www.ovhcloud.com/en/public-cloud/data-processing/ или вы можете легко создать учетную запись на www.ovhcloud.com и выбрать « обработка данных »в разделе публичного облака. Также можно задать вопросы непосредственно от команды разработчиков в общедоступном канале Gitter ODP gitter.im/ovh/data-processing.
Вывод
С ODP проблемы, связанные с запуском кластера Apache Spark, устраняются или упрощаются (мы по-прежнему мало что можем поделать с ожиданиями пользователей!). Вам не нужно беспокоиться о нехватке ресурсов, необходимых для обработки ваших данных, или необходимо создать, установить и управлять собственным кластером.
Сосредоточьтесь на своем алгоритме обработки, а остальное сделает ODP.
К демократизации премиального Bare Metal Cloud
Инновации на всех уровнях — ключевая часть идентичности OVHcloud. Наша сила заключается в том, чтобы постоянно ставить перед собой задачу лучше отвечать на вызовы наших клиентов. Новые функции, которые ждут их в Premium Bare Metal Cloud, являются результатом нашего желания вносить изменения и внимательно прислушиваться к потребностям наших клиентов. Но чтобы бросить вызов этому рынку, нам нужно было разработать прочную стратегию, предполагающую радикальные внутренние преобразования.
OVHcloud предлагает широкий портфель облачных продуктов и решений для четырех вселенных (веб-облако, Bare Metal Cloud, публичное облако и размещенное частное облако). Облако, которое мы доставляем, всегда проектируется и разрабатывается с учетом потребностей наших клиентов, и мы всегда стараемся понять их бизнес, чтобы лучше понимать их проблемы.
Мы начали обсуждение рынка Premium Bare Metal Cloud еще в 2016 году. В то время мы получили отзывы от нескольких клиентов относительно нашего ценового позиционирования на этот конкретный диапазон мощных серверов, которые соответствуют очень высоким требованиям к хранению. Наши изделия из чистого металла были слишком дорогими по сравнению с тем, за что они были готовы платить. Затем мы работали, в частности, с двумя клиентами. Поскольку они были готовы разделить с нами свои расходы, мы смогли спроецировать их экономическую модель на нашу бизнес-модель. Эти два клиента размещали свои собственные услуги через колокацию, без круглосуточной поддержки местной команды, и у них была небольшая интернет-сеть. Они инвестировали в свои собственные серверы, рассчитав свои цены за 5-летний период. Как только мы выполнили этот анализ, мы поняли, что можем предложить им эти мощные серверы по более низкой, гораздо более конкурентоспособной цене. Но для решения этой задачи нам потребуется проделать серьезную работу, которая, вероятно, займет несколько лет.
Наш первый проект включал полную реструктуризацию математической основы нашей бизнес-модели, которую мы использовали для расчета наших цен. Мы начали это в 2017 году, и это заняло три года.
В первый год мы реорганизовали компанию и создали Подразделения. Каждое из Подразделений — это своего рода малый бизнес в OVHcloud. Он способствует нашему коллективному успеху, управляя обязанностями, соответствующими его опыту, и вносит свой вклад в наш стратегический план. Его возглавляет руководитель подразделения, и у него есть план действий.
На второй год мы создали отчеты о прибылях и убытках для каждого подразделения, чтобы они могли моделировать проекты в своей дорожной карте с помощью реальных затрат по сравнению с ожидаемыми выгодами. Чтобы предоставить им эту аналитическую основу, нам пришлось реструктурировать наши финансы. Это включало разделение общих прибылей и убытков компании на несколько микро прибылей и убытков. Это означало, что мы могли распределить затраты по нужным единицам и создать внутренний рабочий процесс выставления счетов. Затем мы смогли рассчитать доход каждой единицы, сверяя доход, полученный от выставления счетов клиентам, с доходом, полученным от внутреннего возвратного платежа для других единиц, при интеграции связанных затрат (команды, лицензии и т. Д.). После этого каждое подразделение выпустило маржу.
На третий год мы связали все эти показатели с финансовой отчетностью и сделали их KPI доступными для подразделений в режиме реального времени. Целью развертывания этих финансовых панелей мониторинга было лучшее управление эффективностью компании, но, что более важно, расширение возможностей команд. Согласовав инструменты финансового мониторинга с новой организацией, подразделения смогли составить более надежные прогнозы, лучше прогнозировать риски и лучше прогнозировать свои инвестиции и расходы на заработную плату. Для компании это был также способ обеспечить, чтобы каждый проект создавал ценность для OVHcloud, а также продолжал обеспечивать, чтобы наше развитие оставалось прибыльным, сбалансированным и устойчивым для нашей конкурентоспособности и независимости. С точки зрения потребителя, такая культура сознательного отношения к затратам в основном приведет к еще большему снижению цен.
В цифровом мире экономика также полагается на два сдвига: сокращение постоянных затрат (за счет увеличения объема продаж) и сокращение переменных затрат (за счет автоматизации задач с помощью программного обеспечения, роботизированных систем и искусственного интеллекта). Массовые вложения в автоматизацию — серьезная проблема для такого поставщика облачных услуг, как мы. Благодаря огромным инвестициям мы повысили качество (меньше ошибок, упростили процедуры, ускорили предоставление услуг) и смогли выполнять больше операций в день без увеличения размера Подразделений. Это означало, что Подразделениям больше не приходилось выполнять повторяющиеся задачи, и вместо этого они могли сосредоточиться на добавленной стоимости, которую они должны были принести нашим клиентам. Мы делаем это, следуя принципам BFLNT, которые я описал в предыдущем сообщении блога.
Наконец, это сочетание операционной и финансовой эффективности, а также уровня автоматизации в подразделениях помогает нам разрабатывать все более рентабельные решения и обеспечивать нашим клиентам еще большее соотношение цены и качества.
Чтобы поддержать свои амбиции, компании, которые несут высокие капитальные затраты, тратя большие суммы на инвестиции в недвижимость или оборудование, никогда не получают высокой оценки на финансовом рынке. Чтобы обезопасить эти крупные инвестиции, они часто используют сложные — даже непрозрачные — финансовые схемы, которые воспринимаются как слишком большой риск.
Для OVHcloud эти большие суммы являются основой нашей действенной модели — инвестирования в строительство и улучшение наших центров обработки данных, обновление производственного оборудования и приобретение новых производственных помещений. Наша бизнес-модель полностью демистифицирует эти масштабные инвестиции, поскольку она изначально обеспечивает возврат инвестиций. Наша способность инвестировать за счет повышения прибыльности позволила нам привлечь капитал в 2016 году (279 миллионов долларов от KKR и TowerBrook) и даже привлечь долг в конце 2019 года (976 миллионов долларов). CAPEX — это наш основной вектор создания стоимости. Мы должны постоянно инвестировать в будущие инновации и инфраструктуру, чтобы обеспечить нашу устойчивость и конкурентоспособность.
Благодаря всей работе, которую мы проделали за последние три года, мы также смогли внести огромные изменения в нашу бизнес-модель. С помощью сложного анализа, который мы получили, теперь мы можем рассчитать цену сервера на основе нескольких переменных, таких как время выполнения обязательств, объем заказа, тип сервера и инвестиционные затраты на инфраструктуру и сам бизнес. Эта новая финансовая модель внутри компании называется «Джекпот», поскольку любое сокращение наших капитальных или операционных расходов (операционных расходов), безусловно, снизит цену для наших клиентов. И в случае, если мы не предоставляем ожидаемую цену — а это означает, что наши решения CAPEX или OPEX недостаточно оптимизированы — мы всегда ищем, где мы можем внедрять инновации и на каком уровне мы должны нарушить. Потому что, если мы сокращаем наши затраты, мы снижаем наши цены, а не увеличиваем маржу.
Наша цель — стать мировым экспертом в Premium Bare Metal Cloud. Мы хотим встряхнуть рынок с 350 до 2500 долларов в месяц (для серверов премиум-класса высшего класса) и стать эталоном, как мы уже делаем для серверов начального и среднего уровня. Клиенты, которым нужна максимальная мощность и мощность, начнут замечать первые результаты нашей стратегии. Чтобы лучше выполнять свои задачи, к концу 2020 года наши публичные цены упадут. Но мы сохраним такую же высокую производительность. В дополнение к нашей промышленной модели, которая уникальна в плане полного контроля и позволяет нам постоянно адаптироваться, в последние месяцы именно наша новая бизнес-модель «Джекпот» помогла нам пойти еще дальше. И на основе этой новой модели мы рассмотрели все — серверы, сеть, энергоснабжение и водяное охлаждение. Сейчас больше, чем когда-либо.
Наша новая финансовая модель позволяет нам более точно отслеживать жизненный цикл продуктов и пересматривать наши модели обязательств. До конца года мы предложим более конкурентоспособные цены по долгосрочным обязательствам. В дополнение к уже доступным моделям ежемесячной оплаты, то есть без обязательств или с обязательством на 6, 12 или 24 месяца, мы также предложим планы обязательств на 3, 4 или 5 лет. Наши цены будут еще лучше для клиентов, которые могут использовать как объем (3 или 12 стоек с 48 или 96 серверами), так и продолжительность (3, 4 или 5 лет). В будущем наши клиенты также смогут получать почасовые расценки на чистый металл с посекундной оплатой.
Наконец, для клиентов, которым нужно много серверных стоек и которые не хотят управлять своей инфраструктурой, мы уже можем предоставить частные пространства в наших центрах обработки данных с 12, 24 или 48 стойками *, оборудованными камерами, значками и журналами. Этот вариант использования удовлетворяет потребности не только клиентов Bare Metal Cloud, но также клиентов Public Cloud и Hosted Private Cloud в режиме «частного региона». Начиная со 100 стоек, мы можем поставить настоящие частные центры обработки данных в зданиях третьих сторон (в помещениях клиентов) *, где бы они ни находились. Это значительно снижает их затраты. В этих центрах обработки данных мы применяем наш промышленный и технический опыт, в том числе нашу эксклюзивную технологию водяного охлаждения, и все наши аппаратные инновации, включая самые последние технологии на рынке. Мы также управляем всеми уровнями программного обеспечения и их жизненными циклами.
Цель этого сообщения в блоге — не подробное описание наших будущих предложений, а объяснение того долгого пути, который заставил нас снизить цены на Premium Bare Metal Cloud. Но если вы подписаны на мою учетную запись в Twitter ( @olesovhcom ), вы, возможно, видели некоторые их превью, потому что я регулярно делюсь информацией о нашей работе.
Всего OVHcloud скоро предложит около 300 моделей Bare Metal Cloud! Это очень широкий диапазон, и наши маркетинговые команды взяли на себя впечатляющую задачу, предложив упрощенный просмотр, чтобы вы могли найти именно то, что вам нужно. В конце октября 2020 года название меню изменится с «Сервер» на «Bare Metal Cloud». Это будет первый шаг в переходе, который состоится в ближайшие месяцы, с гораздо более ориентированным на использование подходом, таким как виртуализация, хранение, глубокое обучение, базы данных и т. Д. Цель состоит в том, чтобы упростить ваше путешествие, и поможет вам легко выбрать модели, наиболее соответствующие вашим потребностям.
Как внутренние клиенты, наши три других облачных юниверса (веб-облако, общедоступное облако, размещенное частное облако), которые все полагаются на наши инфраструктуры Bare Metal Cloud, также получат выгоду от этих инноваций и новых цен. Прежде чем оказывать такое глобальное влияние, нам нужно было изучить основы облака. Ожидайте отличных анонсов в 2020-2021 годах!
Чтобы узнать больше, отправляйтесь на OVHcloud #EcosystemExperience, наше новое виртуальное мероприятие, которое состоится 3, 4 и 5 ноября.
Мы докажем вам конкретными словами, что, нестандартно мыслящие через разрушение и создавая прочную экосистему, мы ежедневно помогаем сделать OVHcloud подлинной альтернативой в облачной индустрии.
Начало революции
OVHcloud предлагает широкий портфель облачных продуктов и решений для четырех вселенных (веб-облако, Bare Metal Cloud, публичное облако и размещенное частное облако). Облако, которое мы доставляем, всегда проектируется и разрабатывается с учетом потребностей наших клиентов, и мы всегда стараемся понять их бизнес, чтобы лучше понимать их проблемы.
Мы начали обсуждение рынка Premium Bare Metal Cloud еще в 2016 году. В то время мы получили отзывы от нескольких клиентов относительно нашего ценового позиционирования на этот конкретный диапазон мощных серверов, которые соответствуют очень высоким требованиям к хранению. Наши изделия из чистого металла были слишком дорогими по сравнению с тем, за что они были готовы платить. Затем мы работали, в частности, с двумя клиентами. Поскольку они были готовы разделить с нами свои расходы, мы смогли спроецировать их экономическую модель на нашу бизнес-модель. Эти два клиента размещали свои собственные услуги через колокацию, без круглосуточной поддержки местной команды, и у них была небольшая интернет-сеть. Они инвестировали в свои собственные серверы, рассчитав свои цены за 5-летний период. Как только мы выполнили этот анализ, мы поняли, что можем предложить им эти мощные серверы по более низкой, гораздо более конкурентоспособной цене. Но для решения этой задачи нам потребуется проделать серьезную работу, которая, вероятно, займет несколько лет.
Новая бизнес-модель
Наш первый проект включал полную реструктуризацию математической основы нашей бизнес-модели, которую мы использовали для расчета наших цен. Мы начали это в 2017 году, и это заняло три года.
В первый год мы реорганизовали компанию и создали Подразделения. Каждое из Подразделений — это своего рода малый бизнес в OVHcloud. Он способствует нашему коллективному успеху, управляя обязанностями, соответствующими его опыту, и вносит свой вклад в наш стратегический план. Его возглавляет руководитель подразделения, и у него есть план действий.
На второй год мы создали отчеты о прибылях и убытках для каждого подразделения, чтобы они могли моделировать проекты в своей дорожной карте с помощью реальных затрат по сравнению с ожидаемыми выгодами. Чтобы предоставить им эту аналитическую основу, нам пришлось реструктурировать наши финансы. Это включало разделение общих прибылей и убытков компании на несколько микро прибылей и убытков. Это означало, что мы могли распределить затраты по нужным единицам и создать внутренний рабочий процесс выставления счетов. Затем мы смогли рассчитать доход каждой единицы, сверяя доход, полученный от выставления счетов клиентам, с доходом, полученным от внутреннего возвратного платежа для других единиц, при интеграции связанных затрат (команды, лицензии и т. Д.). После этого каждое подразделение выпустило маржу.
На третий год мы связали все эти показатели с финансовой отчетностью и сделали их KPI доступными для подразделений в режиме реального времени. Целью развертывания этих финансовых панелей мониторинга было лучшее управление эффективностью компании, но, что более важно, расширение возможностей команд. Согласовав инструменты финансового мониторинга с новой организацией, подразделения смогли составить более надежные прогнозы, лучше прогнозировать риски и лучше прогнозировать свои инвестиции и расходы на заработную плату. Для компании это был также способ обеспечить, чтобы каждый проект создавал ценность для OVHcloud, а также продолжал обеспечивать, чтобы наше развитие оставалось прибыльным, сбалансированным и устойчивым для нашей конкурентоспособности и независимости. С точки зрения потребителя, такая культура сознательного отношения к затратам в основном приведет к еще большему снижению цен.
В цифровом мире экономика также полагается на два сдвига: сокращение постоянных затрат (за счет увеличения объема продаж) и сокращение переменных затрат (за счет автоматизации задач с помощью программного обеспечения, роботизированных систем и искусственного интеллекта). Массовые вложения в автоматизацию — серьезная проблема для такого поставщика облачных услуг, как мы. Благодаря огромным инвестициям мы повысили качество (меньше ошибок, упростили процедуры, ускорили предоставление услуг) и смогли выполнять больше операций в день без увеличения размера Подразделений. Это означало, что Подразделениям больше не приходилось выполнять повторяющиеся задачи, и вместо этого они могли сосредоточиться на добавленной стоимости, которую они должны были принести нашим клиентам. Мы делаем это, следуя принципам BFLNT, которые я описал в предыдущем сообщении блога.
Наконец, это сочетание операционной и финансовой эффективности, а также уровня автоматизации в подразделениях помогает нам разрабатывать все более рентабельные решения и обеспечивать нашим клиентам еще большее соотношение цены и качества.
CAPEX — это ценность
Чтобы поддержать свои амбиции, компании, которые несут высокие капитальные затраты, тратя большие суммы на инвестиции в недвижимость или оборудование, никогда не получают высокой оценки на финансовом рынке. Чтобы обезопасить эти крупные инвестиции, они часто используют сложные — даже непрозрачные — финансовые схемы, которые воспринимаются как слишком большой риск.
Для OVHcloud эти большие суммы являются основой нашей действенной модели — инвестирования в строительство и улучшение наших центров обработки данных, обновление производственного оборудования и приобретение новых производственных помещений. Наша бизнес-модель полностью демистифицирует эти масштабные инвестиции, поскольку она изначально обеспечивает возврат инвестиций. Наша способность инвестировать за счет повышения прибыльности позволила нам привлечь капитал в 2016 году (279 миллионов долларов от KKR и TowerBrook) и даже привлечь долг в конце 2019 года (976 миллионов долларов). CAPEX — это наш основной вектор создания стоимости. Мы должны постоянно инвестировать в будущие инновации и инфраструктуру, чтобы обеспечить нашу устойчивость и конкурентоспособность.
Благодаря всей работе, которую мы проделали за последние три года, мы также смогли внести огромные изменения в нашу бизнес-модель. С помощью сложного анализа, который мы получили, теперь мы можем рассчитать цену сервера на основе нескольких переменных, таких как время выполнения обязательств, объем заказа, тип сервера и инвестиционные затраты на инфраструктуру и сам бизнес. Эта новая финансовая модель внутри компании называется «Джекпот», поскольку любое сокращение наших капитальных или операционных расходов (операционных расходов), безусловно, снизит цену для наших клиентов. И в случае, если мы не предоставляем ожидаемую цену — а это означает, что наши решения CAPEX или OPEX недостаточно оптимизированы — мы всегда ищем, где мы можем внедрять инновации и на каком уровне мы должны нарушить. Потому что, если мы сокращаем наши затраты, мы снижаем наши цены, а не увеличиваем маржу.
Новые методы использования ресурсов
Наша цель — стать мировым экспертом в Premium Bare Metal Cloud. Мы хотим встряхнуть рынок с 350 до 2500 долларов в месяц (для серверов премиум-класса высшего класса) и стать эталоном, как мы уже делаем для серверов начального и среднего уровня. Клиенты, которым нужна максимальная мощность и мощность, начнут замечать первые результаты нашей стратегии. Чтобы лучше выполнять свои задачи, к концу 2020 года наши публичные цены упадут. Но мы сохраним такую же высокую производительность. В дополнение к нашей промышленной модели, которая уникальна в плане полного контроля и позволяет нам постоянно адаптироваться, в последние месяцы именно наша новая бизнес-модель «Джекпот» помогла нам пойти еще дальше. И на основе этой новой модели мы рассмотрели все — серверы, сеть, энергоснабжение и водяное охлаждение. Сейчас больше, чем когда-либо.
Наша новая финансовая модель позволяет нам более точно отслеживать жизненный цикл продуктов и пересматривать наши модели обязательств. До конца года мы предложим более конкурентоспособные цены по долгосрочным обязательствам. В дополнение к уже доступным моделям ежемесячной оплаты, то есть без обязательств или с обязательством на 6, 12 или 24 месяца, мы также предложим планы обязательств на 3, 4 или 5 лет. Наши цены будут еще лучше для клиентов, которые могут использовать как объем (3 или 12 стоек с 48 или 96 серверами), так и продолжительность (3, 4 или 5 лет). В будущем наши клиенты также смогут получать почасовые расценки на чистый металл с посекундной оплатой.
Наконец, для клиентов, которым нужно много серверных стоек и которые не хотят управлять своей инфраструктурой, мы уже можем предоставить частные пространства в наших центрах обработки данных с 12, 24 или 48 стойками *, оборудованными камерами, значками и журналами. Этот вариант использования удовлетворяет потребности не только клиентов Bare Metal Cloud, но также клиентов Public Cloud и Hosted Private Cloud в режиме «частного региона». Начиная со 100 стоек, мы можем поставить настоящие частные центры обработки данных в зданиях третьих сторон (в помещениях клиентов) *, где бы они ни находились. Это значительно снижает их затраты. В этих центрах обработки данных мы применяем наш промышленный и технический опыт, в том числе нашу эксклюзивную технологию водяного охлаждения, и все наши аппаратные инновации, включая самые последние технологии на рынке. Мы также управляем всеми уровнями программного обеспечения и их жизненными циклами.
Глобальное воздействие
Цель этого сообщения в блоге — не подробное описание наших будущих предложений, а объяснение того долгого пути, который заставил нас снизить цены на Premium Bare Metal Cloud. Но если вы подписаны на мою учетную запись в Twitter ( @olesovhcom ), вы, возможно, видели некоторые их превью, потому что я регулярно делюсь информацией о нашей работе.
Всего OVHcloud скоро предложит около 300 моделей Bare Metal Cloud! Это очень широкий диапазон, и наши маркетинговые команды взяли на себя впечатляющую задачу, предложив упрощенный просмотр, чтобы вы могли найти именно то, что вам нужно. В конце октября 2020 года название меню изменится с «Сервер» на «Bare Metal Cloud». Это будет первый шаг в переходе, который состоится в ближайшие месяцы, с гораздо более ориентированным на использование подходом, таким как виртуализация, хранение, глубокое обучение, базы данных и т. Д. Цель состоит в том, чтобы упростить ваше путешествие, и поможет вам легко выбрать модели, наиболее соответствующие вашим потребностям.
Как внутренние клиенты, наши три других облачных юниверса (веб-облако, общедоступное облако, размещенное частное облако), которые все полагаются на наши инфраструктуры Bare Metal Cloud, также получат выгоду от этих инноваций и новых цен. Прежде чем оказывать такое глобальное влияние, нам нужно было изучить основы облака. Ожидайте отличных анонсов в 2020-2021 годах!
Чтобы узнать больше, отправляйтесь на OVHcloud #EcosystemExperience, наше новое виртуальное мероприятие, которое состоится 3, 4 и 5 ноября.
Мы докажем вам конкретными словами, что, нестандартно мыслящие через разрушение и создавая прочную экосистему, мы ежедневно помогаем сделать OVHcloud подлинной альтернативой в облачной индустрии.
Повышение качества данных с Apache Spark
Сегодня мы предлагаем вам гостевой пост от Хьюберта Стефани, директора по инновациям и соучредителя Novagen Conseil.
Как консультанты по данным и активные пользователи Apache Spark, для нас большая честь стать первыми последователями OVHcloudData Processing. В качестве первого варианта использования для тестирования этого предложения мы выбрали наш процесс оценки качества.
Как консалтинговая компания, базирующаяся в Париже, мы разрабатываем комплексные и инновационные стратегии обработки данных для наших крупных корпоративных и государственных клиентов: ведущих банков состояния, государственных органов, розничных торговцев, индустрии моды, лидеров транспорта и т. Д. Мы предлагаем им крупномасштабную бизнес-аналитику, озеро данных создание и управление, бизнес-инновации с наукой о данных. В нашей лаборатории данных мы выбираем лучшую в своем классе технологию и создаем то, что мы называем «ускорителями», то есть готовые к развертыванию или настраиваемые активы данных.
Когда дело доходит до выбора нового технологического решения, у нас есть следующий контрольный список:
Около месяца назад Бастьен Вердебаут, менеджер по продуктам OVHcloud по данным и ИИ, обратился к нам с просьбой протестировать свой новый продукт OVHcloud Data Processing, созданный на основе Apache Spark. Конечно, да!
Одна из причин, по которой мы так стремились открыть эту обработку данных в качестве сервисного решения, заключалась в том, что мы широко используем Apache Spark; это наш швейцарский армейский нож для обработки данных.
Мы постоянно разрабатываем программные активы на базе Apache Spark для решения повторяющихся проблем, таких как:
Мы рассмотрели следующие характеристики обработки данных OVHCloud :
Эти характеристики побудили нас выбрать наш процесс оценки качества в качестве идеального варианта использования, который требует как интерактивности, так и настраиваемых вычислительных ресурсов для обеспечения качественных ключевых показателей эффективности с помощью процессов Spark.
Соответствующая команда, сгенерированная нашим программным обеспечением:
У нас есть команда, которая очень похожа на обычную искру-отправку, за исключением пути к jar, который требует, чтобы двоичный файл находился в корзине объектного хранилища, к которой мы обращаемся с быстрой спецификацией URL-адреса. (NB: эта команда могла быть создана с помощью вызова API обработки данных OVHCloud).
Начиная с этого момента, мы можем теперь точно настроить наш портфель процессов и поиграть с распределением различной мощности с небольшими ограничениями (за исключением квот, назначаемых любому проекту общедоступного облака).
В конце концов, для настройки и посмертного анализа работы мы можем воспользоваться сохраненными файлами журнала. Примечательно, что OVHcloud Data Processing предлагает отображение журналов заданий в реальном времени, что очень удобно и обеспечивает дополнительный контроль через информационные панели Grafana.
Это первый, но важный тест обработки данных OVHcloud; На данный момент он отлично подходит для варианта использования процесса качества Novagen и позволил нам подтвердить несколько важных моментов, когда дело доходит до тестирования нового решения для обработки данных:
Как консультанты по данным и активные пользователи Apache Spark, для нас большая честь стать первыми последователями OVHcloudData Processing. В качестве первого варианта использования для тестирования этого предложения мы выбрали наш процесс оценки качества.
Как консалтинговая компания, базирующаяся в Париже, мы разрабатываем комплексные и инновационные стратегии обработки данных для наших крупных корпоративных и государственных клиентов: ведущих банков состояния, государственных органов, розничных торговцев, индустрии моды, лидеров транспорта и т. Д. Мы предлагаем им крупномасштабную бизнес-аналитику, озеро данных создание и управление, бизнес-инновации с наукой о данных. В нашей лаборатории данных мы выбираем лучшую в своем классе технологию и создаем то, что мы называем «ускорителями», то есть готовые к развертыванию или настраиваемые активы данных.
Когда дело доходит до выбора нового технологического решения, у нас есть следующий контрольный список:
- Инновации и эволюционность : глубина функциональности, дополнительная ценность и удобство использования
- Производительность и рентабельность : внутренние характеристики, но также и техническая архитектура, адаптируемая к потребностям клиентов.
- Открытые стандарты и управление : для поддержки облачных или мультиоблачных стратегий наших клиентов мы предпочитаем полагаться на открытые стандарты для развертывания на различных объектах и сохранения обратимости.
Apache Spark, наш швейцарский армейский нож
Около месяца назад Бастьен Вердебаут, менеджер по продуктам OVHcloud по данным и ИИ, обратился к нам с просьбой протестировать свой новый продукт OVHcloud Data Processing, созданный на основе Apache Spark. Конечно, да!
Одна из причин, по которой мы так стремились открыть эту обработку данных в качестве сервисного решения, заключалась в том, что мы широко используем Apache Spark; это наш швейцарский армейский нож для обработки данных.
- Он работает с очень большим объемом данных,
- Он отвечает потребностям инженерии данных и науки о данных,
- Это позволяет обрабатывать данные в состоянии покоя и передавать данные в потоковом режиме.
- Это де-факто стандарт для рабочих нагрузок с данными в локальной среде и в облаке,
- Он предлагает встроенные API для Python, Scala, Java и R.
Мы постоянно разрабатываем программные активы на базе Apache Spark для решения повторяющихся проблем, таких как:
- Обработка ETL в среде озера данных,
- KPI качества поверх источников озера данных,
- Алгоритм машинного обучения для обработки естественного языка, прогнозы временных рядов…
Идеальный вариант использования: оценка качества данных
Мы рассмотрели следующие характеристики обработки данных OVHCloud :
- Механизм обработки построен на основе Apache Spark 2.4.3
- Задания запускаются через несколько секунд (против минут для запуска кластера)
- Возможность регулировать мощность, выделенную для различных заданий Spark : от низкого энергопотребления (1 драйвер и 1 исполнитель с 4 ядрами и 8 ГБ памяти) до крупномасштабной обработки (потенциальные сотни ядер и ГБ памяти)
- Полное разделение вычислений и хранилищ в соответствии со стандартом облачных архитектур , включая API-интерфейсы S3 для доступа к данным, хранящимся на уровне хранилища объектов.
- Выполнение и мониторинг заданий через интерфейс командной строки и API
Эти характеристики побудили нас выбрать наш процесс оценки качества в качестве идеального варианта использования, который требует как интерактивности, так и настраиваемых вычислительных ресурсов для обеспечения качественных ключевых показателей эффективности с помощью процессов Spark.
Обработка данных OVHCloud на работе
Соответствующая команда, сгенерированная нашим программным обеспечением:
./ovh-spark-submit --projectid ec7d2cb6da084055a0501b2d8d8d62a1 \
--class tech.novagen.spark.Launcher --driver-cores 4 --driver-memory 8G \
--executor-cores 4 --executor-memory 8G --num-executors 5 \
swift://sparkjars/QualitySparkExecutor-1.0-spark.jar --apiServer=5.1.1.2:80У нас есть команда, которая очень похожа на обычную искру-отправку, за исключением пути к jar, который требует, чтобы двоичный файл находился в корзине объектного хранилища, к которой мы обращаемся с быстрой спецификацией URL-адреса. (NB: эта команда могла быть создана с помощью вызова API обработки данных OVHCloud).
Начиная с этого момента, мы можем теперь точно настроить наш портфель процессов и поиграть с распределением различной мощности с небольшими ограничениями (за исключением квот, назначаемых любому проекту общедоступного облака).
Отображение журналов заданий в реальном времени
В конце концов, для настройки и посмертного анализа работы мы можем воспользоваться сохраненными файлами журнала. Примечательно, что OVHcloud Data Processing предлагает отображение журналов заданий в реальном времени, что очень удобно и обеспечивает дополнительный контроль через информационные панели Grafana.
Это первый, но важный тест обработки данных OVHcloud; На данный момент он отлично подходит для варианта использования процесса качества Novagen и позволил нам подтвердить несколько важных моментов, когда дело доходит до тестирования нового решения для обработки данных:
Это начало этого продукта, и мы внимательно рассмотрим его функции. Команда OVHCloud представила часть своей дорожной карты, и она выглядит многообещающей!
Хуберт Стефани, директор по инновациям Novagen Conseil
Бастион OVHcloud SSH - Часть 2: головокружение от делегирования
Это вторая часть серии блогов, вот и первая. Ранее мы обнаружили, что бастион не является вашим обычным хостом перехода SSH (на самом деле, мы обнаружили, что это вообще не хост прыжка), и мы обсудили, как делегирование было одной из основных функций, которые нам изначально нужны. Итак, давайте погрузимся в эти концепции. На бастионе есть две совместимые модели доступа: персональный и групповой.
На бастионе каждая учетная запись имеет (как минимум) один набор личных выходных ключей . Эти звери генерируются при первом создании учетной записи. Личный выходной закрытый ключ находится в домашней учетной записи бастиона. У пользователя учетной записи нет возможности увидеть его или экспортировать из бастиона, но он может использовать его через логику кода бастиона. Пользователь может получить соответствующий открытый ключ в любое время и установить его — или получить его — на удаленных серверах, к которым он должен получить доступ. В зависимости от вашего варианта использования и уровня автономии, который вы хотите предоставить командам, есть два способа управления этим личным доступом.
Первый способ имитирует управление доступом, если бы вы вообще не использовали бастион SSH. Это идеальный способ обработки доступа на простом уровне без слишком большого количества пользователей и ограниченного количества машин. Это позволяет каждому предоставить себе личный доступ на бастион, не прося об этом кого-то другого. Звучит как дыра в безопасности, но это не так. Если кто-то добавит себе личный доступ к удаленному серверу, он будет работать, только если его личный выходной открытый ключ ужебыл установлен на удаленном сервере. Другими словами, либо у него уже был доступ к удаленному серверу для этого — используя средства, отличные от бастиона, — либо кто-то, у кого был доступ к удаленному серверу, принял добавление своего ключа. В любом случае, он не может волшебным образом предоставить себе персональный доступ без разрешения администратора удаленного сервера его ключа.
Другой способ справиться с этим может заключаться в предоставлении ограниченному количеству людей, например службам безопасности, права добавлять личные доступы для других. Таким образом, люди становятся менее автономными, но это может быть полезно, если добавление доступа должно осуществляться через нормализованные процессы. Он также имеет несколько приятных эффектов: как системный администратор, вы можете создать 3 отдельные учетные записи на удаленном компьютере и сопоставить их с каждой добавляемой учетной записью бастиона. Это хороший метод для достижения сквозного отслеживания ; в том числе на удаленном сервере; где вы, возможно, захотите установить auditd или аналогичные инструменты. Это также можно сделать в режиме помощи себе , но это может быть сложнее принудительно.
Чтобы было ясно, эта модель доступа не так эффективно масштабируется, когда мы имеем дело с целыми командами или крупными инфраструктурами — вот где групповой доступ пригодится.
Группа состоит из трех компонентов:
Список серверов на самом деле представляет собой список IP-адресов или IP-блоков. Они сопоставляются с вашими серверами, сетевыми устройствами или чем-либо еще с поддержкой SSH, у которого есть IP (на котором был установлен ключ исходящей группы). Технически этот список фактически состоит из трех элементов: удаленный пользователь , удаленный IP (или блок IP), удаленный порт . То, что применяется к персональному доступу, также применимо и здесь: добавление сервера в список не дает волшебным образом доступа к нему, сначала необходимо установить открытый ключ исходящей группы. Конечно, управление установкой этих ключей вручную быстро становится непрактичным, но вы можете рассмотреть эту часть конфигурации серверов, поэтому ими следует управлять с помощью той централизованной системы конфигурации, которую вы уже используете (Puppet, Chef, Ansible, / bin / cp… подожди, нет, ударил последний ).
Члены — это люди, которые могут подключаться к любому серверу, указанному в списке серверов группы. Они будут использовать закрытый ключ исходящей группы , к которому у них есть доступ, как члены указанной группы. Конечно, у них нет возможности извлечь этот закрытый ключ для собственного использования за пределами бастиона, они могут использовать его только через логику кода бастиона.
У вас новый член команды? Просто добавьте их в свою группу, и они мгновенно получат доступ ко всем серверам группы. Кто-нибудь уходит из компании? Просто удалите там аккаунт на бастионе, и все доступы мгновенно пропадут. Это так, потому что все ваши серверы должны иметь входящие сеансы SSH, ограниченные вашими бастионами. Таким образом, любой мошеннический ключ SSH, который был бы добавлен, больше не используется.
Мы рассмотрели основы группового подхода, но, поскольку нам нужна большая гибкость и делегирование, есть еще кое-что. Помните, я сказал, что в группе 3 компонента? Я соврал. В группе больше, чем просто участники. Дополнительные групповые роли включают:
Все это списки учетных записей, играющих определенную роль в группе.
Во-первых, гости . Они немного похожи на участников , но с меньшими привилегиями: они могут подключаться к удаленным машинам с помощью ключа группы, но не ко всем машинам группы, а только к подмножеству. Это полезно, когда кому-то за пределами группы нужен конкретный доступ к определенному серверу, потенциально на ограниченный период времени (поскольку для таких доступов может быть установлен срок действия).
Затем привратники . Эти ребята ведут список участников и гостей группы. Другими словами, они имеют право давать право доступа . Здесь нет ничего сложного. Затем есть помощники . Как вы уже догадались, они управляют списком серверов, входящих в группу. Если у вас есть автоматизация управления предоставлением серверов вашей инфраструктуры, эта роль может быть предоставлена учетной записи робота, единственной целью которой будет обновление списка серверов на бастионе полностью интегрированным способом с вашей подготовкой. Вы даже можете пометить такие учетные записи, чтобы они никогда не смогли использовать SSH через бастион, даже если кто-то предоставит их по ошибке!
И последнее, но не менее важное: владельцы имеют наивысший уровень привилегий в группе, что означает, что они могут управлять привратниками, хранителями учетных записей и списком владельцев. Им разрешено давать право давать право доступа. Более того, пользователи могут накапливать эти роли, что означает, что некоторые учетные записи могут быть, например, участником и привратником одновременно.
Помимо только что описанных ролей, которые относятся к группе, существуют две дополнительные роли, охватывающие весь бастион: «супервладелец» и «администратор бастиона».
Короче говоря, супервладелец — это неявный владелец всех групп, присутствующих на бастионе. Это удобно, если группа становится бесхозной, поскольку супервладельцы могут назначить нового владельца. Смотри, куда я иду? Супервладельцам разрешено давать право давать право давать право доступа.
Головокружение еще не закончилось? Теперь о самой влиятельной роли: админке бастиона . Эта роль должна быть предоставлена только нескольким лицам, поскольку они могут выдавать себя за кого угодно (даже если, конечно, когда они это делают, это регистрируется и заставляет наш SIEM покраснеть), и на практике не следует отдавать никому, кто еще не получил root-права в самой операционной системе бастиона. Помимо прочего, они управляют конфигурацией бастиона, где объявлены супервладельцы. Задержи дыхание. Готов? Им разрешено давать право давать право давать право давать право доступа. Вот почему делегирование лежит в основе системы: у каждого есть свой набор обязанностей и возможные действия, без необходимости спрашивать администратора бастиона.
Все концепции управления доступом, о которых мы говорили, сопоставлены с реальными командами. Их можно запустить на бастионе после аутентификации пользователя (известное входящее соединение). На бастионном жаргоне они называются командами osh. В этом случае нет исходящих соединений, так как эти команды взаимодействуют с самим бастионом:
Как вы могли заметить на скриншоте выше, версия программного обеспечения Bastion очень близка к 3.00.00 ! Может быть, приближается интересная веха?
В следующей части этой серии блогов мы углубимся в некоторые детали реализации одного из этих плагинов osh , а точнее, в наш подход к программированию безопасности и защиты.
Личный доступ — кусок торта
На бастионе каждая учетная запись имеет (как минимум) один набор личных выходных ключей . Эти звери генерируются при первом создании учетной записи. Личный выходной закрытый ключ находится в домашней учетной записи бастиона. У пользователя учетной записи нет возможности увидеть его или экспортировать из бастиона, но он может использовать его через логику кода бастиона. Пользователь может получить соответствующий открытый ключ в любое время и установить его — или получить его — на удаленных серверах, к которым он должен получить доступ. В зависимости от вашего варианта использования и уровня автономии, который вы хотите предоставить командам, есть два способа управления этим личным доступом.
Угощайтесь
Первый способ имитирует управление доступом, если бы вы вообще не использовали бастион SSH. Это идеальный способ обработки доступа на простом уровне без слишком большого количества пользователей и ограниченного количества машин. Это позволяет каждому предоставить себе личный доступ на бастион, не прося об этом кого-то другого. Звучит как дыра в безопасности, но это не так. Если кто-то добавит себе личный доступ к удаленному серверу, он будет работать, только если его личный выходной открытый ключ ужебыл установлен на удаленном сервере. Другими словами, либо у него уже был доступ к удаленному серверу для этого — используя средства, отличные от бастиона, — либо кто-то, у кого был доступ к удаленному серверу, принял добавление своего ключа. В любом случае, он не может волшебным образом предоставить себе персональный доступ без разрешения администратора удаленного сервера его ключа.
Спросите ИТ-специалистов
Другой способ справиться с этим может заключаться в предоставлении ограниченному количеству людей, например службам безопасности, права добавлять личные доступы для других. Таким образом, люди становятся менее автономными, но это может быть полезно, если добавление доступа должно осуществляться через нормализованные процессы. Он также имеет несколько приятных эффектов: как системный администратор, вы можете создать 3 отдельные учетные записи на удаленном компьютере и сопоставить их с каждой добавляемой учетной записью бастиона. Это хороший метод для достижения сквозного отслеживания ; в том числе на удаленном сервере; где вы, возможно, захотите установить auditd или аналогичные инструменты. Это также можно сделать в режиме помощи себе , но это может быть сложнее принудительно.
Чтобы было ясно, эта модель доступа не так эффективно масштабируется, когда мы имеем дело с целыми командами или крупными инфраструктурами — вот где групповой доступ пригодится.
Групповой доступ — Let's Rock
Группа состоит из трех компонентов:
- Список участников (аккаунты, представляющие отдельных людей)
- По крайней мере, один набор групповых выходных ключей
- Список серверов (фактически IP)
Список серверов
Список серверов на самом деле представляет собой список IP-адресов или IP-блоков. Они сопоставляются с вашими серверами, сетевыми устройствами или чем-либо еще с поддержкой SSH, у которого есть IP (на котором был установлен ключ исходящей группы). Технически этот список фактически состоит из трех элементов: удаленный пользователь , удаленный IP (или блок IP), удаленный порт . То, что применяется к персональному доступу, также применимо и здесь: добавление сервера в список не дает волшебным образом доступа к нему, сначала необходимо установить открытый ключ исходящей группы. Конечно, управление установкой этих ключей вручную быстро становится непрактичным, но вы можете рассмотреть эту часть конфигурации серверов, поэтому ими следует управлять с помощью той централизованной системы конфигурации, которую вы уже используете (Puppet, Chef, Ansible, / bin / cp… подожди, нет, ударил последний ).
Список участников
Члены — это люди, которые могут подключаться к любому серверу, указанному в списке серверов группы. Они будут использовать закрытый ключ исходящей группы , к которому у них есть доступ, как члены указанной группы. Конечно, у них нет возможности извлечь этот закрытый ключ для собственного использования за пределами бастиона, они могут использовать его только через логику кода бастиона.
У вас новый член команды? Просто добавьте их в свою группу, и они мгновенно получат доступ ко всем серверам группы. Кто-нибудь уходит из компании? Просто удалите там аккаунт на бастионе, и все доступы мгновенно пропадут. Это так, потому что все ваши серверы должны иметь входящие сеансы SSH, ограниченные вашими бастионами. Таким образом, любой мошеннический ключ SSH, который был бы добавлен, больше не используется.
И еще немного
Мы рассмотрели основы группового подхода, но, поскольку нам нужна большая гибкость и делегирование, есть еще кое-что. Помните, я сказал, что в группе 3 компонента? Я соврал. В группе больше, чем просто участники. Дополнительные групповые роли включают:
- Гости
- Привратники
- Aclkeepers
- Владельцы
Все это списки учетных записей, играющих определенную роль в группе.
Во-первых, гости . Они немного похожи на участников , но с меньшими привилегиями: они могут подключаться к удаленным машинам с помощью ключа группы, но не ко всем машинам группы, а только к подмножеству. Это полезно, когда кому-то за пределами группы нужен конкретный доступ к определенному серверу, потенциально на ограниченный период времени (поскольку для таких доступов может быть установлен срок действия).
Затем привратники . Эти ребята ведут список участников и гостей группы. Другими словами, они имеют право давать право доступа . Здесь нет ничего сложного. Затем есть помощники . Как вы уже догадались, они управляют списком серверов, входящих в группу. Если у вас есть автоматизация управления предоставлением серверов вашей инфраструктуры, эта роль может быть предоставлена учетной записи робота, единственной целью которой будет обновление списка серверов на бастионе полностью интегрированным способом с вашей подготовкой. Вы даже можете пометить такие учетные записи, чтобы они никогда не смогли использовать SSH через бастион, даже если кто-то предоставит их по ошибке!
И последнее, но не менее важное: владельцы имеют наивысший уровень привилегий в группе, что означает, что они могут управлять привратниками, хранителями учетных записей и списком владельцев. Им разрешено давать право давать право доступа. Более того, пользователи могут накапливать эти роли, что означает, что некоторые учетные записи могут быть, например, участником и привратником одновременно.
Глобальные роли — Приходите получить
Помимо только что описанных ролей, которые относятся к группе, существуют две дополнительные роли, охватывающие весь бастион: «супервладелец» и «администратор бастиона».
Короче говоря, супервладелец — это неявный владелец всех групп, присутствующих на бастионе. Это удобно, если группа становится бесхозной, поскольку супервладельцы могут назначить нового владельца. Смотри, куда я иду? Супервладельцам разрешено давать право давать право давать право доступа.
Головокружение еще не закончилось? Теперь о самой влиятельной роли: админке бастиона . Эта роль должна быть предоставлена только нескольким лицам, поскольку они могут выдавать себя за кого угодно (даже если, конечно, когда они это делают, это регистрируется и заставляет наш SIEM покраснеть), и на практике не следует отдавать никому, кто еще не получил root-права в самой операционной системе бастиона. Помимо прочего, они управляют конфигурацией бастиона, где объявлены супервладельцы. Задержи дыхание. Готов? Им разрешено давать право давать право давать право давать право доступа. Вот почему делегирование лежит в основе системы: у каждого есть свой набор обязанностей и возможные действия, без необходимости спрашивать администратора бастиона.
Подведение итогов
Все концепции управления доступом, о которых мы говорили, сопоставлены с реальными командами. Их можно запустить на бастионе после аутентификации пользователя (известное входящее соединение). На бастионном жаргоне они называются командами osh. В этом случае нет исходящих соединений, так как эти команды взаимодействуют с самим бастионом:
Как вы могли заметить на скриншоте выше, версия программного обеспечения Bastion очень близка к 3.00.00 ! Может быть, приближается интересная веха?
В следующей части этой серии блогов мы углубимся в некоторые детали реализации одного из этих плагинов osh , а точнее, в наш подход к программированию безопасности и защиты.
Путешествие по чудесной стране машинного обучения или «Могу ли я купить дворец в Париже за 100 000 евро?» (Часть 2)
Спойлер, нет, нельзя.
Несколько месяцев назад я объяснил, как использовать Dataiku — известную интерактивную студию AI — и как использовать данные, предоставленные французским правительством, для построения модели машинного обучения, прогнозирующей рыночную стоимость недвижимости. К сожалению, это с треском провалилось: когда я попробовал это на сделках, совершенных на моей улице, в том же году, когда я купил свою квартиру, модель предсказала, что все они имеют одинаковую рыночную стоимость.
В этом сообщении в блоге я укажу несколько причин, по которым наш эксперимент потерпел неудачу, а затем я попытаюсь обучить новую модель, принимая во внимание то, что мы узнали.
Наша модель потерпела неудачу по нескольким причинам. Из них выделяются три:
Вы можете найти описание структуры данных на специальной веб-странице. Я не буду перечислять все столбцы схемы (их 40), но самый важный из них — первый: id_mutation. Эта информация представляет собой уникальный номер транзакции, а не необычный столбец для поиска.
Однако, если вы посмотрите на сам набор данных, вы увидите, что некоторые транзакции распределены по нескольким строкам. Они соответствуют транзакциям перегруппировки нескольких посылок. В примере с моей собственной сделкой есть две строки: одна для самой квартиры, а другая для отдельного подвала под зданием.
Проблема в том, что на каждой такой строке указана полная цена. С точки зрения моей студии искусственного интеллекта, которая видит только набор линий, которые она интерпретирует как точки данных, похоже, что мой подвал и мои квартиры — это два разных объекта недвижимости, которые стоят одинаково! Ситуация ухудшается для собственности, у которой есть земли и несколько построек, прикрепленных к ним. Как мы можем ожидать, что наш алгоритм обучится должным образом в этих условиях?
Разнообразие данных
В данном случае мы пытаемся спрогнозировать стоимость квартиры в Париже. Однако данные, которые мы предоставили алгоритму, объединяют каждую сделку с недвижимостью, совершенную во Франции за последние несколько лет. Вы можете подумать, что чем больше данных, тем лучше, но это не обязательно.
Рынок недвижимости меняется в зависимости от того, где вы находитесь, и Париж — очень специфический случай для Франции, где цены намного выше, чем в других крупных городах и остальной части Франции. Конечно, это видно по данным, но алгоритм обучения не знает этого заранее, и ему очень сложно научиться оценивать небольшую квартиру в Париже и ферму с акрами земли в Лозере на то же время.
Параметры обучения модели
В последнем сообщении в блоге вы увидели, насколько просто использовать Dataiku. Но за это приходится платить: сценарий по умолчанию можно использовать для очень простых случаев использования. Но он не подходит для сложных задач — например, прогнозирования цен на недвижимость. У меня самого нет большого опыта работы с Dataiku. Однако, углубившись в детали, я смог исправить несколько очевидных ошибок:
К счастью, есть способы решить эти проблемы. Dataiku объединяет инструменты для преобразования и фильтрации ваших наборов данных перед запуском ваших алгоритмов. Он также позволяет изменять параметры тренировки. Вместо того, чтобы проводить вас через все шаги, я собираюсь подвести итог тому, что я сделал для каждой из проблем, которые мы определили ранее:
Макет данных
Разнообразие данных
Параметры обучения модели
Параметры обучения модели:
Итак, как мы поживали после всего этого? Что ж, для начала давайте посмотрим на рейтинг R2 наших моделей. В зависимости от тренировки наши лучшие модели имеют оценку R2 от 0,8 до 0,85. Напоминаем, что оценка R2, равная 1, будет означать, что модель идеально предсказывает стоимость каждой точки данных, используемой на этапе оценки обучения. Лучшие модели в наших предыдущих попытках имели оценку R2 от 0,1 до 0,2, так что здесь мы уже явно лучше. Давайте теперь посмотрим на несколько прогнозов этой модели.
Сначала я перепроверил все транзакции со своей улицы. На этот раз прогноз для моей квартиры на ~ 16% ниже цены, которую я заплатил. Но, в отличие от прошлого раза, у каждой квартиры разная оценка, и все эти оценки указаны в правильном порядке. Большинство значений имеют ошибку менее 20% по сравнению с реальной ценой, а худшие оценки имеют ошибку ~ 50%. Очевидно, такая погрешность недопустима при инвестировании в квартиру. Однако по сравнению с предыдущей версией нашей модели, которая давала одинаковую оценку для всех квартир на моей улице, мы добились значительного прогресса.
Итак, теперь, когда у нас, по крайней мере, есть правильный порядок величины, давайте попробуем настроить некоторые значения в нашем входном наборе данных, чтобы увидеть, реагирует ли модель предсказуемо. Для этого я взял точку данных моей собственной транзакции и создал новые точки данных, каждый раз изменяя одну из характеристик исходной точки данных:
С каждой из этих модификаций мы ожидаем, что новые оценки будут ниже первоначальной (рынок недвижимости в Париже находится в постоянной инфляции). Посмотрим на результаты:
По крайней мере, качественно модель ведет себя должным образом.
На этом этапе мы использовали здравый смысл, чтобы значительно улучшить наши предыдущие результаты и построить модель, которая дает прогнозы в хорошем порядке и ведет себя так, как мы ожидаем, при настройке характеристик точек данных. Однако оставшаяся погрешность делает его непригодным для реального применения. Но почему и что мы могли сделать, чтобы продолжать улучшать нашу модель? На то есть несколько причин:
Сложность данных: я немного противоречу себе. Хотя сложные данные сложнее переварить для алгоритма машинного обучения, необходимо сохранить эту сложность, если она отражает сложность в конечном результате. В этом случае мы могли не только чрезмерно упростить данные, но и сами исходные данные могли не иметь большого количества соответствующей информации.
Мы обучили наш алгоритм общему расположению и поверхности, которые, по общему признанию, являются наиболее важными критериями, но в нашем наборе данных отсутствует очень важная информация, такая как полы, экспозиция, годы строительства, диагностика изоляции, состояние, доступность, вид, общее состояние квартир и т. Д.
Существуют частные наборы данных, созданные нотариальными конторами, которые более полны, чем наш открытый набор данных, но хотя они могут иметь такие характеристики, как пол или год постройки, в них, вероятно, не будет более субъективной информации; например, общее состояние или вид.
В наборе данных отсутствует очень важная информация о квартирах.
В этом сообщении блога мы обсудили, почему наша предыдущая попытка обучить модель предсказывать цены на квартиры в Париже потерпела неудачу. Данные, которые мы использовали, не были достаточно очищены, и мы использовали параметры обучения Dataiku по умолчанию, а не проверяли их целесообразность.
После этого мы исправили наши ошибки, очистили данные и настроили параметры обучения. Это значительно улучшило результат нашей модели, но недостаточно для реалистичного использования. Есть способы улучшить модель, но в доступных наборах данных не хватает некоторой информации, а самих данных может быть недостаточно для построения надежной модели.
К счастью, цель этой серии никогда не заключалась в том, чтобы точно предсказать цены на квартиры в Париже. Если бы это было возможно, не было бы больше агентств недвижимости. Вместо этого он служит иллюстрацией того, как любой может взять необработанные данные, найти проблему, связанную с данными, и обучить модель решать эту проблему.
Однако набор данных, который мы использовали в этом примере, был довольно небольшим: всего несколько гигабайт. Все происходило на одной виртуальной машине, и нам приходилось делать все вручную, с фиксированным набором данных. Что бы я сделал, если бы хотел обрабатывать петабайты данных? Если бы я хотел обрабатывать непрерывную потоковую передачу данных? Если бы я хотел раскрыть свою модель, чтобы внешние приложения могли ее запрашивать?
Это то, что мы собираемся рассмотреть в следующий раз, в последнем сообщении блога этой серии.
Несколько месяцев назад я объяснил, как использовать Dataiku — известную интерактивную студию AI — и как использовать данные, предоставленные французским правительством, для построения модели машинного обучения, прогнозирующей рыночную стоимость недвижимости. К сожалению, это с треском провалилось: когда я попробовал это на сделках, совершенных на моей улице, в том же году, когда я купил свою квартиру, модель предсказала, что все они имеют одинаковую рыночную стоимость.
В этом сообщении в блоге я укажу несколько причин, по которым наш эксперимент потерпел неудачу, а затем я попытаюсь обучить новую модель, принимая во внимание то, что мы узнали.
Почему наша модель не удалась
Наша модель потерпела неудачу по нескольким причинам. Из них выделяются три:
- Макет формата открытых данных
- Разнообразие данных
- Параметры модели Dataiku по умолчанию
Макет формата открытых данных
Вы можете найти описание структуры данных на специальной веб-странице. Я не буду перечислять все столбцы схемы (их 40), но самый важный из них — первый: id_mutation. Эта информация представляет собой уникальный номер транзакции, а не необычный столбец для поиска.
Однако, если вы посмотрите на сам набор данных, вы увидите, что некоторые транзакции распределены по нескольким строкам. Они соответствуют транзакциям перегруппировки нескольких посылок. В примере с моей собственной сделкой есть две строки: одна для самой квартиры, а другая для отдельного подвала под зданием.
Проблема в том, что на каждой такой строке указана полная цена. С точки зрения моей студии искусственного интеллекта, которая видит только набор линий, которые она интерпретирует как точки данных, похоже, что мой подвал и мои квартиры — это два разных объекта недвижимости, которые стоят одинаково! Ситуация ухудшается для собственности, у которой есть земли и несколько построек, прикрепленных к ним. Как мы можем ожидать, что наш алгоритм обучится должным образом в этих условиях?
Разнообразие данных
В данном случае мы пытаемся спрогнозировать стоимость квартиры в Париже. Однако данные, которые мы предоставили алгоритму, объединяют каждую сделку с недвижимостью, совершенную во Франции за последние несколько лет. Вы можете подумать, что чем больше данных, тем лучше, но это не обязательно.
Рынок недвижимости меняется в зависимости от того, где вы находитесь, и Париж — очень специфический случай для Франции, где цены намного выше, чем в других крупных городах и остальной части Франции. Конечно, это видно по данным, но алгоритм обучения не знает этого заранее, и ему очень сложно научиться оценивать небольшую квартиру в Париже и ферму с акрами земли в Лозере на то же время.
Параметры обучения модели
В последнем сообщении в блоге вы увидели, насколько просто использовать Dataiku. Но за это приходится платить: сценарий по умолчанию можно использовать для очень простых случаев использования. Но он не подходит для сложных задач — например, прогнозирования цен на недвижимость. У меня самого нет большого опыта работы с Dataiku. Однако, углубившись в детали, я смог исправить несколько очевидных ошибок:
- Типы данных: многие столбцы в наборе данных относятся к определенным типам: целые числа, географические координаты, даты и т. Д. Большинство из них правильно определены Dataiku, но некоторые из них — например, географические координаты или даты — нет.
- Анализ данных: если вы помните предыдущий пост, в какой-то момент мы рассматривали разные модели, обученные алгоритмом. У нас не было времени взглянуть на автоматизацию модели. Этот раздел позволяет нам настроить несколько элементов; такие как типы алгоритмов, которые мы запускаем, параметры обучения, выбор набора данных и т. д.
- С таким большим количеством функций, присутствующих в наборе данных, Dataiku попытался уменьшить количество функций, которые он будет анализировать, чтобы упростить алгоритм обучения. Но он сделал плохой выбор. Например, учитывается номер улицы, но не сама улица. Хуже того, он даже не смотрит на дату или площадь участков (но он действительно учитывает поверхность земли, если она есть…), что, безусловно, является самым важным фактором в большинстве городов!
Как все это исправить
К счастью, есть способы решить эти проблемы. Dataiku объединяет инструменты для преобразования и фильтрации ваших наборов данных перед запуском ваших алгоритмов. Он также позволяет изменять параметры тренировки. Вместо того, чтобы проводить вас через все шаги, я собираюсь подвести итог тому, что я сделал для каждой из проблем, которые мы определили ранее:
Макет данных
- Сначала я сгруппировал строки, соответствующие одним и тем же транзакциям. В зависимости от полей я либо суммировал их (например, когда это была жилая площадь), сохранял одно из них (адрес) или объединял их (например, когда это был идентификатор хозяйственной постройки).
- Во-вторых, я удалил несколько ненужных или избыточных полей, добавляющих шум в алгоритм; например, название улицы (уже существуют уникальные для каждого города коды улиц), суффикс номера улицы («Bis» или «Ter», обычно встречающиеся в адресе после номера дома) или другая информация, относящаяся к администрации.
- Наконец, некоторые транзакции содержат не только несколько участков (на нескольких строках), но также несколько подпунктов на участок, каждый со своей собственной поверхностью и номером подпункта. Это подразделение в основном административное, и участки часто представляют собой ранее прилегающие квартиры, которые были объединены. Чтобы упростить данные, я вырезал номера участков и суммировал их соответствующие поверхности, прежде чем перегруппировать линии.
Разнообразие данных
- Во-первых, поскольку мы пытаемся обучить модель для оценки стоимости парижских квартир, я отфильтровал все транзакции, которые не происходили в Париже (а это, как вы можете ожидать, большая часть).
- Во-вторых, я удалил все транзакции, у которых были неполные данные для важных полей (таких как поверхность или адрес).
- Наконец, я удалил выбросы: транзакции, соответствующие объектам недвижимости, которые не соответствуют стандартным квартирам; такие как дома, коммерческая земля, элитные квартиры и т. д.
Параметры обучения модели
Параметры обучения модели:
- Во-первых, я убедился, что в модели учтены все особенности. Примечание: вместо того, чтобы удалять ненужные поля из набора данных, я мог бы просто сказать алгоритму игнорировать соответствующие функции. Однако я предпочитаю повысить удобочитаемость набора данных, чтобы облегчить его изучение. Более того, Dataiku загружает данные в ОЗУ для их обработки, поэтому запуск на чистом наборе данных делает его более эффективным для ОЗУ.
- Во-вторых, я обучил алгоритм различным наборам функций: в некоторых случаях я сохранил район, но не улицу. Поскольку в Париже много разных улиц, это категориальный признак с высокой мощностью (множество различных возможностей, которые невозможно перечислить).
- Наконец, я попробовал разные семейства алгоритмов машинного обучения: Случайный лес — в основном построение дерева решений; XGBoost — повышение градиента; SVM (Support Vector Machine) — обобщение линейных классификаторов; и KNN (K-Nearest-Neighbours) — который пытается классифицировать точки данных, глядя на своих соседей в соответствии с различными показателями.
Это сработало?
Итак, как мы поживали после всего этого? Что ж, для начала давайте посмотрим на рейтинг R2 наших моделей. В зависимости от тренировки наши лучшие модели имеют оценку R2 от 0,8 до 0,85. Напоминаем, что оценка R2, равная 1, будет означать, что модель идеально предсказывает стоимость каждой точки данных, используемой на этапе оценки обучения. Лучшие модели в наших предыдущих попытках имели оценку R2 от 0,1 до 0,2, так что здесь мы уже явно лучше. Давайте теперь посмотрим на несколько прогнозов этой модели.
Сначала я перепроверил все транзакции со своей улицы. На этот раз прогноз для моей квартиры на ~ 16% ниже цены, которую я заплатил. Но, в отличие от прошлого раза, у каждой квартиры разная оценка, и все эти оценки указаны в правильном порядке. Большинство значений имеют ошибку менее 20% по сравнению с реальной ценой, а худшие оценки имеют ошибку ~ 50%. Очевидно, такая погрешность недопустима при инвестировании в квартиру. Однако по сравнению с предыдущей версией нашей модели, которая давала одинаковую оценку для всех квартир на моей улице, мы добились значительного прогресса.
Итак, теперь, когда у нас, по крайней мере, есть правильный порядок величины, давайте попробуем настроить некоторые значения в нашем входном наборе данных, чтобы увидеть, реагирует ли модель предсказуемо. Для этого я взял точку данных моей собственной транзакции и создал новые точки данных, каждый раз изменяя одну из характеристик исходной точки данных:
- поверхность, чтобы уменьшить это
- координаты (название улицы, код улицы, географические координаты и т. д.), чтобы поместить его в более дешевый район
- дата транзакции до 2015 года (за 3 года до реальной даты)
С каждой из этих модификаций мы ожидаем, что новые оценки будут ниже первоначальной (рынок недвижимости в Париже находится в постоянной инфляции). Посмотрим на результаты:
По крайней мере, качественно модель ведет себя должным образом.
Как мы могли добиться большего?
На этом этапе мы использовали здравый смысл, чтобы значительно улучшить наши предыдущие результаты и построить модель, которая дает прогнозы в хорошем порядке и ведет себя так, как мы ожидаем, при настройке характеристик точек данных. Однако оставшаяся погрешность делает его непригодным для реального применения. Но почему и что мы могли сделать, чтобы продолжать улучшать нашу модель? На то есть несколько причин:
Сложность данных: я немного противоречу себе. Хотя сложные данные сложнее переварить для алгоритма машинного обучения, необходимо сохранить эту сложность, если она отражает сложность в конечном результате. В этом случае мы могли не только чрезмерно упростить данные, но и сами исходные данные могли не иметь большого количества соответствующей информации.
Мы обучили наш алгоритм общему расположению и поверхности, которые, по общему признанию, являются наиболее важными критериями, но в нашем наборе данных отсутствует очень важная информация, такая как полы, экспозиция, годы строительства, диагностика изоляции, состояние, доступность, вид, общее состояние квартир и т. Д.
Существуют частные наборы данных, созданные нотариальными конторами, которые более полны, чем наш открытый набор данных, но хотя они могут иметь такие характеристики, как пол или год постройки, в них, вероятно, не будет более субъективной информации; например, общее состояние или вид.
В наборе данных отсутствует очень важная информация о квартирах.
- Объем данных: даже если бы у нас были очень полные данные, нам понадобилось бы их огромное количество. Чем больше функций мы включаем в наше обучение, тем больше данных нам нужно. И для такой сложной задачи ~ 150 тыс. Транзакций в год, которые мы проводим в Париже, вероятно, недостаточно. Решением может быть создание искусственных точек данных: квартир, которых на самом деле не существует, но которые специалисты-люди все равно смогут оценить.
Но здесь есть три проблемы: во-первых, любая предвзятость экспертов неизбежно передается модели. Во-вторых, нам нужно будет создать огромное количество искусственных, но реалистичных точек данных, а затем потребуется помощь нескольких экспертов-людей, чтобы пометить их. Наконец, вышеупомянутые эксперты будут маркировать эти искусственные данные на основе своего текущего опыта. Им будет очень трудно вспомнить рыночные цены, которые были несколько лет назад. Это означает, что для получения однородного набора данных на протяжении многих лет нам придется создавать эти искусственные данные с течением времени и с той же скоростью, что и настоящие транзакции. - Навыки: наконец, работа в области анализа данных — это работа на полную ставку, которая требует опыта и навыков. Настоящий специалист по данным, вероятно, смог бы достичь лучших результатов, чем те, которые я получил, настроив параметры обучения и выбрав наиболее подходящие алгоритмы.
Более того, даже хорошие специалисты по данным должны разбираться в недвижимости и ценообразовании. Очень сложно создавать продвинутые модели машинного обучения, не разбираясь в теме.
Резюме
В этом сообщении блога мы обсудили, почему наша предыдущая попытка обучить модель предсказывать цены на квартиры в Париже потерпела неудачу. Данные, которые мы использовали, не были достаточно очищены, и мы использовали параметры обучения Dataiku по умолчанию, а не проверяли их целесообразность.
После этого мы исправили наши ошибки, очистили данные и настроили параметры обучения. Это значительно улучшило результат нашей модели, но недостаточно для реалистичного использования. Есть способы улучшить модель, но в доступных наборах данных не хватает некоторой информации, а самих данных может быть недостаточно для построения надежной модели.
К счастью, цель этой серии никогда не заключалась в том, чтобы точно предсказать цены на квартиры в Париже. Если бы это было возможно, не было бы больше агентств недвижимости. Вместо этого он служит иллюстрацией того, как любой может взять необработанные данные, найти проблему, связанную с данными, и обучить модель решать эту проблему.
Однако набор данных, который мы использовали в этом примере, был довольно небольшим: всего несколько гигабайт. Все происходило на одной виртуальной машине, и нам приходилось делать все вручную, с фиксированным набором данных. Что бы я сделал, если бы хотел обрабатывать петабайты данных? Если бы я хотел обрабатывать непрерывную потоковую передачу данных? Если бы я хотел раскрыть свою модель, чтобы внешние приложения могли ее запрашивать?
Это то, что мы собираемся рассмотреть в следующий раз, в последнем сообщении блога этой серии.
Privacy Shield: недействительность
16 июля своим долгожданным постановлением ( C-311/18 ) Суд Европейского Союза (ECJ) нанес серьезный удар по практике передачи персональных данных в страны за пределами Европейского Союза.
Этот случай восходит к 25 июня 2013 года, когда г-н Максимилиан Шремс, гражданин Европы, подал жалобу в Комиссию по защите данных Ирландии с требованием запретить Facebook Ireland Ltd. передавать его личные данные в Соединенные Штаты.
Эта жалоба указывала на массовую слежку со стороны Америки, о которой одновременно сообщил Эдвард Сноуден. Он подчеркнул, что действующие в Соединенных Штатах правила недостаточно регулируют эти программы и не гарантируют субъектам данных права, эквивалентные тем, которые признаны в Европейском союзе.
В первом решении от 6 октября 2015 г. ( C362 / 14 ) Европейский Суд вынес решение в его пользу, признав недействительным Safe Harbor, механизм защиты, реализованный для передачи данных в Соединенные Штаты, который Европейская комиссия сочла адекватным ( решение 2000/520). ).
После этого решения ирландские власти, которые первоначально отклонили жалобу из-за существования Safe Harbor, начали расследование, в ходе которого Facebook Ireland Ltd. затем оправдала введение не Safe Harbor, а стандартных договорных положений в соответствии с те, которые приняты Решением Европейской комиссии 2010/87 / EU, которое, в принципе, должно обеспечивать адекватные гарантии для лиц, затронутых передачей персональных данных в страны, которые не обеспечивают адекватный уровень защиты.
На этот раз Европейский Суд попросили вынести решение о действительности вышеупомянутых стандартных договорных положений, с одной стороны, и «Privacy Shield», нового механизма защиты, созданного тем временем Соединенными Штатами и Комиссией для замены Безопасная гавань.
В своем решении от 16 июля Европейский суд постановил немедленно аннулировать Privacy Shield или, точнее, решение ( 2016/1250 ), которым Европейская комиссия установила, что Privacy Shield представляет собой достаточный механизм защиты для регулирования передача персональных данных в США.
В своем решении Европейский суд счел, что программы наблюдения США не ограничиваются тем, что является строго необходимым, поскольку власти могут, в частности, проводить крупномасштабные операции наблюдения, которые не соответствуют принципам необходимости и соразмерности, действующим в Европейский Союз.
Европейский Суд также отметил, что Соединенные Штаты, включая механизм омбудсмена, на который ссылается Решение о защите конфиденциальности, не предоставляют реальной возможности субъектам данных подавать иски в независимый и беспристрастный суд, как это требуется в соответствии с Хартией основных прав Евросоюз.
Что касается стандартных договорных положений, Европейский суд подтвердил, что они остаются действующим механизмом для защиты передачи персональных данных из Европейского Союза в страны, которые не извлекают выгоду из решения об адекватности. Однако он напомнил, что в соответствии со статьей 46 RGDP сами по себе эти положения не всегда представляют собой достаточную защиту, в частности, в случае передачи данных в страны, которые, как и США, недостаточно регулируют полномочия. вмешательства их властей.
В этом отношении Европейский Суд по существу указывает, что стандартные договорные положения представляют собой договор, заключенный между экспортером, контролирующим данные, и импортером данных, и что этот договор не подлежит исполнению в отношении властей страны, получающей данные; указанные органы не являются стороной контракта.
Таким образом, стандартные договорные положения, хотя и действительны, не являются достаточной гарантией для регулирования передачи персональных данных из Европейского Союза в такие страны, как США. В этом случае должны быть приняты дополнительные меры в дополнение к этим пунктам.
Влияние этого второго опуса отнюдь не незначительно.
Действительно, с 16 июля все экономические операторы, которые ранее передавали персональные данные из Европейского Союза в США на основе Privacy Shield, были обязаны, если они желают продолжить такие передачи, заменить Privacy Shield действующими альтернативными гарантиями.
Однако альтернативные механизмы, которые могут быть введены в действие, перечисленные в статье 46 PGRD и включающие стандартные договорные положения, по большей части являются договорными механизмами, которые Европейский суд сочтет недостаточными из-за их неисполнимости в отношении Власти США.
Следовательно, внедрение этих альтернативных механизмов должно сопровождаться принятием дополнительных мер для обеспечения необходимой защиты.
Тогда возникает вопрос, какие виды мер могут, помимо стандартных договорных положений, представлять собой адекватную защиту от вмешательства со стороны властей США.
Европейский Суд не вынес решения по этому вопросу, а органы по защите данных еще не опубликовали информацию по этому вопросу, что может немного затруднить соблюдение требований.
Говоря конкретно, технически сложно предотвратить доступ властей США к данным, передаваемым из Европейского Союза в Соединенные Штаты, поскольку, как отметил Европейский Суд, власти США перехватывают трафик по сетевым кабелям, особенно в контексте программ разведки и добычи..
В этом отношении даже реализация решений для сквозного шифрования может считаться недостаточной, в частности, из-за решений для дешифрования, которые доступны или могут быть доступны властям, особенно в результате квантовых технологий. Кроме того, некоторые правила могут требовать от операторов передавать свои ключи шифрования властям или даже запрещать некоторые из них в будущем. Соединенные Штаты особенно обсуждают « Закон о законном доступе к зашифрованным данным ».
Альтернативой могло бы стать использование решений, размещенных в Европейском Союзе. Однако нет уверенности даже в том, что этого будет достаточно при любых обстоятельствах, особенно в случае обработки, выполняемой удаленно из Соединенных Штатов, например, в контексте администрирования, обслуживания или поддержки.
Действительно, некоторые операции удаленной обработки, такие как доступ, технически подразумевают временную передачу и, следовательно, раскрывают данные. Более того, это считается передачей данных в смысле европейских правил.
Некоторые субъекты экономической деятельности также сомневаются, можно ли адаптировать дополнительные меры в зависимости от риска для прав и свобод, в частности, чтобы гарантировать, что использование данных с низким риском для частной жизни людей не будет чрезмерно затруднено. Здесь также нет ничего менее уверенного, хотя подход, основанный на оценке риска, который преобладает в RGDP и стандартных договорных положениях, может предполагать это.
За пределами Соединенных Штатов эти вопросы возникают всякий раз, когда осуществляется перевод на основе стандартных договорных положений в страны, в отношении которых не было принято решение о соответствии и для которых невозможно с уверенностью установить, что они предоставляют гарантии, эквивалентные признанным. в пределах Европейского Союза в отношении вмешательства властей.
Неопределенность в отношении типа дополнительных мер, которые необходимо принять, создает незащищенность не только для субъектов данных, которые могут не пользоваться соответствующей защитой при передаче своих данных, но и для экономических операторов, многие из которых все еще ждут подтверждения соблюдения, особенно когда они зависят от сторонних поставщиков услуг или решений, работающих за пределами Европейского Союза.
Таким образом, преобладание — или почти монополия — GAFAM в таких секторах, как онлайн-исследования, социальные сети и реклама, делает чрезвычайно трудным, если не невозможным с точки зрения конкуренции, обходиться без их услуг. И такие услуги обычно включают переводы в Соединенные Штаты, для которых непросто, в частности, из-за упомянутых выше неопределенностей, обеспечить принятие соответствующих дополнительных мер безопасности.
В этом контексте представляется важным, чтобы органы по защите данных продолжали поддерживать экономических операторов, чтобы можно было четко определить и внедрить дополнительные меры, необходимые в случае переводов в США и другие эквивалентные страны.
Нет переводов в США
За исключением услуг, заказываемых непосредственно у американского подразделения OVHcloud, в ходе оказания услуг OVHcloud не передает данные своих клиентов в США.
Действительно, центры обработки данных OVHcloud, расположенные в США, не размещают какие-либо услуги, предлагаемые организациями OVHcloud за пределами США; сказал, что центры обработки данных в США используются только для размещения услуг, продаваемых американским подразделением OVHcloud. Кроме того, американское подразделение OVHcloud не участвует в предоставлении услуг, предоставляемых неамериканскими организациями OVHcloud. В частности, ни одна из этих служб не администрируется из Соединенных Штатов, и, следовательно, никакая соответствующая обработка данных не может осуществляться удаленно и, в частности, получать доступ из Соединенных Штатов.
Следовательно, аннулирование Privacy Shield здесь не влияет.
Что касается услуг, заказываемых у американского подразделения OVHcloud, они обычно не используются для обработки данных в соответствии с европейскими правилами, и в этом случае предпочтительны вышеупомянутые европейские решения. Тем не менее, OVHcloud United States, тем не менее, изучает решения для клиентов, на которых это может повлиять.
Ограниченные переводы в другие страны
Когда клиент выбирает услугу, размещенную в центре обработки данных OVHcloud, расположенном в Европейском Союзе, только европейские и канадские подразделения OVHcloud имеют в рамках администрирования и обслуживания услуг возможность выполнять операции обработки данных. размещены у Заказчиков.
В отношении Канады было принято решение об адекватности ( 2002/2 / EC ).
Европейская комиссия особо отметила, что канадское законодательство «охватывает все основные принципы, необходимые для адекватного уровня защиты физических лиц, даже если исключения и ограничения также предусмотрены для защиты важных общественных интересов. Применение этих стандартов гарантируется средствами судебной защиты и независимым надзором со стороны властей, таких как Федеральный комиссар по конфиденциальности, наделенный полномочиями по расследованию и вмешательству ». Более того, положения канадского законодательства о гражданской ответственности применяются в случае незаконной обработки, которая наносит ущерб лицам ».
Кроме того, OVHcloud никогда не получал от канадских властей запросов, которые были бы несоразмерны основным правам и принципам Европейского Союза.
Таким образом, даже если упомянутое решение об адекватности ограничивается сферой деятельности, подпадающей под действие Канадского Закона о защите личной информации и электронных документов (PIPEDA), что побудило OVHcloud принять договорные положения для определенных операций обработки, выходящих за рамки PIPEDA, — вышеизложенные выводы о канадских Закон обязывает считать, что выполнение стандартных договорных положений для деятельности, не подпадающей под действие PIPEDA, не требует каких-либо дополнительных мер в отношении вмешательства со стороны властей.
Тем не менее, OVHcloud внедрил дополнительные меры в соответствии со своей политикой безопасности и стремится получить подтверждение, в частности от Комиссии, последовательности вышеизложенных выводов. В более общем плане было бы желательно, чтобы Комиссия рассмотрела все решения об адекватности, которые были приняты, особенно до постановлений Европейского суда и вступления в силу GDPR.
Клиенты OVHcloud также могут выбрать центры обработки данных, расположенные за пределами Европейского Союза, для размещения своих услуг, особенно в Сингапуре и Австралии. Однако эти центры обработки данных обычно не используются для обработки данных, на которые распространяется GDPR; предпочтение отдается европейским дата-центрам. Однако для клиентов, желающих осуществить такую передачу в Азию, OVHcloud установил стандартные договорные положения. В этих случаях Заказчик должен провести, при необходимости, с помощью OVHcloud анализ соответствия решения, которое он развертывает на Сервисах OVHcloud.
Что касается использования внутренних инструментов OVHcloud, некоторые из которых содержат данные клиента (данные учетной записи клиента, счета-фактуры, заявки в службу поддержки, данные, касающиеся использования услуг и т. Д.), И которые используются другими организациями OVHcloud за пределами Европы, OVHcloud имеет ввести в действие стандартные договорные положения, в дополнение к которым были реализованы различные технические и организационные меры для максимального ограничения передач в соответствии с политикой безопасности OVHcloud.
В частности, OVHcloud систематически выступает за размещение своей ИТ-системы на территории Европейского Союза. Это позволяет целенаправленно избегать массовых переводов, так как в таком случае удаленного доступа переводы являются случайными и временными.
Кроме того, доступ ограничен на основе принципа минимальных привилегий, который гарантирует, что операторам доступны только данные, необходимые для выполнения законных деловых операций. Эти обращения систематически отслеживаются. Кроме того, в случае обращения к сторонним решениям OVHcloud отдает предпочтение локальному размещению на собственной инфраструктуре, чтобы сохранить контроль.
Все эти меры в сочетании с реализацией строгой политики в отношении обработки запросов властей, по-видимому, обеспечивают адекватную защиту от возможного вмешательства властей в неадекватных странах.
Тем не менее, OVHcloud продолжит уделять пристальное внимание рекомендациям властей, чтобы убедиться в правильности своего механизма.
Кроме того, OVHcloud Group обязуется пересмотреть правовой порядок стран, в которых она присутствует, чтобы оценить их соответствие в свете этого нового решения Европейского суда, и быть в состоянии поддержать своих клиентов наилучшим образом.
Немного истории…
Этот случай восходит к 25 июня 2013 года, когда г-н Максимилиан Шремс, гражданин Европы, подал жалобу в Комиссию по защите данных Ирландии с требованием запретить Facebook Ireland Ltd. передавать его личные данные в Соединенные Штаты.
Эта жалоба указывала на массовую слежку со стороны Америки, о которой одновременно сообщил Эдвард Сноуден. Он подчеркнул, что действующие в Соединенных Штатах правила недостаточно регулируют эти программы и не гарантируют субъектам данных права, эквивалентные тем, которые признаны в Европейском союзе.
В первом решении от 6 октября 2015 г. ( C362 / 14 ) Европейский Суд вынес решение в его пользу, признав недействительным Safe Harbor, механизм защиты, реализованный для передачи данных в Соединенные Штаты, который Европейская комиссия сочла адекватным ( решение 2000/520). ).
После этого решения ирландские власти, которые первоначально отклонили жалобу из-за существования Safe Harbor, начали расследование, в ходе которого Facebook Ireland Ltd. затем оправдала введение не Safe Harbor, а стандартных договорных положений в соответствии с те, которые приняты Решением Европейской комиссии 2010/87 / EU, которое, в принципе, должно обеспечивать адекватные гарантии для лиц, затронутых передачей персональных данных в страны, которые не обеспечивают адекватный уровень защиты.
На этот раз Европейский Суд попросили вынести решение о действительности вышеупомянутых стандартных договорных положений, с одной стороны, и «Privacy Shield», нового механизма защиты, созданного тем временем Соединенными Штатами и Комиссией для замены Безопасная гавань.
Аннулирование Privacy Shield
В своем решении от 16 июля Европейский суд постановил немедленно аннулировать Privacy Shield или, точнее, решение ( 2016/1250 ), которым Европейская комиссия установила, что Privacy Shield представляет собой достаточный механизм защиты для регулирования передача персональных данных в США.
В своем решении Европейский суд счел, что программы наблюдения США не ограничиваются тем, что является строго необходимым, поскольку власти могут, в частности, проводить крупномасштабные операции наблюдения, которые не соответствуют принципам необходимости и соразмерности, действующим в Европейский Союз.
Европейский Суд также отметил, что Соединенные Штаты, включая механизм омбудсмена, на который ссылается Решение о защите конфиденциальности, не предоставляют реальной возможности субъектам данных подавать иски в независимый и беспристрастный суд, как это требуется в соответствии с Хартией основных прав Евросоюз.
Действительные, но не всегда достаточные стандартные договорные положения.
Что касается стандартных договорных положений, Европейский суд подтвердил, что они остаются действующим механизмом для защиты передачи персональных данных из Европейского Союза в страны, которые не извлекают выгоду из решения об адекватности. Однако он напомнил, что в соответствии со статьей 46 RGDP сами по себе эти положения не всегда представляют собой достаточную защиту, в частности, в случае передачи данных в страны, которые, как и США, недостаточно регулируют полномочия. вмешательства их властей.
В этом отношении Европейский Суд по существу указывает, что стандартные договорные положения представляют собой договор, заключенный между экспортером, контролирующим данные, и импортером данных, и что этот договор не подлежит исполнению в отношении властей страны, получающей данные; указанные органы не являются стороной контракта.
Таким образом, стандартные договорные положения, хотя и действительны, не являются достаточной гарантией для регулирования передачи персональных данных из Европейского Союза в такие страны, как США. В этом случае должны быть приняты дополнительные меры в дополнение к этим пунктам.
Влияние этих решений
Влияние этого второго опуса отнюдь не незначительно.
Действительно, с 16 июля все экономические операторы, которые ранее передавали персональные данные из Европейского Союза в США на основе Privacy Shield, были обязаны, если они желают продолжить такие передачи, заменить Privacy Shield действующими альтернативными гарантиями.
Однако альтернативные механизмы, которые могут быть введены в действие, перечисленные в статье 46 PGRD и включающие стандартные договорные положения, по большей части являются договорными механизмами, которые Европейский суд сочтет недостаточными из-за их неисполнимости в отношении Власти США.
Следовательно, внедрение этих альтернативных механизмов должно сопровождаться принятием дополнительных мер для обеспечения необходимой защиты.
Тогда возникает вопрос, какие виды мер могут, помимо стандартных договорных положений, представлять собой адекватную защиту от вмешательства со стороны властей США.
Европейский Суд не вынес решения по этому вопросу, а органы по защите данных еще не опубликовали информацию по этому вопросу, что может немного затруднить соблюдение требований.
Говоря конкретно, технически сложно предотвратить доступ властей США к данным, передаваемым из Европейского Союза в Соединенные Штаты, поскольку, как отметил Европейский Суд, власти США перехватывают трафик по сетевым кабелям, особенно в контексте программ разведки и добычи..
В этом отношении даже реализация решений для сквозного шифрования может считаться недостаточной, в частности, из-за решений для дешифрования, которые доступны или могут быть доступны властям, особенно в результате квантовых технологий. Кроме того, некоторые правила могут требовать от операторов передавать свои ключи шифрования властям или даже запрещать некоторые из них в будущем. Соединенные Штаты особенно обсуждают « Закон о законном доступе к зашифрованным данным ».
Альтернативой могло бы стать использование решений, размещенных в Европейском Союзе. Однако нет уверенности даже в том, что этого будет достаточно при любых обстоятельствах, особенно в случае обработки, выполняемой удаленно из Соединенных Штатов, например, в контексте администрирования, обслуживания или поддержки.
Действительно, некоторые операции удаленной обработки, такие как доступ, технически подразумевают временную передачу и, следовательно, раскрывают данные. Более того, это считается передачей данных в смысле европейских правил.
Некоторые субъекты экономической деятельности также сомневаются, можно ли адаптировать дополнительные меры в зависимости от риска для прав и свобод, в частности, чтобы гарантировать, что использование данных с низким риском для частной жизни людей не будет чрезмерно затруднено. Здесь также нет ничего менее уверенного, хотя подход, основанный на оценке риска, который преобладает в RGDP и стандартных договорных положениях, может предполагать это.
За пределами Соединенных Штатов эти вопросы возникают всякий раз, когда осуществляется перевод на основе стандартных договорных положений в страны, в отношении которых не было принято решение о соответствии и для которых невозможно с уверенностью установить, что они предоставляют гарантии, эквивалентные признанным. в пределах Европейского Союза в отношении вмешательства властей.
Неопределенность в отношении типа дополнительных мер, которые необходимо принять, создает незащищенность не только для субъектов данных, которые могут не пользоваться соответствующей защитой при передаче своих данных, но и для экономических операторов, многие из которых все еще ждут подтверждения соблюдения, особенно когда они зависят от сторонних поставщиков услуг или решений, работающих за пределами Европейского Союза.
Таким образом, преобладание — или почти монополия — GAFAM в таких секторах, как онлайн-исследования, социальные сети и реклама, делает чрезвычайно трудным, если не невозможным с точки зрения конкуренции, обходиться без их услуг. И такие услуги обычно включают переводы в Соединенные Штаты, для которых непросто, в частности, из-за упомянутых выше неопределенностей, обеспечить принятие соответствующих дополнительных мер безопасности.
В этом контексте представляется важным, чтобы органы по защите данных продолжали поддерживать экономических операторов, чтобы можно было четко определить и внедрить дополнительные меры, необходимые в случае переводов в США и другие эквивалентные страны.
А как насчет использования служб OVHcloud?
Нет переводов в США
За исключением услуг, заказываемых непосредственно у американского подразделения OVHcloud, в ходе оказания услуг OVHcloud не передает данные своих клиентов в США.
Действительно, центры обработки данных OVHcloud, расположенные в США, не размещают какие-либо услуги, предлагаемые организациями OVHcloud за пределами США; сказал, что центры обработки данных в США используются только для размещения услуг, продаваемых американским подразделением OVHcloud. Кроме того, американское подразделение OVHcloud не участвует в предоставлении услуг, предоставляемых неамериканскими организациями OVHcloud. В частности, ни одна из этих служб не администрируется из Соединенных Штатов, и, следовательно, никакая соответствующая обработка данных не может осуществляться удаленно и, в частности, получать доступ из Соединенных Штатов.
Следовательно, аннулирование Privacy Shield здесь не влияет.
Что касается услуг, заказываемых у американского подразделения OVHcloud, они обычно не используются для обработки данных в соответствии с европейскими правилами, и в этом случае предпочтительны вышеупомянутые европейские решения. Тем не менее, OVHcloud United States, тем не менее, изучает решения для клиентов, на которых это может повлиять.
Ограниченные переводы в другие страны
Когда клиент выбирает услугу, размещенную в центре обработки данных OVHcloud, расположенном в Европейском Союзе, только европейские и канадские подразделения OVHcloud имеют в рамках администрирования и обслуживания услуг возможность выполнять операции обработки данных. размещены у Заказчиков.
В отношении Канады было принято решение об адекватности ( 2002/2 / EC ).
Европейская комиссия особо отметила, что канадское законодательство «охватывает все основные принципы, необходимые для адекватного уровня защиты физических лиц, даже если исключения и ограничения также предусмотрены для защиты важных общественных интересов. Применение этих стандартов гарантируется средствами судебной защиты и независимым надзором со стороны властей, таких как Федеральный комиссар по конфиденциальности, наделенный полномочиями по расследованию и вмешательству ». Более того, положения канадского законодательства о гражданской ответственности применяются в случае незаконной обработки, которая наносит ущерб лицам ».
Кроме того, OVHcloud никогда не получал от канадских властей запросов, которые были бы несоразмерны основным правам и принципам Европейского Союза.
Таким образом, даже если упомянутое решение об адекватности ограничивается сферой деятельности, подпадающей под действие Канадского Закона о защите личной информации и электронных документов (PIPEDA), что побудило OVHcloud принять договорные положения для определенных операций обработки, выходящих за рамки PIPEDA, — вышеизложенные выводы о канадских Закон обязывает считать, что выполнение стандартных договорных положений для деятельности, не подпадающей под действие PIPEDA, не требует каких-либо дополнительных мер в отношении вмешательства со стороны властей.
Тем не менее, OVHcloud внедрил дополнительные меры в соответствии со своей политикой безопасности и стремится получить подтверждение, в частности от Комиссии, последовательности вышеизложенных выводов. В более общем плане было бы желательно, чтобы Комиссия рассмотрела все решения об адекватности, которые были приняты, особенно до постановлений Европейского суда и вступления в силу GDPR.
Клиенты OVHcloud также могут выбрать центры обработки данных, расположенные за пределами Европейского Союза, для размещения своих услуг, особенно в Сингапуре и Австралии. Однако эти центры обработки данных обычно не используются для обработки данных, на которые распространяется GDPR; предпочтение отдается европейским дата-центрам. Однако для клиентов, желающих осуществить такую передачу в Азию, OVHcloud установил стандартные договорные положения. В этих случаях Заказчик должен провести, при необходимости, с помощью OVHcloud анализ соответствия решения, которое он развертывает на Сервисах OVHcloud.
Что касается использования внутренних инструментов OVHcloud, некоторые из которых содержат данные клиента (данные учетной записи клиента, счета-фактуры, заявки в службу поддержки, данные, касающиеся использования услуг и т. Д.), И которые используются другими организациями OVHcloud за пределами Европы, OVHcloud имеет ввести в действие стандартные договорные положения, в дополнение к которым были реализованы различные технические и организационные меры для максимального ограничения передач в соответствии с политикой безопасности OVHcloud.
В частности, OVHcloud систематически выступает за размещение своей ИТ-системы на территории Европейского Союза. Это позволяет целенаправленно избегать массовых переводов, так как в таком случае удаленного доступа переводы являются случайными и временными.
Кроме того, доступ ограничен на основе принципа минимальных привилегий, который гарантирует, что операторам доступны только данные, необходимые для выполнения законных деловых операций. Эти обращения систематически отслеживаются. Кроме того, в случае обращения к сторонним решениям OVHcloud отдает предпочтение локальному размещению на собственной инфраструктуре, чтобы сохранить контроль.
Все эти меры в сочетании с реализацией строгой политики в отношении обработки запросов властей, по-видимому, обеспечивают адекватную защиту от возможного вмешательства властей в неадекватных странах.
Тем не менее, OVHcloud продолжит уделять пристальное внимание рекомендациям властей, чтобы убедиться в правильности своего механизма.
Кроме того, OVHcloud Group обязуется пересмотреть правовой порядок стран, в которых она присутствует, чтобы оценить их соответствие в свете этого нового решения Европейского суда, и быть в состоянии поддержать своих клиентов наилучшим образом.