Quanto acesso ao banco de dados os desenvolvedores devem ter? [fechadas]


16

Por isso, trabalhei em muitos locais de trabalho diferentes como desenvolvedor e meu nível de acesso ao banco de dados foi variado. Normalmente não tenho acesso ao banco de dados de produção.

Na maioria das vezes, tenho acesso ao banco de dados de teste, mas isso varia. Às vezes, posso fazer e alterar o banco de dados e os dados como quiser, mas geralmente existem outras providências. Como se eu só tivesse acesso de leitura aos dados.

Eu trabalhei em um local em que uma equipe de DBA gerenciaria os bancos de dados; não poderíamos fazer alterações a menos que submetêssemos um formulário com o script sql para que eles "inspecionassem". Eles normalmente não tinham muito a ver com o projeto em si, então na maioria das vezes, era apenas para pressionar F5.

Honestamente, eu posso entender por que o prod precisa ser bloqueado, mas eu prefiro ter o mesmo acesso ao banco de dados nos ambientes de desenvolvimento e teste. Eu acho que a maioria dos desenvolvedores é razoavelmente capaz de conhecer o caminho de um banco de dados. Mas eu gostaria de ouvir opiniões? Quanto acesso ao banco de dados os desenvolvedores devem ter? Podemos confiar em não quebrar nada lá em cima?


6
Provavelmente você quis perguntar "Quanto acesso ao banco de dados de produção os desenvolvedores devem ter?"
Mayank

@ Mayank Você acertou a unha na cabeça. Sempre deve haver um servidor de teste para 'brincar' com novos conceitos. O servidor de produção deve ver apenas as versões revisadas / testadas / comprovadas. Eu diria o mesmo para sites (mesmo que a maioria dos desenvolvedores da Web não use um).
Evan Plaice

@Mayank - Sim, eu gostaria de ouvir sobre o acesso para bancos de dados de produção, mas também gostaria de ouvir opiniões sobre o acesso em ambientes diferentes, como DEV, INT, TEST, PREPROD etc. também
RoboShop

1
Embora tenha sido marcada como duplicada, a pergunta relacionada programmers.stackexchange.com/questions/246618/… é na verdade uma extensão interessante disso.
Eamon Nerbonne

Respostas:


16

Os desenvolvedores precisam ter acesso de leitura a todos os bancos de dados, incluindo prod. Às vezes, o problema é que os dados no Prod não são o que eles esperavam ter e eles precisam ver os dados que estão causando o problema, pois não podem reproduzi-los no dev.

Os desenvolvedores não devem ter direitos de gravação de dados de produção ou direitos para criar objetos. Não deve acontecer nada que não faça parte de um lançamento oficial. Muitas vezes, as pessoas corrigem rapidamente o produto que não funciona, fazendo com que o produto fique ainda mais mole ou funcione, mas esquecem de colocar o código nos servidores dev / QA / Staging e, pior ainda, na fonte repositório de controle e o código será sobrescrito cerca de um mês depois no próximo lançamento oficial.

Prefiro que os desenvolvedores tenham direitos completos de controle de qualidade do banco de dados porque a implantação em outro servidor os ajuda a ver se há alguma lacuna no processo de implantação (opa esqueceu que eu alterei a tabela para fazer isso e tal e oops, esqueci que fiz essa alteração usando a GUI e não em um script no controle de origem, que é como todas as alterações estruturais do banco de dados precisam ocorrer).

Quando você tem um novo cliente do tipo Enterprise que possui seu próprio conjunto de servidores, as permissões podem ser facilitadas antes da entrada em operação. Isso ocorre porque muita coisa precisa acontecer e as poucas pessoas que podem fazer isso acontecer no produto são acumuladas e, às vezes, precisam tirar uma folga. Em particular, as pessoas que estão importando dados de outro sistema podem receber a tarefa de colocá-los em produção antes do lançamento, se o carregamento de dados demorar muito. Essas pessoas tendem a ser especialistas em dados e há um nível de conforto mais alto ao permitir acesso temporário ao produto do que o desenvolvedor médio de aplicativos. Este não é um luxo que você tem ao acessar um servidor de produção já ativo.

Uma das coisas mais críticas sobre como limitar os direitos de produção ao banco de dados é que os desenvolvedores precisam garantir que seu trabalho esteja em um formato que possa ser implantado por outra pessoa. Isso tende a melhorar a qualidade do trabalho, porque eles não estão tentando fazer correções instantaneamente, porque se esqueceram de algo ou algo não funcionou, porque fizeram isso de maneira diferente em prod do que quando se baseavam apenas na memória. Você também perde aqueles "ops, eu apaguei a tabela inteira do usuário por acidente, porque eu esqueci de destacar uma cláusula where" do tipo de acidentes quando implantações de produtos usam apenas scripts que são executados como um todo, não um comando por vez, como é típico quando desenvolvedores executar as coisas no prod. Uma equipe com direitos limitados para produzir bancos de dados é mais provável que também armazene alterações no controle de origem.


1
+1 no comentário sobre o esquecimento de colocar as coisas no controle de origem. Acho que, independentemente dos direitos de acesso e de quem faz a migração para diferentes ambientes, deve ser o mais automatizado possível para garantir que todas as compilações sejam criadas a partir do código de controle de origem. Você deve tentar o máximo possível para limitar ao máximo qualquer processo que exija remotagem no servidor para mexer no código ou no banco de dados.
RoboShop

8
"Os desenvolvedores precisam de acesso de leitura a todos os bancos de dados, incluindo prod" não é necessário, pelo menos no meu trabalho anterior. Os dados do produto contêm registros e transações financeiras do cliente, que são confidenciais.
28411 ohho

3
@ohho, essa é uma exceção válida, mas deve ser realmente difícil solucionar um problema que você não pode reproduzir imediatamente no dev.
HLGEM 28/03

7

Bem, é realmente uma questão de "Vampiros (programadores) versus Lobisomens (administradores do sistema)", como Jeff Atwood colocou aqui .


Vá para a equipe Edward, eu acho.
Joel Etherton

2
@ Joel Etherton, para quem ainda não viu o filme, qual é o Team Edward?
CaffGeek

1
@ Chade É bom que você realmente não tenha visto essa porcaria de "Crepúsculo". Pelo menos você não terá que fingir que não viu, como eu. ;) #
Mayank

@Chad: Eu também não vi os filmes, mas Edward é o vampiro. Eu sei que, por causa do constante bombardeio dos comerciais do Burger King e da campanha idiota "compre nossa porcaria com Crepúsculo manchado por toda parte". Soja um programador.
Joel Etherton

Ah, eu sei que é bom, eu não vi. E eu nunca vou.
CaffGeek

7

Normalmente (isso significa que existe o luxo de configurar um ambiente completo), o acesso do desenvolvedor a:

  • Servidor de produção
    • Nenhum (o SA / PM solicitará a configuração do esquema, o usuário final fornecerá os dados init)
  • Servidor UAT
    • Nenhum (o SA / PM se aplicará à configuração do esquema e à propagação de dados de amostra)
  • Servidor de teste / controle de qualidade
    • Geralmente, o desenvolvedor envia o script de configuração do esquema à equipe de controle de qualidade e o controle de qualidade cria as tabelas
    • Os desenvolvedores têm acesso total aos bancos de dados, mas raramente os alteram
    • Os desenvolvedores podem ajudar os colegas de controle de qualidade a propagar / corrigir / excluir alguns dados
  • Servidor de desenvolvimento / host local
    • Acesso total

A principal razão por que os desenvolvedores não devem tocar nos servidores de produção é: quando algo dá errado, a equipe de operação é responsável, mas não os desenvolvedores.


2
Os desenvolvedores são sempre responsáveis, mesmo que não possam tocar no sistema, eles são os que acabam consertando-o.
Erin

2
Se a correção for uma alteração no banco de dados, é de responsabilidade da equipe de desenvolvimento produzir a correção e a equipe de operação aplicá-la. Além disso, por razões de sanidade, eu não permitiria que os desenvolvedores "alterassem" de forma alguma (dados ou estrutura) o ambiente de controle de qualidade. Qualquer alteração nesse ambiente deve ser tão controlada quanto o ambiente de produção.
Soronthar 25/03

2
Se você tem uma equipe de operação ...
Marcie

Eu pediria acesso somente leitura nos servidores de produção. Facilita a localização de bugs.
Carra

@Carra: Isso pode ter problemas regulatórios, pois os servidores de produção podem ter dados legalmente regulamentados (um sistema médico nos EUA deve estar em conformidade com a HIPAA, por exemplo). Eu nunca estive em um lugar em que alguém tentou restringir meu acesso a viver dados confidenciais, mas eles provavelmente existem.
precisa

2

O mínimo absoluto necessário para realizar o trabalho.

Se todos os desenvolvedores tiverem acesso total ao banco de dados, a chance de ficar com raiva (ou bêbado, ou extremamente cansado ou ...) e causar sérios danos será muito maior, se puderem ler apenas de um banco de dados.

Se seu trabalho pode ser realizado principalmente sem acesso de gravação ao banco de dados (e, na maioria das vezes, quero dizer no máximo algumas solicitações de alteração por semana), você realmente não precisa de acesso de gravação.


2

Existem 2 desejos concorrentes em todo o ambiente de trabalho.

  • O desejo de dar às pessoas acesso para que possam resolver os problemas por conta própria. Isso permite que eles sejam rápidos e de autoatendimento.
  • O desejo de limitar e controlar o acesso para evitar danos, tempo de inatividade ou perda de dados (intencional ou não).

Parte do que molda o equilíbrio atingido (ou deveria mesmo assim) é a expectativa estabelecida para os desenvolvedores. Em todos os trabalhos que tive, os desenvolvedores tiveram acesso a tudo o que a expectativa era de que se limitassem. Acesse o sistema somente se você souber o que está fazendo. Isso significava que você sabia o que estava fazendo do ponto de vista do desenvolvedor e do administrador de sistemas. Se você não tinha certeza em nenhuma das áreas, não tinha como acessar os sistemas sem alguém que o fizesse para acompanhá-lo.

Para resumir, se você não sabe, não deve ter acesso a nenhum sistema que não seja um sistema de desenvolvimento facilmente reconstruível . Se você sabe, do que você sabe , não deveria acessar nenhum sistema, exceto seus sistemas de desenvolvimento facilmente reconstruíveis .


2

Os desenvolvedores devem ter acesso total aos bancos de dados dev (o ideal é que eles estejam executando um servidor local, mas isso nem sempre é possível). Eles devem ter acesso ao banco de dados de build / QA, mas apenas aos dados (devem ter permissão / enviar um ticket para alterar a estrutura). Os desenvolvedores nunca devem ter acesso casual ao banco de dados de produção (a menos que seja uma pequena empresa / projeto e os desenvolvedores também ofereçam suporte à produção).


1

Eu acho que a chave aqui é o nível de responsabilidade que os desenvolvedores têm. Em uma organização grande com muitos desenvolvedores, eles provavelmente terão acesso apenas ao desenvolvimento com acesso somente leitura ao controle de qualidade / teste.

No entanto, deve haver pessoas na equipe de desenvolvimento com acesso total a todos os ambientes. Geralmente é a pessoa responsável por fazer as correções etc. Embora isso seja um pouco arriscado, é uma troca entre o quanto você confia no desenvolvedor, a rapidez com que deseja que as coisas sejam consertadas e os riscos envolvidos na bagunça do sistema ou na divulgação de informações no sistema. .

Eu trabalhei em uma grande loja de TI e tínhamos acesso de leitura à produção para a maioria das pessoas. Eu, como desenvolvedor principal, também tinha permissões para o banco de dados de produção. Eu ainda tinha que seguir as mesmas diretrizes que os administradores de sistemas e os DBAs em termos de processo e documentação, mas também poderia fazer uma correção urgente, se necessário.


0

Há um problema relacionado que muitos de nós esquecemos - podemos não ser as únicas pessoas que usam o banco de dados! Nós tendemos a tomar isso como garantido, mas não devemos. Mesmo sites pequenos podem ter os executivos executando ferramentas de terceiros no banco de dados para seus relatórios. Os sites corporativos quase sempre têm vários usuários das tabelas do banco de dados e sua 'pequena' alteração pode interromper seus aplicativos e vice-versa.

Então essa tem que ser a primeira pergunta. A segunda deve ser a equipe disponível - trabalhei em sites que tinham administradores de sistema que protegiam seu território, mas que na verdade não eram tão bons. (É provavelmente por isso que eles eram tão territoriais - eles sabiam que pegariam muito calor se alguém olhasse em volta.) Às vezes, você precisa ter mais acesso do que gostaria.

Mas, em um mundo ideal, eu concordo com os argumentos de outras pessoas. Não quero acesso a dados ativos, pois, francamente, não quero a responsabilidade. Pense nisso - se eu tiver acesso operacional e houver uma violação, terei que gastar muito tempo provando que não tive nada a ver com isso. Talvez eu tenha que mostrar que não coletou os dados por motivos pessoais, etc. Muitos sites levam a privacidade muito a sério, especialmente. sites do governo.

Eu nem quero acesso de gravação / administrador ao sistema do grupo de teste. Se não posso fazer algo no sistema de produção, não quero poder fazê-lo nos sistemas de teste. O acesso de leitura é a exceção, pois é necessário ajudar a descobrir o que está acontecendo.

Os sistemas de desenvolvimento, individuais e departamentais, são uma história diferente. Mas mesmo aqui, na prática, geralmente é melhor executar todas as alterações no banco de dados através de uma pessoa pontual, em vez de fazer com que todos façam suas próprias coisas.


0

Eu concordo totalmente com toda a resposta, dizendo "o mínimo de privilégios possível para desenvolvedores em bancos de dados de produtos". Mas, para ser sincero, quem pode negar aos desenvolvedores o acesso ao banco de dados, se quiserem obtê-lo. Com vontade suficiente (seja criminosa ou para sempre), eles obterão o acesso necessário.

Quem pode impedi-los de colocar um editor SQL simples no aplicativo? Dessa forma, eles podem usar o banco de dados com os privilégios do aplicativo. Na maioria dos casos, isso é tudo o que é necessário. Quando o banco de dados é configurado com segurança, eles podem não ter o privilégio de criar ou excluir objetos, mas têm pelo menos acesso de leitura e gravação aos dados.

Eu já estou aqui as pessoas das operações choram. Mas seja honesto consigo mesmo, você não está no controle completo do aplicativo implantado na produção, a menos que você mesmo o escreva (e nem mesmo pense em bibliotecas). E para todos os desenvolvedores, como Erin já disse, você também é responsável pelo ambiente de produção, não apenas pelas pessoas das operações. Portanto, use seus privilégios com sabedoria.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.