ГлоссарийРазработка
Термины веб- и мобильной разработки простыми словами
Определения терминов разработки, которые возникают, когда бизнес создаёт, обновляет или принимает от другого подрядчика сайт, приложение или внутреннюю систему. Каждый термин ведёт на услугу или статью, где мы разбираем его подробно.
Платформы, языки и фреймворки
На чём построен сайт или приложение и что каждый выбор значит для найма, обновлений и бюджета.
- Laravel
Laravel это PHP-фреймворк с открытым кодом для веб-приложений, клиентских порталов, бэк-офисов и интернет-магазинов с собственной бизнес-логикой. Новая мажорная версия выходит раз в год, исправления ошибок для неё выпускают 18 месяцев, а исправления безопасности два года (Laravel, октябрь 2026). Мы выбираем Laravel, когда цены, интеграции или процессы у бизнеса свои и готовая платформа потребовала бы постоянных обходных решений.
Подробнее: Сайты на Laravel
- PHP
PHP это серверный язык программирования, на котором работает внутренняя часть сайта: он собирает страницы, обрабатывает формы и обращается к базе данных. На PHP работают 70,2% сайтов с известным серверным языком (W3Techs, сентябрь 2026), в том числе WordPress и Laravel. У каждой ветки PHP свой срок поддержки: 8.2 перестаёт получать исправления безопасности 31 декабря 2026 года, а 8.4 поддерживается до 31 декабря 2028 года.
Подробнее: Обновление старого сайта на Laravel или PHP в 2026 году
- Symfony
Symfony это PHP-фреймворк с открытым кодом, собранный из переиспользуемых компонентов; его выбирают для крупных долгоживущих приложений, над одним кодом которых работают несколько команд. Он даёт контроль и архитектурную свободу на годы ценой более высоких затрат на старте, тогда как Laravel жертвует частью этой свободы ради скорости выхода на рынок. Symfony пользуются около 23% PHP-разработчиков против примерно 64% у Laravel (JetBrains, 2025), а для работы с базой данных в нём обычно применяют Doctrine.
Подробнее: Laravel или Symfony: Самое дорогое технологическое решение, которое вы так и не приняли
- CMS (система управления сайтом)
CMS (content management system) это система, в которой команда редактирует страницы, каталог, медиафайлы и формы сайта без программирования: WordPress, Shopify, Webflow или собственная админка на фреймворке. Выбор должен следовать за тем, как работает бизнес: CMS с открытым кодом, которая отлично подошла на старте, может перестать справляться, когда растут каталог, логика фильтров и интеграции. Верный признак этого момента: маркетинговые кампании начинают придумывать под ограничения CMS.
Подробнее: Когда бизнес перерастает WordPress?
- WordPress
WordPress это самая распространённая CMS с открытым кодом: на ней работают 39,5% всех сайтов и 58,3% сайтов с известной CMS (W3Techs, октябрь 2026). Со страницами, новостями и портфолио она справляется хорошо; сложности начинаются через годы, когда бизнес-логику несут плагины и каждое плановое обновление вызывает тревогу. Популярность делает её и мишенью: Patchstack насчитал 11 334 новые уязвимости WordPress за 2025 год.
Подробнее: Когда бизнес перерастает WordPress?
- Headless CMS
Headless CMS это система управления контентом, которая хранит и редактирует материалы, но сама не выводит страницы: она передаёт контент через API во фронтенд, построенный отдельно, например на Next.js. Так один источник контента питает сайт, приложение и другие каналы, а фронтенд можно менять без переноса контента. Цена такого подхода: две системы в разработке и поддержке вместо одной, поэтому он оправдан при нескольких каналах или сложном фронтенде.
Подробнее: AI веб-дизайн и AI видеомонтаж для фронтенда | PERETZ.agency
- Конструктор сайтов
Конструктор сайтов это облачный сервис вроде Wix, Squarespace или Webflow, где сайт собирают из готовых блоков за ежемесячную плату, обычно от $20 до $80. Он хорошо подходит для постоянного каталога, простого бронирования, нескольких страниц услуг и базовой электронной коммерции. Практичная проверка: если задачу сайта можно описать языком самого конструктора, он подойдёт. Когда нужны интеграции и своя логика, плагины и обходные решения постепенно превращаются в технический долг.
Подробнее: Кастомный сайт против конструктора: что выбрать бизнесу?
- Технологический стек
Технологический стек это набор языков, фреймворков, баз данных и сервисов, на которых построена система, например Vue или React во фронтенде, Laravel или Node.js в бэкенде, PostgreSQL, Redis, Docker и Cloudflare. От стека зависят найм, хостинг и то, какие интеграции даются легко, а какие трудно. Он описывает, чем пользуется система, но не то, чем владеет бизнес: код, данные и аккаунты это отдельный вопрос.
Подробнее: Чему построение систем учит о их покупке
- Фронтенд и бэкенд
Фронтенд это часть сайта или приложения, которая работает в браузере посетителя: вёрстка, CSS, JavaScript и фреймворки вроде React или Vue. Бэкенд работает на сервере и отвечает за логику, базу данных и интеграции; его пишут, например, на Laravel, .NET или Node.js. Стареют они по отдельности, поэтому сайт может казаться устаревшим из-за старого фронтенда или CMS, хотя привычный пользователям интерфейс стоит сохранить.
Подробнее: Нужен ли сайту редизайн? Начните с юзабилити-аудита
- TypeScript
TypeScript это JavaScript с типами: в коде указано, какие данные ожидает каждая переменная и функция, и многие ошибки ловятся ещё до запуска. Он особенно важен, когда JavaScript-продукт вырос настолько, что менять его стало рискованно; обычный путь здесь постепенный перевод, файл за файлом, а не переписывание. Проекты на TypeScript в строгом режиме входят в число задач, под которые мы подбираем разработчиков в команды клиентов.
Подробнее: Нанять JavaScript-разработчика
- Node.js
Node.js это среда, которая запускает JavaScript на сервере, так что продукт может использовать один язык от интерфейса до API и базы данных. На нём делают всё: от простого API на Express до событийных сервисов с очередями сообщений и WebSocket, а также serverless-функции на AWS Lambda, Google Cloud или Vercel. Full-stack JavaScript-разработчик проводит одну функцию через все эти слои; наши специалисты подключаются к командам клиентов по ставке от $45 до $65 в час.
Подробнее: Нанять Node.js-разработчика
- React
React это библиотека JavaScript с открытым кодом для создания интерфейсов из переиспользуемых компонентов, её развивает Meta. Реальные проекты на React бывают очень разными: от кода на Next.js с серверными компонентами и строгим TypeScript до старых одностраничных приложений на классовых компонентах. Перевод такого продукта на серверные компоненты или TypeScript это отдельная миграция, и вести её лучше тому, кто уже делал это раньше.
Подробнее: Нанять React-разработчика
- Next.js
Next.js это фреймворк на основе React, который добавляет серверный рендеринг, маршрутизацию и загрузку данных, так что страницы приходят готовым HTML, который быстро показывается и индексируется. App Router и серверные компоненты позволяют решать, что выполняется на сервере, а что в браузере. В многослойной архитектуре витрина на Next.js может отвечать за рендеринг, модульный контент и оформление заказа, а бизнес-правилами владеет отдельный бэкенд, например ядро на Laravel.
Подробнее: Нанять React-разработчика
- Vue.js
Vue.js это JavaScript-фреймворк с открытым кодом для интерактивных интерфейсов, который часто работает в паре с Laravel на бэкенде. Nuxt добавляет серверный рендеринг для страниц на Vue, которые должны находиться в поиске, а Inertia.js позволяет поставить админку на Vue прямо на ядро Laravel без отдельного API. Продуктам, которые ещё работают на Vue 2, нужен переход на Vue 3, и лучше проводить его, не останавливая выпуск новых функций.
Подробнее: Нанять Vue.js-разработчика
- Angular
Angular это полноценный фронтенд-фреймворк от Google, написанный на TypeScript и применяемый в основном для крупных бизнес-приложений и внутренних систем. Современный Angular строится на standalone-компонентах и сигналах, при этом многие компании всё ещё используют в ежедневной работе приложения на Angular 8 и даже на его предшественнике AngularJS. Для поддержки и обновления таких приложений нужны разработчики, знающие оба поколения, а не только последнее.
Подробнее: Нанять Angular-разработчика
- Python и Django
Python это универсальный язык программирования, а Django его зрелый веб-фреймворк со встроенной админкой, ORM и авторизацией; FastAPI более новый выбор для быстрых асинхронных API. Python часто живёт и в скриптах, которые связывают CRM, ERP, магазин и бухгалтерию. Таким скриптам нужно то же, что любому рабочему коду: ответственный, тесты и мониторинг.
Подробнее: Нанять Python-разработчика
- Серверный рендеринг (SSR)
Серверный рендеринг (server-side rendering, SSR) означает, что сервер собирает полный HTML страницы до отправки, поэтому текст, ссылки и заголовки есть в ней ещё до запуска JavaScript. Поисковые системы и ИИ-краулеры надёжно читают такие страницы, а посетители раньше видят содержимое, особенно на медленных телефонах. Для React и Vue его дают фреймворки Next.js и Nuxt. На нашем сайте оглавление статей рисуется на сервере, поэтому оно больше не сдвигает текст вниз после первой отрисовки.
Подробнее: 3D на живом сайте: наш эксперимент с three.js и что увидел Google
- three.js
three.js это JavaScript-библиотека с открытым кодом, которая рисует интерактивные 3D-сцены в браузере на основе WebGL. На ней строят просмотрщики товаров, конфигураторы и иммерсивные страницы брендов, но сцена тяжёлая, и загрузку нужно продумывать. Текст внутри 3D-холста для Google лишь пиксели, поэтому каждый заголовок и каждая ссылка должны оставаться обычным HTML вне его. На нашем сайте облегчённая загрузка 3D-сцен подняла оценку PageSpeed главной страницы на мобильных с 32 до 78.
Подробнее: 3D на живом сайте: наш эксперимент с three.js и что увидел Google
- WebGL
WebGL это браузерная технология, которая позволяет веб-странице рисовать 2D- и 3D-графику силами видеочипа устройства; на ней построены библиотеки вроде three.js. Если пригодного видеочипа нет, Chrome рисует WebGL программно на основном процессоре, а это медленно и может подвесить страницу. Аккуратный сайт проверяет рендерер до загрузки 3D-сцены и показывает таким устройствам тот же текст и те же ссылки в облегчённом виде.
Подробнее: 3D на живом сайте: наш эксперимент с three.js и что увидел Google
- jQuery и Bootstrap
jQuery это старая JavaScript-библиотека для работы с элементами страницы, а Bootstrap CSS-фреймворк с готовой сеткой и компонентами интерфейса; оба до сих пор лежат в основе многих бизнес-сайтов. Версии здесь важны: в любой сборке jQuery старше 3.5.0 есть задокументированная уязвимость межсайтового скриптинга, а Bootstrap 3 и 4, зависящие от jQuery, перестали поддерживаться в июле 2019 и декабре 2022 года. Обновить их одной строкой обычно не выйдет, потому что темы и скрипты написаны под старое поведение.
Подробнее: Большинству компаний нужен не новый сайт, а новая структура
Приложения, SaaS и бизнес-системы
Какое ПО бизнес заказывает, арендует или связывает между собой, от клиентских порталов до CRM и мобильных приложений.
- Веб-приложение (web application)
Веб-приложение это программа, которая работает в браузере и выполняет работу для пользователей, а не только показывает информацию: клиентский портал, система заказов или бронирования, внутренний инструмент или SaaS-продукт с аккаунтами, ролями и данными. В отличие от сайта, его строят вокруг ролей, прав доступа и интеграций. Наши веб-приложения стоят от $25 000, а крупные продукты делятся на этапы со своими сметами.
Подробнее: Разработка веб-приложений и SaaS
- Клиентский портал
Клиентский портал это веб-приложение, в котором клиенты, дилеры или участники входят в личный кабинет и видят только свои данные: заказы, документы, статус проекта, счета или запросы. Он заменяет переписку и таблицы одним местом, которому доверяют обе стороны. Главное в нём доступ: каждый аккаунт технически не должен дотягиваться до чужих данных, и это должны подтверждать автотесты. Так устроен и наш собственный портал: команда входит с двухфакторной аутентификацией, а встречи показываются в часовом поясе каждого участника.
Подробнее: Разработка веб-приложений и SaaS
- Админ-панель (бэк-офис)
Админ-панель, или бэк-офис, это внутренний интерфейс, в котором сотрудники управляют контентом, заказами, клиентами и другими данными сайта или приложения. В хорошей админке у каждой роли свой вид: менеджер, кладовщик и оптовый партнёр видят и меняют разное. От её удобства зависит, будет ли сайт актуальным: если добавление проекта или товара занимает целый вечер, обновления прекращаются через несколько месяцев.
Подробнее: Сайты на Laravel
- SaaS (программное обеспечение как услуга)
SaaS (software as a service) это программы, которые арендуют по подписке и которые поставщик сам запускает в облаке: CRM, бухгалтерский сервис, платформа электронной коммерции. SaaS подходит для стандартных процессов и быстро даёт команде рабочий инструмент, а заказное ПО нужно там, где задача слишком специфична или стратегична для аренды; часто лучше всего работает сочетание. Прежде чем подписываться, стоит выяснить, какие данные там будут храниться, что произойдёт при смене цен или закрытии сервиса и сколько займёт переезд.
Подробнее: Софт должен подходить бизнесу
- Заказное программное обеспечение
Заказное программное обеспечение это ПО, спроектированное и созданное для одного бизнеса под его процессы, данные и правила, а не настроенное из готового продукта. Оно дороже на старте и требует постоянной поддержки, зато не берёт плату за каждого пользователя и делает ровно то, что нужно. Окупается оно, только если процесс даёт реальное преимущество и его можно чётко описать. Обычно бизнесу принадлежат логика, сценарии работы, структуры данных и интеграции, а хостинг, платежи, авторизация и ИИ-модели остаются арендованными сервисами.
Подробнее: Софт должен подходить бизнесу
- Коробочное ПО
Коробочное ПО это готовый продукт, который бизнес настраивает, а не разрабатывает: типовая CRM, ERP или платформа интернет-магазина. Начать с него дешевле и быстрее, но лицензии, дополнения, внедрение и доработки складываются в заметную сумму за три-пять лет. Разумный порядок такой: выбрать платформу, понять, насколько далеко заходит настройка, найти настоящие пробелы и только потом решать, оправдывают ли они заказную разработку.
Подробнее: Какая CRM подходит вашему бизнесу? Практический гид по выбору CRM-системы
- Salesforce
Salesforce это облачная CRM-платформа для продаж, сервиса и маркетинга, частый выбор по умолчанию в США. Но не всегда правильный: в США цены начинаются от $100 за пользователя в месяц, а глубокая доработка обычно требует сертифицированного партнёра. Если платформа подходит не идеально, менять её не единственный путь: собственный интеграционный слой может связать её с другими системами, например синхронизировать заказы в обе стороны со складской системой.
Подробнее: Какая CRM подходит вашему бизнесу? Практический гид по выбору CRM-системы
- HubSpot
HubSpot это облачная CRM с инструментами маркетинга, продаж и сервиса, которую часто выбирают как более лёгкую альтернативу Salesforce. Она подходит, например, компании на 20-50 человек со своим, но не слишком сложным процессом продаж. Бесплатный тариф, как и у Zoho, позволяет небольшой команде проверить процесс на практике, прежде чем платить за больший объём или прийти к выводу, что нужна собственная разработка.
Подробнее: Какая CRM подходит вашему бизнесу? Практический гид по выбору CRM-системы
- Odoo
Odoo это модульная ERP-система, которая объединяет продажи, закупки, склад, бухгалтерию и другие функции. Как Dynamics 365 Business Central, NetSuite или SAP Business One, она подходит компаниям, у которых циклы закупки, хранения и продажи близки к стандартным. Главный риск в том, что бизнесу приходится подстраиваться под модель данных поставщика. Тарифы стоит изучить внимательно: в прайсе Odoo внешний API, Odoo Studio, работа с несколькими компаниями и внешний хостинг указаны только в тарифе Custom.
Подробнее: Разработка ERP
- Microsoft Dynamics 365
Microsoft Dynamics 365 это семейство CRM- и ERP-приложений Microsoft, которое охватывает всё от продаж и сервиса до финансов и цепочки поставок. Поскольку оно связано с Microsoft 365, Azure и Power Platform, его выбор становится архитектурным решением, а не просто выбором CRM. Коробочная ERP из этого семейства, Business Central, оплачивается за пользователя в месяц при годовом контракте, лицензия Team Members стоит $8.
Подробнее: Какая CRM подходит вашему бизнесу? Практический гид по выбору CRM-системы
- 1С
1С это российское семейство учётных и бизнес-программ, которое до сих пор встроено в работу многих украинских компаний. Украина ввела против него санкции: для госсектора с 2017 года, против разработчика с 2024 года, а сама программа входит в открытый перечень ПО, запрещённого для госорганов и критической инфраструктуры. Уход с 1С это проект миграции данных: справочники, остатки и историю нужно очистить и перенести в новую систему, а старые установки могут быть привязаны к лицензиям, которые новый владелец не может просто унаследовать.
Подробнее: CRM и ERP: в чём разница и какая система нужна вашему бизнесу
- Автоматизация бизнес-процессов
Автоматизация бизнес-процессов это замена повторяющейся ручной работы, например согласований, уведомлений, обработки документов и переноса данных между системами, правилами внутри существующих инструментов и интеграциями между ними. Заказное ПО нужно только там, где не подходит ни одна платформа. Начинать лучше с одного процесса, который отнимает больше всего времени или порождает больше всего ошибок; такой процесс часто удаётся наладить за три-четыре недели. В сфере профессиональных услуг это обычно приём клиентов, документы, расписание или отчётность.
Подробнее: Диджитализация бизнеса
- Прогрессивное веб-приложение (PWA)
Прогрессивное веб-приложение (progressive web app, PWA) это сайт, который ведёт себя как приложение: его можно добавить на главный экран, просмотренные страницы открываются без интернета благодаря service worker, а ещё он умеет присылать push-уведомления. Ему не нужна проверка в магазине приложений и отдельный код для iOS и Android, хотя iOS ограничивает часть возможностей сильнее, чем Android. Многим компаниям PWA хватает до появления нативного приложения или вместо него. Наш собственный сайт тоже PWA.
Подробнее: Когда бизнесу реально нужно мобильное приложение?
- Push-уведомления
Push-уведомления это короткие сообщения, которые приложение или сайт отправляет на устройство пользователя, даже когда оно закрыто, чтобы вернуть человека новостью, статусом заказа или новым материалом. В нативных приложениях это сильный канал, в PWA его возможности зависят от платформы, а в обычном вебе они ограничены. Отключить уведомления можно одним нажатием, поэтому работают они только тогда, когда каждое сообщение действительно полезно получателю.
Подробнее: Когда бизнесу реально нужно мобильное приложение?
- Нативное мобильное приложение
Нативное мобильное приложение это приложение для iOS или Android, созданное собственными языками и инструментами платформы, например Swift или Kotlin, и распространяемое через App Store и Google Play. Оно оправдывает затраты, когда продукту нужны геолокация в фоне, глубокая работа с камерой или AR, работа без сети, биометрия в основном сценарии или тяжёлые вычисления на устройстве. Apple и Google регулярно обновляют свои системы, поэтому нативному приложению нужна постоянная поддержка, а не только бюджет на запуск.
Подробнее: Когда бизнесу реально нужно мобильное приложение?
- Кроссплатформенное приложение (Flutter)
Кроссплатформенное приложение это мобильное приложение, которое пишут один раз, например на Flutter, и выпускают из одного кода и для iOS, и для Android. По сравнению с двумя нативными приложениями разработка короче, но платформенные доработки редко исчезают полностью. Один Flutter-разработчик может вести оба магазина приложений. Наши мобильные приложения стоят от $30 000, а разработчики на Flutter, Swift или Kotlin подключаются к команде клиента по ставке от $45 до $65 в час.
Подробнее: Разработка приложений
- Модерация в App Store
Модерация в App Store это проверка Apple каждого нового приложения и каждого обновления перед публикацией; в Google Play действует похожая проверка. Она длится от нескольких часов до нескольких дней, и обновление могут отклонить по причинам, не связанным с тем, работает ли приложение, чаще всего из-за правил и требований, на которых спотыкаются новые команды, поэтому в планах релиза для неё нужен запас. Кто контролирует аккаунты разработчика, сертификаты подписи и резервные почты, тот решает, выйдет ли обновление вообще, поэтому этот контроль стоит выяснить заранее.
Подробнее: Когда бизнесу реально нужно мобильное приложение?
- Backend for frontend (BFF)
Backend for frontend (BFF) это серверный слой, созданный под один конкретный клиент, обычно мобильное приложение: он собирает данные из CRM, ERP, магазина и других систем и отдаёт ровно то, что нужно экранам приложения. Так приложение остаётся простым, а внутренние системы защищены от прямых обращений. Большая часть сложности и стоимости бизнес-приложения приходится именно на этот слой и его интеграции, а не на экраны, которые видит пользователь.
Подробнее: Когда бизнесу реально нужно мобильное приложение?
Архитектура, данные и интеграции
Как устроены системы, какая из них владеет данными и как информация движется между ними.
- Цифровая архитектура
Цифровая архитектура это то, как системы компании связаны между собой: какая система владеет какими данными, какая служит источником истины, как движется информация и что происходит при сбое. Выбор технологий лишь воплощает эти ответы. Обычно архитектура охватывает несколько слоёв: клиентский опыт, приложения, доменные системы, данные и интеграции, инфраструктуру. Хорошая архитектура изолирует изменения, так что замена CRM не тянет за собой переписывание авторизации, а структуру, не совпадающую с бизнесом, никакой оптимизацией под него не подогнать.
Подробнее: Цифровая архитектура: как построить систему, что растёт вместе с бизнесом
- Бизнес-логика
Бизнес-логика это правила, по которым работает бизнес, записанные в программу: как считаются цены и скидки, как собирается коммерческое предложение, кто что согласует, как применяется налог на каждом рынке. Это та часть системы, которая действительно уникальна для компании. Когда модель ценообразования или процесс расчёта перестают укладываться в плагин, заказная система уже строится, только внутри неподходящих ограничений. Недокументированная логика замедляет каждое изменение и может выдавать правдоподобные, но неверные цифры.
Подробнее: Когда бизнес перерастает WordPress?
- Доменная модель
Доменная модель это описание в коде собственных объектов и правил бизнеса: товаров и их характеристик, цен по рынкам, заказов, клиентов, налоговой логики, цены по запросу. Именно она делает так, что программа подстраивается под бизнес, а не наоборот. В электронной коммерции модель обычно делится на домены: каталог, остатки, продажи, клиенты, маркетинг, контент и операции, у каждого из которых чёткие границы, чтобы каждая область могла меняться в своём темпе.
Подробнее: Софт должен подходить бизнесу
- Модульная архитектура
Модульная архитектура это подход, при котором программы и сайты собирают из независимых переиспользуемых модулей, бизнес-объектов и блоков интерфейса, а не делают единым неразделимым целым. Тогда новый рынок, кампания или сценарий для клиента собираются из существующих частей, без переделки сайта. Обратная ошибка это один гигантский заказной монолит; здравый подход берёт готовые компоненты там, где их достаточно, и создаёт свои только там, где они дают реальное отличие.
Подробнее: Как мы проектируем e-commerce: от объектов к опыту
- Сервисный слой
Сервисный слой это часть приложения, где живёт бизнес-логика: отдельные классы сервисов или действий, отделённые от контроллеров, форм и запросов к базе данных. Валидация уходит в классы запросов, бизнес-правила в сервисы, которые можно тестировать отдельно, а контроллеры только координируют работу. Контроллер на 400 строк, который одновременно проверяет, считает, запрашивает и форматирует, это риск для бизнеса: ни одно правило в нём нельзя поменять, не задев остальные.
Подробнее: Что отличает премиальную сборку на Laravel или Symfony от просто рабочей
- Проектирование схемы базы данных
Проектирование схемы базы данных это планирование того, как хранятся данные: какие таблицы существуют, как они связаны, какие внешние ключи защищают целостность и какие индексы соответствуют запросам, которые реально выполняет приложение. Ошибки здесь дёшево предотвратить и дорого исправлять, потому что от структуры зависят весь код и все интеграции. Они ещё и хорошо прячутся при разработке: 500 тестовых записей обрабатываются быстро, а 500 000 настоящих выявляют каждый пропущенный индекс.
Подробнее: Что отличает премиальную сборку на Laravel или Symfony от просто рабочей
- Миграции базы данных
Миграции базы данных это пронумерованные скрипты, которые шаг за шагом меняют структуру базы: добавляют таблицу, колонку или индекс и позволяют откатить каждое изменение. Поскольку они хранятся в репозитории вместе с кодом, любую среду можно привести к одной и той же структуре, а у каждого изменения остаётся след. Аккуратная история миграций читается как журнал изменений продукта, а в запущенном проекте встречаются отредактированные старые миграции и ручные правки прямо в рабочей базе.
Подробнее: Что отличает премиальную сборку на Laravel или Symfony от просто рабочей
- ORM (объектно-реляционное отображение)
ORM (object-relational mapping) это слой, который связывает таблицы базы данных с объектами в коде, чтобы разработчики работали с заказами и клиентами, а не писали SQL для каждого запроса. В Laravel встроен Eloquent, в Symfony обычно используют Doctrine. ORM ускоряет разработку и делает доступ к данным единообразным, но может скрывать неэффективные запросы, например проблему N+1, пока не придут реальные объёмы данных.
Подробнее: Laravel или Symfony: Самое дорогое технологическое решение, которое вы так и не приняли
- Проблема N+1 запросов
Проблема N+1 запросов это ошибка производительности, при которой код загружает список одним запросом к базе, а потом делает ещё по запросу на каждый элемент, например один запрос на 100 заказов и ещё 100 на их клиентов. На тестовых данных она незаметна, а с реальными данными и одновременными пользователями страница резко замедляется. Обычно её исправляют заблаговременной загрузкой связанных данных (eager loading), и часто она встречается вместе с пропущенными индексами и повторными вычислениями.
Подробнее: Что отличает премиальную сборку на Laravel или Symfony от просто рабочей
- Очереди и фоновые задачи
Очереди и фоновые задачи позволяют приложению передать медленную и не срочную работу, например отправку писем, построение отчётов или обращение к ИИ-модели, отдельному обработчику и сразу ответить пользователю. Результат появляется чуть позже, а посетитель не ждёт и запрос не обрывается по таймауту. ИИ-запросы, которые длятся по несколько секунд, делают очередь почти обязательной. Правильная настройка также делает упавшие задачи видимыми и позволяет их повторить, чтобы ничего не терялось молча.
Подробнее: ИИ-проект застрял на старой системе? Сначала обновление, потом автоматизация
- Задачи по расписанию (cron)
Задачи по расписанию, или cron-задачи, это команды, которые сервер выполняет автоматически по графику: ночной импорт, сборка карты сайта, письма-напоминания, синхронизация данных. Никто не видит, как они выполняются, поэтому о них легко забыть. В недокументированной системе важные cron-задачи входят в число первых вещей, которые новому разработчику приходится искать, и они могут ломаться без сигнала; одну такую нашли запущенной из забытой папки на старом сервере. Список этих задач с ответственными должен быть в документации проекта.
Подробнее: Ваш сайт не падает в день, когда уходит разработчик. Он начинает падать на годы раньше.
- API
API (application programming interface) это заранее определённый способ, которым две системы обмениваются данными и командами, например магазин передаёт заказы в ERP. API не решает, кто владеет данными, что они означают, когда синхронизироваться и что делать при сбое синхронизации: это решения архитектуры. Современные системы открывают данные через API, чтобы ИИ-функция или партнёр запрашивали ровно то, что нужно, а старые полагаются на выгрузки и ночные скрипты. Каждый API это ещё и граница безопасности.
Подробнее: Цифровая архитектура: как построить систему, что растёт вместе с бизнесом
- Версионирование API
Версионирование API это выпуск изменений API в виде пронумерованных версий, чтобы подключённые системы продолжали работать на старой версии, пока их не обновят. Поставщики отключают старые версии по графику, так что у каждой интеграции есть свой срок обслуживания. Shopify, например, выпускает новую версию API каждый квартал и поддерживает каждую стабильную версию не меньше 12 месяцев, поэтому коннекторы к ERP, складу или CRM нужно проверять на совместимость хотя бы раз в год.
Подробнее: Переходите на Shopify Plus? 8 вещей, которые стоит проверить до миграции
- Интеграция систем
Интеграция систем это соединение отдельных бизнес-систем, например CRM, бухгалтерии, склада, таск-трекера и сайта, чтобы данные переходили между ними без ручного ввода. У большинства компаний проблема не в программах, а в интеграции: каждый инструмент работает, но данными они не делятся, и цены или остатки вручную обновляют в нескольких местах. Связать всё со всем значит получить клубок проводов, поэтому цель в продуманных границах. Правильная интеграция обрабатывает конфликты, повторы, сбои и сверку, а один плагин с этим справляется редко.
Подробнее: Цифровая архитектура: как построить систему, что растёт вместе с бизнесом
- Интеграционный слой
Интеграционный слой это собственное промежуточное ПО между существующими системами, которое переносит и переводит данные между ними, не заменяя ни одну из них. Он может синхронизировать заказы в обе стороны между CRM и складской системой или связать коробочную ERP с магазином, CRM и бухгалтерией. Если у слоя чёткие границы, поставщика можно заменить, не расшатав остальное: бизнес зависит от возможности, а не от вендора. Без такого слоя CRM, вшитая прямо в шаблон сайта, превращает каждый редизайн в интеграционный проект.
- Односторонняя и двусторонняя интеграция
Односторонняя интеграция передаёт данные в одном направлении, как товарный фид или выгрузка, а двусторонняя заставляет две системы обновлять друг друга, как магазин и CRM, которые обе редактируют карточки клиентов. Односторонняя интеграция это поток данных; двусторонняя это договор между двумя системами, каждая из которых считает себя правой. Для такого договора заранее нужны правила разрешения конфликтов, повторов и сверки, иначе получаются неверные остатки, задвоенные заказы и не сходящиеся счета.
Подробнее: Что на самом деле делает разработку e-commerce дорогой
- Источник истины (system of record)
Источник истины, или system of record, это единственная система, которая владеет определённым типом данных и чьё значение побеждает при расхождении: обычно ERP для остатков, себестоимости и финансов, PIM для информации о товарах, CRM для клиентов, магазин для заказов и CMS для редакционного контента. Если две системы могут менять остатки независимо, цифры расходятся. Владельцев данных стоит определить до выбора программ, вместе с тем, как быстро остальные системы узнают, что истина изменилась.
Подробнее: CRM и ERP: в чём разница и какая система нужна вашему бизнесу
- Миграция данных
Миграция данных это перенос данных из старой системы в новую: выгрузка, удаление дублей, сопоставление полей и проверка импорта на закрытой копии до настоящего переключения. При внедрении ERP обычный порядок такой: сначала очищенные справочники, затем начальные остатки на дату отсечения, потом открытые документы, а старая история остаётся в архиве только для чтения. Подготовка часто занимает больше времени, чем установка новой системы, а импорт должен проверять данные и вносить изменения так, чтобы их можно было отменить.
Подробнее: CRM и ERP: в чём разница и какая система нужна вашему бизнесу
- Параллельная работа и переключение
Параллельная работа это период, когда старая и новая системы действуют одновременно, пока их цифры не совпадут и новую не примут; переключение (cutover) это момент, когда бизнес окончательно переходит на новую. Новый магазин можно проверить на реальных заказах, пока старый остаётся доступным, а ERP внедрять по отделам, начиная с того, где ошибки обходятся дороже всего. Само переключение проводят в спокойное время и с планом отката, а основная тяжёлая работа делается ещё до смены DNS.
Подробнее: Уходить ли с Magento в 2026 году: обновление, Shopify Plus или Laravel?
Тестирование, релизы и документация
Как изменения проверяют, выпускают и описывают, чтобы следующая команда могла продолжить работу.
- QA-тестирование (quality assurance)
QA-тестирование, или обеспечение качества (quality assurance), это систематическая проверка программы на соответствие требованиям до и после каждого релиза: ручные тест-кейсы, автотесты, регрессионное и нагрузочное тестирование, проверка производительности. Задача QA найти ошибки раньше пользователей, а не исправлять их: исправление относится к разработке. Наши QA-специалисты работают от $30 в час, почасово или полный день за фиксированную сумму в месяц.
Подробнее: QA и тестирование
- Автоматизированное тестирование
Автоматизированное тестирование это проверка программы кодом при каждом изменении: от модульных тестов отдельных функций до сквозных тестов, которые проходят по интерфейсу с помощью Playwright или Cypress. Цель в том, чтобы контролировать стоимость изменений, а не набрать процент покрытия, поэтому тесты в первую очередь пишут там, где ошибка обходится дорого: цены, права доступа, заказы, платежи и остатки. Для продукта, который меняется каждый день, сначала нужны ручные проверки; автоматизация окупается, когда одни и те же проверки повторяются перед каждым релизом.
Подробнее: Что отличает премиальную сборку на Laravel или Symfony от просто рабочей
- Регрессионное тестирование
Регрессионное тестирование это повторная проверка существующих функций после каждого изменения, чтобы убедиться, что работавшее раньше по-прежнему работает, а старые ошибки не вернулись. Оно нужно командам, которые после каждого релиза снова находят одни и те же баги. Визуальное регрессионное тестирование сравнивает скриншоты и ловит непреднамеренные изменения интерфейса. В одном из наших обновлений чаще всего встречались стили, зависевшие от старых версий библиотек, и их поймали на тестовой копии до выхода в рабочую версию.
Подробнее: QA и тестирование
- Кроссбраузерное тестирование
Кроссбраузерное тестирование это проверка того, что сайт правильно выглядит и работает в разных браузерах и на разных устройствах, например в Chrome, Safari и Firefox на компьютерах и телефонах. Браузеры немного по-разному понимают один и тот же код, и расхождения проявляются в вёрстке, формах и медиа. Даже маленькое CSS-правило может повести себя очень по-разному: одно, написанное для изображений галереи, попало на картинки в статьях, и Safari показал их обрезанными в полный размер, а Chrome и Firefox сгладили ошибку.
Подробнее: Claude может построить сайт. Он не может построить понимание. Пока.
- Приёмочное тестирование (UAT)
Приёмочное тестирование (user acceptance testing, UAT) это проверка готовой системы самим клиентом перед запуском: её проводят будущие пользователи на своих реальных задачах. Оно работает, когда у него есть понятный срок (на практике удобны пять-семь рабочих дней), список проверок, одно место для замечаний, один человек, который их сводит, и чёткая граница между дефектом и новой хотелкой. Без этой границы приёмка превращается во второй круг согласования объёма работ.
Подробнее: Сколько на самом деле занимает разработка e-commerce и что должен делать клиент
- Нагрузочное тестирование
Нагрузочное тестирование это проверка того, как система ведёт себя под реальной или пиковой нагрузкой до запуска, с имитацией множества пользователей, заказов или обновлений данных одновременно. Для интернет-магазина это массовое обновление цен и остатков, задержка между ERP и витриной, восстановление после сбоя интеграции и синхронизация во время пика заказов. Пилот с горсткой пользователей прощает медленные запросы, поэтому нагрузочный тест или мягкий запуск должны состояться до того, как система незаметно станет инфраструктурой.
Подробнее: Переходите на Shopify Plus? 8 вещей, которые стоит проверить до миграции
- Код-ревью
Код-ревью это практика, при которой другой разработчик читает изменение, обычно в виде pull request, до того как его вольют в основной код. Оно ловит ошибки, дыры в безопасности и срезанные углы, а знания о коде распространяются по всей команде. С кодом, написанным ИИ, оно ещё важнее: типичный сценарий провала выглядит как промпт, генерация, беглый взгляд, коммит, а исследование DORA 2025 года показало, что ИИ усиливает сильные команды и ухудшает слабые. При аутсорсинге разработки модель работает лучше всего, если на стороне клиента есть человек, способный проверять код.
- CI/CD-пайплайн
CI/CD-пайплайн (непрерывная интеграция и непрерывная доставка) это автоматический путь, который собирает, тестирует и выпускает каждое изменение кода из разработки на стейджинг и в рабочую версию с заранее известным способом отката. Он заменяет вход на сервер и ручную загрузку файлов, а это маленький платёж по техническому долгу при каждом релизе. Хороший деплой намеренно скучен. Если каждый релиз ждёт единственного человека, который понимает пайплайн, узким местом стал сам пайплайн.
Подробнее: DevOps и облачная инфраструктура
- Стейджинг (staging environment)
Стейджинг это закрытая копия рабочего сайта или приложения с тем же кодом, настройками и копией данных, где изменения проверяют до того, как их увидят реальные пользователи. Закрывать его нужно на уровне сервера, а не только меткой noindex, а персональные данные в копии лучше обезличить. При нашем обновлении Laravel с 7 на 13 версию стейджинг поймал две ошибки, которые иначе попали бы на рабочий сайт.
Подробнее: Шесть версий Laravel за три дня
- План отката (rollback plan)
План отката это записанный и проверенный способ вернуть систему в последнее рабочее состояние, если релиз или обновление пошли не так: предыдущая версия кода, резервная копия базы данных, шаги развёртывания и человек, который принимает решение об откате. С ним неудачный релиз стоит нескольких минут неудобства, а не простоя. В наших обновлениях план отката есть на каждом шаге и остаётся наготове, пока клиент не подтвердит, что всё работает.
Подробнее: Модернизация сайта: обновление PHP, Laravel и CMS
- Git-репозиторий (контроль версий)
Git-репозиторий это место, где код проекта и вся история его изменений хранятся под контролем версий, обычно на платформе вроде GitHub или GitLab. Каждое изменение записывается с автором, временем и причиной, и любое прежнее состояние можно восстановить. Надёжнее всего, когда код лежит в организации самой компании, а подрядчики добавлены как участники, а не в личном аккаунте разработчика. Но владение репозиторием ещё не означает владения системой, если в нём нет приватных пакетов, настроек окружения или скриптов развёртывания.
Подробнее: Большинство компаний не владеют своим сайтом. Они владеют экосистемой зависимостей.
- Техническая документация
Техническая документация это письменное объяснение того, как устроена система и почему: архитектура, связи между частями, развёртывание, резервное копирование и восстановление, а также причины ключевых решений. Инструкция к админке или старое техзадание технической документацией не являются. Это память компании о собственном ПО, и от неё зависит, как быстро новый разработчик начнёт приносить пользу. Теперь у неё есть и второй читатель: ИИ-агенты для программирования, которым нужно знать, что нельзя трогать и когда остановиться и спросить.
Подробнее: Ваш сайт не падает в день, когда уходит разработчик. Он начинает падать на годы раньше.
- AGENTS.md
AGENTS.md это обычный Markdown-файл в корне репозитория, который объясняет ИИ-агентам для программирования, как работать в проекте: команды, правила, ограничения и всё, что не очевидно из кода. Его читает большинство крупных ИИ-агентов, а с декабря 2025 года формат курирует Agentic AI Foundation в составе Linux Foundation. При передаче проекта наши клиенты получают такой файл вместе с кодом, командами развёртывания и процедурой отката.
Подробнее: Вашему коду нужна инструкция для ИИ
- Пакет передачи проекта
Пакет передачи проекта это набор материалов, который клиент получает в конце работы, чтобы любая другая команда могла её продолжить: код, команды развёртывания, требования к серверу, процедура отката и документация. Без него следующий разработчик начинает с того, что восстанавливает устройство системы по коду. Наш пакет включает и файл AGENTS.md, чтобы ИИ-агент для программирования мог работать в проекте без догадок.
Подробнее: Интернет магазины
- ПО, готовое к продакшену
ПО, готовое к продакшену, это программа, на которую можно безопасно опереть реальный бизнес: она защищена, надёжно держит настоящий трафик, связана с платежами, CRM и аналитикой, проверена в разных браузерах и на разных устройствах, и её можно разворачивать, отслеживать и менять со временем. Прототип лишь показывает, что идея может работать. Продукт, собранный с ИИ за два дня, говорит о генерации, а не о владении; когда он начинает принимать платежи или хранить персональные данные, ему обычно нужно укрепление, а иногда и переписывание.
Подробнее: Claude может построить сайт. Он не может построить понимание. Пока.
- Вайб-кодинг (vibe coding)
Вайб-кодинг это создание программ, при котором человек обычными словами описывает ИИ-модели, что ему нужно, и принимает написанный ею код, часто не читая его. Термин предложил Андрей Карпаты в феврале 2025 года. Это быстрый способ проверить идею, но продукту, который принимает платежи или персональные данные, нужна проверка безопасности, работы с данными и кода до прихода реальных клиентов.
Подробнее: Вы собрали MVP с помощью ИИ. Оставить, доработать или переписать?
- Шаблонный код (boilerplate)
Шаблонный код (boilerplate) это повторяющийся код, который почти каждому приложению нужен в похожем виде: экраны создания, просмотра, изменения и удаления записей (CRUD), стандартные компоненты, эндпоинты API и конфигурация. Именно здесь ИИ-инструменты экономят больше всего времени, быстро генерируя такой код, когда задача уже понятна. В рефакторинге их вклад меньше, в архитектуре низкий, а в стратегии совсем низкий, поэтому быстрый шаблонный код не сокращает те части проекта, от которых зависит его успех.
Подробнее: AI упростил разработку. Построить успешный продукт — нет.
- Рефакторинг
Рефакторинг это переработка существующего кода, чтобы он стал понятнее и его было легче менять, без изменения того, что он делает для пользователей. Так команда понемногу гасит технический долг, а фраза «потом отрефакторим» часто и становится началом этого долга. Обновление фреймворка в запущенном приложении может потребовать серьёзного рефакторинга, второй по трудоёмкости части миграции после тестирования. С распространением ИИ-инструментов доля рефакторинга упала с 25% изменённых строк до менее чем 10% (GitClear).
Подробнее: Сколько стоит кастомный сайт в 2026 году?
Legacy, обновления и модернизация
Старые версии, скрытый долг и выбор между обновлением и переписыванием.
- Унаследованная система (legacy system)
Унаследованная, или legacy-система, это программа, которой продолжают пользоваться, хотя её платформа, версия языка или фреймворк устарели или больше не поддерживаются, например магазин или CRM на старой версии PHP или Laravel. День за днём она может работать нормально, но блокирует обновления безопасности, новые интеграции и ИИ-инструменты, пакеты которых требуют актуальных версий. Обычно выбирают между поэтапным обновлением и переписыванием.
Подробнее: ИИ-проект застрял на старой системе? Сначала обновление, потом автоматизация
- Технический долг (technical debt)
Технический долг это накопленная цена прошлых упрощений в программном обеспечении: устаревшие версии, быстрые заплатки, скопированные шаблоны, заброшенные плагины и недокументированные интеграции, которые работают, но делают каждое изменение медленнее и дороже. Пока система работает, его обычно не видно; он проявляется при редизайне, переезде или ИИ-проекте. Аудит до начала такой работы показывает долг раньше, чем он появится в бюджете.
Подробнее: Скрытый технический долг, из-за которого редизайн сайта стоит дороже плана
- Когнитивный долг
Когнитивный долг это растущая цена понимания системы: зачем был добавлен этот кусок кода, что от него зависит и пользуется ли им ещё бизнес. Технический долг делает программу труднее для изменений, когнитивный труднее для понимания, а родственный ему долг намерений это утраченные причины прошлых решений (Storey, 2026). Эту цену платят заново перед каждым изменением, и в оценки она почти не попадает; отчасти поэтому мелкие правки в старых системах занимают так много времени.
Подробнее: Код помнит все версии бизнеса
- Неявные знания (неписаные правила)
Неявные знания это неписаное знание о том, как на самом деле работают система и бизнес: исправления, исключения и правила, которые существуют только в голове или таблице конкретного человека. Они всплывают, когда этот человек уходит или систему заменяют, потому что самое сложное при уходе со старой системы это обнаружить её недокументированные доработки. ИИ-модель видит код, а не историю, поэтому кто-то должен записать, что старая система делает на самом деле, до её модернизации или автоматизации.
Подробнее: Почему большинство ИИ-пилотов не доходит до продакшена и как довести свой до живой работы
- Модернизация сайта
Модернизация сайта это обновление кода, языка программирования, фреймворка, CMS и скорости существующего сайта с сохранением интерфейса, контента и всего, что работает. Это не редизайн: сайт может выглядеть новым на старом бэкенде или выглядеть устаревшим на здоровом стеке, и только аудит показывает, какой случай ваш. Работа идёт версия за версией на закрытой копии, с откатом на каждом шаге и без простоя. Наш аудит стоит от $300 для небольших сайтов и от $1 000 для крупных.
Подробнее: Модернизация сайта: обновление PHP, Laravel и CMS
- Обновление мажорной версии (major version upgrade)
Обновление мажорной версии это переход сайта или приложения на новый крупный релиз фреймворка или языка программирования, в котором ожидаются несовместимые изменения. Laravel выпускает такой релиз раз в год, поэтому сайт, который не трогали пять лет, отстаёт примерно на пять версий. Безопасный путь: по одной версии за раз, на закрытой копии, с тестами и планом отката. Один из наших проектов перешёл с Laravel 7 на 13 за три дня.
Подробнее: Обновление старого сайта на Laravel или PHP в 2026 году
- Обновление или переписывание
Обновление или переписывание это решение, довести существующую систему до актуальных версий или построить новую. Обновление сохраняет контент, адреса страниц и историю в поиске и подходит, когда система соответствует бизнесу, модель данных здорова, а работает всё на PHP 7 или 8. О переписывании стоит говорить, когда оценка обновления приближается примерно к 60% стоимости чистой разработки или когда команда уже фактически переписывает систему изнутри обходными решениями. Переписывание в 2026 году стоит от $80 000 до более чем $3 млн.
Подробнее: Шесть версий Laravel за три дня
- Окончание поддержки (EOL)
Окончание поддержки (end of life, EOL) это дата, после которой версия программы больше не получает исправлений безопасности от разработчиков. В этот день ничего не ломается; риск и стоимость последующего обновления растут тихо. Например, поддержка PHP 8.1 закончилась 31 декабря 2025 года, 8.2 последует за ней 31 декабря 2026 года, а Laravel 11 перестал получать исправления безопасности 12 марта 2026 года. Заканчивается поддержка версии, а не платформы, поэтому обычный ответ это обновление, а не замена.
Подробнее: Обновление старого сайта на Laravel или PHP в 2026 году
- Зависимости (пакеты)
Зависимости это внешние пакеты, плагины, библиотеки и SDK, на которые опирается система, вместо того чтобы писать всё самостоятельно. Большинство приложений стоят на тысячах компонентов с открытым кодом, и риск не в том, чтобы ими пользоваться, а в том, чтобы их не знать. Зависимости задают минимальные версии и прекращают поддержку старых сред, поэтому часто вынуждают обновляться; SDK платёжного провайдера, например, может отказаться работать на старом стеке. Зрелые команды знают про каждую зависимость, зачем она нужна, её лицензию и ответственного, и следят за уязвимостями.
Подробнее: Обновление старого сайта на Laravel или PHP в 2026 году
- Заброшенный пакет
Заброшенный пакет это библиотека или плагин, которые автор больше не поддерживает, поэтому они не получают ни исправлений, ни поддержки новых версий фреймворка или языка. При обновлении именно такой пакет часто оказывается настоящим препятствием, серьёзнее самого фреймворка. В нашем собственном обновлении с Laravel 7 на 13 самой сложной частью стала неподдерживаемая библиотека форм админки, использованная более 200 раз в 29 шаблонах; небольшой слой совместимости сохранил старые вызовы рабочими, и переписывать каждое поле формы не пришлось.
Подробнее: Шесть версий Laravel за три дня
- Laravel Shift
Laravel Shift это платный автоматический сервис, который обновляет приложение на Laravel на одну мажорную версию за раз, примерно за $19-39 за шаг. По его собственной оценке, он экономит около двух часов при обновлении до Laravel 12. Вместе с Rector и ИИ-агентами для программирования это путь самостоятельного обновления. Сервис меняет код, но не проверяет, работает ли после этого бизнес: формы, почту, интеграции и задачи по расписанию всё равно нужно тестировать.
Подробнее: Шесть версий Laravel за три дня
- Аудит кода (технический аудит)
Аудит кода, или технический аудит, это структурированная проверка программной системы: версии языка, фреймворка, пакетов, интеграций, хостинга, почты, базы данных, задач по расписанию, прав доступа и правил индексации. Он заканчивается письменным отчётом о том, что в порядке, что рискованно и что делать дальше, с путём обновления, ценой и сроками. Аудит регулярно находит то, чего никто не замечал, например сообщения об ошибках, видимые посетителям, или письма из контактной формы, которые молча отклоняет почтовый сервер. Наш аудит стоит от $300 для небольших сайтов и от $1 000 для крупных, а отчёт остаётся у клиента.
Подробнее: Обновление старого сайта на Laravel или PHP в 2026 году
- Приём проекта от другого подрядчика (project takeover)
Приём проекта это передача работающего сайта, магазина или продукта от прежнего агентства или фрилансера новой команде: сбор доступов и кода, выяснение того, как проект разворачивается, стабилизация и продолжение разработки. Он нужен, когда прежний подрядчик ушёл, перестал отвечать или срывает сроки. Мы начинаем с аудита от $2 500 и ничего не меняем в рабочей версии, пока не заработают резервные копии.
Подробнее: Приём проекта от другого подрядчика
- Тихий сбой
Тихий сбой это неисправность, которая ломает часть системы, хотя внешне всё выглядит нормально: почта, загрузки, задачи по расписанию, индексация или интеграции перестают работать без единой ошибки на экране. Контактная форма по-прежнему благодарит за заявку, но заявка не приходит, или рабочий сайт случайно закрыт от Google. Это самый опасный вид сбоя после обновления или переезда. Сразу после запуска проверьте, что сайт открыт для поисковиков, отправьте настоящую тестовую заявку и дождитесь письма, убедитесь, что интеграции отвечают.
Подробнее: Шесть версий Laravel за три дня
Хостинг, инфраструктура и скорость
Где работает система, как её поддерживают в рабочем состоянии и что делает её быстрой.
- DevOps
DevOps, от слов development и operations (разработка и эксплуатация), это практика автоматизации того, как программы собираются, тестируются, выкладываются и работают, чтобы релизы были частыми, повторяемыми и обратимыми: конвейеры непрерывной интеграции и доставки (CI/CD), инфраструктура как код, мониторинг, резервные копии и управление доступом. В небольшой компании это часто значит, что релизы перестают зависеть от ноутбука одного человека. Наши DevOps-инженеры работают по ставке от $50 до $70 в час.
Подробнее: DevOps и облачная инфраструктура
- Хостинг
Хостинг это услуга и серверы, на которых работает сайт или приложение и хранятся его файлы, база данных и почта. Хостинг-аккаунт, который контролирует человек вне компании, создаёт зависимость, а часть настроек существует только на старом сервере и обнаруживается при первом переезде. Важны и настройки по умолчанию: файрвол или защита от ботов у хостера может закрыть сайт от Google или ИИ-краулеров без всякого решения владельца. Многие старые системы до сих пор работают на тарифах, рассчитанных на сайт, который только показывал страницы.
Подробнее: Обновление старого сайта на Laravel или PHP в 2026 году
- Облачный хостинг (AWS, Google Cloud)
Облачный хостинг это работа сайта или приложения на арендованной масштабируемой инфраструктуре провайдеров вроде AWS или Google Cloud, где мощности растут и сокращаются вместе со спросом. Это не всегда правильный выбор: в зависимости от нагрузки лучшим решением может быть AWS или Google Cloud с Kubernetes, несколько серверов у Hetzner или DigitalOcean или обычный хостинг. Правильная конфигурация это самая простая из тех, что выдерживают нагрузку. Если счёт за облако растёт быстрее трафика, нужен пересмотр расходов.
Подробнее: DevOps и облачная инфраструктура
- Docker и Kubernetes
Docker это инструмент, который упаковывает приложение со всем необходимым в контейнер, одинаково работающий на любом сервере, а Kubernetes это система, которая запускает, масштабирует и перезапускает множество таких контейнеров на разных серверах. Вместе они заменяют собранные вручную серверы повторяемыми, описанными средами. Kubernetes добавляет реальную сложность в эксплуатации, поэтому мы используем его только тогда, когда этого требует нагрузка.
Подробнее: Нанять DevOps-инженера
- Инфраструктура как код (Terraform)
Инфраструктура как код это описание серверов, сетей, баз данных и других облачных ресурсов в файлах кода, обычно с помощью Terraform, вместо ручной настройки в панели управления. Тогда инфраструктуру можно воссоздать, проверить и изменить как любой другой код, с историей каждого изменения. Обратная сторона касается владения: ушедший DevOps-инженер часто оставляет код Terraform и пайплайны, к которым никто не решается прикоснуться. DevOps-инженеры, способные принять такой код, подключаются к командам по ставке от $50 до $70 в час.
Подробнее: Нанять DevOps-инженера
- Переезд на другой хостинг
Переезд на другой хостинг это перенос сайта или приложения на новые серверы, к другому провайдеру или в облако, в идеале на аккаунты, которые контролирует владелец. При правильной подготовке он идёт по плану: копия, проверка, переключение в спокойное время; его можно совместить с обновлением версий, например контролируемый переезд вместе с переходом на PHP 8.2 за два вечера. После переезда часто пропускают две проверки: записи SPF и DKIM, без которых заявки с форм уходят в спам, и то, не блокирует ли новый хостинг поисковых и ИИ-краулеров.
Подробнее: DevOps и облачная инфраструктура
- Домен, регистратор и DNS
Домен это адрес сайта, регистратор это компания, у которой он зарегистрирован, а DNS это набор записей, который направляет домен на серверы сайта и почты. Кто контролирует аккаунт у регистратора, тот контролирует адрес бизнеса. Проверка владения выясняет, кто указан владельцем домена, у кого доступ к аккаунту регистратора, резервные почты, DNS и оплата, и когда домен продлевается. Домен, привязанный к личной почте или к бывшему разработчику, это базовый риск для владения.
Подробнее: Чем ты реально владеешь, а что арендуешь: Digital Ownership Audit
- SSL-сертификат
SSL-сертификат (технически TLS) это цифровой сертификат, который позволяет сайту работать по HTTPS: он шифрует трафик между браузером и сервером и подтверждает подлинность сайта. Браузеры предупреждают посетителей об опасности, если действующего сертификата нет. Сертификаты истекают и требуют продления, обычно автоматического, а просроченный сертификат это типичный сбой, который показывает, кто на самом деле контролирует инфраструктуру, поэтому он входит в любой аудит владения.
Подробнее: Ваш сайт не падает в день, когда уходит разработчик. Он начинает падать на годы раньше.
- CDN (сеть доставки контента)
CDN (content delivery network) это сеть серверов по всему миру, которая отдаёт файлы сайта из точки, ближайшей к посетителю, и по пути фильтрует трафик; распространённый пример это Cloudflare. CDN ускоряет страницы и поглощает атаки. В нём же живут правила кеширования, переадресаций и безопасности, от которых со временем начинают зависеть поиск, скорость и доступность сайта. CDN, настроенный одним сотрудником и нигде не описанный, становится типичным слепым пятном, когда этот человек уходит.
Подробнее: Ваш сайт не падает в день, когда уходит разработчик. Он начинает падать на годы раньше.
- Резервные копии и проверка восстановления
Резервные копии это копии кода, базы данных и файлов системы, которые хранят, чтобы восстановить её после сбоя, атаки или ошибки, а проверка восстановления это реальное восстановление из копии, доказывающее, что она рабочая. Копия, из которой никто ни разу не восстанавливался, это лишь надежда. Основа: ежедневные копии, хранящиеся вне сервера, и процедура восстановления, которая не зависит от конкретного человека. Реальное положение показывают три вопроса: есть ли свежие копии, восстанавливал ли кто-нибудь из них систему и получится ли это, если этот человек уйдёт.
Подробнее: Поддержка и обслуживание сайтов
- Аварийное восстановление (disaster recovery)
Аварийное восстановление (disaster recovery) это задокументированный план и средства для возвращения системы к работе после серьёзного сбоя: потери сервера, взлома сайта, удаления данных или отказа провайдера. Он определяет, где хранятся копии, кто действует, в каком порядке и сколько может длиться восстановление. При техническом due diligence его проверяют вместе с хостингом, средами, резервными копиями, DNS и мониторингом, а отсутствие документированного плана оценивается как высокий риск.
Подробнее: Как провести аудит сайта или цифрового продукта перед покупкой
- Мониторинг и наблюдаемость
Мониторинг и наблюдаемость (observability) это инструменты и практики, которые делают состояние системы видимым: ошибки, упавшие задачи, доступность, замедления и расход ресурсов. Мониторинг следит за известными сигналами и поднимает тревогу, а наблюдаемость позволяет понять, почему что-то пошло не так. Цель в том, чтобы о неудачном платеже, сломанной интеграции или остановленной очереди сообщала сама система, а не звонок клиента. Мониторинг доступности входит в наши планы поддержки, которые стоят от $1 000 в месяц.
Подробнее: DevOps и облачная инфраструктура
- Техническая поддержка сайта
Техническая поддержка сайта это постоянная техническая забота о работающем сайте: мониторинг, ежедневные резервные копии вне сервера, обновления безопасности и фреймворка, работа над скоростью, правки контента и проверка ошибок. Она держит сайт защищённым и актуальным между проектами, а не чинит его только после поломки. Многоязычным сайтам и интернет-магазинам нужны инженеры, а не скрипт, потому что любая интеграция может сломаться без сигнала. Поддержка начинается с вводного аудита кода, инфраструктуры и доступов.
Подробнее: Поддержка и обслуживание сайтов
- Доставляемость писем (SPF, DKIM)
Доставляемость писем это то, доходят ли письма сайта, например заявки с форм, подтверждения заказов и сброс пароля, во входящие, а не в спам или в никуда. Она зависит от DNS-записей вроде SPF и DKIM, которые подтверждают, что сервер вправе отправлять почту от имени домена, и от репутации отправителя. Переезд хостинга без этих записей может отправлять заявки с контактной формы в спам или терять их совсем, а аудиты находят и формы, которые всё ещё пишут на адрес бывшего партнёра. Поэтому доставляемость проверяют после каждого обновления или переезда.
Подробнее: Обновление старого сайта на Laravel или PHP в 2026 году
- Ошибки HTTP 403 и 429
HTTP 403 и 429 это ответы сервера с отказом: 403 Forbidden означает, что доступ запрещён, а 429 Too Many Requests, что клиент отправил слишком много запросов за короткое время. Это намеренные отказы сервера или его защиты от ботов, а не таймауты. Видимости сайта они вредят, когда достаются не тем посетителям: после одного переезда хостинга GPTBot и краулеры Meta получали 403. Кому именно отказывают, показывают логи сервера и тесты краулеров.
Подробнее: Мы отправили ИИ-агента за покупками в 15 американских интернет-магазинов. Вот где он сдался
- Переменные окружения (.env)
Переменные окружения это настройки и секреты, которые хранятся вне кода, в Laravel обычно в файле .env: доступы к базе данных, API-ключи, настройки почты и ключ приложения. Они позволяют одному и тому же коду по-разному работать в разработке, на стейджинге и в рабочей версии и не пускают секреты в репозиторий. Из-за недокументированных переменных окружения переданный код может вообще не запуститься у кого-то другого. Некоторые значения нельзя менять никогда: повторная генерация APP_KEY в Laravel на рабочей среде ломает сессии и все зашифрованные данные.
Подробнее: Чем ты реально владеешь, а что арендуешь: Digital Ownership Audit
- Скорость загрузки (PageSpeed Insights)
Скорость загрузки это то, как быстро страница загружается и становится пригодной к работе, а PageSpeed Insights это инструмент Google, который измеряет её, запуская Lighthouse на замедленном телефоне среднего уровня. Сама лабораторная оценка на позиции не влияет; влияют полевые Core Web Vitals реальных пользователей с порогами 2,5 с для LCP, 200 мс для INP и 0,1 для CLS. Офисные проверки обманчивы: одна главная страница загружалась меньше чем за секунду на офисном Wi-Fi и около шести секунд на обычном телефоне, пока сжатие изображений и смена хостинга не сократили время до двух секунд.
Подробнее: 3D на живом сайте: наш эксперимент с three.js и что увидел Google
- OPcache
OPcache это встроенное расширение PHP, которое хранит скомпилированный код в памяти, чтобы сервер не компилировал каждый скрипт заново при каждом запросе. Это настройка сервера, а не изменение кода, поэтому её стоит проверить на любом PHP-сайте как один из самых дешёвых способов ускорения. На нашем старом сайте на Laravel 7 включение OPcache сократило время ответа сервера примерно с 55 мс до 21 мс.
Подробнее: Шесть версий Laravel за три дня
- Кеширование
Кеширование это сохранение результата затратной работы, например запроса к базе, отрисованной страницы или ответа API, чтобы использовать его повторно, а не вычислять заново. Это один из главных способов сохранить скорость сайта под нагрузкой, и во многих старых системах нормального кеша нет. Применённое вслепую, кеширование может и сломать сайт: в нашей системе на Laravel кеш маршрутов зафиксировал маршруты без языковых префиксов и превратил каждую страницу на стейджинге в 404, поэтому маршруты там никогда не кешируются.
Подробнее: Что отличает премиальную сборку на Laravel или Symfony от просто рабочей
- Отложенная загрузка (lazy loading)
Отложенная загрузка (lazy loading) это загрузка изображений, видео, 3D-сцен и другого тяжёлого содержимого только тогда, когда посетитель вот-вот до него дойдёт, а не вместе со всей страницей. Она ускоряет первую загрузку и экономит трафик на телефонах. Содержимое первого экрана никогда не стоит загружать отложенно, иначе главное изображение появится с опозданием. На нашем сайте 3D в подвале начинает загружаться примерно за 800 px до подвала (на телефонах за 350 px), а диорама на странице контактов ждёт, пока браузер освободится.
Подробнее: 3D на живом сайте: наш эксперимент с three.js и что увидел Google
- Адаптивные изображения (WebP, AVIF)
Адаптивные изображения это картинки, подготовленные в нескольких размерах и отдаваемые в современных форматах вроде WebP и AVIF, чтобы каждое устройство скачивало только нужный ему вариант, а телефон никогда не загружал файл для компьютера. Подходящий размер браузер выбирает сам по списку в коде страницы. Вместе с отложенной загрузкой они сохраняют скорость сайтов с большим количеством изображений, например портфолио и каталогов. Обложки для превью в соцсетях всё же лучше держать в JPEG, который показывает любая сеть.
Подробнее: Сайт для архитектурного бюро: что клиенты смотрят до того, как позвонить
Безопасность и доступы
Кто к чему имеет доступ и как защищены системы и данные.
- Управление доступом (минимальные привилегии)
Управление доступом это контроль того, кто к каким системам и данным имеет доступ, по принципу минимальных привилегий: у каждого человека личный аккаунт только с теми правами, которые нужны для работы. Типичные бреши: общие логины, один человек со всеми админскими или платёжными доступами и бывшие подрядчики, у которых остались доступы к рабочей системе. Основа: личные аккаунты, менеджер паролей под контролем компании, репозиторий в организации компании и изменения в рабочей версии через проверку. После покупки бизнеса доступы стоит сменить, а пользователей пересмотреть в первые 30 дней.
Подробнее: IT-аутсорсинг и аутстаффинг
- Ролевая модель доступа (RBAC)
Ролевая модель доступа (role-based access control, RBAC) это способ выдавать права по ролям, например менеджер, бухгалтер или партнёр, а не каждому человеку отдельно. Для каждой роли она определяет, что можно видеть, менять, согласовывать и выгружать, и записать это стоит до проектирования экранов. Скрытая кнопка это не контроль доступа: правила должны выполняться на сервере и в базе данных. В ERP это значит решить, кто может менять цену, утверждать заказ поставщику, списывать товар или видеть маржу, и проверить это автотестами.
Подробнее: Разработка веб-приложений и SaaS
- Двухфакторная аутентификация (2FA, MFA)
Двухфакторная (2FA), или многофакторная (MFA), аутентификация требует, кроме пароля, второе подтверждение личности, например код из приложения, аппаратный ключ или подтверждение на телефоне. Тогда одного украденного пароля для входа уже недостаточно. Она нужна на каждом аккаунте с доступом к администрированию, деньгам или данным клиентов. Резервные коды важны не меньше самого второго фактора, поэтому проверка владения выясняет, у кого они хранятся.
Подробнее: Разработка веб-приложений и SaaS
- UAE PASS
UAE PASS это национальная цифровая идентификация Объединённых Арабских Эмиратов, которая позволяет резидентам входить в сервисы и подписывать документы электронно без отдельного пароля. Встроенная в личные кабинеты клиентов и B2B-системы, она убирает лишние шаги регистрации и добавляет подтверждённую личность. Для подключения нужны торговая лицензия ОАЭ и соглашение с провайдером, а онбординг проходит в четыре этапа, которые стоит заложить в сроки проекта.
Подробнее: Digital-агентство для бизнеса в ОАЭ
- OWASP Top 10
OWASP Top 10 это стандартный список самых критичных рисков безопасности веб-приложений, который публикует Open Worldwide Application Security Project; на него опираются при безопасной разработке и аудитах. В редакции 2025 года первое место занимает нарушение контроля доступа, и в той или иной форме оно нашлось в каждом проверенном приложении. Коду, написанному ИИ, нужна такая же проверка: по исследованию Veracode 2025 года, 45% образцов сгенерированного ИИ кода содержали уязвимости из OWASP Top 10.
Подробнее: Разработка веб-приложений и SaaS
- Межсайтовый скриптинг (XSS)
Межсайтовый скриптинг (cross-site scripting, XSS) это атака, при которой вредоносный скрипт внедряют в страницу, которую открывают другие люди, и злоумышленник может украсть сессию, изменить содержимое или действовать от имени пользователя. Она использует места, где сайт выводит пользовательский ввод без правильного экранирования. Старые библиотеки несут известные дыры: в любой сборке jQuery старше 3.5.0 есть задокументированная XSS-уязвимость. Код от ИИ тоже не застрахован: Veracode обнаружил, что защита от XSS не срабатывала в 86% соответствующих случаев сгенерированного кода.
Подробнее: Большинству компаний нужен не новый сайт, а новая структура
- CVE (известная уязвимость)
CVE (Common Vulnerabilities and Exposures) это публичный идентификатор, присвоенный известной уязвимости, чтобы производители, сканеры и команды могли точно на неё ссылаться. После публикации CVE о дыре знают и злоумышленники. Версии, поддержка которых закончилась, не получают исправлений для новых CVE и накапливают известные уязвимости, внешне продолжая работать нормально. Один из недавних примеров, CVE-2025-48757, открыл доступ к данным в более чем 170 проектах, собранных на ИИ-инструменте Lovable.
Подробнее: Большинству компаний нужен не новый сайт, а новая структура
- Управление секретами
Управление секретами это то, как команда хранит и контролирует пароли, API-ключи, токены и платёжные доступы: вне исходного кода, никогда в коде, который выполняется в браузере, и с отделением рабочих доступов от тестовых. Секреты живут в настройках окружения или в специальном хранилище с ограниченным и журналируемым доступом. У каждого пароля должен быть ответственный. Пароли, сохранённые в личном браузере сотрудника вместо менеджера паролей компании, это ранний тревожный признак.
Подробнее: Что отличает премиальную сборку на Laravel или Symfony от просто рабочей
- Защита на уровне строк (row-level security)
Защита на уровне строк (row-level security) это функция базы данных, которая определяет, какие строки каждый пользователь может видеть или менять, так что доступ контролирует сама база, а не только интерфейс. В приложении со многими клиентами именно она не даёт одному клиенту прочитать чужие записи, даже если в экране или API есть ошибка. Это главное слабое место многих MVP, собранных с ИИ: при аудите 50 таких приложений у 88% защита на уровне базы данных была полностью отключена.
Подробнее: Вы собрали MVP с помощью ИИ. Оставить, доработать или переписать?
- Журнал аудита (audit trail)
Журнал аудита (audit trail) это защищённая от подделки запись того, кто, что, когда и почему сделал в системе: пользователь или ИИ-агент, использованный инструмент, согласование, решение и результат. Обычные логи фиксируют, что что-то произошло, а журнал аудита позволяет восстановить, почему. В ERP каждое изменение остатков, цены или статуса документа записывается с пользователем и временем, а закрытые периоды нельзя править без корректирующего документа. Когда в бизнес-системах действуют ИИ-агенты, на таком журнале строится управление ими.
Подробнее: Соответствие для агентного ИИ: как защищать, контролировать и наблюдать за ИИ-агентами
- Защита от ботов
Защита от ботов это набор правил файрвола и сервисов, например Akamai, PerimeterX или Kasada, которые распознают и блокируют автоматических посетителей ещё до того, как они попадут на сайт. Она останавливает парсинг и атаки, но принимает решение раньше robots.txt, поэтому настройки по умолчанию могут закрыть сайт от Google или ИИ-краулеров без выбора владельца. В нашем тесте 15 американских интернет-магазинов защита от ботов остановила ИИ-агента для покупок в 4 из них: ответом 403, страницей ожидания, проверкой с удержанием кнопки или ответом 429.
Подробнее: Мы отправили ИИ-агента за покупками в 15 американских интернет-магазинов. Вот где он сдался
- Перечень компонентов ПО (SBOM)
Перечень компонентов ПО (software bill of materials, SBOM) это структурированная опись всех компонентов, от которых зависит программа: библиотек и пакетов с версиями, лицензиями и происхождением. Он позволяет компании быстро ответить, затронута ли она, когда в популярном компоненте находят уязвимость. Регулирование движется к обязательному SBOM через указ президента США 14028 и европейский Cyber Resilience Act, так что прозрачность зависимостей становится вопросом соответствия требованиям, а не только эксплуатации.
Подробнее: Большинство компаний не владеют своим сайтом. Они владеют экосистемой зависимостей.
Другие темы
Глоссарий
Хотите разобрать термин на примере своего проекта?
Приходите на стратегическую сессию. За два часа мы посмотрим на ваш бизнес целиком и простыми словами объясним, что каждое техническое или маркетинговое решение значит именно для него. Сессия стоит $500, и эта сумма засчитывается в проект, начатый в течение 30 дней.