Autor: Rubén Martínez Rioja
Ya hemos visto las herramientas de software más importantes, los comandos TCP/IP. Ahora debemos determinar el modo, la técnica o el método de aplicación, que estará determinado por las circunstancias de nuestra actuación.
Los profesionales de redes locales se encuentran habitualmente bajo dos circunstancias, la necesidad de verificar una instalación realizada o la de atender un aviso de avería, una anomalía detectada o cualquier tipo de incidencia en una red que ya ha sido instalada y, supuestamente, verificada.
Esto determina los procedimientos sistemáticos que deben emplearse en uno u otro caso. Por un lado, la verificación de una instalación comprende su certificación dentro de la normativa internacional, mediante un dispositivo certificador que comprueba que los parámetros de la red se ajustan a los valores asignados de velocidad y calidad de transmisión del tipo de cable instalado.
Por otro lado debe establecerse una configuración específica de los nodos, mediante dominios o grupos de trabajo, configuraciones IP, recursos compartidos, determinación de cuentas de usuario y privilegios asociados, generalmente bajo un sistema de archivo distribuido.
Los procedimientos sistemáticos, los métodos corporativos y las distintas técnicas a aplicar, se documentan a través de diagramas de flujo.
Los diagramas de flujo son la representación gráfica de un proceso mediante una simbología que permite seguir una serie de pasos o fases con bifurcaciones según los valores que toman los distintos parámetros que intervienen en el proceso. Está normalizado en el UML (Unified Modeling Language) Lenguaje Unificado de Modelado, respaldado por la OMG (Object Management Group). Además de usarse en informática y programación, se emplea en otras áreas, como economía, industria, seguridad o psicología.
UML es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. Ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados.
Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.
En la siguiente imagen se muestra un diagrama de flujo sencillo donde se muestra la estructura básica de un proceso de resolución de anomalías genérico, tan genérico que sirve para cualquier suceso de la vida cotidiana.
Los procedimientos generales de resolución de incidencias en redes de área local se clasifican en tres fases, recopilación, ubicación y corrección.
Consiste en la comprobación y documentación de síntomas de red, sistemas operativos y usuarios por parte del administrador de red y la delimitación de las anomalías concretando las áreas afectadas.
Esta documentación se elabora a través de las alertas de los sistemas de red, mensajes de consola, comprobaciones rutinarias automáticas o quejas de los propios usuarios. Debe realizarse bajo los criterios de lógica e intentando reducir el margen de posibilidades.
El científico loco y la araña.
A la hora de determinar la causa de una serie de síntomas, la lógica debe ser el elemento de decisión, pero determinar esa lógica puede resultar más difícil en unos casos que en otros. Para ilustrar la toma de decisiones, con frecuencia se recurre a la parábola o chiste del científico loco con su araña.
El científico tiene amaestrada a la araña, que acude a su llamada. Le extirpa una pata y la llama de nuevo. La araña acude, cojeando. Le arranca otra pata y repite el proceso. La araña, cada vez con más dificultad, acude a la llamada del científico. Finalmente, tras repetir el proceso, le arranca la última de sus patas, la coloca al otro extremo de la mesa, y la llama. La araña no acude.
Conclusión: Las arañas se vuelven sordas si se les extirpan las patas.
Del mismo modo, incorrecto, se podría concluir que las arañas sin patas, pierden obediencia. El error de estas conclusiones resulta evidente desde otro planteamiento, el llamado la navaja de Ockham, principio por el cual, la explicación más sencilla es siempre la más probable.
Debe analizarse el problema bajo la perspectiva de las capas de protocolos, para determinar qué dispositivos pueden ser la causa. En este proceso deben enumerarse las distintas posibilidades de anomalía y pueden realizarse pruebas para descartar posibilidades.
Hasta que no se realiza una identificación del dispositivo, o software que provoca la anomalía, no puede determinarse la causa del problema, pero puede aislarse para reducir el efecto en el resto de dispositivos.
El planteamiento inicial debe contemplar todas las posibilidades imaginables, para, posteriormente, descartar las posibilidades en función de los síntomas descritos y las pruebas realizadas.
Las ubicaciones más habituales de anomalías son:
La mayoría de las anomalías que ocurren en una red de área local, pertenecen a alguno de los grupos descritos. Como decía en el anterior apartado, para evitar la ilógica del científico loco, y cruel con su pobre araña, debemos recurrir a un principio metodológico, o filosófico, atribuido al monje franciscano Guillermo de Ockham (1280-1349)
La navaja de Ockham
La navaja de Ockham es un principio según el cual, en igualdad de condiciones, la explicación más sencilla suele ser la más probable.
Esto implica que, cuando dos teorías, en igualdad de condiciones, tienen las mismas consecuencias, la teoría más simple tiene más probabilidades de ser correcta que la compleja.
En ciencia, este principio se utiliza como una regla general para guiar a los científicos en el desarrollo de modelos teóricos, más que como un árbitro entre los modelos publicados. En el método científico, la navaja de Ockham no se considera un principio irrefutable, y ciertamente no es un resultado científico. «La explicación más simple y suficiente, es la más probable, mas no necesariamente la verdadera», según el principio de Ockham. En ciertas ocasiones, la opción compleja puede ser la correcta.
Su sentido es que, en condiciones idénticas, sean preferidas las teorías más simples, ya que la experiencia demuestra que, ese criterio, tiene mayor probabilidad de ser cierto. Otra cuestión diferente serán las evidencias que apoyen la teoría. Así pues, de acuerdo con este principio, una teoría más simple, pero de menor evidencia, no debería ser preferida a una teoría más compleja pero con mayores pruebas.
¿Cómo medir la simplicidad?, es una cuestión ambigua. Quizás la propuesta más conocida sea la que sugirió el mismo Ockham. Cuando dos teorías tienen las mismas consecuencias, debe preferirse la teoría que postule la menor cantidad de entidades, la que tenga menos elementos. Otra manera de medir la simplicidad, sin embargo, podría ser por el número de axiomas de la teoría. Cuantos más axiomas o postulados, más complejo y, por lo tanto, más improbable.
La navaja de Ockham se aplica a casos prácticos y específicos, englobándose dentro de los principios fundamentales de la filosofía de la escuela nominalista que opera sobre conceptos individualizados y casos empíricos.
La denominación de navaja de Ockham apareció en el siglo XVI, y con ella se expresaba que mediante ese principio, Ockham «afeitaba, como una navaja, las barbas de Platón», ya que de su aplicación se obtenía una notable simplicidad ontológica, por contraposición a la filosofía platónica que «llenaba» su ontología de entidades físicas, matemáticas e ideas puras.
Ockham, decía, exactamente, «Entia non sunt multiplicanda praeter necessitatem», Los entes no deben multiplicarse sin necesidad.
Con la navaja de Ockam se cortó la serie de estupideces que el ex-hoplita del ejército griego difundiera dos mil años atrás.
Como responsables informáticos, nosotros debemos ser como Ockham, no como Platón.
Una vez que se ha ubicado la causa de la anomalía, e identificando el problema, el administrador determinará una solución, procurando realizar el mínimo cambio posible, y teniendo en cuenta si este cambio provocará alguna alteración que repercuta en una nueva anomalía.
Debe, en último caso, valorarse la información inicial de la anomalía, y repasar las posibilidades planteadas inicialmente para encontrar posibles errores o descuidos, siempre con la navaja de Ockham como herramienta fundamental.
Teniendo clara la diferencia entre método y procedimiento, se puede comprender que tengan una distinta clasificación.
De esta forma hay tres métodos:
Generalmente, el fallo está en la gestión del usuario o en la configuración (o desconfiguración) de la aplicación usada. El caso de los plug-in o complementos del navegador de Internet, es lo más habitual.
Generalmente, si el problema es limitado, conviene el método de descenso de capas, pero si es más complejo o extraño, es más conveniente el ascenso de capas. El método de selección es más conveniente después de haber aplicado otros métodos que nos orientan sobre la ubicación (capa) de la anomalía.
Muchos de los avisos de avería que se registran en los centros de mantenimiento, corresponden a un patrón preestablecido. Dependiendo del grupo en el que clasifica el aviso, el operador seguirá un diagrama de flujo predeterminado para cada grupo, en el que preguntará al usuario o cliente, por distintos aspectos verificables de forma simple, y en función de las respuestas, determinará el tipo de aviso, urgencia o procedimiento establecido para su solución.
En estos casos, el personal técnico de campo, recibe el aviso clasificado por el operador para desplazarse al lugar de la anomalía. Una vez allí, se comprueba que el tipo de anomalía corresponde al esperado, y con mucha frecuencia ocurre que la anomalía está provocada por causas muy diferentes a las deducibles por el testimonio de los usuarios y la documentación recibida. En temas siguientes abordaremos de nuevo estas cuestiones.
Como he mencionado, en muchos casos recibimos esa documentación para iniciar los procesos de resolución, pero en otros casos, dependiendo del tipo de anomalía, puede ser necesario que seamos nosotros quienes documentemos la avería para ser estudiada por otra persona o grupo de personas.
En estos casos la documentación que debemos aportar será la siguiente:
La documentación asociada a la resolución de un problema debe permitir su consulta de forma rápida. El método más eficaz consiste en la elaboración de diagramas de flujo, como se dijo anteriormente, en los que una nueva incidencia puede suponer la comprobación de un nuevo parámetro a la hora de solucionar anomalías de la red.
Imagen tomada del siguiente documento de Microsoft Technet
Estos diagramas de flujo permiten establecer procedimientos sistemáticos a la hora de resolver incidencias de todo tipo. Cada red puede tener unas características especiales, un conjunto de sub-redes o determinado tipo de dispositivos de conectividad que hace indispensable que el administrador de red elabore un diagrama de flujo que simbolice los procedimientos de análisis de averías y anomalías.
Microsoft ofrece una gran variedad de herramientas para la elaboración de diagramas de flujo (Word, Power Point, Visio, etc...) pero existe un programa (gracias a Dios y a los programadores de open source) que se ha hecho estándar por ser open source (totalmente gratuito), llamado DIA, con licencia GPLv2.
Los diagramas de flujo se componen de elementos geométricos con texto en su interior unidos por una ruta a seguir. Hay distintos tipos de elementos, dependiendo de la naturaleza del proceso a representar, pero en nuestro caso nos bastará con 5 elementos:
No fueron mil las palabras, pero he aquí la imagen:
Todo diagrama debe tener un comienzo y, al menos, un final. Todo elemento debe estar conectado marcando una dirección, con elementos anteriores y posteriores. Todas las decisiones deben tener marcado el valor consultado en sus bifurcaciones. Siempre debe haber un proceso específico de documentación de la incidencia.
ACTIVIDAD DE AUTOEVALUACIÓN: Comandos TCP/IP-UnixWindows
ACTIVIDAD DE AUTOEVALUACIÓN: Diagramas de flujo ACTIVIDAD DE AUTOEVALUACIÓN: Procedimientos sistemáticosEsta píldora formativa está extraída del Curso online de Verificación y resolución de incidencias en una red de área local (UF0855).
No pierdas tu oportunidad y ¡continúa aprendiendo!
Política de privacidad
ADR Formación utiliza cookies propias y de terceros para fines analíticos anónimos, guardar las preferencias que selecciones y para el funcionamiento general de la página.
Puedes aceptar todas las cookies pulsando el botón "Aceptar" o configurarlas o rechazar su uso pulsando el botón "Configurar".
Puedes obtener más información y volver a configurar tus preferencias en cualquier momento en la Política de cookies
