resiliência no design para serviços em nuvem · pdf file2 “recovery...

Resiliência no design para serviços em nuvem Uma metodologia estruturada para priorizar investimentos de engenharia Maio de 2013

Resumo Visão geral 2

Histórico 2

Vantagens 4

Como funciona a análise e a modelagem da resiliência 5

Considerações sobre implementação 16

Em busca de uma ação 18

Conclusão 18

Recursos adicionais 20

Autores e colaboradores 20

Computação confiável | Resiliência no design para serviços em nuvem 2

Visão geral O Microsoft Trustworthy Computing (TwC) colaborou com inúmeras equipes de serviços em nuvem da Microsoft para desenvolver uma abordagem para aumentar a resiliência do serviço em nuvem, identificando e analisando possíveis falhas. Este artigo resume a motivação e os benefícios de incorporar um design de resiliência robusto ao ciclo de desenvolvimento. Ele descreve a Resilience Modeling and Analysis (RMA), uma metodologia para melhorar a resiliência adaptada da técnica de padrão industrial conhecida como Failure Mode and Effects Analysis (FMEA)1, e fornece uma orientação para implementação. O principal objetivo deste artigo é equipar os engenheiros de serviços em nuvem com uma compreensão detalhada da RMA, incluindo as etapas e os modelos usados para concluir o processo, para permitir uma adoção fácil e consistente.

Histórico O desenvolvimento de software tradicionalmente enfatizava a prevenção contra falhas e, como os clientes operavam os softwares, quaisquer falhas eram isoladas nas implantações locais dos clientes. Hoje, os serviços em nuvem costumam executar sistemas altamente complexos, distribuídos, “sempre disponíveis” e que atendem a diversos clientes. Os sistemas de nuvem são globalmente distribuídos, em geral construídos com o uso de hardware de commodity, e contam com serviços de terceiros e parceiros. A natureza da Internet e das redes globais é de que falhas temporárias e até prolongadas sejam bastante comuns. Por isso, os engenheiros precisam mudar de ideia para adotar práticas de Computação orientada à recuperação (ROC),2 adotar totalmente a ideia de que falhas irão acontecer e, portanto, incorporar estratégias de controle em seus serviços e software para minimizar os efeitos prejudiciais dessas falhas. A figura a seguir mostra um espectro de falhas, que variam de infrequentes (desastres ambientais naturais ou provocados pelo homem) a comuns (imperfeições nos softwares, falhas de hardware ou erros humanos). Como as falhas comuns são inevitáveis, sua ocorrência e impacto precisam ser circunstanciados em serviços durante a fase de design para que os softwares possam ser projetados e implantados de maneira mais resiliente e para que o impacto sobre os usuários seja mínimo.

1 A Failure Mode and Effects Analysis também é conhecida como Failure Mode, Effects, and Criticality Analysis (FMECA). 2 “Recovery Oriented Computing (ROC): Motivation, Definition, Techniques, and Case Studies” http://roc.cs.berkeley.edu/papers/ROC_TR02-1175.pdf


Figura 1. O espectro de falhas varia de falhas comuns a falhas infrequentes. As falhas são inevitáveis, então as técnicas de tolerância a falhas devem ser incorporadas ao design do serviço para reduzir o impacto quando elas acontecerem.

Se adotarmos a ideia de que as falhas são esperadas no mundo dos serviços em nuvem, os engenheiros deverão mudar sua ênfase de projetar tempo estendido entre falhas (TBF) para projetar a redução do tempo de recuperação (TTR) após as falhas. Se as falhas forem triviais, o objetivo mais importante será detectá-las rapidamente e desenvolver estratégias de controle que minimizem os efeitos sobre os clientes. Os conceitos do processo de padrão industrial conhecido como FMEA foram adaptados na tentativa de criar uma metodologia de Resilience Modeling and Analysis (RMA) para equipes de serviços em nuvem na Microsoft. Essa metodologia tem como finalidade priorizar, com mais eficiência, o trabalho nas áreas de detecção, mitigação e recuperação após falhas, todos eles fatores significativos na redução do TTR. Ao concluir a RMA, a equipe de engenharia poderá pensar nos problemas de confiabilidade com detalhes e se equipar melhor para assegurar que, quando as falhas acontecerem, os impactos sobre os clientes sejam mínimos. O FMEA é uma estrutura flexível para realizar análises de falhas qualitativas em sistemas industriais e computacionais. Possíveis falhas são identificadas, e as consequências delas são analisadas de forma a avaliar o risco.

Software Hardware Erro humano

Desastre natural Interrupção dos dados Atividades criminais

Técnicas de tolerância a falhas

Técnicas de recuperação de

desastres


Vantagens Adotar a RMA é um benefício para as equipes de engenharia de serviços em nuvem, pois ela incentiva as práticas recomendadas a seguir, todas elas aprimorando a confiabilidade do serviço.

Tratar problemas de confiabilidade com antecedência na fase de design

O principal objetivo e benefício da RMA é descobrir gaps de resiliência e projetar explicitamente sua detecção e mitigação antes que o código seja enviado para a produção (onde já se torna mais caro alterar e atualizar). A RMA pode ser codificada no ciclo de vida do desenvolvimento e praticada pelas organizações de engenharia de serviços em nuvem para se tornar uma competência importante, que introduzirá os princípios de ROC nas equipes de engenharia para que elas se mantenham consistentemente focadas na redução do tempo de detecção, mitigação e recuperação após as falhas. Depois que o serviço está em produção, continuar aplicando a metodologia RMA permite que a organização de engenharia aplique qualquer conhecimento que seja adquirido até o próximo ciclo de engenharia.

Priorizar iniciativas de trabalho relacionadas à confiabilidade

O principal objetivo da RMA é identificar e produzir uma lista priorizada de falhas de confiabilidade comuns, relevantes a determinado serviço. Os participantes entendem que a recuperação após falhas deve preceder em relação à sua prevenção. Geralmente, os serviços em nuvem complexos estão sujeitos a uma miríade de condições de falhas e costuma ser difícil para as equipes saber onde devem investir seus esforços para reduzir o impacto dessas falhas. Essa questão costuma ser capciosa para equipes cujos serviços consomem componentes ou serviços de diversos proprietários ou terceiros, ou ainda de provedores de serviços. A RMA ajuda a priorizar e informar as decisões sobre investimentos em áreas de detecção, mitigação e recuperação.

Fornecer resultados tangíveis para outras iniciativas de confiabilidade

O processo de RMA produz resultados tangíveis que podem ser usados para outras iniciativas voltadas para a confiabilidade. Equipes de parceiros, operações de serviços e equipes de suporte podem entender melhor como o software de produção é instanciado, aproveitando o diagrama de interação de componentes (CID), criado durante a fase inicial do processo de RMA. Ele propõe um eixo diferente dos diagramas comuns de arquitetura ou design frequentemente encontrados nas especificações de desenvolvimento tradicionais.


A lista de falhas priorizadas é concretamente mapeada para os itens e correções de códigos. Trata-se ainda de um excelente recurso para a organização de testes ajudar a desenvolver casos de testes. Esses mapas sugerem uma noção de lugares no sistema em que as práticas de3 injeção de falhas possam ser mais bem aplicadas para validar a eficiência das mitigações de falhas.

Como funciona a análise e a modelagem da resiliência O processo de análise e modelagem da resiliência (RMA) é realizado em quatro fases, mostradas e descritas na figura a seguir e nos pontos de marcação:

Figura 2. Fases do processo de RMA

• Pré-trabalho. Cria um diagrama para capturar recursos, dependências e interações entre componentes.

• Descoberta. Identifica falhas e gaps de resiliência. • Classificação. Realiza a análise de impacto. • Ação. Produz itens de trabalho para melhorar a resiliência.

Pré-trabalho São realizadas duas tarefas durante essa fase da análise. A primeira é criar um diagrama de interação de componentes (CID); a segunda é transferir todas as interações do diagrama para o modelo de pasta de trabalho de RMA. A principal finalidade desta fase é capturar todos os recursos e as interações entre eles. Essas interações serão usadas para se concentrar na enumeração das falhas na fase de Descoberta. As duas tarefas nesta fase devem ser realizadas antes de prosseguir para a fase de Descoberta.

Tarefa1:CriaroCID

Para o sucesso do processo RMA, é importantíssimo gerar um diagrama abrangente e de alta qualidade nesta tarefa. Se faltarem recursos ou interações no diagrama, poderão faltar falhas, diminuindo assim o valor do exercício. Os desenvolvedores dos recursos de componentes modelados no diagrama são as principais pessoas a precisar dessa tarefa. 3 O exemplo canônico de testes de injeção de falhas é a ferramenta de resiliência do Netflix, conhecida como Chaos Monkey.

Descoberta Classificação

Ação

Pré‐trabalho


Os engenheiros podem questionar qual o nível de detalhes necessário para o diagrama, mas não existe um número de corte claro a ser seguido. A resposta dependerá do fato de as equipes terem escolhido o escopo de um exercício referente a um cenário de ponta a ponta, dos limites dos serviços em nuvem ou dos componentes.4 Entretanto, aplicam-se algumas regras gerais: • Não inclua hardware físico. Os serviços em nuvem costumam ser compostos de funções de

servidor, nos quais geralmente existem diversas instâncias. Na maioria dos casos, não parece produtivo representar componentes de servidor, como discos, placas de rede, processadores etc. Embora ocorram falhas com esses componentes, o impacto e a frequência delas são muito bem compreendidos. Caso uma falha desse tipo afete a capacidade de funcionamento de um recurso, os efeitos serão percebidos na interação do chamador do recurso na forma de um erro ou simplesmente de uma falta de resposta. Da mesma maneira, componentes de rede, como roteadores, comutadores e balanceadores de carga, são todos pontos de falha, mas não precisam ser delineados no diagrama. Outros detalhes são apresentados no texto a seguir sobre como capturar informações relevantes sobre falhas para esses tipos de dispositivos/componentes.

• Enumerar instâncias é importante. O número de unidades funcionais é extremamente importante para a modelagem da confiabilidade. Redundância é uma das técnicas de resiliência primárias aplicadas em todas as camadas de um serviço em nuvem. O número de regiões geográficas em que seu serviço existe, o número de data centers dentro de determinada região e o número de funções de servidor e instâncias são importantes atributos para capturar. Essas informações são usadas para determinar a probabilidade de que determinada falha de interação afete os clientes.

• Inclua todas as dependências. Os serviços em nuvem apresentam muitas dependências, desde a resolução de nome até a autenticação, o processamento e o armazenamento de dados. Em geral, esses serviços são fornecidos por sistemas que não são de propriedade da equipe do serviço em nuvem, mas são críticos para o funcionamento correto do serviço. Cada um dos sistemas de dependência deve ser representado no diagrama, com as interações apropriadas entre eles e seus componentes do serviço em nuvem claramente representados. No entanto, a composição dos sistemas de dependência pode ser ocultada ao desenhá-los no diagrama como uma única forma fora do data center (se o serviço estiver disponível na Internet) ou uma única forma dentro de cada data center (se o serviço for fornecido localmente no data center). Se as informações do contrato de nível de serviço (SLA) forem conhecidas para o sistema de dependência, isso deverá ser percebido também no diagrama.

4 Consulte a subseção “Abordagem”, mais adiante neste artigo, para obter informações sobre como montar o escopo do exercício.


A maioria das equipes tem um diagrama de serviço baseado nos documentos de design ou arquitetura. Além disso, as equipes que já praticam a modelagem de ameaças à segurança, conforme descrito no Microsoft Security Development Lifecycle (SDL)5, terão diagramas de fluxo de dados Nível 0 como referência. Os dois tipos de diagramas são bons pontos de partida; no entanto, às vezes faltam algumas—ou todas as—interações necessárias para um CID completo. A Computação confiável criou documentos CID de exemplo6 para ajudar as equipes a construir seu próprio CID. Esses documentos de exemplo incluem diversas formas e conexões que fornecem dicas visuais para ajudar as equipes a analisar falhas posteriormente no processo. A figura a seguir é um CID de exemplo referente a um serviço em nuvem simples chamado Contoso,7 que coleta informações de clientes da Internet, transforma essas informações usando serviços de terceiros e armazena os dados finais na nuvem.

Figura 3. Diagrama de exemplo de interação entre componentes (CID)

As figuras a seguir fornecem uma visão mais aproximada de algumas das formas que sugerem dicas visuais de brainstorm sobre falhas encontradas na fase de Descoberta:

5 Microsoft Security Development Lifecycle (SDL) www.microsoft.com/sdl 6 Consulte a seção “Recursos adicionais”, no final deste artigo, para conhecer links que levam a documentos de exemplo. 7 Este diagrama não usa todas as formas disponíveis no estêncil do Visio do CID; entretanto, esse estêncil contém uma legenda completa com descrição de cada forma.


• Setas e números das interações. As partes mais importantes de informações são as

interações entre componentes, analisadas na fase de Descoberta para explorar todas as diferentes falhas que possam ser encontradas. As interações são todas identificadas por um número, que será transferido para a pasta de trabalho da RMA.

• Certificados. A forma do certificado é usada para realçar instâncias em que os certificados são necessários. As falhas relacionadas aos certificados são frequentes pontos de falha. Observe como os certificados no diagrama são codificados por cores para se associar à interação correspondente.

• Sinal de produção. O sinal de produção

indica que este recurso emprega a limitação, indicando que um chamador pode encontrar falhas nas interações com este recurso quando existe um atraso intencional do serviço.


• Cache. Observe a forma de cache local em verde, incluída nas instâncias do receptor. O caching é uma mitigação comum contra falhas e, neste caso, se o Serviço do receptor não conseguir prosperar (pela interação 7) em armazenar resultados no banco de dados, ele armazenará em cache os dados localmente até que a conexão com o banco de dados seja restabelecida.

• Domínios de falhas. O seguinte diagrama de exemplo representa as funções de servidor de

vários tipos. Cada tipo de função usa uma identificação especial para capturar informações sobre diferentes domínios de falhas. O conceito dos domínios de falhas é familiar a todos que tenham desenvolvido serviços em nuvem no Windows Azure. O usuário escolhe o número de domínios de falhas para suas instâncias de funções, e a infraestrutura subjacente do Windows Azure garante que as instâncias das funções sejam listadas entre racks de servidor, comutadores e roteadores, de forma que uma falha na camada inferior da infraestrutura não afete mais do que um domínio de falha. Ao abordar as falhas para instâncias de funções, essas informações são importantes, pois influenciam diretamente a magnitude do impacto de que uma falha desse tipo terá sobre um tipo de função do Azure. Para serviços em nuvem criados em um modelo de hospedagem tradicional em data center, é possível aplicar esse mesmo conceito de domínios de falhas à infraestrutura adjacente para avaliar impactos sobre a função do servidor. Além disso, é possível medir o nível de impacto das falhas nesses componentes, simplesmente observando o número de domínios de falhas de cada tipo.


Neste diagrama, observe que todas as instâncias de função de servidor do receptor estão conectadas a um par de roteadores, um par de balanceadores de carga, além de estarem listadas entre cinco comutadores do rack. Essas informações ajudam a transmitir o impacto para a função do receptor caso ocorra uma falha em alguma dessas camadas da infraestrutura.

Depois que o diagrama de interação entre componentes é concluído, a equipe de engenharia pode passar para a segunda tarefa da fase de Pré-trabalho.

Tarefa2:TransferirasinteraçõesdodiagramaparaapastadetrabalhodaRMA

A segunda tarefa na fase de Pré-trabalho transfere os números de interação do CID para a pasta de trabalho da RMA para criar a lista principal de interações, usada durante a fase de Descoberta para enumerar diversos tipos de falhas que possam ser encontradas durante cada interação. As interações numeradas são inseridas na pasta de trabalho da RMA. Entre as informações necessárias estão o ID, um nome abreviado (geralmente especificando o chamador e o respondente) e uma descrição da própria interação. O exemplo de uma pasta de trabalho a seguir inclui informações do diagrama do serviço Contoso, já abordado na Tarefa 1. Identificação Interação

componente/dependência Descrição da interação

1 Cliente de Internet -> Serviço de ingestão

Os clientes usuários finais se conectam pelo ponto de extremidade do lado da Internet das funções Web do Contoso Azure Service Ingestion e carregam os dados.

2 Funções de ingestão -> Tabela de armazenamento do Azure

As Instâncias de ingestão armazenam os dados carregados do cliente na Tabela de armazenamento do Azure.

3 Funções de ingestão -> Fila de armazenamento do Azure

As Instâncias de ingestão enviam uma mensagem para a Fila de armazenamento do Azure com uma indicação para os dados do cliente armazenados na Tabela de armazenamento do Azure.

4 Funções do receptor -> Fila de armazenamento do Azure

As Instâncias do receptor enviam a mensagem para a Fila de armazenamento do Azure, que contém uma indicação para os dados do cliente armazenados na Tabela de armazenamento do Azure.

5 Funções do receptor -> Tabela de armazenamento do Azure

As Instâncias do receptor enviam os dados carregados do cliente da Tabela de armazenamento do Azure.

6 Funções do receptor -> Processamento externo

As Instâncias do receptor enviam os dados carregados do cliente para o Serviço de processamento externo para fins de transformação dos dados.

7 Funções do receptor -> Banco de dados SQL do Azure

As Instâncias do receptor enviam os dados transformados do cliente para o Banco de dados SQL do Azure.

Figura 4. Colunas de interações da pasta de trabalho da RMA (exemplo)

Depois de realizar o CID e gravar todas as suas informações de interação entre componentes na pasta de trabalho da RMA, a equipe de engenharia está pronta para iniciar a fase seguinte do processo de RMA, a fase de Descoberta.


Descoberta

A finalidade da fase de Descoberta é enumerar e gravar possíveis falhas de cada interação entre componentes. Esta fase é uma sessão de brainstorm facilitada, geralmente mais eficiente quando todas as disciplinas de engenharia participam ativamente. Os desenvolvedores são participantes fundamentais desse exercício em razão de seu conhecimento profundo sobre o comportamento do sistema quando ocorrem falhas. As informações que podem ser gravadas na pasta de trabalho da RMA durante este exercício são: • ID de interação. Determinado na fase de Pré-trabalho. • Nome da interação. Determinado na fase de Pré-trabalho. • Nome abreviado da falha. Um nome curto para o tipo de falha. • Descrição da falha. Uma descrição mais longa da falha. • Resposta. Informações sobre o tratamento do erro, alertas, mitigação/restauração associados

a esta falha. As informações na coluna Resposta são usadas para analisar os efeitos de cada falha na fase de Classificação, por isso é muito importante capturar todas as informações descritas na lista que precede. O seguinte exemplo se refere ao serviço Contoso, referido neste artigo. Identificação Interação

componente/ dependência

Nome abreviado da falha

Descrição da falha Resposta


Existência:Resolução de nome

A Tabela de armazenamento do Azure pode não conseguir resolver no DNS em períodos prolongados.

As Instâncias de ingestão armazenam em cache localmente os dados do cliente em discos virtuais até que a resolução de nome seja restaurada para a Tabela de armazenamento do Azure. O cache local persiste durante a reinicialização da VM, mas é perdido na destruição da VN. O sistema de alertas ContosoMon dispara um alerta SEV1 para erros de resolução de nome para a tabela de armazenamento do Azure. A interação humana é requerida caso a condição persista além das durações da fila local.


Latência: Sem resposta

A Tabela de armazenamento do Azure pode não responder por períodos prolongados a todas as instâncias da Função de ingestão.

As Instâncias de ingestão armazenam em cache localmente os dados do cliente em discos virtuais até que a Tabela de armazenamento do Azure volte a responder. O cache local persiste durante a reinicialização da VM, mas é perdido na destruição da VM. O sistema de alertas ContosoMon dispara um alerta SEV1 para erros de resolução de nome para a Tabela de armazenamento do Azure. A Interação humana é requerida caso a condição persista além das durações da fila local.

Figura 5. As colunas da pasta de trabalho da RMA usadas durante o exercício de brainstorm de falhas.


Um facilitador é necessário para assegurar que a reunião de brainstorm de falhas seja produtiva e capture o nível correto de detalhe. O CID será usado e referido durante toda a reunião, provavelmente sendo a única coisa mostrada aos participantes durante esta fase. O facilitador registrará as várias falhas identificadas durante a reunião na pasta de trabalho da RMA. Uma boa prática a seguir para a reunião de brainstorm é limitar o tempo a no máximo 90 minutos a fim de evitar cansaço e perda de qualidade. Se depois de 90 minutos nem todas as falhas das interações tiverem sido examinadas, a experiência mostrará que o melhor a fazer será parar e agendar uma segunda sessão para concluir esta fase. Embora o brainstorm possa começar em qualquer interação (como aquela em que todos concordam de sofrer diariamente de problemas de confiabilidade), é melhor partir do ponto lógico de um cenário e depois seguir a ordem natural das interações a partir daí. O facilitador conduzirá os participantes pela atividade de brainstorm na identificação da maioria das possíveis falhas. Uma pequena estrutura nesta fase percorrerá um longo caminho em direção à garantia de que o exercício é eficiente e ainda abrangente. Para ajudar o facilitador, a Computação confiável desenvolveu uma lista (mostrada na figura a seguir) de falhas comuns que pode ser usada para ajudar a conduzir a conversa de uma forma repetida em cada interação.

Figura 6. Tabela de categorias de falhas para uso durante a fase de Descoberta


As categorias são listadas em sequência lógica de possíveis interações entre componentes. Por exemplo, quando o Componente A faz uma solicitação ao Recurso B, é possível que se encontrem problemas na seguinte sequência lógica: 1. O Recurso B pode não existir ou não ser encontrado. Se for encontrado, 2. O Componente A não consegue se autenticar no B. Se conseguir se autenticar, 3. O Recurso B pode demorar ou deixar de responder à solicitação que o Componente A emitiu,

e assim sucessivamente. A lista que precede não tem a intenção de funcionar como um catálogo completo de todas as falhas possíveis. No entanto, se os participantes pensarem nessas falhas para cada interação e revisarem cada categoria de maneira estruturada, registrar os resultados será mais fácil, e todas as classes de falhas serão menos propensas a se perder. Um ponto muito importante a considerar neste exercício é que as falhas na RMA não equivalem à causa-raiz. Pode haver diversas causas-raízes capazes de levar a uma falha de um recurso, fazendo-o parecer estar offline. Entretanto, em todos os casos assim, o comportamento encontrado pelo chamador é o mesmo: o recurso está offline. A causa-raiz subjacente não influencia a forma como o chamador responderá. Contudo, pode ser vantajoso registrar diversas causas-raízes de um tipo de falha na coluna Descrição da falha para uso posterior, ao determinar a probabilidade do tipo de falha. Depois que as falhas forem completamente enumeradas para todas as interações entre componentes, a equipe de engenharia estará pronta para passar para a fase de Classificação.

Classificação

A finalidade da fase de Classificação é analisar e registrar os efeitos resultantes de cada falha enumerada na fase de Descoberta. Os detalhes registrados para cada tipo de falha na coluna Resposta fornecerão a maior parte do contexto necessário para concluir a tarefa. Este exercício resultará em uma lista de valores de risco calculados para cada tipo de falha, usados como informação para a fase de Ação. Mais uma vez, como na fase de Descoberta, o facilitador conduzirá a reunião, que inclui as mesmas pessoas que participaram da enumeração das falhas. Como antes, recomendamos que a reunião não exceda 90 minutos. Em geral, o facilitador exibe uma pasta de trabalho em uma tela de projeção conforme preenche os dados restantes para cada tipo de falha, usando informações desta reunião. A pasta de trabalho da RMA contém diversas colunas suspensas de seleção que serão preenchidas durante esta fase. A figura a seguir sugere uma visão mais aproximada de cada coluna.


Figura 7. As colunas da pasta de trabalho da RMA usadas durante o exercício de análise de efeitos das falhas

A coluna Risco é um valor calculado, derivado das outras cinco colunas. A ideia por trás desse cálculo é avaliar o risco como produto do impacto e da probabilidade da falha. Probabilidade é um conceito direto, representado por um valor único na pasta de trabalho (selecionado da lista suspensa Probabilidade). No entanto, o impacto de uma falha pode ser decomposto em diversos segmentos. O processo RMA é usado para avaliar o impacto de possíveis falhas durante o design do produto, praticamente da mesma maneira que uma equipe de gerenciamento de problemas avalia o impacto de uma queda de um serviço em nuvem já colocado em produção. As seguintes perguntas essenciais são rotineiramente feitas a respeito do impacto de uma queda: Quais foram os efeitos discerníveis para o usuário ou processo empresarial crítico? Essa

queda foi um problema irrelevante ou impacto sobre o desempenho, ou então algo que impediu a conclusão dos principais cenários de usuário? Qual foi a intensidade do impacto?

Qual foi a magnitude do escopo do impacto? Apenas alguns clientes ou transações foram afetados ou foi o escopo do impacto geral? Qual foi a extensão do impacto?

Quanto tempo levou para que uma pessoa ou sistema automatizado tivesse conhecimento da falha? Qual foi o tempo para detectar (TTD)?

Depois de detectada, quanto tempo levou para recuperar o serviço e restaurar as funcionalidades? Qual foi o tempo para recuperar (TTR)8?

Essas perguntas se aplicam às possíveis falhas na pasta de trabalho RMA, mapeando respectivamente para as colunas Efeitos, Porção afetada, Detecção e Resolução. 8 TTR é o tempo que leva para restaurar a funcionalidade para o cliente, não necessariamente o tempo que leva para que a falha seja totalmente corrigida.


É importante que a equipe de engenharia se lembre de que todas as colunas são completamente independentes uma da outra. O facilitador deve garantir que as avaliações das colunas Efeitos e Porção afetada, em particular, não sejam confundidas durante o exercício. Por exemplo, é perfeitamente aceitável esperar que a equipe analise uma falha que resultaria apenas em uma pequena degradação da qualidade do serviço, embora afetando praticamente todos os usuários do sistema. Contrariamente, a equipe poderia analisar uma falha que afeta apenas um usuário (ou pequena parte do total de transações processadas) no serviço, mas uma falha capaz de trazer sérias consequências em termos de integridade dos dados, incluindo a perda deles. O cálculo numérico das colunas Impacto e Probabilidade é fixo no modelo; os valores suspensos são fixos em três opções9 (quatro, no caso de Efeitos). No entanto, as equipes podem mudar o texto associado das seleções suspensas para refletir melhor as características de seu serviço em nuvem. Por exemplo, os padrões da coluna Detecção de Menos de 5 min, Entre 5 e 15 min e Mais de 15 min podem ser alterados pela equipe com um tempo de detecção de falha do serviço praticamente instantâneo a Menos de 50 milissegundos, Entre 50 e 500 milissegundos e Mais de 500 milissegundos, respectivamente. No início da fase de Classificação, as seleções suspensas de todas essas colunas devem ser revisadas. Quando a análise de efeitos é feita, a fase de Classificação é concluída. A equipe passa a ter uma lista priorizada de falhas para usar como informação para a fase de Ação.

Ação

O propósito desta última fase é tomar providências quanto aos itens descobertos durante a parte de modelagem de resiliência do processo RMA e fazer investimentos tangíveis para aprimorar a confiabilidade do serviço em nuvem. A classificação de riscos das falhas capturadas na pasta de trabalho da RMA durante a fase de Classificação fornece uma orientação sobre a prioridade dos possíveis investimentos de engenharia. Você pode criar itens de acompanhamento avaliando todas as falhas com riscos alto e médio, gerando itens de trabalho para os recursos de engenharia. Algumas vezes é possível transformar falhas de alto risco em falhas de médio risco, reduzindo os valores de tempo para detectar (TTD) ou de tempo para recuperar (TTR). É possível conseguir muitas melhorias nessas duas áreas ao fazer investimentos em sistemas de monitoramento, ou apenas modificando-os. Os itens de trabalho também podem ser considerados para fins de instrumentação e telemetria, detecção e monitoramento, e mitigações que tratam causas-raízes específicas ou aceleram a recuperação. Os itens de trabalho ainda podem introduzir novos casos de teste, que precisarão ser circunstanciados na aplicação de teste no serviço. Os itens de trabalho também podem resultar em solicitações de mudanças arquitetônicas caso a RMA seja realizada com antecedência o suficiente na fase de design. 9 As opções suspensas são expressas como baixa, média e alta para possibilitar que as equipes façam a seleção com mais rapidez sem se preocupar com cálculos de precisão.


Conforme mencionado, um dos principais benefícios que a RMA traz é produzir artefatos que possam ser vantajosos não só para a equipe de recursos, mas também para as equipes de suporte telefônico ou pessoal de operações. Ao desafiar a equipe de engenharia a revalidar a arquitetura e o design durante a fase Pré-trabalho, o CID fornece outras percepções que vão além dos diagramas de design, arquitetura ou construção comumente em uso hoje em dia. A organização de testes pode usar a pasta de trabalho da RMA para se direcionar aos testes de injeção de falhas, já que ela captura metadados sobre a qualidade de resposta de uma interação entre componentes para as falhas no serviço em nuvem. Qualquer componente que incorpore mitigações de falhas pode ser alvo da injeção de falhas para verificar a qualidade e a eficiência dessas mitigações.

Considerações sobre implementação A RMA é uma abordagem simplificada para que as equipes aumentem a resiliência de seu serviço em nuvem, identificando e analisando possíveis falhas. Embora a implementação do processo seja flexível em diversas áreas, as equipes precisam ter cuidado ao levar em conta os tópicos de tempo, abordagem, funções e responsabilidades antes de começar.

Programação

Se a sua equipe estiver acostumada a realizar a modelagem de ameaças à segurança conforme descrito no Microsoft Security Development Lifecycle, você já terá uma boa noção de cadência de RMA. Como nas recomendações para a modelagem de ameaças à segurança, a Computação confiável recomenda revisitar o modelo de resiliência a cada seis meses (não menos do que isso e pelo menos uma vez por ano, definitivamente), sempre que houver mudanças significativas de arquitetura ou funcionalidade ou ao encontrar problemas dinâmicos do site que o impeçam de atender consistentemente às metas de disponibilidade dos clientes. Para os novos serviços, ou serviços que passam por grandes revisões, as equipes devem pensar em implementar a RMA depois que a arquitetura tiver sido mapeada e que o design inicial tiver sido proposto, mas antes que a maior parte do código tenha sido concluída. É mais econômico projetar a resiliência no serviço do que reagir a falhas depois que o serviço já está em operação. As equipes de serviços em nuvem já em produção devem considerar a implementação imediata da RMA; não há necessidade de esperar até uma próxima grande revisão do serviço para iniciar a aplicação da metodologia RMA. A lista de falhas priorizadas gerada pelo processo RMA fornece uma gama de oportunidades para fazer investimentos bem direcionados em instrumentação, detecção, mitigação e recuperação, muitos dos quais podendo ser implementados rapidamente. Além disso, o conhecimento que se adquire por conduzir a análise em um produto já em produção é altamente valioso como informação para os futuros ciclos de planejamento e desenvolvimento. Muitas equipes com serviços que já estão em produção também têm interesse na injeção de falhas. Os resultados do processo RMA fornecem excelentes informações para os testes de injeção de falhas no momento de validar a eficiência das atuais técnicas de mitigação de falhas.


Abordagem

A RMA é flexível o bastante para ser aplicada a qualquer faceta de um serviço em nuvem. Leve em conta cada uma das seguintes variações no escopo ao determinar o investimento em tempo que você pretende fazer em RMA: • Cenário de ponta a ponta. A confiabilidade do serviço deve ser avaliada da perspectiva do

cliente. Consequentemente, as equipes geralmente querem se concentrar em falhas que afetam fluxos de trabalho do usuário ou naquelas em que a organização possa ser mais afetada por incidentes relacionados à confiabilidade. Se você aplicar essa abordagem, priorizará os investimentos de engenharia relacionados à confiabilidade, que são considerados importantes para os consumidores do serviço. No entanto, os cenários de ponta a ponta costumam atravessar muitos limites de componentes e serviços. Para reduzir a necessidade de garantir a participação de tantas pessoas de tantas equipes diferentes, o cenário pode ser dividido em subcenários para que se tenha um nível melhor de aproveitamento.

• Limites dos serviços em nuvem. As equipes costumam se preocupar mais com os problemas de confiabilidade nos limites de seus serviços em nuvem. Esses limites são os pontos de intersecção entre seus componentes dos serviços em nuvem e os serviços fornecidos por terceiros ou parceiros. O exercício da RMA pode ser desenhado de forma que todos os pontos de integração de serviços sejam modelados para falhas. O benefício dessa abordagem é que os pontos de integração residem geralmente onde os serviços são mais suscetíveis a falhas. Além disso, essa abordagem costuma requerer menos participantes para a conclusão do exercício. A desvantagem dessa abordagem é que certos componentes que compreendem cenários de usuários importantes ou fluxos de trabalho essenciais não são modelados o bastante.

• Componente por componente. Uma terceira opção que as equipes podem ter é direcionar a RMA a um pequeno número de componentes do serviço em nuvem de uma vez. Em geral, as equipes começam com componentes que passam por problemas mais ligados à confiabilidade (caso o serviço já esteja em produção) ou com um componente para o qual elas querem introduzir o reconhecimento da confiabilidade logo no início da fase de design. Fazer o escopo do exercício de RMA em um único componente de serviço em nuvem tem o benefício de exigir menos participantes, além de poder ser feito por um custo mais baixo. Essa abordagem é semelhante aos limites de modelagem dos serviços em nuvem, mas para os componentes. Fluxos de trabalho importantes que se espalham por diversos componentes obtêm total cobertura quando cada equipe de componentes conclui a RMA. No entanto, outras análises de como os componentes interagem são necessárias para garantir que as iniciativas de detecção, mitigação e recuperação sejam complementares em cada ponto de integração.


Funções e responsabilidades

O exercício de RMA é mais eficiente quando representantes de todas as disciplinas de engenharia são incluídos no processo, o que possibilita que perspectivas variadas de cada função sejam expressas durante as diversas fases da RMA. Incluir todas as disciplinas de engenharia ajuda a garantir resultados mais abrangentes. Existe uma disciplina que certamente deve participar do processo RMA, que é a disciplina do desenvolvimento. Em geral, os desenvolvedores (ou proprietários de componentes) são mais adequados para falar sobre os detalhes de como um sistema se comportará quando uma falha for encontrada. Um facilitador deve conduzir o processo do início ao fim e atribuir itens de trabalho a outras pessoas no final do processo. Essa pessoa pode ser de qualquer disciplina, mas deve ter a capacidade de orientar cuidadosamente as conversas entre as diversas disciplinas de engenharia para que os itens de trabalho sejam atribuídos na conclusão do exercício e produzam os maiores ganhos de confiabilidade, ainda consumindo o menor número possível de recursos.

Em busca de uma ação Adote os princípios de engenharia associados à computação orientada à recuperação. Incorpore a RMA em seu ciclo de vida de desenvolvimento de software: modele falhas e os efeitos dessas falhas, decida quais falhas devem ser tratadas pelo processo descrito aqui e faça os investimentos em engenharia necessários para reduzir riscos de alta prioridade. Demonstre o valor de aplicar a RMA em seu ambiente, reconsiderando os recursos de engenharia que são exigidos em virtude de não precisar responder continuamente às falhas e os aplique ao design e à entrega subsequente de inovações para os clientes em um ritmo mais rápido jamais visto. Compartilhe a experiência da RMA com outras equipes de engenharia que ainda não deram um passo adiante e as ajude a entender como aplicar a metodologia e a se beneficiar com os ganhos de produtividade como aconteceu com você.

Conclusão A computação em nuvem pode ser caracterizada como um ecossistema complexo, que consiste de infraestrutura compartilhada e dependências levemente acopladas, porém muito integradas, entre aplicativos, muitos dos quais estarão fora do controle direto do provedor. Na medida em que os serviços baseados em nuvem continuam progredindo, as expectativas dos clientes por disponibilidade máxima dos serviços permanecem altas, apesar dos desafios óbvios atrelados à entrega de uma experiência confiável 24 horas por dia, 7 dias por semana e 365 dias por ano.


Apesar de aplicar rigorosamente práticas de design de software bem conhecidas e baseadas em empresas, dos componentes de testes durante o desenvolvimento e da implementação de infraestrutura redundante e cópias replicadas de dados, é inevitável a ocorrência de interrupções. Existem inúmeras evidências de que ser capaz de evitar todas as falhas juntas seja uma suposição falível; continuam aparecendo artigos na mídia que descrevem falhas em serviços em nuvem conhecidos, e os provedores diariamente explicam o que deu errado e como planejam evitar futuras ocorrências. Mas falhas semelhantes continuam a acontecer. Arquitetos de software precisam adotar a ideia de que os recursos de computação subjacentes podem—e certamente irão—simplesmente desaparecer sem aviso, possivelmente por longos períodos. Ou seja, os arquitetos de software precisam aceitar essa nova era de imprevisibilidade e se planejar para isso. A metodologia descrita neste artigo se mostrou altamente eficiente ao ajudar equipes de serviços em nuvem a entender como lidar com ameaças persistentes relacionadas à confiabilidade. Ela também ajuda a priorizar os investimentos necessários em engenharia destinados a reduzir—ou até eliminar—o impacto dessas ameaças do ponto de vista dos clientes. O principal benefício de se adotar a RMA ou uma abordagem mais direcionada, composta apenas de modelagem de falhas e análises de causas-raízes, é que a equipe de serviços em nuvem emerge do exercício com uma análise mais abrangente, baseada na profunda exploração de cada aspecto do serviço construído. Os resultados do processo RMA fornecem à equipe um conhecimento mais aprofundado de onde os pontos de falha conhecidos estão, qual o impacto dos moldes de falhas conhecidas e, mais importante, a ordem para tratar esses possíveis riscos a fim de produzir o resultado mais confiável no menor espaço de tempo. Sabemos que interrupções no serviço são inevitáveis. Estamos criando e desenvolvendo nossos serviços usando metodologias como a RMA para ajudar a minimizar o impacto sobre os clientes quando essas interrupções acontecerem.


Recursos adicionais Orientação para arquitetura de nuvem resiliente no Azure

- Orientação arquitetônica do Windows Azure:

www.windowsazure.com/en‐us/develop/net/architecture/

- FailSafe (no Canal 9): channel9.msdn.com/series/failsafe

Computação orientada à recuperação: roc.cs.berkeley.edu/ Modelos

- Diagrama de interação entre componentes (CID): aka.ms/CID

- Exemplo de pasta de trabalho RMA: aka.ms/RMAworkbook

Confiabilidade da Computação confiável: www.microsoft.com/reliability

Autores e colaboradores DAVID BILLS – Microsoft Trustworthy Computing

SEAN FOY – Microsoft Trustworthy Computing

MARGARET LI – Microsoft Trustworthy Computing

MARC MERCURI – Microsoft Consulting Services

JASON WESCOTT – Microsoft Trustworthy Computing

© 2013 Microsoft Corp. Todos os direitos reservados. Este documento é fornecido "como está". As informações e as opiniões expressadas neste documento, incluindo URLs e outras referências a sites da Internet, podem ser modificadas sem aviso. Você assume o risco ao usá-lo. Este documento não fornece nenhum direito legal para nenhuma propriedade intelectual de qualquer produto da Microsoft. Você pode copiar e usar este documento para fins particulares de referência. Licenciado por Creative Commons Attribution-Non Commercial-Share Alike 3.0 Unported.

http://www.windowsazure.com/en-us/develop/net/architecture/�

http://channel9.msdn.com/series/failsafe�

http://roc.cs.berkeley.edu/�

http://aka.ms/CID�

http://aka.ms/RMAworkbook�

http://www.microsoft.com/reliability�

http://creativecommons.org/licenses/by-nc-sa/3.0/�

http://creativecommons.org/licenses/by-nc-sa/3.0/�

resiliência no design para serviços em nuvem · pdf file2 “recovery...

Documents