Durante trece años hemos estado buscando formas de escalar el desarrollo para que todo funcione de manera confiable a medida que crece y, al mismo tiempo, se lanzan nuevas funciones rápidamente. Una vez pareció importante cambiar fácilmente el nombre de las columnas en una base de datos. Ahora, tuve que cambiar toda la arquitectura sobre la marcha.
Esta es la tercera publicación anual de desarrollo del Black Friday, la semana pico. ¿Por qué finalmente pensamos que somos geniales? lo que hicieron por esto; por qué encontramos dificultades y qué planeamos hacer a continuación.
Resumen: dos años de trabajo por una buena razón
Por quinto año consecutivo, la carga en Mindbox aproximadamente se duplica anualmente. En noviembre de 2020, procesamos 8.750 millones de solicitudes de API, en comparación con los 4.480 millones del año anterior. El pico es de 400 mil solicitudes por minuto. Envió 1,64 mil millones de correos electrónicos y 440 millones de notificaciones móviles. Hace un año, había 1.100 millones de correos electrónicos, pero casi no había mensajes push.
Dinámica del número de envíos por semana del Black Friday:
según nuestros datos, esto es comparable al nivel de carga de hh.ru para solicitudes de API, en términos de carga en bases de datos, con Avito. Aproximadamente un tercio de Yandex-taxi en solicitudes por minuto.
En 2018 y 2019A lo largo de los años, lo hemos abordado mal: los clientes sufrieron rechazos. A fines de 2018, esperaba mejoras rápidas y esperaba una hoja de ruta comercial, que hasta ahora solo se ha completado a medias. En 2019, decidí guardar silencio sobre la hoja de ruta, ya que la confiabilidad se deterioró, las fallas comenzaron en septiembre, y el Black Friday se repitieron, a pesar de la gran cantidad de trabajo realizado.
Hoy podemos concluir: hemos aprendido a afrontar el crecimiento. El Black Friday 2020 transcurrió sin incidentes que afectaran a más de un cliente. Hubo dos fallas parciales a corto plazo debido a infraestructura externa que no violó el SLA. Desafortunadamente, hubo quejas de varios de los clientes más importantes, pero estas son historias únicas que entendemos y estamos trabajando en ellas.
Además, los datos y las opiniones subjetivas de los usuarios muestran una tendencia a largo plazo de aumentar la calidad del desarrollo. Se reduce el número de defectos (errores críticos, fallas y casos de desempeño insatisfactorio).
El gráfico muestra violaciones del SLA interno (más estricto que el externo), que además hicimos aún más estricto este año:
Número de violaciones del SLA interno por un cliente promedio
Logramos “reinventar” completamente el desarrollo en dos años, continuando creciendo a una tasa promedio del 40% de los ingresos por año (en 2019 - 431 millones, en 2020 - 618 millones) y lanzando nuevas funciones. Feelings: sobre cómo cambiar el motor de un automóvil a toda velocidad.
Qué se ha hecho en dos años:
- (LESS) , , .
- 50% , ( ) .
- SRE. SRE .
- , , .
- SLA .
- «-», .
Esto está lejos de todo lo planeado. Seguimos aumentando la cantidad de recursos destinados a la calidad. Esperamos más mejoras de calidad y un lanzamiento más rápido de nuevas funciones en 2021 y más allá.
Por cierto, escribimos regularmente sobre las actualizaciones del producto y mantenemos una página de estado con el historial de incidentes .
El origen de las dificultades: 2008-2018
Mindbox es un producto con una lógica de negocio compleja, desde 2008 nos hemos desarrollado como un servicio para grandes empresas, con una participación de los costos de desarrollo superior al 30%. Desde un punto de vista arquitectónico, era una aplicación monolítica tradicional, pero de muy alta calidad: todos los días lanzamos y seguimos lanzando varias actualizaciones monolíticas.
En 2014, el mercado nos hizo girar hacia un segmento más masivo, incluido el comercio electrónico y el retail. Esto requirió una inversión en servicio al cliente, ventas y marketing.
La empresa nunca ha atraído inversiones externas, siempre se ha desarrollado para su propio beneficio. Además, en 2017, seis meses después de convertirme en CEO, enfrentamos la falta de dinero, me asusté y aumenté en exceso mis márgenes de ganancia. Todo esto condujo a una reducción en los costos de desarrollo al 24% de los ingresos en 2018-2019.
Al mismo tiempo, fue necesario lanzar muchas funciones necesarias para los nuevos clientes, con un rápido aumento en la carga y el número de clientes. Hicimos frente a la acumulación del producto y la arquitectura originales, así como a la descentralización: la formación de equipos de productos autónomos.
Desafortunadamente, la experiencia técnica de dichos equipos no siguió el ritmo del crecimiento de la empresa, que se vio agravado por los límites de lo posible en la arquitectura monolítica. La deuda tecnológica se estaba acumulando, la tecnología utilizada estaba desactualizada y los salarios estaban por debajo del mercado. La contratación de ingenieros se ha vuelto cada vez más difícil, a pesar de los desafiantes desafíos y la cultura única de la empresa. Para 2018, la cantidad de clientes había crecido 10 veces, el éxito del producto se hizo evidente, así como los problemas de confiabilidad y desarrollo en general.
Que medidas hemos tomado
Procesos y recursos
La primera hipótesis fue la centralización: en 2019, se introdujo LESS, esto es cuando varios equipos están trabajando en un proyecto al mismo tiempo. Comenzamos a diseñar épicas en conjunto y a trabajar con confiabilidad, logramos aumentar la previsibilidad y encontrar prácticas de diseño útiles. Sin embargo, al cabo de un año, la ineficiencia del proceso se hizo evidente: desmotivación y reducción de responsabilidad de los equipos por la falta de sentido de "sus" características, altos costos de gestión, que a nadie le gustaba hacer.
Más de un año de diseño colaborativo, surgió una visión de una arquitectura descentralizada que permitiría a cada equipo ser responsable de microservicios aislados mientras continuaba entregando un único producto a los clientes. Junto con la visión, surgieron retrasos de tareas y se hizo evidente que era necesario trabajar en la infraestructura con especialistas dedicados, sin interrumpirla con una hoja de ruta empresarial.
Acordamos asignar el 30% de los recursos para deuda técnica de manera continua. Se formó el primer equipo de infraestructura y se comenzaron a asignar de nuevo equipos autónomos. Al mismo tiempo, se han conservado una serie de procesos de colaboración centralizados, principalmente destinados a mantener la calidad:
- diseño,
- análisis de defectos,
- modelando la carga en hierro,
- estados de demostración y sincronización.
Asumimos la responsabilidad de arquitectos y equipos de métricas de confiabilidad y proyecciones de costos de servidores. Además, asignamos el 30% en cada equipo para la deuda técnica y los errores, mientras esperamos la continuidad del negocio.
En 2020, los procesos se asentaron: se formó un segundo equipo de infraestructura, se ajustó la entrega. La proporción de recursos para tareas comerciales comenzó a crecer lentamente desde un punto bajo de alrededor del 50%, y la proporción de errores comenzó a disminuir:
Asignación de recursos de desarrollo por tareas. El gráfico no es muy informativo, ya que se estableció una métrica confiable hace relativamente poco tiempo, pero se ve reforzada por las impresiones del
campo.Durante este tiempo, aprendimos cómo contratar e incorporar SRE, los separamos de DevOps y la TI de la oficina, formamos procesos de trabajo y describimos el rol.
La escasez de ingenieros se redujo de dos formas:
- Creamos una escuela de desarrollo que gradúa de 8 a 12 desarrolladores junior al año. Estos son desarrolladores que tienen experiencia con nuestra pila, en cuyas habilidades confiamos. Hoy, la escuela tiene 2 equipos de 4 aprendices.
- Aumentamos sistemáticamente la nómina para el desarrollo, ya que los resultados del negocio lo permitían. El salario promedio en desarrollo ha crecido de 120 mil rublos en 2015 a más de 170 a fines de 2020 y continúa creciendo. Esto nos permitió reclutar nuevos líderes tecnológicos y seniors fuertes. La participación de los costos de desarrollo aumentó al 28% y el número de personas aumentó de 27 a 64.
Métricas, métricas y métricas automáticas
En nuestra cultura, es costumbre gestionar por datos, no por opinión personal. Las métricas efectivas son quizás una de las preguntas difíciles a las que las metodologías modernas de gestión del desarrollo no dan una respuesta directa.
Comenzamos automatizando cuatro métricas del libro Accelerate y acelerando el proceso de entrega. Esto no tuvo efectos obvios inmediatos. Pero el intercambio de experiencias con hh.ru y Yandex-cloud nos llevó a la automatización de la métrica de violación de SLA y al establecimiento automático de defectos. Aquí sentimos claramente el beneficio y la conexión con los esfuerzos que se están realizando. El gráfico de esta métrica con una tendencia está al comienzo de la publicación.
Discreto, pero creo que somos una de las pocas empresas en el mundo que tiene una API para clientes que te permite obtener una métrica de la disponibilidad de los componentes de la plataforma en tiempo real.
La métrica descrita anteriormente para la proporción de errores y la deuda técnica en el equipo también parece útil. Además, consideramos cómo los equipos cumplen las promesas dadas para el sprint y los desarrolladores cumplen los plazos para las tareas diarias y semanales.
Finalmente, las encuestas trimestrales anónimas (los textos han mejorado desde entonces, pero la esencia de la encuesta no ha cambiado) y una alta calificación de Habr-Karer muestran una disminución en la desgracia del desarrollo. Se trata de la evaluación de sus ingresos en relación con el mercado, las refinerías y el eNPS (datos de solo dos trimestres hasta ahora).
Encuesta de ingresos para desarrolladores : Encuesta de
revisión para desarrolladores : eNPS Desarrollador:
en una escala del 1 al 10, ¿qué probabilidades hay de que recomiende Mindbox como lugar de trabajo?
Por último, pero no menos importante: tecnología
Todo esto hizo posible organizar la reescritura de un producto monolítico - más de 2 millones de líneas de código en IIS + ASP.NET + NLB / Windows Service / MS SQL - simultáneamente en todas las direcciones:
- API de microservicio y backend, cuando una solicitud de cliente a API Gateway es manejada de manera transparente por múltiples microservicios, incluidas las solicitudes síncronas (patrón de saga).
- Microfront-end, donde las secciones de la interfaz están separadas de las aplicaciones SPA de backend que se pueden alojar en sus propios repositorios, con su propia canalización de diseño.
- Transferencia de microservicios multiinquilino de MS SQL a almacenamientos escalables distribuidos: Cassandra, lickhouse. Kafka en lugar de RabbitMQ.
- Transferencia de la aplicación a .NET Core, linux y transferencia parcial a Managed Kubernetes "Yandex-clouds". Inmediatamente, la introducción de tecnologías modernas SRE y DevOps: OctopusDeploy + Helm, Prometheus, Grafana, Graylog + Sentry, Amixr.IO.
Quizás somos uno de los clientes más cargados de Yandex Cloud, por lo que Nikita Prudnikov habló sobre nuestra implementación y la superación conjunta de las dificultades de CTO con Yandex en Yandex Scale 2020 .
En nuestro artículo sobre Black Friday, puede leer acerca de nuestros principales enfoques de escala utilizando el ejemplo de un componente de la lista de correo que no se rompió el año pasado y no rompió este.
Planes de desarrollo adicionales
A pesar de los resultados obtenidos, debo decir que se ha hecho menos de la mitad de lo planeado. Adelante:
- Continuar aumentando los ingresos de los desarrolladores y contratando a los mejores clientes potenciales senior y tecnológicos
- El tercer equipo de la escuela de desarrollo, que permitirá contratar hasta 12 desarrolladores por año
- Traducción continua de la aplicación a .NET, k8s y Yandex-cloud, escalado automático, diseño azul-verde con reversión instantánea
- Avanzando hacia el establecimiento automático de incidencias en la página de estado, eliminando falsos SLA positivos
- Migración a .NET 5, EF.Core y PostgreSQL (y desarrolladores a nuevas MacBooks)
- Aislamiento de varias piezas más a gran escala del monolito
Impulso motivado para crecer NET-desarrolladores tehlidov y SRE-especialistas para responder a nuestra nuestro trabajo hh.ru . Será interesante, podrás conseguir una experiencia única en el mercado y hacer cosas.
Plataformas de hoja de ruta en 2021
Sentimos una base sólida bajo nuestros pies, lo que nos da la esperanza de poder cumplir nuevamente con las promesas de nuestra hoja de ruta comercial. Intentamos los procesos de planificación descentralizada durante un año por primera vez, pero me permitiré imprudentemente formar expectativas públicas.
Este año agregaremos a la plataforma:
- Constructor de escenarios .
- Almacenamiento y notificación de pedidos anónimos
- Más informes rápidos en la interfaz ( como en nuestro curso )
- Integración con BI
- Nuevo módulo de notificaciones push móviles, que incluye un nuevo SDK
- Posibilidad de eliminar rápidamente cualquier entidad, teniendo en cuenta las dependencias entre sí
- Más algoritmos de aprendizaje automático y muchas mejoras de calidad a los existentes
- Más páginas en un nuevo diseño con capacidad de respuesta de interfaz mejorada
- Personalización simplificada de integraciones y mecánicas estándar
Los planes para 2022 son más ambiciosos, pero espero escribir sobre ellos en un año, si el optimismo está justificado.
Gracias
Al igual que las historias de éxito de los clientes, esta es el mérito de personas específicas a las que expreso mi gratitud:
Nikita Prudnikov, CTO, por la visión, la coherencia y la compresión sistemática.
Roman Ivonin, arquitecto principal, por su paciencia, trabajo en equipo, amplia responsabilidad, liderazgo informal y noches de insomnio.
Igor Kudrin, CIO, por la base de la experiencia, la visión y la salvación de SRE de todo cuando nadie sabe cómo.
Rostislav, Leonid, Dmitry, Mitya, Ilya, dos Artyoms, Alexei, Sergey, Nikolai, Ivan, Slava, Zhenya y otros desarrolladores, productos, líderes tecnológicos y SRE que hicieron de todo esto una realidad. Lo siento si no mencioné a nadie.
Un agradecimiento especial a los clientes que aguantaron, a pesar de que fallamos, y nos dieron la oportunidad de mejorar. Haremos todo lo posible para que siga mejorando.