Capítulo 1. Relación entre SRE y DevOps

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com

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.1 No sólo está la cuestión, en general sin resolver, de cómo dirigir bien los sistemas, sino que las buenas prácticas que se ha descubierto que funcionan dependen en gran medida del contexto y distan mucho de ser ampliamente adoptadas. También está la cuestión, en gran medida sin resolver, de cómo dirigir bien los equipos de operaciones. Suele pensarse 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, la fiabilidad de las operaciones de producción sigue siendo difícil de alcanzar, sobre todo 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 costes,2 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 un conjunto de problemas comunes. Las soluciones más recientes a estos problemas reciben dos nombres distintos: DevOps y Site Reliability Engineering (SRE). Aunque hablamos de ellas individualmente como si fueran reacciones totalmente separadas a la mentalidad empresarial que acabamos de describir,3 esperamos convencerte de que, en realidad, son mucho más parecidas, y los profesionales de cada una de ellas tienen mucho más en común de lo que podrías suponer.

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

Antecedentes de DevOps

DevOps es un conjunto flexible de prácticas, directrices y cultura diseñado para romper los silos en el desarrollo, las operaciones, las redes y la seguridad de TI. Articulado por John Willis, Damon Edwards y Jez Humble, CA(L)MS -quesignifica 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. Compartir y colaborar están a la vanguardia de este movimiento. En un enfoque DevOps, mejoras algo (a menudo automatizándolo), mides los resultados y los compartes con tus colegas para que toda la organización pueda mejorar. Todos los principios CALMS se ven facilitados por una cultura de apoyo.

DevOps, Agile y otras muchas técnicas de reingeniería empresarial y de software son ejemplos de una visión general del mundo sobre la mejor forma 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 debatirse de forma relativamente aislada.

No más silos

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

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

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

Los accidentes son normales

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 vayan mal.5 Por ejemplo, una mala interfaz fomenta inadvertidamente la acción equivocada bajo presión; un fallo del sistema hace inevitable el fracaso si se dan las circunstancias equivocadas (no articuladas); un monitoreo defectuoso 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 tanto, es más rentable centrarse en acelerar la recuperación que en prevenir los accidentes.

El cambio debe ser gradual

La tercera idea clave es que el cambio es mejor cuando es pequeño y frecuente. En los entornos , donde 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 idea de que todos los cambios deben ser considerados por humanos experimentados y agrupados por lotes para un examen eficiente resulta ser más o menos lo contrario de las buenas prácticas. El cambio es arriesgado, es cierto, pero la respuesta correcta es dividir tus cambios en subcomponentes más pequeños siempre que sea posible. A continuación, construye una canalización constante de cambios de bajo riesgo a partir de los resultados regulares de los cambios de producto, diseño e infraestructura.6 Esta estrategia, junto con las pruebas automáticas de de los cambios más pequeños y la reversión fiable de los cambios erróneos, conduce a enfoques de la gestión del cambio de como la integración continua (IC) y la entrega o implementación continua (CD).

El utillaje y la cultura están interrelacionados

Las herramientas son un componente importante de DevOps, sobre todo por el énfasis que se pone en gestionar el cambio correctamente: hoy en día, la gestión del cambio depende de herramientas muy específicas. En general, sin embargo, los defensores de DevOps insisten mucho en la cultura organizativa -más que en las herramientas- como clave del éxito en la adopción de una nueva forma de trabajar. Una buena cultura puede funcionar con herramientas defectuosas, pero rara vez ocurre lo contrario. 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.

La medición es crucial

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, estableces la realidad de lo que está ocurriendo mediante una medición objetiva, verificas que estás cambiando la situación como esperabas y creas una base objetiva para las conversaciones que las distintas funciones acuerdan. (Esto se aplica tanto en contextos empresariales como en otros, como las guardias).

Antecedentes de la ESR

Ingeniería de Fiabilidad del Sitio (SRE) es un término (y una función laboral asociada) acuñado por Ben Treynor Sloss, vicepresidente de ingeniería de Google.7 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 del producto. La SRE es una función laboral, un conjunto de prácticas (descritas a continuación) que hemos comprobado que funcionan, y algunas creencias que animan esas prácticas. Si piensas en DevOps como una filosofía y un enfoque de trabajo, puedes argumentar que la SRE pone en práctica parte de la filosofía que describe DevOps, y está algo más cerca de una definición concreta de un trabajo o función que, por ejemplo, "ingeniero DevOps".8 Así que, en cierto modo, la clase SRE implementa la interfaz DevOps.

A diferencia del movimiento DevOps, que se originó a partir de colaboraciones entre líderes y profesionales de múltiples empresas, la SRE en Google heredó gran parte de su cultura de la empresa que la rodeaba antes de que el término SRE se popularizara ampliamente en todo el sector. Dada esa trayectoria, actualmente la disciplina en su conjunto no pone en primer plano 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 ESR se define por los siguientes principios concretos.

Las operaciones son un problema de software

El principio básico de la SRE es que hacer bien las operaciones es un problema de software. Por 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 reescribir una pila para eliminar los puntos únicos de fallo en la lógica empresarial.

Gestionar por Objetivos de Nivel de Servicio (ONS)

La SRE no intenta dar a todo un 100% de disponibilidad. Como comentamos en nuestro primer libro, Site Reliability Engineering, éste es el objetivo equivocado de por varias razones. En su lugar, el equipo de producto y el equipo de SRE seleccionan un objetivo de disponibilidad adecuado para el servicio y su base de usuarios, y el servicio se gestiona según ese objetivo de disponibilidad.9 Decidir ese objetivo requiere una fuerte colaboración del negocio. Los SLO también tienen implicaciones culturales: como decisiones de colaboración entre las partes interesadas, las violaciones de los SLO hacen que los equipos vuelvan a la mesa de dibujo, sin culpa.

Trabajar para minimizar el trabajo

Para la SRE, cualquier tarea operativa manual, ordenada estructuralmente por , es aborrecible. (Eso no significa que no tengamos operaciones de ese 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 es el trabajo, y para eso pagas a una persona. Para la SRE en el contexto de Google, el trabajo no es el trabajo, no puede serlo. Todo el tiempo dedicado a tareas operativas significa tiempo no dedicado al trabajo de proyecto, y el trabajo de proyecto es la forma en que hacemos que nuestros servicios sean más fiables y escalables.

Sin embargo, la realización de tareas operativas, mediante "la sabiduría de la producción", proporciona una aportación vital a las decisiones. Este trabajo nos mantiene con los pies en la tierra al proporcionar información en tiempo real de un sistema determinado. Las fuentes de trabajo deben ser identificables para que puedas minimizarlas o eliminarlas. Sin embargo, si te encuentras en una situación de infracarga operativa, puede que tengas que impulsar nuevas funciones y cambios más a menudo para que los ingenieros sigan familiarizados con el funcionamiento del servicio al que prestas apoyo.

Automatiza el trabajo de este año

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

La SRE, tal 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: unadeclaració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.

Existe 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. 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, o bien tiendes a añadir más servicios, hasta cierto límite que siga soportando el 50% del tiempo de ingeniería, o bien tienes tanto éxito en tu automatización que puedes dedicarte a otra cosa completamente distinta.

Muévete rápido reduciendo el coste del fracaso

Uno de los principales beneficios de la contratación de SRE no es necesariamente el aumento de la fiabilidad, aunque obviamente eso ocurre; en realidad es la mejora del rendimiento del desarrollo del producto . ¿Por qué? Bueno, la reducción del tiempo medio de reparación (MTTR) de los fallos comunes se traduce en un aumento de la velocidad de desarrollo del producto, ya que los ingenieros no tienen que perder tiempo ni centrarse en limpiar estos problemas. Esto se deduce del hecho bien conocido de que cuanto más tarde se descubre un problema en el ciclo de vida del producto, más caro resulta solucionarlo. Los SRE se encargan específicamente de mejorar el indeseablemente tardío descubrimiento de problemas, lo que reporta beneficios a la empresa en su conjunto.

Compartir la propiedad con los promotores

Los límites rígidos entre "desarrollo de aplicaciones" y "producción" (a veces llamados 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 conocimientos específicos sobre la disponibilidad, latencia, rendimiento, eficiencia, gestión de cambios, monitoreo, respuesta a emergencias y planificación de la capacidad de los servicios de los que se ocupa. Esas 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 del producto asociado.10 Idealmente, tanto los equipos de desarrollo de productos como los de SRE deberían tener una visión holística de la pila -el frontend, el backend, las bibliotecas, el almacenamiento, los núcleos y la máquina física- y ningún equipo debería poseer celosamente componentes individuales. Resulta que puedes hacer mucho más si "difuminas las líneas"11 y haces que los SRE instrumenten JavaScript, o que los desarrolladores de productos cualifiquen 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 una función concreta.

En Ingeniería de Fiabilidad del Sitio, no dejamos suficientemente claro que los equipos de desarrollo de productos en Google son propietarios de su servicio por defecto. La SRE no está disponible ni garantizada para la mayor parte de los servicios, aunque los principios de la SRE siguen informando sobre cómo se gestionan los servicios en todo Google.12 El modelo de propiedad cuando un equipo de SRE trabaja con un equipo de desarrollo de productos también es, en última instancia, un modelo compartido.

Utiliza el mismo utillaje, independientemente de la función o el puesto de trabajo

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. Sin embargo, compartimos este supuesto absoluto con DevOps: los equipos que se ocupan de un servicio13 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 tengas, menos se beneficiará tu empresa de cada esfuerzo por mejorar cada herramienta individual.

Comparar y contrastar

Si observamos los principios anteriores, enseguida vemos bastantes puntos en común en los puntos esbozados:

  • 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.14

  • La colaboración está en el centro del trabajo DevOps. Para que la SRE funcione es necesario un modelo eficaz de propiedad compartida y relaciones de equipo entre socios. 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 algo 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 automáticamente. La interacción crítica entre cambio y fiabilidad hace que esto sea especialmente importante para la SRE.

  • Las herramientas adecuadas son de vital importancia, y las herramientas determinan en cierta medida el alcance de tus 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 de la API para la gestión del sistema 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. Para la SRE, los SLO son dominantes a la hora de determinar las acciones emprendidas 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). Para 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. Tanto DevOps como SRE son cosas orientadas a los datos, ya sean profesiones o filosofías.

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

  • En última instancia, implantar DevOps o SRE es un acto holístico; ambos esperan hacer que todo el equipo (o unidad, u organización) sea mejor, en función de trabajar juntos de una forma muy específica. Tanto para DevOps como para SRE, el resultado debería ser una mayor velocidad.15

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

Sin embargo, también hay 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 la SRE, DevOps es más sensible al contexto. DevOps guarda relativamente silencio sobre cómo llevar a cabo las 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 definidas de forma relativamente estricta y su cometido suele estar orientado a los servicios (y al usuario final) más que a todo el negocio. 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 con eficacia. Aunque la SRE es, como profesión, 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 IC y la DC 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 distintas.

Contexto organizativo y fomento de la adopción con éxito

DevOps y SRE tienen un gran solapamiento conceptual en su funcionamiento. Como cabría 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 pero nunca llegó a decir Tolstoi, los enfoques de operaciones eficaces son todos iguales, mientras que los enfoques rotos están todos rotos 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 costes -que suelen expresarse 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 escaso-, entonces esa organización también debe asegurarse de que los incentivos son los correctos para conseguir todos los beneficios de este enfoque.

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

Los incentivos estrechos y rígidos reducen tu éxito

Muchas empresas definen accidentalmente incentivos formales que socavan el rendimiento colectivo. Para evitar este error, no estructures los incentivos para que estén estrechamente ligados a resultados relacionados con el lanzamiento o la fiabilidad. Como puede decirte cualquier economista, si hay una medida numérica, la gente encontrará la forma de jugar con ella para obtener un mal efecto, a veces incluso de forma totalmente bienintencionada.16 En lugar de eso, debes dar a tu gente la libertad de encontrar las compensaciones adecuadas. Como ya se ha comentado, DevOps o SRE pueden actuar como aceleradores para tu equipo de producto en general, permitiendo que el resto del org de software envíe funciones 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 la implementación, 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).

Es mejor que lo arregles tú; no culpes a otro

Además, evita 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 del traspaso de culpas 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, considera la posibilidad de adoptar las siguientes prácticas para combatir el traspaso de culpas a nivel organizativo:

  • No te limites a permitir, sino que animes activamente a los ingenieros a cambiar el código y la configuración cuando lo requiera el producto. Permite 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.

  • Apoya las autopsias libres de culpa.17 Al hacerlo, 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.

Permite que el soporte se aleje de los productos que son irremediablemente difíciles desde el punto de vista operativo. La amenaza de retirar el 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 de tu contexto: la dinámica debe ser la de responsabilidades mutuamente entendidas. La respuesta a otros organismos puede ser más suave: "Creemos que hay usos más valiosos del 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 rotundamente el apoyo a tales productos se ha convertido en algo institucional.

Considera el trabajo de fiabilidad como una función especializada

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 efectivamente 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, al igual que los SRE participan en el éxito de los equipos de desarrollo de productos. La SRE también tiene la suerte de recibir el apoyo de alto nivel de la dirección, lo que garantiza que las objeciones de los equipos de ingeniería al apoyo de 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 bifurcas tu organigrama o utilizas mecanismos más informales, es importante reconocer que la especialización crea retos. Los profesionales de DevOps y SRE se benefician de tener una comunidad de colegas que les apoyen y les ayuden en su carrera, y de escalafones laborales que les recompensen18 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 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. Sigue siendo posible adoptar un enfoque al estilo DevOps,19 pero la capacidad de mejorar un producto operacionalmente deficiente se ve mermada si, literalmente, lo único que puedes hacer es ayudarle a crecer. Normalmente, sin embargo, la gente tiene más opciones de las que imagina sobre cómo satisfacer esas necesidades de crecimiento frente al ritmo al que se acumula la deuda técnica.20

Cuándo puede sustituir a Si

Sin embargo, cuando tu organización o producto crece más allá de cierto tamaño, puedes ejercer más latitud en qué productos dar soporte, o cómo priorizar ese soporte. 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 tu organización existe una relación de este tipo, la decisión de retirar (o suministrar) apoyo puede basarse en datos objetivos sobre 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 arreglarlo.

Lucha por la Paridad de Estima: Profesional y Financiera

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

Conclusión

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 debate, apoyo de la dirección e implicación de las personas que realmente hacen el trabajo para progresar seriamente. Implantar cualquiera de ellos es un viaje y no una solución rápida: la práctica de renombrar y avergonzar21 es una práctica vacía, con pocas probabilidades de producir beneficios. Dado que se trata de una implementación más opinable de cómo realizar operaciones, la SRE tiene sugerencias más concretas sobre cómo cambiar tus 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 hacerla mejor, nos llamemos como nos llamemos.

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

1 Ten en cuenta que, como esta discusión aparece en un libro sobre SRE, parte de ella es específica de las operaciones de servicios de software, en contraposición a las operaciones de TI.

2 Mary Poppendieck tiene un excelente artículo sobre esto titulado "La trampa del centro de costes". Otra forma en que este enfoque fracasa es cuando una catástrofe muy grande e improbable aniquila por completo el ahorro de costes que conseguiste al pasar a un modelo de operaciones de bajo nivel (por ejemplo, el apagón de British Airways en mayo de 2017).

3 Por supuesto, existen otras posibles reacciones. Por ejemplo, ITIL® es otro enfoque de la gestión de TI que aboga por una mejor normalización.

4 Ten en cuenta también que, al tratarse de un mundo complicado, también hay efectos positivos en la partición, los silos y similares, pero los inconvenientes parecen ser especialmente perniciosos en el ámbito de las operaciones.

5 Véase https://en.wikipedia.org/wiki/Normal_Accidents.

6 Los cambios de mayor riesgo, o los que no se pueden validar por medios automáticos, obviamente deben ser examinados por humanos, si es que no son ellos quienes los promulgan.

7 La historia de la SRE en Google es que surgió de un equipo precursor, más centrado en las operaciones, y Ben dio el impulso para tratar el problema desde el punto de vista de la ingeniería.

8 Se trata de un término equivocado en un gran número de aspectos, quizás el más fundamental sea que no puedes simplemente contratar a algunas personas, llamarlas "ingenieros DevOps" y esperar beneficios inmediatamente. Tienes que aceptar toda la filosofía de cambiar tu forma de trabajar para obtener beneficios. Como dice Andrew Clay Shafer: "La gente vende DevOps, pero no puedes comprarlo". Y, como señala Seth Vargo en "Los 10 mitos de DevOps", no puedes "contratar a un DevOp para que arregle tu organización".

9 Un objetivo de nivel de servicio es una meta de rendimiento de una métrica concreta (por ejemplo, disponible el 99,9% del tiempo).

10 Por supuesto, no todos los equipos lo hacen todo, pero esos son los epígrafes más comunes bajo los que trabaja la SRE.

11 Realiza una violación de capas, si piensas en esto como pilas de capas.

12 De hecho, hay una Revisión de la Disponibilidad para la Producción (Production Readiness Review) para incorporar cualquier cosa; la SRE no se limita a incorporar servicios desde el principio.

13 Un servicio se define vagamente como un software que se ejecuta para realizar alguna necesidad empresarial, generalmente con restricciones de disponibilidad.

14 Dentro de Google, esa cuestión está en gran medida resuelta, y los servicios cambian de estado, configuración, propiedad, dirección, etc., todo el tiempo. Hasta cierto punto, la SRE en Google es la beneficiaria de que el argumento de "el cambio es necesario" se haya combatido y ganado varias veces en el pasado. Pero no completamente repartido, como diría William Gibson.

15 Véase la investigación pertinente en https://devops-research.com/research.html.

16 Véase http://en.wikipedia.org/wiki/Goodhart%27s_law y https://skybrary.aero/bookshelf/books/2336.pdf.

17 Véase, por ejemplo, https://codeascraft.com/2012/05/22/blameless-postmortems/.

18 En las orgs que tienen culturas bien desarrolladas de o. Es probable que las empresas incipientes no tengan formas establecidas de recompensar estas funciones laborales.

19 De hecho, podría decirse que es tu única opción, a menos que subcontrates las operaciones.

20 Para saber cómo aplicar los principios de la ESR en distintos contextos, véase el capítulo 20.

21 En otras palabras, simplemente retitular a un grupo DevOps o SRE sin ningún otro cambio en su posicionamiento organizativo, lo que resulta en una inevitable vergüenza del equipo cuando no se produce la mejora prometida.

Get El cuaderno de trabajo de la fiabilidad del sitio web now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial