Aumenta el valor

empresarial con mejores

operaciones de TI
Guía sobre ingeniería de confiabilidad de sitios (SRE)
Contents
Introducción a la SRE ……………………………………………………………………………………………………………… 1
Beneficios de la SRE ………………………………………………….……………………………………………... 1
Google y la SRE …………………………………………………………………………………………..…………….... 2
Análisis detallado de la SRE ……………………………………………………………………………….…..………………... 3
Encontrar un equilibrio entre la confiabilidad y las nuevas funciones….....……………... 3
Los SLO y porcentaje de errores aceptables……….…………………………….…. 5
Uso de SLOs con Google Cloud ……...…………………….………………………….….… 7
Reducir el trabajo pesado …….……………………………………………….…………………………..…... 8
Identificar el trabajo pesado ……….…………………………….………………………………… 8
Redução do trabalho manual com o Google Cloud ……….…………………… 9
Outros aspectos de la SRE ………………………………………………………………………….………..……. 10
Adoptar la SRE ……………………………………………………………………….…………………………………………..……. 11
Próximos pasos ……………………………………………………………………….……………………………………..………. 13
Más información …….……………………………………………………………………………………………….…………..…….. 13
 1

Introducción a la SRE
E¿Te satisface la manera en que tu organización lleva adelante las operaciones de TI? Para responder, piensa
en preguntas como las siguientes:
• ¿Tus aplicaciones son tan confiables
como necesitan los usuarios? • ¿Tu personal operativo responde a los incidentes de
¿Puedes equilibrar de manera manera organizada y efectiva?
efectiva el lanzamiento de nuevas
funciones y, al mismo tiempo, • Una vez que se ha tratado un incidente, ¿realizas un
mantener la confiabilidad? proceso post mortem eficaz que te ayude a aprender
del incidente?
• ¿Eres capaz de retener a tu
personal de operaciones con tareas • ¿Puedes planificar con precisión el futuro de tus
interesantes y no solo trabajo aplicaciones y determinar los recursos humanos e
pesado y repetitivo? informáticos que requerirán?

Si eres como muchas empresas, la respuesta a muchas (quizás incluso la mayoría) de estas
preguntas es «no». La verdad es que no te convence plenamente la manera en que realizas las
operaciones y te gustaría mejorar.

Beneficios de la SRE

Una manera eficaz de mejorar las operaciones de TI es adoptar lo que se conoce como ingeniería de
confiabilidad de sitios (SRE). La SRE es un conjunto de principios y prácticas utilizadas para ejecutar
sistemas de producción que abordan todos los desafíos que hemos mencionado. Contempla:
• El uso de objetivos de nivel de servicio (SLO) y porcentajes de errores aceptables para crear
expectativas claras entre los desarrolladores, el personal operativo y la empresa acerca de la
confiabilidad que debe tener una aplicación y la velocidad con la que se pueden implementar
nuevas funciones.
• La identificación del trabajo pesado y las tareas manuales de mucha carga, con la
consecuente automatización o reducción de esas tareas.
• La creación de un proceso eficaz de administración de incidentes con responsabilidades y
roles bien definidos.
• La ejecución de procesos post mortem para detectar y solucionar problemas subyacentes sin
culpar a nadie.
• Una planificación precisa de capacidades que te permita comprender los recursos humanos e
informáticos que necesitará una aplicación en el futuro.
La SRE puede abarcar más cuestiones, por lo que esta no es una lista exhaustiva. Además, si bien la
SRE aborda muchos aspectos diferentes de las operaciones, no tienes que adoptar todo a la vez. La
mayoría de las organizaciones comienzan donde tienen mayores inconvenientes; por ejemplo,
mejoran la confiabilidad de las aplicaciones o liberan tiempo del personal operativo al reducir el
trabajo pesado, y luego evolucionan a partir de allí. Independientemente de lo que funcione para ti, la
adopción de la SRE puede ayudarte a sentir más satisfacción con la manera en que tu organización
lleva a cabo las operaciones de TI.
 42

Google y la SRE

Organizaciones del sector utilizan la SRE actualmente para mejorar

sus operaciones de TI. Sin embargo, los conceptos y las técnicas
fundamentales de la SRE se crearon en Google a partir de la
experiencia en la ejecución de nuestros servicios. Nosotros
inventamos la SRE, y la hemos estado desarrollando por más tiempo
que cualquier otra empresa. De hecho, todos los servicios de
producción de Google Cloud están respaldados por personal de SRE
de Google. Creemos que esto nos convierte en tu mejor aliado para
implementar la SRE.
Además, proporcionamos compatibilidad integrada con la SRE en
Google Cloud. Por ejemplo, la suite de operaciones de Google Cloud
incluye herramientas para definir y supervisar los SLO y los
porcentajes de error aceptables. Si eliges ejecutar tus aplicaciones
en Google Cloud, esta compatibilidad explícita te ayuda a adoptar la
SRE más fácilmente.
¿Por qué deberías adoptar la SRE? Porque puede mejorar la manera
en que llevas a cabo las operaciones, como el cumplimiento de las
expectativas de confiabilidad de tus clientes y el aumento de la
satisfacción de tu personal en el lugar de trabajo. Esta mejora, a su
vez, conduce a lo que más te importa: clientes más felices.

¿Por qué adoptar la SRE si ya implementaste DevOps?

DevOps es un movimiento cultural y organizacional que tiene como objetivo aumentar la
velocidad de entrega de software, mejorar la confiabilidad del servicio y crear una
responsabilidad compartida entre las partes interesadas de un software. DevOps y la SRE
comparten muchos principios: aumentar la colaboración, aprender de los errores y enfocarse
en la salud del equipo y la satisfacción de los clientes. La SRE proporciona prácticas,
vocabulario y conceptos concretos que complementan aquellos de DevOps.
DevOps y la SRE se refuerzan y potencian mutuamente. Aplica los principios y las prácticas de
cada uno para mejorar el desempeño de manera continua.
 3

Análisis detallado de la SRE

Comprender cómo puede ayudar la SRE a tu organización requiere conocer un
poco más sobre sus ideas. Y también, familiarizarse con la terminología de la
SRE: por ejemplo, la SRE generalmente utiliza el término más general servicio
que aplicación, una convención que utilizaremos de ahora en adelante. Esta
sección echa un vistazo a los aspectos más importantes de la SRE, junto con
una descripción acerca de cómo Google los respalda.

Encontrar un equilibrio entre la confiabilidad y las nuevas funciones

Supongamos que tu organización ha creado un servicio personalizado que es importante para tu

negocio. Si los clientes utilizan este servicio en particular, probablemente querrás seguir mejorándolo,
y agregarle funciones nuevas lo más rápido posible. También querrás asegurarte de que el servicio es
tan confiable como lo necesitan los usuarios.
Allí tienes una tensión inherente. Los desarrolladores están incentivados para agregar funciones
nuevas: quieren agregar cambios en el servicio. Pero el personal operativo suele esforzarse por
minimizar los cambios en el servicio, ya que cada cambio conlleva la posibilidad de un problema que
reduzca la confiabilidad. La Figura 1 ilustra esta situación.

Usuarios

Developers Operaciones

Servicio

Objetivo: Agregar Objetivo: Asegurarse de que el

funciones nuevas lo servicio cumpla con los
más rápido posibles objetivos de confiabilidad

Figura 1: Los desarrolladores quieren agregar funciones nuevas al servicio, pero el personal operativo
quiere mantener su confiabilidad minimizando los cambios

Lo que se necesita es encontrar una manera clara de manejar esta tensión, con objetivos bien definidos
y consensuados por los desarrolladores y el personal operativo. Esto es exactamente lo que
proporcionan los objetivos de nivel de servicio (SLO). Cada SLO define una meta, como un tiempo de
actividad del 99.5%, para un servicio. Fundamentalmente, los SLO están centrados en el usuario: se
basan en aspectos que le interesan al usuario del servicio, como la disponibilidad o la latencia.
 4

Para medir si se está cumpliendo con un SLO, cada uno tiene asociado indicadores de nivel de servicio
(SLI). Y tanto los SLO como los SLI pueden determinar el cumplimiento de un acuerdo de nivel de
servicio (SLA). La Figura 2 ofrece una perspectiva de cómo funcionan en conjunto los SLO, SLI y SLA.

Users

SLA: 99%
Developers Operations

Service

SLO: 99.5%

SLI x SLI y

Figura 2: Cada SLI mide cierto aspecto de un SLO, mientras que un SLA define un acuerdo comercial con los
usuarios de un servicio

Cada SLI define una medida cuantitativa de algún aspecto de lo que

proporciona el servicio. Es importante destacar que los SLI deben definirse
en relación con lo que les importa a los usuarios del servicio. Por ejemplo, el
"SLI x" de la Figura 2 podría medir el porcentaje de solicitudes de usuario que
arrojan una respuesta correcta en 500 milisegundos, mientras que el "SLI y"
podría medir el porcentaje de intentos exitosos de inicio de sesión válidos.
Definir un SLI basado únicamente en una métrica interna, como el uso de
CPU, no es el mejor enfoque.
Si bien tienen un nombre similar, los SLA son bastante distintos a los SLO y
SLI. Un SLA es un acuerdo comercial con los usuarios de tu servicio, que
generalmente ocasiona una sanción monetaria en caso de incumplimiento.
Los SLA son externos y visibles para los usuarios del servicio, mientras que
los SLO y SLI se utilizan dentro de tu organización de TI.
Debes definir SLO que sean más rigurosos que el SLA de tu servicio. Por
ejemplo, en el contexto utilizado en la Figura 2, el SLO es del 99.5%, mientras
que el SLA es solo del 99%. Esto permite que el SLO actúe como una alerta
temprana. No cumplir con un SLO probablemente signifique que existe el
riesgo de no cumplir con tu SLA, un evento más complicado (y público) que
le cuesta dinero a tu empresa.
 5

Los SLO y porcentajes de error aceptables

Los SLO proporcionan un medio para que los desarrolladores y el personal operativo acuerden el
objetivo de confiabilidad de un servicio. El porcentaje de SLO también define un acuerdo más preciso:
determina la cantidad de minutos que una aplicación puede estar inactiva. Por ejemplo, un SLO de
disponibilidad del 99.5% implica que el servicio puede no estar disponible durante el 0.5% de cada mes,
lo que equivale a unas 3 horas y 40 minutos. Este tiempo de inactividad permitido es el porcentaje de
error aceptable del servicio. Acordar un SLO también implica ponerse de acuerdo sobre una cantidad
precisa de tiempo en que el servicio puede fallar para cumplir ese SLO.
El porcentaje de error aceptable de un servicio proporciona una manera concreta de equilibrar los
incentivos de los desarrolladores y del personal operativo y, al mismo tiempo, mantener el enfoque
sobre las necesidades de los usuarios del servicio. Debido a que cada lanzamiento de una función
nueva pone en riesgo la confiabilidad del servicio, los desarrolladores pueden seguir agregando
funciones nuevas siempre que el servicio se mantenga dentro del porcentaje de error aceptable, es
decir, siempre que el servicio continúe cumpliendo con su SLO. Sin embargo, debido a que los errores
en las funciones recientemente lanzadas provocan un tiempo de inactividad que reduce el porcentaje
de error aceptable, el lanzamiento de estas funciones puede ralentizarse o incluso detenerse por
completo. Por ejemplo, una organización que normalmente realiza implementaciones de funciones
nuevas dos veces al día podría cambiar a una única implementación diaria cuando se agote la mitad del
porcentaje de error aceptable de un mes. Luego, podría pasar a implementaciones una vez por semana
cuando se utilicen las tres cuartas partes del porcentaje de error aceptable, y así llegar a detener la
implementación por completo durante el mes cuando el porcentaje de error aceptable sea nulo. Este
proceso se autorregula: cuando el porcentaje de error aceptable expira, los desarrolladores no pueden
lanzar más funciones a menos que trabajen con el personal operativo.

Otras cuestiones que vale la pena conocer sobre los SLO y los porcentajes de error
aceptables:
• Debido a que los SLO se basan en aspectos que les interesan a los usuarios del
servicio, la elección de los valores de SLO es básicamente una decisión comercial.
En otras palabras, el propietario de un servicio debe determinar el nivel de
confiabilidad que mejor se adapte a sus requisitos comerciales. Esto significa que
los SLO no son solo una medida tecnológica. También proporcionan un lenguaje
común para que el propietario de un servicio, sus desarrolladores y personal
operativo consideren y acuerden las necesidades de confiabilidad del servicio.
• Incluso si los líderes de tu organización desean alcanzar una confiabilidad del
100%, no esperes que este objetivo sea posible. Independientemente de tu
servicio, este depende de otros servicios, y ya que ninguno de ellos brinda una
confiabilidad perfecta, tú tampoco puedes hacerlo. De igual importancia,
aumentar la confiabilidad implica gastar cantidades cada vez mayores de dinero.
El mejor SLO para un servicio equilibra la confiabilidad y los costos.
• El uso de SLO y porcentajes de error aceptables requiere la aceptación de los
líderes. Por ejemplo, si un equipo de desarrolladores agota el porcentaje de error
aceptable del mes, el personal operativo debe contar con la autoridad necesaria
para frenar nuevas implementaciones en pos de garantizar la confiabilidad. La
única forma de obtener esta autoridad en la mayoría de las organizaciones es
logrando que los líderes respalden primero el enfoque de la SRE.
Los SLO y porcentajes de error aceptables definidos le permiten a tu organización
pensar claramente acerca del nivel de confiabilidad (y, por lo tanto, de riesgo) que es
adecuado para un servicio y sus usuarios. Es decir, son una parte fundamental de la SRE.
 68

Los principios y las prácticas de la SRE pueden mejorar tanto la velocidad como la
confiabilidad de las nuevas funciones
En ocasiones, suele haber cierta compensación entre el lanzamiento rápido de nuevas
funciones y el mantenimiento de la confiabilidad. El uso de SLO, SLI y porcentajes de error
aceptables puede ayudarte a administrar esta compensación de manera eficaz.
Sin embargo, el informe Estado de DevOps de DevOps Research and Assessment (DORA)
indica que esto no siempre es así. Según DORA, «Nuestra investigación ha demostrado
consistentemente que la velocidad y la estabilidad son resultados que se potencian
mutuamente». En otras palabras, estas se pueden mejorar al mismo tiempo.
Una razón importante para esto es que la necesidad de trabajar en conjunto en los SLO le
brinda al equipo operativo la oportunidad de ponerse de acuerdo con los desarrolladores al
principio del diseño de un nuevo servicio. Esto convierte a la SRE en una parte del proceso de
desarrollo, y ayuda a los desarrolladores y el personal operativo a colaborar de manera más
eficaz.
Por otra parte, gestionar el equilibro entre la velocidad y la confiabilidad es una parte
importante de la SRE. Sorprendentemente, podrás avanzar rápido sin dañar nada.
 7

Uso de SLO con Google Cloud

Google Cloud Monitoring ofrece

funcionalidades integradas para crear y
utilizar SLO, SLI y porcentajes de error
aceptables con servicios que se ejecutan
en Google Cloud. Cloud Monitoring es
parte de la suite operativa de Google
Cloud, que también incluye Cloud
Logging, Cloud Tracing y más.
Con Cloud Monitoring, puedes definir los
SLO de tu servicio. Para hacerlo, primero
tienes que establecer el SLI del que
dependerá el SLO. Este SLI se puede basar
en diferentes métricas, como la
disponibilidad del servicio, la rapidez con
que responde a los usuarios, la
información de registros, como las tasas
de errores, y más.
Una vez que hayas definido tu SLI, podrás
crear un SLO que lo utilice. La Figura 3
muestra un ejemplo de cómo aplicarlo.
Este ejemplo establece un SLO del 99.5%,
lo que indica que esta cifra debe medirse
durante el transcurso del mes. Una vez
definido, Cloud Monitoring calculará Figura 3: Puedes definir un SLO para un servicio con Cloud
Monitoring
automáticamente el porcentaje de error
aceptable que implica el SLO. También
puedes usar Cloud Monitoring para
verificar el estado de tu SLO, como
muestra la Figura 4. En este ejemplo, se
cumple con el SLO, y queda todavía un
4% restante del porcentaje de error
aceptable.
Como muestran estos ejemplos, la
capacidad de observar los SLO, SLI y los
porcentajes de error aceptables está
integrada en Cloud Monitoring: no ha sido
añadida después. Google Cloud
proporciona observabilidad en contexto, y Figura 4: O Cloud Monitoring exibe o status do SLO,
así brinda información donde la necesitas. que inclui a porcentagem do orçamento de erros
restante
 8

Reducir el trabajo pesado

La palabra «toil» (o trabajo pesado) tiene un significado
especial en términos de SRE. No se refiere a todo lo que el
personal operativo pueda no disfrutar de hacer, como asistir a
las reuniones de equipo, sino que hace referencia a tipos de
trabajo específicos que son necesarios para ejecutar tu
servicio. El trabajo que se califica como «trabajo pesado» es
aquel que es manual, repetitivo y, generalmente,
automatizable. Es más: es aquel trabajo que no proporciona
ningún valor duradero.
Este trabajo pesado es una carga para tu organización. La
mayoría de las personas no lo disfrutan, por lo que exigir
mucho trabajo pesado puede dificultar la retención del
personal operativo. Considera también que este trabajo no
representa el mejor uso del tiempo del personal. Si una tarea
se puede automatizar, ¿por qué no hacerlo? Esto permitiría
que el personal operativo dedique su tiempo a tareas de
mayor valor.

Identificar el trabajo pesado

Reconocer el trabajo pesado puede ser algo difícil;
probablemente, no sepas cuál es el que estás realizando hoy.
Para hacer esta idea más concreta, supongamos que tu
personal operativo debe reiniciar manualmente un servicio
cada semana porque saben que fallará si se ejecuta por más
tiempo. Este es un ejemplo de trabajo pesado: aquel que es
manual y repetitivo.
Desde la perspectiva de la SRE, la reducción de este tipo de
trabajo puede darse de diversas maneras. El equipo de
operaciones podría escribir primero un script que reinicie el
servicio y luego configurar este script para que se ejecute
automáticamente cada semana. Ahora hay un menor trabajo
manual repetitivo, de modo que el trabajo pesado se reduce.
Un enfoque más avanzado implicaría que el equipo operativo
utilice las herramientas de observabilidad, como Cloud
Monitoring, Cloud Logging y Cloud Tracing, para comprender
por qué falla el servicio si no se reinicia semanalmente. Para
realizar este procedimiento, es necesario contar con cierto
conocimiento del servicio en sí, algo que la SRE alienta a que
tenga el personal operativo. Un enfoque aún más avanzado
sería que el personal operativo no solo determine por qué
falla el servicio, sino que también encuentre y resuelva el
problema en el código del servicio. Cualquiera sea el enfoque
que se elija, la SRE potencia al personal operativo a hacer que
el futuro sea mejor que el presente al reducir el trabajo
pesado mediante la automatización.
 19
1

¿El personal de operaciones debería también convertirse en personal de desarrollo?

La distinción tradicional entre desarrolladores y personal operativo está desapareciendo. Un
ejemplo de esto es el paso de la infraestructura al código, donde el personal operativo
configura mediante programación su entorno informático.
La SRE representa otro paso hacia esa dirección. Recuerda que la E en SRE significa
ingeniería, lo que implica que las habilidades de ingeniería de software son parte de lo que se
necesita. De hecho, adoptar la SRE ayuda a poner a las operaciones en igualdad de
condiciones con los desarrolladores.
Adoptar la SRE no implica que debas contratar un conjunto completamente nuevo de
personal operativo. Pero hacer un buen uso de la SRE, que incluye la eliminación del trabajo
pesado, significa ayudar a tu personal a crecer. Un ejemplo importante de esto es garantizar
que al menos parte de tu personal operativo tenga el conocimiento necesario para crear y
mantener soluciones automatizadas.

Reducir el trabajo pesado con Google Cloud

Google Cloud está diseñado para respaldar la SRE, incluida la reducción del
trabajo pesado. Aquí tienes dos ejemplos importantes:
• Google Cloud admite ampliamente la automatización y la
infraestructura como código. Todos sus servicios exponen API que te
permiten controlar tu entorno de manera programática. Si bien puedes
utilizar nuestra herramienta gcloud de línea de comandos o IU Console
para crear y administrar los recursos de Google Cloud de manera
interactiva, todo lo que permite esta herramienta también se puede
hacer mediante llamadas de API. Este enfoque hace posible escribir
código que automatiza el trabajo pesado siempre que sea posible.
• La suite de operaciones de Google Cloud brinda maneras sencillas de
comprender lo que sucede con los servicios. Cloud Tracing, por
ejemplo, le brinda al personal operativo una visión clara de todo lo que
sucede a medida que las solicitudes pasan por tus servicios, mientras
que Cloud Logging permite un examen detallado de lo que hace un
servicio. Y junto con la compatibilidad con SLO mencionada
anteriormente, Cloud Monitoring ofrece diversas maneras de
comprender lo que sucede. Por ejemplo, puedes usar el lenguaje de
consulta de Monitoring para examinar una variedad de datos de series
temporales sobre un servicio en ejecución.
 10

Otros aspectos de la SRE

La SRE es un conjunto de enfoques que se utiliza para ejecutar sistemas

de producción de manera más eficaz. Entre ellos, se incluye el uso de los
SLO para equilibrar el lanzamiento de nuevas funciones con la
confiabilidad y la reducción del trabajo pesado por medio de la
automatización. Hay varios aspectos de la SRE que también son
importantes, entre ellos:
• La creación de un proceso eficaz de administración de
incidentes. Esto puede incluir la definición de una separación
clara de responsabilidades, con una persona a cargo de los
incidentes que asigne roles a las personas involucradas. Esta
persona también está a cargo de mantener un documento
actualizado sobre el estado de los incidentes que rastree el
proceso de su resolución. Contar con esta estructura predefinida
en funcionamiento y luego activarla cuando ocurra un accidente
es un enfoque poderoso para encontrar y solucionar problemas.
• La realización de procesos post mortem sin culpables. La
perfección es imposible, ya que siempre habrá problemas. Luego
de que se resuelva un incidente, es fundamental realizar un
proceso post mortem para documentar con exactitud cuál fue el
problema y cómo se puede evitar en el futuro. También es
fundamental que estos post mortem eviten atribuir culpas. El
objetivo es eliminar las acusaciones, que solo incentivan a las
personas a cubrir los errores. Crear una cultura de procesos post
mortem libres de culpa ayuda a que todas las personas vean la
falla como una oportunidad para mejorar en lugar de una
amenaza para la seguridad de su trabajo.
• Una planificación exitosa de la capacidad. Hay varias maneras de
hacerlo en relación con los servicios basados en la nube. Si
quieres comprender y predecir tus costos, por ejemplo, puedes
crear un mapa que contenga desde las interacciones con los
usuarios hasta los recursos requeridos y los costos esperados.
Esto te permitirá determinar el costo de agregar, digamos, mil
usuarios nuevos por mes. Sea cual sea tu situación, hacer una
planificación exitosa de la capacidad es fundamental para
ejecutar bien los servicios.
Esta no es una lista exhaustiva, ya que la SRE incluye mucho más, pero
puedes darte una idea de las diversas maneras en que la SRE puede
mejorar tus operaciones de TI.
 11

Adoptar la SRE
Al igual que con cualquier cambio organizacional, la adopción de prácticas de SRE implica cambiar partes de tu
cultura. La SRE se define por un conjunto de principios y preceptos del comportamiento, de modo que lidiarás con
personas y procesos, no con herramientas.
Debido a que la SRE se compone en gran parte de un conjunto de prácticas independientes, puedes comenzar
por donde lo consideres más necesario. Por ejemplo, la mayoría de los grupos operativos de TI sufren el trabajo
pesado en cantidad, de modo que su identificación y reducción suelen ser un buen punto de partida. Si
administras servicios que necesitan equilibrar la velocidad de lanzamiento de nuevas funciones y la confiabilidad,
también tiene sentido adoptar los SLO y los porcentajes de error aceptables. Darle valor a las operaciones desde
un principio aporta valor real. Se pueden agregar otros aspectos de la SRE, como los procesos post mortem y la
planificación de la capacidad, siempre que tengan sentido para ti. Dado que la SRE fomenta la mejora continua,
espera iterar en estos cambios a medida que adquieras más experiencia.

No importa cuál sea tu recorrido de SRE, tendrás que invertir en

tu personal operativo: la capacitación es clave para el éxito. Lo
que deba aprender tu personal dependerá de sus habilidades
actuales y los aspectos de la SRE que adoptes. Por ejemplo,
utilizar SLO y porcentajes de error aceptables de manera exitosa
requiere de la creación de relaciones sólidas entre el personal de
operaciones y de desarrollo. Para lograrlo, puedes dejar que
representantes de los dos grupos se reúnan para encontrar y
resolver errores en algún servicio. Si tu mayor prioridad es la
automatización para reducir el trabajo pesado, puedes
concentrarte en capacitar al personal operativo sobre
herramientas y técnicas de desarrollo. Para obtener más detalles
sobre las capacitaciones de SRE, consulta Training Site Reliability
Engineers: What Your Organization Needs to Create a Learning
Program.
Adoptar la SRE también implica mitigar los desafíos que conlleva
este cambio. Como se mencionó anteriormente, por ejemplo,
tener éxito con los SLO y los porcentajes de error aceptables
requiere la aceptación de los líderes de TI. Sin ella, es probable
que el personal de operaciones no pueda ralentizar la
implementación de una función nueva a medida que se reduce el
porcentaje de error aceptable. Para aquellas organizaciones
centradas principalmente en reducir los costos de TI, necesitarás
dejar en claro cómo la adopción de la SRE puede lograrlo con el
tiempo. Un enfoque sería mostrar el ahorro de costos inmediato
al eliminar el trabajo pesado mediante la automatización.
Adoptar la SRE puede mejorar de forma significativa la manera en
la que realizas operaciones de TI. Sin embargo, es fundamental
saber que si bien los principios son comunes, las organizaciones
se mueven hacia la SRE de maneras diferentes. Antes de
comenzar, piensa bien tus objetivos y dónde quieres empezar.
 112
4

Cómo Google puede ayudar

Google Professional Services Organization (PSO) ofrece servicios de consultoría pagos para
ayudar a organizaciones como la tuya a adoptar la SRE. Estos pueden variar desde un
compromiso de seis semanas a una relación de varios años destinada a la transformación
organizacional. Google PSO es una combinación de personas con experiencia interna en
Google SRE y experiencia por fuera de Google con empresas y startups, lo que nos permite
capturar nuevos aprendizajes y el conocimiento de nuestros clientes.
No importa cuál sea tu objetivo de SRE: nosotros podemos ayudarte. Es posible que desees
mejorar solo un aspecto, como la planificación de la capacidad o la definición de SLO para
uno de tus servicios. También, es posible que desees reestructurar la organización de tus
operaciones, en todo o en parte, en torno a la SRE. No importa cuáles sean tus necesidades,
nuestro objetivo es enseñarte los principios fundamentales de la SRE, y así ayudarte a tener
éxito una vez que finalice la interacción.

«Las herramientas y la metodología de Google

han jugado un papel fundamental para ayudar
a redefinir nuestras prácticas de SRE y brindar
un mejor servicio a nuestros clientes... Con
estos esfuerzos, hemos podido acelerar 300
veces los lanzamientos: pasamos de uno cada
Para más información, visita
dos semanas a más de 20 lanzamientos How Lowe's leverages Google
diarios». SRE practices.
Para contactar con Google PSO,
Vivek Balivada haz clic aquí.
Director, Digital SRE & Ops, Lowe's Companies, Inc. Para más información sobre las
ofertas de Google Cloud para la
Rahul Mohan
SRE, visita el sitio web de
Kola Kandy, Sr. Manager, Digital SRE, Lowe's Companies, Inc. Google Cloud SRE.
 13

Próximos pasos
La SRE no se trata solo de SLO y otras herramientas.
Comienza con una mentalidad, una manera de
pensar cómo llevar adelante las operaciones.
Adoptar esta mentalidad implica invertir en tu
personal operativo, lo que impulsa un cambio
cultural que te permitirá tener éxito con este nuevo
enfoque.
Al fin y al cabo, la SRE se refiere en esencia a la
realización de cambios incrementales que
gradualmente mejoran la vida de tu personal
operativo, los desarrolladores y los usuarios de tus
servicios. No lo dudes: comienza hoy mismo.

Más información
What is Site Reliability Engineering (SRE)?
The SRE Book: Site Reliability Engineering: How Google Runs
Production Systems
Creating SLOs with Google Cloud Monitoring
Training Site Reliability Engineers: What Your Organization
Needs to Create a Learning Program
SRE at Google: Our complete list of Customer Reliability
Engineering (CRE) life lessons
Suite de operaciones de Google Cloud