强推

这里给大家推荐一个专栏，友情提示，这个推荐不是广告。这个专栏的名字叫做：乔新亮的CTO成长复盘。

这里面讲了很多很多，每一篇都是精华满满。下面我整理了下文章的标题内容，大家可以了解下这个专栏大体的内容。

开篇词 削弱运气的价值

对于个人认知的复盘 01 职业生涯发展规划：每五年登上一个新台阶 02 到底该怎么理解工作和薪资的关系？ 03 看透本质：研发出了生产事故，到底要不要罚钱 加餐一 大学毕业，我要不要留在一线城市互联网公司？ 加餐二 工作遇到不懂得问题：合适可以求助，如何正确提问？ 加餐三 选择决定上限，努力决定下限

对管理工作的复盘 07 管理者最重要的三个任务（一）：组织调整到位 08 管理者最重要的三个任务（二）：加强组织协同效率 09 管理者最重要的三个任务（三）：激发团队活力 10 管理的人性哲学：金刚之怒，菩萨慈悲 11 全局思维和持续完善的体系的建立，让团队持续成长 12 管理战略上的聚焦和放弃：有舍才有得 13 风险管理：世界是脆弱的，持续管理风险非常重要 14 需求做不完，应该怎么办？（初/中级管理者篇） 15 需求做不完，应该怎么办？（高级管理者篇） 加餐（一） 如何通过演讲分享，打造自己的影响力？

对专业成长的复盘 17 架构决策，是技术管理者最重要的能力 18 架构设计，专业分工和协作精神的体现 19 产品思维，契约精神是基础，洞察人性才能成就卓越 20 高可用设计，让产品没有后顾之忧 21 高性能设计，一切都围绕着契约精神 22 扩展性设计，看透业务的本质 23 考虑限制，让自己的产品不入险地 24 监控设计，让一切都有迹可循，尽在掌控 25 异常设计，让错误无处遁形 26 上云设计，融合云计算的未来

结束语 做时间的朋友

编辑手记 我被老乔洗脑了

以上是整个专栏的全部内容，建议通读一遍，真的干货满满，那么我接下来就自己感兴趣的点来做下分享。

首先有一句话让我大受震撼，科技是向善的，产品应该让人们的生活变得更美好。某些在商业上比较成功的产品，在我（这里指的是乔新亮）看来，就是有问题的、不成功的，因为它给用户的导向是不好的。

对于这句话，我的理解就是，现在很多企业发展都很好，但是其实不是引导人们向善，所以每当国家出台相关政策后，都会使企业遭受重大的打击，甚至陷入生死存亡、性命攸关的紧急时刻。当然也不乏有其他大环境的影响，毕竟经营企业是一个很难得课题。

那为什么要说：科技要向善呢？你是不是有看到过这样的评论：互联网不是法外之地；为什么国家出台那么多政策来限制”企业发展“；我想这是因为，越来越多的人感受到了，那些”不合理的行为“。企业除了要赚钱，更需要明确边界，明确精神，打造向善的产品。

企业应该明确精神，这个精神具体是什么呢？乔新亮（后文尊称为老乔，因为老乔不喜欢被称为乔老师）用一个词来描述，那就是契约精神。同时，为了更好的理解什么事契约精神，以及作为一个技术人员，如何有效配合企业的契约精神，老乔更是举了一系列的例子：比如：京东物流作为一款物流时效性产品，给用户的“契约”是“当日或次日送达（偏远地区除外）”。那么京东物流的订单系统、调度系统、仓储系统、配货系统等，全部都要为这个契约的交付而努力。再举一个例子，唯品会作为一款产品，给用户的“契约”可能是“用更便宜的价格买正版的鞋服”。那么不光是 IT ，整个企业都要为了守住这个契约而努力。彩食鲜的“契约”是提供可信赖的安全食品，那么在基地管理、采购管理、工厂加工、仓储作业、配送服务等各个环节都要确保食品安全，例如对于蔬菜批批检，信息可查询、可追溯。

老乔通过一些列的例子为我们加深理解什么叫做契约精神，那么如何指定契约精神呢，那就是量化，用数字来组成契约，用 “SMART 原则”来检查契约，使得一切都可量化，避免后期各方争论推脱打马虎眼。比如你做的是一个财务系统，那么你要达成的契约就是：准确率98%以上去完成一些账目核算工作。

其实我理解的契约量化的目的就是打造一个卓越的产品。老乔也提到打造一个卓越的产品，有”三个一“思考法：那就是”一站一键一秒“，意思是在场景和目标确定的情况下，让用户在一个位置，点击一个按键，在一秒内达成目标。如果说遵守“契约”，可以打造一个 90 分产品。那么以人为本、洞察人性、使用“一站一键一秒”等方法，则可以打磨出一个卓越的产品。而产品建设就是要以人为本，不断去寻找价值，匹配价值，成就用户。

说完产品，再来聊一聊系统设计方面。

说到系统架构，一定离不开的就是高可用、高性能的设计。

首先高可用，而说的通俗一点，高可用的设计就是为失败而设计，如果系统出现异常，请求失败如何解决。为什么要有高可用的设计呢，老乔给出的结论是”应对变化“。高可用设计真正的敌人是“变化”。而高可用意味着对系统全部元素、连接都进行高可用设计，在物理实例层面主要表现为冗余和集群设计，在代码逻辑层面，方法则多种多样。当你的资源和精力不足以实现全链路高可用时，提供“降级服务”和“熔断服务”，优先保证高可用，其次保证高可靠。这里真的佩服老乔的专栏，专栏底下每一位读者的评论都太太太优秀了，我看的时候，甚至每一个评论都看了一遍，有一位读者评论高可用简直太贴切了，拍手叫绝。

人体就是一个高可用的系统，人的很多器官有两个及以上(冗余设计)，少了一个，人体还能够正常的工作，还能继续生活，每个器官也有不同的等级，就好比服务治理中的，核心服务，和非核心服务，核心服务不能挂，挂了就会影响到整个业务，就好比人的心脏，如果停止工作，那整个人就挂了，但是断了一只手，人还是能够生活(服务降级)，架构设计可以参考生物学中的很多概念。

（果然设计源于生活呀~）这里再提一位读者的评论，总结也是很精辟：限流降级熔断，应用高可用的三板斧。缓存升配扩容，应用高性能的三板斧。多机异地灾备，机器高可用的三板斧。

如果说高可用的设计师为了应对不可预知的变化，那么高性能就是在这不可控的变化中，为系统保驾护航（不知道我这个比喻贴不贴切）。

高性能的设计可以从以下几点切入： 1、为架构做好“保护系统”：做好系统的流量控制（连接数限制，用户数限制，排队策略）； 2、使架构具备扩容能力：储备额外的计算资源，提升弹性扩容的速度（冗余，CAP，异地备份，异地多活）； 3、提升系统各组件处理能力：识别高并发情境中的资源争抢情况（读写分离，Redis缓存，EDA架构，SOA架构，MQ等），同时注意保留架构的可扩展性。

高可用和高性能围绕的点都是技术架构，而技术架构设计的关键在于：不要重复造轮子，至少不要在公司层级造轮子。技术人的惯性思维，包括现在有的时候我还下意识的会表现出来，技术高于一切。所以为了彰显自己技术，喜欢自己研究一些东西，写出来点东西就觉得很有成就感。但请转换思维，记住：技术一定要为业务，业务一定要赚钱，技术绝对不能自嗨，有可以复用的东西就复用，不要自己开发，因为我们大多数都是业务型公司。如果你觉得你的技术牛逼，最好的证明点就是自己创业，把自己的技术做成产品卖出去。如果我们身在业务型公司，就要为业务服务，看向全局，不要停留局部，重复造轮子最可能导致的问题就是：“局部最优，整体很差”。

这里再来一位读者的留言：不要跟我聊纯技术，跟我聊这个技术对公司业务有什么帮助。互联网加速了资源的整合效率。阿里巴巴解决了做生意的效率问题。微信解决了沟通的效率问题。美团解决了吃喝玩乐的效率问题。云计算解决了it基础设置使用的效率问题。发展到一定的阶段，都会变成高度专业和完整体系化的一套复杂系统，把复杂留给了专业，把简单留给了用户。

所以，技术同学，抓紧改变思维，技术高于一切的想法，一定是不对的，但并不是说技术就没有用武之地了。现在大家都说T型人才U型人才，而作为技术同学，我想这个深度一定是技术专业能力，而当你的专业发展到一定的熟练度，你自然而然就会向外拓展，也就是能力整合。

最后再来聊一下，技术同学最恐惧的——故障。

线上发生故障，第一反应是什么？

定位问题？反正我没有看这篇专栏之前，我的思维一直都是定位问题，甚至是复现问题，因为只有知道问题在哪里，我们才能解决，这是我一贯的想法。但是老乔给了我当头一棒。

生产发生故障，第一时间一定是版本回退，且一定要回退到事故前的状态，任何场景都需要还原，比如数据库加索引的操作。

你可能回想，版本回退不是最基本的事情嘛，这个大家都知道呀。但就是版本回退的过程，你还是会被定位问题干扰，看似在版本回退，实则还是定位问题，老乔也给了一个他工作中的一个案例。

这个案例发生于某日下班后 —— 大约是在傍晚 20:00 左右，团队发现了一个出现在生产环境的异常。该异常来自一个可以连接众多终端设备的程序，其具体表现为：所在服务器的 CPU 负载突然飙升。但发现异常后，团队既无法将其恢复，也无法定位问题。发现问题后，共有十几位工程师先后参与了问题分析。很快，两个小时就过去了，监控系统仍然显示 CPU 占用异常，问题还是没有解决。这下，产品负责人着急了，向我求助，并将我拉进了问题调查组的电话会议。进入会议后，我立刻问了大家一个问题：“最近线上有什么版本变动吗？都回退了吗？”团队回答道：“都回退了。”我几乎没有任何犹豫地说道，不可能，一定没有全部回退。 要知道，计算机是非常可靠的。如果一套代码在一台机器上可以正常、稳定地运行，那么在外部环境没有发生任何变更的情况下，一周、一个月、一年后，它大概率能继续保持正常、稳定地运行。 果然，在我的追问下，负责发布的同学说，系统没有回退到上一个版本，而是按研发同学的指挥选择性回退的。好呀，真相大白，我命令他迅速按公司研发制度回退。没成想，回退到上一版本后，系统依然不正常。于是，团队继续查看前端、服务端、数据库等各类监控数据，试图分析问题到底出在哪里。我再一次找到团队，问道，真的都回退了吗？团队可怜兮兮地回答，真的都回退了！ 我的回答是，不可能，鬼才信你们…… 于是，我开始继续不依不饶地追问。终于，在我的“威逼利诱”下，有位同学一拍脑门，犹豫地说道：“我在数据库里加了条索引，不过这肯定不会导致负载异常……”还没说完，我就哭笑不得地打断了他的话，谈这些做什么？赶紧回退去。当这个改动回退后，一切都恢复了正常。 请注意，在这个故事里，当事人员并不是毫无经验的新手；公司并非没有监控系统，相反还做到了可视化、图形化。

不知道看了这个案例，你有没有感同身受。不过应该还是还有人提出质疑，你这个太理想了吧，出了问题就回滚，总会有意外场景吧。这里老乔给了他的经历，在工作的20多年中，版本回退没有解决问题，只有一次，ZooKeeper 因虚拟机连接数过多而崩溃事件。

所以老乔一直在思考，这种版本回退在技术团队中的怪象，为什么会发生呢？最终老乔给出答案，对于故障，我们的目标是：即使找不到 bug，依然可以做好故障恢复。我们必须不断强调并加深印象：生产环境永远不允许调试问题，出现问题立刻回退，查问题要去测试环境。技术同学需要建立全局观，明确一点，恢复功能比找到bug价值更高，这样思维才不会被局限。

要分享的东西真的太多太多了，但是自己没有管理相关的经验，无法加上自己理解予以分享，所以只分享了一下开发层面的东西，真的推荐这个专栏，极客时间搜索《乔新亮的CTO成长复盘》，一定会给你带来不一样的感受。

最后引用老乔的一句话来结束这篇分享：人生是一场修行，选择一个职业，在其中经历磨难，领悟人生的道理，最终殊途同归。