保障业务的 7*24 小时不间断服务并不容易，它需要基础架构、中间件、SRE工作平台等多个层次、工种之间的紧密配合。
客户支持
就算线上系统没有问题，我们的用户仍然会遇到各种麻烦。所以大部分公司都会成立客户支持团队来服务客户。客户支持团队可使用工单、电话或者即时通讯工具来服务客户。
对于客户支持部门，如何来评估他们的业务价值？
很多公司会关注服务质量，即客户对某个会话的服务满意度。但是更重要的是如何减少客户服务的人工成本。
对于客户支持团队收到客户各式各样的问题反馈，大体可以分为这样几类：
- 使用方式类。
- 报故障类。
- 投诉与建议类。（产品本身的优化和改进）
使用方式类
对于“使用方式类”，我们又可以进一步细分为两种情况：
- 一种是用户完全不知道怎么使用我们的产品，需要一步步引导的向导或者DEMO。
- 另一种是接入了我们的产品，但是发生了非预期的结果，需要寻求帮助。
对于第一种情况，我们需要在产品中植入必要的引导。产品帮助文档虽然有，但是我们应该坚信一点是，绝大部分客户的问题应该依靠产品自身来解决，而不是依靠产品文档。
对于第二种情况，在很多时候，出错的信息往往是很难理解的。所以错误信息的呈现，也是需要非常讲究的，我们要将错误信息的表达变得更加贴近用户的语言。甚至，我们可以在错误信息中，给出我们的建议，或者建议文档的链接。
报故障类
对于“报故障类”，也就是用户认为我们的服务出了问题。这个也可以细分为两种情况：
- 一种是我们的服务实际没有问题，而是用户自身的环境出了问题，比如Wi-Fi或者本地运营商的故障。
- 另一种是我们的服务确实有问题，我们如何跟客户之间沟通。
对于第一种情况，我们需要有意识地收集用户请求的整个调用链。依靠Tracing机制，以request id作为线索，获取从客户端到服务端完整的调用链。这样，在报故障时客户端会携带自己的IP 和 Tracing 日志，客户支持人员就可以通过客户IP 和 request id了解这个客户最近都发生了什么事情。
对于第二种情况，这是客户的故障通常会有一个突然的爆发式增长，该什么时候对外宣布事故，及什么时候主动通知客户？
首先，先宣布事故发生，随后找到一个简单解决方案，然后宣布事故结束，要比在问题持续几个小时之后才想起告知客户要更好。
针对事故，我们应当设立一个明确的宣布条件。比如，如下任何一条满足条件，这次事故应该被及时宣布：
云计算
云计算定义了新的交付方式，IT技术供应商不再提供可执行程序或源代码，而是互联网服务。即使在线上出问题的时候，也是IT技术服务商安排技术人员去解决，而不是用户自己想办法解决。
云计算改变了用户与IT技术服务商之间的配合方式。从之前的对交付过程负责，到对服务的质量结果负责，双方的职责更为简单清晰。
云计算发展到今天，大体经历了两个阶段。
资源交付革命
在云计算之前，业务上线过程大体上来说是这样的：
而云计算之后的业务上线被简化为：
交付的IT产品形态并没有发生根本性的变化，以前是物体机，现在是云主机，两者使用上的用户体验并没有很大的差异性。IT资源交付效率发生的巨大变化，主要体现在以下几方面：
容器革命
以容器革命为标志，以Kubernetes为事实标准，迭代的是服务治理的能力。
容器革命带来的变化是：高度自治的服务治理系统对软硬件环境的故障有天然的免疫，我们什么都不用做，系统自己完成自我修复的过程。
今天Kubernetes已经成为DCOS（数据中心操作系统）的事实标准。它带来了以下重要的改变：
- 用户操作的对象不再有机器这玩意，最核心的概念是服务。这也是数据中心操作系统概念的由来。
- 硬件资源池化。软件或服务与硬件环境解绑，可以轻松从一台物体机迁移到另一台物体机。
- 面向逻辑视图描述集群状态。配置中心的数据只体现业务系统的逻辑，不体现物体特性。
服务端的未来
服务治理系统的迭代，最终将让我们达到这样的状态。
- 任何业务都可以轻松达到7*24小时不间断服务。高并发、高可用、高可靠，小菜一碟。
- 做业务都足够的傻瓜化。
- 做一个新的有状态的存储中间件，虽然比做业务麻烦一点，但是，一方面也没有多少新的存储中间件需要做的，另一方面做一个存储中间件有足够便捷的辅助设施。
服务端工程师很可能只是一个阶段性的历史背景下的产物。随着互联网应用开发的基础设施越来越完善，服务端开发的成本越来越低，最终和前端工程师重新合而为一。
