Acordo de nível de serviço bem feito e uma estratégia de saída são essenciais ao se comprometer com um fornecedor de cloud computing Executivos de negócios têm lido tudo sobre computação em nuvem e querem saber quando suas empresas irão adotá-la. CIOs precisam fazer três coisas como resposta à questão e ajudar as unidades de negócio a desfrutarem do ambiente cloud sem correr riscos. A primeira é não desdenhar a nuvem. As unidades de negócio ignorarão a área de TI se ela não oferecer orientação. Segunda: avise os líderes do negócio sobre os riscos da nuvem e as estratégias para reduzir esses riscos. Terceira: quando a decisão de uso de nuvem for tomada, estabeleça um acordo de nível de serviço (SLA, da sigla em inglês) realista e equilibrado. Estabelecer um SLA é apenas uma forma de proteger a empresa. Um processo passo-a-passo desde avaliação até implementação, para ajudar os gerentes do negócio a balancear riscos, impacto fiscal e flexibilidade é muito mais necessário. Se a decisão para um determinado serviço de TI for a favor de uma abordagem em nuvem - software como serviço, plataforma como serviço, infraestrutura como serviço - é preciso saber como proceder e o que fazer caso ocorra algum problema. Esse é o principal ponto, não apenas de SLA, mas de boa governança. Responder às seguintes questões irá ajudar a determinar se o uso de computação em nuvem faz sentido, avaliar fornecedores, determinar se é necessário um SLA e, caso seja, como construir um acordo forte. 1. Por que os serviços em nuvem estão sendo cogitados?
Digamos que seja necessário desenvolver, rapidamente, um aplicativo temporário específico para uma vendedora de barcos, uma que aparece de repente e, tão de repente quanto, é retirada de serviço. Esse é um ótimo caso para o uso de computação em nuvem. Há pouco gasto e com o fornecedor certo, o aplicativo pode ser lançado eficientemente. Mas nem todo caso é apropriado para o atual nível de maturidade da computação em nuvem. Algo que pode ser feito rapidamente usando a infraestrutura interna de TI não tem sentido ser enviado para a nuvem. 2. Quais são os riscos e benefícios?
Se você for morar nas nuvens, leve um para-quedas. Além de avaliar os benefícios, seja realista sobre os piores cenários possíveis, como o aplicativo sair do ar, desempenho comprometido ou, até mesmo, brecha na segurança. É útil pensar nesses casos pela relativa probabilidade, assim como seu impacto no negócio. Por exemplo, um aplicativo corporativo que muitos estão relutantes em enviar para um ambiente de nuvem é ERP, cujo impacto de falha é alto, independentemente da probabilidade de falha, que nunca é zero. 3. Um SLA negociável é necessário? Caso seja, quais penalidades são apropriadas?
Pense sobre porque um SLA é necessário. É uma forma de proteger o que outra pessoa está gerenciando, e você quer que o fornecedor do serviço tenha o pescoço no jogo. O provedor enfrenta altos gastos para oferecer garantia de disponibilidade. Eles precisam compensar isso de alguma forma, então, conforme o cliente aumenta os digitos nas penalidades, o serviço de nuvem fica mais caro. O ponto é que existe uma tensão natural entre o baixo custo do serviço de nuvem e altas penalidades em SLA. O risco que qualquer fornecedor deve adicionar ao seu modelo de negócio - e ao preço - é diretamente proporcional às penalidades financeiras que ele seria obrigado a pagar em caso de violação ao SLA. Existe uma tensão natural parecida, na perspectiva do fornecedor, entre alta disponibilidade e operações de baixo custo. SLA se trata de um recurso para se proteger caso ocorram problemas com seu provedor de cloud, mas não é o único recurso. Trocar de fornecedor ou usar meios internos são outras possibilidades. Portanto, se sua equipe de desenvolvimento usa a nuvem para promover testes, e a nuvem de testes pode ser, facilmente, trazida para casa, não é necessário um SLA muito rígido. Muitos fornecedores oferecem um SLA padrão com créditos de serviço que podem ser perfeitos para o caso exposto. Mas se a falha no serviço pode prejudicar seu negócio de forma significativa, seu caso ainda não condiz com as ofertas de nuvem atuais. 4. Quais critérios são importantes para seu perfil de risco?
Os critérios-chave para a nuvem incluem: disponibilidade, tempo de resposta e tempo de reposta em serviço ao cliente (isto é, quanto tempo é preciso esperar depois de reportar um problema). Incluir fornecimento de serviços importantes, como segurança, faz sentido, mas depende do tipo de uso. Se você usa infraestrutura como serviço, nunca conseguirá receber fornecimento de segurança; isso está fora do alcance do fornecedor já que é você quem administra seus serviços virtuais. Com um fornecedor de SaaS, é mais provável que você receba tal serviço. Tempo de atividade e tempo de resposta são importantes, mas os critérios mais importantes para julgar a qualidade do serviço dependem do uso. Se você quer mudar para nuvem por sua habilidade de escala rápida, pergunte ao fornecedor como ele mede essa habilidade. Essa medida não está a seu critério. Se é importante para seu caso de uso que servidores distribuídos geograficamente ofereçam serviços melhores para um público nacional, é melhor medir critérios em cada uma das regiões. Pense sobre o que pode causar a suspensão dos seus critérios e quem é responsável por eventos externos. Como você vai tirar seu aplicativo do ar para fazer manutenção? E se um terceiro, mal intencionado, lançar um ataque distribuído de serviço-negado? 5. O seu ambiente é o lado mais fraco?
As redes de empresas médias são, às vezes, menores do que poderiam ser quando se trata de conexão de internet. Isso pode ser resultado de um desejo de reduzir a entrada de dados e pontos de saída a fim de minimizar os riscos de segurança. Se seu aplicativo precisa "ligar pra casa" para funcionar (se ele se comunica com um banco de dados local dentro da rede corporativa, por exemplo) e a rede corporativa está com problemas para se conectar à web, então o aplicativo em nuvem também terá dificuldade em se comunicar. Existem estratégias para mitigar esse cenário. O ponto é que, quando se cria um SLA, é preciso identificar, rapidamente, qualquer ponto de falha no seu ambiente a fim de ser um bom cidadão e manter credibilidade frente ao seu fornecedor de serviço. 6. O que demonstraram os testes-piloto e referências?
Não importa quão boa seja a pré-oferta de SLA, é necessário conduzir uma análise detalhada do fornecedor do serviço se o caso de uso envolver qualquer coisa importante. Até os vendedores concordam com isso: "você precisa conversar com dois ou três clientes e verificar o fornecedor", disse Ian Knox, diretor-sênior de gerenciamento de produto da Skytap, um fornecedor de serviço de nuvem. "Se o fornecedor não estiver crescendo, você encontra comentários negativos sobre ele em sites de rede social, eles não durarão muito." 7. Quem irá medir os critérios do SLA?
Se você quer enviar alguma coisa importante para um fornecedor de serviço externo, geralmente, você pode confiar nos critérios passados por eles. Dito isso, a abordagem mais pragmática é conseguir uma terceira perspectiva. Usar um aplicativo de gerenciamento de performance, como Cloudkick, Gomez, enStratus ou Apparent Networks, pode te dar uma luz antes mesmo que o fornecedor faça alguma coisa. Usar medidas terceirizadas tem seu próprio leque de benefícios e desafios. Os fornecedores de serviço provavelmente não irão reconhecer as medidas feitas por terceiros quando se tratar de invocar as penalidades do SLA. Por outro lado, usar um serviço terceirizado pode eliminar problemas antes que os clientes e parceiros notem uma queda no aplicativo e serve como um aviso prévio do que precisa ser verificado com o fornecedor. 8. Por qual perspectiva os critérios do SLA serão medidos?
Pense no local por onde eles serão medidos. Se o seu caso de uso requer espalhar o aplicativo por data centers geograficamente dispersos, medir as diversas perspectivas pode garantir que você não olhará apenas para o rabo do elefante. E não é uma questão de medir apenas pelo lado de fora; o lado de dentro pode ser vitalmente importante. Seu aplicativo multiestratificado pode ficar atrás do firewall do fornecedor, tornando difícil medir o tempo de resposta do servidor de banco de dados versus o tempo de resposta do servidor do aplicativo. Entender como isso pode influenciar, pode ser essencial para resolver problemas ou apontar a origem do problema para o fornecedor do serviço. 9. O que acontece se o fornecedor falhar completamente?
Em algum lugar, no seu planejamento, leve em consideração o que aconteceria caso o fornecedor do serviço falhasse por um período inaceitável. Em um contrato formal, isso significaria o fim do relacionamento. Em um serviço de nuvem "pague-o-quanto-usar", não existe, exatamente, um contrato de serviço. Encerrar o serviço deve ser parte do seu processo. Em qualquer modelo de negócio quase-terceirizado, a responsabilidade de trocar de fornecedor ou de tentar resgatar o que sobrou quando o serviço falha, fica por conta da equipe de TI. Os caras da unidade de negócio colocarão a culpa em você caso alguma coisa saia errada, portanto, é essencial ter um plano de saída. Fonte: InformationWeek EUA
Autor: Jonathan Feldman, executivo de IT e consultor na Carolina do Norte.
Digamos que seja necessário desenvolver, rapidamente, um aplicativo temporário específico para uma vendedora de barcos, uma que aparece de repente e, tão de repente quanto, é retirada de serviço. Esse é um ótimo caso para o uso de computação em nuvem. Há pouco gasto e com o fornecedor certo, o aplicativo pode ser lançado eficientemente. Mas nem todo caso é apropriado para o atual nível de maturidade da computação em nuvem. Algo que pode ser feito rapidamente usando a infraestrutura interna de TI não tem sentido ser enviado para a nuvem. 2. Quais são os riscos e benefícios?
Se você for morar nas nuvens, leve um para-quedas. Além de avaliar os benefícios, seja realista sobre os piores cenários possíveis, como o aplicativo sair do ar, desempenho comprometido ou, até mesmo, brecha na segurança. É útil pensar nesses casos pela relativa probabilidade, assim como seu impacto no negócio. Por exemplo, um aplicativo corporativo que muitos estão relutantes em enviar para um ambiente de nuvem é ERP, cujo impacto de falha é alto, independentemente da probabilidade de falha, que nunca é zero. 3. Um SLA negociável é necessário? Caso seja, quais penalidades são apropriadas?
Pense sobre porque um SLA é necessário. É uma forma de proteger o que outra pessoa está gerenciando, e você quer que o fornecedor do serviço tenha o pescoço no jogo. O provedor enfrenta altos gastos para oferecer garantia de disponibilidade. Eles precisam compensar isso de alguma forma, então, conforme o cliente aumenta os digitos nas penalidades, o serviço de nuvem fica mais caro. O ponto é que existe uma tensão natural entre o baixo custo do serviço de nuvem e altas penalidades em SLA. O risco que qualquer fornecedor deve adicionar ao seu modelo de negócio - e ao preço - é diretamente proporcional às penalidades financeiras que ele seria obrigado a pagar em caso de violação ao SLA. Existe uma tensão natural parecida, na perspectiva do fornecedor, entre alta disponibilidade e operações de baixo custo. SLA se trata de um recurso para se proteger caso ocorram problemas com seu provedor de cloud, mas não é o único recurso. Trocar de fornecedor ou usar meios internos são outras possibilidades. Portanto, se sua equipe de desenvolvimento usa a nuvem para promover testes, e a nuvem de testes pode ser, facilmente, trazida para casa, não é necessário um SLA muito rígido. Muitos fornecedores oferecem um SLA padrão com créditos de serviço que podem ser perfeitos para o caso exposto. Mas se a falha no serviço pode prejudicar seu negócio de forma significativa, seu caso ainda não condiz com as ofertas de nuvem atuais. 4. Quais critérios são importantes para seu perfil de risco?
Os critérios-chave para a nuvem incluem: disponibilidade, tempo de resposta e tempo de reposta em serviço ao cliente (isto é, quanto tempo é preciso esperar depois de reportar um problema). Incluir fornecimento de serviços importantes, como segurança, faz sentido, mas depende do tipo de uso. Se você usa infraestrutura como serviço, nunca conseguirá receber fornecimento de segurança; isso está fora do alcance do fornecedor já que é você quem administra seus serviços virtuais. Com um fornecedor de SaaS, é mais provável que você receba tal serviço. Tempo de atividade e tempo de resposta são importantes, mas os critérios mais importantes para julgar a qualidade do serviço dependem do uso. Se você quer mudar para nuvem por sua habilidade de escala rápida, pergunte ao fornecedor como ele mede essa habilidade. Essa medida não está a seu critério. Se é importante para seu caso de uso que servidores distribuídos geograficamente ofereçam serviços melhores para um público nacional, é melhor medir critérios em cada uma das regiões. Pense sobre o que pode causar a suspensão dos seus critérios e quem é responsável por eventos externos. Como você vai tirar seu aplicativo do ar para fazer manutenção? E se um terceiro, mal intencionado, lançar um ataque distribuído de serviço-negado? 5. O seu ambiente é o lado mais fraco?
As redes de empresas médias são, às vezes, menores do que poderiam ser quando se trata de conexão de internet. Isso pode ser resultado de um desejo de reduzir a entrada de dados e pontos de saída a fim de minimizar os riscos de segurança. Se seu aplicativo precisa "ligar pra casa" para funcionar (se ele se comunica com um banco de dados local dentro da rede corporativa, por exemplo) e a rede corporativa está com problemas para se conectar à web, então o aplicativo em nuvem também terá dificuldade em se comunicar. Existem estratégias para mitigar esse cenário. O ponto é que, quando se cria um SLA, é preciso identificar, rapidamente, qualquer ponto de falha no seu ambiente a fim de ser um bom cidadão e manter credibilidade frente ao seu fornecedor de serviço. 6. O que demonstraram os testes-piloto e referências?
Não importa quão boa seja a pré-oferta de SLA, é necessário conduzir uma análise detalhada do fornecedor do serviço se o caso de uso envolver qualquer coisa importante. Até os vendedores concordam com isso: "você precisa conversar com dois ou três clientes e verificar o fornecedor", disse Ian Knox, diretor-sênior de gerenciamento de produto da Skytap, um fornecedor de serviço de nuvem. "Se o fornecedor não estiver crescendo, você encontra comentários negativos sobre ele em sites de rede social, eles não durarão muito." 7. Quem irá medir os critérios do SLA?
Se você quer enviar alguma coisa importante para um fornecedor de serviço externo, geralmente, você pode confiar nos critérios passados por eles. Dito isso, a abordagem mais pragmática é conseguir uma terceira perspectiva. Usar um aplicativo de gerenciamento de performance, como Cloudkick, Gomez, enStratus ou Apparent Networks, pode te dar uma luz antes mesmo que o fornecedor faça alguma coisa. Usar medidas terceirizadas tem seu próprio leque de benefícios e desafios. Os fornecedores de serviço provavelmente não irão reconhecer as medidas feitas por terceiros quando se tratar de invocar as penalidades do SLA. Por outro lado, usar um serviço terceirizado pode eliminar problemas antes que os clientes e parceiros notem uma queda no aplicativo e serve como um aviso prévio do que precisa ser verificado com o fornecedor. 8. Por qual perspectiva os critérios do SLA serão medidos?
Pense no local por onde eles serão medidos. Se o seu caso de uso requer espalhar o aplicativo por data centers geograficamente dispersos, medir as diversas perspectivas pode garantir que você não olhará apenas para o rabo do elefante. E não é uma questão de medir apenas pelo lado de fora; o lado de dentro pode ser vitalmente importante. Seu aplicativo multiestratificado pode ficar atrás do firewall do fornecedor, tornando difícil medir o tempo de resposta do servidor de banco de dados versus o tempo de resposta do servidor do aplicativo. Entender como isso pode influenciar, pode ser essencial para resolver problemas ou apontar a origem do problema para o fornecedor do serviço. 9. O que acontece se o fornecedor falhar completamente?
Em algum lugar, no seu planejamento, leve em consideração o que aconteceria caso o fornecedor do serviço falhasse por um período inaceitável. Em um contrato formal, isso significaria o fim do relacionamento. Em um serviço de nuvem "pague-o-quanto-usar", não existe, exatamente, um contrato de serviço. Encerrar o serviço deve ser parte do seu processo. Em qualquer modelo de negócio quase-terceirizado, a responsabilidade de trocar de fornecedor ou de tentar resgatar o que sobrou quando o serviço falha, fica por conta da equipe de TI. Os caras da unidade de negócio colocarão a culpa em você caso alguma coisa saia errada, portanto, é essencial ter um plano de saída. Fonte: InformationWeek EUA
Autor: Jonathan Feldman, executivo de IT e consultor na Carolina do Norte.
http://cognostech.posterous.com/
http://www.tweeter.com/ramonritter
