企业信息化自主建设的三重保障

企业信息化自主建设的三重保障

昨天在和研发团队开年度复盘会议时，我提到了技术的“三重保障”。

当企业需要招聘并通过自己的员工和技术人员，进行自主软件产品研发时，以下给研发团队提出的三重保障目标，对于作为互联网创业公司、需要自主建设信息化系统的单位，都是有帮助和启发性的。

三重保障，依次是：终端产品保障、系统架构保障、研发规范保障。

第一重保障：终端产品

终端产品，是企业提供给客户、用户所使用的最终软件产品。这也是用户、销售人员、老板、股东所能直观看得到、摸得着的实实在在的系统、App或小程序、API接口等。这些产品是有使用价值的，它能解决特定的场景问题，能给公司带来客户订单，甚至能完成一系列全流程的管理，形成系统闭环。

对于刚创业起步的公司，产品的研发、产品的发布上线、以及向客户交付可以成单的系统，终端产品的保障意义非常重大。有了落地的产品，有了演示环境、体验账号、产品介绍PPT、功能清单，才能让市场销售部更好地寻找目标客户和进行报价。即便是ToC的产品，产品的能越早发布和上线，就能越早验证用户的兴趣点和积累注册用户。不管是回顾过去，还是展望明年，在产品未正式投产前，都要非常额外关注项目的里程碑、大版本的迭代、流程功能模块不能“缺胳膊短腿”的。在这个过程，是漫长的，需要规划好项目进度、风险、技术选型、基础框架。

同样，对于已经运营多年，已有一定规模的企业，不管是有门店的实体传统企业+互联网，还是纯线上出海业务；不管是ToC终端普通消费者，还是ToB的SaaS服务平台，在每天都有用户使用的情况下，在每天支撑公司的业务发展的前提下，依然要保持“小步快跑、快速迭代”的节奏，一方面，既要不断迭代上新功能完成新需求，另一方面，也要保证项目的发布质量，除此之外，还得关注为了达成销售业绩，研发部门还要关注活动、促销、裂变方面的突发性、重要、临时需求。

不管如何，终端产品是公司向其用户、客户、下游合作伙伴提供可以直接使用的软件、应用或系统，是承担用户、流量、交易、营业额、数据的重要、不可或缺的载体和媒介。那在这背后，研发部门、信息部门、IT部门、技术团队（或其他部门名称），应当如何保障？

公司层面对终端产品的保障，需要在决策层和更高的层面进行方向把控。

首先，我们先来了解下什么是核心域、支撑域和通用域。根据DDD的理念，系统可以分为：核心域、支撑域和通用域。简单来说，核心域是和公司核心业务高度密切相关、独一无二并且关乎核心竞争力、用户个人信息、订单等，其特点是私密、核心、快速响应；支撑域是为了满足核心域的系统能完成核心的主流程业务所配套的系统，例如活动系统、客服系统、财务系统等；通用域是指技术层面上和业务无关的，单纯是技术类的通用服务，例如发短信、上传图片、代理IP。

其次，如果我们把目前企业现有的系统和将要开发和用到的系统，放到这三个圈里，我们就能得出整体的企业架构系统，将会更清晰我们现在有什么以及未来还需要什么。

最后，下一步，就是决定哪些系统应该自主研发，哪些应当直接外部采购，哪些可以进行外包开发。企业要善用并借用外部的力量来完成自己系统生态建设和信息化建设，缩短研发周期、降低成本和更快地推向市场。我的建议是，核心域的系统，一定要坚持自主研发，不能把自己的系统命脉放在别人的手上，一定要充分把控在自己的手上。支撑域，因为需要和核心域的系统进行一定程度上的集成和对接，并且需要根据自己业务的特点进行调整和适配，适合进行外包开发、或合作。企业选择有一定标准化产品的外部企业，然后在此基础上进行定制化开发，会更有成效。剩下的通用域，则是相对好决策的，就是按量或按包租用ECS、短信流量、CDN流量包，这些除非有特殊情况，一般不需要再自主研发，直接在供应商购买即可。

概括来讲，核心域坚持自主研发，支撑域适合外包或外部合作借力，通用域直接采购。

无独有偶，昨晚在看《管理经济学》时，里面也有提到：现货交易、合同、纵向一体化。结合来说，通用域的机会成本低，切换供应商也很方便，比如这家供应的短信费用高，我们可在随时换一家，因为发短信是一件普通的事件并且企业切换成本低，可以直接现货交易、甚至“匿名购买”（是指供应商的销售人员不必知道我方购买人员是谁以及具体需求是什么）直接下单购买，因此没必要为了200多块钱的短信套餐再额外签定一份合同。支撑域，因为涉及专用性投资，为了满足只有自己系统才需要的配套的其他服务和支撑系统，如果企业全部自主研发，就会产生很多部门和官僚主义，并且对内部的挑战也很大。当专用性投资的成本大于或远大于制定合同的成本时，那么可以在对供应商进行对比和评估后，再进行商务谈判，双方约定在合同期限以及服务条款、约束。当供应商能提供的服务、产品越能量化和精确时，合同方式就越能保障甲方企业的利益，避免因机会主义而导致我方企业利益受损。最后，如果供应商报价过高，并且不确定性因素过多，或者制定合同要面临更复杂的环境，甚至找不到匹配的解决方案时，企业就可以考虑自主研发了。

至此，我们理解了终端产品的重要性，以及高层对核心域、支撑域、通用域的决策方向，接下来，在这背后，我们就要看下研发部门在内部，如何通过系统架构和研发规范来保障终端产品的交付和运行。

第二重保障：系统架构

有过互联网从业或开发经验的人，都能理解和知道，系统架构的重要性。有了终端产品还不行，终端产品是静态的，它需要运行在可靠、高性能的系统架构上，才能焕发活力、生机，才能承接流量、承接信息流、促进资金流。

一提到系统架构，我们就可以想到以下关键词：高并发，吞吐量，SLA服务水平，响应时间，最大同时在线人数。

关于高并发

我们需要知道当前系统的历史峰值QPS、当前系统梳理并经过评估后的理论峰值QPS、以及压测的真实峰值QPS，再对应到我们系统能支持的同时在线使用人数。

如何找到历史峰值QPS？这个不难，只需要查看相关的统计报表、云服务器的监控、Nginx访问日志、数据库性能等，就可以找出。要注意同一时间点的关联数据，以及历史峰值发生时刻的那一秒、那一分钟、那一天的最高并发量，将有助于构成完整全面的评估体系和参考数据。

如何评估当前架构的理论峰值QPS？这个稍微有点难度，因为你要完整、清晰、及时收集、汇总并整理画出当前系统的网络拓扑图、服务器部署、各项配置参数、依赖调用关系等，并要在架构师、技术负责人的脑中形成动态的架构图。它是动态的，因为它会随时变化，流量会变，部署会变，业务会变，代码会变，节点会变。随后，充分评估诸如CPU、内存、网络带宽、文件磁盘等核心资源的消耗，就可以推论出理论峰值。

如何找到当前的真实峰值QPS？方案是：进行压测。你可以在测试环境或仿真环境进行压力测试，使用ab或JMeter或其他自动化工具，一方面对正式环境无损伤，另一方面可以通过类比算出正式环境对应的压测结果。你也可以选择在正式环境，摘掉一台服务器进行压测，会更接近真实正式环境的情况。如果只有一台服务器，也可以在闲时进行压力测试。

通常而言，历史峰值QPS < 真实峰值QPS < 理论峰值QPS。

有了以上的数据，就要提前进行下一步的计划，那就是：并发扩容的预案。你可以水平扩容，也可以垂直扩容。垂直扩容就是直接在原来的服务器进行配置升级，这是一个直接有效的短期方案，不需要改代码，不需要重新部署，只需要加钱然后重启服务器就可以了。但这个动作，只是短暂有效，如果并发量超过了单台服务器的负载或者超过了非服务器的负载，这个措施就会失效。你会发现，服务器还是全部卡死的。怎么办？那就需要进行水平扩容了，那就是进行负载均衡分流，做微服务，做拆分。但在这背后，你需要有一套可行、具体的预案。例如，如何部署、如何分流、如何修改发布脚本、如何进行配置等，需要做预案，有什么时间节点、什么人员，需要做什么事情，如何验证。

关于监控

监控，从底层到业务，又可以分为三层：底层的系统监控，中间的健康检测，直观的业务指标监控。

底层的系统监控，更多是关注ECS、服务器的CPU、内存、负载等硬件指标，可以直接使用云服务商的监控和警报，也可以使用类似zabbix的开源软件。及时发现系统层面所存在的毛刺、宕机和异常。

中间的健康检测，是针对每个系统自身的健康检测，主要是检测当前系统正常运行需要用到的服务是否都能正常使用，例如数据库是否畅通、Redis连接是否正常、代理IP是否延时正常等。类似YesDev最近提供的健康检测面板。

关于性能

关于性能，千万不要因小失大，不要把个案当成普遍性问题。

有三个真实的小故事。

有一天，有位客户问我：你会用Redis吗？刚开始有点迷惑，后来才知道客户最真实的问题是当前他的API系统响应慢了，原来平均返回时间是200ms，现在变成了接近2秒。客户以为是由于客户端并发增加所导致的，误以为通过Redis可以提升读写速度。但我一看，服务器的请求量最多才每少20次，客户的服务器PHP-FPM的进程数最多有300个，服务器负载正常，根本不是并发的问题，这是性能的问题。某个接口响应慢，而服务器性能正常，哪怕升级了服务器也没有用，因为这是个案问题而不是普遍的问题。后来，定位到是由于在API接口处理逻辑中使用了Session会话来缓存数据，而客户端的请求是通过代码来调用而不是浏览器，导致每一次API请求都触发了PHP启动新的session会话，从而带来了额外的消耗。后来改成文件缓存，问题解决。

第2个小故障，也很典型。有个在线人数高达上万人数的系统，其中有一个功能，就是需要调用外部的API接口。这个场景很正常，也很普遍。而内部的系统设置的接口请求超时为3秒或5秒或30秒，甚至如果压根不设置超时的话，风险和问题更大。如果这个外部的API接口出现异常，它挂了，或网络不通，就会从这个点引发一系列的问题。首先上这个接口封装后的接口响应慢，随后当前系统卡死（因为很多进程都无法继续服务新的请求，都在阻塞中）。接着，部署在同一台服务器的其他系统服务也随之卡死（因为是共用一台服务器，很多企业都是这样部署的，为了节省服务器成本），最后最后，更多系统卡死。

第3个故障，也是我亲身经历过的。这个故障，我们就像狄仁杰、包大人破案似的。我们通过每次作案的时机、一点点的蛛丝马迹，持续跟踪了几个月，最后在高人的指点下，才找到了这个故障的真正原因和起因。这个故障，三天两头，会导致公司的核心系统和大面积的网站崩溃和瘫痪，每次都是上百万的损失。我们曾经一度以为是同行的恶意攻击，而这个故障的原因是，几年前开发在管理后台写的统计报表，由于需要统计的数据过多，一下子对数据库进行过多的连接。业务人员在操作时，看了界面，没有反应，又点了一次，就这样，操作人员不断点了多次后，就把数据库的连接数蹭蹭蹭地涨上去了。就这样，故障发生了。不知所然，而且操作时机是不确定的，操作人员也不知道是自己的这个操作导致了全公司的系统瘫痪。多么痛的领悟呀。数据库是个好东西，但也要保护好。

这些小故事，都是反而的教材和案例，在进行性能优化和保障时，要引以为戒。

第三重保障：研发规范

最后一重保障是研发规范，这关乎到团队的文化、约定、流程、和人员。

包括但不限于：

• 研发流程
• 发布规范
• 分支管理
• 环境部署
• 提测模板
• 需求评审
• 测试跟踪
• 信息规范
• 安全红线

由于篇幅有时间有限，暂时不展开来讲，后续有机会再来分享。