El título en inglés alude a una famosa campaña de una empresa deportiva, pero sirve para ejemplificar el desafío de trabajar en informática cuando tenemos poco tiempo disponible. ¿Cómo deben manejarse los cambios dentro de los plazos estrechos que nos impone el error budget? Veremos cómo las técnicas modernas de desarrollo ayudan a conseguir este objetivo.
Partamos por un caso ficticio. El cliente de una multinacional quería que su sistema tuviera un SLA (uptime) de 99,95% mensual, equivalente a casi 22 minutos de indisponibilidad por mes, pero el gerente de cuentas de VA Inc. (su proveedor tecnológico) lo convenció que ello era muy caro, así que el cliente aceptó reducirlo a un 99,9% mensual (equivalente a casi 44 minutos mensuales de indisponibilidad). Recordemos que ese tiempo se conoce como el "error budget".
El cliente precisó que todo cambio y mejora al sistema debía hacerse dentro de ese período. El cliente también solicitó tener un panel donde se mostrara el uptime del servicio, ya que no le servía ver la actividad de CPU del servicio como indicador de uptime.
Con una parte del sistema ya en producción hace unos meses, paralelamente, se estaban desarrollando varias mejoras al sistema y una app que trabajaría con lo ya productivo. En realidad, habían varios cambios acumulados esperando la aprobación del cliente para el paso a producción, además de otras mejoras en diferentes fases de desarrollo.
A comienzos del tercer mes de operación, llegó una alerta de seguridad de Apache. Éste debía ser actualizado. El cambio tomó 5 minutos, así que quedaban 39 minutos en el error budget del mes, aún suficiente. Una semana más tarde, un informe de seguridad enviado por el cliente, pedía actualizar una serie de componentes de sistema. Los cambios implicaron el reinicio del servicio y el consumo de otros 6 minutos del "error budget". A mediados de mes, el ingeniero SRE activó el panel que mostraba el uptime del servicio. Para su sorpresa, durante esos 15 días el servidor web se reiniciaba todas las noches cuando rotaban los logs. Esto representaba 2 minutos diarios de indisponibilidad, es
decir, sólo quedaban 3 minutos para hacer todos los cambios y mejoras en ese mes, sin contar algún incidente que pudiera ocurrir.
¿Qué nos dice SRE ante este escenario?
Para el estándar SRE, el uptime es la funcionalidad más importante de un sistema, por lo tanto, si los cambios y nuevas funcionalidades no pueden ser instaladas dentro del tiempo restante (3 minutos en este caso), su instalación se tendrán que postergar para el mes siguiente.
Ante esta situación, se tienen dos alternativas:
- Priorizar y acotar los cambios que impliquen la resolución de problemas existentes, sin comprometer el uptime.
- Usar la "bala de plata" (una anual), que autoriza sobrepasar el "error budget" restante. Para esto se requiere de una aprobación ejecutiva de alto nivel y, por su puesto, del cliente.
Los acuerdos de nivel de servicio (entre ellos el uptime) son obligaciones escritas, suscrita por todos los miembros de la organización, y que su incumplimiento implican consecuencias; generalmente, conlleva la dedicación exclusiva a resolver un problema, sumando a muchas personas de otros proyectos a mantener el error budget. Estas acciones van en detrimento de otros proyectos.
Pongamos más pelos en la sopa, supongamos que la empresa cuenta con mecanismos de instalación automática y todos los cambios pudieron hacerse sin comprometer el uptime.
¿Qué ocurre si alguno de esos cambios o nueva funcionalidades introdujo latencia, no funciona como se esperaba (nuevos y mejores errores) o compromete el uptime? Generalmente, cuando se dan estos escenarios, se tardan días en descubrir el error, habitualmente alertado por los propio usuarios. En consecuencia se compromete el uptime u otros indicadores del servicio.
Entonces ¿qué soluciones hay?
- Es importante que todas las arquitecturas de sistemas cuenten con balanceadores de carga en sus diseños, ya que estos permiten hacer cambios a un grupo acotado de usuarios y así no exponer a todos a una falla de alto impacto (manejo de cambios con blue/green o canary).
- Lo segundo, contar con flujos automatizados de puesta en producción, reemplazo de contenedores (infraestructuras inmutables) por medio de flujos de integración continua (CI/CD) y flujos de cambios automatizados.
- Tercero, trabajar los proyectos con cambios pequeños y constantes, de modo de minimizar los riesgos que implica hacer cambios (usar técnicas de proyectos ágiles).
- Cuarto, contar con mecanismos automatizados de vuelta atrás (se construyen "playbooks" para este propósito) y por último, tener un circuito de pruebas automatizadas en todo el ciclo de desarrollo e incluso en la puesta en producción.
En resumen, nada obliga a las empresas tecnológicas a modernizar sus estrategias/técnicas tradicionales (proyectos cascada, cambios manuales, carencia de SLA y falta de preocupación por el uptime, áreas de QA débiles, etc.), pero si miramos cómo se están moviendo los principales actores tecnológicos, bien conviene prestar atención a estas tendencias. Antes que el juego sea muy duro para entrar en él.
