Проектирование отказоустойчивой архитектуры в Yandex Cloud и AWS

Отказоустойчивая архитектура в Yandex Cloud и AWS строится на принципе распределения нагрузки между несколькими зонами доступности (Availability Zones) и регионами, где критические компоненты — виртуальные машины, базы данных и сетевые шлюзы — работают в режиме активной-активной или активной-пассивной конфигурации с автоматическим переключением при сбое. Ключевое отличие практической реализации от теоретических схем: в Yandex Cloud для группировки и автоматического восстановления ВМ используется сервис Instance Groups с поддержкой проверки состояния приложений, а в AWS аналогом служат Auto Scaling Groups с Health Checks и Target Groups, что позволяет переживать падение не только отдельного сервера, но и целого дата-центра.

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

Фундаментальные принципы надежности в гибридных и облачных средах

Современный системный администратор, переходящий к роли инженера по надежности (SRE), должен понимать, что отказоустойчивость — это не просто наличие резервных серверов, а способность системы сохранять функциональность при частичных сбоях. В контексте Yandex Cloud и AWS это достигается за счет архитектурных паттернов, которые устраняют единые точки отказа (Single Point of Failure — SPOF).

На практике это означает, что вы перестаёте думать категориями «сервер А» и «сервер Б», а начинаете оперировать понятиями «группа серверов в зоне доступности X» и «реплика данных в зоне Y». Смена мышления — самый сложный этап, особенно если за плечами годы классического администрирования, где каждый сервер был уникальной снежинкой с собственным характером.

Что такое отказоустойчивость и зачем она нужна

Отказоустойчивость (Fault Tolerance) — это свойство системы продолжать работу при возникновении ошибок в ее компонентах. В отличие от простого резервирования, где система может просто «замереть» до восстановления, отказоустойчивая архитектура автоматически перераспределяет нагрузку.

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

Ключевые уровни защиты:

1. Уровень приложения: Упаковка в контейнеры (Docker), что позволяет быстро запускать новые копии при сбое. Контейнер здесь — не просто модный термин, а способ стандартизировать среду исполнения и избавиться от классического «на моей машине всё работает».
2. Уровень вычислений: Использование Instance Groups (Yandex) или Auto Scaling Groups (AWS) для автоматического создания новых ВМ при падении старых. Это ваш основной механизм самовосстановления на уровне инфраструктуры.
3. Уровень данных: Кластеризация баз данных (PostgreSQL, MySQL) с репликацией между зонами. Без этого всё остальное теряет смысл — compute можно пересоздать за минуты, а потерянные данные не восстановить ни за какие деньги.
4. Уровень сети: Организация каналов связи через Yandex Cloud Interconnect или AWS Direct Connect в двух точках присутствия для исключения сбоя линии связи. В гибридных средах, где локальное железо соседствует с облаком, одиночный канал — это гарантированный даунтайм при земляных работах экскаватора где-нибудь на трассе.

Разница подходов: Yandex Cloud vs AWS

При проектировании архитектуры важно учитывать различия в инструментарии двух платформ. Хотя принципы (зонирование, репликация) одинаковы, механизмы реализации различаются — и это влияет на то, как вы будете писать Terraform-манифесты и настраивать CI/CD пайплайны.

Важный нюанс: в Yandex Cloud для повышения надежности сети рекомендуется использовать подключение на двух точках присутствия, а если это невозможно — резервировать канал через VPN-соединение через интернет. В AWS аналогичная логика применяется к Direct Connect, где критично наличие двух физических соединений. На практике это часто упирается в бюджет: два выделенных канала — удовольствие не из дешёвых, и бизнесу бывает сложно объяснить, зачем платить вдвое больше за «какую-то надёжность». Аргумент про простой на 8 часов и потерю выручки обычно помогает.

Архитектурные паттерны для Yandex Cloud

Yandex Cloud предлагает набор сервисов, которые позволяют реализовать архитектуру «Active-Active» (активная-активная) с минимальными затратами на ручное управление. Главное преимущество здесь — более низкий порог входа по сравнению с AWS: меньше сервисов, меньше уровней абстракции, проще документация на русском языке. Но это не значит, что можно расслабиться — базовые принципы отказоустойчивости никто не отменял.

Instance Groups как основа автоматизации

Сервис Instance Groups позволяет объединять виртуальные машины в группы и управлять ими как единым объектом. Это критически важно для сценариев, где нужно пережить падение целого дата-центра.

Как это работает на практике:

1. Вы создаете группу виртуальных машин с шаблоном (например, 4 CPU, 16 GB RAM).
2. Настраиваете проверку состояния: группа автоматически проверяет, что приложение внутри ВМ работает (например, возвращает HTTP 200).
3. Если ВМ падает или дата-центр становится недоступным, Instance Group автоматически создает новую ВМ в другой зоне доступности и добавляет ее в группу.

Здесь есть тонкость, которую часто упускают: Health Check должен проверять именно приложение, а не просто доступность ВМ по ICMP. Пинг может проходить, а сервис внутри — лежать мёртвым грузом. Поэтому endpoint вроде /health, который проверяет подключение к базе и доступность критических зависимостей — это must-have, а не nice-to-have.

Пример настройки:
В блоке «Шаблон виртуальной машины» вы можете выбрать образ с Container Solution, указав Docker-образ приложения. Это позволяет упаковать приложение в докер-образ и загружать его прямо на виртуальные машины, что упрощает развертывание и обновление. По сути, вы получаете примитивную оркестрацию контейнеров без необходимости поднимать полноценный Kubernetes — для небольших проектов это золотая середина между сложностью и функциональностью.

Кластеризация баз данных

Для обеспечения надежности данных в Yandex Cloud необходимо использовать кластерные решения баз данных. В настройках базы данных (например, PostgreSQL) можно выбрать режим кластера, где каждый хост запускается с определенными настройками (например, 4 ядра и 16 ГБ памяти), а при необходимости ресурсы масштабируются до 8 ядер и 32 ГБ памяти без остановки сервиса.

Типовая ошибка: Размещение всех узлов базы данных в одной зоне доступности. Если эта зона «упадет», вся система потеряет доступ к данным.
Решение: Распределение узлов (Primary и Replica) по разным зонам (например, zone-a и zone-b) с автоматической репликацией.

Добавлю от себя: не стоит недооценивать latency между зонами при синхронной репликации. В Yandex Cloud задержка между зонами одного региона обычно в пределах единиц миллисекунд, но при интенсивной записи это может стать узким горлышком. Асинхронная репликация снимает проблему производительности, но увеличивает RPO — баланс нужно выбирать под конкретный сервис.

Сетевая отказоустойчивость

Сетевой уровень в Yandex Cloud управляется сервисом Yandex Virtual Private Cloud (VPC). Для критически важных систем, требующих подключения к локальной инфраструктуре клиента (on-premise), используется Yandex Cloud Interconnect.

Стандарт надежности для сети:

• Организация двух физических соединений между инфраструктурой клиента и оборудованием Yandex Cloud на разных точках присутствия.
• Если два физических соединения невозможны, необходимо зарезервировать подключение через VPN-соединение через интернет.

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

Архитектурные паттерны для AWS

В AWS подход к отказоустойчивости более детализирован и требует глубокого понимания иерархии: Регион -> Зона доступности -> Subnet -> Security Group. Количество степеней свободы здесь выше, но вместе с ними растёт и когнитивная нагрузка — легко настроить что-то не так и создать иллюзию надёжности.

Auto Scaling Groups и Health Checks

В AWS аналогом Instance Groups являются Auto Scaling Groups (ASG). Они позволяют автоматически изменять количество ВМ в зависимости от нагрузки (CPU, запросы) или по расписанию.

Ключевые механизмы:

1. Health Checks: ASG постоянно проверяет состояние ВМ. Если ВМ не проходит проверку (например, не отвечает на ping или HTTP-запрос), она удаляется, и создается новая.
2. Target Groups: Группы целевых узлов (например, для Application Load Balancer), которые распределяют трафик только между здоровыми ВМ.
3. Multi-AZ Deployment: ASG автоматически распределяет ВМ по разным зонам доступности внутри региона. Если одна зона недоступна, ASG создает новые ВМ в других зонах.

Пример настройки политики масштабирования:

resource "aws_autoscaling_policy" "scale_up" {
  name                   = "cpu-scale-up"
  autoscaling_group_name = aws_autoscaling_group.app.name
  adjustment_type        = "ChangeInCapacity"
  scaling_adjustment     = 1
  cooldown               = 300
}

Эта политика автоматически добавит ВМ, если средняя нагрузка CPU превысит 70%, и удалит их, когда нагрузка снизится. Важный момент: cooldown-период в 300 секунд не даёт системе дёргаться при кратковременных всплесках. Без него ASG может начать лихорадочно создавать и удалять инстансы, превращая облачный счёт в произведение абстрактного искусства.

AWS Direct Connect и сетевая надежность

Для подключения локальной инфраструктуры к AWS используется AWS Direct Connect. Принцип надежности идентичен Yandex Cloud Interconnect:

• Два физических соединения: Обязательно использовать два канала на разных точках присутствия (Points of Presence) для исключения сбоя линии.
• Резервирование: В случае отсутствия двух физических каналов, резервирование осуществляется через VPN через интернет (AWS Transit Gateway или Direct Connect Gateway с VPN).

Это критично для гибридных сред, где часть данных хранится on-premise, а часть в облаке. На практике часто используют схему «один Direct Connect + один Site-to-Site VPN» как компромисс между стоимостью и надёжностью. Работает, но нужно помнить, что VPN через интернет — это негарантированная полоса и переменная задержка.

Managed Kubernetes (EKS) и отказоустойчивость подов

В AWS контейнеры и Kubernetes осваиваются с позиции админа: как обеспечить отказоустойчивость, а не просто запустить поды. EKS (Elastic Kubernetes Service) позволяет управлять кластером, где поды (Pods) автоматически перезапускаются при сбое.

Паттерн надежности для EKS:

• Размещение узлов (Nodes) кластера в разных зонах доступности.
• Использование Pod Disruption Budgets для ограничения количества подов, которые могут быть остановлены одновременно во время обновлений.
• Настройка ReplicaSets для обеспечения минимального количества копий приложения (например, 3 копии), распределенных по разным узлам.

Pod Disruption Budget — это та штука, которую часто пропускают в спешке, а потом удивляются, почему при обновлении кластера сервис ложится. PDB говорит Kubernetes: «Не смей выключать больше N подов этого сервиса одновременно». Без него плановый rolling update может превратиться в мини-даунтайм.

Пошаговая инструкция: проектирование архитектуры с нуля

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

Шаг 1: Аудит и определение требований

Начните с аудита текущего состояния. Сколько серверов? Какие критические сервисы? Какой уровень доступности (RTO/RPO) требуется?

• RTO (Recovery Time Objective): Максимальное время, которое система может быть недоступна.
• RPO (Recovery Point Objective): Максимальный объем данных, который можно потерять (время между последним бэкапом и сбоем).

Чек-лист аудита:

• [ ] Выявлены все единые точки отказа (SPOF).
• [ ] Определены критические сервисы (БД, API, фронтенд).
• [ ] Зафиксированы требования к RTO и RPO.
• [ ] Проверена возможность размещения ресурсов в разных зонах доступности.

Без этого шага всё остальное — стрельба из пушки по воробьям. Если бизнес говорит «нам можно терять 4 часа», а вы проектируете архитектуру с пятиминутным RTO — вы переплачиваете. И наоборот: обещать 99,99% доступности на одиночном сервере без репликации — значит готовить себе ночной инцидент.

Шаг 2: Выбор региона и зон доступности

Не размещайте все ресурсы в одной зоне доступности (Availability Zone).

• Yandex Cloud: Выберите регион (например, ru-central1) и распределите ВМ по зонам ru-central1-a, ru-central1-b, ru-central1-d.
• AWS: Выберите регион (например, eu-central-1 — Франкфурт) и распределите ресурсы по зонам a, b, c.

Важно: Для критических систем рекомендуется использовать мультирегиональную архитектуру (Active-Active в двух регионах), если бюджет позволяет. Это защита от совсем уж чёрных лебедей — региональных сбоев, которые хоть и редки, но случаются. Вопрос только в том, стоит ли страховка от такого сбоя удвоения инфраструктурных затрат — ответ зависит от цены простоя для конкретного бизнеса.

Шаг 3: Настройка вычислительного уровня (Instance Groups / ASG)

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

В Yandex Cloud:

1. Создайте Instance Group.
2. Настройте шаблон ВМ (Docker-образ, ресурсы).
3. Включите проверку состояния приложения (Health Check).
4. Установите минимальное количество ВМ (например, 2) и максимальное (например, 10).

В AWS:

1. Создайте Auto Scaling Group.
2. Выберите Launch Template с Docker-образом.
3. Настройте Health Checks (EC2 и Target Group).
4. Установите стратегию распределения по зонам (Multi-AZ).

Шаг 4: Организация сетевого уровня и балансировка

Используйте балансировщики нагрузки (Load Balancers) для распределения трафика между здоровыми ВМ.

• Yandex Cloud: Load Balancer (Network Load Balancer или Application Load Balancer). Настройте его на работу с Instance Groups.
• AWS: Application Load Balancer (ALB) или Network Load Balancer (NLB). Настройте его на работу с ASG через Target Groups.

Сетевая архитектура:

• Разделите сеть на публичные и приватные Subnets.
• В публичные Subnets поместите только балансировщики нагрузки.
• В приватные Subnets поместите ВМ и базы данных.
• Используйте Security Groups для ограничения доступа (например, только порт 443 для API, порт 5432 только из приватной сети).

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

Шаг 5: Настройка базы данных и репликации

Базы данных — самый сложный элемент отказоустойчивости.

• Yandex Cloud: Используйте Managed Service for PostgreSQL/MySQL с настройкой кластера. Разместите Primary в одной зоне, Replica в другой.
• AWS: Используйте RDS (Relational Database Service) с Multi-AZ deployment. Это автоматически создает реплику в другой зоне и переключает трафик при сбое.

Типовая ошибка: Использование самописных скриптов для репликации вместо Managed-сервисов. Это увеличивает риск потери данных и усложняет восстановление. Да, managed-сервисы дороже, но цена самодельного решения — это бессонные ночи и риск фатальной ошибки при failover, когда Primary уже мёртв, а Replica отстала на 5 минут транзакций.

Шаг 6: Тестирование и проверка сценариев

Архитектура не считается отказоустойчивой, пока вы не проверили ее на сбой. Это не опциональный этап, а обязательная часть проектирования.

Тестовые сценарии:

1. Падение ВМ: Удалите одну ВМ из группы вручную. Проверьте, создалась ли новая.
2. Падение зоны: Временно отключите доступ к одной зоне (в Yandex Cloud можно симулировать через отключение сети, в AWS — через изменение правил безопасности). Проверьте, переключился ли трафик на другую зону.
3. Падение БД: Отключите Primary узел базы данных. Проверьте, переключилась ли реплика на Primary.
4. Падение дата-центра: Если возможно, симулируйте сбой всей зоны (в облаках это часто делается через отключение сети).

Результат: Система должна продолжать обслуживать трафик без видимых потерь для пользователя. Если во время теста вы обнаружили, что failover занимает 3 минуты вместо ожидаемых 30 секунд — это не провал, а ценный результат. Лучше найти это на тесте, чем в продакшене в час пик.

Инструменты автоматизации: Infrastructure as Code

Ручное управление через веб-консоли неэффективно для масштабных систем. Переход к Infrastructure as Code (IaC) — обязательный этап для современного админа. Это та точка, где заканчивается «потыкать мышкой» и начинается инженерный подход.

Terraform для управления инфраструктурой

Terraform позволяет описывать инфраструктуру в коде (HCL) и версионировать ее, как софт. Это устраняет риск «ручных правок конфигов», которые перестали спасать при количестве серверов за сотню.

Пример структуры проекта:

infrastructure/
├── environments/
│   ├── production/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── terraform.tfvars
│   └── staging/
├── modules/
│   ├── compute/
│   ├── database/
│   └── network/
└── global/
    └── iam/

Преимущества:

• Версионирование: История изменений инфраструктуры в Git.
• Детерминизм: Повторное создание инфраструктуры всегда идентично.
• Аудит: Кто и что изменил в инфраструктуре.

Модульный подход с разделением на окружения — это не просто красивая структура папок. Это возможность протестировать изменение в staging, прежде чем выкатить его в production. И когда что-то идёт не так, git blame показывает, кто именно нажал не ту кнопку.

Ansible для управления конфигурациями

Ansible используется для настройки уже созданных серверов (установка пакетов, настройка конфигов, деплой приложения). В сочетании с Terraform это полный цикл автоматизации: Terraform создает серверы, Ansible их настраивает.

Типовая задача:

- name: Ensure nginx is installed and running
  hosts: web_servers
  become: yes
  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: present
    - name: Start nginx
      service:
        name: nginx
        state: started
        enabled: yes

Связка Terraform + Ansible закрывает 90% потребностей в автоматизации. Terraform отвечает на вопрос «что должно существовать», Ansible — на вопрос «как это должно быть настроено». Оставшиеся 10% — это специфические сценарии, где нужны CI/CD пайплайны и оркестрация посложнее.

Чек-лист: Типовые ошибки и как их избежать

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

Важный нюанс: Не полагайтесь на «автоматическое» восстановление без проверки. Всегда тестируйте сценарии падения (Chaos Engineering). Автоматика имеет свойство отказывать в самый неподходящий момент — и единственный способ узнать об этом заранее — сломать систему намеренно в контролируемых условиях.

Финансовая оптимизация (FinOps) в отказоустойчивых системах

Отказоустойчивость часто ассоциируется с высокими затратами (нужно больше серверов, больше каналов связи). Однако правильная архитектура позволяет оптимизировать расходы. FinOps — это не про «сэкономить любой ценой», а про то, чтобы каждый рубль, потраченный на надёжность, действительно работал на неё.

Баланс между надежностью и стоимостью

1. Auto Scaling: Не держите 10 серверов постоянно, если нагрузка падает ночью. Используйте Auto Scaling (Yandex) или ASG (AWS), чтобы уменьшать количество ВМ при низкой нагрузке. Это снижает затраты на 30-50%.
2. Выбор типа ВМ: Используйте более дешевые типы ВМ (например, с общим процессором) для не критичных узлов, а мощные (с выделенным процессором) — только для БД и API.
3. Резервирование ресурсов: В AWS можно купить Reserved Instances (на 1-3 года) для постоянных ресурсов, что снижает стоимость до 70%. В Yandex Cloud аналог — предоплаченные ресурсы.

Хороший паттерн — держать базовую нагрузку на резервированных инстансах, а пики закрывать spot-инстансами или on-demand машинами через автоскейлинг. Это даёт и предсказуемый бюджет, и эластичность.

Управление инцидентами и финансами

Современный админ управляет не только серверами, но и финансами.

• Мониторинг затрат: Используйте Cloud Monitoring (Yandex) или AWS Cost Explorer для отслеживания расходов.
• Алертинг: Настройте алерты на превышение бюджета.
• Оптимизация: Регулярно анализируйте, какие ресурсы используются неэффективно (например, ВМ с 1% нагрузки).

На практике самый частый источник перерасхода — это забытые ресурсы: снапшоты, которые никто не чистит, диски от удалённых ВМ, балансировщики без трафика. Ежемесячный аудит облачного счета — это не занудство, а прямые деньги, которые можно потратить на что-то полезное.

FAQ: Ответы на частые вопросы

Вопрос: Достаточно ли одной зоны доступности для небольшого проекта?
Ответ: Для проектов, где RTO (время восстановления) не критичен (например, можно потерять 1 час работы), одна зона может быть допустима. Однако для любого коммерческого сервиса, где важна непрерывность, рекомендуется минимум 2 зоны. Падение одной зоны в облаке происходит редко, но неизбежно — это вопрос не «если», а «когда».

Вопрос: Как часто нужно тестировать отказоустойчивость?
Ответ: Минимум раз в квартал. Рекомендуется проводить тесты после каждого крупного изменения архитектуры. Тесты должны включать симуляцию падения ВМ, зоны и базы данных. Идеальный вариант — автоматизированные chaos-тесты в CI/CD пайплайне, которые прогоняются при каждом деплое.

Вопрос: Что делать, если у меня нет двух физических каналов для Interconnect/Direct Connect?
Ответ: В этом случае необходимо зарезервировать подключение через VPN-соединение через интернет. Это не так надежно, как физический канал, но обеспечивает базовую отказоустойчивость. Главное — не забыть настроить мониторинг VPN-туннеля и автоматический failover.

Вопрос: Можно ли использовать Kubernetes для отказоустойчивости в Yandex Cloud и AWS?
Ответ: Да. В Yandex Cloud это Managed Kubernetes, в AWS — EKS. Оба сервиса автоматически распределяют поды по разным узлам и зонам, обеспечивая отказоустойчивость на уровне приложения. Но важно помнить: Kubernetes решает проблемы оркестрации, а не архитектуры — если вы развернули StatefulSet с одной репликой, никакой Kubernetes вас не спасёт.

Вопрос: Как обеспечить отказоустойчивость при обновлении приложения?
Ответ: Используйте стратегию Rolling Update (постепенное обновление) или Blue/Green Deployment. В Instance Groups и ASG это настраивается автоматически: новые версии запускаются, старые удаляются только после проверки состояния новых. Blue/Green сложнее в реализации, но даёт мгновенный откат — новые инстансы работают параллельно со старыми, и переключение трафика происходит одномоментно.

Вопрос: В чем главное отличие Instance Groups в Yandex от Auto Scaling Groups в AWS?
Ответ: Instance Groups в Yandex Cloud больше ориентированы на управление группой как единым объектом с проверкой состояния приложения, а ASG в AWS — на автоматическое масштабирование по правилам нагрузки. Оба решают задачу восстановления сбойных узлов. На практике ASG даёт более гибкие политики масштабирования (по CPU, по количеству запросов, по кастомным метрикам), тогда как Instance Groups проще в настройке и лучше интегрированы с экосистемой Yandex Cloud.

Заключение

Проектирование отказоустойчивой архитектуры в Yandex Cloud и AWS — это не просто настройка сервисов, а системный переход от ручного администрирования к инженерии надежности. Ключевые элементы успеха: распределение ресурсов по зонам доступности, использование Instance Groups/ASG для автоматического восстановления, настройка кластерных баз данных и организация сетевых каналов с резервированием.

Инструменты IaC (Terraform, Ansible) позволяют версионировать инфраструктуру и избегать ручных ошибок. Финансовая оптимизация (FinOps) через Auto Scaling и резервирование ресурсов делает надежную архитектуру экономически эффективной — вопреки распространённому мифу, что «надёжно» всегда означает «дорого».

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