Princípios de conceção de fiabilidade
As interrupções e as avarias são sérias preocupações para todas as cargas de trabalho. Uma carga de trabalho fiável tem de sobreviver a esses eventos e continuar a fornecer consistentemente a funcionalidade pretendida. Tem de ser resiliente para que possa detetar, suportar e recuperar de falhas num período de tempo aceitável. Também tem de estar disponível para que os utilizadores possam aceder à carga de trabalho durante o período de tempo prometido ao nível de qualidade prometido.
Não é realista assumir que não ocorrerão falhas, especialmente quando a carga de trabalho é criada para ser executada em sistemas distribuídos. Alguns componentes podem falhar enquanto outros continuam a operar. A dada altura, a experiência do utilizador pode ser afetada, o que compromete os objetivos empresariais.
As arquiteturas de cargas de trabalho devem ter garantias de fiabilidade no código da aplicação, na infraestrutura e nas operações. As escolhas de estrutura não devem alterar a intenção especificada pelos requisitos empresariais. Tais alterações devem ser consideradas desvantagens significativas.
Os princípios de conceção destinam-se a fornecer orientações para aspetos de fiabilidade que deve considerar ao longo do ciclo de vida de desenvolvimento. Comece com as abordagens recomendadas e justifique os benefícios de um conjunto de requisitos. Depois de definir a sua estratégia, impulsione as ações com a lista de verificação Fiabilidade.
Se não aplicar estes princípios à sua estrutura, a carga de trabalho provavelmente não estará preparada para antecipar ou lidar com problemas na produção. O resultado pode ser interrupções de serviço que levam a perdas financeiras. No caso de cargas de trabalho críticas, a não aplicação destes princípios pode comprometer a segurança.
Requisitos de conceção para empresas
Reúna os requisitos empresariais com foco no utilitário pretendido da carga de trabalho. |
---|
Os requisitos têm de abranger a experiência do utilizador, os dados, os fluxos de trabalho e as características exclusivas da carga de trabalho. O resultado do processo de requisitos tem de indicar claramente as expectativas. Os objetivos têm de ser alcançáveis e negociados com a equipa, tendo em conta um investimento especificado. Têm de ser documentados para impulsionar opções tecnológicas, implementações e operações.
Abordagem | Vantagem |
---|---|
Quantifique o sucesso ao definir destinos em indicadores para componentes individuais, fluxos de sistema e o sistema como um todo. Esses destinos tornam os fluxos de utilizador mais fiáveis? | As métricas quantificam as expectativas. Permitem-lhe compreender as complexidades e determinar se os custos a jusante dessas complexidades estão dentro do limite de investimento. Os valores de destino indicam um estado ideal. Pode utilizar os valores como limiares de teste que o ajudam a detetar desvios desse estado e quanto tempo demora a regressar ao estado de destino. Os requisitos de conformidade também têm de ter resultados previsíveis para fluxos no âmbito. Atribuir prioridades a estes fluxos chama a atenção para as áreas mais sensíveis. |
Compreender os compromissos da plataforma. Considere os limites, quotas, regiões e restrições de capacidade dos serviços . | Os contratos de nível de serviço (SLAs) variam consoante o serviço. Nem todos os serviços e funcionalidades são abordados de forma igual. Nem todos os serviços ou funcionalidades estão disponíveis em todas as regiões. A maioria dos limites de recursos da subscrição são por região. Ter uma boa compreensão da cobertura e dos limites pode ajudá-lo a detetar mecanismos de recuperação e resiliência. |
Determine as dependências e o respetivo efeito na resiliência. | Manter um registo de infraestruturas dependentes, serviços, APIs e funções desenvolvidas por outras equipas ou terceiros ajuda-o a determinar se a carga de trabalho pode funcionar na ausência dessas dependências. Também o ajuda a compreender as falhas em cascata e a melhorar as operações a jusante. Os programadores podem implementar padrões de design resilientes para lidar com potenciais falhas quando utiliza serviços externos que podem ser suscetíveis a falhas. |
Design para resiliência
A carga de trabalho tem de continuar a funcionar com funcionalidades completas ou reduzidas. |
---|
Deverá esperar que ocorram avarias no componente, falhas na plataforma, degradaçãos do desempenho, disponibilidade limitada de recursos e outras falhas. Crie resiliência no sistema para que seja tolerante a falhas e possa degradar-se corretamente.
Abordagem | Vantagem |
---|---|
Distinguir os componentes que estão no caminho crítico daqueles que podem funcionar num estado degradado. | Nem todos os componentes da carga de trabalho têm de ser igualmente fiáveis. Determinar a importância ajuda-o a conceber de acordo com a importância de cada componente. Não irá sobrecarregar a resiliência dos componentes que possam deteriorar ligeiramente a experiência do utilizador, ao contrário dos componentes que podem causar problemas ponto a ponto se falharem. A estrutura pode ser eficiente na alocação de recursos a componentes críticos. Também pode implementar estratégias de isolamento de falhas para que, se um componente não crítico falhar ou entrar num estado degradado, possa ser isolado para evitar falhas em cascata. |
Identifique potenciais pontos de falha no sistema, especialmente para os componentes críticos, e determine o efeito nos fluxos de utilizador. | Pode analisar os casos de falha, o raio de explosão e a intensidade da falha: indisponibilidade total ou parcial. Esta análise influencia a conceção de capacidades de processamento de erros ao nível do componente. |
Crie capacidades de auto-preservação com padrões de estrutura corretamente e modularize a estrutura para isolar falhas. | O sistema poderá impedir que um problema afete os componentes a jusante. O sistema poderá mitigar falhas transitórias e permanentes, estrangulamentos de desempenho e outros problemas que possam afetar a fiabilidade. Também poderá minimizar o raio da explosão. |
Adicione a capacidade de aumentar horizontalmente os componentes críticos (aplicação e infraestrutura) ao considerar as restrições de capacidade dos serviços nas regiões suportadas. | A carga de trabalho será capaz de lidar com picos e flutuações de capacidade variável. Esta capacidade é crucial quando existe uma carga inesperada no sistema, como um aumento na utilização válida. Se a carga de trabalho for concebida para aumentar horizontalmente em várias regiões, pode mesmo superar potenciais restrições temporárias de capacidade de recursos ou outros problemas que afetam uma única região. |
Crie redundância em camadas e resiliência em vários escalões de aplicação. Aponte para redundância em utilitários físicos e replicação imediata de dados. Também visam a redundância na camada funcional que abrange serviços, operações e pessoal. |
A redundância ajuda a minimizar pontos únicos de falha. Por exemplo, se existir um componente, zonal ou indisponibilidade regional, a implementação redundante (ativa-ativa ou ativa-passiva) permite-lhe cumprir os objetivos de tempo de atividade. A adição de intermediários impede a dependência direta entre componentes e melhora a memória intermédia. Ambos os benefícios endurecem a resiliência do sistema. |
Sobreaprovisionar para mitigar imediatamente falhas individuais de instâncias redundantes e para intermédia contra o consumo de recursos em fuga. | Um maior investimento no sobreaprovisionamento aumenta a resiliência. O sistema continuará a funcionar em serviços públicos completos durante uma falha ativa mesmo antes de as operações de dimensionamento poderem começar a remediar a falha. Da mesma forma, pode reduzir o risco de consumo inesperado de recursos em fuga, reclamando a memória intermédia planeada, ganhando tempo de triagem crítico, antes que ocorram falhas no sistema ou dimensionamento agressivo. |
Estrutura para recuperação
A carga de trabalho tem de ser capaz de antecipar e recuperar da maioria das falhas, de todas as magnitudes, com interrupções mínimas na experiência do utilizador e nos objetivos empresariais. |
---|
Mesmo os sistemas altamente resilientes precisam de abordagens de preparação após desastre, tanto no design da arquitetura como nas operações de carga de trabalho. Na camada de dados, deve ter estratégias que possam reparar o estado da carga de trabalho em caso de danos.
Abordagem | Vantagem |
---|---|
Tem planos de recuperação estruturados, testados e documentados que estão alinhados com os objetivos de recuperação negociados. Os planos têm de abranger todos os componentes para além do sistema como um todo. | Um processo bem definido leva a uma recuperação rápida que pode impedir um impacto negativo nas finanças e na reputação do seu negócio. A realização de exercícios de recuperação regulares testa o processo de recuperação de componentes do sistema, dados e passos de ativação pós-falha e reativação pós-falha para evitar confusões quando o tempo e a integridade dos dados são medidas fundamentais de sucesso. |
Certifique-se de que pode reparar dados de todos os componentes com estado dentro dos destinos de recuperação. | As cópias de segurança são essenciais para colocar o sistema novamente num estado de funcionamento através de um ponto de recuperação fidedigno, como o último bom estado conhecido. Cópias de segurança imutáveis e consistentes de forma transacional garantem que os dados não podem ser alterados e que os dados restaurados não estão danificados. |
Implemente capacidades automatizadas de auto-recuperação na estrutura. | Esta automatização reduz os riscos de fatores externos, como a intervenção humana, e reduz o ciclo de correção de interrupção. |
Substitua os componentes sem estado por unidades efémeras imutáveis. | Criar unidades efémeras que pode girar e destruir a pedido proporciona repetibilidade e consistência. Utilize modelos de implementação lado a lado para tornar a transição para as novas unidades incremental, minimizando as interrupções. |
Estrutura para operações
Mude para a esquerda nas operações para antecipar as condições de falha. |
---|
Teste falhas precoces e frequentemente no ciclo de vida de desenvolvimento e determine o impacto do desempenho na fiabilidade. Para efeitos de análise da causa raiz e pós-morte, precisa de ter visibilidade partilhada, entre equipas, do estado de dependência e das falhas contínuas. As informações, diagnósticos e alertas de sistemas observáveis são fundamentais para uma gestão eficaz de incidentes e uma melhoria contínua.
Abordagem | Vantagem |
---|---|
Crie sistemas observáveis que podem correlacionar a telemetria. | A monitorização e os diagnósticos são operações cruciais. Se algo falhar, terá de saber que falhou, quando falhou e por que motivo falhou. A observabilidade ao nível do componente é fundamental, mas a observabilidade agregada de componentes e fluxos de utilizador correlacionados fornece uma vista holística do estado de funcionamento. Estes dados são necessários para permitir que os engenheiros de fiabilidade do site priorizem os seus esforços de remediação. |
Prever potenciais avarias e comportamento anómalo. Torne visíveis falhas de fiabilidade ativas com alertas priorizados e acionáveis. Invista em processos e infraestruturas fiáveis que conduzem a uma triagem mais rápida. |
Os engenheiros de fiabilidade do site podem ser notificados imediatamente para que possam mitigar incidentes em direto em curso e mitigar proativamente potenciais falhas identificadas por alertas preditivos antes de se tornarem incidentes em direto. |
Simular falhas e executar testes em ambientes de produção e pré-produção. | É vantajoso experimentar falhas na produção para que possa definir expectativas realistas de recuperação. Isto permite-lhe fazer escolhas de estrutura que respondam corretamente a falhas. Além disso, permite-lhe testar os limiares que definiu para as métricas empresariais. |
Crie componentes com a automatização em mente e automatize o máximo possível. | A automatização minimiza o potencial de erro humano, o que dá consistência aos testes, à implementação e às operações. |
Factor nas operações de rotina e o seu impacto na estabilidade do sistema. | A carga de trabalho pode estar sujeita a operações em curso, como revisões de aplicações, auditorias de segurança e conformidade, atualizações de componentes e processos de cópia de segurança. Escrutinar essas alterações garante a estabilidade do sistema. |
Aprenda continuamente com os incidentes em produção. | Com base nos incidentes, pode determinar o impacto e as supervisões na conceção e operações que podem passar despercebidas na pré-produção. Em última análise, poderá impulsionar melhorias com base em incidentes da vida real. |
Mantenha-o simples
Evite sobrecarregar o design da arquitetura, o código da aplicação e as operações. |
---|
Muitas vezes, é o que remove, em vez do que adiciona, o que leva às soluções mais fiáveis. A simplicidade reduz a área da superfície para controlo, minimizando ineficiências e potenciais configurações incorretas ou interações inesperadas. Por outro lado, a simplificação excessiva pode introduzir pontos únicos de falha. Manter uma abordagem equilibrada.
Abordagem | Vantagem |
---|---|
Adicione componentes à sua arquitetura apenas se o ajudarem a alcançar valores empresariais de destino. Mantenha o caminho crítico inclinado. | A conceção de requisitos empresariais pode levar a uma solução simples que é fácil de implementar e gerir. Evite ter demasiados componentes críticos, porque cada um deles é um ponto significativo de falha. |
Estabeleça normas na implementação, implementação e processos de código e documente-os. Identificar oportunidades para impor essas normas através de validações automatizadas. | As normas fornecem consistência e minimizam os erros humanos. Abordagens como convenções de nomenclatura padrão e guias de estilo de código podem ajudá-lo a manter a qualidade e tornar os recursos fáceis de identificar durante a resolução de problemas. |
Avalie se as abordagens teóricas se traduzem num design pragmático que se aplica aos seus casos de utilização. | O código da aplicação demasiado granular pode levar a interdependência desnecessária, operações adicionais e manutenção difícil. |
Desenvolva código suficiente. | Poderá evitar problemas que resultem de implementações ineficientes, como consumo inesperado de recursos, falhas de utilizadores ou fluxos de dados e erros de código. Por outro lado, os problemas de fiabilidade devem levar a revisões de código para garantir que o código é suficientemente resiliente para lidar com os problemas. |
Tire partido das funcionalidades fornecidas pela plataforma e dos recursos pré-criados que podem ajudá-lo a cumprir os objetivos empresariais de forma eficaz. | Esta abordagem minimiza o tempo de desenvolvimento. Também lhe permite depender de práticas experimentadas e testadas que foram utilizadas com cargas de trabalho semelhantes. |