背景

最近和小伙伴们吐槽，发现在产品故障review，尤其是涉及到运维的故障review的时候有两个经常背锅的兄弟——“流程”和“监控”。

一般伴随着 发布流程有问题，变更流程不规范，工单流程错误等。

监控呢？基本上就是监控未覆盖，监控报警阈值不合理。

监控问题是运维的重心，这部分内容有机会展开，这几天主要思考了一下流程的问题就一些形而上的务虚的内容掰扯掰扯。

流程的四项基本论断

（本来是想写四项基本原则的怕被喝茶算了）

1 流程需要兼顾效率。

2 没有工具和平台支持的流程终将废弃。

3 流程/工具/平台 最终落实在人的身上。

4 闭环、闭环、闭环

论断1  流程需要兼顾效率

增加流程必须要评估带来的成本和降低的效率，成本提升\效率下降是增加/修改流程必然会带来的负面作用，而且是经常被忽视的。

必须要时刻提醒领导，增加流程会带来成本的增加和效率的降低，怎么说？

以增加审批流程为例，增加一道审批就增加了审批人的工作、并且降低了整体工作的完成效率。对于单个任务也许不明显但是对于量大的日常工单这部分的损耗不可忽略。

完善流程的动力——稳定性可靠性 这是老生常谈的话题，但是稳定性是需要和成本效率做衡量取舍的。

《SRE: Google运维解密》这本书里面明确指出了，不应该盲目的追求高可用性,从99.9% -->99.99%的也不付出的成本是巨大的。

但是也正如DEVOPS里面的墙理论，OPS考虑的是稳定性、DEV考虑的是效率，那么出现了这个流程问题，OPS倾向于增加流程，但是增加流程势必影响DEV的效率？

DEVOPS的实践理论是要推到这堵墙。

综上，当出现了故障，需要谈到增加和修改流程的时候，运维领导必须要考虑到由此带来的成本和降低的效率比较带来的稳定性提升到底是否划算。但是这个问题引发另外两个提问？

问题1： 如何评估上升的成本和降低的效率

问题2；如何评估业务稳定性提升了多少

无法量化无法比较，那无法决策，这个是个难题，这其实是运维的一大课题，如何量化日常运维的成本以及效率？（这得后期展开说了）

但是首先请在故障review的时候得谨慎回应完善流程。

论断2  没有工具和平台支持的流程终将废弃

有了流程，流程在哪？

有人说流程在wiki上，有人说流程在心里。我说流程应该内化在平台上。

信息论里面熵的定义都不陌生，熵让我理解了一件事，如果不施加外力影响，事物永远向着更混乱的状态发展，落在wiki和人心上面的流程也是一样。

流程的确立规范标准化需要人力维持，一旦人员变更，事有松懈，那么在wiki上面的流程区域混乱。

发布的流程、变更的流程需要工具和平台将流程内化在自动化平台内。

这是运维自动化、平台化的内涵，把一切流程内化涵盖，这也是论断1效率的要求。

论断3 流程/工具/平台 最终落实在人的身上

所有的问题都是人的问题，完善的流程、自动化的平台也挡不住低级错误不断的人的失误。

流程工具平台之外，对于运维人员素质培养意识提升是至关重要的。

哲学上看这部分属于主观能动性了，素质高的人员在小米加步枪的情况下也能取得胜利。

论断4 闭环、闭环、闭环

闭环啥意思？

强调三遍的意思在于，任何一个流程要能形成一个正反馈的闭环，流程自身有不断修正反馈问题的机制。

哪些环节的不断修正？

效率（流程的各个环境的效率统计）

成功率（流程各环节流转的成功率，比如发布成功，变更失败统计）

审批（审批时效等）

等等

以上其实涉及到了运维数据运营的范畴。

一个流程结束之后必然要能体现什么，反馈什么。

应用运维的价值体现

1 协助应用产品方设计使用合理的流程，合理体现在需要在稳定性与成本效率之间做好平衡，这个平衡也只有应用运维才好去把控。

2 推动产品相关流程的自动化平台化服务化，运维开发本身需要应用运维去确定流程，并且不同产品之间也需要组合不通的流程，平台化建设需要应用运维推动。

3 人的价值就是指应用运维的价值，在平台流程趋向完善之前，应用运维是稳定性和成本效率的摆渡人。（我在瞎扯请忽略）

4 闭环本身就是数据运营本身是应用运维的另一个价值点。

广告时间依旧：

网易运维与账号中心正在招聘包含了应用运维、系统运维、数据库运维、运维开发相关岗位:

有兴趣加入的伙伴请简历 hzluyang@corp.netease.com