这次找的工作，又一次与系统优化相关。还好，这算是我最熟悉的领域。多年来自己一直以系统工程自居。这类工作，困难，又难以出成绩。但却是不可或缺的。

多年来，我一直尝试，用一种科学的方式和语言来描述系统优化这类工作，一直坚信这种工作也是一种科学，也有最佳的答案。因为科学就一定隐含着重复性。

当然，如果我这次真失业了，搞不好，我也会开个专档，详细描述这个行当的一些要点。但这里我们只捞干的，不说费话，对有一定基础的人来说，也许还是有一定意义。

一定要相信自己所从事的工作是一种科学

分析成功与失败

这点是相当重要的。我们从事一份工作，可能总是需要经历一个埋头苦干，但却难以找到规律的阶段，这个阶段，最常见的特点是：活干完了，却想不清楚是如何实现，似乎即使是经验也很难复制到其它的任务中；更不要说从中提取可以写出来的知识了。

在这个时候，不要放弃，要努力去思考，特别要将重点放在失败的经验中，找到不能那么做的原因；分析一件事失败，有时确比这件事是如何成功的，要简单些。我是说，当你自己是主语去尝试实现 一个目标时。类似飞机失事后，事故分析之类这种，系统出了问题，又不是你导致的，但要你分析的这种，不在这段文字所描述的场景中。

总之，一定要相信自己所从事的事，不是一种玄学。如果是玄学，那就不要做了，不如去算命了，挣得还更多。更能得到人们尊重。

方法就是不断积累，不断分析。

相信世界有普遍规则

这点当然也是必要的。

系统工程师常说的一句话：世界只有一个系统。因为这就是这个世界所构建的模式。没有第二种。不论是宇宙，还是生物体，还是小宇宙，都拥有相同的模式。

你开发的东西不会例外。

系统工程师最后往往会沦为系统优化工程师

当然我这里不是贬义，因为系统优化工资可能会很高。而且活也不一定很累。

但好的系统其实是构建出来的，而不是优化出来的。

但是现实世界构建出来的好系统有，但不多。我们都是普通人，我们没有办法强求这个世界按我们的意志运转，世界就是一个大的草台班子。

所以，系统工程师，你要懂构建主义哲学；但不要耻于做一个系统优化工程师。尽管我们看起来像是帮人处理混乱局面的，但这就是这个世界。

系统的常见问题--根据具体实例

尽管最后系统优化要做许多琐碎的事，但系统性能出问题的原因，却往往非常少。

因为构建系统的法则非常少。

只要你懂得构建主义哲学，就会出现，所有出性能问题的系统，往往是由于相同的原因造成。

所以，构建主义哲学，要花些时间去学习学习。

比如，系统工程师，是从底向上构建，而不是像总工或者架构师那样从上向下造金字塔。

从底向上构建，有许多好处，也有许多要注意的点。

例如，忘记目标，目标是规则之上的目标，没有目标，只要满足规则，你的目标一定会实现，所以，要忘记目的性。至少不要过于关注做所谓正确的事；而要将重心放在提升最小粒度的质量（懂法、守法、参与），和确保最小粒度得到同样的机会（资源可以有优先级，但要得到相等的被调度的权力）。即责权对等，机会均等。

一个案例

例如在我正在处理通信相关的案例中，需要实时并行处理许多种上行和下行任务；这时，一般的调度系统都有优先级的设定；这种设定，在我来看，就是错误的，是违背了系统工程思想的。

最小的粒度，机会必须要均等，资源可以有多有少，但机会一定要均等。

你不能说哪个任务优先级低。例如接入（RACH），相对比较少，而且也比较随机，所以，架构师就认为它的优先级应该很低。

这显然是有问题的。

因为通信系统在压力大的情况下，所有的core都将是 100%的运行状态；在这样的情况，你对RACH这类任务的低优先级，作何种解释呢？

你很难解释，对吧？

所以，这是显然的错误：违背了机会均等原则。

那么有人说，如果这样，实时调度系统的优先级设置还有什么价值呢？

在通信系统中，微任务员的切换都是皮秒级别的，这种级别，通过利用操作系统和CPU的压栈机制是不可能实现的。相反，如果时间片很长，在ms级，现在的作业系统的一切理论当然是可以考虑的：高优先级到达后，可以强行中断正在执行的任务；

这在复杂的实时性高的并行系统中，是无法成立的。

为什么呢？因为其本质违背了分布式系统基本构建法则。

导致机会不均等和系统无法给当前场景对于某个最小粒度的需求，作出合法合理的解释。

经如，反过来，将RACH任务作为最高优先级，是不是就能正确呢？也不能。因为RACH其随时性就意味着不确定性，如果某一时刻太多用户接入怎么办？

所以，如果你作为系统工程师，将全部的精力放在法则这一边，你的生活才能简单下来，只要坚持最基本原因，就可以不去考虑这类场景下的是非对错，你是法律的维护者，不是裁判官。

对我来说，这里的改进，就是将它们的优先级平级。并且，给PRACH和一些这类相对而言不确定性高，但算力要求低的任务绑在一个不被大业务干扰的核上即可。

关于流水线

pipeline这件事，是DSP的概念，对于DSP是没有太大问题的。

但对于CPU来说，有很大问题。

流水线像是工厂的生产线，比如月饼的生产线；电子厂的SPI+SMT+烘烤+AOI的流水线。

DSP程序如果设计好，是可以借鉴的。

但对于通用CPU，这种是不行的。

因为通用CPU的核往往是有限的，也就几个到几十个。

pipeline，意味着任务pipeline的头部得到调度之后，后面的一大堆任务，都鸡犬升天了，占了一个CPU不释放。

这不是好的设计。是违背的最小粒度的机会均等原则的。是典型的法则的破坏者。

改进的办法是，pipeline还保留，但每个task需重新送到调度器，重新调度。

后记

今天就写这么多。国庆了。祝大家国庆快乐。

本文相当于自己的笔记，表达了作为系统工程师如保去分析复杂系统的问题：只要坚持基本法则，不要过于看重具体的业务与实现。你的生活就会变得简单。

今天讲了两条：（1）最小粒度的机会均等和资源可以不均等；（2）不允许有pipeline（一串连续的最小粒度占据一个CPU core）