INNIT Reglas generales de estandarización,

estrategias de administración y
POLITICAS Y ESTANDARES nomenclatura de recursos en Azure

AZURE

Azure Políticas de administración

Reglas de administración
Nomenclatura de recursos
Polítcas de administración
 Todas las aplicaciones deben ser implementadas en App Services bajo el soporte de tipo de aplicación que ofrece Azure. En caso de que se requiera un mayor control sobre el recurso y
los requerimientos de la aplicación se utilizará Cloud Services; (Web Roles, Worker Roles).
 Las aplicaciones serán ya soportadas por Application Service Plan Standard para tener un mejor versiona miento entre ambientes (Producción, Pruebas y Desarrollo). Solo aplica bajo
ciertos requerimientos.
 La solución de un proyecto que contenga Aplicación Web, CMS y Servicios, estos serán implementados dentro del mismo App Service o Cloud Service como aplique y configurados
como aplicaciones en directorios virtuales.
 Los ambientes de Pruebas y Desarrollos implementarán base de datos en planes gratuitos. Siempre y cuando esa opción si sea soportada por la aplicación.
 En primera instancias todas las base de datos serán implementadas con SQL Server. Cuando se requiera una base de datos será implementada a través de la configuración de
servidores en Azure. Cuando el requerimiento no cumple con las opciones SaaS de Azure se generará un VM y se configurará en servidor de base de datos (tener en cuenta el
licenciamiento).
 En caso de implementar una VM, será bajo aprobación. Esta deberá implementar los ambientes de Producción y Desarrollo. Y el costo de la VM se facturará en el tiempo que dure
desarrollo. La primera opción de configuración será el plan Básico
 Cada propuesta de solución antes de su implementación deberá ser validado por el Administrador de Azure.

Reglas de administración
 Todas las subscripciones tendrán como estándar un Storage Account con el nombre coredev ; donde se almacenará toda la información de respaldo de una de una suscripción . Esto
como archivos y backups de bases de datos. Este Storage Account contendrá por default dos containers blobs; dbbackup y vhds . Para almacenar los backups de las bases de datos y
las imágenes de los HDD de las maquinas virtuales respectivamente.

Nomenclatura de recursos

Nombre Regla Ejemplo

Subscripciones <Company>  Rheem

Company: Nombre de la compañía o cliente  Hard Rock
 CEV

Application Service Plan
<Prefix><Subscription>-<Environment>-<Plan>  ASPRheem-Produccion-Free
 Prefix: Prefijo ASP siglas del tipo de recurso  ASPRheem-Dev-Free
 Subscription: Nombre de la subscripción  ASPHardRock-Produccion-Standard
 Environment: Entorno ( Produccion , Dev )
 Plan: Tipo de plan (Free, Standard, Premium)

Resource Groups <Prefix><Subscription>-<Environment>  RGRheem-Dev

 Prefix: Prefijo RG siglas del tipo de recurso  RGCEV-Produccion
 Subscription: Nombre de la subscripción
 Environment: Entorno ( Produccion , Dev )

<Subscription>-<Abbreviation>-<Environment>  Rheem-vm-Dev (vm; Virtual Machine)

General Resource  Subscription: Nombre de la subscripción  CEV-vn-Produccion (vn; Virtual Network)
 Abbreviation: Abreviación del tipo de recurso  CEV-vm-Produccion (vm; Virtual Machine)
 Environment: Entorno ( Produccion , Dev )  HardRock-st-Dev (st; Storage Account)

Estrategia de depuración
 En un periodo semanal se revisará el estatus de cada recurso para monitorear que este siendo en uso de lo contrario pasa a lista de eliminación.
 Cada recurso que este en lista de eliminación se verificara si obtiene aprobación de un respaldo o eliminación completa .
 Cada recurso que se genere para versión de prueba tendrá solamente un periodo de 5 días máximo en un plan Free y 2 días máximo en un plan que genere costo. Cumpliendo los días
establecidos se analiza si se extiende el periodo, de lo contrario se elimina.
 En caso de generar recursos de un plan que genere costo, será antes validado por el arquitecto de solución y revisar que sea necesario esa configuración. Y determinar un periodo de
vida del recurso si estará viviendo en un ambiente de desarrollo.
 Todos los recursos serán administrador por una sola cuenta de administrador en Azure . En caso muy importante de compartir el acceso, este segundo solo tendrá permiso de consulta.
 Se generará un reporte por suscripción y por cada recurso que contiene en Azure, cada semana para que el Product Owner valide y verifique cada uno de los recursos que están
activos y tomar acciones de depuración.

© 2016 INNIT. Todos los derechos reservados. http://www.innit.com.mx