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

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

Однако внутренняя архитектура IT-решений делится на две большие части:

• Frontend — разработка визуальных интерфейсов, дизайна сайтов, приложений. Все то, что пользователи видят на своих экранах;
• Backend — серверная часть, базы данных, доступы к ним, интеграции, поддержка API. Глубинная реализация бизнес-логики и процессов. 

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

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

Однако не все действуют так уверенно. Часто бюджеты и внимание распределяются с фокусировкой на фронтенде. Особенно в среднем и малом бизнесе.

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

Зачем нужен бэкенд

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

1. как минимум где-то должны храниться данные,
2. нужно организовать взаимодействие между хранилищами. 

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

Потому что оно:

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

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

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

Читайте по теме: Как подружить разработку и безопасность в рамках одной компании?

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

Как выглядят проблемы с бэкендом

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

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

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

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

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

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

Что делает бизнес, заинтересованный в надежном бэкенде

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

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

• «Дочка» крупного сотового оператора.
• Группа компаний с десятками филиалов.
• Небольшая онлайн-школа.

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

Читайте по теме: 7 шагов к организации разработки в IT-компании

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

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

Что можно сделать в таких случаях?

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

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

Дальше уже проще. 

Потому что грамотное реструктурирование бэкенда затрагивает не только IT, но и:

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

Это больше бизнесовое, чем «айтишное» решение. 

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

Например, вот как могут выглядеть подходы к бэкенду для устранения подобных проблем:

• Ранжирование типичных запросов клиентов, их приоритезация по срочности и типам

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

В результате KPI сервисного центра были превышены на порядок. 

• Ревизия CRM, систем биллинга, регулярных процессов

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

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

Суммарно это привело к сокращению времени по некоторым операциям с нескольких недель до часов. 

• Вместо ставки на внешнюю IT-экспертизу сделайте акцент на получение автономной и гибко модифицированной среды разработки

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

Фактически это платформенное решение. 

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

Значит ли это, что фронтенд почти не нужен, он вторичен и все держится на бэкенде? Нет, конечно. Это другая крайность, которой следует избегать.

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

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

Фото на обложке: Shutterstock / iJeab