Why Ops Needs a Project‑Management Mindset: Lessons from a Simple RAID Change

Operations (运维) is often seen as an awkward role in IT: fresh graduates rarely encounter it, other engineers may dismiss it as low‑level, and its KPI impact is hard to demonstrate. The author reflects on the meaning of this role.

One Small Incident and the Reflections

In a work chat, colleague A reported a need to restart a server and redo RAID. The author probed the change’s background, discovering it was required to deploy an FTP service using RAID 5, replacing a non‑RAID setup.

Ops Must Understand the “Why” Behind Changes

Author: Do you know the background of this change? A: X told me we need to redo RAID. Author: Why redo RAID? A: To support the new FTP deployment.

Blindly executing a task without grasping its purpose is risky; each change is like merging onto a busy road, increasing the chance of a crash if the impact isn’t evaluated.

Ops Must Choose the Right Timing for Changes

Author: When will you do it? A: I’ll do it as soon as I get the task. Author: There’s a product demo at 2‑3 pm; a mistake could ruin it. What would the client think? A: I didn’t think of that.

Principles for timing:

Avoid peak business periods and critical windows.

Ensure changes on the same product line do not conflict.

Ensure changes across related product lines do not conflict.

Treat each change as a mini‑project, synchronising progress with all stakeholders who perform risk assessments.

Ops Should Act as the “Project Manager” of a Change

Author: Do you know the server’s current state? A: No. Author: If a core service is still running, what could happen? A: X said the machine is brand‑new, no services.

Ops must adopt a questioning attitude, verify assumptions, and confirm no hidden dependencies—much like a firefighter checks for remaining explosives before entering a blaze.

Follow a Structured Change Process

The typical workflow is: requirement confirmation → stakeholder identification → solution discussion → solution and schedule finalisation → change ticket creation → ticket review → approval → change announcement → implementation → post‑implementation review (and optional rollback). Following this process helps identify risks, standardise procedures, and enables automation.

Consistent adherence reduces the probability of incidents, spreads risk, and creates reusable documentation for future changes.

车祸猛如虎变更也一样

A Final Truth

Even a tiny change can teach many lessons; Ops is a global orchestrator that requires meticulous attention. As the author puts it, “Respect the production environment.”