MLOps (Machine Learning and Operations) no Azure

O MLOps (Machine Learning e Operations), de forma similar ao DevOps, é a combinação de práticas e ferramentas que permitem aos times de Data Science e Operações melhorar a implementação de modelos, através da governança de modelos de ML (Machine Learning) e IA, monitoramento, validação, colaboração e comunicação.

MLOps-MSFT
Figura: Microsoft Azure – MLOps

Isso porque segundo Gartner, muitas empresas estão desenvolvendo modelos de Machine Learning, mas apenas 47% deles são publicados em produção. E ainda 88% das iniciativas de IA possuem dificuldades para passar do estágio de teste.

Azure ML é composto de interfaces web e SDK que faz o treinamento e deploy do modelo. O processo (figura abaixo) envolve a gestão dos dados, limpeza dos dados, escrevendo e executando experimentos, publicando os modelos para coletar os dados reais (em produção) e aplicar melhorias nos modelos.

MLOps

  • Experiment: os cientistas de dados realizam diversos experimentos, evoluindo e coletando dados, a procura de respostas para as necessidades do negócio. Fundamento nos conceitos de DevOps e da Engenharia de Software, o MLOps sugere práticas para evitar a promoção de modelos mal escritos a outros ambientes.
  • Develop: o treinamento dos algoritmos (Azure ML Training Services), ETL (Data pipelines) e as práticas de CI/CD para criação dos Pipelines (Azure DevOps Pipelines) de deploy dos experimentos construídos de ML.
  • Operate: inference, monitoramento (com uso de analyse/profile, app telemetry, etc.), testes automatizados e data feedback loop para aprendizado com os dados que levam a melhorias nos modelos.

 

Vantagens

Com os times trabalhando juntos (cientistas de dados e operações), encorajam as operações de negócio data-driven, reduzindo o gap entre a descoberta de insights e ações de implementação. Algumas das vantagens são:

  • Reprodutibilidade e auditabilidade: a criação dos modelos em pipelines específicos e reproduzíveis, possibilitando rollbacks (em caso de erros) e auditorias, caso seja necessário algum rastreamento.

  • Validação: herda conceitos de DevOps como validações automáticas, testes, profiling e gestão de ambientes.

  • Habilita automação e observabilidade ao realizar novas implementações. Permite a comparação entre predicted x expected performance. Coleta as informações que servem de treinamentos aos modelos para melhorias futuras.

 

Fases do MLOps

O framework DevOps para soluções AI no Azure pode ser macro representado dessa forma:

Azure-AI-solutions

E compreende quatro principais fases entre a criação até a implantação dos modelos:

  1. Criação e treinamento dos modelos: use o treinamento com pipelines de aprendizado para criar pipelines reproduzíveis, reunindo todas as etapas (da preparação de dados à avaliação do modelo).
  2. Implantação de modelos: empacotamos o modelo para implantação e a criação de perfil para ajudar a configurar memória, CPU e validar os modelos.

  3. Automatizar o aprendizado E2E: atualizar frequentemente os modelos com Azure Machine Learning e GitHub, testar e implementar continuamente com outros aplicativos e serviços.

  4. Trilha de auditoria: coletar os dados de ponta a ponta para estabelecer uma trilha de auditoria. Por exemplo: dados do publicador dos modelos, data de implementação, uso em produção, etc.

fases-MLOpsFigura: Microsoft Azure – MLOps (adaptada)

 

 

Azure DevOps x Zendesk – Integração com service hooks

O Service Hooks é um recurso interessante do Azure DevOps para habilitar ações, baseadas em eventos que acontecem nos projetos do Azure DevOps. Por exemplo, criar uma notificação no Slack (em algum grupo específico) sobre um deploy bem sucedido. Ele funciona da seguinte maneira:

  • Publisher: define um conjunto de eventos.
  • Subscriptions: recebe os eventos e define as ações (Actions) a serem tomadas. Os consumidores (Consumer) são serviços externos que podem executar suas próprias ações, ao ocorrer algum evento.

service-hooks

Há vários serviços disponíveis no Marketplace que permitem a integração com o Azure DevOps Services. Veja a relação dos principais abaixo:

services-azure-devops

Neste post, vamos abordar a integração do Azure DevOps com o Zendesk.

1. Criando os conectores

O primeiro passo é instalar o IntegrateCloud Connector for VSTS no Zendesk. Vá no Marketplace e execute a instalação.

instalacao-integrate-cloud-azure

Você irá precisar de um Token (do lado do Zendesk) para permitir a integração com o Azure DevOps. Acesse no Zendesk a [Engrenagem de Admin] > Canais > API e ative o acesso por token, conforme imagem abaixo. Salve este token.

API-zendesk

Feito isso, acesse o Azure DevOps e configure o Service Hook do Zendesk para permitir a manipulação dos work items externamente. Para isso, acesse Project Settings > Service Hooks e adicione um novo Serviço do Zendesk.

  • A tela seguinte solicita Area Path e Work Item Type desejado.
  • Na última tela, insira a conta, usuário e token gerado no Zendesk.

new-service-hooks

Também adicione um token do lado Azure DevOps para prover a autorização da configuração do Service Hook, feito acima. Acesse “Personal access tokens” e insira um nome para ele. Salve este token também.

token-service-hooks

2. Integração de work items

Na sequência, crie um novo ticket (ou acesse algum já criado) no Zendesk e configure a área de Aplicativos (lado direito da tela). Insira a URL da conta do Azure DevOps e o Token que acabamos de gerar no passo anterior.

ticket-zendesk

Feita a autenticação, a tela abaixo (do IntegrateCloud Connector for VSTS) irá aparecer. Preencha o Projeto (Area Path) e a  Sprint (Iteration) que deseja publicar esse work item. Salve a modificação.

integratecloud-connector-vsts

Veja que o ticket criado no Zendesk agora foi criado como work item (pode ser do tipo task / bug / epic / feature / user story) no Azure DevOps. Pronto! A integração entre os dois está funcionando.

board-azure-devops

Lembrando que o Service Hooks é um recurso para para habilitar ações, baseadas em eventos e que pode ser utilizado na integração com diversos sistemas (conforme mostrado no início do artigo). Aqui fizemos uma demonstração com o Zendesk.

NoOps é aplicável a sua organização?

Em 2011, a Forrester já publicava um artigo sobre NoOps e como a automação de algumas operações – build, deploy, testes, etc. levaria mudanças as equipes de infra, reduzindo a necessidade de interação com outras equipes e até mesmo da redução de recursos, substituídos por estes processos automatizados.

Claro que, após todos estes anos, e com os resultados obtidos pela disseminação do DevOps (foco na colaboração entre os times e automação) nas organizações, vimos que não é simples e tampouco mágica manter uma área de operações “rodando” em automático. E por isso, hoje o drive está muito relacionado ao trabalho eficiente, melhorando os resultados obtidos pela automação e forma de atuação no trabalho.

Agora em 2019, talvez o conceito de que DevOps possui foco em colaboração e NoOps em automação esteja mudando, pois é mesmo possível automatizar todas as tarefas de infraestrutura? E nas práticas DevOps já não existe forte colaboração entre os times mesmo com automação de inúmeros processos?

Aplicabilidade

Neste novo patamar atingido por serviços Cloud, os recursos podem ser abstraídos da infraestrutura subjacente, e as atividades de provisionamento e implantação de infraestrutura agora são gerenciadas por meio de serviços de infraestrutura e plataforma sob demanda.

O NoOps segue então como tendência ao ambiente que seja automatizado e abstraído da infraestrutura, podendo ser gerenciado por equipes menores e eficientes. Torna-se impossível viabilizar operações em grande escala com execução manual de atividades. A Deloitte Insights traz análises de adoção nas organizações.

É então mais recomendável a ambientes de TI homogêneo com pouca diversidade no nível da infraestrutura. O stack diversificado de tecnologia (aplicações e infraestrutura) e o comum histórico das mudanças no nível de infraestrutura (dinâmicas e distribuídas) tornam muito mais complexa a adoção NoOps nestes ambientes.

DevOps e NoOps

DevOps (by Microsoft) “É a união de pessoas, processos e produtos para permitir a entrega contínua de valor aos nossos usuários finais. A contração de “Dev” e “Ops” refere-se à substituição do Desenvolvimento e Operações em silos para criar equipes multidisciplinares que agora trabalham em conjunto com práticas e ferramentas compartilhadas e eficientes. As práticas essenciais do DevOps incluem planejamento ágil, integração contínua, entrega contínua e monitoramento de aplicativos”.

NoOps significa nenhuma operação. O foco é automatizar todas as tarefas de manutenção associadas ao desenvolvimento e à execução de uma solução. Isso não é uma missão simples, mas possível, considerando que os provedores de serviços terceiros podem executar tarefas de implantação, gerenciamento e manutenção, tal como o EKS da Amazon. E assim, não há necessidade de alta interação entre os times para tornar possível a conclusão do trabalho.

Os provedores de nuvem continuam subindo o stack, assumindo muitas tarefas de administração de sistemas, tais como aplicação de patches, backup e gerenciamento de banco de dados, entre outras. 

Fonte: Appdynamics 

Traditional Ops e NoOps

As operações de TI não desaparecem apenas com a adoção de plataformas em cloud  pública. Entre algumas evoluções na gestão operacional:

  • Automação: na maior parte das tarefas operacionais, sendo norma e não mais exceção.
  • Proativo: o uso de informações preditivas orientadas por IA para monitorar e otimizar serviços de TI, para que as equipes de Ops possam se concentrar em iniciativas voltadas para o cliente.

traditional-ops-noops
Fonte: https://blog.opsramp.com/devops-noops

Na prática

Além das considerações de aplicabilidade (citadas anteriormente) em relação a manutenção e ambientes legados, outro ponto de atenção é a absorção de novas atividades aos desenvolvedores. Além do interesse em administrar suas próprias soluções, vale verificar o processo para não gerar gargalos.

Como NoOps é habilitado por tecnologia, existem algumas opções PaaS como Heroku e serviços cloud na AWS e Azure. Serverless computing e replicable infrastructure são também boas soluções para resolver a parte da infraestrutura e as ferramentas tradicionais de implantação.

DevOps, Ikigai, Gamificação e F4P – despertando o propósito no CI/CD

O acordo do time é essencial para alavancar as entregas contínuas orientadas a valor. Como orquestrar então “processos – pessoas – ferramentas” neste contexto? Utilizando conceitos do Ikigai, Gamificação e Fit For Purpose (F4P), este trabalho demonstra como equilibrar o compromisso das entregas com o que gostamos de fazer. Também compartilha os resultados obtidos com a transformação cultural, envolvendo as boas práticas de desenvolvimento, o comprometimento com CI/CD e a gestão ágil.

Link de acesso do material: Agile Trends 2019 – Leonardo Matsumota.

  • Ikigai: contextualização da filosofia e correlação entre o ser humano e seu trabalho, em busca do propósito entre paixão, missão, profissão e vocação.
  • F4P: utilização do F4P Card (adaptado), Fitness Box Score e Matriz (aderência x identidade) para identificar a satisfação dos colaboradores com a empresa.
  • Hard Skill Canvas: traz alinhamento, transparência e melhoria contínua ao time, conhecendo as competências técnicas que o time precisa para os produtos da organização.
  • Engajando CI/CD: senso de pertencimento, cadência e gestão.
  • Gamificação: ampliando as boas práticas com senso de colaboração e conhecimento.
  • Formato de trabalho: Squads, OKRs e camadas de engajamento.

 

Digital Engagement- Sistema de registro e engajamento

Continuando a abordagem do Bi-modal Gartner, outro conceito importante e mencionado no livro The DevOps Handbook é o Sistema de registro e engajamento. Entre os quatro fluxos de valor estão:

  • Serviço virgem: uma nova iniciativa de software.
  • Serviço abandonado: produtos que já atendem a clientes e estão no mercado há anos.
  • Sistema de registro: centralizados para gerenciar uma única fonte de dados na organização. Contém todo o suporte para a entrega de valor ao cliente . Inclui o gerenciamento dos dados, transações, segurança e privacidade.
  • Sistema de engajamento: interage diretamente com o cliente. Incentivam a interação dos clientes e usuários com a organização por meio de apps, portais colaborativos, etc.

E assim, segundo o conceito de TI Bimodal de Gartner (prática de administrar dois estilos de trabalho separados, mas coerentes: um focado na previsibilidade, o outro na exploração), classifica o sistema de registro e engajamento na seguinte tabela:

Sistema Tipo Bimodal Ritmo de mudanças
Registro Modo 1: fazer direito com foco em estabilidade e confiabilidade Mais lento e costumar ter requisitos normativos e conformidade
Engajamento
Modo 2: fazer rápido com foco em flexibilidade e inovação Mais rápido e permite experimentos em ambientes incertos

Enquanto no sistema de registro, a vantagem é lidar com tarefas burocráticas e demoradas, como conformidade, segurança e privacidade (por exemplo utilizando a telemetria e automação para gerar as evidências), por outro lado, o sistema de engajamento demonstrará a confiabilidade da inovação em ciclos de entregas rápidos, por exemplo, novas funcionalidades que melhoraram a conversão de clientes em 40% no e-commerce da empresa.

Samoore contextualiza que o engajamento digital certamente inicia com os sistemas de engajamento (as tecnologias que permitem aos usuários interagir com a organização), conectando aos sistemas de registro que mantêm os dados sobre a pessoa e sua história com a organização. Os sistemas de insight por fim executam as análises para apoiar essa individualização e tornar a interação relevante.

DevOps – Pipeline de implantação, CI (Continuous Integration) e CD (Continuous Delivery)

Em geral, o processo organizacional para lançamento de um produto (ou nova funcionalidade) no mercado segue as seguintes etapas:

  1. Visão do produto: definição das funcionalidades do produto
  2. Time de Dev: realiza o desenvolvimento de forma iterativa e incremental; uma nova versão a cada iteração
  3. Área de operação: implementa e mantém os ambientes estáveis
  4. Monitoramento e retorno: geração do valor e uso pelo cliente

O Fluxo de valor, desde a concepção do produto até a geração de valor, analisa o caminho completo de criação de valor e compreende o valor exato adicionado em cada parte. Em métodos ágeis, não há prescrição dos aspectos da entrega, e por isso, a última milha é regida por boas práticas para cobrir todo o processo da implantação.

O feedback vai guiando a estratégia da empresa, eliminando barreiras entre os departamentos e permitindo a colaboração entre as pessoas para gerar valor ao cliente.

pipeline-implantacao

Um pipeline de implantação é uma manifestação automatizada do seu processo para levar o software do controle de versão para as mãos de seus usuários. Todo o processo – do conceito ao dinheiro – pode ser modelado como um mapa de fluxo de valor. Envolve os processos de

  • Integração Contínua
  • Entrega Contínua
  • Implantação Contínua

CI-CD

Criando um pipeline de implementação (imagem abaixo no Azure DevOps):

  1. Modelar o fluxo de valor, criando um esqueleto do processo
  2. Automatizar os processos de compilação e testes
  3. Automatizar os processos de implantação
  4. Implantar a estratégia de entrega de versão

pipeline-implantacao-azure-devops.png

  • Envolver qualidade e segurança da informação desde o início
  • Estratégia de testes, considerando teste unitário, integração, segurança, TDD/BDD/ATDD, infraestrutura e performance
  • Telemetria eficiente na coleta e monitoramento das informações

CI (Continuous Integration)

São práticas que encorajam os desenvolvedores a integrar o seu trabalho continuamente – um novo código fonte (branch ou trunk) ao principal (main). Permite ajustes frequentes nos códigos, entregas rápidas e com menos bug. Há três coisas que você precisa estar ciente antes de CI:

  1. Controle de versão
  2. Build automatizado
  3. Acordo do time

Alguns pré-requisitos da CI:

  • Check in frequente
  • Suíte de testes abrangente
  • Manter o processo de Build e Teste curto
  • Gerenciando seu workspace de desenvolvimento

CI é uma prática, não uma ferramenta, e por isso, depende da disciplina para torna-la efetiva. Algumas práticas recomendadas para as equipes:

  • Builds devem passar no coffee test (menos de 5 minutos)
  • Não fazer check in de build com falha
  • Sempre execute todos os testes de confirmação antes do commit
  • Não vá embora com um build quebrado
  • Esteja sempre preparado para reverter a revisão anterior
  • Defina um time box antes de reverter (por exemplo: 10 minutos se não obtiver a solução, reverter a revisão anterior)
  • Test-Driven Development

Jez Humble: “The goal of continuous integration is that software is in a working state all the time”.

Continuous Delivery

É uma extensão do CI para garantir que novas modificações estejam disponíveis para serem implementadas no ambiente de produção.  Os testes e o processo de liberação são automatizados e contribuem com o controle de qualidade para prover feedbacks rápidos aos desenvolvedores.

O deploy para produção não é automático, porém pode ser realizado a qualquer momento, dependendo do aceite da alteração (com o clique de um botão).

Boas práticas:

  • Build somente uma vez o artefato (rebuild – passará novamente por todos os ambientes; quebrará sua auditoria)
  • Artefatos devem ser imutáveis (armazenados com restrição de permissão). Manter os acessos de deployers somente onde deve ter acesso
  • Duas boas razões para ser imutáveis: a) cria confiança entre o time b) ser rastreável (poder verificar versões específicas, etc.)
  • Deployment deve ir para uma cópia de produção; pare o deploy se uma etapa anterior falhar
  • Deployments devem ser idempotente

Métricas do seu pipeline:

  • Você é capaz de auditar uma simples mudança?
  • Quão rápido você pode mover uma mudança para produção?
    (overall cycle time)
  • Cycle time = do check-in até produção

Continuous Deployment

Processo sem intervenção humana, realizando todas as validações anteriores para disponibilizar a nova modificação em produção automaticamente. Somente uma falha encontrada nos testes impede a implementação em produção.

Neste processo é muito importante validar com a área de segurança da informação e compliance da sua empresa a aplicabilidade deste processo. Em operações críticas que trabalham com deploys contínuos (dezenas, centenas ou milhares por dia), torna-se inviável gerenciar este processo sem ter a implantação do Continuous Deployment.

Gestão de backlog – Epic Roadmap, WI relationships e personas no Azure DevOps

Já discutimos sobre o uso do Azure DevOps como plataforma de ciclo de vida do desenvolvimento e a estruturação do backlog na ferramenta (Epic – Feature – User Story – Tasks) de acordo com o seu process template.

Na área de Boards do Azure DevOps, temos alguns novos recursos no Marketplace para apoiar a visualização e gestão das atividades dos times. Selecionei três deles que são bem interessantes:

Crie então a estrutura do seu Time de Projeto no Azure DevOps (Boards > Backlogs). Veja na imagem abaixo que a relação entre Epic – Feature (Requirement) – User Story é de Parent. 

azure-devops-backlog

Feature timeline and Epic Roadmap

Após a estruturação do backlog, ainda em Boards > Backlogs, veja que as guias de “Feature Timeline” e “Epic Roadmap” foram criadas (após a instalação da extensão do Marketplace). A visão é das User Stories em relação a Sprints que serão desenvolvidas. Este roadmap ajuda o time a visualizar a entrega das funcionalidades do projeto.

epic-roadmap

Visualize work item relationships

Após a instalação da extensão no Marketpace, acesse as opções do Work Item (conforme imagem abaixo) e utilize Visualize. Em seguida, veja que será exibido a estruturação do seu backlog, bem semelhante ao FBS (Feature Breakdown Structure), muito utilizado para ajudar o time a melhorar a compreensão do produto e requisitos.

wi-visualization

work-item-visualization

Personas

Por fim, a criação de Personas ajuda a representar o usuário no sistema, descrevendo seu papel e necessidades. Instale a extensão do Marketplace (conforme link no início do artigo) e acesse o novo recurso “Personas” que será exibido, conforme abaixo.

Clique em + Add para adicionar uma nova Persona. Preencha o Nome, Tag, Descrição e Foto conforme necessidade do projeto.

create-persona-azure-devops

Após ter criado a Persona, você consegue utilizar e vincular em qualquer Work Item. No exemplo abaixo, estamos associando quais Personas são afetadas pela aquela atividade.

wi-personas