Simple, pero muy rara en la práctica, es la regla 3-2-1 al momento de hacer respaldos. Personalmente no conozco más de una empresa donde los respaldos de hagan de esta manera, pero si conozco algunas que han pasado momentos en extremo difíciles por haber perdido información. La regla consiste en:

  • 3 copias de cualquier cosa que nos importe.
  • 2 formatos diferentes.
  • 1 respaldo off-site.

Simple en extremo. Llevémosla a la práctica si como administradores de TI queremos evitarnos un buen dolor de cabeza o ser despedidos.

La recuperación de desastres (DR) es constantemente simplificada al hecho de tener respaldos. Esto es algo en lo que hay que tener cuidado. Personalmente he visto iniciativas que pretenden ser solución ante desastres que han fracasado debido a que se omiten ciertos conceptos básicos en la etapa de diseño. Conceptos que me gustaría rescatar hoy:

  • Recovery Time Objetive: es la duración en tiempo y el nivel de servicio en el que un servicio debe restaurarse después de un desastre para evitar consecuencias inaceptables. Esto se debe acordar con el cliente interno para evitar falsas expectativas o vacilar en el momento de mover el sistema de producción a DR.
  • Recovery Point Objective: el nivel aceptable de perdida de datos medido en tiempo. Estará en función del tiempo que se tarda en tomar la decisión de migrar a DR y el tipo de esquema de DR en uso. Las soluciones mas completas con respaldos síncronos (Los datos se escriben en 2 sitios al mismo tiempo) son más caras que los esquemas de respaldo asíncronos (existe un retraso en la copia a un segundo sitio).

Las combinaciones que se pueden crear con mezclas de presupuesto y necesidades son numerosas. Pero en cualquier caso, se deben tener en cuenta las necesidades del negocio.

En lo personal, considero que los componentes mas críticos de un esquema de recuperación ante desastres, son, primero, mantener iguales las configuraciones en los sistemas de producción y DR, y segundo, hacer ejercicios donde se pruebe bajo circunstancias reales que el sistema de recuperación de desastres funciona. Es frustrante cuando se tiene que activar un DR y nos encontramos con que no funciona en lo absoluto o no funciona como debería. Los ejercicios deben practicarse por que, por que no es raro que en la practica surjan escenarios que no se contemplan en la documentación.

Encontré un whitepaper bastante interesante acerca de la reducción de costos en TI. Muchas veces, como administradores de sistemas, esto no nos preocupa mucho, pero ¿Qué pasara cuando seamos gerentes?, ¿Estamos listos para dar un par de propuestas de reducción de costos?

Algunos de los puntos que en lo personal me llamaron la atención son:

  1. Use software Open Source.
  2. Eliminar servicios. ¿Realmente necesitas una mesa de ayuda las 24 horas?
  3. Revisar la movilidad, como por ejemplo, los planes de telefonía.
  4. Moverse al cloud computing. Pagar solo por lo que se usa.
  5. Regatee. La mayoría de los proovedores están dispuestos a negociar, sobre todo si se les comenta que otra oferta esta tocando la puerta.
  6. Vuélvase verde, a través, por ejemplo, de la consolidación de servidores.
  7. Elimine Legacy Services innecesarios.
  8. Elimine reportes innecesarios en papel.
  9. Revalúe sus contratos.
  10. Evalué su estrategia de administración de la capacidad.
  11. Lleve a cabo un inventario, hay que saber lo que se tiene y aprovecharlo.
  12. Considere lo «suficientemente bueno». No gastar en características que no se necesitan.
  13. Adquiera servicios en países con costos de mano de obra más bajos.
  14. Automatice tareas de IT
  15. Use thin clients.

Si deseas descargar el Whitepaper, puedo hacerlo en este link.

El concepto de moda hoy en la publicidad entre fabricantes de hardware y software es «la nube». En lo personal me parece que el concepto no es bien entendido del todo, mas no entrare en discusiones y hoy escribiré acerca de los centros de datos en la nube.

En días pasados tuve la oportunidad de asistir al Amazon Web Services Wokshop y probar la potencia de este producto y realmente quede sorprendido.

En cuestiones de capacidad del centro de datos, hasta ahora las empresas adoptaban 2 posturas:

  • El enfoque reactivo: hacer modificaciones en la infraestructura solo hasta que la misma se ve sobre pasada. Este enfoque es muy riesgoso pues puede paralizar la operación.
  • El enfoque proactivo: adquirir la infraestructura por adelantada, «prediciendo» la demanda. Este enfoque es costoso pues si la estimación es incorrecta se tendrá más de lo que se necesita y esto es caro.

En un centro de datos en la nube, es posible crear servidores sobre demanda al instante, pero sobre todo efectuar cambios en los mismos que no seria posibles al momento en un centro de datos físico. Algunas ventajas del esquema en la nube-elástico-sobredemanda son:

  • Aumentar o disminuir memoria, procesamiento y discos disponibles a un servidor.
  • Eliminar una maquina virtual y volverla a crear,
  • Elegir entre cientos de imágenes con software precargado.
  • Tiempos de entrega del servidor: en un escenario físico, tener un servidor listo puede tomar semanas. En un escenario en la nube, minutos.
  • Cuestiones como el espacio en rack, suministro de electricidad, aire acondicionado se olvidan, permitiendo al administrador enfocarse en la entrega de servicios de valor. Este es un detalle que los escenarios en la nube tiene sobre infraestructuras virtuales on-premise.
  • Reducción del costo total de propiedad. Se paga solo por lo que se usa.

Si estas interesado, en saber mas o hacer pruebas, he revisado los siguientes productos y los puedo recomendar:

A pesar de que la especialización es importante, hay ciertas habilidades de las que cualquier administrador del sistema debe ser consiente y buscar desarrollarlas por lo menos, un poco, para realizar mejor su trabajo:

  1. Habilidades de comunicación y de trato con las personas: trabajamos con personas, servimos a las personas. ¿Algo más?
  2. Ser capaz de programar o crear scripts: si no eres desarrollador, debes saber por lo menos un poco de scripting. La programación puede ser muy útil, sobre todo en la realización de tareas repetitivas. El punto es ser listo, no trabajar mas duro.
  3. Conocimientos en respaldos de información y recuperación de desastres: saber como y tener por lo menos un plan para recuperar nuestros sistemas en caso de fallo es fundamental si no queremos ser despedidos.
  4. Conocimientos en administración de proyectos: sin necesidad de ser un Project manager, nunca esta de mas tener habilidades para calendarizar, estimar recursos, determinar necesidades del cliente, planear con respecto del riesgo, etcétera.
  5. Ser capaz de comunicarse en términos de negocio y no técnicos: debemos entender, que en la mayoría de las empresas, los servicios de TI son generalmente de apoyo y no básicos, por lo que debemos saber comunicar lo que nuestro trabajo aporta al negocio en términos que valor agregado, reducción de costos, aumento de los ingresos o mejor servicio al cliente.
  6. Saber documentar: en términos técnicos para otros administradores de sistemas y al nivel del usuario final, cuando se liberan nuevos servicios.
  7. Conocimientos de cableado estructurado: no es necesario ser el que ejecuta esta tarea, pero se debe saber que es lo correcto y lo incorrecto, por lo menos para supervisar una obra.
  8. Conocimientos de redes: saber hacer un diagnostico básico de un problema de conectividad.
  9. Conocimientos de reparación de computadoras: aunque ya seas administrador de Exchange o de AIX, esto es lo mínimo que se puede esperar de cualquier profesional de TI.
  10. Bases de datos: select, insert, update, delete, son comandos de SQL que debes saber utilizar, siempre hay que estar listos para ofrecer una solución basada en bases de datos, aunque sea a pequeña escala.

Microsoft Operations Framework

28 noviembre 2011

Con relación a la última entrada publicada, me gustaría añadir un marco de trabajo que me pareció bastante práctico y preciso para la administración de los servicios de TI. Se trata de Microsoft Operations Framework (MOF), un conjunto de mejores prácticas, principios y actividades que provén una serie de lineamientos para alcanzar la confiabilidad en las soluciones y servicios de IT.

Su objetivo es proveer a las organizaciones de IT los lineamientos que les ayuden a crear, operar y soportar los servicios de IT, mientras se asegura que las inversiones en este campo entreguen el valor esperado a un nivel aceptable de riesgo.

MOF propone un ciclo de vida para los servicios de TI, compuesto por las fases de planear, entregar, operar y administrar. Cada fase se compone de varias funciones de Service Management, las cuales se pueden apreciar en la siguiente figura:

 

Si deseas mas información para aplicar en tu empresa o departamento, puedes visitar el sitio oficial de MOF en Microsoft aquí.

Cuando buscamos nuevas formas de administrar el caos de TI en nuestras empresas, lo más usual es pensar en ITIL, y lamentablemente creemos que es la solución a todo, cuando no lo es, ya que existen otros estándares y normas que podrían cubrir mejor necesidades más concretas. Los siguientes son algunos ejemplos:

  • Val IT: es un conjunto de documentos que proveen un marco de trabajo para el gobierno de las inversiones en TI. Dicho de otra forma, ofrece un conjunto de buenas prácticas y guías generalmente aceptadas para ayudar a los directores y ejecutivos a alcanzar la máxima rentabilidad de sus inversiones en TI.
  • BMIS: modelo para la administración de la seguridad de la información.
  • RISK IT: herramienta practica para la gestión de riesgos. Proporciona la visión de todos los riesgos relacionados con el uso de las TI.
  • COBIT: es un marco de trabajo de gobernabilidad de TI y conjunto de herramientas que permiten a los gerentes disminuir la brecha entre requerimientos de control, problemas técnicos y riesgos de negocio. Otros los definen como el conjunto de mejores prácticas para el manejo de información.
  • ISO 38500: el estándar ISO para la gobernabilidad de las tecnologías de información. Proporciona un conjunto de principios a ser usados cuando se evalué, dirija y monitoree el uso de las TI en las organizaciones.

Con información de Wikipedia, kybeleconsulting.com e ISACA.org.

En el entorno de la TI, es muy común implementar cambios: nuevas aplicaciones, nuevas versiones, nuevos procesos, etcétera. Y como responsables muchas veces de estos cambios, no sabemos como promoverlos.

Hoy les comparto un video que me pareció muy interesante, con algunas consideraciones que debemos observar para disminuir la resistencia al cambio.

Imagina que tu jefe te solicita enviarle lo mas rápido posible de un reporte del avance de un proyecto. Desea saber que tareas van en tiempo y cuales no, quien es responsable de cada tarea, como se están cumpliendo los objetivos y en general como progresa ese gran proyecto lleno de expectativas.

Una opción podria ser, presentar a tu jefe el archivo de MS Project o Primavera con la información del proyecto; pero es muy probable que no lo entienda por que tiene otras cosas en la cabeza o te diga que eso no es un reporte y que le hiciste perder el tiempo. A mas alto nivel, menos importan los detalles, lo digo por experiencia.

Tu segunda opcion es desarrollar una vistosa presentación con gráficas y mucha información. Pero esto consumira mucho de tu tiempo.

Afortunadamente esto ya le sucedió a alguien, y escribió el libro «One Page Project Manager for IT Projects», el cual explica de manera muy sencilla y practica como poner casi toda la información relevante del proyecto en una sola hoja de calculo, incluyendo información del cumplimiento de las tareas a través del tiempo, objetivos y costos. No tiene mas de 150 paginas y explica de manera muy sencilla como hacer la plantilla, como interpretarla y algunos casos prácticos.

La verdad lo recomiendo mucho. Si desean ver mas información en Amazon pueden entrar haciendo clic aqui.

Si deseas comprar la plantilla para descarga, es posible desde la pagina del autor. Enlace.

El Software como un servicio, es según la Wikipedia «un modelo de distribución de software en donde la compañía de TI provee el servicio de mantenimiento, operación diaria y soporte del software usado por el cliente». En la mayoría de los casos se accede a ellas a través de la web, y en pocas ocasiones requieren de instalar algo en nuestra computadora. En algunos medios también se le llama software sobre demanda (on-demand) Ejemplo son zoho.com, Google Apps, Salesforce, Project Open y SysAid,

Ventajas

  • Los tiempos de puesta en marcha son menores.
  • No hay necesidad de mantenimiento al software. Gastos menores por este concepto.
  • La migración de versiones esta a cargo del proveedor.
  • Seguridad: Es más probable que pierdas información valiosa por fallas en tu equipo, que por deficiencias en el servicio de un proveedor de SaaS. Amenazas como virus o fallas en hardware son más latentes en computadoras de escritorio que en servidores. Esto en el caso de que tu empresa no cuente con mecanismos de respaldo.

Desventajas

  • En hojas de cálculo, dudo que las versiones en línea tengan el mismo poder de MS Excel o Lotus. Hay áreas de oportunidad en flujos de trabajo complejos.
  • Nivel de confianza bajo en datos que pudieran ser críticos para el negocio. Información no cifrada podría se interceptada.
  • Posibilidad de incumplimiento de los niveles de servicio, y no tener a quien reclamarle si nuestro proveedor esta en otro país.
  • Si el servicio de internet no esta disponible, probablemente no lo estará el de SaaS.

Si deseas saber más:

Calculadora de ahorro de costos de Google Apps. Clic aquí.

Directorio de Software como servicio. PortalSaas.com.

SaaSmania. Blog especializado en el tema.