Realmente depende se o desenvolvedor tem alguma responsabilidade de suporte. Se eles estiverem no gancho para suporte de terceira linha, provavelmente precisarão consultar o banco de dados de produção para fazer isso.

Geralmente é uma má ideia fazer qualquer coisa em um servidor de produção, a menos que seja realmente necessário fazê-lo lá.

Para a maioria dos propósitos de desenvolvimento, os espelhos ou instantâneos do banco de dados de produção serão adequados e provavelmente melhores do que o banco de dados de produção ao vivo. Se você estiver fazendo algo que envolva integração, você desejará ambientes de banco de dados estáveis ​​onde você possa controlar o que está neles. Qualquer coisa que envolva reconciliação também precisará da capacidade de olhar para um ponto no tempo controlado.

Se o problema é que você não tem ambientes de espelho de produção ou qualquer meio de colocar uma cópia dos dados de produção em algum lugar para seus desenvolvedores, então essa é uma questão um pouco diferente. Nesse caso, seus desenvolvedores realmente precisam de pelo menos um ambiente de espelho. Se você não consegue ver qual é o problema nos dados, é meio difícil resolvê-lo.

Não.

Os desenvolvedores não devem ter acesso a sistemas de banco de dados de produção pelos seguintes motivos:

1. Disponibilidade e Desempenho : Ter direitos somente leitura em um banco de dados não é inofensivo. Uma consulta mal escrita pode:

   1. Bloqueie tabelas, bloqueando outros processos críticos.
   2. Trash seu cache de dados, forçando outros processos a reler os dados do disco.
   3. Taxar sua camada de armazenamento, impactando outros serviços que compartilham esse armazenamento.

2. Segurança : Seu banco de dados de produção pode conter informações confidenciais como:

   • hashes de senha
   • Informações de pagamento
   • outras informações de identificação pessoal

   Somente aqueles que absolutamente precisam ter acesso a essas informações devem tê-las. Em uma empresa bem organizada, os desenvolvedores não estão entre essas pessoas. Além disso, sua empresa falhará em conformidade com PCI e SOX se seus desenvolvedores puderem acessar os sistemas de produção com esses dados.

   As razões para isso são óbvias. O trabalho de desenvolvimento de um desenvolvedor passa por muitas mãos antes de ser lançado. O que impede um desenvolvedor mal-intencionado com acesso direto à produção de roubar seus dados de produção ou deixar seu banco de dados ativo de joelhos?

   "Mas isso vale para os DBAs também! Eles poderiam fazer isso!" Exatamente. Você quer o mínimo possível de superusuários com responsabilidade.

Sim.

Os desenvolvedores devem ter acesso aos sistemas de produção.

Na minha empresa temos quatro equipes que lidam com bancos de dados de produção. Eles são:

1. Desenvolvedores , que projetam e escrevem o esquema e o código para os bancos de dados. Eles não têm acesso aos bancos de dados em produção. Eles, no entanto, às vezes sentam-se com os administradores ou pessoas de suporte e os ajudam a ver algo ao vivo.
2. Administradores , que implantam, monitoram e gerenciam os bancos de dados em produção.
3. Apoiar as pessoas , que investigam problemas de produção sensíveis ao tempo e fornecem feedback aos desenvolvedores para que eles possam desenvolver correções.
4. Pessoas de Business Intelligence , que extraem dados de bancos de dados de produção usando cópias atualizadas regularmente desses bancos de dados ou extrações cuidadosamente escritas e com controle de qualidade (geralmente projetadas pelos administradores).

É apropriado conceder acesso de produção aos seus desenvolvedores quando você tiver certas deficiências nesses outros grupos.

Por exemplo:

• Você não tem equipe de suporte. Quem vai saber onde procurar para depurar esse problema de produção sensível ao tempo? Seus desenvolvedores. Conceda-lhes acesso " quebrar o vidro ".
• Você não tem uma equipe de BI. Seus administradores não têm ou não querem saber de relatórios ou extratos. Quem vai solucionar o relatório que seus executivos veem todas as manhãs? Seus desenvolvedores. Conceda a eles acesso limitado para depurar esses relatórios e extrações.
• Você não tem uma equipe administrativa. Você está em uma empresa muito pequena ou iniciante, então diga olá ao "DBA acidental". Seus desenvolvedores funcionam como seus administradores e, portanto, precisam de acesso total à produção.

Desempenho seria um GRANDE motivo.

Só porque eles não podem alterar os dados não significa que eles não podem afetar o servidor. Uma consulta mal escrita pode deixar o ambiente de produção de joelhos e potencialmente causar outros problemas (como estouros de tempdb):

SELECT *
FROM BigTable A, OtherBigTable B
ORDER BY Somecolumn

Essa é uma receita para o desastre. Observe que este é um produto cartesiano com um order by, o que significa que será classificado em tempDB.

O princípio é "menor privilégio" e "precisa saber": os desenvolvedores passam neste teste?
Especialmente quando Auditores ou Sarbannes-Oxley vêm bater.

Então, minha próxima suposição: os desenvolvedores são estúpidos. Então, se eles precisam de suporte de 3ª linha, quem precisa disso ? Os macacos da Web normalmente não, mas os tipos de banco de dados sim, se espera-se que eles o suportem.

Então, o acesso é necessário permanentemente? Eles podem ter acesso "quebrar vidro" usando um login SQL ou uma conta alternativa do Windows que requer uma aprovação. No nosso caso, era o proprietário dos dados (algum empresário experiente em tecnologia, espero) e o gerente de TI para aprová-los.

Já vi desenvolvedores testarem ou executarem consultas na produção e derrubá-las por ignorância. Dizendo isso, os desenvolvedores devem assumir a responsabilidade por suas ações: se eles derrubarem um servidor, eles devem sofrer de acordo. Eu tenho alguém rebaixado após um incidente...

Estes assumem uma loja de tamanho razoável, é claro. Quanto mais chapéus as pessoas usam, menos separação de deveres você pode ter

Além disso, existe um ambiente em que os desenvolvedores possam executar consultas em dados recentes? Na minha última loja, o prod era restaurado todas as noites em um servidor de teste para fornecer isso.

Acho que a resposta é, como muitas coisas de TI, "depende".

Um enorme banco de dados ERP com muitas informações confidenciais da empresa e do cliente? Provavelmente não (tanto por motivos de segurança quanto de desempenho).

Um banco de dados departamental de 5 MB com um front-end de acesso que rastreia as contribuições para os fundos de donuts e pizzas? Não vai fazer muita diferença, pelo menos para acesso somente leitura.

É verdade que o primeiro exemplo é muito mais comum que o segundo, mas essas são as diferenças das quais você deve estar ciente se for responsável por tomar esses tipos de decisões de política. Mas, por outro lado, é incrível a rapidez com que um banco de dados de fundos de donuts e pizza de 5 MB pode rastejar para um número de peça de 50 GB/números de cartão de crédito do cliente/quem-sabe-o-que- else banco de dados se você permitir.

Em um ambiente OLTP 24 horas por dia, 7 dias por semana, um desenvolvedor normal não deve ser permitido em produção. Período! Se, de tempos em tempos, um motivo específico aparecer, as permissões poderão ser concedidas mediante solicitação. Mas normalmente não.

Já vi muitos motivos para isso:

• SELECT * de uma grande tabela que leva a:

  • questões de desempenho (produtos cartesianos);
  • problemas de bloqueio que acabaram por colocar o site de joelhos;
  • cadeia de bloqueio que interrompe a replicação;
  • ordenando um grande conjunto de dados que encheu a unidade TempDB que .. adivinha? Causou loucura completa :-)!
  • pressão alta para o DBA responsável pela produção daquela noite;

• leitura de dados confidenciais (um desenvolvedor não deve ter acesso a informações de cartão de crédito... ou quaisquer detalhes pessoais do usuário);

Tenho certeza de que há ainda mais razões.

• Segurança: Pode haver informações confidenciais que são higienizadas quando são disponibilizadas aos desenvolvedores.
• Paranóia: Alguns podem pensar que você ainda pode estragar os dados apenas com acesso selecionado.
• Desempenho: uma consulta requer alguns recursos para ser executada e você não pode me dizer que seus desenvolvedores são perfeitos quando escrevem código.

Alguns itens a considerar

• Os dados são sensíveis?
• Os programadores fazem parte de uma equipe central de confiança ou de alguma equipe offshore?
• Qual é a escala dos dados consultados em termos de impacto no desempenho?
• Qual é a escala do projeto ou dólares envolvidos?
• Quão crítico é o tempo de atividade?

Dólares menores precisam de menos processo precisa de fluxo mais rápido de desenvolvimento.

Dólares maiores precisam de mais processos precisam de padrões mais rígidos de práticas de desenvolvimento.

Adapte suas práticas ao que você está fazendo.

Eu trabalho como desenvolvedor para uma empresa muito grande. Todos os nossos desenvolvedores que farão qualquer tipo de suporte (basicamente todos eles) têm acesso a bancos de dados de produção relevantes. Eu só posso falar pela minha equipe específica, mas vou dizer por que temos acesso.

1. Precisamos de acesso em tempo real para ficar de olho no nosso processamento diário. (Embora tenhamos um painel, precisamos estar atentos às coisas. Embora seja bom ter esse recurso em nosso painel, descobrimos que isso não é prático.)
2. Precisamos de acesso em tempo real para investigar quaisquer falhas de produção porque os atrasos podem ter um impacto enorme. (Eu não vou discutir nossos fracassos aqui. Eles vêm em todos os tipos)
3. Muitas vezes precisamos fazer relatórios personalizados para usuários corporativos e essas informações precisam estar atualizadas. (dba não tem tempo para fazer isso e não temos tempo para esperar por eles. Não é o ideal, com certeza.)
4. Precisamos fazer a verificação das implantações/patches DDL/DML de produção. (Os DBAs os implantam, mas só nós sabemos como ele deve ser estruturado. Sabemos mais sobre nossa estrutura de banco de dados do que os DBAs. Podemos ser estranhos aqui, mas nosso banco de dados é muito complicado porque nosso negócio é muito complicado.)

O desempenho é uma preocupação. Temos ocorrências de desenvolvedores causando lentidão. No entanto, essas são instâncias isoladas e nosso SQL é tão orientado ao desempenho que é raro nossos desenvolvedores não entenderem o impacto de suas consultas.

Para que esta pergunta seja feita, deve-se presumir que eles atualmente não têm acesso. Se uma organização está desenvolvendo software e isso é para solucionar um problema do cliente e o cliente fornece uma cópia de seu banco de dados, então 'sim'. Caso contrário, eu defenderia manter os desenvolvedores fora de produção e criar ambientes alternativos para suas necessidades de pesquisa. Uma vez que a pasta de dente está fora do tubo, é difícil colocá-la de volta.