SLA
Compilado e expandido com base nos artigos e referências da Wikipédia em inglês e alemão.
Um SLA, do inglês Service Level Agreement, ou Acordo de Nível de Serviço (ANS), Contrato de Nível de Serviço [Amazon][IBM][Microsoft] ou Garantia do Nível de Serviço é um compromisso regulamentado entre um provedor (fornecedor) de serviços e um cliente para serviços recorrentes (também chamado na literatura sobre o tema de destinatário) definindo o nível dos serviços fornecidos e esperados. O objetivo é tornar as opções de controle transparentes para o cliente, descrevendo precisamente as características de desempenho asseguradas, como escopo de desempenho, tempo de reação e velocidade de processamento. Aspectos particulares do serviço – qualidade, disponibilidade, responsabilidades – são acordados entre o provedor de serviços e o usuário do serviço.[Kearney][Laudon]
Os SLAs fornecem a base para seus provedores de serviços gerenciados e, se não forem criados com cuidado, não resistem a períodos críticos, deixando impressões duradouras nos relacionamentos com os clientes. Assim, é de suma importância que os SLAs sejam feitos com uma mensagem clara e concisa, indicando os serviços a serem prestados, responsabilidades em cada uma das coordenadas comerciais finais e remediações/penalidades em caso de violação.[Maheshwari]
O componente mais comum de SLA é que os serviços devem ser fornecidos ao cliente, conforme acordado no contrato. Como exemplo, os provedores de serviços de Internet e as empresas de telecomunicações geralmente incluem contratos de nível de serviço dentro dos termos de seus contratos com os clientes para definir o(s) nível(eis) de serviço sendo vendidos em linguagem simples. Neste caso, o SLA normalmente terá uma definição técnica em tempo médio entre falhas (MTBF, mean time between failures), tempo médio para consertar (ou reparar) ou tempo médio para recuperação (MTTR, mean time to recovery); identificando qual parte é responsável por reportar falhas ou pelo pagamento de taxas; responsabilidade por várias taxas de dados; taxa de transferência; flutuações (jitter); ou detalhes mensuráveis semelhantes.
Um componente importante é o nível de serviço, que descreve a qualidade de serviço acordada e contém informações sobre a gama de serviços (por exemplo, tempo, escopo), disponibilidade, tempo de resposta do provedor, etc. Um exemplo típico é a operação de servidores funcionando 24 horas por dia, 7 dias por semana, com uma taxa de falha de, por exemplo, em 24 horas por dia, um máximo de 0,1% ao ano e um tempo de reação de 30 minutos após a notificação da reclamação deve ser garantida por um provedor de serviços externo.[Berger][Ellis][Pulverich][wirtschaftslexikon]
Para objetivar a qualidade de um serviço, o serviço é dividido em diferentes níveis, oferecidos pelo provedor de serviços. Esses níveis de serviço especificam a forma em que um serviço pode ser fornecido.
História e Contexto
Inicialmente, os SLAs vêm do campo de serviços de TI, mas hoje eles são usados para outros serviços, como limpeza de edifícios, manutenção, gerenciamento financeiro, contabilidade, folha de pagamento. Na Alemanha e na Suíça, os SLAs se tornaram conhecidos por meio da ITIL (IT Infrastructure Library, Biblioteca de Infraestrutura de TI).
Os SLAs são parte integrante do gerenciamento de nível de serviço (SLM, service level management). Como parte do processo de gerenciamento de nível de serviço, os SLAs estão sendo constantemente revisados e adaptados para alterar os requisitos de negócios, as condições atuais de mercado e os novos requisitos dos clientes.
Visão geral e definição de termos
Um acordo de nível de serviço é um acordo entre duas ou mais partes, onde um é o cliente e os outros são provedores de serviços. Isto pode ser legalmente formal ou "contrato" informal (por exemplo, relacionamentos internos do departamento). O acordo pode envolver organizações separadas ou equipes diferentes dentro de uma organização. Contratos entre o provedor de serviços e outros terceiros são frequentemente (incorretamente) chamados SLAs – porque o nível de serviço tem sido definido pelo (principal) cliente, não pode haver "acordo" entre terceiros; estes acordos são simplesmente "contratos". Acordos de nível operacional ou OLAs (de operational-level agreements), no entanto, pode ser usado por grupos internos para apoiar SLAs. Se algum aspecto de um serviço não foi acordado com o cliente, não é um "SLA".
O SLA distingue OLA. Um OLA é frequentemente usado para suportar ou proteger um SLA. Uma vez que estes acordos são concluídos entre os departamentos de uma mesma empresa, este Contrato de Apoio (UC, Underpinning Contract) é geralmente apenas para o serviço internamente. Por sua vez é um contrato de hedge de um serviço acordado entre o prestador de serviço e um fornecedor de serviços agindo em seu nome. As dependências existem na medida em que os benefícios garantidos são garantidos pelo apoio a contratos com recursos estrangeiros e estão reativamente ligados uns aos outros através de mecanismos de escalonamento.
O acordo formal com a definição exata dos parâmetros técnicos de um SLA é realizado com a ajuda de Especificação de Nível de Serviço (SLS, Service Level Specification) ou Objetivo de Nível de Serviço (SLO, Service Level Objective). A garantia de serviço (service guarantee) tem um objetivo muito semelhante, mas é prometida a um consumidor de forma padronizada.[Nota 1]
SLAs comumente incluem muitos componentes, desde uma definição de serviços até a rescisão do contrato.[SLA Inf Zone] Para garantir que SLAs são consistentemente atendidos, esses acordos são geralmente elaborados com linhas específicas de demarcação e as partes envolvidas devem reunir-se regularmente para criar um fórum aberto para a comunicação. Recompensas e penalidades aplicadas ao provedor são frequentemente especificadas. A maioria dos SLAs também deixar espaço para a revisão periódica (anual) para serem realizadas alterações.[Shacklett]
Desde o final dos anos 80, os SLAs têm sido usados por operadoras de telefonia fixa. SLAs são tão amplamente utilizados nos dias de hoje que as organizações maiores têm muitos SLAs diferentes existente dentro da própria empresa. Duas unidades diferentes em um script de organização um SLA com uma unidade sendo o cliente e outra sendo o provedor de serviços. Essa prática ajuda a manter a mesma qualidade de serviço entre diferentes unidades na organização e também em vários locais da organização. Este script interno de SLA também ajuda a comparar a qualidade do serviço entre um departamento interno e um provedor de serviços externo.[Ding]
A saída recebida pelo cliente como resultado do serviço prestado é o foco principal do contrato de nível de serviço.
Os acordos de nível de serviço também são definidos em diferentes níveis:
SLA Baseado no Cliente (Customer-based SLA): Um acordo com um grupo de clientes individuais, cobrindo todos os serviços que eles usam. Por exemplo, um SLA entre um fornecedor (provedor de serviços de TI) e o departamento financeiro de uma grande organização para os serviços, tais como sistema financeiro, sistema de folha de pagamento, sistema de faturamento, sistema de aquisição/compras, etc.
SLA Baseado no Serviço (Service-based SLA): Um acordo para todos os clientes que usam os serviços entregues pelo provedor de serviços. Por exemplo:
Um provedor de serviços móveis oferece um serviço de rotina para todos os clientes e oferece certa manutenção como parte de uma oferta com o sistema de carregamento universal.
Um sistema de e-mail para toda a organização. Há chances de dificuldades surgindo neste tipo de SLA de acordo com o nível dos serviços oferecidos que pode variar para diferentes clientes (por exemplo, a equipe da matriz pode usar conexões LAN de alta velocidade enquanto os escritórios locais podem ter que usar uma linha alugada de menor velocidade).
SLA Multinível (Multilevel SLA): O SLA é dividido em diferentes níveis, cada um abordando diferentes conjuntos de clientes para os mesmos serviços, no mesmo SLA.
SLA Nível Corporativo (Corporate-level SLA): Cobrindo todo o gerenciamento de nível de serviço genérico (geralmente abreviado como SLM, service level management) questões apropriadas para cada cliente em toda a organização. Esses problemas provavelmente serão menos voláteis e, portanto, atualizações (revisões SLA) são menos frequentemente requeridas.
SLA Nível de Cliente (Customer-level SLA): cobrindo todas questões SLM relevantes para o grupo de clientes específico, independentemente dos serviços utilizados..
SLA Nível de Serviço (Service-level SLA): cobrindo toda questão SLM relevante aos serviços específicos, em relação a este grupo de clientes específico.
De particular importância na prestação de serviços de rede são os chamados SLAs de desempenho (disponibilidade, tempos de resposta, etc.) que, comparados aos SLAs genéricos, oferecem uma vantagem competitiva significativa, especialmente se estiverem associados a uma espécie de customização do nível parametrizado às necessidades do cliente individual. O monitoramento de SLAs de desempenho, portanto, permite verificar o desempenho dos níveis de serviço em termos de conformidade com os valores-alvo contratuais e a presença de anomalias técnicas e de aplicação que podem causar desserviços ao usuário final. Desse ponto de vista, estamos falando de monitoramento em tempo real dos SLAs cujo gerenciamento envolve o uso de sistemas de alerta que podem relatar on-line a ocorrência de problemas durante a entrega do serviço.
Como exemplo, alguns dos principais indicadores usados como SLA de desempenho são mostrados abaixo:
desempenho de rede;
disponibilidade de componentes do sistema (mainframe, rede, banda, etc.);
disponibilidade do serviço de ponta a ponta;
funcionalidade e tempos de resposta de transações na web.
Componentes
A maioria dos provedores de serviços tem formatos SLA padrão, que são atualizados para cada cliente com alguns detalhes básicos que podem variar para cada cliente. Às vezes, eles têm mais de um modelo para atender a diferentes requisitos de diferentes clientes. Mas eles geralmente são inclinados para os provedores de serviços, então precisam de uma revisão cuidadosa da perspectiva do cliente. Idealmente, um SLA deve ser criado de forma que o padrão não seja recompensador para ambas as partes, e ambos os fins devem ser igualmente envolvidos em seus respectivos domínios. Por exemplo, se o fornecedor atrasar a tarefa, ele poderá ser penalizado, mas e se for causado porque o cliente atrasou certas aprovações? Deve-se definir as expectativas desde o início, através de SLAs cuidadosamente redigidos.[Maheshwari]
Em geral, os SLAs devem incluir todos os aspectos de serviço, gerenciamento e entrega de serviços em todos os níveis, incluindo segregação de deveres e responsabilidades, KPIs (Key Performance Indicators, Indicadores de Nível de Serviço) mensuráveis, plano de comunicação, métricas de escalonamento, plano de mitigação de riscos e término de contratos. Idealmente, deveria ser uma ferramenta usada para medir o desempenho e identificar áreas para melhoria e recursos necessários e, certamente, para não serem usadas como mecanismos de punição para as duas estruturas empresariais conflituarem.[Maheshwari]
Um SLA bem definido e típico conterá os seguintes componentes:[Verma]
Visão geral: Esta seção inclui os princípios básicos do contrato, como nomes das partes envolvidas (geralmente o provedor de serviços e o cliente), data de início da aplicação e ampla introdução de serviços prestados.
Descrição do(s) tipo(s) de serviço(s) a ser(em) fornecido(s): Especifica o tipo de serviço e qualquer detalhe adicional do tipo de serviço a ser prestado. Em caso de conectividade de rede IP, o tipo de serviço descreverá funções tais como operação e manutenção de equipamentos de rede, largura de banda de conexão a ser fornecida, etc.
É necessária a descrição de todos os serviços oferecidos sob todas as circunstâncias possíveis e seus tempos de virada (ou tempo de retorno, turn-around times, TAT, tempo gasto para atender a uma solicitação) definidos em detalhes. No caso de alguns serviços serem oferecidos em casos especiais, eles também devem ser bem definidos. Caso os TATs sejam diferentes em algumas circunstâncias especiais, esta seção deve defini-lo. Quais sistemas são suportados, como os serviços são entregues, horas de operação, serviço de manutenção (se oferecido), dependências de outras pessoas (para aprovações), processos (antes ou depois) e tecnologia (outros aplicativos), todos estes pontos devem ser descritos nesta etapa.
Exclusões e Isenções: Idealmente, o que não é oferecido também deve ser mencionado claramente, não deixando lacuna para a hipótese de qualquer uma das partes.
O nível de desempenho desejado do serviço, especialmente sua confiabilidade e capacidade de resposta: Um serviço confiável será aquele que sofrer interrupções mínimas em um período de tempo específico e estará disponível em quase todos os momentos. Um serviço com boa capacidade de resposta executará a ação desejada imediatamente após o pedido do cliente.
Várias métricas de medição de desempenho devem ser definidas nesta seção. O cliente tem certas expectativas e o provedor de serviços tem determinado processo. Ambas as extremidades devem obter um consentimento mútuo para listar todas as métricas para medir o que o provedor de serviços realizou e definir os níveis de desempenho.
Processo de monitoramento e relatório de nível de serviço: Este componente descreve como os níveis de desempenho são supervisionados e monitorados. Esse processo envolve a coleta de diferentes tipos de estatísticas, a frequência com que essas estatísticas serão coletadas e como essas estatísticas serão acessadas pelos clientes.
Responsabilidades do provedor de serviços e do cliente: não deve haver “terra de ninguém” nem o “campo de todos”. Definir responsabilidades para ambas as partes. Isso certamente evitará qualquer jogo de culpa no futuro.
Medidas gerais de segurança: Para cada dado do cliente é de extrema importância e espera-se que os provedores de serviços tenham todas as medidas de segurança em vigor para manter a integridade de quaisquer dados/informações compartilhadas pelo cliente. Esta seção deve definir claramente quais são as medidas de segurança tomadas ou a serem tomadas pelo provedor de serviços. Não divulgação, anti-caça furtiva, segurança de TI, são alguns que devem ser cuidadosamente redigidos e acordados.
Gerenciamento de Problemas e Processo de Recuperação de Desastres: “Os problemas não são nem convidados nem bem-vindos, mas vêm.” Esse componente especificará os detalhes de contato para relatar o problema e a ordem em que os detalhes sobre o problema devem ser relatados. O contrato também incluirá um intervalo de tempo em que o problema será analisado e também até quando o problema será resolvido.
Deve haver um robusto mecanismo de gerenciamento de problemas e recuperação de desastres que precisa ser claramente comunicado nesta seção.
Resposta e prazo de resolução de problemas: O período de tempo de resposta é o período de tempo durante o qual o provedor de serviços iniciará a investigação do problema. O período de tempo de resolução de problemas é o período de tempo durante o qual o problema de serviço atual será resolvido e corrigido.
Rastreamento de Serviço e Relatórios: O cliente detém os direitos para rastrear os níveis de serviço e desempenho. Com base em termos mutuamente discutidos e acordados, a estrutura de relatórios, intervalos e partes interessadas devem ser definidos nesta seção.
Repercussões para o provedor de serviços que não cumpra seu compromisso: Se o provedor não puder atender aos requisitos estabelecidos no SLA então o provedor de serviços terá que enfrentar as consequências para o mesmo. Essas consequências podem incluir o direito do cliente de rescindir o contrato ou solicitar um reembolso por perdas sofridas pelo cliente devido a falha no serviço.
Revisão Periódica e Processo de Mudança: O acordo de nível de serviço deve ser considerado como um documento dinâmico que precisa ser atualizado com base em poucos fatores externos como - as necessidades do cliente mudaram, o ambiente de trabalho mudou ou as melhores ferramentas e processos evoluíram. O período de revisão e o processo de mudança no SLA devem ser definidos nesta seção para consumo futuro de ambas as partes.
Coordenadas Comerciais: É importante mencionar todas as coordenadas comerciais, juntamente com o preço de cada serviço oferecido, o método de cálculo, com todas as variações possíveis, juntamente com as condições de pagamento.
Rescisão do Processo do Acordo: Sob quais circunstâncias o contrato será rescindido ou expirará, deve ser claramente indicado neste documento, junto com o período de notificação de qualquer um dos lados.
Assinaturas: Partes interessadas relevantes e pessoas autorizadas de ambos os lados devem assinar o documento aprovando todos os detalhes listados, cumprindo as duas partes do acordo até que ele permaneça válido.
Numa listagem mais direta e simplificada, ainda que mais extensa, podemos incluir entre os componentes do conteúdo essencial de um contrato de SLA:
Propósito
Contratante
Revisões de Código (software reviews)[Nota 3]
Histórico de alterações
Especificações
Responsabilidade pelos prestadores de serviços
Beneficiários de responsabilidade
Disponibilidade do serviço
Normas
Agendamento de tarefas / manutenção
Indicadores de Nível de Serviço (KPI, Key Performance Indicators) [Mühlencoert]
Período de medição
Outras definições inerentes à relação das empresas envolvidas e objetos do contrato
Contratos externos
Gestão de escalonamento (Escalation Management)[Nota 4]
Preços (e relacionadas formas de financiamento e impedimentos vinculados a crédito)
Consequências legais em caso de incumprimento (em particular sanções contratuais)
Período do contrato
Assinaturas
A definição de SLAs deve seguir o princípio/critério SMART.[Nota 5] O cliente recebe um serviço fixo nos SLAs (por exemplo, tempos de resposta do suporte, restauração de dados, etc.) a um preço acordado e o contratante garante que ele adere a este contrato.
Uma metodologia de um contrato SLA baseada em melhores práticas por critérios análogos ao SMART. - A partir de EBEX Services Ltd
Com base em todos os componentes necessários a um SLA, podemos definir as melhores práticas para elaborar um documento de acordo completo e confiável para ambas as partes - o fornecer de serviço e o cliente - com base em critérios análogos aos conjuntos de critérios SMART, como por exemplo:[Maheshwari]
Específico - Um SLA deve ser específico e detalhado o suficiente para definir as expectativas de serviços/trabalhos, eliminando com precisão qualquer confusão em ambos os lados.
Quantificado - Os produtos devem ser quantificados para poder medir as entregas em um formato pré-definido.
Mensurável - Deve haver uma maneira de rastrear o desempenho real em relação ao SLA prometido. Todos os serviços devem ser mensuráveis.
Abrangente - O contrato deve cobrir todos os serviços e todas as possíveis obrigações contratuais para todas as partes envolvidas.
Realista - As expectativas definidas no SLA devem ser realistas. Metas irreais e acima dos agentes e suas capacidades podem desmotivar a equipe e a não-entrega levará apenas a falhas nos termos acordados.
Relevante - O SLA deve estar diretamente relacionado ao serviço a ser oferecido e entregue e deve ser relevante para avaliar o desempenho em relação a esse objetivo.
Autorizativo - Este documento de acordo deve ser o documento oficial que vincula ambas as partes.
Prazos - O SLA deve conter um período de tempo em que o serviço será entregue.
Divisão de trabalho - O "Criador" não pode ser um verificador e "Verificador" não pode ser um Criador. A responsabilidade deve ser claramente definida para cumprir a conformidade com legislações, como no caso dos EUA, a SOX.
Métricas de escalonamento - As métricas de escalonamento devem ser claramente definidas. Uma vez que as partes entrem no acordo, o cliente deve estar ciente de quem escalar, caso os serviços não sejam prestados corretamente.
Não técnico - Em vez de usar muitos termos e termos técnicos, deve-se manter a linguagem simples para referência de pessoas não técnicas também. Deve usar uma linguagem simples, facilmente compreensível por todos.
SLAs deve por um lado permitir a criação de uma transparência de preço/performance para os clientes e parceiros, e por outro lado, oferecendo assistência na resolução e prevenção de conflitos – possivelmente comuns – quando a elaboração ou apresentação do SLA esclarecerá as questões críticas.
Métricas comuns
Os contratos de nível de serviço podem conter várias métricas (parâmetros) de desempenho de serviço com objetivos de nível de serviço correspondentes. Um caso comum no gerenciamento de serviços de TI é um call center ou service desk (central de atendimento). Métricas geralmente aceitas nestes casos incluem:
Taxa de abandono (Abandonment Rate): Porcentagem de chamadas abandonadas enquanto aguardam serem respondidas.
ASA (Average Speed to Answer, Velocidade Média de Resposta): Tempo médio (geralmente em segundos) é preciso que uma chamada seja atendida pela central de atendimento.
TSF (Time Service Factor, Fator de Serviço de Tempo): Percentagem de chamadas atendidas dentro de um prazo definido, e.g., 80% em 20 segundos.
FCR (First-Call Resolution, Resolução de Primeira Chamada): Porcentagem de chamadas recebidas que podem ser resolvidas sem o uso de um retorno de chamada ou sem que o caller chame de volta o helpdesk para concluir a resolução do caso.[Desmarais]
TAT (Turn-Around Time, Tempo de Resposta): Tempo gasto para concluir uma determinada tarefa.
MTTR (Mean Time To Recover, Tempo Médio para Recuperar, ou Tempo Médio de Recuperação): Tempo necessário para recuperar após uma interrupção do serviço.
O tempo de atividade (uptime) também é uma métrica comum, geralmente usada para serviços de dados, como hospedagem (hosting) compartilhada, servidores privados virtuais e servidores dedicados. Os “acordos de disponibilidade” são outro tipo de parâmetro muito comum usado em serviços como hospedagem ou servidores dedicados. Acordos comuns incluem porcentagem de tempo de atividade da rede, tempo de consumo de energia, tempos de manutenção, número de janelas de manutenção programada, etc.
Um grande número de SLAs faz referências a especificações ITIL (Information Technology Infrastructure Library, Biblioteca de Infraestrutura de Tecnologias de Informação) quando elas são usadas no campo de serviços de tecnologia da informação.
Em termos gerais, para qualquer processo de negócio - não apenas tecnológico - os Acordos de Nível de Serviço devem refletir claramente dois elementos: descrição dos serviços cobertos pela SLAs e o nível operacional normal. Este último elemento (nível operacional normal) é a grande lacuna de atenção nos níveis de serviço e, no entanto, sem ele, o processo de gerenciamento do nível de serviço não pode ser dado; isto é, o SLA não existe.
Exemplos específicos
Fornecedores de Estrutura de Internet
Não é incomum que um provedor de serviços de estrutura (backbone) de internet (ou provedor de serviços de rede) definir explicitamente seus próprios SLA em seu website.[NTT][Verizon][AT&T] A Lei de Telecomunicações dos EUA de 1996 (U.S. Telecommunications Act of 1996) não exige expressamente que as empresas tenham SLAs, mas fornece um quadro para as empresas a fazê-lo nas Seções (Sections) 251 e 252.[Wikisource] Seção 252(c)(1), por exemplo ("Duty to Negotiate", Dever a Negociar) requer portadores de troca local incumbentes (ILECs, incumbent local exchange carriers) para negociar de boa fé assuntos como revenda e acesso a direitos de rotas.
WSLA
Um contrato de nível de serviço da web (WSLA, web service level agreement) é um padrão para monitoramento de conformidade de acordo de nível de serviço de serviços da web. Ele permite que os autores especifiquem as métricas de desempenho associadas a um aplicativo de serviço da web, metas de desempenho desejadas e ações que devem ser executadas quando o desempenho não é atingido.
WSLA Language Specification (Especificação de Linguagem WSLA), versão 1.0 foi publicado pela IBM em 18 de janeiro de 2001.
Computação em nuvem
O benefício subjacente da computação em nuvem é o compartilhamento de recursos, o qual é suportado pela natureza subjacente de um ambiente de infraestrutura compartilhado. Portanto, SLAs abrangem toda a nuvem e são oferecidos pelos provedores de serviços como um acordo baseado em serviços, em vez de um contrato baseado no cliente. A medição, o monitoramento e a geração de relatórios sobre o desempenho da nuvem são baseados no UX ou sua capacidade de consumir recursos. A desvantagem da computação em nuvem em relação a SLAs é a dificuldade em determinar a causa raiz das interrupções de serviço devido à natureza complexa do ambiente.
Conforme os aplicativos são movidos do hardware dedicado para a nuvem, eles precisam atingir os mesmos níveis de serviço ou ainda mais exigentes do que as instalações clássicas. SLAs para serviços em nuvem, enfocam as características do data center e, mais recentemente, incluem características da rede (ver carrier cloud [Nota 2]) para apoiar SLAs end-to-end (ponta-ponta).[Rueda]
Qualquer estratégia de gerenciamento de SLA considera duas fases bem diferenciadas: negociar o contrato e monitorar seu cumprimento em tempo real. Portanto, a gestão de SLA engloba a definição de contrato de SLA: o esquema básico com os parâmetros de QoS; a negociação de SLA; o monitoramento de SLA; a detecção de violação de SLA; e cumprimento de SLAs — de acordo com as políticas definidas.
O ponto principal é construir uma nova camada sobre a grade, nuvem, ou middleware SOA capaz de criar um mecanismo de negociação entre os provedores e os consumidores de serviços. Um exemplo é o projeto de pesquisa Framework 7 financiado pela UE, SLA@SOI,[Butler] o qual está pesquisando aspectos de SLAs multi-nível, multi-provedor dentro de infra-estrutura orientada a serviços e computação em nuvem, enquanto outro projeto financiado pela UE, VISION Cloud,[Villari] tem fornecido resultados com relação a SLAs orientados por conteúdo.
FP7 IRMOS também investigou aspectos da tradução de termos de SLA em nível de aplicativo para atributos baseados em recursos, em um esforço para preencher a lacuna entre as expectativas do lado do cliente e os mecanismos de gerenciamento de recursos do provedor de nuvem.[Boniface][Cuomo] Um resumo dos resultados de vários projetos de pesquisa na área de SLAs (variando de especificações a monitoramento, gerenciamento e fiscalização) foi fornecido pela European Commission (Comissão Europeia).[Kyriazis]
Terceirização
Terceirização envolve a transferência de responsabilidade de uma organização para um fornecedor. Esse novo arranjo é gerenciado por meio de um contrato que pode incluir um ou mais SLAs. O contrato pode envolver penalidades financeiras e o direito de rescisão se qualquer uma das métricas de SLAs for omitida de forma consistente ou o contrato for violado regularmente. Definir, rastrear e gerenciar SLAs é uma parte importante da disciplina de gerenciamento de relacionamento de terceirização (ORM, outsourcing relationship management[Nota 6]). Os SLAs específicos são tipicamente negociados antecipadamente como parte do contrato de terceirização e usados como uma das principais ferramentas de terceirização da governança no gerenciamento de subcontratação.
No desenvolvimento de software, SLAs específicos podem ser aplicados a contratos de terceirização de aplicativos, de acordo com padrões de qualidade de software, bem como recomendações fornecidas por organizações neutras como a CISQ (Consortium for IT Software Quality, Consórcio para Qualidade de Software de TI), que publicou vários artigos sobre o assunto (tais como Using Software Measurement in SLAs, “Usando a Medição de Software em SLAs” [Curtis]) que estão disponíveis para o público.
Sendo os SLAs usados em contratos de terceirização e centros de serviços compartilhados, devem se acrescentar uma lista de diversas áreas nas quais os SLAs são usados atualmente:
Logística
Gestão de instalações
Aplicativos de e-mail
Planejamento de Recursos Empresariais (ERP)
E-shop / E-Commerce (comércio eletrônico)
Sistemas de faturamento
E-Payroll - “e-folha”, folha de pagamento eletrônica
Serviços de Informação Financeira (FIS, Financial Information Service)
Telecomunicação (telefone fixo ou celular)
Call Center (central de atendimento)
Serviços de recrutamento
Hospedagem / Habitação de Servidores
Computação em nuvem
Gerenciamento de serviços de TI (para aplicativos)
Os acordos de nível de serviço também podem ser usados para uma ampla gama de serviços na área de gerenciamento de edifícios (por exemplo, limpeza e calefação e/ou ar condicionado). Para o contrato de nível de serviço "manutenção" de bens imóveis, a definição de qualidades componentes por meio do método ERAB (Ermittlung des Abnutzungsvorrats von Baustoffen, “determinação do desgaste de estoque de materiais de construção”) é adequada para determinar as variáveis medidas.[Nota 7][Schönfelder] [Facility-Management.de]
Notas
1.Service guarantee
Uma garantia de serviço (service guarantee) é uma ferramenta de marketing que as empresas vêm usando cada vez mais para reduzir a percepção de risco do consumidor, sinalizar a qualidade, diferenciar uma oferta de serviço e institucionalizar e profissionalizar sua gestão interna de reclamação e recuperação de serviço. Ao fornecer garantias de serviço, as empresas concedem aos clientes uma ou mais formas de compensação, ou seja, substituição, reembolso ou crédito fáceis de solicitar, sob as circunstâncias de falha na entrega do serviço. As condições são frequentemente colocadas nessas compensações; no entanto, algumas empresas fornecem-nas incondicionalmente. - en.wikipedia.org - Service guarantee
2.Carrier Cloud
Na computação em nuvem, uma Carrier Cloud (“portador da nuvem” ou “nuvem transportadora”) é uma classe de nuvem que integra redes de longa distância (WAN) e outros atributos das redes de nível de operadora dos provedores de serviços de comunicação para permitir a implantação de aplicativos altamente exigentes na nuvem. Em contraste, a computação em nuvem clássica concentra-se no data center e não aborda a rede que conecta data centers e usuários da nuvem. Isso pode ter resultado em tempos de resposta imprevisíveis e problemas de segurança quando dados críticos de negócios são transferidos pela Internet.
en.wikipedia.org - Carrier cloud
Claudio Oliveira Lopes - O Futuro do Cloud Computing - www.ispblog.com.br
Nos nossos arquivos: docs.google.com
3.Software review
Um software review, ou revisão de software, é "Um processo ou reunião durante a qual um produto de software é examinado por uma equipe de projeto, gerentes, usuários, clientes, representantes de usuários ou outras partes interessadas para comentários ou aprovação". (Definição da IEEE)
Neste contexto, o termo "produto de software" significa "qualquer documento técnico ou documento parcial, produzido como uma entrega de uma atividade de desenvolvimento de software", e pode incluir documentos como contratos, planos de projeto e orçamentos, documentos de requisitos, especificações, projetos, código-fonte, documentação do usuário, documentação de suporte e manutenção, planos de teste, especificações de teste, padrões e qualquer outro tipo de produto de trabalho especializado. - en.wikipedia.org - Software review
4.Escalation Management
Escalation Management (gerenciamento de escalonamento) é amplamente usado para gerenciamento de serviços de TI e também faz parte das recomendações da ITIL. Os processos de escalonamento criados com cuidado podem garantir que os problemas não resolvidos não se demorem e que os problemas sejam resolvidos imediatamente. Critérios de escalonamento, como prazos perdidos, são definidos e resultam em ações apropriadas, como uma mudança de status ou uma notificação para um membro do projeto.
Uma plataforma de Gerenciamento do Ciclo de Vida da Aplicação (Application Lifecycle Management) pode enviar notificações e executar ações automáticas (por meio do fluxo de trabalho de um rastreador - tracker) sempre que usuários (via GUI, graphical user interface, interface gráfica do usuário) e clientes (por meio da API remota - application programming interface, interface de programação da aplicação) enviam e modificam problemas ou determinados eventos ou horários são atingidos.
Com o escalonamento, os rastreadores podem ser configurados de modo que os problemas que atendem aos critérios de escalonamento definidos pelo usuário, ou seja, problemas que precisam de atenção extra, possam ser automaticamente sinalizados, para que possam se tornar mais visíveis em tempo hábil. As condições do acionador de encaminhamento e as ações resultantes são definidas pelo usuário.
As funções, campos, fluxo de trabalho e horário de trabalho, e o cenário onde estas plataformas operam, quando as questões são submetidas antes da data de início e término pretendidas e a data final pretendida, ou pelo menos o número estimado horas (de tempo de trabalho) após a data de início programada, devem ser simuladas antes da implantação, e é recomendável um período de operação experimental, nos quais serão remediados bugs eventuais, inadequações e descobertas variáveis imprevistas, fatores todos a produzirem funções, campos, fluxos de trabalho e horário de trabalho personalizados com o Gerenciamento de Escalação.
codebeamer.com - Escalation Management: Service Level Agreements (SLA)
5.SMART
O SMART é um acrônimo mnemônico, que fornece critérios para guiar no estabelecimento de objetivos, por exemplo, em gerenciamento de projetos, gerenciamento de desempenho de funcionários e desenvolvimento pessoal. As letras S e M geralmente significam específico e mensurável (specific e measurable). Possivelmente, a versão mais comum tem as letras restantes referindo-se a alcançável, relevante e com limite de tempo (achievable, relevant e time-bound). - en.wikipedia.org - SMART criteria
Felipe Andriolo - Método SMART - www.administradores.com.br
- Nos nossos arquivos [ docs.google.com ]
6.ORM
ORM, outsourcing relationship management, gerenciamento de relacionamento de terceirização, é a disciplina de negócios amplamente adotada por empresas e instituições públicas para gerenciar um ou mais prestadores de serviços externos como parte de uma estratégia de terceirização. ORM é um termo amplamente usado que engloba elementos de estrutura organizacional, estratégia de gerenciamento e infraestrutura de tecnologia da informação. - en.wikipedia.org - Outsourcing relationship management
7.ERAB
ERAB, Ermittlung des Abnutzungsvorrats von Baustoffen, “determinação do desgaste de estoque de materiais de construção” é um procedimento de avaliação de depreciação para imóveis baseado na quantificação do valor do desgaste atualizado de materiais usados na construção de uma edificação (ou qualquer construção, como um viaduto ou ponte) na qual uma qualidade mínima de um componente pode ser definido, como por exemplo, um determinado grau de corrosão, ou espessura residual de um piso pelo desgaste, no que é chamado no método de “qualidade de componentes”.
[Facility-Management.de]
Referências
Amazon - «Amazon S3 SLA». Amazon Web Services, Inc
Berger, Thomas G.: Service Level Agreements. VDM, Saarbrücken 2007, ISBN 978-3-8364-1021-2.
Boniface, M.; Nasser, B.; Papay, J.; et al. (2010). "Platform-as-a-Service Architecture for Real-Time Quality of Service Management in Clouds". ICIW '10: Proceedings of the 2010 Fifth International Conference on Internet and Web Applications and Services: 155–160. doi:10.1109/ICIW.2010.91
Butler, J.M.; Yahyapour, R.; Theilmann, W. (2011). "Motivation and Overview". In Wieder, P.; Butler, J.M.; Theilmann, W.; Yahyapour, R. Service Level Agreements for Cloud Computing. Springer Science+Business Media, LLC. pp. 3–12. ISBN 9781461416142.
Cuomo, A.; Di Modica, G.; Distefano, S.; et al. (2013). "An SLA-based Broker for Cloud Infrastructures". Journal of Grid Computing. 11 (March 2013): 1–25. doi:10.1007/s10723-012-9241-4
Curtis, B.; Herron, D.; Subramanyam, J. (July 2015). "Using Software Measurement in SLAs: Integrating CISQ Size and Structural Quality Measures into Contractual Relationships"(PDF). CISQ.
Ding, Jianguo (2010). Advances in Network Management. Auerbach Publications. ISBN 978-1-4200-6455-1.
Desmarais, Mike (2012). "First Call Resolution"
Ellis, Avy; Kauferstein, Michael: Dienstleistungsmanagement - Erfolgreicher Einsatz von prozessorientiertem Service Level Management. Springer, Berlin 2013, ISBN 978-3-540-40585-6.
Facility-Management.de - Definition von Bauelementqualitäten mittels ERAB Verfahre - www.facility-management.de - Nos nossos arquivos [ Método ERAB ]
IBM - «IBM Knowledge Center». www.ibm.com
Kearney, K.T.; Torelli, F. (2011). "The SLA Model". In Wieder, P.; Butler, J.M.; Theilmann, W.; Yahyapour, R. Service Level Agreements for Cloud Computing. Springer Science+Business Media, LLC. pp. 43–68. ISBN 9781461416142.
Kyriazis, D., ed. (June 2013). "Cloud Computing Service Level Agreements - Exploitation of Research Results". European Commission. p. 51.
Laudon, Kenneth C, Jane P. “Management Information Systems 12/E: Managing the Digital Firm”. Pearson Education Asia. ISBN-10 : 027375453X / ISBN-13 : 9780273754534.
Maheshwari, Devna - Elements of Service Level Agreement & SLA Best Practices - esselebex.com - Nos nossos arquivos: [ docs.google.com ]
Microsoft - «Contratos de nível de serviço - Home page | Microsoft Azure». azure.microsoft.com.
Mühlencoert, Th.: Kontraktlogistik-Management. Grundlagen, Beispiele, Checklisten. Wiesbaden: Gabler Verlag, 2012, ISBN 978-3-8349-3131-3
NTT Communications - "Global IP Network SLA".
Pulverich, Michael; Schietinger, Jörg (Hrsg.): Service Levels in der Logistik. Mit KPIs und SLAs erfolgreich steuern. Verlag Heinrich Vogel, München 2007, ISBN 978-3-574-26091-9.
Rueda, J.L.; Gómez, S.G.; Chimento, A.E. (2011). "The Service Aggregator Use Case Scenario". In Wieder, P.; Butler, J.M.; Theilmann, W.; Yahyapour, R. Service Level Agreements for Cloud Computing. Springer Science+Business Media, LLC. pp. 329–342. ISBN 9781461416142.
Schönfelder, U.: Zustandsermittlung von Immobilien mittels Verfahren ERAB – Grundlagen für Instandhaltungsstrategien. Werner Verlag, Dortmund 2012, ISBN 978-3-8041-5253-3.
SLA Inf Zone - "The Service Level Agreement Zone". SLA Information Zone. Service Level Agreement Zone. 2015.
Shacklett, M.E. (12 January 2011). "Five Key Points for Every SLA". Dell. Archived from the original on 22 December 2012.
Verizon - "Global Latency and Packet Delivery SLA".
Verma, Dinesh (September 2004). "Service level agreements on IP networks" (PDF). IEEE. 92 (9).
Villari, M.; Tusa, F.; Celesti, A.; Puliafito, A. (2012). "How to Federate VISION Cloud through SAML/Shibboleth Authentication". In De Paoli, F.; Pimentel, E.; Zavattaro, G. Service-Oriented and Cloud Computing. Springer-Verlag Berlin Heidelberg. pp. 259–274. ISBN 9783642334276.
Wikisource:Telecommunications Act of 1996#SEC. 101. ESTABLISHMENT OF PART II OF TITLE II.
wirtschaftslexikon.gabler.de: Service Level Agreement
Ligações externas e recomendações de leitura
Creating SLA requirements – Setting the roadmap - hnordling.wordpress.com
Creating SLA requirements – Step 1 – Build the business case - hnordling.wordpress.com
Creating SLA requirements – Step 2 – Mirroring business with technical reality - hnordling.wordpress.com
Creating SLA requirements – Step 3 (post 1 of 2) – Monitoring - hnordling.wordpress.com
Esta série nos nossos arquivos: [ H Nordling - Creating SLA requirements ]