Etapa 1: definir objetivos
Analisar qual nível de resiliência é necessário e como você o avaliará é a base para a etapa de definir objetivos. É difícil melhorar algo se você não tem um objetivo e se não consegue avaliá-lo.
Nem todas as aplicações precisam do mesmo nível de resiliência. Ao definir objetivos, considere o nível necessário para fazer os investimentos e compensações corretos. Uma boa analogia para isso é um carro: ele tem quatro pneus, mas carrega apenas um pneu sobressalente. A probabilidade de furar vários pneus durante uma viagem é baixa, e ter peças sobressalentes pode prejudicar outras características, como espaço de carga ou eficiência de combustível, portanto, esta é uma compensação razoável.
Depois de definir os objetivos, você implementa os controles de observabilidade em etapas posteriores (Etapa 2: projetar e implementar e Etapa 4: operar) para analisar se os objetivos estão sendo atingidos.
Mapeamento de aplicações críticas
Definir objetivos de resiliência não deve ser exclusivamente uma conversa técnica. Em vez disso, comece com um foco voltado para os negócios para analisar o que a aplicação deve oferecer e as consequências de uma deficiência. Essa análise dos objetivos de negócios tem então um efeito cascata em áreas como arquitetura, engenharia e operações. Qualquer objetivo de resiliência que você definir pode ser aplicado a todas as suas aplicações, mas a forma como os objetivos são avaliados geralmente varia de acordo com a função da aplicação. Você pode estar executando uma aplicação essencial para os negócios e, se ela estiver com alguma deficiência, sua organização poderá perder uma receita significativa ou sofrer danos à reputação. Como alternativa, você pode ter outra aplicação que não seja tão crítica e possa tolerar algum tempo de inatividade sem afetar negativamente a capacidade de sua organização de fazer negócios.
Como exemplo, imagine uma aplicação de gerenciamento de pedidos para uma empresa de varejo. Se os componentes da aplicação de gerenciamento de pedidos estiverem deficientes e não funcionarem adequadamente, novas vendas não serão realizadas. Essa empresa de varejo também tem uma cafeteria para seus funcionários localizada em um de seus edifícios. A cafeteria tem um menu on-line que os funcionários podem acessar em uma página da web estática. Se essa página ficar indisponível, alguns funcionários poderão reclamar, mas isso não necessariamente causará danos financeiros à empresa. Com base nesse exemplo, a empresa provavelmente escolheria ter metas de resiliência mais agressivas para a aplicação de gerenciamento de pedidos, mas não faria um investimento significativo para garantir a resiliência do aplicação web.
Identificar as aplicações mais críticas, onde envidar mais esforços e onde fazer compensações é tão importante quanto ser capaz de avaliar a resiliência de uma aplicação na produção. Para entender melhor o impacto da deficiência, você pode realizar uma análise de impacto nos negócios (BIA). Uma BIA fornece uma abordagem estruturada e sistemática para identificar e priorizar aplicações comerciais essenciais, avaliar possíveis riscos e impactos e identificar dependências de suporte. A BIA ajuda a quantificar o custo do tempo de inatividade das aplicações mais importantes da sua organização. Essa métrica ajuda a definir quanto custará se uma aplicação específica tiver uma deficiência e for incapaz de concluir sua função. No exemplo anterior, se a aplicação de gerenciamento de pedidos estiver com uma deficiência, o negócio de varejo poderá perder uma receita significativa.
Mapeamento de histórias de usuários
Durante o processo da BIA, você pode descobrir que uma aplicação é responsável por mais de uma função de negócios, ou que uma função de negócios exige várias aplicações. Usando o exemplo anterior de uma empresa de varejo, a função de gerenciamento de pedidos pode exigir aplicações separadas para a finalização da compra, promoções e preços. Se uma aplicação falhar, o impacto poderá ser sentido pela empresa e pelos usuários que interagem com a empresa. Por exemplo, talvez a empresa não consiga incluir novos pedidos, fornecer acesso a promoções e descontos ou atualizar o preço de seus produtos. Essas diferentes funções exigidas pela função de gerenciamento de pedidos podem depender de várias aplicações. Essas funções também podem ter várias dependências externas, o que torna o processo de obtenção de resiliência puramente focada em componentes muito complexo. A melhor maneira de lidar com esse cenário é focar as histórias de usuários
Concentrar-se nas histórias de usuários ajuda você a entender quais partes da experiência do cliente são mais importantes, para que você possa criar mecanismos de proteção contra ameaças específicas. No exemplo anterior, uma história de usuário poderia ser a finalização da compra, que envolve a aplicação de finalização de compras e depende da aplicação de preços. Outra história de usuário pode ser a visualização de promoções, que envolve a aplicação de promoções. Depois de mapear as aplicações mais críticas e suas histórias de usuários, você pode começar a definir as métricas que usará para avaliar a resiliência dessas histórias de usuários. Essas métricas podem ser aplicadas em todo um portfólio ou em histórias de usuários individuais.
Definição das medidas
Objetivos de ponto de recuperação (RPOs), objetivos de tempo de recuperação (RTOs) e objetivos de serviço (SLOs) são medidas padrão do setor usadas para avaliar a resiliência de um determinado sistema. O RPO refere-se à quantidade de perda de dados que a empresa pode tolerar em caso de falha, enquanto o RTO é uma medida da velocidade com que uma aplicação deve estar disponível novamente após uma interrupção. Essas duas métricas são medidas em unidades de tempo: segundos, minutos e horas. Você também pode mensurar o tempo durante o qual a aplicação está funcionando corretamente, ou seja, se ela executa suas funções conforme projetada e se está acessível aos usuários. Esses SLOs detalham o nível esperado de serviço que os clientes receberão e são mensurados por métricas como a porcentagem (%) de solicitações atendidas sem erros em um tempo de resposta inferior a um segundo (por exemplo, 99,99% das solicitações receberão uma resposta todos os meses). O RPO e o RTO estão relacionados às estratégias de recuperação de desastres, supondo que haverá interrupções na operação da aplicação e nos processos de recuperação que vão desde a restauração de backups até o redirecionamento do tráfego do usuário. Os SLOs são resolvidos por meio da implementação de controles de alta disponibilidade, que tendem a reduzir o tempo de inatividade de uma aplicação.
As métricas de SLO são comumente usadas na definição de acordos de serviço (SLAs), que são contratos entre os provedores de serviços e os usuários finais. Os SLAs geralmente vêm com compromissos financeiros e estabelecem penalidades que precisam ser pagas pelo provedor se esses acordos não forem cumpridos. No entanto, um SLA não é uma medida de sua postura de resiliência, e aumentar um SLA não torna sua aplicação mais resiliente.
Você pode começar a definir seus objetivos com base em SLOs, RPOs e RTOs. Depois de definir seus objetivos de resiliência e obter uma compreensão clara de suas metas de RPO e RTO, você pode usar o AWS Resilience Hub
Criação de medidas adicionais
RPO, RTO e SLOs são bons indicadores de resiliência, mas você também pode considerar as metas sob o ponto de vista comercial e definir objetivos com base nas funções da sua aplicação. Por exemplo, seu objetivo pode ser: os pedidos com êxito por minuto permanecerão acima de 98% se a latência entre meu frontend e backend aumentar em 40%. Ou: os fluxos iniciados por segundo permanecerão dentro de um desvio padrão da média, mesmo se um componente específico for perdido. Você também pode criar objetivos para reduzir o tempo médio de recuperação (MTTR) em todos os tipos de falha conhecidos. Por exemplo: os tempos de recuperação serão reduzidos em x% se algum desses problemas conhecidos ocorrer. A criação de objetivos alinhados a uma necessidade comercial ajuda você a antecipar os tipos de falhas que sua aplicação deve tolerar. Também ajuda a identificar abordagens para reduzir a probabilidade de deficiência da sua aplicação.
Se você considerar o objetivo de continuar operando se perder 5% das instâncias que alimentam sua aplicação, você pode determinar que sua aplicação deve ser pré-escalada ou ter a capacidade de escalar com rapidez suficiente para suportar o tráfego adicional causado durante esse evento. Ou você pode determinar que deve aproveitar diferentes padrões de arquitetura, conforme descrito na seção Etapa 2: projetar e implementar.
Você também deve implementar medidas de observabilidade para seus objetivos comerciais específicos. Por exemplo, você pode acompanhar a taxa média de pedidos, o preço médio dos pedidos, o número médio de assinaturas ou outras métricas que podem fornecer insights sobre a integridade da empresa com base no comportamento da sua aplicação. Ao implementar recursos de observabilidade para sua aplicação, você pode criar alarmes e agir se essas métricas excederem os limites definidos. A observabilidade é abordada com mais detalhes na seção Etapa 4: operar.
