La clase SRE implementa la interfaz DevOps

Por Niall Richard Murphy, Liz Fong-Jones y Betsy Beyer, con Todd Underwood, Laura Nolan y Dave Rensin

Las operaciones, como disciplina, son difíciles¹⁾. No sólo está la cuestión, en general sin resolver, de cómo gestionar bien los sistemas, sino que las mejores prácticas que se ha comprobado que funcionan dependen en gran medida del contexto y están lejos de ser ampliamente adoptadas. También está la cuestión, en gran medida sin resolver, de cómo dirigir bien los equipos de operaciones. Se suele pensar que el análisis detallado de estos temas tiene su origen en la Investigación Operativa dedicada a mejorar los procesos y el rendimiento en el ejército aliado durante la Segunda Guerra Mundial, pero en realidad llevamos milenios pensando en cómo hacer funcionar mejor las cosas.

Sin embargo, a pesar de todos estos esfuerzos y reflexiones, las operaciones de producción fiables siguen siendo difíciles de alcanzar, especialmente en los ámbitos de la tecnología de la información y la operabilidad del software. El mundo empresarial, por ejemplo, suele tratar las operaciones como un centro de costos²⁾ lo que dificulta, si no imposibilita, mejoras significativas en los resultados. La tremenda miopía de este enfoque aún no se comprende ampliamente, pero la insatisfacción con él ha dado lugar a una revolución en la forma de organizar lo que hacemos en TI.

Esa revolución surgió al intentar resolver una serie de problemas comunes. Las soluciones más recientes a estos problemas reciben dos nombres distintos: DevOps y Site Reliability Engineering (SRE). Aunque hablamos de ellos individualmente como si fueran reacciones totalmente separadas a la mentalidad empresarial que acabamos de describir ³⁾, esperamos convencerle de que, de hecho, son mucho más parecidos, y los profesionales de cada uno tienen mucho más en común, de lo que podría suponer.

Pero primero, algunos antecedentes sobre los principios clave de cada una.

DevOps es un conjunto flexible de prácticas, directrices y cultura diseñadas para acabar con los compartimentos estancos en el desarrollo, las operaciones, las redes y la seguridad de TI. Articulado por John Willis, Damon Edwards y Jez Humble, CA(L)MS -que significa Cultura, Automatización, Lean (como en Lean management; véase también entrega continua), Medición y Compartición- es un acrónimo útil para recordar los puntos clave de la filosofía DevOps. El intercambio y la colaboración están a la vanguardia de este movimiento. En un enfoque DevOps, se mejora algo (a menudo automatizándolo), se miden los resultados y se comparten con los colegas para que toda la organización pueda mejorar. Todos los principios CALMS son facilitados por una cultura de apoyo.

DevOps, Agile, y una variedad de otros negocios y técnicas de reingeniería de software son todos ejemplos de una visión general del mundo sobre la mejor manera de hacer negocios en el mundo moderno. Ninguno de los elementos de la filosofía DevOps son fácilmente separables entre sí, y esto es esencialmente por diseño. Sin embargo, hay algunas ideas clave que pueden discutirse de forma relativamente aislada.

La primera idea clave es no más silos. Es una reacción a un par de ideas:

• La disposición históricamente popular, pero ahora cada vez más anticuada, de equipos de operaciones y desarrollo separados.

• El hecho de que la siloización extrema del conocimiento, los incentivos para la optimización puramente local y la falta de colaboración han sido en muchos casos activamente malos para el negocio⁴⁾

La segunda idea clave es que los accidentes no son sólo el resultado de las acciones aisladas de un individuo, sino más bien el resultado de la falta de salvaguardias para cuando las cosas inevitablemente van mal ⁵⁾. Por ejemplo, una mala interfaz fomenta inadvertidamente la acción equivocada bajo presión; una característica errónea del sistema hace inevitable el fracaso si se dan las circunstancias equivocadas (no articuladas); una supervisión defectuosa hace imposible saber si algo va mal, por no decir qué va mal. Algunas empresas de mentalidad más tradicional poseen el instinto cultural de erradicar al autor del error y castigarlo. Pero hacerlo tiene sus propias consecuencias: la más obvia es que crea incentivos para confundir los problemas, ocultar la verdad y culpar a otros, todo lo cual, en última instancia, son distracciones poco rentables. Por lo tanto, es más rentable centrarse en acelerar la recuperación que en prevenir los accidentes.

La tercera idea clave es que el cambio es mejor cuando es pequeño y frecuente. En entornos en los que los comités de cambio se reúnen mensualmente para debatir planes minuciosamente documentados para realizar cambios en la configuración del mainframe, ésta es una idea radical. Sin embargo, no es una idea nueva. La noción de que todos los cambios deben ser considerados por humanos experimentados y agrupados por lotes para una consideración eficiente resulta ser más o menos lo contrario de las mejores prácticas. El cambio es arriesgado, es cierto, pero la respuesta correcta es dividir los cambios en subcomponentes más pequeños siempre que sea posible. Esta estrategia, unida a la comprobación automática de los cambios más pequeños y a la reversión fiable de los cambios erróneos, da lugar a enfoques de la gestión del cambio como la integración continua (IC) y la entrega o despliegue continuos (CD).

Las herramientas son un componente importante de DevOps, sobre todo si se tiene en cuenta la importancia de gestionar correctamente el cambio: hoy en día, la gestión del cambio se basa en herramientas muy específicas. Sin embargo, en general, los defensores de DevOps hacen especial hincapié en la cultura organizativa -más que en las herramientas- como clave del éxito a la hora de adoptar una nueva forma de trabajar. Una buena cultura puede funcionar con herramientas defectuosas, pero lo contrario rara vez es cierto. Como dice el refrán, la cultura se come a la estrategia para desayunar. Al igual que las operaciones, el cambio en sí es difícil.

Por último, la medición es especialmente crucial en el contexto empresarial general de, por ejemplo, la ruptura de silos y la resolución de incidentes. En cada uno de estos entornos, se establece la realidad de lo que está ocurriendo mediante una medición objetiva, se verifica que se está cambiando la situación como se esperaba y se crea una base objetiva para las conversaciones sobre la que las distintas funciones están de acuerdo. (Esto se aplica tanto en contextos empresariales como en otros, como las guardias).

Site Reliability Engineering (SRE) es un término (y una función laboral asociada) acuñado por Ben Treynor Sloss, vicepresidente de ingeniería de Google.⁶⁾ Como podemos ver en la sección anterior, DevOps es un amplio conjunto de principios sobre la colaboración durante todo el ciclo de vida entre las operaciones y el desarrollo de productos. SRE es un puesto de trabajo, un conjunto de prácticas (descritas a continuación) que hemos comprobado que funcionan, y algunas creencias que animan esas prácticas. Si se piensa en DevOps como una filosofía y un enfoque de trabajo, se puede argumentar que SRE implementa parte de la filosofía que describe DevOps, y es algo más cercano a una definición concreta de un trabajo o función que, por ejemplo, “ingeniero DevOps”.⁷⁾ Así que, en cierto modo, la clase SRE implementa la interfaz DevOps.

A diferencia del movimiento DevOps, que se originó a partir de la colaboración entre líderes y profesionales de varias empresas, la SRE de Google heredó gran parte de su cultura de la empresa que la rodeaba antes de que el término SRE se popularizara en todo el sector. Dada esa trayectoria, la disciplina en su conjunto no destaca actualmente el cambio cultural por defecto tanto como DevOps. (Eso no implica nada sobre si el cambio cultural es necesario para hacer SRE en una organización arbitraria, por supuesto).

La SRE se define por los siguientes principios concretos.

El principio básico de la SRE es que hacer bien las operaciones es un problema de software. Por lo tanto, la SRE debe utilizar enfoques de ingeniería de software para resolver ese problema. Esto abarca un amplio campo de visión, desde el cambio de procesos y negocios hasta problemas de software igualmente complicados pero más tradicionales, como la reescritura de una pila para eliminar los puntos únicos de fallo en la lógica empresarial.

La SRE no intenta dar a todo una disponibilidad del 100%. Como se explica en nuestro primer libro, Site Reliability Engineering, éste es un objetivo erróneo por varias razones. En su lugar, el equipo de producto y el equipo de SRE seleccionan un objetivo de disponibilidad apropiado para el servicio y su base de usuarios, y el servicio se gestiona de acuerdo con ese SLO.⁸⁾ Decidir este objetivo requiere una fuerte colaboración por parte del negocio. Los SLO también tienen implicaciones culturales: como decisiones en colaboración entre las partes interesadas, las violaciones de los SLO devuelven a los equipos a la mesa de dibujo, sin culpa.

Para la SRE, cualquier tarea operativa manual y estructuralmente obligatoria es aborrecible. (Eso no significa que no tengamos operaciones de este tipo: tenemos muchas. Sólo que no nos gustan). Creemos que si una máquina puede realizar una operación deseada, a menudo debería hacerlo. Esta es una distinción (y un valor) que no se ve a menudo en otras organizaciones, donde el trabajo pesado es el trabajo, y para eso se paga a una persona. Para SRE en el contexto de Google, el trabajo pesado no es el trabajo, no puede serlo. Todo el tiempo dedicado a tareas operativas significa tiempo no dedicado al trabajo del proyecto, y el trabajo del proyecto es la forma en que hacemos que nuestros servicios sean más fiables y escalables.

Sin embargo, la realización de tareas operativas, gracias a “la sabiduría de la producción”, proporciona información vital para la toma de decisiones. Este trabajo nos mantiene con los pies en la tierra al proporcionar información en tiempo real de un sistema determinado. Hay que identificar las fuentes de trabajo para poder minimizarlas o eliminarlas. Sin embargo, si se encuentra en una situación de infracarga operativa, es posible que tenga que impulsar nuevas funciones y cambios más a menudo para que los ingenieros sigan familiarizados con el funcionamiento del servicio al que da soporte.

El verdadero trabajo en esta área es determinar qué automatizar, en qué condiciones y cómo automatizarlo.

La SRE, tal y como se practica en Google, tiene un límite estricto en cuanto al tiempo que un miembro del equipo puede dedicar al trabajo duro, en contraposición a la ingeniería que produce valor duradero: el 50%. Mucha gente piensa que este límite es un tope. En realidad, es mucho más útil considerarlo una garantía: una declaración explícita y un mecanismo que permite adoptar un enfoque de los problemas basado en la ingeniería en lugar de dedicarse a ellos una y otra vez.

Hay una interacción poco intuitiva e interesante entre este punto de referencia y cómo se desarrolla cuando pensamos en la automatización y el trabajo pesado. Con el tiempo, un equipo de SRE acaba automatizando todo lo que puede para un servicio, dejando atrás las cosas que no se pueden automatizar (el efecto Murphy-Beyer). En igualdad de condiciones, esto llega a dominar lo que hace un equipo de SRE, a menos que se tomen otras medidas. En el entorno de Google, se tiende a añadir más servicios, hasta un cierto límite que sigue soportando el 50% del tiempo de ingeniería, o se tiene tanto éxito en la automatización que se puede ir y hacer otra cosa completamente diferente en su lugar.

Las fronteras rígidas entre “desarrollo de aplicaciones” y “producción” (a veces denominados programadores y operadores) son contraproducentes. Esto es especialmente cierto si la segregación de responsabilidades y la clasificación de los operarios como centro de costes provoca desequilibrios de poder o discrepancias en la estima o la retribución.

Los SRE tienden a centrarse en los problemas de producción más que en los de lógica empresarial, pero como su enfoque aporta herramientas de ingeniería de software al problema, comparten conjuntos de habilidades con los equipos de desarrollo de productos. En general, un SRE tiene una experiencia particular en torno a la disponibilidad, latencia, rendimiento, eficiencia, gestión del cambio, supervisión, respuesta de emergencia y planificación de la capacidad del servicio o servicios de los que se ocupa. Estas competencias específicas (y normalmente bien definidas) son el pan de cada día de lo que la SRE hace por un producto y por el equipo de desarrollo de producto asociado.⁹⁾ Idealmente, tanto el equipo de desarrollo de producto como el de SRE deberían tener una visión holística de la pila -el frontend, el backend, las bibliotecas, el almacenamiento, los kernels y la máquina física- y ningún equipo debería poseer celosamente componentes individuales. Resulta que se puede hacer mucho más si se “difuminan las líneas ”¹⁰⁾ y los SRE instrumentan JavaScript, o los desarrolladores de producto cualifican los kernels: el conocimiento de cómo hacer cambios y la autoridad para hacerlo están mucho más extendidos, y se eliminan los incentivos para proteger celosamente cualquier función en particular.

En Site Reliability Engineering, no dejamos suficientemente claro que los equipos de desarrollo de productos de Google son propietarios de sus servicios por defecto. La SRE no está disponible ni garantizada para el grueso de los servicios, aunque los principios de la SRE siguen informando de cómo se gestionan los servicios en todo Google.¹¹⁾ El modelo de propiedad cuando un equipo de SRE trabaja con un equipo de desarrollo de productos es también, en última instancia, un modelo compartido.

Las herramientas son un determinante increíblemente importante del comportamiento, y sería ingenuo suponer que la eficacia de la SRE en el contexto de Google no tiene nada que ver con la base de código unificada y ampliamente accesible, la amplia gama de herramientas de software y sistemas, la pila de producción altamente optimizada y propietaria, etcétera. Sin embargo, compartimos este supuesto absoluto con DevOps: los equipos que gestionan un servicio¹²⁾ deben utilizar las mismas herramientas, independientemente de su función en la organización. No hay una buena forma de gestionar un servicio que tenga una herramienta para los SRE y otra para los desarrolladores de productos, que se comportan de forma diferente (y potencialmente catastrófica) en situaciones distintas. Cuantas más divergencias haya, menos se beneficiará la empresa de cada esfuerzo por mejorar cada herramienta individual.

Si examinamos los principios anteriores, observamos de inmediato bastantes puntos en común:

• Tanto DevOps como SRE dependen de la aceptación de que el cambio es necesario para mejorar. Sin eso, no hay mucho margen de maniobra.¹³⁾

• La colaboración es fundamental para el trabajo de DevOps. Para que la SRE funcione, es necesario un modelo eficaz de propiedad compartida y relaciones entre equipos asociados. Al igual que DevOps, SRE también tiene fuertes valores compartidos en toda la organización, lo que puede hacer que salir de los silos basados en equipos sea un poco más fácil.

• La mejor forma de gestionar los cambios es mediante acciones pequeñas y continuas, la mayoría de las cuales, idealmente, se prueban y aplican de forma automática. La interacción crítica entre el cambio y la fiabilidad hace que esto sea especialmente importante para la SRE.

• La herramienta adecuada es de vital importancia, y la herramienta determina en cierta medida el alcance de sus actos. Sin embargo, no debemos centrarnos demasiado en si algo se consigue utilizando algún conjunto específico de herramientas; al fin y al cabo, la orientación API para la gestión de sistemas es una filosofía más importante que sobrevivirá a cualquier implementación concreta de la misma.

• La medición es absolutamente clave para el funcionamiento tanto de DevOps como de SRE. En el caso de la SRE, las SLO son fundamentales para determinar las medidas adoptadas para mejorar el servicio. Por supuesto, no puede haber SLO sin medición (así como debate entre equipos, idealmente entre producto, infraestructura/SRE y la empresa). En el caso de DevOps, el acto de medir se utiliza a menudo para comprender cuáles son los resultados de un proceso, cuál es la duración de los bucles de retroalimentación, etcétera. Tanto DevOps como SRE están orientados a los datos, ya sean profesiones o filosofías.

• La cruda realidad de la gestión de servicios de producción significa que de vez en cuando ocurren cosas malas, y hay que hablar del porqué. Tanto SRE como DevOps practican autopsias libres de culpa para contrarrestar reacciones inútiles y cargadas de adrenalina.

• En última instancia, implantar DevOps o SRE es un acto holístico; ambos esperan mejorar el conjunto del equipo (o unidad, u organización), en función del trabajo conjunto de una forma muy específica. Tanto para DevOps como para SRE, el resultado debería ser una mayor velocidad.¹⁴⁾

Como puede ver, hay muchos puntos en común entre DevOps y SRE.

Sin embargo, también existen diferencias significativas. DevOps es, en cierto sentido, una filosofía y una cultura más amplias. Dado que efectúa cambios más amplios que SRE, DevOps es más sensible al contexto. DevOps es relativamente silencioso sobre cómo ejecutar operaciones a un nivel detallado. Por ejemplo, no es prescriptivo en cuanto a la gestión precisa de los servicios. En su lugar, opta por concentrarse en derribar barreras en la organización en general. Esto tiene mucho valor.

La SRE, por su parte, tiene responsabilidades relativamente limitadas y su cometido suele estar más orientado a los servicios (y a los usuarios finales) que a la empresa en su conjunto. En consecuencia, aporta un marco intelectual de opinión (que incluye conceptos como los presupuestos de errores) al problema de cómo hacer funcionar los sistemas de forma eficaz. Aunque la SRE, como profesión, es muy consciente de los incentivos y sus efectos, a su vez es relativamente silenciosa en temas como la siloización y las barreras de información. Apoyaría la CI y el CD no necesariamente por el argumento comercial, sino por la mejora de las prácticas operativas que implican. O, dicho de otro modo, la SRE cree en las mismas cosas que DevOps, pero por razones ligeramente diferentes.

DevOps y SRE tienen un gran solapamiento conceptual en su funcionamiento. Como era de esperar, también tienen un conjunto similar de condiciones que tienen que darse dentro de la organización para que a) sean implementables en primer lugar, y b) obtengan el máximo beneficio de esa implementación. Como casi dijo Tolstoi, pero nunca llegó a decir, los enfoques operativos eficaces son todos iguales, mientras que los enfoques deficientes son todos deficientes a su manera. Los incentivos pueden explicar en parte por qué es así.

Si la cultura de una organización valora los beneficios de un enfoque DevOps y está dispuesta a asumir esos costos -típicamente expresados como dificultades en la contratación, la energía necesaria para mantener la fluidez en los equipos y las responsabilidades, y el aumento de los recursos financieros dedicados a compensar un conjunto de habilidades que es necesariamente más raro- entonces esa organización también debe asegurarse de que los incentivos son correctos para lograr el beneficio completo de este enfoque.

En concreto, lo siguiente debería ser cierto tanto en el contexto de DevOps como de SRE.

Muchas empresas definen accidentalmente incentivos formales que socavan el rendimiento colectivo. Para evitar este error, no estructure los incentivos de forma que estén estrechamente ligados a resultados relacionados con el lanzamiento o la fiabilidad. Como cualquier economista puede decirle, si hay una medida numérica, la gente encontrará una manera de jugar con ella para obtener un mal efecto, a veces incluso de una manera totalmente bien intencionada.¹⁵⁾ En su lugar, debe permitir a su gente la libertad de encontrar las compensaciones adecuadas. Como se ha comentado anteriormente, DevOps o SRE pueden actuar como aceleradores para su equipo de producto en general, permitiendo al resto del software organizacional enviar características a los clientes de forma continua y fiable. Esta dinámica también soluciona un problema persistente del enfoque tradicional y divergente del grupo de sistemas/software: la falta de un bucle de retroalimentación entre el diseño y la producción. Un sistema con un compromiso temprano de la SRE (idealmente, en el momento del diseño) suele funcionar mejor en producción tras su despliegue, independientemente de quién sea el responsable de gestionar el servicio. (Nada ralentiza más el desarrollo de funciones que perder los datos de los usuarios).

Además, hay que evitar cualquier incentivo para pasar la culpa de los incidentes de producción o de los fallos del sistema a otros grupos. En muchos sentidos, la dinámica de traspasar la culpa es el principal problema del modelo tradicional de operaciones de ingeniería, ya que la separación de los equipos de operaciones y de software permite que surjan incentivos distintos. En su lugar, considere la adopción de las siguientes prácticas para combatir el traspaso de culpas a nivel organizativo:

• No se limite a permitir, sino que anime activamente a los ingenieros a cambiar el código y la configuración cuando sea necesario para el producto. Permita también a estos equipos la autoridad para ser radicales dentro de los límites de su misión, eliminando así los incentivos para proceder con más lentitud.

• Apoyar las postmortems libres de culpa.¹⁶⁾ De este modo se eliminan los incentivos para restar importancia o encubrir un problema. Este paso es crucial para comprender plenamente el producto y optimizar realmente su rendimiento y funcionalidad, y se basa en la sabiduría de la producción mencionada anteriormente.

Permitir que el soporte se aleje de los productos que son irremediablemente difíciles desde el punto de vista operativo. La amenaza de la retirada del soporte motiva al desarrollo del producto a solucionar los problemas tanto en el periodo previo al soporte como una vez que el producto ya está soportado, lo que ahorra tiempo a todos. Lo que significa ser “irremediablemente difícil desde el punto de vista operativo” puede variar en función del contexto. La respuesta a otras organizaciones puede ser más suave: “Creemos que hay usos de mayor valor para el tiempo de las personas con este conjunto de habilidades”, o enmarcarse en el límite de: “Estas personas renunciarán si se les asigna demasiado trabajo operativo y no se les da la oportunidad de utilizar su conjunto de habilidades de ingeniería”. En Google, la práctica de retirar directamente el apoyo a este tipo de productos se ha convertido en algo institucional.

En Google, la SRE y el desarrollo de productos son organizaciones separadas. Cada grupo tiene su propio enfoque, prioridades y gestión, y no tiene que cumplir las órdenes del otro. Sin embargo, los equipos de desarrollo de productos financian eficazmente el crecimiento de SRE con nuevas contrataciones cuando un producto tiene éxito. De este modo, el desarrollo de productos participa en el éxito de los equipos de SRE, del mismo modo que los SRE participan en el éxito de los equipos de desarrollo de productos. La SRE también tiene la suerte de recibir un apoyo de alto nivel por parte de la dirección, lo que garantiza que las objeciones de los equipos de ingeniería a dar soporte a los servicios “a la manera de la SRE” suelen durar poco. Sin embargo, no hace falta tener un organigrama para hacer las cosas de otra manera, sólo hace falta que surja una comunidad de práctica diferente.

Independientemente de si forja su organigrama o utiliza mecanismos más informales, es importante reconocer que la especialización crea desafíos. Los profesionales de DevOps y SRE se benefician de contar con una comunidad de compañeros que les apoye y les permita desarrollar su carrera, así como de escalas laborales que les recompensen¹⁷⁾ por las habilidades y perspectivas únicas que aportan.

Es importante señalar que la estructura organizativa empleada por Google, así como algunos de los incentivos antes mencionados, dependen en cierta medida de una organización de tamaño considerable. Por ejemplo, si tu startup de 20 personas sólo tiene un producto (comparativamente pequeño), no tiene mucho sentido permitir la retirada del apoyo operativo. Todavía es posible adoptar un enfoque al estilo DevOps,¹⁸⁾ pero la capacidad de mejorar un producto operacionalmente pobre se ve socavada si literalmente todo lo que puedes hacer es ayudarlo a crecer. Normalmente, sin embargo, la gente tiene más opciones de las que imagina sobre cómo satisfacer esas necesidades de crecimiento frente a la velocidad a la que se acumula la deuda técnica.¹⁹⁾

Sin embargo, cuando su organización o producto crece más allá de un cierto tamaño, puede ejercer más latitud en qué productos apoyar, o cómo priorizar ese apoyo. Si está claro que el soporte para el sistema X va a producirse mucho antes que el soporte para el sistema Y, la condicionalidad implícita puede desempeñar un papel muy parecido al de la elección de no dar soporte a los servicios en el mundo de la SRE.

En Google, la sólida asociación de la SRE con el desarrollo de productos ha demostrado ser de vital importancia: si en su organización existe una relación de este tipo, la decisión de retirar (o suministrar) el soporte puede basarse en datos objetivos sobre las características operativas comparativas, evitando así conversaciones que de otro modo no serían productivas.

Una relación productiva entre la SRE y el desarrollo de productos también ayuda a evitar el antipatrón organizativo en el que un equipo de desarrollo de productos tiene que enviar un producto o una función antes de que esté listo. En su lugar, la SRE puede trabajar con un equipo de desarrollo para mejorar el producto antes de que la carga del mantenimiento se desplace lejos de las personas con más experiencia para solucionarlo.

Por último, asegúrese de que existen incentivos profesionales para hacer lo correcto: queremos que nuestra organización DevOps/SRE tenga la misma estima que sus homólogos de desarrollo de productos. Por lo tanto, los miembros de cada equipo deben ser valorados aproximadamente con los mismos métodos y tener los mismos incentivos financieros.

En muchos sentidos, DevOps y SRE se sitúan, tanto en la práctica como en la filosofía, muy cerca el uno del otro en el panorama general de las operaciones de TI.

Tanto DevOps como SRE requieren un debate, el apoyo de la dirección y la implicación de las personas que realizan el trabajo para progresar seriamente. La aplicación de cualquiera de ellos es un viaje y no una solución rápida: la práctica de renombrar y avergonzar²⁰⁾ es una práctica vacía, con pocas probabilidades de producir beneficios. Dado que se trata de una implementación más opinada de cómo realizar operaciones, SRE tiene sugerencias más concretas sobre cómo cambiar sus prácticas de trabajo en una fase más temprana de ese viaje, aunque requiera una adaptación específica. DevOps, al tener un enfoque más amplio, es algo más difícil de razonar y traducir en pasos concretos, pero precisamente por ese enfoque más amplio, es probable que encuentre una resistencia inicial más débil.

Pero los profesionales de cada una de ellas utilizan muchas de las mismas herramientas, los mismos enfoques de la gestión del cambio y la misma mentalidad de toma de decisiones basada en los datos. Al fin y al cabo, todos nos enfrentamos al mismo problema persistente: la producción y su mejora, independientemente de cómo nos llamemos.

Para quienes estén interesados en seguir leyendo, las siguientes sugerencias deberían ayudarles a desarrollar una comprensión más amplia de los fundamentos culturales, empresariales y técnicos de la revolución de las operaciones que se está produciendo en estos momentos:

• Site Reliability Engineering

• Effective DevOps

• The Phoenix Project

• The Practice of Cloud System Administration: DevOps and SRE Practices for Web Services, Volume 2

• Accelerate: The Science of Lean Software and DevOps

Volver al índice