Olá a todos!
Hoje quero falar um pouco sobre algo que li
recentemente em um artigo publicado em 2007 e achei bastante interessante. O
artigo fala sobre alguns documentos que um DBA deve lidar. Esses documentos são
úteis para organizar e gerenciar atividades do DBA, além do mais, um documento
também serve de registro técnico sobre algo.
Bom...
Para começar queria deixar claro uma coisa...
documentar é um trabalho muito chato!! Hehehe
Brincadeiras a parte, a documentação é algo de
extrema importância, e temos que ter sempre em mente que criar ou atualizar um
documento não é apenas um trabalho desnecessário que consome tempo e torna uma
demanda mais lenta. Documentação é um item necessário e obrigatório em qualquer
projeto, servindo a vários propósitos. As
metodologias estão aí para isso, e logicamente, devido à maturidade dos
processos, agregam muito valor ao serviço.
É bastante normal na T.I. (vou corrigir isso, pois
normal não é!!)... É bastante frequente na T.I. encontrar profissionais que não
gostam de documentar, seja esse documento de qualquer natureza. Talvez seja uma
cultura que trazemos da escola ou faculdade, mas que devemos mudar!
Li certa vez (não me recordo onde), que em termos
de documentação nos serviços de T.I., as mulheres são muito mais comprometidas
e responsáveis que os homens. E levando em consideração minha experiência
profissional, eu concordo plenamente com isso! Não podemos generalizar, mas em
uma visão superficial pode-se notar que mulheres são mais organizadas e dedicadas
em trabalhos de documentação (obviamente existem exceções).
Segundo Pichiliani, “em geral, é difícil encontrar
profissionais, em particular DBAs, que trabalhem com muita documentação. Isso
se deve tanto à questão cultural como a questão que envolve a disponibilidade
de tempo para criar e manter a documentação atualizada.”
A seguir é apresentada uma lista de documentos
elencadas por Pichiliani, úteis tanto para quem trabalha tanto como DBA como analista
ou desenvolvedor.
1) MER (Modelo Entidade Relacionamento)
O MER, chamado também de modelo de dados ou
diagrama de entidade-relacionamento, é a principal documentação de um banco de
dados. Nesse documento deve constar
todas as entidades (com seus atributos, tipos de dados e restrições) do banco e
seus relacionamentos. O MER pode ser de três tipos: conceitual, lógico e
físico, e cada um desses têm uma particularidade. Não entrarei no detalhe, mas
recomendo a leitura do artigo de Adail Faleiro, que aborda de forma objetiva o
assunto.
2) Documento de Padrões de Variáveis
Utilizar nomes de fácil entendimento em classes,
métodos, atributos, etc, é cada vez mais frequente como pré-requisito para quem
trabalha com desenvolvimento. Sendo assim, utilizar padrões é sempre uma boa
prática de desenvolvimento. Com foco em banco de dados, possuir um padrão de
nomes para tabelas, colunas, restrições,
procedimentos, funções e demais objetos de dados é muito importante. Segundo Pichiliani,
a idéia é possuir um padrão eficaz que seja fácil de ser utilizado, além de fazer
sentido no contexto de banco de dados. Para formalizar a adoção do padrão, Pichiliani
recomenda criar um documento explicando os detalhes deste padrão tais como: se
os nomes devem ser em português, se as palavras devem estar no plural ou se há
um limite no tamanho da coluna.
3) Plano de Capacidade
Fiz um post recentemente sobre as tarefas de um DBA, e das atividades
que cito (conforme orientação da própria Oracle) é a de “avaliar o hardware do
servidor de banco de dados”, e de acordo com Pichiliani, além de economizar
recursos, dimensionar os recursos necessários mostra que existe um controle não
apenas para o ambiente atual, mas também para os recursos que podem ser
necessários no futuro. Para que esse dimensionamento seja registrado (podendo
evitar possíveis problemas), o DBA deve elaborar um documento de Plano de
Capacidade. Neste documento, informações sobre espaço de armazenamento e
crescimento médio dos ambientes, utilização de CPU, utilização de memória e
outros requisitos técnicos; devem estar contidos para exibir o funcionamento do
servidor atual e até embasar aquisição de novos recursos (hardware ou
software).
4) Dicionário de dados
O dicionário de dados é um documento onde deve
constar uma coleção de metadados que contém definições e representações de
elementos de dados. Ele pode ser considerado um documento complementar ao MER.
No documento deve conter algumas das seguintes informações definição sobre os
objetos, perfis de usuários, papéis e privilégios, restrições de integridade, valores
possíveis para um campo, quantidade típica de valores armazenados, etc. Vale
lembrar que este documento deve sempre estar atualizado com a base de dados
atual, para evitar desgastes e problemas.
5) Política de segurança
De acordo com Pichiliani, um documento que informa
a política de segurança é um objeto não necessariamente técnico que envolve os
procedimentos, responsabilidades e atribuições relacionadas à segurança das
informações e disponibilização delas. Geralmente documentos dessa natureza
contêm regras de usuários e senhas, tais como: nível de dificuldade da senha,
atualização periódica dela, bloquei após repetidas tentativas mal sucedidas.
6) Acordo de
nível de serviço (ANS) ou SLA (Service Level Agreement)
O SLA é um acordo firmado entre a área de T.I. e
seu cliente, que descreve o serviço, suas metas de nível de serviço, além dos
papéis e responsabilidades das partes envolvidas no acordo. Este acordo deve
deixar claro quais serviços estão sendo oferecidos (serviços específicos) e o
nível de cada serviço (horas de funcionamento, downtime, horário do
suporte, etc). Segundo Pichiliani, e com foco em banco de dados, pode-se
utilizar um SLA interno, onde o DBA se compromete a dar algum tipo de retorno (feedback)
ao solicitante, nem que seja apenas a informação de que está ciente da solicitação (mesmo que ainda não tenha uma
solução para a situação). Acordo de nível de serviço é algo que está muito em
alta no mercado de T.I., por isso sugiro a leitura da biblioteca ITIL V3.
7) Diagrama de arquitetura
Geralmente as organizações possuem diversos
ambientes de banco de dados, que podem ser separados de acordo com sua
utilidade, como por exemplo:
- ambiente
de desenvolvimento – banco utilizado por desenvolvedores e analistas de
sistemas para criação de aplicativos;
- ambiente
de homologação – banco utilizado para realização de validações de usuários
antes de implantação de um aplicativo;
- ambiente
de produção – onde os usuários finais trabalham com os dados reais dos
sistemas.
O DBA deve elaborar um diagrama de arquitetura para
facilitar o gerenciamento desses ambientes, onde deverá apresentar de forma
gráfica, quais servidores pertencem ao ambiente de desenvolvimento, homologação
e produção. Este tipo de diagrama contém informações relacionadas à estrutura
arquitetural dos ambientes e é extremamente útil para quem não conhece a
organização física e lógica dos componentes da rede e dos servidores.
8) Estratégia de Backup
Mais uma das tarefas de todo DBA que postei num
artigo passado é a de “Realizar
backup, restaurar e recuperar o banco de dados”. Todo DBA deve possuir uma
estratégia de backup adequada que deve ser criada de acordo com as necessidades
de recuperação e disponibilidade do sistema, ou seja, vai depender do quanto
de downtime e tempo de recuperação é aceitável de acordado com
os SLA’s. Esse tipo de documentação é importante para registro oficial sobre o
que pode ser recuperado e em quais circunstâncias.
É isso aí, pessoal...
Obviamente existem vários outros documentos importantes para um
DBA, mais esses são alguns dos mais interessantes, e que todo DBA deve manter.
Espero ter ajudado!
Até a próxima.
Referências:
Pichiliani, Mauro - Documentação do DBA – 11/06/2007.
Disponível em: http://imasters.com.br/artigo/6392/sql-server/documentacao-do-dba/
. Acessado em: 18/04/2013
Faleiro, Adail Tiago Lima - Modelo Entidade
Relacionamento (MER). Disponível em:
http://www.devmedia.com.br/modelo-entidade-relacionamento-mer/19821. Acessado
em: 19/04/2013.
