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, com 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-o no primeiro dia. Os primeiros dez minutos num novo VPS é o ponto de partida prático para quem escolhe um plano sem gestão, e proteger o acesso SSH deve fazer parte dessa 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";. Um ficheiro em falta, ou um 0 em qualquer uma das linhas, significa que nada é executado e que não receberá qualquer aviso.

Teste-o sem alterar o sistema. Tenha em atenção que o pacote é unattended-upgrades, enquanto o comando fica no singular:

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

A saída apresenta todos os pacotes considerados e termina com uma linha semelhante a No packages found that can be upgraded unattended 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 adivinhar.

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 é necessário reiniciar. 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" adia o reinício enquanto houver alguém com sessão iniciada. É mais seguro num servidor que utiliza interativamente e não serve para nada num servidor em que ninguém inicia sessão. A configuração completa de atualizações unattended no Ubuntu aborda a sintaxe da blocklist e as opções de email.

Monitorização executada noutro local

Um monitor executado no servidor não consegue informar que o servidor está indisponível, porque também fica indisponível. Coloque 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 sua porta real e validade 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 o servidor indisponível num momento que nada mais prevê. Muitas vezes, o primeiro sintoma é um serviço que 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-sucedido, e o monitor alerta quando essa chamada deixa de chegar. Assim, um servidor silencioso gera o seu próprio alerta, algo que uma verificação apenas por pull não consegue fazer quando o problema está no caminho de rede.

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 apresenta 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 apresentar a execução que acabou de fazer, com a data de hoje. restic check verifica a estrutura do repositório e apresenta no errors were found. Agora faça 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 está presente ou não está, e descobrir isso agora demora dez minutos. Depois, 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 apresenta 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 ainda faça o backup. 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 resolve a necessidade de avaliação. Um reinício automático às 02:00 acontece independentemente de a aplicação voltar a funcionar corretamente. Por isso, confirme que todos os serviços arrancam sozinhos e reinicie depois, de propósito, enquanto está acordado:

systemctl is-enabled nginx docker
sudo reboot

Uma atualização unattended também pode instalar um pacote que quebra a aplicação, e nada no processo sabe que isso aconteceu. É o monitor que deteta o problema. Por isso, o monitor 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.