互联网系统稳定性关注的领域是故障管理领域。故障，通常意义就是系统运行行为和预期不一致，并且造成了实际损失。思考一下，双十一页面白屏，外卖下单的时候订单始终提交不了， 这些在系统背后都对应着一些列错误，例如数据库宕机，应用服务器OOM，I/O阻塞等等。
认真的来看，故障管理领域我们可以分为下面的子领域。
【故障防范】- 防患于未然
一般而言，在系统规模比较小的时候，我们通过规范操作，标准化运营维护行为就可以避免大部分故障。例如，CI/CD的落地，数据库/缓存等规范化使用，应用服务防御性设计等， 这些都可以避免相当一部分的故障发生。
随着系统规模增长，以APPID论，成千上万的APPID出现后，一次业务调用的链条开始设计到十几个服务之后，系统复杂度急剧上升。 这时候，就需要通过演练进行故障的防范。 Netflix的Chaos Engeering就是非常著名的演练工程。随机混乱攻击性测试，让服务持有方不得不在防御性设计，系统自愈能力上下功夫，以提高服务的可用性级别，进而增强整个系统的鲁棒性。
【故障感知】- 上天入地的监控系统
Google为整个互联网世界贡献了无数理论瑰宝，其中Dapper指导了大量分布式监控框架的实现，例如Pinpoint，Zipkin，点评老吴的CAT, 我们也有etrace。万变不离其中，这是应用层上trace系统，可以观察调用链，异常，接口QPS，调用成功率等等。
Infra层上业界也有诸多开源框架。总的来说，基本架构为：采集器+时序数据库+Dashboard框架，例如：statsD/collected + graphite + grafana, prometheus, open-falcon等等。
接入层的监控相对比较困难，CDN的可用性，网络接入点的访问成功率，现在可以采用分布式的APM工具进行各地采样，实时反馈当地网络访问的稳定性。
【故障触达】- 即时消息和电话
故障响应的效率高低取决于故障是否可以及时触达应急响应人员。 OnCall流转，消息确认，故障处理状态更新和同步这些是常规的手段。而在实践中，故障定位和排障效率最高的方式是IM群，或者是会议室集中的方式。 原因是信息的及时同步。
故障触达时所携带的故障发生上下文极为重要。 例如，故障发生时的变更，异常指标，初因定位，甚至可以通过算法分析获取有效的根因范围。
【故障止损】- 第一时间应该选择的动作
故障发生的不可预知性决定了我们需要有一整套的故障响应预案，而且应该是验证过的预案。 预案应该至少包含：降级（接口，功能，系统能力），回滚（代码，版本），双活切换，备用机房等。
造成线上问题的原因目前来看主要有两大类： 变更（配置，版本等），容量不足（积累，突发事件等）。无论哪一种，我们在应对时，第一选择都应该是经过演练的预案。
【故障复盘】- 有效改进
故障在结束后进行的复盘是整个故障管理完整闭环的最后一环。 对事不对人，首先关注技术缺陷，其次关注标准操作流程是否完善，最后才是追责。
关于故障复盘，我们在乎的是改进的落地效率。因此，明确改进方案，时间，检查点等，十分有必要。
此外，故障信息是否能自动化收集，分类，也体现了完整的技术运营技术能力。
总结：
互联网系统的系统稳定性最终反应到人们面前的是故障发生率，故障级别等等。因此，提高系统稳定性就是要提高故障管理能力，三分治理，七分自动化（智能化）。
