Latest / M365.FM – Podcast de Microsoft 365, Copilot e IA en español / Azure Chaos Studio explicado: chaos engineering, inyección de errores y apps resilientes en Azure (Doblaje IA)

Transcript

Azure Chaos Studio explicado: chaos engineering, inyección de errores y apps resilientes en Azure (Doblaje IA) · M365.FM – Podcast de Microsoft 365, Copilot e IA en español

• 0:01
  Speaker 2: Listo para 10 días de Microsoft 365, Copilot y Azure
• 0:04
  Speaker 2: y las personas que están dando forma al futuro del trabajo?
• 0:07
  Speaker 2: Este enero, M365 con regresa y venimos con más fuerza.
• 0:12
  Speaker 2: Unas a nosotros para sesiones en vivo, demostraciones reales y
• 0:15
  Speaker 2: conocimientos prácticos de MVP y expertos de la industria en
• 0:17
  Speaker 2: todo el mundo. Nada de diapositivas genéricas, ni términos de
• 0:20
  Speaker 2: moda sin sentido. Abordamos los desafíos reales. Copilot Studio, agentes
• 0:24
  Speaker 2: de IA, Fabric, Seguridad, Gobernanza y Automatización. Ya sea que
• 0:30
  Speaker 2: usted sea un profesional de TI, desarrollador o líder empresarial,
• 0:33
  Speaker 2: hay sesiones diseñadas para usted. Con 10 días completos, puede
• 0:37
  Speaker 2: explorar múltiples tecnologías y conectar con una comunidad global. Vea
• 0:41
  Speaker 2: las sesiones en vivo y lleve ideas prácticas de regreso
• 0:43
  Speaker 2: a su organización. Enero de 2027. 10 días. Una sola
• 0:48
  Speaker 2: comunidad de Microsoft. El registro ya está abierto. Vaya a m365com.net
• 0:54
  Speaker 2: y asegure su lugar hoy mismo. Esto es m365com.net. Únase
• 1:00
  Speaker 2: ahora en m365com.net y nos veremos.¡ En vivo en enero!
• 1:05
  Speaker 2: Bienvenidos a otro episodio de Microsoft Knowledge Nuggets. Soy su
• 1:07
  Speaker 2: anfitrión Milko Pit.¿ Qué pasaría si pudiera romper sus propias
• 1:10
  Speaker 2: aplicaciones en la nube a propósito y de forma controlada
• 1:12
  Speaker 2: para hacerlas más fuertes? Suena contradictorio, pero es la misma
• 1:14
  Speaker 2: lógica que usan los bomberos al realizar quema controlada. Encienden
• 1:17
  Speaker 2: fuegos pequeños a propósito para eliminar males de seca. Así
• 1:20
  Speaker 2: cuando dicen diorreal no queda nada que quemar. Eso es
• 1:22
  Speaker 2: lo que Azure Chaos Studio hace por sus aplicaciones en nube.
• 1:25
  Speaker 2: Al final de este episodio, entenderá qué es el servicio,
• 1:27
  Speaker 2: por qué querría usarlo y cómo le ayuda a construir
• 1:29
  Speaker 2: sistemas que no colapsan cuando algo sale mal. Así que
• 1:33
  Speaker 2: tome su café y empecemos con el problema. El problema.¿
• 1:36
  Speaker 2: Por qué las pruebas tradicionales no son suficientes? Esto es
• 1:39
  Speaker 2: lo que sucede con las pruebas tradicionales. Verifican si el
• 1:41
  Speaker 2: software funciona según lo diseñado bajo condiciones normales. Te gira
• 1:44
  Speaker 2: una prueba, la ejecuta y si el resultado coincide, te
• 1:46
  Speaker 2: da prueba. Es excelente para detectar errores, pero no ve
• 1:49
  Speaker 2: cómo se comporta su sistema cuando algo inesperado falla, como
• 1:52
  Speaker 2: un tiempo de espera de una máquina virtual que muere
• 1:54
  Speaker 2: o una zona de disponibilidad completa que se apaga. Las
• 1:57
  Speaker 2: aplicaciones modernas en la nube ya no son simples. Son
• 1:59
  Speaker 2: sistemas distribuidos que se comunican con bases de datos, cachés,
• 2:02
  Speaker 2: servicios de identidad, API de terceros y otros microservicios, y
• 2:04
  Speaker 2: todas esas piezas tienen dependencias ocultas. Una pequeña falla puede
• 2:07
  Speaker 2: causar un efecto dominio en todo el sistema. Una base
• 2:09
  Speaker 2: de datos se vuelve lenta, la aplicación se agota, el
• 2:11
  Speaker 2: balanceador de carga la marca como no saludable, el tráfico
• 2:13
  Speaker 2: se redirige, otras instancias se saturan y de repente todas
• 2:15
  Speaker 2: las aplicaciones funcionan. Las pruebas tradicionales no detectan esto porque
• 2:19
  Speaker 2: prueban en condiciones perfectas, con todo disponible, latencia red cero
• 2:21
  Speaker 2: y nadie apagando máquinas virtuales durante la ejecución de la prueba.
• 2:25
  Speaker 2: Así que usted despliega en producción sintiéndose confiado hasta que
• 2:27
  Speaker 2: la realidad lo golpea. Y esa falsa confianza es peligrosa
• 2:29
  Speaker 2: porque es la diferencia entre saber que tu sistema funciona
• 2:31
  Speaker 2: y saber que sobrevive. Y sobrevive. Y ahí es donde
• 2:34
  Speaker 2: entra la ingeniería del caos.¿ Qué es realmente la ingeniería
• 2:37
  Speaker 2: del caos? La ingeniería del caos es un método práctico.
• 2:40
  Speaker 2: Inyectas fallas reales y controladas en tu sistema y observas
• 2:42
  Speaker 2: cómo reacciona. Esto no sucede en un laboratorio o una simulación.
• 2:46
  Speaker 2: Sucede en tus recursos reales. La idea es simple. Empieza
• 2:49
  Speaker 2: con una hipótesis, algo como si perdemos una máquina virtual,
• 2:51
  Speaker 2: el balanceador de carga debería seguir dirigiendo el tráfico a
• 2:53
  Speaker 2: las instancias restantes. Luego ejecutas un experimento. Apagas la máquina
• 2:57
  Speaker 2: virtual y observas qué sucede. El balanceador de cargas es
• 2:59
  Speaker 2: su trabajo. La aplicación se relaciona. Tus aletas se activan correctamente.
• 3:02
  Speaker 2: Mides todo y luego reparas lo que se rompe. Aquí está.
• 3:06
  Speaker 2: La ingeniería del caos no es destrucción aleatoria. No es
• 3:09
  Speaker 2: un desarrollador entrando a la sala de servidores a desconectar
• 3:11
  Speaker 2: cables por diversión. Es científica y repetible con restricciones de seguridad.
• 3:15
  Speaker 2: Tú defines el rato impacto y controlas exactamente qué falla,
• 3:17
  Speaker 2: cuándo y por cuánto tiempo. Y lo más importante, aprendes
• 3:20
  Speaker 2: de él. Cada experimento te brinda evidencia. O tu hipótesis
• 3:23
  Speaker 2: era correcta y tu sistema es resiliente, o estaba equivocada
• 3:25
  Speaker 2: y encontraste una debilidad que corregir. De cualquier manera ganas.
• 3:29
  Speaker 2: El desafío es que crear tus propias herramientas de ingeniería
• 3:31
  Speaker 2: del caos es difícil. Tendrías que escribir scripts para apagar
• 3:34
  Speaker 2: máquinas virtuales, inyectar presión en la CPU, bloquear tráfico de
• 3:36
  Speaker 2: red y orquestar todo eso de forma segura y repetible.
• 3:39
  Speaker 2: Es mucho trabajo y esa es exactamente la razón por
• 3:41
  Speaker 2: la que Azure creó un servicio de ministro de automóvil.
• 3:43
  Speaker 2: Presentamos Azure Chaos Studio. Azure Chaos Studio es un servicio
• 3:46
  Speaker 2: total administrado para ejecutar experimentos de caos directamente en tus
• 3:49
  Speaker 2: recursos de Azure. Sin scripts personalizados, sin herramientas terceros, sin
• 3:52
  Speaker 2: tener que construir tu propia plataforma de inyección de fallas.
• 3:55
  Speaker 2: Todo está en el portal de Azure listo para usar.
• 3:57
  Speaker 2: Así es como funciona. Chaos Studio te da dos formas
• 3:59
  Speaker 2: de inyectar fallas. Las fallas directas de servicios se ejecutan
• 4:02
  Speaker 2: a través del plan de control de Azure. Dices a
• 4:04
  Speaker 2: Chaos Studio que apague una máquina virtual y lo hace
• 4:06
  Speaker 2: a través de la propia API de Azure. No se
• 4:08
  Speaker 2: necesita gente. Las fallas basadas en agentes instalan un pequeño
• 4:10
  Speaker 2: agente dentro de tu máquina virtual. Luego puede llevar la
• 4:13
  Speaker 2: CPU al 100%, llenar la memoria o eliminar un proceso específico.
• 4:17
  Speaker 2: Esto te permite simular problemas que ocurren dentro del sistema operativo,
• 4:20
  Speaker 2: no solo a nivel de recurso. Aquí hay una analogía.
• 4:23
  Speaker 2: Imagina que eres dueño de un gran edificio de oficina.
• 4:25
  Speaker 2: Quieres saber si tus salidas de emergencia realmente funcionan. Esperar
• 4:27
  Speaker 2: un incendio real es una pésima idea, así que contratas
• 4:30
  Speaker 2: un equipo especializado en desastre. Entran, bloquean una escalera, simulan
• 4:33
  Speaker 2: humo en el tercer piso y observan cómo reacciona la gente.
• 4:35
  Speaker 2: Eso causa estudio. Es tu equipo de desastre. Los llamas
• 4:38
  Speaker 2: realizan el simulacro y aprendes si tu edificio es seguro
• 4:41
  Speaker 2: antes de que llegue la emergencia real. Chaos Studio admite
• 4:44
  Speaker 2: una amplia gama de recursos de Azure, máquinas virtuales, conjuntos
• 4:48
  Speaker 2: de escalado de VM, blústeres de Azure Kubernetes Service, Azure
• 4:52
  Speaker 2: Cosmos DB, Azure Cache for Redis, grupos de seguridad de
• 4:54
  Speaker 2: red y más. La biblioteca de fallas sigue creando. Así
• 4:58
  Speaker 2: que ya sea que ejecutes una aplicación simple de dos
• 5:00
  Speaker 2: niveles o una arquitectura compleja de microservicios en AKS, puedes probarla.
• 5:03
  Speaker 2: Aquí están las noticias. No necesitas construir ninguna herramienta personalizada.
• 5:06
  Speaker 2: Todo está disponible a través del portal de Azure, las CLI,
• 5:08
  Speaker 2: las API REST, las plantillas IRM, OVICIO. Puedes definir tus
• 5:11
  Speaker 2: experimentos como código e integrarlos en tus canalizaciones de desplazamiento.
• 5:14
  Speaker 2: Pero no nos adelantemos. Primero analicemos cómo están estructurados realmente
• 5:18
  Speaker 2: estos experimentos. Los bloques de construcción, objetivos, pasos, ramas y acciones.
• 5:22
  Speaker 2: Todo experimento de Chaos comienza con objetivos. Es un objetivo.
• 5:25
  Speaker 2: Es simplemente un recurso de Azure contra el cual quieres
• 5:27
  Speaker 2: ejecutar fallas. Abre Chaos Studio, buscas tu recurso 1AVM, un
• 5:30
  Speaker 2: conjunto de escalado, un clúster de AKC y lo incorporas.
• 5:34
  Speaker 2: Esto significa que le dices a Chaos Studio Este recurso
• 5:36
  Speaker 2: está disponible para experimentos. Aquí está. Al incorporar un objetivo,
• 5:40
  Speaker 2: también eliges qué fallas estás dispuesto a permitir en ese recurso.
• 5:43
  Speaker 2: No habilitas todo. Tú eliges. Presión de CPU.¿ Apago VM?
• 5:47
  Speaker 2: Quizás no para producción. Tú decides. Una vez incorporados tus objetivos,
• 5:51
  Speaker 2: quedas un experimento. Piensa un experimento con un plano. Describe
• 5:54
  Speaker 2: exactamente qué fallas inyectar, en qué orden, contra qué objetivos
• 5:57
  Speaker 2: y por cuánto tiempo. No solo dice rompe algo. Defines
• 6:01
  Speaker 2: todo el escenario desde el principio. Los experimentos tienen una
• 6:03
  Speaker 2: estructura simple. Pasos, ramas y acciones. Los pasos se ejecutan
• 6:06
  Speaker 2: en un trazo. Termina el paso 1, luego comienza el
• 6:08
  Speaker 2: paso 2, luego el paso 3. Así es como modelas
• 6:10
  Speaker 2: una línea de tiempo. Primero degradas la red, luego estresas
• 6:13
  Speaker 2: la CPU y después apagas una VM. Cada paso es
• 6:15
  Speaker 2: una fase en tu escenario. Dentro de cada paso puedes
• 6:18
  Speaker 2: tener una o más ramas y es donde las cosas
• 6:20
  Speaker 2: se ponen interesantes. Las ramas se ejecutan en paralelo. Entonces,
• 6:23
  Speaker 2: dentro del paso 1, podrías tener la rama A añadiendo
• 6:25
  Speaker 2: latencia a tu base de datos y la rama B
• 6:26
  Speaker 2: aumentando la CPU en tus servidores web, ambos al mismo tiempo.
• 6:29
  Speaker 2: Esto te permite simular escenarios complejos de fallas múltiples que
• 6:32
  Speaker 2: reflejan incidentes del mundo real. Luego tienes la sección. Las
• 6:35
  Speaker 2: acciones son las fallas reales. Presión de CPU, agotamiento de memoria,
• 6:38
  Speaker 2: apagado de VM, retraso de red, bloqueo de DNS, cierre
• 6:40
  Speaker 2: de procesos. Cada acción apunta a un recurso específico o
• 6:43
  Speaker 2: un grupo de recursos. Y nuevamente, solo puedes usar acciones
• 6:46
  Speaker 2: que hayas habilitado en ese objetivo. Esa es tu red
• 6:49
  Speaker 2: de seguridad. Si no habilitaste el apagado de VM en
• 6:51
  Speaker 2: un objetivo, el experimento simplemente no ejecutará esa acción. Así
• 6:53
  Speaker 2: que el fluido de trabajo se ve así. Incorpora tus objetivos.
• 6:56
  Speaker 2: Habilita las fallas con las que te sientas cómodo. Crea
• 6:58
  Speaker 2: un experimento con pasos, ramas y acciones y luego ejecútalo.
• 7:01
  Speaker 2: Pero antes de empezar a ejecutar uno, hay algo importante
• 7:03
  Speaker 2: que entender. Cuando Chaos Studio ejecuta un experimento y no
• 7:06
  Speaker 2: está simulando nada,¿ realmente está haciendo estas cosas a tus recursos?
• 7:09
  Speaker 2: La presión de CPU es presión de CPU. Un apagado
• 7:11
  Speaker 2: VM es un apagador. Ese es el objetivo principal. Estás
• 7:14
  Speaker 2: probando cómo se comporta tu sistema bajo condiciones de falla real.
• 7:17
  Speaker 2: Y eso significa que debes tener cuidado. Entonces veamos un
• 7:19
  Speaker 2: experimento real y cómo se integra todo. Ejecutando tu primer
• 7:22
  Speaker 2: experimento de Chaos. Hagamos esto real. Imagina que tienes una
• 7:25
  Speaker 2: aplicación web ejecutándose en tres máquinas virtuales dentro de un
• 7:27
  Speaker 2: conjunto de escalado de máquinas virtuales. Cada VM vive en
• 7:30
  Speaker 2: una zona de disponibilidad diferente. Tienes un equilibrador de carga
• 7:33
  Speaker 2: al frente distribuyendo el tráfico entre las tres. La hipótesis
• 7:35
  Speaker 2: es simple. Si perdemos una zona de disponibilidad completa, el
• 7:39
  Speaker 2: equilibrador de carga debería redirigir el tráfico a las dos
• 7:41
  Speaker 2: VMs restantes y la aplicación permanece disponible. Entonces diseñas un
• 7:45
  Speaker 2: experimento con dos pasos. Paso 1. Estresar dos de las
• 7:48
  Speaker 2: tres VMs al 95% del CPU durante 5 minutos. Eso
• 7:51
  Speaker 2: simula un escenario de vecino ruidoso o un proceso descontrolado.
• 7:55
  Speaker 2: Paso 2. Apagar abruptamente todas las VMs en la zona 2.
• 7:58
  Speaker 2: Eso simula una interrupción de zona real. Ejecutas el experimento
• 8:01
  Speaker 2: y luego observas tu sed. Eso es lo que vería.
• 8:03
  Speaker 2: En los primeros 5 minutos, dos UVMs llegan al 100%
• 8:06
  Speaker 2: de CPU. La tercera permanece normal porque no la seleccionaste.
• 8:10
  Speaker 2: Tus tableros de monitoreo se iluminan, las alertas se disparan,
• 8:12
  Speaker 2: el equilibrador de carga nota que esas dos UVMs están
• 8:14
  Speaker 2: luchando pero como técnicamente siguen funcionando, continúa enviándoles tráfico. Tu
• 8:18
  Speaker 2: aplicación se ralentiza pero no se desconecta. Es interesante. Ya
• 8:21
  Speaker 2: aprendiste algo. Luego entra en juego el password. Sus UVMs
• 8:23
  Speaker 2: en la zona 2 se apagan abruptamente, no de forma
• 8:25
  Speaker 2: controlada ni con una advertencia. Simplemente desaparece. Una de esas
• 8:28
  Speaker 2: dos UVMs estresadas estaba en esa zona, así que desaparece.
• 8:31
  Speaker 2: El equilibrador de carga ve que la prueba de estado falla,
• 8:33
  Speaker 2: la elimina del grupo de backend y enruta todo el
• 8:34
  Speaker 2: tráfico a las UVMs sanas restantes. Tu aplicación para MSI.
• 8:37
  Speaker 2: La hipótesis se sostiene. Pero esto es lo que quizá
• 8:40
  Speaker 2: no esperes. Las máquinas virtuales restantes ahora deben manejar el
• 8:43
  Speaker 2: 100% del tráfico. Si no tuviera suficiente capacidad para absorber
• 8:45
  Speaker 2: esa carga, vería pico de latencia. Quizás la aplicación técnicamente
• 8:48
  Speaker 2: siga en línea, pero los usuarios sienten el problema. Eso
• 8:51
  Speaker 2: es un hallazgo. Ahora sabes que necesitas más margen o
• 8:53
  Speaker 2: un escalado automático más rápido. Y recuerda, esto no es
• 8:56
  Speaker 2: una simulación. Cuando Caos Studio ejecute este experimento, esas máquinas
• 8:59
  Speaker 2: virtuales realmente llegan al 95% de CPU. Ese apagado a
• 9:02
  Speaker 2: la zona 2 es un apagado real. La máquina virtual
• 9:04
  Speaker 2: se detiene, el balanceador de carga se reequilibra y tu
• 9:06
  Speaker 2: aplicación sobrevive o no. Ese es el punto principal. No
• 9:08
  Speaker 2: estás adivinando. Estás observando el comportamiento real bajo condiciones de
• 9:12
  Speaker 2: falla real. Aprende si tu aplicación se mantiene activa o
• 9:14
  Speaker 2: se cae. Y si se cae, la arreglas antes de
• 9:16
  Speaker 2: que tus clientes lo vean suceder. Pero este poder conlleva responsabilidad.
• 9:20
  Speaker 2: Debes tener cuidado. La seguridad es primero, evitando interrupciones no planificadas.
• 9:24
  Speaker 2: Chaos Studio tiene múltiples mecanismos de seguridad integrados. Y antes
• 9:28
  Speaker 2: de ejecutar tu primer experimento, debes entender cada uno de ellos.
• 9:31
  Speaker 2: La primera capa de seguridad es la identidad de los permisos.
• 9:34
  Speaker 2: Cada experimento que creas obtiene su propia identidad administrada asignada
• 9:36
  Speaker 2: por el sistema. Pero esa identidad comienza con cero permisos
• 9:39
  Speaker 2: de forma predeterminada. Debes otorgarle explícitamente acceso a los recursos
• 9:42
  Speaker 2: que necesita y otorgar los permisos mínimos requeridos. Si un
• 9:45
  Speaker 2: experimento solo necesita estresar la CPU en dos máquinas virtuales,
• 9:49
  Speaker 2: limita los permisos en lugar de permitirle apagar todo en
• 9:51
  Speaker 2: el grupo de recursos en el grupo de recursos. Luego
• 9:53
  Speaker 2: está la habilitación de fallas que mencioné antes. Cuando incorporas
• 9:56
  Speaker 2: un objetivo, eliges exactamente qué fallas estás dispuesto a permitir.
• 9:59
  Speaker 2: Si nunca habilitas el apagado de UVM en un conjunto
• 10:01
  Speaker 2: de escalado de producción, ningún experimento puede apagarlas. Es un
• 10:05
  Speaker 2: bloqueo estricto que requiere que aceptes deliberadamente cada tipo de falla.¿
• 10:10
  Speaker 2: Ahora por dónde empezar? La respuesta es simple. Empieza poco
• 10:13
  Speaker 2: a poco y en un entorno que no sea de producción.
• 10:15
  Speaker 2: Ejecuta tus primeros experimentos en desarrollo pro. prueba con una
• 10:18
  Speaker 2: sola máquina virtual y una sola falla y valida que
• 10:20
  Speaker 2: tu monitoreo funcione, tus alertas se disparen y puedas cancelar
• 10:23
  Speaker 2: el experimento si algo sale mal. Solo después de haber
• 10:26
  Speaker 2: generado esa confianza en un entorno seguro, deberías siquiera pensar
• 10:29
  Speaker 2: en tocar la producción. Microsoft tiene una advertencia al respecto
• 10:32
  Speaker 2: que quiero compartir directamente. Lo llaman un evento generador de currículums.
• 10:36
  Speaker 2: Si ejecutas un experimento de caos en producción sin las
• 10:38
  Speaker 2: medidas de seguridad adecuadas y de regla toda tu aplicación,
• 10:40
  Speaker 2: es el tipo de error que podría costarte el empleo.
• 10:42
  Speaker 2: Es un hiperbole. Cada estudio es poderoso porque realmente hace
• 10:46
  Speaker 2: cambios en tus recursos, así que usa ese poder sabiamente.
• 10:49
  Speaker 2: La última red de seguridad es la supervisión de cancelación.
• 10:52
  Speaker 2: Mientras se ejecuta un experimento, puede ver el progreso en
• 10:54
  Speaker 2: tiempo real. Usted ve qué pasos se completaron, qué ramas
• 10:57
  Speaker 2: están activas y qué acciones se están ejecutando. Si algo
• 11:00
  Speaker 2: parece incorrecto, presiona cancelar y el experimento se detiene de inmediato.
• 11:04
  Speaker 2: Los recursos afectados permanecen en el estado en que se encuentren,
• 11:06
  Speaker 2: pero no se inyectan nuevas fallas. Así que mantenga sus
• 11:09
  Speaker 2: paneles abiertos y el dedo en el botón de cancelar.
• 11:11
  Speaker 2: Empiece poco a poco, sea deliberado y respete el poder
• 11:12
  Speaker 2: de la rama. Entonces, ahora que sabe cómo mantenerse a salvo,
• 11:15
  Speaker 2: la pregunta es,¿ dónde debería ejecutar estos experimentos? Desplazamiento a
• 11:19
  Speaker 2: la izquierda frente a desplazamiento a la derecha. Entonces,¿ dónde
• 11:21
  Speaker 2: ejecuta realmente estos experimentos? Existen dos enfoques principales y la
• 11:24
  Speaker 2: mayoría de los equipos utilizan ambos. El primero es el
• 11:27
  Speaker 2: desplazamiento a la izquierda. Ejecuta experimentos de caos al principio
• 11:30
  Speaker 2: de su ciclo de desarrollo. Tan pronto como el código
• 11:33
  Speaker 2: se implementa en un entorno de prueba, le aplica fallas
• 11:35
  Speaker 2: y lo hace parte de su canal de CICI, El
• 11:38
  Speaker 2: canal despliega la aplicación, ejecuta un experimento de caos para estresarla,
• 11:41
  Speaker 2: verifica que sobreviva y solo entonces promueve la compilación a
• 11:43
  Speaker 2: la siguiente etapa. Piensa en ello como una puerta de calidad,
• 11:46
  Speaker 2: al igual que las pruebas unitarias o los escaneos de seguridad.
• 11:49
  Speaker 2: Si la aplicación no puede manejar el apagado de una
• 11:51
  Speaker 2: VM en pruebas, no pasa a producción. El segundo enfoque
• 11:53
  Speaker 2: es el desplazamiento a la derecha, lo que significa ejecutar
• 11:55
  Speaker 2: experimentos en producción. Y sí, eso suena aterrador, pero escúchame,
• 11:59
  Speaker 2: no se empieza por ahí. Solo se desplaza a la
• 12:01
  Speaker 2: derecha después de haber generado confianza en entornos que no
• 12:03
  Speaker 2: son de producción. Recomienza con experimentos pequeños y limitados. Tal
• 12:06
  Speaker 2: vez estrese la CPU en una instancia durante un periodo
• 12:09
  Speaker 2: de bajo tráfico. Lo observa de cerca, aprende y lo expande.
• 12:12
  Speaker 2: Quizás apague una sola UVM en producción durante el horario
• 12:15
  Speaker 2: laboral y valide que su balanceador de carga realmente redirige
• 12:18
  Speaker 2: el tráfico, que sus usuarios no noten nada y que
• 12:20
  Speaker 2: su supervisión lo detecte todo. Con el tiempo usted avanza
• 12:23
  Speaker 2: hacia experimentos más agresivos. Existe un tercer enfoque que se
• 12:26
  Speaker 2: sitúa en el medio, los días de juego. Un día
• 12:28
  Speaker 2: de juego es un simulacro de caos programado donde reúne
• 12:30
  Speaker 2: a su equipo de desarrollo, equipo de operaciones, equipo de seguridad,
• 12:32
  Speaker 2: todos los que estarían involucrados en un incidente real. Usted
• 12:35
  Speaker 2: ejecuta un experimento de caos y practica su respuesta incidental.¿
• 12:38
  Speaker 2: Quién recibe el alerta?¿ Quién toma la decisión?¿ Cuál es
• 12:40
  Speaker 2: la cadena de comunicación?¿ Qué tan rápido puede diagnosticar el problema?
• 12:43
  Speaker 2: Los días de juego prueban la tecnología, pero lo que
• 12:45
  Speaker 2: es más importante prueban a las personas y los procesos creadores.
• 12:48
  Speaker 2: La idea clave en los tres enfoques es que la
• 12:49
  Speaker 2: ingeniería del caos no es una prueba única. No ejecutas
• 12:52
  Speaker 2: un experimento, declaras que tu sistema es resiliente y sigues adelante.
• 12:55
  Speaker 2: Los sistemas cambian, el código cambia, las configuraciones cambian, las
• 12:58
  Speaker 2: dependencias cambian. Lo que era resiliente el mes pasado podría
• 13:00
  Speaker 2: ser frágil hoy. El objetivo es la validación continua de
• 13:03
  Speaker 2: la resiliencia.¿ Ejecutas experimentos regularmente?¿ Los integras en tu proceso
• 13:07
  Speaker 2: de lanzamiento y los haces parte de tu ritmo operativo? Entonces,¿
• 13:11
  Speaker 2: cuál es el valor real de todo este esfuerzo? El
• 13:13
  Speaker 2: valor real es generar confianza. La ingeniería del caos hace
• 13:16
  Speaker 2: más que encontrar errores. Genera confianza y eso es algo
• 13:18
  Speaker 2: completamente distinto. Un error es un defecto específico. Lo corriges
• 13:21
  Speaker 2: y sigues adelante. La confianza es un sentimiento. Es saber
• 13:24
  Speaker 2: que tu sistema puede sobrevivir a lo inesperado y eso
• 13:26
  Speaker 2: no se logra solo con pruebas unitarias o de integración.
• 13:30
  Speaker 2: Se obtiene al ver cómo tu sistema maneja una falla
• 13:32
  Speaker 2: real y sale adelante. Este proceso te obliga a mejorar
• 13:35
  Speaker 2: cosas que de otro modo ignoraría. Tu monitoreo, por ejemplo.
• 13:38
  Speaker 2: Al ejecutar un experimento de caos, descubres rápidamente si tus
• 13:41
  Speaker 2: tableros muestran las métricas correctas, si tus alertas se activan
• 13:44
  Speaker 2: en los umbrales adecuados y si tu equipo de guardia
• 13:46
  Speaker 2: recibe la notificación a tiempo. Si no puedes ver que
• 13:49
  Speaker 2: la falla está ocurriendo, no puedes responder a ella. Los
• 13:51
  Speaker 2: experimentos de caos brechas. También descubres suposiciones. Todo arquitecto ha
• 13:55
  Speaker 2: dicho algo como si la base de datos se cae,
• 13:57
  Speaker 2: la aplicación debería simplemente guardar los últimos datos conocidos y
• 13:59
  Speaker 2: seguir funcionando. Eso suena bien a una pizarra, pero funciona realmente.
• 14:03
  Speaker 2: Pero una vez por todas. Sus experimentos de cabo responden
• 14:05
  Speaker 2: a esa pregunta con evidencia real. Apagas la base de
• 14:07
  Speaker 2: datos y observas que su... Quizá la aplicación lo maneja correctamente.
• 14:10
  Speaker 2: Quizá se bloquee.