原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://sery.blog.51cto.com/10037/1614963

作者：田逸（sery@163.com）

按：这是一篇命题作文，是应一位同行兄弟的邀请而作此文。他告诉我，目前他跟开发的关系有些僵持，希望能我能发表一些看法。尽管我不一定能给出好的建议，但我觉得这个事情应该具有一定的普遍性，于是就答应写一篇文字，权作抛砖引玉。

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

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

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

造成这些问题的原因可能是多方面的，可能是认识问题，也可能是项目本身的问题（比如交易型网站运维的地位就要比宣传型网站运维的地位高）。对于我们个人来说，我建议找工作的时候，尽量找交易型的，毕竟公司的存在是以系统平台来赚钱，系统停止就意味着损失，因此个人在组织中的地位自然就比那种宣传型的网站高了不少。对于认识方面的问题，情况比较复杂，需要做更多的分析和考虑。

回到我们的主题上来。随便是一个程序员或者测试人员跑过来，就要求干这干那。没有书面文档，也没有一个流程。这样次数多了，运维人员多半就会感觉被支配，不耐烦，疲于应付。第二种情况是：出现故障，先推给运维。这个真的最要命，也最容易起纠纷。想必不少运维同行也有此遭遇。

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

◎主动

搞技术的人，性格内向的比较普遍，不知道是不是因为长时间跟机器打交道的原因。但不能怎样，主动与人沟通依然是很重要的工作。我们得告诉其它人，运维实际上在干很多事情（选机房、做系统架构、技术选型、日常维护、半夜爬起来跑机房、24小时响应…此处神略65535字），要说出来，项目列得越详细越好！有些事情在其它人看来（比如开发人员）似乎很简单，不就是上架服务器，安装个系统么？那么我们就要跟他较真：哪个机房带宽质量好？哪个机房服务到位？怎么装系统更快、更符合要求（不要给我们讲一路回车，一根到底、程序数据一锅端）？做了要说，而且要多说，才能让别人了解我们其实下了很多功夫，做了很多工作。我时不时会给其它人强调，你们设计的界面在美观、程序再怎么牛逼，系统崩溃了，仅仅是一堆占据硬盘空间的二进制而已！就算没崩溃，找的机房线路垃圾，能跑的起来才是怪事呢！

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

◎协作

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

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

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

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

（3）       根据业务，故障报警发相关人员；

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

（5）       要求相关人员协调排查；

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

（7）       故障排除，总结经验；

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

◎流程

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

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

2015-2-21 于大兴出租屋

本文出自 “sery” 博客，请务必保留此出处http://sery.blog.51cto.com/10037/1614963