8. Introducción de la SRE en las grandes empresas

Sriram Gollapalli, Agilent Technologies

Este capítulo describe mi historia de cómo una empresa emergente de Software como Servicio (SaaS) adquirida (fundada en 2006) introdujo la SRE en una gran empresa (fundada originalmente en la década de 1930), incluidos los desafíos y las oportunidades de que los equipos tradicionales de TI, operaciones, soporte/calidad y las distintas divisiones de ingeniería de productos trabajen conjuntamente. Está dirigido a directivos que entienden que la SRE es lo que su organización y sus productos necesitan, pero que se esfuerzan por determinar cómo poner en práctica estas ideas. Esto fue adaptado de una charla que di en SRECon17 Europe en el verano de 2017 en Dublín, Irlanda.

Calidad significa hacerlo bien cuando nadie está mirando. Henry Ford

Como cofundador de una pequeña startup de SaaS, unirme a una gran organización fue una experiencia emocionante para mí. Nuestro equipo estaba entusiasmado por compartir nuestros conocimientos y aprovechar los recursos y la infraestructura que esta empresa más grande podía proporcionar para expandir nuestro negocio. Nuestra startup aprendió que la estructura matricial -en la que los grupos tienen relaciones duales de información, por función y también a las líneas de producto- puede ser tanto flexible como desafiante a la hora de introducir nuevos paradigmas.

Nuestra organización, Agilent Technologies, tiene profundas raíces en Silicon Valley desde finales de la década de 1930. Como gran fabricante de instrumentos con productos de software principalmente retractilados, tradicionalmente hemos entregado el software grabando CD y DVD y enviándolos por correo, con versiones importantes cada 12 a 24 meses. Como nuestros clientes están empezando a aceptar más la entrega electrónica de sus productos, hemos introducido parches y actualizaciones descargables, pero las limitaciones de tamaño siguen haciendo que el envío sea a veces más eficiente.

A medida que Agilent adquiere empresas SaaS e introduce productos SaaS, la integración continua y las canalizaciones de despliegue ofrecen conductos evolutivos para la entrega, que desafían los procesos tradicionales y las estructuras y funciones organizativas. Organizaciones como el Servicio Postal de los Estados Unidos y FedEx solían ser la única fuente de fiabilidad de nuestros lanzamientos de productos de software. A medida que la entrega en la nube se hace más omnipresente, tenemos que ser esa fuente. Se convierte en un componente integral de nuestra promesa de marca y de la experiencia del cliente.

Es importante comprender que, fundamentalmente, la SRE es un vehículo para mantener y mejorar la salud de los productos orientados al cliente al tiempo que se aumenta la velocidad de la ingeniería de software. Este mensaje resuena entre los ejecutivos y ayuda a abogar por recursos dedicados a la SRE. Para introducir la SRE, utilizamos el siguiente enfoque, que puede ver en la Figura 8-1.

Figura 8-1. Pasos para implantar la SRE en una empresa.

Para determinar dónde encajará la SRE en el futuro y cómo presentar el caso de negocio a su liderazgo, tiene que empezar por comprender la estructura organizativa. Hay muchos componentes a tener en cuenta a la hora de evaluar las capacidades actuales y las posibles carencias.

Las empresas típicas tendrán funciones centrales como las siguientes

• Tecnología de la información/TI central/sistemas de información/servicio de asistencia técnica

• Soporte y servicios de productos

• Operaciones globales

Dada la combinación única de conjuntos de habilidades necesarias que abarcan múltiples grupos, la naturaleza interfuncional de la SRE presentará un desafío inicial para determinar dónde posicionar la SRE en la organización. Hemos realizado encuestas informales entre nuestros colegas de grandes empresas similares: no siempre hay un lugar claro para el grupo. Para determinar la mejor estructura organizativa, identifique a los líderes y/o ejecutivos en posiciones de liderazgo para calibrar su experiencia operativa y su apetito por adoptar un nuevo enfoque de las operaciones. Esto será importante más adelante para la formación en SRE y para compartir los argumentos empresariales. Algunos ejemplos podrían ser el CIO, el Director de Operaciones, el Director de Soporte, el Director de la Nube o el Director de Ingeniería. Es posible que uno de estos grupos encaje de forma lógica en el que su equipo de SRE pueda incubarse.

Imagínese este escenario: su sprint tiene historias bien planificadas con definiciones coherentes de hecho, backlog preparado, pruebas de aceptación aprobadas - es un sprint planificado a poca distancia de la finalización con un amplio margen para incidentes no planificados. Es martes por la tarde, te estás preparando para sumergirte en otra sesión de codificación enfocada, y recibes una llamada de tu equipo de soporte: “Oye, estoy recibiendo tickets de clientes que no pueden añadir artículos a su carrito de la compra, ¿podrías echarle un vistazo?”.

¡Puf! Cualquier esperanza de alcanzar los objetivos y la velocidad del sprint se esfuma mientras te centras en intentar averiguar qué ha pasado.

¿Te suena familiar?

El cambio de contexto reduce cada vez más la eficacia en la entrega de tareas. El primer elemento de su caso empresarial puede centrarse en el hecho de que, sin recursos de SRE, los recursos de ingeniería tradicionales no pueden centrarse en las mejoras y ampliaciones de productos prioritarias para la empresa.

Recopile historias de sus equipos de soporte, ventas, marketing y otros equipos orientados al cliente sobre cómo el departamento de ingeniería podría haber completado los productos de forma más eficiente y estimaciones de alto nivel del tiempo perdido analizando interrupciones o incidencias.

En las grandes organizaciones con múltiples productos (en la nube o de otro tipo), es probable que haya varios recursos o incluso equipos con responsabilidades similares a las de SRE. La colaboración entre estos recursos puede dar como resultado el intercambio de conocimientos y el ahorro de costos al concentrar estos esfuerzos de forma centralizada. Los distintos recursos de la organización podrían estar definiendo y desarrollando procesos y herramientas similares. Identifique estos recursos y calcule el costo de los esfuerzos de trabajo redundantes.

Para establecer una hoja de ruta sobre los productos de los que se encargará la SRE, estudie el panorama actual de la infraestructura.

Cuando empezamos a identificar los tipos de productos que se beneficiarían de un compromiso de SRE, recopilamos información sobre las huellas tecnológicas en las que se basaban los productos. Vimos una gran variedad, desde un producto listo para lanzar a la nube con servidores en copo de nieve repartidos, hasta un producto con una compleja arquitectura Windows y dependencias que tenía un historial de fallos y un ecosistema frágil (versiones del sistema operativo sin soporte, soporte limitado de proveedores, etc.). No subestime la complejidad de poner en funcionamiento un entorno existente e inclúyalo en su evaluación.

Una vez que comprenda el entorno actual, comience a mantener conversaciones y a construir la historia de lo que la SRE significará para su organización y el impacto que puede tener.

Como se ha indicado en la sección anterior, los líderes pueden ser el director de información, el vicepresidente de operaciones, el vicepresidente de soporte y el vicepresidente de ingeniería. Empezamos con conversaciones individuales para comprender las responsabilidades actuales y los puntos débiles que experimentaba cada grupo. Aprovechamos este tiempo para identificar y adaptar la historia de cómo la SRE podría mejorar cada una de sus áreas funcionales.

Como habíamos hecho los deberes y conocíamos la situación de nuestros productos, iniciamos estas conversaciones compartiendo un análisis de alto nivel de nuestro estado actual y de los distintos modelos de entrega de productos (véase la figura 8-2). Aprovechamos esta oportunidad para presentar los conceptos de entrega en la nube y en qué se diferencian del software tradicional empaquetado.

Figura 8-2. Tipos de productos de software y su método de entrega (los puntos representan un único producto).

En ese contexto, hablamos de la evolución de los modelos de entrega y funcionamiento, que empezaron con los administradores de sistemas tradicionales que solían estar en un departamento de TI central. Aunque nuestra organización no aspiraba a convertirse en el próximo unicornio de SaaS ni en el próximo producto de las redes sociales, el uso de ejemplos de Google, Netflix, etc., nos ayudó a mostrar cómo los modelos de entrega del sector estaban cambiando para integrarse más con las organizaciones de ingeniería (véase la figura 8-3). Esto nos sirvió para destacar las diferencias entre los paradigmas operativos tradicionales y la falta de un hogar obvio en una organización.

Figura 8-3. Evolución de los modelos de entrega de software.

Esto nos llevó a definir los principios clave de la SRE adaptados a Agilent:

• El equipo de SRE gestiona servicios de producción -un conjunto de sistemas relacionados, operados para nuestros clientes, que pueden ser internos o externos- y este equipo es responsable en última instancia de la salud de estos servicios.

• Operar con éxito un servicio conlleva una amplia gama de actividades:
  • Desarrollo y aplicación de sistemas de supervisión del rendimiento, la disponibilidad, la latencia y la eficiencia.
  • Planificación de la capacidad, gestión de servidores, recuperación en caso de catástrofe
  • Respuesta a incidentes de emergencia, garantizando que se abordan las causas de las interrupciones.
  • Trabajar estrechamente con el equipo de producto en la gestión de lanzamientos
  • Establecimiento y cumplimiento de objetivos de disponibilidad

• Cuando los SRE se comprometen con un servicio, el objetivo es mejorar el servicio a lo largo de estos elementos (mejora del tiempo de resolución de respuesta a incidentes, aumento de la disponibilidad, etc.), lo que facilita la gestión de los entornos de producción para el servicio.

• Los SRE representan el interés del usuario en que el producto de software esté siempre disponible y en funcionamiento.

• El objetivo de los SRE es permitir que los recursos de ingeniería tradicionales se centren en el producto y aumenten la velocidad.

Al principio, algunas de ellas parecían contraintuitivas y se solapaban con nuestras funciones actuales (por ejemplo, el soporte de infraestructuras de TI o el soporte de productos). Sin embargo, tras nuevas conversaciones, quedó más claro que la SRE es una función única que interactúa con los grupos y recursos de ingeniería de software mucho más estrechamente que los grupos de soporte empresarial tradicionales en el pasado.

Además, las funciones actuales no tenían la capacidad o los conocimientos técnicos para asumir productos dispares con el nivel de detalle necesario para respaldar una experiencia saludable.

Armados con estas definiciones y resumen, programamos reuniones individuales con cada uno de los líderes previamente identificados y los guiamos a través de los conceptos y fundamentos de la SRE. Esta formación resultó ser clave para permitirnos presentar un argumento comercial para financiar un equipo y seguir adelante.

Como habíamos pasado varios meses preparándonos con las partes interesadas, concluimos esta fase con una reunión de un grupo grande en la que resumimos la oportunidad y la presentamos como un caso de negocio. En esa reunión, presentamos la siguiente historia:

• Los retos/problemas empresariales actuales a los que nos enfrentábamos

• Los gastos/esfuerzos actuales en funciones similares pero no cohesionadas.

• Descripción del enfoque de incubar la función SRE bajo nuestra dirección técnica

• Impacto positivo potencial en las operaciones/fiabilidad

Calendario e hitos propuestos para rentabilizar la inversión

En este punto, el caso de negocio y el “por qué” estamos haciendo SRE deben ser respondidos. Ahora viene el “cómo”. Empiece por fijar objetivos y dotar de personal al equipo. Identifique los tipos de recursos que ya están haciendo este tipo de trabajo para el producto o productos de los que es responsable, e intente separarlos en un grupo distinto aparte de sus obligaciones de ingeniería para que ahora puedan centrarse en las responsabilidades de SRE.

Dado que probablemente se trate de un equipo único en la organización, es importante definir, medir e informar a las partes interesadas sobre métricas y actualizaciones coherentes. Un buen punto de partida para medir el éxito de su implementación de SRE son las Cuatro Señales Doradas de Google: tráfico (número de solicitudes por minuto), errores (número de incidentes/errores por día, por producto), saturación (número de web workers activos) y latencia (número de tiempos de espera o duración de la carga de la página). La supervisión de estos factores puede influir en la medición general del tiempo de actividad del producto.

Puede resultar tentador contratar a proveedores para que se centren en la fiabilidad y la entrega de su producto (de hecho, puede que ya sea el caso en su organización) para añadir más cobertura global, conocimientos redundantes, apoyo, etcétera. Al fin y al cabo, se trata de una “función de apoyo”, ¿no? En general, no sería prudente.

Aunque al principio pueda parecer conveniente y de menor riesgo, descubrimos que uno de nuestros productos dependía demasiado de proveedores para una función de apoyo similar. Un día, el proveedor sufrió una rotación interna e intentó gestionar la transferencia de conocimientos entre su personal con un sustituto. La transición del proveedor fue un reto para nosotros porque estaba fuera de nuestro control y el sustituto no tenía los conocimientos profundos que tenía el recurso anterior sobre nuestros productos. Y lo que es más importante, nos dimos cuenta de que ni siquiera teníamos los detalles necesarios para hacernos cargo de la asistencia: nuestros conocimientos específicos sobre los productos se habían externalizado por completo.

Cuando se está empezando a implantar la función de SRE, invertir en un conjunto de empleados dedicados con conocimientos específicos del dominio del producto resultará muy valioso. La rotación de proveedores y el tiempo necesario para la transferencia de conocimientos en los sistemas de producción son dos razones por las que utilizar proveedores como miembros clave de su equipo puede resultar complicado a largo plazo. Cuando se está empezando, los proveedores pueden añadir costos y tiempo para tener una función de SRE coherente y fiable. Usted quiere centrar sus esfuerzos en la creación de capacidades y experiencia internas, no preocuparse por la gestión de una operación de externalización.

Entre los casos en los que los proveedores podrían funcionar se incluyen aquellos en los que desee ampliar las operaciones de SRE, después de que los procesos estén bien documentados y necesite añadir triaje de primer nivel para obtener capacidad adicional.

Un atributo de los miembros del equipo de SRE de éxito es que están estrechamente vinculados al proceso de ingeniería y desarrollo. Este tipo de experiencia y conocimiento profundo de la arquitectura del producto convierte a los miembros actuales del equipo de ingeniería en un gran embudo de recursos. Una forma de reclutar suavemente mientras se difunde la mentalidad de la SRE por toda la organización es trabajar con la dirección de ingeniería para rotar a los miembros del equipo de ingeniería en el equipo de SRE. Encuentre un plazo que funcione para su organización; de dos a tres meses suele funcionar bien. Le sorprenderá descubrir que a veces ya existen recursos para realizar este trabajo en las divisiones de software de los productos. Cuando los incorpore a un equipo central, estarán más expuestos a la cartera de productos más amplia y se beneficiarán de todo el intercambio de conocimientos.

Una vez establecido el equipo, es importante empezar a involucrarse con los equipos de producto durante todas las partes del ciclo de vida de desarrollo del producto, como se describe en la Figura 8-4. La función de la SRE será más eficaz cuanto antes pueda involucrarla en cada producto. La función de la SRE será más eficaz cuanto antes pueda involucrarla en cada producto. Informar y educar a los equipos de ingeniería, marketing de producto y soporte dará como resultado unas relaciones y una implementación más exitosas de la función SRE.

Figura 8-4. Responsabilidades, ejemplos de actividades y beneficios de la participación de la SRE en cada etapa del ciclo de vida de desarrollo del producto

Como dice Matt Klein, ingeniero de software de Lyft, “los SRE deben integrarse en los equipos de producto, sin depender del director de ingeniería del equipo de producto. Esto permite a los SRE hacer scrum con su equipo, ganarse la confianza mutua y mantener los controles y equilibrios adecuados para que pueda tener lugar una conversación real cuando se trata de sopesar la fiabilidad frente a la funcionalidad”.¹⁾

Un componente final del éxito de la implantación será comprender cómo la SRE aprovechará, dependerá y mejorará las divisiones y funciones existentes en la empresa. He aquí algunos ejemplos de interacciones y relaciones que podrían funcionar:

• Tecnología de la información/TI central/sistemas de información/centro de ayuda
  Es probable que estos grupos sean responsables de las capas de infraestructura (es decir, red, centros de datos, seguridad corporativa), así como de gestionar los centros de operaciones de seguridad de la empresa y los centros de operaciones de red. Asegúrese de tener definidos los puntos clave de contacto y las responsabilidades para evitar la duplicación de esfuerzos.

• Soporte y servicios de producto.
  Este grupo normalmente tendrá la primera línea de soporte de cara al usuario, llamadas y procesos definidos de gestión de incidentes. Del mismo modo, invierta tiempo en presentar al equipo de SRE y sus capacidades. Utilícelo cuando establezca un proceso de escalado y un traspaso fluido para minimizar la confusión. Este grupo también puede ser ideal para gestionar las comunicaciones de cara al cliente en medio de los incidentes. Será un socio fuerte en el éxito de su implantación.

• Operaciones globales.
  Este grupo podría tener tableros centralizados que los ejecutivos ya están acostumbrados a revisar. Asóciese con ellos para incorporar en sus comunicaciones métricas y estadísticas de SRE de los productos que está supervisando.

Interactuará constantemente con este tipo de divisiones; no replique esfuerzos ni conocimientos institucionales. Al aprovechar estos recursos y funciones existentes, tendrá la oportunidad de impulsar su función de SRE. Tómese el tiempo necesario para comprender estas capacidades y busque los puntos de intersección.

A continuación se exponen algunas lecciones que aprendimos durante el proceso de introducción de la SRE en nuestra organización:

• Desafíe el statu quo.
  Puede que no resulte evidente de inmediato que la SRE es la respuesta adecuada para su organización. No tema presentar la SRE como una metodología para abordar los problemas a los que se enfrenta. La mezcla única que combina ingeniería, operaciones, TI y habilidades de soporte en una oferta cohesiva para productos de próxima generación puede ser compleja de comunicar. Tuvimos la suerte de trabajar con directivos con visión de futuro que adoptaron nuevos modelos de entrega de productos. No se duerma en los laureles y trate de encajar las responsabilidades de la SRE en las funciones existentes: utilice ejemplos del sector y siga defendiendo sus argumentos.

• Invierta tiempo en comprender sus estructuras organizativas.
  Tanto si está en una división pequeña como si se sienta al lado del CIO, dedique un momento a ponerse en el lugar de los líderes y defina dónde cree que encajaría una función de SRE. Si no resulta evidente de inmediato, trabaje con la dirección para introducir el concepto tal y como se ha descrito. El cambio es posible; después de alinear el apoyo ejecutivo y probar el caso empresarial, debería tener luz verde para incubar un grupo de SRE. Además, establezca contactos con los directivos clave. Necesitará su apoyo para introducir la SRE.

• Enmarcar la introducción de la SRE en torno a una estructura de caso de negocio.
  El caso de negocio resonará con los ejecutivos y proporcionará un enfoque natural a la conversación con el liderazgo de la organización. Es imperativo que usted tenga los conocimientos técnicos para apoyar por qué la SRE es lo que su organización necesita, pero destilar en un caso de negocio puede ser eficaz.

• Establecer límites y centrarse.
  Una vez establecido el grupo, es imprescindible fijar los límites de lo que puede ofrecer. Empiece poco a poco y céntrese en la fiabilidad de unos pocos sistemas de producción. Cuando tenga éxito, podrá ampliar y crear un centro de excelencia compartido. Nos consideraban el “chico nuevo del barrio”, y distintos grupos acudían a nosotros pidiendo ayuda para mejorar la fiabilidad de sus sistemas. Era tentador añadir más productos a nuestro ámbito de actuación; sin embargo, nos dimos cuenta de que teníamos que centrarnos primero en nuestro conjunto original de prioridades. Después de contar con una buena infraestructura y un conjunto de procesos probados, el siguiente paso natural será ampliar y añadir más productos a las responsabilidades del grupo de SRE.

Una vez que haya creado y financiado su equipo, aquí tiene algunos ejemplos de actividades para empezar con un solo producto:

• Trimestre 1 (Q1)
  • Planificar el tablero de mandos general
  • Decidir las herramientas de supervisión de la disponibilidad y de los errores
  • Decidir las herramientas de gestión de incidencias
  • Decidir el sitio de estado de cara al cliente
  • Identificar el plan de rotación de guardia
  • Reducir el ruido de las herramientas de supervisión existentes (N/A si no hay supervisión actualmente)
  • Definir los SLO que desea supervisar
  • Investigar herramientas de mejora continua/despliegue continuo
  • Aplicar la rotación de guardia 12×5

• Trimestre 2 (Q2)
  • Creación y puesta en marcha del tablero de instrumentos
  • Implantación de la herramienta de supervisión de la disponibilidad en los entornos de producción
  • Implantar la rotación de guardia 18×5
  • Estandarizar las configuraciones de los entornos
  • Despliegue automático en entornos
  • Despliegue autoservicio de sistemas de producción a través de la interfaz de usuario
  • Implantar la supervisión de errores en todos los entornos
  • Supervisar y gestionar los presupuestos de errores: coordinación con los equipos de marketing de productos.
  • Integrar el sitio de estado orientado al cliente en la supervisión y el chat interno (Slack, Stride, etc.)

• Trimestre 3 (Q3)
  • Llevar a cabo pruebas de recuperación ante desastres/planificación de la continuidad del negocio (asegurarse de documentar y probar los objetivos de tiempo de recuperación y los objetivos de punto de recuperación).
  • Experimentar con la gestión de contenedores y la orquestación de contenedores (a medida que los productos se vuelvan más complejos con microservicios, será importante comprender los contenedores como vehículo de entrega).
  • Investigar tecnologías y prepararse para el despliegue de microservicios realizando pruebas piloto de despliegue de aplicaciones.
  • Confirmar que el entorno cumple los objetivos de resistencia y alta disponibilidad para los componentes clave de la infraestructura.
  • Formalizar la aprobación en el proceso del ciclo de vida de desarrollo del producto, como se describe en la Figura 8-4.

• Trimestre 4 (Q4)
  • Investigar y probar herramientas de análisis predictivo a partir del análisis de registros.
  • Implantar una rotación de guardia 24/7

Buena suerte en la introducción de la SRE en su empresa. La SRE tiene un futuro apasionante tanto en las pequeñas como en las grandes organizaciones.

• Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, de Nicole Forsgren, Jez Humble y Gene Kim (IT Revolution Press, 2018).

• Increment On-Call

• Starting and Scaling DevOps in the Enterprise

, de Gary Gruver (BookBaby, 2016)

• Ideas sobre métricas

• Conjuntos de habilidades para los miembros exitosos del equipo SRE

• Plantillas para la gestión de incidencias

Sriram Gollapalli lleva más de 15 años diseñando, desarrollando e implementando productos y soluciones SaaS empresariales. Fue cofundador y COO/CTO de iLab Solutions, un SaaS empresarial centrado en el mercado sanitario que Agilent adquirió en el verano de 2016. Antes de eso, pasó varios años como consultor en Deloitte Consulting centrándose en soluciones estratégicas de tecnología empresarial y en Intel como ingeniero de sistemas. Sriram es licenciado en Informática y tiene un máster en gestión de sistemas de información por la Universidad Carnegie Mellon.

Volver al índice