Citymobil: una gu铆a para nuevas empresas para aumentar la estabilidad en medio del crecimiento. Parte 2. 驴Cu谩les son los tipos de accidentes?



Este es el segundo art铆culo de una serie sobre c贸mo nosotros en Citymobil aumentamos la estabilidad del servicio (puede leer el primero aqu铆 ). En este art铆culo, profundizar茅 en los detalles del an谩lisis de accidentes. Pero antes de eso, cubrir茅 un punto que ten铆a que pensar de antemano y cubrir en el primer art铆culo, pero no lo pens茅. Y sobre lo que aprend铆 de los comentarios de los lectores. El segundo art铆culo me da la oportunidad de eliminar este molesto defecto.

0. Pr贸logo


Uno de los lectores hizo una pregunta muy justa: "驴Qu茅 es dif铆cil en el backend de un servicio de taxi?" La pregunta es buena. Me pregunt茅 a m铆 mismo el verano pasado antes de comenzar a trabajar en Citymobil. Entonces pens茅 "pensar, un taxi, una aplicaci贸n con tres botones". 驴Qu茅 podr铆a ser complicado al respecto? Pero result贸 que este es un servicio de muy alta tecnolog铆a y un producto complejo. Para al menos dejar en claro de qu茅 se trata y qu茅 es realmente un gran coloso tecnol贸gico, hablar茅 sobre varias 谩reas de las actividades de productos de Citymobil:

  • Precios. El equipo de fijaci贸n de precios se ocupa de los problemas de precios en cada punto y en cualquier momento. El precio se determina prediciendo el equilibrio de la oferta y la demanda en base a estad铆sticas y otros datos. Todo esto hace un servicio grande, complejo y en constante evoluci贸n basado en el aprendizaje autom谩tico.
  • Precios. La implementaci贸n de varios m茅todos de pago, la l贸gica de los recargos despu茅s del viaje, la retenci贸n de fondos en tarjetas bancarias, facturaci贸n, interacci贸n con socios y conductores.
  • Distribuci贸n de pedidos. 驴A qu茅 m谩quina distribuir el pedido de ventas? Por ejemplo, la opci贸n de distribuci贸n para el m谩s cercano no es la mejor en t茅rminos de aumentar el n煤mero de viajes. Una opci贸n m谩s correcta es comparar clientes y autom贸viles de tal manera que se maximice el n煤mero de viajes, dada la probabilidad de cancelaci贸n por parte de este cliente en particular en estas condiciones (porque lleva mucho tiempo) y la cancelaci贸n o sabotaje del pedido por parte de este conductor (porque toma demasiado tiempo o demasiado bajo verificar).
  • Geo. Todo lo relacionado con la b煤squeda y recepci贸n de direcciones, puntos de aterrizaje, ajuste del tiempo de entrega (nuestros socios, proveedores de tarjetas y atascos de tr谩fico no siempre brindan informaci贸n precisa sobre ETA, teniendo en cuenta los atascos de tr谩fico), mejorando la precisi贸n de la geocodificaci贸n directa e inversa, mejorando la precisi贸n de la m谩quina. Hay mucho trabajo con datos, muchos an谩lisis, muchos servicios basados 鈥嬧媏n aprendizaje autom谩tico.
  • Antifraude La diferencia en el precio de un viaje para un pasajero y para un conductor (por ejemplo, en viajes cortos) crea un incentivo econ贸mico para los estafadores que intentan robar nuestro dinero. Combatir el fraude es algo similar a combatir el spam en el servicio de correo electr贸nico: la integridad y la precisi贸n son importantes. Es necesario bloquear el n煤mero m谩ximo de estafadores (integridad), pero los buenos usuarios no deben confundirse con los estafadores (precisi贸n).
  • Motivaci贸n de los conductores. El equipo de motivaci贸n del conductor se dedica al desarrollo de todo lo relacionado con aumentar el uso de nuestra plataforma por parte de los conductores y la lealtad del conductor debido a varios tipos de motivaci贸n. Por ejemplo, haz viajes X y obt茅n rublos Y adicionales para esto. O compre un turno por Z rublos y viaje sin comisi贸n.
  • Aplicaci贸n de controlador de fondo. Una lista de pedidos, un mapa de demanda (una pista de d贸nde ir al conductor para maximizar sus ingresos), cambios de estado de prokidyvaniya, un sistema de comunicaci贸n con conductores y mucho m谩s.
  • El backend de la aplicaci贸n del cliente (esta es probablemente la parte m谩s obvia y lo que generalmente se entiende por el backend de un taxi): hacer pedidos, desplazarse por los estados sobre cambiar el estado del pedido, garantizar el movimiento de los autom贸viles en el mapa en el pedido y en la entrega, consejos de back-end y etc.

Esta es toda la punta del iceberg. La funcionalidad es mucho m谩s. La interfaz f谩cil de usar oculta una gran parte submarina del iceberg.

Y ahora volviendo a los accidentes. Durante los seis meses de historia de accidentes, hemos compilado la siguiente categorizaci贸n:

  • lanzamiento pobre, errores 500;
  • lanzamiento deficiente, c贸digo sub贸ptimo, carga en la base;
  • intervenci贸n manual fallida en el sistema;
  • huevo de pascua
  • causas externas;
  • lanzamiento deficiente, funcionalidad rota.

A continuaci贸n, escribir茅 qu茅 conclusiones hicimos sobre los tipos m谩s comunes de accidentes.

1. Mala versi贸n, errores 500


Casi todo nuestro backend est谩 escrito en PHP, un lenguaje interpretado con escritura d茅bil. Sucede que despliega el c贸digo y se bloquea debido a un error en el nombre de la clase o funci贸n. Y este es solo un ejemplo cuando aparece el error n煤mero 500. Tambi茅n puede aparecer en caso de un error l贸gico en el c贸digo; lam铆 la rama equivocada; borr贸 accidentalmente la carpeta con el c贸digo; dej贸 en el c贸digo los artefactos temporales necesarios para la prueba; no cambi贸 la estructura de las tablas de acuerdo con el nuevo c贸digo; no reinici贸 ni detuvo los scripts cron necesarios.

Luchamos con este problema secuencialmente en varias etapas. Los viajes perdidos debido a una mala liberaci贸n son obviamente proporcionales al tiempo que estuvo en uso. Es decir, debemos hacer todo lo posible para garantizar que una versi贸n deficiente funcione lo menos posible. Cualquier cambio en el proceso de desarrollo que reduzca el tiempo promedio que se tarda en utilizar una versi贸n incorrecta en al menos 1 segundo es positivo para la empresa y debe implementarse.

Una mala liberaci贸n o cualquier accidente de producci贸n generalmente pasa por dos estados, que llamamos "etapa pasiva" y "etapa activa". La etapa pasiva es cuando a煤n no nos damos cuenta del accidente. La etapa activa es cuando ya estamos en el saber. El accidente comienza en la etapa pasiva y, con el tiempo, cuando nos damos cuenta, el accidente pasa a la etapa activa: comenzamos a combatirlo: primero lo diagnosticamos y luego lo reparamos.

Para reducir la duraci贸n de cualquier accidente en la producci贸n, es necesario reducir la duraci贸n promedio de las etapas pasiva y activa. Lo mismo ocurre con un mal lanzamiento, porque es en s铆 mismo una especie de accidente.

Comenzamos a analizar nuestro proceso actual de reparaci贸n de accidentes. Los lanzamientos incorrectos que encontramos en el momento del inicio del an谩lisis dieron como resultado un promedio inactivo (total o parcial) de 20-25 minutos. La etapa pasiva usualmente toma 15 minutos, la activa 10 minutos. Durante la fase pasiva, las quejas de los usuarios comenzaron a ser procesadas por el centro de contacto, y despu茅s de cierto umbral, el centro de contacto se quej贸 de chats generales en Slack. A veces, uno de los empleados se quejaba cuando no pod铆a pedir un taxi. Una queja de los empleados fue una se帽al para nosotros sobre un problema grave. Despu茅s de la transici贸n de una mala versi贸n a la etapa activa, comenzamos a diagnosticar el problema, analizamos las 煤ltimas versiones, varios gr谩ficos y registros para determinar la causa del accidente. Despu茅s de descubrir la raz贸n, revertimos el c贸digo si la versi贸n incorrecta se bombe贸 por 煤ltima vez, o hicimos una nueva reversi贸n con una confirmaci贸n de lanzamiento incorrecta inversa.

Aqu铆 hay un proceso para lidiar con lanzamientos malos, tuvimos que mejorar.

1.1. Reducci贸n de etapa pasiva


En primer lugar, notamos que si una versi贸n deficiente est谩 acompa帽ada de 500 errores, entonces podemos entender sin quejas que ha ocurrido un problema. Afortunadamente, todos los errores n煤mero 500 se registraron en New Relic (este es uno de los sistemas de monitoreo que usamos), y solo quedaba para atornillar las notificaciones de SMS e IVR sobre el exceso de una cierta frecuencia de "quinientos" (con el tiempo, el umbral se redujo constantemente).

Esto llev贸 al hecho de que la etapa activa del accidente, como "Mala versi贸n, errores n煤mero 500", comenz贸 casi inmediatamente despu茅s de la liberaci贸n. El proceso en caso de accidente comenz贸 a verse as铆:

  1. El programador implementa el c贸digo.
  2. El lanzamiento lleva a un accidente (500 masivos).
  3. SMS llega.
  4. Los programadores y administradores comienzan a entender (a veces no de inmediato, pero despu茅s de 2-3 minutos: los SMS pueden retrasarse, el sonido en el tel茅fono puede apagarse y la cultura de acciones inmediatas despu茅s de SMS no puede aparecer en un d铆a).
  5. Comienza la fase activa del accidente, que dura los mismos 10 minutos que antes.

Por lo tanto, la etapa pasiva se redujo de 15 minutos a 3.

1.2. Reducci贸n adicional de la etapa pasiva.


A pesar de la reducci贸n de la etapa pasiva a 3 minutos, incluso una etapa pasiva tan corta nos molest贸 m谩s que la activa, porque durante la etapa activa ya hacemos algo para resolver el problema, y 鈥嬧媎urante la etapa pasiva el servicio no funciona en su totalidad o en parte, pero " los hombres no lo saben ".

Para reducir a煤n m谩s la etapa pasiva, decidimos sacrificar tres minutos de tiempo de desarrollador despu茅s de cada lanzamiento. La idea era muy simple: despliega el c贸digo y mira New Relic, Sentry, Kibana durante tres minutos para ver si hay 500 errores. Tan pronto como vea un problema all铆, a priori asume que est谩 relacionado con su c贸digo y comienza a comprender.

Elegimos tres minutos en funci贸n de las estad铆sticas: a veces aparec铆an problemas en los gr谩ficos con un retraso de 1-2 minutos, pero nunca hab铆a m谩s de tres minutos.

Esta regla se registr贸 en lo que se debe y no se debe hacer. Al principio no siempre se ejecut贸, pero gradualmente los desarrolladores se acostumbraron a la regla como higiene elemental: cepillarse los dientes por la ma帽ana tambi茅n es una p茅rdida de tiempo, pero debe hacerlo.

Como resultado, la etapa pasiva se redujo a 1 minuto (los horarios todav铆a llegaban tarde a veces). Como sorpresa agradable, esto simult谩neamente redujo la etapa activa. Despu茅s de todo, el desarrollador encuentra un problema en buena forma y est谩 listo para deshacer inmediatamente su c贸digo. Aunque esto no siempre ayuda, porque El problema podr铆a haber surgido debido al c贸digo de otra persona que se estaba implementando en paralelo. Pero, sin embargo, la etapa activa en promedio se redujo a 5 minutos.

1.3. Reducci贸n adicional en la etapa activa


M谩s o menos satisfechos con un minuto de la etapa pasiva, comenzamos a pensar en una reducci贸n adicional en la etapa activa. En primer lugar, prestamos atenci贸n a la historia de los problemas (隆es la piedra angular en la construcci贸n de nuestra estabilidad!) Y descubrimos que en muchos casos no retrocedemos inmediatamente porque no entendemos a qu茅 versi贸n retroceder, porque hay muchas versiones paralelas. Para resolver este problema, presentamos la siguiente regla (y la registramos en lo que se debe y no se debe hacer): antes del lanzamiento, escribes en el chat en Slack, para qu茅 est谩s rodando y qu茅, y en caso de accidente, escribes en el chat "隆accidente, no ruedes!". Adem谩s, comenzamos a informar autom谩ticamente por SMS sobre los hechos de la publicaci贸n para notificar a aquellos que no entran al chat.

Esta simple regla redujo dr谩sticamente el n煤mero de liberaciones ya durante los accidentes y redujo la etapa activa, de 5 minutos a 3.

1.4. Una reducci贸n a煤n mayor en la etapa activa


A pesar del hecho de que advertimos en el chat sobre todos los lanzamientos y bloqueos, a veces aparec铆an condiciones de carrera: uno escribi贸 sobre el lanzamiento y el otro ya se lanz贸 en ese momento; o cuando comenz贸 el accidente, escribieron sobre eso en el chat, y alguien acaba de lanzar un nuevo c贸digo. Estas circunstancias alargaron el diagn贸stico. Para resolver este problema, implementamos una prohibici贸n autom谩tica de versiones paralelas. La idea es muy simple: despu茅s de cada versi贸n, el sistema CI / CD proh铆be que todos se lancen durante los pr贸ximos 5 minutos, excepto el autor de la 煤ltima versi贸n (para que pueda lanzar o hacer hotfix si es necesario) y varios desarrolladores especialmente experimentados (en caso de emergencia). Adem谩s, el sistema CI / CD proh铆be el despliegue durante un accidente (es decir, desde el momento de la recepci贸n de la notificaci贸n del comienzo del accidente hasta el momento de la recepci贸n de la notificaci贸n de su finalizaci贸n).

Por lo tanto, el proceso se hizo as铆: el desarrollador implementa, monitorea los gr谩ficos durante tres minutos, y despu茅s de eso durante dos minutos m谩s, nadie puede implementar nada. Si hay un problema, entonces el desarrollador revierte la versi贸n. Esta regla simplific贸 radicalmente el diagn贸stico, y la duraci贸n total de las etapas activa y pasiva disminuy贸 de 3 + 1 = 4 minutos a 1 + 1 = 2 minutos.

Pero dos minutos del accidente son muchos. Por lo tanto, continuamos optimizando el proceso.

1.5. Detecci贸n autom谩tica de fallas y reversi贸n


Hemos estado pensando durante mucho tiempo c贸mo reducir la duraci贸n del accidente debido a las bajas emisiones. Incluso intentaron obligarse a mirar en la tail -f error_log | grep 500 tail -f error_log | grep 500 . Pero al final, todos se decidieron por una soluci贸n cardinal autom谩tica.

En resumen, este es un retroceso autom谩tico. Configuramos un servidor web separado, en el que cargamos 10 veces menos carga del equilibrador que en otros servidores web. Cada versi贸n fue implementada autom谩ticamente por el sistema CI / CD en este servidor separado (lo llamamos preprod, aunque, a pesar del nombre, la carga real de los usuarios reales fue all铆). Y luego la automatizaci贸n hizo tail -f error_log | grep 500 tail -f error_log | grep 500 . Si no se produjo el error n煤mero 500 en un minuto, el CI / CD despleg贸 el nuevo c贸digo en producci贸n. Si aparecieron errores, el sistema inmediatamente revierte todo. Al mismo tiempo, en el nivel de equilibrador, todas las solicitudes completadas con 500 errores en el preprod se duplicaron en uno de los servidores de producci贸n.

Esta medida redujo el efecto de las quinientas versiones a cero. Al mismo tiempo, en caso de errores en la automatizaci贸n, no cancelamos la regla durante tres minutos para monitorear los gr谩ficos. Eso se trata de malas versiones y errores n煤mero 500. Pasamos al siguiente tipo de accidente.

2. Lanzamiento incorrecto, c贸digo sub贸ptimo, carga base


Comenzar茅 de inmediato con un ejemplo concreto de un accidente de este tipo. Implementamos la optimizaci贸n: agregamos USE INDEX a la consulta SQL, durante la prueba de estas consultas cortas aceleradas, como en la producci贸n, pero las consultas largas se ralentizaron. La desaceleraci贸n de las consultas largas solo se not贸 en la producci贸n. Como resultado, el flujo de solicitudes largas puso a toda la base maestra durante una hora. Entendimos completamente c贸mo funciona USE INDEX , lo describimos en el archivo de hacer y no hacer, y advertimos a los desarrolladores contra el mal uso. Tambi茅n analizamos la consulta y nos dimos cuenta de que devuelve principalmente datos hist贸ricos, lo que significa que se puede ejecutar en una r茅plica separada para consultas hist贸ricas. Incluso si esta r茅plica se encuentra bajo carga, el negocio no se detendr谩.

Despu茅s de este incidente, todav铆a nos encontramos con problemas similares, y en alg煤n momento decidimos abordar el problema sistem谩ticamente. Escaneamos todo el c贸digo con un peine frecuente y realizamos a la r茅plica todas las solicitudes que se pueden realizar all铆 sin comprometer la calidad del servicio. Al mismo tiempo, dividimos las r茅plicas de acuerdo con los niveles de criticidad para que la ca铆da de cualquiera de ellas no detuviera el servicio. Como resultado, llegamos a una arquitectura que tiene las siguientes bases:

  • base maestra (para operaciones de escritura y para consultas que son supercr铆ticas para la actualizaci贸n de datos);
  • r茅plica de producci贸n (para consultas cortas que son un poco menos cr铆ticas para la actualizaci贸n de datos);
  • r茅plica para calcular las relaciones de precios, el llamado aumento de precios. Esta r茅plica puede retrasarse entre 30 y 60 segundos: esto no es cr铆tico, los coeficientes cambian con poca frecuencia y si esta r茅plica cae, el servicio no se detendr谩, solo los precios no coincidir谩n con el equilibrio de la oferta y la demanda;
  • r茅plica para el panel de administraci贸n de usuarios comerciales y el centro de contacto (si cae, el negocio principal no aumentar谩, pero el soporte no funcionar谩 y no podremos ver ni cambiar la configuraci贸n temporalmente);
  • muchas r茅plicas para an谩lisis;
  • Base de datos MPP para an谩lisis pesados 鈥嬧媍on cortes completos seg煤n datos hist贸ricos.

Esta arquitectura nos dio m谩s espacio para el crecimiento y redujo el n煤mero de bloqueos en un orden de magnitud debido a consultas SQL sub贸ptimas. Pero ella todav铆a est谩 lejos de ser ideal. Planea hacer sharding para que puedas escalar actualizaciones y eliminaciones, as铆 como consultas cortas supercr铆ticas para la actualizaci贸n de estos datos. El margen de seguridad de MySQL no es infinito. Pronto necesitaremos artiller铆a pesada en forma de Tarantool. 隆Sobre esto ser谩 necesario en los siguientes art铆culos!

En el proceso de la prueba con c贸digo y solicitudes no 贸ptimos, nos dimos cuenta de lo siguiente: es mejor eliminar cualquier falta de optimizaci贸n antes del lanzamiento, y no despu茅s. Esto reduce el riesgo de un accidente y el tiempo dedicado por los desarrolladores a la optimizaci贸n. Porque si el c贸digo ya se ha descargado y hay nuevas versiones adem谩s, es mucho m谩s dif铆cil de optimizar. Como resultado, introdujimos una verificaci贸n de c贸digo obligatoria para la optimizaci贸n. Lo llevan a cabo los desarrolladores m谩s experimentados, de hecho, nuestras fuerzas especiales.

Adem谩s, comenzamos a recopilar en do's & dont's los mejores m茅todos de optimizaci贸n de c贸digo que funcionan en nuestras realidades, se enumeran a continuaci贸n. Por favor, no perciban estas pr谩cticas como una verdad absoluta y no intenten repetirlas ciegamente en ustedes mismos. Cada m茅todo tiene sentido solo para una situaci贸n espec铆fica y un negocio espec铆fico. Aqu铆 se dan solo por ejemplo, para que los detalles sean claros:

  • Si la consulta SQL no depende del usuario actual (por ejemplo, un mapa de demanda de controladores que indique las tasas de viajes m铆nimos y coeficientes para pol铆gonos), entonces esta consulta debe ser realizada por cron con cierta frecuencia (en nuestro caso, una vez por minuto es suficiente). Escriba el resultado en el cach茅 (Memcached o Redis), que ya se usa en el c贸digo de producci贸n.
  • Si la consulta SQL funciona con datos cuya acumulaci贸n no es cr铆tica para el negocio, entonces su resultado debe almacenarse en cach茅 con algunos TTL (por ejemplo, 30 segundos). Y luego, en solicitudes posteriores, leer desde el cach茅.
  • Si en el contexto del procesamiento de una solicitud en la web (en nuestro caso, en el contexto de la implementaci贸n de un m茅todo de servidor espec铆fico en PHP) desea realizar una consulta SQL, debe asegurarse de que estos datos no hayan "llegado" con ninguna otra consulta SQL (y si llegar谩n m谩s lejos por c贸digo). Lo mismo se aplica al acceso a la memoria cach茅: tambi茅n se puede inundar con solicitudes si lo desea, por lo tanto, si los datos ya han "llegado" de la memoria cach茅, entonces no es necesario que vaya a la memoria cach茅 como a su hogar y la retire, que ya est谩 quitada.
  • Si en el contexto del procesamiento de consultas en la web desea llamar a alguna funci贸n, debe asegurarse de que no se realizar谩n consultas SQL adicionales ni acceso a la cach茅 en sus menudillos. Si llamar a una funci贸n de este tipo es inevitable, debe asegurarse de que no se pueda modificar o que su l贸gica se rompa para no realizar consultas innecesarias en las bases de datos / cach茅s.
  • Si a煤n necesita ingresar a SQL, debe asegurarse de que no puede agregar los campos necesarios m谩s altos o m谩s bajos en el c贸digo a las consultas que ya existen en el c贸digo.

3. Intervenci贸n manual fallida en el sistema


Ejemplos de tales accidentes: un ALTER sin 茅xito (que sobrecarg贸 la base de datos o provoc贸 un retraso de la r茅plica) o DROP sin 茅xito (se encontr贸 con un error en MySQL, bloque贸 la base de datos cuando se dej贸 caer una nueva tabla); fuerte solicitud de un maestro hecho por error a mano; Realizamos trabajo en el servidor bajo carga, aunque pensamos que no ten铆a trabajo.

Para minimizar las ca铆das por estos motivos, es necesario, desafortunadamente, comprender la naturaleza del accidente cada vez. Todav铆a no hemos encontrado la regla general. De nuevo, prueba los ejemplos. Digamos que, en alg煤n momento, los coeficientes de sobretensi贸n dejaron de funcionar (multiplican el precio del viaje en el lugar y momento de mayor demanda). La raz贸n fue que en la r茅plica de la base de datos, de donde provienen los datos para calcular los coeficientes, el script Python funcion贸, que se comi贸 toda la memoria, y la r茅plica se cay贸. El script se ha estado ejecutando durante mucho tiempo, funcion贸 en una r茅plica solo por conveniencia. El problema se resolvi贸 reiniciando el script. Las conclusiones fueron las siguientes: no ejecute scripts de terceros en una m谩quina con una base de datos (grabada en hacer y no hacer, de lo contrario, es un tiro en blanco!), Monitoree el final de la memoria en una m谩quina con una r茅plica y alerta por SMS si la memoria se agota pronto.

Es muy importante sacar siempre conclusiones y no caer en una situaci贸n c贸moda "vieron un problema, lo solucionaron y lo olvidaron". Un servicio de calidad solo se puede construir si se extraen conclusiones. Adem谩s, las alertas por SMS son muy importantes: establecen la calidad del servicio en un nivel superior al que ten铆an, evitan que se caiga y mejoran a煤n m谩s la confiabilidad. Como escalador de cada estado estable, se levanta y queda fijo en otro estado estable, pero a mayor altitud.

Monitorear y alertar con ganchos de hierro invisibles pero r铆gidos cortan la roca de la incertidumbre y nunca nos dejan caer por debajo del nivel de estabilidad que establecemos, que constantemente elevamos solo.

4. huevo de pascua


Lo que llamamos el "huevo de Pascua" es una bomba de tiempo que ha existido durante mucho tiempo, pero que no hemos encontrado. Fuera de este art铆culo, este t茅rmino se refiere a una caracter铆stica no documentada hecha a prop贸sito. En nuestro caso, esto no es una caracter铆stica en absoluto, sino m谩s bien un error, pero que funciona como una bomba de tiempo y que es un efecto secundario de las buenas intenciones.

Por ejemplo: desbordamiento de 32 bits auto_increment ; no optimidad en el c贸digo / configuraci贸n, "disparo" debido a la carga; r茅plica retrasada (generalmente debido a una solicitud sub贸ptima de una r茅plica que se activ贸 por un nuevo patr贸n de uso, o una carga m谩s alta, o debido a una ACTUALIZACI脫N sub贸ptima en el maestro que fue llamado por un nuevo patr贸n de carga y carg贸 la r茅plica).

Otro tipo popular de huevo de Pascua es el c贸digo no 贸ptimo y, m谩s espec铆ficamente, la consulta SQL no 贸ptima. Anteriormente, la tabla era m谩s peque帽a y la carga era menor: la consulta funcion贸 bien. Y con el aumento de la tabla, lineal en el tiempo y el crecimiento de la carga, lineal en el tiempo, el consumo de recursos DBMS creci贸 de forma cuadr谩tica. Por lo general, esto lleva a un efecto negativo agudo: todo estaba "bien" y explosi贸n.

Los escenarios m谩s raros son una combinaci贸n de insectos y huevos de pascua. Un lanzamiento con un error provoc贸 un aumento en el tama帽o de la tabla o un aumento en el n煤mero de registros en una tabla de cierto tipo, y un huevo de Pascua ya existente caus贸 una carga excesiva en la base de datos debido a consultas m谩s lentas a esta tabla demasiado grande.

Aunque, tambi茅n tuvimos huevos de Pascua, no relacionados con la carga. Por ejemplo, auto increment 32 bits: despu茅s de dos y algunos miles de millones de registros en la tabla, las inserciones dejan de realizarse. Por lo tanto, el campo de auto increment en el mundo moderno debe hacerse de 64 bits. Aprendimos bien esta lecci贸n.

驴C贸mo lidiar con los huevos de Pascua? La respuesta es simple: a) busque "huevos" viejos yb) evite que aparezcan nuevos. Intentamos cumplir ambos puntos. La b煤squeda de viejos "huevos" en nuestro pa铆s est谩 asociada con la optimizaci贸n constante del c贸digo. Identificamos a dos de los desarrolladores m谩s experimentados para la optimizaci贸n casi a tiempo completo. Encuentran en slow.log consultas que consumen la mayor铆a de los recursos de la base de datos, optimizan estas consultas y el c贸digo que las rodea. Reducimos la probabilidad de nuevos huevos al verificar el c贸digo de optimizaci贸n de cada confirmaci贸n por parte del sensei rezrabotchiki mencionado anteriormente. Su tarea es se帽alar errores que afectan el rendimiento; decirle c贸mo hacerlo mejor y transferir conocimientos a otros desarrolladores.

En alg煤n momento despu茅s del siguiente huevo de pascua que encontramos, nos dimos cuenta de que buscar consultas lentas es bueno, pero valdr铆a la pena buscar consultas que parezcan lentas pero que funcionen r谩pido. Estos son solo los pr贸ximos candidatos para poner todo en caso de un crecimiento explosivo de la siguiente tabla.

5. Causas externas


Estas son razones que creemos que est谩n mal controladas por nosotros. Por ejemplo:

  • Trote por Google Maps. Puede evitarlo monitoreando el uso de este servicio, observando un cierto nivel de carga, planificando el crecimiento de la carga por adelantado y comprando la expansi贸n del servicio.
  • La ca铆da de la red en el centro de datos. Puede moverse colocando una copia del servicio en el centro de datos de respaldo.
  • Accidente de servicio de pago. Puede omitir la reserva de servicios de pago.
  • Bloqueo de tr谩fico err贸neo por parte del servicio de protecci贸n DDoS. Puede moverse deshabilitando el servicio de protecci贸n DDoS predeterminado y habilit谩ndolo solo en caso de un ataque DDoS.

Dado que eliminar una causa externa es una tarea larga y costosa (por definici贸n), acabamos de comenzar a recopilar estad铆sticas sobre accidentes debido a causas externas y esperar la acumulaci贸n de masa cr铆tica. No existe una receta para determinar la masa cr铆tica. Simplemente funciona la intuici贸n. Por ejemplo, si estuvi茅ramos 5 veces en tiempo de inactividad completo debido a problemas, por ejemplo, del servicio de control DDoS, entonces con cada pr贸xima ca铆da se volver谩 cada vez m谩s agudo para plantear la cuesti贸n de una alternativa.

Por otro lado, si de alguna manera puede hacer que funcione con un servicio externo inaccesible, entonces definitivamente lo hacemos. Y esto nos ayuda a realizar an谩lisis post-mortem de cada oto帽o. Siempre debe haber una conclusi贸n. Eso significa que siempre quieres-no-quieres, pero puedes encontrar una soluci贸n alternativa.

6. Mala versi贸n, funcionalidad rota


Este es el tipo de accidente m谩s desagradable. El 煤nico tipo de accidente que no es visible por ning煤n s铆ntoma que no sean las quejas de usuarios / negocios. Por lo tanto, tal accidente, especialmente si no es grande, puede pasar desapercibido en la producci贸n durante mucho tiempo.

Todos los otros tipos de accidentes son m谩s o menos similares a "mala liberaci贸n, errores n煤mero 500". Es solo que el disparador no es una liberaci贸n, sino una carga, una operaci贸n manual o un problema del lado de un servicio externo.

Para describir el m茅todo de tratar este tipo de accidente, es suficiente recordar una an茅cdota barbuda:

A las matem谩ticas y la f铆sica se les ofreci贸 la misma tarea: hervir una tetera. Se entregan herramientas auxiliares: estufa, hervidor de agua, grifo con agua, f贸sforos. Ambos vierten agua alternativamente en el hervidor, encienden el gas, lo encienden y encienden el hervidor. Luego la tarea se simplific贸: se propuso una tetera llena de agua y una estufa con gas ardiente. El objetivo es el mismo: hervir agua. El f铆sico prende fuego a la tetera. El matem谩tico vierte agua de la tetera, apaga el gas y dice: "La tarea se ha reducido a la anterior". anekdotov.net

Este tipo de accidente debe reducirse por todos los medios a "mala liberaci贸n, errores n煤mero 500". Idealmente, si los errores en el c贸digo se guardaron en el registro como un error. Bueno, o al menos dej贸 rastros en la base de datos. A partir de estos rastros, puede comprender que se ha producido un error e inmediatamente alertar. 驴C贸mo contribuir a esto? Comenzamos a analizar cada error importante y ofrecer soluciones, qu茅 tipo de monitoreo / alerta de SMS se puede hacer para que este error se manifieste inmediatamente de la misma manera que el error n煤mero 500.

6.1. Ejemplo


Hubo quejas masivas: los pedidos pagados a trav茅s de Apple Pay no se cierran. Comenzaron a entender, el problema se repiti贸. Encontramos la raz贸n: realizamos mejoras en el formato de expire date de las tarjetas bancarias al interactuar con la adquisici贸n, como resultado de lo cual comenzaron a transferirlo espec铆ficamente para pagos a trav茅s de Apple Pay en el formato que se esperaba del servicio de procesamiento de pagos (de hecho, uno es tratable, mutilar algo m谩s), por lo que todos los pagos a trav茅s de Apple Pay comenzaron a declinar. R谩pidamente arreglado, desplegado, el problema desapareci贸. Pero "vivieron" con el problema durante 45 minutos.

Siguiendo los rastros de este problema, monitoreamos el n煤mero de pagos fallidos a trav茅s de Apple Pay, y tambi茅n realizamos una alerta SMS / IVR con un umbral distinto de cero (porque los pagos fallidos son la norma desde el punto de vista del servicio, por ejemplo, el cliente no tiene dinero en la tarjeta o la tarjeta est谩 bloqueada) . A partir de este momento, cuando se supera el umbral, aprendemos instant谩neamente sobre el problema. Si la nueva versi贸n presenta CUALQUIER problema en el procesamiento de Apple Pay, lo que conducir谩 a la inoperancia del servicio, incluso parcial, lo aprenderemos de inmediato a partir del monitoreo y revertiremos la versi贸n en tres minutos (se describe anteriormente c贸mo funciona el proceso de laminaci贸n manual). Fueron 45 minutos de tiempo de inactividad parcial, se convirtieron en 3 minutos. Ganancia

6.2. Otros ejemplos


Lanzamos la optimizaci贸n de la lista de pedidos ofrecidos a los conductores. Un error se desliz贸 en el c贸digo. Como resultado, los conductores en algunos casos no vieron la lista de pedidos (estaba vac铆a). Descubrieron el error por accidente: uno de los empleados examin贸 la solicitud del conductor. Retrocedi贸 r谩pidamente. Como conclusi贸n del accidente, hicimos un gr谩fico del n煤mero promedio de pedidos en la lista de controladores de acuerdo con la base de datos, observamos el gr谩fico retroactivamente durante un mes, vimos una falla all铆 e hicimos una alerta por SMS para la consulta SQL, que forma este gr谩fico cuando el n煤mero promedio de pedidos en la lista debajo del umbral seleccionado en funci贸n del m铆nimo hist贸rico del mes.

Cambi贸 la l贸gica de dar devoluci贸n de dinero a los usuarios para los viajes. Incluido distribuido al grupo de usuarios incorrecto. Solucionamos el problema, construimos un calendario de devoluciones de efectivo entregados, vimos un fuerte aumento all铆, tambi茅n vimos que nunca hab铆a habido tal crecimiento, hicimos una alerta por SMS.

Con el lanzamiento, se rompi贸 la funcionalidad de cerrar las 贸rdenes (la orden se cerr贸 para siempre, el pago con tarjetas no funcion贸, los conductores exigieron el pago en efectivo de los clientes). El problema fue de 1,5 horas (etapas total pasiva y activa). Aprendimos sobre el problema del centro de contacto de quejas. Hicieron una correcci贸n, monitorearon y alertaron sobre el tiempo de cierre de las 贸rdenes con umbrales encontrados en el estudio de gr谩ficos hist贸ricos.

Como puede ver, el enfoque para este tipo de accidente es siempre el mismo:

  1. Lanza el lanzamiento.
  2. Aprende sobre el problema.
  3. Arreglarlo
  4. Determinamos qu茅 rastros (en la base de datos, registros, Kiban) puede encontrar los signos del problema.
  5. Trazamos estos signos.
  6. Lo rebobinamos hacia el pasado y observamos las explosiones / ca铆das.
  7. Seleccionamos el umbral correcto para la alerta.
  8. Cuando surge un problema nuevamente, nos enteramos de inmediato a trav茅s de una alerta.

Lo bueno de este m茅todo: una gran clase de problemas se cierra de inmediato con un gr谩fico y una alerta (ejemplos de clases de problemas: no cierre de pedidos, bonos adicionales, falta de pago a trav茅s de Apple Pay, etc.).

Con el tiempo, hemos creado alertas y monitoreo para cada error importante como parte de la cultura de desarrollo. Para evitar que esta cultura se pierda, la formalizamos un poco. Para cada accidente, comenzaron a exigir un informe de ellos mismos. Un informe es un formulario completo con respuestas a las siguientes preguntas: causa ra铆z, m茅todo de eliminaci贸n, impacto en el negocio, conclusiones. Todos los art铆culos son obligatorios. Por lo tanto, si lo quieres o no, escribir谩s las conclusiones. Este cambio de proceso, por supuesto, fue escrito por do's & dont's.

7. Kotan


, , -, . - ( , ) 芦禄. 芦禄. :-)

芦禄 :

. 鈥 , . , ( ), ( ) , . ( , ).

. , . , : 鈥 , 鈥 . , 芦 500- 1 %禄 鈥 . 芦 500- 1 %, - , - , - 禄 鈥 . , . ( ). , : , 芦禄, , , , . 鈥 . ( , ). .

. . , ( , , ), , : , , , .

. , , ( , ).

8. ?


鈥 . . : , . , , . , , , .. 鈥 , 鈥 ! , . , , ? , , .. , , .

. . ( , ), , : , , , . , , . . . -, , . , , , 鈥 : .

9.


, .

??
.
.
( ) post-mortem.
.
do's & dont's.
, , .
, 5 .
.
, .
.
.
.

.
.
.
.
.
SMS/IVR- .
.
( ) .
.
.
- .
( 鈥 slow.log).
- 芦 禄.
.
.
.
.
.
, , .
芦禄 鈥 .
, .
.
.

, ! , , , , !

Source: https://habr.com/ru/post/445704/


All Articles