从运维技术架构变化初探运维组织转型

​​关注嘉为科技，获取运维新知

 

运维人员的恐慌

最近在微信常常看到“将来XX年，没有什么工做是稳定的”、“稳定是最大的不稳定”等等文章，联想到本身所在的运维领域和IT行业，很有感悟。

 

运维人员面临的恐慌，恐怕是空前的：

一、从外部来看，IT架构逐步云化，从IAAS到PAAS；市场对运维人员的需求已经不像以前，某个纵深领域的运维专家就能够市场通吃了；

二、从内部来看，公司新的业务形态、谈数字化转型、谈运营，好像永远离运维人员很远，而不断增长的技术栈、不断增加的规模和数量，却又是运维人员必须接受的挑战。

 

如何从内外部环境变化中赢得运维组织转型，和运维人员价值提高的诉求，是无可奈何又必须面临的话题。

 

从康威定律看运维组织的变化

你们都在谈转型，问题在于：转去哪里？

运维组织的转型离不开运维架构和体系的变化，康威定律某种程度上也能够用来指导运营架构。

 

第必定律

Communication dictates design.

组织沟通方式会经过系统设计表达出来。

 

第二定律

There is never enough time to do something right, but there is always enough time to do it over.

时间再多一件事情也不可能作的完美，但总有时间作完一件事情。

 

第三定律

There is a homomorphism from the linear graph of a system to the linear graph of its design organization.

线型系统和线型组织架构间有潜在的异质同态特性。

 

第四定律

The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems.

大的系统组织老是比小系统更倾向于分解。

 

咱们来看看运营技术架构的变化。

 

第一种：传统建设方法。

运维技术架构按所需的功能模块和市面上通用的产品进行不断累加，后期进行功能和数据打通，实现统一数据化运营的大目标。

                                             

第二种：平台化建设方法。

把通用的运维能力存储在平台内部，造成各个原子能力模块，再经过SOA的架构理念进行封装，将运维所需的场景功能，和平台的原子能力模块进行隔离。这样作的好处在于避免了烟囱式的建设方法，运维的数据和功能获得有效的治理。

 

平台PaaS化设计：打造承载全部运维和运营功能的统一平台，平台具有接入资源层、运维服务能力提供和可承载自定义开发应用的能力，平台具有强大的延展性和服务支撑性。

 

场景工具化：将所需的运维功能进行场景化，以工具化的方式运行在统一平台上，调用底层平台所提供的能力服务，实现功能敏捷迭代，功能之间再也不以烟囱式方式构建。

 

这两种运营架构或许能够给咱们一些启示：

一、组织沟通方式会经过系统设计表达出来。第一种的运营技术架构建设是一种离散式的运维组织沟通方式，每一个纵向领域技术组本身进行技术选型，这样带来的组织方式就是传统的方式，公司有不一样的运维组：网络、操做系统、数据库、办公应用、业务应用等，可是每一个组相对独立，这种模式在当前的内外部运维环境下就会遇到问题；

 

二、企业的运维场景每每须要跨系统跨流程跨组织，自然具有个性化、全流程化的特色，这也是当前对运维组织的要求。公司要上线一个自动化发布系统，提高业务上线效率，这个运维场景须要跨多个运维技术领域（系统、数据库、应用运维）、有很强的个性化（A银行与B银行业未必同样）；

 

三、没有完美，只有更好。组织的转型没有一次调整就能解决的，可是与运营技术架构匹配的组织将带来更大的效能。

 

转型蓝图

转型的目标离不开运维的价值呈现，运维须要从运维支撑提高到增值服务，也就是除了稳定，我还要想一想我和个人组织还能多干点啥？想这些也是须要时间的，于是考虑的重点就是可否经过自动化和标准化释放运维人员。

 

示例

运维支撑的职责：

 

增值服务：

 

从PaaS化运营技术架构的变化趋势来看，若是把运维组织当成技术架构来看的话，应该有一个“运维发动机式的组织”，对外输出运维解决方案。而这个组织在PaaS化的技术运营体系下，咱们称之为技术运营组。

 

技术运营组的职责在于：

一、首先利用输出解决方案和工具的方式，将现有人员平常的运维工做效率提高，例如把平常巡检、提数、配置管理等运维操做自动化、标准化，且标准化要体如今简便的WEB交互界面功能上；这样子运维人员就能获得必定程度的解放，他们就能够做为运维组的“甲方”，去仔细思考本身的运维如何更稳定，本身是否能考虑一些运营。

 

二、技术运营组定义好统一的工具开发或场景构建的标准，并构建起流程式的赋能机制，运维逐步转向运维开发；运维开发定义为：企业为了让IT更好的支撑业务的运行和发展，经过构建运维开发团队保障SLA和提高效率，更大的发挥IT在业务中的价值。

 

三、技术运营组不断提高积累公司一体化运营平台的能力，从烟囱式系统建设，转变为平台化建设，只有这样，才能实现更为高效的数据化运营和智能运营。

 

四、自生长式的运营模式；授人以鱼不如授人以渔，给运维人员作工具则能让运维水平不断提高，简单工做自动化、重复工做标准化。

 

五、之前的“运维领域专家”能够选择作“技术运营组”的需求专家，也能够选择转向或靠拢数据分析、运营辅助专家；充分考虑我的职业发展：工做项与我的发展吻合了，员工才会尽全力，作想作的事。例如开发人员-技术专家、架构师，你让他们去作运维操做，他们或许也能作好，但不会尽全力。

 

 传统运维组织转型的问题和风险

传统运维组织通常有按技术领域（基础架构或应用）划分，或按职责范围（例如执行ITIL组织体系的）划分。

组织想要转型，例如要作运营，首要的问题来了：之前的活谁干？

同时还须要考虑更多的问题：

一、组织转型与运营技术架构一定是相辅相成的。技术架构支撑组织转型，组织转型又能持续丰富运营技术架构。

 

二、初次投入与成本的问题。转的过程须要之前的东西仍然稳定，同时又能启发新的东西，于是须要领导有更为长远的视野和坚决的决心。

 

三、转的过程所遇到的内外部阻力。从工具文化出发，先解决部分问题，初见成效并呈现价值后，再持续解决问题。

 

四、是否每一个人都能转型成功？这是须要领导者更为客观来看待的问题，以及转型过程的引导和安抚，让不一样的人员都去作对应程度的提高和转变。

 

转型过程的思路

运维组织转型的三个维度：流程、我的职业规划和工具平台。

 

传统组织下运维人员具有各个领域运维技能，保障技术设施运行稳定性，而面对业务更为敏捷和灵活的要求时，须要运维组织可以快速响应运营场景的需求，而借助于PaaS提供的运营场景开发服务，传统运维组织可以从保障稳定性上逐步提炼出更高的价值。

 

不一样于业务系统的开发，运营场景的开发是运维人员进行运维开发转型后能足够胜任的，并且更懂运维与运营的是实际拥有维护经验的人，基于平台化的方式，使得运营场景的构建更为敏捷，组织能力得以总体提高。

 

蓝鲸研发运营一体化平台技术架构

蓝鲸智云，简称蓝鲸，是腾讯IEG事业部“腾讯智营”下的一个子品牌（网址：bk.tencent.com/）。蓝鲸是一套基于PaaS的技术解决方案，提供了完善的先后台开发框架、调度引擎、公共组件等模块，帮助业务的产品和技术人员快速构建低成本、免运维的支撑工具和运营系统；蓝鲸是腾讯互娱事业部沉淀多年的技术运营支撑体系，承担着数百款业务线上运营的使命。

 

咱们能够从IEG事业群的业务特色，来探索总体体系是如何诞生的：

 

一、腾讯IEG游戏运营所遇到的业务痛点：

• 有几乎全部的业务类型：重客户端游戏，网页游戏，各种官网，移动终端游戏，大型游戏平台；

• 全部业务之间无关联：几百款游戏相互之间是没有关系的；

• 有几乎全部的流行技术：腾讯游戏几百款业务中，大多数是由世界各地开发商开发出来，所使用的开发语言、开发框架、操做系统、数据库等技术，是没有直观规律的；

• 业务操做单元海量：服务器数量，也就是操做单元，有十余万。

 

二、转型曙光：平台原子化，抽象再抽象；

蓝鲸设计思路：尽量将单个步骤抽象为原子，再将原子自动化，然后经过任务引擎链接成“串”或者“树状分支结构”实现全自动化。这样作的优势在于：不依赖业务类型，不依赖架构，不依赖场景，只要运维手工能作的，均可以作成无人值守。

 

三、不断累积原子平台能力；

把各个运维和运营场景进行抽象，抽象出大部分典型场景都须要获取业务配置，和进行做业执行，这个时候，蓝鲸配置平台和做业平台就产生了，而抽象出来的这种原子平台就成为了PaaS能力池的能力块。

 

四、原子平台集成；

原子平台越建越多，可是原子平台最终都是用来消费和调用的，于是接下来进行总体集成，总体架构上用了SOA架构，而服务模块上则会灵活使用微服务架构。

 

五、平台化开发模式让运维应用自生长；

这个阶段则是真正的释放了运维，平台作好了，搭建服务SaaS开发生命周期的系统组件，使得运营场景可落地为SaaS进行自生长，最大规模时，蓝鲸平台上运行了1000多个SaaS服务于各个业务各个运维和运营场景，而这些场景都是运维人员作出来的。

 

六、自生长的运营平台，才能“完美解决”运维和运营的复杂性和多样性：

• 支持多语言的开发框架；

• SaaS免运维托管；

• 企业服务总线统一集成；

• SaaS运营数据可视化。

 

七、  最后造成的IEG事业群内部运营技术架构：

 

以上为笔者对运维组织转型的理解和分析，欢迎探讨交流，谢谢！