MODULO 1

Escrito por Diana Hernandez Technical Support Lead Los ingenieros de soporte necesitamos una metodologa para solucionar los problemas de nuestros clientes. Hace algunos aos atrs, miembros del grupo de soporte de escalacin para Latinoamrica se reunieron y crearon una metodologa que usa las mejores prcticas basadas en la experiencia del grupo y en el mtodo cientfico para la solucin de problemas. Este blog, usa el contenido de dicho trabajo realizado por los Support Escalation Engineers Viviane Lopes y Andre Teixeira. Son varios los beneficios que se obtienen al utilizar una metodologa para solucionar los problemas, entre ellos llegar a una solucin lo ms rpido posible. Hemos querido compartir con todos nuestros clientes estas mejores prcticas para que sean aplicadas no solamente en los casos de soporte de Microsoft, sino en general en cualquier escenario de solucin de problemas tcnicos. El mtodo cientfico parte de la definicin de un problema, crea una hiptesis, recolecta los datos necesarios, analiza estos datos, entrega un reporte de lo que en los datos se encontr y valida o rechaza la hiptesis. Estos mismos conceptos los podemos aplicar como metodologa para la solucin de los problemas de soporte tcnico. De esta manera surgieron las cuatro etapas utilizadas por los ingenieros del grupo de soporte de Microsoft de Latinoamrica. Estas cuatro etapas son: Defining. Gathering. Analyzing. Fixing.

Fig. 1. Metodologa de resolucin de problemas Estas estn representadas en la figura 1. Su representacin es cclica porque el proceso de resolucin se mueve a travs de las cuatro fases en secuencia con el objetivo de que en cada interaccin el problema sea acotado ms y ms hasta llegar a la solucin. La recomendacin es seguir las fases en secuencia y no omitir ninguna. Es muy difcil llegar al lugar a donde queremos ir si no definimos cual es dicho lugar. El proceso de resolucin de problemas debe siempre comenzar con la definicin del problema. A continuacin vamos a hablar de cada una de las etapas en detalle. Fase 1: Defining (Definicin) El primer paso es elaborar una buena definicin del problema. Depende de cmo definamos el problema, va a ser ms fcil o ms difcil solucionarlo exitosamente. La definicin del problema nos ayuda a definir tambin el criterio de solucin del mismo. Esto es lo que llamamos scope del problema. A menos que el problema este correctamente definido, es poco probable que sea encontrada una solucin satisfactoria. Existen varias tcnicas que pueden ser utilizadas durante esta etapa y que ayudan a nuestros ingenieros a definir un problema, entre ellas tenemos: Escuchar activamente. Realizar preguntas precisas. Parafrasear.

Para quien ha interactuado anteriormente con nuestro grupo de soporte, seguramente estas tcnicas les son familiares. El objetivo es capturar la mayor cantidad de detalles e informacin que nos ayude a definir el problema de una manera precisa. Con base en la definicin del problema y el conocimiento de cmo el producto debera funcionar, el siguiente paso que realiza el ingeniero es crear una hiptesis acerca de que podra ser la causa del problema. Recordemos que una hiptesis es una declaracin que an no se ha establecido como cierta. En el caso de los ingenieros de soporte, diramos que es una aproximacin educada basada en experiencia, conocimiento, habilidades e intuicin. El crear una hiptesis nos ayuda a darle un enfoque a nuestro pensamiento y continuar con las siguientes fases. La fase de defining o definicin, nos debe dar como resultados: Una definicin clara del problema. El criterio bajo el cual se define la solucin del problema. Una o ms hiptesis. Fase 2: Gathering (Recoleccin) Con base en la hiptesis creada, ahora s podemos comenzar a recolectar los datos que son necesarios para comprobar o refutar la hiptesis. Muchas veces tendemos a capturar informacin sin antes haber definido el problema y puede ser frustrante invertir tiempo en recolectar informacin que no ser usada. El primer objetivo de esta fase es definir un plan de accin efectivo para la recoleccin de los datos de tal manera que todos los datos necesarios sean recolectados en la primera vez. El segundo objetivo de esta fase es garantizar que la calidad de los datos es ptima antes de pasar al anlisis. Un buen plan de accin debe ser detallado, incluir informacin especfica de lo que se necesita y si es el caso, incluir explicaciones detalladas de como recolectar la informacin. Actualmente existen herramientas de soporte remoto que facilitan esta labor, caso que se necesite de ayuda para recolectar los datos. Despus de definir el plan de accin de cuales datos se necesitan y cmo van a ser recolectados, el siguiente paso es recolectar dicha informacin siguiendo el plan creado. Una buena prctica es tomar una pequea muestra de los datos para estar seguros que se est recolectando correctamente. Un ejemplo de este escenario son los logs del performance

monitor. Se puede tomar una muestra por un periodo corto de tiempo para garantizar que los contadores estn trabajando como se espera. Antes que los datos sean analizados deben ser validados. La validacin consiste en responder las siguientes preguntas: Es leble la informacin? Por ejemplo un dump de memoria. El cliente puede revisar que es vlido antes de enviarlo al ingeniero usando herramientas como el dumpchk.exe. Los datos contienen informacin relevante? Por ejemplo en una captura de red. El cliente puede revisar con en Network Monitor que la captura incluye trfico entre las maquinas relevantes al problema. Estas pequeas acciones evitan invertir tiempo innecesario tanto del cliente como del ingeniero. La fase de gathering o recoleccin, nos debe dar como resultados: Un plan de accin detallado para recolectar los datos necesarios. Validacin de los datos recolectados. Fase 3: Analyzing (Analisis) El objetivo de esta fase es analizar la informacin recolectada en la fase anterior. Esta informacin es estudiada para confirmar o rechazar la hiptesis o hiptesis generadas en la primera fase. Analizar el problema implica aprender sobre el mismo lo ms que se pueda. En esta fase la experiencia en el tema es crtica as como tambin las herramientas usadas para el anlisis. Dentro de las acciones que un ingeniero de soporte realiza durante esta fase de anlisis estn: Separar los datos que son relevantes para el anlisis basado en la definicin del problema y en el conocimiento y experiencia sobre el tema. Buscar por evidencia obvia primero antes de invertir tiempo en un anlisis ms profundo. Para clarificar este punto, un ejemplo es revisar los logs de Event Viewer antes de tomar un dump completo de la mquina.

 Buscar por contenido ya existente en las bases de datos de conocimiento. Nuestros clientes podran realizar este paso buscando en el sitio de soporte de Microsoft y tambin revisando sus bases de datos de problemas internos. Realizar un anlisis ms profundo. Esto es, investigar los datos recolectados en detalle, intentar reproducir el problema, comparar los datos recolectados con relacin a un ambiente que est trabajando normalmente. Como resultado de este anlisis, debemos ser capaces de confirmar la hiptesis, hay suficiente evidencia que confirme la hiptesis y soporte un diagnostico; o por el contrario tenemos que rechazar la hiptesis. En caso que la hiptesis sea rechazada, tendremos que comenzar un ciclo, esto es, ir a la fase de definicin nuevamente. En este punto se debe considerar colaboracin o escalacin del problema al siguiente nivel. La fase de analyzing o anlisis, nos debe dar como resultados: Hiptesis confirmada por el anlisis de los datos. Resultado del anlisis de los datos. Posible causa raz identificada. Comunicacin a nivel de las personas involucradas informando el progreso. Fase 4: Fixing ( Solucin) En esta fase con base al anlisis realizado previamente, necesitamos elaborar un plan de accin para solucionar el problema. Este plan de accin de solucin debe considerar el impacto y los riesgos de las acciones sugeridas. De ser necesario se recomienda probar el plan de accin en un ambiente de pruebas y de no ser posible, incluir las medidas necesarias tales como tener un respaldo (backup), planes de contingencia, en caso que el plan de accin deba ser aplicado directamente a produccin. Como mejores prcticas para la solucin de problemas tcnicos, la experiencia nos ensea a: Si hay varias maneras de solucionar el problema o una solucin involucra varios pasos, aplicar un cambio cada vez y observar los resultados. Seguir los pasos de acuerdo a las instrucciones dadas y al orden recomendado.

 En caso de dudas sobre el plan de accin, preguntar antes de ejecutar. Aqu podemos tener varias situaciones, que veremos a continuacin. Si despus de aplicar el plan de accin, los sntomas desaparecen, podemos considerar el problema como resuelto. Si el problema original est resuelto pero aparece un problema diferente, esto se debe manejar como un nuevo incidente de soporte e iniciar nuevamente con el ciclo de solucin. Si el problema contina, no hay cambio en los sntomas, debemos retornar a la fase de definicin y comenzar nuevamente. Escalacin al siguiente nivel debe ser considerara en esta situacin. Si el problema empeora (esta condicin es la menos deseada por supuesto!), escalacin al siguiente nivel debe ser considerada a este punto. La fase de fixing o solucin, nos debe dar como resultados la solucin al problema originalmente definido o la decisin de volver a la fase de defining o definicin nuevamente; obviamente considerando la posibilidad de involucrar recursos adicionales que nos ayuden a llegar a una solucin. Esperamos que este contenido les sea de utilidad y les ayude a solucionar los problemas siguiendo esta metodologa que hemos compartido con ustedes y que si de ser necesario tienen la necesidad de interactuar con nuestro grupo de ingenieros de soporte se les facilite el trabajo y puedan llegar a una solucin satisfactoria en conjunto lo ms rpido posible.
MODULO 2

Introduccin al protocolo HTTP

Desde 1990, el protocolo HTTP (Protocolo de transferencia de hipertexto) es el protocolo ms utilizado en Internet. La versin 0.9 slo tena la finalidad de transferir los datos a travs de Internet (en particular pginas Web escritas en HTML). La versin 1.0 del protocolo (la ms utilizada) permite la transferencia de mensajes con encabezados que describen el contenido de los mensajes mediante la codificacin MIME. El propsito del protocolo HTTP es permitir la transferencia de archivos (principalmente, en formato HTML). entre un navegador (el cliente) y un servidor web (denominado, entre

otros, httpd en equipos UNIX) localizado mediante una cadena de caracteres denominada direccin URL.

Comunicacin entre el navegador y el servidor

La comunicacin entre el navegador y el servidor se lleva a cabo en dos etapas:

El navegador realiza una solicitud HTTP El servidor procesa la solicitud y despus enva una respuesta HTTP

En realidad, la comunicacin se realiza en ms etapas si se considera el procesamiento de la solicitud en el servidor. Dado que slo nos ocupamos del protocolo HTTP, no se explicar la parte del procesamiento en el servidor en esta seccin del artculo. Si este tema les interesa, puede consultar el articulo sobre el tratamiento de CGI.

Solicitud HTTP
Una solicitud HTTP es un conjunto de lneas que el navegador enva al servidor. Incluye:

Una lnea de solicitud: es una lnea que especifica el tipo de documento solicitado, el mtodo que se aplicar y la versin del protocolo utilizada. La lnea est formada por tres elementos que deben estar separados por un espacio: o el mtodo o la direccin URL o la versin del protocolo utilizada por el cliente (por lo general, HTTP/1.0)

Los campos del encabezado de solicitud: es un conjunto de lneas opcionales que permiten aportar informacin adicional sobre la solicitud y/o el cliente (navegador, sistema operativo, etc.). Cada una de estas lneas est formada por un nombre que describe el tipo de encabezado, seguido de dos puntos (:) y el valor del encabezado. El cuerpo de la solicitud: es un conjunto de lneas opcionales que deben estar separadas de las lneas precedentes por una lnea en blanco y, por ejemplo, permiten que se enven datos por un comando POST durante la transmisin de datos al servidor utilizando un formulario.

Por lo tanto, una solicitud HTTP posee la siguiente sintaxis (<crlf> significa retorno de carro y avance de lnea):
MTODO VERSIN URL<crlf> ENCABEZADO: Valor<crlf> . . . ENCABEZADO: Valor<crlf> Lnea en blanco <crlf> CUERPO DE LA SOLICITUD

A continuacin se encuentra un ejemplo de una solicitud HTTP:

GET http://es.kioskea.net HTTP/1.0 Accept : Text/html If-Modified-Since : Saturday, 15-January-2000 14:37:11 GMT User-Agent : Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)

Comandos
Comando GET HEAD POST PUT DELETE Descripcin Solicita el recurso ubicado en la URL especificada Solicita el encabezado del recurso ubicado en la URL especificada Enva datos al programa ubicado en la URL especificada Enva datos a la URL especificada Borra el recurso ubicado en la URL especificada

Encabezados
Nombre del encabezado Accept Descripcin

Tipo de contenido aceptado por el navegador (por ejemplo, texto/html). Consulte Tipos de MIME Accept-Charset Juego de caracteres que el navegador espera Accept-Encoding Codificacin de datos que el navegador acepta Accept-Language Idioma que el navegador espera (de forma predeterminada,

ingls) Authorization Identificacin del navegador en el servidor Content-Encoding Tipo de codificacin para el cuerpo de la solicitud Content-Language Tipo de idioma en el cuerpo de la solicitud Content-Length Extensin del cuerpo de la solicitud Tipo de contenido del cuerpo de la solicitud (por ejemplo, Content-Type texto/html). Consulte Tipos de MIME Date Fecha en que comienza la transferencia de datos Utilizado por equipos intermediarios entre el navegador y el Forwarded servidor From Permite especificar la direccin de correo electrnico del cliente Permite especificar que debe enviarse el documento si ha sido From modificado desde una fecha en particular Link Vnculo entre dos direcciones URL Orig-URL Direccin URL donde se origin la solicitud Referer Direccin URL desde la cual se realiz la solicitud Cadena con informacin sobre el cliente, por ejemplo, el nombre User-Agent y la versin del navegador y el sistema operativo

Respuesta HTTP
Una respuesta HTTP es un conjunto de lneas que el servidor enva al navegador. Est constituida por: Incluye:

Una lnea de estado: es una lnea que especifica la versin del protocolo utilizada y el estado de la solicitud en proceso mediante un texto explicativo y un cdigo. La lnea est compuesta por tres elementos que deben estar separados por un espacio: La lnea est formada por tres elementos que deben estar separados por un espacio: o la versin del protocolo utilizada o el cdigo de estado o el significado del cdigo Los campos del encabezado de respuesta: es un conjunto de lneas opcionales que permiten aportar informacin adicional sobre la respuesta y/o el servidor. Cada una de estas lneas est compuesta por un nombre que califica el tipo de encabezado, seguido por dos puntos (:) y por el valor del encabezado Cada una de estas lneas est formada por un nombre que describe el tipo de encabezado, seguido de dos puntos (:) y el valor del encabezado. El cuerpo de la respuesta: contiene el documento solicitado.

Por lo tanto, una respuesta HTTP posee la siguiente sintaxis (<crlf> significa retorno de carro y avance de lnea):
VERSIN-HTTP CDIGO EXPLICACIN <crlf> ENCABEZADO: Valor<crlf> . . . ENCABEZADO: Valor<crlf> Lnea en blanco <crlf> CUERPO DE LA RESPUESTA

A continuacin se encuentra un ejemplo de una respuesta HTTP:

HTTP/1.0 200 OK Date: Sat, 15 Jan 2000 14:37:12 GMT Server : MicrosoftIIS/2.0 Content-Type : text/HTML Content-Length : 1245 Last-Modified : Fri, 14 Jan 2000 08:25:13 GMT

Encabezados de respuesta
Nombre del Descripcin encabezado Content-Encoding Tipo de codificacin para el cuerpo de la respuesta Content-Language Tipo de idioma en el cuerpo de la respuesta Content-Length Extensin del cuerpo de la respuesta Tipo de contenido del cuerpo de la respuesta (por ejemplo, Content-Type texto/html). Consulte Tipos de MIME Date Fecha en que comienza la transferencia de datos Expires Fecha lmite de uso de los datos Utilizado por equipos intermediarios entre el navegador y el Forwarded servidor Redireccionamiento a una nueva direccin URL asociada con el Location documento Server Caractersticas del servidor que envi la respuesta

Los cdigos de respuesta

Son los cdigos que se ven cuando el navegador no puede mostrar la pgina solicitada. El cdigo de respuesta est formado por tres dgitos: el primero indica el estado y los dos siguientes explican la naturaleza exacta del error. Cdigo 10x Mensaje Mensaje de informacin Descripcin Estos cdigos no se utilizan en la versin 1.0 del protocolo

Estos cdigos indican la correcta ejecucin de la transaccin 200 OK La solicitud se llev a cabo de manera correcta Sigue a un comando POST e indica el xito, la parte 201 CREATED restante del cuerpo indica la direccin URL donde se ubicar el documento creado recientemente. La solicitud ha sido aceptada, pero el procedimiento 202 ACCEPTED que sigue no se ha llevado a cabo Cuando se recibe este cdigo en respuesta a un PARTIAL 203 comando de GET indica que la respuesta no est INFORMATION completa. El servidor ha recibido la solicitud, pero no hay 204 NO RESPONSE informacin de respuesta El servidor le indica al navegador que borre el 205 RESET CONTENT contenido en los campos de un formulario Es una respuesta a una solicitud que consiste en el PARTIAL 206 encabezado range. El servidor debe indicar el CONTENT encabezado content-Range Estos cdigos indican que el recurso ya no se 30x Redireccin encuentra en la ubicacin especificada Los datos solicitados han sido transferidos a una nueva 301 MOVED direccin Los datos solicitados se encuentran en una nueva 302 FOUND direccin URL, pero, no obstante, pueden haber sido trasladados Significa que el cliente debe intentarlo con una nueva 303 METHOD direccin; es preferible que intente con otro mtodo en vez de GET Si el cliente llev a cabo un comando GET condicional (con la solicitud relativa a si el documento ha sido 304 NOT MODIFIED modificado desde la ltima vez) y el documento no ha sido modificado, este cdigo se enva como respuesta. Error debido al 40x Estos cdigos indican que la solicitud es incorrecta cliente La sintaxis de la solicitud se encuentra formulada de 400 BAD REQUEST manera errnea o es imposible de responder Los parmetros del mensaje aportan las especificaciones de formularios de autorizacin que se 401 UNAUTHORIZED admiten. El cliente debe reformular la solicitud con los datos de autorizacin correctos 20x xito

El cliente debe reformular la solicitud con los datos de pago correctos 403 El acceso al recurso simplemente se deniega Un clsico. El servidor no hall nada en la direccin 404 NOT FOUND especificada. Se ha abandonado sin dejar una direccin para redireccionar... :) Error debido al Estos cdigos indican que existe un error interno en 50x servidor el servidor El servidor encontr una condicin inesperada que le 500 INTERNAL ERROR impide seguir con la solicitud (una de esas cosas que les suceden a los servidores...) NOT El servidor no admite el servicio solicitado (no puede 501 IMPLEMENTED saberlo todo...) El servidor que acta como una puerta de enlace o 502 BAD GATEWAY proxy ha recibido una respuesta no vlida del servidor al que intenta acceder El servidor no puede responder en ese momento SERVICE debido a que se encuentra congestionado (todas las 503 UNAVAILABLE lneas de comunicacin se encuentran congestionadas, intntelo de nuevo ms adelante) La respuesta del servidor ha llevado demasiado tiempo GATEWAY 504 en relacin al tiempo de espera que la puerta de enlace TIMEOUT poda admitir (excedi el tiempo asignado...) 402

PAYMENT REQUIRED FORBIDDEN

Ms informacin
Para obtener ms informacin sobre el protocolo HTTP, consulte la RFC (peticin de comentarios)1945, que explica el protocolo en detalle:

RFC 1945 - Protocolo de transferencia de hipertexto -- HTTP/1.0 (traduccin al francs) RFC 1945 - Protocolo de transferencia de hipertexto -- HTTP/1.0 (versin original) RFC 2616 - Protocolo de transferencia de hipertexto -- HTTP/1.0 (versin original) Cookies