Перейти к основному содержимому

6.11. Надежность и доступность

В РАЗРАБОТКЕНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНО
Разработчику Архитектору Аналитику

Надежность и доступность​

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

Надежность: способность системы работать без отказов​

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

Ключевыми метриками надежности являются:

  • MTTF (Mean Time To Failure) — среднее время до первого отказа. Эта величина применяется к системам или компонентам, которые не подлежат восстановлению после сбоя. Например, полупроводниковые элементы, аккумуляторы или одноразовые устройства. MTTF отражает ожидаемый срок службы до момента, когда устройство перестает функционировать навсегда.

  • MTTR (Mean Time To Repair) — среднее время восстановления. Это интервал между моментом возникновения отказа и моментом полного возвращения системы в рабочее состояние. В него входят время обнаружения сбоя, диагностики, замены компонентов, перезапуска и проверки работоспособности. Чем меньше MTTR, тем быстрее система возвращается к нормальной работе.

  • MTBF (Mean Time Between Failures) — среднее время между отказами. Эта метрика используется для восстанавливаемых систем и представляет собой сумму MTTF и MTTR. MTBF показывает, как часто можно ожидать сбои в процессе эксплуатации. Высокий MTBF указывает на стабильную и долговечную работу.

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

Доступность: готовность системы к использованию​

Доступность — это мера того, насколько система оперативно и постоянно готова выполнять свои функции в любой момент времени. Доступная система может быть недоступной лишь на короткие, заранее спланированные или минимально возможные интервалы. Доступность выражается в процентах от общего времени и часто описывается через «девятки»: 99%, 99.9%, 99.99% и так далее.

Высокая доступность достигается за счет:

  • минимизации времени простоя,
  • автоматизации процессов восстановления,
  • использования резервных компонентов,
  • грамотного проектирования архитектуры.

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

Отличие надежности от доступности​

Надежность и доступность — смежные, но разные понятия. Надежность отвечает на вопрос: «Как долго система проработает без сбоев?». Доступность отвечает на вопрос: «Как часто система будет готова к использованию?».

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

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

Последовательные и параллельные системы​

Архитектура системы напрямую влияет на её надежность. Два базовых подхода к организации компонентов — последовательное и параллельное соединение — дают принципиально разные результаты.

Последовательные системы​

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

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

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

Параллельные системы​

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

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

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

Существуют также гибридные архитектуры, сочетающие последовательные и параллельные участки. Например, кластер баз данных (параллельный блок) может быть частью последовательной цепочки: балансировщик → кластер БД → файловое хранилище. В таких случаях надежность оценивается по каждому сегменту отдельно, а затем объединяется в общую модель.

Практическое значение в IT​

В современных IT-системах надежность и доступность реализуются через многоуровневые стратегии:

  • Аппаратное резервирование: дублирование источников питания, дисков (RAID), сетевых интерфейсов.
  • Программная отказоустойчивость: автоматический перезапуск процессов, health-check’и, circuit breaker’ы.
  • Географическое распределение: размещение сервисов в нескольких дата-центрах или облачных регионах.
  • Автоматизация восстановления: использование оркестраторов, таких как Kubernetes, для перезапуска упавших контейнеров.
  • Планирование инцидентов: проведение регулярных учений, моделирование сбоев (Chaos Engineering).

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

Уровни доступности и соглашения об уровне обслуживания (SLA)​

Доступность систем в IT-индустрии часто измеряется в так называемых «девятках». Этот термин отражает процент времени, в течение которого сервис остаётся работоспособным и доступным для пользователей. Каждая дополнительная девятка означает значительное сокращение допустимого времени простоя в год.

  • 90% доступности — это 36.5 дней простоя в год. Такой уровень неприемлем для большинства коммерческих сервисов.
  • 99% — около 3.65 дней простоя в год. Подходит для внутренних или некритичных систем.
  • 99.9% — примерно 8.76 часов простоя в год. Стандартный уровень для многих публичных веб-сервисов.
  • 99.99% — около 52.6 минут простоя в год. Используется в высоконагруженных финансовых или телекоммуникационных системах.
  • 99.999% — менее 5.26 минут простоя в год. Такой уровень характерен для критически важной инфраструктуры, например, авиационных или медицинских систем.

Эти цифры не просто маркетинговые показатели. Они закрепляются в соглашениях об уровне обслуживания (Service Level Agreement, SLA) — официальных документах между поставщиком услуг и клиентом. SLA определяет:

  • гарантированную доступность,
  • время реакции на инциденты,
  • ответственность сторон при нарушении условий,
  • компенсации за простой (часто в виде кредитов или скидок).

Например, облачный провайдер может обещать 99.95% доступности для виртуальных машин. Если фактическая доступность окажется ниже, клиент получит возмещение в соответствии с условиями SLA. Однако важно понимать: SLA применяется к инфраструктуре, а не к приложению целиком. Даже при идеальной работе сервера приложение может быть недоступно из-за ошибок в коде, конфигурации сети или проблем с DNS.

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

Практические методы повышения надежности​

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

Резервирование (Redundancy)​

Каждый критический компонент дублируется. Это может быть:

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

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

Автоматическое восстановление​

Современные платформы способны обнаруживать сбои и реагировать на них без участия человека. Например:

  • Kubernetes перезапускает упавший контейнер.
  • Балансировщик нагрузки исключает неработающий сервер из пула.
  • Система мониторинга запускает скрипт восстановления базы данных.

Автоматизация сокращает MTTR и повышает общую доступность.

Изоляция сбоев (Fault Isolation)​

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

  • микросервисов вместо монолита,
  • очередей сообщений (например, RabbitMQ, Kafka),
  • circuit breaker’ов, которые временно отключают зависшие зависимости.

Тестирование отказоустойчивости​

Компании регулярно проводят Chaos Engineering — целенаправленное введение сбоев в рабочую среду для проверки устойчивости. Например, Netflix использует инструмент Chaos Monkey, который случайным образом отключает виртуальные машины в продакшене. Если система продолжает работать — архитектура считается надёжной.

Примеры из реального мира​

  • Amazon Web Services (AWS) гарантирует 99.99% доступности для своих зон доступности (Availability Zones). Это достигается за счёт физического разделения дата-центров, независимых систем питания и охлаждения.
  • Google Search работает с доступностью выше 99.999%. Это возможно благодаря глобальному распределению запросов, кэшированию и автоматическому переключению между кластерами.
  • Банковские системы часто используют активно-активные кластеры баз данных, где оба узла обрабатывают транзакции одновременно. При отказе одного узла второй мгновенно берёт на себя полную нагрузку.