谈运维监控流程改进(8.16)

在整个平台上线，服务实施工作也基本结束后，那么我们的工作重点就应该转到整个服务监控和服务运维上面，而对于服务监控在前面很多文章里面都谈到过，服务运维也应该遵循基本的ITIL标准规范和流程进行执行，即在运行期的系统，做了任何一件事情都要有记录，有流程，有规范模板，有跟踪并最终关闭。

对于运维流程而言，本身又涉及到几个关键方面。

其一是相关的标准规范流程，类似服务请求管理，事件管理，问题管理流程，变更管理，版本发和部署管理，基础环境和应用日常巡检流程规范流程等。这些都应该制定相应的标准规范体系，并按照规范执行。

可以看到在整个过程中涉及到需求变更或Bug缺陷，而这些就会进入到我们系统本身的研发版本规划，研发开发测试，版本部署上线，客户验证，最终完成整个闭环流程，因此运维流程本身又和我们前面谈到的研发过程改进里面的研发生命周期端到端管理融合在一起形成一个整体。

其二是运维本身的自动化，运维自动化里面包括了很多方面的内容，类似的包括了日常巡检工作通过脚本的自动化，关键信息和数据备份的自动化，环境部署的自动化，环境迁移的自动化，环境和应用监控的自动化等。这些自动化工作将极大的节约人工运维的工作量，同时提高运维管理效率。

其三是运维工作的主动化，即我们经常谈到的通过日常运维巡检，通过APM性能监控，通过我们当前的服务性能监控和预警等各种监控预警手段，来提前发现性能问题或其他环境问题，并及时采用有针对性的措施对问题或故障进行处理。这种基于风险意识的主动化运维和监控本身又包括两个阶段。

一阶段：基于预设的准则进行自动化监控并主动进行性能告警或系统故障告警

二阶段：在触发告警后能够进一步基于预设规则进行各种性能调整，类似服务优先级，限流熔断等

在第一阶段告警完成后，仍然需要我们人工介入去分析和处理，但是到了第二阶段，则各种性能优化和调整，服务SLA设置，限流熔断等都通过系统预设的规则自动优化完成。当达到了这一点后，我们基本可以说系统基本具备了自动的优化调整能力。

要注意到在系统正式上线后，对于CMDB基础配置库的稳定是相当重要的，不仅仅是业务系统的版本部署会影响到基础配置库，还有其他很多内容都会影响到基础配置库的变化，必须足够重视，其中包括。

1. 业务系统版本发布和部署，包括应用和数据库，包括基础数据导入更新

2. 单独的基础数据后台导入或更新

3. 服务注册和服务部署

4. 在管控前台进行的配置操作（包括服务授权，安全限流参数设置，基础组织系统数据录入，Token配置等）

5. 数据库或应用进行安全补丁升级

所有上述内容都会影响到基础配置库的变化，而这些变化本身将直接影响到我们应用和环境的稳定性，当应用本身出现问题的时候我们也应该首先检查下是否做了上述修改。所有对运行环境和应用的修改都应该有记录，对于关键修改有流程支撑，这是我们做好运维工作的基本要求，只有这样才能够建立长效的流程化支撑的运维机制，做到凡事有记录，凡事可回溯。