你好呀，我是 Bella 酱～
“又不是不能用，能用就行。”“又不是不能跑，能跑就行。程序和人有一个能跑就行。”
置信很多同学都听过这 2 句话。乍听没故障。 编程 3 部曲，“make it run，make it fast，make it better”。 上述 2 句话，我将其归结为“make it run”这一个阶段，单看这一阶段，没有问题，然而若始终在这一阶段，那就有问题了。
什么是稳定性呢？我将其归类到“make it better”这个阶段。 稳定性是通过一系列伎俩提前发现问题，力求将问题扼杀在襁褓中；稳定性要求在问题产生时，先于业务感知问题，解决问题，进而将问题影响面降至最小；稳定性要求问题产生后要有复盘，复盘哪里能够改良，以防止再次发生此类事件。简言之，稳定性就是为了保障系统失常运行，保障业务如丝般顺滑，保障数据准确无误。
稳定性并非只可能做一些零零散散的事件，稳定性也是有章可循的，有体系化的办法的。 本文将从机制管控、监控告警、梳理零碎危险点、保命措施、线上问题应急机制、故障演练、预先复盘、宣讲这 8 个方面来解说业务团队如果在日常工作中做稳定性，堪称是涵盖了事先、事中、预先的方方面面。
1. 机制管控
所有事件，能上零碎就上零碎，靠人来运行危险是极高的。这个情理，我置信很多同学都是明确的。稳定性保障亦是如此，通过一系列机制和零碎强管控来标准日常工作中的一些行为。
上面这些都是能够参考的：
1）分支公布必须 merge origin master 分支的代码。
2）分支公布必须 cr，且必须通过测试人员批准才可公布。开发、测试不可为同一人，除非测试认可开发自测即可。公布人员和 cr 人员不可为同一人。
3）分支公布须要在零碎中有记录，内容至多蕴含公布工夫、公布分支、公布内容、影响面、是否测试通过等等。
4）制订公布窗口，窗口外的工夫如果须要公布，则须要走审批，审批人员能够是老板，也能够是团队内负责稳定性工作的人员，也能够视团队状况设置为其余的人员，例如团队外围开发等。制订公布窗口次要是为了避免早晨或周末公布的状况，防止公布呈现问题时响应和解决不及时。
5）制订公布流程，次要是服务器环境这方面的，例如公布零碎设置分支必须先在日常环境部署胜利，能力部署预发；只有预发环境部署胜利，能力部署线上；公布线上时，必须先在 beta 环境部署胜利，且察看规定工夫内，能力持续公布至线上；线上至多分几批来公布，每一批至多察看多久等等。
6）禁止流量一刀切，必须有逐渐灰度的过程。通过公布机器的占比也好，通过业务中带灰度标的形式也好，必须要逐渐灰度，禁止流量一次性全副切换。逐渐灰度的过程是一个验证性能，裸露问题的过程，灰度范畴是可控的，能够将灰度范畴告知业务方，以便呈现问题时，业务方晓得哪里有了问题，而不是摸不着头脑。
7）数据修复必须通过工具来操作，工具要可获取以后操作人员，操作工夫等，工具要具备 check 数据修复正确性的能力，工具的每次应用要在后盾有记录，不便当前查看历史操作记录。
2. 监控告警
监控告警的意义在于先于业务方发现问题，能够极大的进步响应速度，更快的开始定位问题。问题一旦定位到，影响面也就能够评估进去了，此时应该思考如何疾速止血，将影响面降至最低。
监控告警设置时有以下几点须要留神：
1）告警范畴。切忌只告警给某个人，这样危险太大，例如当这个人在洗漱时就可能会错过告警信息。能够建一个钉钉告警群，把和这个业务相干的同学都拉进去，以及团队内负责稳定性的同学、老板等等。这样防止了“单点不可用造成服务宕机的状况”，即便一个人错过了告警信息，还有其他人，只有有人看到报警信息并解决就 ok。
2）告警优先级。不同状况须要设置不同的告警优先级。举一个简略的例子，以服务成功率来说，继续 3 分钟成功率低于 97%，能够告警至钉钉告警群；继续 5 分钟成功率低于 97%，能够短信告警至订阅人；继续 10 分钟成功率低于 97%，能够间接电话订阅人。
3）告警内容。这个须要视团队服务现状而定。一般来说，DB 层面的监控告警、服务成功率层面的监控告警、服务解决失败数的监控告警、机器层面的监控告警等是必须的。DB 监控告警例如 CPU 使用率、连接数、QPS、TPS、RT、磁盘使用率等。机器层面的监控告警例如 CPU 使用率、load、磁盘利用率等。服务成功率的告警配置时须要思考继续时长。
4）告警有限性验证。这点是十分要害的，如果告警有效，那上述告警范畴、优先级、内容这 3 个工作就是徒劳的。如果告警设置的阈值太高，那告警将起不到任何作用。如果告警设置的阈值太低，那每天都会承受到大量的告警，长此以往，就对这些告警困倦了，等哪天狼真的来了，人们可能曾经不置信了。通过压测，摸清了服务、DB、机器等的基线后，依据基线设置的告警是最可信的。若后期没有压测，能够先察看一下日常的水位，将告警阈值设置低一些，前面再依据告警状况缓缓调整告警的阈值。
3. 梳理零碎危险点
古人云，知己知彼，百战不殆。为何要知彼呢？知彼，你才晓得他的弱点。做稳定性亦是如此。理解零碎，你才会晓得零碎的危险点在哪里。当然，齐全理解一个零碎，是须要投入大量的工夫和精力的。今人又云，小人性非异也，善假于物也。那梳理零碎危险点的后期，你能够借一下你可恶的共事们的力呀～找到对应利用的 owner，理解一下现状，以及潜在的危险点，以及是否有应答措施。
在梳理零碎危险点时，须要关注以下几点：
1）链路是否闭环。这点是十分要害的，因为如果是零碎层面的缺点，那影响面肯定是很大的。梳理链路是否闭环时，须要你跳出开发的思维，以扫视一个产品的角度来思考，这个产品是否能够在任何状况下失常的 run 起来。如果发现零碎不闭环，肯定要第一工夫告知产品和老板。而后再从产品的角度来思考如何解决这个问题，须要开发什么性能才 ok，而后再将此作为高优先级的开发工作去进行排期修复。
2）慢 SQL。慢 SQL 的威力是十分大的，一条慢 SQL 的执行可能会间接拖垮一个库，此时如果再有其余 SQL 申请执行，那其余 SQL 的执行耗时也会放大很多，这个时候，对于开发人员来说往往难以分辨哪些才是真正的慢 SQL。此时须要静下心来依据工夫点来缓缓查找真正的慢 SQL，或者求助 DBA 同学，业余的同学做业余的事件，后果会更牢靠，耗时也更短一些。如果是本人找到了慢 SQL，最好和 DBA 同学求证一下本人查找的后果是否正确，免得错过了真正的慢 SQL。
3）外围利用、非核心利用是否相互影响。不同重要等级的业务，应该在物理维度间接隔离。常说的读写拆散也是这个情理，读写申请别离拜访不同的机器组，免得相互影响。除此之外，还有 DB 维度的拆散。
4. 保命措施
机制管控、监控告警、梳理零碎危险点都是为了避免问题的产生。可是，常在河边走哪有不湿鞋？如果线上产生了问题，要怎么疾速止血呢？这个时候，就须要日常工作中筹备好一些保命措施了，如果等到问题产生时，再去做筹备，就有点太晚了。
那有哪些保命措施呢？
1）限流。尽管限流会导致一部分申请失败，然而他会加重服务压力，加重 DB 压力呀，在有些时候是能够用来保命的。罕用的限流工具有 Sentinel。日常工作中，能够先在 Sentinel 控制台配置好限流值，问题产生时，间接推限流开关即可。能够针对集群限流，也能够对单机配置限流，这个要看具体的业务场景和需要了。能够对所有利用起源进行限流，也能够对某些特定利用配置限流值，这个也是看具体的需要了。
2）降级。降级分为有损降级和无损降级。有损降级是业务感知的，无损降级只是技术侧的，例如查问从一个数据源降级为另外一个备用数据源，业务侧毫无感知。有损降级，比拟典型的例子就是春晚抢红包流动，百度间接布告告诉元旦当晚，百度云盘登录注册降级，以保障春晚抢红包流动顺利进行。对于有损降级来说，要在日常工作中就定义好，何种状况下，零碎达到什么指标了，才能够进行有损降级。免得问题产生时，思考过少，间接降级，导致更重大的问题产生。
3）切流。当一个机房的服务器产生了网络问题或硬件设施问题或其余导致机房不可用的问题时，能够切流至其余机房。当一个数据源不可用时，也能够切流至备用数据源。这些都能够减小问题的影响面，或解决问题。
4）布控。如果是和内部用户打交道的服务呈现了问题，能够通过业务方或其余形式告诉内部用户，通知他们此时零碎产生了问题，相干同学正在解决中，以安抚他们，而不至于让内部用户一脸懵逼，手足无措。一些官网号通过发微博的形式告知用户，也是布控的一种。
5）上下游、DBA 等的联系方式。有时候可能并非本人零碎的问题，而是上下游零碎异样，间接导致本人零碎的成功率上涨，这个时候，把握上下游合作方同学的联系方式就很重要了，能够疾速告诉对方，让对方染指排查。有时候也可能是 DB 产生了问题，须要 DBA 帮助解决才行，所以把握 DBA 的联系方式也是十分重要的，DBA 同学一个小小的命令可能就能援救你于水火之中。
限流、降级、切流、布控等保命措施均须要清晰的定义零碎哪些指标达到什么值时，才能够执行这些措施。这样当问题产生时，能够疾速做出决策判断，也防止了使用不当造成更大问题。
5. 线上问题应急机制
真的有线上问题产生了，怎么办？莫慌，越慌越乱。
首先，须要做到疾速响应，表明曾经有人在定位问题了。问题定位到之后，应该将如何疾速止血放在第一位。此时就能够将上述的保命措施用上了。如果保命措施都用不到怎么办？只能采取其余措施了，通过公布解决也是一种形式。
一个人是无奈很好的疾速应急的。须要有通讯员和内部沟通，及时汇报以后停顿；须要有解决人定位问题，评估影响面，给出倡议；须要有决策人员，可能是团队内稳定性负责人，可能是老板、也可能是业务方等，决策如何疾速止血。达成统一决策后，解决人依照决策执行即可，通讯员放弃和内部及时的沟通。
6. 故障演练
故障演练的目标是模仿故障产生时，大家的实在反馈，以及是如何解决问题的。所以故障演练不要提前告知团队同学，更不要提前告知是何种线上问题，否则演练将毫无意义。当然，故障演练还应该把握好度，免得影响到线上业务。
7. 预先复盘
线上问题产生后，无论大小，都应该有相应的复盘，小问题能够是小范畴的复盘，大问题能够进一步扩充复盘参加人员的范畴。
次要复盘哪些内容呢？
1）何时发现问题？
确定工夫点
2）哪种形式发现的问题？监控告警还是业务方反馈？
以确定监控告警是否无效，是否有可优化的空间。
3）何时响应问题？
以确定响应是否及时，是否有可优化空间
4）何时定位到问题？
以评估对系统的相熟度，或对线上问题的响应解决能力。有的同学可能是因为对系统不够理解，所以须要耗时很久才可能定位到问题；有的同学可能是因为遇到事件时，或低压下，心理素质不够，导致慌手慌脚，所以才耗时比平时更久。两种状况，可晋升的能力是不同的。
5）有无疾速止血措施？
例如限流、降级、切流等。可看平时保障工作是否到位。如果发现有缺失，则能够记为一个 action，前面工作中把这一块给补上。最好的形式是，同步梳理下，零碎中是否还有其余缺失的疾速止血措施，并一起做掉。
6）须要上下游或 DBA 染指的状况，协同是否顺畅？
以评估协同沟通是否有可晋升的空间，毕竟须要上下游或 DBA 染指的状况，如果能够疾速分割到对应同学的话，是能够节俭很多工夫的，有助于更疾速的解决问题。
8. 宣讲
稳定性素来都不是一个人的事件，它关系到每一位同学，也是每一位同学应该铭刻于心的事件。
在接需要时，须要思考需要是否正当，链路是否闭环。
在写代码时，须要思考代码的健壮性，语法应用是否正确，是否在写慢 SQL。
在公布时，须要思考测试是否通过，是否在公布窗口期，是否有灰度策略，公布时若发现问题应如何解决，是否可回滚等等。
在线上问题产生时，如何疾速应急也是每一位同学都应该理解的。
一些宣讲还是很有必要的，以帮忙每一位同学更好的理解本人应该如何做以保障系统的稳固。
好啦，我是 Bella 酱，一个在 BAT 写代码的妹子，欢送关注我集体微信公众号（ 公众号：Bella 的技术轮子 ）一起学习一起成长！明天的分享就到这里，咱们下期见～