¿Qué es un SRE? El papel vital del ingeniero de confiabilidad del sitio

A medida que el mundo ha cambiado en línea, la confiabilidad de los sitios web, las aplicaciones en la nube y la infraestructura en la nube se ha convertido en un imperativo comercial crítico, para todo, desde operaciones de comercio electrónico hasta bancos globales y motores de búsqueda.

La forma en que administramos los sistemas y sus cargas de trabajo ha cambiado. Hoy en día, rara vez pensamos en términos de servidores valiosos, de alto contacto y de alto rendimiento, sino que, en su lugar, los servidores básicos se agrupan a través de la virtualización, con una arquitectura de software distribuida que evita que las interrupciones del servidor causen tiempo de inactividad. El enfoque ha cambiado del hardware a la infraestructura definida por software y de los procesos manuales inconsistentes y propensos a errores a tareas automatizadas consistentes, confiables y repetibles.

La ingeniería de confiabilidad del sitio es la práctica de mantener esa infraestructura programable y maximizar la disponibilidad de las cargas de trabajo que se ejecutan en ella. El puesto de ingeniero de confiabilidad del sitio (SRE) se originó en los pasillos de Google, que, en el cambio de milenio, quería redefinir la relación entre los desarrolladores de software y el personal de operaciones, y ayudarlos a trabajar juntos para construir sistemas resistentes y flexibles, con la mejora constante y la automatización como principios fundamentales.

¿Qué es un SRE?

A nivel básico, los SRE aportan principios de ingeniería de software a problemas de infraestructura y operaciones, con el objetivo estrella del norte de crear sistemas altamente escalables y confiables.

“Básicamente, es lo que sucede cuando le pides a un ingeniero de software que diseñe una función de operaciones”, como suele decirse Ben Treynor, vicepresidente de ingeniería de Google y padrino de SRE.

La principal de las responsabilidades de la SRE es establecer umbrales de nivel de servicio, que a menudo se manifiestan como objetivos de nivel de servicio (SLO), que ayudan a informar si una versión se autoriza o no. El santo grial es siempre el sagrado 'cinco nueves' o el 99,999% de tiempo de actividad. Cuanto mejor sea el tiempo de actividad, más desarrolladores de cuerdas podrán lanzar cosas nuevas y geniales y más sueño tendrán los SRE, lo que lleva a una relación de beneficio mutuo entre las funciones, muy lejos de los viejos tiempos de antagonismo entre desarrolladores y operaciones.

Una función de SRE se medirá típicamente en un conjunto de métricas de confiabilidad clave, a saber: rendimiento del sistema, disponibilidad, latencia, eficiencia, monitoreo, planificación de capacidad y respuesta a emergencias.

[También en: Supervisión de aplicaciones: lo que DevOps puede hacer mejor]

Responsabilidades laborales clave de un SRE

Cualquier buen SRE estará obsesionado con una cosa en particular: la automatización.

Como afirma Jason Qualman, un SRE en el proveedor de software de monitoreo New Relic, en una publicación de blog: “Gran parte de esta función consiste en pensar en cosas ineficientes y que requieren mucho tiempo que la gente está haciendo y ponerles fin lo antes posible. En lugar de dar una patada en el camino al trabajo manual, estás diciendo: 'Voy a tomarme el tiempo para automatizar esto ahora mismo y evitar que nadie más tenga que hacer esta cosa dolorosa' ".

Otro elemento clave de la función de SRE es algo denominado "ingeniería de versiones", que implica definir las mejores prácticas para garantizar que las versiones de software sean coherentes y repetibles.

“Los ingenieros de versiones tienen un conocimiento sólido (si no experto) de la administración de código fuente, compiladores, lenguajes de configuración de compilación, herramientas de compilación automatizadas, administradores de paquetes e instaladores. Su conjunto de habilidades incluye un conocimiento profundo de múltiples dominios: desarrollo, administración de configuración, integración de pruebas, administración de sistemas y soporte al cliente ”, escribió Dinah McNutt, gerente de programa técnico de Google, para el libro seminal Site Reliability Engineering (publicado por O'Reilly en 2016 y escrito por los empleados de Google Jennifer Petoff, Niall Richard Murphy, Chris Jones y Betsy Beyer).

Luego está la parte de respuesta del rol, que implica alertar, estar de guardia y solucionar problemas, junto con respuesta a emergencias e incidentes y autopsias.

Esencialmente, es importante que los SRE sepan cuál es la mejor manera de monitorear los sistemas y reaccionar cuando las cosas van mal, escribiendo y reescribiendo constantemente los libros de estrategias de respuesta para reducir el tiempo para corregir cualquier falla que pueda ocurrir. En Google, esto implica documentar un incidente, comprender todas las causas fundamentales que contribuyen e implementar acciones preventivas futuras.

"Escribir una autopsia no es un castigo, es una oportunidad de aprendizaje para toda la empresa", escriben los empleados de Google John Lunney y Sue Lueder en un capítulo del libro Site Reliability Engineering .

[También sobre: ​​3 pasos para aplicar metodologías ágiles en las operaciones de TI]

SRE vs ingenieros devops

Sé lo que estás pensando. Todo eso suena mucho a devops, pero cuando se trata de terminología, el puesto de trabajo de SRE en realidad es anterior al ingeniero de devops en unos cinco años.

Ambos se basan en principios similares, pero la diferencia es sutil e importante. Ambas formas de trabajo implican derribar las barreras entre los desarrolladores y el personal de operaciones, y ambas tienen como objetivo aumentar la velocidad de los equipos de desarrolladores mientras se mantiene la resistencia central de esos servicios.

La diferencia clave es que los ingenieros de devops tienden a centrarse en respaldar la entrega continua y la velocidad del desarrollador, mientras que los SRE asumen la responsabilidad de la confiabilidad y la automatización a lo largo del ciclo de vida del software, con énfasis en la implementación y el monitoreo exitoso de las versiones y en mantener funcionando la infraestructura definida por software. El SRE tiene una función integral dentro del equipo de ingeniería más amplio: garantizar que haya un asiento de especialista en la mesa enfocado en la construcción de sistemas estables.

Como dice Jayne Groll de The Devops Institute: “Devops se enfoca en diseñar la entrega continua hasta el punto de implementación; SRE se centra en la ingeniería de operaciones continuas en el punto de consumo del cliente ".

La historia de SRE en Google

Rastrear los principios de SRE hasta sus orígenes en Google a principios de la década de 2000 proporciona una lección fundamental en la disciplina.

“Cuando llegué a Google, tuve la suerte de ser parte de un equipo que estaba parcialmente compuesto por personas que eran ingenieros de software y que estaban inclinados a utilizar el software como una forma de resolver problemas que históricamente se habían resuelto a mano. Entonces, cuando llegó el momento de crear un equipo formal para realizar este trabajo operativo, fue natural adoptar el enfoque de 'todo puede tratarse como un problema de software' y ejecutarlo ”, afirmó Ben Treynor en una entrevista en el blog interno de Google.

“Por lo tanto, SRE básicamente está haciendo un trabajo que históricamente ha sido realizado por un equipo de operaciones, pero utilizando ingenieros con experiencia en software, y confiando en el hecho de que estos ingenieros están inherentemente predispuestos y tienen la capacidad de sustituir el trabajo humano por la automatización, ”Agrega Treynor.

Google también piensa de manera bastante rígida sobre cómo armar un equipo SRE. Todos los SRE de Google deben ser ingenieros de software de Google o "candidatos que estén muy cerca de las calificaciones de ingeniería de software de Google". También deben tener habilidades de administración de infraestructura, más comúnmente "conocimientos internos de sistemas Unix y redes (Capa 1 a Capa 3)".

Las calificaciones de SRE aún tienden a variar de una compañía a otra, pero en lo que respecta a los principios básicos, el enfoque de Google es un punto de partida sólido. Los detalles dependerán de las necesidades comerciales, los procesos establecidos y la pila tecnológica ya adoptada por la organización.

Descripción del puesto y salario de la SRE

Los SRE suelen dedicar alrededor del 50 por ciento de su tiempo a realizar funciones de operaciones tradicionales, como estar de guardia y participar para resolver problemas. El otro 50 por ciento se enfoca en desarrollar software para hacer que los sistemas subyacentes sean más resistentes, automatizados y autorreparables con el tiempo. Es por eso que el puesto requiere una combinación sólida de habilidades de ingeniería de software y operaciones. Un buen SRE estará organizado, se enfriará bajo presión y resolverá problemas. Los gerentes de SRE son responsables del desempeño, la estrategia y la optimización del equipo.

Pero, ¿qué pasa con las organizaciones donde no existe el rol de SRE? En el informe de O'Reilly "¿Qué es SRE?" Kurt Andersen de LinkedIn y Craig Sebenik de Split (un proveedor de software de administración de versiones) recomiendan adoptar un enfoque "de base". Recomiendan encontrar “un equipo de desarrollo que esté motivado para cambiar e implementar un pequeño equipo (o individuo) de SRE allí. Con el tiempo, puede utilizar ese éxito como un ejemplo positivo para otros equipos ".

El salario anual promedio de un SRE es de aproximadamente $ 130,000 en los EE. UU. Y £ 76,000 en el Reino Unido, según el sitio de trabajo Indeed.

Recursos de la SRE

Abundan los recursos para desarrollar habilidades de SRE, desde certificaciones del DevOps Institute hasta libros y recursos en línea de O'Reilly, Microsoft y Google. El ya mencionado gigante Site Reliability Engineering de 550 páginas   de Jennifer Petoff, Niall Richard Murphy, Chris Jones y Betsy Beyer es el tomo de referencia sobre el tema, publicado en 2016. El libro también está disponible en línea de forma gratuita en Google. 

Otros libros más recientes sobre el tema incluyen  Training Site Reliability Engineers  de Jennifer Petoff, JC van Winkel y Preston Yoshioka; ¿Qué es SRE?  por Kurt Andersen y Craig Sebenik; Seeking SRE  por David N. Blank-Edelman, y  The Site Reliability Workbook  de Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara y Stephen Thorne.

O'Reilly también tiene una biblioteca completa de activos en línea, videos y libros electrónicos sobre el tema, cuidadosamente seleccionados en esta lista de reproducción de SRE Essentials por la ex ingeniera de confiabilidad del sitio de Google, Liz Fong-Jones.

El gigante del aprendizaje en línea Coursera ofrece varios cursos, incluido el popular Site Reliability Engineering: Measuring and Managing Reliability from Google Cloud Training. Este curso también está disponible en Pluralsight, al igual que el curso para principiantes Ingeniería de confiabilidad del sitio (SRE): el panorama general de Elton Stoneman. Linux Foundation ofrece un curso autoguiado titulado DevOps and SRE Fundamentals: Implementing Continuous Delivery.

Jellyfish Training, con sede en el Reino Unido, ofrece varias opciones de cursos de formación privados de dos días para la Fundación SRE (SREF).

Leer más sobre devops

  • ¿Qué es devops? Transformando el desarrollo de software
  • 3 formas de iniciar un programa devops
  • Mejores prácticas de Devops: los 5 métodos que debe adoptar
  • 15 KPI para rastrear la transformación de devops
  • Supervisión de aplicaciones: lo que DevOps puede hacer mejor
  • Donde la ingeniería de confiabilidad del sitio se encuentra con devops
  • 5 principios para convertirse en un equipo colaborativo ágil de devops
  • 3 pasos para aplicar metodologías ágiles en operaciones de TI
  • Cómo los equipos ágiles pueden respaldar la gestión de incidentes
  • Cómo Dataops mejora los datos, el análisis y el aprendizaje automático
  • Aplicación de devops en ciencia de datos y aprendizaje automático
  • 7 preguntas para priorizar su backlog de devops