Fallas y problemas.

Aparentemente.

Todo procedimiento se encuentra ante la constante amenaza de un fallo. Es un hecho: cualquier tarea, proceso, procedimiento, sistema o esquimal, desde el momento de su concepción, está destinado a fallar. La calidad del control que sea aplicado a un entorno es lo unico que evita que todo se vaya al carajo desde el momento mismo en que algo, cualquier cosa, es creada. Por si fuera poco, eventualmente, tendremos que reparar los fallos.

A pesar de que todos los fallos normalmente son manejables y reparables (con su debido tiempo), es imperativo llegar al fondo de las cosas, al por qué de la situación, al saber quién ejecutó el “borratodo.sh” o “eliminasystemroot.exe o por qué cuando pones un patron irregular de 14 caracteres en un campo de 15 caracteres tu página web te redirige a google con una busqueda de RTFM. De la misma frustrante manera, cualquier fallo debe ser reportado inmediatamente y debe ser sujeto a un diagnóstico. Éste debe presentarse de manera clara y detallada con el objetivo de poder establecer un procedimiento estándar de resolución de, al menos, ese problema en particular.

A continuación les presento un procedimiento que se puede utilizar para realizar un diagnóstico adecuado de un problema de un sistema informático. Estos pasos pueden ser tomados como referencia para cerrar el campo de influencia del origen de lo que se encuentra provocando el problema. Para realizar el procedimiento hemos reunido a una considerable cantidad de eminencias de la informática actual que no dudarían en descuartizar un servidor para llegar al fondo de las cosas. Fueron ellos quienes nos han inspirado a realizar un procedimiento no invasivo de un inconveniente informático presentado en un entorno heterogeneo.

Este documento será integrado a la metodología PEA tan pronto sea liberado. El documento se encuentra en constante modificación, por lo que será conveniente mantenerse al tanto de las ediciones futuras (sí: lean todos los artículos y regresen todos los dias a dar F5).

Úsenlo a discreción.

—————– sketch ———————

Manual de procedimientos no invasivos
para diagnostico de inconvenientes informáticos
de un ambiente operativo heterogeneo.

Fecha.

Cliente: Nombre y/o descripción del cliente.

Introducción general.

Descripción breve del problema, preferentemente una vez encontrando la solución. Normalmente una o dos oraciones descriptivas de lo que sucede y de qué manera sucede (qué pasa, qué lo ocasiona y cómo evoluciona).

Solución.

Se describe de manera general la forma de solucionar el inconveniente, preferentemente, a manera de redacción. En caso de que sea secuencial, asegurarse que ningún paso dependa de otro que no sea contemplado y que cada paso sea claro y aplicable por cualquier persona. En lo posible, incluir en este mismo paso la evidencia de cómo solventar el inconveniente.

Causado por.

Normalmente llamado “causa raíz”, debe incluir el entorno en el que se genera el inconveniente presentado. El por qué y cómo sucede el incidente o se genera el problema. En caso de sospechar que no se trate de la causa raíz, indicarlo de manera explícita y clara.

Descripción del caso.

Descripción detallada y extendida del caso. Mientras más detalles se obtengan, muchísimo mejor. La descripción debe presentarse a manera de redacción, preferentemente con las palabras del usuario. Se pretende hacer un borrador de las ideas proporcionadas por el cliente, para posteriormente aclararlas a manera de redacción técnica, con los equivalentes proporcionados por el mismo cliente. Se deben incluir, pero no limitarse a: Direcciones IP, nombres de usuario, medio de acceso (internet, VPN, DMZ, etc.), tipo de suscripción, descripción de suscripción, si ha comprado más recursos, si ha sido funcional alguna vez y todo lo que tenga que ver con el procedimiento del cliente o de quien ha encontrado el problema.

Síntomas.

Se debe describir de manera secuencial los síntomas que el cliente ha presenciado, además de ir agregando adicionales conforme se vayan encontrando durante la revisión. Los síntomas deben ser estrictamente tautologías.

Correcto:

1.- El servidor se encuentra sin responder pings.
2.- La suscripción se quedó a la mitad del aprovisionamiento después de ejecutar la tarea.
3.- El equipo se encuentra desconectado de la red.
4.- Es imposible agregar un registro DNS debido a que se recibe un error.
5.- Es imposible completar el procedimiento de manera adecuada.

Incorrecto:

1.- No se puede conectar al servidor.
2.- Las tareas no se completan.
3.- El equipo no está conectado a la red.
4.- No se puede agregar un registro DNS. Marca error.
5.- El procedimiento no se puede completar bien.

Antecedentes del cliente.

Los antecedentes deben incluir, de manera indizada, los eventos descritos por el cliente. De la misma manera, deben ser secuenciales y se deben ir agregando registros conforme vayan siendo encontrados, preferentemente de manera cronológica desde la creación de la suscripción o de haber encontrado el inconveniente. Es indiferente si los antecedentes son descritos mediante tautologías o mediante oraciones estructuradas, siempre y cuando definan un estado en la existencia de la suscripción del cliente.

Datos recabados.

Todo lo relacionado con el procedimiento de verificación. Es imperativo complementar cualquier dato encontrado, indistintamente de si se trata de algo esperado o de un error propiamente hablando. La documentación debe ser de manera secuencial basada en los componentes de un servicio cualquiera y debe generarse en el siguiente orden: Hardware, Software, Redes, Aplicación y Usuario. Los datos a recabar deben incluir el inicio y el fin de la existencia de la suscripción reportada así como los datos de los lapsos en que se hayan mencionado inconvenientes.

Hardware:

Rendimiento CPU.
Rendimiento RAM.
Rendimiento Disco.
Rendimiento Red.
Modificaciones a la configuración del equipo.
Límites de dispositivos físicos.

Redes:

Carga de los dispositivos de interconectividad.
Rutas estáticas.
Consumo de ancho de banda y si existen límites.
Disponibilidad de la red (ping).
Alcance de la red (traceroute).
Modificación a componentes del equipo (adición / remoción de interfaces de red).
Modificación a componentes del sistema operativo (Adición / remoción de rutas estáticas, entradas ARP).
Modificación a componentes de la aplicación (Rutas, direcciones IP, usuarios y contraseñas inmersos en el código).
Límites de recursos de los componentes físicos y lógicos.

Software de bajo nivel (Sistema operativo):

Registro de Eventos / mensajes del sistema.
Tiempo de ejecución continua.
Cantidad de IOPS (en caso de ser disponible).
Necesidad / demanda de Interfaces de Red.
Modificaciones a la configuración del sistema operativo.
Límites de dispositivos lógicos / recursos asignados.

Software de medio / alto nivel (Aplicación):

Requisitos de la aplicación.
Límites de la aplicación.
Datos inmersos en el código.
Validación de errores por parte de la aplicación.
Registro de eventos.
Validación de rendimiento.
Validación de procedimiento de aseguramiento de calidad del desarrollador.
Validación de compatibilidad de la arquitectura de la aplicación con la arquitectura de su entorno.

Usuario final:

Forma de utilizar la aplicación.
Documentación previa.
Experiencia previa.
Tiempo de uso de la aplicación.
De qué manera aprendió a utilizar la aplicación.
Si el usuario es sysadmin.
Si el usuario cuenta con conocimientos avanzados de su aplicación.
Si se han presentado errores adicionales durante el uso de la aplicación.
Si los inconvenientes han sido solventados de fondo.
Si cuenta con procedimientos extraoficiales para mantener el funcionamiento de su aplicación.

Todos los datos deben ser recabados aun cuando la relación que muestren con el inconveniente presentado pueda ser difusa o ligera. Solo se deberán eliminar una vez que se haya descartado completamente de manera práctica que carecen de relación con el problema reportado. Normalmente esto se puede definir como “lluvia de ideas”.

Es posible iniciar de manera inversa, es decir, se puede comenzar diagnosticando el inconveniente a nivel usuario y bajar hasta llegar a los componentes del equipo.

Veredicto (y recomendaciones).

Descripción extendida de las causas del inconveniente generado. Recomendaciones para evitar que este inconveniente se presente nuevamente, en caso de que las mismas existan.

Referencias.

Todo aquel documento que sustente las recomendaciones del veredicto y las recomendaciones realizadas sobre el problema. Normalmente incluidas en forma de URL, pueden ser fuentes diversas oficiales o extraoficiales, siempre que solventen el inconveniente. Las fuentes pueden ser: blogs, bases de conocimiento, artículos sin sabor, manuales técnicos, pruebas de rendimiento, etc.

—————– sketch ———————

Referente a la Metodología PEA.