Monitoreo de apps con MTTD y MTTR

Curso de Fundamentos de Observabilidad con New Relic

Contenido del curso

Bienvenida al curso

1
Observabilidad en sistemas digitales complejos
04:33 min

¿Cómo funciona la web moderna?

Observabilidad y monitoreo

Telemetría y tipos de datos

Reto: Monoliths y Microservices

13
Uso de New Relic: Análisis de Mapas de Aplicaciones Web
02:29 min

Cierre y despedida

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:008:28

Monitoreo de apps con MTTD y MTTR

Curso de Fundamentos de Observabilidad con New Relic

Clase 6 de 15

Clase 6 / 15

Comentarios (41)41 comentarios

Jaime Iván Muñoz Enriquez

Hace 4 años

Monitoreo Acto de recolectar constantemente datos del sistema y rendimiento. Con la finalidad de ser visualizados y trakeados , para identificar lo que va mal y resolverlo

APM: Significa Aplication Performance Monitoring Un Ejemplo: Monitoreo de bebé.

Cuatro pasos para monitorear:

Planear
Instrumentar
Observar:
Detectar y resolver

Este proceso debe ser un ciclo, Ocurre constantemente

El monitoreo debe responder con SI/NO

¿Nuestro servicio esta en línea y disponible?
¿Está funcionando correctamente?
¿Está funcionando bien?

MTTD: Tiempo promedio a detección (debería ser lo mas bajo) MTTR: Tiempo en resolver el problema y logró resolverlo

Jonathan Barzola

Hace 4 años

Maravilloso aporte Jaime! Muy claro la verdad.

Ana Karina Serrano Romero

Hace 4 años

muy buen resumen!

Gerardo Alberto Soto Alvarez del Castillo

Hace 4 años

En la cultura ++DevOps, el éxito de un equipo se mide en cuanto tiempo/costo les toma contestar a todas las preguntas del monitoreo++ de forma positiva.

++Para medir el éxito++ del equipo DevOps ++se hace de forma cuantificada++ y de forma numérica (mediante un rango) y ++utilizando 2 métricas clave utilizadas en la industria:++

MTTD (Mean Time-to-Detection): Tiempo promedio a detectar un problema (debería ser lo mas bajo).

MTTR (Mean Time-to-Resolution): Tiempo promedio en resolver el problema.

Hay un puesto en la industria Tech llamado ++“Site Reliability Engineering”++ que forman parte del equipo DevOps e Infraestructura, y ++suelen estar muy atentos a estas métricas (MTTD y MTTR).++ . ¿Tú que piensas qué debe hacer un equipo para poder tener unas métricas bajas en MTTD y MTTR?

Para tener métricas bajas en MTTD lo mejor es ++tener un buen sistema de monitoreo,++ ya sea de todo el sistema o poner más atención en las partes de la aplicación donde acceden más los usuarios, así como también ++un buen sistema de Test lo más parecido al uso en producción.++
Para tener métricas bajas en MTTS lo mejor es ++simular errores en la aplicación una vez al día en un ambiente controlado++ (Test), y tomar métricas para ir mejorando la velocidad de solución y de esta manera, el equipo de Developments, DevOps y Infraestructura comprenden como funciona la aplicación y como va evolucionando.

Reinaldo Mendoza

Hace 4 años

Gran resumen

Emmanuel Rodríguez

Hace 4 años

📚 Google SRE Engineering .

Al hacer preguntas amplias, obtendrás respuestas amplias e incertidumbre sin contexto.

. Como bien es dicho en la sesión: . Existe un rol llamado Site Reliability Engineering (SRE) en DevOps, los cuales se enfocan en la construcción e implementación de servicios que permiten a los equipos de TI y/o soporte realizar mejor su trabajo. . Entre sus responsabilidades, se enfocan en la preparación, monitoreo y respuestas a incidentes de un sitio o plataforma. . Sin embargo, recordemos que DevOps es también una cultura transversal en una empresa. Por lo que en un desarrollo maduro, generar ciertas métricas, requiere que: .

Tu negocio permita esas métricas
Tu equipo en cuestión, madure en ese ámbito
Tu aplicación / plataforma, sea extendido para ese fin

. Recordemos que: .

Partiendo de buenas prácticas de desarrollo, documentadas y actualizadas, requieren de intención que si no son llevadas al acto, todo SRE quedará reducido.

. Yo empezaría para MTTD y MTTR: .

Documentando
Proyectar MVPs, de servicios o módulos internos.

. Con la mejora del 1%, se toma un banderazo de partida 🤟

Reinaldo Mendoza

Hace 4 años

Genio

Benjamin Arteaga

Hace 4 años

Muchas gracias por compartir.

Tommy Toala Cox

Hace 4 años

¿Qué significa monitoreo?

Es la manera en que recolectamos datos de nuestro sistema y el rendimiento
para poder observarlo de manera rápida y eficaz
con el fin de tomar medidas respecto a cualquier problema que pueda suceder con nuestra aplicación y resolverlo.
Con el fin de que tenga poco o nada de impacto hacia tus clientes o negocio

¿Cómo vamos a monitorear?

Aplicaremos Application Performance Monitoring(APM), que es una serie de pasos que seguiremos para realizar un buen monitoreo.

Pero primero

¿Qué vamos a monitorear?

En general, los desarrolladores monitorean

Tráfico del sitio
Velocidad de carga
poder de cómputo que estamos usando
- CPUS,
- memoria servidor
bases de datos
servicios de terceros
micro servicios
etc

Sabiendo que podemos monitorear prácticamente todo de nuestra aplicación, seguiremos el siguiente proceso para realizar un buen monitoreo.

Plan
1. Proceso en el que se decide que se va a monitorear
Instrument
1. En la instrumentación adecuaremos nuestro código para poder obtener los datos que necesitamos ********************
Observe
1. Estaremos observando constantemente lo que decidimos monitorear, con el fin de detectar cualquier problema lo antes posible
Detect & Resolve
1. Aquí nos centramos en detectar el problema para darle su solución lo antes posible, antes de que pueda afectar algún usuario o en su defecto a la menor cantidad de ellos.

¿Cómo válido que todo esté funcionando bien? - 3 Preguntas Claves

Nos haremos 3 preguntas que nos ayudaran a guiarnos, y estas se deben hacer constantemente, para comprobar que todo esté funcionando como debería.

¿Nuestro servicio está en línea y disponible?
1. Validamos su disponibilidad
¿Está funcionando correctamente?
1. Validamos este cumpliendo correctamente sus funciones. Por ejemplo
  1. Se puede comprar?
  2. Se puede logear?
  3. Puede hacer alguna orden?
¿Está funcionando bien?
1. Aquí verificamos el rendimiento,
  1. Si carga lento o rápido?

<aside> 📌 ********************************************************El éxito de un equipo o empresa radica en CUANTO LES TOMA HACER que todas las respuestas a esas preguntas sean Si******************************************************** </aside>

¿Qué nos puede diferenciar como compañía o desarrollador de los demás?

Podríamos decir que el éxito de monitorear algo reside en 2 puntos.

Detectar el problema
Resolverlo

Por lo tanto, existen dos métricas para esto.

**********************Promedio de tiempo hasta la detección del problema.
1. Mean Time-to-Detectition(MTTD)
******************************************************************Promedio de tiempo hasta resolver el problema.
1. Mean Time-to-Resolution(MTTR)

Por lo tanto, el éxito radica en que el tiempo de nuestras dos métricas sea el menor posible.

En conclusión

Mientras más rápido detectemos el problema, y obtengamos los datos necesarios según nuestro monitoreo, podremos crear soluciones más rápidas y eficaces. Al entender realmente el motivo del problema, podremos dar soluciones más sólidas.

Elena Hernández

Hace 4 años

Para detectar en menor tiempo posible cualquier falla, es necesario conocer muy bien los servicios y aplicaciones, monitorearlos e identificar los puntos crítios en sus flujos y tener el monitoreo en etapas previas a producción, como pruebas y desarrollo.

Robert Cardona

Hace 4 años

Primero que todo no soy un experto, así que digo esto no más, por puro entusiasmo jajajaj.

Considero que para tener un buen --rated-- (MTTD)%, se debe medir la latencia por la cantidad --request-- que está teniendo el servicio. Y comparar el tiempo -- request-- en relacion al tiempo de latencia que toma al servidor para cargar los diferentes paquetes al cliente.

Y en el caso -- rated-- (MTTR)%, se me ocurren un par: Desde medir las frecuencias de los algoritmos. Validar las altas concurrencias de cada servicio para determinar que lenguaje compila más rápido para trabajar esos servicios, sin descuidar escalabilidad, seguridad, optimización.

Nota final: recordad!!! + cores/ram = it`s a lot of money, BUDDY... Y de eso no se trata... 😝😝😝😝😝😝

Ricardo Celis

Profesor

Hace 4 años

sí es un tema 1000% de balance!!

Edwin Cabezas

Hace 4 años

El MTTD podría ser automatizado, si tenemos buenas herramientas de monitoreo podríamos lanzar alertas integradas con mail, slack etc informando sobre errores rapidamente.

Mauricio Garibello Rodriguez

Hace 4 años

Equipo de Platzi esta clase y otras no estan cargando en dispositivos moviles.

Andres Prieto

Hace 4 años

La frase más importante de esta clase:

El éxito de un equipo de DevOps se mide en cuento tiempo tardan en responder a estas preguntas:

¿Nuestro servicio está en línea y disponible?
¿Está funcionando correctamente?
¿Está funcionando bien?

++Esto es cuantificable++

Juan David Sánchez

Hace 4 años

Creería que se podría reducir el MTTD por medio de un sistema de alertas automatizado. El sistema de alertas podría conectarse con sistemas de incidentes como OpsGenie para alertar a las personas encargadas. Un script automatizado podría encargarse de evaluar ciertos aspectos del sistema constantemente para detectar cualquier anomalía y crear las alertas de ser necesario. Adicional al script, también se podrían publicar métricas de uso constantemente desde los servicios (uso de recursos, tiempos de respuestas, cantidad de respuesta con códigos de error, etc) y conectar grandes cantidades de outliers seguidos al sistema de incidentes. Para reducir el MTTR creo que depende del tipo de error que ocurra:

Suponiendo que se cayó una de las zonas que usamos. Podríamos tener un mecanismo que automáticamente deje de rutear hacia la zona que está fallando hacia otra zona que esté funcionando correctamente.
Suponiendo que se introdujo un bug en el código. Podríamos tener un mecanismo que vuelva a llevar al sistema a un estado anterior que se sabía funcionaba correctamente.
En caso de que sea otro problema, igual es importante tener sistema de logs que nos permita capturar la mayor información posible sobre errores, como por ejemplo Sentry, para reducir el tiempo necesario para diagnosticar el problema.

CLAUDIO RIVAS

Hace 4 años

hola, soy el único o no se pueden ver todos los contenidos del curso?

Ricardo Celis

Profesor

Hace 4 años

escribe a team@platzi.com porfa!

Esthefany Paola García Real Joya

Hace 4 años

Hola! el problema sigue. En la app no pude seguir avanzando y en pc se traban.

Geidy johana lopez

Hace 3 años

Lo que yo aria para bajar los riesgos de detección de un problema es monitorear mas contante mente las paginas y no solo eso navegar en ella para detectar los inconvenientes que posiblemente yo pueda evidenciar que podría tener los fututos usuario como un QA aparte del sistema, y reportarlo directamente al equipo de desarrollo para solucionarlo lo mas pronto posible. ya que lo que se necesita es una exelente experiencia para el usuario final.

Leandro Espino Espino

Hace 4 años

Monitoreo de un sistema

El monitoreo consiste en recolectar datos del sistema y de su rendimiento, visualizar dichos datos mediante un dashboard para poderlos interpretar de manera rápida, así mismo, al estar recolectando estos datos, se puede realizar un seguimiento de su comportamiento.

APM

Significa Application Performance Monitoring y es el tipo de monitoreo mas utilizado actualmente.

Planear: El equipo decide que es lo que se va a monitorear
Instrumentar: El sistema se crea con instrumentación para que el equipo pueda recolectar información
Observar: Observar los datos generados por los módulos del sistema que están instrumentados
Detectar y Resolver: Cuando se detectan problemas, se comienza a tomar medidas de acción para resolverlo

Este proceso es constante, cada que hay cambios dentro del flujo de desarrollo.

Guía del correcto monitoreo

Durante el proceso de monitoreo, es necesario responder estas preguntas:

¿Nuestro servicio esta en línea y disponible?
¿Está funcionando correctamente?
¿Está rindiendo bien?

Si alguna de las respuestas de estas preguntas es NO, se deben consultar los datos recolectados durante el monitoreo para poder resolver el problema.

Métricas de monitoreo

MTTD: Tiempo promedio a detección, ¿Cuánto tardamos en darnos cuenta de que existe un problema?
MTTR: Tiempo en resolver el problema y logró resolverlo, ¿Cuánto tardamos en atender y/o solucionar el problema?

SRE

Significa Site reliability engineering y son las personas que forman parte del equipo de DevOps y están atentos a las métricas de monitoreo.

Robert Vásquez

Hace 4 años

Esto de los Quiz le añade valor a los cursos aquí en platzi, me gustan!

Camilo Hernandez

Hace 4 años

Totalmente de acuerdo, es un valor agregado inmenso. Hace mas dinámico y efectivo el aprendizaje.

William Rodriguez

Hace un año

Conclusion del video.. Si instragram se cae debiera caerse Twitter o X también para que no esté la gente quejándose Hahah ... podran cuestionar mis métodos pero no los resultados.

Andres Prieto

Hace 4 años

¿Este proceso de MTTD y MTTR como se hace in-house? Sé que existen servicios que proveen esto de cara a seguridad; pero no se me ocurre como se puede bajar el MTTD por ejemplo de una página de e-comercer, ¿Se está checando cada X así sean las 4 a.m o cómo?

Joan Gomezjurado Sánchez

Hace 4 años

Hola, el sistema de Cpanel sirve para el monitoreo o haria parte de los manitores? Saludos

Jeferson Gonzalez

Hace 3 años

que diferencia hay entre ¿está funcionando correctamente? y ¿está funcionando bien?

Aaron Yamir Fernando Quintana Lobos

Hace 4 años

¿Nuestro servicio está en linea y disponible?
¿Está funcionando correstamente?
¿Está funcionando bien? ¿Estas dos ultimas son muy parecidas, cual es la diferencia?

Izael Ruelas Garcia

Hace 4 años

Sino me equivoco una pregunta se refiere al aplicativo lo que ve el usuario, y la ultima pregunta se refiere a nivel hardware que siga funcionando bien sin detectar niveles de consumos altos en RAM o Procesador

Juan Fernando Herrera Noboa

Hace 4 años

Hola, el primero hace referencia a que entregue los resultados esperados. El segundo a que esta entrega sea de una forma eficiente que no se demore más de lo normal.

Michael Martinez

Hace 2 años

Michael Martinez

Hace 2 años

Recursos

Monitorear aplicaciones web modernas es la práctica de recolectar datos de rendimiento en tiempo real para detectar fallas antes de que afecten al negocio. Si trabajas en desarrollo, DevOps o infraestructura, entender el monitoreo y sus métricas clave (MTTD y MTTR) te permite mantener la salud de sistemas distribuidos como contenedores y Kubernetes.

La idea es simple: tus sistemas no pueden hablar, así que necesitas instrumentos que te avisen cuándo algo va mal. Y aquí viene lo interesante, porque la analogía con un monitor de bebés explica casi todo.

¿Qué significa monitorear una aplicación web?

Monitorear es el acto de recolectar constantemente datos sobre tus sistemas y su rendimiento para visualizarlos en un dashboard y detectar rápidamente cuando algo falla [02:00].

El tipo más común se llama Application Performance Monitoring (APM), o monitoreo del rendimiento de la aplicación. Piénsalo así: en lugar de escuchar el llanto de un bebé por un altavoz, escuchas a tu aplicación a través de data points numéricos.

Los puntos de datos que típicamente revisas son:

Tráfico del sitio web.
Porcentaje de CPU consumido por el procesador.
Memoria RAM disponible frente a la utilizada.
Capacidad de almacenamiento de los discos duros.
Tiempos de carga de las páginas.

¿Qué es APM? Application Performance Monitoring es la práctica de recolectar métricas numéricas de una aplicación, como uso de CPU, RAM y tiempos de carga, para detectar problemas en tiempo real.

Con esa información en pantalla, sabes inmediatamente cuándo hay una crisis: el equivalente a escuchar al bebé llorar es ver que tu sitio se cayó.

¿Cuáles son los pasos para monitorear una aplicación?

El proceso tradicional sigue cuatro pasos que se repiten constantemente cada vez que lanzas nuevas features, páginas o componentes [04:30].

Planear: el equipo decide de forma anticipada qué debe ser monitoreado.
Instrumentar: los sistemas se construyen para permitir la recolección de datos. La instrumentación va dentro de tu código.
Observar: revisas constantemente los datos de las porciones instrumentadas.
Detectar y resolver: cuando aparece un problema, las personas encargadas reciben alertas y el equipo entra en acción.

No es un proceso de una sola vez. Cada nueva característica que sale a producción reinicia el ciclo, así que el monitoreo vive dentro de todo tu flujo de desarrollo.

¿Qué preguntas debe responder tu monitoreo?

En el núcleo del monitoreo hay tres preguntas que debes poder contestar con un sí o un no en cualquier momento [05:30]:

¿Nuestro servicio está online y disponible?
¿Nuestro servicio está funcionando correctamente? Por ejemplo, ¿un usuario puede comprar o pedir comida?
¿Nuestro servicio está rindiendo bien? Es decir, ¿carga rápido?

Si alguna respuesta es no, los datos que recolectas deben servir para detectar y resolver el problema. En la cultura DevOps, el éxito del equipo se mide por cuánto tarda en volver a responder sí a las tres.

¿Qué es el MTTD y el MTTR?

Estas dos métricas son el pan de cada día de un site reliability engineer, perfil que en muchas organizaciones forma parte del equipo de DevOps o infraestructura [07:30].

¿Qué es MTTD? El mean time to detection es el tiempo promedio entre que un problema comienza y el equipo se entera. Debe ser lo más bajo posible y no incluye el tiempo de reparación.

¿Qué es MTTR? El mean time to resolution es el tiempo promedio entre que el equipo detecta el problema y logra dejar todos los sistemas operando con normalidad.

Reducir ambos números es la obsesión de cualquier equipo serio de operaciones, porque cada minuto cuenta.

¿Por qué importa tanto reducir el tiempo de detección?

Los clientes hoy tienen expectativas altísimas sobre las experiencias digitales. Cuando se cae Instagram, Twitter se llena de quejas y la plataforma pierde mucho dinero en publicidad que no se muestra [08:30].

Si una de las tres preguntas se responde con un no, pasan tres cosas a la vez: los usuarios se molestan, tu empresa pierde dinero y la confianza en tu marca se erosiona. Es un escenario donde todos pierden, y por eso MTTD y MTTR son métricas críticas en el mundo digital.

Ahora te toca a ti: ¿qué puede hacer una compañía para bajar su MTTD? ¿Y qué puede hacer para bajar su MTTR? Déjame tu propuesta en los comentarios y responde a la de tus compañeras y compañeros.

Resumen

¿Qué significa monitorear una aplicación web?

Monitorear es el acto de recolectar constantemente datos sobre tus sistemas y su rendimiento para visualizarlos en un dashboard y detectar rápidamente cuando algo falla [02:00].

Los puntos de datos que típicamente revisas son:

Tráfico del sitio web.
Porcentaje de CPU consumido por el procesador.
Memoria RAM disponible frente a la utilizada.
Capacidad de almacenamiento de los discos duros.
Tiempos de carga de las páginas.

¿Qué es APM? Application Performance Monitoring es la práctica de recolectar métricas numéricas de una aplicación, como uso de CPU, RAM y tiempos de carga, para detectar problemas en tiempo real.

Con esa información en pantalla, sabes inmediatamente cuándo hay una crisis: el equivalente a escuchar al bebé llorar es ver que tu sitio se cayó.

¿Cuáles son los pasos para monitorear una aplicación?

El proceso tradicional sigue cuatro pasos que se repiten constantemente cada vez que lanzas nuevas features, páginas o componentes [04:30].

Planear: el equipo decide de forma anticipada qué debe ser monitoreado.
Instrumentar: los sistemas se construyen para permitir la recolección de datos. La instrumentación va dentro de tu código.
Observar: revisas constantemente los datos de las porciones instrumentadas.
Detectar y resolver: cuando aparece un problema, las personas encargadas reciben alertas y el equipo entra en acción.

No es un proceso de una sola vez. Cada nueva característica que sale a producción reinicia el ciclo, así que el monitoreo vive dentro de todo tu flujo de desarrollo.

¿Qué preguntas debe responder tu monitoreo?

En el núcleo del monitoreo hay tres preguntas que debes poder contestar con un sí o un no en cualquier momento [05:30]:

¿Nuestro servicio está online y disponible?
¿Nuestro servicio está funcionando correctamente? Por ejemplo, ¿un usuario puede comprar o pedir comida?
¿Nuestro servicio está rindiendo bien? Es decir, ¿carga rápido?

¿Qué es el MTTD y el MTTR?

Estas dos métricas son el pan de cada día de un site reliability engineer, perfil que en muchas organizaciones forma parte del equipo de DevOps o infraestructura [07:30].

¿Qué es MTTD? El mean time to detection es el tiempo promedio entre que un problema comienza y el equipo se entera. Debe ser lo más bajo posible y no incluye el tiempo de reparación.

¿Qué es MTTR? El mean time to resolution es el tiempo promedio entre que el equipo detecta el problema y logra dejar todos los sistemas operando con normalidad.

Reducir ambos números es la obsesión de cualquier equipo serio de operaciones, porque cada minuto cuenta.

¿Por qué importa tanto reducir el tiempo de detección?

Bienvenida al curso

Observabilidad en sistemas digitales complejos

¿Cómo funciona la web moderna?

De monolitos a microservicios en web

Contenedores, Docker y Kubernetes explicados

Aplicaciones Nativas en la Nube: Conceptos y Beneficios

Observabilidad y monitoreo

Límites reales del monitoreo en DevOps

Monitoreo de apps con MTTD y MTTR

Observabilidad vs Monitoreo en Sistemas Digitales

Los 3 pilares de la observabilidad

Telemetría y tipos de datos

Qué son eventos y metadata en telemetría

Métricas vs eventos en observabilidad MELT

Logs vs eventos en telemetría

Qué son los traces en telemetría distribuida

Reto: Monoliths y Microservices

Uso de New Relic: Análisis de Mapas de Aplicaciones Web

Cierre y despedida

Cómo certificarte en New Relic desde Platzi

Retroalimentación sobre Cursos de Platzi

Monitoreo de apps con MTTD y MTTR

Progreso del curso

Bienvenida al curso

¿Cómo funciona la web moderna?

Observabilidad y monitoreo

Telemetría y tipos de datos

Reto: Monoliths y Microservices

Cierre y despedida

Recursos

Recursos