Mandatos

Un mandato es una declaración permanente sobre en qué debe trabajar Coroid cuando nadie lo solicita: un objetivo, los proyectos que abarca, un presupuesto semanal o mensual y cuándo detenerse. Las solicitudes que provienen de sus sistemas — la entrada de trabajo API, automatizaciones, integraciones, monitoreo — se admiten conforme a sus mandatos activos. Las solicitudes hechas por personas no; consulte ¿Qué solicitudes regula un mandato?.

Un mandato determina qué trabajo puede comenzar. No permite que Coroid fusione ni despliegue nada. Consulte Qué decide Coroid y qué queda bajo su control.

Cuándo tiene sentido un mandato#

Escriba un mandato cuando el trabajo llegue a Coroid sin que nadie solicite cada parte y desee decidir de antemano cuánto puede realizarse:

• un sistema de seguimiento de errores o herramienta de monitoreo que informe incidentes a través de la entrada de trabajo API;
• incidencias de GitHub, o mensajes de Slack, Telegram y Jira, que un Calificar el trabajo una automatización convierte en solicitudes;
• una herramienta de soporte o retroalimentación que transmita lo que reportan los clientes;
• un escáner o tarea de CI que registre hallazgos uno por uno.

Sin un mandato, estas solicitudes se tratan como cualquier otra: una vez que califican, pasan a la cola para ocupar los mismos espacios de agente que el trabajo solicitado por personas, sin presupuesto propio. Una semana con muchas alertas puede entonces saturar su cola. Un mandato las delimita: qué proyectos pueden afectar, cuánto pueden costar por semana o mes y cuántos espacios de agente pueden ocupar simultáneamente.

Cómo viaja una solicitud#

Tome el mandato de la figura, redactado para un proyecto llamado Facturación API. Su sistema de seguimiento de errores genera una alerta por una nueva excepción en la exportación de facturas. El webhook de la regla de alerta, a través de un pequeño relé propio, la registra en la entrada de trabajo API, con el ID del incidencia del sistema de seguimiento como huella digital de la señal, la ruta afectada y 500 solicitudes como la exposición que debe superarse antes de considerar corregido el problema.

1. Calificación opera como para cualquier solicitud: elimina secretos y datos personales, verifica la versión actual, busca duplicados, valida el informe y lo evalúa.
2. Admisión busca el mandato que cubre Facturación API y verifica, en orden: si el mismo problema ya se está tratando, aquí o en otro proyecto; si la evaluación determinó que el comportamiento es el esperado; si uno de los dos espacios del mandato está libre; si hay margen en el presupuesto de esta semana; y si el resultado puede medirse.
3. Admitida, la solicitud se convierte en una tarea con un espacio reservado y parte del presupuesto semanal. Sigue el proceso habitual: especificación, código, pruebas, controles de calidad, QA y revisión, y termina como un pull request.
4. Una persona fusiona dicha tarea. El contrato de resultado registra lo que esa fusión debe lograr: que no haya nuevos eventos relacionados con ese problema durante 24 horas después de 500 solicitudes en la ruta.

Si la misma alerta se activa de nuevo, la segunda solicitud se Ya resuelto y vinculado al primero. Si un despliegue incorrecto genera seis incidencias nuevas a la vez, como máximo dos se ejecutarán bajo el mandato a la vez; el resto se posponen, luego se admiten una por una a medida que se liberan las plazas del mandato. Las otras dos plazas de agente permanecen libres para lo que tu equipo solicite en Nuevo trabajo.

Ejemplos de mandatos#

Evitar que los errores de producción se acumulen#

Los servicios de API informan de errores a un sistema de seguimiento de errores, y su corrección se realiza cuando alguien tiene tiempo.

Las solicitudes llegan desde el sistema de seguimiento de errores a través del trabajo de entrada API, cada una con un signal que indica el ID de la incidencia del sistema de seguimiento, las rutas y un recuento de solicitudes. Cada incidencia se convierte como máximo en una tarea, sin importar cuántas veces se active. Una semana problemática costará como máximo 100 USD. Una alerta enviada sin rutas esperará en lugar de iniciarse, ya que no hay forma de saber si su corrección funcionó; envía las rutas o activa Admitir Trabajos cuyo resultado no se pueda medir.

Trabajar en los errores reportados en GitHub#

Los usuarios abren incidencias en el repositorio de tu aplicación web más rápido de lo que cualquiera puede clasificarlas.

Un Calificar el trabajo La automatización en los nuevos problemas de GitHub crea uno por cada caso. La calificación evita duplicados, identifica errores ya corregidos en la versión actual y señala cuando no se pueden reproducir. El interruptor de medibilidad está activado porque el problema no especifica rutas ni tráfico, por lo que su contrato de resultado no se puede medir; si se desactiva, todos los problemas quedarían pendientes. Los problemas abiertos por personas con acceso de escritura se inician automáticamente; el resto esperan a que alguien los inicie, como se describe en Cuando comienza el trabajo.

Actuar según lo que informan los clientes#

Tu herramienta de soporte recopila informes de los clientes, y los casos urgentes llegan tarde al equipo de ingeniería.

La herramienta de soporte registra cada informe a través del sistema de entrada de trabajo API con una cuenta de servicio. La calificación descarta lo que no se puede reproducir, y el mandato impide que una semana cargada de informes ocupe más de la mitad de las plazas de agente o supere el presupuesto.

Finalizar una limpieza antes de la fecha límite#

El SDK de pagos que utilizas llegará a fin de vida el próximo trimestre, y sus llamadas obsoletas están distribuidas en dos servicios.

Un trabajo de CI genera una solicitud por cada sitio de llamada, usando el archivo y la línea como huella digital de señal; así, un sitio de llamada que aparezca de nuevo en la siguiente ejecución se vincula al trabajo que ya lo gestiona. Coroid aún no lee el destino: cuando desaparece la última llamada, seleccionar Completar tú mismo.

Cuando no necesitas un mandato#

• El trabajo que pide el equipo. Las solicitudes creadas en Nuevo trabajo o importadas se admiten cuando cumplen los requisitos, nunca se posponen y nunca consumen el presupuesto de un mandato.
• Programaciones y seguimientos de hooks. Crean tareas directamente, sin pasar por Calificación, por lo que ningún mandato las limita. En su lugar, dales una prioridad más baja; consulta Programaciones.
• Una iniciativa puntual. El trabajo con una forma y un fin conocidos es un plan, no un mandato.
• Mandatos solapados. Cuando varios mandatos activos cubren el mismo Proyecto, el más antiguo regula sus solicitudes. Asigna cada Proyecto a un único mandato.

Dónde residen los mandatos#

Abrir Control de Calidad → Mandatos. Cada ámbito en Control de Calidad —el valor predeterminado de la organización y cada Proyecto— se vincula a la misma lista, ya que un mandato pertenece a la organización y nombra sus Proyectos por sí mismo. Abrir el ámbito de un Proyecto no filtra la lista.

Los Propietarios y administradores crean y modifican mandatos. Los Miembros pueden leerlos. Los Agentes y cuentas de servicio no pueden modificar ningún mandato en absoluto.

Qué contiene un mandato#

Tipo. Finitos los mandatos tienen un objetivo y finalizan cuando se alcanza, por ejemplo "reducir a cero los hallazgos de seguridad abiertos". Continuos los mandatos son de mantenimiento, como por ejemplo "mantener las rutas de producción libres de excepciones no gestionadas"; tienen una fecha de revisión en lugar de un objetivo.

Objetivo. Una frase que describe lo que debe ser cierto. Es así como las personas interpretan el mandato; la admisión en sí sigue los criterios de ámbito, presupuesto y estado.

Línea base. La métrica con la que se mide el mandato y su origen. Tú defines la métrica y Coroid recopila las lecturas, nunca se introducen manualmente. Nunca forman parte de una exportación de configuraciones. Un nuevo mandato muestra Aún sin lectura.

Objetivo. Para un mandato finito: la métrica y el valor que indican que se ha completado.

Prioridades. Una por línea. Cuando el trabajo compite por capacidad, gana la primera prioridad.

Ámbito.

• Proyectos. Los proyectos que cubre el mandato. Si no se selecciona ninguno, cubre todos los proyectos de la organización, incluidos los creados posteriormente. Marca los proyectos que deseas incluir; un mandato destinado a un repositorio específico debe nombrar ese proyecto.
• Áreas. Patrones de ruta dentro de esos proyectos, uno por línea, por ejemplo apps/api-*/src/**. Si está vacío, significa cualquier lugar.
• Clases de cambios. Los tipos de cambios para los que sirve el mandato, por ejemplo exception_fix.
• Admite trabajos cuyo resultado no se pueda medir. Desactivado por defecto. Cuando está desactivado, una solicitud cuyo contrato de resultado no se pueda medir esperará en lugar de iniciarse.

Presupuesto. Cuánto puede gastar Coroid en el mandato en cada período, en dólares estadounidenses y horas de agente, por semana o por mes. Una semana comienza el lunes a las 00 UTC; un mes, el primer día del mismo. El presupuesto se reinicia automáticamente.:00 UTC; un mes, el primer día del mismo. El presupuesto se reinicia por sí solo.

Condiciones de detención. Se detiene cuando se agota el presupuesto, cuando se alcanza el objetivo, después de varios resultados inconclusivos seguidos o en una fecha determinada.

Fecha de revisión. Para un mandato en curso: la fecha en la que una persona lo renueva o lo retira.

Regla de desviación. Para un mandato en curso: un límite para la métrica de referencia. Superarlo en un período debe generar una notificación al responsable.

Estado y versiones#

Un mandato comienza como un borrador. Publicar lo convierte en activo, y solo los mandatos activos admiten trabajo.

Al modificar un mandato publicado, se genera una nueva versión. Las versiones anteriores se mantienen con quien las publicó y cuándo lo hizo.

Cada publicación y cada cambio de estado constituyen una decisión dentro del mandato. Procedencia, junto con la persona que lo realizó y un evento en el flujo de auditoría de tu organización (mandate.created, mandate.published, mandate.paused y así sucesivamente).

Qué solicitudes regula un mandato#

Un mandato regula las solicitudes que llegan sin una persona en Coroid: desde la entrada de trabajo de API, desde automatizaciones e integraciones como GitHub o incidencias de Jira, y desde la monitorización.

Una solicitud que una persona realiza en Nuevo trabajo, o las importaciones, no están sujetas a un mandato. Siempre se admite si cumple los requisitos, nunca se pospone y no consume el presupuesto del mandato. Una persona la solicitó; los agentes simplemente la ponen en cola.

Una solicitud no atendida se empareja con el mandato activo más antiguo cuyos proyectos incluyan el proyecto de la solicitud, o con el que abarque todos los proyectos. Una solicitud que ningún mandato cubra se admite como una solicitud ordinaria.

Qué decide la admisión#

La admisión es el último paso de Calificación. No realiza ninguna llamada al modelo. Para cada solicitud, decide una de las siguientes opciones:

• Admitida. El trabajo se crea, con una reserva para un espacio de agente y, bajo un mandato, para parte del presupuesto del mandato. Si comienza por sí solo depende de la fuente, como se describe en Cuándo comienza el trabajo.
• Ya resuelto. La misma señal —la misma incidencia en tu sistema de seguimiento o monitorización, o la misma falla— ya está siendo gestionada mediante otra solicitud en cualquier proyecto de la organización. La solicitud se vincula a ese trabajo y no se crea nada nuevo.
• No se necesita cambio. La evaluación de la calificación determinó que el comportamiento reportado es intencionado. No se crea nada.
• Pospuesta. La solicitud es admisible pero no debe iniciarse ahora: la cuota de espacios de agente del mandato está en uso, su presupuesto para ese período se ha agotado, o su resultado no puede medirse y el mandato no lo permite.

Cada decisión y su razón se registran junto con la solicitud.

Solicitudes pospuestas#

Coroid revisa las solicitudes diferidas cada minuto y las admite en cuanto haya un espacio o presupuesto disponible, según la versión actual del mandato. Al aumentar el presupuesto del mandato o pausar otro mandato que ocupe espacios, se liberará una solicitud diferida en la siguiente comprobación. No existe ninguna opción para iniciar una solicitud directamente.

Una solicitud que haya esperado más tiempo del permitido por el plazo del mandato — una semana o un mes — o cuyo mandato ya no esté activo, finalizará sin que se realice ningún trabajo.

Cómo el trabajo de los mandatos comparte capacidad#

El trabajo de los mandatos puede ocupar como máximo la mitad de los agent slots de su organización. agent slots al mismo tiempo, contando tanto el trabajo en ejecución como el trabajo admitido pero aún no iniciado. El resto queda libre para lo que soliciten los usuarios. Si su plan incluye un número ilimitado de slots, la misma proporción se aplicará a su presupuesto mensual de gastos.

Una solicitud admitida mantiene su reserva durante 30 minutos mientras se inicia su tarea. Después de ese tiempo, la reserva expira: una solicitud cuyo trabajo aún no se haya creado volverá a estar diferida, y una tarea ya existente esperará un espacio como cualquier otra.

En una exportación de configuraciones#

Los mandatos viajan dentro de una exportación de configuraciones: tipo, objetivo, destino, prioridades, alcance, presupuesto, condiciones de detención, fecha de revisión y regla de desviación. Los proyectos se identifican por su clave estable y los propietarios por su rol. Las líneas de base nunca viajan; son mediciones de la organización de la que provienen. Un mandato con un nuevo objetivo llega como borrador para que una persona lo publique. Uno cuyo objetivo coincida con un mandato existente lo actualiza: el borrador si aún es un borrador; de lo contrario, como una nueva versión publicada.

Relacionado#

• Contratos de resultados
• Qué decide Coroid y qué permanece bajo su control
• Capacidad y agent slots
• Nuevo trabajo y calificación
• Procedencia