A primeira pergunta foi o que é DR? Obrigado. Obrigado. Cara, o que é um DR? Um DR é um cenário onde eu preciso criar um cenário de redundância ou resiliente a falhas. Então, disaster recovery. Então, eu preciso ter um cenário onde, num caso de falha, eu consiga levar os meus usuários para esse meu ambiente e minha operação continua sendo executada de forma que o usuário não perceba que a falha aconteceu. Disaster recovery. Certo? E aí, às vezes, por exemplo, ah, Fernando, eu trabalho num banco. Num banco, a gente trabalha com o Prime-C. E aí, eu preciso ter um desastre recorre, porque, ah, num caso crítico, eu quero transbordar os meus usuários para este ambiente, para que a operação continue. Fernando, está fazendo sentido para mim. Eu escutei falar que tem uns serviços que são multizonais. Normalmente as pessoas buscam ambientes multizonais ou em várias regiões, em várias zonas. Por quê? Porque aí eu consigo construir um DR no caso de que se uma zona vir a ter uma falha, eu levo ou redireciono os meus usuários para outra zona. Então, eu vou utilizar a outra zona como um disaster recovery. Então, o ambiente de disaster recovery, a grande pergunta que as pessoas fazem normalmente é, Fernando, se eu quero ter um RTO e um RPO com o menor número possível, aí vai vir a pergunta, o que é um RTO e um RPO, Fernando? Pode ser que venha. Eu quero ter o tempo entre a falha e o tempo de recuperação muito próximo do zero. Então, quando eu quero ter o tempo de falha e o tempo de recuperação muito próximo do zero, Então, quando eu quero ter o tempo de falha e o tempo de recuperação muito próximo do zero, possivelmente eu vou ter que ter o N mais 2 ou o N mais X já pré-provisionado, para evitar que no momento de eu direcionar os meus usuários para aquele DR, eu não tenha que provisionar o ambiente em tempo de transferência de usuário ou em transferência de workload. Às vezes o negócio é tão crítico, mas tão crítico, que não dá tempo para isso. Então, você imagina eu provisionar um cenário onde eu tenha lá de venda, onde eu, quando for fazer esse chaveamento, se eu não tiver a máquina pré-provisionada, eu provisionar, por exemplo, 200 máquinas em questões de minutos, sei lá, mil máquinas em questões de segundos. Cara, às vezes não faz sentido, não dá tempo para isso. E às vezes o negócio é tão crítico que eu vou perder uma venda. Então, num cenário desse de DR, às vezes os clientes nos procuram falando, cara, eu não posso ter o DR desidratado, ou eu posso ter um DR desidratado num percentual X. O que eu quero dizer com isso? Dentro desse ambiente de disaster recovery, talvez eu não suporte 100% dos usuários numa cacetada só, numa transferência só. Pode usar a palavra cacetada aqui? Pode, pode. a palavra cacetada aqui? Pode, pode. Numa casa só. Mas eu quero suportar 30% deles e de forma gradativa eu ir estendendo a quantidade de servidores conforme os workloads vão sendo redirecionados para o DR. É onde entra a capacidade de crescer de forma elástica. Um escalonamento horizontal, né? Putz, eu vou, Eu vou crescendo ali, aumentando a quantidade de servidores, conforme o orquídeo vai aumentando. Então, tem que lembrar, por que isso é muito importante? Porque, lógico, que o RTO e o RPO, essas duas métricas, para mim, elas são hiper relevantes para eu entender qual é o número do N mais X. Vamos chamar assim, tá gente? N mais X, eu falei de N mais 2, vamos falar mais de N mais X, tá? Pode ser? Perfeito. Porque o que vai acontecer? Pode ser que essa quantidade aqui extra de servidores que eu vou adicionar, ela só vai ter relevância quando eu entender na minha operação qual que é o meu RPO e qual que é o meu RTO. Qual que é o tempo entre falhas e o tempo de recuperação que eu quero ter. Em alguns ambientes não críticos isso é irrelevante. O cara vai falar, cara, eu aguento uma hora. Putz, cara. Hoje nem percebeu que o negócio está fora exato, hoje uma máquina ela sobe em minutos na nuvem vamos ser muito sinceros se eu tenho lá o meu terraform pré-provisionado é mais rápido ainda certo? se eu vou na console na forma básica se eu tiver muitas máquinas, eu vou demorar muito tempo. Mas se eu tenho lá a minha infraestrutura como código, para eu provisionar isso em outro endereço é muito rápido. Mas, lógico, essas duas variáveis aqui, elas vão ser sensíveis e vão me determinar isto daqui. Tem sentido agora para quem pergunta isso? Elas vão ser sensíveis e vão me determinar isso daqui. Tem sentido agora para quem pergunta aí? Quanto mais crítico, provavelmente eu preciso de mais extras. Exato. Quanto mais crítico, possivelmente mais extras. Quanto mais crítico, eu vou até escrever aqui, menos desidratado. Menos desidratado. Menos desidratado. E você fala em relação a desidratado, é. Quantos caras já prontos para aguentar a pancada quando um desastre começa a acontecer, né? Isso, qual que é a condição mínima de pré-provisionado que eu tenho que ter para isso, certo? Lógico, porque a gente vê pessoas falando, cara, eu quero estar próximo do zero. Há cenários desses também de clientes que estão, cara, eu estou próximo do zero no meu DR. Por quê? Porque na transferência do workload para esse DR eu consigo crescer de forma tão rápida que esse meu desidratado consegue responder de forma rápida para que eu consiga responder todo o workload faz sentido o que eu estou falando? Perfeito Galera, se puder responder um ok, um joinha para o Wesley, eu agradeço Se não fez sentido por favor, me fala que eu volto a explicar