DevOps Pulse是logz.io对DevOps行业的年度分析报告。2019年版的研究结果刚刚发表，我们借此机会与洛格茨的托梅尔·列维(Tomer Levy)分享和评论。io CEO。利维共同logz。io在2014年成功筹集了约1亿美元，并组建了一个250人的团队，前提是为日志管理提供一个基于开源的解决方案。
2019年的调查聚焦于可观察性，让DevOps工程师深入了解什么是系统可观察，如何实现可观察性，以及可观察性如何有助于最大化产品性能。它很有可能让我们窥见本世纪20年代软件开发的未来。首先，软件开发与操作相结合，产生了DevOps。然后DevOps变成了数据驱动。接下来是什么?
Logz。io新闻稿强调了可观察性的日益流行，它在DevOps过程中扮演的战略角色，以及阻碍团队实现其系统的完全可观察性的挑战。大约有1000人参加了这项调查，其中大多数人都不是logz。io客户，它应该合理地接近行业代表。
激起我们兴趣的是参与调查的人们(自我认同的)角色的多样性。从经理和主管到开发人员、DevOps工程师和系统管理员。上次我们检查时，这些角色之间的界限和责任划分似乎不是很清楚。看起来还是这样。
随着DevOps成为主流，研发团队承担着跨多个角色的可观察性责任。DevOps团队仍然在很大程度上负责确保可观察性，但是开发人员和操作人员也不落后。至少logz是这样的。io新闻发布会上说。我们的经历有点不同。
DevOps Pulse是对DevOps行业的年度分析，由logz.io进行。
我们没有注意到，在许多组织中实际上有不同的、不重叠的(在人员方面)DevOps、开发人员和操作团队。通常情况下，当人们说DevOps时，他们实际上指的是实践，而不是团队，因为在许多组织中并不存在专门的DevOps团队。利维澄清说，他们让受访者以他们想要的任何方式来描述他们的角色:
“许多受访者称他们的角色为‘DevOps’，尽管我们知道对于许多公司来说，DevOps意味着一种方法。但是除此之外，经常有一个团队被分配去“拥有”它。是的，根据我们的经验，DevOps/SREs/Platform团队通常是可观察性系统的主要所有者，因为他们管理这些系统并建立指导方针。
开发特性和功能的各种工程团队通常使用它们来实现对其微服务/应用程序的可见性，但并不拥有整个可用性kpi。
运营团队传统上更倾向于“系统管理”，通常是IT的一部分(并不总是)。因此，随着体系结构使用Terraform等工具和SREs等实践变得更加程序化，对手动操作的需求可能会减少。这也引起了工程和IT之间的冲突。如果操作通常是IT的一部分，而SREs/DevOps是工程的一部分。这增加了实践DevOps的开发人员的中心地位。”
但是不管是谁做的，今天在DevOps中到底发生了什么呢?随着生产环境变得更加分布式和短暂，工程团队越来越难以理解系统的可用性和性能。Logz指出，尽管监控工具不断增加，但获得对生产系统的实时可见性从未像现在这样具有挑战性。我是Asaf公司的产品副总裁。以下是报告中支持这一观点的一些要点:
我们认为上述发现并不令人惊讶。它们证实了我们直觉上的期望，以及我们在这个领域看到的东西。这同样适用于另一个关键发现——开源解决方案的主导地位。在可观察性方面，就像在数据库方面一样，开源正在赢得巨大的成功。开源的可观测性栈比私有栈更受欢迎。ELK是最流行的测井工具，Grafana是最流行的度量工具，Jaeger是最流行的分布式跟踪工具。
这似乎是对当今景观的一种非常准确的描述。明天呢?机器学习和云计算是21世纪20年代最重要的两个趋势，是的，你猜对了，它们也在可观察性上留下了印记。
作为一种可观察的解决方案，机器学习正在获得动力。几乎40%的DevOps脉冲参与者使用或正在考虑机器学习解决方案来提高可观测性。这个想法并不新鲜;至少在过去的两三年中，我们已经看到独立供应商在生产中使用它。
DevOps是随着软件开发而发展的。云、机器学习和开源，所有这些都与DevOps相交叉
世界上的谷歌、微软和亚马逊已经这样做了很长时间。但是40%的主流用户是一个确定的信号:它不再只是云巨头和早期采用者——机器学习也正在接管DevOps。
我们说的是云。那么，应用程序整体迁移到云中的新现实对DevOps和可观察性意味着什么呢?这意味着麻烦。让我们选择无服务器架构，它是世界各地开发团队的新玩具，也是云供应商正在积极推广的。Serverless并没有真正消除对服务器的需求，但是它混淆了这一点。这就是问题所在，对于可观测性和超越。
是的，服务器是令人讨厌的野兽，难以配置、启动、管理和监视。大多数开发人员会很高兴，如果他们不再需要处理他们;如果他们能写他们的代码，并看到它的化身和执行无中生有，他们所关心的。Serverless正是这样做的。
但是，通过去掉服务器的概念，并将代码转换为自由浮动函数的松散集合，Serverless还带走了结构和可观察性。无服务器是可观察性的最大技术障碍。尽管有超过40%的受访者采用无服务器技术，但47%的受访者表示，无服务器技术是获得可观测性的最大挑战。Levy表示赞同:
“是的，我们同意serverless使得获取可见性具有挑战性，尽管我们对其重要性感到惊讶。我们估计，serverless之所以困难的主要原因是它的高度分布式。如果你考虑微服务，你可能有20个，50个，甚至200个。如果没有服务器，你可能会有数百种不同的功能，这让连接点变得更加困难。”
那么DevOps人员应该怎么做呢?也许他们不应该使用不支持观察性的技术?再一次，它是开源的。开源是解决这些问题的理想方案，Levy说:
当依赖于开源的连接器、解析器和仪表盘时，开发者社区可以为每一个新的AWS服务快速定制可观察性。例如，如果AWS在过去几个月里只发布了约200项新服务和功能，那么没有任何一个供应商能够如此迅速地适应这种情况。因此，如果我是一名开发人员，并且希望在生产环境中使用新的AWS服务，那么理想的做法是简单地创建Grafana和Kibana仪表板，以便获得对这些服务的可见性。
在Logz。我们已经构建了许多这样的开源连接器，并集成了许多用户构建的解析器，以便更容易地观察新的服务。此外，我们的ELK应用程序使我们的用户能够从广泛的用户社区贡献和下载仪表板。”
再一次，我们不得不注意到云供应商和开源之间的关系。AWS提倡无服务器，导致了可观察性方面的问题。然后社区介入来解决这些问题。当然，如果社区不这样做，AWS很可能会向用户收取这些连接器和解析器的费用。
鉴于AWS的产品开发理念和运输松散连接产品的过往记录，这些问题很有可能一时解决不了。因此，现在的情况是，社区不再等待AWS来做这件事，而是免费做这件事，而包括AWS在内的其他所有人都将受益。
我们真的不知道社区是否更快乐。我们所知道的是，这对于AWS来说是一个非常方便的商业模式。在DevOps中，AWS也在发号施令，这并不奇怪。这是一个AWS的世界，我们只是生活在其中。
