事件响应软件的 DevOps 指南

DevOps指导事件响应Soft 你的合作指南事件响应 事件:一个问题,由一个警告,这可能对客户、您的员工和 组织内部或外部的利益干系人。 为了在当今市场上保持竞争力，企业期望快速创新。许多工程团队认为 构建、部署和运营服务的压力越来越大速度。高绩效团队加快创新速度并保持他们的理智——因为他们能够快速恢复从事件。 操作和一致的正常运行时间。最终，重新思考和重新调整您的DevOps和事件响应方法是 交付新产品和优化现有产品势在必行 服务，以保持您的业务相关性和竞争力。 本买家指南讨论了为什么进步、高性能团队选择投资于高性能事件响应 软件。从整个SDLC面临的挑战到具体的 事件响应产品功能，我们将为您列出所有内容选择事件响应解决方案时需要考虑。 随着我们从敏捷开发转向快速部署， 团队需要超越被动的运营中心进行思考。这就是为什么选择正确的事件响应系统是成功开发运营文化的关键。高性能 工程和运营团队是事故的冠军 响应系统—他们依靠这些系统实现平稳运行 一个事件反应Sof器皿DevOps指南|Splunk2 的挑战 如果没有确定的事件响应，您将面临： •警报声音疲劳。 •员工倦怠。 •紊乱或孤立的通信。 •可怜的警报从不同的IT系统。 •错误的人提醒。 •缺乏准备的一场危机。 •断开连接的工作流。 •重复以前的错误。 一个事件反应Sof器皿DevOps指南|Splunk3 建筑的文化 紧迫性和可用性 高可用性对于业务成功至关重要—这个问题因数字化和市场竞争的加速部署需求。 投资事件响应解决方案以确保 零停机时间，同时快速部署整个工程和它的组织。 我们将分解事件响应如何是维护 在不减慢创新过程的情况下实现可用性—以及DevOps的现状成功执行此Shif的关键部分。 的负面经济影响停机时间 根据2022年的状态可观测性报告调查了1200人全球可观测性实践者，“领导者可观察性实践”（ 包括定义的事件响应流程和工具），平均降低成本 领导:$495，936.70/小时x2次中断/年x2.5小时/解决方案=2.5美元的成本中级:1:80x2x8=495936美元7.9美元的成本 初学者:x6×8=495936.70美元23.8美元的成本 如您所见，采用可观察性实践会带来重大回报定义事件反应过程和工具。 竞争优势的最少的停机时间 领导者可观测性组织使用历史事件数据主动让团队做好准备以更快地解决事件，并在 第一名。这反过来又成为一种竞争优势，因为功能强大。“随叫随到”的团队帮助保护收入损失，维护品牌声誉并推动客户满意度。 停机时间比初学者可观测性组织多90%。领导者可观察性团队在以下情况下的表现往往比同行好得多 吞吐量和稳定。 那么，从财务角度来看，这相当于什么？ 停机成本的计算基于受访者的估计内部开发的关键业务每小时停机成本 应用程序，乘以每年的中断次数及其典型值持续时间(小时)。 停机时间的平均成本决定每小时495765.70美元。在平均，领导者和中间可观察性采用组织看到两个 每年发生重大计划外停机，可观察性初学者可以看到六个每年发生重大停电。领导者平均解决计划外停机问题 在两个半小时，而中级和初学者看到的平均八个小时解决计划外停机。 《2022年可观测性现状》报告还强调，领导者的可观测性组织2.1倍能够推动生产的代码 按需满足大多数内部开发的应用程序的需求。领导者可观测性组织报告停机不常见。 64%的领导人说关键业务内部 开发的应用程序每隔几个季度或更少就会宕机一次——而只有40%的初学者可观测性组织 可以说是一样的。 让我们来做数学! 一个事件反应Sof器皿DevOps指南|Splunk4 Shift罗ITIL: DevOps,现代 信息技术基础设施库（ITIL）模型是在 1980年代后期，人们被运送到用于应用程序的物理磁盘更新。虽然当时并非每家公司都在从事销售业务 SOF软件，现在几乎每个企业都依赖于运行SOFWare和交付在线服务。Sofware正在颠覆每个行业-娱乐， 农业、金融等等。 这就是ITIL失败的地方。ITIL将职责和流程批准分开努力支持标准化和减少重复工作。这个孤立的和 充满流程的方法本质上会减缓变革。尽管如此，许多组织仍然依赖此模型，希望遵守SLA并保持 尽管部署需求非常快，但停机时间几乎为零。 DevOps是一种工作方法，团队不断寻找方法来评估和改进与建筑相关的技术、流程和人员，部署、运营和支持其组织提供的价值。这是一个更广泛的SHIFTN思维方式，通过 客户的镜头。加速这个shiftb: •通过合作创造价值。 •测量和改善流程。 •得到客户的反馈。 •提高透明度。 为了推动创新、保持正常运行时间并支持员工成长，ITIL 在永远在线、24/7的IT范式中站不住脚。因此，我们主张 DevOps模型是事件响应的基石。 一个事件反应Sof器皿DevOps指南|Splunk5 给你的生活带来DevOps DevOps的好处和统一的事件反应对于开发人员：拥有您的代码并授权开发团队 将DevOps与前瞻性事件响应工具相结合意味着混乱的随叫随到的经历。 行动:一个更好的随叫随到的经历 •与开发商合作背后的代码。 •抛弃共享寻呼机—承认并解决自己的问题移动设备。 •在整个工具链（监控等）中集成集中的信息。 •你需要访问上下文,很快。 •提高警报速度，在不牺牲安全性的情况下快速部署或效率。 •创造更稳定的操作环境。 •花时间进行构建和创新，而不是修复和维护。 •提高代码的整体质量。 •支持所有权和问责制，无论角色或头衔如何。提高效率并提升客户体验 •在竞争中保持领先。 •限制停机时间,提高服务质量。 •提高IT员工的工作效率和幸福感。 •推动质量跨团队沟通。 •提高整体组织的速度。 一个事件反应Sof器皿DevOps指南|Splunk6 现代随叫随到的事件生命周期 当今的团队必须在整个生命周期内管理事件-折叠检测、关联、响应、补救、分析和准备。在此 阶段2:相关 部分，我们将深入探讨事件生命周期的五个不同阶段。相关性是系统利用数据进行分组和优先级排序的能力 用于在广泛的数据类型集之间创建关系的策略或规则 对于每个阶段，我们将介绍定义。然后，我们将讨论它们之间的关系 了解待命和事件响应所需的特性和功能 sof制品超过警报做出反应。 阶段1:检测 检测是在特定时间间隔内对指标的观察和比较的观察结果与预期值的对比。然后触发监控系统基于对这些指标的观察的通知和警报。 它如何与事件反应sof器皿吗 简单地说，检测就是监控洞察力，寻找迹象和信号一个事件。但是，在具有旧监视配置的组织中， 实际上，提高检测效果是很困难的。环境配置了广泛的应用的静态阈值。对待命团队的影响是可以衡量的：太多错误警报+过多中断=急性警报疲劳和员工倦怠。为 以上原因，高绩效团队除了关注两件事之外，还关注两件事基本。首先是其监测和检测系统中的时间序列分析。 例如，一些渐进式市场解决方案提供时间序列数据库，在新项目和现有环境中实现广泛采用。 您的事件响应工具应该能够与 先进的监控工具可提高测量保真度。 例如事件、指标、日志和跟踪。可以设置关联手动配置的策略和规则，也可以是机器学习算法用于了解性能基线和趋势并关联数据，而无需人工干预。 它如何与事件反应sof器皿吗 关联是实现事件响应的下一个关键步骤系统，并使处理事件管理和 故障排除。关联会自动对所有警报进行分组和优先级排序，以便事件响应者直接指向最值得注意的警报。这 最终加快根本原因识别并显著降低警报疲劳和倦怠。 一个事件反应Sof器皿DevOps指南|Splunk7 阶段3:响应这一点很重要：开发人员不会积极回应（阅读：采用） 高度反应性的待命管理工具。该工具需要提供上下文， 响应阶段是向事件响应者传递通知 通过任何方式，以及响应者为解决警报而采取的第一步。因此，通过检测阈值，发送电子邮件/短信/聊天/电话 （通知）并且有人确认收到（响应）。 它如何与事件反应sof器皿吗 有几个关键功能可以确保有效响应。你 可以将这些功能视为随叫随到的必需品，或者取决于薄程度功能集是“基本警报”。市场上领先的事件响应工具 将提供: •动态调度。 •小组的旋转。 •自动升级和路由。 •计划覆盖。 这些功能集是必不可少的，但孤立地看，它们根本不强大。足以支持真正的DevOps文化。高绩效的DevOps团队倾向于专注于反应性较低的环境，投资于人员、流程和 确保团队主动准备、最小化和预防的工具 事件。因此，响应过程中的每一秒都提供了机会提高可靠性和正常运行时间。 协作和可见性。 许多高绩效团队通过ChatOps工具取得了成功以及集中通信和设置第一响应者的工作流程 为了成功。在Slack或Microsofteams中接收基本通知时 太好了，一个上下文警报，带有当前状态的视觉指示，以及指向相关的运行手册或仪表板，节省响应者挖掘的宝贵时间 这个错误。 购买事件响应解决方案时，买家不仅应该看用于双向聊天集成和聊天操作功能，以及 能够配置警报以满足团队需求。警报中存在的任何信息有效负载可用于向待命响应者提供其他详细信息。 附加到每个警报的直接或上下文详细信息将减轻压力的待命，并提供下一级技术以更快地解决事件。 一个事件反应Sof器皿DevOps指南|Splunk8 阶段4:修复它如何与事件反应sof器皿吗 当我们讨论分析时，事件需要几个关键步骤 补救是事件响应的真正“救火”阶段，团队在其中 目的快速诊断和解决问题。 它如何与事件反应sof器皿吗 第一部分取决于上下文警报：团队拥有哪些数据访问，也许更重要的是，他们是否有理解能力数据对现实生活的影响。数据的情境化允许团队 将指标转化为可操作的见解，以提供更高保真度的图片这一事件。 事件响应软件可以充当时间序列系统的黑匣子 （例如，InfluxDB），日志分析系统（例如，Splunk）和对生产的更改 (例如,詹金斯,GitHub)。 无论您对这些指标的具体方法如何，您的事件响应应支持系统和数据的整体视图。强大的集成， 上下文警报和附加到警报的运行手册用作集体知识处理各种问题的基础，无论您的角色或任期如何。 第五阶段:分析 定义 分析阶段，称为事后或事后审查，是 事件后的学习过程得到解决。虽然历史方法 此阶段严重依赖根本原因分析（RCA），越来越复杂系统使进步团队不再仅仅依赖单一因果关系 实体分析。相反，团队越来越多地关注以下模型： 解决系统复杂性，例如Cynefin，以更好地理解整体，一个事件的多方面的原因。 响应软件以支持健康的事后审查（PIR）。第一个部分是事件仪表板或时间线，有助于提供 快速查看事件发生前和事件发生期间行为不端的系统;谁 将某些内容运送到生产环境，谁在采取行动，采取了什么行动那个人采取以及整个过程中发生了什么交流 事件。所有这些部分都是有效PIR的关键数据。 第二步也是报告相关：平均确认时间（MTTA） 和平均解决时间（MTTR）。MTTA/MTTR报告支持您的团队可视化并发现有关团队能力的潜在趋势 响应和解决事件。通过全面分析事件的影响 数量—以及您的团队对事件响应软件的使用—您可以确定降低MTTA/MTTR的杠杆，并最大限度地降低成本的停机时间。 第三步是事后审查——不同于 内部PIR，此PIR是一份有形的报告，其中个人，包括领导层，可以快速提取数据的时间范围（不再需要手动聚合电子邮件，松弛，短信和监控系统）的关键学习。此报告有助于 PIR，或“回顾”，并记录长期行动项目。开箱即用PIR报告允许您的团队快速轻松地访问监控数据，系统操作和人工补救，以更好地了解谁、什么、 事件发生的时间、地点和原因。所有这些分析都是必不可少的。团队快速解决生产中的事件，同时提高可靠性 系统解决问题之前发生。 一个事件