El seminario web tiene un sonido malo, por lo que lo desciframos.
Me llamo Edward Medvedev. Hoy hablaré sobre qué es SRE, cómo apareció SRE, para qué tienen los criterios de trabajo los ingenieros de SRE, un poco sobre criterios de fiabilidad, un poco sobre su monitoreo. Subiremos las escaleras, porque no contará mucho en una hora, pero le daré materiales para familiarización adicional, y todos lo estamos esperando en Slerm SRE . en Moscú a finales de enero.
Primero, hablemos de qué se trata SRE - Site Reliability Engineering. Y cómo apareció como una posición separada, como una dirección separada. Todo comenzó con el hecho de que en los círculos de desarrollo tradicionales, Dev y Ops son dos equipos completamente diferentes, generalmente con dos objetivos completamente diferentes. El objetivo del equipo de desarrollo es implementar nuevas funciones y satisfacer las necesidades del negocio. El objetivo del equipo de Ops es que todo funcione y que nada se rompa. Obviamente, estos objetivos se contradicen directamente entre sí: para que todo funcione y nada que se rompa, desplegar nuevas características es lo mejor posible. Debido a esto, hay muchos conflictos internos que la metodología, que ahora se llama DevOps, está tratando de resolver.
El problema es que no tenemos una definición clara de DevOps y una implementación clara de DevOps. Hablé en una conferencia en Ekaterimburgo hace 2 años, y hasta ahora la sección DevOps ha comenzado con una presentación de "Qué es DevOps". En 2017, el devo tiene casi 10 años, pero aún discutimos qué es. Y esta es una situación muy extraña que Google intentó resolver hace varios años.
En 2016, Google lanzó un libro llamado Site Reliability Engineering. Y de hecho, fue a partir de este libro que comenzó el movimiento SRE. SRE es una opción específica para implementar el paradigma DevOps en una empresa en particular. Los ingenieros de SRE se propusieron el objetivo de garantizar un rendimiento confiable del sistema. Se toman principalmente de los desarrolladores, a veces de los administradores con una sólida formación en desarrollo. Y están haciendo lo que los administradores del sistema hicieron antes, pero una sólida formación en el desarrollo y el conocimiento del sistema en términos de código lleva al hecho de que estas personas no están inclinadas al trabajo administrativo de rutina, sino que tienden a la automatización.
Resulta que el paradigma DevOps en los equipos de SRE se implementa por el hecho de que hay ingenieros de SRE que resuelven problemas estructurales. Aquí está, la conexión entre Dev y Ops de la que la gente ha estado hablando durante 8 años. El papel de SRE es similar al papel de un arquitecto en el sentido de que los recién llegados a SRE no lo hacen. Las personas al comienzo de una carrera aún no tienen ninguna experiencia, no tienen la amplitud de conocimiento necesaria. Porque SRE requiere un conocimiento muy fino de qué exactamente y cuándo exactamente puede salir mal. Por lo tanto, se necesita cierta experiencia aquí, como regla, tanto dentro como fuera de la empresa.
Preguntan si se describirá la diferencia entre SRE y devops. Ella acaba de ser descrita. Podemos hablar sobre el lugar de SRE en la organización. A diferencia de este enfoque clásico de DevOps, donde Ops sigue siendo un departamento separado, SRE es parte del equipo de desarrollo. Están involucrados en el desarrollo de productos. Incluso hay un enfoque en el que SRE es un rol que se mueve de un desarrollador a otro. Participan en revisiones de código de la misma manera que, por ejemplo, diseñadores de experiencia de usuario, desarrolladores y, a veces, gerentes de producto. SRE funciona al mismo nivel. Necesitamos su actualización, necesitamos su revisión, de modo que para cada implementación de SRE diga: “Bueno, esta implementación, este producto no afectará negativamente la confiabilidad. Y si es así, hasta cierto punto. También hablaremos sobre esto.
En consecuencia, el SRE tiene un veto para cambiar el código. Y en general, esto también conduce a algún tipo de pequeño conflicto si el SRE se implementa incorrectamente. En el mismo libro sobre Ingeniería de Confiabilidad del Sitio, muchas partes, ni siquiera una, dicen cómo evitar estos conflictos.
Preguntan cómo se relaciona SRE con la seguridad de la información. SRE no está directamente involucrado en la seguridad de la información. Básicamente, en grandes empresas, individuos, evaluadores y analistas hacen esto. Pero SRE también interactúa con ellos en el sentido de que algunas operaciones, algunas confirmaciones, algunas implementaciones que afectan la seguridad también pueden afectar la disponibilidad del producto. Por lo tanto, el SRE en su conjunto tiene interacción con cualquier equipo, incluidos los equipos de seguridad, incluidos los analistas. Por lo tanto, la mayoría de los SRE son necesarios cuando intentan implementar DevOps, pero al mismo tiempo la carga en los desarrolladores se vuelve demasiado grande. Es decir, el equipo de desarrollo en sí mismo ya no puede hacer frente al hecho de que ahora también deben ser responsables de las operaciones. Y aparece un papel separado. Este papel está planeado en el presupuesto. A veces, este rol se establece en el tamaño del equipo, aparece una persona separada, a veces se convierte en uno de los desarrolladores. Entonces, el primer SRE aparece en el equipo.
La complejidad del sistema, que se ve afectada por SRE, la complejidad que afecta la confiabilidad del trabajo, es necesaria y aleatoria. La complejidad necesaria es cuando la complejidad de un producto aumenta en la medida que lo requieran las nuevas características del producto. La complejidad aleatoria es cuando la complejidad del sistema aumenta, pero la característica del producto y los requisitos comerciales no afectan directamente esto. Resulta que o el desarrollador cometió un error en alguna parte, o el algoritmo no es óptimo, o se introducen algunos intereses adicionales que aumentan la complejidad del producto sin necesidad especial. Un buen SRE siempre debería cortar esta situación. Es decir, cualquier confirmación, cualquier implementación, cualquier solicitud de extracción donde la complejidad aumenta debido a adiciones aleatorias debe ser bloqueada.
La pregunta es, ¿por qué no solo contratar a un ingeniero, un administrador de sistemas con mucho conocimiento en el equipo? Se nos dice que un desarrollador en el papel de ingeniero no es la mejor solución de personal. Un desarrollador en el papel de ingeniero no siempre es la mejor solución de personal, pero el punto aquí es que el desarrollador que se ocupa de Ops tiene un poco más de deseo de automatización, tiene un poco más de conocimiento y habilidades para implementar esta automatización. Y en consecuencia, estamos reduciendo no solo el tiempo para cualquier operación específica, no solo la rutina, sino también parámetros comerciales tan importantes como MTTR (Tiempo medio de recuperación, tiempo de recuperación). Por lo tanto, y esto también será un poco más tarde, ahorramos dinero para la organización.
Ahora hablemos sobre los criterios para el trabajo de SRE. Y antes que nada sobre confiabilidad. En las pequeñas empresas, las nuevas empresas, a menudo sucede que las personas suponen que si el servicio está bien escrito, si el producto está bien y correctamente escrito, funcionará, no se romperá. Eso es todo, escribimos un buen código, por lo que no hay nada que romper. El código es muy simple, no hay nada que romper. Estas son casi las mismas personas que dicen que no necesitamos pruebas, porque, mira, estos son tres métodos de VPI, por qué romperlo.
Todo esto está mal, por supuesto. Y estas personas muy a menudo tal código muerde en la práctica, porque las cosas se rompen. Las cosas se rompen a veces de la manera más impredecible. A veces la gente dice que no, esto nunca sucederá. Y todo sucede exactamente. Sucede con bastante frecuencia. Y, por lo tanto, nadie se esfuerza por obtener una disponibilidad del 100%, porque la disponibilidad del 100% nunca sucede. Esta es la norma Y por lo tanto, cuando hablamos de la disponibilidad de un servicio, siempre hablamos de nueves. 2 nueves, 3 nueves, 4 nueves, 5 nueves. Si traduce esto en tiempo de inactividad, entonces, por ejemplo, 5 nueves, entonces esto es un poco más de 5 minutos de inactividad por año, 2 nueves son 3.5 días de inactividad.
Pero es obvio que en algún momento hay una disminución en el POI, el retorno de la inversión. Pasar de dos nueves a tres nueves, esto significa reducir el tiempo de inactividad en más de 3 días. Pasar de cuatro a nueve reduce el tiempo de inactividad en 47 minutos al año. Y resulta que para un negocio esto puede no ser crítico. Y, en general, la confiabilidad requerida no es un problema técnico, en primer lugar, es un problema comercial, es un problema de producto. Qué nivel de tiempo de inactividad es aceptable para los usuarios del producto, qué esperan, cuánto pagan, por ejemplo, cuánto dinero pierden, cuánto dinero pierde el sistema.
Una pregunta importante en este caso es cuál es la confiabilidad de los componentes restantes. Porque la diferencia entre 4 y 5 nueves no será visible en un teléfono inteligente con 2 nueves de confiabilidad. Hablando en términos generales, si algo falla en un teléfono inteligente en su servicio 10 veces al año, lo más probable es que la falla ocurra 8 veces precisamente en el lado del sistema operativo. El usuario está acostumbrado a esto y no prestará atención una vez al año. Es necesario correlacionar el precio de aumentar la confiabilidad y aumentar las ganancias.
Solo en el libro sobre SRE hay un buen ejemplo de aumentar a 4 nueves de 3 nueves. Resulta que el aumento en la disponibilidad es ligeramente inferior al 0.1%. Y si los ingresos del servicio son de $ 1 millón por año, entonces el aumento de los ingresos es de $ 900. Si aumentar la accesibilidad en nueve nos cuesta menos de $ 900 por año, este aumento tiene sentido financiero. Si cuesta más de $ 900 al año, ya no tiene sentido, porque el crecimiento de los ingresos simplemente no compensa los costos laborales, los costos de recursos. Y 3 nueves serán suficientes para nosotros.
Por supuesto, este es un ejemplo simplificado donde todas las consultas son iguales. Y de 3 nueves a 4 nueves es bastante fácil cambiar, pero al mismo tiempo, por ejemplo, cambiar de 2 nueves a 3 ya es un ahorro de 9 mil dólares, puede tener sentido financiero. Naturalmente, en realidad, una falla en una solicitud de registro es peor que una falla en mostrar una página; las solicitudes tienen un peso diferente. Pueden tener criterios muy diferentes desde el punto de vista empresarial, pero aún así, por regla general, si no estamos hablando de servicios específicos, esta es una aproximación bastante confiable.
Nos preguntamos si SRE es uno de los coordinadores al elegir una solución arquitectónica para un servicio. Supongamos en términos de integración en la infraestructura existente para que no se pierda su estabilidad. Sí, los SRE tienen el mismo efecto en las solicitudes de extracción, los compromisos, las versiones, afectan la arquitectura, la introducción de nuevos servicios, microservicios y la introducción de nuevas soluciones. ¿Por qué dije antes que necesito experiencia, necesito calificaciones? De hecho, SRE es una de las voces de bloqueo en cualquier solución arquitectónica y de software. En consecuencia, el SRE como ingeniero debe, en primer lugar, no solo comprender, sino también comprender cómo cualquier solución específica afectará la confiabilidad, la estabilidad y comprender cómo se relaciona esto con las necesidades comerciales, y desde qué punto de vista puede ser es permisible, y con lo que no.
Por lo tanto, ahora solo podemos hablar sobre los criterios de confiabilidad, que en SRE se definen tradicionalmente como SLA (Service Level Agreement). Lo más probable es un término familiar. SLI (Indicador de nivel de servicio). SLO (objetivo de nivel de servicio). El acuerdo de nivel de servicio es posiblemente un término histórico, especialmente si ha trabajado con redes, con proveedores y con hosting. Este es un acuerdo general que describe el rendimiento de todo su servicio, penalización, algunas penalizaciones por errores, métricas, criterios. Y SLI es la métrica de disponibilidad en sí. Es decir, lo que puede ser SLI: tiempo de respuesta del servicio, el número de errores en términos porcentuales. Esto puede ser ancho de banda si se trata de algún tipo de alojamiento de archivos. Si hablamos de algoritmos de reconocimiento, un indicador puede ser, por ejemplo, incluso la exactitud de la respuesta. SLO (Service Level Objective) es una combinación del indicador SLI, su valor y período, respectivamente.
Digamos que SLA puede ser así. El servicio está disponible el 99.95% del tiempo durante todo el año. O 99 tickets de soporte crítico se cerrarán dentro de 3 horas por trimestre. O el 85% de las solicitudes serán respondidas dentro de 1.5 segundos cada mes. Es decir, gradualmente llegamos a comprender que los errores y fallas son completamente normales. Esta es una situación aceptable, la estamos planeando, incluso contamos con ella hasta cierto punto. Es decir, SRE crea sistemas que pueden cometer errores, que deberían responder normalmente a los errores que deberían tenerlos en cuenta. Y si es posible, deben manejar los errores de tal manera que el usuario no los note o los note, pero existe una solución alternativa por la cual no todo se caerá por completo.
Por ejemplo, si sube un video a YouTube, y YouTube no puede convertirlo de inmediato, si el video es demasiado grande, si el formato no es óptimo, entonces la solicitud naturalmente no se perderá, YouTube no dará un error 502, YouTube dirá: "Todos hemos creado, Tu video está siendo procesado. Estará listo en unos 10 minutos ". Este es el principio de degradación elegante, que es familiar, por ejemplo, en el desarrollo de la interfaz, si alguna vez lo ha hecho.
Los siguientes términos de los que hablaremos que son muy importantes para trabajar con confiabilidad, con errores, con expectativas son MTBF y MTTR. MTBF es el tiempo medio entre fallas. Tiempo medio de recuperación MTTR, tiempo promedio de recuperación. Es decir, cuánto tiempo ha pasado desde el momento en que se detectó el error, desde el momento en que apareció el error hasta el momento en que el servicio se restableció completamente a la normalidad. MTBF se soluciona principalmente trabajando en la calidad del código. Es decir, en que el SRE puede decir que no. Y necesita la comprensión de todo el equipo de que cuando el SRE dice "no", lo dice no porque sea perjudicial, no porque sea malo, sino porque de lo contrario todos sufrirán.
Nuevamente, hay muchos artículos, muchos métodos, muchas formas, incluso en el mismo libro al que me refiero tan a menudo, cómo evitar que otros desarrolladores comiencen a odiar a SRE. MTTR, por otro lado, está trabajando en su SLO (objetivo de nivel de servicio). Y esto es principalmente automatización. Porque, por ejemplo, nuestro SLO es un tiempo de actividad de 4 nueves por trimestre. Esto significa que en 3 meses podemos permitir 13 minutos de tiempo de inactividad. Y resulta que no podemos tener MTTR durante más de 13 minutos. Si reaccionamos durante al menos 1 tiempo de inactividad durante 13 minutos, esto significa que ya hemos agotado todo el presupuesto para el trimestre. Estamos rompiendo SLO. 13 minutos para una reacción y arreglar una falla es mucho para el auto, pero muy poco para una persona. Porque mientras una alerta llegue a una persona, mientras reacciona, hasta que comprenda el error, esto ya dura varios minutos. Hasta que una persona entienda cómo solucionarlo, qué arreglar exactamente, qué hacer, entonces esto es unos minutos más. Y, de hecho, incluso si solo necesita reiniciar el servidor, como resulta, o generar un nuevo nodo, el MTTR manual ya dura unos 7-8 minutos. Al automatizar un proceso, el MTTR a menudo alcanza un segundo, a veces un milisegundo. Google generalmente habla de milisegundos, pero en realidad, por supuesto, las cosas no son tan buenas.
Idealmente, SRE debería automatizar su trabajo casi por completo, ya que afecta directamente a MTTR, sus métricas, el SLO de todo el servicio y, por lo tanto, las ganancias del negocio. Si se excede el tiempo, pregúntenos si la culpa recae en SRE. Para bien, nadie tiene la culpa. Y esta es una cultura separada llamada postmortem balmeless, de la que no hablaremos hoy, pero analizaremos en Slurme. Este es un tema muy interesante del que se puede hablar mucho. Hablando en términos generales, si se excede el tiempo asignado para un trimestre, entonces todos tienen la culpa un poco, lo que significa que culpar a todos no es productivo, en lugar de eso, quizás no culpemos a nadie, pero corrijamos la situación y trabajemos con lo que tenemos. En mi experiencia, este enfoque para la mayoría de los equipos, especialmente en Rusia, es un poco extraño, pero tiene sentido y funciona muy bien. Por lo tanto, recomendaré al final del artículo y la literatura que se puede leer sobre este tema. O ven a Slurm SRE.
Te lo explicaré. Si se excede el tiempo de SLO por trimestre, si el tiempo de inactividad no fue de 13 minutos, sino de 15, ¿quién podría ser el culpable de esto? Por supuesto, SRE podría ser el culpable, porque obviamente hizo algún tipo de mala confirmación o despliegue. El administrador del centro de datos puede ser el culpable de esto, porque, tal vez, se llevó a cabo un mantenimiento no programado. Si el administrador del centro de datos tiene la culpa, la culpa es de la persona de operaciones que no calculó el mantenimiento al coordinar el SLO. El culpable es el gerente, el director técnico o alguien que firmó el contrato del centro de datos y no prestó atención al hecho de que el centro de datos SLA no está diseñado para el tiempo de inactividad requerido. En consecuencia, poco a poco todos tienen la culpa de esta situación. Y eso significa que no tiene sentido culpar a nadie en esta situación. Pero, por supuesto, debes arreglarlo. Por lo tanto, hay post-mortem. Y si lee, por ejemplo, la autopsia de Github, que siempre es una historia muy interesante, pequeña e inesperada en cada caso en particular, puede reemplazar que nadie dice que esta persona en particular fue la culpable. La culpa siempre se asigna a procesos imperfectos específicos.
Pasemos a la siguiente pregunta. Automatización Cuando hablo de la automatización en otros contextos, generalmente me refiero a una tabla que indica cuánto tiempo puede trabajar en la automatización de una tarea para no tomar más tiempo para automatizarla de lo que generalmente guarda. Hay un inconveniente El problema es que cuando SRE automatiza alguna tarea, ahorran no solo tiempo, sino también dinero, porque la automatización afecta directamente a MTTR. Ahorran, por así decirlo, la moral de los empleados y desarrolladores, que también es un recurso agotable. Reducen la rutina. Y todo esto afecta positivamente el trabajo y, como consecuencia, el negocio, incluso si parece que la automatización no tiene sentido en términos de costos de tiempo.
De hecho, casi siempre lo ha hecho, y hay muy pocos casos en los que no valga la pena automatizar algo en el rol de SRE. Además hablaremos sobre lo que se llama presupuesto de error, el presupuesto para errores. De hecho, resulta que si todo es mucho mejor para usted que el SLO que estableció para usted, esto tampoco es muy bueno. Esto es bastante malo, porque SLO funciona no solo como un límite inferior, sino también como un límite superior aproximado. Cuando establece SLO en un 99% de accesibilidad, y de hecho tiene un 99.99%, resulta que tiene algo de espacio para la experimentación que no dañará el negocio en absoluto, porque usted mismo determinó esto juntos, y usted es el espacio no utilizar Tiene un presupuesto para errores que no se gastan en su caso.
¿Qué estamos haciendo con él? Lo usamos literalmente para todo. Para probar en condiciones de producción, para implementar nuevas funciones que pueden afectar el rendimiento, las versiones, el mantenimiento y los tiempos de inactividad programados. La regla opuesta también se aplica: si el presupuesto se agota, no podemos descargar nada nuevo, porque de lo contrario se excederá el SLO. El presupuesto ya está agotado, no hemos publicado algo, si afectará negativamente la productividad, es decir, si no es algún tipo de solución que aumente directamente el SLO, entonces vamos más allá del presupuesto, y esta es una mala situación, debe analizarse , post-mortem, y posiblemente algún tipo de solución de proceso.
Es decir, si el servicio en sí funciona mal, y se gasta SLO y el presupuesto no se gasta en experimentos, no en algunas versiones, sino por sí mismo, entonces, en lugar de soluciones interesantes para los desarrolladores, en lugar de características interesantes, en lugar de interesantes lanzamientos. En lugar de algún tipo de trabajo creativo, tendrá que hacer arreglos estúpidos para devolver el presupuesto al pedido o editar el SLO, y este también es un proceso que no debería ocurrir con demasiada frecuencia.
Por lo tanto, resulta que en una situación en la que tenemos más presupuesto para errores, todos están interesados: tanto SRE como los desarrolladores. Para los desarrolladores, un gran presupuesto para errores significa que puede lidiar con versiones, pruebas y experimentos. Para SRE, el presupuesto para errores y la entrada en este presupuesto significa que realmente hacen su trabajo directamente bien. Y esto afecta la motivación para algún tipo de colaboración. Si escucha a sus SRE como desarrolladores, tendrá más espacio para un buen trabajo y mucho menos rutina.
Resulta que la experimentación en la producción es una parte bastante importante y casi integral de SRE en equipos grandes. Y generalmente se llama ingeniería del caos, que proviene del equipo de Netflix que lanzó una utilidad llamada Chaos Monkey.
Chaos Monkey se conecta a la canalización de CI / CD y deja caer el servidor al azar en producción. Nuevamente, en la estructura SRE, estamos hablando del hecho de que un servidor bloqueado no es malo en sí mismo, se espera. Y si está incluido en el presupuesto, es aceptable y no perjudica al negocio. , , , , , .
- , , Chaos Gorilla, . , -, , , , . , , , . , , , - , , , , , . . , , , , , CI/CD . , , , , , , , . , , , . , .
: ? . , . , SRE . , , . , , SRE , , , , , , , . SRE , - . , SRE, - .
, , . , SRE , , . , , . , , , , , , .
, . SRE , . , , SLA, SLI, SLO. , SLA SLO, . - , , , - , , . 4 , IT , . , - .
. , - , , Objectives, , 3 .
, , . SLA, SLI, SLO, , , Objectives, SLA. , : - , , . . , -. , , , , , -, , : - . -, , . , SRE , , .
3 . , , . – , . , , , . – , . , - , - , , . – , , , . , - - , . - . , , .
, , , , , . , . . . . . , .
, Observability. . , . , Observability . - , , , . : , . , , , . , - Kubernetes, , . Observability MTTR. Observability , , , , MTTR.
, , , , SRE. . , , , SRE . , - . , , -, SRE . , , , - . , . SRE . . .
, , , . - , - . SRE, -, , . , , , .
. , , , , , , . . , . canary, , , , - , , , . , , , , .
SRE. , - , SRE, . - , - , , , canary A/B . SRE , . SRE . , , . SRE , , , , 50 50 , , SRE . . , .
. - . , SRE . , , . , , , , , , . SRE.
SRE — , , , , , , . . . Booking.com . , . - . .
, . SRE. , 2 SRE, . SLA, SLI, SLO , . 3 SRE . – Keys to SRE , . — SRE . SRE . SRE , 5 SRE 190 . , DevOps , SRE , .
2 chaos ingeneering: (1) , (2) . 3 Awesome Lists chaos ingeneering , SRE SRE . SRE , , 200 . capacity planning blameless postmortem.
: SRE as a life choice
, . , - . , , . . .
.
PS: , , . , , SRE .