Todo el mundo habla de procesos de desarrollo y pruebas, de formación del personal y de aumento de la motivación, pero estos procesos no son suficientes cuando un minuto de inactividad del servicio cuesta enormes cantidades de dinero. ¿Qué hacer cuando realizas transacciones financieras bajo un SLA estricto? ¿Cómo aumentar la confiabilidad y la tolerancia a fallas de sus sistemas, eliminando el desarrollo y las pruebas de la ecuación?
La próxima conferencia HighLoad++ se llevará a cabo los días 6 y 7 de abril de 2020 en San Petersburgo. Detalles y entradas para . 9 de noviembre, 18:00 horas. HighLoad++ Moscú 2018, sala Delhi + Kolkata. Tesis y .
Evgeniy Kuzovlev (en adelante – CE): - ¡Amigos, hola! Mi nombre es Kuzovlev Evgeniy. Soy de la empresa EcommPay, una división específica es EcommPay IT, la división de TI del grupo de empresas. Y hoy hablaremos de tiempos de inactividad, de cómo evitarlos, de cómo minimizar sus consecuencias si no se pueden evitar. El tema se plantea de la siguiente manera: “¿Qué hacer cuando un minuto de inactividad cuesta 100 dólares”? De cara al futuro, nuestras cifras son comparables.
¿Qué hace EcommPay TI?
¿Quienes somos? ¿Por qué estoy parado aquí frente a ti? ¿Por qué tengo derecho a decirte algo aquí? ¿Y de qué hablaremos aquí con más detalle?
El grupo de empresas EcommPay es un adquirente internacional. Procesamos pagos en todo el mundo: en Rusia, Europa, el Sudeste Asiático (en todo el mundo). Contamos con 9 oficinas, 500 empleados en total, y aproximadamente un poco menos de la mitad de ellos son especialistas en TI. Todo lo que hacemos, todo con lo que ganamos dinero, lo hicimos nosotros mismos.
Nosotros mismos escribimos todos nuestros productos (y tenemos muchos de ellos; en nuestra línea de grandes productos de TI tenemos alrededor de 16 componentes diferentes); Nos escribimos, nos desarrollamos. Y actualmente realizamos alrededor de un millón de transacciones al día (millones es probablemente la forma correcta de decirlo). Somos una empresa bastante joven: sólo tenemos unos seis años.
Hace 6 años era una startup cuando los chicos crearon el negocio. Los unía una idea (no había nada más que una idea) y echamos a correr. Como cualquier startup, corríamos más rápido... Para nosotros, la velocidad era más importante que la calidad.
En algún momento nos detuvimos: nos dimos cuenta de que ya no podíamos vivir a esa velocidad y con esa calidad y que teníamos que centrarnos primero en la calidad. En este momento, decidimos escribir una nueva plataforma que fuera correcta, escalable y confiable. Comenzaron a escribir esta plataforma (comenzaron a invertir, desarrollar, probar), pero en algún momento se dieron cuenta de que el desarrollo y las pruebas no nos permitían alcanzar un nuevo nivel de calidad de servicio.
Haces un nuevo producto, lo pones en producción, pero aun así algo saldrá mal en alguna parte. Y hoy hablaremos de cómo alcanzar un nuevo nivel de calidad (cómo lo hicimos, de nuestra experiencia), sacando de la ecuación el desarrollo y las pruebas; hablaremos sobre lo que está disponible para la operación: qué puede hacer la operación por sí misma, qué puede ofrecer a las pruebas para influir en la calidad.
Tiempos de inactividad. Mandamientos de operación.
Siempre la piedra angular principal, de lo que hablaremos hoy es del tiempo de inactividad. Una palabra terrible. Si tenemos tiempo de inactividad, todo nos va mal. Corremos para levantarlo, los administradores sostienen el servidor; Dios no quiera que se caiga, como dicen en esa canción. De esto es de lo que hablaremos hoy.
Cuando comenzamos a cambiar nuestros enfoques, formamos 4 mandamientos. Los tengo presentados en las diapositivas:
Estos mandamientos son bastante simples:
- Identifique rápidamente el problema.
- Deshazte de él aún más rápido.
- Ayude a comprender el motivo (más adelante, para desarrolladores).
- Y estandarizar enfoques.
Me gustaría llamar su atención sobre el punto número 2. Nos deshacemos del problema, no lo solucionamos. Decidir es secundario. Para nosotros lo primordial es que el usuario esté protegido de este problema. Existirá en algún entorno aislado, pero este entorno no tendrá ningún contacto con él. En realidad, repasaremos estos cuatro grupos de problemas (algunos con más detalle, otros con menos detalle), les diré qué usamos, qué experiencia relevante tenemos en soluciones.
Solución de problemas: ¿Cuándo ocurren y qué hacer al respecto?
Pero comenzaremos fuera de orden, comenzaremos con el punto número 2: ¿cómo solucionar rápidamente el problema? Hay un problema: debemos solucionarlo. "¿Que debemos hacer sobre esto?" - la pregunta principal. Y cuando empezamos a pensar en cómo solucionar el problema, desarrollamos algunos requisitos que deben seguirse para la resolución de problemas.
Para formular estos requisitos decidimos hacernos la pregunta: “¿Cuándo tendremos problemas”? Y resultó que los problemas ocurren en cuatro casos:
- Fallo de hardware.
- Los servicios externos fallaron.
- Cambiar la versión del software (la misma implementación).
- Crecimiento de carga explosiva.
No hablaremos de los dos primeros. Un mal funcionamiento del hardware se puede solucionar de forma muy sencilla: hay que tener todo duplicado. Si son discos, los discos deben estar ensamblados en RAID; si esto es un servidor, el servidor debe estar duplicado; si tienes una infraestructura de red, debes suministrar una segunda copia de la infraestructura de red, es decir, la tomas y duplicarlo. Y si algo falla, cambias a energía de reserva. Es difícil decir algo más aquí.
El segundo es el fracaso de los servicios externos. Para la mayoría, el sistema no es un problema en absoluto, pero para nosotros no. Dado que procesamos pagos, somos un agregador que se interpone entre el usuario (que ingresa los datos de su tarjeta) y los bancos, sistemas de pago (Visa, MasterCard, Mira, etc.). Nuestros servicios externos (sistemas de pago, bancos) tienden a fallar. Ni nosotros ni usted (si dispone de dichos servicios) podemos influir en esto.
¿Qué hacer entonces? Aquí hay dos opciones. Primero, si puedes, deberías duplicar este servicio de alguna manera. Por ejemplo, si podemos, transferimos el tráfico de un servicio a otro: por ejemplo, las tarjetas se procesaron a través de Sberbank, Sberbank tiene problemas: transferimos el tráfico [condicionalmente] a Raiffeisen. Lo segundo que podemos hacer es notar la falla de los servicios externos muy rápidamente y, por lo tanto, hablaremos de la velocidad de respuesta en la siguiente parte del informe.
De hecho, de estos cuatro, podemos influir específicamente en el cambio de versiones de software: tomar medidas que conduzcan a una mejora de la situación en el contexto de las implementaciones y en el contexto de un crecimiento explosivo de la carga. En realidad, eso es lo que hicimos. Aquí, de nuevo, una pequeña nota...
De estos cuatro problemas, varios se solucionan inmediatamente si tienes una nube. Si se encuentra en las nubes Microsoft Azhur, Ozone o utiliza nuestras nubes, desde Yandex o Mail, entonces al menos un mal funcionamiento del hardware se convierte en su problema y todo se pone bien inmediatamente para usted en el contexto de un mal funcionamiento del hardware.
Somos una empresa un poco poco convencional. Aquí todo el mundo habla de "Kubernets", de nubes; no tenemos ni "Kubernets" ni nubes. Pero tenemos bastidores de hardware en muchos centros de datos y nos vemos obligados a vivir de este hardware, estamos obligados a ser responsables de todo. Por tanto, hablaremos en este contexto. Entonces, sobre los problemas. Los dos primeros fueron eliminados de paréntesis.
Cambiar la versión del software. Bases
Nuestros desarrolladores no tienen acceso a la producción. ¿Porqué es eso? Es solo que tenemos la certificación PCI DSS y nuestros desarrolladores simplemente no tienen derecho a acceder al "producto". Eso es todo, punto. En absoluto. Por lo tanto, la responsabilidad del desarrollo termina exactamente en el momento en que el desarrollo envía la compilación para su lanzamiento.
Nuestra segunda base que tenemos, que también nos ayuda mucho, es la ausencia de conocimientos únicos e indocumentados. Espero que sea lo mismo para ti. Porque si no es así tendrás problemas. Los problemas surgirán cuando este conocimiento único e indocumentado no esté presente en el momento adecuado y en el lugar adecuado. Digamos que tiene una persona que sabe cómo implementar un componente específico (la persona no está allí, está de vacaciones o enferma), eso es todo, tiene problemas.
Y la tercera base a la que hemos llegado. Llegamos a ello con dolor, sangre y lágrimas; llegamos a la conclusión de que cualquiera de nuestras compilaciones contiene errores, incluso si no contiene errores. Decidimos esto por nosotros mismos: cuando implementamos algo, cuando ponemos algo en producción, tenemos una compilación con errores. Hemos formado los requisitos que nuestro sistema debe satisfacer.
Requisitos para cambiar la versión del software.
Hay tres requisitos:
- Debemos revertir rápidamente el despliegue.
- Debemos minimizar el impacto de un despliegue fallido.
- Y debemos poder desplegar rápidamente en paralelo.
¡Exactamente en ese orden! ¿Por qué? Porque, en primer lugar, al implementar una nueva versión, la velocidad no es importante, pero sí es importante que, si algo sale mal, retroceda rápidamente y tenga un impacto mínimo. Pero si tiene un conjunto de versiones en producción, para las cuales resulta que hay un error (de la nada, no hubo implementación, pero hay un error), la velocidad de la implementación posterior es importante para usted. ¿Qué hemos hecho para satisfacer estas demandas? Recurrimos a la siguiente metodología:
Es bastante conocido, nunca lo hemos inventado: este es el despliegue Azul/Verde. ¿Lo que es? Debe tener una copia para cada grupo de servidores en los que estén instaladas sus aplicaciones. La copia es “cálida”: no hay tráfico en ella, pero en cualquier momento este tráfico puede enviarse a esta copia. Esta copia contiene la versión anterior. Y en el momento de la implementación, implementa el código en una copia inactiva. Luego cambias parte del tráfico (o todo) a la nueva versión. Por lo tanto, para cambiar el flujo de tráfico de la versión anterior a la nueva, solo debe realizar una acción: debe cambiar el equilibrador en el sentido ascendente, cambiar la dirección, de un sentido ascendente a otro. Esto es muy conveniente y resuelve el problema del cambio rápido y la reversión rápida.Aquí la solución a la segunda pregunta es la minimización: puedes enviar solo una parte de tu tráfico a una nueva línea, a una línea con un nuevo código (sea, por ejemplo, el 2%). ¡Y ese 2% no es el 100%! Si perdió el 100% de su tráfico debido a una implementación fallida, eso da miedo; si perdió el 2% de su tráfico, es desagradable, pero no da miedo. Además, lo más probable es que los usuarios ni siquiera se den cuenta de esto, porque en algunos casos (no en todos) el mismo usuario, al presionar F5, será llevado a otra versión funcional.
Despliegue azul/verde. Enrutamiento
Sin embargo, no todo es tan sencillo “despliegue Azul/Verde”... Todos nuestros componentes se pueden dividir en tres grupos:
- este es el frontend (páginas de pago que ven nuestros clientes);
- núcleo de procesamiento;
- Adaptador para trabajar con sistemas de pago (bancos, MasterCard, Visa...).
Y aquí hay un matiz: el matiz radica en la ruta entre líneas. Si simplemente cambia el 100% del tráfico, no tendrá estos problemas. Pero si quieres cambiar el 2%, empiezas a hacerte preguntas: "¿Cómo hacer esto?" Lo más simple es sencillo: puedes configurar Round Robin en nginx mediante elección aleatoria, y tienes 2% a la izquierda, 98% a la derecha. Pero esto no siempre es adecuado.
Por ejemplo, en nuestro caso, un usuario interactúa con el sistema con más de una solicitud. Esto es normal: 2, 3, 4, 5 solicitudes; es posible que sus sistemas sean los mismos. Y si es importante para usted que todas las solicitudes del usuario lleguen a la misma línea en la que llegó la primera solicitud, o (segundo punto) todas las solicitudes del usuario lleguen a la nueva línea después del cambio (podría haber comenzado a trabajar antes con el sistema, antes del cambio), entonces esta distribución aleatoria no es adecuada para usted. Luego están las siguientes opciones:
La primera opción, la más sencilla, se basa en los parámetros básicos del cliente (IP Hash). Tienes una IP y la divides de derecha a izquierda por dirección IP. Entonces, el segundo caso que describí funcionará para usted, cuando ocurrió la implementación, el usuario ya podría comenzar a trabajar con su sistema, y desde el momento de la implementación, todas las solicitudes irán a una nueva línea (a la misma, digamos).Si por alguna razón esto no le conviene y debe enviar solicitudes a la línea donde llegó la solicitud inicial del usuario, entonces tiene dos opciones...
Primera opción: puedes comprar nginx+ pagado. Existe un mecanismo de sesiones fijas que, tras la solicitud inicial del usuario, asigna una sesión al usuario y la vincula a uno u otro en sentido ascendente. Todas las solicitudes de usuarios posteriores dentro de la duración de la sesión se enviarán al mismo canal ascendente donde se publicó la sesión.Esto no nos convenía porque ya teníamos nginx normal. Cambiar a nginx+ no es que sea caro, es sólo que fue algo doloroso para nosotros y no muy correcto. Las “Sesiones Sticks”, por ejemplo, no funcionaron para nosotros por la sencilla razón de que las “Sesiones Sticks” no permiten el enrutamiento basado en “Esto o lo otro”. Allí puede especificar lo que hacemos las “Sticks Sessions”, por ejemplo, por dirección IP o por dirección IP y cookies o por postparámetro, pero “Esto o lo otro” es más complicado allí.
Por tanto, llegamos a la cuarta opción. Tomamos nginx con esteroides (esto es openresty); este es el mismo nginx, que además admite la inclusión de los últimos scripts. Puede escribir un último script, darle un "descanso abierto" y este último script se ejecutará cuando llegue la solicitud del usuario.
Y, de hecho, escribimos dicho script, nos configuramos "openresti" y en este script clasificamos 6 parámetros diferentes por concatenación "O". Dependiendo de la presencia de uno u otro parámetro, sabemos que el usuario llegó a una página u otra, a una línea u otra.
Despliegue azul/verde. Ventajas y desventajas
Por supuesto, probablemente sería posible hacerlo un poco más simple (use las mismas “Sticky Sessions”), pero también tenemos tal matiz que no solo el usuario interactúa con nosotros en el marco del procesamiento de una transacción... Pero los sistemas de pago también interactúan con nosotros: después de procesar la transacción (enviando una solicitud al sistema de pago), recibimos un reembolso.
Y digamos, si dentro de nuestro circuito podemos reenviar la dirección IP del usuario en todas las solicitudes y dividir a los usuarios según la dirección IP, entonces no le diremos a la misma "Visa": "Amigo, somos una empresa tan retro, parecemos ser internacional (en el sitio web y en Rusia)... ¡Por favor proporciónenos la dirección IP del usuario en un campo adicional, su protocolo está estandarizado”! Está claro que no estarán de acuerdo.
Por lo tanto, esto no funcionó para nosotros: lo hicimos openresty. En consecuencia, con el enrutamiento obtuvimos algo como esto:La implementación azul/verde tiene, en consecuencia, las ventajas y desventajas que mencioné.
Dos desventajas:
- debes preocuparte por el enrutamiento;
- La segunda desventaja principal es el gasto.
Necesita el doble de servidores, necesita el doble de recursos operativos, necesita gastar el doble de esfuerzo para mantener todo este zoológico.
Por cierto, entre las ventajas hay una cosa más que no he mencionado antes: tienes una reserva en caso de crecimiento de carga. Si tiene un crecimiento explosivo en la carga, tiene una gran cantidad de usuarios, entonces simplemente incluye la segunda línea en la distribución 50 a 50 e inmediatamente tendrá servidores x2 en su clúster hasta que resuelva el problema de tener más servidores.
¿Cómo hacer un despliegue rápido?
Hablamos sobre cómo resolver el problema de la minimización y la reversión rápida, pero la pregunta sigue siendo: "¿Cómo implementar rápidamente?"
Es breve y simple aquí.- Debe tener un sistema de CD (entrega continua); no puede vivir sin él. Si tiene un servidor, puede implementarlo manualmente. Tenemos alrededor de mil quinientos servidores y mil quinientos identificadores, por supuesto; podemos plantar un departamento del tamaño de esta sala solo para implementarlo.
- El despliegue debe ser paralelo. Si su implementación es secuencial, entonces todo está mal. Un servidor es normal, implementará mil quinientos servidores durante todo el día.
- Nuevamente, para la aceleración, esto probablemente ya no sea necesario. Durante la implementación, el proyecto generalmente se construye. Tiene un proyecto web, hay una parte frontal (hace un paquete web allí, compila npm, algo así), y este proceso es, en principio, de corta duración: 5 minutos, pero estos 5 minutos pueden ser crítico. Por eso, por ejemplo, no hacemos eso: eliminamos esos 5 minutos, implementamos artefactos.
¿Qué es un artefacto? Un artefacto es una construcción ensamblada en la que ya se han completado todas las piezas del ensamblaje. Almacenamos este artefacto en el almacén de artefactos. Hubo un tiempo en que usamos dos de estos almacenamientos: Nexus y ahora jFrog Artifactory). Inicialmente usamos "Nexus" porque comenzamos a practicar este enfoque en aplicaciones Java (se adaptaba bien). Luego pusieron allí algunas de las aplicaciones escritas en PHP; y "Nexus" ya no era adecuado, por lo que elegimos jFrog Artefactory, que puede artefactorizar casi todo. Incluso hemos llegado al punto de que en este repositorio de artefactos almacenamos nuestros propios paquetes binarios que recopilamos para los servidores.
Crecimiento de carga explosiva
Hablamos de cambiar la versión del software. Lo siguiente que tenemos es un aumento explosivo de carga. En este caso probablemente me refiero a que cuando hablo de crecimiento explosivo de la carga no es exactamente lo correcto...
Escribimos un nuevo sistema: está orientado al servicio, está de moda, es hermoso, tiene trabajadores en todas partes, colas en todas partes, asincronía en todas partes. Y en tales sistemas, los datos pueden fluir a través de diferentes flujos. Para la primera transacción, se puede utilizar el primer, tercero, décimo trabajador, para la segunda transacción, el segundo, cuarto, quinto. Y hoy, digamos, por la mañana tienes un flujo de datos que utiliza los primeros tres trabajadores, y por la noche cambia drásticamente y todo utiliza los otros tres trabajadores.
Y aquí resulta que de alguna manera necesitas escalar a los trabajadores, necesitas escalar de alguna manera tus servicios, pero al mismo tiempo evitar la sobrecarga de recursos.
Hemos definido nuestros requisitos. Estos requisitos son bastante simples: que haya descubrimiento de servicios, parametrización: todo es estándar para construir sistemas escalables, excepto un punto: la depreciación de recursos. Dijimos que no estamos dispuestos a amortizar recursos para que los servidores calienten el aire. Tomamos "Cónsul", tomamos "Nomad", que gestiona a nuestros trabajadores.¿Por qué es esto un problema para nosotros? Retrocedamos un poco. Actualmente contamos con alrededor de 70 sistemas de pago detrás de nosotros. Por la mañana, el tráfico pasa por Sberbank, luego Sberbank cae, por ejemplo, y lo cambiamos a otro sistema de pago. Antes de Sberbank teníamos 100 trabajadores, y después necesitamos aumentar drásticamente 100 trabajadores para otro sistema de pago. Y es deseable que todo esto suceda sin participación humana. Porque si hay participación humana, debería haber un ingeniero sentado allí las 24 horas del día, los 7 días de la semana, que solo debería hacer esto, porque este tipo de fallas, cuando hay 70 sistemas detrás de ti, ocurren regularmente.
Por lo tanto, miramos Nomad, que tiene una IP abierta, y escribimos nuestro propio Scale-Nomad - ScaleNo, que hace aproximadamente lo siguiente: monitorea el crecimiento de la cola y reduce o aumenta el número de trabajadores dependiendo de la dinámica. de la cola. Cuando lo hicimos, pensamos: "¿Quizás podamos abrirlo?" Luego la miraron: era tan simple como dos kopeks.
Hasta ahora no lo hemos abierto, pero si de repente después del informe, después de darte cuenta de que necesitas algo así, lo necesitas, mis contactos están en la última diapositiva, escríbeme. Si son al menos 3-5 personas, lo patrocinaremos.
¿Cómo funciona? ¡Echemos un vistazo! De cara al futuro: en el lado izquierdo hay una parte de nuestro monitoreo: esta es una línea, en la parte superior está el tiempo de procesamiento del evento, en el medio está la cantidad de transacciones, en la parte inferior está la cantidad de trabajadores.Si miras, hay un error en esta imagen. En el gráfico superior, uno de los gráficos se bloqueó en 45 segundos: uno de los sistemas de pago dejó de funcionar. Inmediatamente, el tráfico se recuperó en 2 minutos y la cola comenzó a crecer en otro sistema de pago, donde no había trabajadores (no utilizamos recursos, al contrario, los desechamos correctamente). No queríamos calentarnos; había un número mínimo, entre 5 y 10 trabajadores, pero no podían dar abasto.
El último gráfico muestra una “joroba”, lo que simplemente significa que “Skaleno” duplicó esta cantidad. Y luego, cuando el gráfico bajó un poco, lo redujo un poco: el número de trabajadores cambió automáticamente. Así es como funciona esto. Hablamos sobre el punto número 2: "Cómo deshacerse rápidamente de las razones".
Supervisión. ¿Cómo identificar rápidamente el problema?
Ahora el primer punto es "¿Cómo identificar rápidamente el problema?" ¡Supervisión! Debemos entender ciertas cosas rápidamente. ¿Qué cosas debemos entender rápidamente?
¡Tres cosas!- Debemos comprender y comprender rápidamente el rendimiento de nuestros propios recursos.
- Debemos comprender rápidamente las fallas y monitorear el desempeño de los sistemas externos a nosotros.
- El tercer punto es identificar errores lógicos. Aquí es cuando el sistema está funcionando para usted, todo es normal según todos los indicadores, pero algo sale mal.
Probablemente no te diré nada tan interesante aquí. Seré el Capitán Obvio. Buscamos lo que había en el mercado. Tenemos un “zoológico divertido”. Este es el tipo de zoológico que tenemos ahora:
Usamos Zabbix para monitorear el hardware, para monitorear los principales indicadores de los servidores. Usamos Okmeter para bases de datos. Usamos “Grafana” y “Prometheus” para todos los demás indicadores que no se ajustan a los dos primeros, algunos con “Grafana” y “Prometheus”, y otros con “Grafana” con “Influx” y Telegraf.Hace un año queríamos utilizar New Relic. Lo bueno, puede hacer de todo. Pero por mucho que pueda hacer de todo, es muy cara. Cuando crecimos hasta alcanzar un volumen de 1,5 mil servidores, un proveedor se acercó a nosotros y nos dijo: "Concluyamos un acuerdo para el próximo año". Miramos el precio y dijimos que no, no haremos eso. Ahora estamos abandonando New Relic, nos quedan alrededor de 15 servidores bajo el monitoreo de New Relic. El precio resultó ser absolutamente disparatado.
Y hay una herramienta que implementamos nosotros mismos: Debugger. Al principio lo llamamos “Bagger”, pero luego pasó un profesor de inglés, se rió a carcajadas y le cambió el nombre a “Debagger”. ¿Lo que es? Se trata de una herramienta que, de hecho, en 15-30 segundos en cada componente, como una “caja negra” del sistema, ejecuta pruebas sobre el rendimiento general del componente.
Por ejemplo, si hay una página externa (página de pago), simplemente la abre y mira cómo debería verse. Si esto se está procesando, envía una "transacción" de prueba y se asegura de que esta "transacción" llegue. Si se trata de una conexión con sistemas de pago, lanzamos una solicitud de prueba en consecuencia, siempre que podamos, y comprobamos que todo está bien para nosotros.
¿Qué indicadores son importantes para el seguimiento?
¿Qué monitoreamos principalmente? ¿Qué indicadores son importantes para nosotros?
- El tiempo de respuesta/RPS en los frentes es un indicador muy importante. Él inmediatamente responde que algo anda mal contigo.
- El número de mensajes procesados en todas las colas.
- Numero de trabajadores.
- Métricas básicas de corrección.
El último punto es la métrica “negocio”, “negocio”. Si desea monitorear lo mismo, debe definir una o dos métricas que sean sus principales indicadores. Nuestra métrica es el rendimiento (esta es la relación entre el número de transacciones exitosas y el flujo total de transacciones). Si algo cambia en un intervalo de 5-10-15 minutos, significa que tenemos problemas (si cambia radicalmente).
Lo que parece para nosotros es un ejemplo de uno de nuestros tableros:
En el lado izquierdo hay 6 gráficos, esto es según las líneas: la cantidad de trabajadores y la cantidad de mensajes en las colas. En el lado derecho – RPS, RTS. A continuación se muestra la misma métrica de "negocios". Y en la métrica de “negocios” podemos ver inmediatamente que algo salió mal en los dos gráficos del medio... Este es solo otro sistema que está detrás de nosotros y que ha caído.Lo segundo que teníamos que hacer era monitorear la caída de los sistemas de pago externos. Aquí tomamos OpenTracing, un mecanismo, estándar y paradigma que le permite rastrear sistemas distribuidos; y fue cambiado un poco. El paradigma estándar de OpenTracing dice que creamos un seguimiento para cada solicitud individual. No necesitábamos esto y lo envolvimos en un resumen de seguimiento de agregación. Creamos una herramienta que nos permite rastrear la velocidad de los sistemas detrás de nosotros.
El gráfico nos muestra que uno de los sistemas de pago comenzó a responder en 3 segundos: tenemos problemas. Además, esto reaccionará cuando comiencen los problemas, en un intervalo de 20 a 30 segundos.Y la tercera clase de errores de seguimiento que existen es el seguimiento lógico.
Para ser honesto, no sabía qué dibujar en esta diapositiva, porque llevábamos mucho tiempo buscando en el mercado algo que se adaptara a nosotros. No encontramos nada, así que tuvimos que hacerlo nosotros mismos.
¿Qué quiero decir con seguimiento lógico? Bueno, imagina: te creas un sistema (por ejemplo, un clon de Tinder); Lo lograste, lo lanzaste. El exitoso gerente Vasya Pupkin lo puso en su teléfono, ve a una chica allí, le gusta... y lo similar no le llega a la chica, sino al guardia de seguridad Mikhalych del mismo centro de negocios. El gerente baja y se pregunta: "¿Por qué Mikhalych, el guardia de seguridad, le sonríe tan amablemente?".En tales situaciones... Para nosotros, esta situación suena un poco diferente, porque (escribí) se trata de una pérdida de reputación que indirectamente conduce a pérdidas financieras. Nuestra situación es la opuesta: podemos sufrir pérdidas financieras directas, por ejemplo, si realizamos una transacción exitosa pero no tuvo éxito (o viceversa). Tuve que escribir mi propia herramienta que rastrea la cantidad de transacciones exitosas a lo largo del tiempo utilizando indicadores comerciales. ¡No encontré nada en el mercado! Esta es exactamente la idea que quería transmitir. No hay nada en el mercado que solucione este tipo de problema.
Se trataba de cómo identificar rápidamente el problema.
Cómo determinar los motivos del despliegue
El tercer grupo de problemas que solucionamos es después de haber identificado el problema, después de haberlo solucionado, sería bueno entender el motivo del desarrollo, de las pruebas y hacer algo al respecto. En consecuencia, debemos investigar, debemos levantar los troncos.
Si hablamos de registros (la razón principal son los registros), la mayor parte de nuestros registros están en ELK Stack; casi todos tienen los mismos. Para algunos, puede que no esté en ELK, pero si escribe registros en gigabytes, tarde o temprano llegará a ELK. Los escribimos en terabytes.
Hay un problema aquí. Lo arreglamos, corregimos el error del usuario, comenzamos a desenterrar lo que había allí, subimos a Kibana, ingresamos la identificación de la transacción allí y obtuvimos una tela como esta (muestra mucho). Y en esta calza no queda absolutamente nada claro. ¿Por qué? Sí, porque no está claro qué parte pertenece a qué trabajador, qué parte pertenece a qué componente. Y en ese momento nos dimos cuenta de que necesitábamos rastreo, el mismo OpenTracing del que hablé.Pensamos esto hace un año, dirigimos nuestra atención hacia el mercado y allí había dos herramientas: "Zipkin" y "Jaeger". "Jager" es de hecho un heredero ideológico, un sucesor ideológico de "Zipkin". Todo está bien en Zipkin, excepto que no sabe cómo agregar, no sabe cómo incluir registros en el seguimiento, solo el seguimiento del tiempo. Y "Jager" apoyó esto.
Miramos "Jager": puedes instrumentar aplicaciones, puedes escribir en Api (el estándar Api para PHP en ese momento, sin embargo, no estaba aprobado; esto fue hace un año, pero ahora ya se aprobó), pero hay No era absolutamente ningún cliente. “Está bien”, pensamos y le escribimos a nuestro propio cliente. ¿Qué obtuvimos? Esto es más o menos lo que parece:
En Jaeger, se crean intervalos para cada mensaje. Es decir, cuando un usuario abre el sistema, ve uno o dos bloques por cada solicitud entrante (1-2-3: la cantidad de solicitudes entrantes del usuario, la cantidad de bloques). Para hacerlo más fácil para los usuarios, agregamos etiquetas a los registros y seguimientos de tiempo. En consecuencia, en caso de error, nuestra aplicación marcará el registro con la etiqueta de Error adecuada. Puede filtrar por etiqueta de error y solo se mostrarán los tramos que contengan este bloque con un error. Esto es lo que parece si ampliamos el lapso:
En el interior del vano hay un conjunto de huellas. En este caso, se trata de tres rastreos de prueba y el tercer rastreo nos indica que ocurrió un error. Al mismo tiempo, aquí vemos un rastro de tiempo: tenemos una escala de tiempo en la parte superior y vemos en qué intervalo de tiempo se registró tal o cual registro.En consecuencia, las cosas nos fueron bien. Escribimos nuestra propia extensión y la abrimos. Si desea trabajar con el rastreo, si desea trabajar con “Jager” en PHP, existe nuestra extensión, bienvenido a usarla, como dicen:
Tenemos esta extensión: es un cliente para OpenTracing Api, está hecha como extensión php, es decir, deberá ensamblarla e instalarla en el sistema. Hace un año no había nada diferente. Ahora hay otros clientes que son como componentes. Aquí depende de ti: o sacas los componentes con un compositor o usas la extensión, depende de ti.Estándares corporativos
Hablamos de los tres mandamientos. El cuarto mandamiento es estandarizar los enfoques. ¿De qué se trata esto? Se trata de esto:
¿Por qué aparece aquí la palabra “corporativo”? No porque seamos una empresa grande o burocrática, ¡no! Quería utilizar la palabra "corporativo" aquí en el contexto de que cada empresa, cada producto debe tener sus propios estándares, incluido usted. ¿Qué estándares tenemos?
- Contamos con regulaciones de implementación. No vamos a ninguna parte sin él, no podemos. Nos desplegamos unas 60 veces por semana, es decir, lo hacemos casi constantemente. Al mismo tiempo, en el reglamento de despliegue tenemos, por ejemplo, un tabú sobre los despliegues los viernes: en principio, no realizamos despliegues.
- Requerimos documentación. Ni un solo componente nuevo entra en producción si no existe documentación al respecto, incluso si nació bajo la pluma de nuestros especialistas en I+D. Les requerimos instrucciones de implementación, un mapa de monitoreo y una descripción aproximada (bueno, como pueden escribir los programadores) de cómo funciona este componente y cómo solucionarlo.
- No solucionamos la causa del problema, sino el problema, lo que ya dije. Para nosotros es importante proteger al usuario de problemas.
- Tenemos autorizaciones. Por ejemplo, no consideramos tiempo de inactividad si perdemos el 2% del tráfico en dos minutos. Básicamente, esto no está incluido en nuestras estadísticas. Si es más en términos porcentuales o temporal, ya contamos.
- Y siempre escribimos autopsias. Pase lo que pase, cualquier situación en la que alguien se haya comportado de forma anormal en producción se verá reflejada en la autopsia. Una autopsia es un documento en el que escribes lo que te sucedió, un momento detallado, qué hiciste para corregirlo y (¡este es un bloque obligatorio!) qué harás para evitar que esto suceda en el futuro. Esto es obligatorio y necesario para el análisis posterior.
¿Qué se considera tiempo de inactividad?
¿A qué condujo todo esto?Esto llevó al hecho de que (tuvimos ciertos problemas con la estabilidad, esto no nos convenía ni a los clientes ni a nosotros) durante los últimos 6 meses nuestro indicador de estabilidad fue 99,97. Podemos decir que esto no es mucho. Sí, tenemos algo por lo que luchar. De este indicador, aproximadamente la mitad es la estabilidad, por así decirlo, no la nuestra, sino la de nuestro firewall de aplicaciones web, que está frente a nosotros y se utiliza como un servicio, pero a los clientes esto no les importa.
Aprendimos a dormir por la noche. ¡Finalmente! Hace seis meses no pudimos. Y sobre esta nota con los resultados, me gustaría hacer una nota. Anoche hubo un maravilloso informe sobre el sistema de control de un reactor nuclear. Si las personas que escribieron este sistema pueden escucharme, olvídense de lo que dije sobre "el 2% no es tiempo de inactividad". Para usted, el 2 % es tiempo de inactividad, ¡aunque sea de dos minutos!
¡Eso es todo! Tus preguntas.
Acerca de los balanceadores y la migración de bases de datos
Pregunta del público (en adelante – B): – Buenas noches. ¡Muchas gracias por este informe administrativo! Una breve pregunta sobre sus balanceadores. Mencionaste que tienes un WAF, es decir, según tengo entendido, utilizas algún tipo de equilibrador externo...
EK: – No, utilizamos nuestros servicios como equilibrador. En este caso, WAF es exclusivamente para nosotros una herramienta de protección DDoS.
A: – ¿Puedes decir algunas palabras sobre los equilibradores?
EK: – Como ya dije, este es un grupo de servidores en openresty. Ahora tenemos 5 grupos de reserva que responden exclusivamente... es decir, un servidor que ejecuta exclusivamente openresty, solo envía tráfico proxy. En consecuencia, para entender cuánto tenemos: ahora tenemos un flujo de tráfico regular de varios cientos de megabits. Se las arreglan, se sienten bien y ni siquiera se esfuerzan.
A: – También una pregunta sencilla. Aquí está la implementación Azul/Verde. ¿Qué se hace, por ejemplo, con las migraciones de bases de datos?
EK: - ¡Buena pregunta! Mire, en la implementación Azul/Verde tenemos colas separadas para cada línea. Es decir, si hablamos de colas de eventos que se transmiten de trabajador a trabajador, hay colas separadas para la línea azul y para la línea verde. Si hablamos de la base de datos en sí, deliberadamente la reducimos tanto como pudimos, movimos todo prácticamente a colas; en la base de datos solo almacenamos una pila de transacciones. Y nuestra pila de transacciones es la misma para todas las líneas. Con la base de datos en este contexto: no la dividimos en azul y verde, porque ambas versiones del código deben saber qué está pasando con la transacción.
Amigos, también tengo un pequeño premio para animarles: un libro. Y debería recibirlo por la mejor pregunta.
A: - Hola. Gracias por el informe. La pregunta es esta. Usted monitorea los pagos, monitorea los servicios con los que se comunica... Pero, ¿cómo monitorea para que una persona de alguna manera llegue a su página de pago, realice un pago y el proyecto le acredite dinero? Es decir, ¿cómo se controla que el marchante esté disponible y haya aceptado su devolución de llamada?
EK: – “Comerciante” para nosotros en este caso es exactamente el mismo servicio externo que el sistema de pago. Monitoreamos la velocidad de respuesta del comerciante.
Acerca del cifrado de bases de datos
A: - Hola. Tengo una pregunta un poco relacionada. Tiene datos confidenciales PCI DSS. Quería saber cómo se almacenan los PAN en las colas a las que es necesario realizar transferencias. ¿Utiliza algún cifrado? Y esto nos lleva a la segunda pregunta: según PCI DSS, es necesario volver a cifrar periódicamente la base de datos en caso de cambios (despido de administradores, etc.). ¿Qué sucede con la accesibilidad en este caso?
EK: - ¡Maravillosa pregunta! En primer lugar, no almacenamos PAN en colas. En principio, no tenemos derecho a almacenar PAN en ningún lugar de forma clara, por lo que utilizamos un servicio especial (lo llamamos "Kademon"): este es un servicio que hace solo una cosa: recibe un mensaje como entrada y lo envía. enviar un mensaje cifrado. Y almacenamos todo con este mensaje cifrado. Por lo tanto, nuestra longitud de clave es inferior a un kilobyte, por lo que esto es serio y fiable.A: – ¿Necesitas 2 kilobytes ahora?
EK: – Parece que fue ayer 256… Bueno, ¿dónde más?
En consecuencia, este es el primero. Y en segundo lugar, la solución que existe es compatible con el procedimiento de re-cifrado: hay dos pares de "keks" (claves), que dan "mazos" que cifran (las claves son las claves, los dek son derivados de las claves que cifran) . Y si se inicia el procedimiento (ocurre regularmente, desde 3 meses hasta ± algo), descargamos un nuevo par de "tortas" y volvemos a cifrar los datos. Contamos con servicios separados que extraen todos los datos y los cifran de una manera nueva; Los datos se almacenan junto al identificador de la clave con la que se cifran. En consecuencia, tan pronto como ciframos los datos con claves nuevas, eliminamos la clave anterior.
A veces los pagos deben realizarse manualmente...
A: – Es decir, si te ha llegado un reembolso por alguna operación, ¿aun así lo descifrarás con la clave antigua?
EK: - Sí.
A: – Entonces una pequeña pregunta más. Cuando ocurre algún tipo de falla, caída o incidente, es necesario impulsar la transacción manualmente. Existe tal situación.
EK: - Sí a veces.
A: – ¿De dónde sacas estos datos? ¿O vas tú mismo a este almacén?
EK: – No, bueno, por supuesto, tenemos algún tipo de sistema administrativo que contiene una interfaz para nuestro soporte. Si no sabemos en qué estado se encuentra la transacción (por ejemplo, hasta que el sistema de pago respondió con un tiempo de espera), no lo sabemos a priori, es decir, asignamos el estado final solo con total confianza. En este caso, asignamos la transacción a un estado especial para su procesamiento manual. Por la mañana, al día siguiente, tan pronto como el soporte recibe información de que tales o cuales transacciones permanecen en el sistema de pago, las procesan manualmente en esta interfaz.
A: - Tengo un par de preguntas. Uno de ellos es la continuación de la zona PCI DSS: ¿cómo se registra su circuito? ¡Esta pregunta se debe a que el desarrollador podría haber puesto cualquier cosa en los registros! Segunda pregunta: ¿cómo se implementan las revisiones? Usar identificadores en la base de datos es una opción, pero puede haber revisiones gratuitas: ¿cuál es el procedimiento allí? Y la tercera pregunta probablemente esté relacionada con RTO, RPO. Tu disponibilidad era 99,97, casi cuatro nueves, pero según tengo entendido tienes un segundo centro de datos, un tercer centro de datos y un quinto centro de datos... ¿Cómo los sincronizas, los replicas y todo lo demás?EK: - Empecemos por el primero. ¿La primera pregunta fue sobre los registros? Cuando escribimos registros, tenemos una capa que enmascara todos los datos confidenciales. Mira la máscara y los campos adicionales. En consecuencia, nuestros registros aparecen con datos ya enmascarados y un circuito PCI DSS. Esta es una de las tareas habituales asignadas al departamento de pruebas. Deben verificar cada tarea, incluidos los registros que escriben, y esta es una de las tareas habituales durante las revisiones de código, para controlar que el desarrollador no haya escrito algo. El departamento de seguridad de la información realiza controles posteriores periódicamente aproximadamente una vez a la semana: los registros del último día se toman de forma selectiva y se pasan por un escáner-analizador especial de los servidores de prueba para comprobarlo todo.
Acerca de las correcciones urgentes. Esto está incluido en nuestras regulaciones de implementación. Tenemos una cláusula separada sobre revisiones. Creemos que implementamos revisiones las XNUMX horas del día cuando las necesitamos. Tan pronto como se ensambla la versión, tan pronto como se ejecuta, tan pronto como tenemos un artefacto, tenemos un administrador del sistema de turno en una llamada de soporte, y lo implementa en el momento en que es necesario.Sobre los "cuatro nueves". La cifra que tenemos ahora realmente se ha logrado y nos esforzamos por conseguirla en otro centro de datos. Ahora tenemos un segundo centro de datos y estamos comenzando a realizar rutas entre ellos, y la cuestión de la replicación entre centros de datos es realmente una cuestión no trivial. Intentamos resolverlo al mismo tiempo por diferentes medios: intentamos usar la misma "Tarántula"; no funcionó para nosotros, te lo diré de inmediato. Por eso terminamos ordenando los "sens" manualmente. De hecho, cada aplicación de nuestro sistema ejecuta la sincronización necesaria de "cambios realizados" entre centros de datos de forma asincrónica.
A: – Si conseguiste un segundo, ¿por qué no conseguiste un tercero? Porque nadie tiene el cerebro dividido todavía...
EK: – Pero no tenemos Split Brain. Debido a que cada aplicación está controlada por un multimaster, no nos importa a qué centro llegó la solicitud. Estamos preparados para el hecho de que si uno de nuestros centros de datos falla (confiamos en esto) y en medio de una solicitud de usuario cambia al segundo centro de datos, estamos listos para perder a este usuario, de hecho; pero serán unidades, unidades absolutas.
A: - Buenas noches. Gracias por el informe. Hablaste de tu depurador, que ejecuta algunas transacciones de prueba en producción. ¡Pero cuéntanos sobre las transacciones de prueba! ¿A qué profundidad llega?
EK: – Pasa por el ciclo completo de todo el componente. Para un componente, no existe diferencia entre una transacción de prueba y una transacción de producción. Pero desde un punto de vista lógico, esto es simplemente un proyecto separado en el sistema, en el que sólo se ejecutan transacciones de prueba.
A: -¿Dónde lo cortas? Aquí Core envió...
EK: – Estamos detrás de “Kor” en este caso para transacciones de prueba... Tenemos algo llamado enrutamiento: “Kor” sabe a qué sistema de pago enviar: enviamos a un sistema de pago falso, que simplemente da una señal http y eso es todo.
A: – Dígame, por favor, ¿su aplicación fue escrita en un monolito enorme o la dividió en algunos servicios o incluso microservicios?
EK: – No tenemos un monolito, por supuesto, tenemos una aplicación orientada a servicios. Bromeamos diciendo que nuestro servicio está hecho de monolitos; en realidad, son bastante grandes. Es difícil llamarlos microservicios, pero son servicios dentro de los cuales operan los trabajadores de máquinas distribuidas.
Si el servicio en el servidor está comprometido...
A: – Entonces tengo la siguiente pregunta. Incluso si fuera un monolito, aún dijo que tiene muchos de estos servidores instantáneos, todos básicamente procesan datos, y la pregunta es: "En caso de que uno de los servidores instantáneos o una aplicación se vea comprometido, cualquier enlace individual ¿Tienen algún tipo de control de acceso? ¿Cuál de ellos puede hacer qué? ¿A quién debo contactar para obtener qué información?
EK: - Sí definitivamente. Los requisitos de seguridad son bastante serios. En primer lugar, tenemos movimientos de datos abiertos, y los puertos son sólo aquellos a través de los cuales anticipamos de antemano el movimiento del tráfico. Si un componente se comunica con la base de datos (por ejemplo, con Muskul) a través de 5-4-3-2, solo 5-4-3-2 estará abierto y otros puertos y otras direcciones de tráfico no estarán disponibles. Además, debe comprender que en nuestra producción existen alrededor de 10 bucles de seguridad diferentes. E incluso si la aplicación se vio comprometida de alguna manera, Dios no lo quiera, el atacante no podrá acceder a la consola de administración del servidor, porque esta es una zona de seguridad de red diferente.A: – Y en este contexto, lo que es más interesante para mí es que hay ciertos contratos con servicios: qué pueden hacer, a través de qué “acciones” pueden contactarse entre sí... Y en un flujo normal, algunos servicios específicos solicitan algunos fila, una lista de “acciones” en la otra. No parecen recurrir a los demás en una situación normal y tienen otras áreas de responsabilidad. Si uno de ellos se ve comprometido, ¿podrá interrumpir las “acciones” de ese servicio?
EK: - Entiendo. Si en una situación normal con otro servidor se permitiera la comunicación, entonces sí. Según el contrato SLA, no controlamos que solo se le permitan las primeras 3 "acciones" y no se le permitan las 4 "acciones". Probablemente esto sea redundante para nosotros, porque en principio ya disponemos de un sistema de protección de 4 niveles para circuitos. Preferimos defendernos con los contornos, más que a nivel de las entrañas.
Cómo funcionan Visa, MasterCard y Sberbank
A: – Quiero aclarar un punto sobre el cambio de usuario de un centro de datos a otro. Hasta donde yo sé, Visa y MasterCard operan utilizando el protocolo binario síncrono 8583, y hay combinaciones allí. Y quería saber, ahora nos referimos al cambio: ¿es directamente "Visa" y "MasterCard" o antes de los sistemas de pago, antes del procesamiento?
EK: - Esto es antes de las mezclas. Nuestras mezclas están ubicadas en el mismo centro de datos.
A: – En términos generales, ¿tiene un punto de conexión?
EK: – “Visa” y “MasterCard” - sí. Simplemente porque Visa y MasterCard requieren inversiones bastante importantes en infraestructura para celebrar contratos separados para obtener un segundo par de combinaciones, por ejemplo. Están reservados dentro de un centro de datos, pero si, Dios no lo quiera, nuestro centro de datos, donde hay combinaciones para conectarse a Visa y MasterCard, muere, entonces perderemos la conexión con Visa y MasterCard...
A: – ¿Cómo se pueden reservar? ¡Sé que Visa solo permite una conexión en principio!
EK: – Ellos mismos suministran el equipo. En cualquier caso, recibimos equipos que en su interior son totalmente redundantes.
A: – ¿Entonces el stand es de Connects Orange?..
EK: - Sí.
A: – Pero ¿qué pasa con este caso? Si tu centro de datos desaparece, ¿cómo podrás seguir usándolo? ¿O simplemente el tráfico se detiene?
EK: - No. En este caso, simplemente cambiaremos el tráfico a otro canal, lo que, por supuesto, será más caro para nosotros y más caro para nuestros clientes. Pero el tráfico no pasará por nuestra conexión directa a Visa, MasterCard, sino por el Sberbank condicional (muy exagerado).
Pido disculpas sinceras si ofendí a los empleados de Sberbank. Pero según nuestras estadísticas, entre los bancos rusos, Sberbank es el que cae con mayor frecuencia. No pasa un mes sin que algo se caiga en Sberbank.
Algunos anuncios 🙂
Gracias por estar con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más contenido interesante? Apóyanos haciendo un pedido o recomendándonos a amigos, , un análogo único de servidores de nivel de entrada, que fue inventado por nosotros para usted: (disponible con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).
Dell R730xd 2 veces más barato en el centro de datos Equinix Tier IV en Amsterdam? Solo aqui ¡en los Paises Bajos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $99! Leer acerca de
Fuente: habr.com