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 verdade vem sempre ao de cima – 70% das Empresas falha os SLAs

 

 

Possuir e não possuir um SLA acordado

 

 Pode parecer caricato, mas é verdade que cerca de 70% das empresas falha os SLAs e deve-se essencialmente ao facto das expectativas do negócio estar muito acima das capacidades das TI (engloba comunicações, software, hardware e recurso humanos), que origina a falha no cumprimento dos SLA. Podemos imaginar então os valores de não cumprimentos dos OLA (Nota: OLA não esta relacionada com a conhecida marca de gelados e congelados). Aqui coloco a definição de alguns dos termos mais utilizados nesta componente das TI.

Availability: Capacidade que determinado componente ou serviço tem de executar sua função em certo momento ou por um tempo definido.

Countermeasures: Acções realizadas para prevenir ou reduzir os efeitos de um risco identificado.

Critical Business Functions: Partes críticas dum processo empresarial suportado por um serviço de TI.

End-to-End Service: Todos os componentes de infra-estrutura de TI necessários para entregar um serviço de TI.

High Availability: Método utilizado pata minimizar ou mascarar falhas em componentes de TI.

Incident Life Cycle: Ciclo de vida de um incidente que envolve a ocorrência do incidente, detecção do incidente, diagnóstico da causa da falha, a reparação da falha e recuperação e restauro do serviço.

Maintainability: É a actividade de manter ou restabelecer um componente (software/hardware) da infra-estrutura de TI em um estado operacional.

Operating Level Agreement (OLA): Um acordo interno que apoia as exigências de um SLA.

Risk Management: Processo de identificação e implementação de actividades com a finalidade de reduzir os riscos activos a um nível considerado aceitável.

Reliability: Ausência de falhas em componente ou serviço em determinado período de tempo.

Serviceability: Acordos com fornecedor de serviços de TI para fornecer e manter serviços e componentes de TI.

Service Level Agreement (SLA): Acordo escrito que documenta os níveis exigidos por determinado serviço, firmado entre o fornecedor do serviço (Empresa ou Departamento de TI) e a organização ou terceiros.

Service Outages: O mesmo que Downtime.

João Paulino

Downtime: Período de tempo que um serviço se encontra sem funcionar, com relação ao acordo de funcionamento determinado nos SLAs.

 

Governação de TI, Conceitos e Modelos – Parte I – Introdução (Continuação I)

(Continuação) …

Governação é o quadro no qual a estratégia é formalmente gerida/administrada, inclui elementos como a apresentação de relatórios, funções e responsabilidades, as políticas e normas, e a gestão de riscos ”

(Em “Estratégias de Negócios e de TI” – ITSM / OGC – O Governo do Reino Unido)

 

Nota: Sinceramente não entendo porque é que muitos autores e profissionais utilizam o termo Governança e detrimento do termo Governo… ( João Paulino )

 

Conceitos:

• Processos e Estruturas com o objectivo de garantir que as TI’s suportem e maximizem os objetivos e estratégias da organização.
• Permite controlar – medir, auditar – a execução e a qualidade dos serviços.
• Viabiliza o acompanhamento de contratos internos e externos
• Define condições para o exercício eficaz da gestão com base em conceitos consolidados de qualidade.

Vantagens:

• Alinhar as estratégias de TI com as do negócio
• Maior capacidade e agilidade para novos modelos de negócios ou ajustes nos modelos existentes.
• Demonstra a relação entre aumento nos custos de TI e aumento no valor da informação.
• Mantém os riscos do negócio sob controlo.
• Demonstra a importância da TI na continuidade dos negócios.
• Mede e melhora continuamente a performance de TI.

Defenições:

• Controlos: Conjunto de políticas, procedimentos, práticas, e estruturas organizacionais desenhadas e desenvolvidas para prover uma garantia razoável de que os objectivos do negócio serão atingidos e que acontecimentos indesejáveis serão prevenidos ou detectados e corrigidos atenpadamente.
• Objectivos de Controlo de TI: Definição de determinados objectivos e/ou resultados a serem obtidos/atingidos ao implementar procedimentos de controlo numa determinada actividade de TI.

(Continua) …

 

João Paulino

Governação de TI, Conceitos e Modelos – Parte I – Introdução

Governação de TI

• Conceitos, definições e boas práticas
• Metodologias e Frameworks (recomendações, regras e normas) ITIL
    Estrutura, conceitos e processos COBIT
    Estrutura, conceitos e processos
  CMMI, BS 7799 ISO/IEC 17799:2005/ BS 15000 ISO/IEC 20000-1:2005  e outros modelos
• Normas e Certificação
• Visão geral
• Integração e aplicação dos modelos

Governação: Modelo que define direitos e responsabilidades pelas decisões, estratégias e investimentos, encorajando comportamentos desejáveis e cumprimento de recomendações, normas e regras na utilização das TI, mapeados em controlos e processos que asseguram e garantem o alinhamento entre negócios e TI.

(Continua)…

João Paulino