Introducción al soporte de aplicaciones al estilo Itil.
Todo sistema en Itil es un servicio por que... la finalidad de todo sistema es brindar un servicio al usuario (como cualquier otro servicio transporte, electricidad, agua, etc.) con niveles de calidad aceptables.
Como analogía si yo uso el sistema de transporte se que alguien va a operar el autobús, se que debo de pagar de cierta forma, lo puedo tomar en un horario, etc.
Un incidente entonces es una interrupcion total, parcial, o una degradación en el servicio.
Tipos de servicio
a. Servicios aplicativos para usuarios finales. (Desarrollos)
b. Servicios de tecnología que dan servicio a otros aplicativos. (La base de datos, la red, otro sistema, etc.)
El soporte aplicativo entra justo después de que termina la implementación en producción lo que es lo mismo después del desarrollo.
Una breve guía práctica sobre la Gestión de Incidentes.
Me llega un incidente. ¿Qué hago?
1. Revisar que tenga todos los elementos para poder analizar el caso. Por ejemplo logs, pantalla que generó donde se muestra el error, datos de contacto de quien levantó el incidente, fecha y hora.
2. Tratar de responder lo más rápido a las preguntas. ¿Qué tan grave es?, ¿Es general?, ¿A cuántos usuarios afecta?, ¿Qué cantidad de dinero se pierde o se deja de ganar?, etc.
3. Tomar acciones Inmediatas en cuestión de horas generalemente. Ej: reproceso, reinicio, verifica la conexión a la base de datos, etc.
Fin del incidente
Si no es posible tomar acciones inmediatas porque requiere análisis o se está buscando la causa raíz de lo que genera.
1. ¿Cuál es el escenario en que ocurre?, ¿Cuál es el error?
2. ¿Cuál es la causa?, ¿Dónde se produjo?
3. ¿Cuál es la solución?, ¿Cuál es la fecha estimada?
4. ¿Qué se afecta si modifico código, configuraciones, etc.?, ¿Que tanto debo probar?
5. Hacer corrección(es) al código, parámetros o lo necesario.
6. Probar la corrección.
7. Implantación normalmente con la gestión de cambios
8. Liberar la corrección y probar con el usuario nuevamente.
Plan B. Si fallaron los cambios regresar a la versión anterior los movimientos.
Qué no es un incidente.
Algunos casos:
1. Funcionalidad esperada o nueva:
Ejemplo:
El usuario dice - El sistema hace “A” pero debería hacer “B”.
Cuando revisas la especificación dice que debe hacer “A”, es decir así se pidió, aunque después cambie la necesidad.
El sistema no hace…
¿Antes lo hacía y lo dejó de hacer?
2. Cuando se produce un comportamiento no esperado debido a un incidente en otro sistema
Ejemplo:
Hay una pantalla donde no hay datos.
Al revisar resulta que un Web Service en otra aplicación no está respondiendo.
Se pasa el incidente a otra área.
3. Un error conocido:
Ejemplo:
El sistema falla cuando sobrepasa el número de usuarios esperado, la solución de raiz es ampliar la memoria pero no hay presupuesto, por el momento solo puedo reiniciar a partir de X hora.
Es solo un breve resumen, hay mucho más.
Espero que les haya gustado y les sea de utilidad.
- paranoid_android's blog
- Inicie sesión o regístrese para enviar comentarios
Comentarios
Trabajando por evidencias
Vamos completando esta guía si gustan aportar algo con todo gusto es bienvenido.
- Es muy fácil decir que el sistema falla / que está mal hecho u otra serie de quejas.
Cuando soportamos una aplicación debemos atender este tipo de quejas para aumentar la percepción de satisfacción / calidad con el usuario, con otros sistemas o como diría la justicia para “deslindar” jajaja.
Por eso se deben dar razones sustentando los errores (como dice la comunidad javamexico), esas razones se sustentan con evidencias.
También en casos donde no tengamos la respuesta de manera inmediata las evidencias muestran que estamos trabajando y al menos estamos en el buscando una solución. No es lo mismo decir aquí no está el problema con las manos vacías que llegar con una evidencia.
Como fuentes de evidencias existen muchas pantallas, logs, pruebas a medida, etc.
En este tipo de trabajo a la manera de Itil es muy común intercambiar correos con varios implicados mostrando las evidencias e incluso preguntando a otros colegas por alguna situación o solicitando ayuda para obtener evidencia de otro sistema. Esto genera un tipo de presión pero debe tratarse de manera muy profesional, cordial e incluso con sentido del humor. (No importa dónde está el error o si alguien tiene la culpa Todos estamos jodidos por igual)
Después de ocurrido un incidente en ocasiones se pide un análisis post mortem por lo cual es importante armar un archivo del caso, implicados y recopilar todo lo que esté al alcance en ese momento ya que después es muy difícil. No será lo mismo tratar de recopilar una semana o un mes después.
Las fechas y el calendario de cambios son pistas para futuros casos.
-"El problema comenzó a pasar desde esta fecha, podría coincidir con el cambios que se paso para un mantenimiento"
El registro de todo esto organizando los casos, las evidencias, los errores nos ayuda posteriormente a generar reportes con los que se evalúa la calidad del servicio (sistema).
Organización básica
En esta ocasión le contaré un poco de la organización básica necesaria para conseguir resultados con ITIL.
Quisiera aclarar que en algunos lugares se trata de implementar Itil solo certificando personas lo que considero un error. Esta muy bien tener personal certificado pero es un error no contar con la organización adecuada para hacerlo.
Se necesitan dos responsables por aplicativo uno del lado del Usuario y otro de lado de Sistemas. Esto es muy importante ya que cuando existe una confusión o un problema estos responsables deben tomar las decisiones conjuntas y negociadas.
Por ejemplo:
El rendimiento del sistema está a la mitad, se investiga y resulta que la corrección tardaría 2 horas parando la producción. Quien puede decidir si se puede parar la producción o se debe de esperar hasta el día siguiente es el usuario. El responsable de sistemas debe de especificarle el tiempo y las implicaciones. Ambos negocian y deciden.
Caso contrario:
El usuario desea realizar un cambio en el sistema repentino y urgente. El responsable del aplicativo de sistemas debe sensibilizar al usuario para ayudar a mantener la calma. Y antes de actuar valorar los riesgos, el impacto y mantener un plan de retorno de lo contrario se puede producir un error todavía más grave.
Cuando el problema es aun mayor normalmente las desiciónes escalan más llegando a directivos.
Es muy común que para los usuarios todos urge y con el desarrollo quieran resolver absolutamente todos los detalles. Esto genera desarrollos muy grandes con jornadas de trabajo muy largas.
Es por esta razón , también se necesitan tener usuarios sensibilizados y que conozcan de ITIL desde el punto de vista de un consumidor.
De esta forma los planes de sistemas y el presupuesto destinado es mas eficiente y se tiene una integración continua.
Este otro punto es uno de los problemas más comunes que se ve cuando la organización es insuficiente, cuando se planea un desarrollo se olvida incluir el hardware para atender el volumen estimado. Cabe señalar que hoy en día existen variantes en ITIL como tener parte de los servicios en la nube.
Gracias, hasta la próxima.