Как обеспечить надежность SaaS-продукта для бизнеса?

Большинство компаний использует облачные b2b-сервисы — от онлайн-бухгалтерии и электронного документооборота до речевой аналитики и организации грузоперевозок. Сбои в этих системах могут стать причиной приостановки бизнес-процессов, поэтому отказоустойчивость SaaS — один из основных критериев при выборе решений для бизнеса. Как ее обеспечить, рассказывает IT-World.

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

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

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

Обеспечение отказоустойчивости инфраструктуры и системного взаимодействия

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

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

Резервирование ключевых компонентов и партнерских сервисов

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

Как обеспечить надежность SaaS-продукта для бизнеса?. Рис. 1

Zero Trust. Паранойя или фундамент безопасности?

Например, платформа кадрового электронного документооборота (КЭДО) интегрируется с удостоверяющим центром (УЦ), который выпускает электронные подписи. Если в УЦ происходит сбой, клиенты всех сервисов КЭДО, подключенных к нему, теряют возможность подписывать документы до его восстановления. Поэтому вендору важно обеспечить работу с двумя УЦ, чтобы избежать полной остановки процесс. Это требует существенных затрат, но значительно повышает катастрофоустойчивость платформы.

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

Почему важно нагрузочное тестирование

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

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

Приоритизация критичных процессов

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

Например, в системе КЭДО один из основных «тяжелых» процессов — конвертация печатных форм, то есть преобразование заявлений, документов и локальных нормативных актов (ЛНА) в PDF/А-1А. Обработку заявлений от сотрудников важно проводить оперативно: пользователь отправил заявку и ждет конвертацию онлайн, чтобы тут же подписать и отправить на согласование. Подписание документов и ознакомление с ЛНА (их сотрудник получает от работодателя) не требует спешки — никто не заметит, если уведомление об этой задаче придет пользователю через минуту или две. Поэтому в системе КЭДО при повышенной нагрузке приоритет отдается тем операциям, которые требуют немедленной реакции для лучшего пользовательского опыта.

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

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

Детализация систем мониторинга

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

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

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

Настройка маршрутов эскалации инцидента

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

Первая линия защиты — дежурные инженеры. Техническая поддержка и SRE-специалисты (Site Reliability Engineering — техническое обеспечение надежности сайта) — должны работать в круглосуточном режиме, обеспечивая непрерывный мониторинг и оперативное реагирование на возникающие проблемы. Для бесперебойного функционирования системы поддержки нужно внедрить график дежурств, в случае непредвиденных обстоятельств предусматривающий присутствие инженера на посту.

Импортозамещение в облаках: российский рынок после ухода западных провайдеров

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

Развитие инцедент-менеджмента

После каждого инцидента необходимо проводить тщательный анализ (RCA — Root Cause Analysis) для выявления его истинных причин. Этот процесс может раскрыть неочевидные проблемы в различных характеристиках системы — от архитектуры до бизнес-требований.

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

Обновление сервиса в автоматическом режиме

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

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

Архитектурный бэклог

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

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