DevOps 实践的10个误区

译者: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/

原文发布于微信公众号 - DevOps时代(DevOpsTimes)

原文发表时间:2018-02-06

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏姬小光

前端工程师的核心价值 @2018

作为一个还算资深的前端工程师,我也时常在思考自身的价值到底在何处。网上每年都有许多关于前端工程师这个岗位的讨论,其之所以如此激烈,或因该岗位本身无法明确定义,故...

1423
来自专栏机器之心

演讲 | Youichiro Miyake:数字游戏世界中角色的觉醒与意识

机器之心原创 作者:Joni 编译参与:马亚雄、黄小天 2 月 16 日,星期四,我参加了在东京举办的第五届意识俱乐部 (consciousness club...

30413
来自专栏罗超频道

找社交要答案,搜狗能重构搜索吗?

移动互联网还在不断瓜分着互联网的流量,入口的碎片化使得搜索引擎受到很大冲击,搜索引擎都在尝试重构自己,寻找新的出路,执掌搜狗11年的王小川的思路是:接入独家内容...

4374
来自专栏架构之美

转转大数据平台从 0 到 1 演进与实践

1362
来自专栏BestSDK

从SDK到应用,一文读懂指纹识别的“前世今生”

在互联网发展初期,人们发现商业的边疆可以被极大的拓展,我们可以跟某个素不相识的人在一秒以内完成一笔真实交易。但是,更多的机会也带来了更多的风险。很多在人们看来理...

5306
来自专栏SDNLAB

混合云的四大典型应用案例

在云计算的早期,业界的专家们就对公有云和私有云的优缺点进行了大量的讨论,以帮助企业做出更好的选择。现在大多数企业不再是需要从公有云或者私有云中作出选择,企业现在...

5714
来自专栏携程技术中心

4月热招职位 | 开发/运维/测试/安全/产品/UED

1232
来自专栏DevOps时代的专栏

2018年 DevOps 最新现状研究报告解读

2018年度的 DevOps 最新研究现状姗姗来迟,但最终还是来了,让我们来看一下这份报告今年会给我们带来那些启示。

2683
来自专栏互联网数据官iCDO

大数据项目产品选型的五个建议

原创作者:曾勇,Elastic工程师。 数据如今对企业来说可谓是头等大事。使用欺诈检测来降低财务风险或是建设推荐系统来改善用户体验,都需要数据来为企业解决这些日...

2886
来自专栏携程技术中心

职位推荐 | 一大波技术岗来袭~

2044

扫码关注云+社区

领取腾讯云代金券