¿Cuál es la diferencia entre SRE y DevOps?

¿Cuál es la diferencia entre SRE y DevOps?

Las operaciones de ingeniería y desarrollo de confiabilidad del sitio parecen superponerse mucho en detalle. ¿Cómo sé qué grupo es responsable de qué y cómo sé qué trabajos serían apropiados para mi conjunto de habilidades?

Parece que SRE se trata de mantener servidores y redes, y DevOps se trata de mantener código, ¿es correcto? ¿Todavía no hay una buena cantidad de superposición entre esos dos?

DevOps se trata de mantener el código, ¿es eso correcto?

DevOps no es "solo" sobre código, sistemas o cualquier cosa. DevOps es un término muy general que cubre todo lo relacionado con la entrega de software.

Site Reliability Engineering es un término popularizado por Google. De este artículo https://landing.google.com/sre/interview/ben-treynor.html podemos destilar su TL; DR:

Básicamente, es lo que sucede cuando le pide a un ingeniero de software que diseñe una función de operaciones.

Operaciones, ingeniería y desarrollo de software se están difuminando. El grado de automatización requerido para crear y mantener una infraestructura madura requiere habilidades de los tres. SRE son los administradores, y los ingenieros, y los desarrolladores.

Ver también: http://shop.oreilly.com/product/0636920041528.do

Dave Swersky ya publicó una excelente respuesta arriba con la definición de SRE de Ben Treynor, que es tan conmovedora hoy como lo fue en 2003.

Básicamente, es lo que sucede cuando le pide a un ingeniero de software que diseñe una función de operaciones.

Entonces, en un intento por definir mejor "DevOps", aquí hay un extracto del libro Effective DevOps de Jennifer Davis y Katherine Daniels:

Devops es una forma de pensar y una forma de trabajar. Es un marco para compartir historias y desarrollar empatía ... [es] no es solo otra metodología de desarrollo de software.

Las prácticas [P] pueden incluir métodos de desarrollo de software o características como automatización de infraestructura y entrega continua, [aunque] es mucho más que la suma de estas partes.

Si bien estos conceptos están relacionados y pueden verse con frecuencia en entornos de DevOps, centrarse únicamente en ellos pasa por alto el panorama general: los aspectos culturales e interpersonales que le dan a DevOps su poder.

En resumen: un SRE efectivo aprovechará las prácticas de DevOps.

-

También:

¿Cómo sé qué grupo es responsable de qué?

La propiedad no debe ser implícita; ¡comunicar!

La Ingeniería de Confiabilidad del Sitio se encuentra en operaciones más o menos tradicionales, pero muy automatizada y controlada por versiones, lo que también se llama Infraestructura como Código . Es un papel vertical bien definido . En los DevOps modernos, este es el segmento vertical que se relaciona con las Operaciones. Puedes tener un equipo de SRE.

DevOps como tal es un cambio cultural para una organización. Además de la estructura de gestión vertical, de arriba hacia abajo, crea una conexión horizontal entre los equipos a lo largo de las rutas de trabajo de entrega a lo largo de las cadenas de valor . Para un ingeniero, es un rol horizontal poco definido que une a varios equipos, asegurando que el trabajo pase sin problemas y rápidamente por toda la organización. No puedes tener un equipo de ingenieros de DevOps, eso es un oxímoron , ya que atravesar los límites del equipo es una parte crucial del rol.

Otra forma de describir las diferencias entre Site Reliability Engineering y DevOps es mirar la explicación de Wikipedia de a Site Reliability Engineer, que comienza así:

El ingeniero de confiabilidad del sitio (SRE) es una descripción del trabajo dada a los ingenieros de software centrados en la confiabilidad, la escalabilidad y el desarrollo de la infraestructura de computación en la nube, conocida como Ingeniería de confiabilidad del sitio (SRE).

Entonces puede considerar a los SRE como personas involucradas en Building walls...

Sin embargo, la explicación de WikipediaDevOps comienza así:

DevOps ... es un término utilizado para referirse a un conjunto de prácticas que enfatizan la colaboración y la comunicación de los desarrolladores de software y los profesionales de tecnología de la información (TI) al tiempo que automatizan el proceso de entrega de software y los cambios de infraestructura. Su objetivo es establecer una cultura y un entorno en los que la creación, prueba y lanzamiento de software pueda realizarse de manera rápida, frecuente y más confiable.

Lo que no dice es que todas estas prácticas de DevOps en realidad se desencadenan por una Demanda del lado comercial. Así se combina con la construcción y pruebas (la Desarrollar parte de ella) y el lanzamiento de software, DevOps es acerca de un DDR cultura (= Demanda-Desarrollar-Release) y el medio ambiente, lo que algunas personas pueden recordar de estos 9 segundos de un discurso histórico a Tear down this wall.

Consulte la pregunta acerca de la interrupción breve prevista para el miércoles 3 de mayo de 2017 a las 8 p.m., EE. UU./Este (como un simulacro de incendio para computadoras) para ver un ejemplo sobre todos los sitios de SE ... publicado (firmado) por un usuario con el cargo SRE Manager , Stack Overflow, Inc.