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

MS SQL Server versus Oracle Database, tão diferentes e ao mesmo tempo tão próximos (1.ª Parte)

Este artigo pretende alertar para o cumprimento de boas práticas ao nível de programação SQL nos seus dialectos T-SQL para o caso do MS SQL Server e PL/SQL para o caso do Oracle Database, independentemente do SGBDR, estas práticas têm elevadíssimos benefícios.

 

Boas práticas de codificação em SQL, são muitas vezes simplesmente ignoradas, mas originam imensos custos para o projecto, aplicação ou sistema e até para a organização.  

 

Na minha opinião, um Programador de SQL,  possuir esta qualidade ou mesmo habilidade é uma atitude orientada aos objectivos, alinhamento com as necessidades do cliente ou negócio, profissionalismo e um óptimo estilo de programação em SQL e seus dialectos.

 

E refiro-me concretamente, no caso do Oracle à utilização de BIND VARIABLES, são fundamentais para o desempenho de um sistema.

 

Para se entender melhor passarei a explicar.

 

Imagine uma aplicação que é alvo de milhares de instruções de SQL numa tabela de Base de Dados, como as apresentadas a seguir:

 

SELECT u_nome, p_nome, c_postal FROM t_fornecedor WHERE id_fornecedor = 10735;

SELECT u_nome, p_nome, c_postal FROM t_fornecedor WHERE id_fornecedor = 10840;

SELECT u_nome, p_nome, c_postal FROM t_fornecedor WHERE id_fornecedor = 10987;

 

Cada vez que a consulta é executada, o SGBDR Oracle primeiro analisa a SHARED POOL (zona de memória) a verificar se a instrução de SQL já foi alguma vez executada. Caso tenha já tenha sido executada, o plano de execução utilizado na anterior instância é reutilizado, e a instrução de SQL é executada.

 

No caso da instrução de SQL não ser encontrada na SHARED POOL, o SGBDR Oracle terá executar o processo de “parsing” ou seja análise da instrução de SQL e posteriormente realizar o estudo dos vários planos de execução para encontrar o melhor plano de acordo com as suas parametrizações, antes de executar a instrução propriamente dita. Este processo denomina-se “HARD PARSE”, e para uma Base de Dados OLTP (Online Transaction Processing) poderá consumir mais tempo do que a própria instrução de SQL.

 

Quando é procurada na SHARED POOL a exacta correspondência de uma instrução de SQL, só instruções exactamente iguais são consideradas. Se como no exemplo das Instruções SQL acima colocadas, forem submetidas instruções  de SQL únicas, em que o predicado da cláusula WHERE é sempre diferente (id_fornecedor = 10735, id_fornecedor = 10840, etc.) nunca será encontrada uma correspondência e será necessário realizar um “HARD PARSE”. O “HARD PARSE” é muito intensivo na utilização de CPU e envolve operações de como “LATCH” de chaves nas áreas de memórias partilhadas. Esta situação poderá não originar problemas num sistema com poucos dados e pouco solicitado, mas num sistema com bastantes dados, multi-utilizador e com muitas transacções e muitas delas distribuídas, poderá simplesmente colocá-lo de rastos, com centenas ou milhares de instruções a necessitarem de ser analisadas “HARD PARSE” em simultâneo. Associado a esta situação surge um problema, a contenção que é o resultado dos inúmeros “HARD PARSE” realizados, o “HARD PARSE” é imune a medidas reactivas tais como aumento da memória física, incremento do n.º de CPU’s e muitas outras mediadas de reacção. O “HARD PARSE” é um problema encontrado em muitos sistemas e aplicações empresariais.

 

A solução para este problema é a reutilização dos planos de execução, e esta pode ser alcançada recorrendo a “BIND VARIABLES”. As “BIND VARIABLES” não são mais nem menos do que variáveis de substituição que são colocadas nas posições dos literais (10735, 10840, 10987). Exemplo da mesma instrução, desta vez recorrendo a “BIND VARIABLE”:

 

SELECT u_nome, p_nome, c_postal FROM t_fornecedor WHERE id_fornecedor =: fornecedor_numero;

 

Exemplo de SQL PLUS

 

SQL> variable fornecedor_numero number

SQL> exec :fornecedor_numero := 10987

SQL> SELECT u_nome, p_nome, c_postal FROM t_fornecedor WHERE id_fornecedor =: fornecedor_numero;

 

É muito fácil implementar a utilização de “BIND VARIABLES” em Java, C++ C# ou mesmo em VB.net. E como disse no início este problema não é só para o SGDBR Oracle, acontece ao mesmo ao MS SQL Server ou qualquer outro SGDBR. O MS SQL Server e SQL Bind Parameters serão abordados na 2.ª parte.

 

Continua…

 

 João Paulino

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