什么是自动诊断，为什么要关心？
您如何衡量事件的成本？
许多技术人员的人仅从停机时间或受影响的客户和员工的数量来谈论事件的成本。从表面上，通常是一个相当角度的角度。它成为头条新闻，客户声誉和信任对于任何企业的成功至关重要。
但是，不经常承认的另一个直接成本是在事件中需要参与的人数。不管是为了帮助调查根本原因，对事件进行故障排除和解决，还是免除了他们的责任团队，没有任何事件是否足够严重以影响您的客户。
根据Pagerduty数据，50％的响应者的时间花在了确定谁最好进取以获得额外支持的时间（（并试图弄清楚是否真的有问题）在X环境中或使用Y服务。鉴于此统计数据，这意味着事件的寿命中有50％用于事件的起始阶段（诊断和分类阶段），而不是实际的补救措施。
底线？人数小时的成本和每次事件的手动动作数量可能会变得陡峭。
自动化事件响应
将自动化应用于事件的早期，反复出现的阶段，包括诊断事件的严重程度并了解发生了什么因素（以及如何）的基因组成，这对于最终对事件的补救的成功至关重要。
从人们的角度来看，自动化也很重要，可以确保您的团队每次事件开始时都不会被相同的重复行动所燃烧。确保诊断数据可用于第一响应者，这对于事件响应的路由效率和整体工作流程至关重要。
在进行进一步之前，让我们首先定义诊断数据。诊断数据是事件响应者检索的数据通常比监视工具提供的信息更具体。例如，尽管监视工具会在CPU或内存中有峰值时提醒您，但事件响应者通过查看最高的CPU和内存消耗过程来调查。因此，在这种情况下，过程名称或ID及其相关的计算消费是“诊断数据”。
因此，现在我们已经定义了自动诊断，你为什么要关心？因为实施自动诊断实践可以通过减少的事件持续时间和较少的响应者分页来降低事件的成本。
MTTR的问题
也许“问题”在这里是错误的词，但请听我说：MTTR作为度量太广泛，无法返回颗粒状，可操作的见解。几十年来，平均修复时间（MTTR）一直是IT宇宙中的主食可维护性度量。尽管它有许多应用程序，并且在阐明一般恢复速度方面做得很好，但其致命弱点就是那个基因。现在我们可以安全地推断出50％的响应者的时间花在了确定谁最能吸引更多支持的时间里，我们已经开始查看MTTR时间轴中的其他指标，例如MTTT（平均分类时间）或MTTI（平均进行调查时间）。
mtti/mttt：IT事件的检测与组织开始研究其原因和解决方案之间的平均时间。这表示MTTD（平均检测时间）与MTTR（平均修复时间）之间的时间。
在Pagerduty，我们将其衡量为您的第一响应者“ Acks”到分辨率“ Acks”之间的时间跨度。该指标可帮助我们点击事件期间实际发生的事情。在观察自己的数据之后，我们能够推断出MTTI是MTTR最耗时的因素之一。在现代业务中，当一项任务需要工程师的时间和关注时，该任务对业务来说是一项昂贵的任务。真的昂贵的。
使用自动诊断
现在，让我们回到MTTI和自动诊断。MTTI不仅通过手动提取诊断数据的响应者的技术任务来延长，并必须根据X服务和Y事件破译哪个团队升级为。这也是关于人民及其局限性的，具体取决于开始解决所需的具体专业知识。例如，在许多情况下，第一响应者不知道如何从数据库或网络“观点”调查问题。这可能是由于他们缺乏技能（数据库或网络的背景）；访问或部落知识（例如，特定的应用程序组件取决于与第三方服务的复杂集成）。
通过自动化这些调查和调试任务，除了能够跨团队和响应者委派这些行动外，您还将对MTTI以及MTTR产生积极的级联效应。
那么，为什么要关心自动诊断呢？
使用自动诊断，您可以：
- 减少通过设计途径来向稀缺的专家升级，以向第一响应者提供通常会手动收集的信息
- 分发跨回应团队的主题专业知识
- 调用防火墙和VPC背后的自动化
- 故障排除并在不需要人为辅助的行动的情况下更快地解决
- 提升向新工程师的启用速度，并确保事件响应组织的各个级别的最佳效率
入门
你做出了决定。现在是时候燃烧这条小径了，但是您从哪里开始？
要使用一些营销语：不要试图沸腾海洋。试用一些复杂性和风险较低的动作。This could be taking a deeper look at some of your noisiest services, or you could run some simple data pulls from various monitoring applications, disc usage, etc. But it’s important to have a strategy for the long-term roll out and vision of this functionality. Sure, you can write a script that pulls data from numerous sources and appends that to an incident. But that is far from scalable.
重要的是考虑一下您要从中获取诊断数据的各种基础架构和工具。您将需要一种标准化的方法来与您的异质和动态环境接口。
要了解有关自动诊断的更多信息，请查看我们的一些操作方法，我们将全年继续发布。此外，请注意杰克·科恩（Jake Cohen）在下周Pagerduty峰会呢
有关Pagerduty的流程自动化投资manbetx3.0组合的更多资源，访问此页面和与您的客户经理联系今天。
任何问题？随意问Twitter @Sordnam