后续的一段时间不聊管理了，好好聊聊技术。

今天简单聊几句软件的取向。

周末我记得凌晨聊到一个话题，就是成本怎么减下来，最终有一个点是服务器的使用率的统计和限制。

使用率肯定要关注，但是强调这东西的话，取向有问题。

涉及两个点

一

现在的软件系统本身刻意做了很多切分，主要的目的是为了可靠性，让每次修改发布涉及的单元最小、故障涉及的范围最小、可组合性最强，所有这些取向都是和单台机器的性能使用率背道而驰的。

从企业的角度来说，可靠性肯定要排在一定的（还是不能过高）成本前面，因为如果成本最重要的话，不上任何系统就自然没有这部分成本了。

使用率是要关注、要限制、也要平衡，但是不能由每一个一线程序员来做。架构师、云平台、新技术，去搞定，技术如果目前还不太能特别有效的解决，那这些点不正是技术突破点吗。

引入新思路、新材料从而达成效果是最有效的，限制和控制，是最下下之策。

二

我们首先要分清自己的软件类型，然后再说怎么管，如果你的软件主要挑战是数据（数据量、数据复杂度、数据变化速度），那你的软件是数据密集型软件，运算量本来就不是你的点。

如果你是计算密集型的，处理器的速度是瓶颈，那使用率又天然会特别高，不需要考核什么服务器使用率。

所以你看看，这么一个哪哪都不合适的指标。

以终为始吧，目标拆出过程，然后取舍动作，每一个考核都会引起一串反应，一定要想清楚。

转回来，数据密集型的软件到底该如何做呢，目前看起来大家没啥太多的概念，很多就是凑业务写，手里拿这个Mysql的锤子，看啥都是钉子，调用量高了就加缓存，完全是傻干。

我戏称这种软件开发为，摊煎饼，可以把一勺面糊，摊成特别大的一张饼，所以当然就需要很多的硬件资源，所以想解决就要从此入手，而非其他。

数据量、数据复杂度、数据变化速度，大家仔细想想基于这三个纬度，系统到底怎么设计才好。