O seu fornecedor devia abrir o ticket primeiro.
No nosso desk, muitos tickets somos nós que os abrimos, a partir da nossa própria monitorização, antes de o cliente submeter o que quer que seja. Este é o modelo operacional por trás disso: engenheiros com nome que estão dentro da infraestrutura, não uma fila à espera na borda dela.
Neste artigo 3 secções
- No nosso desk, muitos tickets somos nós que os abrimos, a partir da nossa própria monitorização e deteção de segurança, antes de o cliente submeter o que quer que seja.
- O modelo tem quatro movimentos: abrimos nós o ticket, um engenheiro com nome assume-o de ponta a ponta, integramos ferramentas na sua operação, e o trabalho maior corre como projeto, fora do ticket.
- A fronteira é limpa: a sua empresa gere o negócio e a aplicação. Nós operamos, e construímos, tudo o que está por baixo.
- Nada disto é um escalão ou um extra. É assim que o desk funciona.
Comece pela notificação que não enviou. Um ticket já aberto, já com responsável, e a primeira mensagem nele é nossa. Se só alguma vez teve suporte de hosting que espera no fim de uma fila, essa experiência não faz sentido da primeira vez que acontece.
Muitos dos nossos tickets começam assim, porque o modelo operacional está construído para se mover primeiro.
Os quatro movimentos de uma equipa que atua na frente
Abrimos nós o ticket primeiro
A monitorização e a deteção de segurança estão ligadas a ação, por isso a primeira mensagem num ticket é muitas vezes nossa.
Uma pessoa com nome assume-o, de ponta a ponta, sem escalões
Os mesmos engenheiros que montam os servidores nos racks respondem no canal. Nenhuma parede de L1, nenhuma passagem entre escalões. A relação é com uma pessoa, não com uma fila.
Integramos as nossas ferramentas na sua operação
O sinal mais claro do modelo: construímos superfícies de controlo self-service para clientes sobre infraestrutura que operamos, para que o pessoal deles conduza no dia a dia enquanto nós somos responsáveis pela infraestrutura por baixo. A história completa dessa construção está em construímos um VPN Control Center para a própria equipa de uma agência.
O trabalho maior corre como projeto, fora do ticket
Quando uma colaboração ultrapassa a fila (uma migração de plataforma, uma rearquitetura) torna-se um levantamento, uma luz verde e um playbook de cutover. Isso é uma migração é um projeto, não um ticket.
“No dia a dia, parece ter uma equipa de infraestrutura no quadro de pessoal que, por acaso, também é dona do hardware e da rede onde tudo corre.”
Quem faz o quê
A fronteira merece ser enunciada com exatidão. Nosso é o metal e tudo o que está por baixo da aplicação: provisionamento, migrações e os seus cutovers, arquitetura de acesso seguro, staging e pré-produção, o pipeline de observabilidade, a SAN e o fabric de rede, a postura de backup e DR, engenharia de desempenho e de segurança. Assumimos a responsabilidade pela camada, não apenas pelo ticket. Deles é a aplicação e a lógica de negócio: o que lançar e quando, o código deles, o modelo de dados deles, a decisão de release deles. Nós acompanhamos o deploy. Continua a ser o deploy deles.
| A SUA EMPRESA GERE | NÓS OPERAMOS, E CONSTRUÍMOS |
|---|---|
| A sua aplicação e o respetivo código | Tudo o que está por baixo: computação, SAN, fabric de rede |
| O seu modelo de dados e a lógica de negócio | A plataforma de bases de dados, os seus backups, a sua postura de DR |
| A decisão de release: o que sai, e quando | A camada de staging, o deploy, o playbook de cutover |
| ONDE SE ESBATE, DE PROPÓSITOAs operações do dia a dia da sua equipa | As superfícies de controlo com que a sua equipa opera |
A fronteira esbate-se num ponto deliberado: construímos cada vez mais as ferramentas que permitem à sua equipa servir-se a si própria na borda da nossa camada, para que as suas pessoas operem com confiança sobre infraestrutura que não precisam de compreender. Não entregamos um runbook e vamos embora. Entregamos uma superfície de controlo e ficamos.
Quem compra desta forma
Dominam as plataformas de media e de editoras, porque a velocidade dos releases e os picos de tráfego são existenciais para elas. Logo a seguir vêm as agências digitais que servem os seus próprios clientes finais, porque não se podem dar ao luxo de parecer pequenas à frente de um cliente. As empresas com vários datacenters também fazem parte da mistura. A emoção do comprador difere, mas o pedido é sempre o mesmo: sejam a nossa equipa de engenharia, não o nosso help desk.
Os tempos de resposta estão publicados na nossa página de suporte. Este artigo é sobre quem se move primeiro e quem é responsável pelo trabalho.
Respostas diretas
O que significa na prática a monitorização proativa de servidores?+
Que a deteção está ligada a ação do lado do fornecedor. No nosso desk, muitos tickets somos nós que os abrimos a partir da monitorização e da deteção de segurança, antes de o cliente submeter o que quer que seja.
Tenho um engenheiro dedicado com o managed hosting?+
Aqui um engenheiro com nome assume o problema de ponta a ponta, e a mesma equipa que monta o hardware nos racks responde no canal. Não há sistema de escalões. O modelo é uma pessoa, não uma fila.
O que acontece quando algo avaria às 3 da manhã?+
A monitorização está ligada de modo a abrir o ticket, por isso às 3 da manhã a primeira mensagem é normalmente nossa. Os tempos de resposta estão na página de suporte. Se a sua carga de trabalho precisa de um compromisso específico, definimo-lo consigo.
A minha própria equipa pode continuar a gerir coisas sozinha?+
Sim, deliberadamente. Construímos superfícies de controlo para clientes sobre a infraestrutura que operamos (gestão de utilizadores, acessos, operações do dia a dia) para que a sua equipa conduza e nós sejamos responsáveis pela infraestrutura por baixo.
Qual é a diferença entre managed hosting e ter uma equipa de operações?+
A fronteira. A sua empresa gere a aplicação e o negócio, nós operamos e construímos a camada por baixo, e o trabalho maior corre como projetos de engenharia em vez de tickets.
A primeira mensagem devia ser nossa.
Engenheiros com nome, sem escalões, dentro da infraestrutura onde o seu negócio corre.
Fale com um engenheiroChegou ao fim.
Ponha a leitura em prática
O que executa?
Fale-nos da carga de trabalho, do tráfego e dos requisitos de recuperação. Comece pelo configurador de servidores ou discuta os detalhes com um engenheiro.
Escrito pelos engenheiros que constroem e operam a infraestrutura que descreve.Fale com um engenheiro