Informes de problemas y características de solicitud para Azure Linux

En este artículo se explica cómo notificar errores, problemas de documentación y vulnerabilidades de seguridad y cómo solicitar nuevas características para Azure Linux. Siguiendo las instrucciones que se indican aquí, se garantiza que los problemas y las solicitudes se enrutan a los canales correctos y se pueden solucionar de forma eficaz.

Importante

Azure Linux es de código abierto, pero los compromisos de soporte técnico y ciclo de vida de Microsoft solo se aplican a escenarios de Azure. Específicamente:

  • Se admiten Azure Linux Virtual Machines (VM) / Virtual Machine Scale Sets, el host de contenedores de AKS y las imágenes de contenedor.
  • No se admiten bare metal, imágenes ISO, entornos on-premises ni otras nubes.
  • Las imágenes personalizadas solo se admiten cuando se basan en una imagen de Linux precompilada Azure (por ejemplo, con Image Customizer). Las imágenes creadas desde cero a partir del código fuente de Azure Linux en GitHub no están cubiertas.

Es posible que se cierren incidencias fuera de este ámbito.

Note

Azure Linux 4.0 está ahora en preview y está estrictamente limitado a fines de evaluación y pruebas. No es adecuado para su uso en producción.

Antes de archivar

  • Busque problemas existentes para ver si el problema ya se ha notificado. Si encuentra un problema existente que coincida con el escenario, agregue una reacción de pulgar hacia arriba (👍) e incluya cualquier contexto adicional en un comentario. Esto nos ayuda a priorizar sin crear duplicados.
  • Consulte la imagen más reciente de Azure Linux y los últimos parches para ver si el problema ya se ha corregido en una versión más reciente antes de notificar una incidencia nueva.

Dónde se va a archivar

Tipo de solicitud o problema Dónde se va a archivar
Problemas de producción o interrupciones Si experimenta un problema técnico que afecta a la carga de trabajo de Azure, abrir una solicitud de Soporte técnico de Azure a través del portal de Azure. Las incidencias de GitHub no se monitorizan para el soporte de producción.
Informes de errores, problemas de documentación, solicitudes de características Incidencias de GitHub utilizando la plantilla de incidencia adecuada en el repositorio correcto.
Vulnerabilidades de seguridad Siga las instrucciones de Administración de CV. Por favor, no notifiques vulnerabilidades de seguridad a través de incidencias públicas de GitHub.

Cómo escribir un buen informe de errores

Importante

Al abrir un informe de errores en GitHub, una plantilla de problema rellenada previamente le guiará a través de estos campos. Use la plantilla para proporcionar toda la información solicitada. Por favor, llene completamente. Es posible que se cierren informes incompletos.

Cuanto más pequeño y autónomo sea su caso de reproducción, más rápido se podrá evaluar. Intente aislar el problema de las dependencias o la configuración no relacionadas.

Un buen informe de errores ayuda a los mantenedores a reproducir y corregir el problema más rápido. En el informe, incluya la siguiente información:

  • Versión de Azure Linux y nombre de la imagen: por ejemplo, AzureLinux 4.0 AKS node image 2026.05.
  • Pasos para reproducir: Pasos numerados y específicos que otra persona puede seguir.
  • Comportamiento esperado frente al comportamiento real.
  • Registros: registros pertinentes del sistema o de la aplicación que muestran el error o el comportamiento inesperado.
  • Environment details: servicio Azure (AKS, VM, Virtual Machine Scale Sets, etc.), tamaño/SKU de máquina virtual, región, configuración de red y cualquier modificación de imagen o paquete personalizada.
  • Capturas de pantalla o salida de terminal en las que resulta útil (pegar texto, no imágenes de texto).

Exclusiones del triaje

Para que la priorización siga siendo manejable, se cerrarán los siguientes tipos de incidencias:

  • Problemas relacionados con escenarios fuera de los compromisos de soporte técnico y del ciclo de vida de Microsoft, incluidos:
  • Informes incompletos que faltan pasos de reproducción, información de versión o detalles del entorno.
  • Problemas duplicados: agregue un pulgar hacia arriba (👍) en el problema existente en su lugar.
  • Solicitudes de funcionalidades sin un caso de uso claro de Azure o justificación empresarial.
  • Preguntas relacionadas con la producción que deben dirigirse a un canal de soporte técnico oficial: consulte la guía de las opciones de soporte técnico oficial de Azure Linux para saber cuál es la forma adecuada de obtener ayuda con problemas de producción.

Qué ocurre después de presentar la solicitud

  • La evaluación se realiza de la mejor manera posible. Los mantenedores evalúan incidencias si lo permite la capacidad. No hay acuerdos de nivel de servicio garantizados en problemas presentados por la comunidad.
  • Los problemas se pueden etiquetar para el seguimiento (por ejemplo, bug, docs, upstream, help-wanted).
  • Los problemas se pueden redirigir a un proyecto ascendente o a Fedora cuando esa sea la ruta de control correcta.
  • Las incidencias que estén fuera del alcance, carezcan de detalles clave o no permitan actuar podrían cerrarse sin explicación.
  • Priorizamos los problemas que afectan al uso de Azure Linux en Azure y que incluyen detalles que permiten reproducirlos.
  • Es posible que los problemas sin actividad durante 30 días se cierren automáticamente.

Contenido relacionado

  • Last updated on