Empecé mi carrera cableando racks, instalando sistemas operativos desde CD y reiniciando servidores con nombre propio a los que les tenía casi cariño. Hoy me dedico a diseñar plataformas donde los servidores son ganado sin nombre que aparece y desaparece según la carga. Entre un punto y otro hay más de una década de aprendizajes, muchos de ellos a base de golpes. Esto es lo que le contaría al sysadmin que fui si pudiera mandarle una carta.
El cambio no es de herramientas, es de mentalidad
Mi primer error fue pensar que pasar de sysadmin a SRE consistía en aprender herramientas nuevas: cambiar Bash por Terraform y Nagios por Prometheus. Las herramientas se aprenden en semanas; lo que cuesta años es cambiar la forma de pensar. Un sysadmin arregla servidores; un SRE diseña sistemas que se arreglan solos o, mejor aún, que fallan sin que el usuario lo note. Dejé de preguntarme cómo evito que esto falle y empecé a preguntarme qué pasa cuando esto falle. Esa sola pregunta cambió mi manera de trabajar para siempre.
Lo que me hubiera gustado saber desde el principio
- Aprende a programar de verdad: no scripts de usar y tirar, sino código con tests, revisiones y repositorio. La automatización es software, y tratarla como software es lo que separa una plataforma mantenible de una colección de parches.
- El servidor mascota tiene los días contados: cuanto antes asumas que todo debe poder reconstruirse desde código, antes dormirás tranquilo. Si restaurar una máquina requiere recordar lo que hiciste hace dos años, no tienes infraestructura: tienes arqueología.
- Los errores de otros son oro: leer postmortems públicos de otras empresas me enseñó más ingeniería de fiabilidad que cualquier curso. Los incidentes ajenos son formación gratuita.
- Di que no con datos: el sysadmin que fui decía que sí a todo y vivía apagando fuegos. El SRE que soy negocia presupuestos de error y prioriza con métricas. Los datos convierten discusiones eternas en decisiones rápidas.
- La fiabilidad es una decisión de producto: el noventa y nueve coma nueve por ciento no se decide en la sala de máquinas, se decide con negocio, porque cada nueve extra cuesta dinero y velocidad. Aprender a tener esa conversación vale más que cualquier certificación.
Lo que nadie te cuenta
Que la parte técnica es la fácil. Lo difícil es lo otro: convencer a un equipo de que los postmortems sin culpables van en serio, sostener una rotación de guardias que no queme a la gente, explicar a dirección por qué invertir en algo invisible como la fiabilidad. También que el síndrome del impostor no desaparece con la experiencia; solo aprendes a trabajar con él. Y que está bien no saber de todo: yo sigo abriendo la documentación de cron cada vez que escribo una expresión, y no pasa nada.
Conclusión
Si estás haciendo ese camino ahora mismo, mi consejo es que no tengas prisa y que no menosprecies tu pasado: los años de sysadmin son unos cimientos buenísimos, porque sabes cómo fallan las cosas de verdad, no en los diagramas. Añádele código, métricas y una mentalidad de diseño para el fallo, y tendrás un perfil que vale oro.
¿Estás en plena transición de sysadmin a DevOps o SRE? ¿Qué es lo que más te está costando? Cuéntamelo en los comentarios 😊