Hunter的大杂烩 技术学习笔记

在上篇《大规模互联网服务部署》中，提到的所谓“优雅降级”，在tc内部称为柔性，简单意义上就是在系统过载的时候，通过业务体验降级（减少提供的功能），限制并发使用用户数量等方式，将有限的资源提供给基础业务，来满足用户基本需求；

一般做传统软件业都是无法接受这种结果的，但是在互联网业里面，似乎是家常便饭，无论是ebay还是amazon，都认为是availability是最重要的，而Percona Performance Conference中Morgan对Availability的解释更加简单：

(more…)

摘自《程序员》2008.8

声明：本文所有权属于《程序员》杂志，如本转摘有任何产权方面的问题，请及时联系本人，谢谢！

============================================= 

大规模服务设计部署经验谈(下)

文／J a m e s H a m_lto n译／赖翥翔

运营和功能计划

    要高效地运营服务，关键在于让构建的系统有效地消除运营团队的绝
大部分管理交互。这样做的目标，是让一个高度可靠的24 x 7小时运行的
服务，由一个8 x 5小时工作的运营团队就足以维护起来。
    不过世事难料，一组或者多组系统救火不成，无法恢复上线的事情是
时有发生的。在熟知这些可能性的情况下，实现把损坏的系统标为当机这
个过程的自动化。依赖运营团队手动更新SQL表或者使用特别的技术移
动数据，都会招致灾难。与故障交战正酣时，往往错误也容易迭出。先预
估运营团队需要采取的补救措施，然后预先编写和测试这些过程。一般来
说，开发团队必须将紧急恢复措施自动化，而且他们必须对之进行测试。
显然，百密一疏，并非所有故障都能预估到，但通常一小组恢复措施就可
以用来恢复多种类型的故障。从根本上说，要构建并测试可以根据灾难的
范围和性质以不同方式使用及结合的“恢复内核”。
    恢复脚本应当在生产环境中进行测试。这里有一条普适规则，即如果
没经过频繁测试，什么程序都无法正常工作，因此不要实现团队没勇气使
用的任何东西。如果在生活环境中测试风险过高，那么脚本就没有达到能
在紧急情况下使用的标准，或者说在紧急情况下不安全。这里很关键的一
点是，灾难总是可能发生的，由无法按预期结果运行的恢复步骤所导致的
小问题酿成大灾难的例子是屡见不鲜的。要预见到这样的事件，设计出自
动化措施，让服务回复正常状态，而不至于丢失更多数据或损耗更多正常
运行时间。
    ◆让开发团队承担责任。Amazon也许是沿着这条道路贯彻得最坚定最矢
志不渝的公司了——他们的口号是“你创建就该你管”。这样的立场也许要比
我们会选择的更坚定一些，但这显然是一个正确的大方向。如果不得不频繁在
深更半夜给开发团队打电话，那么你就得做出一套自动化方案。如果需要频繁
给运营团队打电话，那么通常的反应就是要增加运营团队的人手。

(more…)