Avito revela cómo mide la fiabilidad y en qué se diferencia su presupuesto de errores del de Google

Una de las mayores plataformas de internet de Rusia ha explicado públicamente cómo convierte la «fiabilidad» de un eslogan en cifras. Iván Tarásov, TUL Architecture Governance en la plataforma técnica de Avito, desgranó en Habr toda la cadena: desde SLI, SLO y SLA hasta los requisitos no funcionales (NFR) para servicios REST/RPC, buses de datos y operaciones personalizadas. El material subraya de manera especial que el presupuesto de errores de Avito difiere de la descripción canónica del libro Google SRE. Según el autor, es una decisión intencionada.

Una salvedad importante: solo disponemos del anuncio del artículo. Los umbrales concretos, las fórmulas y los argumentos de Avito se detallan en la versión completa, así que a continuación analizamos la estructura del enfoque y su contexto, sin reproducir detalles que no hemos visto.

Qué incluye el sistema

Tarásov dirige varios equipos. Uno de ellos, SLA, crea las condiciones para mejorar la fiabilidad técnica y desarrolla las herramientas de NFR y los escenarios de estabilidad. Del anuncio se desprende el siguiente conjunto de elementos:

• SLI, SLO y SLA como jerarquía básica: qué se mide, qué objetivo se fija y qué se promete.
• Stability Rate y Uptime como dos métricas distintas, cuya diferencia el autor analiza por separado.
• NFR para servicios REST/RPC, es decir, requisitos para la interacción síncrona.
• NFR para buses de datos, donde la fiabilidad se mide de otra manera que en una petición con respuesta.
• NFR para operaciones personalizadas, que no encajan en las plantillas estándar.
• Un presupuesto de errores que se aparta deliberadamente de la versión de Google SRE.

La lista deja clara una cosa: Avito no se limita a un único número de «nueves» por servicio. Cada tipo de interfaz recibe su propia forma de medición.

Por qué no adoptaron tal cual el canon de Google

En el libro Google SRE, el presupuesto de errores equivale a uno menos el SLO. Con un objetivo de 99,9% a 30 días, son unos 43 minutos de indisponibilidad admisible. Mientras el presupuesto no se agota, el equipo lanza versiones con libertad. Cuando se acaba, la prioridad pasa a la estabilización. El mecanismo es sencillo y zanja la eterna disputa entre desarrollo y operaciones.

En la práctica, este modelo tiene puntos débiles. Supone que el SLO está bien definido y que se puede medir de la misma forma en todos los servicios. En una empresa con cientos de servicios, colas, buses y operaciones no estándar, esa condición a menudo no se cumple. Avito afirma que lo tuvo en cuenta y modificó el modelo de forma deliberada. El anuncio no permite ver qué parámetros concretos cambió, y aquí no conviene especular.

Stability Rate frente a Uptime

Uptime muestra tradicionalmente la proporción de tiempo en que el servicio se consideró disponible. La métrica resulta cómoda para los informes, pero es burda: un servicio puede responder y, aun así, devolver errores a una parte de los usuarios. El nombre Stability Rate apunta a una evaluación basada en los resultados de las operaciones, no en el calendario. Avito da la definición exacta en el artículo, pero el mero hecho de separar las dos métricas habla de un enfoque maduro. Los minutos de caída y la proporción de operaciones fallidas describen cosas distintas, y el presupuesto de errores depende de cuál de las dos se tome como base.

Cómo aplicarlo en tu empresa

Incluso sin los detalles de implementación, de la publicación se pueden extraer varias conclusiones prácticas:

• Separa los tipos de interfaz. Las llamadas síncronas, los buses de datos y las operaciones en segundo plano necesitan SLI distintos. Una plantilla única dará un dashboard bonito y una imagen deficiente.
• No confundas disponibilidad con éxito. Si el equipo informa solo de Uptime, una parte de las degradaciones seguirá siendo invisible.
• Documenta por escrito las desviaciones del canon. Si cambias el modelo de presupuesto de errores, deja constancia de las razones y los límites; de lo contrario, dentro de un año nadie recordará por qué se hizo.
• Vincula los NFR al proceso de arquitectura. En Avito de esto se ocupan dentro de Architecture Governance. Los requisitos que se verifican en la fase de diseño cuestan menos que las correcciones posteriores a un incidente.

El artículo original en Habr merece la lectura de quienes construyen prácticas SRE en un gran sistema distribuido. El caso destaca precisamente porque la empresa explica abiertamente dónde y por qué se alejó del esquema comúnmente aceptado.