{"id":22392,"date":"2021-11-16T17:41:33","date_gmt":"2021-11-16T17:41:33","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/2021\/11\/16\/principios-de-la-sre-las-7-reglas-fundamentales\/"},"modified":"2026-06-15T15:45:15","modified_gmt":"2026-06-15T15:45:15","slug":"principios-de-la-sre-las-7-reglas-fundamentales","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/es\/principios-de-la-sre-las-7-reglas-fundamentales\/","title":{"rendered":"Principios de la SRE: Las 7 reglas fundamentales"},"content":{"rendered":"\t\t<div data-elementor-type=\"wp-post\" data-elementor-id=\"22392\" class=\"elementor elementor-22392 elementor-22375\" data-elementor-settings=\"{&quot;ha_cmc_init_switcher&quot;:&quot;no&quot;}\" data-elementor-post-type=\"post\">\n\t\t\t\t\t\t<section class=\"elementor-section elementor-top-section elementor-element elementor-element-7ba9d136 elementor-section-boxed elementor-section-height-default elementor-section-height-default\" data-id=\"7ba9d136\" data-element_type=\"section\" data-e-type=\"section\" data-settings=\"{&quot;jet_parallax_layout_list&quot;:[],&quot;_ha_eqh_enable&quot;:false}\">\n\t\t\t\t\t\t<div class=\"elementor-container elementor-column-gap-default\">\n\t\t\t\t\t<div class=\"elementor-column elementor-col-100 elementor-top-column elementor-element elementor-element-36cba459\" data-id=\"36cba459\" data-element_type=\"column\" data-e-type=\"column\">\n\t\t\t<div class=\"elementor-widget-wrap elementor-element-populated\">\n\t\t\t\t\t\t<div class=\"elementor-element elementor-element-616e1a2b elementor-widget elementor-widget-text-editor\" data-id=\"616e1a2b\" data-element_type=\"widget\" data-e-type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<p>En uno de nuestros <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/2021\/10\/06\/what-is-a-site-reliability-engineer-sre\/\">art\u00edculos anteriores,<\/a>discutimos qu\u00e9 es un SRE, qu\u00e9 hacen y algunas de las responsabilidades comunes que puede tener un SRE t\u00edpico, 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\u00edculo, profundizaremos en los diversos principios y pautas de SRE que un ingeniero de confiabilidad del sitio practica en su funci\u00f3n. Al igual que DevOps, estos principios de SRE sirven como una gu\u00eda para impulsar la alineaci\u00f3n en lo que se refiere a alinear, cumplir y apoyar los objetivos de la organizaci\u00f3n.<\/p><p>Google fue la primera compa\u00f1\u00eda en crear, adoptar y apoyar el papel de la ingenier\u00eda 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\u00edticas 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\u00e1sicos de SRE se centran en una cosa: el sistema de conducci\u00f3n y la fiabilidad del servicio. Profundicemos en estos principios b\u00e1sicos de la SRE.<\/p><h2 id='principios-de-sre'  id=\"boomdevs_1\">Principios de SRE<\/h2><h3 id='aceptar-y-gestionar-el-riesgo'  id=\"boomdevs_2\">Aceptar y gestionar el riesgo<\/h3><p>Aceptar el riesgo es en realidad uno de los principios b\u00e1sicos de la SRE, y es f\u00e1cil ver por qu\u00e9. Para hacer que un sistema sea m\u00e1s confiable, debe considerar escenarios hipot\u00e9ticos y aprender de los posibles fallos. Ning\u00fan sistema es 100% fiable y, en alg\u00fan momento, algo va a salir mal. Desafortunadamente, la mayor\u00eda 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.<\/p><p>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\u00eda significar ralentizar el ritmo de las nuevas funciones, o podr\u00eda generar m\u00e1s costos sin un gran aumento en los ingresos. La idea no es hacer que un sistema sea m\u00e1s confiable de lo que realmente debe ser. Despu\u00e9s 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 &#8220;justo&#8221; de confiabilidad que equilibre el costo, la velocidad y el valor.<\/p><h3 id='objetivos-de-nivel-de-servicio'  id=\"boomdevs_3\">Objetivos de nivel de servicio<\/h3><p>El principio de aceptar el riesgo est\u00e1 estrechamente relacionado con los objetivos de nivel de servicio (SLO). Para desglosarlo, los SLO son objetivos de rendimiento espec\u00edficos dentro de un Acuerdo de Nivel de Servicio (SLA) que se miden en funci\u00f3n de los Indicadores de Nivel de Servicio (SLI), las m\u00e9tricas 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\u00e1 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\u00e1pidamente. En \u00faltima instancia, los SLI se centran en lo que m\u00e1s importa a los usuarios, lo que ayuda a los equipos a priorizar los aspectos del servicio que afectan directamente a la experiencia del usuario.<\/p><p>Aqu\u00ed hay un desglose r\u00e1pido de estos t\u00e9rminos:<\/p><ul><li>SLA: Los acuerdos generales con los clientes o consumidores sobre el nivel de servicio que se va a prestar.<\/li><li>SLO: objetivos de rendimiento espec\u00edficos dentro del SLA, como el tiempo de actividad, el tiempo de respuesta o los est\u00e1ndares de seguridad.<\/li><li>SLI: Las mediciones de rendimiento reales que rastrean el cumplimiento de los SLO.<\/li><\/ul><p>En esencia, los SLO permiten a los equipos medir el rendimiento real en comparaci\u00f3n con el SLA, estableciendo expectativas claras sobre la calidad del servicio. Esta estructura refuerza que existe una tolerancia acordada al riesgo, definiendo cu\u00e1nta variabilidad o tiempo de inactividad puede soportar un servicio sin dejar de satisfacer las necesidades del usuario y los objetivos empresariales.<\/p><p><strong>Lea<\/strong>: Obtenga m\u00e1s informaci\u00f3n sobre <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/2020\/06\/16\/sla-compliance-for-saas-businesses\/\">c\u00f3mo administrar el cumplimiento de SLA<\/a> dentro de su organizaci\u00f3n.<\/p><h3 id='elimine-el-trabajo'  id=\"boomdevs_4\">Elimine el trabajo<\/h3><p>El trabajo, tal como se define con el alcance de la funci\u00f3n SRE, es la cantidad de trabajo manual que se requiere para garantizar que los servicios se est\u00e9n ejecutando. Uno de los principales objetivos de un SRE es automatizar la mayor cantidad de trabajo posible. Esto permite que los SRO abran m\u00e1s tiempo para tareas m\u00e1s importantes. Y cuando lo piensas, reducir el trabajo deber\u00eda 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\u00f3n del servicio de producci\u00f3n, esto puede describirse como trabajo.<\/p><p>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\u00e9 actividades dentro del equipo de SRE est\u00e1n consumiendo m\u00e1s tiempo. A partir de ah\u00ed, identifique d\u00f3nde 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\u00edsticas de servicio. El desarrollo de nuevas caracter\u00edsticas se correlaciona con la mejora de m\u00e9tricas como la confiabilidad y el rendimiento, lo que en \u00faltima instancia reduce el trabajo potencial en el futuro.<\/p><h3 id='monitoreo'  id=\"boomdevs_5\">Monitoreo<\/h3><p>En Dotcom-Monitor, nos preocupamos por <a href=\"https:\/\/www.dotcom-monitor.com\/solutions\/\">las soluciones de monitoreo<\/a> 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\u00e1s importantes de SRE dentro del rol. El monitoreo continuo garantiza que los servicios funcionen seg\u00fan 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\u00f3n anterior, cumplir con esos SLO es clave para los SLA comerciales definidos y, en \u00faltima instancia, para los usuarios. El monitoreo puede proporcionar a los SRE y equipos una tendencia hist\u00f3rica de rendimiento y puede ofrecer informaci\u00f3n sobre lo que es un problema \u00fanico frente a un problema sist\u00e9mico m\u00e1s amplio. Seg\u00fan lo definido por la iniciativa Google SRE, las cuatro se\u00f1ales de oro del monitoreo incluyen las siguientes m\u00e9tricas:<\/p><ul><li><strong>Latencia<\/strong>. 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\u00e1n la experiencia percibida del usuario. El monitoreo puede proporcionar una forma de diferenciar entre<\/li><li><strong>Tr\u00e1fico<\/strong>. El tr\u00e1fico 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<\/li><li><strong>Errores<\/strong>. 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\u00f3 el tiempo de espera porque se estableci\u00f3 un umbral de rendimiento espec\u00edfico. Es importante considerar c\u00f3mo monitorear adecuadamente estos diferentes escenarios como estos.<\/li><li><strong>Saturaci\u00f3n<\/strong>. La saturaci\u00f3n se trata de medir la cantidad de recursos del sistema que tiene un servicio determinado. Hasta cierto punto, la mayor\u00eda de los servicios experimentar\u00e1n una degradaci\u00f3n del rendimiento. Comprender d\u00f3nde ocurre esto puede ayudar a definir correctamente los objetivos y metas de monitoreo, por lo que se pueden llevar a cabo acciones correctivas.<\/li><\/ul><h3 id='automatizaci\u00f3n'  id=\"boomdevs_6\">Automatizaci\u00f3n<\/h3><p>Automatizar, automatizar, automatizar. Mencionamos este principio anteriormente cuando discutimos la reducci\u00f3n 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\u00f3n manual en todas las facetas de sus responsabilidades, la automatizaci\u00f3n de tareas es clave para un negocio exitoso. A medida que los servicios escalan y se vuelven m\u00e1s distribuidos, se vuelve mucho m\u00e1s dif\u00edcil de administrar. Al automatizar las tareas repetitivas en todos los \u00e1mbitos, ya sean pruebas, implementaci\u00f3n de software, respuesta a incidentes o simplemente comunicaci\u00f3n entre equipos, la automatizaci\u00f3n proporciona beneficios inmediatos, eficiencias y, lo que es m\u00e1s importante, consistencia. Desde el momento en que se concibi\u00f3 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\u00e1cticas de DevOps, se han desarrollado varias plataformas y herramientas.<\/p><p><strong>Lea:<\/strong> <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/2021\/10\/20\/top-13-site-reliability-engineer-sre-tools\/\">Las 13 mejores herramientas de confiabilidad del sitio (SRE).<\/a><\/p><h3 id='ingenier\u00eda-de-lanzamientos'  id=\"boomdevs_7\">Ingenier\u00eda de lanzamientos<\/h3><p>Ingenier\u00eda de lanzamientos. Suena como un tema complejo, pero en realidad, es solo una forma simple de definir c\u00f3mo se construye y entrega el software. Si bien la ingenier\u00eda de lanzamiento en s\u00ed misma es su propio t\u00edtulo y funci\u00f3n, dentro del concepto de SRE, esto significa ofrecer servicios que sean estables, consistentes y, por supuesto, repetibles. Esto se remonta a la secci\u00f3n anterior sobre automatizaci\u00f3n. Si vas a hacer algo, hazlo bien Y s\u00e9 capaz de repetirlo de nuevo, de manera consistente, seg\u00fan sea necesario. Construir un mont\u00f3n de servicios \u00fanicos lleva mucho tiempo y crea un trabajo innecesario.<\/p><p>Si nos remontamos a la historia de la posici\u00f3n de SRE en Google, ten\u00edan ingenieros de lanzamiento dedicados que trabajaban directamente con SRE. Los ingenieros de versiones suelen tener la tarea de definir las mejores pr\u00e1cticas en lo que se refiere al desarrollo de servicios de software, la implementaci\u00f3n de actualizaciones, las pruebas continuas y el tratamiento de problemas de software, adem\u00e1s de muchas otras responsabilidades. Este rol se vuelve m\u00e1s cr\u00edtico cuando piensa en c\u00f3mo escalar los servicios e implementarlos r\u00e1pidamente. Tener un conjunto de mejores pr\u00e1cticas 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\u00f3n se pone en producci\u00f3n.<\/p><h3 id='simplicidad'  id=\"boomdevs_8\">Simplicidad<\/h3><p>Con una posici\u00f3n que aparentemente no tiene fin a la cantidad de responsabilidades y expectativas como la que tiene el rol de SRE, el \u00faltimo principio, ir\u00f3nicamente, es la simplicidad. Tal vez sea m\u00e1s f\u00e1cil decirlo que hacerlo en la pr\u00e1ctica, 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.<\/p><p>Los SSE se esfuerzan por un sistema o servicio que no sea complejo o dif\u00edcil de administrar. Los SRO quieren uno que simplemente haga el trabajo para el que fue dise\u00f1ado. Sin embargo, desde la perspectiva de un usuario, un servicio que proporciona muchas caracter\u00edsticas tambi\u00e9n puede proporcionar muchos beneficios, pero para un SRE, eso solo significa m\u00e1s dolores de cabeza potenciales. Sin embargo, el cambio siempre es inevitable si desea agregar nuevas caracter\u00edsticas a un servicio web, h\u00e1galo cuidadosamente. Los cambios incrementales m\u00e1s peque\u00f1os son m\u00e1s f\u00e1ciles (y m\u00e1s simples) de administrar que crear y enviar muchas funciones a la vez. Los SRE tambi\u00e9n tienen que considerar las necesidades y objetivos del negocio.<\/p><h2 id='principios-de-la-sre-las-7-reglas-fundamentales-reflexiones-finales'  id=\"boomdevs_9\">Principios de la SRE: Las 7 reglas fundamentales &#8211; Reflexiones finales<\/h2><p>El rol de SRE se centra en construir, entregar y mantener sistemas y servicios confiables a escala. Estos siete principios b\u00e1sicos ayudan a definir las pr\u00e1cticas para los SRO que ayudan a impulsar la alineaci\u00f3n dentro de las pr\u00e1cticas de DevOps y respaldan los objetivos del negocio. Es un rol complejo que busca equilibrar la confiabilidad con los lanzamientos de caracter\u00edsticas, todo mientras se mantienen niveles excepcionales de calidad.<\/p><p>La plataforma Dotcom-Monitor proporciona a los SRO todas las <a href=\"https:\/\/www.dotcom-monitor.com\/features\/\">funciones<\/a> 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 <a href=\"\/blog\/es\/what-is-synthetic-monitoring\/\">de supervisi\u00f3n sint\u00e9ticas<\/a> para garantizar una experiencia coherente a lo largo del tiempo. No importa el nivel de monitoreo que requiera su equipo, existe una soluci\u00f3n para satisfacer sus necesidades.<\/p><p>Comience de forma gratuita con la <a href=\"https:\/\/userauth.dotcom-monitor.com\/Account\/FreeTrialSignUp\">versi\u00f3n de prueba gratuita de Dotcom-Monitor<\/a> o programe una <a href=\"https:\/\/www.dotcom-monitor.com\/demo\/\">demostraci\u00f3n<\/a> con uno de nuestros ingenieros de rendimiento.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"<p>En uno de nuestros art\u00edculos anteriores,discutimos qu\u00e9 es un SRE, qu\u00e9 hacen y algunas de las responsabilidades comunes que puede tener un SRE t\u00edpico, 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\u00edculo, profundizaremos en los diversos [&hellip;]<\/p>\n","protected":false},"author":21,"featured_media":22384,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-22392","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/posts\/22392","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/comments?post=22392"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/posts\/22392\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/media\/22384"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/media?parent=22392"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/categories?post=22392"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/tags?post=22392"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}