Llegamos a ustedes gracias a:



Reportajes y análisis

20 errores de TI que deberían evitarse

[24/10/2008] En el 2004, el entonces CTO de InfoWorld, Chad Dickerson, encuestó a los mejores y más brillantes responsables de sistemas con el objetivo de revelar los 20 errores más frecuentes en TI, que eran recetas infalibles para incurrir en elevados costos, fallar en las fechas de entrega y, en algunos casos, perder el empleo.

Muchas cosas han cambiado en los últimos cuatro años, excepto que los responsables de TI siguen llevando a cabo prácticas erróneas, fruto de la complejidad de las responsabilidades implícitas a su puesto de trabajo. Bajo el dicho hombre precavido vale por dos, a continuación se exponen 20 nuevos errores que los directores de TI deberían evitar en la actualidad.
1. Políticas de contraseña demasiado exigentes
Una política de contraseñas clara y aplicada de forma consistente en toda la organización es esencial para cualquier red. ¿Qué sentido tiene un firewall cuando únicamente se necesita teclear contraseña para entrar en el sistema?
No obstante, una rigurosa política de contraseña también puede ser un arma de doble filo, en el sentido de que si sus requisitos de contraseña son demasiados complejos y draconianos, o si los usuarios tienen que cambiar sus contraseñas muy a menudo, la política puede tener el efecto contrario para la que fue concebida. Los usuarios que tienen que recordar contraseñas terminan escribiéndolas en un cajón o en un post-it. Intente evitar poner en peligro el fin último de su política de contraseña insistiendo en objetivos que nos son realistas.
Además, las contraseñas siguen siendo del tipo 2004, por lo que si, hoy por hoy, quiere tener un mejor control de accesos, piense en la autenticación multifactor.
2. Una mala administración del data center
El orden no suele ser una cualidad de los administradores de sistemas a pesar de que en el datacenter éste es crítico. El cableado de espagueti, los racks sin etiquetar y el equipo huérfano pueden causar problemas serios. El aprovisionamiento sin ningún tipo de orden puede llevar fácilmente al administrador a reconfigurar el servidor equivocado o volver a formatear el volumen incorrecto, por lo que es recomendable tener todo ordenado (y verificar siempre dos veces las conexiones).
La capacidad por tener ordenados los sistemas también significa liberar los servidores de producción de los desktops de los ingenieros, y de los lugares más recónditos del sótano. Gestionar esos activos es trabajo del personal de TI y debería hacerlo con diligencia y gusto. Cerciórese de que el CFO entienda la importancia de mantener un datacenter amplio y que esté lo suficientemente bien equipado como para crecer con el negocio, sin convertirse en una selva.
3. Perder el control sobre los activos de TI críticos
Cuando el equipo de gestión realiza una petición al departamento de TI del tipo: el personal de márketing necesita correr ad-hoc consultas SQL contra la base de datos de producción. Lo hace a pesar de que sabe que lo próximo que ocurrirá es que las consultas que no están bien formuladas sobrecarguen al servidor, con la consiguiente tarea de resolver el problema de rendimiento.
La experiencia y el juicio en la gestión de TI juegan un papel fundamental en todas las decisiones relacionadas con los activos de TI. No doblegar esa responsabilidad ante deseos evitará la confrontación. Una idea mala es mala incluso aunque el equipo directivo no se dé cuenta.
4. Considerar el legacy como una palabra tabú
El personal de TI más joven detesta la idea de que los procesos de misión crítica todavía pueden correr en sistemas de la época de sus abuelos; pero, a menudo, existe un buen argumento para que el personal de TI valore la edad sobre la belleza. Los web services no son tan sexys como el SOA pero un sistema más antiguo que corre de forma fiable y presenta menos riesgos que una marca nueva desconocida.
Actualizar los sistemas heredados puede ser caro. Por ejemplo, el estado de California espera invertir 177 millones de dólares en cambiar la imagen de su sistema de nóminas. De acuerdo con un estudio de IDC, los costos anuales de mantenimiento para los nuevos proyectos de software alcanzan los millones de dólares. En estos tiempos de presupuestos ajustados, no se debería tener prisa por jubilar a los sistemas antes de tiempo.
5. Ignorar el componente humano de la seguridad
En la actualidad, los administradores de red de hoy tienen acceso a una amplia variedad de herramientas de seguridad. Pero como dice el hacker Kevin Mitnick, el punto más débil de cualquier red son sus usuarios. La red más segura también es vulnerable si sus usuarios son engañados para quebrantar la seguridad, por ejemplo, al facilitar contraseñas u otra información confidencial por teléfono.
Por esta razón, la educación del usuario debería ser la piedra angular de la política de seguridad. Es necesario concienciar a los usuarios de los posibles ataques de ingeniería social, los riesgos implícitos, y cómo responder a los mismos; así como animarles a que informen inmediatamente sobre cualquier acción sospechosa. En esta era del phising y del robo de identidad, la seguridad es una responsabilidad que debe ser compartida por todos.
6. Crear empleados imprescindibles
A pesar de lo reconfortante que es saber que un único empleado entiende todos los sistemas, nunca debería estar entre los intereses de una compañía dejar que su personal de TI se convierta en imprescindible para la entidad. Por ejemplo, el antiguo empleado de la Ciudad de San Francisco, Terry Childs, que fue encarcelado por negarse a revelar contraseñas de red que únicamente él conocía.
Además, los empleados que tienen demasiado valor en determinados puestos pueden también dejar pasar oportunidades para avanzar en su carrera profesional. Más que crear superestrellas especializadas, se debería promover la colaboración y la formación para que toda la plantilla trabaje en una amplia variedad de equipos y proyectos.
Un personal de TI diverso y capacitado no solo estará más satisfecho,sino que además contribuirá mejor al desarrollo del negocio.
7. Plantear problemas en vez de soluciones
¿Las advertencias sobre las vulnerabilidades críticas caen en saco roto? Identificar los riesgos para la seguridad y los posibles puntos de falla es una parte importante de la gestión de TI, pero el trabajo no acaba aquí. Los problemas sin solución aparente pueden poner a la defensiva al equipo de gestión. Por ello, antes de informar sobre cualquier problema, es recomendable trazar un plan concreto de acción que lo resuelva y presentarlo, en el momento de exponer el incidente al equipo directivo.
Para ganarse el apoyo de la dirección, siempre es conveniente explicar las preocupaciones en términos de riesgo para el negocio y ofrecer cifras que apoyen la exposición. Y, además de explicar lo que costaría solucionar el problema, se deberían también exponer el costo que tendría para el negocio no resolverlo.
8. Entrar como administrador
En el 2008 todavía se sigue cometiendo uno de los errores más antiguos que suele cometer el personal de TI sin experiencia. El personal, que habitualmente se conectan al administrador "o la raíz" para tareas menores, representa un riesgo que puede acabar con datos valiosos o sistemas completos por accidente, y este hábito todavía persiste.
Por suerte, los sistemas operativos modernos — entre los que se incluyen Mac OS X, Ubuntu, y Windows Vista- han tomado medidas para contener esta práctica, al comercializarse con los privilegios de más alto nivel por defecto. En vez de funcionar como la raíz todo el tiempo, el personal de TI debe introducir la contraseña administrativa
cada vez que tienen que realizar una tarea de mantenimiento de los sistemas principales. Esto puede ser una molestia, pero, desde luego, es la única práctica correcta. Ya es hora de que todo el personal de TI escuche la indirecta.
9. Correr riesgos con tecnología última generación no probada
Con los programas beta en un lugar común, la tentación de contar con herramientas de última generación en sistemas de producción puede ser enorme. No ceda. El personal de TI de las empresas debería encontrar soluciones, sin dejarse llevar por las apariencias. Está bien ser un adoptador temprano de tecnología en tu escritorio, pero el datacenter no es un lugar para jugar.
En lugar de eso, haga una aproximación moderada. Conozca las últimas novedades, pero no despliegue nuevas herramientas para utilizarlas en sistemas de producción hasta que las haya probado. El experimento con los proyectos piloto son siempre a nivel departamental. También, asegúrese de que exista soporte, ya que a nadie le gusta ser abandonado a su suerte cuando los últimos y más estupendos avances ya no tienen su máxima audiencia.
10. Reinventar la rueda
No hay mejor forma de asegurarnos de la agilidad del personal de TI que haciéndose cargo de las propias necesidades de software. Pero, demasiado a menudo, las compañías emplean desarrolladores de software únicamente para malgastar su talento en los proyectos equivocados.  
Si no desarrolla su propio navegador web o base de datos relacional, entonces, ¿por qué muchas compañías gastan sus energías en desarrollar aplicaciones de CRM personalizadas o sistemas de gestión de contenidos, cuando ya existen muchos productos de calidad en el mercado que dan respuesta a estas necesidades?
El desarrollo in-house de software debería limitarse a proyectos que pudieran aportar una ventaja competitiva. Las funciones que no son únicas del negocio se gestionan mejor con software estándar. Nos equivocamos sin pensamos que lo podemos hacer con software de código abierto y los adaptamos a nuestra necesidades. Los proyectos de desarrollo redundantes solo nos alejan del verdadero objetivo del negocio.
11. Perder el rastro de los usuarios móviles
Las herramientas conectadas a una red pueden facilitar las actualizaciones de seguridad, al hacer por la noche los backups, e incluso gestionar la instalación del software de los usuarios en toda la organización, por supuesto de aquellos que tengan sus PC conectada
a la red LAN corporativa. Pero, lo más importante es saber ¿qué pasa con aquellos usuarios que pasan la mayoría de su tiempo fuera de su sitio?
La movilidad y el teletrabajo han cambiado las reglas del juego para la gestión de sistemas, la seguridad de red y la continuidad del negocio. Los portátiles que carecen de parches de seguridad actuales son el blanco del malware. Archivos de los que nunca se ha hecho backup pueden ser horas perdidas de productividad. Pero lo más importante es ¿qué ocurrirá con la información sensible almacenada en caso de robo o pérdida? Las políticas de TI automatizadas no ofrecen consuelo si logran abrir las brechas en la información.
12. Tirar el dinero en poner parches con soluciones de cumplimiento con la normativa
A la hora de cumplir con la normativa impuesta por Sarbanes-Oxley, HIPAA, y otras leyes, muchas empresas se repliegan al método de la tirita. Pero tirar dinero en objetivos nebulosos de cumplimiento con la normativa consume fondos que, de otra manera, podría utilizarse en proyectos más tangibles. Aunque, en ocasiones, una fecha límite de un organismo regulador exige un rápido cumplimiento, en general es mejor hacer una aproximación integral.
Cuando se planea la estrategia de cumplimiento de la normativa, se piensa en términos de políticas y procedimientos globales más que en puntos de soluciones dirigidos a auditorías específicas. Hay que tratar de eliminar los procesos redundantes y el mantenimiento de registros manual, y centrarse en formas para automatizar el proceso de cumplimiento con la normativa de una forma continuada. Hacerlo de otra manera es solo tirar el dinero.
13. Subestimar la importancia de escalar los sistemas
A pesar de uno puede pensar que ha planificado sus sistemas con capacidad para escalar, la realidad es que éstos crecen con las áreas de problemas ocultas, que le pueden llegar a obsesionar a medida que el negocio crece. Ante todo y sobre todo, sea consciente de las interdependencias de proceso. Un sistema es solo tan robusto como su componente menos confiable. En concreto, cualquier proceso que requiere la intervención humana será un cuello de botella para cualquier proceso automatizado del que depende, no importa cuánto hardware invierta en la tarea.
Tomar la vía rápida es la receta segura para futuros quebraderos de cabeza. Resístase a la tentación de correr una base de datos departamental en un servidor web infrautilizado o dejar una doble estación de trabajo abierta como almacenamiento en red. El proyecto
más insignificante podría convertirse fácilmente en el recurso de misión crítica del mañana, dejándole con la tarea nada envidiable de separar procesos e infraestructura.
14. Administrar mal su estrategia SaaS
Salesforce.com demostró que SaaS (el software como servicio) tiene sólidas bases en la informática empresarial. Cuando se compara con el software tradicional de escritorio, el modelo bajo demanda ofrece a los clientes una baja barrera de entrada y, prácticamente, ningún costo de mantenimiento. Por ello, no es de extrañar entonces, que un número creciente de vendedores de software haya comenzado a ofrecer productos alojados en numerosas categorías de software. Si al menos no ha considerado las opciones SaaS, está perjudicando a su negocio. Aunque, por otro lado, demasiados SaaS, puede ser un problema; ya que los servicios alojados no interoperan y el software de escritorio y el nivel de personalización ofrecida por los vendedores SaaS varían. Por esta razón es conveniente tener presente que SaaS es solo un modelo de negocio y que no es una ganga, si el software no está maduro.
15. No elaborar perfiles de código
El rendimiento relativo es un debate perenne entre programadores. ¿Realmente el código escrito para un lenguaje corre tan bien como el código equivalente escrito para otro?
Por cada aplicación, que sufre un problema de rendimiento debido a un defecto subyacente en el lenguaje, otras innumerables son difundidas con algoritmos mal diseñados y otros problemas de velocidad creados por el programador.
La localización de estos lugares conflictivos es el objetivo de la elaboración de perfiles del código y es lo que lo hace realmente tan crítico. Hasta que no se haya identificado las partes más lentas del código, cualquier intento de optimizarlo será en vano.
16. No beneficiarse de la virtualización
Si no aprovecha las ventajas que le ofrece la virtualización, lo único que está haciendo es complicándose las cosas. Las máquinas virtuales eran un factor de venta clave de los primeros mainframes, pero hoy funcionalidades similares están disponibles en el hardware y sistemas operativos estándar, a menudo sin ningún cargo. La colocación de múltiples máquinas virtuales en una sola máquina física incrementa el ratio de la utilización del sistema, ofreciendo un mayor retorno de la inversión. La virtualización también le permite, de forma fácil, el suministro de nuevos sistemas y crear entornos seguros para probar el nuevo software y configuraciones del sistema operativo.
Algunos vendedores pueden decirle que sus productos no pueden ser instalados en un entorno virtualizado. En ese caso, es preferible dirigir su mirada a otro proveedor, ya que la virtualización es una tecnología demasiado buena como para tener que renunciar a ella.
17. Confiar demasiado en un único fabricante
Es fácil ver por qué algunas empresas siguen confiando en un mismo vendedor una y otra vez para dar respuesta a todas sus necesidades de TI. A los grandes fabricantes de TI les encanta ofrecer soluciones integradas. Además, un contrato de soporte, que promete "un cuello que estrangular", siempre será un revulsivo para los administradores sobrecargados de trabajo. Pero, si ese contrato le hace depender de productos inmaduros, que están fuera del core de negocio del vendedor, podría saturarle con más trabajo.
Rara vez todas las entradas en una línea de producto TI empresarial son creada iguales, aunque sean de un mismo fabricante, y conformarse con una solución mediocre puede tener repercusiones a largo plazo. Aunque tenga sentido que la empresa dé una consideración preferente a los socios del fabricante ya presente en su infraestructura, conviene recordar que no hay nada malo en decir no con educación, si la mejor solución dentro de una gama de productos se encuentran en la oferta de otro proveedor.
18. Seguir adelante con proyectos condenados al fracaso
No toda iniciativa de TI tiene éxito. Aprenda a reconocer los signos de problema y a actuar con decisión. Un proyecto puede fallar por mil motivos diferentes, pero seguir invirtiendo dinero en una iniciativa condenada al fracaso solo agravará los problemas.
Por ejemplo, el FBI gastó cuatro años y más de 100 millones de dólares en el sistema de mantenimiento de registro electrónico, conocido como Archivo de Caso Virtual (VCF), a pesar de las repetidas advertencias de que el proyecto no tenía sentido. Cuando el FBI finalmente tiró la toalla en el 2005, VCF no estaba ni de lejos cerca de darse por finalizado. No deje que esto suceda. Tenga una estrategia de salida lista para cada proyecto, y asegúrese de que pueda ponerla en marcha antes de que un falso arranque haga del proyecto de TI un desastre.
19. No planificar los picos de energía
Las TI sostenibles no solo contribuyen a salvar el planeta sino que también permiten hacer una buena planificación de los recursos. Cuando los costos de la energía entran en una espiral sin control, éstos suponen una amenaza para la agilidad de negocio a la vez que limitan su crecimiento. No espere que su datacenter alcance el máximo de su capacidad para comenzar a buscar formas de reducir el consumo
de energía. Desde las CPU hasta los dispositivos de almacenamiento, desde la memoria hasta los monitores, la eficiencia energética debería ser una consideración clave para todas las nuevas compras de hardware. No limite la búsqueda únicamente al hardware; las soluciones de software como virtualization y SaaS pueden ayudar a consolidar servidores y a reducir aún más su consumo de energía. El resultado no solo será un planeta más sostenible, sino también una empresa más sostenible.
20. Fijar calendarios de productos no realistas
Cuando se planifican los proyectos de TI, en ocasiones, la propia confianza y entusiasmo pueden ser los peores enemigos. Una estimación del tiempo optimista puede fácilmente poner en peligro la entrega del producto. Por este motivo, es preferible establecer tiempos amplios que permitan completar objetivos de proyecto, incluso si éstos parecen demasiado simples desde un principio. Siempre es mejor sobreentregar que sobreacometer.
La flexibilidad a menudo será la llave para el éxito del proyecto. Asegúrese de identificar las áreas de riesgo potencial mucho antes de que se fijen los plazos, sobre todo, si trabaja con vendedores externos. Fijar expectativas realistas durante el ciclo de vida del proyecto, puede evitar el verse forzado a lanzar el software incorrecto o con funcionalidades incompletas a medida que se van cumpliendo los plazos de entrega.
CIO, España