Это — первый материал из серии статей, посвящённой использованию анализа данных и машинного обучения (Machine Learning, ML) в Netflix. Мы применяем то, о чём собираемся рассказать, совершенствуя автоматизацию оперативной деятельности. Делается это ради повышения производительности и экономической эффективности задач, связанных с обработкой больших данных. В понятие «автоматизация оперативной деятельности», кроме прочих, входят следующие операции: диагностика систем, исправление сбоев, конфигурирование, настройка, масштабирование, отладка, тестирование. Всё это — та база, от которой зависит успешность современных платформ, ориентированных на обработку данных. В этом материале речь пойдёт о нашем проекте Auto Remediation, направленном на автоматическое восстановление задач после сбоев. В соответствующую систему интегрированы классификатор ошибок, основанный на правилах, используемый в настоящий момент, и ML‑служба. Цель этой системы заключается в автоматическом восстановлении работоспособности заданий, с которыми что‑то случилось. Мы развернули систему Auto Remediation в продакшне для того, чтобы исправлять с её помощью ошибки заданий Spark. Это — ошибки, связанные с настройками памяти, и неклассифицированные ошибки. Система доказала свою эффективность. Так — было автоматически исправлено 56% ошибок, связанных с памятью, на 50% снижены расходы, вызванные всеми ошибками. Мы, кроме того, видим в Auto Remediation большой потенциал для дальнейшего развития.

Введение

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

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

По мере того, как росли размеры и сложность нашей системы, классификатор, основанный на правилах, столкнулся с определёнными проблемами, связанными с тем, что он поддерживал автоматизацию оперативных задач лишь в ограниченном объёме. Особенно это касалось ошибок, связанных с настройками памяти, и ошибок неизвестного типа. В результате наблюдалась прямая зависимость между ростом операционных расходов и количеством заданий, дававших сбои. В некоторых случаях, например, диагностика и восстановление заданий, давших сбой из‑за ошибок, связанных с нехваткой памяти (Out‑Of‑Memory, OOM), требовали совместных усилий нескольких команд. Причём, к решению проблемы привлекались не только сотрудники, использующие соответствующие системы, но и инженеры службы поддержки, и предметные специалисты.

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

• Интеграция знаний об ошибках, уже имеющихся в компании, и возможностей машинного обучения. Вместо того чтобы полностью отказаться от используемого в текущий момент классификатора, основанного на правилах, в Auto Remediation включили и классификатор, и ML‑службу. В результате Auto Remediation может использовать достоинства обеих подсистем. Классификатор даёт статические, определяемые правилами, сведения о классах ошибок. Эти правила сформированы с участием предметных специалистов. А ML‑служба даёт, относительно каждого задания, рекомендации, учитывающие вопросы производительности системы и стоимости её поддержки. Здесь уже используются возможности машинного обучения. Благодаря интеграции классификатора и ML‑сервиса мы можем адекватно выполнять требования по устранению различных ошибок.

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

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

То, что система действительно обладает вышеозначенными возможностями, подтверждено её практическим использованием в продакшне, где она применяется для борьбы со сбоями задач Spark. Наши наблюдения показывают, что Auto Remediation способна справиться с 56% всех ошибок, связанных с настройками памяти. Делается это путём применения рекомендованных системой настроек памяти без вмешательства человека. Кроме того, её использование приводит к 50% экономии. Это так из‑за того, что система способна рекомендовать новые настройки, применение которых повышает стабильность работы заданий и избавляет нас от необходимости перезапуска заданий из‑за неклассифицированных ошибок. Мы, кроме того, отмечаем значительный потенциал совершенствования системы за счёт тюнинга модели (смотрите раздел «Развёртывание в продакшне»).

Классификатор, основанный на правилах: особенности функционирования и обзор важнейших проблем

Особенности функционирования

На рисунке показан служба классификации ошибок Pensive, входящая в состав платформы по работе с данными Netflix. Она использует классификатор ошибок, основанный на правилах, и состоит из трёх компонентов:

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

• Средство для проведения проверок (Rule Execution Engine). Оно отвечает за сопоставление данных, присутствующих в собранных логах, с набором правил. В состав правила входят два блока сведений. Первый — это имя правила, его источник, лог, сводные данные об ошибке, и о том, возможен ли перезапуск задания после возникновения этой ошибки. Второй — это регулярное выражение, позволяющее распознать сообщение об ошибке в логе. Например, правило с именем SparkDriverOOM включает в себя следующие сведения: если лог задания Spark, выводимый в stdout, содержит текст, соответствующий регулярному выражению SparkOutOfMemoryError:, то ошибку нужно отнести к классу пользовательских ошибок, которые не поддаются исправлению путём перезапуска задания.

• Средство для итоговой обработки результатов (Result Finalizer). Здесь производится итоговая обработка результата классификации ошибки, основанных на выявленном совпадении сообщения об ошибке с неким правилом. Если обнаружено совпадение сообщения об ошибке с одним или несколькими правилами, тогда итоговый результат определяется классификацией ошибки, задаваемой первым правилом (в том случае, если приоритет правил определяется порядком их проверки, и первому правилу назначается наивысший приоритет). А если не найдено ни одного совпадения с правилами — ошибка считается неклассифицированной.

Обзор важнейших проблем

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

• Ошибки, связанные с настройками памяти. Классификатор ошибок, основанный на правилах, выдаёт результаты анализа ошибки, указывающие на то, нужно ли перезапустить задание. Но, в случае с появлением ошибок, которые возникают регулярно, система рассчитывает на инженеров, которые перезапускают сбойное задание вручную. Самый заметный пример — это ошибки, связанные с конфигурированием памяти. Такие ошибки обычно вызывает неправильная настройка памяти конкретного задания. Если дать заданию слишком мало памяти — это может привести к OOM‑ошибкам. Выделение неоправданно большого объёма памяти приведёт к пустой трате ресурсов вычислительного кластера. Особую сложность в борьбе с такими ошибками представляет то, что некоторые ошибки, связанные с настройками памяти, требуют изменения состояния нескольких параметров.
  
  В результате для того, чтобы правильно настроить параметры, связанные памятью, нужно не только что‑то менять вручную. Нужно ещё и очень хорошо разбираться в том, как именно выполняются задания Spark. Кроме того, даже если настройка памяти задания изначально учитывает все тонкости выполнения этого задания, различные изменения, вроде изменений размера данных, или определения задания, могут приводить к падению производительности. На платформе обработки данных Netflix ежемесячно выявляется около 600 ошибок, связанных с настройками памяти. Поэтому одно только своевременное исправление ошибок, вызванных неправильной настройкой памяти, требует нетривиальных инженерных решений.

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

Путь к Auto Remediation: архитектура службы

Подход к решению проблем

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

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

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

Интеграция служб

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

• Nightingale — это служба, в которой выполняется ML‑модель, обученная с использованием Metaflow, ответственная за генерирование рекомендаций по перезапуску заданий. В состав рекомендации входят, во первых — сведения о том, можно ли исправить ошибку путём перезапуска задания; и, во‑вторых — если это так — рекомендованная конфигурация настроек, с которой нужно перезапустить задание.

• ConfigService — это конфигурационная служба, к которой можно обращаться в любое время. Рекомендованные настройки сохраняются в ConfigService в формате JSON Patch с областью применения, позволяющей определить задания, которые могут использовать эти настройки. Когда служба Scheduler делает запрос к ConfigService для получения рекомендованных настроек, Scheduler передаёт ConfigService исходные настройки, а ConfigService возвращает изменённые настройки, применяя JSON‑патч к исходным настройкам. После этого Scheduler может перезапустить задание, используя изменённые настройки (в состав которых теперь входят рекомендованные настройки).

• Pensive — это служба определения типов ошибок, в которой применяется классификатор, основанный на правилах. Она обращается к Nightingale для получения рекомендаций и сохраняет их в ConfigService, после чего они могут быть использованы службой Scheduler для перезапуска заданий.

• Scheduler — это сервис, ответственный за планирование заданий (текущая его реализация выполнена с использованием Netflix Maestro). Каждый раз, когда задание даёт сбой — Scheduler обращается к Pensive для получения классификации возникшей ошибки, которая помогает ему принять решение о том, нужно ли перезапускать задание. Далее — Scheduler обращается к ConfigService, запрашивая настройки, которые рекомендовано использовать при перезапуске задания.

На вышеприведённом рисунке показана последовательность обращений к службам при работе системы Auto Remediation. Вот что тут происходит:

1. После сбоя задания служба Scheduler обращается к Pensive для получения классификации ошибки.

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

3. Pensive, получив рекомендации, обновляет результат классификации ошибки, и сохраняет рекомендованные настройки в ConfigService. Затем Pensive возвращает результат классификации ошибки службе Scheduler.

4. Scheduler, на основе результатов классификации ошибки, полученных от Pensive, решает, нужно ли перезапускать задание.

5. Прежде чем перезапустить задание, Scheduler обращается к ConfigService для получения рекомендованных настроек и перезапускает задание с их использованием.

Путь к Auto Remediation: ML-служба

Обзор

ML‑служба, то есть — Nightingale, ориентирована на генерирование правил восстановления заданий, давших сбой. Эти правила представляют собой компромисс между вероятностью успешного восстановления задания и связанными с этим затратами. Эта служба включает в себя два основных компонента:

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

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

Прогностическая модель ежедневно, в локальном режиме, переобучается. К ней обращается оптимизатор для получения оценки каждого из потенциально подходящих наборов значений конфигурационных параметров. Код оптимизатора выполняется в RESTful‑службе, вызываемой при отказе задания. Если в ходе оптимизации удаётся найти приемлемую конфигурацию настроек — в ответ оптимизатора включаются соответствующие рекомендации. ConfigService использует их для изменения конфигурации, применяемой для перезапуска задания. Если приемлемую конфигурацию найти не удаётся, то есть — другими словами — если перезапуск вряд ли будет удачным только из‑за изменения настроек Spark — в состав ответа оптимизатора включается флаг, указывающий на то, что перезапуски сбойного задания делать не нужно. Это позволяет избежать бессмысленной траты вычислительных ресурсов.

Прогностическая модель

Учитывая то, что мы хотим исследовать вопрос о том, как вероятность успешного перезапуска задания и стоимость перезапуска изменяются в сценариях, предусматривающих использование различных конфигураций, нам нужен какой‑то способ прогнозирования этих двух значений с использованием информации о задании, которая у нас имеется. Платформа обработки данных Netflix логирует сведения и о том, насколько успешным был запуск задания, и о том, сколько стоит выполнение задания. Это даёт нам надёжные метки, с которыми можно работать дальше. Мы используем один и тот же набор признаков для прогнозирования обоих целевых значений, у нас имеются качественные метки, нам, для соблюдения требований SLO, нужно, чтобы модель быстро, сразу после обращения к ней, формировала ответ. Учитывая вышесказанное, мы решили сформулировать нашу проблему в виде задачи, решаемой путём контролируемого обучения ML‑модели, имеющей несколько выходов. В частности — мы воспользовались простым многослойным перцептроном с двумя выходами — по одному для прогнозирования каждого из интересующих нас значений.

Обучение

Каждая запись в наборе обучающих данных содержит сведения о потенциальном перезапуске задания, которое ранее дало сбой из‑за ошибок, связанных с настройками памяти, или из‑за неклассифицированных ошибок. Здесь применяются метки, показывающие, во‑первых — был ли неудачным перезапуск, и во‑вторых — стоимость перезапуска. Исходные входные признаки модели — это, в основном, неструктурированные метаданные, касающиеся задания. Это, в частности, план выполнения Spark, сведения о пользователе, запустившем задание, конфигурационные параметры Spark и другие свойства задания. Мы делим эти признаки на те, которые можно распарсить, приведя к числовым значениям (вроде параметров среды выполнения Spark, касающихся памяти), и на те, которые в виде чисел не выразить (наподобие имени пользователя). Для обработки нечисловых значений мы применяем хеширование признаков, так как они принадлежат наборам значений, отличающихся высоким уровнем изменчивости. Затем мы создаём эмбеддинг более низкой размерности, который конкатенируется с нормализованными числовыми значениями и передаётся ещё через несколько слоёв.

Формирование результатов

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

Оптимизатор

Когда задание даёт сбой — оптимизатор отправляет к Nightingale запрос, содержащий идентификатор задания. Служба, используя этот идентификатор, конструирует вектор признаков, который будет использоваться при выполнении обращений к модели с целью получения результатов её работы. Как уже было сказано, некоторые из этих признаков — это параметры конфигурации Spark, которые являются кандидатами на изменение (например — это spark.executor.memory, spark.executor.cores). Формирование набора конфигурационных параметров Spark основано на знаниях предметных специалистов, которые плотно занимаются тонкой настройкой производительности Spark. Для исследования пространства конфигураций и генерирования рекомендаций мы используем байесовский оптимизатор (реализованный с использованием библиотеки Meta Ax). На каждой итерации оптимизатор генерирует комбинацию значений параметров, которые могут подойти для перезапуска задания. Например — spark.executor.memory=7192 mb, spark.executor.cores=8. Затем оптимизатор анализирует сгенерированную комбинацию значений, обращаясь к прогностической модели для того, чтобы оценить вероятность неудачного перезапуска задания и стоимость перезапуска (то есть — изменяя значения в векторе признаков). После того, как будет выполнено заданное заранее фиксированное количество итераций, если удаётся найти приемлемый набор параметров, оптимизатор возвращает «наилучшее» конфигурационное решение (то есть — то, которое минимизирует целевой показатель, учитывающий вероятность сбоя при перезапуске и стоимость перезапуска задания). Этот набор параметров предназначен для ConfigService. Если же приемлемого набора параметров найти не удалось — мы отключаем перезапуски задания.

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

Развёртывание в продакшне

Мы развернули Auto Remediation в продакшне для того, чтобы автоматизировать восстановление заданий Spark после сбоев, вызванных неклассифицированными ошибками и ошибками, связанными с памятью. Мы, внедряя Auto Remediation, стремились обеспечить устойчивую работу заданий и экономическую эффективность наших систем. Но нас волновал и вопрос о том, как эта система повлияет на сотрудников Netflix:

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

• Если говорить о неклассифицированных ошибках — тех, которые нельзя распознать, используя классификатор, основанный на правилах, то, анализируя их, система Auto Remediation способна выдавать рекомендации относительно их перезапуска. В частности, если ML‑модель прогнозирует высокую вероятность неудачи при перезапуске задания, система рекомендует отключить автоматический перезапуск, что способно сэкономить ресурсы, которые в противном случае тратились бы на безуспешный перезапуск заданий. В некоторых случаях речь идёт о критически важных заданиях, и о ситуациях, когда наши сотрудники решают перезапускать задания даже тогда, когда вероятность их успешного перезапуска невысока. В таких обстоятельствах можно добавить в классификатор, основанный на правилах, новое правило, что приведёт к тому, что в том случае, когда подобная ошибка будет выявлена классификатором в следующий раз, система примет решение по этой ошибке без обращения к ML‑службе. В описанной ситуации хорошо видны сильные стороны решения, в котором используются и знания об ошибках, уже имеющиеся в компании, и возможности машинного обучения.

Развёртывание Auto Remediation в продакшне показало, что система способна подбирать адекватные и эффективные настройки для исправления ошибок, связанных памятью, успешно решая 56% подобных проблем без участия человека. Применение системы, кроме того, привело к 50% снижению расходов на обеспечение работы этих заданий, так как она способна не только рекомендовать настройки, использование которых приводит к успешному перезапуску заданий, но и отключать бесполезные перезапуски. Баланс между эффективностью работы заданий и стоимостью их выполнения можно настраивать. Поэтому мы, используя Auto Remediation, можем принять решение о том, чему отдать приоритет: более высокому уровню успешных перезапусков задач, или более высокому уровню экономической эффективности.

Стоит отметить, что в нашу ML‑службу в настоящий момент внедряется консервативная политика, связанная с отключением перезапусков заданий. Как обсуждалось выше — это сделано для снижения воздействия сбоев на систему в тех случаях, когда наши сотрудники решают всегда перезапускать некие задания. Возникновение таких ситуаций вполне ожидаемо, действовать в них можно, добавляя в классификатор новые правила. Но мы решили, что пользовательский опыт наших сотрудников будет улучшен, если мы займёмся поэтапной подстройкой целевой функции ради постепенного отказа от всё большего количества перезапусков заданий. Учитывая консервативность текущей политики, касающейся отказа от перезапусков заданий, в Auto Remediation виден большой потенциал обеспечения гораздо большей экономии без нанесения ущерба удобству работы наших сотрудников.

Автоматизация за пределами обработки ошибок: система Right Sizing

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

Один из наших проектов, названный Right Sizing, направлен на изменение конфигурации запланированных заданий по обработке больших объёмов данных. Изменения конфигурации заключаются в том, чтобы для выполнения заданий запрашивались бы реально необходимые объёмы ресурсов. Например, мы заметили, что средний размер памяти, запрашиваемый у среды выполнения заданий Spark, примерно в четыре раза больше максимального размера памяти, реально необходимого заданиям. Это указывает на серьёзный перерасход ресурсов. В дополнение к настройкам самих заданий, можно, ради экономии и борьбы с перерасходом ресурсов, поменять и настройки контейнеров, в которых выполняются задания. Используя эвристические методы и методы машинного обучения, мы можем находить подходящие комбинации параметров, влияющих на выполнение заданий. Это позволит уменьшить перерасход ресурсов и сэкономить миллионы долларов в год, не ухудшая производительности наших систем. Эти настройки, подобно тем, с которыми работает Auto Remediation, могут применяться автоматически, с использованием ConfigService. Сейчас мы работаем над системой Right Sizing. Подробности о ней мы планируем раскрыть в одной из наших следующих публикаций. Оставайтесь на нашей волне!