Adrian Sanchez Viveros Este serie de tres entradas analiza el libro El Cisne Negro: El Impacto De Lo Altamente Improbable  por Nassim Nicholas Taleb. Capítulo 16 – La estética de lo aleatorio  Las apariencias engañan? El León no es como lo pintan? – frases trilladas, antiguas que bien, de algún modo el autor comenta que la constante es siempre la constante. No hay absolutos; esto lo puedo percibir a lo largo de éste capítulo donde hace mención el autor que al final, las personas que salen airosas son quienes tienen la capacidad de deducir las consecuencias y el grado de importancia de las ideas – el auténtico valor de las mismas son visibles para éstas personas. Capítulo 17 – Los locos de Locke o las curvas de campana en los lugares equívocos Se desea estar más o menos en lo correcto, que perfectamente equivocado. El autor comenta perfectamente lo que debe realizar con la teoría – ésta se debe considerar como un medicamento, donde a veces no es requerida o necesaria, o es necesaria y fundamental para lograr el alivio deseado o en el peor de los casos, pudiera hasta ser letal. Las teorías se utilizan con moderación, con precaución y supervisadas por un SME. Capítulo 18 – La incertidumbre del farsante Creo firmemente que el ser humano no tenemos la facultad de predecir, si bien, con previos conocimientos, nos damos una idea de las consecuencias, pero debe quedarnos, como seres humanos, muy claro y con los pies en la tierra que nadie puede evitar que el sol salga al día siguiente, no puedo hacer nada si hay vida extraterrestre y nada puedo hacer ante la posibilidad que un Alíen se adueñe de mi cerebro. Capítulo 19 – Mitad y mitad o como ser ecuánime con el Cisne Negro  En un análisis de riesgos que elaboré recientemente para una empresa, comentamos lo importante que era conocer en gran medida éstos mismos – por supuesto que como SME, puedo indicar en mi reporte la probabilidad de ocurrencia Vs la jerarquización de la amenaza de tal modo que, se pueda tener una visibilidad clara de lo que con mayor probabilidad pudiera ocurrir en el Centro de Datos u Centro de Operaciones del cliente. Indica el autor que le preocupan menos los riesgos anunciados y sensacionales, más los maliciosos y ocultos. Se le tiene mayor temor a la diabetes que al terrorismo, por poner o citar un ejemplo. Y creo estar de acuerdo; su terminología me hizo recordar el programa televisivo 1000 formas de morir – donde la introducción del mismo indica que es un milagro que estemos vivos ante la gran cantidad de amenazas probables de ocurrencia – el autor refiere que el tiempo de olvido del hecho de estar con vida es muy poco, dado que es algo de extraordinaria buena suerte, un suceso remoto, una ocurrencia del azar de proporciones monumentales. Preocupemos nuestro tiempo más en los dólares que en los centavos. Conclusiones – Mi perspectiva. Considero que, como todos los libros y autores, narran y describen de acuerdo a experiencias vividas, investigaciones, ensayos, entre otras cosas; no es mi postura criticar al autor y su libro, solo retomar los puntos en los que estoy de acuerdo con el tema. Me gusta el enfoque que da al momento de explicar cómo los seres humanos no estamos listos para lo inesperado. En todo sentido, tiene razón – el Cisne Negro, inesperado, que sucede de muy de vez en cuando y que de alguna forma, trae cosas positivas o negativas, sin dejar de ser trascendente, es lo que al ser humano lo tiene poco o nulamente preparado para reaccionar – me queda muy claro con la explicación del autor, donde expone prácticamente lo sucedido de hace 13 años en las torres gemelas. Nadie estaba preparado para lo inesperado, inusual, desequilibrante para la cotidiana vida humana. Basta recordar mis días en Sun Microsystems, donde en el área de Incident Management, nos percatamos de muchos eventos inesperados al momento de ocurrir la caída del sistema más importante para Radiomovil Dipsa – el modelo 15 K de prepago – y para variar, el Clúster no respondió como debía. El diagnóstico del Ingeniero de Servicio 15 discos dañados y por tanto, levantar el requerimiento inmediato de entrega en el tiempo más corto posible por lo delicado del tema, Radiomovil no podía facturar en su sistema de prepago. Mientras los discos eran solicitados, se intentaba ganar tiempo con el almacén en sitio, para ir reemplazando los discos dañados – mientras que el Ingeniero especialista en HW, ya estaba en camino. Se estimaba que en 45 minutos, tanto la cantidad de discos estuviera en sitio como el Ing. especialista también y así sucedió, tal y como se tenía previsto – al reemplazar todos los discos en una ventana de tiempo otorgada por el tiempo por la criticidad, en horas pico, se estimaba que el problema quedaría resuelto en 2 horas, en lo que los discos eran cambiados y hacían la sincronización completa. Por otro lado, los especialistas en el clúster, que no funcionó, también estaban ya trabajando en línea con soporte de 3er nivel para solucionar el tema. Todo iba de acuerdo al plan de acción trazado en unos minutos, que por experiencias previas, se sabía que se tenía que hacer – pero no se contaba con lo inesperado – 5 discos llegaron DOA (Death of arraving); esto significó que el problema, tardaría más de dos horas en solucionarse. Los 5 discos dañados de fábrica se tuvieron que pedir inclusive prestados de otros clientes, a tal grado que el problema fuera mitigado lo antes posible – la penalización que Dipsa preparaba para Sun, estaba siendo cocinada. Recuerdo en ese evento que si bien, el equipo fue restaurado, el clúster se reparó y de alguna manera, tras negociaciones ríspidas con el Cliente, se dejó claro que siempre la ocurrencia de eventos inesperados suceden y causan un impacto severo tanto en tiempo, dinero y esfuerzo. El diagnóstico Post-mortem que se elaboró debería incluir un plan de mitigación de lo que no funcionó para que ello no volviera a ocurrir. En el sistema que utilizamos para el registro de Incidentes, se quedó guardado en la Base de Datos para tener como referencia el problema y como se solucionó para posibles futuros eventos con otros Clientes. Sun tuvo que pagar una penalización por ello y a su vez, planear el tener un stock con la cantidad de discos similar a las que estaban en los equipos productivos. Así como también, realizar ejercicios programados en periodos más cortos, de simulación de caída de la 15 K, para revisar que el clúster funcionara adecuadamente. El autor también hace referencia de las ocurrencias de éxito de Google y de YouTube como Cisnes Negros, así como la caída de la bolsa en los 80s, que si bien, en algunos casos fue negativo el efecto o en otros casos, fue positivo. Recuero también, cuando estuve en los últimos días de Sun, al leer esos párrafos que comentó el autor, cuando sucedió algo parecido en IBM al principio de los 90s, la especulación de mucha gente al ver como despedían personal, uno tras otro. Especialistas, Gerentes, Operadores, de cualquier nivel y rango organizacional, salían de Sun mientras se rumoraba la posible de compra de la compañía por la oferta lanzada por IBM. Los altos ejecutivos de Sun, hicieron una campaña de mitigación del miedo a ser despedido internamente en la compañía, se hicieron eventos de días completos, comida a más no poder, y en cada uno de ellos, la misma frase repetida en correos – no escuchar ni hacer caso de rumores, Sun se reinventará y no se venderá. La reestructura que está viviendo Sun permitirá seguir adelante imbatible – Oh tristeza – lo que en un momento dado decía que no sucedería; un domingo por la mañana, se recibe el email más desconcertante que he leído – Jonathan Schwartz da el anuncio de la venta de Sun a Oracle. Oh My God! Todo se esperaba, menos que Oracle, una empresa dedicada a vender SW, para BD y ERPs, entre al negocio de HW donde no se tiene la vasta experiencia del mercado como un HP o un IBM; en fin, nadie estaba preparado para la noticia después de que nos hicieron entender que Sun no se vendería, al menos hasta el viernes anterior del email enviado por el Ejecutivo. En el transcurso de ese evento, recuerdo haber leído muchas noticias en Internet acerca de esos rumores, que si IBM, que si HP, en fin. Una serie de expertos en la materia, que como indica el autor, solo hacen referencia a lo ya sabido y sin esperarlo, la empresa fue adquirida por un especialista en SW. Un punto del cual, me gustó como el autor lo expone, es el caso de aquellos alumnos que siempre tienen impecable su boleta de calificaciones – llena de 10, y en uno u otro caso, manchada por un 9. Lo peor aún, alumnos que en su momento, se jactaron de tener maravillosas calificaciones, al momento de entrar al mercado laboral, se dieron cuenta que no bastaba con la sola muestra de tener dieces inmaculados, les faltaba experiencia. Por tanto, compañeros que conocí como eruditos escolares, me los llegue a encontrar 2 o 3 años posteriores, dedicados completamente al Marketing telefónico, o como administrativo en una oficina de abogados, o como capturistas en una firma de Contadores Públicos; no me explique en cierto tiempo, como eso pudo ocurrir, al paso de los años comprendí que la combinación de elementos, entre una excelente posición académica, y una experiencia profesional casi simultánea al egresar de la universidad, serían de gran utilidad para no entrar en un campo competido, con grandes desventajas; mis excompañeros se parecieron al ejemplo del Pavo, mientras duraron en la escuela, cómodamente, engordando su ego con la boleta en 10, y que al llegar el momento, un rotundo “No te acepto por que no tienes la experiencia”, fue la guillotina que con el tiempo, redujo ese antiguo ego a saber que en el mundo empresarial, no es suficiente para lo real, para vivir las propias experiencias y resolver con toma de decisiones, las situaciones que se vayan presentando. Ahora que el autor hizo referencia clara de que la experiencia, no es un sentido malo el tenerla, sino más bien, el problema de ello es basar la experiencia solo en lo que se vive, que es de gran utilidad, pero que debemos entender que el conocer y estar conscientes que estamos limitados al poco conocimiento que tenemos de lo impredecible, de lo inesperado, del Cisne Negro – de dejarnos llevar por intentar predecir el futuro por medio de lo que ya conocemos, descuidando el punto de lo que no conocemos y que, mientras menos suceda, más probabilidad es que cuando ello ocurra, será de grandes dimensiones, para bien o para mal. Hoy en día, me ha tocado estar trabajando con especialistas en distintas ramas de la Tecnología, de hecho, en muchos casos, para el Plan de Recuperación de Desastres, se integran a distintos expertos en distintas tecnologías y participan en el programa elaborado para recuperar un ambiente tecnológico. En el 2010, recuerdo muy bien que hicimos una prueba de Continuidad de Negocio en conjunto con la Recuperación de Desastres, para uno de los clientes del sector de seguros. Previo a toda la prueba, se hicieron muchos preparativos – Gente que participaría, Logística de localidades, interconexión de sitios alternos al ambiente de Recuperación, script detallado de que harían los especialistas y en qué momento. Todo mi equipo especialista técnico para recuperar el ambiente, estaba preparado, las réplicas sincronizadas, los sitios alternos listos para interconectarse para el ambiente – iniciamos las actividades un Lunes a partir de las 21 horas, de acuerdo con los tiempos establecidos por el negocio (RTO|RPO) y que eran nuestro KPI, para demostrar que estábamos listos. Todo ocurrió de acuerdo al plan, y los usuarios iban Probando, de acuerdo a su script de Negocio, los sistemas recuperados. Todos, participando, los especialistas preparados en el War-room para recibir cualquier posible incidente que pudiera interrumpir el trabajo de la prueba – sin embargo, el miércoles a las 12 horas, después de ir trabajando con la recuperación, sin problemas, hubo un área de negocio que no podía continuar su operación por un horrible error de sistema – Licencia de aplicativo vencida – Empezamos todos a poner un alto foco a esa resolución sin poder determinar que estaba ocurriendo, hasta el grado de hablar con especialistas de 3er nivel en USA, para determinar la causa, posiblemente por un problema de licencia de producto de los sistemas AS400. Finalmente el tiempo de prueba se agotó, los especialistas no encontraron la falla, un área de negocio no pudo completar su script de recuperación y por ende, de continuidad de negocio, lo que puso en riesgo alto, la calificación final que el usuario estipula para la prueba. Ese día, “panzamos” la prueba pero teníamos que identificar que sucedió, puesto que el cliente se encontraba molesto. Primero, mi labor fue conseguir un especialista de 2º nivel, experto en AS400 para revisar el script de recuperación que el especialista actual estaba utilizando. En segundo término, tomamos el script, solicité el respaldo que se restaura en cada actividad de ése tipo y realizamos el mismo ejercicio con el especialista de 2 nivel, sin considerar a los Ingenieros expertos que participaron en la restauración del sistema – al siguiente día de recuperación del ambiente, el veredicto del Ingeniero que ejecuto el script fue – Adrián, el script es correcto, he seguido al pie de la letra las instrucciones y funciona adecuadamente – el problema que asumo, es que al final del script, el sistema de tener un IPL, lo que significa, que el sistema entra en un periodo de gracia de 70 días de uso del sistema operativo con licencia temporal – ese era el problema. Volvimos a ejecutar el script, por segunda ocasión y efectivamente, el respaldo no era el problema, la información estaba integra, los equipos perfectamente operando – el problema más bien, fue de ejecución – el Ingeniero en turno, no ejecutó correctamente las instrucciones del manual, omitiendo el paso final de dar IPL a los equipos y por ello, lo que ocurrió fue que el error de Licenciamiento apareció porque no estaba activa la licencia temporal. Adicionalmente, durante el proceso de encontrar que ocurrió, buscando en registros anteriores, me di cuenta que no fue un problema anterior y por ello, no estuvo registrado en las bitácoras de Lecciones aprendidas de los casos anteriores; fue algo inesperado, no contábamos con la omisión del Ingeniero, que provocó que la prueba de esa área de Negocio, comprometiera el resultado final del ejercicio. Se tuvo que repetir la prueba en 15 días posteriores, lo que provocó un desgaste fuerte en los Ingenieros participantes y que, finalmente, conseguí que el especialista de 2º nivel del AS400, pudiera restaurar para de algún modo “asegurar” que ahora, no nos ocurriera de nuevo – y que, previo a cualquier actividad, como tarea adicional, a los especialistas de AS400, tuvieron que realizar cada dos meses, la actividad de restauración y reportarme los resultados. Cosa que durante los 4 años posteriores de ejecución, ese error, estaba de alguna manera, superado y mitigado por las acciones previas tomadas. Sin embargo y como dice el autor, aun así, por muy tranquila que se pueda observar la situación, situación como la del Pavo, no podemos estar seguros de que nada ocurrirá en otro evento. ¿Tanto así, que un ejercicio de continuidad, de verdad, ocurrió un temblor que detuvo la actividad, por 2 horas – como mitigamos ello? Realmente no lo sabría hasta que ocurra. Finalmente, mi ocupación actual, es seguir asesorando a empresas, acompañándoles en sus actividades de Resiliencia, llevando a cabo las pruebas que sean necesarias, pero me queda claro que, en una actividad real, las comunicaciones, las familias y seres queridos, el tiempo y otros factores, pueden ser situaciones que no tomemos en cuenta en un contrato, ni en las bitácoras de lecciones aprendidas y que al ocurrir, ello no esté cubierto y la alta decepción por parte del cliente al saber que no estuvo listo su plan de recuperación por eventos que no se tenían contemplados, ocurrirá de cierta forma. Pero que de algún modo, también es mi responsabilidad hacer comprender al Cliente que eso no lo sabremos, hasta que ocurra el Cisne Negro.   Adrian Sanchez V holds the Informatics Degree with current Master of Managing e-Commerce in progress. Adrian is certified in the following specialties: ITIL, IT Specialist, ISO27001 LI and Business Continuity Professional, with more than 19 years of experience in the Information Technology industry. Adrian has worked for several Companies as Manager and Leader, such as Delivery Services, Assurance, Bank, Pharmaceutical and others sectors in the IT department and supporting complex projects.  Additionally, Adrian is working as Subject Matter Expert, building several solutions for customers, and Business Continuity and Disaster Recovery Consultant. Adrian’s goal is to keep all IT Services, using best practices, in a good shape of Work, Operations and Management, Providing and achieving all Business Targets and Objectives, aligned with the Mission and Company Values.