One Problem at a Time
Keep the decision with your team
Acceptance records intent; your team reviews, merges, and deploys through its own change process.
One Problem at a Time · Episode 4 · 1:07
Why shouldn't optimization tools change production automatically?
Acceptance records intent; your team reviews, merges, and deploys through its own change process.
The decision panel is from a local test cluster, not AKS. The opening failure is an illustrative scenario. Git steps describe the customer’s workflow; the episode does not demonstrate RATIVERA creating, merging, or executing a pull request.
English captions are burned into the video. An optional English caption track and transcript are also available. Use fullscreen for small screen details.
Read the episode 4 transcript
At two in the morning, an automated tool lowers a service's memory limit in production. By six, the service is restarting.
Who approved that change?
Automatic changes act on a model of your workload. They do not know about next week's launch, a migration in progress, or a promise made to a customer.
Evidence should inform a change. Engineering judgment should decide it.
In RATIVERA, every recommendation waits for a person: accept, reject, or defer. Each decision is recorded against the assessment it was based on.
Accepting records the decision only. It does not execute or authorize an infrastructure change, and RATIVERA does not modify your cluster.
The change itself belongs in your Git workflow: a pull request that your team reviews, merges, and deploys through its own pipeline.
That way, every production change stays traceable: who proposed it, who approved it, and when it shipped.
RATIVERA. Understanding Kubernetes, one problem at a time.
Download transcript · WebVTT captions · Original SRT captions