La excepción permanente
"Solo por esta vez, hasta que terminemos la migración." Tres años después, la migración no terminó y la excepción sigue ahí: un puerto abierto, una base de datos sin cifrar, una cuenta sin etiquetas. Nadie recuerda quién la autorizó ni por qué. Multiplicada por cincuenta, esa es la distancia real entre lo que dice la norma y lo que existe.
Lo que convierte una excepción en algo gobernado
Una excepción bien registrada tiene seis datos:
- Qué regla incumple, citada con su versión.
- Qué recurso o sistema afecta.
- Por qué es necesaria.
- Qué riesgo se acepta y qué medidas lo compensan mientras dura.
- Quién la aprueba y quién es responsable de cerrarla.
- Cuándo caduca.
La fecha es lo que importa
Sin fecha de caducidad, una excepción es una nueva regla escrita en un sitio donde nadie la ve. Con fecha, ocurre una de tres cosas cuando vence:
- Se cierra: el recurso ya cumple la norma.
- Se renueva, con un motivo nuevo y una nueva fecha, aprobada otra vez.
- Se escala, si nadie la cierra ni la renueva.
Lo que no puede pasar es que siga existiendo sin que nadie lo decida.
El registro como termómetro
Revisar el registro de excepciones dice mucho de la norma:
- Muchas excepciones sobre la misma regla: la regla probablemente está mal, y conviene proponer un cambio (como vimos en la vida de una norma).
- Excepciones vencidas que se acumulan: el proceso de revisión no funciona.
- Pocas excepciones, todas con fecha: la norma y la realidad están razonablemente alineadas.
Con las reglas y sus excepciones bajo control, queda llevar todo esto a varias nubes a la vez. La primera decisión de gobierno en cualquier nube es también la más estructural: cómo se organizan las cuentas.
Cómo lo aplicamos: Gobierno Multicloud.