背景
《SRE Google运维解密》里提到SRE自动化系统的一个bug导致几乎所有的数据中心机器被成功下线并进行硬盘擦除。当然这本书出版之后又业界也进行了很多的演进。在我们团队现在很难发生这样的事情。因为团队内人人要遵循的一个设计原则是：原则上禁止批量操作。如需批量，需要有审核流程。批量设置上限。
这个原则在我以后会发布的系列文章《架构设计「三大纪律八项注意」》中也会介绍一些。今天先从另一个角度系统的看这个问题。
配额管控策略-逻辑管控
我所在的HULK调度系统团队因为从大的方面将调度系统分成资源和调度两个方面，所以衍生出来就有物理和逻辑两个层次。在运用方面可以用一个简单的例子来解释：秒杀。
在秒杀场景中，假设实际物品库存有10件。这是一个物理概念，被别人订走一个少一个。但是秒杀开始的时候，有100个请求过来，每个人都不知道下一时刻库存有多少。这时候实时感知物理上有多少库存来给用户反馈显然是不合适的。这时候就衍生出来逻辑的概念。
这个逻辑的库存可以用一个计数器来实现，或者是漏斗，不重要。关键是逻辑库存要卡住流程，不能让物理库存为负数。
在我们HULK调度系统中，涉及到硬件资源，一个策略是为应急场景留下一定配额。对于不同的来源的请求给予不同的配额以避免一个来源方未知问题导致所有的资源耗尽。
总结一下上面提到的策略：物理感知是必要的，但是不能代替逻辑管控。逻辑管控包括：不能让资源总量低于实际；必要时留有配额；针对不同来源需要不同的配比。
配额管控策略-批量管控
「核心流程都需要是点对点的。保障流程原则上禁止批量操作。如需批量，需要有审核流程。批量设置上限。」这是我们团队的一个重要的设计原则。
举个我们团队的具体应用：是人都是要死的，是机器都是要坏的。机器故障既然不可避免，那就需要进行自动化处理。HULK调度系统这边有专门的物理机宕机流程。这个流程在设计中做了下面两件事情：1是限量，2是限速。
限量：
按照物理机宕机率统计数据来看，一天理论上不可能有100台物理机同时宕机。如果1天中宕机数超过一定配额，则停止自动化宕机处理，并发出异常报警。
限速：
如果1秒中100台机器同时宕机，更可能发生的事情是网络抖动之类的其他现象。而非真宕机，所以此时也会停止自动化宕机处理，并发出异常报警。
总结
与用户一同工作，以像用户一样思考 --《程序员修炼之道》
相关阅读