开发质量系列：系统运营必须派人常驻机房吗？

系统正式上线后，就会进入日常运营阶段。进入运营阶段，团队的首要目标就发生变更，从建设系统变化为保证系统的稳定性及业务连续性，以及提供常规版本的功能更新。为了保障系统的稳定性，必须做好以下工作：

1. 系统具备一定的容错手段，哪怕是部分功能出现故障，也不会造成系统崩溃。而且在主流程正常的情况下，能把故障的功能进行合理提示并引导到人工处理的方式；

2. 当出现系统崩溃时，具备应急方案能随时启动，保障系统快速恢复或者启动备用系统，让业务不至于长时间被影响；

3. 若系统出现常规故障时，具备运维手册让运维人员自行快速处理，让连锁效应扼杀在摇篮之中；

4. 系统具备基本的监控手段，对日常的硬件（如 CPU、内存、磁盘、网络等）及软件（如数据库状态、中间件状态、主流程节点状态等）进行实时监控并保留监控日志。若出现故障能够通过短信等主动通知方式让运维团队和开发团队尽快获知。

上述每个点都可以单独拿出来讲一套方法论，本次文章的分享重点是：运维手册。对于系统常规性的运维，开发团队有必要做到事必躬亲吗？如何跟运维团队合作才能以最有效率的方式完成常规维护工作？运维手册正是其中的关键。

在展开内容之前，首先要对系统常规维护做范围约束。根据实际工作经验，会把环境信息、日志查询、功能调用及服务重启四块内容纳入到范围内。所以一份专业的运维手册，必然包含上述四点。

• 环境信息

列举系统的前后端登录信息，包括服务器名称、类型、IP、所有的登录用户以及登录用户对应的应用。

• 日志查询

列举每个服务产生的操作日志信息，包括存放目录、产生频度（比如每天一份或者每周日志），日志命名、错误标识。假如运维人员的技术面比较广，可以根据错误标识定位到问题所在，作出应急处理。假如运维人员不了解，也可以把相应日志发送给开发团队进行排查。

• 功能调用

列举常用功能的调用方式，包括功能描述、使用用户、启动语句及验证方式。未来即使开发团队不在现场，运维人员也可以通过开发团队的指示，按照运维手册的步骤操作常用功能。

• 服务重启

服务重启的信息跟功能调用类似，但是会多出停止顺序与启动顺序内容。有时候服务是存在依赖的，若不按照依赖进行停止或启动，将会出现不可预知的问题，所以一定要写清楚服务间的依赖关系。同理，运维人员按照运维手册对系统服务重启即可，无需开发团队在现场配合。

很多开发团队都在天天喊忙，天天在机房救火，殊不知都是在重复劳动而已。除了真正提升开发质量来避免系统产生 BUG 外，还可以把常规的系统维护措施落地到运维手册上，让运维人员也能帮忙分担开发团队的工作压力。