Чему Slack научился за 3 года multi-cloud: 5 ключевых выводов — 15 июля 2026 г. в 08:00:06.134
Чему Slack научился за 3 года multi-cloud: 5 ключевых выводов За три года Slack прошел путь от базовой инфраструктуры для обслуживания LLM до multi-cloud архитектуры с интеллектуальным роутингом между AWS Bedrock и GCP Vertex AI. Инженерный блог компании подробно описывает четыре фазы этого перехода, однако практический интерес представляет не хронология переездов, а несколько выводов, которые переносятся далеко за пределы конкретного кейса. Вывод 1️⃣: экономика железа — платить дважды На старте, при работе через AWS SageMaker, команда столкнулась с тем, что enterprise-видеокарты Nvidia A100 и H100 попросту отсутствовали в наличии, а для удержания пиковых SLA приходилось держать простаивающие ресурсы. Это не специфика Slack, а структурное свойство любого инференса на выделенном железе, включая on-prem: ▪ плата за дефицитное оборудование, которое сложно достать, ▪ плата за его простой в часы низкой нагрузки. Экономика такого подхода определяется не средней утилизацией, а необходимостью держать объем под абсолютный пик. Вывод 2️⃣: один провайдер = единая точка отказа Сколько внутренних механизмов отказоустойчивости ни выстраивай внутри одного облака, отказ уровня всего провайдера кладет сервис целиком. Внутренние failover не защищают от platform-wide outage по определению. К этому добавляется второй фактор: лучшие модели под конкретную задачу нередко эксклюзивны для одного провайдера. Опора на единственного вендора означает одновременно и единую точку отказа, и искусственное ограничение доступа к технологиям. Именно это, а не стремление к сложности, стало настоящим драйвером перехода к multi-cloud. Вывод 3️⃣: критическое решение — слой абстракции вокруг моделей Критическим решением оказалось не то, какую модель выбрать, а то, как построить логику вокруг моделей. Слой абстракции здесь не оптимизация, а базовое требование архитектуры: ▪ модель устаревает за недели ▪ лучшие модели разбросаны по разным облакам. Выигрывает не тот, у кого сейчас стоит лучшая модель, а тот, кто способен подменить ее за день без переписывания приложения. Скорость вывода фич на рынок становится прямым следствием того, насколько рано команда вложилась в нормализацию провайдеров и единый роутинг. Вывод 4️⃣: отказ — это не только 5xx Сервис, который формально доступен, но отвечает медленно, фактически сломан. Slack трактует как мягкие отказы: ▪ рост задержки до первого токена, ▪ всплески p90, ▪ отрицательный тренд пользовательского фидбэка. Роутинг реагирует на деградацию качества раньше, чем на жесткие сбои, и переключает трафик на здоровую альтернативу до того, как проблему заметит пользователь. Это сдвиг от бинарной доступности к качеству как метрике здоровья системы. Вывод 5️⃣: бутылочное горлышко — не технологии Главное бутылочное горлышко масштабирования AI лежит не в технологиях, а в межфункциональном выравнивании. Требования: ▪️Legal, ▪️Security, ▪️Risk, ▪️Compliance. Обслуживание миллионов пользователей без потери стандартов доверия достигается согласованием этих функций с инженерией, а не наличием самого совершенного роутера. Лучшая архитектура отказоустойчивости не имеет ценности, если ее нельзя провести через юридические и регуляторные границы. Итог: направление enterprise AI Сумма этих наблюдений описывает направление, в котором движется enterprise AI: ▪ multi-cloud, ▪ multi-model, ▪ динамическая оркестрация. Однако технический контур здесь вторичен. Устойчивое преимущество строится на: ▪ слое абстракции, ▪ переопределении понятия отказа, ▪ способности организации согласовать инженерию с функциями доверия. Модель в этой конструкции — заменяемый компонент. #кейс