Esta es la parte final de la serie que describe cómo estamos aumentando la disponibilidad de nuestro servicio en Citymobil (puede leer la parte anterior
aquí ). Ahora voy a hablar sobre otro tipo de interrupciones y las conclusiones que sacamos sobre ellas, cómo modificamos el proceso de desarrollo, qué automatización introdujimos.
1. Mala versión: error
Este es el tipo más desagradable de interrupciones e incidentes. El único tipo que no tiene síntomas visibles además de las quejas de los usuarios finales o usuarios comerciales. Es por eso que tal incidente, especialmente uno pequeño, puede pasar desapercibido en la producción por un tiempo.
Todos los otros tipos de interrupciones son más o menos similares a "Mala versión: 500 errores internos del servidor". Lo único es que no se desencadenan por una versión, sino por una carga de trabajo, operación manual o un problema de servicio externo.
Para describir el método de lidiar con este tipo de interrupciones, debemos recordar un viejo chiste:
Un matemático y un físico tienen la misma tarea: hervir agua. Se les dan algunas herramientas auxiliares: una estufa, un hervidor de agua, un grifo con agua, fósforos. Ambos se turnan para llenar el hervidor con agua, encender el gas y comenzar a calentar el hervidor. Luego la tarea se simplifica: se les da un hervidor de agua, lleno de agua y una estufa que ya está encendida. La tarea es la misma: hervir agua. El físico pone la tetera en la estufa. El matemático vacía la tetera, apaga el gas y dice: "El problema se reduce a uno que ya se ha resuelto". © anekdotov.net
Este tipo de interrupción debe reducirse a "Mala versión: 500 errores internos del servidor" a toda costa. Idealmente, los errores deben registrarse de la misma manera que 500 errores. Sin embargo, por supuesto, no puede registrar el evento de un error porque, si pudiera, no haría un error en primer lugar.
Una de las ideas para rastrear un error es buscar rastros en la base de datos. Estos rastros nos permiten ver que hay un error y enviar alertas. ¿Cómo podemos ayudar a esto? Comenzamos a investigar cada gran error y a encontrar soluciones: ¿qué tipo de monitoreo / alerta por SMS se puede crear para que este error se revele como un error 500 de inmediato? Aquí hay algunos ejemplos.
1.1. Ejemplo de una interrupción causada por un error
De repente, recibíamos una gran cantidad de quejas de nuestros usuarios: los pedidos pagados a través de Apple Pay no podían cerrarse. Comenzamos nuestra investigación; El problema se reprodujo en el entorno de prueba. Se encontró la causa raíz: actualizamos el formato de la fecha de vencimiento de las tarjetas de crédito porque fue modificado por un servicio de procesamiento de pagos, pero no lo hicimos correctamente para los pagos a través de Apple Pay; por lo tanto, todos los pagos de Apple Pay fueron rechazados. Lo arreglamos tan pronto como supimos sobre el problema, lo implementamos y el problema desapareció. Sin embargo, este problema estuvo en vivo durante 45 minutos.
A raíz de este problema, monitoreamos una serie de pagos fallidos de Apple Pay y creamos alertas por SMS e IVR con un umbral distinto de cero (dado que el servicio considera que algunos pagos fallidos son normales; por ejemplo, si un cliente no tiene dinero en su cuenta o su tarjeta de crédito está bloqueada). Desde ese momento, nos enteraríamos inmediatamente del cruce del umbral. Si una nueva versión presenta algún problema en el procesamiento de Apple Pay, lo descubriremos de inmediato debido a la supervisión y revertiremos la liberación en 3 minutos (el proceso de reversión manual se describe en uno de los artículos anteriores). Por lo tanto, solían ser 45 minutos de tiempo de inactividad parcial, y ahora son 3 minutos. Beneficio!
1.2. Otros ejemplos
Un error en la lista de pedidos. Implementamos una optimización de la lista de pedidos en la aplicación del controlador. El código tenía un error. Como resultado, a veces los conductores vieron la lista de pedidos vacía. Descubrimos este error por casualidad: uno de los ingenieros estaba jugando con la aplicación del controlador y se encontró con este problema. Identificamos rápidamente el lanzamiento incorrecto y fue revertido de inmediato. En consecuencia, creamos un gráfico de un número promedio de pedidos en la lista basado en la información de la base de datos. Luego miramos este gráfico retrospectivamente mes a mes. Notamos un barranco reciente causado por ese error y creamos una alerta por SMS a través de una consulta SQL. Construye este gráfico cuando un número promedio de pedidos en la lista cruza el umbral inferior que se estableció en función del mínimo para el mes actual.
Un error en cachback. Estábamos alterando la lógica del sorteo de devolución de dinero del usuario. Entre otras cosas, lo enviamos al grupo de clientes equivocado. Se solucionó el problema, se creó el gráfico de devolución de dinero regalado; vimos un aumento drástico y también notamos que esto nunca antes había sucedido, y creamos una alerta por SMS con un umbral apropiado.
De nuevo un error en los pagos. El nuevo lanzamiento causó el error: tomaría una eternidad hacer un pedido, el pago con tarjeta no funcionaba, los conductores solicitaron a los clientes que pagaran en efectivo. Descubrimos el problema a través de quejas de call center. Implementamos una solución y creamos una alerta para el tiempo de cierre de pedidos con umbrales, descubiertos mediante análisis de gráficos históricos.
Como puede ver, estamos utilizando el mismo enfoque para hacer frente a todos los incidentes de este tipo:
- Nos enteramos de un problema.
- Lo solucionamos y encontramos un error en el código.
- Lo arreglamos
- Descubrimos los rastros en la base de datos (también se pueden encontrar rastros en los registros del servidor web o Kibana) que pueden señalar los signos del problema.
- Construimos un gráfico de estos rastros.
- Retrocedemos en el tiempo y observamos los altibajos en el gráfico.
- Seleccionamos un buen umbral para una alerta.
- Cuando el problema surge nuevamente, nos enteramos de inmediato a través de una alerta por SMS.
Lo bueno de este método: un gráfico y una alerta resuelven todo el gran grupo de problemas (ejemplos de grupos de problemas: los pedidos no se pueden cerrar, las bonificaciones adicionales, los pagos de Apple Pay no pasan, etc.)
Finalmente, implementamos alertas y monitoreo para cada gran error como parte de nuestra cultura de ingeniería. Para no perder esta cultura, la formalizamos solo un poco. Comenzamos a obligarnos a crear un informe para cada interrupción. El informe es un formulario lleno de respuestas a las siguientes preguntas: causa raíz, cómo lo solucionamos, impacto comercial, conclusiones. Todos los campos son obligatorios. Entonces, tuvimos que concluir si nos gustó o no. Este cambio de proceso obviamente se escribió en lo que se debe hacer y lo que no.
2. Kotan
Nuestro nivel de automatización de procesos estaba aumentando, y decidimos que era hora de crear una interfaz web que mostrara el estado actual del proceso de desarrollo. Llamamos a esta interfaz web "Kotan" (de la palabra rusa "roll", "roll out" :-)
"Kotan" tiene la siguiente funcionalidad:
Lista de incidentes . Contiene la lista de todos los activados en alertas pasadas, lo que requiera una reacción humana inmediata. Para cada incidente registramos la hora en que comenzó, la hora en que terminó (si ya terminó), el enlace a un informe (si el incidente terminó y hay un informe) y el enlace de la guía de alertas para ver qué tipo de alerta este incidente pertenece a
El directorio de alertas . Esta es prácticamente una lista de todas las alertas. Para aclararlo, la diferencia entre una alerta y un incidente es la siguiente: la alerta es como una clase, mientras que el incidente es un objeto. Por ejemplo, "la cantidad de 500 errores es mayor que 1" es la alerta. Y "el número de 500 errores es mayor que 1 y ocurrieron en esta fecha, en este momento, duraron tanto", es un incidente. Cada alerta se agrega al sistema manualmente a través del proceso descrito anteriormente después de que se resuelve un problema específico que nunca antes ha sido detectado por el sistema de alerta. Tal enfoque iterativo garantiza un bajo riesgo de alertas falsas positivas (que no requieren ninguna acción). El directorio contiene un historial de informes completo para cada tipo de alerta; eso ayuda a diagnosticar un problema más rápido: recibe una alerta, va a "Kotan", hace clic en el Directorio, revisa todo el historial y tiene una idea sobre dónde bucear. Una clave para una solución de problemas exitosa es tener toda la información a la mano. El enlace al código fuente de la alerta (para saber con certeza de qué situación se trata esta alerta). Una descripción escrita de los mejores métodos actuales para combatir esta alerta.
Informes Estos son todos los informes en la historia. Cada informe tiene enlaces para todos los incidentes con los que está asociado (a veces los incidentes vienen en grupos; la causa raíz es la misma, y creamos un informe para todo el grupo), la fecha en que se escribió este informe, el indicador de confirmación de la solución del problema y la mayoría importante: la causa raíz, cómo se solucionó, el impacto en los negocios, las conclusiones.
Lista de comida para llevar . Cada conclusión tiene una nota que indica si se ha implementado, si la implementación aún está por llegar o si no es necesaria (con una explicación de por qué no).
3. ¿Qué ha cambiado en el proceso de desarrollo de software?
Un componente crítico de la mejora de la disponibilidad es un proceso de desarrollo de software. El proceso está cambiando constantemente. El objetivo de tales cambios es disminuir la posibilidad de incidentes. Las decisiones para enmendar el proceso no deben tomarse de manera abstracta, sino que deben basarse en la experiencia, los hechos y los números. El proceso no debe construirse de manera direccional hacia abajo, sino de abajo hacia arriba con la participación activa de todos los miembros del equipo, ya que muchos jefes de todo el equipo son mejores que un jefe de un gerente. El proceso debe ser seguido y monitoreado; de lo contrario, no tiene sentido tenerlo. Los miembros del equipo deben corregirse entre sí en caso de divergencia: ¿quién más lo haría por ellos? Debe haber una automatización máxima cuidando las funciones principales, ya que un humano comete errores constantemente, especialmente en el trabajo creativo.
Para estar seguros de que cada incidente tiene resultados, hemos hecho lo siguiente:
- Cada alerta bloquea automáticamente los lanzamientos.
- Cuando recibimos una alerta de cierre (un mensaje de texto que indica que el incidente ha terminado), no desbloqueamos los comunicados de inmediato, sino que nos ofrecen crear un informe sobre el accidente.
- Un informe debe contener la siguiente información: la causa raíz de un accidente, cómo se solucionó, el impacto comercial, las conclusiones.
- El informe fue escrito por el equipo que resolvió el problema. Los armados con la información completa sobre el accidente.
- Las versiones se bloquean automáticamente hasta que se crea y aprueba dicho informe. Eso motiva al equipo a concentrarse rápidamente y crear un informe justo después de que se solucione un accidente.
- El informe debe ser aprobado por alguien que no esté en el equipo, para asegurarse de que contiene toda la información necesaria para comprenderlo.
Al hacerlo, nosotros, por un lado, logramos autodisciplina para guardar cada incidente en la historia, y por otro, proporcionamos un control automatizado. Ahora es imposible no sacar conclusiones o no escribir un informe.
4. En lugar de un epílogo
En lugar de un epílogo, permítanme resumir rápidamente lo que cambiamos en el proceso de desarrollo de software para disminuir una cantidad de viajes perdidos.
Gracias por leer hasta el final. ¡Buena suerte a tu negocio! ¡Le deseo menos pedidos perdidos, transacciones, compras, viajes y todo lo que sea crucial para usted!