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

对纠正措施必须进行追踪，直到执行完成。要记住，在纠正措施没有得到完全执行之前，事故重发的风险会一直存在。必须确保执行人和完成日期都落实到位，而且执行人要一直负责到底，哪怕原来的事件已逐渐成为过去。要在错误追踪系统或其他类似工具中将其标记为高优先级项目，这样有助于确保正确的信息都记录下来了，从而避免丢失。
改正性活动常常会和开发活动竞争资源的优先权属。对于网站的稳定性和新功能，在重要程度上给予同等对待，在这点上取得管理层的支持，非常重要。声称网站稳定性最重要的公司，对于确保改正性活动的完成，大有帮助。纠正措施要根据能够防止的类似事故的数量来确定优先顺序，假如一项措施只能纠正当前发生的事故，而另一项措施却能修复一批可能的类似事故，则肯定后者会得到更高的优先级，从而工程部门也会将精力集中在这项措施上。
另外，确保将事后分析的数据录入到最终工具中，为事件赋予一个根本原因类别，以便对其进行数据挖掘，从而管理层也能够对长期趋势进行识别。我们使用这样的事故类别，如硬件失效、与更新有关、容量/流量事故、已存在的软件错误，对事故进行归类。使用历史数据，对申请哪些资源、使用什么样的工具、启动什么样的自动化项目进行更加明的策。要将资源用在多发的事故类别上，从而在整个公司范围内有组织地降低这些事故的发生率。有宕机的历史数据，对于调整有难度、耗资源的项目是特别有用的。

经过了多年的事后分析经历，我发现了一些内容，你可能会考虑将其用于改正性活动，我称其为网站可操作性。
消除单点故障
硬件可能，也将会，失效。使用冗余进行防护。不要让硬件失效成为发生影响客户的事件的原因。
容量规划
了解网站将来的容量需求。将容量规划建立在主要的约束条件(如CPU、内存、I/O及存储)的整体利用率的基础上，而不要建立在次要约束条件(如用户数量)的基础上。对于这些你所需要的东西，要在需要之前，就做好预备。
监控
监控对于检测和诊断事故是非常重要的。本书的其他章节对于监控已经提供了大量的建议。
发布管理
从历史上看，更新是引发事故的主要原因。要确保你的发布过程具有适当的质量控制，要考虑这样的实现概念，如自动测试、预演环境、受限的生产部署、暗启动(部署代码，但不激活其功能，直到证明代码是稳定的)以及立即回滚的能力。
运维架构复审
在发布之前，对架构进行复审，对新的发布或产品在生产环境中将会如何执行进行审查，要考虑可维护性、失效场景、对事件的响应以及架构的可靠性和可伸缩性。
配置管理
随着系统的增长，生产环境中的配置也会变得越来越复杂。无法理解更新对生产配置的意义往往会导致人为事故的发生。有一个易懂、好用的配置管理系统，将有助于工程师避免这些无意中发生的问题。请参阅本书第5章，查看更多的建议。
随时待命和提升过程
识别问题，尽快提交给能够解决问题的人。
不稳定的组件
标识并修复那些发生过崩溃以及人为事故的软件组件，将其标识为高优先级，即使它们易响于手工修复。这些手工修复累积起来，会对客户体验、伸缩能力以及效能都造成负面影。
要采取积极主动的行动，确保网站建设内容的可操作性，能避免很多痛苦的事后分析。

分享题目：事后分析的后续工作有哪些？
当前路径：/news37/146187.html

成都网站建设公司_创新互联，为您提供建站公司、手机网站建设、服务器托管、云服务器、全网营销推广、网站建设

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联