Quantos DBAs são necessários para trocar a lâmpada?

 Uma das dificuldades na gestão do serviço de DBAs é dimensionar de forma eficiente a equipa (DBA BOX). A maioria das equipas de DBAs encontra-se a operar com um número deficiente de elementos.

A principal causa para esta situação é a ideia que menos elementos, acarretam menos custos. No imediato esta suposição pode ser verdade, mas a médio e longo prazo não. A equipa de DBAs com excesso de trabalho, pode cometer erros e constrangimentos de operação e de manutenção que originem custos superiores ao salário de vários elementos da equipa de DBAs.

Esta mensuração não é uma ciência exacta e depende muito do ambiente envolvente: 

• Os SLAs, quanto mais restrito é o nível de serviço, mais exigente é para a equipa de DBAs a efectivação do mesmo. Existem situações em que as respostas das base de dados (resultados das instruções de SQL) é na casa dos milésimos de segundo e esta é uma situação mais difícil de garantir suporte, manutenção e administração do que a base de dados com SLAs em que as respostas (resultados das instruções de SQL) é na casa dos segundos, também o cumprimentos das melhores práticas recomendadas pelo ITIL no suporte a base de dados (incident Management, problem Management, configuration Management, change Management, release Management) e uma gestão de serviço prestado pela DBA BOX pressupõe um controlo das operações, onde é necessário possuir o número de elementos que garantam o seu cumprimento.

  

• Os requisitos de desempenho, quanto maiores forem as necessidades de desempenho das bases de dados mais exigente é o seu suporte, manutenção e administração.

 

• A experiência, competência e empenho individual de cada elemento da equipa de DBAs é muito importante no dimensionamento da equipa.

 

• O impacto da indisponibilidade, quanto maior o custo monetário e de imagem do cliente numa indisponibilidade, maior será a pressão na equipa de DBAs e na suas operações.

 

• O número de SGBDR, o número de base de dados associadas e a sua dimensão, o número de utilizadores, número de processos suportados e a sua tipologia, influência bastante o número de elementos necessário na equipa de DBAs. É necessário realizar manutenção, administração, validar cópias de segurança, produzir documentação, planear a melhoria contínua, garantir a disponibilidade e o desempenho das bases de dados, melhorar instruções de SQL.

 

• No caso das equipas de desenvolvimento não possuírem as competências suficientes no desenvolvimento de instruções de SQL complexo, é necessário que existe essa competência no seio da equipa de DBA para melhorar o desempenho das instruções de SQL.

 

Como alguém já disse é só fazer a conta e obtêm o resultado, neste caso o número de elementos das equipas de DBAs (DBA BOX).

João Paulino

Institucionalizar o BRIEFING/DEBRIEFING e “VOO de cadeira” nas operações da DBA BOX

BRIEFING/DEBRIEFING e “VOO de cadeira” são termos oriundo do meio aeronáutico, como conhecedor do meio, com muito agrado os acolho no meio informático. É importante que não sejam utilizados em vão nas TI’s.

O BRIEFING é uma reunião de informação táctica antecedente à partida para uma missão aérea na qual participam os PILOTOS AVIADORES, onde é explicado o conteúdo da missão, as manobras a realizar e os objectivos a atingir.

O DEBRIEFING é uma reunião em que participam os PILOTOS AVIADORES após a missão aérea, onde são analisados e aferidos os resultados da missão, respectivas manobras e se detectam os aspectos a serem especificamente melhorados.

O “VOO de cadeira” é um treino de preparação onde os PILOTOS AVIADORES simulam todas a manobras e movimentos que vão executar na missão, como se de um voo real se tratasse.

Para assegurar uma elevada proficiência nas suas intervenções as DBA BOX, tal como os PILOTOS AVIADORES asseguram nas suas missões, aquelas devem realizar BRIEFING/DEBRIEFING e “VOO de cadeira“.

O “VOO de cadeira” será um treino de preparação onde o elemento ou os elementos da DBA BOX simulam em ambiente de teste, todos os passos das acções a realizar num ambiente de produção de base de dados.

O BRIEFING será a reunião, onde são alinhados os pormenores da intervenção, revisto o plano e os seus objectivos.

O DEBRIEFING é uma reunião, onde são analisados e aferidos os resultados da intervenção, respectivas acções e se detectam os aspectos a serem melhorados.

No meio militar a falha tem um preço muito alto, falhar ou não, pode ser a diferença entre a vida e morte.

João Paulino

2009 é o ano da DBA BOX Agile

Este ano de 2009 é derradeiro no que respeita à transição das DBA BOXs para uma metodologia “Agile” e alinhamento com ITSM, regidas pelas recomendações do ITIL.

A atitude egocêntrica, desalinhada e reactiva que cerca de 90% das DBA BOXs que prestam apoio de administração e manutenção de base de dados em Portugal, é uma das causas, senão a maior de problemas e incidentes, que acontecem em base de dados.

É completamente errada a postura de dificultar os processos de negócio do cliente, de ser resistente a mudanças. Assiste-se a comportamento errados na demora de realizar tarefas/acções com elevado grau de maturidade com o intuito do cliente sentir na pele a necessidade e dependência que têm da DBA BOX. A ausência de análise e gestão de risco na maioria das acções realizadas, falta de planos de continuidade são exemplos da fraca qualidade na tentativa de prestar um serviço.

Ainda pior é a forma de agir em “Cartel” que algumas DBA BOXs apresentam. Não é nada raro o cliente saber que um dos seus sistemas apresenta lentidão, proceder à detecção da causa, ser informado pelos administradores de sistema que os HOSTs que suportam as base de dados se encontram com carga elevada (seja CPU ou I/O) e quando a DBA BOX é contactada, informa que não há qualquer lentidão ou carga nas bases de dados. Neste tipo de BDA BOX não existe responsabilidade, idoneidade, proficiência, enfim reina a falta de profissionalismo. Quem não sabe é como quem não vê, quantas vezes a DBA BOX não tem sequer a percepção real do seu comportamento e as consequências nos processos do cliente e do seu negócio.

Afaste os seus sistemas de base de dados deste tipo de DBA BOXs e fuja deles como o diabo foge da cruz.

A DBA BOX não é mais uma ilha isolada no IT, onde ninguém consegue aceder, para onde as comunicações são difíceis e os seus habitantes são hostis e não colaborativos.

É necessário criar pontos de comunicação e acesso à ilha da DBA BOX, alinha-la com metodologias Agile e regê-la pelas recomendações do ITIL apoiada por ITSM. É um enorme passo no sentido de fazer com que seja proficiente, responsável, proactiva, colaborativa e alinhada com o seu cliente.  É forma correcta de obter, gerir e melhorar o nível e qualidade esperada do serviço.

 

João Paulino

A Crise e o seu reflexo na DBA BOX

A Crise e o seu reflexo na DBA BOX

Como resultado da actual crise ou por simples falta de recursos humanos e ainda sobre o capa da redução de custo a que os departamentos de TI se encontram sujeitos, estes recorrem a préstimos de DBA BOX externas. Não me parece uma opção descabida, no entanto há que ter cautela, e porquê? Bom, vou tentar explicar e abordando as diferentes vertentes na gestão de serviços da DBA BOX associada a práticas “ITSM/ITIL” e metodologias “Agile”.

Será que os elementos da DBA BOX são suficientes para trocar a sua lâmpada?

O que quero perguntar é se DBA BOX possui recursos suficientes para garantir a correcta e eficiente administração e manutenção do conjunto de base de dados a seu cargo, e nos sistemas considerados críticos uma disponibilidade operacional contínua numa base 24 X 7.

Quais as normas, e processos que a DBA BOX está sujeita e deve cumprir?

Qual é a garantia que são cumpridos todos os procedimentos, que as cópias de segurança são fiáveis e encontram-se em condições de serem utilizadas, as regras de segurança, confidencialidade estão a ser contempladas?

Os dados mais críticos e sensíveis estão a salvo de acções de má fé ou de espionagem?

Qual o método e métricas de avaliação de desempenho de cada elemento da DBA BOX?

A qualquer momento sabe-se quem é o recurso responsável por determinada intervenção? Ou estão encapsulados na DBA BOX? Recursos eficazes, correctos e com brio profissional têm nome e constroem um portfólio.

Quem é que controla, verifica e auditas as acções da DBA BOX?

Cerca de 75% dos problemas com base de dados são originados por erro humano. Uma parte por negligência ou desleixo, mas a maioria por falta de proficiência. As coisas más acontecem, e acontecem de um modo muito fácil e rápido!

Além de prometer que se fornece um nível de serviço da DBA BOX, é necessário garantir e efectivar essa promessa. Para se alcançar esse objectivo é necessário gerir a DBA BOX de forma alinhada com as necessidades e perspectiva do cliente em deternimento do tecnológico. Reduzir os custos e entregar valor ao negócio, migrar de uma prática de perspectiva tecnológica para uma prática de serviço.

É imprescindível retribuir condignamente o cumprimento dos requisitos e expectativas do cliente e do seu negócio ao nível da qualidade do serviço da DBA BOX, aquele deverá ser capaz de avaliar e mesurar a contribuição do serviço da DBA BOX na cadeia de valor do seu negócio. Para obter essa métrica deve-se colocar o cliente a participar na avaliação contínua e no entendimento do serviço da DBA BOX e as suas expectativas futuras do mesmo e preparação para os desafios empresariais do cliente.

O objectivo do PCDA ou ciclo de Deming é tornar claros e ágeis os processos envolvidos na gestão, neste caso na gestão de qualidade do serviço da DBA BOX e divide-se em quatro passos:

 - Planear

 - Executar

 - Verificar

 - Agir

 Fase 1. Planear (PLAN)

Esta fase é desenvolvida tendo como base as necessidades e orientações do cliente e do seu negócio. Quando é iniciada esta fase deve ter em consideração 3 pontos importantes:

                – Determinar os objectivos, incidindo nos itens de controlo.        

                – Estabelecer e o percurso para atingir os objectivos.

                – Seleccionar pelos métodos a utilizar para alcançar os objectivos.

Após decidir os objectivos, recorre-se a uma metodologia correcta para alcançar os resultados pretendidos.

Fase 2. Executar o Plano(DO)

                – Treinar para alcançar a proficiência na metodologia a ser utilizada.

                – Executar o processo cumprindo o método.

                – Recolher a informação pertinente para verificação e validação do processo.

As tarefas devem ser executadas exactamente e cumprindo os planos.

Fase 3. Verificar os resultados do Plano Executado (CHECK)

                – É durante esta fase que são validados os processos e avalia-se os resultados obtidos:

                – Verificar se as acções foram realizadas de acordo com o padrão.

                – Comparar os valores/resultados com o padrão/norma/boas práticas.

Aferir se os itens de controlo correspondem aos dos objectivos.

 

Fase 4. Realizar acções correctivas ao Plano Executado e Verificado(ACT)

                – Estas acções devem ser baseadas nos resultados da fase 3.

                – Se os resultados se desviarem do padrão, iniciar as acções necessárias para os corrigir.

                – Caso se encontrem fora do padrão, deve-se investigar a causa ou origem e providenciar acções de prevenção e correcção.

Melhorar de forma continuada o processo de trabalho e o método.

A DBA BOX Ágil encontra-se envolvida e comprometida com a segurança, disponibilidade, confidencialidade, evolução e comportamento dos dados numa ou várias Base de Dados. Para além das competências técnicas tradicionais de administração, programação, modelação de dados, realização de testes, etc, deverá possuir conhecimentos sobre os processos de software, bem como competências que lhe permitam uma colaboração efectiva com profissionais de outras BOX’s, por exemplo: equipas de desenvolvimento, arquitectos e engenheiros de  Base de Dados, para esta colaboração a DBA BOX deverá possuir conhecimentos gerais de OOP, UML entre outras. A acção da DBA BOX deverá ser evolutiva e interactiva e tem que adaptar-se ao modernos processos de desenvolvimento (i.e.: Unified Process  ou XP).

 

João Paulino

Database Architect 

Livro sobre as melhores práticas no redimensionamento e melhoramento da MS SQL Server BOX

Este é um dos projectos que tenho para este segundo semestre, o outro ainda é segredo provavelmente sobre o outro SGBDR, mas mais prático. Estes dois projectos serão de livre distribuição e em formato electrónico. Aliás a estruração e planificação dos mesmos manteram-me afastado da “lides” bloguistas.

João Paulino

Nota: Projecto alterado, aguardem as novidades!!!

João Paulino