软件研发管理系列文章（运维服务）

前面分享了需求管理，版本管理，研发流程，绩效管理，这里分享运维服务，产品开发完了，就该销售或者上线运营了，下一步就交给运维团队，也就是售后服务团队。

导向，运维自动化，自动化运维，通过技术解决问题，而不是人工解决 运维从背锅侠变成技术专家的转型。

1、概念性的内容

1）运维的工作就是系统交付，就是把系统运行起来，再一个就是日常维护，通过日常的维护、巡检，提前发现问题，防止系统出故障；再有就是出故障时快速恢复，尽量少的避免客户损失。

2）现在运维团队的工作已经进化了非常多，从devops到谷歌的sre，运维团队对于架构，开发和问题解决等的工具化，平台化，把工作融入到前端开发，而不是后端的被动救火。

3）sre，站点可靠性工程师，从名字就知道了，这是让站点故障让客户无感知的岗位，谷歌是全球top级的互联网公司，他的业务以自运营为主，这样在全球有无数的节点来服务用户，这些节点的故障必然导致用户的影响甚至损失，所以可靠性非常重要。说到可靠性，大家耳熟能详的双机冷备、热备、温备，分布式负载均衡，冗灾，两地三中心，多链路，多副本。

4）可靠性的本质是冗余，就是通过多个工作单元之间的有机组合，在部分出问题时，不影响或者尽量少的影响用户。

2、技术性的方案

运维工作很多的印象中是工程问题，是操作问题，实际应该是技术问题，通过技术让系统不出问题，出问题能自愈，不能自愈的要及早发现并能通过工具快速恢复。接下来我要把完整方案给大家罗列罗列。

1）安装部署平台，环境即代码

在devops以前，开发环境与测试环境和运行环境是分离的，环境配置都是按照指导手册完成的，devops提出了环境即代码的方法，就是把环境的所有操作象代码一样管理起来，通过配置系统进行管理，跟着系统走，这样每一套环境就可以是一样的，这样就不会存在不一致的情况。环境管理涉及到物理服务器，虚拟服务器，容器，数据库，操作系统，分布式微服务等的脚本和配置，这些系统的打包，安装，配置的脚本，文件都一起打包、归档、发布。

2）告警

告警平台，告警收集脚本，应用系统打点，告警通知机制，根据告警实现自动处理，自动工单，不能自动处理的，生产人工工单。及时检查系统健康度，给系统体检，及时发现和告警和自动处理问题。

3）日志

日志分级，应用系统日志打点，日志分析平台，根据日志了解系统的健壮性，研发埋点质量变得很重要，要把设计系统健康度的信息 ，以最小化信息量，最小化频率产生出来，产生一般在内容 由日志服务到存储盘，再由工具进行分析。分析工具要把日志在立体化建模出来，能复原每一个业务操作流程，进而反应系统健康度。

4）巡检，巡检脚本，巡检分析平台

周期性给系统体检，把关键必要的点 ，甚至模拟业务操作来触发业务流程。巡检与人的体检一样主动发现问题，并告警解决。

5）配置服务，配置即代码

配置文件弊端很多，是上一个时代的做法，每次需要重启系统，这个会导致很多问题，配置错误，配置不一致 配置不同步等等等。配置服务，建立配置管理，配置刷新，配置版本，配置回滚的服务，避免了重启和多系统配置不一致，不同步的问题。

6）itsm，运维管理系统

运维组织需要一个管理系统，实现运维管理的及时有效，可记录课考核的流程平台。

7）服务治理平台，微服务，容器，容器治理，服务治理

实现服务的注册、发现、启停、扩容、减容，通过服务管理实现系统的自愈能力。

8）在线升级，灰度发布/特性开关/金丝雀发布

通过分布式负载均衡服务，通过新老系统的并存，来检查新系统的正确性，再逐步切换，实现不停机升级。

9）监控，作战室，作战大屏

大的运维组织需要有一个作战室和大屏 掌握全球的系统运行情况，并及时协调解决问题。

10）备份，冗灾，恢复

最后一招，也是底裤，是不能脱的，就是备份容灾和恢复工具，系统出问题，又不能短时间解决的时候，就回到上一个健康状态 这个很重要，很多系统没有，所有的恶性事件都是没有这个系统模块。