Reconheço que a experiência e as habilidades de cada um são diferentes. Dito isso, quero evitar criar expectativas muito altas (ou muito baixas) para um DBA que por meio de ações; parece ser um 'administrador'.
Dado:
- Sou um desenvolvedor que está se aprofundando na solução de problemas e problemas de desempenho do SQL Server. À noite estou assistindo a vídeos de Brent Ozar com um balde de pipoca.
- Uma empresa com várias divisões, esta divisão com cerca de 100 membros da equipe
- Muitos clientes com bancos de dados com milhões de linhas com ETL
- Uma pequena equipe de DBA que é esticada para lidar com esses mesmos clientes. Lide com problemas de HAG, backup, restaurações, crie novas implantações para clientes novos ou atualizados.
NÃO estou tentando justificar minha própria opinião. Desejo ajustar minha opinião ou de outras pessoas na empresa.
Pergunta:
Diante do exposto, deve-se esperar que um DBA seja simplesmente um 'administrador'? Isso é algo que você normalmente já viu?
Entrei nesta novela (veja minhas outras perguntas recentes) com a expectativa de que um DBA seja 'esperado' para mergulhar fundo. Cheguei a acreditar que entendi mal e estou inclinado para um DBA - ser um 'administrador'.
Congratulo-me com as experiências de outros e talvez conselhos para refinar esta questão.
Os títulos são apenas isso, nada mais do que um conjunto de palavras, e a relevância de seu significado depende de como você define esse significado no contexto do seu domínio. Nesse caso, esse domínio é a sua empresa, então vocês devem definir o papel do DBA para atender às necessidades do negócio (realisticamente sob o guarda-chuva do que um DBA pode fazer).
DBA é um desses tipos de papéis que eu descobri que evoluem como muitos chapéus ou tipo de posição cruzada. O raciocínio é que é uma carreira fortemente povoada por uma mistura de pessoas que foram Desenvolvedores de Software, Administradores de Sistemas ou nenhum dos dois, em uma vida passada.
Como alguém que passou de desenvolvedor de software para DBA residente para DBA real em outra empresa e de volta a um quase desenvolvedor de software / DBA agora, pude experimentar a maior parte do desenvolvimento de banco de dados e do lado de ajuste de desempenho de ser um DBA, em oposição ao servidor e gerenciamento de banco de dados - embora eu tenha e ainda gerencie alguns desses aspectos também. Isso ocorreu devido à minha experiência anterior como desenvolvedor e porque as empresas para as quais trabalhei precisavam de alguém que pudesse escrever código, mas também ajudar a otimizar o desempenho na camada de banco de dados, tanto do ponto de vista arquitetônico quanto de ajuste de consulta.
Então, em resumo, há um arco-íris de funções de DBA por aí entre aqueles que essencialmente apenas administram sistemas de banco de dados e sujam as mãos sob o capô dos próprios servidores, outros que fazem puramente design de banco de dados e ajuste de desempenho e outros que têm uma mistura das responsabilidades reais de desenvolvimento de software (mesmo fora da camada de banco de dados) e fazer ajuste de desempenho e gerenciamento de banco de dados.
Penso que a figura do DBA deve ser considerada primordialmente como administrador da instância e responsável pelo seu bom funcionamento, armazenamento de dados, eficiência e disponibilidade das bases de dados, mas também por verificar a boa execução dos procedimentos e processos de forma a garantir um uso equilibrado dos recursos.
Na minha experiência ele deve ser visto pelos programadores como um aliado que deve ser consultado e envolvido desde as primeiras etapas do projeto. Seu ponto de vista é valioso e diferente do de um programador. Um programador tem seu aplicativo no coração, um dba todo o ecossistema de aplicativos que depende da instância.
Seu relacionamento deve ser sinérgico, não conflitante.
Se você se deparar com problemas rasos, não precisará fazer mergulhos profundos.
Se você se deparar com problemas complexos, mas não tiver experiência suficiente, não poderá fazer mergulhos profundos. Outros os dominarão, pois os problemas complexos são escassos e as pessoas inteligentes os procuram.
Se você for o único DBA e os outros não tiverem experiência suficiente (eles vão delegar trabalho para bancos de dados sem pensar no que estão fazendo), você terá que mergulhar fundo. Este é o caso em um ambiente típico de desenvolvimento web. Você deve fazer esses mergulhos profundos, mesmo que alguém diga que você deve ou não deve.
Esses ambientes complexos de computação e desenvolvimento têm muitas partes interessadas. Se sua organização atingiu alguns níveis de maturidade, você terá desenvolvedores/arquitetos corporativos, bem como desenvolvedores/arquitetos de banco de dados no local. Em ambientes colaborativos autocríticos, os desenvolvedores corporativos estão cientes de que sua arte de resolver problemas é útil, mas têm pontos cegos. Os desenvolvedores de dados fazem coisas úteis também têm pontos cegos e esperam que esses pontos cegos não sejam os mesmos dos desenvolvedores corporativos. O mergulho profundo ajudará a expandir ainda mais as fronteiras.
Respostas originalmente deixadas como comentários:
Como DBA, faço muito mais do que administrar. Certifico-me de que as coisas funcionam melhor do que bem e garanto que os desenvolvedores não estão tentando contornar as regras envolvidas ao interagir com os sistemas. Meu trabalho é proteger os dados de ameaças externas e internas, sejam elas malévolas ou não. Eu ensino as pessoas sobre o sistema. Eu respondo novas perguntas do negócio. Essas respostas – espero – resultam em melhores decisões. “Qualquer um” pode administrar um banco de dados, mas nem todos podem gerenciar um. - matigo
Vai variar de empresa para empresa. Brent Ozar tem um gráfico rápido sobre isso, mas quanto maior/mais antiga a empresa, mais pequenas são as responsabilidades na minha experiência. As startups menores se apoiarão mais em um engenheiro de dados híbrido ou engenheiros de confiabilidade do site para tarefas clássicas de DBA + automação + ajuste + escrita de código. -lowlydba-john- m
O DBA não é necessariamente um 'administrador'
O que você está se referindo é um
Production DBAMas também há
Development DBAquem foca no ajuste de desempenho e na escrita de consultas.Aqui você pode ler mais (este é um link além do lowlydba, confira também)
https://www.brentozar.com/sql/picking-a-dba-career-path/
Se os DBAs da sua empresa devem ou não 'mergulhar profundamente' nos problemas de desempenho de consulta em tempo de execução, acho que depende das respostas às perguntas "para que eles foram contratados?" e "qual é a descrição do trabalho deles?"
Se a descrição do trabalho de uma determinada pessoa não diz estritamente
Production DBA(e as únicas funções que ela espera executar são backups, HAG, manter as luzes nos servidores, automatizar etc.), então o 'mergulho profundo' não é apenas esperado, mas você tem o direito de exigi-lo. Um bom DBA não ficará esperando que alguém exija algo, mas sim corrigindo problemas de forma proativa e antecipada, embora