El seminario web tiene un audio deficiente, por lo que lo transcribimos.
Mi nombre es Medvedev Eduard. Hoy hablaré de qué es SRE, cómo apareció SRE, qué criterios de trabajo tienen los ingenieros de SRE, un poco sobre criterios de confiabilidad, un poco sobre su monitoreo. Caminaremos sobre las cimas, porque no se puede decir mucho en una hora, pero les daré materiales para una revisión adicional, y todos los estamos esperando en . en Moscú a finales de enero.
Primero, hablemos de lo que es SRE: ingeniería de confiabilidad del sitio. 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 características y satisfacer las necesidades del negocio. El objetivo del equipo de operaciones es asegurarse de que todo funcione y nada se rompa. Obviamente, estos objetivos se contradicen directamente entre sí: para que todo funcione y nada se rompa, implemente la menor cantidad de funciones nuevas posible. Debido a esto, existen 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 comenzaba con el informe "¿Qué es DevOps?". En 2017, Devops tiene casi 10 años, pero todavía estamos discutiendo qué es. Y esta es una situación muy extraña que Google intentó resolver hace unos años.
En 2016, Google lanzó un libro llamado Site Reliability Engineering. Y de hecho, fue con este libro que comenzó el movimiento SRE. SRE es una implementación específica del paradigma DevOps en una empresa específica. Los ingenieros de SRE están comprometidos a garantizar que los sistemas funcionen de manera confiable. En su mayoría provienen de desarrolladores, a veces de administradores con una sólida experiencia en desarrollo. Y hacen lo que solían hacer los administradores de sistemas, pero una sólida formación en desarrollo y 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 a la automatización.
Resulta que el paradigma DevOps en los equipos SRE se implementa por el hecho de que hay ingenieros SRE que resuelven problemas estructurales. Aquí está, la misma conexión entre Dev y Ops de la que la gente ha estado hablando durante 8 años. El papel de un SRE es similar al de un arquitecto en el sentido de que los recién llegados no se convierten en SRE. Las personas al comienzo de sus carreras aún no tienen ninguna experiencia, no tienen la amplitud de conocimientos necesaria. Porque SRE requiere un conocimiento muy sutil de exactamente qué y cuándo puede salir mal. Por lo tanto, aquí se necesita cierta experiencia, por regla general, tanto dentro como fuera de la empresa.
Preguntan si se describirá la diferencia entre SRE y devops. Ella acaba de ser descrita. Podemos hablar del lugar de la 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 pasa de un desarrollador a otro. Participan en las revisiones de código de la misma manera que, por ejemplo, los diseñadores de UX, los propios desarrolladores y, a veces, los gerentes de producto. Los SRE funcionan al mismo nivel. Necesitamos aprobarlos, necesitamos revisarlos, para que en cada implementación la SRE diga: “Está bien, esta implementación, este producto no afectará negativamente la confiabilidad. Y si lo hace, entonces dentro de unos límites aceptables. También hablaremos de esto.
En consecuencia, la SRE tiene derecho de veto para cambiar el código. Y en general, esto también genera algún tipo de pequeño conflicto si el SRE se implementa incorrectamente. En el mismo libro sobre Site Reliability Engineering, muchas partes, ni siquiera una, cuentan cómo evitar estos conflictos.
Preguntan cómo se relaciona la SRE con la seguridad de la información. La SRE no está directamente involucrada en la seguridad de la información. Básicamente, en las grandes empresas, esto lo hacen individuos, probadores, analistas. 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, SRE en su conjunto tiene interacción con cualquier equipo, incluidos los equipos de seguridad, incluidos los analistas. Por lo tanto, los SRE se necesitan principalmente cuando intentan implementar DevOps, pero al mismo tiempo, la carga para los desarrolladores se vuelve demasiado grande. Es decir, el propio equipo de desarrollo ya no puede hacer frente al hecho de que ahora también deben ser responsables de Ops. Y hay un papel aparte. Esta función está prevista 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. Así aparece el primer SRE en el equipo.
La complejidad del sistema que se ve afectado por SRE, la complejidad que afecta la confiabilidad de la operación, es necesaria y accidental. La complejidad necesaria es cuando la complejidad de un producto aumenta en la medida requerida por las nuevas características del producto. La complejidad aleatoria es cuando la complejidad del sistema aumenta, pero las características del producto y los requisitos comerciales no afectan directamente esto. Resulta que 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 debe cortar esta situación. Es decir, cualquier confirmación, implementación, solicitud de extracción, donde la dificultad aumenta debido a la adición aleatoria, debe bloquearse.
La pregunta es por qué no contratar a un ingeniero, un administrador de sistemas con mucho conocimiento en el equipo. Un desarrollador en el papel de un ingeniero, se nos dice, no es la mejor solución de personal. Un desarrollador en el rol de ingeniero no siempre es la mejor solución de personal, pero el punto aquí es que un desarrollador que se dedica a operaciones tiene un poco más de deseo por la automatización, tiene un poco más de conocimiento y un conjunto de habilidades para implementar esta automatización. Y en consecuencia, reducimos no solo el tiempo para algunas operaciones específicas, no solo la rutina, sino también parámetros comerciales tan importantes como MTTR (Mean Time To Recovery, tiempo de recuperación). Así, y de esto también hablaremos un poco más adelante, ahorramos dinero a la organización.
Ahora hablemos de los criterios para el funcionamiento de la SRE. Y en primer lugar sobre la fiabilidad. En las pequeñas empresas, en las startups, suele pasar que la gente asume que si el servicio está bien escrito, si el producto está bien escrito y correctamente, 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 los tres métodos VPI, ¿por qué romper aquí?
Todo esto está mal, por supuesto. Y estas personas muy a menudo son mordidas por dicho código en la práctica, porque las cosas se rompen. Las cosas se rompen a veces de las formas más impredecibles. A veces la gente dice que no, nunca sucederá. Y pasa todo el tiempo. Sucede con bastante frecuencia. Y es por eso que nadie se esfuerza nunca por una disponibilidad del 100 %, porque la disponibilidad del 100 % nunca sucede. Esta es la norma. Y por tanto, cuando hablamos de la disponibilidad de un servicio, siempre hablamos de nueves. 2 nueves, 3 nueves, 4 nueves, 5 nueves. Si traducimos esto en tiempo de inactividad, entonces, por ejemplo, 5 nueves, esto es un poco más de 5 minutos de tiempo de inactividad por año, 2 nueves son 3,5 días de tiempo de inactividad.
Pero es obvio que en algún momento hay una disminución del POI, el retorno de la inversión. Pasar de dos nueves a tres nueves significa menos tiempo de inactividad en más de 3 días. Pasar de cuatro nueves a cinco reduce el tiempo de inactividad en 47 minutos por año. Y resulta que para los negocios puede no ser crítico. Y en general, la confiabilidad requerida no es una cuestión técnica, en primer lugar, es una cuestión comercial, es una cuestión 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 aquí es cuál es la confiabilidad de los componentes restantes. Porque la diferencia entre 4 y 5 nueves no será visible en un smartphone con 2 nueves de fiabilidad. En términos generales, si algo se rompe en un teléfono inteligente en su servicio 10 veces al año, lo más probable es que 8 veces la falla ocurra en el lado del sistema operativo. El usuario está acostumbrado a esto, y no le prestará atención una vez más 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 desde 3 nueves. Resulta que el aumento de la disponibilidad es un poco menos del 0,1%. Y si el ingreso del servicio es de $1 millón al año, entonces el aumento en el ingreso es de $900. Si nos cuesta menos de $900 al año aumentar la asequibilidad en nueve, el aumento tiene sentido desde el punto de vista financiero. Si cuesta más de 900 dólares al año, ya no tiene sentido, porque el aumento de ingresos simplemente no compensa los costos laborales, los costos de recursos. Y 3 nueves serán suficientes para nosotros.
Este es, por supuesto, un ejemplo simplificado donde todas las solicitudes son iguales. Y pasar de 3 nueves a 4 nueves es bastante fácil, pero al mismo tiempo, por ejemplo, pasar de 2 nueves a 3, esto ya es un ahorro de 9 mil dólares, puede tener sentido financiero. Naturalmente, en realidad, la falla en la solicitud de registro es peor que la falla en mostrar la página, las solicitudes tienen diferentes pesos. Pueden tener un criterio completamente diferente desde el punto de vista comercial, pero de todos modos, por regla general, si no estamos hablando de algunos servicios específicos, esta es una aproximación bastante confiable.
Recibimos una consulta sobre si la SRE es uno de los coordinadores a la hora de elegir una solución arquitectónica para el servicio. Digamos en términos de integración en la infraestructura existente, para que no haya pérdida en su estabilidad. Sí, los SRE, de la misma manera que las solicitudes de extracción, los compromisos y los lanzamientos afectan la arquitectura, la introducción de nuevos servicios, microservicios, la implementación de nuevas soluciones. ¿Por qué dije antes que se necesita experiencia, se necesitan calificaciones? De hecho, SRE es una de las voces de bloqueo en cualquier solución arquitectónica y de software. En consecuencia, un SRE como ingeniero debe, en primer lugar, no solo comprender, sino también comprender cómo algunas decisiones específicas afectarán la confiabilidad, la estabilidad y comprender cómo esto se relaciona con las necesidades comerciales, y desde qué punto de vista puede ser aceptable y que no
Por lo tanto, ahora solo podemos hablar de criterios de confiabilidad, que tradicionalmente se definen en SRE como SLA (Acuerdo de nivel de servicio). Lo más probable es que sea un término familiar. SLI (Indicador de Nivel de Servicio). SLO (Objetivo de Nivel de Servicio). Acuerdo de nivel de servicio es quizás un término simbólico, especialmente si ha trabajado con redes, con proveedores, con alojamiento. Este es un acuerdo general que describe el desempeño de todo su servicio, penalizaciones, algunas penalizaciones por errores, métricas, criterios. Y SLI es la métrica de disponibilidad en sí. Es decir, lo que puede ser SLI: el tiempo de respuesta del servicio, el número de errores en porcentaje. Podría ser ancho de banda si se trata de algún tipo de alojamiento de archivos. Cuando se trata de algoritmos de reconocimiento, el indicador puede ser, por ejemplo, incluso la exactitud de la respuesta. SLO (Objetivo de Nivel de Servicio) es, respectivamente, una combinación del indicador SLI, su valor y período.
Digamos que el SLA podría ser así. El servicio está disponible el 99,95% del tiempo durante todo el año. O 99 tickets de soporte críticos se cerrarán en 3 horas por trimestre. O el 85 % de las solicitudes se responderán en 1,5 segundos todos los meses. Es decir, gradualmente llegamos a comprender que los errores y las fallas son bastante normales. Esta es una situación aceptable, la estamos planeando, incluso contamos con ella hasta cierto punto. Es decir, la SRE construye sistemas que pueden cometer errores, que deben responder con normalidad a los errores, que deben tenerlos en cuenta. Y siempre que sea posible, deben manejar los errores de tal manera que el usuario no los note o los note, pero hay algún tipo de solución, gracias a la cual todo no se derrumbará por completo.
Por ejemplo, si carga un video en 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 fallará con un tiempo de espera, YouTube no dará un error 502 , YouTube dirá: “Hemos creado todo, su video se está procesando. Estará listo en unos 10 minutos". Este es el principio de degradación elegante, que es familiar, por ejemplo, del desarrollo front-end, 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. MTTR Mean Time To Recovery, tiempo medio de recuperación. Es decir, cuánto tiempo ha pasado desde el momento en que se descubrió el error, desde el momento en que apareció hasta el momento en que el servicio se restauró a su funcionamiento normal completo. MTBF se soluciona principalmente mediante el trabajo en la calidad del código. Es decir, el hecho de que los SRE puedan decir "no". Y es necesario que todo el equipo entienda que cuando SRE dice "no", no lo dice porque sea dañino, 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 con tanta frecuencia, sobre cómo asegurarse de que otros desarrolladores no comiencen a odiar SRE. MTTR, por otro lado, se trata de trabajar en sus SLO (Objetivo de nivel de servicio). Y es sobre todo 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 MTTR no puede ser más de 13 minutos. Si respondemos a al menos 13 tiempo de inactividad en 1 minutos, significa que ya hemos agotado todo el presupuesto del trimestre. Estamos rompiendo el SLO. 13 minutos para reaccionar y solucionar un bloqueo es mucho para una máquina, pero muy poco para un ser humano. Porque hasta que una persona recibe una alerta, hasta que reacciona, hasta que entiende el error, ya son varios minutos. Hasta que una persona entienda cómo arreglarlo, qué arreglar exactamente, qué hacer, entonces esto son unos minutos más. Y, de hecho, incluso si solo necesita reiniciar el servidor, como resultado, o generar un nuevo nodo, el MTTR manual ya es de unos 7-8 minutos. Al automatizar el proceso, MTTR muy a menudo alcanza un segundo, a veces milisegundos. Google suele hablar de milisegundos, pero en realidad, claro, no todo es tan bueno.
Idealmente, la SRE debería automatizar su trabajo casi por completo, porque esto afecta directamente el MTTR, sus métricas, el SLO de todo el servicio y, en consecuencia, la rentabilidad del negocio. Si se excede el tiempo, se nos pregunta si SRE tiene la culpa. Afortunadamente, nadie tiene la culpa. Y esta es una cultura separada llamada post mortem balmeless, de la que no hablaremos hoy, pero la analizaremos en Slurm. Este es un tema muy interesante del que se puede hablar mucho. En términos generales, si se excede el tiempo asignado por trimestre, entonces un poco de todos tiene la culpa, lo que significa que culpar a todos no es productivo, en cambio, quizás no culpemos a nadie, pero corrijamos la situación y trabajemos con lo que tenemos. En mi experiencia, este enfoque es un poco extraño para la mayoría de los equipos, especialmente en Rusia, pero tiene sentido y funciona muy bien. Por lo tanto, recomendaré al final del artículo y la literatura que puede leer sobre este tema. O ven a Slurm SRE.
Dejame 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 puede ser el culpable de esto? Por supuesto, SRE puede tener la culpa, porque claramente hizo algún tipo de mal compromiso o implementación. El administrador del centro de datos puede tener la culpa de esto, porque puede haber realizado algún tipo de mantenimiento no programado. Si el administrador del centro de datos tiene la culpa de esto, entonces la culpa es de la persona de Ops, que no calculó el mantenimiento cuando coordinó el SLO. El responsable, el director técnico o alguien que firmó el contrato del centro de datos y no prestó atención al hecho de que el SLA del centro de datos no está diseñado para el tiempo de inactividad requerido es el culpable de esto. En consecuencia, todos poco a poco en esta situación tienen la culpa. Y significa que no tiene sentido echarle la culpa a nadie en esta situación. Pero, por supuesto, hay que corregirlo. Por eso existen las autopsias. Y si lees, por ejemplo, las autopsias de GitHub, y esta siempre es una historia muy interesante, pequeña e inesperada en cada caso específico, puedes reemplazar que nadie dice nunca que esta persona en particular tuvo la culpa. Siempre se culpa a procesos imperfectos específicos.
Pasemos a la siguiente pregunta. Automatización. Cuando hablo de automatización en otros contextos, a menudo me refiero a una tabla que le dice cuánto tiempo puede trabajar en automatizar una tarea sin tomar más tiempo para automatizarla de lo que realmente ahorra. Hay un inconveniente. El problema es que cuando los SRE automatizan una tarea, no solo ahorran tiempo, también ahorran dinero, porque la automatización afecta directamente al MTTR. Salvan, por así decirlo, la moral de los empleados y desarrolladores, que también es un recurso agotable. Reducen la rutina. Y todo esto tiene un efecto positivo en el trabajo y, en consecuencia, en los negocios, aunque parezca que la automatización no tiene sentido en términos de costos de tiempo.
De hecho, casi siempre lo ha hecho, y son muy pocos los casos en los que no se debe automatizar algo en el rol de SRE. A continuación hablaremos de lo que se denomina presupuesto de errores, el presupuesto de errores. De hecho, resulta que si todo te sale mucho mejor que el SLO que tú mismo te marcas, 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 se establece un SLO del 99 % de disponibilidad y, de hecho, tiene un 99,99 %, resulta que tiene espacio para experimentos que no dañarán en absoluto el negocio, porque usted mismo lo ha determinado todo junto, y está este espacio no lo use. Tienes un presupuesto para errores, que en tu caso no se agota.
Qué hacemos con esto. Lo usamos para literalmente todo. Para pruebas en condiciones de producción, para implementar nuevas funciones que pueden afectar el rendimiento, para lanzamientos, para mantenimiento, para tiempos de inactividad planificados. También se aplica la regla inversa: si se agota el presupuesto, no podemos lanzar nada nuevo, porque de lo contrario excederemos el SLO. El presupuesto ya se ha agotado, hemos liberado algo si afecta negativamente al rendimiento, es decir, si esto no es algún tipo de arreglo que en sí mismo aumenta directamente el SLO, entonces estamos yendo más allá del presupuesto, y esta es una mala situación. , necesita ser analizado, post mortem, y posiblemente algunas correcciones de proceso.
Es decir, resulta que si el servicio en sí no funciona bien, y se gasta SLO y el presupuesto no se gasta en experimentos, no en algunos lanzamientos, sino por sí mismo, entonces en lugar de algunas correcciones interesantes, en lugar de características interesantes, en lugar de lanzamientos interesantes. En lugar de cualquier trabajo creativo, tendrá que lidiar con arreglos estúpidos para volver a poner en orden el presupuesto 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 desarrolladores. Para los desarrolladores, un gran presupuesto para errores significa que puede lidiar con lanzamientos, pruebas y experimentos. Para las SRE, un presupuesto para errores e ingresar ese presupuesto significa que directamente están haciendo bien su trabajo. Y esto afecta la motivación de algún tipo de trabajo conjunto. Si escuchas a tus SRE como desarrolladores, tendrás más espacio para el buen trabajo y mucha menos rutina.
Resulta que los experimentos en producción son 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 bloquea aleatoriamente el servidor en producción. Nuevamente, en la estructura SRE, estamos hablando del hecho de que un servidor caído no es malo en sí mismo, es lo esperado. Y si está dentro del presupuesto, es aceptable y no perjudica al negocio. Por supuesto, Netflix tiene suficientes servidores redundantes, suficiente replicación, para que todo esto se pueda arreglar, y para que el usuario en su conjunto ni se dé cuenta, y más aún, nadie deja un servidor por cualquier presupuesto.
Netflix tuvo un conjunto completo de tales utilidades durante un tiempo, una de las cuales, Chaos Gorilla, cierra por completo una de las zonas de disponibilidad de Amazon. Y tales cosas ayudan a revelar, en primer lugar, dependencias ocultas, cuando no está del todo claro qué afecta a qué, qué depende de qué. Y esto, si está trabajando con un microservicio y la documentación no es del todo perfecta, esto puede resultarle familiar. Y nuevamente, esto ayuda mucho a detectar errores en el código que no se pueden detectar en la etapa, porque cualquier etapa no es exactamente una simulación exacta, debido al hecho de que la escala de carga es diferente, el patrón de carga es diferente, el equipo es también, muy probablemente, otros. Las cargas máximas también pueden ser inesperadas e impredecibles. Y tales pruebas, que de nuevo no van más allá del presupuesto, ayudan muy bien a detectar errores en la infraestructura que la puesta en escena, las pruebas automáticas y la canalización de CI/CD nunca detectarán. Y mientras esté todo incluido en tu presupuesto, no importa que tu servicio se haya caído allí, aunque parecería muy aterrador, el servidor se cayó, qué pesadilla. No, eso es normal, eso es bueno, eso ayuda a detectar errores. Si tienes un presupuesto, entonces puedes gastarlo.
P: ¿Qué literatura puedo recomendar? Lista al final. Hay mucha literatura, aconsejaré algunos informes. Cómo funciona, y funciona SRE en empresas sin producto software propio o con mínimo desarrollo. Por ejemplo, en una empresa donde la actividad principal no es el software. En una empresa, donde la actividad principal no es el software, SRE funciona exactamente igual que en cualquier otro lugar, porque en una empresa también necesita usar productos de software, incluso si no están desarrollados, necesita implementar actualizaciones, necesita cambiar la infraestructura, necesita crecer, necesita escalar. Y los SRE ayudan a identificar y predecir posibles problemas en estos procesos y controlarlos después de que comience un cierto crecimiento y cambien las necesidades comerciales. Porque no es absolutamente necesario estar involucrado en el desarrollo de software para tener un SRE si tiene al menos algunos servidores y se espera que tenga al menos algo de crecimiento.
Lo mismo ocurre con los proyectos pequeños, las organizaciones pequeñas, porque las grandes empresas tienen el presupuesto y el espacio para experimentar. Pero al mismo tiempo, todos estos frutos de experimentos se pueden usar en cualquier lugar, es decir, SRE, por supuesto, apareció en Google, en Netflix, en Dropbox. Pero al mismo tiempo, las pequeñas empresas y las nuevas empresas ya pueden leer material condensado, leer libros, ver informes. Comienzan a escuchar sobre esto con más frecuencia, miran ejemplos específicos, creo que está bien, realmente puede ser útil, también necesitamos esto, es genial.
Es decir, todo el trabajo principal para estandarizar estos procesos ya se ha realizado por usted. Le queda a usted determinar el papel de la SRE específicamente en su empresa y comenzar a implementar realmente todas estas prácticas, que, nuevamente, ya han sido descritas. Es decir, desde principios útiles para pequeñas empresas, esta es siempre la definición de SLA, SLI, SLO. Si no está involucrado en el software, estos serán SLA internos y SLO internos, un presupuesto interno para errores. Esto casi siempre conduce a algunas discusiones interesantes dentro del equipo y dentro del negocio, porque puede resultar que gastas en infraestructura, en algún tipo de organización de procesos ideales, la canalización ideal es mucho más de lo necesario. Y estos 4 nueves que tiene en el departamento de TI, realmente no los necesita ahora. Pero al mismo tiempo, podrías dedicar tiempo, gastar el presupuesto de errores en otra cosa.
En consecuencia, el seguimiento y la organización del seguimiento es útil para una empresa de cualquier tamaño. Y en general, esta forma de pensar, donde los errores son algo aceptable, donde hay un presupuesto, donde hay Objetivos, vuelve a ser útil para una empresa de cualquier tamaño, empezando por Startups de 3 personas.
El último de los matices técnicos para hablar es el monitoreo. Porque si hablamos de SLA, SLI, SLO, no podemos entender sin monitorizar si nos ajustamos al presupuesto, si cumplimos con nuestros Objetivos y cómo influimos en el SLA final. He visto tantas veces que el monitoreo ocurre así: hay algún valor, por ejemplo, el tiempo de una solicitud al servidor, el tiempo promedio o la cantidad de solicitudes a la base de datos. Tiene un estándar determinado por un ingeniero. Si la métrica se desvía de la norma, llega un correo electrónico. Todo esto es absolutamente inútil, por regla general, porque conduce a tal exceso de alertas, exceso de mensajes de monitoreo, cuando una persona, en primer lugar, debe interpretarlos cada vez, es decir, determinar si el valor de la métrica significa la necesidad de alguna acción. Y en segundo lugar, simplemente deja de notar todas estas alertas, cuando básicamente no se requiere ninguna acción de su parte. Esa es una buena regla de monitoreo y la primera regla cuando se implementa SRE es que la notificación solo debe llegar cuando se requiere acción.
En el caso estándar, hay 3 niveles de eventos. Hay alertas, hay tickets, hay registros. Las alertas son cualquier cosa que requiera que usted tome una acción inmediata. Es decir, todo está roto, debes arreglarlo ahora mismo. Los boletos son los que requieren una acción retrasada. Sí, debe hacer algo, debe hacer algo manualmente, la automatización falló, pero no tiene que hacerlo durante los próximos minutos. Los registros son cualquier cosa que no requiere acción y, en general, si las cosas van bien, nadie los leerá nunca. Solo necesitará leer los registros cuando, en retrospectiva, resultó que algo se rompió durante algún tiempo, no lo sabíamos. O necesitas investigar un poco. Pero en general, todo lo que no requiere ninguna acción va a los registros.
Como efecto secundario de todo esto, si hemos definido qué eventos requieren acciones y hemos descrito bien cuáles deben ser estas acciones, esto significa que la acción se puede automatizar. Es decir, lo que pasa. Pasamos de alerta. Pasemos a la acción. Vamos a la descripción de esta acción. Y luego pasamos a la automatización. Es decir, cualquier automatización comienza con una reacción a un evento.
De monitoreo, pasamos a un término llamado Observabilidad. También ha habido un poco de exageración en torno a esta palabra durante los últimos años. Y pocas personas entienden lo que significa fuera de contexto. Pero el punto principal es que la Observabilidad es una métrica para la transparencia del sistema. Si algo salió mal, con qué rapidez puede determinar qué salió mal exactamente y cuál era el estado del sistema en ese momento. En términos de código: qué función falló, qué servicio falló. Cuál era el estado de, por ejemplo, variables internas, configuración. En términos de infraestructura, esto es en qué zona de disponibilidad ocurrió la falla, y si tiene algún Kubernetes instalado, en qué pod ocurrió la falla, cuál era el estado del pod. Y en consecuencia, la Observabilidad tiene una relación directa con MTTR. Cuanto mayor sea la Observabilidad del servicio, más fácil será identificar el error, más fácil será corregir el error, más fácil será automatizar el error, menor será el MTTR.
Volviendo a las pequeñas empresas, es muy común preguntarse, incluso ahora, cómo lidiar con el tamaño del equipo y si un equipo pequeño necesita contratar un SRE por separado. Ya hablé de esto un poco antes. En las primeras etapas de desarrollo de una startup o, por ejemplo, un equipo, esto no es necesario en absoluto, porque SRE puede convertirse en un papel de transición. Y esto reanimará un poco al equipo, porque al menos hay algo de diversidad. Y además preparará a la gente para que con el crecimiento, en general, las responsabilidades de la SRE van a cambiar muy significativamente. Si contratas a una persona, entonces, por supuesto, tiene algunas expectativas. Y estas expectativas no cambiarán con el tiempo, pero los requisitos cambiarán mucho. Por lo tanto, cómo contratar una SRE es bastante difícil en las primeras etapas. Cultivar el tuyo es mucho más fácil. Pero vale la pena pensarlo.
La única excepción, quizás, es cuando existen requisitos de crecimiento muy estrictos y bien definidos. Es decir, en el caso de una startup, esto puede ser algún tipo de presión de los inversores, algún tipo de pronóstico de crecimiento varias veces a la vez. Entonces contratar una SRE se justifica básicamente porque se puede justificar. Tenemos requisitos para el crecimiento, necesitamos una persona que se responsabilice de que con tal crecimiento nada se rompa.
Una pregunta más. Qué hacer cuando los desarrolladores cortan varias veces una característica que pasa las pruebas, pero rompe la producción, carga la base, rompe otras características, qué proceso implementar. En consecuencia, en este caso, es el presupuesto de errores que se introduce. Y algunos de los servicios, algunas de las funciones ya se están probando en la producción. Puede ser canario, cuando solo una pequeña cantidad de usuarios, pero ya en la producción, se implementa una característica, pero ya con la expectativa de que si algo falla, por ejemplo, para la mitad de todos los usuarios, aún cumplirá con el presupuesto para errores. En consecuencia, sí, habrá un error, para algunos usuarios todo se estropeará, pero ya hemos dicho que esto es normal.
Hubo una pregunta sobre las herramientas SRE. Es decir, ¿hay algo en particular que los SRE usarían y que todos los demás no usarían? De hecho, hay algunas utilidades muy especializadas, hay algún tipo de software que, por ejemplo, simula cargas o se dedica a realizar pruebas Canary A/B. Pero básicamente, el kit de herramientas SRE es lo que sus desarrolladores ya están usando. Porque SRE interactúa directamente con el equipo de desarrollo. Y si tiene diferentes herramientas, resultará que lleva tiempo sincronizar. Sobre todo si los SRE trabajan en equipos grandes, en empresas grandes donde puede haber varios equipos, es la estandarización de toda la empresa que ayudará mucho aquí, porque si se usan 50 utilidades diferentes en 50 equipos, eso significa que el SRE debe conocerlas. todo. Y, por supuesto, esto nunca sucederá. Y la calidad del trabajo, la calidad del control de al menos algunos de los equipos disminuirá significativamente.
Nuestro seminario web está llegando a su fin. Me las arreglé para decir algunas cosas básicas. Por supuesto, nada sobre SRE se puede decir y entender en una hora. Pero espero haber logrado transmitir esta forma de pensar, los principales puntos clave. Y luego será posible, si está interesado, profundizar en el tema, aprender por su cuenta, ver cómo lo están implementando otras personas, en otras empresas. Y en consecuencia, a principios de febrero, acércate a nosotros en Slurm SRE.
El Slurm SRE es un curso intensivo de tres días que va a hablar de lo que ahora estoy hablando, pero con mucha más profundidad, con casos reales, con práctica, todo el intensivo va encaminado al trabajo práctico. Las personas se dividirán en equipos. Todos ustedes estarán trabajando en casos reales. En consecuencia, contamos con los instructores de Booking.com Ivan Kruglov y Ben Tyler. Tenemos un maravilloso Eugene Barabbas de Google, de San Francisco. Y te diré algo también. Así que asegúrese de visitarnos.
Entonces, la bibliografía. Hay referencias en SRE. en el mismo libro, o mejor dicho, en 2 libros sobre SRE, escritos por Google. Otro , donde los términos y su aplicación son un poco más detallados. Los siguientes 3 son informes sobre SRE en diferentes empresas. Primero - , este es un discurso de apertura de Ben Trainer de Google. Segundo - . El tercero es otra vez . Cuarto informe de , que tiene solo 5 empleados clave de la SRE en 190 países. Es muy interesante ver todo esto, porque así como DevOps significa cosas muy diferentes para diferentes empresas e incluso para diferentes equipos, SRE tiene responsabilidades muy diferentes, incluso en empresas de tamaños similares.
2 enlaces más sobre los principios de la ingeniería del caos: , . Y al final hay 3 listas de la serie Awesome Lists sobre acerca de y acerca . La lista en SRE es increíblemente grande, no es necesario revisarla toda, hay alrededor de 200 artículos. Recomiendo encarecidamente los artículos de allí sobre la planificación de la capacidad y sobre la autopsia sin culpa.
Artículo interesante:
Gracias por escucharme todo este tiempo. Espero que hayas aprendido algo. Espero que tengas suficiente material para aprender aún más. Y nos vemos. Ojalá en febrero.
El seminario web fue presentado por Eduard Medvedev.
PD: para los que les gusta leer, Eduard dio una lista de referencias. Aquellos que prefieran entender en la práctica son bienvenidos a .
Fuente: habr.com