Saltar a contenido

Governance Rules

Regla permanente

Ningun servicio nuevo o modificado se considera terminado si no actualiza Governance.

Regla de trazabilidad completa

Todo servicio debe poder responder, como minimo, estas preguntas dentro de su ficha:

  • que es
  • donde vive
  • como corre
  • con que imagen corre
  • en que redes participa
  • que puertos usa
  • que volumenes o binds usa
  • que dominio lo publica
  • si pasa por NPM o no
  • que datos no se pueden perder
  • como se respalda
  • quien lo usa
  • de que depende
  • que rompe si falla

Reglas obligatorias

  1. Todo servicio debe tener un service_id unico y una ficha propia en services/.
  2. Toda ficha debe usar SERVICE-TEMPLATE.md y completar sus secciones obligatorias.
  3. Todo servicio compartido debe registrar sus Usos registrados.
  4. No se documentan secretos. Solo se documenta ubicacion, responsable, metodo de resguardo y riesgo.
  5. Si la evidencia no esta confirmada, se escribe pendiente de validar.
  6. Toda app nueva debe registrar proposito, owner, criticidad, dependencias, operacion, salud, backup y restore.
  7. Todo cambio relevante debe crear o actualizar el runbook correspondiente.
  8. El catalogo maestro y la auditoria baseline son la referencia operativa del VPS.
  9. Esta estructura debe seguir siendo compatible con una futura copia a /opt/governance.
  10. Governance manda sobre memoria informal: si algo no esta aqui, no se considera trazado.
  11. Toda documentacion, runbook, estado operativo o respuesta para admin debe usar lenguaje claro, amable y simple.
  12. Toda guia para admin debe explicar, cuando aplique: que es, para que sirve, donde esta, como se revisa y que hacer si falla.
  13. Si una explicacion tecnica necesita ejemplo simple para entenderse mejor, se agrega.
  14. Evitar jerga tecnica innecesaria.

Contratos de cierre obligatorios

Antes de cerrar un servicio nuevo o un cambio relevante, debe existir:

  • entrada en CATALOG.md
  • ficha completa en services/
  • catalogos especificos actualizados en catalog/
  • backup documentado
  • restore documentado
  • owner definido
  • revision de secretos
  • paso por CHANGE-GATES.md

Bloqueos de cierre

Ningun cambio se cierra si:

  • creo un servicio y no cree su ficha
  • agrego una red y no actualice catalog/NETWORKS.md
  • agrego un volumen o bind y no actualice catalog/VOLUMES.md
  • agrego un dominio o NPM y no actualice catalog/DOMAINS.md
  • agrego o cambio puertos y no actualice catalog/PORTS.md
  • agrego un backup o cambio su estrategia y no actualice catalog/BACKUPS.md
  • agrego un servicio compartido y no cree su usage entry
  • cambio dependencias y no actualice la ficha del servicio
  • cambio un runbook y no deje trazado el estado final

Regla de cierre

El servicio o cambio queda pendiente hasta que todos los contratos anteriores esten cumplidos.