Mandatos

Um mandato é uma declaração permanente sobre em que o Coroid deve trabalhar quando ninguém está presente para solicitar: um objetivo, os projetos que abrange, um orçamento por semana ou mês e até quando deve parar. As solicitações provenientes de seus sistemas — o canal de entrada de trabalho API, automações, integrações e monitoramento — são aceitas com base nos mandatos ativos. Solicitações feitas por pessoas não são; veja Quais solicitações um mandato governa.

Um mandato determina quais trabalhos podem começar. Ele não permite que o Coroid faça merge ou implante nada. Veja O que o Coroid decide e o que fica sob sua responsabilidade.

Quando um mandato faz sentido#

Escreva um mandato quando o trabalho chegar ao Coroid sem que alguém solicite cada parte separadamente e você quiser decidir antecipadamente quanto dele pode ser executado:

• um rastreador de erros ou ferramenta de monitoramento que relata incidentes pelo canal de entrada de trabalho API;
• notificações do GitHub, ou mensagens do Slack, Telegram e Jira, que um Qualificar o trabalho automação transforma em solicitações;
• uma ferramenta de suporte ou feedback que repassa o que os clientes relatam;
• um scanner ou tarefa de CI que registra descobertas uma por uma.

Sem um mandato, essas solicitações são tratadas como qualquer outra: assim que se qualificam, entram na fila para ocupar os mesmos slots de agente que o trabalho solicitado por pessoas, sem orçamento próprio. Uma semana movimentada de alertas pode então encher sua fila. Um mandato as delimita: quais projetos podem afetar, quanto podem custar por semana ou mês e quantos slots de agente podem ocupar simultaneamente.

Como uma solicitação segue seu caminho#

Considere o mandato da figura, criado para um projeto chamado Faturamento API. Seu rastreador de erros gera um alerta para uma nova exceção na exportação de faturas. O webhook da regra de alerta, por meio de um pequeno relay próprio, o registra no canal de entrada de trabalho API, usando o ID do problema do rastreador como impressão digital do sinal, a rota afetada e 500 solicitações como a exposição que deve ser superada antes que a correção seja considerada válida.

1. Qualificação funciona como para qualquer solicitação: remove segredos e dados pessoais, verifica a versão atual, procura por duplicatas, valida o relatório e avalia-o.
2. Admissão localiza o mandato que abrange o Faturamento API e verifica, nesta ordem: se o mesmo problema já está sendo tratado, aqui ou em outro projeto; se a avaliação confirmou que o comportamento era esperado; se um dos dois slots do mandato está livre; se há espaço no orçamento desta semana; e se o resultado pode ser medido.
3. Admitida, a solicitação se torna uma tarefa com um slot reservado e parte do orçamento da semana. Ela segue o caminho normal — especificação, código, testes, portas de qualidade, QA e Revisão — e termina como um pull request.
4. Uma pessoa faz o merge dela. A contrato de resultado registra o que esse merge deve alcançar: nenhum novo evento relacionado a esse problema nas próximas 24 horas após 500 solicitações na rota.

Se o mesmo alerta disparar novamente, a segunda solicitação é já resolvido e vinculado ao primeiro. Se uma implantação defeituosa gerar seis novos problemas de uma só vez, no máximo dois serão executados sob o mandato por vez; os demais são adiados, então admitidos um por um à medida que as vagas do mandato se liberarem. As outras duas vagas de agente permanecem livres para o que sua equipe solicitar em Novo trabalho.

Exemplos de mandatos#

Evitar o acúmulo de erros de produção#

Seus serviços API relatam erros a um rastreador de erros, e a correção deles ocorre quando alguém tem tempo.

As solicitações chegam do rastreador de erros através do API de entrada de trabalho, cada uma com um signal nomeando o ID do problema do rastreador, as rotas e uma contagem de solicitações. Cada problema se torna no máximo uma tarefa de trabalho, independentemente de quantas vezes seja disparado. Uma semana problemática custa no máximo 100 USD. Um alerta enviado sem rotas aguarda em vez de começar, pois nada indicaria se sua correção funcionou; envie as rotas ou ative Admitir trabalho cujo resultado não pode ser medido.

Trabalhar nos bugs relatados no GitHub#

Os usuários abrem problemas no repositório do seu aplicativo web mais rápido do que qualquer pessoa consegue triá-los.

Um Qualificar tarefa A automação em novos problemas do GitHub cria um arquivo para cada um. A qualificação evita duplicatas, identifica problemas já corrigidos na versão atual e informa que não é possível reproduzi-los. O interruptor de mensurabilidade está ativado porque o problema não especifica rotas ou tráfego, portanto seu contrato de resultado não pode ser medido; com o interruptor desativado, todas as tarefas ficariam em espera. As tarefas abertas por pessoas com acesso de escrita são iniciadas automaticamente; as demais aguardam que alguém as inicie, conforme descrito em Quando o trabalho começa.

Agir com base no que os clientes relatam#

Sua ferramenta de suporte coleta relatórios dos clientes, e os casos urgentes chegam ao time de engenharia com atraso.

A ferramenta de suporte registra cada relatório por meio do sistema de entrada de tarefas API com uma conta de serviço. A qualificação rejeita o que não pode ser reproduzido, e o mandato impede que uma semana movimentada de relatórios consuma mais da metade das vagas de agente ou exceda o orçamento estabelecido.

Finalizar uma limpeza antes do prazo#

O SDK de pagamentos que você utiliza atingirá o fim de sua vida útil no próximo trimestre, e suas chamadas obsoletas estão distribuídas em dois serviços.

Um job de CI gera uma solicitação por cada ponto de chamada, usando o arquivo e a linha como impressão digital de sinal, para que um ponto de chamada identificado novamente na próxima execução seja vinculado ao trabalho já em andamento. O Coroid ainda não lê o destino: quando a última chamada desaparecer, escolha Concluir você mesmo.

Quando você não precisa de um mandato#

• Trabalho solicitado pelas pessoas. As solicitações feitas em Novo trabalho ou importadas são aceitas quando se qualificam, nunca adiadas e nunca consomem o orçamento de um mandato.
• Agendas e acompanhamentos via hook. Eles criam tarefas diretamente, sem Qualificação, portanto nenhum mandato os limita. Dê a eles uma prioridade menor em vez disso; veja Agendas.
• Uma iniciativa pontual. Trabalho com formato conhecido e fim definido é um plano, não um mandato.
• Mandatos sobrepostos. Quando vários mandatos ativos cobrem o mesmo Projeto, o mais antigo rege suas solicitações. Atribua cada Projeto a um único mandato.

Onde os mandatos existem#

Abrir Controle de Qualidade → Mandatos. Cada escopo no Controle de Qualidade — o padrão da organização e cada Projeto — está vinculado à mesma lista, pois um mandato pertence à organização e nomeia seus próprios Projetos. Abrir o escopo de um Projeto não filtra a lista.

Proprietários e administradores criam e alteram mandatos. Membros podem lê-los. Agentes e contas de serviço não podem alterar um mandato de forma alguma.

O que um mandato contém#

Tipo. Finitos mandatos têm um alvo e terminam quando ele é alcançado, por exemplo "reduzir para zero as falhas de segurança pendentes". Contínuos mandatos são de manutenção, como por exemplo "manter as rotas de produção livres de exceções não tratadas"; eles têm uma data de revisão em vez de um alvo.

Objetivo. Uma frase que descreve o que deve ser verdadeiro. É assim que as pessoas leem o mandato; a admissão em si segue o escopo, orçamento e status.

Linha de base. A métrica pela qual o mandato é medido e sua origem. Você nomeia a métrica, e as leituras são coletadas pelo Coroid, nunca digitadas manualmente. Elas nunca fazem parte de uma exportação de configurações. Um novo mandato exibe Nenhuma leitura ainda.

Alvo. Para um mandato finito: a métrica e o valor que indicam conclusão.

Prioridades. Uma por linha. Quando o trabalho compete por capacidade, a primeira prioridade prevalece.

Escopo.

• Projetos. Os projetos abrangidos pelo mandato. Se nenhum estiver marcado, ele abrange todos os projetos da organização, incluindo os criados posteriormente. Marque os projetos desejados; um mandato definido para um repositório específico deve nomear esse projeto.
• Áreas. Padrões de caminho dentro desses projetos, um por linha, por exemplo apps/api-*/src/**. O valor vazio significa qualquer local.
• Classes de alteração. Os tipos de alteração aos quais o mandato se aplica, por exemplo exception_fix.
• Aceita trabalhos cujo resultado não pode ser medido. Desativado por padrão. Quando está desativado, uma solicitação cuja contrato de resultado não puder ser medida aguarda em vez de começar.

Orçamento. O quanto o Coroid pode gastar no mandato em cada período, em dólares americanos e horas de agente, por semana ou por mês. Uma semana começa na segunda-feira às 00 UTC; um mês começa no primeiro dia. O orçamento se abre automaticamente novamente.:00 UTC; um mês começa no seu primeiro dia. O orçamento se abre novamente sozinho.

Condições de parada. Pare quando o orçamento for esgotado, quando a meta for alcançada, após um número determinado de resultados inconclusivos seguidos ou em uma data específica.

Data de revisão. Para um mandato em andamento: a data em que uma pessoa o renova ou encerra.

Regra de desvio. Para um mandato em andamento: um limite para a métrica de referência. Ultrapassá-lo em um período deve gerar uma escalação para o responsável.

Status e versões#

Um mandato começa como um rascunho. Publicar o torna ativo, e somente mandatos ativos aceitam trabalhos.

Alterar um mandato publicado gera uma nova versão. As versões anteriores são mantidas com quem as publicou e quando.

Cada publicação e cada alteração de Status representam uma decisão no âmbito do mandato. Procedência, indicando a pessoa que o criou e um evento no fluxo de auditoria da sua organização (mandate.created, mandate.published, mandate.paused e assim por diante).

Quais solicitações um mandato regula#

Um mandato regula solicitações que chegam sem uma pessoa em Coroid: desde a entrada de trabalho em API, desde automações e integrações como GitHub ou issues do Jira, e desde monitoramento.

Uma solicitação feita por uma pessoa em Novo trabalho, ou importações, não está sujeita a um mandato. Ela é sempre admitida quando qualificada, nunca é adiada e não consome o orçamento do mandato. Uma pessoa a solicitou; as vagas dos agentes simplesmente a enfileiram.

Uma solicitação não atendida é vinculada ao mandato ativo mais antigo cujos projetos incluem o projeto da solicitação, ou àquele que abrange todos os projetos. Uma solicitação que não se enquadra em nenhum mandato é admitida como uma solicitação comum.

O que a admissão decide#

A admissão é a última etapa de Qualificação. Ela não faz nenhuma chamada a modelos. Para cada solicitação, decide uma das seguintes opções:

• Admitida. O trabalho é criado, com reserva de uma vaga para o agente e, sob um mandato, parte do orçamento do mandato. Se ele começará por conta própria depende da origem, conforme descrito em Quando o trabalho começa.
• Já resolvido. O mesmo sinal — o mesmo problema no seu rastreador ou monitoramento, ou a mesma falha — já está sendo tratado em outra solicitação em qualquer projeto da organização. A solicitação é vinculada a esse trabalho, e nada novo é criado.
• Nenhuma alteração necessária. A avaliação da Qualificação constatou que o comportamento relatado é intencional. Nada é criado.
• Adiada. A solicitação é admissível, mas não deve começar agora: a cota de vagas de agentes do mandato está em uso, seu orçamento para o período foi consumido, ou seu resultado não pode ser medido e o mandato não admite isso.

Cada decisão e seu motivo são registrados junto à solicitação.

Solicitações adiadas#

Coroid verifica novamente as solicitações adiadas a cada minuto e as admite assim que houver um espaço ou orçamento disponível, de acordo com a versão atual do mandato. Aumentar o orçamento do mandato ou pausar outro mandato que esteja ocupando espaços libera um adiamento na próxima verificação. Não existe nenhuma forma de iniciar uma solicitação diretamente de maneira excepcional.

Uma solicitação que aguardou mais tempo do que o período definido pelo seu mandato — uma semana ou um mês — ou cujo mandato já não está ativo, será encerrada sem que o trabalho seja executado.

Como o trabalho dos mandatos compartilha capacidade?#

O trabalho dos mandatos pode ocupar no máximo metade da capacidade total da sua organização. espaços de agente ao mesmo tempo, contando o trabalho em execução e o trabalho admitido mas ainda não iniciado. O restante permanece livre para atender às demandas das pessoas. Se o seu plano possuir espaços ilimitados, a mesma proporção se aplica ao seu orçamento mensal de gastos.

Uma solicitação admitida mantém sua reserva por 30 minutos enquanto sua tarefa é iniciada. Depois disso, a reserva expira: uma solicitação cujo trabalho ainda não foi criado volta para a lista de adiados, e uma tarefa já existente aguarda por um espaço como qualquer outra.

Em uma exportação de configurações#

Os mandatos são incluídos em uma exportação de configurações: tipo, objetivo, alvo, prioridades, escopo, orçamento, condições de interrupção, data de revisão e regra de desvio. Os Projetos são identificados pelo seu código estável, e o proprietário é definido por função. As linhas de base nunca são incluídas; elas representam medições da organização de onde vieram. Um mandato com um novo objetivo chega como rascunho para ser publicado por uma pessoa. Aquele cujo objetivo corresponde a um mandato existente o atualiza: o rascunho, se ainda for um rascunho; caso contrário, como uma nova versão publicada.

Relacionado#

• Contratos de resultado
• O que Coroid decide e o que permanece sob seu controle
• Capacidade e espaços de agente
• Novo trabalho e qualificação
• Procedência