Escrito por Andrew Clay Shafer
Cuando descubrí que había gente trabajando en un segundo libro de SRE, me acerqué y le pregunté si podía escribir algunas palabras. Los principios del primer libro de SRE se alinean muy bien con lo que siempre imaginé que sería DevOps, y las prácticas son reveladoras, incluso cuando no son 100% aplicables fuera de Google. Después de leer los principios del primer libro de la SRE por primera vez —aceptar el riesgo (Capítulo 3) , los objetivos de nivel de servicio (Capítulo 4) y eliminar la fatiga (Capítulo 5) —quise gritar ese mensaje desde los tejados. “Abrazar el riesgo” resonó mucho porque había usado un lenguaje similar muchas veces para ayudar a las organizaciones tradicionales a motivar el cambio. Capítulo 6siempre fue un objetivo implícito de DevOps, tanto para permitir 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 crean un contrato desapasionado entre las consideraciones operativas y la entrega de nuevas funciones. La SRE, SWE (ingeniero de software) y las empresas están de acuerdo en que el servicio debe estar a la altura para ser valioso, y la solución SRE cuantifica los objetivos para impulsar acciones y prioridades. La solución —convierta el nivel de servicio en un objetivo y cuando esté por debajo del objetivo priorice la confiabilidad sobre las funciones— elimina un conflicto clásico entre operaciones y desarrolladores. Se trata de un reencuadre simple y elegante que resuelve problemas al no tenerlos. Doy estos tres capítulos como tarea para casa a casi todas las personas que he conocido desde entonces. Son tan buenos. Todo el mundo debería saberlo. Dile a todos tus amigos. Ya les he contado a todos los míos.
La última década de mi carrera se ha centrado en ayudar a las personas a entregar software con mejores herramientas y procesos. A veces, la gente dice que contribuí a inventar DevOps, pero estaba en condiciones de tomar prestados y robar patrones exitosos de muchas organizaciones y proyectos diferentes. Me avergüenzo cuando la gente dice que “DevOps” fue inventado por cualquiera, pero especialmente por mí. No me considero un experto en nada más que en ser curioso. Mi DevOps idealizado siempre modeló cualquier información que pudiera extraer o inferir de mis amigos, y mis amigos estaban construyendo Internet. Tuve el privilegio de tener acceso entre bastidores a personas que implementan y operan 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 entregar rápidamente software de alta disponibilidad a través de Internet. El cambio de software entregado en medios físicos a software entregado como servicio forzó una evolución de herramientas y 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 tiene que esperar a enviar la próxima caja envuelta en plástico para cambiar el software. Para algunos, esta es también una mala noticia. Simplemente tuve la oportunidad y la perspectiva de articular los patrones más exitosos de la nueva forma para una audiencia receptiva. El cambio de software entregado en medios físicos a software entregado como servicio forzó una evolución de herramientas y 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 tiene que esperar a enviar la próxima caja envuelta en plástico para cambiar el software. Para algunos, esta es también una mala noticia. Simplemente tuve la oportunidad y la perspectiva de articular los patrones más exitosos de la nueva forma para una audiencia receptiva. El cambio de software entregado en medios físicos a software entregado como servicio forzó una evolución de herramientas y 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 ningún valor. La buena noticia es que no tiene que esperar a enviar la próxima caja envuelta en plástico para cambiar el software. Para algunos, esta es también una mala noticia. Simplemente tuve la oportunidad y la perspectiva de articular los patrones más exitosos de la nueva forma para una audiencia receptiva.
En 2008, antes de que usáramos la palabra DevOps como lo hacemos ahora, había pasado por el colapso de las punto com, la escuela de posgrado y un par de montañas rusas financiadas por empresas como desarrollador, buscando respuestas en Google todos los días todo el tiempo. Trabajaba en Puppet a tiempo completo y estaba fascinado por el potencial de la automatización para transformar las organizaciones de TI. Puppet me empujó a resolver problemas en el dominio de las operaciones. En este momento, Google usaba Puppet para administrar sus estaciones de trabajo corporativas Linux y OS X a una escala que impulsaba las capacidades del servidor Puppet. Teníamos una excelente relación de trabajo con Google, pero Google mantuvo en secreto ciertos detalles de sus operaciones internas como una cuestión de política. Lo sé porque soy curioso por naturaleza y busco constantemente más información. Siempre supe que Google debe tener excelentes herramientas y procesos internos, pero lo que eran estas herramientas y procesos no siempre era evidente. Finalmente, acepté que hacer preguntas profundas sobre Borg probablemente significaba que la conversación actual no iba muy lejos. Me hubiera encantado saber más sobre cómo Google hizo todo, pero esto simplemente no estaba permitido en ese momento. La importancia de 2008 también incluye la primera conferencia O’Reilly Velocity y el año en que conocí a Patrick Debois. “DevOps” aún no existía, pero estaba a punto de serlo. Era el momento adecuado. El mundo estaba listo. DevOps simbolizaba una nueva forma, una forma mejor. Si La importancia de 2008 también incluye la primera conferencia O’Reilly Velocity y el año en que conocí a Patrick Debois. “DevOps” aún no existía, pero estaba a punto de serlo. Era el momento adecuado. El mundo estaba listo. DevOps simbolizaba una nueva forma, una forma mejor. Si La importancia de 2008 también incluye la primera conferencia O’Reilly Velocity y el año en que conocí a Patrick Debois. “DevOps” aún no existía, pero estaba a punto de serlo. Era el momento adecuado. El mundo estaba listo. DevOps simbolizaba una nueva forma, una forma mejor. SiSite Reliability Engineering se había publicado entonces, creo que la comunidad que se formó se habría unido para enarbolar la bandera de “eliminar el trabajo duro” y el término DevOps podría no haber existido nunca. A pesar de los contrafácticos, sé que el primer libro de la SRE avanzó personalmente en mi comprensión de lo posible, y ya ayudé a muchos otros solo con los principios de la SRE.
En los primeros días del movimiento DevOps, evitamos conscientemente las prácticas de codificación porque todo estaba evolucionando muy rápidamente y no queríamos poner límites a lo que DevOps podría convertirse. Además, explícitamente no queríamos que nadie “poseyera” DevOps. Cuando escribí sobre DevOps en 2010, hice tres puntos distintos. Primero, los desarrolladores y las operaciones pueden y deben trabajar juntos. En segundo lugar, la administración del sistema se parecerá cada vez más al desarrollo de software. Finalmente, compartir con una comunidad global de práctica acelera y multiplica nuestras capacidades colectivas. Casi al mismo tiempo, mis amigos Damon Edward y John Willis acuñaron el acrónimo CAMS para Culture, Automation, Metrics, and Sharing. Jez Humble luego expandió este acrónimo a CALMSagregando la mejora continua Lean. Lo que cada una de estas palabras podría significar en contexto merece ser un libro completo, pero las menciono aquí porque Site Reliability Engineering hace referencia explícitamente a Culture, Automation, Metrics y Sharing junto con anécdotas sobre el viaje de Google para mejorar continuamente. Al publicar el primer libro de SRE, Google compartió sus principios y prácticas con la comunidad global. Ahora defino DevOps simplemente como “optimizar el rendimiento humano y la experiencia del software operativo, con software y con humanos”. No quiero poner palabras en la boca de nadie, pero también parece una excelente manera de describir SRE.
En última instancia, conozco DevOps cuando lo veo y veo a SRE en Google, en teoría y en la práctica, como una de las implementaciones más avanzadas. Las buenas operaciones de TI siempre han dependido de una buena ingeniería, y la resolución de problemas de operaciones con software siempre ha sido fundamental para DevOps. La ingeniería de confiabilidad del sitio hace que el aspecto de la ingeniería sea aún más explícito. Me estremezco cuando escucho a alguien decir “SRE versus DevOps”. Para mí, son inseparables en el tiempo y el espacio, como etiquetas que describen los sistemas sociotécnicos que entregan una infraestructura moderna 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 Agile, posiblemente lo mejor de Agile, pero no todas las organizaciones son capaces o están dispuestas a adoptar XP.
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 marco adecuado. Sin la ubicuidad del hardware computacional conectado con redes de alta velocidad, gran parte de lo que damos por sentado como “software” no sería posible. Ésta es una verdad innegable. Lo que creo que muchos extrañan en esta conversación sobre tecnología son los humanos. La tecnología existe gracias a los humanos y, con suerte, parahumanos, pero si miras un poco más profundo, también te darás cuenta de que el software en el que confiamos, y 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 imperfecto: software y humanos que confían en sí mismos para construir el futuro. La confiabilidad se está comiendo el mundo. Sin embargo, la confiabilidad no se trata solo de tecnología, sino también de personas. Las personas y la tecnología forman un único sistema tecnosocial. Una característica interesante de que Google comparta SRE con el resto de la industria es que cualquier excusa sobre qué tipo de procesos funcionan a escala se vuelve inválida. Google estableció el estándar más alto tanto en confiabilidad como en escala. Puede haber argumentos válidos sobre por qué alguien no puede adoptar las prácticas de Google SRE directamente, pero los principios rectores deben aplicarse. Mientras miro el panorama de posibilidades para construir el futuro y la ambición de transformar la experiencia humana con software, veo muchos proyectos ambiciosos para conectar todo literalmente a Internet. Mis matemáticas dicen que los proyectos exitosos 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 comenzaron SRE y necesitarán resolver los mismos problemas de confiabilidad. Sostengo que, en estos casos, la adopción de herramientas y procesos que se parecen sospechosamente a la SRE no es opcional sino existencial, aunque no hay necesidad de esperar esa crisis porque los principios y prácticas de la SRE se aplican a cualquier escala. Veo muchos proyectos ambiciosos para conectar todo literalmente a Internet. Mis matemáticas dicen que los proyectos exitosos 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 comenzaron SRE y necesitarán resolver los mismos problemas de confiabilidad. Sostengo que, en estos casos, la adopción de herramientas y procesos que se parecen sospechosamente a la SRE no es opcional sino existencial, aunque no hay necesidad de esperar esa crisis porque los principios y prácticas de la SRE se aplican a cualquier escala. Veo muchos proyectos ambiciosos para conectar todo literalmente a Internet. Mis matemáticas dicen que los proyectos exitosos 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 comenzaron SRE y necesitarán resolver los mismos problemas de confiabilidad. Sostengo que, en estos casos, la adopción de herramientas y procesos que se parecen sospechosamente a la SRE no es opcional sino existencial, aunque no hay necesidad de esperar esa crisis porque los principios y prácticas de la SRE se aplican a cualquier escala. pero algunos tendrán el mismo tamaño que Google cuando iniciaron SRE y deberán resolver los mismos problemas de confiabilidad. Sostengo que, en estos casos, la adopción de herramientas y procesos que se parecen sospechosamente a la SRE no es opcional sino existencial, aunque no hay necesidad de esperar esa crisis porque los principios y prácticas de la SRE se aplican a cualquier escala. pero algunos tendrán el mismo tamaño que Google cuando iniciaron SRE y deberán resolver los mismos problemas de confiabilidad. Sostengo que, en estos casos, la adopción de herramientas y procesos que se parecen sospechosamente a la SRE no es opcional sino existencial, aunque no hay necesidad de esperar esa crisis porque los principios y prácticas de la SRE se aplican a cualquier escala.
La SRE generalmente se enmarca como la forma en que Google realiza las operaciones, pero eso pierde el panorama general: la SRE en la práctica permite la ingeniería de software, pero también transforma la arquitectura, la seguridad, la gobernanza y el cumplimiento. Cuando aprovechamos el enfoque de SRE en proporcionar una plataforma de servicios, todas estas otras consideraciones llegan a tener un énfasis de primera clase, pero dónde y cómo sucede eso puede ser bastante diferente. Al igual que SRE (y con suerte DevOps) trasladó 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 verificación y esperanza a habilitar los comportamientos correctos con código en ejecución. Las organizaciones que adoptan los principios y prácticas de SRE sin revisar estos otros aspectos pierden una gran oportunidad para mejorar,
Siempre disfruto aprendiendo. Leí cada palabra del primer libro de la SRE de principio a fin. Me encantaba el idioma. Me encantaron las anécdotas. Me encantó comprender más sobre cómo se ve Google a sí mismo. Pero la pregunta para mí siempre es: “¿Qué comportamiento cambiaré?” Aprender no es recopilar información. Aprender es cambiar el comportamiento. Esto es fácil de determinar o incluso cuantificar en determinadas disciplinas. Ha aprendido a tocar una canción nueva cuando puede tocarla. Eres mejor en el ajedrez cuando ganas partidas contra jugadores más fuertes. La ingeniería de confiabilidad del sitio, como DevOps, no solo debería cambiar los títulos, sino también realizar cambios de comportamiento definitivos, centrándose en los resultados y, obviamente, en la confiabilidad. El libro de trabajo de confiabilidad del sitiopromete avanzar desde una enumeración de principios y prácticas de Google para Google hacia acciones y comportamientos más contextuales. La confiabilidad del sitio es para todos, pero la confiabilidad no proviene de la lectura de libros. Aquí está para asumir el riesgo y eliminar el trabajo duro.