Quando vale a pena obter um DBA?

Question

Eu já trabalhei em algumas empresas de tecnologia que variam de 10 pessoas a ~ 150 e nunca encontrei um DBA real. Quão grande uma empresa precisa obter antes de obter um DBA? Quais são os critérios que precisam ser atendidos?

(Eu também postei isso em estouro de pilha . É apenas em ambos os lugares porque um moderador sugeriu, "Isso pode ser um daqueles raros casos em que vale a pena perguntar tanto em SO quanto em SF ")

    

Answer 1

Para muitas empresas, elas simplesmente não precisam de um DBA em tempo integral, mesmo que tenham um banco de dados interno construído em casa. Outros precisam de vários DBAs.

Como uma pessoa mencionou quando o custo de perder o banco de dados é maior que o salário do DBA, então obtenha um. Esse é um ótimo lugar para começar. No entanto, se o banco de dados não muda muito, e está em bom hardware, uma empresa provavelmente poderia passar por anos sem um DBA em tempo integral. O truque aqui é ter um bom consultor local (ou remoto) para garantir que os backups sejam automatizados e que a manutenção do outro banco de dados esteja acontecendo regularmente. Peça-lhes que verifiquem o sistema algumas vezes por ano para um exame de saúde e contratem-no para lidar com grandes projetos e atualizações de servidores, e você deve estar bem na maior parte do tempo.

À medida que a empresa crescer, você terá um funcionário de nível mais avançado para lidar com as coisas do dia-a-dia, mas mantenha o consultor em ordem, até que valha a pena pagar o preço de um DBA sênior. .

Não há empresa de tamanho que precise de um DBA. A empresa em que estou agora é uma pequena empresa de 20 pessoas, mas nós vivemos e morremos por nosso banco de dados, portanto, contratar um DBA de nível sênior fazia sentido. Eu tenho clientes do projeto lado que são centenas de empresas que só têm um sistema de processamento de pedidos em casa onde o banco de dados raramente muda. Eu atualizei o servidor em 2007 e não voltei desde então. Eu faço o check-in a cada poucos meses e sou informado de que o sistema está funcionando bem e está se apoiando para que eu continue do meu jeito.

    

Answer 2

Se você estiver usando apenas software de terceiros, eu diria que isso depende do RDBMS que você usará (Oracle, MySQL, DB2, MS SQL, etc.), o tamanho dos dados relativos à energia do hardware em que será armazenado e da qualidade do software de terceiros. Para pequenas coisas em bancos de dados fáceis de usar, ter um (com vontade) tech guy fazer o básico é provavelmente suficiente. OTOH, a elaboração de um desenvolvedor que quer escrever código da web e forçá-la a fazer backup de bancos de dados Oracle é uma má idéia.

Se você está fazendo um desenvolvimento interno, gostaria de saber quais são os requisitos de escalonamento do banco de dados (você está construindo o próximo google ou twitter, ou está mantendo receitas?). O que você quer que o DBA faça (faça backup dos bancos de dados? Proteja os bancos de dados? Participe do desenvolvimento? Escreva o código? Esquema do banco de dados do arquiteto? Trabalhe na ampliação ou scale-out? Crie um esquema de replicação? Interaja com fornecedores de hardware? Especificar hardware? Criar "padrões de codificação"? Basta reunir os gatos?).

Colocar um DBA no início pode ajudar a evitar que os projetos enfrentem problemas mais tarde, e geralmente é mais barato evitar erros comuns do que corrigi-los depois.

    

Answer 3

Eu diria que isso depende.

Como esse é um negócio, pergunte-se: "Qual é o custo de perder esse banco de dados?"

Assim que o custo for maior ou igual ao salário de um DBA, contrate um DBA.

O "custo" será um número difícil de encontrar. Mas deve incluir tempo de recuperação, perda de produtividade (por usuário) e perda de vendas. Locais como a Amazon (que atingiu o pico há alguns anos com 60 vendas por segundo) podem colocar um número definido no custo de inatividade.

    

Answer 4

Depois de ter um servidor de banco de dados e começar a ter problemas de desempenho, é hora de obter um DBA, IMO. Pode haver momentos em que os desenvolvedores tenham experiência suficiente para lidar com uma configuração inicial de banco de dados em alguns casos.

    

Answer 5

Dependendo dos recursos e do tempo gasto para gerenciar o banco de dados, qual é a preocupação e onde o banco de dados está hospedado. Muitas empresas decidem que é mais rentável e confiável fazer parceria com um provedor de hospedagem gerenciado que ofereça serviços de banco de dados para um DBA superior que pode ficar ocioso durante a maior parte do dia e usado como um seguro de 'e se'.

    

Answer 6

Isso realmente depende de quantos Bancos de Dados você precisa gerenciar. Temos um DBA no local e ele é muito bom. Temos Instâncias de Oracle PROD / TEST / TRAIN / DEV que exigem patches de segurança frequentes, correções regulares e upgrades após os ciclos de teste de regressão do lado funcional. Fora isso, qualquer outra coisa na empresa que usa um banco de dados Oracle ou SQL também gerencia. Ele tem a tarefa de manter clones atualizados para testes e também gerencia os backups de banco de dados do RMAN no Enterprise Manager.

Considerando que nosso banco de dados é a força vital da empresa, acho que, em determinadas situações, você precisa ter um DBA habilidoso na equipe.

    

Answer 7

Se você precisa ou não contratar um DBA, precisa ter alguém encarregado dos servidores de produção e desenvolvimento.

Você precisa ter uma determinada pessoa encarregada das alterações de produção.

Em grandes projetos com mais de dois desenvolvedores, você precisa ter uma pessoa encarregada de migrar as alterações para o desenvolvimento (de estações de trabalho ou esquemas de usuários).

Se você planeja usar o Reporting Services ou os serviços de análise, poderá investigar um DBA especializado nessas tecnologias.

Se você tiver dados confidenciais, é melhor verificar se alguém está monitorando e se a segurança está correta - ou então você pode entrar em conflito com os regulamentos do governo, o que custa dinheiro.

    

Answer 8

Quando

1. O trabalho de DBA é sobre a cabeça de quem está fazendo isso ou
2. A pessoa que está fazendo o trabalho do DBA agora é mais bem aproveitada em outros lugares.

Answer 9

Gostaria de sugerir que, assim que os bancos de dados começarem a ocupar tempo suficiente para que você não consiga concluir seu trabalho, talvez considere isso.

Tente obter um DBA com um plano de fundo multidisciplinar, para que eles tenham algo a fazer além de ficarem esperando o banco de dados quebrar.

    

Answer 10

Não estou convencido de que os DBAs sejam necessários.

Como desenvolvedor de aplicativos, acho que um DBA é desnecessário - qualquer modificação no lado do aplicativo deve ser feita pelos desenvolvedores de aplicativos - um DBA não pode nem deve fazer essas alterações (de fato, essas mudanças devem passar pelo mesmo alterar o controle e o QA como qualquer outra mudança da equipe de desenvolvimento, para que o DBA se tornasse um dos integrantes da equipe.

Da mesma forma, qualquer coisa que NÃO seja uma alteração no aplicativo é um problema de sysadmin e deve ser tratada pela equipe de operações com a diretiva de controle de alterações THEIR - novamente, não no território do DBA.

Quando eu descobrir para que serve, eu avisarei você.

Na minha opinião, os DBAs não podem fazer muito trabalho de desempenho, porque 99% disso virá da modificação do aplicativo, que as operações não devem fazer.

    

Answer 11

Provavelmente, mais ou menos na mesma época do ciclo de administração, é melhor ter um Administrador de Sistema do que alguém que faça parte desse tempo, bem como seu trabalho real.

Claro que, em parte, essa é uma resposta irrelevante, mas apenas uma que pretende fazer você pensar. Você precisa de um administrador de sistema em geral para gerenciar a segurança, a disponibilidade e o desempenho de seus sistemas de back-end. Você precisará de um dba para gerenciar a segurança, disponibilidade e desempenho de seus sistemas de banco de dados. Em ambos os casos, vale a pena separar o trabalho quando ele começa a levar muito tempo, tornando-se muito complicado ou consumindo recursos muito escassos.