https://docs.microsoft.com/es-es/learn/modules/choose-azure-services-sla-lifecycle/
Unidad 1: Introducción
En este módulo, obtendrá información sobre los acuerdos de nivel de servicio (SLA) en Azure y cómo pueden afectar a las decisiones sobre el diseño de las aplicaciones. También conocerá el ciclo de vida de los nuevos servicios de Azure, desde la versión preliminar hasta su disponibilidad general.
¿Qué efecto tendrá el pasaje a la nube en los acuerdos de disponibilidad?
La transición a la nube elimina la carga que supone dar soporte a la infraestructura de TI. Cuando se pierde la conectividad de red o se produce un error en una unidad de disco duro, el proveedor de servicios en la nube se encarga de restaurar el servicio.
El Departamento de TI de Tailwind Traders hospeda en su centro de datos aplicaciones y servicios del resto de la empresa. Este departamento mantiene acuerdos en vigor con otros equipos en los que se estipula la disponibilidad de los servicios, lo que incluye cuándo y cómo se puede producir el mantenimiento planeado. Dado que Tailwind Traders mueve sus cargas de trabajo a Azure, la empresa deja de tener el control total del hardware y las redes. ¿Cómo se verán afectados los acuerdos de disponibilidad?
Unidad 2: ¿Qué son los acuerdos de nivel de servicio (SLA)?
Video
- Los Acuerdo de Nivel de Servicio SLA
- Es el acuerdo formal entre el proveedor de servicio y el cliente que garantiza el nivel de servicio
- Puede ser por ejemplo entre Microsoft y un cliente
- Pero también existen en las organizaciones por ejemplo entre el departamento de TI y sus usuarios
- En Azure estos SLA se representan en porcentaje (%) relacionada a la disponibilidad del servicio
- Esta disponibilidad se le conoce como Up Time
- Es decir que si el servcios esta disponible al 100% se tiene un 100% de Up time
- En los acuerdos se definen muchos términos entre ellos Down Time que es cuando el servicio no esta disponible
- Así como cualquier crédito que usted recibiría si el SLA no se cumple
- Y realmente lograr un 100% es muy difícil y caro ya que
- Se requiere tiempo para realizar mantenimiento de los equipos o actualizaciones
- Replicar cada componente encaso de que alguno falle
- Y muchas tareas de respaldo
- Por esto las SLA se dan en porcentajes de
- Existe una diferencia de un SLA de 99% a 99.9%?
- Si un servicio con 99% puede estar abajo por 1.68hrs por semana, o 7.2hrs por mes
- Y esto ocurre a lo largo del tiempo
- Un servicio con 99.9% solo son 10 minutos por semana o 43.2 minutos por mes
- es una gran diferencia
- Si el servicio es crítico para se empresa, minutos en vez de horas puede hacer una gran diferencia
- Pero tiene su costo
- Todos los servicios de Azure tienen su SLA
Continuamos
Como se ha mencionado en el vídeo, un Acuerdo de Nivel de Servicio (SLA) es un contrato formal entre una empresa de servicios y el cliente. En Azure, este acuerdo define los estándares de rendimiento que Microsoft se compromete a proporcionar al cliente.
En este artículo, obtendrá más información sobre los acuerdos de nivel de servicio de Azure: por qué son importantes, dónde puede encontrar el SLA de un servicio de Azure específico y qué incluye un SLA típico.
¿Por qué son importantes los acuerdos de nivel de servicio?
La comprensión del acuerdo de nivel de servicio de los servicios de Azure que use le ayudará a conocer las garantías que puede esperar.
La disponibilidad de los servicios que usa afecta al tiempo de actividad y en el rendimiento de las aplicaciones que se compilan en Azure. Comprender los acuerdos de nivel de servicio implicados puede ayudarle a definir el acuerdo de nivel de servicio que establezca con sus clientes.
¿Dónde puedo acceder a los acuerdos de nivel de servicio de los servicios de Azure?
- Puede acceder a los acuerdos de nivel de servicio desde Contratos de nivel de servicio.
Cada servicio de Azure define su propio acuerdo de nivel de servicio. Los servicios de Azure están organizados por categoría.
Abra el acuerdo de nivel de servicio de Azure Database for MySQL, una base de datos administrada que facilita a los desarrolladores el trabajo con bases de datos MySQL. En breve volveremos a este acuerdo de nivel de servicio.
Para ello:
- Vaya a Contratos de nivel de servicio.
- En la categoría Bases de datos, seleccione Azure Database for MySQL.
¿Qué incluye un acuerdo de nivel de servicio típico?
Un acuerdo de nivel de servicio típico cuenta con estas secciones:
- IntroducciónEn esta sección se explica qué esperar del acuerdo de nivel de servicio, por ejemplo, su ámbito y la repercusión que las renovaciones de suscripción pueden tener en las condiciones del acuerdo.
- Términos generalesEsta sección contiene los términos empleados en todo el acuerdo de nivel de servicio, de modo que ambas partes (el cliente y Microsoft) entiendan y compartan el mismo vocabulario. Por ejemplo, en esta sección se puede definir el significado de tiempo de inactividad, incidentes y códigos de error.En esta sección también se definen las condiciones generales del acuerdo, que incluyen una explicación de cómo enviar una demanda o recibir créditos por cualquier problema de rendimiento o disponibilidad, así como las limitaciones del acuerdo.
- Detalles del Acuerdo de Nivel de ServicioEn esta sección se definen las garantías específicas del servicio. Los compromisos de rendimiento se miden normalmente en porcentajes, que normalmente están comprendidos entre el 99,9 % («tres nueves») y el 99,99 % («cuatro nueves»).Por lo general, el compromiso de rendimiento principal se centra en el tiempo de actividad, es decir, en el porcentaje de tiempo que un producto o servicio está operativo y sin problemas. Algunos acuerdos de nivel de servicio se centran también en otros factores, como la latencia o la rapidez con la que el servicio debe responder a una solicitud.En esta sección también se definen las condiciones adicionales que son específicas de este servicio.
Dedique un momento a leer el acuerdo de nivel de servicio de Azure Database for MySQL.
Verá que este acuerdo de nivel de servicio se centra en el tiempo de actividad. Azure Database for MySQL garantiza un tiempo de actividad del 99,99 % («cuatro nueves»). Esto significa que se garantiza que el servicio se ejecutará y estará disponible para procesar las solicitudes el 99,99 % del tiempo.
¿Qué relación hay entre los porcentajes y el tiempo de inactividad total?
El tiempo de inactividad es el período de tiempo que el servicio no está disponible.
La diferencia entre el 99,9 % y el 99,99 % puede parecer pequeña, pero es importante comprender lo que significan estos números en cuanto al tiempo de inactividad total.
En esta tabla se ofrece una idea de cómo se reduce el tiempo de inactividad total a medida que el porcentaje del acuerdo de nivel de servicio aumenta del 99 % al 99,999 %:
Estas cantidades son acumulativas, lo que significa que la duración de varios cortes de servicio diferentes se combina o se suma.
¿Qué son los créditos de servicio?
Un crédito de servicio es el porcentaje del precio que ha pagado que se le abonará conforme al proceso de aprobación de reclamaciones.
Un acuerdo de nivel de servicio describe la respuesta dada por Microsoft cuando un servicio de Azure no opera según su especificación. Por ejemplo, puede obtener un descuento compensatorio en su factura de Azure si un servicio no funciona conforme al acuerdo de nivel de servicio.
Por lo general, los créditos aumentan a medida que el tiempo de actividad se reduce. A continuación, se muestra cómo se aplican los créditos de Azure Database for MySQL según el tiempo de actividad:
¿Cuál es el acuerdo de nivel de servicio de los servicios gratuitos?
Normalmente, los productos gratuitos no tienen un acuerdo de nivel de servicio.
Por ejemplo, muchos servicios de Azure proporcionan un nivel gratuito o compartido que ofrece una funcionalidad más limitada. Los servicios como Azure Advisor siempre son gratis. El acuerdo de nivel de servicio de Azure Advisor indica que, al ser gratuito, no tiene un acuerdo de nivel de servicio con respaldo financiero.
¿Cómo se puede saber cuándo se produce una interrupción en el servicio?
Estado de Azure proporciona una visión global del estado de los servicios y las regiones de Azure. Si sospecha que hay una interrupción, suele ser un buen lugar para comenzar a investigar.
El estado de Azure proporciona una fuente RSS con los cambios de estado de los servicios de Azure a los que puede suscribirse. Esta fuente puede conectarse a software de comunicación como Microsoft Teams o Slack.
Desde la página estado de Azure también puede acceder a Azure Service Health, que proporciona una vista personalizada del estado de los servicios y las regiones de Azure que está usando, directamente desde Azure Portal.
¿Cómo puedo solicitar un crédito de servicio a Microsoft?
Normalmente, deberá presentar una reclamación a Microsoft para recibir un crédito de servicio. Si adquiere los servicios de Azure de un partner proveedor de soluciones en la nube (CSP), este suele encargarse de administrar el proceso de reclamación.
Cada acuerdo de nivel de servicio especifica el plazo en el que se debe enviar la reclamación y el plazo para que Microsoft la procese. En muchos servicios, la reclamación debe enviarse antes de que finalice el mes natural siguiente al mes en el que se produjo el incidente.
A continuación, veamos algunos otros factores que Tailwind Traders necesita tener en cuenta y que podrían afectar a los objetivos de rendimiento del acuerdo de nivel de servicio.
Unidad 3: Definición del acuerdo de nivel de servicio de la aplicación
Un acuerdo de nivel de servicio de la aplicación define los requisitos del acuerdo para una aplicación específica. Este término normalmente hace referencia a una aplicación que el cliente compila en Azure.
Tailwind Traders ejecuta una aplicación basada en Azure denominada «Pedidos Especiales». La aplicación realiza un seguimiento de los pedidos especiales que los clientes han hecho en las tiendas físicas de la empresa. Un pedido especial incluye un artículo y todos los elementos personalizados que necesita el cliente. Por ejemplo, una puerta plegable podría incluir personalizaciones como la dimensión y la colocación de bisagras. Dado que las personalizaciones suelen requerir un tratamiento especial, el artículo personalizado debe pedirse al proveedor cuando lo necesita un cliente.
Hay muchas decisiones de diseño que se pueden tomar para mejorar la disponibilidad y la resistencia de las aplicaciones y los servicios que se crean en Azure. Estas decisiones quedan fuera del acuerdo de nivel de servicio para un servicio específico. En esta parte, se analizarán algunas de estas consideraciones.
Un buen punto de partida es debatir en equipo sobre la importancia que tiene para el negocio la disponibilidad de cada aplicación. En las secciones siguientes se tratan algunos de los factores que Tailwind Traders podría considerar.
Impacto empresarial
Si la aplicación Pedidos Especiales se bloquea, ¿cómo repercutiría esto en la empresa? En este caso, los clientes no podrían realizar nuevos pedidos a través de la tienda y el personal no podría comprobar el estado de los pedidos existentes. Los clientes tendrán que intentarlo de nuevo más tarde o posiblemente acudirán a la competencia.
Repercusión en otras operaciones empresariales
La aplicación Pedidos Especiales no afecta a otras operaciones. Por lo tanto, la mayor parte del negocio de Tailwind Traders seguirá funcionando con normalidad, aunque la aplicación Pedidos Especiales deje de funcionar.
Patrones de uso
Los patrones de uso definen cuándo y cómo acceden los usuarios a la aplicación.
Una cuestión que debe tenerse en cuenta es si el requisito de disponibilidad difiere entre períodos de tiempo críticos y no críticos. Por ejemplo, una aplicación de declaración de impuestos no puede tener un error justo antes de una fecha límite de presentación.
En el caso de Tailwind Traders, las tiendas minoristas no están abiertas las 24 horas del día, por lo que, si la aplicación deja de funcionar durante la noche, el impacto será mínimo. No obstante, dado que Tailwind Traders tiene tiendas minoristas en todo el mundo, la empresa tendrá que asegurarse de que cada ubicación tenga acceso al servicio durante su horario comercial.
¿Qué decide el equipo?
Supongamos que Tailwind Traders decide que un acuerdo de nivel de servicio del 99,9 % es aceptable para la aplicación Pedidos Especiales. Esto le da a la empresa un tiempo de inactividad estimado de 10,1 minutos por semana. Pero ¿cómo se asegurará de que sus opciones de tecnología estén cubiertas por el acuerdo de nivel de servicio de la aplicación?
En la parte siguiente veremos cómo el equipo asocia los requisitos de la aplicación con servicios de Azure específicos. Conocerá algunas de las técnicas que puede usar para ayudar a garantizar que las opciones de tecnología cumplan con el acuerdo de nivel de servicio de la aplicación.
Unidad 4: Diseño de la aplicación para satisfacer el acuerdo de nivel de servicio
Tailwind Traders decide que un acuerdo de nivel de servicio del 99,9 % es aceptable para la aplicación Pedidos Especiales. Recordemos que esto le da a la empresa un tiempo de inactividad estimado de 10,1 minutos por semana.
Ahora hay que diseñar una solución eficaz y confiable para esta aplicación en Azure, teniendo en cuenta el acuerdo de nivel de servicio de la aplicación. Habrá que seleccionar los productos y servicios de Azure y aprovisionar los recursos según esos requisitos.
Es inevitable que haya problemas. Pueden producirse errores de hardware. La red puede tener períodos intermitentes en los que se agote el tiempo de espera. Si bien es poco habitual que todo un servicio o toda una región experimenten interrupciones, es necesario establecer un plan para esos eventos.
Vamos a seguir el proceso que Tailwind Traders utiliza para asegurarse de que sus opciones de tecnología cumplen el acuerdo de nivel de servicio de su aplicación.
Identificación de las cargas de trabajo
Una carga de trabajo es una función o tarea distinta que se separa lógicamente de otras tareas, en términos de requisitos de almacenamiento de datos y lógica empresarial. Cada carga de trabajo define un conjunto de requisitos para la disponibilidad, la escalabilidad, la coherencia de los datos y la recuperación ante desastres.
En Azure, la aplicación Pedidos Especiales necesitará:
- Dos máquinas virtuales.
- Una instancia de Azure SQL Database
- Una instancia de Azure Load Balancer
En este diagrama se muestra la arquitectura básica:
Combinación de los acuerdos de nivel de servicio para calcular un SLA compuesto
Después de haber identificado el acuerdo de nivel de servicio para las cargas de trabajo individuales de la aplicación Pedidos Especiales, es posible que observe que esos acuerdos de nivel de servicio no son iguales. ¿Cómo afecta esto a nuestro requisito general de acuerdo de nivel de servicio de la aplicación del 99,9 %? Para calcularlo, hay que realizar algunas operaciones matemáticas.
El proceso de combinación de acuerdos de nivel de servicio ayuda a calcular el acuerdo de nivel de servicio compuesto para un conjunto de servicios. Para calcular el acuerdo de nivel de servicio compuesto, hay que multiplicar el acuerdo de cada uno de los servicios.
Desde Contratos de nivel de servicio encontrará el acuerdo correspondiente a los servicios de Azure que necesite. Son las siguientes:
Por tanto, el acuerdo de nivel de servicio compuesto para la aplicación Pedidos Especiales será:
Recuerde que necesita dos máquinas virtuales. Por lo tanto, el acuerdo de nivel de servicio de Virtual Machines del 99,9 % se incluye dos veces en la fórmula.
Tenga en cuenta que, aunque todos los servicios individuales tienen acuerdos de nivel de servicio que son iguales o mejores que el acuerdo de la aplicación, el hecho de combinarlos da como resultado un número total que es inferior al 99,9 % que necesita. ¿Por qué? Porque el uso de varios servicios agrega un nivel de complejidad adicional y aumenta ligeramente el riesgo de que se produzcan errores.
Aquí puede ver que el acuerdo de nivel de servicio compuesto del 99,78 % no cumple el acuerdo de nivel de servicio requerido del 99,9 %. Podría consultar con su equipo si esto es aceptable. También podría implementar otras estrategias en el diseño para mejorar este acuerdo de nivel de servicio.
¿Qué ocurre cuando el acuerdo de nivel de servicio compuesto no satisface sus necesidades?
En el caso de la aplicación Special Orders, el contrato de nivel de servicio compuesto no cumple el acuerdo requerido del 99,9 %. Echemos un vistazo a algunas estrategias que Tailwind Traders puede considerar.
Elección de las opciones de personalización que se ajustan al acuerdo de nivel de servicio requerido
Cada una de las cargas de trabajo definidas anteriormente tiene su propio acuerdo de nivel de servicio, y las opciones de personalización que se toman al aprovisionar cada carga de trabajo afectan a ese acuerdo. Por ejemplo:
- DiscosCon Virtual Machines, puede elegir entre un disco administrado HDD estándar, un disco administrado SSD estándar, un disco SSD Premium o Disco Ultra. El acuerdo de nivel de servicio para una sola VM sería del 95 %, 99,5 % o 99,9 %, dependiendo de la opción de disco.
- NivelesAlgunos servicios de Azure se ofrecen como producto de nivel gratuito y como servicio de pago estándar. Por ejemplo, Azure Automation proporciona 500 minutos de tiempo de ejecución de trabajos en una cuenta gratuita de Azure, pero no está respaldado por un acuerdo de nivel de servicio. El acuerdo de nivel de servicio estándar para Azure Automation es del 99,9 %.
Asegúrese de que las decisiones de compra tienen en cuenta la repercusión en el acuerdo de nivel de servicio de los servicios de Azure que elija. Esto garantiza que el acuerdo de nivel de servicio sea compatible con el acuerdo de nivel de servicio necesario para su aplicación.
En este caso, Tailwind Traders podría elegir la opción Disco Ultra para sus máquinas virtuales para ayudar a garantizar un mayor tiempo de actividad.
Creación de requisitos de disponibilidad en el diseño
En el diseño de aplicaciones se pueden considerar factores relacionados con la infraestructura de la nube subyacente.
Por ejemplo, para mejorar la disponibilidad de la aplicación, evite tener únicos puntos de error. Por lo tanto, en lugar de agregar más máquinas virtuales, se pueden implementar una o más instancias adicionales de la misma máquina virtual en las diferentes zonas de disponibilidad de una misma región de Azure.
Una zona de disponibilidad es una ubicación física única dentro de una región de Azure. Cada zona de disponibilidad consta de uno o varios centros de datos equipados con alimentación, refrigeración y redes independientes. Estas zonas usan programaciones diferentes para el mantenimiento, por lo que, si una zona se ve afectada, la instancia de máquina virtual de la otra zona no se ve afectada.
La implementación de dos o más instancias de una máquina virtual de Azure en dos o más zonas de disponibilidad eleva el acuerdo de nivel de servicio de la máquina virtual al 99,99 %. Al volver a calcular el acuerdo de nivel de servicio compuesto anterior con este acuerdo de nivel de servicio de Virtual Machines, se obtiene el siguiente acuerdo:
Este acuerdo de nivel de servicio revisado del 99,96 % supera el objetivo del 99,9 %.
Para obtener más información sobre el acuerdo de nivel de servicio para Virtual Machines, visite SLA para Virtual Machines.
Inclusión de redundancia para aumentar la disponibilidad
Para garantizar la alta disponibilidad, se puede planear que la aplicación tenga componentes duplicados en varias regiones, lo que se conoce como redundancia. Por otro lado, para minimizar los costos durante períodos no críticos, se puede ejecutar la aplicación únicamente en una región. Tailwind Traders podría tener esto en cuenta si las tarifas de pedidos especiales tienden a ser mucho mayores durante determinados meses o estaciones.
Para lograr la máxima disponibilidad en la aplicación, agregue redundancia a cada parte de la aplicación. Esta redundancia incluye la propia aplicación, así como los servicios y la infraestructura subyacentes. Sin embargo, tenga en cuenta que esto puede ser difícil y caro, y a menudo da como resultado soluciones más complejas de lo necesario.
Antes de agregar redundancia, considere si la alta disponibilidad es un requisito importante para usted, dado que puede haber formas más sencillas de satisfacer el acuerdo de nivel de servicio de la aplicación.
Un rendimiento muy alto es difícil de lograr
Los objetivos de rendimiento por encima del 99,99 % son muy difíciles de lograr. Un acuerdo de nivel de servicio del 99,99 % equivale a 1 minuto de tiempo de inactividad por semana. Es difícil responder a errores con la rapidez suficiente para satisfacer los objetivos de rendimiento de acuerdos de nivel de servicio que superen el 99,99 %. En su lugar, si se produce una interrupción, la aplicación debe ser capaz de realizar un diagnóstico y una reparación de manera automática.
MCT: Video 6.2.1: Descripción del Acuerdo de nivel de servicio SLA
- Un acuerdo de nivel de servicio (SLA) es un contrato formal entre una empresa de servicios y un cliente, para que tenga un nivel de garantía que puede esperar
- Cada servicio de Azure define su SLA y se pueden consultar sin tener una suscripción de Azure
- Los servicios gratuitos no tiene un SLA
Partes de un SLA
- Introducción:
- se explica que esperar del acuerdo
- Su ámbito
- Repercuciones que las renovaciones de suscripciones puedan tener
- Términos generales:
- Describen todos los términos utilizados en el SLA, para que el cliente y Microsoft compartan el mismo vocabulario
- Condiciones general del acuerdo
- Como enviar una demanda
- Y recepción de créditos
- Detalles:
- Garantías específicas del servicios
- Compromisos del rendimiento (que se miden en porcentajes entre 99.9% y 99,99%) y este se basa en el tiempo de actividad es decir el tiempo que el servicio esta operativo, pero hay otros que se centran en otros factores como latencia o tiempo de respuesta
- El tiempo de inactividad es el tiempo en que el servicio no esta disponible
- La diferencia entre 99,9% y 99,99% parece pequeña pero no lo ese
- Cuando el proveedor de nube no cumple con su SLA, nos ofrece una compensación que es un crédito de servicio que es un porcentaje que se le abonará al cliente del precio que ha pagado, las compensación aumenta conforme el tiempo de actividad se reduce
- Una carga de trabajo es una tarea independiente de otras tareas en términos de almacenamiento y lógica empresarial
- Cada carga de trabajo definen un conjunto de requisitos para la disponibilidad, escalabilidad, coherencia de los datos y recuperación ante desastres
- Por ejemplo si requerimos para la carga de trabajo
- 2 MV
- Un balanceador
- y una BD SQL Server
- La multiplicación de los SLA de cada servicio nos brinda el nivel de contrato compuesto para la carga de trabajo
- Esto indica que agregar varios servicios aumenta el nivel de complejidad disminuyendo el SLA y aumentando la posibilidad de que se generen errores por tanto para una carga de trabajo el SLA es diferente
- Por eso es importante definir correctamente cada servicio, por ejemplo podemos seleciconar un mejor disco duro y Azure Aplication gateway es un servicio gratuito (sin SLA) pero si seleccionamos el básico si se nos ofrece un SLA mejorando nuestro SLA compuestos
- Para mejorar la disponibilidad de la aplicación se podría crear instancias de la aplicación en diferentes zonas de disponibilidad y esto aumenta el SLA, ya que al estar la aplicación en 2 zonas no se verá afectada por el mantenimiento de una zona
Unidad 5: Acceso a la versión preliminar de servicios y características
Ahora que la empresa Tailwind Traders tiene sus aplicaciones en funcionamiento en Azure, quiere empezar a examinar nuevas funcionalidades de Azure. Una opción consiste en consultar los servicios en versión preliminar. En este módulo, obtendrá información sobre cómo los servicios de Azure pasan de la fase de versión preliminar a la disponibilidad general del producto integrado en Azure.
En el caso de Tailwind Traders, la migración desde el centro de datos a Azure tiene más que ver con la eficacia operativa. El equipo de investigación y desarrollo está examinando nuevas características basadas en la nube que les darán ventaja sobre sus competidores.
Tailwind Traders se encuentra en las fases de desarrollo de la creación de un sistema de entregas mediante drones para clientes en zonas rurales. La empresa necesita que el sistema de orientación de los drones sea capaz de realizar el seguimiento en tiempo real de las tormentas, pero la característica todavía no está disponible. Recientemente se ha publicado un servicio AI Storm Analyzer en la fase de versión preliminar pública. El equipo de RD& de Tailwind Traders ha decidido incorporar el servicio de versión preliminar en las primeras fases de las pruebas de aplicaciones.
¿Qué es el ciclo de vida de un servicio?
El ciclo de vida de un servicio define la forma en que cada servicio de Azure se pone a disposición del público.
Cada servicio de Azure empieza con fase de desarrollo. En esta fase, el equipo de Azure recopila y define los requisitos y comienza a crear el servicio.
A continuación, el servicio pasa a la fase de versión preliminar pública. Durante esta fase, el público puede acceder al servicio, experimentar con él y proporcionar comentarios reales. Los comentarios ayudan a Microsoft a mejorar los servicios. Lo que es más importante, proporcionar comentarios le ofrece la oportunidad de solicitar funcionalidades nuevas o diferentes para que los servicios se adapten mejor a sus necesidades.
Una vez que se valida y se prueba un servicio de Azure nuevo, se pone a disposición de todos los clientes como servicio listo para la producción. Esto se conoce como disponibilidad general (GA).
¿Qué términos y condiciones se pueden esperar?
Cada versión preliminar de Azure define sus propios términos y condiciones. Todos los términos y condiciones específicos de la versión preliminar se excluyen de los contratos de nivel de servicio y la garantía limitada.
Es posible que algunas versiones preliminares no estén cubiertas por el soporte técnico al cliente y puedan estar sujetas a compromisos de seguridad, cumplimiento y privacidad reducidos o diferentes. Por estos motivos, no se recomienda usar esas versiones preliminares para cargas de trabajo críticas para la empresa.
¿Cómo se puede acceder a los servicios de versión preliminar?
Se puede acceder a ellos desde Azure Portal.
Siga estos pasos para ver qué servicios están disponibles en versión preliminar. Puede seguir adelante si tiene una suscripción a Azure.
- Abra Azure Portal e inicie sesión.
- Seleccione Crear un recurso.
- Escriba versión preliminar en el cuadro de búsqueda y seleccione ENTRAR.
- Seleccione un servicio de versión preliminar para obtener más información sobre él. También puede iniciar el servicio si desea probarlo.
¿Cómo se puede acceder a las nuevas características de un servicio existente?
Algunas características en versión preliminar están relacionadas con un área específica de un servicio de Azure existente. Por ejemplo, un servicio de cálculo o de base de datos que use diariamente podría proporcionar una funcionalidad mejorada. Estas características en versión preliminar están disponibles al implementar, configurar y administrar el servicio.
Aunque una característica en versión preliminar de Azure se puede usar en producción, asegúrese de conocer las limitaciones antes de implementarla en un entorno de producción.
¿Cómo se puede acceder a las características en versión preliminar para Azure Portal?
de acceder a las características en versión preliminar que son específicas de Azure Portal en Microsoft Azure (versión preliminar).
Las características en versión preliminar típicas del portal proporcionan mejoras de rendimiento, navegación y accesibilidad a la interfaz de Azure Portal.
Cuando se usa la versión preliminar de Azure Portal, se muestra Microsoft Azure (versión preliminar) en el encabezado de página para recordarle qué versión de Azure Portal usa. Las características en versión preliminar pública que están disponibles opcionalmente también se etiquetan con (versión preliminar) en las páginas de Azure.
¿Cómo puedo proporcionar comentarios en Azure Portal?
Se pueden proporcionar en varios sitios:
- En cualquiera de los 124 foros de servicios de Azure, vaya a la página de ideas de la comunidad de comentarios de Azure.
- La pestaña Comentarios de Azure Portal.
¿Cómo puedo mantenerme informado de las últimas novedades?
En la página Actualizaciones de Azure se ofrece información sobre las últimas actualizaciones de productos, servicios y características de Azure, y hojas de ruta y anuncios de productos.
En la página actualizaciones de Azure, puede:
- ver los detalles de todas las actualizaciones de Azure;
- Vea qué actualizaciones están ahora disponibles, en versión preliminar o en desarrollo.
- examinar actualizaciones por categoría de producto o tipo de actualización;
- buscar actualizaciones por palabra clave;
- suscribirse a una fuente RSS para recibir notificaciones;
- Acceso a la página de Microsoft Connect para leer anuncios y noticias de productos de Azure.
MCT: Video 6.2.2: Descripción Ciclo de vida de un servicio de Azure
- El ciclo de vida de un servicio, define como un servicio de Azure se pone a disposición de los usuarios
- Fases:
- Desarrollo: donde el equipo de Azure recopila los requisitos y comienza a desarrollar el servicio
- Versión preliminar: cuando ya lo desarrollaron para a versión preliminar, durante esta fase el público puede acceder al servicio para probarlo y retroalimentarlo
- Disponibilidad general (GA): una vez terminada la fase de versión preliminar se pasa disponibilidad general marcada como servicio para producción
- las versiones preliminares pueden ser de productos, servicios, software y regiones
- Cada uno define sus propios términos y condiciones (SLA)
- Pero no todos tendrán un soporte técnico por tanto no se recomiendan para producción
- Azure clasifica las versiones preliminares de 2 formas
- Privada: para que solo ciertos clientes las prueben
- Pública: disponible para todos los clientes
- para determinar cuando un servicio esta listo para GA todas sus características pasan el proceso de
- Y una vez cerradas son aprobadas se ponen en GA
- la página de actualizaciones pone a disposición las actualizaciones disponibles
Unidad 6: Prueba de conocimientos
Considere el siguiente escenario: Luego, elija la mejor respuesta para cada pregunta y seleccione Comprobar las respuestas.
Recuerde que la aplicación Pedidos Especiales de Tailwind Traders incluye dos máquinas virtuales, Azure Load Balancer y Azure SQL Database:
Este es el acuerdo de nivel de servicio de cada servicio:
Para calcular el acuerdo de nivel de servicio compuesto de un conjunto de servicios, multiplique el acuerdo de nivel de servicio de cada uno de los servicios. Recuerde que el acuerdo de nivel de servicio compuesto existente es:
El equipo quiere agregar una característica de cartografía que permita calcular las rutas entre los proveedores cercanos y las tiendas. Para ello, el equipo utilizará Azure Maps.
Además, el equipo necesita más capacidad de procesamiento para mantener el ritmo de la demanda. Para ello, agregará una tercera máquina virtual al grupo.
El diagrama siguiente muestra su propuesta de plan:
Recuerde que puede acceder a los acuerdos de nivel de servicio desde la página Contratos de nivel de servicio.
Tailwind Traders también está pensando en usar un servicio de realidad aumentada en la aplicación Pedidos Especiales para ayudar a los clientes a visualizar sus personalizaciones. Este servicio de Azure se encuentra actualmente en la fase de versión preliminar pública.