新闻资讯

信息技术：运维跟开发一定有仇吗?开发能在多大程度上帮助运维减轻半夜被叫起的负担?

这是一篇命题作文：《运维跟开发一定有仇吗?开发能在多大程度上帮助运维减轻半夜被叫起的负担?》，是应一位同行兄弟的邀请而作此文。他告诉我，目前他所属的运维跟开发的关系有些僵持，希望能我能发表一些看法。尽管我不一定能给出好的建议，但我觉得这个事情应该具有一定的普遍性，于是就答应写一篇开发和运维的关系协调的文字，权作抛砖引玉。

总所周知，一个网站或者一个项目要创建、开发和运营，绝不是一个人可以完成的(个人玩玩那种不算)。至少需要产品、设计、程序开发(前端、后台)、测试、系统维护(部署、运营、维护)、平台运营等等若干职位。

在团队的认知中，某些职位的人总喜欢强势认为自己很重要，是处于主导地位的。于是在这些人的意识里，其它职位或人员都是辅助和次要的，是围绕着他的。在这样的环境里，造成人员冲突的几率就大，相互协作的意识就几乎不存在。如果项目最高领导(老板)也有这种认识，那么情况就更加糟糕。

我司我组的运维都看着挺辛苦的，经常半夜两三点起来处理故障问题，因为经常有致命告警。他们往往对某些实现上的细节不清楚，所以也很有可能把主导项目的开发leader叫起来，于是大家都在深更半夜不太清醒的状态下处理故障。从经常半夜两三点发生致命告警，到经常半夜两三点不太清醒的状态下处理故障，再到经常半夜两三点发生致命告警——胳膊要有胳膊的觉悟，你是扭不过大脑的。

不管哪种情况，作为小开发，该管的事是“提出问题”，而不是“怎么解决问题”。三更半夜运维接告警有几种：

1、硬件告警，如内存错误/Raid降级类，这种基本上通过冗余等方式解决

2、外企，服务对象是国外客户有时差，这个以前是叫应用运维，现在是叫SRE/DEVOPS解决，项目详细的抛错代码及对应解决方案wiki，监控是全流程的埋点，可以很快定位是哪里有压力或者瓶颈。至于打印堆栈/dump内存这种，看贵司花多少钱招来的运维吧，5000的运维肯定是干不了的；

3、晚上定时任务类的，大数据处理类的，这种基本放到凌晨跑，出了故障也比较常见，基本上运维可以解决。

在大部分不规范的或者不是以技术做驱动的公司里，一个比较典型的情况就是：对于系统运维人员，如果系统长期稳定运行，一些人就会认为，这些人是不是多余的?反之，如果故障频发，一些人有开始抱怨，运维是干啥的啊，怎么老出问题?

是不是说如果开发把功能做得完备些，特别是在上线前多测试演练，多在可能故障的地方埋点以帮助在意外情况下可以恢复到一个慢但准确的Plan B的执行路径上来，这样哪怕运维半夜被叫醒，也可以快速迁到plan B，不至于人为操作半天，毕竟运维不在清醒情况下更容易出问题。

所以总觉得运维如此辛苦，是因为开发在开发环节：

1)没有用心把系统做得故障冗余

2)没有重视上线前测试演练

3)没有配合和敦促运维一起做好面板监控和自动化处理(于是乎总要通过慢的命令行的人工操作)的结果。

....

这样的仅仅从一方找原因的分析结果让我联想到餐厅清洁工抱怨的故事。以前我听到过餐厅清洁工埋怨客人把地方弄得太脏，导致她们工作很辛苦。但是这里有个悖论：如果客人素质都非常高，不仅不会不小心把东西弄到地上，甚至多数人还会自觉收拾桌面，那么，结果就是餐厅会减少清洁工的数量。比如餐厅提倡客人自己收拾，他们就可以招聘更少的清洁工，降低成本。但这对清洁工来说是坏消息啊……

造成开发和运维矛盾问题的原因可能是多方面的，可能是认识问题，也可能是项目本身的问题(比如交易型网站运维的地位就要比宣传型网站运维的地位高)。目碰上半夜救火这种事情很多方面的因素都有，

  1.比如我程序极限承载能力是 10W 并发，集群承载能到 20W，但是客户拿去招投标就说 20W，结果实施方案计划并没有涉及集群部署这样，这是方案留下的隐患问题。当然也存在商业沟通的问题。

  2.比如程序设定的功能 A 很好但是 A 不符合用户实际使用需求，用户提了个 A+的功能，然后单纯的为了那个+去做定制开发，为了定制而定制，定制开发这种事容易出问题我就不多说了……我们后面可能发现 A+确实更贴合实际需求，但是下一个版本乃至大版本更新都没有把 A+纳入基线开发，还只推出 A 功能，就还会重复做 A+开发，怕研发兄弟们工作量不饱和吗?……这算是产品规划方面的问题

  3.在开发过程中吧，确实很多情况现场生产环境和开发环境不一样(成天听研发大兄弟和我诉苦)，尤其是一个产品分了很多模块，每个模块又特别细化到单个小组为单位进行开发，可能真就是自己测试自己的那些功能性能啥问题都没有，然后一到现场，这个接口不对，那个字段不对……内部沟通也有些问题

  4……一时间想不到了。不说了我去补觉了，三点多才睡。

  世界上没有完美的程序，也没有完美的产品，也没有完美的人。产品、研发、交付、运维、商务……都不容易。

对于我们个人来说，我建议找工作的时候，尽量找交易型的，毕竟公司的存在是以系统平台来赚钱，系统停止就意味着损失，因此个人在组织中的地位自然就比那种宣传型的网站高了不少。对于认识方面的问题，情况比较复杂，需要做更多的分析和考虑。 回到我们的主题上来。随便是一个程序员或者测试人员跑过来，就要求干这干那。没有书面需求文档，也没有一个测试反馈流程。这样次数多了，运维人员多半就会感觉被支配，不耐烦，疲于应付。第二种情况是：出现故障，先推给运维背锅。这个真的最要命，也最容易起纠纷。想必不少运维同行也有此遭遇。

尽管我很久没专注于技术，写这些文字也有些力不从心，勉为其难抛一些想法，供大伙参考。

▼主动配合

搞技术的人，性格内向的比较普遍，不知道是不是因为长时间跟机器打交道的原因。但不能怎样，主动与人沟通依然是很重要的工作。我们得告诉其它人，运维实际上在干很多事情(选机房、做系统架构、技术选型、日常维护、半夜爬起来跑机房、24小时响应…此处神略65535字)，要说出来，项目列得越详细越好!

有些事情在其它人看来(比如开发人员)似乎很简单，不就是上架服务器，安装个系统么?那么我们就要跟他较真：哪个机房带宽质量好?哪个机房服务到位?怎么装系统更快、更符合要求(不要给我们讲一路回车，一根到底、程序数据一锅端)?做了要说，而且要多说，才能让别人了解我们其实下了很多功夫，做了很多工作。我时不时会给其它人强调，你们设计的界面在美观、程序再怎么牛逼，系统崩溃了，仅仅是一堆占据硬盘空间的二进制而已!就算没崩溃，找的机房线路垃圾，能跑的起来才是怪事呢!

▼部门协作

中国人是一个人情社会，只有大家时不时一起吃个饭，很多事情就好商量了。你是否准备请或者被请，跟其它部门的人一起出去吃饭呢?

把责任推给别人，原因很简单—利益和面子!谁愿意努力付出了，最后却因为发生故障扣钱甚至影响前途呢(很多机构只注重处罚而很少提及奖励)?遇到人品差的，这种情况发生得就很频繁了。

没有人保证系统运行中不发生问题或故障，除非把电源给关闭掉。我经常的措施是：

1、收集相关资源的联系方式：机房、供货商、服务提供商(cdn之类的);

2、收集相关技术人员的联系方式：技术负责人、程序员、测试等等;

3、根据业务，故障报警发相关人员;

4、联系接口人员告知故障发生，获取故障现象并简单描述

5、要求相关人员协调排查;

6、告知自己排查的情况(查了哪些项目、数值是什么状况、修改了什么、数据截图等);

7、故障排除，总结经验;

8、内部讨论一下，看能否大事化小(小事化了要看具体情况)。如果不是己方的责任，过分强调过错或过失，又会回到相互推卸责任这个老路上来。

▼处置流程

没有流程，必定会引起一团糟，比如前边说的，随便是个人就跑过来提要求;流程太繁琐，也不行，会严重影响效率。在这里，不强调怎么做流程，但起码，我们可以相互约定一个接口人，有什么需求，尽量通过接口人。

如果什么都不能改变，尽快闪人吧!

作者：田逸 文章来自51cto