Estes documentos são úteis não apenas para ajudar a documentar aspectos técnicos, mas também para organizar e gerenciar o trabalho do DBA (Database Administrator).
Ao contrário do que alguns podem pensar, a documentação não é apenas um trabalho desnecessário que toma tempo e torna tudo mais lento. Ela é um item necessário e obrigatório em qualquer projeto, servindo a vários propósitos.
Em geral, é difícil encontrar profissionais,
1) MER (Modelo Entidade Relacionamento)
O MER (Modelo Entidade Relacionamento), também conhecido apenas como modelo de dados ou diagrama de entidade-relacionamento, é a principal documentação de um banco de dados. Neste diagrama são relacionadas as principais entidades (tabelas) e seus relacionamentos, além de alguns detalhes a respeito das entidades, como nome das colunas nas tabelas, tipos de dados e constraints. Geralmente utiliza-se uma ferramenta CASE para modelagem deste diagrama, sendo o ER-Win um dos softwares mais utilizados para elaborar este diagrama. Independente do software utilizado é imprescindível que o DBA conte com ao menos um MER para cada uma das bases que ele administra.
2) Padrões de Variáveis (Tabelas, colunas etc) e Documentação
Uma das boas práticas de desenvolvimento é contar com padrões. Saber colocar nomes significativos e explicativos em funções, variáveis, classes etc está se tornando cada vez mais um pré-requisito para quem trabalha com desenvolvimento. No que tange à banco de dados, a idéia não é diferente: possuir um padrão de nomes para tabelas, colunas, constraints e objetos de bancos de dados é muito importante. Aqui a idéia não é apenas possuir um padrão e utilizá-lo largamente, mas 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 de um padrão, recomenda-se montar um documento explicando todos os detalhes deste padrão como, por exemplo, se o padrão é baseado na notação húngara, se os nomes devem ser em português ou se há um limite no tamanho da coluna.
3) Capacity Plan
A necessidade de prever recursos de hardware é uma das grandes responsabilidades de um DBA. Além de economizar recursos, a previsão mostra que há um controle não apenas para os recursos que estão sendo utilizados, mas também para os recursos que podem ser necessários no futuro. Para ajudar nesta previsão, o DBA deve ser responsável pela elaboração de um documento chamado Capacity Plan, ou Plano de Capacidade. Este documento deve listar as necessidades de espaço de armazenamento, utilização de CPU, largura de banda e outros requisitos técnicos que possam impactar o banco de dados. Com certeza, este é um documento que envolve muitos aspectos e deve ser elaborado com cuidado. Por questões práticas, muitas vezes é necessário fazer uso de estimativas e tendências ao invés de contar com informações precisas. Deste modo, o documento não precisa estar 100% correto, mas deve conter uma boa base e previsão dos principais recursos computacionais relacionados ao banco de dados.
4) Dicionário de dados
O Dicionário de dados é um documento que complementa o MER. Este documento deve conter mais detalhes a respeito das tabelas e seus relacionamentos. Por exemplo, além de listar todas as colunas de uma tabela, o documento deve fornecer também uma pequena descrição do significado desta coluna, quais são os valores possíveis, a quantidade típica de valores armazenados e quais constraints agem sobre esta coluna. Além das informações sobre colunas, este documento apresenta o nome dos objetos que dependem da tabela, como stored procedure, triggers, views, funções etc, e suas respectivas funções, além dos parâmetros necessários e o que é retornado. É importante notar que este documento deve sempre estar alinhado e atualizado com a base de dados atual, para evitar desencontros e desentendimentos.
5) Política de segurança
O documento contento a política de segurança é um documento não-técnico que envolve os procedimentos, responsabilidades e atribuições relacionadas tanto à segurança das informações como do acesso à elas. Geralmente este documento contém uma política de usuários e senhas, que especificam várias regras, como as definidas abaixo:
- Troca de senha a cada três meses;
- Desabilitar as contas padrão;
- Forçar senhas com letras, números e caracteres especiais que tenham um tamanho mínimo de 10 posições;
Outras políticas gerais de senha, como o cancelamento após um algumas tentativas e horários definidos para certos usuários, também deve constar neste documento, sempre tendo em mente a utilização de sistemas e bancos de dados.
6) N.D.A (non-disclosure agreement) - Compromisso de sigilo
Imaginem a seguinte situação:
Somos responsáveis por uma base de dados que deve ser integrada com um sistema externo à empresa. Para discutir os detalhes desta integração, uma reunião é marcada com a equipe externa à empresa que desenvolve o sistema. Durante esta reunião são apresentadas informações sigilosas da empresa que trabalhamos, com o objetivo de discutir os aspectos da integração.
Vamos supor que na situação apresentada acima os profissionais da equipe externa hajam da má fé e utilizem as informações fornecidas para seu próprio benefício, seja comercialmente ou não. Este tipo de situação pode gerar diversos problemas, podendo chegar ao ponto onde a equipe que agiu de má fé ser acusada de roubo.
Para e proteger de situações como estas, é comum fazer uso de um documento chamado NDA (non-disclousure agreement), também conhecido como compromisso de sigilo. Este é o tipo de documento que protege todo mundo: tanto quem assina como quem solicita a assinatura. Em termos práticos, que assina compromete-se a não revelar nenhum detalhe da informação que lhe vai ser comunicada sob pena de ser alvo de procedimento legal.
7) S.L.A. (Service Level Agreement) - Acordo de nível de service (ANS)
O SLA, também conhecido como Acordo de nível de serviço - ANS, é um acordo entre a área prestadora de serviços e seus clientes. 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). Geralmente este acordo é colocado na forma de um contrato que deve ser assinado na contratação do serviço. Para banco de dados, em particular, pode-se utilizar um SLA interno, onde o DBA se compromete a dar algum tipo de retorno (feedback) ao solicitante. Notem que este retorno não quer dizer, necessariamente, a resolução do problema ou o conserto, mas sim que o DBA está ciente da solicitação.
8) Diagrama de arquitetura
Atualmente é comum encontrar nas empresas diversos ambientes de bancos de dados. Estes ambientes são separados de acordo com a sua finalidade, isto é, seu principal objetivo. Por exemplo, é comum encontrar ambientes de desenvolvimento, onde os programadores/analistas executam diversos testes durante o processo de desenvolvimento, e ambientes de programação, onde os usuários finais trabalham com os dados reais dos sistemas.
Para documentar e organizar o gerenciamento destes ambientes, o DBA deve elaborar um diagrama de arquitetura, que indica, de forma gráfica, quais servidores pertencem ao ambiente de desenvolvimento e ao ambiente de produção, como eles estão localizados em relação aos usuários com informações sobre link, rede, zonas desmilitarizadas (DMZ), firewalls, roteadores, etc. 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. É importante lembrar que este documento pode ser flexível, ou seja, pode incluir detalhes específicos, como endereços I.P. e senhas, ou apresentar uma visão de alto nível, onde apenas os principais servidores são apresentados.
9) Estratégia de Backup
Todo DBA profissional deve possuir uma estratégia de backup adequada. Esta estratégia deve ser montada de acordo com as necessidades de recuperação e disponibilidade do sistema, ou seja, toda a estratégia de backup vai depender do quanto de downtime e tempo de recuperação é aceitável.
É importante documentar a estratégia de backup utilizada, tanto para oficializar este tipo de tarefa como para conscientizar os usuários a respeito do que pode ser recuperado, quando, sob quais condições e a qualidade do que foi recuperado. Geralmente este documento contém todos os bancos de dados envolvidos na estratégia, como o backup será realizado, qual a periodicidade, qual é o procedimento para recuperação, quem são os responsáveis e os recursos envolvidos. Por fim, é importante atualizar este documento conforme as necessidades de disponibilidade e recuperação mudam de acordo com o volume de informações manipuladas pelos sistemas.
10) Procedimento para controle de chamados ou O.S. (ordem de serviço)
Este último item não é exatamente um documento, mas sim um procedimento que deve ser adotado para o controle de solicitações de serviço (ou chamados) ao DBA. Este tipo de controle evita problemas de comunicação entre quem solicitou e que realiza uma tarefa. Deixar este controle apenas a cargo do envio de e-mails é um primeiro passo, mas investir em um sistema para controlar o acesso às pessoas é algo fundamental, uma vez que este procedimento está diretamente relacionado com as regras definidas no SLA. Obviamente, este tipo de controle deve ser utilizado de forma sensata, pois existem diversos tipos de solicitações que podem exigir tratamentos diferentes, como apenas uma olhada no estado de um servidor. Mais uma vez, a idéia aqui é estabelecer um mecanismo de controle tanto para quem solicita a tarefa como para quem a executa.
Outros tipos de documentos são necessários para quem trabalha com desenvolvimento de sistemas. Atas de reunião, manuais de implementação de sistemas e help-online são apenas alguns exemplos disto. Em geral, o DBA é o profissional que menos tem que lidar com este tipo de documentação. Apesar disso, é importante que o profissional que trabalha com banco de dados, e também com desenvolvimento de sistemas, tenha consciência que esta documentação não necessariamente é burocracia, mas sim que ela é um artefato extremamente importante para todos os profissionais envolvidosMauro Pichiliani é mestre em computação, possui as certificações MCP, MCDBA, MCT e MCTS e atua como consultor de banco de dados com enfoque na área de tunning.
Nenhum comentário:
Postar um comentário