ASPIRE

衡量安全分析运营的指标

=Start=

缘由：

了解一些最常见的事件指标

在当今永不停机的世界中，中断和技术事件比以往任何时候都更加重要。故障和停机期间会带来现实后果，错过截止时间、付款逾期、项目延迟。

这就是为什么公司必须量化和跟踪有关正常运行时间、停机期间以及团队解决问题的速度和有效性的指标。

业界最常跟踪的一些指标包括 MTBF（故障前平均时间）、MTTR（平均恢复、修复、响应或解决时间）、MTTF（平均故障时间）和 MTTA（平均确认时间），这一系列指标旨在帮助技术团队了解事件发生的频率以及团队从这些事件中恢复的速度。

正文：

参考解答：

一开始在准备写这个主题的时候想写的大而全且尽量深入和通用，但在查阅了大量文档资料之后发现这太麻烦了，而且对我来说必要性不大（但在了解的过程中从指标的定义和设定初衷里还是学习到了很多），虽然说大部分时候你需要用业界通用的名词来定义某个指标，但这其实也不是必须的，对于大部分概念而言，在你要沟通和讨论的文档/会议/公司范围内定义清楚，参与方都认可就行了，不用过于纠结。核心还是要保证最终效果，指标含义定义的再准，文档写的再高大上，说的再天花乱坠，等到出事的时候都是扯淡（不过很多领导其实并不关心这个，他们还是喜欢好看的指标和文档，细节无需关心也不用关心）。

关于 MTTR 的免责声明

我们在谈论 MTTR 时，很容易假设它是一个含义单一的指标。但事实是，它可能代表了四种不同的衡量标准。R 可以代表修复、恢复、响应或解决(Repair, Recover, Respond, or Resolve)，虽然这四个指标确实重叠，但它们都有自己的含义和细微差别。

因此，如果您的团队正在谈论跟踪 MTTR，最好弄清楚他们在说哪个 MTTR 以及他们是如何定义的。在您开始跟踪成功和失败之前，您的团队需要同步了解您正在跟踪的内容，并确保每个人都知道他们在说同样的事情。

MTTRepair：平均修复时间
MTTRecover：平均恢复时间
MTTRespond：平均响应时间
MTTResolve：平均解决时间

几个关键时间点

其实这里有张自己画的图，后面有机会补上

1⃣️事件发生时间 -1-> 2⃣️自动告警/人工反馈时间 -2-> 3⃣️事件发现时间 -3-> 4⃣️分析决策时间 -4-> 5⃣️止损开始时间 -5-> 6⃣️止损完成时间 -6-> 7⃣️问题根治时间

1 - 告警时长 #在真实的世界里，除了要求事件发生之后我们能准确发现（准召率要高），还希望能尽早发现（告警延迟要低），以方便我们尽快介入好降低损失和影响，这就对数据分析和安全策略制定的同学提出了很高的要求（间接的底层的平台能力和数据质量也要足够的好才行，否则巧妇难为无米之炊）。

2 - 确认时长 #直接体现的是值班oncall同学的响应速度和告警系统的有效性，比如值班oncall同学如果关注消息及时，确认时长是几乎可以忽略不计的；还比如严重级别的告警发出去了之后本来应该是秒级别响应的，结果值班oncall同学刚好在和其它同学当面讨论着其它的技术问题没有及时关注消息，这个时候告警系统如果是直接电话通知的，就不会受此情况影响；还有告警升级的问题等等。

3 - 分析时长 #告警确认只是个开始，确认告警很快只能说明值班oncall同学很负责，但是真正影响整体运营指标的还是分析时长，当应急响应的同学接收到告警之后，可以借助平台/工具快速的获取全量的数据和信息来完整复现“案发”场景时，分析的效率就会很高、分析结论的可信度也高，也有助于后面做出更合理的决策，降低整体时长和事件产生的影响。

4 - 决策时长 #如果分析报告全面立体，平时的应急预案做的比较完善，决策速度相应的也会快很多，甚至可以忽略不计，比如通过 SOAR 按照既定剧本进行决策执行的效率就非常高。

5 - 止损时长 #线上问题的处理思路一般是先止损，再谈其他的。事故之中的核心是「快速止损」，因为查找问题是一个相对来说难度比较大，也比较漫长的过程，这个时间是不可控的。

6 - 问题根治时长 #这个要看具体问题和所处阶段，有些问题的根治时间和止损时间相同，因为临时止损完之后问题也就解决了，有些问题涉及到的链路比较长、业务方比较多，那根治的时长就可能会比较长也不太可控，如果有大老板盯着可能处理起来也很快，但如果没有的话就说不好了。


MTT Detect #平均 检测 时间，是指从系统故障到检测或告警所需的平均时间。这个指标用于直接标记安全策略的召回率（系统出问题了要能够检测出来）和警报系统的及时性（策略命中了之后告警要能及时触达到值班运营同学甚至是相关负责人那里）。但是这个指标其实也间接标记了几个其它的问题，安全策略的准确率和相关日志以及数据分析的时延大小。主要用于考核数据分析和安全策略同学，而数据分析和安全策略同学为了达到设定的准召率和时延指标，一方面是要加强对已有数据的深度挖掘，另一方面也需要对底层依赖的日志提供方提出更多和更高的需求才能完成目标。

MTT Acknowledge #平均 确认 时间，是从触发警报到开始处理问题所花费的平均时间。此指标可用于跟踪团队的响应能力和警报系统的有效性。MTTA 在跟踪响应速度方面很有用。您的团队是否受警报疲劳困扰并且响应时间过长？此指标将帮助您标记问题。oncall值班同学看到了告警之后要及时确认，如果发出来的告警都是准确的，那只需要认真负责就行，如果发出来的告警准确率没那么高（包括但不限于正确性和分类分级的合理准确情况），oncall值班同学就容易陷入警报疲劳的困扰从而降低跟踪响应的速度以及后续的一系列指标。

MTT Investigate #平均 调查 时间，是指从确认一个安全事件到开始调查其原因和解决方案的平均时间。表面检验的是应急响应、安全分析人员的经验和能力水平，但其实也是对安全工具、平台的易用性，日志的完整性、丰富程度的检验，因为在事件发生之后，如果安全分析人员可以通过安全平台快速准确的拿到相关日志和数据，就可以减少调查研究所需时间，尽可能的降低MTTI这个数字。

MTT Respond #平均 响应 时间，是从首次收到产品或系统故障警报开始，到从产品或系统故障中恢复所需的平均时间。这不包括警报系统中的任何延迟时间。通常将此 MTTR 用于网络安全。

MTT Repair #平均 修复 时间，是修复系统所需的平均时间。这包括修复时间和任何测试时间。直到系统恢复完全正常运行，此指标才会停止计时。平均修复时间并不总是与系统中断本身的时间相同。某些情况下，修复会在产品故障或系统中断后的几分钟内开始。在其他情况下，在问题出现、检测到问题和开始修复之间会有一段时间间隔。此指标在跟踪维护人员修复问题的速度时最有用。它并不是要识别系统警报问题或修复前延迟，这两者也是评估事件管理计划成败的重要因素。目标是通过提高修复流程和团队的效率来尽可能降低这个数字。

MTT Recover #平均 恢复 时间，用于衡量您的完整恢复流程的速度。它有您想要的那么快吗？它与您的竞争对手相比如何？这是一个高级指标，可帮助您确定是否有问题。但是，如果您想诊断问题出在流程的哪里（是您的警报系统有问题吗？团队在修复上花了太长时间吗？有人响应修复请求的时间太长吗？），您将需要更多的数据。因为故障和恢复之间会发生很多事。

MTT Resolve #平均 解决 时间，是完全解决故障所需的平均时间。这不仅包括检测故障、诊断问题和修复问题所花费的时间，还包括确保故障不会再次发生所花费的时间。该指标将处理修复的团队的责任扩展到长期提高绩效。这是灭火与灭火然后对房屋进行采取防火措施之间的区别。这个 MTTR 与客户满意度之间有很强的相关性，因此需要重点注意。
NIST 的应急响应生命周期

Incident Response Life Cycle Step1 - (Preparation)(准备)
Incident Response Life Cycle Step2 - (Detection and Analysis)(检测和分析)
Incident Response Life Cycle Step3 - (Containment, Eradication, and Recovery)(遏制，根除和恢复)
Incident Response Life Cycle Step4 - (Post-Incident Activity)(事件后的活动-复盘、整改等)


review:
* 发生了什么，什么时候发生的(what happened and when)
* 应急响应团队的表现(how well the IR team performed)
* 是否按文档流程操作的(whether documented procedures were followed)
* 当前的流程是否完备(whether those procedures were adequate)
* 什么信息在需要的时候存在缺失(what information was missing when it was needed)
* 哪些动作让恢复变慢了(what actions slowed recovery)
* 可以做些什么不同的事情(what could be done differently)
* 可以做些什么来预防未来的事故(what can be done to prevent future incidents)
* 未来可以寻找哪些先兆或指标(what precursors or indicators can be looked for in the future)
参考链接：

MTBF、MTTR、MTTA 和 MTTF #nice
https://www.atlassian.com/zh/incident-management/kpis/common-metrics

应急响应中你到底该关注哪些指标？ #nice
https://www.freebuf.com/articles/es/321522.html

如何选择事件管理 KPI 和指标
https://www.atlassian.com/zh/incident-management/kpis

INCIDENT RESPONSE PLAN: FRAMEWORKS AND STEPS #nice
https://www.crowdstrike.com/cybersecurity-101/incident-response/incident-response-steps/

Computer Security Incident Handling Guide #nice
https://www.nist.gov/publications/computer-security-incident-handling-guide
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf

Top 5 Incident Response Metrics with Real-World Examples & Impact #nice
https://www.splunk.com/en_us/blog/learn/incident-response-metrics.html

What Is Incident Management?
https://www.splunk.com/en_us/data-insider/what-is-incident-management.html

14 Cybersecurity Metrics + KPIs You Must Track in 2023 #nice
https://www.upguard.com/blog/cybersecurity-metrics

什么是MTTR，MTBF，MTTF和MTTA？ 事件管理指标指南
https://www.motadata.com/zh-CN/blog/incident-management-metrics/

MTTR、MTBF、MTTF、可用性、可靠性傻傻分不清楚？
https://zhuanlan.zhihu.com/p/439348834

常见的设备可靠性指标: MTBF/MTTF/MTTR/MTBR
https://blog.digiinfr.com/%E5%B8%B8%E8%A7%81%E7%9A%84%E8%AE%BE%E5%A4%87%E5%8F%AF%E9%9D%A0%E6%80%A7%E6%8C%87%E6%A0%87mtbf-mttf-mttr/

基于ISO12489看设备的可靠性指标MTBF/MTTF/MTTR
https://blog.digiinfr.com/%e5%9f%ba%e4%ba%8eiso12489%e7%9c%8b%e8%ae%be%e5%a4%87%e7%9a%84%e5%8f%af%e9%9d%a0%e6%80%a7%e6%8c%87%e6%a0%87mtbf-mttf-mttr/

无法衡量谈何改进？提升安全运营效率的7个关键指标
https://www.aqniu.com/hometop/88814.html

评估安全运营中心能力的七大关键指标
https://www.goupsec.com/guide/8895.html
https://www.secrss.com/articles/47494

Top 5 security analytics to measure
https://www.helpnetsecurity.com/2022/04/28/security-analytics-importance/

【顶会解读】安全运营中的告警分诊技术解析
http://blog.nsfocus.net/soc-aisecops/

现代企业应重点跟踪的12个网络安全建设指标
https://www.secrss.com/articles/51625

应急响应指标什么是MTTR、MTTD、MTTA、MTTI、MTTC
https://www.cnblogs.com/fczlm/p/16904168.html

Top 15 Cybersecurity Metrics and KPIs for Better Security
https://cybertalents.com/blog/top-15-cybersecurity-metrics-and-kpis-for-better-security

7 Incident Response Metrics and How to Use Them
https://securityscorecard.com/blog/how-to-use-incident-response-metrics/

=END=

Docker

, ,
, , , , , ,

《 “衡量安全分析运营的指标” 》 有 7 条评论

  1. 14 Cybersecurity Metrics + KPIs You Must Track in 2023
    https://www.upguard.com/blog/cybersecurity-metrics
    `
    Why are Cybersecurity Metrics Important? 为什么网络安全指标很重要?

    14 Cybersecurity KPIs to Track 14个可跟踪的网络安全关键指标
    1. Level of Preparedness 准备程度
    2. Unidentified Devices on Internal Networks 内部网络中未识别的设备
    3. Intrusion Attempts 入侵尝试数量
    4. Security Incidents 安全事件数量
    5. Mean Time to Detect (MTTD) 平均检测时间
    6. Mean Time to Resolve (MTTR) 平均解决时间
    7. Mean Time to Contain (MTTC) 平均遏制时间
    8. First Party Security Ratings 第一方安全评级
    9. Average Vendor Security Rating 供应商安全评级与能力评价
    10. Patching Cadence 问题修补节奏
    11. Access Management 访问管理
    12. Company vs Peer Performance 和同行业公司表现对比
    13. Vendor Patching Cadence 供应商问题修补节奏
    14. Mean Time For Vendors Incident Response 供应商事件响应的平均时间

    How to Choose the Right Cybersecurity Metrics? 如何选择正确的网络安全指标?
    `

    无法衡量谈何改进？提升安全运营效率的7个关键指标
    https://www.aqniu.com/hometop/88814.html
    `
    如今，网络安全运营已经成为企业网络安全保障建设的一项重要内容。安全运营做的好，企业的安全风险就会降低，反之，则可能会存在重大安全隐患。不过，随着网络攻击技术的日新月异，企业安全运营体系也需要不断的优化和改进，并定期对安全运营中心（SOC）及运营计划的有效性进行评估，但这并不容易。
    据最新研究数据显示，目前大多企业组织的安全运营成熟度有待改进和提升。在对250多名安全运营人员的调查中，仅有不到2成的受访者对目前的安全运营能力感到满意；其余受访者则认为，其所在组织的安全运营工作并不成熟，或者并不了解安全运营水平究竟如何。
    MTTD（平均检测时间）和MTTR（平均响应时间）是目前最常用于衡量安全运营效率的评价指标，减少MTTD和MTTR已经成为企业增强安全运营弹性的主要目标。但随着企业成熟度的提高，这时候需要更全面的评估安全运营团队是否可以实现其关键绩效指标（KPI）和服务等级协议（SLA）。因此，**除了MTTD和MTTR外，企业还应该跟踪更多的关键性能力指标，以衡量组织应对网络威胁的真实安全运营能力。**
    以下总结了7个关键指标，可以帮助企业更好地设置安全运营基线，从而更全面了解安全运营计划的执行情况，并从中发现存在的问题和不足：

    01 – 平均事件检测时间（Mean Incident Time to Detect，MTTD）

    MTTD是指安全风险事件从最初被检测到最终确定其有效性所花费的时间。它是衡量安全运营效率的关键指标，可以反映企业在识别安全事件的真实威胁方面的能力和水平。
    指标价值：
    * 实现基于威胁/事件类型（例如通过MITRE ATT&CK类别）的事件调查和报告；
    * 实现基于威胁检测方法（捕获、行为分析、场景分析、特定威胁检测技术等）的安全事件调查和报告；
    * 发现安全运营体系在支持威胁发现和威胁鉴定方面的能力水平和不足。

    02 – 平均事件响应时间（Mean Incident Time to Response，MTTR）

    MTTR是衡量调查和减轻已确认事件所花费的时间。它是衡量安全运营效率的关键指标，显示了安全运营团队在分析和缓解安全事件的实际威胁方面的能力与不足。
    指标价值：
    * 实现基于威胁/事件类型的安全事件调查与报告；
    * 发现安全运营体系在安全事件响应方面存在的问题和不足。

    03 – 平均警报分类时间（Mean Alarm Time to Triage，MTTT）

    MTTT是指从警报信息出现到运营团队开始检查告警信息所需的时间。它可以帮助企业了解对威胁的实时响应水平。
    指标价值：
    * 实现对警报信息的优先级范围划分；
    * 明确安全运营团队需要承担的监控负载和范围；
    * 可以明确安全运营团队的监控重点，并以此优化团队配置。

    04 – 平均警报合格时间（Mean Alarm Time to Qualify，MTTQ）

    MTTQ是指警报信息经过全面检查到确定其有效性或添加为威胁所需的时间。MTTQ可帮助企业了解安全运营团队识别威胁的能力以及其中所存在的能力瓶颈。
    指标价值：
    * 实现警报优先级范围内的有效报告；
    * 实现对警报结果的评价；
    * 发现安全运营解决方案在警报查询、分析和上下文检索方面存在能力不足。

    05 – 平均威胁调查时间（Mean Threat Time to Investigate，MTTI）

    MTTI是指新添加的威胁经过全面调查到确定有效性或升级为事件所需的时间。它可以帮助企业识别对新安全威胁事件的识别和调查能力。
    指标价值：
    * 实现基于威胁/事件类型（例如通过MITRE ATT&CK类别）的调查和报告；
    * 评估安全运营解决方案在搜索、数据分析、上下文分析和协作领域的进展状况和能力水平。

    06 – 平均事件缓解时间（Mean Time to Mitigate，MTTM）

    MTTM是指从安全事件创建到事件风险缓解并消除所花费的时间。它可以帮助企业了解安全运营团队能够以多快的速度解决新出现的安全风险事件。
    指标价值：
    * 实现基于威胁/事件类型（例如通过MITRE ATT&CK类别）的风险处置流程；
    * 发现现有安全运营体系在调查取证、标准化操作、自动化和团队协作方面的能力水平和存在问题。

    07 – 平均事件恢复时间（Mean Time to Recover，MTTV）

    MTTV是指从安全风险事件缓解到完全恢复所需的时间。它可以帮助企业了解安全运营团队和其他相关群体从突发安全事件中完全恢复的能力和速度，也可以从中识别出安全运营和协作的难点及瓶颈。
    指标价值：
    * 实现基于威胁/事件类型（例如通过MITRE ATT&CK类别）的安全事件应对和处置；
    * 发现现有安全运营体系在调查取证、标准化操作、自动化响应和团队协作方面的能力水平和存在问题。
    `

    回复

  3. 有效告警的最佳实践
    https://newrelic.com/resources/ebooks/effective-alerting-guide
    `
    No one ever said that alerting was easy. How do we ensure that alerts are delivered in a timely manner while preventing as many false positives and negatives as possible? Additionally, how do we make sure we’re detecting issues on time and not waking up our users in the middle of the night with false alarms? Alert fatigue is a real thing.
    没人说过问题告警是件容易的事。我们如何确保及时发送告警，同时尽可能多地防止误报和误报？此外，我们如何确保及时发现问题，而不是在半夜用假告警唤醒用户？警觉性疲劳是真实存在的。

    随着软件开发的速度越来越快，警报成为一种不可或缺的做法，对于现代 DevOps 团队来说更是如此。为什么会这样？

    首先，重要的是要考虑不同维度的站点性能的服务级别质量：

    * 可靠性。软件是您业务成功的核心；您需要知道您的系统已启动并正常运行。
    * 故障排除。你无法解决你不知道的问题。如果出现问题，您需要上下文来快速修复它。
    * 自动化。您不能每 10 秒手动刷新一次主页；您需要一个可以全年无休地为您监视事物的工具。
    * 复杂性。你的系统太复杂了，你不可能时时刻刻都在看；您需要一种可以随着系统的增长而扩展的警报实践。
    * 对结果负责。最终，您要对提供给客户和利益相关者的数字体验负责。不可用、损坏或缓慢的系统肯定会让他们对您失去信心。

    由于这些基本问题，我们必须在行动中保持警惕，我们需要设置警报的指南。在本指南中，我们将向您介绍如何为您的技术堆栈创建和管理有效的警报策略。在高层次上，我们将涵盖：

    * 现代技术堆栈的转变如何导致警报策略的转变
    * 动态和扩展环境的一些警报最佳实践
    * 如何设计和维护对您的组织和团队有用的警报系统

    有效实施的警报系统是任何成功的 DevOps 团队最重要的部分之一。

    # Modern Technology Stacks: Affecting Alerting Through Challenges and Change

    # Alerting Design Principles
    1. 考虑质量而不是数量。 自信的团队通常拥有更稀疏、更高质量和更有意义的警报策略。对其警报策略缺乏信心的团队通常有一种“囤积者心态”，并且会积累低质量的警报策略，这些策略最终会变得嘈杂且用处不大。
    2. 创建可操作的页面。 质量警报策略是可操作且有意义的。页面应呈现需要积极参与和响应的情况；否则，它们会产生不必要的噪音和警报疲劳。许多警报系统的功能是不断发出不可操作的通知——如果没有任何问题，就不应该有任何来自警报的噪音。
    3. 广播信息项。 对于某些警报，您可能需要提供有关系统事件的详细信息，即使它们不是立即可操作的。通过电子邮件或 Slack 等渠道向您的团队广播此类项目。
    4. 确定上游依赖项是可操作的还是信息性的。 如果上游依赖项出现故障，您的团队可能无法对此做任何事情，因为他们不拥有该依赖项。在这种情况下，信息广播更为合适。但是，如果团队可以做些什么来减轻上游依赖性的影响，那么页面是合适的。
    5. 优先考虑人工发送的通知。 人类对他们的系统有自动化无法提供的理解。如果有人发送通知，例如支持人员提出问题，请优先处理。
    6. 投资警报自动化。 作为优先考虑人工通知的必然结果，自动化您的策略、通知渠道和事件跟踪。您预先花在这方面的时间将在以后实际中断期间为您节省时间。
    7. 建立警报文化。 这些指导方针都不是特别具有革命性，但工程团队往往无法建立一种警报文化，从而导致理解和流程方面的差距。确保您的所有团队成员都了解您的警报策略，并将其记录为整体工作流程的一部分。

    # Creating an Alerting Strategy

    # Alerting for Dynamic and Scaled Environments

    # Managing Different Alerting Sources

    # Making Alerting Work for Your Team

    # Incident Response Lifecycle Framework

    # Next Steps

    # Successful DevOps starts here
    `

    回复

  4. 无效告警优化实践总结
    https://mp.weixin.qq.com/s/cBCaHwEvQFGM7RNDMMavzA
    `
    对于7*24小时不间断运行的后台服务，监控告警是稳定性运行的基石。很多开发者都有过这样的经历，对服务的每一个指标都做了严格的监控和告警，唯恐漏掉告警导致问题无法发现，导致每天接收到大量的无效告警，告警的泛滥逐渐麻痹了警惕性，结果真实的问题初漏端倪时却被忽略，最终导致了严重的故障。

    如何提升告警的有效性，准确识别问题，同时又不至于淹没在大量的无效告警中，正是本文所探讨的内容。

    # 告警是可靠性的基础

    首先来看一下告警的重要性，为什么我们需要耗费这么多精力来优化告警。虽然我们都期望一个服务是没有故障的，但事实确是不存在 100% 没问题的系统，我们只能不断提升服务的可靠性，我们期望做到：

    * 对服务当前状态了如指掌，尽在掌控
    * 能够第一时间发现问题，并且快速定位问题原因

    要想做到以上两点，只能依赖完善的监控&告警，监控展示服务的完整运行状态，但是不可能一直盯屏观察，并且也不可能关注到所有方面，要想被动的了解系统状态，唯有通过告警，自动检测异常情况。

    # 告警面临的现实问题

    理想中的告警，不存在误报（即本来正常的，告警为异常）也不存在漏报（即本来异常的，误认为正常），所以理想的模型满足以下三点：

    * 误报为0：出现的告警都是需要处理的问题
    * 漏报为0：异常问题都能够告警发现
    * 及时发现：能够第一时间发现问题，甚至于在导致故障前发现问题

    但在实践中无法做到理想情况。要减少漏报，需要针对每一种可能发生的场景进行监控，同时配置告警，这其实并不算困难；但我们的告警往往不是太少了，而是太多了，以至于需要耗费大量时间处理无效告警，由于告警过多，容易忽略真正有用的告警，导致异常发现的时间变长，或者忽略的潜在的风险。所以对于告警，最大的问题在于如何减少无效告警，提升告警的效率。

    先来看一下无效告警产生的原因。

    监控系统应该解决两个问题：什么东西出故障了，以及为什么会出故障。其中“什么东西出故障了”即为现象，“为什么”则代表了原因（可能是中间原因）。现象和原因的区分是构建信噪比高的监控系统时最重要的概念。

    在实践中，想绝对做到这两点几乎不可能，但我们可以无限趋向于理想模型。

    告警一般是通过“现象”来判断，而是否有问题要看产生现象的原因判断。相同的现象引起的原因可能不同，这种“可能性”是导致误告警的最核心原因。

    # 告警分类

    同样是告警，对于CPU跑满这种情况需要立即处理，但对于单机健康状态告警（正常异常机器会自动置换，异常情况可能置换失败），系统并不能自动解决这种状况，但是一段时间内不处理，也不会造成影响，负载均衡设备会自动摘除。

    所以这里涉及到一个告警分类的问题，当然，告警可以有很多种分类方法，分成很多种级别区别对待，但在优化无效告警的目标下，我们通过是否需要立即停下手头工作立即处理，分为三类：

    * 紧急：收到报警就需要立即执行某种操作。如CPU跑满，内存跑满等。判断标准，是否对业务有影响，以及是否有潜在的未知风险
    * 不紧急：系统并不能自动解决目前状况，但是一段时间内不处理，也不会造成影响。如单机出现访问不通异常。判断标准，对业务无影响，基本无潜在的风险，但最终需要人工介入处理
    * 不需要处理：已知异常并且系统会自动恢复，不需要人工接入。如机器虽然出现异常，但运维底座会再一段时间内自动处理，不需要人工介入

    对于一个异常，首先需要判断是否需要立即处理，区分进行优化。

    # 告警设置原则

    * 告警具备真实性：告警必须反馈某个真实存在的现象，展示你的服务正在出现的问题或即将出现的问题
    * 告警表述详细：从内容上，告警要近可能详细的描述现象，比如服务器在某个时间点具体发生了什么异常
    * 告警具备可操作性：每当收到告警时，一般需要做出某些操作，对于某些无须做出操作的告警，最好取消。当且仅当需要做某种操作时，才需要通知
    * 新告警使用保守阈值：在配置告警之初，应尽可能扩大监控告警覆盖面，选取保守的阈值，尽可能避免漏报。
    * 告警持续优化：后续持续对告警进行统计分析，对误报的告警，通过屏蔽、简化、阈值调整、更精准的体现原因等多种方式减少误报，这是一个相对长期的过程。

    # 善用工具

    另外优化告警的一个必备条件，就是要熟悉所用告警平台使用，如果都不知道告警平台可以做到什么程度，可以设置怎样灵活的条件阈值，是很难对告警做合理优化的。

    # 告警处理流程

    **前面提到了告警的优化是一个持续的过程，不存在一劳永逸的事情**。需要每天或者每周安排值班人员负责告警事宜，这点上确实是需要一定的投入。值班同学需要持续关注告警的有效性，对于出现的无效告警，分析清楚原因，持续优化阈值或者告警策略。

    * 确保能够收到所有告警：可以通过接收人组解决，确保所有值班同学都在一个接收人组，如果有人员变动也方便修改
    * 上升线路：需要判断问题的严重性，适合时机上升，增加资源快速把问题消灭再萌芽状态
    * 明确根本原因：确保弄清楚问题原因，而不是表面上恢复。比如单台机器CPU跑满告警，可能存在未知的死循环问题，如果仅仅重启进程恢复，很可能掩盖了问题，导致未来出现大面积的死循环引发故障
    `

    回复

  5. 跟误告警说再见，Smart Metrics 帮你用算法配告警
    https://mp.weixin.qq.com/s/jfT1pqKXGh3JjT5ajR8qTA
    `
    # 引言

    某位资深 SRE 同学表示“一天不收个几十条告警，我都觉得不安心”，“告警天天告，我们的应用一点事情都没有”。这都反映了一个非常普遍的现象 — “误告警泛滥”，而“真”告警容易被淹没。ARMS AIOps 团队对超过 6 万条关于响应时间和错误率突增的告警进行了分析，发现其中只有 3.05%的告警是“真”告警。同时发现误告警泛滥根源在于单靠现有告警产品的能力很难配置出行之有效的告警规则。因此，ARMS 基于托管版 Grafana 推出智能告警插件——Smart Metrics，用算法帮助用户解决”告警配置难、维护难”的问题。
    本文从两类常见的无效告警规则入手，分析有效告警配置难，误告警泛滥的原因，介绍 Smart Metrics 是如何帮助用户解决告警难配的问题的，并介绍一些最佳实践。

    # 告警现状分析

    误告警泛滥

    我们通过对 ARMS 告警数据及用户访谈进行分析，发现许多用户一天收几百条告警，但其中真正有用的只有几条。更可怕的是，那几条“真”告警往往被淹没在大量误告警中，导致用户没能在第一时间对真实故障做出处理。这些误告警往往是由一些不良的告警配置习惯造成的，比较典型的有下面两种：

    1. “一刀切”式配告警方式：
    比如一位 SRE 同学要管理很多接口，但为了节省告警配置时间，所以选择对所有应用/接口的响应时间、错误率和调用量配置统一且固定阈值。然而，不同应用/接口正常状态下的响应时间、调用量和错误率指标的正常水位本身就不相同，成百上千的应用/接口使用同一阈值自然会产生大量误告警。

    2. “疏于打理”的告警阈值：
    有的告警规则在应用起初是没有问题的，但随着业务增长，响应时间、调用量等业务指标，以及 CPU 使用率等机器指标的平均水位线已发生变化。但 SRE 没有及时更新阈值，导致系统正常时也会不断产生告警。

    有效告警配置难、维护难的原因

    1. 许多运维指标起伏不定，很难设定合适的静态阈值。
    它们往往呈现出以小时、天、周为周期的季节性特征。这些指标本身就起伏不定，导致静态阈值、同比阈值都不好配。

    2. 同一指标，不同应用\接口\主机阈值不同。
    以 RT 指标(响应时间)举例， 有的接口正常时 RT 在 200ms 左右，那么当 RT 大于 300ms 时，可以判定为异常。然而，有些接口长期访问量大， 整体指标在 500ms 左右正常波动，合适的告警阈值可能是 600ms 左右。而一个应用可能有几百个接口，运维同学要对所有接口配置合适的阈值，时间成本非常高。

    3. 指标的正常水位会随着业务的增长变化。
    随着公司业务发展、新应用上线，一些指标正常状态水位会不断变化。如果没有及时更新阈值，就很容易产生大量误告警。

    综上，靠现有告警产品中依赖静态阈值方式，需要 SRE 同学投入大量时间成本且难以取得较好效果。 为解决这个问题，ARMS推出基于 Grafana 的智能告警插件——SmartMetrics，用算法来帮助用户配置有效告警。

    # 更简单的告警配置方式-SmartMetrics

    SmartMetrics 是一款“智能、易用、效果可见”的告警插件，**能够从历史指标数据学习指标的特征，并对未来一段时间内指标正常变化范围做出预测，生成上下边界。这里的上下边界围成的区间默认就是 90 置信区间。也就是按照前面几天的趋势，指标没有发生异常的话，有 90 的概率，它未来的值会落到我们预测得到的上下边界中**。

    SmartMetrics 通过多模型融合方式为不同类型指标计算上下边界。SmartMetrics 先通过 Smart-PLR 算法捕捉指标关键特征，并利用分类算法确定该指标曲线类型；根据其类型来选择最适合时序预测模型与最佳参数；最后生成上下边界。

    SmartMetrics 在采取业界热门开源算法 Prophet、STL、ARIMA， BiLSTM 基础上，基于阿里云内部大数据实践进行单周期/多周期识别、趋势识别、异常点识别、毛刺识别、变点识别等优化， 最终融合成一套多模型 Smart-Prophet 算法方案。SmartMetrics 具有以下几个特点：
    a. 准确性：算法在阿里云内部进行多场景经历过验证， 拥有精准、全面的异常点发现能力。配合告警持续时间，起到精准告警效果。
    b. 通用性：算法对于业务指标和基础指标有比较好支持， 对于周期性、趋势性、波动性指标进行比较好的曲线分类和模型参数配置。
    c. 免维护：使用SmartMetrics的用户无需随业务变化对算法进行动态化调参，算法可自适应通过对指标变化的规律学习，从而适应业务变化。
    `

    回复

  7. Technical Metrics Aren’t Enough: 10 Strategic Security Measures
    https://rvasec.com/slides/2016/Ben%20Smith%20Measuring%20Security%20-%20How%20Do%20I%20Know%20What%20a%20Valid%20Metric%20Looks%20Likepdf.pdf

    Measuring Security – How Do I Know What a Valid Metric Looks Like?
    `
    1. Why measure anything?
    2. Poor metrics
    3. Knowing your audience
    4. Good metrics
    5. Summary and additional resources

    —

    为什么要关注何为有效的安全衡量指标？

    Will a savvy understanding of the metrics of your internal environment become even more important as this happens?
    在这种情况下，对内部环境指标的深入理解是否会变得更加重要?

    1. 获得洞察力
    2. 用业务自己的语言与业务交流——安全计划具有可衡量的业务价值
    3. 客观地证明安全目标正在得到实现
    4. 证明新投资的合理性
    5. 改进！

    —

    Poor Metrics
    • Easy to collect, but not very actionable
    – Operational metrics ≠ Business-centric metrics
    • Examples of what NOT to measure *
    – Spam emails received
    – Virus infection attempts blocked
    – Technical security vulnerabilities resolved
    – Failed logins
    • We tend to measure what we can’t control

    差的衡量指标
    * 易于收集，但可操作性不强
    – 业务指标 ≠ 以业务为中心的指标
    * 不应衡量的指标举例(*)
    – 收到的垃圾邮件
    – 阻止病毒感染尝试
    – 解决的技术安全漏洞
    – 登录失败
    * 我们倾向于衡量我们无法控制的东西

    Poor Metrics
    • Subjectively measured
    • Inconsistently measured
    • Costly to gather
    • May not be “metrics” at all
    • May not be built for your true audience

    差的衡量指标的特点
    * 主观衡量
    * 衡量标准不一致
    * 收集成本高
    * 可能根本不是”衡量标准”
    * 可能不是为真正的受众设计的

    —

    Know Your Audience
    了解你的受众

    • Create a common language between the Business and Security
    • CISOs are the most influential securityfocused consultants to the Business or rather, they *should* be
    • Metrics must reflect the role and the value that the Security organization plays in the Business strategy

    * 在业务和安全之间建立一种共同语言
    * CISO是对企业最有影响力的安全顾问–或者说，他们应该是。
    * 衡量标准必须反映安全组织在业务战略中发挥的作用和价值

    • The “language” of Security is hard for the Business to fully understand
    – Presentation skills are essential – practice!
    • Communicating in a Business context
    – Leverage standard templates or communication tools
    – Consider a taxonomy document

    安全的“语言”对业务来说很难完全理解
    * 演讲技巧是必不可少的–练习!

    在业务环境中进行交流
    * 利用标准模板或沟通工具
    * 考虑做一个分类文档

    • Business leaders are extremely busy
    – Connect your message to an identified business driver
    – Critical information should be front and center
    • The Business finds it extremely difficult to identify its own risk appetite
    – Consider scenarios and story-telling as tools
    • Business leaders are challenged in communicating back to Security, too!
    – Understand the goals/initiatives of the Business units

    业务领导是非常繁忙的
    * 将你的信息与已确定的业务驱动因素联系起来
    * 关键信息应放在前面和中心

    业务方发现要确定自己的风险偏好是非常困难的
    * 考虑将情景和讲故事作为工具

    业务领导在与安全部门的沟通反馈中也面临着挑战!
    * 了解业务部门的目标/举措

    —

    What Makes a “Good” Metric?
    • “The primary goal of metrics is to quantify data to facilitate insight.” Andrew Jaquith
    • A good metric is:
    – Consistently measured
    – Cheap to gather
    – Expressed as cardinal number or percentage
    – Expressed using at least one unit of measure
    – Contextually specific

    什么是“好的”指标?
    • “指标的主要目标是量化数据，以促进洞察力。” Andrew Jaquith
    • 一个好的衡量标准是:
    – 持续测量
    – 收集成本低
    – 以基数或百分比表示
    – 至少使用一个度量单位来表示
    – 具体情况

    —

    What Makes a “Good” Metric?

    Actionable
    The source of the problem, or necessary actions to take, are clear when the metric goes up, down, flat or off-target

    Common interpretation
    People in the organization recognize what the metric means

    Accessible, creditable data
    The data can be acquired with modest effort from a source that people trust

    Transparent, simple calculation
    How the metric is generated is shared and easy to understand

    什么是”好的”指标？

    可操作
    当指标上升、下降、持平或偏离目标时，问题的根源或需要采取的行动都很明确

    通用解释
    组织内的人认识到指标的含义，不存在不清楚或是有歧义的情况

    可获取、可信的数据
    可以不费力的从人们信任的来源获取数据

    计算透明、简单
    指标的生成方式是共享的，易于理解

    —

    Five Security Metrics to Consider
    1. Time elapsed between incident discovery and incident containment
    2. Number of orphaned information assets without an owner
    3. Days to remediate 50% (the “half-life”) of vulnerable hosts
    4. Number of server patches applied outside of a scheduled maintenance window
    5. Percentage of third-party users whose privileges were reviewed this reporting period

    5个需要考虑的安全指标

    1. 从发现事件到抑制事件所需的时间(MTTR)
    2. 没有所有者的信息资产的数量
    3. 修复50%的易受攻击主机所需的天数（”半衰期”）
    4. 在预定维护窗口之外应用的服务器补丁的数量
    5. 本汇报周期内权限被审查的第三方用户的百分比

    —

    Caveats

    • Don’t blindly accept your vendor’s proffered metrics.
    – “We tend to overvalue the things we can measure and undervalue the things we cannot.” John Hayes

    • Metrics should be actionable!
    – “If a measurement matters at all, it is because it must have some conceivable effect on decisions and behaviour. If we can’t identify a decision that could be affected by a proposed measurement and how it could change those decisions, then the measurement simply has no value.” Douglas W. Hubbard

    注意事项

    不要盲目接受供应商提供的衡量标准。
    – 我们往往会高估我们能衡量的东西，而低估我们不能衡量的东西”。 John Hayes

    衡量标准应具有可操作性！
    – 如果一个衡量标准是重要的，那是因为它一定会对决策和行为产生某种可以想象的影响。如果我们无法确定某项决策会受到某项衡量建议的影响，也无法确定衡量建议会如何改变这些决策，那么这项衡量建议就毫无价值可言。 Douglas W. Hubbard
    `

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注