Estabelecendo a Viabilidade Mínima com a Constellation Energy

Minimum viability refers to the smallest set of essential capabilitiespolíticas,people, processes, and technologypolíticas,obrigatórioto keep a business operational during a major disruption. 

It requires leadership decisions, cross-functional alignment, and prioritization of outcomes, making it a strategic business discipline rather than a technical exercise. 

With outages often lasting weeks, minimum viability provides the fastest path toajudandorestoreessential operations andreducefinancial and reputational impact. 

Through cross-functional analysis of dependencies, workflows, and identity services, often uncovering critical systems that were previously overlooked. 

Minimum viability is a shared responsibility across IT, security, operations, risk, finance, and executive leadership. 

Assista ao vídeoSaiba mais no SHIFT 2025para ver a transcrição com marcação de tempo

Olá e sejam bem-vindos a este episódio do SHIFT Podcast.

Este episódio tem como foco estabelecer a viabilidade mínima, tornando-a o elemento mais
valioso para o seu negócio.

Olá a todos, sou Vidya Shankaran, CTO de Campo da Commvault, e estou aqui hoje acompanhada por Ha
Hoang, CIO da Commvault Technologies, e Jay, CIO da Constellation Energy.

Obrigada por se juntarem a nós aqui hoje.

Obrigado pelo convite.

Obrigado pelo convite.

Claro.

Normalmente, quando falamos sobre viabilidade mínima, o tempo médio de inatividade registrado
no setor, segundo as estatísticas otimistas, é de 24 dias.

Mas, para a maioria das empresas, esse período é longo demais para ser suportado.

Não é só isso, mas também o impacto financeiro na receita que isso pode causar às empresas,
sem falar no dano à reputação que a empresa sofre durante os 24 dias de

inatividade.

Portanto, hoje, o setor define viabilidade mínima como um conjunto mínimo de recursos que
inclui as pessoas, os processos e, é claro, a pilha de tecnologia que compõem esse

negócio viável.

E alcançar essa viabilidade mínima se torna o momento decisivo para determinar se a empresa
poderá sobreviver e prosperar após um ataque cibernético.

Portanto, como a MV é o tema da nossa discussão aqui hoje, convidei Ha.

e o Jay conosco.

E minha primeira pergunta para Ha seria: como você definiria a viabilidade
mínima, indo além do equívoco que provavelmente existe no setor de que se trata apenas de uma lista de verificação de TI?

Como você conduz isso com uma mentalidade de liderança?

Para mim, a viabilidade mínima tem menos a ver com a pilha de tecnologias e mais com clareza nas decisões.

É perguntar: qual é o menor conjunto de recursos de que precisamos para manter o negócio
funcionando enquanto tudo o mais está fora do ar, certo?

Portanto, é uma mentalidade que exige disciplina, que consiste em priorizar o resultado e não apenas
a infraestrutura, certo?

Então, acho que, quando você aplica essa perspectiva, o planejamento de Recovery se torna uma conversa de liderança
sobre compromissos e não apenas um exercício técnico, certo?

E isso também ajuda a construir uma responsabilidade compartilhada entre as unidades de negócios, o departamento de Risk e
, hum, a TI.

Faz todo o sentido.

Agora, já que temos o prazer de ter você aqui conosco hoje, Jay, o que significa “viabilidade mínima”
para uma empresa de infraestrutura crítica como a Constellation Energy, onde

o tempo de inatividade definitivamente não é uma opção?

Bem, acho que provavelmente concordaria um pouco com o que você estava dizendo.

É o esporte coletivo por excelência.

Certo?

Quero dizer, não é uma discussão exclusiva da área de TI.

Não é uma discussão com unidades de negócios individuais.

Não é uma discussão com a equipe de segurança, nem com a de TI.

É realmente uma discussão com todo mundo.

Porque, na verdade, o que significa “empresa minimamente viável” é exatamente isso, certo?

O que significa para mim continuar operando meu negócio principal?

Certo?

E como isso se traduz na prática?

Então, para mim, acho que a mensagem mais importante é que se trata de um esporte coletivo, porque não é algo
individual

Nenhum grupo consegue fazer isso sozinho.

Adorei isso.

E preciso perguntar isso a vocês dois.

Provavelmente vou dar a palavra ao Ha primeiro.

Houve algum contratempo ou surpresa que o pegou de surpresa enquanto vocês elaboravam a
lista de ativos críticos mínimos viáveis?

Sim, com certeza.

Houve alguns.

Alguns dos sistemas ou aplicativos fundamentais

que achávamos que eram, digamos, essenciais, sabe, certamente não estavam lá, certo?

Ou não entraram na nossa lista.

E então acho que sistemas como o de identidade, que considero mais uma questão secundária, eram
, na verdade, bastante críticos.

E, às vezes, hum, a gente se concentra principalmente no que o cliente vê, que são os
aplicativos, certo?

Mas se você pensar se trata de um serviço de transição, se é identidade, se
são apenas sistemas básicos de interdependência,

esses são os que eu considero essenciais.

Adorei.

Eu acrescentaria que o conjunto todo é que importa.

E se alguém disser que não é assim, tá inventando.

Ninguém fez isso antes, certo?

É a primeira vez que realmente começamos a pensar nisso; sempre falamos sobre
produtos minimamente viáveis, mas nunca sobre empresas minimamente viáveis.

Acho que o mais importante para mim é que tínhamos uma visão muito tradicional do mundo, na qual classificávamos
os aplicativos em alto, médio e baixo valor comercial.

E dizíamos: “Bem, isso é fácil.

Vamos simplesmente recuperar os aplicativos de alto valor comercial e pronto.

O que aprendemos foi que um monte desses aplicativos de baixo valor comercial provavelmente fazia
algo para alimentar ou fornecer algo para o aplicativo de alto valor comercial.

Então, pensar em termos que pareciam muito absolutos não funciona quando se trata de
uma empresa minimamente viável, certo?

Porque estamos falando de um sistema, não de aplicativos individuais.

E essa foi a maior descoberta para nós.

E aposto que foi assim para muita gente.

Acho que essa é uma

expressão que ele acabou de usar, de que não se trata de um produto mínimo viável, mas sim de um negócio mínimo
viável ou de uma empresa mínima viável.

O que me leva ao próximo ponto.

Em todo esse processo, como tem sido sua parceria com seu CISO,
especialmente na definição de alguns desses ativos críticos e em relação a quem toma essas decisões de Recovery

?

Sim, você destacou os ativos críticos, mas então quem ajuda?

a priorizar as operações de recuperação?

É.

Nossa, como eu disse, é um esporte coletivo, mas você também precisa de um árbitro.

Então, acho que, em muitos aspectos, o CIO e o CSO realmente atuam um pouco como um árbitro
nesse caso, porque quando você começa a simular o cenário e analisa, tivemos um ótimo parceiro que

nos ajudou na WWT e que realmente nos ajudou a refletir sobre isso e a passar
tanto pelo processo técnico quanto pelos

vou dizer processos procedimentais, porque o que a gente acaba aprendendo é que todo mundo acha
que a própria área é a mais importante.

Então, acho que o mais importante para o CIO e o CISO se concentrarem é como assumir
esse papel de juiz e jurado, mas também como garantir que se concentrem nas, como você mencionou,

algumas tecnologias fundamentais e essenciais, como identidade e rede, certo?

Sem isso, nada funciona.

Portanto, trata-se também de ajudar as pessoas a entender

essa peça do quebra-cabeça.

É assim que eu vejo o papel deles, certo?

Adorei isso.

De volta pra você, Ha.

Em tudo isso, voltando ao que o Jay disse sobre como isso é um esporte coletivo, você enfrentou algum
desafio ao elaborar o caso de negócios ao apresentá-lo provavelmente para a

, da equipe de risco e da equipe de conformidade?

E quais foram alguns dos equívocos que já estavam arraigados nessas

áreas de negócios e que você precisou esclarecer antes de conseguir vender o caso de uso em
torno da viabilidade mínima?

Ao reunir essas equipes, obviamente, acho que a abordagem da viabilidade mínima precisava
ser diferente, certo?

Tinha que ser em termos de negócios e não nesse jargão de Backup and Recovery, certo?

Então, no caso do setor financeiro, trata-se, você sabe, de proteger a continuidade da receita.

Para as equipes de risco, trata-se de limitar a exposição.

E, para as equipes de operações, o foco é garantir a satisfação dos clientes.

E, portanto, acho que, quando as equipes e as funções se veem refletidas na estratégia de viabilidade mínima
, é aí que ocorre o alinhamento.

E, em termos de equívocos, acho que o maior deles é achar que viabilidade mínima
significa esforço mínimo.

Como se fosse uma questão de baixar padrões ou aceitar uma recuperação parcial.

Essa é uma ótima observação.

A realidade é que é exatamente o contrário, certo?

Hum… Trata-se, na verdade, de disciplina e, hum, de focar no que realmente, hum, impulsiona a continuidade e
a resiliência quando cada minuto conta, certo?

E acho que o outro equívoco é achar que se trata de uma questão puramente tecnológica, certo?

Então, conselhos de administração e CIOs como nós esperam uma lista de verificação ou um diagrama arquitetônico, mas, na
realidade, trata-se de uma conversa sobre estratégia de negócios, certo?

Sobre como as empresas realmente priorizam o valor sob pressão, o que decidem proteger e
por quê.

Adorei esse slogan que você acabou de usar: “como priorizar o valor
comercial sob pressão”.

Eu provavelmente…

colocaria em negrito, destacaria e enfatizaria até enjoar, porque essa é a essência da
própria definição de MVC.

O que me leva ao próximo ponto.

Falamos sobre estratégia.

Falamos sobre como isso é um trabalho em equipe.

Mas quais são os principais KPIs?

Como você quantifica e mede isso?

Essas não são as métricas tangíveis por excelência, não é mesmo?

Ou será que estou deixando passar alguma coisa?

São o RPO e o RPTO que servem de base para suas decisões?

Quais seriam as unidades de medida de sucesso com base no MVC?

Acho que, no meu caso, vou começar talvez menos pelo lado das métricas e, depois, talvez você chegue a elas.

Mas, para mim, o importante é garantir que você não esteja usando o sistema apenas em situações de crise.

Acho que é um equívoco comum ficar parado e dizer: “Vamos treinar isso e
vamos ter isso”.

Para nós, mudamos

todos os nossos backups and recoveries para o Commvault porque queríamos que as pessoas usassem esse sistema todos
os dias.

Então, queríamos garantir que eles soubessem como usar o sistema, como operá-lo,
como lidar com todos os detalhes, porque, você sabe, falamos sobre estar sob pressão,

certo?

Não é nesse momento que você quer experimentar algo novo.

Então, essa é uma das coisas.

E vou acrescentar algo ao último ponto sobre o qual você estava falando, que era outro relacionado à DR,
certo?

Acho que outro equívoco comum é achar que já temos DR.

Por que eu preciso disso?

Certo?

Quero dizer, eu já tenho isso.

E acho que

novamente, se você pensar em DR, é uma mentalidade um tanto ultrapassada, certo?

Tem uma mentalidade que, por falta de um termo melhor, é meio que do tipo “buraco no chão”, certo?

Se eu não tiver essa coisa específica, o que acontece?

Bem, não acho que nenhum dos nossos ambientes exista em menos de cinco outras nuvens ou cinco outros
ambientes.

Então, eu realmente acho que se trata, primeiro, de mudar a mentalidade e, depois, de mudar
suas operações para não agir apenas em caso de crise.

É assim que eu vejo a questão.

Adorei isso.

Concordo plenamente.

É, obviamente, sabe, a gente analisa métricas quantitativas e qualitativas, indicadores,
certo?

E, sabe, tecnicamente, todo mundo vai medir o RPO e o RTO, certo, e
a porcentagem de seus dados de backup válidos e coisas do tipo.

Mas acho que o que também me concentro e acompanho é a rapidez com que conseguimos tomar decisões confiantes
sob pressão, certo?

Porque acho que a Readiness não se resume apenas à rapidez com que podemos recuperar ou restaurar, mas também à
rapidez com que podemos confiar nos dados e no sistema que estamos restaurando.

Então, até que ponto isso realmente se resume à operacionalização dos testes?

Tudo isso.

Muito.

É.

Quero dizer, é sempre isso que importa, certo?

Preparação, prática.

Olha, no nosso mundo, a gente treina bastante.

Nós treinamos tudo o que fazemos.

Porque você quer ter certeza de que, quando realmente precisar ou quando estiver sob pressão,
será capaz de executar a tarefa.

E acho que isso não é diferente.

Talvez a boa notícia — ou a má notícia — seja que todos nós tivemos muitas oportunidades de praticar isso
recentemente, certo?

Seja por causa de interrupções na nuvem ou de provedores que causam problemas, certo?

Tivemos oportunidades de praticar isso.

E outra coisa que eu diria é que você precisa aproveitar essas oportunidades para dizer:
não tenha medo de usar o sistema que você tem, certo?

Você criou um sistema, então use esse sistema.

Como faço para usá-lo

para me recuperar mais rápido?

Como faço para usá-lo, seja para a Recovery de uma nuvem específica ou para lidar com um incidente que esteja
ocorrendo, certo?

Acho que se trata de olhar para frente e usá-lo, e não deixá-lo de lado pensando:
“Ah, será que preciso fazer essa coisa de DR?

Tipo, “eu tenho que fazer isso?”

Todos nós temos essa mentalidade.

Não basta configurar e esquecer.

Isso mesmo, exatamente.

Tipo, já que está aí, use-o.

É, e isso é definitivamente algo que as organizações precisam aprimorar.

Não é algo

exercício que se faz uma vez e pronto.

É um processo dinâmico que você precisa aprimorar continuamente.

E sejamos honestos, ele também está em constante crescimento, certo?

Os dados e tudo mais não estão diminuindo o ritmo.

Provavelmente, para quase todo mundo, o produto que você lançou é uma fração do tamanho do
que você tem hoje.

Isso muda o jogo, né?

Exatamente.

O que me leva à próxima pergunta, a mais crucial, que foi mais difícil.

Foi a execução técnica ou a mudança cultural?

Eu diria que foi a mudança cultural, sem dúvida alguma.

O trabalho técnico é complexo, mas tem solução.

É possível automatizar e testar para chegar à solução.

Mas o mais difícil é a mudança de mentalidade, na minha opinião, de ver a Recovery como uma tarefa de TI para
entender que a resiliência é, na verdade, uma

capacidade empresarial compartilhada.

É.

É.

Quero dizer, eu concordo.

Eu diria que a parte técnica é fácil porque tenho uma equipe técnica incrível e eles
fazem tudo parecer realmente fácil.

Mas eu realmente acho que a tecnologia é algo que dá para resolver, certo?

São uns e zeros, e a gente consegue resolver tudo.

O problema é que essa discussão sempre foi: “Ei, TI, façam o que têm que fazer e nos avisem quando
terminarem”, certo?

Mas essa conversa já não é mais assim.

E, para mim, essa é a maior mudança: agora é preciso reunir todos os líderes de negócios em
uma sala e dizer: “Ei, precisamos conversar sobre Recovery”.

E não é mais apenas: “Ei, TI, avisem quando terminarem”.

E essa é a mudança cultural.

Concordo plenamente.

Acho que, ao avaliar a viabilidade, surgem conversas um tanto incômodas sobre
priorização, certo?

O que realmente precisa acontecer nas primeiras 24 horas versus o que pode esperar.

E é aí que eu acho que

estamos pedindo aos líderes empresariais, essencialmente, que façam escolhas em tempo real, e essas são
as conversas difíceis.

É.

Não, isso faz todo o sentido.

E, especialmente no que você mencionou, se você perguntasse a qualquer líder empresarial, ele
responderia: “Meu AppStack é importante”.

Tudo é importante.

Eu sou o mais importante.

Sim, com certeza.

Então, depois de ter passado por

e me dedicado à construção do seu MVC — e, claro, como acabamos de discutir, esse
é um processo contínuo.

Mas quais são as principais lições aprendidas, as “cicatrizes de batalha” que você gostaria
de compartilhar com seus colegas para que eles não enfrentem os mesmos desafios ao

ao desenvolverem seu MVC?

Eu diria: pratiquem a Recovery, como se fosse dia de jogo, certo?

Porque não dá para desenvolver resiliência em meio a uma crise.

Ela se constrói nos treinos que você faz antes.

Perfeito.

Acho que, para mim — e você já mencionou isso algumas vezes, e eu nunca me canso de enfatizar —,
o ponto-chave é a camada fundamental.

Acho que, tradicionalmente, simplesmente não pensamos na ausência de elementos fundamentais, como
o Active Directory, a rede e tudo mais — agora, tudo isso é definido por software

do que nunca.

E acho que essa é a maior mudança que precisamos realmente respeitar e colocar em prática

e compreender: como seria se eu tivesse que recuperar minha autenticação central antes
que qualquer um da minha equipe pudesse trabalhar?

E é nisso que sempre esquecemos.

O pessoal de TI não consegue fazer nada sem isso.

E acho que essa é a maior cicatriz de batalha.

E, francamente, acho que é uma das coisas que
a Commvault faz melhor do que qualquer outra empresa: a recuperação no nível da floresta do Active Directory, que é tão essencial e foi um dos

principais diferenciais para nós na hora de escolher o produto.

Obrigado.

Obrigado por compartilhar essa visão.

E antes de deixar vocês dois irem embora, quais seriam as frases de efeito, aquelas conclusões
de impacto, que vocês gostariam de nos deixar?

Nossa, acho que acabei de dizer isso.

Treine Recovery como se fosse dia de jogo.

Perfeito.

Adorei isso.

Para mim, é um esporte coletivo.

E você não pode simplesmente deixar isso por conta da sua equipe de TI e dizer: “Ei, me avisem quando estiver pronto”.

Esse é um esporte coletivo em que todos na sala precisam participar da conversa.

Perfeito.

Muito obrigado por estar aqui conosco hoje e compartilhar suas ideias.

Muito valiosas.

E a todos os nossos espectadores que estão conosco virtualmente: se quiserem se aprofundar nos
conceitos de viabilidade mínima, deem uma olhada no nosso Relatório de Análise da Giga Om, que aborda

mais detalhadamente sobre a viabilidade mínima, disponível no site Commvault.com.

Obrigado.