viernes, 22 de noviembre de 2024

Ante un failover hace falta un plan de contingencia

spot_img

La creación de protocolos de conmutación por error, o de failover, es esencial para garantizar la capacidad de entrega de las comunicaciones en todo momento.

Es importante comprender mejor cómo funciona esto y cómo desarrollar una eficaz estrategia para una empresa.

 Por Mariano Martinez Viademonte (*)

 Recientemente Facebook y sus diversas aplicaciones asociadas estuvieron inactivas durante aproximadamente 7 horas. Como resultado, más de 3.5 mil millones de usuarios se vieron en problemas para comunicarse con sus amigos y familiares y lo que es peor, para administrar sus negocios.

Si bien una caída masiva que de tales proporciones es poco común, lo sucedido nos hace reflexionar acerca de la importancia de crear estrategias de failover o de contingencia para así estar preparados ante cualquier eventualidad como esta. Después de todo, no porque un canal comunicativo esté caído, todos los mensajes y transacciones deben verse perjudicados. Tener un plan B nunca está de más.

¿Qué es un failover comunicativo?

 ¿Cuál es el significado de esta palabreja? La conmutación por error o failover es un modo operativo de respaldo en el que un componente secundario asume las funciones de un componente del sistema cuando el componente principal deja de estar disponible, ya sea por falla o por tiempo de inactividad programado.

Los llamados failovers son utilizados cuando un canal de comunicación no es capaz de entregar un mensaje y, por lo mismo, es reemplazado por otro. En otras palabras, se trata de canales de “respaldo” o de contingencia.

He aquí un ejemplo: un usuario necesita recibir un mensaje a través de WhatsApp para confirmar la entrega de un pedido. Sin embargo, se encuentra en un lugar sin servicio de Internet y, por lo tanto, no puede recibir dicha comunicación. En estos casos, es posible configurar que cuando este canal primario (WhatsApp) no esté disponible, el contenido del mensaje sea enviado al cliente a través de SMS.

En resumen, un failover comunicativo no es otra cosa que una forma de garantizar canales alternativos para que los mensajes que deseas enviar a tus usuarios, en efecto, les lleguen, incluso si el canal original para ese envío no está disponible en el momento.

En Infobip, utilizamos el failover de mensajes en la plataforma Moments o mediante API. En este orden de ideas, los canales alternativos o de contingencia pueden ser configurados dentro del proceso de creación de mensajes y son compatibles con otros canales de comunicación.

¿Qué se debe tener en cuenta al crear una estrategia de failover?

Antes de crear cualquier tipo de estrategia de contingencia, es importante enfatizar lo siguiente:

Reforzar los mensajes a través de diferentes canales, a la misma vez, no es una estrategia de failover.

Por el contrario, se trata de la capacidad de garantizar la entrega de información importante a un usuario, incluso ante la caída o inactividad de un canal. Hay que recordar que esto no es lo mismo que hacer spam a través de varios canales a la vez.

  1. ¿Qué mensajes son considerados como cruciales y precisan de una estrategia de failover?

Los mensajes que deberían ser considerados para crear estrategias de contingencia son aquellos que, por su misma naturaleza, son extremadamente importantes y posiblemente tengan algunas limitaciones de tiempo. Lo anterior aplica cuando, por ejemplo, un usuario ha solicitado la autenticación de dos factores pero no puede recibir un SMS para verificar su identidad. También aplica cuando un canal tan relevante como WhatsApp se halla inactivo para enviar la confirmación de una entrega o la respuesta a una consulta urgente.

Este tipo de mensajes, los que se consideran cruciales para la experiencia del cliente, son los primeros que debes tener en cuenta para la creación de protocolos de failover.

 Optar por el canal correcto

Para esto, tener en cuenta los siguientes factores:

  • ¿Qué canal alternativo tiene el mismo hábito de mercado que su canal original?: por ejemplo, Viber y WhatsApp poseen usabilidades parecidas. Por su parte, la gran mayoría de las personas en LATAM cuentan con acceso a WhatsApp y SMS.
  • ¿Las infraestructuras de los canales alternativos son similares a las del original?: aquí es importante tener en cuenta si ambos precisan de internet o si pertenecen a un mismo proveedor, como es el caso de Instagram y WhatsApp. En caso de que ambos canales pertenezcan a una misma compañía, será mejor que uno no sea el plan de contingencia del otro.
  • ¿Cuál es el nivel de seguridad del canal alternativo?: dependiendo de qué tan sensible o confidencial sea el mensaje o la información a enviar, es posible que no sea muy seguro enviar su contenido a través de correo electrónico. Lo anterior aplica, por ejemplo, para procesos de autenticaciones de identidad, entre otros.

Por cuestiones de presupuesto, SMS es el canal de contingencia más utilizado para estos escenarios. Sin embargo, no hay que perder de vista que este canal podría llegar a restringir el mensaje que se desea enviar, ya que no es compatible con medios como RCS Messaging y WhatsApp.

  1. Adapta los mensajes

Los diferentes canales tienen diferentes formas de comunicarse. Por lo tanto, cuando configures un mensaje de contingencia, asegúrate de adaptarlo al nuevo formato.

Por ejemplo: si se está enviando un RCS que tiene información de precio dentro de la imagen, en caso de transferir el mensaje mediante SMS es importante que esta información esté contenida en el texto del nuevo mensaje.

  1. Establecer un tiempo máximo para intentar el reestablecimiento de un canal

Antes de establecer que un mensaje no puede ser enviado a través de un canal en particular, este ingresa a una línea de espera para intentar la reactivación o el reenvío del mismo. Solo después de eso, se activa el protocolo de failover.

Sin embargo, es importante entender que algunos mensajes no dan espera, dependiendo de su mismo contenido.

En estos casos, deberá establecerse un tiempo máximo menor para así activar el protocolo cuanto antes. Esto es muy común, por ejemplo, en casos de autenticación de dos factores ya que generalmente tienen un determinado período de activación de aproximadamente 60 segundos. En otros casos, como la notificación de cambios de contrato, es posible esperar una reactivación durante 24 o 48 horas antes de activar este protocolo.

(*) Regional Manager South Latam en Infobip

 

 

 

 

Compartir:

spot_img
spot_img
spot_img
spot_img
spot_img
spot_img

Noticias

CONTENIDO RELACIONADO