Как сделать диагностику отказов надёжной с помощью Pensive AI26.10.2026 19:01

[не удалось получить полный текст]

Авторы: Praneeth Yenugutala, Victor Dusa, Anastasia Samoilova, Megan Ren, Justin Wei, Marcelo Mayworm

В Netflix специалисты по данным и машинному обучению ежедневно запускают миллионы задач в системах оркестрации и вычислительных средах, таких как Titus, Spark, Trino и Druid. В дни пиковой нагрузки сбоями заканчиваются примерно 100 000 задач. Однако сам сбой — лишь начало. Кому-то ещё нужно найти полезный сигнал в нескольких журналах, определить, связана ли причина с кодом или платформой, и решить, следует ли повторить попытку, изменить конфигурацию или передать проблему дальше. Даже небольшая доля сложных сбоев может отнимать время инженеров, расходовать вычислительные ресурсы и прерывать критически важные конвейеры обработки данных.

Первым решением этой проблемы стала система Pensive для автоматической диагностики и устранения проблем на платформе данных Netflix. Pensive собирала журналы неудачно завершившихся задач, использовала регулярные выражения и написанные вручную правила на Java для извлечения и классификации ошибок, а затем передавала рекомендации по повторному запуску или устранению проблем таким продуктам, как Maestro. Благодаря системе около 50% сбоев можно было устранять самостоятельно, а в некоторых случаях — автоматически.

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

Чтобы решить эту неоднозначную и сложную задачу в масштабах Netflix, мы вложили силы в Pensive AI, добавив извлечение ошибок с помощью ИИ и целевые рекомендации по диагностике и устранению проблем для специалистов по данным и машинному обучению. Цель заключалась не просто в том, чтобы поставить модель перед большим массивом журналов. Нам требовались ограниченное извлечение данных, предсказуемые входные данные для оценки, отзывчивая работа продукта и проверки качества, сопровождающие систему на всех этапах — от локальной разработки до эксплуатации. Эти требования определили каждый уровень архитектуры, о которой мы расскажем в этой статье. Pensive AI дополняет детерминированные процессы возможностями ИИ, что обеспечивает более широкий охват, низкую задержку, контролируемые расходы на ИИ и более простое сопровождение на протяжении всего жизненного цикла разработки ПО. На этой основе мы планируем изучить более агентные сценарии отладки, о которых говорится в части 6.

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

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

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

Часть 1. Поиск полезных ошибок

Правила прежней версии Pensive точны, но каждое из них рассчитано на определённую структуру журнала. Упрощённый вариант правила выглядит так:

- name: SparkContainerOOM
logSource: GENIE_STDERR
restartable: false
regex: "Container.*is running beyond physical memory limits.*Killing container"
summary: Spark AM container runs out of memory

С помощью Pensive AI мы хотели находить полезные ошибки, для которых ещё не было соответствующих правил, и проще адаптироваться к изменению структуры знакомых ошибок после обновления платформы. Data Portal (наш интерфейс для конвейеров обработки данных) показывает извлечённые ошибки, если они доступны, и содержит ссылки на исходные журналы, предоставляя специалистам отправную точку для сортировки проблем. Возникает вопрос: как попросить модель определить ошибку, не заставляя её пословно воспроизводить длинную трассировку стека?

Генерация выходных токенов намного медленнее, чем чтение входных. Прямое копирование текста сделало бы обработку длинных ошибок дорогой и медленной. Вместо этого Pensive нумерует строки каждого журнала и передаёт модели последовательность записей {lineNumber, text}. Модель определяет первую и последнюю строки фрагмента с ошибкой, а Pensive извлекает выбранный текст из собственной копии журнала, снижая затраты и задержку. Таким образом, модель всегда возвращает два целых числа — номера начальной и конечной строк, — независимо от того, охватывает выбранный фрагмент несколько строк или несколько сотен. Отображаемый текст берётся непосредственно из исходного журнала, что снижает вероятность галлюцинаций. Модель всё же может выбрать неверный диапазон, поэтому качество извлечения остаётся важным показателем наших оценок ИИ, о чём мы расскажем далее.

В оркестрируемых рабочих процессах функция «Pensive AI Error Extraction» запускается автоматически при каждом сбое шага. Попытка выполнения шага — это один запуск шага в рабочем процессе Maestro. Maestro и так обращается к Pensive, чтобы получить определённую регулярными выражениями ошибку и классификацию возможности перезапуска, поэтому извлечение с помощью ИИ выполняется в рамках того же запроса и возвращает результаты вместе с уже существующими полями. Общий ответ Pensive должен быть сформирован в пределах жёсткого 90-секундного тайм-аута постобработки Maestro для неудачной попытки выполнения шага.

Рисунок 2. Извлечение ошибок. Устаревшие правила выполняются всегда. Вызов ИИ ограничен общим сроком ожидания, а запоздавшие вызовы не учитываются. Pensive объединяет оба результата в один ответ и кэширует его.

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

Не менее тщательно нужно было продумать контракт данных между Pensive AI и различными потребителями. Прежняя модель данных содержала одну объединённую строку ошибки; извлечение с помощью ИИ вместо этого возвращает список ошибок — по одной для каждого источника журналов, — со ссылками на исходные журналы. Изменение старого поля нарушило бы работу существующих клиентов. Мы добавили новую модель данных рядом с прежней моделью данных для извлечения ошибок без ИИ и продолжили формировать обе. В ходе внедрения Data Portal, наш пользовательский интерфейс для мониторинга и наблюдения за конвейерами обработки данных, отдавал предпочтение ошибкам ИИ, если они были доступны, и при их отсутствии использовал прежнее значение. Это позволило внедрять систему постепенно и гарантировало, что для исторических сбоев по-прежнему отображается ошибка: мы решили не заполнять старые данные задним числом из-за ограничений срока хранения журналов.

Переход продолжается и сегодня. Интерфейс Data Portal для неудачно завершившихся шагов Maestro уже использует новое поле извлечённых с помощью ИИ ошибок, а редактор запросов (для редактирования и выполнения SQL), записные книжки Workbench (управляемая вычислительная платформа и интерфейс для редактирования и выполнения записных книжек на основе Jupyter) и некоторые клиенты Slack, обращающиеся к Pensive, по-прежнему используют прежний механизм извлечения ошибок. Прежде чем работать с новыми данными, каждому клиенту необходимо внести совместимое изменение схемы. Наличие обоих заполненных полей позволяет командам переходить на новое поведение в удобном темпе, не требуя согласованного одномоментного переключения, пока мы продолжаем развивать Pensive AI.

Часть 2. Полная диагностика сбоев и взаимодействие с продуктом

Помимо извлечения ошибок, мы создали Pensive AI Debugging — инструмент, который анализирует неудачные попытки выполнения шагов, определяет первопричины и предлагает способы устранения проблем. Он доступен через программные API, MCP и пользовательский интерфейс продукта (Data Portal); все эти способы опираются на общую точку входа в платформу данных Netflix. Такая общая модель обеспечивает единообразное поведение и позволяет создавать индивидуальные интерфейсы для продуктов.

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

Такой подход даёт нам стабильную единицу работы для кэширования. Мы кэшируем каждый ответ для отладки по попытке выполнения шага. Второй запрос превращается в чтение пары «ключ — значение», а не в новый вызов ИИ для вывода. Кэш также предотвращает дублирование работы, дополнительно снижая задержку и затраты. Это означает, что результат отладки, сформированный в Data Portal, кэшируется и сразу возвращается при запросе через MCP, без дополнительного вызова ИИ для вывода. Условная запись создаёт запись о выполняющейся операции: один вызывающий клиент начинает генерацию, а остальные ждут общего результата, чтобы избежать конфликтов при одновременных запросах для одного и того же сбоя попытки выполнения шага. Если генерация продолжается дольше установленного тайм-аута отказа от операции, Pensive считает запись заброшенной и перехватывает её. Сформированные ответы удаляются через 90 дней, чтобы контролировать затраты и оптимизировать хранение: запросы на отладку для гораздо более старых задач встречаются редко.

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

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

Для пользователей важнее всего, чтобы долгий ответ воспринимался как процесс, который продолжается. Pensive передаёт ответ потоком по мере его формирования. Сервис отправляет события, инициируемые сервером, а уровень GraphQL публикует их заново в виде подписки WebSocket для клиента Data Portal.

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

Часть 3. Оценка и улучшение нужного нам поведения

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

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

Стабильные входные данные необходимы для воспроизводимых экспериментов по оценке, в ходе которых мы проводим A/B-тестирование новых моделей, конфигураций или добавляемого контекста, чтобы повысить качество ответов. Срок хранения журналов, используемых Pensive AI, может составлять от семи до 30 дней. Во время выполнения задачи рабочие запросы Pensive AI асинхронно архивируют полученные журналы в объектном хранилище S3, чтобы загрузка не попадала на критический путь взаимодействия с пользователем. Загрузка не перезаписывает существующий объект, сохраняя точный снимок данных, использованный для создания примера оценки. Оценки используют эти архивные журналы, поэтому изменения показателей можно отнести к тестируемой системе. Архив также не позволяет параллельным экспериментам перегружать исходные системы и даёт возможность запускать их без влияния на рабочую среду. Кэширование входных данных журналов в S3 дополнительно снижает затраты на проведение оценок.

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

• Полнота: LLM-оценщик сравнивает прежнюю ошибку Pensive для сбоя с ошибками, извлечёнными Pensive AI, и определяет, продолжает ли известная ошибка присутствовать в результатах, даже если формулировки различаются.
• Точность: Второй оценщик видит только извлечённые ИИ ошибки и проверяет, является ли каждая из них значимой и применимой сама по себе.
• Повторяющийся шум: Скрипт анализирует весь набор данных и ищет строки, которые встречаются слишком часто. Общая строка состояния может выглядеть безобидно в одном ответе, но отвлекать, если она присутствует в значительной доле сбоев. Строки, появляющиеся более чем примерно в 30% рабочих процессов, могут быть явно исключены. На практике в список исключений входят всего три строки, каждая из которых иначе присутствовала бы почти в каждой извлечённой ошибке.
• Задержка: Мы фиксируем задержку каждого вызова извлечения. Одни лишь показатели качества не показывают, когда кажущееся улучшение требует слишком больших дополнительных затрат труда, что часто связано с ростом расходов на ИИ.

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

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

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

Часть 4. Контроль качества на этапе выпуска

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

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

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

Часть 5. Поиск сигналов обратной связи от пользователей

Система ценна лишь в том случае, если она сокращает объём ручной отладки и поиска по журналам, который приходится выполнять пользователям. Нам требовался показатель, доступный в продуктовой телеметрии и непосредственно связанный с поведением, которое Pensive AI призвана изменить. Одним из главных показателей стало количество действий по ручному изучению журналов отладки. Интерфейс Pensive уже содержит ссылки на журналы неудачно завершившихся попыток выполнения шагов. Чтобы оценить, насколько функция сократила поиск по необработанным журналам, мы сравнили неудачные попытки, в которых кто-то взаимодействовал с Pensive AI, с теми, где этого не происходило. Во второй группе в среднем было на 321% больше действий по ручному изучению журналов отладки. Это наблюдательное сравнение не доказывает причинно-следственную связь и не показывает конкретного сокращения среднего времени решения проблемы, но позволяет предположить, что целевая диагностика часто помогает специалистам изучить меньше необработанных журналов. Программный доступ через MCP также позволяет командам создавать операционные сценарии с терминалами или индивидуальные агентные решения на основе той же службы диагностики.

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

Рисунок 4. Цикл обратной связи. Оценка «палец вверх» или «палец вниз» связывается с точной трассировкой LLM, создавшей ответ, по тому же logId, который присваивается во время генерации. Трассировки и отзывы пополняют эталонные наборы данных и наборы для оценки, а каждый ответ с оценкой «палец вниз» вызывает уведомление в Slack в рабочее время.

Часть 6. Дальнейшая работа на основе заложенного фундамента

Pensive AI создаёт основу для дальнейшей работы, выходящей за рамки диагностики и рекомендаций по устранению проблем. Мы изучаем «Pensive AI Deepthink» — управляемый агентный сценарий, который пользователь сможет подключить по желанию и который потребует больше ресурсов и времени. Он основан на точном анализе с низкой задержкой, выполняемом Pensive AI Debugging, и собирает дополнительный контекст из внутренней документации, руководств, прошлых обсуждений в Slack, исходного кода, запросов к хранилищу данных только для чтения и сведений о выполнении Spark. Этап маршрутизации направляет расследование к подходящему специализированному модулю, например для сбоев Spark, ошибок аудита данных или задержек рабочих процессов. Это позволяет сохранить стабильную и детерминированную исходную точку, одновременно специализируя расследование и повышая полноту выявления проблем. Мы также обсуждаем с командой Spark возможность использовать ответы Pensive AI для анализа сбоев и A/B-сравнения в ходе предстоящих миграций платформы.

Мы также планируем развивать «Pensive AI Error Classification». Устаревшие правила, которые сложно поддерживать, классифицируют сбои по возможности перезапуска и по тому, вызваны ли они платформой или пользователем. Maestro использует эти метки и соответственно меняет поведение при повторных попытках, например прекращает выполнение при первом сбое или настраивает число повторов по умолчанию (по умолчанию для ошибок платформы выполняется больше попыток, чем для ошибок пользователя). Классификация ошибок должна соответствовать более высоким требованиям, чем одно лишь извлечение ошибок и отладка. Перевод большей части классификации ошибок на ИИ позволил бы отказаться от большинства оставшихся правил, требующих постоянного сопровождения, и не повторять попытки для неизвестных сбоев, которые вряд ли удастся устранить. При определении возможности перезапуска самая дорогая ошибка — классифицировать сбой, который можно устранить, как не подлежащий перезапуску: Maestro превратит шаг, который можно было восстановить, в окончательный сбой, что приведёт к оповещениям конечных пользователей и ручному устранению проблемы. Прежде чем поручать такие решения классификации на основе ИИ, необходимо настроить систему оценки с учётом этого последствия. Не менее важно избегать повторных попыток при непостоянных сбоях, которые не удастся устранить: повторы расходуют вычислительные ресурсы и задерживают конвейеры обработки данных.

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

Часть 7. Благодарности

Эта работа была бы невозможна без наших замечательных коллег из Data Platform и партнёров из Data Engineering и Analytics, которые предоставляли отзывы на раннем этапе. Мы не можем перечислить всех поимённо, но глубоко признательны им за вклад, повлиявший и на качество ответов, и на взаимодействие с продуктом. Особая благодарность Adith Swaminathan за рекомендации по оценке и улучшению вывода моделей, а также за содержательное сотрудничество. Благодарим участников команды Orchestration, особенно Deepak Ramalingam и Malcolm Ramirez, за дополнительный инженерный вклад.

Мы также благодарим организацию инженерной поддержки (команду ESO) за практическое тестирование Pensive AI и её интеграцию в поддержку пользователей. Спасибо Abhishek Kapatkar (команда Data Developer Experiences) и Emmie Dong (команда Data Movement) за отзывы, которые помогли улучшить интеграцию Pensive AI с остальной экосистемой. Особая благодарность команде AI Platform (Kyle Ahn, Rob Mann) и команде Braintrust за помощь с распределённой трассировкой, инфраструктурой оценок и поддержкой среды выполнения шлюза моделей.

Мы также благодарим Kamran Masood, Ely Spears, Ronald Leung, Anjali Norwood, Prashanth Ramdas, Charles Smith, Harikrishna Menon и других руководителей за конструктивные отзывы и поддержку проекта Pensive AI.

Статья «Как сделать диагностику сбоев надёжной с помощью Pensive AI» впервые опубликована в Netflix TechBlog на Medium, где читатели продолжают обсуждать её, выделяя фрагменты и отвечая на них.

© Netflix Tech Blog