Short answer
Reliability engineering assesses how systems meet explicit availability, degradation, and recovery expectations.
About Reliability engineering
The ability to design and improve systems so they meet explicit availability, failure-handling, and recovery expectations.
Use this competency for
- Roles accountable for production availability, recovery, or failure handling.
- Functions that design safeguards for systems whose interruption has material consequences.
Do not use this competency for
- Roles with no influence over system operation, failure handling, or recovery.
Important distinctions
Performance engineering
Performance engineering addresses speed and capacity. Reliability engineering addresses continuity, degradation, and recovery.
Debugging
Debugging identifies a cause in a specific failure. Reliability engineering changes systems and operating practices to meet ongoing service expectations.
Expectations by level
IC1
Individual contributor 1
Applies established reliability safeguards to scoped work with guidance and confirms that the change can be observed and reversed.
Observable behaviors
- Adds the expected health signal for changed behavior.
- Uses the documented rollout and rollback steps.
- Updates the runbook when a known recovery step changes.
Examples
- Added an alert for a scheduled job using the team threshold and response link.
- Tested the rollback step for a configuration change before release.
IC2
Individual contributor 2
Independently designs reliability for a team-owned service, resolving failure, degradation, and recovery choices against agreed expectations.
Observable behaviors
- Defines how a change fails and what users experience.
- Tests recovery for critical state or dependencies.
- Uses incident and service data to prioritize safeguards.
Examples
- Added bounded retries and duplicate handling for an unreliable dependency.
- Ran a recovery exercise and fixed a missing database restore step.
IC3
Individual contributor 3
Sets reliability direction across teams for complex dependencies and makes service expectations, ownership, and recovery evidence explicit.
Observable behaviors
- Defines shared availability and recovery expectations with owners.
- Reviews cross-system designs for cascading failure paths.
- Uses incident patterns to change safeguards across teams.
Examples
- Established degradation behavior for a shared dependency used by several products.
- Coordinated a recovery exercise across three services and closed the ownership gaps it exposed.