Healthcare.gov 2013: o lançamento que não escalou

01 · CONTEXTO

Um site, três sistemas e uma porta de entrada

O HealthCare.gov é o site federal dos Estados Unidos para a compra de planos de saúde privados por consumidores de estados que não criaram seus próprios marketplaces. No lançamento, em 1º de outubro de 2013, e por algum tempo depois, os usuários encontraram quedas e falhas técnicas. A fonte deste caso é o estudo do Escritório do Inspetor-Geral do Departamento de Saúde dos EUA sobre o projeto.

Três peças importam aqui. O EIDM servia para os consumidores criarem contas e verificarem a identidade. O FFM era o núcleo do sistema e determinava a elegibilidade para planos e para auxílio financeiro. O Hub roteava pedidos de informação para outras agências federais e de volta, como a Receita (IRS) e a Previdência (SSA).

1. O consumidor entra pelo EIDM, o sistema que cria contas e verifica identidades. Ele é a porta de entrada do site.

2. Dali o consumidor chega às funções e às informações do site, que ficam no FFM, o núcleo do sistema.

3. O FFM determina a elegibilidade para planos e para auxílio financeiro e consulta o próprio banco de dados.

4. Quando precisa de dados federais, o pedido passa pelo Hub, que o roteia para outras agências, como IRS e SSA, e devolve a resposta.

02 · O DIA DO LANÇAMENTO

Mais gente do que o previsto e quase ninguém inscrito

Em 1º de outubro de 2013 o site teve 250.000 usuários simultâneos, muito acima da capacidade planejada, e as quedas começaram em até 2 horas após o lançamento, impedindo muitos consumidores de entrar e se inscrever.

O CTO dos EUA atribuiu os problemas ao volume, cinco vezes o número de usuários simultâneos previsto. Mas a própria investigação relata que logo ficou claro que os problemas não vinham só do número de visitantes e sim também de problemas centrais de desempenho. No primeiro dia da primeira inscrição aberta, só seis consumidores conseguiram enviar a inscrição e escolher um plano.

03 · O QUE PREPAROU A QUEDA

Teste que não aconteceu, capacidade descoberta tarde e uma porta estreita

O teste de ponta a ponta é a etapa final e crítica que simula o uso do consumidor em todas as funções. A CMS nunca conseguiu completá-lo, porque as peças do sistema chegaram tarde demais. A equipe técnica considerava lançar no prazo mais prioritário do que testar e resolver problemas de desempenho, e um responsável descreveu o próprio lançamento como um teste do sistema, com os problemas a resolver depois.

Em 26 de setembro de 2013, técnicos da CMS fizeram um teste de desempenho limitado e viram que o site suportava bem menos usuários simultâneos que o planejado. Parte do motivo era que o código exigia mais infraestrutura do que a CMS previra. Pouco antes do lançamento, a CMS pediu que a capacidade fosse dobrada em 3 dias. A Terremark acrescentou mais que o dobro e, até 29 de setembro, o limite de usuários simultâneos tinha subido bastante.

1. A falta de capacidade do EIDM criou um gargalo para os consumidores chegarem às funções e às informações do site.

2. A contratada do EIDM relatou que não sabia que todos os visitantes passariam por ele e, por isso, subestimou a capacidade necessária.

3. No FFM, o software do site pedia informação ao banco mais de 100 vezes numa operação que deveria exigir 1 ou 2 pedidos.

4. Um técnico da CMS disse que o FFM era o problema maior, mas que só se via a dimensão dos problemas de código depois de superar o do EIDM.

04 · SEM ENXERGAR O SISTEMA

Quem opera não vê o todo

Segundo técnicos da CMS, o monitoramento coordenado não era prioridade antes do lançamento porque os recursos iam para a construção do site. Antes do lançamento, cada contratada monitorava os próprios sistemas e não via os demais, embora eles trabalhassem juntos.

Depois do lançamento havia centros de comando separados, com ferramentas para acompanhar quedas, tempo de resposta e erros, mas sem uma equipe com visão de todo o sistema e poder de agir. Um integrante da equipe técnica que ajudou no conserto contou que não havia onde ver se o site estava no ar, exceto a CNN.

05 · RECUPERAÇÃO E LIÇÕES

Painéis, salas de espera e entradas redundantes

Entre 1º de outubro e 1º de dezembro de 2013, a CMS comprou ferramentas de monitoramento com painéis de desempenho do site. Decidiu também refatorar o código existente em vez de reconstruir do zero e contratou a QSSI como integradora técnica de sistemas, para aconselhar na coordenação de tarefas e recursos técnicos.

1. Ferramentas de monitoramento passaram a dar à equipe painéis de desempenho do site.

2. Com a capacidade sobrecarregada, a CMS podia colocar consumidores numa sala de espera. Ali eles podiam pedir um e-mail para voltar quando houvesse capacidade ou ligar para a central.

3. Para ter redundância, a CMS contratou desenvolvedores para começar a criar um login exclusivo do HealthCare.gov, diferente do login usado em toda a CMS.

4. Uma nova ferramenta de compra de planos dispensava que o consumidor criasse conta.

5. A proporção de tempo em que o site funcionava foi de 42 por cento no início de novembro para mais de 90 por cento no fim de novembro, e ele passou a suportar mais de 35.000 usuários simultâneos sem cair.

A CMS recuperou o site para uso intenso em até dois meses. A nova política de contingência buscou criar sistemas redundantes para manter o site no ar se os principais falhassem. A tabela resume a mudança nos pontos que este caso acompanha.