建设背景
在科技持续赋能业务创新发展的时代背景下，要求科技基础能快速满足敏捷、高效的业务创新需求和高度灵活、可扩展的开发运维需求，电力运维传统技术架构和开发运维模式越来越难以适应未来电力服务发展要求，主要存在以下挑战。
一是面对运维服务线上化、场景化、生态化的客观形势，传统单体式架构高耦合性的特点，导致团队沟通成本高、相互依赖强、扩展能力不足，严重掣肘了产品快速创新。二是在传统开发运维模式下，开发和运维两者的目标诉求不一致，流程上也存在割裂的情况，一定程度上减缓了IT交付业务价值的速度。三是传统基于物理机、虚拟机的资源分配、管理和调度能力较弱，扩展能力有限，资源利用率不高。四是系统、网络、应用、数据等各维度的运维监控依赖于各类异构的监控产品，存在监控孤岛，无法及时汇总分析监控信息。
技术实践
项目融合微服务、容器化、DevOps等最新理念，集成了多种开源技术，通过深入分析选型、定制化开发改造，组件式搭建敏捷开发运维平台。平台选用Dubbo、Nacos、Apollo提供微服务化的基础框架服务和运行环境;使用Docker作为微服务的应用载体;采用Kubernetes动态管理微服务的调度，提供服务发现和应用支撑能力;部署Elasticsearch、Logstash和Kibana实现分布式日志系统的汇集，搜索和分析;通过Jenkins提升自动化构建水平，为DevOps流程提供工具化服务;基于Prometheus和Zabbix实现多层级整体监控方案。
1.构建微服务基础架构，实现业务解耦
平台以应用微服务化为核心，提供非侵入式分布式架构基础组件服务，包括应用模板、注册配置、消息队列、日志搜集、全链路追踪等，助力微服务应用快速接入，支持可视化编排服务启动，管理应用服务全生命周期，有效解决微服务的分布式特点带来的管理复杂性。平台可智能选择负载均衡最佳流量模式，判断需要熔断限流的服务，实现自动化的服务治理功能。平台通过外部化应用配置管理，将服务配置与应用解耦，支持配置的实时更新和敏感数据的加解密。应用启动过程中相关模块自动连接配置中心读取相关的配置数据并初始化，大幅简化了过去繁琐的配置工作。
2.实现容器化弹性能力，提升资源利用率
平台采用高可用、高弹性的容器云技术，在业务峰值时可根据策略自动增加业务层容器数量和集群层的节点规模，通过双层动态扩展应对大流量、高并发场景，在业务低峰自动缩减运行环境。同时可以复用IaaS私有云资源，支持虚拟机、物理机等多种环境，统一管理计算、网络、存储等基础资源，避免重复建设。因此，相较传统虚拟化技术，敏捷开发运维平台具备更智能的资源调度策略以及更高效的资源管理能力，进一步提高资源利用率。
3.完善监控运维体系，快速定位解决问题
平台已构建涵盖系统、应用、数据、网络、容器等多维度多层次运维体系，具备完善的负载均衡、性能指标监控、日志监控、故障报警等功能，在监控界面上可迅速获取平台状态、系统用户、资源分配、应用拓扑、业务健康状态等数据，提供详细的技术指标和极简的操作体验。针对微服务应用，在框架层面实现了对请求调用路径的监控，图形化展现树状结构的调用链路关系，便于问题快速定位。支持通过统计分析调用链监控数据、日志信息、系统性能指标，更合理的提出应用优化方向。
4.标准化应用交付，简化应用上线部署
平台采用容器镜像作为统一软件交付物，加强了软件版本控制，结合配置中心，确保多环境一致性交付，避免因环境不一致所引起的一系列部署运行问题。平台支持应用系统的灰度发布及多版本发布管理，让新老版本同时运行并可实现策略分流，进而精细化控制业务影响范围。同时支持一键式应用升级或回滚，简化运维人员投产上线工作，降低版本发布风险。
5.优化网络组件，提升网络性能及安全性
为满足运维机构的网络安全需求，为平台设计了二层网络方案，可无缝嵌入SDN网络，使容器具有类似虚拟机的使用体验，便于应用容器化推广。平台将容器内的应用与非容器的应用置于同一网络层面，更易于制定网络安全策略，且与开源方案相比，减少了转发损耗，提升了网络性能。此外，平台为应用系统提供4层和7层的统一软件负载均衡、健康检查等能力，监控应用系统可用性，支持最小连接数、源地址散列等多种转发策略，并可根据流量进行负载均衡器横向扩展，提升平台入口处性能和可靠性。
平台成效
基于平台，结合容器和微服务的技术特点和优势，浙商银行设计并实现了以下DevOps流程，如图1所示。流程实现从源码、构建、打包、测试、审批到发布的全自动化，提供灵活的定制能力，可根据人员角色和组织架构动态调整，使金融业务项目管理兼顾严谨性和敏捷性。DevOps流程重塑开发和运维之间传统的合作方式，将二者融入统一业务流程，加强了协同和沟通效率，以完善业务产品为共同核心目标促使业务持续改进，将追求稳定性的业务运维和开发过程的创新保持同步，有效提升了开发、测试、投产及运维的一体化、标准化、自动化。
我们容易搞混的一个概念就是平台和软件的区别，平台本身不仅仅一个技术概念，更多是包含了商业上的内涵，通过平台构建一个开放的基础设施，核心能力是连接;平台的存在，能够提升连接效率，实现更多场景协同;在消费互联网领域，美团，京东，淘宝把软件作为载体，联通线上和线下的交易;而在产业互联网，则有些不同，比如XX管家提供运维平台给客户，软件本身免费，通过服务获取收益。
脱离商业本质来谈软件产品和平台产品区别，意义并不是很大，是否部署在云端和本地，只是技术难度有区别。目前拥有平台并参与市场竞争的玩家大致可以分为三类：
第一类是硬件开发商，这些厂商主要利润来源是销售硬件，推出软件平台的主要目的是带动硬件的销售，硬件利润高，软件不值钱，久而久之使得软件部门的价值很难得到体现，开发的产品也摆脱不了东拼西凑的影子，进而影响到整个公司的数字化战略的推进。
第二类是软件开发商，相对于硬件开发商，软件开发商利润来源有两种，一种是单纯的软件的销售获取收益，软件商和硬件商销售模式就趋于一致了。这种情况下，软件企业往往面临客户的质疑，为什么硬件厂商的提供软件产品可以免费送，而软件厂商产品却需要单独购买，你的产品好在哪里，我为什么要花钱?软件厂商们必须证明客户为此花钱是值得，这是一个市场培育的过程;另外一种是基于平台提供SAAS服务，在这种模式下，用户可以省去高额的一次性软件使用费，软件厂商通过后期的例如能源托管，电费计量，运维等服务获取收益，并且随着规模的增加，单个用户成本逐渐减少，这种商业模式有点接近于消费互联网了，但不完全一样，消费互联网是“小场景、大流量”，即消费领域的细分小场景，但每个场景可以连接数海量的用户;产业互联网是“多场景、小流量”，每个细分场景用户不多，但每个场景都能跑通，则需要线上线下服务联动闭环，这对企业来说是很考验内功的。
第三类是系统集成商，这个有点像工程领域的EPC承包商，对于用户来说，无论是硬件设备选型，工程实施，平台构建，后期的服务运维，每个领域都有较高的业务壁垒，都是需要耗费大量时间和精力沉淀和积累，系统集成商能够以更专业更经济的角度给用户一站式服务，并在此基础上实现自身业务的闭环。即传统工程、设备和软件向服务业务转型，EAAS工程即服务。在服务的过程中，平台起到了串联的产业链作用，提升服务效率，这是真正意义的平台商业模式。否则搞定了业主方，靠卖软件，卖设备，而且卖出去就不管了，还是始终在传统项目理念，无法真正解决用户痛点，最终是无法形成核心竞争力。
笔者曾经调研过国内某家上市公司推广云平台的策略，该公司是以仪表和电气终端设备为主营产品，同时也配套云端产品给用户服务，其商业策略有二：
用户自营: 用户自身具备运维能力，平台商指导用户完成设备安装和调试和运维人员培训，并将软件部署在用户服务器上，此时用户需要一次性支付软件费用。
数据托管：用户不具备运维能力，平台方帮助用户完成设备安装和调试，用户将数据上传至平台方服务器，委托平台商管理，平台方按约定收取软件基础费用和托管费用。费用和终端数量和数据规模相关。
随着物联网、大数据、移动互联网等新一代信息技术与城市生活的深度融合，越来越多的应用场景与服务模式被“解锁”。眼下，信息技术手段正赋予配电运维平台全新的生命力。
