DevOps的缺点

现在到处都是DevOps。工具集正在爆炸式增长。公司提供各种各样的产品以满足顾客的需要。看谷歌趋势，关键字devops在过去两年中人气翻了一番。

作为一名敏捷教练，去年我一直在稳定地与DevOps团队合作，在那里我看到了作为DevOps的一些缺点。通过梳理其他博客文章，我和我的团队并没有发现太多关于两个缺点的内容。我想分享一下这段经历，让读者从另一个角度来看待DevOps。

DevOps对我们来说是什么?

这是一个很好的问题，取决于你读的内容。如果这个术语的创始人能在宣言中抓住他们的定义就好了(对敏捷眨眨眼)。在本文的其余部分，我们的DevOps团队将遵循“您构建它”的原则。你来经营吧。”他们支持自己编写的系统。他们负责代码的整个生命周期。一旦他们开始编写它，他们知道当它在生产中中断时，他们也会调试它。

开发人员疲劳

虽然知道成千上万的人在使用您的系统是一种令人兴奋的体验，但在半夜被叫醒处理系统故障就不那么令人兴奋了。虽然读者可能会说我们应该在我们的系统中建立更多的稳定性来避免这个问题，但对于我们这个蓬勃发展的初创公司来说，这不是一夜之间就能解决的问题，我们在过去的几个月里招聘了30多名新员工。开发人员也会像其他人一样犯错误，这些错误会导致生产中的bug。

与此同时，我们的DevOps团队必须共享呼叫轮换，并有一个备份，以防我们的第一反应团队成员遇到问题。我们曾让一些人在一个阳光明媚的周日早上出去骑自行车，却不得不回到他们的笔记本电脑前，因为他们必须调试在生产中失败的代码。在我们的面试过程中，甚至有候选人在介绍我们的团队作为DevOps时询问我们是如何处理呼叫轮换的。

用户疲劳

拥有一个持续的部署训练是非常棒的，它可以自动地在生产中推出新特性。每隔一个月就会看到客户反馈告诉我们他们已经厌倦了学习新功能，这并不是件好事。谁能想到呢!我们非常乐意推动新功能，自动化部署流程，以加快生产速度，而我们完全忘记了生产线末端的客户。

我把用户疲劳定义为客户跟不上新功能。特性的推出要非常频繁，以便用户发现并适应他们当前使用软件的方式。软件开发人员可能很难理解这一点，因为我们总是在它的要点。想想现场技术人员或客户服务代表，他们与软件有着不同的关系。他们的主要关注点并不是我们正在热情开发的软件，因此他们对新功能的兴趣程度不如我们在新功能构建后立即部署新功能的愿望那么高。

通过大量的Visual Studio Code (VS Code)发布，我亲身体验过这种用户疲劳。因为我有时会写一些代码，所以我可以每个月打开这个工具几次。在2017年初的前几个月，我很兴奋地收到一个指标，告诉我有一个新版本可用。我会阅读冗长的描述性自述文件，以发现该工具是如何改进的。两年后，我不再费心去看文件了。总有一大堆新功能。动图可以加快我的学习速度。但我太忙了，抽不出时间。

结论

虽然我不能忽视DevOps工具给我们的职业带来的巨大价值，但我想说，关于如何运营DevOps团队，有必要做出一个受过良好教育的决定。

在加入DevOps的潮流之前，我建议你的团队问自己以下问题来解决DevOps的一些缺点:

• 我们将如何应对在办公时间之外发生的生产系统故障?
• 我们为什么迟迟不承认这个系统故障?我们让我们的客户知道吗?
• 我们是否有一个程序来找到系统故障的根本原因，以避免问题在生产中再次发生?我们是否为这些事后分析设定了时间，迫使我们从系统故障中吸取教训?
• 我们是否拥有比其他用户更愿意参与频繁发布新功能的测试用户?