Mantenimiento somos todos

steinar-engeland-112658-unsplash
Foto: Steinar Engeland

En las últimas semanas he estado pensando en temas relacionados con el mantenimiento y sistemas complejos. En ello ha tenido mucho que ver el colapso de dos infraestructuras de ingeniería en los últimos días, la primera en Vigo (y 2) y la segunda en Génova, pero sobre todo ha influido el tiempo que he estado diseñando, operando y manteniendo un plataforma de producto basada en la nube Azure (IaaS, PaaS y SaaS, tenemos de todo).

Tras algunas conversaciones y lecturas diversas, he querido escribir algunas notas breves relacionadas, de una forma u otra, con el mantenimiento de infraestructuras en general y de las plataformas de software en particular. Espero que se vean como trivialidades evidentes pero soy consciente de que hay mucha gente ahí fuera para la que esto son conceptos nuevos y extraños, o cosas que simplemente conviene ignorar, como en los casos de Vigo y Génova, con los resultados que ya conocemos.

El mantenimiento es desagradecido. Inaugurar puentes, o desarrollar nuevas características de software, da más visibilidad y prestigio que dedicarse a mantener cualquiera de los dos. El mantenimiento es predecible, aburrido (para la mayoría), genera costes evidentes y beneficios a veces difíciles de cuantificar. Dado como funciona la mente, esperamos que las cosas funcionen, no nos sorprende y por eso las tareas de mantenimiento se vuelven invisibles.

El mantenimiento no es para todos. No todo el mundo está preparado para hacer un trabajo invisible y que no termina nunca. Es un trabajo para Penélope: una persona discreta y humilde, eclipsada por la fama de su marido Ulises, que mantuvo con su propia astucia el reino a salvo durante los 20 años que tardó este a Ítaca. Quizá ese es el perfil del perfecto “mantenedor”: humilde, discreto, capaz, inasequible al desaliento y con fuertes valores. No me imagino a Penélope diciendo “Oh bueno, ya lo arreglará otro“.

El mantenimiento es caro pero puede ser más caro no hacerlo. Diseñar e implementar plataformas o estructuras de ingeniería civil o software que requieran poco mantenimiento y simplificar este al máximo, reduce costes siempre. Pero para ello hacen falta conocimientos, perspectiva y comunicación (una persona no lo sabe todo, nunca). La importancia del coste de mantenimiento es algo que entienden bien los contables al trabajar con datos cuantificables y manejar conceptos como CAPEX y OPEX, pero no tanto los desarrolladores o ingenieros que quieren construir “the next big thing” y estar a la última para la carrera de ratas que es el desarrollo de software.

El mantenimiento no es apagar fuegos. Si tienes un “fuego en producción”, como decimos en el gremio, es porque algo no se ha hecho bien anteriormente (diseño, implementación, mantenimiento…). Da igual lo mucho que te feliciten por haber arreglado el problema si en el fondo lo has provocado tú de forma inadvertida. Si aceptas esto, la tarea de mantenimiento es si cabe más ingrata. Pero si no lo aceptas eres más un bombero pirómano que el héroe del día. En cualquier caso no vale con resolver los problemas, idealmente tienes que cambiar algo para que el problema no vuelva a suceder nunca o que se solucione solo.

El mantenimiento es necesario. Da igual lo genial que sea un sistema. Da igual si lo has construido con tus propias manos con las mejores prácticas. Siempre necesitará algún tipo de mantenimiento. A menudo se pone de ejemplo de ingeniería “bien hecha” a los puentes romanos como cosa que funciona sin tocarse. Afortunadamente en Toledo tenemos varios, de varias épocas y sabemos que es una falacia (además de un sesgo de supervivencia). El puente de Alcántara por ejemplo, ha tenido que ser reconstruido varias veces y finalmente cerrado al tráfico, y su historia está conectada a la construcción del puente Nuevo, que es un KISS en toda regla. Lamentablemente vivimos en una época en que la filosofía es “usar y tirar” las cosas por lo que es difícil argumentar con alguien que solo mira a corto plazo la necesidad de mantener, documentar, etc.

El mantenimiento es complejo. Para hacer su trabajo los equipos de mantenimiento deben conocer la infraestructura y su contexto, además de aprender a lidiar con modificaciones y nuevos eventos que no se habían previsto en el diseño original. Al final, alguien de “mantenimiento” puede llegar a saber más sobre un sistema que sus propios creadores o al menos a conocerlo de una manera diferente (teoría vs práctica). Para poder llevar a cabo su trabajo, “mantenimiento” debe saber de diversas materias, estudiar el sistema a lo largo del tiempo y conocer su historia. En los peores casos tiene que saber improvisar y adaptarse. Para seguir un manual “paso a paso” que contiene cada tipo de incidencia registrada es mejor poner una máquina (que necesitará su propio mantenimiento, pero esa es otra historia).

El mantenimiento se basa en el conocimiento. Si has llegado hasta aquí entenderás que cualquier mantenimiento se basa en el conocimiento del sistema (historia, procesos, herramientas, personas) de cada detalle de la infraestructura. No digo que haya que conocer TODO sobre el sistema, que es imposible, pero cuanto más, mejor. Sin una documentación decente que asimilar poco a poco durante un largo periodo y sin asumir un periodo de aprendizaje práctico, el mantenimiento tiende a convertirse en un “apagar fuegos” grandes o pequeños. Porque el mantenimiento es complejo, pero no tiene por qué serlo más de lo necesario, y ahí es donde la transmisión de conocimiento por diferentes métodos, es esencial.

La documentación tiene que cumplir una función, no una forma. A menudo he visto que solicitar que se documente algo trae quejas y conatos de rebelión en los equipos de programación. En esos casos el tema suele zanjarse con una documentación de attrezzo, información trivial que se disfraza en un formato “profesional” pero sin un contenido útil o trabajado. Esto se traduce en archivos Word de 300 páginas detallando trivialidades y conteniendo capturas de pantalla, o bien en forma de reuniones de formación presencial donde se cuenta, con suerte, un 10% de las mismas trivialidades del documento, pero con pausas para café. La documentación no se hace de un día para otro, evoluciona y crece con el tiempo al cuidado de un equipo de personas a las que les preocupa el futuro.

El coste de propiedad puede variar enormemente de la noche a la mañana. A menudo pensamos que alquilar algo es más caro que comprarlo (coches, casa, on premises vs cloud…), pero es una falacia. Los costes de propiedad se pueden disparar de por sorpresa de formas inesperadas y entonces el propietario tiene un problema. No quiero decir que sea mejor el pago por uso siempre, pero los humanos tendemos a evaluar mal los riesgos futuros así que una estrategia que nos ofrezca opciones (código abierto, entornos híbridos, estándares migrables…) suele ser mejor que casarse con una solución o producto concreto. De nuevo, los contables tienen mucho más claro el problema del coste de propiedad que el resto de los mortales al usar conceptos como activo, pasivo, amortización o, de nuevo, CAPEX y OPEX.

Por último, el mantenimiento es cosa de todos. Si ves que algo se puede arreglar, arréglalo o avisa para que lo arreglen. Es mejor para todos eso que esperar a que se rompa del todo, o a condenar al siguiente a sufrir malas condiciones. En desarrollo me gusta aplicar (y pedir) la llamada “regla del boy scout” que consiste en dejar las cosas mejor que como te las encontraste. No se trata de cambiar grandes cosas, sino de mejorar poco a poco, (funcionamiento, formato, documentación). A día de hoy es algo trivial y puedes corregir erratas en libros de Tim O’Reilly o documentación de Azure sin apenas esfuerzo. Estos dos últimos ejemplos son casos reales, ojo.

Espero que este ladrillo no haya desanimado a quien esté haciendo mantenimiento de lo que sea, desde Q&A de software a revisión de tuberías, aunque si de verdad sois Penélopes o Sísifos, sé que os dará igual. Y además puede que os interese leer “Innovación y Tradición: Historia de la tecnología moderna” muy al hilo de todo esto.

Ánimo y al toro.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s