老男孩想说：

1）请大佬们多给公司的运维人员一些思考、说话和决策的权利，他们一定是最棒的运维。

2）运维部门不光是技术服务部门，更是运维制度、规范及各种运维管理流程的制定部门。

3）多数情况，开发人员更多的是关注功能实现（项目周期紧所致），运维人员才会更关注规范、性能、和稳定（职责所在）。

在老男孩全职及兼职过的多家大中小型互联网企业中，发现很多公司的开发人员甚至是老大（可能不太懂技术细节）给你提运维工作需求，提需求很正常，这是我们运维人员的职责所在，但是他们还会关注实施部署细节，甚至是你操作每一步的细节，最悲催的是，每个操作步骤都给你规定死了！哇！这手伸的也太长了，到底开发负责运维还是运维人员负责运维啊？

发生以上问题的原因，老男孩总结了几条，可能不完全：

1）多数公司里开发人员是主导，从“小”形成的这个坏习惯，这和公司起步早期开发一并兼职运维有关。

2）公司规模较小，且大佬们是开发出身，根本不重视运维人员的素质和能力，甚至可能认为运维可有可无。

3）开发人员和大佬，不信任运维人员的能力，所以，老想过于细节的指导限制。

其实，对于一个合格（注意：合格二字）的运维工程师来说，在运维工作中最忌讳的就是完全听开发人员或者其他需求人的意见和思路，如果每次都是需求人划道，然后我们来走，我们会废掉的，大家想想，别人让你干啥你就干啥，你还能好么？(注意：这是提了需求后，还要求你按他们的具体思路完成工作的意思)

最主要的我们才是专业运维，我们要对自己部署的服务业务负责，听别人的思路，操作出了问题还是我们的责任啊（和别人无关），参考别人思路是对的，但是，自己要有主见（前提是优秀的思路，这里的意思是不能盲从，请注意“盲”字）。以前听过运维人员和开发和老大抱怨，“都是你们让我做的，又不是我自己做的，和我无关。大家听听可笑不？”

   在这里老男孩再次郑重呼吁：

1）作为公司的大佬们，应该充分给你的运维人员更多思考的能力以及发挥的空间，毕竟他才是专业运维，否则，你请他来还有什么意义，如果实在不信任他们，可以让他们出详细方案然后召集大家讨论PK。

下面的博文地址是老男孩在几年前作为运维经理时亲自和各个部门PK的经历，至今难忘：http://oldboy.blog.51cto.com/2561410/1059344

2）应禁止开发人员及其他需求人提出需求后，还要附加对超出自己职责的需求运维工作细节指手画脚，只要运维人员能满足需求人的具体需求，解决实际问题就好，实现过程的权利交由运维吧。一个专业的运维人员的对于运维工作的思维在多数情况下比相当能力的开发人员更加准确，专业。

3）对于一些大的架构该着和新项目上线，可以召集所有人包括开发人员一起开会讨论确定方案，按计划实施（运维操作）。当然了， 如果上线前期能够多找运维、架构、DBA等把把脉效果就更好了。注：有的公司运维、架构、DBA还没有分开，那就通属于运维部门了。

    给个荒唐但是可以说明问题的范例吧！

需求：让运维人员去机房装系统

开发经理或老大可能会说，呆着拿centos 6.3的CD盘下班后20:00点出发做001次公交车，然后,下车后不准打车，必须步行到机房。

以上内容，也许很夸张，但是说明了被人规定路线及细节去操作的悲催问题，今天一个老男孩的学生问了一个这样运维人员思想和能力被开发绑架的问题，因此，有了本博文。

另：如果确实是大公司，有了完备的运维方案形成的规范和流程，并形成了自动化运维体系，运维人员直接选择选项按回车，那是另外要讨论的问题，本文更多的还是针对中小公司的不正常、不规范的对待运维人员的情形和大家分享下老男孩的个人运维见解。

声明：本文仅就事论事，不针对任何个人和公司（包括老男孩全职和兼职的多家公司）。如有不妥敬请原谅。在留个记号供大家探讨。

后记：有关开发和运维之间纠结的故事，大家可以在下面评论共同交流探讨。