Llegamos a ustedes gracias a:



Columnas de opinión

Lo que los SREs quieren que los desarrolladores de aplicaciones sepan

Por: Isaac Sacolick, presidente de StarCIO

[15/10/2020] Es importante que todas las personas que trabajan en el sector de la tecnología de la información acepten comentarios críticos y consejos para mejorar los procesos, la calidad y la colaboración. En el caso de los equipos de desarrollo agile, esa retroalimentación suele venir de los propietarios de los productos, los gerentes de relaciones comerciales, las partes interesadas, los clientes y los usuarios finales de las aplicaciones en desarrollo y que reciben apoyo. Si una aplicación es difícil de usar, funciona lentamente o no satisface las necesidades del flujo de trabajo, los equipos agiles deben recibir esta retroalimentación crítica y ajustar las prioridades de los pendientes.

Igual de importante es recibir retroalimentación de los equipos operacionales que apoyan las aplicaciones en los ambientes de desarrollo, prueba y producción. Los SREs (ingenieros de confiabilidad del sitio, por sus siglas en inglé) son los responsables de la fiabilidad y el rendimiento de las aplicaciones de producción, y son una fuente importante de las buenas prácticas y la retroalimentación a los equipos de desarrollo.

Con el objetivo de ponerse en los zapatos de sus colegas, los desarrolladores deberían considerar las responsabilidades, herramientas y actividades de los SREs. A continuación, se presentan algunos de sus consejos sobre cómo los desarrolladores pueden mejorar las aplicaciones, los procesos de desarrollo y las herramientas que influyen en el rendimiento.

Trabaje con los SREs como un solo equipo de desarrollo

Los líderes de las organizaciones de tecnología asignan a los SREs para que trabajen con uno o unos cuantos equipos de desarrollo agile. En muchos casos, el número de desarrolladores y equipos de desarrollo es significativamente mayor que el número de SREs. Es común que estos dividan su tiempo entre varios dominios y equipos, y deben aprender los detalles técnicos y de negocios de muchas aplicaciones.

Independientemente de la organización y la estructura del equipo, los desarrolladores deben considerar a los SREs como parte del equipo con objetivos alineados. Hablé con Jason Walker, field CTO de BigPanda, acerca de la alineación requerida, ya que los SREs pasan la mayor parte de su tiempo atendiendo incidentes de producción e investigando problemas de rendimiento, mientras que los desarrolladores probablemente estén trabajando en la siguiente característica. "No es suficiente formar un equipo de SRE y asumir que perseguirán todos los problemas solos. Los desarrolladores tienen que modificar y modernizar sus procesos, herramientas y mentalidad al mismo tiempo", sugiere Walker.

En la práctica, esto significa que los desarrolladores deben abordar las cuestiones no funcionales y recibir retroalimentación de los SREs sobre qué tipos de problemas abordar. Recomiendo a los equipos de desarrollo que dediquen el 30% de la velocidad del nuevo lanzamiento a la deuda técnica, los problemas de rendimiento, las lagunas de seguridad y las mejoras de la fiabilidad.

Lo más importante es que los desarrolladores, los ingenieros de pruebas y los SREs trabajen como un equipo de desarrollo responsable equilibrando las presiones para lanzar más características más rápidamente, con el trabajo necesario para garantizar la fiabilidad, el rendimiento y la seguridad.

Comprender la infraestructura, el entorno y los componentes

Si los desarrolladores y los SREs fueran socios, cada uno de ellos tendría que entender mejor los roles del otro. Para los desarrolladores, esto significa comprender la infraestructura, los entornos, los servicios en la nube y los componentes de las aplicaciones de los que su aplicación o servicio depende o en los que se está ejecutando.

Conversé con Will Cappelli, CTO de Europa, Oriente Medio y África, y vicepresidente de estrategia de producto de Moogsoft sobre este desafío. "El desarrollo necesita volverse más 'consciente'. No se trata de un retorno a los procesos de desarrollo rígidos y de arriba hacia abajo. Significa que el desarrollo debe anticiparse, observar y responder continuamente al comportamiento de los componentes que libera en el entorno de producción. Esto significa la aplicación agresiva de la IA a las métricas, registros y rastros que están siendo generados por esos componentes".

Cappelli está sugiriendo que, aunque muchos equipos de desarrollo están desarrollando microservicios, automatizando sus pruebas, desplegando con CI/CD (integración continua/despliegue continuo), y configurando el entorno de ejecución con infraestructura como código, los desarrolladores todavía deben entender el entorno y anticipar los diferentes tipos de problemas.

Asegúrese de que el código, los mensajes de registro y las excepciones sean comprensibles

Los desarrolladores también deberían tomar medidas para ayudar a los SREs a aprender las aplicaciones, los servicios y los entornos de desarrollo. Cuando se produce un incidente importante en el entorno de producción, los SREs deben revisar todas las alertas de supervisión, los mensajes de registro y las excepciones que preceden al incidente y durante el mismo. Su objetivo es restaurar el servicio rápidamente para minimizar el impacto en la empresa y los usuarios finales, y también realizar un análisis de las causas de fondo.

Cuando los desarrolladores no proporcionan mensajes de registro, excepciones o comentarios de código fáciles de entender, la tarea se hace más difícil.

Walker de BigPanda está de acuerdo y sugiere que los desarrolladores deben abordar la pregunta: "¿Qué debería requerir la supervisión de esta aplicación cuando tengo que entregarla a otra persona? De lo contrario, podrían simplemente reenviar los registros de errores a su SRE, pero ¿qué significa esto?"

Etiquete las historias que impactan en la fiabilidad, el rendimiento y la seguridad

Demos un paso más y consideremos también la mejor manera de involucrar a los SREs durante el proceso de desarrollo. Si la proporción entre desarrolladores y SREs es alta, el número de historias de usuarios agile planeadas o activas en el sprint será aún mayor. No es realista esperar que los SREs lean cada requisito y evalúen sus riesgos operacionales.

Los equipos de desarrollo y los arquitectos de aplicaciones pueden ayudar definiendo, etiquetando y aumentando sus estimaciones de historias de usuarios de mayor riesgo y defectos. He implementado procesos que incluyen los siguientes pasos:

  • Los arquitectos deben definir criterios que ayuden a los equipos de desarrollo a comprender qué tipos de implementaciones deben marcar por consideraciones de fiabilidad, rendimiento y seguridad.
  • Los propietarios de los productos y los líderes técnicos agile deberían etiquetar las historias que cumplan estos criterios de riesgo. El etiquetado de las historias y tarjetas puede hacerse fácilmente en herramientas agile como Jira Software y Azure DevOps. Esto hace que sea más simple para los SREs, arquitectos e infosec identificar cuáles revisar.
  • Los equipos de desarrollo deben ajustar sus estimaciones agile para reflejar los criterios de aceptación no funcionales basados en los riesgos identificados.
  • Los desarrolladores deben implementar suficiente manejo de excepciones, pruebas y monitoreo apropiado para la implementación y el tipo de riesgo.
  • Los Scrum Masters deben pedirles a los SREs, arquitectos o infosec que participen en las revisiones rápidas relevantes para que puedan evaluar las correcciones de riesgo implementadas.

Estos pasos reflejan un equilibrio entre el logro de los objetivos empresariales, la garantía de la fiabilidad de las aplicaciones y el reconocimiento de las limitaciones de personal de muchas organizaciones de TI.

Shift-left testing e invertir en la supervisión de las aplicaciones

Reconocer los riesgos del desarrollo e implementar reparaciones a nivel de la historia es una táctica para reducir el riesgo operacional. Esto debería formar parte de una filosofía general de shift-left testing en el que la mayoría de las pruebas estén automatizadas y los equipos agile, incluyendo los desarrolladores e ingenieros de automatización de pruebas, implementen un nivel apropiado de pruebas continuas en el canal de CI/CD.

Este nivel de pruebas es complicado por la pandemia y el cambio al trabajo remoto. En un estudio reciente de Kobiton sobre el impacto de COVID-19 en el control de calidad móvil, el 55% de los encuestados sugiere invertir en la cultura del trabajo a distancia y el 50% recomienda que las organizaciones de TI evalúen herramientas que habiliten/activen a los equipos de pruebas remotas. El trabajo a distancia también afecta al desarrollo agile, y los equipos distribuidos que adoptan culturas y prácticas de desarrollo también deben adaptar las prácticas de colaboración.

Mientras que el shift-left testing y la implementación de prácticas de seguridad durante el desarrollo agile son buenas prácticas, la implementación de monitores de aplicaciones y el despliegue de soluciones de AIops como BigPanda o Moogsoft también requieren el apoyo del equipo de desarrollo. Estos sistemas tienden un puente entre el mundo de los conocimientos que los equipos de desarrollo pueden probar y el mundo de las incógnitas que afectan a los entornos de producción.

Los equipos de desarrollo deben tener en cuenta la retroalimentación de los SREs y otras personas que trabajan en operaciones de TI. El hecho de que haya menos problemas operativos significa que todo el mundo puede centrarse más en ofrecer capacidades, satisfacer a los usuarios finales e investigar nuevas tecnologías.

Isaac Sacolick es el autor de Driving Digital: The Leader's Guide to Business Transformation through Technology, que cubre muchas prácticas como la metodología ágil, devops y ciencia de datos que son fundamentales para los programas exitosos de transformación digital. Sacolick es un reconocido CIO social, bloguero desde hace mucho tiempo en Social, Agile and Transformation y CIO.com, también es presidente de StarCIO.