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.
Peço que você faça um pequeno teste antes de continuar a ler esse post. Anote em um papel a sua resposta e a de outros colegas para a seguinte pergunta: "O que oficializa o início de um projeto na sua organização?"
Há cinco anos, quando fazia essa pergunta como parte de um levantamento do nível de maturidade da gerência de projetos, a maioria das respostas demonstrava que as pessoas tinham percepções diferentes ou equivocadas de quando um projeto era iniciado na empresa.
Quando o inicio de um projeto não é devidamente oficializado, o mesmo já começa com um problema grave de falha de comunicação e entendimento. Certamente os recursos necessários não serão envolvidos corretamente e a probabilidade de ocorrer atraso, mudança de escopo e aumento de custos é muito alta.
Atualmente, acredito que as empresas estejam mais preparadas devido ao grande número de pessoas que possuem certificações relacionadas à gerência de projetos. Infelizmente, isso não quer dizer que os processos estejam mais fortes ou que não ocorram equívocos sobre o entendimento de quando começa um projeto. Um dos principais benefícios em utilizar as metodologias de gerenciamento de projetos é a utilização de uma nomenclatura única para os artefatos do projeto. Por exemplo, o PMI define o Charter como o documento que oficializa um projeto, e o MSF, o documento de Visão/Escopo.
O documento que oficializa o início de um projeto deve conter uma visão macro do que necessita ser feito. Os detalhes do que fazer e como fazer deverá ser fruto da fase de planejamento. Este documento é um resumo do que se sabe sobre o projeto no seu início.
Um Charter auxilia a:
- Ter um claro direcionamento para o projeto;
- Ter um claro entendimento das expectativas;
- Entender as restrições às quais o projeto está sujeito;
- Saber quanto de risco é aceitável para o projeto;
- Saber os limites de recursos humanos e de gastos para o projeto;
- Saber exatamente quando o projeto termina;
Abaixo um exemplo de seções se que pode conter em um documento de Charter:
- Objetivos do Projeto
- Conecta o projeto aos objetivos estratégicos da organização.
- Apresenta os problemas a resolver ou oportunidades a capturar.
- Produtos do Projeto
- Apresenta, explica ou detalha o produto, serviço, processo ou plano que será produzido.
- Escopo
- Define quais são as macro atividades que serão realizadas pela equipe do projeto.
- Requerimentos
- Lista e explica os requerimentos mais importantes. São as funcionalidades e as funções que se está buscando para cada entregável. Nem todos os requerimentos serão incluídos no charter, apenas os mais importantes.
- Critério de aceitação
Define as condições finais de entrega. Responde as perguntas:
- Como o cliente decidirá que está satisfeito com a entrega final?
- Quais métricas serão usadas?
Limites do Escopo
- Apresenta o alcance do projeto. Onde exatamente o projeto inicia e onde ele termina? O que não está incluído no escopo?
Revisões e aprovações
- Define um calendário para as revisões e aprovações das entregas intermediárias e finais.
Relatórios de Progresso
- Define como será controlado o andamento do projeto. Quais relatórios de progresso a gerência quer do time do projeto? Com que freqüência esses relatórios devem ser produzidos?
Composição do time
- Apresenta a equipe de trabalho. Quem está designado para o time? Quem será o líder do projeto? Algum departamento específico deverá ser envolvido?
Cronograma
- Apresenta o andamento recomendado. Tipicamente, o único cronograma requerido no charter é o das entregas em uma visão geral. O detalhamento do cronograma é realizado na fase de planejamento.
Limite de esforço do time
- Define qual é a quantidade limite de tempo que o time interno do projeto pode despender?
Limite de gasto
- Define, da mesma forma, qual é o orçamento limite para o projeto?
Restrições do Projeto
- Apresenta alguma outra restrição de recursos que o time do projeto deve conhecer?
Prioridades do Projeto
- Apresenta as prioridades do projeto que o time precisa conhecer. Se o time necessitar tomar uma decisão entre mais escopo (mais funcionalidade e mais funções), menores prazos (fazer mais rápido) ou menos dinheiro, quais opções ele pode utilizar?
O charter estabelece a base para todas as atividades de planejamento. O envolvimento correto das pessoas para a confecção, revisão e aprovação economiza tempo e esforço durante o planejamento e garante que o projeto esteja na direção correta. O Charter também é uma ferramenta crucial para o entendimento do projeto por todos os envolvidos e deveria ser entregue a todos os participantes do projeto.
