Podcast: Reproduza em uma nova janela | Download (Duração: 39:55 – 36,5 MB)
Assine: Podcasts da Apple | Spotify
Mass Brigham CTO Nallan (Sri) Sriraman analisa os riscos da nuvem que reviveram a conversa sobre transparência SaaS que os sistemas de saúde deixaram em silêncio. Assista abaixo ou no YouTube.
Nalan (Sri) Sriraman, Diretor Técnico, Massachusetts. General Brigham
Após uma série de interrupções na nuvem pública no outono passado, General Brigham de Massachussets O CTO Nallan (Sri) Sriraman chegou a uma conclusão desconfortável. A sustentabilidade multirregional pela qual os sistemas de saúde pensavam que estavam a pagar era, em alguns casos, uma ilusão. Especificamente, regiões de nuvem projetadas para falhar implementaram planos de controle compartilhados de forma independente. Enquanto isso, os provedores de SaaS hospedados nessas nuvens não tinham obrigação de divulgar onde suas cargas de trabalho estavam realmente localizadas.
Em resposta, ele publicou uma carta aberta aos fornecedores de SaaS pedindo maior transparência. Os motivos eram claros. Especificamente, quando um hiperescalador falha, os sistemas de saúde precisam saber em minutos se o seu software crítico está exposto.
A disciplina que foi esquecida
A diferença, diz ele, se deve a uma mudança de 15 anos na forma como o setor de saúde compra software. Quando os aplicativos eram executados no local, as equipes de TI faziam perguntas detalhadas sobre resiliência durante a entrega. À medida que as cargas de trabalho foram migradas para a nuvem, assumiu-se que a independência regional estava incorporada. Na prática, esta suposição falhou.
“Também notamos que alguns hiperescaladores de nuvem gerenciam o plano de controle de forma colaborativa”, disse Sriraman. “Assim, quando uma região cai, a outra cai. Esses serviços estão interconectados.”
Segundo ele, a ligação é uma falha de design não intencional que os fornecedores corrigirão assim que ocorrer. Mais fundamentalmente, a questão é institucional. Durante mais de uma década, clientes e fornecedores deixaram de ter conversas sobre sustentabilidade. O custo deste desvio só se torna visível quando algo falha.
31 de outubro e o mapa de vulnerabilidade
Em 31 de outubro de 2024, o raio da explosão tornou-se privado. Esse dia era o prazo final para registrar os benefícios dos funcionários no sistema médico acadêmico de US$ 23 bilhões. O site de benefícios desapareceu. O Brigham General eventualmente rastreou a interrupção até um parceiro SaaS hospedado no hiperescalador afetado. A essa altura, os funcionários já reclamavam há horas.
A lição foi direta. Construa um mapa de vulnerabilidade. Desenvolva um questionário e envie-o a cada grande parceiro de SaaS. Pergunte em qual hiperescala eles estão sendo executados, em qual região e como é a sequência de failover. Pergunte também quem desencadeia uma transição de falha e quanto tempo leva. Para contratos existentes, a maioria dos parceiros compartilha de bom grado quando solicitado. Entretanto, para novos contratos, a janela de contratos públicos proporciona uma alavancagem natural.
Em sua experiência, os parceiros compartilham prontamente quando solicitados. Na verdade, a conversa sobre sustentabilidade simplesmente morreu há mais de uma década. Na verdade, reiniciá-lo exige mais disciplina do que alavancagem.
Nível 0 e o cartão de recuperação
Ao mesmo tempo, o General Brigham conduzia um exercício interno sobre a criticidade dos pedidos. Especificamente, o sistema classifica os aplicativos em seis camadas. O nível 0 cobre infraestrutura básica, como conectividade WAN, acesso sem fio e DNS. Tudo isso deve ser confirmado antes que a recuperação do aplicativo possa começar. Além disso, o nível 1 inclui EHR, exames laboratoriais, banco de sangue e outros sistemas clinicamente importantes. Os níveis restantes descem em ordem de prioridade.
A interrupção do CrowdStrike aprimorou a estrutura. Quando todos os sistemas ficam inativos ao mesmo tempo, as equipes de TI precisam de uma sequência pré-construída para seguir. Como resultado, Sriraman alterna o EHR de produção entre dois data centers a cada seis meses. Ambos os ambientes permanecem em alguma condição de funcionamento. Além disso, os exercícios de mesa são realizados em cadência normal. Ressalta-se que a classificação de gravidade pertence à equipe de preparação para emergências que faz a ligação com base nos fatos apresentados pelas equipes de tecnologia.
Em última análise, o relacionamento operacional é central para tudo isso. A classificação envolve médicos e empresários decidindo quais 200 dos 2.000 aplicativos devem aparecer primeiro. A TI então constrói a sequência de recuperação em torno dessas prioridades.
Leve embora
- Crie um mapa de vulnerabilidade SaaS. Documente em qual hyperscaler e região cada parceiro principal está sendo executado, além da sequência de failover e dos pontos de acionamento.
- Reabra a conversa sobre sustentabilidade. Os provedores compartilharão informações mediante solicitação; disciplina é o que se perde.
- Verifique a independência da região. Verifique se os planos de controle são compartilhados entre regiões, pois alguns designs de hiperescala os conectam.
- Cada nível de aplicativo. Uma classificação de seis níveis, incluindo o Nível 0 para infraestrutura, fornece lógica de triagem quando todo o resto falha.
- Um data center alternativo está em operação. O reencaminhamento periódico da produção entre locais mantém ambos prontos para um failover real.
- Deixe as operações classificarem a gravidade. As equipes de preparação para emergências devem fazer uma chamada de importância alta-média-baixa a partir dos fatos apresentados pela TI.
Seu diagnóstico remonta a um hábito ausente que definiu as operações de TI por décadas. “Esquecemos de fazer as perguntas”, disse Sriraman.
