La IA gestiona incidentes y los ingenieros pierden el contacto con sus sistemas

El autor tiene la cabeza bien amueblada, pero pocas o ninguna empresa va a dedicar tiempo a simulaciones de incidentes para sus SREs.

¿Por qué no? Porque incluso antes de la IA, muy pocas empresas dedican tiempo a practicar la restauración de sus copias de seguridad, o la recuperación ante desastres, o elegir runbooks de uso poco frecuente para practicar, o ver si pueden rotar secretos fácilmente sin tiempo de inactividad, o intentar redesplegar el sistema en la nube/plataforma de otro proveedor, o, o, o... Es el trabajo de operaciones menos atractivo que existe. A ningún ejecutivo le importa esto. Las organizaciones de operaciones presionan por un trabajo llamativo, igual que todos los demás: nueva infraestructura para nuevos proyectos, chatbots geniales, nuevos paneles llamativos, hacer que las gráficas suban y vayan hacia la derecha, etc.

Los pilotos de aerolíneas pasan por entrenamiento de simulación de desastres porque el gobierno lo exige. Si no fuera una condición para tener la licencia de piloto, ninguna empresa pagaría por ello.

¿Quieres que los SREs dediquen tiempo a entrenar para desastres? Da un paso atrás. Apoya la licencia profesional. Haz que sea una condición para tener la licencia. No obtendrás un comportamiento profesional en toda la industria hasta que profesionalices el trabajo. No sucederá sin licencias porque cada atajo que no es inmediatamente visible para los consumidores se traduce en ganancias adicionales, y el aumento de la competencia eventualmente requiere que se tomen estos atajos para mantenerse al día con la competencia y seguir en el negocio. Obligar a todos los actores a someterse a licencias requiere que todos los actores paguen estos costos y, por lo tanto, les prohíbe [...]

Encuentro que el uso de la IA es como arenas movedizas.

Cuanto más la uso, más tengo que depender de ella para hacer cambios/arreglar cosas en el mismo sistema. Al final, salgo sintiéndome vacío; sin conocimiento intuitivo del sistema "que yo construí" o arreglé.

La revisión de código es importante, pero no reemplaza el modelo mental que puedo construir cuando hago todos los pasos del desarrollo de software manualmente sin IA.

Cuanto más código escribe autónomamente, menos intuición tienen los dueños humanos sobre ese código. La pérdida de intuición es una semilla de deuda técnica que crece con el tiempo. En un horizonte lo suficientemente largo, puede hacer que mirar tu propio código base se sienta como el primer día en el trabajo (a veces en una empresa que tú fundaste).

Afortunadamente, hay formas de mitigar esto y esencialmente traducir esa intuición humana de cómo "debería" ser el código base en barreras de protección para los agentes. Pero sin eso, estás poniendo tus velas en un mar estocástico donde cada ola no se parece en nada a la anterior.

Veo que se menciona la analogía de la aviación de vez en cuando. En la aviación el fallo es catastrófico, y los sistemas que operas no cambian sobre la marcha (juego de palabras intencionado).

Probablemente puedas entrenar a los SREs de esa manera, pero solo les estás enseñando a _reaccionar_ eficientemente, no a _arreglar_ las causas raíz únicas y especiales de esos fallos. La analogía de la aviación sería un ingeniero de aviones que intenta entrenarse para fallos de motor en vuelo Y depuración de motores / rediseño de motores al mismo tiempo.

Nunca tuvo sentido en la ingeniería de software, y nunca lo tendrá. Un minuto dedicado a simulacros es un minuto mejor dedicado a rehacer el código base para reducir las posibilidades de futuros incidentes. Esta publicación está muy centrada en SRE.

Así que parece que pagas a la IA para resolver incidentes y luego pagas dinero y tiempo para que los ingenieros reciban capacitación sobre resoluciones de incidentes sintéticos.

La comparación con los pilotos es un poco inconexa porque el dominio varía mucho para cada empresa y producto. Crear simulaciones sintéticas dentro de cada dominio es como pagar dos veces por lo mismo, ¿por qué no dejar que los ingenieros manejen los incidentes reales en primer lugar? De hecho, ¿por qué no dedicar más reflexión a construir mejores sistemas?

El código también.

Trabajo con programadores y no es raro que recuerden con un detalle sorprendente el código que han escrito en el pasado.

Alguien podría mencionar un problema que ha surgido y se quedarán mirando al vacío por unos momentos y realmente recordarán de dónde proviene ese problema en el código, porque recuerdan haberlo escrito hace unos 8 meses.

Esta habilidad se perderá cuando la IA genere todo el código, estaremos atrapados en un bucle perpetuo de tener a la IA haciendo un seguimiento del estado del código para que la IA lo extienda y lo mantenga.

He visto una variación de esto donde ingenieros al azar son llamados a llamadas de incidentes de producción y no se espera que los ingenieros estén familiarizados con el sistema.

Se les pidió que "simplemente usen IA" y entiendan el componente, trien el problema, construyan una solución, etc. El ingeniero se vio obligado a elegir entre aceptar una solución potencialmente mediocre que la IA ha sugerido o arriesgarse a parecer un recurso incompetente que no sabe cómo aprovechar la IA.

Puedes adivinar qué eligió el ingeniero. La solución no era mala, pero era subóptima para algunos casos límite. Tuvimos que revisarla más tarde. Ten suficientes de estas situaciones, y los ingenieros eventualmente definitivamente se rendirán en entender el sistema en detalle.

Si el aumento de capacidades continúa como lo ha hecho, entonces un incidente que no pueda ser resuelto por la IA dejará perplejos a los humanos sin importar la práctica.

Me gusta el ejemplo del avión del artículo, pero creo que en realidad será como el código. Hace 1.5 años, los ingenieros decían rutinariamente que todavía escribían código a mano aquí o allá para mantener sus habilidades afiladas, y eso ya no es algo que se escuche mucho, si es que se escucha.

Si un SRE se enfrenta a una situación que una IA no puede resolver, entonces dicho SRE usará los sistemas de IA para triar más a fondo, apuntándola a diferentes lugares, etc.

Esto funciona para SREs con experiencia e intuición pre-IA, posiblemente menos con nuevos reclutas que vienen post-IA. No sé cuál es la solución a esto, tal vez los simulacros de práctica lo sean, pero tengo la corazonada de que todo el campo será absorbido, igual que muchos otros campos de la ingeniería.

Solo hay una cantidad limitada de necesidad de gusto y juicio, antes de que incluso eso haya sido incorporado en los modelos.

Hay una dinámica interesante también. Incluso si un ingeniero lee la salida de la IA y entiende la causa raíz de los problemas y cómo diagnosticar el incidente, de alguna manera les resulta difícil internalizar el aprendizaje y aplicarlo la próxima vez a un nuevo incidente. Como resultado, el ingeniero pierde el contacto con el sistema de todos modos.

Parece que nuestros cerebros de alguna manera tienen que experimentar los fallos durante un diagnóstico y, en general, realizar este tipo de búsqueda de caminos por sí mismos para comprender verdaderamente el sistema. No sé si esto tiene que ver con cómo nuestros cerebros realmente aprenden.