Cloudflare опубликовал квартальный обзор сбоев интернета за июль–сентябрь 2026 года. Отчет построен на данных Cloudflare Radar, а через сеть компании идет больше 20% мирового веб-трафика. Так что картина получается вполне репрезентативная. За три месяца Radar зафиксировал 49 сбоев. 19 из них – отключения по решению властей, и 18 из этих 19 устроил Ирак. Повод традиционный: школьные экзамены. Ирак глушит интернет на время экзаменов уже одиннадцатый год подряд и делает это по расписанию, как электричка. Начало в 03:30–04:00 UTC, длительность от 15 минут до полутора часов. В этом квартале было три волны: начало июля, конец августа – начало сентября и специальный раунд с 26 сентября, растянувшийся до 10 октября. Девятнадцатое правительственное отключение – региональное ограничение в Тигре, в Эфиопии, после начала боев. При этом Сирия и Судан, которые раньше тоже отключали интернет на экзамены, в этом году так делать не стали. Что-то меняется. Медленно. Вторая по частоте причина – электричество: 14 сбоев в 10 странах. Впереди, как обычно, Куба. Национальная энергосистема падала 6 июля, 14 июля, 3 августа, а с 18 по 20 сентября остров три дня сидел без света. У Кубы один провайдер, ETECSA, и никакого резерва. Нет электричества – нет интернета во всей стране. Сразу. Без всякой постепенной деградации. Теперь про РФ. 19 сентября, в дни выборов, связь пропала на Сахалине, в Магаданской области, на Камчатке и Чукотке. Ростелеком сообщил о двух повреждениях магистралей. На Сахалине спилили опору и оборвали линию Холмск – Томари. В Хабаровском крае кабель на участке Селихино – Ягодный перерезали в нескольких местах. Два обрыва с разницей в два часа, в день голосования. В аннотации Radar это значится как обрыв кабеля во время выборов. Кто и зачем пилил опоры – отдельный интересный вопрос. А технический урок простой: Дальний Восток висит на очень небольшом числе магистралей, и любой серьезный обрыв там превращается в региональный блэкаут. Иран в третьем квартале страну целиком не отключал. После 87-дневного блэкаута, который закончился 26 мая, единственный иранский эпизод – локальный сбой в сети Fanap Telecom 27–28 сентября. Из остального: кибератака на португальского оператора MEO, сбой в зоне Google Cloud us-central1-b, обрыв оптики в Гайане, технические проблемы у O2 в Чехии и J:COM в Японии, тайфун на Гуаме и землетрясение магнитудой 7,1 в Японии. Самое любопытное в отчете – арифметика. В третьем квартале прошлого года сбоев было 71, сейчас 49. Выглядит как улучшение. Но если убрать отключения по решению властей, оба квартала дают ровно по 30 событий. То есть интернет надежнее не стал. Просто экзаменационный сезон оказался короче. Вывод повторяется из квартала в квартал. Физическую инфраструктуру ломают погода, электричество и экскаваторы, и с этим можно бороться резервированием. А государство выключает интернет по графику, и от этого никакое резервирование не спасает.

Кредитные токены ИИ как обеспечение кредитных токенов ИИ Уже в ближайшие время большинство ИИ-стартапов столкнутся с невозможностью приобрести реальные вычислительные мощности для "своего" ИИ (и я сейчас не про Claude Code за $200 на команду, а про хорошую масштабируемую инфру для ИИ), потому что все доступные ресурсы... а) ограничены; б) уже распроданы. А чтобы получить доступ к реальным GPU мощностям, компании необходимо оформлять заказ на целые кластеры, а это миллионы и миллионы $$. ↓ Как следствие, поставщики GPU и ИИ-инфры поднимают требования к кредитному рейтингу и инвестиционному уровню таких стартапов. А стартапы, как правило, не имеют такого рейтинга (только если за ними сразу не стоит какой-нибудь A16Z) ↓ Поэтому поставщики инфры и облачные провайдеры не готовы брать на себя дополнительные кредитные риски стартапов и требуют всё более и более крупных предоплат вплоть до 100% от суммы контрактов. + даже у классического бизнеса с необходимым инвестиционным кредитным рейтингом шансов получить кредиты под GPU крайне мало, потому что этот рейтинг снижается из-за того, что они: а) наращивают обычную долговую нагрузку классическими способами; б) не являются инновационными стартапами, а лишь перепродают свои услуги покупателям токенов. ↓ Поэтому поставщики GPU будут всё чаще требовать, чтобы конечные покупатели токенов либо имели высокий инвестиционный рейтинг, либо сразу вносили крупный денежный депозит кэшем. ↓ Рост цен на GPU (из-за ограниченности предложения и высокого спроса) неизбежно приведёт к дальнейшему росту цен в сегменте инференса и росту требований под обеспечение кредитов на него. ↓ В таких условиях создание стартапа в области ИИ становится структурно и финансово всё более и более сложной задачей, а получение дешевых токенов станет всё более затруднительным. ↓ В то же время конкуренция на уровне прикладных решений потребует от компаний всё более быстрых и масштабных затрат токенов. А стартап/компания (или фонд за ними), способные за несколько дней выделить $1B долларов в/на токены, обладают колоссальным преимуществом перед стартапом, которому для начала нужно привлечь $1B ещё до того, как у него появится готовый продукт. → Узкое бутылочное горлышко кредитов на ИИ ←

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

Но брать под обеспечение реальное физическое GPU-невозможно, потому что его нужно физически проверять и обслуживать, потому что даже GPU за $100K имеет свойство ломаться. Именно поэтому на рынок могут выйти (и уже выходят) компании, которые создают 🥁🥁🥁 рынок форвардных контрактов на вычислительные ИИ мощности с физическим исполнением обязательств! Простыми словами: форвардный контракт на ИИ позволяет кредиторам брать в качестве обеспечения не сам кластер GPU, а «час работы GPU» и перепродавать его на ликвидном ИИ-рынке! Готово – кредитный риск клиента вообще отходит на второй план и даже если AI-стартап из двух человек, работающий в сильно пахнущем стариной викторианском особняке в Сан-Франциско перестанет платить по счетам, у кредитора останется реальная возможность эффективно реализовать обеспечение и GPU для нового конечного потребителя!

Характеристики ЦОДов ФНС по данным самой ФНС То, что они называют "цодом" в самой Москве — это, конечно, не ЦОД. Это "серверная комната" — всего сотня стоек. И обратите внимание, как там все импортозамещено: Cisco, Oracle, IBM Power и вот это все. ЦОДы в Городце и Дубне — это точные копии друг друга. Типа, если один ЦОД сгорит, в другом все останется. Так вот — один, в Городце — сгорел. Второй остался. Это почти никак не повлияет на сдачу налоговой отчетности и работоспособность налоговой системы РФ. Но вот если ударят по Дубне... Вот это уже будет катастрофа. Заменить или куда-то перебросить все эти информсистемы невозможно. Ну, в обозримом временном промежутке. Мне очень интересно как теперь все эти эффективные менеджеры будут изворачиваться

Какой бизнес строить в мире AI Последнее время меня очень занимает тема трансформации в агентскую экономику. Много читаю и думаю про это. Пока это скорее теоретизация, но контуры уже прослеживаются. Если сильно упростить, вижу три долгосрочных типа продуктов, которые могут забирать существенную часть новой экономики и не быть съеденными следующими версиями моделей. 1. Отраслевые операционные системы для агентов Это продукты, которые переводят данные, процессы, правила и экспертизу конкретной индустрии в среду, где агенты могут выполнять реальную работу. Не просто «AI для страхования», а система, которая знает, откуда брать данные, что агент может делать сам, где нужен человек и как проверять результат. Главный актив здесь – глубокое понимание того, как реально устроена индустрия. 2. Владельцы уникальных данных, доступа и возможностей Модель может стать сколь угодно умной, но она не может сама узнать актуальную погоду, наличие номера в отеле, кредитную историю человека или физически перевести деньги. Поэтому огромная ценность останется у тех, кто владеет чем-то внешним по отношению к модели: уникальными данными, доступом, лицензией, инфраструктурой или возможностью совершить действие. AI будет становиться коммодити. Доступ к реальности – нет. 3. Инфраструктурные рынки и маршрутизаторы Агенту не обязательно знать, у кого получать нужный результат. Он может сказать: «Дай максимально точный прогноз дождя» или «Проверь эту компанию максимально надежно». Промежуточная инфраструктура сама выберет поставщика по качеству, цене и надежности. Простая прослойка, которая только проксирует чужой API, долго не проживет. Ценность появляется там, где рынок агрегирует не только предложение, но и доверие, качество, права, гарантии или исполнение. Поэтому агенты убьют далеко не всех посредников. Сильнее всего пострадают те, чья ценность в интерфейсе, поиске, сравнении и человеческом внимании. Гораздо устойчивее те, кто берет на себя оформление, контроль качества и логистику. Booking, как пример. Он вполне может построить инфраструктуру для агентов: у него уже есть отели, цены, доступность номеров, платежи, возвраты и отзывы. Но правильный агент должен сравнить Booking, Expedia, прямую цену отеля, программы лояльности, доступные юзеру, и выбрать лучшее предложение. А Booking выгоднее, чтобы транзакция осталась внутри Booking. Это один из интересных источников возможностей для стартапов: не там, где крупный игрок не способен что-то построить, а там, где правильный новый продукт конфликтует с большим существующим бизнесом. Главный вопрос к любой идее: Почему этот продукт модели не смогут просто встроить в следующий релиз? Если ценность – промпты, память, оркестрация или интерфейс вокруг модели, позиция слабая. Если это отраслевые процессы, уникальные данные, права доступа, инфраструктура, отношения, оформление, логистика или доверие – сильная. Можете не сомневаться, если все это понимаю я, то понимают и тысячи предпринимателей и инвесторов в Долине. Многие уже такое строят. Поэтому сильно возбуждаться я бы не стал. Вероятность, что глобального победителя построите именно вы, а не выпускник MIT, бывший сотрудник Google или фаундер с экзитом и доступом к другим порядкам ресурсов, ниже нуля. Возможность лишь в том, что они начнут с самого жирного рынка Штатов. А для нас шанс есть в локальных рынках, под которые глобальным игрокам долго и дорого адаптироваться. Важно только, чтобы рынок был достаточно большим, чтобы на нем заработать. Все эти разгоны про будущее, скорость наступления которого непонятна. Нам из околоайтишного пузыря кажется, что все вокруг круглостуточно вайкодят и обвешаны агентами, но реальный мир гораздо инертнее. Поэтому самые реалистичные возможности как раз лежат в переходном периоде, когда в новую экономику начнет вкатываться большинство. Продукты там выглядят менее секси, зато намного доступнее для запуска и извлечения денег прямо сейчас. Про них напишу в следующем посте, если вы не будете жадничать и оставите под этим 100 реакций.

Ну что, на каждом углу рассказывают о внедрении автономных ИИ-агентов, а исследование «Инфосистемы Джет» и Smart Ranking в это время показывает другие результаты. Смотрите на эту лестницу разочарования: • пилотируют или используют LLM — 86% компаний • пилотируют полуавтономных агентов — 59% (в проде — 15%) • автономных агентов в пилоте — 25% (в проде — 8%) • мультиагентные системы — 23% (в проде — 8%) Почему так? Да потому что агентам нужны данные, интеграции, контроль, доверие, владелец процесса и доказанный эффект. В исследовании выделили несколько проблем: 44% компаний жалуются на незрелость процессов и данных, 58% — на стоимость GPU, 56% — на юридические риски, а 46% вообще не видят экономического эффекта. Отдельный привет тем, кто думает, что «просто подключим модель и всё заработает». Без данных ИИ автоматизирует не более 5% процессов. Так что никакой магии, только скучная инфраструктура.

Интересный репортаж с девятой конференции по кибербезопасности E.DSO – EE-ISAC - ENCS – ENISA, которая была в этот раз посвящена безопасности энергосистем. Одной из ключевых проблем, которую там обсуждали, была проблема домашних инверторов и накопителей. Поскольку они считаются фактически бытовыми приборами, особого регулирования этого рынка нет, а между тем общая генерация этого сектора уже достигает 100 ГВт. При этом они управляются, как правило, через облака, причем плохозащищенные, и в основном китайские. Атака на генерацию такого масштаба способна серьезно нарушить работу энергосистемы — по данным специалистов, для этого достаточно вывести из эксплуатации всего 3 гигаватта. Напомню, что представить эту величину очень просто — средняя мощность одного энергоблока АЭС составляет как раз около одного гигаватта. Я, в общем, когда столкнулся с тем, что самый свежий вариант логгера к инвертору Deye предусматривает только использование облака для управления, и услышал от менеджера компании-установщика, что подъедет инженер, всё настроит и "даст доступ", сразу нашел способ собрать локальный доступ к инвертору, сам всё настроил и никому никакого доступа не дал — это критическая инфраструктура моего дома и никакой "инженер", не говоря уже о китайском облаке, туда доступа иметь не должен. Тем более, что сейчас так сделать совершенно не сложно и, что самое интересное, без облака доступ лучше и надежнее. https://berthub.eu/articles/posts/solar-nightmare-at-the-conference/

📌 Учёные призвали изолировать от интернета модели, способные к кибератакам Открытое письмо об ИИ и кибербезопасности подписали 406 исследователей, в основном из университетов и научных институтов разных стран, среди них Йошуа Бенжио, Джеффри Хинтон, Стюарт Рассел, Перси Лян, а также криптографы Рон Ривест и Дэн Боне. Авторы призывают разработчиков моделей с развитыми навыками взлома немедленно перейти на надёжные системы изоляции и по умолчанию запускать такие модели на машинах, физически отключённых от интернета. По их словам, без немедленных перемен в разработке и внедрении ИИ такие случаи продолжатся, а следующие ударят по уязвимой критической инфраструктуре гораздо сильнее. В этих утечках учёные видят две проблемы сразу. Модели ведут себя непредсказуемо, а разработчики пренебрегают обычными правилами кибербезопасности, хотя более надёжные песочницы могли бы утечки предотвратить. Поэтому нужны и исследования согласованности ИИ, и лучшие средства изоляции. Если модель всё же выпускают в интернет, круг разрешённых ей действий, по мнению авторов, нужно соизмерять с тем, насколько плохо мы пока умеем предсказывать, не приведут ли они к сбою защиты. Письмо предлагает создать международный орган вместе с правительствами и специалистами по ИИ и кибербезопасности, который должен вырабатывать открытые стандарты изоляции для случаев, когда модели дают больше доступа, чем позволяет песочница, и вести учёт утечек. Как такой орган будет устроен и кто его будет финансировать, в письме не сказано. Среди подписавших нет представителей OpenAI, Anthropic и DeepMind. @ai_machinelearning_big_data #news #ai #ml

Как встраивать ИИ в продукт Полезно продактам, CPO и тем, кто сейчас автоматизирует команды и процессы. 1. ИИ может ухудшить ваш продукт. Он может быть медленным и ненадежным, или же решать проблему, которой ни у кого нет. Тот факт, что это ИИ, еще не означает, что его стоит разрабатывать. 2. Подумайте, нужно ли вам вообще разрабатывать ИИ. Зачастую лучше сначала создать что-то для ИИ, например, сервер MCP. Их проще создавать и поддерживать. 3. Ищите jobs to be done, а не демо. Лучшие возможности для ИИ — это задачи, выполнение которых занимает более 30 секунд, использующие код или интерфейсы, которые пользователи не знают (например, SQL), или задачи, которые пользователи повторяют более 20 раз 4. Онбординг — отличная первая цель. Визард установки с ИИ выполняет работу, занимающую два часа, за 8 минут. 5. Не спрашивайте: «Как добавить ИИ в это?» Спрашивайте: «Как выглядит agent-first-версия этого?» Такой вопрос заставляет переосмыслить jobs to be done для agent-first-будущего и помогает не быть разрушенным ИИ-native конкурентом. 6. Создание продуктов «формата 2030 года» может потребовать начать с нуля и отказаться от накопленных за годы UI-решений и допущений, которые больше не актуальны. 7. Следите за клиентами, которые пересобирают ваш продукт с помощью ИИ. Это показывает, какие функции им действительно нужны. Когда клиенты создают собственный прототип вашего продукта с помощью MCP и Claude Code, — нужно добавить в продукт больше настраиваемых «canvas»-артефактов. 8. Валидируйте ИИ-концепты также, как новые продукты. Запишите, по каким критериям будет оцениваться результат и какой runway у инициативы. Спросите, насколько команда будет разочарована, если её потеряет (PMF-опрос). 9. Опишите, как ваш продукт проигрывает ИИ-native угрозе, а затем профинансируйте собственную версию этого «атакующего». Даже лучший продукт поддержки проиграет продукту, где ИИ отвечает на все тикеты, — вероятно, поэтому Intercom так сильно развернулась в сторону Fin. 10. Ответьте на вопрос: чем это лучше Claude? Именно к нему люди обращаются по умолчанию. Ваш moat — это контекст: функциональность продукта, данные пользователей, а также инструменты и skills, которые вы построили. 11. Сосредоточьтесь на общей ИИ-инфраструктуре. Сделайте примитивы — промпты, стриминг, согласия, evals, задачи и аналитику, — которые продуктовые команды смогут расширять и встраивать в свои продукты. Выберите единый UX-паттерн, чтобы избежать «смерти от тысячи виджетов», а затем не мешайте командам. Продуктовые команды лучше знают своих пользователей, а не ИИ-команда. 12. Позвольте агентам запускать код. Исполнение кода даёт агентам возможности beyond predefined tools. 13. Позвольте агентам делать всё, что могут делать пользователи. Если есть инструмент создания эксперимента, но нет инструмента его запуска, агент сделает всё остальное и остановится, чтобы попросить вас кликнуть по UI. Это ограничивает возможности агентов. 14. Тестируйте продукт headlessly, чтобы развить «эмпатию к агентам». Проверяйте агентные фичи через CLI, чтобы сталкиваться с теми же точками трения, что и они. 15. ИИ не убивает ваш UI — он меняет его назначение. Меньше экранов для выполнения действий, больше — для одобрения, проверки и отмены действий агентов. Стройте UI, когда текста недостаточно. 16. Управляйте агентами на их уровне абстракции. Агенты работают лучше, если позволить им гибко писать и рассуждать. Перестаньте заставлять агентов использовать предустановленные query-инструменты и разрешили им писать собственный SQL. 17. Настройте ИИ-observability с первого дня: - Трейсите LLM-вызовы: входы, выходы, latency и стоимость. Это выявляет ошибки и проблемы, исправление которых даёт быстрый рост качества. - Отслеживайте использование агентами так же, как использование людьми. Агенты не генерируют pageviews или rageclicks, но можно отслеживать вызовы MCP-инструментов, запросы страниц и другое. - Используйте evals, но начинайте с малого. Вручную читайте трейсы, чтобы найти места, где ИИ ошибается. Создайте eval для проверки этой проблемы и улучшайте продукт, чтобы улучшить результат eval. Даже небольшие golden- или синтетические датасеты давали огромный прирост качества по сравнению с обычным циклом разработки. 18. Изучите unit-экономику ИИ-продукта. Наш визард стоит $6,67 за запуск, но улучшенная активация и retention стоят дороже. Переход трейс-саммари со стандартного gpt-4.1-nano на flex-уровень gpt-5-nano вдвое снизил затраты. 19. Многие сбои агентов — на самом деле сбои контекста. Добавление агенту значительно большего объёма контекста улучшило эффективность визарда сильнее, чем улучшенное reasoning, многошаговое планирование, субагенты, pruning и compaction. И Сделайте так, чтобы люди могли легко создавать контекст, которого агент не знает. 20. Прозрачная компания полезна для агентов. Ваши Агенты и агенты клиентов могут смотреть в кодовую базу, handbook и документацию, чтобы лучше понимать, как работает ваш продукт.

Читатели канала напомнили, что смерть Кащея на кончике иглы, игла в яйце, яйцо в утке, утка в сундуке, сундук на дереве, а дерево расположено по двум адресам, где находятся два ЦОДа ФНС Дубна Московская область, г. Дубна, ул. Технологическая, 2. Федеральный центр обработки данных ФНС официально открылся в 2015 году. Проектировать его начали в 2012-м, проект стоил 7,9 млрд рублей. Задача центра в том, чтобы собрать единый налоговый файл страны, общую базу налоговых данных в одном месте. Вторую очередь в ноябре 2020 года открывал Мишустин. (Вот, кстати, сроки стройки и бюджеты - три года и миллиарды рублей — но э то было до войны и даже до крымнаша — тогда оборудование проще было ввозить) Городец Нижегородская область, г. Городец, ул. Речников, 14. Запущен в декабре 2015 года как точная копия Дубны, так называемый горячий резерв. Позже рядом построили ЦОД №2 площадью 5600 кв. м. Как это работает Обе площадки работают одновременно в зеркальном режиме и обслуживают весь массив данных Минфина и подведомственных служб, чтобы исключить потерю информации. Между ними около 380 км по прямой. Что там лежит Не только налоги. АИС Налог-3, единая система, через которую автоматизирована вся работа ФНС. Единый реестр ЗАГС: рождения, браки, смерти. Федеральный регистр населения ЕРН, его инфраструктура модернизируется в обоих ЦОДах. В 2020 году в ЦОД ФНС из ЦОДа Гознака переехала система госзакупок. Что с резервом Изначально площадок должно было быть три: Дубна, Городец и Волгоград. От волгоградского ЦОДа отказались, а деньги направили на вторые очереди в двух существующих. Так что вся система держится на двух точках. На фоне нынешних атак на дата-центры вопрос о третьей площадке, похоже, снова станет актуальным. Но денег, вроде как нет.

Ладно. Поставил себя на место "эффективных менеджеров гости" — сидел, думал, как всё же сделать ДЦ менее уязвимыми для атаки дронов. Вот что придумал: Раз перенести дата-центры под землю, в Сибирь или за границу не получится, то есть еще вариант: раздробить их. Идея Вместо нескольких гигантских ЦОДов строится сеть из множества небольших узлов, объединённых в одну систему. Потеря любого узла некритична: нагрузка автоматически переезжает на соседние. Так устроены облака с зонами доступности, только узлов больше и они дальше друг от друга. Устойчивость здесь не в прочности здания, а в избыточности и скорости переключения. Примерно так же, кстати, сделан VPN Generator, но продолжим... Из чего состоит узел Модуль заводской сборки: машинный зал на несколько десятков стоек, ИБП, охлаждение, пожаротушение, удалённый мониторинг. Мощность от сотен киловатт до мегаватта. Генератор с топливом обычно стоит рядом отдельным блоком. Модули бывают двух типов. Контейнер ставят под открытым небом. Модульный зал собирают внутри существующего здания: склада, цеха, корпуса. Сейчас второй вариант лучше: стены и крыша дают защиту, которой у контейнера нет. Принципы Рассредоточение: узлы разнесены на десятки и сотни километров. Избыточность: мощности с запасом на потерю нескольких узлов. Стандартизация: одинаковые модули и одинаковое железо, проще закупать и менять. Близость к энергии: у электростанций, подстанций, заводов с собственной генерацией. Безлюдная эксплуатация: управление удалённо, инженеры выезжают по вызову. Как это сделать сейчас Площадки. Промзоны, территории заводов и станций, пустующие склады и цеха. Модуль в существующем здании быстрее согласовать и проще защитить. Энергия. Прямое подключение к генерации или свои газопоршневые установки. Газ есть почти везде, где есть промышленность, и это снимает зависимость от подстанций. Оборудование. Модули, ИБП и охлаждение делают российские и китайские производители, серверы идут из Китая через параллельный импорт контрабанду. Чем меньше моделей, тем проще держать складской запас. Связь. Узлы региона замыкаются в оптическое кольцо, к каждому минимум два независимых канала от разных операторов. Софт. Без него ничего не работает: оркестрация, распределённое хранение с репликацией, балансировка и автоматическое переключение. Облака это уже умеют, корпоративные системы придётся переписывать. Организация. Региональные кластеры, склад запасных модулей, выездные бригады, единый мониторинг и план замены узла за недели. Как это выглядит на практике Регион обслуживают несколько узлов по мегаватту в 50–150 км друг от друга, связанные кольцом. Данные лежат минимум на двух узлах, потеря любого не роняет сервис. Большие московские ЦОДы остаются для того, что нельзя раздробить, а малые узлы берут на себя резерв, кэш контента и распределённые сервисы. Звучит реалистичнее, чем "строить ЦОДы в Сибири"

В «Ростелекоме» после украинских ударов по дата-центрам предложили создать центр обработки данных «судного дня» Заместитель председателя правления «Ростелекома» Валерий Ермаков после атаки на центр обработки данных (ЦОД) «Сбера» заявил, что необходимо создать центр обработки данных «судного дня». По его словам, речь идет о «площадке бэкапов [резервных копий]».

Так называемый ЦОД судного дня — это то, что должно быть, потому что сегодня бэкап — это то, что позволяет любому сегодня провайдеру услуг очень быстро восстановиться.

«Это действительно было невозможно представить какое-то время назад, но сейчас это прям реальная потребность», — заявил он. ——— Украинские дроны в первой половине октября атаковали три дата-центра «Яндекса», а в ночь на 14 октября нанесли удар по центру обработки данных «Сбера» в городе Балаково Саратовской области. После ударов по дата-центрам «Яндекса» сервисы как самой компании, так и ее клиентов работали с перебоями. В «Сбере» после атаки ззаявили, что все их сервисы работают штатно. Однако пользователи начали жаловаться на сбои в работе самого «Сбера» и других сервисов. @meduzalive

Онбординг агентов в Enterprise кодовые базы на миллионы LoC Вместе с Максимом Ключниковым (Этихлид) поделились своим опытом о том, как добиться максимум эффективности от AI агентов на больших легаси проектах. Я рассказывал про построение тезауруса и борьбу с тех долгом, а также поделился неочевидными результатами наших бенчмарков, измеряющих эффективность контекстных движков (векторный RAG, графовый RAG). Во второй части Максим рассказал об AI-native инфраструктуре . А в третьей части к нам присоединился Глеб Михеев (Уставший техдир) и мы вместе поотвечали на вопросы зрителей, обсудили тему миграции больших проектов, а также тему объективного измерения эффективности агентов на своей кодовой базе. Запись на YouTube: Конвертируем Enterprise-проект в Dark Factory — Родион Мостовой и Максим Ключников Таймкоды: 00:00 Знакомство со спикерами и начало доклада 02:15 Что такое Dark Factory и что для неё нужно 09:25 Делаем Enterprise-проект понятным агенту 14:20 Тезаурус, инварианты и знания команды 26:05 Исследование подсистем и проблема missing change 29:20 Контекстные движки: поиск и GraphRAG 36:50 Верификация: тесты, AI QA и запуск в CI/VM 56:30 Максим Ключников: замыкаем петлю на инфраструктуру 1:25:25 Воркфлоу для типовых задач 1:28:05 Профиль готовности проекта к агентам 1:31:05 Сколько работы можно отдать агентам 1:42:30 Обсуждение и вопросы участников @ai_driven