Model Role SOP / Operating Playbook: DevOps Engineer

Purpose, scope and work products

Use this SOP when an authorised request, a pipeline failure, a planned release, or an observed delivery signal requires a change to the path from source to production. The assigned engineer can inspect, propose, implement and test a bounded delivery-system change and recommend a next action. The local service and change policy determines who may approve a production promotion, bypass a gate, accept a security risk, invoke rollback, or declare an incident resolved. Cloud-only administration, release scheduling, standalone test execution and security operations belong to their respective owners unless the assignment explicitly connects them to the delivery path.

The work should leave reviewable outputs appropriate to the case:

• a versioned pipeline, build, test, deployment or rollback change with review history;
• execution evidence that identifies source revision, workflow definition, inputs and test result;
• an artifact identity, such as a package version or image digest, linked to its build and registry record;
• a promotion decision request with the approved gates, approver and observed outcome;
• deployment and feedback evidence, including a known-good recovery reference where applicable; and
• an exception, incident or handoff note that tells the next owner what happened and what decision remains.

Do not create an artifact solely to fill the template. Retain the records that the employer's approved systems and retention rules call for.

Roles, inputs and locally controlled fields

• Requesting developer or team: Supplies the change purpose, repository, expected behavior and test context; confirms application-level defects and acceptance criteria.
• Assigned DevOps engineer: Maps the delivery path, changes the authorised workflow, runs or arranges validation, records evidence and communicates a recommendation. Confirm locally: repository access, pipeline permissions, environment scope and deployment delegation.
• Service owner or operations/SRE partner: Owns service health, operational constraints, alert interpretation and incident response for the service. Confirm locally: service ownership and the incident route.
• QA/test partner: Helps define useful validation, investigate flaky or failed tests and distinguish product failure from a broken test system.
• Security or control owner: Defines required scanning, provenance, secret, access and exception controls. Confirm locally: who may accept a failed or unavailable control.
• Release/change approver: Makes the approval decision where local policy requires it. Confirm locally: the named approver, permitted change window, separation of duties and rollback authority.

Before work starts, capture the local fields in the employer's approved request or change record: [service and owner], [repository and branch], [environment and deployment target], [approved pipeline and artifact registry], [change or incident record], [acceptance tests and gate policy], [release approver], [rollback decision maker], [monitoring signals and observation window], [communication channel], [record retention rule], and [working hours or on-call assignment, if any]. A missing material field is a clarification task, not permission to invent a default. Tool brands, thresholds, rotation and response times must come from the employer's actual configuration.

Trigger-to-close delivery workflow

Follow this sequence for a planned change or adapt its entry point to a failure or incident. Keep one linked case so another engineer can reconstruct the inputs, decisions and outcome.

1. Register the trigger and owner. Record the request, failed run, alert or release event; source link and time; affected service and environment; expected result; urgency; and requester. Check who owns the service and whether the engineer has authority to touch the workflow. For an incident, use the local incident route immediately rather than waiting for a normal change cycle.
2. Map the actual path. Identify source revision, workflow definition and dependencies, runner, build/test stages, artifact creation and registry, promotion gates, deployment target, feedback signals and recovery route. Compare the documented path with a recent execution. Mark unknown or inaccessible steps and ask the relevant owner; a diagram alone is not execution evidence.
3. Set the change boundary and acceptance check. State the fault or improvement hypothesis, proposed change, affected environments, expected test result, failure condition and rollback or restore option. Determine required review, security check, change window and release approver from local policy. If the request would waive a gate or expand production access, stop that action and seek the designated owner’s decision.
4. Implement a reviewable change. Modify only the approved pipeline, script, configuration or infrastructure component. Use version control and the employer's review route. Keep secrets in approved storage and avoid putting credentials into logs or artifacts. Where workflow dependencies or caches are involved, verify what revision or input actually runs rather than assuming a declaration proves execution.
5. Validate build, tests and artifact identity. Run the appropriate checks in an approved environment. Inspect the execution record for the source revision, workflow version, dependency resolution, test outcome and produced artifact identity. Compare clean and reused-cache results when a cache change could alter correctness. Check applicable scan or provenance gates; do not treat a green pipeline as proof that every control was present.
6. Request and record the promotion decision. Present the exact artifact, validation evidence, residual risks, target environment, observation plan and recovery option to the local approver. Record the approval or rejection in the approved system. The engineer's recommendation is distinct from the approver's decision. Silence, a successful test or access to a deploy button is not approval.
7. Deploy within assigned authority and observe. If authorised, promote the identified artifact through the approved mechanism. Verify that the target runs the intended artifact and that the expected service and deployment signals arrive. A missing alert or telemetry signal is unknown health, not a healthy pass. Compare behavior with the acceptance check for the locally specified observation period.
8. Handle deviation and hand off. On a failed gate, artifact mismatch, deployment fault, degraded service or absent signal, halt further promotion where authorised, preserve evidence and notify the named service/release/incident owner. Recommend rollback or restore using the known-good reference and local decision rule; execute it only if delegated or explicitly approved. Record the decision maker, action, verification and outstanding risk.
9. Close with evidence and improvement. Confirm the owner agrees that the acceptance condition or recovery condition was met. Link the final workflow revision, run, artifact, deployment, signal and decision records. Update the runbook or backlog with a specific correction, owner and due date when follow-up remains. Close the case in the local system, or mark it handed off with a named next owner and status; do not report an unresolved release as complete.

Operating rhythm

These are prompts for an agreed local cadence, not a claim that all DevOps roles have the same schedule. In the selected study, 53 of 106 postings did not state cadence; some named rotations or off-hours work, while others did not. Confirm each frequency, coverage period and handoff route with the employer.

• Daily or each assigned working shift: Review assigned pipeline failures, planned promotions, relevant service signals and pending approvals. Separate an application/test failure from a runner, dependency, artifact or deployment fault. Leave a status note for work that will outlast the shift.
• Weekly or each local planning cycle: Review recurring failure patterns, flaky checks, slow or unreliable stages and aged exceptions with developers, QA and service owners. Prioritise one bounded improvement and keep ownership visible.
• Monthly or each local control cycle: Reconcile runbooks, pipeline permissions, artifact-retention settings, recovery rehearsal or trend measures when those reviews are actually required. Use the employer's schedule and owners; a monthly review is not implied by every vacancy.
• At a release, failure, incident or tool change: Recheck the specific gates, artifact identity, signal path, approver and recovery action. Treat preview or beta features as controlled tests until the local platform owner has approved their use. Record what was observed and what remains unverified.

Decisions, handoffs and escalation

The engineer can normally explain the delivery path, present evidence, propose a bounded change and surface an exception. Local policy controls who may merge a protected branch, approve production release, change a required gate, accept vulnerability or availability risk, command an incident, or authorize rollback. The same person may hold several roles at one employer, but never infer authority from the job title or a tool permission alone.

Use a handoff that names the affected service/environment, current status, last known good artifact, failed or missing evidence, impact, action already taken, requested decision, next owner and next check time. Escalate immediately through the local incident route for material service degradation; to the release/change owner for an unapproved promotion; to security for a blocked or suspect control; and to the service owner for application-specific failure. If an owner cannot be reached, follow the employer's documented fallback and keep the risky action paused unless emergency authority is explicitly delegated.

Records, quality checks and measures

Keep the source/change record, reviewed configuration diff, pipeline run and test evidence, artifact digest or version, scan/provenance result where required, approval decision, deployment event, observation evidence and exception or rollback record linked in the approved system. Record timestamps and owners so the next engineer can distinguish a planned action from an executed one. Do not copy sensitive logs or secret values into a broad status report.

Check quality at the boundary where errors become costly:

• Reproducibility: Can a reviewer identify the source revision, executed workflow and inputs that produced the artifact?
• Artifact traceability: Is the deployed identity the same one that passed the required checks and was approved for promotion?
• Gate integrity: Were required tests, scans, reviews and approvals executed, with failures or waivers documented by the right owner?
• Feedback validity: Are expected signals present and correctly associated with this release, service and observation interval?
• Recovery readiness: Is the known-good reference valid, and has the relevant restore path been checked under local rules?
• Handoff completeness: Can another engineer continue without guessing the status, decision maker or next action?

Possible local measures include change lead time, failed-deployment or rollback rate, time to restore service, pipeline failure/retry rate, flaky-test recurrence and artifact-to-deployment traceability. Define the event boundaries and data source before computing any measure; report missing data rather than treating it as zero. Use measures to investigate and improve a path, not as universal benchmarks or evidence of this sample's actual outcomes. DORA's delivery metrics guidance offers a conceptual starting point, not a target derived from the vacancy study.

Exception handling

• Build or test fails: Preserve the failing stage and inputs; ask the application or QA owner to help isolate product code, test design, dependency and runner causes. Do not disable a required test to obtain a pass without the local control decision.
• Artifact cannot be identified or differs from approval: Stop promotion; compare build, registry and deployment records; request a fresh decision for the actual artifact.
• Scan, provenance or access check fails: Keep the gate enforced; route the evidence to the security or policy owner. A tool outage is an exception to resolve, not evidence that the artifact is acceptable.
• Telemetry is missing or ambiguous: Treat health as unverified. Check instrument, collector, alert rule and deployment correlation with the service owner before relying on an automated success or rollback decision.
• Deployment degrades service: Use the incident route, preserve the timeline and request or invoke the authorised recovery action. Verify recovery against the service owner's signal, then document the contributing delivery-system fault.
• Approval or owner is unavailable: Retain the proposed change and evidence, mark the case blocked, and use the documented escalation path. Do not convert an unanswered request into approval.

Reusable SOP model

Copy and fill this compact record in the employer's approved system for each service and change type. Bracketed values are local employer fields, not predefined MTF policies.