Por que a administração de banco de dados é tão difícil?

Conheço muitos administradores de banco de dados e eles têm entre 28 e 29 anos.

Toda administração de banco de dados é assim? Quero dizer, é sobre obter experiência mais de pelo menos 7-8 anos?

Ou é ser um administrador de banco de dados tão difícil?

A posição requer um amplo espectro de conhecimento, que vai do desenvolvimento à administração do sistema e até ao 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 oferecer uma apresentação de alto nível ao gerenciamento, ajudando um desenvolvedor a ajustar uma consulta, provisionando espaço em disco para um novo sistema e restaurando dados do backup na mesma hora. Essas responsabilidades exigem uma riqueza de conhecimentos com pouca sobreposição.

As consequências da falha geralmente são 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 de longo alcance e devastadoras. Isso requer um nível de conhecimento e experiência que não podem ser obtidos em um curto período 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 terá reconhecimento. Os DBAs são notados quando há problemas. Além de serem notados quando seus problemas são autoinfligidos, eles também são culpados quando o banco de dados apresenta problemas devido à codificação incorreta, configuração incorreta da rede ou armazenamento incorreto.

Eu mudei de desenvolvedor para DBA aos 29 anos. Para mim, as coisas que dificultam ser um DBA também o tornam gratificante. Gosto de absorver e usar um amplo espectro de conhecimento, e a maior oportunidade para o fracasso torna a evitação ainda mais significativa, quer os outros vejam ou não.

Tornar-se um DBA realmente exige uma grande quantidade de experiência, mas pode vir basicamente de apenas quatro caminhos diferentes:

1. Ser desenvolvedor e fazer um segue para um DBA
2. Ser desenvolvedor e redigido como DBA
3. Treinamento direto da faculdade / escola comercial para se tornar um DBA
4. Ser um SysAdmin e fazer um segue para ou executar tarefas duplas como DBA

Ser desenvolvedor e fazer o segue para um DBA

Em outra pergunta que foi feita neste site: Como os DBAs poderiam ser mais 'amigáveis ​​ao programador' , mencionei que eu era desenvolvedor há 16 anos e trabalhava com DBAs. O trabalho 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 segundo plano me fez sentir que eu ainda estava na faculdade aprendendo com algum professor adjunto, mas que realmente sabia o que fazia. Desde que o DBA estivesse disposto a compartilhar o que sabia, sem dominar você , ele poderia se tornar seu mentor em termos de desenvolvimento de instruções SQL (o SQL é, por si só, uma Linguagem de Programação Sensível ao Contexto) que é tão eficiente quanto possível. Certamente, existem outras partes comuns, como executar 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 poderá se concentrar no desenvolvimento de aplicativos.

As demandas de um desenvolvedor podem ser exigentes, mas também o DBA. O desenvolvedor que voluntariamente faz a transição para o papel de um DBA muda o foco do desenvolvimento e da codificação para as coisas mundanas que mencionei antes. À luz disso, o DBA, trabalhando em estreita colaboração com os programadores, cria uma oportunidade para o DBA fazer contribuições criativas para qualquer projeto, tornando assim o papel de um DBA muito mais interessante.

Ser desenvolvedor e redigido como DBA

Para a maioria dos desenvolvedores que não vêem nada além de desenvolver e codificar pelo resto da vida, isso pode ser como escolher participar do reality show Survivor ou do game show Wipeout . O novo DBA gasta seu tempo interagindo com a 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 poderia parecer deixar um Hibachi japonês cozinhar em um restaurante italiano. O cozinheiro pode preparar qualquer coisa, mas deve perceber que há novas receitas, utensílios de cozinha, talheres, carnes, temperos, legumes e uma série de outras coisas mundanas a serem ajustadas (saneamento, inventário, 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.

Treinamento direto da faculdade / escola comercial para se tornar um DBA

Essa é, de longe, a maneira mais letal de se tornar um DBA. Esse também é o caminho mais raro - de fato, 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:

1. Aplicando habilidades da faculdade / escola comercial na função DBA,
2. Interagindo com o RDBMS específico (PostgreSQL, Oracle, MySQL, DB2, Sybase, Ingres) e,
3. Interagindo com os desenvolvedores ( um futuro DBA aprendendo habilidades sociais decentes logo depois da escola? Sim, certo! ).

Nisso, os desenvolvedores terão vantagem sobre os DBAs por anos. Os DBAs precisam aprender a se adaptar rapidamente às necessidades dos desenvolvedores nos primeiros anos como DBA. Talvez um DBA possa fazer um salário inicial decente, mas é mais difícil crescer sem se desenvolver nessas três áreas de aprendizado.

Ser um SysAdmin e fazer um seguimento para ou fazer um duplo dever como DBA

Como um desenvolvedor anterior e agora um DBA, uma coisa que não deve ser tomada 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 cheio de projetos de infraestrutura, além de seus próprios shows internos no MySQL. Eu não o invejo, eu o elogio. Honestamente, como a verdadeira mente de um SysAdmin / DBA é estranha para mim, deixo a critério dos SysAdmin / DBAs atualizar este parágrafo (ou substituí-lo completamente) para descrever esse caminho .

Conclusão

Independentemente de qual caminho você escolher, o papel de um DBA pode ser distinto ou nojento, dependendo de como você está disposto a ser orientado (ou torturado) no início e de como está disposto a trabalhar com outras horas extras. Só então podemos dizer que eles gostam de ser um DBA.

A propósito, aconteceu que eu experimentei os dois primeiros caminhos do DBA a partir de agosto de 2004 aos 39 anos. Os dois anos de experiência que tive no papel de DBA esboçado fizeram a transição para um DBA em tempo integral muito agradável e confortável .

Meu conselho aos DBAs de 28 a 29 anos? Seja tão bom em trabalhar com pessoas quanto com o RDBMS. Se você crescer em ambas as áreas, poderá torná-lo um DBA nos próximos anos.

A administração do banco de dados é difícil por dois motivos

Feedback lento Se alguém toma uma má decisão no papel de arquiteto de software, geralmente leva mais tempo para obter feedback negativo comparado a um programador. O programador pode frequentemente tomar conhecimento 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 que cometeu um erro ao projetar um banco de dados pode apenas 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 defeituoso 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 têm mais de 50 anos.

É muito fácil ser um DBA ruim

Sério, porém, um DBA geralmente tem responsabilidade especial por algo que geralmente é crítico para o sucesso ou fracasso de uma empresa: seus dados

Se você administra uma empresa, pode muito bem empregar pessoas competentes e experientes 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ê deve verificar suas somas muito mais para este último

Na minha opinião, ser um administrador de banco de dados é fácil ... até que algo quebre a empresa e o ônus de consertar e restaurar o que quer que seja esteja sobre seus ombros.

Ser administrador de banco de dados (ou administrador de rede ou sistema) é uma posição que requer um certo nível de maturidade. É preciso alguém que trabalhe bem sob pressão. Isso não quer dizer que não haja pessoas mais jovens por aí que possam lidar com isso com as habilidades necessárias.

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á inoperante.

Conheço muitos administradores de banco de dados e eles têm entre 28 e 29 anos. Toda administração de banco de dados é assim?

A maioria dos bons programadores sólidos que eu conheço também tem pelo menos 25 anos de idade. Eu imagino que haja um fator correlacionado à idade + experiência = bom codificador. ;)

Quero dizer, é sobre obter experiência mais de pelo menos 7-8 anos? Ou é ser um administrador de banco de dados tão difícil? O que você acha?

Ser 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, que quase ninguém frequenta a escola por tempo suficiente para aprender e, portanto, ninguém conhece. A lógica de conjunto compartilha algumas regras com a álgebra, mas os mecanismos (MSSQL, Oracle etc.) são eles mesmos bestas distorcidas da implementação dessas regras; portanto, você não apenas precisa entender a matemática por trás dos bancos de dados, mas também a implementação que deseja. correr em cima de. Isso nem conta saber a sua linguagem de script preferida (PL / SQL, TSQL, etc).

Em seguida, considere que, como dba, você será responsável por garantir que os dados comerciais mais críticos sejam confiados às suas mãos. Você precisa ter passado pelas piores partes de "cometer erros estúpidos" e precisa aprender um pouco de autocontrole. A maioria das pessoas entre 21 e 23 anos ainda não aprendeu isso. Alguns de nós, aos 30 anos, ainda não o fizeram.

OT: É por isso que digo que as pessoas realmente não sabem nada até que tenham pelo menos 40 anos e, então, são consideradas acima da colina, quando na realidade estão apenas alcançando seu ritmo. (disse como alguém que tem 31 anos)

Eu não acho que ser um DBA seja difícil. Tornar-se um foi embora.

Eu queria responder para adicionar outro aspecto que não foi bem discutido acima: campo de visão.

Existem diversas variedades de funções para desenvolvedores e algumas (por exemplo, desenvolvimento de driver de dispositivo ou desenvolvimento de agendadores de sistema operacional) exigem um campo de visão muito estreito e a capacidade de aprofundar-se 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 com tanta profundidade técnica (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, é necessário poder alternar entre esses modos de maneira rápida e fácil. Os bancos de dados são mecanismos matemáticos, mas são mecanismos matemáticos que se encaixam nos ambientes de negócios de maneiras muito complexas. Portanto, é preciso ser capaz de enfrentar o problema de matemática como um problema de matemática e também perguntar como ele se encaixa em todo o resto.

Quando você olha para engenheiros de rede ou administradores de sistema sênior, eles são os que mais se aproximam de um DBA sênior nessa área (embora cada campo seja bem diferente - um bom administrador de sistemas sênior exige um campo de visão ainda mais amplo 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, passando por matemática relacional e questões puramente técnicas de design, tudo sem qualquer transição real (e provavelmente no decorrer da avaliação de uma decisão específica).

Eu trabalho como DBA e desenvolvedor. Os dois papéis são extremamente complementares, mas eu sou um DBA primeiro e se você viu as bibliotecas que escrevi, isso seria óbvio. Mas a razão pela qual eles são complementares é que, no lado do desenvolvimento, interajo diretamente com os usuários finais do software e, por isso, sou constantemente pressionado em relação à amplitude da minha visão, enquanto no lado do banco de dados eu me desafio. na profundidade.

Existe outro caminho, um pouco diferente dos listados.

Comece como desenvolvedor, torne-se um designer de banco de dados e depois um DBA. Esse caminho foi mais prevalente há cerca de trinta anos, quando os bancos de dados começaram a ultrapassar aplicativos baseados em arquivos, e as pessoas com conhecimento em bancos de dados eram poucas e distantes entre si.

PS: Quando eu era um ex-programador que virou DBA, os programadores costumavam me perguntar "o DBA não é chato?"

Minha resposta: "só é chato quando você está fazendo certo!". :)

Estou bastante no início da minha jornada de DBA, mas aqui estão algumas das razões pelas quais as pessoas podem encontrar esse trabalho com dificuldade ... É difícil porque:

• você tem muitas responsabilidades: as pessoas podem entrar e sair de uma empresa, mas para algumas delas, o ativo mais importante são os dados. Você é responsável por isso e tem todos os poderes sobre ele. Como diz o ditado, com grandes potências vêm grandes responsabilidades. Erros muito caros estão à espreita.
• você precisa aprender e continuar aprendendo: eu vejo isso como um bônus, mas nem todas as pessoas estão dispostas a reservar um tempo para manter seus conhecimentos atualizados.
• pode ser demorado: as coisas vão quebrar no meio da noite, você estará pronto?
• muitas vezes você precisará corrigir os erros de outras pessoas: e geralmente não receberá muito crédito por todo o seu bom trabalho. Não tenha medo de aprimorar as habilidades de seu pessoal.

Brad Mc Gehee escreveu um livro sobre o assunto, "Como se tornar um DBA excepcional". Vale a pena ler se você pretende aprofundar a questão.

Boa sorte!

Tornei-me dba aos 25 anos. Demorei 6 meses a partir do momento em que comecei a estudar para obter a certificação e 2 meses depois eu tinha um emprego. Eu acho que a determinação definitivamente desempenha um papel importante. Para mim, não foi difícil conseguir o emprego. Só foi preciso força de vontade para estudar e mostrar que eu era capaz de aprender o que sempre é colocado na minha frente.

Eu direi que tudo que eu tinha era um diploma de psicologia e um histórico de suporte técnico. Quando recebi meu trabalho como DBA do Oracle Apps, pensei imediatamente em OMG, todas as coisas que estudei para me tornar um DBA CORE não me ajudaram nem um pouco. Lembro-me de me sentir extremamente sobrecarregado. Eu tinha que me lembrar diariamente que posso aprender isso e, dois anos depois, adquiri muito mais conhecimento.

O que estou dizendo é que ser um DBA não é difícil, nem um pouco difícil, mas aprender tudo no trabalho e fora do trabalho, que deveríamos saber como os dba anteriores mencionaram antes, é demorado e exige muita diligência. Descobri que na maioria das pessoas de 27 anos de idade ou menos não tenho a diligência nem o desejo de querer aprender um espectro tão grande de tecnologias. Mas eu amo meu trabalho como um DBA do Oracle Apps e aguardo com expectativa todo o resto que sempre será lançado para aprender. Você pode fazê-lo, se você se dedicar a isso, não importa a sua idade!

Ser um DBA também significa que você é proativo em vez de reativo. Você precisa imaginar o que o futuro reserva e planejar adequadamente. Isso envolve trabalhar duro ... uma vez, muitas e muitas vezes, e se você fizer certo, a recompensa é uma completa falta de reconhecimento de nome. :-) Você também deve ter a capacidade de dizer "não" às pessoas (incluindo os chefes) e comunicar de maneira objetiva e eficaz suas razões pelas quais seu público pode entender. Você precisa ser prudente e tomar decisões racionais em situações de alta pressão. Você deve ser capaz de controlar seus erros rapidamente e não deixá-los exibir a tela azul, mas alternar efetivamente de "Não acredito que acabei de fazer isso" para "Ok, qual é a melhor maneira de corrigir isso".

Como alguém que se considera primariamente um SysAdmin e, em segundo lugar, um DBA acidental, acho que parte disso se resume à quantidade de conhecimento necessária para você ficar sozinho e fazer o trabalho, ou talvez o mais importante, para entendê-lo.

A antiga certificação MCDBA resume muito bem, eu acho. Exigia a aprovação de quatro exames, um exame SysAdmin, um exame de infraestrutura de rede, um exame de desenvolvimento de banco de dados e um exame de administração SQL. Essa é uma gama bastante ampla de tópicos; portanto, de maneira realista, é provável que você encontre um deles primeiro. Eu argumentaria que grande parte da administração do SQL está nos ombros dos outros três, então a maioria das pessoas o acessa através de uma dessas rotas inicialmente. Por exemplo, um SysAdmin manipulando os backups do SQL (minha primeira incursão no SQL há muitos anos) ou um desenvolvedor projetando o banco de dados para o código que eles estão escrevendo. No começo, você não saberá tudo, mas terá a base de pelo menos parte dele, por exemplo, os sistemas em que o SQL roda e como as permissões funcionam, ou os métodos de programação usados ​​para conversar com o banco de dados,

É difícil julgar se ser um DBA é realmente o que você quer fazer até fazê-lo, mas pela rota acima as pessoas são capazes de se desenvolver gradualmente. Você pode amá-lo e torná-lo o foco da sua carreira, ou descobrir que não é para você e seguir seu caminho de carreira anterior, tudo sem dar um salto gigantesco no desconhecido. Mas isso leva tempo e se encaixa na tendência dos DBA de serem "mais sábios em anos" na indústria.

Para ser um bom DBA, você também precisa da confiança e maturidade que costuma vir com a idade. Outros listaram outros aspectos disso, mas eu acrescentaria ter a confiança necessária para dizer não e defender sua posição, temperado com a experiência para saber quando é apropriado.

Finalmente, acho que ser um bom DBA requer uma certa mentalidade, e é difícil saber se você tem isso até estar nas trincheiras. Ter atenção aos detalhes, disposição para planejar com antecedência, capacidade de olhar para o cenário geral e não ter medo de documentar seu trabalho são aspectos importantes da manutenção de um sistema estável. Alguns SysAdmins e Desenvolvedores são assim, e podem facilmente fazer a transição, enquanto outros podem achar que, embora sua abordagem tenha valor em seu trabalho atual, como DBA eles se esforçam e acham essas coisas uma tarefa árdua e não gostam do trabalho.

Eu acho que a parte mais difícil de pelo menos se tornar um administrador de banco de dados bastante involuntário é o fato de que você precisa suportar o que acontece com os bancos de dados da organização específica em que você se deparou.

Na minha experiência, meu primeiro choque ocorreu em uma manhã de segunda-feira, quando o servidor do banco de dados travou por causa de um erro aparentemente de hardware, mas ainda assim eu era suspeito de ter feito algo errado.

Você pode imaginar que tudo o que alguém já aprendeu ou exercitou em sua vida deve ser aplicado para fazer com que tudo funcione novamente. Então, é claro, você pode criar um clone e até backups rápidos de tudo - estamos falando aqui apenas de um pequeno servidor de banco de dados que direciona as coisas para outras redes de computadores através de servidores de link. Ainda assim, a responsabilidade parece tremenda durante esses momentos.

Como desenvolvedor de software ou como testador de software, a responsabilidade também é grande, mas nunca tive momentos tão difíceis. Posso imaginar que a razão reside no fato de que cada um deles tece apenas um pouquinho da teia de aranha do mundo da tecnologia da informação.

Se eu me tornar um administrador de banco de dados, atualizarei o que escrevi agora aqui.

E, sim, agora tenho 38 anos e meio.

Como a maioria das habilidades, aprender a ser um dba leva tempo. Tornar-se um bom dba leva mais tempo. Quanto mais você lê e aprende, mais conhecimento pode aplicar.

Outro caminho para se tornar um dba é a elaboração de relatórios ou como especialista em aplicativos. Quanto mais tempo você gasta com as mãos no SQL, mais você aprenderá sobre como os dbs funcionam. Tornar-se proficiente em consultas SQL fornecerá um bom ponto de partida para se tornar um dba.