Capítulo 1. Introducción Introducción
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
La esperanza no es una estrategia.
Dicho tradicional de la SRE
Es una verdad universalmente reconocida que los sistemas no se ejecutan solos. Entonces, ¿cómo debe funcionar un sistema, especialmente un sistema informático complejo que funcione a gran escala?
El Enfoque Sysadmin de la Gestión de Servicios
Históricamente, las empresas han empleado administradores de sistemas para gestionar sistemas informáticos complejos.
Este enfoque de administrador de sistemas, o sysadmin, implica ensamblar componentes de software existentes e implementarlos para que funcionen juntos y produzcan un servicio. A continuación, se encarga a los administradores de sistemas que ejecuten el servicio y respondan a los eventos y actualizaciones que se produzcan. A medida que el sistema crece en complejidad y volumen de tráfico, generando el correspondiente aumento de eventos y actualizaciones, el equipo de administradores crece para absorber el trabajo adicional. Dado que la función de administrador del sistema requiere un conjunto de habilidades muy diferente del que se exige a los desarrolladores de un producto, los desarrolladores y los administradores del sistema se dividen en equipos separados: "desarrollo" y "operaciones" u "ops".
El modelo sysadmin de gestión de servicios tiene varias ventajas. Para las empresas que deciden cómo gestionar y dotar de personal a un servicio, este enfoque es relativamente fácil de aplicar: como paradigma familiar de la industria, hay muchos ejemplos de los que aprender y emular. Ya se dispone de una reserva de talento relevante. Se dispone de una serie de herramientas existentes, componentes de software (listos para usar o de otro tipo) y empresas de integración para ayudar a gestionar esos sistemas ensamblados, por lo que un equipo de administradores de sistemas novatos no tiene que reinventar la rueda y diseñar un sistema desde cero.
El enfoque de administrador de sistemas y la consiguiente división entre desarrollo y operaciones tiene una serie de desventajas y escollos. A grandes rasgos, se dividen en dos categorías: costes directos y costes indirectos.
Los costes directos no son ni sutiles ni ambiguos. Gestionar un servicio con un equipo que depende de la intervención manual tanto para la gestión de cambios como para la gestión de eventos se vuelve caro a medida que crece el servicio y/o el tráfico hacia el servicio, porque el tamaño del equipo necesariamente escala con la carga generada por el sistema.
Los costes indirectos de la división desarrollo/operaciones pueden ser sutiles, pero a menudo son más caros para la organización que los costes directos. Estos costes se derivan del hecho de que los dos equipos son bastante diferentes en cuanto a formación, conjunto de habilidades e incentivos. Utilizan un vocabulario diferente para describir las situaciones; tienen suposiciones diferentes tanto sobre el riesgo como sobre las posibilidades de soluciones técnicas; tienen suposiciones diferentes sobre el nivel objetivo de estabilidad del producto. La división entre los grupos puede convertirse fácilmente no sólo en una cuestión de incentivos, sino también de comunicación, objetivos y, finalmente, confianza y respeto. Este resultado es una patología.
Por eso, los equipos de operaciones tradicionales y sus homólogos de desarrollo de productos suelen entrar en conflicto, sobre todo por la rapidez con que el software puede lanzarse a producción. En el fondo, los equipos de desarrollo quieren lanzar nuevas funciones y que los usuarios las adopten. En el fondo, los equipos de operaciones quieren asegurarse de que el servicio no se rompe mientras ellos tienen el busca en la mano. Como la mayoría de las interrupciones se deben a algún tipo de cambio -una nueva configuración, el lanzamiento de una nueva función o un nuevo tipo de tráfico de usuarios-, los objetivos de ambos equipos están fundamentalmente en tensión.
Ambos grupos entienden que es inaceptable exponer sus intereses en los términos más escuetos posibles ("Queremos lanzar cualquier cosa, en cualquier momento, sin obstáculos" frente a "No queremos cambiar nunca nada del sistema una vez que funcione"). Y como su vocabulario y sus hipótesis de riesgo difieren, ambos grupos recurren a menudo a una forma familiar de guerra de trincheras para promover sus intereses. El equipo de operaciones intenta salvaguardar el sistema en funcionamiento contra el riesgo de cambio introduciendo puertas de lanzamiento y de cambio. Por ejemplo, las revisiones de lanzamiento pueden contener una comprobación explícita de cada problema que haya causado una interrupción en el pasado, lo que podría ser una lista arbitrariamente larga, en la que no todos los elementos aportan el mismo valor. El equipo de desarrollo aprende rápidamente a responder. Hacen menos "lanzamientos" y más "cambios de bandera", "actualizaciones incrementales" o "cherrypicks". Adoptan tácticas como fragmentar el producto para que haya menos funciones sujetas a la revisión de lanzamiento.
El enfoque de Google para la gestión de servicios: Ingeniería de Fiabilidad del Sitio
El conflicto no es una parte inevitable de ofrecer un servicio de software. Google ha optado por gestionar nuestros sistemas con un enfoque diferente: nuestros equipos de Ingeniería de Fiabilidad del Sitio se centran en contratar ingenieros de software para gestionar nuestros productos y crear sistemas para realizar el trabajo que, de otro modo, realizarían, a menudo manualmente, los administradores de sistemas.
¿Qué es exactamente la Ingeniería de Fiabilidad del Sitio, tal como se ha llegado a definir en Google? Mi explicación es sencilla: La SRE es lo que ocurre cuando le pides a un ingeniero de software que diseñe un equipo de operaciones. Cuando me incorporé a Google en 2003 y me encargaron dirigir un "Equipo de Producción" de siete ingenieros, toda mi vida hasta entonces había sido la ingeniería de software. Así que diseñé y dirigí el grupo de la forma en que me gustaría que funcionara si yo mismo trabajara como SRE. Desde entonces, ese grupo ha madurado hasta convertirse en el actual equipo de SRE de Google, que sigue siendo fiel a sus orígenes, tal como lo concibió un ingeniero de software de toda la vida.
Un elemento fundamental del enfoque de Google sobre la gestión de servicios es la composición de cada equipo de SRE. En su conjunto, los SRE pueden dividirse en dos categorías principales.
El 50-60% son Ingenieros de Software de Google, o más exactamente, personas que han sido contratadas mediante el procedimiento estándar para Ingenieros de Software de Google. El otro 40-50% son candidatos que se acercaban mucho a las cualificaciones de los ingenieros de software de Google (es decir, entre el 85 y el 99% del conjunto de aptitudes requeridas), y que además tenían un conjunto de aptitudes técnicas útiles para la SRE, pero poco frecuentes para la mayoría de los ingenieros de software. Con diferencia, los conocimientos internos del sistema UNIX y la experiencia en redes (Capa 1 a Capa 3) son los dos tipos más comunes de conocimientos técnicos alternativos que buscamos.
Común a todos los SRE es la creencia y la aptitud para desarrollar sistemas de software que resuelvan problemas complejos. Dentro de la SRE, seguimos de cerca el progreso profesional de ambos grupos, y hasta la fecha no hemos encontrado ninguna diferencia práctica en el rendimiento entre los ingenieros de las dos vías. De hecho, la formación algo diversa del equipo de SRE da lugar con frecuencia a sistemas inteligentes y de alta calidad que son claramente el producto de la síntesis de varios conjuntos de habilidades.
El resultado de nuestro enfoque de la contratación para la SRE es que acabamos con un equipo de personas que (a) se aburrirán rápidamente realizando tareas a mano, y (b) tienen el conjunto de habilidades necesarias para escribir software que sustituya su trabajo anteriormente manual, incluso cuando la solución sea complicada. Los SRE también acaban compartiendo formación académica e intelectual con el resto de la organización de desarrollo. Por lo tanto, la SRE está haciendo fundamentalmente el trabajo que históricamente ha realizado un equipo de operaciones, pero utilizando ingenieros con experiencia en software, y apostando por el hecho de que estos ingenieros están inherentemente predispuestos a, y tienen la capacidad de, diseñar e implementar la automatización con software para sustituir el trabajo humano.
Por diseño, es crucial que los equipos de SRE se centren en la ingeniería. Sin una ingeniería constante, la carga de operaciones aumenta y los equipos necesitarán más gente sólo para seguir el ritmo de la carga de trabajo. Al final, un grupo tradicional centrado en operaciones escala linealmente con el tamaño del servicio: si los productos soportados por el servicio tienen éxito, la carga operativa crecerá con el tráfico. Eso significa contratar a más personas para hacer las mismas tareas una y otra vez.
Para evitar este destino, el equipo encargado de gestionar un servicio necesita codificar o se ahogará. Por lo tanto, Google pone un tope del 50% en el trabajo de "operaciones" agregado para todos los SRE: entradas, guardias, tareas manuales, etc. Este límite garantiza que el equipo de SRE tenga tiempo suficiente en su agenda para hacer que el servicio sea estable y operativo. Este tope es un límite superior; con el tiempo, si se les deja a su aire, el equipo de SRE debería acabar teniendo muy poca carga operativa y dedicarse casi por completo a tareas de desarrollo, porque el servicio básicamente funciona y se repara solo: queremos sistemas que sean automáticos, no sólo automatizados. En la práctica, la escala y las nuevas funciones mantienen a los SRE en estado de alerta.
La regla general de Google es que un equipo de SRE debe pasar el 50% restante de su tiempo realmente haciendo desarrollo. Entonces, ¿cómo hacemos cumplir ese umbral? En primer lugar, tenemos que medir cómo se emplea el tiempo de SRE. Con esa medición en la mano, nos aseguramos de que los equipos que dedican sistemáticamente menos del 50% de su tiempo al trabajo de desarrollo cambien sus prácticas. A menudo esto significa devolver parte de la carga de operaciones al equipo de desarrollo, o añadir personal al equipo sin asignarle responsabilidades operativas adicionales. Mantener conscientemente este equilibrio entre el trabajo operativo y el de desarrollo nos permite garantizar que los SRE tengan el ancho de banda necesario para dedicarse a la ingeniería creativa y autónoma, al tiempo que conservan la sabiduría obtenida del lado operativo de la gestión de un servicio.
Hemos descubierto que el enfoque de Google SRE para ejecutar sistemas a gran escala tiene muchas ventajas. Dado que los SRE modifican directamente el código en su afán por hacer que los sistemas de Google funcionen por sí mismos, los equipos SRE se caracterizan tanto por una rápida innovación como por una gran aceptación del cambio. Dichos equipos son relativamente baratos: para prestar el mismo servicio con un equipo orientado a operaciones se necesitaría un número de personas significativamente mayor. En cambio, el número de SRE necesarios para ejecutar, mantener y mejorar un sistema aumenta de forma sublineal con el tamaño del sistema. Por último, la SRE no sólo evita la disfuncionalidad de la división entre desarrollo y operaciones, sino que esta estructura también mejora nuestros equipos de desarrollo de productos: las transferencias fáciles entre los equipos de desarrollo de productos y de SRE forman de forma cruzada a todo el grupo, y mejoran las habilidades de los desarrolladores que, de otro modo, podrían tener dificultades para aprender a construir un sistema distribuido de un millón de núcleos.
A pesar de estas ganancias netas, el modelo SRE se caracteriza por su propio conjunto de retos. Uno de los retos continuos a los que se enfrenta Google es la contratación de SRE: no sólo compite por los mismos candidatos que la línea de contratación de desarrollo de productos, sino que el hecho de que pongamos el listón de la contratación tan alto en términos de habilidades de codificación y de ingeniería de sistemas significa que nuestro grupo de contratación es necesariamente pequeño. Como nuestra disciplina es relativamente nueva y única, no existe mucha información en el sector sobre cómo crear y gestionar un equipo de SRE (¡aunque esperemos que este libro avance en esa dirección!). Y una vez que un equipo de SRE está en marcha, sus enfoques potencialmente poco ortodoxos de la gestión de servicios requieren un fuerte apoyo de la dirección. Por ejemplo, la decisión de detener los lanzamientos durante el resto del trimestre una vez agotado el presupuesto para errores podría no ser aceptada por un equipo de desarrollo de productos, a menos que lo ordene su dirección.
Principios de la ESR
Aunque los matices de los flujos de trabajo, las prioridades y las operaciones cotidianas varían de un equipo de SRE a otro, todos comparten un conjunto de responsabilidades básicas para el servicio o servicios que soportan, y se adhieren a los mismos principios básicos. En general, un equipo de SRE es responsable de ladisponibilidad, latencia, rendimiento, eficiencia, gestión de cambios, monitoreo, respuesta a emergencias y planificación de la capacidad de su(s) servicio(s). Hemos codificado normas de compromiso y principios sobre cómo interactúan los equipos de SRE con su entorno: no sólo con el entorno de producción, sino también con los equipos de desarrollo de productos, los equipos de pruebas, los usuarios, etc. Esas normas y prácticas de trabajo nos ayudan a mantener nuestro enfoque en el trabajo de ingeniería, en contraposición al trabajo de operaciones.
La siguiente sección analiza cada uno de los principios básicos de la SRE de Google.
Garantizar un enfoque duradero de la ingeniería
Como ya se ha dicho, Google limita el trabajo operativo de los SRE al 50% de su tiempo. El tiempo restante debe dedicarse a utilizar sus habilidades de codificación en el trabajo del proyecto. En la práctica, esto se consigue monitoreando la cantidad de trabajo operativo que realizan los SRE y redirigiendo el exceso de trabajo operativo a los equipos de desarrollo de productos: reasignando errores y tickets a los gestores de desarrollo, [re]integrando a los desarrolladores en las rotaciones de buscapersonas de guardia, etcétera. La redirección finaliza cuando la carga operativa vuelve a descender al 50% o menos. Esto también proporciona un mecanismo eficaz de retroalimentación, guiando a los desarrolladores para que construyan sistemas que no necesiten intervención manual. Este enfoque funciona bien cuando toda la organización -SRE y desarrollo por igual- entiende por qué existe el mecanismo de la válvula de seguridad, y apoya el objetivo de no tener eventos de desbordamiento porque el producto no genera suficiente carga operativa para requerirlo.
Cuando están centrados en el trabajo de operaciones, por término medio, los SRE deben recibir un máximo de dos incidencias por turno de guardia de 8-12 horas. Este volumen objetivo da al ingeniero de guardia tiempo suficiente para tratar el incidente con precisión y rapidez, limpiarlo y restablecer el servicio normal, y luego realizar una autopsia. Si se producen con regularidad más de dos incidencias por turno de guardia, los problemas no pueden investigarse a fondo y los ingenieros se ven lo suficientemente desbordados como para impedirles aprender de estos sucesos. A la inversa, si los SRE de guardia reciben sistemáticamente menos de un incidente por turno, mantenerlos a punto es una pérdida de su tiempo.
Deben redactarse autoinformes de todos los incidentes significativos, independientemente de que hayan dado lugar o no a un aviso; los autoinformes que no hayan dado lugar a un aviso son aún más valiosos, ya que probablemente señalen claras lagunas en el monitoreo. Esta investigación debe establecer lo ocurrido en detalle, encontrar todas las causas raíz del suceso y asignar acciones para corregir el problema o mejorar la forma de abordarlo la próxima vez. Google opera bajo una cultura postmortem libre de culpa, con el objetivo de exponer los fallos y aplicar ingeniería para solucionarlos, en lugar de evitarlos o minimizarlos.
Perseguir la máxima velocidad de cambio sin violar la SLO de un servicio
Los equipos de desarrollo de productos y de SRE pueden disfrutar de una relación de trabajo productiva eliminando el conflicto estructural de sus respectivos objetivos. El conflicto estructural está entre el ritmo de innovación y la estabilidad del producto, y como se ha descrito antes, este conflicto a menudo se expresa indirectamente. En la ESR sacamos a la luz este conflicto, y luego lo resolvemos con la introducción de unpresupuesto de errores.
El presupuesto de error se deriva de la observación de que el 100% es un objetivo de fiabilidad erróneo para prácticamente todo (los marcapasos y los frenos antibloqueo son excepciones notables). En general, para cualquier servicio o sistema de software, el 100% no es el objetivo de fiabilidad adecuado, porque ningún usuario puede distinguir entre un sistema disponible al 100% y otro al 99,999%. Hay muchos otros sistemas en el camino entre el usuario y el servicio (su portátil, el WiFi de su casa, su ISP, la red eléctrica...) y esos sistemas en conjunto tienen una disponibilidad muy inferior al 99,999%. Por tanto, la diferencia marginal entre el 99,999% y el 100% se pierde en el ruido de otras indisponibilidades, y el usuario no recibe ningún beneficio del enorme esfuerzo necesario para añadir ese último 0,001% de disponibilidad.
Si el 100% es un objetivo de fiabilidad erróneo para un sistema, ¿cuál es entonces el objetivo de fiabilidad correcto para el sistema? En realidad, no se trata de una cuestión técnica, sino de una cuestión de producto, que debería tener en cuenta las siguientes consideraciones:
-
¿Con qué nivel de disponibilidad estarán satisfechos los usuarios, teniendo en cuenta cómo utilizan el producto?
-
¿Qué alternativas hay disponibles para los usuarios que no estén satisfechos con la disponibilidad del producto?
-
¿Qué ocurre con el uso que hacen los usuarios del producto en los distintos niveles de disponibilidad?
La empresa o el producto deben establecer el objetivo de disponibilidad del sistema. Una vez establecido ese objetivo, el presupuesto de errores es uno menos el objetivo de disponibilidad. Un servicio que está disponible al 99,99% tiene un 0,01% de indisponibilidad. Ese 0,01% de indisponibilidad permitida es elpresupuesto de errores del servicio. Podemos gastar el presupuesto en lo que queramos, siempre que no lo sobrepasemos.
Entonces, ¿cómo queremos gastar el presupuesto para errores? El equipo de desarrollo quiere lanzar funciones y atraer a nuevos usuarios. Idealmente, gastaríamos todo nuestro presupuesto de errores asumiendo riesgos con las cosas que lanzamos para lanzarlas rápidamente. Esta premisa básica describe todo el modelo de los presupuestos para errores. En cuanto las actividades de la ESR se conceptualizan en este marco, liberar el presupuesto de errores mediante tácticas como los lanzamientos por fases y los experimentos del 1% puede optimizar lanzamientos más rápidos.
El uso de un presupuesto de errores resuelve el conflicto estructural de incentivos entre el desarrollo y la SRE. El objetivo de la SRE ya no es "cero interrupciones", sino que los SRE y los desarrolladores de productos pretenden gastar el presupuesto de errores para conseguir la máxima velocidad de las características. Este cambio marca la diferencia. Una interrupción ya no es algo "malo": es una parte esperada del proceso de innovación, y un acontecimiento que tanto los equipos de desarrollo como los de SRE gestionan en lugar de temer.
Monitoreo
El monitoreo es uno de los principales medios por los que los propietarios de servicios controlan la salud y disponibilidad de un sistema. Como tal, la estrategia de monitoreo debe construirse cuidadosamente. Un enfoque clásico y común del monitoreo consiste en vigilar un valor o condición específicos, y luego activar una alerta por correo electrónico cuando se supere ese valor o se produzca esa condición. Sin embargo, este tipo de alerta por correo electrónico no es una solución eficaz: un sistema que requiere que un humano lea un correo electrónico y decida si hay que tomar algún tipo de acción como respuesta es fundamentalmente defectuoso. El monitoreo nunca debe requerir que un humano interprete ninguna parte del dominio de alerta. En su lugar, el software debe hacer la interpretación, y los humanos deben ser notificados sólo cuando necesiten tomar medidas.
Hay tres tipos de salida de monitoreo válida:
- Alertas
-
Significan que un ser humano necesita actuar inmediatamente en respuesta a algo que está ocurriendo o a punto de ocurrir, para mejorar la situación.
- Entradas
-
Indican que un humano debe actuar, pero no inmediatamente. El sistema no puede manejar automáticamente la situación, pero si un humano actúa dentro de unos días, no se producirá ningún daño.
- Registro
-
Nadie necesita mirar esta información, pero se registra con fines de diagnóstico o forenses. La expectativa es que nadie lea los registros a menos que algo se lo pida.
Respuesta de emergencia
La fiabilidad es una función del tiempo medio hasta el fallo (MTTF) y del tiempo medio hasta la reparación (MTTR) [Sch15]. La métrica más relevante para evaluar la eficacia de la respuesta de emergencia es la rapidez con la que el equipo de respuesta puede devolver la salud al sistema, es decir, el MTTR.
Los humanos añaden latencia. Aunque un sistema determinado experimente más fallos reales, un sistema que pueda evitar emergencias que requieran la intervención humana tendrá mayor disponibilidad que un sistema que requiera la intervención de personas. Cuando los humanos son necesarios, hemos descubierto que pensar y registrar las buenas prácticas con antelación en un "libro de jugadas" produce aproximadamente una mejora de 3 veces en el MTTR en comparación con la estrategia de "improvisar". El ingeniero de guardia héroe y multiusos funciona, pero el ingeniero de guardia con práctica y armado con un libro de jugadas funciona mucho mejor. Aunque ningún libro de jugadas, por completo que sea, sustituye a los ingenieros inteligentes capaces de pensar sobre la marcha, los pasos y consejos claros y minuciosos para la solución de problemas son valiosos cuando se responde a una página de alto riesgo o sensible al tiempo. Así, Google SRE confía en los libros de jugadas de guardia, además de en ejercicios como la "Rueda de la Desgracia".2 para preparar a los ingenieros a reaccionar ante situaciones de guardia.
Gestión del cambio
La SRE ha descubierto que aproximadamente el 70% de las interrupciones se deben a cambios en un sistema activo. Las buenas prácticas en este ámbito utilizan la automatización para lograr lo siguiente:
-
Poner en marcha implantaciones progresivas
-
Detectar problemas con rapidez y precisión
-
Revertir los cambios de forma segura cuando surgen problemas
Este trío de prácticas minimiza eficazmente el número total de usuarios y operaciones expuestos a los malos cambios. Al eliminar a los humanos del bucle, estas prácticas evitan los problemas normales de fatiga, familiaridad/desgana y falta de atención a tareas muy repetitivas. Como resultado, aumentan tanto la velocidad de liberación como la seguridad.
Previsión de la demanda y planificación de la capacidad
La previsión de la demanda y la planificación de la capacidad pueden considerarse como la garantía de que existe suficiente capacidad y redundancia para atender la demanda futura prevista con la disponibilidad requerida. No hay nada particularmente especial en estos conceptos, salvo que un número sorprendente de servicios y equipos no toman las medidas necesarias para garantizar que la capacidad requerida esté disponible en el momento en que se necesite. La planificación de la capacidad debe tener en cuenta tanto el crecimiento orgánico (que se deriva de la adopción y el uso natural del producto por parte de los clientes) como el crecimiento inorgánico (que resulta de acontecimientos como el lanzamiento de funciones, campañas de marketing u otros cambios impulsados por la empresa).
En la planificación de la capacidad son obligatorios varios pasos:
-
Una previsión precisa de la demanda orgánica, que se extienda más allá del plazo necesario para adquirir capacidad
-
Una incorporación precisa de las fuentes de demanda inorgánica en la previsión de la demanda
-
Pruebas periódicas de carga del sistema para correlacionar la capacidad bruta (servidores, discos, etc.) con la capacidad de servicio
Dado que la capacidad es fundamental para la disponibilidad, se deduce naturalmente que el equipo de SRE debe encargarse de la planificación de la capacidad, lo que significa que también debe encargarse del aprovisionamiento.
Aprovisionamiento
El aprovisionamiento combina la gestión del cambio y la planificación de la capacidad. Según nuestra experiencia, el aprovisionamiento debe realizarse rápidamente y sólo cuando sea necesario, ya que la capacidad es cara. Este ejercicio también debe hacerse correctamente o la capacidad no funcionará cuando se necesite. Añadir nueva capacidad suele implicar poner en marcha una nueva instancia o ubicación, realizar modificaciones importantes en los sistemas existentes (archivos de configuración, equilibradores de carga, redes) y validar que la nueva capacidad funciona y ofrece resultados correctos. Por tanto, es una operación más arriesgada que el cambio de carga, que a menudo se hace varias veces por hora, y debe tratarse con el correspondiente grado de precaución adicional.
Eficacia y rendimiento
El uso eficiente de los recursos es importante siempre que un servicio se preocupe por el dinero. Dado que la SRE controla en última instancia el aprovisionamiento, también debe participar en cualquier trabajo sobre la utilización, ya que ésta es una función de cómo funciona un servicio determinado y cómo se aprovisiona. De ello se deduce que prestar mucha atención a la estrategia de aprovisionamiento de un servicio, y por tanto a su utilización, supone una palanca muy, muy grande sobre los costes totales del servicio.
El uso de recursos es una función de la demanda (carga), la capacidad y la eficiencia del software. Las SRE predicen la demanda, proporcionan capacidad y pueden modificar el software. Estos tres factores son una gran parte (aunque no la totalidad) de la eficiencia de un servicio.
Los sistemas de software se vuelven más lentos a medida que se les añade carga. La ralentización de un servicio equivale a una pérdida de capacidad. En algún momento, un sistema que se ralentiza deja de prestar servicio, lo que corresponde a una lentitud infinita. Los SRE provisionan para cumplir un objetivo de capacidad a una velocidad de respuesta específica, y por tanto se interesan mucho por el rendimiento de un servicio. Los SRE y los desarrolladores de productos monitorizarán (y deberían hacerlo) y modificarán un servicio para mejorar su rendimiento, añadiendo así capacidad y mejorando la eficiencia.3
El final del principio
La Ingeniería de Fiabilidad del Sitio Web representa una ruptura significativa con las buenas prácticas existentes en el sector para gestionar servicios grandes y complicados. Motivada originalmente por la familiaridad - "como ingeniero de software, así es como me gustaría invertir mi tiempo para realizar un conjunto de tareas repetitivas"-, se ha convertido en mucho más: un conjunto de principios, un conjunto de prácticas, un conjunto de incentivos y un campo de trabajo dentro de la disciplina más amplia de la ingeniería de software. El resto del libro explora en detalle la SRE Way.
1 Vicepresidente de Ingeniería de Google, fundador de Google SRE
2 Ver "Juego de rol en caso de catástrofe".
3 Para saber más sobre cómo puede funcionar esta colaboración en la práctica, consulta "Comunicaciones: Reuniones de producción".
Get Ingeniería de Fiabilidad del Sitio now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
