Los primeros 90 días: Guía paso a paso para ingenieros DevOps
Hola, nueva incorporación. ¡He oído hablar de ti!
Aprendiste Kubernetes a fondo, automatizaste todo lo automatizable y gestionaste pipelines. Estudiaste estrategias de CI/CD, herramientas de Infraestructura como Código y las peculiaridades de YAML como si te fuera la vida en ello.
¡Felicidades, conseguiste el puesto de Ingeniero DevOps!
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Te entregaron acceso a la consola de la nube, la pipeline de construcción y, posiblemente—horriblemente—acceso root en producción (sin presión).
La mayoría de las incorporaciones en DevOps son un frágil cóctel de “lee este documento aleatorio de 2021”, “pregunta por ahí” y “no toques ese script, creemos que aún hace algo”.
El rol rara vez está bien definido y las expectativas son ridículamente altas mientras la documentación es escasa. Además… algunos despliegues parecen capaces de despertar una antigua maldición.
Aunque la entrevista pudo haber sido sobre herramientas, tus primeros 90 días giran en torno a personas, procesos y prioridades. Aquí es donde te ganas la credibilidad, descubres lo que no está documentado y sientas las bases para la infraestructura en la que tu equipo pueda confiar.
Este playbook no arreglará la infraestructura de tu equipo de la noche a la mañana. Pero te ayudará a evitar parecer el que la rompió.
El rol: DevOps vs. Platform vs. SRE
Empecemos con el eterno aviso: “DevOps es una cultura, no un puesto de trabajo.” Claro, Jan – pero el puesto de trabajo existe. Y en la práctica, eso suele significar una combinación de especialista en automatización, arquitecto de sistemas, SRE y experto en herramientas internas.
Se supone que debes ser un facilitador, un multiplicador, un campeón de la velocidad de entrega. Pero la verdad es que serás la persona a la que acuden cuando:
- La construcción falla y nadie sabe por qué.
- Alguien necesita un nuevo entorno de pruebas ahora mismo.
- Está pendiente una auditoría de cumplimiento y los secretos están flotando en texto plano.
- “Deberíamos automatizar eso” se convierte en “¿Puedes automatizar eso?”
Platform Engineering es DevOps con mejor marketing.
SRE es DevOps con un SLA.
Como lo llamen, tu trabajo es hacer que las cosas escalen, sigan funcionando y no sean un desastre.
Los primeros 30 días: No toques nada (aún)
Consejo #1: Mapea la infraestructura, no solo la arquitectura
Aprende de qué eres responsable: proveedores de la nube, pipelines de CI/CD, orquestación de contenedores, gestión de secretos y flujos de trabajo de incidentes. Crea tu propio “mapa de infra” para visualizar el stack. Puntos extra si enlazas a dashboards en vivo o scripts.
Consejo #2: Encuentra el radio de impacto
Toda organización DevOps tiene una configuración de “por favor, no toques eso”. Haz un inventario de todo lo que podría explotar si se manipula incorrectamente. Esto incluye:
- Scripts de despliegue que hacen SSH en producción (¿por qué… por quééé?)
- Trabajos de Jenkins modificados por última vez en 2019
- Runbooks manuales guardados en un PDF
- Archivos de Terraform que nunca se aplicaron realmente
Pregunta: ¿Qué es crítico pero no está documentado? ¿Quién es responsable? ¿Y cuál es el plan de recuperación si falla?
Consejo #3: Participa en un despliegue, o mejor aún, acompaña uno en vivo
Aprenderás más de un solo despliegue (y sus problemas) que de horas de documentación. ¿Qué partes son manuales? ¿Qué cosas fallan? ¿Qué es conocimiento tribal y qué está documentado? Aún no estás aquí para lanzar ideas geniales. Estás aquí para observar y aprender en profundidad.
Deberías ser capaz de trazar un commit desde el merge hasta producción con los ojos cerrados. Entiende:
- La canalización CI/CD (dónde se rompe, dónde se generan cuellos de botella)
- Gestión de secretos (por favor, que no estén en variables de entorno)
- Flujos de aprobación (¿estamos desplegando YOLO desde Slack?)
No envíes código. Solo observa el funcionamiento y toma notas.
Los Primeros 60 Días: Identificar Riesgos, Reducir Fricción
Consejo #4: Logra una victoria en 5 minutos
Busca tareas de alta fricción y bajo riesgo que puedas automatizar o convertir en plantillas. Estas mejoras del “1%” facilitan tu trabajo y generan buena voluntad en el equipo. Solo encuentra algo que tome 5 minutos más de lo necesario y haz que sea más rápido:
- Un envoltorio de shell para la configuración local de desarrollo
- Un asistente CLI
- Un módulo reutilizable de Terraform
- Un script para eliminar entornos de pruebas atascados
- Notificación de Slack para compilaciones fallidas
Las pequeñas victorias generan confianza. La confianza te da margen para hacer grandes cambios.
Consejo #5: Audita la canalización CI/CD con extremo rigor
Observa los tiempos de construcción. Observa la cobertura de pruebas. Observa qué falla a diario. Haz preguntas como:
- ¿Podemos paralelizar las pruebas?
- ¿Esto podría haberse prevenido antes en CI?
- ¿Estamos almacenando en caché las dependencias?
- ¿Desplegamos al hacer merge... o solo con fe y sin garantías?
No estás aquí para señalar culpables. Estás aquí para que el flujo sea sin fricción.
Consejo #6: Crea paneles que la gente realmente use y clarifica la responsabilidad
Grafana, Prometheus, Datadog—no importa cuál. Lo importante es:
- ¿Tu equipo puede ver la tasa de éxito de los despliegues?
- ¿Las alertas significan algo o solo son ruido?
¿Alguien está vigilando las tasas de error antes de que los usuarios se quejen? ¿Quién se encarga de la canalización de construcción? ¿De los charts de Helm? ¿De las configuraciones de DNS? Los límites de responsabilidad rara vez están claros. Haz una lista de las áreas grises y clarifícalas con tu equipo. Esto previene culpas más adelante.
Ahora tú eres responsable de la visibilidad. Hazlo valer.
Los Primeros 90 Días: Generar Confianza a través de la Fiabilidad
Consejo #7: Entrega algo que aumente la estabilidad
Esto podría ser:
- Agregar alertas a un sistema poco monitorizado
- Mejorar la cobertura de pruebas en pre-producción
- Reducir la inestabilidad en las canalizaciones CI
- Refactorizar un script de bash que estaba a un rm -rf de un desastre
No tiene que ser algo enorme. Debe hacer que tu equipo respire más tranquilo.
Consejo #8: Escribe una nota de retroalimentación sobre “DevEx”
Recoge comentarios anónimos o informales de los desarrolladores sobre dónde la infraestructura les ralentiza. Expón lo que has aprendido y sugiere experimentos (por ejemplo, desarrollo local más rápido, entornos efímeros, mejores registros).
Redacta un documento titulado “Esto es lo que aprendí y lo que haré a continuación.” Es una hoja de ruta (¡y también un motivo para presumir ;). Compártelo con tu responsable y tu equipo.
Crea una lista de “No debo olvidar esto”:
- Las rarezas extrañas que descubriste
- La infraestructura en la sombra que nadie reconoce como suya
- El conocimiento secreto que solo Carl de IT parece conocer
Convierte esa lista en documentos, automatizaciones o tickets—o guárdala cerca. Esto demuestra a la dirección que estás construyendo sistemas a prueba de incendios.
Consejo #9: Elige un proyecto de alto impacto y comienza a definirlo
A estas alturas, deberías tener suficientes señales para identificar un área principal de mejora. Utiliza el tramo final de tus primeros 90 días para acotarlo, socializarlo y obtener alineación.
- Migra los trabajos poco fiables a GitHub Actions
- Reemplaza un servidor insustituible por infraestructura como código
- Crea un camino dorado para que los desarrolladores creen nuevos servicios
Empieza en pequeño y demuestra tu valor. Documenta todo.
Palabras finales
Con suerte, en tus primeros 90 días, puedes estabilizar las cosas, desplegar lo que haga falta y, lo más importante, evitar que los ingenieros griten al vacío.
Esos primeros días se tratan de ganar tracción para el largo plazo. ¡Encuentra las grietas y documenta como un maniático!
¿No es tu primera vez en tecnología?
Este manual de DevOps es parte de una serie en crecimiento para nuevas contrataciones que quieren generar impacto antes de que les asignen la “herencia” de sistemas antiguos.
👉 ¿Acabas de comenzar en un puesto de Ingeniero de Seguridad? Te tenemos cubierto:
Los primeros 90 días: Edición ciberseguridad
👉 ¿Prefieres los commits que el acceso root? Consulta:
Los primeros 90 días: Edición ingeniero de software
Y sí—pronto tendremos más roles. Mantente atento o, mejor aún, suscríbete al boletín para no perderte el próximo.
