Su proveedor debería abrir el ticket primero.
En nuestro desk, muchos tickets los abrimos nosotros, desde nuestra propia monitorización, antes de que el cliente presente nada. Este es el modelo operativo que hay detrás: ingenieros con nombre que están dentro de la infraestructura, no una cola que espera en su extremo.
En este artículo 3 secciones
- En nuestro desk, muchos tickets los abrimos nosotros, desde nuestra propia monitorización y detección de seguridad, antes de que el cliente presente nada.
- El modelo tiene cuatro movimientos: abrimos nosotros el ticket, un ingeniero con nombre lo lleva de principio a fin, integramos herramientas en su operación, y el trabajo más grande se ejecuta como proyecto, fuera del ticket.
- El límite es limpio: usted dirige su negocio y su aplicación. Nosotros operamos, y construimos, todo lo que hay debajo.
- Nada de esto es un nivel ni un complemento. Así es como funciona el desk.
Empiece por la notificación que usted no envió. Un ticket ya abierto, ya con responsable, y el primer mensaje que hay en él es nuestro. Si solo ha conocido un soporte de hosting que espera al otro extremo de una cola, esa experiencia no cuadra la primera vez que ocurre.
Muchos de nuestros tickets empiezan así, porque el modelo operativo está construido para moverse primero.
Los cuatro movimientos de un equipo que actúa por delante
Abrimos nosotros el ticket primero
La monitorización y la detección de seguridad están conectadas a la acción, así que el primer mensaje de un ticket es a menudo nuestro.
Una persona con nombre lo lleva, de principio a fin, sin niveles
Los mismos ingenieros que montan los servidores en el rack responden en el canal. Sin muro de L1, sin traspasos entre niveles. La relación es con una persona, no con una cola.
Integramos nuestras herramientas en su operación
La señal más clara del modelo: hemos construido superficies de control self-service para clientes sobre infraestructura que operamos nosotros, de modo que su personal conduce el día a día mientras nosotros respondemos de la infraestructura que hay debajo. La historia completa de esa construcción está en construimos un VPN Control Center para el equipo de una agencia.
El trabajo más grande se ejecuta como proyecto, fuera del ticket
Cuando un encargo supera la cola (una migración de plataforma, un rediseño de arquitectura) se convierte en un levantamiento, una luz verde y un playbook de cutover. Eso es una migración es un proyecto, no un ticket.
“En el día a día, parece tener un equipo de infraestructura en plantilla que, además, resulta ser dueño del hardware y de la red en los que se ejecuta.”
Quién hace qué
El límite merece enunciarse con exactitud. Nuestro es el metal y todo lo que hay bajo la aplicación: aprovisionamiento, migraciones y sus cutovers, arquitectura de acceso seguro, staging y preproducción, el pipeline de observabilidad, la SAN y el fabric de red, la postura de backup y DR, ingeniería de rendimiento y de seguridad. Asumimos la responsabilidad de la capa, no solo del ticket. Suyo es la aplicación y la lógica de negocio: qué publicar y cuándo, su código, su modelo de datos, su decisión de release. Nosotros acompañamos el deploy. Sigue siendo su deploy.
| USTED DIRIGE | NOSOTROS OPERAMOS, Y CONSTRUIMOS |
|---|---|
| Su aplicación y su código | Todo lo que hay debajo: cómputo, SAN, fabric de red |
| Su modelo de datos y su lógica de negocio | La plataforma de bases de datos, sus backups, su postura de DR |
| La decisión de release: qué se publica, y cuándo | El nivel de staging, el deploy, el playbook de cutover |
| DONDE SE DIFUMINA, A PROPÓSITOLa operación diaria de su equipo | Las superficies de control con las que opera su equipo |
El límite se difumina en un punto, de forma deliberada: cada vez construimos más las herramientas que permiten a su equipo autoservirse en el borde de nuestra capa, para que su gente opere con confianza sobre una infraestructura que no tiene que entender. No entregamos un runbook y nos vamos. Entregamos una superficie de control y nos quedamos.
Quién lo compra así
Dominan las plataformas de medios y editores, porque la velocidad de los releases y los picos de tráfico son existenciales para ellos. Les siguen de cerca las agencias digitales que atienden a sus propios clientes finales, porque no pueden permitirse parecer pequeñas delante de un cliente. Las empresas con varios datacenters también están en la mezcla. La emoción del comprador varía, pero la petición es la misma, siempre: sean nuestro equipo de ingeniería, no nuestro help desk.
Los tiempos de respuesta están publicados en nuestra página de soporte. Este artículo trata de quién se mueve primero y quién responde del trabajo.
Respuestas directas
¿Qué significa en la práctica la monitorización proactiva de servidores?+
Que la detección está conectada a la acción en el lado del proveedor. En nuestro desk, muchos tickets los abrimos nosotros desde la monitorización y la detección de seguridad, antes de que el cliente presente nada.
¿Tengo un ingeniero dedicado con el managed hosting?+
Aquí un ingeniero con nombre lleva el asunto de principio a fin, y el mismo equipo que monta el hardware en el rack responde en el canal. No hay sistema de niveles. El modelo es una persona, no una cola.
¿Qué pasa cuando algo se rompe a las 3 de la madrugada?+
La monitorización está conectada para abrir el ticket, así que a las 3 de la madrugada el primer mensaje suele ser nuestro. Los tiempos de respuesta están en la página de soporte. Si su carga de trabajo necesita un compromiso concreto, lo definimos con usted.
¿Puede mi propio equipo seguir gestionando cosas por su cuenta?+
Sí, deliberadamente. Construimos superficies de control para clientes sobre la infraestructura que operamos (gestión de usuarios, acceso, operación diaria) para que su equipo conduzca y nosotros respondamos de la infraestructura que hay debajo.
¿Cuál es la diferencia entre el managed hosting y tener un equipo de ops?+
El límite. Usted dirige la aplicación y el negocio, nosotros operamos y construimos la capa de debajo, y el trabajo más grande se ejecuta como proyectos de ingeniería en lugar de tickets.
El primer mensaje debería ser nuestro.
Ingenieros con nombre, sin niveles, dentro de la infraestructura en la que se ejecuta su negocio.
Hable con un ingenieroHa llegado al final.
Ponga la lectura a trabajar
¿Qué está ejecutando?
Cuéntenos la carga de trabajo, el tráfico y los requisitos de recuperación. Empiece por el configurador de servidores o repase los detalles con un ingeniero.
Escrito por los ingenieros que construyen y operan la infraestructura que describe.Hable con un ingeniero