6 运营和功能计划
要高效地运营服务，关键在于让构建的系统有效地消除运营团队的绝大部分管理交互。这样做的目标，是让一个高度可靠的24 x 7 小时运行的服务，由一个8 x 5小时工作的运营团队就足以维护起来。
不过世事难料，一组或者多组系统救火不成，无法恢复上线的事情是时有发生的。在熟知这些可能性的情况下，实现把损坏的系统标为当机这个过程的自动化。依赖运营团队手动更新SQL 表或者使用特别的技术移动数据，都会招致灾难。与故障交战正酣时，往往错误也容易迭出。先预估运营团队需要采取的补救措施，然后预先编写和测试这些过程。一般来说，开发团队必须将紧急恢复措施自动化，而且他们必须对之进行测试。显然，百密一疏，并非所有故障都能预估到，但通常一小组恢复措施就可以用来恢复多种类型的故障。从根本上说，要构建并测试可以根据灾难的范围和性质以不同方式使用及结合的“恢复内核”。
恢复脚本应当在生产环境中进行测试。这里有一条普适规则，即如果没经过频繁测试，什么程序都无法正常工作，因此不要实现团队没勇气使用的任何东西。如果在生活环境中测试风险过高，那么脚本就没有达到能在紧急情况下使用的标准，或者说在紧急情况下不安全。这里很关键的一点是，灾难总是可能发生的，由无法按预期结果运行的恢复步骤所导致的小问题酿成大灾难的例子是屡见不鲜的。要预见到这样的事件，设计出自动化措施，让服务回复正常状态，而不至于丢失更多数据或损耗更多正常运行时间。
6.1 让开发团队承担责任。
让开发团队承担责任。Amazon也许是沿着这条道路贯彻得最坚定最矢志不渝的公司了——他们的口号是“你创建就该你管”。这样的立场也许要比我们会选择的更坚定一些，但这显然是一个正确的大方向。如果不得不频繁在深更半夜给开发团队打电话，那么你就得做出一套自动化方案。如果需要频繁给运营团队打电话，那么通常的反应就是要增加运营团队的人手。
6.2 只进行软删除。
只进行软删除。绝不要删除任何东西，只可以把这些东西标记成删除状态。在有新数据进入时，即时将请求记录下来。每两周（或者更长时间）保存一份所有操作的历史记录，可以有助于从软件或者管理上的错误进行恢复。如果有谁犯了错误，忘记在delete 语句加上where 子句（这样的错误以前发生过，以后也可能再犯），那么数据的所有逻辑拷贝都会被删除。不管是RAID还是镜像都无法防止这样的错误。具备数据恢复的能力，可以让原来会十分令人窘迫难堪的大问题转化为一个小到甚至可以忽略不计的小障碍。对于那些已经做过离线备份的系统，只需要从上次备份开始记录进入服务的附加数据就可以了。不过谨慎起见，不管怎么说我们还是推荐进行更进一步的备份。
6.3 跟踪资源分配。
跟踪资源分配。了解性能规划的额外负载所带来的开销。每个服务都需要开发出一些使用的度量标准，例如并发在线用户数量、每秒用户访问数或者其它合适的标准。不管度量标准是什么，在这个负载度量和所需的硬件资源之间肯定存在一个已知的直接相互关系。估算的负载数字应当由销售和营销部门提供，并在性能规划过程中为运营团队所使用。不同的服务会拥有不同的变更速率，也要求不同的订购周期。在我们开发过的服务中，我们每90天更新一次市场预报，每30天更新一次性能规划和订购一次设备。
6.4 每次变更一样东西。
每次变更一样东西。在出现麻烦时，应当每次只向环境应用一个变更。这条准则看起来显而易见，但我们也看见过许多场合里出现多个变更，导致起因和效果不能吻合。
6.5 使所有资源都可以配置。
使所有资源都可以配置。在生产环境中，任何存在变更需求的资源，都应无需经过任何代码改变，就能在生产环境中进行配置和调优。即使你没什么好理由说明为什么某个值会有必要在生产环境中更改，只要实现起来没什么难度，还是让它可变更好些。不应在生产环境中随意更改这些开关，而应该使用为生产环境所规划的配置对整个系统进行彻底测试。不过，在出现生产环境问题时，比起编码、编译、测试再部署代码变更的过程，进行简单的配置变更永远是更加简单、安全和快速的。