Quanto custa um servidor privado para um fundador a solo?

Quanto custa um servidor privado para um fundador a solo? Uma lista prática

Não é possível fazer uma estimativa de preço útil sem definir o que o servidor privado vai executar. Um fundador a solo que aloja uma aplicação destinada aos clientes terá uma fatura diferente da de alguém que também executa uma base de dados, tarefas em segundo plano, um ambiente de teste e testes automatizados na mesma máquina. Se procura um servidor para aplicação de fundador a solo, comece por identificar estas cargas de trabalho.

Use as seis etapas abaixo para estimar separadamente os custos em dinheiro e o tempo despendido. Assim, terá um orçamento ajustado à sua aplicação, em vez de uma configuração genérica de startup. Consulte os preços atuais dos fornecedores antes de introduzir qualquer valor; os preços e as condições de faturação podem mudar.

Se está a perguntar «quanto custa um servidor privado para um fundador a solo?», comece por preencher as cargas de trabalho e os serviços abaixo. Não atribua um preço a nenhum item até o confirmar junto do fornecedor relevante.

Etapa 1 — Defina a configuração do fundador a solo

Anote a aplicação que pretende executar. Inclua os componentes principais, como o processo web, a base de dados, os ficheiros carregados e as tarefas agendadas. Se a aplicação precisar de um ambiente de teste separado ou de um processo de trabalho, inclua-o na lista; caso contrário, deixe-o de fora desta estimativa.

Defina o que significa «servidor privado» para este cálculo. Pode tratar-se de um servidor virtual privado fornecido por uma empresa de alojamento, de uma máquina física dedicada ou de uma instância privada numa plataforma de cloud. Estas opções podem ter modelos de faturação diferentes, por isso não as compare como se «servidor» significasse o mesmo produto em todo o lado.

Mantenha o âmbito limitado. Quem está a calcular o custo de uma aplicação web não precisa de incluir um sistema de identidade para toda a empresa, um chat de equipa ou uma rede de escritório, a menos que a aplicação dependa desses elementos. Este limite facilita a comparação da estimativa do primeiro mês com a fatura real.

Faça uma breve nota sobre o âmbito, por exemplo:

• Aplicação: indique o nome do produto e a sua função principal.
• Ambiente: apenas produção ou produção e ambiente de teste.
• Dados: base de dados, ficheiros carregados e quaisquer cópias de segurança necessárias para a aplicação.
• Operações: tarefas agendadas, monitorização e administração remota.

Mantenha esta lista junto do orçamento. Se o plano de um fornecedor incluir uma funcionalidade de que não precisa, registe esse facto em vez de a tratar como um requisito.

Etapa 2 — Meça o que já utiliza

Comece pelos dados da aplicação atual, mesmo que esteja a funcionar num plano de avaliação ou numa máquina local. Registe os recursos de computação utilizados, a quantidade de dados armazenados e o tráfego enviado e recebido. O painel de controlo do serviço de alojamento, os registos da aplicação ou a consola da base de dados podem fornecer alguns destes valores; indique a fonte de cada um.

Meça um período representativo, por exemplo, o período abrangido pelo painel de controlo atual, e anote as respetivas datas. Não transforme um pico breve no lançamento numa necessidade de capacidade permanente sem verificar o que o provocou. Uma importação pontual, por exemplo, pode exigir uma resposta diferente da do tráfego regular de utilizadores.

Separe os tipos de armazenamento. A base de dados da aplicação, os ficheiros dos clientes, os registos do servidor e as cópias de segurança podem ter necessidades de retenção diferentes e ser faturados de formas distintas. Se ainda não tiver uma cópia de segurança, registe o plano necessário como uma questão por resolver, em vez de assumir que está incluído no preço do servidor.

Crie uma pequena folha de registo:

• Computação: utilização atual e carga de trabalho que a provoca.
• Armazenamento: base de dados, ficheiros, registos e cópias de segurança, em linhas separadas.
• Tráfego: utilização de entrada e saída, nas unidades indicadas pelo fornecedor.
• Períodos de pico: a data e o evento na origem de qualquer aumento invulgar.

Esta etapa evita um erro comum de orçamentação: escolher um servidor com base numa descrição genérica de «aplicação pequena» quando é a sua base de dados ou o tráfego de ficheiros que determina os requisitos. Guarde as medições originais para as comparar com a primeira fatura.

Etapa 3 — Calcule os custos em dinheiro do primeiro mês

Consulte os preços do servidor e de cada serviço necessário para executar a aplicação. Verifique os preços atuais na página do fornecedor e confirme se o valor apresentado pressupõe um período de faturação, uma região, um sistema operativo ou um método de pagamento específico. Anote a data da consulta; um orçamento guardado é mais útil do que um valor de que se lembra de uma pesquisa anterior. Para saber como calcular custos de alojamento web, some as rubricas necessárias apenas depois de confirmar os preços e o que cada plano inclui.

Use linhas separadas em vez de uma única rubrica genérica de «alojamento». Um plano de servidor pode não incluir um domínio, armazenamento para cópias de segurança, um serviço de base de dados, tráfego de saída, monitorização ou uma licença de software paga. Alguns destes elementos podem estar incluídos, mas confirme cada um nos detalhes do plano antes de indicar um custo de zero.

Para cada rubrica, guarde a página ou o orçamento que confirma o valor. Verifique se a primeira fatura pode incluir um período de faturação parcial, um custo de configuração ou uma renovação a um preço diferente. Estes detalhes podem fazer com que o valor a pagar no primeiro mês seja diferente do custo mensal recorrente.

Se a aplicação depender de um serviço de proxy pago para pedidos de saída, trate-o como uma dependência da aplicação, não como parte do preço do servidor. Antes de o incluir na estimativa, consulte quanto custa um proxy para o nível de utilização previsto.

Etapa 4 — Tenha em conta o tempo que dedica à operação

Uma fatura baixa do servidor pode, ainda assim, exigir várias horas de trabalho. Faça uma lista das tarefas previstas: configuração inicial, implementação da aplicação, instalação de atualizações, verificação de cópias de segurança, análise de alertas e diagnóstico de falhas. Estime o tempo de cada tarefa em horas, mas mantenha essas horas separadas das despesas em dinheiro.

Use um registo simples do tempo durante o primeiro mês. Anote a data, a tarefa e o tempo despendido. Por exemplo, um problema na implementação que surja numa terça-feira deve constar do registo, mesmo que o resolva durante uma pausa para café; caso contrário, o esforço de manutenção desaparece da sua análise de custos.

Não atribua um valor arbitrário ao seu tempo, a menos que tenha uma razão clara para o fazer. Pode apresentar dois valores: o dinheiro pago aos fornecedores e as horas dedicadas à operação do servidor privado. Se mais tarde comparar o servidor com um serviço gerido, estes dois valores ajudam a perceber se uma fatura mais baixa lhe está a custar demasiado tempo como fundador.

O acesso remoto também deve fazer parte do plano de operação. Se pretende ligar-se ao servidor através de uma VPN, indique separadamente qualquer serviço de VPN pago e consulte as condições do respetivo plano; este guia sobre como escolher uma VPN pode ajudar a avaliar essa dependência específica.

Defina um limite para a resolução de problemas. Por exemplo, decida antecipadamente se um problema recorrente de implementação justifica dedicar-lhe mais uma hora ou se deve levar a uma mudança de plano de alojamento. O limite é uma decisão sua, não um padrão universal.

Etapa 5 — Defina um limite de despesas seguro antes do lançamento

Defina um limite mensal de despesas antes de publicar a aplicação. Baseie-o no orçamento de que dispõe e anote quais os custos incluídos: servidor privado, armazenamento, tráfego, cópias de segurança e serviços da aplicação. Um limite que exclua uma dependência paga não lhe dará um aviso sobre o custo total.

Configure os alertas de faturação que o fornecedor disponibiliza. Verifique para onde é enviado cada alerta, qual o evento de despesa ou utilização que o aciona e se é apenas uma notificação, em vez de um limite rígido de despesa. Não assuma que um alerta impede cobranças adicionais; confirme os controlos disponíveis na documentação de faturação do fornecedor.

Decida o que fará se a utilização ou os custos ultrapassarem o limite. Entre as ações possíveis estão investigar um pico de tráfego, pausar uma tarefa não essencial, reduzir o nível do serviço ou restringir temporariamente uma funcionalidade que gere uma utilização invulgar. Anote a ação junto do alerta para não ter de tomar essa decisão pela primeira vez durante um incidente.

Um limite só é útil se levar a uma verificação. Programe um lembrete no calendário para perto da data de faturação, de modo a consultar o painel de controlo e comparar a estimativa atual com a utilização registada. Se o fornecedor permitir definir orçamentos separados por projeto ou alertas ao nível do serviço, configure-os para a aplicação em vez de depender apenas de uma notificação geral da conta.

Mantenha uma pequena margem de segurança apenas se o seu orçamento o permitir e não a encare como uma autorização para ignorar o limite. O objetivo é saber que alteração fará quando a fatura se aproximar do valor máximo, em vez de presumir que um custo excedente não terá consequências.

Etapa 6 — Reveja o custo real depois da primeira fatura

Quando chegar a primeira fatura, compare cada custo com a rubrica correspondente da sua estimativa. Verifique o período faturado, a moeda, os impostos, os créditos, os custos pontuais e quaisquer taxas baseadas na utilização. Se algum valor não corresponder, consulte os detalhes de faturação do fornecedor antes de alterar o plano do servidor.

Compare a utilização real com as medições da Etapa 2. Se o armazenamento tiver aumentado mais depressa do que o previsto, identifique se a causa foram os ficheiros carregados pelos clientes, os registos ou o período de retenção das cópias de segurança. Se o tráfego tiver sido superior, verifique se veio de utilizadores reais, de uma tarefa automatizada ou de um processo de implementação antes de concluir que a aplicação precisa de um servidor maior.

Reveja também o registo do tempo. Se tiver dedicado várias sessões a uma tarefa que esperava fazer apenas uma vez, como restaurar uma cópia de segurança ou corrigir um script de implementação, atualize a estimativa do tempo de operação. Se voltar a acontecer, pode ser sinal de que deve alterar a configuração ou documentar o procedimento com mais clareza.

Sempre que possível, faça uma alteração de cada vez. Alterar ao mesmo tempo o plano do servidor, a política de cópias de segurança e o comportamento da aplicação pode dificultar a identificação da mudança que afetou a fatura seguinte. Registe a data e o motivo da alteração e, depois, compare a fatura seguinte com as mesmas rubricas de custo.

Para terminar a revisão, substitua cada valor por preencher pelo montante indicado na fatura ou num orçamento atual do fornecedor e anote junto dele a data e a fonte. Assim, terá uma base concreta para tomar a próxima decisão mensal.