思维升级了，问题就好办了

文 | Rickzhang

老陈不知道该怎么汇报了。

作为一家国有杂志社新提拔上来负责新媒体业务的副总编，老陈上任接的第1个任务就是为这家杂志开发一个APP。

当时他踌躇满志，在自媒体大号工作的经历，让他以为一切都可以完成的非常顺利且精彩。

然而让人意想不到的是，领导似乎每隔一段时间都会有新的想法，而有时候前后矛盾的需求，让APP的落地平添了很多变数。再加上中间预算的几经变化，也让负责技术的经理换了三任，开发程序员的五人团队变动了四个。

最后，由于对进度的不满，在领导的直接干预下，技术经理和开发团队全被辞退，转而把整个项目交给了上级领导有关系的一家外包公司处理。

然后矛盾就彻底爆发。

一方面，中途经手的技术负责人太多，使得技术实施的思路和整体的框架经过2~3次修改，大规模的修正中间存有的各种问题，在最终测试阶段全部暴露出来。

另一方面，由于程序员经手次数太多，很多原来的程序问题没有解决，不得不另开辟新的代码，绕过原有问题程序去做功能落地。这只能是写程序的程序员能看懂的东西，到了最终外包团队落实封装测试的时候，就让他们叫苦不迭。

这使得最近三个月，老陈的核心工作就是在四处灭火。业务部门对于相应数智化业务的落地非常着急，而外包公司又无法快速上线，中间产生了大量的沟通问题与纠纷，很多事直接就捅到了社领导那里。

最终，社领导通知老陈，让他在周一例会准备一个报告，以便管理层评估项目是否终止。

老陈在接到通知后很不理解，他特别想知道好好的事情到底是怎么走到今天这个地步的。

实际上，老陈作为信息化负责人的经历和杂志社领导最终忍痛废止数智化投资的事情，在企业推动企业数智化过程中不是个案。

当前对于信息化尤其是数智化的重视，是中国企业发展史上从来没有过的时期。企业普遍认同数智化会成为企业发展的助推器，愿意投入资金和精力，将管理与业务各方面逐渐实现数智化。

然而，对于数智化技术标准和能力的不了解，让很多企业在投资数智化业务开发的时候，走了弯路甚至吃了大亏。

腾讯云副总裁黄俊洪在接受CSDN（专业开发者社区）访谈时曾表示，传统企业处在逐步数智化转型的一个阶段，它转型的动力主要有两个方面，一方面是来自于自身业务发展的需求，另一方面是来自企业降本增效的需求。

“从具体的行业场景来看，无论是金融、政务或制造业等等，随着我们数智化的深入，单独简单云服务已经远远不能满足传统企业数智化的需求”。

因此，我们更需要新的数智化思维。

本来是共同努力推动企业信息化，最终却变成了杂志社与老陈一起双输的格局，真正的原因并不只是老陈在总结报告中特意指出的那个：领导在过程中更换了几次功能和目标的设定，影响到了整体的进度。

或者说，杂志社领导对于APP开发的目标不明确，并不是此次整体业务数智化失败的主要原因。

因为好的产品经理在领导目标变化的时候，都会对此作出预案并积极调整，而主要推动整个项目最终走向消亡的，实际上是在实施过程中开发团队不注意的标准化和延续性的开发过程。

某种程度上，杂志社领导经过几轮变动需求弄清楚自己需要什么功能之后，老陈的技术团队从管理者到程序员都已经出现了几轮变动。这让之前写的代码隐藏的问题，后面的程序员并不清楚，最终使得混杂在一起的产品在测试时漏洞百出。

这已经成为现在很多企业部署数智化研发时候重大的风险。

实际上，企业做数智化业务投入时，应该做的是通过战略决策落地的方式推动企业在数智化方面的转型。因此，管理者只要知道数智化产品研发的逻辑和问题所在就行，以便于在自己的过程中对此加以避免。

首先，我们最应该转变的，其实是对于云服务的认知。某种程度上，买几台云服务器和数据库，把开发环境搬到云上面，从传统的本地化的编程体验转到云原生体验，这其实只是初步企业业务上云的过程，离发挥云服务真正的优势还差得很远。

其次，我们也要知道相对于现在协同的云开发模式，传统应用的架构或开发方式通常构建时间更长，大批量发布，只能逐渐扩展，并且会发生更多的单点故障。

企业开发传统的应用必然要租用或者购买相应的网络服务，服务器、数据库等等软硬件来配套，而这些投入在企业业务扩张的时候还必须根据同比例进行放大，这对于企业来说又是一个不小的成本，而且在投资决断的时候也会让管理者非常头疼。

传统 IT 开发与后期运营系统的不是一波人，这中间会出现很多因为沟通不畅带来的问题。整个团队是分裂的，接手后期使用和维护的技术人员，完全依靠自身技术水平来维护程序的运转。哪怕重要问题还需要协调开发团队来解决，费时费力不说，中间耽误的时间和空间成本也无法避免。

这是所有投入数智化业务研发的企业必须关注的重点。如果不对这些问题有事先的准备，在管理策略和整个开发的架构与时间表上进行把控，就会让企业数智化的投资出现大问题。

另外，对于一家企业来说，更换信息化或数智化的负责人是可以理解的事情，甚至更换整个开发团队也是可以理解的事情。毕竟面试成绩特别好的求职者，在工作中能力不行的比比皆是，企业肯定要在各个岗位上找到最优的人事配置。

但信息化和数智化研发过程，对企业来说必须要保持整体开发进度的稳定，如果开发团队稳定不了，就想方设法让整个工作的进度和流程，乃至于基础的代码保持稳定。这就使得不论开发团队如何更替，整体都能保证产品研发的进度以及产品研发的质量。

当然，这属于实际操作中需要注意的问题，但这种问题如果不提到非常重要的地位，企业管理团队之前非常好的战略就得不到落实，最终也会影响企业的稳定与发展。

所以，企业需要升级对数智化研发的认知，用高维度的理念来推动问题的解决和整体效率的提升。

现在推进数智化的企业遇到的问题，实际上很多互联网平台在之前发展的道路中都遇到过，也曾经成为这些平台发展道路上的桎梏。

他们最终趋向的解决方案叫“云原生”。

这跟企业现在不停提出的“业务上云”不是一个逻辑。上云只是简单地把基础设施能够搬到云上，而云原生需要借助的是云的弹性伸缩能力，还有按量付费模式，去实现云上的开发、运维、测试、部署等生命周期，充分享受到云计算红利的模式。

这种模式就是基于云的一些基础能力，比如说容器化的能力，资源的编排与管理能力，可以通过这种方式跟这种资源编排的结合，能大大降低开发者代码编写和服务部署等其他成本，使得开发者能够更加聚焦在自己具体的业务开发层面。

这是腾讯业务实践带来的经验，毕竟腾讯是最早接触云原生的互联网大平台之一。早在2015年云原生技术基础的“容器”和“K8S”刚出现时，腾讯内部就将这些技术引入到实际业务中。

企业可以把容器看作是为单个的业务数智化搭建一个正常且舒适的实施环境；K8S则是在容器基础上形成的，可以完成一系列任务的数智化业务的环境集群。

腾讯当时发现这两个云原生基础业务对他们的帮助最大，尤其是如火如荼的游戏业务。

一般来说，游戏业务有一个特点，上线初期如果火爆可能有大量扩容操作，运行一段时间后，如果效果不行可能会频繁合并服务器和下线。而K8S系统中服务器节点的快速启停、动态升降配的能力非常符合这个场景，于是腾讯将K8S系统引入，运行了很多游戏业务，加强了配置灵活性，降低了一定的成本。

早期经过这一系列内部业务试点，腾讯在云原生技术的积累逐步成熟；之后腾讯逐步将云原生技术放到腾讯云上对外部客户输出，同时进一步在腾讯内部自研业务中全量推进云原生技术升级换代。

这其中最重要的就是腾讯文档这个腾讯在线办公重要功能的落地，而这个功能是一个完全建立在云原生基础之上的开发。

当下腾讯云通过容器服务和K8S技术，将腾讯内部数千万核心的资源拉通到一个大的资源池中去调度和管理，在提高资源装箱率的同时，也进一步通过容器在离线混部技术使服务器资源利用率从30%提升至65%。

除了容器外，基于云上的微服务和开发运维一体化技术，腾讯内部也进一步打造了统一的开发框架和研效平台，这让腾讯文档的开发进度和运维效率有极大提升。

开发中，腾讯文档实现了通过大量工具来自动化研发过程中的基础动作，提升开发效率。同时沉淀各种组件、工具、规范，切实落实程序质量管理制度，坚决执行一致性建设。

关键，腾讯文档因为其应用特性，必须保证低故障率和高稳定性。

在使用云原生开发逻辑和工具实现后，云原生应用平台可自动进行腾讯文档的基础架构调配和配置，根据应用的日常需求在部署时动态分配和重新分配资源。而基于云原生运行时的构建方式可优化应用生命周期管理，包括扩展以满足需求、资源利用率、可用资源编排，以及从故障中恢复，最大程度减少停机时间。

这让整体效率有了翻天覆地的提升，也让腾讯文档的易用性和稳定性上了一个台阶。

现在对云原生的定义还没有统一，但内部的功能基本上都差不多。

一般来说，云原生就是将程序的开发和运营全部放在云上，通过微服务的方式将程序的功能细分到最小的模块，这样能保证模块的稳定，每次程序的修正都会变成模块上的叠加；通过容器化为微服务提供实施保障，起到应用隔离作用；利用Devops（开发运维一体化）的思维，实现开发、测试、运营在云上一体，是一个沟通文化也是组织形式，为云原生提供持续交付能力；最终实现持续交付，这是不误时开发，不停机更新，小步快跑，反传统瀑布式开发模型。

通俗来讲，云原生跟传统开发模式最不一样的地方，就在于程序跑在一个个容器组成的集群里，而这些集群不考虑基础的软件环境，只考虑云上的环境，这能大大降低企业开发投入的前期准备成本。

另外针对于开发的细节，云原生实际上是将业务需求拆分成最细小的微服务模块，并利用云平台提供的各种工具复现出来，然后再利用模块的叠加实现业务的数智化功能。

而Devops的思维，就是利用各种云上的工具来辅助开发人员实现开发、测试、封装、运维一体化。所有的问题能及时解决，开发人员也能第一时间拿到云系统提供的各种精准反馈，有利于加快业务数智化落地的时间，提升管理的效率。

在这些原则的帮助下，持续交付就成为必然形成的一个特例，也会让业务滚动发展，小步快跑不断迭代。能出现用最小的成本，维护数智化业务最快速发展的情况。

这些优势都打在了企业投资数智化的痛点上。

腾讯文档就是一次很好的云原生开发示例，尤其是对企业的投资和管理策略来说，了解整个过程，对他们未来相似工作的落地有很大好处。

首先，腾讯文档团队强调了源代码的统一性，并通过云原生的各种工具维持这种统一性的实现。这其中包括但不限于使用统一的开发框架、利用云原生工具生成通用代码和建立代码仓库等方式，目的就是为解决相应业务数智化开发或者转型，当遇到整个团队人员变动影响到开发进程的情况。

因为所有代码都在仓库中，而且框架一样标准一样，每个人调取相应的微服务模块都有记录，改进也都在统一的标准下执行，后续人员的接手也会便利。

其次，腾讯文档团队在确立业务开发功能前认真分析云平台提供的各种微服务模块，将已经成型的模块集成到自身的业务需求中，让业务需求实现过程标准化、低代码性和可重复。

现在各家云平台各种各样的微服务已经非常成熟，能满足绝大多数企业数智化业务开发过程中各种需求的实现。在这个过程中，如果直接调用云服务平台的相应微服务产品，不光省时省力，而且还能保证整个过程的稳定和安全。

实际上，腾讯文档云原生开发过程中，仅通过引入自动化脚手架工具，就让创建新服务的开发需求，从原本需要一天时间变成不超过3个小时，大大降低了开发人员的工作强度，而且还提升了开发效率，降低了协同中出现的问题。

腾讯文档在云原生逻辑和工具基础上快速开发、部署的经验表明，管理者在一线开发过程中可以找到云原生的逻辑，并通过这些经验指导技术团队，利用云原生的方式来保证开发的稳定，进而保证企业数智化战略实施的稳定。

而随着虚拟化技术的成熟和分布式框架的普及，在容器技术、可持续交付、编排系统等开源社区的推动下，以及微服务等开发理念的带动下，应用上云已经是不可逆转的趋势。

腾讯文档的实践表明，企业树立好云原生的思维，利用云原生的方法和工具，将应用全部实现原生化上云，就会大大降低开发人员的难度以及后期运维和升级的难度，并可以实时的扩充自身的功能，形成一个动态化调整的结构。

腾讯云副总裁黄俊洪在接受采访时曾指出，从腾讯云原生的实践来看，云原生的发展本质上是解放了开发者的生产力，“让这种代码的开发工作得到一个有效的质的提升，让企业的开发团队能够更加聚焦在有创造力的业务逻辑跟业务场景的理解跟开发上面来”。

这对每个想投资数智化业务的企业来说，都十分重要。

于企业管理团队来说，了解一线开发的新技术和新策略只是一个出发点，真正的目的是设立数智化业务的云化思维。

因为只有对自身业务进行最细致的分析，找到业务底层的模块才能更好地指导开发团队，建立微服务内核的云原生应用，也才可能将自己的业务数智化。

这是数智化产品开发的逻辑。

而数智化只是企业管理的工具和思路，企业真正需要的是协调所有的资源去完成自身发展的需求。这就是云原生在现在越来越火的基础。

腾讯云副总裁刘颖曾表示，云原生技术能够帮助企业提高应用的开发、发布迭代速度，让企业能够在激烈的市场竞争中满足用户越来越高的期望。

另外一方面，云原生技术具备极致的资源伸缩能力、服务自治和自愈能力，能够极大发挥云的优势，让企业在新场景下，能够灵活应对 “架构越来越复杂、资源越来越多、稳定性要求越来越高的挑战”。

在这个过程中，如何用好云原生和全栈开发的工具，通过调整自身数智化研发的思路，进而搭建一整套适合云原生的管理体系和发展模型，成为企业信息化亟待解决的问题。

那么，我们该怎么利用云原生的理念？数智化负责人有没有好的案例可以参考？技术团队应该怎么通过云原生的逻辑来管理？

在上周末TechoDay腾讯技术开放日上，腾讯云除了讲述各个产品原理，还重点呈现了腾讯文档、传统企业招商局、外资企业英特尔等厂商的云原生实现路径及价值复盘，并整理成《腾讯云原生指南》，有兴趣上云的企业可以下载研究一下。

*文章为作者独立观点，不代表笔记侠立场。

也可点击阅读原文，了解哦