Afortunadamente, dado que la Ingeniería de confiabilidad del sitio se desarrolló internamente en Google y solo recientemente ha comenzado a abrirse camino en la comunidad en general, está bastante bien definida. Lo que no es , sin embargo, son las operaciones de web (o "administración de sistemas" - como un ejemplo de la falta de claridad, se utiliza tanto en su pregunta). Es difícil discutir las diferencias entre dos cosas cuando no estás del todo seguro de cuál es una de ellas.
Pero soy un tipo aventurero, así que lo intentaré.
En tiendas muy tradicionales, los desarrolladores y los administradores de sistemas están muy aislados entre sí. Los desarrolladores crean una aplicación, luego consideran que su trabajo está completo tan pronto como se haya confirmado su código. Los administradores del sistema toman los artefactos de compilación (que pueden ser solo el código, si es un lenguaje interpretado) y lo implementan en los servidores de producción. El trabajo de los administradores de sistemas es mantener la aplicación funcionando sin problemas y, en general, administrar el entorno de producción. Sin embargo, a menudo los problemas de rendimiento provienen de problemas de arquitectura en la aplicación; los administradores de sistemas no tienen el conocimiento de programación para saber qué está haciendo la aplicación, y los desarrolladores no saben cómo actúa la aplicación en la topología de producción con el tráfico de producción, por lo que nadie está equipado por sí mismo para resolver el problema.
Además, los desarrolladores generalmente son juzgados por la rapidez con que pueden producir nuevas características, mientras que los administradores de sistemas son juzgados por lo poco frecuente que la aplicación se rompe en la producción. Dado que el cambio es una de las principales causas de ruptura, esto pone a los dos departamentos en desacuerdo entre sí: una vieja rivalidad que perjudica al negocio y a las personas involucradas.
En algún momento, algunas empresas centradas en los desarrolladores se molestaron tanto por esto que comenzaron a practicar "NoOps": eliminaron sus departamentos de operaciones y los obstáculos que se percibían con ellos. En realidad, esto significaba que los desarrolladores asumían roles de operaciones, pero mantenían sus títulos anteriores.
En una discusión sobre NoOps , John Allspaw, entonces Vicepresidente de Operaciones Técnicas en Etsy y editor del respetado libro de Operaciones Web , definió los roles en Etsy de esta manera:
Etsy Operations es responsable de:
- En respuesta a las interrupciones, toma de guardia
- Sistemas de alerta de umbralización, diseño
- Diseño de arquitectura y revisión
- Construyendo colección de métricas
- Configuración de la aplicación
- Infraestructura de construcción / gestión
Etsy Development es responsable de:
- En respuesta a las interrupciones, toma de guardia
- Sistemas de alerta de umbralización, diseño
- Diseño de arquitectura y revisión
- Construyendo colección de métricas
- Configuración de la aplicación
- Envío de código público
Ninguna de esas listas es exhaustiva, estoy seguro de que me falta algo. Si bien Etsy Ops ha realizado cambios en la aplicación orientados a la producción, son pocos pero reales (y a veces bastante profundos). Si bien Etsy Dev hace cambios en el Chef, son pocos pero reales. Si hay tanta superposición en las responsabilidades, ¿por qué la diferencia, podría preguntar? Dominio de experiencia y antecedentes. No muchos desarrolladores tienen un conocimiento profundo de cómo funciona el inicio lento de TCP, pero Ops sí. No muchas operaciones tienen un conocimiento exhaustivo de los algoritmos de clasificación o relevancia, pero Dev sí. Ops tiene años de experiencia en pronosticar el uso de recursos rápidamente con una precisión aceptable, Dev no. Es posible que Dev no conozca los pros y los contras de distribuir las opciones de carga de trabajo en todas las capas 1-7, tal vez solo a las 7, Ops sí. El modelado de relación de entidad puede ser natural para un desarrollador, puede que no para las operaciones. Al final, ambos descubren soluciones a varias formas de escenarios de falla bizantina y patrones de resiliencia, en todos los niveles y capas.
En su mundo, los desarrolladores y los ingenieros de operaciones tenían habilidades y responsabilidades de alto nivel muy similares; donde diferían era en su experiencia. Sus diferentes especialidades los alentaron a trabajar juntos para resolver problemas, y sus habilidades básicas comunes les dieron un lenguaje para hacerlo.
Esta es generalmente la definición de operaciones web en la que aterrizo para la mayoría de los casos. Entonces es con el que vamos a continuar.
Entonces, ¿qué es la ingeniería de confiabilidad del sitio?
El libro de Google SRE se abre con una definición de SRE ... y luego otra ... y luego pasa un capítulo que continúa definiendo el rol y un libro completo que cubre los detalles. Incluso cuando se desarrolla en una organización, parece que es difícil condensar el trabajo en una sola definición acordada.
Para comenzar, necesitamos regresar al 2003, cuando Ben Traynor se unió a Google y fundó lo que se convirtió en el primer equipo de Ingeniería de Confiabilidad del Sitio. Recordemos que hace unos párrafos estábamos a principios de la década de 2010; pero en 2003, la industria todavía estaba bastante centrada en la división sysadmin / developer como la forma natural de las cosas. Entonces, cuando Ben dice que SRE es lo que sucedería si un ingeniero de software creara un equipo de operaciones, esta fue una fusión mucho más radical de los dos mundos de lo que parece ahora.
La definición dada en el prefacio enfatiza cada una de las tres palabras individualmente:
- Ingeniería : el uso de conceptos informáticos y de ingeniería para resolver problemas
- Confiabilidad : un enfoque en hacer que los sistemas sean más escalables, más confiables y más eficientes
- Servicio : la evolución posterior del "sitio", enfatizando que los SRE son responsables de los servicios en red
El capítulo de introducción enumera los principios de la Ingeniería de Confiabilidad del Sitio como:
- Asegurar un enfoque duradero en la ingeniería : tomar medidas preventivas para evitar páginas frecuentes y otros "trabajos"
- Persiguiendo la velocidad de cambio máxima sin violar el SLO de un servicio, un tema que puede tener fácilmente su propia respuesta de varios cientos de palabras, pero que se resume a grandes rasgos como ayudar a los desarrolladores a realizar cambios, siempre que no causen demasiados problemas
- Monitoreo : alertas automáticas cuando las cosas salen mal
- Respuesta de emergencia : arreglar cosas cuando están rotas
- Gestión del cambio
- Planificación de capacidad
- Aprovisionamiento
- Eficiencia y rendimiento : garantizar que un servicio funcione al nivel esperado: el cuello de botella perjudica a los usuarios, pero el exceso de capacidad cuesta dinero
Clasificaría la ingeniería de confiabilidad del sitio como un subconjunto especializado de operaciones web modernas. Una organización SRE se centra principalmente en automatizar todo , en un grado que solo es rentable en empresas bastante grandes. Ideas como los presupuestos de error solo pueden funcionar cuando su servicio tiene muchas, muchas solicitudes, ya que de lo contrario pierde granularidad (para un servicio más pequeño, un error particular podría afectar del 0 al 20% de sus solicitudes, según el minuto). Las áreas relacionadas como la seguridad están ausentes de la definición de SRE porque las empresas lo suficientemente grandes como para tener verdaderos equipos SRE tienen equipos dedicados para la seguridad.
El programa SRE, según lo definido por Google, es operaciones web desarrolladas para las necesidades específicas de Google, y no necesariamente aplicables en otros lugares.
Sin embargo, la Ingeniería de Confiabilidad del Sitio se ha expandido recientemente en un uso más amplio de la industria. Mi título de trabajo actual es un SRE, a pesar de que trabajo en una empresa mucho más pequeña y la descripción de mi trabajo encaja bastante bien con la definición de operaciones web de Etsy de John Allspaw en 2012. Mi teoría es que hemos estado progresando a través de títulos como una abreviatura para defender la evolución de un solo campo:
- Comenzamos como administradores de sistemas .
- Luego, a medida que los sitios web se convirtieron en algo más que una "cosa", las ofertas de trabajo comenzaron a referirse a los ingenieros de operaciones web para distinguir a los administradores de sistemas que se especializaban en la web de aquellos que también manejaban las TI de la oficina general.
- Entonces se suponía que DevOps debía separar a aquellos que se sentían cómodos usando la programación para reducir su carga de trabajo de operaciones web.
- Pero a medida que DevOps se confundió por la falta de una definición clara , adoptamos la Ingeniería de Confiabilidad del Sitio para especificar que estamos buscando personas que brinden servicios de producción de soporte de guardia.
Entonces, ¿cuál es la diferencia entre un administrador de sistemas y un SRE? El año en que recibieron su título. ¿Cuál es la diferencia entre las operaciones tradicionales y la ingeniería de confiabilidad del sitio? SRE es simplemente la encarnación actual de operaciones, utilizando nuevas herramientas (¡hola, contenedores!) Y, a medida que los programas en red continúan volviéndose más grandes y más importantes, un mayor enfoque en las prácticas que permiten a un ingeniero hacer más .