Descripción Modelo Operativo DevSecOps

Introducción

El Modelo Operativo DevSecOps define los participantes y roles dentro del ámbito DevSecOps, sus responsabilidades y cómo se relacionan. Así mismo, identificará actores fuera del modelo DevSecOps pero que participan en algún punto del ciclo de vida.

La colaboración y la responsabilidad compartida son esenciales para garantizar que el software cumpla con los requisitos establecidos, se entregue a tiempo y dentro del presupuesto, y se mantenga en funcionamiento de manera estable. Este modelo promueve un ambiente de trabajo positivo, en el que los miembros del equipo se sienten valorados, motivados y están comprometidos con el éxito del proyecto.

En concreto, el Modelo Operativo:

• Define los roles y equipos participantes, identificando aquellos que forman parte del ámbito DevSecOps
• Define funciones y responsabilidades de los mismos
• Asocia las funciones y responsabilidades a los roles mediante una Matriz RASCI
• Define un modelo de relación entre las partes (dentro del ámbito DevSecOps) y con el resto de equipos
• Define una forma de trabajo, haciendo énfasis en la coordinación interna y el seguimiento de las tareas

Contexto

Es necesario definir cómo las prácticas DevSecOps se llevan a la práctica en la ADA, teniendo en cuenta la organización de personas, equipos y sus responsabilidades, nuevas o existentes.

El Modelo Operativo DevSecOps, en el contexto del proyecto de Impulso DevSecOps va de la mano del Proceso de Transición a DevSecOps, como facilitador del cambio de paradigma en el desarrollo y operación de los sistemas.

Estructura del modelo

El modelo definirá los participantes y roles, las responsabilidades asociadas y cómo se relacionan las partes.

También identificará actores fuera del modelo DevSecOps pero que tienen relación e influencia en su funcionamiento.

Ámbito de utilización

Este modelo operativo es de aplicación a todo sistema de información, servicio, componente, aplicación, etc. que:

• Se encuentra en el Proceso de Transición a DevSecOps.

• Se encuentre operativo o en desarrollo para ser desplegado en las infraestructuras de despliegue de la ADA, utilizando el modelo DevSecOps impulsado por el Servicio de Gobierno TI y Calidad y los recursos de la Plataforma CI/CD de DevSecOps.

Glosario de términos

Para una mejor comprensión del Modelo Operativo DevSecOps hay que tener en cuenta la definición de los términos utilizados en el mismo. Para más detalle ver Glosario de términos.

Roles y participantes

Para facilitar la comprensión de la matriz RASCI, a continuación se describen los roles necesarios para definir el modelo, diferenciando entre aquellos que forman parte del modelo propio de los que simplemente participan por tener algún tipo de interacción.

Será un rol el conjunto de funciones (tareas, responsabilidades) a desarrollar por los participantes.
Se denominará participante al equipo de trabajo concreto que desarrollará un rol. Los participantes se tienen que poder ubicar en el organigrama de la ADA de forma precisa.

Los roles se estructurarán en 2 niveles. El rol de primer nivel que hace referencia al contexto y el rol de segundo nivel que lo concreta de forma específica.

Roles en el ámbito del modelo

Son aquellos roles que trabajan continuamente utilizando este Modelo Operativo en el desarrollo del ciclo de vida de los Sistemas de Información utilizando la metodología DevSecOps para el desempeño de sus tareas.

Estos roles son:

• Gestión Negocio y Herramientas
  • DevSecOps
    • Operación
    • Desarrollo
• Impulso DevSecOps
  • Impulso DevSecOps

Para más detalle ver Roles y participantes.

Roles externos estrechamente relacionados con el modelo

Son aquellos roles que tienen interacción y colaboran con los roles anteriores dentro del Modelo Operativo, pero que no tienen por qué aplicar la metodología DevSecOps.

Estos roles son:

• Gestión Infraestructura
  • Infraestructuras
• Arquitectura de Soluciones
  • Arquitectura de Soluciones
• Gestión del Servicio
  • Vigilancia
• Calidad Software
  • Gobierno de Calidad
  • Oficina de Calidad
• Seguridad
  • Unidad de Seguridad TIC

Para más detalle ver Roles y participantes.

Responsabilidades

De forma complementaria a las responsabilidades identificadas al describir los roles, se detallan aquellas que son necesarias para la elaboración de una matriz RASCI que ayude a la coordinación en la ejecución de las mismas.

Existen tareas que dependiendo del entorno (TEST, PRE, PRO) en que esté desplegado el software, la responsabilidad de la misma puede recaer en distintos roles, aunque las acciones a realizar son las mismas. Por ello, en este apartado se describen las tareas/responsabilidades sin tener en cuenta el entorno donde se encuentra desplegado el software. 

Esta distinción de entornos se ha realizado en la matriz RASCI y en las responsabilidades a realizar por cada rol. Si esta distinción no se especifica, es porque ese rol tiene esa responsabilidad en todos los entornos.

La definición de los entornos existentes se detalla en Entornos de Ejecución del Software bajo DevSecOps.

Catálogo de responsabilidades

Cada una de estas responsabilidades se detalla en la página Catálogo de responsabilidades.

Matriz RASCI

La matriz RASCI se detalla en la página Matriz RASCI del Modelo Operativo.

Modelo de relación

En este apartado se identificarán los procedimientos o buenas prácticas de colaboración y comunicación entre equipos.

Procedimientos de colaboración y comunicación interna a DevSecOps

Un equipo DevSecOps se considerará compuesto por aquellas personas que se reúnen periódicamente. La forma de colaboración y comunicación principal dentro del equipo DevSecOps son las reuniones y otras formas de comunicación directa de ámbito grupal (ej: reunión presencial, videoconferencia, mensajería instantánea grupal).

El tamaño y composición exacta de los roles que conforman un equipo DevSecOps dependerá de varios factores: el número y tipología de productos a gestionar, su complejidad, su tecnología específica y los requisitos funcionales y no funcionales, su criticidad, etc. En el apartado DevSecOps, de la página Roles y participantes en el ámbito del modelo, se describe una composición típica, aunque ésta puede ser diferente para cada equipo (e incluso variar durante el ciclo de vida del software). En cualquier caso se busca la autosuficiencia del equipo, incorporando aquellos roles con los cuales se requiere una mayor agilidad en la gestión, a través de la interacción directa.

Que la pertenencia a un equipo DevSecOps permita una mayor agilidad a través de una interacción directa entre sus miembros no debe implicar una pérdida de control del trabajo que se realiza. Las herramientas utilizadas por el equipo DevSecOps permitirán este control, a través del registro de las actividades y los flujos de escalado y autorización. En este sentido, es importante establecer pautas de uso, así como límites, para evitar que un posible mal uso de las herramientas disponibles conlleve una pérdida de control del trabajo realizado.

Por ejemplo, la herramienta de mensajería instantánea o de videoconferencia no es una vía adecuada para realizar una solicitud o escalar una tarea a un equipo. En cambio, sí puede utilizarse para consultar una duda antes de hacer dicha solicitud, para evitar que tenga que ser subsanada.

Relación con otros roles y equipos

Cuando un miembro de un equipo DevSecOps tenga que relacionarse con un equipo u organización externa (esto es, no perteneciente al equipo DevSecOps), empleará para ello el procedimiento o método que tenga establecido dicho equipo u organización (ej: alta de una petición o incidencia vía NAOS o SIO) (en próximas versiones de este documento se definirán estos procedimientos).

Dicho miembro del equipo DevSecOps será un interlocutor designado para establecer esta relación (debiendo haberse tramitado las preautorizaciones necesarias para actuar en nombre del equipo DevSecOps, en caso de ser necesario) y hará el seguimiento de dicha interacción.

Cada vez que se realice este tipo de interacción con otros equipos, quedará así registrado en el sistema de ticketing del equipo DevSecOps (siendo deseable que se incluya, además de la referencia o n.º de ticket, una copia del contenido íntegro de dicha interacción, incluyendo la respuesta recibida y su interpretación y/o consecuencias).

Agrupación de Sistemas de Información

Con el objetivo de optimizar la carga de trabajo de los distintos equipos y reutilizar el conocimiento adquirido, se agruparán los sistemas de información que compartan características o estén relacionados atendiendo a unos criterios establecidos. Estos grupos conformarán los equipos DevSecOps que trabajarán siguiendo las pautas establecidas en el Modelo Operativo.

Se planificarán reuniones periódicas en las que cada equipo DevSecOps analizará las tareas que tiene en curso, los posibles bloqueos que puedan surgir y se establecerán los próximos pasos a seguir.

La periodicidad de las reuniones se establecerá atendiendo a las necesidades de cada equipo DevSecOps, e incluso, si se considera necesario, atendiendo a las necesidades de los sistemas de información en concreto, pudiendo ser este un criterio a tener en cuenta para realizar las agrupaciones.

Podemos diferenciar tres tipos de sistemas de información en función de la evolución de sus desarrollos y la carga de trabajo relacionada:

• Sistemas con carga alta: sistemas de información que están en continua evolución, liberando versiones semanales o quincenales.
• Sistemas con carga media: sistemas de información que liberan versiones mensuales o trimestrales.
• Sistemas con carga baja: sistemas de información que liberan versiones semestrales o anuales.

Para realizar los grupos de sistemas de información (entre 2 y 3 sistemas por grupo) se deberán tener en cuenta los siguientes criterios:

• Nivel de carga del sistema de información.
• Características comunes o relación entre sistemas de información.
• Pertenencia al mismo Organismo.

Asimismo, para poder cubrir las necesidades de sistemas cuya carga es baja o muy baja, o tengan necesidades específicas, se permitirá crear equipos DevSecOps que den servicio a un único sistema de información.

Atendiendo a la carga de los sistemas incluidos en cada grupo, se establecerá la periodicidad de las reuniones:

Herramientas de comunicación

La base del paradigma DevSecOps es la colaboración entre sus miembros siguiendo un enfoque ágil. Para hacer esto posible, se hace necesario establecer mecanismos que permitan una comunicación fluida y permanente entre sus miembros con la ayuda de diversas herramientas.

En lo que respecta al uso de estas herramientas de comunicación, se atenderá a las siguientes condiciones o principios:

• Disponibilidad: Todos los miembros del equipo DevSecOps deberán estar accesibles en todo momento para el resto de miembros (dentro de su horario de dedicación). Para ello se incluirán en una lista accesible por todos los demás miembros sus identificadores e información de contacto en cada herramienta.
• Organización por grupos: Cada miembro pertenecerá a un grupo con la denominación del equipo, unidad funcional de la organización o rol dentro del equipo DevSecOps (p.ej.: Desarrollo, Operaciones, OTP).
• Asignación a grupos: Cada grupo dispondrá de un identificador de grupo en aquellas herramientas que lo soporten. Estos identificadores de grupo serán los que se empleen, preferentemente, para hacerles llegar las solicitudes y escalados, tanto internos como externos (de esta forma se evitará que la vía de entrada de una petición o tarea se dirija a una persona de manera individual, que pueda no estar disponible para atenderla). Cada grupo establecerá un mecanismo para asignar las solicitudes al miembro del equipo, unidad funcional o rol que se encargará de su gestión (p.ej.: mediante autoasignación y/o alertas). En cualquier caso, la falta de asignación individual no debe ser motivo para que se deje de atender una solicitud.

Los equipos DevSecOps tendrán a su disposición el siguiente conjunto de herramientas de comunicación (al menos una por cada tipología):

• Herramientas de ticketing o de gestión de proyectos
• Herramienta de mensajería instantánea
• Herramienta de Videoconferencia
• Herramientas Auxiliares

Seguimiento

El equipo DevSecOps es un equipo de trabajo que sigue una metodología de gestión ágil para llevar a cabo su actividad diaria. Son aplicables muchos de los principios y prácticas de otras metodologías ágiles como Scrum, adaptándose a la casuística específica que conlleva  que trabajen juntos equipos que tradicionalmente han funcionado de manera separada y bajo modelos de gestión diferentes.

DevSecOps no es prescriptivo en cuanto a la forma de organizar el trabajo dentro del propio equipo, por lo que en este sentido, es el proyecto y sus necesidades las que deben marcar la mejor metodología a seguir. Es aceptable, e incluso puede ser aconsejable, que cada equipo de los que componen el DevSecOps siga manteniendo una forma de trabajo a nivel interno independiente (la estipulada por la unidad funcional o departamento de la organización a la que pertenecen, del que dependen orgánicamente), ya sea Scrum, Kanban o incluso ITIL. Si bien, deberían aprovechar el hecho de que exista una comunicación directa con otros miembros del equipo DevSecOps, para que esto se traduzca en una relación más ágil y fluida cuando se atienden solicitudes provenientes de otros agentes externos no pertenecientes al DevSecOps. Ya que, de no ser así, se perderían buena parte de las ventajas que supone pertenecer a un equipo DevSecOps.

A continuación se describirá el funcionamiento de las reuniones que involucran al equipo DevSecOps al completo, esto es, las reuniones de sincronización o Daily DevOps.

Reuniones de sincronización (Daily DevOps)

La Daily DevOps es una reunión periódica, normalmente diaria, que persigue que todos los miembros del equipo estén sincronizados en el trabajo que llevan a cabo. Se asemeja por tanto a la reunión “Daily Scrum”, que se lleva a cabo en la metodología Scrum. En esta reunión principalmente se intenta descubrir de manera temprana los impedimentos que puedan existir para que las tareas asignadas al equipo se realicen correctamente y en plazo.

1. Asistentes
   Como se ha comentado anteriormente, a estas reuniones asisten todos los miembros del equipo DevSecOps, si bien, no tienen que asistir siempre todos los miembros de cada equipo de los que conforman el DevSecOps, sino una representación de cada uno o asistir por turnos. Lo importante es que todos los equipos estén representados en cada reunión.
   Un rol necesario para el correcto funcionamiento de la reunión Daily es el rol de Coordinador DevSecOps, que actúa de manera similar a un Scrum Master. Normalmente la coordinación del equipo DevSecOps será ejercida por un perfil jefe de proyecto o Scrum Master, proveniente de uno de los equipos implicados.
   También debe participar el Product Owner de los productos gestionados por el equipo DevSecOps, y/o miembros de la Dirección del proyecto. Su función será la aprobación de las actuaciones y decisiones que lo requieran.
2. Alcance
   El alcance de cada reunión Daily no tiene por qué incluir todos los productos software gestionados por el equipo DevSecOps al completo. Por ejemplo, puede ser conveniente repartir varios subconjuntos de productos entre los días de la semana disponibles para las reuniones (p.ej. tratar unos productos los lunes, miércoles y viernes, y otros productos los martes y jueves).
3. Preparación previa
   Es aconsejable que exista una orden del día previa para optimizar la asistencia de los miembros a cada reunión (según su involucración en los temas a tratar). Si la reunión Daily DevOps se celebra al final de la mañana, la orden del día puede elaborarse y enviarse con cierta antelación durante la misma mañana (2-3 horas antes), mientras que si el Daily se celebrase a primera hora, la orden del día debería enviarse al final del día anterior.
   El contenido de la orden del día consistirá en un listado de tickets obtenidos a partir del sistema de gestión de proyectos que se vayan a tratar durante la reunión. Para elaborar este listado se seleccionarán aquellos tickets más prioritarios, de mayor impacto, reclamados por el peticionario, bloqueados o que lleven un tiempo sin actualizarse (p.ej: más de 5 días), y que por tanto sea conveniente hacerles un seguimiento más estrecho para, con la colaboración de todo el equipo, intentar desbloquearlos y acelerar su resolución.
   Cualquier miembro del equipo DevSecOps puede proponer tickets para su inclusión en la orden del día.
4. Desarrollo de la reunión
   Durante la reunión se revisan cada uno de los tickets de la orden del día, y se procede a tomar una decisión consensuada sobre la mejor manera de continuar con su resolución. Estas decisiones pueden ser, p.ej., la asignación de un ticket, su priorización, su bloqueo, desbloqueo o incluso anulación dependiendo de las dependencias que tenga con otras actuaciones en marcha o previstas, el cambio de su alcance, la conveniencia de dividirlo en subtareas, la toma de decisiones técnicas o de ámbito funcional, la necesidad de abordar una reunión de trabajo entre varios equipos involucrados en su resolución, etc... La reunión Daily no es una reunión de trabajo, por lo que no debería dedicarse demasiado tiempo a examinar en detalle cada ticket, sino sólo lo necesario para que el asignatario pueda continuar con la tramitación del mismo.
   La reunión Daily también puede utilizarse como una suerte de CAB (Change Advisory Board) ágil, en el que se repasan los cambios pendientes de autorización, de forma que se aprueben y puedan pasar a ser realizados (por este motivo deben asistir los roles de Product Owner y/o la Dirección del proyecto).
   La duración total de la reunión no debería exceder de unos 30 minutos. Si es necesario abordar algún tema con mayor profundidad, se puede tratar en una reunión ad-hoc o de trabajo posterior, a la que asistan sólo los miembros del equipo involucrados (p.ej. a continuación del Daily).
5. Conclusiones de la reunión
   Todas las decisiones tomadas en el Daily DevOps se anotan en el propio histórico de los tickets tratados por parte del Coordinador DevOps (esto hace innecesario levantar acta de cada reunión, en aras de una mayor agilidad).
   Periódicamente se extraerán métricas o estadísticas, a partir de la información contenida en los tickets empleando para ello la herramienta de gestión de proyectos, de forma que se pueda dar cuenta del avance de cada uno de los productos software en las reuniones de seguimiento con los Product Owners o la Dirección del proyecto.

Reuniones de seguimiento y de trabajo

Estas reuniones no difieren de las que se realizan habitualmente en otros paradigmas de gestión de proyectos.

Las reuniones de trabajo son reuniones de nivel operativo en la que un subconjunto del equipo DevSecOps se ponen de acuerdo en un momento temporal concreto (no son periódicas) y se reservan el tiempo necesario para realizar conjuntamente una actividad (trabajo habitualmente relacionado con la resolución de una tarea o historia de usuario del backlog del producto). Estas reuniones pueden llevarse a cabo ya sea de manera presencial o en remoto, siempre que se tenga acceso a la herramientas necesarias para efectuar la actividad prevista (y sincronizándose vía mensajería instantánea o videoconferencia).

Las reuniones de seguimiento, por otra parte, se programan con menor periodicidad que las reuniones Daily de sincronización (p.ej. con periodicidad semanal, mensual, trimestral o semestral), y necesariamente involucran a los Product Owners y/o la Dirección del proyecto. El objetivo es dar cuenta de los avances desde un punto de vista de más alto nivel que el operativo (en este sentido son reuniones de nivel táctico o estratégico), tratándose cuestiones como: la disponibilidad de recursos humanos o económicos , la involucración de actores externos al equipo del proyecto, o la imagen externa que se tiene del proyecto, los productos o la organización como consecuencia del trabajo realizado. De estas reuniones habitualmente se extraerá un acta en la que queden reflejados los acuerdos alcanzados.