Alarmas de rendimiento en vSAN

Es cierto que a veces las alarmas de rendimiento son genéricas.

Al buscar en Google también hay información genérica o demasiada.

Si estamos bajo este escenario, ¿Cuál es el siguiente paso?

A veces queremos soluciones rápidas, más si es un incidente y que Google nos de la solución.

La realidad es que no siempre funciona, además una determinada solución no necesariamente aplica para todos los escenarios ni configuraciones, hay que tener cuidado y no ser mecánico.

Lo que planteo a continuación lo escribo pensando en cuando nos llega un incidente de rendimiento bajo #vSphere o #vSAN de #VMware, pero pudiese aplicar en la administración de cualquier infraestructura.

El paso obligatorio por el cual hay que transitar es el de levantar la información, lo cual incluye identificar, determinar los hechos y si es posible cuantificar.

No hay que dejarse presionar, ni por los demás ni por uno mismo con la voz que dice «hay que resolverlo rápido». Ya que podríamos pasar algo por alto debido a la presión.

Una de los aspectos a determinar es, de dónde viene el reporte:

¿Del funcional o del administrador de la aplicación?, ¿Del programador o del DBA?, también puede ser del jefe de departamento de la aplicación pensando que si abre el reporte o llama todo se resolverá más rápido por su cargo.

Esta información nos ayudará a determinar si necesitamos obtener la descripción del incidente de rendimiento por otros medios para comprender mejor.

He aprendido que dependiendo del rol que se tenga, se puede tener una percepción totalmente diferente, así que debemos saber quién redactó o transmitió el mensaje.

Si es un ticket donde se describe el incidente de rendimiento, yo soy del pensar que hay que llamar para escuchar, hacer preguntas, indagar y que la descripción quede clara o validar lo escrito.

Si es que nuestro jefe o compañero nos está explicando el incidente, también soy de la idea de llamar con el afectado o el origen del incidente para que me explique.

No tiene idea de cuántos malos entendidos se pueden resolver y la diferencia en tiempo de solución se puede ahorrar uno cuando se identifica correctamente el incidente.

Por la prisa me llegué a saltar este paso y sufrí las consecuencias, no quiero que otros la pasen.

¿Te parece que es importante saber la fuente de dónde se reporta el incidente y su versión de los hechos?

Comparte este artículo a la vCommunity VMware para que la información pueda ayudar a otros colegas:

LinkedIn

Otros artículos relacionados

Home-Lab y el profesional de TI

Agarrar el timón para direccionar nuestra carrera. Así yo definiría tener un laboratorio, nos convertimos en científicos que prueban, ensayan y logran mejores resultados. Aprender

Leer más »