Siete maneras de asegurarse de que su sala de espera funciona a la primera
Cuando instale CrowdHandler y configure una sala de espera, queremos que lo haga bien a la primera.
Nos complace decir que hemos visto a mucha gente instalar CrowdHandler directamente en prod, en medio de una emergencia de carga, para ver cómo salvaba el día.
Pero, con la mejor voluntad del mundo... los errores ocurren. Así que aquí va un aviso. Siete trampas en las que hemos visto caer a nuestros clientes, con consejos para evitarlas y garantizar una instalación sin problemas.
¿Crees que te has preparado...?
Digamos que va a lanzar un nuevo producto, servicio o venta.
Usted sabe que es probable que su sitio tenga problemas de demanda o de carga. Tal vez prevea una demanda elevada porque tiene un producto extremadamente limitado, o un problema de carga elevada porque sabe que un número sin precedentes de visitantes llegará a su sitio al mismo tiempo.
Así que sabes que vas a necesitar una sala de espera. De hecho, estás construyendo la sala de espera desde el principio. Va a formar parte de la experiencia del usuario. Sabes exactamente cómo va a funcionar y cómo se incorporará la cola a la solución que estás construyendo. Estará totalmente probada. Es imposible que salga mal.
...¿Existe?
Para asegurarnos, repasemos los problemas más comunes de la integración personalizada de CrowdHandler y cómo evitarlos.
1. Pruebas funcionales limitadas
A menudo vemos que los clientes prueban su integración personalizada cuidadosamente elaborada con un pequeño grupo de interesados internos: cinco o diez personas que realizarán algunos recorridos de usuario estándar y comprobarán que los usuarios se ponen en cola y son redirigidos al sitio correctamente.
Sin embargo, este tipo de pruebas no da una idea realista de cómo funciona el sitio con una cola activa. Después de todo, una vez que esos pocos usuarios han pasado por el proceso de la sala de espera y se les ha permitido entrar en el sitio, ya no hay cola. Pero muchos de los problemas de integración sólo tienden a revelarse cuando se activa la cola en un sitio muy concurrido.
Cuando realice pruebas, debe comprobar realmente que los usuarios conservan su estado promocionado (normalmente indicado por una cookie CrowdHandler) en el sitio de destino. En lugar de limitarse a que sus usuarios de prueba se filtren de la sala de espera al sitio, debe comprobar si la sesión de CrowdHandler se mantiene.
Así que, como mínimo, deberías
Establecer la tasa a 0, lo que hará que la cola para poner en marcha
Aumentar la tarifa temporalmente para permitir el paso de algunos usuarios
Vuelva a poner la tasa a 0 (creando de nuevo una cola activa)
A continuación, compruebe que los usuarios que han sido promocionados al sitio pueden seguir completando recorridos de usuario funcionales.
Establecer la tasa de nuevo a 0 después de permitir que algunos usuarios pasen es vital porque, en este punto, si la sesión de CrowdHandler de un usuario se rompe, serán enviados de vuelta a la cola. Sin embargo, si mantienes la tasa alta, esos usuarios no serán enviados a la cola, y no sabrás que tu integración tiene un problema.
2. Prod no refleja Dev
Claro, a todo el mundo le encantaría decir que sus entornos de ensayo y desarrollo son un fiel reflejo del directo... pero, según nuestra experiencia, rara vez es así.
Uno de los problemas más comunes que hemos visto es que un cliente se pasa días, o semanas, haciendo pruebas en su entorno de desarrollo o de ensayo, y luego aplica la misma configuración al sitio de producción una hora antes de ponerlo en marcha y espera que funcione de forma idéntica. Cuando se dan cuenta de que no es así, ya es demasiado tarde.
Esto sucede porque las cosas que tienden a ser diferentes entre el sitio en vivo y el de desarrollo son exactamente los tipos de cosas que llamarían la atención en una sala de espera. Muchas de las protecciones que la gente tiene que tener en su sitio de producción -por ejemplo, tener el sitio detrás de una CDN, ejecutar un cortafuegos o protección contra bots- no suelen ser necesarias en la puesta en escena, por lo que parte de su enrutamiento de red o configuración podría ser diferente.
Así que asegúrese de buscar diferencias en:
Enrutamiento de red (especialmente aplicable en implementaciones CDN, DNS)
Infraestructura de protección de bots o cortafuegos o configuraciones que no coinciden con las reales
Para asegurarte de que no te encuentras con ningún problema grave en una fase tardía, te recomendamos que pongas la producción en marcha al menos 24 horas antes de que sea necesario. Una vez que haya completado las pruebas funcionales en un entorno de desarrollo o de fase, extiéndalas a un área de producción que no vaya a suponer un problema para usted (un patrón específico de URL protegida que probablemente no moleste a los usuarios reales) y realice algunas pruebas a pequeña escala en el entorno de producción. Incluso podrías hacer una pequeña prueba de producción en mitad de la noche.
Simplemente... no lo dejes para el último momento.
3. Bloqueo de IP
Las integraciones personalizadas envían la IP del usuario a la API de CrowdHandler, para que podamos comprobar que no está en una lista prohibida. Sin embargo, no es raro que los sitios se configuren de tal manera que accidentalmente nos envíen la IP de algún servidor proxy en lugar de la IP del usuario... y esto activa erróneamente el bloqueo de IP de CrowdHandler.
Esto sólo tiende a ser un problema si usted está enrollando a mano su integración (si está utilizando una de nuestras integraciones, nos hemos encargado de todo eso), pero es bastante fácil equivocarse, así que tenga cuidado.
Más información: Resolución de problemas de integraciones de API personalizadas
4. Ajustar la tasa demasiado alta
La mayoría de la gente cree que su sitio puede soportar mucho más tráfico del que puede. Por eso, según nuestra experiencia, los clientes suelen fijar una tasa de entrada demasiado alta.
Si es la primera vez que se pone en marcha, no sabe cuánto tráfico puede esperar y, sinceramente, aún no sabe cuánto tráfico puede gestionar. No se deje engañar por la capacidad de su sitio para gestionar miles de solicitudes por segundo; esto no se traducirá en el número de seres humanos reales que puede canalizar desde su cola.
Los sitios que pueden manejar fácilmente más de 60 usuarios por minuto (es decir, una nueva sesión por segundo) son bastante raros, por lo que probablemente debería comenzar con 30 o menos, a menos que realmente conozca el perfil de carga de su sitio.
En resumen: es mejor empezar por lo bajo. Luego, si te sorprendes gratamente, es fácil aumentar la tasa. Recuperar una aplicación muerta puede ser más complicado.
Véase también: ¿Por qué no funcionan las pruebas de carga?
5. Exclusiones de URL
Si está utilizando la integración DNS, la integración CDN, o su propia integración del lado del servidor con un controlador frontal, estará comprobando cada URL para enviar usuarios a la cola.
Sin embargo, es probable que ciertas URLs sean llamadas por aplicaciones de terceros que no deben ser enviadas a una cola - por lo tanto, estas URLs deben ser excluidas.
Un ejemplo obvio de esto es una pasarela de pago. Un usuario completa una transacción con, digamos, PayPal o Stripe, y la pasarela de pago envía de vuelta un recibo de confirmación de pedido, golpeando una URL en su servidor. Si no ha excluido esa URL, la integración CrowdHandler (que comprueba cada URL, recuerde) interviene y dice que la pasarela de pago necesita estar en cola. El pedido nunca se completará y el usuario no podrá realizar el pago.
Esta es otra razón para realizar pruebas funcionales completas, con bastante antelación. Ponga su tasa a 0, para asegurarse de que la cola está activa, y pruebe recorridos de usuario completos, que incluyan aquellas aplicaciones de terceros que puedan depender de su dominio protegido.
Más información: Resolución de problemas de integraciones de API personalizadas
6. Simplificación excesiva de la plantilla
Una de las principales razones por las que a la gente le gusta usar CrowdHandler son las plantillas personalizadas, y hemos visto a gente hacer cosas realmente creativas y emocionantes con la libertad que ofrecen las plantillas.
La plantilla por defecto, o "inicial", incluye diferentes mensajes y estados para varios escenarios, algunos de los cuales son más obvios que otros. Por ejemplo, la sala aún no está abierta, la sala está llena, el usuario está bloqueado por comportamiento sospechoso y el usuario aún no tiene asignada una posición en la cola.
Sin embargo, cuando se personaliza la plantilla, es habitual que sólo se tenga en cuenta el "camino feliz" y se ignoren -o, peor aún, se eliminen por completo- algunos de los mensajes de error y estados menos obvios. Entonces, cuando un usuario se encuentra con una de estas condiciones, se encuentra con una interfaz de usuario poco útil.
Es importante entender que los usuarios necesitan ver feedback, incluso si ese feedback les dice algo que no te parece positivo, como su posición actual, la barra de progreso o el tiempo de espera estimado. Según nuestra experiencia, ocultar estos elementos es contraproducente. Sin ellos, los usuarios empezarán a comportarse de forma impredecible o a reaccionar mal ante la falta de información. Puede perder ventas o incluso dañar su reputación.
7. Establecer tiempos de espera de sesión extremos
Todas las aplicaciones web utilizan el concepto de tiempo de espera de sesión, y CrowdHandler no es diferente.
CrowdHandler tiene por defecto 15 minutos, que es una duración de sesión relativamente estándar para una aplicación web. Todo esto significa que, una vez que un usuario ha hecho clic en algo, entonces, durante los próximos 15 minutos, CrowdHandler supondrá que todavía están allí.
El usuario mantiene viva su sesión haciendo clic en las páginas, pero un tiempo de espera de 15 minutos significa que podría ausentarse 15 minutos para prepararse un café y volver sin encontrarse de nuevo en la cola. Cuando vuelve a hacer clic, se reactiva la sesión, por lo que aún tiene tiempo de sobra para navegar.
Conviene recordar que el número de sesiones no es más que un indicador muy simplificado de la carga que soporta la aplicación. Cuando la gente está fuera haciendo café, no está cargando tu aplicación.
Sin embargo, nos encontramos con que algunos clientes fijan la duración de la sesión demasiado baja o demasiado alta.
En cualquier caso, es contraproducente. Demasiado bajo y podrías acabar enviando a la gente de vuelta a la cola en mitad de su visita. Demasiado alto, y podrías encontrarte gestionando una cola muy larga, porque las sesiones de los usuarios permanecen activas durante mucho tiempo después de que se hayan ido.
Más información: Uno dentro, uno fuera
¿Preparado para hacerlo bien a la primera?
¿Prevé una gran carga o una demanda elevada y está listo para instalar una sala de espera?