Puesto
DevOps e ingeniería de plataforma
¿Cuántas personas tienen que hacer algo para que un cambio llegue a producción? Si son más de dos, un despliegue es un acontecimiento y no una actividad, y por eso ocurre pocas veces.
Conversación inicial
Cuatro preguntas por las que empezaríamos
¿Cuántas personas tocan un despliegue a producción?
Cuantas más manos, menos a menudo desplegáis, y cuanto menos a menudo desplegáis, más grande y más arriesgado se vuelve cada cambio.
¿Con cuánta rapidez os enteráis de un problema en producción?
Si es por un usuario, la monitorización mide algo distinto de lo que de verdad se rompe.
¿Cómo sabéis que el entorno de pruebas coincide con producción?
Si es por suposición, algunos fallos de producción no se pueden reproducir en ningún otro sitio.
¿Qué es lo que no hacéis aunque sabéis que hay que hacerlo?
Normalmente: no ordenáis la configuración y no revisáis los costes de infraestructura. Siempre porque no hay nada ardiendo.
Nos quedamos con el trabajo repetitivo, vosotros con las decisiones sobre la plataforma
La configuración de entornos, la ejecución de los despliegues, recoger contexto durante un incidente y resumir los costes se pueden quitar del escritorio. Las decisiones sobre el estándar de la plataforma y sobre la respuesta a un incidente se quedan con el ingeniero.
- Un despliegue deja de ser un acontecimiento. - Una ejecución repetible con reversión hace que los cambios más frecuentes y más pequeños sean más seguros que los raros y grandes.
- Un incidente empieza con contexto. - Qué cambió en las últimas horas, qué más reaccionó, qué servicios están relacionados, antes de que nadie empiece a buscar.
- El estándar se ve y una desviación tiene nombre. - Un equipo puede hacerlo de otra manera, pero entonces se sabe dónde y por qué, en lugar de descubrirse durante una caída.
Alcance
Qué se puede quitar de un equipo de plataforma
Veinte tareas de ejemplo. Cada una tiene un punto de aprobación humana. Abajo una selección, y el alcance lo ajustamos a vuestro stack.
Entornos y su configuración
- Configuración de entornos descrita y reproducible
- Una comparación del entorno de pruebas con producción
- Una señal cuando la configuración se desvía
- Un registro de las desviaciones del estándar (decisión: el ingeniero)
Despliegues
- Una ejecución de despliegue repetible con un paso de reversión donde sea posible
- Comprobaciones previas al despliegue como condición para arrancar
- Un registro de despliegues con el alcance de los cambios
- Una señal cuando un despliegue se aparta de la ejecución (valoración: el ingeniero)
Monitorización y alertas
- Una revisión de las alertas por su utilidad
- Señalar las alertas con alta proporción de falsos positivos (juicio sobre su utilidad: el ingeniero)
- Enlazar una alerta con un servicio y un responsable
- Una señal cuando un servicio no tiene monitorización
Incidentes
- Contexto junto al aviso: cambios recientes y servicios relacionados
- Las señales de la misma ventana temporal recogidas juntas
- La cronología del incidente registrada mientras ocurre
- Un borrador del análisis posterior al incidente (contenido: el ingeniero)
Costes de infraestructura
- Coste asignado a servicios y equipos
- Señalar los recursos que no se usan
- Cambios de coste frente al periodo anterior
- Material para una decisión de cambiar la configuración (decisión: el ingeniero)
Un día de trabajo
Hoy
- La configuración de los entornos vive su propia vida y se desvía en silencio
- Un despliegue necesita varias personas presentes y un buen día
- Durante un incidente empezáis estableciendo qué cambió recientemente
- Las alertas llegan en cantidades que consumen la atención del equipo
- Reconstruís la cronología del incidente a posteriori, de memoria
- Miráis los costes de infraestructura cuando llega la factura
Con asistencia de IA
- La desviación de configuración entre entornos se señala
- El despliegue tiene una ejecución repetible y, para los cambios irreversibles, fases
- Un incidente empieza con la lista de cambios recientes y servicios relacionados
- Se señalan las alertas que nunca llevaron a una acción
- La cronología del incidente se registra sola mientras ocurre
- El coste se asigna a servicios y equipos sobre la marcha
- Frecuencia de despliegue
cambios más pequeños más a menudo, en lugar de grandes y raros
un despliegue no exige reunir a varias personas
- Tiempo de restablecimiento tras un incidente
un camino más corto hasta la causa
el contexto y los cambios recientes están junto al aviso
- Entornos que coinciden
menos fallos que no se pueden reproducir fuera de producción
la desviación de configuración se señala
- Coste de infraestructura
se ve qué cuesta dinero y de quién es
coste asignado a servicios y equipos
Empezamos por los despliegues, porque su frecuencia afecta a todo lo demás.
- Paso 1
Una ejecución de despliegue repetible
Con un paso de reversión y comprobaciones previas al arranque. Para los cambios irreversibles, ante todo las migraciones de esquema, la reversión no existe y no fingimos lo contrario: ahí se trabaja por fases y se corrige hacia delante, y la ejecución tiene que contarlo.
- Paso 2
Entornos que coinciden
Una comparación de configuración y una señal de desviación.
- Paso 3
Contexto durante un incidente
Cambios recientes, servicios relacionados, la cronología registrada mientras ocurre.
- Paso 4
Alertas y costes
Una revisión de la utilidad de las alertas y la asignación de costes. Al final, porque requiere datos de varios periodos.
Preguntas frecuentes
Preguntas que surgen en la primera reunión
¿En qué se diferencia esto de un administrador de sistemas?
El administrador mantiene lo que ya corre: servidores, copias de seguridad, actualizaciones. Aquí el asunto son los entornos en los que se construye el software y el camino que recorre un cambio hasta producción. En empresas pequeñas los puestos se combinan a menudo, pero los problemas que resuelven son completamente distintos.
¿Puede ser más pequeño el equipo de plataforma después de esto?
Los equipos de plataforma suelen ser un cuello de botella y no un exceso: cada equipo de producto hace cola ante una o dos personas. Asumir los despliegues repetitivos y la recogida de contexto durante los incidentes no reduce el equipo, acorta esa cola. De hecho eso es lo primero que notan los equipos de producto.
¿Esto entra en el ámbito del Reglamento de IA?
Trabajar en infraestructura no es un uso de alto riesgo. El único punto que requiere cuidado es que los datos sobre despliegues e incidentes sirvan para mejorar la plataforma y no para evaluar equipos ni a las personas que entregaron un cambio.
¿Os queda alguna pregunta que no esté aquí? Reservad una llamada
Siguiente paso
¿Cuántas veces desplegasteis a producción el mes pasado?
Os enseñaremos cómo es el trabajo de plataforma cuando un despliegue deja de ser un acontecimiento y un incidente empieza con contexto.