运维的工作方向相对多样，随着业务规模的不断扩展，互联网公司在运维岗位的划分上会越来越细致。当前，许多大型互联网公司在初创时期通常只有系统运维一类的职位，但随着服务规模和服务质量要求的提升，他们逐步细化了运维工作的分类。

  如图所示：

我们将运维工作分为以下四个阶段：

1.手工管理阶段
手工管理阶段主要负责线上服务的变更、状态监控、容灾和数据备份等任务，还包括定期检查服务和处理故障。

具体职责如下：
设计评审：在产品研发阶段参与产品设计评审，从运维角度提出意见，确保服务符合高可用性要求。
服务管理：负责制定和实施线上业务升级、变更及回滚方案，掌握所负责的服务和环境的各类情况。

2. 工具管理阶段
随着服务器数量和系统复杂度的增加，全人工操作方式已无法满足业务快速发展的需要。因此，运维人员逐步开始使用批量操作工具，并针对不同操作类型编写不同的脚本程序。但各团队都有自己的工具，每次操作需求变化时都需要调整工具。这主要是因为环境和操作规范不统一，导致程序化处理能力较弱。尽管效率有所提升，但也带来了新的瓶颈，操作质量并没有显著提升，甚至可能因为批量执行而引发更大规模的问题。为此，运维人员开始建立大量流程规范，如复查机制，先上线一台服务器观察10分钟，再继续后续操作，或一次升级完成后至少观察20分钟等。这些流程主要依赖人为监督和执行，但在实际操作中往往执行不到位，反而降低了工作效率。

3. 平台管理阶段
在这个阶段，对运维效率和误操作率有了更高要求，因此开始建设运维平台，通过平台承载标准和流程，解放人力并提高运维质量。此时对服务的变更动作进行了抽象，形成统一的操作方法、服务目录环境和服务运行方式标准，例如程序的启停接口必须包括启动、停止和重载等。通过平台约束操作流程，如之前提到的上线一台服务器观察10分钟，可以在平台中强制设定暂停检查点，第一台服务器操作完成后，运维人员需要填写相应检查项，然后才可以继续执行后续部署动作。

4. 系统管理阶段
由于服务数量更大、服务关联关系更复杂、各个运维平台林立，原有的批量操作转化为平台操作的方式已不再适用，因此需要对服务变更进行更高层次的抽象。将每台服务器抽象成一个容器，由调度系统根据资源使用情况，将服务调度和部署到合适的服务器上，从而自动化完成与监控系统、日志系统、备份系统等周边运维系统的联动。通过自调度系统，根据服务运行情况动态调整容量，自动化处理常见服务故障。运维人员的工作也会前置到产品设计阶段，协助研发人员改造服务，使其可以接入自调度系统。在运维发展的整个过程中，我们希望所有工作都能实现自动化，减少重复劳动，降低知识传递成本，提高运维交付效率和安全性，使产品运行更稳定。对于故障处理，希望由事后处理变为提前发现，由人工处理变为系统自动容灾。