Como medir el desempeño de un DBA

Antes de que continúes leyendo, quiero informarte que no encontraras la respuesta aquí, si no que esto es una reflexión de lo complicado que es medir el desempeño estándar de un DBA,

Y es aquí donde entra lo complejo, por que vamos a ver si lo medimos por la cantidad de requerimientos que recibe y termina, me ha tocado ver situaciones en donde en un equipo de 10 DBAs, el que mas numero de requerimientos terminaba era un DBA Jr que sus tareas mas complejas era hacer un export/import.

Si lo medimos los requerimientos por la manera de "Cero defectos en la primera entrega", nos enfrentamos a que tenemos normalmente un ambiente y flujo de trabajo que pasa por desarrollo luego pruebas y finalmente por producción.

En que parte del proceso de los requerimientos mides los cero defectos , en producción o los empiezas a medir desde que recibes tu requerimiento en desarrollo, cuando lo que van a salir son todos los errores que pasas a pruebas para tratar de eliminarlos?

Y que pasa cuando nada falla en desarrollo y pruebas, pero llegas a producción y eres el gran afortunado de descubrir un nuevo bug en la versión que estas trabajando?

Me dirás, la manera que lo puedo medir es en el numero de queries exitosos que hacemos a la base de datos y estos responden en el tiempo adecuado? Para empezar de que manera se define exitoso, que no falla o que sencillamente regresa los datos que debería? Y en tiempo, como puedes definir el tiempo adecuado si un query depende no tanto de ti, si no de los desarrolladores y de la cantidad de datos que regresa, de la misma forma, si un query me regresa datos en 30 minutos o 1 segundos, todo depende del proceso que estés corriendo, los dos pueden estar bien o pueden estar mal.

Existen varias cosas que si creo que puedes medir, pero no de una forma de rendimiento estándar, si no de la salud del ambiente y tus bases de datos

• • El tiempo que la base de datos esta disponible en acuerdo con los SLAs establecidos.
• • El numero de alarmas del mismo tipo que recibiste el mes pasado contra las de este mes, y que se hizo para reducirlo.
• • La cantidad de Base de Datos que tienen los estándares establecidos en los SLAs por la empresa y por tu equipo.
• • El numero de pruebas de desastre que son exitosas en el año.
• • La cantidad de respaldos exitosos/no exitosos que tuviste en el mes.

Como puedes ver es complejo por que desde mi punto de vista un DBA se debe de medir de forma cualitativa no cuantitativa. Y para medirlo de forma cualitativa la formula es por cada DBA y por cada ambiente que tienes.

Al ultimo la realidad del desempeño de un DBA, es que se acaba midiendo por que tan bien ejerce sus funciones en la adversidad de una situación; Es ese 10% de las situaciones catastróficas que no fueron causadas por el mismo y que tiene un DBA en su profesión que acaba determinando si es un buen DBA o no.