Llegamos a ustedes gracias a:



Reportajes y análisis

Confesiones verdaderas

[14/08/2009] Es una de las leyes no escritas de la física: en un momento u otro, todos meten la pata.

Pero cuando los profesionales de TI cometen errores, ellos no se andan con juegos. Edificios enteros se oscurecen. Sitios web desaparecen. Compañías se detienen. Porque si vas a meter la pata, mejor que sea memorable.
Siempre les digo a mis muchachos: hey, ustedes van a hacer cosas estúpidas, señala Rich Casselberry, director de operacionesTI en Enterasys, un fabricante de sistemas de red. Está bien hacer algo estúpido si tienes la información errónea. Pero si haces algo estúpido porque eres estúpido, ese es un problema. El truco es no enloquecer, lo cual solo lo hace peor, o tratar de esconderlo. Necesitas averiguar cómo evitar que suceda otra vez.
Hemos reunido algunos de los más egregios ejemplos de profesionales de TI suficientemente valientes para compartir sus metidas de pata con nosotros. Respaldos que salen mal, gente con privilegios de administrador que probablemente no deberían tenerlos, lo que puede ir mal cuando desconectas el equipo equivocado -en algunos casos, hemos oscurecido sus identidades para reservar su vergüenza; otros geeks, sin embargo, están perfectamente deseosos de reconocer sus propios errores de juventud.
Seguro, algunos de estos percances son divertidos en retrospectiva. Pero no se ría muy fuerte. Sabemos que usted probablemente ha cometido algunos peores.
Confesión verdadera de TI No. 1: El caso del misterioso respaldo invisible
Nuestro primer cuento de desventuras involucra un profesional TI veterano que no quiere que su nombre real sea usado, así que solo lo llamaremos Mala Suerte Harry.
Harry tuvo su cuota de desgracias cuando empezó, hace una década, en un gran fabricante de equipos de red en el Noreste. Ese fue el tiempo en el que él cambió una variable ambiental que rompió todo en las aplicaciones financieras de su compañía, ganándose un correo electrónico de su jefe, ordenándole nunca entrar en su sistema otra vez. O cuando estrelló el sistema ERP de núcleo de la compañía sobreescribiendo /dev/tty. Harry dice que después de que accidentalmente desprendió las líneas T1 de la compañía fuera de la pared con su pager, fue prohibido de jamás reingresar al closet de telecomunicaciones.
Pero lo peor sucedió después de que Harry instaló un sistema de respaldo en cinta Emerald. ¿Se molestó en leer el manual? Por favor. Esto era un juego de niños. Simplemente cargue install.exe, y deje que el software haga lo suyo.  Parecía trabajar perfectamente. Cuatro horas después, se completó el primer respaldo y todo se veía bien.
Adelante seis meses. Harry tiene una llamada tarde una noche en su casa, de uno de sus compañeros de trabajo. La cinta de respaldo de esa noche está completamente en blanco, le dice su amigo. Peor aún, los respaldos de las últimas cuatro semanas también están en blanco.
Tal como Harry pronto descubrió, ese programa de respaldo en particular se instala en modo demo por defecto. El modo demo lucía exactamente como el modo real, e incluso tomó la misma cantidad de tiempo que un respaldo real, pero nunca se grabó nada en la cinta -hecho que fue resaltado en el manual, lo que Harry pudo haber visto si lo hubiera leído.
Afortunadamente, la compañía usaba ADP para el procesamiento de nómina. ADP envió de vuelta registros históricos de nómina, así que la firma solo perdió una semana de datos. ¿Las malas noticias? Harry estuvo despierto hasta las 3 am llenando manualmente sobres de nómina, junto con su jefe, el vicepresidente de finanzas, el departamento de nómina entero, y el nuevo CIO de la compañía, a quien conoció por primera vez esa noche.
Tengo que decir que era muy popular, bromea. Creo que la única razón por la cual no me despidieron fue que para ese punto se habían acostumbrado tanto a que anduviera metiendo la pata, que se dieron cuenta que no podía hacer nada bien.
¿Lecciones aprendidas? 1. Examina las restauraciones, no los respaldos, señala Harry. A nadie le importa si el respaldo funciona; les importa si la restauración lo hace. 2. Piensa antes de tipear. 3. Despójese de su pager (o BlackBerry) antes de entrar al closet de telecomunicaciones, solo para estar seguro.
Confesión TI verdadera No. 2: Algunas veces es un conserje quien ayuda a limpiar un desastre de TI
Tarde, una noche en 1997, Josh Stephens estaba trabajando completamente solo en su consola en una gran compañía de telecomunicaciones del Medio Oeste. Stephens estaba haciendo cambios a los switches Cisco Catalyst en el call center del principal cliente de la empresa de telecomunicaciones, que estaba localizado varios estados lejos. Ahí fue que los spanning tree protocols (STP) se fueron por la borda.
Todavía no estoy seguro de cómo lo hice exactamente, pero causé algún tipo de tormenta de transmisión y de pérdida de control de STP que bloqueó no solo el switch en el que estaba trabajando, sino cada uno de los switches en esa instalación, señaló. Esa tormenta de transmisión colapsó cientos de usuarios del call center, dejando a muchos de ellos en medio de llamadas de clientes.
Peor aún, los switches estaban bloqueados duro, lo que requería apagarlos físicamente y un lento plan metódico para volverlos a poner en línea, uno a la vez. El datacenter estaba miles de millas lejos, y no tenía personal TI en el lugar, así que Stephens hizo la siguiente mejor cosa: llamó a mantenimiento.
Terminé encontrando un conserje que tenía llaves para todos mis closets LAN y lo convencí de (a) cuáles dispositivos eran los switches Catalyst, y (b) cómo apagarlos, señala. También le prometí que no lo despedirían por ayudarme.
Aunque el call center estuvo caído por más de una hora, nadie nunca se enteró por qué o quién estuvo detrás del problema, señala Stephens, quien ahora es vicepresidente de tecnología y Jefe Geek (sí, ese es el título real) de SolarWinds, un fabricante de software de administración de redes.
¿Lecciones aprendidas? 1. No haga cambios sin programar una ventana para ellos, incluso si los cambios parecen menores, señala Stephens. 2. Nunca realice un evento de control de cambio sin recursos de TI cerca del equipo que está cambiando. 3. Sea amable con los conserjes. Algún día podrían salvar sus activos.
Confesión TI verdadera No. 3: Levante las manos y aléjese del terminal
Uno de los inevitables hechos de la vida tec es que cuando a los gerentes se les da derechos administrativos para sistemas complejos, cosas malas tienden a suceder.
A finales de los ochentas, Johanna Rothman era directora de desarrollo para un pequeño fabricante de sistemas de procesos distribuidos en el área de Boston. La gerencia de la compañía insistió en sobretiempo obligatorio para todos, incluida Rothman. Después de tres meses de esto, Rothman y su equipo estaban malhumorados y exhaustos, una receta para el desastre.
Una noche, a las 9 pm, me di cuenta que tenía un montón de archivos para borrar, señala. Estoy en un sistema Unix, y el sistema no me dejará borrarlos -no estoy en la raíz. Bueno, yo soy la directora. Tengo la contraseña de raíz. Ingreso al sistema como ?root?. Inicio rm —r, -el repetitivo borrar- desde el directorio que sé es el directorio correcto. Yo sé esto.
Después de algunos minutos, el comando rm deja de trabajar. Rothman, aún ocupada borrando todas las aplicaciones, mata el trabajo, llama al gerente de TI y le explica lo que ha hecho.
Él dice: ?Apártese del teclado. Estoy llegando para iniciar la restauración?. Yo digo: ?Puedo ayudar. ¿Dónde están las cintas?? Él dice: ?Aléjese. Solo váyase. No necesito más de su ayuda.
La restauración toma dos días. Rothman dice que ella durmió hasta tarde ambos días, y le dijo a todos los demás en su equipo que hicieran lo mismo. Ella también dejó disculpas en el correo de voz a todos los desarrolladores.
Creo que la única razón por la que no me despidieron es porque la gerencia estaba muy ocupada con la crisis para darse cuenta de qué lío había hecho, señala Rothman, quien ahora maneja su propio grupo consultor de TI, y mantiene una distancia segura hacia los directorios de raíz Unix.
¿Lección aprendida? 1. No hay razón para que alguien más arriba del nivel de gerente tenga la contraseña de raíz, indica Rothman. 2. Demasiado sobretiempo vuelve a la gente cansada y estúpida. Cuanto más cansados estén, más estúpidos se vuelven.
Confesión TI verdadera No. 4: ¿Qué puede hacer Brown por usted?
Aquí hay uno de esos raros infortunios en los cuales los datos fueron de hecho respaldados. Pero qué es lo que se respaldó es donde las cosas se ponen agrias.
Hace 27 años, David Guggenheim había obtenido su primer trabajo real como administrador de datos biológicos en una firma de consultoría ambiental en el sur de California. En ese tiempo, el hardware de la firma consistía en un PDP-11 y un mainframe IBM 360 de tiempo compartido en Los Angeles, al cual accedían vía dial-up.
Era momento de archivar un importante proyecto desde el mainframe de IBM, así que hice sonar mis nudillos y empecé a teclear con fuerza el JCL (Lenguaje de Control de Trabajo, por sus siglas en inglés) necesario para escribir nuestros datos en cintas, que luego serían enviadas a nuestra oficina, señala. Envié el trabajo, satisfecho de que nuestros datos estarían respaldados de manera segura.
Pocos días después, un conductor de UPS asomó su cabeza por la puerta en la oficina de la firma y gritó: ¿Hay un David Guggenheim aquí?"
El camión de UPS estaba lleno desde el piso hasta el techo con cajas, todas ellas dirigidas a Guggenheim. Él abrió la primera. Estaba llena de tarjetas perforadas. Y también lo estaban el resto de ellas.
Eran nuestros datos del mainframe de IBM, indicó. Para mi horror, me di cuenta de que en lugar de especificar la salida hacia la cinta magnética, especifiqué la salida hacia tarjetas perforadas. Ya no puedo recordar muy bien mi JCL, pero según recuerdo, era la diferencia entre especificar ?=0? en lugar de ?=1?. Estaba absolutamente humillado.
Se pone peor. Unos días después de que todo el equipo se viera involucrado en limpiar suficiente espacio en el suelo para la montaña de cajas, llegó la cuenta. El costo de un trabajo de respaldo en tarjetas perforadas era cerca de mil dólares (y recuerde, aquí estamos hablando de dólares en 1982).
Había hecho estallar nuestro presupuesto, había matado un bosque, y aún así había fracasado en respaldar nuestros datos en cinta, señala Guggenheim, quien ahora es el Dr. David Guggenheim, Ph.D., presidente de 1planet 1ocean, y socio principal de The Ocean Foundation. "Desde entonces, he pasado mi carrera haciendo trabajo ambiental, así que con algo de suerte he pagado mi penitencia por los árboles muertos.
¿Lecciones aprendidas? 1. Pequeños errores pueden causar enormes problemas, así que siga revisando hasta que le duela. 2. Inmediatamente reconozca sus errores; la humildad es una gran maestra. 3. Tome el tiempo para apreciar el humor de una colosal metida de pata, señala Guggenheim. "Hace maravillas para los pinchazos.
Confesión TI verdadera No. 5: Desconecte bajo su propio riesgo
A mediados de los noventa, Jan Aleman era gerente TI interino para una gran compañía de telecomunicaciones en Holanda. Él fue llamado para reemplazar a un CTO que se fue bajo circunstancias menos que voluntarias. Antes de que el ex CTO fuera despedido, sin embargo, ordenó a IBM un sistema failover de 300 mil dólares para el motor de facturación de misión crítica de la compañía.
Un muy buen vendedor de IBM le había vendido este sobrevaluado hardware, asegurándole que si el sistema primario fallaba, se transferiría a la perfección al secundario, señala Aleman. Él dijo que era completamente redundante, que nada podía salir mal. Yo dije: ?De acuerdo, veamos si realmente funciona?.
Así que Aleman desconectó el enchufe de corriente del sistema primario de la pared, justo frente al vendedor de IBM. Todos los sistemas de núcleo de la compañía se oscurecieron. El motor de facturación crítico estuvo caído por el resto de la tarde. Los conmutadores telefónicos aún trabajaban, pero nadie en el área operativa podía hacer algo.
Aunque el sistema failover estaba instalado y corriendo, nadie se había molestado en probarlo. Así que la siguiente cosa que hizo Aleman fue instituir pruebas quincenales del sistema en los fines de semana.
Desconecté la compañía, señala Aleman, quien ahora es CEO de Servoy, un desarrollador de software híbrido (SaaS y en las instalaciones). No hay necesidad de decir que no estaban muy felices, pero nada malo me sucedió a mí. Aún no estoy seguro de cómo conseguí llevar esto a cabo.
¿Lecciones aprendidas? 1. Siempre prueba los sistemas antes de apostar la compañía en ellos (repítalo tanto como sea necesario). 2. Piense dos veces antes de jalar ese cable de energía.
Confesión TI verdadera No. 6: Nunca deje que otro sea el maestro de sus dominios
Alrededor del 2003, más o menos, "Fred" (no es su nombre real) era el gerente de TI de una compañía de cable regional en el Medio Oeste. En ese tiempo, la compañía tenía unos 35 mil suscriptores. Para impulsar sus servicios de negocios, decidió volverse un vendedor de nombres de dominios para Network Solutions.
Como parte de la transición a la venta de nombres de dominio, la compañía redirigió todas las notificaciones de renovación de dominio a una persona en su unidad de soporte de negocios. Nosotros asumimos que solo las notificaciones de dominio de nuestros clientes irían allí, y no los propios dominios de la compañía, señala Fred. Pero como dice el dicho, asumir nos convierte a todos en borricos.
Como era de esperarse, una noche alrededor de las 10 pm todo alrededor del ISP dejó de trabajar: DNS, correo electrónico, los propios sitios web de la compañía, y los sitios que hospedaba para sus clientes de negocios, todo simplemente se desvaneció.
¿El problema? El ISP se había descuidado y no había renovado sus propios dominios. La persona en soporte de negocios asumió que Fred también estaba siendo notificado de las renovaciones (él no lo estaba), y Fred asumió que ya que él no estaba siendo notificado, todo estaba super bien (no lo estaba).
Para cuando diagnosticamos el problema -porque raramente piensas en revisar si tu propio dominio ha expirado- habíamos caído de los servidores de raíz y tomó otras 24 horas completas antes de que todo fuera restaurado, señala Fred.
¿Lecciones aprendidas? 1. Siempre tenga a muchas personas recibiendo alertas importantes. 2. Registre sus dominios por 10 años y probablemente será el problema del siguiente tipo.
Confesión TI verdadera No. 7: No pregunte, no cuente y no deje que le hagan tomar un polígrafo
Hace cuatro años, "Paul" (no es su nombre real), un analista de datos independiente en (sí) el Medio Oeste, estaba trabajando con un cliente de gobierno en un proyecto de análisis de 20 mil dólares. Después de dos meses de trabajo duro, él entregó un borrador preliminar al cliente, y luego se fue a un viaje de trabajo de una semana.
Antes de irse, Paul quemó un disco con todos los datos del proyecto, para poder terminarlo en el hotel durante su viaje. Y como era su costumbre usual en ese tiempo, borró todos los 4GB de datos del proyecto de su disco duro para liberar espacio.
Luego, por supuesto, perdió el disco: 20 mil dólares de trabajo, perdidos en un chispazo. ¿Qué hizo? Lo que cualquier consultor inteligente haría: le cobró al cliente por el proyecto entero, por completo. Y prontamente recibió un cheque.
Pasaron seis meses y no supe nada del cliente, señala Paul. Creí que eso era increíble, porque esperaba recibir comentarios y cambios del borrador. Pasó un año, y nada. Finalmente, dos años después de entregar el borrador, la temida llamada finalmente llegó.
¿Alguna vez va a terminar este proyecto?, escuché del otro lado del teléfono, señala Paul. Yo dije: No hay forma en que pueda respaldar esos datos y recomendaciones originales, ya que han pasado dos años. Nada de la información es válido ahora. Por supuesto, yo sabía muy bien que nunca podría brindar algún dato actualizado o recomendaciones actualizadas basados en los datos originales. Afortunadamente, el cliente aceptó esa explicación, y luego procedió a discutir qué honorarios necesitaba para algún trabajo nuevo.
En su defensa, Paul dice que el borrador preliminar estaba 95% completo, y que el cliente le dijo que ya habían implementado muchas de las recomendaciones que él había hecho.
En estos días, Paul es un autoproclamado loco del respaldo de datos.
En cualquier día tengo unas 10 copias de todos los datos de los proyectos actuales, y puedo restaurar completamente cada archivo de datos del proyecto en el que he trabajado durante los últimos tres años en unos cinco minutos, señala. Aprendí una dura lección que ciertamente no olvidaré pronto.
¿Lecciones aprendidas? 1. Nunca podrá tener suficientes respaldos. 2. Es una buena idea también tener copias físicas a la mano, solo por si acaso. 3. Si pierde todos sus datos antes de haber entregado el producto final, trate de asegurarse de que está trabajando para el gobierno en ese momento. Podrían nunca darse cuenta.
¿Le gustó este artículo? Comparte con nosotros su experiencia enviándonos un mail a editorial@cioperu.pe. Garantizamos confidencialidad, si así lo desea.
Dan Tynan, InfoWorld (US)