研发过程的技术型决策之浅见

       在架构设计领域一直有这种说法，“业务功能架构可以有多种多样的实现方式，但是非功能特性决定整个架构的成败”，对此我是高度认同的。尤其是在目前基础设施高度完善，框架产品不断地在降低业务开发的复杂度的背景下，我依然觉得业务系统的开发人员依然要重视系统的技术实现与系统的非功能需求等，尤其是业务系统的运行时状态；因为业务系统的很多风险来自业务自身复杂性的比例往往比技术实现上的风险低得多。

        在我们平常的业务系统开发中，经常遇到的中间件故障、容器运行环境不稳定等这些容易被业务开发同学忽视的技术风险，又往往导致我们业务系统自身的健壮性面临比较多的挑战。

       现在国内的整个技术发展趋势，也是在不断地通过职责分工，让业务的开发同学更多关注业务，最大化提升业务价值，让框架开发团队的同学关注造轮子，让基础设施技术同学保障可靠的基础设施供给。分工的初衷是好的，但是软件的成败往往又是很复杂的。在这种背景下，不同的团队目标不一样。业务开发同学关注最多的业务建模，怎么样保证业务能够低成本地实现规模化效应，框架开发团队同学关注比较多的是框架的性能与扩展性，怎么样获得最多的使用场景，基础设施技术同学关注比较多的是基础设施供给的稳定性与时空效率，怎么样获取资源利用率最大化。正是这种目标上的差异，导致大家忽视了技术服务业务的核心诉求以及不同角色对待风险的认知gap提升了风险问题的发生概率。而这类事件往往就意味着业务上的资产损失或用户流失，其中最致命的就是用户技术信任度，尤其是在金融等风险容忍度极低的行业。

       国内这些年移动互联网的蓬勃发展，我们的C端应用发展迅猛。而C端产品，我们关注比较多的非功能需求是高流量高并发挑战下的高性能与高可用。我们对此的解决方案通常是分布式架构与弹性设计理念来应对流量带来的张力效果。我们有一个决策的前提，就是允许业务上的小概率失败，CAP理论中我们会更关注于业务的可用性尤其是核心业务的可用性，本质是因为我们的容错成本是相对较低的。

      但是在我们更复杂的B端产品中，技术需求往往要求又高得多和复杂得多。

      B端应用的复杂性，其中一个比较突出的点就是作业链条很长，参与者角色多，作业规则繁杂等，这种场景下，一个典型的技术需求就是一致性问题，尤其是实时一致性问题。这个问题的本质其实在于我们对数据分布的合理规划，既要兼顾数据读写的效率，更要兼顾数据在特定场景下的一致性诉求。我们会在多数据副本与单副本之间不断地balance，本质是水平与垂直的数据分布规划，而这种诉求又催化了我们数据库存储产品逐步HTAP化的设计思想。

      另一个比较显著的技术需求就是高可靠性。C端应用的高可靠建设理念很多都是建立在失败容错或兜底策略设计上。但是B端产品，尤其是生产性系统产品，失败导致的损失往往是物料资源的损失或生产事故等。彼时，非常多C端应用场景下的设计理念在B端场景下是行不通的。这个时候，我们在设计的时候，第一位关注的流程的准确与健壮性，会舍弃掉莫些高性能的技术实现方案。

       再一个比较显著的技术需求就是数据仿真。C端应用的数据产品很多是用来做数字化运营决策，而生产软件做数据仿真，更多的是通过数据的手段来降低不必要的资源消耗，同时尽可能地完善产品在使用场景中会遇到的各种情境，提高产品的使用可靠性。

       简而言之，场景决定诉求，核心诉求的达成路径上，我们要把最多的精力发在核心矛盾的解决上。我们业务开发，要树立一个相关宏观的技术观，不仅仅关注我们的业务价值实现，更应该具备识别技术风险的能力。研发与运维一体化，从本质上是要求我们开发人员要具备宏观的软件设计理念，能够把控好技术实现风险，同时通过合理的技术规划最大化服务业务。

       在如今大模型带来的开发范式的变化趋势下，良好的高层视角与综合素养是技术人员的核心竞争力。技术的工具供给体系已经非常发达，它对我们技术人员的一个挑战是怎么样基于业务场景选择简洁有效的技术体系来达成我们的业务目标，同时管理业务达成过程中的技术风险。这些都是一些偏综合素质的历练，毕竟能真正在基础大模型研发需要极高的算法背景，抑或是大模型部署与调试，也需要相关的算法应用背景。个人认为，对于普通的业务开发同学来讲，除了加强自身的算法素养，提升自身的综合素养，并把自己的业务认知力与大模型的工具体系融合起来，才是差异化竞争的取胜之匙。