How Atlassian Manages Customer Data


How Atlassian does Resilience

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

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

На этой странице кратко описывается, как мы организуем полный жизненный цикл управления данными клиентов, в том числе резервное копирование с использованием встроенных возможностей Amazon Web Services (AWS), которое повышает доступность наших сервисов; как мы регулярно тестируем свои планы аварийного восстановления и какой подход к непрерывному совершенствованию планов по аварийному восстановлению и обеспечению непрерывности бизнеса используем.

How we manage back ups

First things first: Infrastructure and databases

В общих чертах, инфраструктура, которую используют продукты Atlassian, делится на две части: среда «платформа как услуга» (PaaS), которую мы называем Micros, и не-Micros. На платформе Micros работают продукты Jira, Confluence, Statuspage и Atlassian Access, а в среде не-Micros — Bitbucket, Opsgenie и Trello. Для простоты основное внимание в этой статье мы уделим своим самым крупным продуктам: Jira, Confluence и Bitbucket.

Jira и Confluence Cloud размещаются в нескольких регионах AWS (а именно: на западном и восточном побережье США, в Ирландии, Франкфурте, Сингапуре и Сиднее; при необходимости список регионов планируется расширить). Эти продукты используют инфраструктуру AWS как услугу (IaaS). Jira и Confluence Cloud используют логически раздельные реляционные базы данных для каждого экземпляра продукта, а вложения из Jira и Confluence Cloud размещаются на нашей платформе хранения документов (Media Platform), которая, в свою очередь, находится в хранилище Amazon S3.

Услуги и функции Bitbucket Cloud предоставляются набором сервисов, которые находятся в ЦОД компании NTT Communications (NTT) в городе Ашберн (штат Вирджиния), а их резервные копии хранятся в ЦОД NTT в городе Санта-Клара (штат Калифорния) и в AWS. Данные клиентов Bitbucket Cloud размещаются в PostgreSQL и системах хранения данных NetApp.

Backups

В Atlassian понимают: чем бы ни занималась ваша компания, она создает данные, без которых не смогла бы существовать. Мы всегда следуем собственной ценности «Не #@!% клиента», и для нас очень важно защитить ваши данные от потери. Поэтому мы реализуем масштабную программу резервного копирования.

Для защиты данных в Jira и Confluence Cloud компания Atlassian использует возможности Amazon RDS (сервис реляционных баз данных Amazon) по созданию снимков состояния, благодаря чему каждый день создается автоматическая резервная копия каждого экземпляра RDS. Снимки состояния Amazon RDS хранятся в течение 30 дней. Они позволяют восстановить экземпляр до состояния на определенный момент времени и зашифрованы по стандарту AES–256.

Для защиты данных Bitbucket их резервные копии сохраняются как в физических центрах хранения и обработки данных NTT, так и в AWS.

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

Подробную информацию см. на нашей странице часто задаваемых вопросов о хранении данных.

How we utilise multiple data centers and availability zones for high availability

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

Для этого компания Atlassian использует высокодоступные ЦОД AWS в разных регионах мира. Каждый регион AWS — это отдельная географическая область, состоящая из нескольких изолированных зон, которые называются зонами доступности (AZ). Например, регион US-West (западное побережье США) имеет две AZ: us-west-1a в Северной Калифорнии и us-west-1b в Орегоне. Обе эти зоны относятся к одному и тому же региону, но являются географически изолированными.

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

В Jira и Confluence используется режим многозонального высокодоступного развертывания сервиса Amazon RDS. При таком развертывании Amazon RDS выполняет и поддерживает синхронную резервную репликацию в различных AZ одного региона для резервирования и обеспечения возможности переключения при отказе. Переключение AZ при отказе выполняется автоматически и обычно занимает 60–120 секунд, поэтому операции с базой данных могут возобновиться в кратчайшие сроки и без вмешательства администратора. Понятия региона, AZ и репликации иллюстрируются приведенными ниже схемами. В Opsgenie, Statuspage, Trello и Jira Align используются аналогичные стратегии развертывания, с небольшими отличиями во времени репликации и переключения при отказе.

В случае Bitbucket все основные серверы баз данных размещаются в ЦОД NTT, а узлы репликации и резервные копии хранятся в центрах обработки данных как NTT, так и AWS. Данные рабочей среды постоянно реплицируются в центрах обработки данных NTT, расположенных в городах Ашберн (Вирджиния) и Санта-Клара (Калифорния), с использованием технологии зеркалирования. Репликация данных рабочей среды Bitbucket с основного сайта на вспомогательный выполняется каждые 2 часа. Средняя задержка репликации составляет 10–20 минут, а максимальная — не более четырех часов.

How we determine recovery time and recovery point objectives

В идеальном мире мы никогда не теряли бы важные деловые данные. Однако в реальной жизни система с нулевым риском потери данных либо недостижима, либо запредельно дорога. Хотя корпоративная культура Atlassian ориентирована на сценарий с нулевой потерей данных и автоматическим восстановлением работоспособности при отказе зоны доступности, при планировании непрерывности бизнеса необходимо задавать целевые сроки восстановления (RTO) и целевые точки восстановления (RPO) для нахождения правильного баланса между затратами, выгодой и риском.

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

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

Если говорить более конкретно, мы разбиваем сервисы на понятные блоки, которые называем уровнями. Мы определили три уровня (1, 2 и 3) для продуктов и ориентированных на клиентов сервисов, бизнес-систем и внутренних инструментов Atlassian, а также один базовый уровень (0) с еще более высоким уровнем доступности для критических компонентов, на которых все держится.

For each tier, we’ve defined mandatory targets by reviewing, amongst other things, business impact assessments and typical usage scenarios for the services we build. Our service tiers help determine availability, reliability, RTO and RPO targets as set out in the table below.

         
  Уровень 0 Уровень 1 Уровень 2 Уровень 3
Критически важные компоненты инфраструктуры и сервисов К уровню 0 относятся сервисы, которые лежат в основе всех остальных сервисов и являются критически важными для поставки наших продуктов. Сервисы уровня 1 — это, в основном, наши продукты или сервисы, напрямую связанные с их поставкой. Сервисы уровня 2 — некритичные либо внутренние сервисы. Сервисы уровня 3 — некритичные либо внутренние сервисы.
Примеры сервисов:

Примеры сервисов

· Платформа AWS

· Сервер Micros

· Сетевое ядро

Примеры сервисов

· Jira и Confluence Cloud

· Bitbucket

Примеры сервисов

· Image Effects

· CAC

Примеры сервисов

· Получение аналитической информации и (или) данных бизнес-аналитики

RPO* < 1 часа < 1 часа < 8 часов  < 24 часов 
RTO** < 4 часов < 6 часов < 24 часов < 72 часов

*RPO (целевая точка восстановления) — потеря данных в случае отказа

**RTO (целевой срок восстановления) — восстановление работы сервисов в случае отказа

Atlassian назначает владельцев сервисов ответственными за соблюдение целевых показателей RPO и RTO для соответствующих сервисов.    

 

How we do disaster recovery testing

Atlassian регулярно тестирует механизмы аварийного восстановления и непрерывно их совершенствует в рамках своей программы аварийного восстановления (DR). Эта программа ориентирована на обеспечение надежности и устойчивости данных клиентов. Мы проводим плановое и специальное тестирование следующих компонентов.

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

Процесс. Проводится ежеквартальное тестирование действующих процессов резервного копирования и восстановления критически важных / ориентированных на клиентов сервисов (включая сервисы уровня 0 и 1) для проверки их соответствия целевым показателям RTO и RPO (с учетом уровня сервиса). Все обнаруженные в процессе тестирования проблемы оформляются в виде заявок Jira и отслеживаются до полного исправления.

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

Системы. Технические команды по обеспечению надежности сайта (SRE) и команды по проектированию продуктов ведут постоянный мониторинг различных показателей сервисов, чтобы повысить качество обслуживания пользователей. Автоматические оповещения настраиваются таким образом, чтобы участники команды SRE получали уведомления, если показатели сервисов выходят за заданные пределы. Это позволяет немедленно принимать меры в рамках процессов реагирования на инциденты.

Дашбоард аварийного восстановления. Дашбоард DR используется внутри компании для централизованного отслеживания заявок Jira, касающихся контроля, технического обслуживания и тестирования критически важных / ориентированных на клиентов сервисов (включая сервисы уровня 0 и 1), чтобы обеспечить своевременное проведение проверок документации и процессов резервного копирования и восстановления.

Тестирование и моделирование аварийного восстановления (DR). Проводится ежегодное и специальное тестирование DR. В рамках тестирования DR мы проводим «настольные» учения, во время которых команды DR анализируют сценарии возможных инцидентов. В ходе этих учений тестируются различные сценарии и выявляются недостатки в процессах восстановления. Сценарии «настольных» учений включают в себя землетрясения, пожары, стихийные бедствия, комплексные учения по восстановлению и тестирование. После тестирования DR выполняется сбор, анализ и обсуждение результатов и намечаются дальнейшие шаги в рамках процесса непрерывного совершенствования. Меры по совершенствованию оформляются в виде заявки Jira и отслеживаются до их реализации.

Компания Atlassian предъявляет строгие требования к тестированию и процессам, а ее первоклассные специалисты сводят все в единую систему. С учетом этого, в программу DR компании Atlassian включены следующие человеческие ресурсы.

Инженеры по обеспечению надежности (SRE). SRE участвуют в регулярных собраниях по аварийному восстановлению и представляют свои критически важные сервисы. Инженеры SRE совместно с командой по оценке рисков и обеспечению соответствия требованиям выявляют недостатки в процессах DR и занимаются их устранением.

Эксперты в области аварийного восстановления. Каждая команда по продукту / сервису (включая базовые сервисы) имеет в своем составе эксперта в области DR, который контролирует и оказывает помощь в реализации DR для данного продукта/сервиса, чтобы он соответствовал требованиям, предъявляемым к сервису данного уровня.

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

Other broader business continuity measures and plans

Atlassian использует эффективные средства обеспечения непрерывности бизнеса (BC) и аварийного восстановления (DR). Они помогают свести к минимуму влияние на клиентов любых сбоев в работе. Основные руководящие принципы нашей программы BC и DR:

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

Обеспечение устойчивости посредством тестирования. Компания Atlassian осознает, что для достижения оптимальной устойчивости необходимо регулярное плановое тестирование и постоянное внедрение улучшений.

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

In summary

Atlassian combine best in-class technologies and on-going testing and validation to ensure our customer data is highly available, reliable and resilient. We operate multiple geographically diverse data centres, have an extensive backup program, and gain assurance through regularly testing disaster recovery and business continuity plans. To top it all off, we have exceptional people and dedicated resources bringing our processes together.