事后分析的后续工作有哪些？

发布：2018-06-23 14:40:37 浏览：3140

对纠正措施必须进行追踪，直到执行完成。要记住，在纠正措施没有得到完全执行之前，事故重发的风险会一直存在。必须确保执行人和完成日期都落实到位，而且执行人要一直负责到底，哪怕原来的事件已逐渐成为过去。要在错误追踪系统或其他类似工具中将其标记为高优先级项目，这样有助于确保正确的信息都记录下来了，从而避免丢失。

改正性活动常常会和开发活动竞争资源的优先权属。对于网站的稳定性和新功能，在重要程度上给予同等对待，在这点上取得管理层的支持，非常重要。声称网站稳定性最重要的公司，对于确保改正性活动的完成，大有帮助。纠正措施要根据能够防止的类似事故的数量来确定优先顺序，假如一项措施只能纠正当前发生的事故，而另一项措施却能修复一批可能的类似事故，则肯定后者会得到更高的优先级，从而工程部门也会将精力集中在这项措施上。

另外，确保将事后分析的数据录入到最终工具中，为事件赋予一个根本原因类别，以便对其进行数据挖掘，从而管理层也能够对长期趋势进行识别。我们使用这样的事故类别，如硬件失效、与更新有关、容量/流量事故、已存在的软件错误，对事故进行归类。使用历史数据，对申请哪些资源、使用什么样的工具、启动什么样的自动化项目进行更加明的策。要将资源用在多发的事故类别上，从而在整个公司范围内有组织地降低这些事故的发生率。有宕机的历史数据，对于调整有难度、耗资源的项目是特别有用的。

经过了多年的事后分析经历，我发现了一些内容，你可能会考虑将其用于改正性活动，我称其为网站可操作性。

消除单点故障

硬件可能，也将会，失效。使用冗余进行防护。不要让硬件失效成为发生影响客户的事件的原因。

容量规划

了解网站将来的容量需求。将容量规划建立在主要的约束条件(如CPU、内存、I/O及存储)的整体利用率的基础上，而不要建立在次要约束条件(如用户数量)的基础上。对于这些你所需要的东西，要在需要之前，就做好预备。

监控

监控对于检测和诊断事故是非常重要的。本书的其他章节对于监控已经提供了大量的建议。

发布管理

从历史上看，更新是引发事故的主要原因。要确保你的发布过程具有适当的质量控制，要考虑这样的实现概念，如自动测试、预演环境、受限的生产部署、暗启动(部署代码，但不激活其功能，直到证明代码是稳定的)以及立即回滚的能力。

运维架构复审

在发布之前，对架构进行复审，对新的发布或产品在生产环境中将会如何执行进行审查，要考虑可维护性、失效场景、对事件的响应以及架构的可靠性和可伸缩性。

配置管理

随着系统的增长，生产环境中的配置也会变得越来越复杂。无法理解更新对生产配置的意义往往会导致人为事故的发生。有一个易懂、好用的配置管理系统，将有助于工程师避免这些无意中发生的问题。请参阅本书第5章，查看更多的建议。

随时待命和提升过程

识别问题，尽快提交给能够解决问题的人。

不稳定的组件

标识并修复那些发生过崩溃以及人为事故的软件组件，将其标识为高优先级，即使它们易响于手工修复。这些手工修复累积起来，会对客户体验、伸缩能力以及效能都造成负面影。

要采取积极主动的行动，确保网站建设内容的可操作性，能避免很多痛苦的事后分析。