En el año 2013, se puso en contacto conmigo Google para concertar una entrevista de trabajo para varios puestos que tenían en el centro de Google en Dublín. Por aquel entonces, yo vivía en Londres. Mudarse a Dublín para trabajar en Google, si el trabajo era interesante, no iba a ser un problema. La primera entrevista, sobre Linux y redes, fue bastante bien. Las típicas preguntas sobre cómo se gestiona la memoria en dicho sistema operativo, tipos de terminación de los procesos, así como preguntas sobre estructuras de algunos paquetes de red, checksum, y demás. La entrevista fue muy bien. Al cabo de unos días me llamaron para una segunda entrevista para tratar temas un poco más en profundidad. Me ofrecían un puesto de Site Reliability Engineer (SRE).
Yo no sabía lo que era un SRE, pero una búsqueda rápida por internet me llevó a una página de Google donde se detallaba concretamente en qué consistía dicho perfil. Supongo que después de estar varios años como desarrollador y arquitecto, las responsabilidades de un SRE no me llamaban mucho la atención. Me parecía un perfil de soporte, al que me negaba a moverme. Mi interés estaba más en la creación de soluciones, y no en el soporte de las mismas. Así que les dije que no me interesaba. Pero el tiempo me ha demostrado que estaba equivocado.
En los últimos 5 años, hice una transición desde arquitectura pura de aplicaciones, a infraestructura y arquitectura de soluciones en la nube. Entre mis responsabilidades estaba la de preparar los entornos de producción, configurar el servicio CI/CD, configurar los registros de imágenes de Docker, supervisar que la arquitectura de las soluciones que se desarrollaban eran seguras, escalables y fiables. Es decir, me había convertido en un SRE. Con una excepción. Cuando la solución se desplegaba en producción y se entregaba al cliente, se hacía una transición a un equipo de soporte puro y duro, que eran los encargados de mantener los sistemas en producción. Cuando se encontraban con determinados problemas relacionados con la infraestructura y los servicios en producción, los escalaban a nuestro equipo para solucionarlos. Es decir, que en teoría, en la empresa existe un equipo de infraestructura y arquitectura de sistemas, y un equipo de soporte gestionados de forma separada. Pero en la práctica, son en realidad son dos equipos que están condenados a unirse y trabajar al unísono. Es un equipo de SRE dividido.
Y es que soporte es SRE, pero SRE no es soporte. Me explico. Entre las responsabilidades de un SRE está la de responder a incidentes en producción, pero eso solo debería ser, como mucho, un 20% de su tiempo. El 80% del tiempo restante es desarrollar soluciones para que los servicios sean más fiables, para mejorar la observabilidad, para mejorar la seguridad, para automatizar procesos, para minimizar el tiempo de caída del servicio en los despliegues, y mucho más. La ‘E’ en SRE significa ingeniería. Es la práctica de, mediante ingeniería, velar por la fiabilidad y seguridad de las cargas de trabajo en producción.
Con el tiempo he ido madurando la idea errónea que tenía de SRE en el 2013. Ahora, que llevo años despegado del diseño y desarrollo de aplicaciones de forma directa, y con un perfil más de infraestructura y arquitectura de sistemas, veo la práctica de SRE mucho más interesante y enriquecedora. Pero sobre todo, como una práctica que puede darte un reto nuevo cada día ¿A quién no le gustan los retos? La obligación de un SRE es minimizar el tiempo que se dedica al soporte mediante la automatización y autorecuperación de los sistemas. Y para eso hace falta mucha ingeniería. Hace falta observabilidad para tomar decisiones objetivas, basadas en datos, a la hora de refactorizar un sistema. Y también para trabajar en potenciales incidentes de forma proactiva, y no reactiva cuando estos ocurren. Cada incidente que ocurra es en realidad una nueva oportunidad para rediseñar la solución y hacerla más fiable. Hacen falta sistemas inteligentes para restablecer servicios de forma automatizada. Hace falta redundancia y coordinación entre sistemas para que las actualizaciones no afecten al servicio.Y mucho más.
No te diría que el de SRE es el trabajo más importante en una empresa de internet, pero sí es quizás el más crítico. Yo me montaría en un cohete feo como el de Jeff Bezos, pero no en un cohete que no sea fiable. Por eso, ahora en el 2021, me interesa más que nunca el perfil de SRE. De hecho, el lunes pasado empecé como Head of SRE en Epos Now, una empresa que ofrece un servicio de puntos de venta en la nube. En la actualidad tenemos más de 41000 clientes por todo el mundo, cada uno con múltiples terminales tirando de nuestros servicios. La fiabilidad y seguridad tiene que ser excelente. Quedarnos sin servicio significa dejar inoperativos a miles de restaurantes y comercios. Sin duda, tengo todo un reto de ingeniería, y no de soporte, por delante.
¡Muchas gracias por leerme!