WEBVTT

1
00:00:00.167 --> 00:00:03.900
At two in the morning, an automated tool lowers a service's

2
00:00:03.900 --> 00:00:05.600
memory limit in production.

3
00:00:05.600 --> 00:00:08.167
By six, the service is restarting.

4
00:00:08.167 --> 00:00:10.100
Who approved that change?

5
00:00:10.567 --> 00:00:13.600
Automatic changes act on a model of your workload.

6
00:00:13.600 --> 00:00:16.167
They do not know about next week's launch,

7
00:00:16.167 --> 00:00:20.133
a migration in progress, or a promise made to a customer.

8
00:00:20.600 --> 00:00:22.400
Evidence should inform a change.

9
00:00:22.400 --> 00:00:25.067
Engineering judgment should decide it.

10
00:00:25.533 --> 00:00:29.200
In RATIVERA, every recommendation waits for a person:

11
00:00:29.200 --> 00:00:30.967
accept, reject, or defer.

12
00:00:30.967 --> 00:00:35.200
Each decision is recorded against the assessment it was based

13
00:00:35.200 --> 00:00:35.800
on.

14
00:00:35.800 --> 00:00:38.133
Accepting records the decision only.

15
00:00:38.133 --> 00:00:41.900
It does not execute or authorize an infrastructure change,

16
00:00:41.900 --> 00:00:45.133
and RATIVERA does not modify your cluster.

17
00:00:45.600 --> 00:00:48.567
The change itself belongs in your Git workflow:

18
00:00:48.567 --> 00:00:50.967
a pull request that your team reviews,

19
00:00:50.967 --> 00:00:54.200
merges, and deploys through its own pipeline.

20
00:00:54.200 --> 00:00:56.967
That way, every production change stays traceable:

21
00:00:56.967 --> 00:01:00.467
who proposed it, who approved it, and when it shipped.

22
00:01:00.933 --> 00:01:05.333
RATIVERA. Understanding Kubernetes, one problem at a time.