开发人员如何重新编码？

如果您查看其他组织，那么为什么开发人员会花很多时间在其他事情上？因为，当您开始与必须进行手动监视的开发人员交谈时，他们可能不需要很多额外的工作。他们引入了另一个必须学习的库，然后花时间弄清楚它是如何工作的。然后，他们还必须尝试找出将数据发送到哪里。然后弄清楚，“我如何访问数据？我也只访问开发中或生产后期的数据吗？”

使用Dynatrace，这些都是您不再需要解决的所有事情，因为这是开箱即用的。没有手动代码检测，数据会自动发送到Dynatrace，会自动进行分析，然后我们对该数据了解很多。我们知道这些数据来自何处。我们知道它来自Blake，因为他在下午两点通过Jenkins将此构建部署到了这个环境中，然后又部署到了这个环境中。让我比较这两个版本。然后让我向布雷克发送一条带有结果的Slack消息。现在情况已得到解决。

从您的角度来看，云工具如何使开发人员的生活更轻松？我越来越多地听到有关开发人员将更多时间花在与编码无关的任务上或将大量时间花在手动监视上的故事。

我们正在朝着实现自主云的方向发展，这意味着我们的ACE团队正在提供平台中的所有工具，从而减轻了开发人员的所有痛苦，并将其作为自助服务提供给他们。

因此，这意味着如果开发人员在他们想要部署的工件中，他们想要获得反馈，他们基本上只是说：“这是我的工件将其放入容器注册表中。” 然后将其拿起，并通过我称之为专心的管道进行部署，以我们采用它的方式，部署它并运行有意义的测试的方式来讨论，这意味着我们知道要更改的代码，并且仅运行有意义的测试。

接下来，我们正在研究KPI，因此我们正在研究SLI（服务水平指标）和SLO（服务水平目标）验证。因此，我们弄清楚了这段代码的性能，与以前的版本相比性能如何以及与之前的版本相比。然后，我们通过Slack将这些纠正性反馈提供给开发人员。如果有明确的问题，我们将自动打开JIRA门票。基本上，在故障单中，为他们提供了所需的所有数据，因为所有数据都在我们自动监控的地方。

在内部，我们在Dynatrace上使用Dynatrace，因此实质上，我们希望用户使用Dynatrace时使用Dynatrace。这意味着要对开发，质量检查，暂存和生产进行仪器检测。不仅将其用于监视，而且还用于生产工作负载以及在我们的生产前测试中应用该工作负载。因为如果您运行测试，则要运行尽可能接近生产的测试。这些是我们可以做的。

我们可以将数据作为自助服务提供。因此，我总是说我们有很多很棒的数据，但是最重要的是，如果我们能够在正确的时间以他们选择的工具将正确的数据提供给正确的人，以便他们做出下一个正确的决定。我们可以通过Slack提供数据。我们可以创建JIRA门票。我们可以将其推送到他们的IDE中。我们可以为开发人员做很多事情。

我们要做的是通过自助服务，在他们愿意使用的工具中为他们提供所需的数据。这对他们有很大帮助，因为他们不必学习其他工具。他们不必配置任何额外的东西。这不是他们需要做的额外步骤。数据就在那里。大多数情况是完全自动发生的，例如监视。此外，代码分析和性能特征会自动发生。

继续我的故事，当我说开发人员将某些东西上传到注册表中并进行部署时，如果效果很好，它会自动升级到下一阶段，我们可能会进行更多性能测试，然后开发者反馈，“嘿，这是可靠且出色的代码。” 因此，如果您愿意，我们可以投入生产。只需单击即可。“好吧，让我们把它推出。您是想将它发布给所有人，还是想先将它发布给一个小的测试小组，以获得一些反馈？”

在过去，如果幸运的话，部署可能每月一次进行，现在您可以听到 Citrix的Nestor A. Zapata这样的用户的故事， 他们每天可以使用Dynatrace进行多次部署。

究竟！之所以花费这么长时间，是因为当我们开始进行DevOps转型时，这对于我们的组织也是如此。我们首先在核心Dynatrace软件平台上进行了此操作，但是我们还有许多其他团队正在构建其他软件。他们都建立了自己的资料和管道。他们都想出了如何进行连续交付的方式，并且都花了很多时间来确保这些工具正常工作，这没有意义，因为像您一样，这些开发人员表示他们希望构建真正的新功能，而不是处理管线还活着。

因此，当我们说我们需要提供围绕Dynatrace构建的平台时。当我们提供Dynatrace软件平台时，我们需要为所有其他开发团队做同样的事情。因此，我们需要为他们提供一个平台，使他们变得非常自治，可以在我们的云平台上交付软件。一切都必须是自助服务，以便他们实际上可以专注于提供新功能和新价值。

许多IT经理都在努力摆脱技术债务。他们还试图最大程度地减少停机时间，并减少追踪问题的时间。云工具在这方面提供了即时帮助。

我们还通过Keptn解决了一个客户问题。多亏詹金斯（Jenkins），它才出现在大约10至15年前，并且彻底改变了CI，许多人还把它用于CD。我在与Jenkins合作的公司中看到的是，他们开始于某些项目，建立了管道，并且为他们工作。然后，接下来的事情发生了，他们复制了该管道，并根据需要对其进行了修改。然后，接下来的事情发生了，他们复制了该管道并根据需要对其进行了修改。因此，您最终得到10到15到100多个不同的管道，每个人都必须单独维护它。

在这些管道中，这是基本的。这是逻辑定律。这是您必须继续工作的所有编码。这也是消磨开发人员编写代码热情的一部分时间。这是我们使用Keptn解决的问题：不再有管道代码。一切都是声明性的。这意味着您不必处理要在脚本中定义的脚本，您要在哪个阶段执行该脚本，为哪个工具执行哪个工作，以及对输出做什么。Keptn是事件驱动的。它有一种自发的方法，可以通过部署，测试，评估和升级，通过管道中的意见来提升工件。它使开发人员可以抽出时间去做他们真正喜欢的事情。您将如何描述NoOps？

NoOps是一种心态。这就是我们所做的一切。在我们所做的每一件事中，我们都在考虑可能会出问题的地方，以及如何通过自动化避免这种情况的发生。那么我的代码更改或生产中的配置更改可能会出什么问题，这些错误通常会导致Ops中的某人修复某些问题？我如何一开始就避免这种情况？如何构建更多测试来阻止错误的代码更改？如何建立自动化的自我修复功能以自动回滚而不是让某人做某事？

所以NoOps是一种心态。这个想法是，作为开发人员，我只需要考虑以下几点。如何在系统中建立弹性？关键指标是否可以告诉我我是否健康？然后根据这些指标，确定下一步该做什么。我要放大还是缩小或回滚？最后，这意味着我要减少传统的运营工作量。这就是为什么NoOps是一种心态。

仍然有很多人负责基础架构和操作，但是由于自动化，我们使大多数事情实现了自动化，从而使问题永远不会在生产中结束，因为我们在流程的早期就停止了不良代码更改。如果有问题要解决，我们希望尽可能自动地修复这些问题。

最后，我认为Thomas Reisenbichler很好地说明了NoOps是一种心态，这意味着组织中的每个人都必须考虑我现在正在采取的措施可能会出什么问题以及如何使它的修复自动化？

对于那些不熟悉零客户的人，您将如何形容？是心态吗？

不，客户零意味着我们是我们自己的客户。我们在Dynatrace之前先使用Dynatrace。因此，我们正在使用最新版本来监视我们的所有环境，然后再将其发布给客户。这就是为什么我们零客户。我们是内部第一批使用最新版本，最新功能的公司，并且向产品团队提供反馈。

正如Thomas Reisenbichler昨天说的那样，Dynatrace ACE团队启发并要求了我们现在在Dynatrace平台中看到的许多功能。我们正在交付管道中使用Dynatrace，就像我们希望客户使用它一样，但是此功能不能很好地完成其工作，“我们需要这个和这个。”

几年前，他们说我们需要产品中的日志分析。昨天我们在谈论堆转储功能。这些都是零客户所经历的所有事情。我们想使用我们的产品，然后再使用第一个客户。这就是为什么它是零顾客。

太好了，在其他许多公司中，我也看不到使用这种方法！

显然，我们很幸运，该产品Dynatrace是解决了开发过程中许多问题的产品。

我想这取决于您作为组织提供的产品类型以及如何尽早使用该产品。我敢肯定，大多数公司正在开发的软件是可以在将其展示给客户之前尝试在内部使用的软件。

从趋势和未来的角度来看，在未来的道路上，有哪些事情可以激发您使开发人员的生活更加轻松？

如果您还记得昨天在谈论图片故事时的类比。我认为我们需要做出的类比是，我们需要像拍摄照片一样简单，通过增强图像的应用程序运行它，然后进行部署并获得反馈。交付软件必须变得非常简单。编写一些代码，然后通过管道运行它，使我可以警惕不良代码，然后就如何使其变得更好提出建议。然后自动将其交付给我的用户，他们给了我反馈。

它必须像在Instagram上发布内容一样简单。我认为这是我未来五年的目标。

因此，软件的抽象层仍然必须保留一种简单的心态吗？

是的，我们都知道世界上缺少开发人员。因此，这意味着为了使我们能够加入更多的开发人员，我认为我们还需要使其变得更容易。您不能像我们一样训练对所有事情都有很深知识的软件架构师。我们还需要考虑如何为没有软件工程背景的新手提供帮助，以便他们能够轻松开发自助软件或以不费力的自助服务方式交付价值，而又不会让他们搞砸一切。因此，它需要简单易行，但必须具有故障保护功能。

相关文章