Cómo el comercio electrónico sobrevive a las promociones a gran escala. Preparándose para las cargas máximas en la web [Parte 2]

Hola Habr!
Hace una semana había un artículo en el que comencé una conversación sobre cómo preparar un proyecto de comercio electrónico para el crecimiento explosivo del tráfico y otras delicias de promociones a gran escala.
Descubrimos los detalles técnicos clave, ahora prestaremos atención a los problemas administrativos y optimizaremos los procesos de soporte durante las cargas pico:

• qué hace que el sitio sea inestable y por qué la nube no es una panacea;
  
• qué parámetros comerciales necesitan ser monitoreados para detectar un problema antes de que traiga pérdidas significativas;
  
• cómo enrutar el incidente del evento a la solución sin caos y localizar la falla.
  

Y mucho más: ¡les pido a todos que corten!

En mi experiencia, el mayor dolor de cabeza en la preparación para acciones a gran escala es una fuerte presión administrativa. El negocio, que hasta entonces estaba muy tranquilo, de repente tiene el deseo de que todos estén en la corriente, eliminen el polvo del sitio, y así sucesivamente: "Dios no permita lo que suceda, seremos multados. Tratemos de satisfacer este deseo generalmente sano. Hablaremos de esto en el ejemplo del Black Friday, ya que este es el ejemplo más llamativo de un fuerte aumento de la carga en el sitio.
Y comenzaremos con la pregunta fundamental: ¿cuál es exactamente la causa del funcionamiento inestable de nuestro sitio?

Lo que hace que un sitio sea inestable

Ha llegado el momento de hacer lo que has estado posponiendo durante mucho tiempo. Para comprender qué factores hacen que un sitio sea menos estable, plantee y analice el historial de problemas. Simplemente no digas que no lo tienes.

Su parte superior tendrá más o menos las siguientes razones:

1. Liberar bloqueos relacionados.
   
2. Administradores en mal estado: arreglaron uno, pero otro rompió. Desafortunadamente, tales superposiciones a menudo están ocultas y no hacen historia.
   
3. Echó a perder el negocio: lanzó torcidamente la acción, eliminó algo, etc.
   
4. Servicios de afiliados rotos.
   
5. Software "triste". Muy a menudo esto sucede debido a los párrafos. 1 y 2.
   
6. Daño fisico.
   
7. Otros problemas
   

Por supuesto, todas las situaciones son diferentes, y su "calificación" puede resultar ligeramente diferente. Pero los problemas asociados con los cambios en el sitio y el factor humano, así como los frutos de su amor conjunto (liberaciones o intentos de optimizar algo) aún conducirán.

Erradicar estos problemas para que en el primer intento de hacer los cambios necesarios y no romper lo que funciona bien, es una tarea sobre la que se han roto muchas copias. Y tenemos muy poco tiempo, solo unos cuatro meses. Afortunadamente, esto se puede manejar localmente. Para hacer esto, siga un par de reglas simples:

1. Funciona - no tocar.

Complete todo el trabajo planificado lo antes posible, en un par de semanas, en un mes. Qué tan temprano para abordar las mejoras contará su historial de incidentes. Muestra cuánto dura la cola principal de los problemas. Después de eso, no toque el sitio y la infraestructura del producto hasta que la carga haya pasado.

2. Si aún tenía que entrar en la producción para reparaciones urgentes, realice una prueba.

Regularmente, incansablemente, incluso los cambios más pequeños y menores. Primero, en un entorno de prueba, incluso bajo carga, y solo luego transfiéralo al producto. Y nuevamente, pruebe y vuelva a verificar los parámetros clave del sitio. Es mejor realizar el trabajo por la noche, cuando la carga es mínima, porque debería tener tiempo para salvar la situación si algo sale mal. Una buena prueba es una ciencia, pero incluso una prueba inteligente es mejor que no tenerla. Lo principal es no confiar en "tal vez".

Los cambios de congelación durante una carga alta es la única herramienta confiable.

Qué hacer con los servicios de afiliación, ya lo hemos discutido en un artículo anterior. En resumen: desconecta sin piedad por cualquier problema. En la mayoría de los casos, muchos usuarios del servicio tienen problemas de inmediato, y contactar al soporte técnico es una medida poco efectiva. Sus cartas no los ayudarán a reparar más rápido, en esas horas el departamento de TI del servicio está caliente sin ellos.

Sin embargo, si no informa el problema y no obtiene el número de incidente con el momento en que se inició, lo más probable es que no pueda cobrar una multa al servicio por violar el SLA.

Un poco sobre confiabilidad

Como parte de la preparación, debe cambiar todos los servicios de clúster y hardware que fallan. Más sobre esto en uno de mis artículos anteriores.

Me gustaría llamar su atención sobre el siguiente concepto erróneo popular: a muchos les parece que transferir un sitio desde sus servidores a la nube da inmediatamente +100 de confiabilidad. Lamentablemente, solo +20.

Para aumentar la tolerancia a fallas de un servidor virtual, la nube comercial simplemente automatiza y acelera el "reemplazo" del hardware caído en segundos, elevando automáticamente la máquina virtual en uno de los servidores activos. Palabras clave: "acelera" y "hierro caído". La máquina virtual aún se reiniciará. VMware Fault Tolerance y los análogos que le permiten escapar de un reinicio generalmente no se usan en la virtualización comercial debido al consumo de recursos y al rendimiento reducido de las máquinas virtuales protegidas. De ahí la conclusión: una nube comercial no es una panacea para la tolerancia a fallas, sus principales ventajas son la flexibilidad y la escalabilidad.

Mire en el historial de cuánto tiempo de inactividad tuvo que reemplazar o reparar equipos físicos. Después de pasar a la nube, su número disminuirá y, sí, la vida será un poco más fácil para usted. No tiene que correr a un almacén o tienda para un nuevo servidor. Pero ahora se agregarán chistes de virtualización a los bloqueos de hierro.

Puede suceder que la máquina no esté disponible, pero el host físico sigue respondiendo. La nube no verá este problema. O exactamente lo contrario: el host no responde, pero todo está bien con las máquinas virtuales. En este caso, la virtualización los elevará a otra parte. Tardará un tiempo en comenzar, y nuevamente estará inactivo de la nada. Y bajo carga, puede ser fatal. Por lo tanto, incluso en la nube, debe recordar la redundancia. Por cierto, advertir al proveedor de virtualización sobre qué máquinas se respaldan entre sí es una gran idea. De lo contrario, puede suceder que todos sus automóviles terminen en el mismo servidor físico y mueran al mismo tiempo.

• Al realizar pruebas de carga, tiene sentido planificar pruebas de tolerancia a fallas bajo carga.
  

Esto es cuando, justo durante la prueba de carga, sueltas el nodo en el clúster y ves lo que sucede. Con los clústeres configurados correctamente y los recursos asignados correctamente, esto no debería afectar negativamente los resultados de la prueba y causar un montón de errores.

Parece que hemos terminado todos los típicos "tambores". Antes de seguir leyendo, le recomiendo que actualice los detalles técnicos descritos en el artículo anterior . Después de todo, si el sitio es técnicamente incapaz de soportar la carga, la velocidad de reacción no lo salvará.

Ahora pensemos en cómo prepararse para lo inusual o repentino. No podemos evitarlos por definición, por lo que nos queda arremangarnos y aprender a repararlos lo más rápido posible.

Pasos para resolver un incidente

Considere qué constituye el momento de eliminar el accidente:

1. Velocidad de detección de fallas: retraso de monitoreo, recepción de un mensaje del usuario, etc.
   
2. Tiempo de respuesta al incidente detectado: alguien debe notar el informe y tratarlo.
   
3. Hora de confirmar la presencia del incidente: ¿había un niño?
   
4. Tiempo para analizar el incidente y encontrar soluciones.
   
5. Tiempo para resolver el incidente y los problemas. No siempre es posible arreglar todo la primera vez, y esta etapa puede tener varias iteraciones.
   

Por lo general, un servicio de soporte es responsable de la resolución de problemas. Si el equipo es grande, cada uno de estos pasos puede ser realizado por diferentes personas. Y el tiempo, como sabes, es dinero. En nuestro caso, literalmente. El Black Friday tiene una duración fija, y los competidores están alertas: los clientes pueden gastar todo con ellos. En consecuencia, es fundamental que cada empleado conozca su área de responsabilidad y que el transportador resuelva los incidentes.

Miremos cada etapa por separado, identifiquemos los puntos problemáticos y consideremos formas de optimizarlos rápidamente.

Todos los consejos, sugerencias y recomendaciones a continuación no son una receta para una "vida hermosa", sino cosas específicas que podrá implementar en los próximos 3-4 meses que faltan hasta el Viernes Negro.

Detectar accidente

En el escenario más infructuoso, el cliente le informa de los problemas. Es decir, el problema es tan grave que pasó su tiempo informando . En este caso, solo un cliente muy dedicado escribirá o llamará, y un usuario simple se irá encogiéndose de hombros.

Además, a menudo el cliente no tiene acceso directo al departamento de TI. Por lo tanto, escribe a info@business.ru o llama a las chicas desde un centro de llamadas. Cuando la información llegue a TI, pasará mucho tiempo.

Supongamos que tenemos muchos clientes leales, y cada uno de ellos considera que es su deber escribir sobre problemas en TP. Si bien el incidente se clasifica como masivo, mientras aumenta y decide, pasarán horas. Al mismo tiempo, se pueden perder llamadas individuales y, a veces, el correo info@business.ru no se recoge durante semanas.

Por lo tanto, será muy útil comenzar un monitoreo independiente de los principales parámetros comerciales. Al menos: la cantidad de usuarios en el sitio, la cantidad de compras realizadas y su proporción. Estos datos le permitirán responder rápidamente si algo salió mal y reducirá significativamente el tiempo para identificar (y resolver) un problema específico en el sitio.

No hay usuarios? Necesitamos ver a dónde podrían ir. ¿Hay usuarios en el sitio, pero no hay ventas? Esta es una señal del problema, y ​​bastante tarde. Las pruebas de escenarios automáticas lo ayudarán a descubrir que algo sucedió en alguna parte . Por lo general, las pruebas automáticas se ejecutan en compilaciones o versiones, pero están bien para el monitoreo. Con su ayuda, puede ver el desglose o la desaceleración de algunos procesos comerciales importantes a través de los ojos del usuario.

Por supuesto, si no tiene pruebas de escenario, durante los pocos meses restantes hasta el Viernes Negro, no cubrirá todas las pruebas productivas. Sí, y pueden dar una carga seria. Pero con las pruebas de una docena de procesos básicos es muy posible ponerse al día.

También es muy útil para rastrear el tiempo promedio de respuesta del servidor. Si crece, puede esperar problemas de ventas. Dichos datos deben ser monitoreados automáticamente por el sistema de monitoreo.

Como puede ver, con un monitoreo competente, puede reducir el tiempo que lleva detectar un problema de horas y días a unos pocos minutos, y a veces ver el problema antes de que alcance su altura máxima.

Tiempo de respuesta al incidente

Hicimos un gran trabajo y, gracias al monitoreo, detectamos una falla al instante. Ahora debe comenzar el incidente, asignar prioridad, enrutar y asignar a la persona responsable del procesamiento posterior.

Aquí hay dos cosas importantes:

• Recibir notificación de un problema lo antes posible;
  
• Esté preparado para procesar la notificación con prontitud.
  

Muchos especialistas de TI no están acostumbrados a responder rápidamente a las cartas, incluso si tienen un cliente en su teléfono inteligente. Por lo tanto, las notificaciones importantes no deben enviarse por correo electrónico.

Use SMS para alertas de accidentes. Mejor aún, implemente un marcador de bot para los casos más críticos. Personalmente no he visto ninguna implementación práctica de tales bots, pero si los recursos lo permiten, ¿por qué no? Como último recurso, use WhatsApp / Viber / Jabber. Por desgracia, Telegram en el territorio de la Federación Rusa por muchas razones comprensibles no puede ser un canal confiable para notificaciones de emergencia.

También puede ser útil escalar automáticamente un incidente si no hay confirmación. Es decir, el monitoreo notificará al siguiente en línea si el destinatario principal de la notificación no responde. Este sistema te asegurará si algo (o alguien) sale mal.

Ahora hablemos sobre cómo proporcionar una respuesta rápida a los mensajes de falla. Primero, alguien debe estar preparado para ser responsable de manejar las alertas. Las alertas para todo el equipo son útiles, pero solo para mantener a las personas actualizadas.

La responsabilidad colectiva no es confiable cuando se requiere velocidad.

Si no configura el reloj en un horario claro durante la duración de la acción, es posible que durante una fuerza mayor alguien duerma y alguien no tenga acceso desde su casa. Alguien estará en el camino. Y, de hecho, no hay nadie para abordar el problema en la próxima hora. Por supuesto, puede poner un oficial de servicio operativo las 24 horas, pero aquí hay un matiz. No obligará a buenos especialistas a trabajar constantemente en turnos, lo que significa que cuando los necesite, aún tendrá que buscarlos y despertarlos. Y aquellos que aún trabajan por turnos, quedan fuera del contexto general de la vida del equipo. Esto tiene el efecto más fatal en su efectividad para las tareas planificadas.

Lo que nos salvará es que, en la mayoría de los proyectos, debemos responder rápidamente a los mensajes, comprender lo que sucedió y con urgencia debemos repararlo unas 18 horas al día. Por lo general, de 6 a 8 a.m. a 1-2 a.m. al día siguiente, hasta el 90% del tráfico y las ventas.

Para evitar superposiciones, es suficiente cambiar el horario de trabajo para aquellos en servicio a formatos como:

• 6: 00-15: 00 y 17: 00-02: 00 - deber "desde casa";
  
• 15: 00-17: 00 - cubra a aquellos en la oficina;
  
• 02: 00-06: 00 - poco tráfico. Sin embargo, designe a una persona que no esté muy dormida.
  

No te olvides del fin de semana. Este problema se puede resolver de la misma manera.

Si su actividad diaria de usuario se distribuye de manera diferente, elija un horario similar en el que el sitio de horario estelar no quede desatendido.

Estar en servicio significa ser responsable de procesar eventos de monitoreo, llamadas de líneas anteriores (atención al cliente) y monitorear el sistema como un todo. Pero mientras todo está tranquilo, el oficial de servicio se dedica a su trabajo principal.

Asegúrese de comenzar a trabajar unos días antes del inicio de la carga. En primer lugar, esto asegurará una vez más que todos tengan todos los accesos. En segundo lugar, un cambio en el modo de funcionamiento es el estrés, muchos necesitarán "calmarse". Y sería mejor si el período de adicción no coincide con el calor principal.

Genial, llegan alertas, y es para aquellas personas que deberían responderles. Pero el tiempo de respuesta de las personas en servicio está muy influenciado por la presencia de alertas innecesarias y no procesadas, así como notificaciones, que en principio no implican ninguna acción. Es muy importante no dejar alertas sin procesar. Si ocurren muchos eventos similares de manera regular, investigue la causa y repárelo. No debe haber alarmas activas en el sistema de monitoreo.

Por experiencia, si algo no puede repararse rápidamente o si no requiere reparación, pero aún así "parpadea", es mejor suprimir la notificación y crear una tarea para el desarrollo. Una alarma que parpadea constantemente tarde o temprano se vuelve familiar y deja de llamar la atención. El problema es que cuando surge un problema real, las personas pueden confundir la bombilla e ignorar un evento realmente importante.

La configuración adecuada y la priorización de eventos en el sistema de monitoreo sigue siendo extremadamente importante. El sistema debe notificarle exactamente lo que necesita ser reparado. Sobre fallas específicas o el riesgo de su ocurrencia. ¿No reparará el uso del 100% de la CPU? Eliminará las altas latencias en el servidor WEB, porque el uso de la CPU es información para la depuración, no es un problema. Si el Black Friday el procesador se carga al 100% a la carga objetivo, la velocidad de respuesta y teniendo en cuenta las existencias, esto significa que ha calculado todo correctamente.

La utilización de los recursos del sistema debe controlarse, pero esta es una tarea ligeramente diferente, que es importante para la planificación de recursos y la identificación de áreas de impacto del accidente.

Configuramos los eventos, ahora es importante priorizar correctamente lo que corregiremos en primer lugar. Para hacer esto, descubriremos cuáles son las diferencias entre los niveles de alertas críticas y de advertencia. Déjame darte algunos ejemplos exagerados pero comprensibles.

Crítico : esto es cuando vas a la abuela en el metro, recibes una alerta y vas a la estación más cercana. Sacas una computadora portátil, te sientas en un banco pequeño y comienzas a trabajar: hubo una parada en las ventas o aparecieron grandes pérdidas. Es decir, Crítico es algo que tiene un impacto directo, aunque significativo, en los usuarios.

Advertencia : esto es cuando no abandonas el trabajo hasta que lo reparas. Lanzar todo y correr para ayudar en aras de la advertencia no es necesario. Puedes terminar / terminar y tomar una decisión. Por ejemplo, existía un claro riesgo de problemas críticos, como un servidor caído de un par HA, los errores cayeron en los registros y similares. Si no martilla y repara concienzudamente tales eventos (así como profundiza en las causas y realiza trabajos para prevenirlos), habrá muy pocos de ellos.

Otra cosa que a menudo se olvida. No arrojes de turno solo a los administradores. Asegúrese de atraer desarrolladores formando pares de trabajo para cada turno. Esto será útil para nosotros en los próximos pasos.

Si el proyecto es funcionalmente complejo, tiene sentido enviar consultores, analistas, evaluadores y todos los demás que puedan ser útiles de servicio. Asegure su disponibilidad al menos por llamada. El especialista tendrá que confirmar el problema (o viceversa) y ayudarlo con la localización funcional; cuando tenga que criar a una persona para su reparación, esto le ahorrará tiempo. Discutiré este tema con más detalle en la siguiente sección.

Y el último punto importante. Cada oficial de servicio debe conocer a fondo los contactos y las áreas de responsabilidad de todos sus colegas en situaciones de emergencia. Si no puede resolver el problema por sí solo y, en estado de pánico, comienza a buscar rescatadores disponibles, vendrá el caos, por lo que perderá mucho tiempo.

El cumplimiento de estas reglas simples ayudará a evitar problemas debido a notificaciones perdidas y garantía: cuando llegue la emergencia (lea "Black Friday" y "incidente de emergencia"), las personas podrán resolver los problemas de inmediato.

Confirmar incidente

El siguiente paso después de recibir una notificación es comprender qué salió mal exactamente y si existe un problema en principio: determinar de inmediato quién tiene la razón, el usuario o el sistema, no siempre es fácil. El hecho es que la misma alerta se puede interpretar de manera diferente según el ángulo de visión.

, , ( ), . , . , . , , «» , .

, . , ! - , «».

- . «» . , , .

— , , . , . , , . — - « », « » « , ».

, , , , «». , , . — , , , . : , , .

, . , . . , , . — , : .

. -, , , – , , , , ( , ) .



. .

. , .

, . , , :

• ;
  
• ;
  
• ;
  
• ;
  
• (, ..).
  

, , , . -. , ELK .

, , .

- , , , .

, — . , , . , . , .

- , . , , , — .

: , , , . , 3 :

1. ;
   
2. ;
   
3. .
   

. ( ). , , -, , - .

. . , , , . , , — .

. , - - , , , - . . . , , , .

, , . , . , , « » .

– SLA. SLA – , , . SLA , . , - . , .

— , . , , . .

Hasta ahora, eso es todo lo que me gustaría contar sobre este tema. Me alegrará si mi consejo, transferido a las realidades de su negocio, me permite sobrevivir a la gran carga con calma y comodidad.

Si quieres consejos sobre cómo actuar en tu situación, te invito a mi seminario Black Friday. Secretos de supervivencia. En el formato de preguntas y respuestas, hablaremos sobre la preparación del sitio para el crecimiento del tráfico y discutiremos los detalles técnicos y organizativos de este proceso.

El seminario se llevará a cabo el 16 de agosto en Moscú. Dado que el evento será bastante de cámara (máximo 25 personas), se requiere una cita. Y estoy esperando el resto para debatir en los comentarios. :)