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.

Existe un tema que ha sido cuestión de debate desde hace mucho tiempo, y es el si las empresas dependen de los departamentos de TI, o los departamentos de TI existen por las empresas. Es común escuchar a profesionales de TI que creen que se merecen un gran sueldo solo porque “sin computadoras la empresa no puede operar” así como también no es extraño saber de dueños de empresas que ven las TI como un mal necesario, un gasto que hay que hacer.

Creo que ante visiones de este tipo, son los líderes de TI los que se deben acercar a la parte operativa y buscar un acercamiento. ¿Como?  Siguiendo estos consejos:

  • Buscar participar en la toma de decisiones de la organización.
  • Cuidar el lenguaje. Evitar utilizar jerga tecnológica cuando se habla con el negocio.
  • Buscar a los colegas del negocio proactivamente para discutir sobre los problemas que se desean resolver.
  • Participar desde las etapas iniciales en la planeación estratégica, para evitar ser tomados por sorpresa  en cuanto a tiempo y presupuestos.
  • Entender que las TI no son siempre una solución en si misma, sino un medio para que la empresa alcance sus objetivos, y transmitir esto a la organización.

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.

ITIL siempre ha sido un tema que ha llamado mi atención, pero mas me la llama una serie de creencias que he observado que tienen las personas del área de TI, las cuales, son a veces objeto de caza de vendedores de software “ITIL compliance” y consultores que solo quieren vender por vender. Y les comparto algunos puntos de vista muy personales en este post:

  • Los procesos deben entregar valor, un proceso o control, que solo exista con el argumento de “todo se debe documentar” pero que no aporte valor, debe ser revisado o eliminado.
  • El servicio esta por encima del proceso. Si un proceso detiene o dificulta la entrega de un servicio, y mas aun si este servicio es critico para la organización, entonces el proceso debe ser revisado o eliminado.
  • La implementación de ITIL, debe ser para beneficio de la organización entera, no solo para el área de TI. Una vez vi un caso, en donde, con el supuesto de mejorar la atención de service desk, se migro a una herramienta “ITIL compliance” que solo genero quejas de los usuarios, pues de tardarse 2 minutos en abrir un caso en la mesa de ayuda, pasaron a 10 minutos.
  • El software no es la solución a las deficiencias en el servicio, no caigamos en el truco de que un software que cuesta 100 000 resolverá nuestras deficiencias en gestión.
  • ITIL no tiene que ser implementado tal y como lo dicen los libros, se puede adaptar a la organización. ITIL no es una ley, ni un estándar, son un conjunto de mejores practicas.
  • No hay que implementar métricas a diestra y siniestra solo por hacerlo. Debemos escoger aquellas que realmente nos de información valiosa para la mejora continua.
  • No hay necesidad y en ningún libro dice que las cosas se tienen que hacer de la noche a la mañana. El proceso de adopción debe ser hecho al ritmo de la organización, sin afectar las operaciones u otros proyectos en curso.
  • Y por ultimo, apliquemos siempre el sentido común, el menos común de los sentidos.

 

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:

  • Amazon Web Services (ofrece un “free tier” que te permite hacer pruebas con servidores linux y Windows)
  • Citrix Pay-As-You-Grow (ofrece versions de prueba)
  • The rack Space Cloud
  • GoGrid    (Ofrece cedito de $100 usd para pruebas)

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.