浅谈服务治理第三篇

保障业务的 7*24 小时不间断服务并不容易，它需要基础架构、中间件、SRE工作平台等多个层次、工种之间的紧密配合。

客户支持

就算线上系统没有问题，我们的用户仍然会遇到各种麻烦。所以大部分公司都会成立客户支持团队来服务客户。客户支持团队可使用工单、电话或者即时通讯工具来服务客户。

对于客户支持部门，如何来评估他们的业务价值？

很多公司会关注服务质量，即客户对某个会话的服务满意度。但是更重要的是如何减少客户服务的人工成本。

对于客户支持团队收到客户各式各样的问题反馈，大体可以分为这样几类：

• 使用方式类。
• 报故障类。
• 投诉与建议类。（产品本身的优化和改进）

使用方式类

对于“使用方式类”，我们又可以进一步细分为两种情况：

• 一种是用户完全不知道怎么使用我们的产品，需要一步步引导的向导或者DEMO。
• 另一种是接入了我们的产品，但是发生了非预期的结果，需要寻求帮助。

对于第一种情况，我们需要在产品中植入必要的引导。产品帮助文档虽然有，但是我们应该坚信一点是，绝大部分客户的问题应该依靠产品自身来解决，而不是依靠产品文档。

对于第二种情况，在很多时候，出错的信息往往是很难理解的。所以错误信息的呈现，也是需要非常讲究的，我们要将错误信息的表达变得更加贴近用户的语言。甚至，我们可以在错误信息中，给出我们的建议，或者建议文档的链接。

报故障类

对于“报故障类”，也就是用户认为我们的服务出了问题。这个也可以细分为两种情况：

• 一种是我们的服务实际没有问题，而是用户自身的环境出了问题，比如Wi-Fi或者本地运营商的故障。
• 另一种是我们的服务确实有问题，我们如何跟客户之间沟通。

对于第一种情况，我们需要有意识地收集用户请求的整个调用链。依靠Tracing机制，以request id作为线索，获取从客户端到服务端完整的调用链。这样，在报故障时客户端会携带自己的IP 和 Tracing 日志，客户支持人员就可以通过客户IP 和 request id了解这个客户最近都发生了什么事情。

对于第二种情况，这是客户的故障通常会有一个突然的爆发式增长，该什么时候对外宣布事故，及什么时候主动通知客户？

首先，先宣布事故发生，随后找到一个简单解决方案，然后宣布事故结束，要比在问题持续几个小时之后才想起告知客户要更好。

针对事故，我们应当设立一个明确的宣布条件。比如，如下任何一条满足条件，这次事故应该被及时宣布：

1. 是否需要引入SRE 之外的团队来一起处理问题？
2. 在处理了一个小时后，这个问题是否依然没有得到解决？
3. 这次事故是否正在大范围地影响最终用户？

云计算

云计算定义了新的交付方式，IT技术供应商不再提供可执行程序或源代码，而是互联网服务。即使在线上出问题的时候，也是IT技术服务商安排技术人员去解决，而不是用户自己想办法解决。

云计算改变了用户与IT技术服务商之间的配合方式。从之前的对交付过程负责，到对服务的质量结果负责，双方的职责更为简单清晰。

云计算发展到今天，大体经历了两个阶段。

资源交付革命

在云计算之前，业务上线过程大体上来说是这样的：

1. 首先，购买基础的IT资源，比如服务器和交换机等；
2. 然后，将服务器和交换机等通过物流系统运送到IDC机房并上架；
3. 安装上基础的操作系统；
4. 部署业务系统。

而云计算之后的业务上线被简化为：

1. 购买云上虚拟的云主机若干台，这些云主机已经按用户选择预装了基础的操作系统；
2. 部署业务系统。

交付的IT产品形态并没有发生根本性的变化，以前是物体机，现在是云主机，两者使用上的用户体验并没有很大的差异性。IT资源交付效率发生的巨大变化，主要体现在以下几方面：

1. 资金优化：消除了物流的成本。
2. 时间优化：物流时间、产品自助化水平（上架、操作系统安装）。
3. 资源复用率提升：云计算通过将不同用户的IT资源聚集在一起，提升了IT资源的使用效率，减少了社会资源的浪费。

容器革命

以容器革命为标志，以Kubernetes为事实标准，迭代的是服务治理的能力。

容器革命带来的变化是：高度自治的服务治理系统对软硬件环境的故障有天然的免疫，我们什么都不用做，系统自己完成自我修复的过程。

今天Kubernetes已经成为DCOS（数据中心操作系统）的事实标准。它带来了以下重要的改变：

• 用户操作的对象不再有机器这玩意，最核心的概念是服务。这也是数据中心操作系统概念的由来。
• 硬件资源池化。软件或服务与硬件环境解绑，可以轻松从一台物体机迁移到另一台物体机。
• 面向逻辑视图描述集群状态。配置中心的数据只体现业务系统的逻辑，不体现物体特性。

服务端的未来

服务治理系统的迭代，最终将让我们达到这样的状态。

• 任何业务都可以轻松达到7*24小时不间断服务。高并发、高可用、高可靠，小菜一碟。
• 做业务都足够的傻瓜化。
• 做一个新的有状态的存储中间件，虽然比做业务麻烦一点，但是，一方面也没有多少新的存储中间件需要做的，另一方面做一个存储中间件有足够便捷的辅助设施。

服务端工程师很可能只是一个阶段性的历史背景下的产物。随着互联网应用开发的基础设施越来越完善，服务端开发的成本越来越低，最终和前端工程师重新合而为一。