Conheço muitos administradores de banco de dados e todos têm mais de 28-29 anos.
Toda administração de banco de dados é assim? Quero dizer, isso é sobre ganhar experiência por mais de 7-8 anos?
Ou ser um administrador de banco de dados é tão difícil?
A posição exige um amplo espectro de conhecimentos que vão desde o desenvolvimento até a administração do sistema e até mesmo o gerenciamento. Um DBA não deve apenas saber sobre backup, recuperação, operações internas, memória e segurança, mas também como se comunicar com desenvolvedores e gerenciamento. Um DBA pode estar fazendo uma apresentação de alto nível para o gerenciamento, ajudando um desenvolvedor a ajustar uma consulta, provisionando espaço em disco para um novo sistema e restaurando dados de backup na mesma hora. Essas responsabilidades exigem uma riqueza de conhecimento com pouca sobreposição.
As consequências da falha são geralmente maiores para um DBA do que para um desenvolvedor. Os DBAs geralmente oferecem suporte a dezenas, até centenas de aplicativos e sistemas diferentes, a maioria dos quais é vital para o sucesso da empresa. Uma violação de segurança, falha de recuperação ou problema de desempenho pode ter ramificações devastadoras e de longo alcance. Isso requer um nível de conhecimento e experiência que não pode ser adquirido em um curto espaço de tempo.
Quanto melhor um DBA fizer seu trabalho, menos visibilidade terá. Um DBA com um banco de dados seguro, recuperável, disponível e com bom desempenho não será reconhecido. DBAs são notados quando há problemas. Eles não apenas são notados quando seus problemas são auto-infligidos, mas também são responsabilizados quando o banco de dados apresenta problemas devido a codificação inadequada, configuração de rede inadequada ou armazenamento configurado incorretamente.
Mudei de desenvolvedor para DBA quando tinha 29 anos. Para mim, as coisas que tornam difícil ser um DBA também o tornam recompensador. Gosto de absorver e usar um amplo espectro de conhecimento, e a maior oportunidade para o fracasso torna a evitá-lo ainda mais significativa, quer os outros vejam isso ou não.
Tornar-se um DBA na verdade exige uma grande quantidade de experiência, mas basicamente pode vir de apenas quatro caminhos diferentes:
Ser um desenvolvedor e fazer a transição para um DBA
Em outra pergunta que foi feita neste site, Como os DBAs poderiam ser mais 'programáveis' , mencionei que fui desenvolvedor por 16 anos que trabalhei com DBAs. Ter trabalhado com eles me fez perceber que, na medida em que sua experiência incluía teoria de banco de dados, matemática discreta e experiência em programação, eles podiam ver como um banco de dados deveria funcionar e como uma consulta deveria ser executada.
Ter um DBA com essas coisas em seu passado me fez sentir que ainda estava na faculdade aprendendo com algum professor adjunto, mas que realmente conhecia suas coisas. Contanto que o DBA estivesse disposto a compartilhar o que eles sabiam, sem se impor sobre você , eles poderiam realmente se tornar seu mentor em termos de desenvolvimento de instruções SQL (o SQL é, em si, uma linguagem de programação sensível ao contexto) que são tão eficientes quanto possível. Claro, existem outras partes mundanas, como realizar instalações, fazer backups, fazer atualizações de software, monitorar métricas de desempenho, gerar relatórios e assim por diante. Mas, como desenvolvedor, se você se concentrar nos bancos de dados e no SQL que é executado nesses bancos de dados, com o tempo você se tornará tão adepto do SQL que será uma segunda natureza e você poderá se concentrar no desenvolvimento de aplicativos.
As demandas de um desenvolvedor podem ser desgastantes, mas o DBA também pode. O desenvolvedor que voluntariamente faz a transição para a função de DBA muda o foco do desenvolvimento e codificação para as coisas mundanas que mencionei antes. À luz disso, o DBA trabalhando em estreita colaboração com os programadores cria a oportunidade para o DBA fazer contribuições criativas para qualquer projeto, tornando o papel de um DBA muito mais interessante.
Ser um desenvolvedor e ser elaborado como um DBA
Para a maioria dos desenvolvedores que não veem nada além de desenvolver e codificar para o resto de sua vida, isso pode ser como escolher estar no reality show Survivor ou no game show Wipeout . O novo DBA passa seu tempo interagindo com aquela Black Box (conhecida por todos nós simplesmente como o banco de dados) que eles contataram para obter dados ao longo dos anos.
O novo DBA agora pode criar suas próprias tabelas e índices. Isso pode se assemelhar a deixar um Hibachi japonês cozinhar em um restaurante italiano. O cozinheiro pode preparar qualquer coisa, mas deve perceber que existem novas receitas, utensílios de cozinha, talheres, carnes, temperos, legumes e muitas outras coisas mundanas para se ajustar (saneamento, estoque, horário de início, horário de trabalho, etc). Este não é apenas um momento de transição, mas também um momento para superar uma grande curva de aprendizado. Um novo nível de experiência deve ser aprendido e desenvolvido, apesar da culinária japonesa especializada ao longo dos anos. Nesse aspecto, os Desenvolvedores devem se reeducar para pensar como um DBA.
Treinando direto da faculdade/escola profissional para se tornar um DBA
Esta é, de longe, a maneira mais letal de se tornar um DBA. Este também é o caminho mais raro - na verdade, isso é praticamente inédito. Agora estamos falando de deixar alguém do McDonald's ou Burger King entrar no mesmo restaurante italiano.
Três curvas de aprendizado estão envolvidas:
Nisso, os desenvolvedores terão vantagem sobre os DBAs por anos. Os DBAs devem aprender a se ajustar rapidamente às necessidades dos desenvolvedores em seus primeiros anos como DBA. Talvez um DBA possa ganhar um salário inicial decente, mas é mais difícil crescer sem se desenvolver nessas três áreas de aprendizado.
Ser um SysAdmin e fazer uma transição ou fazer dupla função como DBA
Como um ex-desenvolvedor e agora um DBA, uma coisa que não deve ser dada como certa é o papel do SysAdmin.
Ter o papel de SysAdmin/DBA é um pouco inspirador para mim. Na empresa de hospedagem do meu empregador, temos um cara que é SysAdmin/DBA (SCMDBA). Ele está tão sobrecarregado com projetos de infraestrutura, além de seus próprios shows internos no MySQL. Eu não o invejo, eu o elogio. Sinceramente, como a verdadeira mente de um SysAdmin/DBA é estranha para mim, deixo a critério do SysAdmin/DBAs atualizar este parágrafo (ou substituí-lo completamente) para descrever este caminho .
Conclusão
Independentemente do caminho que você escolher, o papel de um DBA pode ser distinto ou repugnante, dependendo de como você está disposto a ser orientado (ou torturado) no início e de quão disposto você está para trabalhar com outras pessoas ao longo do tempo. Só assim se pode dizer que gosta de ser DBA.
A propósito, acontece que experimentei os dois primeiros caminhos de DBA a partir de agosto de 2004, aos 39 anos. Os dois anos de experiência que tive na função de DBA redigido tornaram a transição para um DBA em tempo integral muito agradável e confortável .
Meu conselho para DBAs de 28 a 29 anos? Seja tão bom em trabalhar com pessoas quanto você é com o RDBMS. Se você crescer em ambas as áreas, poderá se tornar um DBA nos próximos anos.
A administração de banco de dados é difícil por dois motivos
Feedback lento Se alguém toma uma decisão ruim no papel de arquiteto de software, geralmente leva mais tempo para obter feedback negativo em comparação com um programador. O programador muitas vezes pode ficar ciente do erro durante a compilação ou durante a execução de testes, o que significa que o ciclo de aprendizado é bastante rápido. Um administrador de banco de dados cometendo um erro ao projetar um banco de dados pode obter feedback quando descobrir como os usuários finais realmente usarão o software. Isso significa que pode levar anos para obter o feedback de que o design do banco de dados foi falho e precisa ser refeito. Portanto, leva anos para ganhar experiência, em vez de minutos (às vezes) para programadores.
Erros caros Essa também é a razão pela qual os CEOs de grandes empresas geralmente estão na faixa dos 50 anos.
É muito fácil ser um mau DBA
Falando sério, um DBA geralmente tem responsabilidade especial por algo que muitas vezes é crítico para o sucesso ou fracasso de um negócio: seus dados
Se você administra uma empresa, pode estar interessado em empregar pessoas experientes e competentes nessa função
Não acho que seja uma questão de 'mais fácil' ou 'mais difícil' - apenas uma questão de quão valiosos são seus dados: não é inerentemente mais difícil colocar um satélite no espaço do que uma pessoa, mas você verificaria suas somas muito mais para este último
Na minha opinião, ser um administrador de banco de dados é fácil... até que algo quebre que ameace a empresa e o ônus de consertar e restaurar o que quer que seja está em seus ombros.
Ser Administrador de Banco de Dados (ou Administrador de Rede ou Sistema) é um cargo que exige um certo nível de maturidade. É preciso alguém que trabalha bem sob pressão. Isso não quer dizer que não existam pessoas mais jovens por aí que possam lidar com isso com o conjunto de habilidades necessário.
Além disso, é fácil aprender os comandos de um livro para fazer backup/restaurar um banco de dados, otimizar a configuração do servidor, etc. Mas a experiência ganha quando você recebe o alerta de que seu banco de dados está inativo.
A maioria dos bons e sólidos programadores que conheço também tem pelo menos 25 anos de idade. Imagino que exista um fator correlacionando a idade + experiência = bom codificador. ;)
Ser um administrador de banco de dados não é fácil, se é isso que você quer dizer. Há muitas coisas que você deve saber como dba. Isso também significa escola, e significa alguns anos de tutela sob outra pessoa. Lembre-se de que os bancos de dados são lógicos de conjunto, que quase ninguém vai à escola tempo suficiente para aprender, que, portanto, ninguém conhece. O set-logic compartilha algumas regras com a álgebra, mas os mecanismos (MSSQL, Oracle, etc.) correr em cima. Isso nem conta saber sua linguagem de script preferida (PL/SQL, TSQL, etc).
Em seguida, considere que, como dba, você será responsável por garantir que os dados de negócios mais críticos sejam frequentemente confiados às suas mãos. Você precisa ter superado as piores partes de "comete erros idiotas" e precisa ter aprendido um pouco de autocontrole. A maioria das pessoas de 21 a 23 anos ainda não aprendeu isso. Alguns de nós com 30 anos ainda não.
OT: É por isso que eu digo que as pessoas realmente não sabem nada até que tenham pelo menos 40 anos, e então eles são considerados ultrapassados, quando na verdade eles estão apenas alcançando seu passo. (disse como alguém que tem 31 anos)
Eu não acho que ser um DBA é difícil. Tornar-se um foi embora.
Eu queria responder para acrescentar outro aspecto não bem discutido acima: campo de visão.
Há uma grande variedade de funções para desenvolvedores e algumas (por exemplo, desenvolvimento de driver de dispositivo ou desenvolvimento de programadores de sistema operacional) exigem um campo de visão muito estreito e a capacidade de se aprofundar em um pequeno problema e analisá-lo de um ponto de vista puramente técnico . Existem outros campos que exigem campos de visão muito amplos, mas não tanto aprofundamento técnico (desenvolvimento de aplicativos de negócios com uma estrutura de ERP de sua escolha).
Os bancos de dados são únicos porque, para fazê-los bem, você precisa ser capaz de alternar entre esses modos de maneira rápida e transparente. Bancos de dados são mecanismos matemáticos, mas são mecanismos matemáticos que se encaixam em ambientes de negócios de maneiras muito complexas. Portanto, é preciso ser capaz de abordar o problema matemático como um problema matemático e também perguntar como ele se encaixa em todo o resto.
Quando você olha para engenheiros de rede sênior ou administradores de sistema sênior, eles são a correspondência mais próxima de um DBA sênior nesta área (embora cada campo seja bem diferente - um bom administrador de sistema sênior requer um campo de visão ainda mais amplo do que um bom dba, e bons engenheiros de rede exigem um campo mais profundo).
Em outras palavras, para ser um bom DBA, você precisa ser capaz de alternar entre requisitos de negócios de alto nível e entendimentos de nível muito baixo relacionados ao armazenamento em disco real e até matemática relacional e questões puramente técnicas de design, tudo sem qualquer transição real (e provavelmente durante a avaliação de uma decisão específica).
Atuo como DBA e desenvolvedor. As duas funções são extremamente complementares, mas eu sou um DBA primeiro e se você visse as bibliotecas que escrevi, isso seria óbvio. Mas a razão pela qual eles são complementares é que, no lado do desenvolvimento, eu consigo interagir diretamente com os usuários finais do software e, portanto, sou constantemente pressionado em relação à intensidade da minha visão, enquanto no lado do banco de dados eu posso me desafiar na profundidade.
Existe outro caminho, um pouco diferente dos listados.
Comece como um desenvolvedor, depois torne-se um designer de banco de dados e, em seguida, torne-se um DBA. Esse caminho era mais prevalente cerca de trinta anos atrás, quando os bancos de dados começaram a ultrapassar os aplicativos baseados em arquivos em grande momento, e as pessoas com experiência em banco de dados eram poucas e distantes entre si.
PS: Quando eu era um ex-programador transformado em DBA, os programadores costumavam me perguntar "o trabalho de DBA não é chato?"
Minha resposta: "só é chato quando você está fazendo certo!". :)
Estou no início da minha jornada de DBA, mas aqui estão algumas das razões pelas quais as pessoas podem achar esse trabalho difícil... É difícil porque:
Brad Mc Gehee escreveu um livro sobre isso, "Como se tornar um DBA excepcional". Vale a leitura se você pretende aprofundar a questão.
Boa sorte!