但是今天，我们将特别关注开发者特有的东西以及作为开发者的可观察性如何[听不清]，对吧?
在我们开始之前，我想我最喜欢用飞机来比喻可观察性。
这是747的旧版本，像第一个版本，大概在60年代末，也许是70年代初。
我们看到的是很多不同的仪器，很多仪表，很多旋钮，很多信息要看，并试图理解发生了什么。
通常，当我们看到那个时间点上的飞机时，基本上是三个人在驾驶。
是飞行员，副驾驶，真正在飞行的人，然后第三个人会一直坐在后面，靠近拍摄照片的地方，看着所有不同的仪表和信息，试图从中找到意义。
据我所知，这个职位被称为飞行工程师。
我的意思是，如果你看一下要掌握的无限数量的信息，这对我来说当然是有意义的，对吧?
这真的很难。只有一个人负责，燃料够吗?
我们会比预期更快地失去燃油吗?
是(听不清)压力?
什么都对吗?他的职责是说，嘿，机长，副机长，副驾驶，大副，出了问题，我们需要解决。
所以，作为开发者，我想我们都知道同样的问题，对吧?
我是说，从外面飞行看起来很简单。
就像我们的服务一样。我们有API网关，我们有端点，我们有简单的服务，这些东西只是响应用户的需求。
但作为工程师，作为实施过更复杂系统的人，我们知道这不是真的，对吧?
看起来更像这样。
系统是相互连接的，呼叫服务相互呼叫，它们到相同的服务，获取订单、地址、联系方式，诸如此类。
现实总是有点复杂。这就像……
就像我说的，就像飞机一样，对吧?
飞行看起来很简单。
尤其是现在，我们马上就会看到但现实，至少是非常不同的。我是说，现在可能还是这样，
也许我们需要飞行员执照还是有很好的理由的，对吧?
不管怎样，我有什么资格说这个?
我叫克里斯。我是资深开发者的拥护者。
我们至少创建一个可观察性解。
我有一点偏见，我想说我们创造了最好的，但这取决于你。
我强烈建议你尝试一下。
我来自一个非常强大的工程背景，我有足够的经验
我只是在数到10之后就停止了，因为在某些时候，你会开始觉得自己老了……
这同样适用于所有不同的编程语言。
我喜欢学习新东西，我喜欢尝试新东西，但是仅仅列出所有的编程语言，会让你觉得很奇怪。
但还有一个重要的事实，对那些还不认识我的人来说，我是德国人。
作为一个德国人，至少我们大多数人，我们有一个具体的技术事实，这非常重要。
我们都喜欢啤酒，对我来说也是如此。
那么，我们从何而来，对吧?我的意思是，在过去，作为工程师，至少对我来说是这样，我讨厌看仪表板。
他们给了我很多不同的图表，给了我很多不同的信息但是当我遇到问题的时候，这肯定不是我想要的信息。
它是CPU调用，它是系统调用，它是分页信息，它是网络流量。
它可能给了我一些提示，但它从来没有真正帮助我解决问题。
我做了什么?嗯，我想和大多数工程师一样，我忽略了所有的监控。
就像，是的，这是可操作的东西但对我没有帮助，对吧?
它没有给我任何有用的信息。
所以作为工程师，我必须承认我…
我创造了一个公平的份额，我们把它与我们喜欢做的其他事情联系起来，因为它给了我们信息，那是大量的日志文件。
我想每个人都知道当操作来到你面前告诉你，哦，你必须真的，真的减少对数。磁盘空间快用完了。
但这意味着，它夺走了我们唯一真正有用的东西，至少在大多数时候，因为我们仍然需要弄清楚发生了什么，什么时候发生了。
我的意思是，如果你曾经试图搜索千兆字节的锁，这本身就是一场噩梦。
所以人们想出了这个新东西，他们称之为可观察性和DevOps，对吧?
可观测性的有趣之处在于，它实际上只是增加了更多的数据源。
所以现在我们不仅有日志文件和CPU指标，或者云指标，我们有性能信息，我们有联系人，我们有分布跟踪，我们有基础设施中正在发生的变化，我们有依赖关系，我们有这么多的东西，它变得越来越复杂，很难忽略，也很难找出真正有用的东西。
所以人们想，好吧，当我们有了所有这些信息，我们需要找到一种方法把它们联系起来，也许有什么东西能帮助我们。
所以人们开始编写或创建可观察性工具，Instana就是其中之一。
可观测性工具有点像现代飞机上的平板电脑，对吧?
它把飞机收集和计算的所有信息
试着从中找出意义，试着联系起来，或者，希望它不只是尝试，希望它以正确的方式联系起来，对吧?
这是现代的。
我认为这是最新的型号，至少是现代的747飞机只有两个人因为飞行工程师，至少现在已经不存在了。
它可能适用于更大的飞机，但不适用于典型的消费航空公司。
但是我们需要查看的所有不同的监控信息发生了什么，它们实际上变成了六个监视器，其中两个监视器用于驾驶员，两个监视器用于副驾驶员。
我认为，它们可能会显示相同的信息。
也许它们显示的信息取决于现在是谁在驾驶飞机。
然后中间的顶部屏幕会给你推力的信息，我认为是高度，巡航速度，诸如此类的信息。
然后是中间较低的屏幕它是一种奇怪的粉红色据我所知，我不是飞行工程师，对吧?据我所知，这种颜色一直保持不变，直到出了什么问题才会改变。
这意味着如果你总是看一下这个屏幕，它有颜色，一切都很好。
第二种颜色消失了，它显示了信息，你知道你想看它，你想弄清楚发生了什么。
这基本上就是可观测性工具给你的。
他们收集所有不同的数据源，所有的信息，把它们联系在一起，建立理解，然后帮助你。
尽管如此，大多数人认为它只能帮助运维人员，比如DevOps运维，it运维，不管你叫什么，但它实际上可以帮助我们作为开发人员。
作为开发者，我的意思是，我们的工作是什么?
掷骰子，然后创造一种方法，这个数字肯定是随机的。
显然，它不是。
我们工作的一部分和工程师角色的变化方式是人们所说的高性能工程。
这意味着优化工程过程，而可观察性在优化过程中起着重要作用。
所以我们作为工程师的商业价值，以及我们创造的商业价值，在我看来，有四个方面。这是开发频率。
开发频率意味着我们多久部署一次?
我们是一天部署一次，一个月部署一次，还是半年部署一次?
因为这直接影响到改变的前置时间。那么一个特性从最初的想法到实际部署需要多长时间呢?
另一件事是恢复的时间。如果出了问题，它不是可操作的，但它是我们构建的应用程序或我们构建的服务的一部分，修复它需要多长时间?
恢复需要多长时间?
第四个是变更失败率。
这很重要，因为基本上，我们可以非常快，无论是在部署上，在变更的准备时间上，还是在恢复的时间上但这意味着什么，如果每一秒钟甚至每一次发布都会引入某种错误或某种失败，对吧?
所以这四个指标基本上是创造商业价值的东西。
功能的时间，恢复的时间，以及非常低的错误率或故障率。
失败率，就像我说的，就我们在创造东西时失败的频率而言。
所以我们又回到了梦境的现实。
我们的梦想是，我们有一个用户服务，用户调用用户服务，我们可能有一些内部服务，照顾所有的数据库信息，当我们来的时候
返回后，我们进入一些外部CRM系统，丰富我们数据库中的用户信息，我不知道，比如最后的订单之类的。
但在现实中，这样的东西看起来很可怕，对吧?
你有很多依赖关系，很多服务，你可能有重复自己的服务。
在本例中，内部联系人服务和内部地址服务被调用了几次，因为我们返回的层次结构中的多个对象都有联系人和地址信息。
很明显，每个微服务本身都调用其他微服务。
所以我们创造了很多依赖关系。
依赖关系是随着微服务的蓬勃发展而产生的。
它们并不新鲜，我们有眼镜蛇，我们有肥皂，但有了微服务，这些东西基本上冲击了所有的工程部门。
在过去，它只像大公司一样。
今天，如果你想要创造一些东西，你想要扩展，你就会选择微服务。
这个信息图很酷的一点是，就像这个依赖关系图一样，我们可以从不同的角度来展示它。
我们可以用时序表或时序图来表示。
例如，何时调用子服务或依赖服务。
需要多长时间才能做出回应以及内部还拨打了哪些电话，对吧?
我说过，梦很简单。
从我们的角度来看，这是一个非常简单的事情你可能能够实现类似的东西但回头看，这个图表的这个图表，这是相同的调用或相同的请求流作为时序图。
作为工程师，我们首先要得到一些提示。
这很棒。
你看看来自外部的请求。
你看着它，就像，嗯，它花了900毫秒来响应。
我们看到这里是最后一个外部请求这里是第一个请求，间隔很长，如果间隔是900毫秒，那么这个间隔可能是450毫秒。
因此，作为工程师，我们的第一个意图是弄清楚，我们看到这个调用是什么，我们看到这个调用是什么，我们查看我们自己服务的源代码，然后想，为什么它需要450毫秒?
我的意思是，如果你能加快速度，你的客户的转化率就会提高，我不知道，40%
那可能是唾手可得的。
想象一下，如果你把响应时间减半，你就是一个英雄，而且转化率提高了40%。
或者只要20%，你就会成为公司的英雄。
还有一种方法可以展示它那是一种堆栈跟踪，树形图。
我们之前做过的调用可以用树形图来表示。
树形图的有趣之处在于它给了我们更多的信息。
它告诉我们这些召唤是如何被影响的，它们是如何被召唤的。
在Instana中，你可以点击任意一个点它会给出HTTP参数之类的信息，比如GRPC请求是什么?
正在执行的数据库语句是什么?
诸如此类。你真的不需要为此做任何事情，这些都是自动收集、整合和关联的。
Instana会给你所有这些信息。
所以很明显，我们不是唯一的，我们不是第一个意识到这种事情很难的人，对吧?
这个梦想和现实并不相符。我的意思是，有一些人已经发现了它，并把它形象化了，我不得不同意他们的观点。
作为工程师，我们工作的一部分就是要有一个前端，不仅是面向用户的前端，也是面向其他服务、其他部门的前端。
我们的工作是承担困难的部分，隐藏所有的复杂性。
但是作为工程师有一件非常糟糕的事情，那就是，凌晨3点我们躺在床上，我们睡得很香，睡得很好，我们真的不想醒来，但是发生了一些事情，你被召唤了。
那天晚上，有人打电话给你，你接电话，那个人告诉你发生了什么事。
他或她告诉你，你必须弄清楚它是如何工作的，哪里出了问题，并解决它，因为你随时待命。
好了，你开始看这些东西有一件事真的，真的会阻碍你快速弄清楚发生了什么。
这就是建筑的复杂性。
我们添加的东西越多，社区就越多，数据库就越多。微服务越多，我们添加的不同框架就越多，编程语言也是如此，我们得到的架构复杂性就越高，对吧?
我们需要在简单性和可伸缩性之间进行权衡。
我们仍然试着让它们稍微相交，但是我们它们只是越来越远离彼此。
但很酷的是，我们可以使用Instana作为一个随叫随到的开发者我们正在调查一些不是我们服务的东西，我们不知道发生了什么。
或者，不，我们换个更好的说法，对吧?
这是我们的服务，但我们发现不是我们的服务出了问题，对吧?
所以我们在凌晨3点看那个服务，我们还没有完全清醒，你只是想弄清楚发生了什么。
所以你要花40到50到60分钟才能弄清楚，这不是你的服务，而是你呼叫的服务。
所以你重新分配了票，然后打电话给下一个人说，嘿，对不起。我是随叫随到，我有这个问题，这是你们的服务，你能帮我解决吗?
所以你唤醒了第二个人，第二个人现在正在憎恨手术而第一个人正在憎恨你。
所以第二个人也没有完全清醒，对吧?
刚醒来，看了看他们的服务大概一个小时后发现，不是我的服务，而是他们的服务有问题所以现在我们工作了两个小时，我们打电话给第三个人他们都是独立的团队，对吧?
他们不知道对方在做什么。他们只需要调用API规范。
两小时后，第三个3分钟就算出来了。
这是两个半小时的固定时间。
现在，你必须在没有Instana的帮助下思考这个问题，对吧?
或者没有可观察性的帮助。
现在我们使用可观测性工具，如果我们打开它，我们就会得到罚单。
在最好的情况下，它甚至不会送到你那里因为负责运营的人已经知道了，哦，好吧，是的。
这是错误击中用户的地方但这是这个deck中的服务它实际上使所有请求失败。
在这种情况下，它只是缓存，对吧?
所以它甚至不应该失败。
就像我说的，在最好的情况下，它甚至不会送到你那里。
它会直接传递给另一个人，这可能只需要30分钟，而不是两个半小时。
人们称之为MTTGBTB，我喜欢这个词。
是时候回去睡觉了。
就像我说的，在最好的情况下，它是零，因为你甚至没有醒来。
这是什么意思呢?
我们有一个巨大的信息和依赖关系图
可观测性工具知道它们之间的关联，我们看到中间有一些黄色和红色的点，它们给了我们一些信息，有些地方出了问题，但没有人能理解。
有趣的是，我们可以把这些东西分开，然后说，好吧，请只告诉我什么对我的服务重要，对我的部门重要，我该叫什么?谁打电话给我?
如果我想放弃一个服务，真的有什么需要。或者我们可以放弃它，因为没有人再调用这个旧版本的服务了，对吧?
诸如此类。
从我的角度来看，这是行为驱动开发的直接延伸，每个人都知道单元测试是如何工作的，现在持续部署是如何工作的，但我们想做的是可观察性驱动的开发。
我们想把一些东西部署到准备阶段，开发阶段，或者你称之为这些环境的任何地方，我们必须有一个可观察性工具，试图理解，它的质量是一样的吗?
错误率高吗?响应时间是增加还是减少?
在最好的情况下，它会下降。
有什么问题吗?有新的依赖项还是最后的依赖项?
就像我说的，弄清楚是否有人在调用你想要放弃的旧版本的服务。
如果只有两三个人还在给你打电话，你可能想直接联系那些部门，说，嘿，你们真的想放弃这项服务。
像这样的东西，你通常不理解的东西。
所以，对于可观察性驱动的开发，我们需要的是快速反馈周期。
部署，想出办法，部署，想出办法。
我们需要健康指标，我们需要了解如果错误率更高，如果故障率更高，我们想要的东西是20年前，也许是10年前，我从未想过我会说我们需要功能切换。
部署，如果出现问题，告诉操作，嘿，这个新功能开关打开了如果那个服务行为不正常，在打电话给任何人之前先关掉这个开关。
然后得到所有额外的信息，比如分析，错误，堆栈，诸如此类的东西，得到所有好的东西，然后试着弄清楚发生了什么。
正如我所说，可观察性驱动开发，不幸的是，我们只有25到30分钟的时间，我们已经开始了。
有一本电子书，是我之前写的，“开发者的可观察性电子书”，去Instana.com/dev-observability下载，随意。
我很乐意在twitter、@NocturiasTK或稍后的聊天中谈论这些。
还有一件重要的事情。
当你从这次演讲中学到一件事时，不要试图自己去理解所有的事情。
利用我们现在拥有的工具，并确保你了解如何使用它们以及它们如何帮助你。
我知道作为工程师，我们讨厌仪表板，但也有工具不仅仅是度量标准。
这对我们很有帮助。
所以试着成为一个现代工程师去理解正在发生的事情。
所以，如果你有任何问题，我很乐意在Twitter @NocturiasTK上讨论，我很乐意在聊天中回答问题。
说到这里，我想感谢大家的聆听和欢呼。
