GSAS (Global Software Architecture Summit) 2022 es uno de esos eventos que no pueden perderse los que trabajan con arquitectura de Software.
Ya tenemos el resumen de cómo fue la segunda edición, pero antes de que lo veáis, os dejo con muchas de las preguntas que se trataron en el evento.
La evaluación de entrega de software de varios equipos es un enfoque simple y fácil de ejecutar para evaluar la entrega de software en muchos equipos diferentes dentro de una organización.
La evaluación cubre diez dimensiones en total:
Un equipo sano
Basado en los criterios de Spotify Squad Health Check con algunas adiciones:
– Fácil de publicar: ¿Qué tan fácil es publicar un cambio en el software en el que trabaja?
– Proceso adecuado: ¿Qué tan adecuado es el proceso para desarrollar y entregar software?
– Calidad de la tecnología: ¿Qué tan saludable es la base del código?
– Valor: ¿trabajas en cosas valiosas como equipo?
– Velocidad: ¿Qué tan rápido trabajas en equipo?
– Misión: ¿sabes por qué estás trabajando en las cosas?
– Diversión: ¿Qué tan divertido es trabajar en tu equipo? ¿Cuánto compañerismo y sentido de trabajo en equipo?
– Aprendizaje: ¿Cuánto se aprende en equipo?
– Apoyo: ¿Cuánto apoyo reciben como equipo?
– Peones o jugadores: ¿Cuánto control tienes sobre lo que trabajas y cómo?
– Seguridad psicológica: ¿Qué tan seguro se siente para plantear inquietudes?
– Equipos que nos rodean: ¿Qué tan bien trabajan los equipos que te rodean contigo y con tu equipo?
– Plataforma de entrega: ¿Qué tan efectiva y fácil de usar es la plataforma de entrega que sustenta la entrega de su equipo?
– Estilo de gestión: ¿Qué tan efectivos y apropiados son los enfoques de la gerencia y otras partes interesadas de alto nivel?
Implementación
Basado en preguntas clave del libro DevOps for the Modern Enterprise de Mirco Hering:
– Reconstrucción del entorno: qué sucedería si decidieras eliminar el entorno y reconstruirlo a partir de una configuración almacenada.
– Configuración nueva: qué sucedería si decidieras eliminar la configuración de la aplicación y volver a implementarla.
– Volver a implementar la aplicación: qué sucedería si decidieras volver a implementar la aplicación aunque nada haya cambiado.
– Volver a ejecutar las pruebas: qué sucedería si decidieras volver a ejecutar el conjunto de pruebas y luego otra vez.
Flujo
Basado en los criterios del libro Accelerate de Nicole Forsgren, Jez Humble y Gene Kim, además de algunos detalles de The Principles of Product Development Flow de Don Reinertsen:
– Tiempo de ciclo: ¿Cuánto tarda un cambio de código en pasar del control de versiones a la ejecución en producción? (Mínimo, Típico)
– Frecuencia de implementación: ¿con qué frecuencia se implementa su equipo en producción?
– MTTR: ¿Cuánto tiempo lleva restaurar su aplicación o servicio después de un incidente?
– Cambios fallidos: ¿Qué proporción de cambios en su aplicación o servicio en producción fallan o necesitan corrección? (Este suele ser el número de implementaciones fallidas)
– Trabajo en progreso: ¿En cuántas cosas trabaja su equipo al mismo tiempo? (Mínimo, Típico)
– Innovación: ¿Qué tan bien puede innovar en torno a los enfoques de entrega?
– Incorporación: ¿Qué tan efectivo es el proceso de incorporación para nuevos equipos y personal nuevo?
– Edad de la rama: ¿Cuánto tiempo viven sus ramas?
– Retrospectivas: ¿Qué tan efectivas son las retrospectivas de su equipo?
Entrega continua
Basado en criterios seleccionados del libro Entrega continua de Jez Humble y Dave Farley:
– Release Candidate: ¿cada registro conduce a un posible lanzamiento?
– Listo – ¿Listo significa liberado?
– Configuración automatizada: ¿la configuración se realiza mediante procesos automatizados utilizando valores tomados de su depósito de configuración?
– Opciones de configuración: ¿es fácil para cualquiera ver qué opciones de configuración están disponibles para una versión particular de una aplicación en todos los entornos en los que se implementará?
– Construcciones rotas: ¿revisas una construcción rota?
– Pruebas fallidas: ¿hace comentarios sobre las pruebas fallidas?
– Binarios: ¿construir sus binarios una vez?
– Stop The Line: si alguna parte de la tubería falla, ¿detiene la línea?
– Implementación idempotente: ¿el proceso de implementación es idempotente?
– Stubs: ¿usáis stubs para simular sistemas externos?
– Reproducción de API: ¿graba las interacciones con un servicio o una API pública?
– Azul-Verde: ¿tiene un mecanismo que le permita probar una nueva versión junto con una versión existente y retroceder a la versión anterior si es necesario?
– Historial del entorno: ¿es posible ver un historial de los cambios realizados en cada entorno, incluidas las implementaciones?
– Cambios en la base de datos: ¿desacoplar la implementación de la aplicación de la migración de la base de datos?
Operabilidad
Basada en criterios seleccionados del libro Team Guide to Software Operability de Matthew Skelton, Alex Moore y Rob Thatcher.
– Colaboración: ¿Con qué frecuencia y de qué manera colabora con otros equipos en los aspectos operativos del sistema, como las características operativas?
– Gasto en operatividad: ¿Qué proporción del presupuesto del producto y del esfuerzo del equipo se dedica a abordar los aspectos operativos? ¿Cómo rastreas esto?
– Conmutadores de funciones: ¿Cómo sabe qué conmutadores de funciones están activos para este subsistema?
– Implementación de configuración: ¿Cómo implementa un cambio de configuración sin volver a implementar el software?
– Estado del sistema: ¿Cómo sabe que el sistema está en buen estado?
– KPI de servicio: ¿Cómo realiza un seguimiento de los principales indicadores clave de rendimiento (KPI) del servicio/sistema? ¿Qué son los KPI?
– Registro funcionando: ¿Cómo sabe que el registro funciona correctamente?
– Capacidad de prueba: ¿Cómo demuestra que el sistema de software es fácil de probar? ¿Qué proporcionas y a quién?
– Certificados TLS: ¿Cómo sabe cuándo un certificado SSL/TLS está a punto de caducar?
– Datos confidenciales: ¿Cómo se asegura de que los datos confidenciales en los registros estén enmascarados u ocultos?
– Rendimiento: ¿Cómo sabe que el sistema/servicio funciona dentro de los rangos aceptables?
– Modos de falla: ¿Cómo puede ver y compartir los diferentes modos de falla conocidos del sistema?
– Seguimiento de llamadas: ¿Cómo rastrea una llamada/solicitud de extremo a extremo a través del sistema?
– Estado del servicio: ¿Cómo se muestra el estado actual del sistema/servicio a los equipos de operaciones?
Etapa de Tests
Basado en criterios seleccionados de los libros Agile Testing de Lisa Crispin y Janet Gregory, Continuous Delivery de Jez Humble y Dave Farley, Growing Object-Oriented Software de Steve Freeman y Nat Price, Working Effectively with Legacy Code de Michael Feathers, Guía del equipo para la capacidad de prueba del software por Ash Winter y Rob Meaney:
– Prueba primero (clases): ¿qué proporción del tiempo escribe la prueba primero para métodos y clases?
– Prueba primero (características): ¿qué proporción del tiempo escribe la prueba primero para las características y el comportamiento?
– % de prueba unitaria: ¿en qué nivel de cobertura de código considera que sus pruebas unitarias han tenido éxito?
– % de pruebas de funciones: ¿en qué nivel de cobertura de funciones considera que sus pruebas de funciones (o pruebas de comportamiento) han tenido éxito?
– Cobertura de funciones: ¿qué proporción de las funciones de su código cubre una prueba de funciones (o prueba de comportamiento)?
– Datos de prueba: ¿qué proporción de sus datos de prueba se genera a partir de scripts y se inyecta automáticamente en los almacenes de datos?
– Implementación: ¿qué proporción de su código de canalización de implementación tiene pruebas que cubren el comportamiento de la compilación y la implementación?
– Capacidad de prueba: ¿qué proporción de su tiempo dedica a hacer que el software sea comprobable?
– CDC/Pact/SemVer: ¿cuánto utiliza los enfoques de prueba entre equipos, como los contratos impulsados por el consumidor (CDC)/Pact/Semantic Versioning?
– Otro código: ¿qué confianza tiene en el código de otros equipos de la organización con los que trabaja o consume (pero no escribe)?
Confiabilidad y SRE
Basado en criterios seleccionados de los libros Site Reliability Engineering de Betsy Beyer, Chris Jones, Jennifer Petoff y Niall Murphy, The Site Reliability Workbook editado por Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara y Stephen Thorne, Seeking SRE editado por David N. Blank-Edelman, Team Guide to Software Operability de Matthew Skelton, Alex Moore y Rob Thatcher:
– Disponibilidad del servicio: ¿qué tan disponible (en «nueves») debe estar su servicio o aplicación y cómo lo sabe o decide?
– Objetivos del usuario y SLI: ¿qué debe hacer su servicio/aplicación desde el punto de vista del usuario?
– Comprensión de los usuarios y el comportamiento: ¿quiénes son los usuarios del software y cómo interactúan con el software? ¿Cómo lo sabes?
– SLI/SLO: ¿cómo sabe cuándo los usuarios han experimentado una interrupción o un comportamiento inesperado en el software?
– Estado del servicio: ¿cuál es el indicador o la métrica más importante que utiliza para determinar el estado y la disponibilidad de su software en producción/en vivo?
– SLI: ¿qué combinación de tres o cuatro indicadores o métricas utiliza (o podría/utilizaría) para proporcionar una imagen completa del estado y la disponibilidad de su software en producción/en vivo?
– Presupuesto de errores y mecanismos similares: ¿cómo sabe el equipo cuándo dedicar tiempo a los aspectos operativos del software (registro, métricas, rendimiento, confiabilidad, seguridad, etc.)? ¿Ese tiempo realmente se gasta?
– Alertas: ¿qué proporción de su tiempo y esfuerzo dedica como equipo a hacer que las alertas y los mensajes operativos sean más confiables y relevantes?
– Trabajo duro y solución de problemas: ¿qué proporción (aproximadamente) de su tiempo se dedica a incidentes de sistemas en vivo y qué tan predecible es el tiempo necesario para solucionar problemas?
– Tiempo de diagnóstico: ¿cuánto tiempo se tarda normalmente en diagnosticar problemas en el entorno de producción/en vivo?
Trabajando fuera de horarios
Basado en criterios seleccionados de los libros Site Reliability Engineering de Betsy Beyer, Chris Jones, Jennifer Petoff y Niall Murphy, The Site Reliability Workbook editado por Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara y Stephen Thorne, Guía de equipo para la operatividad del software de Matthew Skelton, Alex Moore y Rob Thatcher:
– Propósito de on-call: ¿cómo definiría «on-call»?
– Beneficios de on-call: ¿cuáles son algunas de las formas en que el software se beneficia al tener desarrolladores de on-call?
– Recompensa: ¿cómo se le recompensa por estar de guardia fuera del horario laboral?
– UX de guardia: ¿cuál es la experiencia del usuario (UX)/experiencia del desarrollador (DevEx) de estar de guardia en este momento?
– Aprendizaje de la guardia: ¿qué sucede con el conocimiento adquirido durante la guardia? ¿Cómo se mejora el software en función de las experiencias de guardia?
– Actitud hacia la guardia: ¿bajo qué circunstancias la guardia no sería una carga?
– Futuro de guardia: ¿qué se necesitaría para que este equipo/escuadrón esté feliz de estar de guardia?
– Herramientas para la guardia: ¿qué herramientas o procesos faltan, son ineficaces o insuficientes en este momento en relación con la guardia?
– Mejorar la guardia: ¿cuánto tiempo dedican como equipo a mejorar la experiencia de guardia? ¿Con qué frecuencia trabaja en las mejoras de guardia?
– Flexibilidad de guardia: ¿qué tan flexible es la rotación o el horario de guardia? ¿De qué manera el programa satisface las diferentes necesidades de los miembros del equipo?
– Accesibilidad de guardia: ¿qué tan accesible es la guardia? Específicamente, ¿qué proporción de los miembros de su equipo están de guardia con regularidad?
Seguridad
Basado en criterios seleccionados de los libros Agile Application Security de Laura Bell, Michael Brunton-Spall, Rich Smith, Jim Bird; Alice and Bob Learn Application Security de Tanya Janca; Seguro por diseño de Dan Bergh Johnsson, Daniel Deogun, Daniel Sawano; Entrega continua de Jez Humble y Dave Farley; y Modelado de amenazas: diseño para la seguridad de Adam Shostack:
– OWASP Top Ten: ¿verifica los riesgos de seguridad de OWASP Top Ten?
– Principios de diseño seguro: ¿cuál es el enfoque de la seguridad y el cumplimiento?
– Modelado de amenazas: ¿cómo aborda el modelado de amenazas?
– Seguridad basada en dominios: ¿de qué manera trabaja con expertos en dominios para ayudar a que el código sea seguro?
– Pruebas de entrada: ¿qué tipo de prueba de entrada realiza en la canalización de implementación?
– Privilegio mínimo: ¿qué enfoque adopta para acceder a los permisos de las cuentas utilizadas para ejecutar su software?
– Seguridad de la cadena de suministro: ¿cómo verifica la calidad y la seguridad de los componentes de software externos utilizados en su software?
– HTTPS en todas partes: ¿dónde se utiliza HTTPS (HTTP sobre TLS/SSL) en su software?
– Pruebas de seguridad automatizadas: ¿qué tipo de pruebas de seguridad automatizadas se realizan en su código y cuándo?
– Responsabilidad por la seguridad: ¿quién es responsable de la seguridad y la capacidad de protección de su software?
– Política como código: ¿las políticas de seguridad están definidas en el código (o configuración) y son comprobables?
Interacciones de equipo
Basadas en criterios seleccionados de los libros Team Topologies de Matthew Skelton y Manuel Pais y Dynamic Reteaming de Heidi Helfand:
– Tipo de equipo: ¿está claro el tipo de su equipo para usted y para otros equipos a su alrededor?
– Equipos de larga duración: ¿qué tan duradero (larga vida) es su equipo? ¿Cuándo se disolverá el equipo?
– Cambio de miembros del equipo: ¿cómo se agregan o eliminan miembros del equipo? ¿Qué informa el proceso?
– Team API: ¿cómo define el mandato y el enfoque del equipo?
– Interacciones del equipo: ¿cómo define, planifica y explora las interacciones entre su equipo y otros equipos?
– Dependencias entre equipos: ¿qué enfoque adopta para realizar un seguimiento de las dependencias entre equipos?
– Espacio de trabajo del equipo: ¿de qué manera contribuye su espacio de equipo físico y/o en línea a una sensación de cohesión y empoderamiento del equipo?
– Cohesión del equipo: ¿qué tan unido se siente tu equipo? ¿Cuánta confianza hay dentro del equipo?
– Carga cognitiva del equipo: ¿cómo afecta la carga cognitiva del equipo al trabajo del equipo?
El objetivo de las evaluaciones es promover y mantener un ambiente de trabajo positivo para construir y ejecutar sistemas de software donde:
– Los cambios en el software se crean, prueban e implementan en producción de forma rápida y segura mediante prácticas de entrega continua.
– Se optimizan procesos y prácticas para el flujo de cambio hacia Producción
– El software está diseñado y construido para permitir implementaciones independientes y desacopladas para familias separadas de sistemas
– El software está diseñado y construido de una manera que aborda la operabilidad, la capacidad de prueba, la liberación, la seguridad y la confiabilidad.
– Los equipos siempre detectan los problemas en producción antes de que los clientes y usuarios se den cuenta
– La responsabilidad y la rendición de cuentas por los cambios de software conducen al empoderamiento y la propiedad
– Trabajar con software es gratificante e interesante
– Estar de guardia y dar soporte al software es sostenible y valioso
– Las personas se sienten seguras para desafiar prácticas y enfoques deficientes
– Los equipos tienen una misión clara y patrones de interacción bien definidos con otros equipos.
Fundamentalmente, las evaluaciones deberían ayudar a desbloquear y habilitar a los equipos para que puedan tener éxito. El equipo debe sentirse alentado y empoderado para decidir qué acciones quieren tomar para mejorar sus procesos y prácticas en base a las discusiones.
Muchas organizaciones encuentran que ejecutar evaluaciones de equipo cada 3 meses proporciona un buen resultado.