← tópicos

Específicos · Infraestrutura em TI

Continuidade: HA (ativo-ativo × ativo-passivo, SPOF), noves, RTO × RPO, MTBF/MTTR

RTO olha para a frente — quanto tempo até o serviço voltar; RPO olha para trás — quanto de dado se aceita perder. Inverter os dois é a armadilha número um do tópico.

Altíssima64 itens no tópico

A ideia que organiza o assunto

Desenhe uma linha do tempo e marque um ponto nela: o desastre. Quase todo item deste tópico pergunta por um dos dois lados desse ponto.

À esquerda está o passado, e a moeda ali é dado. O último instante cuja informação eu ainda tenho guardada não é o instante do desastre — é o instante do último backup ou da última replicação. A distância entre um e outro é o RPO: quanto de trabalho a organização aceita perder. Definir o RPO é, na prática, definir de quanto em quanto tempo se copia.

À direita está o futuro, e a moeda ali é tempo de serviço parado. Do desastre até o instante em que o serviço volta a atender vai o RTO: quanto tempo a organização aceita ficar sem aquilo. Definir o RTO é definir o tipo de sítio alternativo, o tamanho do cluster e o contrato com o fornecedor.

RPO olha para trás e se mede em dados perdidos; RTO olha para frente e se mede em indisponibilidade. Um item que descreva o RPO como “tempo até restaurar” ou o RTO como “integridade dos dados replicados” está errado sem que você precise de mais nada. É o formato mais frequente e mais barato de errar um item aqui.

A mesma linha organiza as métricas de disponibilidade: MTBF é a distância entre dois desastres, MTTR é a largura de um deles, e a disponibilidade é a razão entre o tempo em pé e o tempo total.

E antes da linha existe uma cadeia fixa, que decide os itens normativos: a BIA descobre o que dói e em que ordem recuperar; a análise de riscos descobre o que pode derrubar aquilo; a estratégia escolhe como atender aos prazos que a BIA apurou; o plano diz o que se faz na hora. Diante de um item de norma, pergunte em que elo aquilo acontece — a banca troca os elos de lugar o tempo todo.

Duas perguntas, portanto, e quase nada além delas: de que lado do desastre isso está? e em que elo da cadeia isso acontece?

Por que se usa (e o que custa)

Disponibilidade se compra com redundância, e redundância se paga em equipamento ocioso, complexidade e sincronismo. Cada nove adicional custa aproximadamente uma ordem de grandeza a mais: sair de 99% para 99,9% é trocar três dias e meio de parada anual por menos de nove horas, e sair de 99,99% para 99,999% significa uma infraestrutura que quase ninguém precisa e quase ninguém consegue operar.

O mesmo vale para a continuidade. Reduzir o RTO de vinte e quatro horas para uma hora não é ajuste de plano: é trocar um sítio frio por um sítio quente espelhado. Reduzir o RPO de vinte e quatro horas para zero é trocar backup noturno por replicação síncrona — que, por sua vez, cobra em latência de escrita. É por isso que a continuidade começa pela BIA e não pela tecnologia: só a criticidade do processo justifica o preço do prazo.

E há um custo que a prova cobra em forma de generalização: nada disso elimina o desastre. Continuidade reduz probabilidade e impacto; não promete ausência de falha.

Como funciona

Alta disponibilidade é a eliminação sistemática do ponto único de falha. SPOF é todo componente cuja queda derruba o serviço inteiro — uma fonte, um switch, um enlace, um banco, um datacenter. O método é sempre o mesmo: identificar o componente único e duplicá-lo, em N+1 (um sobressalente para o conjunto) ou 2N (conjunto inteiro espelhado). Alta disponibilidade não é ausência de falha: é falha curta e recuperação rápida.

Cluster é o instrumento. Dois ou mais nós trabalham em conjunto e se apresentam ao usuário como um sistema único — imagem única de sistema. Os nós trocam sinais de vida (heartbeat); quando um para de responder, outro assume as suas funções, e isso se chama failover. A volta do serviço ao nó original, depois que ele se recupera, é o failback. Se a rede entre os nós cai mas ambos continuam vivos, cada um pode julgar-se o sobrevivente e assumir o serviço ao mesmo tempo: é o split-brain, e o que o evita é o quórum — só opera o lado que reúne mais da metade dos votos. Pacemaker, Corosync, Heartbeat e Keepalived são as implementações que a prova cita.

Ativo-ativo × ativo-passivo é a escolha de como usar a redundância. No ativo-ativo, todos os nós atendem simultaneamente e há balanceamento de carga entre eles (round robin, menor número de conexões, ponderado); ganha-se desempenho junto com disponibilidade, mas exige-se tratamento de estado e de sessão. No ativo-passivo, um nó atende e o outro espera pronto para assumir; o hardware fica ocioso, porém o failover é simples e sem problema de concorrência.

As métricas. O MTBF (tempo médio entre falhas) mede quanto o sistema opera entre uma falha e a seguinte — é confiabilidade, e quanto maior, melhor. O MTTR (tempo médio de reparo) mede quanto se leva para consertar — é manutenibilidade, e quanto menor, melhor. A disponibilidade sai dos dois: MTBF ÷ (MTBF + MTTR). Downtime é o tempo indisponível; uptime, o tempo em operação. E o cálculo depende da configuração dos componentes: em série, as disponibilidades se multiplicam e o conjunto é sempre pior que a pior peça; em paralelo, o que se multiplica são as indisponibilidades, e o conjunto fica melhor que a melhor peça. Não há como calcular disponibilidade ignorando o arranjo.

A cadeia da continuidade. A GCN (gestão de continuidade de negócios) é um sistema de gestão, com ciclo PDCA, política, papéis, recursos, treinamento, testes, análise crítica e melhoria contínua — não é um documento. Dentro dela, a BIA levanta as atividades críticas, o impacto da interrupção ao longo do tempo, as interdependências e os prazos (RTO e RPO); a avaliação de riscos identifica ameaças e vulnerabilidades que podem causar a interrupção; a estratégia de continuidade, escolhida a partir dessas duas, decide como atender aos prazos; e os planos documentam os procedimentos. O PCN trata da continuidade das atividades; o PRD (plano de recuperação de desastres) trata de restaurar a infraestrutura de TI; o PCO reúne os procedimentos alternativos para casos de inoperância previamente definidos; o PAC, a comunicação com as partes interessadas durante a crise.

Os sítios alternativos são o preço do RTO: o frio tem espaço e infraestrutura básica e leva dias; o morno tem hardware instalado e dados defasados e leva horas; o quente é espelho pronto e leva minutos ou nada.

As normas. A ABNT NBR ISO 22301 traz os requisitos do sistema de gestão de continuidade (é a certificável); a 22313, as diretrizes de implementação. A NBR 15999, baseada na britânica BS 25999, foi a antecessora brasileira e cedeu lugar à 22301. A ISO/IEC 27005 cuida da gestão de riscos de segurança da informação — e não estipula método: exige abordagem sistemática e deixa a metodologia para a organização. A 27031 trata da prontidão da TIC para a continuidade; a 27035, da gestão de incidentes. No ITIL, a continuidade dos serviços de TI é o ITSCM, que reduz riscos a um nível aceitável e prepara a recuperação; quem cuida de atender à demanda dentro do orçamento é o gerenciamento da capacidade; e confiabilidade, manutenibilidade, funcionalidade e resiliência são objetivos do gerenciamento da disponibilidade.

O que decide os itens

RTO × RPO — a distinção que decide mais itens que todas as outras somadas:

RTORPO
direção no tempopara a frente, a partir do desastrepara trás, a partir do desastre
o que se perdetempo de serviço paradodados / trabalho
perguntaem quanto tempo tem de voltar?quanto de dado posso perder?
definesítio alternativo, cluster, contratofrequência de backup / replicação
RTO = 0 / RPO = 0serviço sem interrupção perceptívelnenhuma perda: replicação síncrona

MTBF × MTTR × MTTF — MTBF é entre falhas (confiabilidade); MTTR é o reparo (manutenibilidade); MTTF é o tempo até a falha de componente não reparável. MTBF ≈ MTTF + MTTR.

Ativo-ativo × ativo-passivo:

ativo-ativoativo-passivo
nós atendendotodos, simultaneamenteum só; o outro aguarda
balanceamento de cargasim, é parte do modelonão há tráfego no nó reserva
ganhodisponibilidade e desempenhodisponibilidade apenas
custosincronismo de estado e de sessãohardware ocioso

Failover × failback — failover é o outro nó assumir; failback é o serviço voltar ao nó original depois do conserto. A banca troca as duas palavras com frequência.

Alta disponibilidade × tolerância a falhas — a HA admite uma interrupção breve e recupera rápido; a tolerância a falhas mascara a falha e não interrompe. “Continuamente disponível, com pouco downtime e recuperação rápida” descreve HA.

BIA × análise de riscos — a BIA olha a consequência: o que dói, quanto dói ao longo do tempo, em que ordem recuperar, quais os prazos. A análise de riscos olha a causa: que ameaças e vulnerabilidades podem provocar a interrupção. Quem estabelece criticidade, prioridades de recuperação e interdependências é a BIA — não a análise de riscos e não a estratégia.

Estratégia × plano — a estratégia escolhe como atender aos prazos (sítio, terceirização, redundância, trabalho manual); o plano documenta o que se faz na hora, quem faz, com que recurso e a quem se comunica.

GCN × gestão de incidentes — registrar, classificar, tratar e comunicar eventos é a gestão de incidentes; manter a entrega dos produtos e serviços em nível aceitável durante e após a disrupção é a GCN. Elas se completam, e nenhum item que as oponha (“ao contrário de”) tende a estar certo.

PCN × PRD × PCO × PAC — negócio, TI, procedimentos alternativos de operação e comunicação, nessa ordem de escopo.

Ativos primários × ativos de suporte (27005) — primários são processos e informação; de suporte são hardware, software, rede, pessoas, instalações. Não existe “ativo secundário” na norma.

Ameaça × vulnerabilidade × risco — ameaça é o agente ou evento; vulnerabilidade é a fragilidade explorável, inclusive um controle que funcione mal ou seja usado incorretamente; risco é o efeito da ameaça explorando a vulnerabilidade. Vulnerabilidade sem ameaça continua sendo vulnerabilidade.

Falso positivo × falso negativo (antispam e varredura) — e-mail legítimo barrado é falso positivo; spam que passa é falso negativo.

Números que caem

disponibilidadeMTBF ÷ (MTBF + MTTR), ou uptime ÷ (uptime + downtime)
99% — “dois noves”3,65 dias de parada por ano (87,6 h)
99,9% — “três noves”8,76 horas por ano (43,2 min/mês)
99,99% — “quatro noves”52,6 minutos por ano (4,3 min/mês)
99,999% — “cinco noves”5,26 minutos por ano (26 s/mês)
99,9999% — “seis noves”31,5 segundos por ano
ano de referência525.600 minutos (8.760 horas)
redundânciaN+1 (um reserva para o conjunto) × 2N (espelho completo)
quórum em clustermais da metade dos nós: n/2 + 1
sítio frio · morno · quentedias · horas · minutos de RTO
ISO 22301 × 22313requisitos (certificável) × diretrizes
NBR 15999antecessora brasileira, baseada na BS 25999
27005 · 27031 · 27035riscos · prontidão da TIC · incidentes

Como a CEBRASPE derruba você aqui

Medido sobre os 30 itens errados já explicados do tópico. Quase dois terços deles são a mesma jogada: o tópico é feito de pares, e a banca dá a definição certa de um sob o nome do outro. Nenhuma metade da frase é falsa isoladamente — é o emparelhamento que está errado.

Um termo trocado pelo parceiro de par — 43%, o formato dominante. Os pares que aparecem medidos: RTO e RPO, “ao tempo necessário para a recuperação dos dados” dito do RTO, quando dado é assunto do RPO; MTBF e MTTR, um MTBF de quatro horas lido como se o serviço “se recupera de falhas nesse período”; failover e failback, assumir as funções do nó que falhou batizado de “failback”; falso positivo e falso negativo, a mensagem legítima barrada pelo filtro chamada de “falso negativo”; ativos primários e de suporte, que o item lista como “primários ou secundários”. O mesmo movimento percorre a cadeia do plano: “a análise de risco reconhece as prioridades” e “a estratégia de continuidade de negócio define a criticidade dos processos de negócio” — criticidade, prioridade, interdependência e prazo são entrega da BIA, sempre. Defesa: para cada sigla, diga para que lado ela olha antes de ler o resto. Dado olha para trás, serviço olha para frente; MTBF mede tempo em pé, MTTR mede tempo de conserto; failover é ida, failback é volta; a BIA diagnostica, a estratégia escolhe, o plano executa.

Premissa invertida — 20%. Aqui o item afirma o contrário do que a norma diz, e a inversão vem embalada num trecho normativo correto que lhe dá credibilidade. “A determinação do ponto de recuperação objetivo (RPO) é definida tecnicamente como o tempo máximo necessário para a restauração da capacidade operacional total de um serviço” — é a definição do RTO. “Os riscos, em sua maior parte, são estáticos”, quando a 27005 parte justamente do contrário para exigir monitoramento contínuo. “O controle dos processos terceirizados é opcional”, quando a 22301 o exige, porque terceirizar a execução não transfere a responsabilidade. Um controle que “é incapaz de representar por si só uma vulnerabilidade”, quando controle que funciona mal é vulnerabilidade. Downtime que “corresponde ao tempo de atividade de um sistema”, que é uptime. Defesa: quando o item disser que algo é opcional, dispensável, estático ou incapaz, suspeite — a família de normas costuma dizer exatamente o oposto, e é dela que sai o gabarito.

Absoluto — 13%. “Eliminar qualquer possibilidade de desastre ou perda de dados”: nenhum plano elimina, e a existência de um RPO maior que zero prova que alguma perda é tolerada por projeto. “Esses recursos sejam sistematicamente mantidos em duplicidade”, quando duplicar é uma estratégia entre várias. O impacto “integralmente determinado pelo custo da recuperação e da reposição da informação”, quando reputação, oportunidade e consequência legal também contam. “Qualquer tentativa de invasão a um ambiente computacional é considerada um crime cibernético”. Defesa: achado o absoluto, procure o contraexemplo que ele exclui — e lembre que continuidade reduz, nunca elimina.

Conteúdo atribuído à etapa errada — 13%. Quase sempre o alvo é o PCN, que recebe o que vem antes ou depois dele: “No plano de continuidade de negócios, é apresentado um estudo do cenário atual da organização, com a avaliação de potenciais riscos” — isso é insumo, produzido antes; “o plano de continuidade de negócios (PCN) deve focar o isolamento físico do hardware atingido” — isso é contenção, da resposta a incidentes; “Na visão da GCN não é necessário fazer levantamento de possíveis ameaças e análise de risco” — é etapa interna da própria GCN. E, entre processos do ITIL, garantir que os serviços “atendam às necessidades atuais e futuras do negócio dentro do orçamento planejado” é definição de gerenciamento da capacidade, não de continuidade. Defesa: o PCN documenta resposta e recuperação — papéis, recursos, prazos. Diagnóstico e avaliação ficam fora dele.

Regra esticada para além do que a norma diz — 7%. “Conforme método específico estipulado na norma NBR ISO 27005:2019”: a 27005 dá diretrizes e deixa o método à organização. E um plano que funcionaria para disrupções “mesmo que não tenham sido mapeadas anteriormente em um processo de análise de risco e impacto”: eficácia comprovada só existe para o cenário analisado e testado.

Disponibilidade calculada por atalho — 3%. “A quantidade de nós disponíveis e a quantidade de falhas ocorridas nas últimas 24 horas” não entram na conta, e tampouco se pode dispensar “a configuração dos componentes”, porque série e paralelo dão resultados opostos com as mesmas peças. Se a fórmula não reduzir a tempo em pé sobre tempo total, o item está errado.

Erros clássicos

Achar que RPO é um tempo de recuperação. Os dois são medidos em unidades de tempo, e é exatamente isso que a banca explora. O RPO é tempo de dado: quantas horas de trabalho cabem na janela entre duas cópias.

Confundir alta disponibilidade com tolerância a falhas. HA aceita cair e levantar depressa; tolerância a falhas não deixa cair. Um item que exija “nenhuma interrupção” de um cluster de alta disponibilidade está exagerando.

Achar que ativo-passivo não é alta disponibilidade. É. O que ele não oferece é balanceamento de carga nem ganho de desempenho.

Somar noves sem conta. Cinco noves não são “quase o mesmo” que quatro: são 52 minutos contra 5 minutos por ano, uma ordem de grandeza de custo.

Tratar a GCN como um documento. A GCN é sistema de gestão, com política, recursos, treinamento, teste e melhoria contínua; o PCN é apenas um de seus produtos.

Supor que o plano cobre o que não foi mapeado. Um PCN vale para os cenários que a BIA e a análise de riscos levantaram. Item que prometa eficácia diante de intempéries não mapeadas está errado.

Confundir MTBF com MTTF. MTBF pressupõe reparo e reinício de operação; MTTF é o tempo até a falha de um componente que não se conserta.

Esquecer o SPOF que não é servidor. O ponto único de falha costuma estar no enlace, na fonte, no ar-condicionado ou no fornecedor — não no nó que foi duplicado.

Praticar64 itens