Archive for the Sem categoria Category

Service-Oriented Architecture (SOA)

Posted in Sem categoria on 2 de agosto de 2014 by editor master

Service-Oriented Architecture (SOA), pode ser traduzido como arquitetura orientada a serviços, e é um estilo de arquitetura de software cujo princípio fundamental prega que as funcionalidades implementadas pelas aplicações devem ser disponibilizadas na forma de serviços.1 2 Frequentemente estes serviços são conectados através de um “barramento de serviços” (enterprise service bus, em inglês) que disponibiliza interfaces, ou contratos, acessíveis através de web services ou outra forma de comunicação entre aplicações.2 3 4 A arquitetura SOA é baseada nos princípios da computação distribuída e utiliza o paradigma request/reply para estabelecer a comunicação entre os sistemas clientes e os sistemas que implementam os serviços.5

Além da perspectiva estritamente técnica, a arquitetura orientada a serviços também se relaciona com determinadas políticas e conjuntos de “boas práticas” que pretendem criar um processo para facilitar a tarefa de encontrar, definir e gerenciar os serviços disponibilizados.6 7

A arquitetura orientada a serviços também se insere em um processo de reorganização dos departamentos de tecnologia da informação das organizações, permitindo um melhor relacionamento entre as áreas que dão suporte tecnológico à empresa e as áreas responsáveis pelo negócio propriamente dito, graças a maior agilidade na implementação de novos serviços e reutilização dos ativos existentes.8 9

Cquote1.svg SOA é uma abordagem arquitetural corporativa que permite a criação de serviços de negócio
interoperáveis que podem facilmente ser reutilizados e compartilhados entre aplicações e empresas.
Cquote2.svg

Introdução

Parece provável supor que a maioria das funcionalidades de um software sejam entregues e consumidas como serviços. Devido à maturidade dos protocolos Web Services e outras tecnologias, o mais provável é que tudo seja realmente implementado através de serviços.

As implementações SOA dependem de uma rede de serviços de software. Serviços incluem baixo acoplamento de unidades e de funcionalidade. Cada serviço implementa uma ação, como preencher um formulário on-line de uma aplicação ou visualizar um extrato bancário de uma conta, ou realizar uma reserva on-line para bilhete de avião. Ao invés de realizar de chamadas diretas para o código fonte, os serviços definem protocolos que descrevem como enviar e receber as mensagens, utilizando descrições em metadados.

Por exemplo, os principais sites da Internet criaram e ainda estão criando formas de interação entre estes sites e o seu blog ou sua página na rede social. Estas interações e trocas de informação serão aprofundadas ainda mais e disponibilizadas através de serviços, facilitando a troca de informações entre duas entidades diferentes. Sendo assim, a interação de uma página na Internet com outra página ou mesmo um software corporativo, ou ainda um aparelho de telefone celular serão muito mais fáceis. O desenho e projeto de novos softwares precisam levar esta ideia em consideração. Já não existem aplicações isoladas. Todas elas acabam trocando informação com outras aplicações.

Os desenvolvedores SOA associam funcionalidades de software (os serviços) aos objetos de forma não-hierárquica. Durante o processo eles utilizam uma ferramenta de software que contém a lista completa de todos serviços disponíveis, suas características e seus significados, com o objetivo de construir uma aplicação utilizando esses recursos.

Programadores fazem amplo uso da linguagem XML para descrição dos tipos e estruturas de dados em SOA. Também baseada em XML, a Web Services Description Language (WSDL) normalmente descreve os serviços, enquanto o protocolo SOAP descreve os protocolos de comunicação, além de outros padrões alternativos, como WADL e REST. SOA depende dos dados e serviços que são descritos por metadados que devem satisfazer os seguintes critérios:

1. Os metadados devem vir de uma forma que os sistemas de software podem usar para configurar dinamicamente a descoberta e a incorporação de serviços definidos, e também para manter a coerência e integridade. Por exemplo, os metadados podem ser utilizados por outros aplicativos, como um catálogo, para executar serviços de autodescoberta, sem modificar o contrato de um serviço funcional.

2. Os metadados devem vir de uma forma que o designer de sistema seja capaz de compreender e gerir com um gasto razoável de custo e esforço.

SOA tem como objetivo permitir que usuários agrupem funcionalidades de forma a obter aplicações dedicadas que serão construídas quase inteiramente a partir de serviços de software pré-existentes. Quanto maior o agrupamento, menor a quantidade de interface necessária para implementar qualquer conjunto de funcionalidade; no entanto, agrupamentos muito grandes são mais difíceis de reutilizar. Cada interface tem uma quantidade de processamento, portanto há que se considerar a performance e a granularidade dos serviços. A grande promessa de SOA sugere que a criação da n-ésima aplicação é baixa, pois todos os serviços necessários para satisfazer aos requisitos da aplicação já existem. No mundo ideal, bastaria coordenar os serviços para produzir uma nova aplicação.

Mas, para SOA operar, nenhuma interação deve existir entre as funcionalidades ou dentro delas. Ao contrário, usuários especificam a interação dos serviços de forma pré-definida com o objetivo de atender aos novos requisistos. Por isso, a necessidade de implementar serviços com mais funcionalidades que funções ou classes tradicionais, e para que o designer da aplicação não se sobrecarregue ao tratar a complexidade de milhares de objetos com granularidade menor.

Os programadores desenvolvem os próprios serviços usando linguagens tradicionais como Java, C, C++, C# ou COBOL. Serviços também podem ser usados como interfaces para sistemas legados, permitindo a mudança de layout de sistemas antigos.

Os serviços SOA são menos acoplados que as funções de bibliotecas de um programa executável. Serviços SOA também rodam sobre ambientes seguros (como Java e .Net) e com outras linguagens de programação que podem gerenciar alocação de memória e exceção, permitir late binding e certo nível de abstração de tipos de dados.

A partir de 2008, um número crescente de empresas de software começaram a oferecer serviços de software para terceiros por uma taxa pré-definida. No futuro, sistemas SOA podem consistir de tais serviços combinados com outros criados de forma personalizada. Essa ação tem o potencial de reduzir os custos sobre os clientes e promover a padronização na indústria de software. Em particular, a indústria do turismo tem agora um conjunto bem-definido e documentado de serviços e dados, o suficiente para permitir que qualquer engenheiro de software razoavelmente competente possa criar software de agência de viagens utilizando os serviços totalmente off-the-shelf.

A arquitetura SOA se apoia na orientação a serviços como princípio fundamental de design. Se um serviço apresenta uma interface simples que abstrai a complexidade envolvida nela, usuários podem utilizar esses serviços sem necessitar de conhecimentos de sua implementação.

Requisitos

A fim de utilizar eficientemente uma SOA, deve-se atender aos seguintes requisitos:

A interoperabilidade entre diferentes sistemas e linguagens de programação fornece a base para a integração entre aplicações em diferentes plataformas, através de um protocolo de comunicação. Um exemplo dessa comunicação depende do conceito de mensagens. Usando mensagens, através de canais de mensagens definidos, diminui a complexidade da aplicação final, permitindo que o desenvolvedor do aplicativo se concema de banco de dados compartilhado. Isto permite que novas funcionalidades sejam desenvolvidas para um formato de negócio de referência comum para cada elemento de dados.

Abordagem de Web Services

Web Services (Serviços Web) podem implementar uma arquitetura orientada a serviços. Serviços Web fazem blocos funcionais de construção acessíveis através de protocolos de Internet padrão independente de plataformas e linguagens de programação. Estes serviços podem representar tanto novas aplicações quanto apenas invólucros em torno dos sistemas legados existentes para torná-los em rede ativada.

Cada bloco de construção SOA pode desempenhar um ou ambos os papéis:

Service Provider – O prestador de serviços cria um serviço Web e, eventualmente, publica sua interface e acesso a informação para o registro de serviços. Cada fornecedor deve decidir quais os serviços irá expor, como fazer trade-offs entre a segurança e a facilidade de acesso, como preço dos serviços, ou (se nenhuma taxa extra), como e se a explorá-los para outro valor. O provedor também tem que decidir em qual categoria os serviços devem ser listados em um dado serviço de broker e que tipo de acordos com parceiros comerciais são obrigados a usar o serviço. Ele registra que os serviços estão disponíveis dentro dele, e as listas de todos os beneficiários potenciais do serviço. O implementador do corretor, então, decide o âmbito do corretor. Corretores públicos estão disponíveis através da Internet, enquanto intermediários privados só são acessíveis a um público limitado, por exemplo, os usuários de uma intranet da empresa. Além disso, a quantidade de informações oferecidas tem de ser decidido. Alguns corretores especializados em muitas listas. Outros oferecem altos níveis de confiança nos serviços listados. Algumas cobrem um amplo panorama de serviços e outros, o foco dentro de uma indústria. Alguns corretores catálogam outros. Dependendo do modelo de negócio, os corretores podem tentar maximizar o look-up dos pedidos, o número de anúncios ou exatidão dos anúncios. O Universal Description Discovery and Integration (UDDI) define uma maneira de publicar e descobrir informações sobre os serviços da Web. Outros serviços incluem (por exemplo) ebXML (Electronic Business utilizando eXtensible Markup Language) e aqueles baseados na ISO / IEC 11179 Metadata Registry (MDR) padrão.

Atendimento ao consumidor – O consumidor de serviços ou cliente do serviço web localiza entradas no registro do corretor para encontrar as operações e, em seguida, liga-se ao prestador do serviço para invocar um de seus serviços de web. Seja qual for o serviço a serviço, os consumidores precisam, eles têm que levá-la para o corretor, em seguida, vinculá-lo com o respectivo serviço e usá-lo. Eles podem acessar vários serviços, se o serviço oferece vários serviços.

Acoplamento

É o nível de interdependência entre os módulos de um sistema. Uma das características do SOA é o baixo acoplamento. Um módulo é considerado coeso quando possui uma atividade bem definida. Diferentemente do que as pessoas pensam, SOA não se trata de uma simples invenção. A arquitetura orientada a serviços nada mais é que a evolução natural da arquitetura de sistemas tradicional para solucionar as necessidades de desenvolvimento e capacidade de adaptação às novas demandas de mercado, que se faz cada vez mais exigente em qualidade e agilidade.

Serviço

Um serviço, do ponto de vista da arquitetura SOA, é uma função de um sistema computacional que é disponibilizado para outro sistema. Um serviço deve funcionar de forma independente do estado de outros serviços, exceto nos casos de serviços de processos (process services)10 , e deve possuir uma interface bem definida. Normalmente, a comunicação entre o sistema cliente e aquele que disponibiliza o serviço é realizada através de web services.

Processos

Cquote1.svg Mais do que uma tecnologia, SOA também influencia regras e processos de negócios,
além de muitas vezes implicar reengenharia de software simultaneamente.
Cquote2.svg

A Arquitetura Orientada a Serviços pode ser bem representada a partir do seguinte processo, chamado de “find-bind-execute paradigm” o que significa aproximadamente paradigma de “procura-consolida-executa”. Tal conceito é análogo a “Ciclo de Deming” aplicado aos serviços, que define o ciclo que envolve o planejamento, a execução, o monitoramento e a tomada de ação pró ativa para a melhoria da qualidade.

Esquema adaptado do paradigma “find-bind-execute”

Tecnicamente falando, o processo preconiza que os provedores de serviços registrem informações em um registro central, com suas características, indicadores, e aspectos relevantes às tomadas de decisões. O registro é utilizado pelo cliente para determinar as características dos serviços necessários, e se o mesmo estiver disponível no registro central, como por exemplo por um catálogo de serviços, o cliente poderá utilizá-lo, sendo este oficializado através de um contrato que enderece este serviço.

Tecnologia

O termo “Service-Oriented Architecture” (SOA) ou Arquitetura Orientada a Serviços expressa um conceito no qual aplicativos ou rotinas são disponibilizadas como serviços em uma rede de computadores (Internet ou Intranets) de forma independente e se comunicando através de padrões abertos. A maior parte das implementações de SOA se utilizam de Web services (SOAP , REST e WSDL). Entretanto, uma implementação de SOA pode se utilizar de qualquer tecnologia padronizada baseada em web.

Definições de SOA

O SOA coloca a prestação de serviço como eixo de todo o negócio, dando destaque à gestão de serviços e ao cliente.

Termo Definição / Comentário
Serviço É uma função independente, sem estado (stateless) que aceita uma ou mais requisições e devolve uma ou mais respostas através de uma interface padronizada e bem definida. Serviços podem também realizar partes discretas de um processo tal como editar ou processar uma transação. Serviços não devem depender do estado de outras funções ou processos. A tecnologia utilizada para prover o serviço, tal como uma linguagem de programação, não pode fazer parte da definição do serviço.
Orquestração Processo de sequenciar serviços e prover uma lógica adicional para processar dados. Não inclui uma representação de dados.
Stateless Não depende de nenhuma condição pré-existente. Os serviços não devem depender de condições de outros serviços. Eles recebem todas as informações necessárias para prover uma resposta consistente. O objetivo de buscar a característica de stateless dos serviços é possibilitar que o consumidor do serviço possa sequenciá-lo, ou seja, orquestrá-los em vários fluxos (algumas vezes chamados de pipelines) para executar a lógica de uma aplicação.
Provedor O recurso que executa o serviço em resposta a uma requisição de um consumidor.
Consumidor É quem consome ou pede o resultado de um serviço fornecido por um provedor.
Descoberta SOA se baseia na capacidade de identificar serviços e suas características. Conseqüentemente, esta arquitetura depende de um diretório que descreva quais os serviços disponíveis dentro de um domínio.
Binding A relação entre os serviços do provedor e do consumidor deve ser idealmente dinâmica; ela é estabelecida em tempo de execução através de um mecanismo de binding.

Fundamentos de SOA

Como serviços encapsulam a lógica

Pode ser em contextos distintos. Estes contextos podem ser específicos para uma tarefa de negócio, entidades de negócio e outros agrupamentos de negócio.

Serviços podem encapsular a lógica de outros serviços “find-bind-execute”

Na figura, quando construímos uma solução consistente de serviço, cada serviço pode encapsular a tarefa realizada por um passo individual ou um sub-processo composto de um conjunto de passos. Um serviço pode encapsular toda a lógica do processo. O último caso representado pelo serviço pode englobar a lógica encapsulada de outros serviços.

Como serviços são relacionados

Serviços podem encapsular a lógica de outros serviços “find-bind-execute”

Dentro do SOA serviços podem ser usados por outros serviços ou por outros programas. Independentemente, o relacionamento por trás do serviço é baseado no entendimento que os serviços possam interagir. Eles devem estar atentos ao outro. Esta consciência é obtida através do uso da descrição do serviço.

Como serviços se comunicam

Quando as mensagens são enviadas eles perdem o controle do que acontece depois. Essas mensagens podem ser equipadas com inteligência suficiente para auto-governar as partes lógicas do processamento.

Serviços podem encapsular a lógica de outros serviços “find-bind-execute”

Esta arquitetura é similar ao passado da arquitetura distribuída que suporta mensagens e separação de interface de processamento lógico. O que distingue é como esses três componentes fundamentais (serviço, descrição e mensagem) são projetados. Onde entra a orientação de serviços.

Como serviços são projetados

Serviços podem encapsular a lógica de outros serviços “find-bind-execute”

Acoplamento: busca-se um fraco acoplamento. Contrato de serviço: meio de acesso a esse serviço. Autonomia: serviços têm controle sobre a lógica que a encapsulam. Abstração: além do que é descrito no contrato de serviço, serviços escondem a lógica do mundo exterior. Reusabilidade: a lógica é dividida no serviço com a intenção de reuso. Agregabilidade: coleções de serviços podem ser coordenados e montados em forma de serviços compostos. Stateless: serviços minimizam a retenção da informação em determinada atividade. Descoberta: serviços são projetados para ser exteriormente descrito, para que possam ser encontrados e avaliados através de mecanismos de descobertas disponíveis.

Como serviços são construídos A obtenção do SOA não exige serviço web, mas SOA pode e deve ser realizada através do uso da plataforma de tecnologia de serviço web.

Ver também

Wikiquote
O Wikiquote possui citações de ou sobre: SOA

Referências

  1. SOA Working Group of The Open Group. Definition of SOA (em inglês). Página visitada em 4 de junho de 2007.
  2. Boris Lublinsky. Defining SOA as an architectural style (em ingles). Página visitada em 4 de junho de 2007.
  3. Dirk Krafzig, Karl Banke, Dirk Slama. Enterprise SOA: Service-Oriented Architecture Best Practices. 1 ed. Estados Unidos da América: Prentice Hall, 2004. ISBN 0131465759
  4. Martin Keen, Susan Bishop, Alan Hopkins, Sven Milinski, Chris Nott, Rick Robinson, Jonathan Adams, Paul Verschueren, Amit Acharya. Patterns: Implementing an SOA using an Enterprise Service Bus (em inglês). Página visitada em 4 de junho de 2007.
  5. Raghu R. Kodali. What is service-oriented architecture? (em inglês). Página visitada em 4 de junho de 2007.
  6. Bobby Woolf. Introduction to SOA governance (em inglês). Página visitada em 4 de junho de 2007.
  7. OASIS. Reference Model for Service Oriented Architecture 1.0 (em inglês). Página visitada em 4 de junho de 2007.
  8. Chris Harding, The Open Group. Achieving Business Agility through Model-Driven SOA. Página visitada em 4 de junho de 2007.
  9. Rich Rogers. Reuse engineering for SOA. Página visitada em 4 de junho de 2007.
  10. Nicolai M. Josuttis, SOA in Practice The Art of Distributed System Design.

Ligações externas

Processos ITIL Principais

Posted in Sem categoria on 2 de agosto de 2014 by editor master

 

Os principais processos e função do ITIL para suportar o gerenciamento de serviços de TI são:

Gerenciamento de serviços de TI

Posted in Sem categoria on 2 de agosto de 2014 by editor master

 

Origem: Wikipédia, a enciclopédia livre.
NoFonti.svg
Este artigo ou secção cita uma ou mais fontes fiáveis e independentes, mas ela(s) não cobre(m) todo o texto (desde agosto de 2011).
Por favor, melhore este artigo providenciando mais fontes fiáveis e independentes e inserindo-as em notas de rodapé ou no corpo do texto, conforme o livro de estilo.
Encontre fontes: Googlenotícias, livros, acadêmicoScirusBing. Veja como referenciar e citar as fontes.

O gerenciamento de serviços de TI tem por objetivo prover um serviço de TI com qualidade e alinhado às necessidades do negócio, buscando sempre uma redução de custos a longo prazo.1

Os serviços de TI devem atender às necessidades de negócios das organizações que são diferentes uma das outras devido a práticas e ramo de atuação. Porém a construção de serviços de TI de modo singular possui custos mais elevados de produção que podem tirar a competitividade das organizações. O tempo de desenvolvimento pode não atender as necessidades de mercado, não sendo raras as vezes que um serviço de TI é liberado e as necessidades de mercado já foram alteradas. Em certos casos para atender os tempos requeridos pelo mercado a qualidade dos serviços de TI é reduzida, através da redução do seu ciclo de desenvolvimento, prejudicando seu desempenho futuro ou mesmo, inibindo a sua reutilização para a composição de outros serviços de TI. Uma fábrica de serviços de TI tem o objetivo de resolver alguns desses problemas.

Processos ITIL Principais

Os principais processos e função do ITIL para suportar o gerenciamento de serviços de TI são:

Referências

  1. IT Service Management Forum (2002). van Bon, J.. ed. IT Service Management: An Introduction. Van Haren Publishing. ISBN 9080671347

COBIT

Posted in Sem categoria on 2 de agosto de 2014 by editor master

 

Origem: Wikipédia, a enciclopédia livre.

COBIT®, do inglês, Control Objectives for Information and related Technology, é um guia de boas práticas apresentado como framework, teste dirigido para a gestão de tecnologia de informação (TI).1 Mantido pelo ISACA (Information Systems Audit and Control Association), possui uma série de recursos que podem servir como um modelo de referência para gestão da TI, incluindo um sumário executivo, um framework, objetivos de controle, mapas de auditoria, ferramentas para a sua implementação e principalmente, um guia com técnicas de gerenciamento.1 Especialistas em gestão e institutos independentes recomendam o uso do CobiT como meio para otimizar os investimentos de TI, melhorando o retorno sobre o investimento (ROI) percebido, fornecendo métricas para avaliação dos resultados (Key Performance Indicators KPI, Key Goal Indicators KGI e Critical Success Factors CSF).

O CobiT independe das plataformas adotadas nas empresas, tal como independe do tipo de negócio e do valor e participação que a tecnologia da informação tem na cadeia produtiva da empresa.

Em dezembro de 2007, foi lançado o COBIT 4.1, com maiores implementações em relação à versão anterior, 3.0, lançada em 2003.2

O COBIT 5 é a atual versão do framework. Uma das principais alterações em relação ao COBIT 4.1 é a integração com outros conjuntos de boas práticas e metodologias, como padrões ISO, ITIL, Val IT, dentre outros.3

O cubo do Cobit

É o modelo que representa como os componentes se inter-relacionam:

cubo do COBIT

Critérios de Informação ou Requisitos de Negócio

  • Efetividade: lida com a informação relevante e pertinente para o processo de negócio, bem como a mesma sendo entregue em tempo, de maneira correta, consistente e utilizável.
  • Eficiência: relaciona-se com a entrega da informação através do melhor uso dos recursos, de forma mais produtiva e econômica.
  • Confidencialidade: proteção das informações confidenciais a fim de se evitar sua divulgação indevida.
  • Integridade: relaciona-se com a fidedignidade e totalidade da informação, bem como sua validade para o negócio.
  • Disponibilidade: relaciona-se a disponibilidade das informações quando esta é exigida para processamento pelo negócio. Também possui relação com a salvaguarda dos recursos necessários e sua capacidade.
  • Conformidade: aderência a leis, regulamentos e obrigações contratuais relacionadas ao negócio.
  • Confiabilidade: relaciona-se com a entrega da informação apropriada para tomada de decisão.

Recursos de TI

  • Aplicações
  • Informações
  • Infraestrutura
  • Pessoas

Processos de TI

  • Dominios
  • Processos
  • Atividades

Estrutura do CobiT

CobiT cobre quatro domínios, os quais possuem 34 processos, e estes processos possuem 210 objetivos de controle:

  • Planejar e Organizar
  • Adquirir e Implementar
  • Entregar e Suportar
  • Monitorar e Avaliar

Planejar e Organizar

O domínio de Planejamento e Organização cobre o uso de informação e tecnologia e como isso pode ser usado para que a empresa atinja seus objetivos e metas. Ele também salienta que a forma organizacional e a infraestrutura da TI devem ser consideradas para que se atinjam resultados ótimos e para que se gerem benefícios do seu uso. A tabela seguinte lista os processos de TI para o domínio do Planejamento e Organização.

PROCESSOS DE TIPlanejar e Organizar

PO1 Definir um Plano Estratégico de TI 6 OCs
PO2 Definir a Arquitetura de Informação 4 OCs
PO3 Determinar o Direcionamento Tecnológico 5 OCs
PO4 Definir os Processos, Organização e Relacionamentos de TI 15 OCs
PO5 Gerenciar o Investimento em TI 5 OCs
PO6 Comunicar as Diretrizes e Expectativas da Diretoria 5 OCs
PO7 Gerenciar os Recursos Humanos de TI 8 OCs
PO8 Gerenciar a Qualidade 6 OCs
PO9 Avaliar e Gerenciar os Riscos de TI 6 OCs
PO10 Gerenciar Projetos 14 OCs

Adquirir e Implementar

Para executar a estratégia de TI, as soluções de TI precisam ser identificadas, desenvolvidas ou adquiridas, implementadas e integradas ao processo de negócios. Além disso, alterações e manutenções nos sistemas existentes são cobertas por esse domínio para assegurar que as soluções continuem a atender aos objetivos de negócios. Este domínio tipicamente trata das seguintes questões de gerenciamento: · Os novos projetos fornecerão soluções que atendam às necessidades de negócios? · Os novos projetos serão entregues no tempo e orçamento previstos? · Os novos sistemas ocorreram apropriadamente quando implementado? · As alterações ocorrerão sem afetar as operações de negócios atuais?

PROCESSOS DE TIAdquirir e Implementar

AI1 Identificar Soluções 4 OCs
AI2 Adquirir e Manter Software Aplicativo 10 OC
AI3 Adquirir e Manter Infraestrutura de Tecnologia 4 OC
AI4 Habilitar Operação e Uso 4 OC
AI5 Adquirir Recursos de TI 4 OC
AI6 Gerenciar Mudanças 5 OC
AI7 Instalar e Homologar Soluções e Mudanças 9 OC

Entregar e Suportar

O domínio Entregar e Suportar foca aspectos de entrega de tecnologia da informação. Cobre a execução de aplicações dentro do sistema de TI e seus resultados, assim como os processos de suporte que permitem a execução de forma eficiente e efetiva. Esses processos de suporte também incluem questões de segurança e treinamento. A seguir, a tabela com os processos de TI desse domínio.

PROCESSOS DE TIEntregar e Suportar

DS1 Definir e Gerenciar Níveis de Serviço 6 OC
DS2 Gerenciar Serviços de Terceiros 4 OC
DS3 Gerenciar Capacidade e Desempenho 5 OC
DS4 Assegurar Continuidade de Serviços 10 OC
DS5 Assegurar a Segurança dos Serviços 11 OC
DS6 Identificar e Alocar Custos 4 OC
DS7 Educar e Treinar Usuários 3 OC
DS8 Gerenciar a Central de Serviço e os Incidentes 5 OC
DS9 Gerenciar a Configuração 3 OC
DS10 Gerenciar os Problemas 4 OC
DS11 Gerenciar os Dados 6 OC
DS12 Gerenciar o Ambiente Físico 5 OC
DS13 Gerenciar as Operações 5 OC

Monitorar e Avaliar

O domínio de Monitorar e Avaliar lida com a estimativa estratégica das necessidades da companhia e avalia se o atual sistema de TI atinge os objetivos para os quais ele foi especificado e controla os requisitos para atender objetivos regulatórios. Ele também cobre as questões de estimativa, independentemente da efetividade do sistema de TI e sua capacidade de atingir os objetivos de negócio, controlando os processos internos da companhia através de auditores internos e externos.

PROCESSOS DE TIMonitorar e Avaliar

ME1 Monitorar e Avaliar o Desempenho 6 OC
ME2 Monitorar e Avaliar os Controles Internos 7 OC
ME3 Assegurar a Conformidade com Requisitos Externos 5 OC
ME4 Prover a Governança de TI 7 OC

Estrutura de cada processo

Cada processo do CobIT deve descrever as seguintes características:

  • Nome do processo
  • Descrição do processo
    • Critérios de informação
    • Declaração genérica de ações
      • Indicadores de performance
    • Recursos de TI envolvidos
    • Objetivos de controle detalhados
    • Diretrizes de gerenciamento
      • Entradas
      • Saídas
      • Matrizes de responsabilidade
      • Objetivos e métricas
    • Modelo de maturidade

Notas e referências

Ver também

Referências

ITILv3

Posted in Sem categoria on 2 de agosto de 2014 by editor master

 

Origem: Wikipédia, a enciclopédia livre.

A versão 3 da biblioteca ITIL foi lançada mundialmente em maio de 2007 como uma atualização completa da antiga versão 2 (ITILV2), publicada na década de 90 do século passado.

Processos

O ITIL V3 possui exatos 26 processos, listados a seguir nominalmente e agrupados de acordo com o estágio do ciclo de vida de serviço (volumes) a que pertencem.

Processo Publicação Extensão Estágio do Ciclo de Vida de Serviço Processo
Avaliação ST Estratégias de Serviço
(Service Strategies)
Geração de Estratégia
Cumprimento de Requisição SO Gerenciamento Financeiro
Geração de Estratégia SS Gerenciamento de Portfólio de Serviço
Gerenciamento da Capacidade SD SO, CSI Gerenciamento da Demanda
Gerenciamento da Configuração e de Ativo de Serviço ST SO Desenho de Serviço
(Service Design)
Gerenciamento da Capacidade
Gerenciamento da Continuidade do Serviço de TI SD CSI Gerenciamento da Continuidade do Serviço de TI
Gerenciamento da Demanda SS SD Gerenciamento da Disponibilidade
Gerenciamento da Disponibilidade SD CSI Gerenciamento de Fornecedor
Gerenciamento de Acesso SO Gerenciamento de Segurança da Informação
Gerenciamento de Evento SO Gerenciamento do Catálogo de Serviço
Gerenciamento de Fornecedor SD Gerenciamento do Nível de Serviço
Gerenciamento de Incidente SO CSI Transição de Serviço
(Service Transition)
Avaliação
Gerenciamento de liberação e Implantação ST SO Gerenciamento da Configuração e de Ativo de Serviço
Gerenciamento de Mudança ST Gerenciamento de liberação e Implantação
Gerenciamento de Portfólio de Serviço SS SD Gerenciamento de Mudança
Gerenciamento de Problema SO CSI Gerenciamento do Conhecimento
Gerenciamento de Segurança da Informação SD SO Planejamento e Suporte da Transição
Gerenciamento do Catálogo de Serviço SD SS Validação e Teste de Serviço
Gerenciamento do Conhecimento ST CSI Operação de Serviço
(Service Operation)
Cumprimento de Requisição
Gerenciamento do Nível de Serviço SD CSI Gerenciamento de Acesso
Gerenciamento Financeiro SS Gerenciamento de Evento
Mensuração de Serviços CSI Gerenciamento de Incidente
Planejamento e Suporte da Transição ST Gerenciamento de Problema
Processo de Melhoria em 7 Etapas CSI Melhoria Contínua de Serviço
(Continual Service Improvement)
Mensuração de Serviços
Relatório de Serviço CSI Processo de Melhoria em 7 Etapas
Validação e Teste de Serviço ST Relatório de Serviço

Volumes do ITIL V3

O ITIL V3, publicado em maio de 2007, e atualizado em 2011, é composto de cinco volumes, estágios do ciclo de vida de serviço, detalhados abaixo:

Estratégia do serviço (Service Strategy)

Como ponto de origem do ciclo de vida de serviço ITIL, o volume sobre estratégia do serviço é um guia sobre como tornar mais claro e priorizar investimentos sobre provimento de serviços.

Os pontos chaves sobre este volume são:

  • Definição do valor do serviço;
  • Ativos do serviço (service assets);
  • Análise de mercado;
  • Tipos de provimento de serviço.

Processos neste volume incluem:

  • Gerenciamento de Estratégia para Serviços de TI
  • Gerenciamento de portfólio (ou carteira) de serviços;
  • Gerenciamento financeiro de serviços de TI;
  • Gerenciamento de demandas;
  • Gerenciamento do relacionamento com o negócio (atualização 2011).

Desenho de serviço (Service Design)

Desenho, com ITIL, é englobar todos os elementos relevantes à entrega de serviços de tecnologia, ao invés de focar somente no projeto da tecnologia propriamente dita. Assim, projeto de serviços aponta como uma solução planejada de serviço interage com o negócio e ambiente técnico.

Com ITIL, trabalho de projetar um serviço de TI é agregado em um simples pacote de projeto de serviços (Service Design Package – SDP). SDP, em conjunto com outros serviços de informação, são gerenciados com um catálogo de serviços.

Processos inclusos neste volume:

  • Gerenciamento de catálogo de serviços;
  • Gerenciamento de fornecedores;
  • Gerenciamento do nível de serviço (Service Level Management – SLM);
  • Gerenciamento de disponibilidade;
  • Gerenciamento de capacidade;
  • Gerenciamento de continuidade de serviços de TI;
  • Gerenciamento de segurança da informação;
  • Coordenação do Desenho do Serviço.

Transição do serviço (Service Transition)

Este volume é direcionado à entrega dos serviços necessários ao negócio no uso operacional, e geralmente englobam o “projeto”.

Os processos deste volume incluem:

  • Gerenciamento de configurações e ativos de serviço
  • Planejamento de transição e suporte
  • Gerenciamento de liberação e entrega (release and deployment)
  • Gerenciamento de mudança (Change Management)
  • Gerenciamento de conhecimento
  • Papéis da equipe engajada na transição do serviço.

Operação do serviço (Service Operation)

Parte do ciclo de vida onde serviços e valor são entregues diretamente. Assim, monitoramento de problema e balanceamento entre disponibilidade de serviço e custo, etc, são considerados.

Processos inclusos são:

  • Balanceamento do conflito das metas (disponibilidade vs custo, etc).
  • Gerenciamento de eventos.
  • Gerenciamento de incidentes.
  • Gerenciamento de problemas.
  • Cumprimento dos pedidos.
  • Gerenciamento de acesso, (service desk).

Melhoria contínua do serviço (Continual Service Improvement)

A meta do CSI (Continual Service Improvement) é ajustar e reajustar serviços de TI às mudanças contínuas do negócio através da identificação e implementação de melhorias aos serviços de TI que apoiam processos negociais.

Para gerenciar melhorias, o CSI deve definir claramente o que deve ser controlado e medido..

Conjunto de livros

Versões eletrônicas (eBook):

Versões Impressas:

Complementos

Ver também

Ligações externas

Simple Network Management Protocol

Posted in Sem categoria on 2 de agosto de 2014 by editor master

Origem: Wikipédia, a enciclopédia livre.
Question book.svg
Esta página ou secção não cita nenhuma fonte ou referência, o que compromete sua credibilidade (desde abril de 2012).
Por favor, melhore este artigo providenciando fontes fiáveis e independentes, inserindo-as no corpo do texto por meio de notas de rodapé. Encontre fontes: Googlenotícias, livros, acadêmicoScirusBing. Veja como referenciar e citar as fontes.
Protocolos Internet (TCP/IP)
Camada Protocolo
5.Aplicação HTTP, SMTP, FTP, SSH, Telnet, SIP, RDP, IRC, SNMP, NNTP, POP3, IMAP, BitTorrent, DNS, Ping
4.Transporte TCP, UDP, RTP, SCTP, DCCP
3.Rede IP (IPv4, IPv6) , ARP, RARP, ICMP, IPsec
2.Enlace Ethernet, 802.11 WiFi, IEEE 802.1Q, 802.11g, HDLC, Token ring, FDDI, PPP,Switch ,Frame relay,
1.Física Modem, RDIS, RS-232, EIA-422, RS-449, Bluetooth, USB, …

O protocolo SNMP (do inglês Simple Network Management Protocol TRIPA 2 – Protocolo Simples de Gerência de Rede) é um protocolo, da camada de aplicação, de gerência típica de redes IP, que facilita o intercâmbio de informação entre os dispositivos de rede, como placas e comutadores (em inglês: switches). O SNMP possibilita aos administradores de rede gerenciar o desempenho da rede, encontrar e resolver seus eventuais problemas, e fornecer informações para o planejamento de sua expansão, dentre outras.

O software de gerência de redes não segue o modelo cliente-servidor convencional pois para as operações GET e SET a estação de gerenciamento se comporta como cliente e o dispositivo de rede a ser analisado ou monitorado se comporta como servidor, enquanto que na operação TRAP ocorre o oposto, pois no envio de alarmes é o dispositivo gerenciado que toma iniciativa da comunicação. Por conta disso, os sistemas de gerência de redes evitam os termos ‘cliente’ e ‘servidor’ e optam por usar “gerente” para a aplicação que roda na estação de gerenciamento e “agente” para a aplicação que roda no dispositivo de rede.

Gerência de redes

O programa gerente da rede é a entidade responsável pelo monitoramento e controle dos sistemas de hardware e software que compõem a rede, e o seu trabalho consiste em detectar e corrigir problemas que causem ineficiência (ou impossibilidade) na comunicação e eliminar as condições que poderão levar a que o problema volte a surgir.

A gerência de uma rede pode não ser simples, dada sua heterogeneidade em termos de hardware e software, e de componentes da rede, por vezes incompatíveis. As falhas intermitentes, se não forem detectadas, podem afetar o desempenho da rede. Um software de gerência de redes permite ao gestor monitorar e controlar os componentes da sua rede.

Componentes Básicos do SNMP

Uma rede gerida pelo protocolo SNMP é formada por três componentes chaves:

  1. Dispositivos Geridos
  2. Agentes
  3. Sistema de Gerenciamento de Redes (NMS – Network-Management Systems)

Um Dispositivo Gerido é um nó de rede que possui um agente SNMP instalado e se encontra numa rede gerida. Estes dispositivos colectam e armazenam informações de gestão e mantém estas informações disponíveis para sistemas NMS através do protocolo SNMP. Dispositivos geridos, também às vezes denominados de dispositivos de rede, podem ser routers, servidores de acesso, impressoras, computadores, servidores de rede, switches, dispositivos de armazenamento, dentre outros.

Um Agente é um módulo de software de gestão de rede que fica armazenado num Dispositivo Gerido. Um agente tem o conhecimento das informações de gestão locais e traduz estas informações para um formato compatível com o protocolo SNMP.

Um sistema NMS é responsável pelas aplicações que monitoram e controlam os Dispositivos Geridos. Normalmente é instalado num (ou mais que um) servidor de rede dedicado a estas operações de gestão, que recebe informações (pacotes SNMP) de todos os dispositivos geridos daquela rede.

Arquitetura

O framework SNMP consiste de: Agentes Mestres (Master Agents), Sub-agentes (Subagents) e Estações de Gerenciamento (Management Stations).

Master Agent

O Master Agent em uma rede gerenciada é, na verdade, um software sendo executado em um dispositivo com suporte a SNMP, por exemplo, um roteador, que interage com uma estação de gerenciamento. É o equivalente a um servidor, na comunicação cliente/servidor, ou a um daemon, sob o ponto de vista de sistemas operacionais. Os subagentes são os responsáveis por passarem informações específicas para o Masters Agent.

Subagent

Os subagentes ou subagents são pequenos programas em execução no dispositivo com suporte a SNMP, responsáveis pelo monitoramento de recursos específicos naquele dispositivo, como por exemplo, o status de um link ethernet em um roteador, ou a quantidade de espaço livre em um disco de um servidor. Algumas características dos softwares subagentes são:

  • Coletar informações de objetos gerenciados
  • Configurar parâmetros destes objetos gerenciados
  • Responder a solicitações do software de gerência da rede
  • Gerar alarmes ou traps em determinadas situações

Management Station

O Gerente da Rede ou Estação de Gerenciamento ou ainda Management Station é o componente final da arquitetura de uma solução SNMP. Funciona como um cliente em uma comunicação cliente/servidor. Realiza requisições de informações aos dispositivos gerenciados, que podem ser temporárias ou através de comandos a qualquer tempo. E ainda é o responsável por receber alarmes gerados pelos agentes e gerar saídas para estes alarmes, tais como, alterar (SET) o valor de um determinado parâmetro gerenciado no equipamento, enviar mensagem para o celular do administrador da rede, dentre outras.

O SNMP e o ASN.1

O SNMP é um protocolo padrão usado para gerência de redes, que define os formatos dos pedidos que o Gerente envia para o Agente e os formatos das respostas que o agente retorna, assim como o significado exato de cada pedido e resposta. Uma mensagem SNMP é codificada com um padrão designado de ASN.1 (do inglês: Abstract Syntax Notation.1).

O ASN.1 para permitir a transferência de grandes pacotes, sem desperdiçar espaço em cada transferência, usa uma combinação de tamanho e valor para cada objeto a ser transferido.

Comandos do SNMP

O SNMP não define um grande número de comandos, em lugar disso define duas operações básicas:

  • GET, para obter um valor de um dispositivo
  • SET, para colocar um valor num dispositivo

O comando que especifica uma operação de GET ou SET deve especificar o nome do objeto, que é único.

Podemos definir objetos. No caso de um contador de erros de CRC e uma vez que o SNMP não inclui comandos específicos para fazer reset do contador, uma forma simples é colocar zero no contador. Neste caso, o Gerente faz o GET (leitura) do parâmetro desejado para determinar o estado do dispositivo. As operações que controlam o dispositivo são definidas como efeitos secundários de SET (alterar/gravar valores) em objetos.

Especifica (na versão 1) quatro pacote de unidades de dados (PDU):

  1. GET, usado para retirar um pedaço de informação de gerenciamento.
  2. GETNEXT, usado interativamente para retirar sequências de informação de gerenciamento.
  3. GETBULK, usado para retirar informações de um grupo de objetos.
  4. SET, usado para fazer uma mudança no subsistema gerido.
  5. TRAP, usado para reportar uma notificação ou para outros eventos assíncronos sobre o subsistema gerido.

Nomes de objetos e MIB

Todos os objetos acedidos pelo SNMP devem ter nomes únicos definidos e atribuídos. Além disso, o Gerente e o Agente devem acordar os nomes e significados das operações GET e SET. O conjunto de todos os objetos SNMP é coletivamente conhecido como MIB (do inglês: Management Information Base). O standard SNMP não define o MIB, mas apenas o formato e o tipo de codificação das mensagens. A especificação das variáveis MIB, assim como o significado das operações GET e SET em cada variável, são especificados por um padrão próprio.

A definição dos objetos do MIB é feita com o esquema de nomes do ASN.1, o qual atribui a cada objeto um prefixo longo que garante a unicidade do nome, a cada nome é atribuído um número inteiro. Também, o SNMP não especifica um conjunto de variáveis, e como a definição de objetos é independente do protocolo de comunicação, permite criar novos conjuntos de variáveis MIB, definidos como standards, para novos dispositivos ou novos protocolos. Por isso, foram criados muitos conjuntos de variáveis MIB que correspondem a protocolos como UDP, IP, ARP, assim como variáveis MIB para hardware de rede como Ethernet ou FDDI, ou para dispositivos tais como bridges, switches ou impressoras.

Aspectos de segurança

O SNMP, até a sua versão 2, não suportava qualquer tipo de autenticação, o que o tornava vulnerável a uma série de ameaças de segurança. Tais ameaças incluíam o acesso e modificação não autorizados de dados nas MIBs dos dispositivos gerenciados.

Essa vulnerabilidade do protocolo fez com que diversos fabricantes não implementassem a operação Set, reduzindo o SNMP a uma ferramenta de monitoração apenas.

SNMPv2 e SNMPv3

A versão 2 do SNMP é uma evolução do protocolo inicial. O SNMPv2 oferece uma boa quantidade de melhoramentos em relação ao SNMPv1, incluindo operações adicionais do protocolo, melhoria na performance, segurança, confidencialidade e comunicações Gerente-para-Gerente. A SNMPV3 inclui implementação na segurança ao protocolo como privacidade, autenticação e controle de acesso.

Na prática, as implementações do SNMP oferecem suporte para as múltiplas versões (RFC 3584), tipicamente SNMPv1, SNMPv2c e SNMPv3.

Ligação Externa

Planejamento Estratégico de TI

Posted in Sem categoria on 1 de agosto de 2014 by editor master

Gestão de segurança da informação. 1.1 Normas NBR ISO/IEC 27001. 1.2 NBR ISO/IEC 27002. 1.3 NBR
ISO/IEC 27005. 1.4 ISO/IEC 31000. 2. Gestão de continuidade de negócio.
2.1 Normas NBR ISO/IEC 22301. 3
Gerenciamento de projetos.
3.1 PMBOK 5.0.
3.2 Projetos e organização, dinâmica do escritório de projetos.
4 Gerenciamento de serviços.
4.1 ISO/IEC 20000.
4.2 ITIL v3 atualizada em 2011. Conceitos básicos e objetivos, processos e funções do ITIL v3.
5. Governança de TI.
5.1 COBIT 5. Conceitos básicos, objetivos, domínios,
processos e atividades. 6. Avaliação de Processo. 6.1 Norma NBR ISO/IEC 15504. Estrutura de Medição para
Capacidade de Processo. 7. O ciclo PDCA. 8 Ferramen
tas de análise de ambiente. 8.1 Análise SWOT. 8.2
Análise de Cenários. 8.3 Matriz GUT.
9. Auditoria em TI.
9.1. Processo de Auditoria de TI.
9.2 Processos.
9.3 Grupos de processos e Áreas de conhecimento
Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 236 outros seguidores