Home | 简体中文 | 繁体中文 | 杂文 | Github | 知乎专栏 | 51CTO学院 | CSDN程序员研修院 | OSChina 博客 | 腾讯云社区 | 阿里云栖社区 | Facebook | Linkedin | Youtube | 打赏(Donations) | About
知乎专栏多维度架构

7.3. 制度、流程和规范的误区

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

这些规范就好比“请保持室内卫生,不准乱丢垃圾,禁止随地吐痰,不要闯红灯” 一样没起到的实质作用。

管理层擅长制定乌托邦式的流程与规范,随便拿出一条都堪称完美,无懈可击,但没有考虑到执行结果,流程规范在执行过程中每个环节都会出现问题。任何一个环节出现问题就如同多米诺骨牌,造成连锁反应,最终无法控制。

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

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

终于有一天我意识问题的存在,开始反思,是否需要制定这些规范?制定流程规范的目的是什么?

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

7.3.1. 故事一

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



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

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

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

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

所以我主张技术手段:例如源码如果发布到线上,必须经过版本库,只能使用自动部署,不允许程序员私自将代码交给运维手工部署。另外发布代码的同事,可以不提供生产服务器登陆权限,他只能通过工具发布代码。

部署流程如下:



源码(程序员) 提交到development 分支UAT阶段 ----> 合并到 testing 分支Beta阶段(主管合并,程序员没有权限)------> master 分支(主管合并) -----> 自动部署系统(运维) ----> 生产服务器。

这样通过技术手段防止了代码因员工离职,硬盘损坏等等原因,导致代码丢失的可能。

代码发布者也无需对照部署文档,手动登陆服务器逐条按照部署说明书操作,防止了人员误操作,也提高了部署效率,节省了人力成本,通常在5分钟之内可以完成所有部署。

7.3.2. 故事二

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



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

我的建议为什么不在IDE上设置自动格式化,或者在svn/git提交的时候通过hook调用格式化程序。甚至可以做到,在提交的时候编译,编译不通过,就提交不上去。

7.3.3. 故事三

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

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

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

7.3.4. 故事四

在举一个例子,运维工作要求备份数据,制定规范,A员工负责备份,B 员工负责检查A员工的备份。这个流程没有任何问题。

结果两年以后出事了,需要恢复数据,发现A没有备份,而B在一年前就再没有检查A的工作。

起初前一年还是按流程备份,后来A发现B不再严格检查工作,备份工作逐渐减少,最后停止了备份,一直相安无事,直到事发。

7.3.5. 故事五

我曾经遇到过一个兢兢业业的管理者,他制定规范,要求值班的同事7*24小时,每间隔一定的时间做一次操作,验证系统正常运行,以便能够第一时间通知运维处理故障。

值班的同事偶尔偷懒,他就半夜起来监控他们工作。一个打工者能做到如此,真让人佩服。

但是故障的频率依然没有改观,运维仍是每天疲于奔命的救火。

但是我们有更好的方法,真的不必如此操劳且效率低下。

7.3.6. 总结

上面的几个故事是一个无休止的死循环

			
出问题 -> 领导发火 -> 行政处分 -> 制定规范 -> 执行规范 -> 慢慢淡忘 -> 后续无人跟进 -> 石沉大海 -> 继续出问题。
			
			

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

员工考虑的是尽快完成工作,规范不应成为完成工作的负担。

只有机器人才能100%执行流程,任何由人执行的流程规范都不可能做到100%执行,在军队中即使是严格训练过的士兵也常常犯错。

很多管理者将其归咎为 “执行力” 弱,我并不这么认为。有些犯错并不是执行力问题,也不是敬业度问题,可能需要从心理学角度解释。这是我在阅读几本心理学著作后发现的。

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

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

7.3.7. 案例分析:怎样避免电梯伤人事件再发生

电梯与我们的生活是密不可分,生活在城市,很难想象如果没有电梯会怎么样。

事件起因、经过和结果

几年前有一起电梯(手扶梯)伤人事件,事情的起因是这样的,一家商场电梯维修了一半,为了不影响商场运业,维修人员几把盖板临时盖上,供顾客使用。

事件的经过是这样的,一位妈妈带着孩子来到商场购物,一脚踩在电梯盖板上,盖板突然反转,顾客直接掉进电梯,母亲顺势将孩子抛出,然后就被搅入传送机构,血肉模糊,最后惨死在电梯里。

最后我们看看处理结果,事件发生之后,新闻与评论无非是指责商场,指责电梯维保,指责生产厂家,探讨电梯行业等等舆论层面。商场马上启动公关,进入司法理赔谈判等等。

我们看到舆论只会去职责,从未有人提出过解决方案。

怎样彻底解决电梯伤人,让这种事件不能再次发生呢?

社会舆论一边倒“管理层面”,也就是提高商场服务意识,工作人员敬业程度等等,但这些因素是不可控。

另一种是“技术层面”,通过技术手段解决电梯安全问题。在我看来此次事件是电梯设计缺陷所致。

电梯伤人事件解决方案.  现在我来说说技术层面“电梯伤人事件解决方案”。 首先在电梯盖板下面安装一个按压开关,当盖板安装好后,开关处于下压状态,电路导通,通过继电器,开电梯电源。 一旦盖板被打开,电梯立即停止供电。进一步延伸功能,当盖板被打开,停止电梯供电,同时触发警报。 怎么样?成本不足5元钱,安装两个零件彻底解决了安全问题, 在现有的电梯设备上改装,只需要几个小时就可以完成。 这种技术层面的解决方案,远比媒体/舆论期望的“管理层面解决方案”要好。 我们可以在很多方面作出技术改善,安装各种传感器,实现工作状态实时监控,故障报警,自动响应等等。

当下需要重点解决的是下面几点:

实时监控.  目前电梯都是每年巡检一次,使用过程中出现问题再找厂商上面维修。这样的检查是远远不够的,往往电梯出现问题,轻者将人困在其中,重者就会伤人。

例如我们可以采用很多传感器技术监控电梯:

  1. 电梯门安全,目前很多电梯又具备防止夹人的功能,老式通过限位开关的那种逐渐淘汰,新的基本采用光传感器,我遇到过几次故障,例如反复无法关门。 我认为可能做很多改进,例如反复关门超过3~5次就发出报警,停止电梯运行。
  2. 红外空间扫锚,当电梯停止运行(无人乘坐),扫描电梯室内热源,热源超过5分钟,发出警报。这种情况可能是小孩被困或者老人晕倒。

远程监控.  远程监控是指电梯传感器收集的数据,实时或定时发送到厂家,用作数据分析,归档备份

故障报警.  目前主要靠人来判断故障,然后决定是否需要通知厂商维修。 有了上面的监控数据,电梯出现故障厂家第一时间知道,并上门维修。 甚至厂家可以可通收集的监控数据,通过技术人员分析,决定是否远程遥闭电梯。

自动响应.  是电梯智能化的标志,电梯能根据预先设定的程序,对轻微故障,作出自动响应。如上面谈到的“电梯门安全”,“红外空间扫锚”。

电梯行业应该引入4S概念.  目前电梯市场十分混乱,我认为电梯行业应该引入4S概念。

  • 是一种集销售(Sale)
  • 零配件(Sparepart)
  • 售后服务(Service)
  • 信息反馈(Survey)

四位一体的销售企业,让电梯的销售,配件,售后保养,以及问题反馈流程化,标准化。