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

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

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

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

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

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