10. Despejar el camino para la SRE en la empresa

Damon Edwards, Rundeck, Inc.

“Suena muy bien, pero ¿cómo podría funcionar eso aquí?”.

¿Trabaja en una empresa mediana o grande? ¿Se le ha pasado esta pregunta por la cabeza al leer este libro? Sepa que no está solo.

Cambiar la forma en que una organización lleva a cabo sus operaciones es difícil a cualquier escala. Sin embargo, es en la empresa donde los retos y los obstáculos al cambio suelen parecer montañas insuperables.

¿Cambiar las herramientas? Complicado, pero factible a cualquier escala.

¿Enseñar a las personas nuevas habilidades? Difícil y lento, pero hay caminos conocidos que todos pueden seguir, que todo el mundo puede seguir.

¿Cambiar radicalmente el funcionamiento de su organización? Aquí es donde se encuentra la montaña metafórica en todas las organizaciones, excepto en las más pequeñas.

No tema, pasar de un modelo clásico de operaciones empresariales a un modelo de SRE es factible. Las empresas lo están haciendo ahora mismo, mientras usted lee este libro.

Este capítulo está dirigido a los líderes empresariales que buscan transformar sus organizaciones de operaciones tradicionales a SRE. Aprenderá a identificar y eliminar los obstáculos que, si no se abordan, socavarían su transformación hacia la SRE.

Este capítulo proviene de una compilación de conocimientos adquiridos al trabajar con grandes empresas para transformar sus organizaciones de operaciones. Estas personas han tomado el camino inexplorado hacia la SRE para que su viaje sea más fácil.

En primer lugar, examinaré las fuerzas sistémicas que se interpondrán en su camino. En segundo lugar, destacaré las técnicas para superar esos obstáculos, de modo que pueda iniciar y mantener su transformación hacia la SRE.

¿Cómo medir el éxito? Mejora de la fiabilidad, mejora de la MTTD/MTTR ¹⁾, mayor agilidad organizativa y compañeros más eficaces. ¿En qué consiste el fracaso? Acabar con algunos nuevos títulos de “SRE”, pero sin que cambie mucho más.

El Trabajo Pesado Operativo (Toil) es el villano oculto en el camino hacia la SRE. En las organizaciones que ya han interiorizado la forma de trabajar de la SRE, detectar y eliminar el trabajo pesado es un reflejo natural. En las organizaciones que provienen de una cultura de operaciones tradicional, detectar y eliminar el trabajo pesado es una habilidad de toda la organización que a menudo hay que aprender.

¿Qué es el trabajo pesado? Vivek Rau, de Google, lo explica muy bien: “El trabajo pesado es el tipo de trabajo vinculado a la gestión de un servicio de producción que tiende a ser manual, repetitivo, automatizable, táctico, carente de valor duradero y que aumenta linealmente a medida que crece el servicio”. Cuantos más de estos atributos tenga una tarea, más seguro se puede estar de que la tarea debe clasificarse como trabajo pesado.

Clasificar una tarea como trabajo pesado no significa que sea frívola o innecesaria. Al contrario, la mayoría de las organizaciones se paralizarían si no se realizaran. El valor del trabajo es a menudo un punto de confusión entre los equipos de operaciones empresariales tradicionales. Para algunos, la intervención manual en el funcionamiento de los servicios es la descripción de su trabajo.

El hecho de que una tarea sea necesaria para aportar valor a un cliente no significa necesariamente que sea un trabajo que añada valor. Para quienes estén familiarizados con los principios de la Lean manufacturing, esto no es muy distinto del Tipo 1 Muda ²⁾ (tareas necesarias que no añaden valor). El trabajo puede ser necesario a veces, pero no añade valor duradero (es decir, un cambio en la percepción del valor por parte de los clientes o de la empresa).

En lugar de que los SRE dediquen su tiempo a tareas que no añaden valor, es mejor que dediquen la mayor parte de su tiempo a tareas de ingeniería que añaden valor. También a partir de las útiles definiciones de Vivek Rau, el trabajo de ingeniería puede definirse como el trabajo creativo e innovador que requiere juicio humano, tiene valor duradero y puede ser aprovechado por otros (véase la Tabla 10-1).

Tabla 10-1. Comparación de las características del trabajo pesado y del trabajo de ingeniería

Trabajar en una organización con una alta proporción de trabajo de ingeniería se siente, metafóricamente hablando, como si todo el mundo estuviera nadando hacia una meta. Trabajar en una organización con una baja proporción entre trabajo de ingeniería y esfuerzo es más bien como andar por el agua, en el mejor de los casos, o hundirse, en el peor.

El objetivo del “trabajo no pesado” suena bien en teoría pero, en realidad, es inalcanzable en una empresa en funcionamiento. Las organizaciones tecnológicas siempre están en constante cambio, y los nuevos desarrollos (esperados o inesperados) casi siempre causan trabajo pesado.

Lo mejor que podemos esperar es reducir el trabajo pesado y mantenerlo a un nivel manejable en toda la organización. El trabajo pesado vendrá de cosas que ya conoce pero que no tiene tiempo o presupuesto para automatizar inicialmente (por ejemplo, despliegues semimanuales, actualizaciones/retrocesos de esquemas, cambio de cuotas de almacenamiento, cambios de red, adiciones de usuarios, adición de capacidad, cambios de DNS y conmutación por error de servicios). El trabajo pesado también se verá afectado por los imprevistos que pueden causar incidentes que requieran intervención manual (por ejemplo, reinicios, diagnósticos, comprobaciones de rendimiento y cambios en la configuración).

El trabajo pesado puede parecer inocuo en pequeñas cantidades. La preocupación por incidentes individuales de trabajo pesado se suele descartar con una respuesta como “No hay nada malo en un poco de trabajo pesado”. Sin embargo, si no se controla, el trabajo pesado puede acumularse rápidamente hasta alcanzar niveles tóxicos tanto para el individuo como para la organización.

Para el individuo, unos niveles elevados de trabajo pesado conllevan lo siguiente:

• Descontento y falta de sentimiento de logro.
• Agotamiento
• Mayor número de errores, que requieren mucho tiempo para corregirlos.
• No hay tiempo para aprender nuevas habilidades
• Estancamiento profesional (por falta de oportunidades para realizar proyectos que aporten valor).

Para la organización, unos niveles elevados de trabajo pesado conllevan lo siguiente:

• Falta constante de capacidad de los equipos
• Costos de apoyo operativo excesivos
• Incapacidad para avanzar en iniciativas estratégicas (el síndrome de “todo el mundo está ocupado, pero no se hace nada”).
• Incapacidad para retener a los mejores talentos (y adquirirlos cuando se corre la voz sobre el funcionamiento de la organización).

Uno de los aspectos más peligrosos del trabajo pesado es que requiere un trabajo de ingeniería para eliminarlo. Piense en la última avalancha de tareas manuales y repetitivas que ha experimentado. Hacer esas tareas no impide que aparezca la siguiente tanda.

Reducir la carga de trabajo pesado requiere tiempo de ingeniería, ya sea para crear la automatización de apoyo que elimine la necesidad de intervención manual o para mejorar el sistema a fin de aliviar la necesidad de intervención en primer lugar.

El trabajo de ingeniería necesario para reducir el esfuerzo suele consistir en crear automatización externa (es decir, scripts y herramientas de automatización fuera del servicio), crear automatización interna (es decir, automatización suministrada como parte del servicio) o mejorar el servicio para que no requiera intervención de mantenimiento.

El trabajo pesado consume el tiempo necesario para realizar el trabajo de ingeniería que evitará futuros esfuerzos. Si no se tiene cuidado, el nivel de trabajo en una organización puede aumentar hasta un punto en el que la organización no tenga la capacidad necesaria para detenerlo. Si lo alineamos con la metáfora de la deuda técnica, esto sería la “bancarrota de la ingeniería”, como se ilustra en la Figura 10-1.

Figura 10-1. El exceso de trabajo pesado consume la capacidad de un equipo para realizar tareas de ingeniería que mejoren el negocio y reduzcan el trabajo.

El modelo de trabajo de la SRE -y todos los beneficios que conlleva- depende de que los equipos tengan una amplia capacidad para el trabajo de ingeniería. Si el trabajo pesado se come esa capacidad, el modelo SRE no puede ponerse en marcha ni mantenerse. Un SRE perpetuamente enterrado bajo el trabajo pesado no es un SRE, sólo un tradicional y sufrido SysAdmin con un nuevo título.

Las empresas son un terreno fértil para el trabajo pesado. En primer lugar, en lo que respecta al concepto de trabajo pesado, las filosofías heredadas de gestión de operaciones eran ciegas (“Todo el mundo parece ocupado. ¡Gran eficiencia!”) o indiferentes (“¿Por qué te quejas de estos dolores de cabeza? Te pago para que tengas dolores de cabeza”). En segundo lugar, el alto nivel de complejidad organizativa que se encuentra en una empresa crea trabajo dura y se interpone en el camino de los esfuerzos para reducirlo.

Para este debate, definiremos una “empresa” como cualquier compañía que haya tenido el éxito histórico necesario para acumular una cantidad significativa de legado (cultura, organización, proceso y tecnología).

Las empresas tienen un “aspecto” distinto. Desde una perspectiva empresarial, encontrará múltiples líneas de negocio, cada una nacida o adquirida durante épocas diferentes que tenían un contexto y unos supuestos subyacentes únicos. Desde el punto de vista tecnológico, encontrará varias generaciones de plataformas y herramientas -algunas totalmente nuevas, otras antiguas y en evolución, otras huérfanas- que deben combinarse para prestar servicios a los clientes.

Es bueno tener en cuenta que en una empresa nada vive aislado. Lo que tú haces depende de los demás. Lo que hacen los demás depende de ti. En las arquitecturas clásicas, estas dependencias son fijas y obvias. En las arquitecturas modernas, a menudo son dinámicas y se abstraen, pero siguen existiendo. A nivel humano, los incentivos, presupuestos, políticas, creencias y normas culturales están entrelazados en los distintos extremos de una empresa.

Esta interconexión hace que la eliminación del trabajo duro sea mucho más difícil en la empresa. El trabajo duro que realiza el propio equipo puede eliminarse con un sencillo trabajo de ingeniería. Pero, ¿qué ocurre con todo el trabajo que se debe a condiciones o sistemas que existen en otras partes de la organización? Su eliminación está fuera del control de un equipo, a menos que éste pueda encontrar soluciones que trasciendan los límites de la organización, lo que cualquiera con experiencia empresarial sabe que no es una hazaña trivial.

El trabajo pesado que está parcial o totalmente fuera del control de un equipo es especialmente peligroso. Acerca al equipo a ese umbral de bancarrota en el que el trabajo pesado desplaza todo el trabajo de ingeniería. Esta es una causa común del antipatrón por el que los equipos de SysAdmin son rebautizados como “equipos SRE”, pero la falta de ingeniería bloquea la transformación más allá del nuevo nombre.

Después de haber establecido que el exceso de trabajo pesado impedirá que una empresa cambie a un modelo de SRE, se deduce lógicamente que va a tener que trabajar a través de los límites de la organización con el fin de contener eficazmente el trabajo pesado. Sin embargo, el trabajo transfronterizo es uno de los grandes retos de la TI empresarial.

Trabajar a través de los límites de la organización es difícil debido a una confluencia de efectos de silo, colas de solicitudes y el más venerable de todos los caballos de batalla de las operaciones de TI, los tickets.

La metáfora del silo se atribuye por primera vez a Phil S. Ensor, que la utilizó en 1988 ³⁾ para describir los retos organizativos de su empresa, Goodyear Tire. Desde entonces, el concepto de “silos” ha sido discutido por el movimiento de Lean Manufacturing y el movimiento DevOps. Algunas personas piensan erróneamente que “silos = equipos”, pero en realidad, los silos no tienen mucho que ver con la estructura organizativa. La idea de un silo realmente tiene todo que ver con la forma en que un grupo trabaja dentro de una organización.

En términos sencillos, se dice que un grupo “trabaja en un silo” cuando sus miembros trabajan desconectados de otros grupos (lo sepan o no), como se muestra en la Figura 10-2. A la hora de detectar silos, hay que buscar situaciones en las que un grupo trabaje en un contexto diferente al de otros grupos, su trabajo proceda de una fuente distinta a la de otros grupos (es decir, que tenga atrasos diferentes) y el grupo trabaje con incentivos o prioridades diferentes (y a menudo forme parte de una cadena de gestión distinta). Es casi seguro que este grupo está trabajando en un silo y experimentando una serie de síntomas: cuellos de botella, traspasos lentos, falta de comunicación, desajustes en las herramientas, errores de entrega, exceso de reprocesamiento y conflictos (normalmente del tipo de señalar con el dedo).

Figura 10-2. Silos Los silos describen una forma de trabajar desconectada y no una estructura organizativa específica.

Si ha trabajado en operaciones en una empresa, probablemente reconozca esta condición. Algunos incluso la describen con tristeza como “la forma en que siempre han funcionado las cosas”. Es endémica del modelo clásico de operaciones, en el que hay muchos equipos de especialistas divididos por conocimientos funcionales que utilizan sistemas de tickets y dependen en gran medida de la gestión de proyectos para coordinar el trabajo e impulsarlo a través de la organización.

Los equipos de operaciones no se proponen trabajar en silos ni sufrir sus consecuencias. Suelen ser el subproducto natural de las filosofías de gestión tradicionales basadas en el impulso humano de “optimizar” los esfuerzos a gran escala clasificando a las personas según su especialización funcional, agrupando lo similar con lo similar e incentivándolas para que miren hacia dentro y optimicen.

Las transferencias problemáticas (demasiado lentas, incorrectas, mucho trabajo repetido, etc.) son el problema más citado que puede atribuirse a los efectos de los silos. Esto tiene sentido, ya que los silos sólo se convierten en un problema cuando usted necesita algo de alguien que no pertenece al silo (o alguien que no pertenece al silo necesita algo de usted).

Y recuerde que, en la empresa, nada vive aislado. Hacer algo importante normalmente significa que la información y el trabajo van a tener que cruzar uno o más límites organizativos.

¿Qué es lo que falla cuando el trabajo tiene que pasar entre grupos aislados? Suele tener que ver con desajustes (véase la Figura 10-3):

Desajustes de información
Las partes que intervienen en el traspaso trabajan con información diferente o procesan la información desde puntos de vista distintos, lo que provoca un aumento de los errores y la repetición del trabajo (es decir, la repetición del trabajo debido a errores anteriores).

Desajustes en los procesos
Las partes que intervienen en el traspaso siguen procesos diferentes o procesos que nominalmente son los mismos, pero que tienen un enfoque diferente y producen resultados no esperados por la otra parte. Los desajustes de tiempo y cadencia entre partes de un proceso que tienen lugar en silos diferentes también provocan un aumento de los errores y las repeticiones.

Desajuste de herramientas
Se observa un aumento de los errores y la repetición del trabajo cuando las distintas partes a ambos lados de los límites del silo utilizan herramientas diferentes o herramientas que no están configuradas para conectarse sin problemas. Cuando el trabajo tiene que ser traducido sobre la marcha por una persona que traslada información y artefactos a mano de una herramienta a otra, es inevitable que se introduzcan retrasos, variaciones y errores en el proceso.

Desajustes de capacidad
Los cuellos de botella y los retrasos se producen cuando la cantidad o el ritmo de las solicitudes procedentes de un lado del silo superan la capacidad de quienes las atienden. A menudo, el nivel de solicitudes supera o queda por debajo de lo esperado, lo que tiene el efecto dominó de perturbar la planificación y el flujo de trabajo de otras partes de la organización.

Figura 10-3. Las transferencias entre silos son problemáticas debido a los desajustes

Durante décadas, la contramedida a la que se ha recurrido para solucionar los problemas de traspaso causados por los silos ha sido insertar una cola de solicitudes para gestionar el traspaso (normalmente un sistema de tickets). A primera vista, las colas de peticiones pueden parecer una forma ordenada y eficaz de gestionar el trabajo que atraviesa las divisiones de una organización. Sin embargo, si miramos bajo la superficie, descubriremos que las colas de solicitudes son una fuente importante de despilfarro económico para cualquier empresa. Veamos la siguiente lista, creada por el conocido autor y experto en desarrollo de productos Donald G. Reinertsen, que cataloga el impacto negativo de las colas (véase también la Figura 10-4):⁴⁾

Mayor duración del ciclo Las colas aumentan la duración del ciclo porque se tarda más en llegar al principio de una cola grande que de una pequeña. Incluso los pequeños retrasos pueden agravarse exponencialmente en un sistema complejo e interdependiente como una organización de TI empresarial.

Mayor riesgo Las colas aumentan el tiempo entre la solicitud y el cumplimiento, lo que a su vez aumenta la probabilidad de que cambie el contexto de la solicitud original (una condición de carrera). Si surge un problema, el solicitante se encuentra ahora en una posición mental diferente (a menudo trabajando en otra cosa) de la que tenía cuando hizo la solicitud.

Más variabilidad Las colas más largas conllevan altos niveles de utilización, y los niveles más altos de utilización amplifican la variabilidad. Esto provoca tiempos de espera más largos y una mayor probabilidad de errores.

Más sobrecarga Las colas añaden una sobrecarga de gestión para gestionar la cola, informar sobre el estado y gestionar las excepciones. Cuanto más larga sea la cola, más aumentarán estos gastos generales.

Menor calidad Las colas reducen la calidad al retrasar la información a los participantes en el proceso. Los retrasos en la retroalimentación hacen que el costo de solucionar los problemas sea mucho mayor (por ejemplo, los errores son más fáciles de solucionar cuando se detectan antes) y a menudo significan que se han creado problemas adicionales de origen similar antes de que llegue la primera retroalimentación negativa.

Menos motivación Las colas tienen un efecto psicológico negativo al minar la motivación y la iniciativa. Esto se debe a que las colas (especialmente las más largas) eliminan la sensación de urgencia e inmediatez de los resultados del trabajo del solicitante. Si no se siente el impacto y no se ve el resultado, es propio de la naturaleza humana desconectarse negativamente del trabajo.

Figura 10-4. Se ha demostrado que las colas son económicamente costosas

Si nos fijamos en la ciencia que hay detrás del impacto de las colas, es difícil justificar la inserción de colas en toda la organización. No tiene sentido inyectar voluntariamente en su organización tiempos de ciclo más largos, retroalimentación más lenta, más riesgo, más variabilidad, más gastos generales, menos calidad y menos motivación.

A pesar de ello, ¿cuál es el método más común de gestionar el trabajo en las organizaciones de operaciones de TI? Colas de solicitudes en forma de sistemas de tickets.

Cuando una organización gestiona la interacción entre personas que trabajan en otros silos a través de tickets, está socavando la capacidad de las personas para realizar un trabajo de ingeniería que añada valor, tanto directa (más tiempo de espera, más sobrecarga, más desconexiones, más errores) como indirectamente (más trabajo). Y lo que es peor, gran parte de esta falta de capacidad y del aumento de trabajo está más allá de su capacidad de solución porque la causa está en otro silo.

En las próximas secciones, explicaré cómo eliminar los silos, las colas y los tickets, y cómo evitar sus efectos nocivos allí donde no pueden eliminarse.

Esperamos que la primera parte de este capítulo haya demostrado que la SRE exige un cambio de las condiciones fundamentales que prevalecen en las organizaciones de operaciones empresariales heredadas. Las secciones siguientes exponen los pasos que puede dar para eliminar los obstáculos a una transformación de la SRE.

Como con cualquier transformación, debe favorecer un enfoque de mejora continua. Su organización es un sistema complejo. Las grandes transformaciones de sistemas complejos son arriesgadas y tienen un pobre historial de éxito. Por mucho que planifique de antemano una transformación SRE, lo más probable es que vaya por otros derroteros una vez que empiece a moverse. Anime a su equipo a embarcarse en una serie de acciones constantes y deliberadas.

Las sugerencias del resto de este capítulo no deben considerarse como requisitos previos para pasar a la acción ni como una fórmula definitiva a seguir (es decir, “el único camino verdadero”). Se trata de pautas y lecciones para aplicar de forma continua. Reúna a su nuevo equipo de SRE. Empodérelo para que empiece a transformar su forma de trabajar. Capacite al equipo para traspasar los límites de la organización y colaborar en mejoras que beneficien a todos. Favorezca la acción y la mejora continua.

Si va a transformar el funcionamiento de su organización de operaciones, es mejor que aproveche un conjunto de conocimientos de transformación de eficacia probada. El movimiento de Lean manufacturing ha generado una gran cantidad de patrones y técnicas de diseño⁵⁾ que podemos aplicar para mejorar cualquier proceso de trabajo. En concreto, es el principio de Kaizen (cuya traducción aproximada es “mejora continua”), nacido del Sistema de Producción Toyota, el que acelera las transformaciones e impulsa la capacidad de una organización para aprender continuamente. Para llevar el Kaizen a una organización, existe un método llamado Kata, también basado en el Sistema de Producción Toyota.

Kata es una metodología excelente para aplicar al reto de eliminar el trabajo, los silos y las colas de peticiones. Kata anima a las organizaciones a examinar el flujo de trabajo de principio a fin y a experimentar metódicamente hasta alcanzar el resultado deseado. Se anima a los equipos a ver más allá de su silo de trabajo y a pensar de forma holística sobre los problemas. Kata le ayudará a identificar lo que se interpone en el camino de sus objetivos y luego a mantenerse alineado mientras itera hacia esos objetivos.

Es importante señalar que el Kata consiste en que los equipos se mejoren a sí mismos. La mejora duradera del rendimiento se produce cuando las personas saben cómo solucionar los problemas como parte de su trabajo diario. Los proyectos puntuales o la ayuda externa pueden aportar un beneficio concreto en un momento determinado. Sin embargo, las empresas no se quedan quietas. Continuamente surgen nuevos retos, grandes y pequeños.

Los equipos de SRE deben realizar trabajos de ingeniería para mejorar la fiabilidad y operatividad de los sistemas y reducir el trabajo (liberando más tiempo para el trabajo de ingeniería). Los equipos de SRE, por definición, deben ser equipos de aprendizaje que puedan detectar y solucionar problemas como parte de su trabajo diario. Kata es una referencia excelente para enseñar a los nuevos equipos de SRE a pensar y trabajar así.

El enfoque Kata ya se está convirtiendo en una práctica común en los esfuerzos de Agile y DevOps que buscan mejorar los procesos de desarrollo y entrega. Sin embargo, los procesos de operaciones rara vez se consideran dignos de este esfuerzo, especialmente en las culturas de operaciones heredadas. Este descuido es desafortunado porque la calidad operativa tiene el mismo valor que cualquier otra medida de calidad en su organización. Incluso los procesos de operaciones ad hoc (por ejemplo, los que se producen una sola vez debido a un incidente o a un tipo de evento similar) son procesos que merecen ser estudiados.

Si está considerando pasarse a la SRE, debe asumir que su organización ya conoce el valor de invertir en mejorar el trabajo de operaciones. Si no es así, es necesario que los líderes técnicos y empresariales de su empresa mantengan una conversación sobre el valor.

Hay muchos libros, presentaciones y otros recursos disponibles para profundizar en la práctica de Kata. Recomiendo encarecidamente las obras de Mike Rother⁶⁾ y John Shook⁷⁾. Sin embargo, parte de la belleza de Kata es que no se necesitan muchos conocimientos para iniciar y empezar a ver los beneficios. He aquí una visión general del proceso Kata en un contexto de operaciones:

1. Elige una dirección o un reto. Este es su objetivo direccional de alto nivel. ¿Hacia dónde quiere ir como organización? ¿Cuál es el valor empresarial que debe maximizar? ¿Cuál es el estado ideal del trabajo operativo en su empresa?
   
   Es fundamental que haya consenso sobre cuál es el valor de las operaciones para la empresa y cuáles deben ser los niveles de rendimiento y fiabilidad para maximizar ese valor. Toda la organización (desde los ingenieros de primera línea hasta la dirección) debe saber por qué se están embarcando en esta transformación de la SRE y cómo mejorará el negocio.
   
   Las respuestas no tienen por qué ser demasiado detalladas ni explicar cómo se va a llegar a ese punto. Sin embargo, si las respuestas acaban sonando a tópicos generales o a una vaga declaración de objetivos, es un fracaso (por ejemplo, “Deleitar a los clientes con servicios rápidos y de alta disponibilidad”). Siga intentándolo hasta que la gente tenga una noción decente de hacia dónde tiene que ir la organización y por qué. Debe haber cierto reconocimiento tanto de los resultados operativos mensurables (por ejemplo, reducción de incidentes, mejora de los tiempos de respuesta y aumento de la frecuencia de cambio) como de los resultados empresariales deseados (por ejemplo, aumento de las ventas y mayor puntuación neta del promotor).
   
   
2. Comprender la situación actual. Comprenda claramente cómo funcionan las cosas hoy. Adopte una visión integral del proceso que desea mejorar y esfuércese por comprender cómo se hace realmente en la actualidad. ¿Por qué se hace así? ¿Qué se necesita para hacerlo? ¿Quién es necesario para hacerlo? ¿Qué se interpone en el camino? ¿Cuándo va mal?
   
   Asegúrese de examinar cada uno de los tipos de trabajo de su organización. El trabajo orientado a proyectos es una opción obvia (ingeniería de sistemas, creación de entornos, etc.). También es importante analizar los incidentes (es decir, los escenarios de fallo). Examinar los incidentes como procesos puede sonar extraño, porque los incidentes rara vez siguen un proceso estándar más allá de algunas formalidades de comunicación y recopilación de información. Sin embargo, si se examinan suficientes incidentes, se encontrarán patrones comunes. Los incidentes proporcionan una visión muy esclarecedora de cómo una organización está realmente “programada” para funcionar.
   
   Recuerde que los silos son su enemigo. Hacer este tipo de análisis en privado o limitarlo a un equipo de “expertos” aporta un valor mínimo a su organización. Las empresas son famosas por su compartimentación de la información. Muy pocas personas sabrán cómo se desarrollan realmente los procesos de principio a fin, e incluso ellas no estarán de acuerdo. Seguramente abrirá muchos ojos y escuchará comentarios como “Hmm, no es así como yo pensaba que funcionaba” o “No lo sabía”, incluso de los empleados más veteranos. Sólo por eso merece la pena el esfuerzo.
   
   Haga su análisis abiertamente y fomente la participación del mayor número posible de personas. Busque participantes con conocimientos que puedan aportar. Invite a desarrolladores, gestores de programas y otros equipos de operaciones. Su transformación hacia la SRE tiene más posibilidades de éxito si el mayor número posible de personas tiene una comprensión similar de lo que hay que cambiar.
   
   El análisis visual es una forma muy eficaz de alinear a un grupo de personas, siempre que realicen el análisis visual en grupo. En el mundo de la fabricación física, esto significa ir a la fábrica y observar directamente el trabajo de primera mano. \\ 
   En las operaciones informáticas, la mayor parte del trabajo no se ve. Aparte de algunos artefactos, el trabajo consiste en abstracciones y modelos mentales individuales. Por lo tanto, ir al Gemba en nuestro contexto sólo funciona si se reúne a la gente y se alinean esos modelos mentales lo mejor que se pueda en una sesión de retrospectiva del proceso. La figura 10-5 muestra los resultados de una de estas sesiones. Esta alineación es extremadamente importante porque esos modelos mentales individuales son la lente a través de la cual cada persona de su organización evalúa y ejecuta su trabajo diario.
   
   Figura 10-5. Artefactos de análisis visual creados durante una sesión de retrospectiva del proceso
   ¿Cómo hacerlo? Este análisis visual funciona mejor cuando se examina un proceso cada vez. Elija un proceso (una entrega concreta del trabajo del proyecto o un incidente específico). Reúna a personas que conozcan el proceso de primera mano (lo suficiente para analizarlo de principio a fin). Dibuje lo que ocurrió realmente (céntrese en el flujo de trabajo, con las personas y las herramientas como detalles de apoyo de segundo nivel). Por último, pida a los participantes que identifiquen y discutan los obstáculos. Repita esta operación con suficientes casos del proceso (o grupo de procesos relacionados) hasta que haya un consenso razonable sobre cómo se desarrolla el proceso, por qué se desarrolla (si se trata de un incidente) y qué se interpone en el camino.
   
   Existen otros recursos a los que puede recurrir para desarrollar su técnica de visualización y análisis. El Value Stream Mapping⁸⁾ y la clasificación Lean Waste son muy útiles.
   
   
3. Establezca su siguiente condición objetivo. En este paso se decide el siguiente objetivo de mejora que la organización intentará alcanzar. Una vez más, lo mejor es hacerlo en grupo. Sobre la base del objetivo direccional determinado en el paso 1 y la situación actual descubierta en el paso 2, ¿cuál es el siguiente paso intermedio importante que vamos a intentar alcanzar? Esto es en lo que se va a centrar la organización, por lo que todo el mundo debería ser capaz de articular cómo debería ser cuando se alcance la condición objetivo.
   
   Como aconseja Mike Rother, “fijar las condiciones objetivo no consiste en elegir entre las opciones existentes o las mejores prácticas. Se trata de aspirar a un nuevo rendimiento. Al fijar un objetivo e intentar alcanzarlo, se aprende por qué no se puede. Eso es en lo que se trabaja”.
   
   
4. Experimente para alcanzar el objetivo. Lleve a la organización a un ritmo iterativo de formulación de hipótesis (por ejemplo, “Si pudiéramos parar/arrancar x, se reduciría/aumentaría y en una cantidad z”), probando alternativas (por ejemplo, cambios en el proceso, las herramientas o la organización) y evaluando el resultado. Si el resultado le acerca a la condición objetivo, ponga en práctica lo que se probó y continúe con otros experimentos. Si ve el Método Científico en esto, está en lo cierto. Repita el experimento hasta alcanzar la siguiente condición objetivo.

Durante el paso 4 de este proceso, asegúrese de revisar el paso 2 a menudo para asegurarse de que todo el mundo sigue comprendiendo la condición actual. Asimismo, asegúrese de revisar a menudo la especificación de la siguiente condición objetivo para garantizar que todo el mundo se mantiene alineado.

Cuando alcance la condición objetivo, repita el paso 1 (“¿sigue siendo válido el objetivo?”) y luego los pasos 2 a 4.

Tal y como se ha descrito anteriormente en este capítulo, los silos y los problemáticos traspasos y costosas colas de solicitudes que los acompañan causan un daño considerable a una organización. Por lo tanto, tal vez sea obvio que la primera estrategia para aliviar este problema es deshacerse de tantos silos y traspasos como sea posible.

Las organizaciones con visión de futuro están pasando de una estructura “vertical” tradicional alineada por competencias funcionales a una estructura “horizontal” alineada por flujos de valor o productos. La estructura vertical es la clásica estrategia de división por funciones (desarrollo, control de calidad, operaciones, red, seguridad, etc.). La estructura horizontal comprende equipos interfuncionales que pueden encargarse de todo el ciclo de vida de un servicio.

La idea que subyace a los equipos multifuncionales es que se ocupen de la mayor parte posible del ciclo de vida sin necesidad de transferir trabajo a otros equipos. No hay traspasos significativos ni interrupciones en el contexto, y el trabajo de todos fluye desde un único back-log alineado por prioridades comunes. Se evitan en gran medida los cuellos de botella, los bucles de retroalimentación son más cortos y los tiempos de ciclo son más rápidos. Si surge un problema, es más fácil para un equipo multifuncional responder y rectificar el problema, como se ilustra en la Figura 10-6.

Figura 10-6. Los equipos interfuncionales reducen la necesidad de muchos traspasos

Estos equipos interfuncionales también suelen denominarse equipos orientados al servicio, equipos orientados al producto o equipos orientados al mercado. Estas denominaciones ponen de relieve que el objetivo de estos equipos es la alineación hacia una entrega de valor reconocible por la empresa a un cliente (es decir, un servicio específico identificable por el cliente). Esta alineación permite a los miembros del equipo comprender cómo su trabajo repercute en el negocio y, a continuación, optimizar el equipo para maximizar el valor para el cliente (en lugar de la eficiencia funcional).

Aunque la idea de los equipos interfuncionales parece sencilla, su implantación supone un importante cambio estructural y cultural para las empresas.

Para entender por qué se trata de un cambio tan importante para las empresas, basta con mirar las reglas de la contabilidad corporativa. Hay que reconocer que se trata de un ámbito en el que la mayoría de los ingenieros pensaban que nunca tendrían que profundizar. Sin embargo, algunos conceptos básicos ofrecen una ventana a algunas de las fuerzas más fundamentales que dan forma a una empresa.

La financiación basada en proyectos suele ser el principal flujo de dinero en las TI empresariales. Una vez identificada una necesidad empresarial, existe un proceso para definir un proyecto y financiarlo con un presupuesto específico. Una vez financiado, el proyecto pasa por los distintos silos funcionales de la organización de TI hasta que llega a la fase de producción y se considera terminado. La siguiente iteración suele considerarse un nuevo proyecto con un presupuesto distinto.

La financiación basada en proyectos aumenta la presión sobre las operaciones de varias maneras:

• En primer lugar, la proliferación de servicios e infraestructuras a medida genera una cantidad significativa de trabajo para las operaciones. Cuando una organización está orientada a proyectos, los equipos se desplazan de un proyecto a otro, dejando a menudo tras de sí un rastro de nuevo software y nueva infraestructura. El desplazamiento de los equipos a nuevos proyectos priva a los equipos de aprender de la retroalimentación operativa. Además, como ya se ha comentado en este capítulo, la creación constante de software e infraestructura nuevos y netos (aunque se construyan siguiendo patrones documentados) crea nueva deuda técnica y errores derivados de condiciones desconocidas. Estos comportamientos son fuentes continuas de trabajo para los equipos en los que se descarga la responsabilidad operativa.
• En segundo lugar, en el afán por llegar a la línea de meta de un proyecto, los problemas operativos no siempre se abordan adecuadamente antes de pasar a la fase de producción. Los equipos de entrega son juzgados por haber entregado el proyecto dentro del presupuesto o por debajo de él. Por naturaleza, las cuestiones operativas como la estabilidad, la escalabilidad, la capacidad de despliegue, la configurabilidad, la observabilidad y la capacidad de gestión tienden a recibir un tratamiento superficial o suelen ser lo primero que se recorta en un apuro de tiempo. En el peor de los casos, estas preocupaciones operativas no se tienen en cuenta en absoluto. Aunque los recursos de desarrollo de alto valor se reciclan y reasignan rápidamente a los proyectos, un equipo de operaciones tiene que hacerse cargo de cada proyecto y de su fiabilidad y escala. En un modelo tradicional, se trata de un trabajo continuo que suele requerir más personal. Sin embargo, incluso suponiendo que los equipos de operaciones estén equipados con las habilidades necesarias para realizar el trabajo de ingeniería en un modelo de SRE, estos equipos siguen estando en perpetuo modo de ponerse al día, y la quiebra de la ingeniería es siempre un riesgo si los niveles de trabajo son demasiado altos.
• En tercer lugar, al ser los proyectos el principal vehículo de financiación, los presupuestos operativos se consideran sobre todo gastos de explotación y mantenimiento, u OpEx en la jerga contable. Los OpEx son la categoría presupuestaria que se somete a un mayor escrutinio y control de costos porque afectan directamente a la rentabilidad del año en curso. Los equipos cuya financiación procede en gran medida de OpEx son naturalmente susceptibles a los impulsos de la dirección en favor de la organización por funciones y los mandatos de eficiencia, que fomentan el trabajo en silos.

La mayor parte del trabajo se centra en las operaciones y el mantenimiento, que son OpEx. En general, toda la financiación basada en proyectos es CapEx (gastos de capital). Los trabajos de ingeniería para construir o mejorar un sistema suelen ser CapEx porque mejoran un activo (y pueden amortizarse en varios años, por lo que el impacto negativo en el beneficio del año en curso es menor). Un equipo financiado con un presupuesto de OpEx y gestionado por eficiencia a menudo no tendrá el presupuesto (o los estatutos generales) para realizar un trabajo de ingeniería significativo.

Para pasar a un modelo de SRE, no es necesario ser un experto en contabilidad. Sin embargo, resulta rentable ser muy consciente de cómo fluye el dinero en su empresa. Si quiere que su paso a la SRE sea algo más que un cambio en los títulos de los puestos, tendrá que argumentar que el equipo de SRE debería financiarse para realizar trabajos de ingeniería y estar vinculado a los equipos que se encargan del ciclo de vida del servicio, desde el inicio hasta el desmantelamiento. El paso de la financiación basada en proyectos a la financiación basada en productos (con equipos interfuncionales) ya está ganando terreno en los debates sobre Agile y DevOps. Si esta idea se está abriendo paso en su organización, intente aprovecharla para su transformación en SRE.

En las empresas que experimentan con equipos interfuncionales y SRE se perfilan dos patrones comunes. El primero consiste en que los SRE (y otros roles funcionales) se unan a equipos de producto dedicados. De este modo, se crean equipos multifuncionales que pueden hacerse cargo de un servicio desde su creación hasta su desmantelamiento. El desarrollo y las operaciones en curso se llevan a cabo dentro de estos equipos multifuncionales. Desde el punto de vista empresarial, esto suele considerarse un cambio radical con respecto a los modelos de organización tradicionales. A veces se habla de este modelo como el modelo “Netflix”.

El segundo modelo es que la SRE siga siendo una organización distinta. Los equipos de desarrollo tienen competencias de SRE e inicialmente se encargarán de todo el ciclo de vida de un servicio. Cuando el servicio ha alcanzado un cierto nivel de rendimiento y estabilidad, se produce un traspaso formal a un equipo de SRE con conocimientos de desarrollo integrados. Este equipo de SRE gestiona la disponibilidad y escalabilidad del servicio según los acuerdos de rendimiento alcanzados con los equipos de desarrollo.

Si los cambios realizados por el equipo de desarrollo hacen caer el rendimiento del servicio por debajo de los niveles acordados, existe un mecanismo para devolver más responsabilidad operativa al equipo de desarrollo. Desde una perspectiva empresarial, la forma general de este modelo parece la más familiar. Sin embargo, la forma en que se desarrolla el trabajo en este modelo sigue siendo una desviación radical de los modelos de operaciones tradicionales. A veces se le denomina modelo Google.

Por supuesto, los empleados de Netflix y Google se apresurarán a señalar que hay muchos más matices en ambos modelos. Sin embargo, estas descripciones proporcionan un posible punto de partida de alto nivel para pensar en cómo diseñar un modelo que funcione mejor para las condiciones únicas de su empresa.

Es probable que las opciones disponibles se vean limitadas por la forma en que el resto de la empresa quiera funcionar. Por ejemplo, cambiar por completo la estructura organizativa para pasar a equipos alineados con el producto requerirá la aceptación de al menos los departamentos de desarrollo y gestión de productos (que probablemente necesitarán debates empresariales más amplios). Mantener una división organizativa tradicional entre desarrollo y operaciones tiene la ventaja de no alterar las arraigadas estructuras políticas de la empresa, pero, al mismo tiempo, esas estructuras políticas pueden reforzar las viejas formas de trabajar y socavar involuntariamente los esfuerzos de mejora.

Las técnicas de visualización descritas en el paso 2 del proceso Kata (captar la situación actual) pueden ayudar en los debates sobre cambios en la estructura organizativa. La visualización no sólo ayuda a comprender el flujo de trabajo, sino también a ver cómo influye la estructura organizativa en dicho flujo.

Cualquiera que sea el modelo elegido, se producirá un choque cultural cuando se derriben los muros que separan a los equipos de desarrollo de los de operaciones. Los SRE desempeñan un papel esencial a la hora de aportar conocimientos y experiencia en operaciones a los equipos que tradicionalmente sólo se dedicaban al desarrollo. En el mundo del fitness hay una expresión que dice: “Los grandes abdominales se hacen en la cocina, no en el gimnasio”. Del mismo modo, “Las grandes operaciones empiezan en el desarrollo, no en la producción”. Los SRE desempeñan el papel fundamental de aportar habilidades y disciplina operativas a equipos que antes sólo se dedicaban al desarrollo.

Siempre hay casos en la empresa en los que no se pueden poner todas las habilidades y conocimientos necesarios en equipos interfuncionales. Por razones prácticas, financieras o políticas, la mayoría de las empresas que operan a gran escala no pueden evitar tener equipos de especialistas funcionales. Las redes, las plataformas, la seguridad y la gestión de datos son áreas comunes en las que las empresas dependen de equipos centralizados, ya sea por falta de especialistas o por la necesidad (percibida o real) de centralizar el control.

La presencia de estos equipos de especialistas significa que no se pueden evitar los traspasos durante el flujo normal de trabajo a través de la organización. O necesitas algo de uno de ellos para hacer tu trabajo, o estás en uno de estos equipos especializados donde todos necesitan algo de usted.

Las dependencias entre servicios (una realidad en la empresa) obligan a los equipos a consumir servicios de otros equipos y a hacerles peticiones operativas (por ejemplo, cambios de configuración, comprobaciones de estado, ajustes de rendimiento, coordinación de despliegues y adición de cuentas). Esto crea otra serie de traspasos inevitables.

Como se ha dicho antes, siempre que hay un punto de traspaso y el trabajo tiene que pasar del contexto de un equipo a otro, existe la posibilidad de que se produzcan efectos de silo y se creen problemas.

Como no es posible eliminar todos los traspasos, hay que aplicar técnicas y herramientas para mitigar su impacto negativo. Aplicar la solución tradicional de colas de solicitudes basadas en tickets es caro, tóxico para la organización y sólo debería ser el último recurso.

En su lugar, la solución debería ser desplegar capacidades de autoservicio en esos puntos de transferencia. Estas capacidades de autoservicio deben proporcionar interfaces basadas en pull para todo lo que antes tenía que hacer alguien al otro lado de una cola de solicitudes (investigar problemas de rendimiento, cambiar la configuración de la red/cortafuegos, añadir capacidad, actualizar esquemas de bases de datos, reinicios, etc.).

El objetivo del autoservicio es no estorbar a las personas que necesitan realizar una tarea operativa. En lugar de hacer que alguien rellene un ticket y se siente en una cola de peticiones, se le proporciona una GUI, API o herramienta de línea de comandos para que lo haga por sí mismo, cuando lo necesite. Esta capacidad elimina el tiempo de espera, acorta los bucles de retroalimentación, evita los errores de comunicación y mejora la capacidad laboral de los equipos que antes tenían que atender esas solicitudes, liberándoles de peticiones repetitivas para que puedan centrarse en el trabajo de ingeniería que añade valor.

La idea del autoservicio no es nueva. Sin embargo, el enfoque tradicional del autoservicio consiste en que un equipo de operaciones privilegiado cree “botones” un tanto estáticos para que los equipos menos privilegiados los pulsen (por ejemplo, el botón de despliegue para nuevos archivos .war). Hay un número limitado de escenarios en los que este enfoque estático funciona. Además, sigue dejando al equipo con mayores privilegios como el cuello de botella, ya que son ellos los que tienen que construir -y mantener- el botón y la automatización subyacente. Esta carga de mantenimiento por sí sola limita la cantidad de capacidades de autoservicio estático que una organización de operaciones puede exponer.

Para maximizar la eficacia del autoservicio, es necesario proporcionar la capacidad de definir y ejecutar procedimientos automatizados, como se muestra en la Figura 10-7. Por supuesto, es necesario establecer restricciones para hacer cumplir los límites de seguridad y ayudar a prevenir errores. Por supuesto, es necesario poner restricciones para reforzar los límites de seguridad y ayudar a prevenir errores, pero proporcionar la capacidad de definir y ejecutar proporciona el mayor valor.

Figura 10-7. Tradicional tramitación de solicitudes mediante tickets frente a autoservicio completo

Por ejemplo, pensemos en el servicio Elastic Compute Cloud (EC2) de Amazon Web Services (AWS). La posibilidad de pulsar un botón y obtener una máquina virtual en funcionamiento era interesante. Sin embargo, la capacidad de controlar tu propio destino creando tus propias imágenes de máquina (AMI) y configuración fue revolucionaria. Daba poder a los individuos y permitía a los equipos desacoplarse y avanzar a su propio ritmo. Sin embargo, el acceso no es ilimitado. Los usuarios están limitados por razones de seguridad, tanto por AWS como por sus propias políticas de seguridad. Los usuarios también están limitados en sus opciones para proporcionar “barandillas” para evitar que los usuarios del sistema cometan algunos tipos de errores o afecten al rendimiento de otros usuarios. En este ejemplo, la capacidad de definir y ejecutar la automatización se traslada a los usuarios finales y la gobernanza es compartida por los operadores (AWS en este caso) y los usuarios finales.

Para maximizar el valor del autoservicio en la empresa, reproduzca este patrón de trasladar la capacidad de definir y ejecutar la automatización a cualquier punto de la organización que mejore el flujo de trabajo.

==== El Autoservicio Ayuda a los SRE de Múltiples Maneras ====

Dentro de una empresa, las capacidades efectivas de autoservicio son un impulso para los esfuerzos de SRE. A continuación se enumeran algunas de las ventajas:

Reduce el trabajo
Salvo contadas excepciones, atender solicitudes repetitivas es una tarea ardua. Disponer de capacidades de autoservicio eficaces puede ayudar a los SRE a reducir la carga de trabajo mediante una rápida automatización para reducir esas solicitudes repetitivas. A menudo, las solicitudes repetitivas no siguen el mismo patrón cada vez, y esto puede socavar la capacidad de un SRE para configurar una automatización reutilizable. Si puede configurar las primitivas adecuadas y luego dar a los solicitantes la capacidad y el permiso para crear sus propios procedimientos automatizados, puede crear autoservicio para un conjunto aún más amplio de solicitudes repetitivas. Examinar qué procesos de autoservicio acaban creándose también puede indicar tanto a los SRE como a los desarrolladores dónde deben centrarse sus esfuerzos de ingeniería actuales para reducir la necesidad de intervenciones futuras.

Alivia los problemas de seguridad y cumplimiento normativo
La seguridad y el cumplimiento normativo son hechos inevitables en la empresa. Ya sea como cicatriz organizativa de problemas pasados, como respuesta a los temores del sector o como directiva de un auditor, la transformación de su SRE tendrá que funcionar dentro de los requisitos de seguridad y cumplimiento existentes. No aconsejo tratar de introducir un nuevo modelo de operaciones y cuestionar las políticas de seguridad o cumplimiento existentes. Elija sus batallas.

Las capacidades de autoservicio pueden proporcionar tanto un sistema de registro de la actividad operativa como un punto de aplicación de políticas. Puede utilizar los mismos mecanismos de autoservicio dentro de los equipos y más allá de sus fronteras. Esto le proporcionará tanto la capacidad de realizar un seguimiento de la actividad operativa para cumplir los requisitos de conformidad como una forma de ampliar de forma segura la distribución de los privilegios de acceso. De este modo, los SRE pueden trabajar en un ámbito más amplio de su infraestructura de lo que se permitía anteriormente. Esto también permite a sus colegas que tradicionalmente no trabajan en operaciones participar en la actividad de operaciones sin tener que abrir tickets para que otros lo hagan por ellos.

La separación de funciones es un requisito estándar de la mayoría de las empresas. No importa si es para cumplir normativas específicas (por ejemplo, el requisito 6.4 de PCI DSS) o para satisfacer controles normativos más generales, la separación de funciones puede interferir con los planes de un equipo para asumir la propiedad interfuncional del desarrollo, las pruebas y las operaciones de un servicio.

Las herramientas de autoservicio pueden ayudar proporcionando un mecanismo a través del cual una persona en un rol de desarrollo puede crear un procedimiento que alguien en un rol de operaciones puede examinar y ejecutar rápidamente. Además, quienes desempeñan funciones privilegiadas en operaciones pueden crear capacidades de autoservicio limitadas y preaprobadas que pueden ser ejecutadas a petición por quienes desempeñan funciones no privilegiadas (por ejemplo, funciones de desarrollo o control de calidad). A menudo se puede persuadir a los auditores de que esta forma de autoservicio sigue cumpliendo el requisito de separación de funciones porque el rol de operaciones establece el procedimiento, concede el acceso específico y recibe los registros y la notificación de su uso.

La preocupación por la seguridad también es la culpable de muchas de las solicitudes repetitivas actuales que pueden etiquetarse como tareas. Puramente por motivos de seguridad, actualmente se obliga a la gente a hacer colas y esperar a que alguien haga algo por ellos. El autoservicio, realizado correctamente, ofrece a los solicitantes la posibilidad de actuar por sí mismos. Puede mantener las posturas de seguridad mediante un control de acceso detallado, un registro completo y notificaciones automatizadas.

Mejora la respuesta ante incidentes
Las capacidades de autoservicio son útiles para capturar las mejores prácticas de un equipo en forma de listas de comprobación y runbooks automatizados. Al responder a incidentes, las listas de comprobación pueden mejorar tanto el rendimiento individual como el del equipo. La configuración de listas de comprobación como runbooks automatizados no sólo fomenta la coherencia, sino que también permite que la ejecución de las listas de comprobación -y la observación de los resultados- sea una actividad de grupo.

Maximiza el valor de los servicios y la infraestructura estándar
Se considera una buena práctica que los equipos de SRE dediquen parte de su tiempo de ingeniería a crear y mantener infraestructura estándar (por ejemplo, plataformas y entornos) y servicios de operaciones (por ejemplo, sistemas de despliegue y capacidad de observación). Cuanto mejores sean las capacidades de autoservicio, más podrá aprovechar una organización estos componentes y servicios estándar.

Si se examinan las empresas que emplean un estilo de operaciones de SRE y que son consideradas de alto rendimiento por sus homólogas, se verá que a menudo han creado herramientas a medida para permitir las capacidades de autoservicio. Por ejemplo, fíjese en la combinación de Spinnaker, Winston, y Bolt de Netflix. En un principio, se trataba de herramientas específicas desarrolladas desde cero para la organización específica y específica de Netflix. Las empresas probablemente descubrirán que necesitan capacidades de autoservicio más genéricas para abarcar la heterogeneidad derivada de décadas de adquisición y acumulación.

Las operaciones como servicio (OaaS) son un patrón de diseño genérico y aparentemente sencillo para crear capacidades genéricas de autoservicio de operaciones. La idea básica de OaaS es que es una plataforma para distribuir de forma segura la capacidad tanto de definir como de ejecutar procedimientos automatizados, como se muestra en la Figura 10-8.

Figura 10-8. Visión general del patrón de diseño OaaS

Para el éxito de este patrón de diseño es fundamental que la plataforma sea ligera y funcione con cualquier lenguaje o herramienta de scripting popular. Obligar a los equipos a estandarizar un lenguaje o marco de automatización no es realista, dada la naturaleza heterogénea de las empresas modernas. De hecho, no sólo no es realista, sino que puede ralentizar una organización. Los equipos deben ser capaces de utilizar los lenguajes y herramientas de automatización que deseen (o que hayan heredado), permitiendo al mismo tiempo que otras herramientas orquesten procedimientos a través de esos lenguajes y marcos subyacentes.

El control de acceso y la audibilidad también son fundamentales para el éxito de este patrón de diseño. Para que cualquier solución prospere en la empresa, el control último debe permanecer en manos de las personas y equipos que se considere que tienen un mayor nivel de privilegio de acceso.

Los esfuerzos de OaaS tienen más posibilidades de superar las expectativas cuando se combinan con proyectos de supervisión y observabilidad. Los proyectos de implantación tienden a centrarse en gran medida en la automatización. Sin embargo, cuando el proyecto avanza, muchas organizaciones descubren que carecen de visibilidad de la salud operativa, el estado y la configuración. Metafóricamente hablando, están distribuyendo las llaves del coche sin dar a la gente la capacidad de ver por dónde van. Para evitar este problema, ponga el mismo énfasis desde el principio tanto en “la vista” como en “el hacer”.

El patrón de diseño OaaS debería ser compatible con cualquier modelo operativo de operaciones. Tanto si se está pasando a equipos multifuncionales (Figura 10-9) como si se mantiene una división más cercana a la organización tradicional de desarrollo y operaciones (Figura 10-10), el desarrollo de las capacidades de autoservicio de su organización le reportará beneficios.

Figura 10-9. Patrón de diseño OaaS con un modelo organizativo de equipos interfuncionales

Figura 10-10. Patrón de diseño OaaS con un modelo organizativo más tradicional de desarrollo y división Ops/SRE

Uno de los desarrollos más poderosos del movimiento de la SRE es la popularización de un conjunto de conceptos de gestión que formalizan las expectativas en torno a la actividad operativa de una organización. Para los que trabajan en empresas que tienen un modelo de SRE desde el principio, las siguientes ideas pueden ser evidentes. Para los que trabajan en las operaciones tradicionales de TI de la empresa, estas ideas a menudo ponen de relieve hasta qué punto el modelo de SRE se aleja de las creencias y prácticas tradicionales de las operaciones.

En una organización suele haber tensiones sobre cuánto riesgo es tolerable para un servicio concreto y quién es responsable cuando no se cumplen los Objetivos de Nivel de Servicio (Service-Level Objectives, SLO por siglas en inglés). En las divisiones empresariales tradicionales, se incentiva al extremo de producto de una empresa para que vaya más rápido, y al extremo de operaciones para que evite el tiempo de inactividad y otros problemas de rendimiento. Este es el tipo de desajuste en los incentivos que favorece la formación de silos. ¿Cómo mantener alineados ambos intereses? ¿Cómo conseguir que todas las funciones inviertan tanto en velocidad como en fiabilidad?

Los presupuestos de errores son un marco para medir y utilizar el riesgo permitido. En concreto, es la diferencia entre la fiabilidad teóricamente perfecta y un SLO aceptable acordado por las partes interesadas de la empresa y la tecnología. Los presupuestos de errores proporcionan un marco para negociar con la empresa hasta qué punto es aceptable un fallo y seguir satisfaciendo las necesidades de la empresa.

La metáfora del presupuesto no es casual. Los presupuestos son una representación de la moneda que está disponible para ser gastada. Lo mismo ocurre con los presupuestos de errores. Los desarrolladores y los SRE pueden utilizar ese presupuesto para intentar hacer avanzar la empresa. Si un servicio tiene un presupuesto de errores pequeño, los desarrolladores y los SRE deben ser más conservadores para favorecer la estabilidad. Si un servicio tiene un presupuesto de errores mayor, los desarrolladores y SREs pueden ser más agresivos y favorecer la velocidad y la experimentación en producción. Al igual que con otros tipos de presupuestos, la negociación gira en torno a cómo gastarlo mejor y, en algunos casos, no gastarlo en absoluto (véase la Figura 10-11).

Figura 10-11. El presupuesto de error es la diferencia entre la perfección y el SLO acordado

¿Qué ocurre si se supera el presupuesto de errores? Los presupuestos de errores se asignan a un servicio, no a una función concreta. Todos los roles implicados en el servicio deben respetar el presupuesto. Por ejemplo, si se infringe el presupuesto de errores debido a un cambio agresivo o problemático, los que desempeñan funciones de desarrollo deben adaptar su comportamiento (lo que a menudo incluye asumir más responsabilidad operativa) y adaptar el servicio para que funcione dentro del presupuesto de errores asignado.

Esto contrasta fuertemente con los Acuerdos de Nivel de Servicio (SLA) tradicionales que se encuentran en las operaciones de TI de las empresas. Si se incumplen estos SLA tradicionales, Operaciones (en un papel de proveedor de servicios) incurren en la penalización y Desarrollo (que ya está en su siguiente proyecto) normalmente no. Además, el concepto de indicador de nivel de servicio (SLI; medida de rendimiento cuantificable), un SLO (objetivo de rendimiento) y el presupuesto de errores (cantidad actual por encima del SLO) es más matizado y pragmático que los enfoques tradicionales de SLA. Hay que asegurarse de que los equipos procedentes de culturas de operaciones tradicionales entienden las diferencias.

Los límites de trabajo pesado son otro concepto que desafía el pensamiento tradicional de las operaciones. Ya he explicado por qué el trabajo pesado debilita la función del SRE. Definir un límite en la cantidad de trabajo pesado que debe realizar un SRE individual o un equipo supone una declaración de prioridades y protege la capacidad de un individuo o un equipo para realizar un trabajo de ingeniería.

Los límites de trabajo pesado también son indicadores de la salud de un equipo. Si el trabajo pesado de un equipo supera un umbral predeterminado (por ejemplo, el límite por defecto de Google del 50% de la capacidad de un ingeniero), la organización puede movilizarse para encontrar formas de ayudar a rectificar la situación. Al igual que los presupuestos de errores, los límites de trabajo ayudan a los SRE a llegar a un acuerdo sobre el comportamiento esperado, proporcionan señales claras cuando se necesita ayuda y evitan ser invadidos por trabajo repetitivo que no añade valor. En una cultura tradicional de operaciones de TI, los equipos rara vez tienen este tipo de protecciones.

El concepto de trabajo pesado está en gran medida ausente de la cultura tradicional de operaciones empresariales (a pesar de los altos niveles de lo que ahora se puede identificar como trabajo pesado). Para las personas que trabajan en organizaciones modernas inspiradas en la SRE, el trabajo pesado es algo malo. El impulso es encontrar formas de eliminarlo, y sus colegas apoyan el esfuerzo. En la cultura empresarial tradicional, el trabajo pesado se considera, en el mejor de los casos, un elemento que “está bien arreglar” y, en el peor, simplemente se acepta.

Cuando introduzca límites al trabajo pesado, tendrá que educar a su gente para socializar el concepto de trabajo pesado y hacerles entender por qué el trabajo pesado es destructivo tanto para el individuo como para la organización.

Aunque DevOps fue en su día dominio exclusivo de las startups, se ha convertido en un ideal aceptado en la mayoría de las empresas. Nacido en 2009, DevOps es un amplio movimiento cultural y profesional centrado en “la calidad, fiabilidad, estabilidad y seguridad de primera clase a un costo y esfuerzo cada vez menores; y la aceleración del flujo y la fiabilidad en todo el flujo de valor tecnológico”⁹⁾.

Los objetivos de DevOps y SRE se solapan bastante. También hay bastante solapamiento entre los fundamentos teóricos de DevOps y SRE. Benjamin Treynor Sloss, el líder de Google que acuñó por primera vez el término SRE y presidió la codificación de las prácticas SRE de Google, ve un claro solapamiento entre DevOps y SRE:

Se podría considerar que DevOps es una generalización de varios principios básicos de SRE a una gama más amplia de organizaciones, estructuras de gestión y personal. De forma equivalente, se podría considerar la SRE como una aplicación específica de DevOps con algunas extensiones idiosincrásicas. ¹⁰⁾

Dentro de la empresa, DevOps se ha aplicado más a menudo al ámbito limitado que comienza con el desarrollo de software y se mueve a través de la tubería de prestación de servicios (desde la comprobación del código fuente hasta el despliegue automatizado). En estas empresas, la penetración de la transformación DevOps es mínima más allá del despliegue y el grueso de las prácticas de operaciones se ha mantenido sin cambios. SRE es una oportunidad para aprovechar el impulso iniciado por DevOps y continuar los esfuerzos de transformación a lo largo del resto del ciclo de vida posterior al despliegue.

Recomiendo buscar el impulso de DevOps en su organización y alinear sus esfuerzos de transformación de SRE. Hay lecciones que cada uno puede aprender del otro. Trabajar tanto Dev-hacia-Ops (DevOps) como Ops-hacia-Dev (SRE) dará a la transformación de su empresa la mejor oportunidad de éxito.

El concepto de trabajar a partir de un único backlog bien gestionado y de proteger la capacidad de un equipo no comenzó con el movimiento SRE. Ambos son conceptos Lean fundamentales para mejorar el flujo de trabajo y son populares en las comunidades Agile y DevOps. Estos conceptos son mucho menos frecuentes en las culturas de operaciones tradicionales, pero pueden ser extremadamente útiles para gestionar el trabajo de -y proteger- a los equipos en transición hacia la SRE.

El trabajo de SRE, por definición, es una mezcla de trabajo planificado y no planificado. Esta mezcla de tipos de trabajo es una de las más difíciles de gestionar. El trabajo planificado y el no planificado son modos de trabajo diferentes y no se mezclan bien. Además, el hecho de que cada tipo de trabajo tenga un retraso diferente empeora aún más las cosas. Es como servir a varios amos al mismo tiempo. Es fácil ser arrastrado en demasiadas direcciones o ser completamente atropellado por las demandas que compiten entre sí.

Los ingenieros que trabajan en organizaciones tradicionales de operaciones informáticas suelen tener varios proyectos pendientes con distintas fuentes de trabajo gestionados de diferentes maneras. Hay un sistema a través del cual les llega el trabajo de un proyecto formal. Luego puede haber otra forma en la que el equipo mantiene un backlog y gestiona el trabajo de ingeniería que no llega a un proyecto formal. Y, por supuesto, hay otra forma de gestionar las solicitudes que se interrumpen, como las incidencias.

El paso de cada equipo a un único backlog unificado (planificado + no planificado) da sus frutos. En lugar de la tensión constante entre el valioso trabajo planificado y el necesario trabajo no planificado, los backlogs unificados dejan claras la priorización y las compensaciones. También facilitan la reserva de capacidad para el trabajo no planificado (en realidad, otro tipo de “presupuesto”).

Kanban es una metodología de gestión que incluye ideas como los backlogs unificados y la capacidad protegida. Se ha demostrado que Kanban mejora significativamente el flujo de trabajo en organizaciones con tipos de trabajo mixtos. Los escritos y presentaciones de Dominica DeGrandis, autora y experta en Kanban desde hace mucho tiempo, son un buen punto de partida, ya que es una de las pioneras en la aplicación de Kanban a las organizaciones de operaciones.

Ahora puede parecer de sentido común que optimizar el rendimiento de sus activos más importantes, su personal, es fundamental para el éxito de cualquier empresa tecnológica. Sin embargo, no siempre ha sido así. Si lleva suficiente tiempo en el sector de las operaciones de TI, habrá visto culturas de operaciones tradicionales que trataban a su personal como engranajes intercambiables. Si un engranaje se desgastaba, ¡es que no había sido lo suficientemente resistente! Si la máquina se rompía, la culpa era de un engranaje. Los engranajes no son más que piezas, así que busque en otra parte el proveedor de engranajes más barato.

Si quiere construir una organización altamente eficaz y dinámica, necesita una cultura que permita a sus empleados asumir riesgos razonables, comunicar malas noticias a sus superiores, ser creativos y apoyar a sus compañeros. La seguridad psicológica y los factores humanos¹¹⁾ son campos de estudio relacionados que van mucho más allá de las TI, pero que tienen mucho que ofrecer a nuestro sector. Desde los análisis de catástrofes aéreas hasta las tragedias médicas, existe un corpus de conocimientos reutilizable sobre cómo maximizar el rendimiento humano en situaciones estresantes y complejas.

Estamos trabajando en un momento único en la historia de las operaciones de TI. Aunque a menudo obtenemos nuevas tecnologías y herramientas, rara vez tenemos la oportunidad de remodelar la estructura, los comportamientos y la cultura de las operaciones. Esta es una oportunidad para mejorar la vida laboral de los profesionales de operaciones de todo el mundo y mejorar los resultados para sus empleadores.

La SRE es un movimiento dirigido por profesionales en continua evolución. Lo mejor de un movimiento dirigido por profesionales es que usted puede formar parte de él. Ya sea en línea o en persona en conferencias o reuniones, únase a él.

Como en la mayoría de las TI, los primeros en adoptarlo y promoverlo no suelen ser empresas. No dejes que esto te disuada. En primer lugar, las lecciones aprendidas y los principios debatidos son más aplicables de lo que se piensa. En segundo lugar, puede que las empresas no se apresuren a adoptar nuevas prácticas, pero a medida que aumente la aceptación por parte de la comunidad, la adopción por parte de las empresas irá en aumento. Involucrarse pronto en la SRE es una forma de preparar sus habilidades y hacer que su empresa sea más competitiva.

No importa si aprende de las experiencias de otros profesionales o si valida lo que ha aprendido compartiendo sus experiencias, su participación le reportará más valor que el esfuerzo que haya invertido.

Ahora, arremanguémonos y pongámonos manos a la obra.

Damon Edwards es cofundador de Rundeck Inc, los creadores de Rundeck, la popular plataforma de gestión de operaciones de código abierto. Anteriormente, Damon fue socio director de DTO Solutions, una consultora de DevOps y mejora de operaciones de TI centrada en grandes empresas. Damon es ponente habitual en conferencias, escritor y presentador de podcasts.

Volver al índice