En uno de nuestros artículos anteriores,discutimos qué es un SRE, qué hacen y algunas de las responsabilidades comunes que puede tener un SRE típico, como apoyar las operaciones, lidiar con los tickets de problemas y la respuesta a incidentes, y el monitoreo y la observabilidad general del sistema. En este artículo, profundizaremos en los diversos principios y pautas de SRE que un ingeniero de confiabilidad del sitio practica en su función. Al igual que DevOps, estos principios de SRE sirven como una guía para impulsar la alineación en lo que se refiere a alinear, cumplir y apoyar los objetivos de la organización.
Google fue la primera compañía en crear, adoptar y apoyar el papel de la ingeniería de confiabilidad del sitio. Desde entonces, el papel de SRE ha evolucionado a medida que la industria ha cambiado y ha pasado de las estructuras monolíticas tradicionales a grandes redes y microservicios ampliamente distribuidos. Sin embargo, una cosa ha permanecido en gran medida igual: los principios a los que se adhieren los SRO. Estos principios básicos de SRE se centran en una cosa: el sistema de conducción y la fiabilidad del servicio. Profundicemos en estos principios básicos de la SRE.
Principios de SRE
Aceptar y gestionar el riesgo
Aceptar el riesgo es lo primero de los principios de SRE, y por una buena razón. Para mejorar la confiabilidad de un sistema, es importante medir el impacto de las fallas de “qué pasaría si”. Se entiende que ningún sistema es 100 por ciento confiable. En algún momento, algo va a salir mal. Desafortunadamente, el usuario o cliente cotidiano no sabe, o no le importa, ser tan comprensivo. Y hay un costo inherente asociado con garantizar la confiabilidad. Ya sea que eso signifique un costo financiero, un costo de tiempo o simplemente la confianza de un cliente en sus servicios.
Una responsabilidad de los SRO es apoyarse en el fracaso y el riesgo para aprender cómo pueden hacer que sus servicios y sistemas sean más resistentes. Sin embargo, hay compensaciones que deben considerarse. Por ejemplo, garantizar la máxima fiabilidad puede tener el costo de poder implementar más rápidamente servicios futuros. ¿O tal vez las mejoras adicionales no necesariamente significan una ganancia sustancial en los ingresos? El objetivo es hacer un sistema confiable, pero no más de lo que debe ser, ya que el costo y el tiempo asociados con hacerlo superan los beneficios potenciales.
Objetivos de nivel de servicio
El principio de aceptar el riesgo está estrechamente vinculado a los objetos de nivel de servicio o SLA. Para profundizar un poco más, los SLO son el conjunto formalizado de objetivos dentro de un acuerdo de nivel de servicio (SLA) que se miden con respecto a los indicadores de nivel de servicio o SLÍ. Los SLA son las métricas de rendimiento reales de sus servicios. Por ejemplo, si su SLO indica que su tiempo de actividad debe ser del 99,9%, el SLI real debe cumplir o superar esa métrica de rendimiento para cumplir con ese SLO específico. Los SLÍ son los indicadores que un SRE monitorearía continuamente, de modo que si alguna vez sale de ese umbral, los equipos son alertados y el problema puede resolverse rápidamente. Los SLÍ están realmente vinculados al usuario para determinar qué es lo más importante para su experiencia en relación con el servicio.
SLAs vs. SLOs vs. SLIs
- SLA. Acuerdos realizados con sus clientes o clientes que definen el nivel de servicio que se va a entregar.
- SLA. Un acuerdo dentro del SLA que establece métricas específicas, como tiempo de actividad, tiempo de respuesta, seguridad, resolución de problemas, etc.
- SLIs. El rendimiento real, o mediciones, de sus SLO que determinan el nivel de cumplimiento.
Los SLA utilizados para medir el rendimiento real frente al SLA, que son los acuerdos entre un proveedor de servicios y el cliente. Una vez más, todo esto se remonta a la idea de que debe haber un acuerdo o entendimiento sobre cuánto riesgo, o tolerancia, se puede permitir para un servicio determinado.
Lea: Obtenga más información sobre cómo administrar el cumplimiento de SLA dentro de su organización.
Elimine el trabajo
El trabajo, tal como se define con el alcance de la función SRE, es la cantidad de trabajo manual que se requiere para garantizar que los servicios se estén ejecutando. Uno de los principales objetivos de un SRE es automatizar la mayor cantidad de trabajo posible. Esto permite que los SRO abran más tiempo para tareas más importantes. Y cuando lo piensas, reducir el trabajo debería ser realmente parte del trabajo de cualquier persona. Cuanto menos tiempo se necesite en tareas redundantes se garantiza una mejor productividad a largo plazo. Cada vez que un ingeniero de confiabilidad del sitio debe participar en actividades manuales repetitivas, en lo que se refiere a la gestión del servicio de producción, esto puede describirse como trabajo.
En muchos casos, puede haber ocasiones en las que una SRE tenga que llevar a cabo actividades manuales que consumen mucho tiempo, pero no todas deben definirse como trabajo. Sin embargo, es clave definir qué actividades dentro del equipo de SRE están consumiendo más tiempo. A partir de ahí, identifique dónde se pueden hacer mejoras para reducir la cantidad de trabajo para un mejor equilibrio laboral. Cuando Google introdujo por primera vez el papel de SRE, establecieron el objetivo de que la mitad del tiempo de un SRE se centrara en reducir el trabajo operativo futuro o agregar características de servicio. El desarrollo de nuevas características se correlaciona con la mejora de métricas como la confiabilidad y el rendimiento, lo que en última instancia reduce el trabajo potencial en el futuro.
Monitoreo
En Dotcom-Monitor, nos preocupamos por las soluciones de monitoreo para rastrear el tiempo de actividad, la disponibilidad, la funcionalidad y el rendimiento general de servidores, sitios web, servicios y aplicaciones. El monitoreo es uno de los principios más importantes de SRE dentro del rol. El monitoreo continuo garantiza que los servicios funcionen según lo previsto y puede ayudar a identificar el momento en que surgen los problemas para que puedan solucionarse de inmediato. Como mencionamos en la sección anterior, cumplir con esos SLO es clave para los SLA comerciales definidos y, en última instancia, para los usuarios. El monitoreo puede proporcionar a los SRE y equipos una tendencia histórica de rendimiento y puede ofrecer información sobre lo que es un problema único frente a un problema sistémico más amplio. Según lo definido por la iniciativa Google SRE, las cuatro señales de oro del monitoreo incluyen las siguientes métricas:
- Latencia. La latencia es la cantidad de tiempo, o retraso, que tarda un servicio en responder a una solicitud. Claramente, los tiempos de respuesta lentos afectarán la experiencia percibida del usuario. El monitoreo puede proporcionar una forma de diferenciar entre
- Tráfico. El tráfico se refiere a la cantidad de demanda o carga del usuario que hay en el sistema. Esto se puede medir mediante solicitudes HTTP por segundo o dependiendo del servicio real
- Errores. Los errores se refieren a la velocidad a la que fallan las solicitudes al servicio. Sin embargo, es importante que los equipos de SRE diferencien entre errores duros, como errores de servidor 500, y errores de software, como una respuesta de 200 OK que se aplicó el tiempo de espera porque se estableció un umbral de rendimiento específico. Es importante considerar cómo monitorear adecuadamente estos diferentes escenarios como estos.
- Saturación. La saturación se trata de medir la cantidad de recursos del sistema que tiene un servicio determinado. Hasta cierto punto, la mayoría de los servicios experimentarán una degradación del rendimiento. Comprender dónde ocurre esto puede ayudar a definir correctamente los objetivos y metas de monitoreo, por lo que se pueden llevar a cabo acciones correctivas.
Automatización
Automatizar, automatizar, automatizar. Mencionamos este principio anteriormente cuando discutimos la reducción del trabajo, pero no se puede subestimar. La naturaleza del papel de la SRE es tan diversa como puede ser un rol. Con el fin de reducir el potencial de intervención manual en todas las facetas de sus responsabilidades, la automatización de tareas es clave para un negocio exitoso. A medida que los servicios escalan y se vuelven más distribuidos, se vuelve mucho más difícil de administrar. Al automatizar las tareas repetitivas en todos los ámbitos, ya sean pruebas, implementación de software, respuesta a incidentes o simplemente comunicación entre equipos, la automatización proporciona beneficios inmediatos, eficiencias y, lo que es más importante, consistencia. Desde el momento en que se concibió el rol de SRE, ha habido un cambio en la forma en que los equipos de desarrollo, control de calidad y operaciones colaboran. Para soportar estos nuevos entornos y prácticas de DevOps, se han desarrollado varias plataformas y herramientas.
Lea: Las 13 mejores herramientas de confiabilidad del sitio (SRE).
Ingeniería de lanzamientos
Ingeniería de lanzamientos. Suena como un tema complejo, pero en realidad, es solo una forma simple de definir cómo se construye y entrega el software. Si bien la ingeniería de lanzamiento en sí misma es su propio título y función, dentro del concepto de SRE, esto significa ofrecer servicios que sean estables, consistentes y, por supuesto, repetibles. Esto se remonta a la sección anterior sobre automatización. Si vas a hacer algo, hazlo bien Y sé capaz de repetirlo de nuevo, de manera consistente, según sea necesario. Construir un montón de servicios únicos lleva mucho tiempo y crea un trabajo innecesario.
Si nos remontamos a la historia de la posición de SRE en Google, tenían ingenieros de lanzamiento dedicados que trabajaban directamente con SRE. Los ingenieros de versiones suelen tener la tarea de definir las mejores prácticas en lo que se refiere al desarrollo de servicios de software, la implementación de actualizaciones, las pruebas continuas y el tratamiento de problemas de software, además de muchas otras responsabilidades. Este rol se vuelve más crítico cuando piensa en cómo escalar los servicios e implementarlos rápidamente. Tener un conjunto de mejores prácticas y herramientas (y hacerlas cumplir) es esencial para poder satisfacer estas demandas y brinda tranquilidad a los equipos de SRE una vez que esa construcción se pone en producción.
Simplicidad
Con una posición que aparentemente no tiene fin a la cantidad de responsabilidades y expectativas como la que tiene el rol de SRE, el último principio, irónicamente, es la simplicidad. Tal vez sea más fácil decirlo que hacerlo en la práctica, este principio se centra en la idea de desarrollar un sistema o servicio que sea tan complejo como sea necesario. Si bien eso puede parecer contradictorio al principio, realmente se reduce a querer un sistema que sea confiable, consistente y predecible. Eso puede sonar aburrido, pero para un SRE, ese es uno de los objetivos finales finales.
Los SSE se esfuerzan por un sistema o servicio que no sea complejo o difícil de administrar. Los SRO quieren uno que simplemente haga el trabajo para el que fue diseñado. Sin embargo, desde la perspectiva de un usuario, un servicio que proporciona muchas características también puede proporcionar muchos beneficios, pero para un SRE, eso solo significa más dolores de cabeza potenciales. Sin embargo, el cambio siempre es inevitable si desea agregar nuevas características a un servicio web, hágalo cuidadosamente. Los cambios incrementales más pequeños son más fáciles (y más simples) de administrar que crear y enviar muchas funciones a la vez. Los SRE también tienen que considerar las necesidades y objetivos del negocio.
Principios de la SRE: Las 7 reglas fundamentales – Reflexiones finales
El rol de SRE se centra en construir, entregar y mantener sistemas y servicios confiables a escala. Estos siete principios básicos ayudan a definir las prácticas para los SRO que ayudan a impulsar la alineación dentro de las prácticas de DevOps y respaldan los objetivos del negocio. Es un rol complejo que busca equilibrar la confiabilidad con los lanzamientos de características, todo mientras se mantienen niveles excepcionales de calidad.
La plataforma Dotcom-Monitor proporciona a los SRO todas las funciones de monitoreo que necesitan para garantizar la continuidad de sus servicios. Desde alertas e informes configurables hasta paneles e informes en tiempo real, la plataforma proporciona las herramientas esenciales necesarias para administrar el rendimiento de todos sus servicios a largo plazo. Por ejemplo, cree scripts de aplicaciones web basados en el comportamiento, las acciones y las rutas de acceso del usuario y configure tareas de supervisión sintéticas para garantizar una experiencia coherente a lo largo del tiempo. No importa el nivel de monitoreo que requiera su equipo, existe una solución para satisfacer sus necesidades.
Comience de forma gratuita con la prueba de 30 días de Dotcom-Monitor o programe una demostración con uno de nuestros ingenieros de rendimiento.
