
从运维技术架构的变化对运维组织转型的初步研究
张敏
【摘要】
根据我对技术和行业的了解,作者分析了运维组织的转型.
涉及的关键字: 自动化操作和维护,自动化操作,PaaS操作,蓝鲸等.
【文字】
最近,微信经常看到诸如“未来XX年没有工作稳定”,“稳定是最大的不稳定”之类的文章,这让我想起了我的运维领域和IT行业.
运维人员面临的恐慌可能是前所未有的:
1. 从外部角度来看,从IAAS到PAAS,IT架构逐渐变得乌云密布;市场对运维人员的需求已不复存在,具有一定深度的运维专家可以吞噬市场;
p>
2. 从内部角度来看,公司的新业务形式,数字化转型和运营似乎总是与运维人员相距甚远,但是技术堆栈,规模和数量不断增加,但乌克兰人必须接受这一运营挑战;
如何从内部和外部环境变化中赢得运营和维护组织的转变,以及如何提高运营和维护人员的价值的要求,是迫在眉睫的,必须面对这一话题.
每个人都在谈论转型,问题是: 去哪里?
运维组织的变革与运维结构和系统的变化密不可分. 康韦定律也可以在一定程度上指导运营结构.
康威定律:
第一定律;

沟通决定设计;
组织沟通将通过系统设计来表达;
第二定律;
永远没有足够的时间去做正确的事,但是总是有足够的时间去做;
不可能再花更多的时间做一件完美的事情,但是总有时间完成一件事情;
第三定律;
从系统的线性图到其设计组织的线性图具有同态;
线性系统与线性组织结构之间存在潜在的异质同构特征;
第四定律;
在开发过程中,大型系统的结构趋向于分解,从本质上说,比小型系统更容易崩解;
大型系统组织总是比小型系统更倾向于分解;
让我们看一下运营技术架构的变化:
第一: 传统的施工方法;根据市场上所需的功能模块和常用产品不断积累运维技术框架,并进行后续功能和数据的交流,以达到统一数据运行的目的.

第二种方法: 基于平台的构建方法;将一般的运维功能存储在平台内部,以形成每个原子功能模块,然后通过SOA架构概念进行封装,将运维所需的场景功能进行封装,并隔离平台的原子功能模块;这样做的优点是避免了像烟囱一样的施工方法,有效地管理了运行维护数据和功能;


平台的PaaS设计: 创建一个具有所有运维功能的统一平台,该平台具有访问资源层,运维服务能力的提供以及承载定制开发应用程序的能力,并且该平台具有强大的可扩展性和服务支持性;
场景工具: 设定所需的操作和维护功能,以工具方式在统一平台上运行,并调用基础平台提供的功能服务;实现功能的敏捷迭代,功能之间没有烟囱以模态方式构建;
这两个操作结构可能会给我们一些启发:
1. 组织沟通方法将通过系统设计来表达;第一个运营技术架构的构建是离散的运维组织通信方法. 每个垂直领域技术小组都选择自己的技术,这带来了组织方法是传统的方法. 该公司有不同的运营和维护组: 网络,操作系统,,办公应用程序,业务应用程序等,但是每个组都是相对独立的. 该模型处于当前的内部和外部运维环境中. 面临问题;
2. 企业的运营和维护场景通常需要跨系统,跨流程和跨组织的流程,这自然具有个性化和全流程的特征. 这也是操作和维护组织的当前要求;该公司需要启动一个自动发布系统以提高业务效率,这种运维场景需要跨越多个运维技术领域(系统,,应用程序运维),并且具有强大的个性化(银行A和银行B可能不一样);
3. 没有完美,只有更好. 组织的转型无需一次调整即可解决,但是与运营技术架构相匹配的组织将带来更高的效率.
转型的目标与运维的价值密不可分. O&M需要从O&M支持升级到增值服务,也就是说,除了稳定性之外,我还想考虑对我的组织还能做什么?考虑这一点需要花费时间,因此考虑的重点是是否可以通过自动化和标准化来释放运维人员.
示例:
操作和维护支持职责:

增值服务:

从基于PaaS的运营技术架构的变化的角度来看,如果将运维组织视为一种技术架构,则应该有一个“运维引擎类型的组织”来导出运维解决方案. 在基于PaaS的技术运营体系下,该组织称为技术运营组:

技术运营团队的职责是:
1. 首先,使用输出解决方案和工具来提高现有人员的日常运营和维护效率,例如自动化和标准化日常检查,编号和配置管理等运营和维护操作,并应在标准化中体现标准化WEB交互界面功能;使运维人员可以在一定程度上得到解放,可以作为运维小组的“当事方”,仔细考虑其运维如何更加稳定,是否可以考虑进行某些操作;

2. 技术操作小组定义了统一的工具开发或方案构建标准,并建立了流程样式的启用机制,并且操作和维护逐渐转移到操作和维护开发;运营和维护开发的定义是: 为了使IT更好而发展的企业通过建立运营和维护开发团队来支持业务的运营和发展,确保SLA并提高效率,并最大化IT在业务中的价值;
3. 从烟囱式系统建设到平台建设,技术运营团队不断提高积累公司集成运营平台的能力. 只有这样,才能实现更高效的数据操作和智能操作;
4. 自增长操作模式;教人钓鱼比教人钓鱼差. 为运维人员制作工具可以提高运维水平,简化工作自动化,重复工作标准化;
5. 原“运维专家”可以选择作为“技术运维团队”的需求专家,也可以选择与数据分析和运维专家联系或接近. 充分考虑个人职业发展: 工作项目与个人发展保持一致之后,员工将尽自己最大的努力去做自己想要做的事情,例如开发人员,技术专家,建筑师,让他们进行操作和维护操作,他们也许能够做得好,但他们不会尽力;
传统的运维组织通常根据技术领域(基础结构或应用程序)或职责范围(例如ITIL组织系统的实施)进行划分;

组织想要转型,例如进行运营,第一个问题是: 谁曾做过前任工作?同时,还需要考虑更多问题:
1. 组织转型和运营技术架构必须相辅相成;技术架构支持组织转型,组织转型可以继续丰富运营技术架构;
2. 初期投资和成本问题;过渡过程要求以前的事物保持稳定,同时可以激发新事物,因此需要对领导者有长远的眼光和坚定的决心;
3. 过渡过程中遇到的内在和外在阻力,从工具文化出发,首先解决一些问题,首先看到结果并向领导者展示价值,然后继续解决问题;
4. 每个人都能成功转型吗?这个问题需要领导者更加客观地看待,以及对转型过程的指导和安慰,以便不同的人可以做出相应的改进和改变;
运维组织转型的三个维度: 流程,个人职业生涯规划和工具平台.
传统组织的运维人员具有各个领域的运维技能,以确保技术设施的运行稳定性. 当面对更加敏捷和灵活的业务需求时,运维组织需要能够快速响应运营场景的需求. 关于PaaS提供的操作方案的开发,传统的运维组织可以从稳定的保证中逐步获取更高的价值.
与业务系统的开发不同,运营场景的开发足以使运维人员进行运维发展的转型,而了解运维与运维的人实际上就是基于平台的维护经验,使操作场景的构建更加敏捷,并提高了整体组织能力:

蓝鲸智云,或简称蓝鲸,是腾讯IEG事业部腾讯I营旗下的子品牌(网站: bk.tencent.com/). 蓝鲸是一套基于PaaS的技术解决方案,提供了完整的前端开发框架,调度引擎,公共组件和其他模块,以帮助业务产品和技术人员快速构建低成本,免维护的支持工具和操作系统. 这是腾讯互娱事业部多年积累的技术运营支持系统,承担着数百家企业运营的使命.

我们可以根据IEG业务组的业务特征来探索整个系统的诞生方式:
1. 腾讯的IEG游戏运营遇到的业务痛点:
几乎所有业务类型(大型客户端游戏,网页游戏,各种官方网站,移动终端游戏,大型游戏平台),并且所有业务都不相关(数百种游戏彼此不相关)所有流行的技术(腾讯游戏中数百家企业中的大多数都是由世界各地的开发人员开发的. 开发语言,开发框架,操作系统,和其他使用的技术都不直观),企业运营单位的数量(服务器,即操作单元超过100,000)
2. 转换的曙光: 平台雾化,抽象和再次抽象;蓝鲸的设计思路: 尝试将单个步骤抽象为原子,然后使原子自动化,然后通过任务引擎“实现完全自动化”将它们连接到“字符串”或“树枝结构”. 这样做的好处是不依赖于业务类型,不依赖于体系结构,不依赖于场景,只要可以手动进行操作和维护,就可以使其无人值守.
3. 不断积累原子平台的能力;抽象各种操作,维护和操作方案,并抽象出大多数典型方案自动化运维平台框架,以获取业务配置并执行作业. 此时,蓝鲸配置平台和操作平台已经生成. 抽象的原子平台已经成为PaaS能力库的功能块;

4. 原子平台集成;原子平台的构建越来越多,但最终还是将原子平台用于消费和调用,因此遵循整体集成自动化运维平台框架,整体架构使用SOA架构,服务模块将灵活使用微服务架构;

5. 平台开发模型允许运维应用程序增长;这个阶段是操作和维护的真正释放. 该平台已准备好构建服务SaaS开发生命周期的系统组件,以便可以为SaaS实施操作方案. 自最发展以来,Blue Whale平台已为各种运营,运营和维护场景运行了1,000多个SaaS服务,这些场景是由运维人员进行的.

6. 自我成长的运营平台可以“完美地解决”运营,维护和运营的复杂性和多样性:
支持多种语言的开发框架;
SaaS免费运营和维护托管;
企业服务总线的统一集成;
SaaS操作数据可视化;

7. IEG业务组的最终内部运营技术结构:

总结: 以上是作者对运维组织转型的理解和分析,欢迎讨论与交流,谢谢!
本文来自电脑杂谈,转载请注明本文网址:
http://www.pc-fly.com/a/jisuanjixue/article-277076-1.html
知耻而后勇
四是战争指挥失误
那个东西搞作战和反恐可以