Este es un segundo artículo de una serie "Citymobil: un manual para mejorar la disponibilidad en medio del crecimiento del negocio para las nuevas empresas". Puedes leer la primera parte
aquí . Sigamos hablando sobre la forma en que logramos mejorar la disponibilidad de los servicios de Citymobil. En el primer artículo, aprendimos a contar los viajes perdidos. Ok, los estamos contando. Que ahora Ahora que estamos equipados con una herramienta comprensible para medir los viajes perdidos, podemos pasar a la parte más interesante: ¿cómo disminuimos las pérdidas? ¡Sin frenar nuestro crecimiento actual! Dado que nos parecía que la mayor parte de los problemas técnicos que causaban la pérdida de viajes tenían algo que ver con el backend, decidimos centrar nuestra atención en el proceso de desarrollo del backend primero. Saltando por delante de mí mismo, voy a decir que teníamos razón: el backend se convirtió en el sitio principal de la batalla por los viajes perdidos.
1. Cómo funciona el proceso de desarrollo
Los problemas generalmente son causados por la implementación del código y otras acciones manuales. Los servicios que nunca se cambian y se tocan a mano a veces también funcionan mal, sin embargo, esa es una excepción que solo prueba la regla.
En mi experiencia, la excepción más interesante e inusual fue la siguiente. En 2006, cuando trabajaba en uno de los pequeños servicios de correo web, había una puerta de enlace que representaba todo el tráfico y se aseguraba de que las direcciones IP no estuvieran en las listas negras. El servicio funcionó en FreeBSD y funcionó bien. Pero un día simplemente dejó de funcionar. Adivina por qué? El disco en esta máquina falló (los bloques defectuosos se habían estado formando durante un tiempo y sucedió lo inevitable) y sucedió tres años antes de la falla del servicio. Todo estaba vivo con el disco fallido. Y luego FreeBSD, por razones que solo él conoce, de repente decidió abordar el disco fallido y se detuvo como resultado.
Cuando era un niño, de 10 a 12 años, fui de excursión al bosque con mi padre y escuché una frase de él que nunca olvidé: "todo lo que necesitas hacer para mantener encendida la hoguera es no tocarla". Creo que la mayoría de nosotros podemos recordar una situación en la que alimentamos un poco de madera al fuego que ya ardía y se apagaría sin motivo.
La conclusión es que los problemas son creados por las acciones manuales de los humanos; por ejemplo, cuando alimenta madera a la hoguera que ya está bien encendida, corta el oxígeno y mata el fuego o despliega el código con errores en la producción. Por lo tanto, para comprender qué causa los problemas de los servicios, debemos comprender cómo funciona el proceso de implementación y desarrollo.
En Citymobil, el proceso estuvo totalmente orientado al desarrollo rápido y organizado de la siguiente manera:
- 20-30 lanzamientos por día.
- Los desarrolladores realizan la implementación por sí mismos.
- Pruebas rápidas en el entorno de prueba por parte del desarrollador.
- Pruebas mínimas automatizadas / unitarias, revisión mínima.
Los desarrolladores trabajaron en condiciones difíciles sin soporte de control de calidad, con un flujo enorme de tareas muy importantes del equipo de producto y experimentos; trabajaron tan intensa y consistentemente como pudieron, resolvieron tareas difíciles de una manera simple, se aseguraron de que el código no se convirtiera en espagueti, entendieron las problemáticas comerciales, trataron los cambios de manera responsable y rápidamente hicieron retroceder lo que no funcionaba. No hay nada nuevo aquí. Hubo una situación similar en el servicio Mail.Ru hace 8 años cuando comencé a trabajar allí. Iniciamos
Mail.ru Cloud de forma rápida y fácil, sin preludio. Estaríamos cambiando nuestro proceso en el futuro para lograr una mejor disponibilidad.
Apuesto a que te habrás dado cuenta de ti mismo: cuando no hay barreras prohibidas, cuando solo eres tú y la producción, cuando llevas una gran carga de responsabilidad, estás haciendo maravillas. He tenido una experiencia así. Hace mucho tiempo era prácticamente el único desarrollador en el servicio de correo web Newmail.Ru (fue adquirido hace un tiempo y luego retirado);
if (!strcmp(username, "danikin")) { … some code… } despliegue por mí mismo y realicé pruebas de producción también en mí mismo a través de
if (!strcmp(username, "danikin")) { … some code… } . Entonces, estaba familiarizado con esta situación.
No me sorprendería descubrir que un enfoque tan "rápido y sucio" ha sido utilizado por muchas startups exitosas y no exitosas, pero todas impulsadas por una pasión: el deseo de un rápido crecimiento del negocio y una cuota de mercado.
¿Por qué Citymobil tuvo ese proceso? Para empezar, había muy pocos desarrolladores. Llevaban un tiempo trabajando para la empresa y conocían muy bien el código y los negocios. El proceso funcionó idealmente bajo esas condiciones.
2. ¿Por qué apareció la amenaza de disponibilidad?
El crecimiento de las inversiones en el desarrollo de productos causado por nuestros planes de productos se volvió más agresivo y comenzamos a contratar más desarrolladores. El número de implementaciones por día estaba aumentando, pero naturalmente su calidad disminuyó ya que los nuevos muchachos tuvieron que sumergirse en el sistema y los negocios en condiciones de campo. El aumento en el número de desarrolladores resultó no solo en lineal, sino también en una caída cuadrática de la disponibilidad (el número de implementaciones creció linealmente y la calidad de una implementación promedio disminuyó linealmente, por lo que "linear" * "linear" = "quadratic").
Obviamente, no podríamos seguir así. El proceso simplemente no fue construido para estas nuevas condiciones. Sin embargo, tuvimos que modificarlo sin comprometer el tiempo de comercialización; es decir, mantener entre 20 y 30 lanzamientos por día (teniendo en cuenta que su número crecería a medida que crezca el equipo). Crecimos rápidamente, realizamos muchos experimentos, evaluamos rápidamente los resultados y realizamos nuevos experimentos. Probamos rápidamente hipótesis de productos y negocios, aprendimos de ellas e hicimos nuevas hipótesis que probamos nuevamente de inmediato y así sucesivamente. Bajo ninguna circunstancia nos detendríamos. Además, queríamos acelerar y contratar desarrolladores más rápido. Por lo tanto, nuestras acciones dirigidas al crecimiento empresarial crearon una amenaza de disponibilidad, pero no teníamos ninguna intención de modificar estas acciones.
3. Ok, la tarea está establecida, el proceso es claro. Que sigue
Tener una experiencia de trabajo en el servicio de correo electrónico Mail.Ru y Mail.Ru Cloud, donde la disponibilidad en algún momento se había convertido en la prioridad número uno, donde las implementaciones se llevaban a cabo una vez por semana, donde todo estaba cubierto por pruebas automatizadas y unitarias y el el código fue revisado al menos una vez, pero a veces incluso tres veces, me enfrenté a una situación totalmente diferente.
Uno pensaría que todo era bastante simple: podríamos replicar el proceso de correo electrónico / nube Mail.Ru en Citymobil, aumentando así la disponibilidad del servicio. Sin embargo, como dicen, el diablo está en los detalles:
- las implementaciones en Mail.Ru email / cloud se realizan una vez por semana, no 30 veces al día; en Citymobil no queríamos sacrificar la cantidad de lanzamientos;
- en Mail.Ru email / cloud, el código está cubierto por prueba automática / unidad y no teníamos ni tiempo ni recursos para eso en Citymobil; Lanzamos todo nuestro esfuerzo de desarrollo de backend a hipótesis y pruebas de mejora del producto.
Dicho esto, fuimos cortos en términos de desarrolladores de back-end, a pesar de que fueron contratados rápidamente (un agradecimiento especial a los reclutadores de Citymobil, ¡los mejores reclutadores del mundo! Creo que habrá un artículo separado sobre nuestro proceso de reclutamiento) , por lo que no había manera de que pudiéramos abordar los problemas de prueba y revisión sin disminuir la velocidad.
4. Cuando no sabes qué hacer, aprende de los errores
Entonces, ¿qué es tan mágico que hemos hecho en Citymobil? Decidimos aprender de los errores. El método de mejora del servicio de aprender de los errores es tan antiguo como el tiempo. Si el sistema funciona bien, está bien. Si el sistema no funciona bien, también es bueno ya que podemos aprender de los errores. Es más fácil decirlo que ... En realidad, también se puede hacer fácilmente. La clave es establecer una meta.
Como aprendimos Primero, comenzamos a escribir religiosamente la información sobre cada corte, grande y pequeño. Para ser honesto, al principio no tenía ganas de hacerlo, ya que esperaba un milagro y pensé que las interrupciones se detendrían por sí mismas. Obviamente, nada se detenía. La nueva realidad exigió sin piedad algunos cambios.
Comenzamos a registrar todos los cortes en una tabla de Google Docs. Para cada corte hubo la siguiente información breve:
- fecha, hora, duración;
- la causa raíz
- qué se hizo para solucionar el problema;
- impacto en el negocio (número de viajes perdidos, otros resultados);
- comida para llevar
Para cada gran interrupción, creamos un archivo grande separado con una descripción detallada minuto a minuto desde el momento en que comenzó la interrupción hasta el momento en que terminó: qué hicimos, qué decisiones se tomaron. Por lo general, se llama autopsia. Agregaríamos los enlaces a estas autopsias en la tabla general.
Había una razón para crear dicho archivo: llegar a conclusiones que tuvieran como objetivo disminuir el número de viajes perdidos. Era muy importante ser muy específico acerca de cuál es "la causa raíz" y cuáles son "las conclusiones". El significado de estas palabras es claro; sin embargo, todos pueden entenderlos de manera diferente.
5. Ejemplo de una interrupción que hemos aprendido de
La causa raíz es un problema que debe corregirse para evitar tales accidentes en el futuro. Y conclusiones: las formas de eliminar la causa raíz o reducir la probabilidad de su resurgimiento.
La causa raíz es siempre más profunda de lo que parece ser. Las conclusiones son siempre más complicadas de lo que parecen ser. Nunca debería estar satisfecho con la causa raíz supuestamente encontrada y nunca estar satisfecho con supuestas declaraciones, para que no se relaje y pare en lo que parece correcto. Esta insatisfacción crea una chispa para su posterior análisis.
Permíteme darte un ejemplo del mundo real: implementamos código, todo se cayó, lo revertimos, todo volvió a funcionar. ¿Cuál es la causa raíz del problema? Dirías:
Despliegue. Si no hubiera implementado el código, entonces no habría habido un accidente. Entonces, ¿cuál es la conclusión: no más implementaciones? Esa no es una muy buena comida para llevar. Entonces, muy probablemente, esa no fue la causa raíz, necesitamos profundizar más.
Despliegue con un error. Esa es la causa raíz? De acuerdo ¿Cómo lo arreglamos? Dirías por las pruebas. ¿Qué tipo de prueba? Por ejemplo: prueba de regresión completa de toda la funcionalidad. Esta es una buena comida para llevar, recordemos. Pero necesitamos aumentar la disponibilidad aquí y ahora antes de implementar la prueba de regresión completa. Necesitamos cavar aún más profundo.
Implementación con un error causado por la impresión de depuración en la tabla de la base de datos; sobrecargamos la base de datos y se cayó bajo carga. Eso suena mejor Ahora quedó claro que incluso la prueba de regresión completa no nos salvará de este problema. Dado que no habrá una carga de trabajo en la base de datos de prueba similar a la carga de trabajo de producción.
¿Cuál es la causa raíz de este problema, si profundizamos aún más? Tuvimos que hablar con los ingenieros para averiguarlo. Resultó que el ingeniero se acostumbró a que la base de datos pudiera manejar cualquier carga de trabajo. Sin embargo, debido al rápido crecimiento de la carga de trabajo, la base de datos no podía en ese momento manejar lo que manejó el día anterior. Muy pocos de nosotros tuvimos la oportunidad de trabajar para los proyectos con una tasa de crecimiento del 50% mensual. Para mí, por ejemplo, ese fue el primer proyecto como ese. Después de sumergirse en un proyecto como ese, comienza a comprender nuevas realidades. Nunca sabrás que está ahí afuera hasta que lo encuentres.
El ingeniero ideó la forma correcta de solucionarlo: la impresión de depuración debe realizarse en un archivo que debe escribirse a través de un script cron en la base de datos en un hilo. En caso de que haya demasiada impresión de depuración, la base de datos no caerá; los datos de depuración simplemente aparecerán tarde o temprano. Este ingeniero obviamente ha aprendido de su error y no lo volverá a cometer. Pero otros ingenieros también deberían saber sobre eso. Como? Necesitan que se les diga. ¿Cómo hacerlos escuchar? Al contarles toda la historia de principio a fin, exponiendo las consecuencias y proponiendo una forma correcta de hacerlo; y también, escuchando y respondiendo sus preguntas.
6. ¿Qué más podemos aprender de este error o "qué hacer y qué no hacer".
Ok, sigamos analizando esta interrupción. La compañía está creciendo rápidamente, están llegando nuevos ingenieros. ¿Cómo van a aprender de este error? ¿Deberíamos decirle a cada nuevo ingeniero al respecto? Obviamente, habrá más y más errores: ¿cómo hacemos que todos aprendan de ellos? La respuesta es casi clara: cree un archivo de qué hacer y qué no hacer. Vamos a escribir todas las conclusiones en este archivo. Mostramos este archivo a todos nuestros nuevos ingenieros y también a todos nuestros ingenieros actuales en un chat de grupo de trabajo cada vez que se actualiza lo que se debe y no se debe hacer, instando a todos a leerlo nuevamente (para repasar la información anterior y ver el uno nuevo).
Se podría decir que no todos leerán atentamente. Se podría decir que la mayoría lo olvidará justo después de leer. Y tendría razón en ambas cuentas. Sin embargo, no puedes negar el hecho de que algo se quedará en la cabeza de alguien. Y eso es lo suficientemente bueno. En la experiencia de Citymobil, los ingenieros toman muy en serio este archivo y las situaciones en que se olvidaron algunas lecciones ocurrieron muy raramente. El hecho mismo de que la lección haya sido olvidada puede verse como un problema; Debemos sacar una conclusión y analizar los detalles para descubrir la forma de cambiar algo en el futuro. Este tipo de excavación conduce a redacciones más precisas y precisas sobre qué hacer y qué no hacer.
La conclusión de la interrupción descrita anteriormente: crea un archivo de qué hacer y qué no hacer; escriba todo lo que hemos aprendido en él, muestre el archivo a todo el equipo, solicite a cada recién llegado que lo estudie y aliente a las personas a hacer preguntas.
Consejo general que derivamos de la revisión de la interrupción: no deberíamos usar una combinación de palabras "sucede una mierda". Tan pronto como lo diga en voz alta, todos deciden que no se necesita hacer nada, no se necesitan conclusiones, ya que los humanos siempre han cometido errores, están cometiendo errores ahora y los cometerán en el futuro. Por lo tanto, en lugar de decir esa frase, debe hacer
una conclusión específica. Una conclusión: tal vez sea un paso pequeño, pero sigue siendo un paso hacia la dirección de la mejora del proceso de desarrollo, los sistemas de monitoreo y las herramientas automatizadas. ¡Estos pequeños pasos dan como resultado un servicio más estable!
7. En lugar de epílogo
En otras partes, hablaré sobre los tipos de interrupciones en la experiencia de Citymobil y entraré en detalles sobre cada tipo de interrupción; También le contaré sobre las conclusiones que sacamos sobre las interrupciones, cómo modificamos el proceso de desarrollo, qué automatización introdujimos. Estén atentos!