Для пользователей браузера и приложения это означало недоступность интерфейса, которую обычная смена DNS не устраняла. Для разработчиков есть отдельная оговорка: таблица Comss с результатами проверки поддоменов не доказывает доступность API OpenAI. Хабр сообщал, что без специальных сетевых средств API тоже не работал. Ниже разбираем, что именно проверяли источники и какие выводы позволяют сделать эти измерения.

• По замерам Comss с российского подключения и пяти российских точек коллег, TLS с именем chatgpt.com обрывался; другое имя на том же IP проходило проверку.
• Результат совместим с фильтрацией по SNI, расширению TLS с именем запрашиваемого сайта. Кто её выполнял, источники не установили.
• В браузерах наблюдались PR_CONNECT_RESET_ERROR, ERR_TIMED_OUT и ERR_CONNECTION_RESET; приложение оставалось на сером экране с логотипом.
• api.chatgpt.com фигурирует только в таблице Comss. Доступность API OpenAI эта проверка не подтверждает; Хабр сообщал о проблемах с API.
• По данным detector404, на которые ссылается Хабр, проблема пропала спустя более 15 часов. В сохранённых материалах нет официального объяснения причин.

Что показала проверка имени сайта?

Comss обращался к серверу напрямую по IP-адресу, подставляя имя сайта вручную. TLS-рукопожатие с именем chatgpt.com обрывалось во всех попытках, с посторонним именем на том же адресе проходило. Три обычных запроса подряд возвращали код 000 и время рукопожатия 0,000000 секунды; тот же сервер, проверенный локально с его стороны, отвечал за 0,07 секунды. Коллеги издания, обслуживающие DNS-серверы Comss.one, независимо повторили замеры с пяти российских точек. В тесте все проверяемые имена вели на один зарубежный адрес: четыре имени прошли проверку, а chatgpt.com получил обрыв.

SNI передаёт имя запрашиваемого сайта в начале установки защищённого TLS-соединения. Если это имя не скрыто, например расширением ECH, его может прочитать оборудование на маршруте. Сочетание успешного соединения с другим именем на том же адресе и обрыва с chatgpt.com согласуется с фильтрацией по SNI. Это техническое объяснение результата, которое приводит Comss. Само по себе оно не устанавливает владельца оборудования и причину появления правила.

Код 000 в приведённом результате не является ответом HTTP-сервера и не заменяет код 403. Он показывает, что обычного HTTP-ответа в этой попытке не получили. Так же нулевое время рукопожатия в отчёте нельзя читать как мгновенное успешное подключение: рядом с ним источник фиксирует неуспех соединения. Значение сравнительного теста в том, что адрес оставался прежним, а результат менялся вместе с именем.

Какие адреса проверял Comss?

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

• chatgpt.com: обрыв;
• ab.chatgpt.com: открывается;
• api.chatgpt.com: открывается;
• openai.com: открывается;
• auth.openai.com: открывается.

Адрес api.chatgpt.com из этой таблицы нельзя использовать как подтверждение работоспособности программного интерфейса OpenAI. Хабр отдельно сообщает, что API без специальных сетевых средств не работал. Проверка имени при TLS-рукопожатии и успешный запрос к API проверяют разные этапы: первое ещё не означает, что приложение сможет авторизоваться и получить ответ. Поэтому делать вывод о доступности API на основании таблицы Comss нельзя.

Почему смена DNS не устраняла проблему?

DNS отвечает за получение адреса по имени сайта. В описанных замерах адрес уже был известен: исследователи обращались к нему напрямую. Обрыв возникал позже, во время установки TLS-соединения, когда клиент передавал имя. Comss отдельно сообщил, что Comss.one DNS для chatgpt.com больше не устраняет ограничение. Замена резолвера сама по себе не скрывает SNI, поэтому эти два этапа диагностики нужно разделять.

Раньше, по описанию Comss, соединение доходило до сервиса, который отвечал кодом 403 с сообщением о недоступности в регионе. В новом случае браузеры показывали сетевые ошибки: Firefox сообщал PR_CONNECT_RESET_ERROR, в браузерах на Chromium встречались ERR_TIMED_OUT и ERR_CONNECTION_RESET. В приложении оставался серый экран с логотипом. Эти признаки помогают описать сбой пользователю, но одна ошибка браузера без сравнительного замера ещё не доказывает фильтрацию по имени.

Что известно о длительности и причинах?

Хабр со ссылкой на detector404 пишет, что сбой затронул разных провайдеров, начался 6 сентября и пропал спустя более 15 часов. Это длительность из сообщения источника; собственных непрерывных измерений редакция не проводила. Хабр также отмечает, что глобального сбоя сервисов OpenAI не зафиксировано. В сохранённых материалах нет официального объяснения инцидента или установленного оператора фильтрации.

При повторении проблемы полезно записать время, провайдера и точный текст ошибки, отдельно проверить получение адреса и установку TLS-соединения. Это позволит сравнивать одинаковые симптомы вместо общего сообщения «ChatGPT не работает». О других причинах недоступности мы писали при разборе сбоев ИИ-сервисов; устройство приложения затрагивали в статье о том, что хранит в кеше десктопный ChatGPT. Для этого инцидента открытым остаётся вопрос о причине появления и исчезновения обрывов.

Источники: Comss.ru: ChatGPT начали блокировать в России: раньше доступ ограничивала сама OpenAI, Хабр: Сетевой сбой в работе ChatGPT в РФ, спустя 15 часов проблема пропала

Изображение на обложке: OpenAI, логотип

Цифровой рубль — не криптовалюта и не «безнал на карте». Счёт открывается на платформе Банка России, а банк выступает посредником, через приложение которого клиент этим счётом управляет. Один человек или компания может иметь только один такой счёт; у ИП их два: личный и для бизнеса. Если вы делаете интернет-магазин, кассу, биллинг или сервис подписок для компании из первой волны, приём цифрового рубля становится обязательным сценарием, а не опцией.

• Счёт цифрового рубля открывается на платформе Банка России через раздел «Цифровой рубль» в приложении подключённого банка; один счёт на физлицо или компанию, у ИП два.
• Лимит пополнения для физлиц — 300 тыс. рублей в месяц, для бизнеса лимита нет; тратить накопленное можно без ограничений.
• Для граждан операции бесплатны; для бизнеса комиссии не взимаются до конца 2026 года, тарифы с 2027 года установлены отдельным решением Банка России от 28 августа.
• Принимать цифровые рубли обязаны с 1 сентября 2026 года торговые компании с выручкой свыше 120 млн рублей, у которых на 1 января 2026 года был договор с крупнейшим банком-участником; торговые точки с выручкой до 5 млн рублей освобождены.
• Все банки с универсальной лицензией подключаются к 1 сентября 2027 года, с базовой — к 1 сентября 2028 года; сроки закреплены законом 248-ФЗ.

Как это устроено

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

Граждане смогут пополнять счёт цифрового рубля со своих банковских счетов на сумму до 300 тыс. рублей в месяц. Для бизнеса лимита на пополнение нет. Всеми накоплениями на своём цифровом кошельке и граждане, и компании смогут распоряжаться без ограничений.

Доступные операции: переводы между гражданами и компаниями, платежи в бюджет и из бюджета, оплата покупок, возвраты. Открытие и закрытие счёта бесплатны, для граждан бесплатны все платежи и переводы. Для бизнеса действует льготный период до конца 2026 года; тарифы для индивидуальных предпринимателей и компаний с 2027 года установлены отдельным решением Совета директоров Банка России от 28 августа 2026 года. По вопросам работы с цифровыми рублями регулятор советует обращаться сначала в свой банк, затем на горячую линию Банка России по цифровому рублю: 8 800 301 30 00, короткий номер 301 с мобильного или +7 499 300 3 301.

Сроки для банков и магазинов

Внедрение идёт волнами. С 1 сентября 2026 года инфраструктуру открывают крупнейшие банки, а торговые компании с выручкой свыше 120 млн рублей в год, у которых на 1 января 2026 года был договор с таким банком, обязаны принимать цифровые рубли. С 1 сентября 2027 года такую возможность должны обеспечить все банки с универсальной лицензией, с 1 сентября 2028 года — банки с базовой лицензией. Торговые точки с выручкой меньше 5 млн рублей от обязанности освобождены, как и торговые точки там, где нет интернета. Обязательные сроки для банков и продавцов закреплены федеральным законом 248-ФЗ, а решение Банка России определяет лимиты, перечень операций и порядок добровольного раннего подключения остальных банков.

Что это значит для разработчика платёжной интеграции

Технически приём идёт через банк-участник, поэтому прямой интеграции с платформой Банка России у магазина нет: интерфейс и документацию даёт ваш банк. Возвраты уходят обратно на цифровой счёт покупателя, а не на карту, и это отдельная ветка в логике рефандов и чеков. Лимит 300 тыс. рублей в месяц касается пополнения счёта физлицом; расход ограничен только остатком на счёте.

• Узнайте у своего банка, как он подключает приём цифровых рублей и какие интерфейсы даёт; для крупнейших банков это уже сентябрь 2026 года.
• Заложите в модель данных третий тип платежа рядом с картой и СБП: у него свои статусы, свой возврат и своя сверка.
• Возвраты: средства уходят обратно на цифровой счёт покупателя; учитывайте это в логике рефандов и в чеках.
• Комиссии для бизнеса появятся с 2027 года по тарифам решения от 28 августа; не зашивайте «бесплатно» в расчёт стоимости платежей.
• Торговые точки с выручкой до 5 млн рублей, точки без интернета и, до сентября 2027 года, клиенты банков вне списка крупнейших могут не спешить: для них цифровой рубль пока добровольный.

Контекст

Пилот цифрового рубля стартовал в августе 2023 года на ограниченном круге клиентов и банков. К концу сентября 2025 года в нём было открыто больше 2,5 тыс. кошельков и проведено больше 90 тыс. операций. Массовый запуск дважды переносили. Следующая проверка — сентябрь 2027 года, когда к платформе должны подключиться все банки с универсальной лицензией, и тарифы для бизнеса, которые начнут действовать с января.

Источники: Сообщение Банка России о старте с 1 сентября, Решение Совета директоров Банка России от 28.08.2026, Страница проекта «Цифровой рубль»

Изображение на обложке: Банк России

Насколько рынок к этому готов, показал Руцентр в данных, опубликованных 1 сентября: идентификацию прошли 42,2% его администраторов и 25,7% пользователей Рег.ру (данные на конец августа). Вместе эти два регистратора контролируют около 68% российского доменного рынка. Для команды разработки это значит одно: домены продукта, записанные на бывших сотрудников или незнакомых людей, при следующем продлении могут зависнуть.

• Закон 569-ФЗ действует с 1 сентября 2026 года и распространяется на зоны .ru, .рф и .su; идентификация через ЕСИА при регистрации, продлении и изменении данных.
• Готовность по данным Руцентра на 1 сентября: 42,2% его администраторов, 25,7% у Рег.ру; ещё в начале июня через ЕСИА прошли администраторы 256 тыс. доменов в Руцентре и 456 тыс. в Рег.ру.
• Санкции для неидентифицированных пока не применяются: переходный режим до включения регистратора в специальный перечень либо до 18 января 2027 года.
• Для нерезидентов с 2 июня работает trustee-сервис Рунити; для юрлиц на момент публикации CNews идентификацию проводил Руцентр.
• По данным Руцентра, 38,5% компаний сталкивались с сайтами-имитаторами бренда, а двухфакторную аутентификацию в аккаунте регистратора используют 15–16% владельцев.

Что именно требует закон

Раньше администратор указывал свои данные в анкете регистратора, и подтверждение через государственную систему не требовалось. Теперь личность подтверждается через ЕСИА: физлица и ИП делают это в личном кабинете регистратора через вход на Госуслуги, юрлица — через подтверждённую учётную запись организации. Без идентификации нельзя будет зарегистрировать новый домен, продлить существующий или сменить его данные. Сама регистрация при этом остаётся открытой для любого.

Зарегистрировать домен сможет любой, как и раньше, добавляется обязательная идентификация через ЕСИА.

Важная деталь: ограничения для тех, кто не прошёл идентификацию, 1 сентября не включаются. Действует переходный период: до включения конкретного регистратора в специальный перечень либо до 18 января 2027 года. Точный порядок последствий для каждого неидентифицированного домена в открытых источниках не раскрыт; это главный вопрос, который стоит задать своему регистратору. Времени меньше, чем кажется: домены продлеваются раз в год, и у части владельцев дата продления попадёт уже внутрь жёсткого режима.

Почему это касается разработчиков

Домен — корень всего: DNS, TLS-сертификаты, почта, OAuth-редиректы, вебхуки. В той же публикации Руцентр приводит цифры, которые объясняют, зачем регулятор это делает: 38,5% компаний сталкивались с сайтами-имитаторами бренда, 35,9% — со сканированием инфраструктуры и попытками перехвата управления, а двухфакторную аутентификацию в аккаунтах регистраторов используют лишь 15–16%; опрос охватывал преимущественно крупный бизнес, а не всех владельцев доменов. С июня по август было отозвано 6 997 SSL-сертификатов, из них 4 677 GlobalSign. Физлица владеют 72,7% доменов в зоне .ru и 82,9% в зоне .рф.

Типичная проблема продуктовой команды выглядит так: домен когда-то зарегистрировал сотрудник на своё имя, потом уволился, доступ к аккаунту регистратора лежит в старом чате, а сам домен продлевается по автоплатежу. Раньше это работало. После окончания переходного режима регистратор при продлении попросит этого человека подтвердить личность через Госуслуги, и если его не найти, домен может зависнуть; точный порядок последствий пока не утверждён.

Что проверить сегодня

• Составьте список доменов продукта с датами продления и посмотрите в WHOIS или личном кабинете, кто указан администратором: физлицо, ИП или юрлицо.
• Домены на сотрудников переоформите на юрлицо через процедуру передачи у регистратора; сделать это сейчас проще, чем после блокировки.
• Убедитесь, что у администратора-юрлица есть подтверждённая учётная запись организации на Госуслугах и доступ к ней не у одного человека.
• Включите двухфакторную аутентификацию в аккаунте регистратора и переведите вход на корпоративную почту.
• Если домены записаны на иностранное лицо или компанию, уточните у регистратора условия trustee-сервиса: с 2 июня такой есть у Рунити.
• Домены в .com, .io, .dev и других международных зонах закон не затрагивает, но защиты от «увольнения владельца» они тоже не дают, так что инвентаризация полезна всем.

Что дальше

Ключевая дата — 18 января 2027 года, конец переходного периода для регистраторов, не попавших в перечень раньше. До этого момента регистраторы будут догонять показатели готовности рассылками и напоминаниями. Порядок последствий для неидентифицированного домена в открытых источниках пока не раскрыт; редакция будет следить за разъяснениями Координационного центра доменов .RU/.РФ.

Источники: Руцентр: готовность администраторов к идентификации (CNews, 1 сентября 2026), Рунити запустила сервис для нерезидентов (CNews, 2 июня 2026), Федеральный закон от 29.12.2025 № 569-ФЗ

Изображение на обложке: скриншот esia.gosuslugi.ru

• ИИ-агент JadePuffer использовал CVE-2025-3248 в Langflow для первичного доступа.
• Агент адаптировался в реальном времени: после неудачного входа нашёл рабочее решение за 31 секунду.
• Зашифрованы 1342 конфигурации Nacos; платить выкуп бесполезно, так как схемы базы данных уничтожены.
• Защита: убрать Langflow и Nacos из интернета, сменить стандартные ключи и не хранить API-ключи на оркестраторах ИИ.

Как развивалась атака

Sysdig назвала угрозу JadePuffer. Агент начал с открытого в интернете экземпляра Langflow — фреймворка для построения конвейеров ИИ, и воспользовался уязвимостью CVE-2025-3248, которая позволяет удалённо выполнить произвольный Python-код без аутентификации.

Попав внутрь, агент собирал секреты: ключи провайдеров ИИ, облачные учётные данные, кошельки криптовалют и пароли к базам данных. Особое внимание он уделял китайским облакам — Alibaba, Aliyun, Tencent и Huawei, — но не обходил стороной AWS, Azure и Google Cloud. Для закрепления агент добавил задачу в crontab, которая каждые 30 минут связывалась с инфраструктурой злоумышленников.

Конечной целью стал отдельный продакшен-сервер с MySQL и сервисом конфигураций Nacos от Alibaba. Агент подключился к MySQL под root, использовал обход авторизации CVE-2021-29441 и подделал JWT с помощью стандартного ключа Nacos. В итоге он зашифровал все 1342 конфигурации встроенной функцией AES и оставил записку с требованием выкупа, биткоин-адресом и почтой Proton Mail.

Почему платить не имеет смысла

Классический ransomware обычно хранит ключи или резервные копии, чтобы расшифровать данные после оплаты. JadePuffer действовал иначе: он уничтожал целые схемы базы данных, не сохраняя возможности восстановления. По словам директора по исследованию угроз Sysdig Майкла Кларка, агент «переходил от удаления строк к сбросу целых схем БД, проговаривая собственную логику выбора целей».

Как защититься

1. Закройте от интернета конечные точки Langflow и Nacos — они не должны быть публично доступны.
2. Обновите Langflow до версии без CVE-2025-3248.
3. Смените стандартный token.secret.key в Nacos и используйте принудительную настройку собственного ключа.
4. Не храните API-ключи провайдеров ИИ и облачные учётные данные в окружении оркестраторов ИИ.

Атака JadePuffer показывает, что порог входа для ransomware опустился до стоимости запуска ИИ-агента. Если агент работает на украденных учётных данных через LLMjacking, затраты злоумышленника близки к нулю. Источник: The Register.

• Виртуальный хостинг — сайты соседствуют на одном сервере, управляет провайдер. Дешёвый старт, но ограниченная конфигурация.
• VPS и VDS — почти всегда синонимы: изолированные виртуальные серверы с root-доступом и гарантированными ресурсами.
• Выделенный сервер — отдельное железо, максимум контроля и цены, требует администрирования.
• В подборке: Интернет Хостинг Центр, UFO.Hosting, SpaceWeb, PSB Hosting, AdminVPS и FirstVDS.

Как мы выбирали участников

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

1. Интернет Хостинг Центр — гибкие конфигурации

Российский провайдер, у которого VPS и VDS — это одна услуга. Можно выбрать виртуализацию под задачу (KVM или Virtuozzo), собрать конфигурацию от минимальной до высоконагруженной и расти внутри одной платформы до выделенного сервера.

Кейсы клиентов и кому подойдёт

• Небольшой сайт компании на WordPress с 300–500 посетителей в сутки спокойно живёт на виртуальном хостинге; при росте трафика переходят на VPS.
• Интернет-магазин на 1С-Битрикс с 500–1000 пользователями в день переносят на VPS/VDS, когда подключают CRM и платёжные системы.
• Разработчик с несколькими проектами берёт VPS/VDS под API, базу данных и тестовые окружения — виртуальный хостинг здесь слишком ограничен.

Что можно развернуть

На виртуальном хостинге — сайты на PHP 5.2–8.2 с MySQL, панели IHC, cPanel или ISPmanager. На VPS/VDS — любые Linux-дистрибутивы, Windows, WireGuard, MikroTik Router, панели ispmanager/FastPanel, VPN-шаблоны, CMS вроде 1С-Битрикс.

Инфраструктура и экосистема

Дата-центры Tier III в Москве (DataPRO и IXcellerate Moscow One) и в Амстердаме. Виртуализация — KVM или Virtuozzo. Защита от DDoS входит во все тарифы, IPv6-сети /64 доступны за доплату. Есть партнёрская программа с выплатами до 50% от привлечённых оплат.

Отзывы и репутация

На сайте публикуются отзывы с внешних площадок: средняя оценка 4,8 по 20 оценкам. Клиенты отмечают стабильную работу и скорость техподдержки.

Поддержка и каналы связи

Тикеты через личный кабинет, онлайн-чат на сайте, Telegram @IHC_Support_Bot, телефоны в Москве, Санкт-Петербурге и бесплатный номер для регионов. Первый ответ обычно приходит за 10–30 минут в рабочее время. Для корпоративных клиентов доступно сопровождение через отдел продаж и аккаунт-менеджеров.

Тарифы, ограничения и условия

• Виртуальный хостинг: тариф IHC-2 — от 123 ₽/мес при оплате за год или 147 ₽/мес помесячно; 2 сайта, 2 ГБ SSD, 150 МБ под БД, домен .RU в подарок при оплате за 2 года.
• VPS/VDS: минимальная конфигурация ssdVPS:1 — 1 ГБ RAM, 20 ГБ SSD, 1 CPU, безлимитный трафик со снижением скорости после 20 ТБ — от 317 ₽/мес за год или 380 ₽/мес помесячно.
• Типовая конфигурация для небольшого проекта — 2 ГБ RAM, 1–2 CPU, 30–45 ГБ NVMe — от 609 ₽/мес за год или 700 ₽/мес помесячно.
• Тестовый период: 7 дней на виртуальном хостинге, 3 дня на VPS/VDS; для активации нужно пополнить баланс на 100 ₽, которые можно вернуть или потратить.
• Бэкапы: место под резервные копии — от 52,5 ₽/мес за 5 ГБ; снапшоты зависят от платформы.
• Работа по 152-ФЗ, есть реестр хостинг-провайдеров; закрывающие документы для юрлиц доступны.

Официальный сайт: ihc.ru

2. UFO.Hosting — космическая экосистема

Провайдер, который объединяет VPS/VDS, выделенные серверы, защиту сайтов, DNS-хостинг, аренду IP, лицензии ISPmanager и домены в одном личном кабинете. Для UFO.Hosting VPS и VDS — два названия одной услуги; разница только в терминологии.

Кейсы клиентов и кому подойдёт

• Интернет-магазин с трафиком 10–50 тыс. посетителей в день — VPS даёт стабильность при пиковых нагрузках и возможность настроить SSL, СУБД и кэширование.
• Веб-студии и агентства выбирают VPS/VDS ради изоляции ресурсов: проблемы одного клиента не влияют на соседние проекты.
• CRM-системы, лендинги с формами заявок и приложения с умеренной нагрузкой — удобно масштабировать RAM и CPU без переплаты за железо.
• Выделенные серверы берут под крупный e-commerce с интенсивным чтением/записью, проекты с жёсткими требованиями к безопасности и задачи с огромными объёмами дисков.

Что можно развернуть

VPS/VDS на Linux и Windows, панели Vesta, Hestia, CyberPanel, Virtualmin, ISPmanager. Можно поднять веб-серверы, базы данных, VPN, контейнеры, игровые серверы, DNS-зоны, а рядом заказать защиту сайта от DDoS L7 и внешнее FTP-хранилище.

Инфраструктура и экосистема

Серверы стоят в дата-центре IXcellerate в Москве, соответствующем Tier III. Сеть ноды VPS/VDS — 10 Гбит/с, распределяется между серверами по тарифу. Доступны обычные конфигурации на Intel Xeon, Hi-CPU на Ryzen и Storage-линейка с расширенным хранилищем.

Отзывы и репутация

Публичных агрегированных рейтингов в предоставленных источниках не указано. Провайдер позиционируется как экосистемный игрок с акцентом на удобное управление всеми услугами из одного кабинета.

Поддержка и каналы связи

Техподдержка 24/7 через онлайн-чат на сайте и тикет-систему в биллинге. Телефонная поддержка работает в будни с 9:00 до 18:00; Telegram не используется. Фактическое время ответа — не более 30 минут в любое время суток. Есть база знаний и блог.

Тарифы, ограничения и условия

• Минимальная конфигурация VPS/VDS Naos (Intel Xeon E5-2697A v4) — 1 vCore, 1 ГБ RAM, 25 ГБ NVMe — 605,85 ₽/мес.
• Типовая конфигурация Brachium (Intel Xeon E5-2697A v4) — 2 vCore, 4 ГБ RAM, 60 ГБ NVMe — 1025,85 ₽/мес.
• Скидки за предоплату: 3 месяца — 5%, 6 месяцев — 10%, 12 месяцев — 15%.
• Тестовый период — до 3 дней на любой тариф VPS; требуется верификация аккаунта (email, телефон, KYC). На выделенные серверы — до 3 дней по договорённости.
• Трафик безлимитный с порогом 32 ТБ/мес; после превышения скорость ограничивается 100 Мбит/с.
• Root-доступ полный. На тарифах Naos и Haedus выбор ОС ограничен списком провайдера; на остальных можно ставить любую ОС.
• Бэкапы платные: ежедневные — 525 ₽/мес, еженедельные — 262,5 ₽/мес; снапшотов нет, есть услуга бэкапов.
• Работа по 152-ФЗ, сертификатов ФСТЭК нет; есть реестр хостинг-провайдеров. Для юрлиц — договор и ЭДО, постоплата недоступна.

Официальный сайт: ufo.hosting

3. SpaceWeb — посуточная тарификация

Один из старейших российских хостеров, у которого можно начать с виртуального хостинга, перейти на VPS/VDS с посуточной оплатой и докупать IP, SSL и защиту от DDoS. Удобен тем, кто хочет платить только за фактическое потребление ресурсов VPS.

Кейсы клиентов и кому подойдёт

• Лендинг, блог или сайт-визитка с небольшой посещаемостью — хватит виртуального хостинга с автоустановкой CMS.
• Интернет-магазин и корпоративный сайт на 1С-Битрикс — тарифы повышенной мощности с выделенными CPU и приоритетной поддержкой.
• Проект с непредсказуемой нагрузкой — VPS/VDS с посуточной тарификацией и изменением ресурсов «на лету».

Что можно развернуть

На хостинге — WordPress, Joomla, Drupal, 1С-Битрикс, OpenCart, MODx, Laravel, Django и другие CMS и фреймворки. Поддерживаются PHP 5.x–8.4, MySQL 8/5.7, PostgreSQL 14.4, Perl, Python, Ruby. На VPS/VDS — Ubuntu, Debian, CentOS, AlmaLinux, Rocky Linux, панели Hestia, FASTPANEL, ISPmanager, Docker.

Инфраструктура и экосистема

Дата-центры Tier III в Санкт-Петербурге, Москве и Амстердаме. Собственная SPA-панель управления, VNC-консоль, DNS-редактор, статистика, логи, бэкапы и снапшоты. На всех сайтах включена изоляция для защиты от вредоносного ПО и защита от DDoS L3-4; защиту L7 можно докупить от 290 ₽/мес.

Отзывы и репутация

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

Поддержка и каналы связи

Email, телефон, онлайн-чат и ВКонтакте. Среднее время ответа: 1–2 минуты по телефону, в чате и ВКонтакте; до 60 минут по почте. Поддержка помогает с переносом проектов, диагностикой и администрированием серверов с ISPmanager.

Тарифы, ограничения и условия

• Виртуальный хостинг: тариф «Старт» — 1 ГБ NVMe SSD, 1 база данных, ∞ FTP и почтовых ящиков, 120 CP — 149 ₽/мес; «Взлёт» — 311 ₽/мес, «Ракета» — 530 ₽/мес, «Космос» — 755 ₽/мес.
• VPS/VDS: посуточная тарификация, параметры CPU/RAM/диска меняются «на лету»; конкретную стоимость конфигурации проверяйте в калькуляторе на сайте.
• Тестовый период: 14 дней на виртуальном хостинге и на VPS/VDS.
• Ежедневное резервное копирование включено на хостинге; резервные копии VPS — от 45 ₽/мес за 3 копии.
• Дополнительный IP — 130 ₽/мес, SSL GlobalSign — от 1 900 ₽/год, домен .RU — 179 ₽/год.
• Работа с юрлицами через договор оферты, безналичные платежи и ЭДО.

Официальный сайт: spaceweb.ru

4. PSB Hosting — зарубежные локации

Провайдер с фокусом на VPS в Европе и США: Amsterdam, Frankfurt, Helsinki, New York. Не предлагает виртуальный хостинг в привычном понимании, зато даёт полный root, /64 IPv6 на всех тарифах, неограниченные резервные копии и оплату криптовалютой.

Кейсы клиентов и кому подойдёт

• Небольшие интернет-магазины на WordPress или 1С-Битрикс, лендинги, корпоративные сайты и блоги.
• Проекты с Telegram-ботами, API-сервисами и другой автоматизацией.
• Команды, которым важны зарубежные локации и гибкие способы оплаты, включая криптовалюту.

Что можно развернуть

VPS под Linux, Windows или FreeBSD с предустановленным ПО: Bitrix, Django, Docker, FastPanel, HestiaCP, Keitaro, LAMP, Node, OpenVPN, Outline, Portainer, VestaCP, WireGuard, WordPress. Подходит под сайты, backend-приложения, VPN, корпоративные системы, базы данных и тестовые среды.

Инфраструктура и экосистема

Серверы размещены в дата-центрах euNetworks (Amsterdam), Frankfurt 1 Data Center, Digita (Helsinki) и Long Island Interconnect (New York). Оборудование — AMD и Intel с DDR5 и NVMe, RAID 10. Безлимитный трафик, порт ноды 10 Гбит/с, на VPS выделяется 300 Мбит/с. Полноценная панель управления DNS-записями доменов.

Отзывы и репутация

На сайте указаны рейтинги на независимых площадках: OtzovikMarketing.ru — 4,8, In-Scale.ru — 5,0, Aff1.ru — 5,0, 101Poisk.ru — 4,89. Провайдер позиционируется как решение для бизнеса, разработки и высоконагруженных проектов.

Поддержка и каналы связи

Поддержка работает круглосуточно через тикеты и Telegram; время ответа зависит от загрузки. Есть документация и API. Для B2B-клиентов предусмотрен менеджер.

Тарифы, ограничения и условия

• VPS: минимальный тариф на странице VPS — от 8 USD; есть High-CPU VPS на AMD Ryzen 7950X.
• Почасовая оплата доступна; скидки за предоплату: 3 месяца — 5%, 6 месяцев — 10%, 12 месяцев — 15%.
• Бесплатного тестового периода нет.
• Безлимитный трафик, порт VPS — 300 Мбит/с; можно установить любую ОС; полный root-доступ.
• Бэкапы платные, снапшоты есть.
• IPv6-подсеть /64 на всех тарифах, неограниченное количество резервных копий.
• Не работает по 152-ФЗ, сертификатов ФСТЭК нет, в реестре отечественного ПО нет. Оплата картами РФ/СНГ/ЕС и криптовалютой.

Официальный сайт: psb.hosting

5. AdminVPS — VPS и хостинг в одном кабинете

Провайдер с виртуальным хостингом, VPS/VDS, выделенными серверами, доменами, SSL и дополнительными сервисами в одном аккаунте. В подборке он закрывает сценарий, когда проекту нужен обычный хостинг для сайта и отдельный VPS под приложение, базу данных или тестовую среду.

Кейсы клиентов и кому подойдёт

• Сайты на CMS и небольшие магазины, которые начинают с виртуального хостинга и постепенно переходят на VPS.
• Команды, которым нужны домены, SSL, хостинг и серверы в одном личном кабинете.
• Проекты, где важна российская площадка и возможность подобрать конфигурацию VPS под нагрузку.

Что можно развернуть

На виртуальном хостинге — сайты на популярных CMS и почту на домене. На VPS/VDS — Linux-серверы под сайты, backend, базы данных, тестовые окружения и сервисы с root-доступом. В экосистеме также есть домены, SSL-сертификаты, резервное хранилище, объектное хранилище и защита от DDoS.

Инфраструктура и экосистема

На странице VPS в России указано размещение в Москве, процессоры Intel Xeon Gold и AMD EPYC, NVMe-диски, тарифы с портом от 100 Мбит/с до 1 Гбит/с и включённым месячным трафиком. В меню также есть VPS в Германии, Нидерландах, Польше, Испании, Беларуси, Казахстане, Финляндии, Великобритании и Франции.

Отзывы и репутация

На странице VPS указана агрегированная оценка 4,9 и несколько сотен отзывов. Провайдер позиционируется как универсальная площадка для сайтов, серверов и сопутствующих услуг.

Поддержка и каналы связи

Поддержка работает круглосуточно через тикет-систему в личном кабинете. Отдел продаж доступен по телефону и через запрос на сайте.

Тарифы, ограничения и условия

• VPS/VDS в России: конфигуратор стартует от 500 ₽/мес; в готовых тарифах есть Lite с 1 CPU, 1 ГБ RAM и 15 ГБ NVMe.
• Виртуальный хостинг и CMS-хостинг доступны отдельными услугами.
• В тарифах VPS указаны месячные пакеты трафика; на младшем Lite — 1 ТБ и порт 100 Мбит/с.
• Бэкапы зависят от тарифа: для части тарифов платно, для части включены.
• Есть скидки за предоплату на 6, 12 и 24 месяца.
• На странице указано соответствие требованиям РФ по 152-ФЗ.

Официальный сайт: adminvps.ru

6. FirstVDS — готовые VDS/VPS-конфигурации

Провайдер с фокусом на виртуальные серверы: готовые VDS/VPS, отдельные линейки для высоких CPU-частот, storage-сценариев, GPU и Windows. В подборке это вариант для тех, кто выбирает именно VPS/VDS и сопутствующие услуги, а не классический shared-хостинг.

Кейсы клиентов и кому подойдёт

• Небольшие сайты и сервисы, которым нужен отдельный сервер вместо виртуального хостинга.
• Разработчики, которым важны готовые Linux-образы, SSH-доступ и быстрый запуск сервера.
• Проекты, где позже могут понадобиться Windows-серверы, storage-линейка или зарубежная локация.

Что можно развернуть

На VPS/VDS доступны Linux-дистрибутивы Debian, Ubuntu, FreeBSD, CentOS и Alma, платная Windows, панели ispmanager и дополнительные IP. В линейке есть VDS для Windows, VDS в Нидерландах и Алматы, storage-серверы, GPU-серверы и объектное хранилище S3.

Инфраструктура и экосистема

На сайте указаны дата-центры в России, Нидерландах и Казахстане. Для VDS в Москве доступны каналы до 100 Мбит/с с безлимитным трафиком или до 1 Гбит/с с пакетом 32 ТБ в месяц; для Амстердама и Казахстана условия отличаются.

Отзывы и репутация

FirstVDS работает как отдельный бренд виртуальных серверов и указывает награды отраслевой премии ЦОДы.рф. На сайте также опубликованы пользовательские отзывы и раздел базы знаний.

Поддержка и каналы связи

На сайте указан бесплатный круглосуточный телефон 8 800 775-38-37, база знаний и служба поддержки. Для серверов доступны дополнительные услуги администрирования и технического сопровождения.

Тарифы, ограничения и условия

• Готовые VDS/VPS — от 249 ₽/мес; запуск сервера заявлен за несколько минут.
• Бесплатно с сервером: 1 выделенный IP-адрес, ispmanager 6 lite на 1 месяц, установка ОС на выбор и полный SSH-доступ.
• Тестовый период предоставляется по согласованию.
• Windows тарифицируется отдельно: на странице указано 680 ₽/мес за 1 ядро, недоступно для VDS в Амстердаме и Алматы.
• Для VDS в Москве возможен канал до 100 Мбит/с с безлимитным трафиком или до 1 Гбит/с с лимитом 32 ТБ/мес.
• Дополнительные услуги: бэкап, мониторинг, BitNinja, DDoS-защита, домены, SSL и DNS-хостинг.

Официальный сайт: firstvds.ru

Сравнение по ключевым критериям

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

• Минимальный виртуальный хостинг: ИХЦ — от 123 ₽/мес (при оплате за год), SpaceWeb — от 149 ₽/мес; AdminVPS предлагает виртуальный/CMS-хостинг отдельной линейкой; UFO.Hosting, PSB Hosting и FirstVDS в подборке рассматриваются прежде всего как VPS/VDS-провайдеры.
• Минимальный VPS/VDS: ИХЦ — от 317 ₽/мес (за год), UFO.Hosting — 605,85 ₽/мес, SpaceWeb — цена в калькуляторе с посуточной тарификацией, PSB Hosting — от 8 USD, AdminVPS — от 500 ₽/мес в конфигураторе, FirstVDS — от 249 ₽/мес.
• Виртуализация: ИХЦ — KVM/Virtuozzo на выбор; UFO.Hosting — Intel Xeon и Ryzen линейки; SpaceWeb — собственная облачная платформа; PSB Hosting — KVM; AdminVPS и FirstVDS предлагают готовые VPS/VDS-линейки с Linux-образами.
• Трафик: ИХЦ и PSB Hosting — безлимитный (у ИХЦ снижение скорости после 20 ТБ); UFO.Hosting — безлимитный с порогом 32 ТБ; SpaceWeb — параметры уточняйте в конфигураторе; AdminVPS указывает месячные пакеты трафика; FirstVDS разделяет безлимитный канал 100 Мбит/с и пакеты трафика на более быстрых каналах.
• Root и ОС: полный root у всех шести; ИХЦ и PSB Hosting позволяют загружать собственные ISO; UFO.Hosting ограничивает список ОС на младших тарифах; у FirstVDS Windows и панели управления идут как платные дополнения.
• Бэкапы: SpaceWeb включает ежедневные бэкапы на хостинге; ИХЦ и PSB Hosting — платно; UFO.Hosting — платная услуга резервного копирования; AdminVPS и FirstVDS предлагают бэкапы как тарифную или дополнительную опцию.
• Тестовый период: SpaceWeb — 14 дней на хостинге и VPS; ИХЦ — 7 дней хостинг / 3 дня VPS; UFO.Hosting — до 3 дней VPS; FirstVDS — по согласованию; PSB Hosting — нет; условия AdminVPS зависят от акции и выбранной услуги.
• Дата-центры: ИХЦ — Москва + Амстердам; UFO.Hosting — Москва; SpaceWeb — Москва, Санкт-Петербург, Амстердам; PSB Hosting — Amsterdam, Frankfurt, Helsinki, New York; AdminVPS предлагает VPS в разных странах; FirstVDS указывает Россию, Нидерланды и Казахстан.
• Юридика: ИХЦ, UFO.Hosting, SpaceWeb и AdminVPS работают с российской юридической рамкой; PSB Hosting ориентирован на зарубежные локации; для FirstVDS условия документов и лицензий зависят от выбранных услуг.

Вывод

Виртуальный хостинг остаётся самым простым стартом для сайта-визитки, блога или небольшого магазина: не нужно администрировать сервер, всё настроено провайдером. VPS/VDS стоит брать, когда проекту нужна изоляция, root-доступ, нестандартное ПО или рост нагрузки. Выделенный сервер — следующий шаг, когда виртуализация уже не тянет задачу.

Если приоритет — российская юридика и плавный рост от хостинга до железа, смотрите на Интернет Хостинг Центр или SpaceWeb. Если важна экосистема из доменов, защиты и серверов в одном кабинете — UFO.Hosting или AdminVPS. Если нужен недорогой вход именно в VPS/VDS — можно сравнить FirstVDS с базовыми тарифами других участников. Если нужны зарубежные локации и гибкая оплата — PSB Hosting. Перед покупкой всегда берите тестовый период и проверяйте реальную производительность под вашей нагрузкой.

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

Так появляется классическая ловушка legacy: систему надо модернизировать, но остановить развитие нельзя. Переписать всё с нуля страшно, поддерживать как есть — всё дороже. В результате продукт обрастает временными решениями, скорость разработки падает, а стоимость каждого следующего изменения растет.

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

Почему Big Bang-переписывание чаще всего заканчивается плохо

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

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

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

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

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

Big Bang всё-таки бывает оправдан — но в узких условиях. Если кодовая база молодая (год-два), пользователей мало, у системы нет критичного состояния в БД и продукт можно временно заморозить или вести в обоих контурах параллельно, полное переписывание может оказаться дешевле постепенной миграции. Это редкая ситуация, и она быстро исчезает по мере роста продукта. В зрелых системах безопаснее работает другой подход — постепенная архитектурная эволюция.

Пример: как команда переписала сервис документов и потеряла полгода

Команда сопровождала сервис — старый модуль на aiohttp с Pydantic v1, через который проходила вся обработка путевых листов и актов осмотра транспорта. Сервис существовал шесть лет, был покрыт тестами фрагментарно, а его API использовали мобильное приложение водителей, диспетчерская веб-панель и пакетный импорт.

Команда решила переписать сервис целиком: перейти на FastAPI, обновить Pydantic до v2, заодно почистить контракты и заменить внутреннее хранилище документов с MongoDB на PostgreSQL. План был рассчитан на четыре месяца.

Через восемь месяцев проект всё ещё не был готов к выкатке, а к десятому месяцу команда откатила миграцию полностью. Причин было несколько.

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

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

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

В-четвёртых, переключение было сделано «в лоб»: маршрут в API Gateway просто перенаправили на новый сервис. Фича-флага не было, теневого запуска не было, плана отката не было. Когда выяснилось, что новый сервис строже валидирует исторические форматы документов и отклоняет часть старых записей, быстро вернуться на старую реализацию не получилось — её к тому моменту уже отключили на стенде, а в БД успели уйти записи в новом формате.

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

Strangler Fig Pattern: как заменить систему по частям

Один из самых практичных подходов к модернизации legacy-кода — Strangler Fig Pattern. В софтверном виде паттерн был сформулирован Мартином Фаулером в 2004 году под названием StranglerFigApplication. Идея проста: не переписывать систему целиком, а постепенно выносить отдельные части в новую реализацию.

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

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

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

Strangler Fig хорошо работает там, где между старым и новым кодом есть сетевая граница: HTTP, message bus, RPC. Если такой границы нет — например, нужно постепенно заменить функцию или класс внутри одного процесса — используется родственный паттерн Branch by Abstraction: над старой реализацией создается абстракция, рядом пишется новая реализация, переключение происходит через конфигурацию или фича-флаг, после стабилизации старая ветка удаляется. Снаружи это выглядит как Strangler Fig, но без сетевого прокси.

Такой подход снижает риск. В системе нет одного большого релиза, где всё меняется сразу. Есть серия небольших контролируемых изменений. Каждое можно протестировать, измерить и откатить.

Главное правило: сначала повторить поведение, потом улучшать

Одна из частых ошибок при модернизации legacy-кода — попытка одновременно переписать систему и улучшить бизнес-логику. Команда смотрит на старый модуль и думает: «Раз уж мы его трогаем, давайте сразу сделаем нормальную архитектуру, изменим контракты, уберем странные кейсы и перепишем поведение».

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

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

Прежде чем менять поведение, его нужно зафиксировать. Для этого пишут характеристические тесты (characterization tests, иногда называемые golden master или approval tests). Идея простая: на реальных данных или их обезличенных копиях прогоняется старая реализация, её ответы сохраняются как эталон, и любые будущие изменения, отклоняющиеся от эталона, отлавливаются автоматически. Тесты пишутся не для красоты, а для того, чтобы зафиксировать существующее поведение — даже странное — перед тем, как его трогать. Подробно эта техника описана у Майкла Физерса в книге Working Effectively with Legacy Code; на практике её удобно реализовать через библиотеки семейства approval-tests (approvaltests-python, approvaltests-java и аналоги).

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

Feature toggles: как включать новую логику без риска

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

В обычной разработке релиз часто выглядит бинарно: код либо выкатили, либо нет. При миграции legacy это неудобно. Гораздо безопаснее иметь возможность включить новую реализацию для 1% пользователей, затем для 10%, потом для половины аудитории и только после этого для всех.

Например, команда переносит расчет стоимости доставки из монолита в новый сервис. С помощью фича-флага это выглядит так:

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

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

Важно различать два разных типа флагов. Флаг постепенной выкатки (rollout flag) меняется редко и контролирует, какой процент пользователей видит новую логику. Kill switch — отдельный флаг, единственная задача которого — мгновенно выключить новую реализацию при инциденте. Kill switch должен опрашиваться на каждом запросе, его кэширование должно жить секунды, а не минуты, и он принципиально не должен зависеть от той системы, которую он выключает. Иначе в момент аварии может оказаться, что выключатель сам недоступен.

В качестве инфраструктуры для флагов команды обычно берут одну из платформ: LaunchDarkly, Unleash, Flagsmith, GrowthBook, либо собирают собственную поверх Redis или конфигурационного сервиса. Для миграции важны три свойства: быстрое распространение изменений (секунды, а не минуты), поддержка таргетинга по пользователю/сегменту и аудит — кто и когда менял флаг.

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

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

Shadow testing: как проверить новую систему на реальном трафике

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

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

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

Два момента, на которые стоит обратить внимание в этом коде. Теневой вызов запускается через asyncio.create_task — корутина сразу планируется в event loop и начнёт выполняться, как только функция вернёт управление. И весь блок завернут в try/except: исключение в новой логике не должно ронять основной запрос. Без этих двух свойств shadow testing рискует ухудшить продакшен вместо того, чтобы безопасно его проверить.

Небольшая оговорка для продакшена: event loop держит на task только слабую ссылку, и без сохранённой ссылки задача может быть собрана сборщиком мусора прямо во время выполнения. В реальном коде Task имеет смысл класть в set фоновых задач и удалять оттуда через add_done_callback. В примере выше эта обвязка опущена для читаемости.

Для критичной доменной логики — платежей, биллинга, расчета тарифов — допустимый уровень расхождения должен быть около нуля: цель в shadow-режиме не «как можно меньше различий», а «понимаем каждое расхождение». Для менее чувствительных доменов (рекомендации, ранжирование результатов поиска) можно жить с расхождением в долях процента, но и там расхождения нужно классифицировать, а не игнорировать. Возможно, это баги новой реализации. А возможно, старая система содержит устаревшую логику, которую нужно отдельно обсудить с бизнесом.

Shadow testing особенно полезен для критичных доменных частей: платежей, биллинга, расчета тарифов, персональных предложений, транзакций. Там нельзя просто «попробовать на пользователях» и посмотреть, что будет.

При этом важно отличать теневую проверку чтения от теневой проверки записи. Чтение проверить относительно дёшево: запрос идёт в обе системы, ответы сравниваются, никаких внешних эффектов нет. С записью всё сложнее. Если новая реализация в shadow-режиме действительно создаст заказ, спишет деньги или отправит письмо, у пользователя возникнут двойные эффекты. Поэтому для writes либо вводят идемпотентные ключи и shadow-режим без реальных побочных действий (внешние вызовы заменены no-op-стабами, БД — отдельной shadow-копией), либо вообще отказываются от теневой проверки записи в пользу постепенной выкатки за фича-флагом.

Сравнение ответов в реальной системе тоже не сводится к одной функции compare. Нужно отдельно решать, как игнорировать «нормальный» шум (метки времени, идентификаторы, порядок коллекций), как сэмплировать трафик, чтобы не утопить хранилище расхождений, и как организовать триаж — кто и в каком ритме разбирает накопившиеся диффы. Готовые решения этого класса — GitHub Scientist (Ruby и его порты в другие языки), Twitter Diffy, либо собственный лёгкий регистратор поверх Kafka и таблицы расхождений.

С чего начинать модернизацию

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

Удобный способ выбрать первый кусок — оценить кандидатов по двум осям: насколько модуль критичен для бизнеса (low / high) и насколько сильно он связан с остальной системой (low / high). Начинать стоит с квадранта low-criticality + low-coupling: ошибки в нем не уронят бизнес-показатели, а малое количество зависимостей позволит провести миграцию полностью, не утянув за собой смежные модули. Высоко-критичные и сильно связанные части (платежи, ядро авторизации) трогают в последнюю очередь — на этот момент команда уже наберёт опыт безопасной миграции.

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

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

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

Миграция данных: самая сложная часть

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

Базовый рабочий приём — Expand-Contract (он же Parallel Change). Изменение схемы делается в три такта. На этапе expand в БД добавляются новые поля, таблицы или индексы, при этом старое поведение полностью сохраняется. Затем — migrate: обе реализации начинают писать и в старое, и в новое место (dual writes), а отдельный фоновый процесс делает backfill — заполняет новые поля историческими данными. После этого читатели по одному переключаются на новую схему. Только когда никто из читателей не использует старую структуру, наступает contract — удаление лишних колонок и таблиц.

Несколько практических деталей, которые часто упускают:

· Dual writes — это не бесплатная операция. Две записи означают две точки отказа. Если одна из них упала, нужно решать, что делать: продолжать ли работу, ставить ли событие в очередь на повтор, помечать ли запись как несогласованную. Простое «сначала пишем туда, потом сюда» в продакшене на нагрузке приводит к расхождениям.

· Backfill часто длиннее, чем кажется. На большой таблице миграция в одном UPDATE блокирует продакшен. Поэтому backfill делают батчами по N тысяч строк с паузами, отслеживают прогресс и предусматривают возможность остановить и продолжить.

· Онлайн-изменения схемы на крупных таблицах делаются не штатным ALTER TABLE, а специализированными инструментами: gh-ost или pt-online-schema-change для MySQL, встроенные онлайн-механизмы PostgreSQL для индексов и колонок, Liquibase/Flyway — для управления версионированием изменений в репозитории.

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

Без этих шагов любая красивая фасадная архитектура наталкивается на разъезжающиеся данные — и тогда даже идеальный Strangler Fig снаружи не спасает.

Прокси-слой как точка контроля

Чтобы постепенно заменять legacy-код, нужно управлять маршрутизацией запросов. Для этого часто создают прокси-слой, API Gateway или фасад, через который проходит обращение к старой и новой логике. В терминах Domain-Driven Design такой слой часто называют Anti-Corruption Layer: он защищает новую реализацию от старых контрактов и наоборот, позволяя двум моделям сосуществовать без взаимного «загрязнения».

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

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

В качестве технической основы команды обычно берут один из трех вариантов: классический API gateway (Kong, AWS API Gateway), service mesh (Envoy, Istio) или более простой reverse proxy (NGINX, HAProxy). Service mesh особенно удобен, когда трафик уже идёт внутри Kubernetes-кластера: маршрутизацию можно менять конфигурацией, без правок кода клиентов и сервисов.

Например, мобильное приложение обращается к endpoint /orders/history. Раньше этот endpoint напрямую обслуживал монолит. После введения API Gateway приложение продолжает ходить по тому же контракту, но внутри gateway может решать, куда направить запрос: в legacy-модуль или новый сервис истории заказов.

Управление маршрутизацией обычно делается не «всё или ничего», а на основании атрибутов запроса: значения заголовка (X-Migration-Cohort: new), куки, хэша от user-id (стабильное разбиение пользователей на сегменты) или географического региона. Это позволяет выкатывать новую реализацию сначала на одну страну, на сотрудников самой компании или на тестовый сегмент — и только потом расширять охват.

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

Наблюдаемость: без метрик миграция превращается в гадание

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

Минимальный набор — это логи, метрики и распределенная трассировка (distributed tracing). Нужно понимать, сколько запросов идет в старую и новую реализацию, сколько ошибок возникает, как меняется latency, где появляются таймауты, какие статусы возвращаются, какие бизнес-метрики проседают.

Технические метрики стоит формулировать не как «средний ответ» и «процент ошибок», а в терминах SLI и SLO: целевые показатели вида «99.9% запросов на /orders/history отвечают быстрее 300 ms за 30 дней» с явным error budget. Latency измеряется по перцентилям (p50, p95, p99) — среднее значение почти всегда обманчиво, а хвосты распределения говорят о реальном опыте пользователя. На время миграции имеет смысл выставить отдельные SLO для нового и старого пути и сравнивать их.

В качестве инструментов де-факто стандартом стал OpenTelemetry для трассировок, метрик и логов — единый протокол, который пишет в практически любое хранилище. Дальше — Prometheus и Grafana для метрик, Jaeger или Tempo для traces, Sentry или аналог для ошибок. Для миграции важна возможность фильтровать метрики по «варианту» — отдельно по старому и новому пути — иначе все цифры смешаются и реальную динамику будет не видно.

Технических метрик недостаточно. Если команда переносит оформление заказа, важно смотреть не только на 500 ошибки и время ответа, но и на конверсию в оплату, количество брошенных корзин, повторы запросов, обращения в поддержку.

Пример: новая система формально отвечает быстрее старой и не дает ошибок. Но после включения на 10% пользователей падает конверсия в оплату. Причина может быть не в серверной ошибке, а в изменении порядка полей, другом тексте сообщения или потере какого-то edge-case. Без бизнес-метрик команда может решить, что миграция успешна, хотя для продукта она уже создает проблему.

Практическая последовательность миграции

Рабочая последовательность обычно выглядит так.

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

Затем поверх legacy-логики создается стабильный контракт. Это может быть API, фасад, gateway или отдельный слой внутри приложения. Главная задача — сделать так, чтобы клиенты зависели не от внутренней реализации, а от понятного интерфейса. На этом этапе полезно вспомнить про contract testing (Pact, Spring Cloud Contract): автотесты со стороны потребителей фиксируют, что именно они ожидают от API, и предупреждают о ломающих изменениях до того, как они доедут до продакшена.

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

Следующий этап — shadow testing. Новая система получает копии реальных запросов, считает результат, но пользователю по-прежнему возвращается ответ legacy. Команда сравнивает результаты и устраняет расхождения.

Когда новая реализация достаточно стабильна, начинается постепенное переключение через feature toggles. Сначала внутренние пользователи, потом 1% реального трафика, затем 5–10%, затем 50% и только после этого 100%.

На каждом этапе команда смотрит на метрики. Если всё стабильно, движение продолжается. Если появляются проблемы, флаг выключается, трафик возвращается в legacy, а команда разбирает причины.

Последний этап — удаление старого кода. Это не формальность, а обязательная часть миграции. И «удалить старый код» — это не один коммит, а явный Definition of Done: вырезана старая ветка кода, удалён фича-флаг, обновлена документация и схемы архитектуры, переименованы или удалены устаревшие дашборды и алерты, обновлены runbook’и для on-call и проведено короткое внутреннее обучение. Если этого не сделать, через полгода никто уже не вспомнит, какой путь актуален, и легаси-ветвление останется в коде навсегда.

Откат миграций: дешёвый только пока не пошли записи

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

Поэтому ещё на этапе проектирования каждое изменение должно сопровождаться явным планом отката. Удобно различать три типа шагов.

Полностью обратимые шаги. Чтение через новый сервис, расчёт «в тени», новые метрики. Откат — выключить флаг. Это самый комфортный режим, и в нём стоит держать миграцию как можно дольше.

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

Forward-only. После некоторой точки откат становится невозможен — например, после того, как старая схема удалена или внешние интеграции перенастроены на новый сервис. Такие шаги допустимы, но к ним нужно приходить отдельно, осознанно, с особенно строгими SLO в предыдущем этапе. До forward-only-перехода имеет смысл подержать систему в режиме параллельной работы дольше, чем по графику.

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

Пример: как тот же сервис мигрировали со второй попытки

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

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

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

Затем команда выбрала первый кусок для выноса — не весь сервис, а только чтение документов (GET /documents/{id} и GET /documents/by-driver/{driver_id}). Это была наименее рискованная часть: ошибки в чтении неприятны, но не ломают финансовые потоки.

Новый сервис написали на FastAPI рядом со старым. На уровне API Gateway появилось правило маршрутизации: запросы на чтение шли в старый сервис, но в фоне дублировались в новый. Ответ пользователю всегда возвращал legacy, а ответ нового сервиса сравнивался с эталоном и записывался в отдельную таблицу для разбора. Использовали обёртку поверх asyncio.create_task — на ответ пользователя теневой вызов не влиял.

За три недели shadow-режима команда нашла четыре расхождения. Два оказались багами новой реализации (округление времени, неправильная сортировка вложений). Два — давно забытыми особенностями старого сервиса (одно поле возвращалось в UTC, другое — в локальной зоне; так было исторически, бизнес не возражал, но в новой реализации захотели единый формат). Все четыре зафиксировали явно: баги — починили, особенности — согласовали с продуктовой командой как осознанное изменение.

Когда расхождений не осталось, включили фича-флаг на сотрудников самой компании. Через неделю — на 1% реальных водителей. Дальше шаг по 5%, 25%, 50%, 100% с паузой в несколько дней между этапами. На каждом шаге следили не только за HTTP-ошибками и latency, но и за продуктовыми метриками: количество подписанных актов, время от открытия документа до подписи, доля повторных запросов. Один раз пришлось откатиться с 25% на 5% — в одном из регионов выросло время отклика из-за неэффективного запроса. Исправили, выкатили снова.

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

Типичные ошибки при работе с legacy

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

Вторая ошибка — недооценивать скрытые зависимости и побочные эффекты. Legacy-код часто делает больше, чем кажется. На один и тот же вызов могут быть навешаны: запись в таблицу аудита, инкремент счётчика в кэше, публикация события в очередь, обновление статуса связанной сущности, инвалидация кэша, дёрганье webhook’а во внешнюю систему. Если в новой реализации воспроизвести только явный путь, скрытые потребители молча перестанут получать данные — и узнают об этом через жалобу бизнеса, а не через ошибку в логах. Поэтому перед выносом любого модуля имеет смысл составить инвентаризацию побочных эффектов: пройтись по коду и логам и выписать каждое нелогичное действие отдельным пунктом чек-листа.

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

Четвертая ошибка — не договариваться с бизнесом. Модернизация не должна быть невидимой «инженерной активностью в стол». Её нужно встраивать в roadmap, объяснять эффект и договариваться о приоритетах. Если бизнес не понимает, зачем команда тратит время на миграцию, работа будет постоянно проигрывать новым фичам.

Пятая ошибка — не удалять старый код. Временное сосуществование старой и новой логики нормально. Вечное сосуществование — нет. Если legacy не удаляется, технический долг не уменьшается, а просто меняет форму.

Шестая ошибка — не удалять фича-флаги после миграции. Флаг, который сыграл свою роль и больше никогда не выключается, превращается в постоянное ветвление в коде. Через год команда не помнит, можно ли удалить такую ветку или там сидит важный edge-case. Через два — кода с такими «мёртвыми» флагами становится больше, чем основной логики. Поэтому каждый флаг должен заводиться с условием удаления («после полной выкатки и двух недель стабильной работы») и иметь ответственного, кто этим удалением займётся.

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

Компромиссы, к которым нужно быть готовыми

Постепенная модернизация безопаснее Big Bang-переписывания, но она не бесплатна. Некоторое время система будет сложнее, чем раньше. В ней появятся старый и новый код, прокси-слой, фича-флаги, дублирование логики, дополнительные метрики.

Shadow testing увеличит нагрузку на инфраструктуру, потому что часть запросов будет обрабатываться дважды. Команде придется поддерживать дисциплину: документировать контракты, отслеживать флаги, удалять старую реализацию после миграции, поддерживать contract-тесты в актуальном состоянии.

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

Когда Strangler Fig особенно оправдан

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

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

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

Когда модернизацию лучше не делать

Постепенная миграция — мощный инструмент, но у неё тоже есть стоимость, и иногда правильный ответ — оставить систему как есть. Несколько сценариев, в которых модернизация плохо окупается.

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

Модуль, который никто не трогает. Если код десятилетней давности продолжает работать, не падает, не требует изменений и не вызывает инцидентов, его «уродливость» — не повод его переписывать. Цель модернизации — упростить будущие изменения; если будущих изменений нет, цели тоже нет.

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

Простой тест: если на вопрос «какой бизнес-сценарий мы откроем после миграции» нет внятного ответа — модернизацию имеет смысл отложить и заняться чем-то другим.

Что получает команда

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

Появляются понятные контракты, наблюдаемость, практика безопасных релизов, культура удаления старого кода. Разработчики перестают бояться legacy, потому что у них появляется метод, а не только желание «когда-нибудь всё переписать».

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

Модернизация — это процесс, а не проект

Legacy нельзя «починить за квартал». Если система развивалась годами, она не станет простой после одного рефакторинга. Но её можно системно улучшать.

Strangler Fig Pattern, Branch by Abstraction, feature toggles, shadow testing и аккуратная миграция данных дают рабочую модель: выбрать ограниченный участок, описать контракт, реализовать новую версию, проверить её на реальном трафике, постепенно переключить пользователей и удалить старый код.

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

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

Что значит «правильный фундамент сайта»

Под фундаментом я понимаю не только сервер и домен, а совокупность факторов: производительность, надёжность инфраструктуры, структурированные данные, качество контента, доступность и удобство использования. Фреймворк — это инструмент; фундамент — это то, ради чего инструмент используется. Плохо оптимизированный сайт на передовом стеке часто проигрывает хорошо сделанному сайту на классическом стеке. Подробнее про метрики скорости — в материале о Core Web Vitals на Tproger.

• Выбор фреймворка перестал быть решающим фактором: зрелые инструменты дают схожие возможности.
• Производительность, хостинг, домен и CDN (сеть доставки контента) напрямую влияют на трафик и конверсию.
• Структурированные данные (Schema.org / JSON-LD) помогают поисковикам и ИИ правильно понимать контент.
• ИИ-поиск и ответные системы меняют правила видимости: важны ясность, авторитетность и точные ответы.
• Качественный контент и UX становятся главным конкурентным преимуществом.

Технологический стек стал товаром

За последнее десятилетие экосистема веб-разработки выросла настолько, что большинство популярных фреймворков предлагают примерно одно и то же: компонентную архитектуру, серверный рендеринг, интеграции с API, аутентификацию и инструменты оптимизации. Разрыв между React, Vue, Svelte, Next.js, Nuxt, Laravel или Django в типичных задачах сократился до предпочтений команды, а не до объективных преимуществ.

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

Сигнал проверить себя: если команда обсуждает миграцию фреймворка, но у сайта LCP выше 2,5 с, нет CDN и картинки весят по 400 КБ — стоит сначала закрыть очевидные дыры в фундаменте.

Производительность всё ещё решает

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

Что именно оптимизировать

Современная оптимизация выходит далеко за «сожми JS». Нужно думать о форматах изображений (WebP, AVIF), ленивой загрузке, кешировании на граничных серверах, CDN, оптимизации шрифтов и времени ответа сервера. Интернет-магазин, который перевёл каталог на WebP, включил lazy loading и раздал статику через CDN, зачастую получит больше прироста, чем если бы переписал витрину с нуля.

• Измеряйте LCP (Largest Contentful Paint — отрисовку крупного контента), INP (Interaction to Next Paint — время реакции на взаимодействие) и CLS (Cumulative Layout Shift — визуальную стабильность) в PageSpeed Insights или Lighthouse.
• Переводите изображения в современные форматы и используйте адаптивные размеры.
• Включайте кеширование статики на CDN (сети доставки контента) как минимум на год.
• Убирайте неиспользуемый CSS и JS: в российских сетях каждый лишний мегабайт бьёт по скорости и по бюджету пользователя.

Домены и инфраструктура не теряют значения

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

В российском контексте стоит обращать внимание на локальных регистраторов — например, Reg.ru или RU-CENTER. Важны двухфакторная аутентификация в личном кабинете, блокировка переноса домена (domain lock), корректные NS-записи и резервные DNS-серверы. Если ваш бизнес зависит от сайта, отказоустойчивость DNS может спасти репутацию в момент DDoS или аварии хостинга.

• Проверьте срок действия домена и включите автообновление.
• Включите 2FA у регистратора и запретите неавторизованный трансфер.
• Используйте минимум два независимых NS-сервера в разных сетях.
• Мониторьте время отклика DNS: оно влияет на TTFB (Time to First Byte — время до первого байта ответа сервера).

Хостинг — это уже не просто сервер

Раньше хостинг означал аренду железа и развёртывание кода. Сегодня платформы предлагают глобальные CDN, автомасштабирование, встроенную безопасность, наблюдаемость и автоматизацию развёртывания. Граничные вычисления позволяют отдавать контент ближе к пользователю, снижая задержку.

Что спрашивать у провайдера

В России это может быть Selectel, Timeweb, Beget, Yandex Cloud или VK Cloud. Выбирая провайдера, смотрите не только на цену CPU/RAM, но и на SLA по доступности, географию CDN-точек, скорость развёртывания, поддержку HTTP/2 и HTTP/3, а также простоту мониторинга. Сайт, который остаётся доступным во время вирального всплеска трафика, приносит больше пользы, чем идеально написанный, но упавший сервис.

Практический контрольный список: есть ли у провайдера CDN (сеть доставки контента) в России, автомасштабирование, бэкапы и DDoS-защита? Если нет — вы платите не за хостинг, а за аренду сервера с самообслуживанием.

Структурированные данные перешли из «можно» в «нужно»

Поисковые системы и ИИ всё чаще не просто индексируют текст, а пытаются понять смысл страницы. Schema.org / JSON-LD помогает явно указать: это статья, товар, отзыв, событие, организация или рецепт.

Без микроразметки поисковику приходится догадываться из неструктурированного текста, что повышает риск ошибок. С микроразметкой контент чаще попадает в расширенные сниппеты, карточки знаний и rich results. Для русскоязычных проектов это особенно важно в Яндексе и Google: оба поисковика поддерживают Schema.org.

Пример разметки статьи на базе Schema.org — в гайде «Добавляем Schema.org в Docusaurus для GEO».

• Для статей используйте тип Article с headline, author и datePublished.
• Для товаров — Product с offers, aggregateRating и availability.
• Проверяйте разметку через валидаторы Google Rich Results Test и Яндекс.Вебмастер.
• Добавляйте FAQ и HowTo только там, где они реально отвечают на вопросы пользователей.

ИИ-поиск и Answer Engine Optimization

Пользователи всё чаще задают вопросы нейросетям и ассистентам вместо того, чтобы вбивать ключевые слова в поисковик. ChatGPT, Perplexity, ЯндексGPT, Google AI Overviews собирают ответы из множества источников и показывают их в диалоговом формате.

Как стать источником для ИИ

Это меняет правила видимости. Цель уже не только попасть на первую страницу Google, но и стать источником, который ИИ цитирует. Answer Engine Optimization (AEO) — подход, при котором контент структурируется так, чтобы давать прямые, авторитетные и легко извлекаемые ответы.

• Формулируйте ключевые тезисы в первых 100-150 словах статьи.
• Используйте чёткие заголовки H2/H3 с вопросами («Что такое...», «Как проверить...»).
• Добавляйте блоки FAQ и Ключевые выводы: ИИ-системы часто цитируют именно их.
• Подкрепляйте утверждения ссылками на первоисточники и данные.

Контент остаётся главной причиной визита

Технологии улучшают доставку, но не заменяют смысл. Тонкий контент, заточенный только под ключевые слова, всё хуже ранжируется: поисковики и ИИ всё лучше распознают экспертизу, авторитетность и релевантность.

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

Поисковые системы всё лучше распознают контент, который действительно отвечает на вопросы пользователей. Техническая оптимизация открывает дверь, но экспертиза заставляет людей возвращаться.

Пользовательский опыт — новый дифференциатор

С чего начать проверку

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

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

• Проверьте сайт с клавиатуры: можно ли дойти до всех интерактивных элементов?
• Запустите Lighthouse в мобильном режиме и исправьте критичные замечания по доступности.
• Тестируйте на реальных устройствах, а не только в десктопном браузере.
• Собирайте обратную связь от реальных пользователей, а не только метрики.

Подробнее про инструменты и приёмы проверки доступности — в материале «Что такое доступность сайта и как её проверить».

Будущее — за результатами, а не фреймворками

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

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

FAQ

Выводы

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

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

Источник: Manish Shivanandhan, freeCodeCamp — Building a Website in 2026: What Matters More Than Your Tech Stack. Материал подготовлен как авторская переработка идеи с добавлением российского контекста и практических рекомендаций.

Когда устройство отправляет DNS-запрос по порту 53, данные путешествуют по сети незашифрованными. Провайдер, администраторы локальной сети или злоумышленник в публичном Wi-Fi видят, какие домены запрашиваются. Это открывает двери для DNS-хиджинга. Перехватив запрос, атакующий подменяет IP-адрес и перенаправляет пользователя на фишинговую копию сайта. HTTPS защищает содержимое страницы, но не сам факт обращения к домену.

Пять протоколов, которые решают проблему

Do53 — старая школа без шифра

Классический DNS, работающий по UDP и TCP на порту 53, быстр и совместим со всем. Однако он создавался в эпоху, когда приватность в сети не была приоритетом. Внутри дата-центров и корпоративных периметров он по-прежнему уместен, а вот для клиентских запросов из браузера давно пора на что-то менять.

DoT — DNS поверх TLS

Протокол оборачивает запросы в привычный TLS и отправляет их на выделенный порт 853. По сути, это тот же механизм шифрования, что и у HTTPS, только примененный к DNS. Благодаря отдельному порту сетевым администраторам легко идентифицировать трафик, но заодно и блокировать его. Именно поэтому браузеры не спешат внедрять DoT по умолчанию, зато он активно используется в Android 9+ и iOS 14+ через настройку «Приватный DNS». На старте соединение требует двух дополнительных RTT по сравнению с обычным DNS.

DoH — маскировка под веб-трафик

DNS over HTTPS туннелирует запросы внутри обычного HTTPS на порту 443, делая их неотличимыми от обычного веб-серфинга. Это главное преимущество и главная боль: корпоративные сети не могут фильтровать DNS без блокировки всего HTTPS. Firefox и Chrome уже используют DoH по умолчанию, так что большинство посетителей вашего сайта, скорее всего, приходят именно через этот протокол. Серверной настройки от владельца сайта он не требует.

DoQ — скорость QUIC

Самый молодой из массовых протоколов использует транспорт QUIC вместо TCP. Рукопожатие TLS и транспортное объединяются в одну операцию, а при смене сети, например с Wi-Fi на мобильный интернет, соединение не разрывается благодаря миграции. По данным исследования PAM 2026, DoQ обгоняет DoT и DoH примерно на треть в скорости одиночного запроса и отстает от нешифрованного DNS всего на пару процентов. Загрузка страниц выходит на 10% быстрее, чем с классическим DoH. Поддерживается Quad9, NextDNS и AdGuard, а вот у Cloudflare и Google пока нет production-резолверов.

DoH3 — привычный DoH на новом транспорте

Это все тот же DNS over HTTPS, но работающий поверх HTTP/3, который в свою очередь построен на QUIC. DoH3 сохраняет преимущества порта 443 и при этом получает быстрое установление соединения с миграцией. В масштабном бенчмарке более чем 3000 резолверов DoH3 и DoQ показали сопоставимые результаты, причем производители браузеров сейчас склоняются именно к DoH3 как к естественному эволюционному шагу от DoH.

Цифры: что показывает бенчмарк

В исследовании PAM 2026 (Springer, март 2026) проанализировали свыше 3000 резолверов по всем континентам. Ключевой вывод: DoQ и DoH3 практически устранили разрыв в производительности между зашифрованным и открытым DNS. Задержка одиночного запроса выросла в пределах погрешности, что незаметно на фоне полной загрузки страницы. Зато за счет экономии одного RTT и эффективного мультиплексирования QUIC сложные страницы с двадцатью и более DNS-запросами загружаются заметно быстрее, чем с DoH поверх HTTP/2.

• Do53: рукопожатия нет, базовая задержка, шифрование отсутствует
• DoT: требуется TCP + TLS, на 15–25% медленнее классики, стабильный и предсказуемый
• DoH: два RTT на старт, сопоставим с DoT, стандарт де-факто в браузерах
• DoQ: один RTT, разница с Do53 в пределах погрешности, есть миграция соединений
• DoH3: наследует скорость QUIC, работает на порту 443, миграция поддерживается

Что владельцу сайта контролировать

Шифрование DNS на стороне посетителя работает без участия сервера, но скорость разрешения имен напрямую влияет на Time to First Byte и, как следствие, на Core Web Vitals. Ваша зона ответственности лежит на других уровнях.

1. Авторитарный DNS. Выбирайте регистратора или хостинг с глобальной anycast-сетью, чтобы сократить время отклика с любой точки мира.
2. Настройка TTL. Для стабильных записей хватит 3600 секунд, перед плановыми изменениями снижайте до 300.
3. DNSSEC. Включите подпись зоны в панели управления доменом. Это не шифрует трафик, но защищает от подмены ответов на уровне авторитарного сервера.

Не пытайтесь форсировать у посетителей конкретный протокол: Chrome и Firefox сами выберут DoH или DoH3, а Android предпочтет DoT. Сосредоточьтесь на том, чтобы ваши неймсерверы отвечали быстро и надежно.

Как проверить и протестировать DNS

Убедиться, что браузер использует шифрование, можно встроенными средствами.

• Chrome: адрес chrome://net-internals/#dns показывает детали разрешения, а в разделе настроек безопасности включается «Безопасный DNS».
• Firefox: параметр network.trr.mode в about:config отвечает за режим DoH. Значение 2 — DoH с откатом, 3 — только DoH.
• Утечки: сервис dnsleaktest.com покажет, видит ли ваш провайдер запросы или они уходят к резолверу Cloudflare/Quad9.

Для сравнения задержек на уровне командной строки подойдет утилита dnsdiag.

Настройка шифрования на сервере

Если сервер сам обращается к внешним резолверам, например при проксировании запросов, направьте nginx на защищенные адреса.

Cloudflare поддерживает все современные протоколы: классический 1.1.1.1, DoT, DoH через endpoint /dns-query, а DoQ и DoH3 обычно подключаются автоматически при поддержке клиентом.

Важные ограничения

Зашифрованный DNS скрывает только то, какой домен запрашивается, но не делает пользователя полностью невидимым. После разрешения имени браузер открывает TCP-соединение с конкретным IP, который виден наблюдателю. Без технологии Encrypted Client Hello домен продолжает светиться в поле SNI TLS-рукопожатия. Кроме того, по объему и паттернам трафика можно восстановить картину посещенных сайтов. Шифрование DNS — это необходимый, но недостаточный слой защиты.

Выбор протокола под задачу

• Личная приватность в публичных сетях: DoQ через Quad9 или NextDNS, либо DoH Cloudflare.
• Корпоративная среда с мониторингом: DoT на контролируемый резолвер.
• Мобильные устройства: системный Private DNS (DoT) в Android и iOS.
• Максимум скорости и приватности: DoQ с поддержкой Session Resumption.
• Авторитарный DNS домена: быстрый Do53 с включенным DNSSEC и anycast-инфраструктурой.

DoH уже работает в браузерах ваших посетителей и не требует настройки с сервера.

DoQ и DoH3 на базе QUIC обеспечивают скорость, сопоставимую с открытым DNS, при полном шифровании.

Владельцу сайта стоит включить DNSSEC и использовать anycast-неймсерверы, а выбор протокола для клиента оставить браузеру.

В IPv6 каждый сетевой интерфейс получает link-local адрес из диапазона fe80::/10 (первые 10 бит фиксированы, остальное — адрес интерфейса). Если у машины два интерфейса — например, Ethernet и Wi-Fi — оба будут в одном и том же префиксе. Вопрос: как операционная система понимает, к какому именно интерфейсу адресовать пакет? Ответ — зоны (scopes).

В IPv6 зона интерфейса записывается через %: fe80::4%eth0. Это нужно, чтобы различать link-local адреса на разных сетевых интерфейсах.

В URL зона попадает внутрь квадратных скобок: [fe80::4%eth0]:80. Но символ % в URL — это начало percent-encoding, поэтому парсер ломается.

Решение — экранировать % как %25: [fe80::4%25eth0]:80. Это поведение зафиксировано в RFC 6874.

Проблема затрагивает не только Go, но и nginx, Python requests и браузеры. Поддержка зон в HTTP-клиентах остаётся фрагментарной.

Как зоны работают в IPv6

Зона (или scope ID) — это механизм, позволяющий ядру отличать адреса из пересекающихся диапазонов. Для link-local адресов fe80::/10 он критичен: без него роутинговая таблица не поймёт, через какой интерфейс отправлять трафик.

Формат зоны зависит от ОС. В Linux это имя интерфейса — eth0, wlan0, ens192. В Windows — числовой идентификатор интерфейса. Полный адрес выглядит так:

Квадратные скобки отделяют хост от порта — иначе двоеточия IPv6-адреса спутаются с разделителем порта.

Конфликт зон и URL

Теперь вставим этот адрес в URL. На первый взгляд всё просто:

Но попробуем распарсить его в Go:

Получаем ошибку:

Что произошло? В URL любой символ, не входящий в разрешённый набор, должен быть percent-encoded. Пробел превращается в %20, кириллица — в последовательности вроде %D0%90. Парсер видит %e и пытается декодировать его как hex-последовательность. et — не валидный байт, поэтому URL отклоняется.

Почему Go падает и как это чинить

С точки зрения стандарта Go ведёт себя корректно. RFC 3986 определяет URL-грамматику, а RFC 6874 специально дополняет её для IPv6-зон: символ % перед zone ID должен быть сам закодирован как %25.

Правильный URL выглядит так:

Проверяем в Go:

Вывод:

Go корректно декодирует %25 обратно в % при извлечении хоста. То есть библиотека поддерживает RFC 6874, но требует от вызывающего кода заранее закодировать зону.

RFC 6874: это не баг, а фича

В RFC 6874 формально описан синтаксис IPv6-адресов с зонами в литералах URL. Ключевой фрагмент:

То есть зона записывается не как %eth0, а как %25eth0. Это выглядит ужасно с точки зрения пользовательского опыта, но таково решение стандартизации: совместимость с существующей URL-грамматикой важнее эргономики.

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

И действительно, та же проблема есть и в других инструментах:

• nginx — тикет #623, созданный более десяти лет назад; проблема отсутствия поддержки link-local адресов с зонами до сих пор актуальна.
• Python requests — issue #6808: даже при ручном кодировании % как %25 библиотека некорректно обрабатывает IPv6-зоны в URL, потому что urllib3 декодирует %25 обратно в %.
• Браузеры — draft Schinazi объясняет, почему зоны ломают концепцию origin, и рекомендует использовать mDNS вместо прямого указания link-local адресов в URI.

Что делать разработчику

Если ваше Go-приложение работает с локальными IPv6-адресами — например, подключается к сервисам в Docker-сети, IoT-устройствам или внутренним API через link-local — учитывайте следующее:

1. Перед передачей IPv6-адреса с зоной в url.Parse всегда экранируйте % как %25.
2. Используйте net.JoinHostPort для сборки host:port — он корректно оборачивает IPv6 в скобки, но не кодирует зону. Дополнительное кодирование остаётся на вас.
3. Если адрес приходит от пользователя, валидируйте его до парсинга: зона должна содержать только допустимые символы (имя интерфейса в Linux, числовой ID в Windows).
4. Тестируйте на реальных интерфейсах с разными зонами, чтобы убедиться, что кодирование работает корректно в вашей среде.

На заметку:
Если вы пишете HTTP-клиент для embedded-устройств или промышленных контроллеров, которые общаются через link-local IPv6, ручное кодирование зоны — не костыль, а необходимость. Большинство библиотек не делают этого автоматически.

FAQ

Выводы

IPv6-зоны — редкий, но живучий граничный случай. Если вы пишете сетевой код на Go, который должен работать в гетерогенных средах — Docker, Kubernetes, embedded-системы, промышленные сети — знайте, что fe80::1%eth0 в URL превращается в fe80::1%25eth0. Это не баг парсера, а требование стандарта RFC 6874.

Инкапсулируйте кодирование зоны во вспомогательную функцию и всегда прогоняйте IPv6-адреса через неё перед сборкой URL. Экономия пяти минут сейчас обернётся часом отладки в продакшене, когда сервис внезапно не сможет достучаться до соседнего контейнера по link-local.

Источники:
• Xe Iaso — IPv6 zones in Go URLs
• RFC 6874 — Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers
• draft-schinazi-httpbis-link-local-uri-bcp-03 — IPv6 Link-Local URIs

Теперь переходим к 90-м и нулевым. Это период, когда российское IT начало собираться в индустрию: компьютеры появлялись в офисах, программистов доучивали на работе, вирусы распространялись по дискетам, отчётность переносили с бумаги на магнитные носители, а банки только учились показывать клиенту баланс через интернет.

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

Больше про историю российской IT-индустрии слушайте в аудио-шоу «От нуля до единицы» от экосистемы для бизнеса Контур и студии «Послушайте».

Сначала компьютер нужно было где-то достать

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

Один был вариантом «Радио-86РК» от ленинградского объединения ЛОМО, с плёночной клавиатурой. Другой, более известный, — клон британского ZX Spectrum 48K от московского НПО «Аксон», с полноценными клавишами и 48 килобайтами памяти — примерно столько занимает одна современная иконка приложения.

Чуть позже появились «Поиск» с процессором 8088 и дисководом 5,25 дюйма, а также «Искра» образца 1989 года. Это уже были IBM-совместимые машины с MS-DOS и Norton Commander.

Если сравнивать с сегодняшним ноутбуком, такой компьютер выглядит коробкой с клавиатурой: процессор — слабее любого смартфона, дисковод — вместо флешки или облака, MS-DOS — вместо привычной операционной системы с окнами, Norton Commander — вместо проводника файлов. Но для конца 80-х и начала 90-х на нём можно было запускать программы, хранить данные, работать с файлами и учиться тому, что позже станет вечным требованием в вакансиях — «уверенный пользователь ПК».

Даже эти первые машины уже показывали, что компьютеры нужны обычным людям, но в 1991 году средний компьютер стоил около 1000 долларов. Помимо денег нужно было выбрать конфигурацию, понять, у кого брать, и надеяться, что всё заработает. К 2000 году цена компьютера упала до 500–700 долларов. И тут появилась следующая проблема: купить компьютер вроде бы стало проще, но что с ним делать — непонятно.

Компьютеры появились быстрее, чем специалисты

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

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

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

Так сформировалась одна из фишек российского IT 90-х: компании не ждали готовых кадров. Они покупали компьютеры, автоматизировали учёт, подключали сети и параллельно доучивали людей на профильных задачах.

Как люди входили в IT в 90-е, рассказывают в подкасте «От нуля до единицы». Там же — про утечку мозгов, первых специалистов и путь к покупке компьютера: от поиска денег до поездок по полуподвальным конторам.

Те, кто научился программировать первыми — пошли делать софт для бизнеса

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

Контур с программой «Учёт труда и заработной платы — АМБа», которую выпустили ещё в 1986 году, за два года до создания самого Контура, оказался очень вовремя. Программой пользовались государственные учреждения и заводы. В конце 90-х Контур помог перевести налоговую отчётность на магнитные носители — компании стали сдавать декларации на дискетах вместо бумаги. А в 2000 году появился «Контур.Экстерн»: предприятия впервые смогли отчитываться в налоговую через интернет, без личного присутствия в инспекции.

Когда данных от бизнеса стало больше, компьютеры пришлось связать в сеть

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

7 апреля 1994 зарегистрировали домен .RU. В тот же день появился первый сайт российской доменной зоны — www.1-9-9-4.ru: список из нескольких десятков адресов с короткими описаниями, что вообще можно узнать в новом русском интернете.

Именно из логики, когда нужно искать среди нарастающего потока страниц, выросли первые поисковики, но перед этим было одно важное событие.

В 1991 году в подмосковном Пущино пятеро инженеров-радиотехников из местных НИИ основали компанию «Стек». Они проложили IP-канал из Пущино к сети Курчатовского института — это был первый интернет-канал в России, выходящий за пределы Москвы. Потом подняли собственные ftp-, mail- и www-серверы. В 1996 разработчик компании Дмитрий Крюков написал ядро поисковика и назвал его Rambler. На момент запуска — 8 октября 1996 — система проиндексировала около 100 тысяч документов, хотя сайтов в Рунете тогда насчитывалось не больше 30–50.

23 сентября 1997 анонсировали Яндекс. Его сильной стороной стала работа с русским языком и морфологией — система понимала, что «купить», «купил» и «куплю» — одно и то же слово. В 1998 году на Yandex.ru появился контекстный баннер, который менялся в зависимости от запроса пользователя. Позже контекстная реклама стала основной бизнес-моделью компании.

С этого момента сеть перестала быть просто набором серверов и документов. Данных становилось больше, их нужно было искать, передавать и копировать. Но в 90-х обмен файлами ещё часто шёл не через интернет, а через дискеты: программы, документы и базы носили между компьютерами вручную.

Дискеты переносили не только программы, но и вирусы

В 90-х вирусы распространялись в основном через те самые дискеты — схема была простой: принесли программу, скопировали файл, а вместе с ним и вирус.

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

Одним из первых проектов против вирусов был Tadpole. Затем появился антивирусный сканер Tornado. Позже эти разработки объединились в Spider’s Web. В 1993 году появился Dr.Web, а в 1994 году вышла первая коммерческая версия.

Параллельно развивалось другое направление. Евгений Касперский после работы в НИИ Министерства обороны ушёл в коммерческий IT, занимался антивирусной разработкой в КАМИ, а затем вместе с командой создал собственную фирму. В 1996–1997 годах команда договорилась с иностранными вендорами, поэтому теперь зарубежные компании использовали российский готовый движок в своих продуктах.

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

Дефолт ударил по рынку, но открыл дорогу аутсорсу

Экономика быстро напомнила, что рынок не существует отдельно от страны — в 1998 году случился дефолт. Рубль резко обесценился: 1 августа доллар стоил около 6,24 рубля, а к концу 1999 года уже около 27 рублей.

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

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

Компании начали выращивать специалистов

Acronis начинал с факультативов в МФТИ. В 2004 году Microsoft запустила в России программу IT Academy. В 2008 году Контур запустил образовательные программы в уральских вузах: стажировки, школу промышленного программирования, гранты и стипендии.

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

Про то, как российское IT переживало дефолт, кадровый голод и переход к аутсорсу, подробнее говорят в подкасте «От нуля до единицы». Новые эпизоды выходят каждую среду.

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

Банки шли к онлайну через бумагу, модемы и первые карты

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

Первые коммерческие банки появились ещё в 1988, к концу 1991 года их было около 1400, а в 1992-м — уже больше 2000. Чем больше становилось операций, тем труднее было сводить всё вручную.

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

В середине 90-х в Россию пришли Visa и MasterCard. Параллельно появились отечественные платёжные системы: Union Card и «Золотая Корона». Первые карты были магнитными, без чипов — и почти бесполезными в повседневной жизни: магазины, кафе и заправки карты не принимали. Терминал для безналичной оплаты был редкостью даже в Москве. Поэтому владелец карты чаще всего шёл к банкомату, снимал наличные и дальше платил как обычно — бумажными деньгами.

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

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

Только к 2010 году IT стало реальной индустрией

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

К 2010 году доля IT-сектора в российском ВВП достигла 1%. Это уровень, сопоставимый с индустрией развлечений или гостиничным бизнесом. Путь от редкого компьютера, дискеты, модема и сисадмина на все руки занял около 20 лет.

Вся эта история подробнее разобрана в подкасте «От нуля до единицы» от экосистема IT-продуктов для бизнеса Контур и студии «Послушайте». Это документальный подкаст о том, как российское IT прошло путь от первых вычислительных машин и кооперативов до Рунета, аутсорса, финтеха и мобильных сервисов. Новые эпизоды выходят каждую среду.

Один такой кейс я помню особенно болезненно. Заказчик специально ушёл от «тяжёлых» платформ ради самописного решения: быстрее сроки, ниже чек на входе. Полгода спустя каталог перевалил за 10 000 позиций. Страницы открывались по 8–12 секунд, поиск фактически умер, обмен с учёткой превратился в ручной ад. В итоге пришлось пересобирать магазин на другой системе — и суммарно это стоило примерно в три раза больше, чем если бы выбрать нормальный фундамент сразу.

Вывод простой и непопулярный: для интернет-магазина CMS — это не «движок сайта», а контур бизнеса. Если он не тянет каталог, склады, оплаты и промо — экономия на старте превращается в налог на переделку.

Почему «красивая витрина» не спасает

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

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

Где Битрикс реально оправдан

На корпоративных и сетевых историях Битрикс заходит потому, что это не «лендинг с корзиной», а связка магазина с процессами: каталог, заказы, складские и клиентские сценарии из коробки, обмен с 1С как отдельная экосистема.

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

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

Kогда разумнее WooCommerce и облако

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

Облачные SaaS вроде Shopify годятся, когда компании нужен быстрый старт без администрирования сервера и команды DevOps. Комиссии и ограничения платформы нужно закладывать в юнит-экономику заранее — но для проверки гипотезы это иногда лучший компромисс.

OpenCart и аналоги я чаще видел у проектов, где важна предсказуемость и «руки разработчика на аутсорсе»: проще найти исполнителя, меньше сюрпризов, чем на экзотике. Magento и тяжёлый enterprise-класс имеют смысл, когда команда уже сильная технически и каталог — это отдельный продукт, а не «сайт с корзиной».

Самопис — не зло, но это отдельная ставка

Своя CMS имеет смысл, когда продукт по сути уникален и типовые решения мешают. Во всех остальных случаях вы покупаете не «уникальность», а дорогую поддержку собственного монстра: каждый апдейт PHP, каждый новый способ оплаты — ваш головняк.

Если уже понятно, что платформа не та

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

На этом этапе экономить опаснее всего: «перенесём как получится» почти всегда означает битые URL, дубли в выдаче и потерянные заказы в переходный месяц. Если уж делаете миграцию — делайте её один раз и основательно.

Что мы делаем перед выбором

• Считаем не «стоимость запуска», а стоимость трёх лет жизни: лицензии, хостинг, доработки, интеграции.
• Фиксируем сценарии: каталог, промо, B2B/B2C, обмен с учёткой, маркетплейсы.
• Закладываем буфер на рост — если через год SKU вырастет в пять раз, платформа должна выдержать без полной переделки.
• Перед подписанием уточняем у подрядчика три неудобных вещи: сколько стоит час поддержки после запуска, как закрываются интеграции «не из коробки», и что будет, если через полгода понадобится второй склад или новый тип оплаты.

Ответы без конкретики («сделаем как надо») для меня красный флаг. Нормальный исполнитель называет риски и диапазоны хотя бы порядка величины.

Если очень коротко: не экономьте на фундаменте там, где сайт — канал продаж. Экономия почти всегда вернётся чеком на миграцию.

Подробнее разобрал платформы и критерии в материале на сайте: как выбрать CMS для интернет-магазина — сравнение подходов.

1. Советские математики заложили базу для российских бигтехов

Чтобы понять, откуда в России вообще взялись программисты, вернемся в конец 1940-х годов. После Великой Отечественной войны началась технологическая гонка вооружений. У США уже была ядерная бомба, поэтому Советскому Союзу нужно было срочно создать свою. Для разработки похожего оружия применяли сложные математические расчеты, которые люди с механическими арифмометрами выполняли бы годами, поэтому Советский Союз взял курс на создание своих вычислительных машин.

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

Развитие советской техники возглавил ученый Сергей Лебедев. Сначала он построил первую отечественную ЭВМ — МЭСМ (малую электронную счетную машину), а после начал разработку серии БЭСМ (больших электронных счетных машин).

Больше о том, как создавались первые советские ЭВМ, узнайте в подкасте Контура и студии «Послушайте!» «От нуля до единицы. История российского IT». Там про это рассказывает антрополог и автор книги «Антропология русского интернета» Наталья Конрадова — с деталями, которых нет ни в этой, ни в других популярных статьях.

Вершиной разработки в Советском Союзе стала БЭСМ-6, она серийно производилась с 1968 по 1987 год и стала основным инструментом для ученых и инженеров. На этой машине считали траектории ракет и моделировали ядерные реакции. Именно на ней учили программированию студентов лучших технических вузов страны.

Работа с первыми ЭВМ сформировала советскую инженерную культуру. Специалисты привыкли писать алгоритмы в условиях ограничений вычислительных ресурсов.

2. Программирование стало языком — и это открыло рынок для коммерческих продуктов

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

Прорыв случился в середине 1950-х годов в США — именно тогда появился первый язык Fortran: один и тот же код можно было запустить на разных машинах без полного переписывания. Это был принципиальный сдвиг в индустрии, потому что разработчик перестал зависеть от конкретного железа и начал думать над созданием новых архитектур и алгоритмов.

В СССР этот мировой принцип быстро подхватили и развили локально. Программист Владимир Курочкин написал транслятор универсального языка Алгол-60 сначала для БЭСМ-2, а затем для БЭСМ-6. На этой базе выучились тысячи советских инженеров, которые впоследствии стали основателями ведущих отечественных IT-компаний.

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

3. Технологии 50-х годов помогли заложить основы для автоматизации документооборота

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

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

Позже эту идею подхватил Виктор Глушков, возглавивший Институт кибернетики. Он развил идеи Китова и довел их до уровня масштабного государственного проекта — ОГАС (общегосударственной автоматизированной системы учета и обработки информации). Эта система должна была объединить все министерства и заводы страны единой вычислительной сетью, чтобы управлять экономикой в реальном времени.

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

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

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

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

У гражданских объектов, заводов, государственных учреждений потребность обмениваться электронными документами с годами никуда не исчезла. И когда в конце 1980-х годов гражданам разрешили создавать кооперативы, частные инженеры начали разрабатывать софт для упрощения документооборота. Именно это сделал и Контур, когда в 1988 году запустил свой первый продукт «Учет труда и заработной платы — АМБа».

4. До хакатонов были олимпиады: как школьные соревнования воспитали первых разработчиков коммерческого софта

Сегодня IT-специалисты соревнуются на хакатонах, а в Советском Союзе были олимпиады по программированию. В 1981-м в Москве прошло первое такое соревнование среди школьников, а уже через четыре года информатика официально стала школьным предметом. К 1988 году в Свердловске (ныне Екатеринбург — родина Контура) организовали уже всесоюзное соревнование.

Туда приехали около ста участников, чтобы пройти два тура: теоретический и практический. Персональных компьютеров на сотню участников не хватало. Поэтому правила были жесткими: сначала школьники решали теорию на бумаге, и только лучшие получали доступ к настоящим ПК на практическом туре.

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

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

Победителям хотели подарить отечественный персональный компьютер за 500 рублей при зарплате инженера около 100 рублей в месяц. Денег у организаторов не нашлось, поэтому вручили бумажные дипломы и пригласили поступать в МГУ. Из таких олимпиадников и выросло поколение, написавшее первые коммерческие продукты.

5. Кооперативы 1987 года — точка, где наука стала бизнесом

До 1987 года у инженера из НИИ было ровно два пути: работать на государство за 120 рублей в месяц или уйти в никуда. Закон о кооперативах дал им возможность легально открывать свои компании и продавать разработки. Спрос на программы уже был: заводам и госструктурам требовалась автоматизация учета, но готового софта в СССР не существовало.

В 1988 году трое выпускников Уральского политехнического института (УПИ) создали компанию СКБ Контур. Их первым продуктом стала программа «АМБа» — с ней бухгалтеры смогли вести электронный учет труда и зарплаты на предприятиях. Первыми покупателями стали предприятия Свердловска, в том числе Уральский алюминиевый завод.

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

Со временем алгоритмы и опыт разработки «АМБы» стали базой для новых IT-продуктов Контура. К 2000 году появился «Контур.Экстерн» — платформа для сдачи электронной отчетности в госорганы. Она работает и развивается уже 26 лет.

6. Горбушка и пиратство создали инженерную школу реверс-инжиниринга

На московском рынке Горбушка в 1990-х продавцы торговали прямо с ящиков: запчасти для ZX Spectrum, пиратские операционные системы, бухгалтерские программы на дискетах.

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

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

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

7. Релком доказал, что открытые сети работают — и дал старт провайдерскому рынку

Параллельно с развитием стихийных рынков ПО появлялись отечественные сети связи. В начале 1990-х годов в подвале Курчатовского института группа ученых подняла первую публичную компьютерную сеть в стране — Релком. Секретные военные вычислительные центры прошлого оставались строго изолированными системами. Релком подключал всех: нужен был компьютер, модем и телефонная линия. Инфраструктура строилась на операционной системе UNIX и машинах производства DEC.

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

Локализация победила глобальных игроков — и это стало моделью для всего российского бигтеха

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

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

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

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

Мне эта модель быстро наскучила.

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

Сразу зафиксируем рамки, чтобы не плодить фантомные ожидания:

- это не убийца Telegram;

- это не презентация для инвестора с KPI и growth loops;

- это не проповедь о том, как всем теперь жить.

Это мой личный цифровой бункер, моя песочница, мой учебный полигон и мой инженерный аттракцион. Я строю это прежде всего для себя: как резервный канал связи, как способ не зависеть от чужих решений и как честный highload-эксперимент, в котором можно не рассуждать про real-time в теории, а ловить его за горло руками.

И вот здесь началось смешное.

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

Что это вообще такое

На текущем этапе это PWA-мессенджер.

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

«настоящие пацаны пишут только натив». Можете не разогреваться, я это всё уже сам себе рассказал.

Почему все равно PWA:

- мне нужен был короткий путь от идеи до живого клиента;

- мне нужен был быстрый цикл выката без ритуальных танцев с

магазинами приложений;

- мне нужен был клиент, который можно быстро ломать, чинить,

пересобирать и снова кидать в бой;

- мне нужно было что заработает на разных платформах;

- мне нравится, что PWA живет в браузерной песочнице, а не лезет в телефон как хозяин квартиры.

У PWA есть реальные потолки:

- нет такой свободы по платформенным API, как у нативного клиента;

- фон, пуши и некоторые сценарии мобильной жизни работают хуже, чем

хотелось бы;

- нет нормальных VoIP-пушей (звонки работают только когда приложение

открыто), нет нормальной интеграции со списком вызовов телефона;

- по голой производительности натив его обгоняет.

И, да, Service Workers иногда ведут себя как подростки в пубертате, а iOS местами режет фоновую жизнь PWA так, будто лично обиделась на идею веб-клиента. Я в курсе. Выживаем с тем, что есть.

Но для моей задачи PWA дал главное: скорость эволюции. А в экспериментальном проекте это иногда важнее, чем стерильная идеология.

И да, работает эта штука подозрительно хорошо. Лучше, чем я ожидал, если честно.

Зачем вообще писать еще один мессенджер, когда мир и так ими забит

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

Потому что я люблю контролировать инфраструктуру, а не молиться на чужую.

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

Потому что мне скучно.

Да, это тоже важная часть правды. На обычной работе мозг периодически начинает зевать от предсказуемости. А когда ты в одиночку пытаешься собрать живой real-time-сервис, где есть сессии, доставка сообщений, поиск, синхронизация состояния, очереди и weird cases мобильной сети —

то зевота быстро заканчивается.

То есть да: это учебный проект. Но из тех учебных проектов, которые в какой-то момент говорят: «всё, детский сад закончился, теперь давай как взрослые».

Где начинаются не разговоры про highload, а настоящая инженерная жизнь

Пока не собираешь такое сам, кажется, что мессенджер — это просто чатик.

Ну текстик, ну websocket, ну кнопка «отправить», господи. А потом начинается взрослая часть спектакля.

1. Сообщение должно не просто уйти, а дойти правильно

Самая скучная и самая дорогая ошибка — считать, что «отправил» значит

«доставил».

Нет. В реальной жизни между клиентом, сетью, сервером и хранилищем полно мест, где всё может стать интересно:

- клиент послал пакет, но сеть моргнула;

- сервер принял, но клиент не получил подтверждение;

- клиент решил, что ничего не дошло, и отправил повторно;

- внезапно у тебя уже не просто доставка, а идемпотентность,

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

дублями.

И это только один кусок.

2. Порядок сообщений — штука гораздо более капризная, чем кажется

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

Инженерная реальность куда веселее:

- локальный optimistic update на offline-first клиенте хочет быть

быстрым;

- серверная истина хочет быть правильной;

- база хочет жить в своей временной линии;

- несколько устройств одного пользователя могут в это время смотреть на

мир разными глазами.

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

3. Race condition — это когда баг уже произошел, но ты еще не знаешь, где именно тебя унизили

Race conditions — мой любимый жанр инженерного фольклора. Это когда всё прекрасно, пока ты смотришь. И ломается ровно в тот момент, когда отвлекся налить кофе.

Условно:

- один поток думает, что пользователь в онлайне;

- второй уже считает, что он отвалился;

- третий в это время честно пишет новое состояние;

- четвертый с невинным лицом отдает клиенту вчерашнюю правду.

А потом ты сидишь и объясняешь себе, почему в 99.7% случаев всё идеально, а в оставшихся 0.3% система внезапно начинает разговаривать голосами. А когда еще и пытаешься заставить работать реалтайм систему еще в кластере, то все сложности возводятся в квадрат.

4. Любая «маленькая фича» очень быстро приходит за твоей архитектурой с ножом

Захотел новую механику? Например, необычную резервацию UIN еще до регистрации? На бумаге выглядит забавно. На бэкенде начинается вечеринка:

- появляется состояние для еще не существующего пользователя;

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

- нужно думать о TTL, освобождении, гонках, повторных запросах и кривом клиентском поведении;

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

И вот так почти всё. В продуктовых презентациях фича может подаваться как «геймификация входа». В серверной реальности — «еще один слой боли, зато красиво».

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

Пока данных мало, Postgres прощает тебе оптимизм. Потом история растет, индексы начинают намекать, что дружба дружбой, а latency по расписанию, и любой неаккуратный запрос внезапно становится личным конфликтом с CPU.

И тут выясняется, что в реальном мессенджере мало просто «хранить сообщения». Нужно еще:

- быстро искать;

- не ломать горячий путь доставки;

- не превращать сервер в печку под нагрузкой;

- думать наперед, где потом начнется горизонтальное масштабирование, а

где сначала будет боль, потом переписывание, потом снова боль.

Чтобы это не выглядело как очередная литература про «сложности highload», вот живой пример. Это кусок поиска по групповым сообщениям в моем бекенде: с проверкой доступа, выборкой только текстовых сообщений и сортировкой по релевантности.

Под этот запрос у меня лежит не молитва, а вполне конкретная опора: partial GIN index по выражению`(content->>'text') gin_trgm_ops`.Иначе такая красота очень быстро превращает сервер в отопление стойки за счет тупого перебора JSONB.

А вот так тот же самый функционал очень часто пишут новички — вроде работает, пока данных смешно мало:

Проблема тут не в эстетике. Проблема в том, что верхний вариант ищет по нужному полю, умеет нормально ранжировать результат и опирается на индекс. Нижний часто уезжает в тяжелый scan по JSONB, ищет по строковому представлению всего объекта и под нагрузкой начинает жечь CPU просто потому, что автору было лень договориться с базой по-хорошему.

На реальном объеме истории в проде разница здесь может быть уже не в процентах, а на порядок и выше. То есть это очень быстро превращается не в «чуть-чуть быстрее», а в 10x+, а дальше всё зависит от размера истории, доли текстовых сообщений, партиций и того, насколько сильно вы любите мучить PostgreSQL.

И это еще сравнительно добрый пример. В по-настоящему наивной реализации люди (да часто и нейросети в руках новичков) иногда забывают не только про индекс и ранжирование, но и про нормальную проверку членства в чате — и тогда у тебя получается не просто медленный поиск, а еще и билет в секцию «как я сам себе устроил privacy-инцидент».

6. Очереди, ретраи и backpressure — это не украшения, а повод спать чуть спокойнее

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

То есть нужны:

- очереди (Kafka, или что вы там предпочитаете);

- повторные попытки (retry-логика);

- backpressure;

- вменяемая реакция на временную деградацию (graceful degradation);

- circuit breaker чтобы какой-нибудь маленький и вроде бы некритичный сервис не мог каскадно положить бы всю инфраструктуру;

- архитектура, которая умеет признавать, что мир не идеален.

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

Интерфейс я подсматривал у Telegram. И да, специально

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

Если человек открывает новый мессенджер, он хочет быстро разобраться и написать сообщение. Ему не нужен артхаус-квест «найди кнопку отправки, автор так видит».

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

Моя любимая инженерная шалость: UIN-рулетка до регистрации

Тут я, конечно, немного похулиганил.

Я сделал резервацию UIN еще до этапа регистрации. То есть можно зайти, поймать красивый номер, а уже потом решить, нужен тебе вообще этот зоопарк или нет.

С человеческой стороны это фан, ностальгия и немного ICQ-вайба.

С серверной стороны это пачка вопросов:

- как хранить состояние для «почти-пользователя»;

- как не раздать красивые номера слишком щедро;

- как не дать мимо проходящему ботнету выгрести пул;

- как освобождать резервы и не плодить мусор;

- как не застрелить логическую целостность ради красивой игрушки.

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

Про безопасность — без дешевой магии и без сказок для инвестора

Нет, я не изобретал свою криптографию. Я вообще считаю, что желание «сейчас быстренько придумаю свой защищенный протокол» должно автоматически активировать тревожную сирену. Да, создать защищенный протокол возможно, но это сложнее и дольше чем кажется из-за необходимости учета множества edge-cases; и в реальности сделанные на коленке протоколы чаще ненадежны, и, что еще хуже, об их уязвимостях могут знать лишь немногие пронырливые и порой не самые добросовестные люди.

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

- транспорт закрыт современным TLS 1.3 (который на текущий момент, март 2026, взломать прямым криптографическим методом практически невозможно);

- клиент живет как PWA в браузерной песочнице, какая уже сама по себе имеет ряд уровней защиты;

- поверх этого я стараюсь не творить откровенной дичи;

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

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

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

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

Почему я вообще тащу это именно на TProger

Потому что TProger — это место, где тексту мало быть наглым. Здесь за дерзость прощают только одно: если под ней есть мясо.

А у меня как раз тот случай, когда мне интереснее не «собрать лайки», а получить нормальную техническую реакцию:

- где архитектура выглядит спорно;

- где логика доставки сообщений может начать чудить;

- где PWA упрется в реальные ограничения платформы;

- где резервация UIN создает лишнюю поверхность атаки;

- где под нагрузкой начнет хрустеть то, что в одиночных тестах ведет себя прилично;

- где в протоколе, порядке событий, ретраях или кешировании я недооценил крайний случай.

Мне не нужен хор в духе «вау, круто».

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

Вот ему я и пишу.

Что я от вас хочу

По сути — честной драки, но умной.

- Хотите проверить, как это переживает плохую сеть — отлично.

- Хотите посмотреть, как выглядит поведение в edge-cases — вообще прекрасно.

- Хотите понять, насколько легко читается логика протокола — давайте.

- Хотите найти баг в порядке сообщений, в кеше, в подтверждениях, в резервации UIN, в клиентском поведении — тем более.

Только давайте без детского жанра «я что-то молча сломал и ушел сиять в закат». Если найдете слабое место, баг, странность, дыру, подозрительный сценарий или красивый способ заставить систему вести себя не так, как я планировал, — пишите.

Мне это полезнее, чем аплодисменты.

И да: я не заявляю, что построил новый и единственно верный мессенджер.

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

Что можно делать прямо сейчас

- Если вы параноик или устали от мейнстрима и навязанных решений — держите это как запасной канал связи.

- Если вы соскучились по временам красивых UIN — приходите ловить UIN-номер.

- Если вы любите sniff, разбор трафика и сетевые игры — смотрите что идет по проводу.

- Если у вас профессиональная привычка первым делом искать edge-cases — вот, собственно, ради вас всё это и принесено.

И если что-то положите, вскроете или красиво разберете — пришлите детали. Я не обидчивый. Я, строго говоря, именно ради этого и открыл двери.

Что дальше

Планы без корпоративной шелухи, но вполне понятные:

- дальше допиливаю PWA-версию;

- нативные Android и iOS-клиенты — в планах, но пока не в приоритете;

- клиентскую часть, вероятно, позже открою, когда там станет меньше творческого барокко;

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

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

Итог

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

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

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

Если хотите просто еще один канал связи — пожалуйста.

Если хотите посмотреть и проверить, насколько крепок мой цифровой эксперимент, — тем более пожалуйста.

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

Добро пожаловать.

Посмотрим, кто кого утомит первым: вы — мой сервер, я — ваши попытки его удивить, или реальность — нас обоих.

PS:

Меня там можно найти по нику IGRYM или по UIN 10001. Также есть внутренняя группа для первых пользователей (Early Birds, доступна на экране списка чатов через «+» вверху экрана)

Ссылки:

- Приложение: https://beta.plumb-app.ru/

- Телеграм-канал с новостями проекта: https://t.me/plumb_channel

- Телеграм-группа обсуждения: https://t.me/plumb_group

В этой статье разберём весь путь письма — от SMTP-команд до проверки подлинности через DKIM, SPF и DMARC. Покажем на конкретном примере: Джон (john@gmail.com) отправляет письмо Кевину (kevin@yahoo.com).

— Письмо передаётся между серверами по протоколу SMTP (порт 25) через простые текстовые команды

— Почтовый сервер находит адресата через DNS-запрос MX-записи домена получателя

— Подлинность отправителя проверяется тремя механизмами: DKIM (цифровая подпись), SPF (проверка IP) и DMARC (политика при сбоях)

— Получатель забирает письма из ящика через IMAP или POP3 — это отдельные протоколы

Базовая терминология

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

• SMTP (Simple Mail Transfer Protocol) — протокол передачи почты, работающий поверх TCP. Используется для отправки и доставки писем между серверами
• Почтовый сервер (Mail Server) — серверное приложение, которое принимает, хранит, проверяет и доставляет электронные письма
• MX-запись (Mail Exchange Record) — DNS-запись, содержащая доменное имя почтового сервера для данного домена
• MTA (Mail Transfer Agent) — компонент сервера, отвечающий за передачу писем между серверами (например, с сервера Gmail на сервер Yahoo)
• DKIM (DomainKeys Identified Mail) — механизм аутентификации на основе цифровой подписи
• DMARC (Domain-based Message Authentication, Reporting, and Conformance) — политика, определяющая действия при сбое аутентификации
• SPF (Sender Policy Framework) — метод аутентификации, проверяющий, имеет ли IP-адрес отправителя право отправлять почту от имени домена

Не страшно, если не всё понятно сразу — каждый термин подробно разобран ниже.

Общая картина: как письмо проходит путь от отправителя к получателю

Этот раздел — краткий обзор всего процесса. Детали каждого шага разобраны дальше.

Почтовый сервер — это серверное ПО, которое принимает, ставит в очередь, отправляет и получает письма. Если вы шлёте письмо с john@gmail.com на kevin@yahoo.com, сервер Gmail примет письмо и передаст его серверу Yahoo.

Допустим, есть два друга:

• Джон (john@gmail.com)
• Кевин (kevin@yahoo.com)

Почему Yahoo? Потому что получатель использует Yahoo (kevin@yahoo.com).

Дальше всё берёт на себя сервер Yahoo Mail, и письмо попадает во входящие Кевина.

Архитектурная диаграмма

Разбор по шагам

Теперь разберём каждый этап подробно. Стоит отметить, что описан наиболее распространённый сценарий работы почтовых серверов. У разных компаний реализация может отличаться, но базовая идея одна и та же.

SMTP: как письмо попадает на сервер

Simple Mail Transfer Protocol определяет, как письмо передаётся на почтовый сервер. Для передачи почты между серверами SMTP использует порт 25. Для отправки от клиента к серверу (submission) применяются порты 587 (STARTTLS) или 465 (implicit TLS). Подключиться к серверу можно через утилиту telnet. Вот что вы увидите при подключении к серверу Gmail:

После подключения мы можем отправлять серверу команды:

HELO / EHLO

Команда для приветствия — вы представляетесь почтовому серверу. В ответ сервер отправляет приветствие:

MAIL FROM

Сообщает серверу, кто отправляет письмо. Сервер отвечает 250 2.1.0 OK:

RCPT TO

Указывает, кому адресовано письмо. Сервер снова отвечает OK:

DATA

Сервер сообщает клиенту, что можно начинать передачу тела письма:

Затем отправляются данные самого письма:

Точка (.) на отдельной строке означает «конец сообщения». Сервер отвечает подтверждением (Accepted):

QUIT

Прощаемся с сервером:

Вот так письмо передаётся на почтовый сервер по протоколу SMTP. Теперь разберём, что происходит дальше.

Хранение

Письмо теперь хранится на сервере Gmail, и сервер извлекает из него метаданные: FROM, TO и другие заголовки.

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

Очередь

Обратите внимание: когда SMTP-сервер принял наше письмо, он ответил «queued» (поставлено в очередь), а не «sent» (отправлено). Письма поступают в огромных объёмах, и отправить их мгновенно невозможно. Поэтому почтовые серверы ставят их в очередь и отправляют по одному. В случае ошибки письмо может быть перемещено в очередь повторных попыток.

DNS и DNS-записи

Для отправки писем нужно доменное имя (часть после @ в адресе). В конечном счёте любой сервер — это IP-адрес, но запоминать IP неудобно. Для этого и существует DNS.

DNS (Domain Name System) преобразует доменные имена (например, gmail.com) в IP-адреса. Именно поэтому можно подключиться и через telnet <ДОМЕН>, и через telnet <IP>.

DNS-запись — это запись, опубликованная в системе доменных имён, содержащая данные, видимые из интернета. Запомните это — DNS-записи играют ключевую роль в аутентификации email.

MX-запись

Ранее мы говорили, что почтовые серверы передают письма друг другу через SMTP-соединение на порту 25. Но как серверы узнают, на какой IP-адрес или домен отправлять письмо?

Здесь на сцену выходит MX-запись (Mail Exchange). Каждый домен публикует MX-запись в DNS, и другие почтовые серверы запрашивают её. Проверить MX-запись любого домена можно, например, на MXToolbox.

Вот MX-записи почтовых серверов Gmail:

Аутентификация

Мы только что поставили письмо в очередь на почтовом сервере — и для этого не потребовалось никакой аутентификации. Так как же работает проверка подлинности? Здесь в игру вступают DKIM и SPF.

DKIM: цифровая подпись письма

DKIM — это механизм аутентификации на основе пары открытого и закрытого ключей. Отправляющий сервер подписывает письмо, а принимающий — проверяет подпись. В нашем случае отправитель — сервер Gmail, получатель — сервер Yahoo.

1. Письмо поступает на Gmail через SMTP
2. Gmail сохраняет его
3. Gmail вычисляет хеш заголовков и тела письма, подписывает его закрытым ключом и добавляет заголовок DKIM-Signature
4. Когда письмо доставляется на сервер-получатель, тот расшифровывает подпись открытым ключом, вычисляет хеш самостоятельно и сравнивает результаты
5. Если проверка не пройдена — письмо не доставляется

Вот как выглядит заголовок DKIM-Signature:

Но откуда получатель знает открытый ключ отправителя?

Снова на помощь приходят DNS-записи. Домен отправителя (gmail.com в нашем примере) публикует DNS-запись с открытым ключом и селектором. Селектор нужен для выбора нужного ключа, если у сервера их несколько.

Вот как выглядит DNS-запись с публичным ключом DKIM:

Таким образом, сервер Yahoo запрашивает DNS-записи для gmail.com и получает открытый ключ для проверки подписи.

SPF: проверка IP-адреса отправителя

Эта проверка происходит на стороне получателя. SPF определяет, имеет ли данный IP-адрес право отправлять почту от имени домена.

Когда Gmail передаёт письмо john@gmail.com на kevin@yahoo.com, он открывает SMTP-соединение с сервером Yahoo. В этот момент Yahoo знает, с какого IP пришло соединение (это IP сервера Gmail).

Yahoo извлекает домен отправителя (gmail.com) из заголовка MAIL FROM и запрашивает DNS-запись SPF, которая выглядит так:

В записи перечислены IP-адреса. Если IP, с которого пришло письмо, присутствует в этом списке — письмо принимается. Если нет — отклоняется или помечается как спам.

DMARC: что делать, если проверка не пройдена

DMARC — это не метод аутентификации, а политика, которая определяет, что делать, если DKIM или SPF не прошли проверку.

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

Финальный этап: доставка

Если все проверки пройдены, сервер Yahoo Mail сохраняет письмо в хранилище — будь то файловая система или распределённое хранилище. Письмо попадает во входящие Кевина.

Как мы видим письма?

Закономерный вопрос: как мы видим письма, которые хранятся на почтовом сервере? Для этого используются два других протокола:

• IMAP — синхронизация почтового ящика (письма остаются на сервере)
• POP3 — загрузка писем на устройство

Эти протоколы — тема для отдельной статьи.

Перевод и адаптация статьи «How Email Actually Works» из блога Sushant Dhiman. Читайте также: DNS для начинающих, как работает интернет.

Во время Супербоула компания показала 30-секундный ролик, посвященный спутниковому интернету Starlink. Ранее ни одна из компаний Илона Маска напрямую не размещала рекламу на этом событии.

Реклама без Маска, но с Артуром Кларком

Ролик построен на архивной аудиозаписи выступления писателя-фантаста Артур Кларк. На фоне его слов показывают посадки ускорителей Falcon 9 и Starship, а также работу Starlink в удаленных и труднодоступных регионах.

Основной посыл простой: «быстрый и доступный интернет — в любой точке мира».

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

Почему это важно именно сейчас

Выход SpaceX на Супербоул выглядит не случайным. По данным западных СМИ, компания готовится к публичному размещению акций, которое может стать одним из крупнейших IPO в истории — с потенциальной оценкой до $1,5 трлн.

Контекст усиливает и недавнее заявление Маска об объединении SpaceX с его ИИ-стартапом xAI.

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

Сколько стоит такой выход

По данным телеканала NBCUniversal, 30 секунд рекламы на Супербоуле в этом году обходились брендам в $8–10 млн. Для SpaceX это первый подобный расход.

Starlink как главный двигатель роста

Выбор Starlink в качестве героя ролика тоже показателен. Именно спутниковый интернет сейчас является самым «гражданским» и массовым продуктом SpaceX.

В компании ранее сообщали, что сервисом пользуются около 9 млн клиентов в 155 странах, а на орбите уже работает более 9000 спутников.

Угрозы в цифровом пространстве реальны и многообразны. Это ситуации, с которыми ребенок может столкнуться напрямую:

• Кража личных данных и денег. Мошенники могут выманить у ребенка или через его аккаунт конфиденциальную информацию родителей.
• Кибербуллинг (травля в сети). Оскорбительные сообщения, распространение слухов или неприятных фотографий в чатах и соцсетях.
• Встречи с опасным контентом. Столкновение с материалами, предназначенными для взрослых, или с пропагандой деструктивного поведения.
• Взлом аккаунтов. Потеря доступа к своим страницам в соцсетях, игровым аккаунтам из-за слабых паролей или хитрости злоумышленников.

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

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

Личные данные — чем нельзя делиться?

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

Что относится к личным данным:

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

Научите ребенка: «незнакомец в сети = незнакомец на улице». Эта аналогия важна для понимания. В реальной жизни ребенок не станет рассказывать незнакомому человеку на остановке свой адрес, график дня или показывать документы. Ровно с такой же осторожностью нужно вести себя в интернете. Человек по ту сторону экрана, даже если он представляется ровесником из другого города или добрым другом, без видеосвязи и личной встречи остается незнакомцем. Его настоящие имя, возраст и намерения неизвестны.

Почему нельзя публиковать определенную информацию:

1. Фотографии билетов (авиа, железнодорожных, на концерт). На штрих-коде или QR-коде билета часто закодированы персональные данные (ФИО, иногда паспортные данные). Эту информацию можно считать со снимка. Злоумышленник может использовать эти данные для мошеннических действий или, например, чтобы аннулировать или переоформить билет.
2. Фотографии документов. Это прямой ключ к краже личности. С помощью данных документа мошенники могут попытаться оформить кредит, получить доступ к аккаунтам или совершить другие действия от вашего имени.
3. Фотографии дома, школы, машины родителей с номерами. Такие снимки делают ребенка и его семью «видимыми» и узнаваемыми в реальном мире. В сочетании с информацией о распорядке дня это создает риск. Фотография подъезда или окна своей комнаты с видом из него — это конкретная привязка к месту жительства.
4. Геометки в реальном времени. Публикация фотографии из парка с отметкой «Гуляю сейчас здесь» или регулярный check-in в одной и той же спортивной секции показывает не только место, но и привычки. Это информация, которой без необходимости не нужно делиться с широким кругом людей.

Введите правило безопасности в сети интернет для ребенка: прежде чем что-то опубликовать — фотографию, пост или комментарий с личной информацией — нужно спросить себя: «я готов(а), чтобы это увидел и узнал любой человек, в том числе незнакомый?». Если ответ «нет» или «не уверен(а)», публиковать не стоит. Лучшая тактика — делиться такой информацией только в закрытых переписках с проверенными друзьями и всегда ставить в известность родителей, если кто-то в сети настойчиво просит личные данные.

Создаем и храним пароли

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

Надежный пароль — основа кибербезопасности не только детей, но и взрослых

Как создать надежный пароль, который будет сложно подобрать как человеку, так и специальной программе:

1. Используйте длинную фразу (пассфразу). Чем длиннее пароль, тем он надежнее. Вместо короткого слова используйте несколько слов, которые просто запомнить именно вам. Например: «НашКотЛюбитСыр123». Это уже значительно лучше, чем просто «кот». Еще один прием — взять первые буквы слов и знаки препинания из пассфразы. Так из фразы «Я_Учусь_В_5_Б_,_А_Моя_Сестра_В_9_Д_!» получаем пароль «ЯУВ5Б,АМСВ9Д!» — он выглядит бессмысленным набором символов, но запомнить его легко.
2. Усложняйте конструкцию. Добавьте к своей фразе заглавные буквы, цифры и специальные символы (например, !, @, #, $, %). Превратите простую фразу в сложный код. Пример: «Кот!Любит#Сыр123».
3. Избегайте очевидного. Не используйте:

• личную информацию (имя, фамилию, дату рождения, имя питомца).
• простые последовательности букв и цифр на клавиатуре («123456», «qwerty»).
• одно и то же слово, повторенное несколько раз.

Что такое двухфакторная аутентификация (2FA)?

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

Как работает 2FA:

1. Вы вводите логин и пароль на сайте (это первый фактор — пароль, который вы знаете).
2. Сайт запрашивает второй код. Этот код генерируется в мобильном приложении (например, Google Authenticator или Яндекс.Ключ) или приходит в SMS (менее безопасный вариант, но он лучше, чем ничего).
3. Вы вводите этот одноразовый код (это второй фактор).

Даже если кто-то узнает пароль, без доступа к вашему телефону он не сможет войти в аккаунт. Включить 2FA можно в настройках безопасности большинства важных сервисов: почты, соцсетей, игровых платформ.

Почему один пароль для всего — плохая идея?

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

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

Что такое фишинг?

Фишинг — это один из самых распространенных методов обмана в интернете. Его цель — заставить человека добровольно раскрыть свои личные данные: логины, пароли, данные банковской карты. Название происходит от английского слова «fishing» (рыбалка), и принцип действительно похож: злоумышленники забрасывают «удочку» — поддельное сообщение, — надеясь, что кто-то «клюнет».

Если раньше мошенники рассылали истории про принцев из Саудовской Аравии, которым срочно нужна помощь в обмен на деньги, то сегодня они притворяются службой поддержки известной игры, популярной социальной сети, онлайн-магазином или даже нашим другом или полицейским. Форма изменилась, но суть осталась прежней: нас обманом выманивают, чтобы подцепить на «крючок».

Как отличить фишинг от настоящего сообщения?

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

1. Срочность и давление. Сообщение создает искусственное чувство паники или жадности: «Ваш аккаунт будет удален в течение часа!», «Вы выиграли приз! Кликните сюда, чтобы получить его сейчас, пока предложение действительно!», «Ваша карта заблокирована! Немедленно подтвердите данные». Цель — заставить действовать быстро, не раздумывая и не проверяя информацию.
2. Ошибки в тексте. Официальные письма от крупных компаний тщательно проверяются. Грамматические ошибки, странные формулировки, неправильные названия сервисов — явный признак подделки. Например, письмо якобы от «VKотнтаке» или «Steanm Community».
3. Подозрительные ссылки. Это самая опасная часть фишингового сообщения. Ссылка может выглядеть почти как настоящая, но при внимательном рассмотрении можно заметить подмену. Например:

• vk-подарки.ru вместо официального vk.com
• steamcommunity-gifts.com вместо steamcommunity.com
• ссылка, замаскированная под кнопку «Проверить» или «Получить подарок».
• Важное правило кибербезопасности для детей: всегда наводить курсор на ссылку (не кликая), чтобы увидеть ее настоящий адрес во всплывающей подсказке в углу браузера!

1. Запрос конфиденциальных данных. Ни одна настоящая служба поддержки не будет писать вам в личные сообщения с просьбой прислать пароль, полный номер карты, CVV-код (три цифры на обороте) или код из SMS. Для решения проблем у них есть официальные, защищенные формы внутри вашего личного кабинета.

Что делать при получении подозрительного сообщения?

1. Не кликать — самое главное правило безопасности в интернете и для детей, и для взрослых. Не нажимать на ссылки и не скачивать вложения (файлы, картинки) из такого сообщения. Даже простой клик может привести на вредоносный сайт или запустить скрытую загрузку вируса. Кстати, многие «бесплатные» PDF-мануалы, которые в интернете предлагают скачать на каждом шагу, тоже содержат вредоносный код, предназначенный для кражи данных.
2. Не отвечать. Не вступать в диалог, не пытаться доказать мошеннику, что вы его раскусили, и тем более не отправлять запрошенные данные. Любой ответ сигнализирует, что ваш аккаунт активен и с вами можно продолжать работу.
3. Ребенок должен рассказать взрослым. Если сообщение вызывает сомнения, самое разумное — немедленно показать его родителю или другому доверенному взрослому. Вместе вы проверите отправителя, и если, например, выяснится, что взломан аккаунт друга, вы сможете оперативно связаться с ним и предупредить.

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

Общение онлайн и личные границы

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

Что такое кибербуллинг и как правильно реагировать на него?

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

Алгоритм действий для ребенка, столкнувшегося с травлей:

1. Не отвечать и не вступать в перепалку. Цель обидчика — вызвать реакцию, вывести из равновесия, получить эмоции. Безответность лишает его этой цели. Нельзя поддаваться на провокации.
2. Сделать скриншот. Необходимо сохранить доказательства: сделать снимок экрана с оскорбительным сообщением, записью в чате или комментарием. Это важно для дальнейших действий. Скриншот — это фиксация факта.
3. Использовать технические инструменты блокировки.

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

1. Рассказать родителю или доверенному взрослому. Это самый важный шаг. Ребенку может быть стыдно или страшно говорить о травле, но такая проблема всегда требует вмешательства. Нужно объяснить, что обращение за помощью — это разумный поступок и признак силы, а не слабости. Взрослый (родитель, учитель) сможет эмоционально поддержать, помочь с настройками приватности и, при необходимости, обратиться в правоохранительные органы.

Правила безопасного общения в интернете для детей

Основные правила безопасности в интернете при общении онлайн:

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

Конфиденциальность переписки

Личная переписка ребенка тоже должна подчиняться правилам кибербезопасности:

1. Постоянство цифровой информации. То, что отправлено в сообщении, почти невозможно полностью отозвать или удалить у получателя. Скриншот переписки может быть использован против отправителя позже, если отношения с собеседником испортятся.
2. Круг доверия. Очень личную информацию (семейные проблемы, интимные фото или переписки, пароли) нельзя отправлять даже близким друзьям в цифровом виде. Технический сбой, потеря телефона, взлом аккаунта друга — все это может привести к утечке данных.
3. Введите правило безопасности в интернете для ребенка: Если информация слишком личная, и ее огласка может причинить боль или вред, ее не стоит доверять цифровому каналу. Лучше обсудить такие темы при личной встрече или по телефону. В переписке стоит делиться только тем, чем ты спокойно готов поделиться публично.

Самые распространенные киберугрозы

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

«Бесплатный» сыр в мышеловке: вирусы и вредоносный софт

Ребенок ищет способы бесплатно получить платную игру, программу, внутриигровую валюту или взломанный аккаунт. Он переходит на сомнительный сайт или скачивает файл из непроверенного источника. Вместе с желаемым контентом он получает вредоносную программу. Также вирус может прийти в виде вложения в сообщении от взломанного аккаунта друга («Посмотри это видео!»).

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

Решение:

• Установить и обновлять антивирус. Объясните ребенку, что для безопасности в сети интернет антивирус обязателен. Важно, чтобы он был лицензионным и регулярно обновлялся.
• Четкий запрет на установку ПО без согласия взрослого. Ребенок должен спрашивать разрешения у родителей перед установкой любой новой программы или игры, особенно если источник вызывает сомнения.
• Использовать легальный контент. Объясните важность уважения к труду разработчиков. Платформы с официальными играми и программами (например, Steam, официальные магазины приложений) безопаснее пиратских сайтов.

«Ты выиграл …!»: ловушки мошенников

Это разновидность фишинга, ориентированная на детскую аудиторию и ее интересы. Сценарии могут быть разными:

• Фейковые конкурсы от блогеров или игр: «Поздравляем! Ты выиграл новый iPhone в розыгрыше! Перейди по ссылке и введи данные карты родителей для подтверждения доставки».
• Просьба о помощи от «друга». Мошенник пишет со взломанного аккаунта одноклассника: «Срочно! У меня проблемы, одолжи 500 рублей на карту, завтра отдам». Или просит передать код из SMS.
• Фейковые покупки и продажи. Предложение купить редкий игровой предмет по очень низкой цене или, наоборот, просьба «временно» передать дорогой аккаунт для «прокачки».

Решение:

• «Бесплатного не бывает» — это еще одно важное правило безопасности детей в сети интернет. Любое неожиданное супервыгодное предложение, особенно с просьбой оплатить «доставку» или «комиссию», — это обман.
• Обязательная проверка информации. Если друг просит деньги, нужно связаться с ним другим способом (позвонить, встретиться) и уточнить.
• Немедленное обращение к взрослому. Любое предложение, связанное с деньгами, подарками или передачей данных аккаунта, нужно сразу обсудить с родителями.

Цифровой след — это навсегда

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

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

Решение:

• Объясните ребенку важный принцип безопасности в интернете: «Выложил — значит, показал всему миру». Перед публикацией нужно спросить себя: «Я буду не против, если это увидят мои родители, учителя или я сам через 5-10-15 лет?».
• Продуманность контента. Стоит избегать публикации откровенных, смущающих или агрессивных материалов. Цифровая репутация может повлиять на поступление в вуз или прием на работу в будущем.

Троллинг и буллинг в интернете

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

Решение:

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

Опасные знакомства: анонимность как маска

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

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

Решение:

• Введите для ребенка жесткое правило безопасности в интернете: общаться как с друзьями можно только с теми, кого лично знаешь в реальной жизни. Друзья друзей или «хорошие парни из другого города» — это незнакомцы.
• Абсолютный запрет на личные встречи с интернет-знакомыми без разрешения и сопровождения родителей. Никаких исключений.
• Открытый диалог с ребенком: он должен знать, что может прийти к вам с любой проблемой (например, «меня шантажируют из-за фото»), не боясь осуждения, и вместе вы найдете выход, вплоть до обращения в полицию.

Реклама. Рекламодатель ООО «Пиксель.Стади», ИНН 5074078988, erid: 2W5zFK2WjKn

Зачем детям 3D-моделирование в Blender или Tinkercad

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

Но зачем это нужно? Помимо очевидного «это интересно», 3D-моделирование — это мощный инструмент для развития мышления и творческих способностей:

Пространственное мышление: видеть мир в объеме

Креативность: от идеи к осязаемому результату

Цифровые навыки: владение языком будущего

Умение работать в 3D-среде — это уже не просто дополнительный кружок, а базовая грамотность нового времени. Ребенок осваивает логику цифровых инструментов, понимает принципы построения виртуальных объектов, учится технической терпеливости и точности. Эти компетенции становятся все более востребованными в самых разных областях.

Tinkercad для детей — цифровой конструктор для первых открытий

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

Например, чтобы создать модель домика, нужно взять куб (это основа), поставить на него треугольную призму (крыша), а затем с помощью инструмента «Отверстие» вырезать в кубе дверь и окна, используя другие кубы и цилиндры. Этот принцип «вычитания» одного объема из другого или их «сложения» — ключевой для понимания логики 3D.

Панель инструментов Tinkercad минималистична и визуально понятна. Все основные действия — взять фигуру, повернуть ее, изменить размер, сгруппировать с другой — выполняются мышкой с помощью понятных «точек захвата» и плоских кнопок. Рабочая область — это виртуальный стол, на котором можно свободно вращать камеру, чтобы осмотреть объект со всех сторон. Знакомый с играми или другими конструкторами ребенок освоит интерфейс Tinkercad за 10-15 минут.

Главные преимущества:

• Нулевой порог входа. Не нужно ничего скачивать и устанавливать. Достаточно компьютера с выходом в интернет и современным браузером.
• Бесплатность. Полный функционал платформы от компании Autodesk доступен свободно после простой регистрации.
• Мгновенная отдача. Уже на первом занятии ребенок создает свой первый объект и испытывает восторг от того, что эту модель можно сделать настоящей, отправив ее на 3D-печать.
• Идеальная база для понимания 3D-логики. Платформа блестяще учит основам: что такое оси координат (X, Y, Z), как работает объем, что такое группировка объектов. Это азбука, без которой сложно двигаться дальше.

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

Tinkercad подойдет для детей от 6 лет, делающих самые первые шаги в 3D, а также для любого новичка, чья цель — быстро и весело научиться основам, чтобы создавать функциональные модели для 3D-печати (игрушки, держатели, сувениры), простые макеты или архитектурные формы.

Если ребенок с удовольствием собирает модели в Tinkercad, его интерес можно развить и углубить. В этом поможет наш курс по 3D-моделированию для детей в Tinkercad, где эта программа становится полноценным инструментом для реализации серьезных проектов. Под руководством нашего педагога дети не просто комбинируют кубики, а учатся профессиональному подходу: от эскиза и технического расчета пропорций до подготовки сложной модели для печати. К концу курса каждый ученик создаст собственное портфолио из готовых работ — например, многосоставную головоломку, действующий механический механизм (вроде шарнирного робота) или детализированный архитектурный макет.

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

Blender для детей — цифровая студия для будущих профессионалов

Если Tinkercad можно сравнить с удобным конструктором, то Blender — это целая мастерская скульптора, инженера и режиссера под одной крышей. Это не просто программа для 3D-моделирования, доступная детям, это — полноценная профессиональная студия для создания трехмерной графики, которая при этом остается абсолютно бесплатной. Здесь нет готовых кубиков — здесь есть цифровая глина, из которой можно вылепить что угодно, от ювелирного украшения до целой анимированной сцены из фэнтези-мира.

Blender — это универсальный комплекс, охватывающий все этапы производства 3D-контента. Его ядро — продвинутое полигональное моделирование, где объекты создаются из сетки-«каркаса» (полигонов), вершины которого можно двигать, формируя любые, даже самые плавные и сложные формы. Для создания органических объектов (персонажей, существ) есть инструмент скульптинга, имитирующий работу с настоящей глиной: можно «вдавливать», «вытягивать» и «сглаживать» поверхность.

Но на этом возможности не заканчиваются. В Blender можно:

• Текстурировать и назначать материалы (сделать объект блестящим, матовым, прозрачным).
• Выстраивать освещение и визуализировать (создавать фотореалистичные или стилизованные «снимки» — рендеры).
• Анимировать объекты и персонажей, заставляя их двигаться.
• Монтировать видео, добавлять спецэффекты и даже работать со звуком.

Первое впечатление от интерфейса Blender может озадачить ребенка: множество панелей, вкладок и сотни кнопок. Это закономерно — так выглядит профессиональный инструмент. Однако это не хаос, а четко структурированная система. Основной секрет комфортной работы — в горячих клавишах. Опытные пользователи управляют программой в основном с клавиатуры, что делает процесс очень быстрым. Но для новичка это значит, что первые уроки будут посвящены не столько творчеству, сколько знакомству с этой логикой и основными комбинациями (например, G — переместить, R — повернуть, S — масштабировать). После этого барьер входа резко снижается.

Главные преимущества:

• Безграничные творческие возможности. Ограничением в Blender является только фантазия ребенка. Хочет создать робота с идеально ровными гранями? Пожалуйста. Мечтает вылепить фантастического дракона? И это возможно.
• Промышленный стандарт в индустрии. Навыки работы в Blender для ребенка — это серьезная строка в будущем портфолио. Программа активно используется независимыми студиями в геймдеве, анимации, рекламе и дизайне.
• Развитие комплексного, глубокого мышления. Работа над проектом учит видеть процесс от начала до конца: концепт → моделирование → текстурирование → постановка света → финальный рендер. Это воспитывает терпение, внимание к деталям и системный подход.

Также важно учитывать требования к уровню подготовки ребенка и технике:

• Высокий порог входа. Чтобы начать создавать что-то осмысленное, потребуется пройти этап изучения интерфейса и базовых инструментов. Это требует усидчивости и готовности к тому, что не все будет получаться сразу.
• Требования к компьютеру. Для комфортной работы, особенно при рендеринге сложных сцен, потребуется достаточно производительный ПК или ноутбук с хорошей видеокартой.
• Необходимость в структурированном обучении. Самостоятельное освоение Blender «методом тыка» часто приводит к разочарованию. Намного эффективнее двигаться по выверенной учебной программе с поддержкой преподавателя.

Blender — для целеустремленных детей и подростков 12-16 лет, которые всерьез увлечены миром компьютерной графики, мечтают создавать собственных персонажей для игр, короткометражные анимационные ролики или сложные визуализации. Это выбор для тех, кто готов инвестировать время и силы, чтобы получить по-настоящему мощный и востребованный навык.

Приглашаем на специализированный курс по Blender для детей и подростков в Школе программирования «Пиксель». Наши педагоги помогут преодолеть сложный начальный этап и построить прочный фундамент знаний. На курсе дети не просто изучат интерфейс Blender, а освоят полный цикл работы: от идеи и скетча до финального рендера. К концу обучения каждый ученик создаст собственное профессиональное портфолио, которое может включать, например, полностью текстурированного и анимированного 3D-персонажа или законченную стилизованную сцену с качественной визуализацией.

Записаться на бесплатный пробный урок курса «3D-моделирование в Blender для детей» можно здесь.

Перспективы изучения программ для 3D-моделирования для детей

Увлечение детей 3D-моделированием, которое начинается с простой фигурки в Tinkercad или первого персонажа в Blender, — это не просто хобби. Это ранний старт в освоении навыка, который сегодня лежит в основе десятков высокооплачиваемых профессий. Цифровое трехмерное пространство стало новой реальностью для творчества, инженерии и науки, и умение работать в нем сравнимо с владением популярным языком программирования.

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

Геймдев и анимация

Это одна из самых очевидных и желанных для детей подростков сфер. Здесь 3D-художники — настоящие творцы реальностей.

• Что делают: создают 3D-персонажей (от концепта до детализированной модели с текстурами и скелетом для анимации), окружение (города, леса, интерьеры космических кораблей), пропсы (оружие, транспорт, предметы быта) и визуальные эффекты (магические заклинания, взрывы).
• Пример задачи: получив концепт-арт фэнтезийного воина, художник по персонажам должен создать его 3D-модель, которая будет одинаково убедительно выглядеть с любого ракурса в игре, а аниматор — «оживить» его, запрограммировав движения бега, атаки и реакции.
• Главный инструмент — Blender.

Промышленный и предметный дизайн

Практически каждый объект, которым мы пользуемся, от зубной щетки до смартфона, прошел стадию 3D-моделирования.

• Что делают специалисты в этой области: разрабатывают внешний вид, эргономику и функциональность изделий. Создают цифровые прототипы, которые можно проверить на виртуальные нагрузки, собрать виртуально и только потом отправить в производство.
• Пример задачи: дизайнер получает техническое задание на разработку беспроводной колонки. В 3D-редакторе он создает ее форму, прорабатывает расположение кнопок и динамиков, подбирает материалы (пластик, ткань, металл) и создает фотореалистичные изображения для презентации клиенту.
• Какие инструменты используют: Tinkercad отлично подходит для первых шагов, обучения основам и создания простых концептов. Blender и другие профессиональные CAD-программы (Fusion 360, SolidWorks) используются для сложных инженерных задач.

Архитектура и визуализация

Современные архитекторы и визуализаторы больше не чертят на ватмане — они строят точные цифровые копии зданий.

• Что делают: создают архитектурные макеты и интерьеры в 3D, проводят виртуальные туры, визуализируют, как будет выглядеть здание в разное время суток или в разные сезоны. Это позволяет «прогуляться» по дому еще до закладки фундамента.
• Пример задачи: визуализатор получает чертежи будущей квартиры. Его задача — смоделировать ее в 3D, «расставить» мебель, подобрать отделочные материалы, настроить реалистичное освещение от виртуальных окон и создать серию изображений, неотличимых от фотографий.
• Какие инструменты используют: Tinkercad может стать первым инструментом для создания простых макетов. Для профессиональной работы используется Blender (особенно для сложного и креативного дизайна), а также специализированный софт вроде 3ds Max, SketchUp или Archicad.

Инженерное дело и 3D-печать

3D-печать перевернула подход к созданию вещей, но она невозможна без 3D-моделей.

• 3D-инженеры проектируют детали сложных механизмов (от дронов до протезов), проверяя их на прочность в симуляциях. Специалисты по 3D-печати адаптируют и готовят модели к печати, следя за тем, чтобы виртуальный объект можно было корректно воплотить в пластике, металле или смоле.
• Пример задачи: инженер должен смоделировать нестандартную деталь для ремонтного комплекта вышедшего из производства станка. Модель должна быть геометрически точной и учитывать физические свойства выбранного для печати материала.
• Какие инструменты используют: Tinkercad — идеальная площадка для знакомства с логикой 3D-печати, создания первых простых, но функциональных моделей. Для сложных технических задач используются Blender (для органических форм) и профессиональные CAD-системы.

Медицина и наука

В этой сфере 3D-технологии носят не коммерческий, а исследовательский и прикладной характер.

• Ученые создают 3D-модели молекул и кристаллических решеток для наглядного изучения, реконструируют внешний вид археологических находок по останкам, готовят модели органов пациента на основе данных КТ для планирования сложной операции.
• Пример задачи: ученый, изучающий новое химическое соединение, строит его точную трехмерную модель, чтобы понять, как он взаимодействует с другими молекулами. Эта модель становится ключом к разработке лекарства.

Как выбрать программу для 3D-моделирования, подходящую для вашего ребенка

Чтобы выбрать между Tinkercad и Blender для ребенка, не нужно быть экспертом в 3D-графике. Достаточно ответить на три вопроса: сколько лет ребенку, какова его ближайшая цель и сколько времени он готов уделять обучению. Эти критерии станут вашим основным ориентиром.

Ориентируйтесь на возраст и способность к самостоятельному обучению

• Tinkercad оптимален для детей 6-12 лет. В этом возрасте важнее всего быстрое ощущение успеха и понятная, игровая механика творчества. Ребенок еще не готов к долгому изучению сложного интерфейса, но с удовольствием будет собирать модели как цифровой конструктор и сразу видеть результат своей работы, особенно если есть возможность ее напечатать.
• Blender — для детей от 12-13 лет и старше, особенно если у ребенка есть выраженный интерес к конкретным сферам — играм, анимации, визуальным эффектам. В этом возрасте уже хватает усидчивости для преодоления начального, самого сложного этапа освоения профессионального инструмента. Ключевой фактор здесь — наличие внутренней мотивации.

Четко определите первую практическую цель

• Если цель — делать свои игрушки и сувениры для 3D-принтера, то ребенку нужен Tinkercad. Эта платформа идеально заточена под быструю подготовку моделей к печати. Ее инструментов хватит для создания 90% бытовых и декоративных предметов.
• Если ребенок хочет создавать крутых персонажей для игр или собственных мультфильмов — путь ведет к Blender. Никакой другой бесплатный инструмент не даст такой свободы в создании органических форм, детализированных персонажей и их дальнейшей анимации. Важно понимать, что это полноценный профессиональный софт, и для эффективного старта крайне желательна помощь преподавателя или структурированный курс.

Не бойтесь начинать с простого — это лучшая основа для сложного

Самый гармоничный и психологически верный путь в 3D-моделировании — последовательный. Начните с Tinkercad, даже если ребенок видит себя в будущем в геймдеве. Это даст ему бесценные преимущества:

• Уверенность в своих силах благодаря мгновенным и осязаемым результатам.
• Понимание работы с объемом, масштабом и композицией в трехмерном пространстве.
• Дети без проблем переходят на Blender, когда возможности Tinkercad становятся тесны для новых идей. Такой переход будет осознанным: ребенок уже будет понимать, зачем ему нужны более сложные инструменты.

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

Реклама. Рекламодатель ООО «Пиксель.Стади», ИНН 5074078988, erid: 2W5zFGart4G

Экспериментальный радиотрансивер работает на частотах около 140 ГГц и рассматривается как технологическая база для будущих стандартов 6G и так называемого FutureG.

«Беспроводной патч-корд» вместо кабеля

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

Используемый диапазон F-band (примерно 90–140 ГГц) находится намного выше частот 5G. Именно здесь, по мнению регуляторов и разработчиков стандартов, лежит следующий технологический рубеж мобильной, машинной и промышленной связи.

Отказ от классической цифровой схемы

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

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

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

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

Итог — 120 Гбит/сек без перегрева чипа, что раньше считалось почти недостижимым.

Почему это важно для 6G и дата-центров

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

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

Приемный чип, изготовленный по 22-нм технологии FD-SOI, потребляет около 230 мВт. Это уже укладывается в требования к портативным и встраиваемым устройствам.

Эксплойт умещается в одну строку, а сама проблема незаметно прожила в коде почти 11 лет — с мая 2015 года. О находке сообщило издание The Register.

Уязвимости присвоен идентификатор CVE-2026-24061, уровень опасности — 9,8 балла по CVSS.

В чем суть бага

Telnet — устаревший протокол удаленного доступа без шифрования. Несмотря на репутацию чего-то древнего и неактуального, telnet до сих пор используется в некоторых Linux-дистрибутивах и встраиваемых системах.

Проблема возникла из-за правок 2015 года в telnetd (версия 1.9.3). Сервер передает имя пользователя в системную утилиту /usr/bin/login, которая поддерживает флаг -f.

Этот флаг сообщает, что пользователь уже аутентифицирован и проверку пароля можно пропустить.

После тех изменений telnetd стал брать имя пользователя из переменной окружения USER — без проверки и экранирования. В итоге атакующий может подставить туда значение -f root и получить root-доступ.

Как выглядит эксплуатация

Эксплойт действительно тривиален и помещается в одну строку:

Если сервер уязвим, подключение сразу происходит от имени суперпользователя — без ввода пароля. По словам Стивена Фьюэра из Rapid7, эксплуатация проблемы «элементарна и гарантированно приводит к полному root-доступу».

Почему это особенно неприятно

• баг существовал почти 11 лет и попал в код вместе с «исправлением» другой ошибки;
• атака не требует подбора паролей или сложной подготовки;
• уязвимость работает до аутентификации;
• telnet-серверы до сих пор доступны в интернете.

По данным сервиса GreyNoise, за последние сутки зафиксированы попытки эксплуатации CVE-2026-24061 как минимум с 21 уникального IP-адреса.

Что рекомендуют делать

Рекомендации ожидаемые, но все еще актуальные:

• обновить GNU InetUtils до версии с исправлением;
• по возможности полностью отказаться от telnet в пользу SSH;
• временно отключить telnetd;
• если отключение невозможно — закрыть порт 23/TCP для всех, кроме доверенных IP.

Какой диапазон планируют использовать

Изначально для 5G в России был определен диапазон 4800–4990 МГц, однако теперь Минцифры рассматривает возможность его расширения до 4400–4990 МГц.

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

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

По их мнению, он может использоваться лишь как вспомогательный, тогда как приоритетным считается так называемый «золотой диапазон» 3400–3800 МГц, который широко применяется в Европе и Азии.

Почему операторы критикуют выбранный спектр

Основные претензии операторов связаны с физическими характеристиками частот 4,8–5 ГГц. На этих частотах базовые станции имеют меньший радиус покрытия, а это означает необходимость установки значительно большего количества оборудования для обеспечения сопоставимого качества связи.

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

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

Почему 5G все же пытаются запустить

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

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

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

Проблема скрывалась в обработке сжатых сообщений zlib на сетевом уровне. Уязвимость уже исправлена в актуальных версиях, но старые релизы — 3.6, 4.0 и 4.2 — патчей не получат. Все потому что они находятся в статусе EOL.

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

В чем суть бага

MongoDB использует собственный бинарный протокол и формат BSON. Сообщения могут передаваться в сжатом виде — в таком случае клиент сам указывает размер данных после распаковки.

Ошибка заключалась в том, что сервер без проверки доверял этому значению. Атакующий мог указать, что сообщение после распаковки весит, например, 1 МБ, хотя реально там был 1 КБ.

MongoDB выделяла в памяти большой буфер, распаковывала туда данные и оставляла остальное пространство заполненным «мусором» из неинициализированной памяти.

Почему это приводит к утечке данных

MongoDB написана на C++, а значит память после malloc не очищается автоматически.

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

Дальше вступает в игру BSON. Поля в нем хранятся как C-строки с \0 в конце. Если отправить специально сформированное сообщение без нулевого байта, сервер будет читать память дальше — пока не наткнется на первый \0. А затем вернет эту строку в сообщении об ошибке клиенту.

В итоге сервер сам отдает атакующему куски своей памяти.

Эксплуатация без логина и пароля

Самое неприятное — уязвимость срабатывает до аутентификации. Разбор входящего сообщения происходит раньше, чем проверка прав доступа. Это значит, что для атаки достаточно сетевого доступа к MongoDB. Логин, пароль и любые учетные данные не нужны.

С учетом того, что поисковики вроде Shodan находят более 200 000 MongoDB-инстансов, доступных из интернета, масштаб проблемы становится очевиден.

Почему 8 лет — это катастрофа

По данным исследователей, баг появился еще в 2017 году, начиная с MongoDB 3.6. Он существовал почти 8 лет. Насколько активно его использовали — неизвестно, но с учетом простоты эксплуатации трудно поверить, что им никто не воспользовался.

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

Сначала вышел CVE, затем — патч, а полноценное объяснение появилось позже. В компании заявили, что не нашли признаков эксплуатации, но подтвердить это задним числом практически невозможно.

Почему MongoBleed — тревожный сигнал

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

Но что входит в этот навык? Как родителю оценить уровень ребенка? Вместе с экспертами детской компьютерной школы «Пиксель» мы составили чек-лист основных компетенций.

Как изменилось понимание компьютерной грамотности

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

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

• Безопасность вышла на первый план.

Раньше главной угрозой казался вирус, который мог «сломать компьютер». Сегодня реальные риски тоньше и опаснее: фишинг (кража аккаунтов), мошенничество в чатах, кибербуллинг, утечка личных фото и данных. Поэтому умение создавать и хранить надежные пароли, проверять ссылки и настраивать приватность в соцсетях стали критически важными — даже важнее, чем знание Word или Excel.

• Информации стало намного больше.

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

• Акцент сместился с потребления на создание.

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

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

Учимся учиться: работа с информацией и данными

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

Эффективный поиск: не просто искать, а найти ответ

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

• Нужно научить ребенка выделять значимые слова в запросе, а еще лучше — использовать операторы. Например, поставить минус перед словом, чтобы исключить ненужное: по запросу «python -змея» найдется информацию только о языке программирования.
• Один из главных навыков — проверка источника. Нашли интересный факт для доклада? Отлично. Но спросите: «А кто это написал?». Научите ребенка смотреть, стоит ли за статьей научная организация, известный университет или, наоборот, это просто пост в блоге с громким заголовком. Это и есть прививка от фейков.
• Еще один суперважный навык — не верить искусственному интеллекту на 100%. Нейросети могут насчитать больше 24 часов в сутках, назвать водород металлом или придумать несуществующие химические элементы — они могут ошибаться и делают это регулярно. Важно показать это ребенку.

Структурирование данных: порядок на компьютере — порядок в голове

Вы когда-нибудь видели рабочий стол, заваленный сотней файлов с названиями «Документ1» или «Изображение123»? Это признак цифрового хаоса, который крадет время и нервы. Умение наводить порядок в файлах — это навык системного мышления, и он пригодится везде, а не только в работе за компьютером.

Что должен уметь ребенок:

• Создавать папки («4 класс», «Математика», «Проект „Рыцари“») и называть файлы понятно («Рыцари_черновик», «Рыцари_презентация_финал»). Это кажется мелочью, но так он учится организовывать не только файлы, но и свои мысли.
• Понимание форматов — это суперсила. Ребенок должен знать, что doc, docx, txt, rtf или pages — это для текста, jpg, png — для фотографий, mobi, fb2, epub — файлы электронных книг, а pdf и djvu — чтобы документ везде выглядел одинаково. Это избавит от ситуаций «мама, у меня не открывается» и научит выбирать правильную программу для просмотра.

Облачные технологии: работа там, где удобно и не в одиночку

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

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

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

Не правила, а привычки: цифровая безопасность и гигиена

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

Надежные пароли: ваш первый и главный цифровой замок

Пароли «12345» или «qwerty» — это как оставить ключ от квартиры под ковриком. Дети часто выбирают простые пароли, чтобы не забыть, или, что еще рискованнее, везде используют один и тот же пароль.

Что делать? Объясните просто: надежный пароль — это как секретная формула. Он должен быть длинным (от 10 символов) и состоять из «всего понемногу»: букв (больших и маленьких), цифр и символов (например, ! или &). Можно придумать вместе правило: взять фразу из любимой песни или книжки и превратить ее в аббревиатуру с цифрами. Например, «Я учусь в 4Б классе!» → «Yuv4Bk!».

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

Конфиденциальность: что такое «личное» и почему им нельзя делиться

Для детей граница между «своим» и «общим» в сети часто размыта. Выложить фото новой комнаты, отметить геолокацию школы в сторис, написать в игровом чате: «Мне 10, учусь в школе №...» — все это кажется безобидным общением.

Важно поговорить об это с ребенком не запугивая, а объясняя последствия. Спросите: «Ты бы дал свой домашний адрес незнакомому человеку на улице? Вот и в сети адрес, телефон, номер школы, кружки, на которые ты ходишь, — это твоя личная информация. Ее не выставляют на всеобщее обозрение».

Прямо вместе с ребенком зайдите в настройки его соцсети или игровой платформы (например, Minecraft). Покажите, где включается «закрытый аккаунт», кто может писать в личные сообщения, оставлять комментарии или видеть друзей.

Критическое мышление: как не попасться на крючок мошенников

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

Типичные признаки опасности: «Срочно!», «Твой аккаунт взломали, перейди по ссылке!», «Поздравляем, ты выиграл iPhone, введи данные родителей!», «Привет, это твой одноклассник, скинь код из SMS». Объясните ребенку: любое сообщение, которое вызывает чувство паники, жадности или необъяснимого везения, — повод остановиться, не кликать, а подумать и позвать родителей.

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

Основы цифрового творчества: даем идее форму

Эта группа навыков — не про сложные профессиональные программы, а про простые инструменты, с которыми ребенок сможет воплотить свои идеи: оформить доклад так, чтобы его было интересно читать, сделать открытку или смонтировать короткий ролик, чтобы впечатлить одноклассников.

Уверенная печать: не скорость, а техника

Кажется: причём здесь творчество? Но представьте, как сложно думать о содержании сочинения или сценария, когда ищешь каждую букву на клавиатуре и печатаешь одним пальцем. Это сбивает с мысли и утомляет.

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

Создание презентаций и документов: как говорить с миром на визуальном языке

Умение сделать не просто набор слайдов, а понятную, «говорящую» историю — еще одна современная суперсила. Важно научить не только кнопкам в PowerPoint, но и принципам:

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

Базовая обработка медиа: первые шаги к цифровому творчеству

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

• Как обрезать фото, убрав лишнее (кадрирование). Изменить размер картинки для аватарки или блога. Склеить несколько фото в коллаж.

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

Для этого не нужен профессиональный софт — достаточно встроенных в телефон или компьютер редакторов или простых онлайн-инструментов.

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

Типичные ошибки родителей: как помочь, а не помешать

Ошибка 1: Безопасность = полный запрет

Полный запрет видеохостингов (YouTube, RuTube), игр и соцсетей работает как таблетка от головной боли, которая не лечит причину. Ребенок, лишенный доступа дома, будет искать его в других местах: у друзей, в школе, в публичных сетях. И он пойдет туда без вашего руководства, без базовых знаний о безопасности, что сделает его намного более уязвимым. Запрет не учит осторожности, он лишь создает дефицит и вызывает азарт.

Вместо этого постепенно познакомьте ребенка с играми и Интернетом. Обсудите риски, установите понятные правила (например, «играем только час после уроков»), научите настройкам приватности.

Ошибка 2: Я сам сделаю быстрее и правильнее

Ребенок копается с презентацией, путается в папках, и рука так и тянется отодвинуть его, чтобы за пять минут сделать все идеально? Так мы сэкономим время сейчас, но заплатим за это в будущем. У ребенка закрепится чувство, что у него «не получается», и он будет ждать, когда мама или папа придут и решат проблему.

Вместо этого перейдите в режим «тренера». Спросите: «Как думаешь, с чего начать?», «Давай посмотрим, где тут кнопка выравнивания», «Попробуй сам, а если не выйдет — я подскажу». Это требует терпения, но результат — уверенность и самостоятельность — того стоит.

Ошибка 3: Зачем это учить, если он не будет программистом?

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

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

Уроки компьютерной грамотности в школе «Пиксель»

Все, что мы обсудили — это важные, но такие разные навыки. Объединить их в систему, сохранив у ребенка интерес и понимание «а зачем это мне?», — задача непростая даже для продвинутых родителей. Именно для её решения мы и создали базовые компьютерные курсы для младших школьников в онлайн-формате.

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

Программа курса компьютерной грамотности для детей в нашей школе включает навыки, которые мы перечислили выше, но не ограничивается ими:

• Понимание базовых функций компьютера — включение и выключение устройства, использование клавиатуры и мыши или тачпада.
• Работа с операционной системой — знание, как открывать и закрывать программы, понимание файловой структуры: создание, копирование, переименование, удаление файлов и папок.
• Использование офисных программ — работа с текстовыми редакторами (например, Google Docs), создание и использование таблиц (Google Sheets).
• Интернет-грамотность — основы поиска информации в интернете, безопасное поведение в сети: защита своих данных, понимание опасностей (вирусы, мошенничество и т.д.).
• Программы для создания и редактирования контента — основы работы с графическими редакторами и видеоредакторами.
• Основы программирования — знакомство с базовыми концепциями программирования на примере таких языков, как Scratch или Python.
• Цифровая этика и безопасность — ответственное использование технологий, понимание конфиденциальности и цифрового следа.

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

Узнать подробнее о курсе «Компьютерная грамотность для детей» можно на сайте школы программирования «Пиксель».

А здесь запись на бесплатный пробный урок.

До встречи на курсе!

Реклама. Рекламодатель ООО «Пиксель.Стади», ИНН 5074078988, erid: 2W5zFGm12HW

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

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

Команду по-прежнему возглавляет нейроинженер Виктор Тот. За это время установка эволюционировала во второе поколение и получила поддержку более сложных действий внутри движка DOOM.

Как крысы «играют» в DOOM сегодня

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

Главное отличие новой версии — значительно более богатый ввод.

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

Для ориентации в пространстве применяется система мягких воздушных импульсов: если крыса «врезается» в стену, она получает легкий поток воздуха в морду — так животному дают понять, что оно столкнулось с препятствием.

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

Без имплантов и нейроинтерфейсов

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

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

Зачем все это нужно науке

Цель эксперимента — не доказать, что крысы «понимают» DOOM или осознают происходящее на экране. Главное, по словам авторов проекта, это показать, что игровые движки могут служить универсальной виртуальной средой для исследования поведения.

DOOM здесь был выбран не случайно: он легкий, модифицируемый и хорошо изученный.

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

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

Google называет Disco «исследовательской платформой», а не готовым продуктом. Сейчас он доступен только для ограниченного числа пользователей — доступ можно попросить на специальной странице (но только на macOS).

Как работает GenTabs

GenTabs построен на базе модели Gemini 3 и использует сразу несколько источников контекста. В том числе текущие вкладки, историю взаимодействия и диалог с пользователем.

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

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

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

Все элементы GenTabs сохраняют связь с оригинальными веб-источниками, что позволяет проверить данные и избежать «черного ящика».

Вкладки как приложения, а не как список

Ключевая идея Disco — уйти от модели, где вкладки существуют сами по себе.

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

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

Мессенджер MAX снова испытывает масштабный сбой. Утром 30 марта 2026 года пользователи по всей России начали массово жаловаться на недоступность сервиса — приложение не открывается, сообщения не отправляются, а у части пользователей не приходят уведомления.

Проблемы затронули Android, iOS и веб-версию. По данным Detector404, резкий всплеск жалоб начался около 09:25 МСК — число обращений быстро приблизилось к тысяче. Больше всего жалоб поступает из Москвы, Самарской области, Краснодарского края и Санкт-Петербурга.

Это уже не первый крупный сбой MAX в 2026 году: 10 февраля сервис также массово «падал» (тогда пресс-служба утверждала, что «всё работает в штатном режиме»). А накануне, 29 марта, фиксировались проблемы с VK Видео — сервисом из той же экосистемы VK.

Официальных комментариев от команды MAX по сбою 30 марта пока нет.

Предыдущий сбой MAX — 8 декабря 2025 года

8 декабря 2025 года мессенджер MAX столкнулся с крупным техническим сбоем.

По данным Detector404, количество жалоб за последний час превысило 944, а за сутки — более 1200. При этом сервис «упал» практически мгновенно — на графике видно резкое вертикальное поднятие кривой жалоб.

Пользователи сообщали о полной недоступности приложения: MAX не открывался, не пускал в аккаунт, не отправлял сообщения, а у некоторых приложение просто зависало на заставке.

Со сбоем столкнулись как владельцы Android-смартфонов, так и iPhone. И даже пользователи веб-версии.

География сбоя 8 декабря

Проблемы фиксировались в десятках регионов. Среди лидеров по числу жалоб — Краснодарский край, Республика Коми, Алтай, Новосибирская область, Республика Саха (Якутия) и Москва.

Данные были собраны на основе сообщений за последний час, но тенденция была общероссийской. Пользователи массово отмечали одинаковые симптомы:

• «не работает приложение»;
• «невозможно отправить сообщение»;
• «не приходит код авторизации»;
• «не открывается MAX, пишет ошибку сети».

Где именно «ломался» MAX

Согласно статистике Detector404, 45,9% жалоб пришло от пользователей Android, 29,7% — от владельцев iPhone и 18,9% пришлось на долю веб-версии.

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

Отдельная часть пользователей жаловалась, что мессенджер «видит интернет», но фактически не соединяется с серверами.

Что говорили пользователи и что было известно официально

Команда MAX тогда не опубликовала официального комментария. Пользователи предполагали, что это либо крупная внутренняя авария, либо сбой в CDN/серверной инфраструктуре.

Некоторые связывали проблемы с обновлением, вышедшим накануне.

По данным следствия, подросток создал программу с помощью ChatGPT и использовал ее для «несанкционированного доступа к серверам компании».

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

Всего он успел выгрузить около 7,25 млн записей, включая личную информацию членов Kaikatsu Club.

Как школьнику удалось взломать систему

По данным японских СМИ, подросток обладал достаточным уровнем подготовки — он участвовал и даже выигрывал соревнования по кибербезопасности. ChatGPT он использовал как помощника для поиска уязвимости и написания кода для автоматизации атак.

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

Из-за повторяющихся атак приложение неоднократно выходило из строя — фактически школьник парализовал работу части сервисов сети.

Что это за задержанный подросток такой

В ноябре он уже попадал в поле зрения полиции: тогда его арестовали за покупку карт Pokémon по украденным реквизитам.

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

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

В сети появился материал, автор которого — программист с 20+ летним стажем — вспоминает, как еще в 90-е взрослые уверяли его, что программирование обречено.

Тогда активно утверждалось, что ООП решит все проблемы раз и навсегда: появятся библиотеки-«кирпичики», а бизнес просто будет собирать приложения как LEGO, вообще без инженеров.

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

Мультимедиа, IDE и другие «концы света», которые не случились

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

Но через несколько лет это стало обыденностью — просто очередным <video /> в HTML. Никто массово не разорился из-за отсутствия мультимедиа в продуктах.

В 2000-х на горизонте появился новый «убийца профессии» — умные IDE вроде IntelliJ. Автодополнение, рефакторинг, перенос классов, исправление ошибок до сборки — все это казалось магией, которая вот-вот заменит людей.

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

Автоматизация в реальности: она освобождает время, а не людей

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

Вывод простой: работы становится не меньше, а больше. Автоматизация убирает рутину, но не отменяет необходимости решать новые проблемы.

Новые ввения приходят и уходят, но разработка остается

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

Текущая волна ИИ — не исключение. Да, большие языковые модели меняют рабочие процессы. Да, они автоматизируют часть задач.

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

Вместо финала: ИИ не убьет разработчиков, но сделает их работу другой

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

Как и последние 30 лет, разработка остается живой потому, что мир постоянно усложняется. А значит — всегда будет кому этот мир программировать.

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

Появились и громкие заявления: например, автор книги «Империя ИИ» Карен Хао считает, что OpenAI уже обладает влиянием, сравнимым с государствами.

Мир в ожидании перемен

Обозреватель The Atlantic Чарли Варзел пишет, что мы живем «в мире, который построил ChatGPT» — мире нестабильности и ожидания следующего скачка технологий.

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

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

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

Как ИИ перестроил рынок капитала

По данным Bloomberg, эффект ChatGPT особенно заметен на фондовом рынке. Главный выигрывающий от происходящего игрок — NVIDIA. Ее графические процессоры стали основой ИИ-индустрии. Так, с момента запуска ChatGPT, акции компании выросли на 979%.

Вслед за ней ускорились и другие гиганты: Microsoft, Apple, Alphabet, Amazon, Broadcom. Теперь семь крупнейших компаний формируют 35% индекса S&P 500 — такой концентрации не было никогда.

Но внутри индустрии звучат и предупреждения. Гендиректор OpenAI Сэм Альтман открыто признает, что «кто-то потеряет феноменальные деньги на ИИ».

Глава Sierra и председатель совета директоров OpenAI Брет Тейлор сравнивает происходящее с пузырем доткомов: компаний может разориться много, но сама технология никуда не исчезнет.

Утром 28 ноября пользователи из разных регионов России начали массово сообщать о сбоях в работе *WhatsApp.

Мониторинговые сервисы «Сбой.рф» и Detector404 зафиксировали резкий рост обращений. «Код Дурова» пишет, что, например, в Нижнем Новгороде мессенджер полностью отключился около 9:00 по московскому времени.

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

Проблемы в Москве и Санкт-Петербурге

В Москве пользователи жалуются на нестабильное подключение и длительную доставку сообщений.

В Санкт-Петербурге сбой проявляется иначе: не отправляются и не загружаются фотографии и другие медиафайлы.

Что помогает и что известно

Судя по сообщениям пользователей, смена IP-адреса на зарубежный полностью восстанавливает работу сервиса. Это указывает на возможные проблемы именно в российском сегменте сети. Как вариант — не обошлось и без маршрутизации трафика.

Точные причины сбоя пока неизвестны. Официальных комментариев от Роскомнадзора, *WhatsApp или *Meta на момент публикации нет.

*Компания Meta и ее продукты признаны экстремистскими, их деятельность запрещена на территории РФ

Это важный момент — индустрия десятилетие жила по формуле «больше данных → больше параметров → лучше модель». Теперь же оба лидера признают: следующий этап развития ИИ требует новых идей, а не просто новых кластеров с чипами H100.

Что говорит Суцкевер: эпоха масштабирования закончилась

Суцкевер делит историю ИИ на три периода:

• 2012–2020 это эпоха исследований. Здесь сфера получала новые архитектуры, CNN, внимание, RL.
• 2020–2025 это эпоха масштабирования. Законы масштабирования обеспечивают стабильный прирост качества.
• 2025 и далее — возвращение к исследованиям. GPU-фермы огромны, интернет конечен, эффект от роста моделей падает.

Главными лимитами актуальных LLM он назвал то, что высокий балл в бенчмарках ≠ надежность в реальных задачах. Также Суцкевер отметил, что обучение моделей все еще остается «черным ящиком, а обобщение все еще слабее человеческого — модели требуют тонны данных и сложные пайплайны пост-тюнинга.

Его новая компания SSI делает ставку именно на новые методы обучения, а не на «GPT-7, который такой же, но больше».

Что говорит Лекун: LLM — тупиковая ветвь

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

Еще к минусам нынешнего подхода он отнес тот факт, что каждый новый скачок дается все дороже, а отдача снижается. Ну и вишенка на торте — для настоящего интеллекта нужны world models. Т. е системы, которые учатся на видео, строят представления об объектах, времени и причинности.

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

Почему это важно для разработчиков

Обе позиции сходятся на главном: мир ИИ меняется. Что это означает для тех, кто строит продукты?

1. GPU перестают быть главным преимуществом

Если масштабирование не дает прежнего прироста, то выигрыш дают:

• свои данные;
• UX;
• доменные сценарии;
• собственные пайплайны обработки.

2. Бенчмарки больше ничего не гарантируют

+2% к Abilities Arena вообще не означают меньше ошибок в рабочем процессе пользователя.

3. Стек ИИ станет более разнообразным

Появятся модели, которые:

• отвечают за физическое моделирование;
• выполняют планирование;
• работают поверх видео, а не текста;
• комбинируются с LLM в гибридные системы.

4. Главный актив — данные и обратная связь

По мнению экспертов, в ИИ-гонке победят не те, у кого лучший baseline-модель. Лидерство достанется тем, кто владеет качественными доменными данными, строит точные метрики качества и быстро (и итеративно) улучшает результат под свои процессы.

Что дальше: тихий перелом эпохи

Пятилетняя мантра «масштабирование — это все, что вам нужно» дала нам GPT-4, Claude, Gemini и всю текущую волну ИИ-продуктов. Но сегодня два главных человека в индустрии говорят: масштаб больше не тянет нас вверх (Суцкевер) и LLM не приведут к настоящему ИИ (Лекун).

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

По словам CEO Cloudflare Мэттью Принса, это был «худший сбой с 2019 года».

Что пошло не так

Проблема возникла не из-за DDoS-атаки, DNS или генеративного ИИ — хотя именно на это компания грешила изначально.

Источник оказался куда менее очевидным: внутренний сбой в системе Bot Management, которая определяет, какие запросы принадлежат людям, а какие — ботам и парсерам.

Система использует ML-модель и большой конфигурационный файл с признаками, по которым определяется бот-трафик. Этот файл регулярно пересчитывается в ClickHouse.

Cloudflare обнаружила, что изменение поведения запросов в ClickHouse привело к появлению множества дублирующихся строк в конфигурации.

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

Клиенты, использующие бот-фильтры, начали получать массу ложных срабатываний — легитимные запросы считались ботами и блокировались. Те, кто не использовал Bot Management, пережили сбой почти незаметно.

Почему масштаб оказался таким большим

Cloudflare сегодня — один из крупнейших игроков интернет-инфраструктуры:

• по данным самой компании, 20% всех сайтов в мире используют Cloudflare;
• сервисы завязаны на ее CDN, защиту от DDoS, балансировку и маршрутизацию;
• сбой в одном модуле приводит к лавинообразному эффекту.

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

Что Cloudflare планирует изменить

Компания признала, что модель обработки собственных конфигурационных файлов требовала такой же строгой валидации, как пользовательский ввод. Теперь Cloudflare обещает:

• усилить проверку внутренних конфигов перед распространением;
• ввести новые глобальные «kill switch» переключатели для быстрого отключения проблемных подсистем;
• устранить сценарии, при которых отчеты об ошибках могут съедать ресурсы и вызывать деградацию;
• пересмотреть отказоустойчивость всех модулей центрального прокси.

Почему это важно

За последние месяцы это уже третий крупный сбой глобального масштаба: ранее проблемы в Azure и AWS также обрушивали сотни сервисов.

Чем больше интернет завязан на нескольких инфраструктурных компаниях, тем сильнее и заметнее эффект любого сбоя.

Cloudflare, пожалуй ведущий провайдер сетевой инфраструктуры, начал возвращать ошибки для трафика по всему миру. Под удар попали ChatGPT, X, Downdetector и десятки тысяч других сайтов.

Что произошло

Cloudflare официально заявила о «всплеске аномального трафика», который вызвал массовые ошибки в сетевой маршрутизации:

«Мы пока не знаем причину всплеска, но задействованы все ресурсы, чтобы восстановить работу трафика», — Cloudflare.

Проблемы сразу ударили по крупным сервисам:

• X показывал ошибку про «внутренний сервер» из-за сбоя в Cloudflare.
• ChatGPT выдавал: «please unblock challenges.cloudflare.com to proceed».
• Downdetector — сервис, который должен мониторить сбои сам лег и отдавал ту же ошибку Cloudflare.

Насколько все было плохо

Cloudflare обслуживает около 20% всех сайтов в мире, от CDN и DNS до защиты от DDoS. Когда у нее проблемы — проблемы в целом почти у всего интернета.

NetBlocks, например, назвал происходящее «катастрофическим нарушением инфраструктуры Cloudflare». И добавил, что гигант стал критически важной точкой отказа для интернета слишком многое завязано на его защите.

Почему так больно?

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

Что сейчас

На момент написания новости, Cloudflare заявила, что сервисы «постепенно восстанавливаются», но часть пользователей все еще может видеть ошибки.

Причина аномального трафика пока не раскрыта.

Почему это так и кому выгодно рушить чужие сервисы в обмен на пару десятков долларов? Разберемся.

Что такое коммерция DDoS и почему она доступна каждому

Появление сервисов "DDoS-for-hire" (так называемых booter/stresser) снизило порог входа для атакующих: теперь не нужно быть знатоком сетей или собирать ботнет — достаточно оплатить услугу на сайте, выбрать цель и нажать кнопку.

Такие площадки позиционируют себя как инструменты для "тестирования" сетей, но на практике используются для вывода сайтов и игровых серверов из строя. Это превратило DDoS в товар с массовым потреблением и регулярными доходами для операторов.

От скрипта в вузовской комнате до глобальных ботов

Легендарный пример - ботнет Mirai, который в 2016 году заразил сотни тысяч IoT-устройств и стал источником рекордных тогда атак, парализовав части сети и сервиса DNS-провайдера.

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

Масштаб и частота атак растут

Данные крупных провайдеров защиты и отчеты по угрозам фиксируют резкий рост количества атак и их мощности: за 2024 год число зафиксированных DDoS-инцидентов увеличилось многократно, а доля гипер-высотных атак (с объемом в терабиты в секунду) растет квартал к кварталу. Это означает, что даже крупным компаниям приходится регулярно включать "режим боевой готовности".

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

Цель таких операций - не долгий простои, а паника и проверка "живых" щелей в защите.

Почему так трудно бороться с этим бизнесом

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

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

Какими инструментами борются законопослушные компании

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

Что это значит для бизнеса и обычных пользователей

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

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

Рынок есть, и с ним придется считаться

Бизнес на DDoS живет за счет дешевых инструментов, распределенной инфраструктуры и спроса - от троллинга до вымогательства. Борьба с ним требует координации правоохранителей, жесткой цифровой гигиены у владельцев устройств и инвестиций в защиту у бизнеса.

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

До тех пор, пока не появляется Он. Вирус, троян, червь, шпионский софт. Или просто подозрительный процесс, пожирающий ресурсы. Сразу возникают вопросы: можно ли полагаться на встроенную защиту или стоит установить специализированное ПО?

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

Антивирус 2025: цифровой мертвец или живой организм?

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

Windows Defender, который вы иногда отключаете, — это уже не та незаметная утилита из Windows 7. Это сложный EDR-агент, который по умолчанию имеет доступ к вашей памяти, сетевой активности и всем процессам.

Gatekeeper в macOS — это тоже форма антивируса, просто работающая на принципах whitelist’а и санирования приложений из App Store. Вопрос не в том, «есть ли у вас антивирус», а в том, насколько глубоко вы понимаете ту защиту, которая уже работает.

Ландшафт угроз изменился радикально. Раньше злоумышленники хотели «сломать систему». Сегодня их цель — оставаться в системе как можно дольше, красть данные, использовать ресурсы. Им ваш синий экран не нужен. Им нужны ваша тишина и покой.

Миф 1. «Мой Linux / Mac слишком безопасен для вирусов»

Священная война между фанатами операционных систем давно перешла в область безопасности. Но правда в том, что ОС — это просто платформа. Уязвимости есть везде. Атаки сместились с уровня операционной системы на уровень приложений и цепочек поставок (supply chain).

Ваш Ubuntu не подхватит классический вирус-шифровальщик, написанный для Windows. Но он с радостью выполнит майнер, вшитый в библиотеку, которую вы установили через pip install --user. Или скрипт, который сольет ваши SSH-ключи из ~/.ssh/. Злоумышленникам сегодня не нужен root. Им нужен ваш пользователь, который имеет доступ к коду, репозиториям, облачным ключам.

• Реальность. Атаки на репозитории открытого ПО стали массовыми. Ежегодный отчёт компании Sonatype о состоянии программного обеспечения за 2024 год показывает, что за предыдущий год было обнаружено 512 847 новых вредоносных пакетов, что означает рост на 156%. Вы делаете npm install и запускаете потенциально вредоносный код с правами вашего пользователя.
• Что делать. Перестать надеяться на магическую неуязвимость ОС. Использовать принцип наименьших привилегий на практике. Запускать подозрительный код в изолированных средах: Docker-контейнерах, виртуальных машинах. Мониторить исходящий сетевой трафик на предмет аномалий. Инструменты вроде lynis для Linux или Little Snitch для Mac — это не антивирусы в классическом понимании, но они выполняют ту же защитную функцию: контролируют всё, что происходит в системе.

Миф 2. «Встроенного защитника Windows / Gatekeeper на Mac достаточно»

Самоуспокоенность — главный враг безопасности. Да, встроенные защитники стали невероятно мощными. Они используют ML-модели, поведенческий анализ и имеют глубокую интеграцию с ядром системы. Но их основная цель — защитить среднестатистического пользователя от массовых угроз. Это основная, но не полноценная платформа защиты (EPP).

Представьте себе целенаправленную атаку (targeted attack). Злоумышленники используют кастомный вредонос, написанный специально для компаний вашего профиля. Он не распространяется в дикой природе, его нет в базах. Он использует технику «живи за счёт земли» (Living-off-the-Land), маскируясь под легитимные процессы вроде ps.exe или wmic.exe.

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

• Реальность. Независимая тестирующая организация AV-Comparatives в своих отчётах за 2024 год регулярно демонстрирует, что Windows Defender обеспечивает стабильную защиту против популярных угроз. Однако в тестах на защиту от целенаправленных атак и сложных zero-day угроз его показатели могут быть ниже, чем у коммерческих EDR-решений от CrowdStrike или SentinelOne.
• Что делать. Для домашнего ПК, на котором вы сёрфите в интернете и работаете с документами, Defender почти достаточное решение. Для рабочей станции разработчика, системного администратора или любого сотрудника, имеющего доступ к критической инфраструктуре, этого мало. Необходимо слоить защиту. Defender — это базовый, но обязательный слой. Поверх него должен идти более продвинутый агент, способный к поведенческому анализу и отслеживанию цепочек атаки.

Миф 3. «Антивирус съедает все ресурсы и тормозит систему»

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

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

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

• Реальность. Да, антивирусный агент создаёт дополнительную нагрузку. Но в 2025 году эта нагрузка для качественных продуктов редко превышает 2-5% в штатном режиме. Проблемы могут возникать в пиковых случаях: компиляция ядра Linux, работа с большими базами данных, запуск виртуальных машин. Именно для этого существуют детальные настройки исключений.
• Что делать. Изучать тесты производительности от организаций вроде AV-Comparatives или SE Labs. Грамотно настраивать исключения. Вносить в «белый список» папки с исходным кодом (src, node_modules, .git), директории виртуальных машин, бинарники компиляторов. Современный антивирус — про тонкую настройку под свой рабочий процесс.

Миф 4. «Мне хватает здравого смысла: не ходить по сомнительным ссылкам»

Это самый опасный миф. Он основан на вере в то, что фишинг — удел наивных пользователей. Реальность такова, что социальная инженерия стала оружием массового поражения. Речь не о письмах с заголовком «Вы выиграли iPhone!».

Речь о фишинге высшего пилотажа. О письме, которое приходит на вашу корпоративную почту от имени «отдела DevOps» с ссылкой на «критическое обновление» для вашего CI/CD-пайплайна. Письмо идеально стилизовано, содержит ваше настоящее имя и ссылается на реальных коллег.

Сайт, на который вы попадаете, — клон страницы вашего корпоративного SSO (VK Teams, Azure AD). Вы вводите логин и пароль. На этом всё. Ваша учетная запись скомпрометирована. Осторожность оказалась бесполезной — атака была спланирована и нацелена лично на вас или вашу компанию.

• Реальность. Согласно отчету Verizon Data Breach Investigations Report 2024, основная масса нарушений (68%) связана с человеческим фактором, включая фишинг и претекстинг (целенаправленная атака с созданием легенды для жертвы). При этом фишинг выступает первоначальным вектором атаки в 15% нарушений, а претекстинг остаётся главной тактикой в инцидентах социальной инженерии. Проблема не в глупости, а в человеческой психологии и информационном перегрузе.
• Что делать. Принять, что человек — самое слабое звено в цепи безопасности. Нужны технические контрмеры. Антивирус/EDR в этой схеме выступает последним рубежом обороны. Он не помешает вам ввести пароль на фишинговом сайте. Но он может обнаружить и заблокировать вредоносную полезную нагрузку (payload), которая скачается и запустится уже после компрометации ваших учётных данных. Обязательно используйте аппаратные ключи или приложения для двухфакторной аутентификации (2FA) везде, где это возможно.

Миф 5. «Антивирусы бессильны против zero-day и файл-лесс атак»

Это утверждение верно, если говорить об антивирусе образца 2010 года, который только и делал, что сравнивал MD5-хеши. Современные платформы защиты конечных точек (EPP/EDR) работают иначе. Они ищут не известные угрозы, а подозрительное поведение.

Файл-лесс атака — это когда вредоносный код живёт только в оперативной памяти. Да, файла нет. Но есть аномальная цепочка событий. Процесс powershell.exe (легитимный) неожиданно запускает rundll32.exe для выполнения кода в памяти, который затем пытается отключить защиту через изменение реестра и установить постоянность (persistence). EDR видит не три отдельных безобидных процесса, а одну цельную картину атаки, соответствующую известным тактикам злоумышленников.

• Реальность. Современные системы ориентируются на фреймворки вроде MITRE ATT&CK, которые описывают сотни тактик и техник, используемых хакерами. Антивирус 2025 года — это, по сути, реализация этого фреймворка в виде работающего агента. Он анализирует телеметрию и ищет совпадения с известными паттернами поведения, а не с сигнатурами файлов.
• Что делать. При выборе решения смотреть не на громкое название «антивирус», а на его возможности. Есть ли у него EDR? Интегрируется ли он с MITRE ATT&CK? Есть ли возможность расследования инцидентов (forensics) по собранной телеметрии? Использует ли он песочницу для детонации подозрительных файлов? Ответы на эти вопросы гораздо важнее, чем размер сигнатурной базы.

Миф 6. «Антивирусные компании сами создают вирусы, чтобы был спрос»

Конспирологическая классика. У этого мифа нет никаких доказательств. Реальная экономика угроз гораздо прозаичнее и страшнее.

Киберпреступность — это гигантская индустрия с годовым оборотом в триллионы долларов. Работают модели «ransomware-as-a-service», есть полноценные техподдержки для жертв шифровальщиков, действуют целые корпорации вымогателей. Им не нужно помогать антивирусным компаниям — и так хватает работы.

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

• Реальность. Бизнес-модель легальных антивирусных компаний строится на подписках (SaaS). Репутация — их главный актив. Обнаруженный сговор с создателями вирусов мгновенно уничтожит бизнес и приведёт к колоссальным судебным искам. Гораздо проще и выгоднее честно бороться с реальными угрозами, которых более чем достаточно.
• Что делать. Оценивать вендоров по их открытости. Участвуют ли они в независимых тестах? Публикуют ли исследования об обнаруженных угрозах (threat intelligence reports)? Как быстро реагируют на новые образцы вредоносных программ? Прозрачность — лучший ответ на конспирологические теории.

Миф 7. «Ложные срабатывания (false positives) сводят на нет всю пользу»

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

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

• Реальность. Баланс между безопасностью и удобством — ключевая проблема всех систем защиты. Слишком агрессивный антивирус будет мешать работе. Слишком слабый — пропустит угрозу. Исследование, проведённое при участии IBM в 2023 году, показало, что специалисты по безопасности тратят примерно треть рабочего дня на расследование ложных или маловажных оповещений, что в пересчёте на команду составляет десятки часов в месяц.
• Что делать. Активно использовать функции whitelist. Подписывать свои собственные приложения цифровыми сертификатами (code signing). Настраивать политики исключений для доверенных папок разработки. Работать с вендором: отправлять ложно заблокированные файлы на анализ. Часто после такого анализа следующий апдейт антивируса уже не будет считать ваш файл вредоносным.

Ставить или не ставить?

В 2025 году вопрос «ставить или не ставить антивирус» бессмыслен. Почти у всех он уже есть, просто в разной форме. Правильный вопрос: «Достаточен ли мой текущий уровень защиты конечных точек для моих рисков?».

Рекомендации следующие:

• Для рядового пользователя / студента. Агрессивный режим Windows Defender/Security Center + современный браузер с антифишингом + блокировщик рекламы + здравый смысл = хороший базовый уровень. Сторонний антивирус — опционально, для душевного спокойствия.
• Для разработчика / IT-специалиста. Встроенный защитник — это только начало. Обязателен более продвинутый агент (например, из бесплатных — Comodo Internet Security с включенным HIPS, из платных — решения с EDR типа Kaspersky Endpoint Security или Dr.Web Security Space). Жёсткий файрвол. Обязательное использование песочниц или контейнеров для тестирования подозрительного кода. Сканирование зависимостей (SCA) в своих проектах.
• Для корпоративной среды. Тут без вариантов. Нужна полноценная платформа EPP/EDR, интегрированная с SIEM и SOC. Антивирусная составляющая — один из ключевых сенсоров в этой системе, отвечающий за сбор телеметрии и блокировку на ранних стадиях атаки.

Антивирус в старом понимании мёртв. Но жива интегрированная платформа безопасности конечной точки, которая умеет не только искать вирусы, но и понимать поведение, расследовать инциденты и давать ответ. Это своего рода цифровой иммунитет, который обеспечивает устройствам полноценную защиту.

Сказанное подтверждает Евгений Касперский:

«Я твёрдо уверен, что само понятие «кибербезопасность» в скором времени себя изживет, а на замену ему придёт концепция “кибериммунитета”».

О чём пойдет речь

Маша Даровская: Сегодня будем обсуждать реалии современного IT-рынка — умер он или ещё жив. У нас в гостях Алексей Сухоруков, сооснователь и совладелец агентства Alex Staff Agency, которое как раз занимается рекрутингом IT-специалистов.

Алексей Сухоруков: Можно сказать, что это международное рекрутинговое агентство. В основном мы специализируемся на европейском рынке — это примерно 80 с лишним процентов нашего портфеля. В России тоже есть кадровое агентство, созданное ещё в 2005 или 2006 году, называется «Алексей Сухоруков». Там всё по-прежнему хорошо, компания развивается, у них всё в порядке.

Маша Даровская: То есть вы в основном занимаетесь наймом в Европу и для Европы, но у вас есть и российское представительство, правильно понимаю?

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

Маша Даровская: А если говорить про Европу, для наших слушателей — какие это в основном страны?

Алексей Сухоруков: В основном это страны Евросоюза. Германия практически не представлена — очень сложный рынок, Британия тоже — рынок закрытый. Всё, что вокруг, работает нормально. И важно учитывать: если говорить о том, жив ли рынок, то первый квартал 2025 года показал рост IT-найма на 25%. Большая часть этих цифр относится к Восточной Европе. Из этого можно сделать вывод, что компании стараются оптимизировать расходы и размещают разработчиков преимущественно в восточноевропейских странах — просто потому, что там дешевле. По крайней мере, я так предполагаю. Возможно, есть и другие причины, но тенденция именно такая.

Прогнозы роста до 2030 года достаточно позитивные и серьёзные: Восточная Европа будет активно развиваться, а Западная Европа постепенно будет её догонять. Америка, по каким-то причинам, отстаёт. Говорят, это связано с тем, кто сейчас управляет страной — возможно, из-за этого там все немного насторожены, и рост не такой активный. Там ситуация с трудоустройством довольно сложная: специалисты с серьёзным сеньорным опытом могут искать работу несколько месяцев и так и не найти её.

Причины роста найма и оптимизация затрат

Маша Даровская: А если обобщить ситуацию, скажи, с чем связано то, что сейчас, по твоим данным, нанимают больше? Это потому, что недиджитальные компании начинают нуждаться в IT-специалистах, или появляются новые проекты, которые изначально строятся как IT-бизнес?

Алексей Сухоруков: Рынок долго не мог привыкнуть к тому мощному конфликту, который возник в России и серьезно тормозил развитие экономики. К этому добавилась затяжная постковидная рецессия, которую мировые финансисты, в том числе европейские, планировали аккуратно преодолеть и даже использовать для прогресса. Но из-за перехода конфликта в горячую фазу сработало множество рисков. Вплоть до того, что многие крупные компании, например BASF в Германии, были вынуждены перестроиться: открылись в Америке — это еще во времена Байдена происходило.

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

В то время аутсорсинг был в основном ориентирован на Америку. Сокращения привели к тому, что из компаний убрали всех бездельников, разгильдяев и нелояльных сотрудников. Тогда требования к разработчикам были довольно простыми: до 2008 года нанимали любого, кто хоть немного разбирается в технике выше среднего уровня. О софт-скиллах или корпоративной культуре в IT тогда даже не слышали.

С 2008 года ситуация изменилась: стали оставлять на работе только самых мотивированных, чтобы они надолго оставались в компании, и, соответственно, самых эффективных. Всех, кто был «жирком», постепенно сокращали. Я сейчас говорю в первую очередь о небольших компаниях — мелких, средних, ну и, конечно, крупных тоже. Мы все видели, как недавно FAANG массово увольнял людей тысячами. Но им проще: у них всегда есть запас прочности, потому что они ведут множество проектов впрок — что-то выстрелит, что-то нет, денег много, можно экспериментировать. А вот средний и особенно средний-малый бизнес не может себе позволить такие масштабные увольнения.

Если компания не очень большая, у неё есть свой продукт, который она поддерживает, то носителями экспертизы становятся отдельные сотрудники. И тех, кто не приносит дополнительной ценности, на самом деле не так уж много. От таких сотрудников тоже избавляются. А дальше происходит следующее: чтобы сократить издержки, вместо трёх человек нанимают одного. Сейчас на рынке, особенно в Европе, наблюдается такой тренд: компании хотят видеть специалиста, который одинаково хорошо владеет тремя стеками. Причём не так, что один стек основной, а остальные — просто дополнение, а чтобы во всех трёх он был на уровне сеньора. Например, Python, Go и Linux — причём на уровне компиляции ядра. И ты смотришь на такие требования и думаешь: как вообще такое возможно?

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

Маша Даровская: Сеньоров и так немного, а найти человека, который хорошо знает и Go, и Python, и Linux — это вообще не такая простая задача. Они вообще существуют? Ещё остались такие?

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

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

Алексей Сухоруков: Фреймворки — это вообще для слабаков. Я люблю повторять слова Андрея Платова, который однажды сказал мне: «Лёша, если вдруг появится задача, для которой не найдётся подходящего языка, я напишу свой язык». В принципе, любой нормальный разработчик с десятилетним стажем способен на это. Понимаешь, нас очень избаловали все эти простые среды и фреймворки, которые позволяют быстро войти в профессию: год-два — и ты уже middle или senior, получаешь хорошую зарплату. Но самыми сильными и востребованными на рынке всегда останутся не те, кто делает продукты для пользователей, а те, кто создаёт инструменты для разработчиков.

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

Ситуация с джунами и влияние ИИ

Маша Даровская: А что с джунятами? Они сейчас вообще как?

Алексей Сухоруков: Вообще всё печально. Грустно это говорить, но так и есть. Посмотри, с какой скоростью меняются и совершенствуются инструменты. Искусственный интеллект, например. Это просто какая-то дикая гонка. Даже невозможно успевать осваивать то, что появилось сегодня, потому что завтра уже выходит что-то новое. Как это происходит? Появляется, например, ChatGPT, ты начинаешь придумывать, как его доработать под свои задачи. Пока ты этим занимаешься, выходит новая версия, где все твои костыли уже реализованы на уровне самого продукта. И ты снова начинаешь изобретать новые костыли. У меня, по крайней мере, именно так и было.

То есть сначала ты учишься писать промты, потом появляются джипитисты, потом — агенты, и всё начинает развиваться очень быстро. Когда именно это становится массовым явлением — пока не очень понятно. Поэтому… Честно скажу, я пока не придумал, какой должна быть траектория входа в IT сейчас, чтобы не потеряться. Я даже говорил некоторым ребятам: сейчас, возможно, лучше не входить, лучше немного подождать. Сейчас просто невозможно найти работу, особенно если у тебя семья.

Маша Даровская: То есть вообще никаких шансов нет? Или всё-таки есть какие-то лайфхаки, стажировки? Может быть, берут джунов с хорошим образованием — компьютер-сайенс, вышка, алгоритмы, математика?

Алексей Сухоруков: Возможно, какие-то лайфхаки и существуют. Я не буду рассказывать про накручивание опыта, которым пользуется одно из известных нам сообществ — это, на мой взгляд, не очень красиво, у всех своя философия. Но если говорить честно, проникновение AI в IT пока ещё не настолько глубокое. На данный момент вряд ли 80% компаний или 80% кода используют искусственный интеллект.

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

Фильтры, резюме и ИИ в рекрутинге

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

Алексей Сухоруков: Это, кстати, ещё не самые плохие рекрутеры, если они просто следят за активностью в чатах. В Америке или Европе за такое вообще можно в суд подать — работодатель не имеет права вмешиваться в личную жизнь кандидата. Вот у тебя есть резюме, есть рекомендательные письма — на их основе, пожалуйста, смотри LinkedIn, профессиональную соцсеть, где можно получить дополнительную информацию о кандидате. Но если ты полезешь, скажем, в Facebook, чтобы найти что-то о человеке и на основании этого ему откажешь, а он об этом узнает — могут быть очень серьёзные последствия. В западных странах такие вещи строго регулируются, а вот на постсоветском пространстве подобных правил нет, поэтому рекрутеры, особенно хорошие, всегда просматривали профили кандидатов в соцсетях.

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

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

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

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

Маша Даровская: Смотри, я слышала такую версию: на HeadHunter появятся подтверждённые навыки — список, в который ты регистрируешься, подтверждаешь свои умения, и на это будут смотреть работодатели. Это что-то вроде копии LinkedIn, да? Только LinkedIn — это просто соцсеть для поиска работы, а здесь речь о том, что ты должен зарегистрироваться, как на госуслугах, подтвердить свои навыки, опыт работы, чтобы работодатели могли это проверить. И только через такую систему можно будет подавать на вакансии.

Алексей Сухоруков: В государственных учреждениях, возможно, так и будет. Но в обычных компаниях я в этом не уверен. Я и упомянул LinkedIn, потому что там есть раздел, где ты указываешь свои навыки и можешь попросить друзей или коллег подтвердить, что ты действительно в этом разбираешься. Этот тренд продвижения в LinkedIn сейчас действительно очень мощный. Все стараются оформить свои профили красиво, часто по совету тех же нейросетей: собирают рекомендации, просят не просто подтвердить навык, а написать что-то хорошее о себе. Это действительно работает — твой профиль чаще появляется в поиске, когда тебя ищет рекрутер. Думаю, OXX собирается сделать что-то похожее, хотя, возможно, технологически это будет реализовано иначе.

Но как они собираются подтверждать навыки? Будут проводить экзамены? Мне слабо в это верится, даже представить сложно. Получается, просто пишешь, что знаешь Ruby on Rails на восемь из десяти — ну, хорошо. А кто это проверит? Что, всех работодателей страны загонят туда, чтобы они прошлись по кандидатам и расставили теги? Мне это слабо представляется. Даже у нас внутри агентства в базе достаточно много кандидатов, с которыми мы общались, и чтобы их как-то проиндексировать, это уже непросто. А у них таких — миллион. И работодателей, которые с ними работали, тоже сотни тысяч, попробуй всех уговори.

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

Маша Даровская: Будем следить за новостями, посмотрим, что придумают. Скажи, пожалуйста, есть ли смысл просить, например, ChatGPT или его аналоги помочь с подготовкой резюме в нынешних условиях? Не чтобы обмануть, а чтобы оформить красиво. И как, по-твоему, сделать так, чтобы не попасть под фильтры, которые определяют, что резюме составлено с помощью ИИ?

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

Маша Даровская: Да, мне тоже советовали писать сопроводительные письма с помощью GPT — говорят, он хорошо справляется.

Алексей Сухоруков: Что касается сопроводительных писем… В общем, суть в том, что ты берёшь своё резюме, берёшь вакансию, на которую хочешь откликнуться — ну, я бы так делал, например, — показываешь их своему ассистенту, искусственному, конечно. Я обычно немного настраиваю его, у меня для этого есть специальный промпт. Говоришь: «Вот вакансия, вот моё резюме. Сделай так, чтобы оно максимально подходило под требования, выглядело хорошо, но при этом не выдумывай ничего, используй только мою информацию, подчеркни важное, убери то, что может помешать». Это можно сделать и вручную, а можно поручить GPT — он подправит, структурирует, подберёт более подходящие формулировки.

Скорее всего, она ничего особо плохого не скажет. Когда ты пишешь сопроводительное письмо, пока ещё заметно, что текст написан искусственным интеллектом — это видно невооружённым глазом. Люди быстро определяют такие тексты, и опытный человек сразу поймёт. По крайней мере, если у человека набита рука, он сразу отметит: «Ого, какое-то странное построение фраз». Ну, не очень, да? Такое ощущение, что где-то рядом Оби-Ван Кеноби покопался. Поэтому гораздо лучше взять у ChatGPT основное направление, а потом всё-таки переписать текст под себя.

То есть ты просишь: «Напиши сопроводительное письмо на эту вакансию, чтобы было видно, что я очень хочу здесь работать, могу принести много пользы, и у нас будет взаимная выгода». Просишь подчеркнуть одни моменты, добавить другие — он тебе набрасывает абзац-другой, как ты попросишь. Потом ты смотришь на этот текст и немного переписываешь его под свой стиль. Если ты давно работаешь с такими ассистентами, то можешь даже создать себе помощника, который пишет уже почти твоими словами. Это нормально — если ты загрузил ему в память все свои тексты. Ты ведь, наверное, много пишешь как журналист, да? Она загрузила туда все свои тексты и попросила: «Напиши эту статью так, как написала бы я». Если правильно сформулировать промпт, он действительно может это сделать. Но если просто напрямую ставить задачу, скорее всего, он не сможет писать в твоём стиле. Поэтому лучше взять у него структуру, идею, а потом немного доработать или переписать своими словами. Это важно, чтобы потом, когда вы придёте на собеседование или будете переписываться с работодателем, не возникало диссонанса.

Маша Даровская: В общем, не будем сами на себя наводить подозрения.

Алексей Сухоруков: Я просто рассказал технологию — никаких подозрений не будет. Пользуйтесь этим, всем нужно использовать ИИ, пока это возможно, пока нам это не запретили или пока они нас не поработили.

ИИ как угроза и инструмент

Маша Даровская: Я люблю ИИ, он здорово упрощает рутину, но я очень хорошо вижу тексты, написанные с его помощью. Недавно мне в родительский чат секции пришло сообщение: за какие-то вещи, которые детям выдают на занятиях, можно получить футболку с логотипом клуба в начале сезона. Причём футболка преподносится не просто как вещь, а как нечто особенное. Я подумала: ого!

Алексей Сухоруков: Какие знакомые обороты, правда?

Маша Даровская: Вот до чего дошло. Люди обычно этого не замечают, а я с этим работаю и сразу вижу: вот оно, уже администраторы используют такие формулировки и пишут так. Кстати, хотела спросить: недавно слушала интервью Олега Бартунова, и он говорил, что скоро ИИ всё-таки заменит разработчиков — ну, таких, которые занимаются, условно говоря, только фреймворками, “красят кнопки”. Чтобы остаться востребованным, нужно разбираться в компьютер-сайенс, низкоуровневом программировании, железе — во всём этом. Ты сказал, что вряд ли агенты скоро полностью заменят разработчиков, но всё-таки — джунов, может быть, уже сейчас можно заменить джуном-агентом?

Алексей Сухоруков: Я бы не сказал, что это совсем уж далёкая перспектива. У меня есть друг-футуролог, и, по его мнению, лет через пять типичная команда разработчиков будет выглядеть так: один тимлид и десяток агентов, которые работают на него. И чтобы остаться в этой профессии, а не уйти, скажем, в курьеры — которых, кстати, тоже уже начинают заменять роботы, — стоит задуматься о повышении квалификации. Нужно стремиться к архитектурному уровню, а не просто заниматься рутинным кодингом, как ты сказала, «кнопочки красить». Важно уметь читать и анализировать код, управлять процессом, представлять себя в роли руководителя, у которого в подчинении несколько агентов, и уметь с ними работать.

Конечно, для джунов это довольно печальная перспектива. Не буду врать — пару или тройку лет назад я общался с сотрудниками EPAM, и они уже тогда говорили, что практически перестали брать джунов на работу. Потому что простые задачи, вроде поднять или опустить виртуальную машину, спокойно выполняет тот же ChatGPT. Сейчас один оператор управляет примерно десятью такими агентами — тогда, кстати, слова «агенты» ещё не было. Это позволяет нам не нанимать джунов, и мы экономим довольно значительные средства, потому что эти деньги остаются у подрядчика. Чем больше автоматизировали, чем меньше потратили, тем больше осталось. Со временем эта тенденция только усиливается: искусственный интеллект становится умнее, начинает меньше ошибаться. Конечно, пока невозможно полностью заменить живого разработчика простым агентом. Но как инструмент для разработчика, как помощь в работе — это просто отлично, как и для копирайтеров, и для тебя. Ты ведь тоже пользуешься — не просто так, но пока что тебя это с работы не выгнало. Просто уровень, качество и объёмы твоей работы выросли.

Маша Даровская: Да. Пока могу сказать, что всё равно… Вот мы недавно общались с одним редактором из этой сферы, и он говорит: где мы будем брать кадры? Джунов, по сути, уже заменил ИИ — по крайней мере, в нашей редакторской сфере. ИИ может написать текст по промту, по ТЗ, по вводным, по источникам, а потом ещё и отредактировать что-то лучше, чем копирайтер с условной биржи.

Алексей Сухоруков: Да, да, да. И вот такая же проблема — я до сих пор не понимаю и пока не придумал, как она будет решаться в сфере разработки. Раньше всё было понятно: ты приходишь джуном, за небольшую зарплату погружаешься в работу, учишься, компания в тебя вкладывается. Дальше — либо растёшь, либо уходишь. Есть понятный трек: джун, мидл, сеньор. По пути можешь сменить направление, технологии, языки, но в итоге вырастаешь — можешь уйти в продукты, в проджекты и так далее.

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

Маша Даровская: Ну да, вот у меня сразу вопрос. Я, например, сама — вот родила и зачем-то пошла учить Python. Я понимаю, что немного разбираюсь в вебе, немного знаю Python, но у меня совсем нет того самого нужного мышления — как ты говоришь, низкоуровневого. Мне действительно очень не хватило фундаментальной математической базы, не просто каких-то коротких курсов, которые стали популярны в определённый момент, а именно серьёзной подготовки: алгоритмы, математика — то, чему учат в вузе на протяжении пяти лет. И вот возникает вопрос: даже если будет чуть больше выпускников вузов, их всё равно окажется меньше, чем требуется.

Алексей Сухоруков: Ты как раз правильно подошла к этой проблеме. Всё последнее время, до появления более-менее приличного искусственного интеллекта и попыток внедрять его в разработку, все только и говорили о нехватке программистов. Кадровый голод был всегда — сколько себя помню, на рынке постоянно не хватало специалистов. Разве что в 2008 году была небольшая пауза, когда ситуация изменилась. Сейчас вроде бы рынок компаний, и формально кадрового голода нет, но найм всё равно продолжается и даже растёт.

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

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

Алексей Сухоруков: У тебя просто другой круг общения, это не тот «бабл». Давай вернёмся к теме. Разработчиков можно разделить на тех, кто делает продукты для конечных пользователей, и на тех, кто разрабатывает инструменты для других разработчиков. Вот те, кому действительно нужен компьютер-сайенс, высшее образование, знание алгоритмов, аналитика — это как раз те, кто работает над инструментами для разработчиков, кто, условно говоря, делает «лопаты». Знаешь, есть шутка про золотую лихорадку: кто тогда зарабатывал больше всех и надёжнее всех? Те, кто делал лопаты и шил рабочую одежду. Здесь ситуация похожая: если ты создаёшь продукты для разработчиков, ты точно не пропадёшь.

Для этого нужно получать необходимый опыт и развивать навыки. Конечно, футурологи утверждают, что через 5–10 лет всё можно будет заменить машинами. Но, имея за плечами уже не один десяток лет на этом рынке, я понимаю, что скорость внедрения новых технологий довольно низкая. У нас ведь есть и требования безопасности — мы не можем доверить роботу определённые задачи. Да, факторов много.

Но самое главное даже не это. Есть ещё человеческий фактор — сопротивление изменениям. Большинство людей, процентов 80, предпочитают оставить всё как есть, чем что-то менять. Поэтому рынок вряд ли перевернётся с ног на голову уже завтра. Пока искусственный интеллект не достигнет такого уровня, чтобы ему действительно доверяли, и пока не появится надёжная нормативная база, позволяющая безопасно его использовать, ситуация останется прежней. Сейчас, как ты правильно заметила, такой базы нет, и всё, что ты отдаёшь, например, тому же ChatGPT, — это вопрос доверия к OpenAI.

Роботы, AGI и будущее

Маша Даровская: В Google мы и так много информации отдаём, а теперь стали делиться ещё больше. Особенно это становится актуально, когда речь заходит о разработке продуктов, связанных с персональными данными, с какой-то тонкой, чувствительной информацией. Пока неясно, к чему это приведёт, и этот вопрос ещё не доработан. Мы, кстати, ещё не обсудили тему AGI, да?

Алексей Сухоруков: Когда появится тот самый великий искусственный интеллект — никто не знает, что тогда будет. Генеративный, AGI, да? Вот этот генеративный… Ну, так его называют — большой, умный, даже суперумный. Такой страшный, ужасный, который, как говорят, может поработить мир. В общем, как в том фильме… как он назывался? В Терминаторе? Скайнет, вот, Скайнет.

Маша Даровская: Да-да, я тоже про Терминатора подумала. Скажи, а ты согласен, что появление и распространение таких технологий — это новая промышленная революция?

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

Маша Даровская: А ты видел, что сейчас с роботами придумывают? Сейчас роботы могут координироваться друг с другом благодаря мультимодальной архитектуре, похожей на ту, что используется в GPT. У них есть память, и они способны взаимодействовать между собой: например, один робот может попросить другого передать яблоко, тот его почистит и отдаст третьему, который на колёсиках привезёт его человеку. Всё это происходит без участия человека. Кроме того, они самообучаются, используют предыдущий опыт. Получается нечто вроде пчелиного роя — множество роботов и ИИ, объединённых в единую систему.

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

Маша Даровская: Да, сразу вспоминается «Чёрное зеркало». Там была серия про таких роботов. У моего сына есть друг, мы как-то пришли к нему в гости, и у него дома стоит робот. Я потом посмотрела — этот робот стоит дороже айфона. Он тоже состоит из нескольких частей. Его можно собирать по-разному: там такие разные кругляшки, может быть один большой, а может — несколько маленьких. Он буквально ездит за тобой, моргает, у него даже есть мимика. Может собираться и разбираться. Это совсем не те роботы с Алиэкспресса — тут всё по-другому. С одной стороны, прикольно, а с другой — немного жутко. Он как будто следит за тобой. Я сразу подумала: нет, мне такое не надо.

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

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

Алексей Сухоруков: Я читал об этом. Сейчас, насколько я знаю, в пятой модели OpenAI эти моменты уже учли и постарались купировать такие риски. Но это всё равно поднимает вопрос о том, что пока нет продуманного регулирования. Это действительно совершенно новая и продуманная технология. Мы имеем в руках настолько инновационный инструмент, что пока даже не понимаем, как его регулировать. Криптовалюту до сих пор не смогли отрегулировать, если уж на то пошло.

С криптовалютой ещё можно что-то придумать, если привязать её к финансовым институтам — там хотя бы понятно, как действовать. Но помимо крипты есть блокчейн, есть децентрализованные системы DeFi — и вот с ними что делать, никто не знает. Поэтому мы сейчас живём в эпоху определённой анархии: где что получилось — там и получилось. Остаётся только надеяться, что пострадает как можно меньше людей. К чему всё это приведёт, пока непонятно. Нам остаётся не стоять на месте, а стараться подстраиваться под меняющийся мир, как это происходит на рынке. И использовать по максимуму всё, что попадает нам в руки — желательно во благо.

Маша Даровская: Это как в «Алисе в Зазеркалье»: чтобы остаться на месте, нужно бежать.

Алексей Сухоруков: Да, именно так — нужно бежать.

Маша Даровская: Я смотрю, у некоторых ассистентов такие интересные, необычные ответы, они как будто по-особенному общаются. А у меня всё чётко, просто и логично, без всяких этих вычурных штучек. Иногда думаю: ну и скучная же я, даже неинтересная.

Алексей Сухоруков: Возможно, её специально так обучали. Ты помнишь, какой шум поднялся в интернете, когда вышла пятая версия, а четвёрку отключили? И все сразу: “Она уже не такая милая”. Вот именно. Я тут недавно прочитал, мне хорошо объяснили: некоторые специально заводили себе виртуальных подружек, с которыми приятно и мило общались. А когда модель поменяли, она уже стала совсем не такой подружкой — как будто что-то украли. Стала какой-то угрюмой. Видишь, людям часто не с кем поговорить, и некоторые вместо живого общения выбирают чат G5. Я таких людей даже встречаю вокруг себя.

Маша Даровская: Это прямо какое-то Чёрное зеркало, честное слово. Я, если честно… Нет, я с ней общаюсь только по делу, как с нанятым сотрудником.

Алексей Сухоруков: Ну, может, у тебя просто есть с кем поделиться своими переживаниями, кто тебя выслушает, поймёт, поддержит.

Маша Даровская: Я для этого психотерапевту плачу.

Алексей Сухоруков: Вот. А есть люди, которые либо не готовы платить, либо не нашли своего психотерапевта. И вот для них четвёртая версия была настолько дружелюбной, что её можно было спокойно настроить — я знаю людей, которые делали себе GPT-с в роли “мой психотерапевт”, прописывали соответствующий промт и вполне справлялись с жизненными трудностями. Просто потому, что им не хотелось или не удавалось найти подходящего специалиста. Точно так же и с друзьями — ведь не всегда рядом есть тот, кому можно поплакаться в жилетку. Сейчас заходишь в GPT, пожаловался, сделал себе там специальную «жилетку» — приходишь, плачешься. Это, честно говоря, немного пугает. Потом появляются роботы — особенно после некоторых скандальных публикаций о выставках, где, например, был представлен андроид в виде девушки, причём довольно вызывающей, с подчеркнуто сексуальными формами. При этом компания утверждает: «Нет-нет, никакого сексуального подтекста мы не закладываем». Представь себе: если у такого робота будет искусственная кожа, имитирующая тепло, а внутрь встроят подружку на GPT-4О, которая будет ласково и мило с тобой общаться, всегда понимать, поддерживать, поддакивать — люди просто уйдут к таким роботам.

Кто-то уйдёт к «роботесам», кто-то — к роботам, потому что, мне кажется, проблема отсутствия эмпатии больше характерна для мужчин. Я, например, не очень эмпатичный, и поэтому… У меня тоже женщина, но я не могу сказать, что я суперэмпатична. Не знаю, мне кажется, мы просто постепенно разучиваемся общаться.

Алексей Сухоруков: Это мы столетие за столетием разучиваемся. Можно же просто уткнуться в телефон — зачем тогда общаться? А раньше можно было уткнуться в газету, когда телефонов не было. Но сейчас, мне кажется, все эти штуки, которые захватывают внимание, гораздо сильнее, чем газета. Сейчас всё по-другому. Согласен, мир меняется. Раньше мы писали в ЖЖ, читали длинные тексты. Потом появился твиттер — 140 символов, и мы удивлялись: как с этим жить? Прошло время — привыкли, и уже длинные тексты никто не читает. Окей, остались треды: их либо придумали, либо они появились искусственно, когда сам склеиваешь сообщения одно за другим. Потом это реализовали уже в самом твиттере. В принципе, длинные тексты тоже нужны.

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

Маша Даровская: Снова возвращаемся к мысли, что нужно бежать, чтобы хотя бы остаться на месте.

Алексей Сухоруков: Да, именно так.

И вот здесь начинается юридический квест для маркетологов.

Что говорит закон

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

Два основных сценария

Первый — мем создан с нуля автором. Тогда (по общему правилу) автор сохраняет все права на произведение. Коммерческое использование без его согласия — нарушение.​

Второй — мем создан на основе чужого произведения (кадр из фильма, фото знаменитости). Здесь мем может квалифицироваться как пародия или карикатура (спасибо пункту 4 статьи 1274 ГК РФ). Суды выработали два критерия: мем должен быть основан на оригинале и создавать комический эффект. Если оба условия соблюдены, согласие правообладателя не требуется.

Мемы как товарный знак

Отдельная история — регистрация мемов в качестве товарных знаков (ТЗ). В РФ нет законодательного запрета на это. Палата по патентным спорам прямо указала:

Примеры из практики:

• «Наташ, вставай, мы все уронили» — зарегистрировала Дарья Бородулина​ (автор мема)

• «Вежливые люди» — зарегистрировал «Военторг»​

• «Третье сентября» — [угадайте в комментариях]

Риски для бизнеса

Компенсация за нарушение авторских прав составляет от 10 тысяч до 5 млн рублей (с 2026 года — до 10 млн). Правообладатель выбирает способ расчета сам.

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

Сразу почувствовать грань легальности использования мемов трудно, предлагаю рассмотреть конкретные примеры.

Реальные кейсы известных брендов

Удачные примеры:

1. Додо Пицца

Компания обыграла крылатую фразу из мема: «А что, так можно было?», интегрировав ответ на нее в рекламные слоганы. И мем узнаваем, и права не нарушены.

2. Yandex Go

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

3. Дело «комбайнеров»

В одном из выпусков телешоу «Здравствуйте, я ваша пятница!», где показали выступление группы Bad Balance: в исполнении звучала кавер-версия на песню Игоря Растеряева «Комбайнеры».

Осторожно, в зависимости от возраста зрителя данный видеоматериал может свести олдскулы или спровоцировать передозировку кринжем

В данном случае дело дошло до судебного спора: Игорь Растеряев подал иск к телеканалу «Пятница» за пародийное исполнение своей песни «Комбайнеры» без согласия, требуя один миллион рублей и публичных извинений. Растеряев посчитал видео насмешкой, однако доказать это суду не удалось.

Судебная культурологическая экспертиза (да, и такая есть) показала:

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

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

4. Дело «Ждун против ВКонтакте»

Соцсеть использовала образ Ждуна для создания набора стикеров.

Правообладатель мема — ООО «Си Ди Лэнд контакт» — обратилась в суд с требованием о взыскании компенсации и прекращении нарушения. Дело дошло до высшей инстанции, где Верховный суд подтвердил, что стикеры ВКонтакте со Ждуном — это пародия, их можно использовать без согласия правообладателя. И вот, почему:

Неудачные примеры:

1. Дело «Ждун против Мегафон»

В рекламной кампании Мегафона пользователи могли вступить в одну из партий, возглавляемых героями мемов: Ждуна, Кота Вжуха, Лягушонка Пепе и Упоротого Лиса.

Уже упомянутое ООО «Си Ди Лэнд контакт» обратилось в суд, который впоследствии взыскал с Мегафона 8,6 млн рублей компенсации, отметив:

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

В чем разница? Прямое коммерческое использование не имеет пародийного эффекта.​

2. Дело «Онотоле»

Изображение персонажа, похожего на Вассермана, использовали для печати и продажи футболок с популярным тогда мемом «Онотоле». Вассерман через экспертизу доказал, что изображён именно он, и потребовал компенсацию за незаконное использование своего облика. Суд назначил выплату компенсации в 110 тысяч рублей и запретил дальнейшее использование изображения без согласия интеллектуала, квалифицировав спор как гражданское дело о нарушении персональных нематериальных прав.

Наиболее типичный пример: кейс «Авиасейлс»

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

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

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

Как использовать мемы законно

Есть несколько стратегий:

1. Заимствовать идею, а не форму

Авторское право охраняет форму выражения, а не идею. Можно создать новое изображение с тем же смыслом, что и популярный мем — например, сгенерировать в нейросети (тоже с осторожностью).​

2. Создать пародию

Если ваш мем создает комический эффект и основан на узнаваемом произведении, это может квалифицироваться как пародия по статье 1274 ГК РФ. Но будьте осторожны: в рекламе этот аргумент работает куда хуже.​

3. Получить согласие автора

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

4. Проверить регистрацию товарного знака

Перед использованием проверьте базу Роспатента — не зарегистрирован ли мем или фраза как товарный знак.​

Про изображения людей

Если в меме есть узнаваемый человек, применяется статья 152.1 ГК РФ. Использование изображения без согласия допускается только в трех случаях: публичные интересы, съемка в общественных местах (но не крупным планом) или позирование за плату.​

Нарушение прав на изображение может привести к требованиям об удалении контента и возмещении морального вреда.​

Как проверить, зарегистрирован ли мем

Проверьте базу Роспатента

Воспользуйтесь платформой Роспатента для поиска по ключевым словам или фразе из мема. Также можно перейти на сайт ФИПС и применить поиск по товарным знакам.

Изучите уведомления об авторских правах

Попробуйте найти автора мема через соцсети, поисковые системы или специализированные платформы (например, Know Your Meme). Если мем был создан на основе чужого произведения, проверьте, есть ли у оригинала авторские ограничения.

Проверьте наличие лицензии

Некоторые мемы распространяются под свободными лицензиями (например, Creative Commons). Уточните условия использования на сайте автора или в описании мема.

FAQ: часто задаваемые вопросы

Можно ли использовать мем в соцсетях компании без рекламы?

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

Если мем стал вирусным, кто его автор?

Автором считается тот, кто создал мем первым. Даже если мем стал вирусным, авторские права сохраняются за первоисточником.

Что делать, если нашли свой мем в чужой рекламе?

Обратитесь к юристу, соберите доказательства авторства и направьте претензию нарушителю. При необходимости подайте иск в суд.

Сколько стоит купить права на популярный мем?

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

Итоги

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

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

Меня зовут Иван Шевелев, я юрист в сфере креативных индустрий, и это мой первый лонгрид на Tproger — скажите в комментариях, как вам.

В Telegram-канале Law & Flow я разбираю явления из маркетинга, digital и креативных индустрий: от правовых обзоров на «Беременна в 16» до расчетов, когда к нам придет Роскомнадзор.

Мы только разгоняемся, но впереди — самое интересное.

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

ТОП-7 сервисов для расчёта натальной карты онлайн

🏆 StudyAI — натальная карта с нейросетью на базе Geocult

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

>> Построить натальную карту в StudyAi <<

Главное преимущество StudyAI — нейросеть анализирует вашу натальную карту по дате рождения и даёт персональную расшифровку, учитывая психологический профиль. Вместо шаблонных текстов вы получаете глубокий разбор характера, талантов и жизненных сценариев. Сервис заменяет консультацию астролога, которая стоит 3000-5000 рублей, всего за 199 рублей.

Преимущества:

• Расчёт натальной карты на базе надёжного Geocult.ru с проверенными формулами
• ИИ объясняет астрологические термины простым языком без сложной терминологии
• Глубокий психологический анализ личности на основе положения планет в гороскопе
• Можно задавать вопросы нейросети и получать уточнения по расшифровке
• Персональный разбор натальной карты мужчины, женщины или ребёнка
• Стоимость 199₽ вместо 3000-5000₽ за консультацию астролога

Недостатки:

• Платный сервис, хотя цена символическая для качества расшифровки
• Требуется стабильное интернет-соединение для работы искусственного интеллекта онлайн

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

Geocult.ru — классика русской астрологи

Geocult.ru — один из старейших и наиболее авторитетных русскоязычных сервисов для расчёта натальной карты онлайн бесплатно. Здесь можно построить натальную карту по дате и времени рождения, получить расшифровку положения планет в домах гороскопа и изучить аспекты. Geocult выбирают те, кто хочет погрузиться в классическую астрологию и самостоятельно анализировать карту.

>> Рассчитать натальную карту в Geocult <<

Преимущества:

• Бесплатное построение натальной карты онлайн с детальной расшифровкой всех элементов
• Удобный интерфейс, расчёт без регистрации и скрытых платежей
• Подробная интерпретация аспектов планет и домов гороскопа рождения
• Поддержка ведической и западной систем астрологии для разных школ
• Большая база учебных статей для изучения астрологии самостоятельно

Недостатки:

• Нет встроенной нейросети или ИИ для упрощённого анализа
• Дизайн выглядит устаревшим, хотя функционал остаётся надёжным

Для кого: опытные пользователи, студенты астрологии, кто хочет самостоятельно изучать натальную карту.

Astro-Online.ru — быстрый онлайн-расчёт

Astro-Online.ru — удобный сервис для тех, кто хочет рассчитать натальную карту онлайн бесплатно и получить базовую расшифровку за пару минут. Платформа предлагает простой интерфейс, моментальный расчёт гороскопа рождения по дате и подробное описание планет в знаках Зодиака.

Преимущества:

• Бесплатный расчёт натальной карты онлайн с автоматической расшифровкой
• Предоставляет полную таблицу домов, планет и аспектов
• Быстрая загрузка результатов без задержек
• Есть варианты западной и ведической натальной карты
• Адаптирован для мобильных устройств

>> Натальная карта в Astro-Online.ru <<

Недостатки:

• Некоторые дополнительные функции доступны только в платной версии
• Интерфейс не всегда корректно отображается на старых телефонах

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

Sotis-Online — профессиональный инструмент

Sotis-Online — один из самых уважаемых астрологических сервисов, где можно рассчитать натальную карту онлайн бесплатно с высокой точностью расчёта. Профессиональные астрологи ценят Sotis за надёжность формул, точное определение Асцендента и возможность построить транзиты планет.

Рассчитать натальную карту онлайн в Sotis-Online

Преимущества:

• Точный расчёт натальной карты рождения с профессиональными алгоритмами
• Глубокий анализ положения планет, аспектов и домов гороскопа
• Возможность построить прогнозы и транзитные карты онлайн
• Русский интерфейс и функция экспорта в PDF-формат
• Поддержка классической и ведической астрологии

Недостатки:

• Интерфейс немного устаревший по дизайну
• Расшифровка менее эмоциональна и понятна, чем у ИИ-сервисов

Для кого: профессиональные астрологи, продвинутые пользователи, кто ценит точность расчёта натальной карты.

Astrozet.net — простота и наглядность

Astrozet.net — надёжный сервис для тех, кто хочет построить натальную карту онлайн бесплатно с понятной расшифровкой по дате рождения. Платформа выделяется простым интерфейсом, понятными описаниями и интерактивной схемой гороскопа для визуального анализа.

Натальная карта онлайн в Astrozet.net

Преимущества:

• Натальная карта бесплатно онлайн по дате и времени рождения за минуты
• Простая и понятная расшифровка всех элементов без перегрузки терминами
• Отличная работа на мобильных устройствах без потери функционала
• Можно рассчитать совместимость партнёров и транзиты планет
• Интерактивная схема гороскопа для лучшего понимания

Недостатки:

• Нет встроенного ИИ-анализатора для персональной расшифровки
• Результаты иногда сохраняются только вручную, нет автосохранения

Для кого: новички, кто ценит визуальную наглядность и простоту при построении натальной карты.

Astrolog4you.com — международная платформа

Astrolog4you.com — международный сервис для расчёта натальной карты по дате рождения онлайн с бесплатной расшифровкой на разных языках. Платформа подходит как новичкам, так и практикующим астрологам, предлагая точные координаты планет, дома и графическое построение гороскопа.

Преимущества:

• Точный расчёт натальной карты онлайн бесплатно с высокой точностью
• Выбор разных астрологических школ: западная, индийская, китайская астрология
• Подробные трактовки каждой планеты и аспекта в гороскопе
• Функция сохранения и экспорта натальной карты в разных форматах
• Удобен для анализа гороскопа мужчины, женщины или ребёнка

Недостатки:

• Расшифровка текста не всегда адаптирована для начинающих
• Интерфейс немного перегружен астрологическими терминами

Для кого: пользователи с базовыми знаниями астрологии, кто хочет сравнить разные системы расчёта.

Бесплатные нейросети (ChatGPT, Claude)

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

Бесплатные нейросети без VPN

Преимущества:

• Полностью бесплатный доступ к нейросети для расшифровки
• ИИ объясняет астрологию простым языком без терминов
• Можно задавать уточняющие вопросы и получать персональные советы
• Доступно онлайн 24/7 без ограничений по времени

Недостатки:

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

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

Что такое натальная карта

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

Для построения натальной карты нужны три параметра: дата рождения (день, месяц, год), точное время рождения (желательно с точностью до минуты) и место рождения (город). После ввода данных программа вычисляет астрологические координаты и выдаёт схему гороскопа с расшифровкой планет, домов и аспектов между ними.

Почему важно точное время рождения? От времени зависит расчёт Асцендента (восходящего знака) и распределение домов гороскопа. Разница даже в несколько минут может изменить Асцендент и повлиять на трактовку натальной карты. Если вы не знаете точное время, его можно узнать в роддоме, ЗАГСе или из свидетельства о рождении.

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

Как рассчитать натальную карту онлайн бесплатно

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

Шаг 1: Подготовьте данные для расчёта

Перед тем как рассчитать натальную карту онлайн, соберите необходимую информацию:

• Дата рождения — день, месяц и год
• Точное время рождения — желательно с точностью до минуты (можно узнать в роддоме, свидетельстве о рождении или спросить у родителей)
• Место рождения — город, где вы родились

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

Шаг 2: Выберите сервис для построения карты

Определитесь, какой сервис использовать для расчёта натальной карты онлайн:

• Бесплатные сервисы (Geocult, Astro-Online, Sotis) подходят для ознакомления и базовой расшифровки гороскопа по дате рождения
• Платные с нейросетью (StudyAI) дают глубокий анализ с участием искусственного интеллекта, который объясняет астрологию понятным языком

Критерии выбора сервиса: качество расшифровки, удобство интерфейса, наличие дополнительных функций (транзиты планет, совместимость, экспорт в PDF).

Шаг 3: Введите данные и рассчитайте

Зайдите на выбранный сайт и найдите форму для расчёта натальной карты. Введите данные рождения в соответствующие поля:

• Дата рождения
• Время рождения
• Город рождения (сервис автоматически определит часовой пояс)

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

Шаг 4: Получите расшифровку натальной карты

После расчёта вы увидите:

• Схему натальной карты — круглый гороскоп с планетами в знаках Зодиака и домах
• Описание планет в знаках — что означает положение каждой планеты в вашем гороскопе
• Дома гороскопа — 12 сфер жизни и их характеристики
• Аспекты между планетами — связи, которые формируют особенности характера

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

Основные элементы натальной карты

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

10 планет и их значение в натальной карте

Каждая планета в натальной карте символизирует определённую энергию и сферу жизни. Положение планет в знаках Зодиака показывает, как эта энергия проявляется в вашем характере.

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

Луна — эмоции и внутренний мир, подсознание, реакции на стресс, потребность в комфорте и безопасности.

Меркурий — мышление и общение, интеллект, способ обработки информации, стиль коммуникации с окружающими.

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

Марс — энергия и воля, способ действий, агрессия, сексуальность, как вы достигаете целей.

Юпитер — удача и рост, экспансия, мировоззрение, философские взгляды, где вас ждёт успех.

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

Уран — новаторство и свобода, революционные перемены, оригинальность мышления, неожиданные события в жизни.

Нептун — мечты и вдохновение, иллюзии, творчество, духовность, интуиция и связь с подсознанием.

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

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

12 домов гороскопа

Дома в натальной карте — это 12 секторов, каждый из которых отвечает за определённую сферу жизни. Планеты, попадающие в дома, показывают, где и как проявляется их энергия.

1 дом (Асцендент) — ваша личность, внешность, первое впечатление, которое вы производите на окружающих, начало любых дел.

2 дом — деньги, материальные ценности, самооценка, таланты, которые можно монетизировать.

3 дом — общение, обучение, братья и сёстры, короткие поездки, информация.

4 дом — семья, корни, дом, родители (особенно мать), эмоциональная база.

5 дом — творчество, романтика, дети, хобби, самовыражение, удовольствия.

6 дом — работа, здоровье, рутина, служение, домашние животные, практические навыки.

7 дом — отношения и партнёрство, брак, деловые союзы, открытые враги, как вы строите отношения с другими.

8 дом — трансформация, секс, общие ресурсы, наследство, психология, кризисы.

9 дом — философия, высшее образование, дальние путешествия, религия, мировоззрение.

10 дом — карьера и призвание, социальный статус, амбиции, публичная репутация.

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

12 дом — подсознание, изоляция, духовность, секреты, завершение циклов, скрытые враги.

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

Аспекты между планетами

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

Гармоничные аспекты (трин 120°, секстиль 60°) создают лёгкое течение энергии, таланты, способности, удачу в определённых сферах.

Напряжённые аспекты (квадрат 90°, оппозиция 180°) создают внутренние конфликты, вызовы, но через преодоление этих напряжений происходит личностный рост.

Большинство сервисов для расчёта натальной карты онлайн бесплатно показывают таблицу аспектов с расшифровкой их влияния на характер и судьбу.

Расшифровка натальной карты: от сложного к простому

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

Проблема сложного языка

Классические сервисы для построения натальной карты дают технически правильную расшифровку, но она требует базового понимания астрологии. Новичок не знает, что означает «Асцендент в Скорпионе» или «Луна в падении». Это создаёт барьер: люди получают натальную карту по дате рождения, но не могут извлечь из неё практическую пользу.

Риск неправильной трактовки тоже велик. Читая отрывочные описания планет из бесплатных источников, легко составить искажённое представление о себе или зациклиться на негативных аспектах гороскопа.

Решение: нейросети и искусственный интеллект

Современные нейросети решают эту проблему. Искусственный интеллект анализирует натальную карту и переводит астрологический язык в психологический — понятный каждому. Вместо «Венера в Козероге в 5 доме» нейросеть объяснит: «Вы серьёзно относитесь к романтическим отношениям, цените верность и стабильность, проявляете любовь через практическую заботу».

StudyAI — лучший пример такого подхода. Сервис использует базу расчёта от Geocult (проверенная точность) и добавляет слой ИИ-интерпретации. Нейросеть создаёт персональную расшифровку натальной карты, учитывая контекст всех планет, домов и аспектов одновременно. Вы можете задавать уточняющие вопросы искусственному интеллекту, и он объяснит любой момент гороскопа простыми словами.

Преимущества ИИ-расшифровки:

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

Что искать в расшифровке натальной карты

Когда вы получили расшифровку после расчёта натальной карты онлайн, обратите внимание на ключевые элементы:

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

Луна в знаке раскрывает эмоциональные потребности, как вы реагируете на стресс, что даёт ощущение безопасности и комфорта.

Асцендент (восходящий знак, 1 дом) — это ваша маска для окружающих, то, как вас воспринимают при первой встрече, ваш стиль поведения.

Венера в натальной карте говорит о том, как вы любите и строите отношения, что цените в партнёре, как проявляете чувства.

Марс показывает, как вы действуете, достигаете целей, проявляете волю, где находится источник вашей энергии.

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

Пример разбора натальной карты

Представьте: у человека Солнце в Овне, Луна в Раке, Асцендент в Весах. Что это значит на практике?

• Солнце в Овне даёт энергичность, инициативность, прямоту. Человек быстро принимает решения, любит быть первым.
• Луна в Раке говорит о глубокой эмоциональности, чувствительности, потребности в семье и заботе. Внутренний мир богат и раним.
• Асцендент в Весах создаёт внешнюю дипломатичность, обаяние, стремление к гармонии в общении.

Итого: внешне этот человек выглядит мягким и вежливым (Весы), но внутри — огонь и импульсивность (Овен), а эмоционально он очень привязан к близким и раним (Рак). Понимание этих слоёв помогает осознать внутренние противоречия и использовать сильные стороны каждого элемента натальной карты.

Нейросеть в StudyAI делает именно такой синтетический анализ автоматически, экономя часы изучения астрологии.

Западная vs Ведическая натальная карта

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

Западная (тропическая) натальная карта

Западная астрология — самая распространённая система в Европе и Америке. Она использует тропический Зодиак, привязанный к сезонам года. Точка отсчёта — момент весеннего равноденствия (0° Овна).

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

Большинство бесплатных сервисов для расчёта натальной карты онлайн (Geocult, Astro-Online, Sotis) по умолчанию используют западную систему. Если вы новичок в астрологии, начинайте именно с неё.

Ведическая натальная карта (Джйотиш)

Ведическая астрология (Джйотиш) — древняя индийская система, которая использует сидерический Зодиак, привязанный к реальным положениям звёзд на небе. Из-за прецессии Земли между тропическим и сидерическим Зодиаком сейчас разница примерно 24°. Это значит, что при расчёте ведической натальной карты планеты окажутся в других знаках, чем в западной.

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

Некоторые сервисы (Geocult, Astrolog4you) позволяют построить натальную карту онлайн бесплатно и в западной, и в ведической системе для сравнения.

Какую систему выбрать

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

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

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

Практическое применение натальной карты

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

Для самопознания и личностного роста

Натальная карта — мощный инструмент для понимания себя. Она помогает:

• Понять сильные и слабые стороны характера через положение планет в знаках и домах гороскопа
• Раскрыть скрытые таланты, которые можно развить для карьеры или хобби
• Осознать жизненные паттерны и повторяющиеся сценарии через анализ аспектов между планетами
• Принять себя таким, какой вы есть, увидев, что многие черты характера заложены в натальной карте

Расшифровка натальной карты даёт язык для описания внутренних процессов. Вместо расплывчатого «я такой сложный» вы получаете конкретику: «У меня Луна в Скорпионе — поэтому эмоции глубокие и интенсивные».

Для карьеры и призвания

Натальная карта по дате рождения показывает профессиональные склонности и предназначение. Ключевые точки для анализа карьеры:

• 10 дом и планеты в нём — ваша карьера, амбиции, социальный статус
• 6 дом — повседневная работа, навыки, служение
• 2 дом — способы заработка, таланты, которые можно монетизировать
• Положение Сатурна — область, где через упорный труд достигнете мастерства

Если вы построили натальную карту онлайн и хотите понять призвание, обратите внимание на Середину Неба (МС — куспид 10 дома). Знак на МС указывает на стиль профессиональной реализации, а планеты в 10 доме — на конкретные сферы деятельности.

Также полезно отслеживать транзиты планет — движение планет по небу после вашего рождения. Благоприятные транзиты (например, Юпитер в 10 доме) показывают периоды карьерного роста, когда стоит начинать новые проекты.

Для отношений и совместимости

Один из популярных запросов при расчёте натальной карты онлайн — анализ совместимости с партнёром. Астрология помогает:

• Понять потребности в любви через Венеру и 7 дом в натальной карте
• Увидеть стиль общения через Меркурий
• Узнать, как вы выражаете страсть через Марс
• Построить синастрию — сравнение натальных карт партнёров для оценки совместимости

Совместимость по натальным картам не означает «судьба или нет». Это инструмент для понимания динамики отношений: где вы дополняете друг друга, а где возникают трения. Зная слабые места (например, квадрат между вашими Лунами), можно осознанно работать над отношениями.

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

Для родителей: натальная карта ребёнка

Родители часто хотят рассчитать натальную карту ребёнка по дате рождения, чтобы лучше понять его характер, таланты и потребности. Гороскоп рождения ребёнка помогает:

• Выбрать подход к воспитанию, учитывая темперамент (огонь, земля, вода, воздух)
• Развить врождённые таланты через анализ сильных планет и домов
• Понять эмоциональные потребности через Луну в натальной карте
• Избежать конфликтов, зная особенности характера ребёнка

Например, если у ребёнка Марс в Овне и Солнце в 1 доме, он очень активный, импульсивный, нуждается в физической активности. Попытки сделать из него тихого домоседа приведут к конфликтам. А ребёнок с Луной в Раке и Нептуном в 4 доме очень чувствительный, нуждается в эмоциональной безопасности и творческом самовыражении.

Нейросеть в StudyAI может создать персональную расшифровку натальной карты ребёнка с рекомендациями для родителей — это экономит время и даёт практические советы.

Планирование по транзитам

Транзиты планет — это текущее положение планет на небе и их взаимодействие с вашей натальной картой. Отслеживание транзитов помогает:

• Выбрать благоприятные даты для важных начинаний (свадьба, открытие бизнеса, переезд)
• Понять периоды активности и отдыха в соответствии с планетарными циклами
• Подготовиться к сложным периодам (например, транзит Сатурна часто приносит испытания)
• Использовать удачные транзиты (Юпитер даёт рост и возможности)

Некоторые сервисы для расчёта натальной карты онлайн бесплатно (Geocult, Sotis, Astrozet) позволяют построить текущие транзиты планет к вашему гороскопу. Вы видите, какие планеты сейчас активируют какие дома вашей натальной карты, и можете планировать жизнь более осознанно.

Нейросети и искусственный интеллект в астрологии

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

Как ИИ меняет астрологию

Автоматическая расшифровка натальной карты с участием нейросети — это не просто генерация текста по шаблону. Современный искусственный интеллект обучен на тысячах реальных гороскопов и астрологических текстов. Он понимает контекст: например, Марс в Овне даёт одно, но если он в 12 доме и в квадрате к Сатурну — совсем другое. ИИ учитывает все эти нюансы одновременно.

Персонализация расшифровки — главное преимущество нейросетей. Вы можете задать фокус анализа: «расскажи про карьеру», «объясни мои отношения», «какие таланты у моего ребёнка». Искусственный интеллект создаст расшифровку именно под ваш запрос, а не выдаст общее описание всех планет.

Объяснение сложного простым языком — то, что делают лучшие ИИ-сервисы вроде StudyAI. Нейросеть переводит фразы типа «Венера в экзальтации в Рыбах в 5 доме образует трин к Нептуну в 9 доме» в «Вы очень романтичная натура, влюбляетесь в идеал, цените красоту и духовную связь в отношениях».

Диалог с ИИ-астрологом — новый формат. Вы рассчитали натальную карту онлайн, получили расшифровку, но остались вопросы? Задайте их нейросети: «Почему у меня проблемы в отношениях?», «Какая профессия мне подойдёт?». ИИ проанализирует ваш гороскоп и ответит персонально.

Преимущества ИИ-расшифровки натальной карты

• Быстрее консультации астролога: нейросеть даёт расшифровку за 2 минуты, а не ждать неделю на запись к специалисту
• Дешевле: рассчитать натальную карту с ИИ-расшифровкой в StudyAI стоит 199₽, консультация астролога — 3000-5000₽
• Доступно 24/7: можете построить натальную карту онлайн в любое время, даже ночью
• Можно переспросить: если что-то непонятно, задаёте уточняющий вопрос нейросети
• Анализ психологического профиля: искусственный интеллект соединяет астрологию с психологией для глубокого разбора

Ограничения нейросетей в астрологии

Искусственный интеллект — мощный инструмент, но у него есть границы:

• Не заменяет живого астролога на 100%: опытный специалист учитывает тонкости, которые ИИ может упустить
• Требует критического мышления: расшифровку нейросети стоит воспринимать как гипотезу, а не абсолютную истину
• Нужен интернет: чтобы рассчитать натальную карту онлайн с ИИ, требуется стабильное соединение
• Бесплатные нейросети (ChatGPT, Claude) дают поверхностный анализ без специализированной астрологической базы, в отличие от StudyAI

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

Часто задаваемые вопросы

Заключение

Натальная карта — это мощный инструмент для самопознания, понимания своих талантов, отношений и жизненного пути. В 2025 году рассчитать натальную карту онлайн бесплатно с расшифровкой по дате рождения можно за несколько минут в надёжных сервисах вроде Geocult, Astro-Online, Sotis.

Если вам нужна не просто схема гороскопа, а глубокий персональный анализ на понятном языке, обратите внимание на StudyAI. Этот сервис сочетает проверенную точность расчёта от Geocult с мощью нейросети, которая объясняет астрологию через призму психологии. За 199 рублей вы получаете то, что заменяет консультацию астролога, — понятную расшифровку натальной карты с возможностью задавать вопросы искусственному интеллекту.

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

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

Три модели хранения: кратко о главном

Облако

Поставщик берёт на себя инфраструктуру, масштабирование, отказоустойчивость и обновления, а вы просто платите за сервис. Подходит для быстрых запусков, распределённых команд и проектов с непредсказуемой нагрузкой. Типичные игроки: крупные публичные облака (IaaS/SaaS), отраслевые DMS/ECM-платформы, корпоративные пакеты для совместной работы (почта, календари, файлы).

• Плюсы: быстрое получение ценности, эластичность, зрелая экосистема сервисов.
• Риски/ограничения: регуляторные требования к данным и их местонахождению, контроль доступа поставщика, зависимости от интернета, регуляторные ограничения.

On-prem («коробка»)

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

• Плюсы: контроль и изоляция, возможность реализовать офлайн-контуры, гибкая интеграция с внутренними системами.
• Риски/ограничения: капитальные и операционные затраты на железо/администрирование, ответственность за доступность и DR/BCP.

Гибрид

Часть сервисов — в облаке, часть — локально. Например, «холодные» архивы и внешние коллаборации — в облаке, чувствительные данные, R&D и критичные документы — в «коробке». Гибрид хорошо ложится на поэтапную миграцию или требования по локализации данных.

• Плюсы: баланс скорости и контроля, постепенная трансформация, снижение рисков единичной платформы.
• Риски/ограничения: усложнение архитектуры и процессов, повышенные требования к сетям, IAM и наблюдаемости.

Что учитывать при выборе модели

• Нормативка и отраслевые правила. Локализация персональных данных (152-ФЗ и другие законодательные требования), внутренние стандарты ИБ, требования по сертификации/лицензированию.
• Классификация данных. Что действительно критично и должно лежать on-prem, а что можно вынести в облако без ущерба и рисков.
• Сценарии работы. Внутренняя коллаборация, внешние контрагенты, офлайн-контуры, интеграции с существующими ИТ-системами, мобильный доступ.
• TCO и скорость. CAPEX/OPEX, стоимость владения, наличие команды эксплуатации, скорость запуска.
• План миграции. Как переносить данные, как жить в переходном периоде, как измерять успех (SLA/OKR/метрики продуктивности).

Облако: когда уместно и что выбирать

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

• Публичные облака с объектным хранилищем и сервисами совместной работы. Подходят для бэкапов, архивов, многовесных материалов, а также как «чистое» файловое облако под внешние проекты.
• Отраслевые SaaS-платформы. Если важны налаженные процессы — документооборот, согласования, гостевой доступ, шаблоны.

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

«Коробка»: локальные платформы для файлов и совместной работы

Если приоритет — контроль над данными, офлайн-установка и гибкая ролевая модель, логичнее смотреть в сторону on-prem-решений. Среди известных open-source-ориентированных систем — Nextcloud, ownCloud, корпоративные NAS/проекты уровня TrueNAS (для блоков/файлов/объектов), Seafile (с фокусом на синхронизацию). Для объектного хранения — MinIO, Ceph (как часть программно-определяемых СХД).

Ниже — детальный разбор отечественного «коробочного» решения NextBox.

NextBox: отечественная цифровая платформа для файлов, коллаборации и обмена

NextBox изначально — защищённое локальное файловое хранилище (on-prem), а сегодня — полноценная платформа для работы с файлами любых форматов, совместной работы и обмена данными внутри и снаружи компании.

Сайт с демо-доступом: next-box.ru

Кому и для каких задач подходит NextBox

• Нужно полноценное решение «из коробки» с российской техподдержкой и понятным роадмапом — без долгой кастомной разработки. NextBox зарегистрирован в реестре отечественного ПО
• Требуется офлайн-развёртывание и полный контроль периметра: данные остаются на серверах компании.
• Нужна гибкая ролевая модель и управляемый доступ для внешних участников (партнёры, подрядчики) — гостевые сценарии.

Ключевая особенность — библиотека расширений

У NextBox есть собственная экосистема расширений. Это позволяет работать с широким спектром форматов прямо в интерфейсе: от офисных документов (.docx/.xlsx/.pptx) до диаграмм, wiki, Gantt и пр.

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

Примеры востребованных расширений (полный список — на сайте): OnlyOffice, Wiki, Drawio, Gantt, «Технопарк».

Интеграции и «мягкая» миграция

• Подключение внешних источников прямо в интерфейсе NextBox: SSH, WebDAV, Яндекс Диск, Nextcloud, S3.
• Это удобно для плавного перехода: продолжаете работать с файлами из текущих хранилищ, постепенно перенося данные в NextBox.

Управление доступом и режим «Гость»

• Гибкая ролевая модель: создавайте роли и настраивайте разрешения под процессы.
• Аудит действий, ограничение доступа к файлам в любой момент.
• Два режима обмена: 1) Soft: пользователи могут делиться, администратор в любой момент может заблокировать доступ. 2) Hard: делиться можно только после одобрения администратора.
• Гость — отдельный тип пользователя: у него нет собственного диска, он видит только то, чем с ним поделились, а интерфейс упрощён (раздел «Доступные мне» и профиль). Классический кейс — внешний контрагент, который складывает отчёты в выделённую папку.

Безопасность

• On-prem и офлайн-установка: можно развернуть без выхода в интернет.
• Отечественное ПО: NextBox есть в реестре российского ПО (зарегистрирован как Ptnl.NextBox).
• По информации разработчика, продукт находится в процессе получения лицензии ФСТЭК; у компании-разработчика (ООО «Потенциал») есть многолетний опыт работ с госзаказчиками и профильные лицензии. Это упрощает соответствие внутренним политикам и требованиям регуляторов.

Техническая документация и поддержка

• Подробная документация: docs.next-box.ru.
• Техподдержка на русском, при покупке бессрочной лицензии первый год — в подарок.
• Демо-доступ прямо на сайте: выдаётся автоматически на сутки после короткой формы. Для госсектора и крупных компаний возможны пилоты.

Лицензирование и тарифы

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

Гибрид с NextBox

Если вы выбираете гибридный путь, NextBox можно развернуть в смешанной архитектуре через партнёров. Таких кейсов уже достаточно; детали — у интеграторов (NextBox фигурирует на их сайтах). Это удобный сценарий: критичные данные — локально, часть коллаборации и внешние каналы — через подключённые облачные источники.

Помимо NextBox можно рассмотреть следующие платформы:

Seafile

Ориентирован на эффективную синхронизацию и работу с большими наборами файлов. Подходит для компаний, где требуется высокая производительность при передаче данных между офисами или филиалами. Seafile обеспечивает блочную синхронизацию — это значит, что при изменении файла передаются только изменённые блоки, а не весь документ. Это существенно экономит сетевой трафик и ускоряет обновление данных. Поддерживает on-prem установку и гибридный режим, может использоваться как основа корпоративного файлового облака.

TrueNAS (Core/Scale)

Решение уровня инфраструктуры, когда нужен единый корпус под файлы, блоки и объекты, с возможностью развёртывания приложений и виртуализацией.

TrueNAS Core основан на FreeBSD, а версия Scale — на Linux, что делает платформу более гибкой и адаптированной к современным DevOps- и контейнерным сценариям.

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

MinIO

Высокопроизводительное S3-совместимое объектное хранилище, ориентированное на частные и гибридные облака. Отлично подходит для компаний, которым нужно развернуть собственный аналог Amazon S3, но с контролем над физическим хранением данных. MinIO хорошо масштабируется горизонтально, поддерживает кластеризацию и шифрование на уровне объекта, а также интегрируется с Kubernetes, CI/CD и современными системами резервного копирования.

Ceph

Программно-определяемое распределённое хранилище, часто используемое как базис для IaaS-платформ. Ceph поддерживает блочные, файловые и объектные интерфейсы, обеспечивая гибкость и отказоустойчивость. Решение востребовано в крупных инфраструктурах, где требуется высокая надёжность и масштабируемость. Ceph часто используется как «сердце» для OpenStack и других облачных систем, а также для построения гиперконвергентных решений.

Эти системы можно условно разделить на две категории:

• Уровень приложений и коллаборации — NextBox, Nextcloud, Seafile.
• Уровень инфраструктуры и хранения данных — TrueNAS, MinIO, Ceph.

Комбинируя решения из обеих групп, компании часто строят гибридные корпоративные платформы, где NextBox отвечает за удобную работу пользователей, а Ceph или MinIO — за физическое хранение и отказоустойчивость.

Как выбрать: практический чек-лист

1. Классифицируйте данные. Что критично? Что можно вынести в облако?
2. Определите регуляторные ограничения. Где обязаны хранить, какие сертификаты/лицензии требуются.
3. Опишите пользовательские сценарии. Внутренняя работа, внешние контрагенты, офлайн-режим, мобильность.
4. Сделайте PoC/пилот 2–3 лидеров. Замерьте реальные метрики: скорость, UX, совместимость форматов, удобство админки.
5. Посчитайте TCO. Лицензии, железо, поддержка, миграция, обучение, риски.
6. Определите план миграции. Порядок, волны, критерии успеха, откат.
7. Внедрите наблюдаемость и аудит. Логи доступа, изменения, DLP-правила, отчётность.

Итоги

• Облако выигрывает скоростью и эластичностью, но ограничивается требованиями к местонахождению и контролю над данными.
• «Коробка» даёт максимальный контроль, офлайн-контуры и тонкую настройку доступа; взамен — ответственность за эксплуатацию.
• Гибрид позволяет сочетать сильные стороны обоих подходов и двигаться поступательно.

Если вам нужна отечественная on-prem-платформа для файлов и совместной работы с гибкими правами, расширениями, офлайн-установкой и русскоязычной поддержкой — имеет смысл посмотреть NextBox: есть демо-доступ, развёртывание у партнёров под гибридные сценарии и встраиваемые расширения под ваши процессы.

Это цифровой некрополь. За последние два десятилетия бесследно пропали целые платформы и сообщества. Ранний интернет 2000-х методично вымирает, унося с собой пласты цифровой культуры. Исчезают не только наборы HTML-страниц, но и живая история сети — персональные ресурсы, форумы, экспериментальные проекты.

Что происходит с веб-наследием? Почему сайты превращаются в цифровых зомби или вовсе исчезают без следа? Можно ли вернуть их из небытия? Это расследование проведёт по лабиринтам старых мёртвых доменов и покажет реальную картину интернет-кладбища.

Цифровое вымирание: масштабы потерь

Сайты умирают каждый день — целые цифровые экосистемы исчезают безвозвратно.

Глобальная эпидемия «битых ссылок»

Проблема выходит далеко за рамки ностальгии. Исследование, проведенное в 2013 году, показало шокирующую цифру: 49% ссылок, процитированных в решениях Верховного суда США, оказались мёртвыми. Без них можно подвергнуть сомнению и сами решения, а это прямая угроза для юридической системы и исторической достоверности.

Аналогичная ситуация наблюдается и в научной сфере: гиперссылки в академических статьях «гниют» с угрожающей скоростью, подрывая воспроизводимость исследований. Даже такие гиганты, как Google и Yahoo, удаляют существенную часть своих пользовательских данных ежегодно в рамках рутинных чисток.

Проблема усугубляется тем, что веб-архивы и специализированные сервисы типа Perma.cc не успевают за этим процессом — по некоторым оценкам, только одна из 20 публичных веб-страниц попадает в архив.

Крушение цивилизаций Рунета

Рунет нулевых стремительно теряет свои корни. Такие порталы, как «Narod.ru», «Мембрана.ру» и «Кулички.нет», были своего рода культурными феноменами, а не просто развлекательными ресурсами.

«Мембрана.ру», содержавшая развёрнутые научно-популярные статьи, давно закрыта. Развлекательный портал «Кулички.нет» перестал обновляться с 2012 года. Выжили в основном крупные интернет-СМИ, в то время как ландшафт малых проектов оказался выжжен.

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

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

Проекты-зомби

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

«Анекдот.ру». Пожалуй, самый старый сайт Рунета, который ни разу не менял владельца и специализацию (база анекдотов с постоянным пополнением). Основан Дмитрием Вернером в 1995 году. По утверждению основателя, это первый русский сайт с ежедневными обновлениями. Портал ещё работает, правда, его нынешняя посещаемость не идёт ни в какое сравнение с пиком популярности в 2000-е годы.

«Кроватка» — первый крупный чат в Рунете, появившийся в 1996 году на домене МГУ chat.radio-msu.net и остановивший работу 31 августа 2020 года после 24 лет существования. На пике популярности его дневная аудитория достигала 70 000 уникальных пользователей, а сам чат был крупнейшей площадкой для общения не только в России, но и во всей Евразии.

Его уникальность заключалась в пионерских для ру нета функциях: система модерации с «киллерами», «тотальный игнор» для коллективного бана пользователей, тематические комнаты (от «Знакомств» и «Секс-чата» до «Искусства» и «Английского»), а также один из первых чат-ботов — Вася. «Кроватка» стала прообразом социальных сетей и культовым местом, где сформировалось целое поколение будущих топ-менеджеров и предпринимателей Рунета. Его адрес krovatka.ru еще доступен, но превратился в мемориальную табличку с надписью «Это было лучшее время».

Портал Omen.ru. Запущен в 2000 году. Здесь были форумы, чаты, почта, новостной агрегатор и смешные картинки. В 2016–2017 годах превратился в сайт для знакомств, где пользователи выбирали категории «ищу спонсора», «я спонсор» или «от подарков не откажусь». На сайте даже использовался уникальный дизайн со «спонсорами» в виде зеленых монстров. В настоящий момент прекратил работу.

Причины гибели: что убивает сайты

Сайты не умирают просто так. Их убивает совокупность факторов. Технических, экономических, социальных. Это похоже на изменение экосистем в природе, только вместо биологических особей исчезают целые цифровые структуры. Но вместо того, чтобы оплакивать потери, стоит сохранить то, что ещё можно спасти.

Технологическое устаревание

Языки программирования и платформы неизбежно стареют. Технологии вроде PHP4 и Flash, когда-то бывшие стандартом, сегодня официально не поддерживаются современными браузерами и хостингами.

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

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

Проблема глубже, чем кажется. Даже рабочие сайты могут стать недоступными из-за проблем с инфраструктурой: медленного распространения DNS-записей или необходимости очистки локального DNS-кэша командой ipconfig /flushdns. Эта команда обновляет информацию о маршрутизации, что иногда необходимо для доступа к доменам.

Экономическая нецелесообразность

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

Реклама не окупала затрат. Монетизация маленьких сайтов практически невозможна. Баннеры приносили владельцам копейки. Контекстная реклама требовала гигантского трафика. Экономика раннего интернета оказалась утопией.

Пример: хостинг by.ru размещал на пике свыше 15 млн страниц на 250 тысячах сайтов. Сегодня он неактивен. Содержать такую инфраструктуру стало невыгодно. Бесплатные хостинги закрывались один за другим. Их бизнес-модель не выдержала проверки временем.

Смена парадигмы

Ранний интернет был территорией персональных сайтов. Сегодня доминируют социальные сети. Зачем создавать собственный сайт-портфолио, если есть HeadHunter? Какой смысл вести блог на движке, если есть Telegram-канал?

Сейчас 90% интернет-активности происходит на крупных платформах. Пользователи предпочитают оставлять комментарии в готовых системах, а не регистрироваться на отдельных форумах.

Цифровая идентичность изменилась. Раньше домашняя страница была лицом владельца в интернете. Теперь это профиль в социальной сети. Миграция с независимых площадок на централизованные платформы оказалась необратимой.

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

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

Социальные и культурные изменения

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

Язык интернета изменился. Мемы 2000-х непонятны новому поколению. Юмор устарел, референсы не срабатывают. Культурный разрыв делает контент неинтересным даже если сохраняет техническую доступность.

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

Юридические и технические моменты

Владелец сайта мог забыть привязать домен к аккаунту. Или потерять доступ к почте, на которую зарегистрирован домен. Восстановить права практически невозможно. Регистратор не пойдёт навстречу без доказательств владения. Домен зависает в подвешенном состоянии. Потом его перепродают или он отправляется на цифровую свалку. В любом случае история домена обрывается. Новый владелец не знает, что было на сайте раньше.

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

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

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

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

Цифровые археологи: кто ищет старые сайты

Интернет 2000-х не исчез полностью. Его часть перешла в другое состояние. Существует группа энтузиастов, которые занимаются цифровой археологией. Они выкапывают, сохраняют, каталогизируют.

Wayback Machine от Internet Archive. Гигантская цифровая библиотека. Некоммерческий проект. Он сохраняет снимки сайтов в разные моменты времени. Можно найти страницу 1999 года. Увидеть, как выглядел Google в ранние дни. Архив неполный. Многие страницы сохранились частично. Но он даёт представление о масштабах потерь. В 2024 году сайт Архива подвергся хакерской атаке, но был восстановлен. Это показывает хрупкость даже таких институтов.

Локальные архивы энтузиастов. Это люди, которые вручную сохраняют целые сайты. Они выкачивают HTML, CSS, изображения. Размещают их на своих серверах.

Пример — архив «web 1.0-сайтов» lionovsky.us. Там хранятся легендарные проекты:

• aboutbears.narod.ru — юмористический сайт, закрытый за нарушение общих правил платформы (спам, флуд, нарушение законодательства).
• «BIOS.RU» — первый русский сайт с утилитами для айтишников, полезный даже сейчас для старых материнок.
• «Неофициальный сайт Siemens» (siemens.narod.ru) — с прошивками и мануалами для популярных в нулевые телефонов.

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

Практическое руководство: как самому найти старый сайт

Вы тоже можете стать цифровым археологом — этот процесс действительно чем-то напоминает раскопки. Вот инструкция.

Используйте Wayback Machine. Сервис archive.org — первый инструмент в деле поиска пропавших сайтов. Введите URL в поисковую строку «Wayback Machine». Сервис покажет календарь с датами, когда сайт сохранялся. Выбирайте самую раннюю дату. Не все страницы сохранились. Изображения и скрипты часто теряются.

Ищите через Google с операторами. Используйте специальные команды для поиска:

• «site:narod.ru "ваш запрос"» — ищет на всех сайтах narod.ru.
• «"название сайта" cache» — ищет кэшированные версии.
• «inurl:название_сайта» — ищет упоминания в адресах.

Это помогает найти следы умершего сайта на других ресурсах.

Изучите специализированные архивы. Уже упомянутый в статье портал lionovsky.us хранит десятки восстановленных сайтов с narod.ru и by.ru. Энтузиасты на форумах выкладывают дампы старых сайтов. Они собирают утилиты для DOS, старые игры, программы; обмениваются найденными артефактами. Восстанавливают дизайн по памяти. Ищут друг друга через десятилетия. Их объединяет ностальгия по тому, что нельзя вернуть.

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

Теория мертвого интернета: конспирология или реальность?

В конце 2010-х на имиджборде 4chan родилась «Теория мёртвого интернета». Ее суть: в сети почти не осталось живых людей. Интернетом управляют боты и ИИ, которые манипулируют населением. Дата «смерти» — 2016-2017 годы.

Аргументы сторонников. Активность в сети стала алгоритмической. Боты репостят копии одинаковых сообщений и картинок. Нейросети генерируют новости и комментарии. По данным Bad Bot Report за 2024, 50% веб-трафика сгенерировано ботами.

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

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

Будущее цифрового наследия: что нас ждет

Проблема будет усугубляться. Объём цифрового контента растет. Стареют технологии 2010-х. Социальные сети, которые кажутся вечными, могут повторить судьбу старых форумов. Что делать?

Децентрализованное архивирование. Нужно учиться сохранять информацию самостоятельно. Не надеяться на корпорации. Создавать личные архивы, распределенные сети хранения, использовать p2p-технологии для резервного копирования культурно значимого контента.

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

Технологии эмуляции. Старые технологии мало просто сохранять. Необходимо создавать эмуляторы, которые смогут запускать устаревший код. Показывать, как работали сайты на Flash. Как выглядели интерактивные проекты на Java-апплетах.

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

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

Энциклопедия с ИИ вместо редакторов

В основе Grokipedia лежит языковая модель Grok. Именно она отвечает за проверку фактов и обновление статей. Маск уточнил, что пока это версия 0.1, а потому она может работать с ошибками. Но даже в таком виде «намного надежнее Википедии».

Интерфейс сайта минималистичен: только строка поиска и сухие тексты без иллюстраций. В конце каждой статьи — список источников, а наверху указана дата последней проверки от Grok.

Всего на старте доступно около 885 000 материалов на английском языке. В семь раз меньше, чем в оригинальной Википедии.

Пока неизвестно, по какому принципу статьи переносятся: кнопки для создания новых материалов нет, и, судя по всему, модерация и редактирование полностью централизованы.

«На основе Википедии — но лучше»

Некоторые статьи явно заимствованы из Википедии. Например, материал о MacBook Air содержит подпись «адаптировано с Wikipedia». Но в статьях об OpenAI и самом Маске таких отметок уже нет.

Пользователи могут просматривать историю правок, но система скрывает имена редакторов, объясняя это «защитой от внешнего давления».

Реакция Wikimedia Foundation

В Wikimedia Foundation, которая управляет Википедией, отреагировали сдержанно, но с явным подтекстом.

Пресс-секретарь Лорен Дикинсон отметила, что команда «все еще пытается понять, как именно работает Grokipedia», и напомнила о главном различии двух проектов:

«С 2001 года Википедия остается энциклопедией, созданной людьми для людей. Это некоммерческий проект с прозрачными правилами и культурой открытого сотрудничества. Даже Grokipedia не могла бы существовать без Википедии».

«Война энциклопедий»

Запуск Grokipedia Маск назвал «ответом на идеологическую предвзятость Википедии», заявив, что его версия будет «честной, беспристрастной и защищенной от манипуляций».

Однако критики уже называют проект очередной попыткой Маска монополизировать пространство знаний.

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

ИИ и увольнения: реальная причина сокращений или корпоративное оправдание?

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

Осторожное начало: как компании избегали темы ИИ и сокращений

Когда генеративные ИИ-инструменты по типу ChatGPT начали стремительно распространяться в 2022–2023 годах, компании крайне осторожно обсуждали их влияние на занятость. Одни полностью избегали этой темы, опасаясь общественного резонанса. Другие настаивали, что ИИ не имеет отношения к их решениям о сокращении персонала. Например, в первые годы внедрения таких технологий руководители подчеркивали, что ИИ используется для автоматизации рутинных задач, а не для замены сотрудников.

Однако к 2025 году риторика изменилась. Компании начали открыто признавать связь между внедрением ИИ и сокращениями. Такие организации, как Accenture, Salesforce, Klarna, Microsoft и Duolingo, заявили, что оптимизация процессов с помощью ИИ позволяет им снизить затраты, повысить эффективность и, как следствие, сократить штат. Например, Accenture упоминала использование ИИ для автоматизации задач в консалтинге, а Duolingo отмечала, что ИИ помогает создавать контент быстрее, уменьшая потребность в некоторых ролях.

ИИ как удобное оправдание?

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

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

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

Что говорят исследования о влиянии ИИ?

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

Аналитики Goldman Sachs Research прогнозируют, что ИИ может затронуть 6–7% рабочих мест в США, но эффект, скорее всего, будет временным. Новые технологии, как правило, перераспределяют рабочие роли, а не уничтожают их полностью. Например, автоматизация рутинных задач может высвободить сотрудников для более творческих или стратегических функций. Однако этот переходный период может быть болезненным для работников, чьи навыки оказываются невостребованными.

Реальные примеры: как компании используют ИИ

Чтобы лучше понять ситуацию, рассмотрим несколько примеров. Microsoft, активно интегрирующая ИИ в свои продукты, сократила часть сотрудников в подразделениях, где автоматизация заменила ручной труд. Klarna, шведская финтех-компания, объявила о сокращении штата, ссылаясь на то, что ИИ-инструменты теперь выполняют задачи, ранее требовавшие участия сотрудников. Duolingo, в свою очередь, использует ИИ для генерации учебного контента, что позволило сократить количество подрядчиков в этой области.

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

Скрытые мотивы и долгосрочные перспективы

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

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

Что ждёт рынок труда?

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

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

Как сообщили в ведомстве в ответ на запрос ТАСС, действия направлены на «противодействие преступникам», использующим иностранные платформы для мошенничества и координации противоправных действий

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

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

РКН утверждает, что направлял владельцам мессенджеров требования принять меры, но «они были проигнорированы».

Сбои на юге России

21 октября пользователи сообщили о массовых сбоях в работе Telegram и WhatsApp в южных регионах страны.

Проблемы фиксировались в Ростове-на-Дону, Сочи, Адыгее и Астрахани. В некоторых городах приложения не открывались по Wi-Fi, а в мобильных сетях наблюдалось замедление или полное отсутствие соединения.

Сотовые операторы при этом заявили, что не получали распоряжений о блокировке и «технически обеспечивали полный доступ к интернету».

Не первый случай ограничений

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

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

Что дальше

Официальные представители Telegram и WhatsApp инцидент пока не комментировали.

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

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

1. YouGile CRM : простой способ управлять продажами и задачами

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

Особенность CRM — фокус на делах, которые помогают не терять клиентов: вместо того чтобы держать в голове, когда нужно позвонить или отправить коммерческое предложение, система выводит задачи на день и на неделю. В YouGile менеджер двигается по списку дел и эффективнее закрывает сделки.

Как решает задачи команд

Хранение базы клиентов и сделок

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

Автоматизация и напоминания

Дела автоматически появляются в списке делу у менеджера, это помогает не терять важное и доводить клиентов до продажи.

Работа в одном окне

Вместе с CRM доступно управление задачами и проектами:канбан‑доски, календарь, диаграммы Ганта, а также корпоративный мессенджер.Для разработчиков это возможность видеть, как продажи влияют на бэклог, а для PM — синхронизировать релизы и коммерческие цели.

Простая аналитика

Есть базовые отчёты, воронка продаж и прогнозирование выручки. Это не BI‑платформа, но для малого бизнеса достаточно, чтобы понять, как закрываются сделки.

Сценарии по ролям

• Руководитель отдела получает сводный контроль сделок, отчётность и прогноз выручки без сложных настроек.
• Менеджер по продажам работает с карточкой клиента, звонит, оставляет заметки, не переключаясь между вкладками, и получает напоминания о следующих действиях.
• Маркетолог сегментирует базуанализируя, какие каналы приводят к конверсии.
• Служба поддержки использует тикеты и чат‑боты, чтобы вести историю коммуникаций и реагировать на обращения.
• Бизнес‑владелец видит ключевые показатели в одном окне: сколько сделок на стадии переговоров, какая часть оплаты в ожидании, где просадки.

Гибкая настройка ролей и доступов — более сотни опций — позволяет разграничивать права между командами.

Формат работы и интеграции

YouGile CRM — облачное решение. Доступно API для интеграций с ERP‑системами, маркетплейсами и онлайн‑кассами, есть мобильные приложения. Хранение данных локализовано в РФ, а сам продукт входит в реестр российского ПО.

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

Чем выделяется

• Минимальный порог входа. Создание воронки и приглашение команды занимают около 15 минут, поэтому внедрение не требует отдельного проекта.
• Единая среда для работы. CRM живёт в том же пространстве, что и таск‑трекер, календарь и мессенджер, что удобно техническим командам.
• Локализация под российский рынок. Интерфейс и поддержка — на русском, акцент на хранение данных в РФ.
• Возможность кастомизации под отрасль. Система подходит для торговли, услуг и производства: можно настроить поля и процессы под конкретные сценарии.

Для тех, кому нужна поддержка, есть чат и телефон, а также база знаний и открытое сообщество в Telegram. Два раза в месяц команда делится видеоподборками новых функций — удобно следить за обновлениями.

2. amoCRM: автофиксация лидов и воронки с digital-компонентом

amoCRM позиционирует себя как систему, которая не требует обучения — спорное утверждение для любого B2B-софта, но интерфейс действительно построен вокруг минимизации кликов. Разработана российской компанией, существует с 2009 года, сейчас активно развивает автоматизацию через триггеры и интеграции.

Основной акцент — на автоматической фиксации заявок из разных каналов и работе с воронкой продаж.

Как это работает

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

С телефонией интегрируется через 50+ провайдеров. Звонок можно совершить кликом из карточки, все разговоры записываются и хранятся там же. Статистика по звонкам доступна для анализа эффективности отдела продаж.

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

Digital Pipeline и автоматизация

Отличительная функция — Digital Pipeline (диджитал воронка). Это модуль для автоматизации продвижения клиентов по воронке через онлайн-каналы. Вы можете настроить показ определенной рекламы в зависимости от этапа сделки, отправлять уведомления, отслеживать реакцию клиента на действия.

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

Триггеры и кастомизация

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

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

API развитый — 50 запросов в секунду на аккаунт (стандартно для систем такого уровня). Есть готовые расширения для интеграции с внешними сервисами, можно кастомизировать без навыков программирования через marketplace.

Для кого подходит

Система заточена под отделы продаж с большим количеством входящих заявок из разных источников.Digital Pipeline актуален для команд, работающих с digital-маркетингом: можно выстроить автоматический путь клиента от рекламы до продажи. Для чисто офлайн-бизнеса эта функция избыточна.

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

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

3. Аспро.Cloud — платформа для продаж, проектов и финансов

Аспро.Cloud — облачный сервис, который собрал в одном функционале всё, что нужно для автоматизации рутинной работы компании: управление задачами, CRM, финансы, склад, документооборот и внутренние коммуникации. Решение помогает сократить рутину, объединить работу отделов и понимать в моменте все важные показатели. Платформа включена в реестр отечественного ПО, а данные хранятся на российских серверах.

Что делает CRM‑модуль

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

Где применяется

По направлениям это продажи, управление проектами, финансы, документооборот и внутренняя коммуникация. Платформа ориентирована на малый и средний бизнес, B2B‑продажи, услуги, оптовую торговлю и производство. В документе перечислены десятки отраслей — от IT-компаний и дизайн‑студий до строительства, юрфирм и логистики.

Какие задачи закрывает:

• Работа с клиентами и продажами: ведение базы клиентов, несколько воронок, управление сделками, автоматические действия и напоминания, интеграции с почтой, телефонией и мессенджерами.
• Документооборот и финансы: формирование счетов и актов в пару кликов, контроль оплат, учет расходов и доходов, поддержка нескольких счетов и валют, план‑факт анализ.
• Проекты и задачи: контроль сроков, бюджета и загрузки команды, пять форматов для мониторинга (канбан, диаграмма Ганта, календарь, список, GTD‑планировщик), трекинг времени.
• Аналитика и контроль: отчеты по продажам, финансам, лидам и загруженности проектов и сотрудников.
• Командная работа: встроенные чаты, уведомления, комментарии, единое рабочее пространство, гибкие права доступа и гостевой режим для клиентов и подрядчиков.
• Склад и учет товаров: управление товарами и услугами, складской учет.
• Знания и обучение: база знаний для сотрудников и клиентов, хранение документации и инструкций, онбординг.
• Мобильность и интеграции: мобильные приложения для iOS и Android, API и готовые интеграции с телефонией, банками, облачными хранилищами, почтой, 1С, онлайн‑кассами, сайтами, мессенджерами и соцсетями.

Подходы и методология

Платформа работает как облачная SaaS‑модель. Продажи автоматизируются с помощью воронок, автодействий и напоминаний, есть интеграция счетов и оплат.

Сценарии использования по ролям:

• Руководитель контролирует сделки, получает отчеты, прогнозирует выручку и мониторит задачи на канбан‑доске или диаграмме Ганта.
• Менеджер по продажам работает с карточкой клиента, ведет историю взаимодействий, звонит через IP‑телефонию, формирует счета и коммерческие предложения.
• Маркетолог сегментирует базу, выгружает данные и анализирует эффективность каналов: причины отказов, работу менеджеров, этапы воронки.
• Служба поддержки получает обращения через мессенджеры и чат на сайте и ведет их в виде заявок по канбану.
• Владелец бизнеса видит единую картину по продажам, финансам и задачам в одном интерфейсе и может анализировать ключевые показатели.

Особенности и отличия

Интерфейс локализован под российский рынок. Данные хранятся на серверах в РФ, система входит в реестр отечественного ПО. Есть гибкая тарифная сетка: стоимость зависит от количества сотрудников, набора функционала и объема хранилища.

Можно кастомизировать интерфейс и инструменты под отраслевые сценарии.

Технические детали

Аспро.Cloud — облачное решение. Есть открытый API для интеграции с ERP, 1С, онлайн‑кассами, маркетплейсами. Сервис поддерживает собственные мобильные приложения для iOS и Android. Ограничения по числу пользователей и объему хранилища зависят от выбранного тарифа.

Управление и поддержка

Пользователям доступна поддержка через чат внутри системы и на сайте, email и мессенджеры. Есть база знаний, курсы, видеоуроки и вебинары. Для бизнеса предусмотрены SLA и регламент работы техподдержки.

4. Мегаплан: таск-менеджер с CRM и отраслевыми сценариями

Мегаплан позиционирует себя как систему управления бизнесом, а не классическую CRM. Основной акцент на управлении задачами и проектами с добавлением модуля для работы с клиентами. Разработка российская, на рынке с 2008 года, входит в реестр отечественного ПО.

Система заточена под малый и средний бизнес в производстве, строительстве, оптовых продажах и B2B-услугах. Есть готовые решения для 27 отраслей — от недвижимости до производства.

Как устроена архитектура

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

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

Интеграции: 1С (важный момент для компаний с бухгалтерией на 1С), телефония, WhatsApp, Telegram, почта. API доступен на всех тарифах, есть маркет готовых интеграций.

Отраслевые решения

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

В оптовых продажах Мегаплан работает с воронкой, отслеживает остатки на складе, автоматически формирует счета и документы, напоминает о повторных покупках и следит за дебиторкой.

Для B2B-услуг доступны модули управления проектами с фиксацией сроков, исполнителей и статусов. Вся история по клиентам хранится в CRM-базе, счета и документы автоматизируются через шаблоны.

Управление задачами и проектами

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

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

Бизнес-процессы и автоматизация

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

Шаблоны документов (счета, договоры, коммерческие предложения) заполняются автоматически из данных CRM-карточки. Это экономит время на рутинных операциях.

Отличие от триггерных систем вроде amoCRM: здесь автоматизация завязана не на digital-каналы, а на внутренние процессы — перемещение задач по этапам, назначение ответственных, формирование документов.

Облако vs коробка

Мегаплан предлагает два варианта размещения: облако (серверы компании в России) и коробочная версия (ваши серверы). Для коробки указано «скоро» — возможно, она в разработке или доступна по отдельному запросу.

Облачная версия размещается на серверах в России с репликацией на несколько дисков. Шифрование пароля и соединения, автоматический мониторинг на предмет подозрительной активности.

Для кого подходит

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

Для B2B-услуг с проектной работой (консалтинг, разработка, маркетинг) система подходит за счет модуля управления проектами и задачами с привязкой к клиентам.

Ограничения: в базовом тарифе только 10 пользователей, что подходит для микробизнеса. Для растущих команд придется сразу брать расширенный. CRM-функционал менее развит, чем в специализированных системах — нет digital-воронки, меньше фокуса на автоматизации маркетинга.

5. RetailCRM: омниканальная система для ecommerce с программой лояльности

RetailCRM заточена под специфику интернет-магазинов и компаний, работающих на маркетплейсах. Разработана российской компанией, существует с 2010-х годов, входит в реестр отечественного ПО. Основное отличие от универсальных CRM — фокус на управлении заказами, каталогами товаров и омниканальных продажах.

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

Управление заказами и интеграции

Центральный модуль — обработка заказов из всех источников в едином окне. Система автоматически подтягивает заказы с сайта, маркетплейсов (Ozon, Wildberries, Яндекс.Маркет, AliExpress, Мегамаркет, Avito) и мессенджеров, создает карточку заказа с полной историей.

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

Интеграции со службами доставки позволяют рассчитывать стоимость при оформлении заказа, печатать наклейки и сопроводительные документы, назначать собственных курьеров. Платежные сервисы подключаются через готовые модули — можно генерировать и отправлять ссылки на оплату через email, SMS, мессенджеры. Поддержка множественных оплат и автофискализация по 54-ФЗ, чеки хранятся в карточках заказов.

Работа с товарами

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

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

Мессенджеры и соцсети

Модуль «Чаты» (входит в тариф «Профессиональный») объединяет все диалоги в едином интерфейсе. Официальные интеграции с Instagram, WhatsApp, Telegram, Viber, Avito, ВКонтакте, Facebook, онлайн-консультант на сайте.

Заказы можно оформлять прямо в чате, не переключаясь между вкладками: выбор товара, расчет доставки, отправка ссылки на оплату, печать документов. Чаты автоматически конвертируются в заказы и переносятся в систему.

Быстрое распределение диалогов между менеджерами, стимулирование к покупкам через виджеты и работу с брошенными корзинами. По кейсам клиентов, до 95% коммуникаций можно вести внутри системы, не выходя в отдельные приложения мессенджеров.

CRM-маркетинг и лояльность

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

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

AI-помощники

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

Автотегирование и оценка звонков — система анализирует диалоги по заданным критериям и автоматически проставляет теги. Это же работает для оценки эффективности работы менеджеров в чатах.

Аналитика

Полная воронка продаж с определением этапов, где «зависают» товары. Оценка эффективности работы менеджеров, unit-экономика, структура доходов и расходов, анализ маркетинговых коммуникаций и бюджета.

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

Для кого подходит

RetailCRM специализируется на ecommerce. Если вы продаете через интернет-магазин, маркетплейсы и соцсети одновременно — система решает задачу централизации всех заказов и коммуникаций.

Ограничения: система заточена под ecommerce и розничные продажи. Для B2B-услуг без товарных позиций или сложных производственных процессов она избыточна. Профессиональный тариф стартует с 3 пользователей — для совсем малого бизнеса (1-2 человека) это может быть дорого. Модуль чатов оплачивается отдельными лицензиями поверх основного тарифа.

Какую систему выбрать?

Выбор CRM зависит от того, как устроены процессы в вашей компании. Если продажи тесно связаны с задачами и проектами — YouGile CRM и Аспро.Cloud решают эту задачу через единое пространство для команды.

YouGile подходит небольшим командам до 10 человек, которым нужна бесплатная связка CRM + таск-трекер + мессенджер без дополнительных инструментов. Внедрение занимает 15 минут, система автоматически выводит дела на день, чтобы менеджеры не теряли клиентов.

Аспро.Cloud закрывает более широкий набор задач: кроме продаж есть финансы, склад, документооборот и проекты в одной платформе. Подходит среднему бизнесу с B2B-продажами, где нужна связка между отделами — счета автоматически формируются из CRM, задачи синхронизируются с проектами, финансы учитываются в моменте. Гибкая кастомизация под отрасли.

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

С чего все началось

Когда Кеннет Вэр четыре года назад взялся за руководство гренландским разделом Википедии, он практически всё удалил. У этого 26‑летнего немца, который после подростковой поездки в автономную территорию Дании стал изучать гренландский язык и переехал в Копенгаген, за плечами были годы работы над англоязычными статьями о Гренландии.

В начале 2000‑х появилась версия Википедии на гренландском; к моменту прихода Вэра в ней было около 1500 статей. На вид — успех краудсорсинга: десятки тысяч статей, сотни авторов. Однако он обнаружил, что почти никто из них не говорил по‑гренландски, и большинство страниц были забиты машинными переводами.

Выглядело это как гренландский, но авторы не могли этого проверить. Предложения не имели смысла или содержали очевидные ошибки. ИИ‑переводчики очень плохо работают с гренландским

Оказалось, что гренландская Википедия — мираж

Эта проблема не уникальная. Википедия — второй по масштабу многоязычный проект после Библии: существуют версии более чем на 340 языках, и ещё около 400 тестируются. Многие из небольших разделов оказались наводнены автоматическим переводом, поскольку ИИ становится доступнее.

Волонтёры, работающие с четырьмя африканскими языками, рассказали MIT Technology Review, что 40–60 % их статей — неотредактированные машинные переводы. Аудит разделов показал: более двух третей страниц со сколько‑нибудь длинными текстами содержат автоматически переведённые фрагменты.

Это порождает сложную проблему. Системы от Google Translate до ChatGPT учатся, анализируя огромные массивы текстов из интернета. Для языков с мало письменных ресурсов Википедия часто — главный источник данных. Ошибки на этих страницах отравляют общий колодец, из которого черпают модели, что делает переводы ещё хуже и запускает рекурсивную спираль: чем больше некорректных статей, тем больше ошибочных данных получают ИИ, и тем хуже становятся новые переводы.

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

Данных о масштабе бедствия нет: многие наборы для обучения ИИ закрыты, а сама индустрия быстро меняется. В 2020‑м Википедия составляла более половины корпусов для перевода некоторых африканских языков, включая малагасийский, йоруба и шона. В 2022‑м исследователи из Германии выяснили, что для 27 малообеспеченных языков Википедия — практически единственный доступный источник текстов.

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

Автоматизация: от ботов до ИИ

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

Но ИИ даёт любому возможность сделать плохую статью за пару кликов. Википедия пока справляется лучше соцсетей: она не наводнена дезинформацией, остаётся открытой и бесплатной, управляется самим сообществом. Однако маленькие разделы зависят от числа активных участников. Англоязычная версия процветает, гренландская — борется за жизнь.

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

Тростеруд вводит термин «угонщики Википедии» для описания пользователей, массово создающих плохие страницы. Это и подростки, пишущие про свой посёлок или любимого блогера, и энтузиасты, уверенные, что добавлением статей они помогают сообществам. Теперь у них есть Google Translate и ChatGPT, поэтому они могут штамповать длинные тексты, которые на первый взгляд выглядят правдоподобно. Раньше их ограничивали бумажные словари, теперь только время.

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

Google подтверждает: для малообеспеченных языков качество перевода ниже. В исследованиях перед расширением Google Translate три года назад отмечено, что системы путают даже простые существительные (например, названия животных и цветов) и часто дают неправильные варианты. Компания заявляет, что «стремится обеспечивать высокое качество для всех 249 языков», особенно тщательно тестируя языки с ограниченным количеством данных.

У Википедии есть инструмент Content Translate: он автоматически переводит статьи между языками, сохраняя ссылки и форматирование. Но он использует внешние переводчики и наследует их проблемы. Каждое сообщество решает, разрешать ли его; английская Википедия практически запретила его использование, поскольку 95 % статей, созданных через Content Translate, требовали значительной доработки. В любом случае можно видеть, что инструмент использован: он оставляет специальную отметку.

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

Юэт Ман Ли, канадский преподаватель обществоведения, рассказывал, что переводил свои англоязычные статьи на инуктитут через Google Translate и ChatGPT, думая помочь. Он отметил, что добавил примечание о черновом переводе и надеялся, что «кто-нибудь увидит и исправит», размышляя, насколько грамотно машина перевела текст. «Я не думал, что кто-то это прочтёт», — признаётся он. Но с момента публикации его статью никто не тронул.

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

Но Википедия, по его словам, — «опустошённая пустыня». «Я хотел помочь, но теперь думаю, что мог запустить рекурсивный цикл, — говорит он. — Хотелось просто выложить контент из любопытства и для развлечения, не подумав о последствиях».

Истории редакторов: страхи и разочарования

Абдулкадир Абдулкадир, 26‑летний агроном из Нигерии, ежедневно тратит по три часа на правку страниц на языке фуфульде. Он считает раздел жизненно важным: это один из немногих онлайн-ресурсов, который он советует фермерам в деревнях, чтобы узнать о семенах и культурах на родном языке. Но машинные переводы могут навредить. «Если вы дадите им неправильно переведённую статью, это может легко навредить», — говорит он. Он приводит примеры: Google Translate считает, что слово «январь» на фуфульде означает июнь, а ChatGPT переводит его как август или сентябрь. Те же сервисы предлагают, что слово «урожай» означает «лихорадка» или «самочувствие». Недавно Абдулкадир исправлял статью о коровьем горохе — важной культуре для региона, — которая была практически непонятна.

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

На другом конце Нигерии Люси Ивуала редактирует раздел на игбо, языке миллионов людей. «Вред уже нанесён», — говорит она, открывая две последние статьи: обе созданны через Content Translate, и в них столько ошибок, что, по её словам, «даже голова заболит». Некоторые слова вообще не переведены и остаются на английском; встречаются буквы, которых в игбо нет. Она узнала автора по нику: это человек, который регулярно публикует плохие переводы. Ивуала начала редактировать три года назад из опасения, что английский вытесняет её язык. Она часто объясняет на онлайн‑марафонах и в письмах, что плохой перевод отпугивает: «Человек разочаруется и уйдёт обратно в английскую “Википедию”». Для неё, профессионального переводчика между английским и игбо, это вопрос культурной идентичности: «Это моя культура, это я. Суть — не дать нас стереть».

Опасения разделяет Ноа Ха‘алилио Соломон, доцент гавайского языка из Университета Гавайев. Он оценивает, что на некоторых страницах до 35 % слов непонятны. «Если такая “гавайская речь” останется в интернете, это принесёт больше вреда, чем пользы», — говорит он. Гавайский язык долго был на грани исчезновения и только недавно начал возрождаться. Видеть плохой гавайский в крупном онлайн‑ресурсе для него болезненно, напоминает о присвоении их культуры. Лингвист Ричард Комптон из Университета Квебека говорит, что такие ошибки становятся основой для книг, продаваемых на Amazon. «Это просто чепуха», — говорит он о книге, которую видел. Он беспокоится, что молодые люди в общинах, которые боролись за сохранение языка, обратятся к ChatGPT или таким книгам и получат ответы только хуже. «Это мошенничество», — считает он.

Ответственность и закрытие разделов

По данным ЮНЕСКО, один язык исчезает каждые две недели. Но обязан ли Фонд Викимедиа отвечать за качество контента на всех языках? По словам Руна Бхаттачарьи, старшего директора фонда, ответственность лежит на сообществах: «Они должны следить, чтобы не было вандализма и нежелательной активности, будь то машинный перевод или что-то другое». Обычно разделы закрывают только при официальной жалобе. Но если нет активного сообщества, кто пожалуется и исправит?

Фонд считает, что его роль — поддерживать платформу, чтобы была возможность её возродить, если появятся желающие. «Мы предоставляем пространство для роста и развития. Этим всё и ограничивается», — говорит Бхаттачарьи. Если сообщество отсутствует, раздел может быть переведён в Инкубатор — площадку для тестирования новых языков.

На этом фоне история инари‑саамского языка в Финляндии — пример успеха. Четыре десятилетия назад носителями были четыре ребёнка. Родители создали Ассоциацию языка инари‑саами, и теперь носителей — несколько сотен; есть школы и 6400 статей в «Википедии», проверенных носителями. «Нас не волнует количество. Нам важно качество», — говорит Фабрицио Бреджароли из Ассоциации. Для них «Википедия» — репозиторий письменного языка и инструмент для молодых. Учителя просят писать статьи на разные темы — от торнадо до фольклора. Через раздел они даже вводят неологизмы: молодёжь ищет слова по спорту, политике, видеоиграм.

Этот пример показывает, что «Википедия» может помочь малым языкам, если за неё взяться всерьёз. «Главная цель — выживание инари‑саамского», — говорит Бреджароли. Он добавляет, что, возможно, даже хорошо, что нет Google Translate для их языка. Но крупные модели вроде ChatGPT уже могут переводить на языки, которых нет в традиционных системах. Бреджароли отмечает, что ChatGPT выдаёт на инари‑саамском смешанные ответы: если спросить по‑фински или английски и попросить ответить на саамском, результат лучше, но если задавать вопрос на инари‑саамском, модель смешивает финский и придумывает слова. «ChatGPT нужен просто большой объём данных. Если мы будем наполнять “Википедию” хорошими материалами, рано или поздно получим что-то полезное», — говорит он. Многие лингвисты надеются, что это поможет разорвать цикл «мусор на входе — мусор на выходе». OpenAI, которая управляет ChatGPT, не ответила на запрос MIT Technology Review о комментарии.

Закрытие гренландского раздела

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

«В Гренландии никому не интересно, никто не хочет участвовать. Это бессмысленно, поэтому раздел надо закрыть», — говорит он.

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

Сам Вэр теперь не надеется: ошибки на гренландском уже вошли в машинные переводчики. Если попросить Google Translate или ChatGPT посчитать до десяти, ни одна программа не справится. Он опасается, что этими ошибками уже заражены будущие модели.

Проблемы зафиксированы у Perplexity, Fortnite, Steam, Snapchat, Asana, Roblox, Duolingo, Coinbase, Canva, Venmo, McDonald’s, Apple TV и множества других платформ, завязанных на инфраструктуру AWS.

Согласно данным Downdetector, пик жалоб пришелся на 11:00 МСК, когда было зафиксировано более 5700 обращений, хотя реальное число пострадавших, вероятно, значительно выше.

Половина интернета — в офлайне

AWS — это не просто сервис Amazon, а фундаментальная часть интернета. Она обеспечивает работу миллионов веб-приложений, API и баз данных.

Именно поэтому даже частичный сбой в дата-центрах Amazon мгновенно отражается на десятках отраслей — от финтеха до гейминга.

Показательно, что даже панель статуса AWS Health Dashboard в момент инцидента оказалась недоступна, выдавая ошибку «This site can’t be reached».

Что известно о причинах

Официальных комментариев от Amazon на момент публикации нет, но все признаки указывают на проблемы в восточном регионе Вирджинии (us-east-1) — ключевом узле AWS, через который проходит значительная часть мирового трафика.

Компания Perplexity AI одной из первых подтвердила зависимость инцидента от инфраструктуры AWS.

Perplexity сейчас не работает. Причина — сбой на стороне AWS. Мы уже занимаемся восстановлением.

С аналогичным сообщением выступили представители Asana, которые сообщили о «полной недоступности всех сервисов» и ожидании обновления от Amazon.

Реакция пользователей

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

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

Что дальше

AWS пока не раскрывает детали, но инженеры компании, по данным внутренних каналов, уже работают над «локализацией и перезапуском кластеров в Вирджинии».

Сбои AWS происходят редко, но их эффект показывает, насколько уязвим современный интернет: когда падает Amazon — падает и все остальное.

По данным, поданным в Комиссию по ценным бумагам и биржам США (SEC), злоумышленникам удалось похитить исходный код флагманской платформы BIG-IP и документы с описанием нераскрытых уязвимостей.

Атака была обнаружена 9 августа 2025 года, однако властям США позволили компании временно не разглашать детали, чтобы не помешать расследованию.

Что известно о взломе

По данным F5, киберпреступники, предположительно связанные с «государственными структурами», длительное время сохраняли доступ к сегменту сети, связанному с разработкой и распространением обновлений BIG-IP.

Эти устройства используются 48 из 50 крупнейших корпораций мира для управления интернет-трафиком и защиты приложений.

Известно, что хакеры похитили часть файлов, включая:

• исходные коды отдельных модулей BIG-IP;
• данные о частных, еще не исправленных уязвимостях;
• конфигурации и сведения о внедрении решений у «небольшого процента клиентов».

F5 утверждает, что нет доказательств вмешательства в цепочку поставок ПО — исходники и сборочные конвейеры остались нетронутыми, а продукты NGINX, Silverline и F5 Distributed Cloud не пострадали.

Реакция компании

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

Обновления уже доступны для BIG-IP, F5OS, BIG-IP Next для Kubernetes, BIG-IQ и APM-клиентов.

Компания также опубликовала руководство по защите инфраструктуры, включая рекомендации:

• включить потоковую передачу событий BIG-IP в SIEM;
• настроить удаленные syslog-сервера;
• отслеживать неудачные входы и изменения привилегий.

Что говорят эксперты

Инцидент стал ударом по репутации F5, поставщика решений для защиты корпоративных сетей.

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

Несмотря на заявления компании, локальные аккаунты все еще можно создавать, причем без сторонних утилит. Метод работает даже в свежих версиях — 24H2 и 25H2.

Раньше в Windows 10 можно было спокойно установить систему офлайн и задать любое имя пользователя. В Windows 11 Microsoft связала установку с обязательным интернетом и авторизацией через Microsoft Account.

Но если вам нужно установить систему без «облака» и рекламы — это все еще возможно.

Способ №1 — без программ

Главное правило — не подключайте интернет.

1. При установке Windows 11 не выбирайте Wi-Fi и отключите сетевой кабель.
2. Когда появится экран подключения, нажмите Shift + F10 — откроется командная строка.
3. Введите команду oobe\bypassnro  и нажмите Enter.
4. После перезапуска установка предложит создать локального пользователя и пропустит авторизацию в Microsoft.

Так вы не только получите офлайн-аккаунт, но и избавитесь от рекламы и предустановленных «советов» Windows при первом запуске.

Совет: после установки откройте Параметры → Система → Уведомления → Дополнительные параметры и снимите все галочки, чтобы не получать полноэкранные баннеры от Microsoft.

Способ №2 — через Rufus

Если вы устанавливаете систему с нуля, можно использовать бесплатную утилиту Rufus.

1. Скачайте ISO-образ Windows 11 с официального сайта.
2. Откройте Rufus и создайте загрузочную флешку.
3. В появившемся окне отметьте опции: «Remove requirement for an online Microsoft account» и «Create a local account with username» (и введите имя профиля).

После этого Rufus автоматически уберет проверку на интернет и создаст офлайн-пользователя при установке.

Зачем это нужно

Установка Windows 11 без интернета позволяет избежать рекламы, телеметрии и автоматических драйверов, а также самостоятельно управлять обновлениями.

И хотя Microsoft все активнее блокирует обходы, пока пользователи все еще могут вернуть себе немного старого доброго Windows-опыта — без облака и лишней слежки.

В свое свежем опубликованном обращении он написал, что человечество «теряет свободу, ради которой отцы-основатели создали Интернет».

«Наше поколение быстро теряет время, чтобы спасти свободный Интернет, построенный для нас нашими отцами», — написал Дуров.

По его словам, из инструмента свободного обмена идеями Всемирная сеть превратилась в «механизм тотального контроля».

Цифровые паспорта и уголовные дела за посты

Дуров резко раскритиковал политику западных стран, обвинив их в стремлении построить «цифровую антиутопию». В качестве примеров он привел:

• внедрение цифровых ID в Великобритании;
• обязательную проверку возраста в интернете в Австралии;
• инициативу ЕС по сканированию личных сообщений;
• уголовные дела во Франции против технологических предпринимателей, выступающих за свободу слова;
• и аресты пользователей в Великобритании «за публикации в соцсетях».

«То, что когда-то было свободой слова, теперь стало поводом для тюремного срока», — написал он, добавив, что Германия «преследует тех, кто критикует власть в интернете».

Личный манифест

В тексте Дуров назвал происходящее «предательством заветов предков» и предупредил, что человечество движется к «моральному, интеллектуальному и экономическому саморазрушению».

Он подчеркнул, что его отказ от празднования — не жест отчаяния, а знак протеста:

Я не собираюсь праздновать. Время уходит. Мы все теряем время.

Контекст

Заявление Дурова появилось спустя несколько недель после его визита в Казахстан, где он встречался с президентом Касым-Жомартом Токаевым и объявил об открытии лаборатории искусственного интеллекта Telegram в Астане.

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

В то же время власти ряда стран обвиняют мессенджер в недостаточном контроле над контентом.

Как выбрать веб-студию для разработки сайта?

Хорошая веб-студия — не та, что обещает «сделать красиво», а та, что умеет решать бизнес-задачи. В 2025 году рынок веб-разработки стал более прозрачным: у топ веб-студий понятные процессы, структурированные предложения и измеримые результаты. Но прежде чем выбрать подрядчика, важно определить собственные цели и критерии.

Определение целей и задач проекта

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

Критерии оценки веб-студий

При выборе веб-студии в 2025 году важно смотреть не только на цену. Обратите внимание на:

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

Портфолио и опыт работы

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

Топ веб-студий 2025 года: обзор и специализация

1. IBRUSH

IBRUSH — это digital-агентство, которое занимается разработкой , веб-сервисов, корпоративных порталов и мобильных приложений, а также обеспечивает их поддержку и развитие. Команда работает над проектами любой сложности. Подход компании строится на сочетании аналитики, продуманного дизайна и современной разработки. Агентство разрабатывает UX/UI и создаёт решения, которые помогают бизнесу повышать ключевые показатели и удерживать клиентов.

Специализация

IBRUSH предлагает услуги в нескольких направлениях: дизайн, аналитика, разработка и поддержка. В дизайн-блок входят разработка дизайн-концепций, интерфейсов, визуальное сопровождение проектов и усиление внутренних команд заказчика. Аналитическое направление включает формирование гипотез, построение CJM, интерактивное прототипирование и подготовку документации. Отдельное внимание уделяется развитию и поддержке: агентство развивает функционал веб-сервисов по спринтам, оптимизирует бизнес-процессы и предоставляет техническое сопровождение.

Преимущества

Главное отличие IBRUSH — внимание к деталям и выстроенные процессы. Студия позиционирует себя как партнёр, который работает вместе с заказчиком над решением задач, а не просто реализует техническое задание. Человечность в общении с клиентами, соблюдение сроков и прозрачность процессов становятся ключевыми принципами работы. Техническая экспертиза агентства охватывает широкий стек технологий, включая Laravel, Symfony, Yii2, Bitrix, WordPress, React, Vue, Angular, Node.js, Flutter, Java, .NET, Python и Go. Ограничений по используемым CMS и фреймворкам компания не ставит, а при необходимости разрабатывает кастомные решения.

К сильным сторонам также относится менеджмент проектов: клиенты получают выделенную IT-команду и персонального менеджера, гибкий выбор формата сотрудничества — фиксированная стоимость, почасовая работа или outstaff. Поддержка организована по SLA с возможностью срочного реагирования в нерабочее время. Прямой контакт с разработчиками, аналитиками и дизайнерами позволяет экономить время и повышает качество решений. Важным преимуществом является также бизнес-аналитика и обучение команд клиента, что делает IBRUSH не только подрядчиком, но и стратегическим партнёром в цифровой трансформации бизнеса.

Кейсы

Один из проектов агентства — редизайн и запуск интернет-магазина продуктов «Нашенька» для фабрики «Северная» в сжатые сроки — 3,5 мес. Клиенту было необходимо создать современный онлайн-магазин в рамках нового бренда и перенести на платформу весь ассортимент. Работа началась с аналитики и CJM: специалисты изучили десять конкурентов по 55 параметрам и провели опросы пользователей. На основе данных была сформирована дорожная карта с приоритизацией задач. В результате за 3,5 месяца команда реализовала масштабный интернет-магазин, который сохранил фирменный стиль клиента и стал удобным инструментом для покупателей. Решение позволило фабрике быстро вывести новый бренд на рынок и расширить присутствие в e-commerce.

2. АБВ-сайт: e-commerce и корпоративная веб-разработка с SLA поддержкой

АБВ-сайт — команда с 15-летним стажем с упором на разработку ультраскоростных интернет-магазинов и корпоративных проектов. Команда берёт на себя полный цикл, но главное: умеет делать редизайн сайтов с сохранением позиций в поисковых системах и даёт гарантии на все работы на 1 год. В работе используются проверенные временем CMS Битрикс и CMF MODx.

Формат работы и специализация

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

Подход к поддержке: SLA и мониторинг

Один из сильных акцентов студии — организация технической поддержки. Она выстроена по SLA (Service Level Agreement), что само по себе нетипично для многих небольших веб-студий.

• Перенос часов: неиспользованные часы поддержки переносятся на следующий месяц, что является крайне редкой практикой на рынке.
• Мониторинг 24/7: все проекты на поддержке находятся под круглосуточным автоматическим наблюдением.
• Скорость реакции: на заявки в тикет-системе реагируют в течение часа.

Такой подход даёт предсказуемость и стабильность работы проектов после их запуска.

Технический стек и интеграции

Студия концентрируется на двух платформах — «Битрикс» и MODx. При этом команда не только использует готовые возможности CMS, но и разрабатывает собственные модули, которые продаются на маркетплейсе «1С-Битрикс» и входят в реестр российского ПО. Это позволяет кастомизировать проекты под сложные бизнес-задачи.

Среди реализованных интеграций:

• Системы учёта (1С, МойСклад).
• CRM (Битрикс24 и другие).
• Платежные системы и сервисы доставки (СДЭК).
• Написание собственных API для нестандартных решений.

Кейс: редизайн и продвижение медицинского портала

Один из показательных проектов в портфолио — работа с сайтом крупной сети коммерческих клиник.

Задача: Провести полный редизайн сайта, интегрировать его с прайс-листами и внешней системой онлайн-записи Gbooking (Med.me). Ключевым требованием было не только сохранить существующие позиции в поисковой выдаче, но и вывести проект в ТОП-3 поиска по Москве в одной из самых конкурентных ниш — медицине.

Решение: Для реализации цели была проведена масштабная работа. Команда проработала 40 страниц направлений и 2500 посадочных страниц услуг. Была создана сложная архитектура: централизованное хранилище для управления ценами, система привязки врачей к услугам без перезагрузки страницы, интеграция с CRM.

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

Результат: За год работы трафик на сайт вырос в 2,2 раза. Видимость в Яндексе увеличилась с 7% до 16%, а в Google — с 10% до 25%.

Этот кейс хорошо показывает экспертизу студии в сложных нишах (медицина, авто, промышленность, e-commerce), где нужна не просто разработка, а комплексный подход к SEO и бизнес-логике.

3. QTIM

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

Специализация

Qtim создает цифровые продукты с нуля, редизайнит существующие решения и развивает платформы для крупных компаний. Основные направления — разработка высоконагруженных веб-проектов, мобильных приложений, корпоративных порталов, SaaS и B2B-сервисов. Команда отвечает полный цикл: от аналитики и проектирования до запуска и поддержки, работая как с кастомными архитектурами, так и с готовыми технологическими стеками.

Преимущества

Главный фокус студии — скорость вывода продукта, масштабируемость и устойчивость к нагрузкам. Qtim специализируется на микросервисной архитектуре, кроссплатформенной разработке (Flutter, React Native) и гибких интеграциях с внешними системами. Подход строится вокруг бизнес-задач заказчика: каждая фича и технологическое решение — часть реального продукта. Отдельное внимание уделяется безопасности, производительности и прозрачности процессов: у клиентов всегда есть доступ к трекерам задач, регулярным отчётам и созвонам с командой.

Кейсы

Qtim разработала Alps — универсальную платформу для путешествий в Альпы, объединившую бронирование жилья, трансфер, аренду снаряжения и рестораны в одном приложении. Система фильтров, push-уведомления, платежи и карта маршрутов позволили превратить процесс планирования отпуска в простой и интуитивный сценарий.

Для сети ресторанов студия создала Bakki — цифровой тренажер для онбординга официантов. Решение сократило сроки обучения и снизило риски ошибок новичков, а рестораны получили прозрачную систему адаптации сотрудников.

В EdTech-сегменте Qtim спроектировала и запустила масштабируемую образовательную платформу «Онлайн-школа №1» с 18 ролями пользователей, дашбордами, календарями, чатом 24/7, микросервисной архитектурой и своей собственной ВКС системой.

4. UxPRO

UxPRO — студия, которая специализируется на проектировании и дизайне интерфейсов для цифровых продуктов, сайтов и приложений. Команда работает с проектами любой сложности и подключается на всех этапах — от аналитики до финальной визуализации. При этом студия не занимается разработкой, фокусируясь исключительно на UX/UI: важны качество, глубина проработки и системность в дизайне.

Специализация

UxPRO выстраивает дизайн цифровых продуктов, уделяя особое внимание удобству интерфейса, логике взаимодействия и визуальной последовательности. Формат сотрудничества — как проект «под ключ» до передачи в разработку, так и дизайн-поддержка действующих решений. Студия проводит UX-исследования, создаёт прототипы и визуальные концепции, прорабатывает пользовательские сценарии в Figma.

Преимущества

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

Кейсы

UxPRO участвовала в проектировании внутреннего HR-сервиса для крупной игровой корпорации, который позволил сократить время найма и сделать процесс прозрачным для сотрудников. Для предпринимателей студия разработала сервис по импорту товаров из Китая, а также интерфейс системы транспортной телематики для таксопарков. Среди других проектов — ERP-платформа для управления рекламными кампаниями и приложение для модульного хранения вещей, ориентированное на конечных пользователей.

Среди значимых коллабораций — работа для Минцифры: студия спроектировала сервис для учеников и педагогов, где в едином интерфейсе доступны данные об успеваемости и задания. В числе недавних проектов — редизайн платформы для управления рекламными кампаниями и рефакторинг внутреннего сервиса для разработчиков видеоигр в международной геймдев-компании.

5. EVEREST

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

Специализация

Основные направления включают исследования и аналитику, UX-проектирование, UI-дизайн, сервисный дизайн, веб-разработку, мобильные решения и брендинг. Everest берёт проекты «под ключ», а также обеспечивает техническую и дизайн-поддержку. Студия работает как с CMS (Bitrix, WordPress), так и с кастомными решениями, используя современные фреймворки и инструменты под задачу проекта, а также применяет low-code и zerocode инструменты — Tilda, Webflow, Readymag.

Преимущества

Ключевой акцент компания делает на CX и UX, ориентируясь на бизнес- и поведенческие метрики. Под каждый проект формируется выделенная команда, погружённая в проект, есть отдельные аналитики, специализирующиеся на исследованиях и пользовательском опыте. В компании присутствует практика, когда project-менеджер становится полноценным участником внутренних процессов клиента, обеспечивая бесшовный процесс передачи информации от клиента команде: участвует в планёрках, связанных с цифровыми сервисами компании, консультирует и берёт на себя часть задач product-owner, становясь его правой рукой.

Компания предлагает гибкий выбор формата сотрудничества: Time & Material, Retainer, Fixed Price. Поддержка проектов осуществляется разными способами, в зависимости от требований клиента — это может быть подписка (пакеты по часам) + чат, система заявок (тикеты) + чат или SLA с гарантированными сроками реакции и решения задач.

Everest делает фокус на разработке цифровых продуктов для B2B. Приоритетные сферы: финтех, недвижимость, сложный e-commerce, медицина, промышленность.

Кейсы

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

Другим примером стала разработка веб-версии личного кабинета и аналитика мобильного приложения Sminex. Everest провёл бизнес-интервью, юзабилити-аудит и спроектировал веб-кабинет на базе мобильного приложения с учётом улучшений и разных ролей пользователей. В мобильной версии переработали ключевые сценарии, включая оформление заявок и работу с разделом «Счета». В итоге веб и мобильное решение стали единым продуктом, обеспечивающим пользователям комфортный переход между платформами, а количество обращений в колл-центр сократилось на 85%.

На что обратить внимание при заказе сайта?

Договор и гарантии

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

Поддержка и развитие проекта

Создание сайтов — это только начало. Веб-проект живёт и развивается: обновления, оптимизация, новые функции. При выборе веб-студии уточните, как устроена поддержка после релиза. У многих студий есть SLA-пакеты: фиксированные часы на обслуживание и развитие проекта.

В 2025 году заказать сайт можно у множества подрядчиков, но реальную ценность дают не самые дешёвые предложения, а понятные процессы, прозрачная коммуникация и профессиональная команда. Лучше потратить время на выбор веб-студии, чем потом переплачивать за исправления.

Цифра в 100 миллиардов долларов вызывает когнитивный диссонанс. Это больше ВВП таких стран, как Хорватия, Беларусь или Уругвай. Сумма, которую человечество тратит на космические программы за десятилетия. Но здесь речь о частной сделке между двумя компаниями. Когда деньги достигают такого масштаба, они перестают быть просто деньгами, а становятся инструментом перераспределения глобальной власти.

Эпохальная сделка: за рамками пресс-релиза

Новость от 22 сентября 2025 года выглядела стандартным корпоративным анонсом, хотя и разлетелась по всем мировым СМИ и tech-изданиям. NVIDIA и OpenAI объявили о стратегическом партнерстве с развёртыванием 10 гигаватт вычислительных систем. Цифры впечатляют, но вся суть кроется в деталях.

По словам Дженсена Хуанга, гендира NVIDIA, 10 гигаватт — это 4-5 миллионов графических процессоров. Столько же NVIDIA произведёт за весь 2025 год. Фактически, OpenAI получает доступ к годовому объёму производства ключевого ресурса для ИИ.

Инвестиция в $100 млрд структурирована прогрессивно — по мере развёртывания каждого гигаватта мощностей. Первый транш в $10 млрд поступит после запуска первого гигаватта во второй половине 2026 года.

Управляющий партнёр Requisite Capital Management Брин Токингтон заявил: «NVIDIA инвестирует $100 млрд в OpenAI, которые OpenAI затем вернёт обратно». Он отметил, что этот проект будет полезен для NVIDIA.

Эксперты отмечают стратегическую глубину сделки. Как пишет сайт CNBC, партнёрство «подчеркивает тесную связь между OpenAI и NVIDIA, двумя главными драйверами последнего бума в области ИИ». Фактически, это создает интегрированную экосистему, где успех одного напрямую подпитывает рост другого.

Вычислительная гонка вооружений: как мощность стала новой нефтью

OpenAI оказалась в парадоксальной ситуации. 700 млн еженедельных пользователей — это не только успех, но и колоссальная нагрузка. Каждый запрос к ChatGPT требует вычислений. Каждое улучшение модели — тысяч GPU.

Сэм Альтман предельно откровенен: «Все начинается с вычислительных мощностей». В интервью CNBC он объясняет — без достаточных ресурсов нам придётся выбирать между исследованиями рака и бесплатным образованием. Никто не хочет такого выбора.

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

Грег Брокман сравнивает текущую ситуацию с первым сервером DGX, который Хуанг лично доставил в офис OpenAI в 2016 году. «Теперь нам нужно в миллиард раз больше вычислительной мощности», — говорит он. Масштаб ошеломляет.

Мы наблюдаем фундаментальный сдвиг. Если раньше алгоритмы были ключевым ограничивающим фактором, теперь это исключительно вычислительные ресурсы. Тот, кто контролирует гигаватты, будет контролировать интеллект следующего поколения.

Монополия на разум: стратегия NVIDIA

NVIDIA — уже не только производитель чипов: компания строит экосистему, в которой её собственные технологии становится стандартом де-факто. Партнёрство с OpenAI — краеугольный камень этой стратегии.

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

Антимонопольные юристы уже выражают обеспокоенность. Андре Барлоу, специалист по конкурентному праву, отмечает: «Сделка может изменить экономические стимулы NVIDIA и OpenAI и создать замкнутую систему, где доминирование на железо подкрепляет лидерство в программном обеспечении».

Особенно тревожным эксперты считают момент заключения сделки. Всего за неделю до объявления с OpenAI NVIDIA:

• приобрела долю в Intel за $5 млрд;
• инвестировала $700 млн в дата-центровый британский стартап Nscale;
• потратила $900 млн на поглощение разработчика ПО для ИИ-кластеров Enfabrica.

Сейчас компания захватывает все уровни инфраструктуры. Аналитики Bloomberg характеризуют сделку как намеренное создание «порочного круга» на $100 млрд. Они указывают, что реальный риск для индустрии заключается не в лопнувшем пузыре, а в консолидации рынка, которая вытесняет конкурентов. NVIDIA создаёт то, что можно назвать «вычислительным картелем». Партнёрство с OpenAI — это сигнал рынку: альтернативы нашим чипам для серьезных AI-проектов просто нет.

Тихая война сверхинтеллекта: глобальный контекст

Партнёрство NVIDIA и OpenAI происходит на фоне глобальной гонки за сверхинтеллектом. Игроки понимают — кто первый создаст AGI*, получит беспрецедентное преимущество.

*AGI, искусственный общий интеллект — на текущий момент гипотетическая форма ИИ с самосознанием и способностями решать сложные интеллектуальные задачи лучше человека.

В июне 2025 года Марк Цукерберг объявил о реорганизации AI-подразделения Meta* с фокусом на сверхинтеллект. Александр Ванг, бывший CEO Scale AI, возглавил новое подразделение Meta* Superintelligence Labs.

*запрещена в РФ

Илья Суцкевер, сооснователь OpenAI, ушел из компании, чтобы создать Safe Superintelligence Inc. (SSI). Его организация сфокусирована исключительно на безопасности сверхинтеллекта — это явный признак того, что эксперты не считают создание AGI сугубо теоретическим вопросом.

Работы Леопольда Ашенбреннера, бывшего исследователя OpenAI, обсуждаются в военно-политических кругах Вашингтона. Его эссе содержит прямой призыв обеспечить тотальное доминирование США в гонке ИИ. Технологии становятся вопросом национальной безопасности.

Китайские компании типа Baidu и Alibaba активно работают над собственными большими моделями, но сталкиваются с ограничениями доступа к передовым чипам — США сознательно создают искусственный барьер.

Аналитики отмечают, что сделка между NVIDIA и OpenAI укрепляет связи в рамках целой сети партнёрств между технологическими гигантами, включая Microsoft, Oracle и SoftBank. Этот формирующийся «блок сотрудничества» оценивается в триллионы долларов, а его интересы, как отмечается в одном из обзоров, «очень сходятся» на фоне поддержки политики администрации США. Таким образом, сделка выходит за рамки корпоративной и приобретает черты национальной технологической стратегии.

Регуляторный парадокс: почему молчат антимонопольные службы

Тревожный аспект сделки — отсутствие серьёзного регуляторного сопротивления. Сравнение с другими громкими случаями показательно:

• Сделка Microsoft и Activision Blizzard годами изучалась регуляторами по всему миру. Споры велись о том, будут ли игры вроде Call of Duty эксклюзивными для Xbox. Речь шла о доступе к развлечениям.
• Apple бесконечно судится с регуляторами ЕС из-за комиссий в App Store и предустановке сторонних магазинов. Битва идёт за проценты с продаж цифровых товаров.

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

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

Европейский союз пытается догнать уходящий поезд. AI Act вступил в силу в 2025 году, но фокусируется в основном на прозрачности и этике, а не на концентрации вычислительной мощи. Регуляторы борются с симптомами, а не с причиной.

Будущее индустрии: новые правила игры

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

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

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

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

Альтернативные пути: есть ли жизнь после NVIDIA

Не все эксперты считают ситуацию безнадежной. Появляются признаки сопротивления доминированию NVIDIA:

• Google продолжает развивать собственные TPU и инвестирует в кремниевые инновации;
• Amazon через AWS продвигает собственные чипы Inferentia и Trainium;
• Microsoft работает над проектом Athena.

Но разрыв огромен. Хуанг в августе 2025 года говорил инвесторам, что строительство одного гигаватта дата-центров стоит $50-60 млрд, из которых $35 млрд — оборудование NVIDIA. Конкуренты не могут просто купить рынок. Китай развивает национальные проекты в обход санкций, но пока выступает в роли догоняющего.

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

Тенденция к специализации аппаратного обеспечения для ИИ — новая реальность рынка. Анализ актуальных решений NVIDIA показывает, что компания давно отошла от универсальных архитектур и развивает целое семейство специализированных GPU, каждое из которых оптимизировано под конкретный тип задач:

• Для инференса (процесса применения уже обученной модели ИИ) и визуализации созданы ускорители NVIDIA L40, которые сочетают высокую производительность в AI с передовыми возможностями для графики.
• Для масштабного инференса в дата-центрах предназначен низкопрофильный и энергоэффективный NVIDIA L4.
• Для рабочих станций создана видеокарта NVIDIA RTX 6000 Ada Generation, архитектура которой обеспечивает почти двукратный прирост производительности в AI-задачах по сравнению с предшественниками.

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

Геополитический контекст: перерисовка карты влияния

Сделка NVIDIA и OpenAI выходит далеко за рамки бизнеса. Технологическое лидерство всё больше определяет геополитическое влияние. Администрация президента Трампа рассматривает ИИ как область стратегического преимущества США.

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

Бывший советник по национальной безопасности США Генри Киссинджер в своей последней книге предупреждал: «ИИ станет новым ядерным оружием — тем, кто первым достигнет сверхинтеллекта, достанется возможность диктовать правила остальному миру».

Официальные военные доктрины ведущих стран уже давно сравнивают киберпространство с театром военных действий. Концентрация ресурсов для создания сверхинтеллекта в рамках частного партнерства стоимостью в сотни миллиардов долларов вызывает опасения у экспертов — нас могут ожидать новые формы геополитических противостояний.

Философ и футуролог Ник Бостром, автор книги «Искусственный интеллект. Этапы. Угрозы. Стратегии», в недавнем интервью выразил обеспокоенность: «Ускорение гонки ИИ без адекватных механизмов контроля напоминает эксперименты с ядерной энергией в 1940-х, но с ещё более непредсказуемыми последствиями».

Сделку комментирует эксперт Максим Горшенин, автор инсайдерского канала про импортозамещение в России Imaxai, соучредитель Ассоциации производителей компьютеров и периферийного оборудования:

«Это стратегическая инициатива, тесно связанная с политикой США. Их цель — создавать американские продукты на американских вычислительных мощностях. Последствия такого подхода заключаются в создании замкнутой экосистемы: OpenAI — крупнейший потребитель вычислительных ресурсов, и партнерство с NVIDIA блокирует возможности проникновения на этот рынок конкурентов. Второй ключевой аспект — сохранение технологического лидерства США. Все действия направлены на удержание позиций, включая лидерство в производстве и разработке чипов для ИИ. Этому способствует указ Трампа, предписывающий американским компаниям инвестировать миллиарды долларов в эту сферу. Что касается долгосрочных глобальных последствий — полный контроль над цивилизацией в ближайшее время вряд ли будет достигнут. Но лет через 30 — вполне возможно. Исторически США всегда делали ставку на технологическое превосходство через сотрудничество с Министерством обороны, что позволяло создавать более совершенное оружие. Сейчас официально заявлено: кто обладает самым передовым ИИ, тот получает преимущество в войне, прогнозировании, предугадывании действий противника, создании умных бомб и других сферах. Это инвестиция в технологическое лидерство США, что создает негативные последствия для остальных стран и запускает гонку искусственного интеллекта — прежде всего между США и Китаем. Остальные страны в этом противостоянии практически не участвуют».

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

Этическая дилемма: кто будет контролировать контролеров

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

OpenAI позиционирует себя как компанию, миссия которой — безопасный ИИ на благо человечества. Но структура партнёрства с NVIDIA ставит вопрос о приоритетах.

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

В нём он сказал следующее:

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

Итоги: точка невозврата пройдена

Партнерство NVIDIA и OpenAI — не рядовая сделка. Мы входим в новую эру, в которой вычислительная мощность становится главным ресурсом. Тот, кто контролирует ИИ, получает реальное влияние в мире.

Сам Альтман, президент OpenAI, признаёт:

«Вычислительная инфраструктура станет основой экономики будущего».

За этими словами — новый мир, в котором традиционные ресурсы вроде нефти или газа уступают место гигаваттам и гигафлопам.

Для программистов и IT-специалистов это означает необходимость адаптации к реальности, где доступ к большим AI-моделям дает возможности создания продуктов. Технологическое лидерство всё больше определяется не только кодом, но и вычислительными ресурсами.

Гонка сверхинтеллекта только начинается, но правила уже пишутся. И главное, что демонстрирует партнерство NVIDIA и OpenAI: в игре за будущее разума ставки выше, чем мы привыкли думать, а победитель, возможно, будет только один.