Mostrando entradas con la etiqueta incidencias. Mostrar todas las entradas
Mostrando entradas con la etiqueta incidencias. Mostrar todas las entradas

14 de enero de 2011

Sin papelera de reciclaje en el buzón de correo de Notes


En el post que comentaba la historia del regreso de los buzones de correo electrónico, de ciertos empleados de la empresa donde trabajo, al "Bing Bang", comenté que escribiría alguna entrada sobre aspectos del funcionamiento de Lotus Notes que desconocía y que me sorprendieron.
Una de esos posts fue Autenticación de Lotus Notes Server y otra de las que tenía pendiente es esta.

Después de recrear los buzones de correo de los empleados que lo perdieron, me avisaron de que cuando eliminaban correos, se eliminaban de manera permanente, es decir que no iban a la típica "papelera de reciclaje".
Observando el comportamiento que me habían indicado, observé que en la barra de herramientas del buzón de correo no aparecía el típico icono de una papelera y en vez de él aparecía una X.

Barra de herramientas del buzón de correo con el icono en X para la acción de eliminación

A raíz, de esto, lo primero que se me ocurrió mirar es en las preferencias de la aplicación haber si se tenía que activar algo para que la funcionalidad de reciclaje estuviese activa, aunque eso tenía que ser extraño ya que no se había hecho ninguna intervención en las aplicaciones clientes (por ejemplo una resinstalación), por lo que no tenía mucho sentido que la configuración se hubiese alterado; no obstante, lo hice (cosas más raras he visto), sin llegar a obtener mucho éxito.
Lo de revisar la configuración de la aplicación cliente, es lo más habitual, cualquier aplicación con las que tratamos, cambiamos su comportamiento a través de algún menú de preferencias ( análogamente opciones), pero como el cliente de Notes no solo es una aplicación de cliente de correo, sino es más bien una aplicación cliente de acceso aplicaciones de Lotus, es normal que las preferencias que dependen exclusivamente de una aplicación en concreto no aparezcan dentro de la configuración de las preferencias de la aplicación cliente, sino en las preferencias de la configuración de la aplicación de Lotus. Dicho esto me puse a revisar las preferencias de laaplicación de Lotus, en este caso un buzón de correo, sin tampoco obtener mucho éxito.

Menú de acceso a las preferencias de aplicación de Lotus de correo

Lo siguiente que se me ocurría era que al crear los nuevos buzones, la hubiera cagado no seleccionando la plantilla correcta. Para los que no estén en la onda de Lotus Notes, yo solo lo estoy un poco, a mí entender las aplicaciones Lotus Notes se componen de un formato único de fichero (extensión nsf) que almacena en su interior todo lo relacionado a a la aplicación (vistas, formularios, procedimientos, etc.), parte que se llama, o yo le llamo plantilla, y los datos de la aplicación; es decir que en este caso, estoy hablando de una aplicación que tiene una plantilla de buzón de correo y como datos va a tener correos electrónicos, entradas de agenda, etc.
Revisé que la plantilla que se estaba aplicando fuera la correcta, y que fuera la última versión, ya que la plantilla que se utiliza en la empresa es una modificación de la plantilla estándar de Lotus Notes, para permitir exportar los e-mails al servidor de ficheros; todo era correcto. Luego pasé a preguntarle a mi compañero, que se encarga de programar las modificaciones de las plantillas, si dicho comportamiento podía tener que ver con las modificaciones que el hace en la plantilla, pero su respuesta fue que no, a no ser que hubiese modificado algo sin darse cuenta, algo que descartaba porque la plantilla que yo había aplicado era la misma que estaba aplicada a los buzones de correo que no se perdieron, y el borrado de datos en estos últimos se comportaba de manera habitual, es decir enviándolos a la papelera.
Ya empezaba a estar un poco hasta los hue... del tema; intenté utilizar el Sr. Google, haber si él podía resolvernos el problema, pero era complicado como formularle las preguntas correctas, porque no encontré nada de interés.
Dándole vueltas a la cabeza y repasando que no me hubiese dejado nada importante en la creación de los nuevos buzones, se me ocurrió que no había mirado en las propiedades de una aplicación de Lotus, así que me puse a ello; entonces descubrí que había una propiedad que se llamaba "Soft Deletions" y que estaba deshabilitada, así que por el nombre (“borrados suaves”) se puede intuir que tienes que ver con la salvaguarda de los borrados de datos, así que la activé.

 Acceso a las propiedades de una aplicación de Lotus
 Dialogo de Propiedades de una aplicación de Lotus (Pestaña avanzado)
Una vez activada y después de cerrar y abrir la aplicación, el icono de la X se había cambiado por una papelera y cuando borrabas correos estos se iban a la "papelera de reciclaje".

Barra de herramientas del buzón de correo con el icono de la papelera para la acción de eliminación

Además dentro de las preferencias de la aplicación de correo habían aparecido nuevas opciones de configuración sobre el eliminado, una de estas la misma que la que se podía indicar en las propiedades, la de el tiempo límite de permanencia de los datos eliminados.

Dialogo de preferencias de aplicación de Lotus de correo con la opción “Soft Deletions” deshabilitada
Dialogo de preferencias de aplicación de Lotus de correo con la opción “Soft Deletions” habilitada

En resumen, la opción de “Soft Deletions” es una propiedad de cualquier aplicación de Lotus, por lo que se debería poder hacer uso de esta característica en cualquiera de ellas.


Hasta la próxima enfermos.

21 de noviembre de 2010

Mi mailbox ha regresado al “Big Bang”


Descripción del entorno
Lotus Notes es una aplicación que se clasifica dentro de la categoría de colaboración de grupos o equipos de trabajo.
En la empresa, en la cual empleo la mayor parte de mi tiempo, utiliza esta herramienta desde hace mogollón de años, aunque parece que a nadie le acabe de satisfacer, la herramienta sigue ahí y bien viva ya que se van pidiendo la implementación de nuevas funcionalidades sobre ella.

Nosotros, los del departamento de TI, tenemos que sufrir las constantes críticas de la mayor parte de los usuarios, incluyendo usuarios con potestad para impulsar un cambio (la dirección), pero este nunca llega, ya que aunque nosotros no somos unos fans de Notes, somos realistas y exponemos las realidades que hay cuando se nos dice “¿por que no ponemos Outlook?” (He dicho Outlook, porque para el usuario es Outlook y nada más, es decir Exchange no existe).
En resumen, el cambio nunca llega porque cuando empiezan a sonar los números, los que pagan ya se echan para tras, y eso que solo llegan a escuchar el dinero de adquisición de la licencia de Exchange, sin haber escuchado lo que cuesta otra herramienta que supla las funcionalidades que ofrece Notes y no Exchange, desarrollo de aplicaciones y BBDD de “negocio” y su migración.

En fin dentro de este berenjenal a nosotros nos toca lidiar con la administración de Notes y las constante insatisfacción y todo eso con una política, de puertas hacia dentro, de inversión mínima en TI.

Como de costumbre, el gran perjudicado en una insuficiente inversión en el importante ámbito actual de las TI, no se lo lleva el personal del departamento de TI que tenemos que plantarnos fuera de horarios para apagar fuegos, aprender de manera autodidacta y normalmente a base de “ostias”, etc., sino que se lo lleva los usuarios y sobre todo la continuidad de negocio de la empresa.

Regresando al “Big Bang”
Hace poco más de una semana, el servidor de Notes de Barcelona dejó de funcionar, al estropearse dos discos de un RAID 5, así que los datos se quedaron en el limbo, ya que no hay tiempo para mandar esos discos a un empresa de recuperación de datos, ya que el servidor se tiene que restablecer lo antes posible; el tema económico, ni lo menciono ya que no lo llegamos ni a consular, pero con la política de inversión mencionada anteriormente, se puede prever con cierta exactitud la respuesta.

La incidencia hasta aquí la normal, no hay disco hot spare, así que a reinstalar servidor y su servicio, después de cambiar los dos discos.

Lo que sucedió, es que ciertos usuarios no tenían una copia de su BBDD de correo, así que volvieron a “Big Bang”, buzón vacío y si tenías algo importante te las apañas para recuperar lo o continuas tu actividad sin esa información como puedas. He dicho ciertos usuarios, por otros si tenían una copia, ya que usan correo web y para eso necesitamos tener replicada su BBDD en otro servidor Notes, y casualidad o no, suele coincidir con el correo de los usuarios de mayor importancia (hablando en términos organizativos).

Restableciendo el servidor
Yo, que de administrar el Notes, sé lo del día a día, ya que el tiempo de la extendida jornada laboral, con el personal que somo en TI, no deja para estar jugando con los sistemas, e invertir en formación del personal de TI (y otros tantos departamentos, más bien casi todos a excepción uno y medio) no cabe en los presupuestos de la empresa; tuve que reinstalar un servidor de Notes entero y meterlo en el Domino existente, sin más ayuda hasta la fase de poner la guinda al pastel, ya que mi compañero no estaba localizable.

La verdad es que el Notes, as nivel de interfaz y de la lógica de ejecutar las acciones es rebuscado, de ahí su baja popularidad entre los usuarios, pero para administrarlo no lo es mucho, aunque la lógica de ejecución y realización de operaciones sobre él sigue siendo la misma, pero para los IT Pros no hay mucho problema ya que nos dedicamos a probar lo todo.

En resumen, la instalación del software, es un siguiente, siguiente, siguiente, … si no te encuentras que te falta algo como me pasó a mí. Como tenía que restaurar un servidor, necesitaba conseguir el ID (fichero de registro de los elementos registrados en el Domino: máquinas, servidores, etc.) del servidor antiguo y justo este ni estaba en el names (BBDD donde Domino gestiona todos los elementos registrados) y menos lo encontré perdido por algún directorio de los múltiples que tenemos en la empresa.
De tenerlo, creo que hubiese podido asociar esa nueva instalación al servidor ya registrado, pero al no ser así tuve que crear un nuevo servidor, al cual le puede poner el mismo nombre que antiguo, préviamente habiendo renombrado al antiguo, y no hizo falta mucho más para que el Domino continuara tratando el nuevo servidor como el servidor existente.

Evaluación
Finalmente la experiencia no ha estado más, ahora ya sé instalar un servidor Lotus Notes, añadirlo a un Domino existente, además de haber aprendido y encontrado múltiples herramientas y operaciones de administración que Lotus Notes tiene.
Para los usuarios y la continuidad de negocio, ha sido un mal menor, ser perdió poca información importante, al menos para la empresa, para el usuario que la ha perdido parece algo más importante, y como siempre, si se hubiese tenido una copia de seguridad en toda regla el impacto de perdida de información hubiese sido minúsculo, pero si no la hay, puedo constatar que es por falta de inversión en TI, no solo en máquinas (que si que hace falta) sino en aplicaciones y en recursos humanos.

Tengo previsto, espero que sea en un breve espacio de tiempo, escribir alguna entrada sobre algunas cosas que he descubierto de Lotus Notes, que me han sorprendido como funcionan, y que me han tenido perdiendo una parte del tiempo, ya que remendando por Internet, en Google y en la documentación de IBM, no logré encontrar, con el objetivo de que a alguien le puedan ser útiles.


Hasta la próxima enfermos.

10 de octubre de 2010

Gestionando incidencias de manera organizada (3/3)

conjuntoEntradas() {

Planificando la resolución
Asumiendo mi rol, por falta de la persona al cargo y por la poca experiencia de mi compañero, no sin motivos justificados, decidí invertir mi maravillo tiempo dentro de la jornada y fuera de él, a planificar la resolución de la incidencia, que se iba a atender al día siguiente y fuera de la jornada laboral para no entorpecer la actividad diaria de la empresa, después de saber que se tenía que restablecer el sistema por completo.

Como por motivos de productividad y disponibilidad no se podía atender el mismo día, yo tenía más tiempo de realizar una mejor planificación, más detallada, pensada y documentada. Así que pensé y evalué exhaustivamente la situación y de ahí saque un documento donde se detallaba lo sucedido, los sistemas afectados y el tiempo necesario para su restauración completa (debido al volumen de información), las actuaciones a realizar sobre los sistemas afectados indirectamente y la lista de acciones a llevar a cabo de manera correlativa.

Al plasmar todo esto en un documento, me permitió tener un mejor razonamiento de la situación y de sus resolución; además el documento iba a ser a la guía para hacer lo de manera metódica y no olvidarse de nada, dar un soporte a la explicación verbal mi compañero para que lo tuviese más claro y pudiese acudir en caso de duda, teniendo presente que la incidencia era en la oficina donde él estaba y que nos separaban unos 600 km y además tener un informe de la incidencia algo que nunca se ha hecho y que en situaciones futuras se puede llegar agradecer, como los planes de contingencia, que por cierto a falta de recursos, también son inexistentes.

Con todo lo que acabo de mencionar, creo que el tiempo invertido en crear el mencionado documento, ha sido de sobras, rentabilizado, además de la satisfacción de trabajar planificada y organizadamente, y más cuando algún miembro el equipo está desconcertado y con poco control de la situación.

Aquí os dejo un documento modelo del que realicé por si puede servir de algo.

Conclusiones
Las incidencias surgen cuando toca y es bastante complicado o prácticamente imposible predecir cuando van a suceder así que cuando más preparado estés, planes de contingencia, infraestructura de backups, copias de seguridad actualizadas de la información y de los sistemas críticos (configuraciones, parametrizaciones, etc.), sistemas hardware replicados y preparados para soportar posibles fallos, etc., y sobre todo cuando no hay un plan de acción para la situación o una situación que se lo asemeje y hay un margen temporal de reacción entonces piensa, razona y elabora un planning de como vas a abordar la resolución y restauración manteniendo el servicio los más disponible posible mientras actúas y si no eres un lobo solitario y tienes compañía, un equipo o un único compañero, explícale el planning y hazle participe en las situaciones que le implican directamente, si realmente quieres que “te eche un cable” y le ponga ganas al asunto.

Hasta la próxima enfermos.

6 de octubre de 2010

Gestionando incidencias de manera organizada (2/3)

conjuntoEntradas() {

Descripción de la incidencia
Durante la mañana se detecta que el servidor está offline; entonces se procede a verificar el motivo y se detecta que está en la pantalla justo antes de realizar el boot del sistema operativo.

Se revisa lo que sucede y desde la controladora SATA-RAID se detecta que dos discos están en estado offline, por lo que se prueba de forzar su estado a online y se revisa si el sistema operativos es capaz de arrancar. Por ahora aunque el indicativo es que el fallo es de dos disco, al encontrarlos en estado offline y no en estado fail puede que el fallo haya sido, aunque poco probable, por otra causa.

El sistema operativo arranca, por lo que el servicio esta de nuevo disponible. Tras arrancar se decide instalar un aplicación del fabricante que monitorea el estado del hardware, esto ya es un FAIL por no tenerlo instalado desde que el servidor se puso en producción. Con dicha aplicación se pueden lanzar test sobre el hardware, en este caso lo hicimos sobre los discos, y en el test se comprueba que un disco falla, así que se llega a la conclusión que el reinicio pudo ser algo puntual por fallo de un disco algo que siendo un RAID 5 no tendría porque haber sucedido, pero al arrancar sin problemas de nuevo, no da pie a pensar, después del test, que haya dos discos dañados.

Se tramita el cambio de disco con el fabricante y al día siguiente, antes de que empiece la jornada laboral, se reemplaza.

El servicio se levantó en menos de una hora y se mantuvo todo el día, pero al día siguiente después de haber reemplazado el disco, el servicio se vuelve a detener con los mismos síntomas; esta vez el disco que el día anterior había estado offline se encuentra en estado fail, no obstante se puede de nuevo levantar el servidor y con otro aplicación de diagnóstico se obtiene un estado del servidor en un fichero de log que tras el análisis por parte del fabricante se dictamina que el segundo disco también está averiado. Debido a que el fallo, se produjo en dos discos, se nos indica que hay que reinstalar todo el sistema de nuevo, ya que el error puede haberse propagado al resto del RAID y eso puede producir inestabilidades en el sistema.

Aquí es cuando para mí empieza el tratamiento de la incidencia de manera planificada, ya que hasta el momento ha sido acción-reacción ya que el problema estaba ahí y había que resolverlo lo antes posible y las circunstancias han permitido activar y mantener de nuevo el servicio y tener un margen acotado de tiempo para organizar como eliminar el problema definitivamente.

No me voy a alargar más explicando que es lo que se ve afectado por la caída de uno de los servidores de almacenamiento en una de las oficinas, ya que tendría que entrar en bastante detalle en el funcionamiento del sistema y no es el objetivo de esta serie de posts.

Información a los usuarios
Yo soy de los que prefiere estar informado de las cosas y vivir la realidad antes que vivir engañado pensando que todo es un jardín de rosas.

Esta es una de las cosas que yo he echado en falta desde que rondo por la empresa, siempre que pasa algo y en algunas ocasiones, se va hacer algo no se informa ni se advierte de nada a los usuarios. Sé que a veces esto puede ser contraproducente, por la idea que algunos se puedan hacer de la situación, pero creo que eso se soluciona dando un explicación con los mínimos tecnicismos que se pueda pero que te permita explicar de lo que sucede y como se va a solventar la incidencia, esto último es muy importante mencionarlo y como se dice para que no cunda el pánico.

Así que con el rol que tenía desde un primer momento decidí mantener a los usuarios informados para evitar, la sicosis de estos, ya que cuando lo que involucra la incidencia es información y encima la que está generando día día los empleados con su esfuerzo, es lo que le coge a todos, supongo que pensando las N horas extras sin remuneración que tendrán que hacer para restablecer el trabajo ya realizado.

Manteniendo los informados, también te evitas que te suene el teléfono cada 2 minutos, preguntando te que sucede y cuando va a estar solucionado además de escuchar, en algunos casos, despotricaciones varias; por lo que el tiempo que dedicas escribiendo el comunicado, creo que se rentabiliza, de manera lineal al número de usuarios afectados.

Además en este caso, también era necesario información que actividades podían desarrollar con normalidad y cuales no y como hacer un workarround mientras se solventaba la incidencia.

Hasta la próxima enfermos.

2 de octubre de 2010

Gestionando incidencias de manera organizada (1/3)

conjuntoEntradas() {

De que va esto
En esta serie de posts voy escribir una posible forma de gestionar de una manera más o menos organizada como se debería gestionar una incidencia en empresa de tamaño medio con menos personas en el departamento de TI de lo que realmente sería necesario, teniendo en cuenta que tampoco se contratan recursos externos (outsourcing y/o insourcing).
Antes de continuar con el tema a tratar quiero dejar claro que lo aquí descrito no tiene que ser lo estrictamente correcto y mucho menos la manera perfecta, todo se puede mejorar; ésta, ni de lejos, es la única vía para tratar incidencias, pero si, desde mi punto de vista, una manera ordenada, organizada y metódica de hacerlo, aunque el resto es libre de opinar de otro modo, y por mi parte lo respeto totalmente.
Porque ahora
Si ahora estoy escribiendo este conjunto de posts es porque antes de ir me de vacaciones, tuve que afrontar, en la empresa donde ahora trabajo, una incidencia; esta vez a diferencia de las demás tenía que asumir el rol de gestionar su resolución debido a que el responsable que lo tendría que hacer estaba gozando de sus merecidas vacaciones. En el pasado he participado en muchas otras pero siempre he tenido un papel de técnico que le indican que es lo que tiene que ir haciendo y como se tiene que coordinar con el resto del equipo y siempre he pensado, ya sea por la situación del departamento dentro de la empresa (no hay tiempo material dentro de la jornada laboral, con los recursos que somos para hacer las cosas bien) o por cualquier otro motivo, que, el orden, la coordinación y la metodología han sido inexistentes.

Todo esto quería publicarlo en el momento que pasó pero entre las vacaciones, el volumen de trabajo al regreso en la empresa en la cual trabajo y nuevos retos profesionales en modo freelance me ha obligado a retrasar su publicación.

Escenario organizativo
El escenario en el que se desarrollo la incidencia es el siguiente:
  • Empresa con unos 110 usuarios aproximadamente, de los cuales unos 80 trabajando en las tres oficinas que consta la empresa, el resto de vacaciones, de viaje de negocios o trabajan fuera por la actividad que están desarrollando.
  • Departamento de TI, o podríamos decir de mierdas varias, formado por 4 personas, 2 en la oficina de Madrid, 1 en Bilbao y el otro, yo, en Barcelona. Dadas las fechas, solo eramos dos, yo, y el recién incorporado y recién terminado un CGS de Administración de Sistemas, en Madrid.

Escenario tecnológico
La infraestructura de comunicación, la descrita en este post, pero ahora sin la cuarta oficina, Málaga, que la crisis ha obligado a cepillarse la.
Se utiliza el sistema DFS (Distributed File System), para mantener replicados en las 3 oficinas gran parte de los espacios de almacenamiento de documentos de trabajo, pero sin Share Point, usando un sistema de acceso desarrollado en la empresa para atacar los repositorios evitando accesos simultáneos a mismo fichero, sobre este punto, no hago manifestaciones, ya que no es el objetivo de este conjunto de posts.
Usamos 3 máquinas en cada oficina para el almacenamiento de la información, replicando se en malla por pares, es decir los 3 servidores de una oficina contienen información distinta, por lo que no se replican entre ellos, y se replican con sus 3 homólogos ubicados en las otras dos oficinas; y lo hacen las 24 horas y con todo el ancho de banda que la red les dé.

Sistema afectado
La incidencia fue originada por el fallo de dos discos montados en RAID 5 de uno de los 3 servidores de almacenamiento ubicado en la oficina de Madrid.

Hasta la próxima enfermos.