Prólogo II

Andrew Clay Shafer

Cuando me enteré de que la gente estaba trabajando en un segundo libro de SRE, me acerqué y pregunté si podía escribir unas palabras. Los principios del primer libro de SRE se alinean muy bien con lo que siempre imaginé que era DevOps, y las prácticas son perspicaces, incluso cuando no son 100% aplicables fuera de Google. Después de leer los principios del primer libro de SRE por primera vez -aceptar el riesgo (Capítulo 3), objetivos de nivel de servicio (Capítulo 4) y eliminar el trabajo duro (Capítulo 5)- quería gritar ese mensaje a los cuatro vientos. “Asumir el riesgo” resonó tanto porque había utilizado un lenguaje similar muchas veces para ayudar a las organizaciones tradicionales a motivar el cambio. El capítulo 6 fue siempre un objetivo implícito de DevOps, tanto para dejar a los humanos más tiempo para el trabajo creativo de orden superior como para permitirles ser más humanos. Pero realmente me enamoré de los “objetivos de nivel de servicio”. Me encanta que el lenguaje y el proceso creen un contrato desapasionado entre las consideraciones operativas y la entrega de nuevas funcionalidades: el SRE, el SWE (ingeniero de software) y la empresa están de acuerdo en que el servicio tiene que estar al día para ser valioso, y la solución SRE cuantifica los objetivos para impulsar acciones y prioridades. La solución -hacer del nivel de servicio un objetivo y, cuando se está por debajo del mismo, priorizar la fiabilidad sobre las prestaciones- elimina un conflicto clásico entre operaciones y desarrolladores. Se trata de un replanteamiento sencillo y elegante que resuelve los problemas sin tenerlos. Doy estos tres capítulos como tarea a casi todas las personas que conozco desde entonces. Son así de buenos. Todo el mundo debería conocerlos. Díselo a todos tus amigos. Yo se lo he contado a todos los míos.

La última década de mi carrera se ha centrado en ayudar a la gente a entregar software con mejores herramientas y procesos. A veces la gente dice que he contribuido a inventar DevOps, pero yo solo estaba en posición de tomar prestados y robar patrones de éxito de muchas organizaciones y proyectos diferentes. Me apena cuando la gente dice que “DevOps” pudo haber sido inventado por cualquiera, pero especialmente por mi. No me considero un experto en nada más que en ser curioso. Mi DevOps idealizado siempre se basó en cualquier información que pudiera extraer o deducir de mis amigos, y resulta que mis amigos estaban construyendo Internet. Tuve el privilegio de acceder tras bambalinas a personas que desplegaban y operaban una muestra representativa de las infraestructuras y aplicaciones más increíbles del mundo. DevOps simboliza aspectos de las optimizaciones emergentes y existenciales necesarias para suministrar rápidamente software de alta disponibilidad a través de Internet. El cambio del software entregado en soportes físicos al software entregado como servicio forzó una evolución de las herramientas y los procesos. Esta evolución elevó la contribución de las operaciones a la cadena de valor. Si los sistemas no funcionan, el software no tiene valor. La buena noticia es que no hay que esperar al envío de la siguiente caja empaquetada para cambiar el software. Para algunos, esta es también la mala noticia. Simplemente tuve la oportunidad y la perspectiva de articular los patrones más exitosos de la nueva forma a una audiencia receptiva.

En 2008, antes de que utilizáramos la palabra DevOps como lo hacemos ahora, yo había pasado por el colapso de las puntocom, la escuela de posgrado y un par de montañas rusas financiadas por empresas como desarrollador, buscando respuestas en Google a diario durante todo ese tiempo. Estaba trabajando en Puppet a tiempo completo y me fascinaba el potencial de la automatización para transformar las organizaciones de TI. Puppet me empujó a resolver problemas en el ámbito de las operaciones. En ese momento, Google utilizaba Puppet para gestionar sus estaciones de trabajo Linux y OS X corporativas a una escala que sobrepasaba las capacidades del servidor Puppet. Teníamos una gran relación de trabajo con Google, pero Google mantenía en secreto ciertos detalles de sus operaciones internas por una cuestión de política. Lo sé porque soy curioso por naturaleza y buscaba constantemente más información. Siempre supe que Google debía de tener herramientas y procesos internos excelentes, pero no siempre era evidente cuáles eran. Con el tiempo, acepté que hacer preguntas profundas sobre Borg probablemente significaba que la conversación actual no estaba yendo muy lejos. Me habría encantado saber más sobre cómo Google lo hacía todo, pero esto simplemente no estaba permitido en ese momento. La importancia de 2008 también incluye la primera conferencia Velocity de O'Reilly y el año en que conocí a Patrick Debois. “DevOps aún no existía, pero estaba a punto de hacerlo. Era el momento adecuado. El mundo estaba preparado. DevOps simbolizaba una nueva forma, una forma mejor. Si Site Reliability Engineering se hubiera publicado entonces, creo que la comunidad que se formó se habría unido para enarbolar la bandera de “eliminar el trabajo pesado” y el término DevOps nunca habría existido. A pesar de los supuestos contrarios, sé que el primer libro de SRE hizo avanzar personalmente mi comprensión de lo posible, y ya he ayudado a muchos otros sólo con los principios de SRE.

En los primeros días del movimiento DevOps, evitamos conscientemente codificar prácticas porque todo evolucionaba muy rápidamente y no queríamos poner límites a lo que DevOps podía llegar a ser. Además, explícitamente no queríamos que nadie “poseyera” DevOps. Cuando escribí sobre DevOps en 2010, planteé tres puntos distintos. En primer lugar, los desarrolladores y las operaciones pueden y deben trabajar juntos. En segundo lugar, la administración de sistemas se parecerá cada vez más al desarrollo de software. Por último, compartir con una comunidad global de práctica acelera y multiplica nuestras capacidades colectivas. Más o menos al mismo tiempo, mis amigos Damon Edward y John Willis acuñaron el acrónimo CAMS para Culture, Automation, Metrics, y Sharing (Cultura, Automatización, Métricas y Compartir). Más tarde, Jez Humble amplió este acrónimo a CALMS añadiendo la mejora continua Lean. El significado de cada una de estas palabras en su contexto merecería un libro entero, pero las menciono aquí porque Site Reliability Engineering hace referencia explícita a Culture, Automation, Metrics y Sharing junto con anécdotas sobre el viaje de Google hacia la mejora continua. Al publicar el primer libro de SRE, Google compartió sus principios y prácticas con la comunidad mundial. Ahora defino DevOps simplemente como “optimizar el rendimiento humano y la experiencia operando software, con software y con humanos”. No quiero poner palabras en boca de nadie, pero me parece una forma estupenda de describir también la SRE.

En última instancia, reconozco DevOps cuando lo veo y veo SRE en Google, en teoría y en la práctica, como una de las implementaciones más avanzadas. Unas buenas operaciones de TI siempre han dependido de una buena ingeniería, y resolver los problemas de las operaciones con software siempre ha sido fundamental para DevOps. La Ingeniería de Confiabilidad del Sitio hace que el aspecto de ingeniería sea aún más explícito. Me acobardo cuando oigo a alguien decir “SRE frente a DevOps”. Para mí, son inseparables en el tiempo y el espacio, como etiquetas que describen los sistemas sociotécnicos que proporcionan infraestructuras modernas con software. Considero DevOps un conjunto genérico de principios y SRE una implementación explícita avanzada. Una analogía paralela sería la relación entre Agile y Extreme Programming (XP). Es cierto que XP es ágil, posiblemente lo mejor de Agile, pero no todas las organizaciones son capaces de adoptar XP o están dispuestas a hacerlo.

Algunos dicen que “el software se está comiendo el mundo”, y entiendo por qué lo hacen, pero “software” por sí solo no es el encuadre correcto. Sin la ubicuidad del hardware informático conectado a redes de alta velocidad, mucho de lo que damos por sentado como “software” no sería posible. Es una verdad innegable. Lo que creo que muchos pasan por alto en esta conversación sobre tecnología son los seres humanos. La tecnología existe gracias a los humanos y, con suerte, para los humanos, pero si miramos un poco más a fondo, también nos daremos cuenta de que el software del que dependemos, y que probablemente damos por sentado, depende en gran medida de los humanos. Nosotros dependemos del software, pero el software también depende de nosotros. Se trata de un único sistema interconectado de hardware-software imperfecto y humanos que dependen de sí mismos para construir el futuro. La fiabilidad se está comiendo el mundo. Pero la fiabilidad no sólo tiene que ver con la tecnología, sino también con las personas. Las personas y la tecnología forman un único sistema tecnosocial. Un aspecto positivo de que Google comparta la SRE con el resto de la industria es que cualquier excusa sobre qué tipo de procesos funcionan a escala pierde su validez. Google estableció el estándar más alto tanto en fiabilidad como en escala. Puede haber argumentos válidos sobre por qué alguien no puede adoptar directamente las prácticas de SRE de Google, pero los principios rectores deberían seguir aplicándose. Cuando observo el panorama de posibilidades para construir el futuro y la ambición de transformar la experiencia humana con el software, veo un montón de proyectos ambiciosos para, literalmente, conectarlo todo a Internet. Mis cálculos dicen que los proyectos que tengan éxito se encontrarán ingiriendo e indexando cantidades increíbles de datos. Pocos, si es que hay alguno, superarán la escala de Google en la actualidad, pero algunos tendrán el mismo tamaño que Google cuando empezaron con la SRE y necesitarán resolver los mismos problemas de fiabilidad. Sostengo que, en estos casos, la adopción de herramientas y procesos que se parezcan sospechosamente a la SRE no es opcional, sino existencial, aunque no hay necesidad de esperar a esa crisis porque los principios y prácticas de la SRE se aplican a cualquier escala.

La SRE suele enmarcarse en la forma en que Google lleva a cabo las operaciones, pero eso no permite tener una visión más amplia: En la práctica, la SRE permite la ingeniería de software, pero también transforma la arquitectura, la seguridad, la gobernanza y el cumplimiento. Cuando aprovechamos el enfoque de la SRE para proporcionar una plataforma de servicios, todas estas otras consideraciones consiguen tener un énfasis de primera clase, pero dónde y cómo sucede puede ser muy diferente. Al igual que SRE (y, con suerte, DevOps) desplazó cada vez más la carga a la ingeniería de software, la arquitectura moderna y las prácticas de seguridad evolucionan de diapositivas, listas de comprobación y esperanza a habilitar los comportamientos correctos con código en ejecución. Las organizaciones que adoptan principios y prácticas de SRE sin revisar estos otros aspectos pierden una enorme oportunidad de mejorar, y probablemente también se encontrarán con resistencia interna si las personas que se consideran responsables de esos aspectos no se convierten en aliados.

Siempre me gusta aprender. Leí cada palabra del primer libro de la SRE de un tirón. Me encantó el lenguaje. Me encantaron las anécdotas. Me encantó entender mejor cómo se ve Google a sí mismo. Pero la pregunta para mí siempre es: “¿Qué comportamiento voy a cambiar?”. Aprender no es recopilar información. Aprender es cambiar comportamientos. Esto es fácil de determinar o incluso cuantificar en ciertas disciplinas. Has aprendido a tocar una nueva canción cuando puedes tocar la canción. Eres mejor al ajedrez cuando ganas partidas contra jugadores más fuertes. La Ingeniería de Confiabilidad del Sitio, al igual que DevOps, no debe limitarse a cambiar títulos, sino a realizar cambios de comportamiento definitivos, centrándose en los resultados y, obviamente, en la confiabilidad. El Manual de Confiabilidad del Sitio promete avanzar desde una enumeración de principios y prácticas de Google para Google hacia acciones y comportamientos más contextuales. La fiabilidad del sitio es para todos, pero la fiabilidad no se consigue leyendo libros. Brindemos por asumir riesgos y eliminar trabajo pesado.

Volver al índice