Чем доступность отличается от надежности, как вычисляется доступность и надежность системы, формулы расчета вероятности безотказной работы системы с микросервисной архитектурой.
Доступность и надежность: в чем разница?
Доступность информационной системы является одним из ключевых свойств, которые должны обеспечить меры информационной безопасности, о чем я недавно писала здесь. Доступность системы означает возможность обращения к ней, т.е. такое состояние, когда авторизованные субъекты, имеющие права доступа к информационным активам внутри системы (данным и компонентам ИС), могут их реализовать. Требования к доступности обычно задаются в процентах, например, доступность на уровне 99,99 означает, что система должна быть доступной 99,99% времени из 100%. При таком уровне доступности возможная недоступность системы не должна превышать 9 секунд в сутки, а время безотказной работы должны быть не менее 23 часа 59 минут 51 секунд в течение 24 часов. Пример расчета с помощью сервиса https://shootnick.ru/uptime/99.99 показан в таблице:
| Период | Возможная недоступность в течение | Время безотказной работы |
| День | 9 секунд | 23 часа 59 минут 51 секунд |
| Неделя | 1 минута | 6 дней 23 часа 59 минут |
| Месяц | 4 минуты 23 секунды | 30 дней 10 часов 24 минут 43 секунды |
| Квартал | 13 минут 9 секунды | 91 день 7 часов 14 минут 9 секунд |
| Полугодие | 26 минут 18 секунд | 182 дня 14 часов 28 минут 18 секунд |
| Год | 52 минуты 36 секунд | 365 дней 4 часа 56 минуты 36 секунд |
Однако, система может быть недоступной как по причине плановых отключений, например, на время обслуживания или обновления, так и из-за внеплановых аварий, называемых отказами. Характеристика безотказности относится к понятию надёжности – свойству системы выполнять требуемые функции в определенных условиях в течение заданного промежутка времени. Надёжность является комплексным свойством и выражается не только в периоде безотказной работы, но также может включать характеристики ремонтопригодности и сохраняемости параметров и объектов.
Для технических систем надежность обычно измеряется в часах и называется наработкой на отказ. Например, на новый автомобиль обычно дают гарантию 3 года с момента выпуска или 100-200 тысяч км пробега. Эти значения обусловлены тем, что вероятность отказа, т.е. поломки новой машины в первые 3 года эксплуатации очень мала. Поэтому производитель берет на себя обязательства устранить поломку, возникшую в результате заводского брака. Однако, подобная аналогия не подходит для информационных систем: даже если откажет аппаратное обеспечение, с данными и алгоритмами их обработки ничего не случится после определенного срока эксплуатации.
Задавать требования к надежности ИС в ТЗ можно с помощью следующих показателей:
- вероятность отказа в процентах в течение конкретного периода времени;
- частота отказов в течение конкретного периода времени;
- время восстановления после отказа (RTO, Recovery Time Objective);
- интенсивность отказов системы при выполнении конкретной функции.
Вообще теория надежности является неотъемлемой инженерной практикой при создании технических систем. И при разработке информационных систем ее тоже следует применять, особенно когда речь идет про микросервисную архитектуру. Почему именно для систем с микросервисной архитектурой важно рассчитывать надежность? Все просто: такая система состоит из нескольких подсистем (микросервисов) и средств их взаимодействия. Например, при асинхронной интеграции нескольких сервисов через Apache Kafka, RabbitMQ или другой брокер сообщений, отказ этого промежуточного ПО (middleware) может привести к недоступности всей системы или к нарушению ее работоспособности. Впрочем, в случае синхронной интеграции нескольких сервисов через веб-API отказ одного из них тоже может стать причиной неработоспособности всей системы и/или невозможности выполнения межсервисных транзакций.
Поэтому расчет надежности микросервисной системы очень важен при проектировании архитектурных решений. Как это сделать, рассмотрим далее.
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
3 июня, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.
Надежность микросервисной системы
Как уже было отмечено, система с микросервисной архитектурой является многокомпонентной, поскольку состоит из нескольких сервисов и, возможно, средств обеспечения их взаимодействия. Кроме того, каждый сервис может состоять из нескольких компонентов, например, серверное приложение и база данных. Согласно теории надежности, интенсивность отказов многокомпонентной системы равна сумме интенсивностей отказов ее компонент и не зависит от времени. Однако, в зависимости от структуры многокомпонентной системы ее общая надежность вычисляется по-разному.
Например, для простой системы с последовательным соединением независимых элементов надежность (вероятность работоспособного состояния) равна произведению надежностей ее элементов. А для системы с параллельным соединением независимых элементов их ненадежности, т.е. разность между 1 и вероятностью безотказной работы, перемножаются.
Поскольку вероятность безотказной работы всегда меньше 1, при любой структуре системы добавление еще одного элемента снижает ее общую надежность.
На практике большинство информационных систем имеют последовательное строение. Это характерно даже для классической трехзвенной архитектуры клиент-серверного приложения. Например, следующая диаграмма C4 показывает набор контейнеров, из которых состоит система Интернет-магазина, и их развертывание по программным узлам – средам исполнения.
Эта диаграмма создана с помощью следующего скрипта PlantUML:
@startuml
!include <C4/C4_Container>
!include <C4/C4_Deployment>
title Интернет-магазин
LAYOUT_LEFT_RIGHT()
Person(User, "Пользователь", "Не аутентифицированный пользователь")
System_Boundary(c1, "I-Shop") {
Node (web-browser) {
Container(frontend, "Клиентское приложение (Frontend)", "HTML, JS", $descr="Веб-страницы для отображения и запроса данных, а также отправки команд")
}
Node (web-server_Nginx) {
Container(backend, "Серверное приложение (Backend)", "Python", $descr="Серверное веб-приложение")
}
Node (DB-server_PostgreSQL) {
ContainerDb(shared_db, "Общая БД", "PostgreSQL", "Общая база данных")
}
}
Rel(User, frontend, "Смотреть товары", "HTTPS")
Rel(User, frontend, "Смотреть поставщиков", "HTTPS")
Rel(frontend, backend, "запросы", "HTTPS")
Rel(frontend, backend, "команды", "HTTPS")
Rel(backend, shared_db, "управлять товарами, заказами и пользователями", "postgres")
SHOW_LEGEND()
@enduml Это пример последовательного соединения элементов в системе. Рассчитаем общую надежность такой системы при следующих показателях надежности ее элементов:
- вероятность отказа клиентского приложения равна 0,5%, т.е. вероятность безотказной работы (1-0,005)=0,995;
- вероятность отказа серверного приложения равна 5%, т.е. вероятность безотказной работы (1-0,05)=0,95;
- вероятность отказа базы данных равна 1%, т.е. вероятность безотказной работы (1-0,01)=0,99;
В таком случае надежность системы составит 0,999*0,95*0,99=0,9357975.
Если backend состоит из нескольких микросервисов, например, сервис аутентификации и авторизации, сервис управления заказами, сервис оплаты и пр., о чем я писала здесь, при вычислении общей надежности системы следует учитывать надежность каждого сервиса.
В свою очередь, каждый сервис может состоять из нескольких структурных элементов, каждый из которых может отказать. При этом всю систему можно рассматривать как последовательное соединение элементов, кроме тех участков, где реализовано горячее резервирование. Например, при использовании Kafka в качестве средства асинхронной интеграции между сервисами установка фактора репликации больше 1 означает параллельное соединение элементов, т.к. каждое сообщение, отправленное сервисом-продюсером, реплицируется и может быть прочитано сервисом-потребителем даже при отказе лидера. Аналогичное замечание характерно для балансировки нагрузки по нескольким экземплярам приложений и баз данных. В этом случае надежность такого участка вычисляется как произведение ненадежностей, т.е. разность между 1 и вероятностью безотказной работы.
Таким образом, для системы с микросервисной архитектурой справедливы следующие выводы относительно ее надежности:
- многоэлементный характер микросервисной архитектуры предполагает множество точек отказа;
- добавление каждого нового элемента в систему снижает ее общую надежность;
- для расчета общей надежности системы следует представить ее в виде простой структуры с последовательным и/или параллельным соединением элементов.
На практике я ни разу не видела полноценного расчета надежности для информационной системы (впрочем, это не означает, что такого не существует в реальности)). Максимум, с чем приходилось сталкиваться, — это определение критичных элементов как потенциальных точек отказа, например, шлюз API, принимающий запросы с клиентских приложений и маршрутизирующий их по бэковским сервисам, сервисная шина или брокер сообщений, обеспечивающие взаимодействие между сервисами, база данных, где хранится информация, необходимая для работы нескольких приложений. После определения таких критичных элементов проектировщик системы может применить какие-то архитектурные приемы, направленные на снижение вероятность их отказа. Например, использование нескольких экземпляров серверного приложения и базы данных с репликацией и балансировкой нагрузки.
Справедливости ради стоит отметить, что отсутствие подробных математических расчетов надежности часто обусловлено отсутствием статистики отказов: ведь на тестовом сервере невозможно проверить все варианты использования системы, даже после модульного, интеграционного и нагрузочного тестирования. Впрочем, сложности в расчете надежности не означают, что следует от них отказаться. Лучше сделать это хотя бы приблизительно, чем не сделать вообще.
Основы архитектуры и интеграции информационных систем
Код курса
OAIS
Ближайшая дата курса
20 мая, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.
Больше материалов про проектирование информационных систем, разработку требований и их оформление в ТЗ вы узнаете на моих курсах в Школе прикладного бизнес-анализа на базе нашего лицензированного учебного центра обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
