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

2 julio
Gregory Burmistrov, System Analyst and Site Reliability Engineer from DataArt
Las preguntas más frecuentes sobre SRE (Parte I)

 

Site Reliability Engineering (SRE) -que en español sería la Ingeniería de Confiabilidad de Sitios- es un tema en auge, aunque aún continúa siendo un misterio para muchos que confunden al Ingeniero de SR con el SysAdmin o DevOps. Es por eso que, en este último tiempo, recopilé las preguntas más frecuentes y traté de responderlas con la mayor claridad posible; espero les resulte útil la información.

1. SRE: ¿es del libro que Google publicó?

En general, sí. El concepto de Ingeniería de Confiabilidad de Sitios nació en Google, en 2003, y desde entonces muchas organizaciones han formado sus propios equipos. Se destacan, por supuesto, aquellas cuyo éxito empresarial está directamente relacionado con el buen funcionamiento de los sistemas informáticos (Apple, Microsoft, Facebook, Twitter, Dropbox, Oracle, etc.). Hace 4 o 5 años, la SRE comenzó a popularizarse y en los últimos 2 o 3 años, la lista de quienes se destacaron en los proyectos se ha ampliado considerablemente. Al fin y al cabo, ¿quién no depende hoy en día de los sistemas de TI internos, su confiabilidad, rendimiento e integración con servicios externos? Las tareas de los Ingenieros de Confiabilidad de Sitios en diferentes compañías pueden variar y dependen en gran medida del tipo de negocio. En este sentido, SRE, como un enfoque relativamente nuevo, se parece a Agile que -como probablemente habrán notado- es diferente para todos. Sin embargo, la lista de conocimientos y habilidades que un especialista debería tener será, en cualquier caso, un 80% igual.

2. ¿Es solo un nombre de moda para soporte técnico?

¡De ninguna manera! El concepto asume que los desarrolladores no solo escriben código, sino que también monitorean cómo funciona en producción. Así, se borra el límite entre el desarrollo y la explotación. Una de las tareas de un equipo de SRE es evitar que un lanzamiento se convierta en una partida de pingpong entre los desarrolladores y los DevOps, donde todos afirman que el problema proviene del otro lado. Un Ingeniero de Confiabilidad de Sitios analiza constantemente la posibilidad de automatización y tiene amplios poderes. Cualquier problema para ellos es, ante todo, una razón para el análisis. Si se repite o está lleno de riesgos altos, la SRE puede decidir arreglar algo en la propia aplicación o escribir (por su cuenta o con la ayuda de colegas) una herramienta que elimine los problemas sin la intervención humana. Gracias a la Ingeniería de Confiabilidad de Sitios, entendemos si hay bugs en la aplicación, cómo solucionarlos y cómo mejorar continuamente la confiabilidad de este sistema en el futuro.

Si bien la resolución de problemas es también su responsabilidad, la tarea clave que persigue es cuantificar el desempeño del sistema y el trabajo sistemático para mejorar su confiabilidad. Podría convertirse en Soporte solo si el proceso está mal organizado: cuando el número de incidentes crece como una avalancha y el ingeniero simplemente no tiene tiempo para hacer su trabajo principal, porque está resolviendo las tareas urgentes diarias. En nuestros proyectos lo prohibimos deliberadamente, ya que asumimos que en el desarrollo del concepto de SRE hay perspectivas serias para nuestro propio negocio. Por eso, reducimos su suporte a un nivel controlado y aceptable.

Finalmente, una diferencia muy importante entre SRE y Soporte, es el número de comunicaciones. Para el Ingeniero en Confiabilidad de Sitios, la escasa medida en que muchos analistas de sistemas (especialmente en pequeñas empresas) tienen que comunicarse, es una sorpresa. En nuestros proyectos, impulsamos un contacto constante con representantes comerciales y grupos independientes de desarrolladores.

3. ¿Desarrollador o DevOps?

SRE es un intento por consolidar ambos. Los ingenieros que trabajan aquí entienden bien el sistema, saben cómo profundizar "debajo del capó" y están listos para reescribir el código incorrecto. Pero en esta función, también hay una sugerencia de DevOps: un Ingeniero en Confiabilidad de Sitios necesita comprender cómo funcionan los servidores, en qué se implementa el sistema, cómo se escala el sistema, cómo se distribuye la carga, etc. Estos especialistas se requieren principalmente para trabajar en grandes proyectos empresariales con aplicaciones complejas y de alta carga. Son ellos quienes saben cómo se comporta el sistema en condiciones reales, especialmente si algo sale mal, es decir, falla la conexión de la red o la base de datos. Este conocimiento es necesario no solo para estabilizar rápidamente la aplicación, sino también para realizar los cambios necesarios en el código fuente.

4. ¿Qué es la confiabilidad? ¿Existen criterios claros para medirla?

Lo primero que hace un SRE es rodear cualquier sistema con métricas que pueden variar de un proyecto a otro, siempre cuidándose de no medir lo que no estamos interesados ​​en medir. Por ejemplo, la cantidad de espacio de disco en el servidor y la carga del procesador solo afectan el trabajo, pero no responden ninguna de las preguntas importantes para nosotros, ya que los ingenieros de SR no están interesados ​​en los indicadores técnicos, sino en los Indicadores de Nivel de Servicio (SLI, por sus siglas en inglés), es decir, métricas de negocios. El sistema sirve mejor a los clientes, no cuando el procesador está menos cargado, sino cuando puede manejar constantemente más solicitudes sin sacrificar la calidad.

Solo aprendiendo a medir indicadores críticos para el negocio podemos comenzar el proceso de aumentar la confiabilidad. Está claro que, al mismo tiempo, el costo de desarrollo, soporte y mantenimiento del sistema está creciendo. Además, crecen de manera exponencial, especialmente si estamos hablando de un sistema que opera en diferentes regiones, donde surge la cuestión de una línea universal (la mayoría de las veces, la SRE trata con historias complejas de este tipo). Y es allí donde la SRE se convierte en una figura clave en las negociaciones con la empresa ya que pueden, con referencia a los indicadores cuantitativos, explicar qué tan confiable es el sistema, qué cuellos de botella existen y cuánto costará eliminarlos. Es junto con los representantes comerciales que los ingenieros de SR establecen los Objetivos de Nivel de Servicio (SLO, otra abreviatura importante), es decir, los indicadores de confiabilidad aceptables.

5. ¿Qué formación y experiencia requiere tener un especialista en SRE?

El concepto aún es nuevo y prácticamente no hay especialistas preparados en el mercado. Por lo tanto, para estos roles se considera tanto a los desarrolladores (es bueno cuando un SRE no le teme a Python o Java) como a los ingenieros de DevOps que están listos para profundizar en el código. Afortunadamente, la gama de tareas es muy amplia, desde la supervisión y la alerta (tareas típicas de DevOps) hasta la compleja solución de problemas que solo pueden realizar los desarrolladores con experiencia.

Algunas tareas clásicas: el servidor registra constantemente quedarse sin memoria; o el grupo de threads finaliza, es decir, algunos no se devuelven; o uno de los tres servidores detrás del equilibrador de carga está sobrecargado constantemente, aunque los otros dos funcionan normalmente. Estos son problemas técnicos no triviales cuya solución requiere una comprensión profunda de lo que está "debajo del capó", es decir, cómo se escalan los sistemas en las nubes, cómo se distribuye la carga y cómo el servidor la maneja. Lo más probable es que un desarrollador de alto nivel los investigue. Hay tareas de configuración, así como locales y no tan complejas.

SRE es un área que limita con desarrollo y DevOps, y es casi imposible encontrar una persona con amplia experiencia en ambas áreas. Por lo tanto, no se espera que tengan conocimiento de todos los procesos y herramientas. SRE le permite aprender trabajando en tareas específicas con ingenieros experimentados. Por lo tanto, hay perspectivas aquí no solo para los seniors, sino también para los desarrolladores junior o DevOps, que tienen la oportunidad ahora de sumergirse en el tema antes de que se convierta en una práctica general.