Leer las notificaciones de mantenimiento de RDS

Al leer el cuerpo hay tres cosas que fijar: qué se actualiza, cuándo y si habrá parada. Una actualización del sistema operativo (required operating system update) o una versión menor del motor significan unos minutos de parada en Single-AZ y una desconexión corta por conmutación por error (failover) en Multi-AZ. Un cambio de hardware se comporta igual.

El “cuándo” aparece como la hora de inicio de la ventana de mantenimiento de esa instancia, escrita en UTC. Hay que pasarla a su zona horaria, y ahí es donde la confusión es fácil: la conversión puede mover el día, y lo que parecía la noche del sábado resulta ser la madrugada del domingo.

Casi todas las notificaciones ofrecen dos opciones —aplicar la actualización de inmediato o aplazarla hasta la siguiente ventana— y ambas se eligen desde la consola de RDS. Ahora bien, una actualización obligatoria no desaparece por aplazarla: acaba aplicándose de todos modos. Además, un mismo correo puede enumerar varias instancias, y cuando producción y preproducción van mezcladas en la misma notificación, lo que se pasa por alto es justamente la parte de producción.

Si tiene a su cargo las cuentas de varios clientes, ese mismo asunto le llega una vez por cliente. Deducir cada vez, a partir del ID de cuenta del asunto y del nombre de instancia del cuerpo, de quién es la producción de la que habla el correo es el trabajo que más tiempo consume.

Sabaki extrae del cuerpo el ID de cuenta y el nombre de la instancia, vincula la notificación con el cliente correspondiente y muestra la hora de inicio del mantenimiento como fecha límite, en su zona horaria. El resumen dice qué instancia se detiene, cuándo y por cuánto tiempo; la explicación, en español, dice en qué cambia el impacto según sea Single-AZ o Multi-AZ y cuáles son las opciones de adelantar o aplazar.

El resumen y la explicación en español sirven tal cual como borrador del aviso que usted le envía al cliente. Si pone el canal de Slack de ese cliente como destino, en cuanto llega la notificación el cliente ya sabe cuándo y por cuánto tiempo se detiene, y a quien esté a cargo solo le queda añadir lo suyo. Lo que se hizo queda en el registro de gestión, así que después se puede comprobar si el aviso llegó a salir.

Si en cada notificación acaba comprobando si el mantenimiento cae de madrugada, la solución de fondo es cambiar la ventana de mantenimiento de la propia instancia para que encaje con su operación. La explicación trae la hora de inicio de la ventana ya en su zona horaria, así que sirve de base para esa revisión.