# Representaciones del modelo operativo 2 por 2 Estas representaciones del modelo operativo 2 por 2 son ilustraciones que le ayudan a comprender las relaciones entre los equipos de su entorno. Estos diagramas se centran en quién hace qué y en las relaciones entre los equipos, pero también analizaremos la gobernanza y la toma de decisiones en el contexto de estos ejemplos. Sus equipos pueden tener responsabilidades en varias partes de varios modelos, según las cargas de trabajo que admitan. Es posible que desee desglosar áreas disciplinarias más especializadas que las de alto nivel descritas. Existe la posibilidad de que estos modelos varíen infinitamente a medida que se separen o agreguen actividades, o se superpongan equipos y se proporcionen detalles más específicos. Puede darse cuenta de que sus capacidades se superponen o no se reconocen en todos los equipos y que pueden proporcionar una ventaja adicional o generar eficiencias. También puede identificar las necesidades insatisfechas de su organización que pueda planificar abordar. Al evaluar el cambio organizativo, examina las ventajas y desventajas entre los distintos modelos, en qué lugar se encuentran sus equipos individuales dentro de los modelos (ahora y después del cambio), cómo cambiarán las relaciones y las responsabilidades de sus equipos y si los beneficios merecen repercutir en su organización. Puede tener éxito con cada uno de los cuatro modelos operativos siguientes. Algunos modelos son más apropiados para casos de uso específicos o en puntos específicos del desarrollo. Algunos de estos modelos pueden ofrecer ventajas con respecto a los que se utilizan en su entorno. **Topics** + [Modelo operativo completamente separado](fully-separated-operating-model.md) + [DevOps con proveedor de servicios administrados en la nube](devops-with-cloud-managed-service-provider.md) + [Operaciones en la nube y habilitación de plataformas (COPE)](cloud-operations-and-platform-enablement.md) + [DevOps distribuidas](distributed-devops.md) + [DevOps descentralizadas](decentralized-devops.md) + [Evolución de su modelo operativo](evolving-your-ops-model.md) # Modelo operativo completamente separado En el siguiente diagrama, en el eje vertical tenemos las aplicaciones y la plataforma. Las aplicaciones se refieren a la carga de trabajo que genera un resultado empresarial y pueden ser software desarrollado a medida o adquirido. La plataforma se refiere a la infraestructura física y virtual y a otro software compatible con esa carga de trabajo. En el eje horizontal, tenemos Ingeniería y Operaciones. La ingeniería se refiere al desarrollo, la creación y las pruebas de aplicaciones e infraestructuras. Las operaciones son la implementación, la actualización y el soporte continuo de las aplicaciones y la infraestructura. ![\[Diagrama del modelo tradicional\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/operational-excellence-pillar/images/full-seperate.png) Históricamente, las organizaciones adoptaron marcos como ITIL o estándares como ISO y moldearon sus actividades operativas en torno a ellos, lo que a menudo dio como resultado una topología completamente separada. En este modelo, las actividades de cada cuadrante las lleva a cabo un equipo independiente. El trabajo se transfiere entre los equipos mediante mecanismos como las solicitudes de trabajo, las colas o los tickets, o mediante un sistema de gestión de servicios de TI (ITSM). La transición de las tareas a los equipos o entre ellos aumenta la complejidad y crea cuellos de botella y retrasos. Las solicitudes pueden retrasarse hasta que se conviertan en una prioridad. Los defectos detectados tardíamente pueden requerir una revisión importante y es posible que tengan que volver a pasar por los mismos equipos y sus funciones. Si hay incidentes que requieren la adopción de medidas por parte de los equipos de ingeniería, sus respuestas se retrasan debido a la actividad de transferencia. Existe un mayor riesgo de desalineación cuando los equipos de negocios, desarrollo y operaciones se organizan en torno a las actividades o funciones que se llevan a cabo. Esto puede llevar a que los equipos se centren en sus responsabilidades específicas en lugar de centrarse en lograr resultados empresariales. Los equipos pueden estar muy especializados, aislados físicamente o aislados lógicamente, lo que dificulta la comunicación y la colaboración. # DevOps con proveedor de servicios administrados en la nube El modelo de DevOps con proveedor de servicios gestionados en la nube sigue una metodología de *creación y ejecución* para los equipos de aplicaciones. Sin embargo, es posible que su organización no cuente con las habilidades o los miembros del equipo necesarios para respaldar a un equipo dedicado de ingeniería y operaciones de plataformas, o puede que no esté en condiciones de invertir el tiempo y el esfuerzo necesarios para hacerlo. Como alternativa, es posible que desee contar con un equipo de plataformas que se centre en crear capacidades que diferencien a su empresa, pero que prefiera subcontratar las operaciones diarias indiferenciadas. Los proveedores de servicios administrados como [AWS Managed Services](https://aws.amazon.com/managed-services/) o proveedores de la [AWS Partner Network](https://aws.amazon.com/partners/find/results/?keyword=Managed+Service+Provider) proporcionan experiencia en la implementación de entornos en la nube y admiten sus requisitos de seguridad y cumplimiento y sus objetivos empresariales. ![\[DevOps con proveedor de servicios administrados en la nube\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/operational-excellence-pillar/images/devops-msp.en.png) Para esta variante, tratamos la gobernanza como centralizada y gestionada por el equipo de la plataforma, mientras que la creación de cuentas y las políticas se gestionan con AWS Organizations y AWS Control Tower. Este modelo requiere que modifique sus mecanismos para que funcionen con los de su proveedor de servicios. No aborda los cuellos de botella y los retrasos creados por la transición de tareas entre los equipos, incluido el proveedor de servicios, ni las posibles modificaciones relacionadas con la detección tardía de los defectos. Aprovecha los estándares, las prácticas recomendadas, los procesos y la experiencia de sus proveedores. También obtendrá los beneficios del desarrollo continuo de sus ofertas de servicios. La incorporación de los servicios administrados a su modelo operativo puede ahorrarle tiempo y recursos, y hace que sus equipos internos sigan centrados en los resultados estratégicos que diferenciarán a su empresa, en lugar de desarrollar nuevas competencias y capacidades. También puede proporcionarle tiempo para desarrollar y desarrollar las capacidades de su propia plataforma sin ralentizar sus programas de migración a la nube. # Operaciones en la nube y habilitación de plataformas (COPE) Este modelo de operaciones en la nube y habilitación de plataformas (COPE) busca establecer una metodología de *creación y ejecución*, ya que permiten que los equipos de aplicaciones lleven a cabo las actividades de ingeniería y operaciones para sus cargas de trabajo mediante la adopción de una cultura de DevOps. Es posible que sus equipos de aplicaciones tengan la tarea de migrar, adoptar la nube o modernizar sus cargas de trabajo, pero es posible que no tengan las habilidades necesarias para respaldar adecuadamente la arquitectura y las operaciones de la nube. Es probable que esta falta de capacidades y familiaridad del equipo de aplicaciones ralentice la agilidad de su organización y repercuta en los resultados empresariales. Para resolver este problema, utilice la experiencia operativa que ya tiene en su organización para ayudar a los equipos de aplicaciones en su transición hacia las operaciones en la nube. Puede ser un equipo dedicado de expertos o un equipo virtual con participantes seleccionados de toda la organización. Sin embargo, el objetivo sigue siendo el mismo: proporcionar un apoyo operativo que desarrolle la capacidad del equipo de carga de trabajo mediante principios de automatización basados en la nube, la eliminación del trabajo pesado indiferenciado, patrones estandarizados y la promoción de la autonomía. El objetivo es desarrollar las capacidades de la nube con suficiente madurez y reducir la barrera de las responsabilidades operativas para que los equipos de aplicaciones ya no necesiten soporte adicional. El modelo COPE se centra en el nivel de carga de trabajo. Si varios equipos necesitan este enfoque a la vez, si está llevando a cabo un proyecto de migración complejo, a gran escala y de varios años, o si está creando una plataforma para respaldar estas iniciativas, considere la posibilidad de utilizar un Centro de excelencia en la nube (CCoE). Este es un mecanismo que muchos han tenido éxito cuando buscan acelerar sus migraciones a la nube y transformar ampliamente su organización. ![\[Diagrama Operaciones en la nube y habilitación de plataformas (COPE)\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/operational-excellence-pillar/images/cope.en.png) Su equipo de ingeniería de plataformas crea una capa delgada de capacidades básicas de plataforma compartida, que se basan en estándares predefinidos para que los adopten los equipos de aplicaciones y que proporciona el equipo de COPE. El equipo de ingeniería de plataformas codifica las arquitecturas y patrones de referencia empresariales que se proporcionan a los equipos de aplicaciones mediante un mecanismo de autoservicio. Con un servicio como AWS Service Catalog, los equipos de aplicaciones pueden implementar arquitecturas, patrones, servicios y configuraciones de referencia aprobados, que cumplan de forma predeterminada con los estándares de gobierno y seguridad centralizados. El equipo de ingeniería de plataformas también proporciona un conjunto estandarizado de servicios (por ejemplo, herramientas de desarrollo, herramientas de observación, herramientas de copia de seguridad y recuperación y redes) a los equipos de aplicaciones. El equipo de COPE gestiona y admite los servicios estandarizados y proporciona asistencia a los equipos de aplicaciones para establecer su presencia en la nube en función de las arquitecturas y patrones de referencia. Trabajan con los equipos de aplicaciones para ayudarles a establecer las operaciones de referencia. Durante este proceso, los equipos de aplicaciones asumen progresivamente más responsabilidad por sus sistemas y recursos a lo largo del tiempo. El equipo de COPE impulsa la mejora continua junto con el equipo de ingeniería de la plataforma y actúa como proponente para los equipos de aplicaciones. Los equipos de aplicaciones reciben asistencia para configurar los entornos, los procesos de CI/CD, la gestión de cambios, la observabilidad y la supervisión, y establecer los procesos de gestión de incidentes y eventos, con el equipo de COPE integrado según sea necesario. El equipo de COPE participa con los equipos de aplicaciones en estas actividades operativas y, con el tiempo, va reduciendo gradualmente la participación del equipo de COPE a medida que los equipos de aplicaciones asumen la responsabilidad. El equipo de aplicaciones se beneficia de las habilidades del equipo de COPE y de las lecciones aprendidas por la organización. Están protegidos por las barreras de protección establecidas mediante una gobernanza centralizada. El equipo de aplicaciones se basa en éxitos reconocidos y se beneficia del desarrollo continuo de los estándares organizacionales que ha adoptado. Obtienen una mejor visión del funcionamiento de su carga de trabajo mediante el proceso de establecer la observabilidad y la supervisión, y son capaces de comprender mejor el impacto de los cambios que llevan a cabo en sus cargas de trabajo. El equipo de COPE también puede retener el acceso necesario para respaldar las actividades operativas, ofrecer una visión de las operaciones empresariales que abarque a los equipos de aplicaciones y ofrecer asistencia en la administración de incidentes críticos. El equipo de COPE sigue siendo responsable de las actividades que se consideran cargas pesadas indiferenciadas y las llevan a cabo mediante soluciones estándares compatibles a gran escala. También siguen gestionando actividades operativas automatizadas y programáticas bien conocidas para que los equipos de aplicaciones puedan centrarse en diferenciar sus aplicaciones. Obtiene la ventaja de los estándares, las prácticas recomendadas, los procesos y la experiencia de su organización, derivados del éxito de sus equipos. Establece un mecanismo para replicar estos patrones exitosos para los nuevos equipos que los adopten o se modernicen en la nube. Este modelo hace hincapié en la capacidad del equipo de COPE para ayudar a los equipos de aplicaciones a adquirir conocimientos y artefactos consolidados y llevar a cabo la transición. Reduce las cargas operativas de los equipos de aplicaciones, con el riesgo de que los equipos de aplicaciones no logren independizarse. Establece relaciones entre los equipos de ingeniería de plataformas, COPE y aplicaciones, lo que crea un circuito de retroalimentación para permitir más evolución e innovación. Establecer sus equipos de ingeniería de plataformas y COPE y, al mismo tiempo, definir los estándares para toda la organización puede facilitar la adopción de la nube y respaldar los esfuerzos de modernización. Al proporcionar el apoyo adicional de un equipo de COPE que actúa como consultor y socio de sus equipos de aplicaciones, puede eliminar las barreras de la carga de trabajo que ralentizan la adopción de las beneficiosas capacidades de la nube por parte de los equipos de aplicaciones. # DevOps distribuidas El modelo de DevOps distribuido separa (o distribuye) las responsabilidades de las operaciones de ingeniería de aplicaciones y las operaciones de ingeniería de infraestructura entre los equipos de ingeniería, según la [metodología COPE](cloud-operations-and-platform-enablement.md). Sus ingenieros de aplicaciones se encargan tanto de la ingeniería como de la operación de sus cargas de trabajo. Del mismo modo, sus ingenieros de infraestructura se encargan tanto de la ingeniería como de la operación de las plataformas que utilizan para dar soporte a los equipos de aplicaciones. ![\[Diagrama del modelo de DevOps distribuidas\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/operational-excellence-pillar/images/distributed-devops.en.png) En este ejemplo, tratamos la gobernanza como centralizada en cualquier parte de la organización. Los estándares se distribuyen, proporcionan o comparten entre los equipos de aplicaciones y plataformas. Utilice herramientas o servicios que le ayudan a controlar de forma centralizada sus entornos en todas las cuentas, como [AWS Organizations](https://aws.amazon.com/organizations/). Los servicios como [AWS Control Tower](https://aws.amazon.com/controltower/features/) amplían esta capacidad de administración al ayudarle definir esquemas (que respaldan sus modelos operativos) para la configuración de las cuentas, aplicar una gobernanza continua mediante AWS Organizations y automatizar el aprovisionamiento de nuevas cuentas. *Creación y ejecución* no significa que el equipo de aplicaciones sea responsable de toda la cadena de herramientas, la plataforma y la pila completa. El equipo de ingeniería de plataformas proporciona un conjunto estandarizado de servicios (por ejemplo, herramientas de desarrollo, herramientas de supervisión, herramientas de copia de seguridad y recuperación y redes) al equipo de aplicaciones. El equipo de la plataforma también puede proporcionar al equipo de aplicaciones acceso a los servicios aprobados del proveedor de servicios en la nube, a configuraciones específicas de los mismos o a ambos. Los mecanismos que proporcionan una capacidad de autoservicio para implementar servicios y configuraciones aprobados, como Service Catalog, pueden ayudar a limitar los retrasos asociados con las solicitudes de cumplimiento y, al mismo tiempo, reforzar la gobernanza. El equipo de la plataforma activa una visibilidad de pila completa para que los equipos de aplicaciones puedan diferenciar entre los problemas relacionados con los componentes de sus aplicaciones y los servicios y componentes de infraestructura que consumen sus aplicaciones. El equipo de la plataforma también puede proporcionar asistencia para configurar estos servicios y orientación sobre cómo mejorar las operaciones del equipo de aplicaciones. Como se mencionó anteriormente, es fundamental que existan mecanismos para que los equipos de aplicaciones soliciten adiciones, cambios y excepciones a las normas en apoyo de las actividades y la innovación de sus aplicaciones. El modelo de DevOps distribuidas proporciona sólidos circuitos de retroalimentación a los equipos de aplicaciones. Las operaciones diarias de una carga de trabajo aumentan el contacto con los clientes, ya sea mediante la interacción directa o indirectamente mediante solicitudes de soporte y características. Esta mayor visibilidad permite a los equipos de aplicaciones abordar los problemas con mayor rapidez. El compromiso más profundo y la relación más estrecha proporcionan información sobre las necesidades de los clientes y generan una innovación más rápida. Todo esto también es válido para el equipo de plataforma que apoya a los equipos de aplicaciones, ya que el equipo de plataforma debería ver a estos equipos de aplicaciones como sus clientes. Los estándares adoptados pueden aprobarse previamente para su uso, lo que reduce la cantidad de revisiones necesarias para iniciar la producción. Consumir los estándares comprobados y respaldados proporcionados por el equipo de la plataforma puede reducir la frecuencia de los problemas con esos servicios. La adopción de estándares ayuda a los equipos de aplicaciones a centrarse en diferenciar sus cargas de trabajo. # DevOps descentralizadas El modelo de DevOps descentralizadas es una variación de la metodología de *creación y ejecución* en la que las operaciones son principalmente propiedad de los equipos de carga de trabajo. Sus ingenieros de aplicaciones se encargan tanto de la ingeniería como de las operaciones de sus cargas de trabajo. Del mismo modo, sus ingenieros de infraestructura se encargan tanto de la ingeniería como de las operaciones de las plataformas que utilizan para dar soporte a los equipos de aplicaciones. ![\[Diagrama de DevOps descentralizadas\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/operational-excellence-pillar/images/decentralized-devops.en.png) En este ejemplo, tratamos la gobernanza como descentralizada. El equipo de la plataforma sigue distribuyendo, proporcionando o compartiendo los estándares entre los equipos de aplicaciones, pero los equipos de aplicaciones son libres de diseñar y utilizar las nuevas capacidades de la plataforma en apoyo de su carga de trabajo. En este modelo, el equipo de aplicaciones tiene menos limitaciones, pero eso conlleva un aumento significativo de las responsabilidades. Debe contar con habilidades adicionales (y, posiblemente, miembros del equipo) para respaldar las capacidades adicionales de la plataforma. El riesgo de que se produzcan modificaciones importantes aumenta si los conjuntos de habilidades son inadecuados y los defectos no se detectan a tiempo. Haga cumplir las políticas que no estén delegadas específicamente a los equipos de aplicaciones. Utilice herramientas o servicios que le ayudan a controlar de forma centralizada sus entornos en todas las cuentas, como [AWS Organizations](https://aws.amazon.com/organizations/). Los servicios como [AWS Control Tower](https://aws.amazon.com/controltower/features/) amplían esta capacidad de administración al ayudarle definir esquemas (que respaldan sus modelos operativos) para la configuración de las cuentas, aplicar una gobernanza continua mediante AWS Organizations y automatizar el aprovisionamiento de nuevas cuentas. Es beneficioso contar con mecanismos para que el equipo de aplicaciones solicite adiciones y cambios en las normas. Puede aportar nuevos estándares que pueden beneficiar a otros equipos de aplicaciones. Los equipos de la plataforma pueden decidir que proporcionar soporte directo para estas capacidades adicionales es un apoyo eficaz a los resultados empresariales. Este modelo limita las restricciones a la innovación con requisitos importantes de habilidades y miembros del equipo. Aborda muchos de los obstáculos y retrasos creados por la transición de tareas entre equipos y, al mismo tiempo, promueve el desarrollo de relaciones efectivas entre los equipos y los clientes. # Evolución de su modelo operativo Los modelos ofrecidos avanzan progresivamente hacia una mayor autonomía a nivel de carga de trabajo, según el principio de equipos de dos pizzas. Es importante entender que este proceso desde un enfoque tradicional a DevOps descentralizadas (como base para una evolución continua hacia un modelo de equipo de dos pizzas) probablemente lleve tiempo y requiera desarrollar la madurez de una serie de capacidades. Por lo tanto, hemos proporcionado un ejemplo de cómo puede llevar a cabo la transición entre modelos a medida que su equipo y su organización avanzan en el proceso de transformación empresarial. En cada cambio o modelo, evoluciona hacia un equipo más autónomo, pero alineado con la organización al mismo tiempo. ![\[Diagrama de evolución del modelo operativo en la nube de procesos y flujos de valor en las instalaciones a flujos de valor automatizados\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/operational-excellence-pillar/images/evolving-ops.en.png) Al evaluar la forma en que su equipo puede respaldar la evolución de su organización, examine las ventajas y desventajas entre los distintos modelos, si sus equipos individuales se encuentran dentro de los modelos (a medida que van pasando y evolucionando), cómo podrían cambiar la relación y las responsabilidades de su equipo y si los beneficios merecen repercutir en su organización. Tenga en cuenta que el cambio nunca es lineal. Algunos modelos son más adecuados para casos de uso o momentos específicos del proceso, y algunos de estos modelos pueden ofrecer ventajas en comparación con los de su entorno.