Medición de indicadores y seguimiento a proyectos

En internet no encontre nada, pero si me paso en un empleo pasado, en una central de monitoreo
Resulta que (segun me comentaron) una persona que se encargaba de la parte de DBA borro accidentalmente todos los datos de los clientes, seguro hizo un “delete” sin “where”, esto sin bien no tiene que ver con algo automatizado y a lo que se le haga seguimiento, tambien es algo a considerar para el rol de Data Engineer

Algunos ejemplos que puedieron ser evitados con el adecuado monitoreo:

1. Tabla 4: Lista de incidentes causados por problemas relacionados a la data
   

   

2. Tabla 5: Lista de incidentes causados por problemas relacionados al modelo
   

   

3. Tabla 6: Lista de incidentes causados por problemas no técnicos (ética, interpretabilidad, viabilidad económica)
   

   

Obtenido de: Monitoring machine learning models: a categorization of challenges and methods

Como catastrofe que pueda pasar se me ocurre que se limpien datos de mas (perdida de informacion valiosa), uso exesivos e inecesarios de recursos en la nuve, o acceso de usuarios no autorizados

Perder data valiosa, es un error garrafal. Es como olvidar la historia y destruir la materia prima para la continuidad de un negocio. Todavia en la actualidad ocurren esas cosas.
Muchas veces son errores de novato y en ese momento aprendemos jeje

Consejo general, capturen toda la data y después comienzan a decidir cuál les será útil, al menos cuando vayan iniciando una aplicación, integración, etc.

Como una experiencia propia, en la empresa tenemos la plataforma de Splunk, esta plataforma, según como se configure, cobra por la capacidad de data que se ingresa. Teóricamente se tiene un limite de capacidad, pero si se da la necesidad, puedes sobrepasarlo y la plataforma te cobra extra el excedente. Nadie solía monitorear cuanto se estaba consumiendo de esa capacidad. En una ocasión hicieron que una nueva plataforma de seguridad cargara los logs sobre Splunk y la persona que hizo la configuración no verificó que información estaba enviando. Resultó que la plataforma estaba enviando TODOS los logs cuando no eran necesarios. Se triplicó el límite de consumo. Afortunadamente, Splunk nos envío una notificación ofreciéndonos una capacidad limite superior debido al alto consumo, por lo que pudimos solucionarlo antes de que los costos subieran como los cohetes de SpaceX. Obviamente hubo un sobrecosto ese mes, pero no fue tan alto como hubiese podido ser.

No medir es DOLOROSO.

Mi resumen de la clase:

Al dejar cosas corriendo debemos de tener muy en cuenta el monitoreo, debemos saber cómo están funcionando las cosas que querremos y de qué manera estamos trabajando con ello.
Cuando no medimos nos volvemos loco con saber que fallo, medir es tan importante como generar un modelo de aprendizaje automático.
Debemos de saber cuáles son los puntos de riesgo de nuestros datos.
Debemos de tener visibilidad a través de dos niveles:
Dashboards y alertas y notificaciones de cuando las cosas fallan.

Buena explicacion.