10º aniversário do resgate do HealthCare.gov
(pauladamsmith.com)- Em 18 de outubro de 2013, uma pequena equipe técnica iniciou na Casa Branca a primeira avaliação em campo para reerguer o HealthCare.gov, que havia travado logo após o lançamento; esse esforço mais tarde passou a ser chamado de “tech surge”
- O site foi lançado em 1º de outubro de 2013, mas não funcionava direito, e por causa da paralisação do governo federal iniciada no mesmo dia, o apoio externo só pôde entrar após 17 de outubro
- No primeiro dia, a equipe passou pela Casa Branca, HHS, CMS, Exchange Operations Center e escritório da CGI para identificar gargalos de um grande sistema em que contratos, componentes e regras de negócio, e procedimentos de implantação estavam todos entrelaçados
- No local, ficaram evidentes como principais riscos os testes manuais, implantações noturnas longas com rollback, provisionamento lento de recursos, uma camada central de dados sem esquema e a ausência de monitoramento em tempo real
- Depois de instalar o New Relic manualmente em alguns servidores no escritório da CGI, latência, taxa de erros e volume de requisições começaram a ficar visíveis pela primeira vez; em seguida, ao longo de cerca de dois meses e meio, o trabalho de resgate foi ampliado e contribuiu para melhorar o site
18 de outubro de 2013, o início do resgate
- O trabalho de recuperação do HealthCare.gov ganhou força na sexta-feira, 18 de outubro de 2013, às 7h15 da manhã, com um pequeno grupo reunido perto da entrada da West Wing da Casa Branca
- O grupo inicial incluía Todd Park, Brian Holcomb, Gabriel Burt, Ryan Panchadsaram, Greg Gershman e Paul Smith, e mais tarde naquele dia Mikey Dickerson se juntou por uma longa chamada no viva-voz
- Alguns vieram de fora do governo e outros já trabalhavam nele, mas todos eram especialistas em tecnologia com experiência em startups ou em grandes organizações de tecnologia
- Todd Park, então CTO dos EUA, selecionou essas pessoas para reforçar os funcionários públicos e as equipes de contratadas que haviam construído o HealthCare.gov
- A missão não era agir como “cavalaria chegando para salvar”, mas entrar discretamente em um ambiente já sob forte pressão e estresse para coletar informações e fazer uma avaliação, em uma postura de apoio discreto
- Todd Park disse que os 30 dias seguintes seriam cruciais, e a meta era inscrever 7 milhões de pessoas até 31 de março de 2014, quando terminava o período de inscrições públicas
O vazio criado pela paralisação e pelo fracasso do lançamento
- O HealthCare.gov foi lançado em 1º de outubro de 2013, mas não funcionou adequadamente, e no mesmo dia começou a paralisação do governo federal
- Por causa da paralisação, pessoas de fora da equipe central do HealthCare.gov não puderam entrar para ajudar
- Enquanto isso, as notícias se enchiam da paralisação e do desastre do lançamento que avançava lentamente, ampliando o vazio de informações, as especulações e as preocupações
- A Casa Branca não conseguia entender o que havia dado errado no HealthCare.gov, e se o site fracassasse, o principal meio de levar os benefícios do Affordable Care Act a milhões de pessoas poderia ficar comprometido
- A paralisação terminou em 17 de outubro, e só então a equipe técnica externa pôde verificar a situação real e começar o trabalho
A visão geral do sistema identificada na manhã do primeiro dia
- Depois de tomar café da manhã no Navy Mess da Casa Branca, a equipe subiu ao escritório do Chief of Staff para se encontrar com Denis McDonough
- Denis McDonough perguntou diretamente: “Dá para consertar?”, e alguns membros da equipe, tensos, responderam que sim
- Em seguida, seguiram para o Hubert H. Humphrey Building, sede do HHS, onde se reuniram com Marilyn Tavenner, responsável pelo CMS, e sua equipe
- Nessa reunião, foram compartilhadas a estrutura do HealthCare.gov, os principais componentes funcionais e os pontos de falha e problemas de desempenho em alto nível que a liderança do CMS conhecia
- Como a liderança do CMS era formada por especialistas em política de saúde e administradores, as informações repassadas estavam mais próximas de métricas de negócio do site e de explicações gerais de desempenho
- No fim da manhã, eles seguiram para a sede do CMS em Woodlawn, Maryland, onde encontraram lideranças do HealthCare.gov como Michelle Snyder, Henry Chao e Dave Nelson
- Foi ali que começaram a surgir, pouco a pouco, informações sobre problemas de implantação, gargalos, os pontos em que os usuários “emperravam” no site, o banco de dados XML MarkLogic, a arquitetura de implantação e os tipos de servidor
A realidade operacional revelada no XOC
- À tarde, seguiram para o Exchange Operations Center, ou XOC, em Columbia, Maryland
- O XOC era um hub de controle em estilo missão para a operação do HealthCare.gov, e ali a equipe ouviu os relatos dos técnicos que lidavam diretamente com o site
- Os problemas confirmados no local eram muito mais graves do que o previsto inicialmente
- Havia falta de confiança nas mudanças feitas no código-fonte
- Muitas partes do site eram geradas por procedimentos complexos de geração de código e exigiam coordenação minuciosa entre equipes
- Os testes eram, em grande parte, um processo manual
- Releases e implantações exigiam longas janelas de indisponibilidade noturna e, quando falhavam, eram seguidos por rollbacks demorados
- A camada central de dados não tinha esquema
- O provisionamento de recursos de hospedagem era lento e não automatizado
- Não havia, em uma forma visível para as equipes, nem APM nem métricas básicas como CPU, memória, disco e rede
- Nesse ponto, a equipe aceitou que a situação era muito pior do que havia imaginado no começo, e Paul Smith anotou às pressas em seu caderno Moleskine o que estava ouvindo
A noite em que conectaram o New Relic no escritório da CGI
- À noite, seguiram para o escritório da CGI em Herndon, Virgínia
- A CGI era a principal contratada do HealthCare.gov, e a equipe se reuniu com a liderança e com os times técnicos para fazer perguntas
- Nessa reunião, era importante que a equipe técnica externa conquistasse a confiança do time da CGI
- O time da CGI estava sob pressão e exausto
- A equipe de resgate enfatizou que não estava ali para culpar ninguém, mas para ajudar
- Tentou demonstrar capacidade de engenharia com base na experiência com sites de alto tráfego
- A pergunta central era “o que está errado com o site e como vocês sabem disso?”, mas CMS e CGI em grande parte não conseguiam mostrar em que pontos específicos, dentro do sistema, certos componentes não estavam funcionando como esperado
- A equipe propôs instalar em alguns servidores o New Relic, um serviço de monitoramento em estilo APM com o qual já estava familiarizada
- Ignorando o procedimento normal de release, instalaram manualmente o agente em parte dos servidores escolhidos, e a liderança do CMS aprovou a mudança depois de confirmar que já havia licença do New Relic
- As pessoas que permaneceram até perto da meia-noite executaram a alteração, e no painel administrativo do New Relic exibido na tela da sala de reunião, os servidores selecionados do “red shard” logo começaram a enviar métricas
- Pela primeira vez, ficaram visíveis métricas operacionais em tempo real como picos de latência nas requisições, taxa de erros e número de requisições por minuto, revelando um estado do sistema que até então era praticamente invisível
- Essas métricas criaram a base para relacionar métricas de negócio ao estado do sistema e priorizar correções e ações com maior potencial de melhoria
Depois do primeiro dia de 18 horas
- Depois de sair de Herndon, a equipe fez uma breve retrospectiva por volta das 2 da manhã na silenciosa Roosevelt Room da Casa Branca
- Nesse momento, o grupo entendeu que o problema não era algo que pudesse ser resolvido apenas com aconselhamento de curto prazo, e aceitou que precisaria se dedicar a esse trabalho por algum tempo, até que o site se recuperasse
- Após dormir por algumas horas, na manhã seguinte voltaram para Herndon
- O cronograma do primeiro dia teve cerca de 18 horas, e maratonas parecidas continuaram depois disso
- Até o fim de dezembro, ao longo de cerca de dois meses e meio, o tech surge foi ampliado e novos membros se juntaram à equipe, ajudando a melhorar o HealthCare.gov
- Naquele ano, milhões de pessoas conseguiram cobertura de saúde, algo inédito para muitas delas
1 comentários
Opiniões no Hacker News
A intenção original era que cada estado operasse sua própria exchange, e que apenas os moradores dos estados que se recusassem usassem a exchange federal.
No início, 36 estados não criaram suas próprias exchanges 0, e hoje parece que 20 estados, incluindo D.C., operam seus próprios marketplaces 1.
O shutdown do governo em 2013, que impediu que pessoas de fora da equipe estadual do HealthCare.gov entrassem para ajudar, foi liderado pelo senador Ted Cruz com o objetivo de sabotar o ACA 2.
Às vezes sinto que o princípio americano de que “cada estado é independente” vai longe demais.
Eles temiam que um sistema federal de saúde acabasse levando a um seguro-saúde universal e, depois de conseguirem a concessão, recusaram-se a implementar as exchanges esperando que a lei morresse.
Mas a lei não morreu, e eles ainda se incomodam com isso.
Ao repassar verbas federais aos estados como block grants e deixar que os estados cuidassem de programas como o TANF e das avaliações de elegibilidade 1, tanto a eficiência com que cada dólar do orçamento federal virava apoio real quanto o número de pessoas atendidas e os valores recebidos pioraram muito.
Não sei qual era a justificativa para os marketplaces estaduais do ACA, mas historicamente, quando se colocam os estados no meio, aumenta o espaço para intermediários estragarem o programa e desviarem o dinheiro para outros fins.
Por exemplo, o Texas recusou 5 a 6 bilhões de dólares por ano em dinheiro gratuito que o governo federal queria dar para a expansão do Medicaid 2.
Acho que vi várias vezes a história de alguma seguradora que teve prejuízo por causa de um pequeno número de pacientes com tratamentos muito caros e, quando esses custos cresceram demais e ela aumentou os preços, ninguém quis comprar aquele produto.
Procurei essas matérias recentemente e não consigo mais encontrá-las, então fico em dúvida se foi algo que imaginei.
Tenho dinheiro e vontade de contratar, mas não consigo; então esse sistema é um fracasso.
Guardo a lembrança de ter trabalhado com essas pessoas quando todo mundo foi puxado para consertar isso.
Ver o Gabe programando no VIM era como ver um violinista virtuose, e trabalhando com o Mikey eu vi o poder de métricas e SRE.
Saímos de uma situação em que todos na sala apontavam o dedo para o próximo fornecedor para uma em que parte dos gargalos foi realmente identificada.
No geral, consertar um sistema quebrado sem poder tirá-lo do ar para uma grande refatoração era como operar uma pessoa que está correndo; foi uma experiência realmente intensa.
Uma pequena startup de D.C. era algo como subcontratada da subcontratada da subcontratada responsável pela landing page da frente, e ainda assim guardo uma boa lembrança de termos conseguido fazer com que as pessoas chegassem a uma página real no healthcare.gov, em vez de uma página de erro 500.
Se minha memória não falha, isso foi graças a um único servidor usando Jekyll e um backup.
Em termos atuais, era uma abordagem de “geração de páginas estáticas”, por isso podia ser hospedado em hardware modesto.
Na época, isso era visto como uma tática bastante avançada, e provavelmente é disso que você está se lembrando.
Pelo que sei, aquele site foi substituído completamente quando a exchange federal abriu, e a landing page em si não recebia nem processava informações pessoais, então não havia grande dificuldade para servi-la.
Tudo travou depois que os usuários começaram de fato a tentar encontrar planos de seguro.
A Development Seed também criou outro projeto de que talvez você já tenha ouvido falar, o Mapbox, e acabou transformando toda a empresa nessa direção.
Lembro de ouvir em um podcast que, em vez de mostrar como erro as falhas de “timeout do backend”, eles mudaram para enviar os dados por e-mail e dizer ao usuário: “Tudo certo, recebemos. Volte mais tarde para verificar”.
Achei muito inteligente e guardei isso como uma abordagem que poderia usar em uma emergência no futuro.
Algo parecido aconteceu no WebTV quando houve sobrecarga no banco de dados: eles derrubaram todos os servidores finais de entrega de e-mail que precisavam de conexão com o banco de dados, fazendo com que os e-mails ficassem enfileirados nos servidores SMTP de entrada, e depois esvaziaram a fila quando a sobrecarga do banco foi resolvida.
A lição é que, para reduzir a carga de um sistema projetado para operar de forma transacional mas que está falhando, use processamento orientado a lotes a partir de uma fila.
O episódio do podcast “Go Time” sobre esse tema foi excelente e abordou como Go foi usado para servir parte do site
Recomendo muito esse episódio e o podcast
https://changelog.com/gotime/154
Cliquei achando que seria uma discussão técnica interessante, mas a parte técnica só apareceu bem mais adiante
Em vez disso, os bastidores do processo foram inesperadamente muito interessantes, e estou realmente ansioso pela próxima parte
Gostei muito de ler este artigo
Lembro de, 10 anos atrás, o pessoal no HN fuçando minuciosamente o código-fonte do site no GitHub: https://news.ycombinator.com/item?id=6540993
O que aconteceu de fato não foi ideal, mas fico curioso se, além desta retrospectiva, existe algum material explicando com mais detalhes exatamente o que aconteceu e como foi resolvido
Pretendo continuar acompanhando os próximos textos desta série
Tem um pouco de cara de pornô de competência em engenharia, mas gosto desse tipo de história
Li The Phoenix Project alguns anos atrás; era romanceado e apresentava Agile e DevOps de forma bem explícita, mas, para mim, como analista de dados, foi algo novo e gostei. Se houver recomendações semelhantes, eu gostaria de ler
Para citar um bom trecho, Dickerson afixou as regras na parede logo do lado de fora da sala de controle
Regra 1: “Salas de guerra e reuniões existem para resolver problemas. Há muitos outros lugares para gastar energia criativa transferindo culpa.”
Regra 2: “A pessoa que deve falar sobre um assunto não é a de cargo mais alto, mas a que mais entende daquele assunto. Se alguém estiver sentado passivamente enquanto gerentes e executivos falam com informações menos precisas, saímos dos trilhos, e eu quero saber disso.” Dickerson explicou depois que “quando você tira os gerentes do caminho, os engenheiros querem resolver os problemas”
Regra 3: “Devemos nos concentrar nos assuntos mais urgentes que vão nos prejudicar nas próximas 24 a 48 horas.”
A solução é não continuar entregando esse tipo de trabalho às mesmas empresas
Parece claro que empresas como CGI e IBM não são competentes o bastante, e não entendo por que não são proibidas de participar de licitações em contratos futuros semelhantes
Se estragarem um contrato, deveriam ficar excluídas de todos os contratos governamentais pelos próximos 10 anos
Assim teríamos tecnologia que realmente funciona, em vez de continuar reciclando entregas lixo
Por isso, empresas pequenas têm dificuldade para participar
Ou então misturar as equipes
Em breve não vai sobrar ninguém disposto a assumir o trabalho
“Certas tecnologias, incluindo um banco de dados XML chamado MarkLogic” — um banco de dados XML para um serviço essencial usado por 300 milhões de pessoas?
Assustador
Talvez as regras de negócio estivessem em XML e fossem, na prática, somente leitura, enquanto os dados dinâmicos ficavam em um banco de dados relacional
Talvez seja só um palpite esperançoso da minha parte
Pode ter sido um banco de dados de configuração, mas, como o problema parece ter vindo da lógica de negócio, isso por si só já poderia ter sido um problema