如何避免DevOps的常见问题

DevOps还未彻底发展成熟。如果用人的一生来比喻，那么DevOps还只是位少年——虽然早已脱离襁褓，但远没有长大成人。就在这时，历史性的挑战突然出现，要求其在COVID-19疫情的冲击之下，快速发展为加快软件开发工作的全面实施方案。

作为一名“少年”，DevOps在核心要素方面当然无需含糊——协作为王、自动化至上以及全面实现“持续”特性，包括持续集成、部署、测试以及改进。

而持续改进的一大重要组成部分，就是主动找出当前阻碍获得成功的错误，进而努力避免这些错误。纵观众多全球财富两千强企业，都能发现其中不少都在三大DevOps错误中折戟沉沙。下面来看如何有效避免。

开发人员负担过重

随着数字化转型在2021年成为全体CIO的首要工作，企业自然希望以创纪录的速度交付足以改变游戏规则的强大功能，借此迅速击败竞争对手。

这当然需要整个团队的共同努力，包括开发人员、产品负责人、测试人员、运营以及网站可靠性工程师（SRE）等。但是，每当有某些功能或方案未能及时交付，锅该由谁来背？几乎永远是开发者。另一个残酷的现实在于，绝大多数企业很难吸引到一流的开发人员，留住少数顶尖人才就成为一项长期而艰难的挑战。

总之，企业万万不可对开发人员予取予求。只有为开发者们留下充足的空间，他们才能承担起测试与安全保护等职责。

当然，质量保证与安全工作并不能只靠开发者的自觉，而应在项目之初就以制度性形式存在。要强调的是，千万不要让这样的工作流程进一步加大本就十分沉重的开发者负担。否则，顶尖开发人才很可能投入其他企业组织的怀抱。

用统一要求衡量每一位开发者

每个组织以及每位团队成员都可以通过正确的方式得到适当的培训与支持，进而为DevOps成功做出贡献。但是，不同成员做出贡献的方式也有所区别，不应统一要求。

任何行动、流程或技术的早期采用者，往往正是组织内最为耀眼的超级巨星、业务骨干。他们对自己的工作内容充满热情，关注领域内的各类新兴趋势，而且总有强大的内驱力在工作上做出种种尝试。无论是不断修改当前解决方案、还是寻找新的可行方法、再到为广泛社区做出贡献，他们始终参与其中。没错，这些都是非常重要的习惯，也必然会带来令人印象深刻的成果。

但千万别把这些当成普适性的评判标准。大多数应用交付人员并不是这么工作的，或者说并不一定具有这种冒险意识以及将新事物带入生活的原始冲动。他们投入了数年甚至数十年不断完善自己掌握的技巧，希望以最高效、最顺畅的“老办法”持续处理问题。

此外，不同的团队往往具有不同的技能、舒适区、优先级，而且很可能需要面对不同的应用栈与合规性/治理要求。具体来讲，初创团队往往更关注DevOps方法与工具集，而负责后端的团队则更多偏向传统SAP。非要以统一的要求衡量双方，只会徒增烦恼。

当然，DevOps本身也是一项需要全面规划的事务。

如果希望在整个企业之内加速创新，那么每位员工都应该在DevOps当中扮演自己的角色，包括坚持贯彻DevOps提出的核心理念、在工具集与实践方面提供其他员工友好型选项、在涉及不同系统及项目的各小组中引入可见性与治理层。

未充分了解整体用户体验

如今的用户对于功能往往抱有极高期望，但对问题的容忍度却极低。Forrester最近发现，单是在客户体验层面的改进也足以为企业带来巨大的利润影响。他们估计，客户体验系数每增加1点（0到100），年收入即可实现显著提升——汽车行业为11亿美元、零售行业为4.96亿美元，电信行业为3.88亿美元。反之，如果客户体验有所下降，也必定引发相应的收入损失。

当然，团队中的每位成员都希望打造并推出用户喜爱的软件。但是，不同的职能角色往往抱持着不同的观点、个人优势与短板。从规划、测试、发布再到监控，我们需要真正全面地了解业务，并通过每一位团队成员的参与有力捍卫整体用户体验。

不少DevOps团队目前仍在依靠底层技术，例如在单元测试中，来确定候选发布版本是否可以安全推出。遗憾的是，这样的测试往往只能发现编码错误，却无法保证卓越的产品体验。要达成体验改进的目标，需要做到如下三点：

第一，采取基于风险的测试，借此快速判断是否需要根据某些测试结果叫停项目发布。

第二，对事务进行端到端功能测试，例如从移动端到API、SAP与Salesforce等打包应用，乃至自定义应用程序与大型机等。

第三，通过负载/性能测试保证应用程序能够及时扩展并应对需求激增。

以上三大误区在任何组织内都很常见。毕竟DevOps还是少年，有时难免带来一些麻烦——但只要悉心陪伴它的成长，相信DevOps终将成为企业发展道路上的强大助力。
责任编辑人：ＣＣ