Технологии и разработка — архитектура, код и инженерия

Заменит ли AI программистов в 2026: реальный опыт и ограничения AI в разработке

Thu, 19 Mar 2026 10:01:41 +0300

Непопулярное мнение про AI

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

Во-первых, AI действительно сильно бустанет разработку и около IT. Если раньше условно от программиста требовали писать 1000 строк кода в неделю, то теперь это может быть 10 000. То же самое с другими специализациями. Но это не про замену, это про изменение рынка. Станет больше кода, больше проектов и больше попыток что-то запустить. При этом в какой-то момент начинаешь ловить себя на мысли, что иногда задачу быстрее и дешевле решить руками, чем пытаться объяснить LLM, что ты от нее хочешь — токены и время на диалог спокойно съедают весь эффект.

Во-вторых, запуск новых продуктов действительно упростился. Напилить SaaS для тестирования гипотезы за день или даже за пару часов — уже реальность. Мы сами пробовали, и да, это ощущается как магия. Но дальше начинается обратная сторона: безопасность, архитектура, поддержка. Видел кейс, где на вайбкодинг-продукте с интеграцией со Stripe взломали систему и увели платежные данные. Плюс история с BuzzFeed — ставка на AI и в итоге разговоры о риске банкротства. Это хороший сигнал, что сам по себе AI не делает продукт жизнеспособным.

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

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

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

Ну и важный момент. Разработка — это не только код, это услуга. А в любой услуге есть коммуникация, погружение в бизнес, понимание задач и ограничений. Я слабо представляю, что CTO среднего бизнеса скажет: «пойду навайбкоджу себе CRM и B2B-площадку». Скорее он обратится к тем, кто уже это делал.

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

А как у вас? AI — это уже рабочий инструмент или пока больше про «поиграться и забыть»?

Яндекс Кит для интернет-магазина: что это, как работает и стоит ли запускать сайт

Wed, 04 Feb 2026 10:26:41 +0300

Новое начало маленьких интернет-магазинов?

Кажется, ниша небольших интернет-магазинов на WP и Тильде либо умирает, либо уверенно движется в эту сторону. И нет, это не про вайб-кодинг — он только расправляет крылья, посмотрим, куда его занесёт. Сегодня хочется поговорить про другое. Про Яндекс Кит.

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

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

С этим у Кита как раз всё неплохо. Базовый набор — ровно то, что нужно: обмен с 1С, «МойСклад», Яндекс Маркет, интеграция с Ozon и WB, retailCRM, amoCRM, Bitrix24. Можно подключить свой домен, фирменный стиль по мелочи, всё как положено.
По оплатам — Яндекс Pay и CloudPayments.
По логистике — Яндекс, СДЭК, Ozon Логистика.

В итоге со старта получается очень приятный и взрослый набор, без ощущения «песочницы».

Отдельно стоит сказать про одну из ключевых фишек — бесшовную интеграцию с Yandex ID. Что это даёт на практике? Более высокую конверсию за счёт того, что данные пользователя уже заполнены. А если карта привязана — покупка превращается буквально в пару кликов. Для небольшого интернет-магазина это огромная разница.

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

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

Но реальность сейчас такая: если ты продал на маркетплейсах на 5 млн рублей, 2–2,5 млн из них ты спокойно отдал в виде комиссии, логистики и маркетинговых сборов. И тут возникает вполне логичный вопрос — а неужели на своём интернет-магазине нельзя привлечь клиентов хотя бы на эти же 2 млн? При этом данные пользователей остаются у тебя, их можно догревать, возвращать, продавать повторно. А это уже совсем другая экономика.

Так что рынок разработки интернет-магазинов умер? И да, и нет.

Этот вопрос поднимался ещё в тот момент, когда маркетплейсы начали активно захватывать рынок. Зачем свой магазин, если это затраты, куча проблем, ресурсы и неочевидная отдача? Ответ пришёл со временем. Свой интернет-магазин — это бренд и прямой доступ к клиенту. А значит, меньше зависимости от правил площадки и чуть более спокойный сон.

В итоге что получается. Рынок разработки интернет-магазинов не умрёт. Яндекс Кит просто займёт свою нишу, отжав у Тильды, WP и части типовых решений на Битриксе проекты небольших e-commerce. Если нужно что-то сложное, нетривиальное или B2B — вариантов по-прежнему немного, и кастом никуда не денется.

Со своей стороны мы планируем активно пробовать Яндекс Кит как ещё один инструмент быстрого запуска для небольших e-commerce-проектов, где городить что-то большое и сложное просто нецелесообразно.

Инструменты меняются. Смысл — нет.

Синхронное, асинхронное, конкурентное и параллельное выполнение — в чём разница простыми словами

Wed, 28 Jan 2026 12:26:45 +0300

В чём разница и почему это важно

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

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

Как ускорить выполнение

Если хочется, чтобы программа или сайт работали быстрее, вариантов на самом деле не так много.

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

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

Асинхронность и ожидание

Рассмотрим простой бытовой пример — стирку.

Сортировка вещей перед стиркой занимает 15 минут.
Сама стирка длится 40 минут.
Развесить и разложить чистое — ещё около 10 минут.

Если делать всё строго последовательно, процесс выглядит так: сначала сортируем вещи, затем запускаем стирку и просто ждём, после чего разбираем чистое. В сумме получается 65 минут.

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

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

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

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

Последовательное, конкурентное и параллельное выполнение

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

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

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

Задачи не выполняются одновременно, но они чередуются. Их выполнение перекрывается по времени, и система остаётся отзывчивой.

Такое выполнение обеспечивается конкурентными потоками. В повседневной речи термины «конкурентное» и «чередующееся» часто используют как синонимы.

Исходящие запросы: синхронно и асинхронно

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

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

Пока данные не получены, выполнение просто «стоит». Процессор при этом простаивает.

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

Входящие запросы: синхронно и асинхронно

Теперь посмотрим на ситуацию со стороны сервера.

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

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

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

Ключевое наблюдение в том, что сервер чаще всего не упирается в процессор. Он ждёт данные — от базы данных или других сервисов — и в это время ничего полезного не делает.

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

Почему классический репрайсер для Ozon и Wildberries уже не работает — и что мы строим вместо него

Wed, 19 Nov 2025 14:39:32 +0300

SaaS был ошибкой? Возможно. Часть 4

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

Месяц кастдевов

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

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

А вот в enterprise-историях проблема подтверждается. Каждый решает её по-своему, костылями и полуавтоматом. У селлеров с небольшим ассортиментом всё проще — там хватает существующих сервисов. Я насчитал больше двадцати живых решений, и у каждого свои особенности: ограничение на количество товаров, странные тарифы и отсутствие нормальных интеграций. Всё руками, о связке с 1С или динамическими ценами часто даже не мечтают.

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

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

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

Что сделали по разработке

Перезапустили сайт решения. Хотелось собрать всё на Тильде, но пошли другим путём — сделали максимально примитивно, чтобы проверить конверсию самого подхода. Личного кабинета пока нет, но рассчитываем довести его до ума за ближайшие одну–три недели.

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

Личный кабинет стал чуть красивее обычного орчида, но ещё не тот результат, от которого отваливается челюсть, но в целом окей. Зато сделали авторизацию через email и OTP — СМС подключим позже.

Интересные находоки

Нашли хак на Ozon. Если товар стоит в акции, менять цену нельзя — она пишется, но берётся медианная. Однако если сначала вынуть товар из акции, обновить цену и вернуть обратно — всё работает. Абсолютно легально, пока.

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

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

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

Что дальше

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

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

В разговоры с экспертами добавился новый блок — прикидка трендов. Что будет дальше?

API может стать платным. Больно, но не смертельно. Цена персонализируется до безумия — непонятно, что будет с РРЦ и МРЦ. Запрет на изменение цен по API? Сомнительно, но и на это у нас есть запасной вариант.

Далее по плану.

Запускаем SaaS.
Доделываем стратегии.
Включаем рекламу и аутрич.
А дальше — посмотрим, что покажут цифры и люди.

Модуль миграции товаров в интернет-магазин на Битрикс | Быстрый перенос с маркетплейсов

Fri, 03 Oct 2025 09:26:13 +0300

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

Маркетплейсы продолжают закручивать гайки. К комиссиям добавляется и НДС. В итоге продавцам становится всё сложнее удерживать маржинальность. У Amazon, например, комиссии на некоторых категориях доходят до 50% — и это уже не страшилка, а реальность.

Многие селлеры просто не вывозят в таких условиях и начинают искать альтернативы.

Что предлагает рынок

Рынок реагирует по-своему. Яндекс недавно запустил KIT — по сути, конструктор интернет-магазина, заточенный под fashion-сегмент. Для небольших продавцов логично и дальше использовать тильду или аналогичные платформы. Запустить витрину на 50–100 товаров так можно быстро и недорого.

Где возникает разрыв

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

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

В России из серьёзных платформ по сути остаётся Bitrix и пара его аналогов.

Наш кейс и решение

Мы пошли по пути минимального входа: Bitrix + готовое решение + наш модуль миграции. Такой старт-пакет позволяет быстро запуститься и сразу получить рабочий интернет-магазин.

Модуль решает самую больную часть — миграцию контента. Он умеет подтянуть каталог с нужной площадки (Ozon, Wildberries, Яндекс.Маркет, Lamoda) и автоматически разложить товары в Bitrix. Получаем готовую базу, с которой можно работать.

Дальше уже можно подключить 1С, настроить синхронизацию и развивать проект. Главное — продавец экономит недели рутинного копипаста и может сразу проверить спрос на своей площадке.

Что дальше

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

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

Уязвимости Битрикс и Laravel — реальные кейсы и простые меры защиты

Tue, 16 Sep 2025 18:28:40 +0300

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

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

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

Что реально ломают

Чаще всего достаётся CMS: в Битриксе это модули и готовые решения, которые не обновляются вовремя; в WordPress ситуация ещё хуже. Laravel-проекты тоже не застрахованы: последние пару лет участились случаи заражения через сторонние пакеты, особенно бесплатные.

Что работает против уязвимостей

Регулярные обновления ядра и модулей, плюс актуальная версия PHP (сейчас минимум 8.2).\
Использование штатных инструментов: проактивный фильтр, защита админки по IP, одноразовый вход, настройка безопасных паролей.
Ограничение доступа к серверу: FTP, SSH, база — только по IP.
Периодическое сканирование на уязвимости: встроенный модуль безопасности в Битрикс + AI-Bolit.
Мониторинг серверов и кода: чем раньше обнаружен вирус, тем проще вычистить.

Бэкапы — наше всё

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

ТруСтори

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

Где перегибают

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

40 рекомендаций для условно безопасной веб-системы

Обновите ядро и все модули/пакеты до последних версий.
Используйте актуальную версию PHP (8.2+).
Удалите неиспользуемые модули и пакеты.
Проверяйте зависимости на уязвимости (composer audit, встроенные сканеры).
Включите WAF/проактивный фильтр.
Ограничьте доступ к админке и API по IP.
Включите двухфакторную авторизацию для админов.
Используйте только сложные пароли, настройте их регулярную смену.
Запретите доступ к FTP/SSH/БД извне, кроме доверенных IP.
Закройте публичный доступ к .env, конфигам, логам.
Отключите показ ошибок на продакшене.
Настройте права на файлы и каталоги (минимально необходимые).
Используйте HTTPS везде.
Настройте корректные заголовки безопасности (CSP, HSTS, X-Frame-Options).
Защитите формы CSRF-токенами.
Ограничьте CORS только доверенными доменами.
Сканируйте проект встроенными и внешними сканерами (AI-Bolit, OWASP ZAP).
Подключите мониторинг логов авторизаций, ошибок и изменений файлов.
Настройте уведомления о подозрительных активностях.
Проверяйте целостность файлов ядра/фреймворка.
Раз в полгода проводите внешний аудит безопасности.
Храните секреты и ключи только в переменных окружения, не в коде.
Проверьте APP_KEY (Laravel) или аналоги — он должен быть надёжным.
Используйте очереди/джобы для тяжёлых процессов.
Минимизируйте количество администраторов с полными правами.
Разграничьте права доступа для редакторов, маркетологов и разработчиков.
Отключите или ограничьте системные консольные команды на продакшене.
Настройте регулярные бэкапы БД и файлов.
Храните бэкапы на отдельном сервере/в облаке.
Проверяйте возможность восстановления из бэкапов.
Храните несколько версий бэкапов за последние 1–2 месяца.
Используйте Fail2Ban или аналог для защиты от брутфорса.
Настройте Firewall (сетевой и на уровне веб-сервера).
Ограничьте доступ к /storage, /bootstrap, /bitrix/admin и другим критичным директориям.
Удалите или закройте от доступа тестовые и dev-сервера.
Включите автоматическое обновление ОС и критичных пакетов.
Используйте CDN/DDoS-защиту (Cloudflare, DDoS-Guard).
Подключите систему централизованного логирования (ELK, Sentry, Zabbix).
Регулярно проверяйте базу CVE на уязвимости используемых решений.
Делайте пентест/нагрузочное тестирование хотя бы раз в год.

Вывод

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

Поэтому если у вас до сих пор живёт старый «БУС», проекты на ранних версиях Laravel или давно не обновлявшийся Битрикс24 — сейчас тот самый момент, когда стоит обновить. Если вы ждали сигнала, то вот он.

Кастомизация Битрикс24: мифы и реальные способы доработки коробки

Fri, 12 Sep 2025 09:06:02 +0300

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

Откуда растут мифы

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

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

Простые варианты

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

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

Когда нужно больше

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

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

Подход «в лоб»

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

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

Подход «изящный»

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

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

Другие возможности

Есть ещё виджеты — например, в контакт-центре можно добавить свой блок. Можно работать через Bitrix24 UI Kit, использовать ui.buttons или даже встроить iFrame. В целом никто не мешает построить свой фронт на Vue или React, но это уже отдельная большая тема.

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

Итоги

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

Self-hosted Sentry: опыт внедрения и настройка мониторинга ошибок

Tue, 09 Sep 2025 15:53:45 +0300

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

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

Попытки найти замену

После первых тестов был долгий период экспериментов с аналогами. Самый заметный из них — GlitchTip. В облаке он казался нормальным вариантом, но в self-hosted быстро вскрылись ограничения. Базовые и интуитивные графики, которые есть в Sentry, там просто отсутствовали. Мы страдали с ним месяцев шесть-восемь, но в итоге признали: полноценной заменой это не станет.

Почему не сразу self-hosted Sentry

Казалось бы, ответ на поверхности — подними свой сервер с Sentry и работай. Но тут встаёт проблема ресурсов. Система прожорливая, особенно если у вас десяток проектов, которые могут генерировать по 100 тысяч алертов в день. Сервер ложится, команда нервничает.

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

Основные блоки Sentry

Проекты
В Sentry всё начинается с проекта. Для каждого приложения или модуля можно завести отдельный проект: фронт, бэк, мобильное приложение. Это удобно, если у компании несколько сервисов или большой монолит, разбитый на части.

События (Events)
Каждая ошибка или перформанс-проблема фиксируется как событие. В нём хранится полный набор данных: стек вызовов, заголовки, браузер, IP, параметры пользователя.

Алерты (Alerts)
Система умеет настраивать алерты: уведомления в почту, Slack, Telegram или другие интеграции. Это позволяет реагировать на проблемы сразу, а не ждать звонка от клиента.

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

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

Интеграции Sentry

Sentry поддерживает большинство популярных фреймворков и CMS:

Backend: Laravel, Symfony, Django, Flask, Spring, .NET, Node.js, Ruby on Rails, Go.
Frontend: Vue.js, React, Angular, Svelte, jQuery.
CMS: Bitrix, WordPress, Drupal, Joomla.
Мобильные приложения: iOS (Swift, Objective-C), Android (Kotlin, Java), React Native, Flutter.
DevOps и инфраструктура: интеграции с Docker, Kubernetes, GitHub, GitLab, Jira, Slack, Telegram.

Чем удобен self-hosted формат

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

Как мы интегрируем сейчас

На проектах процесс отлажен:
— Laravel и Vue — берёшь мануал и подключаешь туда, где нужен мониторинг.
— Bitrix — ещё проще: ставишь модуль, закидываешь ключи, и все алерты автоматически уходят в Sentry.

В итоге по каждой ошибке у нас полный набор данных: браузер, хосты, заголовки, stack trace, куки. Можно спокойно разбираться, а не притворяться Шерлоком Холмсом.

Чем это обернулось

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

Вывод: self-hosted Sentry — не подарок. Он требует ресурсов, внимания и оптимизации. Но это инструмент, который реально работает. И если выбирать между хаосом и спокойной жизнью команды, выбор очевиден.

История систем релизов: от FTP и SVN до CI/CD, GitOps и Progressive Delivery

Mon, 25 Aug 2025 17:03:01 +0300

Одна большая боль нашего милого IT-рынка — релизы. Выкатываем новые фичи, а где-то в другом месте что-то отваливается.

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

1990-е – начало 2000-х. FTP и SSH

На заре всё было просто: есть сервер, есть доступ по FTP или SSH, и есть код, который надо «просто закинуть». Мы так делали. И вы так делали. Ошибки? Они уже на продакшене.

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

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

2000-е. CVS, SVN и «релизы по кнопке»

Когда команды подросли, стало понятно: хаос с FTP убивает проект. Пришли системы контроля версий. Сначала CVS, потом Subversion (SVN).

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

Проблемы? Конфликты кода при слиянии веток, разъехавшиеся окружения «у меня работает — на сервере нет» и ночные выкладки с кофе и пиццей.

2005–2010. Git и первые шаги CI/CD

Git родился в 2005 году, но в массовое использование в компаниях пришёл только к началу 2010-х, когда GitHub и GitLab сделали его доступным. Вместе с ним пришла мода на CI/CD — автоматическую сборку и деплой после коммита.

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

2010-е. Blue-green deployment

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

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

Середина 2010-х. Канареечные релизы и feature flags

Канареечный релиз — когда новая фича выкатывается сначала на 1–5% пользователей. Если всё ок — увеличиваем процент, пока не получат все. Если нет — тихо откатываем, и никто, кроме «канареек», не заметил.

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

Сейчас. Progressive delivery, GitOps и «релизы без страха»

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

Progressive delivery — логичное развитие канарейки. Здесь идея в том, что релиз — это не момент, а процесс. Выкатываем обновление сначала на минимальную аудиторию, мониторим метрики (ошибки, время отклика, конверсии), и только после зелёных сигналов расширяем охват. Иногда это делается волнами: сначала внутренняя команда, потом 1%, потом 10%, 50% и только после этого 100%. Такой подход особенно ценен для продуктов с большой базой пользователей, где ошибка на продакшене стоит дорого — как в деньгах, так и в репутации.

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

GitOps закрыл старую проблему «инфраструктура живёт отдельно от кода». Теперь и код, и конфигурация серверов, и пайплайны сборки лежат в одном репозитории. Любое изменение — через pull-реквест, с автоматической проверкой и прозрачной историей. Это упростило повторяемость окружений и сделало релизы более предсказуемыми. А в связке с Kubernetes, Terraform и ArgoCD всё стало максимально автоматизировано: пушишь изменения в репозиторий, и система сама раскатывает их на нужные окружения.

Релизы без страха — идеал, к которому все идут. Но правда в том, что даже с progressive delivery и GitOps проблемы всё равно бывают. Просто теперь они реже, их проще локализовать и быстрее откатывать. И да, ночных выкладок «все в офисе, пока не починим» стало заметно меньше. А значит, можно не только быстрее выкатывать продукт, но и жить в чуть более человеческом ритме.

Итог

Любой из этих методов может работать. Где-то старые схемы дешевле и проще, где-то без канареек и blue-green нельзя.

Мы для своих проектов остановились на Git с CI/CD — это наш компромисс между скоростью, безопасностью и экономикой. Он не решает все проблемы, но заметно снижает их количество и позволяет спать ночью, а не ждать три часа у консоли, пока выкатывается новая версия.

AI на стероидах: как искусственный интеллект усиливает сильных и вытесняет слабых

Wed, 20 Aug 2025 14:58:27 +0300

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

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

Честно, мне показалось, что он стал работать хуже, чем GPT-4. Да, отдельные тесты показывают квантовый скачок. Но в прикладных задачах всё оказалось не так радужно — приходилось использовать Claude и DeepSeek. Наверное починят, но пока так.

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

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

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

Моё мнение: проблема «вайб-кодинга» (когда весь проект пишет AI) в целом не страшна. Важно, чтобы ты понимал, что происходит в коде, а не просто жамкал ctrl+c/ctrl+v. Если задача решена быстрее, но с сохранением качества и структуры — почему бы и нет?

Поэтому хочу поделиться топ-8 решений с AI, которые реально ускоряют нашу работу.

1. Оценка задач

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

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

2. Аналитика

То же самое, что и со сметами. Обучаем агента на примерах хороших ТЗ и ФТ. Скармливаем ему материалы проекта — тексты, макеты, PNG, все что есть.

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

3. Резюме встреч

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

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

4. UX/UI

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

5. Вайб-кодинг

Как говорится: «меняйся или умри». Если не использовать AI сейчас, легко оказаться за бортом.

У нас проекты большие, с кучей кода и легаси. Кидать куски в GPT можно, но он не видит всей картины. Поэтому искали IDE с возможностью сканировать весь проект. Остановились на Cursor. Пока используем его.

6. Аудиты

AI знает весь ваш проект. Главное — не давать индексировать токены и ключи, иначе привет «восстание машин» и дыры в безопасности.

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

7. HR

Скоринг резюме. На вакансии фронта приходят сотни откликов, и даже тестовые задания не спасают.

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

8. Редактирование текстов

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

Совет максимально простой: пусть все исходящие письма или длинные сообщения проходят через AI. Качество вырастет.

Вместо вывода

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

AI — не замена человеку, а надеюсь станет вторым пилотом. Он ускоряет и усиливает, но не делает работу за тебя.

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

Мне нравится думать, что AI — это допинг для сильных специалистов. Ощущение будто работаешь на стероидах — быстрее, мощнее, продуктивнее. И посмотрим, куда это приведёт дальше.

Ошибки SEO продвижения: куда уходит бюджет и почему сайт не даёт трафика

Wed, 23 Jul 2025 11:57:37 +0300

Дергается глаз от некоторых SEO-задач. Почему? Обсудим

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

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

Изначально этот пост планировался как серия из 4 — 5 постов про SEO, но решил собрать один лонгрид, высказаться так сказать и закрыть тему.

Сегодня рекламных инструментов стало откровенно мало. Google Ads ушёл, таргет умирает, Яндекс Директ на грани pay-to-win. Из реального трафика остались Яндекс, органика Google, да блогеры. . А значит, SEO остаётся едва ли не ключевым каналом, где вы можете привлекать клиентов системно, без ежемесячных вливаний в рекламу. Особенно если ваш сайт — это не просто визитка, а обладает каталогом. В этом случае игнорировать SEO — всё равно что стрелять себе в ногу.

Когда компания запускают проекты за несколько миллионов и не может выделить хотя бы бюджет на «печеньки» для SEO — чтобы сайт хотя бы технически соответствовал реалиям требований поиска в 2025 года — это либо чей то хитрый план или чей то недосмотр. Говорить про зоны ответственности вероятно не стоит, так как с одной стороны это ответственность pm со стороны заказчика — знать что он покупает. С другой стороны, что за подрядчик, если профессионал не сказал об этом клиенту. Иногда компаний / отделов несколько, иногда это разные подразделения. Ну вы поняли.

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

Дёргается глаз, горит пукан

Если вы работаете с SEO-подрядчиками, фрилансером, вы точно сталкивались с задачами типа: «Сделайте вёрстку валидной». Мы, как разработчики, получаем такие задачи регулярно. И каждый раз у меня начинает дергаться глаз и гореть пукан.

Чтобы добиться валидной верстки на старых проектах с историей и своей архитектурой это десятки, а иногда сотни часов работы. А самое забавное — чаще всего такие задачи даже не обсуждаются и не обосновываются, просто «падают» в бэклог. Зачем? Потому что SEO-команда выгрузила 10 000 ошибок по валидатору. Красиво выглядит в отчёте. Звучит страшно. В голове клиента возникает ощущение: «если столько ошибок — точно надо чинить».

Но давайте честно: что именно даст эта правка? Ни один SEO-специалист не скажет, что валидная вёрстка — ключ к ТОПу. Это один из сотен факторов ранжирования, и далеко не самый важный. У него просто минимальный вес при прочих равных. Потратить N часов разработчика на устранение «лишнего div-а» или «не тот порядок meta-тегов», при этом не имея нормальных посадочных страниц и семантики — это прямое вредительство. Особенно в проектах, где нет даже базового SEO-фундамента.

Как появляются такие задачи

Чаще всего они возникают из-за того, что SEO-подрядчику нужно что-то показать клиенту. Работа застопорилась, идей нет, семантика собрана, тексты поменяны, а результатов нет. Тогда в ход идут автоматические сканеры сайта: Labrika, Serpstat, Netpeak, кто что любит. Все они умеют пугать. Особенно блоком «технические ошибки».

Выглядит это как: «На сайте обнаружено 11 304 ошибки в разметке. Срочно устранить!»
В реальности? 500 товаров, по 20 одинаковых ошибок на карточке.
Даже если исправите — ничего не изменится. Но отчёт станет красивее. И можно сказать: «Работаем. Оптимизируем».

Это называется работа ради работы. Показная активность. И она съедает часы, ресурсы и внимание.

Когда SEO нет — и это ещё хуже

Но есть и другой сценарий. И он, честно, пугает больше. Когда SEO нет совсем. Представьте себе: проект на кастомной разработке, работает, живёт, развивается, в него вкладывают ресурсы. Мы видим это постоянно — особенно в fashion-сегменте, в ритейле, в нишевых b2b-порталах. Проекту несколько лет, десятки тысяч SKU, работает команда, маркетинг, CRM, а SEO — просто не занимались.

Проверяешь мета-теги: «Название раздела – Название компании». Всё, и это в лучшем случае. Ни одного коммерческого запроса. Ни слова «купить», ни «в наличии», ни цен. Description — машинный или отсутствует. Хочется спросить: Почему, это же так просто?

Обычно в такой ситуации либо подрядчик за SEO не отвечает, либо SEO «внутри», но никто особо не вникает. Проблема в том, что даже базовые вещи — не сделаны. Хотя внедрить их стоит недорого, а отдача может быть колоссальной. 80/20 работает и здесь, иногда. Даже не нужно пробиваться в топ по суперчастотникам, да и вероятно это сделать будет тяжело. Среднечастотные и низкочастотные запросы — абсолютно рабочая зона.

Где действительно лежит трафик

В e-commerce и B2B трафик идёт из двух зон: разделы каталога и карточки товара. По нашим данным — около 70% органики приходит с категорий/разделов, остальное — с товарных страниц. При этом схема простая: один ключ — одна страница. Хочешь трафик по «синие строительные каски» — сделай страницу именно под этот запрос. Полноценную посадочную с текстом, мета-тегами и заголовками.

Это настолько базовая вещь, что удивительно, сколько проектов её игнорируют. Упрощенная структура унаследованная из 1С, объединённые категории, не оптимизированные шаблоны разделов — и вот вы сами забираете у себя органику.

Как еще достать трафика

Второй слой — это страницы, которые не очевидны, но часто конвертируют: поиск по сайту, фильтры, бренды в связке с категориями. Страницы поиска — золото. Люди вводят туда конкретные потребности: «чёрные ботинки 42 размер». Почему бы не отдать им релевантную страницу и не открыть её для индексации? Технически это просто, а эффект может быть ощутимым.

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

Бренды с категориями — наша любимая история. Люди ищут «Erich Krause карандаши», «Nike футболки», «Bosch перфораторы». Но на сайтах чаще всего есть только страница бренда — и всё. И пользователь тонет в хаосе товаров. Мы же рекомендуем сделать полноценные страницы по связке «бренд + категория». Это потребует генерации, возможно, сложной логики. Но оно того стоит. Даже если из сотни новых страниц в топ выйдут 20 — этого хватит, чтобы трафик начал расти.

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

Вроде есть — но не работает

Еще один кейс — когда SEO «ведут», но задач по технике / доработкам нет. Нет новых страниц, нет изменений в структуре, нет изменений по коду. Заказчику кажется, что всё под контролем — есть подрядчик, приходят отчёты. А если копнуть — там либо закупка поведенческих факторов, либо имитация активности. Да, может быть временный всплеск. Но на длинной дистанции побеждает тот, кто строит структуру, пишет контент и создает страницы под спрос. То есть без технических доработок развивать ресурс по SEO едва ли возможно.

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

В целом, это справедливо и для платного трафика — там же A/B-тесты, гипотезы и постоянные эксперименты, так что изменений, по идее, должно быть ещё больше.

Куда действительно стоит вкладываться

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

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

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

Mon, 14 Jul 2025 12:57:56 +0300

Почему запуск “с чистого листа” — это чаще про миграцию, чем про новизну

Примерно 30–40% наших проектов — это запуск с чистого листа. Иногда так и есть: никакого кода, никаких интерфейсов, просто идея и желание начать. Но на практике чаще всего «чистый лист» оказывается с заметками на полях. Даже если нет легаси-кода и серверов в подвале — почти всегда есть пользователи, бонусы, заказы, каталоги — всё это должно куда-то переехать. И чем раньше мы начнём думать об этом, тем спокойнее будет запуск.

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

Каталог и бонусы: выглядит просто, но с нюансами
С каталогом товаров всё обычно проще. Чаще всего он приходит из внешней системы: 1С, Excel, XML, PIM — не суть. Там всё более-менее понятно. Согласовали структуру — и вперёд. Ошибки начинаются тогда, когда база плохо структурирована, а на старом проекте это держалось на костылях. Выгружаем — и получаем не структуру, а хаос.

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

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

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

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

Мы в своей практике чаще всего идём по пути прямого импорта: сначала переносим пользователей, затем — связанные с ними заказы. Главное — правильно сопоставить ID старых и новых сущностей, иначе вы получите тысячи «висячих» заказов, которые ни к кому не привязаны.

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

Универсальных рецептов нет
Вопреки распространённому мнению, «проект с нуля» почти всегда начинается с миграции. Даже если вы переходите с Битрикса на Битрикс, будет масса нюансов. Если переезжаете с чего-то вроде WooCommerce или Тильды — тем более.

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

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

Как повысить конверсию в eCommerce: сравнение платёжных решений — редирект, SDK и ввод карты на сайте

Fri, 04 Jul 2025 09:41:00 +0300

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

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

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

И я задумался: сам бы я пришёл к себе на консультацию как директор агентства? Наверное, да, но не факт. А если бы я был директором e-commerce проекта? Вероятно, нет.

Поэтому с сегодняшнего утра — курс корректируем. Буду больше писать о том, в чём мы сильны: разработка и развитие B2B / D2C / B2C ecommerce-проектов.

Погнали.

Что не так с оформлением заказа
Как проходит оплата в типичном интернет-магазине на Bitrix или другом типовом движке?
Форма заказа — часто многошаговая. Потом сообщение: «Спасибо, ваш заказ оформлен, сейчас мы переведём вас на оплату». Следом — редирект на платёжный шлюз, где вводим данные карты, иногда повторно. Оплачиваем, нажимаем «вернуться на сайт».
Итого — два редиректа, три интерфейса. И куча поводов для сомнений и отказа от покупки. Особенно если это повторный заказ или импульсная покупка.

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

Какие есть варианты, если хочется так же
Если вы хотите принимать оплату картой прямо на сайте, у вас есть два пути. Первый — обрабатывать данные карты самостоятельно. Это значит, что ваш сервер будет напрямую принимать номер карты (PAN), срок действия, CVV и другие чувствительные данные. Такой подход возможен, но связан с огромными сложностями: вы обязаны пройти полную сертификацию PCI DSS (уровень 1), настроить сквозное шифрование, защиту каналов передачи, использовать сертифицированные HSM-модули и регулярно проходить аудит. Это дорого, долго, и требует штатных специалистов по безопасности. Любая ошибка — и вы нарушаете международные стандарты, рискуя не только деньгами, но и репутацией.

Второй путь — использование SDK/API от платёжной системы. В этом случае пользователь визуально вводит данные карты у вас на сайте, но технически эти данные отправляются напрямую платёжному провайдеру. Ваш сервер не видит и не хранит информацию карты — вы получаете только токен, с которым уже можно списывать средства. Это решение не требует сложной сертификации, укладывается в минимальные требования PCI DSS (SAQ A) и значительно упрощает внедрение. Вы получаете современный UX и безопасность без лишних затрат и рисков.

Мы в проектах чаще используем SDK/API или редирект (классика)— в зависимости от задач клиента, типа заказов и повторных покупок.

Что даёт ввод карты прямо на сайте (SDK или самостоятельный приём)
Плюсы:
– Повторная покупка — одна кнопка
– Меньше отказов — пользователь не покидает сайт

Минусы:
– Ограниченная вариативность — СБП и др. нужно подключать отдельно
– Не все готовы вводить данные на малознакомом сайте

Что выбрать?
Если вы не входите в топ-100 eCom по DataInsight, но хотите увеличить повторные заказы и не терять клиента на каждом шаге — SDK будет отличным решением. Редирект — это рабочий компромисс. Но если вы хотите UX как у маркетплейсов — без SDK никак.

В следующих постах разберём практику:
— Зачем вам PIM-система и как внедрять
— Интегрируем логистику без привязки к внешним сервиса
— Что должно быть в личном кабинете eCom-проекта
— Делаем бонусныу систему и при чем тут фальшивомонетничество

Проблемы при миграции Битрикс24 на Астра Линукс: кейс отказа от Apache и перехода на Nginx + PHP-FPM

Tue, 01 Jul 2025 18:09:11 +0300

Когда «ускорение» оборачивается откатом

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

Мы работаем с крупными инсталляциями Битрикс24: по 2000–3000 активных пользователей в системе, десятки интеграций, сложная автоматизация. В один момент перед нами встал вызов: перейти на импортозамещённое окружение, включая «Астра Линукс» и отказ от привычного Apache в пользу связки Nginx + PHP-FPM.

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

Как это выглядело: миграция «в лоб»

Решение принималось быстро. Никто не давил — просто все были за эффективность. Apache решили не использовать: «устаревший», «тяжёлый», «нам всё равно нужно больше производительности».

Мы развернули новое окружение:

ОС: Astra Linux
Web-сервер: Nginx
PHP: PHP-FPM
СУБД: PostgreSQL

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

Назначили день Х, перенесли файлы и базу, запустились.

И началось: падение стабильности без Apache

Первый звоночек — пользователи не смогли синхронизировать календари с мобильными устройствами.
Потом не проходили заголовки для zip-архивации.
Затем отвалились некоторые интеграции с внешними сервисами, особенно REST-запросы.

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

Мы ушли в дебаг:

Начали с логов
Проверили сокеты
Запустили трассировку пакетов
Сравнили поведение Nginx и Apache на одном и том же коде

Результаты нас неприятно удивили.

Почему Bitrix24 «любит» Apache

Коробочная версия Битрикс24 до сих пор во многих местах завязана на особенности работы Apache:

Использование .htaccess файлов
Обработка нестандартных заголовков
Проксирование для мобильных клиентов
Роутинг внутри REST API

Да, формально Bitrix работает и под Nginx. Да, на сайте есть конфигурации. Но под капотом — множество нюансов, которые не эмулируются простыми правилами nginx.conf.

Когда мы пытались сымитировать Apache-правила в Nginx — устраняя одни баги, ломались другие.
Мобильные приложения отказывались работать. REST-запросы возвращали пустые данные. Архивы не скачивались.
А клиент уже работал на новом сервере. Проект в бою. Откат — сложный. Ресурсы на пределе.

Что мы сделали: откат к проверенному решению

Решение оказалось не героическим, а здравым: поставить Apache.

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

Что из этого вынесли: уроки и рекомендации

Всегда читайте рекомендации вендора

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

Неочевидные функции — ваши лучшие тест-кейсы

Мы добавили в свой чек-лист для QA:

Проверка zip-архивации
Синхронизация календарей
Интеграции с мобильными устройствами

Именно они вскрывают глубинные архитектурные зависимости, которые не заметны при базовой проверке интерфейсов.

Не «ускоряйтесь», пока не знаете цену ускорения

Да, отказ от Apache выглядит как оптимизация. Но если это приводит к нестабильной работе ядра — вы теряете больше, чем выигрываете. Особенно в B2B-проектах, где SLA, штрафы и сложные договорные отношения.

И напоследок: импортозамещение — это не просто про «поставить галочку»

Никакой сарказм. Мы поддерживаем курс на импортонезависимость. Но подход должен быть зрелым:

Тестируйте заранее
Учитывайте legacy-архитектуру
Не бойтесь “старых” решений, если они решают задачу
Apache — не панацея, но и не зло

Если вы переходите на Астра Линукс, внимательно пересмотрите архитектуру вашего веб-стека. Иногда лучше не экспериментировать с критически важными модулями, особенно если вы работаете с Bitrix24.

Обмен 1С с сайтом: как работает, почему падает и как починить

Fri, 27 Jun 2025 17:49:05 +0300

Удивительно, но на некоторых проектах до сих пор всплывают проблемы с обменом между сайтом и 1С которые не могут решить.

Недавно помогали коллегам с подобным кейсом: старый БУС, 1С, обмен заказами долго шёл без проблем — и в один день встал. В логах — вал ошибок, обмен стоит. Разобрались, починили. Заодно решил расчехлить старую инструкцию из Wiki.

Принцип работы штатного обмена

Обмен между 1С и сайтом реализован через протокол CommerceML 2, где основа — XML-файлы. Обмен всегда инициируется со стороны 1С. Сайт играет роль приёмника.

Что можно передавать:

товары и торговые предложения (в 1С — «характеристики»)
остатки
цены
заказы в обе стороны
пользователи
справочники и прочие сущности

Ключевые особенности:

точка входа на сайте —
```
/bitrix/admin/1c_exchange.php
```
взаимодействие идёт через серию GET-запросов
данные записываются во временные таблицы (b_xml, b_xml_tree_import_1c)
при сбое обмен начинается с начала

Важно: одновременные обмены одного типа невозможны, так как данные будут перезаписаны. Это может привести к потере целостности данных.

Версии обмена: как определить

Разные версии модуля обмена (на стороне 1С и на сайте) формируют разные составы файлов:

```
import.xml
```
и
```
offers.xml
```
— минимальный набор
добавление
```
prices.xml
```
и
```
rests.xml
```
— передача цен и остатков отдельно
```
goods.xml
```
+ дополнительные запросы (например, деактивация) — для кастомизированных решений

Подробности: https://www.dev.1c-bitrix.ru/api_help/sale/xml/index.php

Дополнительный модуль обмена от 1С

На сайте 1С доступен бесплатный модуль, который можно установить в конфигурацию:
https://1c.1c-bitrix.ru/ecommerce/download.php

Что он даёт:

дерево выгрузки товаров и категорий
гибкость в отборе данных

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

Режимы выгрузки

В 1С можно выбрать один из двух режимов:

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

Также можно отключить:

выгрузку изображений
определённые свойства или разделы

Заказы выгружаются, если их

дата изменения

больше

даты последней выгрузки

Типовые проблемы и их причины

❌ Включён ZIP-архив — часто вызывает ошибки. Лучше выключить.
❌ Слишком большой размер пакета — рекомендуемое значение: не более 100 элементов.
❌ Много свойств у товаров — увеличивает нагрузку и время выполнения.
❌ Ручное редактирование в админке перетирается данными из 1С.
❌ Массовое изменение заказов (обработчиком или API) — вызывает очередь, которую 1С не успевает обработать.

Ручная отладка обмена

Иногда проще отладить руками, эмулируя работу 1С.

Пример запросов:

Авторизация:

/bitrix/admin/1c_exchange.php?type=sale&amp;mode=checkauth
/bitrix/admin/1c_exchange.php?type=catalog&amp;mode=checkauth

Полученный

sessid

используется в следующих шагах.

Загрузка файла вручную:

Положите нужный XML-файл в
```
/upload/1c_catalog/
```
Вызовите:

/bitrix/admin/1c_exchange.php?type=catalog&amp;mode=file&amp;filename=rests_123.xml&amp;sessid=ВАШ_ID

Жмите F5 — по ответам на экране будет видно, когда обмен завершится

Почему не выгружаются заказы

Если 1С «не видит» заказы:

Проверьте отбор на стороне 1С — может стоять фильтр «только оплаченные»
Сайт отправляет всё, что попадает под условия (
```
дата изменения &gt; последней выгрузки
```
)

Важно: при ручной проверке обмена заказы выгружаются один раз. Чтобы повторить выгрузку — нужно изменить заказ вручную (например, добавить комментарий).

Проверка:

/bitrix/admin/1c_exchange.php?type=sale&amp;mode=query&amp;sessid=ВАШ_ID

Кастомизация модуля обмена

Что можно делать безопасно:

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

Что не стоит делать:

править ядро модуля обмена напрямую — это приведёт к проблемам при обновлении

Дополнительные справочники (например, бонусы клиентов) лучше выгружать через отдельный скрипт (XML, CSV, JSON).

Реальный кейс: обмен встал из-за завершённых заказов

На одном из проектов 1С начала выгружать старые заказы, уже в статусе «Выполнен». Битрикс по умолчанию не позволяет вносить изменения в закрытые заказы. В результате:

1С пыталась обновить более 1000 заказов
сайт их отклонял
обмен вставал
сервер перегружался

Что сделали:

Очистили очередь заказов на сайте (
```
mode=query
```
)
В таблице
```
b_sale_order
```
сняли флаг «к выгрузке»
В 1С очистили внутренний реестр на стороне обмена

После этого обмен заработал.

Общие выводы

Обмен с 1С — мощный инструмент, но требует внимания:

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

Если проект выходит за рамки стандартного обмена — стоит рассматривать переход на брокеры: RabbitMQ, Kafka, Datareon. Там выше гибкость и скорость, но потребуется тщательная архитектура, чтобы избежать зацикливаний и потерь данных.

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

Репрайсер для маркетплейсов: для озон и wildberries

Tue, 03 Jun 2025 11:38:08 +0300

Мы тут пилим новый стартап — систему управления ценами на маркетплейсах, на сленге репрайсер с парсером. И если честно, идем по самому «неправильному» пути.

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

Но давайте по делу.

Проблема, которая болит у многих

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

Следить за этим можно, но это ад. Глазами и ручками по 2–3 раза в день просматривать сотни карточек? Такое даже на старте звучит как наказание.

Что мы сделали

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

Сравнивает текущую цену на карточке с базовой.
Если цена на маркетплейсе опустилась ниже — высчитывает разницу и повышает базовую цену до нужного уровня.
Выгружает обновленную цену через API обратно на площадку.

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

MVP

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

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

Если вы ищете репрайсер для маркетплейсов, который работает с Wildberries и Ozon — вы по адресу. Наш сервис Guard Price — это автоматическая система мониторинга и корректировки цен, созданная из реальной боли клиентов. В отличие от других решений, наш репрайсер WB и Ozon не просто следит за ценами, а автоматически поднимает их до нужного уровня, если маркетплейс внезапно активировал скидку.

Интеграции с Excel, Google Таблицами, 1С, а также удобная работа с API делают его идеальным инструментом для продавцов, которые хотят сохранить маржу и контроль над ценами. Сейчас тестируем MVP и собираем обратную связь, чтобы сделать продукт ещё лучше. Попробуйте — даже если вы уже знакомы с MPStats или Indeeper.

Сейчас тестируем гипотезу через лендинг, а вот кстати ссылочка: https://guardprice.ru/

Проект сдан. Но не закончен

Fri, 30 May 2025 15:50:40 +0300

Май — месяц новых рубрик.

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

Суть рубрики:
Я буду описывать ситуации — вымышленные, а иногда и вполне реальные — из практики, связанной с нашей «агентской» деятельностью. Через пару дней после публикации кейса выкладываю своё мнение и вариант решения. Формат интерактивный, полезный и местами душераздирающий.

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

p.s. Формат не я придумал — честно подсмотрел у Сергея Колганова. Постараюсь адаптировать под нашу специфику.

Погнали.

🎮 Игровой кейс №1000.
Клиент возвращается с «небольшими доработками» после сдачи проекта...

Ситуация: Проект успешно сдан, акты подписаны, клиент доволен. Проходит две недели, и от него приходит письмо: «Ребята, все супер, но мы тут подумали, было бы здорово еще вот тут кнопочку подвинуть, тут текст поменять, а еще добавить небольшой раздел с отзывами. Это же мелочи, быстро сделаете в рамках гарантии/поддержки?» Вы понимаете, что «мелочи» могут легко вылиться в несколько дней работы, а то и больше, если начать копать.

Как реагировать?

Все бесплатно: Быстро сделать все правки для лояльности, не выставляя счет.
Отказ по ТЗ/договору: Проект принят. Новые задачи – платно. Предложить новый заказ.
Гибкий подход: Мелкие правки – бонус. Крупные – оценить и выставить счет.
Абонентская поддержка: Предложить договор на ежемесячную поддержку для доработок.

Ответ будет через пару дней

Ответ к кейсу 1000. Как бы поступил я и почему это

Это одна из самых частых и деликатных ситуаций в нашей работе. Тут важно найти баланс между лояльностью клиента и защитой своих ресурсов.

Почему не вариант 1 (Сделать все бесплатно)? Это опасная дорожка. Один раз сделав бесплатно значительный объем доработок, вы рискуете создать у клиента впечатление, что так будет всегда. «Мелочи» могут превратиться в бесконечный поток, а ваша команда будет тратить время, которое не оплачивается. Это прямой путь к снижению рентабельности и демотивации сотрудников.
Почему не вариант 2 (Вежливо, но твердо отказать на все)? Слишком формальный и жесткий подход может обидеть клиента, особенно если он действительно лоялен и у вас были хорошие отношения. Даже если вы юридически на 100% правы, это может испортить долгосрочное сотрудничество и сарафанное радио. Иногда небольшая гибкость окупается сторицей.
Почему не вариант 4 (Сразу предлагать абонентскую поддержку)? Это хороший вариант для дальнейшего развития отношений, но если клиент пришел с небольшим конкретным запросом, сразу «продавать» ему абонемент может быть преждевременно и выглядеть как попытка навязать ненужную услугу. Лучше сначала решить текущую потребность.

Так почему же вариант 3 – оптимальный?

Гибкость и клиентоориентированность: Вы показываете, что слышите клиента и готовы пойти навстречу. Сделать пару действительно мелких правок (например, заменить номер телефона или поправить опечатку) – это хороший жест, который почти ничего вам не стоит, но ценится клиентом.
Установление границ: Одновременно вы четко даете понять, что есть предел бесплатных «плюшек». Когда вы говорите: «Вот это мы сделаем быстро как бонус, а вот эти задачи (например, добавление нового раздела) уже требуют времени наших специалистов, давайте оценим и согласуем», – вы приучаете клиента к тому, что дополнительная работа стоит денег.
Прозрачность: Клиент видит, что вы не просто отмахиваетесь, а анализируете его запрос. Предоставление оценки на платные доработки позволяет ему принять взвешенное решение.
Мост к дальнейшему сотрудничеству: После того как вы помогли с текущими «мелочами» (часть бесплатно, часть платно), можно уже предложить и вариант 4 – абонентскую поддержку, если клиент предполагает, что подобные задачи будут возникать регулярно. Это будет выглядеть логичным и своевременным предложением.

Практический вывод: Всегда будьте готовы к таким запросам. В идеале, еще на этапе подписания актов проговорите с клиентом, что входит в гарантийную поддержку (исправление ошибок, которые были в рамках ТЗ), а что является новой задачей. Но если такой разговор не состоялся или клиент «забыл», действуйте по варианту 3. Проявите немного гибкости, но не позволяйте садиться себе на шею. Четкая коммуникация и аргументация – ключ к успеху.

Как ускорить сайт на Битрикс: полный гайд по оптимизации скорости загрузки

Tue, 20 May 2025 08:38:38 +0300

По статистике, на Битриксе работает около ~ 11% сайтов в РФ. Это не мало, для сравнения тильда и WP ~ 59%.

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

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

Общие шаги анализа

Собрать обратную связь. Какие страницы тормозят? Какие действия? Где затыки?
Проверить системные требования. CPU, RAM, дисковая подсистема — всё должно быть в норме.
Оценить загрузку сервера. top, htop, Task Manager — загруженность ЦП, памяти, диска.
Проверить географию. Сервер должен быть в РФ, а не на экваторе.
Дальше — по слоям: локация → сервер/ПО → окружение → backend → frontend.

Анализ сервера

Скорость диска. Проверь через hdparm, fio. Норма — от 150 МБ/с.
Доступность сервера. Не перегружен ли ботами? Смотри access.log.
Ошибки. error.log, php_errors.log — критические сбои и ошибки.
PHP. Настройки opcache, memory_limit, max_execution_time.
MySQL. Проверь query_cache, innodb_buffer_pool_size, tmp_table_size.
Cron. Нагрузка от зацикленных или тяжёлых заданий.
Свободные ноды. Хватает ли ресурсов под процессы?
Свободное место. Минимум 5–10 ГБ должно быть свободно.

Анализ базы данных

Диагностика Битрикс. Встроенный инструмент: /bitrix/admin/performance.php.
Медленные запросы. slow_query_log, инструмент в phpMyAdmin, EXPLAIN.
Индексы. Наличие по часто используемым полям.
Очистка. b_event_log, b_search_content — чистим старое.
Жирные таблицы. Например, b_sale_fuser может распухнуть до гигабайтов.

Анализ кода и модулей

Включить отладку. Кол-во запросов, время ответа.
Кэш и композит. Должны быть включены и корректно работать.
Пользовательский код. Отключить свои компоненты, проверить init.php.
Отключение модулей. Через /bitrix/admin/module_admin.php. Всё лишнее — в архив.
Профайлер. /bitrix/admin/perfmon_panel.php — ищем долгие участки.
Тяжёлые функции. CIBlockElement::GetList, CSaleOrder::GetList — аккуратно.
Обмены. С 1С и прочими системами — могут грузить базу и API.

Оптимизация фронтенда

Сокращение запросов. Анализ в браузере — DevTools.
Кеширование. Проверить, работает ли компонентный кеш.
Минификация CSS/JS. Через /bitrix/admin/performance_tuning.php.
GZIP. Должен быть включён для статики.
Изображения. Сжатые, современный формат (WebP).
Внешние подключения. Шрифты, YouTube, картинки — переложить внутрь проекта.

Тестирование нагрузки

Стресс-тест. Apache JMeter, k6 — симуляция пользователей.
Сессии. Где возможно — убрать session_start().
Очередь заданий. Проверить /bitrix/admin/agent_list.php, лучше — cron.
Кэш серверных данных. Redis / Memcached > файловый кэш.

Инфраструктурные проверки

Сетевые задержки. ping, traceroute.
CDN. Для ускорения статики.
Балансировка. Если есть балансировщики — проверяем распределение.
Актуальность ПО. Версии PHP, MySQL, модули Битрикс — обновлены?

План Б: смена окружения и архитектуры

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

Apache + mod_php
PHP-FPM
PHP-PM
FrankenPHP
RoadRunner
Swoole
NGINX Unit

Что выбрать — зависит от контекста. Универсального ответа нет.

Железо: когда ускорение начинается с «железа»

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

Процессор

Битрикс активно использует одноядерные операции → важна производительность на ядро.
Частота — от 3.5 ГГц. Желательно с Turbo Boost (Intel) или Precision Boost (AMD).
Кэш L2/L3 — чем больше, тем лучше.
Новые архитектуры (Intel Alder Lake, AMD Zen 3) дают реальный прирост.
Пример: Intel Core i7-13700K с архитектурой Raptor Lake — на голову выше старых Xeon.

Диски

Только SSD. Лучше — NVMe (но не любой: смотри IOPS, задержки, скорость записи/чтения).

Дополнительно

Elasticsearch — для поиска, фильтров, сортировки, каталогов.
Kafka, RabbitMQ, Datareon — брокеры очередей.
Часть рекомендаций актуальна и для Битрикс24, но у него требования к окружению ещё выше.

Это должно помочь.

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

Почему не стоит копировать Apple или Авито под ключ

Wed, 07 May 2025 09:10:38 +0300

В жизни любой веб-студии, digital-продакшена или фрилансера случались заявки вроде:
«Сделайте лендинг как у Apple»,
«Хочу аналог Авито, но с нашим дизайном»,
«Давайте повторим HH, только для другой ниши».

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

Разбираться в мотивах таких идей не будем — они понятны. Давайте поговорим, почему, скорее всего, ничего путного из этого не выйдет.

Дизайн как у Apple — это не про шрифты и анимации

Когда звучит фраза «Сделайте как у Apple», важно задать вопрос: зачем? У Apple аудитория в сотни миллионов пользователей, и их сайт — это финальный штрих гигантской маркетинговой машины.

Да, можно вдохновиться стилем, использовать похожие акценты или анимации. Но магия Apple — это не шрифт San Francisco и не белые фоны. Это контент: рендеры, тексты, микровзаимодействия, проработанные до пикселя.

За этим стоит команда из десятков дизайнеров, маркетологов, фотографов и 3D-художников. И если вы не собираетесь вкладываться на этом уровне — результата «как у Apple» не будет.

В итоге получаем не «как у Apple», а «как смогли». И это не про дизайн — это про ожидания.

Сделать «аналог Авито» — звучит просто

Ещё один популярный запрос — клон маркетплейса, доски объявлений, дейтинга и любых платформ, где встречаются две стороны: продавцы и покупатели.

В представлении заказчика это сайт из трёх страниц: главная, каталог и карточка объявления. Просто, быстро, дешево.

Но на деле — это сложный бэкенд с множеством взаимосвязей.
Понадобятся:

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

И это мы даже не трогаем главную боль: «проблему курицы и яйца». Нет аудитории — нет контента. Нет контента — никто не приходит.

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

Разработка — это не самое главное

Удивительно, но факт: разработка — это не главная часть таких проектов. Она важная, она дорогая, но она технически решаемая.

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

Если этого нет — не спасёт ни код, ни крутой дизайн.

Что делать вместо

Итак, если вдруг вам в голову пришла «гениальная идея» создать ещё один маркетплейс — остановитесь и задайте себе честный вопрос: а точно ли он нужен рынку?

Возможно, лучше:

стартовать с более простого решения — например, классического e-commerce;
собрать MVP, где продавцов эмулирует внутренняя команда;
сосредоточиться на валидации гипотез, а не на масштабной разработке.

И напоследок — про флажки в ТЗ

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

Лучше чуть проще, но честно. И с пониманием, что вы делаете и зачем.

Хочешь MVP, который работает, а не мечту на Figma — сядь, посчитай, подумай. А потом уже запускай.

Почему проекты срывают сроки: 10+ причин провалов и способы избежать хаоса в разработке

Wed, 23 Apr 2025 11:04:10 +0300

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

🗂 Согласования. Требуют гораздо больше времени, чем кажется. Когда вам называют сроки до старта работ, в них обычно не заложено время на обратную связь. Представьте дизайн типового ecom-проект с 100+ экранами: предварительное согласование, затем правки, потом утверждение всего пула, а еще адаптив под минимум 4 разрешения. И ведь нужно не просто посмотреть, но и вникнуть, дать конкретные замечания. Сколько на это заложить времени?

👥 Команда. Еще один критический фактор. Люди болеют, уходят в отпуск. Конечно, эти риски лежат на подрядчике, и если его менеджмент умеет виртуозно жонглировать ресурсами, то сроки едут не сильно или вовсе не едут. Тут многое зависит от проектного менеджера — сильный PM вывезет проект с любой командой.

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

🔗 Интеграции. Сегодня есть почти в каждом проекте — 1С, ERP, Microsoft Dynamics или какая-нибудь шина данных. И даже при максимально качественном предпроектном обследовании что-то может пойти не так. Данные в каталоге могут оказаться заполненными наполовину или быть в неожиданном формате.

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

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

🤔 Недооценка сложности задач. Это классическая проблема — разработчики склонны оптимистично оценивать задачи, не учитывая «закон Хофштадтера»: все занимает больше времени, чем кажется, даже с учётом закона Хофштадтера.

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

✅ Нечёткое определение готовности. Без чётких критериев приёмки или «definition of done» команды могут бесконечно полировать функциональность или, наоборот, считать задачу завершённой раньше времени.

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

Минимизируем риски

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

— 🌀 Гибкое управление проектом. Это позволяет оперативно реагировать на изменения, отслеживать прогресс и пересматривать задачи по мере их выполнения. Разделить проект на маленькие итерации (спринты) с четкими результатами по каждой, что позволяет отслеживать и контролировать риски в реальном времени.

— 🧑‍⚕️ Резервирование ресурсов. Создание резервных ресурсов и планов на случай отсутствия ключевых сотрудников (по болезни, отпуску).

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

— 🧩 Планирование рисков. Идентификация потенциальных рисков на старте проекта и подготовка стратегий для их минимизации.

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

Laravel + Orchid: Идеальное решение для админок без CMS

Mon, 21 Apr 2025 10:32:35 +0300

Не только Битриксом едины. Иногда мы меняем модули и компоненты на роуты и контроллеры — Laravel в нашем арсенале давно.

На нём мы собираем всё: от бэкендов под мобилки до админок для магазинов. А дальше — как фантазия подскажет 😅

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

Писать с нуля на HTML – можно даже купить готовый шаблон, есть весьма приличные варианты.
Сделать отдельный фронт на Vue или React – пишем API для редактирования, отдельно собираем фронтенд.
Использовать готовое решение – наиболее известные сейчас: SleepingOwl, Laravel Nova и Orchid.

Когда-то давно мы использовали SleepingOwl, но по ряду причин отказались от него. Laravel Nova хороша, но платная. В итоге мы обратили внимание на Orchid – визуально приятное, опенсорсное, кастомизируемое и регулярно обновляемое решение.

Это база

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

📊 Гибкие таблицы и формы – Встроенные механизмы для работы с таблицами (TD, Layouts, Screens) позволяют легко создавать CRUD-интерфейсы, настраивать фильтрацию и сортировку данных.

🔐 Система разрешений (ACL) – Гибкая ролевая модель, которая позволяет управлять доступом на уровне пользователей, ролей и отдельных действий.

🎨 TailwindCSS + Turbo – В Orchid используется современный стек технологий, что делает интерфейс легковесным и быстрым без необходимости вручную писать HTML и CSS.

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

Неочевидно

🧠 «Глобальные состояния» в Screens – Можно использовать $this->state() для хранения и передачи данных между методами внутри одного экрана (аналог Livewire). Это позволяет сделать более сложные и динамичные страницы без обновления.

🚀 Интерактивные элементы через AsyncAction – Orchid поддерживает асинхронные операции без перезагрузки страницы. Можно использовать AsyncAction для выполнения сложных запросов, отправки писем или обновления данных в фоновом режиме.

🔔 Поддержка WebSockets – Orchid позволяет легко интегрировать Laravel Echo и Pusher для создания real-time интерфейсов, но эта возможность редко используется. Можно делать обновления данных без перезагрузки.

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

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

В итоге — Orchid оказался именно тем, что искали для Laravel-проектов. Прост в освоении, гибок в кастомизации и визуально приятен. Можно быстро собрать MVP, а потом не стыдно и в прод выкатить.

Интеграция 1С и Битрикс24: варианты решений для закрытых контуров и сложных проектов

Fri, 18 Apr 2025 09:29:56 +0300

Довольно много работаем с коробочными Битрикс24 — от энтерпрайзов до поменьше — и почти всегда на таких проектах всплывает тема интеграций. Битрикс24 с чем-то ещё.

Чаще всего это, конечно, 1С. Обычно в виде ЗУП — «Зарплата и управление персоналом». Вполне логично: когда у тебя 1000+ пользователей внутреннего портала, удобнее управлять ими централизованно через одну систему.

В целом для ЗУПа есть штатная интеграция. Пользователей и немного данных она передаёт, но не более.

🔐 Проблема закрытых контуров
Частая история: 1С живёт в изолированном контуре, где интернет даже не ночевал. А интеграция даже у коробочных Битриксов работает через серверы вендора. Получается, что связать «открытый» Битрикс24 и «закрытую» 1С — почти невозможно.

А бывает и хуже: обе системы закрыты, и каждая — в своём контуре. Это уже совсем весело.

🧰 Какие есть варианты интеграции
Разберу по степени сложности и зрелости проекта.

🗂 1. Обмен через файлы
Форматы могут быть любые: CSV, XML, Excel.
1С формирует файл, кладёт у себя. Прокси-сервер, у которого есть доступ и туда, и наружу, отгружает файл в Битрикс24. Дальше всё обрабатывается. Обратно — по той же схеме.

Плюсы:
– быстро
– просто
– дешево

Минусы:
– сложно контролировать
– мало гибкости
– можно сломать одной запятой

🔌 2. API с обеих сторон
На стороне 1С — веб-сервис. На стороне Битрикс24 — обработчик, который знает, что и куда тащить. Прокси по-прежнему нужен. Такой вариант требует больше усилий, особенно если потоков несколько: пользователей гоним, задачи, отпуска, статусы.

Если настроить всё грамотно — один из самых универсальных способов. Особенно если есть потребность в двустороннем обмене.

🛢 3. SQL-шина
Работает как прокси. Оба участника читают и пишут в общую базу. Обычно один поток = одна таблица. Например, пользователи из 1С → в Битрикс24 — это один поток. Можно, конечно, всё в одну таблицу, но тогда больше шансов на косяки.

Хорош тем, что всегда можно зайти, посмотреть, что передано, что зависло, что обработалось. Прозрачно и удобно. Я бы назвал это «шина на коленке», но работает стабильно.

🏗 А если нужно что-то посерьёзнее?
Когда обменов много, системы становятся сложнее, появляется больше направлений и требований по отказоустойчивости — начинают появляться полноценные брокеры сообщений: Kafka, RabbitMQ, всё чаще — Datareon.

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

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

⚠️ О чём часто забывают
– CSV может поломаться от одной запятой
– API требуют авторизации, логирования, повторных попыток
– SQL-шина без чётких расписаний может вызвать гонки данных
– Kafka и Rabbit — мощно, но требовательно, особенно к инфраструктуре и команде

🔒 Безопасность и устойчивость
Независимо от подхода — критично:
– логировать обмен
– ограничивать доступ
– обрабатывать ошибки
– предусмотреть восстановление после падения

Особенно если данные важные, а обмен идёт в реальном времени.

🧩 Что удобно в реальных проектах
– возможность вручную «толкнуть» данные в систему
– визуализация очередей (видно, что висит и почему)
– простое добавление новых параметров без переписывания всей логики
– защита от потери данных, подтверждение доставки

Гейзенбаг и самооборона: Как проактивная защита Битрикса может заблокировать сам себя

Wed, 16 Apr 2025 09:47:45 +0300

💡 Гейзенбаг (Heisenbug) — это такой баг, который исчезает или меняет поведение, как только ты пытаешься его исследовать. Смотришь — и он уже ведёт себя по-другому. Почти как квантовая частица 🧙‍♂️

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

Ситуация вымышленная, все совпадения случайны (ну почти).

На входе: корпоративный сайт на Битриксе, который отдаёт API. Фронт — на Vue 3 / Nuxt.
Симптомы: периодически, в разное время, часть фронта просто перестаёт работать, а в браузере — ошибка: Nuxt не работает.

Примерно через 20–60 минут всё само «оживает» и продолжает работать как ни в чём не бывало.

Что говорят логи?
🔍 pm2 — пусто (есть варнинги, но не критичные)
📄 nginx — чисто
🐘 php — молчит
🧱 Битрикс — почти ничего, а что есть — не страшно
🖥 Нагрузка на сервер — не выше 20%
💽 Жёсткие диски — расслаблены, курят бамбук

Мы прыгали с бубном вокруг сервера, но:
— эмуляция нагрузки не даёт сбоя
— API отвечает
— тестовый стенд работает как часы

Железо и нагрузка тут не при чём.

Так мы жили пару месяцев, перебирав все мыслимые и немыслимые варианты 🧠

Пока однажды...

В access.log заметили, что часть трафика отбраковывается с ошибкой 403 ❌
Причина — попытка инъекции вредоносного кода. С одной стороны — хорошо: злоумышленник не пробрался 👮‍♂️
С другой — странно. Кто именно блокирует?

Выяснилось: проактивный фильтр Битрикса.
Стало интересно. Копаем глубже ⛏️

Симулируем атаку: подставляем «вредный» код в URL и… ловим бан от Битрикса.
Фронт частично перестаёт работать. Вот оно! 🧩

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

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

🚫 Вуаля: фронт частично недоступен, API под блоком.
🔥 Причём инициатором бана оказался... он сам 🤦

P.S.
Решение «сложить фронт и бэкенд на один сервер и один домен» — не наше, так что не кидайтесь тапками 👟

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

Выбираем архитектуру: монолит против микросервисов

Mon, 07 Apr 2025 17:39:16 +0300

Объявим участников. В правом углу — бывший чемпион в супертяжелом весе — Мистер Монолит. В левом углу — молодая и накачанная банда микросервисов в полулегком весе.

Я видел несколько серьезных монолитов в своей жизни. У одного из них было около 5+ часов времени сборки, и компании пришлось построить свой собственный CI, чтобы продолжать двигаться вперед.

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

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

Определения

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

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

Мертвая лошадь?

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

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

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

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

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

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

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

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

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

Ок. Монолит плох. Микросервисы плохи... Ааааа... Всё плохо. Бежать некуда. Что делать?

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

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

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

Вопрос масштаба

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

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

В данной части я конечно утрирую, но все же от проекта к проекту понитие “микро” может быть разным. Где то это сервис вроде PIM, поиска или шины данных, а у кого то это сервис состоящий из 1 — 2 классов и например конвертирует данные из одного формата в другой.

Все упирается в вопросы масштаба с которым вы смотрите.

Что выбрать?

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

По мере того, как они начинают расти, ищите естественные трещины (куски кода с очень разными атрибутами). Это те части, которые можно постепенно разделить на отдельные сервисы.

Главное не пропустить момент, когда монолит выходит из-под контроля. Лучше начать разделять вещи немного преждевременно, чем сделать это слишком поздно. Мое внутреннее чувство подсказывает, что как только вы начинаете тратить около 5% своего времени на борьбу с проблемами монолита, пора что-то с этим делать.

Приведу пример на родном, прости господи, Битрикс. С ростом проекта, вероятно, первым делом у вас возникнул проблемы со стандартным обмен с 1С, если оно есть. Это решается как раз выделение модуля обмена в отдельный сервис плюс шина данных Ребит или Кафка.

Контекст имеет решающее значение

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

Когда-то и мы были дикими 🦖

Thu, 03 Apr 2025 08:25:16 +0300

На заре становления нашей компании Git был чем-то непонятным и ненужным.

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

Сейчас, попадая на проект без Git, мы испытываем недоумение: как компания жила и развивала свой проект без системы контроля версий? Например, совсем недавно к нам обратился клиент с запросом на доработку e-commerce проекта. Начав разбираться, мы увидели, что изначально это был шаблонное решение, но со временем в него добавили массу кастомных решений – местами удачных, местами не очень.

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

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

Базовый набор инструментов для работы над проектами

1. Git – это база
Без Git сегодня никуда. Это не только система контроля версий, но и страховка от случайных ошибок и удобный инструмент командной работы. Мы используем локальный GitLab, но если у клиента уже есть свой репозиторий, работаем с ним.

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

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

3. CI/CD – автоматизация развертывания
На некоторых проектах без CI/CD просто невозможно работать. Хотя не всегда он нужен в минимальном наборе, на серьезных проектах это must-have. Мы используем GitLab CI/CD для автоматизации развертывания и тестирования.

4. Документация – экономия времени в будущем
Честно говоря, мы сами не всегда вели документацию, но это неизменно приводило к проблемам. Поэтому сейчас придерживаемся правила:
– Завершил задачу – добавь описание в таск-трекер.
– Внес значительное изменение – задокументируй в базе знаний.

Для этого используем комбинацию Яндекс.Трекера и его встроенной вики. Главное – неважно, какой инструмент вы используете (хоть Google Docs), важно, чтобы документация была.

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

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

6. Мониторинг – чтобы не ловить проблемы постфактум
Даже качественный код не спасает от внешних факторов: сервер может упасть, провайдер может отключить услугу, модули могут сломаться. Чтобы не узнать о проблеме от разъяренного клиента, мы используем три инструмента:

Uptime – отслеживание доступности проекта и сбор статистики.
Zabbix – мониторинг состояния сервера (нагрузка, память, дисковое пространство).
Sentry – слежение за ошибками на фронтенде и бэкенде. Да, он потребляет 15 ГБ ОЗУ, но зато все ошибки наглядно и с алертами.

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

А какие инструменты используете вы?

Киллер-фича 🚀

Tue, 01 Apr 2025 08:38:59 +0300

Хотите приложение для своего проекта? Допустим, у вас есть портал, сервис или интернет-магазин, и вы хотите сделать для него мобильное приложение. Какие у вас есть варианты?

Нативные приложения 📱

Первое, что приходит на ум, — это нативные приложения для iOS и Android. Для их разработки используются Swift и Kotlin. По сути, это два отдельных проекта, объединенных только общим API и дизайном (и то далеко не всегда). У каждой платформы свои особенности, поэтому неудивительно, что иногда Android уходит вперед в развитии, а иногда наоборот. Разработка нативного приложения требует ресурсов, ведь поддерживать две платформы сразу — это двойная работа, больше затрат на тестирование, исправление багов и обновления.

Кроссплатформенные решения 🔄

Следующий вариант — кроссплатформенные технологии. Например, Xamarin (жив ли он еще?), React Native или Flutter, который сейчас на коне. В этом случае процесс разработки схож: сначала создаем API, затем собираем дизайн, интегрируем аналитику, настраиваем пуш-уведомления и наконец запускаем приложение. Поддерживать такой проект проще, так как код один, но все же в некоторых случаях приходится делать доработки под каждую платформу. Это дешевле, чем нативная разработка, но все равно может быть затратным.
Но что, если и этот вариант не подходит по бюджету? 🤔

PWA — альтернатива ⚡️

Здесь на сцену выходит PWA — технология, которая позволяет создать приложение на базе обычного веба. Прогрессивные веб-приложения (Progressive Web Applications) представляют собой улучшенные версии привычных сайтов, которые ведут себя как мобильные приложения.

Существует также TWA (Trusted Web Activities), которая позволяет запускать веб-сайты как приложения на Android, используя Chrome Custom Tabs, и IWA (Isolated Web Apps) — изолированные веб-приложения, работающие в ограниченной среде. Однако в большинстве случаев никто не вникает в эти нюансы и называет все просто PWA.
Мы используем эту технологиями уже 6-7 лет и можем сказать: работает, можно брать.

Как создать? 🛠

Если ваш проект уже работает на Vue или React, то считайте, что он готово, почти. В противном случае сначала нужно собрать API, затем создать отдельный фронтенд, ориентируясь на мобильное разрешение, и наконец интегрировать все вместе. Бэкенд может быть любым — хоть Laravel, хоть Битрикс, хоть даже WordPress (да-да, мы такое встречали). Главное, чтобы сайт работал по HTTPS.

Когда все готово, начинается магия. Загружаем проект на сервер и переходим на сайт PWA Builder или аналоги Аналогов довольно много. Указываем ссылку на наш PWA, ждем. Если есть ошибки в манифесте или других настройках, исправляем их и повторяем процесс. В результате получаем два исходника: один для Android, другой для iOS. Дальше загружаем их в магазины приложений, следуя стандартным инструкциям.

Киллер фича ✨

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

Минусы? 🤷‍♂️

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

Заключение 📊

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

Брокеры сообщений: что это, как работают и какой выбрать?

Tue, 25 Mar 2025 18:33:41 +0300

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

Виды общения

Общение — это основа взаимодействия между людьми и системами. Самый привычный формат — диалог, когда один человек (N) передаёт информацию другому (Y) и ожидает ответ. Это классическая модель запроса и ответа.

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

Существует также обмен через посредника. Представим, что N передаёт сообщение X, а тот, в свою очередь, распространяет его среди друзей C, D и E. Этот принцип реализован в мессенджерах и новостных рассылках.

Другой вариант — N записывает сообщение и оставляет его в специальном ящике. X может забрать его в удобное время. Здесь каждый получатель получает только одно сообщение.

Паттерны обмена информацией

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

Request-Response (Запрос-Ответ) – примером является работа HTTP, когда клиент делает запрос на сервер и ждёт ответа.
One-Way (Односторонний обмен) или Fire and Forget (Отправил и забыл) – отправитель передаёт сообщение без ожидания ответа, как в случае с UDP-пакетами.
Publish-Subscribe (Публикация-Подписка, Pub-Sub) – отправитель публикует сообщение в канал, а подписчики его получают.
Point-to-Point (Точка-Точка) – каждое сообщение доставляется только одному получателю.

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

Роль брокеров сообщений

Брокер сообщений – это программный посредник, который реализует паттерны Pub-Sub и Point-to-Point. Его основная задача – упрощение маршрутизации, хранения и доставки сообщений. Использование брокера оправдано, если:

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

Гарантия доставки сообщений

При передаче данных возможны сбои, поэтому брокеры предлагают различные уровни гарантии доставки:

At most once (Не более одного раза) – сообщения могут теряться.
At least once (Хотя бы один раз) – возможна повторная отправка, чтобы гарантировать доставку.
Exactly once (Строго один раз) – сообщения не теряются и не дублируются.

Очереди и топики

Брокеры реализуют два основных механизма работы:

Очереди (Queue, Point-to-Point) – сообщение читается одним получателем и затем удаляется.
Топики (Topic, Pub-Sub) – сообщение доставляется сразу нескольким подписчикам.

Альтернативные подходы

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

RabbitMQ: «умный брокер, тупой потребитель»

RabbitMQ – традиционный брокер с поддержкой Pub-Sub и Point-to-Point. Он активно управляет сообщениями: распределяет их по подписчикам, отслеживает их статус и удаляет после обработки. Он поддерживает At most once и At least once, а его настройка проще, чем у Kafka.

Принцип работы RabbitMQ:

Отправитель (Publisher) передаёт сообщение в обменник (Exchange).
Сообщение попадает в одну или несколько очередей (Queue).
Подписчики (Consumers) забирают сообщения из очереди.

Apache Kafka: «тупой брокер, умный потребитель»

Kafka – мощный брокер для работы с большими объёмами данных. В отличие от RabbitMQ, он не удаляет сообщения после обработки. Они остаются в хранилище и могут быть прочитаны несколько раз. Kafka поддерживает Exactly once и обладает высокой отказоустойчивостью.

Принцип работы Kafka:

Продюсер (Producer) отправляет сообщение в топик.
Брокер записывает сообщение в журнал (лог) без удаления.
Подписчики (Consumers) сами запрашивают (pull) сообщения.

Kafka vs RabbitMQ: что выбрать?

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

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

Баги, Ошибки, Проблемы, Недостатки, Неисправности, Сбои, и Дефекты

Thu, 27 Feb 2025 10:11:02 +0300

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

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

Если что-нибудь может пойти не так, оно пойдёт не так...

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

Дефект — это ошибка, обнаруженная на этапе разработки.

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

Сбой или отказ — это когда система не соответствует своим требованиям. Это ошибка, которая дошла до пользователя.

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

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

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

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

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

Несколько примеров интересных ошибок

Ошибки единиц измерения

Когда вы имеете дело с физическими системами, единицы измерения имеют значение. Есть разница, едете ли вы со скоростью 100 миль или 100 км в час. Это опыт, который команде Mars Climate Orbiter пришлось пройти нелегким путем: одна команда использовала ньютоны, а другая — фунт-силы. Это несоответствие в коммуникации между двумя программными компонентами привело к взрыву космического корабля. Это потеря в размере 327,6 млн долларов США.

Ошибки на единицу или ошибка неучтённой единицы (Off-by-One Errors)

Ошибки на единицу — это одни из самых распространённых логических ошибок в программировании. Они возникают, когда мы путаемся в границах ><=:

Меньше или меньше либо равно
Больше или больше либо равно
Меньше или больше

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

Хорошие юнит-тесты помогают выявлять ошибки.

Условия гонки / race condition

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

Грязное чтение
Неповторяющиеся чтения
Фантомное чтение

Ошибки, вызванные гонками данных, очень трудно отловить, поскольку они зависят от точного времени выполнения разных процессов. Из-за этого их иногда называют «Гейзенбагами» (Heisenbugs) – если попытаться их поймать, они словно исчезают.

Нефункциональные проблемы

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

Другая частая проблема — чрезмерное потребление памяти в браузерах. Это критично для смартфонов, где ресурсы ограничены.

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

Человеческая ошибка

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

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

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

Держите меня семеро, я прикручиваю ИИ

Tue, 18 Feb 2025 11:35:29 +0300

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

Для особо душных: мы будем использовать не «искусственный интеллект», а языковую модель на основе нейронных сетей, построенную по архитектуре трансформера (далее — ИИ).

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

Выбор между локальным и облачным решениями

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

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

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

Выбор облачной платформы

Так как сервис ориентирован на российский рынок, требовалось решение с серверами в РФ. Коробочную версию мы исключили по причинам, указанным выше. В итоге выбор сузился до Яндекса и Сбера.

Для тестирования мы использовали GPT и Claude, сформировав 10 типовых задач для генерации текста.

Результаты тестирования

Вот субъективные оценки различных моделей по нашему сценарию:

Яндекс 4 Lite — 9
Яндекс 4 Pro — 7
Claude 3.5 Sonnet — 7
Claude 3.5 Haiku — 6
GPT-4o Mini — 8
GigaChat — 5

В итоге остановились на младшей модели Яндекса. Она показала хорошие результаты и выдачу в удобном формате.

Песочница Яндекса

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

Что дальше

Мы принимаем ответы от ИИ через API, обрабатываем их и формируем финальный ответ для пользователя. В целом, процесс довольно прост.

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

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

Теперь рассматриваем вариант внедрения ИИ в поиск, вероятно, через Elasticsearch или напрямую.

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

Fri, 17 Jan 2025 08:37:01 +0300

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

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

Дисклеймер

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

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

Если вы убежденный противник PHP и Битрикса в частности, или скорость для вас ассоциируется исключительно с Go, возможно, этот материал не для вас. Также если вы сеньор-разработчик Битрикса – вам здесь может быть не слишком интересно.

Кейс первый: Таинственное замедление

Первым пациентом стал проект на Битриксе, созданный на основе готового решения с серьезной кастомизацией. B2B-проект с интеграцией с 1С, каталогом около 10 тысяч товаров и примерно сотней свойств. Сервер у проекта был настоящий космолет – на таком не только сайты можно хостить, но и, пожалуй, космические корабли запускать.

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

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

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

Дальнейшее расследование привело нас к таблице с 80 миллионами записей – таблице готового решения, хранящей названия корзин и их цвета. Это была реализация модного разделения корзин. Странность заключалась в том, что при минимальном трафике и закрытом характере портала такой объем данных казался необъяснимым.

Разгадка крылась в роботах – Яндекса, GPT, Apple и прочих. Система создавала для каждого бота отдельную сессию и автоматически генерировала корзину с зеленым цветом и названием по умолчанию. Решение оказалось простым – мы закрыли проект от ботов и добавили механизм очистки неактуальных корзин. Результат – время загрузки снизилось с 6 секунд до 0,04-0,06 секунд.

Кейс второй: Периодические падения сервера

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

Команда проекта уже провела определенную работу: настроили memcached, оптимизировали базу данных, экспериментировали с настройками 1С, но существенных улучшений это не принесло.

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

Первая команда выводит всех ботов в отдельный файл:

awk ’{print $6}’ bots.log | sort | uniq -c | sort -nr | head -n 1

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

awk -F\» ’{print $6}’ bots_sort.log | sort | uniq -c | awk ’$1 > 5000’ | sort -nr

Особенностью проекта оказалось необычное соотношение – на 100 тысяч товаров приходилось 10 тысяч свойств, что существенно выше нормы. Компоненты каталога не были оптимизированы под такой объем данных, а стандартный обмен с 1С только усугублял ситуацию.

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

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

Главные уроки

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

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

В поисках программистов-экзорцистов

Sat, 21 Dec 2024 14:09:44 +0300

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

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

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

В результате заказчик ищет виновника торжества чтобы в будущем не повторять ошибок. Сам на себя он не подумает, может быть причина в подрядчике, но довольно часто заказчик приходит к выводу, что вероятно проблема кроется в технологии. На перезапуск проекта ее непременно нужно поменять на другую: с WordPress на Битрикс, с Битрикса на Laravel, с PHP на Python и так далее. Можете написать любую комбинацию, не промахнетесь.

Важно понимать: нет плохих технологий, языков программирования, фреймворков и CMS — есть их неправильное использование. Это как пытаться есть суп вилкой. Конечно, у каждой технологии есть своя специализация. Например, на Go маловероятно, что вы будете разрабатывать корпоративный сайт. Технически это сделать конечно можно, но вряд ли целесообразно. Однако если задача состоит в том что бы расшить узкое место с помощью отдельного микросервиса, Go может оказаться окажется прекрасным выбором.

Выбор

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

Рассмотрим показательный пример: компания по производству мебели планирует создать платформу для онлайн-продаж. На первый взгляд, задача кажется простой — нужен интернет-магазин. Но копнем глубже: компании требуется интеграция с 1С для учета складских остатков, конфигуратор мебели для клиентов, система управления заказами для менеджеров и API. И здесь мы сталкиваемся с классическим выбором между популярными решениями: Tilda, WordPress, OpenCart, 1С-Битрикс.

Каждая из этих систем прекрасна в своей нише. WordPress изначально создавался как блоговая платформа, OpenCart и 1С-Битрикс специализируется на e-commerce. И хотя современные CMS благодаря плагинам и расширениям способны выполнять практически любые задачи, это не всегда оптимальный путь.

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

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

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

Ключевой критерий

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

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

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

Как обычно важен контекст

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

В IT-мире нет однозначно плохих или хороших решений — они просто разные, как цвета и вкусы. Главное — правильно оценить контекст и сделать осознанный выбор технологии под конкретные задачи.

Синонимы, транслит и магия: Как заставить систему читать мысли пользователя

Sat, 14 Dec 2024 12:42:13 +0300

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

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

Речь идет о транслите, учете ошибок в написании, синонимах и других тонкостях. Обычно все начинается с классического поиска в формате выборки по SQL или нечеткого поиска..

Эволюция

Штатный битрикс поиск умеет искать по названиям и описаниям. Дополнительно в него можно включить любое свойство, чтобы расширить возможности поиска. Это отличный вариант улучшения на старте. Достаточно загрузить каталог в 1С или на сайт и через запятую добавить ключи, по которым должен осуществляться поиск товаров. Функция транслита обычно присутствует, но почти всегда остается выключенной.

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

Появляется Sphinx — довольно старая система, но ее преимущество перед стандартным решением в том, что мы сами индексируем нужные нам данные, плюс поиск становится условно быстрым.

Затем на сцену выходят мощные решения вроде Elasticsearch \+ Kibana — инструмент, который мы регулярно внедряем клиентам. Здесь можно самостоятельно настроить индексацию, синонимы, учет ошибок и аналитические дашборды, а также установить веса — просто идеально.

Мода

Для стартапов и небольших приложений подойдут Meilisearch и Typesense с их простотой использования и быстрой интеграцией. Проекты, связанные с искусственным интеллектом, оценят Weaviate и Milvus благодаря семантическому поиску. Для корпоративных решений рассмотрите Vespa или Opensearch. При необходимости встроить поиск в существующую инфраструктуру обратите внимание на RedisSearch или ZincSearch.

SaaS-сервисы: быстро, но с ограничениями

Отдельно стоит упомянуть SaaS-сервисы. Туда загружается XML или JSON с контентом для индексации, после чего возвращается готовая выдача. Практически это выглядит как установка фрейма или JS-строки поиска с последующим вызовом Vue-компонента с результатами.

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

Что важно учесть

1. Обработка ввода пользователя

Транслитерация: Поддержка ввода на русском и английском (например, «stul» и «стул»).

Опечатки: Распознавание и исправление ошибок (например, «стлу» → «стул»).

Синонимы: Учет различных формулировок (например, «диван» = «софа»).

Регистронезависимость: Поиск должен работать независимо от регистра (например, «СТУЛ» = «стул»).

Множественное число и склонения: Поддержка форм слов (например, «стула», «стулья»).

Префиксный поиск: Результаты при вводе части слова (например, «стул» → «стул», «стулья», «стульчик»).

2. Логика поиска

Релевантность: Ранжирование результатов по популярности, наличию и соответствию.

Поиск по полям: Разделение на основные (названия, категории) и дополнительные (описания, характеристики).

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

Поиск по частям фраз: Например, «детский стул» → «стул детский», «детский стол и стул».

Сложные запросы: Поиск по нескольким параметрам одновременно (например, «стул деревянный дешевый»).

3. Обогащение функционала

Перевод слов: Если сайт многоязычный, поиск должен учитывать перевод (например, «chair» = «стул»).

Популярные запросы: Отображение популярных и трендовых запросов.

Подсказки (автокомплит): Предложение вариантов поиска во время ввода.

История запросов: Возможность повторить предыдущие поиски.

Семантический поиск: Понимание контекста, даже если запрос некорректен (например, «стол круглый белый»).

Как выбрать правильное решение поиска

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

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

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

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

Таблица

В формате Google Таблицы: https://docs.google.com/spreadsheets/d/1diUu2S1K1l3vBBoYsmDVYI6eH4FJrBLCEQv_WrWMt1s/edit?usp=sharing

Запрос	Что выводится сейчас	Что должно выводиться (ожидаемый результат)	Ошибка, которая не обрабатывается
молоко	Ссылка на результаты поиска	Товары с «молоко», включая «молоко 1%», «кефир» и «йогурт». Все виды хлеба, включая «багет», «батон», «нарезка».	Не учитываются синонимы (например, «кефир», «йогурт»).
хлеб	Ссылка на результаты поиска	Все виды хлеба, включая «багет», «батон», «нарезка»	Нет обработки синонимов (например, «батон»).
mlk	Ссылка на результаты поиска	Результаты с «молоко» (транслитерация «mlk» → «молоко»).	Транслит не обрабатывается.
яблк	Ссылка на результаты поиска	Результаты для «яблоко» (исправление опечатки).	Опечатка не обрабатывается.
шокоадный	Ссылка на результаты поиска	Товары с «шоколад», «батончик», включая «сникерс», «твикс».	Поиск работает строго по фразе, не учитывает раздельный поиск слов.
молоко детское	Ссылка на результаты поиска	Товары с молоком, включая категорию «детское».	Нет фильтрации по категориям (например, «детское молоко»).
1л молока	Ссылка на результаты поиска	«Молоко 1 литр», «кефир 1 литр».	Нет обработки числовых значений.
яблоки зеленые	Ссылка на результаты поиска	Зеленые яблоки, включая категории «фрукты», «яблоки».	Не работает поиск по ключевым словам с уточнением цвета.

Инструкция для заполнения:

Запрос: Впишите поисковый запрос, который пользователь может ввести.
Что выводится сейчас: Скопируйте ссылку на текущие результаты поиска (или опишите, что выводится).
Что должно выводиться: Опишите, как вы ожидаете, что результаты должны быть отображены.
Ошибка, которая не обрабатывается: Укажите, какая ошибка присутствует в работе поиска (например, отсутствие фильтрации, неработающие синонимы, игнорирование опечаток и т. д.).

Этот формат поможет четко определить проблемные места и области для улучшения.

Заключение

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

Вспоминая пример с Wrike, где поиск осуществлялся по названиям, содержанию описаний проектов и задач, включая комментарии. А в Яндекс.Трекере, к примеру, общий поиск работает только по названиям задач — крайне неудобно.

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

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

Человек, который контролирует 40% интернета. Восхождение open-source империи

Thu, 12 Dec 2024 08:23:18 +0300

В начале 2000-х 19-летний разработчик Мэтт Муленвег форкнул систему управления контентом b2/cafelog, добавив в нее функции, которых, по его мнению, не хватало.

К октябрю 2009 года проект, получивший название WordPress, стал самой популярной open-source CMS в интернете, сегодня обеспечивающей работу более 810 миллионов веб-сайтов по всему миру.

Практически любой — от New York Times до Нила Пателя — использует WordPress для создания блога, интернет-магазина, корпоративного сайта или портфолио. Система бесплатна, легка в использовании, оптимизирована для поисковых систем и изначально была открыта для любых модификаций. Точнее, была открыта до определенного момента.

Закулисье открытого проекта: конфликт с WP Engine

В сентябре 2024 года произошли драматические события. Муленвег публично раскритиковал хостинг-компанию WP Engine, назвав ее «раком» WordPress из-за минимального вклада в развитие открытого проекта и неправомерного использования бренда. В ответ WP Engine направила Муленвегу письмо с требованием прекратить подобные высказывания.

Реакция Муленвега была молниеносной: он заблокировал WP Engine, в результате чего клиенты хостинг-провайдера лишились возможности обновлять свои веб-сайты. Спустя несколько недель Муленвег присвоил плагин ACF, созданный WP Engine, используя сомнительную юридическую формулировку о потенциальном риске для сообщества.

Конфликт между Муленвегом и WP Engine продолжается и сейчас, постепенно перемещаясь в судебную плоскость. Это противостояние стало переломным моментом в мире открытого программного обеспечения — теперь будет период до и после этого конфликта.

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

WordPress охватывает более 810 миллионов веб-сайтов, но существование всей этой экосистемы полностью зависит от одного человека — Мэтта Муленвега. Слишком много власти для одного человека? Без сомнения, да.

Империя Муленвега

Существует очевидный конфликт интересов. Несмотря на то, что WordPress распространяется бесплатно, Муленвег заработал на нем миллиарды долларов. Он владеет компанией Automattic, которой принадлежат WordPress.com и Pressable — два хостинг-провайдера для WordPress, популярный плагин Jetpack, WooCommerce и множество других проектов.

Нападая на WP Engine, Муленвег фактически атакует прямого конкурента Automattic, компании, зарабатывающей полмиллиарда долларов ежегодно благодаря WordPress.

Сообщество

Никто не понимает мотивов Муленвега. Многие уважаемые представители open-source сообщества, включая Дэвида Хайнемейера Ханссона, призывали его к деэскалации конфликта и переговорам вместо стремления довести WP Engine до банкротства.

В ответ Муленвег написал письмо, полное оскорблений, высмеивая Ханссона за его неспособность капитализировать собственные успешные open-source проекты.

Что на самом деле движет Муленвегом? Он — владелец и CEO компании с годовым оборотом 500 миллионов долларов, создавший один из самых успешных веб-проектов. Действия последних трех месяцев заставляют многих задуматься о его истинных намерениях.

Open-source

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

Это не только considerably подорвало репутацию WordPress, но и поставило под сомнение саму концепцию открытого программного обеспечения.

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

Я не стану защищать WP Engine, но действия Муленвега представляются совершенно несоразмерными предполагаемым нарушениям.

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

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

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

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

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

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

Айсберг надежд: как фреймворк обещает всё

Tue, 10 Dec 2024 08:23:18 +0300

За последний год в общении с клиентами все чаще возникает один и тот же сценарий: приходит компания с проектом b2b или b2c портала, который неплохо ложиться поверх Битрикс Управление сайтом, но в процессе общения нас просят, а давайте посчитаем стоимость проекта на коробке БУС и на фреймворке.

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

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

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

Стоит отметить, что разговор обычно происходит в плоскости бэкенда, причем неважно, идет ли речь о Django, Laravel или Ruby on Rails. Дальше диалог развивается по одному из двух сценариев: либо мы начинаем считать дополнительную смету.

Альтернативное решение почти всегда в 1,5 — 2,5 раза дороже, параллельно пытаемся объяснить потенциальные подводные камни такого решения.

Framework vs cms

В нашей практике речь чаще всего идет о проектах в e-commerce, где функционал практически идентичен. Для несложных проектов — каталог, форма заявки, интеграция с CRM — фреймворк действительно может быть оптимальным выбором. Однако ситуация меняется, когда планируется расширение функционала, уже имеющегося в готовом решении: скидки, товары с характеристиками, интеграции с логистикой, 1С, платежными системами.
Здесь возникают принципиальные вопросы. Во-первых, весь этот функционал придется разрабатывать с нуля или почти с нуля. Во-вторых, и это самое важное — нет гарантии, что новый код будет написан оптимально и работать быстрее, чем в коробочном решении.

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

Подводные камни

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

Наша формула выбора предельно проста: если текущий и планируемый функционал проекта на 70% укладывается в возможности коробочного решения и не требует кардинальной ломки его логики — используем готовое решение. Это особенно актуально для проектов с нестандартной логикой, например, маркетплейсов с разделением заказа по поставщикам.

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

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

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

Резервное копирование: двести тысяч единиц уже готовы

Mon, 02 Dec 2024 09:32:36 +0300

Хочу поговорить о теме бэкапов и резервного копирования проектов. Так сложилось, что я учился на специальности «Комплексная защита объектов информатизации». Сейчас эта специальности нет существует, точнее есть, но в несколько в ином виде.

Двести тысяч единиц уже готовы, еще миллион на подходе

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

Резервируй всё: каналы, серверы, мощности, бэкапы — словом, всё, что может отказать и имеет значимость для бизнеса.

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

Много / мало?

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

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

Целостность

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

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

Период хранения?

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

Все просто

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

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

Как сделать авторизацию на сайте: Новая надежда

Fri, 29 Nov 2024 11:14:24 +0300

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

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

Терминологический экскурс: Аутентификация и авторизация

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

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

Авторизация — это процесс определения прав и уровня доступа пользователя к ресурсам системы после успешной аутентификации. Она отвечает на вопрос «что пользователь может делать?» и позволяет управлять доступом к данным, функциям или файлам в зависимости от роли, настроек или других условий.

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

Процесс входа на сайт обычно включает два этапа — аутентификацию и авторизацию, поэтому его правильно называть аутентификацией с авторизацией или просто процессом входа (login process)

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

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

Эволюция входа: Исторический экскурс

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

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

Безопасность vs Удобство

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

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

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

Альтернативные методы входа

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

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

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

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

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

Возвращение email: Новая надежда

Король вернулся. Email снова на коне. Организация максимально простая — одно окно ввода email, никакой регистрации, восстановления доступа не требуется. Если email нет — создаем в базе, если есть — высылаем пароль.
Шаблон email в этом случае примитивен, но имеет два варианта. Выслать контрольную строку с авторизацией или код для входа. Метод со ссылкой еще более простой, так как в интерфейсе нам нужно только окно ввода email и все.

Лично мне безумно удобно пользоваться. Почта всегда под рукой на телефоне. Кто скажет иначе — я возражу, что сейчас невозможно почти пользоваться телефоном, не введя email и на Apple, и на Android.
Ты уже наверняка сталкивался с данным подходом, его например внедрила figma.

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

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

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

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

Вход через социальные сети: Еще один вариант

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

Сравнительная таблица

1 — минимальная оценка (сложно, неудобно, редко используется).
5 — максимальная оценка (очень удобно, легко внедрить, популярно).

Метод	Удобство	Простота реализации	Безопасность	Популярность
Логин/email + пароль	4	5	3	5
Через телефон (звонок/SMS)	4	4	4	4
Через социальные сети	5	3	3	5
Одноразовый код по email	4	5	4	4
QR-код	4	3	4	3
Биометрия	5	2	5	3
Через мессенджеры	3	4	4	2
Приложения-аутентификаторы	4	4	5	4
Без паролей (passwordless)	5	4	5	4
Сертификаты или токены	3	2	5	2

Итого

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

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

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

Saas vs Self-Hosted: Что выбрать?

Sun, 08 Sep 2024 16:40:46 +0300

Сегодня хочу поделиться с вами своими мыслями и опытом по вопросу выбора SaaS или self-hosted решения? Я прошел через этот выбор не раз и не два, и хочу рассказать вам, какие подводные камни встречаются на этом пути.

Сразу хочу заметить, что выбор очень сильно зависит от размеров компании, команд, стадии развития и других факторов. Если вы маленький стартап или небольшой бизнес, то SaaS вероятно будет лучшим выбором. А если вы крупная корпорация, то выбор по сути уже не стоит — вам, скорее всего, понадобится комбинация обоих подходов с уклоном в self-hosted решения.

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

Для начала, давайте разберемся, о чем вообще речь. SaaS (Software as a Service) — это когда вы платите за подписку на готовое облачное решение. Вроде как удобно: заплатил — и пользуйся. Self-hosted, с другой стороны, это когда вы берете софт под свой контроль, устанавливаете его на свои сервера и сами им управляете. Звучит сложнее, но у этого подхода есть свои преимущества.

У себя в компании мы взяли курс на self-hosted решения и стараемся отказываться от SaaS по мере возможностей, но, тем не менее, эти решения все еще занимают значительную часть используемого нами ПО. Почему так?

Преимущества SaaS, или почему это так соблазнительно

Быстрый старт.

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

Экономия на старте.

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

Масштабируемость

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

Автоматические обновления

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

Работа отовсюду

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

Поддержка 24/7

Когда у тебя нет собственного IT подразделения (а у многих малых бизнесов его нет), техподдержка SaaS-сервисов — это просто спасение.

Но не все так радужно в мире SaaS. Есть и обратная сторона медали.

Недостатки SaaS, или почему мы начали смотреть в сторону self-hosted

Ограниченная кастомизация

Бывало, сидишь и думаешь: «Вот бы в этом отчете кнопка была здесь, а это поле — вон там». Но нет, в SaaS ты пользуешься тем, что дают. Иногда это реально бесит.

Зависимость от интернета

Однажды у нас отключили интернет на полдня. Все, приехали — работа встала. С self-hosted такого бы не случилось.

Безопасность данных

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

Неожиданные ограничения

Помню, как мы уперлись в лимит хранилища на одном SaaS-сервисе. Чтобы его увеличить, пришлось переходить на тариф, который был нам вообще не нужен по функционалу. Деньги на ветер!

Сложности с миграцией

Решили мы как-то сменить одно SaaS-решение на другое. Боже, какой это был ад с переносом данных! Никогда больше.

Преимущества self-hosted, или почему мы все больше смотрим в эту сторону

Полный контроль

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

Кастомизация по полной

Хочешь добавить новую фичу? Вперед! С self-hosted решениями ты можешь подкрутить систему под себя как душе угодно.

Независимость

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

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

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

Но и у self-hosted есть свои минусы:

Высокие начальные затраты Серверы, лицензии, настройка — все это стоит денег. И немалых.
Нужны специалисты Без толкового айтишника тут никуда. А хорошие спецы стоят дорого.
Ответственность за все Обновления, безопасность, бэкапы — все на твоих плечах. Иногда это реально выматывает.
Сложности с масштабированием Нужно больше мощностей? Готовься к новым затратам и головной боли с настройкой.

Так что же выбрать?

Честно? Нет универсального ответа. В нашей компании мы используем микс из SaaS и self-hosted решений. Для каких-то задач удобнее и выгоднее SaaS, для других — self-hosted.

Вот несколько советов из моего опыта:

Рассматривайте варианты. Есть масса бесплатных self-hoste решений, да возможно, они хуже saas, но их можно дорабатывать
Интеграции. Перед внедрением, оцените насколько новый сервис интегрируем с текущими.
Комьюнити. Бери решение где шире распространение, если возникнут сложности — вы сможете найти единомышленников.
Стек и API. Смотрите свой стек или api должно быть открытым со всеми возможностями.
Оцените свой бюджет. Если денег в обрез, начните с SaaS.
Подумайте о безопасности. Работаете с чувствительными данными? Лучше self-hosted.
Оцените свои технические возможности. Нет айтишников? SaaS будет проще.
Подумайте о будущем. Планируете быстрый рост? SaaS легче масштабировать.
Проанализируйте свои бизнес-процессы. Нужна глубокая кастомизация? Смотрите в сторону self-hosted.

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

Как работает капча с галочкой?

Sun, 25 Aug 2024 15:53:27 +0300

Почему роботы не могут просто нажать кнопку «Я не робот»?

Привет, друзья! Сегодня поговорим о том, с чем сталкивается каждый из нас в интернете — о загадочных галочках «Я не робот». Казалось бы, что может быть проще? Но не всё так очевидно, как кажется на первый взгляд. Давайте разберемся, почему эти маленькие квадратики так важны и как они на самом деле работают.

reCAPTCHA: эволюция защиты от ботов

Помните старые добрые времена, когда нас заставляли вводить искаженный текст, чтобы доказать, что мы не роботы? Эти головоломки назывались CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart). Звучит как название рок-группы, правда?

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

Почему роботы не могут просто нажать на галочку?

Спойлер: могут! Дело в том, что современные боты настолько продвинуты, что могут делать практически всё, что и человек в интернете. Они играют в Runescape, управляют целыми фермами аккаунтов в соцсетях и, да, могут нажимать на любые кнопки. Но есть нюанс...

Секрет в том, как мы нажимаем

Главная фишка reCAPTCHA не в том, что вы нажимаете, а в том, как вы это делаете. Вот несколько хитростей:

Скорость реакции: Боты слишком быстры и эффективны. Мы, люди, медлительны и непредсказуемы. Система ищет именно эту человеческую «неэффективность».
Траектория движения мыши: У роботов она идеально прямая, у нас — как пьяный матрос на палубе в шторм. Каждое движение уникально и непредсказуемо.
Паузы и колебания: Мы можем остановиться, почесать нос, отвлечься на кота. Боты так не делают (пока что). Эти маленькие перерывы — признак человечности.
Использование тачпада: Если вы на ноутбуке, ваши шансы пройти тест взлетают до небес благодаря хаотичности движений. Тачпад — лучший друг reCAPTCHA!

Визуальные головоломки: когда галочки недостаточно

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

Cloudflare писали, даже самый продвинутый ИИ все еще испытывает трудности с выделением конкретных объектов из загроможденного или размытого изображения. А вот для нас, людей, это обычно не проблема. Так что когда вас просят отличить велосипеды от мопедов на размытых картинках, знайте — вы участвуете в тесте, который современный ИИ пока не может пройти.

Невидимая слежка: когда CAPTCHA становится шпионом

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

Google даже разработал систему reCAPTCHA Enterprise, которая оценивает вашу «человечность» по шкале. Прямо как серия «Чёрного зеркала», только в реальности! Эта система использует легкодоступную информацию, чтобы определить, человек вы или бот.

Плюсы и минусы невидимой CAPTCHA

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

Что дальше?

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

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

Итог

Так что в следующий раз, когда будете ставить галочку «Я не робот», помните: вас проверяют не на способность нажать на квадратик, а на вашу уникальную человеческую неэффективность и непредсказуемость. Разве это не прекрасно?

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

P.S. А вы знали, что название CAPTCHA — это на самом деле аббревиатура? Полностью оно расшифровывается как «Completely Automated Public Turing test to tell Computers and Humans Apart». Попробуйте сказать это три раза подряд быстро — отличный тест на человечность!