99%的程序员容易忽视的“系统”健康问题

99%的程序员容易忽视的“系统”健康问题_第1张图片

导读

对于业务同学,不管是从0到1完成一个项目,还是从1到2迭代或者维护老系统,多多少少会因为客观或非客观因素,产生一些当时可控的“负债”,随着时间的积累,那些当时以为可控的“负债”,慢慢“长大”,使得在项目随后发展的过程中,复杂度越来越高、潜在的风险越来越大。本文将阐述我对于业务负债以及身体负债的一些思考。

目录

1 负债的合理性与必然性

2 如何有序的消除负债-结构化思考

3 从业务负债看身体负债

4 总结

01

负债的合理性与必然性

这个标题乍一看,会让人感觉有点奇怪,“负债”合理且必然?这里先抛出一个观点:解决负债的前提是“认可”负债,看见“不合理”事物的合理性是解决负债的前提,下来我依次谈谈关于负债的合理性和必然性。

   1.1 熵增定律引起的必然性趋势

首先熵增定律的定义是:在孤立系统中总是趋向熵增状态,最终达到熵的最大状态,也就是系统的最混乱无序状态。例如,房间很久不打扫,就会布满灰尘;长久不骑的单车会生锈;交通系统临时瘫痪,车辆很快就会堵死等等 。熵增定律同时适用于一个系统的演化规律。我们为了对抗“系统”的混乱,为此做出的努力,可以看成了“逆熵”的过程。

想想我们为什么需要练习“正念”、“冥想”?,本质也是一种逆熵的行为,如果不加控制,“精神熵”会增大,我们会成为“思维”的奴隶,被思维反噬,我们希望思维是有序的,因此我们去正念、去看书,去整理我们的思绪。(思考:想想如何控制自己不去想一些糟糕的事?)

为什么我们要去健身?,本质上也是逆熵的过程,身体随着时间慢慢衰老、身体激素水平、代谢水平开始慢慢降低、会对新鲜事情失去兴趣,会觉得没意思,这不是你的问题,因为我们的身体同样也遵循熵增定律。去正念是对抗“精神熵”、去健身是对抗“身体熵”。

从熵增定律看软件系统,我们会得到一个结论:系统的复杂度(混乱程度)随着时间的推移,必然越来越高,复杂度导致了业务的开发、测试、运维各个阶段负债增多,对于软件设计的目的,可以总结为“逆熵的过程”。

   1.2 因果律引起的合理性结果

因果率是事物发展的基本规律之一,在分析论中,有一个很知名的方法,叫 5why 分析法,意思是要看清楚一件事的本质,可以问自己五个为什么。我们举几个栗子:

问题:我最近状态很不好。

第一个为什么:为什么我状态不好?

答: 因为我睡得太晚了,睡觉前老是看手机?

第二个为什么:为什么我老是看手机,到很晚才睡觉? 

答:因为我工作了一天,辛苦了一天,还没有一些自己的娱乐,我想晚上的时间才是真正属于自己的。(在潜意识里,你不想结束这一天)

第三个为什么:为什么我不想结束这一天,直接去睡觉?

答:原因是我的生活被各种事情到“打扰到”我一直处于一个“中断”的状态,到了夜晚,我才可以专心做自己的事。

第四个为什么:为什么我的生活总是很凌乱,被很多人牵着走?因为我对于一天要做的事和时间分配没有一个清晰的计划,换句话说,我也不知道今天要做什么,别人让你做什么你就做什么。

答:因为我没有很强的时间管理意识。

第五个为什么:为什么我没有一个很强的时间管理,总是被事拉着走?

答:...

看看这个 demo,对于第一个 why,大部分人都会告诉自己,早早睡觉就好啦,少看手机,到这里问题已经结束。事实证明,这很难做到,因为第一个 why 并没有找到问题核心的原因。到第五个为什么,我们想到了时间管理。当然这只是一种路径,大家可以运用这种方法,不妨问自己几个问题,逼迫自己去想一下问题的根源在哪里。在这里我想分享一下我的心得:对于大多数的问题的解决方案,最后的最后可能都会集中在三个问题上:如何做时间管理、如何做精力管理、如何做情绪管理。

   1.2.1 从具体到抽象

我们现在把上述的例子抽象化,从个性中找共性,尝试得到一般性规律。如下图所示,我们可以把因果逻辑抽象成最基本的单元,事件 A 导致事件 B,通俗地讲,事件 A 就是时间 B 的第一个为什么。

99%的程序员容易忽视的“系统”健康问题_第2张图片

如果我们再次追问原因,就可以把这个过程抽象成下图,我们把它称为一条因果逻辑链,或者思维深度,当一件事发生,往前追溯的事件数量越大,说明思维逻辑越深。

99%的程序员容易忽视的“系统”健康问题_第3张图片

当然,实际的情况可能复杂得多。一件事情的发生,不能完全归结于之前的另一件事,而是之前所有事件的加权。找到问题本质的难点其实是:找到影响因素最大的那个事件。如果判断失误,在错误的结论上越跑越远,结果往往会更加糟糕。方向错了,越努力,死得越快。

99%的程序员容易忽视的“系统”健康问题_第4张图片

如果以上叫做追忆往昔,那么下来我们想说说展望未来,如果我们把视野看向未来,会得到以下的图,事件 B 会对未来的事件产生加权后的影响。如果把 5why 分析法泛化一下,我们可以这样问自己,今天做的事,会对明天产生什么样的影响,它会产生什么连锁反应。

99%的程序员容易忽视的“系统”健康问题_第5张图片

现在我们把过去的因果和未来的因果放在一起看看就得到了如下图。

99%的程序员容易忽视的“系统”健康问题_第6张图片

因果逻辑链是一个很好的工具,它逼迫我们去思考从前,也思考未来,找到事情的本源,分析未来的趋势。(具体的更加详细的内容,推荐大家阅读《深度思维》)

面对软件工程中的种种负债,需要用一种辩证且开放的心态看待,看到负债发生的必然性,通过深度思考,找到逻辑链条上那个最大的影响因素,肯定“负债”的合理性,是有效解决负债的前提。

   1.3 康威定律带来的沟通负债

康威定律揭示了组织架构沟通方式和系统设计之间的密切联系,对于复杂的系统,系统设计离不开人与人之间的沟通,解决好了人与人的沟通问题,很大程度上就解决了系统设计问题。下面我们来论述沟通带来的负债。

   1.3.1 一对一沟通

针对一对一的沟通模式,我们可以借助通信系统中的通信模型很好地抽象这个过程。

99%的程序员容易忽视的“系统”健康问题_第7张图片


从这个图中,我们可以看到,如果想让信息100%地无损传递,需要控制二件事:

  1. 编码系统和解码系统需要用一套。这就可以解释不同背景和成长环境下的人对于同一句话有着不同的理解,因为他们有着不同的编码和解码系统!

  2. 信息在传递过程中,需要有一种对抗噪声的算法,防止“坏人”篡改信息。

以上两点,在通信工程实践中是有最优解的,但是把信息源和接收源换成人,这件事就变的异常的困难,我们没法用一套标准的“规则”要求人。从中我们可以得到一个结论:沟通是有损的,这是业务负债的一大来源。

   1.3.2 多对多沟通

多对多沟通是一个更加复杂的场景,在多系统中如何让信息有效地传递?(这像不像分布式一致性问题,推荐阅读 paxos、raft 算法),大家都经历过这种场景:开会中,我们希望对一个问题的答案或者解法得到一个共识,如下图所示:

99%的程序员容易忽视的“系统”健康问题_第8张图片

当开会人数是3时,沟通次数最少是3*(3-1)/2=3。

当开会人数是4时,沟通次数最少是4*(4-1)/2=6。

当开会人数是5时,沟通次数最少是5*(5-1)/2=15。

...

当开会人数是 n 时,沟通次数最少是 n*(n-1)/2,这是可以得到一个炸裂的结论:沟通的复杂度是 O(n2)!也就是沟通的复杂度会随着人数的增加,呈现指数增长趋势。这个结论是悲伤的,悲伤的点在于:

  1. 当你试图通过人员增多解决问题时,你可能会把问题更加复杂化!

  2. 项目的复杂度比项目的体量增长要快!

99%的程序员容易忽视的“系统”健康问题_第9张图片

如上图所示:直线代表着通过增加人数而带来的劳动力,曲线代表这增加人数带来的复杂度,在 [0,临界点]区间内,问题整体可控,在[临界点,+∞]区间内,复杂度变高,债务出现。(问题:如何找到临界点呢?)

以上的情况还是在信息可靠传输的情况下进行,如果加上损耗因子,我们会得到沟通带来的损耗也是指数级的:如果损耗因子为 k(0

如果把人换成系统,这不就是微服务分布式系统的通信问题,在中台设计思路上,偏向于使用领域建模的方式把微服务拆分成边界明确的小模块,提高复用能力,但是这也带来了服务数量爆炸、运维困难的问题。(这真是一种 trade off 啊)

总结:沟通有损和组织成员沟通带来的复杂度,是引起业务负债的另一大原因。

02

如何有序的消除负债-结构化思考

当我们需要解决一个复杂问题时,不妨从一个具体且相似的问题回答,找找相似点。

比如:如何减脂?说实话,这个问题也困扰了我很久,在减脂的路上反反复复,相爱相杀。总结一下,有这么几点困难:

  • 减脂的流派很多,网上的知识很零碎,对于小白来说,压根不知道听谁的,很难找到适合自己的方法(结构化思考)。

  • 减脂并非一朝一夕,你找不到一种固定的方法,一招吃遍天。不同的阶段需要使用不同的方法。

  • 大部分同学减脂,是为了瘦,但是瘦不是目的,健康才是。(目标一开始就错了,一开始就背道而驰)。

对于以上三个问题,不难联想到:

  • 结构化思考,系统化思考。

  • 问题会变化,解决问题的方式也需要变化,需要建立一个良好的反馈机制。

  • 搞清楚为什么做,比怎么做更重要。

   2.1 结构化思考
   2.1.1 结构化表达

结构化思考最重要的就是:把问题、知识、方法、灵感、或者步骤 ...结构化地表达出来、变成你心中的一颗树。

比如针对业务开发流程中可能引起的负债这一问题,可以把问题聚拢在下图中:

99%的程序员容易忽视的“系统”健康问题_第10张图片

针对不同时期,不同阶段的问题,进行分类!进行分类!进行分类!重要的事说三遍,如果把不同的问题,看成是一类问题,会出事!

当归类完成后,就需要针对性地,有主次地解决。在“资源”一定的情况下,需要先抓住主要矛盾、抓大放小、比如现网安全问题要比代码规范问题优先级更高。

   2.1.2 透过现象看本质

在阅读《思考,快与慢》一书中,作者清晰地描述了,人的两套系统,即系统1、和系统2。系统1的运作是无意识且快速的,不需要去消耗注意力,如判断两个苹果的大小?回答1+1=几?回家的路该怎么走?而系统2则是高度多样化的,并且需要消耗大量的注意力,如,判断股票的买卖时机、在嘈杂的环境中听清某个人说了什么、一篇文章作者的意图...

作者还提到了几个比较有意思的点:

  1. 系统1是不善于质疑的,人们会更倾向于凭借直觉解决生活中的问题。(非理性思考)

  2. 人们更愿意用一个简单易懂的道理来解释一个复杂问题。

  3. 当系统1遇到困难时,才会激活系统2运行。  

99%的程序员容易忽视的“系统”健康问题_第11张图片

结合书中作者提到的点,针对解决业务负债的问题,我们需要摒弃系统1的常态化、惯性化思维模式、激发系统2的思维模式,这需要克服自身的惰性,并需要大量的时间进行深度思考,找到事情的“真相”。 

99%的程序员容易忽视的“系统”健康问题_第12张图片

   2.2 学习生物的智慧

人的一生的三分之一都用在睡眠上,有很长一段时间我在想人为什么要睡觉呢?不睡觉是不是就可以做更多的事,是不是就可以跑在前头,直到一个无意的机会读完了《睡眠革命》,才理解了睡眠的意义。

人的身体很像一个计算机系统,每个器官各司其职,协同完成一天的工作。日常生活中,大脑是一个及其活跃的器官,在运行期间,会产生大量的垃圾:淀粉样β蛋白,在大脑紧张工作时,大脑会将清理工作推迟,只有到了睡眠时,尤其是深度睡眠时,大脑才会切换到清理模式,换句话说:睡眠实际上是大脑的一种消除“负债”的有效手段(身体对抗熵的过程),这里还隐含了一个很重要的点:定期清理。身体不会一直累积负债,而是在合适的周期内定期处理。这也可以回答如何长期睡眠不足,身体没办法消除负债,时间久了,人会生病,系统也会“生病”。

下图左边抽象了身体通过睡眠对抗负债的一个过程,右图是业务偿还负债的一个对应过程,这对于我们的启发是:定期对业务进行复盘,找到负债,在可控的情况下解决负债,是一个不错的选择。(在问题没有发生的时候,解决问题,代价最小)

99%的程序员容易忽视的“系统”健康问题_第13张图片

   2.3 先扛住,再优化,扛住了,优化呢?

你有没有遇到过这种场景:

产品侧同学:业务同学紧急提出了一个需求,需要马上支持,在下周三前上线。

技术侧同学:按常规的做法需要a 、b、c,但是时间可能来不及,有一个快速的短期方案可以支持,但这种方案会产生a、b、c目前可以“容忍”的问题。经过了一番讨论,决定先采取短期快速的方案优先支持业务,等支持完业务后,再优化解决。

问题往往就出现在业务成功支持以后,我们还能不能想起当时“妥协”而产生的负债?及时地优化,而不是让“负债”长大。

这是困难的,是基因里,人们会对“坏”的事情,更加敏感,需要活下去,经历了“事故”、经历了“失败”,人们往往更愿意去复盘,去优化。但是面对“成功”,人们往往会沉浸在喜悦中,这个时候劈你的雷可能已经上路了。面对成功的项目,需要庆幸,需要感谢,感谢供电局没有停电;感谢地球没有爆炸;感谢概率学在某一刻倾向性的选择。

03

从业务负债看身体负债

如果说业务负债,带来的“痛苦”还可以“容忍”,那身体上的负债呢?系统挂了,可以修复 bug、重新上线,身体挂了,什么都没了。人生是一场一次性的游戏,如果有一个准则,那我想一定是:不出局,我一直玩,小尺度的快和慢,并不太重要。这一章我会阐述对于身体负债的一些思考。

   3.1  身体系统与计算机系统的相似性

身体和系统有很多的相似性,每个人的身体好似一个分布式系统,每个器官各司其职,大脑类似 CPU、眼睛、耳朵就像是 io 设备、食物类似于电...所以我在思考,能不能使用管理计算机的方式管理我们自己的身体,使身体也“高可靠”、“高可用”。

   3.1.1 从运维方法 看身体管理

在我看来:如何让身体保持良好的“状态”和如何运维好一个系统?是同一个问题。身体这个“系统”,在我们出生的时候就已经被创造,在出生到死亡之间,可以说一直处于一个运行维护得状态。有的人维护的好,可以和所处的环境达到一个“和”的状态,愉快且充实地生活着,相反有的人维护得不好,生活质量变差,“精神熵”增大,负面情绪将控制你的生活。基于系统的相似性,那我们能不能借鉴常用的运维手段管理身体这个大系统?答案是:完全可以!

   3.1.2 身体也需要一个监控系统

对于运维,要去了解一个系统的好坏,最直接的就是看整个系统的关键监控曲线,比如整体服务的 SLA、关键接口的成功率、超时率等等,身体也是如此,我们去判断自己的身体状态不应该是靠感觉,而是靠数据。对比一个周期与上个周期的数据,才可以说,ok 我身体变好了、我身体不如以前了。

之前有一则新闻:Kernel 和 OS Fund 的 CEO 布莱恩现在每年至少花费200万美元,聘请30多名医生和健康专家监测他身体的每一个机能。对于普通人,我们不可能做到这种地步,但是还是有很多可以操作的方法,比如以下三点即使每个人都可以轻松做到的。

  • 定期体检。

  • 使用睡眠监测软件,监控心率、血氧、睡眠周期。(这里推荐 autosleep)

  • 定期记录体脂和体重。

定期通过监控的数据去 review,你会发现很多神奇的事情,这让你会更加了解你的身体。基于数据,而不是基于感觉。

   3.1.3 身体也需要一个日志系统。

日志系统会帮助收集系统的运作过程,方便我们去定问和排查问题,身体也一样!

小的时候应该都有写日记的习惯,在一个风和日丽的下午....这里当然说的不是这种日记,而是记录你身体状态的日记。我们每天可以自己去记录一些身体的关键数据,用来定期地复盘。我打个样,如下图:  

99%的程序员容易忽视的“系统”健康问题_第14张图片

刚开始我们可以降低难度,每天就记录睡眠的时间和体重,主要是培养一个记录的习惯,可能一天两天你感觉不到变化,但是一个月两个月,你就可以在一个长时间维度上,感受到你身体的变化。你会感受到,因为你每天健康饮食,给你自己带来的好处。

   3.2 如何有序地消除身体负债?

这里我分两个方面去回答这个问题。

   3.2.1 反馈机制

每个人的身体状态和精神状态是不同的,没有一个固定的公式告诉你应该怎么去做,你需要自己去优化、去迭代,没有只要做了什么就成功的案例,网上的方法也是零碎的,有的人讲你要有氧、有的人讲你要吃水煮、有的人说是你“湿气”大....这些都是在一个小范围内去讨论问题,身体是一个系统工程,需要系统的方法论解决。

解决的前提是建立良好的反馈机制,良好的反馈机制又建立在数据和复盘上,我们需要通过数据,而非感觉去判断一个身体的健康走向。数据又建立在一个习惯上,记录身体在某个点的状态,如,睡眠、体重、饮食等等等...

如果你是小白,你可以把记录的数据定期拿给医生,或者专业的运动营养师看,让他们给你一些专业的意见、计划上的调整。当你了解自己以后,你就可以自己去微调你的计划。切记不要走极端,类似不吃饭了、突然去运动…物极必反,每个人自己最佳的平衡点需要自己去找,没人可以帮助你。

   3.2.2 心理健康更加重要

情绪对人的影响非常大,中医上讲大喜、大悲都是有害的,情绪化很容易让人的心被困住,没有强大的能量很难走出来。原生家庭可能会是人的情绪的很大的一个影响因素,这里推荐大家阅读《被讨厌的勇气》《当下的力量》《心流》,里面有一些可操作的方法去加强你的心理建设。

和自己的心相处是一个很难的课题,这里我的一些建议是去看书,尤其是心理学和历史学。虽然从古代到现代,我们的科技发展了,但是面对的问题,可能并没有改变,人还是那些人,人性还是那么个人性,太阳底下没有新鲜事,你遇到的问题,别人已经总结好了方法,你只需要学习、吸收、实践。把一件事放在宏观的历史尺度下,你会更加地辩证和从容,而不是用“好”和“坏”去判断。心理学会让你更好地和自己的心相处,心里不打架、不拧巴。

人们通过学习、经历创造了属于自己的思维,又被自己的思维困在其中,你可能需要给思维边界开一些口子,让不同的想法进来,重塑你的思维。

04

从业务负债看身体负债

负债不可怕、拥抱负债吧,积极地解决可能是唯一的方法。最后希望大家都可以有序地、有节奏地解决自己的身体负债、业务负债。

-End-

原创作者|吕昊俣

  99%的程序员容易忽视的“系统”健康问题_第15张图片

对于业务债,你是选择早日修复,还是尝试与其共存?欢迎评论分享自己的看法。我们将选取1则最有价值的评论,送出腾讯云开发者社区定制笔记本1个(见下图)。11月28日中午12点开奖。

99%的程序员容易忽视的“系统”健康问题_第16张图片

欢迎加入腾讯云开发者社群,社群专享券、大咖交流圈、第一手活动通知、限量鹅厂周边等你来~

99%的程序员容易忽视的“系统”健康问题_第17张图片

(长按图片立即扫码)

99%的程序员容易忽视的“系统”健康问题_第18张图片

99%的程序员容易忽视的“系统”健康问题_第19张图片

99%的程序员容易忽视的“系统”健康问题_第20张图片

99%的程序员容易忽视的“系统”健康问题_第21张图片


你可能感兴趣的:(99%的程序员容易忽视的“系统”健康问题)