SRE lleva a cabo 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 predispuestos inherentemente y tienen la capacidad de sustituir el trabajo humano por la automatización.
SRE también es conocida como un rol, el cual puede desarrollar una sola persona o bien un staff organizado en equipos responsables de aspectos tan relevantes como la disponibilidad, control de latencia, peformance, eficiencia, monitoreo, gestión de cambios, capacity planning, etc.
Para ser ingeniero de confiabilidad del sitio, es necesario contar con una formación un tanto híbrida, es decir contar con una trayectoria de desarrollo de software con experiencia en operaciones, o bien de administración de sistemas o de operaciones de TI con habilidades de desarrollo de software.
Adicionalmente SRE permite a los desarrolladores crear un marco propicio para la creación de aplicaciones o sistemas a gran escala, ayudando a que los equipos encuentren el equilibrio entre el lanzamiento de nuevas funcionalidades y la garantía de que sean confiables para los usuarios, aumentando la estabilidad de un sistema desde su origen y mientras evoluciona.
Cabe destacar que de acuerdo a un reporte de Abril de 2021 del DevOps Institute, el 22% de un total de 2000 organizaciones encuestadas han adoptado el modelo SRE, durante el año 2020 el porcentaje fue del 15%, es decir, se observa un marcado interés por este enfoque.
La SRE permite que los equipos determinen las características nuevas que se pueden lanzar y en qué momento, gracias al uso de acuerdos de nivel de servicio (SLA) para definir la confiabilidad requerida del sistema mediante indicadores de nivel de servicio (SLI) y objetivos de nivel de servicio (SLO).
SLA: Define las expectativas del cliente sobre el funcionamiento del servicio.Debe derivar de la SLO.
SLO: El objetivo del servicio que ayuda al equipo a mantenerse dentro de la SLA.
SLI: Las métricas reales de performance del servicio. El SLO es generalmente compuesto por múltiples SLIs.
El SLO se determina en función del tiempo de inactividad que se acordó como aceptable, denominado "estimación de errores", y representa el límite máximo de interrupciones y errores permitidos. Con la SRE no se espera un 100% de confiabilidad, sino anticipar y controlar el impacto de las fallas.
Es posible que el equipo de desarrollo alcance el límite de la estimación de errores al lanzar una nueva característica o funcionalidad. Al utilizarse este recurso junto con el SLO, se puede determinar si se debe lanzar un producto o un servicio según el margen de error disponible. Si un servicio está dentro de los parámetros de estimación de errores permitidos, el equipo de desarrollo puede lanzarlo cuando lo desee. Sin embargo, si el sistema tiene demasiados errores o interrupciones más prolongadas de lo previsto, no se podrán realizar lanzamientos nuevos hasta que los errores estén dentro de los parámetros.
Los ingenieros de SRE realizan tareas operativas y las relacionadas al proyecto. Google recomienda que los SRE dediquen hasta un 50% del tiempo a las operaciones. El resto del tiempo deben dedicarse a las tareas de desarrollo, como crear funciones nuevas, ampliar el sistema e implementar la automatización.
El equipo de desarrollo realiza pruebas automatizadas de las operaciones para demostrar la confiabilidad y puede ocuparse del resto del trabajo operativo y de los servicios con bajo rendimiento para evitar que los ingenieros inviertan demasiado tiempo en las operaciones de una aplicación o un servicio.
La automatización es una parte muy importante del trabajo de los ingenieros de confiabilidad del sitio. Si deben resolver un problema varias veces, deben automatizar la solución. Así también se garantiza que las tareas operativas ocupen un bajo porcentaje de su carga de trabajo.Mantener el equilibrio entre las operaciones y la labor de desarrollo es un elemento clave de la SRE.
SRE y su relación con DevOps
DevOps es un cambio cultural que rompe los silos entre los equipos de desarrollo, pruebas, control de calidad y operaciones para acelerar el desarrollo de aplicaciones y mejorar la calidad del software, aumentando la disponibilidad de la infraestructura, maximizando el rendimiento de las aplicaciones y reduciendo los costos. La SRE puede considerarse una implementación de DevOps.
En resumen, ambos se basan en las relaciones y la cultura del trabajo en equipo, y tienen como objetivo acortar la brecha entre los equipos de desarrollo y de operaciones para prestar servicios con mayor rapidez.
Los principales beneficios que ofrecen las prácticas de DevOps y de SRE incluyen:
• ciclos de vida de desarrollo de las aplicaciones más ágiles, haciendo cambios incrementales de forma rápida y eficiente
• mayor calidad y confiabilidad de los servicios, monitoreando el rendimiento y mejorar cuando sea necesario.
• reducir el número de silos de organización
• poseer y/o desarrollar una cultura de trabajo flexible, abierta y adaptable
• menor tiempo de TI por cada aplicación desarrollada, por ejemplo, utilizando la automatización siempre que sea posible.
Para destacar una diferencia, la SRE es diferente porque depende de los ingenieros de confiabilidad del sitio dentro del equipo de desarrollo, que también deben tener experiencia en operaciones, para eliminar los problemas de comunicación y de flujo de trabajo. Su función requiere las habilidades tanto del equipo de desarrollo como del de operaciones, ya que superpone las responsabilidades.
La SRE puede ayudar a los equipos de DevOps cuyos desarrolladores tengan demasiadas tareas operativas y necesiten a un especialista en dicho campo. En términos del código y las características nuevas, DevOps se concentra en aportar eficiencia a todo el proceso de desarrollo, mientras que la SRE se enfoca en equilibrar la confiabilidad del sitio con la creación de características nuevas.
Tecnologías para respaldar la SRE
Las plataformas de aplicaciones modernas basadas en la tecnología de contenedores, Kubernetes y los microservicios son fundamentales para las prácticas de DevOps, ya que permiten ofrecer servicios de software seguros e innovadores. La SRE se basa en la automatización de las tareas operativas de rutina y la estandarización en todo el ciclo de vida de las aplicaciones. Un ejemplo son los contendores de Linux, que brindan al equipo la tecnología subyacente necesaria para desarrollar las aplicaciones on-premises y/o en la nube, y habilitan un entorno unificado para el diseño, la distribución, la integración y la automatización.
Por otro lado, Kubernetes, moderna plataforma para automatizar las operaciones de los contenedores de Linux y permitir la gestión de clústeres que ejecutan estos contenedores en todas las nubes públicas, privadas o híbridas con facilidad y eficiencia.
Con la plataforma adecuada puede aprovechar mejor los cambios que implementó en la cultura y en los procesos.
Red Hat Openshift Container Platform es la plataforma Kubernetes empresarial que respalda las iniciativas de SRE. https://www.redhat.com/es/technologies/cloud-computing/openshift Para establecer un esquema potente, escalable y amigable de automatización dentro de su empresa contamos con la Red Hat Automation Platform https://www.redhat.com/es/technologies/management/ansible Con IBM Instana (producto APM, Application Performance Monitoring) las empresas obtendrán observabilidad empresarial para mejorar la gestión del rendimiento de las aplicaciones, independientemente de dónde residan: nube pública, nube privada, nube híbrida, u on-premises, y permitirá al equipo de SRE establecer SLAs y SLOs más precisos. https://www.instana.com/
Fuentes
https://discoverthenew.ituser.es/devops/2019/02/que-es-sre-y-en-que-se-parece-y-diferencia-de-
devops
https://www.redhat.com/es/topics/devops/what-is-sre
https://www.devopsinstitute.com/devops-institute-announces-the-upskilling-2021-enterprise-
devops-skills-report-press-release/
https://opsani.com/resources/site-reliability-engineering-service-level-agreement-terms-explained-
sla-slo-sli/
