Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
Linuxtopia - CentOS Enterprise Linux 4: Introduccion a la administracion de sistemas - Planificaci�n para Desastres

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:

  • Fallas del hardware

  • Fallas del software

  • Fallas ambientales

  • Errores humanos

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.

 
 
  Published under the terms of the GNU General Public License Design by Interspire