Disponibilidade é risco de negócio

O texto abaixo não reproduz o paper. Usa os fatos que os autores publicaram e tira a consequência para quem depende de um site, de uma API ou de um certificado SSL. A referência está no final.

Os quatro riscos, e o que importa aqui

Westerman pesquisava no Center for Information Systems Research do MIT Sloan. Hunter era da Gartner. Juntos, eles propuseram quatro riscos para a conversa entre negócio e TI: disponibilidade, acesso, precisão e agilidade.

Disponibilidade, no paper, é manter os sistemas e os processos de negócio que dependem deles em funcionamento, e recuperar o serviço depois de uma interrupção. Acesso é quem pode ver o quê. Precisão é a informação certa, no tempo certo. Agilidade é conseguir mudar sem um custo absurdo.

Para uma loja, uma landing ou uma API pequena, o primeiro nome é o que dói na hora: a página que o cliente abre, o checkout, o /health. Os outros três continuam existindo. Um monitor de uptime não resolve vazamento de dado, relatório errado nem projeto que não sai do lugar.

O caso que o paper usa

Na véspera de Natal de 2004, o sistema de escala de tripulação da ComAir, então subsidiária da Delta, parou. O paper registra o estrago em receita: US$ 20 milhões. Também registra dano de marca, uma investigação federal e a saída do presidente da companhia.

Os fatos operacionais, como os autores contam: a troca do sistema tinha sido adiada cinco vezes. A última, em meados de 2004, empurrou a substituição para o início de 2005. Um campo do sistema só contava até 32.767 alterações no mês. Entre 22 e 24 de dezembro, o mau tempo gerou mais de 6.000 mudanças de escala. Por volta das 22h da véspera de Natal, a alteração seguinte travou o sistema. Sem ele, a regra da aviação americana impedia os voos. Não havia reserva pronta para assumir. A equipe recarregou tudo do zero. O sistema voltou tarde no dia 25. A operação normal, só em 29 de dezembro. Cerca de 200 mil passageiros ficaram no caminho. Duas semanas depois, o secretário de Transportes dos Estados Unidos anunciou uma investigação. Uma semana mais tarde, o presidente da ComAir deixou o cargo.

O paper junta um segundo exemplo, menor na duração e enorme no efeito. Em agosto e de novo em novembro de 2005, a Bolsa de Tóquio conseguiu operar só 90 minutos do pregão, por uma falha de software. Em janeiro de 2006, fechou mais cedo por vários dias: o volume de ordens, depois de uma notícia, passou do que o mercado processava.

A pergunta que o paper deixa na mesa

Para disponibilidade, os autores sugerem que a diretoria saiba responder quatro coisas: quais processos dependem de TI, o que acontece se o sistema some, quanto custa aquele processo parado por uma hora e por um dia, e qual é o procedimento para voltar.

A ComAir mostra o teto dessa conta: dias parado, receita na casa das dezenas de milhões de dólares, gente presa no aeroporto, regulador na porta. A bolsa mostra o chão: 90 minutos de um dia de trabalho já bastam para o risco deixar de ser “assunto de TI”.

Nenhuma das duas histórias é uma loja brasileira. A pergunta escala. Se o processo é o checkout, uma hora tem número. A calculadora da UpGuardian faz a conta proporcional do faturamento. O case de tráfego pago acrescenta a verba de anúncio que continua clicando numa página fora. As duas são estimativas de ordem de grandeza, no espírito da pergunta do paper — custo de uma hora, custo de um dia — e não o prejuízo fechado de uma companhia aérea.

O que um monitor simples cobre

A ComAir não caiu porque a home devolveu erro. Caiu porque um limite interno estourou e ninguém tinha um sistema reserva. A UpGuardian não vê contador interno, não substitui backup e não escreve plano de continuidade. Isso continua sendo operação de quem cuida do sistema.

O que o monitor vê é o lado de fora, o que o visitante encontra:

• a URL do site, do checkout ou da API responde com o status esperado;
• uma porta TCP ainda aceita conexão;
• o certificado SSL está perto de vencer — página “no ar” que o navegador trata como indisponível.

Quando a checagem falha, o alerta sai por e-mail, WhatsApp ou webhook. Quando volta, sai outro. No paper, o procedimento de recuperação é parte da disponibilidade. Para um time pequeno, esse procedimento começa em saber que caiu, pausar o anúncio e chamar quem sobe o serviço — em minutos, não quando o cliente manda mensagem.

Os outros três riscos do framework ficam de fora de propósito. Acesso, precisão e agilidade pedem outra ferramenta. Disponibilidade do endpoint é o recorte em que um monitor de uptime cabe.

Referências

• Westerman, George; Hunter, Richard. Developing a Common Language About IT Risk Management. MIT Sloan CISR Working Paper No. 377, junho de 2009. © 2009 MIT Sloan Center for Information Systems Research. Repositório do MIT (DSpace). Também em SSRN 1979796.

Os números da ComAir, da Bolsa de Tóquio e as quatro perguntas de disponibilidade vêm desse paper. A leitura para site, API, SSL e alerta é da UpGuardian.