É muito comum aos profissionais da área de informática serem questionados pelos amigos a respeito dos problemas que experimentam no seu dia a dia - no meu caso, principalmente quando é assunto é Microsoft.
Recentemente, me deparei com algumas situações de perdas de dados, e percebi que existe uma falta de informação do usuário final das melhores práticas e opções de como fazer backup. Aliado a este fato, a falta de tempo e a confiança exagerada nos equipamentos utilizados aumentam ainda mais o risco de perdas de dados. Na maioria dos casos, fotos digitais, planilhas financeiras, documentos de teses e trabalhos de fim de ano são perdas inestimáveis.
Este assunto é muito vasto e um post somente não seria suficiente para abrangê-lo. Por isto, resolvi dividir em três posts:
1 – Política de Backup;
2 – Extração dos dados e ferramentas disponíveis;
3 – Manipulação dos dados e ferramentas disponíveis.
IMPORTANTE: As informações que se seguem são melhores práticas que desenvolvi para meu uso e de alguns amigos PARA DADOS PESSOAIS APENAS. Utilize por sua conta e risco. Dados empresariais geralmente seguem processos e regulamentações específicas e não são tratados nesta série de posts.
Este é o primeiro post da série, que trata da política de backup para usuários finais. Nada melhor que iniciar discorrendo sobre as tecnologias mais comuns para a realização de backup:
CD e DVD: o tempo de vida médio dessas mídias é de 5 a 30 anos, dependendo do método de armazenagem (NIST). Outro ponto importante é a compatibilidade em longo prazo, ou seja, em 30 anos existirão aparelhos de CD/DVD para computadores?
Discos rígidos: A relação preço/capacidade de disco rígido é uma das melhores atualmente. A principal desvantagem dos backups de disco rígido é que eles são facilmente danificados, e que sua durabilidade ao longo de períodos de anos é desconhecida. Fiquem atentos as interfaces disponíveis do disco, pois ao longos dos anos as interfaces de discos vão mudando e é provável que não seja possível re-conectar um disco antigo em um computador novo.
Solid state storage: Também conhecido como memória flash ou USB flash drives. Estes dispositivos são relativamente caros para sua baixa capacidade, mas oferecem excelente portabilidade e facilidade de uso. Eu particularmente acho que eles não devem ser utilizados como meios para backup permanente, mas para transporte de dados apenas.
Backup remoto (on-line): É o backup via internet. Ele protege contra alguns dos piores cenários, como incêndios ou inundações que destruiriam quaisquer cópias de segurança confinado no mesmo local físico. No entanto, há uma série de inconvenientes, como as conexões de internet serem mais lentas do que a velocidade dos dispositivos de armazenamento de dados local. Um problema para grandes quantidades de dados. É necessário confiar em um provedor de serviços que garanta privacidade e integridade dos dados do backup. Neste caso entra a segurança, que será discutida em outro post.
1 – Definir os arquivos que você gostaria de fazer backup.
Após identificar as mídias que você vai usar, a primeira tarefa é selecionar quais os arquivos devem estar no backup. Certamente não é toda a informação que você tem. A sua resposta vai definir quanto de espaço é necessário para armazenar os dados.
2 – Definir os tipos de documento
A segunda tarefa é definir os tipos de documentos, para a montagem de uma política de backup. De uma maneira simplificada, neste post criei dois tipos:
Documentos estáticos: São aqueles documentos que não devem sofrem alterações. Ex: fotos, filmes, músicas, formulários, recibos do IR, documentos de referência, etc
Documentos dinâmicos: São aqueles em que a informação muda periodicamente. Ex: teses, planilhas financeiras, documentos de projetos, etc.
ps: Softwares de correio eletrônico que baixam as mensagens localmente no seu computador deve ter modelo diferenciado para backup. Tópico para outro post.
3 – Definir a classificação de importância
A terceira atividade para definirmos nossa política de backup é classificar os dados em relação a sua importância. Gosto muito do modelo:
Must Have (Obrigatório) – Esses dados devem sempre estar disponíveis em backup na sua última versão; Ex: fotos, filmes caseiros, teses, documentos de projetos, planilhas financeiras, etc.
Nice to Have (Importante) – Alguns dados que podem ser obtidos de outra maneira que não somente o seu backup, mas dariam certo trabalho. Ex: músicas, filmes, documentos de referência, etc
Optional (Opcional) – Dados que somente se tiver espaço sobrando você faria um backup. Ex: músicas.
4 – Definir a política de backup pessoal
A última atividade é definir a política de backup. O modelo depende do modo de trabalho. Usuários móveis nem sempre tem acesso aos discos rígidos ou DVDs dos locais em que estão, e estão mais sujeitos ao roubo ou perda da informação. Usuários que estão constantemente no mesmo local físico utilizam outro modelo de política de backup.
Abaixo um exemplos de política de backup para usuários finais. No próximo post iremos atualizar essa política apontando a forma de extração de dados.
|
|
Obrigatório |
Importante |
Opcional |
|
Dinâmico |
Diário – on-line ou flash
Semanal – Disco ou on-line
Mensal - DVD |
Semanal – Disco
Mensal – DVD |
Mensal - DVD |
|
Estático |
Criação – on-line
Criação – Disco
Semestral – DVD |
Bimestral – Disco
Semestral – DVD |
Anual - DVD |
Um processo de incorporação - (Merge & Acquisition - M&A) de uma forma geral é um grande desafio. Consolidar as infra-estruturas de rede física e lógica são atividades complexas e caras. A novidade é o uso do IPv6 nesse processo, pois além dos benefícios na integração das infra-estruturas a empresa aproveita para iniciar o ciclo de atualização do IPv4 para o IPv6, uma vez que dentro dos próximos cinco anos o IPv6 deve ser o protocolo predominante na Internet .
Quando dois ambientes de TI independentes se tornam um, os primeiros problemas que aparecem são:
- Conflitos de sub-rede de IPv4 e tabelas de roteamento;
- Gerenciamento de regras de firewall;
- Integração dos serviços de resoluções de nome;
- Integração de autenticações e serviço de correio eletrônico;
- Projeto de nova topologia para a nova empresa.
Todos os problemas listados acima podem resolvidos utilizando IPv6 devido às recentes mudanças nos roteadores e sistemas operacionais, que suportam nativamente o IPv6. As tecnologias de transição como o ISATAP e o IP sobre HTTPS, e o crescimento da maturidade de protocolo são outro ponto positivo para a adoção do IPv6.
Os benefícios do uso do IPv6 em um cenário de M&A são a redução da complexidade e a melhor comunicação ponto a ponto, permitindo que aplicativos internos que não funcionem com NAT, possam ser executados entre as duas empresas. Além disso, o IPv6 oferece melhor segurança e suporte para a entrega priorizada e em tempo real dos dados .
Em breve, terminei um documento sobre IPv6 em um cenário de M&A e ,assim que ele for validado com o time de IPv6 da Microsoft, eu compartilharei com vocês.
Dando continuidade a serie de posts sobre Green IT vou detalhar mais o assunto de energia elétrica.
Quando se planeja a arquitetura de uma aplicação, é comum se preocupar com itens como: custo, escalabilidade, alta-disponibilidade, dentre outros. Em um futuro não tão distante, dois novos itens serão mensurados e terão tanta importância quanto os mencionados. O custo do consumo de energia e o impacto ambiental.
De posse da cartilha da ANEEL, que explica a conta de energia elétrica, obtenho o valor médio do KWh cobrado no Brasil em 2005, que é de R$ 0,293. Desta forma podemos perceber melhor o impacto financeiro. Apenas como curiosidade, nesse valor estão embutidos: Tributos (34,44%), Distribuição (27,76%), Transmissão (7,01%), e Geração (30,77%).
Uma lâmpada de 60W (watts), em uma hora gera 0.06 (60/1000) kWh. O custo de 1 hora com essa lâmpada ligada seria 0.06 * 0,293 = R$ 0,01758. Imagine agora, essa lâmpada ligada 24 horas por dia, 7 dias por semana durante todo o ano. Para chegar ao resultado final usamos a fórmula: 0.06 * 24 *365 * 0,293 = R$ 154,00. Considerando que cada quilowatt-hora contribui com aproximadamente 1 Kg de CO2 emitido, com 525,6 kWh por ano geraríamos 525,6 Kg de CO2 emitidos no ano.
Os detalhes de consumo de energia e o total kWh para diversos tipos de configuração do equipamento e carga já estão disponíveis pela maioria dos fabricantes de hardware.
Observemos, por exemplo, os detalhes de energia do Dell PowerEdge R710 com um Power Supply de 870W, o modelo típico com 2 Intel Xeon, 12GB RAM, 4 HD, 6 NIC Gigabits e 2 Power Supply. O fabricante estima para ele um consumo de 2.143 KWh/ano para quando o servidor está com pouca utilização e 4.674 quando com 100% de utilização. (obs: Esses valores utilizam a soma de 1 watt a cada watt nominal do servidor, como overhead).
Se quiser ir além, peça o consumo de energia de cada componente. O uso de energia dos componentes individuais não precisa ser exata, mas é importante porque ele fornece um sistema de classificação para os consumidores de energia dentro do servidor. Por exemplo, a CPU é geralmente o maior consumidor de energia.
Baseado nos números do Dell PowerEdge R710, do modelo típico, é possível montar uma planilha que calcula o valor anual do custo de energia elétrica e quantidade de CO2 emitidos. Nesse exemplo, vamos imaginar 3 servidores, dois servidores web e 1 servidor de Banco de Dados SQL .
|
|
(R$) Pouca utilização / ano |
(CO2) Pouca utilização / ano |
(R$) Alta utilização / ano |
(CO2) Alta utilização / ano |
|
Servidor 1 - WEB |
627,9 |
2.143 |
1369,5 |
4.674 |
|
Servidor 2 – WEB |
627,9 |
2.143 |
1369,5 |
4.674 |
|
Servidor 3 – BD |
627,9 |
2.143 |
1369,5 |
4.674 |
|
TOTAL |
1.883,7 |
6.429 |
4.108,5 |
14.022 |
É certo que os servidores não vão operar o tempo todo a 100% nem a 5%. Por isso, é importante avaliar qual a carga a aplicação vai exercer em cada servidor. Igualmente importante é configurar o sistema operacional de forma que exija menos CPU e disco, pois, dessa forma, se consome menos energia e consequentemente se polui menos.
Os Datas Center geralmente contêm centenas a milhares de servidores. Apenas para ilustrar o impacto de uma especificação acima do necessário, imagine que um lote de 200 servidores do modelo Dell PowerEdge R710 fosse da configuração máxima. O consumo de energia em pouca utilização é de 3.877 kWh/ano. Multiplicando por 200, obtemos o valor de 775400 kWh ou R$ 227.192,20 de conta de energia elétrica por ano. Se esse 200 servidores fossem da configuração típica o custo cairia para R$ 125.579,80 por ano. Uma economia de 101.612,40 por ano. Esse valor poderia ainda ser maior se os servidores fossem de muita utilização (cargas maiores).
Alguns críticos colocam que os custos necessários para se implantar Green IT não são atraentes e, por isso, não vêem beneficio imediato. Eu discordo. A adoção das práticas de Green IT, que foca em ajustar a sua TI para utilizar os recursos de forma eficiente, reduz custos, fomenta a maturidade dos processos internos e reduz o impacto ambiental. O investimento inicial se paga ao longo dos anos e a qualidade e eficiência operacional dos serviços pode ainda mais reduzir os custos.
Esse post foi baseado no artigo escrito por Rajesh Chheda, Dan Shookowsky, Steve Stefanovich, and Joe Toscano, publicado no The Architecture Journal #18, da Microsoft. O jornal pode ser acessado em http://www.architecturejournal.net/.
Um dos assuntos que têm me interessado muito é o gerenciamento de Data Centers e Green IT. A Microsoft tem publicado vários artigos interessantes sobre o assunto, em diversos canais diferentes.
Neste post, vou resumir e comentar o artigo: Microsoft’s Top 10 Business Practices for Environmentally Sustainable Data Centers, publicado em abril deste ano pelo Microsoft’s Global Foundation Services (GFS) Infrastructure Services team.
O que mais me chamou a atenção no artigo é a mudança de paradigma que a Microsoft propõe e adota no gerenciamento de Data Centers para, de forma sustentável, reduzir a energia elétrica, desperdícios e custos.
1 – Forneça incentivos para sustentar os objetivos: Incentivos podem reduzir o período de tempo necessário para se obter resultados. Nos Data Centers da Microsoft, os gerentes são recompensados pela melhoria da eficiência de operação como um todo. Por exemplo, o Power Usage Effectiveness (PUE), que é o resultado do total de energia do Data Center dividido pela energia que é utilizada para a infraestrutura de servidores, é usado para recompensar os gerentes. Esse modelo é diferente do usado pela maioria dos Data Centers, que recompensa os gerentes apenas pela disponibilidade dos serviços contratados.
Outra diferença está na forma de cobrança de hosting. O modelo utilizado pela maioria dos Data Centers cobra pelo metro quadrado ocupado. Esse modelo tende a compactar diversos equipamentos em pequenos espaços, exigindo mais consumo de energia elétrica e infraestrutura de resfriamento. Além do mais, a cobrança por metro quadrado não reflete o verdadeiro custo da construção e manutenção dos Data Centers.
O modelo de cobrança de hosting adotado pela Microsoft é baseado na proporção de energia elétrica consumida. Esse novo modelo permitiu ganhos substanciais em eficiência e mudou a forma de o cliente implantar a solução, incentivando–o a também ser mais eficiente na sua solução.
2 – Focalize a utilização efetiva do recurso: Eficiência energética é um elemento importante nas práticas da Microsoft, mas igualmente importante é a utilização eficaz dos recursos implantados. Por exemplo, se apenas 50% da capacidade de alimentação de um Data Center é utilizada, é desperdiçada uma grande parte da energia despendida nas fontes de alimentação ininterrupta (UPS), geradores, equipamentos de resfriamento e assim por diante para a capacidade total prevista.
A Microsoft vem utilizando uma arquitetura modular de Data Centers. Desta forma, adiciona mais recursos à medida do necessário.
3 – Utilize servidores virtuais: Seguindo a lógica do item 2, servidores subutilizados são um problema típico em vários Data Centers. A solução adotada/proposta na Microsoft é a migração de servidores físicos para virtuais, consolidando aplicações em servidores físicos compartilhados.
A tecnologia de virtualização Hyper-V em Windows 2008 x64 é amplamente usada nos Data Centers da Microsoft, e é à base de infraestrutura do Windows Azure.
O benefício imediato do uso de virtualização é a melhoria da eficiência operacional. As equipes de operação dos Data Centers conseguem implantar um servidor em questões de minutos. Se um servidor físico apresentar problemas é possível migrar os servidores virtuais para outro hardware sem causar indisponibilidade do serviço.
Estudos comprovaram que os servidores físicos consomem aproximadamente 60% do consumo total de energia quando estão com 20% de processamento. O consumo chega a aproximadamente 85% quando estão com o processamento entre 80% e 90%.
Os benefícios chaves de virtualização são:
· Redução na compra de equipamentos;
· Redução de custos de energia, resfriamento e espaço;
· Maior agilidade para implantar novos serviços;
· Redução de indisponibilidade e janelas de manutenção;
4 – Aumente a qualidade dos processos: Vários processos existentes nos Data Centers são customizados para atender requerimentos de conformidade, como SOX e Basileia II. A qualidade e consistência dos processos são cruciais para se obter um padrão de comportamento e reduzir situações não planejadas.
5 – Adote o Gerenciamento de Mudanças: Processos de mudanças fracos ou planos de mudanças mal definidos geralmente resultam em um comportamento inesperado e desastroso para a empresa. O impacto desse resultado não esperado afeta os objetivos de Green IT, pois os procedimentos de análise e correção requerem mais uso de energia elétrica e possivelmente acarretam uso ineficiente de recursos computacionais.
Processos bem documentados, repetitivos e que envolvam as pessoas corretas, juntamente com o desenvolvimento e a análise dos planos de comunicação, risco e rollback pela equipe que prepara a mudança, são extremamente importantes para a sobrevivência dos Data Centers.
6 – Invista no monitoramento e entendimento do comportamento das suas aplicações: As aplicações e particularidades da rede e seu tráfego são únicos em cada ambiente. Quanto mais você as entender, mais fácil será implantar melhorias para elas. Defina uma equipe que faça análise de performance e tendência de suas aplicações. Se as suas aplicações não são eficientes, esse comportamento vai ser repassado para os servidores.
7 – Defina uma plataforma de hardware para que atendam os requerimentos das aplicações: Na Microsoft, devido ao volume de compra para os Data Centers, os hardwares dos servidores são modificados junto aos fornecedores para que gastem o mínimo de energia possível, eliminando slots de memória e I/O que não serão utilizados.
Como a maioria das empresas não tem essa abertura para a customização de hardware, outra forma de se obter a melhor plataforma de hardware é comprá-lo com a configuração exata do que foi especificado. Quando se entende o comportamento da sua aplicação, é possível avaliar, por exemplo, que um servidor com quatro processadores pode não ter um desempenho tão melhor do que um servidor de dois processadores, que consome menos energia.
8 – Avalie e teste o desempenho dos servidores, o consumo de energia e o TCO: O processo de compra de equipamentos para os Data Centers da Microsoft é todo baseado em testes. Existe uma equipe que avalia o consumo de energia, a performance e calcula o TCO de cada equipamento selecionado. É importante realizar todos os testes in-house para que seja possível avaliar outros quesitos de desempenho e simular a carga dos aplicativos que vão ser executados neles.
Na ausência de um time para realizar todos os teste, é recomendado utilizar SPECpower_ssj2008 – Para maiores informações visite o site do Standard Performance Evaluation Corp. - www.spec.org/specpower
9 – Defina um número reduzido de opções de hardware para os clientes: Restringir a quantidade de opções para hardware permite que o processo de compra se beneficie do volume, proporcionando redução no custo do equipamento. Outro beneficio importante é a redução do custo operacional e da complexidade para instalar e suportar o equipamento.
O processo de seleção de novos servidores ocorre a cada 12-18 meses nos Data Centers da Microsoft, de maneira que não exista a necessidade de se instalar novos hardwares em ciclos de tempo pequenos.
10 – Tire proveito da competição entre os fabricantes de hardware para promover a inovação e redução de custos: Fomentar a competição é uma boa prática. Compartilhe seus requerimentos e soluções entre vários fabricantes, para que seja possível trabalhar em uma solução otimizada com cada um deles.
Geralmente o peso maior fica para o consumo de energia e preço, sendo a capacidade de processamento secundário. Não se esqueça que consumo de energia é um dos maiores custos de um Data Center.
Um evento de indisponibilidade representa, antes de tudo, uma fraqueza da sua estrutura de TI. Não importa se a causa foi um ataque de denial-of-service, um bug do produto ou uma falha na operação. Pode até parecer injusto, mas é a realidade.
Um grande equívoco é acreditar que a melhor solução está nas tecnologias (caras) de tolerância a falhas. Investir em treinamento e desenvolvimento de processos pode ser bem mais eficiente do que se pensa. Dê uma olhada no gráfico abaixo. Ele é o resultado de uma pesquisa realizada pelo Gartner sobre as principais causas de falhas nos serviços de TI.
Olhando o gráfico não tem como não lembrar da Lei de Pareto. Nesse caso, se gasta 80% do orçamento e energia para resolver 20% dos problemas (o foco atualmente ainda é tecnologia, onde se gasta mais dinheiro.)
Em relação identificar custos relacionados à indisponibilidade, é relativamente fácil calcular o custo de substituição de um hardware danificado, os custos de perda de produtividade e de perda de faturamento. No entanto, os custos resultantes de perdas em categorias como desempenho financeiro e reputação são mais difíceis de calcular.
A tabela abaixo ajuda a identificar as categorias de perdas e os custos que uma parada no serviço podem causar. Todas elas são diretamente proporcionais ao tempo de parada e recorrência.
|
Categoria |
Custo Envolvido |
|
Produtividade |
Número de empregados afetados x custo da hora de cada empregado
Aumento do pessoal para suportar o impacto de várias indisponibilidades |
|
Receita |
Perda faturamento – Ex: número de transações não realizadas
Pagamentos de multas
Perda de receita futura – Ex: perda de um cliente fidelizado |
|
Desempenho Financeiro |
Fluxo de Caixa
Preço da ação |
|
Reputação |
Diretoria da Empresa
Clientes
Fornecedores
Mercado Financeiro
Parceiros de Negócio |
|
Outros |
Empregados insatisfeitos
Custo de hora extra ou suporte técnico especializado
Custo de envio/recebimento emergencial
Despesas de Viagem |
Tenho certeza que, se a maioria das empresas calculassem as perdas decorrentes de uma indisponibilidade corretamente muita decisões seriam mudadas.
O investimento em mais treinamento e a adoção de processos de governança melhoram o nível de serviço da TI como um todo, diferente do valor gastos em tecnologia, que na maioria das vezes evitar a indisponibilidade de poucos serviços.
A nuvem é o termo usado como uma metáfora para a Internet. É uma abstração para a infraestrutura complexa que se esconde por trás de um serviço. Este modelo tipicamente se baseia em data centers externos, em um modelo de infraestrutura de serviço com custos operacionais por CPU.
Vamos fazer um exercício onde podemos aplicar esse conceito de computação em nuvem dentro dos data centers corporativos? Vamos trabalhar o serviço de correio eletrônico, um dos serviços mais utilizados pelas empresas e um dos mais críticos.
Imaginemos, então, o seguinte cenário. A empresa CONTOSO (com 50.000 funcionários) tem um ambiente de correio eletrônico baseado em Microsoft Exchange Server 2007. CONTOSO acaba de adquirir a empresa NWTRADERS (com 20.000 funcionários) e o primeiro projeto é a consolidação dos serviços de correio eletrônico em CONTOSO.
No modelo tradicional, a empresa CONTOSO iria avaliar se o hardware utilizado é suportado, e como na maioria dos casos, prepararia uma nova arquitetura para absorver os novos usuários. Esse modelo requer um número considerável de tempo e dinheiro para passar pelas etapas de aquisição de servidores, instalação e configuração do produto e reestruturação da nova arquitetura.
No modelo de computação em nuvem privada, o ambiente de correio eletrônico seria baseado em uma estimativa de capacidade de um conjunto de hardware/software chamado de célula do serviço: uma combinação dos diversos papéis desempenhados pelo serviço de correio eletrônico capaz de suportar um número específico de usuários.
Imaginemos, em nosso cenário, que cada célula comportaria até 10.000 caixas postais. Neste caso, seria necessário montar apenas mais duas células para os usuários da NWTRADERS.
Para trabalhar no modelo da nuvem é necessário ter contratos com fabricantes de hardware para fornecimento de um padrão predefinido e com estimativas de entregas pré-acordadas. A utilização de servidores virtuais é quase obrigatória, pela facilidade do uso de templates de servidores virtuais. Com isso, é possível subir uma célula do serviço em questão de minutos.
Não quero passar a idéia de que montar a infraestrutura de rede para a nuvem seja simples, pois exige uma arquitetura modular de quase todos os componentes. No nosso exemplo, qual seria o impacto de se colocar mais duas células no serviço de Active Directory e Segurança?
O mais importante, e que nem sempre é falado, é a dependência direta do gerenciamento de serviço. A computação em nuvem privada requer uma maturidade nos processos de governança muito maior do que o modelo atual praticado nas empresas.
Por fim, não acredito que o modelo de computação em nuvem privada seja o melhor para pequenas e médias empresas, no entanto, aquelas que oferecem serviços para milhares de usuários devem repensar a forma como trabalham e avaliar os benefícios desse novo modelo.
Os gerentes de TI são colocados diversas vezes em posição desconfortável quando precisam preparar um relatório que justifique o investimento de um ou mais projetos de TI. Primeiramente porque se baseiam exclusivamente em recursos e benefícios da tecnologia proposta e atribuem valores errados ou desconsideram os benefícios indiretos.
Por este motivo, o Microsoft Business Value Group criou um guia passo a passo que aborda o processo de justificação econômica, que vai da analise financeira à forma da apresentação dos resultados para o comitê gestor da empresa.
O REJ (Rapid Economic Justification) não é novo, e infelizmente é pouco conhecido. O REJ vai além da construção dos elos entre os gerentes de TI e os executivos de negócios, ele permite a "fusão" da linguagem comum de economia no plano de TI, de forma a demonstrar como investimentos em TI podem beneficiar o negócio.
O REJ enfatiza a palavra rápida por um bom motivo: para que você realize a análise rapidamente. Em primeiro lugar porque as condições de negócios mudam rapidamente, e existe o risco de re-trabalho sem que haja resultados. Em segundo lugar, a área diretora da empresa tem geralmente pouco tempo, e mostrar à eles informações que não permita a tomada de decisão gera um risco de naufragar o projeto por justificativa ruim.
Duas a quatro semanas é a estimativa de tempo para aplicar o REJ em uma iniciativa, dependendo da sua complexidade, do acesso às informações e a maturidade da organização.
Se você se interessou sobre o assunto e quer mais informações, não deixe de ler o documento Rapid Economic Justification Guide que está disponível no link: http://www.microsoft.com/business/enterprise/value.mspx
Para começar a falar sobre o primeiro motivador vamos dar uma rápida passada na história da computação moderna.
Os primeiros computadores eletrônicos foram desenvolvidos no meio do século XX, entre 1940 e 1945. Nesta época os computadores ocupavam salas inteiras e o consumo de energia era equivalente a centenas de computadores PC que conhecemos atualmente. Bill Gates nascia em 28 de outubro de 1945, e após 30 anos, em 1975, fundava a Microsoft com Paul Allen.
As décadas de 70 e 80 foram repletas de novidades e as principais empresas que conhecemos hoje foram fundadas neste período. Somente nos Estados Unidos, em 1980 existiam aproximadamente 1 milhões de computadores. Em 1986 esse número pulou para 30 milhões.
Não é difícil de imaginar que na década de 80, nos países do chamado "1º mundo", em algumas empresas e órgãos do governo a governança de TI começava se tornar cada vez mais complexa. E esse é o principal e grande motivador para o nascimento das metodologias de governança - a complexidade de gerenciar os recursos de TI. E a complexidade só aumentou com o passar dos anos.
Quando não se tem um gerenciamento adequado dos recursos de TI os principais sinais são: falta de qualidade do serviço prestado e recursos financeiros mal investidos.
Neste cenário, o conceito do ITIL surgiu no final década de 80, patrocinado pelo governo inglês com o objetivo de desenvolver um framework que pudesse melhorar a qualidade dos serviços de TI e ter uma gerência financeira mais responsável, tanto para o governo como as empresas privadas. Outras empresas e países desenvolveram frameworks de governança similares ao do ITIL no mesmo período, mas nenhum deles obteve o sucesso que o ITIL teve.
Em 1999, as normas do ITIL se tornaram então padrão "de fato" pela instituição BS 15000. Esse marco é muito importante, pois as regras de governança passaram a ser um padrão de referência por orgãos oficiais. Em 2005 a ISO 20000 internacionaliza o padrão de governança. Em outras palavras, esse é o segundo grande motivador para adoção de governança - Uma empresa certificada em padrões de governança internacionais tem mais oportunidades daquelas que não tem. Pois consegue comprovar a sua eficiência na governança de TI.
O terceiro e último motivador para adoção do ITIL é a obrigatoriedade de se adequar as regulamentações dos mercados. Como por exemplo, lei Sarbanes-Oxley de 2002 (SOX), HIPAA - Regulamentação norte-americana que protege informações sobre saúde e Basiléia II - Norma global que rege a adequação de capital de bancos internacionais. As regulamentações é uma forma de garantir um melhor gerenciamento dos recursos de TI e assim dimunir o risco de imprevistos.
Resumindo, necessidade de gerenciar a sempre mais complexo recursos de TI, a obtenção de um diferencial de mercado por meio de um selo que garante a eficiencia da sua empresa e a obrigatoriedade de aderir aos padrões e normas que fomentam um melhor gerenciamento são os três grandes motivadores para adoção do ITIL/MOF nas empresas.
De acordo com o ditado popular “o melhor caminho é aquele que você conhece”, eu também demorei a me aventurar em PowerShell (PSH), devido ao arsenal de scripts em VBS e C# que já tenho desenvolvido. Entretanto, aos poucos estou me rendendo a facilidade e ao poder do PowerShell, que para mim é uma mistura de VBS com C# usando a estrutura do bash.
Dando seqüência ao post que comparava PowerShell (PSH) com C# , neste post pretendo fazer uma comparação entre scripts em PSH com o Visual Basic Script (VBS) e o Windows Script Host (WSH) que são as linguagens mais consolidada entre os profissionais de infra-estrutura para a plataforma Windows.
Seguindo os mesmos moldes do artigo anterior, peguei um script desenvolvido em VBS e o portei para PSH. O script selecionado é utilizado em migração de Active Directory, mais especificamente na migração das estações.
Um arquivo texto contendo o nome das estações que serão migradas é entregue pela equipe de TI. O script então verifica quais estão ligadas por meio de WMI ping, e filtra quais já foram migradas anteriormente, extraindo o nome do domínio de cada uma delas. O resultado é um arquivo texto com as estações que podem migradas naquele momento.
Visual Basic Script
01. On Error Resume Next
02. strComputer = "."
03. Const ForReading = 1
04. Const ForAppending = 8
05. Set objFSO = CreateObject("Scripting.FileSystemObject")
06. Set InputFile = objFSO.OpenTextFile ("C:\temp\computers.txt", ForReading)
07. Set OutputOKtFile = objFSO.OpenTextFile ("C:\temp\pingOK.txt", ForAppending, True)
08. Set OutputNOTOKtFile = objFSO.OpenTextFile ("C:\temp\pingNOTOK.txt", ForAppending, True)
09.
10. Do Until InputFile.AtEndOfStream
11. strRead = InputFile.Readline
12. Set objWMIService = GetObject("winmgmts:\\" & strRead & "\root\cimv2")
13. Set colPings = objWMIService.ExecQuery ("Select * From Win32_PingStatus where Address='" & strRead & "'")
14. For Each pingStatus in colPings
15. If IsNull(pingStatus.StatusCode) or pingStatus.StatusCode<>0 Then
16. OutputNOTOKtFile.WriteLine(strRead)
17. Else
18. Set objWMIComputer = GetObject( "winmgmts:\\" & strRead & "\root\cimv2" )
19. Set colComp = objWMIComputer.ExecQuery( "Select * from Win32_ComputerSystem")
20. For Each compStatus in colComp
21. OutputOKtFile.WriteLine(compStatus.name & " - " & compStatus.domain)
22. Next
23. End If
24. Next
25. Loop
PowerShell v2
01. $fInput=get-content "C:\temp\computers.txt"
02. foreach($strRead in $fInput)
03. {
04. $ALive=get-wmiobject -Query "select * from win32_pingstatus where Address='$strRead'" | Select-Object statuscode
05.
06. if($ALive.statuscode -eq 0)
07. {
08. Get-WmiObject -Class Win32_ComputerSystem -ComputerName $strRead | FT Name,Domain -A -HideTableHeaders| Out-File -Append -Force c:\temp\PingOK.txt
09. }
10. else
11. {
12. $strRead| Out-File -Append -Force c:\temp\PingNOTOK.txt
13. }
14. }
As principais diferenças entre PSH e VBS são:
· No PSH não precisa inicializar e controlar os componentes WMI, AD, File System entre outros, logo o código fica reduzido;
· A estrutura dos cmdlets Verbo-Substantivo (Verb-Noun), permite estruturas genéricas poderosas, como get-content que pode abrir arquivos, e extensões orientadas aos serviços, como Get-ADUser, da extensão do Active Directory;
· O PSH utiliza classes e métodos .NET, enquanto no VBS o seu uso é limitado;
· O PSH requer .Net 2.0 e a sua própria instalação, o VBS é nativo na plataforma Windows;
· O PSH é suportando no Windows XP Service Pack 2, Windows Server 2003, Windows Vista, Windows 7 e Windows Server 2008, enquanto o VBS pode ser executado praticamente em todas os Sistemas Operacionais Windows;
· A quantidade de código desenvolvido em VBS é superior ao do PSH. Encontrar um exemplo pronto na Internet em VBS é (teoricamente) mais fácil.
Em médio/longo prazo eu vejo benefícios claros na adoção e migração de VBS para PSH. A Microsoft vem acrescentando novos recursos e investindo no PSH nos últimos anos. Todos os produtos recém-lançados suportam a nova linguagem para configuração. Por isso, pense duas vezes quando pensar que PSH não vale a pena. Experimente portar seus scripts, e em pouco tempo você vai se surpreender desenvolvendo em PSH.
Essa semana escrevi um post no blog da Comunidade Brasileira de AD da Microsoft com o titulo deste post.
Para quem quiser conferir o post acesse o link: http://blogs.technet.com/brzad/archive/2009/08/12/comparando-c-com-powershell-no-desenvolvimento-de-scripts.aspx
Abraços
Dando continuidade ao post anterior sobre o artigo IT Service Management Metrics that Matter, mais precisamente sobre a métrica Server to System Administration Ratio (Índice do número de servidores por administrador), gostaria de compartilhar algumas experiências e apresentar o modelo que meu colega da Microsoft Canadá (Thanks Craig) utiliza em seus clientes (e logo eu também).
Não é incomum que durante algumas consultorias alguns clientes me perguntem qual o número ideal de profissionais para gerenciar o seu ambiente de TI. Algumas poucas vezes me apresentaram um número mágico de 25 à 30 servidores/administrador em reuniões. A verdade é que não existe tal número e que vários fatores influenciam a quantidade de servidores/administrador que cada empresa pode adotar.
A métrica servidores/administrador pode ser interpretada de diferentes formas. O modelo que a maioria das empresas emprega, mesmo que inconscientemente, é o de equipes de suporte. O mais comum é utilizar equipes para a plataforma Windows, Unix/Linux e Banco de Dados. Neste caso, o cálculo não leva em conta as equipes de desenvolvimento ou as que mantêm os sistemas internos, bem como as equipes responsáveis pelos processos e gerenciamento de governança.
Eu particularmente não vejo muito sentido em usar essa métrica em empresas com menos de 50 servidores, pois abaixo desse valor o modelo de equipes é geralmente mais otimizado do descrito acima.
A meu ver cada equipe de suporte deve ter o seu próprio índice de servidores/administrador. A empresa pode adotar a média delas como um número oficial se achar necessário. Lembre-se que, por exemplo, os bancos de dados dependem de um ou mais servidores (Windows ou Unix/Linux) e com isso não basta contar apenas o numero de servidores e dividir pela totalidade da equipe de suporte.
O modelo apresentando por Craig utiliza 8 direcionadores que auxiliam a mensurar se o índice de servidores/administrador está adequado. São eles:
- Experiência - Nível de experiência e a quantidade de habilidades da equipe
- Complexidade - Nível de padronização do ambiente
- Quantidade de mudanças - Freqüência de mudança dentro no ambiente
- Maturidade do ambiente - Freqüência de incidentes dentro do ambiente
- Criticidade - Nível de serviço esperado do ambiente
- Dispersão geográfica - Nível de separação dos elementos dentro do ambiente
- Nível de automação - Efetividade das ferramentas de monitoramento e processos de automação
- Maturidade do Processo - Nível de otimização dos processos de suporte
O gráfico abaixo exemplifica melhor esses direcionadores.
Por fim, gostaria de ressaltar que com a virtualização em pleno vapor o número de servidores de uma empresa pode dobrar em poucos meses. Algumas pessoas acreditam que os servidores virtualizados não contam para o índice servidores/administrador. É verdade que gerenciar um ambiente virtual é bem mais fácil que o físico, mas se tomarmos os direcionadores acima, apenas o item "complexidade" se beneficiaria com o ambiente virtual. Logo, não se iludam, servidores virtualizados devem ser sempre levados em conta para o cálculo da métrica.
Gene Kim, Co-Fundador e CTO da Tripware escreveu um artigo muito interessante intitulado IT Service Management Metrics that Matter, onde ele apresenta um estudo das melhores práticas que as empresas mais eficientes aplicam, e principalmente, o que as diferenciam das demais em relação à governança de TI.
O resultado da pesquisa indica que as empresas que tem alta performance em governança monitoram as mudanças e definem conseqüências (administrativas) para aqueles que fazem mudanças não autorizadas. Essa é a principal diferença entre as organizações que tem governança e as que ainda lutam para chegar lá, de acordo com o artigo. (confesso que concordo totalmente com esse ponto!)
Com base nesta informação o artigo estabelece quatro métricas, intituladas como as mais importantes pelo autor, e que direcionam a organização a ser mais eficiente. São elas:
Mean Time to Repair - MTTR (período médio de recuperação) - as organizações mais maduras já sabem que 80% das falhas são decorrentes de mudanças, e 80% do tempo necessário para resolver o problema está relacionado na descoberta e entendimento do que foi mudado. A gestão de mudança bem feita reduz o MTTR e conseqüentemente faz com que o impacto de uma falha seja minimizado.
First Fix Rate (Índice de correção na primeira tentativa) - é a porcentagem de incidentes que são restaurados com êxito na primeira tentativa de correção. Este indicador influência diretamente a disponibilidade do sistema e o MTTR. Ele mede, em outras palavras, quão eficiente é a sua equipe.
Change Success Rate (Índice de mudanças com sucesso) - determina o número de alterações implantadas com êxito, sem criar um incidente ou interrupção do serviço.
Server to System Administration Ratio (Índice do número de servidores por administradores) - Durante a pesquisa realizada por Gene Kim, curiosamente, notou-se que as empresas que apresentavam os melhores índices nos indicadores acima também tinham uma relação maior entre servidores e administradores. Por exemplo, uma empresa com uma taxa de 35 servidores para cada Administrador (35:1), tinha índices piores que as empresas com 125:1. Esta métrica é uma das mais interessantes por ser fácil de calcular e definir a eficácia e eficiência da equipe de TI.
Em relação a esta última métrica, um colega da Microsoft Canadá me passou um método que acredito ser muito útil para ajudar os gerentes de TI a identificar quais são os pontos de melhoria que precisam investir para ter uma melhor relação de servidores/administradores. Entretanto, eu vou deixar esse tema para o meu próximo post.
Existem várias formas de se montar um Dashboard de monitoramento. Tudo depende da audiência e da informação que se deseja obter do dashboard. No post gerenciamento de incidentes, exemplifico um modelo muito útil para a equipe de gerenciamento de problemas e de incidentes, por mostrar erros recorrentes, volumetria, desvio padrão do atendimento, dentre outras informações. Entretanto, para um CIO, esse relatório não apresenta as informações mais relevantes, como por exemplo, a disponibilidade de um serviço crítico, o MTTR (período médio de recuperação) e o MTBF (período médio entre falhas) dos serviços.
A boa notícia é que recentemente foi lançado o Service Level Dashboard for System Center Operations Manager 2007 v2.0, que vem cheio de novos recursos interessantes para criar relatórios, tais como:
- Atualização quase em tempo real - A latência dos dados varia de dois a três minutos, munindo os gerentes de informação necessária para tomar decisão rápida;
- Métricas de service level tracking - Novas métricas facilitam o acompanhamento do MTTR, MTBF e tendências de performance dos serviços monitorados;
- Utilização do SharePoint Services 3.0 - O dashboard agora é acessado via WEB, com isso é possível estabelecer controle de acesso aos relatórios, eliminando a necessidade do gerente ter que utilizar o Operations Manager console;
- Service level objectives (SLOs). A funcionalidade do Service Level Tracking do Operations Manager configura quais são os objetivos de cada aplicativo ou grupo de computadores. Por exemplo, é possível configurar um SLO de disponibilidade para um grupo de servidores ou um serviço específico para 99,9%.
Se tudo que eu disse acima ainda ficou confuso, de uma olhada neste vídeo de 12min. Nada como ver na prática como se configura e utiliza o produto. A documentação e o produto estão disponíveis no site de download Center da Microsoft.
Em relação aos contratos de SLA (Service Level Agreement), um dos pontos mais críticos é a definição de quanto tempo o serviço deve ficar no ar. Agora que está na moda cloud computing, ou serviços na nuvem (Internet), essa informação passa a ser crucial no caso de indisponibilidade do serviço contrado.
Nos casos das organizações que estão definindo os seus contratos, muito cuidado para não pedir um SLA muito agressivo, pois quanto maior o tempo que o serviço deve ficar no ar (uptime), mais dinheiro se gasta com redundância de componentes e dispositivos de tolerância a falhas.
A tabela abaixo mostra a diferença que faz colocar um 9 a mais nos 99% que vemos.
|
|
Dias / ano |
Dias / ano |
Horas / ano |
Minutos / ano |
Horas / mês |
Minutos / mês |
|
|
365 |
365 |
8,760 |
525,600 |
730 |
43,800 |
|
% uptime |
Uptime (dias/ano) |
Downtime (dias/ano) |
Downtime (hours/ano) |
Downtime (minutes/ano) |
Downtime (hrs/mês) |
Downtime (minutes/mês) |
|
99% |
361,35 |
3,65 |
87,6 |
5.256 |
7,3 |
438 |
|
99.9% |
364,635 |
0,365 |
8,76 |
525,6 |
0,73 |
43,8 |
|
99.99% |
364,9635 |
0,0365 |
0,876 |
52,56 |
0,073 |
4,38 |
|
99.999% |
364,99635 |
0,00365 |
0,0876 |
5,256 |
0,0073 |
0,438 |
|
Mudando os Noves |
Aumento de Uptime - dias/ano |
Reduz em downtime - dias/ano |
Reduz em downtime - hours/ano |
Reduz em downtime -minutes/ano |
Reduz em downtime - hrs/mês |
Reduz em downtime -minutos/mês |
|
2 para 3
(.99 para .999) |
3,285 |
3,285 |
78,84 |
4.730,4 |
6,57 |
394,2 |
|
3 para 4 |
0,3285 |
0,3285 |
7,884 |
473,04 |
0,657 |
39,42 |
|
4 para 5 |
0,03285 |
0,03285 |
0,7884 |
47,304 |
0,0657 |
3,942 |
O processo de gerência de configuração (GC) exige uma disciplina rígida para que não ocorra inconsistência dos dados. A dificuldade de encontrar uma ferramenta que se adeque ao processo e ao orçamento, e ter os recursos (pessoal e técnico) para a implantação e operação do CMDB torna, em minha opinião, a gerência de configuração (GC) um dos processos mais complexos a serem implantados.
Em algumas empresas o processo da GC começa sem um escopo delimitado, ou seja, não se focou em um grupo pequeno de serviços, mas em toda a TI. Nesses casos, é comum que um software de inventário (como o SCCM - System Center Configuration Manager) seja utilizado como o ponto de partida do CMDB. Um software de inventário pode alimentar um CMDB, mas faltam funções críticas para que seja bem sucedido na GC.
O objetivo principal de um CMDB é ajudar a organização a compreender as relações entre os componentes de TI e controlar sua configuração. O mais importante para o CMDB não existe em softwares de inventários, que é o relacionamento entre os componentes. Quando os componentes acordados de infra-estrutura, aplicativos associados, plataforma, middleware, rede e armazenamento que compõem a configuração de um serviço são relacionados, a análise de impacto de mudança é mais precisa.
Um software de inventário fornece informações que não são pertinentes para a GC. Por exemplo, qual a finalidade de se armazenar o modelo, marca e CPU de um computador em um CMDB? Essas informações não agregam valor na análise de uma mudança que já foi planejada e definida pelas áreas competentes.
Um CMDB deve conter a funcionalidade de linha do tempo (baseline), que mostra a configuração dos itens de configuração de um sistema em um ponto específico no tempo. Essa função permite o sistema seja reconstruído, após um erro de configuração, em uma data posterior. Dificilmente se encontra essa característica em softwares de inventário.
Outro ponto importante que não é coberto é facilitar/permitir o acesso às informações contidas no banco de dados por outros processos de governança. A quantidade de tabelas e relacionamentos destes produtos praticamente inviabiliza a integração para que os processos de gestão de mudanças e entrega atualize e altere os itens de configuração.
Dados os pontos acima, recomendo fortemente que se utilizem processos automáticos para a atualização dos ICs, extraindo os dados do software de inventário, e não utilizar o software de inventário como um CMDB inicial.
