Документация, это не решение проблемы ухода ключевых людей. Это страховка с франшизой. Она смягчает удар, но не предотвращает его. Настоящая защита от низкого bus factor не вики, а ротация задач, где никто не владеет модулем монопольно с обязательным код-ревью, контекст распределяется между 2+ людьми и тесты как документация, чтобы падающий тест показал, зачем нужен хак. Без этого любая база знаний, это красивое кладбище решений, принятых людьми, которых уже нет в команде.
Если белый список на домашнем интернете реально работает, откройте терминал и выполните:
traceroute 8.8.8.8
Если маршрут обрывается на узле вашего провайдера (последняя строка с ответом внутри РФ), а при этом traceroute ya.ru доходит до конца, поздравляю это фильтрация транзита, а не атака на сеть.
Пока в статьях ни одного скриншота трассировки, ни одного лога, ни сравнения через разных провайдеров. Только анонимные "собеседники". Без доказательств, это слух, а не факт.
Не верьте на слово. Проверьте сами, 30 секунд в терминале дадут больше ясности, чем 30 статей.
Очередная статья/сборник костылей без понимания архитектуры современных систем фильтрации. Давайте разберу самые критические упущения на мой скромный взгляд обывателя.
Замедление не равно блокировка, автор смешивает два разных механизма DPI:
Замедление — снижение скорости после распознавания сигнатуры (например, по JA3 fingerprint TLS handshake)
Белые списки — разрешение трафика ТОЛЬКО к доверенным доменам/IP, всё остальное отбрасывается на уровне маршрутизации
Против белых списков ни один из предложенных методов не работает, потому что трафик просто не покидает границы РФ. Это не замедление, это фильтрация на уровне пиринга.
MTProto и SOCKS5 это мёртвые технологии, сигнатуры MTProto известны с 2018 года. Современные ТСПУ детектируют его по всему возможному:
Фиксированному размеру пакетов (1024 байта)
Отсутствию TLS handshake
Характерному паттерну обмена ключами
SOCKS5 без шифрования это вообще подарок для анализа, все домены и IP видны в открытом виде. Работоспособность этих решений в 2026 году, признак того, что провайдер ещё не обновил правила фильтрации.
TG WS Proxy = локальный костыль, прокси на localhost не решает проблему на уровне сети, он лишь оборачивает трафик в WebSocket, но:
Не маскирует конечный домен (TLS SNI до ESNI/ECH раскрыт)
Не защищает метаданные (объём, частота запросов)
Требует постоянной работы фонового процесса — точка отказа
Модифицированные клиенты = риск компрометации, AyuGram/exteraGram — неофициальные сборки, даже при открытом исходном коде:
Нет гарантии, что собранный бинарник соответствует коду
Плагины (exitFy) загружаются из непроверенных источников
Риск внедрения бэкдора для сбора сессионных ключей
Главный упущенный риск, это метаданные, даже при успешном обходе фильтрации:
Провайдер видит объём трафика к зарубежным хостингам (например, 50 ГБ в месяц на сервер в Амстердаме)
Временные паттерны (подключение в 02:00 к одному и тому же IP)
Flow correlation (совпадение времени подключения с известными сетевыми )
Короче, ваши метаданные часто опаснее содержимого, ведь они строят социальный граф без расшифровки сообщений.
Реальное решение, это арендованный VPS + XTLS/VLESS с правилами маршрутизации (geoip/geosite), но и оно уязвимо против белых списков. Нет серебряной пули, есть только управление рисками и понимание, что любая попытка обхода оставляет следы на уровне метаданных.
Эта статья поверхностный обзор для широкой аудитории, но далеко не технический документ для принятия решений.
Основная проблема, это фактические ошибки в описании протоколов (OpenVPN, энтропия), смешение юридических и технических моделей (провайдер vs ТСПУ) и игнорирование метаданных как вектора утечки, плюс элементарное отсутствие анализа клиентских уязвимостей.
Рекомендация практикам, не использовать эту статью, как источник для архитектурных решений. Для оценки рисков лучше почитайте спецификации протоколов RFC 768 для WireGuard, RFC 5246 для TLS и тестируйте утечки через ipleak.net.
Анализируйте трафик в Wireshark с фильтром tls.handshake.type == 1 и помните, что идеальной анонимности нет, есть только управление рисками через многослойную защиту (не только VPN).
Спасибо за развернутые ответы, но пара моментов требует уточнения, потому что маркетинг и реальность немного расходятся:
Про 2 vCPU, вы сами признали, что это бизнес-решение, а не техническая необходимость. И что в будущем запустим экономичные типы. То есть сегодня клиент с микросервисом на 0.2 ядра сознательно переплачивает 900%, потому что ваша архитектура не умеет шарить ядра между ВМ. Выглядит как перекладывание неэффективности на клиента. Возможно лучше так и написать, типа минимум 2 vCPU, это временный компромисс ради упрощения архитектуры.
Про цены с натяжкой принято, по мне этого действительно не хватает, чтобы принять решение, потому что кроме прочтения статьи, надо пойти и найти прайсы. Ну ок.
Про миграцию ВМ, ок, ожидаем, у конкурентов она реализована, ведь это не просто фича, это база для обновления гипервизоров без даунтайма продакшена. Значит пока ваше облако не позволяет обновлять инфраструктуру без остановки ВМ.
Про географию, где две зоны в Московской области, при ЧС на уровне региона оба ЦОДа в одной точке отказа. Вы сами написали, что фактический RPO зависит от механизма записи и может быть ненулевым. То есть при городской аварии гарантирована потеря данных. Для критичных систем это осознанный риск, который клиент должен знать до выбора платформы.
Пока просто хорошая техническая база, но маркетинговая упаковка не соответствует зрелости платформы, потому что не хватает расклада по ограничениям и рискам.
Техническая статья без цен ок, норм. Но техническая статья, которая одновременно:
хвастается отказом от овербукинга (звучит как этический подвиг),
кричит "предсказуемость",
и при этом тщательно убирает единственный параметр, по которому архитектор оценивает предсказуемость, стоимость,
это не техническая статья. Это попытка прикинуться инженером, чтобы потом впаять клиенту ценник как у конкурентов, но чуть дороже, потому что мы честные. Если хочешь писать про честность, пиши цифры. Если не хочешь писать цифры, не используй слово "честное". Это не сложно. Это базовая честность с самим собой. А вопрос "вы правда ожидали цены", звучит так, будто вы только что спросили: "Вы правда ожидали, что еда в ресторане будет съедобной?" Нет. Я ожидал меню. Без цен, это не ресторан. Это социальная столовая.
Спасибо за ответы, но часть из них только подтверждает слабые места:
1) Лыткарино + Зеленоград оба в пределах Московской агломерации. При ЧС на уровне региона (кабельный коридор Москвы, авария на МРСК Центра) оба ЦОДа в зоне риска. Это не multi-region, это две зоны в одной географической точке отказа. Для критичных систем, недостаточно.
2) "Чётное количество vCPU во избежание запуска разных ВМ на одном ядре", логика странная. Если 1 физ. ядро = 2 HT-потока, то 2 vCPU = оба потока одного ядра. Вы не избегаете соседей, вы просто гарантируете, что ядро целиком отдано одной ВМ. Но тогда вопрос: почему нельзя 1 vCPU (один поток)? Для бота, фонового воркера, микросервиса с нагрузкой 0.1 ядра это прямой оверхед 900%. Это не техническое ограничение, это бизнес-решение. Признайте честно.
3) vCPU = поток, ок. Тогда при нагрузке 15% CPU вы платите за простаивающие 85% потока. И за второй поток того же ядра, который тоже простаивает. Без овербукинга это не честность, это неэффективность, переложенная на клиента.
4) "Поддержка Terraform есть", в документации вижу только описание REST API. Официальный провайдер в реестре HashiCorp registry.terraform.io есть? Или речь про кастомный модуль на коленке? Для автоматизации это разные вещи.
5) "Есть партнёр по DDoS" не есть встроенная защита. Это "идите сами настраивайте, платите третьей стороне, разбирайтесь с маршрутизацией". У Яндекса защита на уровне сети "из коробки".
6) Посмотрел, например "99,0% — 99,99% | простой от 4 мин 19 сек до 43 мин 11 сек | компенсация 5%", но проблема в том, что 99,0% в калькуляторе, это 7 часов простоя с компенсацией 5%. Серьезно?
7) "Невозможно всё охватить", цены не деталь для углублённого анализа. Цена это первое, что смотрит архитектор при сравнении платформ. Статья позиционируется как про честность, но базовый элемент честности, стоимость владения, убран за рамки. Это не техническая необходимость, это маркетинговый выбор.
Возникает небольшое количество вопросов в связи с вашей публикацией:
Два ЦОДа в Москве, это две зоны отказоустойчивости или два здания в пределах МКАД? Если второе, как вы гарантируете RPO < 5 мин при ЧС городского масштаба, например, кабельный срез по всем маршрутам?
Минимум 2 vCPU на ВМ, это архитектурное ограничение гипервизора или бизнес-решение? Для микросервисов с нагрузкой 0.2 vCPU это прямой оверхед 900%. Как обосновываете?
"Нет овербукинга", звучит очень честно, пока не посчитаешь TCO. Приведите сравнение стоимости 100 ВМ с нагрузкой 15% CPU против аналогичного кластера на Selectel/Yandex и пожалуйста цифры, не принципы.
1 vCPU = 1 физическое ядро или 1 HT-поток? Если поток, то как решаете contention при одновременной нагрузке соседей на разные потоки одного ядра?
Собственный стек вместо OpenStack окей, но где публичная документация по API? Поддержка Terraform provider есть или писать свой на коленке?
Цены в статье отсутствуют полностью. Это такой маркетинговый приём или политика "звоните, менеджер посчитает"? Для архитектора сразу красный флаг.
Производительность диска отвязана от объёма, это круто, но какая максимальная пропускная способность на ВМ? 1 Гбит/с? 10? Или как у некоторых "облаков" 300 Мбит/с и никакого SLA на сетку?
Тройная репликация "между двумя зонами", это 2+1 или 1+1+1? Если первое, то при потере одной зоны вы мгновенно теряете отказоустойчивость. Это осознанный компромисс?
DDoS-защита на уровне сети есть или клиент сам тянет трафик через сторонние фильтры?
Есть ли публичный SLA на доступность ВМ и дисков, и какие компенсации при его нарушении?
Пиринг с Google/Cloudflare/Microsoft есть напрямую или весь исходящий трафик идёт через одного транзитного оператора?
Снапшоты CoW ок, но сколько стоит хранение дельты в месяц? У некоторых провайдеров "бесплатный снапшот" превращается в 30% к стоимости диска за хранение инкрементов.
Как быстро работает миграция ВМ между хостами без даунтайма? Менее 30 сек или как в старых решениях 2–3 минуты с потерей сетевого стека?
У вас свои ЦОДы, супер, но кто поставщик питания и есть ли независимые вводы от разных подстанций?
И последнее, почему в статье, где вы пишите "что надёжность инфраструктуры и гибкость сервисов — это те требования, от которых нельзя отступать. И чтобы выполнить их честно, мы сделали ставку на два принципа: собственную физическую инфраструктуру и собственную разработку." нет ни одной цифры по ценам, ни одного бенчмарка, ни одного кейса клиентов, только лозунги?
Жду ответы, посчитаю реальный TCO под наш стек, пока выглядит как красивая презентация без цифр для принятия решения.
В статье описаны несколько передовых методов ускорения инференса (от FP8/INT4-квантизации SpinQuant до EAGLE-спекуляций и динамического сжатия KV‑cache). При этом вы подчёркиваете, что все эти техники можно комбинировать для мультипликативного эффекта ускорения. Как вы системно оцениваете взаимодействие таких методов, чтобы избежать отрицательных синергий (накладных расходов, накопления ошибок при агрессивной квантизации и т. п.)?
И есть ли у вас критерии выбора “оптимального набора” технологий для реальных сценариев, где важны как минимальная латентность, так и стабильное качество (например, при длинных контекстах, многошаговых диалогах или Q&A над большими документами)?
Кроме этого предлагаю добавить раздел о «динамическом комбинировании» ускоряющих техник, где подробно описать, как на практике выбирать набор методов (SpinQuant, FP8, EAGLE, DMC и т. д.) в зависимости от конкретных характеристик задачи и среды. Можно сформировать:
1) Методологию бенчмаркинга, предложить сценарии разной «длины контекста», вариативного батчинга и сложного многошагового диалога, чтобы показать, как каждая техника ведёт себя при определённой конфигурации.
2) Модель принятия решений, представить систему «весовых коэффициентов», которая позволит взвешивать приоритеты между «скоростью» и «качеством» для каждого метода.
3) Пример динамического выбора, описать, как в продакшен-системе можно подключать или отключать определённые оптимизации «на лету», ориентируясь на текущий контекст (например, длину запроса, оставшиеся GPU-ресурсы, нагрузку на сервис).
Таким образом можно показать не только набор техник, но и практический подход к тому, как эти методы эффективно комбинировать без нежелательной «накладной синергии» и падения точности.
По ходу статьи вы рассуждаете о необходимости объединять разнообразные форматы данных (текст, снимки, графики) в рамках единой мультимодальной модели и указываете на дискуссию между подходами “большие универсальные” vs. “компактные специализированные” системы. Как именно вы оцениваете эффективность этих подходов при работе с мультимодальным контекстом?
Например, на практике не станет ли Retrieval-Augmented Generation (RAG) с многомерными векторными БД слишком ресурсоёмким для “больших” MLLM, а попытка сократить модель до “малой” существенно ударит по качеству анализа сложных типов данных (вроде медицинских снимков и текстовых записей врача)?
Расскажите пожалуйста о критериях выбора оптимального размера и архитектуры MLLM, если набор мультимодальной информации очень велик и разнороден.
Позвольте уточнить несколько моментов, поскольку, судя по всему, возникло лёгкое недопонимание того, что я имел в виду:
«Ортогональность» тем Control Plane и системы хранения
Вы пишете, что «логически некорректно формулировать вывод, что одно проще, чем другое», и считаете их «ортогональными». Однако в предыдущих сообщениях (и статье) фактически прозвучало противопоставление: мол, строить собственный Control Plane сразу «адекватно», а систему хранения можно пока взять готовую (Ceph), а потом заменить.
Я не утверждал, что это «одна и та же» задача. Скорее, хотел показать: с точки зрения рисков и долгосрочных затрат обе области (Control Plane и Storage) критичны для облака. При этом в статье вы выбрали разные стратегии: Control Plane — полностью свой, систему хранения — временно стороннюю. Поэтому возникает логичный вопрос: почему одну «боль» вы решаете сразу с нуля, а вторую предпочитаете отложить, хотя в обоих случаях потенциально масштабные переделки чреваты большими усилиями?
Проблема «иллюзорной правильности» на старте
Мы говорили не о том, что «open source» изначально хуже, а о том, что любая архитектура, принятная на ранних этапах, может столкнуться с новыми сценариями, которые поначалу не были учтены. На практике есть масса примеров, когда даже собственный код, написанный опытными инженерами, нуждается в глубокой переделке при изменении рыночных условий или добавлении новых сервисов.
Ваш ответ сводится к тезису «мы имеем достаточный опыт и лучше понимаем домен, поэтому код будет проще адаптировать». Но опыт, безусловно, снижает риски, хотя и не обнуляет их. Остаётся открытым вопрос: какие именно механизмы модульности или абстракции вы закладываете, чтобы эти будущие изменения не привели к «годам боли»? Ведь даже с крутой командой нельзя предусмотреть абсолютно всё.
Свобода в будущем vs. Сложность текущей разработки
Вы уверены, что собственный Control Plane будет проще адаптировать, поскольку «это ваш код». Понятно, что отсутствие жёсткой привязки к чужой roadmap даёт свободу — но часто «самописные» решения по мере роста обрастают своими уникальными ограничениями и техническим долгом.
В open source-комьюнити много контрибуций и патчей, появляются новые фичи или паттерны, которые можно относительно легко «подтянуть». В случае полностью самописного Control Plane всё придётся делать силами своей команды. Это не всегда быстрее или дешевле, даже если команда «строит облако в третий раз».
Хотелось бы узнать, как вы будете оценивать целесообразность «подтягивать» некие сторонние компоненты, если технологический ландшафт изменится (например, появятся новые подходы к сетевой виртуализации или диспетчеризации ресурсов)?
Двойная логика выбора
Вы пишите, что OpenStack «проблемно адаптировать» под современные сценарии, поэтому сразу от него отказались; одновременно вы взяли Ceph с прицелом «потом спокойно перепишем, когда созреем». Но ведь Ceph — это тоже open source, со своими нетривиальными ограничениями.
Получается, что в одном случае (Control Plane) вас не устраивает необходимость глубоких доработок, поэтому делаете всё «под себя» здесь и сейчас.
В другом случае (Storage) та же самая проблема не воспринимается как блокирующая. При этом Ceph — довольно «тяжёлое» решение, которое тоже потребует немало усилий при интеграции и дальнейшей замене.
Именно поэтому у стороннего читателя может сложиться впечатление, что вы противопоставляете «сделать сразу правильно» и «взять что-то готовое с доработкой потом», хотя для обеих задач (Control Plane и Storage) риски похожи. Отсюда и наш первоначальный вопрос — как именно вы оцениваете риски долгосрочных переделок в собственном коде, и почему считаете, что этот риск меньше, чем при использовании open source-платформы (для Control Plane), но при этом нормальный для Ceph (Storage)?
Ваш опыт и экспертиза, несомненно, повышают шансы, что архитектура Control Plane будет продумана и более гибкая изначально.
Однако хочется понять, какие конкретные архитектурные паттерны или процессы (модульность, ревизия API, планирование backward-совместимых изменений и т. д.) вы используете, чтобы «фундамент» Control Plane не пришлось перелопачивать через пару лет с не меньшими издержками, чем при отказе от open source.
Надеюсь, удалось прояснить, что я не пытаюсь смешать в одну кучу две разных задачи, а скорее уточнить вашу логику по обеим направлениям. Ведь цель дискуссии — разобрать возможные технические и стратегические риски, чтобы чётче понимать, как вы пришли к нынешней архитектуре.
Вы упомянули фича-тоглы и канареечные выкатки, но не объяснили, как решаете задачу согласованности данных в БД при поэтапном внедрении миграций.
Предположим, у вас есть несколько микросервисов, которые используют одни и те же таблицы, и вы вносите несовместимые изменения в схему (добавляете или меняете поля).
Как вы гарантируете, что часть сервиса со старой логикой корректно работает с новой схемой, пока не завершится канареечная выкатка? И что будет при откате, если новая версия уже успела создать/изменить записи в недопустимом для старого кода формате?
В статье вы подробно описываете подход к построению пайплайна для разных окружений и автоматизации всего цикла разработки и доставки. Однако нередко узким местом подобных систем становятся обновления баз данных и миграции схем при релизах, особенно если требуется zero-downtime.
Как вы гарантируете согласованность данных, когда код одной версии сервиса может временно работать с уже изменённой или ещё не до конца мигрированной схемой? И как при этом выстраивается процесс отката (rollback) при обнаружении критической ошибки, учитывая, что состояние базы данных зачастую нельзя «просто вернуть» к предыдущему состоянию без риска потери данных?
В вашей версии получается, что «правильно» реализовать Control Plane изначально проще, чем заново проектировать и заменять фундаментальную систему хранения в будущем. Но «правильность» решений на ранних этапах может оказаться иллюзорной — по мере роста облака, появления новых сценариев и изменений в индустрии может выясниться, что изначальный дизайн Control Plane требует серьёзных переделок. Как вы оцениваете риск того, что принятое сейчас архитектурное решение для Control Plane также придётся переосмыслять и переделывать с существенными затратами? Предусмотрена ли какая-то модульность или абстракция, позволяющая адаптироваться к новым требованиям без корневой реконструкции?
Вы говорите о стратегической важности полного контроля над стеком. Но почему тогда в качестве основы для хранения выбрали Ceph, а не стали разрабатывать систему хранения с нуля сразу? Если определённые компоненты можно брать готовыми, почему не использовать такую же логику для Control Plane с модификациями поверх OpenStack или других платформ?
Документация, это не решение проблемы ухода ключевых людей. Это страховка с франшизой. Она смягчает удар, но не предотвращает его. Настоящая защита от низкого bus factor не вики, а ротация задач, где никто не владеет модулем монопольно с обязательным код-ревью, контекст распределяется между 2+ людьми и тесты как документация, чтобы падающий тест показал, зачем нужен хак. Без этого любая база знаний, это красивое кладбище решений, принятых людьми, которых уже нет в команде.
Если белый список на домашнем интернете реально работает, откройте терминал и выполните:
Если маршрут обрывается на узле вашего провайдера (последняя строка с ответом внутри РФ), а при этом
tracerouteya.ruдоходит до конца, поздравляю это фильтрация транзита, а не атака на сеть.Пока в статьях ни одного скриншота трассировки, ни одного лога, ни сравнения через разных провайдеров. Только анонимные "собеседники". Без доказательств, это слух, а не факт.
Не верьте на слово. Проверьте сами, 30 секунд в терминале дадут больше ясности, чем 30 статей.
Очередная статья/сборник костылей без понимания архитектуры современных систем фильтрации. Давайте разберу самые критические упущения на мой скромный взгляд обывателя.
Замедление не равно блокировка, автор смешивает два разных механизма DPI:
Замедление — снижение скорости после распознавания сигнатуры (например, по JA3 fingerprint TLS handshake)
Белые списки — разрешение трафика ТОЛЬКО к доверенным доменам/IP, всё остальное отбрасывается на уровне маршрутизации
Против белых списков ни один из предложенных методов не работает, потому что трафик просто не покидает границы РФ. Это не замедление, это фильтрация на уровне пиринга.
MTProto и SOCKS5 это мёртвые технологии, сигнатуры MTProto известны с 2018 года. Современные ТСПУ детектируют его по всему возможному:
Фиксированному размеру пакетов (1024 байта)
Отсутствию TLS handshake
Характерному паттерну обмена ключами
SOCKS5 без шифрования это вообще подарок для анализа, все домены и IP видны в открытом виде. Работоспособность этих решений в 2026 году, признак того, что провайдер ещё не обновил правила фильтрации.
TG WS Proxy = локальный костыль, прокси на localhost не решает проблему на уровне сети, он лишь оборачивает трафик в WebSocket, но:
Не маскирует конечный домен (TLS SNI до ESNI/ECH раскрыт)
Не защищает метаданные (объём, частота запросов)
Требует постоянной работы фонового процесса — точка отказа
Модифицированные клиенты = риск компрометации, AyuGram/exteraGram — неофициальные сборки, даже при открытом исходном коде:
Нет гарантии, что собранный бинарник соответствует коду
Плагины (exitFy) загружаются из непроверенных источников
Риск внедрения бэкдора для сбора сессионных ключей
Главный упущенный риск, это метаданные, даже при успешном обходе фильтрации:
Провайдер видит объём трафика к зарубежным хостингам (например, 50 ГБ в месяц на сервер в Амстердаме)
Временные паттерны (подключение в 02:00 к одному и тому же IP)
Flow correlation (совпадение времени подключения с известными сетевыми )
Короче, ваши метаданные часто опаснее содержимого, ведь они строят социальный граф без расшифровки сообщений.
Реальное решение, это арендованный VPS + XTLS/VLESS с правилами маршрутизации (geoip/geosite), но и оно уязвимо против белых списков. Нет серебряной пули, есть только управление рисками и понимание, что любая попытка обхода оставляет следы на уровне метаданных.
Эта статья поверхностный обзор для широкой аудитории, но далеко не технический документ для принятия решений.
Основная проблема, это фактические ошибки в описании протоколов (OpenVPN, энтропия), смешение юридических и технических моделей (провайдер vs ТСПУ) и игнорирование метаданных как вектора утечки, плюс элементарное отсутствие анализа клиентских уязвимостей.
Рекомендация практикам, не использовать эту статью, как источник для архитектурных решений. Для оценки рисков лучше почитайте спецификации протоколов RFC 768 для WireGuard, RFC 5246 для TLS и тестируйте утечки через ipleak.net.
Анализируйте трафик в Wireshark с фильтром tls.handshake.type == 1 и помните, что идеальной анонимности нет, есть только управление рисками через многослойную защиту (не только VPN).
Спасибо за развернутые ответы, но пара моментов требует уточнения, потому что маркетинг и реальность немного расходятся:
Про 2 vCPU, вы сами признали, что это бизнес-решение, а не техническая необходимость. И что в будущем запустим экономичные типы. То есть сегодня клиент с микросервисом на 0.2 ядра сознательно переплачивает 900%, потому что ваша архитектура не умеет шарить ядра между ВМ. Выглядит как перекладывание неэффективности на клиента. Возможно лучше так и написать, типа минимум 2 vCPU, это временный компромисс ради упрощения архитектуры.
Про цены с натяжкой принято, по мне этого действительно не хватает, чтобы принять решение, потому что кроме прочтения статьи, надо пойти и найти прайсы. Ну ок.
Про миграцию ВМ, ок, ожидаем, у конкурентов она реализована, ведь это не просто фича, это база для обновления гипервизоров без даунтайма продакшена. Значит пока ваше облако не позволяет обновлять инфраструктуру без остановки ВМ.
Про географию, где две зоны в Московской области, при ЧС на уровне региона оба ЦОДа в одной точке отказа. Вы сами написали, что фактический RPO зависит от механизма записи и может быть ненулевым. То есть при городской аварии гарантирована потеря данных. Для критичных систем это осознанный риск, который клиент должен знать до выбора платформы.
Пока просто хорошая техническая база, но маркетинговая упаковка не соответствует зрелости платформы, потому что не хватает расклада по ограничениям и рискам.
Техническая статья без цен ок, норм. Но техническая статья, которая одновременно:
хвастается отказом от овербукинга (звучит как этический подвиг),
кричит "предсказуемость",
и при этом тщательно убирает единственный параметр, по которому архитектор оценивает предсказуемость, стоимость,
это не техническая статья. Это попытка прикинуться инженером, чтобы потом впаять клиенту ценник как у конкурентов, но чуть дороже, потому что мы честные. Если хочешь писать про честность, пиши цифры. Если не хочешь писать цифры, не используй слово "честное". Это не сложно. Это базовая честность с самим собой. А вопрос "вы правда ожидали цены", звучит так, будто вы только что спросили: "Вы правда ожидали, что еда в ресторане будет съедобной?" Нет. Я ожидал меню. Без цен, это не ресторан. Это социальная столовая.
Спасибо за ответы, но часть из них только подтверждает слабые места:
1) Лыткарино + Зеленоград оба в пределах Московской агломерации. При ЧС на уровне региона (кабельный коридор Москвы, авария на МРСК Центра) оба ЦОДа в зоне риска. Это не multi-region, это две зоны в одной географической точке отказа. Для критичных систем, недостаточно.
2) "Чётное количество vCPU во избежание запуска разных ВМ на одном ядре", логика странная. Если 1 физ. ядро = 2 HT-потока, то 2 vCPU = оба потока одного ядра. Вы не избегаете соседей, вы просто гарантируете, что ядро целиком отдано одной ВМ. Но тогда вопрос: почему нельзя 1 vCPU (один поток)? Для бота, фонового воркера, микросервиса с нагрузкой 0.1 ядра это прямой оверхед 900%. Это не техническое ограничение, это бизнес-решение. Признайте честно.
3) vCPU = поток, ок. Тогда при нагрузке 15% CPU вы платите за простаивающие 85% потока. И за второй поток того же ядра, который тоже простаивает. Без овербукинга это не честность, это неэффективность, переложенная на клиента.
4) "Поддержка Terraform есть", в документации вижу только описание REST API. Официальный провайдер в реестре HashiCorp registry.terraform.io есть? Или речь про кастомный модуль на коленке? Для автоматизации это разные вещи.
5) "Есть партнёр по DDoS" не есть встроенная защита. Это "идите сами настраивайте, платите третьей стороне, разбирайтесь с маршрутизацией". У Яндекса защита на уровне сети "из коробки".
6) Посмотрел, например "99,0% — 99,99% | простой от 4 мин 19 сек до 43 мин 11 сек | компенсация 5%", но проблема в том, что 99,0% в калькуляторе, это 7 часов простоя с компенсацией 5%. Серьезно?
7) "Невозможно всё охватить", цены не деталь для углублённого анализа. Цена это первое, что смотрит архитектор при сравнении платформ. Статья позиционируется как про честность, но базовый элемент честности, стоимость владения, убран за рамки. Это не техническая необходимость, это маркетинговый выбор.
Возникает небольшое количество вопросов в связи с вашей публикацией:
Два ЦОДа в Москве, это две зоны отказоустойчивости или два здания в пределах МКАД? Если второе, как вы гарантируете RPO < 5 мин при ЧС городского масштаба, например, кабельный срез по всем маршрутам?
Минимум 2 vCPU на ВМ, это архитектурное ограничение гипервизора или бизнес-решение? Для микросервисов с нагрузкой 0.2 vCPU это прямой оверхед 900%. Как обосновываете?
"Нет овербукинга", звучит очень честно, пока не посчитаешь TCO. Приведите сравнение стоимости 100 ВМ с нагрузкой 15% CPU против аналогичного кластера на Selectel/Yandex и пожалуйста цифры, не принципы.
1 vCPU = 1 физическое ядро или 1 HT-поток? Если поток, то как решаете contention при одновременной нагрузке соседей на разные потоки одного ядра?
Собственный стек вместо OpenStack окей, но где публичная документация по API? Поддержка Terraform provider есть или писать свой на коленке?
Цены в статье отсутствуют полностью. Это такой маркетинговый приём или политика "звоните, менеджер посчитает"? Для архитектора сразу красный флаг.
Производительность диска отвязана от объёма, это круто, но какая максимальная пропускная способность на ВМ? 1 Гбит/с? 10? Или как у некоторых "облаков" 300 Мбит/с и никакого SLA на сетку?
Тройная репликация "между двумя зонами", это 2+1 или 1+1+1? Если первое, то при потере одной зоны вы мгновенно теряете отказоустойчивость. Это осознанный компромисс?
DDoS-защита на уровне сети есть или клиент сам тянет трафик через сторонние фильтры?
Есть ли публичный SLA на доступность ВМ и дисков, и какие компенсации при его нарушении?
Пиринг с Google/Cloudflare/Microsoft есть напрямую или весь исходящий трафик идёт через одного транзитного оператора?
Снапшоты CoW ок, но сколько стоит хранение дельты в месяц? У некоторых провайдеров "бесплатный снапшот" превращается в 30% к стоимости диска за хранение инкрементов.
Как быстро работает миграция ВМ между хостами без даунтайма? Менее 30 сек или как в старых решениях 2–3 минуты с потерей сетевого стека?
У вас свои ЦОДы, супер, но кто поставщик питания и есть ли независимые вводы от разных подстанций?
И последнее, почему в статье, где вы пишите "что надёжность инфраструктуры и гибкость сервисов — это те требования, от которых нельзя отступать. И чтобы выполнить их честно, мы сделали ставку на два принципа: собственную физическую инфраструктуру и собственную разработку." нет ни одной цифры по ценам, ни одного бенчмарка, ни одного кейса клиентов, только лозунги?
Жду ответы, посчитаю реальный TCO под наш стек, пока выглядит как красивая презентация без цифр для принятия решения.
В статье описаны несколько передовых методов ускорения инференса (от FP8/INT4-квантизации SpinQuant до EAGLE-спекуляций и динамического сжатия KV‑cache). При этом вы подчёркиваете, что все эти техники можно комбинировать для мультипликативного эффекта ускорения. Как вы системно оцениваете взаимодействие таких методов, чтобы избежать отрицательных синергий (накладных расходов, накопления ошибок при агрессивной квантизации и т. п.)?
И есть ли у вас критерии выбора “оптимального набора” технологий для реальных сценариев, где важны как минимальная латентность, так и стабильное качество (например, при длинных контекстах, многошаговых диалогах или Q&A над большими документами)?
Кроме этого предлагаю добавить раздел о «динамическом комбинировании» ускоряющих техник, где подробно описать, как на практике выбирать набор методов (SpinQuant, FP8, EAGLE, DMC и т. д.) в зависимости от конкретных характеристик задачи и среды. Можно сформировать:
1) Методологию бенчмаркинга, предложить сценарии разной «длины контекста», вариативного батчинга и сложного многошагового диалога, чтобы показать, как каждая техника ведёт себя при определённой конфигурации.
2) Модель принятия решений, представить систему «весовых коэффициентов», которая позволит взвешивать приоритеты между «скоростью» и «качеством» для каждого метода.
3) Пример динамического выбора, описать, как в продакшен-системе можно подключать или отключать определённые оптимизации «на лету», ориентируясь на текущий контекст (например, длину запроса, оставшиеся GPU-ресурсы, нагрузку на сервис).
Таким образом можно показать не только набор техник, но и практический подход к тому, как эти методы эффективно комбинировать без нежелательной «накладной синергии» и падения точности.
По ходу статьи вы рассуждаете о необходимости объединять разнообразные форматы данных (текст, снимки, графики) в рамках единой мультимодальной модели и указываете на дискуссию между подходами “большие универсальные” vs. “компактные специализированные” системы. Как именно вы оцениваете эффективность этих подходов при работе с мультимодальным контекстом?
Например, на практике не станет ли Retrieval-Augmented Generation (RAG) с многомерными векторными БД слишком ресурсоёмким для “больших” MLLM, а попытка сократить модель до “малой” существенно ударит по качеству анализа сложных типов данных (вроде медицинских снимков и текстовых записей врача)?
Расскажите пожалуйста о критериях выбора оптимального размера и архитектуры MLLM, если набор мультимодальной информации очень велик и разнороден.
Позвольте уточнить несколько моментов, поскольку, судя по всему, возникло лёгкое недопонимание того, что я имел в виду:
«Ортогональность» тем Control Plane и системы хранения
Вы пишете, что «логически некорректно формулировать вывод, что одно проще, чем другое», и считаете их «ортогональными». Однако в предыдущих сообщениях (и статье) фактически прозвучало противопоставление: мол, строить собственный Control Plane сразу «адекватно», а систему хранения можно пока взять готовую (Ceph), а потом заменить.
Я не утверждал, что это «одна и та же» задача. Скорее, хотел показать: с точки зрения рисков и долгосрочных затрат обе области (Control Plane и Storage) критичны для облака. При этом в статье вы выбрали разные стратегии: Control Plane — полностью свой, систему хранения — временно стороннюю. Поэтому возникает логичный вопрос: почему одну «боль» вы решаете сразу с нуля, а вторую предпочитаете отложить, хотя в обоих случаях потенциально масштабные переделки чреваты большими усилиями?
Проблема «иллюзорной правильности» на старте
Мы говорили не о том, что «open source» изначально хуже, а о том, что любая архитектура, принятная на ранних этапах, может столкнуться с новыми сценариями, которые поначалу не были учтены. На практике есть масса примеров, когда даже собственный код, написанный опытными инженерами, нуждается в глубокой переделке при изменении рыночных условий или добавлении новых сервисов.
Ваш ответ сводится к тезису «мы имеем достаточный опыт и лучше понимаем домен, поэтому код будет проще адаптировать». Но опыт, безусловно, снижает риски, хотя и не обнуляет их. Остаётся открытым вопрос: какие именно механизмы модульности или абстракции вы закладываете, чтобы эти будущие изменения не привели к «годам боли»? Ведь даже с крутой командой нельзя предусмотреть абсолютно всё.
Свобода в будущем vs. Сложность текущей разработки
Вы уверены, что собственный Control Plane будет проще адаптировать, поскольку «это ваш код». Понятно, что отсутствие жёсткой привязки к чужой roadmap даёт свободу — но часто «самописные» решения по мере роста обрастают своими уникальными ограничениями и техническим долгом.
В open source-комьюнити много контрибуций и патчей, появляются новые фичи или паттерны, которые можно относительно легко «подтянуть». В случае полностью самописного Control Plane всё придётся делать силами своей команды. Это не всегда быстрее или дешевле, даже если команда «строит облако в третий раз».
Хотелось бы узнать, как вы будете оценивать целесообразность «подтягивать» некие сторонние компоненты, если технологический ландшафт изменится (например, появятся новые подходы к сетевой виртуализации или диспетчеризации ресурсов)?
Двойная логика выбора
Вы пишите, что OpenStack «проблемно адаптировать» под современные сценарии, поэтому сразу от него отказались; одновременно вы взяли Ceph с прицелом «потом спокойно перепишем, когда созреем». Но ведь Ceph — это тоже open source, со своими нетривиальными ограничениями.
Получается, что в одном случае (Control Plane) вас не устраивает необходимость глубоких доработок, поэтому делаете всё «под себя» здесь и сейчас.
В другом случае (Storage) та же самая проблема не воспринимается как блокирующая. При этом Ceph — довольно «тяжёлое» решение, которое тоже потребует немало усилий при интеграции и дальнейшей замене.
Именно поэтому у стороннего читателя может сложиться впечатление, что вы противопоставляете «сделать сразу правильно» и «взять что-то готовое с доработкой потом», хотя для обеих задач (Control Plane и Storage) риски похожи. Отсюда и наш первоначальный вопрос — как именно вы оцениваете риски долгосрочных переделок в собственном коде, и почему считаете, что этот риск меньше, чем при использовании open source-платформы (для Control Plane), но при этом нормальный для Ceph (Storage)?
Ваш опыт и экспертиза, несомненно, повышают шансы, что архитектура Control Plane будет продумана и более гибкая изначально.
Однако хочется понять, какие конкретные архитектурные паттерны или процессы (модульность, ревизия API, планирование backward-совместимых изменений и т. д.) вы используете, чтобы «фундамент» Control Plane не пришлось перелопачивать через пару лет с не меньшими издержками, чем при отказе от open source.
Надеюсь, удалось прояснить, что я не пытаюсь смешать в одну кучу две разных задачи, а скорее уточнить вашу логику по обеим направлениям. Ведь цель дискуссии — разобрать возможные технические и стратегические риски, чтобы чётче понимать, как вы пришли к нынешней архитектуре.
Вы упомянули фича-тоглы и канареечные выкатки, но не объяснили, как решаете задачу согласованности данных в БД при поэтапном внедрении миграций.
Предположим, у вас есть несколько микросервисов, которые используют одни и те же таблицы, и вы вносите несовместимые изменения в схему (добавляете или меняете поля).
Как вы гарантируете, что часть сервиса со старой логикой корректно работает с новой схемой, пока не завершится канареечная выкатка? И что будет при откате, если новая версия уже успела создать/изменить записи в недопустимом для старого кода формате?
В статье вы подробно описываете подход к построению пайплайна для разных окружений и автоматизации всего цикла разработки и доставки. Однако нередко узким местом подобных систем становятся обновления баз данных и миграции схем при релизах, особенно если требуется zero-downtime.
Как вы гарантируете согласованность данных, когда код одной версии сервиса может временно работать с уже изменённой или ещё не до конца мигрированной схемой? И как при этом выстраивается процесс отката (rollback) при обнаружении критической ошибки, учитывая, что состояние базы данных зачастую нельзя «просто вернуть» к предыдущему состоянию без риска потери данных?
В вашей версии получается, что «правильно» реализовать Control Plane изначально проще, чем заново проектировать и заменять фундаментальную систему хранения в будущем. Но «правильность» решений на ранних этапах может оказаться иллюзорной — по мере роста облака, появления новых сценариев и изменений в индустрии может выясниться, что изначальный дизайн Control Plane требует серьёзных переделок. Как вы оцениваете риск того, что принятое сейчас архитектурное решение для Control Plane также придётся переосмыслять и переделывать с существенными затратами? Предусмотрена ли какая-то модульность или абстракция, позволяющая адаптироваться к новым требованиям без корневой реконструкции?
Вы говорите о стратегической важности полного контроля над стеком. Но почему тогда в качестве основы для хранения выбрали Ceph, а не стали разрабатывать систему хранения с нуля сразу? Если определённые компоненты можно брать готовыми, почему не использовать такую же логику для Control Plane с модификациями поверх OpenStack или других платформ?