许式伟的架构课
许式伟
七牛云CEO
立即订阅
19946 人已学习
课程目录
已更新 71 讲 / 共 77 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 怎样成长为优秀的软件架构师?
免费
基础平台篇 (21讲)
01 | 架构设计的宏观视角
02 | 大厦基石:无生有,有生万物
03 | 汇编:编程语言的诞生
04 | 编程语言的进化
05 | 思考题解读:如何实现可自我迭代的计算机?
06 | 操作系统进场
07 | 软件运行机制及内存管理
08 | 操作系统内核与编程接口
09 | 外存管理与文件系统
10 | 输入和输出设备:交互的演进
11 | 多任务:进程、线程与协程
12 | 进程内协同:同步、互斥与通讯
13 | 进程间的同步互斥、资源共享与通讯
14 | IP 网络:连接世界的桥梁
15 | 可编程的互联网世界
16 | 安全管理:数字世界的守护
17 | 架构:需求分析 (上)
18 | 架构:需求分析 (下) · 实战案例
19 | 基础平台篇:回顾与总结
加餐 | 我看Facebook发币(上):区块链、比特币与Libra币
加餐 | 我看Facebook发币(下):深入浅出理解 Libra 币
桌面开发篇 (16讲)
20 | 桌面开发的宏观视角
21 | 图形界面程序的框架
22 | 桌面程序的架构建议
23 | Web开发:浏览器、小程序与PWA
24 | 跨平台与 Web 开发的建议
25 | 桌面开发的未来
26 | 实战(一):怎么设计一个“画图”程序?
27 | 实战(二):怎么设计一个“画图”程序?
28 | 实战(三):怎么设计一个“画图”程序?
29 | 实战(四):怎么设计一个“画图”程序?
30 | 实战(五):怎么设计一个“画图”程序?
31 | 辅助界面元素的架构设计
课外阅读 | 从《孙子兵法》看底层的自然法则
加餐 | 想当架构师,我需要成为“全才”吗?
32 | 架构:系统的概要设计
33 | 桌面开发篇:回顾与总结
服务端开发篇 (14讲)
34 | 服务端开发的宏观视角
35 | 流量调度与负载均衡
36 | 业务状态与存储中间件
37 | 键值存储与数据库
38 | 文件系统与对象存储
39 | 存储与缓存
40 | 服务端的业务架构建议
41 | 实战(一):“画图”程序后端实战
42 | 实战(二):“画图”程序后端实战
43 | 实战(三):“画图”程序后端实战
44 | 实战(四):“画图”程序后端实战
45 | 架构:怎么做详细设计?
46 | 服务端开发篇:回顾与总结
加餐 | 如何做HTTP服务的测试?
服务治理篇 (11讲)
47 | 服务治理的宏观视角
48 | 事务与工程:什么是工程师思维?
49 | 发布、升级与版本管理
50 | 日志、监控与报警
加餐 | 怎么保障发布的效率与质量?
51 | 故障域与故障预案
52 | 故障排查与根因分析
53 | 过载保护与容量规划
54 | 业务的可支持性与持续运营
55 | 云计算、容器革命与服务端的未来
56 | 服务治理篇:回顾与总结
架构思维篇 (8讲)
57 | 心性:架构师的修炼之道
用户故事 | 站在更高的视角看架构
58 | 如何判断架构设计的优劣?
59 | 少谈点框架,多谈点业务
60 | 架构分解:边界,不断重新审视边界
加餐 | 实战:“画图程序” 的整体架构
61 | 全局性功能的架构设计
62 | 重新认识开闭原则 (OCP)
许式伟的架构课
登录|注册

54 | 业务的可支持性与持续运营

许式伟 2019-11-05
你好,我是七牛云许式伟。
保障业务的 7x24 小时不间断服务并不容易,所以我们花费了非常长的篇幅来探讨这件事情。我们需要系统性的、结构化的解决方案,它的涉及面非常广,需要基础架构、中间件、SRE 工作平台等多个层次、多个工种之间的紧密配合。

客户支持

但就算线上没有出问题,我们的用户仍然会遇到各种麻烦。所以大部分公司都会成立客户支持团队来服务客户。客户支持团队可能使用工单、电话或者即时通讯工具来服务客户。
对于客户支持部门,我们如何评估他们的业务价值?
很多公司会关注服务质量,简单说就是客户对某个会话的服务满意度。这当然也是重要的,但对整个客户支持部门来说,最核心的还不是这一点。
我们最核心的关注点,是如何减少客户服务的人工成本。
通常来说,客户支持团队会收到客户各式各样的问题反馈。这些反馈大体可以分这样几类:
使用姿势类;
报障类;
投诉与建议类。这个不是今天关注的内容,不再展开。
我们首先看 “使用姿势类”。这又细分为两种情况:一种是完全不知道应该怎么用我们的产品,需要有一步步引导的向导或者示范的 DEMO。另一种是接入了我们的产品,但是发生了非预期的结果,于是客户迷茫了,需要寻求帮助。
怎么才能避免用户拿到我们的产品,完全摸不到北,不知道应该怎样才能使用起来的情况发生?在产品中植入必要的引导是非常必要而且重要的。产品帮助文档虽然应该有,但是我们应该坚信的一点是,绝大部分客户的问题应该依靠产品自身来解决,而不是依靠产品文档来解决。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(3)

  • Bachue Zhou
    “但是 Go 语言团队显然不是这么看的。它特意在代码逻辑中加入了这种使用姿势上误用的检测,检测到错误后直接抛出异常,让程序停止运行。在异常信息的提示中,它告诉你,你的代码存在了什么样的问题。” 这才是坑呢,应该学习 Rust 的做法,线程不安全的代码根本不能通过编译,这才是理想的做法。Go 虽然有数据竞争检测,但这个也不是百分百能检测出来。而 Rust 能百分百地不让存在线程安全问题的代码通过编译。

    作者回复: rust的编程哲学坦白来说是我不认同的,凡事过犹不及,它是典型。

    2019-11-13
    1
  • Aaron Cheung
    七牛云的 Pandora 日志平台 老师推荐了多次 值得试试👍
    2019-11-05
    1
  • 雷霹雳的爸爸
    这还真是挺难的一个问题,一个是如许大所说的视野问题,另一个在于组织文化方面的水平约束了能给予技术团队从多大程度上去整合整个业务价值链条来为客户提供能够更好的支持,以及为其自身做出必要的信息收集和技术演进支撑,这不是官话,作为一个传统服务业数字化转型过程艰难爬的技术支撑小组的领班人,还是很多切肤之痛的
    2019-11-05
收起评论
3
返回
顶部