O modo de emergência (também mencionado como IPKVM) permite a conexão ao VPS sem RDP diretamente do nível do hypervisor, economizando de 15 a 20 minutos por semana.
Primeiro e acima de tudo — não irritar as pessoas. Em todo o mundo, o suporte é dividido em níveis, e o funcionário da primeira linha deve tentar as maneiras típicas de resolver. Se a tarefa ultrapassa suas capacidades, deve ser encaminhada para a segunda linha. Assim, entre os administradores de VDS, frequentemente encontramos pessoas que sabem pensar. Ao contrário de muitos outros suportes. Bem, pelo menos substancialmente mais frequente. E eles estruturam bem o ticket, descrevendo imediatamente tudo o que é necessário. Se a primeira linha 'perde o foco' e, por acaso, responde a isso pedindo para desligar e ligar — isso é um fracasso.
A tarefa é bastante simples: tornar o suporte do nosso VDS hosting adequado com o mínimo de custos. Porque somos o fast food do mundo dos provedores de hospedagem: nada de 'refinamentos' especiais, preços baixos, qualidade normal. Já houve uma história sobre como, com a aparição de influenciadores do Instagram tentando automatizar a gestão de contas e donos de pequenos negócios com contabilidade remota e outras pessoas que não são muito familiarizadas com a tecnologia, a comunicação 'como um admin para outro admin' deixou de funcionar. Foi necessário mudar a linguagem de comunicação.
Agora vou falar um pouco mais sobre os processos — e sobre os erros inevitáveis que surgem com eles.
Não irritar as pessoas nº 1
Qualquer suporte é uma produção em linha. Chega um pedido, o funcionário da primeira linha tenta imediatamente reconhecer a situação típica, que já aconteceu mil vezes e acontecerá mais mil. A chance é de 90%, que o pedido seja padrão, e que possa ser respondido com apenas alguns cliques para inserir o modelo. Normalmente, é preciso apenas preencher algumas palavras no modelo — e está feito. Ou acessar a interface de gerenciamento e clicar em alguns botões lá. Nos casos mais complexos (como transferências de zona para zona, por exemplo) é necessário seguir um algoritmo.
O que mais irrita as pessoas, independentemente de outras qualidades do suporte, é a reação típica a um pedido atípico. Chega um ticket, onde tudo está detalhadamente descrito, há várias informações necessárias para três perguntas à frente, o cliente prevê o diálogo... E nas primeiras palavras, o funcionário do suporte, no modo automático, começa a digitar o template de resposta 'tente reiniciar, deve ajudar'.
É exatamente isso que provoca a frustração nas pessoas, e é após essas situações que ficam as piores avaliações e os comentários mais exaltados. É claro que cometemos erros, e é daí que conhecemos as estatísticas. Cometemos erros de várias formas, mas esses casos são sempre simplesmente absurdos. Isso inclui até nós mesmos. Nós, é claro, gostaríamos que tais coisas não acontecessem de forma alguma. Mas isso é bem difícil na prática: a cada poucas semanas, um funcionário cansado da rotina pode acabar apertando botões equivocadamente.
Não irritar as pessoas Nº 2
A segunda situação que provoca frustração semelhante é quando nenhum suporte responde a um ticket por um longo período. Na Europa, esse comportamento de suporte é considerado normal: três dias para a aceitação de um incidente é mais do que aceitável. Mesmo que você esteja com uma situação urgente e algo pegando fogo - sem redes sociais, sem telefone, sem mensageiro, apenas e-mail e aguarde sua vez. Na Rússia, isso é muito menos comum, mas ainda assim alguns tickets acabam sendo "esquecidos". No início, estabelecemos um SLA para a primeira resposta de 15 minutos. E isso considerando um serviço 24/7 genuíno. É claro que, à medida que o VDS se torna maior, isso aparece. Mas provedores de serviços duvidosos não têm isso. E nós, no início, éramos justamente duvidosos e só depois nos tornamos mais ou menos grandes. Bem, mais ou menos medianos.
A primeira linha é composta por operadores que receberam scripts e foram treinados para reagir a situações típicas. Eles rapidamente classificam os problemas e tentam, em 15 minutos, ou responder com uma ação típica, ou informar que o ticket está sendo tratado e transferi-lo para a segunda linha.
A segunda linha é de administradores de hosting, que conseguem quase tudo manualmente. Nesse grupo também está o gerente de suporte, que sabe fazer tudo e um pouco mais. A terceira linha são os desenvolvedores, que lidam com tickets como "corrija isso na interface" ou "o parâmetro tal está sendo considerado incorretamente lá".
Reduzir o número de solicitações
Por razões compreensíveis, se você quer fornecer suporte a um custo baixo, é preciso não aumentar a primeira linha de atendimento para que as pessoas lidem mais rapidamente com scripts, mas sim aumentar a automação. Para que, em vez de pessoas com scripts, existam verdadeiros scripts. Portanto, uma das primeiras coisas que fizemos foi automatizar processos como a criação de máquinas virtuais, escalonamento de recursos (incluindo aumento e diminuição de disco, mas não da frequência do processador) e outras tarefas similares. Quanto mais o usuário puder fazer a partir da interface, mais fácil será para a primeira linha, e menor poderá ser. Quando o usuário entra em contato sobre algo que está disponível no painel, é preciso demonstrar e explicar como isso pode ser realizado de forma autônoma.
Se você não precisa de suporte, isso significa que está indo bem.
Uma segunda característica que economiza muito tempo é o preenchimento demorado da base de conhecimento. Quando o usuário enfrenta um problema que não consta na lista de ações suportadas (na maioria das vezes, são perguntas do tipo "como instalar um servidor de Minecraft" ou "onde no Windows Server configurar o VPS"), um artigo é escrito na base de conhecimento. Um artigo detalhado é criado para todas as solicitações estranhas. Por exemplo, se o usuário pede suporte para remover o firewall embutido do Windows Server, enviamos informações sobre o que pode acontecer se ele realmente for desativado, e como conceder permissões apenas para o software selecionado. Porque o problema geralmente é que algo não consegue se conectar devido às configurações, e não ao próprio firewall. Mas explicar isso a cada vez em um diálogo é muito difícil. E desativar o firewall não é algo que desejamos fazer, pois em breve podemos perder a máquina virtual ou o cliente.
Se algo relacionado a software aplicado na base de conhecimento se torna muito visitado, é possível adicionar a distribuição ao marketplace, de modo que surja o serviço de "criar um servidor com isso já instalado". Na verdade, foi assim que aconteceu com o Docker e com o servidor de Minecraft. Mais uma vez, um botão "façam-me bem" na interface economiza até cem tickets por ano.
Modo de emergência
Após estas ações, os problemas mais sérios que exigem intervenção manual são relacionados ao fato de que o usuário, por algum motivo, perdeu o acesso remoto ao sistema operacional convidado no hipervisor. O caso mais comum é uma configuração incorreta do firewall; o segundo mais frequente são bugs que impedem a inicialização normal do Windows e forçam a reinicialização no Modo Seguro. E, no modo seguro, o RDP não está disponível por padrão.
Criamos um modo de emergência para este caso. Na verdade, geralmente para acessar a máquina VDS, é necessário ter algum cliente para trabalho remoto. Na maioria das vezes, isso envolve acesso por console, RDP, VNC ou algo semelhante. A desvantagem desses métodos é que eles não funcionam sem um sistema operacional. Mas nós, a nível de hipervisor, conseguimos obter tanto a imagem da tela quanto enviar as entradas do teclado! Na verdade, isso acaba sobrecarregando bastante o processador (devido à transmissão de vídeo), mas permite alcançar o resultado desejado.
Por isso, oferecemos acesso ao modo de emergência a todos os usuários, mas ele é limitado em duração de uso contínuo. Felizmente, como a prática mostra, esse tempo é geralmente suficiente para reiniciar e fazer ajustes.
O resultado é ainda menos tickets para o suporte. E onde o administrador pode corrigir o ticket por conta própria, o suporte não precisa intervir manualmente.
Problemas restantes
Muito frequentemente, os usuários acham que o suporte está tentando enganá-los. Infelizmente, não há nada que possamos fazer a respeito (ou não conseguimos pensar em uma solução). Dois exemplos mais comuns são limites de recursos e proteção contra DDoS.
Cada máquina virtual tem limites de carga no disco, memória e tráfego permitido. A possibilidade de definir limites está especificada na oferta, e esses limites são ajustados para que a maior parte dos usuários trabalhe confortavelmente, mesmo sem tomar conhecimento deles. Mas se você de repente começa a consumir muito a largura de banda e o disco, os algoritmos automaticamente alertam o usuário. Desde abril do ano passado, removemos as bloqueios automáticos. Em vez disso, estabelecemos limites suaves por prazo variável.
Antes era assim: um aviso, depois, se o usuário não respondesse, - bloqueio automático. E nesse momento as pessoas ficavam ofendidas: "Mas o que é isso? O seu sistema está com problemas, não houve nada!" - e a partir daí, era possível tentar entender o software aplicado ou sugerir a atualização do plano. Não temos como analisar o funcionamento do software aplicado, pois isso está além do suporte. Embora nos primeiros casos, analisássemos isso junto aos usuários. Especialmente me lembro daquele caso em que o manipulador de visualizações no YouTube tinha um trojan embutido, e esse trojan estava com vazamento de memória. No final, chegamos à conclusão de que não eram erros de software, mas sim problemas dos próprios usuários, senão estaríamos sobrecarregados com solicitações semelhantes. Mas até agora, ninguém admitiu que poderia ter ultrapassado os critérios sozinho.
A história é semelhante com DDoS: nós escrevemos que você, caro usuário, está sob ataque. Por favor, ative a proteção. E o usuário diz: "Ah, é vocês que estão me atacando!" Claro, estamos derrubando um único usuário com um DDoS para enganá-lo a pagar 300 rublos. É um bom negócio. Sim, eu sei que muitos grandes provedores de hospedagem da categoria mais cara incluem essa proteção no plano, mas não podemos fazer isso: a economia de fast food dita outros preços mínimos.
Não menos frequentemente, o suporte é insatisfeito com aqueles cujos dados removemos. No sentido de que removemos legitimamente após o término do período pago. Se alguém não renova o aluguel do VDS, várias notificações são enviadas explicando o que acontecerá em seguida. No momento do término do pagamento, a máquina virtual é parada, mas sua imagem é salva. Uma última notificação é enviada, seguida de mais algumas. A imagem é mantida por sete dias adicionais e só depois é excluída permanentemente. Existe uma categoria de pessoas que fica muito insatisfeita com isso. Desde "o administrador foi demitido, e as notificações estavam indo para o e-mail dele, vocês precisam restaurar" até acusações de fraude e ameaças de violência física. A razão - os mesmos preços para todos os outros usuários. Se formos armazenar por um mês, serão necessários mais armazenamento. Isso significará preços mais altos para cada cliente individual. E a economia de fast food... Bem, vocês entendem. E assim, acabamos recebendo feedback em fóruns como "cobraram, deletaram dados, golpistas."
Deixe-me mencionar que temos uma linha de tarifas premium. A situação lá é, é claro, diferente, pois levamos em consideração o desejo do cliente e configuramos de forma flexível tanto o limite quanto a remoção em caso de não pagamento (levamos para o negativo, apenas para não bloquear). Isso já é economicamente viável, porque realmente acontecem diversas situações, e manter um cliente grande e constante custa caro.
Às vezes, os usuários são mal-intencionados. Várias vezes tivemos falhas em nosso sistema, bloqueando centenas de máquinas virtuais devido a ações claramente ilegítimas de clientes. Na verdade, foi por causa de tais situações que precisávamos de nossos próprios drivers de rede, para monitorar a atividade de rede e ver que o usuário não está realizando um ataque de seu servidor. Esse tipo de monitoramento é importante para que as fronteiras entre máquinas virtuais vizinhas não sejam violadas por indivíduos problemáticos.
Há aqueles que simplesmente fazem spam, mineram ou de alguma forma violam a oferta. Depois, eles entram em contato com o suporte e perguntam o que deu errado e por que a máquina foi bloqueada. Se o processo no ticket na captura de tela se chama 'enviador de spam.exe', é provável que algo esteja errado. A cada duas semanas, recebemos reclamações de empresas como a Sony ou Lucasfilm (agora — Disney), de que alguém de nossa máquina virtual, dentro de nosso intervalo de endereços IP, está distribuindo um filme pirata. Para tal, é um bloqueio imediato e devolução do saldo restante na conta conforme a oferta (lembrando: a quantização é por segundo, ou seja, o saldo sempre será exato). E para devolver o dinheiro, por lei, é necessário apresentar um documento de identidade: isso é uma medida contra a lavagem de dinheiro. Piratas, por algum motivo, em vez de apresentar o documento, dizem que nós tomamos o dinheiro deles, esquecendo de esclarecer algumas circunstâncias.
Ah, sim. A melhor pergunta do ano para nós é: 'Posso testar a máquina virtual pelo plano de 30 rublos por mês durante alguns dias antes da compra?'.
Resultado
A primeira linha classifica os tickets e responde com ações típicas. A maior parte das insatisfações ocorre aqui. Não há como corrigir isso, pois a base da correção está na automação do hosting, ou seja, em um enorme backlog. Sim, temos mais do que muitos no mercado, mas ainda assim não é suficiente. Portanto, a melhor coisa a se fazer é estabelecer um monitoramento da primeira linha. O monitoramento do suporte ao cliente é a execução das KPI da primeira linha. Atrasos no SLA são visíveis em tempo real: quem está errando, frequentemente — por quê. Com tais alertas, os tickets nunca se perdem. Sim, pode-se responder a um ticket com um template inadequado, mas isso já sabemos pela feedback.
Se o cliente pedir muito, um especialista da segunda linha pode acessar o servidor e fazer o que for necessário para o cliente (a condição é a confirmação por e-mail, onde ele comunicará os dados de acesso ao servidor).
Fazemos isso muito raramente e confiamos esse trabalho apenas aos melhores, porque queremos ter garantias de que os dados do usuário não serão danificados. Os melhores são a segunda linha de suporte.
A primeira linha tem uma base de conhecimento, onde pode-se direcionar consultas mais complexas.
Um painel de controle rico em funcionalidades, mais uma base de conhecimento — e assim conseguimos reduzir o número de atendimentos para 1 a 1,5 por ano por cliente, em média.
A segunda linha geralmente lida com solicitações complexas que exigem trabalho manual. O que é característico: quanto mais caro o plano, menos dessas solicitações em relação à máquina virtual. Normalmente, porque aqueles que podem pagar por um plano caro ou têm especialistas na equipe ou simplesmente metade dos problemas não surgem porque a configuração é suficiente para tudo. Eu ainda me lembro daquele herói que instalou uma versão não tão antiga do Windows Server em uma configuração com 256 MB de RAM.
A segunda linha tem um conjunto de distribuidores e um conjunto de scripts de automação. Ambos podem ser atualizados conforme necessário.
A segunda linha e gerentes pessoais de planos VIP podem adicionar notas ao perfil do cliente. Se ele for um administrador Linux, assim será registrado. Isso servirá como um lembrete para a primeira linha: o usuário sabe que isso não será um tiro no pé, mas uma destruição controlada.
A terceira linha gerencia as situações mais estranhas. Por exemplo, tivemos um bug que impedia o acesso a uma das funções do painel do usuário no Firefox. O usuário chegou a chantagear: "Se não corrigirem em 12 horas, vou escrever em todas as avaliações de hospedagem". Acontece que o problema estava no bloqueador de anúncios personalizado. Do lado do usuário, por mais estranho que pareça. Muitas vezes, chegam erros complexos sem detalhes, e não conseguem reproduzir o problema. Às vezes, vêm com prints: "Por que vocês estão corrigindo isso há um mês?" — "Na verdade, estamos procurando o seu bug todo esse tempo", "Ah, bem, ele aconteceu de novo hoje, mas novamente não consegui reproduzir"…
De fato, você nunca sabe onde vai parar um print do diálogo com o suporte, e quando alguém entra em contato com o suporte, é porque está com um problema. É possível melhorar a relação. Pelo menos, tentar.
Sim, sabemos que nosso suporte não é perfeito, mas, como eu gostaria de acreditar, ele combina uma rapidez suficiente com uma qualidade adequada. E não aumenta os preços dos planos para aqueles que podem se virar sem ele.
Fonte: habr.com
