# Modelo operativo
En esta sección, ofrecemos una forma de entender el modelo operativo con el que trabaja, cómo se puede visualizar ese modelo y cómo, a nivel de equipo, debe evolucionar para obtener el máximo valor de su inversión en servicios en la nube. De este modo, puede mejorar sus prácticas operativas, crear equipos y cargas de trabajo ágiles y contribuir positivamente a los resultados empresariales.
Es habitual que el equipo se encuentre en varios niveles organizativos, y que esos niveles tengan formas de trabajar ya existentes. Participar con el equipo en la consecución de resultados empresariales significa entender dónde se encuentran los equipos en esos niveles, la posición de los equipos con los que interactúa y cómo trabajan. Por lo tanto, los equipos tienen que comprender el rol que tienen en el éxito de otros equipos, conocer el rol de los demás equipos en su propio éxito y tener objetivos en común.
Estas capas constituyen el modelo operativo general de la organización. El funcionamiento de la organización para obtener resultados empresariales depende de muchos factores, como el tipo, el sector, la geografía, el tamaño y el nivel de autonomía. Sin embargo, es probable que se clasifique en tres categorías amplias:
+ Centralizado
+ Descentralizado
+ Federado
Estas topologías de organización se describen en [Organize for success](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-cloud-operating-model/implement-roadmap.html#organize).
Su equipo y su carga de trabajo se encuentran dentro del modelo operativo de su organización. No es razonable esperar que un único modelo operativo sea capaz de respaldar a todos los equipos y sus cargas de trabajo. Por lo tanto, su equipo también necesita su propio modelo operativo. Esta forma de trabajar depende de la organización, el departamento, la composición del equipo y las características de la propia carga de trabajo.
La mayoría de las organizaciones que se trasladan a la nube lo hacen como parte de un programa de transformación empresarial que busca descubrir nuevas formas de trabajar (el modelo operativo) para respaldar los objetivos estratégicos a largo plazo. Este viaje no es un ejercicio puntual, sino un proceso que requiere una evolución continua y un progreso gradual hacia el objetivo estratégico. Esto permite a los propietarios de las cargas de trabajo adaptarse al modelo operativo en evolución con una interrupción mínima.
Amazon se suele utilizar como ejemplo de cómo una gran organización es capaz de innovar a escala, ya que permite a los equipos mantenerse cerca de los clientes, lanzar rápidamente productos y servicios innovadores y aprovechar las arquitecturas técnicas que respaldan la velocidad y la agilidad. Esto nos obligó a reestructurar la forma en que se organizan nuestros equipos, lo que ahora se conoce como equipos de *dos pizzas*. Un equipo formado por dos personas cuenta con todos los recursos necesarios (ingeniería, pruebas, gestión de productos y programas y operaciones) para poseer y ejecutar una carga de trabajo de extremo a extremo.
Recomendamos adoptar este modelo operativo como una forma comprobada de que los equipos de carga de trabajo pueden actuar con rapidez y contribuir a los resultados empresariales generales de la manera que mejor sirva a sus clientes.
Es posible que las organizaciones que deseen emular este éxito necesiten adaptar su modelo operativo a lo largo de su proceso de transformación. Tanto en una organización como en un equipo, esto requiere consideración, planificación y comunicación. La siguiente sección proporciona una forma de visualizar estos modelos operativos a nivel de equipo y cómo evolucionan para *crearlos y ejecutarlos*.
# 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.
# Relaciones y propiedad
Su modelo operativo define las relaciones entre los equipos y respalda la propiedad y la responsabilidad identificables.
**Topics**
+ [OPS02-BP01 Recursos con propietarios identificados](ops_ops_model_def_resource_owners.md)
+ [OPS02-BP02 Procesos y procedimientos con propietarios identificados](ops_ops_model_def_proc_owners.md)
+ [OPS02-BP03 Actividades operativas con propietarios identificados responsables de su rendimiento](ops_ops_model_def_activity_owners.md)
+ [OPS02-BP04 Mecanismos existentes para administrar las responsabilidades y la propiedad](ops_ops_model_def_responsibilities_ownership.md)
+ [OPS02-BP05 Mecanismos para solicitar adiciones, cambios y excepciones](ops_ops_model_req_add_chg_exception.md)
+ [OPS02-BP06 Responsabilidades predefinidas o negociadas entre equipos](ops_ops_model_def_neg_team_agreements.md)
# OPS02-BP01 Recursos con propietarios identificados
Los recursos para su carga de trabajo deben tener propietarios identificados para el control de cambios, la resolución de problemas y otras funciones. Se asignan propietarios para las cargas de trabajo, las cuentas, la infraestructura, las plataformas y las aplicaciones. La propiedad se registra mediante herramientas como un registro central o metadatos adjuntos a los recursos. El valor empresarial de los componentes determina los procesos y los procedimientos que se les aplican.
**Resultado deseado:**
+ Los recursos tienen propietarios identificados mediante metadatos o un registro central.
+ Los miembros del equipo pueden identificar a quién pertenecen los recursos.
+ Las cuentas tienen un único propietario siempre que sea posible.
**Patrones comunes de uso no recomendados:**
+ Los contactos alternativos para sus Cuentas de AWS no están asignados.
+ Los recursos carecen de etiquetas que identifiquen a qué equipos pertenecen.
+ Tiene una cola de ITSM sin una asignación de correo electrónico.
+ Dos equipos tienen la propiedad solapada de un elemento fundamental de la infraestructura.
**Beneficios de establecer esta práctica recomendada:**
+ El control de cambios de los recursos resulta sencillo con una propiedad asignada.
+ Puede implicar a los propietarios adecuados a la hora de solucionar problemas.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
Defina qué significa la propiedad para los casos de uso de los recursos en su entorno. La propiedad puede indicar quién supervisa los cambios en el recurso, quién lo respalda durante la resolución de problemas o quién es responsable desde el punto de vista financiero. Especifique y registre los propietarios de los recursos, incluido el nombre, la información de contacto, la organización y el equipo.
**Ejemplo de cliente**
AnyCompany Retail define la propiedad como el equipo o la persona que se encarga de los cambios y de la asistencia a los recursos. Usa AWS Organizations para administrar sus Cuentas de AWS. Los contactos alternativos de la cuenta se configuran mediante bandejas de entrada de grupo. Cada cola de ITSM se asigna a un alias de correo electrónico. Las etiquetas identifican a quién pertenecen los recursos de AWS. Para otras plataformas e infraestructuras, tiene una página wiki en la que se identifican la propiedad y la información de contacto.
### Pasos para la implementación
1. Empiece con la definición de la propiedad de su organización. La propiedad puede implicar quién es el propietario del riesgo del recurso, quién es el propietario de los cambios en el recurso o quién presta asistencia al recurso cuando se solucionan problemas. La propiedad también podría implicar la propiedad financiera o administrativa del recurso.
1. Se usa [AWS Organizations](https://aws.amazon.com/organizations/) para administrar cuentas. Puede administrar los contactos alternativos de sus cuentas de forma centralizada.
1. Si utiliza las direcciones de correo electrónico y los números de teléfono de la empresa como información de contacto, podrá comunicarse aunque la persona a la que pertenezca dicha dirección o teléfono haya abandonado la organización. Por ejemplo, cree listas de correo electrónico diferentes para la facturación, las operaciones y la seguridad, y configure estos contactos como Facturación, Seguridad y Operaciones en cada Cuenta de AWS activa. Las notificaciones de AWS llegarán a diversas personas y se responderán incluso si alguien está de vacaciones, cambia de rol o deja la empresa.
1. En caso de que [AWS Organizations](https://aws.amazon.com/organizations/) no administre una cuenta, los contactos alternativos de esta permitirán que AWS pueda ponerse en contacto con las personas adecuadas si fuera necesario. Configure los contactos alternativos de la cuenta para que apunten a un grupo en lugar de a una persona.
1. Utilice etiquetas para identificar a los propietarios de los recursos de AWS. Puede especificar tanto los propietarios como su información de contacto en etiquetas independientes.
1. Puede usar reglas de [AWS Config](https://aws.amazon.com/config/) para garantizar que los recursos tengan las etiquetas de propiedad requeridas.
1. Para obtener instrucciones detalladas sobre cómo crear una estrategia de etiquetado para su organización, consulte el [documento técnico sobre prácticas recomendadas de etiquetado de AWS](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html).
1. Utilice [Amazon Q Business](https://aws.amazon.com/q/business/), un asistente conversacional que utiliza IA generativa para mejorar la productividad de la fuerza laboral, responder preguntas y completar tareas en función de la información de los sistemas empresariales.
1. Conecte Amazon Q Business al origen de datos de su empresa. Amazon Q Business ofrece conectores prediseñados para más de 40 orígenes de datos compatibles, incluidos Amazon Simple Storage Service (Amazon S3), Microsoft SharePoint, Salesforce y Atlassian Confluence. Para obtener más información, consulte [Conectores de Amazon Q Business](https://aws.amazon.com/q/business/connectors/).
1. Para otros recursos, plataformas e infraestructuras, cree documentación que identifique la propiedad. Todos los miembros del equipo deben poder acceder a ella.
**Nivel de esfuerzo para el plan de implementación:** bajo. Utilice la información de contacto de la cuenta y las etiquetas para asignar la propiedad de los recursos de AWS. Para otros recursos puede utilizar algo tan simple como una tabla en un wiki para registrar la propiedad y la información de contacto o una herramienta ITSM para asignar la propiedad.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [OPS02-BP02 Procesos y procedimientos con propietarios identificados](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html)
+ [OPS02-BP04 Mecanismos existentes para administrar las responsabilidades y la propiedad](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_responsibilities_ownership.html)
**Documentos relacionados:**
+ [AWS Account Management - Updating contact information](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html)
+ [AWS Organizations - Updating alternative contacts in your organization](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_update_contacts.html)
+ [Documento técnico sobre prácticas recomendadas de etiquetado de AWS](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [Build private and secure enterprise generative AI apps with Amazon Q Business and AWS IAM Identity Center](https://aws.amazon.com/blogs/machine-learning/build-private-and-secure-enterprise-generative-ai-apps-with-amazon-q-business-and-aws-iam-identity-center/)
+ [Amazon Q Business, now generally available, helps boost workforce productivity with generative AI](https://aws.amazon.com/blogs/aws/amazon-q-business-now-generally-available-helps-boost-workforce-productivity-with-generative-ai/)
+ [Nube de AWS Operations & Migrations Blog - Implementing automated and centralized tagging controls with AWS Config and AWS Organizations](https://aws.amazon.com/blogs/mt/implementing-automated-and-centralized-tagging-controls-with-aws-config-and-aws-organizations/)
+ [AWS Security Blog - Extend your pre-commit hooks with AWS CloudFormation Guard](https://aws.amazon.com/blogs/security/extend-your-pre-commit-hooks-with-aws-cloudformation-guard/)
+ [AWS DevOps Blog - Integrating AWS CloudFormation Guard into CI/CD pipelines](https://aws.amazon.com/blogs/devops/integrating-aws-cloudformation-guard/)
**Talleres relacionados:**
+ [AWS Workshop: Tagging](https://catalog.workshops.aws/tagging/)
**Ejemplos relacionados:**
+ [Reglas de AWS Config - Amazon EC2 with required tags and valid values](https://github.com/awslabs/aws-config-rules/blob/master/python/ec2_require_tags_with_valid_values.py)
**Servicios relacionados:**
+ [Reglas de AWS Config - required-tags](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html)
+ [AWS Organizations](https://aws.amazon.com/organizations/)
# OPS02-BP02 Procesos y procedimientos con propietarios identificados
Conozca quién tiene la propiedad de la definición de procesos y procedimientos específicos, por qué se utilizan esos procesos y procedimientos y por qué existe esa propiedad. Comprender las razones por las que se utilizan procesos y procedimientos específicos permite identificar las oportunidades de mejora.
**Resultado deseado:** su organización cuenta con un conjunto de procesos y procedimientos bien definidos y mantenidos para las tareas operativas. El proceso y los procedimientos se almacenan en una ubicación central y están disponibles para los miembros de su equipo. El proceso y los procedimientos se actualizan con frecuencia, a través de la propiedad claramente asignada. Siempre que es posible, los scripts, las plantillas y los documentos de automatización se implementan como código.
**Patrones comunes de uso no recomendados:**
+ Los procesos no se documentan. Pueden existir scripts fragmentados en estaciones de trabajo de operadores aisladas.
+ Solo unas pocas personas o el equipo de manera informal saben cómo usar los scripts.
+ Está previsto actualizar un proceso heredado, pero la propiedad de la actualización no está clara y el autor original ya no forma parte de la organización.
+ Los procesos y los scripts no se pueden detectar, por lo que no están disponibles cuando son necesarios (por ejemplo, en respuesta a un incidente).
**Beneficios de establecer esta práctica recomendada:**
+ Los procesos y procedimientos impulsan sus esfuerzos para gestionar sus cargas de trabajo.
+ Los nuevos miembros del equipo se hacen eficaces más rápidamente.
+ Reducción del tiempo para mitigar los incidentes.
+ Los diferentes miembros del equipo (y equipos) pueden usar los mismos procesos y procedimientos de manera coherente.
+ Los equipos pueden escalar sus procesos con procesos repetibles.
+ Los procesos y procedimientos estandarizados ayudan a mitigar el impacto de transferir las responsabilidades de las cargas de trabajo entre los equipos.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
+ Los procesos y procedimientos tienen propietarios identificados que son responsables de su definición.
+ Identifique las actividades operativas que se han llevado a cabo para ayudar a sus cargas de trabajo. Documente estas actividades en un lugar accesible.
+ Identifique de forma exclusiva a la persona o equipo responsable de la especificación de una actividad. Son responsables de verificar que un miembro del equipo con la formación adecuada y con los permisos, el acceso y las herramientas correctas pueda hacerla con éxito. Si hay problemas para llevar a cabo la actividad, los miembros del equipo que la llevan a cabo son responsables de proporcionar la información detallada necesaria para mejorar la actividad.
+ Refleje la propiedad en los metadatos del artefacto de la actividad a través de servicios como AWS Systems Manager, documentos y AWS Lambda. Capture la propiedad de los recursos mediante etiquetas o grupos de recursos y especifique la propiedad y la información de contacto. Utilice AWS Organizations para crear políticas de etiquetas y asegurarse de que se registra la información de contacto y de propiedad.
+ Con el tiempo, estos procedimientos deberían evolucionar para que puedan ejecutarse como código, lo que reduce la necesidad de intervención humana.
+ Por ejemplo, considere la posibilidad de usar funciones de AWS Lambda, plantillas de CloudFormation o documentos de automatización de AWS Systems Manager.
+ Lleve a cabo el control de versiones en los repositorios apropiados.
+ Incluya un etiquetado de recursos adecuado para que los propietarios y la documentación puedan identificarse fácilmente.
**Ejemplo de cliente**
AnyCompany Retail define la propiedad como el equipo o individuo que posee los procesos de una aplicación o grupos de aplicaciones (que comparten prácticas y tecnologías arquitectónicas comunes). Inicialmente, los procesos y procedimientos se documentan como guías paso a paso en el sistema de administración de documentos y se pueden encontrar mediante etiquetas en la Cuenta de AWS que aloja la aplicación y en grupos específicos de recursos dentro de la cuenta. Usa AWS Organizations para administrar sus Cuentas de AWS. Con el tiempo, estos procesos se convierten en código y los recursos se definen con infraestructura como código (por ejemplo, plantillas de CloudFormation o AWS Cloud Development Kit (AWS CDK)). Los procesos operativos se convierten en documentos de automatización en funciones de AWS Systems Manager o AWS Lambda, que pueden iniciarse como tareas programadas, en respuesta a eventos como alarmas de AWS CloudWatch o eventos de AWS EventBridge, o iniciarse mediante solicitudes dentro de una plataforma de administración de servicios de TI (ITSM). Todos los procesos tienen etiquetas para identificar la propiedad. La documentación de la automatización y el proceso se mantiene en las páginas wiki generadas por el repositorio de código del proceso.
### Pasos para la implementación
1. Documente los procesos y procedimientos existentes.
1. Revíselos y manténgalos actualizados.
1. Identifique un propietario para cada proceso o procedimiento.
1. Colóquelos bajo control de versiones.
1. Siempre que sea posible, comparta procesos y procedimientos entre cargas de trabajo y entornos que compartan diseños arquitectónicos.
1. Establezca mecanismos para recibir comentarios y mejorar.
1. Defina políticas sobre la frecuencia con la que se deben revisar los procesos.
1. Defina los procesos de los revisores y aprobadores.
1. Implemente problemas o una cola de tickets para que se proporcionen comentarios y se haga un seguimiento de ellos.
1. Siempre que sea posible, los procesos y procedimientos deben contar con la aprobación previa y la clasificación de riesgos de una junta de aprobación de cambios (CAB).
1. Verifique que los procesos y procedimientos sean accesibles y fáciles de encontrar para quienes tienen que ejecutarlos.
1. Utilice etiquetas para indicar dónde se puede acceder a los procesos y procedimientos de la carga de trabajo.
1. Utilice mensajes de error y eventos significativos para indicar los procesos o procedimientos adecuados para abordar un problema.
1. Use wikis y la administración de documentos, y haga que los procesos y procedimientos se puedan buscar de manera uniforme en toda la organización.
1. Utilice [Amazon Q Business](https://aws.amazon.com/q/business/), un asistente conversacional que utiliza IA generativa para mejorar la productividad de la fuerza laboral, responder preguntas y completar tareas en función de la información de los sistemas empresariales.
1. Conecte Amazon Q Business al origen de datos de su empresa. Amazon Q Business ofrece conectores prediseñados para más de 40 orígenes de datos compatibles, incluidos Amazon S3, Microsoft SharePoint, Salesforce y Atlassian Confluence. Para obtener más información, consulte [Conectores de Amazon Q](https://aws.amazon.com/q/business/connectors/).
1. Automatice cuando sea necesario.
1. Las automatizaciones deben desarrollarse cuando los servicios y las tecnologías proporcionan una API.
1. Imparta formaciones adecuadas sobre los procesos. Desarrolle casos de usuario y los requisitos para automatizar esos procesos.
1. Mida la utilización de los procesos y procedimientos correctamente, y cree problemas o tickets para respaldar la mejora iterativa.
**Nivel de esfuerzo para el plan de implementación:** medio
## Recursos
**Prácticas recomendadas relacionadas:**
+ [OPS02-BP01 Recursos con propietarios identificados](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_resource_owners.html)
+ [OPS02-BP04 Mecanismos existentes para administrar las responsabilidades y la propiedad](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_responsibilities_ownership.html)
+ [OPS11-BP04 Administración de conocimientos](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**Documentos relacionados:**
+ [AWS Documento técnico de : Introducción a DevOps en AWS](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)
+ [Documento técnico de AWS: Prácticas recomendadas para el etiquetado de los recursos de AWS](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [Documento técnico de AWS: Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
+ [Nube de AWS Operations and Migrations Blog - Using Amazon Q Business to streamline your operations ](https://aws.amazon.com/blogs/mt/streamline-operations-using-amazon-q-for-business/)
+ [Nube de AWS Operations & Migrations Blog - Build a Cloud Automation Practice for Operational Excellence: Best Practices from AWS Managed Services](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/)
+ [Nube de AWS Operations & Migrations Blog - Implementing automated and centralized tagging controls with AWS Config and AWS Organizations](https://aws.amazon.com/blogs/mt/implementing-automated-and-centralized-tagging-controls-with-aws-config-and-aws-organizations/)
+ [AWS Security Blog - Extend your pre-commit hooks with AWS CloudFormation Guard](https://aws.amazon.com/blogs/security/extend-your-pre-commit-hooks-with-aws-cloudformation-guard/)
+ [AWS DevOps Blog - Integrating AWS CloudFormation Guard into CI/CD pipelines](https://aws.amazon.com/blogs/devops/integrating-aws-cloudformation-guard/)
**Talleres relacionados:**
+ [AWS Well-Architected Operational Excellence Workshop](https://catalog.workshops.aws/well-architected-operational-excellence/en-US/)
+ [AWS Workshop: Tagging](https://catalog.workshops.aws/tagging/)
**Videos relacionados:**
+ [How to automate IT Operations on AWS](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [AWS re:Invent 2020 - Automate anything with AWS Systems Manager](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [AWS re:Inforce 2022 - Automating patch management and compliance using AWS (NIS306)](https://www.youtube.com/watch?v=gL3baXQJvc0)
+ [Soportes You - Diving Deep into AWS Systems Manager](https://www.youtube.com/watch?v=xHNLNTa2xGU)
**Servicios relacionados:**
+ [AWS Systems Manager - Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Service Management Connector](https://aws.amazon.com/service-management-connector/)
# OPS02-BP03 Actividades operativas con propietarios identificados responsables de su rendimiento
Averigüe quién tiene la responsabilidad de efectuar actividades específicas en las cargas de trabajo definidas y por qué existe esa responsabilidad. Conocer quién tiene la responsabilidad de efectuar las actividades sirve para saber quién llevará a cabo la actividad, validará el resultado y proporcionará información al propietario de la actividad.
**Resultado deseado:**
La organización define claramente las responsabilidades para llevar a cabo actividades específicas en cargas de trabajo definidas y responder a los eventos que genera la carga de trabajo. La organización documenta la propiedad y los procesos que se llevan a cabo y hace que esta información sea fácil de encontrar. Revisa y actualiza las responsabilidades cuando se producen cambios organizativos, y los equipos hacen un seguimiento y miden el rendimiento de las actividades de identificación de defectos e ineficiencias. Implementa mecanismos de obtener comentarios para hacer un seguimiento de los defectos y las mejoras y apoya la mejora iterativa.
**Patrones comunes de uso no recomendados:**
+ No documenta las responsabilidades.
+ Existen scripts fragmentados en estaciones de trabajo de operadores aisladas. Solo unas pocas personas saben cómo usarlos o se refieren a ellos de manera informal como *conocimiento de equipo*.
+ Hay que actualizar un proceso heredado, pero nadie sabe quién es el propietario del proceso y el autor original ya no forma parte de la organización.
+ Los procesos y los scripts no se pueden encontrar y no están disponibles cuando son necesarios (por ejemplo, en respuesta a un incidente).
**Beneficios de establecer esta práctica recomendada:**
+ Sabe quién es responsable de llevar a cabo una actividad, a quién debe notificar cuando sea necesario tomar una medida y quién toma la medida, valida el resultado y proporciona comentarios al propietario de la actividad.
+ Los procesos y procedimientos impulsan sus esfuerzos para gestionar sus cargas de trabajo.
+ Los nuevos miembros del equipo se hacen eficaces más rápidamente.
+ Reduce el tiempo necesario para mitigar los incidentes.
+ Los diferentes equipos utilizan los mismos procesos y procedimientos para llevar a cabo las tareas de manera uniforme.
+ Los equipos pueden escalar sus procesos con procesos repetibles.
+ Los procesos y procedimientos estandarizados ayudan a mitigar la repercusión de transferir las responsabilidades de las cargas de trabajo entre los equipos.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
Para empezar a definir las responsabilidades, comience por la documentación existente, como las matrices de responsabilidades, los procesos y procedimientos, los roles y responsabilidades, y las herramientas y la automatización. Revise y organice debates sobre las responsabilidades de los procesos documentados. Lleve a cabo una revisión con los equipos para identificar desajustes entre las responsabilidades de los documentos y los procesos. Analice los servicios que se ofrecen con los clientes internos de ese equipo para identificar las diferencias de expectativas entre los equipos.
Analice y aborde las discrepancias. Identifique oportunidades de mejora y busque las actividades que se solicitan con frecuencia y requieren muchos recursos, que suelen ser firmes candidatas a una mejora. Examine las prácticas recomendadas, los patrones y la orientación prescriptiva para simplificar y estandarizar las mejoras. Registre las oportunidades de mejora y haga un seguimiento de las mejoras hasta el final.
Con el tiempo, estos procedimientos deberían evolucionar para ejecutarse como código, lo que reduce la necesidad de intervención humana. Por ejemplo, los procedimientos se pueden iniciar como funciones de AWS Lambda, plantillas de CloudFormation o documentos de Automatización de AWS Systems Manager. Verifique que estos procedimientos estén controlados por versiones en los repositorios apropiados e incluyan el etiquetado de recursos adecuado para que los equipos puedan identificar fácilmente a los propietarios y la documentación. Documente la responsabilidad de llevar a cabo las actividades y, a continuación, supervise las automatizaciones para que se inicien y funcionen correctamente, así como la obtención de los resultados deseados.
**Ejemplo de cliente**
AnyCompany Retail define la propiedad como el equipo o individuo que posee los procesos de una aplicación o grupos de aplicaciones que comparten prácticas y tecnologías arquitectónicas comunes. Inicialmente, la empresa documenta los procesos y procedimientos como guías paso a paso en el sistema de administración documental. Hacen que los procedimientos sean fáciles de encontrar mediante etiquetas en la Cuenta de AWS que aloja la aplicación y en grupos específicos de recursos de la cuenta, y utilizan AWS Organizations para administrar sus Cuentas de AWS. Con el tiempo, AnyCompany Retail convierte estos procesos en código y define los recursos con la infraestructura como código (a través de servicios como plantillas de CloudFormation o AWS Cloud Development Kit (AWS CDK)). Los procesos operativos se convierten en documentos de automatización en funciones de AWS Systems Manager o AWS Lambda, que pueden iniciarse como tareas programadas, en respuesta a eventos como alarmas de Amazon CloudWatch o eventos de Amazon EventBridge, o mediante solicitudes dentro de una plataforma de administración de servicios de TI (ITSM). Todos los procesos tienen etiquetas para identificar a quién pertenecen. Los equipos administran la documentación para la automatización y el proceso dentro de las páginas wiki que genera el repositorio de código para el proceso.
### Pasos para la implementación
1. Documente los procesos y procedimientos existentes.
1. Revise y verifique que estén actualizados.
1. Verifique que cada proceso o procedimiento tenga un propietario.
1. Ponga los procedimientos bajo un control de versiones.
1. Siempre que sea posible, comparta procesos y procedimientos entre cargas de trabajo y entornos que compartan diseños arquitectónicos.
1. Establezca mecanismos para recibir comentarios y mejorar.
1. Defina políticas sobre la frecuencia con la que se deben revisar los procesos.
1. Defina los procesos de los revisores y aprobadores.
1. Implemente problemas o una cola de tickets para proporcionar comentarios y hacer un seguimiento de ellos.
1. Siempre que sea posible, proporcione una aprobación previa y una clasificación de riesgos de los procesos y procedimientos que ha obtenido de una junta de aprobación de cambios (CAB).
1. Haga que los procesos y procedimientos sean accesibles y fáciles de encontrar para los usuarios que necesitan ejecutarlos.
1. Utilice etiquetas para indicar dónde se puede acceder a los procesos y procedimientos de la carga de trabajo.
1. Utilice mensajes de error y eventos fáciles de entender para indicar los procesos o procedimientos adecuados para abordar el problema.
1. Use wikis o la administración de documentos para que los procesos y procedimientos se puedan buscar de manera uniforme en toda la organización.
1. Automatice cuando sea apropiado.
1. Cuando los servicios y las tecnologías tengan una API, desarrolle automatizaciones.
1. Verifique que los procesos se entiendan bien y desarrolle los casos de usuario y los requisitos para automatizar esos procesos.
1. Determine si los procesos y procedimientos se utilizan de forma satisfactoria y haga un seguimiento de los problemas para facilitar una mejora iterativa.
**Nivel de esfuerzo para el plan de implementación:** medio
## Recursos
**Prácticas recomendadas relacionadas:**
+ [OPS02-BP01 Recursos con propietarios identificados](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_resource_owners.html)
+ [OPS02-BP02 Procesos y procedimientos con propietarios identificados](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_resource_owners.html)
+ [OPS02-BP04 Mecanismos existentes para administrar las responsabilidades y la propiedad](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_responsibilities_ownership.html)
+ [OPS02-BP05 Mecanismos para solicitar adiciones, cambios y excepciones](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_find_owner.html)
+ [OPS11-BP04 Administración de conocimientos](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**Documentos relacionados:**
+ [Documento técnico de AWS: Introducción a DevOps en AWS](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)
+ [Documento técnico de AWS: Best Practices for Tagging AWS Resources](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [Documento técnico de AWS: Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
+ [Nube de AWS Operations & Migrations Blog: Build a Cloud Automation Practice for Operational Excellence: Best Practices from AWS Managed Services](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/)
+ [AWS Workshop: Tagging](https://catalog.workshops.aws/tagging/)
+ [AWS Service Management Connector](https://aws.amazon.com/service-management-connector/)
**Videos relacionados:**
+ [AWS Knowledge Center Live \$1 Tagging AWS Resources](https://www.youtube.com/watch?v=MX9DaAQS15I)
+ [AWS re:Invent 2020 \$1 Automate anything with AWS Systems Manager](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [AWS re:Inforce 2022 \$1 Automating patch management and compliance using AWS (NIS306)](https://www.youtube.com/watch?v=gL3baXQJvc0)
+ [Soportes You \$1 Diving Deep into AWS Systems Manager](https://www.youtube.com/watch?v=xHNLNTa2xGU)
# OPS02-BP04 Mecanismos existentes para administrar las responsabilidades y la propiedad
Conozca las responsabilidades de su rol y cómo contribuye a los resultados empresariales, ya que este conocimiento determina la prioridad de sus tareas y por qué su rol es importante. Esto ayuda a los miembros del equipo a reconocer las necesidades y responder de la forma adecuada. Cuando los miembros del equipo conocen su rol, pueden establecer la propiedad, identificar oportunidades de mejora y saber cómo influir o hacer los cambios apropiados.
En ocasiones, es posible que una responsabilidad no tenga un propietario claro. En estas situaciones, diseñe un mecanismo para resolver esta carencia. Cree una ruta de derivación bien definida a alguien con autoridad para asignar la propiedad o planificar la forma de satisfacer la necesidad.
**Resultado deseado:** los equipos de su organización tienen responsabilidades claramente definidas que incluyen su relación con los recursos, las acciones que se deben llevar a cabo, los procesos y los procedimientos. Estas responsabilidades se corresponden con las responsabilidades y objetivos del equipo, así como con las responsabilidades de otros equipos. Debe documentar las rutas de derivación de una manera uniforme y fácil de encontrar y debe introducir estas decisiones en artefactos de documentación, como matrices de responsabilidad, definiciones de equipos o páginas wiki.
**Patrones comunes de uso no recomendados:**
+ Las responsabilidades del equipo son ambiguas o están mal definidas.
+ Los roles del equipo no se corresponden con las responsabilidades.
+ El equipo no ajusta sus metas y objetivos a sus responsabilidades, lo que dificulta la medición del éxito.
+ Las responsabilidades de los miembros del equipo no se corresponden con las del equipo ni con la organización en general.
+ Su equipo no mantiene actualizadas las responsabilidades, lo que las hace incoherentes con las tareas que lleva a cabo.
+ Las rutas de derivación para determinar las responsabilidades no están definidas o no son claras.
+ Las rutas de derivación no tienen un único propietario que garantice una respuesta oportuna.
+ Los roles, las responsabilidades y las rutas de derivación no son fáciles de encontrar y no están disponibles cuando son necesarios (por ejemplo, en respuesta a un incidente).
**Beneficios de establecer esta práctica recomendada:**
+ Cuando sepa quién tiene la responsabilidad o la propiedad, podrá contactar con el equipo o el miembro del equipo adecuado para presentar una solicitud o la transición de una tarea.
+ Para reducir el riesgo de inacción y de que existan necesidades no atendidas, ha identificado a una persona que tiene la autoridad para asignar la responsabilidad o la propiedad.
+ Cuando define claramente el alcance de una responsabilidad, los miembros de su equipo ganan autonomía y propiedad.
+ Sus responsabilidades determinan las decisiones que toma, las acciones que emprende y las actividades que transfiere a sus propietarios adecuados.
+ Es fácil identificar las responsabilidades abandonadas porque tiene una idea clara de lo que queda fuera de la responsabilidad de su equipo, lo que le ayuda a derivar los problemas para aclararlos.
+ Los equipos evitan la confusión y la tensión, y pueden administrar más adecuadamente sus cargas de trabajo y sus recursos.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
Identifique los roles y responsabilidades de los miembros del equipo y asegúrese de que conozcan las expectativas de su rol. Haga que esta información sea fácil de encontrar para que los miembros de su organización puedan identificar con quién deben contactar, ya sea un equipo o una persona. Cuando las organizaciones tratan de aprovechar las oportunidades de migrar y modernizar en AWS, los roles y responsabilidades también podrían cambiar. Mantenga a sus equipos y a sus miembros al corriente de sus responsabilidades y proporcióneles la formación adecuada para llevar a cabo sus tareas durante este cambio.
Determine el rol o el equipo que debe recibir las derivaciones para identificar la responsabilidad y la propiedad. Este equipo puede interactuar con varias partes interesadas para tomar una decisión. Sin embargo, deben ser propietarios de la administración del proceso de toma de decisiones.
Proporcione mecanismos accesibles para que los miembros de su organización descubran e identifiquen la propiedad y la responsabilidad. Estos mecanismos les enseñan con quién contactar para necesidades específicas.
**Ejemplo de cliente**
AnyCompany Retail completó recientemente una migración de cargas de trabajo desde un entorno en las instalaciones a su zona de aterrizaje en AWS con un enfoque de migración mediante lift-and-shift. Revisó las operaciones para determinar cómo llevar a cabo las tareas operativas comunes y verificó que su matriz de responsabilidades existente refleja las operaciones en el nuevo entorno. Cuando migró de un entorno en las instalaciones a AWS, redujo las responsabilidades de los equipos de infraestructura relacionadas con el hardware y la infraestructura física. Esta medida también dio lugar a nuevas oportunidades para hacer evolucionar el modelo operativo de sus cargas de trabajo.
Aunque identificó, abordó y documentó la mayoría de las responsabilidades, también definió rutas de derivación para cualquier responsabilidad que se hubiera pasado por alto o que pudiera tener que cambiar a medida que evolucionaran las prácticas operativas. Para explorar nuevas oportunidades para estandarizar y mejorar la eficiencia de sus cargas de trabajo, proporcione acceso a herramientas operativas como AWS Systems Manager y herramientas de seguridad como AWS Security Hub CSPM y Amazon GuardDuty. AnyCompany Retail revisa las responsabilidades y la estrategia en función de las mejoras que quiere abordar en primer lugar. A medida que la empresa adopta nuevas formas de trabajo y patrones tecnológicos, actualiza su matriz de responsabilidad de la forma correspondiente.
### Pasos para la implementación
1. Comience con la documentación existente. Estos son algunos documentos iniciales típicos:
1. Matrices de responsabilidad o de responsable, encargado, consultado e informado (RACI)
1. Definiciones de equipo o páginas wiki
1. Definiciones y ofertas de servicios
1. Descripciones de roles o puestos
1. Revise y organice debates sobre las responsabilidades documentadas:
1. Lleve a cabo una revisión con los equipos para identificar desajustes entre las responsabilidades documentadas y las responsabilidades que el equipo suele desempeñar.
1. Analice los posibles servicios que ofrecen los clientes internos para identificar las diferencias de expectativas entre los equipos.
1. Analice y aborde las discrepancias.
1. Identifique oportunidades de mejora.
1. Identifique las solicitudes más frecuentes y que requieren más recursos, que suelen ser firmes candidatas a una mejora.
1. Busque las prácticas recomendadas, conozca los patrones, siga las recomendaciones y simplifique y estandarice las mejoras.
1. Registre las oportunidades de mejora y haga un seguimiento de ellas hasta el final.
1. Si un equipo aún no tiene la responsabilidad de administrar y hacer un seguimiento de la asignación de responsabilidades, identifique a alguien del equipo para que asuma esta responsabilidad.
1. Defina un proceso para que los equipos soliciten una aclaración de la responsabilidad.
1. Revise el proceso y verifique que sea claro y fácil de usar.
1. Asegúrese de que alguien sea el propietario de las derivaciones y haga un seguimiento de ellas hasta el final.
1. Establezca métricas operativas para medir la eficacia.
1. Cree mecanismos para obtener comentarios para verificar que los equipos puedan llamar la atención sobre las oportunidades de mejora.
1. Implemente un mecanismo de revisión periódica.
1. Lleve a cabo la documentación en una ubicación accesible y reconocible.
1. Las wikis o el portal de documentación son opciones comunes.
**Nivel de esfuerzo para el plan de implementación:** medio
## Recursos
**Prácticas recomendadas relacionadas:**
+ [OPS01-BP06 Evaluación de las compensaciones](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_tradeoffs.html)
+ [OPS03-BP02 Preparación de los miembros del equipo para actuar cuando los resultados están en riesgo](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_emp_take_action.html)
+ [OPS03-BP03 Fomento de la derivación](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_enc_escalation.html)
+ [OPS03-BP07 Recursos adecuados para los equipos](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_res_appro.html)
+ [OPS09-BP01 Medición de los objetivos operativos y los KPI con métricas](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_measure_ops_goals_kpis.html)
+ [OPS09-BP03 Revisión de las métricas de las operaciones y priorización de las mejoras](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_review_ops_metrics_prioritize_improvement.html)
+ [OPS11-BP01 Implementación de un proceso de mejora continua](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_process_cont_imp.html)
**Documentos relacionados:**
+ [Documento técnico de AWS: Introducción a DevOps en AWS](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)
+ [Documento técnico de AWS: Nube de AWS Cloud Adoption Framework: Operations Perspective](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-operations-perspective/aws-caf-operations-perspective.html)
+ [Excelencia operativa del Marco de AWS Well-Architected: Representaciones 2 por 2 del modelo operativo](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model-2-by-2-representations.html)
+ [Guía prescriptiva de AWS: Building your Cloud Operating Model](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-cloud-operating-model/welcome.html)
+ [Guía prescriptiva de AWS: Create a RACI or RASCI matrix for a cloud operating model](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/create-a-raci-or-rasci-matrix-for-a-cloud-operating-model.html)
+ [Nube de AWS Operations & Migrations Blog - Delivering Business Value with Cloud Platform Teams](https://aws.amazon.com/blogs/mt/delivering-business-value-with-cloud-platform-teams/)
+ [Nube de AWS Operations & Migrations Blog - Why a Cloud Operating Model?](https://aws.amazon.com/blogs/mt/why-a-cloud-operating-model/)
+ [AWS DevOps Blog - How organizations are modernizing for cloud operations](https://aws.amazon.com/blogs/devops/how-organizations-are-modernizing-for-cloud-operations/)
**Videos relacionados:**
+ [AWS Summit Online - Cloud Operating Models for Accelerated Transformation](https://www.youtube.com/watch?v=ksJ5_UdYIag)
+ [AWS re:Invent 2023 - Future-proofing cloud security: A new operating model](https://www.youtube.com/watch?v=GFcKCz1VO2I)
# OPS02-BP05 Mecanismos para solicitar adiciones, cambios y excepciones
Puede presentar solicitudes a los propietarios de los procesos, procedimientos y recursos. Las solicitudes incluyen adiciones, cambios y excepciones. Estas solicitudes pasan por un proceso de administración de cambios. Tome decisiones fundamentadas para aprobar las solicitudes cuando sean viables y se determine que son adecuadas tras una evaluación de los beneficios y los riesgos.
**Resultado deseado:**
+ Puede presentar solicitudes para cambiar procesos, procedimientos y recursos en función de la propiedad asignada.
+ Los cambios se hacen de forma deliberada y se tienen en cuenta los beneficios y los riesgos.
**Patrones comunes de uso no recomendados:**
+ Debe actualizar la forma de implementar su aplicación, pero no hay forma de solicitar un cambio en el proceso de implementación al equipo de operaciones.
+ El plan de recuperación de desastres debe actualizarse, pero no hay ningún propietario identificado al que solicitar cambios.
**Beneficios de establecer esta práctica recomendada:**
+ Los procesos, los procedimientos y los recursos pueden evolucionar a medida que cambian los requisitos.
+ Los propietarios pueden tomar decisiones fundamentadas cuando hacen cambios.
+ Los cambios se hacen de forma deliberada.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
## Guía para la implementación
Para implementar esta práctica recomendada, debe poder solicitar cambios en los procesos, los procedimientos y los recursos. El proceso de administración de los cambios puede ser ligero. Documente el proceso de administración de cambios.
**Ejemplo de cliente**
AnyCompany Retail utiliza una matriz de asignación de responsabilidades (RACI) para identificar a quién corresponden los cambios en los procesos, los procedimientos y los recursos. Dispone de un proceso de administración de cambios documentado, ligero y fácil de seguir. Con la matriz RACI y el proceso, cualquiera puede enviar solicitudes de cambio.
**Pasos para la implementación**
1. Identifique los procesos, los procedimientos y los recursos de su carga de trabajo y los responsables de cada uno de ellos. Documéntelos en su sistema de administración de conocimientos.
1. Si no ha implementado [OPS02-BP01 Recursos con propietarios identificados](ops_ops_model_def_resource_owners.md), [OPS02-BP02 Procesos y procedimientos con propietarios identificados](ops_ops_model_def_proc_owners.md) o [OPS02-BP03 Actividades operativas con propietarios identificados responsables de su rendimiento](ops_ops_model_def_activity_owners.md), empiece con ellos en primer lugar.
1. Colabore con las partes interesadas de su organización para desarrollar un proceso de administración de cambios. El proceso debe abarcar las incorporaciones, los cambios y las excepciones de recursos, procesos y procedimientos.
1. Puede utilizar el [Administrador de cambios de AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html) como plataforma de gestión de cambios para los recursos de carga de trabajo.
1. Documente el proceso de administración de cambios en su sistema de administración de conocimientos.
**Nivel de esfuerzo para el plan de implementación:** medio. El desarrollo de un proceso de administración de cambios requiere la coordinación con las múltiples partes interesadas de toda la organización.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [OPS02-BP01 Recursos con propietarios identificados](ops_ops_model_def_resource_owners.md): es necesario identificar a los propietarios de los recursos antes de crear un proceso de gestión de cambios.
+ [OPS02-BP02 Procesos y procedimientos con propietarios identificados](ops_ops_model_def_proc_owners.md): es necesario identificar a los propietarios de los procesos antes de crear un proceso de gestión de cambios.
+ [OPS02-BP03 Actividades operativas con propietarios identificados responsables de su rendimiento](ops_ops_model_def_activity_owners.md): es necesario identificar a los propietarios de las actividades operativas antes de crear un proceso de gestión de cambios.
**Documentos relacionados:**
+ [Guía prescriptiva de AWS: Foundation playbook for AWS large migrations: Creating RACI matrices ](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.html#raci)
+ [ Documento técnico Change Management in the Cloud ](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)
**Servicios relacionados:**
+ [AWS Systems Manager Change Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html)
# OPS02-BP06 Responsabilidades predefinidas o negociadas entre equipos
Posibilite que se definan o negocien acuerdos entre equipos que describan cómo trabajan y se apoyan mutuamente (por ejemplo, tiempos de respuesta, objetivos de nivel de servicio o acuerdos de nivel de servicio). Los canales de comunicación entre equipos están documentados. Comprender el impacto del trabajo de los equipos en los resultados de la empresa y los resultados de otros equipos y organizaciones fundamenta la priorización de sus tareas y contribuye a que respondan adecuadamente.
Cuando la responsabilidad y la propiedad no están definidas o se desconocen, se corre el riesgo de que no se aborden las actividades necesarias a tiempo y de que se hagan esfuerzos repetidos y potencialmente conflictivos para satisfacer esas necesidades.
**Resultado deseado:**
+ Se acuerdan y documentan los acuerdos de trabajo o asistencia entre equipos.
+ Los equipos que se prestan asistencia o colaboran entre sí tienen definidos los canales de comunicación y las expectativas de respuesta.
**Patrones comunes de uso no recomendados:**
+ Se produce un problema en producción y dos equipos distintos empiezan a solucionar los problemas independientemente el uno del otro. Sus esfuerzos aislados prolongan la interrupción.
+ El equipo de operaciones necesita ayuda del equipo de desarrollo, pero no hay un tiempo de respuesta acordado. La solicitud está atascada en la lista de tareas pendientes.
**Beneficios de establecer esta práctica recomendada:**
+ Los equipos saben cómo interactuar y prestarse asistencia mutua.
+ Se conocen las expectativas de capacidad de respuesta.
+ Los canales de comunicación están claramente definidos.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** bajo
## Guía para la implementación
La implementación de esta práctica recomendada significa que no existe ninguna ambigüedad sobre cómo colaboran los equipos. Los acuerdos formales codifican la forma en que los equipos trabajan juntos o se prestan asistencia mutua. Los canales de comunicación entre equipos están documentados.
**Ejemplo de cliente**
El equipo de SRE de AnyCompany Retail tiene un acuerdo de nivel de servicio con su equipo de desarrollo. Cada vez que el equipo de desarrollo presenta una solicitud en su sistema de tickets, puede esperar una respuesta en quince minutos. Si se produce una interrupción en el sitio, el equipo de SRE toma la iniciativa en la investigación con la ayuda del equipo de desarrollo.
**Pasos para la implementación**
1. En colaboración con las partes interesadas de toda su organización, desarrolle acuerdos entre los equipos basados en procesos y procedimientos.
1. Si dos equipos comparten un proceso o un procedimiento, elabore un manual de procedimientos sobre cómo colaborarán.
1. Si existen dependencias entre los equipos, acuerde un SLA de respuesta para las solicitudes.
1. Documente las responsabilidades en su sistema de administración de conocimientos.
**Nivel de esfuerzo para el plan de implementación:** medio. Si no existen acuerdos entre los equipos, puede resultar difícil llegar a un acuerdo con las partes interesadas de toda la organización.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [OPS02-BP02 Procesos y procedimientos con propietarios identificados](ops_ops_model_def_proc_owners.md): se debe identificar la propiedad del proceso antes de establecer acuerdos entre los equipos.
+ [OPS02-BP03 Actividades operativas con propietarios identificados responsables de su rendimiento](ops_ops_model_def_activity_owners.md): se debe identificar la propiedad de las actividades operativas antes de establecer acuerdos entre los equipos.
**Documentos relacionados:**
+ [AWS Executive Insights: Estimulación de la innovación y la velocidad con los equipos de dos pizzas de Amazon ](https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/)
+ [ Introducción a DevOps en AWS: Equipos de dos pizzas ](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html)