正文共： 2146字，预计阅读时间： 8分钟
《谈谈稳定交付（一）——研发过程》中提到的系统稳定，从软件分层、岗位过程和运行状态来看，用这三句话概括：
符合预期的功能交付
不中断的使用体验
具备持续交付能力的团队
这篇来聊聊第二点，如何实现“不中断的使用体验”。
从代码上线的那一刻起，产品和研发真正进入了验证阶段，不管是人还是机器，作为用户都在实时地反馈着运行的体验。研发经常面对老板灵魂拷问的“稳定”，也大多是用户核心体验遭受损失的时候。
人总是难免出错的，尽善尽美的设计不论从产品还是研发来说，在时间和成本的制约下都不可能达到。从解决问题的角度，尽快识别体验受损，先于问题带来负面影响或扩大范围就修复，是一个更容易收敛的方向。
那么，如何识别体验受损。
用户投诉时，影响就已经扩大。从经验看，一个投诉背后可能一千个用户已经受影响。但自己人不可能每时每刻都盯着产品使用，如果用户是机器，投诉无从提起。一个已经被证明的方式是数字度量。
用户的行为体现着他们的体验，行为可以用数字来度量。产品承载的是业务，因此核心体验就是核心功能的度量。单位时间内的支付笔数或登录数、核心使用路径的转化漏斗等等，都可以从核心功能中加以识别并数字化。
有了业务的量化，如何体现在系统中？
在研发面试中有一道经典问题：“浏览器中输入URL后回车到页面完全展示，发生了什么？”这个问题的回答能够体现基于业务和架构思考的全面性，继续基于回答的深挖，可以得到技术深度的细节验证。
这个问题体现的是，系统承接的业务实现，就是业务数据的流转过程。用户体验是否中断，就是数据流转是否中断，或者数据流速带来的延迟是否匹配用户的忍耐范围。
到这里，我们有了第一个方向——一切尽在掌握：识别用户、定义核心功能和路径、梳理业务数据流转过程、摸排可能带来数据中断的点、摸排计算或传输延迟的场景。
有了方向，接下来的问题是如何实现。数据中断和数据延迟分别代表的是高可用的两个场景：容灾和性能，这也代表着工作实现的两个目标。
同样的，任何工作开展前，都需要基于目标进行度量，或者是定义度量的方向。通常的定义有：容量、可用性、时延、错误率、是否人工。人工这一项经常会被忽略，这是工程产品化的基石，背后意义是在问题出现时的处理速度，能否深入演进至系统自愈。
度量后的关注点是波动，任何数据波动都可能是稳定性的隐患，基于波动去定义场景、问题和解决方案。而平均数据的变化，就是体现团队工程能力最佳的注解。
有了目标和度量，需要具体展开工作了。一个是梳理，一个是应对。应对在所有研发团队日常中多多少少都有体现，核心点在于梳理是否全面，是否做到一切尽在掌握，抓住数据流转这个方法就能够保证线的完整度。唯一要注意的是梳理落实在应用级，避免业务流在集群中的流转被遗漏。
数据流完整了，也需要对每个点的全面性做确认。通常我们会从IaaS、PaaS、SaaS或业务层来区分注意点。业务规模小一些的，或者完整基于云原生的，PaaS的的要素可能会合入IaaS或者业务层考量。
IaaS层是硬件基础，四大硬件点：内存、网络、磁盘、CPU。还有物理部署，属于架构的范畴，但很容易被忽略。
PaaS层根据业务不同差异较大。一方面是业务中台，背后是服务化管理。一方面是广泛被应用的大数据和流批计算套件。要点是集群、应用、数据。如果基于云原生，要省去很多动手的工作，同时风险也被转向外部开放，在应对中需要在业务层多加考虑，同时要和云厂商建立深度的合作内容。
PaaS中容易被忽略的有两点。一个是开源套件中的管理应用，很容易在业务流中忽略掉服务治理流。在服务治理流中的数据和应用是否具备高可用，会在意想不到的时候出现一个大坑。另一个是数据中的状态，与持久化的数据和配置相比，状态数据会影响到服务完整恢复的周期，由于广泛应用开源，通过演练能更容易暴露出关注点。
业务层方面，除了开篇提到的业务度量，确认核心业务和业务等级能够极大控制解放方案的复杂度。
有了完整的梳理，应对的工作就是确定性的。工程方面，架构、监控、灰度（无感发布）、弹性伸缩、限流、熔断，基于不同的业务场景都有非常成熟的解决方案，取舍在于演进过程。一些短期难以自动化或者复杂度必须人介入的，就需要有预案的准备，并辅以流程制度来减少人为出错的场景或者范围。
上述是服务器角度，web或移动端方法类似，可以参考《移动互联网技术质量体系的理解》。从中断和延迟看，分别有如下的方向，由于数据体量可控，因此直接抽出一些北极星指标更容易集中收敛。
实现不中断的体验，体现的是研发团队的工程能力，在不同业务水平下，需要适度进行工程建设。虽然一个有追求的团队目标是全面的工程产品，但一口吃不成胖子。在过渡期采用适当的流程规范，以人力为建设过程提供缓冲是必要的。
最后基于这个体系，附上以我们团队情况建设的脑图供大家参考。
拖地先生，从事互联网技术工作，在这里聊聊日常的实践和心得。往期推荐：
如果对你有帮助，让大家也看看呗~
