Capacity planning : Introducción (I)

Actualización – 10 Dic 2012


Puedes encontrar más información sobre Capacity Planning en el sitio del libro:

www.capacity-planning-it.com


En este post voy a hablar de cual es la metodología que yo sigo para realizar un capacity planning, no estoy intentando sentar cátedra, ni mucho menos, sencillamente me limito a contestar a un buen amigo que en su día me preguntó cómo ejecutaba yo un capacity planning, ¿qué metodología estaba siguiendo? si para el análisis de los datos utilizaba algún modelo matemático o por el contrario realizaba el análisis en base a mi experiencia profesional. Para responder a esas preguntas y por si puede ser útil a alguien mas, decidí escribir este post contando mi forma de ejecutar un capacity planning.

“La rueda ya está inventada, no me cuentes cómo es, cuéntame para qué la utilizas”

Introducción

Una de las funciones de un área de IT es realizar el capacity planning de la plataforma utilizada para desarrollar el negocio de la compañía. Lo mas sorprendente y quizás una de las causa de que no se implante fases de capacity planning en los proyectos de IT es que no existe una metodología única, no existe un modelo unificado, una norma que todo el mundo pueda seguir. De toda la bibliografía y documentos técnicos que he podido leer en los últimos años, la única conclusión que he sacado es que cada fabricante, empresa de servicios, profesor universitario, consultor y blogger tiene su propia metodología para ejecutar un capacity planning. Quizás, como he comentado anteriormente, esta falta de estandarización sea la causa de que capacity planning sea un término no demasiado conocido entre los responsable IT.

¿Qué es un capacity planning?

El primer paso es entender en qué consiste un capacity planning, creo que la definición que puedes encontrar en wikipedia es perfecta.

“Capacity planning is the process of determining the production capacity needed by an organization to meet changing demands for its products.[1] In the context of capacity planning, “capacity” is the maximum amount of work that an organization is capable of completing in a given period of time.” Wikipedia.org

Es el proceso para determinar la capacidad que tienen una compañía para afrontar el crecimiento en la demanda de sus productos. Para un área IT, podemos decir que dicha área dispone de una serie de productos, los cuales son consumidos por el resto de la compañía. Estos productos son las distintas infraestructuras IT sobre las que se despliega el negocio de la compañía. Siempre que hablo de infraestructura IT, me refiero tanto al HW como al SW, incluyendo todos los procedimientos necesarios para la explotación de la plataforma y por su puesto, una de las partes más importantes de toda la infraestructura, el equipo humano. Normalmente se tiende a olvidar la relación que mantiene el equipo humano con el resto de los elementos de la infraestructura.

Para la ejecución de un capacity planning es importante contar no solo con los componentes HW y SW, sino también con recursos humanos del área.

Por lo tanto, capacity planning consiste en el estudio de la capacidad del área de IT para absorber el crecimiento de las necesidades del negocio de la compañía. No debemos perder nunca la perspectiva de que el área IT ofrece un producto que es consumido por el resto de la compañía para desarrollar su negocio.

Lo importante no es el capacity planning en sí, sino que demos respuestas a las necesidades de negocio de la compañía.

¿Por qué hacer un capacity planning?

Existen varias razones para realizar un capacity planning, pero creo que hay una que está por encima del resto. La principal razón es que el capacity planning nos permitirá distinguir entre la gestión del riesgo y la percepción del riesgo, como defiende Neil Gunter en su libro “Guerrilla Capacity Planning“.

  • La gestión del riesgo, consiste en conocer en profundidad cuales son los riesgos reales a los que se puede enfrentar nuestra plataforma y realizar una serie de acciones, para en la medida de lo posible, eliminar o minimizar el impacto de dichos riesgos en el negocio de la compañía.
  • La percepción del riesgo, es tener constancia de la existencia de ciertos riesgos, pero no analizar el impacto de dichos riesgos sobre el negocio. Sin un análisis de los riesgos, podemos llegar a tener una percepción equivocada del riesgo, provocando que lo que nosotros suponemos son pequeños riesgos, en realidad tenga un impacto enorme en el negocio de la compañía.

Realizar un capacity planning, nos permitirá conocer cuales son los riesgos reales de la plataforma IT de la que somos responsables y cómo dichos riesgos impactan en el negocio de nuestra compañía.

Un error muy común es creer que un capacity planning sirve únicamente para medir el rendimiento de nuestra plataforma desde el punto de vista IT. Este error es mas frecuente de lo que mucha gente puede pensar. Podéis preguntar a cualquier persona del área IT, sobre cuanto dinero pierde la compañía cada vez que hay un problema de rendimiento en la BD, muy poca gente podrá contestar con exactitud a esa pregunta. La mayoría de la gente que trabaja en IT tendemos a no prestar demasiada atención al impacto de los problemas de la plataforma IT en el negocio de nuestra compañía.

Es primordial que la gente que trabajamos en IT comprendamos que debemos comenzar a mirar fuera de nuestras propias áreas, para comprender cómo nuestro trabajo impacta en el desarrollo del negocio de nuestra compañía. Si conseguimos obtener esta nueva perspectiva, podemos entender que la pregunta que intentamos responder mediante un capacity planning no es ¿cómo de lentos son mis discos? o ¿necesitaré comprar otra máquina de BBDD? sino ¿cómo está impactando al negocio que los discos tengan un problema de rendimiento o ¿está mi infraestructura de BBDD preparada para absorber el nuevo despliegue de la compañía ?

¿Cuándo hay que realizar un capacity planning?

Este es el único punto donde todo el mundo está de acuerdo. Durante el ciclo de vida de una plataforma IT, existe tres momentos en los que se debería realizar un capacity planning.

  • Durante el periodo de desarrollo del proyecto, para identificar posible carencias en la definición de las especificaciones del proyecto, así como el impacto que tendrá el proyecto en la plataforma de negocio.
  • Una vez la plataforma esté en producción, periódicamente se debería realizar un capacity planning, para identificar posibles cuellos de botella y gestionar los riesgos para el negocio que se puedan encontrar, informando a la dirección periódicamente.
  • Cada vez que la compañía vaya a tomar una decisión sobre el negocio, debería realizarse un capacity planning para chequear que dicha decisión no impactará de forma negativa en la actual plataforma.

Tengo que aclarar que la duración, así como la dimensión del capacity planning depende del objetivo al que se desea llegar, no requiere el mismo tiempo, ni recursos, la ejecución de un capacity planning durante el periodo de desarrollo del proyecto, que el tiempo y recursos necesarios para un capacity planning periódico. Las razones son obvias, durante la primera fase, se han establecido los distintos procedimientos para recoger y analizar los datos de la plataforma, por lo tanto una vez que tenemos los procedimientos establecidos, realizar un capacity planning periódico es un asunto trivial.

A veces la dirección de la empresa puede disponer de una información equivocada sobre la capacidad de la plataforma de negocio y no es raro el caso en el que se adoptan acciones de negocio sin disponer de la suficiente capacidad en la plataforma de IT. Es responsabilidad de las áreas de IT facilitar a la dirección de la compañía las herramientas necesarias para una correcta toma de decisión. Estas herramientas, no son otra cosas que los informes sobre el capacity planning de la plataforma IT.

Con la información correcta, tanto la dirección como las unidades de negocio, podrán tomar decisiones que no provoquen un riesgo para el negocio de la compañía.

Ejemplo 1: Una compañía vende libros mediante una plataforma WEB, la clientela se limita únicamente a un país determinado, el negocio va viento en popa y la dirección decide expandir el mercado a los países vecinos. La dirección decide que como la plataforma está funcionando correctamente, por lo tanto el proceso de expansión será dar a conocer la plataforma en el nuevo país y crear los canales de distribución para la entrega de los libros. Una plataforma IT que funcionaba perfectamente en un país, comienza a degradarse debido al aumento de operaciones nuevas, provocando una caída en las ventas derivada de la lentitud y los fallos en la navegación de la plataforma WEB.

En el ejemplo anterior podemos ver cómo una decisión tomada, bien por falta de información, bien por una percepción del riesgo equivocada, provoca unas perdidas en una compañía que estaba funcionando perfectamente y desde las áreas de IT, debemos reflexionar sobre ¿quién ha tenido la culpa?, es fácil caer en el argumento de “…es que los de arriba no tienen ni idea…”. ¿ No somos las áreas de IT responsables de informar a la dirección sobre las posibilidades de la compañía a nivel IT? yo creo que s. Las áreas IT son responsables tanto o más que la dirección, por esa razón siempre aconsejo que se realicen informes periódicos sobre el estado de la plataforma IT y que dichos informes incluya información sobre capacity planning.

¿Quién debe realizar el capacity planning?

En principio debería ser una tarea de todas las áreas que intervengan directamente en el desarrollo del negocio de la compañía, pero dependiendo del momento, dentro del ciclo de vida de la plataforma IT, en el que se proponga la idea de ejecutar un capacity planning, deberemos incluir a más o menos áreas. Aunque lo normal es que el capacity planning de IT afecte únicamente a la plataforma IT que está dando servicio. Por lo tanto centrándonos en las áreas IT, el principal responsable de un capacity planning debe ser el área de Sistemas, ya que es esta área la responsable de mantener los sistema de producción y deberían conocer perfectamente, debido a la experiencia del día a día, cual es el estado y las posibilidades de crecimiento.

Las 3 Fases de un capacity planning

Como he comentado al principio del post, no existe un procedimiento unificado que defina los pasos de un capacity planning y este no es el único problema de estandarización, tampoco en algunas de las fases existe un estándar que defina cómo deben realizarse dichas fases. En este apartado vamos a ver las 3 fases básicas necesarias para ejecutar un capacity planning.

  • Definición de los niveles de servicio.
  • Análisis de la capacidad.
  • Planificación de acciones.

Dependiendo de la documentación que sigáis, tendréis más o menos fases, las tres fases anteriores son la que yo sigo. Quiero volver a comentar, que en este post estoy describiendo CÓMO realizo yo un capacity planning, lo cual no quiere decir que sean las fases y procedimientos perfectos, sencillamente, son las fases y procedimientos que a mi me sirven.

Definición de los niveles de servicio

La primera fase y puede que una de las más críticas, es la definición de los niveles de servicio que se van a exigir a la nueva plataforma. Es muy importante que exista un acuerdo entre las distintas áreas que intervienen en el desarrollo del negocio sobre los distintos niveles de servicio que debe cumplir la nueva plataforma.

El nivel de servicio define el nivel mínimo por encima del cual la calidad del servicio es aceptable. Dependiendo del tipo de nivel que se defina, decimos que el servicio está degradado si la calidad que está ofreciendo la plataforma está por debajo de los niveles de servicio mínimos o sencillamente el servicio está indisponible.

Es muy importante que la definición de los niveles de servicio debe ser realistas con las necesidades del negocio de la compañía. Nunca se deben aceptar unos niveles de servicio que no representen la realidad del negocio, tanto por debajo como por encima. Establecer unos niveles de servicio demasiado exigentes puede provocar un error de cálculo en el capacity planning que se reflejará, por ejemplo, en un aumento de la inversión. Por otro lado unos niveles de servicio relajados, supondrán un problema de rendimiento de la plataforma frente a pequeños crecimientos no esperados de las necesidades de la plataforma.

Ejemplo 2: En nuestra empresa de venta de libros por Internet, durante la fase de definición de los niveles de servicio se exige que uno de los niveles definidos, el tiempo de respuesta de las páginas, sea de 1 a 2 seg. Este tipo de niveles de servicio provocaran que el capacity planning que estamos realizando aconseje por ejemplo, duplicar o triplicar la capacidad de procesamiento en BBD, para reducir los tiempos de respuesta de los servidores de aplicación. Esta inversión dispararía el coste del proyecto, cuando una tienda de venta de libros no necesita unos tiempos de respuesta como los de un buscador o un periódico digital.

Para establecer los niveles de servicio se deben tener claro cuales serán las unidades de trabajo, en base las cuales se definirán los niveles de servicio. Como unidad de trabajo entendemos la operación básica necesaria para el desarrollo de una parte del negocio. Un negocio, desde el punto de vista del capacity planning, estará formado por varias unidades de trabajo. Es muy importante que la unidades de trabajo definidas reflejen la realidad del negocio de nuestra compañía.

Una unidad de trabajo puede estar formada por un conjunto de operaciones, las cuales habrá que definir de forma clara. En el siguiente ejemplo podemos ver algunas unidades de trabajo.

Ejemplo 3: En nuestra web de venta de libros, podemos definir las siguientes unidades de trabajo:

  • Transacción, todas las operaciones necesarias para comprar un libro.
  • Registro, todas las operaciones necesarias para que un usuario se registre.
  • Consulta pedido, las operaciones que permiten a un usuario consultar un pedido.

Cada una de estas unidades de trabajo agrupará una serie de operaciones sobre la plataforma IT. Entendemos como operación sobre la plataforma, todas aquellas interactuaciones entre los distintos elementos HW, SW o humanos que se necesitan realizar en la plataforma como parte de una unidad de trabajo, por ejemplo accesos a BBDD, tiempos de respuesta de la red, entrada/salida del almacenamiento, uso de CPU, etc.

Es importante que la unidad de trabajo se definan como entidades genéricas, de esta forma conseguimos crear grupos de operaciones, que a su vez agrupan los distintos elementos de la plataforma, pudiendo encontrar posibles problemas de rendimiento o cuellos de botella de una forma muy sencilla. Si por el contrario, elegimos como unidad de trabajo, por ejemplo, el tiempo de respuesta de disco, tendremos problemas a la hora de realizar un análisis. Muchas de las operaciones de nuestra plataforma necesitan accesos a disco, pero no todas tienen las mismas necesidades de tiempos de respuesta, lo que nos permitiría por ejemplo agrupar distintas operaciones en discos de distintas velocidades, pero si elegimos como unidad de trabajo el tiempo de respuesta del disco, todos los discos de la plataforma deberían tener como mínimo el mismo tiempo de respuesta que el mas lento de los discos. Esto provocaría errores en los resultados derivados del capacity planning, sobre todo porque no es una situación real.

En resumen, yo suelo elegir como unidades de trabajo, aquellas operaciones críticas para el desarrollo del negocio, esto me permite identificar problemas en la plataforma IT, asociar dichos problemas a una parte del desarrollo del negocio y poder de esta forma gestionar el riesgo que dicho problema puede llegar a plantear. Al centrar el foco en una parte concreta de la plataforma podremos obtener unos resultados mas correctos, ya que emplearemos gran parte del tiempo en el análisis de los puntos críticos.

Análisis de la capacidad

El concepto Análisis de la capacidad abarca una extensión demasiado basta en una infraestructura IT, debemos ser muy conscientes de qué debemos analizar, en el caso contrario podríamos perder el objetivo, no del análisis, sino del capacity planning, ya que el análisis de la capacidad de la plataforma IT debe cubrir aspectos HW, SW y por supuesto analizar los factores humanos. Por estas razones, en la fase anterior hice mucho hincapié en que se definieran unidades de trabajo desde la perspectiva del negocio para delimitar los elementos críticos de una infraestructura IT, siempre desde el punto de vista del negocio. El análisis de la capacidad pretende responder a la pregunta:

¿Está la plataforma IT preparada para los nuevos requerimientos que demanda el negocio de mi compañía?

El objetivo principal del análisis es responder a la pregunta anterior, pero dicho análisis generaran otra serie de beneficios colaterales, que nos ayudaran a las áreas IT en la toma de decisiones en el futuro, por ejemplo en cuanto a la escalabilidad, la disponibilidad y los costes.

Cuando vamos a realizar un análisis el primera paso consiste en recuperar un conjunto de datos. Dependiendo de la calidad de los datos recogidos y de la experiencia de equipo que los analizará, el análisis será mas o menos preciso. Por lo tanto existen dos máximas a la hora de realizar un análisis de la capacidad de la plataforma:

  • Tener un buen procedimiento para recoger datos, lo que nos garantizará la calidad de los mismos.
  • Disponer de un equipo humano con la suficiente experiencia como para interpretar los datos recogidos de forma correcta.

Sobre el segundo punto, la experiencia de las personas que analizarán los datos, creo que no cabe aclaración posible. En cuanto al primer punto, si existe discrepancia entre los distintos autores y/o profesionales relacionados con los capacity planning.

Como comenté al principio, no hay un modelo estandarizado de obtención y análisis de los datos para medir la capacidad de una plataforma IT, de echo existen miles de modelos, ya que cada profesional que realiza uno capacity planning lo puede ejecutar de una forma determinada. Aun sin existir un modelo estándar, en la documentación existente sobre capacity planning existen, llamémoslas tendencias:

  • Modelos Matemáticos, son todos aquellos modelos que hacen uso de métodos matemáticos, para modelizar el comportamiento de una plataforma. Casi todos los elementos de una plataforma se modelizan matemáticamente obteniendo unas funciones que nos permitirán tanto medir la carga de la plataforma como predecir el rendimiento de la misma.
  • Modelos basados en la experiencia, son aquellos modelos que reniegan del modelo matemático, se basan en la experiencia y la subjetividad del conocimiento de la persona que está realizando el análisis.

Desde hace tiempo, utilizo mi propio modelo para el análisis de los datos en un capacity planning, que un mezcla de los dos modelos anteriores. Dicho modelo se basa en los siguientes puntos.

Recursos de la plataforma

Hay que realizar un análisis de cada una de las unidades de trabajo que hemos definido en la fase de definición de los niveles de servicio. En este análisis agruparemos todas las operaciones que se realizan en una unidad de trabajo y realizaremos un estudio de cómo dichas operaciones interactúan con los recursos disponibles en la plataforma, uso de CPU, accesos a discos, fallos de cache, envío de paquetes, creación de procesos, lecturas/escrituras en BBDD, etc.

No debemos olvidar que estamos realizando un análisis de la capacidad de la plataforma y existen dos variables, las cuales debemos modelar, volumen y tiempo de respuesta. Todas la plataformas trabajan con volumen de datos y se encargan de manipular y/o presentar dichos datos en un tiempo de respuesta determinado.

  • Volumen, el capacity planning nos puede ayudar en determinar si el nuevo volumen de datos que debe gestionar la plataforma es asumido por ésta y en caso contrario, cuales son las acciones que debemos tomar.
  • Tiempo de respuesta, es el tiempo necesario para considerar que una operación ha finalizado.

La experiencia de las personas

La experiencia de las personas que realizan el análisis es fundamental. La experiencia la justifico porque realizar un modelo matemático del comportamiento de una plataforma IT es demasiado complicado, se pueden producir errores que enmascaren problemas y únicamente si la gente que está haciendo el análisis tiene experiencia, no solo en la ejecución del capacity planning sino experiencia en IT, podrán ser lo suficientemente críticos para identificar posibles problemas.

Muchas veces durante el proceso de implantación de un proyecto, a raíz de los resultados obtenidos en el capacity planning, se deben tomar decisiones, como por ejemplo, aumentar la capacidad de cálculo y surge la pregunta ¿cómo crecemos vertical u horizontalmente? es necesario que las personas que están realizando el capacity planning tenga la experiencia suficiente en IT para resolver este tipo de dudas y poder justificar las decisiones.

No me fío demasiado de las empresas que presumen de realizar capacity planning, pero que no disponen de profesionales formados y con experiencia en tecnología, los cuales nos ayudaran a justificar los resultados.

Teoría de colas

Suelo utilizar teoría de colas, lo que me permite construir un modelo de las relaciones existentes entre los elementos de la plataforma que intervienen en una unidad de trabajo. Realizar un modelo utilizando teoría de colas para TODA la plataforma puede ser un trabajo faraónico, que nos haga perder tiempo en la fase de análisis, yo suelo centrarme en aquellas unidades de trabajo que presentan cierta criticidad para el negocio de la compañía. En el libro Performance by Design: Computer Capacity Planning By Example podréis encontrar algunos ejemplos de como implementar redes de colas.

Si emplear un modelo basado en teoría de colas te parece complicado, puedes sustituirlo por un grafo de estados o sencillamente un esquema donde representes las relaciones existentes entre los distintos elementos de la plataforma. Para mi, es infinitamente útil disponer de esquemas, con lo que poder discutir sobre posibles dudas con las distintas áreas que intervienen en la ejecución de un proyecto, es más rápido, siempre es mas rápido preguntarle a alguien que está centrado en otra tareas utilizando un esquema que realizando una descripción sobre la relación existente entre el click del usuario en una página en concreto y el acceso a disco que dicho click provoca. También es muy objetivo, la realidad (por lo menos una aproximación) es lo que representa el esquema, si no está en vuestro esquema, no lo podrás medir.

Herramientas

Normalmente no suelo utilizar herramientas comerciales para la recolección de los datos, en el mercado existen muchas herramientas que te permite no solo recoger los datos sino modelarlos( BMC Perform/Predict o HyPerformix), yo personalmente, prefiero recoger los datos y modelarlos, lo que me permite un margen de maniobra casi infinito y otro punto importante es reducir el coste total de ejecución del capacity planning. Los comandos disponibles en el sistema y lenguajes de scripting como PERL o AWK, son suficientes para obtener datos de la plataforma.

Durante la fase de análisis deberíamos ir planteando una solución para disponer de una sencilla plataforma para la generación de informes. Esta plataforma de informes, se alimentará con los datos que hemos obtenido y permitirá disponer de informes de una forma sencilla y rápida. Debemos tener en cuenta que las distintas unidades de negocio de nuestra compañía nos solicitarán informes con información que a nosotros nos puede parecer trivial. Yo tengo la siguiente regla de oro:

“Todo el tiempo que empleas generando informes, lo pierdes analizando los datos.”

Por lo tanto intenta reducir al máximo el tiempo empleado para generar información.

Modelos físicos y teóricos

No siempre, durante el desarrollo de un capacity planning se puede disponer de una plataforma física sobre la que obtener los datos, a veces dicha plataforma no existe y debemos crear un modelo teórico con el que trabajar, por su puesto que un modelo teórico presenta muchas limitaciones y debemos ser muy conservadores con los resultados que obtengamos, pero los modelos teóricos nos pueden ayudar a tomar ciertas decisiones sin tener que invertir dinero en algo que aún no sabemos como va a funcionar.

Siempre que puedas, monta un modelo físico, porque te permitirá comprobar las interacciones entre los distintos elementos de la plataforma, así como medir los tiempos de respuesta de los distintos elementos, aunque debas realizar extrapolaciones posteriormente.

Otras veces nos encontraremos con plataformas físicas sobre las que se quieren hacer modificaciones, por ejemplo añadir nuevos servidores web, en este caso, debemos crear un modelo utilizando la plataforma ya existen y los nuevos elementos que aún no se han incorporado, creando un modelo mixto que nos ayudará en la toma de decisión sobre la forma en la que debe crecer la plataforma.

Básicamente estos son los puntos principales del modelo que yo aplico para el análisis de la capacidad de una plataforma, dependiendo de la naturaleza del negocio de dicha plataforma, habrá que profundizar mas en unos puntos que en otros.

Procedimiento de análisis de la capacidad.

  1. Análisis de los recursos de la plataforma. Utilizando las unidades de trabajo definidas en la fase de definición de los niveles de servicio, iremos identificando todas las operaciones que una unidad de trabajo realiza sobre los distintos componentes de la plataforma, como son la CPU, memoria, discos, red, etc. Se crea un documento con cada unidad de trabajo. En dicho documento se definen los niveles de servicio que tiene la unidad de trabajo. Se realiza una lista con todas las operaciones que ejecutará la unidad de trabajo y por cada operación se identifican todos los elementos de la infraestructura que intervienen en dicha operación. Una vez finalizado este punto, dispondremos de una serie de documentos, los cuales definen perfectamente la plataforma
  2. Creación de un esquema de las unidades de trabajo críticas para el negocio. Con la información recopilada en el paso anterior, crearemos un esquema relacional entre los distintos componentes afectados en las operaciones de una unidad de trabajo. Yo suelo utilizar una red de colas para representar las dependencias existentes entre los distintos componente de la plataforma. Lo interesante de las redes de colas es que de forma visual podemos detectar muy rápidamente cuales son los posibles cuellos de botella y analizando cada uno de estos posibles cuellos de botella podemos tener una idea real de como la carga actual está afectando al desarrollo del negocio, también nos permite conocer rápidamente cuales serán los elementos de la plataforma que mas impacto tendrán en el rendimiento de la misma en caso de añadir mas carga. El utilizar teoría de colas no es obligatorio, tal como he comentado antes, se puede utilizar cualquier forma de representación, el propósito es disponer de una serie de esquemas que nos permitan realizar un análisis visual rápido sobre las relaciones dentro de la plataforma.
  3. Creación de un modelo físico y/o teórico sobre el que recoger los datos. Una vez hemos realizado el análisis del relación entre los distintos componentes de la plataforma, es interesante poder crear un prototipo sobre el que realizar las pruebas. Dependiendo del propósito del capacity planning y del estado de nuestra plataforma, podremos disponer de una maqueta exactamente igual, una maqueta reducida en la que los valores obtenidos tendrán que ser cuidadosamente extrapolados a la plataforma real o bien crear una serie de maquetas teóricas sobre la que poder realizar los cálculos de crecimiento.
  4. Crear los scripts y procedimientos para la recogida de los datos. La creación de los scripts de recogida de datos debe realizarse en base a los elementos y variables que vayamos a analizar. Es importante no excederse en la captura de información, hay quien piensa que la cantidad de datos no es un problema, pero cuando estamos realizando un análisis sobre la capacidad de la plataforma, lo que no podemos hacer es cargar a la plataforma con trabajo para recoger su propia carga. Yo suelo realizar scripts sencillos que no se solapen en el tiempo y evitando crear gigantescos scripts de cientos de líneas que capturan datos, los parsean y te devuelven una hoja Excel. Cualquier SO está formado por miles de comandos sencillos, utilízalos y en cuanto a los datos, almacena en bruto y posteriormente realiza el trabajo de parseado. Es muy importante que la información almacenada esté perfectamente organizada, ya que los datos recogidos, pueden ser necesarios, hora, días, semanas o meses mas tarde. También debes tener cuidado en cómo guardas los datos, como he dicho, suelo guardarlos en bruto, porque posteriormente puedo tratarlos mejor, siempre que trates los datos y los parsees, perderás información.
  5. Analizar la información de cada unidad de trabajo por separado. Con todos lo datos obtenidos se debe realizar un análisis detallado de cada una de las unidades de trabajo por separado, esto no dará un idea de como se está comportando dicha unidad de trabajo, si existen problemas de tiempo de respuesta en alguno de los elementos involucrados en las operaciones de la unidad de trabajo y cómo podemos hacer crecer los recursos de la plataforma para disminuir los tiempos de respuesta de los distintos elementos y por lo tanto el tiempo de respuesta de la unidad de trabajo. Yo suelo realiza el estudio por separado, actualizando los documentos creados en el paso 1, de esta forma podemos mantener toda la información crítica en dicho documentos, así como crear una bitácora en caso de que empleen mas de un ciclo en el desarrollo del proyecto.
  6. Analizar la información de todas las unidades de trabajo en su conjunto. Una vez se hemos analizado cada uno de las unidades de trabajo, se le debe dar un peso, dependiendo de lo que estemos midiendo, por ejemplo si nos hemos centrado en los tiempos de respuesta, pues podríamos utiliza el tiempo de respuesta de cada unidad de trabajo, con la unidad de trabajo y su peso, creamos un grafo que represente al negocio de la compañía, relacionaremos las distintas unidades de negocio entre si, con la idea de identificar posibles relaciones que confluyan en una misma unidad de trabajo y por lo tanto la conviertan en un posible cuello de botella, pero ya no a nivel de plataforma sino desde el punto de vista del negocio.
  7. Generar informes sobre los análisis. El último paso consiste en crear toda la documentación necesaria, por ahora tenemos un documento donde se describen cada una de las unidades de trabajo, sus operaciones y los elementos de la plataforma que han intervenido en la unidad de trabajo, también disponemos de un esquema, en mi caso una red de colas, por cada una de las unidades de trabajo, otro esquema, yo utilizo grafos de estado para relacionar las distintas unidades de trabajo y por último una cantidad ingente de datos en bruto. Si se ha realizado un buen análisis sencillamente habría que presentar el grafo con los pesos de las unidades de trabajo y los documentos de las unidades críticas.

Planificación de acciones

La última fase de un capacity planning es la planificación de las acciones en base a los resultados obtenidos. Dependiendo de la fase del proyecto en la que nos encontremos, la planificación de acciones pueden provocar que se tenga que replantar la arquitectura de la nueva plataforma, se tenga que realizar un inversión en la plataforma de producción, etc.

De esta fase solo hay que destacar una cosa y es que se debe generar una documentación personalizada para las distintas áreas que intervienen en el desarrollo del proyecto, si no hacemos esto, no conseguiremos transmitir de forma firme y eficiente las carencias, problemas, modificaciones, de la plataforma. En resumen este es el momento donde se debe realizar una gestión del riesgo, si no conseguimos transmitir los posibles riesgos, habremos fracasado en nuestra tarea de capacity planning y por lo tanto, estaremos poniendo en peligro el negocio de nuestra empresa.

Hemos trabajado durante las fases anteriores para construir una herramienta a la que llamaremos Planificación de acciones, la cual deberá ser utilizada por todas las áreas que intervienen en el proyecto, con el fin de ayudarlos en la toma de decisión de algunos de los problemas a los que se enfrenten. Así como hemos conseguido transmitir a las unidades de negocio cuales son las limitaciones de la plataforma para el desarrollo de nuevas oportunidades de negocio.

10 consejos para un capacity planning

Esta es una lista de consejos que suelo dar sobre como tener existo en un capacity planning:

  1. Determina claramente los niveles de servicio que se exigirán a la plataforma.
  2. Un capacity planning no sirve para medir el rendimiento de, por ejemplo, unos discos, sino para ver el impacto que el rendimiento de unos discos tienen sobre el negocio.
  3. La información que generes debe ser de calidad y personalizada, evita realizar documentaciones bíblicas que nadie leerá.
  4. Automatiza la generación de informes.
  5. Determina las dependencias existentes entre los distintos elementos de una plataforma, te ayudará en la identificación de los cuellos de botella.
  6. Gestiona los riesgos, no los percibas.
  7. Piensa siempre en la disponibilidad, la escalabilidad y los costes de la plataforma.
  8. Realizar el capacity planning en la fase de desarrollo de un proyecto es más barato y más fácil implementar sus acciones.
  9. Es mejor un mal capacity planning que no tener ninguno.
  10. Lo importante es el NEGOCIO, la tecnología es solo una herramienta.

Libros que hay que leer

Algunos de los libros que considero indispensables leer, para conocer algo del estado del arte actual son:

Capacity planning : Un caso práctico (II)

En el próximo post realizaremos un ejemplo práctico de cómo ejecutar un capacity planning y profundizaremos en alguno de los puntos críticos, como son la definición de los niveles de servicio o el análisis de la capacidad, así como la creación de la documentación, grafos, redes de colas, etc.

Actualización : Puedes encontrar más información sobre Capacity Planning en el sitio www.capacity-planning-it.com


@CapacityPlanIT

3 Responses

  1. Rosita Fraguel November 18, 2009 / 6:20 pm

    Magnífico post. Espero impaciente el siguiente con los ejemplos mientras leo el “Performance by Design…”. Gracias por el post y la bibliografía.

  2. Abelardo Estañol December 6, 2009 / 3:27 pm

    Me parece un excelente documento, siento que solo falta concluirlo con algunas graficas para ver como se implementa, claro esto para personas como yo que apenas nos iniciamos en algo tan interesante y que debemos manejar quienes estamos a cargo de equipos de computo, de todas formas agradezco que tengas disponible este documento y nos de luz a quienes estamos iniciando.

  3. Nestor Pinzon January 14, 2010 / 12:42 am

    Felicitaciones un trabajo bien resumido y muy juicioso. Gracias por el aporte

Comments are closed.