Talk about the formulation of technical specifications
Almost all technology companies will pay attention to technical specifications, but the substantive role of these specifications is like "please maintain indoor hygiene, no clutter, and no spitting."
The author has worked for 15 years, which is a lot of experience in 15 years, and has also worked in different companies. Almost every company will encounter various specifications. With the development of my career, I finally became a specification maker. I have also presided over the formulation of development specifications, operation and maintenance specifications, testing specifications, and so on.
I have done a lot of specifications, and there are countless documents, but the technical staff will not read them at all. Through the meeting, it will be communicated downwards. The people in the meeting have no intention to pay attention to your specifications. The resistance to the implementation of the specifications is very large and the effect is poor.
Finally one day I realized the existence of the problem and began to reflect on whether companies need to formulate these norms. I found that it has a lot to do with the current environment, and it has a lot to do with corporate culture.
Some mandatory norms can be avoided through some technical means. There is no need for specification if it does not appear! http://netkiller.github.io/
story one
For example, in the following short story, a certain department of the company lost the code that will be developed for several months, so the test could not be carried out, and the leader was angry.
- Regular backup mechanism
- Code Comment Requirements
- Code access requires higher level approval
- Detailed deployment documentation and more
I think there are two main means of source code management, technical means and management means.
Let me first talk about management methods: For example, through rules and regulations, accountability and other means, employees are required to meet the normative standards, but usually the execution ability will be discounted, unable to meet expectations, and there are too many unstable factors of people. It is often too late to find that the employee does not operate in accordance with the norms, and the dismissal of the employee cannot restore the company's losses.
Just as the company's rules and regulations are clearly written, employees are required to submit code to the repository, but they are not implemented for various reasons. When the code is lost, the company will be held accountable from top to bottom, and the company's losses cannot be recovered.
所以我主张技术手段： 例如源码如果发布到线上，必须经过版本库，只能使用自动部署，不允许程序员私自将代码交给运维手工部署。另外发布代码的同事，可以不提供生产服务器登陆权限，他只能通过工具发布代码。 部署流程如下： 源码(程序员) 提交到development 分支UAT阶段 ----> 合并到 testing 分支Beta阶段（主管合并，程序员没有权限）------> master 分支(主管合并) -----> 自动部署系统(运维) ----> 生产服务器。 这样通过技术手段防止了代码因员工离职，硬盘损坏等等原因，导致代码丢失的可能。 代码发布者也无需对照部署文档，手动登陆服务器逐条按照部署说明书操作，防止了人员误操作，也提高了部署效率，节省了人力成本，通常在5分钟之内可以完成所有部署。http://netkiller.github.io/
故事二
我再来举另外一个例子，就是开发中的编码规范，很多软件企业都有是不是？
例如要求程序员： if (){} 要写成 if () { ... } 等等要求不一一列举，甚至组织代码评审解决编码规范问题。
我的建议为什么不在IDE上设置自动格式化，或者在svn/git提交的时候通过hook调用格式化程序。http://netkiller.github.io/
故事三
管理层要求运维每天发送服务器状态报告，运维人员需要登录每个服务器或者从cacti等工具中获得服务器运行状态数据，然后制作一个报告文档，每天给各位发送一次。
运维需要一个专职人员做这个报告，这种报告几乎没有人看，就像“人民日报” 人民从来不看。
当运维事故该出现的时候还是会出现，老板一个一个骂，扣工资，扣奖金，运维觉得委屈，公司受到损失。平日里的这些工作并不能避免运维事故，也不能改善运维工作。
故事四
在举一个例子，运维工作要求备份数据，A员工负责备份，B 员工负责检查A员工的备份，结果两年以后出事了，需要恢复数据，发现A没有备份，而B在一年前就再没有检查A的工作。起初前一年还是按流程备份，后来A发现B不再严格检查工作，备份工作逐渐减少，最后停止了备份，一直相安无事，直到事发。http://netkiller.github.io/
故事五
我曾经遇到过一个兢兢业业的管理者，他制定规范，要求值班的同事7*24小时，每间隔一定的时间做一次操作，验证系统正常运行，以便能够第一时间通知运维处理故障。值班的同事而偶偷懒，他就半夜起来监控他们工作。一个打工者能做到如此，真让人佩服。 但是我们有更好的方法，真的不必如此操劳且效率低下。
这些故事是一个无休止的死循环
出问题 -> 发上制定规范 -> 无人看/看了慢慢淡忘/石沉大海 -> 继续出问题。连续出现问题，采用行政手段处分，扣奖金等等。很多管理者将其归咎为 “执行力” 弱，我并不这么认为。
我觉得很多规范是形式主义。我一向主张实用主义。
通过技术手段可能避免很多没有意义规范，开发自动化，测试自动化，运维自动化，这是趋势也是我的努力的目标。http://netkiller.github.io/
上面仅仅举了几个例子，较片面，不能完全表达我的想法，需要更多的沟通，欢迎提出您的意见与建议。
http://netkiller.github.io/