问electron系统日历？

降本增效的核心点就是多用成熟的产品，少用自研。

很多人都迷信自研和业务定制，但其实，比如对办公软件来说，飞书和企业微信就能满足99%的需求了，你自己那点定制的需求可能就是伪需求，而你要为此付出很大的成本。

举个跟架构师和开发无关的例子。一个企业给员工管饭，是要自已经营一个食堂呢？还是找一个合作的饭馆？如果这个你觉得不容易回答，想一想，你每天去菜市场买菜呢？还是要自己种菜？

答案是显而易见的，人类自从有了分工，整个社会运行才更高效。

说回降本增效这个话题，那就是去掉那些伪需求，多用成熟的产品和第三方合作伙伴，让擅长的人做擅长的事。

任何一个项目或者说工程，都要衡量ROI，哪怕是NGO也一样。 业务创新还是降本增效（不是将本），都是达成项目目标的方法。

而系统是工具，架构设计是实现工具的手段。

市场变化快，增长预期高，自然可以投入更高，可以糙快猛，萝卜快了不洗泥。

等到一片红海，容错率低，活着才是第一要务，必须精打细算，严格评估ROI。

架构设计上的降本增效，有很多种方案，比如复用，比如用云，比如分级冗余，比如拿现成产品凑合用，等等。

核心的点在成本投入多少才合理。

你的观点是对的，这的确是个关于平衡和取舍的点。在做架构设计时，可以充分考虑业务现在的发展情况，对短中长期的需求有一个预判。

问题中你提到了架构的高可用，以高可用为例，业务眼下需要达到什么样的水平呢？能匹配业务的发展诉求，略有超前，给日后的发展留下口子就行，不要直接把路给堵死了。例如，对于一个刚起步的业务，可能同一AZ中能够做到无状态的集群化部署就行了；随着业务发展，后面再考虑同Region的多AZ容灾，可以先从冷备做起，再到热备，最后多活；如果业务发展更大了，再来考虑异地容灾的问题。前几步有比较成熟的解决方案，小成本的方式就能实现，对业务来说也是可以接受的。