齐立规矩、共定乾坤——广东移动网管支撑系统入网标准升级亮相

诚取天地正气问人间暖凉

法引规矩方圆律世间万象

身处通信行业，我们常以为用户提供“电信级”的服务为傲，而提供如此高质量的服务则得益于从电信行业从设备生产制造到入网验收，都遵循着一套严格的国际标准。而支撑通信网络生产运维的网管支撑软件系统当然也有与之匹配“电信级入网”标准。

▼

是的，你没有听错，广东移动O域在原有网管规范和技术标准的基础上，结合其在DevOps、微服务架构改造等领域的最新实践成果，编制了新版的《广东移动网管支撑系统入网标准》，目的是让网管O域云平台上所承载的系统拥有能提供“电信级”的软件服务能力，下面就跟着小编一起“划重点”——三步掌握网管系统新入网标准的核心内容。

【认识总体原则】

重点：开源，解耦，受控

先来说说三者的关系，开源是为了掌握核心技术，更好的实现系统和模块间的解耦，进而让系统变得更加受控，总体上实现降本增效。

首先是开源优先原则：

广东移动O域技术栈优先选择开源技术和产品，只在极少数情况下选择商业产品解决方案。

例如：

为了保证系统良好的兼容性、可移植性和扩展性，我们优先选择开源操作系统和数据库（如Linux、MySQL），而不再采用Windows、.NET和SQL Server 等技术，在负载均衡方面我们则选择通过自主研发二次封装后的Nginx软负载方案，而弃用现有的F5、Redware等商用硬负载方案。

编程语言用Java/JavaScript/Python/PHP等跨平台编程语言，大数据处理方面则选用Hadoop的免费版本Hortonworks。

对于个别对性能、功能和稳定性有特殊要求的场景，在目前没有合适的开源替换解决方案的情况下，我们仍然会采用商用方案，如下：

考虑到部分重要系统对集中事务处理的性能要求较高，其关系型数据库仍会承载在Oracle数据库一体机上。

考虑到功能易用性和与DevOps流水线的集成能力，需求管理软件用暂使用付费版的Jira。

考虑到技术演进和变更，虚拟化层不用KVM，阶段性沿用VMWare，未来会转向K8s和Docker的容器化解决方案。

出于保护存量投资，且无明显开源技术优势的情形，则仍然继续使用相关软件。例如，流程引擎沿用普元的EOS，地图组件沿用ArcGis等。

当然，我们还会与时俱进，定期调整技术栈，对一些免费转收费的软件提前寻找替换方案。例如，Oracle将要对Java收费了，未来我们计划转向OpenJDK。

由于不可抗力而必须使用商业产品或不在标准支持范围内的产品，我们会把这类系统部署在单独的资源池里，交给特例系统建设单位自己负责商用产品的购买、搭建、维护和管理。

其次是分离解耦原则：

主要是实现“两分离、四解耦”，即人机分离，D/O分离；软硬件解耦，数据共享解耦，软件功能分层解耦，运维分层解耦。

人机分离：

原则上不允许开发人员操作生产环境，所有运维动作（如启停服务、扩缩容、清除异常状态等）必须固化为脚本和可视化、傻瓜化的网页功能，接入广东移动自建的运维作业平台（Ansible）。

D/O分离：

开发环境、测试环境、预生产（预发布）环境、生产环境分离，分级部署。不允许未经测试和验证直接发布软件到生产环境。原则上，生产环境的所要实施的变更，都必须从通过预生产环境集成验证后的发布制品库中获取，采用自动化的方式进行部署。

软硬件解耦：

软件开发商只需要提供软件产品的业务功能，不需要负责IaaS、PaaS层的建设和维护。

数据共享解耦：

系统间的数据共享，原则上必须通过ESB总线，不允许点对点互联。

软件功能分层解耦：

不是所有系统都能够直连网元、不是所有系统都必须提供报表和大屏页面，这些传统“一脚踢”的通用功能，已经被抽象成6个基础技术平台，2个工具集，9个基础能力中心，1个应用中心。所以，有些功能不用你做的，你只需要提供服务接口即可。如下图所示：

运维分层解耦：

按照ITSM的规范，系统运维可以分为L1/L2/L3三个层次，广东移动O域的所有网管系统的L1运维，都是统一交给一家第三方厂家的。所以，软件开发商在项目验收之前，需要开发出L1运维所需的运维工具，并将L1层的运维知识传递给那家第三方运维厂家。这些要求将纳入“非功能点验收标准”的之中。L2/L3运维目前仍然是原厂负责。

最后是全面受控原则：

所有入驻O域云平台的网管系统，需在源代码、应用日志、系统账号、移动服务（手机APP）、部署架构、开发规范和数据库变更等方面被严格要求，具体内容如下:

源码受控：

所有系统必须从源码开始接入广东移动自建的DevOps生产线（CI/CD Pipeline），实现持续交付，不允许将离线开发完成的制品手工发布到生产环境进行部署。部分非定制化的通用组件，经我们同意之后，可以不交源码，改以依赖库的方式注入产品线。另外，目前我们的CI/CD Pipeline同时支持容器化和虚拟机的部署。

日志受控：

所有系统必须接入广东移动自建的ELK统一日志平台，把所有的应用日志（包括异常事件、接口与组件状态、业务流量流速、用户感知等）提供出来，并依托这一日志平台开发故障定位、性能分析等运维功能。

账号受控：

不允许各系统自建用户账号权限管理体系，必须接入广东移动自建的单点登录SSO，并支持标准要求的六级通用权限体系。简单来说，就是每个系统都要支持手机号码+验证码登录，并根据用户在公司OA上的角色身份，为其赋予系统的默认访问权限。

移动应用（手机APP）受控：

不允许各系统自建单独的移动应用（手机APP），各系统只可以开发移动应用的后台，所有的应用的前台服务（即用户UI相关部分），必须在广东移动掌上运维APP上开发和集成，要么提供源码，要么提供依赖包给掌上运维集成。不允许提供单独的apk或ipa。

部署架构受控：

部署架构必须遵循广东移动的架构规范，实现端到端的高可用。

开发规范受控：

必须遵循广东移动的开发规范，尤其是数据库开发规范、微服务接入规范、ESB接入规范、日志开发与接入规范。

数据库变更受控：

数据库的库表结构、SQL语句的所有日常变更，必须经过功能验证和安全性测试，并经过广东移动DBA团队审核通过之后才能上线。

有个小建议，希望各位供应商在系统开发之前，尽早让广东移动O域的架构师参与架构评审，我们的团队至少有十几年丰富的实（tian）施（keng）经验，可是很牛的。

对了，说了那么多，差点忘了最重要的：

技术路线和架构规划必须与广东移动OSS最新的规划架构蓝图保持一致。目前最新的规划架构蓝图是O3（One Open Oss），我们选定的技术路线，就要跟随哦。见下图：

广东移动网管O3规划技术框架

【了解架构要求】

重点：健壮，弹性

这是对系统微观架构设计的一些较为通用而又不得不提的要求，主要的内容有：

1.流程版本化：

如果软件系统涉及流程，要能支持不同流程的并存。

2.接口版本化：

系统、模块间的调用接口，要带自描述的版本号，向下兼容旧版本。也就是说接口两端系统解耦，可以独立升级。

3.接口要支持：

流量控制、防浪涌、QoS保障、缓存、出错重试。

要实现端到端的流量控制，流程中间经过的各段接口要跟前端收单接口同步扩缩容，避免出现前面放水、后面洪水的情况。

要有机制防止突然的访问量浪涌，包括系统故障或拥塞时产生的雪崩效应、包括恶意爬虫等。机制要优先考虑缓冲、去重，尽量避免简单粗暴的“拒绝服务”。

要对工单的重要性有排序机制，遇到拥塞时，优先处理重要等级高的工单。

所有接口遇到对端停止服务（割接中、或者故障）或者网络抖动，要有缓存容错机制，确保每一张有效工单都被处理，而不是丢失。

4.OLAP/OLTP分开优化、读写分离，分区分表

OLTP事务性、OLAP分析型应用的优化模式不一样。可以将二者分库分表处理。

读为主的数据库操作和写为主的数据库操作要分开，可以使用类似Oracle的ADG技术进行读写分离。

热数据（如：配置数据）要尽量放在内存数据库，定期同步。

场景类应用尽量使用本地持久化技术，避免网络抖动造成的数据缺失。

5.微服务化、无状态化

广东移动已建成微服务管控平台，未来目标是所有应用系统都要微服务化接入这个平台，为微服务提供统一的服务注册、访问路由、配置管理、流量管理、熔断管理、调用链监控以及安全认证等功能。

未来目标是所有用户侧相关服务组件实现无状态化、在此之前，可以先实现容器化+接口解耦。

【掌握开发和运维要求】

重点：开发—持续交付、平滑演进、蓝绿发布

运维四化：

脚本化、可视化、自动化、智能化。

1、持续交付、单件流：

从源码接入DevOps生产线，小步快跑，持续交付。实现一个功能就交付一个功能，不要等一大团功能实现了再一起上线。

2、平滑演进：

新版本的入口放在旧版本上，让用户感受不到系统升级的变化。适当的时候可以使用灰度发布，逐步扩大升级范围。

3、蓝绿发布：

新特性上线必须带上开关，方便上线后随时关闭特性，回到未发布的状态。

4、运维经验不能只存在于某个核心专家脑海中，要固化成脚本，进一步写成可视化的界面按钮，再进一步，根据某些触发条件自动执行。最终目标：

自愈、免维护！

通过以上三步，我们已经大概了解《广东移动网管支撑系统入网标准（2018b版）》的主要内容。更详细的规范，稍后我们将通过正式的渠道予以发布，让我们一起期待吧！