vbaspdelphi的专栏

跟踪故障 提高可靠性的唯一可靠的方法论是建立一个极限，同时不断跟踪改变。 　测试可靠性 如果你还没有亲自试过某件东西，那么就假设它是坏的。 SRE的一项关键指责就是要定量地分析我们维护的某项服务的质量。对服务质量的自信可以用过去的系统可靠度和未来的系统可靠度来衡量。前者可以通过抓取和分析历史性监控信息来活得，后者可以用给予历史数据的预测来量化。 如果我们在短时间内做了大量改动，等待监控数据再积累一段

22 处理连锁故障 如果请求没有成功，以指数型延迟重试。 为什么人们总是忘记增加一点点抖动因素呢？ 连锁故障产生的原因和如何从设计上避免 服务器过载 资源耗尽。某一种资源的耗尽可以导致高延迟、高错误率，或者低质量回复的发生。这些的确是在资源耗尽时应该出现的情况：在负载不断上升到过载时，服务器不可能一直保持完全正常。 CPU。如果CPU资源不足以应对请求负载，一般来说所有的请求都会变慢。这个场景会

刚看了几页，就收获颇丰，非常震撼。 SRE是DevOps在google的具体实践。 一件事儿有可能发生就真的很有可能发生。P01是阿波罗8号上面的一个程序，一旦被人按下，就有可能造成数据丢失，当时是有个程序员的孩子在模拟器上玩儿的时候发现的，这个时候程序员打算修复，但是被上级拒绝了，只能写到playbook里面，一单触发bug，需要重新上传数据。结果，终于有一天，一个宇航员触发了这个P01的程序，差

如果一件事儿顺手可以做，那就做吧，总比回头计划着想着容易。 如果一件事儿重要，哪怕有很多其他的小事儿，另外，着急的事儿也是重要的事儿。 如果一件事儿过去做需要1个小时，那么就试着几分钟做完吧。 尊重别人总是对的，哪怕意见再不合。尊重别人，诋毁别人，这个就像是一个在向银行存钱，一个是在银行贷款，自己掂量掂量吧。 所谓的创新，就是把各种东西杂糅在一起，而且是有序，东西越多越值钱。 如果一次买了

huha~