一晃工作十年，阅历渐丰，隐约发现其实社会中的一些现象其实和软件工程的一些理念有异曲同工之妙，今天就先拿笔者听闻的一些公司管理策略（套路）来简单说说。
事件1-系统吞吐量困境
这两年部门走了不少人，但是活似乎没有减少，那如何维持产出不变呢？
拿软件行业常说的吞吐量、延迟、容量这三个概念来类比一翻。吞吐量指的是单位时间内能处理的任务数，比如我们常说的qps、tps，简称T，延迟指的是完成单个任务所需要的时间，比如接口的响应时间是1s，简称L，容量指的是硬件资源，比如我们说的4核8g，简称C，三者之间的大致关系是：T=C/L，从这个公式来看要提高T有种办法，增加C或者减小L。
回到现实世界来看，在不可能加人的情况下（增加容量）那就只能提高工作效率了（减小延迟），牛马可怜兮兮的跟领导说：我的键盘已经敲的冒火星，真的再不能加活了，领导淡淡的回复：加把劲，克服一下。
牛马想破脑袋，终于做出了一个艰难的决策：一切从简，单测省去、注释不写、基本可用，通过这些简化延迟确实小了。
不幸的是领导很快发现了这一切，将牛马召集在一起意味深长的对大家说：我知道大家都很忙，但是我们也要保证质量，单测要做，Code Review也要加强，几个00后的牛马情绪激动的说：真的没时间啊，领导简单的回复：加把劲，克服一下。
牛马黔驴技穷，减小L遇到了瓶颈，那就只能想办法增加容量（加班）来维持这脆弱的平衡，完美复刻了互联网公司「既要压工期又要零故障」的经典死锁。
事件2-年薪包的资源超卖算法
如今大多数公司的薪酬都是年薪包制度，月薪可能只有1万，但是年薪包可以达到20万，刚入行的时候一直不解：为什么问了我期望年薪还要问我期望base，直接年薪除12不就得了。
出一个思考题，公司的年利润只有35万但是招聘两个年薪包20万的人干活，最后公司能盈利吗？
在学习k8s时有些文章提到为了资源利用最大化，我们可以将request设置为容器运行所需的最小资源，这样集群中就可以运行更多的容器（正如企业将年薪包拆解为底薪+不确定年终奖，利用人员流动的统计规律实现人力成本超卖），但是带来的问题是可能会存在超卖，如果在同一时间点大量容器都开始申请request外的资源，就会引起资源争抢、OOMKill等风险，然而大多数情况是由于业务特性的不同，这种同一时刻申请资源的情况不多。
回到刚才的思考题，公司利润只有35万，员工支出要40万，似乎不能盈利，但如果有以下情况呢：
1.中途有人离职（提前释放资源），即使后来有人接替，不满一年好多没有年终奖（业务特性不同，不会同一时刻申请资源）；
2.两个人都坚持到了最后，降薪（减小request和limit）或者末尾淘汰（OOMKill)。
周末的早晨闲来无事，天马行空的写点乱七八糟的。
