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.