Ingeniería
Ingeniero de software
Cinco niveles de júnior a principal y seis competencias, desde entregar código hasta hacer crecer al equipo.
- 5 niveles
- 6 competencias
Plantilla de escalera de carrera
Cuatro niveles de ingeniero DevOps júnior a staff y seis competencias, de la infraestructura al apoyo a los desarrolladores.
Plan gratuito · Sin tarjeta de crédito
Esta escalera de carrera es para ingenieros DevOps, de plataforma y de infraestructura en empresas de unas 20 a 200 personas. A ese tamaño, el equipo de infraestructura suele ser de una a seis personas que gestionan las cuentas cloud, los pipelines de entrega, la monitorización y las guardias, y que dedican tanto tiempo a ayudar a los desarrolladores como a tocar servidores. Describe cuatro niveles, desde alguien que hace cambios de infraestructura bien acotados hasta la persona responsable de la dirección de la plataforma de la empresa. Su nivel más alto, Ingeniero DevOps staff, es un nivel de especialista; gestionar el equipo de infraestructura es otro trabajo.
Cada nivel se define por lo que hace la persona y por cuánto del sistema se le confía, no por los años de experiencia ni por el número de herramientas de su CV. Lee una fila de la matriz de competencias de izquierda a derecha para ver cómo crece una expectativa; lee la sección de un nivel para ver todo lo que se espera en él. Úsala para explicar qué significa el siguiente nivel, para estructurar los check-ins y para tomar decisiones de ascenso que puedas defender.
Adáptala antes de publicarla. Sustituye la redacción genérica por tu propio stack y tus propias prácticas, y elimina las partes que corresponden a otro equipo, por ejemplo si la seguridad o las bases de datos dependen de otra área.
Hace cambios bien acotados en la infraestructura y los pipelines, con revisión, y aprende cómo funciona producción.
Es responsable de partes de la infraestructura de principio a fin y asume su parte completa de las guardias.
Diseña y lidera proyectos de infraestructura de los que dependen varios equipos, y eleva el listón de fiabilidad.
Marca la dirección de la plataforma de la empresa y responde de su fiabilidad, su seguridad y su coste.
Cada fila es una competencia y cada columna, un nivel. Lee una fila de izquierda a derecha para ver cómo crece lo que se espera.
| Competencia | Ingeniero DevOps júnior | Ingeniero DevOps | Ingeniero DevOps sénior | Ingeniero DevOps staff |
|---|---|---|---|---|
| Infraestructura como código | Hace cambios en el código de infraestructura existente siguiendo los patrones ya establecidos, revisa el diff previsto antes de aplicarlo y nunca cambia producción a mano sin preguntar antes. | Escribe módulos de infraestructura reutilizables para servicios y entornos nuevos, gestiona el estado y los secretos de forma segura y elimina los recursos que ya no se usan. | Diseña la organización del código de infraestructura y de los entornos de la empresa, lidera cambios como actualizaciones de red o de clúster con un plan de rollback probado y mantiene visible el gasto en cloud por equipo. | Elige los componentes y proveedores básicos de la plataforma para los próximos años, fija los estándares que sigue la infraestructura de todos los equipos y es responsable del presupuesto de infraestructura junto con la dirección. |
| Pipelines de build y entrega | Arregla pasos rotos de los pipelines y añade jobs sencillos a pipelines existentes, y sabe explicar a un desarrollador por qué ha fallado su build. | Construye y mantiene el pipeline completo de un servicio (build, tests, artefactos, despliegues en todos los entornos) y acelera los pasos lentos de los que se quejan los desarrolladores. | Diseña plantillas de pipeline compartidas que usan todos los equipos, introduce métodos de release más seguros como los despliegues canary o blue-green y hace seguimiento de la frecuencia de despliegue y la tasa de fallos. | Define cómo entrega software toda la empresa, desde la estrategia de ramas hasta el rollback, y elimina los cuellos de botella que frenan la entrega en todos los equipos. |
| Fiabilidad y respuesta a incidentes | Acompaña las guardias de otros, sigue los runbooks para las alertas conocidas y escala rápido con la información que necesita la siguiente persona. | Asume su parte completa de las guardias, resuelve sin ayuda la mayoría de los incidentes de su área, escribe runbooks de lo que ha arreglado y prueba las copias de seguridad restaurándolas de verdad. | Lidera la respuesta a los incidentes graves, dirige post-mortems sin culpables y lleva a término las acciones de seguimiento, y planifica la capacidad y el failover de los sistemas críticos. | Fija los objetivos de fiabilidad con producto y la dirección, diseña el proceso de guardias e incidentes para toda ingeniería y planifica para desastres como perder una región o un proveedor. |
| Monitorización y observabilidad | Añade dashboards y alertas siguiendo ejemplos existentes, y revisa primero los logs y las métricas cuando algo parece ir mal. | Configura logs, métricas y alertas para los servicios nuevos, ajusta las alertas para que cada aviso requiera una acción y ayuda a los desarrolladores a encontrar lo que necesitan en los datos. | Diseña el enfoque de observabilidad de los sistemas principales de la empresa, define las señales de salud de los servicios con las que se mide a los equipos y reduce el ruido de alertas en todos los equipos. | Elige las herramientas de observabilidad de la empresa y su modelo de costes, y se asegura de que la dirección pueda ver la salud de la plataforma sin tener que preguntar a un ingeniero. |
| Seguridad y accesos | Sigue las normas del equipo sobre secretos y accesos, aplica los parches rutinarios e informa de inmediato de cualquier cosa que parezca un problema de seguridad. | Gestiona los accesos y secretos de sus servicios con mínimo privilegio, parchea las vulnerabilidades según su gravedad y corrige los hallazgos de los escaneos de seguridad. | Diseña los límites de red, la gestión de identidades y la de secretos en toda la plataforma, prepara las evidencias para las revisiones de seguridad de los clientes y lidera la respuesta a los incidentes de seguridad. | Es responsable, junto con la dirección, de la postura de seguridad de la plataforma, fija los controles que exige el cumplimiento normativo (por ejemplo, SOC 2 o ISO 27001) y hace que el camino seguro sea el más fácil para todos los equipos. |
| Apoyo a los desarrolladores y colaboración | Responde a las preguntas de los desarrolladores sobre entornos y pipelines, documenta los arreglos que hace y pide revisión pronto. | Escribe guías claras para las tareas habituales, trabaja en pareja con los desarrolladores para desplegar y depurar sus servicios e introduce a los nuevos compañeros en la infraestructura. | Construye herramientas de autoservicio que permiten a los equipos crear servicios y entornos sin abrir un ticket, ejerce de mentor de otros ingenieros DevOps y participa en la contratación. | Trata la plataforma como un producto interno cuyos usuarios son los desarrolladores, decide qué es responsabilidad de los equipos y qué del equipo de plataforma, y hace crecer a los próximos ingenieros sénior. |
Desplaza la tabla hacia los lados para ver todos los niveles.
Descargar en CSV Se abre en Excel, Google Sheets o Numbers.
Hace cambios bien acotados en la infraestructura y los pipelines, con revisión, y aprende cómo funciona producción. Cambios concretos en el código de infraestructura y los pipelines existentes, planificados y revisados por alguien con más experiencia.
Es responsable de partes de la infraestructura de principio a fin y asume su parte completa de las guardias. Servicios, entornos o pipelines de uno o dos equipos de producto, desde el diseño hasta la operación diaria.
Diseña y lidera proyectos de infraestructura de los que dependen varios equipos, y eleva el listón de fiabilidad. La infraestructura compartida que usa la mayor parte de ingeniería, y proyectos como migraciones que afectan a todos los equipos.
Marca la dirección de la plataforma de la empresa y responde de su fiabilidad, su seguridad y su coste. Toda la plataforma de producción, su dirección a varios años vista y su presupuesto, para todos los equipos de ingeniería.
Expresiones genéricas como «código de infraestructura» o «pipelines» son fáciles de aceptar y difíciles de evaluar. Sustitúyelas por tus herramientas y prácticas reales, para que un ingeniero júnior sepa exactamente qué se espera que aprenda primero.
Con uno a tres ingenieros DevOps, los niveles júnior, intermedio y sénior suelen bastar. Añade el nivel staff cuando alguien esté marcando de verdad la dirección de la plataforma y sea responsable de su presupuesto para toda ingeniería, no como título para la persona con más experiencia de un equipo pequeño.
Indica en qué nivel se entra en las guardias, cuándo se lideran incidentes y cómo se compensa el tiempo de guardia. Las expectativas de guardia no escritas son uno de los motivos más habituales por los que los ingenieros de infraestructura se queman y se van.
Relaciona cada nivel DevOps con el nivel de ingeniero de software del mismo alcance y salario. El trabajo de plataforma es trabajo de ingeniería, y mantener las dos escaleras alineadas facilita los cambios entre equipos de producto y de plataforma.
Preguntas frecuentes
En sentido estricto, DevOps es una forma de trabajar, no un puesto; en la práctica, en empresas de 20 a 200 personas estos puestos describen casi siempre el mismo trabajo con distinto énfasis: los SRE se centran en los objetivos de fiabilidad (normalmente SLO y presupuestos de error) y en los incidentes, los ingenieros de plataforma en herramientas de autoservicio para los desarrolladores y los ingenieros DevOps en los pipelines y la infraestructura. Una sola escalera suele cubrir los tres; ajusta la redacción de las competencias en lugar de crear escaleras separadas.
Normalmente cuando los desarrolladores dedican una parte notable de su semana a despliegues, entornos y problemas de producción en lugar de a funcionalidades, o cuando los clientes empiezan a pedir compromisos de disponibilidad y revisiones de seguridad. En muchas empresas esto ocurre en torno a los 15 a 30 ingenieros.
Sí, pero cuenta lo que la persona aprende y mejora, no cuántos avisos ha atendido. Liderar bien un incidente grave, escribir post-mortems cuyas acciones se llevan a cabo y reducir el ruido de alertas son evidencias claras para el siguiente nivel. Estar de guardia a menudo no lo es.
Pueden ayudar a alguien a aprender una plataforma, pero no deberían decidir un nivel. Evalúa lo que la persona ha construido y gestionado en tu entorno frente a la matriz de competencias. Un certificado sin esa evidencia no demuestra el siguiente nivel; esa evidencia sin certificado, sí.
Tres o cuatro, porque los equipos de infraestructura en empresas de este tamaño son pequeños. Esta plantilla usa cuatro (Júnior, Ingeniero DevOps, Sénior y Staff) y funciona bien junto a una escalera de ingeniero de software de cinco niveles, con los niveles staff alineados.
Configura sus niveles y habilidades para tu equipo, evalúa a las personas con ellos en los check-ins y mantén la coherencia en las decisiones de ascenso.
Plan gratuito · Sin tarjeta de crédito
Ingeniería
Cinco niveles de júnior a principal y seis competencias, desde entregar código hasta hacer crecer al equipo.
Ingeniería
Cuatro niveles de ingeniero de QA júnior a líder y seis competencias, del diseño de pruebas a las prácticas de calidad.
Ingeniería
Cuatro niveles de Engineering Manager a VP de ingeniería, con seis competencias de gestión.