cost&efficiency

降本增效，我的一点看法

降本增效，基本是这两年一个快被说烂的词了，我自己也算是深陷其中很长一段时间。今天主要是想写下自己的理解，不一定对，不认同就划过，瞎哔哔我的，我会直接拉黑。

方向要选对，试错要考虑成本

选对方向，这个是最最最重要的。道阻且长，行则将至，这说的是你得走的方向是对的，要不然走死你你也到不了。有人会说，很多时候，我也不知道哪个方向是对的啊，好的，没问题，你说的对。那这个时候就是要去尝试，但是尝试一定是小分队去尝试，甚至可以多个小分队分别往多个不同的方向去试，这样错了，成本也不会很高。但是如果是全部资源投入去尝试，去折腾，那一旦发现方向错误，这成本可是不小哦，既有人力成本，也有时间成本。但人性使然，沉没成本，不是每个人都愿意及时认错割肉的，就跟你买了股票下跌后，你总想着拿到回本一样，导致即使发现做了，也不及时止损，让团队继续投入，越来越拉，团队最终陷入盲目忙碌的泥沼，看似忙忙碌碌，实则原地打转，消耗大量的人力、物力和时间成本，最终做成的事情寥寥无几，士气低落。

别瞎砍瞎降

那些无法加人加班解决的事情

我所在公司，身处金融强监管行业，这个行业有个共性，公司要开展任何新业务，必须要先拿到监管机构的审批才可以的，不像腾讯美团等互联网大厂，很多业务就是我想到了，系统弄出来，就可以营业。但监管审批这个事情，要持续多久，这个是不受公司内部资源控制的（你有个董事是川普那就是另一码事了），无法通过加人加班加速这个过程的。那这一类事情，提早开始，配合监管的要求，不断优化材料，必要的时候做出demo版的系统进行演示等，日拱一卒，这些审批最终都会通过的，然后合法展业。这一类事情，如果同行竞对想copy，都需要走一遍这个过程，如果我厂花了2年才拿到审批，那同行如果从零开始，那它绝不可能2个月就拿到，大概率也是2年左右的，这样的护城河就是无比稳固的。降本增效，一定不能把这一类事情给砍了，等要用的时候发现没有，又在说什么当时为啥砍掉了。。。。。

那些可以日拱一卒做得完的事情

参考嘉信理财，盈透证券，我们不说全部的产品特性，就说其中用户常用的80%吧，这是能列出一个很清晰的清单的，这个清单一定是可以日拱一卒，做得完的，并可以不断完善，包装成用户喜欢的体验。每日精进一点，持续完善这些功能，产品体验没道理做不好的。如果朝令夕改，今天全力开发新功能 A，明天却毫无征兆地暂停 A 去做 B，后天又推翻 B 转向 C，过段时间又回头发现 A 在市场上需求很大，最终啥都没搞成，产品体验糟糕，研发系统也是各种补丁摞补丁，各种猥琐，先猥琐解决再迭代优雅，没有时间去及时重构，最终是永远猥琐，优雅个屁。团队被折腾得疲惫不堪，每天看似忙忙碌碌，其实都是瞎忙，毫无成就感。中层管理者的精力每天都花在揣摩上意，如履薄冰地向上管理上，无法专注于团队建设和业务推进，精力都浪费在无意义的内耗上。其实每个产研团队的同事在说一句话的时候会很自豪的，但是很久没听过了，“我们app的那个xxx功能，我们团队做的，欢迎体验，有什么问题及时反馈给我们，我们评估改善”。

云原生

云原生主要解决的问题是什么？1. 资源利用率，动态扩缩容，省钱。 2. 资源隔离（cpu，内存等），服务稳定性

先别说云原生的其他好处，就说这2点很明显的好处吧。

主要想说下资源利用率这个事情，其实基于金融证券服务的场景，我们预期比较理想的服务器资源管理方式是怎么样的？

• 刚开盘的30-60分钟会是订单量高峰，我们希望能提前几分钟把服务扩容；
• 等请求量高峰过去后，再自动缩容（机器归还，省钱嘛）
• 如果盘中突发预期外的事件导致请求量暴增，自动识别到（例如识别到cpu，io等用量突增）进行自动扩容，波峰过去后，再自动缩掉。

整体的思路就是跟用水用电一样，我用就给钱，不用就不给钱，用的时候随时有，不用的时候随时关（归还）。但在服务器资源管理方面，这势必需要准备一个服务器资源池子，那这个池子归我厂还是归云厂商呢？如果归我厂，那这个池子的费用怎么算? 又怎么保证每次扩容这个池子都是够的？同样，放到云厂商，这个事情又怎么管理呢？这个池子不管归谁，都不可能平时闲置的，大家都想省钱和赚钱啊。

再说资源隔离方面，主要是指的cpu和内存这些资源，这个其实是刚需，因为我们经常有机器的资源被各种服务观测等的agent服务打满，导致作为主人的各金融服务无法工作了。这个不展开说了，云原生有这个功能，和你能用的好这个功能以及需要的前置工作和配套设施，这是两码事。

就这些吧，随便写写。