Cuando una agencia gestiona uno o dos entornos de clientes, la rapidez con la que respondes a un incidente es lo que más cuenta. Si conoces el entorno, la solución suele estar al alcance de la mano. Un problema resuelto y gestionado bien puede fortalecer la relación con el cliente, así que una respuesta rápida es una habilidad que desarrollas y un motivo de orgullo en el que te basas.
Sin embargo, el volumen de incidentes en una cartera crece al mismo ritmo que la propia cartera. Si te enfocas mal, puedes llegar a ser más rápido resolviendo problemas sin que disminuya la frecuencia con la que se producen. La diferencia entre la rapidez de respuesta y la frecuencia de los incidentes es donde reside el verdadero coste de una agencia reactiva.
Por qué la rapidez en la respuesta a incidentes no es la métrica de éxito adecuada
Las configuraciones de un solo sitio pueden mantener una cultura de soluciones rápidas porque los incidentes son poco frecuentes y aislados. Conocer el entorno a fondo y tener un camino familiar hacia la resolución significa que tu velocidad de respuesta es una métrica de rendimiento significativa. A esto se le llama «tiempo medio de recuperación o reparación» (MTTR): el tiempo medio que se tarda en resolver un fallo una vez que se produce.
Sin embargo, el tiempo medio entre fallos (MTBF) se convierte en un mejor indicador del estado operativo a medida que creces. Mientras que el MTTR mide la velocidad de recuperación, el MTBF mide cuánto tiempo funciona un sistema antes del siguiente fallo. Un MTBF alto significa que las averías son poco frecuentes, pero un MTBF bajo indica que tu equipo está en un proceso de recuperación casi constante, independientemente de lo rápido que sea cada recuperación individual.
En pocas palabras, si solo optimizas el MTTR, te estás centrando en el taller mientras el vehículo sigue averiándose. En cambio, necesitas el MTTR para saber cómo de eficiente es la recuperación y el MTBF para saber si el entorno está generando incidencias en primer lugar.
Lo que cuesta un MTBF bajo en un portflio en expansión
En un portfolio grande, un MTBF bajo por sitio genera una cola de soporte que la velocidad de respuesta por sí sola no puede resolver. Los tipos de incidencias más comunes suelen repetirse en varios sitios:
- Los conflictos por actualizaciones de plugins afectan a varias instalaciones a la vez cuando se lanza una actualización de un plugin compartido que se usa en todo el portfolio.
- La degradación del rendimiento provocada por bots puede afectar a varios sitios a la vez cuando el tráfico automatizado elude el almacenamiento en caché y consume hilos PHP sin límite.
- Los errores de despliegue provocan fallos de configuración en los entornos de producción cuando no se siguen de forma sistemática los flujos de trabajo de staging.
- Incidentes en la infraestructura compartida en plataformas que no aíslan los sitios web pueden propagarse en cadena de un sitio a otro dentro del mismo servidor.
Muchos de estos incidentes no los ha causado tu equipo y no puedes evitarlos dentro del entorno. Por eso, solucionarlos más rápido no es lo mismo que tener menos incidentes.
Hall es un cliente de Kinsta con décadas de experiencia como agencia web. En su anterior proveedor de alojamiento, las interrupciones recurrentes del sitio web durante los picos de tráfico afectaban directamente a los ingresos de un cliente de WooCommerce y absorbían recursos del equipo que deberían haberse dedicado al trabajo para el cliente:
Kinsta funciona igual que nosotros. Necesitamos un rendimiento excelente para que no haya sorpresas, y un soporte técnico de primera por si surge algún problema. Kinsta nos permite reducir las distracciones relacionadas con el soporte técnico y aumentar la productividad.
Los costes que no aparecen en los tickets de incidencias
La mayoría de las agencias calculan el coste directo de un incidente, que suele corresponder a las horas que dedica un desarrollador o un gestor de cuentas a diagnosticar y resolver el problema. Esta cifra es real, pero incompleta, debido a algunos costes ocultos:
- El cambio de contexto te sacará de un proyecto de construcción para que te ocupes de un incidente en un sitio web en producción, pero la construcción no se detiene. Las investigaciones indican que se tarda entre 15 y 25 minutos en recuperar por completo la concentración profunda tras una interrupción, lo que significa que un solo incidente a media mañana puede acabar, sin que te des cuenta, con la mayor parte de un bloque de trabajo concentrado. Ese coste nunca aparece en el ticket del incidente, pero se acumula en todos los sitios web del portfolio.
- Si gestionas y resuelves un solo incidente con transparencia, la confianza del cliente será sólida. Por el contrario, si se producen incidentes de forma recurrente, eso genera dudas sobre si el entorno es fiable. La frecuencia por sí sola determina la confianza del cliente a lo largo del tiempo.
- Una agencia que se basa en respuestas reactivas convierte a los desarrolladores sénior en una primera línea de defensa permanente. Al ser el modo de funcionamiento habitual de un portfolio en crecimiento, esto genera rotación de personal y limita la capacidad, lo que hace que la situación negativa se agrave aún más.
El esfuerzo constante de un equipo por evitar que un portfolio sufra fallos recurrentes es más un problema de plataforma que de personal. La solución pasa por una infraestructura que no necesite intervenciones constantes para mantenerse estable. La reconocida agencia de marketing digital Paramark describe un modelo similar al de Kinsta:
Se necesitaba una gestión del sistema muy intensa para evitar que las páginas web fallaran. Entre los problemas más habituales estaban la gestión de los recursos del servidor y la limpieza de los archivos de registro. Si no se hacía eso, las páginas web se volvían inestables.
La solución (hacer un seguimiento de los incidentes por sitio y mes, en lugar del tiempo hasta la resolución) te permite saber si el entorno está mejorando de verdad o si tu equipo simplemente se está volviendo más hábil a la hora de gestionar un problema recurrente.
Cómo se previenen los incidentes
La infraestructura y la plataforma en general de Kinsta se basan en esta filosofía, que consiste en reducir la probabilidad de que se produzcan incidencias, en lugar de limitarse a reducir el tiempo de recuperación.
Para empezar, cada sitio se ejecuta en su propio contenedor aislado de Linux con un stack de software dedicado. Los recursos no pueden traspasar los límites del contenedor, y esto se aplica incluso entre sitios que pertenecen a la misma cuenta de empresa.
En el caso del portfolio de una agencia, los incidentes puntuales en un entorno no afectan al rendimiento ni a la disponibilidad de ningún otro sitio web que gestiones. En cambio, en las plataformas de alojamiento compartido, un pico de uso de recursos en un sitio web afecta negativamente al resto de sitios del mismo servidor.
Copias de seguridad automáticas y restauración con un solo clic
Kinsta crea copias de seguridad diarias completas de cada sitio web y las conserva durante al menos 14 días. Puedes acceder a las copias de seguridad y restaurarlas desde la pantalla Copias de seguridad en MyKinsta, donde también tienes acceso a otros dos tipos de copias de seguridad relevantes:
- Las copias de seguridad generadas por el sistema se activan automáticamente antes de operaciones clave, como restaurar desde una copia de seguridad existente. Siempre hay un punto de restauración antes de que se ejecute una operación.
- Las copias de seguridad manuales te permiten crear hasta cinco instantáneas adicionales en cualquier momento, a las que también puedes asignar una etiqueta para identificarlas.
El botón Restaurar a de cada copia de seguridad te permite volver a un estado conocido con unos pocos clics. Para las agencias que utilizan las Actualizaciones Automáticas de Kinsta en todo su portfolio, cada actualización programada se ejecuta con un punto de restauración generado por el sistema ya establecido. El proceso ahora es «restaurar y analizar», lo que es predecible independientemente del sitio web afectado.
Entornos staging y envío selectivo
Los entornos staging de Kinsta te ofrecen una copia independiente del sitio web en producción para que puedas probar los cambios antes de que lleguen a los clientes. Todos los planes de Kinsta incluyen un entorno staging estándar gratuito por sitio web. Cuando un cambio esté listo para el despliegue, el envío selectivo te permite controlar exactamente qué es lo que se traslada a producción.
Para usar el envío selectivo, selecciona tu entorno staging en MyKinsta, haz clic en Enviar entorno y elige un ámbito de despliegue (Archivos o Base de datos). Cada ámbito tiene también un menú desplegable que te permite ajustar lo que se envía:
Kinsta crea una copia de seguridad automática del entorno de destino antes de cada despliegue. Los errores de despliegue que llegan a los sitios en producción suelen ser una fuente frecuente de incidencias, así que una configuración multientorno que utilice envíos selectivos y copias de seguridad automáticas previas al despliegue es una forma de evitar tener que intervenir urgentemente en el sitio en producción.
La protección contra bots como capa de gestión de incidencias de rendimiento
La Protección contra Bots de Kinsta filtra el tráfico antes de que WordPress procese una solicitud, para reducir la carga automatizada a nivel de infraestructura antes de que afecte al rendimiento del servidor. Por defecto, Kinsta bloquea el tráfico clasificado como malicioso en toda la plataforma.
Para configurar la protección de un sitio, ve a la pantalla Protección contra Bots en MyKinsta y haz clic en Cambiar dentro del panel Nivel de protección:
Puedes elegir entre cuatro niveles diferentes y Bloquear tráfico malicioso es la opción predeterminada para todos los sitios web. Esto bloquea los intentos de DDoS y las solicitudes procedentes de direcciones IP asociadas a fuentes de ataque conocidas. Sin embargo, también puedes ampliar esta configuración para bloquear el tráfico automatizado confirmado, enviar solicitudes de verificación a las solicitudes que parezcan proceder de bots o que no estén clasificadas, e incluso verificar todo el tráfico no verificado, incluidos los visitantes que parezcan humanos.
Si seleccionas varios sitios a la vez en MyKinsta y haces clic en Acciones > Cambiar protección contra bots, también puedes aplicar un nivel de protección a varios sitios a la vez. La carga generada por bots puede eludir por completo la caché y consumir hilos de PHP con cada solicitud, sobre todo al gestionar WooCommerce o sitios de membresía. Con el tiempo, cada vez es más necesario disponer de esta funcionalidad.
Las analíticas como sistema de alerta temprana
La suite de analíticas de MyKinsta te permite detectar problemas antes de que afecten a tus clientes. Desde la pantalla de Analíticas, la pestaña Rendimiento te permite hacer un seguimiento de los tiempos de respuesta de PHP y del uso de hilos PHP a lo largo del tiempo. Un patrón de aumento en los tiempos de respuesta sin que haya un aumento correspondiente en el tráfico humano suele ser una señal temprana que apunta a una carga de bots o a una consulta de base de datos ineficiente:
Revisar los gráficos analíticos juntos te lleva unos minutos por sitio y te permite detectar patrones que se pasan por alto con la monitorización reactiva. Por ejemplo, al consultar el gráfico de Visitas en la sección Uso del plan, puedes ver datos sobre aspectos como el tráfico humano facturable. Si lo comparas con el informe Solicitudes más frecuentes por visitas (que abarca todo el tráfico, incluidas las solicitudes automatizadas), obtienes una visión de dónde la carga generada por bots está afectando al rendimiento del servidor, aunque el recuento de visitas parezca normal.
Cambiar el modelo operativo de tu agencia para centrarlo en la prevención
La reducción del número de incidentes se consigue gracias a la elección de la plataforma y las funcionalidades, más que a cambios en los patrones de trabajo.
Por ejemplo, empieza a registrar los factores individuales de cada sitio web que contribuyen al problema, junto con los pasos para resolverlo, cuando se produzca un incidente. El objetivo no es documentar por documentar, sino ver si los incidentes se repiten por las mismas razones subyacentes. Los registros de MyKinsta pueden ayudarte en esto:
Un registro que muestra tres incidencias en la misma página web, causadas por conflictos al actualizar plugins, apunta a una deficiencia en el flujo de trabajo de staging. Sin ese registro, el patrón pasa desapercibido y las incidencias siguen produciéndose.
Una lista de comprobación previa al despliegue es la mejor forma de integrar las decisiones que ya has tomado en un proceso que se pueda repetir. Los puntos que te indico a continuación te ayudan a evitar los tipos más comunes de incidentes que se pueden prevenir:
- Prueba cada cambio en un entorno staging de Kinsta comparando su estado con el de producción antes de implementarlo.
- Utiliza el envío selectivo para ajustar el alcance de la implementación al cambio.
- Revisa la Protección contra Bots después de cualquier despliegue que añada funcionalidad dinámica visible para el público, sobre todo formularios, flujos de pago o puntos de acceso de inicio de sesión.
- Comprueba el gráfico de Rendimiento en la sección Analíticas tras el despliegue para confirmar que los tiempos de respuesta se mantienen dentro de los límites.
Una vez que hagas un seguimiento regular de los incidentes por sitio, podrás informar de las tendencias de fiabilidad de forma proactiva, en lugar de tener que explicar los problemas a posteriori. Un cliente que recibe un resumen trimestral en el que se muestra una disminución de la frecuencia de incidentes y un tiempo de actividad constante tiene una percepción del servicio diferente a la de alguien a quien le llaman después de cada incidente.
Una infraestructura que prioriza la prevención es lo que hace que el crecimiento de la agencia sea sostenible
La respuesta rápida ante incidentes es una capacidad fundamental para cualquier organismo. La infraestructura que hace que los incidentes sean poco frecuentes es la que determina si esa capacidad se utiliza constantemente o si apenas se necesita. A nivel de agencia, la diferencia entre ambas situaciones es lo que marca la diferencia en cuanto a la rentabilidad y la estabilidad del equipo.
El conjunto de herramientas y la infraestructura de Kinsta (como el aislamiento mediante contenedores, el sistema de copias de seguridad automáticas y la protección contra bots) abordan las categorías de incidentes a las que dedicas más tiempo a responder. A partir de ahí, el proceso que pongas en marcha, como un registro de incidentes o una lista de comprobación previa al despliegue, hace que la reducción sea constante en todos los sitios que gestionas.
Para las agencias que gestionan sitios web de clientes en Kinsta, el Programa para Socios de Agencias ofrece soporte dedicado, recursos de venta conjunta y herramientas diseñadas para gestionar WordPress a gran escala.
