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

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

• AI-открытый алгоритм балансировки нагрузки в MoE-моделях оказался в 5 раз быстрее, но вызвал споры о том, действительно ли это «открытие» или просто удачная генерация кода.
• Критика в том, что LLM не «открывает» алгоритмы, а лишь генерирует код, который может быть удачным, и что человеческий экспертизе все еще необходима, чтобы проверить и понять этот код.
• Обсуждение также подняло вопрос о том, что если LLM может предложить алгоритм, то он должен быть в состоянии объяснить, как он работает, и что это может быть критично для безопасности и надежности системы.
• Некоторые комментаторы подчеркнули, что вместо того, чтобы полагаться на «открытие» алгоритма, стоит ли это вообще обсуждать, какие именно критерии безопасности и эффективности мы хотим, чтобы будущие системы могли бы быть устойчивы к подобным «открытиям».

Databricks разработала умную систему балансировки нагрузки для Kubernetes, которая эффективно распределяет трафик между тысячами кластеров. Вместо стандартного подхода с использованием Ingress-контроллеров они создали собственное решение на основе Envoy Proxy и внутреннего сервиса Discovery. Это позволяет динамически обновлять конфигурации маршрутизации без перезагрузки, что критично для среды с постоянными изменениями кластеров.

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

• Обсуждаются клиентские решения для балансировки нагрузки в gRPC, такие как kuberesolver и xDS-резолвер, как альтернативы сервисным мешам для снижения операционной сложности.
• Отмечается, что стандартные механизмы Kubernetes (kube-proxy, Headless Service) ограничены базовыми алгоритмами и не поддерживают сложные сценарии балансировки.
• Поднимается вопрос, почему не используется Rendezvous hashing (HRW), на что следует ответ, что для сложных требований (зональная аффинность, проверки здоровья) простого хеширования недостаточно.
• Указывается на проблему масштабирования при прямом обращении клиентов к API Kubernetes и преимущества использования xDS для получения обновлений о состоянии эндпоинтов.
• Обсуждаются операционные недостатки полного сервисного меша (сложность, стоимость) и тренд на внедрение только необходимых частей (например, xDS) напрямую в клиенты.

Анализ трёх недавних проблем

С 17 сентября 2025 года

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

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

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

Хронология событий

Наложение этих ошибок значительно усложнило диагностику. Первая ошибка появилась 5 августа, затронув около 0,8% запросов к Sonnet 4. Две другие возникли 25-26 августа.

Изменение балансировки нагрузки 29 августа увеличило количество затронутых запросов, что привело к противоречивым отчетам пользователей.

Три перекрывающиеся проблемы

1. Ошибка маршрутизации контекстного окна

5 августа некоторые запросы Sonnet 4 перенаправлялись на серверы, настроенные для контекстного окна в 1 млн токенов. Изначально ошибка затрагивала 0,8% запросов, но к 31 августа эта доля выросла до 16%.

Около 30% пользователей Claude Code столкнулись с ухудшением ответов. На Amazon Bedrock пик затронутых запросов составил 0,18%, на Google Cloud Vertex AI — менее 0,0004%.

Решение: Исправлена логика маршрутизации. Фикс развернут 4 сентября, к 16 сентября распространен на основные платформы.

2. Повреждение вывода

25 августа ошибка конфигурации на серверах TPU вызвала сбой при генерации токенов. Это приводило к появлению неожиданных символов (например, тайских или китайских в ответ на английские запросы) или синтаксических ошибок в коде.

Проблема затрагивала Opus 4.1/4 (25-28 августа) и Sonnet 4 (25 августа - 2 сентября). Сторонние платформы не пострадали.

Решение: Выявлена и откатана ошибочная конфигурация.

• Критика отсутствия юнит-тестов и акцент на использовании эвалов для тестирования моделей.
• Удивление способностью Anthropic влиять на инфраструктуру AWS Bedrock, что противоречит обязательствам AWS.
• Обсуждение технических сбоев: ошибки маршрутизации запросов, коррупция вывода и баг компилятора XLA, повлиявшие на качество Claude.
• Высокое количество инцидентов, отмеченных на статусной странице Claude, и призывы к улучшению качества и надежности сервиса.
• Критика недостаточной прозрачности отчета Anthropic, включая отсутствие данных о степени деградации и компенсаций для пользователей.
• Обсуждение проблем недетерминированности в LLM и сложностей обеспечения воспроизводимости результатов.
• Спекуляции о причинах использования разных аппаратных платформ (TPU, AWS) и их влиянии на пользовательский опыт.