VPS gerido ou não gerido: qual escolher?

VPS gerido ou não gerido: a resposta curta

Escolher entre um VPS gerido e um VPS não gerido é uma questão de trabalho, não de produto. Num VPS não gerido, a responsabilidade pelas atualizações, pela firewall, pelas cópias de segurança, pela monitorização e pelo reboot às 2am é sua. Num VPS gerido, o fornecedor trata de parte dessas tarefas, mas essa parte pode variar bastante entre hosts. A única comparação útil é a lista de tarefas que cada plano retira das suas mãos, comparada com o custo das suas próprias horas.

Não existe uma definição padrão para a palavra gerido. Para alguns hosts, isso significa que o sistema operativo recebe atualizações e que uma pessoa responde a um ticket. Para outros, significa apenas que foi instalado um painel de controlo e que tudo o que está acima dele fica a seu cargo. Também pode significar um contrato de serviço escrito, com um tempo de resposta definido. Dois planos com a mesma designação podem ser diferentes em todos os aspetos relevantes. Por isso, leia o documento de escopo antes de consultar o preço. Se ainda está a decidir para que serve a máquina, o que pode realmente fazer com um VPS é a melhor questão para esclarecer primeiro.

As tarefas que alguém precisa assumir

Todo servidor em execução tem a mesma lista de tarefas. Num plano não gerido, essa lista é sua. Num plano gerido, paga para que algumas linhas sejam retiradas dela. Percorra a lista e escreva um nome ao lado de cada item.

• Atualizações do sistema operativo e os reinícios exigidos pelas atualizações do kernel.
• Regras de firewall, mantidas corretas à medida que adiciona e remove serviços. Os fundamentos da firewall ufw para um VPS abrangem o conjunto inicial de regras.
• Acesso SSH: gestão de chaves, início de sessão por palavra-passe desativado, revogação de uma chave quando alguém sai e uma forma de voltar a entrar quando fica sem acesso.
• Backups, uma cópia externa e um restauro que tenha realmente executado.
• Monitorização, o que significa saber se o servidor está acessível, se o disco tem espaço, se o serviço continua em execução e se o certificado não expirou.
• Revisão de logs e resposta quando algo nesses logs parece incorreto.
• Configuração dos serviços do servidor web, da base de dados, do reverse proxy e da fila, se utilizar uma.
• Renovação de certificados e correção quando a renovação automática deixa de funcionar.
• Capacidade, o que significa detetar que a memória está esgotada antes de o out of memory (OOM) killer o detetar por si.
• Resposta a incidentes, o que significa estar acordado e acessível a uma hora que não escolheu.

A maioria dessas tarefas é rotineira e pode ser atribuída a um script. A resposta a incidentes é a exceção, porque requer uma pessoa capaz de tomar decisões. Esse é o verdadeiro produto vendido por um plano gerido. Por isso, a lista de verificação mais abaixo dedica a maioria das perguntas ao âmbito do suporte, e não às atualizações.

O que normalmente não está incluído na gestão

É neste ponto que os compradores podem ter problemas, por isso seja rigoroso. Um contrato de gestão normalmente cobre o sistema operativo e o software instalado pelo fornecedor. A cobertura termina no limite da sua aplicação.

O seu próprio código é da sua responsabilidade. Um erro 500 da sua aplicação não é uma falha do servidor. O fornecedor confirma que o processo do servidor web está em execução e devolve o pedido ao cliente. Esse é um limite razoável. Também é a maior diferença entre o que os compradores esperam e o que contrataram.

Os problemas ao nível da aplicação normalmente estão fora do âmbito. Uma consulta lenta à base de dados, um plugin que deixou de funcionar depois de uma atualização, uma cache configurada incorretamente ou uma fila de correio que deixou de ser processada: tudo isto está acima desse limite, mesmo quando o fornecedor instalou o software subjacente.

A maior parte da recuperação de dados está fora do âmbito. As cópias de segurança do fornecedor protegem a imagem que o fornecedor tem do servidor completo e existem para o caso de falha do hardware do host. Raramente foram concebidas para o caso em que apagou uma linha, executou uma migração incorreta ou corrompeu um ficheiro há seis semanas e só hoje detetou o problema. Pergunte qual é o período de retenção, se é possível extrair um único ficheiro e quem executa o restauro.

O software que instalou é da sua responsabilidade. Se instalar Docker, o fornecedor normalmente gere o host, enquanto tudo o que está dentro dos containers fica sob a sua responsabilidade.

As edições manuais podem anular o suporte. Alguns contratos excluem um componente do âmbito do suporte depois de o cliente editar diretamente a respetiva configuração. Pergunte sobre esta condição se planear ajustar alguma coisa.

Valorize o seu tempo em relação à diferença mensal

Compare as duas propostas que tem à sua frente e anote a diferença mensal. Esse valor corresponde ao que o provedor cobra para eliminar os itens da lista acima. Agora atribua um valor ao seu lado da decisão.

• Quanto vale uma hora do seu tempo e quantas horas por mês essa lista exige depois de automatizada?
• Quanto custa uma hora de indisponibilidade para o serviço executado neste servidor?

Um servidor Ubuntu estável, com atualizações automáticas e monitorização externa, exige pouca atenção de rotina. Na maioria dos meses, não exige nenhuma. O trabalho de rotina fica barato quando é gerido por um script. As interrupções são a parte dispendiosa, e é para tratar delas que um plano gerido é vendido. Se o servidor executa um projeto pessoal, uma indisponibilidade não custa nada e a opção não gerida é a escolha óbvia. Se o servidor processa encomendas, avalie cuidadosamente se um contrato de suporte realmente reduz a duração da indisponibilidade, porque um provedor gerido ainda precisa de ler o seu ticket, reproduzir a falha e agir.

A diferença também aumenta com o número de servidores. As tarifas de serviços geridos normalmente são cobradas por servidor, enquanto a automação é escrita uma vez e copiada. O segundo servidor reduz para metade o custo efetivo do script que escreveu para o primeiro. Por isso, leia como gerir vários servidores Linux antes de aceitar uma tarifa por servidor. Para os valores base de ambos os lados da comparação, quanto custa realmente um VPS por mês define o limite inferior, e a comparação entre VPS e servidor dedicado torna-se relevante quando a carga de trabalho é suficientemente grande para que o custo adicional do serviço gerido seja um erro de arredondamento.

Perguntas a fazer a um host antes de pagar pelo plano gerido premium

Faça estas perguntas antes de pagar e peça as respostas por escrito. Uma página de vendas não é um documento de âmbito.

1. O que está incluído, tarefa a tarefa? Peça a lista, não o folheto.
2. O suporte cobre o software que eu instalar ou apenas o software instalado por vocês?
3. Aplicam patches automaticamente? Reiniciam o servidor para atualizações do kernel sem me perguntarem primeiro?
4. Quem é responsável se um patch aplicado por vocês causar uma falha na minha aplicação?
5. Fazem backups? Onde são armazenados, durante quanto tempo são mantidos e quem executa uma restauração?
6. Restauraram recentemente um servidor de um cliente? Quanto tempo demorou?
7. Qual é o tempo de resposta aos tickets? É diferente às 03:00 de um domingo?
8. Continuo a ter acesso root? Usar esse acesso reduz o que vocês suportam?
9. A tarifa é cobrada por servidor ou por conta?
10. Se eu sair, o que levo comigo? Uma configuração que exista dentro de um painel de controlo proprietário pode ser difícil de exportar.

A pergunta 5 determina a maioria das restantes. Um host que responde com precisão está a indicar que já executou esse procedimento. Uma resposta vaga significa que a restauração nunca foi testada. Um backup não testado é apenas uma cópia. A pergunta 5 também tem uma dimensão relacionada com a localização: o local físico onde as cópias estão armazenadas é uma questão jurídica tanto quanto técnica, e o que realmente importa ao escolher um país de alojamento explica esse tema.

O caminho intermédio: sem gestão mais automatização

A maioria dos leitores técnicos não quer nenhum dos extremos. Quer um plano sem gestão, com o trabalho rotineiro entregue à máquina, e a sua atenção reservada para aquilo que uma máquina não consegue avaliar. Configure isto no primeiro dia. Os primeiros dez minutos num VPS novo é o ponto de partida prático para quem escolhe um serviço sem gestão, e proteger o acesso SSH deve fazer parte da mesma primeira sessão.

Atualizações de segurança automáticas

sudo apt update && sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades

Esse ficheiro deve agora conter APT::Periodic::Update-Package-Lists "1"; e APT::Periodic::Unattended-Upgrade "1";. A ausência do ficheiro significa que nada é executado e que não receberá qualquer aviso. As duas linhas têm funções diferentes. Um 0 na segunda linha significa que nunca são instaladas atualizações. Um 0 na primeira linha apenas impede a atualização das listas de pacotes, pelo que as atualizações continuam a ser executadas com listas obsoletas e deixam silenciosamente de encontrar novas correções de segurança. Nenhum dos dois erros produz uma mensagem de erro.

Teste sem alterar o sistema. Note que o pacote é unattended-upgrades, enquanto o comando está no singular:

sudo unattended-upgrade --dry-run --debug

A saída lista todos os pacotes considerados e termina com a linha No packages found that can be upgraded unattended and no pending auto-removals quando não há nada pendente. As execuções reais são registadas em /var/log/unattended-upgrades/unattended-upgrades.log, por isso consulte esse local em vez de fazer suposições.

Uma atualização do kernel não produz qualquer efeito até a máquina reiniciar, porque o kernel em execução é o que foi carregado no arranque. O ficheiro /var/run/reboot-required aparece quando há um reboot pendente. Pode monitorizar esse ficheiro ou deixar a máquina tratar disso em /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Automatic-Reboot-WithUsers "false" impede o reboot enquanto houver alguém com sessão iniciada. Isto é mais seguro numa máquina que utiliza de forma interativa e inútil numa máquina em que ninguém inicia sessão. A configuração completa de unattended upgrades no Ubuntu explica a sintaxe da lista de bloqueio e as opções de email.

Monitorização executada noutro local

Um monitor executado no servidor não consegue avisar que o servidor está indisponível, porque também fica indisponível. Execute a verificação num segundo host ou num serviço externo. Uptime Kuma para monitorização de estado é a opção habitual para alojamento próprio e deve ficar numa máquina diferente daquela que monitoriza.

Monitorize pelo menos quatro aspetos: acessibilidade, utilização do disco, resposta da aplicação na porta real e expiração do certificado. O disco é o aspeto que mais frequentemente causa problemas. Um ficheiro de log ou uma base de dados que cresce um pouco todos os dias pode deixar a máquina indisponível num momento que nada mais prevê. O primeiro sintoma costuma ser um serviço que já não consegue escrever e termina.

df -h
sudo du -xh --max-depth=1 /var | sort -h
journalctl --disk-usage

Adicione também um heartbeat. Um temporizador no servidor chama um URL depois de cada backup ou verificação de integridade bem-sucedidos, e o monitor gera um alerta quando essa chamada deixa de chegar. Um servidor silencioso gera assim o seu próprio alerta, o que uma verificação apenas por consulta não consegue fazer quando é o caminho de rede que falhou.

Backups que restaurou pelo menos uma vez

sudo apt install -y restic
sudo sh -c 'umask 077; printf %s "a-long-random-passphrase" > /root/.restic-pass'
export RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
export RESTIC_PASSWORD_FILE=/root/.restic-pass
sudo -E restic init

restic init imprime created restic repository <id> at sftp:... uma vez. Executá-lo contra um repositório que já existe falha em vez de o substituir, que é o comportamento pretendido. Guarde uma cópia dessa passphrase fora do servidor: sem ela, o repositório não pode ser lido e não existe qualquer forma de recuperação.

sudo -E restic backup /etc /home /srv
sudo -E restic snapshots
sudo -E restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
sudo -E restic check

restic snapshots deve listar a execução que acabou de fazer com a data de hoje. restic check verifica a estrutura do repositório e imprime no errors were found. Faça agora a parte que a maioria das pessoas ignora:

sudo -E restic restore latest --target /tmp/restore-check
ls /tmp/restore-check/etc

O ficheiro que esperava encontrar está presente ou não está, e descobrir isso agora custa dez minutos. Em seguida, coloque a execução num temporizador para que não dependa de si. Escreva /etc/systemd/system/restic-backup.service:

[Unit]
Description=restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
Environment=RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
Environment=RESTIC_PASSWORD_FILE=/root/.restic-pass
ExecStart=/usr/bin/restic backup /etc /home /srv
ExecStart=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

E /etc/systemd/system/restic-backup.timer:

[Unit]
Description=Run restic backup daily

[Timer]
OnCalendar=daily
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
journalctl -u restic-backup.service -n 30 --no-pager
systemctl list-timers restic-backup.timer

list-timers mostra a próxima execução e o tempo restante. Um resultado vazio significa que ativou o serviço em vez do temporizador, que é o erro mais comum neste caso. Persistent=true executa um trabalho perdido depois do próximo arranque, para que uma máquina que esteve desligada durante a noite faça o backup na mesma. Backups Restic num VPS explica em mais detalhe a organização e a retenção dos repositórios, e serviços e temporizadores systemd explica os ficheiros de unidade linha a linha.

O que a automatização não resolve

Não substitui a capacidade de decisão. Um reboot automático às 02:00 acontece quer a aplicação volte a arrancar corretamente quer não. Por isso, confirme que todos os serviços arrancam sozinhos e faça depois um reboot de propósito enquanto está acordado:

systemctl is-enabled nginx docker
sudo reboot

Uma atualização sem supervisão também pode instalar um pacote que avaria a aplicação, e nada no processo sabe que isso aconteceu. É o monitor que deteta o problema, razão pela qual deixa de ser opcional quando as atualizações são automáticas. A máquina trata do trabalho rotineiro. O incidente continua a ser da sua responsabilidade.

Quando o serviço gerido compensa

É importante considerar com justiça a opção gerida. Quatro situações fazem dela a escolha certa.

• Ninguém na equipa administra Linux, e contratar alguém não faz parte do plano.
• Um requisito de conformidade identifica uma parte responsável pela aplicação de patches, e essa parte não pode ser você.
• A stack é uma das áreas em que o fornecedor se especializa, por isso o suporte já encontrou falhas como a sua.
• A pessoa que faria o trabalho de outra forma é o colaborador mais caro da equipa, e uma hora dessa pessoa custa mais do que um mês do serviço premium.

Um serviço gerido não é automaticamente mais seguro. Os planos geridos aplicam patches mais depressa do que um proprietário desatento, e isso é uma vantagem real. Também instalam frequentemente um painel de controlo, que é uma aplicação de grande dimensão exposta à rede, com uma página de login e o seu próprio histórico de vulnerabilidades. Essa pode ser uma troca razoável, mas continua a ser uma troca.

A decisão baseia-se sempre na mesma lista. Registe as dez tarefas, indique quem é responsável por cada uma em cada proposta e compare a diferença com o valor de uma hora da sua atenção. A maioria dos leitores técnicos que fazem isso acaba por escolher uma opção não gerida e entregar as tarefas rotineiras a um temporizador. Essa é uma resposta defensável, não apenas uma opção barata.

FAQ

Qual é a diferença entre um VPS gerido e um VPS não gerido?

Um VPS não gerido fornece-lhe a máquina e nada mais. Cabe-lhe aplicar patches, configurar a firewall, fazer cópias de segurança, monitorizar o sistema e reiniciar o servidor depois de uma atualização do kernel. Num VPS gerido, parte desse trabalho passa para o fornecedor, normalmente a camada do sistema operativo e o software que este instalou para si. O limite exato é definido por cada fornecedor, não pelo termo em si. Por isso, peça por escrito o âmbito de cada tarefa antes de comparar dois preços.

Um VPS gerido significa que não preciso das minhas próprias cópias de segurança?

Não. As cópias de segurança do fornecedor normalmente protegem a imagem do servidor inteiro mantida pelo fornecedor e destinam-se a situações em que o host falha. Raramente ajudam quando eliminou um ficheiro, executou uma migração incorreta ou corrompeu dados há semanas e só detetou o problema hoje. Pergunte durante quanto tempo os snapshots são mantidos, se é possível restaurar um único ficheiro e quem executa o restauro. Depois, mantenha a sua própria cópia externa com uma ferramenta como restic e teste-a com restic restore latest --target /tmp/restore-check para confirmar que funciona.

Um VPS gerido é mais seguro do que um VPS não gerido?

Não por si só. Um plano gerido aplica patches mais rapidamente do que um proprietário que nunca inicia sessão, o que reduz efetivamente o risco. Muitos planos geridos também instalam um painel de controlo, e um painel é uma aplicação de grandes dimensões exposta à rede, com a sua própria página de início de sessão e o seu próprio histórico de vulnerabilidades. Um servidor não gerido com atualizações de segurança automáticas, uma firewall fechada, SSH apenas com chaves e nada adicional a escutar é um alvo menor do que um servidor gerido com um painel em execução.

Posso começar com um VPS não gerido e mudar para um VPS gerido mais tarde?

Normalmente, sim, embora raramente seja apenas uma opção a ativar. Os fornecedores costumam auditar ou reconstruir um servidor antes de assumirem a responsabilidade por ele, porque não suportam uma configuração que não conseguem consultar. Pergunte em que consiste a integração, se é necessária uma reinstalação e se alguma configuração feita por si ficará posteriormente fora do âmbito do suporte.

Mantenho o acesso root num VPS gerido?

Na maioria dos planos de VPS gerido, sim, mas o acesso root e o âmbito do suporte estão relacionados. Alguns fornecedores reduzem ou anulam o suporte de um componente que editou manualmente, e alguns reconstruirão o servidor a partir do seu próprio template se um pedido de suporte exigir uma análise aprofundada. Obtenha essa regra por escrito antes de ajustar qualquer configuração e mantenha os ficheiros de configuração num sistema de controlo de versões. Assim, uma reconstrução demora uma hora em vez de um fim de semana.