建设研发运营一体化平台

lili_qq

目
录
: T+ a) m  S3 O4 d# I5 y) y8 P. d1 b8 K

• 研发运营一体化平台是未来IT建设的方向
• 建设“研发运营一体化”，从哪些方面着眼？
• 时间维度的建设目标：自动化、数据化、智能化
• 空间维度建设目标：监、管、控、流程、分析
• 组织与团队
• PaaS平台与SaaS场景分离，沉淀工具文化
  . P' V' e; o/ g6 X

研发运营一体化平台是未来IT建设的方向
0 x( m" ]% j- D! T “一切以业务为中心”应该说已经成为IT界的共识，研发部门也好，运维部门也好，共同的目的都是支撑好业务的发展。
在这样的共识下，研发和运维部门由传统的独立、相对隔离，逐渐走向融合和统一，也是必然。伴随着DevOps、微服务、敏捷、运营自动化等理念和技术的逐步成熟、完善，这一进程正在加快。
5 z; L3 g( A$ ~ 在一套平台上实现研发和运维的敏捷、紧密、流畅的协同和配合，建设研发运营一体化的IT运营平台，是现在的共识，是未来的方向。
建设“研发运营一体化”，从哪些方面着眼？
% @; M+ f$ p. h5 d 理论基础、组织架构、工具平台，这三个方面可能是我们要重点考虑的。
( a$ L& r% z0 w' V

- u2 V& r4 X, F 首先需要明确建设的目标和方向，通过调研、沟通、讨论和决策，确定建设的方向和建设的口号。目标本身可能按照时间和空间维度又有不同：在未来的不同时间点上，要达成怎样的建设目标；在当前空间的能力状态下，要达成怎样的建设目标。
' F& J$ Z+ H" T, d( u5 L 我们用于指导确立目标的理论基础有哪些：ITIL、ITOM、DevOps、精益敏捷、行业标准、巨头公司最佳实践、国家标准？这些理论基础在当下是否是正确的？用于指导目标的确立是否是合适的？于我们需要达成的业务目标是否是有益的？这些可能是我们需要考虑清楚的。
其次针对我们要实现的目标，要经过怎样的分解，确保能够责任到团队、责任到人，确保有人在全力以赴推动目标达成。以及我们当前的IT架构是否需要进行调整，以确保目标的达成。
7 b4 W) @+ D# d% T  \9 ^8 P* o 最后我们需要选购或者研发怎样的产品、工具或者平台，才能确保我们的目标是可行的，是可达成的。中间还需要考虑产品或者平台本身的成本、建设周期以及是否有益于目标的持续推进。
* w$ h" t& Y2 y  e0 j  ~ 时间维度的建设目标：自动化、数据化、智能化
我们的浅薄理解：在时间维度上，“研发运营一体化平台”从能力层面大体上应该会经历“自动化”、“数据化”、“智能化”三个阶段。
. G( V3 X( {: _9 N. s
在“自动化”阶段，重点在于实现工具驱动运维。“自动化”，顾名思义，重点通过平台和工具实现研发、测试、部署、运维、运营等IT场景的自动化。将以往断点的、手工的、孤立的场景，通过平台和工具的自动化能力，悉数串联，在可视化界面中，打通从研发到运营的整个IT流程。
在“数据化”阶段，重点在于实现数据驱动运维。通过在平台中接入大数据模块，实现研发、运维和运营的数据的接入、存储和分析，在对数据进行全面挖掘和分析的基础上，实现研发运营的数据化驱动。例如，通过搜集用户对于某个新功能的体验数据来判断是否启动新的研发需求和研发计划，来改变业务或者应用的体验。
在“智能化”阶段，重点在于实现机器驱动运维。这个阶段是比较靠后的阶段，需要前面两个阶段的能力积累和传递。在这个阶段，基于智能算法的机器学习来训练智能运维/运营机器人，实现无人值守和智能的运维与运营。
三个阶段，彼此独立，又相辅相成，共同构成“研发运营一体化平台”时间线上的建设目标梯度。
& r+ r% u1 }2 z& I5 h5 t 空间维度建设目标：监、管、控、流程、分析
无论“研发运营一体化平台”的建设处于哪个时间目标点，可能都需要考虑IT对象的监、管、控、流程、分析。
: J2 V  u4 }: X8 L3 L; R
监：对于业务、应用以及支撑应用的组件进行整体的监控，并能够对接故障自愈模块，实现流程内故障的自动恢复。
  p/ R- n" C( H+ |# f2 o 管：IT对象的配置管理，统一的配置中心，提供配置数据，用于支撑研发运营一体化中的场景。
控：通过SaaS层工具实现研发、测试、部署和运营各个场景的自动化、数据化和未来的智能化。
流程：通过平台对接流程平台，实现ITIL流程的自动化执行。
分析：在自动化和数据化的基础上，通过提取数据进行分析，来得到研发运营中某些方面的知识。
针对IT对象的监、管、控、流程、分析，贯穿于“研发运营一体化平台”建设的整个周期中，通过这几个方面的实现，来构建不同阶段的“研发运营”的整体蓝图。
组织与团队
. Q& ~7 }, X" E9 W0 u  ]9 ? 在实现“研发运营一体化平台”建设过程中，从技术角度而言，组织与团队本身可能也需要经历某些调整，以便与目标匹配。

例如，如若采用蓝鲸作为构建“研发运营一体化平台”的整体PaaS平台，由于蓝鲸的PaaS平台与SaaS场景分离的特性，传统的运维团队会经历一些裂变：

• 部分擅长于SaaS工具开发的人员转型为运维开发，专职于技术运营SaaS工具的构建；在数据化阶段，可以进一步提升为运维AI工程师；
• 部分擅长于运营需求沟通和规划的人员转型为运维规划，专职于需求对接和工具规划；未来有可能进一步提升为运维数据分析师；
• 而传统的运维操作部分的工作，则可能由成本更低的专职的运维职能团队或者运维外包团队使用构建的工具去执行。
  ; z$ L3 J0 _' {4 z

依托平台提供的内部生态，使得IT团队人尽其才，各展所长，稳定成长；对于业务目标和IT建设目标的实现有着积极的作用。
PaaS平台与SaaS场景分离，沉淀工具文化
“研发运营一体化平台”的建设落实到具体的方案或者产品的选择阶段，我们的粗浅理解是：应该摒弃以往的烟囱运动—即通过不断部署更新的、更多的、彼此孤立的烟囱式工具和产品来解决问题，而应该基于统一的PaaS模式平台，通过运维开发模式来实现场景SaaS工具的构建，构建企业内部的研发运营生态体系，沉淀自己的工具文化。
5 B) \1 {% E( r$ B) \' x3 d8 z& w
研发运营一体化平台架构图
& s1 T& U- D" {3 t7 f0 } 由于平台本身采用SOA松耦合架构模式，针对时间维度的建设目标：自动化—数据化—智能化，通过PaaS平台中接入“数据平台”模块、“AI平台”模块，能够实现PaaS平台本身由自动化平台向数据化平台、智能化平台的进化。
$ n: W. f! Y( w, X 同时由于平台本身PaaS平台与SaaS场景分离的特性，PaaS平台本身的升级并不影响SaaS工具的使用，两者是松耦合关系；因此，我们能够基于平台本身提供的前后端开发框架，使用Python持续沉淀我们的工具文化，去覆盖研发（CI）、部署运维（CD）、运营（CO）等应用的完整生命周期。
$ O; F3 \% p1 ~, y SaaS工具的运维开发，同样遵循OASR的方法论体系，如下所示：
2 r! h: a  w, w& t7 S& `) i
0 u1 k4 @  r9 q 所谓的工具文化指的是：能用工具的地方不用人，必须用人的地方用工具辅助人。
由此，工具文化需要解决的核心问题就是：需要为哪些人（角色）的哪些日常工作（场景）的哪些IT对象的哪些活动提供工具。
% K1 \! d% ^6 I9 y3 g/ n% | 例如，我们分析一个系统管理员的工作，可能如下：
1 e& j' A; W' V7 T0 E% K 运维的对象：windows系统、Linux系统、AIX系统等；
涉及的运维活动可能包括：部署系统、初始配置、软件安装、基线管理、安全管理、日常巡检、补丁修复、日志分析、故障排除等；
# e; d3 e1 N% G6 l4 D: d: E 上面的活动所属的场景可能包括：系统资源交付、系统日常管理、系统可用性保障、系统安全保障等；
1 C9 Q: ]5 _% s 执行这些操作的角色就是：系统管理员。
8 }6 B& m& Y: ^ 针对上面这样一个需求，完全可以在纳管Windows、Linux、AIX的基础之上，将所有这些运维场景和活动纳入一个“系统管理门户”APP，为系统管理员定制一个PaaS平台之上的SaaS工具，使得其能够在这样一个工具中实现日常绝大部分工作的自动化执行。
+ z/ `, Q& D# F+ h9 s8 h- v
4 f' C% s6 Z0 B( x! C) X 系统管理门户
4 N9 x. p: M4 [( g “研发运营一体化平台”是IT未来建设大的方向，也是一个逐步推进和更迭的过程。路漫漫其修远兮，吾将上下而求索。
一家之言，抛砖引玉，也欢迎各位同侪前辈在留言区一起探讨。

" j4 x% p/ z/ q2 [( g

jack_are

要解决信息系统的系统异构集成、数据共享和数据交换传输标准等关键性技术问题。

STGing

从集成的层面上，需要考虑三个层面：数据层面、应用/服务层面和流程层面。即各应用系统在数据层面可以相互交换，在应用层面可以互相调用，在流程层面可以协同在一起实现全院级的业务协同；从集成的手段上，包括点对点集成和通过平台来集成，要实现全院级集成，应当通过平台化的手段来实现。