¿Cómo se relaciona SRE con DevOps? – Capítulo 1 (Libro SRE – 4 de 32)

Escrito oor 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 solo existe la cuestión generalmente no resuelta de cómo ejecutar bien los sistemas, sino que las mejores prácticas que se han encontrado que funcionan dependen en gran medida del contexto y están lejos de ser ampliamente adoptadas. También existe la cuestión, en gran parte sin abordar, de cómo dirigir bien los equipos de operaciones. En general, se cree que el análisis detallado de estos temas se origina en la investigación operativa dedicada a mejorar los procesos y la producción en las fuerzas armadas aliadas durante la Segunda Guerra Mundial, pero en realidad, hemos estado pensando en cómo operar mejor las cosas durante milenios .

Sin embargo, a pesar de todo este esfuerzo y pensamiento, las operaciones de producción confiables siguen siendo esquivas, particularmente en los dominios de la tecnología de la información y la operatividad del software . El mundo empresarial, por ejemplo, a menudo trata las operaciones como un centro de costos, 2 lo que dificulta, si no imposibilita, las 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ó de intentar resolver un conjunto común de problemas. 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 independientes a la mentalidad empresarial que acabamos de describir, 3 esperamos persuadirlo de que, de hecho, son mucho más parecidos y los practicantes 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 uno.

Antecedentes de DevOps

DevOps es un conjunto flexible de prácticas, pautas y cultura diseñadas 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, que significa Cultura, Automatización, Lean (como en administración Lean ; ver también entrega continua ), Medición y Compartir, es un acrónimo útil para recordar el puntos clave de la filosofía DevOps. El intercambio y la colaboración están a la vanguardia de este movimiento. En un enfoque de DevOps, mejora algo (a menudo automatizándolo), mide los resultados y comparte esos resultados con colegas para que toda la organización pueda mejorar. Todos los principios de CALMS son facilitados por una cultura de apoyo.

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

No más silos

La primera idea clave es no más silos . Esta 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 desarrollo y operaciones independientes
  • El hecho de que la separación extrema del conocimiento , los incentivos para la optimización puramente local y la falta de colaboración en muchos casos han sido activamente perjudiciales para las empresas 4

Los accidentes son normales

La segunda idea clave es que los accidentes no son solo el resultado de las acciones aisladas de un individuo, sino más bien el resultado de la falta de salvaguardas para cuando las cosas inevitablemente van mal. 5 Por ejemplo, una mala interfaz fomenta inadvertidamente la acción incorrecta bajo presión; una falla en el sistema hace que la falla sea inevitable si ocurren circunstancias incorrectas (no articuladas); La monitorización rota hace que sea imposible saber si algo está mal, no importa quéEstá Mal. Algunas empresas de mentalidad más tradicional poseen el instinto cultural para erradicar al autor del error y castigarlo. Pero hacerlo tiene sus propias consecuencias: lo más obvio, crea incentivos para confundir los problemas, ocultar la verdad y culpar a los demás, todo lo cual, en última instancia, son distracciones no rentables. Por tanto, es más rentable centrarse en acelerar la recuperación que en prevenir accidentes.

El cambio debe ser gradual

La tercera idea clave es que el cambio es mejor cuando es pequeño y frecuente . En entornos donde los comités de cambio se reúnen mensualmente para discutir planes minuciosamente documentados para realizar cambios en la configuración del mainframe, esta es una idea radical. Sin embargo, esta no es una idea nueva. La noción de que todos los cambios deben ser considerados por humanos experimentados y agrupados para una consideración eficiente resulta ser más o menos lo opuesto a las mejores prácticas. El cambio es arriesgado, es cierto, pero la respuesta correcta es dividir los cambios en subcomponentes más pequeños cuando sea posible. Luego, construye un flujo constante de cambios de bajo riesgo a partir de los resultados regulares de los cambios en el producto, el diseño y la infraestructura. 6Esta estrategia, junto con las pruebas automáticas de cambios más pequeños y la reversión confiable de los cambios incorrectos, conduce a enfoques para la gestión de cambios como la integración continua (CI) y la entrega o implementación continua (CD) .

Las herramientas y la cultura están interrelacionadas

Las herramientas son un componente importante de DevOps, particularmente dado el énfasis en la gestión del cambio correctamente; hoy en día, la gestión del cambio se basa en herramientas muy específicas. Sin embargo, en general, los defensores de DevOps enfatizan fuertemente la cultura organizacional, en lugar de las herramientas, como la clave del éxito en la adopción de una nueva forma de trabajar. Una buena cultura puede trabajar en torno a herramientas rotas, pero lo contrario rara vez es cierto. Como dice el refrán, la cultura se come la estrategia para el desayuno . Como las operaciones, el cambio en sí mismo es difícil.

La medición es crucial

Por último, la medición es particularmente crucial en el contexto empresarial general de, por ejemplo, romper los silos y la resolución de incidentes. En cada uno de estos entornos, estableces la realidad de lo que está sucediendo mediante la medición objetiva, verificas que estás cambiando la situación como esperas y creas una base objetiva para las conversaciones en las que coinciden las diferentes funciones. (Esto se aplica tanto en contextos comerciales como en otros contextos, como de guardia).

Antecedentes de la SRE

Ingeniería de confiabilidad del sitio (SRE) es un término (y 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 del ciclo de vida completo entre las operaciones y el desarrollo de productos. SRE es un rol laboral, un conjunto de prácticas (que se describen a continuación) que hemos encontrado que funcionan y algunas creencias que animan esas prácticas. Si piensa en DevOps como una filosofía y un enfoque de trabajo, puede argumentar que SRE implementa parte de la filosofía que describe DevOps y está más cerca de una definición concreta de un trabajo o función que, digamos, “ingeniero de DevOps”. 8 Entonces, de alguna manera, 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 varias empresas, SRE en Google heredó gran parte de su cultura de la empresa circundante antes de que el término SRE se popularizara ampliamente en la industria. Dada esa trayectoria, la disciplina en su conjunto actualmente no destaca el cambio cultural de forma predeterminada 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.

Las operaciones son un problema de software

El principio básico de SRE es que hacer bien las operaciones es un problema de software. Por lo tanto, la SRE debería utilizar enfoques de ingeniería de software para resolver ese problema. Esto es a través de un amplio campo de visión, que abarca todo, desde cambios de procesos y negocios hasta problemas de software igualmente complicados pero más tradicionales, como reescribir una pila para eliminar puntos únicos de falla en la lógica comercial.

Gestionar por objetivos de nivel de servicio (SLO)

La SRE no intenta que todo esté disponible al 100%. Como se discutió en nuestro primer libro, Ingeniería de confiabilidad del sitio , este es el objetivo equivocado 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 administra según ese SLO. 9 Decidir sobre ese objetivo requiere una fuerte colaboración por parte de la empresa. Los SLO también tienen implicaciones culturales: como decisiones de colaboración entre las partes interesadas, las violaciones de SLO llevan a los equipos de vuelta a la mesa de dibujo, sin culpa.

Trabajar para minimizar el esfuerzo

Para la SRE, cualquier tarea operativa manual con mandato estructural es aborrecible. (Eso no significa que no tengamos tales operaciones: tenemos muchas. Simplemente no nos gustan). Creemos que si una máquina puede realizar una operación deseada, entonces una máquina 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 se le paga a una persona. Para SRE en el contexto de Google, el trabajo duro no es el trabajo, no puede serlo. Cualquier tiempo dedicado a tareas operativas significa tiempo que no se dedica al trabajo del proyecto, y el trabajo del proyecto es la forma en que hacemos que nuestros servicios sean más confiables y escalables.

Sin embargo, la realización de tareas operativas, mediante “la sabiduría de la producción”, proporciona una entrada vital en las decisiones. Este trabajo nos mantiene conectados al proporcionar comentarios en tiempo real de un sistema determinado. Las fuentes de trabajo deben ser identificables para que pueda minimizarlas o eliminarlas. Sin embargo, si se encuentra en una posición de baja carga operativa, es posible que deba impulsar nuevas funciones y cambios con más frecuencia para que los ingenieros estén familiarizados con el funcionamiento del servicio al que brinda soporte.

La sabiduría de la producción

Una nota sobre “la sabiduría de producción”: con esta frase, nos referimos a la sabiduría que se obtiene de algo que se ejecuta en detalles producción a la desordenados de la forma en que realmente se comporta, y cómo el software debería realmente ser diseñado, en lugar de una vista whiteboarded de un Servicio aislado de los hechos sobre el terreno. Todas las páginas que recibe, los tickets que recibe el equipo, etc., son una conexión directa con la realidad que debería informar un mejor diseño y comportamiento del sistema.

Automatizar el trabajo de este año

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

La SRE, tal como se practica en Google, tiene un límite estricto de cuánto tiempo puede dedicar un miembro del equipo a trabajar, a diferencia de la ingeniería que produce un valor duradero: 50%. Mucha gente piensa en este límite como un tope . De hecho, es mucho más útil pensar en ello como una garantía , una declaración explícita y un mecanismo habilitante para adoptar un enfoque de ingeniería a los problemas en lugar de simplemente trabajar en 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 duro. Con el tiempo, un equipo de SRE termina 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 acciones. En el entorno de Google, tiende a agregar más servicios, hasta un límite que aún admite el 50% del tiempo de ingeniería, o tiene tanto éxito en su automatización que puede ir y hacer otra cosa completamente diferente en su lugar.

Muévase rápido reduciendo el costo de fallas

Uno de los principales beneficios de la participación de SRE no es necesariamente una mayor confiabilidad, aunque obviamente eso sucede; en realidad, se trata de una producción mejorada del desarrollo de productos. ¿Por qué? Bueno, un tiempo medio de reparación reducido (MTTR) para fallas comunes da como resultado una mayor velocidad del desarrollador del producto, ya que los ingenieros no tienen que perder tiempo y concentrarse en la limpieza después de estos problemas. Esto se deriva del hecho bien conocido de que cuanto más tarde en el ciclo de vida del producto se descubre un problema, más caro es solucionarlo . Los SRE están específicamente encargados de mejorar el descubrimiento tardío indeseable de problemas, lo que genera beneficios para la empresa en su conjunto.

Comparta la propiedad con los desarrolladores

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 las operaciones como un centro de costos conduce a desequilibrios de poder o discrepancias en la estima o el pago.

Los SRE tienden a centrarse en los problemas de producción en lugar de en los problemas de lógica empresarial, pero a medida que su enfoque aporta herramientas de ingeniería de software para resolver el problema, comparten conjuntos de habilidades con los equipos de desarrollo de productos. En general, un SRE tiene experiencia particular en torno a la disponibilidad, latencia, rendimiento, eficiencia, gestión de cambios, monitoreo, respuesta a emergencias y planificación de la capacidad de los servicios que atiende. Esas competencias específicas (y generalmente bien definidas) son el pan y la mantequilla de lo que hace SRE por un producto y por el equipo de desarrollo de producto asociado. 10Idealmente, tanto los equipos de desarrollo de productos como los de SRE deberían tener una visión holística de la pila (frontend, backend, bibliotecas, almacenamiento, kernels y máquina física) y ningún equipo debería poseer celosamente componentes individuales. Resulta que puede hacer mucho más si “difumina las líneas” 11 y tiene SRE como instrumento JavaScript, o los desarrolladores de productos califican los núcleos: el conocimiento de cómo hacer cambios y la autoridad para hacerlo están mucho más extendidos, y los incentivos para guardar celosamente alguna función en particular se eliminan.

En Ingeniería de confiabilidad del sitio , no dejamos lo suficientemente claro que los equipos de desarrollo de productos en Google son propietarios de su servicio de manera predeterminada. La SRE no está disponible ni se garantiza para la mayor parte de los servicios, aunque los principios de la SRE aún informan cómo se administran los servicios en Google. 12 El modelo de propiedad cuando un equipo de SRE trabaja con un equipo de desarrollo de productos es, en última instancia, también un modelo compartido.

Utilice las mismas herramientas, independientemente de la función o el título del trabajo

Las herramientas son un determinante increíblemente importante del comportamiento, y sería ingenuo suponer que la eficacia de SRE en el contexto de Google no tiene nada que ver con la base de código unificada ampliamente accesible , la amplia gama de herramientas de software y sistemas, las herramientas altamente optimizadas y patentadas. pila de producción, etc. Sin embargo, compartimos esta suposición absoluta con DevOps: equipos que se ocupan de un servicio 13deben utilizar las mismas herramientas, independientemente de su función en la organización. No existe una buena forma de administrar un servicio que tiene una herramienta para las SRE y otra para los desarrolladores de productos, comportándose de manera diferente (y potencialmente catastrófica) en diferentes situaciones. Cuanta más divergencia tenga, menos se beneficiará su empresa de cada esfuerzo por mejorar cada herramienta individual.

Comparar y contrastar

Al observar los principios anteriores, inmediatamente vemos muchos puntos en común en los puntos descritos:

  • Tanto DevOps como SRE dependen de la aceptación de que el cambio es necesario para mejorar. Sin eso, no hay mucho espacio para maniobrar. 14
  • La colaboración está al frente y en el centro del trabajo de DevOps. Un modelo efectivo de propiedad compartida y relaciones de equipo de socios son necesarios para que SRE funcione. 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 gestión del cambio se lleva a cabo mejor como 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 confiabilidad hace que esto sea especialmente importante para SRE.
  • El herramental adecuado es de vital importancia, y el herramental determina hasta cierto punto el alcance de sus actos. Sin embargo, no debemos centrarnos demasiado en si algo se logra utilizando algún conjunto específico de herramientas; Al final del día, la orientación API para la gestión del sistema es una filosofía más importante que durará más que cualquier implementación particular de la misma.
  • La medición es absolutamente clave para el funcionamiento de DevOps y SRE. Para SRE, los SLO son dominantes para determinar las acciones tomadas para mejorar el servicio. Por supuesto, no puede tener SLO sin medición (así como un debate entre equipos, idealmente entre el producto, la infraestructura / SRE y el negocio). Para DevOps, el acto de medir se usa a menudo para comprender cuáles son los resultados de un proceso, cuál es la duración de los ciclos de retroalimentación, etc. Tanto DevOps como SRE son cosas orientadas a datos, ya sean profesiones o filosofías.
  • La cruda realidad de la gestión de los servicios de producción significa que de vez en cuando suceden cosas malas y hay que hablar sobre el motivo. Tanto SRE como DevOps practican autopsias sin culpa para compensar reacciones inútiles cargadas de adrenalina.
  • En última instancia, implementar DevOps o SRE es un acto integral; Ambos esperan mejorar a todo el equipo (o unidad u organización), en función del trabajo conjunto de una manera muy específica. Tanto para DevOps como para SRE, el resultado debería ser una mejor velocidad. 15

Como puede ver, hay muchas áreas 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. Debido a que produce un cambio más amplio 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 torno a la gestión precisa de los servicios. En cambio, elige concentrarse en derribar barreras en la organización en general. Esto tiene mucho valor.

La SRE, por otro lado, tiene responsabilidades definidas de manera relativamente estrecha y su cometido está generalmente orientado al servicio (y al usuario final) en lugar de orientado a todo el negocio. Como resultado, aporta un marco intelectual obstinado (que incluye conceptos como presupuestos de error ) al problema de cómo ejecutar sistemas de manera eficaz. Aunque la SRE es, como profesión, muy consciente de los incentivos y sus efectos, a su vez guarda un silencio relativo sobre temas como la siloización y las barreras de la información. Sería compatible con CI y CD no necesariamente por el caso comercial, sino por las prácticas operativas mejoradas involucradas. O, para decirlo de otra manera, SRE cree en las mismas cosas que DevOps pero por razones ligeramente diferentes .

Contexto organizacional y fomento de la adopción exitosa

DevOps y SRE tienen una superposición conceptual muy grande en cómo operan. Como era de esperar, también tienen un conjunto similar de condiciones que deben cumplirse dentro de la organización para que a) sean implementables en primer lugar yb) obtengan el máximo beneficio de esa implementación. Como casi nunca dijo Tolstoi , los enfoques operativos efectivos son todos iguales, mientras que los enfoques rotos son 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 de DevOps y está dispuesta a asumir esos costos, generalmente expresados como dificultades en la contratación, la energía necesaria para mantener la fluidez en los equipos y responsabilidades, y mayores 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 sean correctos para lograr el beneficio total de este enfoque.

Específicamente, lo siguiente debería ser cierto en el contexto de DevOps y SRE.

Incentivos estrechos y rígidos Limitan su éxito

Muchas empresas definen accidentalmente incentivos formales que socavan el desempeño colectivo. Para evitar este error, no estructure los incentivos para estar estrechamente ligados a resultados relacionados con el lanzamiento o la confiabilidad. Como cualquier economista puede decir que, si no es una medida numérica, la gente encontrará una forma de juego que mal efecto, a veces incluso de forma totalmente bien intencionado. dieciséisEn cambio, debe permitir a su gente la libertad de encontrar las compensaciones adecuadas. Como se mencionó anteriormente, DevOps o SRE pueden actuar como un acelerador para su equipo de productos en general, lo que permite que el resto de la organización de software envíe funciones a los clientes de manera continua y confiable. Esta dinámica también soluciona un problema persistente con el enfoque de grupo de sistemas / software tradicional y divergente: la falta de un circuito de retroalimentación entre el diseño y la producción. Un sistema con participación temprana de SRE (idealmente, en el momento del diseño) generalmente funciona mejor en la producción después de la implementación, independientemente de quién sea responsable de administrar el servicio. (Nada ralentiza el desarrollo de funciones como la pérdida de datos del usuario).

Es mejor arreglarlo usted mismo; No culpes a nadie más

Además, evite cualquier incentivo para pasar la culpa de los incidentes de producción o fallas del sistema a otros grupos. En muchos sentidos, la dinámica de pasar la culpa es el problema central del modelo tradicional de operaciones de ingeniería, ya que separar los equipos de operaciones y de software permite que surjan incentivos separados. En su lugar, considere la posibilidad de adoptar las siguientes prácticas para combatir la transmisión de la culpa a nivel organizacional:

  • No solo permita, sino que anime activamente a los ingenieros a cambiar el código y la configuración cuando sea necesario para el producto. También permita que estos equipos tengan la autoridad para ser radicales dentro de los límites de su misión, eliminando así los incentivos para avanzar más lentamente.
  • Apoye las autopsias sin culpa. 17 Al hacerlo, se eliminan los incentivos para restar importancia o encubrir un problema. Este paso es crucial para comprender completamente el producto y optimizar su rendimiento y funcionalidad, y se basa en la sabiduría de la producción mencionada anteriormente.

Permita que el soporte se aleje de productos que son irremediablemente difíciles de operar. La amenaza de retirada del soporte motiva el desarrollo de productos para solucionar problemas tanto en el período previo al soporte como una vez que el producto recibe soporte, lo que ahorra tiempo a todos. Lo que significa ser “irremediablemente difícil desde el punto de vista operativo” puede diferir según su contexto; la dinámica aquí debe ser una de responsabilidades mutuamente entendidas. El rechazo a otras organizaciones podría ser más suave, “Creemos que hay usos de mayor valor del tiempo de las personas con este conjunto de habilidades”, o enmarcado dentro del límite de “Estas personas renunciarán si se les asigna demasiadas tareas operativas”. trabajar y no se les da la oportunidad de utilizar su conjunto de habilidades de ingeniería “. En Google, la práctica de retirar completamente el soporte de dichos productos se ha vuelto institucional.

Considere el trabajo de confiabilidad como un rol especializado

En Google, SRE y el desarrollo de productos son organizaciones independientes. Cada grupo tiene su propio enfoque, prioridades y gestión, y no tiene que hacer las ofertas 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 esta manera, el desarrollo de productos tiene un interés en el éxito de los equipos de SRE, al igual que los SRE tienen un interés en el éxito de los equipos de desarrollo de productos. La SRE también tiene la suerte de recibir apoyo de alto nivel por parte de la gerencia, lo que garantiza que las objeciones de los equipos de ingeniería a los servicios de soporte “al estilo SRE” sean generalmente de corta duración. Sin embargo, no es necesario tener un organigrama para hacer las cosas de manera diferente, solo necesita que surja una comunidad de práctica diferente.

Independientemente de si divide su organigrama o utiliza mecanismos más informales, es importante reconocer que la especialización crea desafíos. Los practicantes de DevOps y beneficio SRE de tener una comunidad de pares para el apoyo y desarrollo de la carrera, y las escalas de trabajo que recompensa a 18 de las habilidades únicas y perspectivas que aportan a la mesa.

Es importante tener en cuenta que la estructura organizativa empleado por Google, así como algunos de los incentivos mencionados, es algo dependiente de una organización de tamaño considerable. Por ejemplo, si su startup de 20 personas tiene solo un producto (comparativamente pequeño), no tiene mucho sentido permitir la retirada del soporte operativo. Todavía es posible adoptar un enfoque al estilo DevOps, 19 pero la capacidad de mejorar un producto operativamente deficiente se ve socavada si, literalmente, todo lo que puede hacer es ayudarlo a crecer. Sin embargo, por lo general, las personas tienen más opciones de las que imaginan sobre cómo satisfacer esas necesidades de crecimiento en comparación con la tasa a la que se acumula la deuda técnica. 20

¿Cuándo* puede sustituir a si?

Sin embargo, cuando su organización o producto crece más allá de un cierto tamaño, puede ejercer más libertad sobre qué productos respaldar o cómo priorizar ese soporte. Si está claro que el soporte para el sistema X va a suceder mucho antes que el soporte para el sistema Y, la condicionalidad implícita puede jugar el mismo papel que la decisión de no apoyar los servicios en el mundo SRE.

En Google, la sólida asociación de SRE con el desarrollo de productos ha demostrado ser de importancia crítica: si tal relación existe en su organización, entonces la decisión de retirar (o suministrar) el soporte puede basarse en datos objetivos sobre características operativas comparativas, evitando así que no sea productivo conversaciones.

Una relación productiva entre SRE y el desarrollo de productos también ayuda a evitar el anti-patrón organizacional en el que un equipo de desarrollo de productos tiene que enviar un producto o característica antes de que esté completamente listo. En cambio, SRE puede trabajar con un equipo de desarrollo para mejorar el producto antes de que la carga del mantenimiento se aleje de las personas con más experiencia para arreglarlo.

Luchar por la paridad de estima: carrera y finanzas

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


Conclusión

En muchos sentidos, DevOps y SRE se encuentran, tanto en la práctica como en la filosofía, muy cerca entre sí en el panorama general de las operaciones de TI.

Tanto DevOps como SRE requieren discusión, apoyo de la administración y la participación de las personas que realmente hacen el trabajo para lograr un progreso serio. Implementar cualquiera de ellos es un viaje y no una solución rápida: la práctica del cambio de nombre y la vergüenza 21 es hueca, y es poco probable que produzca beneficios. Dado que se trata de una implementación más obstinada de cómo realizar las operaciones, la SRE tiene sugerencias más concretas sobre cómo cambiar sus prácticas laborales al principio de ese viaje, aunque requieran una adaptación específica. DevOps, que tiene un enfoque más amplio, es algo más difícil de razonar y traducir en pasos concretos, pero precisamente debido a ese enfoque más amplio, es probable que encuentre una resistencia inicial más débil.

Pero los profesionales de cada uno utilizan muchas de las mismas herramientas, los mismos enfoques para la gestión del cambio y la misma mentalidad de toma de decisiones basada en datos. Al final del día, todos enfrentamos el mismo problema persistente: la producción y su mejora, sin importar cómo nos llamen.

Para aquellos interesados en leer más, las siguientes sugerencias deberían ayudarlo a desarrollar una comprensión más amplia de los fundamentos culturales, comerciales y técnicos de la revolución de las operaciones que está teniendo lugar en este momento:

1

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

2 Mary Poppendieck tiene un artículo excelente sobre esto llamado “ La trampa del centro de costos “. Otra forma en la que este enfoque falla es cuando un desastre muy grande e improbable borra por completo los ahorros de costos que logró al pasar a un modelo de operaciones de bajo nivel (consulte la interrupción de British Airways en mayo de 2017 ).

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

4 Tenga en cuenta también que debido a que este es un mundo complicado, también hay efectos positivos en las particiones , los silos y similares, pero las desventajas parecen ser particularmente perniciosas en el dominio de las operaciones.

5 Ver https://en.wikipedia.org/wiki/Normal_Accidents .

6 Los cambios de mayor riesgo, o aquellos que no se pueden validar por medios automáticos, obviamente aún deben ser examinados por humanos, si no implementados por ellos.

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

8 Este es un nombre inapropiado en una gran cantidad de formas, quizás la más fundamental es que no puede simplemente contratar a algunas personas, llamarlas “ingenieros de DevOps” y esperar beneficios de inmediato. Tienes que aceptar toda la filosofía de cambiar la forma en que trabajas para poder beneficiarte. 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 puede “contratar un DevOp para arreglar su organización”.

9 Un objetivo de nivel de servicio es un objetivo para el desempeño de una métrica en particular (por ejemplo, disponible el 99,9% del tiempo).

10 Por supuesto, no todos los equipos hacen todo, pero esos son los encabezados más comunes bajo los cuales trabaja SRE.

11 Realice una violación de capas, si piensa en esto como pilas en capas.

12 De hecho, existe una Revisión de preparación de producción para incorporar cualquier cosa ; SRE no solo incorporará servicios desde un principio.

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

14 Dentro de Google, esa cuestión está resuelta en gran medida, y los servicios cambian de estado, configuración, propiedad, dirección, etc., todo el tiempo. Hasta cierto punto, SRE en Google es el beneficiario del argumento de que “el cambio es necesario” se ha peleado y ganado varias veces en el pasado. Pero no completamente distribuido de manera uniforme , como diría William Gibson.

15 Consulte la investigación relevante en https://devops-research.com/research.html .

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

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

18 En organizaciones que tienen culturas bien desarrolladas de ambos. Es probable que las empresas en etapa inicial no hayan establecido formas de recompensar estos roles laborales.

19 De hecho, podría decirse que esa es su única opción a menos que subcontrate las operaciones.

20 Para obtener más información sobre cómo aplicar los principios de SRE en diferentes contextos, consulte Ciclos de vida del equipo de SRE .

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

? SIGUIENTE
? ANTERIOR

Relacionados

Deja un comentario