Hola, ¿Cómo están? Bienvenidos a este segundo programa de Top Dev La Entrevista, programa de Hireline donde podrán conocer de cerca la experiencia de muchos expertos de la industria y en esta ocasión tenemos a Josué Padilla para platicarnos cómo es trabajar como Site Reliability Engineer, en ThredUp, en Estados Unidos.

¿Qué es un Site Reliability Engineer?

Un SR para abreviar, es una posición que es muy parecida a un DevOps Engineer, pero básicamente es alguien que está encargado de que el sitio o la plataforma o en la aplicación funcione siempre.

Y esto conlleva a estar atento en el monitoreo, de que el rendimiento de la aplicación sea el óptimo, estar checando sobre actualizaciones de software, baches, estar trabajando junto a los desarrolladores para planear bien la arquitectura de los sistemas para estar viendo todo desde muy, muy gran escala, y encontrar cuellos de botella. Todo con el fin de que la plataforma funcione como tal.

¿Qué tecnologías o lenguajes utiliza un Site Reliability Engineer?

Es bastante amplio porque un SR está muy metido también en el desarrollo. Entonces, creo que es muy, muy importante también conocer de programación.

Casi todos los SR que conozco, siempre han tenido un background de desarrollo, incluyéndome, que empezaron como software engineer. Y después de ahí fueron transicionando a posiciones más relacionadas con esto. Es muy importante conocer al menos un lenguaje de programación, ya sea Java, Python, cualquiera.

¿Qué herramientas utiliza un Site Reliability Engineer?

Existen herramientas que casi son las mismas que se comparten con DevOps.

¿Cómo fue tu primera experiencia como Site Reliability Engineer?

Yo empecé como Infrastructure Engineer, más enfocado a automoción de infraestructura, estar manejando AWS, cuentas de la nube que tenemos y entre otros, que igual es al final como quien dice “sigo haciendo las mismas cosas, nada más cambia el nombre”

Cuando empecé yo estaba inclinando más por el lado de desarrollo y también lo que se conoce como platform engineer, que comparten mucho unos un poco más inclinados en una u otra cosa, pero al final de esos, son como combinar operaciones y desarrollo.

¿Cómo es el trabajo de un Site Reliability Engineer en una empresa de Estados Unidos?

En el trabajo no hay tanta diferencia porque al final necesitas estar sacando las cosas. Igual y puede variar un poco como en qué tan avanzados están en cuanto a la adopción de tecnologías.

En Estados Unidos es más común que sale algo nuevo e intentas usarlo. Lo que sí es que yo por ejemplo no tengo ningún compañero de equipo aquí en México. O sea, yo soy la única persona que está en México, todos mis compañeros están en Estados Unidos o en Europa.

Creo que sí es algo que te cuesta un poco acostumbrarte, por las diferencias de cultura, por la forma de educación, de que todo es absolutamente en inglés. No es difícil, pero tardas un poquito en acostumbrarte, no la forma de trabajar, sino como los cambios de cultura, a cómo es el día a día allá, cómo se maneja.

¿Qué importancia tiene el inglés para un Site Reliability Engineer?

Es súper importante, ha sido indispensable y es la diferencia de que por más bueno que seas, si no sabes inglés, está limitado a las empresas que puedes encontrar aquí en México hablando de salario, de crecimiento, de prestaciones, de todo. Aquí en donde estoy trabajando cero español, nadie habla español. Entonces, el 100% de toda la comunicación, tanto escrita como por llamada, es en inglés.

Igual en algunos casos, por ejemplo, si trabajas en una consultora o en algo así, no lo necesitas dominar tan al 100%. Aparte es posible o muy probable que tus compañeros de equipo estén ahí contigo y tal vez su manager es el que se tiene como comunicar con los demás.

¿En alguna empresa te ofrecieron algún apoyo para que mejoraras el inglés?

Aquí en el caso particular donde estoy, no. No es como algo que ofrezcan, aquí esperan que hables inglés, podrías pedirle a alguien que te ayude a algo, pero no, no es algo que se ofrezca ahí.

En la mayoría de las empresas que yo he visto en donde estaba antes sí era muy común que se organizaban clases de inglés o incluso es una prestación como que puedas tener acceso a algún curso online o que se organizan dentro de la misma empresa como grupo de estudios.

¿Qué consejo les darías a Engineers juniors?

Que te guste lo que haces porque si te gusta lo que haces, tú vas a estar aprendiendo, vas a estar informándote y vas a estar mejorando hasta como por hobbie y eso te hace mejor, que trates de ser el mejor para que siempre estés tratando de mejorar tus habilidades, tus conocimientos, buscando cosas nuevas que lo nuevo que salió y que no te cueste.

Creo que también junto a esa como habilidad o estas ganas de aprender también las habilidades de comunicación porque son bastante importantes aquí.

¿Cómo diferenciar a un Site Reliability Engineer Junior, mid o senior?

Más que nada la velocidad en la que puede resolver un problema, pero esto lleva muchas cosas. O sea, no es como que puedas escribir más rápido, desarrollar una app más rápido, sino que como comenté antes, igual y una persona que es junior, igual y su manager le va a decir “oye, es que este problema, o sea si se resuelve, entonces implementa eso”.

Pero conforme vas avanzando, agarrando más experiencia, igual puedas ver ¿Está correcto esto o por qué? ¿Cuál es el problema que tiene? Entonces, creo que ya conforme vas avanzando y vas ganando las habilidades y la confianza también de hablar, incluso antes de que se dé cuenta que hay un problema, puedas detectarlo y arreglarlo antes de que suceda.

Obviamente está la experiencia también de que has vivido más cosas, de que has pasado por distintos problemas, resuelto diferentes situaciones que se te quedan y ya tienes un catálogo más grande de lecciones, va creciendo tu enciclopedia mental. Es meterte un poco de ese lado del negocio o el cliente y entender, y tratar de leerle la mente, de averiguar sus circunstancias por la que están pidiendo algo.

¿Cómo cambian los proyectos, dependiendo del tamaño de la empresa o el país de la compañía para un Site Reliability Engineer?

Sí hay relación, pero hay muchas variables en juego. Por ejemplo, en una empresa más pequeña, creo que siempre es más importante la velocidad, sacar un feature rápido, eso pasa mucho en startups, no le dan tanto énfasis de que haya pruebas y que esté documentado.

Una empresa pequeña tiene necesidades de negocio distintas. Eso me pasó cuando estaba en la primera empresa aquí en México. Entonces cuando me moví a una empresa bastante más grande, igual existía esa necesidad de crear nuevo producto, hacer un cambio en la página principal o en el buscador o cosas así.

Pero las cosas que me tomaban o que le tomaban a los desarrolladores un día acá, eran de dos semanas por más simple que fuera el cambio, cualquier cosa que pueda afectar, puede afectar bastante en los ingresos.

¿En qué proyectos trabajas actualmente como Site Reliability Engineer?

Justo uno de los retos que estoy haciendo es tener mejor visibilidad, tener como todo centralizado hablando de aprobaciones de cambios de seguridad o de todo dentro de un lugar de distintas plataformas; todo en un solo punto.

Es una plataforma para poder tener centralizadas las cosas y agilizar todo. Tiene un poco más como de The box aplicado a procesos, no tanto de desarrollo, sino a procesos en aprobaciones y cosas así.

¿Cómo es el día a día de un Site Reliability Engineer?

Un día a día de mi trabajo es estar trabajando en un proyecto, pero también una de mis responsabilidades es que si existe un problema o un servicio falló, yo tengo que ver. No es 100% mi responsabilidad, porque el dueño del servicio o del sistema que falló, tendría que ver qué está pasando.

Muchas veces como está conectado la infraestructura con estos servicios, que son cosas que nada más nosotros conocemos, pues sí nos piden ayuda. Muchas veces es de que estoy trabajando y falla algo o algún desarrollador tiene algún problema con algún sistema y pues “oye, es que está pasando esto” y nosotros tenemos cientos de servicios y es imposible conocerlos todos.

Entonces, me tengo que echar un clavado en cinco minutos a ver qué hace, cómo funciona y ya con base a eso, poder ayudarlos a resolver el problema.  Sí es bastante cansado porque, o sea, de no saber nada, te topas con esto y tú tienes que estar indagando y preguntando, viendo qué y cómo. Es aprender algo bastante complejo, muy rápido y con la presión encima de que se está perdiendo dinero, no se estaban viendo cosas, etc.

¿De todas las experiencias que has tenido, en cuál llegó un punto en el que no sabías ni qué y cómo lo resolviste?

Pues algo que se quedó grabado es de que nosotros usábamos un servicio para capturar métricas de los servicios y el servicio tenía un problema, fallaba en nuestra infraestructura. Y estuvimos bastante rato tratando de ver si era un problema nuestro, de arreglarlo.

Contactamos al proveedor, tuvimos una charla con el CTO, estuvimos en juntas con los desarrolladores de la aplicación que estábamos usando como tal y pues sí, era como de “oye, ¿Y ya intentaron hacer esto?” y nosotros por nuestra cuenta googleando el programa ajeno y ya encontramos qué era. Y al final, hasta nos mandaron playeras y un montón de souvenirs.

¿Qué consejo les darías a los Site Reliability Engineer que van empezando?

Ser autodidacta es una cosa que te cambia la vida totalmente, que no dependas de alguien que te enseñe o que te diga que tienes que aprender esto, sino tú solo ves que hay algo te pueda servir y aprender. Y vas mejorando tu habilidad de aprender también a lo largo del tiempo.

Nunca dejen de practicar eso, de aprender, de estar leyendo, de estar siempre manteniéndose informados. Y también lo que les había comentado de sus habilidades de comunicación.

¿Qué recurso recomendarías para un Site Reliability Engineer?

Hay un libro que me gusta y que me sirvió bastante, no es técnico, pero sí está enfocado como a la cultura de DevOps que se llama Phoenix Project. Y ese libro es como una novela, o sea está en un formato novela de una persona que creo que empieza, apenas lo contratan. Es como su travesía de cómo convertir una empresa en un dinosaurio gigante.

Para un lado más técnico, un libro que sacó Google que se llama SRE Handbook, que es básicamente todo lo que tienes que saber para ser un SRE.

¿Quieres dar el siguiente paso en tu carrera profesional?

Entra a hireline.io