Why Small Internet Companies Still Need Operations: Beyond the Myth of No Ops

<code>这是对一个问题的回应——“中小（互联网）企业真的需要运维么？”</code>

Many people assume that small internet companies can skip testing and operations because their IT environment seems simple, but this overlooks the business value that operational capability brings.

You may not need dedicated ops staff, but you cannot do without ops as a capability; it delivers tangible business value.

When businesses focus solely on rapid feature delivery—often multiple releases per day—they neglect the foundational capabilities needed to support that speed. Instead of using tools to streamline processes, they hire more people, mistakenly believing that more manpower equals higher productivity.

Introducing automation and standardized tools can save time and labor, yet many organizations still ignore this, over‑emphasizing pure business drive.

Technically, as product lines proliferate, organizational complexity grows and teams become autonomous. Small teams enjoy ordered information flow, but as the number of products explodes, information becomes chaotic, lacking standards, policies, or platforms. This “discrete organization” lacks a central control node.

What can testing and operations actually do?

Both disciplines still align with business goals but focus on delivering better functionality—improved testability, completeness, maintainability, and stability. Decades of methodology support high‑quality software delivery and should not be ignored.

Early involvement of testing/ops creates a test/ops‑driven development methodology. If testing joins only after requirements are set, it becomes a cost center rather than a value creator; the same applies to ops. Testability and operability influence design decisions from code to architecture.

Operations can serve as the central control node because all service delivery ultimately passes through ops. Ops are closest to users, can instantly capture usage status, and manage production environments, establishing unified technical standards across product lines.

Ops feedback drives further development optimizations—both business‑related (user experience) and non‑business (performance, cost).

To realize these benefits, ops should be separated from development and organized centrally. The evolution of the DO relationship includes three stages:

Stage 1 – Mixed: Ops is a sub‑process of development, handling resource delivery.

Stage 2 – Separated: Ops becomes independent, defining standards, building platforms, and collecting data.

Stage 3 – Fused: Ops capability flows into development; all engineers possess operational skills as part of their workflow.

With a centralized ops function, many activities become possible: defining standards, building automation platforms, collecting operational data, and enabling data‑driven DevOps practices.

Ultimately, ops is a capability, not a job title. Even startups can forgo dedicated ops personnel, but they cannot ignore the operational capability that accelerates business growth and improves product quality.