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 en realidad uno de los principios básicos de la SRE, y es fácil ver por qué. Para hacer que un sistema sea más confiable, debe considerar escenarios hipotéticos y aprender de los posibles fallos. Ningún sistema es 100% fiable y, en algún momento, algo va a salir mal. Desafortunadamente, la mayoría de los usuarios no conocen (o no les importa particularmente) esta realidad. Solo quieren que las cosas funcionen, y siempre hay un costo para lograr esa confiabilidad, ya sea en dinero, tiempo o incluso en mantener la confianza del cliente.
Para los SRE, apoyarse en el riesgo y aprender de los fracasos es esencial para construir sistemas resilientes. Pero siempre hay que sopesar las compensaciones. Maximizar la confiabilidad podría significar ralentizar el ritmo de las nuevas funciones, o podría generar más costos sin un gran aumento en los ingresos. La idea no es hacer que un sistema sea más confiable de lo que realmente debe ser. Después de todo, si el esfuerzo y los recursos adicionales no agregan un valor significativo, es mejor invertirlos en otra parte. En SRE, se trata de encontrar el nivel “justo” de confiabilidad que equilibre el costo, la velocidad y el valor.
Objetivos de nivel de servicio
El principio de aceptar el riesgo está estrechamente relacionado con los objetivos de nivel de servicio (SLO). Para desglosarlo, los SLO son objetivos de rendimiento específicos dentro de un Acuerdo de Nivel de Servicio (SLA) que se miden en función de los Indicadores de Nivel de Servicio (SLI), las métricas reales que rastrean el rendimiento de su servicio. Por ejemplo, si su SLO indica que el tiempo de actividad debe ser del 99,9%, el SLI mide si está alcanzando esa marca. Estos SLI son monitoreados continuamente por los SRE, por lo que si el rendimiento cae por debajo del umbral acordado, el equipo recibe una alerta y puede responder rápidamente. En última instancia, los SLI se centran en lo que más importa a los usuarios, lo que ayuda a los equipos a priorizar los aspectos del servicio que afectan directamente a la experiencia del usuario.
Aquí hay un desglose rápido de estos términos:
- SLA: Los acuerdos generales con los clientes o consumidores sobre el nivel de servicio que se va a prestar.
- SLO: objetivos de rendimiento específicos dentro del SLA, como el tiempo de actividad, el tiempo de respuesta o los estándares de seguridad.
- SLI: Las mediciones de rendimiento reales que rastrean el cumplimiento de los SLO.
En esencia, los SLO permiten a los equipos medir el rendimiento real en comparación con el SLA, estableciendo expectativas claras sobre la calidad del servicio. Esta estructura refuerza que existe una tolerancia acordada al riesgo, definiendo cuánta variabilidad o tiempo de inactividad puede soportar un servicio sin dejar de satisfacer las necesidades del usuario y los objetivos empresariales.
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 versión de prueba gratuita de Dotcom-Monitor o programe una demostración con uno de nuestros ingenieros de rendimiento.
