Feedback

Feedback

1. Objetivo do feedback

   • Obter visão clara do fluxo de valor em todos os estágios do ciclo de vida do serviço, produto, desenvolvimento e implementação, entrada em operação e retirada.
     • - Todas as equipes que participam do fluxo de valor devem ter feedback rápido. - Dessa forma, todos os participantes do fluxo de valor tem a oportunidade de aprender desde os primeiros estágios do projeto.
     • - Recebendo um feedback rápido sobre o processo ou produto sendo desenvolvido, desvios quanto ao processo ou produto podem ser rapidamente consertados.

2. Opções para resolução de problemas

   • Correção - Fix Forward
     • - É uma mudança no código e deve ser executada em ambientes com grande maturidade: Teste automatizado, implantação rápida, telemetria. - Significa resolver erro em produção para que continue a funcionar normalmente o que acabou de implantar.
   • Reversão - rollback ou fallback
     • - Usuário deixa de receber a implantação e há duas formas: 1) Implantar a versão anterior ( Ex: Canário ). 2) Alternância de recursos: mais fácil de reverter e menos arriscada. - Usualmente o rollback é mais rápido que o Fix Forward.

3. Suporte Compartilhado

   • A implantação de um Pipeline com testes automatizados não garante erro zero em função da complexidade dos sistemas
   • Priorizar solução de erros de software
     • - A equipe de Dev deve priorizar essa solução para não impactar a operação por muito tempo. - Equipe de infraestrutura dá feedback a equipe de desenvolvimento sobre erros que não consegue resolver sem correção e nova implantação de código.
   • Priorizar resolução de incidentes em produção
     • - Todos os participantes do fluxo de valor devem compartilhar as responsabilidades na resolução de incidentes em produção.

4. Guia de Lançamento - Launch Guidance

   • - Ao lançar um produto novo há uma série de requisitos a considerar para saber se o lançamento foi ou não bem sucedido.
   • - São itens que devem ser observador com cuidado antes de fazer um lançamento em produção.
   • Número de Defeitos e Severidade
     • - Funciona conforme o planejado?
   • Tipo e frequência dos alertas
     • - Gera eventos adequados em produção.  - O que será lançado lança alertas adequados segundo o que foi requisitado?
   • A arquitetura da aplicação é fracamente acoplada?
   • Cobertura de monitoramento
     • - Permite restaurar o serviço rapidamente quando ocorrer um erro?
   • Requisitos de Implantação
     • - A implantação é um processo previsível e automatizado para produção?
   • Higiene da Produção
     • Outra pessoa consegue dar suporte à produção?

5. Google SRE

   • -Significa Site Reliability Engineering - Basicamente é um cargo criado pelo Google - Engenheiro de Confiabilidade do Site. Um indivíduo que trabalha com infraestrutura mas que conhece muito de engenharia de software. - O SRE deve conhecer codificação para automatizar processos e minimamente entender de desenvolvimento de sistemas.
   • Dev representa a equipe do produto
     • - O Dev representa a equipe do produto e gerencia o serviço em produção até que esteja saudável e faça a transição para OPS ( SRE )
   • SRE representa a equipe de operação
     • - SRE representa OPS e sustenta os serviços sob sua responsabilidade. Faz o papel de consultor durante o tempo em que o time DEV é responsável pela gestão do serviço em produção.

6. Lista de revisão de segurança para colocar código em produção

   • - Essas Listas já contam com suporte para o usuário. Sendo fornecido ou pela equipe de dev - LRR ou pela equipe de operações - HRR
   • Lista de Revisão de Prontidão de Lançamento
     • - LRR: Launch Readiness Review. - Suporte completo fica com a equipe de Dev até que o serviço esteja maduro e preparado para transição ( HRR )
     • Antes de lançar, a aplicação ficará em torno de 6 meses sendo suportada pela equipe DEV.
   • Lista de Revisão de Prontidão sem intervenção
     • - HRR: Handoff Readiness Review. - Suporte completo é transferido para Ops. - As listas são parecidas mas a HRR é mais rigorosa e tem maior padrão de aceitação.

7. Suporte de aplicação frágil em produção

   • - São aplicações passadas para a equipe de operação mas com indicativo de erros em desenvolvimento. Podem ser repassadas para a equipe de desenvolvimento fornecer suporte.
   • Handback
     • - Conceito utilizado pelo Google para evitar que uma aplicação muito frágil em produção impacte o trabalho da equipe de operações. A aplicação frágil pode ser devolvida para que a equipe de desenvolvimento forneça o suporte completo.
     • - Com o Handback, a equipe de operação devolve a responsabilidade de suporte em produção da aplicação frágil para a equipe de Dev.

8. Experiência do Usuário ( UX ) como feedback

   • - Colocar a experiência do Usuário no Suporte.
   • Pesquisa Contextual
     • - A Pesquisa Contextual ocorre quando a equipe do Produto observa um cliente usar a aplicação em seu ambiente natural.
     • - Objetiva mostrar todas as dificuldades na prática: cliques numerosos, lentidão, transição de várias telas, migração de dados para outros sistemas, etc.
   • Gerar empatia e incentivar a colaboração
     • - Essa Simples ação gera maior empatia e incentiva as equipes a melhorar a qualidade na origem.

Bilder und Dateien der Mindmap