Incidente de alojamiento: coordine la recuperación y redacte una solicitud de soporte útil
Cuando un servicio falla, las primeras acciones pueden aclarar el incidente o borrar la información necesaria para comprenderlo. Una respuesta útil separa lo que observan los usuarios, lo que sabe el equipo y lo que sigue siendo una hipótesis. Mantenga una cronología coordinada y asigne a cada cambio un responsable, un motivo y una forma de comprobar el resultado.
La conclusión práctica
Estabilice la situación sin perder pruebas útiles, comparta una cronología fáctica y concisa, realice cambios controlados y verifique la recuperación mediante el recorrido del cliente afectado.
Determine el impacto y asigne un responsable de la coordinación
Empiece por lo que ha dejado de funcionar y a quién afecta. Una caída de un sitio web público, tareas en segundo plano retrasadas y una pantalla de administración no disponible tienen consecuencias distintas. Anote la primera hora de fallo conocida, la zona horaria, el servicio o dominio afectado y si el problema es continuo o intermitente. Mantenga esas observaciones separadas de supuestos como «el servidor está caído» cuando solo se ha comprobado un endpoint de una aplicación.
Asigne a alguien la coordinación de la respuesta y el mantenimiento de la cronología, aunque en un equipo pequeño sea la misma persona que también realiza el trabajo técnico. Identifique quién puede aprobar un cambio arriesgado y quién se comunica con las personas afectadas. Varios administradores realizando cambios independientes pueden impedir saber qué acción ayudó. Utilice un registro de incidente compartido y un traspaso claro cuando cambie la persona de guardia.
Compruebe si el incidente tiene una dimensión de seguridad, como un cambio de cuenta inesperado, contenido alterado o credenciales expuestas. Una sospecha de compromiso requiere una respuesta que contemple la contención y las pruebas, no solo un reinicio rápido. Deje cualquier obligación contractual de notificación u obligación legal en manos de las personas responsables adecuadas. Esta guía operativa no decide esas obligaciones, y un ticket de soporte normal no sustituye el proceso de respuesta de seguridad de una organización.
Conserve un registro útil antes de cambiar el sistema
Registre los síntomas actuales y los cambios recientes relevantes antes de que se pierdan de la memoria. Incluya las horas de despliegue, las ediciones de configuración, los cambios de certificados o de DNS y las tareas programadas que se solapen con el fallo. Recopile registros estrictamente relevantes con las herramientas y permisos disponibles. El journal de systemd puede filtrarse por hora y servicio; los registros de la aplicación pueden tener sus propios identificadores de correlación. Anote de dónde procede cada extracto y el contexto horario utilizado.
Limite los datos que recopila y comparte a lo que necesita la investigación. Los registros pueden contener identificadores de sesión, parámetros de solicitud, datos personales o secretos escritos accidentalmente por una aplicación. Censure la copia enviada a soporte y conserve el original de forma privada cuando proceda. No pegue un archivo de entorno completo ni un volcado de base de datos en un ticket. Una referencia de transacción pública puede ser útil para una investigación de pago; una clave privada de monedero nunca lo es.
| Conservar | Por qué ayuda | Evitar compartir |
|---|---|---|
| Referencia de servicio o pedido | Identifica el recurso propio | Contraseñas y claves de recuperación |
| Intervalo de tiempo con zona horaria | Alinea las observaciones y los registros | Una hora no explicada de un reloj desconocido |
| Error exacto y recorrido afectado | Hace que el síntoma sea reproducible | Una exportación sin filtrar que contiene datos de clientes |
| Acciones recientes y sus resultados | Evita cambios repetidos o conflictivos | Especulación presentada como causa confirmada |
Elija la intervención más pequeña que encaje con las pruebas
Exponga la hipótesis y el resultado esperado antes de un cambio. Si un despliegue introdujo el error, una reversión preparada de la aplicación puede ser más informativa que cambiar ajustes de red no relacionados. Si el sistema de archivos está lleno, borrar archivos arbitrarios puede destruir datos útiles sin tocar la causa. Determine qué se puede eliminar o mover de forma segura, conserve el registro relevante y compruebe el comportamiento de recuperación de la aplicación cuando haya espacio disponible.
Reiniciar puede ser una acción de recuperación razonable en las circunstancias adecuadas, pero también cambia el estado que está investigando. Tenga en cuenta las escrituras activas, el trabajo en cola y la información que se perderá. Cuando un reinicio inmediato sea necesario para restablecer el servicio, registre la decisión y el resultado. Los reinicios repetidos sin una nueva hipótesis pueden convertir un fallo intermitente en una larga secuencia de pruebas perdidas.
Si sospecha una intrusión, implique al responsable de seguridad correspondiente y utilice un plan de contención autorizado. Restringir la exposición, aislar una carga de trabajo, conservar las pruebas relevantes y sustituir las credenciales afectadas pueden tener prioridades distintas según la situación. No experimente con archivos o herramientas de un atacante en otro sistema de producción. Mantenga las copias de investigación y el acceso estrictamente controlados, y evite que una acción de recuperación incierta propague el incidente a un entorno que de otro modo no estaría afectado.
Proporcione a soporte un resumen que impulse la investigación
Abra una solicitud desde la cuenta propietaria del servicio afectado cuando sea posible. Empiece por el impacto y la referencia, y después indique el intervalo de tiempo observado, el error exacto, el recorrido reproducible y los cambios recientes relevantes. Mencione las acciones ya intentadas y si cada una mejoró, empeoró o no modificó el síntoma. Si el problema es intermitente, incluya un pequeño número de marcas de tiempo representativas en lugar de decir que falla de forma aleatoria.
- Servicio afectado, dominio o referencia de pedido propio.
- Hora de inicio observada y zona horaria, además de horas de fallo representativas.
- Comportamiento esperado y resultado exacto que ve el usuario.
- Extractos de registro seguros y relevantes o referencias públicas de transacciones.
- Cambios recientes y acciones de recuperación intentadas con sus resultados.
- La siguiente decisión o dato de infraestructura que necesita que el equipo aclare.
Un ejemplo útil es un informe que indique que el inicio de sesión de una aplicación devuelve un error concreto tras un despliegue determinado, mientras su página de inicio pública sigue funcionando, con tres marcas de tiempo de fallo y un rastro de aplicación redactado. Eso da a la siguiente persona un punto de partida concreto. «Todo está roto, arréglenlo, por favor» no lo hace. Mantenga las observaciones de seguimiento en la misma conversación para que el equipo pueda ver la evolución del incidente en lugar de reconstruir varias solicitudes desconectadas.
Verifique la recuperación y convierta el incidente en una mejora de mantenimiento
Compruebe el recorrido que falló originalmente, no solo si un proceso está en ejecución. Confirme que el trabajo pendiente avanza, que los datos son coherentes y que los usuarios autorizados pueden realizar las acciones importantes. Continúe la observación el tiempo suficiente para detectar el patrón de recurrencia relevante para el incidente. Si se utilizó una excepción temporal o una solución alternativa, registre su responsable y el plan para retirarla. Un registro de errores silencioso no basta si la aplicación está descartando trabajo sin avisar.
Cierre la respuesta con una cronología concisa, la causa confirmada cuando se haya establecido, las condiciones contribuyentes y el seguimiento práctico. Distinga una causa confirmada de una explicación que sigue siendo plausible pero no está probada. Asigne acciones como probar una restauración, ajustar las comprobaciones de despliegue o mejorar un diagnóstico ausente. El propósito es que el siguiente incidente sea más fácil de detectar y gestionar, con un registro que otro responsable de mantenimiento pueda entender sin haber estado presente.
