17. 风险管理

涉及项目可能遇到各种不确定因素。它包括风险识别，风险量化，制订对策和风险控制等。

17.1. 开发，测试与运维的关系

开发，测试，运维不是三个独立部门，他们相互紧密联系，但又相互制约：

开发只负责写程序，将运行无误的程序提交至版本库中

开发不能私自将程序交给运维部署，也不能将编译好的程序给运维测试。

测试部只能从版本库提取代码，然后编译，打包，运行，测试

不允许测试部将代码交给运维部部署

避免代码没有经过版本库流入生产环境，线下与线上代码不一致

运维部负责部署应用程序，配置管理，只接受测试部确认无误的版本，部署代码只能从版本库中提取

17.2. 技术规范的误区

开发 -> 测试 -> 运维 贯穿始终。

几乎所有的技术企业都会重视技术规范，为此制定各种规范，并要求员工严格执行。同时员工会想出各种对策，就这样形成了潜规则。

流程与规范的制定需要需要满足几个条件，简单，容易掌握，容易执行，可重复执行

企业管理层擅长制定乌托邦式的流程与规范，随便拿出一条都堪称完美，无懈可击，但没有考虑到执行结果，流程规范在执行过程中每个环节都会出现问题。

我16年的职业生涯中在不同的公司任职过，几乎每到一家公司都会遇到各种规范，随着职业发展最后我也成为了规范的制定者，也曾经主持制定过开发规范，运维规范，测试规范等等。

我做过很多规范，文档无数，技术人员根本不会去看，通过开会向下传达，开会的人根本没有心思理会你的规范，规范执行阻力是很大的，效果也差。

终于有一天我意识问题的存在，开始反思，企业是否需要制定这些规范？ 我发现与企业环境/文化有很大关系。

有些强制的规范可以通过一些技术手段，避免出现。不会出现也就无需规范！

只有机器人才能100%执行流程

除了事，制定规范，后续无人跟进，

员工考虑的是尽快完成工作，

但这些规范起到的实质作用就好比“请保持室内卫生，不准乱团垃圾，禁止随地吐痰”

故事一

例如下面一个小故事，公司某部因为将开发数月的代码丢失了，导致测试无法进行，领导打发雷霆，某管理层制定了下面的规范，大意为。

1. 定期备份机制
2. 代码注释要求
3. 代码访问需要更高层的批准
4. 详细的部署文档
等等

我认为源码管理主要有两种手段，技术手段与管理手段。

我先谈谈管理手段： 例如通常通过规章制度，责任追究等等手段，要求员工达到规范标准，但通常执行力都会打折，无法达到预期，人的不稳定性因素太多。往往发现员工没有按照规范操作为时已晚，将该员工辞退也无法挽回公司的损失。

就如公司规章制度写的清清楚楚，要求员工提交代码到版本库，但各种原因没有被执行，当代码丢失，从上至下追究责任，公司的损失无法挽回。

所以我主张技术手段：
例如源码如果发布到线上，必须经过版本库，只能使用自动部署，不允许程序员私自将代码交给运维手工部署。另外发布代码的同事，可以不提供生产服务器登陆权限，他只能通过工具发布代码。
部署流程如下：
源码(程序员) 提交到development 分支UAT阶段 ----> 合并到 testing
分支Beta阶段（主管合并，程序员没有权限）------> master 分支(主管合并) -----> 自动部署系统(运维)
----> 生产服务器。
这样通过技术手段防止了代码因员工离职，硬盘损坏等等原因，导致代码丢失的可能。
代码发布者也无需对照部署文档，手动登陆服务器逐条按照部署说明书操作，防止了人员误操作，也提高了部署效率，节省了人力成本，通常在5分钟之内可以完成所有部署。

故事二

Sidebar content.

-----
我再来举另外一个例子，就是开发中的编码规范，很多软件企业都有是不是？

例如要求程序员：
if
(){}
要写成
if ()
{
...
}
等等要求不一一列举，甚至组织代码评审解决编码规范问题。

我的建议为什么不在IDE上设置自动格式化，或者在svn/git提交的时候通过hook调用格式化程序。

故事三
-----
管理层要求运维每天发送服务器状态报告，运维人员需要登录每个服务器或者从cacti等工具中获得服务器运行状态数据，然后制作一个报告文档，每天给各位发送一次。

运维需要一个专职人员做这个报告，这种报告几乎没有人看，就像“人民日报” 人民从来不看。

当运维事故该出现的时候还是会出现，老板一个一个骂，扣工资，扣奖金，运维觉得委屈，公司受到损失。平日里的这些工作并不能避免运维事故，也不能改善运维工作。

故事四
-----
在举一个例子，运维工作要求备份数据，A员工负责备份，B
员工负责检查A员工的备份，结果两年以后出事了，需要恢复数据，发现A没有备份，而B在一年前就再没有检查A的工作。起初前一年还是按流程备份，后来A发现B不再严格检查工作，备份工作逐渐减少，最后停止了备份，一直相安无事，直到事发。

故事五
-----
我曾经遇到过一个兢兢业业的管理者，他制定规范，要求值班的同事7*24小时，每间隔一定的时间做一次操作，验证系统正常运行，以便能够第一时间通知运维处理故障。值班的同事而偶偷懒，他就半夜起来监控他们工作。一个打工者能做到如此，真让人佩服。
但是我们有更好的方法，真的不必如此操劳且效率低下。

这些故事是一个无休止的死循环
-----
出问题 -> 发上制定规范 ->
无人看/看了慢慢淡忘/石沉大海 ->
继续出问题。连续出现问题，采用行政手段处分，扣奖金等等。很多管理者将其归咎为 “执行力”
弱，我并不这么认为。


我觉得很多规范是形式主义。我一向主张实用主义。

通过技术手段可能避免很多没有意义规范，开发自动化，测试自动化，运维自动化，这是趋势也是我的努力的目标。

上面仅仅举了几个例子，较片面，不能完全表达我的想法，需要更多的沟通，欢迎提出您的意见与建议。

原文出处：Netkiller 系列 手札
本文作者：陈景峯
转载请与作者联系，同时请务必标明文章原始出处和作者信息及本声明。

《新程序员》：云原生和全面数字化实践50位技术专家共同创作，文字、视频、音频交互阅读

总结

以上是生活随笔为你收集整理的17. 风险管理的全部内容，希望文章能够帮你解决所遇到的问题。

如果觉得生活随笔网站内容还不错，欢迎将生活随笔推荐给好友。