Arquivo mensal: junho 2015

Implementando Skype for Business On Premissess

 

Olá pessoal em parceria com o Everton do site msbsb.com.br ele nos cedeu este post sobre O Skype for Business. Assim me poupou de postar meu LAB.

Mas já fiz ele e está no ar em casa usando.

Só não tenho o Gateway para ligar ainda com minha linha Telefônica.

Mas é excelente. Curta o Post e obrigado.

Tenho postado do Lync 2013

https://fabiosilva.com.br/2014/08/05/passo-a-passo-instalando-o-lync-server-2013-standard-edition-front-end-no-windows-2012-parte-1/
https://fabiosilva.com.br/2014/08/05/passo-a-passo-instalando-o-lync-server-2013-monitoramento-standard-edition-front-end-parte-2/

O Lab é simples
VM 1 = Active Directory Domain Services + Certificate Services
VM 2 = Skype for Business Server

Pre-requisitos de DNS:
Registros Host(A) / Alias (CNAME)

Registros SRV

  1. -_sipinternaltls
  2. -_tcp
  3. – 5061
  4. – MSBSB-SKPFE01


Aqui no meu lab estou usando Windows Server 2012 R2, é necessário que se instale o KB2982006.

Instalação dos pré-requisitos no servidor front-end.

Clique com o botão direito no “Windows Power Shell” e mande executar como administrador conforme imagem abaixo.

Em seguida execute os comandos abaixo:
import-module servermanager
Add-WindowsFeature NET-Framework-Core, RSAT-ADDS, Windows-Identity-Foundation, Web-Server, Web-Static-Content, Web-Default-Doc, Web-Http-Errors, Web-Dir-Browsing, Web-Asp-Net,Web-Net-Ext, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Http-Logging, Web-Log-Libraries, Web-Request-Monitor, Web-Http-Tracing, Web-Basic-Auth, Web-Windows-Auth, Web-Client-Auth,Web-Filtering, Web-Stat-Compression, Web-Dyn-Compression, NET-WCF-HTTP-Activation45, Web-Asp-Net45, Web-Mgmt-Tools, Web-Scripting-Tools, Web-Mgmt-Compat, Server-Media-Foundation,BITS -Source D:\sources\sxs

OBS: Não esqueça de deixar a mídia do Windows Server 2012 R2 montada no servidor, para a execução dos comandos.

 Depois de reiniciado o servidor, adicione a mídia do Skype for Business. Abra a mídia, a instalação do Visual C++ vai iniciar automaticamente.

Já no início da instalação do Skype

  1. Como meu lab está sem internet no momento marquei para não checar os updates, o recomendado é que se faça o check dos updates.
  2. Clique em install


  1. Aceite os termos de licença
  2. Clique em OK


  1. Clique em Prepare Active Directory


  1. Em Prepare Schemma clique em Run


Clique em Next

Depois de completo com sucesso clique em Finish

Em Prepare Current Forest clique em Run

Clique em next

Deixe em local domain e clique em next

Depois de finalizado com sucesso clique em Finish

Em Prepare Current Domain clique em Run

Clique em next

Depois de finalizado com sucesso clique em Finish

Agora no “Active Directory Users and Computers” no container “Users“. Procure o grupo “CSAdmnistrator“, adicione à esse grupo o usuário que vai administrar o Skype for business server.

Voltando no instalador do Skype, clique em Install Administrative Tools.

Em seguida clique em next

Após finalizar com êxito clique em Finish

Voltando no Deployment Wizard clique em “Prepare first standard Edition Server

Clique em next

Depois de finalizado clique em Finish

Agora abra o “Skype for Business Server Topology Builder

Após abrir o “topology builder” marque New Topology e clique em OK

Coloque o nome que desejar no arquivo de topologia.
OBS: Eu sempre coloco a data da modificação no arquivo.

Coloque o sip domain e clique em next

Se você tem um sip domain adicional, adicione e clique em next.

  1. Coloque o nome do site.
  2. Coloque a descrição do site.
  3. Clique em next


  1. Coloque o nome da cidade
  2. Coloque o nome do estado
  3. Coloque o nome do pais
  4. Clique em next


Deixe marcado para abrir o wizard para o novo front-end clique em Finish.

Clique em next.

  1. Coloque o FQDN do servidor
  2. Marque a opção standard edition
  3. Clique em next


  1. Nesse primeiro tutorial vou só colocar o conferencing, nos próximos eu vou implementar o resto.
  2. Clique em next


Clique em next.

Clique em Next

Veja que ele configura o SQL Express automaticamente, clique em next.

  1. Coloque o nome do servidor onde vai ser armazenado o file store. Aqui vou colocar no próprio Front-end.
  2. Coloque o nome da pasta.
  3. Clique em Next.


  1. Coloque a URL de acesso quando a conexão vier da rede externa
  2. Clique em next.


Desmarque a associação do Web Apps Server e clique em next.

Agora no Topology Builder, clique com o direito na raiz e clique em “Publish Topology

Clique em next.

Clique em next.

Depois de publicado, abra o deployment wizard e clique em “Install or Update

Em Install Local Configuration Store clique em Run

Clique em Next.

Depois de terminado com sucesso clique em Finish

Em Setup or Remove Skype for Business Server Components clique em Run

Clique em Next.

Depois de terminado com sucesso clique em Finish.

Em Request, Install or Assign Certificates clique em Run.

  1. Marque o Default Certificate.
  2. Clique em Request.


  1. Selecione a unidade certificadora que vai gerar os certificados para o S4B.
  2. Por padrão ele já coloca o nome para o certificado, mas esse nome pode ser alterado.
  3. Coloque o nome da organização.
  4. Coloque a unidade da organização, no caso o departamento.
  5. Selecione o pais.
  6. Coloque o estado.
  7. Coloque a cidade.
  8. Selecione os sip domains que tem que constar nos certificados.
  9. Clique em Next.


Clique em Next.

Depois de verificar o “Task status” clique em next.

Deixe marcado para assinar o certificado gerado, clique em next.

Clique em Next.

Clique em Next.

Clique em Finish.

  1. Agora marque o “OAuthTokenIssuer”
  2. Clique em request.


  1. Selecione a unidade certificadora que vai gerar os certificados para o S4B.
  2. Por padrão ele já coloca o nome para o certificado, mas esse nome pode ser alterado.
  3. Coloque o nome da organização.
  4. Coloque a unidade da organização, no caso o departamento.
  5. Selecione o pais.
  6. Coloque o estado.
  7. Coloque a cidade.
  8. Clique em Next.


Clique em Next.

Depois de verificar o “Task status” clique em next.

Deixe marcado para assinar o certificado gerado, clique em next.

Clique em Next.

Clique em Next.

Depois de verificar o “Task status” clique em Finish.

Depois de assinado todos os certificado clique em close.

No Deployment Wizard, em “service status” clique em Run.

Verificando os serviços em funcionamento.

Obs: Antes de abrir o console, não esqueça de instalar o Silverlight.
Abra o painel de controle.

Logue com o usuário que é o administrador do S4B.

No painel de controle, em Topology podemos verificar o status do servidor.

 

Backup Histórico de conversas Skype For Business For Users and Administrators

Todas as funções do Lync Online foram convergidas com o Skype adquirida pela Microsoft onde o nome é forte no Mercado e trabalha sob multiplataforma.

Praticamente todos Sistemas operacionais de mercado e celulares o Skype está presente.

O que os usuários têm me perguntado muito é, dá para fazer o backup das conversas? Eu respondo que dá.

O que os administradores me perguntam muito é, dá para fazer o backup das conversas e o usuário não conseguir apagar o histórico? Eu respondo que dá.

Os Powerusers não gostaram da parte dos administradores (Risos), mas lembrando que você em ambiente corporativo e assinado termo de conduta do uso de softwares e internet corporativa você está sujeito a monitoramento a qualquer momento pois você está utilizando as propriedades das empresas mesmo em tempos de BYOD.

Mas e daí o computador é meu e pessoal? Mas e daí os dados não são seus, são da corporação!!! A briga de gato e rato vai ser assim sempre.

É possível realizar backup dos histórico de conversas caso você queira consultar ou até mesmo guardar.

Veja que no menu em forma de relógio do Skype ele exibe os histórico de conversas recentes e abaixo você pode ver as conversas na pasta de hisptrico de conversas no Outlook.

Visualizando no Outlook você tem acesso ao seu histórico de conversas.

Como você está sincronizado com uma conta Exchange online pelo seu Outlook 2007, 2010 ou 2013 considere isso um backup pois sua caixa de e-mail plano E1, E3 e outros planos tem 50GB de espaço e ainda o Arquivo morto online que varia até 100GB.

“AAAAAA” você é Power User e conhece a ferramenta de “Cabo a Rabo”, sabe fazer backup do PST e tudo, e pode deletar?

Veja bem, tem o lado do administrador que tem acesso total a sua caixa:

O lado do administrador, é também evitar que o usuário possa apagar o histórico de mensagem pois o gerente dele quer ver o que ele anda falando no Skype, pois lembra que você assinou um termo de conduta? Sim ele pode dentro dos rigores da lei defender seu patrimônio.

OBS: Defesa contra seres humanos com pensamento ruins não existem qualquer software.

Não vou entrar no mérito de mostrar como libera o acesso total a uma caixa que o intuito deste post é o backup do histórico de conversas.

Com o acesso Total a caixa do usuário o administrador neste menu acima pode evitar que o usuário delete as mensagens com as permissões de deletar as conversas.

Mesmo o usuário deletando conforme as políticas o administrador ainda consegue via GUI restaurar as mensagens deletadas.

Às vezes é uma chatice mostrar estes pontos, mas duvido que um administrador do Office 365 tenha feito este tipo de trabalho.

Este tópico vale para o Skype For Businness online e Onpremissess.

O Skype Onpremissess é mais fácil pois além deste tópico ainda é possível fazer a recuperação da base no SQL Server.

Outros meios como Archiving, com ferramentas terceiras também é possível só no Skype Onpremissess.

É ainda possível fazer o backup do PST mas você pode escolher só a pasta de histórico de conversas de um determinado usuário.

É claro que estou mostrando o dia a dia sem custos mas se você quer se aprofundar mais eu tenho um link abaixo sobre IGNITE da Microsoft que houve a pouco tempo de como realizar o backup do Skype Onpremisses via Powershell.

Para quem gosta como eu virou uma lindeza abrir a tela e ficar “brincando” de backup e automatizar processos de backup do “Skype”.

https://myignite.microsoft.com/#/videos/aee7200b-2f91-e411-b87f-00155d5066d7?sq=backup&sf=%5B%5D#ignite-html-anchor

Este link mostra como relizar exportação de dados de usuários ou base do Skype ou Lync.

https://technet.microsoft.com/pt-br/library/jj205337.aspx

Backup Lync (Skype for business) Onpremissess

https://gallery.technet.microsoft.com/Backup-Skype-for-Business-8194d0b6

Próximo post mostro como exportar contatos do Skype.

Acesse que você vai gostar muito e ter paciência para ver o vídeo que é grande, mas vale a pena.

MDM Office 365

Pessoal

Novidade em alguns tenants do Office 365.

MDM: Mobile Device manager, ou seja, gerenciamento de dispositivos móveis.

O Gerenciamento de Dispositivos Móveis do Office 365 pode ajudar você a proteger e gerenciar dispositivos móveis como iPhones, iPads, Androids e Windows Phones usados por usuários licenciados do Office 365 em sua organização. Você pode criar políticas de gestão de dispositivos móveis que incluam configurações para ajudar com o controle do acesso aos documentos e emails do Office 365 de sua organização para dispositivos móveis e aplicativos com suporte. Se um dispositivo for perdido ou roubado, você poderá apagar remotamente os dados do dispositivo para remover informações organizacionais confidenciais.

microsoft-office-365-devices-540x334

 

  • Você pode usar o MDM para Office 365 para proteger e gerenciar os seguintes tipos de dispositivo.
  • Windows Phone 8.1
  • iOS 6 ou versões posteriores
  • Android 4 ou versões posteriores
  • Windows 8.1*
  • Windows 8.1 RT *

    image2

Os aplicativos com suporte para os diversos tipos de dispositivos móveis da tabela a seguir solicitarão aos usuários o registro no MDM para Office 365. Nesse local, há uma nova política de gestão de dispositivos móveis que se aplica ao dispositivo de um usuário que não registrou anteriormente o dispositivo. Se o dispositivo de um usuário não estiver em conformidade com uma política, dependendo de como a política é configurada, talvez o usuário não possa acessar os recursos do Office 365 nesses aplicativos ou talvez ele tenha acesso, mas o Office 365 reporte uma violação da política.

O diagrama a seguir mostra o que acontece quando um usuário com um novo dispositivo entra em um aplicativo que dá suporte ao controle de acesso com o MDM para Office 365. O usuário é impedido de acessar os recursos do Office 365 no aplicativo até que registre seu dispositivo.

Mostra o processo de registro para um novo dispositivo.

ObservaçãoObservação:
As políticas e regras de acesso criadas no MDM para Office 365 vão substituir as políticas de caixa de correio de dispositivo móveis do Exchange ActiveSync e as regras de acesso de dispositivos criadas no Centro de administração do Exchange. Quando um dispositivo for registrado no MDM para Office 365, qualquer política de caixa de correio de dispositivo móvel do Exchange ActiveSync ou regra de acesso de dispositivo aplicada ao dispositivo será ignorada. Para saber mais sobre o Exchange ActiveSync, consulte Exchange ActiveSync no Exchange Online.

Se você criar uma política para bloquear o acesso com determinadas configurações ativadas, os usuários serão impedidos de acessar os recursos do Office 365 ao usar um aplicativo com suporte relacionado em Controle de acesso aos emails e documentos do Office 365. As configurações que podem impedir o acesso dos usuários aos recursos do Office 365 estão nessas seções:

  • Segurança
  • Criptografia
  • Desbloqueado
  • Perfil de email gerenciado

Por exemplo, o diagrama a seguir mostra o que acontece quando um usuário com um dispositivo registrado não está em conformidade com uma configuração de segurança em uma política de gestão de dispositivos móveis que se aplica ao seu dispositivo. O usuário entra em um aplicativo que dá suporte ao controle de acesso com MDM para Office 365. Eles é impedido de acessar os recursos do Office 365 no aplicativo até que o dispositivo esteja em conformidade com a configuração de segurança.

Mostra que o usuário está bloqueado quando o dispositivo não é compatível.

No Tenant para quem tem E3 aparecerá desta maneira.
Office_365_MDM
Mais um item de qualidade no Office 365 e sem pagar nada mais.
Espero que gostem.
Fonte: Microsoft.

3° Hangout OpenStack Brasil

Olá

Nesse artigo vou falar sobre CLI e REST API no OpenStack.

O objetivo é dar um “start” nesse assunto e mostrar o caminho das pedras para quem quiser fazer mais testes e estudar mais sobre o assunto.

O ambiente que utilizei foi o seguinte:

2 máquinas virtuais no Virtual Box, ambas com Ubuntu 14.04 LTS. Em uma delas fiz um deploy com Devstack, vamos chama-la de “nuvem” e na outra vamos instalar o client do OpenStack, vamos chama-la de “cliente”.

 

A instalação do cliente será feita através do PIP que é um script Python que já instala todas as dependências e a versão mais atualizada.

Mãos a obra

INSTALANDO DEPENDÊNCIAS PARA INSTALAR CLI EM UBUNTU 14.04 LTS

#apt-get update

#apt-get install -y python-pip

#apt-get install -y build-essential

#apt-get install -y python-dev libxslt1-dev libxml2-dev

 

INSTALANDO OPENSTACK CLI

#pip install python-openstackclient

Nesse momento o cliente OpenStack já está instalado, porém, para iniciarmos a interação com a plataforma através do CLI precisamos passar nossas credenciais e para isso podemos logar (odeio essa expressão) pelo Horizon, clicar na aba projetos -> acesso e segurança -> API -> Baixar arquivo RC.

Abra o arquivo, copie o conteúdo, crie um arquivo na sua máquina cliente:

#vim openstackrc.sh

Salve o arquivo e execute o seguinte comando:

#source openstackrc.sh

Agora nossas variáveis foram criadas com as credenciais necessárias para acessar nossa nuvem OpenStack, então vamos executar alguns comandos para verificar o ambiente.

Lista as instancias criadas

#nova list

Lista imagens disponíveis

#glance image-list

Lista grupos de segurança

#nova secgroup-list

Lista regras do grupo de segurança default

#nova secgroup-list-rules default

 

Lista pares de chaves

#nova keypair-list

Lista flavors

#nova flavor-list

Lista redes configuradas

#nova network-list

Mostra detalhes da rede de nome private

#nova network-show private

 

Agora vamos começar a criar os componentes para vincular à instância que vamos lançar mais adiante.

Os comandos abaixo criam um grupo de segurança com o nome secgroup1 e define para ele uma regra que permite acesso SSH de qualquer IP e outra que permite protocolo icmp de todos os tipos também de qualquer IP.

#nova secgroup-create secgroup1 “secgroup1″

#nova secgroup-add-rule secgroup1 tcp 22 22 0.0.0.0/0

#nova secgroup-add-rule secgroup1 icmp -1 -1 0.0.0.0/0

Agora podemos listar as regras do grupo de segurança secgroup1

#nova secgroup-list-rules secgroup1

Vamos criar um flavor de nome “flavor1”, vamos definir o ID 6, 64MB de memória, 1GB de disco e 1 CPU. Para isso executamos o comando abaixo:

#nova flavor-create       flavor1    6   64   1    1

Podemos agora fazer o download de uma imagem do Cirros e criar essa imagem na nossa nuvem.

#wget http://download.cirros-cloud.net/0.3.1/cirros-0.3.1-x86_64-disk.img

#glance image-create –name=cirros_hangout –is-public=true –container-format=bare \

–disk-format=qcow2 –file cirros-0.3.1-x86_64-disk.img

#glance image-show cirros_criado

#glance image-delete cirros_criado

Agora o par de chaves

#ssh-keygen -t rsa -f chave.key

 

#nova keypair-add –pub-key chave.key.pub chave

Finalmente vamos lançar uma instância usando todos os componentes que criamos anteriormente, para isso executamos o comando:

#nova boot –flavor flavor1 –image cirros_hangout –security-groups secgroup1 –key-name chave instancia-cirros

#nova list

#nova show instancia-cirros

Nossa instância já foi criada, porém no ultimo comando podemos perceber que ela está vinculada apenas à nossa rede privada, isso não permite que nossa instância tenha acesso à rede externa, Internet e nem que possamos acessá-la de outro computador. Para resolvermos isso precisamos atribuir um floating IP à nossa instância.

#nova floating-ip-create

#nova add-floating-ip instancia-cirros <IP_CRIADO>

Agora, finalmente podemos conectar por SSH na nossa instância.

 

REST API

Agora vou mostrar alguns exemplos de comandos que podemos executar através da API REST do OpenStack.

Para exemplificar essa interação, utilizei um plugin do Google Chrome chamado Advanced REST Client.

 


LISTAR AS VERSÕES DE API

url: http://192.168.1.46:5000/

método: GET

cabeçalhos:

AUTENTICANDO

url: http://192.168.1.46:5000/v3/auth/tokens

método: POST

cabeçalhos: Content-type : application/json

body:

{
“auth”: {
“identity”: {
“methods”: [
“password”
],
“password”: {
“user”: {
“name”: “admin”,
“password”: “password”,
“domain”: {
“name”:”Default”
}

}
}
}
}
}

Nesse caso você substitui o “admin” e “password” pelo seu usuário e senha, o mesmo que utiliza para logar no Horizon.

VALIDANDO O TOKEN

url: http://192.168.1.46:5000/v3/auth/tokens

método: GET

cabeçalhos: X-Auth-Token: “token de serviço” (aqui vai o token de serviço)

X-Subject-Token: a70f063b60184a1fbd10eaa55d933705 – (aquio token retornado no commando aterior)

 

Obs: O token de serviço pode ser encontrado no arquivo /etc/keystone/keystone.conf no host onde está instalada a sua nuvem ou no arquivo local.conf que você criou ao fazer a implementação do Devstack.

CHECAR O TOKEN CRIADO

url: http://192.168.1.46:5000/v3/auth/tokens

método: HEAD

cabeçalhos: X-Auth-Token: “token de serviço”

X-Subject-Token: a70f063b60184a1fbd10eaa55d933705

 

LISTAR PROJETOS

url: http://192.168.1.46:5000/v3/projects

método: GET

cabeçalhos: X-Auth-Token: “token de serviço”

CRIAR NOVO PROJETO

url: http://192.168.1.46:5000/v3/projects

método: POST

cabeçalhos: X-Auth-Token: “token de serviço”

Content-type : application/json

 

Body:

{
“project”: {
“description”: “description1″,
“domain_id”: “default”,
“enabled”: true,
“name”: “MeuProjeto1″
}
}

CURL

Os mesmos comandos que executamos através do plugin do Google Chrome podem ser executados pelo console de uma estação Linux pelo comando “curl”.

LISTA VERSÕES DE APIS

#curl -i http://192.168.1.46:5000/ ; echo

AUTENTICA

#curl -i -H “Content-Type: application/json”   -d ‘

{ “auth”: {

“identity”: {

“methods”: [“password”],

“password”: {

 

“user”: {

“name”: “admin”,

“domain”: { “id”: “default” },

“password”: “initd”

}

}

}

}

}’ \

LISTA PROJETOS

 #curl -i -H “X-Auth-Token: token-de-serviço” http://192.168.1.46:5000/v3/projects ; echo

DOCUMENTAÇÃO

API Quick Start
Cloud Administrator Guide
Command line reference
API Complete Reference

Agradeço o Sandro do Conacloud que cedeu a matéria e estamos nesta empreitada difundindo a ferramenta. E a nossa parceria como sempre.

Em breve estaremos com uma solução pronta de backup com Openstack.

Windows Server 2016 Tecnical Preview disponível no Azure

Pessoal

Para quem tem Azure, está disponível o Windows Server 2016.

Interface já no padrão Windows 10.

Mudanças Visuais com a cara do Windows 10 mas o que mais foi alterado são suas mudanças estruturais.

  • Active Directory Federation Services (ADFS): Novos recursos que permitem a configuração de ADFS para autenticar usuários armazenados em diretórios Lightweight Directory Access Protocol (LDAP).
  • Remote Desktop Services: Suporte para aplicações OpenGL e OpenCL e adição da função MultiPoint Services para o Windows Server.
  • Cluster de failover baseado no Hyper-V ou um servidor de arquivos do tipo Scale-out: Eles agora podem ser atualizados sem nenhum downtime ou sem a necessidade de se criar um novo cluster com nós rodando o Windows Server Preview.
  • Web Application Proxy: Agora suporta pré-autenticação para aplicações usando o protocolo HTTP Basic, caracteres especiais em URLs de aplicações, redirecionamento de HTTP para HTTPS, uso de autenticação passthrough com aplicações HTTP e mais.
  • Windows PowerShell 5.0: Inclui novas características como o suporte para desenvolvimento com classes e novos recursos de segurança.
  • Rede: Novo recurso habilita a funcionalidade Generic Routing Encapsulation (GRE) para o Windows Server Gateway.

A lista completa com todas as novidades pode ser encontrada aqui.

Enquanto isso já vamos nos atualizando.


SharePoint 2013: Como criar um sistema de pesquisa online, quiz ou enquete em um site Sharepoint Online ou 2013

Objetivo

O objetivo deste artigo é mostrar um recurso muito interessante do SharePoint 2013 chamado pesquisa.

Visão Geral

Esta opção é muito utilizada quando há a necessidade de se criar um sistema de pesquisa online, enquete ou quiz em um site do SharePoint 2013. Geralmente um sistema de pesquisa, deste porte fica presente dentro de um site com o principal objetivo entreter, buscar conhecimento sobre um determinado assunto através de respostas fornecidas por um usuário. Dependendo da questão a ser tratada o pesquisa do SharePoint 2013  é ainda bem mais amplo porque permite entender o sentimento de pessoas sobre um determinado assunto.

Iniciando o procedimento

1 – Com um site do SharePoint 2013 devidamente aberto clique em: Engrenagem – Configurações do Site.

Exemplo:



2 – Na tela de configurações do site clique sobre a opção Biblioteca e listas do site.



3 – Na opção Configurações do Site – Bibliotecas e Listas do Site clique em Criar novo Conteúdo.

Exemplo:



4 – Dentro do conteúdo do site clique em Adicionar um novo aplicativo.

Exemplo:



5 – Localize o recurso chamado Pesquisa e clique sobre ele.

Exemplo:



6 – Defina o nome do seu sistema de pesquisa e clique em Criar. Neste exemplo o chamei de Quiz de perguntas.

Exemplo:



7 – Com o sistema de pesquisa criado, chegou a hora de criar as perguntas de sua pesquisa para isso clique sobre a opção Adicionar Perguntas.

Exemplo:

 




8 – Em configurações – nova pergunta, digite a pergunta que será utilizada na pesquisa, na sequência defina opção escolha e informe as opções de resposta.

Exemplo:



9 – Marque a opção botões de opção e valor padrão opção. Para inserir uma nova pergunta basta clicar na opção nova pergunta e para finalizar a inserção de perguntas clique em Concluir.

Exemplo:



10 – O próximo passo agora é testar as perguntas cadastradas para isso clique sobre a opção Responder a esta pesquisa.

Exemplo:



11 – Ao clicar sobre a opção Responder a esta pesquisa, marque a opção e clique em próxima para ir para a próxima pergunta a ser respondida, caso seja, a última pergunta a ser respondida no quiz clique em concluir.

Exemplo:



 

12 – Se você mandou o link do quiz para um número de 5 pessoas e quer saber se todas elas responderam ao questionário da pesquisa, observe o número de resposta presente na tela inicial da pesquisa – Quiz de Perguntas.

Exemplo:



13 – É importante lembrar que você tem um gráfico que o auxilia na leitura de informações da pesquisa realizada no quiz para isso basta utilizar a opção Mostrar um resumo gráfico das resposta.

Exemplo:



14 – Um histórico também é apresentado caso você queira consultar o nome de quem as respondeu por exemplo para isso é necessário que você acesse a opção Mostrar todas as resposta.

Exemplo:



15 – Uma outra opção também que você pode utilizar é a opção Exibir onde é possível visualizar o recurso Visão Geral, Resumo Gráfico e Todas as resposta de forma simples e rápida.

Exemplo:



Fonte: Microsoft

Passo a passo para Integração do Active Directory Azure com Ad Azure, Office 365 e Active Directory Local e uso do Remote App para DaaS com Cloud Hibrida.

 

Este procedimento é uma iniciativa de uso de Desktop como Serviço como Citrix RemoteApp, o próprio RemoteApp da Microsoft e o novo serviço que a Microsoft está oferecendo nos serviços do Azure como AzureRemoteApp.

Foi abordado alguns serviços como Azure AD, Office 365, rede VPN e rede do Azure e o próprio RemoteApp.

A integração total durou 40 horas pela complexidade do uso do AD local, documentação para integração.

 

 

Entrar no Menu Active Directory Azure e ir no botão novo.

 

Neste menu você pode escolher um novo Diretório do AD, mas neste caso nós iremos escolher um diretório existente.

Altere para diretório existente e prossiga

OBS: Ele irá pedir para desconectar o Administrador Global para o processo prosseguir.

 

No próximo passo autentique com o Administrador Global do Seu Office 365.

Pronto você já vai se autenticar com o seu usuário do AD Azure do Office 365.

 

 

Active Directory Azure integrado

 

Usuários integrados ao ADazure

No caso nós iremos usar o AD local, é preciso utilizar o ADSync.

 

O passo a passo está neste Link como referência.

http://mauriciocassemiro.com/2014/02/24/implantando-o-servidor-de-sincronizao-de-diretrios-dirsync-no-windows-server-2012-r2/

 

Remote APP

Neste RemoteApp utilizamos as licenças BASIC que é até 20 usuários.
Para consumidor final o valor por usuário é de R$48,00 e quem utiliza plano pré-pago como contra E.A os valores são mais atrativos.

Próximo passo, vincular a uma rede virtual.

A rede virtual privada é um dos passos para que o RemoteApp funcione de forma hibrida, neste caso você vai vincular ele a sua rede de produção, homologação ou desenvolvimento.

OBS: A rede do Azure é um passo importante por isso consulte um administrador de rede como conhecimento de Nuvem Azure para que funcione corretamente.

 

 

Agora é necessário ingressar no domínio utilizando uma conta de serviço valido e seu caminho de unidade organizacional.

OU: OU=Usuarios_Servicos,OU=SEUDOMINIO,DC=NOME,DC=NOME,DC=com,DC=br

 

 

Agora, precisaremos vincular a imagem do servidor onde a aplicação está instalada.

Essa imagem, é de algum servidor onde a aplicação foi instalada e copiado o VHD para o diretório de images do remoteapp.

 

 

Antes de vincular a imagem, é preciso no servidor onde a aplicação está instalada, rodar um sysprep.

 

Depois de rodar o Sysprep capturar a imagem da máquina virtual criada.

 

Após preparar a máquina virtual para o sysprep, a máquina irá rodar por mais ou menos 2 horas.

No menu do RemoteAapp é preciso autorizar os usuários que irão acessar a aplicação.

 

IMPORTANTE: Na criação da máquina virtual hibrida foi usado a ISO já preparada para RemoteApp Windows Server 2012 R2 Session Host. Caso for usar uma imagem simples não funcionará.

Este processo irá demorar de de 1 a 3 horas para o processo de crição da Imagem desde o Sysprep até a imagem aparecer para criação do RemoteApp.

Após todo processo é só inserção dos usuário que irão acessar a aplicação virtualizada.

Terminando o processo você estará apto a utilizar o RemoteApp.

Acessar o site https://www.remoteapp.windowsazure.com/.

Baixar a aplicação

Instalar a aplicação

Ele fara o streaming da aplicação.

Após baixar a aplicação acesse para a primeira autenticação.

Após a autenticação você pode acessar a aplicação virtualizada.

 

Aplicação em funcionamento.

 

Referencias: http://mauriciocassemiro.com Dyrsync (Adsync)

– Criar uma imagem do RemoteApp com base em uma máquina virtual do Azure:

https://azure.microsoft.com/pt-br/documentation/articles/remoteapp-image-on-azurevm/

 

– How To Publish an Internal Windows App on Azure Remote App:

http://blogs.technet.com/b/gbanin/archive/2014/12/10/how-to-publish-an-internal-windows-app-on-azure-remote-app.aspx

 

– Documentação complete do Azure RemoteApp:

https://azure.microsoft.com/pt-br/documentation/articles/remoteapp-whatis/

Agradecimento ao apoio do Vinicius Apolinario e Weberson Pontes (Microsoft) e Referencia do Mauricio Cassemiro.

 

 

 

 

 

Você sabe o que é DEVOPS?

O que é DevOps afinal?//

O que é DevOps afinal?

Mar 16th, 2013 | Comments

1. Papo sobre DevOps

Hoje vim falar sobre a buzzword DevOPs. Algumas pessoas tem me procurado pelo blog para conversar sobre este termo, e normalmente eles querem que eu responda as seguintes perguntas:

  1. O que significa DevOps?
  2. DevOps é um movimento?
  3. DevOps é uma filosofia, é um conceito ou uma cultura?
  4. DevOps é uma metodologia?
  5. DevOps é algum tipo de ambiente ou grupo de ferramentas ?
  6. O especialista DevOps é um devel que entende de infra?
  7. O especialista DevOps é um sysadmin que entende de devel?
  8. DevOps é um cargo? é um setor ou um departamento?
  9. DevOps só funciona em startups ou serve para o ambiente corporativo?
  10. O DevOps é algo novo?

Ao longo do texto eu pretendo responder a todas estas questões, mas para respondê-las vamos precisar entender algumas coisas antes.

2. Como tudo começou?

Para que possamos compreender de forma plena, precisamos ir ao cerne desta história. O movimento DevOPs não começou em um lugar só, existem muitos lugares que dão pistas sobre as origens do termo, mas aparentemente as informações mais concretas sobre as origens deste movimento nos levam ao ano de 2008. Neste ano, começaram a utilizar o termo infraestrutura ágil em algumas listas de discussão com foco em desenvolvimento ágil, e na mesma época durante evento Agile 2008, surgiram conversas que abordavam o tema metodologia ágil para a administração de infraestrutura, inspirada no modelo ágil de desenvolvimento, no entanto, foi a lista de discussão européia com nome agile-sysadmin que começou a abordar o tema com propriedade, com isso ela ajudou a colocar os primeiros tijolos na ponte que faria a ligação entre developers e sysadmins. Um dos participantes desta lista era Patrick Debois (@patrickdebois), além de muito ativo ele era e ainda é um grande entusiasta do assunto.

O termo DevOPS só foi criado de fato em 2009 durante a conferência Velocity da O’Reilly, nesta conferência John Allspaw (Etsy.com) e Paul Hammond (Typekit) apresentaram o trabalho 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr, veja abaixo os slides desta palestra.

A palestra acima deixou Patrick Debois muito animado, foi então que ele teve a ideia de criar um encontro chamado DevOpsDay, este encontro ocorreu em Ghent no final de 2009, foi um encontro de dois dias e aparentemente foi lá que tudo começou.

De lá para cá, Patrick Debois, Gildas Le Nadan, Andrew Clay Shafer, Kris Buytaert, JezzHumble, Lindsay Holmwood, John Willis, Chris Read, Julian Simpson, R.I.Piennar (mcollective) e muitos outros levaram o evento para diversas localidades, dentre elas:

  • New York 2012
  • Rome 2012
  • Mountain View 2012
  • India 2012
  • Tokyo 2012
  • Austin 2012
  • Goteborg 2011
  • Bangalore 2011
  • Melbourne 2011
  • Mountain View 2011
  • Boston 2011
  • Göteborg 2011
  • Sao Paulo 2010
  • Hamburg 2010
  • Mountain View 2010 (video intro)
  • Sydney 2010
  • Ghent 2009

É importante falar que ao levar o evento para diversos países, estas pessoas foram responsáveis por disseminar a cultura DevOps pelo globo, com isso, direta ou indiretamente eles se tornaram a força motriz de uma discreta revolução no mundo da TI.

Inicialmente a cultura DevOps se mostrou muito presente no ambiente das startups, porém, algum tempo depois começou a fazer parte do mundo corporativo, aqui neste texto procuro trazer a visão da cultura DevOps no meio corporativo.

Na abertura do evento DevOpsDay há sempre um vídeo de intro, veja dois deles:

Ghent 2009

Mountain View 2010

3. DevOps Manifest

Apesar de terem organizado o DevOpsDays em diversos países, não foi estabelecido um manifesto para o assunto, logo existem muitas interpretações acerca deste termo.

Mas antes de argumentar acerca do possível conteúdo de um manifesto DevOps, primeiro temos que entender a dinâmica na relação entre as áreas de infraestrutura (infra) e desenvolvimento (devel).

4. Analisando Infra e Devel

Para entender melhor o que DevOps significa, precisamos então analisar de forma prática e direta a vida de sysadmins, desenvolvedores e o cotidiano destas áreas, eu espero que isto lhe ajude a compreender melhor o assunto adiante.

Vamos imaginar – hipoteticamente – uma empresa de comunicação que desenvolve aplicações web em sua maioria para portais de notícias, e em alguns casos também faz aplicações web internas (rh, financeiro, administrativo), nessa empresa o devel trabalha com PHP, PYTHON, RUBY e JAVA.

Para um melhor entendimento, considere as duas características abaixo como cotidianas nesta empresa fictícia:

  1. O Devel está começando a trabalhar com metodologias ágeis (pró-ativo, evolutivo e contínuo).
  2. A Infra continua trabalhando no modelo tradicional de administração (manual, caótico e reativo).

4.1 Infra em foco

A infra é composta em parte pelos sysadmins, estes rapazes e moças tem a missão de manter os sistemas funcionando, são eles que fazem os deploys e os rollbacks das aplicações do devel, é responsabilidade deles manter o ambiente de produção intacto.

Os sysadmins tem que rodar as aplicações, monitorar o funcionamento, a performance, avaliar e propor melhorias de forma a manter as aplicações sob seu cuidado a pleno vapor – rodando de forma rápida e estável, além disto, eles devem planejar as mudanças com cautela, tentando minimizar os riscos envolvidos.

Eles se preocupam com segurança, estabilidade e principalmente com o acordo de nível de serviço (SLA) de cada produto sob sua responsabilidade, esta preocupação é fundamental para o negócio.

Entenda que se uma aplicação parar de funcionar isto vai impactar no SLA, podendo significar perdas financeiras significativas relacionadas ao produto, afinal produto fora significa cliente insatisfeito e prejuízo, seja ele financeiro, seja ele institucional, e no caso da sustentação do produto, isto significa que a prestadora do serviço, neste caso a empregadora dos sysadmins, pode ser multada. De toda o jeito, o que ocorre de forma direta é diminuição do valor do negócio.

Em resumo, a infra (sysadmins) se preocupa em proteger o valor do négocio.

4.2 Devel em foco

O devel é composto em parte por desenvolvedores, estas moças e rapazes trabalham com lógica e criatividade, eles passam boa parte de seu tempo codificando soluções, e focam seu trabalho nos requisitos que o analista conseguiu mapear junto ao cliente.

Os desenvolvedores estão constantemente criando e aprimorando suas aplicações, com isto novas versões são criadas e precisam ser disponibilizadas, assim seus clientes poderão usufruir dos recursos solicitados.

Nova versão significa novo deploy, e caso ocorra algum problema, isto irá demandar um rollback, ambos procedimentos envolvem equipes de infra.

Em resumo, podemos dizer que o devel se preocupa em aumentar o valor do negócio.

4.3 Onde está o conflito?

Os desenvolvedores querem colocar suas aplicações no ar o mais rápido possível, no entanto os sysadmins querem ter certeza que a aplicação está estável o suficiente para entrar em produção sem gerar incidentes.

Nos últimos anos esse conflito foi latente no mundo de TI, algumas empresas tinham regras tão rígidas que só permitiam deploy uma vez por semana – em casos mais rígidos apenas uma vez por mês, tudo isto pensando em proteger o negócio.

Com o devel mudando de metogologia, nem preciso dizer que esse método de deploy – uma vez por semana – não combina com desenvolvimento ágil, com isso a infra teve que evoluir a fórceps, e quem antes fazia deploy uma vez por semana, teve que aprender a fazer várias vezes por dia.

É claro que a infra trabalhando com os métodos que estava acostumada (deploy 1 vez por semana e manual) não dava vazão as demandas, e também é óbvio que o devel não possuía uma infra adequada para fazer o desenvolvimento de forma contínua.

Além de tudo isso, normalmente o devel não conhece e não tem como prever aspectos importantes relativos a infra que fica de cara para o cliente, portanto, quando a aplicação vai para produção, normalmente ocorrem – constantes – pequenos incidentes que geram uma enorme perda de valor no negócio. Traduzindo, são aqueles ajustes na aplicação que precisam ser feitos de última hora pois o ambiente devel é completamente diferente da produção.

O cliente por sua vez reclama – com razão – e depois a gerência de TI ficava tentando encontrar o dono do problema (caça as bruxas), de um lado devel dizendo que infra é engessada, lenta e que não oferece um ambiente adequado para desenvolverem suas aplicações, do outro lado a infra dizendo que o devel faz código ruim e instável e que não é culpa deles se a aplicação não funciona.

Eu sou de infra há muitos anos, mas tenho que dizer que a infra devido a culturas arcaicas de administração, heranças do tempo dos mainframes, tem mais culpa no cartório neste cenário, porém o devel também tem seus problemas, afinal, como estão começando a aplicar métodos ágeis, ainda estão criando a cultura de execução de testes e garantia de qualidade (QA).

4.3.1 Incidentes

Quando ocorre algum incidente, você vai ouvir da infra falando para o devel que o problema não são as máquinas, é o código, e certamente o devel vai falar para infra que o problema não é o código, são as máquinas, e provavelmente ainda vão dizer que o sistema está funcionando no notebook deles, e infelizmente isso será algo cotidiano.

Espero que neste ponto você já esteja enxergando o problema.

É preciso entender que infra e o devel trabalham em nichos, cada um no seu quadrado, cada um em sua realidade e nenhum deles está muito disposto a mudar sua cultura, nenhum deles está disposto a ceder. A infra não conhece o devel e não sabe como mudar para ajudá-los, o devel não conhece a infra e não sabe como pedir o que precisam.

No final das contas, as pessoas não conseguem estabelecer uma forma sadia e eficiente de comunicação, e com isso, não existe trabalho colaborativo entre estas duas áreas.

4.4 O combustível do conflito

Acima eu apresentei o conflito comum entre as áreas, porém existe o combustível que o mantém acesso, e esse combustível é o comportamento do sysadmin, portanto, há de fato uma razão para se ter tanto ódio deles, vamos a elas:

  • Eles falam não
  • Eles falam não pela segunda vez
  • Eles falam não pela terceira vez
  • Eles falam não o tempo todo por diversas razões, para diversos pedidos
  • Eles demoram, atrasam e perdem prazos de atendimento
  • Eles se recusam a quebrar as coisas mesmo que seja para encontrar o problema
  • Eles se preocupam com UPTIME e não com o negócio
  • Eles acham que o devel só quer saber de perfumarias e coisas do gênero
  • Eles não se esforçam para ajudar o devel a encontrar o problema
  • Eles acham que o problema do devel não é problema deles
  • Eles não conseguem enxergar o negócio e não enxergam que infra e devel são parte de um todo

E isso tudo faz parte daquele comportamento arcaico que eu já mencionei, eu quis reforçar isto pois é bom mostrar as raizes de um problema para ajudar na reflexão do que é preciso mudar.

Veja que tal comportamento é inaceitável e incompatível com o mundo de hoje, mesmo assim ainda é muito comum encontrar pessoas que possuem este tipo de atitude e perfil.

4.5 Uma pitada de realidade

Lembra que eu disse que a infra se preocupa em proteger o negócio e o devel se preocupa com as formas de agregar valor ao negócio?

Esqueça o que eu disse, isso funcionava nos anos 70/80/90, mas hoje isso não é suficiente.

A infra deve entender que sua obrigação é oferecer os meios para fazer o negócio fluir, e isso também é papel do devel.

Ambas equipes precisam mudar a forma de pensar e de agir, porém é preciso ter consciência de que mudanças estão associadas a problemas, uma mudança pode quebrar seu produto e afetar o seu negócio.

Então qual é a receita mágica?

Como mudar sem afetar o negócio?

4.6 Mudanças necessárias

A infra previsa evoluir, e precisa fazer isto rapidamente.

O devel predisa ter controle de todas as fases do deploy.

A infra precisa começar a trabalhar de forma automatizada e dinâmica, precisa ser mais veloz para subir novos ambientes ou mesmo reconstruir/duplicar os ambientes existentes para suprir as necessidades do devel, não dá mais para trabalhar de forma manual e usar as mesmas metodologias da época dos mainframes.

O devel precisa conseguir passar para infra suas necessidades de forma clara, e tem que se esforçar para fazer a infra entender isto – e eles não vão entender na primeira vez.

4.6.1 Busca de soluções

E foi a busca de soluções para estas necessidades que motivou importantes discussões no mundo da TI, foi então que começaram a falar de ‘Infraesturura ágil’ no ano de 2008, vamos agora entender o que é isso.

5. Infraestrutura ágil

5.1 Infraestrutua como código

A discussão acerca de infraestrutura ágil ganhou força com o crescimento de duas tendências, são elas virtualization e cloud computing. Desde 2003 empresas começaram a conviver com ambientes virtualizados, logo um parque com poucas máquinas físicas poderia se tornar um parque com dezenas máquinas virtuais, e após o recente advento da Cloud, dezenas de máquinas virtuais podem se tornar centenas ou milhares de instâncias a serem administradas na nuvem.

Não havia mais espaço para se trabalhar infraestrutrua da forma tradicional, foi necessário dar um passo a diante e pensar em infraestrutura como código, principalmente quando paramos para analisar o recente boom das startups, empresas pequenas com produtos de enorme alcance, produtos que rodam em centenas de instâncias na nuvem, atendendo milhões de usuários, e tudo isso é administrado por equipes mínimas.

O objetivo é fazer deploy não só de aplicações, mas deploy de infraestrutura de forma rápida e controlada.

Isso significa que se você precisa subir um ambiente JBOSS você vai fazer isto em poucos minutos e não em dias.

5.2 Ferramentas de infraestrutura ágil

Quando se fala em infraestrutura ágil o que vem a mente são ferramentas, e de fato elas são parte disto.

Basicamente temos três tipos de ferramentas, são elas:

  1. Orquestradores
  2. Ferramentas para gerenciamento de configurações
  3. Ferramentas para bootstrapping e provisionamento

Orquestradores são ferramentas que nos permitem executar comandos e controlar nodes/instâncias de nosso parque em tempo real. Alguns destes são Fabric, Capistano, Func e Mcollective.

Ferramentas de gerência de configuração normalmente controlam estados de seu sistema, ajudam a centralizar toda as configurações e facilitam a administração e criação de novos ambientes. Algumas delas são Puppet, Chef, Cfegine e Salt.

Ferramentas de bootstrapping são aquelas que nos ajudam a instalar um sistema operacional seja em uma máquina física, seja em um máquina virtual, seja em uma instância na nuvem, dentre elas temos alguns provedores de CLOUD como AWS e Rackspace que já oferecem isso nativamente, existem também ferramentas como o Kickstart e Cobbler que atuam neste segmento.

A combinação destes três tipos de ferramentas nos permite ter o que chamamos de infraestrutura ágil.

Mas apesar da qualidade e dos ganhos em utilizar tais tecnologias, a ferramenta sozinha não resolverá seus problemas, é preciso mudar a cultura e a forma de trabalhar a infraestrutura.

5.3 Equipe de infraestrutura ágil

Equipes que trabalham com infraestrutura ágil também precisam de um método diferenciado de organização, normalmente estas equipes estão trabalhando seguindo estes eixos:

  1. Versionamento do código e arquivos de configuração (git)
  2. Organização de atividades de forma visual (KANBAN BOARD)
  3. Trabalho em pares
  4. Divisão das atividades em sprints
  5. Reuniões ágeis diárias (standup meeting de 10 minutos – em pé)
  6. Reuniões ágeis periódicas (retrospectiva e planejamento de sprints).

Parece com SCRUM mas não é, mas é fortemente inspirado nele e no Kanban.

5.4 Então DevOps e Infraestrutura ágil são a mesma coisa?

Não, infraestrutura ágil é parte da cultura DevOps.

DevOps depende de infraestutura ágil, mas ainda tem muito mais.

Apesar da evolução da infra, ainda falta algo que conecte as duas áreas, precisamos de um agente de mudanças principalmente no meio corporativo.

6. Cultura DevOps

Chegou a hora de entrar neste assunto, agora nós vamos aprofundar nossos estudos em relação a cultura DevOps.

6.1 Características da cultura DevOps

Para entender a cultura devops sem fazer um texto muito longo, vou pontuar as suas principais características – em minha opinião.

6.1.1 Em relação as características da cultura

Patrick Debois (foi quem cunhou o termo) diz que DevOPs essencialmente é uma cultura, e a descreve utilizando 4 eixos, são eles:

  • Cultura
    • Colaboração
    • Fim das divisões
    • Relação saudável entre as áreas
    • Mudança de comportamento
  • Automação
    • Deploy
    • Controle
    • Monitoração
    • Gerência de configuração
    • Orquestração
  • Avaliação
    • Métricas
    • Medições
    • Performance
    • Logs e integração
  • Compartilhamento
    • O feedback é tudo
    • Boa comunicação entre a equipe

Eu prentendo detalhar um pouco mais estes eixos, vamos lá.

6.1.2 Em relação as características técnicas

Um ambiente DevOps deve ter/possuir/oferecer/permitir:

  • Infraestrutura como código
  • Orquestração de servidores
  • Gerência de configurações
  • Provisionamento dinâmico de ambientes
  • Controle de versões compartilhado entre infra e devel
  • Ambiente de desenvolvimento, teste e produção (no mínimo)
  • O ambiente de devel deve possibilitar TDD
  • Infra deve participar dos projetos desde o início [1]
  • Infra deve participar das reuniões de devel [2]
  • Devel deve participar das reuniões de infra [3]
  • Ambiente de entrega contínua [4]
  • Os desenvolvedores devem conseguir fazer o deploy sem interferência da infra [5]
  • Monitoramento eficaz com processamento adequado dos eventos e métricas
  • Capacidade de resposta rápida a incidentes e problemas
  • Backup e restore confiável

[1] O devel precisa envolver a infra nos projetos desde o início – isso significa participar das reuniões técnicas ou SCRUM, afinal sem a infra não há projeto, e além disto, quanto mais problemas foram resolvidos durante o projeto – com ajuda da infra, menos problemas serão expostos aos clientes.

[2] A infra também precisa observar quais são as metas da empresa a longo prazo, principalmente aquelas ligadas ao devel, pois enxergando onde o devel quer chegar, ela pode se programar melhor para ter certeza que a infraestrutura tecnológica estará preparada para atendê-los quando esse momento chegar.

[3] A infra precisa envolver o devel em suas reuniões técnicas para que o devel entenda e tenha ciência da realidade da infra, assim eles vão conseguir enxergar suas qualidades, atribuições, planos de melhorias, atualizações programadas, agendas de manutenção, eles vão conhecer os recursos disponíveis e também descobrir a limitações da equipe, sejam elas técnicas, sejam materiais. Além disto, o devel pode ser um grande aliado da infra na solução de problemas, afinal o conhecimento que o devel traz pode ajudá-los a melhorar a forma com que administram seu ambiente, tornando este processo mais eficiente.

[4] O devel precisa adotar alguma metodologia de entrega ou desenvolvimento contínuo e a infra precisa entender esse processo para que juntos criem os ambientes com as ferramentas certas.

[5] A infra precisa ceder um pouco e evoluir, precisa oferecer ao devel um ambiente adequado onde eles sejam o dono do produto, onde o devel consiga fazer todo o ciclo de desenvolvimento de forma direta, o devel precisa conseguir gerar e controlar o código, precisa fazer o commit com segurança, precisa fazer o build, testar o build, validar a aplicação e entregar a nova versão de forma transparente sem que para isso precise passar por um burocrático e engessado processo de mudança.

6.1.3 Em relação aos valores humanos

Para a adoção da cultura funcionar, a equipe precisa observar e exercitar os seguintes valores:

  • Confiança no trabalho de sua equipe
  • Respeito pessoal e profissional por todos da equipe
  • Sinceridade sobre eventos e incidentes ocorridos
  • Honestidade sobre as causas dos incidentes (não esconda nada da sua equipe)
  • Entendimento de que o problema é responsabilidade de todos
  • Entendimento de a solução é responsabilidade de todos
  • Entendimento de que os resultados são o reflexo do trabalho de toda a equipe
  • Comunicação efetiva e dinâmica
  • Postura construtiva sempre
  • Espírito de colaboração

6.1.4 Em relação a forma de trabalho

É recomendavél que a equipe:

  • Internalize e adapte métodos ágeis como KABAN e SCRUM para seu dia-a-dia
  • Aprofunde estudos em entrega contínua
  • Aprofunde estudos em gerência de configurações e orquestração

Acho que é isso, características técnicas, valores humanos e forma de trabalhar, espero que tenha ficado claro para você.

6.2 Aplicando a cultura

Após observar as principais características deste movimento, normalmente pensamos em como aplicar isto em nosso meio. Para ajudar na reflexão vamos avaliar o meio startup e o meio corporativo.

6.2.1 A realidade no ambiente startup

A cultura DevOPs combina muito com startups, nestes locais normalmente já se trabalha desenvolvimento utilizando metologias ágeis, foi inclusive neste nicho em que começaram a discutir infraestrutura ágil – a precursora do movimento devops, portanto, as pessoas deste meio conseguem absorver os conceitos e a cultura DevOPs sem grandes dificuldades, eles conseguem compreender os preceitos de colaboração e feedback pois já fazem isto em seu dia-a-dia.

Quem está uma startup não tem as amarras e vícios da coporação, este é um grande facilitador e não é necessário nenhum tipo de intervenção para internalizar a cultura, a partir do estímulo de um líder as pessoas começarão a estudar e aplicar DevOPs naturalmente.

Na startup normalmente não existe divisões, departamentos, todos trabalham juntos e isso também é um facilitador, afinal não existem barreiras para se comunicar.

6.2.2 A realidade no ambiente corporativo

A corporação não funciona como a startup, lá existe burocracia e o uso vicioso de métodos ultrapassados, portanto não bastará o estímulo da alta hieraquia para que equipes de infra e devel comecem a vivenciar a cultura DevOPs, neste tipo de ambiente, em minha opinião pessoal e profissional, é necessário intervir cirurgicamente para conseguir internalizar a cultura DevOps.

Em resumo, você precisa trazer alguém – de fora – que conhece DevOP para que esta pessoa passe a contaminar os demais.

Esse processo é lento, mas se o especialista tiver os meios e o apoio do alto escalão, mudanças fantásticas poderão ocorrer.

6.3 O especialista DevOps no meio corporativo

Ele foi trazido para atuar como um agente de mudanças, ele precisa contaminar as áreas e mostrar que a cultura DevOps funciona.

6.3.1 Característica gerais de um especialista DevOps em 2013

  • Está na casa dos 30 anos ou mais
  • É um profissional sênior em infraestrutura
  • Tem um bom background em desenvolvimento
  • Tem um bom background em metodologias ágeis
  • Tem sólidos conhecimentos em soluções opensource e similares
  • Trabalha intensamente com automação e infraestrutura como código

6.3.2 Onde esse especialista atua?

Este especialista em DevOps terá um pé na infra e outro no devel, em alguns casos também terá o pé na área de garantia de qualidade (QA).

Ele é a cola que faltava para unir infra, devel e qualidade.

6.3.3 Como esse especialista atua?

Ele será a ponte entre as áreas de infra e devel, ele conhece a infra a fundo e entede de forma ampla processos de desenvolvimento ágil.

6.3.3.1 Pé no devel

Ele participa dos projetos de desenvolvimento desde o seu nascimento, seu foco é oferecer os recursos para os desenvolvedores trabalhem da forma mais eficiente, além disto, com sua ótica de infra ele toma todas as precauções para que os aspectos de segurança, monitoramento, eficiência e escalabilidade sejam observados desde o início do projeto.

O DevOps vai ainda estudar todo o processo de desenvolvimento e definir – em conjunto com o devel – as ferramentas que irão permitir um processo de desenvolvimento e entrega contínua. Após definir ele vai instalar e manter esse infra.

Alguns DevOps conseguem até avaliar o código do produto e enxergar problemas de performance, esse tipo de visão sistêmica e raciocínio rápido são diferencias importantes para uma entrega com mais qualidade.

6.3.3.1 Pé na infra

Na infra ele é o principal agente de mudanças, é ele que vai puxar a fila para iniciar a implantação de uma infraestrutura ágil, ele domina as ferramentas de orquestração, gerência de configuração e provisionamento e vai usar esse conhecimento para que a equipe passe a trabalhar a infraestrutura como código.

Este profissional também vai ajudá-los a mudar seu comportamento e cultura, ele vai orientá-los nos métodos ágeis de execução de atividades, aqueles inspirados no SCRUM e KANBAN.

6.4 Ele fica na infra ou no devel?

Para internalizar DevOPs, normalmente estas barreiras não existem, infra e devel devem habitar o mesmo espaço, sem paredes, sem divisórias, todos na mesma sala, isso é fundamental para extinguir os nichos e criar uma equipe mais unida e coesa.

Respondendo a pergunta, ele deve ficar junto com as duas equipes se for possível, esse é o melhor dos mundos.

Se não for possível ficarem todos juntos, o especialista deve se esforçar para interagir com as duas equipes diariamente.

Ele vai ser o agente de mudanças até que infra e devel comecem a entender e adotar a cultura de forma natural.

7. Quais os ganhos em adotar a cultura DevOPs?

Vamos avaliar dentro da ótica de cada área o que melhora com a adoção da cultura DevOPs.

7.1 Ganhos para a infra

  • Infraestrutua como código (equipe para de administrar e passa a desenvolver a infra)
  • Infra mais eficiente e rápida usando métodos ágeis
  • Equipe de Infra mais organizada
  • Equipe de Infra se comunicando melhor
  • Infra fazendo mais em menos tempo com menos gente
  • Ambientes de gerência de configuração, orquestração e provisionamento implantados
  • Deploys de infra (novos ambientes) mais rápidos e seguros => entrega rápida
  • Ambiente padronizado e sob-controle
  • Feedback rápido em todas as atividades de infra

7.2 Ganhos para o devel

  • Devel tem ambiente mais adequado para trabalhar (dev/teste/prod)
  • Devel passa a contar com ambiente de desenvolvimento contínuo
  • Devel passa a contar com testes automatizados
  • Deploys de apps (novas versões) mais rápidos e seguros => entrega rápida
  • Feedback rápido em todas as fases de desenvolvimento

7.3 Ganhos mútuos Infra/Devel

  • Acaba a divisão Infra vs Devel (acaba a guerra)
  • Infra participa dos projetos e acompanha de perto tudo o que acontece
  • Infra participando resulta em melhor planejamento do ambiente de produção
  • Infra participando resulta em monitoramento mais eficaz da aplicação
  • Devel começa a compreender melhor a infra e isso resulta em um produto melhor
  • Equipes trabalhando em conjunto para aumentar o valor do negócio

7.4 Ganhos para a empresa

  • Melhor comunicação entre devel e infra (diminuição de conflitos)
  • Soluções rodando com maior estabilidade e desempenho
  • Entregas mais rápidas
  • Menor tempo de paradas
  • Diminuição de incidentes
  • Diminuição de custos
  • Diminuição de riscos
  • Aumento do valor do negócio

8. Amarrando as pontas

Vamos partir para perguntas e respostas no melhor estilo FAQ.

8.1 Indo direto ao ponto (e respondendo as perguntas do início)

Respondendo sobre o termo DevOps:

  1. DevOps está diretamente relacionado a um melhor feedback entre as áreas de TI.
  2. DevOps é um movimento, é um conceito, é uma cultura e uma filosofia, e não existe uma explicação fácil.
  3. DevOps possibilita diminuição dos riscos de mudanças através do uso de um ferramental adequado e adoção de uma cultura específica.
  4. DevOps busca entregar sistemas melhores, com menor custo, fazendo isto de forma mais rápida e com menor risco.
  5. DevOps envolve a área de Infra e Devel primáriamente.
  6. DevOps é pura metodologia ágil tando na Infra quanto no Devel.
  7. DevOps só funciona se as equipes de infra e devel estiverem dispostas a ceder, mudar sua cultura e método de trabalho.
  8. DevOPs não é um cargo, tão pouco um setor ou departamento, é uma cultura.
  9. DevOps não está restrito ao ambiente das startups, é possível utilizar essa cultura no meio corporativo.
  10. DevOps não é algo novo, as boas práticas estão ai desde de sempre, logo esse ‘juntado’ de práticas não é novidade para muita gente, mas para alguns serve como uma boa referência para aplicar mudanças necessárias.

Respondendo sobre o especialista em DevOps:

  1. O especialista em DevOps de hoje é normalmente alguém que conhece muito de infra e tem uma base sólida de devel.
  2. O especialista em DevOps também pode ser alguém que veio do devel e que tem uma base sólida de infra (esse geralmente é mais completo).

8.2 Quero ser um DevOps e não sei por onde começar

Não há um tutorial para isto, minha recomendação é que você estude desenvolvimento ágil e procure entender o processo de desenvolvimento do local onde você trabalha, estude ferramentas para desenvolvimento contínuo, estude ferramentas de gerência de configuração, orquestração e provisionamento, fazendo isto você poderá dar os primeiros passos como entusiasta da cultura DevOps e estará apto a atuar em seu ambiente, você poderá agir como uma ponte entre as áreas de devel e infra, e principalmente, poderá modernizar os processos e o ambiente de infra.

8.3 Eu trabalho com infra ágil, sou um DevOps?

Não existe uma entidade certificadora, uma prova ou alguém que possa lhe conceder este título, não existe um manual de conduta para dizer se você é um DevOps ou não, mas em 2013 é bastante comum encontrar profissionais que estão estudando infraestruta ágil e se denominando DevOps.

Se você está buscando melhorar seu ambiente, entregar mais rápido, entregar algo com mais qualidade, algo que minimize custos, algo que diminua riscos, algo que envolva automatização pesada, se você trabalha infraestrutura como código, se você está atuando como um agente de mudanças em sua equipe, penso que DevOps é um termo adequado para descrever o seu trabalho, mesmo que não esteja diretamente envolvido com uma equipe de Devel.

8.4 Não existe receita mágica ou caminho rápido

Como eu já mencionei não existe uma metodologia clara, DevOps ainda é um movimento em constante construção e definição, eu citei uma série de melhorias que fazem parte da cultura DevOps, cabe a cada empresa ou a cada gestor estudar e descobrir a melhor forma de combinar essas pequenas receitas técnicas e aplicar em seu ambiente.

Espero que este artigo tenha te ajudado a entender melhor a cultura DevOPs.

9. Referências

Sites

Slides

Fonte das imagens

[1] Dev OPs: https://devcentral.f5.com/blogs/us/devops-is-not-all-about-automation
[3] Ops Burn: http://devops.com
[4] Combusível: http://www.huffingtonpost.com
[5] DevOps Diagram: http://www.skybotsoftware.com/skynews/2012/07/24/why-devops-more-trend

Fone principal: http://gutocarvalho.net