译者：suren，本文由 DevOps时代高翻院翻译发布。

（下面的列表是基于我们的 CTO Rob Zuber 和 Andrew Homeyer 在 Waffle.io 上十一月的研讨会“DevOps：实践误区”总结出来的）

1、你有一个“DevOps”团队

DevOps 旨在打破经常存在与研发和运维之间的“沟通障碍”，想象下这些团队之间紧密合作，并互相学习各自的实践经验。

所以，如果正确地实践了的话，DevOps 会被当作一种文化在整个团队中被接受，而不是某个团队在“承担 DevOps 任务”。

DevOps 真正的挑战是，如何让你的研发团队像运维一样思考问题，反之亦然。

2、不再尝试缩短你的发版周期

如果 DevOps 意味着快速、频繁迭代，那么多快才够呢？这确实要依据情况而定，向 DevOps 靠拢就是在逐渐地接近全面的持续研发模式。

如果你所在的企业，迭代周期是六个月，那么可能感觉八周就真的很快了。但如果你处在创业阶段，八周意味着你每次交付需要做的工作太多。

开始回顾一下每次发版时有多痛苦，而不是多久才能发一次版。

当某件事情完成后，你会部署吗？如果答案是否定的，那么怎么做才能移除这个障碍呢？你可以把大型的工程代码分成一些较小的吗？增加一些特性标签呢？

最终，部署将不再是什么大事。可能对于大型组织而言，八周可能就是他们的目标。让我们来看一些指标：当一个团队是每周发版一次时，他们更容易做到每晚发一次。

之后，开始看到部署可以做到每天20到30次。当到了这种程序，就开始做到真正的持续迭代了。

3、你把研发当作了成本中心

人员的成本很大，而研发人员的成本则是最大的。很多组织认为这是一种可控的成本，但这不是正确的思路。公司应该关注如何最大化研发的产出，而不是成本。

最好的办法，就是让研发去做他们感兴趣的事情。事实上，工程师加入你们的组织的原因，就是想要解决感兴趣的问题，也就是你们的业务问题。

因此，你最应该做的事情，就是排除一切会阻碍他们解决这些问题的事情。

最大的罪恶？就是低效率的工具。

当研发人员进行快速迭代时，如果能看到他们的成果对客户的影响。那么，他们就会对自己的代码更加有主人翁意识，并尽力提高质量。

给他们提供好用的工具，以及有很对反馈的环境，就可以最大化你在研发人员上的投资。

4、任何繁重的事情都亲自做而不作区分

对任何繁重的事情都亲自来做，而不进行区分，这样会占用你的很多时间，但这不一定是你的核心业务。

举一个极端的例子，当你想要给同事发送邮件时，可以选择开发出一个新的邮件程序，也可以注册Gmail。

同样地，你并不会由于工作时需要就自己去种植咖啡豆。当你在犹豫自建还是购买时，请思考“自己做这件事情对我们的客户产生直接的价值吗？由于是我们的商业机密而不能购买吗？如果其中任何一个答案是否定的，就可以考虑利用一个工具来做。

这些复杂的事情已经有人在他们的业务中完成了。所以，你应该站在巨人的肩膀上，关注自己的核心业务。

5、不做任何测试

DevOps 产生的背景是：团队合作更高效。

加快交付节奏的一种方法是，部署通过了自动化测试的新代码，会减少一些奇葩的因素。

当把手工测试中的部分验证工作转移为自动化测试时，需要一定的时间投入。当它会使得你在部署前的测试速度程指数加快。自动化测试能保证上次检查过的部分亦然是正确的，并即使码线已经发生变化亦然会令你感到安全。

6、做过多的测试

测试越多越好吗？可能吧，在 Andrew 的一个团队中，一套基于 Selenium 的自动化测试需要运行8个小时。这些测试包含一些不确定性，可能随机地发生失败。

像这样的测试能让你对部署很自信吗？可能不会吧。

思考”到底需要多少测试“，不如想一下”代码后并到 master 后怎么做才能让你感到放心“。有一套轻量级的测试，并关注在 核心业务价值上，会让你很放心地做部署。

7、事情没有轻重缓急，你总是被打断

紧急的事情处理最好能做到持续性。非紧急问题的持续性怎么办呢？不太好说。对实时沟通依赖的增加，会导致你需要回应每个消息。如果你有业务问题需要处理，最好能让团队中的每个人都了解。

合理安排时间很重要，根据情况来利用整块的时间。毕竟，持续模型的目标就是解救研发人员于水火之中。

8、合并代码占用了你的时间

如果代码合并总是需要占用很多时间，并需要很多人员协调，那么你实践 DevOps 的方法是有问题的。

过去，由于软件的混乱总是有不一致的地方，所以合并需要大量的工作。这是需要你控制的。

因此，你的代码和其他模块之间的关系越简单，出问题后就越容易定位。当你的增量越小，就更容易做合并或者从错误中恢复。

很多研发人员有过这样的经历，当做合并时所有的人都在 Stack 频道上。Stack 在紧急情况下很有帮助。如果你的紧急情况只是”合并“的话，Stack 不是最佳选择。

例如：比较一下基于主干（trunk）的或者持续集成方式的研发，找到一种当你和别人合作时最小化增量的方式。

9、部署吓跑了你

部署不应该是个难题。根据你的持续部署实践经验，如何保障部署是安全的？是的，可以借助测试，但也应该思考当发生故障时该怎么办。团队应该做到快速回滚。

你能做到在30秒内打一个补丁吗？对极了。通过演练这些方案，你可以在遇到紧急情况时提前采取行动。

10、研发人员不关心生产上的事情

DevOps 不仅时要缩短研发与运维之间的距离，还包括团队与客户之间的。

如何才能让研发更加关心生产活动？通过消除任何阻断在他们的代码与客户所见之间的责任。

换句话说，研发应该是自己的 QA。这是另一种缩短反馈回路而提高代码质量的方法。当研发就是代码到达客户之前的最后一道关卡时，他们能亲身感受到错误带来的 影响，并感觉是自己的错误。

他们为了对自己的代码更加放心不出问题，就会在部署之前做更多的工作，而不只是草草了事。写更好的测试代码成为了一种保障不出错 的方法。

让研发接近最终用户，并让他们亲身体验构建出来的价值，这样很有效。上午构建后下午就能在生产中看到效果的这种激动，也正是他们进入这个行业的初衷，这种简单的方法是使得研发人员能愉快并高产的关键。

无论你实践了多久的 DevOps 方法论，总会有值得改进的地方。更多的 DevOps 实践不仅有益于研发团队，而且对所有的组织都是有益的。

是的，DevOps 就是为了让研发看到他们自己工作的结果，并快速改进或者修复，从而实现快速迭代。

通过对研发工作的充分授权，不仅会创建一个愉快的研发团队，而且这样的团队也可以专注地带来一批满意的客户。这对于所有的组织来说都是一种成功。

原文链接：https://circleci.com/blog/10-ways-you-re-doing-devops-wrong/