Remediation#

In this edition, remediation is a preview. Hyvop writes a plan, shows it, and collects the approvals. It carries nothing out. It does not change or delete anything in your cloud account. Review the plan and apply the change yourself.

Remediation > Preview (/remediation/preview) lists the plans and opens one. Remediation > Action Queue, the tickets and destinations, the execution log and Governance Mode are locked in the Community Edition; they belong to the editions that carry changes out. Jira and ServiceNow tickets are not part of this edition either.

The plan#

A plan is made for an open finding on a resource that has an accountable person (ownership.md). Hyvop makes it by itself, as the finding moves along (findings.md). There is one open plan for a finding: asking again returns the plan there is, until it is rejected or the finding is reopened.

A plan holds: a summary and the reasoning; the savings options and the one chosen; a maintenance window; the steps; the messages and tickets it would send, as text only; the tier of the change; and the approvers, each with their role and the reason they are on the list.

The plan screen shows "What the agent knew" (each question it asked and what it was answered) and the rulings that shaped the plan. Plans have these statuses: Draft, Awaiting review, Changed (awaiting review), Approved, Rejected.

Who writes it#

The rules write every plan. If a model is set up (ai.md), it first drafts: it may choose among the finding's options, propose more approvers among the people already confirmed, and write a note. The rules then keep what is allowed and say, on the plan, what they refused. The model cannot name a person who is not confirmed. With no model, a used-up budget, a timeout or an answer that is not usable, the rules alone write the plan and the plan says so.

The tier#

Hyvop classifies the change into one of five tiers, from automatic to critical, with the environment in mind. The environment comes from a tag or from what the administrator said of the cloud account (core.env.REMEDIATION_ACCOUNT_ENVIRONMENTS). A resource's name is never read for it. Unknown is production: production or unknown never gets less than explicit approval. A tier can be raised by a rule, never lowered, and the reason is in the rulings.

Who must approve, and why#

The approvers are the people confirmed for the resource, in the order of their roles; the first is the accountable person. The plan says why each one is there, with the evidence. The rules in code are:

• Every approver is a confirmed person. A suggested or stale person never approves.
• Whoever asked for the plan does not approve it.
• A destructive or irreversible action (the option says delete, terminate, remove, destroy, drop, purge, release, decommission, deregister or wipe) has two approvers.
• The tier's number of approvers is a minimum.
• A policy can add an approver, or forbid the plan.

If nobody is accountable, or fewer people are confirmed than the tier needs, the plan is blocked. It says what is missing, nothing is sent to anyone, and it links to "Confirm who answers for it". Once ownership is confirmed the plan is written again in the same place.

The chain: in which order#

The plan screen has an Approval chain. Each approver is a step, with a position and a stage. The approvers of one stage are asked together; stages are asked one after the other. A person a policy requires gets a stage of their own after the others.

An answer out of turn is refused: "It is not your turn to answer this plan yet: it waits for Ada (Service Owner)." That holds whatever the channel: the screen or a mailed link. Someone who is not a required approver is refused. Each step shows why this person, the channel, when it is due, and the answer with its comment. An administrator can have approvers answer in any order instead (core.approvals.order: any).

Approving#

On the plan screen, a required approver whose turn it is can Approve or Reject, if their account is a user or an administrator; a viewer cannot answer on the screen (a mailed link needs no account). A required approver or an administrator can also edit the plan, as long as nobody has answered; an edit sends it back to "Changed, awaiting review".

By e-mail link. When a relay is set (mail.md), Hyvop mails each person whose turn it is a link. The person opens it, reads the plan and answers, without an account. Opening the link decides nothing: the answer is a separate step, so a mail scanner that follows links answers nothing. The link is theirs alone and works for seven days as shipped. A forwarded e-mail lets its holder answer in the approver's name until the link expires.

With no relay, nothing is mailed, and the product says so. Whether mail is sent also depends on how the administrator set core.approvals.requests: send, show-only, or by-edition.

Reminders and escalation#

• When a step opens, its approvers are mailed once.
• An approver who has not answered is reminded every 3 days, twice at most, as shipped.
• A step has a time, 5 days as shipped. Past it, the step is escalated once: the next person of the chain is asked as well and may answer; or, when the chain names nobody further, the FinOps reviewer (an address the administrator sets, otherwise the organisation's administrators) is told.
• The overdue person's approval is still required. Escalation never lets a plan be approved by fewer people than it needs.

approvals.md has the settings for these.

Not built: Slack as a channel (approval is by the screen and by e-mail), a second level of escalation, and everything that comes after approval. When every required approver has approved, the finding is Approved and the loop stops: nothing is executed, nothing is verified, and no ticket is opened.