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

服务客户这一块也可以更好的借助于技术手段，所以整个架构课程覆盖内容范围，只懂技术的人是写不出来的

“产品被开发出来，对于很多研发人员的认知来说，是个结束”，这句话感触很多。 很多时候，技术人员容易有种误解“我的代码不出错就好了”、”服务不报错就不是我的问题”、“虽然报错了，但问题应该出在上游”，最后花了时间，费了精力，问题仍不能被解决。但资深人员就会有一个意识，要解决的是业务问题，不是系统问题。我们要做的是，推动业务问题解决，而不是自己的代码不出错。 “绝大部分客户的问题应该依靠产品自身来解决，而不是依靠产品文档来解决”。这句话也总结的特别好。 经常有人反馈“不是我软件用，是你不会用”，“我都给你培训过了啊，你咋还不会”、“大家为啥就不看文档呢”，其实当把自己作为一个新用户，带入场景试一下，就会发现，这个软件怎么能真么设计呢，这个流程好别扭啊。有了这个思路， 会打开一片新天地，开发能力会迅速得到提升。 好的技术人员，都会深入理解业务，自觉不自觉的考虑到这些问题，做的产品就更好用，解决问题的效果也会更好。

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

七牛云的 Pandora 日志平台 老师推荐了多次 值得试试👍

这还真是挺难的一个问题，一个是如许大所说的视野问题，另一个在于组织文化方面的水平约束了能给予技术团队从多大程度上去整合整个业务价值链条来为客户提供能够更好的支持，以及为其自身做出必要的信息收集和技术演进支撑，这不是官话，作为一个传统服务业数字化转型过程艰难爬的技术支撑小组的领班人，还是很多切肤之痛的

学习打卡

阿里云的企业服务。 比腾讯云感觉要好。

如果应用在发布之前能够内测一段时间，它的质量肯定会有更大的保证。 1.找上一部分目标人群免费试用，甚至可以给他们有偿试用。 2.就是我们的应用软件不管是to B还是to C的，它的使用必须足够简单，操作起来越复杂越容易出错。 3.如果本身就是一个特别复杂的系统，这样的系统在我看来就是半自动化系统，每一步都需要人来选择，于是十几二十步后，恐怕连写代码的人都不知道程序是个什么样子。