行业动态

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

运维人员的恐慌

最近在微信上经常看到诸如“未来XX年没有工作是稳定的”、“稳定是最大的不稳定”之类的文章。想想运维领域和IT行业，我还是挺开明的。

运维人员面临的恐慌恐怕是前所未有的：

1、从外部来看，IT架构正在逐渐云化，从IAAS到PAAS；运维人员的市场需求不再像以前那样，一定深度领域的运维专家可以占领所有市场；

2、从内部来看，公司的新业态、数字化转型、运营似乎永远离运维人员很远，而技术栈不断增加、规模不断扩大、数量有多少是运营商必须接受的另一个挑战。

如何从内外部环境的变化中赢得运维组织的转型和运维人员价值提升的需求是必须面对的课题。

康威定律视角下的运维组织变迁

每个人都在谈论转型，但问题是：在哪里？

运维组织的变革，离不开运维架构和制度的变革。在某种程度上，康威定律也可以用来指导操作结构。

第一定律

.

一个组织的沟通方式是通过系统设计来表达的。

第二定律

没有时间做正确的事，但有时间重新做。

没有多少时间可以完美地完成一件事，但总有时间完成一件事。

第三定律

从a的图到它的图有一个。

线性系统和线性组织结构之间存在异态的可能性。

第四定律

大的比小的更倾向于 。

大系统组织总是比小系统更容易分解。

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

第一：传统的施工方法。

根据市场上所需的功能模块和常用产品不断积累运维技术架构，后期对接功能和数据，实现数据统一运营的大目标。

第二种：平台搭建方法。

将通用运维能力存储在平台中，形成各种原子能力模块，然后通过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事业部“腾讯智慧阵营”的子品牌（网址：/）。蓝鲸是一套基于PaaS的技术解决方案，提供完整的前后端开发框架、调度引擎、公共组件等模块，帮助业务产品和技术人员快速构建低成本、免运维的支持工具和操作系统；蓝鲸是腾讯互娱事业部多年积累的技术运营支撑体系，承担着百家商家在线运营的使命。

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

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

2、转型的曙光：平台原子化、抽象与抽象；

蓝鲸设计思路：尽可能将单个步骤抽象成一个原子，然后将原子自动化，再通过任务引擎将其连接成“字符串”或“树状分支结构”，实现全自动化这样做的好处是它不依赖于业务类型、架构或场景。只要可以手动操作维护，就可以做到无人值守。

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

抽象各种运维和操作场景，抽象出最典型的需要业务配置和作业执行的场景。此时蓝鲸配置平台和作业平台创建完成，抽象的原子平台成为PaaS能力池的能力块。

4、原子平台集成；

原子平台越来越多，但原子平台最终是用于消费和调用的。因此，进行了整体整合。整体架构采用SOA架构，服务模块灵活采用微服务架构。

5、平台开发模式，让运维应用自动增长；

这个阶段是真正的运维发布，平台准备好，搭建服务SaaS开发生命周期的系统组件，让运营场景实现SaaS自我成长。蓝鲸平台最大规模运行在1000多个SaaS服务上，服务于各种业务的各种运维和运营场景，这些场景都是运维人员做的。

6、一个自我成长的运营平台，可以“完美解决”运维的复杂性和多样性：

7、IEG事业群最终内部运营技术架构：

以上是作者对运维组织转型的理解和分析。欢迎讨论交流服务器运维技术，谢谢！