Льготы крепчают

ИТ-льготы взлетели до облаков в прямом смысле 🙂. Все преференции для ИТ сохранятся в том же виде, но теперь освобождение от НДС распространится и на облачный софт. Об этом заявил премьер-министр Мишустин на ЦИПРе.

Спросили у СЕО Облакотеки Максима Захаренко, что это значит для облачного рынка. Если коротко: когда льготы не действуют на облачные сервисы, ключевые преимущества облаков — гибкость и экономическая привлекательность — не реализуются в полной мере. А подробнее

Пока деталей нет, но это не мешает с удовольствием порассуждать на тему.

Современные ИТ-инфраструктуры компаний часто представляют из себя гибридные сценарии. Например, когда часть ресурсов размещена в традиционной ИТ-инфраструктуре в корпоративном ЦОДе, а часть предоставляется провайдером облачных сервисов в виде сервиса.

Когда клиент покупает лицензию на ПО в традиционный ЦОД, она не облагается НДС. Но если нужно то же самое ПО в том же самом объеме получить на площадке провайдера, то НДС уже приходится платить. Что особенно неудобно — эти нюансы развертывания нужно учитывать заранее, и очень сложно это потом поменять. Так теряется гибкость — одно из главных преимуществ облака.

В непростых современных экономических условиях, при высокой ставке, вспоминается еще одно важное преимущество облачных сервисов — отсутствие капитальных затрат. Небольшие ежемесячные платежи в режиме PAYG очень заманчивы для клиентов. Уверен, что такие модели потребления ПО привлекательны и для поставщиков. Однако мешали регуляторные ограничения, которые могли привести к уплате НДС. Похоже, что их снимают.

Важный нюанс: где-то в явном виде будет прописано освобождение от НДС облачных сервисов, построенных на ПО и ПАКах из Реестра отечественного ПО. И да, эта льгота никаким образом не коснется сервисов на базе софта, которого нет в перечне .

#Максим_ерунды_не_скажет

Сервис начинается с документации

Когда говорят про качество сервиса, обычно обсуждают отказоустойчивость, поддержку, интерфейсы, SLA. Но очень редко — документацию. Хотя именно она часто становится первой точкой контакта клиента с сервисом.

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

Признаюсь честно: раньше я относилась к документации примерно как к чему-то, что просто должно существовать. Где-то написано, ссылка есть — и ладно.

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

Кто пишет документацию в Облакотеке?

Если честно — все, кто причастен к сервису. Во-первых, инженер, который знает все технические детали. Во-вторых, product owner, который знает, как это должно работать для клиента и какие сценарии самые частые. Наконец, поддержка, которая знает, где клиенты спотыкаются чаще всего.

Но здесь есть важный нюанс: инженер почти всегда пишет для инженера. Ему кажется очевидным, что прежде чем что-то залить в бакет, нужно этот бакет создать, потом нужно получить ключи доступа, а потом уже подключаться и загружать объекты. Для него это базовая последовательность действий, а вот для клиента — далеко не всегда.

Поэтому у нас документацию финально «причесывает» тот, кто смотрит на нее глазами пользователя, а не админа или разработчика. Задача — убрать все, что требует специальных знаний для понимания, и добавить все, что автор пропустил, потому что сам знает это наизусть.

Как тестируем?

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

Также мы смотрим на тикеты поддержки. Если один и тот же вопрос приходит снова и снова — значит, ответ на него в документации либо отсутствует, либо написан так, что его не находят или не понимают. Это прямой сигнал к правке.

Кстати, именно так появился целый раздел с пошаговыми инструкциями по работе с нашими ВМ. Не потому что мы такие предусмотрительные, а потому что поддержка несколько раз объясняла одно и то же разным людям.

Зачем улучшать документацию?

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

Кроме того, плохая документация влияет и на поддержку. Когда первая линия не может дать клиенту ссылку на понятную инструкцию, ей приходится каждый раз объяснять заново, своими словами, с нуля. Это трата времени и энергии.

Что нам помогло?

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

Перестали писать «технически правильно», взамен стараемся писать понятно. «Выполните инициализацию соединения через API-endpoint» и «введите адрес сервера в поле подключения» — это одно и то же, но второй вариант поймет живой человек без словаря.

Готовим видеоинструкции для самых частых сценариев. Часть аудитории читает текст, а часть — смотрит.

Поддержка стала соавтором документации. Если первая линия видит, что клиенты регулярно спотыкаются на одном и том же месте — это сигнал для нас, и мы его обрабатываем.

Документация — это не приложение к продукту, а его часть. Если клиент не может разобраться сам — значит, сервис еще не готов .

#Оксана_объясни

Облачная оттепель: свежий медиадайджест

Собрали весенний дайджест — где засветилась Облакотека и какие тезисы стоит забрать с собой .

Железо месяца — «Российская газета»

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

Стратегия месяца — БИТ

Выбирать провайдера стоит не по лозунгам, а по понятным критериям: юрисдикция, совместимость с текущей ИТ-средой, реальная экономика, зрелость платформы и стратегия выхода. Почему именно они — читайте в материале.

Киберустойчивость месяца

Промышленность все чаще оказывается в фокусе вымогателей: остановка цеха или линии быстро превращается в ощутимый бизнес-ущерб. Здесь говорим о роли ИИ в защите производства и при этом держим в уме главное: если нет сегментации сети, контроля учетных записей и базовой ИБ-гигиены, никакая «умная» аналитика не спасет.

Конкуренция месяца

Облачный рынок взрослеет: конкуренция давно ушла от простого сравнения цен на виртуальные машины. Теперь клиенты смотрят на сервисную модель, экспертизу и готовность провайдера решать реальные задачи бизнеса. Что в фокусе у современных заказчиков — рассказали в колонке.

#засветились

Нет данных — нет проблемы. Продолжение

Ошибка дизайна промптов. Системный промпт агенту был написан в эмоциональном ключе, с капсом и матом, в стиле «NEVER FUCKING GUESS!».

Звучит вроде мотивирующе, но работает плохо. ИИ не испугается, а капс и ругательства не делают промпты более точными. Конкретные запреты приводят в типичную ловушку промтов «не делай»: при перечислении недопустимых действий можно легко оставить за бортом все, о чем не подумали.

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

Ну и вишенка на торте. Про маленький автопрокатный SaaS еще неделю назад знали полтора человека, а теперь говорят из каждого утюга. Ничего не утверждаю, но замечу, что «There's no such thing as bad publicity», то есть любой PR — это хороший PR, но тут уж пусть меня поправят коллеги из iTrend .

Денис Бойцов, операционный директор iTrend

Есть такое выражение «Геростратова слава». Оно означает, что известность достигнута либо в скандале, либо путем совершения чего-нибудь непотребного. Примерно это настигло PocketOS. Но то, как они выкручиваются, достойно учебников по пиару.

Исходный пост основателя компании построен как настоящий детектив. В начале сторилайна абзац лида — от описания ситуации стынет кровь. Затем абзац о том, что у них за компания, чем она занимается и как ее клиенты уже 5 лет жить без них не могут. А дальше — 3 экрана эмоциональных накатов и на ИИ-агент, и на поставщика инфраструктуры, и на черта лысого. Только PocketOS хорошие. И написано так душевно, от первого лица — читаешь и веришь. Мало кто умеет облажаться так красиво.

#созвонились_обсудили

Нет данных — нет проблемы

А вы же видели новость о том, как ИИ-агент в Cursor за 9 секунд удалил основную базу и все бэкапы стартапа PocketOS (1600+ клиентов, если что)? Заметил расхождения в учетных данных и поступил как настоящий перфекционист: в системе, которой не существует, ошибок быть не может.

Сегодня разберем этот кейс с PDE Облакотеки Владимиром Кондратьевым и обсудим, как держать ИИ на коротком поводке. Бонусом — посмотрим на ситуацию с точки зрения репутации вместе с коммуникационным агентством iTrend.

По иронии судьбы PocketOS занимается SaaS для аренды автомобилей, и сразу пришла в голову ассоциация: как только происходит авария с беспилотными машинами, все сразу подхватывают новость и трубят о ней. При этом забывают, что люди водят опаснее, а у большого процента аварий беспилотников причиной становится человеческий фактор.

Давайте разберемся, не обошлось ли и тут без этого фактора?

Что случилось? Разработчики SaaS-решения дали агенту в Cursor рутинную задачу в тестовой среде, агент уперся в проблему с доступом, нашел в постороннем файле API-токен от Railway и одним запросом удалил основной том вместе с бэкапами. Здесь явно заметны три ошибки, посмотрим на них по порядку.

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

Обычная рекомендация — добавлять API-токены, ключи и прочие критичные вещи в gitignore. Но для лучшей защиты у самого GitHub есть встроенный механизм с подходящим названием GitHub Secrets. В этом случае ключ подставляется в сборку в зашифрованным виде, и его не видно в коде. Этого хватает большинству небольших команд, городить корпоративные хранилища ради двух токенов обычно смысла нет.

Мог ли разработчик заранее понять, что у токена слишком широкие права? Здесь ответственность делится. Railway сам по себе выдавал токены с полным доступом ко всему, даже если создавался токен под безобидную задачу вроде управления доменами. Это была их собственная архитектурная ошибка, и после инцидента они ее признали и закрыли.

Разработчику же стоило не просто довериться известному сервису, а почитать документацию внимательно или даже провести тест токена.

Ошибка архитектурная. Все бэкапы хранились на том же томе, что и сами данные. Очевидно, что при удалении тома будут удалены и бэкапы. Это уже явная ошибка команды.

Со времен ленточных хранилищ известно старое правило «3-2-1»: три копии данных, два разных носителя, одна копия физически вне основной площадки. В итоге спасло компанию то, что у них все-таки нашелся отдельный полный бэкап трехмесячной давности, лежавший на стороне. Без него история закончилась бы «летальным исходом» для стартапа.

Продолжение

Самара, поехали! Запустили новую локацию Облакотеки

Вместе с нашим партнером VolgaCloud мы организовали уютную площадку в Поволжье. Она уже доступна для тестов и других задач. Вместе с нашей партнерской феей Женей Минаевой рассказываем подробности.

Что означает «запуск локации»?

Мы выбрали местный ЦОД — надежный и соответствующий всем нашим требованиям. Партнер установил необходимое оборудование. Затем мы совместно провели настройку сетей и интеграцию площадки в инфраструктуру Облакотеки, организовали подключение к личному кабинету для удобства пользователей.

В перспективе мы хотим предлагать площадку под самые непростые проекты с требованиями КИИ. А сейчас она доступна для любых задач и тестирования.

Почему именно Самара?

Причина проста — активность, инициатива и рвение партнера.

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

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

Чего мы ждем от проекта?

Я думаю, что в развитии площадки нам поможет локальный патриотизм и большее доверие со стороны региональных компаний. У нас есть задел на работу с госсектором и крупными промышленными предприятиями (ориентир на КИИ). Плюс будут более выгодные условия для самарских компаний и соседей по ПФО.

В целом, мне кажется, запуск площадки – удачный стратегический ход. Переход от простой перепродажи к соавторству — это именно то, что сейчас нужно рынку. Клиенты ищут не просто «железо» в облаке, а готовую экспертизу под ключ.

Кирилл Солохин, CEO Volga Cloud:

Для самарского региона и ПФО в целом это сильное УТП. Когда бизнес видит связку из федерального облачного провайдера и сильного локального игрока, это снимает главный страх региональных заказчиков — «быть просто строчкой в тикет-системе московского офиса». По сути, это выбор в пользу предсказуемости и настоящей партнерской и человеческой поддержки.

#мы_все_о_своем_об_облачном

Не NVIDIA единой

Сегодня вместе с Владимиром Кондратьевым, PDE Облакотеки, немного расшатываем культ одного вендора. Разбираемся на практике, что находится за пределами привычного стека и почему иногда стоит туда заглянуть.

Я регулярно получаю запросы, и почти каждый раз разговор начинается одинаково: «Нам нужна ВМ с картами H100, сколько стоит?». Я достаточно долго шел по пути «давайте попробуем дешевые NVIDIA вместо дорогих», пока в какой-то момент не задал себе вопросы: почему именно NVIDIA и что будет, если посмотреть шире?

Почему рынок так хочет NVIDIA?

NVIDIA запустила технологию CUDA (Compute Unified Device Architecture) еще в 2006 году.

Эта программно-аппаратная платформа для параллельных вычислений на GPU включает набор API, компилятор (nvcc), библиотеки (cuBLAS, cuDNN, cuFFT и др.) и драйверы. Проприетарная, работает только на железе NVIDIA.

В итоге видеокарта закрепилась в роли стандарта, и любая альтернатива стартует с позиции догоняющего. Дополнительно сыграл свою роль дефицит 2023-2024 годов: под срочные задачи нужно было брать то, что работает из коробки, а не то, что нужно «допиливать».

Фишка в том, что ИИ-индустрия очень быстро меняется, и сегодняшний расклад отличается не только от того, что было два-три года назад, а и от полугодовой давности.

Есть ли реальные альтернативы?

Компания AMD на рынке графических ускорителей существует давно — с 2006 года. Серверная ИИ-линейка называется Radeon Instinct: MI100 вышла в 2020 году, MI200 и MI210 в 2022, MI300X в конце 2023, сейчас на подходе MI450.

Софтверный стек ROCm (Radeon Open Compute platform) развивается по принципу open-source. Включает компилятор HIP (позволяет писать код, который собирается и под AMD, и под NVIDIA), библиотеки (rocBLAS, MIOpen, RCCL), драйверы. Работает на серверных Instinct и части потребительских Radeon.

Долгое время ROCm был заметно сырее CUDA, и именно это было главным тормозом. Ситуация принципиально изменилась с ROCm 7.0, который вышел летом 2025 года. Появились нормально работающие бэкенды под vLLM и SGLang, Другие движки — Hugging Face TGI, llama.cpp — тоже хорошо работают на ROCm.

Что получаем при сравнении?

AMD Instinct MI210 — это прямой аналог NVIDIA A100 PCIe 80GB. Обе карты одного поколения и имеют схожие характеристики. MI210 несет 64 ГБ HBM2e и 1.6 ТБ/с пропускной способности памяти, A100 идёт с 80 ГБ и 1.94 ТБ/с. В чистых FP32 и FP64 MI210 формально сильнее, но на FP16 и INT8 A100 будет впереди.

Почему стоит присмотреться к AMD?

Основной софт нормально работает. vLLM и SGLang на ROCm находятся в состоянии «включил и забыл».

Экономика. Например, MI210 на вторичном рынке сегодня обойдется в $7 тыс., A100 — это уже почти 10 тысяч. AMD был дешевле на старте (MSRP MI210 примерно вдвое ниже A100), и амортизация идет плавнее.

Весь стек AMD открытый: ROCm, драйверы, библиотеки. У NVIDIA же CUDA и ключевые компоненты проприетарные. Плюс в EULA на потребительские карты прямо прописан запрет на использование в дата-центрах, а у AMD таких ограничений нет в принципе.

Встает вопрос: если ли у вас цель получить LLM как сервис (LLM-aaS), который будет доступен через API, действительно ли важно, что там у нас под капотом? Пишите свое мнение в комментариях .

#искусственно_интеллектуально

Хотели как лучше, а получилось как всегда

Никто из нас не идеален, и в доказательство — наш директор департамента техподдержки расскажет о своих промахах при работе с людьми. Сегодня учимся на чужих ошибках, рефлексируем и ищем решение вместе с Ириной Курбатовой.

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

Когда-то мне казалось, что с этим багажом мои идеи точно незаменимы 😅. Но благие намерения не учитывали индивидуальные потребности коллег. К чему это приводило?

Людей с потребностью в юморе душило мое занудство.
Тех, кому важно уважение к их опыту и экспертизе, обижали замечания. Ведь гораздо более эффективно — спросить самого человека, как это лучше сделать, и учесть его рекомендацию в общем плане действий.
Тем, кому важно четко планировать время, мои предложения создавали проблемы, если я не задумывалась о том, сколько времени понадобится на их реализацию.
Для коллег, действующих с азартом и фокусом на быстрые изменения, мои списки предложений, детальные шаги реализации планов были жутким усложнением и потерей драгоценного времени.
Люди, которым важно побыть в одиночестве, зачастую видели решения лучше моих. А назойливость и дотошность со стороны здесь были лишними.

Как исправляем ошибки?

Личная адаптивность начинается с умения видеть: как мои действия (или бездействие) повлияли на результат, какой подход мог бы дать результат лучше, и что стоит сделать прямо сейчас.

Про результаты действий рассказала выше.

Новый подход — стараюсь применять свои исследовательский талант и опыт только там, где попросили. При этом сверять стиль подачи с потребностями другого человека. А если не просят, то никто не мешает изучать новое в своем узком направлении работы.

Что я делаю для этого прямо сейчас? Во-первых, разделяю задачи на те, где был запрос на помощь, а где нет, и сдвигаю фокус внимания туда, где действительно нужен мой вклад. Во-вторых, чаще спрашиваю себя: своевременны ли мои предложения и замечания? Вместе с кем воплощать изменения будет эффективнее?

#Ирина_поддержи

Следующая остановка — Азия. Невошедшее

В интервью у нас все серьезно и по делу: рынок, возможности, ограничения. Но кое-что осталось за кадром — публикуем размышления Максима Захаренко про конец глобализации и особенности работы на восточном рынке.

Как изменился глобальный контекст для выхода на зарубежные рынки?

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

Интернета, как мы его знали изначально — сети, которая объединяет людей и дает полный доступ к информации — сейчас практически не существует. РФ лишена доступа к технологическим сервисам Запада из-за санкций. Там, где западные санкции не используются, Россия сама себя отрезает от остального мира запретом практически всех известных коммуникационных сервисов.

Но это происходит не только у нас. Китай и США взаимно изолируют себя от технологий друг друга. Уже больше десятка стран заявили об отключении детей от соцсетей. Фильтрация любого трафика на государственном уровне стала технологически возможной и используется повсеместно. Практически все страны ввели суверенизацию персональных данных: требуют размещать и обрабатывать ПД граждан на своей территории.

И, конечно, бэкдоры, встроенные так или иначе во все умные устройства, ограничивают использование «чужого» оборудования и софта не только на КИИ, но и, зачастую, вообще в стране.

Центральная Азия в таких мировых условиях — «тихая гавань». Это небольшой осколок той самой глобализации, поэтому приходится конкурировать со всеми: американскими, российскими, китайскими, индийскими компаниями.

Какие есть особенности при работе в ЦА?

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

В Азии не отказывают прямо. Мне очень сложно, когда не говорят «нет». Ты надеешься, отрабатываешь, тратишь силы, когда надо было бы понять, что это уже «нет».

Есть свои нюансы общения. Тут принято спрашивать «здравствуйте, как вы?». Это просто вежливость, не надо на это реально отвечать как у вас дела. Что-то типа «how do you do» в английском.

При этом никак не получается договориться с молодыми сотрудниками общаться на «ты». Им тыкаешь, а они к тебе на «вы» — «Максим ака».

Еще важно выглядеть солидным, что лично мне сложно. Зато мои местные ребята умеют «дуть щеки» 😊.

#Максим_ерунды_не_скажет

Следующая остановка – Азия. Стоит ли российским ИТ-компаниям выходить на зарубежные рынки в 2026?

Давние связи, близость к России, ИТ-решения в дефиците – казалось бы, рынок Центральной Азии выглядит для российских компаний привлекательно. А как обстоит дело на самом деле?

Обсуждаем тонкости выхода на Восток с СЕО Облакотеки Максимом Захаренко. Облачный провайдер уже несколько лет ведет бизнес в Казахстане и Узбекистане, так что опыт накопился солидный.

Выходить или не выходить?

Для российских технологических компаний складывается достаточно сложная ситуация на внутреннем рынке РФ. Во-первых, непростая экономическая обстановка с существенным уменьшением расходов на ИТ. Вторая тенденция – технологические ограничения и отключение интернета, на котором завязаны все ИТ-сервисы. И, что мне кажется еще более важным, это надолго.

Так что выход на новые рынки может быть одним из немногих вариантом развития для технологической компании. Были бы ресурсы.

У нас есть опыт работы в Казахстане и Узбекистане. Мне кажется, эти страны выбрали выигрышную стратегию – быть тихой гаванью в мировом хаосе.

Открытая инвестиционная политика, дружба со всеми (Узбекистан взаимовыгодно дружит даже с Афганистаном), выгодное географическое положение в центре Азии, через который идут маршруты из ЮВА/Китая на Запад (новый Великий Шелковый Путь), специальные институты ИТ-развития (Астана Хаб, IT-Park) – все это дает 6-8% годового роста ВВП и создает атмосферу развития.

Что нужно знать о местном рынке?

ИТ-рынок в регионах ЦА менее насыщен: в высоких технологиях, особенно в качественном технологическом сервисе много незанятых ниш. Однако, несмотря на дефицит предложения, бизнес не будет бросаться на все, что предлагают из РФ.

Надо помнить, что здесь открыты технологиям со всего мира, поэтому приходится со всеми конкурировать. Российским компаниям еще предстоит доказать свою конкурентоспособность в ЦА – и это будет не просто. На слуху единицы успешных выходов на другие рынки. Можно вспомнить Яндекс Go: сервис стал лидером среди агрегаторов такси в странах ЦА. А кто еще?

При этом в Казахстане и Узбекистане к российским технологическим компаниям отношение в целом хорошее. Никаких ограничений ни формально, ни фактически нет. Но есть и нюансы. Банки внимательно контролируют платежи за ИТ (ПО, оборудование, ИТ-сервисы), чтобы избежать проксирования поставок в РФ западных решений и не попасть под вторичные санкции.

Также в ЦА работает огромное количество иностранных корпораций. Это значительный платежеспособный пласт клиентов, которым, по внутренним политикам, нельзя работать с компаниями с российскими корнями.

Нужно ли локализоваться?

Поскольку российский бренд или отдельный бренд для международного бизнеса одинаково неизвестен, я бы рекомендовал второй вариант. Все равно заново раскручивать, но локальность даст некоторое преимущество.

У нас в этом регионе, например, полноценные офисы. Удаленно найти партнеров и стать «своим» очень сложно. Я сам езжу в ЦА два раза в год, потому что стратегических вопросов много и «вес начальника» в переговорах играет важную роль.

Какие уроки мы извлекли?

Я не устану повторять фразу красноармейца Сухова: «Восток – дело тонкое». Да, у нас много общего. Советское прошлое, коллективизм, русский язык существенно упрощают процесс общения и работы. Но есть и много различий – и со временем, сходство уменьшается, а различий становится больше.

Значительная часть нашего бизнеса основана на партнерстве с местными технологическими компаниями. Это работает, если ты станешь своим, заслужишь доверие, что происходит не быстро.

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

#мнение #экспорт

ИЗЧ в VK | MAX

Наш СЕО Максим Захаренко дал интервью для канала «Импортозамещение здорового человека». Поговорили о том, стоит ли российским ИТ-компаниям выходить на зарубежные рынки в 2026 и почему Центральная Азия все чаще оказывается в фокусе .

Больше каналов — дороже доверие

Раньше канал связи выбирали. Теперь — проверяют, какой из них еще живой. Наша партнерская фея Женя Минаева порассуждала сама и пообщалась с партнерами на тему инструментов для деловых коммуникаций в 2026 году.

Главный вывод, к которому все пришли: кто ищет, тот всегда найдет, создаст, придумает. Главное — оставаться на связи и оставаться людьми. Не просто быть в доступе 24/7, а сохранять качество контакта в потоке цифрового шума. А вот что думаю лично я .

В 2026 году коммуникации с партнерами скорее всего еще не один раз изменятся. Сейчас в мире полно инструментов, но их выбор всегда зависел не только от удобства и популярности, но и от стабильности платформы.

Telegram перестал быть удобным и абсолютно стабильным мессенджером, бизнес начал активнее диверсифицировать каналы связи. Электронная почта уже не прошлый век, а «островок стабильности» и независимости от политики соцсетей. Это по-прежнему более надежный вариант фиксации официальных договоренностей.

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

Что говорят наши партнеры?

Павел Карасев, бизнес-партнер «Компьютерных технологий»:

Новые вызовы — это повод актуализировать информацию о партнерах. Первое что нужно сделать: обновить информацию, email, мобильный и офисный телефон, спросить какой вид связи сейчас предпочтительный. Это и точка контакта, и проявление заботы для сохранения партнерских связей.

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

Александр Жогов, CEO ИТ-компании «+Альянс»:

2026 год не перестает удивлять :) Мы продолжаем общаться в корпоративном мессенджере от зарубежных коллег внутри компании и с теми клиентами, у кого он есть. С другими — продолжаем «тележиться».

Ну а для параноиков запустили у себя MAX, даже сделали интеграцию с CRM и Service Desk. А вот как пройти там верификацию (российской компании в российском сервисе!) — это отдельная история.

Алексей Бовин, директор по развитию SoftStore:

Да придумаем чего-нибудь, нам бы побольше вызовов рынка! Кстати, можете общаться у меня на проекте nabaze.online. Я его сделал для детишек, чтобы в играх созваниваться, но использовать можно и по другому назначению. Создали комнату с паролем и сидите, демонстрацию экрана и OBS Studio уже прикрутил.

Алексей Набоков, основатель компании «Центр компетенций»:

Мы точно останемся в Telegram. У нас не только российская аудитория, мы все больше работаем с другими странами. В целом, важно не столько где, сколько как: с нами можно общаться по почте, в Telegram, в Teams — главное, чтобы это был живой человеческий диалог. Сейчас, в эпоху ИИ, особенно не хочется общаться с бездушными ботами. Важно знать, что по ту сторону есть человек.

Павел Житнюк, генеральный директор коммуникационного агентства iTrend:

Все наши клиенты — ИТ-компании с продвинутыми пользователями, поэтому абсолютное большинство продолжают использовать Telegram. И планируют это делать до тех пор, пока не возникнет легальных препятствий.

Некоторые компании тестируют альтернативы: Яндекс Мессенджер, встроенные решения Bitrix. Есть единичные случаи переезда рабочих чатов в Max. А вот почта и звонки не показывают значительного роста — привычка к мессенджерам и удобство работы в них пока сильнее.

#Женя_давай_дружить

Один в бизнесе не воин

Поговаривают, что в Китае сейчас бум «компаний одного человека» — предпринимателей, у которых почти нет сотрудников, зато есть ИИ-агенты. Президент Alibaba Куо Чжан утверждает, что от 30% до 40% клиентов их платформы — это такие компании.

Обсудили этот феномен с Максимом Захаренко, СЕО Облакотеки.

Не так давно оказалось правдой совершенно нереалистичное футуристическое известие, что китайцы построили солнечную электростанцию площадью с Казань и мощностью 21 ГВт. Кому интересно — загуглите спросите ИИ про Talatan Solar Park. Китай, конечно, страна чудес, но новости, поступающие оттуда, надо как следует фильтровать.

Перейдем к one‑person companies (OPC). Да, ИИ уже сейчас уверенно заменяет людей во многих сферах, но, далеко не во всех. Пока еще ждет своих умных роботов вся деятельность, связанная с физическим миром: логистика, стройка, сельское хозяйство, ноготочки 😁. Все это основано на работе людей, хотя им и могут помогать умные инструменты.

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

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

Особенно странно, что концепцию OPC поддерживают местные власти. Очевидно, она ведет к массовой безработице и социальной напряженности.

Подводя итог — цифры явно натянуты. А сама новость больше связана с промо ИИ-агента Accio Work, чем с реальностью .

А вы что думаете про концепцию OPC?

#взлетит_не_взлетит

Нажать нельзя подождать

Когда выкатывать релиз? Да кто его знает. Зато мы на своем опыте поняли, когда этого делать точно не стоит. Сегодня об этом расскажет Оксана Новицкая, директор по развитию Облакотеки. И заодно объяснит, как снизить риск того, что все пойдет не по плану.

У нас нет тяжелого этапа согласований релизов с протоколами, обоснованиями и подписями. Но есть четкий ритм: обновления выходят примерно раз в две недели.

Дату, как правило, определяет руководитель команды разработки, но не единолично. Она согласовывается с продуктовыми владельцами, в том числе со мной. Это важный момент. Я смотрю не только на техническую сторону, но и на контекст: кто из клиентов может почувствовать изменение, нет ли у них сейчас горячего периода (закрытие месяца, например).

Когда лучше подождать?

Это самая живая часть нашей практики, потому что ответы мы получили не из учебника.

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

Перед горячим периодом (в том числе и у клиентов). Конец месяца, праздники, высокая нагрузка у партнера — не время для экспериментов с продакшном.

Когда мониторинг показывает «что-то красное». Добавлять изменение поверх нестабильной системы — все равно что чинить машину на ходу. Сначала стабилизируем, потом двигаемся.

То, что войдет в релиз, должно быть заранее известно. Никаких сюрпризов в последний момент (по крайней мере, мы к этому стремимся). Если появляются блокирующие факторы, то обновление сдвигается. Лучше изменить дату, чем выкатить что-то сырое.

Небольшие исправления, не затрагивающие глобальную логику, могут выходить чаще и без оповещений клиентов.

Зачем нужен план отката?

Конечно, перед выкаткой на релиз мы бэкапим все, что может быть затронуто. Базы, сервисы, микрофронты и так далее.

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

Как минимизируем риски?

Со временем у нас выработалось несколько привычек:

Сначала песочница. Любое изменение проходит через тестовую среду, близкую к боевой. Соблазн «да там ничего сложного» велик, но мы его давим. Есть, конечно, некоторые моменты, которые мы не можем воспроизвести в песочнице, но это какие-то совсем исключительные случаи.

Обязательная проверка в релизе основных функциональных элементов. Сразу после выкатки релиза все проверяем. Не обновили и пошли спать, а запустили автотесты, проверили все элементы, отследили отсутствие ошибок в логах.

Клиент всегда знает заранее. О дате и времени выкладки обновлений обязательно оповещаем. Клиент, которого предупредили, реагирует совсем иначе, чем тот, которого просто накрыло.

Хороший процесс управления изменениями — это не про бюрократию, а про понимание: что меняем, почему сейчас, что делаем, если все пойдет не так. Когда это понимание есть, то можно двигаться быстро и не бояться каждого деплоя .

#Оксана_объясни

Разделяй и властвуй… над данными

Если в компании очередь к DWH-команде длиннее, чем в поликлинике, то Data Mesh придумали для вас. Сегодня рассказываем, в чем суть подхода и как он применяется на практике. Для этого расспросили Александра Зеньковича, руководителя направления DWH/ML в компании «ДАР» (ГК «КОРУС Консалтинг»).

Почему компании переходят на Data Mesh?

Цель — быстрее извлекать пользу из данных: повышать их качество и применять для развития решений, оперативно запускать аналитику. Классический подход монолитного хранилища для манипуляций с информацией скорее мешает выполнить эту задачу. А единая DWH-команда обычно перегружена.

С подходом Data Mesh мы переносим ответственность за работу с данными на бизнес-домены. У таких подразделений, как маркетинг и продажи, например, есть свои источники данных и показатели. Команды сами собирают и структурируют информацию, но используют при этом стандартизированную инфраструктуру и правила для публикации и использования данных.

В итоге новые аналитические сценарии появляются быстрее, а «центральная команда» разгружается. В ряде проектов мы видели сокращение time-to-market аналитики в 1,5-2 раза и более прозрачную ответственность за качество данных.

Как это работает на практике?

Вначале мы декомпозируем бизнес на домены и закрепляем за ними ответственность за работу с собственными данными.

Далее выстраиваем платформенный слой: единый стандарт data-продуктов, каталог данных, базовые сервисы (хранение данных, их обработка и доступы). Так команды разных доменов могут работать по единым стандартам, автономно публиковать и использовать свои данные.

Важно закладывать правильную масштабируемую архитектуру платформы и выделять ИТ-ресурсы и команду под новые запросы. Кроме того, удобно использовать облака: они дают гибкую инфраструктуру и готовые сервисы — управление доступами, например.

Какие подводные камни?

Главный риск в том, что Data Mesh воспринимают как работу с исключительно технологической архитектурой. Но самый сложный шаг — это организационная и управленческая трансформация. Если нет изменений в бизнес-модели и реальных владельцев данных в доменах, то все сводится к «старому DWH на новых технологиях». Эффекта не будет.

Другая ошибка — преждевременная децентрализация. Когда команды получают автономию, но нет стандартов (единые Data Governance и Data Quality), это приводит к фрагментации, росту издержек и конфликтам между бизнес-доменами. Качество работы с данными может снизиться.

На практике важно внедрять Data Mesh поэтапно: сначала платформа и правила, а затем — постепенное распределение ответственности между подразделениями.

Кому подойдет Data Mesh?

Крупным компаниям с большим количеством доменов, команд и источников данных (например, в ритейле, финтехе, телекоме). То есть там, где с данными работают десятки команд и есть распределенная модель управления.

Отдельные элементы Data Mesh можно закладывать и в молодых, небольших компаниях, чтобы избежать проблем масштабирования в будущем.

#созвонились_обсудили

Модель думает, база знает

Если у вас в компании база знаний лежит мертвым грузом, а сотрудники и клиенты все равно спрашивают одно и то же — есть новости. Мы в Облакотеке подняли RAG-пайплайн на своем железе и ищем тех, кто готов его протестировать на реальных данных. И да, это бесплатно пока что.

В чем суть?

RAG (Retrieval-Augmented Generation) — это архитектурный подход, при котором языковая модель отвечает не на основе своих весов или данных, на которых ее учили, а на основе контекста, извлеченного из вашей базы знаний в момент запроса.

Это работает так: запрос превращается в векторный формат, по нему ищется семантически близкий контекст, который передается в LLM вместе с вопросом. В результате система дает ответы, основанные на реальных данных, что сводит процент галлюцинаций к минимуму.

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

Что конкретно подняли?

Pipeline разбит на три независимых компонента, каждый на отдельной VM.

Embedder. Используем BGE-M3 от BAAI — одна из лучших открытых моделей для многоязычного эмбеддинга, поддерживает до 8192 токенов на входе, хорошо работает с русским языком. Принимает документы при индексации и запросы в продакшене, переводит в векторные представления.

Параметры VM: RTX A4000; 8 CPU; 46 GB RAM; 100 GB SSD.

Векторная БД. Отдельная легкая VM для хранения эмбеддингов и обработки семантического поиска. Тестируем несколько типов VBD, в том числе и для GraphRAG.

Параметры VM: 2 CPU; 4 GB RAM; 50–100 GB SSD.

LLM Qwen3.5-9B, инференс через SGLang. Используем модель от Alibaba, Qwen3.5-9B, которая вышла в феврале 2026 года. В ней 9 миллиардов параметров, контекстное окно ~262K токенов, что важно для RAG с большими базами знаний.

Модель поддерживает два режима работы: с цепочкой рассуждений (thinking mode) и без нее — для задач, где важна скорость ответа. SGLang обеспечивает эффективный батчинг и высокую пропускную способность на GPU, это рекомендованный фреймворк для инференса Qwen3.5. Под модель выделены две карты RTX A4000 по 16 GB VRAM каждая — итого 32 GB суммарной видеопамяти через тензорный параллелизм, что позволяет комфортно разместить модель и обслуживать параллельные запросы.

Параметры VM: 2× RTX A4000; 16 CPU; 92 GB RAM; 512 GB SSD.

Наш стек: Ubuntu, NVIDIA Driver, NVIDIA CUDA, Docker, Docker Compose. В качестве векторных хранилищ используем Qdrant, PostgreSQL + pgvector, LanceDB и Milvus. Также применяем SGLang и техники кэширования для оптимизации вычислений.

Что за GPU используем?

RTX A4000 — профессиональная графическая карта с 16 GB VRAM, изначально спроектированная для CAD и визуализации, а не для дата-центров. Аренда или покупка таких карт существенно дешевле, чем A100 или H100. Именно RAG делает это возможным: модели не нужно помнить все из весов — нужный контекст подается в момент запроса.

Поэтому 9B-модель на 32 GB суммарной VRAM справляется с задачами, для которых без RAG потребовалась бы модель в разы большего размера и соответствующее железо. Качество ответов при этом определяется качеством подготовки данных и релевантностью извлеченного контекста.

Какие особенности подготовки данных?

Это очень важный первоначальный этап: документы нужно очистить, разбить на чанки, проиндексировать через эмбеддер и загрузить в векторную БД. Мы готовы помочь с этим процессом в рамках тестирования — это отдельная экспертиза по эффективной подготовке данных.

Кому может быть нужно?

Компаниям, у которых есть структурированная база знаний, документация, FAQ (что угодно, по чему должна отвечать модель) и желание попробовать RAG.

Нам, в свою очередь, нужна нагрузка системы и обратная связь по качеству. Поэтому бесплатно выдаем в тест работающий RAG-pipeline. Если вы давно хотели «прикрутить» LLM к своей базе знаний — напишите в личку Владимиру @VladimirSTV, обсудим.

#искусственно_интеллектуально

Сегодня пятница, значит, можно себе позволить немного отвлечься от логов и деплоев. Предлагаем сыграть в нашу небольшую игру!

В чем суть? При помощи эмодзи мы загадали девять фильмов/сериалов про ИТ, ИИ, роботов и технологии будущего. Ваша задача — листать картинки и угадывать фильмы. И, конечно, хвастаться в комментариях, сколько вы отгадали.

Ответы:

1) Я, робот
2) Бегущий по лезвию
3) Социальная сеть
4) Матрица
5) Мистер Робот
6) Черное зеркало
7) Кремниевая долина
8) ВАЛЛ-И
9) Терминатор 2: Судный день

P.S. Если узнали все — либо бы вы очень догадливы, либо просто уже давно в ИТ и умеете читать странные наборы символов 😄.

#пятничный_оффтоп