Resiliencia empresarial con el uso de planes de recuperación en la nube de AWS

Pues bueno, bienvenidos a otro webinar. Si saben y los que no lo sepan, cada mes llevamos a cabo uno. Y en este mes de agosto el objetivo es platicar e ir a fondo con el tema de Resiliencia Empresarial con el uso de planes de recuperación en la nube. Este tema es ideal para empresas que desean proteger su información y asegurar la continuidad de su operación. ¿Y qué empresa no necesita y requiere cuidar su información y la continuidad del negocio? En los presentadores estará el Ingeniero Osvaldo Luna, es el ingeniero, Máster, Arquitecto de soluciones y el que más tiene experiencia en estos temas nube, arquitectando ya gran cantidad de proyectos y del otro lado como el consultor experto. Yo tengo ya un par de años de experiencia en temas de consultoría y en áreas de comerciales. Estaré su servidor Carlos González, apoyándolos en cualquier tema, en el webinar y postwebinar. Aquí estaremos. En la agenda tenemos básicamente siete temas bien importantes, de los cuales a partir del tema 3 estará incorporándose el Ingeniero Osvaldo, donde nos platicará bien a detalle técnico y cómo realizar tus planes de resiliencia operativa, cómo cuidar tus aplicativos. En el tema 3, respaldo y recuperación, Resiliencia empresarial con el uso de replicación alta disponibilidad, que es un tema bien importante. Y en el tercer tema tendríamos Estrategias de Resiliencia Multiregión, que es un tema que se ha venido facilitando con la migración a la nube. Y en temas Nubes, ¿Quién es CompuCloud? CompuCloud somos una empresa con más de ya 9 años de experiencia en temas nube. Nos especializamos en temas de Amazon Web Service. Somos un partner consultor, tenemos presencia a nivel nacional y en Centroamérica. Somos especialistas y la especialización es arquitectar soluciones, todo tipo de soluciones cloud dentro de los servicios de Amazon Web Service. Administrar, implementar, migrar, generar respaldos y postventa, monitoreos de la infraestructura en la nube. Tenemos múltiples certificaciones, fuimos Partner Consultor del año en el 2019. Tenemos competencias como el tema Digital Customer Experience y también hacemos el tema de Web Architect Framework, que es un programa con el cual revisamos la infraestructura una vez que quieras migrar a la nube o estando en la nube. Y aquí es un poco para dejarlos pensando. Y lo que me va a tocar a mí platicarles va a ser muy como un tema comercial y más de entregarles el preámbulo a lo que les va a platicar Osvaldo en este punto los dejaría Sabes que a nivel global más de el 54 % de las organizaciones mexicanas han sufrido un ataque cibernético y además En promedio tenemos 13 contingencias al año, en el caso de México el promedio ronda en 12 contingencias, que no precisamente puede ser quizá un ataque dirigido, sino que algún tema de corte en el suministro eléctrico, falta de conexión, entre otros temas que iremos platicando, pero hacer conciencia de que son temas que ocurren y ocurren por año bastantes veces, no solamente una vez. El primer tema que me va a tocar y que no lo comentaba en la pasada agenda que vieron, pero bueno yo lo voy a llevar, ¿Que es tener resiliencia empresarial? Y es bien importante este tema y creo que es muy importante saber qué es tener el tema de resiliencia empresarial y entender qué es precisamente y yo quiero primero ir a lo más básico, de hecho es bueno cimentar las bases, ¿Que es la resiliencia en el sentido de la palabra per se por sí sola, ¿Qué es la resiliencia? Y hablamos que es la capacidad para adaptarse a las situaciones adversas con resultados positivos, quiere decir que cómo reaccionamos ante una situación y que esta situación no nos afecte y podamos salir de la situación con un buen resultado. Entonces hablando de la palabra per se, ahora ¿Que es resiliencia empresarial? Va muy de la mano y brinda a las organizaciones oportunidades de afrontar situaciones adversas y recuperarse y garantizar la continuidad de negocio, hablando del sistema, las plataformas de tecnología, del servicio que se le entrega a nuestros clientes, si somos una empresa que le entrega servicio a un cliente final y cómo aseguramos esta continuidad también ante un tema de alta demanda donde no solamente es un problema, sino que es un problema de múltiples transacciones en nuestros servidores y cómo entregamos este servicio en un pico de alta demanda. Puntos clave y aquí también es como para dejarnos pensando en los puntos clave de la resiliencia y hablamos del tema de cómo afecta la calidad del servicio y la experiencia a los usuarios y ya aquí soy redundante, pero volvemos a lo mismo, estamos hablando de un tema de resiliencia compleja, que la resiliencia compleja que es un tema como el tema de seguridad, es una disciplina de principio a fin que debe incorporarse previamente a que ocurre el problema y no en el problema andando, sino si se implementa en un problema y ya esté ya teniendo el problema va a ser muy complicado recuperarnos de una manera rápida. ¿Estamos? El tercer punto, la resiliencia es un factor clave en los costos, ya que tenemos que saber cuántos sitios, cuántas copias de datos y saber cuánto vamos a respaldar, porque cada punto tiene un costo adicional y tener contemplado este tipo de costo, que al final tenerlo contemplado va a ser un beneficio a largo plazo para darle la continuidad al negocio. La resiliencia en la nube no tiene por qué ser la misma que la TI tradicional, de hecho es un proceso mucho, mucho más rápido y ya estando en la nube, los planes de recuperación suelen ser muy ágiles, de este punto lo platicará más a detalle Osvaldo. Los datos son un elemento vital de sus aplicaciones y la jerarquía de almacenamiento, no todos los datos, conocer y tener bien entendido que no todos los datos son iguales. Quizá hay información que no es tan tan importante, puede ser temas de fotos que igual pueden sacar fotos otro día o si se puede sustituir, pero temas de información que es imposible ya recuperar o volver a crear, si se vuelve muy, muy complicado tenerla y tenemos que utilizar un plan diferente y con mayor.

Seguridad.

En este tema. Aquí en este punto es nomás dejarnos pensando, de igual forma Osvaldo irá yendo un poquito más a detalle y te dirá cómo reaccionar ante este tipo de cosas. ¿Pero qué estás planeando, que tienes un plan de acción si ocurre alguno de los siguientes escenarios? ¿Pensemos un poco, qué pasaría si ocurre uno o múltiples eventos? Y aquí vamos a arrojar una pregunta antes de continuar con punto por punto, donde quisiéramos saber si cuentas con un plan de resiliencia. Es bien importante saber si cuentas con un plan y si no digo el día de hoy, para eso estamos y vamos a desarrollar que al final se costumiza, tiene que ser bien, bien diferente para cada tipo de cliente, todos tenemos diferente tipo de necesidades y vamos viendo que tenemos un sí y un 80 por ciento en no. Y esto digo no tiene nada de malo, De hecho el 70-80% de las empresas a nivel nacional no cuentan con un plan y la reacción a veces en el ataque es cuando comienzan a tomar medidas, pero ya post un ataque o post un evento, este vamos a unos minutos, creo que está el 68% de la participación ya está lista pero quedó en un 27 % el sí y un 73 % el no. Muy bien, pues muchas gracias por sus respuestas, igual pues seguimos avanzando. Vale, voy punto por punto y voy a tratar de ser rápido, pero es básicamente pensar en qué pasaría si ocurre uno o más eventos, donde sea un evento en el servidor, literal ten una problemática en el servidor, una interrupción a nivel rack, interrupción a nivel edificio, por ejemplo, temas de agua, corriente, eléctrica, fuego, donde literal va a ser un daño en específico a nuestro servidor físico, problemas de conexión, un desastre regional, tema de energía, clima, tener que movernos por algún desastre natural o eliminación, modificación accidental de datos y cómo poder recuperar estos datos una vez eliminados. ¿Entonces, qué pasaría? ¿Y esto se queda así como duda, qué pasaría si ocurre alguno de estos eventos en sus servidores? ¿Cómo nos recuperamos si ya tenemos un plan para alguno de estos puntos? Vamos con el siguiente tema que también es importante y es como para quedarnos con la idea de que existe y cómo lo vamos a resolver, repito, se va a ver en los siguientes puntos. Consecuencias de no tener un plan de resiliencia empresarial Las consecuencias pueden ser mínimas, a lo mejor tenemos un ataque que viene encriptó, algo que no era tan importante dentro de nuestra operación, pero podemos tener pérdida de datos, que la pérdida de datos llegue a representar el 43 % de costos, porque estos datos pueden ser hasta propiedad intelectual lo que estamos perdiendo y puede ser más este porcentaje, el 91% de los ataques son spear y phishing, donde alguien te estafa, se hace pasar por alguien más. Solo el 6 % de las empresas que sufren pérdida de datos catastróficos continúa con su operación. A lo mejor hay empresas que definitivamente les pidieron un rescate muy, muy muy elevado a nivel monetario y pues ya no pudieron recuperar toda esa información, entonces podría llevarlos a un cierre. ¿Y por qué recibimos ataques? Comúnmente los ataques es una solicitud de dinero para la liberación de la información y las consecuencias, Hablando de otros puntos de consecuencias, daños a la reputación, problemas legales, pérdida significativa en los ingresos, pérdida de propiedad intelectual y podemos tener vandalismo en línea. Amenazas más comunes Para irnos un poquito más a tema secuestro de información, que estos secuestros comúnmente Windows es el número uno en este tipo de ataques, ocurren más de 4.000 ataques de ransomware al día. ¿Qué es ransomware? Definitivamente alguien que encripta tu información y te solicita un rescate. Y ahorita con el tema del home office, la expansión a hogares ha vuelto un poquito más complicado esta seguridad. Tenemos que generar planes diferentes y un incremento en las etapas de phishing por correo electrónico. Vamos a la siguiente. Aquí en este punto va a comenzar mi compañero y el ingeniero Máster Osvaldo Luna. Él nos platicará de este tercer punto, cómo tener aplicativos resilientes y continuidad del negocio. Aquí empezamos con un fondo más técnico y más de cómo per se ya resolver las problemáticas.

Perfecto, perfecto. Muchas gracias, Charly. Nada más para confirmar que me estén viendo y escuchando correctamente.

Sí, te escuchamos, Inge.

Perfecto. Perfecto. Muy bien. Muchas gracias a todos nuevamente agradezco su tiempo. Y pues, como dicen, vamos a continuar en el tema de la agenda y un poquito un tema más técnico donde vamos a aterrizar todos estos conceptos que mi compañero Carlos pusimos a reflexionar un poquito los antecedentes del por qué tener un plan de resiliencia. Entonces, muchas veces el tema de resiliencia se interpreta como es nomás necesito tener un backup, necesito tener un escenario de replicación. El tema de resiliencia va más allá, donde nosotros aquí en Copuclá lo vamos a dividir como cuatro puntos principales en el tema de recuperación y respaldo, tema de replicación, estrategias de alta disposición y estrategias multisitio y multirregión. Entonces, basada en estas cuatro, vamos a profundizar un poquito en cada una de ellas, en el cual nos va a permitir poder darles a conocer un poco más sobre las tecnologías, sobre la estrategia de resiliencia que necesitaría su organización y sobre todo como CompuCloud y AWS los puede llevar o los puede ayudar para poder establecer esta estrategia de resiliencia. Muy bien, primero que nada, continuamos en el tema de la agenda. Lo primero que vamos a ver la estrategia de resiliencia número la unicial, que es el respaldo y recuperación para asegurar tus datos empresarial. Y antes de entrar en materia, antes de entrar en materia no solo con eso, sino con las otras tres estrategias de resiliencia, primero tenemos unos conceptos clave que nos queremos asegurar que tengan claro. Primero que nada es el RTO y el RPO. ¿Qué es el RTO? Digo, el RPO o por qué va en esta diapositiva al iniciar, pues bueno, principalmente todas las necesidades de resiliencia, como lo bien lo menciona inicialmente, están en función de un RTO y un RPO para cumplir con la función o las necesidades de las empresas acuerdo a estos tiempos. Donde RPO es la información que la empresa está dispuesta a perder, ¿Qué quiere decir? Mis puntos de recuperación es el tiempo máximo que yo estoy dispuesto a perder. Si por ejemplo hacemos una estrategia de backup cada 24 horas, pues bueno, ese es el máximo de información que estoy dispuesto a perder, máximo 24 horas. Y el RTO significa o tiene que ver con el tiempo que las empresas pueden estar sin operar, es decir, en caso de tener una contingencia, cuánto tiempo tengo que estar ya o mis sistemas continuar operando. Entonces es muy importante empezar a generar una estrategia de RTO y RPO. Y creo que aquí tenemos alguna pregunta, Giovanna, Es correcto.

No, solo confirmaban que escuchábamos bien.

Perfecto, muy bien, excelente. Entonces, muy bien, continuamos. Entonces la parte de RTO precisamente, ¿Cuánto tiempo voy a tardar en levantarme en caso de una contingencia? ¿Entonces es tener bien claro estos conceptos y si hoy en día las organizaciones no requieren como tal o no tienen claro cuánto tiempo van a necesitar, cuánto están dispuestos a perder? Es el primer tema que debemos abordar antes de generar o empezar a planear una estrategia de resiliencia. Y la razón por la cual es importante esta estrategia de resiliencia es precisamente porque nos lleva a dos puntos. Primero que nada vamos a contar, saber si ya cuenta con un escenario de DRP, es decir, desde como significa Disaster Recovery Plan, donde principalmente se divide, principalmente, no digo que sean los únicos escenarios, pero principalmente se divide en temas de recuperación y respaldo y replicación como parte de una estrategia de Disaster Recovery Plan, donde vamos a entrar en cada una de ellas en este momento. Y primero vamos a entrar con el tema de respaldo y recuperación, es con lo que vamos a iniciar del primero de los cuatro puntos anteriormente planteados en la agenda. Y antes de entrar en materia, quisiéramos comentarles qué casos de usos o cómo saber si yo requiero un backup o una estrategia de backup y recuperación. Bueno, son algunos casos, no quiere decir que sean los únicos, pero son los más comunes y lo que en base a nuestra experiencia nos ha dado. Primero que nada, cuándo voy a usar una estrategia de resiliencia de backup, una de ellas es el tema de cuando necesito tener un almacenamiento de datos a largo plazo, donde necesito tener datos a manera de histórico y por un tiempo determinado por temas de compliance, por temas de necesidades de la empresa, por las razones que sean. ¿Otro caso de uso recomendado cuando se recuerdan lo que mencioné RPO que lo vamos a estar tocando en toda esta parte, el RPO o el tiempo máximo que me permito para perder información sea mayor a 24 horas, de 24 horas en adelante, es decir, si yo necesito mi backup, hacerlo cada semana o estar recuperando y no pasa nada si pierdo esa información o tengo también cuando el tiempo de estar el tema si son usuarios, si hoy en día no utilizan la nube de AWS, es decir, tienen su infraestructura física on premise que diga sabes qué necesito? Pues una vez que funcione es un aplicativo que pues bueno no pasa nada si me vuelvo a levantar en dos días, ¿Por qué? Porque está el tema de descargar la información, volver a levantar sus servidores y toda esta parte la estrategia es correcta o inclusive si ya son usuarios de AWS con la estrategia de respaldos adecuada que ahorita vamos a entrar, pues también cuando tiene necesidad de una redo de dos horas porque es más corto, si ya son bueno AWS, si es la misma estrategia de backup porque ya están operando en AWS, o sea ya su productivo está en AWS, simplemente en caso de una falla se genera el último backup y a partir de ahí se genera una imagen donde podamos estar más, más rápido recuperar, ¿Por qué? Porque podemos aprovisionar hardware de manera inmediata basado en las imágenes que ya tenemos y es por ello que el tiempo de recuperación se vuelve mucho más ágil ya cuando están en la nube de AWS, pero si no es el caso también podemos apoyarlo. También cuando tienen aplicaciones que no son críticas, que son aplicaciones importantes, aplicaciones de pruebas, aplicaciones puede ser en un tema de desarrollo tal vez que no son core de la empresa, también el caso es un caso recomendado también cuando ya se encuentran con una estrategia de respaldo, es decir, sabes que yo ya tengo mi respaldo de sitio, pero quiero generar un respaldo de mi respaldo o para generar alta disponibilidad en tema de backup por si algo pasa, tengo una contingencia mayor, es decir, se me daña mi rack de servidores, se me daña mi respaldo, poderlo llevar bajo ese sentido y obviamente es un esquema de RPL, es el más económico y también, punto importante, no por ser más económico también nos va a ayudar a generar una protección de datos ante ataques de ransomware. Tenemos casos de clientes que por tener este respaldo con nosotros, lamentablemente tienen en su ambiente productivo un ataque de ransomware y el respaldo se mantiene intacto, entonces no tiene necesidad de arriesgarse a pagar estos rescates ni nada, sino que la información se mantiene íntegra. Entonces este es uno de los casos de uso para el tema de backup. Y el tema de backup también nos permitirá tener diferentes estrategias o métodos de seguridad, donde la estrategia la dividimos en cuatro principales estrategias de backup que va dependiendo a sus necesidades que se pudiera llegar a requerir en su organización. Donde la primera estrategia a nivel de estrategias de backup es la copia de seguridad a nivel imagen. Es decir, yo me llevo el servidor, le saco una fotografía, por decirlo así, con sistema operativo, aplicaciones, particiones de disco duro y me lo llevo hacia otro lado, hacia otro lado, en este caso puede ser hacia la nube de AWS o si ya son usuarios de la nube de AWS, hacia otra región. Las copias a nivel de volumen es igual a nivel imagen, pero ya no necesariamente de una copia masiva de todo el servidor con todas sus particiones, sino que de un volumen específico. Si tiene tres particiones y sabes que quiero sacar una copia a nivel imagen donde se encuentra solamente la partición de sistema operativo y mis aplicaciones, se genera la imagen de esa cuestión y se puede llevar hacia otro sitio o a la nube de AWS con diferentes estrategias. Copia de seguridad a nivel sistema de archivo, es decir, cuando también se conoce como un sistema de temas de manera granular, cuando solamente me interesa respaldar los datos, archivos y que el día de mañana si tengo la necesidad de recuperar ese archivo, pues no necesito levantar o aprovisionar una nueva máquina virtual porque está en una imagen, sino que ya recupero ese único archivo que pudiera llegar a necesitar y se descarga y listo. Entonces ese es un esquema como tal. Y el tema de copias de seguridad basada en aplicaciones y base de datos, más o menos es como el tema nivel archivos, pero también por ejemplo, si tienen una base de datos de SQL Server y quieren mandar el punto back de que genera esa base de datos, pues se manda ese punto back donde les va a permitir también inclusive generar las copias de seguridad de todo tipo, tablas, esquemas, tablas registros, todo lo que tenga que ver a nivel base de datos es toda esta parte. ¿Cuál método les funciona? Pues bueno también depende de la necesidad, donde puede ser como dicen una combinación de uno o varias y obviamente podemos ofrecer métodos de seguridad en varios niveles, comparte nuestra solución de pesas o inclusive podemos generar diferentes estrategias a diferentes niveles. Del lado izquierdo podemos ver el tema de cómo se hace regularmente donde tienen su base de datos en su data center corporativo y ahí mandan los datos, llámese a cintas, llámese a discos e inclusive algunas de ellas generan una estrategia para mandarla a un almacenamiento adicional fuera de las oficinas para contingencias mayores. En el tema de AWS podemos replicar que es el cuadro que está en medio donde ya no necesita montar otro data center adicional, sino podemos hacer uso de los data center adicional cuando están en su corporativo, sus aplicativos principales u operativos y con estrategias podemos mandar hacia la nube de AWS todos estos archivos o todos estos métodos de backup como ya lo mencioné a nivel imagen, a nivel sistemas de archivos, a nivel disco o inclusive a nivel base de datos podemos estarlo mandando con la frecuencia que podemos generar o inclusive si hoy en día ya cuenta o ya dicen soy usuario de la nube de AWS o inclusive también de otro, podemos generar también este mismo esquema. De hecho el método acá pues como dicen por estar en la nube no quiere decir que nos vayamos a olvidar de es una buena práctica resiliencia, pero también el mensaje que les quiero dar que dependiendo el que sea su escenario podemos aprovisionar sin ningún inconveniente. Y aquí está por ejemplo las dos opciones que les mencionaba, un pequeño diagrama de cómo con la técnica de backup y restore podemos ver cómo está en la parte de arriba con un cloud connector, mandar desde sus aplicaciones o inclusive si tienen diferentes sitios concentrarlo también en la nube de AWS donde a través de metodologías donde se puede estar generando inclusive respaldos paralelos, tenemos herramientas que los podemos ayudar para llevar eso a cabo a la nube de AWS, donde no necesariamente tienes que dejarse parte de tu estrategia es seguir respaldando de manera local, lo puede seguir haciendo como se muestra la imagen debajo y estar manteniendo los dos o inclusive solamente mandar a la nube, dependiendo su estrategia podemos apoyarlos y llevarlo a esta parte. Y obviamente parte de las recomendaciones que podemos que nosotros generamos para un backup, primero que nada tiene que ser un tema, un servicio de gestión de copias centralizadas para un buen funcionamiento de una estrategia de resiliencia basado en el tema de backup, pues tiene que ser un servicio centralizado que obviamente se cumplan con los requisitos de respaldos regulatorios y comerciales. Aquí va un poquito lo que hablamos del RTO y RPO, si tienen hoy en día on premise, un RTO de, de por ejemplo de una hora y un RPO de 15 minutos pudiera ser no la opción ideal de resiliencia. Entonces hay que analizar esta parte. Obviamente el tema de backup es el escenario más sencillo y rentable para protegernos y también debe haber parte de lo que ello, debe haber una protección o hay una protección común de datos en las aplicaciones de la nube de AWS y on premise, lo que les comentaba con mandar el tema de AWS Backup estar generando, te permite administrar los respaldos centralizados independientemente donde lo tengas, como bien lo menciona ahí con el conjunto de APIs. Muy bien, entonces hasta aquí ya finalizamos con el tema de backup. Ahora nos vamos a ir al segundo, por decirlo así, la segunda parte de los cuatro que les mencioné, que es la resiliencia empresarial con el uso de replicación. Y este está muy interesante, ¿Por qué? Porque muchas veces hay una línea, una línea muchas veces no tan delgada, algunas otras, entre el tema de backup y replicación, pero se vuelve, es por ello que nosotros la separamos, porque sí hay una diferencia y es lo que queremos establecer o plantearles en esta ocasión. El tema de replicación, primero que nada tenemos que tener cuáles son los casos de uso recomendados. Primero de ellos, si tenemos un rpo menor a 24 horas, es decir, sabes que yo tengo que estarlo haciendo cada 12 horas o tengo que, no me puedo permitir perder más información de una hora como tal, pues bueno, ya la opción de backup pudiera ser no la más adecuada. Entonces es donde tenemos que generar una estrategia de replicación. Muchas veces se malinterpreta como que replicación es todo el tiempo estar replicando en tiempo real, no quiere decir que es el único escenario, sí es uno de ellos, pero el único. Entonces ahorita vamos a entrar más en materia, pero también ¿Cuándo tengo que usar yo un escenario de replicación? Pues bueno, cuando tengamos un RTO menor a dos horas también, es decir, si hoy en día estás trabajando de manera on premise, pero tus requerimientos es tener tu aplicativo arriba al menos de dos horas, pues bueno tenemos que generar esta estrategia donde la nube se convierte en tu aliado, donde ya tienes de manera local tus aplicaciones corriendo y en caso que llegue a fallar o fallar algún servidor o cualquier tema, pues bueno tú puedas continuar operando en la nube de AWS. Y algo muy importante a diferencia del backup, son las aplicaciones a un caso de uso recomendado bastante, bastante interesante es las aplicaciones de misión crítica. Como lo mencionaba anteriormente mi compañero Carlos, no toda la información, no todos los datos son iguales, se tienen que tratar con el nivel de sensibilidad y el nivel de importancia que requieran, porque basado en eso, en ver qué datos en realidad son críticos y que no, se genera una estrategia de resiliencia compuesta. Entonces aquí donde entra que digan sabes que si tengo aplicativos de emisión crítica, que si esos se separan media hora cada minuto nos genera pérdidas monetarias a la organización cada minuto, entonces se tienen que completar o categorizar con una aplicación de misión crítica que puede estar ya sea de on premise, inclusive en alguna otra nube. Y algunos de los ejemplos, no son los únicos, pero algunos ejemplos comunes es su ERP, obviamente el tema de ERP, si las operaciones pararían, pues definitivamente es un tema de misión crítica. Si tienen algún tema de e commerce en el cual se dediquen a temas o la comercialización en línea, pues bueno se cae su e commerce, dejan de vender y pues bueno obviamente es algo de impacto para el negocio. Y a cualificaciones core, aquí ya se pueden ver muchas, cada empresa tendrá sus aplicaciones que son importantes tanto para la operación interna como para las aplicaciones que entregan hacia sus clientes. Y también que otro caso, cuando ya se cuenta con un esquema de respaldo en sitio, pero necesitas una continuidad de negocio en aplicaciones críticas, es lo mismo que mencionaba, tú ya haces tu respaldo de manera local, pero dices de estos 10 servidores que tengo necesito por lo menos el ERP mandarlo a un escenario de replicación sin problemas, tú sigues manteniendo tus otros 9 servidores por decirlo de alguna manera y este otro lo mandas hacia la nube de AWS y también para tener múltiples puntos de recuperación hasta minuto e historial de inversiones. ¿Esto qué quiere decir? Si por alguna razón tú necesitas estar haciendo backups de manera muy seguida, como ahí lo menciona, hasta cada minuto, por ejemplo, cada minuto necesita estar haciendo una imagen y estar haciendo corte y poder tener múltiples puntos de recursos. Recuperación también es algo importante que ya sabes que yo necesito por seis meses guardar el historial de cada minuto porque así lo genera la empresa, o sea yo quiero poder regresar en cualquier parte del tiempo durante seis meses atrás, en cada minuto, cada diez minutos, cada hora, ya dependiendo los puntos se hace o se arma la medida y también es un caso de recuperación o toda esta parte, llámese por temas de compliance o también por ataques de ransomware que también llegan a encriptar la información, pero si su RPO es mayor o menor de 24 horas, más bien esa es la solución para ustedes. Y un esquema orgánico y paulatino de migración hacia la nube de AWS. ¿Este está súper interesante y por qué lo menciono? Porque muchas veces pasa eso ¿No? Hay veces que tenemos necesidades de decir ¿Sabes qué? Lo que pasa es que ya tengo mi infraestructura por vencer o tengo mi infraestructura que está fallando, ya venció la garantía pero todavía tengo que generar o aprovisionar más tiempo. Pues bueno, también es un esquema de estar generando esta parte y preparando el terreno, ¿Por qué? Porque te va a dar los beneficios, uno de ellos ya estás generando una estrategia de ERP como lo mencioné y aparte de ellos podrás estar listo de una manera más rápida cuando requieras hacer una migración hacia el amor, es decir, ya estás encaminado el día de mañana que requieran, miras a la nube, ya como dicen ya recorriste todo el tiempo que regularmente nos lleva más tiempo de planeación migrar, sino ya tú ya te adelantaste y ya no es cuestión de semanas ni de meses, sino ya es cuestión de días o inclusive hasta horas hacer el cambio o el switcheo por completo, es por ello que lo pongo como un escenario más orgánico. Y pues bueno, ¿Cómo funciona el tema de de la parte de ERP? Pues bueno, primero que nada este es un caso de cómo funciona más o menos se hacen instalaciones, obviamente se debe ser temas de agentes para posteriormente se genera la programación de los respaldos o historial o puntos de recuperación que se genera posteriormente que ya se hace la instalación, pues bueno, se genera, se monitorea y definimos con qué frecuencia, cada cuándo y qué historial y se empieza a almacenar todo en la nube y obviamente se genera un esquema de monitoreo y algo importante que es parte también de nuestra oferta, hacemos o hacer ejercicio de recuperación es una práctica que más allá de que así funciona, sino es una buena práctica donde se pruebe constantemente que en realidad funciona. Por qué lo peor que nos puede pasar es de que tengamos el respaldo de ciertas de mis aplicaciones y nunca probarlo y el día de mañana que por alguna razón tengan una contingencia, asegurarnos de que son viables, asegurarnos de que estén totalmente adecuadas y que totalmente sanas, por decirlo así, todos los datos que tenemos. Entonces es algo que nosotros recomendamos y obviamente que tu información esté segura en la nube. Basado en esto, existen tres técnicas de recuperación o de replicación que ahorita estamos el primero de ellas y lo voy a ir los tres que tengo empezando por este, los voy llevando en orden de costo, el tema para qué casos de uso se necesitan y con toda esta parte. Pero antes de comenzar por aquí tenemos una pregunta donde si ustedes actualmente cuentan con un plan de recuperación ante desastre, nos pudieran ayudar a contestar por favor y damos ahí un minutito. Muy bien, tenemos ahí el 70%, ojalá nos puedan apoyar todos a contestar y damos otros 20 segunditos más para continuar. ¿Cuentan con algún tema recuperación desastre? Muy bien, en este momento ya estamos cerrando, les comento que el 35% ya cuenta con un plan de recuperación, me parece excelente, el otro 65% no. Pues bueno, como les comentamos, parece tal vez el webinar para quienes ya cuenten, vean, poder saber si es el correcto o inclusive puedan mejorarlo y los que no, pues bueno, poder darles visibilidad como dice por dónde empezar. Perfecto, muchas gracias Gio. Continuamos entonces precisamente el tema de la primera técnica es una técnica que se le llama el tema de Pilot Light o luz piloto. Este es el esquema de replicación más económico y nos permite tener como dice, un RPO definitivo 15 minutos, es decir, la información que me puedo permitir pues es 15 minutos y un tiempo máximo de recuperación de dos horas. ¿Y por qué lo hacemos? ¿Por qué cumple con esta parte? Bueno, lo menos el escenario más económico y funciona de la siguiente manera. Por ejemplo, hoy en día si ustedes ya cuentan con un escenario de replicación o un escenario de esquema de luz piloto, pues bueno, nos permitirá estar generando, como podrán ver, imaginemos que tenemos un sitio, todo lo va a hacer en función de un sitio web, pero puede viajar perfectamente en su organización. Del lado izquierdo está funcionando todo el tiempo y ya tenemos del lado derecho la estructura o la infraestructura como le llamamos o arquitectura pasiva, es como nosotros la identificamos esta arquitectura, arquitectura pasiva del lado derecho se anticipa, es decir, nosotros configuramos previamente ambientes de replicación, esquemas de conectividad, seguridad, pero se mantiene como lo dice con el tema piloto, es decir, generando consumos muy mínimos en la infraestructura de AWS, es decir, no necesitas grandes gastos para estar generando y simplemente vamos a estar replicando la data de las bases de datos, que es lo que cambia más frecuentemente y en base a eso se va a estar generando esta replicación. Una vez que llegas a pasar o llega a fallar tu replicación, por lo que hacemos, en lugar de apuntar hacia su esquema on premise, apuntamos a lo que está en AWS y empezamos a aprender a encender los recursos como lo dice ahí estaríamos empezando en minutos. Entonces nosotros como ya tenemos todo preparado, pues bueno, es la manera como a través de switcheos y ciertas estrategias de redireccionamiento DNS y toda esta parte podemos continuar la operación. Se hace un trabajo previo y se mantiene con un esquema de consumo muy mínimo y es por ello que es el escenario más económico. El siguiente es como decir WARN Standby, donde tenemos algo prendido como tal y del otro lado sí lo tenemos comprendido pero no atendiendo cuestiones de productivas, esto aplica, ese es un escenario un poquito más costoso que el anterior. ¿Por qué? Porque aquí implica tener recursos prendidos en la nube de AWS, es decir, ya tenemos no sólo la data que vamos a estar recibiendo, sino vamos a estar generando o van a estar prendidos los servidores. Y esto es para cuando requerimos un RTO súper más agresivo, donde el RPO se sigue manteniendo, porque al final de cuentas lo hacemos con la misma herramienta y podemos seguir manteniendo RPO, pero el RTO se baja a 30 minutos. ¿Por qué? Porque ya está algo ya preparado, ya no hay que encender, ya no hay que hacer redirecciones por completo, sino simplemente nos enfocamos en enrutamiento y es por ello que se genera. ¿Y cómo funciona? Pues de manera sencilla tenemos el tema como lo pueden ver en las flechas, todo el enrutamiento se está manejando a su esquema on premise, por ejemplo, y lo vamos llevando hacia o vamos replicando toda la data y en el momento que tengamos una contingencia, pues bueno simplemente lo convertimos en ambiente productivo, ya no hay nada que aprender, ya estaba aprendido solo nada más estaba en standby, se convierte en esquema productivo. Posteriormente generamos la técnica de un Doctor Multisite o también muchas lo conocemos como activo activo. Este es el escenario más caro porque no solo involucra, muchas veces no sólo involucra tener la infraestructura aprendida, sino se requieren generar o tener herramientas adicionales, contratar software adicionales de fabricantes especializados e integrarlos con la nube AWS para llegar a tener un RPO, un RTO Near 0 como se conoce en la industria, es decir, muy cercano a cero, donde no puedes quedarte casi casi ni un minuto fuera de operación. Obviamente de los 15 minutos que está anterior, al estar cerca de cero, los costos sí cambian disruptivamente, si hay mucho incremento, porque precisamente reitero el mayor reto es el tema de estar generando temas de aplicaciones o sobre todo bases de datos. Pero lo importante de ello también es de la cuestión de lo que tenemos en el tema de la base de datos. Podemos llegar a nosotros también a poder generar servicios administrados de AWS. En AWS hay bases de datos administrados que funcionan de manera global, donde ya te facilita esta estrategia como lo podemos ver para que puedas llegar a tener este mirror todo el tiempo y que podamos de una manera muy sencilla haciendo uso y la tecnología WC con base datos administrar, poder llegar a ser global y generar esta estrategia a costos mucho más bajos como lo hicimos de manera tradicional. Servicios de base de datos relacionales como aurora por ejemplo, auroraDB o inclusive no relacionales como DynamoDB. ¿Entonces toda esa parte es como lo vamos a estar manejando y sobre todo lo importante para finalizar gráficamente lo que ya comenté, pues bueno tenemos aquí el espectro y opciones de Doctor cuál es el doctor que me convierte o la estrategia de recuperación de datos? Pues bueno, dependiendo de qué tan azul o hasta más rojo que involucra o el color tiene que ver con la criticidad de la información y qué tan rápido necesitemos recuperarnos, esta es una estrategia que les va a poder ayudar. ¿Cuál va a ser la estrategia? Entre más a la derecha esté, quiere decir que necesitas recuperarte más rápido y tus datos son más críticos. Nos vamos a ir con la estrategia DDR Multisite o si algo no es tan crítico y tampoco necesitas una recuperación tan rápida en cuestión de minutos, pues también nos iríamos del otro sistema Backup in restore. Entonces, esto es un ejemplo gráfico que el objetivo era como aterrizar más lo que ya mencionamos. Y pues bueno, vamos al siguiente punto de la agenda, vamos a avanzar para que no se nos acabe el tiempo. ¿Pues el tema de la alta disp, definitivamente es un escenario donde muchas veces la confusión, oye que AWS no es disponible? Por supuesto, maneja altos niveles de disponibilidad, más sin embargo, también tenemos que buscar el tema resiliencia, que va desde basado en la arquitectura, es decir, tú ya estás en productivo, tú ya utilizas la nube de AWS, pero qué tengo que hacer o para qué casos de usos, Pues bueno, también cuando el RTO se ha acercado a cero, también cuando las aplicaciones de misión críptica, por ejemplo, basadas en web, bases de tipo e commerce, de tipo streaming o inclusive cuando las aplicaciones con necesidad de altos niveles de SLA, es decir, necesito tener porque lo que tengo ahí está basado, está en contratos con mis clientes y queda un minuto fuera. Entonces esto es también para esta parte. Y algo importante que siempre debemos de tener un Doctor Es, es decir, si nosotros generamos un escenario de alta disponibilidad, también el Doctor Una estrategia de Doctor Dependiendo del termómetro anterior, también debe ser considerado. Porque una cosa es tener la arquitectura, estamos generando arquitectura alta disponibilidad y tolerante a fallos, pero que debe estar siempre presente, no olvidarnos de los backups o de la replicación según las necesidades. Y también alguna práctica recomendable es un ciclo de DevOps, que ya posteriormente hemos tenido algunos webinars hablar de DevOps y podemos posteriormente profundizar más en este tema. Pero esto tiene que ver ¿Por qué? Porque todo el tema de actualizaciones, updates y toda esta parte, un ciclo DevOps ayudaría a mantenerse constantemente en deployment continuo con ambientes de pruebas, ambientes de desarrollo y sin tener que estar con las famosas ventanas de mantenimiento donde dices, ¿Sabes qué? Es que quiero implementar una nueva actualización y voy a dejar fuera a mis usuarios por una hora. Entonces también es un caso de uso recomendado, algo integrar al tema de alta disponibilidad. ¿Y cómo lo hacemos? Pues bueno, simplemente se puede generar uso de la arquitectura global de aws, que consta 21 regiones y 66 zonas de disponibilidad y también 187 bordes o endpoint como le llaman para garantizar temas de latencia. Y obviamente existen las definiciones también de alta disponibilidad. ¿Que es importante o a qué me refiero cuando hablo de alta disponibilidad? Pues bueno, como mencioné, es mejorar el tiempo de que un sistema tiene la actividad. El tema recuperación, desastre, es donde vamos a involucrar también tema de lo que ya hablamos de Doctor Y sobre todo enfocado a la continuidad del negocio. ¿Que quiere decir? Mejorar el funcionamiento de todos los aspectos de su aplicación y conectividad, etcétera, que puedan llevarlos o ayudarlos a tener esta parte. Así más o menos como se ve un diagrama de cómo podemos utilizar las regiones múltiples, las zonas de disponibilidad, donde podemos tener dividido el aplicativo en diferentes zonas de disponibilidad, que por ahí ya les mencioné, ¿Sale? Pero ahorita vamos a aterrizarlo. Pero un punto importante o importantísimo, por no decir lo menos, es el tema de tenemos que eliminar el primer punto.

Esto es del proyecto anterior, el target group.

Perdón, creo que ahí alguien abrió el micrófono, perdón. Entonces, perdón. El tema de eliminando los únicos puntos de falla, por ejemplo, debemos de quitar eso es lo primero que se debe considerar. ¿Qué quiere decir? Que ahorita se los voy a ejemplificar, pero tiene que ver con tener servicios administrados de AWS, esquema serverless, por ejemplo, auto provisionamiento, donde podamos responder de manera automática ante eventos que se prendan y se apaguen solas las instancias, agrupación de clústeres de servidores balanceados, tanto para servidores de aplicativo como bases de datos y sobre todo tener la conectividad de red. Entonces, ¿A qué me refiero con eliminar el punto de falla? Pues bueno, una arquitectura que tiene un único punto de falla es por ejemplo esta que ven ahorita en pantalla, donde tenemos un servidor con una IP pública, imaginemos que es un website, todos los usuarios se conectan al dominio, la página web y en ese servidor una estructura monolítica, pues tenemos hasta la base de datos. Esta es, por decirlo así, una mala práctica si queremos llegar a tener un escenario de alta disponibilidad. Entonces, basada en este tema de alta disponibilidad, tendremos que llevar una arquitectura que está así, a llevarla a un nivel como lo están viendo, donde el mismo website, estamos generando una arquitectura que ya no depende solo de un servidor, sino depende de muchos microservicios, bases de datos, autoadministrada, como pueden ver, el tema de aurora, grupos de autoescalamiento, lo que les mencioné que nos va a permitir crecer y decrecer de manera importante, de manera importante la infraestructura y sobre todo generar el tema de seguridad y balance estas partes. Entonces ese es un claro ejemplo de cómo quitaríamos un único punto de falla y cómo generar una arquitectura de alta disponibilidad que se vuelve parte de las estrategias de resiliencia. Y vamos al último punto no menos importante técnico, el que es un tema multirregión, multisitio, que es muy parecido al del tema de alta disponibilidad, pero sobre todo si ya son usuarios, si ya son usuarios de la propia nube de AWS o inclusive que tienen actualmente una parte como tal compliance, primero que tenemos que tener un RTO o los casos recomiendo menores a cero, aplicaciones de misión crítica basadas en webs, e commerce, streaming, aplicaciones con altos niveles de SLA, también si necesitan generar una estrategia de entrega global o de tienen usuarios que se conectan de todo el mundo para ofrecer la misma experiencia de usuario, también es algo importante a considerar un caso de uso. Aplicaciones que corran en otra nube o inclusive en on premise también puede ser un caso de uso. Y también como se los mencioné anteriormente, no olvidar el tema de un plan de DRP, siempre debe estar presente y recomendar un ciclo de DevOps. Simplemente aquí está cómo se muestra el tema de la estrategia como tal de web services, de multirregión y donde diferentes vamos a poder tener general intercambio de tráfico en múltiples zonas de disponibilidad en nubes privadas, están migrando imágenes de uno a otro, se vuelve parte de una estrategia también como tal. Y pues bueno aquí lo estamos llevando también a una estrategia también multirregión en AWS, donde ya mi misma carga de trabajo no solo está en Estados Unidos, sino que está por ejemplo en una región de Estados Unidos y una región de Europa donde tenemos distribuida la carga y puede ser hasta más donde hay servicios administrados como les comentaba de manera global como Dynamo, DB, NoSQL que nos permite por ser nativa global, nos permite generar un tema de adopción hacia la nube o adquirir un esquema multirregión y un esquema multisite. Aquí hay una arquitectura, es decir, ya ahorita este es un ejemplo, por ejemplo si ya cuenta con ustedes con VMware, entonces la diferencia que en lugar de que esté en una región de AWS como la anterior de Estados Unidos y una región de Europa, por ponerlo un ejemplo, este es donde combinamos del lado derecho se encuentra el tema de AWS con bimwork y del lado izquierdo su data center, entonces también se puede hacer un escenario donde a través de esta parte podamos volver a recomendar, podamos recomendar o dirigir las cargas entre un sitio u otro y poder una misma carga de trabajo, poder generar una arquitectura multisite para aplicaciones también como les mencionaba de tipo críticas. Y pues bueno, consideraciones, lo mismo que he mencionado, el tema RTO consider arquitectura de red, replicaciones, temas de monitoreo, controles de seguridad, sobre todo temas de servicios administrados deben de estar siempre presentes en toda esta parte. Y pues bueno, hasta aquí concluiría mi participación, muchas gracias mi estimado Charly, te cedo los micrófonos.

Muy bien Osvaldo, digo, buenísima toda la información y creo que nos quedamos con algo muy valioso, esto no se construye de un día para otro. Cabe mencionar que la experiencia, los nueve años de experiencia de CompuCloud nos permiten llevar este tipo de presentaciones a este nivel de profundidad y platicando de puntos importantes, hablando a 360 grados de un tema de resiliencia. Buenísimo, vamos con la pregunta, No sé si quieras iniciar primero con la pregunta Giovanna, que tenemos ya para comenzar con la conclusión y ¿Estarías dispuesto a adaptar un plan de resiliencia para asegurar la continuidad de las actividades de tu organización? Digo, en una metáfora es como si habláramos de nuestro seguro de auto, ¿Estarías dispuesto a tener un respaldo para en dado caso que tengas un accidente, no tengas que descapitalizarte o perder tu dinero de un one shot, sino que tengas tu respaldo para que alguien más te ayude a poder hacer este pago y solventar los gastos? Pero es más como hablando de tu seguro de continuidad y de protección de tu información, es de suma importancia que aquí parte de la conclusión, digo, adelantándome un poco en lo que que llevamos las preguntas al término, es que un plan de resiliencia va a ser como lo comentaba Oswald, lo comentó a lo largo de la presentación, es muy diferente para todos nos ayudará a llevar un plan de resiliencia customizado, es el plan de CompuCloud, que lleven a cabo un plan adaptado y diseñado hasta la medida, porque recordando, todos tenemos las mismas necesidades. ¿Creo que ya cierras con las preguntas o vamos a continuar? Creo que tenemos un 54% y en este punto como conclusión, Comps te ayudan a tener aplicaciones recientes independientemente si usas la nube, si estás on premise o si utilizas otra nube, generar un plan a la medida es de suma importancia. Independientemente cómo estás trabajando al día de hoy, adoptar un modelo que se adapte a tus necesidades. Y este punto es el que se habló a lo largo de la presentación. Un modelo a la medida customizado para tu tipo de cargas, tus tipos de información. Este análisis, este assessment se lleva a cabo por CompuCloud y te entregamos de la mano de Osvaldo y todo un área de ingeniería bastante robusta dentro del equipo y el área comercial. Te llevamos hacia un escenario donde conocerás los costos para tu tipo de modelo de negocio que tengas. Como este tercer punto, la resiliencia debe tener en consideración desde el inicio del ciclo de proyecto. Quiere decir que pensar en ello antes de que suceda una problemática y no ya cuando sucedió. Entonces nuestra preparación o nuestro. Nuestro día a día ya tiene que estar pensado en tener un plan de recuperación de resiliencia. Entonces esto se tiene que pensar de ya y con Puclado los vamos a ayudar a que se lleve a cabo. Perdón por repetir lo mismo, pero es de su importancia que lo sepan. Recuerda que ya como último punto, la resiliencia es fundamental para las empresas, ya que es un seguro para la continuidad y para la protección de su información. La resiliencia es compleja, no es igual para todos y además tienen que ser modelos que se tienen que realizar previamente a tener alguna problemática. Va de la mano con generar un plan completo. La resiliencia es un factor clave en los costos. La resiliencia en la nube no tiene que ser precisamente la misma que la del tema de TI tradicional. Hablando on premise, los tiempos de recuperación no son los mismos, pero de todos modos llevamos el assessment para cualquier tipo de escenario. Los datos son elementos vitales para aplicativos. Creo que esto ya quedó claro. Los datos son de suma importancia para los aplicativos y la continuidad del negocio. Jerarquía de almacenamiento. No todos los datos son iguales y hay datos que son mucho más importantes que otros con los que tenemos que tener mayor calidad de protección. Y ya como la última invitación, los invito y los invitamos en plural, a quien se acerquen a nosotros, ya sea conmigo o ahorita las otras dos personas que les voy a comentar, los ejecutivos de otras zonas, a recibir una consultoría personalizada, que esta consultoría es literal, una consultoría 360 grados para conocer cómo trabajan actualmente y hacer un plan customizado a la medida para que tengan un plan de resiliencia en la nube de AWS y probar por 15 días sin costo este plan de recuperación customizado, entendiendo que previamente necesitan el punto 1, hacer esta consultoría de la mano de los expertos de Compu Cloud y posteriormente, una vez llevando la consultoría, que este primer punto es un punto que literal nos da la apertura, saber qué van a necesitar para llegar al segundo punto. No sé si tengan alguna duda aquí puntual. Se abre el foro de preguntas. Aquí sigue, de todos modos, Osvaldo, de costos, Pues primero hablamos de la consultoría. Ya estarían acercándose conmigo.