Ingeniero de DevOps / plataforma / SRE

Infraestructura como código, definiciones de tuberías, manifiestos: el gran volumen de texto estructurado que describe lo que debería existir.

Decidir a las tres de la madrugada, con prisa y con información parcial, qué se revierte, qué se degrada y qué se le cuenta a la gente mientras sigue roto.

Explicar una factura de nube, encontrar lo que la ha triplicado y decidir qué ineficiencia merece la semana de un ingeniero.

Elegir la arquitectura, los modos de fallo que estás dispuesto a tener y lo que el equipo seguirá siendo capaz de operar dentro de dos años.

Una encuesta a profesionales, así que ese 90% es uso declarado por uno mismo y no uso medido, y el «80% cree que aumentó su productividad» que la acompaña es una creencia y hay que leerlo como tal: este sitio tiene un ensayo aleatorizado en el que desarrolladores con experiencia fueron un 19% más lentos mientras creían que eran un 20% más rápidos, así que lo que uno cree sobre su propia velocidad no es evidencia sobre su velocidad. Lo que no es declaración sobre el propio rendimiento es la correlación que los investigadores calculan entre quienes responden, y esa es la parte útil: la adopción se relaciona positivamente con el rendimiento del proceso y del producto, y negativamente con la estabilidad de la entrega. El mecanismo que dan los autores es concreto: sin pruebas automatizadas sólidas, control de versiones maduro y ciclos de realimentación rápidos, un mayor volumen de cambios produce inestabilidad, y los equipos con arquitecturas poco acopladas ven ganancias mientras que los muy acoplados ven pocas o ninguna. Quien publica esto es Google Cloud, que vende las herramientas por las que pregunta.

Una herramienta se usa a gran escala en trabajo real y eso está medido, y quien decidió usarla fue la persona que trabaja, no quien emplea. Es más que un registro de capacidad —el trabajo es real, no una demostración— y menos que uno de despliegue, porque ningún empleador la puso en producción, ni la exigió, ni construyó un proceso alrededor. Ponderada como `cautious`: `automating` significa que la máquina puede hacer la tarea Y que hay indicios de adopción, y esto es un indicio de adopción; pero el uso puede ser una prueba, y buena parte de la medición viene de una parte con intereses, así que un registro nunca basta y dos independientes sí. Fíjate además en quién cuenta. La telemetría de un proveedor ve esto directamente y a la vez vende la herramienta, así que un registro de este tipo declara ese interés en su ámbito de aplicación; una agencia estadística que pregunta a las empresas si su personal usa IA en tareas ve el mismo canal sin ningún interés propio, y donde exista es la mejor fuente.

Un estudio sectorial encargado, no una medición, y se registra aquí porque apunta en dirección contraria a casi todo el resto de esta base. El mismo documento que espera que el soporte autónomo encoja espera que el trabajo aterrice en este puesto: dice que la función de DevOps pasará a supervisar los acuerdos de nivel de servicio y a desarrollar sistemas nuevos, que desarrollo y operaciones se juntan para dar un soporte más integral, y enumera a los ingenieros de automatización y orquestación entre los puestos con demanda creciente. También nombra al ingeniero de DevOps como el destino que considera un salto fácil o moderado para los ingenieros de soporte cuyo desplazamiento espera. Nada de eso es evidencia de que se contratara a nadie, de que subiera la plantilla ni de que la transición ocurriera: es la expectativa de una agencia, publicada antes de que la IA generativa llegara al público, referida solo a Singapur y construida a partir de entrevistas a partes interesadas y no de datos de empleo. Lo que sí establece es que el hallazgo de desplazamiento que hay en otra parte del mismo informe no afirma que el trabajo desaparezca.

Una persona con nombre y con posición reconocida predijo algo públicamente, en una fecha, en una declaración atribuible. Se registra para que quede comprobable quién dijo qué y cuándo, y nunca mueve la evaluación de una tarea, porque una predicción no es una observación. Su valor llega después: el registro queda en la misma página que la evidencia sobre esa ocupación, así que quien lee el pronóstico lee al lado el registro de lo que pasó luego. Esa es la rendición de cuentas; este sitio no publica ningún veredicto sobre si un pronóstico se cumplió.

El escalón que antes contrataba a gente junior, escribir y conectar configuración, es el que tiene apuntado el mecanismo más claro, porque es código con un resultado verificable por máquina. Lo que eso le deja a quien empieza son las guardias, que son la parte más dura y la que se suponía que había que ganarse. Empuja para estar en las revisiones de incidentes mucho antes de entrar en el cuadrante.

Tu palanca es la decisión de diseño y el aviso de incidente, y las dos son porciones pequeñas de la semana. El riesgo no es que se automaticen, es que las horas que las rodean se adelgacen hasta que un ingeniero cubra servicios que ninguna persona puede tener en la cabeza. Vigila los servicios por ingeniero igual que un camarero vigila los cubiertos por camarero.

Quedarte y reforzarte

Muévete hacia el diseño y aléjate del cableado

La decisión de diseño no tiene árbitro automático, que es justo por lo que ninguna herramienta puede cerrar el círculo sobre ella, y es la parte del puesto que se acumula.

Rehacer el puesto

Adueñate de la operabilidad de lo que construyen otros

Que se genere más configuración significa más sistemas de los que nadie responde, y alguien tiene que sostener el estándar de qué puede correr en producción.

La mitad de la configuración se está moviendo y deprisa, porque el código de infraestructura o se aplica limpiamente o da error, y un resultado verificable por máquina es lo que permite a un modelo reintentar sin vigilancia. Las guardias no, porque un incidente es por definición el fallo que nadie anticipó y el aviso va de daño aceptable y no de una respuesta correcta. La forma probable no es la eliminación sino el adelgazamiento: menos ingenieros cubriendo más servicios, lo que conserva todas las tareas y empeora el cuadrante.

Ninguna fecha. Dos cifras que puedes producir tú dicen más que cualquier previsión: qué parte de tu semana se va en trabajo donde aplicarlo o sale bien o da error, y de cuántos servicios responde ahora cada ingeniero de tu cuadrante. La primera es tu exposición por tarea; la segunda es el cambio que de verdad alcanza a la gente en este puesto, y se mueve en silencio un par de trimestres después de que aterrice cualquier herramienta.

Normalmente no, y este es el caso más claro del sitio de una herramienta que parece un ahorro y se comporta como una deuda. Cada recurso creado es un recurso que alguien tiene que mantener, asegurar y al final borrar, así que configurar más rápido produce más configuración en vez de menos trabajo: las horas se desplazan de escribir a desenredar. Desenredar es invisible en una hoja de ruta, que es exactamente por lo que se presupuesta como un ahorro.

Es la tarea más segura de la ocupación y también la más pequeña. Si un diseño fue el correcto se descubre dieciocho meses después, lo que significa que no hay árbitro automático y por tanto no hay bucle que una herramienta pueda cerrar; pero en casi todos los equipos las decisiones de diseño son unos pocos días por trimestre. Un puesto puede estar seguro en su tarea más veterana y aun así perder la mayoría de sus horas, y esa distancia es lo que hay que planificar.