灾难发生后：如何从历史事件管理数据中学习
毫无疑问，您的高中历史老师对乔治·桑塔亚纳（George Santayana）的著名说法有所变化，”那些不记得过去的人被谴责重复。“
我敢肯定，桑塔亚娜（Santayana）写这句话时没有考虑事件管理。但是他的智慧仍然适用 - 如果您负责事件管理，那么值得关注。
的确，事件管理的主要目的是识别和解决问题这会影响您的基础架构，但是您的事件管理操作不应止步于此。您还应该利用警报系统生成的丰富数据来主动检测和防止问题的大量数据，而不是仅仅对客户票做出反应，以便您可以获得洞察力，以帮助您使基础架构更具弹性。
在这篇文章中，我将概述一些处理历史事件管理数据的策略，包括如何收集和分析数据以及在使用此信息时寻找什么。
保存并标准化数据
分析历史事件管理数据的第一步是找到一种标准化的方法来收集和解析信息。这可能是具有挑战性的，因为历史日志数据的数量和格式之间的变化很大不同的监视系统。
某些监视系统在事实之后可以检查的记录数据中根本没有提供太多。例如，pingdom是实时监控的绝佳工具，但是由于它旨在告诉您现在发生了什么，而不是昨天发生的事情，因此它不会单独提供太多的历史数据。
其他监视系统将数据保存在有限的时间内或以难以使用的格式存储。例如，要分析SNORT数据，您可能需要筛选数据包转储。除非Wireshark是您最喜欢度过星期五晚上的方式，否则这是很多工作。
此外，如果您有很多监视系统，它们可能会将数据转移到许多分散的位置。一些工具将日志写入 /var /log在本地计算机上，在那里很难找到它们，并且可以通过维护脚本删除。其他人则将日志在云中保持不同的时间 - 如果您想一次分析所有历史数据，则不理想。
由于这些原因，为了充分利用事件管理数据，您应该确保做两件事：
- 将警报和日志发送到中央收集点，只要您需要它们，就可以存储它们（只要原始监视系统或本地存储将支持它们）。
- 将数据在您的收集点转换为标准格式，并提取可重新投资到基础架构的可行见解和外卖（带有类似的过程事件验尸事件）。
类似的工具logstash，，，，Splunk和造纸在这里可能会有所帮助。他们有助于从孤立的位置收集数据，并将其引导到中央存储点。
Pagerduty通过允许您从这些和其他来源导入数据，将其转换为标准化格式，并集中和交叉相关的数据与绘制模式和趋势的可视化数据，并且可以利用以识别根本原因等。
查看并分析您的数据
保存数据只是战斗的一半。另一个挑战是如何查看和分析它。
在大多数情况下，查看数据的最简单方法是通过基于Web的接口。理想情况下，它将采用复杂的搜索，您可以使用该搜索来从日志中查找特定事件，监视事件的当前状态，等等。这就是为什么能够过滤和搜索在您的整个基础架构中，正常化的字段非常有帮助。
虽然网络界面可能很适合查找小规模趋势或追踪特定类型的事件的历史，但要获得所需的更大图片。表格和警报列表无法帮助您了解全系统趋势。基于您的事件管理数据的可视化，例如类似的Pagerduty包括在报告中，帮助您大规模解释信息。
最后但并非最不重要的一点 - 尤其是如果您要通过编程分析数据，则可以根据需要导出日志数据。Pagerduty API使得收集和导出日志数据您需要的任何格式（以及事件API V2还将所有这些数据自动归一化为通用格式）。
要找什么
一旦进行了数据分析，您应该寻找什么？当然，您的确切需求会根据您正在监视的基础架构的类型而有所不同，但是一些通用的信息点包括：
- 发生事件的频率。如果此数字随时间变化，您将想知道为什么。
- 承认的平均时间（mtta）和平均解决（MTTR）事件的时间。通过跟踪这些数字，您将知道您的团队如何有效地处理其事件管理职责。
- 您的团队中谁在处理警报方面做得最多？知道这一点不仅可以使您的辛勤工作奖励成员，而且意识还会决定您的警报是否正确分发并授予合适的人。例如，如果一个管理员收到的警报要多于其公平份额，则应调整事情，以免他们不知所措 -导致警报疲劳，没有人想要那个。
- 哪些监视系统正在生成最多的警报？如上所述，如果您将各种监视系统中的警报合并到单个记录位置中，您还可以确定哪些系统为您提供最多的信息。您将能够查看系统的表现不佳或产生过多的噪音，并根据需要调整警报阈值。
如果您遵循这些提示，则一遍又一遍地面对相同类型的事件，就不会被重复记录。取而代之的是，您将能够确定大型趋势，这将帮助您找到使基础架构整体更有效的方法。
这就是事件管理可以真正回报的方式。记住另一个经常引用的格言 - “”一盎司的预防值得一磅治愈。事件响应是治愈的，但是创建一个使用历史事件管理数据的连续反馈循环是可以预防的最佳实践。