Cómo la IA transformará las prácticas de DevOps y SRE | Better Stack Podcast Ep. 12
BBetter Stack
Computing/SoftwareAuto EnthusiastManagementTelecommutingMental HealthInternet Technology
Transcript
00:00:00Lo plantearé así: abre un proyecto de código Claude y pídele que te diseñe un puente
00:00:05O un rascacielos
00:00:08Y luego quiero que tomes ese diseño y vayas a construirlo
00:00:12Y después quiero que te sientes en él. ¿Te sentirías cómodo haciendo eso?
00:00:16¿Te sentirías cómodo cruzando en coche ese puente que diseñó?
00:00:19Exacto, hasta que dejes de negar con la cabeza. Necesitamos a esos ingenieros ahí fuera
00:00:25Bienvenidos al podcast de Better Stack, donde hablamos sobre desarrollo de software, inteligencia artificial y todo tipo de nuevas tecnologías
00:00:32Soy uno de vuestros anfitriones, Andris, y hoy me acompaña Wishes. Hola, y...
00:00:38Amin Astani. Hola, Amin. ¿Cómo va todo? Qué alegría tenerte por aquí.
00:00:44Sí, eh, gracias por invitarme. Es un verdadero placer. Así que, por lo que sé de ti...
00:00:51pienso que eres más o menos...
00:00:53algo así como un mago de SRE. Estás muy metido en ese mundo, tienes tu propio podcast sobre el tema
00:01:01así que tenemos curiosidad por saber cómo empezaste en esta área y cómo ha sido tu trayectoria a lo largo de...
00:01:08tu carrera en el desarrollo de software hasta ahora.
00:01:11Sí, buena pregunta otra vez, Andris, Richard. Gracias por invitarme. Sí, ¿cómo empecé?
00:01:17Bueno, cuando estaba en el instituto, la madre de mi novia me presentó Red Hat Linux.
00:01:23Ella estaba haciendo un curso de informática en un colegio comunitario y...
00:01:29simplemente me enseñó su escritorio, que no era Windows, no era Mac. Yo estaba muy confundido; lo que era, era un escritorio KDE corriendo sobre...
00:01:37Red Hat Linux, y me fascinó. Empecé a meterme en eso en penúltimo año de instituto
00:01:44y luego obtuve mi, eh...
00:01:47título en informática, y me interesé mucho por la infraestructura, por los sistemas operativos y por enseñarle a una computadora a hacer cosas
00:01:55que antes no podíamos controlar, así que ese fue el comienzo.
00:02:00Así que siempre has sido como un defensor del software libre, imagino, si usas Linux.
00:02:06Ah, al 100 por ciento
00:02:08Linux ha sido mi sistema principal
00:02:10durante más de dos décadas ya, desde...
00:02:122005.
00:02:15De acuerdo. Y, ¿cuándo fue el momento en que empezaste a tomarte muy en serio el SRE?
00:02:20Sí, eso fue hace unos 10 años. Antes de eso, yo era un profesional de operaciones clásico en una empresa SaaS de crecimiento rápido
00:02:29llamada Acquia. Si alguna vez has oído hablar de Drupal, el fundador del proyecto de código abierto Drupal
00:02:34fundó una compañía que ofrecía servicios profesionales, alojamiento y soporte para sitios web de Drupal.
00:02:38Así que estuve en su equipo de operaciones, pero a medida que la empresa crecía —y era un crecimiento meteórico—,
00:02:45con muchos clientes grandes cuyos nombres reconocerías, con esa escala vino un montón de trabajo manual tedioso. ¡Ahí lo tienes!
00:02:51Ahora estamos hablando de SRE. Había mucho trabajo manual tedioso, había muchos incidentes.
00:02:55Estábamos empezando a chocar con la realidad de operar a escala frente a la arquitectura con la que habíamos
00:03:01empezado originalmente y los procesos con los que empezamos, así que comencé a leer The Phoenix Project. Me adentré en
00:03:09la práctica de la administración de sistemas en la nube, que fue el primer libro sobre SRE.
00:03:12No era el libro de SRE de Google; SRE ocupaba apenas unas páginas y tenía 12 prácticas.
00:03:17Y de nuevo, me intrigó muchísimo y empecé a ponerlo en práctica.
00:03:21Y la verdad es que no sé qué es The Phoenix Project. ¡Vaya por Dios!
00:03:26Sí, sí. The Phoenix Project fue como el libro original de DevOps
00:03:31y es un libro realmente bueno.
00:03:34Sí, es una historia y trata sobre
00:03:39el vicepresidente de operaciones de TI lidiando con algunos problemas organizativos importantes y
00:03:45cómo, bajo la guía de un mentor misterioso que luego descubres que es miembro de la junta directiva de la empresa,
00:03:53le enseña sobre
00:03:55conceptos
00:03:56de la vieja escuela de fabricación en plantas y cómo se aplican directamente a la ingeniería de software y a las operaciones de TI, y
00:04:05introdujo muchos conceptos que sigo usando hoy en día y de los que hablo con los clientes hoy en día porque es extremadamente relevante.
00:04:11Así que sí, ese fue el libro original, pero a partir de ahí
00:04:13leí un montón de cosas, gran parte de ello en el mundo de la gestión.
00:04:18Así que, además de todo lo técnico que leería solo para mejorar mis habilidades como SRE y como ingeniero de software,
00:04:24también está el tema de la gestión, porque DevOps y SRE son prácticas sociotécnicas.
00:04:29Estás tendiendo un puente entre lo que la tecnología puede hacer y cómo los humanos la usan para lograr buenos resultados de negocio
00:04:36Y me imagino que hay mucho error humano involucrado en eso y en lidiar con él, ¿verdad?
00:04:42Vaya, sí, absolutamente. O sea, caramba, hay un libro sobre el error humano que probablemente deberías leer también.
00:04:50Sí, hay un caballero... su nombre desafortunadamente se me escapa ahora mismo, pero es
00:04:57como profesor en Sídney, Australia, y todo de lo que habla son accidentes aéreos y de cómo el error humano...
00:05:05es enorme, ¿no? Es muy útil en la cultura de los post-mortems; el error humano no es donde terminamos.
00:05:10O sea, si dices, 'oh, sí, la razón por la que tuvimos este incidente, este incidente de producción, fue error humano',
00:05:16No, ese es el comienzo del debate, no el final. Qué factores contribuyeron a
00:05:21que esa persona en ese puesto tecleara mal un comando y arruinara la base de datos de producción
00:05:27¿Debería haber tenido acceso a la base de datos de producción? ¿Eran ergonómicas las herramientas? ¿Durmió la noche anterior?
00:05:34¿Cuántas veces lo llamaron? Sabe, hay todo tipo de factores
00:05:38Pero sí, cuando la gente dice error humano, enseguida pienso en ese libro. Tendré que dejarle un enlace en las notas del programa
00:05:45Sí, creo que recuerdo mi primer
00:05:49acercamiento a las pruebas de extremo a extremo cuando escuchaba un curso en el que alguien habló
00:05:54sobre un incidente en el que se desarrolló cierto tipo de software para
00:05:58cirujanos y tenías que hacer clic en los botones en un orden determinado
00:06:03pero los cirujanos se acostumbraron tanto a hacer clic que lo hacían
00:06:07tan rápido que el software empezó a fallar y nadie se esperaba que eso pudiera ocurrir
00:06:13Así que es bastante interesante
00:06:15Sí, sin duda, la intersección entre los seres humanos y la automatización es algo a lo que siempre debemos prestar atención en los productos que operamos
00:06:25Sí
00:06:26Y también escuché que empezaste
00:06:28con DevOps y SRE durante la era del buscapersonas, cuando tenías que usar localizadores. ¿Es correcto?
00:06:35Sí, de hecho, la primera vez que estuve de guardia me entregaron un buscapersonas
00:06:42físico. Y claro, oh vaya, ¿en qué año fue eso?
00:06:46Fue en 2005
00:06:48Ah, vaya. Bien. Así que mi primer trabajo en tecnología... Oh, esto es genial
00:06:55Trabajaba en un garaje, como toda startup exitosa, en Plant City, Florida
00:07:02El padre de una buena amiga
00:07:04mía tenía un proyecto secundario en el que gestionaba alojamiento web, correo y un ISP de acceso telefónico desde su garaje
00:07:12Se llama Se llama Curtis Fellaini. Le tengo muchísimo respeto y él, este...
00:07:18me enseñó todo lo que sabía. Pero sí, utilizábamos esta herramienta de guardia llamada What's Up Gold
00:07:24Y lo que hacía... Sé que te suena el nombre, y lo que hacía no eran comprobaciones HTTP
00:07:33Hacía pings ICMP a los servidores, un ping de la vieja escuela, y si no obtenía respuesta
00:07:40enviaba
00:07:42un aviso. Y yo llevaba un buscapersonas, llevé uno durante un tiempo cuando trabajaba allí
00:07:48Inmediatamente después, cuando trabajaba en mi alma mater haciendo supercomputación y HPC, usábamos Nagios
00:07:54y mensajes de texto al teléfono móvil
00:07:57¿Fue una elección deliberada o para entonces ya habían surgido tecnologías más nuevas, como mencionabas los mensajes SMS y cosas así?
00:08:07Sí, en aquellos días ya había más herramientas
00:08:11aunque limitadas, pero había más herramientas disponibles para supervisar
00:08:15la infraestructura en ese momento. Y cuando estaba en el departamento de HPC de la Universidad del Sur de Florida
00:08:22ya manejábamos escalas de cientos de servidores, porque es computación de alto rendimiento
00:08:27Tienes bastidores de servidores haciendo tareas de cálculo, así que necesitábamos
00:08:31algo un poco más avanzado que
00:08:34un buscapersonas. El contenido del aviso también importaba, porque si solo recibías
00:08:40un mensaje que decía, vaya, tengo que ir a comprobar qué pasa por el beeper
00:08:45con Nagios al menos obtenías algo de contexto, como que este servidor
00:08:50está caído o este servicio vinculado a este servidor está caído. Así que incluso entonces
00:08:56en aquellos días ya había cierta sofisticación para poder configurar
00:09:01lo que
00:09:03querías supervisar por host o por servicio
00:09:06Definitivamente era muy anterior a los SLO, ni siquiera pensábamos en eso
00:09:13Solo pensábamos en si este puerto está abierto y me da la respuesta esperada
00:09:17Vaya, 2005. Creo que yo iba a la secundaria en esa época, ni siquiera pensaba en la informática
00:09:26por entonces
00:09:28No lo aparento
00:09:30pero soy mayor de lo que parezco. Sí, ya me di cuenta. Bueno, te ves muy bien. ¡Muchas gracias!
00:09:37Haciendo un poco de investigación, parece que trabajaste en Meta. ¿Qué hacías
00:09:43y cómo era trabajar allí?
00:09:45Dios mío. Fui ingeniero de producción
00:09:48y gerente de ingeniería de producción, así que
00:09:52lo que significa básicamente es que es su versión de SRE. Trabajé en dos proyectos: el primero, durante unos meses,
00:10:00lo hice en un equipo llamado Conveyor. De hecho, creo que hay artículos públicos para el IEEE sobre
00:10:06Conveyor. Conveyor es probablemente uno de los sistemas de integración continua más grandes del planeta
00:10:11Por lo tanto, todos los artefactos de compilación generados para los servicios backend de Meta
00:10:18pasan por Conveyor, y se realiza un despliegue progresivo de los cambios en miles y miles de servicios backend
00:10:25¿Son estrictamente internos de Meta?
00:10:29Solo interno, sí.
00:10:31Pero sí, hay un artículo de Boris Gubrick que deberías leer
00:10:37sobre lo que construyeron y es muy, muy interesante.
00:10:39Así que estuve allí unos meses cuando lo estaban escalando
00:10:43y ayudándoles con las alertas, porque al principio
00:10:46recibes cientos de alertas a la semana y yo pensaba: «espera,
00:10:49vamos a limpiar esto».
00:10:51Y ya sabes, poner su observabilidad en un punto en el que al menos supieran cuándo ocurrían los fallos, y también
00:10:58preparé algunos...
00:11:00¿cómo dirías?, algunos procedimientos de emergencia para apagar funciones clave usando su herramienta de marcas de características
00:11:06um, solo para asegurarnos de poder recuperarnos rápidamente de los incidentes.
00:11:10Así que hice eso durante unos meses, pero la mayor parte de mi estancia la pasé
00:11:13en otro equipo que
00:11:16era una especie de Heroku interno. Tienes servicios sin estado muy sencillos
00:11:23y, ya sabes, los equipos los crean constantemente y necesitas ejecutarlos en alguna parte, y ese
00:11:29equipo y servicio existían para simplificar ese proceso, porque antes levantar un servicio era muy difícil. Así que fui el primer
00:11:37ingeniero de producción
00:11:40en ese equipo y fue bastante salvaje. Pero eso fue lo que hice allí.
00:11:44Definitivamente fue muy divertido. Había gente con la que trabajé que
00:11:48tenía un cerebro cinco veces
00:11:51más grande que el mío, ya sabes, la gente con la que trabajas en empresas así es simplemente
00:11:55superbrillante y aprendí muchísimo ahí. Iba a decir que creo que hay una empresa llamada Honeycomb y
00:12:02la persona que la fundó, Charity Majors, ¿estaba en Meta?
00:12:06¿La conoces?, ¿la conociste?
00:12:09Um, lo sé, es muy, muy interesante
00:12:12que preguntes eso. La conocí en un evento de Observability Days hace año y medio en Boston, la conocí en persona.
00:12:20Sí, trabajó en Meta, um,
00:12:22y la inspiración para Honeycomb vino de una
00:12:26herramienta de observabilidad a escala planetaria llamada Scuba.
00:12:30Exacto, así que usé Scuba y me encantó, y me alegra mucho que ella, um,
00:12:37haya fundado una empresa para hacer eso. Ella y yo hemos estado hablando en LinkedIn de vez en cuando últimamente
00:12:44debido a nuestro interés común en
00:12:47cómo la programación con agentes va a influir en la fiabilidad.
00:12:51Así que hemos estado hablando de ese tema de vez en cuando,
00:12:54pero sí, es una persona genial y es un privilegio charlar con ella de vez en cuando.
00:12:59Sí, sí, de hecho, esa es una buena transición hacia lo que también queríamos preguntarte. ¿A dónde crees que llevará la IA
00:13:06a la SRE, al DevOps y a todas estas prácticas?
00:13:13Vaya, de acuerdo. ¡Qué gran cuña publicitaria! Muchas gracias. Voy directo al grano aquí.
00:13:19Tenemos a ingenieros de software a los que se les ha dado
00:13:24una herramienta increíble, que es el desarrollo con agentes. Todo el mundo está consiguiendo que se genere código como por arte de magia de la nada, con herramientas como Claude y demás.
00:13:35Así que esto significa que va a haber una cantidad de código un orden de magnitud mayor
00:13:39fluyendo a través de nuestro
00:13:42flujo de valor, nuestras canalizaciones de CI/CD, nuestras pruebas, nuestras revisiones, nuestro despliegue de código, nuestra respuesta a incidentes, nuestros procedimientos de gestión de cambios...
00:13:50Todo este código va a pasar por el sistema que cada uno de nosotros ha construido para nuestras empresas,
00:13:56y eso significa que vamos a poner a prueba
00:13:58todas esas capacidades. Por ejemplo,
00:14:01existe una relación
00:14:04lineal
00:14:06entre el número de cambios que puedes hacer en una pieza de software y el número de avisos o incidentes que recibes.
00:14:12Eso es un hecho establecido,
00:14:14así que
00:14:15es razonable asumir que si aumentas el flujo de código a través de tu pipeline por diez,
00:14:20vas a tener diez veces más alertas.
00:14:23Entonces, ¿cómo
00:14:26respondería tu organización a eso? Esa es realmente la pregunta. Así que, desde el lado de SRE, anticipo
00:14:32que en el futuro los de operaciones vamos a ser muy, um,
00:14:39muy populares, porque vamos a ser donde esté el cuello de botella.
00:14:42Ya no se trata de escribir código y lanzarlo, sino de cómo lo operamos,
00:14:49¿funciona?, ¿está cumpliendo las expectativas del cliente?
00:14:51um,
00:14:53y
00:14:55por eso anticipo que ese será el gran cambio.
00:14:58Es un gran desafío, porque muchas cosas pueden salir mal durante esta transición.
00:15:04Como mencioné, puedes tener muchos más incidentes. ¿Cómo estás aprendiendo de los fallos
00:15:09y, ya sabes, sigues haciendo los post-mórtems?, ¿estás construyendo un pipeline de CI/CD que realmente funcione
00:15:15y que básicamente haga que el esfuerzo humano siempre tenga un alto impacto?
00:15:20Lo divertido es que llevamos décadas preparándonos para esto. Solo que, ya sabes,
00:15:27solemos pensar en ello en términos de las grandes tecnológicas donde hay 20 000 ingenieros,
00:15:31pero
00:15:33ahora tenemos organizaciones más pequeñas que pueden producir diez veces más código y, por lo tanto, el flujo es el mismo.
00:15:38Así que todos esos fundamentos
00:15:40sobre los que esas grandes empresas han estado escribiendo y hablando durante la última década,
00:15:47ahora todos vamos a tener que aplicarlos de verdad.
00:15:49Como todos los fundamentos, realmente tienes que cumplirlos. Y luego está eso,
00:15:53también está el asunto de que
00:15:56las organizaciones, como las de desarrollo de software, se han organizado bajo la idea de que, vaya, lo que lleva más tiempo,
00:16:03lo que consume más recursos, es codificar,
00:16:05así que debemos asegurarnos de que los ingenieros pasen el mayor tiempo posible programando.
00:16:09Si eso deja de ser cierto, tenemos que reorganizarnos en torno a aquellas actividades que ahora consumen más tiempo.
00:16:15Así que va a haber un pequeño cambio en la forma en que dirigimos estas organizaciones y, por último,
00:16:20y creo que has visto esto en términos de la tendencia de la IA en la SRE,
00:16:23de la que he hablado a menudo en mi pódcast, de que vamos a tener que introducir hábilmente
00:16:31esa tecnología en los lugares adecuados donde podamos sacarle mucho provecho para realizar esas operaciones, ¿verdad?
00:16:37Porque, por ejemplo, hay empresas ahí fuera, creo que un buen ejemplo es incident.io, en las que te avisan
00:16:44y, antes de que siquiera te levantes de la cama,
00:16:47ya hay un flujo de trabajo con agentes que dice: «de acuerdo, ¿qué cambios se hicieron en la base de código recientemente?
00:16:53¿Qué dicen realmente las alertas?, ¿qué dicen realmente las métricas?» e intenta
00:16:59hacer un diagnóstico de primera pasada, de nuevo, antes de que siquiera te levantes de la cama y te quites las lagañas de los ojos.
00:17:04Así que hay algunas áreas en nuestras responsabilidades operativas que pueden
00:17:09beneficiarse mucho de la IA, pero no adoptas todo a la ligera,
00:17:12sino que tienes que pensar cuáles son los problemas reales y cuál es el ROI.
00:17:16Pero en fin, esa es mi tesis. De hecho, voy a dar un seminario web en un par de semanas sobre este mismo tema.
00:17:23Eso es muy interesante porque, um, el caso de uso que mencionaste antes,
00:17:29levantarse de la cama y que ya te avisen sobre algo,
00:17:32¿eso ya se ha implementado en la práctica?, porque
00:17:36algo que veo que puede salir mal es que, digamos, tienes estos niveles de triaje donde en el primer triaje
00:17:43tal vez la IA pueda resolverlo por sí sola, pero luego, en el segundo, necesitamos un humano en el bucle. Y a veces lo que
00:17:51—solo para hacer una comparación con la programación— a veces veo que el código de Claude, cuando está razonando, dice:
00:17:56«Debería hacer esto», y luego dice: «espera un segundo,
00:17:59no,
00:17:59probablemente debería borrar todo esto, empezar de nuevo y hacer esto otro».
00:18:02Y siento que podría pasar lo mismo con estos bots de gestión de incidentes: dicen, «oh, esto es un arreglo fácil»,
00:18:10«espera, tal vez pueda solucionarlo yo solo», situaciones así.
00:18:13No, tienes toda la razón, 100 %.
00:18:15Creo que últimamente ha estado circulando esta cita de IBM de los años 70: «Nunca hagas que una computadora tome una
00:18:22decisión de gestión». Así que lo que quiero decir con esto es que hay dos formas de usar
00:18:27estas
00:18:29herramientas de IA, o la automatización en general. Hay dos filosofías sobre la automatización
00:18:32sobre las que la gente ha escrito. La primera se llama el principio de lo residual, donde básicamente dices: «oh, vale, vamos a hacer que el software»
00:18:38—no tiene por qué ser IA, pueden ser simplemente herramientas— «haga todas estas cosas por nosotros
00:18:43de forma autónoma en nuestro nombre, sin que tengamos que pensar en ello».
00:18:46Y entonces a nosotros, los humanos, se nos deja lo que sobra, que suele ser aquello que requiere un doctorado para resolverse.
00:18:51Um,
00:18:53a) eso
00:18:54no es muy manejable, porque entonces estás gastando todo tu presupuesto en doctorados,
00:18:57y además estás depositando demasiada confianza en un sistema que funciona de forma autónoma, y si toma la decisión equivocada, estás en problemas.
00:19:04La más
00:19:07manejable es lo que se conoce como principio compensatorio, donde lo que haces es multiplicar la fuerza del esfuerzo humano:
00:19:15permites que las computadoras y la automatización hagan aquello en lo que son buenas, y dejas que los humanos hagan aquello
00:19:22en lo que los humanos son buenos,
00:19:25que es
00:19:26Nosotros comprendemos el contexto de nuestros sistemas. Comprendemos el problema que intentamos resolver, comprendemos, ya sabes, la experiencia del cliente
00:19:33Hay una gran cantidad de contexto en nuestro cerebro que hace que sea mucho
00:19:38Más ventajoso para nosotros usar eso en lugar de dejar que la IA lo haga, que lo haga todo. Así que, para responder a tu pregunta de forma más directa
00:19:44Creo que esta reorientación hacia la IA realmente no debería estar
00:19:50Haciendo cambios en producción a menos que sea en un camino bien acotado y bien definido
00:19:58Te daré un ejemplo: reversiones automáticas de código. Hacemos eso automáticamente sin IA si estás pensando en Kubernetes
00:20:06verdad, si tienes un despliegue y estás cambiando, ya sabes, la versión de tu de tu nueva imagen de contenedor y tus
00:20:13comprobaciones de disponibilidad no tienen éxito. ¿Adivina qué?
00:20:16No va a desplegar el cambio
00:20:19Exacto. Así que esos mecanismos son muy sencillos, fáciles de comprender y nos permiten realizar cambios de forma segura
00:20:26Ya sabes, esos tipos de problemas bien definidos. Creo que puedes dejar que la automatización los haga y la automatización ya los está haciendo
00:20:32pero tener
00:20:35A la IA ahora mismo diciendo sí, deberíamos hacer este cambio en nuestra infraestructura sin intervención humana
00:20:41Creo que es irresponsable. Creo que nosotros, como humanos, volviendo al punto sobre las restricciones, creo que
00:20:46nuestro tiempo se va a desplazar hacia
00:20:49¿Es esta realmente la decisión correcta que tomar?
00:20:52Ya sabes, hacer esas esas esas aprobaciones, revisión de código y revisión de cualquier cambio en la infraestructura
00:20:59creo que va a ser donde
00:21:00vamos a estar dedicando gran parte de nuestro esfuerzo
00:21:03Y sí, vamos a querer automatizar eso donde podamos, pero requiere disciplina y un historial de seguridad
00:21:09Sí, y otra pregunta a partir de lo que decías antes es lo que comentaste sobre esta comparación lineal de que cuanto más código tienes
00:21:19más incidentes vas a tener, así que has estado trabajando como consultor
00:21:22en este campo. ¿Has oído que las empresas lo están experimentando ahora mismo, como
00:21:28que desde que están
00:21:30produciendo
00:21:31o delegando más código a la IA, están experimentando más incidentes como resultado?
00:21:36Sin duda, totalmente sí
00:21:39Totalmente sí, y también añadiría a eso que hay otros modos de fallo que están empezando a surgir debido
00:21:47a
00:21:49este cambio. Creo que uno muy fácil de pensar y razonar
00:21:53es
00:21:54que tus canales de CI/CD se están saturando, la latencia entre tener un artefacto de compilación creado y luego enviarlo a producción está tardando cada vez más
00:22:00porque simplemente hay más cambios pasando a través de él. Así que sí, las organizaciones están empezando a
00:22:05sentir estos puntos de dolor ya mismo. O sea, acabo de tener un rápido ejemplo de caso de estudio. Tengo un
00:22:12cliente para el que hice recientemente una evaluación porque una de las cosas que hago es examinar
00:22:17la postura operativa de toda la empresa, cómo lanzan el código, cómo lo ejecutan y darles orientación sobre qué hacer a continuación
00:22:24Así que uno de los equipos dijo, sí, esto de la IA es buenísimo, vamos a empezar a sacar características
00:22:31y lo hicieron, pero
00:22:33no cambiaron su forma de lanzar, no tenían un proceso de revisión de código bueno y sólido
00:22:38y por lo tanto el número de incidentes se disparó inmediatamente, así que en vez de
00:22:43centrarse en el código y simplemente enviar todas las cosas que pensaban que iban a hacer, estaban siendo sepultados por escalaciones de clientes
00:22:49e incidentes
00:22:51Así que, sí, esto no es teórico, está pasando ahora mismo
00:22:55este orden de magnitud incrementado de cambios a producción va a
00:23:01revelar
00:23:03todos los eslabones débiles en tu postura operativa
00:23:06Y cuando eres como un
00:23:09médico de SRE que tiene este cliente con este problema, ¿cuál es tu sugerencia sobre qué hacer en este caso,
00:23:16como acabas de mencionar?
00:23:18Exacto. Aludí a ello antes: todos esos fundamentos de los que hablamos
00:23:24durante la última década o dos, tenemos que centrarnos en ellos
00:23:27como los equipos
00:23:29necesitan, por ejemplo, los equipos necesitan tener una estrategia de pruebas válida
00:23:35Necesitan saber que el código que se están preparando para enviar a producción es de alta calidad
00:23:39Todas las cosas sobre las que han aprendido en el pasado o en las que piensan... Soy un gran defensor de los objetivos de nivel de servicio
00:23:43soy un gran defensor de los SLO
00:23:47porque eso nos permite comprender la salud de nuestro sistema de producción desde el punto de vista del cliente
00:23:52de modo que
00:23:54es una gran pieza del rompecabezas porque te permite regular de forma basada en datos la cantidad de cambios
00:23:59que estás haciendo en producción en términos de solicitudes de funciones y cosas por el estilo. De ese modo
00:24:03no estás arriesgando tu fuente de ingresos actual
00:24:07mientras persigues nuevas fuentes de ingresos
00:24:10Esa es la razón de negocio por la que quieres los SLO. Una cosa que he notado con los SLO en la empresa anterior en la que trabajé
00:24:16es que decían
00:24:19cada equipo debería, ya sabes, mantener sus objetivos de SLO y para algunos equipos, como íbamos tan rápido
00:24:25no estábamos cumpliendo esos objetivos
00:24:28y muchos equipos se estaban quedando atrás
00:24:30y la decisión de la dirección fue: da igual, es más importante lanzar funciones que mantener los objetivos de SLO
00:24:36Sí
00:24:37Y esa es probablemente la razón principal por la cual los SLO no han sido tan efectivos como Google prometió hace una década
00:24:44Porque aquí está el detalle, y ya he hablado de esto en contenido anterior: puedes tener un programa de SLO
00:24:49puedes pasar por el proceso de hacer que los ingenieros se reúnan en un rincón y digan, oh, ¿cuál es el recorrido del usuario?
00:24:55y vamos a cuantificarlo y vamos a configurar algo de observabilidad
00:24:57y configurar Prometheus u OpenTelemetry y obtener paneles muy bonitos, pero
00:25:01si el gerente de producto
00:25:05si la organización de producto no está dispuesta a colaborar
00:25:07si el equipo ejecutivo no está dispuesto a colaborar
00:25:09entonces
00:25:12es una pérdida de tiempo
00:25:14Entonces solo tienes a los SRE y tal vez a los ingenieros trabajando en un rincón diciendo oigan, las cosas no están sanas
00:25:19y ya sabes
00:25:21tienes a la directiva queriendo seguir lanzando. Para que los SLO tengan éxito
00:25:26tiene que ser un juego en el que todos participen, y cuando evalúo
00:25:32la postura de SLO de las organizaciones, lo cual es muy importante para mí, suelo hacer esa pregunta: si se agota un presupuesto de errores
00:25:38¿Qué hace el gerente de producto?
00:25:41Si el gerente de producto dice, de acuerdo, el próximo sprint vamos a cambiar el alcance del próximo sprint
00:25:46bien
00:25:48estás en una madurez media; si no lo hacen
00:25:50estás en una madurez baja. De hecho, desarrollé un modelo de madurez de SLO del uno al cinco —el uno siendo inmaduro y el cinco optimizando— para ayudar
00:25:58a las empresas a razonar sobre dónde se encuentran en el proceso, pero tienes razón, muchas organizaciones no
00:26:03hacen SLO. Tienen un panel, tienen métricas en él, a los ingenieros se les paga por ello
00:26:08pero
00:26:10las decisiones de negocio no se toman usando los SLO
00:26:12Son solo alertas
00:26:16Y entonces, el tipo de clientes que tienes que acuden a ti, ¿en qué
00:26:21situación están para que
00:26:24requieran tu asistencia? ¿Están en una buena situación, mala, intermedia?
00:26:28Depende. Hay dos puntos de inflexión con los que suelo trabajar con los clientes: el primer punto de inflexión es como
00:26:37la empresa en etapa temprana que acaba de recibir una ronda de financiación, su organización de ventas lo está bordando, tienen adecuación de producto al mercado
00:26:44pero están verdes y nunca antes habían gestionado infraestructura de nivel empresarial
00:26:49Nunca le habían vendido a clientes empresariales y están empezando a flaquear
00:26:53bajo la presión de esa mayor escala, muy similar a la experiencia que tuve al principio de mi carrera
00:26:59O sea, es algo que conozco muy, muy bien porque lo viví. Ese es el primer punto de inflexión
00:27:04Y ese es un punto de inflexión divertido. Es un buen problema que tener, aunque puede ser estresante para la gente que trabaja allí
00:27:09el segundo punto de inflexión
00:27:12es por lo general cuando eres una organización más grande y ahora necesitas empezar a estandarizar
00:27:17cómo operas a través de múltiples equipos
00:27:21Tal vez tengas un programa de SRE y necesites evaluar cuán efectivo es el programa de SRE, si los procesos funcionan
00:27:28si el modelo de colaboración funciona, si los equipos de ingeniería participan realmente en el proceso y si producto participa en el proceso
00:27:34Así que las empresas que, ya sabes, hacen muchas adquisiciones
00:27:37suelen acudir a mí porque intentan domesticar a esta fiera salvaje, porque cada vez que hacen una adquisición
00:27:44hay una pila tecnológica totalmente nueva que deben integrar, por lo que hay mucha gobernanza de alto nivel en la que hay que empezar a pensar
00:27:50en términos de asegurarse de que todos siguen las mismas reglas
00:27:55Claro
00:27:57Y creo que con las empresas más pequeñas, como mencionaste, aquellas que han recaudado algo de dinero
00:28:02con la IA presente y la gente usándola para construir características
00:28:06el tipo de falta de estructura aumentará, porque la gente simplemente crea características y las lanza con IA
00:28:13sin pensar en registros, métricas, trazas ni nada por el estilo
00:28:16¿Cuáles son las mayores cosas que has notado que las personas en la fase más pequeña de su empresa te traen como problemas
00:28:23que para ti son flagrantes pero que ellos no veían como un problema?
00:28:27Sí, o sea, creo que ya lo mencioné en una respuesta anterior, pero lo abordaré desde una perspectiva general
00:28:34así que
00:28:36lo más evidente que veo es un bucle de retroalimentación roto entre lo que ocurre en producción
00:28:41y lo que experimenta el cliente, y luego lo que sucede en términos de priorización de productos.
00:28:46Y lo he visto durante mucho tiempo en muchos equipos. Es probablemente el problema más común.
00:28:55Así que, cuando trabajo como consultor,
00:28:58una de las cosas en las que pienso tras bambalinas es cómo asegurarme de que se establezca ese bucle de retroalimentación.
00:29:03Así que es increíble
00:29:05cuántas empresas experimentan un incidente,
00:29:08los clientes se molestan,
00:29:10envían tickets a soporte y soporte se ve inundado
00:29:13de tickets. Soporte tiene este regalo increíble para darle a la organización de ingeniería de producto, que se llama comentarios. Ellos saben
00:29:23qué es lo que enoja al cliente, qué le impide disfrutar del servicio y qué los motiva potencialmente a irse.
00:29:30Y lo he visto una y otra vez
00:29:33que esos comentarios se ignoran por completo o se les da una prioridad menor que al trabajo de nuevas funciones,
00:29:41y el resultado final es
00:29:44a toda máquina con las funciones a pesar de que el producto está ardiendo, y eso para mí
00:29:51es algo que veo de inmediato cuando entrevisto y evalúo a los equipos.
00:29:55Pero por lo general, cuando trabajas dentro de la empresa, no lo ves porque piensas: oh, soy ingeniero de software,
00:29:59me incentivan a lanzar funciones. Envié 50 componentes el trimestre pasado, genial, voy a recibir ese bono.
00:30:05Los jefes de producto piensan lo mismo:
00:30:07sí, sacamos estos proyectos. Este cliente se está registrando con nosotros porque lo hicimos. Mientras tanto,
00:30:11los clientes actuales están furiosos, no están contentos con lo que está pasando.
00:30:16Así que hay un bucle de retroalimentación roto.
00:30:19¿Y eso se debe a la cultura en San Francisco o simplemente a que
00:30:22la gente solo quiere parecer mejor que sus competidores? No lo sé. ¿Por qué crees que pasa eso?
00:30:28No creo que sea exclusivo de San Francisco. Creo que es propio de los negocios en general, de las estructuras de incentivos, como
00:30:36de las culturas empresariales, porque
00:30:39cuando
00:30:41tienes
00:30:42diferentes departamentos,
00:30:44a medida que una empresa crece, y eso ocurre de forma natural porque hay que organizar el esfuerzo,
00:30:49se empieza a aislar en silos.
00:30:51Tengo ingenieros de software por aquí, tengo gerentes de producto por allá. Tal vez estén integrados
00:30:55con los equipos de ingeniería, pero tienen su propio conjunto de incentivos. Están los de soporte y los de DevOps y SRE,
00:31:01que tienen sus propios incentivos, pero todos están separados y entran en conflicto.
00:31:06Exacto, y
00:31:09por lo general,
00:31:11en esta etapa del juego, nadie se ha sentado con ellos para decirles:
00:31:13¿cómo cambiamos nuestra estructura de incentivos para que
00:31:18todos vayamos en la misma dirección? Una de las cosas que hizo Meta
00:31:21y que realmente me gustó, y creo que funciona muy bien,
00:31:25es que al evaluar el rendimiento de un ingeniero, al menos en los equipos con los que trabajé,
00:31:31no solo se fijaban en las funciones,
00:31:34sino en la excelencia operativa, la excelencia en producción, y analizaban en qué incidentes participaban,
00:31:41en qué trabajo de fiabilidad colaboraban, en qué trabajo de escalabilidad trabajaban.
00:31:45Cómo hacían que el sistema fuera más fiable y operable, y eso influía en si recibían el bono
00:31:51o si obtenían un ascenso. Era una parte importante
00:31:54de los criterios.
00:31:57Así que,
00:31:58cuando realmente empezaron a apostar por eso, significó que los incentivos para los ingenieros de software cambiaron, y en el equipo en el que estaba,
00:32:05donde realmente estábamos
00:32:07impulsando eso junto con los líderes de ingeniería con los que trabajaba,
00:32:12esos ingenieros mágicamente comenzaron a acercarse a mí para decirme: oye, me gustaría participar en tareas de fiabilidad contigo,
00:32:18¿puedo hacerme cargo de este proceso de pruebas de carga?
00:32:20Claro, por supuesto. Aquí tienes los manuales de procedimientos, algunos scripts y, ya sabes,
00:32:25adelante. Es increíble lo que pasa cuando los incentivos
00:32:29cambian. Así que
00:32:31creo que es una progresión natural para cualquier organización: si eres una pequeña startup donde todos se encargan de todo
00:32:38y estás intentando conseguir financiación y ganar esos clientes iniciales y mantenerlos contentos,
00:32:43creo que los incentivos ya están alineados,
00:32:45De lo contrario, la empresa no sobreviviría, pero a medida que creces y tienes esa separación de funciones,
00:32:51cada vez es más difícil mantener una estructura de incentivos alineada en toda la organización.
00:32:55Así que sí, aquí es donde surgen los temas sociotécnicos cuando hablamos de SRE y DevOps.
00:33:00Claro, y también mencionaste que con todo este avance a toda marcha hacia la IA,
00:33:06la gente necesitará a más personas como tú trabajando en este campo y, ya sabes, por otro lado,
00:33:12escuchamos que la ingeniería de software está muriendo, que ya no hay empleos, ¿verdad?
00:33:17¿Crees que, para los desarrolladores juniors que escuchan este podcast,
00:33:23SRE y DevOps son un buen campo para adentrarse en este momento específico? Sí, y sí, entonces
00:33:30yo me voy a oponer, no seré la persona que diga que la ingeniería de software ha muerto.
00:33:36De hecho, creo que los fundamentos
00:33:38son aún más
00:33:41importantes.
00:33:43Comprender los lenguajes de programación y cómo funcionan, los algoritmos y cómo funcionan, es aún más importante,
00:33:50porque
00:33:53¿cómo se supone que vamos a revisar el código que genera la IA?
00:33:56¿Y cómo se supone que diseñaremos sistemas que funcionen? Porque si simplemente le dices a un modelo LLM: Oye, diseña esto,
00:34:04¿estás seguro de que va a funcionar? Lo plantearé así: abre un proyecto de Claude Code
00:34:08y pídele que te diseñe un puente
00:34:11o un rascacielos.
00:34:15Y luego quiero que tomes ese diseño y vayas a construirlo.
00:34:18Y después quiero que te sientes en él. ¿Te sentirías cómodo haciendo eso?
00:34:22¿Te sentirías cómodo cruzando el puente que diseñó?
00:34:25Exacto, hasta que dejes de negar con la cabeza, necesitamos a esos ingenieros en su lugar.
00:34:31Claro, y en cuanto a la gente de SRE y DevOps, sí, obviamente
00:34:34necesita haber más de nosotros porque ahí es donde está el cuelloella de botella; si estamos haciendo tantos cambios en el sistema,
00:34:39definitivamente tenemos que asegurarnos de que esté saludable, de entender las implicaciones de los cambios en producción,
00:34:43de que tengamos una canalización CI/CD, una cadena de valor que, si lo extiendo al nivel más alto, sea
00:34:51saludable, esté monitoreada y sea tratada como un servicio de producción, porque a mi parecer lo es; todas esas habilidades van a cobrar aún más importancia.
00:34:58Es como la forma en que suelo verlo, es algo así como las carreras de F1, tienes un equipo de boxes
00:35:04y ese equipo de boxes lo sabe todo sobre el vehículo, puede cambiar cada pieza y le da al piloto la capacidad de dominar esa pista de carreras.
00:35:12Necesitas
00:35:15a estas personas, um, porque eso les da a los jefes de producto y a los arquitectos, ya sabes, el entorno para
00:35:22iterar rápidamente y poder lanzar esos cambios sin que surjan esas limitaciones
00:35:27así que en mi opinión
00:35:29es como
00:35:30es un gran momento para ser SRE. Siento que hace un par de años era diferente porque todo el mundo estaba siendo despedidos
00:35:35pero creo que
00:35:37si realmente te enfocas en los fundamentos, si entiendes
00:35:39ya sabes, Linux y los sistemas, así como los aspectos sociotécnicos, básicamente lo que significa ser realmente un SRE
00:35:46um, creo que puedes llegar
00:35:49muy lejos
00:35:51en esta carrera, pero debemos tener en cuenta la llegada del desarrollo agéntico
00:35:57No podemos hacernos de la vista gorda al respecto
00:35:59 Así que mencionaste
00:36:02¿Era The Phoenix Project? Sí, el libro
00:36:05Sí, entonces, ¿qué otros recursos crees que son valiosos para alguien que quiera profundizar mucho en este tema?
00:36:12Vaya, hombre, o sea, hay un montón. Déjame conseguirte los libros más importantes
00:36:18O sea, The DevOps Handbook es bueno. Sentí que cuando salió ese libro
00:36:21era un gran resumen de todo lo que había aprendido antes de que saliera el libro. Es una gran
00:36:27es una gran guía completa Leading Change de John Kotter
00:36:30trata sobre el liderazgo en el cambio transformacional y las organizaciones
00:36:34Te da un marco y cuando eres SRE en un equipo o si intentas impulsar una transformación de fiabilidad
00:36:41es algo bueno de conocer. El libro Toyota Kata
00:36:45que trata sobre cómo Toyota, ya sabes, hace la mejora continua en la fabricación de vehículos
00:36:52Muy útil, muy útil. Uno de los primeros en idear el sistema. Sí, creo que he oído hablar de eso. Sí
00:36:59Kaizen
00:37:02¿Era el concepto de Toyota?
00:37:04El milagro económico japonés es lo que creó Agile
00:37:07y DevOps, como si fuera el precursor de eso. Otro libro, The Practice of System and Network Administration
00:37:13Mencioné que creo que podrían tener una nueva edición, muy, muy útil
00:37:17Sí, los libros de SRE que produce Google son buenos, pero pondré una salvedad
00:37:22Esos son libros escritos por personas que trabajan para empresas que son absolutamente gigantescas
00:37:27y tienen un presupuesto infinito
00:37:30así que las prácticas y las formas en que hacen las cosas van a ser diferentes a las de tu
00:37:35startup de cuatro personas, pero creo que
00:37:37juntar todas esas piezas te dará una comprensión desde la perspectiva de un ingeniero,
00:37:44de
00:37:44un líder
00:37:46y de un estratega sobre cómo impulsar iniciativas de DevOps y SRE.
00:37:49Así que creo que tengo una perspectiva única porque lo pienso de forma holística. No solo me enfoco profundamente en
00:37:55todo lo que hago es Kubernetes y hago que Kubernetes funcione. Intento hacer que los equipos funcionen
00:37:59y luego, a partir de ahí, resolvemos los problemas técnicos.
00:38:03Y para todos los oyentes, dejaremos los enlaces de los libros mencionados en las notas del programa.
00:38:09Eh, iba a preguntar, volviendo al tema de la IA, estoy de acuerdo contigo en que la gente debe aprender los fundamentos y que
00:38:16la ingeniería de software o el desarrollo no van a desaparecer, pero hay una especie de tendencia
00:38:21en la que veo a más y más gente enviar código a producción sin revisarlo,
00:38:26y estoy seguro de que es gente de Twitter o X, o simplemente
00:38:30gente presumiendo, que no es del todo cierto.
00:38:32Pero, pero hay líderes de opinión, como personas que dirigen empresas de IA como Darío, eh Musk, que dicen, oigan,
00:38:39el próximo año, 2027, lo que sea,
00:38:41pueden escribir código y lanzarlo sin mirarlo, o pueden escribir código
00:38:47como código compilado sin escribir el lenguaje de programación, es decir, compilar ese código y por tanto los lenguajes estarán muertos. ¿Qué opinas de eso?
00:38:54Dudo mucho que estos líderes de opinión estén de guardia,
00:38:58porque si lo estuvieran, dirían algo completamente diferente.
00:39:02Ni hablar.
00:39:04No están, no están, no están en la infraestructura. No forman parte del grupo de seguridad de la información
00:39:08quejándose de las
00:39:09vulnerabilidades introducidas, ni están lidiando con lo que pasa cuando los clientes se enojan. O sea,
00:39:13claro, los LLM pueden producir
00:39:16código sintácticamente correcto y más o menos lógico.
00:39:21¿Lo escriben como en un 20 o 30 por ciento?
00:39:23Tal vez.
00:39:25Pero aun así,
00:39:29aun así,
00:39:31vas a seguir necesitando un monitoreo y una observabilidad adecuados,
00:39:37ya sabes, pruebas en producción. De acuerdo, si quieres pruebas en producción como defiende Charity,
00:39:42hay cierta inversión previa
00:39:45que tienes que hacer y, en su opinión,
00:39:48será la observabilidad, comprender el comportamiento de tu software; pero aun así, si yo,
00:39:54ya sabes,
00:39:56fuera un gobierno y necesitara comprar software,
00:39:59tiene que cumplir con mis controles de seguridad.
00:40:03Si fuera una empresa médica y estuvieras escribiendo software que es literalmente responsable de mantener con vida a los pacientes,
00:40:09¿De verdad crees que quieres que un LLM genere eso sin revisión? Eso sería imperdonable.
00:40:15Nos remonta al ejemplo del puente o el rascacielos. ¿De verdad quieres que un LLM diseñe un puente o un rascacielos
00:40:21y simplemente lo envíe, verter el mortero y las varillas, vámonos? No,
00:40:27no, absolutamente no.
00:40:31Sí, esa analogía del puente y el rascacielos es una forma muy buena de verlo, nunca lo había pensado así.
00:40:37Ya sabes, si fueras un ingeniero
00:40:39de cero a héroe, ¿te gustaría caminar sobre tu propio puente recién construido?
00:40:43Sí, y esto es lo que tenemos que pensar. Así que mi... mencionaba a Curtis,
00:40:49me encanta ese tipo, al principio de este episodio.
00:40:52Él era PE,
00:40:56un ingeniero profesional en ingeniería eléctrica, lo que significaba que fue a la escuela,
00:41:02hizo el examen PE, estuvo como pasante en una empresa durante varios años y luego, eventualmente, tras hacer un gran examen,
00:41:09entonces y solo entonces pudo hacer proyectos de ingeniería. Hay un alto nivel de disciplina
00:41:18en cómo
00:41:21haces las cosas. O sea, es lo mismo con los médicos.
00:41:23Aprendes la parte académica, pero luego estás en el campo durante años bajo supervisión antes de poder ejercer la medicina real.
00:41:30Y hay una razón para eso, es porque
00:41:33las decisiones que tomamos tienen ramificaciones masivas en las vidas de los seres humanos, en el medio ambiente y
00:41:40en el mundo, eh, y el software aún no se ha puesto al día
00:41:44con eso todavía.
00:41:47Y no estoy diciendo necesariamente que debamos emular esos modelos, pero
00:41:52sí tenemos que al menos
00:41:54reconocer los riesgos que estamos introduciendo. Necesitamos tener la disciplina de que, cuando construimos cosas que afectan las vidas de los seres humanos,
00:42:01debemos tener esa disciplina. Debemos pensar en el riesgo, debemos pensar en los resultados adversos,
00:42:05debemos asumir la responsabilidad y creo que
00:42:08hay muchas organizaciones que no quieren oír eso porque obstaculiza su capacidad de progresar,
00:42:14pero
00:42:16¿por qué escribimos software? Estamos resolviendo problemas para la gente, no deberíamos introducir otros nuevos.
00:42:23Sí, y es muy interesante lo que dijiste sobre tu amigo, perdón, olvidé su nombre, el PE, ingeniero profesional Curtis, porque Curtis,
00:42:31sí, porque aquí en Canadá
00:42:33se discutió que aquí, para poder llamarse ingeniero, realmente se necesita una certificación profesional.
00:42:40Y luego estuvo el debate de que los ingenieros de software no deberían tener el título de ingenieros porque no se han ganado esa certificación.
00:42:48Sí.
00:42:51Sí, eso resuena, eso resuena.
00:42:53Sí, el nivel de disciplina es completamente diferente entre nuestra industria y la de ellos.
00:42:57Sí, exactamente. Eh, quería tocar algo que escribiste en tu
00:43:03biografía de LinkedIn, mencionaste: del agotamiento y los cuellos de botella a equipos y sistemas fiables y de rápido movimiento.
00:43:12Entonces, ¿cuál es tu experiencia con el agotamiento?
00:43:16Dios mío. Tengo mucha experiencia con el agotamiento.
00:43:21Ya sabes, como persona de operaciones en organizaciones de rápido crecimiento,
00:43:26hay
00:43:28definitivamente personas con complejos de héroe, personas que quieren demostrar su valía, personas que tienen
00:43:35esos pequeños detalles en su psicología donde sienten que necesitan
00:43:39intervenir y adueñarse de las cosas. Es una vulnerabilidad, ¿verdad? El síndrome del impostor,
00:43:45todas esas tendencias que todos tenemos como personas, complacer a los demás, todas esas cosas pueden contribuir al agotamiento, en el que
00:43:52estás tan motivado por demostrar a los demás que estás haciendo un buen trabajo que no escuchas a tu cuerpo,
00:43:59no escuchas
00:44:02tus emociones, tu estado emocional. No eres introspectivo. No te das tiempo ni espacio para descansar.
00:44:08Tu relación con el descanso es disfuncional; hubo un período de tiempo en el que pensé que el descanso era malo,
00:44:14que la ociosidad
00:44:16era una pérdida de tiempo, cuando ya sabes,
00:44:20en esta etapa de mi vida en la que pienso mucho en estas cosas, no, el descanso
00:44:25te da la capacidad de hacer grandes esfuerzos más adelante.
00:44:29Ya sabes, la gente que hace culturismo no está en el gimnasio todos los
00:44:35días trabajando cada grupo muscular, se dan tiempo
00:44:40para reconstruir las fibras de sus músculos.
00:44:45¿Entonces por qué
00:44:47decimos
00:44:49que no podemos hacer eso cuando se trata de nuestras mentes?
00:44:51Ese es el tema, pero recuerdo
00:44:55que después de dejar Meta, fui como el paciente cero en la gigantesca ola de despidos,
00:45:01así que me afectaron los despidos. Sí, lo siento por eso.
00:45:04Oh, no, o sea, seguro, Moto no existiría si no fuera por eso. Ah, genial.
00:45:08De las cenizas un fénix, ¿verdad? Cien por ciento, esa fue mi respuesta ante ello.
00:45:13Pero ese período en el que estoy empezando mi propio negocio
00:45:18y dando un paso atrás en la industria para pensar en cómo quiero trabajar, realmente me hizo
00:45:23ser muy consciente del agotamiento que cargaba conmigo y que no estaba reconociendo.
00:45:32Y recuerdo que al principio de mi carrera era el típico administrador de sistemas gruñón, y si hay alguien
00:45:38de Acquia o exempleado de Acquia escuchando esto, sabe de qué estoy hablando.
00:45:42Yo solía ser muy gruñón,
00:45:44y ahora soy muy jovial porque he trabajado un poco en mí mismo, pero
00:45:49eso era agotamiento y no lo reconocía.
00:45:51Simplemente pensaba que demasiada gente se acercaba a pedirme cosas
00:45:56cuando deberían hacerlo por sí mismos, como lean la página man, ¿saben a qué me refiero?
00:45:59Lidié con mucho agotamiento y creo que mi negocio y la forma en que lo manejo me dan
00:46:04el espacio
00:46:07para
00:46:08enfrentar esos desafíos directamente e interactuar con el trabajo de una manera más saludable,
00:46:13que se adapte mejor a cómo funciona mi cerebro, a lo que quiero en mi vida y a asegurarme de que
00:46:20Sabes, no estoy
00:46:23viviendo para trabajar. Estoy trabajando
00:46:25para tener experiencias que me enriquezcan. ¿A qué me refiero?
00:46:28¿Qué opinas de eso? Sé que me desvíe un poco.
00:46:31Iba a decir que lo del sysadmin
00:46:34amargado... Me identifico con eso, no por mí, sino por empresas en las que he trabajado, siempre hay un tipo que
00:46:40sabe levantar Kubernetes o lo sabe todo sobre AWS, y si quieres algo de él,
00:46:44te pone caras y luego va y lo hace, pero no quiere hacerlo, así que puedo relacionarme con eso,
00:46:49pero entiendo por qué pasa y de dónde viene, simplemente por el hecho de que ocurre mucho y
00:46:56puedo ver esa frustración.
00:46:59Y sí, creo que es bueno tomarse un descanso de eso y, um, tienes que trabajar en ti mismo y probar otras cosas,
00:47:05sin duda. Hay responsabilidad personal en eso, pero también ser muy consciente de la cultura
00:47:11de los entornos en los que trabajas, de los equipos, de la gente con la que interactúas
00:47:15y asegurarte de elegir los lugares que sean mejores para ti. Sé que el mercado laboral sigue un poco extraño,
00:47:21puede ser difícil tomar
00:47:22ese tipo de decisiones y poder decir simplemente que vas a ir a otro lugar.
00:47:26Eso puede ser muy difícil, lo reconozco también, pero al menos ser consciente
00:47:30de dónde estás y escuchar tus emociones, escuchar a tu cuerpo y hacer algo al respecto,
00:47:36creo que es una gran parte del rompecabezas. Hay una
00:47:39doctora, la doctora Maslach, que creó algo llamado inventario de burnout
00:47:44Lo diseñó originalmente para el personal médico porque ella estaba en el campo de la medicina,
00:47:49pero el inventario de burnout y su investigación son sumamente aplicables a la tecnología.
00:47:56Y puedes incluso
00:47:58ver algunas de sus charlas. Creo que hizo...
00:48:01creo que daba charlas para el evento anual de DevOps que el autor de The Phoenix Project
00:48:06organizaba, así que
00:48:08sí,
00:48:09he leído un poco sobre el aspecto clínico del burnout además de experimentarlo personalmente.
00:48:15Sí, y me alegra muchísimo que este despido se haya convertido en algo bueno para ti, que abrió el camino
00:48:24para que establecieras tu propia empresa, y me parece muy interesante que, por lo que veo en tus publicaciones,
00:48:31diriges esta empresa
00:48:33básicamente en la carretera, ¿verdad? Estás
00:48:35viajando todo el tiempo. Básicamente llevas un estilo de vida nómada. ¿Es correcto? Así es.
00:48:42Vivo de forma nómada, estoy literalmente en esta llamada usando Starlink en medio del desierto en Nevada ahora mismo.
00:48:50Convertí mi camioneta Tacoma...
00:48:54La llamo Molly. Convertí mi camioneta en una
00:48:59estación de combate móvil. Estoy de pie
00:49:02en la caja de la camioneta
00:49:04um
00:49:05y tengo un espacio cómodo para dormir, 300 vatios de energía solar,
00:49:09un refrigerador, un sistema de energía que construí yo mismo. Así que hice de esta
00:49:16microcasa a partir de esta camioneta y he trabajado desde todas partes, desde mi terreno aquí en Nevada hasta
00:49:23el estacionamiento de un cine AMC en Boston, o sea, trabajo desde cualquier lugar, lo cual es muy divertido.
00:49:29Llevo haciendo este tipo de cosas
00:49:31durante dos años y medio. Empecé Shirtomoto hace tres años,
00:49:34he vivido de forma nómada los últimos dos años y medio y ha sido la mejor experiencia y aventura de mi vida.
00:49:41Ya sabes,
00:49:43trabajando en las montañas, una vez un oso se subió a mi camioneta.
00:49:46Ah, guau.
00:49:48Sí, ¿cómo fue eso?
00:49:51Fue un poco aterrador. En aquellos días estaba en una tienda de campaña de techo,
00:49:54no en mi cámper actual. ¿Era un oso negro o un oso pardo?
00:49:58Bueno, sigo vivo, por lo tanto era un oso negro. Ah, qué bien.
00:50:02Era el oso negro más grande que he visto en mi vida, era gigantesco.
00:50:06Estaba buscando cestas de pícnic o algo así,
00:50:08pero
00:50:09se metió a la caja de la camioneta donde yo estaba durmiendo arriba, en el soporte con la tienda de techo, y desplazó el peso.
00:50:17Tuve que sacar las llaves del bolsillo, presionar el botón de la alarma y hacer eso,
00:50:21y luego el oso huyó cuando sonó la alarma.
00:50:24Sí, después de eso entendí la necesidad de construir algo cerrado, como esto. Al menos el oso no me ve ni puede entrar, así que
00:50:30o entrar allí, así que
00:50:33Mencionaste Nevada y Boston, así que has hecho un viaje de costa a costa con tu camión cada año. Sí, cada año.
00:50:42De hecho, planeo regresar al noreste en un mes. Ahora mismo tengo un remolque de carga de seis por diez que estoy convirtiendo
00:50:48como que después de esta llamada voy a perforar agujeros e instalar ventanas y ventiladores,
00:50:52e instalando mil vatios de energía solar y haciendo todo el proceso, y va a ser mi
00:50:58mi centro de mando y oficina móvil en el que pueda trabajar cuando el clima sea clemente.
00:51:02Eso es genial. Y para algunos ingenieros o personas que también estén interesadas en esto,
00:51:08¿cuál es el precio de construir una casa rodante así como la que has hecho?
00:51:13Quiero decir, lo del remolque de carga es bastante económico, puedes conseguir uno por unos cuatro o cinco mil y luego
00:51:20lo que necesites hacerle, el precio puede subir, pero necesitas aislarlo,
00:51:24obviamente necesitas algo de ventilación, algo de electrificación.
00:51:27Hay todo un universo de personas ahí fuera que hacen este tipo de cosas.
00:51:31Um, soy solo uno de los pocos que combinó la vida nómada con la tecnología y la hizo funcionar.
00:51:36Pero ya sabes, el camión es una Tacoma con una camper personalizada encima de una empresa llamada Go Fast.
00:51:41Compré esta usada, pero um...
00:51:44Sí, realmente depende de cuáles sean tus necesidades. O sea, veo a gente arreglándosselas en un Prius,
00:51:51ya sabes, y también veo a gente en vehículos más sofisticados, pero
00:51:55sí, el costo de entrada puede ser bajo si sabes un poco de autos y estás dispuesto a
00:52:01ya sabes, poner manos a la obra y trabajar.
00:52:04¿Qué te inspiró a empezar esta aventura de
00:52:07acampar y viajar y
00:52:10mejorar tu auto?
00:52:11Sí, um, bueno, solo había vivido en dos lugares antes de
00:52:14este viaje y me pasaba la vida entera trabajando y básicamente haciendo lo que la gente me decía que hiciera,
00:52:21lo que se espera de un joven, ya sabes, vas a la universidad, obtienes tu título, consigues un buen trabajo,
00:52:26asciendes. Hice eso
00:52:28y
00:52:29y al final de ese camino corporativo, me di cuenta, caramba, no soy tan feliz como
00:52:34debería ser al respecto; he logrado algunas cosas masivas, pero no lo siento, y desde que comencé mi propio negocio y me di cuenta, oye,
00:52:41¿realmente quiero pagar tanto alquiler en el área metropolitana de Boston?
00:52:44Si no me quedaba en Boston, ¿qué haría? Y encontré un video de YouTube de este tipo que tomó un camión de U-Haul,
00:52:51ya sabes, como un camión de mudanzas,
00:52:53y lo convirtió en un apartamento sobre ruedas y pensé:
00:52:55¿Eh?
00:52:58Eso es genial.
00:53:00Y comencé a adentrarme en este agujero negro de YouTube y a enterarme de que hay como toda
00:53:05una comunidad de personas que viven así y simplemente
00:53:08investigué y vi un montón de YouTube y luego decidí, lo vendí todo,
00:53:13no renové el contrato de alquiler de ese apartamento
00:53:16y conduje hacia el oeste en mi Civic y unos meses después conseguí a Molly y lo armé y
00:53:22y comencé... pero sí, era comprender que tenía un montón de
00:53:28experiencia de vida que necesitaba ponerme al día.
00:53:31Um, ya sabes, pasaba demasiado tiempo, irónicamente, en un podcast de tecnología, pasaba demasiado tiempo
00:53:37frente a la computadora y no el suficiente tiempo ahí fuera en el mundo, y me di cuenta de que necesitaba esa experiencia para equilibrarme porque
00:53:44soy algo más que un tipo obsesionado con la programación; soy un ser humano con mi propio
00:53:49estilo,
00:53:52tengo experiencia, necesito salir y tocar un poco de pasto.
00:53:55Tengo que tocar un poco de pasto y he tocado mucho más que pasto aquí en el mundo: rocas,
00:53:59ya sabes, montañas, agua, todo tipo de cosas. Hay todo tipo de cosas que tocar por aquí. Sí, 100%.
00:54:04Así que mencionaste lo del oso, ¿has tenido alguna otra
00:54:08aventura interesante mientras estabas en la carretera?
00:54:12O sea, tantas, o sea, hice el paso Cinnamon en Colorado con amigos, que es una ruta todoterreno, ya sabes,
00:54:18un poco técnica, un poco desafiante; he estado en Wyoming, he estado en Yellowstone, Grand Teton;
00:54:24he acampado en terrenos públicos cerca de allí donde se pueden ver los osos. A veces escucho
00:54:30burros salvajes por donde estoy, vi caballos salvajes hace unos días.
00:54:34Puedes oírlos caminar y miras por la ventana de la tienda y ahí están, hay unos caballos,
00:54:39um...
00:54:41Pero sí, he recorrido el país de punta a punta unas cuantas veces
00:54:45um
00:54:47y sí, ha estado bien. Tengo una novia que está dispuesta a
00:54:51complacer mis locuras y vivimos aventuras juntos.
00:54:54em, y sí, ha ha sido divertido. o sea, eso podría ser un episodio entero sobre todos los lugares locos en los que he estado
00:55:01Ah, sí
00:55:03Eso suena genial. Probablemente haya un episodio en tu propio podcast, ¿verdad?
00:55:08Sobre esto, sabes, debería haberlo porque normalmente suelo... bueno, como traigo a un invitado y estamos hablando, ya sabes
00:55:15del tema, pero tal vez debería hacer uno yo solo hablando de esto
00:55:20Sí, incluso las... las opiniones y tus lecciones sobre el agotamiento, creo que sería un
00:55:25episodio muy útil para muchos ingenieros, especialmente hoy en día, porque siento que
00:55:29nos han prometido que la IA
00:55:33nos hará más productivos y que trabajaremos menos horas, cuando en realidad siento que es lo contrario, básicamente
00:55:41a veces simplemente te estás agotando por la cantidad de trabajo que se espera que hagas con estas herramientas ahora disponibles
00:55:50Sí, mis opiniones al respecto probablemente se considerarían muy subversivas
00:55:53Y lo dejaré así, o sea, donde necesitamos... necesitamos más trabajadores, seamos honestos
00:55:58Eso es lo que somos. Somos trabajadores. Necesitamos condiciones que sean más humanas
00:56:03Totalmente
00:56:06Sí, de acuerdo
00:56:08Siempre nos gusta preguntar a nuestros invitados: ¿Tienes alguna opinión polémica sobre SRE, DevOps,
00:56:14IA o cualquier cosa relacionada con la tecnología? Sí, sí. Muy bien, opinión polémica, y lo digo con la mayor cantidad de
00:56:22respeto, no pretendo acaparar la práctica de SRE
00:56:26pero diré esto: si tienes un rol de SRE, si tienes un puesto de trabajo
00:56:29que es SRE
00:56:32y ahora mismo estás en un rincón escribiendo YAML
00:56:34y recibiendo alertas
00:56:37quiero que te plantees realmente si eso es de hecho un rol de SRE
00:56:40SRE es una práctica en la que tomas un sistema no tan fiable
00:56:45y lo transformas en un sistema fiable
00:56:47y haces felices a los clientes a través de los SLO
00:56:50gestión de trabajo rutinario, planificación de capacidad, ¿verdad?, todas esas responsabilidades operativas de orden superior y utilizando la ingeniería de software
00:56:59Eso es muy, muy importante. Eso es la práctica de SRE
00:57:01Así que YAML no es un lenguaje de programación si eso es lo que haces la mayor parte del tiempo
00:57:06Te animo a que, ya sabes, te adentres en aguas más profundas. Es genial por aquí
00:57:11hay una gran comunidad, mucha gente que estará más que feliz de enseñarte, pero
00:57:15asegúrate de encontrar roles que te desafíen y te ayuden a crecer
00:57:18El libro “The Phoenix Project” hizo popular la palabra DevOps y desde entonces hay gente que son ingenieros de DevOps que hacen qué?
00:57:26Dijiste algo como escribir YAML y
00:57:29deletrear Kubernetes y todo eso, y es como si el DevOps
00:57:33del que hablaba el libro no fuera alguien que hace eso. Es más como lo que explicaste, conectar dos diferentes
00:57:39¿cómo era la palabra? ¿no sistemas, sino disciplinas?
00:57:43Y creo que es bastante común, como dije en el mundo, ver “soy un ingeniero de DevOps”
00:57:48“estoy aprendiendo DevOps” y es como que no es eso, es
00:57:51lo que explicaste, es difícil ahora tender ese puente porque ahora es tan común que la gente sea ingeniera de DevOps
00:57:56que ya no se ve como lo que explicaste. Pero sí, es difícil dar marcha atrás ahora, ¿no?
00:58:02Sí, o sea, estamos hablando de semántica y nombres, así que intentaré matizar lo que digo cuando me refiero a DevOps
00:58:09Sí, en efecto
00:58:10No estamos hablando de un conjunto de herramientas. No estamos hablando de un equipo específico, ya sabes, título, herramienta o equipo, la gente habla de esto
00:58:15todo el tiempo. No, no es eso, es la práctica de unir
00:58:19tecnología, personas, liderazgo y procesos para que podamos entregar software al cliente de una manera que sea lo más rápida posible
00:58:27productiva y sea lo mejor posible para el negocio, o sea, eso para mí es lo que es DevOps y el medio para llegar
00:58:34ahí es inverso
00:58:35No es solo Kubernetes, Kubernetes es una pieza del rompecabezas. No es solo, ya sabes, CI/CD
00:58:40Es una pieza del rompecabezas. A veces también es sentarse y escuchar a la gente. A veces se trata de construir visión y estrategia, a veces
00:58:47ya sabes, se trata de darles el día libre a tus equipos después de que les hayan enviado demasiadas alertas a las 3 a. m.
00:58:52DevOps se trata de esa visión
00:58:55holística en lugar de solo las herramientas, las herramientas son atractivas, lo entiendo, la gente quiere vender las herramientas
00:59:01pero eso es solo una faceta de toda la experiencia. Sí, hablando de herramientas, ¿tienes alguna herramienta favorita que uses?
00:59:08Vaya, okay. Eh, déjame... déjame pensar en eso. Sí, voy a... voy a proponer una. Así que
00:59:14últimamente
00:59:15ha habido muchos incidentes en GitHub recientemente
00:59:20y nos hemos acostumbrado un poco a: “Oye, me gustaría que mis procesos de compilación y mis tuberías de pruebas estuvieran
00:59:26en servidores propios”. Hay una herramienta que puedes ejecutar en su lugar si quieres alojar tus propias cosas
00:59:32llamada Concourse
00:59:35Y me gusta Concourse. Te permite construir
00:59:38pipelines muy sofisticadas para pruebas, compilación, entrega o lo que sea usando YAML, cada pequeña sección se ejecuta en un contenedor
00:59:47pero lo alojas tú mismo y la razón por la que realmente me gusta
00:59:50es que la comunidad de código abierto
00:59:53como la gobernanza es... es su propio modelo de gobernanza
00:59:56No pertenece a una empresa que pueda, ya sabes, cambiar la licencia y convertirlo en un SaaS
01:00:01lo cual hemos visto muchas veces en otros proyectos. Así que si te estás frustrando con,
01:00:06ya sabes,
01:00:09usar el servicio en la nube de moda para tu CI/CD, echa un vistazo a Concourse, úsalo, ejecútalo en tus instalaciones
01:00:16Ya sabes, tal vez retrocedas cinco o diez años en cuanto a filosofía, pero podría ser más estable. ¿Quién sabe?
01:00:20Genial. Nunca había oído hablar de él. Tendré que investigarlo
01:00:23Sí, yo también
01:00:26Sí, es bueno. Oh, hay... hay algunas empresas por ahí que definitivamente lo usan
01:00:29Y sí, los amigos no dejan que sus amigos ejecuten Jenkins, o sea, eso ya pasó. No hagas eso. No hagas eso
01:00:35Así que estás diciendo que Jenkins está muerto
01:00:38¿Dije eso?
01:00:41No, no, no, solo... no era la pregunta trampa
01:00:44Pero lo que sí digo es que hay... hay más opciones
01:00:47y no creo que la gente quiera escribir scripts en Groovy nunca más. Así que sí
01:00:51otras cosas que hay por ahí han sido un dolor de cabeza para mí también
01:00:54Sí, cuando lo he usado
01:00:57Sí
01:00:59Muy bien
01:01:01¿Hay algo que quieras promocionar, como... tienes un podcast, hay algo más de lo que quieras hablar antes de terminar?
01:01:06Claro, hagá-moslo. Siempre lo agradezco. Sí
01:01:09Yo... soy consultor en mi empresa Cherto Moto. Eso es c-e-r-t-o-m-o-d-o.io. Me especializo en evaluar
01:01:18la postura de confiabilidad, DevOps y SRE de las empresas. Si te pajan mucho
01:01:22si no lanzas con frecuencia, si los clientes están enojados
01:01:26deberías definitivamente apartar un espacio en mi calendario. También conduzco un podcast llamado Reliability Rebels
01:01:31donde entrevisto a personas hablando sobre
01:01:33cómo SRE no son solo las herramientas, sino también desafiar el statu quo
01:01:38hablando de lo sociotécnico, y luego el 24
01:01:41de febrero, voy a hacer un... un seminario web sobre
01:01:45la
01:01:47avalancha de código de la IA
01:01:48Creo que lo llamo el tsunami de código de IA. Em, y hago seminarios web mensuales hablando de todo tipo de temas interesantes
01:01:54así que si estás interesado, echa un vistazo a mi sitio web y podrás enterarte de todo eso. ¡Muchas gracias por la oportunidad de promocionarlo!
01:01:59De nada. Gracias. Gracias por
01:02:03hablar de todas estas... perdón, aventuras y lecciones aprendidas. Ha sido muy divertido tenerte
01:02:09Así que gracias a todos por escuchar este episodio del Better Stack Podcast
01:02:13Suscríbete a nuestro programa donde sea que consigas tus podcasts, Apple, Spotify, YouTube, elige tu opción, pero por ahora
01:02:20es un adiós de mi parte
01:02:22es un adiós de mi parte
01:02:25y un adiós de mi parte
01:02:33(música alegre)