赵成的运维体系管理课
赵成
蘑菇街平台技术总监
立即订阅
5576 人已学习
课程目录
已完结 48 讲
0/4登录后，你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 带给你不一样的运维思考
免费
应用运维体系建设 (11讲)
01 | 为什么Netflix没有运维岗位？
02 | 微服务架构时代，运维体系建设为什么要以“应用”为核心？
03 | 标准化体系建设（上）：如何建立应用标准化体系和模型？
04 | 标准化体系建设（下）：如何建立基础架构标准化及服务化体系？
05 | 如何从生命周期的视角看待应用运维体系建设？
06 | 聊聊CMDB的前世今生
07 | 有了CMDB，为什么还需要应用配置管理？
08 | 如何在CMDB中落地应用的概念？
09 | 如何打造运维组织架构？
10 | 谷歌SRE运维模式解读
11 | 从谷歌CRE谈起，运维如何培养服务意识？
效率和稳定性最佳实践 (20讲)
12 | 持续交付知易行难，想做成这事你要理解这几个关键点
13 | 持续交付的第一关键点：配置管理
14 | 如何做好持续交付中的多环境配置管理？
15 | 开发和测试争抢环境？是时候进行多环境建设了
16 | 线上环境建设，要扛得住真刀真枪的考验
17 | 人多力量大vs.两个披萨原则，聊聊持续交付中的流水线模式
18 | 持续交付流水线软件构建难吗？有哪些关键问题？
19 | 持续交付中流水线构建完成后就大功告成了吗？别忘了质量保障
20 | 做持续交付概念重要还是场景重要？看“笨办法”如何找到最佳方案
21 | 极端业务场景下，我们应该如何做好稳定性保障？
22 | 稳定性实践：容量规划之业务场景分析
23 | 稳定性实践：容量规划之压测系统建设
24 | 稳定性实践：限流降级
25 | 稳定性实践：开关和预案
26 | 稳定性实践：全链路跟踪系统，技术运营能力的体现
27 | 故障管理：谈谈我对故障的理解
28 | 故障管理：故障定级和定责
29 | 故障管理：鼓励做事，而不是处罚错误
30 | 故障管理：故障应急和故障复盘
31 | 唇亡齿寒，运维与安全
云计算时代的运维实践 (6讲)
32 | 为什么蘑菇街会选择上云？是被动选择还是主动出击？
33 | 为什么混合云是未来云计算的主流形态？
34 | Spring Cloud：面向应用层的云架构解决方案
35 | 以绝对优势立足：从CDN和云存储来聊聊云生态的崛起
36 | 量体裁衣方得最优解：聊聊页面静态化架构和二级CDN建设
37 | 云计算时代，我们所说的弹性伸缩，弹的到底是什么？
个人成长 (5讲)
38 | 我是如何走上运维岗位的？
39 | 云计算和AI时代，运维应该如何做好转型？
40 | 运维需要懂产品和运营吗？
41 | 冷静下来想想，员工离职这事真能“防得住”吗？
42 | 树立个人品牌意识：从背景调查谈谈职业口碑的重要性
加餐 (4讲)
划重点：赵成的运维体系管理课精华（一）
划重点：赵成的运维体系管理课精华（二）
划重点：赵成的运维体系管理课精华（三）
新书 |《进化：运维技术变革与实践探索》
结束语 (1讲)
结束语 | 学习的过程，多些耐心和脚踏实地
赵成的运维体系管理课
登录|注册
21 | 极端业务场景下，我们应该如何做好稳定性保障？
赵成 2018-02-28
从今天开始，和你分享我对微服务和分布式架构下的稳定性保障的理解。
稳定性保障需要一定的架构设计能力，又是微服务架构比较核心的部分。在陈皓老师的“左耳听风”专栏，以及杨波老师的“微服务架构核心 20 讲”专栏都有非常详细的介绍。所以在我的专栏里，我会结合特定的场景，并着重从运维和技术运营的角度来分享。
我们所面对的极端业务场景
首先，看一下我们当前所面对的极端业务场景，我把它大致分为两类。
1.可预测性场景
什么是可预测性？简单来说，就像电商每年的大促，如 618、双 11、双 12 等等。这类业务场景是可预测的，业务峰值和系统压力峰值会出现在某几个固定的时间点，我们所做的所有准备工作和稳定性应对措施，都是针对这些固定时间点的，比如零点时刻。
峰值压力可预测，就意味着可以提前评估用户访问模型，并根据模型进行压测调优。发现系统中的瓶颈就调优或者扩容，调整完成之后，继续压测，继续调整，直至系统容量达到原来设定的目标。由此可见，在可预测的场景下，与后面的不可预测场景相对比，从准备过程上来说会更加从容。
但是，我们的优化或扩容是有限度的，也就是不会无限度地投入成本，来满足零点这个峰值时刻，让所有用户都能够正常访问。从成本和收益角度来说，这样做是不现实的。
所以，在峰值那个时间点上，当用户流量远远大于系统容量时，我们所采取的措施绝不是再去扩容或优化，因为无论是从时效性、系统稳定性还是成本收益上看，这样做都已经无法满足要求了。
那我们该采取什么策略呢？这里我们采取的策略是在系统承诺容量内，保证系统的核心功能能够正常运行。以电商为例，就是要确保整个交易链路是正常的，用户可以正常登陆，访问商品，下单并最终支付。对于非核心功能，就会通过预案执行功能降级。对于超出系统承诺容量的部分进行流量限流，并确保在某些异常状况下能够熔断或旁路，比如缓存故障，就要马上限流并将请求降级到数据库上。
所以，我们在 618，双 11 和双 12 的零点峰值时刻去访问各大电商网站，很大概率上都会提示系统正忙，请稍后再试，短则 2~3 分钟，长则 5~10 分钟，再去访问，网站功能就一切正常了。这并不代表各大电商网站宕机了，而是其在瞬时超大流量访问压力下采取的一种保护措施，这一点反而说明这些电商网站的大促预案非常完善。
2.不可预测性场景
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《赵成的运维体系管理课》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(2)
feie22对于熔断和降级实现方式，应该是研发主导吧，能举个具体的例子说明下吗作者回复: 技术实现上研发主导，但是场景梳理，产品设计上，还是会依赖运维，运维离线上环境是最近的，这个优势并不是所有开发都具备的。
后面文章还会介绍到，可以关注下2018-02-28 3- 老衲只吃肉老师，我们目前在容量预估上出现问题，请教一下你
（1） 压测是否需要独立的压测环境？如果放到你说的beta环境或者预发布环境，是否会对线上环境的数据库造成影响，因为你的预发布环境和beta环境都是和生产公用一个库。
（2）如果需要独立的压测环境，如何部署？单应用接口压测部署还简单。如果全链路压测部署怎么部署？部署生产一样的？还是把对应链路的都找出来【其实测试人员和运维人员都可能找不出来，因为对业务不熟，还是公司的培训体制问题】，全链路压测，还涉及到多个库，线上都是分开部署的。是否为了达到目的，尽量和线上相同？ 其实整个工程是很复杂的。
是否能给一些建议，目前在这一块遇到了思路上的瓶颈。2019-07-23 1
收起评论