Como a Atlassian estabelece a prontidão operacional

Nível 0: infraestrutura básica crítica

Serviços de nível 0 apresentam a infraestrutura de suporte e componentes de serviços compartilhados dos quais os serviços de nível 1 dependem para funcionar. Os componentes são considerados críticos se uma das seguintes situações for verdadeira:

• Eles são necessários para que o serviço de nível 1 seja executado ou acessado pelos usuários
• Eles são necessários para que o cliente se inscreva em um serviço de nível 1
• Eles são necessários para que a equipe dê suporte ou realize as principais funções operacionais no serviço de nível 1, como:

- Iniciar / Parar / Reiniciar o serviço
- Realizar uma implementação, upgrade, reversão ou hot fix
- Determinar o estado atual (para cima / baixo / degradado)

Nível 1: serviços essenciais

Serviços de nível 1 apresentam uma função vital para negócios, clientes ou produtos. Esses são serviços voltados para o cliente ou serviços internos essenciais para os negócios. Quando o serviço está degradado ou indisponível, a empresa perde dinheiro ou não consegue realizar funções comerciais críticas e/ou a funcionalidade principal da perspectiva do cliente é perdida. Os serviços de nível 1 exigem turnos de suporte 24 horas por dia, 7 dias por semana, têm SLAs elevados para as principais métricas e um conjunto rigoroso de requisitos de entrada em operação.

Nível 2: serviços não essenciais

Serviços de nível 2 apresentam um serviço voltado para o cliente que não faz parte da funcionalidade principal. Os serviços de nível 2 oferecem valor agregado ou uma experiência adicional ao usuário, que pode ser considerada opcional ou "conveniente".

Serviços de nível 2 incluem serviços públicos com função sobretudo de marketing, como sites de empresas públicas. Esses não são serviços empresariais oferecidos de forma direta aos clientes nem serviços internos usados pelas equipes para desempenhar aspectos de suas funções, como ferramentas de colaboração, rastreamento de tickets e outros.

Os serviços de nível 2 podem ou não exigir turnos de suporte 24 horas por dia, 7 dias por semana, ter SLAs inferiores e menos requisitos para as entradas em operação.

Nível 3: apenas funções internos ou não críticos

Serviços de nível 3 apresentam a funcionalidade interna para a empresa ou serviços beta experimentais. Essa classe também pode incluir serviços que sejam funções experimentais atuais para os primeiros usuários, onde se estabelece uma expectativa de que a qualidade do serviço possa se degradar durante a versão beta. Esse nível disponibiliza um grupo de SLA baixo para serviços que são suportados apenas pelos melhores esforços.

Perda de dados (RPO)

Esse número representa a quantidade máxima de dados que vão ser perdidos pelo serviço no caso de uma falha no serviço. O serviço de nível 0 vai perder menos de uma hora de dados no caso de uma falha no serviço.

Restauração de serviços (RTO)

Esse número representa o tempo máximo antes que o serviço volte a funcionar. O serviço de nível 0 vai se recuperar por completo em menos de quatro horas.

Backups

Quando o serviço é interrompido, as equipes podem precisar usar backups para restaurar os dados até um determinado momento. É importante fazer backups regulares dos dados, implementar processos de restauração e testar esses processos de forma rotineira. O processo de backup e restauração deve ser confiável e eficaz. A documentação e os testes são fundamentais aqui.

Definição de concluído

• Implementar o processo de backup e restauração
• Documentar e testar o processo de backup e restauração
• Teste o processo de backup e restauração com frequência
  

Gerenciamento de capacidade

Descreva quais capacidades o serviço oferece aos consumidores com clareza. Em particular, identifique quaisquer limites que o serviço impõe aos consumidores. Implemente testes de desempenho para garantir que o serviço opere dentro dos limites esperados.

Aqui estão alguns exemplos de informações para testar e disponibilizar aos consumidores.

• O serviço é limitado a X requisitos por segundo
• O serviço garante um tempo x de resposta
• A função X do serviço é ou não replicada entre regiões
• O consumidor não deve fazer X
  - sobrecarregar o serviço
  - fazer upload de arquivos maiores que X

Definição de concluído

• Os limites do serviço são identificados e documentados
• O teste de desempenho está em vigor para verificar se os limites foram aplicados
  

Conscientização do cliente

A capacidade de suporte é um aspecto importante da qualidade do serviço que está ao lado da confiabilidade e da usabilidade. As equipes devem criar processos de suporte para serviços ou novas funções de serviços antes que ele seja lançado. A capacidade de suporte pode incluir um processo de suporte ao cliente, um processo de controle de alterações, runbooks de suporte e outros itens focados no suporte.

Processo de suporte ao cliente

Os desenvolvedores devem entender o que acontece quando os clientes entram em contato com a equipe de suporte para obter suporte e devem entender as devidas responsabilidades com relação ao processo de suporte. Isso pode incluir fazer parte da rotação de plantão ou ser solicitado a resolver problemas de produção à medida que eles ocorrem.

Processo de controle de alterações

Nem todas as alterações afetam os clientes da mesma forma. Algumas alterações são imperceptíveis para os clientes. Por exemplo, uma pequena correção de bug. Algumas resultam em um grande esforço de adoção pelo cliente, como a reescrita completa da API. O controle de alterações ajuda a avaliar a magnitude do impacto que as alterações podem ter para o cliente.

Runbooks de suporte

Os runbooks oferecem uma visão geral de alto nível de como o serviço funciona, bem como explicações informativas dos problemas que podem ocorrer e qual o processo de resolução. É importante atualizar os runbooks com frequência e verificar se os procedimentos de suporte documentados são precisos à medida que o serviço muda com o tempo.

Definição de concluído

• A documentação que responde à maioria das perguntas que a equipe de suporte exigiria para investigar um item
• O processo funcional que controla as alterações
  
  

Recuperação de desastres

Parte de um desastre é perder a zona de disponibilidade. Os serviços precisam ser bastante resilientes para operar do mesmo jeito no caso de uma falha na zona de disponibilidade. A recuperação de desastres tem dois componentes: primeiro, desenvolver e documentar um processo de recuperação de desastres e, segundo, realizar testes contínuos do processo documentado. A recuperação de desastres precisa ser testada com frequência. Teste a capacidade de lidar com falhas na zona de disponibilidade usando o plano documentado de recuperação de desastres.

Definição de concluído

• O plano de recuperação de desastres (DR) está documentado
• O plano de recuperação de desastres (DR) é testado
• Testes recorrentes do plano de DR estão programados
  

Registros

Os registros são úteis por vários motivos, como detecção de anomalias, investigação durante ou após uma interrupção do serviço e rastreamento de atividades maliciosas conectando eventos relacionados entre serviços usando identificadores exclusivos. Existem muitos tipos de registros. Alguns registros muito úteis que a maioria dos serviços deve incluir são:

• Registros de acesso
• REGISTROS DE ERROS

Definição de concluído

• Registros apropriados são gerados
• Os registros são armazenados em algum lugar onde possam ser encontrados e pesquisados com facilidade.
  

Verificações de acesso lógico

As verificações de acesso lógico se concentram no gerenciamento do acesso de usuários internos, acesso de usuários externos, acesso de serviço a serviço e criptografia de dados. Como o serviço previne o acesso não autorizado a funcionalidades e dados? Como as permissões do usuário são definidas, verificadas, atualizadas e descontinuadas? Esses controles oferecem proteção suficiente para dados confidenciais?

Usuários internos

Algumas perguntas importantes a serem respondidas são: como os usuários internos são autenticados? Como o acesso é concedido/provisionado? E como é removido? Como funciona o escalonamento de privilégios? Qual é o processo para análises e auditorias regulares de acesso?

Usuários externos

Como é gerenciada a autenticação para clientes? Como o acesso é concedido/provisionado? E como é removido? Como funciona o escalonamento de privilégios? Qual é o processo para análises e auditorias regulares de acesso?

Serviço a serviço

Isso é semelhante aos usuários internos e externos. As equipes devem determinar como os serviços vão ser autenticados entre si. Por exemplo, com a configuração do OAuth 2.0.

Criptografia

É provável que as equipes queiram criptografar dados em repouso e em trânsito. Explique como o serviço gerencia a criptografia de dados. Como a equipe gerencia as chaves? Qual é a política de rotação de chaves?

Definição de concluído

• As verificações de acesso lógico são documentadas, implementadas e testadas para usuários internos, usuários externos e serviço a serviço
• Os dados são criptografados em repouso
• Os dados são criptografados em trânsito
• A criptografia é implementada e testada
  

Versões

A implementação da nova versão do serviço não deve interromper o tráfego de clientes além do definido no SLA dos serviços. Todas as mudanças devem ser revisadas por colegas, testadas e implementadas por meio de pipelines de CI/CD. Após cada implementação, verifique se a implementação foi bem-sucedida e não interrompeu nenhuma funcionalidade. É preferível que a verificação automatizada seja realizada após a implementação. Tenha vários ambientes, por exemplo, de teste, staging, pré-produção e produção, para que as implementações possam ser testadas.

Definição de concluído

• O serviço tem uma implementação sem tempo de inatividade
• Há ambientes em que o serviço deve ser implementado e testado antes de entrar em produção
  

Checklist de segurança

A checklist de segurança é um conjunto de práticas e padrões para desenvolver e manter a infraestrutura e o software seguros. Esses padrões reduzem a probabilidade de violações de privacidade e violações de dados e, por sua vez, aumentam a confiança do cliente. As equipes devem desenvolver uma checklist de segurança que aborde a natureza do serviço que estão criando. Alguns exemplos de requisitos estão listados:

Definição de concluído

• Evidência de que não existem vulnerabilidades críticas ou altas abertas para o serviço
• Uso de criptografia em repouso para todos os armazenamentos de dados
• Evidência de que o serviço não permite conexões HTTP inseguras
  

Métricas de serviço

As métricas de serviço dão informações essenciais de saúde e diagnóstico sobre um serviço e capacitam as equipes a monitorar e responder a incidentes. Comece definindo um conjunto de métricas que são monitoradas para cada serviço. Em seguida, crie um painel com essas métricas em uma ferramenta como Datadog ou New Relic. Acione alarmes quando uma métrica sair dos limites e crie tickets de problemas no caso de um alarme.

Definição de concluído
Aqui estão alguns exemplos de coisas para medir:

• Latência: o tempo necessário para lidar com uma solicitação
• Tráfego: locais de carregamento no serviço por usuários externos
• Erros: número de usuários que afetam erros ou falhas
• Saturação: o quanto o serviço está ocupado e o quanto mais ele pode suportar
• Uso de recursos subjacentes: CPU, memória, disco
• Componentes internos do aplicativo, como filas, horários e fluxo
• Uso e funcionalidade principal do serviço: usuários ativos, ações por minuto
  

Resiliência do serviço

Os requisitos de resiliência determinam se um serviço pode ou não lidar com alterações na carga e/ou falhas de vários componentes. É possível que um serviço resiliente seja escalado por conta própria e seja resistente a falhas de um único ponto central.

Escalabilidade automática

Se o serviço tiver a capacidade de escalabilidade automática, tenha certeza que esteja tudo configurado e testado da maneira correta. Determine qual métrica vai acionar a escalabilidade automática e teste para garantir que ela esteja funcionando. Por exemplo, se o serviço exigir o armazenamento de dados em disco, ele pode monitorar a porcentagem de espaço livre dos discos e escalar ao adicionar o armazenamento quando a porcentagem de espaço livre estiver abaixo do limite.

Teste de falha de um único ponto central

É recomendável ter serviços que possam sobreviver a falhas de um único ponto central. Se um único ponto central do serviço cair, o serviço deve continuar funcionando, talvez com capacidade reduzida. Teste isso encerrando pelo menos um ponto central no serviço e observe o comportamento do sistema. É esperado que seu serviço dê conta de uma falha de um único ponto central. O ambiente em que você vai simular uma falha de um único ponto central deve ser monitorado.

Definição de concluído

• Evidência da escalabilidade automática implementada e testada
• Evidência de que os ambientes de produção e/ou de staging executam vários pontos centrais
• Evidência de que o serviço é resistente a falhas de um único ponto central
  

Suporte

Suporte é o processo de dar suporte a um serviço após o lançamento. As equipes precisam ter runbooks, ferramentas operacionais e rotações de plantão prontos e em funcionamento antes de entrarem em operação, para que os serviços que enfrentam empecilhos tenham processos de resolução.

Runbooks

Os runbooks dão aos respondentes de plantão o contexto e as instruções de que precisam para liderar esforços rápidos de remediação e resposta a incidentes.

Ferramentas operacionais

Executar serviços com um padrão suficiente significa que existe uma lista de plantão posicionada e que uma ferramenta operacional como o Opsgenie está configurada para alertar em plantão quando o serviço apresentar empecilhos.

De plantão

Para um serviço de nível 2 e nível 3, é necessária uma lista de plantão

Para um serviço de nível 1 e 0, é necessária uma lista de plantão 24 horas por dia, 7 dias por semana

Definição de concluído

• Os runbooks estão escritos e podem ser encontrados pelo suporte
• A ferramenta operacional está configurada e testada
• As rotações de plantão estão em vigor e estão sendo paginadas, caso surjam itens
  

Verificações de prontidão operacional sugeridas de nível 3

• Backups
• Registros
• Versões
• Checklist de segurança
• Métricas de serviço
• Suporte
  

Os serviços de nível 3 começam com os requisitos mais básicos de prontidão operacional.

Verificações de prontidão operacional sugeridas de nível 2 e nível 1

• Backups
• Recuperação de desastres
• Registros
• Versões
• Checklist de segurança
• Métricas de serviço
• Resiliência do serviço
• Suporte

Os serviços de nível 2 e nível 1 adicionam requisitos de prontidão operacional de resiliência de serviços e recuperação de desastres. É importante observar que os serviços de nível 2 e nível 1 podem ter diferentes requisitos de prontidão operacional. Não é necessário que os níveis tenham requisitos diferentes. Se outro requisito de prontidão operacional for considerado necessário para um nível de serviço específico, adicione-o. O nível 2 e o nível 1 podem divergir, dependendo das necessidades da equipe.

Verificações de prontidão operacional sugeridas de nível 0

• Backups
• Gerenciamento de capacidade
• Conscientização do cliente
• Recuperação de desastres
• Registros
• Verificações de acesso lógico
• Versões
• Checklist de segurança
• Métricas de serviço
• Resiliência do serviço
• Suporte

Os serviços de nível 0 adicionam gerenciamento de capacidade, conscientização do cliente e verificações de acesso lógico.