El cuaderno de trabajo de la fiabilidad del sitio web

Prólogo II

Andrew Clay Shafer

Cuando me enteré de que se estaba trabajando en un segundo libro de SRE, me puse en contacto con ellos y les pregunté si podía escribir unas palabras. Los principios del primer libro de SRE se ajustan muy bien a lo que siempre imaginé que era DevOps, y las prácticas son muy perspicaces, aunque no sean aplicables al 100% fuera de Google. Después de leer por primera vez los principios del primer libro de SRE -aceptarel riesgo (Capítulo 3), los objetivos de nivel de servicio (Capítulo 4) y eliminar el trabajo duro (Capítulo 5)- quise gritar ese mensaje a los cuatro vientos. "Abrazar el riesgo" resonó tanto porque yo había utilizado un lenguaje similar muchas veces para ayudar a las organizaciones tradicionales a motivar el cambio. El Capítulo 6 siempre fue 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. La SRE, la SWE (ingeniera de software) y la empresa están de acuerdo en que el servicio tiene que estar a la altura para ser valioso, y la solución de la 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 objetivo priorizar la fiabilidad sobre las características- elimina un conflicto clásico entre operaciones y desarrolladores. Se trata de un replanteamiento sencillo y elegante que resuelve problemas al no 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 saberlo. 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 contribuí a inventar DevOps, pero yo sólo estaba en posición de tomar prestados y robar patrones de éxito de muchas organizaciones y proyectos diferentes. Me avergüenzo cuando la gente dice que "DevOps" lo inventó cualquiera, pero especialmente yo. No me considero un experto en nada, salvo 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 entre bastidores a personas que implementaban 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 tienes que esperar al envío de la siguiente caja retractilada para cambiar el software. Para algunos, ésta es también la mala noticia. Simplemente tuve la oportunidad y la perspectiva de articular los patrones más exitosos de la nueva forma ante un público receptivo.

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. Trabajaba 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 aquel momento, Google utilizaba Puppet para gestionar sus estaciones de trabajo Linux y OS X corporativas a una escala que superaba 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 grandes herramientas y procesos internos, pero lo que eran estas herramientas y procesos no siempre era evidente. Con el tiempo, acepté que hacer preguntas profundas sobre Borg probablemente significaba que la conversación actual no iba muy lejos. Me habría encantado saber más sobre cómo lo hacía todo Google, pero esto simplemente no estaba permitido en aquel 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 entonces se hubiera publicado Site Reliability Engineering, creo que la comunidad que se formó se habría unido para enarbolar la bandera de "eliminar el trabajo" y el término DevOps quizá nunca hubiera existido. A pesar de los contrafácticos, 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 la SRE.

En los primeros días del movimiento DevOps, evitamos conscientemente codificar las 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. Primero, 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 Edwards y John Willis acuñaron el acrónimo CAMS para Cultura, Automatización, Métrica y Compartir. Más tarde, Jez Humble amplió este acrónimo a CALMS añadiendo mejora continua Lean. Lo que cada una de estas palabras pueda significar en su contexto merece un libro entero, pero las menciono aquí porque Site Reliability Engineering hace referencia explícita a Culture, Automation, Metrics, and Sharing (Cultura, Automatización, Métricas y Compartir) 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 y la experiencia humana 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, conozco DevOps cuando lo veo y considero que SRE en Google, en la teoría y en la práctica, es una de las implementaciones más avanzadas. Las 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 Fiabilidad del Sitio Web hace aún más explícito el aspecto de la ingeniería. Me acobardo cuando oigo a alguien decir "SRE frente a DevOps". Para mí, son inseparables en el tiempo y en el espacio, como etiquetas que describen los sistemas sociotécnicos que proporcionan infraestructuras modernas con software. Considero que DevOps es 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 Ágil, 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 el "software" por sí solo no es el encuadre correcto. Sin la ubicuidad del hardware computacional conectado con 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 humanos. La tecnología existe gracias a los humanos y, con suerte, para los humanos, pero si miras un poco más profundamente, también te das cuenta de que el software del que dependemos, y que probablemente damos por sentado, depende en gran medida de los humanos. 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 compartiera la SRE con el resto del sector es que cualquier excusa sobre qué tipo de procesos funcionan a escala quedó invalidada. Google estableció el estándar más alto tanto para la fiabilidad como para la 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, adoptar herramientas y procesos que se parezcan sospechosamente a la SRE no es opcional, sino existencial, aunque no es necesario 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 pasa por alto el panorama general: 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 llegan a tener un énfasis de primera clase, pero dónde y cómo ocurre puede ser muy diferente. Al igual que la SRE (y esperemos que DevOps) desplazó cada vez más la carga a la ingeniería de software, las prácticas modernas de arquitectura y seguridad evolucionan desde las diapositivas, las listas de comprobación y la esperanza hasta la habilitación de los comportamientos correctos con código en ejecución. Las organizaciones que adopten los principios y prácticas de la 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 disfruto aprendiendo. Leí cada palabra del primer libro de la SRE de un tirón. Me encantó el lenguaje. Me encantaron las anécdotas. Me encantó comprender 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 el comportamiento. Esto es fácil de determinar o incluso de cuantificar en ciertas disciplinas. Has aprendido a tocar una canción nueva cuando puedes tocar la canción. Eres mejor al ajedrez cuando ganas partidas contra jugadores más fuertes. La Ingeniería de la Fiabilidad del Sitio Web, al igual que DevOps, no debería limitarse a cambiar títulos, sino a realizar cambios de comportamiento definitivos, centrándose en los resultados y, obviamente, en la fiabilidad. El Site Reliability Workbook 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. Por abrazar el riesgo y eliminar el esfuerzo.