Capítulo 8. Planificación para Desastres

La planificación para desastres es fácil de olvidar para un administrador de sistemas — no es agradable y siempre pareciera que hay algo más importante que hacer. Sin embargo, dejar pasar la planificación para desastres es una de las peores cosas que un administrador de sistemas puede hacer.

Aunque a menudo se trata de los desastres dramáticos (tales como un incendio, una inundación o tormenta) lo que primero viene a la mente, los problemas más mundanos (tales como que unos contructores corten los cables por accidente o un lavamanos que esté botando agua) pueden ser igualmente destructivos. Por lo tanto, la definición de un desastre que un administrador debe tener en mente, es cualquier evento no planeado que pueda interrumpir la operación normal de la organización.

Aunque sería imposible listar todos los tipos diferentes de desastres que podrían ocurrir, esta sección examina los factores principales que forman parte de cada tipo de desastre para que asi cualquier exposición a un desastre se pueda examinar no en términos de su posibilidad, pero si de los factores que podrían llevar a un desastre.

8.1. Tipos de desastre

En general, hay cuatro tipos de factores diferentes que pueden disparar un desastre. Estos factores son:

8.1.1. Fallas del hardware

Las fallas de hardware son fáciles de entender - el hardware falla y el trabajo se detiene. Lo que es más dificil de entender es la naturaleza de las fallas y cómo se puede minimizar su exposición a ellas. He aquí algunos enfoques que puede utilizar:

8.1.1.1. Mantener partes adicionales de hardware

En su forma más simple, las exposiciones debidas a fallas del hardware se pueden reducir manteniendo repuestos de hardware adicionales. Por supuesto, este enfoque asume dos cosas:

  • Alguien está en el sitio con suficientes habilidades para diagnosticar el problema, identificar la parte defectuosa y reemplazarla.

  • Está disponible un repuesto para el hardware defectuoso.

Estos problemas se cubren con más detalles en las secciones siguientes.

8.1.1.1.1. Tener las habilidades

Dependiendo de sus experiencias pasadas y del hardware relacionado, el tener las habilidades necesarias puede que no sea un problema. Sin embargo, si no ha trabajado con hardware anteriormente, puede considerar buscar en los colegios

SugerenciaSugerencia
 

Antes de tomar este enfoque de reparar las cosas ud mismo, asegurese de que el hardware:

  • No se encuentra bajo garantía

  • No está bajo ningún contrato de servicio/mantenimiento

Si usted trata de reparar un hardware que se encuentra cubierto por una garantía o contrato de servicio, lo más probable es que estará violando los términos del acuerdo y estará poniendo en peligro su cobertura.

Sin embargo, aún con las habilidades mínimas, puede ser posible diagnosticar efectivamente y reemplazar un hardware defectuoso — si selecciona cuidadosamente sus repuestos.

8.1.1.1.2. ¿Qué cosas tener en almacén?

Esta pregunta ilustra la naturaleza multifacética de las cosas relacionadas con desastres. Cuando considere qué repuestos tener en almacén, he aquí algunas de las cosas que debe tener en mente:

  • Tiempo máximo permitido fuera de servicio

  • La habilidad requerida para hacer la reparación

  • El presupuesto disponible para los repuestos

  • Espacio de almacenamiento requerido para los repuestos

  • Otro hardware que podría utilizar el mismo repuesto

Cada uno de estos problemas tiene una trascendencia en los tipos de repuestos que se deberían guardar en almacén. Por ejemplo, al almacenar sistemas completos se tiende a reducir el tiempo fuera de servicio y requiere habilidades mínimas para instalar, pero sería muchísimo más costoso que tener un CPU y un módulo RAM de repuestos. Sin embargo, este costo puede ser justificado si su organización tiene varias docenas de servidores idénticos que se podríanbeneficiar de tener un sistema adicional de repuesto.

No importa cual sea la decisión final, la pregunta siguiente es inevitable y se discute a continuación.

8.1.1.1.2.1. ¿Cuánto guardar en almacén?

La pregunta de los niveles de repuestos es también multifacética. He aquí los principales problemas:

  • Tiempo máximo permitido fuera de servicio

  • Tasa de fallas proyectada

  • Tiempo estimado de reemplazo del repuesto

  • El presupuesto disponible para los repuestos

  • Espacio de almacenamiento requerido para los repuestos

  • Otro hardware que podría utilizar el mismo repuesto

En un extremo, para un sistema que puede permitirse estar fuera de servicio dos días y una parte que puede ser utilizada una vez en un año y que se puede reemplazar en un día, tendría sentido guardar solamente un repuesto (y quizás hasta ninguno, si tiene confianza de su habilidad de asegurar un repuesto en 24 horas).

Por otro lado, un sistema que no se puede permitir estar fuera de servicio más que unos pocos minutos, y un repuesto que podría utilizarse una vez al mes (y que podría tomar semanas en reemplazar) podría significar que se necesiten media docena de repuestos (o quizás más).

8.1.1.1.3. Repuestos que no son repuestos

¿Cuándo un repuesto no es un repuesto? Cuando es hardware que se utiliza día a día pero que también está disponible como repuesto para un sistema de mayor prioridad, si surge la necesidad. Este enfoque tiene sus beneficios:

  • Menos dinero dedicado a repuestos "no productivo"

  • Se sabe que el hardware funciona

Sin embargo, este enfoque tiene sus desventajas:

  • La producción normal de la tarea de menor prioridad es interrumpida

  • Hay una exposición si la tarea de menor prioridad falla (no dejando ningún repuesto para el hardware de mayor prioridad)

Dadas estas limitaciones, el uso de otro sistema en producción como un repuesto puede funcionar, pero el éxito de este enfoque depende de la carga de trabajo específica del sistema y del impacto de la ausencia del sistema en las operaciones generales de la organización.

8.1.1.2. Contratos de servicios

Los contratos de servicios pasan el problema de las fallas de hardware a alguien más. Lo único que necesita hacer es confirmar que ha ocurrido una falla y que no parece estar relacionado a un problema de software. Usted simplemente hace la llamada y alguien más aparece para encargarse de que las cosas esten en funcionamiento otra vez

Parece muy simple. Pero como con la mayoría de las cosas en la vida, hay mucho más de lo que el ojo puede ver. He aquí algunas cosas que debería considerar cuando esté revisando contratos de servicios:

  • Horas de cobertura

  • Tiempo de respuesta

  • Partes disponibles

  • Presupuesto disponible

  • Hardware cubierto

Exploramos cada uno de estos detalles más de cerca en las secciones siguientes.

8.1.1.2.1. Horas de cobertura

Hay diferentes contratos de servicios disponibles para satisfacer necesidades diferentes; una de las grandes variables entre los contratos se relaciona con las horas de cobertura. A menos que esté dispuesto a pagar un contrato premium por ese privilegio, usted no puede simplemente llamar a la hora que quiera y esperar a que unos pocos minutos después aparezca un técnico en la puerta.

En vez de esto, dependiendo de su contrato, quizás ni siquiera pueda llamar a la compañía si no en un día/hora específica, o si puede, probablemente no envíen un técnico hasta la hora o fecha que está especificado en su contrato.

La mayoría de las horas de cobertura son definidas en términos de las horas y los días durante los cuales se puede enviar un técnico. Algunas de las horas de cobertura más comunes son:

  • Lunes a viernes desde las 09:00 hasta las 17:00

  • Lunes a viernes, 12/18/24 horas cada día (con los tiempos de comienzo y de finalización acordados mutuamente)

  • Lunes a sábado (o de lunes a domingo), las mismas horas que anteriormente

Como puede esperarse, el costo de un contrato se incrementa con las horas de cobertura. En general, extender la cobertura de lunes a viernes tiende a costar menos que añadir sábado y domingo.

También aquí hay una posibilidad de reducir los costos si está dispuesto a hacer algo del trabajo.

8.1.1.2.1.1. Servicio de depósito

Si su situación no requiere más que la disponibilidad de un técnico durante las horas laborales normales y tiene la experiencia suficiente como para determinar lo que está dañado, puede considerar la opción de un servicio técnico o depot service. Conocido por muchos nombres diferentes (incluyendo walk-in service y drop-off service), los fabricantes pueden tener este tipo de servicios donde los técnicos trabajan en el hardware que los clientes traen.

Los servicios técnicos tienen la ventaja de ser tan rápidos como usted. Usted no tiene que esperar a que un técnico esté disponible y vaya a sus oficinas. Los técnicos de este tipo de servicio no se desplazan hasta sus instalaciones, lo que significa que alguien puede trabajar en su hardware tan pronto como usted lo pueda entregar en el servicio.

Debido a que los Servicios Técnicos se hacen una ubicación central, es muy probable que las partes requeridas se encuentren disponibles. Esto puede eliminar la necesidad de un despacho nocturno inmediato o de esperar a que la parte llegue desde muchos kilómetros de distancia desde otra oficina que al parecer posee una de estas partes en almacén.

Sin embargo, esto tiene sus desventajas. La más obvia es que usted no puede escoger las horas de servicio — usted recibe el servicio cuando el Servicio Técnico está abierto. Otro aspecto es que los técnicos no trabajan luego de sus horas normales, por lo que si su sistema falló un viernes a las 4:30 pm y usted llegó al Servicio Técnico a las 5:00 pm, nadie trabajará en su equipo hasta el siguiente lunes en la mañana.

Otra desventaja es que el Servicio Técnico depende de que se encuentre cercano a su negocio. Si su organización se encuentra ubicada en la zona metropolitana, es posible que esto no sea un problema. Sin embargo, las organizaciones en ubicaciones más rurales pueden tener el Servicio Técnico a un largo camino.

SugerenciaSugerencia
 

Si está considerando un Servicio Técnico, tómese un momento para considerar los mecanismos para hacer llegar el hardware hasta el servicio. ¿Utilizará el vehiculo de la compañía o propio? Si utiliza su propio vehículo, ¿Su vehículo tiene el espacio y la capacidad de carga suficiente?, ¿Qué hay del seguro? ¿Se necesitará más de una persona para descargar el hardware?

Aunque estas son preocupaciones mundanas, se deberían considerar antes de tomar la decisión de utilizar un Servicio Técnico.

8.1.1.2.2. Tiempo de respuesta

Además de las horas de cobertura, muchos acuerdos de servicios especifican un nivel de tiempo de respuesta. En otras palabras, cuando usted llama pidiendo un servicio, ¿cuánto tiempo debe esperar hasta que llegue un técnico? Como se puede imaginar, mientras más rápida la respuesta más costoso será el acuerdo.

Existen límites para los tiempos de respuesta disponibles. Por ejemplo, el tiempo de viaje desde las instalaciones del fabricante hasta las suyas, tiene una gran trascendencia en los tiempos de respuesta posibles[1]. Los tiempos de respuesta dentro del rango de cuatro horas generalmente se consideran entre las opciones más rápidas. Tiempos de respuesta más lentos pueden ir desde ocho horas (lo que efectivamente se convierte en un servicio de "al día siguiente" para un acuerdo de horas laborales estándar) hasta 24 horas. De la misma manera que con los otros aspectos de un acuerdo de servicios, aún estos tiempos son negociables — por el precio correcto.

NotaNota
 

Aún cuando no ocurre frecuentemente, debe estar consciente de que los acuerdos de servicios con claúsulas de tiempos de respuesta, algunas veces pueden estirar el servicio de un fabricante más allá de su habilidad para responder. A veces se escucha de organizaciones que envian a alguien — cualquier persona — para responder a una llamada de servicio con tiempos de respuesta cortos, simplemente para cubrir su responsabilidad. Esta persona aparentemente diagnostica el problema y llama a "la oficina" para solicitar que alguien traiga "la parte correcta".

En realidad, están esperando a que llegue la persona que es capaz realmente de manejar la llamada.

Aunque quizás se pueda entender que esto ocurra bajo circunstancias extraordinarias (tales como problemas de energía que han dañado los sistemas a lo largo del área de servicio), si este es un método consistente de operación, debería contactar al gerente de servicios y solicitar una explicación.

Si sus necesidades de tiempo de respuesta son rigurosas (y su presupuesto adecuadamente grande), hay un enfoque que puede recortar sus tiempos de respuesta aún más — inclusive a cero.

8.1.1.2.2.1. Tiempo de respuesta cero — Disponer de un técnico in situ

Dada la situación adecuada (usted es uno de los clientes más grandes en la zona), necesidad suficiente (el tiempo fuera de servicio de cualquier magnitud es inaceptable) y los recursos financieros (si pregunta por el precio, lo más probable es que no lo pueda pagar), quizás sea un candidato para un técnico a tiempo completo in situ. Los beneficios de tener a un técnico disponible son obvios:

  • Respuesta inmediata a cualquier problema

  • Un enfoque más proactivo al mantenimiento del sistema

Como puede esperarse, esta opción puede ser muy costosa, particularmente si requiere de un técnico in situ 24x7. Pero si este enfoque es apropiado para su organización, debe tener varios puntos en mente para sacar el máximo provecho.

Primero, los técnicos in situ necesitan muchos de los recursos de un empleado regular, tales como espacio de trabajo, teléfono, tarjetas de acceso/llaves, etc.

Los técnicos in situ no son de mucha ayuda si no cuentan con las partes correctas. Por lo tanto, asegúrese de que se tiene un almacenamiento seguro para los repuestos del técnico. Además, asegúrese de que el técnico mantenga un inventario de repuestos apropiado para su configuración y que estas partes no sean consumidas por otros técnicos para sus clientes.

8.1.1.2.3. Partes disponibles

Obviamente, la disponibilidad de partes juega un papel importante en limitar la exposición de su organización a fallas de hardware. En el contexto de un acuerdo de servicio, la disponibilidad de partes toma otra dimensión, pues la esta no solamente aplica a su organización, pero también a cualquier otro cliente en el territorio que pueda necesitar esas partes. Otra organización que ha comprado más hardware del fabricante que usted, puede recibir un trato preferencial cuando se refiere a conseguir los repuestos (y por ende los técnicos).

Lamentablemente, hay muy poco por hacer en tales circunstancias, más allá de tratar de resolver la situación con el gerente de servicios.

8.1.1.2.4. Presupuesto disponible

Como se mencionó anteriormente, los contratos de servicios varían en precio de acuerdo a la naturaleza de los servicios que se suministren. Tenga en cuenta que los costos asociados con un contrato de servicio son un gasto recursivo; cada vez que se vence el contrato, usted debe negociar un nuevo contrato y pagar nuevamente.

8.1.1.2.5. Hardware cubierto

He aquí un área donde puede ayudar a mantener los costos a un mínimo. Considere por un momento que usted ha negociado un acuerdo de servicio que tiene a un técnico in situ 24x7, repuestos in situ — y todo lo necesario. Cada pieza de hardware que compre de este fabricante está cubierta, incluyendo la PC que la recepcionista de la compañía utiliza para tareas no críticas.

Esa PC realmente necesita a alguien in situ 24x7? Aún si esa PC es vital para el trabajo del/de la recepcionista, este(a) solamente trabaja de 09:00 a 17:00; es muy improbable que:

  • La PC será utilizada desde 17:00 hasta las 09:00 de la mañana siguiente (sin mencionar los fines de semana)

  • Una falla de esta PC será notable, excepto durante 09:00 y 17:00

Por lo tanto, pagar por la casualidad de que esta PC necesite servicio a mitad del sábado en la noche, es una pérdida de dinero.

Lo que hay que hacer aquí es dividir el acuerdo de servicio de manera que el hardware que no sea crítico esté agrupado de forma separada al hardware crítico. De esta forma, se pueden reducir los costos.

NotaNota
 

Si tiene veinte servidores configurados de forma idéntica que son críticos para su organización, puede estar tentado a tener un acuerdo de servicio de alto nivel para uno o dos, dejando el resto cubiertos por un acuerdo mucho más económico. Luego, no importa cual de los servidores falle durante el fin de semana, usted dirá que es uno de los elegibles para el servicio de alto nivel.

No lo haga. No solamente es deshonesto, pero además la mayoría de los fabricantes hacen un seguimiento de tales cosas usando los números de seriales. Aún si usted se las arregla para tales verificaciones, se gasta mucho más luego de ser descubierto que siendo honesto y pagando por el servicio que realmente necesita.

8.1.2. Fallas del software

Algunas fallas de software pueden resultar en largos tiempos fuera de servicio. Por ejemplo, los dueños de cierta marca de computadores conocidos por sus funcionalidades de alta disponibilidad, descubren esto a primeras. Un error en el código de manejo de tiempo del sistema operativo del computador resultó en que los sistemas fallen a cierta hora de cierto día. Mientras que esta situación es un ejemplo más espectacular de una falla de software en acción, otras fallas relacionadas con el software pueden ser menos dramáticas, pero aún devastadoras.

Las fallas del software pueden golpear en dos áreas:

  • Sistema operativo

  • Aplicaciones

Cada tipo de falla tiene su impacto específico y se exploran en más detalles en las secciones siguientes.

8.1.2.1. Fallas del sistema operativo

En este tipo de falla, el sistema operativo es responsable por la interrupción del servicio. Las fallas del sistema operativo vienen de dos áreas:

  • Caídas del sistema

  • Colgarse o bloquearse

Lo principal a tener en cuenta sobre las fallas del sistema operativo es que estas sacan cualquier cosa que el computador estaba ejecutando en ese momento. Como tales, las fallas del sistema operativo pueden ser devastadoras para la producción.

8.1.2.1.1. Caídas del sistema

Las caídas ocurren cuando el sistema opertativo experimenta una condición de error desde la cual no se puede recuperar. La razón de las caídas pueden variar desde una incapacidad para manejar un problema de hardware subyacente hasta un error en el código a nivel del kernel abarcando el sistema operativo. Cuando un sistema operativo falla, se debe reiniciar el sistema para poder continuar la producción.

8.1.2.1.2. Colgarse o bloquearse

Cuando el sistema operativo deja de manejar estos eventos, el sistema se detiene aparatosamente. Esto se conoce como un bloqueo o se dice que el computador está colgado. Los interbloqueos (también conocido como deadlock, cuando dos recursos se disputan los recursos que el otro posee) o livelocks (dos o más procesos respondiendo a las actividades de cada uno, pero sin hacer un trabajo útil) pueden provocar que el sistema se cuelgue, con el mismo resultado final — una falta total de productividad.

8.1.2.2. Fallas de las aplicaciones

A diferencia de las fallas del sistema, las fallas de las aplicaciones pueden ser más limitadas en el ámbito de lo que dañan. Dependiendo de la aplicación específica, una sola aplicación que esté fallando puede afectar solamente a un usuario. Por otro lado, si se trata de una aplicación de servidor que está sirviendo a una gran población de aplicaciones clientes, las consecuencias de la falla serían mucho más extensas.

Las fallas de las aplicaciones, igual que otras fallas del sistema, pueden ser causadas por caidas o bloqueos; la única diferencia es que aquí es la aplicación la que se está guindando o fallando.

8.1.2.3. Obteniendo ayuda — Asistencia de software

De la misma forma que los fabricantes de hardware ofrecen soporte para sus productos, muchos proveedores de software colocan paquetes de soporte disponibles a sus clientes. Excepto por las diferencias obvias (no se requieren repuestos y la mayoría del trabajo lo puede hacer el personal de soporte a través del teléfono), los contratos de soporte de software pueden ser bastante similares a los contratos de hardware.

El nivel de soporte suministrado por un fabricante de software puede variar. He aquí algunas de las estrategias de soporte más comunes empleadas hoy día.

  • Documentación

  • auto-asistencia

  • Soporte de Web o de correo electrónico

  • Soporte telefónico

  • Soporte in situ

Cada tipo de asistencia se describe en más detalles en las secciones siguientes.

8.1.2.3.1. Documentación

Aunque a veces es ignorada, la documentación del software puede servir como una herramienta de soporte de primer nivel. Bien sea en línea o impresa, la documentación a menudo contiene la información necesaria para resolver muchos problemas.

8.1.2.3.2. Auto asistencia

La auto asistencia confia en que el cliente utiliza los recursos en línea para resolver sus propios problemas relacionados al software. A menudo estos recursos toman la forma de FAQs (Preguntas más frecuentes) basadas en el Web o bases de datos de conocimientos.

Las FAQs tiene poca o ninguna capacidad de selección, dejando que el cliente se desplace pregunta por pregunta con la esperanza de encontrar una que mencione el problema que tiene. Las bases de conocimiento tienden a ser un poco más sofisticadas, permitiendo la entrada de términos para realizar búsquedas. Las bases de conocimientos también pueden ser bien completas en ámbito, convirtiéndola en una buena herramienta para resolver problemas.

8.1.2.3.3. Soporte Web o de correo electrónico

Muchas veces lo que a veces parece un sitio de auto asistencia, también incluye algunas formas basadas en web o correo electrónico que permiten que la persona pueda enviar preguntas al personal de soporte. Mientras que esto puede parecer a primera vista una mejora de un buen sitio web de auto asistencia, realmente depende de la gente que contesta los correos.

Si el personal de soporte está saturado de trabajo, es dificil obtener la información necesaria de ellos, pues su principal preocupación es la de responder rápidamente a cada correo y moverse al siguiente. La razón de esto es que casi todo el personal de soporte usualmente es evaluado por el número de problemas que pueden resolver. Los problemas de escalada también son complicados porque hay poco que hacer dentro de un correo electrónico para promover respuestas con mejores tiempos de respuestas y más útiles — particularmente cuando la persona leyendo su correo está apurado para moverse al siguiente.

La forma de obtener el mejor servicio es asegurarse de que su correo electrónico responde todas las preguntas que un técnico podría preguntarle, tales como:

  • Claramente describa la naturaleza del problema

  • Incluya todos los números de versión pertinentes

  • Describa lo que ya ha hecho en un intento de resolver el problema (aplicó los últimos parches, reinición con la configuración mínima, etc.)

Al darle al técnico de soporte más información, tiene más oportunidades de obtener la asistencia que necesita.

8.1.2.3.4. Soporte telefónico

Como su nombre implica, el soporte telefónico implica hablar con un técnico a través del teléfono. Este estilo de soporte es más similar al soporte de hardware; en que pueden haber diferentes niveles de soporte disponible (con diferentes horas de cobertura, tiempo de respuesta, etc.)

8.1.2.3.5. Soporte in situ

También conocido como consultorías in situ, el soporte de software in situ normalmente está reservado para resolver problemas específicos o para efectuar cambios críticos, tales como la instalación y configuración inicial, actualizaciones importantes, etc. Como se puede esperar, este es el tipo de soporte más costoso.

Sin embargo, hay situaciones en las que las consultorías in situ tienen sentido. Como ejemplo considere una pequeña organización con un único administrador de sistemas. La organización va a implementar su primer servidor de bases de datos, pero la implementación (y la organización) no es lo suficientemente grande como para justificar la contratación de un administrador de bases de datos dedicado. En esta situación, a menudo puede ser más económico traer a un especialista de un proveedor de bases de datos para que maneje la implementación inicial (y ocasionalmente más adelante, si surge la necesidad) que entrenar al administrador de sistemas con una habilidad que será utilizada muy de vez en cuando.

8.1.3. Fallas ambientales

Los problemas pueden ocurrir aún cuando el hardware se está ejecutando perfectamente y aunque el software esté configurado de la forma adecuada. Los problemas más importantes que ocurren fuera del sistema mismo tienen que ver con el ambiente físico en el cual reside el sistema.

Los problemas ambientales se pueden desglosar en cuatro categorías:

  • Integridad del edificio

  • Electricidad

  • Aire acondicionado

  • Tiempo y el mundo exterior

8.1.3.1. Integridad del edificio

Para ser una estructura tan simple, un edificio realiza una gran cantidad de funciones. Proporciona un refugio contra los elementos. Suministra el ambiente climático adecuado para los contenidos del edificio. Tiene mecanismos para proporcionar energía y protección contra fuegos, robos y vandalismo. Para realizar todas estas funciones, no es una sorpresa que hayan muchas cosas que pueden salir mal con un edificio. He aquí algunas de las posibilidades a considerar:

  • Los techos pueden tener goteras, dejando pasar agua hasta los centros de datos.

  • Varios sistemas del edificio (tales como agua, desagues, o manejo del aire) pueden fallar, dejando el edificio inhabitable.

  • Los pisos puede que no tengan suficiente capacidad para soportar el equipo que desea colocar en su centro de datos.

Es importante tener una mente creativa cuando se tiene que pensar sobre las diferentes formas en que un edificio puede fallar. La lista de arriba solamente es un comienzo para ponerlo a pensar en esta dirección.

8.1.3.2. Electricidad

Debido a que la electricidad es como la sangre de cualquier sistema computacional, los problemas relacionados a la energía son de suprema importancia en la mente de un administrador de sistemas. Hay muchos aspectos diferentes sobre la electricidad; estos se cubren con más detalles en las secciones siguientes.

8.1.3.2.1. La seguridad de su energía

Primero, es necesario determinar que tan seguro es su suministro de energía. De la misma forma que cualquier otro centro de datos, probablemente obtenga su electricidad desde la compañía eléctrica local a través de líneas de transmisión. Debido a esto, hay límites para lo que puede hacer para asegurarse de que su suministro principal de energía es tan seguro como pueda ser posible.

SugerenciaSugerencia
 

Las organizaciones ubicadas cercanas a una compañía eléctrica quizás puedan negociar conexiones a dos rejillas de energía diferentes:

  • La que sirve a su zona

  • La que viene de la compañía eléctrica vecina

Los costos asociados con la implementación de líneas eléctricas directas desde la rejilla vecina son considerables, haciendo esto una opción solamente para organizaciones bastante grandes. Sin embargo, a tales organizaciones les puede parecer que la redundancia obtenida es mucho más valiosa que los costos en muchos casos.

Aquí, lo principal a verificar son los métodos a través de los cuales la energía es traída a las instalaciones de su organización y dentro del edificio. ¿Las líneas de transmisión están por debajo o sobre la tierra? Las líneas sobre el suelo son susceptibles a:

  • Daños por condiciones ambientales extremas (hielo, viento, relámpagos)

  • Accidentes de tránsito que dañan los postes y/o transformadores

  • Animales perdidos en el lugar incorrecto y cortando las líneas

Sin embargo, las líneas bajo tierra tienen sus limitaciones únicas:

  • Daños de trabajadores de construcción cavando en los lugares incorrectos

  • Inundaciones

  • Relámpagos (sin embargo, mucho menos que con las líneas sobre la tierra)

Continue haciendo un seguimiento a las líneas eléctricas dentro de su edificio. ¿Primero van a un transformador externo? ¿Está el transformador protegido contra vehículos o contra árboles que se puedan caer sobre el? ¿Los interruptores de apagado están protegidos contra usos no autorizados?

Ya dentro del edificio, ¿pueden estar las líneas de energía (o los páneles a las cuales se conectan) sujetas a otros problemas? Por ejemplo, ¿puede un problema de plomería inundar la sala eléctrica?

Continue haciendo el seguimiento de la energía hasta el centro de datos; ¿hay alguna otra cosa inesperada que pueda interrumpir el suministro de energía? Por ejemplo, ¿está el centro de datos compartiendo uno o más circuitos con cargas que no son del centro de datos? Si es así, la carga externa puede un día de estos hacer que se caiga la protección de sobrecarga del circuito, dejando fuera de servicio al centro de datos también.

8.1.3.2.2. Calidad de la electricidad

No es suficiente con asegurarse que la fuente de energía de su centro de datos esté bien protegida. También debe considerar la calidad de la energía que está siendo distribuida a su centro de datos. Hay muchos factores que debe considerar:

Voltaje

El voltaje de la energía entrante debe ser estable, sin reducciones de voltaje (a menudo conocidas como holguras, inclinaciones oapagones parciales) o incrementos de voltaje (conocidos como puntos y oleadas).

Forma de las ondas

La forma de la onda debe ser una onda limpia del seno, con un mínimo THD (Total Harmonic Distortion).

Frecuencia

La frecuencia debe ser estable (la mayoría de los países utilizan una frecuencia de energía de 50Hz o 60Hz).

Ruido

La energía no debe incluir ningún ruido de RFI (Interferencia de Frecuencia de Radio) o EMI (Interferencia electro-magnética).

Corriente

La energía se debe suministrar a una tasa suficiente como para correr el centro de datos.

La energía suministrada desde la compañía eléctrica normalmente no satisface los estándares necesarios para un centro de datos. Por lo tanto, usualmente se requiere un nivel de condicionamiento de la energía. Hay varios enfoques para hacer esto posible:

Protectores de corriente

Los protectores de corriente hacen exáctamente lo que su nombre indica — filtran el oleaje de la fuente de poder. La mayoría no hacen nada más que esto, dejando los equipos vulnerables a otros problemas relacionados con la energía.

Acondicionadores de energía

Los acondicionadores de energía tratan de lograr un enfoque más completo; dependiendo de lo sofisticado que sea la unidad, los acondicionadores de energía a menudo cubren la mayoría de los problemas descritos arriba.

Conjuntos de Moto-generadores

Un moto-generador esencialmente es un motor eléctrico grande activado por su suministro normal de poder. El motor está conectado a una rueda voladora, la cual a su vez está conectada a un generador. El motor mueve la rueda y el generador, lo cual produce la electricidad en suficientes cantidades para correr el centro de datos. De esta forma, la energía del centro de datos está separada de la electricidad externa, lo que significa que se eliminan una gran parte de los problemas relacionados con la electricidad. La rueda voladora también permite la habilidad de mantener energía durante interrupciones eléctricas cortas, pues toma varios segundos para que la rueda se detenga al punto en que ya no genere energía.

Fuentes De Alimentación Continuas

Algunos tipos de Fuentes de Alimentación Contínuas, más conocidos como UPS, incluyen la mayoría (si no es que todas) las funcionalidades de un acondicionador de energía[2].

Con las últimas dos tecnologías discutidas anteriormente, hemos comenzado con el tópico con el que la mayoría de la gente se relaciona cuando piensa sobre energía — energía de reserva. En la próxima sección, se exploran diferentes enfoques sobre el suministro de energía de reserva.

8.1.3.2.3. Energía de reserva

Un término relacionado con la energía que casi todo el mundo ha escuchado es un apagón. Un apagón es una pérdida completa de energía y puede durar una fracción de segundos o semanas.

Debido a que la extensión de los apagones puede variar muchísimo, es necesario abordar la tarea de suministrar energía usando tecnologías diferentes para apagones de diferente duración.

SugerenciaSugerencia
 

La mayoría de los apagones frecuentes duran, en promedio, no más que unos pocos segundos; los apagones más largos son mucho menos frecuentes. En consecuencia, concéntrese primero en los apagones de solamente unos pocos minutos de duración, luego piense en los métodos a utilizar para protegerse de apagones más largos.

8.1.3.2.3.1. Suministrar energía por pocos segundos

Puesto que la mayoría de las interrupciones duran sólo unos segundos, su solución de energía de reserva debe tener dos características principales:

  • Corto tiempo para cambiarse a la energía de reserva (conocido como tiempo de transferencia)

  • Un tiempo de ejecución (el tiempo que durará la energía de reserva) medido en segundos a minutos

Las soluciones de energía de reserva que satisfacen estas características son los conjuntos de moto-generadores y los UPSs. La rueda voladora en el moto-generador permite que el generador continue produciendo electricidad por el tiempo suficiente para cubrir interrupciones de un segundo o un poco más. Los moto-generadores tienden a ser bastante grandes y costosos, haciendolos una solución práctica solamente para los centros de datos de mediano a gran tamaño.

Sin embargo, otra tecnología — llamada un UPS — puede cubrir estas situaciones donde un moto-generador es demasiado costoso. También pueden manejar interrupciones más largas.

8.1.3.2.3.2. Suministrar energía por pocos minutos

Los UPSs se pueden comprar en una variedad de tamaños - lo suficientemente pequeño como para ejecutar una sola PC por cinco minutos o lo suficientemente poderoso como para ejecutar el centro de datos completo por una hora o más.

Los UPSs están formados por las partes siguientes:

  • Un switch de transferencia para intercambiarse desde la fuente primaria de poder a la fuente de energía de reserva

  • Una batería, para suministrar la energía de reserva

  • Un inversor, el cual convierte la corriente DC desde la batería a corriente AC requerida por el hardware del centro de datos

Aparte del tamaño y la capacidad de la batería de la unidad, los UPSs vienen en dos tipos básicos:

  • Los UPSs fuera de línea utilizan un inversor para generar energía solamente cuando falla el suministro principal de poder.

  • Un UPSs en línea utiliza un inversor para generar energía todo el tiempo, activando el inversor a través de su batería solamente cuando la fuente principal de energía falle.

Cada tipo tiene sus ventajas y desventajas. Un UPS fuera de línea usualmente es menos costoso, debido a que el convertidor no tiene que ser construído para operar todo el tiempo. Sin embargo, si ocurre un problema con el UPS fuera de línea esto pasará inadvertidamente (hasta que ocurra la próxima interrupción eléctrica).

Los UPSs en línea tienden a ser mejor en proporcionar energía limpia para su centro de datos; después de todo, un UPS en línea básicamente está generando energía para usted a tiempo completo.

Pero no importa qué tipo de UPS usted seleccione, debe medir el tamaño de su UPS para anticipar la carga (asegurando por tanto que el UPS tiene energía suficiente para producir electricidad al nivel de voltage y corriente requerido), y debe determinar cuánto tiempo le gustaría ejecutar su centro de datos usando la energía de la batería.

Para determinar esta información, primero debe determinar las cargas que el UPS servirá. Revise cada equipo y determine cuánta energía necesita (esto normalmente está listado en una etiqueta cerca del cable eléctrico de la unidad). Escriba el voltaje, los watts y/o amperios. Una vez que tenga estos números para todo el hardware, debe convertirlos a VA (Volt-Amps). Si tiene un número de vatiaje, puede utilizar el vatiaje listado como VA; si tiene amperios, multipliquelo por los voltios para obtener el VA. Al añadir los números de vatiaje puede llegar al número aproximado VA requerido por el UPS.

NotaNota
 

Siendo más específicos, este enfoque para calcular el VA no es correcto; sin embargo, para obtener el verdadero VA necesitaría conocer el factos de energía para cada unidad y esta información, raramente se encuentra disponible. En cualquier caso, los números de VA obtenidos usando este enfoque, reflejan los valores del peor caso, dejándole un margen de error por razones de seguridad.

Determinar el tiempo de ejecución es más que una pregunta de negocios que técnica - cpntra qué tipo de interrupciones está dispuesto a protegerse y cuánto dinero está dispuesto a gastar para hacerlo? La mayoría de los sitios selecciona tiempos de ejecución menores que una hora o dos como máximo, pues a partir de este punto la energía a partir de las baterias se vuelve bastante costosa.

8.1.3.2.3.3. Suministrar energía por las próximas horas (y más)

Una vez que llegamos al punto de interrupciones eléctricas que se miden en días, las opciones se vuelven más costosas. Las tecnologías capaces de manejar interrupciones eléctricas de largo tiempo están limitadas a generadores activados por algún tipo de motor - principalmente diesel o de turbinas.

NotaNota
 

Tenga en mente que los generadores activados a través de motores requieren de recargas regulares mientras se esten ejecutando. Debería conocer la tasa de uso de su combustible con una carga máxima y programar las entregas de combustible de acuerdo a esto.

En este punto, sus opciones son bien abiertas, asumiendo que su organización tiene los fondos suficientes. Esto también es un área en la que los expertos deberían ayudarlo a determinar la mejor solución posible para su organización. Muy pocos administradores de sistemas tienen el conocimiento especializado necesario para planear la adquisición y despliegue de estos tipos de sistemas de generación de energía.

SugerenciaSugerencia
 

Se pueden rentar generadores portables de todos los tamaños, haciendo posible tener los beneficios de un generador sin el gasto de dinero inicial para comprar uno. Sin embargo, tenga en cuenta que en desastres que afectan su vecindad en general, los generadores alquilados serán difíciles de obtener y muy costosos.

8.1.3.2.4. Planificación para interrupciones prolongadas

Mientras que un apagón de cinco minutos es solamente un poco más que una inconveniencia para el personal en una oficina a oscuras, ¿qué tal si el apagón dura una hora? ¿cinco horas, un día, una semana?

El hecho es, aún si el centro de datos está operando normalmente, en algún punto una interrupción prolongada eventualmente afectará a su organización. Considere los puntos siguientes:

  • ¿Qué pasa si no hay electricidad para mantener el control ambiental en el centro de datos?

  • ¿Qué pasa si no hay electricidad suficiente para mantener el control ambiental en todo el edificio?

  • ¿Qué pasa si no hay energía para operar las estaciones de trabajo, el sistema telefónico, las luces?

El punto aquí es que su organización debe determinar a qué punto una interrupción prolongada tendrá que simplemente ser tolerada. Si esto no es una opción, su organización debe reconsiderar su habilidad para funcionar de forma completamente independiente de un sitio con electricidad, lo que significa que se necesitaran generadores muy grandes para servir a un edificio completo.

Por supuesto, aún este nivel de planificación no puede ocurrir en un vacío. Es muy probable que lo que sea que esté causando la interrupción prolongada, también esté afectando el mundo externo a su organización, y que el mundo externo comenzará a tener un efecto en la habilidad de su organización para continuar sus operaciones, aún cuando se tenga capacidad de generar electricidad de forma ilimitada.

8.1.3.3. Calefacción, Ventilación y Aire Acondicionado

Los sistemas de Calefacción, Ventilación y Aire Acondicionado ( Heating, Ventilation, and Air Conditioning, HVAC) utilizados en los edificios de oficinas de hoy día, son increíblemente sofisticados. A menudo controlados por computadoras, el sistema HVAC es vital para proporcionar un ambiente laboral cómodo.

Los centros de datos tienen equipos adicionales de manejo de aire acondicionado, principalmente para eliminar el calor generado por los muchas computadoras y el resto del equipo asociado. Las fallas en el sistema HVAC pueden ser devastadoras para el funcionamiento continuo de su centro de datos. Dada su complejidad y la naturaleza electromagnética, las posibilidades de una falla son muchas y variadas. He aquí algunos ejemplos:

  • Las unidades de manejo de aire acondicionado (esencialmente grandes ventiladores eléctricos) pueden fallar debido a la sobrecarga eléctrica, una falla, falla de la correa/polea, etc.

  • Las unidades de enfriamiento (a menudo llamadas chillers) pueden perder su refrigerante debido a filtraciones o tomar sus compresores y/o motores.

La reparación y mantenimiento de un HVAC es un campo muy especializado - un campo que el administrador de sistemas promedio debería dejar a los expertos. En cualquier caso,

8.1.3.4. El tiempo y el mundo externo

Hay algunos tipos de tiempo que pueden causar problemas a un adminstrador de sistemas:

  • Las nevadas fuertes y el hielo puede impedir que el personal llegue hasta el centro de datos y hasta puede tapar los condensadores de aire acondicionado, provocando que se eleven las temperaturas de los centros de datos justament cuando no hay nadie que pueda acercarse al centro de datos para llevar a cabo las acciones correctivas.

  • Vientos fuertes que pueden interrumpir la energía y las comunicaciones, con vientos extremadamente fuertes dañando inclusive el edificio mismo.

Hay otros tipos de tiempo que también pueden provocar problemas, aún cuando no sean tan conocidos. Por ejemplo, las temperaturas muy altas pueden ocasionar que se sobrecarguen los sistemas de enfriamiento, generando apagones parciales o totales cuando el panel eléctrico se sobrecarga.

Aunque es muy poco lo que puede hacer sobre el tiempo, el conocer la forma en que este puede afectar las operaciones de su centro de datos, lo ayudará a mantener las cosas funcionando cuando se tenga mal tiempo.

8.1.4. Errores humanos

Se ha dicho que las computadoras son realmente perfectas. La razón detrás de esta afirmación es que si usted profundiza lo suficiente, detrás de cada error computacional encontrará el error humano que lo causó. En esta sección se exploran los tipos de errores humanos más comunes y sus impactos.

8.1.4.1. Errores humanos del usuario final

Los usuarios pueden cometer errores que podrían tener un impacto muy serio. Sin embargo, debido a que su ambiente normalmente no tiene muchos privilegios, los errores tienden a ser de naturaleza localizada. Puesto que la mayoría de los usuarios interactuan exclusivamente con una computadora por una o más aplicaciones, usualmente es dentro de las aplicaciones que ocurren la mayoría de los errores.

8.1.4.1.1. Uso inapropiado de las aplicaciones

Cuando las aplicaciones son usadas inapropiadamente, pueden ocurrir varios problemas:

  • Archivos sobreescritos inadvertidamente

  • Datos incorrectos utilizados como entrada a una aplicación

  • Archivos no claramente nombrados u organizados

  • Archivos borrados accidentalmente

La lista puede continuar, pero esto es suficiente para ilustrar la situación. Puesto que los usuarios no tienen privilegios de superusuario, los errores que cometen estan usualmente limitados a sus propios archivos. Como tal, el mejor enfoque es dividido:

  • Eduque a sus usuarios para el uso correcto de sus aplicaciones y en las técnicas correctas de administración de archivos

  • Asegurese de que se hacen copias de respaldo regulares de los archivos de sus usuarios y de que el proceso de restauración es tan organizado y rápido como sea posible

Más allá de aquí, es poco los que se puede hacer para mantener los errores de los usuarios a un mínimo.

8.1.4.2. Errores del personal de operaciones

Los operadores tienen una relación más profunda con las computadoras de una organización que los usuarios finales. Mientras que los errores de un usuario tienden a ser orientados a aplicaciones, los de los operadores tienden a llevar a cabo un rango más amplio de tareas. Aunque la naturaleza de las tareas haya sido dictada por otros, algunas de estas tareas pueden incluir el uso de utilidades a nivel del sistema, donde el potencial para daños más amplios debido a errores es mayor. Por lo tanto, los tipos de errores que un operador puede hacer se centran en la habilidad de un operador de seguir procedimientos que hayan sido desarrollados para su uso.

8.1.4.2.1. No se siguen los procedimientos

Los operadores deben tener conjuntos de procedimientos documentados y disponibles para casi cada acción que realizan[3]. Puede ser que un operador no siga los procedimientos de la forma en que estos están establecidos. Puede haber varias razones para esto:

  • El ambiente fue modificado en algún momento en el pasado y los procedimientos nunca se actualizaron. Ahora el ambiente cambia otra vez, dejando a que el operador memorice un procedimiento inválido. En este punto, aun si los procedimientos se actualizaron (lo que es poco probable, dado el hecho de que no estaban actualizados anteriormente) el operador no lo sabrá.

  • El ambiente fue modificado y no existen procedimientos. Esto es simplemente una versión más fuera de control que la situación anterior.

  • Los procedimientos existen y son correctos, pero el operador no los seguirá (o no puede).

Dependiendo de la estructura gerencial de su organización, quizás no pueda hacer mucho más que simplemente comunicar sus preocupaciones al gerente adecuado. En cualquier caso, ofrecerse para ayudar en lo que sea posible para ayudar es la mejor forma de abordar esto.

8.1.4.2.2. Errores cometidos durante los procedimientos

Aún si el operador sigue los procedimientos y aunque los procedimientos esten correctos, todavía se pueden cometer errores. Si esto ocurre, existe la posibilidad de que el operador sea descuidado (en cuyo caso se debería involucrar al supervisor del operador).

Otra explicación es que fue simplemente un error. En estos casos, los mejores operadores se daran cuenta de que algo está mal y buscaran ayuda. Siempre anime a sus operadores a que contacten a la gente adecuada si sospechan que algo anda mal. Aunque muchos operadores están muy bien preparados y son capaces de resolver muchos problemas independientemente, el hecho es que esto no es su trabajo. Y un problema que se complica más por un operador con buenas intenciones puede amenazar la carrera de la persona y su habilidad para resolver rápidamente un problema que quizás originalmente era un problema pequeño.

8.1.4.3. Errores del Administrador del Sistema

A diferencia de los operadores, los administradores de sistemas realizan una variedad de tareas usando las computadoras de la organización. También a diferencia de los operadores, las tareas que los administradores de sistemas llevan a cabo a menudo no están basadas en procedimientos documentados.

En consecuencia, los administradores de sistemas a veces crean trabajo adicional para sí mismos cuando no tienen cuidado en lo que están haciendo. Durante el curso de llevar a cabo las responsabilidades diarias, los administradores de sistemas tienen acceso más que suficiente a los sistemas computacionales (sin mencionar los privilegios de superusuario) como para afectar accidentalmente los sistemas.

Los administradores de sistemas cometen errores de configuración o durante el mantenimiento.

8.1.4.3.1. Errores de configuración

Los administradores de sistemas a menudo deben configurar varios aspectos de un sistema computacional. Esta configuración incluye:

  • Correo electrónico

  • Cuentas de usuarios

  • Red

  • Aplicaciones

La lista puede extenderse mucho más. La tarea actual de configurar varía en gran medida; algunas tareas requieren editar un archivo de texto (usando cualquiera de los cientos de sintaxis de archivos de configuración), mientras que otras tareas requieren la ejecución de alguna utilidad de configuración.

El hecho de que estas tareas son manejadas de forma diferente es simplemente un reto adicional al hecho básico de que cada tarea de configuración requiere un conocimiento diferente. Por ejemplo, el conocimiento requerido para configurar un agente de transporte de correo es fundamentalmente diferente al conocimiento requerido para configurar una conexión de red.

Dado todo esto, quizás debería ser una sorpresa que solamente se cometen unos pocos errores. En cualquier caso, la configuración es y seguirá siendo, un reto para los administradores de sistemas. ¿Hay algo que se pueda hacer para hacer el proceso menos susceptible a errores?

8.1.4.3.1.1. Control de cambios

La tendencia común de cada cambio de configuración es que ha ocurrido algún tipo de cambio. El cambio puede ser grande o puede ser pequeño. Pero aún se trata de un cambio y debería ser tratado de una forma particular.

Muchas organizaciones implementan algún tipo de proceso de control de cambios. La intención es la de ayudar a los administradores de sistemas (y a todas las partes afectadas por el cambio) a administrar el proceso de cambio y reducir la exposición de la organización a cualquier error que pueda ocurrir.

Un proceso de control de cambios normalmente desglosa el cambio en pasos diferentes. He aquí un ejemplo:

Investigación preliminar

La investigación preliminar intenta definir claramente:

  • La naturaleza del cambio que tomará lugar

  • Su impacto, si el cambio es exitoso

  • Una posición de retroceso, si el cambio falla

  • Una evaluación de qué tipos de falla son posibles

La investigación preliminar puede incluir probar el cambio propuesto durante el tiempo planificado fuera de servicio, o puede ir tan allá como para incluir la implementación del cambio primero en un ambiente de prueba especial, ejecutándose en un hardware dedicado para las evaluaciones.

Planificación

Se examina el cambio con un ojo hacia las mecánicas actuales de la implementación. La planificación se hace incluyendo una descripción de la secuencia y tiempo del cambio (junto con la secuencia y tiempo de cualquier paso necesario para cancelar el cambio en caso de que ocurra un problema), así como también asegurarse de que el tiempo asignado para los cambios es suficiente y no entra en conflicto con ninguna otra actividad a nivel de sistemas.

El producto de este proceso a menudo es una lista de verificación de pasos para que la use el administrador del sistemas mientras está llevando a cabo el cambio. Junto con cada paso están las instrucciones a realizar para cancelar el cambio y volver al estado anterior, en caso de que falle el paso. A menudo se incluyen los tiempos estimados, haciendo fácil para que el administrador del sistema determine si el trabajo está dentro de la planificación o no.

Ejecución

En este punto, la ejecución real de los pasos necesarios para implementar el cambio debería ser directa y anti-culminante. El cambio es implementado o (si ocurren errores) se cancela.

Supervisión

Bien sea que se implemente el cambio o no, se monitoriza el ambiente para asegurarse de que todo está funcionando como debería.

Documentación

Si se implementa el cambio, toda la documentación existente se actualiza para reflejar la configuración modificada.

Obviamente, no todos los cambios de configuración requieren este nivel de detalles. La creación de una cuenta de usuarios no requiere ninguna investigación preliminar y la planificación probablemente consistirá de determinar si el administrador tiene tiempo libre para crear una cuenta. La ejecución sera igualmente rápida; la monitorización consiste de asegurarse de que la cuenta es utilizable y la documentación probablemente consistirá en enviar un correo electrónico al supervisor del usuario.

Pero a medida que la configuración se vuelve más compleja, se hace necesario un proceso de control de cambios más formal.

8.1.4.3.2. Errores cometidos durante el mantenimiento

Este tipo de errores pueden ser insidiosos porque se hace muy poca planificación o seguimiento durante el mantenimiento de día a día.

Los administradores de sistemas ven el resultado de estos errores diariamente, especialmente de los usuarios que juran que no cambiaron nada - simplemente la computadora se echó a perder. El usuario que afirma esto usualmente no se recuerda qué fue lo que hizo y cuando le pase lo mismo a usted, probablemente usted tampoco recuerde lo que hizo.

La cuestión clave a tener en mente es que usted debe ser capaz de recordar los cambios que realizó durante un mantenimiento si quiere ser capaz de resolver los problemas rápidamente. Un verdadero proceso del control del cambio no es realístico para los cientos de cosas que se hacen durante un día. ¿Qué se puede hacer para seguir las 101 cosas que un administrador de sistemas realiza diariamente?

La respuesta es simple - tome notas. Bien sea que esté hecho en un cuaderno, un PDA o como comentarios en los archivos comentados, tome notas. Al hacer un seguimiento de lo que hace, tiene más oportunidades de notar una falla como relacionada a un cambio que realizó recientemente.

8.1.4.4. Errores de Servicio Técnico

Algunas veces la propia gente que se supone debería ayudarlo a mantener sus sistemas funcionando confiablemente, son los que complican más las cosas. Esto no se debe a ninguna conspiración; es simplemente por el hecho de que cualquiera que esté trabajando en una tecnología por alguna razón, arriesga el hacer esa tecnología inoperable. El mismo efecto es en el trabajo cuando los programadores reparan un fallo pero terminan creando otro.

8.1.4.4.1. Hardware reparado incorrectamente

En este caso, el técnico falló en diagnosticar el problema correctamente y realizó una reparación innecesaria (e inútil), o el diagnóstico fue correcto, pero la reparación realizada no se llevó a cabo bien. Puede ser que la parte misma reemplazada estaba defectuosa, o que no se siguió el procedimiento adecuado cuando se realizó la reparación.

Por eso es importante estar al tanto de lo que está haciendo el técnico en todo momento. Haciendo esto, puede mantener un ojo sobre las fallas que puedan parecer estar relacionadas al problema original de alguna forma. Esto mantiene al técnico en carril por si hay un problema; de lo contrario hay oportunidad de que el técnico pueda ver esa falla como nueva y no relacionada con la supuestamente reparada. De esta forma, no se pierde tiempo buscando por el problema incorrecto.

8.1.4.4.2. Reparar una cosa y dañar otra

Algunas veces, aún cuando se diagnosticó y reparó el problema exitósamente, surge otro problema en su lugar. Se reemplazó el módulo del CPU, pero la bolsa antiestática en la cual vino, se dejó en el gabinete bloqueando el ventilador y causando un apagado por sobre-calentamiento. O se reemplazó el disco duro que estaba fallando en la formación RAID, pero puesto que se golpeó accidentalmente un conector en otra unidad y se desconectó, la formación RAID continua fuera de servicio.

Estas cosas pueden ser el resultado de descuidos crónicos o de un error honesto. No importa. Lo que siempre debe hacer es revisar cuidadosamente las reparaciones realizadas por un técnico y asegurarse de que el sistema está funcionando correctamente antes de dejar que el técnico se retire.

Notas

[1]

Y esto probablemente se considere el mejor caso posible, pues usualmente los técnicos son responsables por territorios que se extienden fuera de la oficina en todas las direcciones. Si usted está en un extremo del territorio y el único técnico disponible está en el otro extremo, el tiempo de respuesta será aún mayor.

[2]

La tecnología de UPS se discute en más detalles en la Sección 8.1.3.2.3.2.

[3]

Si los operadores en su organización no tienen procedimientos de operación, trabaje en con ellos, la gerencia y sus usuarios para crearlos. Sin procedimientos, un centro de datos está fuera de control y vulnerable a sufrir problemas graves en el curso de las operaciones diarias.