Como a Atlassian gerencia os dados dos clientes


Como a Atlassian trabalha a resiliência

Os produtos em nuvem da Atlassian são elaborados para alto desempenho e construídos com as melhores tecnologias do mercado para que você saiba que seus dados e serviços vão estar disponíveis sempre que precisar. Aqui na Atlassian, a gente se preocupa muito com a resiliência dos dados e serviços dos clientes, ainda mais porque a gente também usa o mesmo conjunto de produtos.

Por isso, a gente trabalha para minimizar o impacto aos clientes em caso de interrupções. Com vários data centers em locais diferentes, a Atlassian tem um programa abrangente de backup e a segurança que só testes frequentes dos planos de recuperação de desastres e continuidade dos negócios podem trazer.

Nesta página, você pode ver como é feito o gerenciamento do ciclo de vida geral da gestão de dados do cliente, incluindo backups que usam recursos nativos do Amazon Web Services (AWS) para garantir a disponibilidade dos serviços, como e com que frequência os planos de recuperação de desastres são testados e nossa abordagem para a melhoria contínua dos planos de recuperação de desastres e continuidade dos negócios.

Gerenciamento de backups

Começando do começo: infraestrutura e banco de dados

Em termos gerais, a Atlassian é dividida em dois conjuntos principais de infraestrutura onde os produtos são executados: um ambiente de plataforma como serviço (PaaS), conhecido internamente como Micros, e não Micros. Entre os produtos executados na plataforma Micros estão o Jira, Confluence, Statuspage e Atlassian Access. Exemplos de produtos executados em ambientes não Micros incluem Bitbucket, Opsgenie e Trello. Para simplificar, este artigo vai tratar dos nossos maiores produtos: Jira, Confluence e Bitbucket.

O Jira e o Confluence Cloud estão hospedados em várias regiões do AWS usando a oferta de infraestrutura como serviço (IaaS) da AWS (em especial no leste e oeste dos EUA, Irlanda, Frankfurt, Singapura e Sydney, com planos de expandir para outras regiões conforme necessário). O Jira e o Confluence Cloud usam bancos de dados relacionais separados por lógica para cada instância do produto, e os anexos armazenados neles são mantidos em nossa plataforma de armazenamento de documentos ("Plataforma de mídia"), que é, por sua vez, armazenada no Amazon S3.

Os serviços e recursos do Bitbucket Cloud são oferecidos por um conjunto de serviços em execução no data center da NTT Communications (NTT) em Ashburn, Virgínia, com os backups mantidos no data center da NTT em Santa Clara, Califórnia, bem como na AWS. Os dados do cliente do Bitbucket Cloud são armazenados nos arquivadores PostgreSQL e NetApp.

Backups

A gente sabe que, independente do que sua empresa faça, ela cria dados e, sem esses dados, você não tem como fazer negócios. Respeitar o valor "Não ferre a vida do cliente" da Atlassian exige uma enorme preocupação em proteger você da perda de dados com um extenso programa de backup.

Para o Jira e o Confluence Cloud, a Atlassian utiliza o recurso de instantâneo do Amazon RDS (Amazon Relational Database Service) para criar backups diários automatizados de cada instância do RDS. Os instantâneos do Amazon RDS são mantidos por 30 dias com suporte para recuperação pontual e são criptografados usando a criptografia AES-256.

Para o Bitbucket, os backups são armazenados nos data centers físicos da NTT, bem como no AWS.

A Atlassian testa backups para restauração a cada trimestre, e todos os itens identificados nesses testes resultam em tickets do Jira para garantir que todos os itens sejam monitorados até serem corrigidos.

Para saber mais, consulte as perguntas frequentes sobre armazenamento de dados.

Uso de vários data centers e zonas de disponibilidade para uma alta disponibilidade

Com furacões, terremotos e tsunamis — riscos remotos, mas possíveis — é imprescindível que os dados sejam copiados (e replicados) em locais geográficos diferentes, para que possam ser recuperados, aconteça o que acontecer.

Para isso, a Atlassian usa as instalações de data center com alta disponibilidade do AWS em várias regiões do mundo. Cada região do AWS é um local geográfico separado com vários locais isolados, conhecidos como Zonas de Disponibilidade (AZs). Por exemplo, US-West (a costa oeste dos Estados Unidos) é uma região onde existem duas AZs, us-west-1a (no norte da Califórnia) e us-west-1b (no Oregon), ambas na mesma região geral, mas isoladas geograficamente.

Cada AZ é projetada para estar isolada das falhas em outras AZs e para proporcionar conectividade de rede de baixo custo e baixa latência a outras AZs na mesma região. Essa alta disponibilidade de várias zonas é a primeira linha de defesa e significa que os serviços executados em implementações com várias AZs devem poder resistir às falhas de AZ.

O Jira e o Confluence utilizam o modo de implementação de várias AZs para o Amazon RDS. Em uma implementação com várias AZs, o Amazon RDS provisiona e mantém uma réplica síncrona em espera em uma AZ diferente da mesma região para oferecer redundância e capacidade de failover. O failover da AZ é automatizado e costuma levar de 60 a 120 segundos e, portanto, as operações do banco de dados podem ser retomadas o mais rápido possível, sem intervenção administrativa. Esses conceitos de região, AZ e replicação estão destacados nos diagramas abaixo. Opsgenie, Statuspage, Trello e Jira Align usam estratégias de implementação semelhantes, com pequenas variações no tempo de réplica e failover.

Para o Bitbucket, todos os servidores de banco de dados primários estão nos data centers da NTT, com os pontos centrais de replicação e os backups armazenados nos data centers da NTT e no AWS. Os dados de produção são replicados sem interrupção nos data centers da NTT em Ashburn, VA e Santa Clara, CA, através da tecnologia de espelhamento. Os dados de produção do Bitbucket são replicados a cada duas horas do site primário ao site secundário, com um lag de replicação de em média 10 a 20 minutos e no máximo dentro de quatro horas.

Definição do tempo de recuperação e os objetivos do ponto de recuperação

Em um mundo ideal, dados comerciais vitais nunca seriam perdidos. Na prática, porém, um sistema com risco zero de perda de dados é inatingível ou tem um custo absurdo. A cultura da Atlassian faz com que a gente sempre busque atingir esse cenário de perda de dados zero e a capacidade de sobreviver automaticamente a uma falha na zona de disponibilidade. No entanto, para planejar a continuidade dos negócios, é preciso definir "objetivos de tempo de recuperação" e "objetivos de ponto de recuperação" (RTOs e RPOs, em inglês, respectivamente) e encontrar o equilíbrio certo entre custo, benefício e risco.

O RTO é o período após um incidente no qual o processo (ou sistema) comercial deve ser recuperado para poder voltar a funcionar. O RPO, por sua vez, é a quantidade de dados que a empresa aceita que pode perder em uma operação de recuperação. Em um exemplo simples: imagine que você faz backups diários e ocorre um incidente no final do dia. Ao fazer a recuperação com o backup (que foi feito ontem), você vai perder o que equivale a um dia de dados. Esse é o RPO.

Com avaliações de impacto e risco nos negócios, nossas equipes podem definir metas personalizadas de RTO e RPO com base nos requisitos de usuários do cliente e no possível impacto de uma interrupção.

Em termos mais específicos, os serviços da Atlassian são divididos em buckets que podem ser compreendidos com facilidade, chamados níveis. São três níveis para produtos e serviços voltados ao cliente, sistemas de negócios da Atlassian e ferramentas internas (níveis 1, 2 e 3), e um nível subjacente (nível 0) que oferece um padrão de disponibilidade ainda mais alto para os componentes críticos dos quais tudo depende.

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.

         
  Nível 0 Nível 1 Nível 2 Nível 3
Componentes essenciais de serviço e infraestrutura Os serviços de nível 0 são a base de todos os outros serviços, são essenciais para a entrega dos produtos. Os serviços de nível 1 são, no geral, nossos produtos ou têm relação direta à entrega desses produtos. Os serviços de nível 2 não são essenciais ou são internos. Os serviços de nível 3 não são essenciais ou são internos.
Exemplo de serviços:

Exemplo de serviços

· Plataforma AWS

· Servidor Micros

· Núcleo da rede

Exemplo de serviços

· Jira e Confluence Cloud

· Bitbucket

Exemplo de serviços

· Image Effects

· CAC

Exemplo de serviços

· Recebimento de dados analíticos e/ou de BI

RPO* <1 hora <1 hora <8 horas   <24 horas  
RTO** <4 horas <6 horas <24 horas <72 horas

*RPO — Objetivo do ponto de recuperação — perda de dados em caso de desastre

*RTO — Objetivo do tempo de recuperação — restauração de serviços em caso de desastre

Na Atlassian, a responsabilidade por garantir que o serviço relevante atenda às metas de RPO e RTO é designada aos Proprietários do Serviço.    

 

Testes de recuperação de desastres

A Atlassian conduz testes regulares de recuperação de desastres e se esforça para melhorar sempre, cumprindo o Programa de Recuperação de Desastres (DR, na sigla em inglês). O objetivo é garantir que os dados e serviços dos clientes sejam confiáveis e resilientes. São feitos testes programados e ad hoc, incluindo os seguintes elementos:

Documentação — Para os serviços críticos/voltados para o cliente (incluindo os níveis 0 e 1), são feitas análises trimestrais da documentação de backup para verificar a precisão e integridade/atualidade. Todos os itens identificados são documentados e resultam em um ticket interno do Jira, para que sejam monitorados até serem corrigidos.

Processo — Também são feitos testes trimestrais dos processos técnicos de backup/recuperação para serviços críticos/voltados para o cliente (incluindo os níveis 0 e 1), para determinar se os objetivos de RTO e RPO estão sendo atingidos (com base na classificação do nível de serviço). Todos os itens identificados decorrentes desses testes resultam em um ticket do Jira, para que sejam monitorados até serem corrigidos.

Resiliência e failover — São feitos testes periódicos e ad hoc para níveis de resiliência nas AZs para ter certeza de que a Atlassian consegue lidar com uma falha de AZ com tempo de inatividade mínimo. Embora a gente entenda que uma falha completa da região seja muito improvável, o teste de failover da região toda também é feito com frequência e a nossa resiliência regional continua se aprimorando.

Sistemas — As equipes de Engenharia de confiabilidade de sites (SRE) e as equipes de engenharia de produtos monitoram, sem parar, uma ampla variedade de métricas entre os serviços para ajudar a garantir que os usuários tenham experiências excelentes. São configurados alertas automatizados para notificar os membros da equipe de SRE quando determinados limites de métricas de serviço são ultrapassados, para que sejam tomadas ações imediatas em nossos processos de resposta a incidentes.

Painel de recuperação de desastres — A gente tem um painel de DR interno que possibilita o monitoramento central dos tickets do Jira relacionados à supervisão, manutenção e teste de serviços críticos/voltados para o cliente (níveis 0 e 1), garantindo assim que as análises da documentação e os processos de backup/recuperação sejam concluídos dentro do prazo.

Testes e simulações de DR — São feitos testes de DR uma vez por ano e ad hoc. Como parte dos testes de DR, há discussões informais para ajudar as equipes de DR a percorrer vários cenários de possíveis incidentes. Nessas discussões, diferentes cenários são testados para identificar lacunas nos processos de recuperação. Dentre os cenários para discussão estão terremotos, incêndios, desastres naturais, exercícios e testes de recuperação. Os resultados dos testes de DR são coletados, analisados e discutidos para determinar o escopo das próximas etapas, o que contribui para a melhoria constante. Os esforços de melhoria são documentados em um ticket do Jira e monitorados até serem corrigidos.

A Atlassian sabe que, além dos testes e processos rigorosos, ainda precisa manter o padrão que definiu de ter pessoas excepcionais fazendo tudo isso acontecer. Assim, a Atlassian inclui os seguintes profissionais no programa de recuperação de desastres:

Engenheiros de confiabilidade de sites ("SREs") — São profissionais comprometidos com reuniões periódicas contínuas de DR e representam seus serviços críticos. Eles identificam falhas de DR com a equipe de risco e conformidade, focando na correção necessária.

Defensores da recuperação de desastres — Os defensores da DR são nomeados em cada equipe de produto/serviço (incluindo serviços subjacentes) para supervisionar e ajudar na gestão da implementação de DR para um determinado produto/serviço e assegurar que ele atenda aos requisitos do nível de serviço.

Liderança — As gerências executiva e sênior estão envolvidas o tempo todo nos processos de recuperação de desastres. Com a liderança envolvida, a Atlassian tem os fatores técnicos e comerciais participando da estratégia de resiliência.

Outras medidas e planos de continuidade de negócios mais amplos

A Atlassian se esforça para manter fortes recursos de Continuidade de Negócios ("BC") e DR para garantir que o efeito sobre os clientes seja minimizado, caso haja uma interrupção em nossas operações. Os princípios fundamentais que norteiam nosso programa de BC e DR incluem:

Melhoria contínua — A Atlassian procura assegurar que as melhorias na resiliência venham por meio de eficiências operacionais, automação, novas tecnologias e práticas comprovadas.

Testes de garantia — A Atlassian acredita que, com testes programados regulares e aplicação de melhorias contínuas, é possível obter a resiliência ideal.

Recursos dedicados — A Atlassian designou pessoas e equipes para assegurar que os produtos voltados para o cliente recebam a atenção necessária para concretizar o BC e o DR. A Atlassian tem o nível certo de recursos alocados para apoiar nosso comitê de direção, avaliações de riscos, testes de análise de impacto nos negócios e, claro, incidentes reais.

Um breve resumo

A Atlassian combina as melhores tecnologias, testes e validação contínuos para garantir que os dados de nossos clientes estejam sempre disponíveis e sejam confiáveis e resilientes. Além disso, trabalha com vários data centers em locais diferentes, tem um extenso programa de backup e garante a segurança com testes regulares de recuperação de desastres e planos de continuidade de negócios. Por fim, dispõe de pessoas excepcionais e recursos dedicados para unir todos esses processos.