The document discusses configuration management in systems engineering, emphasizing the importance of maintaining consistent product states throughout their lifecycle. It highlights the need for observability, which allows teams to infer internal system states based on external outputs, and differentiates between monitoring and observability. Additionally, it covers execution feedback and the impact of environmental contexts on achieving target configuration states.

1. Configuration: Do you prove yours?
Infra Management Room
@abrianceau in/abrianceau alexandre@rudder.io

2. 2

3. Configuration management is a systems
engineering process for establishing and
maintaining consistency of a product [...]
throughout its life.
Configuration_management
“
3

4. How devops can help to understand?
4
Culture
AutomationShare
Measurement

5. Why we need Observability in Configuration Management?
5
Causality AgencyPerspective
trust and prove
configuration states
provide insights
relevant to different needs
help teams find
the best levers
for their job
A
B

6. 6

7. Let's remember: What does configuration management do?
7
configuration
target state
feedbackconfiguration

8. Let's remember: What does configuration management do?
8
configuration
target state
feedbackconfiguration
feedbackconfiguration
feedbackconfiguration

9. Observability is a measure of how well
internal states of a system can be inferred
from knowledge of its external outputs.
Observability
“
9

10. Monitoring VS Observability: having a factual & deep insight
monitoring observability
10

11. 11
PARAM
RULE
● Id
DIRECTIVE
● Id
● (Components)
GROUP
● Id
RUDDER config
(global)
● Policy Mode
● Schedule
● ...
NODE
● Properties
● Policy Mode
● Schedule
● ...
Environmental context
Historisation
Historisation
Compliance
historised
Event logs
Change request

12. 12
PARAM
RULE
● Id
DIRECTIVE
● Id
● (Components)
GROUP
● Id
RUDDER config
(global)
● Policy Mode
● Schedule
● ...
NODE
● Properties
● Policy Mode
● Schedule
● ...
Environmental context
● Id : . . .
● Generated : . . .
Files
Node configuration
Historisation
Historisation
Expected reports
(node id, config id,
timestamp)
Run reports
Historisation
Compliance
historised
Send expected reportsMetadata
● Integrity
● Signature
Config
● For Rule R,
Directive D1,
Component C
Event logs
Change request

13. 13
PARAM
RULE
● Id
DIRECTIVE
● Id
● (Components)
GROUP
● Id
RUDDER config
(global)
● Policy Mode
● Schedule
● ...
NODE
● Properties
● Policy Mode
● Schedule
● ...
Environmental context
● Id : . . .
● Generated : . . .
Files
Node configuration
Historisation
Historisation
RUN
● Reports
● Reports
● ...
● ...
METADATA
● node id
● config id
● run timestamp
RUN
● Reports
● Reports
● ...
● ...
METADATA
● node id
● config id
● run timestamp
● Signature
Get config
Send configuration
reports
Expected reports
(node id, config id,
timestamp)
Run reports
Historisation
Compliance
historised
Send expected reportsMetadata
● Integrity
● Signature
Config
● For Rule R,
Directive D1,
Component C
Event logs
Change request

14. Impactful events category
14
Definition ExecutionCreation
of the target state of the configuration of the configuration
rules
node’s groups
configurations
parameters
global
per nodes
environmental context
properties
policy mode...
tracing the configuration
generation process
OS specificity
template
variables...
predict configuration state
anticipation of any change
used to compare with the execution
execution feedback
fine grained comparison with the
expectation
prevent any alteration

15. Are you sure that I didn’t forget something ?
● And on the node itself ?
● Observability should be agnostic
○ Protocol normalization
● Beyond 1st level of external output usage
○ Data mining
○ Process mining and AI
15
Business oriented
Technique
oriented
External events
and targeted configuration state
Expected configuration
Execution
feedbacks

16. Configuration: Do you prove yours?
Infra Management Room
@abrianceau in/abrianceau alexandre@rudder.io