在大多数企业当中，开发人员仿佛都来自火星，而运维人员则来自金星。当然，也有些员工将这两个部门看作是吸血鬼和狼人。无论怎样比喻，开发团队与运维团队都有着自己的目标、数据指标和团队文化。除此之外，通常最大的问题在于运维人员希望一切工作都具备可预测性和固定性，相反开发人员则乐于改变。

所以这些有关于优先级的差异经常会引发摩擦，导致开发与运维团队难以顺畅的沟通。尽管很多企业一直在想办法使这两个团队团结在一起，但开发还是不停抱怨运维人员，运维人员也在疯狂吐槽开发人员。这种状况在传统企业中尤为普遍。不过，DevOps的出现取得了相当不错的进展，似乎有望弥合这一鸿沟。

相互抱怨显然无法化解紧张的气氛，但彼此理解却可以。对此分别向几位开发与运维进行了询问：

假设你是一位软件开发人员（或者运维人员），而且能够满足自己的一个愿望。你能够让运维团队（或者开发团队）理解目前正困扰着开发团队（或者运维团队）的一个问题，那么你会作何选择？

以下是他们给出的答案：   

§  相互尊重是非常必要的。

§  服务最终用户至关重要。

§  运维代码同样非常重要。

1、问题的实质在于相互尊重

我们必须时刻提醒自己运维与开发团队拥有不同的能力。他们相互补充，而非彼此对抗。因此即使大家厌烦了没完没了的会议，也应当借此机会好好进行交流（并不是坐着发呆...）。

只有开发与运维团队都充分理解了在生产环境下运行应用程序所必需的组成部分，并知道如何保证其安全性与正常运行，工作效率才能真正达到顶峰，一位开发者指出：“实现这项目标的最佳途径就是广开言路”。因此，运维团队中应该纳入开发成员，这可能需要做出一些调整与变通，因为某些企业可能要求不同团队间彼此独立，所以，组建一支小型团队充当“看守”的角色，由他们充当运维与开发部门之间的沟通桥梁是个可以尝试的方法。

缺少了定期沟通，开发者与运维者之间只会在出现问题时才有机会交流，而结果自然是引发一场决定错误归属的对喷。

2、终极目标在于服务用户

必须牢记，整个系统的作用在于服务用户，并不是服务于系统管理员。相当常见的一个状况就是，开发与运维团队忘记了自己的根本目标，那就是服务用户，”rackAID（Linux运维工作托管服务供应商）CEO Jeff Huckaby表示他们会因为停机问题、糟糕的网站性能、部署障碍或者其它种种问题而相互指责，而最终没有哪一方乐于承担责任。”

应当建立一种责任文化，同时利用客观制定的指标加以强制执行。与其相互指责应该要求相关负责团队保持良好的用户体验，这一点非常重要，一旦大家开始推卸责任的同事，用户也将因此流失。”

我曾听到过开发人员们抱怨运维团队总是把设备运行当成是唯一的要务。在情绪低落的开发者看来，运维人员们仿佛忘记了自己的核心职责，那即是创造并提供能够服务于用户的软件，并由此为企业带来收益，而对这些开发者来说，任何阻碍这一目标实现的因素都该千刀万剐——没错，任何因素。

开发者们可能意识到了运维团队的良好出发点通常是为了让系统更加稳定和安全，但他们基于此采取的具体实现方法让人颇为反感。更令人措手不及的是，这种流程甚至有可能影响到用户的正常体验。

作为一名开发者，软件开发有时候需要一定程度上的通融来实现更高的执行效率。但大多数情况下，那些规则（例如谁来访问、何时访问、可以安装哪些组件等等）会导致开发或支持的周期被严重推迟。

诚实的开发人员们经常抱怨说，他们发现某些障碍根本无法逾越。诚然，开发者们的工作可能会带来潜在风险，但如果运维人员不知情，那问题就解决了？还是更加危险呢？

最好的办法是将开发成员引入运维事务，如此一来，两个团队就能相互帮助,至少理解对方的优先级考量。

3、运维代码也是软件

颇为讽刺的是，开发者们还抱怨称运维团队总是把系统归为自己管辖范畴内的资产，但处理方式往往很马虎。

开发者与运维者都需要编写软件，他们也都很担心性能与稳定性问题甚至更为重要的安全问题。运维人员管理VPN或者编写脚本时，他们管理的是一套软件流程。但开发者有时候则需要某种超出运维团队控制能力的运行状态，像创建新流程以及变更测试。作为一名开发者，更希望编写出没有bug的代码，同时，他们也希望能够推出更多新功能。

运维人员在质量控制流程中所进行的变更，其实与开发人员的原始代码一样。如果没有被纳入开发团队的规划中，运维人员在最后关头做出的变更其实起不到什么实际效果。

相反的，情况甚至会更糟。一些系统管理员在未经测试的情况下对生产方案做出变更，极大程度上容易导致其发生崩溃。

总结以上观点，可以看到这两大团队其实真的应该彼此交流自己目前的工作内容以及规划方向。但这些还只是开发者与运维团队之间的一部分冲突缘由，也许哪天双方会真正视对方为知己好友，这谁又知道呢？（小午许编译）

在大多数企业当中，开发人员仿佛都来自火星，而运维人员则来自金星。当然，也有些员工将这两个部门看作是吸血鬼和狼人。无论怎样比喻，开发团队与运维团队都有着自己的目标、数据指标和团队文化。除此之外，通常最大的问题在于运维人员希望一切工作都具备可预测性和固定性，相反开发人员则乐于改变。

所以这些有关于优先级的差异经常会引发摩擦，导致开发与运维团队难以顺畅的沟通。尽管很多企业一直在想办法使这两个团队团结在一起，但开发还是不停抱怨运维人员，运维人员也在疯狂吐槽开发人员。这种状况在传统企业中尤为普遍。不过，DevOps的出现取得了相当不错的进展，似乎有望弥合这一鸿沟。

相互抱怨显然无法化解紧张的气氛，但彼此理解却可以。对此分别向几位开发与运维进行了询问：

假设你是一位软件开发人员（或者运维人员），而且能够满足自己的一个愿望。你能够让运维团队（或者开发团队）理解目前正困扰着开发团队（或者运维团队）的一个问题，那么你会作何选择？

以下是他们给出的答案：   

§  相互尊重是非常必要的。

§  服务最终用户至关重要。

§  运维代码同样非常重要。

1、问题的实质在于相互尊重

我们必须时刻提醒自己运维与开发团队拥有不同的能力。他们相互补充，而非彼此对抗。因此即使大家厌烦了没完没了的会议，也应当借此机会好好进行交流（并不是坐着发呆...）。

只有开发与运维团队都充分理解了在生产环境下运行应用程序所必需的组成部分，并知道如何保证其安全性与正常运行，工作效率才能真正达到顶峰，一位开发者指出：“实现这项目标的最佳途径就是广开言路”。因此，运维团队中应该纳入开发成员，这可能需要做出一些调整与变通，因为某些企业可能要求不同团队间彼此独立，所以，组建一支小型团队充当“看守”的角色，由他们充当运维与开发部门之间的沟通桥梁是个可以尝试的方法。

缺少了定期沟通，开发者与运维者之间只会在出现问题时才有机会交流，而结果自然是引发一场决定错误归属的对喷。

2、终极目标在于服务用户

必须牢记，整个系统的作用在于服务用户，并不是服务于系统管理员。相当常见的一个状况就是，开发与运维团队忘记了自己的根本目标，那就是服务用户，”rackAID（Linux运维工作托管服务供应商）CEO Jeff Huckaby表示他们会因为停机问题、糟糕的网站性能、部署障碍或者其它种种问题而相互指责，而最终没有哪一方乐于承担责任。”

应当建立一种责任文化，同时利用客观制定的指标加以强制执行。与其相互指责应该要求相关负责团队保持良好的用户体验，这一点非常重要，一旦大家开始推卸责任的同事，用户也将因此流失。”

我曾听到过开发人员们抱怨运维团队总是把设备运行当成是唯一的要务。在情绪低落的开发者看来，运维人员们仿佛忘记了自己的核心职责，那即是创造并提供能够服务于用户的软件，并由此为企业带来收益，而对这些开发者来说，任何阻碍这一目标实现的因素都该千刀万剐——没错，任何因素。

开发者们可能意识到了运维团队的良好出发点通常是为了让系统更加稳定和安全，但他们基于此采取的具体实现方法让人颇为反感。更令人措手不及的是，这种流程甚至有可能影响到用户的正常体验。

作为一名开发者，软件开发有时候需要一定程度上的通融来实现更高的执行效率。但大多数情况下，那些规则（例如谁来访问、何时访问、可以安装哪些组件等等）会导致开发或支持的周期被严重推迟。

诚实的开发人员们经常抱怨说，他们发现某些障碍根本无法逾越。诚然，开发者们的工作可能会带来潜在风险，但如果运维人员不知情，那问题就解决了？还是更加危险呢？

最好的办法是将开发成员引入运维事务，如此一来，两个团队就能相互帮助,至少理解对方的优先级考量。

3、运维代码也是软件

颇为讽刺的是，开发者们还抱怨称运维团队总是把系统归为自己管辖范畴内的资产，但处理方式往往很马虎。

开发者与运维者都需要编写软件，他们也都很担心性能与稳定性问题甚至更为重要的安全问题。运维人员管理VPN或者编写脚本时，他们管理的是一套软件流程。但开发者有时候则需要某种超出运维团队控制能力的运行状态，像创建新流程以及变更测试。作为一名开发者，更希望编写出没有bug的代码，同时，他们也希望能够推出更多新功能。

运维人员在质量控制流程中所进行的变更，其实与开发人员的原始代码一样。如果没有被纳入开发团队的规划中，运维人员在最后关头做出的变更其实起不到什么实际效果。

相反的，情况甚至会更糟。一些系统管理员在未经测试的情况下对生产方案做出变更，极大程度上容易导致其发生崩溃。

总结以上观点，可以看到这两大团队其实真的应该彼此交流自己目前的工作内容以及规划方向。但这些还只是开发者与运维团队之间的一部分冲突缘由，也许哪天双方会真正视对方为知己好友，这谁又知道呢？（小午许编译）