论文部分内容阅读
【摘 要】按照公司信息化规划“创新驱动、技术引领”的目标，以创新驱动专业发展，提升基層组织创新活力，促进专业创新协同。以快速响应业务需求为原则，基于互联网思维，有序推进云化、移动化、数据化、AI化的IT架构升级，构建灵活的营销业务支撑信息生态体系，以实现公司的数字化转型。
【关键词】南网数字化;Devops;转型;应用
一、为什么DevOps
为有效实现公司信息化目标，在数字化转型推进过程中，公司对当前较为突出的问题进行深入调研摸底，主要表现在：
1、IT架构针对业务诉求响应慢，客户诉求得不到快速解决，影响用户体验和满意度，与公司“以用户为中心”理念存在差距。
2、公司营销业务分布面广，各地区个性化需求突出，导致营销系统变更频繁。
3、长期以来基于传统IT架构下的开发和运维分工职责和分工不明确，代码开发、测试和系统发布部署质量得不到保障。
针对上述三大长期存在的困扰，需要将需求、开发、测试和运维等工作整合在一起，并使这个“有机体”长期有效的持续进行。借鉴于大型互联网公司的成功经验，devops的引入是必然之选。
二、Devops实践
2.1 核心内容
2.1.1 组织架构
南网作为国家电力行业重点企业，体量大，业务覆盖范围广，而营销系统作为业务支撑的核心系统，在数字化转型中升级变更牵一发而动全身，影响范围广，风险高。在数字化转型过程中力求双态并行（稳态和敏态），是南网信息技术管理的前提条件。如何能够有效的落实双态，Devops是南网的不二之选，如何能够做到“三用”，最终转型成功，关键在于组织架构顶层设计是否正确。因为企业的组织架构站在企业“金字塔”制高点，以业务为出发点自上往下看，相对传统的基于技术驱动的IT组织架构自下往上看，更具战略前沿性。
南网通过其信息化部门成立数字化研究研（上述所指“公司”），再针对各业务组建部门，以自主研发、自主可控为主，通过部门和外部先进企业合作共建的模式，吸取外部科技力量，快速提升自身技术力量，培养具有较强研发能力的技术骨干。遵循devops理念，在开发层面由公司主导，外部企业为辅，借助外部企业先进技术，快速提升自身研发能力。在运维层面核心技术架构坚持独立自主，业务上则与各厂商联合运维，吸取外部企业经验，不断完善自身团队。
2.1.2 devops工具
随着信息技术的不断发展，IT架构已经逐渐从昂贵的“IOE”模式转向廉价的“X86”和开源的互联网模式，IT管理层面也由过去求“稳”的ITIL V3面向流程管控模式转向求“敏”的devops模式。在此大势下，应用于devops的开源工具如雨后春笋般涌现，比较典型的devops应用工具为docekr+jenkins+git+harber+kubernetes。
公司的devops工具选型综合权衡公司已有平台资源、成本和安全可靠性，在持续集成方面选用成熟的开源工具框架docekr+jenkins+git，在持续部署方面则选用大型厂商产品腾讯云TSF。开发人员完成代码开发并将其提交到git公共代码仓库，运维人员通过jenkins从git公共代码仓库将应用程序代码打包到docker容器中，形成docker镜像，再将docker镜像通过TSF部署到生产环境中。
2.1.3 团队能力建设
devops之所以是当前应用运维的主流，其最重要的原因之一是改变传统的运维模式。传统的运维模式下开发、测试、发布、部署这几个软件管理节点人员投入大、软件发布周期长，开发运维协调效率低，通常情况下开发运维不能明确分清责任边界，运维人员常贴上“背锅侠”标签，软件管理质量差，特别是在海量的服务运维中，大部分企业只能通过加人头、加班，运维人员苦不堪言。在devops体系下，持续集成、持续部署、自动化测试则成为其代名词，开发团队关注持续集成，测试团队关注自动化测试，运维人员关注持续部署。devops与传统体系相比，表面上对开发和运维只是加了“持续”两字，测试加上“自动化”三字，前者看起来简单，但理解却很难，后者看起来容易理解，但做起来却很难，因为“持续”和“自动化”都对其使用团队的技能要求高很多，特别是在开源的环境下，则越发突出。此时开发团队不再是单纯的只懂开发，因为交付物发生了根本的改变，传统的开发产出的是可执行的程序，而现在要求的是容器镜像，其中涉及的技术栈更多，要求的综合知识面更广;运维团队也不再是单纯的只懂运维，也需要有开发思想，随着发布的便捷化，敏态优势凸显，运维的工作任务更多，要求运维人员能够通过“编程”实现应用镜像容器的编排部署。测试团队在“自动化”思想下，转变则更大，需要融入到开发团队去，在代码构建完后，与开发人员一道“或者转化为开发人员自行”编写自动测试脚本，实现代码拉取、构建、测试和发布自动化。
2.2 分阶段摸索
正如前面3.1所述，Devops的体系建设，由于严重依赖于devops工具和团队能力，所以整个过程不是一蹴而就，而是需要分阶段推进，逐步探索。基于公司刚组建完成现状，以团队视角，可以分以下四个阶段进行：
第一阶段，devops团队的组建，包括人才的储备、企业IT环境的熟悉和工具的选型三方面工作。经过1-2年的协调运作，形成基本的开发运维体制，能够应对日常的开发运维工作。此时团队的技能水平低下，成员间协助度过磨合期，开发运维效率低下，但是不影响正常的业务运作。
第二阶段，devops团队的提升，包括成员的能力大幅提升，业务运作成熟稳定，规范IT管理。此阶段中，一方面成员由于少了前期对IT环境、业务流程适应的困扰，积累了基本的技能和技术运行模板（包括程序，脚本等），开始着力提升更为适合业务增长的技能，使大量重复的劳动自动化，以腾出更多的工作时间用于自我学习、自我提升;另一方面，领导开始从管理上缩紧，逐步规范团队行为，建立更为完善的IT管理规范。经过2-3年的发展，趋向成熟，团队达到社会生产水平的中上水平。
第三阶段，devops团队的成熟，包括成员协作有序，业务谋求创新。此阶段中，团队之间的协调高度默契，常规的开发运维业务流程处于自动化，整个IT环境氛围良好，团队开始追求更高层次的挑战--智能化，“科技电力”口号吹响，团队着力于以应用技术创新推动业务的创新，以谋求为用户带来更好的体验。
参考文献：
[1]钟群.供电企业检修技改项目管理现状与完善对策[J].企业技术开发，2011（2）.
[2]李忠军.对电力企业设备维修管理模式的若干探讨[J].中小企业管理与科技，2010（6）.
（作者单位：南方电网数字电网研究院有限公司）
【关键词】南网数字化;Devops;转型;应用
一、为什么DevOps
为有效实现公司信息化目标，在数字化转型推进过程中，公司对当前较为突出的问题进行深入调研摸底，主要表现在：
1、IT架构针对业务诉求响应慢，客户诉求得不到快速解决，影响用户体验和满意度，与公司“以用户为中心”理念存在差距。
2、公司营销业务分布面广，各地区个性化需求突出，导致营销系统变更频繁。
3、长期以来基于传统IT架构下的开发和运维分工职责和分工不明确，代码开发、测试和系统发布部署质量得不到保障。
针对上述三大长期存在的困扰，需要将需求、开发、测试和运维等工作整合在一起，并使这个“有机体”长期有效的持续进行。借鉴于大型互联网公司的成功经验，devops的引入是必然之选。
二、Devops实践
2.1 核心内容
2.1.1 组织架构
南网作为国家电力行业重点企业，体量大，业务覆盖范围广，而营销系统作为业务支撑的核心系统，在数字化转型中升级变更牵一发而动全身，影响范围广，风险高。在数字化转型过程中力求双态并行（稳态和敏态），是南网信息技术管理的前提条件。如何能够有效的落实双态，Devops是南网的不二之选，如何能够做到“三用”，最终转型成功，关键在于组织架构顶层设计是否正确。因为企业的组织架构站在企业“金字塔”制高点，以业务为出发点自上往下看，相对传统的基于技术驱动的IT组织架构自下往上看，更具战略前沿性。
南网通过其信息化部门成立数字化研究研（上述所指“公司”），再针对各业务组建部门，以自主研发、自主可控为主，通过部门和外部先进企业合作共建的模式，吸取外部科技力量，快速提升自身技术力量，培养具有较强研发能力的技术骨干。遵循devops理念，在开发层面由公司主导，外部企业为辅，借助外部企业先进技术，快速提升自身研发能力。在运维层面核心技术架构坚持独立自主，业务上则与各厂商联合运维，吸取外部企业经验，不断完善自身团队。
2.1.2 devops工具
随着信息技术的不断发展，IT架构已经逐渐从昂贵的“IOE”模式转向廉价的“X86”和开源的互联网模式，IT管理层面也由过去求“稳”的ITIL V3面向流程管控模式转向求“敏”的devops模式。在此大势下，应用于devops的开源工具如雨后春笋般涌现，比较典型的devops应用工具为docekr+jenkins+git+harber+kubernetes。
公司的devops工具选型综合权衡公司已有平台资源、成本和安全可靠性，在持续集成方面选用成熟的开源工具框架docekr+jenkins+git，在持续部署方面则选用大型厂商产品腾讯云TSF。开发人员完成代码开发并将其提交到git公共代码仓库，运维人员通过jenkins从git公共代码仓库将应用程序代码打包到docker容器中，形成docker镜像，再将docker镜像通过TSF部署到生产环境中。
2.1.3 团队能力建设
devops之所以是当前应用运维的主流，其最重要的原因之一是改变传统的运维模式。传统的运维模式下开发、测试、发布、部署这几个软件管理节点人员投入大、软件发布周期长，开发运维协调效率低，通常情况下开发运维不能明确分清责任边界，运维人员常贴上“背锅侠”标签，软件管理质量差，特别是在海量的服务运维中，大部分企业只能通过加人头、加班，运维人员苦不堪言。在devops体系下，持续集成、持续部署、自动化测试则成为其代名词，开发团队关注持续集成，测试团队关注自动化测试，运维人员关注持续部署。devops与传统体系相比，表面上对开发和运维只是加了“持续”两字，测试加上“自动化”三字，前者看起来简单，但理解却很难，后者看起来容易理解，但做起来却很难，因为“持续”和“自动化”都对其使用团队的技能要求高很多，特别是在开源的环境下，则越发突出。此时开发团队不再是单纯的只懂开发，因为交付物发生了根本的改变，传统的开发产出的是可执行的程序，而现在要求的是容器镜像，其中涉及的技术栈更多，要求的综合知识面更广;运维团队也不再是单纯的只懂运维，也需要有开发思想，随着发布的便捷化，敏态优势凸显，运维的工作任务更多，要求运维人员能够通过“编程”实现应用镜像容器的编排部署。测试团队在“自动化”思想下，转变则更大，需要融入到开发团队去，在代码构建完后，与开发人员一道“或者转化为开发人员自行”编写自动测试脚本，实现代码拉取、构建、测试和发布自动化。
2.2 分阶段摸索
正如前面3.1所述，Devops的体系建设，由于严重依赖于devops工具和团队能力，所以整个过程不是一蹴而就，而是需要分阶段推进，逐步探索。基于公司刚组建完成现状，以团队视角，可以分以下四个阶段进行：
第一阶段，devops团队的组建，包括人才的储备、企业IT环境的熟悉和工具的选型三方面工作。经过1-2年的协调运作，形成基本的开发运维体制，能够应对日常的开发运维工作。此时团队的技能水平低下，成员间协助度过磨合期，开发运维效率低下，但是不影响正常的业务运作。
第二阶段，devops团队的提升，包括成员的能力大幅提升，业务运作成熟稳定，规范IT管理。此阶段中，一方面成员由于少了前期对IT环境、业务流程适应的困扰，积累了基本的技能和技术运行模板（包括程序，脚本等），开始着力提升更为适合业务增长的技能，使大量重复的劳动自动化，以腾出更多的工作时间用于自我学习、自我提升;另一方面，领导开始从管理上缩紧，逐步规范团队行为，建立更为完善的IT管理规范。经过2-3年的发展，趋向成熟，团队达到社会生产水平的中上水平。
第三阶段，devops团队的成熟，包括成员协作有序，业务谋求创新。此阶段中，团队之间的协调高度默契，常规的开发运维业务流程处于自动化，整个IT环境氛围良好，团队开始追求更高层次的挑战--智能化，“科技电力”口号吹响，团队着力于以应用技术创新推动业务的创新，以谋求为用户带来更好的体验。
参考文献：
[1]钟群.供电企业检修技改项目管理现状与完善对策[J].企业技术开发，2011（2）.
[2]李忠军.对电力企业设备维修管理模式的若干探讨[J].中小企业管理与科技，2010（6）.
（作者单位：南方电网数字电网研究院有限公司）