Как Atlassian обеспечивает готовность к эксплуатации

Уровень 0: критическая магистральная инфраструктура

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

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

- запуск/останов/перезапуск службы;
- развертывание, обновление, откат или исправление;
- определение текущего состояния (работает / не работает / снижена производительность).

Уровень 1: основные службы

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

Уровень 2: неосновные службы

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

A tier-2 service includes public services that function mainly in a marketing capacity, such as public company websites. They don’t offer customers direct business-grade services and internal services used by teams to perform aspects of their roles, such as collaboration tools, work tracking, and more.

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

Уровень 3: только внутренние или некритические функции

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

Потеря данных (RPO)

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

Восстановление работы службы (RTO)

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

Резервное копирование

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

Критерии готовности работы

• Внедрение процесса резервного копирования и восстановления.
• Документирование и тестирование процесса резервного копирования и восстановления.
• Систематическое тестирование процесса резервного копирования и восстановления.
  

Управление ресурсами

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

Вот несколько примеров информации, которую необходимо протестировать и предоставить потребителям.

• Служба может обрабатывать до X требований в секунду.
• Служба гарантирует время отклика, равное X.
• Функция X службы реплицируется или не реплицируется в различных регионах.
• Потребитель не должен делать X, например:
  - перегружать службу;
  - загружать файлы размером более X.

Критерии готовности работы

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

Информированность клиентов

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

Процесс поддержки клиентов

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

Процесс управления изменениями

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

Перечни процедур поддержки

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

Критерии готовности работы

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

Аварийное восстановление

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

Критерии готовности работы

• План аварийного восстановления задокументирован.
• План аварийного восстановления протестирован.
• В график внесены регулярные проверки плана аварийного восстановления.
  

Ведение журналов

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

• журналы доступа;
• ЖУРНАЛЫ ОШИБОК

Критерии готовности работы

• Созданы соответствующие журналы.
• Журналы хранятся в удобном и доступном для поиска месте.
  

Логические проверки доступа

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

Внутренние пользователи

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

Внешние пользователи

Каким образом выполняется аутентификация клиентов? Как происходит предоставление доступа и как его отключают? Каков принцип эскалации прав? В чем заключается процесс регулярных проверок и аудита доступа?

Отношения между службами

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

Шифрование

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

Критерии готовности работы

• Логические проверки доступа задокументированы, внедрены и протестированы на внутренних и внешних пользователях, а также между службами.
• Данные шифруются при хранении.
• Данные шифруются при передаче.
• Шифрование реализовано и протестировано.
  

Релизы

Развертывание новой версии службы не должно нарушать трафик клиентов сверх показателей, определенных в SLA службы. Все изменения должны быть проверены коллегами, а также протестированы и внедрены через конвейеры CI/CD. После каждого развертывания проверяйте, успешно ли оно прошло и не привело ли к нарушению работоспособности. При этом желательно внедрить автоматическую проверку после развертывания. Для тестирования развертываний используйте несколько сред, например тестовую, промежуточную, предварительную и рабочую.

Критерии готовности работы

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

Список задач безопасности

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

Критерии готовности работы

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

Показатели службы

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

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

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

Устойчивость службы

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

Автоматическое масштабирование

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

Тестирование отказов одного узла

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

Критерии готовности работы

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

Поддержка

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

Перечни процедур

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

Операционные инструменты

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

На дежурстве

Для службы уровней 2 и 3 требуется график дежурств.

Для службы уровней 1 и 0 требуется круглосуточный график дежурств.

Критерии готовности работы

• Перечни процедур написаны и доступны в службе поддержки.
• Операционный инструмент настроен и протестирован.
• Составлен график дежурств, а также настроены оповещения на случай возникновения проблем.
  

Рекомендуемые проверки готовности к эксплуатации для уровня 3

• Резервное копирование
• Ведение журналов
• Релизы
• Список задач безопасности
• Показатели службы
• Поддержка
  

К службам уровня 3 предъявляются самые базовые требования по части готовности к эксплуатации.

Рекомендуемые проверки готовности к эксплуатации для уровней 2 и 1

• Резервное копирование
• Аварийное восстановление
• Ведение журналов
• Релизы
• Список задач безопасности
• Показатели службы
• Устойчивость службы
• Поддержка

К службам уровней 2 и 1 добавляются требования относительно аварийного восстановления и устойчивости. Важно отметить, что службы уровней 2 и 1 могут иметь разные требования по части готовности к эксплуатации (хотя это и не обязательно). Если для определенного уровня служб необходимо другое требование по части готовности к эксплуатации, добавьте его. Уровни 1 и 2 могут отличаться в зависимости от потребностей команды.

Рекомендуемые проверки готовности к эксплуатации для уровня 0

• Резервное копирование
• Управление ресурсами
• Информированность клиентов
• Аварийное восстановление
• Ведение журналов
• Логические проверки доступа
• Релизы
• Список задач безопасности
• Показатели службы
• Устойчивость службы
• Поддержка

Службы уровня 0 включают управление ресурсами, информированность клиентов и логические проверки доступа.