为什么不做开发做运维(开发转运维容易吗)

这是一篇命题作文，是应一位师兄的邀请写的。他告诉我，目前他和发展的关系有些僵持，希望我能发表一些意见。虽然我未必能给出好的建议，但我觉得这件事在一定程度上是具有普遍性的，所以我写了一篇有权利对玉抛砖引玉的文章。

众所周知，创建和运营一个网站或项目，绝不是一个人就能完成的(不算个人发挥)。至少需要产品、设计、程序开发(前端、后端)、测试、系统维护(部署、运营、维护)、平台运营等几个岗位。

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

在大多数非标准或技术驱动的公司中，典型的情况是：

对于系统运维人员来说，如果系统长期稳定运行，有人会想，运维是不是多余的？相反，如果经常出现故障，有些人又开始抱怨，那是什么操作和维护呢？为什么总是有问题？

出现这些问题的原因有很多，可能是认知问题，也可能是项目本身的问题(比如交易类网站的运营维护状况高于宣传类网站)。我个人建议，找工作的时候，尽量找交易型的。毕竟公司的存在是基于系统平台赚钱的，系统停止意味着亏损，所以个人在组织中的地位自然要比宣传网站高很多。至于认知问题，情况比较复杂，需要更多的分析和思考。

让我们回到我们的话题。任何程序员或测试人员都来要求做这做那。没有书面文件，也没有流程。如果这种情况发生得更频繁，大多数运维人员会感到被支配、不耐烦和厌倦应对。第二种情况是：出了问题，先推到运维。这真的是最致命的，也是最容易引起纠纷的。想必很多运维同行也有这样的经历。

抛出一些想法供大家参考。

倡议

搞技术的人比较内向。不知道是不是因为和机器打交道久了。但是，积极与他人沟通还是很重要的。

我们需要让别人知道运维其实是在做很多事情(选择机房、制作系统架构、技术选型、日常维护、半夜起床运行、24小时响应……请告诉我们，项目越详细越好！

有些事情对其他人(比如开发人员)来说似乎很简单，只需要放在服务器上安装一个系统。那我们就要跟他实话实说：哪个机房的带宽质量好？哪个机房服务到位了？如何更快更符合要求的安装系统(不要告诉我们一路回车，一路到底，所有的程序数据)？如果一定要说点什么，多说点，可以让别人知道，其实我们已经很努力了，做了很多工作。

要知道，设计的界面漂亮，程序牛逼，系统崩溃，不过是一堆二进制文件占用硬盘空间！

中国是一个人类社会，每个人都会时不时地在一起吃饭，很多事情都很容易讨论。你是打算邀请还是被邀请和其他部门的人出去吃饭？

坐标

把责任推给别人，原因很简单：——好处和面子！没有人愿意努力，但最后却因为失败扣钱，甚至影响未来(很多组织只注重惩罚，很少提及奖励)。

没有人能保证系统运行不会出现问题或故障。对于所有不可预测的问题，我通常的措施是：

1.收集相关资源的联系方式：机房、供应商、服务商(cdn等)；

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

3、根据业务，将故障报警发送给相关人员；

4.联系接口人员告知故障的发生，获取故障现象并简要描述。

5.要求相关人员配合调查；

6.告知自己调查情况(调查了哪些项目，数值是多少，修改了哪些，数据截图等。);

7.排除故障，总结经验；

8.内部讨论一下，看有没有可能有很大的不同(要看具体情况)。如果不是我们自己的错，如果过分强调过错或者疏忽，就会回到互相推卸责任的老路。

程序

没有这个过程，肯定会造成一片混乱。例如，正如bmdkl所说，任何个人都会来索要。流程太繁琐，行不通，会严重影响效率。这里不强调流程怎么做，但至少可以相互约定一个接口人，有需求的话尽量通过接口人。

如果什么都不能改变，尽快离开这里！

本文转载自微信官方账号：51CTO科技栈作者：彩色眼周水蜜桃

结束