La ingeniería de confiabilidad del sitio es todavía una función de trabajo relativamente nueva y es un desafío obtener una imagen clara del día a día. Conozca cómo se ve el rol de una SRE con este perfil.
por Emily Mell
La ingeniería de confiabilidad del sitio es una práctica de DevOps en la que los profesionales de TI codifican y automatizan el mantenimiento y el soporte de la infraestructura y las aplicaciones. SRE se preocupa principalmente por la confiabilidad del servicio y comúnmente usa acuerdos de nivel de servicio para dictar y cumplir con las expectativas en torno a diversas métricas, como el tiempo de actividad.
¿Qué hace un ingeniero de confiabilidad del sitio?
Donde las organizaciones de DevOps fomentan relaciones más estrechas entre los equipos de desarrollo y operaciones, así como otras partes interesadas clave, como los equipos de redes, seguridad y pruebas, el equipo de ingeniería de confiabilidad del sitio actúa como líder de comunicación y, en ocasiones, incluso como embajador del proyecto. .
Saul Ortigoza, ingeniero senior de confiabilidad del sitio en Wizeline, una compañía global de desarrollo de productos con sede en San Francisco, usa una variedad de sombreros técnicos y culturales en cualquier día de trabajo. “Mi principal objetivo es lograr que [los clientes] y los ingenieros tengan éxito, y también ayudar a escalar la disciplina y la práctica de DevOps”, explicó Ortigoza.
Ortigoza comenzó con una licenciatura en ingeniería mecatrónica , para la cual trabajó en automatización industrial, dijo, con algo de codificación de bajo nivel e ingeniería eléctrica de bajo nivel en la mezcla. Su carrera comenzó en la industria automotriz, probando sistemas integrados, un rol que sentó las bases para un futuro puesto de SRE. “Empleaba la mayor parte de mi tiempo para mejorar los procesos y crear herramientas para facilitar el trabajo diario”, dijo. Esto lo llevó a comenzar a usar herramientas como Jenkins, un servidor de automatización de código abierto, y GitLab, una herramienta de ciclo de vida DevOps basada en Git, para construir un marco para el entorno de prueba.
¿Cómo es un rol de SRE en el día a día?
Cuando se le pidió que describiera un día normal en su rol, Ortigoza comenzó su lista con reuniones. Como SRE senior en Wizeline, actúa como intermediario entre las diferentes partes interesadas (clientes, líderes de equipos de TI y líderes comerciales) para garantizar que los proyectos se desarrollen y evolucionen sin problemas.
Saúl Ortigoza
Cada grupo de componentes de la SRE tiene diferentes necesidades y objetivos, que deben alinearse todos al final del día: los clientes tienen requisitos para sus entregables, y esos requisitos informan cómo Ortigoza solicita proyectos a sus desarrolladores, y esos desarrolladores tienen sus propias necesidades. para el éxito.
Como la mayoría de los profesionales de DevOps, Ortigoza señala que DevOps no es un rol de trabajo o algo que realiza una persona. “Es más una cultura … que todos tienen que [hacer] su parte, todos tienen que contribuir. Y lo más importante de esta cultura es la propiedad … todos son responsables de cualquier cosa que estemos haciendo”, dijo.
Una cultura de propiedad no es una cultura de culpar por fallas o fallas. Más bien, es una cuestión de independencia y responsabilidad colectiva. Esto fomenta la autosuficiencia y el trabajo de mayor calidad, porque si lo rompen, también tienen que arreglarlo.
“Uno de los [conceptos erróneos] más comunes es que un ingeniero de confiabilidad del sitio … hace todas las cosas relacionadas con CI / CD, infraestructura y automatización”, dijo Ortigoza y se rió. Y aunque la SRE definitivamente toca todas esas cosas, la función de la SRE es brindar orientación y soporte a los equipos de TI constituyentes, para permitir que los ingenieros hagan las cosas por sí mismos.
De hecho, el equipo de SRE es responsable de los proyectos terminados, lo que requiere una supervisión cercana y una comunicación regular, pero eso no significa arrebatar el control a los ingenieros encargados de proyectos determinados. En cambio, esta supervisión genera más oportunidades de apoyo y asistencia: cada profesional de TI aporta conocimientos y perspectivas únicos, todo lo cual es invaluable para el desarrollo exitoso de un proyecto.
Pero Ortigoza no solo permite que quienes lo rodean hagan su trabajo. Tiene su propio proyecto en Wizeline, con una gran empresa de tecnología que se negó a nombrar. Para este proyecto, actúa principalmente como arquitecto de infraestructura y lidera la tarea de construir una plataforma personalizada. Y aunque las reuniones y las habilidades de comunicación son clave, Ortigoza dijo que la arquitectura es la habilidad más importante para su rol de SRE.
“Los SRE están en etapa inicial. Saben un poco de todo”, dijo, incluyendo codificación, pruebas, seguridad y administración de proyectos, y mucha infraestructura y automatización.
DevOps e IaC
“El noventa por ciento del trabajo [en Wizeline] es con clientes externos. Y [la infraestructura como código] es una práctica estándar para DevOps y proyectos de confiabilidad”, explicó Ortigoza. Y justo cuando IaC se convierte en una práctica estándar en las organizaciones de DevOps, Terraform se está convirtiendo rápidamente en una parte esencial de los kits de herramientas de IaC; Ortigoza estima que el 80% de los proyectos de IaC que ve dependen de Terraform, junto con una variedad de otras herramientas que se integran con él. CloudFormation es otra opción popular , así como varios marcos sin servidor . “Terraform es muy bueno para, quizás, recursos de alias, pero también estamos usando Kubernetes; también usaremos algo como Helm, o herramientas creadas alrededor de Helm, para implementar también patrones de infraestructura como código”, dijo Ortigoza.
Ortigoza también recomienda llevar IaC un paso, o un salto, más allá y adoptar un enfoque de todo como código para todo el ecosistema de TI, que dice que incluye cosas como políticas e incluso documentación . Cuando la documentación se registra y almacena en una variedad de lugares, como una base de datos de administración de configuración y un documento de Google o, peor aún, localmente en la computadora de alguien, es muy fácil perder el rastro de la información. También es fácil para la documentación comenzar a crear árboles con diferentes personas que actualizan información diferente en diferentes momentos. Toda esa información debe codificarse y almacenarse lo más cerca posible de su tema; esto facilita el proceso para actualizar la documentación cuando se actualiza el código mismo, porque no es necesario buscarlo.
Consejos para principiantes en DevOps
Siempre les digo a mis ingenieros … que el software no es código.
“Una de las principales cosas que DevOps intenta resolver es … equipos multifuncionales”, dijo Ortigoza. Porque si bien los equipos multifuncionales son ideales para DevOps, a menudo es difícil organizar una integración estrecha de esos cruces y, en última instancia, muchas organizaciones implementan silos de DevOps. Incluso un silo de DevOps sigue siendo un silo y, en última instancia, daña más a la organización de TI de lo que ayuda. “No tener equipos multifuncionales lo ralentizará mucho porque habrá muchas barreras y … pasar cosas de un equipo a otro. Esto es muy malo para la velocidad de retroalimentación y para la comunicación de hacer las cosas”.
El principal consejo de Ortigoza es ver las cosas de manera integral. “Siempre les digo a mis ingenieros … que el software no es código”, dijo. El software es, en cambio, una gran cantidad de partes móviles suministradas por muchos equipos diferentes, como la documentación de prueba y la seguridad, y todas esas piezas son tan importantes como el código escrito de los desarrolladores.
Se supone que DevOps facilitará este proceso y la interacción, dijo, porque sus objetivos incluyen ese equipo multifuncional, y el liderazgo senior estará formado por expertos que invertirán en esas áreas. El consejo de Ortigoza: Escuche a esos expertos. Pero permanezca abierto al diálogo; En una organización DevOps, todo profesional de TI debe abordar su trabajo con una mentalidad de propiedad y esforzarse por lograr la autosuficiencia siempre que sea posible. Porque la SRE está ahí para guiarte, no para hacer tu trabajo por ti.
Por último: “No intente resolver los problemas de las personas con la tecnología”, dijo Ortigoza.
Existen innumerables aplicaciones y herramientas destinadas a resolver todos sus problemas, pero a veces la introducción de una nueva herramienta puede exacerbar un problema de personas, en lugar de resolverlo. En lugar de buscar el estante de las herramientas disponibles, evalúe su organización y su cultura y, en su lugar, busque la fuente del problema que desea resolver. Una nueva aplicación brillante no solucionará eso por ti.
