Modelo de madurez de excelencia operativa

Modernizar las operaciones mediante la inserción intencionada de herramientas controladas por IA para reducir el esfuerzo manual, propenso a errores y ofrecer un valor medible.

Evalúe los flujos de trabajo operativos de un extremo a otro para identificar dónde la inteligencia artificial puede mejorar la coherencia y la productividad, a la vez que equilibra pragmáticamente el costo, el riesgo y el tiempo de valor.

Compra: Soluciones de GenAI listas para usar

Las herramientas de GenAI disponibles en el mercado tienen capacidades de inteligencia artificial integradas. Pueden clasificarse ampliamente por intención. Una categoría es herramientas genéricas de asistencia interactiva, como GitHub Copilot, que dependen del contexto y se pueden usar para una variedad de tareas. Estas herramientas requieren poca o ninguna configuración y proporcionan asistencia contextual que se integra directamente en los flujos de trabajo existentes de los desarrolladores. La otra categoría es herramientas y agentes diseñados específicamente, como agentes de implementación y agentes de ingeniería de confiabilidad de sitios (SRE), que están diseñados para funciones específicas. Se pueden integrar para la productividad del desarrollador a través del IDE y los asistentes de la CLI.

Algunos servicios Azure también tienen características integradas de inteligencia artificial, lo que puede incurrir en costos adicionales.

Construcción: GenAI con implementación personalizada

GenAI personalizado inserta inteligencia artificial directamente en flujos de trabajo operativos y de desarrollo adaptados a una carga de trabajo específica. Los agentes personalizados pueden extraer contexto de incidencias, repositorios de código, métricas y sistemas de supervisión para generar información que refleje el estado actual de las operaciones y actuar dentro de los límites definidos.

Las implementaciones más avanzadas pueden generar y validar código o infraestructura con estándares internos, enrutar el trabajo en función de la experiencia o la disponibilidad, y aplicar modelos de aprendizaje automático personalizados para predicciones especializadas. Este enfoque permite una mayor automatización y una alineación más estrecha con los procesos de la organización, pero requiere una inversión continua en ingeniería, calidad de los datos, gobernanza, seguridad y mantenimiento.

Patrones funcionales de IA

A continuación se muestran algunas de las funcionalidades de inteligencia artificial más comunes y accesibles que se usan en la práctica, pero esta lista no es exhaustiva. Use esta lista para evaluar dónde en las operaciones puede insertar inteligencia artificial para obtener mejoras en la productividad.

✓ Agentes de resumen

Los agentes de resumen suelen usar una arquitectura sencilla de estilo Copilot con recuperación y generación de respuestas sencillas, lo que hace que sean relativamente fáciles de implementar y operar.

Riesgo: El resumen conlleva un riesgo inherente de incorrección, especialmente cuando el agente sintetiza información de varios documentos. Aunque no se pueden eliminar por completo los errores, puede reducir el riesgo operativo mediante la implementación de la explicación y la navegación incremental. Los sistemas deben indicar claramente qué contenido se ha resumido y permitir a los usuarios profundizar en el material de origen para la validación.

Los costos de inferencia pueden acumularse con el tiempo. Enrutar solicitudes sencillas a modelos más pequeños y de menor costo y reservar modelos más avanzados para la síntesis compleja de varios documentos, aceptando la orquestación adicional que podría requerir este enfoque. Proporcione resúmenes iniciales concisos y permita a los usuarios explorar en profundidad detalles auxiliares y contenido de origen.

La administración de datos presenta costos ocultos adicionales. Administre activamente el ciclo de vida de los datos para evitar el sobredimensionamiento de índices causado por documentos obsoletos o versiones redundantes. Cuando sea necesario el contexto histórico, conserve el contenido anterior a través del control de versiones deliberado en lugar de la duplicación no controlada.

Los comentarios directos de los usuarios son valiosos. Capture la entrada sobre la calidad y la utilidad del resumen, y úsela para evaluar las decisiones de enrutamiento del modelo, la eficacia del índice y el impacto de las estrategias de almacenamiento en caché o preprocesamiento.

Examples

• Cultura DevOps de OE:01. Extraiga elementos estructurados como elementos de acción, propietarios, fechas límite y declaraciones de riesgo de documentos no estructurados.
• Respuesta a incidentes OE:08. Resumir los incidentes, las operaciones posteriores, los resultados de seguridad y los informes de auditoría para comprender rápidamente el ámbito, el impacto y los resultados.

✓ Agentes de recomendación

Los agentes de inteligencia artificial que proporcionan recomendaciones se basan en modelos orientados al razonamiento que pueden analizar varios orígenes de datos. Estos modelos deben tener suficiente profundidad analítica para admitir la correlación entre orígenes en lugar de basarse en enfoques ligeros o puramente generativos.

Contrapartida: Aunque un alcance más amplio puede aportar valor, las fuentes con referencias cruzadas podrían estar mal ponderadas o no ajustarse a la intención original. La dependencia excesiva de estas respuestas generadas por la inteligencia artificial corre el riesgo de amplificar los errores y, posiblemente, complicar el problema con las llamadas iterativas.

Los orígenes a los que se hace referencia cruzada suelen aumentar el costo por solicitud y la latencia de inferencia. Minimice las llamadas externas, favoreciendo menos consultas más ricas en lugar de muchas consultas más detalladas. El acceso y la correlación de varios orígenes externos en tiempo de ejecución pueden ser costosos, por lo que paralelizar el acceso a los datos y, cuando sea factible, precargar los datos en índices compartidos.

Trabajar con varios orígenes agrega complejidad de integración. Los errores de un único origen se pueden propagar a través del pipeline de recomendaciones. Aplique límites de validación y protección de seguridad al combinar entradas. Cuando se requiere una baja latencia, consulta los orígenes en paralelo. Pasos de preprocesamiento que no dependen de la solicitud específica, como la clasificación, el enriquecimiento y las búsquedas. Almacene en caché los resultados intermedios y las características usadas con frecuencia para reducir el cálculo repetido.

Trate los motores de recomendaciones como sistemas de soporte de decisión en lugar de cajas negras. La explicación es fundamental para crear confianza y confiabilidad operativa. Los sistemas deben proporcionar lógicas claras para las recomendaciones, resaltar las señales clave y contribuir a los orígenes de datos. Considere la posibilidad de incluir indicadores de confianza (por ejemplo, de 0 a 100%) para ayudar a los sistemas de bajada o a los usuarios a medir la confiabilidad.

Examples

• OE:06 Diseño de una cadena de suministro de cargas de trabajo. Busque escenarios y casos perimetrales centrados en el cliente que son difíciles de detectar y que a menudo se pasan por alto para incluir en el conjunto de pruebas.
• OE:08 Administración de incidentes. Valide los planes de transición del proveedor utilizando IA para simular al equipo de soporte del proveedor usando únicamente la documentación proporcionada, los procedimientos, los modelos de estado y las vías de escalado. La simulación resalta las brechas y las dependencias ocultas antes de la entrega.
• Diseño de automatización de OE:10. Evalúe el código de automatización, la telemetría y los datos de incidentes para recomendar qué automatizaciones deben mejorarse, retirarse o expandirse.

✓ Agentes de generación de artefactos

Los agentes de inteligencia artificial pueden ayudar a generar código, definiciones de infraestructura y pruebas, pero sus salidas podrían formar parte de una carga de trabajo de producción. La generación de código es intrínsecamente no determinista y la traducción de requisitos de lenguaje natural en artefactos ejecutables puede producir resultados que se diferencian de la intención original. Por este motivo, la propiedad clara, los controles explícitos y la integración en las prácticas de ingeniería existentes son esenciales. La inteligencia artificial es más eficaz cuando el espacio del problema se entiende bien y la variación es limitada, por ejemplo, tareas de codificación repetitivas o estandarizadas, y se deben aplicar límites de protección para guiar sus salidas.

Seleccionar los modelos adecuados es fundamental. Use modelos adecuados para la generación de código y la ejecución de herramientas y combítelos cuando corresponda. Un modelo de razonamiento puede ayudar con el análisis del sistema, la planeación o la descomposición, un modelo centrado en código puede generar los propios artefactos y otros modelos pueden admitir pruebas o pasos de implementación.

La generación debe estar fundamentada en plantillas, implementaciones de referencia, directrices de codificación y ejemplos que reflejen los estándares de la organización y del sector. Los estándares claros ayudan a detectar el desfase y aplicar la coherencia. Cuando se usan plantillas, la salida de IA es más predecible.

Al igual que la mayoría de los agentes, los generadores de código pueden extraerse de varios orígenes. Debería tratar todas las salidas como no fiables hasta que se validen. Aplique principios de privilegios mínimos para limitar los permisos y el ámbito de ejecución de herramientas. Los agentes nunca deben implementar ni modificar recursos de producción sin aprobación explícita y controlada.

Integre los artefactos generados en el ciclo de vida del desarrollador estándar. Este ciclo incluye solicitudes de incorporación de cambios, revisiones de código, pruebas automatizadas y análisis de seguridad. Aplique el mismo rigor que aplicaría para el código creado por el usuario, incluidas las comprobaciones de dependencia y la infraestructura como análisis de código (IaC) para garantizar la confiabilidad y el cumplimiento.

Contrapartida: La revisión humana sigue formando parte del modelo de costes y debe tenerse en cuenta al calcular el ROI. Además, el aumento de la generación de artefactos desplaza la presión sobre el rendimiento a etapas posteriores. Los flujos de trabajo de prueba, validación e implementación deben escalarse en consecuencia para evitar introducir nuevos cuellos de botella. La automatización de la validación siempre que sea posible a través de linters, pruebas, análisis estático y verificaciones de políticas es esencial para conservar el flujo de un extremo a otro y el tiempo hasta su valor.

Examples

• OE:02 Estandarizar las operaciones. Genere artefactos de código y documentos que cumplan los estándares de la organización y mantenga la documentación de estándares actualizada a medida que evolucionan los recursos.
• OE:07 Diseñe un sistema de supervisión. Genere configuraciones de panel integradas que alineen las métricas de ingeniería con los resultados empresariales seleccionando automáticamente las métricas adecuadas entre orígenes.
• Diseño de automatización de OE:10. Supervise de forma autónoma los entornos de producción para el desfase de configuración, infiere el estado previsto y actualice las definiciones de arranque para mantener los sistemas alineados con el tiempo.

✓ Agentes de validación de directivas

Los agentes de inteligencia artificial pueden ayudar a revisar y validar los recursos en función de las directivas y los estándares. Su función es respaldar la toma de decisiones, señalar desviaciones y garantizar el cumplimiento. Los seres humanos conservan la supervisión final.

La validación comienza con una evaluación y pruebas cuidadosas antes de la implementación. Los estándares deben tener versiones y cada recurso debe hacer referencia claramente a la directiva aplicable, lo que garantiza la rastreabilidad. A medida que evolucionan las directivas, debe tener en cuenta la sobrecarga de mantenimiento y actualizar los procesos de validación en consecuencia. Siempre que sea posible, realice revisiones por lotes y paralelice y centre las comprobaciones incrementales en los cambios en lugar de volver a examinar todos los recursos.

Debe equilibrar cuidadosamente el costo y el rendimiento. Tenga en cuenta la cantidad de datos históricos necesarios para realizar predicciones precisas, pero también tenga en cuenta el impacto en el almacenamiento, el procesamiento y la latencia. Los datos demasiado pequeños reducen la confiabilidad, pero aumenta demasiado el costo.

La seguridad sigue siendo un factor clave. El acceso a las salidas de validación debe restringirse a los usuarios autorizados, como los revisores de seguridad, para asegurarse de que la información confidencial está protegida.

La eficacia se mide, no se asume. Utiliza paneles de control para hacer seguimiento de métricas como las incidencias detectadas frente a las incidencias en producción, los falsos positivos y la cobertura. Vuelva a introducir estas conclusiones en la lógica de validación, los mensajes y los procesos operativos para refinar continuamente la contribución del agente.

Examples

• OE:03 Formalizar prácticas de desarrollo. Valide las descripciones de trabajo y los criterios de aceptación en las plantillas organizativas para aplicar una barra de calidad coherente.
• OE:04 Estandarizar herramientas y procesos. Revise el código base para aplicar la barra de calidad y los estándares de la organización, y registre brechas como deuda técnica.
• OE:05 Use la infraestructura como código. Aplique estándares de seguridad revisando el código, las plantillas de IaC y los diseños para detectar patrones que no son seguros, infracciones de directivas y configuraciones débiles.

✓ Agentes de optimización de acciones

Los agentes de optimización de acciones se extienden más allá del análisis y las recomendaciones mediante la realización de acciones operativas directas. Dado que sus salidas pueden modificar sistemas o procesos, estos agentes requieren un diseño, supervisión e integración cuidadosos en los flujos de trabajo.

Riesgo: La seguridad es una preocupación principal. Idealmente, los agentes deben funcionar dentro de un flujo de trabajo humano en bucle, donde las acciones propuestas se revisan y aprueban antes de la ejecución en producción. El acceso a herramientas y sistemas debe seguir el principio de privilegios mínimos, limitando el agente solo a los permisos necesarios para realizar sus tareas. La auditoría detallada es esencial, capturando las acciones que se propusieron, quién las aprobó y los registros de ejecución para la rastreabilidad.

Implemente límites de protección que exijan un radio de explosión mínimo limitando el ámbito de cada cambio. Las ejecuciones de herramientas deben ser idempotentes para permitir reintentos seguros y el sistema debe incluir mecanismos de validación y reversión. Los puntos de comprobación, las copias de seguridad u otras estrategias de recuperación pueden admitir la corrección segura de cambios no deseados.

Examples

• OE:08 Administración de incidentes. Tan pronto como se active una alerta, recopile automáticamente el contexto, ponga en correlación los datos y realice la evaluación de prioridades iniciales. Al hacerlo, los ingenieros pueden empezar con una imagen clara del incidente en lugar de la recopilación manual de datos.
• Diseño de automatización de OE:10. Optimice continuamente la configuración de producción de bajo riesgo, como los tamaños de caché y los valores de tiempo de espera, dentro de los límites definidos por el usuario, mediante el uso de valores inferidos a partir del análisis de los datos de supervisión.
• OE:11 Prácticas seguras de despliegue. Automatiza tu estrategia de despliegue en exposición progresiva mediante la identificación autónoma del momento óptimo de salida, así como el segmento objetivo y los porcentajes adecuados para tus despliegues en canario.

Resalta el trabajo en equipo y la unidad en la resolución de problemas para establecer una base sólida que crea operaciones coherentes y estables en fases posteriores.

Establezca una mentalidad de DevOps en el nivel 1 para garantizar el éxito de las estrategias futuras. Implemente metodologías de DevOps bien establecidas para mejorar la eficacia del proceso. Céntrese en la creación de vocabulario, procesos y herramientas esenciales y comunes para operaciones estables.

Estrategias clave

✓ Fomentar la colaboración y fomentar una cultura sin culpa

Alinee los esfuerzos de equipo con las necesidades empresariales al tiempo que fomenta una cultura colaborativa.

Los miembros de equipos centralizados, el personal de tiempo completo dedicado a la funcionalidad de la carga de trabajo, los asociados o los proveedores suelen administrar las operaciones de carga de trabajo. Estas personas deben funcionar como una fuerza colectiva, con respeto mutuo y reconocimiento de la experiencia entre sí. Si los equipos operan como partes independientes, pueden producirse complejidades y fricción. Los equipos independientes minan el objetivo de funcionar como un único sistema eficaz que impulsa los resultados empresariales.

Para reducir el sentido aislado de la propiedad, aboga por un enfoque unificado para resolver problemas. Todos los esfuerzos deben satisfacer las necesidades del negocio. Vea tanto los éxitos como los fracasos como resultados compartidos.

✓ Adoptar metodologías y herramientas de colaboración estándar

Comience con herramientas probadas en el sector y procesos de ciclo de vida de desarrollo de software (SDLC) que se adapten a la carga de trabajo y mejore la eficiencia del desarrollo. No diverge de métodos probados y evite metodologías personalizadas porque a menudo presentan una mayor fricción.

Entre las opciones populares se incluyen los paneles Agile, Scrum y Kanban. La mayoría de los desarrolladores experimentados, los ingenieros de DevOps y los propietarios de productos están familiarizados con estas herramientas, lo que minimiza la curva de aprendizaje para las nuevas contrataciones.

Inicialmente, use estándares establecidos del sector para incorporar la normalización. Optimice los procesos más adelante. Asegúrese de que las herramientas que seleccione pueden crecer con sus necesidades, sin necesidad de cambiar a soluciones de vanguardia prematuramente.

✓ Configurar procesos de control de código fuente

En función de la escala de la aplicación, decida cómo estructurar el código fuente. Para sistemas más grandes, cada equipo debe tener sus propios procesos para crear e implementar componentes de los que son responsables. Deben tener interfaces claramente definidas que permitan la detectabilidad y el uso compartido de componentes con otras partes del sistema. Seleccione una tecnología de control de código fuente y configure procesos para asegurarse de que los miembros del equipo no interfieren entre sí.

De forma similar, una única canalización de implementación podría ser más eficaz para aplicaciones a menor escala. Esto simplifica la coordinación y también puede ser mejor para la confiabilidad. Sin embargo, puede resultar difícil actualizar o migrar partes específicas del sistema.

✓ Usar la infraestructura como código (IaC) como enfoque de implementación principal

Use un enfoque declarativo como estándar para las implementaciones para garantizar la coherencia, repetibilidad y ventajas a largo plazo, como la automatización, la documentación automática y el historial de cambios.

Se prefieren las implementaciones de IaC en lugar de implementaciones en portales para evitar riesgos derivados de configuraciones inconsistentes y la falta de pruebas. Evite lenguajes compilados o formatos propietarios restringidos a programas específicos.

Comience con una buena base mediante herramientas compatibles de forma nativa con Azure, como Bicep y Terraform. Evalúe las herramientas para asegurarse de que simplifican su futuro recorrido. Asegúrese de que el proveedor de tecnología tiene una buena documentación y un programa de soporte técnico de servicio confiable.

Riesgo: Considere las oportunidades de modernización perdidas como riesgos. Por ejemplo, debe modernizar las herramientas y los procesos que se usan en soluciones locales. Al migrar a la nube, estas herramientas suelen requerir scripts personalizados difíciles de administrar y pueden causar problemas si no los moderniza.

Para mitigar este riesgo, explore las opciones de tecnología modernas y actualice los procesos locales.

Uno de los objetivos para adoptar IaC es la coherencia. Hacer que las plantillas sean lo suficientemente flexibles como para implementarse en varios entornos. Use parámetros, variables y archivos de configuración para modificar la configuración de recursos para cada entorno. Abstrae solo la configuración necesaria y evita la excesiva abstracción de la configuración que rara vez cambia. Además, evite la sobrecarga de las soluciones al confiar en bibliotecas de plantillas extensas. Esta práctica puede provocar desafíos de mantenimiento.

Establezca una base sólida de IaC para crear más oportunidades para la optimización de la implementación y la administración del sistema en niveles futuros. Por ejemplo, puede agregar la configuración de estado deseada o GitOps.

✓ Priorice la seguridad desde el principio

Priorice la seguridad incluso en esta fase temprana. Las medidas de seguridad suelen basarse en la segmentación, como roles, recursos y redes, que presentan complejidades. El equipo debe reconocer estas complejidades, crear medidas de seguridad al principio y planear la inversión en seguridad a lo largo del tiempo. Este enfoque evita aplazar las implementaciones de seguridad a fases posteriores.

Riesgo: Los procesos de desarrollo, soporte técnico y operaciones pueden crear fricción. Los esfuerzos de seguridad a menudo se enfrentan a la resistencia, aunque los equipos empiecen fuerte con buenas intenciones.

Para mitigar el riesgo, agregue tareas de seguridad a trabajos pendientes. Esta práctica garantiza la responsabilidad dentro del equipo y hace que el progreso sea rastreable junto con las tareas de desarrollo.

Haga que las herramientas y los procesos sean transparentes para detectar fácilmente vulnerabilidades a través de auditorías y revisiones del mismo nivel. Explore las herramientas estándar del sector que admiten el examen de vulnerabilidades y los controles de seguridad, incluso si aún no las implementa.

Asegúrese de que las herramientas y las prácticas de implementación usen el mismo proveedor de identidades que los entornos de producción para minimizar los diferentes planos de control de identidad.

Estandarizar procesos fundamentales. Este enfoque simplifica las responsabilidades de toma de decisiones y define los requisitos para la implementación y supervisión del sistema.

En el nivel 2, el equipo debe adoptar un enfoque más estructurado y centrar las actividades de desarrollo en la funcionalidad principal de la carga de trabajo. Establecer la coherencia al principio ayuda a minimizar las cargas operativas en fases posteriores.

Estrategias clave

✓ Definir roles de equipo y responsabilidades de toma de decisiones

Adoptar una mentalidad de producto. En lugar de ver la carga de trabajo como integración de herramientas, tecnologías o funciones de trabajo, tratóla como un producto cohesivo con un enfoque claro en el objetivo final. En el nivel 2, aplique un enfoque más estructurado en el que cada rol se define y respeta claramente.

La experiencia en el equipo suele variar. Esta diversidad puede ser útil para distribuir la toma de decisiones entre varias funciones de trabajo. Por ejemplo, los miembros específicos del equipo podrían destacar en la toma de decisiones técnicas, mientras que otros miembros del equipo podrían ser expertos en definir resultados empresariales para seguir siendo competitivos en el ecosistema.

Riesgo: Algunos equipos de trabajo adoptan una cultura impulsada por el consenso, donde se comprometen a las tareas solo cuando todos están de acuerdo. Esta cultura promueve la inclusividad, pero a menudo ahoga las iniciativas cuando no se logra el consenso total.

Asegúrese de un proceso de toma de decisiones bien estructurado mediante los siguientes principios:

• Designe a un individuo responsable directamente para asegurarse de que la toma de decisiones se distribuya entre los miembros del equipo y se alinee con sus áreas de experiencia, en lugar de estar centralizadas con una persona.

  Documente quiénes son los responsables de la toma de decisiones e incluya esta información en los materiales de incorporación de nuevos empleados.

• Considere la posibilidad de adoptar una metodología de toma de decisiones que defina claramente roles y responsabilidades específicos. Tenga en cuenta que estos enfoques pueden crear divisiones y alejar el foco de los objetivos del producto. Establecer mecanismos de control y equilibrio para evitar la toma de decisiones aislada y reducir el conflicto.

✓ Se esfuerza por realizar mejoras, independientemente de lo pequeño que sea

Fomentar una mentalidad de mejora continua significa tomar decisiones hoy en día con la comprensión de que se pueden refinar mañana.

Retrasar los cambios puede hacer que el equipo pierda las oportunidades de mejora actuales. Evite el exceso de pensamiento e indecisión. La búsqueda de una solución perfecta podría dificultar el progreso pequeño pero significativo. Céntrese en realizar mejoras ahora mientras busca continuamente formas de mejorar.

La deuda técnica es una herramienta estratégica en el desarrollo para capturar decisiones a corto plazo. Puede servir como motivador para las actualizaciones incrementales, lo que evita la acumulación innecesaria. Trate la deuda técnica como una tarea recurrente en la lista de tareas pendientes.

✓ Estandarizar procesos fundamentales

Diferentes clases de cargas de trabajo tienen requisitos de proceso únicos adaptados a sus características específicas. Por ejemplo, las cargas de trabajo de IA dependen de las operaciones de aprendizaje automático y las operaciones de inteligencia artificial generativa para impulsar las canalizaciones de datos al modelo. Las cargas de trabajo críticas priorizan los paneles de supervisión en tiempo real en los que los ingenieros de confiabilidad del sitio pueden actuar rápidamente.

Dentro de una clase de carga de trabajo, se esfuerza por la estandarización para mejorar la coherencia y reducir la carga operativa. En el caso de las cargas de trabajo de IA que incluyen modelos discriminativos y generativos, normalice los procesos en torno a las operaciones de datos. Estas operaciones incluyen el acceso a datos, la limpieza y la transformación antes de que se utilicen para entrenar modelos o fundamentar modelos de IA generativa.

Se recomienda la normalización para los siguientes casos de uso:

Riesgo: La mejora continua y la innovación a menudo se producen cuando un equipo se desvía ligeramente de los estándares establecidos para explorar mejores enfoques. Estas desviaciones deben fomentarse pero estar estructuradas. Por ejemplo, hospedar días de innovación permite al equipo centrarse en proyectos de mejora previamente seleccionados, lo que fomenta ideas nuevas y experimentación.

✓ Comprar herramientas en lugar de crear herramientas personalizadas

Los procesos estandarizados incluyen las herramientas necesarias para una implementación eficaz. En este nivel, priorice las soluciones comerciales en lugar de soluciones personalizadas, que puede reconsiderar posteriormente para casos de uso especializados.

Las herramientas diarias para cargas de trabajo incluyen herramientas de desarrollo, pruebas, supervisión e implementación. Las herramientas compradas simplifican los flujos de trabajo y garantizan la coherencia. Esta coherencia permite a los equipos centrarse en ofrecer características sin la complejidad de desarrollar y mantener soluciones personalizadas.

Riesgo: Cuando se tienen en cuenta las herramientas, a menudo hay una tendencia a sobresalentar la extensibilidad y el potencial futuro de la herramienta en lugar de su funcionalidad principal. En esta fase, céntrese en herramientas prácticas, solucione los problemas actuales y ajuste al flujo de trabajo actual.

✓ Adopción de la automatización en toda la carga de trabajo

A medida que desarrolle una carga de trabajo nueva o existente, busque oportunidades para integrar la automatización. El diseño de una nueva carga de trabajo teniendo en cuenta la automatización desde el principio hace que la adopción futura sea perfecta. De forma similar, la incorporación de la automatización a las cargas de trabajo existentes o las cargas de trabajo brownfield , al principio de su ciclo de vida, le ayuda a obtener eficacia y mantener la coherencia a lo largo del tiempo.

Para simplificar la adopción, use herramientas avanzadas y conocidas que sean compatibles con su plataforma en la nube en lugar de crear soluciones desde cero. Explore las herramientas de automatización nativas del proveedor de nube para simplificar el diseño. Por ejemplo, muchos servicios de Azure admiten el escalado automático para las funcionalidades de rendimiento y conmutación por error para la recuperación ante desastres. Al evaluar las herramientas que no son de Microsoft, tenga en cuenta la experiencia de su equipo y los estándares empresariales pertinentes.

Las siguientes áreas pueden beneficiarse de la automatización:

• Tareas operativas rutinarias, como la supervisión y las alertas, y la administración de actualizaciones

• Tareas del ciclo de vida de desarrollo de software, como implementaciones y pruebas

• Optimizaciones del rendimiento de la carga de trabajo, como el escalado de recursos

• Mecanismos de seguridad y gobernanza, como exámenes y aplicación de directivas

• Actividades de copia de seguridad y recuperación

• Optimizaciones de costos, como desasignaciones y cierres de recursos

Riesgo: En las primeras fases del desarrollo de cargas de trabajo, tenga cuidado de centrarse demasiado en la creación o integración de la automatización, ya que puede desviar la atención de la entrega de la carga de trabajo a la producción. Tome un enfoque medido para asegurarse de que la carga de trabajo se pueda administrar al tiempo que mantiene la velocidad de desarrollo.

Dilema: Si una tarea se puede realizar con poca frecuencia, eficaz y segura por parte de los seres humanos, puede que no valga la pena automatizar. Por ejemplo, la automatización de la actualización anual de un certificado podría no justificar la inversión de los ciclos de desarrollo.

✓ Ampliar la experiencia de infraestructura como código para configurar la infraestructura y administrar las aplicaciones

En el nivel 1, el enfoque consiste en adoptar herramientas de infraestructura como código (IaC) para implementar infraestructuras y canalizaciones para el código de aplicación. En el nivel 2, amplíe esa práctica para incluir la configuración y la administración de la infraestructura y las aplicaciones implementadas.

Use un enfoque de configuración de estado deseado para arrancar los recursos y evitar el desfase de configuración. Las distintas tareas y plataformas requieren diferentes herramientas de automatización. Por ejemplo, Ansible es adecuado para administrar la configuración de estado deseada para máquinas virtuales (VM), mientras que una solución de GitOps, como Flux, es adecuada para clústeres de Kubernetes.

Determine el nivel correcto de automatización para las tareas posteriores a la implementación para minimizar la carga operativa al tiempo que mantiene el diseño sencillo. Las tareas como instalar certificados, configuraciones del sistema operativo y propagación de bases de datos son todas las opciones adecuadas para la automatización. Además, considere la posibilidad de ampliar la automatización para incluir la implementación y configuración de la aplicación en máquinas virtuales o hosts de contenedor recién implementados.

Riesgo: Evite la expansión innecesaria de herramientas. Los desarrolladores o equipos de desarrollo que usan diferentes enfoques y tecnología pueden dar lugar a un ecosistema de herramientas fracturado. Normalice una serie de herramientas selectas para la carga de trabajo que cumplan sus requisitos y asegúrese de que el equipo de cargas de trabajo está entrenado en esas herramientas. Del mismo modo, sea selectivo sobre la adopción de estándares organizativos para herramientas. Si su organización sugiere herramientas que agregan un riesgo excesivo a la carga de trabajo, evalúe herramientas alternativas que sean más adecuadas.

✓ Definir la estrategia de implementación de la carga de trabajo

Una estrategia de implementación es un componente fundamental de excelencia operativa. Una estrategia de implementación bien diseñada garantiza que los servicios permanezcan disponibles para los usuarios al reducir o eliminar el tiempo de inactividad durante las actualizaciones o los cambios. Obtenga consenso de las partes interesadas sobre cómo y cuándo se implementan los cambios en producción. Considere los siguientes puntos:

• Defina el tiempo de inactividad tolerado. Determine si la carga de trabajo puede admitir el tiempo de inactividad sin causar problemas significativos o pérdidas financieras. Especifique claramente si cero tiempo de inactividad es un requisito para las implementaciones rutinarias.

• Establecer la frecuencia de implementación. Determine la frecuencia de implementación basada en el desarrollo de características. Acepte una programación, ya sea diaria, semanal, trimestral u otro enfoque adecuado. Cuando sea posible, priorice las implementaciones más pequeñas y frecuentes si se alinean con su escenario.

• Planee las implementaciones de emergencia. Desarrolle un plan para implementar procedimientos que gestionen implementaciones de emergencia, como parches urgentes de seguridad. Este enfoque garantiza que los miembros del equipo comprendan sus responsabilidades y puedan actuar rápidamente cuando sea necesario.

Diseñe un sistema de implementación repetible que se pueda automatizar para minimizar los errores y garantizar la coherencia. Incluya disposiciones para la reversión para restaurar el sistema a un estado funcional si se producen errores en la última implementación.

✓ Diseñar la pila de supervisión de cargas de trabajo

El diseño de un sistema de supervisión requiere que seleccione qué supervisar y comprender la importancia de esas métricas para los usuarios.

Empiece por recopilar registros y métricas de todos los componentes de la carga de trabajo. Aproveche las herramientas de supervisión proporcionadas por la plataforma. Estas herramientas se integran con los servicios y proporcionan información funcional y operativa con poca configuración. Almacene estos datos de forma segura en una solución de almacenamiento confiable que se pueda consultar para su análisis.

Riesgo: Evite recopilar datos excesivos porque puede crear ruido y aumentar los costos. Comience con métricas básicas como CPU, uso de memoria y uso de almacenamiento. Agregue métricas de estado de aplicaciones útiles a lo largo del tiempo.

En función del análisis inicial, trabaje con las partes interesadas para definir lo que significan los estados correctos y incorrectos para la carga de trabajo. Esta información se usa en fases posteriores para desarrollar un modelo de salud que refleje con precisión ese estado de salud.

Riesgo: Su canal de monitoreo sirve como herramienta para recopilar métricas comerciales, como contracargos, acuerdos de nivel de servicio de transacción, garantías de capacidad y totales de ventas. Mantenga una distinción clara entre las métricas de estado de la carga de trabajo y las métricas empresariales.

Recopile métricas empresariales como una característica de aplicación en lugar de mediante configuraciones de supervisión. Los flujos de datos de supervisión se pueden muestrear y normalmente no se pueden recuperar en un desastre. Trate los datos críticos para la empresa como datos de carga de trabajo y manténgalos separados de las señales de estado de la carga de trabajo.

Reducir el riesgo de errores de implementación que podrían dar lugar a tiempo de interrupción. Si se produce un tiempo de inactividad, asegúrese de que los ingenieros de fiabilidad del sitio pueden enfocarse en problemas críticos sin perder tiempo en recopilar métricas para el análisis.

En los niveles anteriores, normaliza el ciclo de vida de desarrollo de software y toma decisiones clave sobre los métodos de implementación, las pruebas y la recopilación de telemetría.

En el nivel 3, las operaciones deben madurar para aumentar la confianza en la implementación. Las pruebas se convierten en un requisito para el lanzamiento en vivo para garantizar implementaciones seguras y estables. Los procesos de implementación también evolucionan, incorporando canalizaciones automatizadas para construir e implementar cargas de trabajo en producción. Para minimizar el radio de impacto de los riesgos, se mantiene una segmentación adecuada entre los recursos fundamentales y el código de aplicación.

Las prácticas de supervisión también maduran. El sistema de monitoreo se extiende para implementar un modelo de salud que convierte el conocimiento operativo en ideas accionables. Las alertas se simplifican para adaptarse al contexto empresarial, por lo que las alertas irrelevantes no provocan falsas alarmas y provocan una falta de confianza en el sistema de supervisión.

Estrategias clave

✓ Uso de entornos independientes para promover versiones

En este nivel, es importante establecer la promoción de versiones como un protocolo de control de cambios formal antes de la puesta en marcha. Este proceso lleva adelante los cambios propuestos a través de varias fases con puertas de calidad. Cada fase se somete a pruebas exhaustivas y los cambios solo avanzan si pasan estas comprobaciones y reciben aprobación.

Cree entornos distintos para diferentes fases, como desarrollo/pruebas, control de calidad, pruebas de aceptación de usuarios (UAT) y producción. Este enfoque garantiza una validación exhaustiva antes de pasar a la siguiente fase. La idea es administrar los riesgos en los entornos inferiores porque los errores deben detectarse temprano para minimizar el radio de explosión.

✓ Realizar pruebas suficientes

En este nivel, decida una estrategia en la que las pruebas se priorizan para las partes críticas del sistema. Siga estos pasos para garantizar una estrategia de prueba sólida:

• Definir casos de prueba. Cree casos de prueba para el código de la aplicación, las plantillas de infraestructura y la configuración.

• Realice varios tipos de pruebas. Realice diferentes tipos de pruebas en cada entorno. Comience a probar los cambios de alto riesgo en entornos de bajo riesgo. Mueva gradualmente los cambios de alto riesgo a entornos de mayor riesgo a medida que crece la confianza.

• Configure entornos de prueba independientes. Cree entornos distintos para diferentes actividades de prueba. Por ejemplo, si realiza pruebas de UI, cree un entorno dedicado que esté separado de los entornos de desarrollo y de producción.

Idealmente, mantenga los entornos de desarrollo y prueba lo más parecidos posible al entorno de producción. Asegúrese de que los datos de prueba coincidan estrechamente con los datos de producción, incluso si solo es un ejemplo. Los recursos también deben ser comparables. Por ejemplo, las bases de datos de prueba pequeñas que tienen unos pocos megabytes de datos pueden ser suficientes en algunos casos, pero es esencial validar las características mediante el uso de una base de datos de tamaño de producción cercano que contiene varios terabytes para evaluar el rendimiento real.

Dilema: Es importante mantener estos entornos cerca, pero hay desventajas que se deben tener en cuenta. La implementación de la escala completa del entorno de producción en desarrollo no es factible.

Encuentre equilibrio entre la proximidad al entorno de producción y tener un entorno no de producción rentable. Por ejemplo, considere la posibilidad de crear entornos de desarrollo y pruebas efímeros, que se descomponen después de que se supere una prueba.

Dimensionar entornos según el caso de prueba. Las pruebas unitarias solo pueden requerir la biblioteca coincidente y las versiones del sistema operativo en una configuración más pequeña. Las pruebas de resistencia pueden necesitar un entorno de preproducción con SKU de servicio idénticas. Las pruebas de rendimiento pueden exigir una implementación a escala de producción.

✓ Automatizar pruebas y otras comprobaciones de calidad cuando sea posible

La automatización es excelente para garantizar la coherencia y detectar rápidamente cambios de configuración inesperados. Determine qué cambios se pueden comprobar mediante pruebas automatizadas. Por ejemplo, los análisis de seguridad son perfectos para la automatización cuando te trasladas a un entorno de desarrollo. No todas las pruebas deben automatizarse y algunas pruebas no se pueden automatizar. Por ejemplo, UAT requiere comparar la implementación con las expectativas de los usuarios y obtener su aprobación.

Hay varias herramientas de prueba disponibles para automatizar y simplificar diferentes tipos de pruebas, como Azure Load Testing y Azure Pipelines para orquestar pruebas automatizadas.

✓ Configurar procesos de aprobación

A medida que la implementación se mueve a través de diferentes entornos, es importante usar procesos de prueba y aprobación para validar los cambios. Esta validación debe madurar y hacerse más rigurosa con el tiempo. Por ejemplo, al pasar de una estación de trabajo de desarrollador a un entorno de desarrollador compartido, los exámenes de seguridad básicos y las revisiones del mismo nivel suelen ser suficientes. Pero más adelante, es posible que tenga que incluir las partes interesadas de la empresa. Tenga en cuenta las siguientes instrucciones para garantizar un proceso de implementación estructurado y eficaz:

• Aprobación de versiones normales: En lo que respecta a las versiones normales, el traslado de ensayo a producción requiere un conjunto diferente de criterios. Las decisiones sobre las versiones, como pasar a producción, necesitan aprobación de las partes interesadas, una documentación clara o ambas. El equipo de carga de trabajo debe definir quién forma parte del proceso de aprobación y sus responsabilidades. En algunos casos normativos, los auditores también pueden incluirse en el proceso de toma de decisiones. Establezca estos roles y responsabilidades en el nivel 2.

• Tener un proceso separado para los hotfixes: Para situaciones críticas como el despliegue de parches de seguridad, podría necesitar un proceso de implementación ad-hoc. Cree un proceso de emergencia para acelerar estas correcciones de alta prioridad. Este proceso podría incluir la aprobación de solo las partes interesadas clave y los miembros técnicos. Como alternativa, puede desarrollar una canalización que omita algunas aprobaciones para una implementación más rápida.

  Tenga en cuenta el riesgo para la empresa o los clientes al determinar qué pasos omitir. Las pruebas de alta inversión y bajo riesgo se pueden omitir en situaciones de emergencia, mientras que las pruebas de alto riesgo y baja inversión siempre deben ejecutarse. La persona directamente responsable (DRI) debe tomar las decisiones finales con la entrada de las partes interesadas clave y los responsables de la toma de decisiones técnicas.

✓ Implementar implementaciones automatizadas

Mantenga ciclos de implementación independientes para diferentes capas en función de su tasa de cambio esperada. En algunos casos, puede ser necesario combinar ciclos, en función de las interdependencias y los requisitos de tiempo de inactividad. Sin embargo, en la mayoría de los casos, se esfuerza por la granularidad mediante la administración independiente de cada capa con privilegios mínimos. Asegúrese de que los cambios de una capa no afecten a los demás.

Por ejemplo, los cambios en la infraestructura de red deben ser menos frecuentes que los cambios en el código de la aplicación. Administre estos cambios por separado a través de un proceso simplificado a través del control de calidad. Para crear un proceso, cree canalizaciones de implementación que estén alineadas con las capas de carga de trabajo. Ejecute pruebas en recursos de infraestructura como código en un entorno controlado antes de implementarlas en producción.

✓ Desarrollar un modelo de salud

Una vez que tenga implementado un sistema básico de supervisión, combine el contexto de negocio con los datos de supervisión para cuantificar el estado general de funcionamiento de los componentes de la carga de trabajo y el estado general del conjunto. Este ejercicio, conocido como modelado de salud, implica contextualizar los valores de supervisión de la infraestructura y las aplicaciones dentro del contexto empresarial. Para crear un modelo de salud eficaz, tenga en cuenta los siguientes principios clave:

• Proporcione el contexto de datos observado por el sistema. Establecer umbrales es una parte importante del modelado de salud. Para asegurarse de que los umbrales son significativos para la carga de trabajo, proporcione valores numéricos con contexto. Por ejemplo, aunque un uso elevado de CPU entre 70% y 90% podría indicar generalmente un estado incorrecto en una carga de trabajo, podría ser correcto para otra carga de trabajo que use eficazmente los recursos disponibles.

• Alerta sobre los cambios. Los cambios en estos valores indican cambios en el estado de salud y deben impulsar la acción por parte de los DRIs. Por lo tanto, las alertas son otro componente esencial del modelado de salud. Evite activar las métricas estándar y enviar todas las alertas a un centro de soporte técnico. En su lugar, genere alertas en función de los cambios en su modelo de salud. La información contenida en las alertas debe ser significativa y accionable, notificando a los equipos adecuados sobre problemas específicos que necesitan investigación o acción correctiva.

• Visualiza tu modelo de salud. Use herramientas de visualización de la plataforma de supervisión para compartir fácilmente señales de estado de carga de trabajo con diferentes partes interesadas. Algunas partes interesadas pueden requerir estadísticas específicas, como la disponibilidad de la aplicación. Los equipos de operaciones necesitan acceso a todas las señales de estado. La configuración de paneles diferentes puede ayudar a proporcionar a cada equipo la información que necesitan.

Con el tiempo, desarrolle una estrategia para realizar un seguimiento y analizar las tendencias históricas de la salud de la carga de trabajo.

✓ Configurar el proceso de administración de incidentes

Cuando la carga de trabajo está en producción, es normal tratar incidentes como interrupciones de la plataforma, daños en los datos, etc. La clave es gestionar estos incidentes de forma eficaz dentro de los objetivos que ha establecido para la carga de trabajo. Por lo tanto, antes de ir a producción, tenga un plan de soporte técnico estructurado como primer paso en la administración de incidentes.

• Formalice las operaciones de soporte técnico definiendo quién está de guardia, cuáles son sus tareas y cómo se administran las transferencias entre el personal de guardia. Lo ideal es que no haya huecos en la rotación de llamadas y todos sepan quién es responsable de controlar incidentes en un momento dado.

• Para cada tipo de incidente, asegúrese de que tiene un proceso de respuesta o cuaderno de estrategias bien definido. Por ejemplo, puede usar los resultados del análisis del modo de falla (FMA) o de la línea base de seguridad.

• Use el modelo de salud para ejecutar pruebas básicas sobre la preparación de la gestión de incidentes, donde el operador supervisa el impacto de un problema simulado mientras un desarrollador de guardia puede necesitar solucionar problemas.

Asegúrese de que el sistema cumple los estándares de calidad prometidos a los usuarios y evita infracciones de los acuerdos de nivel de servicio.

En los niveles anteriores, el equipo de gestión de cargas de trabajo se centra en la creación de características y en poner el sistema en producción. En este nivel, el enfoque cambia de crear características a mantener y mejorar un sistema activo. Con los usuarios reales que ahora dependen de ella, la prioridad se convierte en la administración de cambios a través de operaciones eficientes del día 2, como la evaluación de prioridades, el mantenimiento, las actualizaciones y la solución de problemas.

La estrategia principal es usar la experiencia real para mejorar las operaciones. Las pruebas también se convierten en una práctica no negociable para reducir los riesgos asociados a los cambios. Debe integrar las pruebas en cada parte del desarrollo, desde la corrección de errores hasta agregar características y refinar la respuesta a incidentes. Sin ella, es posible que los problemas graves no se detecten hasta que lleguen a producción.

En este nivel, la deuda técnica se convierte en una preocupación real. Las implementaciones que son menos que ideales pueden estar activas, lo que puede complicar el mantenimiento. Los equipos deben analizar la carga de mantenimiento y centrarse en reducirla.

Estrategias clave

✓ Uso de prácticas de implementación seguras

Después de la producción, los tres tipos clave de cambios suelen incluir actualizaciones rutinarias, nuevas actualizaciones de características y actualizaciones de emergencia. Use prácticas de implementación seguras para mantener el sistema estable durante estos cambios. Independientemente del tipo de cambio, trate cada cambio como un posible punto de error para los usuarios de la carga de trabajo.

Integre las estrategias siguientes en el proceso de control de cambios:

• Valide continuamente y de manera exhaustiva. Pruebe temprano y a menudo a lo largo del ciclo de vida de desarrollo y a medida que los cambios progresan a través de diferentes entornos. Idealmente, cada vez que un artefacto cambia, cree pruebas centradas en esos cambios. A continuación, ejecute el conjunto de pruebas completo para validar los flujos de un extremo a otro. Los resultados de las pruebas proporcionan datos de validación, pero las partes interesadas de la empresa deben seguir aprobando estos cambios.

  Contrapartida: la ejecución de todo el conjunto de pruebas genera confianza en las implementaciones. Sin embargo, puede que no sea práctico para todos los cambios debido al tiempo y al costo. Equilibre las pruebas exhaustivas con consideraciones sobre los costos. Adapte el proceso de aprobación en función del impacto de los cambios. Los cambios menores deben tener un procedimiento simplificado, mientras que los cambios significativos, como las nuevas características, requieren una revisión exhaustiva.

  En este nivel, puede adoptar conceptos operativos avanzados, como conmutaciones por error regionales. El objetivo es automatizar completamente estos procesos, con un enfoque en la recuperación automática en la mayoría de los escenarios. Estos procesos también deben probarse ampliamente.

• Implemente el control de versiones para las API. Administre los cambios en el modelo de datos cuidadosamente para garantizar la compatibilidad con versiones anteriores. Una estrategia de control de versiones de API ayuda a los sistemas existentes a seguir ejecutándose sin problemas después de implementar los cambios. El control de versiones retrospectivas puede resultar complicado, por lo que es recomendable definir una estrategia desde el principio.

• Implementar actualizaciones incrementales. En el nivel 3, los procesos de implementación se estandarizan mediante canalizaciones automatizadas en todos los entornos. En el nivel 4 de madurez, la carga de trabajo está en producción. El enfoque cambia a refinar las actualizaciones incrementales, incluida la administración de ciclos de versión.

  Implemente actualizaciones pequeñas y frecuentes para simplificar la validación de un pequeño conjunto de cambios. Automatice tareas de validación como pruebas de carga, implementación para probar entornos y pruebas A/B.

  Nota:

  Los patrones de implementación seguros, como las implementaciones canary y blue-green, proporcionan flexibilidad y confiabilidad a través de implementaciones en paralelo. Por ejemplo, en implementaciones azul-verde, se crea un nuevo entorno, se desplaza el tráfico y se retira el entorno anterior. Otras técnicas de implementación incluyen marcas de características e inicios oscuros. Estos enfoques permiten realizar pruebas en producción antes de que los cambios se implemente en todos los usuarios. Esta funcionalidad está disponible con servicios específicos de Azure, como Azure App Service, donde las actualizaciones se pueden implementar gradualmente mediante el intercambio gradual entre ranuras de implementación.

• Recuperarse de errores de implementación. Tenga en cuenta que se producirán errores en algunas actualizaciones. Con las actualizaciones incrementales, la solución de problemas se vuelve más rápida cuando se producen problemas. Si se produce un error, detenga el sistema para evitar daños adicionales e implementar cambios para corregir el problema. La restauración a partir de copias de seguridad es aceptable si mantiene la continuidad. El objetivo es avanzar a una versión estable en lugar de confiar únicamente en procedimientos de reversión.

✓ Optimizar las operaciones de compilación

En el nivel 3, debe tener ciclos de implementación independientes para diferentes capas de la arquitectura en función de su tasa de cambio. Como mínimo, mantenga las canalizaciones de infraestructura y código.

Ahora que la carga de trabajo está en producción, reconsidere el enfoque de capas. Si es posible, se deben desacoplar aún más los componentes arquitectónicos para permitir cadencias de lanzamiento más flexibles. Este enfoque reduce los retrasos y minimiza los errores en componentes individuales. Además, ejecute pruebas y procesos de ejecución prolongada como trabajos paralelos para ahorrar tiempo y mejorar la productividad del desarrollador.

✓ Validar procesos de respuesta a incidentes

En el nivel 3, se establece un sistema de soporte técnico bajo demanda con guías de respuesta para definir respuestas a incidentes. Sin embargo, tener un cuaderno de estrategias es solo el primer paso. Ahora que la carga de trabajo está en producción, debe validar y mejorar la eficacia del proceso de administración de incidentes y desarrollar un plan de comunicación sólido. Tenga en cuenta los procedimientos siguientes:

• Pruebe las respuestas a incidentes. Incorpore respuestas de tecnología, personas y procesos. Para introducir realismo en los esfuerzos de validación, te recomendamos que ejecutes días de juego. Los días del juego son eventos planeados en los que se introducen errores para probar la capacidad del equipo para detectar y resolver problemas. Este enfoque garantiza que el equipo tenga las herramientas, los recursos y los procedimientos adecuados implementados. La ingeniería de caos es otra técnica valiosa que introduce interrupciones controladas para observar los resultados. Como alternativa, también se pueden usar métodos manuales, como deshabilitar los back ends en un load balancer de carga global o realizar una conmutación por error de base de datos, para probar la respuesta.

• Desarrollar un plan de comunicación. Defina claramente las responsabilidades de comunicación en el equipo de cargas de trabajo, los equipos de soporte técnico y el personal de respuesta de emergencia. Estandarizar la cadencia y el formato de las actualizaciones de estado interno a las partes interesadas del negocio fomentan la transparencia y la confianza. En escenarios específicos, como infracciones de seguridad, se requiere la divulgación responsable a los usuarios finales. Asegúrese de que el tipo y el nivel de información adecuados se definen claramente en estas comunicaciones externas.

• Realice una revisión de incidentes. Trate cada incidente como una oportunidad para aprender de producción. Use este proceso para identificar debilidades en los procesos de implementación y desarrollo y confirmar la realización de mejoras del sistema.

✓ Optimizar las operaciones mediante el uso de datos de supervisión de producción

En el nivel 4, la supervisión avanzada debe emitir, correlacionar y analizar métricas dentro de un contexto empresarial. En este nivel, mejore su precisión aprendiendo del entorno de producción. Use los datos de supervisión para refinar los procesos basados en las mejores estimaciones. Tenga en cuenta los siguientes ejemplos clave:

• El enfoque principal en el nivel 3 es desarrollar un modelo de salud para la carga de trabajo. En el nivel 4, ajuste el sistema de alertas y establezca objetivos realistas e indicadores de nivel de servicio.

• Como parte de las operaciones del día 2, minimizar el desfase de configuración debe ser una prioridad clave. Sin este enfoque, el entorno en tiempo de ejecución podría diferir gradualmente de su estado previsto. Comience capturando una instantánea de la configuración correcta conocida. A continuación, aproveche las métricas de observabilidad de producción para comparar el comportamiento actual con esa línea de base. Este enfoque garantiza la alineación continua con el estado del sistema previsto.

• Este nivel es ideal para introducir bucles de retroalimentación para comprender mejor cómo se comporta el sistema bajo factores de estrés específicos y predecir el impacto de los nuevos elementos. La telemetría del sistema guía estos bucles de retroalimentación al proporcionar información clave que ayuda a pronosticar los cambios de carga de trabajo y a dar forma a soluciones proactivas frente a posibles problemas. También puede usar estos datos para ayudarle a priorizar la deuda técnica.

Como práctica general, ajuste la pila de supervisión en función de los datos y patrones de observabilidad en producción. Tenga en cuenta los procedimientos siguientes:

• Ajuste los niveles de registro para equilibrar la visibilidad y el ruido para capturar actividades en las rutas críticas.

• Amplifica las alertas importantes al suprimir las irrelevantes.

✓ Automatizar el mantenimiento

En el nivel 3, los esfuerzos de automatización se centran principalmente en la implementación en producción. En el nivel 4, los equipos han reducido significativamente el trabajo manual mediante la automatización de procesos de compilación, prueba e implementación mediante canalizaciones de integración continua y entrega continua. Al igual que con las puertas de calidad, las aprobaciones específicas también se pueden administrar a través de flujos de trabajo automatizados.

En el nivel 4, la automatización operativa debe estar controlada por la experiencia de producción del mundo real y centrarse en abordar la deuda técnica.

Tenga en cuenta los siguientes ejemplos de automatización del día 2.

El objetivo principal es identificar tareas repetitivas controladas por humanos que podrían haberse pasado por alto en fases anteriores debido a las fechas límite. Pero no debería automatizar todo. La rentabilidad de la inversión debe guiar la automatización. Prefiere usar tecnologías y conocimientos existentes en lugar de empezar con herramientas completamente nuevas. Si se necesitan herramientas ligeras, evalúe su ciclo de vida y sus requisitos de mantenimiento.

✓ Mejorar la eficiencia mediante la alineación de herramientas y procesos con estándares de la organización

En la madurez del nivel 4, céntrese en obtener eficiencia operativa mediante la evaluación de los recursos y procesos de ingeniería. Identifique qué recursos son esenciales, pero no básicos para su negocio.

Para estos recursos, tenga en cuenta los siguientes puntos:

• Use herramientas compartidas que ya están disponibles en su organización.

• Considere el software que no es de Microsoft para tareas específicas, como la conversión de datos.

Los recursos creados previamente incluyen canales de soporte técnico y pueden reemplazar soluciones personalizadas. Este enfoque reduce la carga operativa de las soluciones creadas por el equipo. Evalúe el estado de estos recursos para satisfacer sus necesidades e identifique las brechas restantes.

Explore las siguientes áreas de la carga de trabajo:

• Evalúe el código personalizado. En lugar de escribir código personalizado para tareas como el análisis, evalúe las soluciones de código abierto que se consideran estándar del sector. El uso de estas herramientas puede reducir la necesidad de mantenimiento de código y dar lugar a una base de código más pequeña. Explore las opciones que ya están disponibles en su organización. Puede haber bibliotecas existentes que puede integrar en la carga de trabajo para controlar tareas rutinarias como la autenticación.

• Evalúe la cadena de herramientas. Evalúe las áreas en las que puede confiar en otros equipos que usan herramientas similares. Ajuste el uso de bibliotecas, plantillas y módulos en consecuencia. Alinee las herramientas de infraestructura como código en toda la organización para simplificar las operaciones.

• Evalúe los procesos. Identifique los procesos centralizados que pueden realizar tareas que puede haber implementado usted mismo, como el examen de seguridad. En lugar de administrar su propio proceso de cuarentena para paquetes NuGet, use el proceso del equipo de seguridad existente de la organización informándoles de los módulos usados en la carga de trabajo.

  La compatibilidad es otra área clave. Al principio, los equipos de desarrollo suelen encargarse del soporte técnico mediante la supervisión de métricas y la corrección de problemas en directo. En esta fase, considere la posibilidad de establecer roles dedicados como ingenieros de guardia. Si su organización tiene un equipo de soporte técnico compartido, úselo para reducir la carga de soporte técnico en los desarrolladores.

  Nota:

  Si es posible, realice la transición de soporte diario a proveedores externos. Los proveedores no tienen contexto profundo como el equipo de desarrollo o los arquitectos que llevan la carga de trabajo a producción. Antes de entregar tareas a un proveedor, asegúrese de que el sistema es estable en producción y defina claramente las tareas de administración. Los proveedores necesitan elementos clave para tener éxito. Defina umbrales en el modelo de salud que representen Saludable, No saludable, y Degradado. Entrene proveedores en cuadernos de estrategias, herramientas y otros recursos de solución de problemas. Si no pueden identificar las causas, establezca rutas bien definidas para escalar y derivar problemas al equipo de gestión de carga.

✓ Administrar la deuda técnica a una cadencia regular

La deuda técnica es el resultado de los atajos que se toman durante el desarrollo para cumplir con los plazos, lo que puede resultar en implementaciones menos que ideales. Los equipos deben trabajar para reducir esta deuda mediante el análisis de la complejidad y el tiempo de mantenimiento. Si no se aborda la deuda técnica, los sistemas pueden ser más complejos y más difíciles de mantener o escalar. Esta complejidad ralentiza la innovación a medida que los desarrolladores pasan más tiempo solucionando problemas en lugar de trabajar en nuevas características.

Tenga en cuenta las siguientes recomendaciones tácticas para controlar la deuda técnica:

• Haga un seguimiento de la deuda técnica junto con el desarrollo de características.

• Reserve la capacidad en cada sprint para abordar la deuda técnica, independiente del desarrollo de características. En ocasiones, dedique sprints completos a abordar la deuda técnica.

• Agregue la resolución propuesta al trabajo pendiente inmediatamente si tiene previsto incurrir en nuevas deudas técnicas para nuevas características.

La deuda técnica es una parte normal del desarrollo y una oportunidad para mejorar. A medida que se agregan nuevas características, la deuda se acumula. Equilibre el esfuerzo de pagar las deudas antiguas con las nuevas, asociadas al desarrollo de características innovadoras.

Continúa mejorando y adaptando, pero nunca supongas que has terminado.

Establezca una carga de trabajo bien diseñada en Azure a medida que avance a través de los niveles 1 a 4. El diseño configura prácticas operativas como la supervisión, las pruebas, la implementación y la automatización, que prepara el sistema para producción. Una vez que el sistema está en producción, se centra en estabilizar las operaciones y administrar los cambios para proteger la experiencia del usuario.

En la fase final, la madurez significa operar la carga de trabajo a escala, lo que la mantiene confiable y actualizada. También requiere competencia en la identificación de áreas en las que el diseño actual ha alcanzado sus límites y la preparación de los cambios en los requisitos empresariales. Las suposiciones sobre las restricciones pueden quedar obsoletas a medida que evoluciona el ecosistema. Mantener la estática puede dar lugar a la regresión porque los entornos, las prácticas y las herramientas siguen evolucionando. Sin inversión en los enfoques de nivel 5, su carga de trabajo corre el riesgo de quedarse atrás.

El nivel 5 no es un objetivo final ni un punto de control técnico. Es un cambio de mentalidad centrado en modernizar la cultura, los procesos, las herramientas y la tecnología. Las operaciones se tratan con el mismo rigor, inversión e innovación que recibe la aplicación del entorno de trabajo.

Estrategias clave

✓ Oportunidades de rediseño puntuales basadas en el crecimiento observado y potencial futuro

Las arquitecturas de carga de trabajo están diseñadas intencionadamente con restricciones y tienen una vida útil limitada. A través del nivel 4, la arquitectura probablemente cumpla los requisitos empresariales de forma eficaz. En este nivel, evalúe cómo el sistema controla los nuevos patrones de uso, tecnologías, crecimiento y desafíos operativos.

Por ejemplo, una solución que funciona para miles de usuarios podría producir un error cuando se escalaba a decenas de miles. Un mayor volumen de datos puede introducir problemas de atomicidad, mientras que una mayor demanda de rendimiento y cumplimiento puede empujar la arquitectura a sus límites. Estas presiones pueden impedir la entrega de nuevas funcionalidades y crear cuellos de botella para aumentar la capacidad.

En este nivel, reconozca los puntos de inflexión e identifique las áreas donde podría necesitar rediseñar. Tenga en cuenta las siguientes áreas:

• Es posible que la elección inicial de herramientas, marcos y servicios de plataforma se adapte a sus necesidades empresariales. Sin embargo, a medida que evoluciona el sistema, estas herramientas podrían estar rígidas o estrechamente acopladas, las bibliotecas podrían carecer de extensibilidad y los servicios de plataforma podrían alcanzar el final del ciclo de vida, lo que interrumpe las dependencias existentes.

  Explore herramientas y servicios dentro del ecosistema más amplio que proporcionen un sólido apoyo y una adopción generalizada de la comunidad. Seleccione una arquitectura modular y acoplada flexible para facilitar la sustitución o las actualizaciones.

• En niveles anteriores, el equipo de cargas de trabajo podría administrar toda la pila técnica. Este enfoque puede ser eficaz inicialmente, pero a menudo da lugar a una mayor presión y sobrecarga operativa a medida que el sistema se escala. Para facilitar esta carga, considere la posibilidad de descargar responsabilidades a equipos especializados, como los centrados en redes, seguridad o observabilidad. Su experiencia permite al equipo principal de cargas de trabajo centrarse en ofrecer valor de producto.

• La administración de instancias dedicadas al cliente (o de un solo inquilino) puede aumentar tanto el costo como la sobrecarga operativa. Este desafío suele indicar la necesidad de adoptar una arquitectura multiinquilino. Este cambio requiere inversiones operativas y arquitectónicas más amplias, como controlar la incorporación de inquilinos y el aislamiento de acceso a datos.

• Reformule su estrategia de implementación para escalar de manera predecible y gestionar el aislamiento de fallos y el rendimiento a gran escala. Explore prácticas probadas como el patrón de sellos de implementación.

  • Una unidad de escalado es un grupo lógico de recursos que se escalan juntos para manejar el aumento de la carga mientras se supervisan de forma independiente. Estas unidades se implementan automáticamente como bloques repetibles en función de umbrales definidos y se pueden replicar cuando sea necesario.

    Sin embargo, este enfoque puede dar lugar a un escalado de servicios específicos, lo que da como resultado costos agregados.

    Para obtener más información, consulte Arquitectura de unidad de escalado.

  • Los entornos inmutables son configuraciones de implementación en las que los sistemas nunca se modifican después de la implementación. En lugar de actualizar un sello de implementación existente, desmonte el sello anterior y vuelva a implementarlo con los cambios necesarios. Este enfoque requiere modelos de implementación en paralelo, como implementaciones azul-verde. Para adoptar esta práctica, las canalizaciones deben estar preparadas para desplegar automáticamente una nueva instancia para gestionar el hiperescalamiento o reemplazar unidades defectuosas.

    Las prácticas de implementación segura de Nivel 4 deberían prepararte para esta transición. No debe haber regresión y los usuarios deben realizar la transición a la nueva marca sin problemas.

✓ Uso de la automatización para reducir aún más la fricción

La transición de nivel 4 a nivel 5 no solo se trata de aumentar la automatización. También se trata de usar la automatización para reducir la fricción y decidir cuándo se deben ejecutar estas tareas.

Tenga en cuenta los ejemplos siguientes:

• Creación automatizada de entornos de desarrollador locales: Proporcione una experiencia estandarizada configurando cada estación de trabajo de desarrollador con el mismo conjunto de herramientas, versiones de biblioteca y otros recursos de desarrollo. Esta coherencia proporciona a todos los desarrolladores acceso a un entorno uniforme, independientemente del nivel de experiencia. También facilita una mejor colaboración, el uso compartido de conocimientos y la incorporación. Use entornos de desarrollo virtualizados para simplificar este proceso.

• Flujos de trabajo automatizados de evaluación y resolución de alertas: Use la automatización para clasificar y priorizar alertas basadas en reglas predefinidas y desencadenar flujos de trabajo de resolución. Para las alertas de alta prioridad, el sistema puede notificar al equipo pertinente e iniciar el proceso de resolución para acelerar los tiempos de respuesta.

• Corrección automatizada de incidentes: Implemente scripts de recuperación automática que reinicien automáticamente los servicios o cambien las cargas de trabajo cuando se detecten problemas. Por ejemplo, si un servidor web se bloquea, un script puede reiniciar el servicio o redirigir el tráfico a un servidor de copia de seguridad para minimizar el tiempo de inactividad.

• Uso automatizado de recursos: A medida que avanza la madurez en otros pilares, es probable que tenga que introducir la automatización para apoyar sus objetivos. Por ejemplo, puede programar recursos y entornos no críticos durante las horas de poca actividad para reducir los costos y optimizar el uso de recursos.

• Administración automatizada de inquilinos: Optimice la incorporación y retirada de inquilinos en entornos multiinquilino. Cuando se registra un nuevo inquilino, la automatización puede crear cuentas de usuario, aprovisionar recursos y configurar las opciones.

✓ Crear entornos de desarrollador para cada característica o cambio

Las operaciones del día 2 se centran en implementar cambios seguros. Cada cambio pasa por entornos diferentes que se configuran con fines específicos, como desarrollo, pruebas y seguridad. Al seguir las instrucciones de nivel 4, se supone que ha automatizado la creación de esos entornos.

A diferencia de los niveles 1 a 4, que se centran en examinar internamente la preparación de producción y administrar el cambio de carga de trabajo, el nivel 5 es una oportunidad para que el equipo de cargas de trabajo comparta sus diseños, éxitos, errores con otras cargas de trabajo en toda la organización. Los equipos de carga de trabajo no necesitan experimentar errores por sí mismos para aprender a evitarlo si pueden aprender de forma preventiva de otros que han ido antes que ellos.

✓ Compartir conocimiento y contribuir a la madurez de la organización

Los niveles 1 a 4 se centran en la preparación interna y la administración del cambio de carga de trabajo. El nivel 5 es diferente porque crea una oportunidad para que los equipos de cargas de trabajo compartan sus diseños, éxitos y errores con otros equipos de toda la organización. Un equipo no tiene que experimentar errores de primera mano si puede aprender de otros que han experimentado desafíos similares.

Este cambio implica la transición de principios de excelencia operativa en el nivel de carga de trabajo individual a la organización que invierte en operaciones centralizadas. Estos equipos centralizados se componen de grupos de ingeniería dedicados que crean herramientas de implementación equipadas con barreras de protección, automatización, observabilidad y pruebas.

El equipo de cargas de trabajo debe compartir técnicas, herramientas e información que han sido eficaces con los equipos del mismo nivel. Comience por interactuar con los equipos de los que depende la carga de trabajo. Después, conéctate con los equipos que dependen de tu carga de trabajo. A medida que comparte experiencias y resultados, aprenda de esos equipos. Debería ver un mayor uso compartido de conocimientos a través de plataformas compartidas, documentación y involucración de la comunidad.

✓ Habilite las capacidades de autoservicio en las distintas funciones de trabajo.

A medida que experimenta tareas repetitivas y no planificadas dentro de las responsabilidades rutinarias de desarrollo de la carga de trabajo, evalúe si, en cambio, deberían entregarse como soluciones automatizadas que los miembros del equipo puedan invocar cuando sea necesario. Crear y mantener funcionalidades de autoservicio para estas tareas no planeadas para mejorar la agilidad y la autonomía del equipo.

Comience con tareas no planeadas que consumen mucho tiempo o propensas a errores que son rentables para entregar al equipo de carga de trabajo como una solución de autoservicio. La solución debe optimizar el tiempo de los miembros del equipo y crear coherencia en estas tareas. Este enfoque da como resultado una rentabilidad de la inversión durante la vida útil de la solución de autoservicio.

Siga el enfoque y las funcionalidades que se describen en Iniciar el recorrido de ingeniería de la plataforma.