Mi ruta hacia el VCDX – parte 2

Que tal gente, el día de hoy vamos a continuar con la serie de artículos para compartirles las experiencias que viví a lo largo de mi camino hacia el VCDX. En el articulo anterior hablamos de que proyecto debemos utilizar y como crear o plasmar el proyecto basándonos en requerimientos, supuestos, limitantes y riesgos. Hoy toca hablar de lo que DEBE cumplir un diseño desde la perspectiva del “blueprint” y que este pueda ser aceptado para ser defendido.

¿Que es el Blueprint?

Como cualquier examen y no solo de VMware, se tiene un documento o referencia de que es lo que el examen estará cubriendo. Para el VCDX no es distinto, también se tiene un blueprint que nos indica que es lo que se debe de seguir, la GRAN diferencia con respecto al VCDX es que el no seguir el blueprint puede hacer que tu diseño NO sea aceptado para defender o si se tienen partes que no han sido cubiertas a buen nivel esto impactará mas a futuro en tu presentación y defensa.

El blueprint para la versión Data Center Virtualization (DCV) se puede descargar desde aquí:

VMware Certified Design Expert 5 – Data Center  Virtualization

En el caso de mi compañero Niran (@niranec) y mío , el diseño lo fuimos basando en el blueprint y nos preocupábamos por cubrir cada una de las partes que este requiere. Pero aún así existieron puntos que tuvimos que ir afinando en el camino y algunos otros que al final (cuando digo final es 8:20 AM de nuestra defensa a las 9AM) tuvimos que dejar listos para la defensa.

¿Que debo de incluir en el paquete de aplicación para cumplir con el blueprint?

Lo primero que debemos de entender son los documentos que constituyen un paquete de aplicante para VCDX, estos documentos forman parte del kit “Virtualization Design & Deploy Service Kit” y se apegan a la metodología de diseño de VMware. Cabe destacar que el kit contiene muchos mas documentos que los necesarios para el proceso de VCDX, en el caso de el VCDX se piden los documentos esenciales que son:

  •  Documento de diseño – En este caso estamos hablando del documento “clave” de un paquete de aplicación, aquí básicamente se define la arquitectura de todos los componentes propuestos que forman parte de la solución que estaríamos presentando nuestro cliente. Generalmente este documento define si se nos dará la oportunidad de tener una defensa frente a los panelistas. Es importante notar que la revisión del documento es basada en los pilares de la metodología de diseño de VMware:

    Recoverability, Availability, Manageability, Performance, Security

    En este documento se debe de mostrar la transición de requerimientos, limitantes y supuestos hacia el mundo conceptual, del mundo conceptual debemos de tener la capacidad de traducirlo a un modelo lógico y finalmente aterrizarlo a un diseño físico (donde se incluyen especificaciones de servidores, storage, networking, marcas, etc)

  • Guía de instalación – Este documento puede resultar “trivial” para muchos aplicantes, pero es bastante importante. Digamos que se incluyo como parte de la solución (claramente como parte de su diseño) vSphere App HA, definieron políticas, que VMs serán cubiertas, cuales son los requerimientos que esta tecnología cumple, cuales son los “riesgos” etc… todo suena perfecto, con la capacidad de diseño y entendimiento de la tecnología que ustedes manejan es muy seguro que la solución funcione sin ningún problema, ¿Pero que pasa cuando esta solución es gestionada por el cliente?, ¿Que sucede si se requiere re instalar este componente? ¿Servicios extra? (si claro…)… Debemos de considerar que el diseño que nosotros estamos realizando debe de ser repetible por personas que sean ajenas al mismo, es decir, que sin haber estado involucradas puedan tomar los distintos documentos y puedan re instalar o modificar la infraestructura. En este caso en especifico mi compañero  Niran (@niranec) y yo construimos un ambiente desde cero en mi laboratorio donde instalamos TODOS los componentes basándonos en nuestro diseño, por lo que aun siendo un diseño ficticio si se tomara la guía de instalación sería bastante sencillo de implementar, este ambiente estaba constituido por 17 VMs (y aún mas que corrían sobre los vESXis):

Screen Shot 2014-08-10 at 10.20.07 PM

  • Guía operativa – En esta guía se debe de cubrir operaciones del día a día, por ejemplo, tomar un snapshot, crear una VM, agregar un disco virtual, etc. Pero también debemos de cubrir operaciones del día a día de soluciones extra como Update Manager, vCOPs, etc.
  • Plan de implementación – En este documento debemos de estipular cuales serán las tareas a seguir, personas o equipos encargados, tiempos, alcances, objetivos, etc. En nuestro caso, Niran (@niranec) preparo un Gantt bastante completo detallando cada una de las tareas que en conjunto definimos que deberían formar parte de la implementación de nuestro diseño. Un ejemplo de algo que tal vez no es tan “obvio” es el tener workshops o tener cursos (ya sean formales o por parte del consultor) para transmitir el conocimiento de las tecnologías que forman parte de esta solución.
  • Matriz de pruebas – En este documento se definen todas las pruebas que debemos realizar para poder constatar que todas las tecnologías que forman parte de la solución funcionan y que los objetivos de nuestro cliente fueron cumplidos. Un ejemplo de lo que debemos verificar es el nivel de disponibilidad requerido para algún o algunos componentes de la arquitectura, por ejemplo, 99.999% de disponibilidad para una base de datos crítica, debemos de mostrar que la arquitectura propuesta es capaz en realidad de entregar dicho nivel de disponibilidad (no solo en el papel…).

¿Que consideraciones debo de tener para mis documentos?

  • Crea tu propio estilo – No descarguen los templates de servicios profesionales desde partner central y basen su documentación en ellos… un VCDX debe de ser capaz de crear su propio estilo, incluir secciones especificas basadas en su diseño a toda la documentación, crear diagramas, tablas, etc. No estoy diciendo que no tomen estos templates para darse ideas o poder entender una estructura correcta, solamente deben de tener su propio estilo y deben de comprender que cada diseño es distinto, simplemente comprendamos que este es un proyecto para un “cliente” por lo cual debemos de mostrar nuestra marca e incluir información relevante para nuestro cliente.
  • LEAN y LEAN y después de haber leído, LEAN otra vez el blueprint – la clave del éxito para tener un diseño y documentación a nivel de un VCDX es el cumplir con los requerimientos del blueprint. No crean que porque llevan 4 meses trabajando su documento es perfecto, les puedo decir con seguridad que no lo es. Dense el tiempo para revisar su documento de diseño contra el blueprint, verifiquen que cumplen con todos los requerimientos y que los pilares de la metodología de diseño de VMware están cubiertos (RAMPS) porque si falta alguno de ellos es muy seguro que su diseño no sea aceptado o que no sean exitosos en su defensa.
  • Cubre todas las áreas técnicas  y de negocio – En tu documentación se debe de incluir detalles de diseño de todos los aspectos de una solución integral, es decir, desde motivaciones de negocio, consideraciones políticas hasta temas súper técnicos.
    speak-geek-box_large
    El error mas grande que tenemos nosotros como tecnólogos es el hecho de que muchas veces no consideramos temas de negocio o fuera de nuestra área de confort que es la tecnología, lamentablemente (¿O debería decir “afortunadamente”?) el objetivo de un arquitecto es proveer soluciones en base a todos los requerimientos y situaciones que los clientes puedan tener, aún cuando estos puedan ser basados en temas de negocio. Algo también es MUY importante es el hecho que alguien que tenga el nivel de VCDX debe de ser capaz de entender cualquier elemento del diseño, es decir, si en nuestro diseño hablamos de una tecnología o producto en especifico (VMware o de terceros), debemos de ser capaces de contestar cualquier pregunta sobre esta y entender como se integra e incluso cuales son los impactos que tiene a los distintos componentes de nuestra arquitectura (impactos tecnológicos y de negocio), por lo que si en el proyecto existieron distintos arquitectos o responsables de diferentes secciones de la solución debemos de estar consientes que CUALQUIER elemento es y será (se los digo por experiencia) sujeto a preguntas y cuestionamientos por los panelistas.
  • Pidan apoyo para revisar su documento – Esto es esencial, las revisiones de nuestro diseño definirán muchísimas áreas de oportunidad, elementos erróneos o que falten en nuestra solución. Recordemos que NO sabemos todo, aun cuando tengamos el nivel de VCDX somos personas por lo que tenemos errores y no contamos con todo el conocimiento. En nuestro caso en especifico tuvimos apoyo de varios VCDXes en el camino, desde Travis Wood VCDX x2 #97 (@vTravWood), Andrew Nelson VCDX #33 (@vmwnelson),Jonathan Shannon, Sean Howard VCDX #130 (@showardvmware), Jonathan Kohler VCDX #116 (@JonKohler) hasta el gran Mostafa Khalil VCDX #2 (@MostafaVMW).

De las cosas mas importantes que aprendí en este proceso es que NINGUN DISEñO ES PERFECTO, no se estresen si después de haber enviado su paquete de documentación descubren que algo esta mal o que algo falto… Lo peor que puede pasar es que deban de volver a enviar su documentación cubriendo lo que faltó o que tengan que defender ese elemento frente a los panelistas. Obtener el VCDX es un proceso, muchos no lo obtienen en el primer intento, cada oportunidad y cada intento nos enseña algo nuevo e importante así que no queda nada mas que disfrutar :)

 

 

Leave a Reply