Motor de habilitación de la nube: una guía práctica

Motor de habilitación de la nube: una guía práctica

Guía prescriptiva para establecer un motor de habilitación de la nube

Agosto 2020

Avisos Los clientes son responsables de realizar su propia evaluación independiente de la información contenida en este documento. Este documento: (a) es solo con fines informativos, (b) representa las ofertas de servicios y prácticas actuales de AWS, que están sujetas a cambios sin previo aviso, y (c) no crea compromisos ni garantías de AWS y sus filiales, proveedores o licenciantes. Los productos o servicios de AWS se proporcionan «tal cual» sin garantías, representaciones o condiciones de ningún tipo, ya sean explícitas o implícitas. Las responsabilidades y responsabilidades de AWS con sus clientes están controladas por acuerdos de AWS, y este documento no forma parte de ningún acuerdo entre AWS y sus clientes ni modifica.

© 2020 Amazon Web Services, Inc. o sus filiales. Todos los derechos reservados.

Contenido Resumen ............................................................................................................................ 6

Introducción ........................................................................................................................ 7

Construyendo el equipo .................................................................................................. 9

Formación y Coaching .................................................................................................. 10

Proyectos piloto ............................................................................................................. 10

Arquitectura para la nube .............................................................................................. 10

Operación en la nube .................................................................................................... 11

Mejora continua ............................................................................................................. 11

Comenzando: Ofertas de servicio .................................................................................... 11

Servicios básicos .......................................................................................................... 11

Servicios Adicionales .................................................................................................... 15

Consideraciones ............................................................................................................... 16

Patrones para el éxito ...................................................................................................... 16

Anti-patrones — Acciones a evitar ................................................................................... 20

Conclusión ........................................................................................................................ 24

Apéndice 1: Evolución del CEE de la empresa ................................................................ 25

Apéndice 2: La historia de Amazon.com .......................................................................... 25

Apéndice 3: Equipos de dos pizzas y productivización .................................................... 28

Apéndice 4: Modelo operativo de nube ............................................................................ 29

Apéndice 5: Migración ...................................................................................................... 30

AWS CSMatrix - Herramienta de evaluación de capacidades ...................................... 30

Evaluación de la cartera de migración (MPA, Migration Portfolio Assessment, por sus siglas en inglés) para TCO y ROI ................................................................................. 30

Aceleradores basados en la experiencia (EBA, experienced based accelerators) ....... 30

Apéndice 6: Orientación prescriptiva ................................................................................ 31

Apéndice 7: KPI de operaciones ...................................................................................... 31

Colaboradores .................................................................................................................. 35

Revisiones de documentos .............................................................................................. 35

Amazon Web Services Motor de habilitación de la nube: una guía práctica

6

Resumen Este documento es un manual práctico para definir, establecer e implementar un Motor de Habilitación de la Nube (en adelante CEE, de sus siglas en inglés “Cloud Enablement Engine”). Recoge y resume las lecciones aprendidas y los anti-patrones recogidos en los emprendimientos de habilitación de la nube exitosos en Amazon y otras grandes empresas. Se ha escrito mucho sobre la necesidad de establecer un CEE, los beneficios de pasar a una mentalidad de productivización y el valor en las empresas de las tribus, gremios (guilds) y equipos de dos pizzas. Sin embargo, las organizaciones más grandes todavía tienen dificultadas con un plan de CEE de 30 a 60 a 90 días , y los componentes esenciales del CEE durante sus primeros seis meses de existencia.

La guía prescriptiva de este documento proporciona asesoramiento pragmático y táctico para establecer un Motor de Habilitación de la Nube (CEE), también conocido como Centro de Excelencia en la Nube (CCoE, Cloud Center of Excellence) o Equipo de Habilitación de la Nube. Este documento sirve como guía paso a paso para las actividades de configuración inicial y las diez mejores prácticas que se han extrapolado al trabajar en un gran número de clientes.


7

Introducción Un enfoque clave de Cloud Enablement Engine (CEE) es transformar la organización de tecnología de la información (TI) de un modelo operativo local a un modelo operativo en la nube (COM, Cloud Operating Model). La transformación a COM y el camino de CEE están muy correlacionadas e interconectadas. Durante la fase incipiente de la CEE, la atención de la CEE se centrará en los componentes de infraestructura de una COM. Esto incluye las operaciones, la seguridad y el control, la arquitectura y el gobierno de la plataforma y las funciones de aprovisionamiento de la infraestructura y administración de la configuración. Amazon Web Services (AWS) entiende que los modelos operativos empresariales (in situ) se basan en la biblioteca de infraestructura de tecnología de la información (ITIL). La transformación de la nube de un modelo operativo local a un COM incluye el mapeo de ITIL a una nube, ágil y capacidades y procesos basados en DevOps. ITIL 4.0 adhiere a DevOps, nube y agile.

En primer lugar, la CEE debe centrarse en las necesidades de las empresas (líneas de negocio o, LOB de sus siglas en inglés, y propietarios de productos) y de los clientes internos de TI (equipos de desarrollo, operaciones, seguridad, bases de datos e infraestructura). Establecer un CEE no es instantáneo o una sola operación, es un proceso iterativo. El cambio organizacional y cultural requiere compromiso de los líderes y tiempo. La mayoría de los clientes comienzan con una Landing Zone, un entorno de laboratorio y de tres a cinco aplicaciones de prueba re-hosteadas, y escalan horizontalmente a medida que se vuelven más cómodos. Los primeros resultados de CEE, en forma de adopción de la nube de producción, se pueden lograr en un plazo de tres meses. Para aprovechar todos los beneficios de la nube en términos de operaciones, administración, aprovisionamiento y arquitecturas nativas de la nube, el proceso puede tardar un año o más.


8

Perspectiva de AWS CEE sobre la implementación

Philip Potloff, jefe de estrategia empresarial de AWS, describe un CCoE (utiliza el nombre tradicional de un CEE) en esta entrada de blog. «El CCoE es un equipo multidisciplinario que se reúne para implementar el gobierno, las mejores prácticas, la formación y la arquitectura necesarias para la adopción de la nube de una manera que proporcione patrones repetibles para que la empresa completa los siga», afirma Philip. Este post de blog se centra en la creación de instancias y composición del equipo inicial, aconsejando que el equipo sea una combinación de miembros del equipo multifuncional que no han trabajado estrechamente juntos, y un grupo de jugadores de un equipo A que tienen un largo historial de estrecha colaboración y éxito.

La construcción de una CEE comienza con una persona, un sponsor de la Nube, un ejecutivo que rinde cuentas por el éxito CEE. Se asegurará de que los KPI de CEE y los objetivos estén directamente alineados con los objetivos de negocio de la empresa.

Como se indica en el apéndice 1, la CEE evoluciona con el tiempo para ser menos centralizada, y los servicios ofrecidos en la estructura descentralizada son asumidos por las líneas de negocio. En el apéndice 2, se detalla el cambio organizativo, de procesos, de herramientas y de arquitectura que Amazon.com emprendió durante su transformación a arquitecturas orientadas a servicios (SOA), microservicios, liberación de bases de datos relacionales monolíticas (Oracle), equipos de dos pizzas y el modelo operativo de producto.

Se requieren cinco actividades para comenzar a construir un CEE:

• Construir el equipo

• Formación y Coaching

• Proyectos piloto

• Arquitectura para la nube

• Operación en la nube

La Mejora Continua es una actividad adicional que debe tenerse en cuenta, y será primordial después de que la CEE haya estado funcionando durante un año o más.


9

Construyendo el equipo La primera actividad consiste en definir las funciones y responsabilidades e identificar a los miembros del equipo a través de un organigrama. Un aspecto de mapear la estructura del equipo y del personal implica mapear roles tradicionales a roles en la nube. Esto incluye la el mapeo de roles on-premises de arquitectura, infraestructura, operaciones, seguridad, alineación empresarial y de TI, administración de proyectos, datos y aplicaciones. Las habilidades y competencias necesarias para cubrir con éxito los puestos son fundamentales.

Es importante destacar los roles iniciales que son cruciales para el éxito de la instauración de la CEE. El miembro inicial del equipo debe conocer los servicios de AWS, las redes, la seguridad, las operaciones, el desarrollo de aplicaciones, las migraciones, las bases de datos y la infraestructura. Deben ser apasionados por la tecnología, pero también tener perspicacia del negocio, la capacidad de evangelizar internamente la tecnología y el valor de la CEE, y tener suficiente capital político interno para acceder directamente y comunicarse con los líders de las líneas de negocio (LOB). Las organizaciones típicamente limitan la CEE inicial a 3-5 personas. Esto se ajusta al enfoque del equipo de dos pizzas de Amazon y garantiza un equipo ágil que está capacitado para tomar decisiones rápidas.

Los primeros recursos incluyen:

1. Persona de infraestructura y operaciones (como un arquitecto de nube)

2. Especialista en seguridad y redes o migración (dependiendo del enfoque inicial de CEE)

3. Ingeniero de plataformas en la nube (como un experto en materia scripting)

4. El líder CEE, que es un miembro respetado de la organización de TI.

Parte de la creación del equipo implica identificar los servicios principales que se ofrecerán y establecer los objetivos, métricas y KPI del equipo. En la creación inicial del equipo, menos es más. Recomendamos mantener la lista menor a seis ofertas de servicios y capacidades ofrecidas en los primeros 2-6 meses.

Este documento no proporciona detalles sobre las funciones y responsabilidades de CEE, ni sobre la asignación de roles on-prem a la nube. Los clientes empresa están entusiasmados con obtener esta información, junto con las descripciones de puestos, de AWS. Para obtener información más detallada sobre este tema, comuníquese con el equipo local de asesoramientode servicios profesionales de AWS.


10

Formación y Coaching La segunda actividad es la formación y el coaching y debe realizarse antes de las actividades tres a cinco. La actividad de entrenamiento y coaching implica la construcción de un portal web en la nube (por ejemplo, wiki, sitio web, etc.), la identificación de brechas de formación (LNA — Learning Needs Analysis), la creación de un plan de formación, la formación interna y/o la identificación de socios, la implementación de la formación y la participación de las personas mediante talleres, hackathons, Immersion Days, lunch and learns, etc. La CEE no es responsable de impartir toda la formación. La CEE trabajará con el equipo interno de formación para crear las rutas de aprendizaje, identificar proveedores de formación de certificación, como Linux Academy, A Cloud Guru, etc., y ofrecer formación inicial y capacitar a los formadores en el equipo de formación corporativo.

Proyectos piloto La tercera actividad es Proyectos piloto y permite al equipo de CEE obtener experiencia práctica con AWS. El equipo experimentará con algunos proyectos piloto seleccionados utilizando un entorno de laboratorio. Esto le da al equipo el desarrollo más rápido de habilidades y el desarrollo de conocimientos internos. El equipo de CCE recibirá formación sobre AWS Well Architected y se familiarizará con las arquitecturas de referencia de AWS, los inicios rápidos, y las soluciones de AWS. El objetivo es la agilidad y documentar las lecciones aprendidas en una base de mejores prácticas.

Arquitectura para la nube La cuarta actividad es la arquitectura para la nube e implica definir la arquitectura de estado final de AWS para entornos de desarrollo, pruebas, pruebas de rendimiento, control de calidad y producción. Se establecen las políticas de identidad y control de acceso en la nube. Además, se definen la estructura de la cuenta de AWS y los roles de IAM. Los procesos de facturación y gestión financiera se configuran mediante el etiquetado y la facturación de AWS. Las directivas de gobierno se establecen para la solicitud de acceso, la seguridad y los límites de uso y servicio son configurados. AWS ofrece soluciones para muchos objetivos de esta actividad, como AWS Landing Zone y AWS Control Tower.


11

Operación en la nube La quinta actividad es Operando en la Nube y se centra en cómo una empresa debe operar en la nube utilizando el Modelo Operativo en la Nube (COM). Para obtener más información, consulte Creación de un modelo operativo en la nube.

Las capacidades de operación incluyen lo siguiente: infraestructura como código, repositorios de código y control de versiones, supervisión, alertas, notificaciones e informes, políticas de escalado, seguimiento financiero y auditoría, políticas de implementación de servicios y revisión de oportunidades para prácticas de DevOps. A menudo implica la creación de un documento y un proceso de Revisión de Preparación de Operaciones (ORR, Operation Readiness Review), centrado en infraestructura , para garantizar que las nuevas cargas de trabajo trasladadas a AWS estén listas para la producción. Puede encontrar más información sobre los modelos operativos en la nube en el Apéndice 4.

Mejora continua La sexta actividad es la mejora continua e incluye revisiones periódicas de proyectos y post mortems, mantenerse al día con las últimas tecnologías e innovaciones, automatizar todo (NoOps), seguimiento de costos, revisiones de KPI a través de un portal KPI, reuniones mensuales de revisión y capacitación continua. También implica utilizar Machine Learning (ML) para operaciones, aprovisionamiento, alertas y administración.

Comenzando: Ofertas de servicio La función principal del equipo de CEE es proporcionar una plataforma de AWS preparada para la empresa que sea fácilmente consumible por los usuarios finales. El equipo de nube es responsable del refuerzo general de la seguridad de la plataforma, que incluye la definición de roles y políticas estándar de AWS Identity and Access Management (IAM), la evaluación de la seguridad y la habilitación de los servicios de AWS mediante políticas de IAM, la federación de SSO/AD de plataforma, la definición de grupos de seguridad estándar (sistemas back-end requeridos), AMI de sistemas operativos estándares de la empresa, estrategia y administración de cuentas, facturación y optimización de costos, construccciones de VPC, herramientas CI/CD (Jenkins, Ansible, etc.), plataforma API e incorporación de aplicaciones.

Servicios básicos El CEE debería ofrecer los siguientes servicios básicos en los seis primeros meses siguientes a su creación:


12

1. FinOps: Este servicio ofrece rigurosos procesos de gestión financiera para la previsión de costos, el monitoreo, la generación de informes, la optimización y la asignación. Evalúa las soluciones arquitectónicas eficientes en costo tanto en la arquitectura como en la infraestructura y recomienda la solución más eficiente en costo. Optimiza continuamente los activos en la nube provisionados frente al consumo para maximizar la utilización. Proporciona informes y proyecciones transparentes a través de paneles de autoservicio a los clientes internos y a las partes interesadas para ayudarles a administrar su presupuesto de manera eficaz. Analiza las facturas en la nube y asigna costos a los clientes internos y las partes interesadas. Asegura que el costo de la nube esté optimizado para ofrecer el máximo valor al negocio al menor costo posible mediante la implementación de los controles financieros adecuados.

2. Gobierno de la nube: Este servicio se refiere a los procesos de toma de decisiones, criterios y políticas involucrados en la planificación, arquitectura, adquisición, implementación, operación y gestión de una capacidad de cómputo en la nube. El gobierno en la nube abarca un amplio conjunto de funciones que incluyen: establecimiento de objetivos de nivel de servicio, gobierno de AWS, incluida la estrategia de cuenta, políticas de seguridad, gestión de cuentas, facturación y controles de costos, establecimiento y medición de métricas y KPI, y cumplimiento de las cargas de trabajo con los estándares de la industria. El equipo CEE es responsable de actualizar e implementar políticas y prácticas para apoyar los modelos de gobierno necesarios y así permitir que las cargas de trabajo sean conformes con las operaciones empresariales. Por ejemplo, PCI-DSS, HIPPA y FedRAMP. La CEE auditará las cargas de trabajo desde una perspectiva técnica y de cumplimiento empresarial, e informará del estado actual a los ejecutivos.

3. Migraciones: este servicio permite al equipo de CEE crear la estrategia de migración de AWS, definir la metodología y desarrollar y compartir las prácticas recomendadas de migración. Esta estrategia incluye recomendaciones sobre herramientas de migración, decisiones sobre cuándo aplicar una de las 6-Rs (rehost, replace, rearchitect, re-platform, y re-engineer) a una aplicación. La estrategia incluirá una evaluación de la cartera, revisión de la arquitectura, revisión o estrategia de seguridad, planificación de la migración de aplicaciones, análisis de TCO, integración de aplicaciones, implementación y operaciones en curso. Los equipos utilizarán esta experiencia como base para las mejores prácticas y lecciones aprendidas centradas en Migración, Modernización y Consolidación de DC. El equipo de CEE debe familiarizarse con la


13

herramienta AWS Migration Portfolio Assessment (MPA), los aceleradores basados en experiencia (EBA, experience based accelerators) y la matriz de éxito del cliente (CSMatrix, customer success matrix, creada y mantenida por los equipos de cuentas de AWS). El EBA es un banco de talleres interactivos que acelera el cambio organizacional, la racionalización del portafolio y las migraciones de aplicaciones a la nube. AWS CSMatrix es un marco para evaluar el estado actual de las capacidades en la nube de una organización con respecto a estas seis perspectivas: negocio, personas y gobierno centradas en las capacidades empresariales; mientras que las perspectivas de plataforma, seguridad y operaciones se centran en las capacidades técnicas. Para obtener más información sobre AWS MPA y CSMatrix, consulte el Apéndice 5.


14

4. Configuración y optimización de la plataforma: este servicio proporciona orientación a la empresa sobre la dirección de la plataforma general, aprovisiona entornos AWS iniciales, crea AMI base (imagen dorada) , automatiza las implementaciones de infraestructura mediante scripting y optimiza la plataforma mediante la implementación de arquitecturas de referencia. El aprovisionamiento del entorno de AWS incluye la estructura inicial de la cuenta y la facturación, la seguridad, la identidad y la evaluación, el registro, la supervisión y la estructura de red que utilizan AWS Landing Zone y AWS Control Tower. Los procedimientos de aprovisionamiento ayudan a planificar, implementar y mantener una infraestructura técnica estable para dar soporte a los procesos empresariales de la organización. El equipo de CEE utilizará AWS Well-Architected Framework para implementar los últimos consejos sobre prácticas recomendadas de AWS y orientación paso a paso para corregir los gaps que surjan en la arquitectura utilizando datos. El equipo actualizará continuamente los stacks de arquitectura de referencia y la hoja de ruta en función de las prioridades empresariales. El objetivo del servicio de arquitectura de plataforma es construir las soluciones arquitectónicas más eficaces para patrones de arquitectura recurrentes y promover la reutilización con la ajustes cuandos se requieran.

5. Operaciones: Este servicio se ofrece para soporte, mantenimiento, monitoreo y gestión de incidentes de la plataforma en la nube. El CEE admite la integración de herramientas y activos de la empresa con herramientas y activos en la nube. Este servicio valida y orquesta un plan de continuidad de negocio (BCP, businsess continuity plan) y escenarios de recuperación ante desastres (DR) y trabaja con el equipo de ingeniería de plataformas en la nube para automatizar estos escenarios. El equipo es responsable de establecer cómo funcionará la estructura de soporte en la nube, incluido el trabajo con los equipos de soporte centralizados existentes para establecer el modelo de soporte. El equipo también ayuda a impulsar la automatización y cambiar los procesos existentes, como la automatización para actualizar los registros de cambios. El equipo también crea el soporte inicial para las nuevas aplicaciones que se incorporan, soluciona problemas y ayuda a impulsar la colaboración abierta para solucionar problemas de soporte.


15

6. Gestión de cambios organizativos y de procesos: la tecnología es solo un componente de una transformación en la nube. Las personas, los procesos y la transformación organizacional son fundamentales para una transformación de la nube. La nube impulsa cambios generalizados, incluida la automatización, en muchas funciones críticas, como ingeniería, operaciones, seguridad, cumplimiento normativo, finanzas, etc. El servicio también crea oportunidades para organizarse de manera más eficiente mediante la creación de equipos DevOps multifuncionales para el desarrollo de productos. Cambia la estructura de la organización y las funciones relevantes según corresponda para aprovechar la eficiencia que introduce la nube. Este servicio impulsa el cambio en toda la organización de una manera cuidadosamente orquestada. Evalúa el alcance del cambio introducido por la nube en diversas funciones y trabaja con las partes interesadas para planificar cómo la organización implementará los cambios en estas funciones. Proporciona una comunicación oportuna y específica de las iniciativas de cambio en toda la organización a medida que las lleva a cabo. El equipo de gestión del cambio de la organización va más allá de las iniciativas tecnológicas en la nube para impulsar los cambios necesarios en las personas y los procesos en toda la organización.

Servicios Adicionales La segunda fase de la CEE generalmente proporciona servicios adicionales como ingeniería DevOps, Site Reliability Engineering (SRE), implementación automatizada de aplicaciones y especialista en herramientas CI/CD, preparación operativa en la nube y soporte ORR (operational readiness review) en la nube, y soporte para pilotos/pruebas de valor.

Un CEE maduro debe contener dos equipos distintos: CEE - Cloud Business Office (CBO) y Cloud Platform Engineering (CPE). La CBO se centra en la PMO, la gobernanza y la gestión del cambio organizacional y de procesos. También alinea las soluciones y mejores prácticas ofrecidas por el equipo de CPE a las necesidades de los clientes (Business, Development y Operations) y las partes interesadas clave (Finanzas, Recursos Humanos, EA y Seguridad).

El equipo de CPE proporciona los estándares empresariales como capacidades de autoservicio que permiten a los equipos de desarrollo cumplir con los requisitos de gobierno mientras aceleran la adopción. Son los hacedores prácticos. En la creación inicial de la CEE, habrá una organización CPE.


16

Consideraciones Establecer una CEE, identificar los recursos correctos, obtener su tiempo, identificar los gaps en las habilidades, llenar esos gaps, desplegar una Landing Zone, crear servicios, capacitación, e integrarse en las operaciones y sistemas contables existentes es un ejercicio complejo, que consume mucho tiempo y no trivial. Por lo general, es iterativo, y normalmente comienza pequeños y escalas con el tiempo. Ocupar tiempo para construir la base correcta, los procesos, la experimentación, la fijación y la capacitación acelerará el proceso total. Es muy importante verificar que los clientes y los altos directivos tengan una clara comprensión de la línea de tiempo y que no se comprometan demasiado. Defina los requisitos, cree, pruebe y revise con las partes interesadas claves antes de comprometerse con los programas de migraciones o las fechas de inicio de las aplicaciones.

Patrones para el éxito Estos patrones de éxito deberían centrarse en los primeros 90-100 días de establecimiento de la CEE.

1. Liderazgo ejecutivo: Este es un requisito previo esencial para asegurar el nivel adecuado de apoyo organizativo para establecer una CEE. Establezca un Comité Directivo Ejecutivo compuesto por ejecutivos de nivel C. Estos ejecutivos no son parte del CEE pero se asegura de que la CEE está creando valor y está alineada con las metas y objetivos de nivel corporativo y de la junta directiva. Proporcionan orientación sobre la corrección del curso y eliminan los obstáculos.

2. Comité Directivo de la Nube: Este comité debe establecerse para garantizar el progreso, eliminar los obstáculos y ayudar con cualquier decisión crítica (es decir, decisiones sobre el cambio de los procesos existentes). El comité directivo debe capacitar al equipo de nube para que piense de manera diferente y desafíe el statu quo. Al comienzo del viaje, cuando se toman muchas decisiones críticas, el comité debe reunirse semanalmente o quincenalmente. A medida que el equipo y los procesos maduran, la cadencia de las reuniones puede reducirse y eventualmente eliminarse.


17

3. Oficina de Administración de Proyectos (PMO): La función de PMO suele consistir en scrum masters ténicos / jefes de proyecto que coordinan el trabajo en todas las verticales de TI, en todo el equipo de nube y con los equipos de aplicaciones. Scrum y agile son la visión. Inicialmente, la PMO comunica actualizaciones ejecutivas, comunicaciones a través de todas las verticales, establece comunidades en la nube, contribuye a boletines informativos de TI, coordina lunch & learn, elabora artículos internos, comparte prácticas recomendadas, garantiza la existencia de documentación técnica para el usuario final y participa en la resolución de problemas en todas las verticales. Los documentos de orientación prescriptiva son un gran mecanismo para compartir las mejores prácticas y lecciones aprendidas en un dominio específico, como la nube híbrida, la modernización de aplicaciones y la preparación operativa. La comunidad práctica para la transformación empresarial ha creado documentos de orientación que tratan sobre la nube híbrida en AWS, la resiliencia de aplicaciones, la aceleración de la migración, la recuperación ante desastres y la modernización de aplicaciones. Estos documentos pueden ser utilizados por los CEE de los clientes y pueden ponerse a disposición de los equipos de cuentas con un NDA. Una PMO es fundamental para el éxito a largo plazo, pero no debe ser pesada (en el sentido de complejizar en exceso los procesos de comunicación e intercambio de información) cuando el uso de la nube es bajo en la empresa. La comunicación es clave cuando la CEE está en su infancia, el mantra del equipo debe ser, “comunicarse, comunicarse y luego comunicarse de nuevo”. Un manifiesto en la nube o PR/FAQ (estilo comunicado de prensa, preguntas frecuentes) son un gran recurso de comunicación para empezar y han sido utilizados con éxito por los clientes de AWS. El manifiesto de la nube incluye los principios y principios rectores de la modernización y transformación a la nube AWS. El manifiesto se puede utilizar para guiar la toma de decisiones con respecto a la transformación de las personas, los cambios en los procesos, los cambios organizativos, la arquitectura de la nube y el cambio cultural. La PMO en la nube también puede hacer un impacto facilitando y liderando el llamado semanal a un foro de la nube.


18

4. Formación: El equipo CEE es responsable de colaborar con la organización de formación interna para garantizar la completitud de la formación para los recursos corporativos, los miembros del equipo de CEE y/o los recursos principales de AWS. La CEE valida los requisitos de capacitación de la organización cubre los cuatro espectros de la formación y la educación: sensibilización colectiva, certificaciones, talleres personalizados y capacitación Justo en el tiempo tiempo (JIT, just in time). Seminarios web de nivel100 y 200 de AWS y aprende a dar a conocer AWS y la nube a la mayoría de la empresa. Puede encontrar algunos ejemplos en el sitio de AWS OnlineTech Talks. La formación en certificación de AWS Solution Architect Associate y Professional crea una base de AWS y es un resultado importante para crear una sólida capacidad de prestación, implementación y servicios administrados dentro de las organizaciones de CEE y de TI. Esta formación se ofrece en módulos digitales y presenciales. Los talleres personalizados para migraciones, seguridad, redes, fundamentos de la arquitectura de AWS y operaciones de AWS son formación básica clave. Los miembros de CEE son los mentores, los campeones y los facilitadores clave de la sensibilización y el conocimiento de AWS y de la nube. Además de la formación de recursos técnicos en toda la empresa, la formación de ejecutivos es fundamental. Los ejecutivos que forman parte del comité directivo, en particular, necesitan comprender las capacidades, los servicios, los procesos y las herramientas y metodologías de la nube para que puedan proporcionar asistencia y orientación eficaces.

5. Dinámica central del equipo CEE: Los CEE suelen estar integrados por un equipo de agentes de cambio de mentalidad abierta, encargados de iniciar e implementar un cambio fundamental en el funcionamiento de la organización. El equipo está formado por especialistas en todo el espectro de funciones de TI incluidas las redes, la seguridad, la base de datos, el desarrollo de aplicaciones, las operaciones y la gestión de programas. Los individuos de CEE son pensadores que están listos para liderar la transformación empresarial mediante el uso de servicios, herramientas y tecnologías en la nube. Los recursos de CEE suelen estructurarse desde una perspectiva organizativa en un equipo que informa a un líder en un modelo centralizado; están integrados en las líneas de negocio y tienen una línea punteada a la organización de TI en un modelo descentralizado, o un modelo federado (una combinación de centralizado y descentralizado).


19

6. Gobernanza práctica y pragmática: el día 1 implica el establecimiento de una estrategia de etiquetado de recursos. A continuación, está el establecimiento una estándar de optimización de costos a través de visualización de costos / contracargo, estandarizar la gestión de costos, identificar y medir métricas y KPI (ejemplo, los KPI de operación de respuesta a incidentes se pueden encontrar en el Apéndice 7), e implementar herramientas de optimización como AWS Trusted Advisor y soluciones de socios, como CloudHealth, CloudCheckR, Cloudability, etc.

Otras tareas iniciales de gobernanza incluyen:

a. Identificar y documentar el cumplimiento mediante la administración de configuración

b. Administración de licencias de software

c. Gestión de cuentas de AWS y facturación

d. Definición de directiva de IAM

e. Implementar procesos en torno a la gestión de los aumentos de límite de servicio en todas las cuentas: las incidencias de límite de servicio pueden representar más del 50% de las incidencias de soporte en clientes nuevos en AWS.

7. Proporcione valor inicial: ofrezca de tres a cinco aplicaciones pequeñas (aplicación SaaS de ISV compatible con Drupal, LAMP o AWS), migraciones de elevación y desplazamiento a AWS que reducen el tiempo de ejecución y los costes operativos, o desarrolle y ofrezca un sistema de infraestructura como código para AWS. La CEE debe ofrecer de dos a tres resultados tangibles que impulsen el valor y los resultados del negocio en los primeros 90 días. El valor inicial también se puede demostrar mediante la certificación de un determinado número de recursos en AWS o la creación de un modelo FinOps. La gamificación de estos logros iniciales puede ayudar a impulsar el éxito.

8. Encargue la realización de Revisiones de Buena Arquitectura (WARs, Well Architected Reviews): Las WARs deben ser obligatorias para todas las aplicaciones que se ejecutan en AWS. Una WAR también se puede ejecutar para cargas de trabajo on-prem. De hecho, más de 7000 (10% de todos los WARS) se han completado en cargas de trabajo locales. Realizar estas revisiones en las aplicaciones antes de trasladarlas a AWS puede preparar estas aplicaciones y las cargas de trabajo correspondientes para la migración o modernización a AWS.


20

9. Operaciones de práctica: utilice eventos como AWS GameDays para practicar la respuesta a incidentes. AWS GameDays es un taller que sumerge a los equipos en un escenario ficticio en el que tienen el reto de crear y mantener soluciones altamente disponibles y escalables. Netflix Days of Chaos es una herramienta de código abierto inspirada en AWS GameDays y está dirigida a capacitar a desarrolladores y recursos de operaciones en la gestión de incidentes de producción.

10. Comunidad de práctica: Junto con el desarrollo de una CEE, AWS ha observado que el desarrollo de una Comunidad de Práctica (CoP) es beneficioso. La CoP identifica y comparte las mejores prácticas, y apoya los esfuerzos de mejora de las capacidades y desarrollo de código en comunidad. Estos esfuerzos son útiles para desarrollar la cultura y federar la experiencia en diferentes unidades de negocio, equipos y roles. Estas comunidades de práctica proporcionan zonas seguras donde los compañeros pueden ayudarse mutuamente y compartir problemas del mundo real. A veces, las organizaciones que no han establecido CoP se han estancado sus esfuerzos de adopción, ya que el número de equipos que necesitan apoyo supera la capacidad del CEE. La CoP permite a los miembros de la comunidad ayudarse mutuamente, reduciendo la carga de trabajo en la CEE. Las CoPs son análogo a un “guild” en la implementación de DevOps de Spotify. Amazon y AWS cuentan con comunidades de campo técnica (TFC, Technical Field Community ).

Anti-patrones — Acciones a evitar Estos anti-patrones se centran en acciones, estrategias y enfoques adoptados por equipos de CEE de las empresas que pueden tener graves consecuencias negativas en el éxito de un CEE.


21

1. Cree en “construirlo y vendrán”: Los consumidores de la nube son el cliente. En el caso de una CEE, los consumidores de la nube son la línea de dueños de negocios, propietarios de productos, finanzas, marketing y equipos de TI; infraestructura, operaciones, desarrollo de aplicaciones, seguridad y base de datos. Comprender sus necesidades y proporcionar los servicios y herramientas que respaldan esas necesidades. Los CEE deben asegurarse de que el backlog de CEE esté impulsado por las necesidades y requisitos claramente definidos del cliente interno. La creación de la Landing Zone perfecta de AWS no garantiza que las líneas de negocio se muevan a la nube. Desarrollar una sofisticada plataforma de monitoreo en la nube no significa que las líneas de negocio u operaciones acepten esta nueva cosa. Por ejemplo, una empresa de fabricación global, desarrolló una plataforma de supervisión de AWS. El equipo de CEE fue a desplegar esta plataforma y descubrió que una de las líneas de negocio había desarrollado su propia plataforma de monitoreo que era similar. La línea de negocio, por supuesto,eligió seguir utilizando la que desarrollaron.

2. Subestimar el poder de los mandos intermedios: Más que la falta de coincidencia de talentos, hemos visto que el mayor bloqueador para cambiar y, por lo tanto, la adopción de la nube es la aceptación de los líderes un nivel inferior a los ejecutivos. Como en el ejemplo anterior, esta empresa de fabricación global luchó durante casi tres años para conseguir (más allá del grupo de innovación) cualquier migración a AWS. Una vez que pudieron lograr la adopción de la nube en toda la empresa, pudieron migrar con éxito a AWS. Tenga en cuenta que muchas decisiones durante una transformación en la nube se toman (incluyendo qué migrar primero) debido a razones políticas, no a los resultados empresariales o a la tecnología adecuada.


22

3. Cambio organizativo y cultural: aunque el cambio organizacional no ocurre de la noche a la mañana y es uno de los multiplicadores de la fórmula de innovación de Amazon (Charlie Bell; fórmula para la innovación), muchos esfuerzos de modernización de la nube, transformación digital y transformación de la nube fallan o se detienen porque una empresa intenta cambiar una organización, o pasar a DevOps, Agile o dos equipos de pizza. La realidad es que el cambio organizacional es difícil y disruptivo, y el cambio cultural (la cultura es esencialmente la forma no escrita e inexplicable que las personas toman decisiones, interactúan entre sí e interactúan con socios y clientes) no es a corto plazo. El éxito de los cambios tecnológicos y de procesos influye en el cambio organizacional y cultural. No cambie su estructura organizativa sin iniciar proyectos en la nube. Por ejemplo, implemente una canalización CI/CD. Este cambio forzará cambios en las herramientas, la arquitectura, la tecnología, y los procesos, que centrarán la estructura organizativa y la cultura en el cambio. Amazon tardó más de 10 años en cambiar completamente la estructura organizativa y la arquitectura y la tecnología para pasar a la nube. Amazon no tenía tanta deuda técnica heredada, tenía una cultura definida de innovación (principios de liderazgo, puertas bidireccionales y unidireccionales, etc.), y solo era una empresa de más de 6 años cuando empezaron.

4. Barandas de protección incompatibles: construir demasiada seguridad para cargas de trabajo que no la necesitan, o por el contrario, no construir ninguna. Las barandas deben ser apropiadas para el portafolio de ese momento. Dicho esto, hay barandas mínimas que deben establecerse al principio y son difíciles de rehacer (puerta unidireccional).

5. Falta o incompleta estrategia de perfeccionamiento de habilidades: los anti-patrones comunes pueden ir desde: Los clientes entrenan a todos, pero no tienen un plan para proporcionar a estos individuos experiencia práctica que conduce a la ilusión de experiencia; Nadie está entrenado, por lo que aquellos que saben más son abrumados o se frustran con la mayoría que no tiene entrenamiento; No hay formalidad para compartir las mejores prácticas. Conectar expertos con novatos a través de reuniones, cumbres y comunidades de práctica es una forma de aumentar lentamente la habilidad de los empleados.


23

6. Herramientas agnósticas a la nube: la mayoría de los clientes empresariales defienden las virtudes y pontifican sobre los beneficios de un único panel para orquestación multi-cloud. Sin embargo, en términos de implementación real, los clientes empresariales tienen pocos sistemas de producción reales que proporcionan administración, aprovisionamiento y operaciones en múltiples nubes. Las empresas pueden dedicar una cantidad excesiva de tiempo a las herramientas, tecnologías y procesos de CEE que son independientes de la nube antes de obtener una nube pública adecuada. Por ejemplo, un cliente que postuló e iteró sobre varias soluciones de proveedores que proporcionaban portabilidad en la nube para CI/CD, operaciones y administración. Después de 1 año más, finalmente decidieron ir a AWS primero.

7. Construir una “torre de marfil”: La CEE no debe estar dotada sólo de líderes de pensamiento. Los miembros del equipo del CEE deben ser constructores con habilidades prácticas. Todos los miembros del equipo de CEE deben tener acceso directo a sus clientes, escuchar sus necesidades y construir la cartera de CEE basada en los requisitos empresariales.

8. Dotación de personal a la CEE con Enterprise Architects: Correlacionado con el punto seis, la CEE no debe consistir en Enterprise Architects. Se han realizado estudios que muestran una relación inversa entre el número de arquitectos empresariales en una iniciativa en la nube y el éxito de la iniciativa en la nube.

9. Uso de tarjetas de crédito personales: El uso de tarjetas de crédito personales para crear cuentas de prueba, piloto o desarrollo crea desafíos irrevocables en términos de control de costos, reducción de costos, pérdida potencial de propiedad intelectual (IP) o incluso pérdida de servicio. Se trata tanto de un coste como de una cuestión de propiedad intelectual. Las empresas han sido rehenes de un ex empleado cuando una cuenta de AWS de prueba se convirtió en una cuenta de producción porque se abrió la cuenta con la tarjeta de crédito personal de los ex empleados.


24

10. Mantenga los mismos procesos y herramientas: los desarrolladores, las operaciones, los administradores de sistemas, los desarrolladores de aplicaciones y los DBA están interesados en mantener las mismas herramientas. Los directores de proyectos, auditores, equipos de riesgo y cumplimiento y gobernanza desean mantener los mismos procesos en su lugar. Es el papel de la CEE educar a estas personas que sin cambios en los procesos y nuevas herramientas, no se utilizarán todos los beneficios de la nube, tales como nuevos modelos de precios, computación bajo demanda, arquitecturas efímeras e inmutables, agilidad, flexibilidad y expansión global. Parte de esta formación consiste en asignar los procesos actuales basados en ITIL a nuevas capacidades y procesos amigables para la nube. El argumento entregado para mantener las herramientas y procesos idénticos es que AWS, es sólo otra instalación de alojamiento. Esta actitud sofocará el proceso, el cambio cultural y organizacional que impedirá una transformación de un modelo operativo local a una COM.

11. Deje que los CEE se conviertan en un bloqueador para la adopción de la nube: Un CEE está diseñado para ser un facilitador de la adopción de la nube. Sin embargo, si el CEE no produce resultados, conserva los mismos procesos de modelo operativo local o se convierte en el único punto de validación para todas las implementaciones de AWS, se percibirá que el CEE constituye un impedimento para la adopción de la nube.

Conclusión Se debe adoptar un enfoque mínimo de productos viables (MVP) para construir el equipo de CEE y sus ofertas. Aunque una infraestructura totalmente automatizada y una implementación de aplicaciones con CI/CD compatible con DevOps puede ser el objetivo final, la CEE debe establecer primero una arquitectura básica con la seguridad, el registro y la supervisión adecuados, el etiquetado de servicios de AWS, la infraestructura como código y un red resiliente creada. La CEE debe poner barandas de protección para las operaciones del entorno de AWS, y establecer y gobernar las métricas y los indicadores clave de rendimiento utilizados para garantizar la excelencia operativa. Los objetivos de nivel de servicio (SLO) y los indicadores de nivel de servicio (SLIs) permitirán a las empresas medir el éxito y establecer una línea de base para la mejora continua. Los CEE aprenderán, iterarán y proporcionarán más capacidades. No hay algoritmo de compresión para la experiencia.


25

Apéndice 1: Evolución del CEE de la empresa Amazon Web Services (AWS) ha observado dos enfoques de alto nivel para un CEE. El primero es prescriptivo. En este enfoque, el CEE supervisa o implementa directamente todos los proyectos en la nube. La participación temprana del CEE en la implementación del proyecto es un paso obligatorio para la unidad o línea de negocio. Un caso de uso común para cuando se adopta este enfoque es cuando una empresa está experimentando una migración masiva a AWS impulsada por el cierre del centro de datos o una estrategia all-in (todo a la nube). Un CEE prescriptivo suele ser temporal (de 1 a 3 años) y proporciona una residencia para la experiencia en la nube hasta que se alcance una adopción más amplia. Este enfoque lo implementan las empresas que inician sus viajes a la nube.

El segundo es un enfoque de asesoramiento o habilitación. En este enfoque, los miembros del equipo de CEE sirven como expertos internos para proyectos en la nube. Este tipo de CEE desempeña una función habilitadora, asesorando sobre arquitectura, servicios disponibles y mejores prácticas. Proporcionan estándares, junto con soluciones seguras y repetibles que los equipos consuman para que puedan ser autosuficientes. El asesoramiento CEE acelera la implementación de proyectos de aplicaciones en la nube, pero no es responsable de implementarlos. Los principales casos de uso son nuevos proyectos y migraciones de aplicaciones a AWS impulsadas por un caso de negocio o una estrategia de actualización tecnológica (reducción de costos). El enfoque de asesoramiento lo utilizan las empresas avanzadas en la nube, como Amazon.com.

Con frecuencia, los clientes comienzan con el enfoque prescriptivo y pasan a un enfoque de asesoramiento y habilitación a medida que la adopción de la nube escala en una empresa. Esta metamorfosis de prescriptiva a habilitación encaja bien con la evolución de la TI empresarial, desde las operaciones tradicionales hasta el estado futuro de los modelos operativos de TI (modelos operativos en la nube) que AWS está adoptando.

Apéndice 2: La historia de Amazon.com En 2001, Amazon.com era una aplicación monolítica con equipos monolíticos. La aplicación monolítica se escribió en Perl utilizando una base de datos Oracle como almacenamiento persistente. La aplicación contenía toda la lógica de visualización, negocio y base de datos en todas las funciones empresariales. Esto incluía toda la lógica y funcionalidad por la que Amazon se hizo famoso:


26

pedidos con un solo clic, similitudes y recomendaciones. El primer gran hito fue el lanzamiento en toda Amazon.com de un servicio de implementación llamado Apollo. Este servicio se conviertió en AWS CodeDeploy. En 2009, Amazon.com llevó a cabo un estudio interno para averiguar dónde podrían existir ineficiencias. Lo que encontraron fue que muchos equipos todavía estaban se veían ralentizados por los procesos manuales y los flujos de trabajo. Esta fue la razón del desarrollo de una herramienta de canalización de código en Amazon; esta herramienta fue la base de AWS CodePipline. Durante el viaje cultural, organizacional, tecnológico y de procesos de 2001 a 2009, Amazon.com pasó de proyectos, TI centralizada y procesos basados en ITIL a la productivización, equipos de dos pizzas e implementó herramientas como Apollo y canalización de código. El resultado fue la capacidad de Amazon.com para lograr 50 millones de despliegues al año en 2016. Werner Vogel analiza aspectos de la transformación empresarial y tecnológica de Amazon.com aquí. Por supuesto, la historia no termina aquí. Amazon.com migró a Amazon Elastic Compute Cloud (Amazon EC2) (estilo de lift and shift) en 2012. El 15 de octubre de 2019 Amazon.com desactivó su última base de datos Oracle, habiendo migrado a bases de datos relacionales de código abierto: NoSQL (Amazon DynamoDB), Amazon Elastic MapReduce (EMR), Amazon Redshift y Amazon Simple Storage Service (Amazon S3). Tradicionalmente, la base de datos relacional ha sido la opción de base de datos para todos los casos de uso de persistencia de datos. El nuevo modelo mundial es utilizar la base de datos que mejor soporta el caso de uso.Los principios rectores de la transformación de Amazon.com fueron: diseño para los fallos (todo falla todo el tiempo), monitoreo y gestión centralizados, automatización no es una fase, mejora continua, SSH a servidores no permitido, soportar un ágil SDLC (Software Development Lifecycle), promoción de mejores prácticas sin ser restrictivo (barandillas), la propiedad descentralizada (autoservicio) y la búsqueda continua de conceptos horizontales. Siete áreas tecnológicas en las que se centró el esfuerzo fueron: APIs, gestión de microservicios, integración/entrega continua, tecnología agnóstica, infraestructura como código, monitoreo/métricas/trazas/APM, y comunicación y colaboración (ChatOps). Las lecciones aprendidas fueron: la cultura compartida importa tanto como herramientas, tecnologías, procesos, y estrategias. Los equipos deben ser altamente autónomos basados en productos. Productos no proyectos. Esta estructura organizacional impulsa la propiedad. Los equipos de productos comparten cadenas de herramientas; las mejores herramientas se convierten en el estándar de facto. No hay centro de excelencia, está en todas partes. El mejor enfoque a largo plazo es centrarse en la ingeniería de plataformas en la nube, no en un CEE centralizado. Otra lección que Amazon aprendió durante la transformación es que no solo se mejoró el aspecto tecnológico mediante el uso de productos a los que acceden las API y la migración a la nube. El proceso operativo y de desarrollo se benefició de APIs, CI/CD y DevOps. El modelo de producto fue un factor clave


27

en la creación rápida de soluciones innovadoras con un fuerte enfoque en el cliente. Cada equipo de producto es completamente responsable del producto, desde el análisis de la funcionalidad, hasta la arquitectura, la construcción, y el funcionamiento de la misma. El gobierno se logra mediante la inducción y capacitación exhaustivas, exámenes periódicos de métricas técnicas y de negocio, intercambio periódico de nuevas herramientas, servicios, tecnologías, intercambio público de corrección de errores y administración de configuración y aprovisionamiento (CI/CD).

La implementación de AWS Identity and Access Management (IAM) utiliza la administración de permisos de manera centralizada a nivel de API y como un servicio interno de corredor de identidades. La automatización se logra mediante el despliegue automatizado (AWS CodeDeploy), la entrega continua (AWS CodePipeline) y la infraestructura como código (AWS CloudFormation). El monitoreo continuo se implementa mediante Amazon CloudWatch, alertando sobre el flujo de trabajo empresarial además de métricas de infraestructura de bajo nivel, monitoreo de servicios web (métricas de servicios) y AWS X-Ray (monitoreo de extremo a extremo). La mejora continua se logra con narrativas, PR/FAQs para nuevas características, productos, mejoras de procesos de negocio, nuevas iniciativas y otras ideas, Ninjas de mejora (equipo centralizado que analiza los procesos actuales y hace recomendaciones para mejoras), COEs (mecanismo de Amazon donde cualquiera puede plantear una preocupación por un proceso o producto), AWS — PFR (los clientes pueden enviar solicitudes de características de producto) y una mentalidad de primero API. La interfaz de usuario se puede mejorar continuamente si se accede a través de una API. La consola se puede mejorar continuamente si se escribe utilizando una API abierta basada en REST.


28

Apéndice 3: Equipos de dos pizzas y productivización Amazon y Amazon Web Services (AWS) utilizan una mentalidad de producto para garantizar una excelente experiencia de cliente. Un producto en este contexto se define por: realizar muy bien un número limitado de tareas comunes; tener entradas y salidas claramente definidas; ser útil para múltiples clientes; y mejorar continuamente para satisfacer las necesidades de esos clientes. Por ejemplo, Amazon.com utiliza varios equipos de productos para ejecutar el sitio web del cliente. La definición del producto es importante ya que es la interrelación entre los productos, los clientes que utilizan los productos (consumidores) y los equipos que crean los productos (proveedores). Estas relaciones interdependientes destacan dónde los equipos de productos son tanto consumidores como proveedores. Esta interdependencia requiere un nivel adicional de propiedad, responsabilidad y escrutinio para que cada equipo esté incentivado en ofrecer productos y servicios de mayor calidad. Cuando las organizaciones no definen y operan eficazmente sus sistemas como productos, a menudo experimentan fallas fundamentales que la responsabilidad entre productos gestionaría o evitaría de manera inherente. Con cada equipo de productos completamente funcionales desde el negocio hasta las operaciones, son plenamente responsables de todos los aspectos de sus servicios. Incluso los proveedores de servicios compartidos son propietarios de productos y ofrecen un servicio que otros equipos de productos pueden elegir utilizar (aunque, los productos deben estar en demanda o deberíamos cuestionar su existencia). Sin embargo, el resultado básico es el mismo. El equipo de productos es responsable y no entrega esta responsabilidad a ningún otro proveedor de productos.

Finalmente, poseer la operación de un producto hasta el cliente final (interno/externo) cultiva empatía con la perspectiva del cliente. A medida que los propietarios de productos eligen celebrar contratos con otros propietarios de productos, se crea una relación proveedor/consumidor y se desarrolla la confianza. Empoderar a los equipos de productos para que tomen sus propias decisiones sobre cómo solucionan los problemas y qué otros productos utilizan permite la plena y completa responsabilidad del producto y cómo lo perciben sus clientes.


29

Apéndice 4: Modelo operativo de nube AWS Professional Services Advisory define un modelo operativo de nube como la alineación de los objetivos de negocio y de TI mediante la formación de equipos de productos multifuncionales que están obsesionados con los clientes, capaces de iterar y entregar valor rápidamente, y optimizar los beneficios de la nube. Es una solución prescriptiva de mejores prácticas que transforma la forma en que funcionan la relación entre tecnología y negocio. Hay 17 dominios operativos clave del modelo operativo en la nube:

• Estrategia y cambio

• Diseño de la organización

• CBO*: Arquitectura y gobierno de plataformas

• CBO: Informes Operacionales

• CBO: Gestión de proveedores

• CBO: Gestión de productos

• CBO: Gestión Financiera

• CBO: Formación e Incorporación

• Gestión de Recursos y Bienes

• CPE*: Administración de aprovisionamiento y configuración

• CPE: Gestión de Disponibilidad y Continuidad

• CPE: Gestión de la capacidad

• CPE: Administración del ciclo de vida

• CPE: Procesos principales de TI

• CPE: Salud Operacional

• CPE: Gestión de la seguridad

• Datos y analítica

*Oficina de negocio de nube (CBO, Cloud Business Office) y Ingenieria de plataforma de nube (CPE, Cloud Platform Engeineering).

Para obtener más información, consulte Creación de un modelo operativo de nube


30

Apéndice 5: Migración AWS CSMatrix - Herramienta de evaluación de capacidades Cuestionario para determinar el estado actual de las capacidades de TI e ingeniería de la empresa en términos de negocio, gobierno, personal, seguridad, operaciones, y plataforma. CSMatrix se basa en el marco de adopción de nube de AWS (CAF, cloud adoption framework, por sus siglas en inglés). CSMatrix consta de 192 preguntas divididas equitativamente entre las seis perspectivas de negocio y técnicas de CAF. A cada pregunta se le asigna una calificación de uno a cinco que se alinea a las etapas de adopción de la nube : proyecto, fundación, aceleración y migración, optimización y reinvención, y disrupción. Un reporte que incluye aspectos destacados y observaciones, a partir de la evaluación se genera un gráfico de radar, conclusiones claves, una clasificación funcional (de uno a cinco) con recomendaciones para aumentar la calificación en cada una de las seis perspectivas CAF.

Evaluación de la cartera de migración (MPA, Migration Portfolio Assessment, por sus siglas en inglés) para TCO y ROI La herramienta de evaluación de la cartera de migración (MPA) es una herramienta de costo de migración y TCO (Total cost of ownership, costo total de propiedad en inglés). La herramienta se basa en migraciones de clientes reales, puntos de datos empíricos de clientes, y promedios y supuestos de la industria. La herramienta genera informes para el análisis del TCO (costo de ejecución en AWS) y el informe de ROI (Return of investment, retorno de inversión en inglés) (ahorros de costos - costos de migración). Se genera el tiempo estimado para completar la migración en meses con el número estimado de recursos. La herramienta también proporciona las horas de las personas de migración, incluidos los costos de migración de AWS, los recursos de los clientes y un socio certificado de migración de AWS.

La herramienta en línea puede ser ejecutada por recursos de AWS o socios participantes.

El entrenamiento en línea de APN (AWS Partner Network) sobre economía en la nube se puede encontrar aquí (cursos de entrenamiento de tres a cinco horas). Este entrenamiento requiere iniciar sesión en APN antes de comenzar.

Aceleradores basados en la experiencia (EBA,


31

experienced based accelerators) A través de la ejecución de miles de migraciones de aplicaciones, AWS ha aprendido que no hay ningún sustituto para la experiencia práctica, el diseño de patrones repetibles y el trabajo en equipo en las primeras etapas de la transformación de la nube. Tanto los equipos de aplicaciones como las organizaciones de negocio encuentran comodidad al saber que no son los primeros en experimentar cambios a gran escala de personas, procesos y tecnología. Como resultado, AWS ha desarrollado el programa de aceleración basada en experiencias (EBA). El EBA se diseñó basándose en la experiencia adquirida a través de miles de migraciones y cientos de transformaciones de clientes. Durante la EBA, AWS aporta talento y metodología experimentados en trabajo y capacitación a los clientes para desarrollar los mejores escenarios de migración posibles en función de los requerimientos individuales del cliente. El taller de EBA es de 4 a 5 días y los preparativos comienzan 3-a 4 semanas antes del taller.

Apéndice 6: Orientación prescriptiva CEE crea guías, con un alcance específico de una tecnología o un tema de transformación. Por ejemplo, orientación sobre cómo abordar una solución híbrida con sus aplicaciones y activos locales existentes, o cómo aprovechar eficazmente la nube de AWS en una estrategia de recuperación ante desastres. Los puntos de vista han sido creados por equipo tecnológico empresarial de América que se puede compartir a demanda con socios y clientes bajo un NDA:

1. Resiliencia y Productivización de las Aplicaciones.

2. Nube híbrida.

3. Recuperación ante desastres (continuidad del negocio).

4. Migración a velocidad.

5. Árbol de decisión para el paso de monolítico a microservicios.

Apéndice 7: KPI de operaciones El valor de negocio se convierte en un imperativo de toda la organización cuando crea una visibilidad amplia de las métricas que miden el valor del negocio. Las métricas hacen que el valor de negocio sea real, inmediato e importante. Los líderes de nivel C suelen crear un flujo de trabajo de realización de beneficios utilizando Value Score Card que mide métricas claves para sus objetivos de negocio (fusiones y adquisiciones, nuevos mercados, eficiencia operativa, ventaja competitiva). Por lo tanto, es importante que la CEE identifique, mida, e informe sobre los KPI en función de los servicios que se ofrecen. Se recomienda comenzar con no más de 10 métricas


32

para cada servicio. A medida que las métricas se vuelven verdes, se pueden despriorizar y se pueden agregar otras nuevas en función de los objetivos empresariales priorizados. La CEE debe establecer tableros que informen de métricas importantes y los ponga a disposición de los empleados según corresponda.

Alineación con las necesidades de los clientes internos

• Número de equipos objetivo abordados: número de features en la cartera de productos ya incorporados en el backlog.

• Porcentaje de equipos objetivo abordados: número de equipos objetivo abordados/número total de equipos objetivo.

• Porcentaje de funciones originadas por clientes o partes interesadas: número de funciones en la cartera de productos de clientes o partes interesadas, y número total de funciones.

Mejore la alfabetización y la fluidez de la nube

• Alfabetización en la nube en equipos objetivo: Porcentaje de empleados con alfabetización en la nube en los equipos objetivo.

• Certificación en la nube en equipos objetivo: Porcentaje de empleados con certificación en la nube en los equipos objetivo.

Cree soluciones reutilizables eficaces

• Número de soluciones disponibles

• Número de veces que se reutilizan las soluciones

• Veces que las soluciones se reutilizan: Número de veces que se reutilizan las soluciones/número total de solicitudes recibidas

Acelere la incorporación de clientes

• Tiempo para incorporarse al equipo: El tiempo que se tarda en incorporarse a un equipo con las credenciales adecuadas y proporcionar el acceso necesario

• Tiempo para aprovisionar solución para el equipo

• Tiempo para entrenar al equipo en la solución

• Número de aplicaciones en desarrollo/pruebas

• Número de aplicaciones en producción

• Número de aplicaciones migradas

• Número de aplicaciones nativas de nube


33

Mejorar la eficacia del equipo de aplicaciones

• Frecuencia de despliegue: Número de veces que el software se despliega en producción durante un período de tiempo

• Tiempo de despliegue: tiempo necesario para desplegar el software en producción después de que se haya entregado al control de versiones

• Volumen de cambio: volumen medio de cambio en un despliegue

• Fallo de despliegue: Número de veces que el despliegue provoca interrupciones inesperadas o fallas no planificadas.

• Tiempo medio para la detección: tiempo medio para detectar un error después de una despliegue.

• Tiempo medio entre fallos.

• Tiempo medio para la recuperación: tiempo medio para recuperarse de fallos

Mejore la seguridad y el cumplimiento • Controles de seguridad implementados: número de controles de seguridad

implementados

• Controles de cumplimiento implementados: número de controles de cumplimiento implementados

• Controles de seguridad automatizados: número de controles de seguridad automatizados

• Controles de cumplimiento automatizados: número de controles de cumplimiento automatizados

• Porcentaje de controles de seguridad automatizados

• Porcentaje de controles de cumplimiento automatizados

Operaciones Métricas de gestión de incidentes

La administración de incidentes es un servicio crítico y generalmente se puede dividir en varios subcomponentes:

• Mesa de servicio

o Métricas: Tiempo para responder llamada, tiempo para crear ticket, número de llamadas coincidentes con base de datos de errores conocida.

• Generación de registros

o Métricas: Número de incidentes de producción con trazas


34

disponibles, número de sistemas de producción que registran trazas, antigüedad de las trazas disponibles.

• Captura de eventos y alertas

o Número de falsos positivos, número de falsos negativos, número de eventos creados por alerta vs manual, tiempo necesario para crear tickets a partir de alertas automáticas, tiempo de actividad de la API de incidentes centrales, número promedio de incidentes de severidad 1/2/3 en el mes anterior.

• Categorización de severidad y clasificación de incidentes

o Número de aplicaciones de producción con un plan de categorización de severidad de incidente acordado, número de incidentes clasificados por encima o por debajo, número de grupos de resolución asignados que no están disponibles, tiempo medio que tarda los grupos de resolución en responder.

• Flujo de trabajo

o Cumplimiento de RTO, tiempo medio necesario para cerrar incidentes de severidad 1/2/3.

• Administración de incidentes críticos

o Número de incidentes críticos, tiempo promedio de resolución de incidentes críticos, número de horas de tiempo de actividad de las aplicaciones empresariales de producción pérdidas durante interrupciones críticas.

• Comunicaciones de usuario

o Número de incidentes con comunicaciones publicadas, tiempo promedio para notificar a los usuarios afectados, tiempo para lanzar análisis posteriores a incidentes críticos.

Métricas de automatización

• Porcentaje de actividades de operaciones automatizadas en funciones objetivo Porcentaje de actividades de operaciones automatizadas frente a entregadas manualmente en las funciones objetivo.


35

Colaboradores Entre los colaboradores de este documento se incluyen:

• Tom Laszewski, Técnico empresarial de capital privado de las Américas, AWS

• Andrei Savine, arquitecto de transformación empresarial de WW, AWS

Revisiones de documentos

Fecha Descripción

Agosto 2020 Primera publicación

Date post:	16-Oct-2021
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Motor de habilitación de la nube: una guía práctica

Documents