Las preguntas más frecuentes sobre SRE (Parte II)

26 agosto
Por: Gregory Burmistrov, System Analyst and Site Reliability Engineer from DataArt
Las preguntas más frecuentes sobre SRE (Parte II)
La Ingeniería de Confiabilidad de Sitios (SRE, por sus siglas en inglés) está en auge, pero continúa siendo para muchos un misterio. Es por eso que, en este último tiempo, recopilé algunas de las preguntas más frecuentes y traté de responderlas con la mayor claridad posible. En este artículo, podrán encontrar la segunda parte de la información.

6. ¿La SRE se opone al desarrollo de features?

Si bien la SRE puede limitar un desarrollo excesivamente rápido debido a que actúa como un estabilizador, pensar que son opuestos es un gran error. La SRE no coarta a los desarrolladores; más bien, equilibra la parte comercial que constantemente requiere la expansión de features de cualquier aplicación (no perdamos de vista que, especialmente aquellos que son diseñados a toda prisa, siempre desestabilizan el sistema). Si la producción corre el riesgo de caer, la SRE puede apelar al indicador de presupuesto de error, haciendo sonar la alarma e indicando la necesidad de estabilización. Todos entienden intuitivamente que, si el sistema está estable, se puede desestabilizar ligeramente con el objetivo de agregar nuevas funciones, caso contrario, no se podrían tomar riesgos y se necesitaría eliminar las amenazas, posponiendo el desarrollo. El concepto de SRE permite hablar sobre él en términos comprensibles, con la participación de información específica expresada cuantitativamente. El ingeniero en SR tiene responsabilidad por este equilibrio, así como también la autoridad apropiada para flexibilizarlo cuando es necesario.

7. ¿El trabajo de SRE es rutinario?

De ninguna manera. En general, no estamos hablando de un conjunto infinito de operaciones repetitivas, sino que el trabajo de SRE se puede dividir en dos partes: seguramente un día, un servidor se caerá y tendrá que lidiar con él; y lo más probable es que caiga por la noche. Apagar el fuego es bastante divertido: se corre con un extinguidor de incendios actuando hábil y valientemente, y se conquista el fuego con placer ya que, después de esto, es posible irse a dormir con un sentido de logro. Pero para un SRE, ese trabajo es solo el comienzo: necesita luego comprender qué causó el incidente, evaluarlo y decidir cómo evitar que esto suceda en el futuro. Otra cosa es que tal investigación puede en sí misma resultar atractiva, y su conclusión exitosa es una razón suficiente para estar satisfecho.

8. ¿Un SRE trabaja junto a los desarrolladores o se trata de un equipo separado?

Se pueden utilizar ambos enfoques. En el primer caso, el ingeniero de SR se introduce en el equipo junto con el desarrollador y el ingeniero de control de calidad; en el segundo, se forma todo un equipo de SRE para trabajar en proyectos que han pasado la etapa de desarrollo activo, donde el sistema es bastante estable. Tal sistema puede ser operado activamente por el cliente, por lo tanto, mejorar el proceso y la interacción, y proporcionar recuperación automática puede ser especialmente importante.

El equipo lo complementa con métricas, entiende el dispositivo, busca áreas problemáticas. En algunos casos, el ingeniero en SR puede solicitar una revisión al equipo de desarrolladores o hacer cambios independientes en el código, si están limitados en tamaño y se ajustan al presupuesto de error.

9. ¿Qué se puede aprender trabajando como SRE?

Principalmente, se puede conocer la complejidad del sistema, algo que en el futuro puede ayudarlo a ir a producción. Actualmente, casi nadie puede permitirse simplemente escribir código sin pensar en su futuro; todos los participantes de cualquier proyecto importante deben monitorear la carga y la seguridad. Trabajar con los sistemas existentes como ingeniero en SR hace posible cortar el camino y sumergirse inmediatamente en este proceso. Esto permite a los desarrolladores ir más allá, tienen la oportunidad de ver y tocar todas las formas modernas de trabajar en la producción: monitoreo y alerta. Además, las herramientas destinadas a esto, por regla general, son programas de código abierto. Es decir, la experiencia adquirida se puede transferir fácilmente a otros proyectos y empresas.

Para los ingenieros de DevOps, la SRE es una gran oportunidad para comprender mejor cómo se escriben los sistemas. Tal trabajo le permite sumergirse en código a un nivel que en 2-3 años, si lo desea, le permitirá desarrollarse más como programador.

10. ¿El concepto de SRE va a durar mucho tiempo? ¿Será una experiencia en demanda?

La SRE llegó para quedarse, y adquirir experiencia en este campo, en el futuro, puede ser indispensable. Podrá convertirse en una fuente de ingresos estable para cualquier empresa dirigida a proyectos empresariales grandes y complejos. Los sistemas continúan complicándose, los gastos generales aumentan y es casi imposible recordar todos los detalles del despliegue de 200 micro servicios en la cabeza. Por lo tanto, el papel de un ingeniero en SR en los próximos años puede llegar a ser tan común como la automatización de control de calidad hace 10 años, y DevOps hace cinco años. Para administrar proyectos con cientos de desarrolladores, definitivamente se necesitarán personas capaces de soportar el caos que se aproxima. De lo contrario, las aplicaciones comenzarán a colapsar bajo su propio peso.

Aún más, la experiencia en SRE será útil incluso para aquellos que, después de algún tiempo, deseen regresar (o saltar por primera vez) estrictamente al desarrollo. La capacidad de ver el futuro de su código en producción puede ser obligatoria en los próximos años. Y nadie quiere ser maldecido por colegas y usuarios, para quienes el funcionamiento ininterrumpido del sistema es crítico.