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

运维人员的恐慌

最近在微信经常看到“未来XX年，没有什么工作是稳定的”、“稳定是最大的不稳定”等等文章，联想到自己所在的运维领域和IT行业，颇有感悟。

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

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

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

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

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

大家都在谈转型，问题在于：转去哪里？

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

第一定律

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化设计：打造承载所有运维和运营功能的统一平台，平台具备接入资源层、运维服务能力提供和可承载自定义开发应用的能力，平台具备强大的延展性和服务支撑性。

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

这两种运营架构或许可以给我们一些启示：

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

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

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

转型蓝图

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

示例

运维支撑的职责：

增值服务：

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

技术运营组的职责在于：

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

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

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

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

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

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

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

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

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

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

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

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

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

转型过程的思路

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

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

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

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

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

我们可以从IEG事业群的业务特点，来探索整体体系是如何诞生的：

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

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

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

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

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

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

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

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

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

4、原子平台集成；

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

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

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

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

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

• SaaS免运维托管；

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

• SaaS运营数据可视化。

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

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