"Y si no disparas, me echarán a perder"
Hasta hace poco, se creía que el servicio debería funcionar. Dibujaron, inventaron, escribieron guiones: todo parece estar bien, puedes pasarlo al producto.
Pero los competidores no están dormidos, por lo que la carrera comienza no solo por las nuevas características, sino también por la velocidad. Cualquier congelación de la aplicación o una respuesta larga del servidor (sin mencionar los errores emergentes del número 500) estropean la impresión del servicio y obligan al usuario a irse a otro lugar. Seguramente, todos enfrentaron situaciones en las que, en lugar de comprar un boleto para un avión, tren o concierto, se mostraba en la pantalla el mensaje "Error interno del servidor", y usted estaba furioso por romper el monitor.
Soy Victor Bodrov, trabajo en Yandex. Dinero en el equipo de investigación de productividad y quiero hablar sobre cómo es útil estudiar la productividad directamente en la producción.
Cada minuto de tiempo de inactividad es desastroso para las empresas, especialmente para aquellos involucrados en transacciones financieras, como transferencias y pagos, pago de bienes en las tiendas. Cada pago pendiente no es solo pérdidas monetarias, sino también pérdidas de reputación. En tales condiciones, se necesita un alto tiempo de actividad, para lo cual es necesario estar al tanto del sistema de pago y monitorear constantemente todos sus indicadores, prestando especial atención al rendimiento.
¿Por qué investigarlo?
En primer lugar, conocer el rendimiento de su propio servicio lo ayuda a prepararse para el lanzamiento de nuevas funciones, diversas promociones y ventas. El conocimiento de indicadores confiables ayudará en el momento adecuado a satisfacer la afluencia de nuevos usuarios, no con una puerta pequeña con torniquete, sino con puertas delanteras y brazos abiertos.
En segundo lugar, un buen servicio debe conocer el límite de su rendimiento en cualquier momento, por lo que las mediciones deben ser regulares. Si hace esto con la frecuencia suficiente, manteniendo la relevancia de los datos, no se pierda la degradación en su servicio y puede restaurar rápidamente los indicadores requeridos.
En tercer lugar, confiando en datos de rendimiento actualizados, es más fácil para las empresas planificar el desarrollo de un servicio y elegir direcciones de crecimiento.
Para aquellos que están desconcertados por este problema por primera vez, surge la pregunta: ¿dónde y cómo medir la productividad? A menudo, se usa un banco para tales experimentos. En empresas individuales, hay un stand especial para la investigación del desempeño. Si lo tienes, ¡genial! Si es 1 en 1 corresponde al producto, entonces todo está bien para usted. Pero la mayoría de las veces es muy costoso mantener un stand que coincida completamente con el producto. Como ser Resulta que el único lugar que corresponde totalmente al producto es el producto en sí.
Para muchos, la propuesta de medir y verificar algo directamente en el producto parece herética. No se alarme si todo se hace con cuidado, no pasará nada malo. Por ejemplo, calculamos previamente los posibles riesgos y determinamos qué puede sufrir el experimento en nuestro sistema. Junto con esto, planeamos cómo reducir el peligro y monitorear constantemente el estado del sistema.
La investigación sobre productos no cancela el uso del soporte. Puede realizar comprobaciones de liberación y experimentos especiales para estudiar el rendimiento de los microservicios, incluidos individualmente o en varias combinaciones.
La ventaja principal e innegable de los resultados obtenidos en el producto: son las opciones más honestas y lo más cercanas posible al procesamiento real del tráfico de usuarios. No importa cuán cerca esté el soporte del producto en términos de características, no podrá atraparlo, como la tortuga de Aquiles. Al investigar sobre el producto, utilizará las mismas bases de datos que los usuarios reales, la misma red, el mismo entorno. No es necesario construir nada, todo ya se ha construido antes que usted y funciona correctamente.
Los datos de tales experimentos serán de interés para todos los ingenieros, independientemente de la función que se les asigne: desarrolladores, probadores, administradores. Los indicadores de rendimiento garantizados también interesarán a la empresa: para los clientes potenciales serán un anuncio convincente del servicio.
Selección de escenarios y patrones de flujo de carga
Para la organización segura y adecuada de tales experimentos, se deben completar varios pasos obligatorios.
Selección de escenario
El primer paso, el más importante, es seleccionar los escenarios en estudio. Pueden ser solicitudes individuales (por ejemplo, verificar el saldo) o escenarios con lógica compleja, donde cada solicitud posterior depende de los resultados de la anterior (pago de bienes en la tienda, transferencia de billetera a billetera). Regularmente tomamos una lista de todos los procesos comerciales que existen en el sistema. Tenemos más de 400 procesos de este tipo y, en función de los objetivos del negocio, coordinaremos las prioridades del escenario.
¿Qué escenarios deberían incluirse en el grupo prioritario?
- Aquellos para los que se espera un aumento en la actividad del usuario en el futuro cercano.
- Aquellos para los cuales existen restricciones estrictas constantes (por varias razones) que no le permiten caer por debajo del SLA.
Por lo tanto, es posible formar un conjunto de escenarios de prioridad para verificaciones periódicas en el producto. En nuestra empresa, realizamos disparos contra ellos al menos una vez por trimestre.
Se selecciona un conjunto de técnicas y herramientas dependiendo de la lógica del guión. En nuestro caso, los escenarios de prioridad tienen lógica ramificada. Por ejemplo, cuando se realizan pagos con tarjeta, se llevan a cabo varios controles, según el script que vaya a su propia sucursal, por lo que usamos JMeter para implementarlos. Es conveniente solo para escenarios tan complejos, donde cada solicitud posterior depende del resultado de la anterior. Si necesita disparar solicitudes individuales, le recomiendo usar Phantom de alto rendimiento.
Para investigar escenarios de usuarios, pueden ser necesarios usuarios especiales, en nombre de los cuales se realizarán las solicitudes. Si utiliza un usuario o un pequeño número de ellos, puede encontrar el almacenamiento en caché de datos, lo que distorsionará los resultados. Cuantos más usuarios diferentes, más precisos serán los datos de la investigación.
Circuito de carga
En el segundo paso, seleccionamos el circuito de alimentación de intensidad de entrada.
Por ejemplo, antes de una venta, determinamos cuáles son las principales formas en que los usuarios pagarán. Para ajustar y rastrear cuellos de botella, realizamos disparos en ciertos tipos de pagos. Como regla general, la actividad del usuario durante varias promociones tiende a favorecer uno u otro escenario. Al marcarlo, obtienes una imagen clara de su comportamiento bajo carga.
Pero las empresas también pueden estar interesadas en el panorama general del rendimiento. Para este caso, puede combinar los escenarios empresariales más populares en proporción a su uso por parte de usuarios reales y activar la carga acumulativa. Vale la pena considerar que en este caso pueden surgir dificultades con la evaluación cuantitativa. En lugar de un número de rendimiento específico, obtendrá una serie de números, que, a su vez, puede variar según las proporciones de un escenario particular en el flujo general.
El suministro de intensidad también puede ser diferente. Me centraré en los dos perfiles más comunes. Esta es una prueba con una prueba de flujo de intensidad y estabilidad suministrada que aumenta linealmente (o paso a paso), en la cual la operación a largo plazo del servicio se verifica bajo un flujo de intensidad estable y grande. La segunda opción requiere un largo tiempo de investigación, que no siempre es posible en un entorno de combate, además, el nivel de intensidad suministrada ya debería conocerse.
Eje X - tiempo, eje Y - intensidad de carga (solicitudes por segundo)
Es bueno cuando hay un SLA específico en función del cual puede realizar comprobaciones supervisando el rendimiento, el tiempo de respuesta y el comportamiento de los componentes. Una situación más común es cuando el nivel de rendimiento es desconocido y usted necesita determinarlo. Para hacer esto, utilizamos la primera opción: medición con una intensidad suministrada creciente. Encendemos el flujo de entrada, lo incrementamos linealmente o paso a paso, observamos el comportamiento del servicio. Una carga aplicada linealmente puede rastrear con mayor precisión el punto de saturación y el punto de ruptura. Esto se describió con más detalle en nuestro artículo . Pero la intensidad suministrada por pasos combina incluso pequeñas pruebas de estabilidad, especialmente si los pasos son largos en el tiempo. No se recomienda aplicar inmediatamente un gran flujo de carga a la entrada, es mejor "calentar" el servicio, aumentando gradualmente la corriente de entrada.
También puede realizar una serie de dos experimentos. Primero mida el punto de saturación con una carga aplicada linealmente y pare. No debe continuar alimentando la transmisión más allá del desglose, sigue siendo un producto, no un soporte. El segundo experimento es observar el comportamiento del servicio bajo una carga escalonada seleccionando varios pasos cerca del punto de saturación. Y luego realice una prueba de estabilidad en la medida en que el tiempo lo permita, eligiendo una carga para ella 15-20% por debajo del punto de saturación (o un desglose si de repente la tuvo antes de la saturación). Subir más alto es peligroso.
Tiempo
A continuación, debe determinar la hora del experimento. Una de las condiciones más importantes para realizar mediciones de rendimiento en el producto es la seguridad para todos los usuarios reales. Es extremadamente raro que haya una oportunidad de detener el servicio por un tiempo para prevenirlo y bombardearlo con calma. Como regla general, los servicios en línea están ajustados para funcionar las 24 horas, los 7 días de la semana, por lo que debe adaptarse al modo de uso del servicio.
Es lógico que cuanto mayor sea la actividad real del usuario, mayores serán los riesgos de que el disparo pueda ocasionar tiempo de inactividad y pérdidas financieras. Por otro lado, cuanto menos tráfico de usuarios, menos error de medición. Por lo tanto, para minimizar el impacto de los experimentos, se recomienda que se realicen en períodos de actividad reducida del usuario.
Como muestra la práctica, la actividad mínima de nuestros usuarios cae en el período de dos a siete de la mañana. Por supuesto, cada servicio tiene sus propias características y su propia audiencia, por lo que determinamos el tiempo de rodaje mediante el monitoreo del comportamiento de los usuarios. No siempre es posible organizar experimentos en el período óptimo seleccionado. Para disparar al producto, especialmente en la etapa inicial de su conexión, se requiere un mayor control. Esto causará dificultades, ya que sus colegas también son personas y no siempre pueden ir a trabajar por la noche. Esta situación requerirá un compromiso. Debe elegir un horario que sea adecuado para todos y al mismo tiempo satisfacer la condición de baja actividad del usuario.
Dificultades para trabajar con contrapartes
Si el servicio está vinculado no solo a los cálculos internos, sino también a la interacción con servicios de terceros (contrapartes), debe elegir cómo llevará a cabo su despido: junto con la contraparte o utilizando el talón del servicio. Naturalmente, si planea disparar a los servidores de la contraparte, primero debe ponerse de acuerdo en todo. Esto complicará en gran medida la preparación para disparar, pero agregará ventajas a la veracidad de los resultados obtenidos como resultado.
Y viceversa: si reemplaza el servicio de la contraparte con un enchufe, la preparación para disparar se simplificará enormemente, pero la honestidad de los resultados disminuirá. Debe tenerse en cuenta que el talón debe imitar el comportamiento de la contraparte tanto como sea posible, y no solo dar 200 OK.
Las contrapartes mismas son diferentes. Algunos van fácilmente a verificaciones conjuntas, mientras que otros ejecutan cada paso a través de muchas instancias. Determinar el momento de los experimentos también puede causar controversia. Por ejemplo, algunas oficinas estatales aceptan trabajar solo de 9 a 18 horas.
Verificación de acceso y coordinación con el Consejo de Seguridad, departamentos financieros, administradores
En esta parte, nos centraremos en los accesos y aprobaciones con todas las personas responsables: el servicio de seguridad, los departamentos financieros y los administradores del sistema.
Debe verificar los accesos necesarios . Asegúrese de que nada interfiera con la investigación y, si es necesario, ordene los accesos de los administradores de la red, tanto de usted como de sus contrapartes, si trabaja con ellos. Los administradores de red ayudarán con la configuración de equilibrio. Una vez tuvimos un cambio de balanceador de round-robin a ip-hash. Como resultado, todas nuestras consultas cayeron en el mismo frente, seleccionadas por el nuevo algoritmo de equilibrio.
Después de obtener acceso, debe depurar y verificar el script en la secuencia de unidad más pequeña.
Los siguientes pasos son aprobaciones . En primer lugar, póngase en contacto con el servicio de seguridad para que su experimento no se interrumpa en el despegue debido a una "actividad sospechosa". Para evaluar todos los riesgos posibles del Consejo de Seguridad, se requiere un plan de despido detallado: quién, qué y en qué cantidades está involucrado.
A continuación, debe coordinar el plan de despido con los departamentos financieros y comerciales. Si el servicio está asociado con actividades financieras, se requerirá coordinación con el departamento financiero y contabilidad. Cualquier actividad financiera adicional puede afectar los estados financieros o incluso causar un mal funcionamiento en la formación de una variedad de resúmenes de publicación. Esto debe evitarse, por lo que vale la pena advertir a los colegas, habiendo resuelto la configuración óptima de los experimentos.
Si tiene un departamento de estadísticas que acumula información sobre el funcionamiento del servicio, debe coordinar el rodaje con ellos. El hecho es que el flujo de carga causará una ola adicional de estadísticas. Acuerde si tomarán en cuenta las pruebas en sus informes o no. De lo contrario, decida cómo se separarán los datos de los usuarios reales de los de prueba.
Cuando planifique, también debe coordinar la fecha y la hora de las pruebas con el departamento comercial, ya sea que tengan anuncios o promociones planificadas para este momento o alrededor. No olvide informar a los líderes del equipo sobre todas las actividades planificadas y no planificadas en el producto. Naturalmente, debe advertir y estar de acuerdo con los administradores, ya que durante el rodaje puede ser necesaria su participación. Además, son los administradores en el curso sobre todas las acciones en el producto. Quizás justo en el momento que elija, se planifique la conmutación del centro de datos, el reemplazo del servidor u otro trabajo.
Despido y análisis de los resultados.
Finalmente, discutimos la realización de disparos con monitoreo. Determinamos dónde mirar durante los experimentos, en qué condiciones parar, a qué sensores responder. Esto debe hacerse "en tierra", antes del inicio del rodaje.
Hay varias razones para detenerse.
1) En una señal de monitoreo. En este caso, no importa si la funcionalidad involucrada en el experimento se rompe o si ocurre una emergencia en el otro extremo del servicio. Debe detener las pruebas y comprender los motivos, porque el buen funcionamiento del servicio es una de las principales prioridades.
2) Con el crecimiento de la red o errores HTTP. Esta es una situación de emergencia que requiere intervención.
3) Si se alcanza la saturación, el rendimiento ya no aumenta, pero el tiempo de respuesta aumenta. No es necesario esperar el desglose y poner el producto. El resultado para el análisis ya está allí, puede detener el experimento de forma segura.
Después del experimento, puede comprender que no hay suficientes registros y resultados y debe repetir el experimento con el registro de depuración habilitado. Esto hará que el registro y la escritura en el disco sean más pesados, pero ahora conoce el nivel de la carga requerida, lo que significa que en lugar de una prueba larga, puede acortarlo.
Análisis de resultados
Al final, queda por analizar los resultados y proporcionar los datos obtenidos a las partes interesadas. Puede comenzar a hacer esto ya durante los experimentos. Usamos paquetes Zabbix y Elastic con Grafana y Kibana para el análisis. Monitoreamos las características de tiempo de todas las llamadas externas e internas involucradas en nuestro experimento, monitoreamos los grupos de conectores, las colas y el monitor de la base de datos. Para el seguimiento en línea de métricas desde el lado del generador de tráfico: servicio Yandex Lunapark (hay un análogo abierto: overload.yandex.net).
La presentación de los resultados variará dependiendo de quién los necesite. Para el desarrollo, los administradores y probadores necesitan un informe detallado con métricas, gráficos, registros, seguimientos de pila precisos. Para las empresas, el resultado y las previsiones de desarrollo son importantes. En este caso, la concreción y el énfasis de los números es mejor y más visual. Para hacer esto, puede usar el principio de los semáforos. La zona roja es mala, es urgente optimizarla. Amarillo: notamos una degradación de los indicadores, debe prestar atención a esto. Verde: todo está bien, sigue adelante. Una visión clara y accesible de los resultados de la investigación ayudará a eliminar preguntas sobre la importancia y utilidad de medir el desempeño.
¡Investigación exitosa y recuerde la seguridad del usuario!