Como proveedor de
hospedaje (o cualquier persona que administra un servidor compartido)
probablemente tenga por lo menos dos razones para decidirse a
utilizar un programa de monitoreo de servidores. Todo el tiempo
su servidor esta abajo, suena su teléfono y su bandeja
de entrada se llena con correo de clientes insatisfechos. El
servicio de monitoreo de red puede alertarle cuando su
servidor no se encuentra disponible; usted lo sabrá antes
que sus clientes. Ha trabajado mucho construyendo su negocio.
Invertido en hardware, incontables horas configurando y probando,
y más todavía asegurándose de que las cosas
trabajen sin incidentes. Con las herramientas de monitoreo de
servidores puede obtener un fantástico tiempo
de actividad y hacerse de una valiosa reputación.
El monitoreo de servidor tiene dos objetivos: Mantener informado
cuando ocurra algún error. Publicar el mayor porcentaje
de tiempo de actividad posible. Aquí te mostramos algunos
consejos de cómo utilizar de la mejor manera el servicio
de monitoreo de red para conseguirlos. Esta lista
de cómo se hace y cómo no, compila 5 años
de historia de responder a solicitudes de soporte.
No monitorear otro dominio
del servidor.
Esta es probablemente la principal causa de cortes innecesarios
entre las compañías que monitorean el hospedaje
web. Si proporciona un nombre de dominio completamente calificado
(FQDN) en la configuración del dispositivo, entonces un
mal comportamiento de un DNS hará que su sitio aparezca
marcado como caído. Esto puede ser lo que usted desea
si está proporcionando los servicios de DNS a sus clientes,
pero si no es así, lo que realmente estamos haciendo es
el monitoreo de otro dominio en el servidor. Si se cae su dominio
del servidor, el tiempo de inactividad le generará cargos.
Fondo: A menos que tenga su propio servidor de nombres de
dominio (DNS), no utilice FQDNs en la configuración
del dispositivo.
No ignore las alertas.
Recibimos correos todo el tiempo de los clientes que quieren
saber por qué después de varias horas o incluso
días, seguimos reportando que su dispositivo está abajo.
Tan pronto como se genera una notificación de alerta,
el reloj ha comenzado a marcar su tiempo de inactividad. Hasta
que se determine que el sitio se restauró, se le
acumulará el tiempo de inactividad lo cual afectara sus
estadísticas de los próximos meses. A menos que
el corte sea causado por un error en el software,
no
podemos eliminarlos. Yo uso el cronómetro en mi teléfono
celular. Tan pronto como recibo la alerta inicia el cronómetro;
no puedo ver mi teléfono sin ver como transcurre el tiempo.
Como mi equipo y yo estamos trabajando en el problema, incluso
sobre las conferencias telefónicas me informa la lectura
actual en el cronómetro.
Fondo: cada hora de tiempo de inactividad es otro 0.1% mas
de tiempo de inactividad. No ignore las alertas de dispositivo
caído.
Utilizar la característica “Check
All”.
Una vez haya reparado el servidor y este nuevamente en línea,
su siguiente tarea debe consistir en asegurarse que el sistema
sabe que esta en línea. Hasta que el sistema revise el
dispositivo, el tiempo de inactividad sigue aumentando. Si ya
ha recibido la alerta de “Device OK” para el dispositivo
entonces todo esta bien. De lo contrario, debe acceder a su cuenta
y usar la función “Check All”.
El “Check
All” se encuentra en la parte inferior de la lista de dispositivos
de la parte derecha de la página. Al hacer click, todos
los dispositivos serán inmediatamente programados para
ser comprobados de nuevo. Si el dispositivo realmente se restauró,
pronto será informado que esta arriba nuevamente después
de la comprobación. Si se informa que no esta arriba,
entonces sabrá, unos días después cuando
un cliente muestre un tiempo de actividad del 98% durante el
mes.
Fondo: después de un corte, utilice la función “Check
All” para probar su servidor y asegurarse de que se ha
solucionado el problema.
Realizar cambios de DNS cuidadosamente.
Si desea hacer un seguimiento de su servidor de nombres de dominio,
entonces usted querrá utilizar nombres de dominio completamente
calificados (FQDNs) al configurar sus dispositivos.
Sin embargo si está utilizando FQDNs, deberá tener
cuidado al hacer cambios en los nombres de dominio. La cuestión
es el TTLs (time-to-live) de las entradas de DNS. Al dar de alta
una entrada DNS también se le da un TTL. Esto permite
que los navegadores web y otros servicios de Internet guarden
en cache la entrada del nombre del dominio y la dirección
IP evitando pedir esta información nuevamente. Esto acelera
drásticamente la experiencia del usuario, mientras recorta
la carga en los servidores de dominios.
El problema viene cuando va a cambiar la entrada DNS de un nombre
para apuntar a una nueva dirección IP. Si no se hace correctamente,
esto puede generar el temido “rolling outage”, donde
alternativamente se le informa que su sitio esta abajo y unos
minutos después que se ha restaurado nuevamente.
Este ciclo puede durar máximo una hora (los servidores
tienen un TTL máximo de 60 minutos). Con nuestra
red de estaciones de monitoreo dispersa, puede tomar algún
tiempo el propagar los cambios de su DNS en ellas, teniendo que
esperar a que el TTLs pare, así, termine el tiempo.
Esto no es realmente diferente a lo que sus clientes experimentan,
ellos también tendrán problemas para acceder a su
sitio después de cambiar y actualizar las entradas de sus
servidores de DNS; los navegadores solo esperarán que termine
el TTL.
Fondo: Realice cuidadosamente los cambios de DNS para no
provocar cortes. Actualice el TTL a 60 segundos o menos sin
cambiar el resto de la entrada. Después espere hasta que el TTL anterior
expire. Si su TTL es de 24 horas, tendrá que esperar 24
horas antes de realizar el último cambio. Por, último
al hacer cambios de su DNS y establecer el TTL a como estaba
antes.
No monitorear su página
de Internet o de sus clientes en un servidor compartido.
Si quiere publicar estadísticas del tiempo de actividad
de un servidor compartido, definitivamente necesita monitorear
el servicio HTTP en el servidor. Para hospedaje web compartido,
el servicio de monitoreo web ya sea utilizando HTTP/S o HTTPb es el mejor camino para dar legitimidad al monitoreo. Puede utilizar
un PING para estar seguro que el servidor esta arriba, pero realmente
no le dirá a sus clientes lo bien que su servidor Apache
o IIS sirven sus páginas.
Dicho esto, si utiliza un chequeo HTTP/S o HTTPb, no monitorea
su página de Internet (si esta en el mismo servidor) o alguna
de las páginas de internet de sus clientes. ¿Por
qué? Debido a que un día tendrá su página
de internet abajo por mantenimiento, o su cliente y de repente
tendrá un corte en su impecable porcentaje de uptime. Si
desea proporcionar monitoreo a las páginas de Internet de
sus clientes, puede hacerlo utilizando dispositivos independientes;
el dispositivo que utiliza para anunciar su uptime no debe ser
su página de Internet o la página de Internet de
algún cliente.
Fondo: Es una buena idea utilizar el monitoreo de HTTP/s
o HTTPb en su servidor compartido; las estadísticas del uptime
de los usuarios dan mayor crédito porque están
monitoreando su servidor web en acción. Sin embargo cree
una página de prueba de monitoreo, no monitoree su propia
página de Internet o de sus clientes.
Instalar contactos múltiples
y un horario de escalada.
Siempre que tiene una caída, el cronómetro esta
marcando su tiempo de inactividad. Cada minuto de tiempo de inactividad
afecta el porcentaje del tiempo de actividad. Por otra parte,
más importante, sus clientes no tienen acceso a ninguna
de sus páginas de Internet. Disponemos de una amplia
variedad de métodos de contacto y un sofisticado mecanismo
de escalada. Debe crear una variedad de métodos de contacto
y utilizar el horario de escalada cada vez que las caídas
sean más persistentes y largas.
¿Has escuchado el dicho, "cuando llueve, se derrama?" Es
sorprendente la cantidad de caídas del servidor, no solo
he experimentado la caída del servidor, pero por alguna
razón mi teléfono móvil estaba teniendo problemas
de envío de mensajes SMS. Una vez tuve un día entero
del valor de todos los mensajes a la vez. La betería de
mi teléfono parece que muere justo antes de un gran corte.
Cuando configure el contacto de notificación, configure
más de una manera de mantener contacto con el personal de
soporte. Lo ideal sería utilizar 2 o más contactos
SMS de múltiples compañías y por lo menos
un contacto telefónico. Después debe configurar su
programa de notificación a fin de que los SMS y de telefonía
mantengan el contacto para estar informado siempre tanto como dure
el corte. Puede hacerlo utilizando el "Repetir notificación
de caída del dispositivo cada X minutos" verificando
la casilla en la página de Programación de notificación.
Fondo: Configuración de múltiples métodos
de contacto cuando ocurre un corte. Utilice múltiples
compañías de SMS y telefonía si es posible
(por ejemplo, usted usa Cingular y otra persona en su lista de
contactos usa T-Mobile). Establecer el " Repetir notificación
de caída del dispositivo cada X minutos " verificando
la casilla.
Resumen
Somos un excelente recurso para hacer felices a sus clientes
actuales y atraer nuevos clientes. Nuestra red de servicios de
monitoreo proporciona los medios para ser notificado cuando se
produce un corte. Podrá solucionar el problema más
rápido ya que sabrá acerca de este más
rápido. Esto mantendrá a sus clientes contentos.
Proporcionamos también los medios para publicar el
tiempo de actividad en el resto del mundo, lo que le permite
diferenciar la calidad del servicio que proporciona con respecto
a sus competidores. El uso de las estrategias en este documento,
puede maximizar su tiempo de actividad mientras reduce o elimina
los “falsos positivos” que afectan su porcentaje
de tiempo de actividad.
|
