# data[].attributes.body
¿Qué es DevOps? El término "DevOps" generalmente se refiere a un movimiento profesional que aboga por una relación de trabajo colaborativo entre el Desarrollo y las Operaciones de TI, lo que resulta en un rápido flujo de trabajo planificado.

Para garantizar que este enfoque sea factible, debe haber los siguientes roles de DevOps:

1. Propietario del Producto (Product Owner) La intersección entre el equipo y el cliente, rol que comprende cómo debe ejecutarse la aplicación para ofrecer valor a los usuarios y qué infraestructura de nube se necesita para admitir la aplicación en producción. Puede ser una persona del lado del cliente o del equipo de DevOps subcontratado, según los requisitos del proyecto y otros factores.

2. Jefe de Equipo (Team Lead ) Este es el puesto para el miembro del equipo más experimentado, que puede analizar el conjunto de habilidades requeridas para cada proyecto y delegar las responsabilidades de DevOps en todo el equipo.

3. Cloud Architect, Persona con amplia experiencia práctica en la construcción de infraestructuras Cloud, y en la comprensión de lo que tienen que incluir para admitir varios tipos de aplicaciones y servicios en producción.

4. Site Reliability Engineer (SRE) Especialista en DevOps que se concentra en garantizar un rendimiento estable y una disponibilidad ininterrumpida de aplicaciones de alta carga en sistemas a gran escala.

5. Administrador del Sistema DevOps Es una de los roles principales de DevOps, ya que la supervisión en la nube representa más de la mitad de todas las tareas y el tiempo de DevOps. Cada miembro del equipo debe ser capaz de manejar las tareas de soporte, sin embargo, estos son el pan de cada día para el administrador de soporte.

La ingeniería de confiabilidad del sitio (SRE) es un enfoque de ingeniería de software para las operaciones de TI. Los equipos de SRE utilizan el software para gestionar los sistemas, resolver los problemas y automatizar las tareas operativas.

La SRE asigna las tareas que siempre han realizado los equipos de operaciones, muchas veces de forma manual, a los ingenieros o a los equipos de operaciones, que utilizan el software y la automatización para resolver los problemas y gestionar los sistemas de producción.

Comparación entre DevOps y la SRE

DevOps es un modo de abordar la cultura, la automatización y el diseño de las plataformas para generar mayor valor empresarial y capacidad de respuesta, mediante la prestación ágil de servicios de alta calidad. La SRE puede considerarse una implementación de DevOps.

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.

Algunos de los beneficios que ofrecen las prácticas de DevOps y de SRE incluyen ciclos de vida de desarrollo de las aplicaciones más rápidos, mayor calidad y confiabilidad de los servicios y menor tiempo de TI por cada aplicación desarrollada.

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.

https://www.tecnologias-informacion.com/devops.html
https://www.redhat.com/es/topics/devops/what-is-sre#comparaci%C3%B3n-entre-devops-y-la-sre

# data[].attributes.body
¿Qué hace Site Reliability Engineer?

Site Reliability Engineer (SRE) es un rol de gestion de proyectos que colabora con los procesos entre el desarrollo de software para la mejora de la estabilidad y el rendimiento; y la monitorización y resolución de problemas, con el fin de asegurar tanto la disponibilidad del servicio como el crecimiento y la innovación empresarial.

# data[].attributes.body
No hay una descripción del cargo única para el puesto de SRE, lo que sí hay, no obstante, es coincidencia en que el SRE debe asegurar(se) de la disponibilidad, el rendimiento, la monitorización y la respuesta a incidencias de las plataformas y servicios que opera su organización. Los equipos SRE personifican la filosofía DevOps poniendo el foco en los objetivos antes mencionados.
El equipo de SRE tiene la función de ejecutar y operar sistemas complejos a gran escala para clientes internos y externos en la nube.
Se puede agregar que el SRE se encargan de la forma en que se implementa, configura y supervisa el código, así como de la disponibilidad, la latencia, la gestión de los cambios, la respuesta ante emergencias y la gestión de la capacidad de los servicios en la producción.

# data[].attributes.body
Aunque es una posición que pertenece a la tanda de nuevas profesiones, el puesto de Site Reliabiliy Engineer Hace ya 15 años que Ben Treynor, Vicepresidente de Ingeniería de Google, creó el concepto Site Reliability Engineering para solventar los problemas que surgían entre los equipos de desarrollo y los de operaciones. A los primeros le preocupaba desarrollar el código para desplegar nuevas funcionalidades, mientras los segundos estaban pendientes de que el código funcionara y si no lo hacía, lo devolvían a los desarrolladores. La tensión entre ambos equipos era permanente. Los desarrolladores perseguían nuevas características y velocidad, al tiempo que sus compañeros de operaciones buscaban la estabilidad, lo que en ocasiones obligaba a ir más despacio. En definitiva, unos y otros tenían objetivos distintos: funcionalidad vs. estabilidad.

Para limar estas asperezas nació lo que se conoce como la cultura DevOps, un modelo diseñado para derribar las barreras entre los equipos y equilibrar las diferencias entre desarrolladores, sistemas y otras áreas del trabajo en las empresas tecnológicas. Sin entrar en demasiados detalles, en resumen, las prácticas DevOps implican intentar reducir los problemas de la organización, entender que errar es parte del proceso, implementar los cambios de forma continua y gradual, utilizar herramientas de aprovisionamiento, de automatización de procesos, y, por supuesto, medirlo todo.

En un entorno como el de hoy, cambiante y permanente evolución, la presión por ser cada vez más ágiles en los tiempos de salida al mercado, manteniendo la estabilidad o la fiabilidad de los productos al 100%, va en aumento. La cultura DevOps, que se adopta en los equipos de TI –de los cuales el de SRE forma parte–, tiene como objetivo crear un ambiente colaborativo en función de una meta común, logrando que los departamentos de operaciones y desarrollo estandaricen procesos comunes, así como herramientas ágiles para la entrega de software.

Depende, fundamentalmente, del tamaño de la empresa, su actividad y de cuáles sean las prioridades de ésta. Por otra parte, aunque la posición es relativamente nueva para el mundo en general, en las empresas tecnológicas adquiere cada vez mayor protagonismo y todas las grandes del sector, como Dropbox, Twitter,
Apple y, por supuesto, el pionero Google, incluyen el puesto entre sus filas.

Como ya hemos mencionado, no hay una descripción del cargo única para el puesto de SRE, lo que sí hay, no obstante, es coincidencia en que el SRE debe asegurar(se) de la disponibilidad, el rendimiento, la monitorización y la respuesta a incidencias de las plataformas y servicios que opera su organización. Los equipos SRE personifican la filosofía DevOps poniendo el foco en los objetivos antes mencionados.

Dentro de las tareas del equipo de SRE está, claramente, la mejora continua de los sistemas a través de la incorporación de nuevos servicios y funcionalidades. Además, por supuesto, de la resolución, cuando ocurren incidencias, de los problemas subyacentes para garantizar que todo vuelva rápidamente a la normalidad. Dada la escala a la que trabajan normalmente los equipos de SRE, es prácticamente imposible que no haya incidentes de vez en cuando. Sin embargo, hay una manera de que los mismos incidentes no se repitan: el postmortem. Este proceso que es, en rigor, una autopsia de lo ocurrido permite a los miembros del equipo de SRE formalizar el proceso de aprendizaje a partir de los errores o fallos del sistema. El concepto es bien conocido en el sector tecnológico y de acuerdo a la definición de John Lunney y Sue Lueder “es un registro escrito de un incidente, su impacto, las acciones tomadas para mitigarlo o resolverlo, la(s) causa(s) raíz y las acciones de seguimiento para evitar que el incidente vuelva a ocurrir”. En cualquier caso, es una parte importante del trabajo de los equipos de SRE.

Quienes lo conforman son personas proactivas e innovadoras que proporcionan diversos enfoques de ingeniería de software para resolver los desafíos que plantea tanto a nivel operativo como a nivel de desarrollo y mantenimiento de infraestructura. Cualquiera que forme parte de ese equipo desempeña un papel importante en el desarrollo de los productos y servicios de la empresa.

El SRE en Magnolia trabaja en el corazón de nuestro sistema de producción, supervisando el desempeño del servicio y que todo esté en orden, definiendo y administrando la infraestructura como código (IaC) en la nube, mejorando los pipelines de CI/CD, construyendo los sistemas de monitorización e implementando los sistemas de aprovisionamiento y orquestación.

Además, los miembros del equipo de SRE colaboran en el diseño, construcción y despliegue de servicios escalables, en las revisiones de la arquitectura, en las pruebas de vulnerabilidad y en las revisiones de seguridad.
Para entrar a formar parte de este equipo hace falta tener un grado en Informática o en un campo técnico relacionado, o experiencia práctica equivalente, además de experiencia comprobada con infraestructura en la nube (AWS y Terraform), herramientas de administración de configuración (Ansible), entrega continua y tecnologías de contenedores (Docker, Kubernetes).

En una posición de SRE es muy importante la capacidad de análisis y solución de problemas distribuidos en la producción a gran escala. Es importante tener experiencia en programación con uno o más lenguajes relevantes: Java, Python, Bash, Go, JavaScript, así como en la operación, optimización y escalado de bases de datos SQL, tecnología de contenedores y clústeres gestionados con Kubernetes.
Hay que estar familiarizado con los estándares de seguridad y operación, así como con las mejores prácticas sobre datos personales. Y en Magnolia, además valoramos mucho las habilidades de comunicación sólidas y la pasión por lo que hacemos.

# data[].attributes.body
El Site Reliability Engineer (SRE) es un puesto que reparte su tiempo entre el desarrollo de software para la mejora de la estabilidad y el rendimiento; y la monitorización y resolución de problemas, con el fin de asegurar tanto la disponibilidad del servicio como el crecimiento y la innovación empresarial.

Los y las especialistas en SRE se dedican a idear sistemas que presentan una alta tolerancia ante los fallos, utilizando estrategias como la degradación gradual (desactivación de algunos procesos para que el sistema siga funcionando, aun con incidencias); o la defensa en profundidad, que prevé vías para que los errores se corrijan por sí solos de manera automática.

# data[].attributes.attachment_link.title
What is Site Reliability Engineering (SRE)

# data[].attributes.attachment_link.description
SRE leverages operations data and software engineering to automate IT operations tasks, and to accelerate software delivery while minimizing IT risk

# data[].attributes.body
-Su objetivo es mantener enfocada a la organización enfocada en lo que realmente le importa al cliente

-Se encarga de  asegurar que las plataformas y servicios sean confiables y estén habilitadas para cuando el cliente quiera usarlas

-Se encarga de reducir los tiempos de respuesta  cuando aparecen los incidentes y problemas de la manera mas eficiente posible

Fuente:https://www.gremlin.com/site-reliability-engineering/the-role-and-responsibilities-of-sres-in-software-engineering/

# data[].attributes.body
https://www.youtube.com/watch?v=xin3Tb8f31M

# data[].attributes.body
"Los equipos de SRE se encargan de la forma en que se implementa, configura y supervisa el código, así como de la disponibilidad, la latencia, la gestión de los cambios, la respuesta ante emergencias y la gestión de la capacidad de los servicios en la producción."

LINK: https://www.redhat.com/es/topics/devops/what-is-sre

# data[].attributes.attachment_link.readable_text
Para ser ingeniero de confiabilidad del sitio, es necesario contar con una trayectoria de desarrollo de software con experiencia adicional en operaciones, o bien de administración de sistemas o de operaciones de TI con habilidades de desarrollo de software.

Los equipos de SRE se encargan de la forma en que se implementa, configura y supervisa el código, así como de la disponibilidad, la latencia, la gestión de los cambios, la respuesta ante emergencias y la gestión de la capacidad de los servicios en la producción.

La ingeniería de confiabilidad del sitio 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).

Los SLI son medidas definidas de aspectos específicos sobre los niveles de servicio que se proporcionan. Los más importantes son la latencia de las solicitudes, la disponibilidad, la tasa de errores y el rendimiento del sistema. Los SLO se basan en el valor o el rango objetivo para un nivel de servicio específico basado en el SLI.

El objetivo de nivel de servicio se determina en función del tiempo de inactividad que se acordó como aceptable, denominado "estimación de errores", que representa el límite máximo de interrupciones y errores permitidos.

Con la SRE no se espera una confiabilidad al 100 %, sino que se planifican y se aceptan las fallas.

Es posible que el equipo de desarrollo alcance el límite de la estimación de errores al lanzar una característica nueva. Pero al utilizar este recurso junto con el SLO, puede determinar si 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 que se prevé en la estimación, no se podrán realizar lanzamientos nuevos hasta que los errores estén dentro de los parámetros.

El equipo de desarrollo realiza pruebas automatizadas de las operaciones para demostrar la confiabilidad.

Los ingenieros de confiabilidad del sitio dividen el trabajo entre las tareas operativas y las del proyecto. Según las prácticas recomendadas de Google para los SRE, pueden dedicar hasta un 50 % del tiempo a las operaciones y deben estar bajo supervisión para no excederse.

El resto del tiempo deben dedicarlo a las tareas de desarrollo, como crear funciones nuevas, ampliar el sistema e implementar la automatización.

El equipo de desarrollo 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 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 solo la mitad de su carga de trabajo.

Mantener el equilibrio entre las operaciones y la labor de desarrollo es un elemento clave de la SRE.

# data[].attributes.attachment_link.description
Para ser ingeniero de confiabilidad del sitio, es necesario contar con una trayectoria de desarrollo de software con experiencia adicional en operaciones, o bien de administración de sistemas o de operaciones de TI con habilidades de desarrollo de software.

# data[].attributes.body
El Site Reliability Engineer (SRE) es un puesto que reparte su tiempo entre el desarrollo de software para la mejora de la estabilidad y el rendimiento; y la monitorización y resolución de problemas, con el fin de asegurar tanto la disponibilidad del servicio como el crecimiento y la innovación empresarial.

Los y las especialistas en SRE se dedican a idear sistemas que presentan una alta tolerancia ante los fallos, utilizando estrategias como la degradación gradual (desactivación de algunos procesos para que el sistema siga funcionando, aun con incidencias); o la defensa en profundidad, que prevé vías para que los errores se corrijan por sí solos de manera automática.

# data[].attributes.body
Los siete roles DevOps principales

Adoptar roles nuevos o redefinidos no es suficiente para una transformación exitosa de DevOps, pero es un primer paso fundamental. «En las implementaciones DevOps que no prosperan, las organizaciones no se dan cuenta de que las personas son la parte más importante de la ecuación», dice Gerry Leitao, vicepresidente de managed delivery services y plataformas para la consultora Capgemini North America. «Estas organizaciones a menudo incorporan miembros a sus nuevos equipos DevOps antes de que hayan entendido completamente las habilidades técnicas y soft que se requieren para un equipo DevOps de alto rendimiento. No se dan cuenta de que no todo el personal tiene la visión o las ganas necesarias para tener éxito en un entorno altamente colaborativo y fluido «.

Estos son los siete roles – y habilidades relacionadas, – que son esenciales para cualquier organización que quiera adoptar un enfoque DevOps con éxito».

1. El DevOps pionero “evangelist”

«Hay organizaciones de TI que han evolucionado para sacarle partido a las prácticas y capacidades de DevOps, y hay otras que están en proceso de hacerlo», dice Croker. «Esa evolución no va a producirse sola, y el role principal lo tiene la persona que va a liderar ese cambio». El evangelista de DevOps es tu líder.

Esta persona debe promover los beneficios de DevOps identificando y cuantificando los beneficios comerciales resultantes de la mayor agilidad que ofrece DevOps. Como agente de cambio, DevOps evangelist asegura la coordinación de los equipos de desarrollo y operativos, identifica los roles clave que apoyen los métodos de DevOps y se asegura de que los profesionales de TI estén capacitados para llevar a cabo esos cambios, dice Nagisetty. Además, el líder de tu movimiento DevOps necesita eliminar el miedo al fracaso de la organización, dice Antao. «Tienes que crear una cultura que sea de aprendizaje donde no pase nada por fracasar, se haga rápido, se aprenda y se mejore con ello».

Croker está de acuerdo. «En una organización dirigida por DevOps, hay algunos roles nuevos… pero es mucho más importante es que se logre un cambio cultural para afrontar los retos que surgen al proporcionar servicios TI y de las operaciones de TI», afirma.

2. El release manager

Tanto si llamas a este role release manager, release engineer o product stability manager, el enfoque es el mismo: «Los release managers se encargan de la gestión y coordinación del producto desde el desarrollo hasta la producción», dice Nagisetty. «Normalmente se centran en más detalles técnicos y obstáculos en los que un project manager típico no estaría involucrado». Los release managers supervisan la coordinación, la integración y el flujo de desarrollo, testing e implementación para apoyar la entrega continua del servicio. Están enfocados no solo en crear, sino también en mantener la cadena de aplicaciones de principio a fin, dice Antao.

3. El arquitecto de automatización

Debido a que DevOps depende en gran medida de los sistemas automatizados, este role es fundamental. A veces, se les conoce como especialistas en integración, los arquitectos de automatización analizan, diseñan e implementan estrategias para despliegues continuos, al tiempo que garantizan una alta disponibilidad en los sistemas de producción y preproducción, dice Nagisetty.

«Los arquitectos de automatización tienen un rol integral de automatización sobre las herramientas de DevOps y las plataformas cloud», dice Leitao. «Este rol también puede abarcar el lean thinking en los procesos clave de DevOps».

El rol de arquitecto de automatización se ha vuelto clave en el mundo de DevOps. «Las organizaciones DevOps deben crear un entorno de mucha confianza que esté completamente automatizado y libre de obstáculos», dice Mizrachi. «En determinadas circunstancias, todo el mundo tiene que disponer de vehículos 4×4 para conducir fuera de la carretera por terrenos difíciles. La función de la automatización de DevOps tiene la tarea de construir la carretera para que podamos usar coches rápidos».

El puesto es especialmente importante para las organizaciones que se organizan por aspectos geográficos, añade.

4. El developer/probador de software

El desarrollador de software es el corazón de la organización DevOps. En DevOps, la categoría de desarrollador de software puede seguir siendo la mismo, pero el nuevo rol del developer/tester de software aumenta drásticamente el alcance de las responsabilidades. Los desarrolladores son responsables no solo de convertir los nuevos requisitos en códigos, sino también en testing, implementación y monitoreo continuo. «No solo crean códigos para algo específico y lo pasan al equipo de control de calidad», dice Antao de PwC.

Así como DevOps implica una colaboración más amplia entre los equipos de desarrollo y operaciones, a veces también se lo denomina DevTestOps, lo que refuerza la idea de que el testing es una parte del proceso, dice Nagisetty.

Este cambio a menudo requiere que se realice un testing más automatizado para que la calidad no se vea perjudicada. «El problema es que los equipos aún piensan que pueden hacer los tests de forma manual y aun así ser ágiles. No se puede», dice Mizrachi. «Si necesitas testear nuevas versiones todos los días y lo haces de forma manual tardando dos semanas, es prácticamente imposible. La calidad del producto generalmente se deteriora hasta que la organización y los procesos cambian».

5. El profesional de experience assurance (XA)

Si bien la función de garantía de calidad (QA) a menudo forma parte del desarrollo de software, se necesita un nuevo tipo de control cuando las organizaciones adoptan el enfoque DevOps. La necesidad contar con los testers de control de calidad es reemplazada por la necesidad de que los expertos de XA se encarguen de garantizar que todas las características y funciones nuevas se lancen teniendo en cuenta la experiencia del usuario final. «Lo que se espera actualmente de los roles de QA es probar la funcionalidad, pero el rol debe evolucionar para incluir el testing de la experiencia del usuario», dice Mizrachi.

6. El ingeniero de seguridad

En el tradicional desarrollo en cascada, la seguridad del sistema ha surgido tarde. Es un «requisito no funcional» que, al igual que la garantía de calidad, a menudo se agrega al final del desarrollo del sistema, dice Antao de PwC.

El enfoque DevOps cuenta con ingenieros de seguridad que trabajan codo a codo con los desarrolladores, integrando sus recomendaciones mucho antes en el proceso. «Le dan seguridad al producto, no al final», dice Antao.

7. La importancia del technology player

Los profesionales de operaciones de TI o administración de sistemas tradicionales se centran en mantener los servidores en funcionamiento. «En general, sus máquinas funcionan mejor cuando hay pocos cambios», dice Perforce’s Warren. «Es probable que la causa más común de las interrupciones del servicio sean las aplicaciones que se ejecutan en estos servidores, por lo que los administradores incluyen controles muy estrictos sobre lo que está permitido ejecutar en sus servidores. Requieren un amplio control de calidad en un entorno de prueba, un gran delivery, documentación de operaciones y lanzamientos poco frecuentes». Los desarrolladores típicos han sido codificadores directos sin involucrarse en los sistemas de postproducción.

El entorno rápido de DevOps requiere un nuevo perfil. «Los expertos en operaciones o administración ahora se están involucrando a lo largo del proceso de desarrollo», dice Warren. «Hoy en día, no sería raro que estos expertos en operaciones, que a veces se conocen como ingenieros de DevOps, participen en la planificación de sprints para garantizar que se priorice una mejor calidad de servicio, gestión de recursos o seguridad por parte de la compañía».

Teniendo como antecedente el desarrollo o las operaciones de TI, «DevOps requiere miembros para su equipo que puedan operar de manera efectiva en plataformas de desarrollo, herramientas, redes, servidores y bases de datos, e incluso en desarrollo y soporte», dice Leitao.

Una transición efectiva al entorno de DevOps es más una cuestión de las personas que integran el equipo y de la manera en que trabajan juntas para ofrecer productos de una forma diferente que de la tecnología. Al reclutar o volver a formar a los profesionales de TI para ocupar estos siete roles de DevOps, los líderes de TI pueden dar un primer paso importante hacia el logro de un modelo DevOps exitoso.

# data[].attributes.body
Los equipos de SRE se encargan de la forma en que se implementa, configura y supervisa el código, así como de la disponibilidad, la latencia, la gestión de los cambios, la respuesta ante emergencias y la gestión de la capacidad de los servicios en la producción

# data[].attributes.body
Investigar sobre el rol dentro de un equipo de DevOps -  Site Reliability Engineer