先标准化还是先自动化：IT运维管理升级，该如何做是好？
本帖最后由 adminlily 于 2020-3-8 16:50 编辑IT运维的标准化与自动化之争
IT运维升级建设到底应该先进行标准化建设，还是应该先进行自动化建设，这个争议由来已久。
企业IT系统、环境和流程运行多年之后，难免出现IT环境无法有效支撑业务运行和发展的情况，不少企业就会着手考虑进行企业IT运维管理的改造、升级和重建。
但究竟应该先进行IT标准化的梳理和建设，还是应该先着手IT自动化的研究和部署，往往会引发企业内部的争议。
建议先标准化的认为：没有标准化做支撑，不实现数据中心、基础架构、业务应用、服务流程的标准化制定和落地，要实现自动化只能是痴人说梦、凌空虚蹈，根本无法落地。并且由于没有标准化作为基座，自动化运维很快又会陷入零散、手动、混乱地步，无法成为常态运行。
建议先自动化的认为：首先落地标准化并不能直接降低当前运维工作耗费的时间、成本，减少相关错误；无法将运维人从底层的重复操作、故障排除工作中解放出来，专注于更重要的业务服务层面的工作；并且由于标准化的工作，额外增加了工作量，并且短期内看不到标准化对于IT环境和运维工作质量的直接提升，没有太大意义。
孰是孰非？一两句难以断定。或者说我们不需要去下定论到底谁对谁错。
我们直接回到出发点：无论我们首先要实现自动化、还是要实现标准化，根本目的是什么？这个目的在两种情况下是不是在大方向上是一致的？
如果是一致的，我们是否应该抛弃非此即彼的想法，专注于我们的根本目的，从而来研究和判断，到底应该先自动化还是标准化，或者有无第三条路可以走？
何为标准化？
企业IT运维管理不标准，带来的问题有目共睹。大体归纳起来，可能会带来下面这些问题：
企业IT建设的标准化其实是一个非常庞大的话题，这里面包括万象。从大的层面，甚至可以认为：与企业IT相关的任意一种资源对象，软件、硬件、工具、流程、人员、组织结构等从生（建立）到死（废止）的整个生命周期的管理都属于标准化的范畴。
完整的、统一的、全面覆盖的标准化建设应该涵盖上面每种IT资源和对象，这种类型的标准化建设周期冗长、费用昂贵、一般分期进行。
我们如果把标准化范围稍微缩小点，聚焦于IT运维层面，那么一般而言企业的IT运维标准化建设应该涵盖以下几个大的方面：
在上述四个大的标准化建设范畴下，我们可以进一步细化标准化整体的设计思路：
举例来说，针对其中的“基础架构标准化”的内容，在定制标准化的时候，我们需要考虑必须覆盖全部基础架构组件的标准化：
并且针对每个组件，都需要有完整的生命周期管理标准，如下图所示：
并且针对生命周期管理中的每个步骤和阶段，需要体现到具体的标准化方案和文档，如下图所示：
如此之后，针对操作系统这个具体对象的在生命周期管理中的这个阶段的标准化规范算是制定出来了。这种标准化和规范在后续能否持续得到执行和贯彻，能否真正体现到对IT管理的提升，体现到对业务的支撑效能上，是需要打个问号的。
事实上，由于这种标准化往往是由上往下设计出来的标准化，而不是从底层实际环境、人员组织、流程、运维事物“生长”起来的标准化。如果没有成熟的、稳定的平台、工具和流程把这种标准化真实、有效的运行下去；如果不能把这种标准化落实到每天的IT运维管理工作中去，往往只要数年一过，各项标准化执行往往就剩下个骨架，或者连骨架也不剩了，成了纯粹的摆设。
何为自动化？
IT运维自动化是比较容易理解的，通过工具、平台和流程等实现日常运维操作管理的自动化。
比如蓝鲸智云是业界非常知名的自动化运维平台。
蓝鲸智云，简称蓝鲸，是腾讯游戏运营部“腾讯智营”下的子品牌。它是一套基于 PaaS平台的自动化运维解决方案，提供了完善的前后台开发框架、调度引擎、公共组件等模块，帮助业务的产品和技术人员快速构建低成本、免运维的自动化支撑工具和运营系统；是腾讯游戏运营部沉淀多年的技术运营支撑体系，承担着数百款业务线上运营的使命。
目前，蓝鲸智云体系不仅提供了基础运维（发布变更、监控处理、数值调整、数据提取等）的无人值守服务，而且还给运维人员提供了解决方案（工具），并随时调整，避免重复性的操作服务。
能否同时兼顾两者？
IT运维管理没有绝对的标准化。企业IT存在的意义是为内部和外部的用户提供IT服务，支撑企业业务运行和发展。既然如此，个人愚见：就不必一定去计较某个运维操作本身、某个对象运维操作流程是不是符合运维最佳实践和最佳标准。在能够满足企业的合规性前提下，有效的支撑了IT服务和业务，在当前来说，就是相对标准的，不必过多纠结。
传统进行IT升级建设的时候，往往将标准化和自动化建设割裂开来，分阶段进行这两个阶段的建设；并且往往倾向于优先进行标准化建设，再考虑自动化建设。但是这样建设的劣势，其实我们在前面已经探讨过了，并不能确保制定的标准化能够真正融入企业IT运维管理的血液。
在我个人看来，其实标准化是一个相对的概念和不断变化的概念，什么意思呢？
比如对于一个企业A的IT运维管理部门来说，它的IT环境标准化程度事实上是与它的IT运维管理能力相匹配的；我们可以把运维管理能力理解为一个运维的“价值”，而IT环境标准化程度是一个运维的“价格”。“价格”是由“价值”决定的，并围绕“价值”在一定范围内波动。
也就是说你具备什么样的运维管理能力，就对应着你能拥有整体上怎样的标准化程度；你的IT环境的标准化程度意味着整体的运维管理能力就处于目前这个阶段。
这种能力本身当然能够通过采购更先进的软件、更复杂高级的流程工具、建设落实更多的标准化文档和流程得到一定程度的提升，这种提升本身事实上是运维的“价格”的变动，而不是“价值”的变动。
决定运维的“价值”能否产生质的变化的，事实上在于企业的运维人的意识和能力、企业的运维组织方式、企业的运维文化等更多软实力。这种软实力的提升并非一日之功，事实上需要长久的学习、持续的进步和坚持不懈的培养。冰冻三尺非一日之寒。
企业IT管理过程中经常出现这种现象，就很容易理解了：单纯的通过IT运维标准化建设来提升企业运维管理能力，由于是运维“价格”的拔高，运维“价值”本身依然维持在当前的水平；所以数年之后，整体的IT环境再次回落到零散无序的状态。
这同样也可以解释为什么很多企业大张旗鼓的建设ITSM流程平台，但一般不用经历太久的时间，就会回到“先操作，再提单”，“操作了，忘记提单”，“现在流程平台都不怎么用了，都是直接上机器操作”这样的一个状态。ITSM没有助力企业运维能力的提升，反而成了运维人员的累赘。企业的运维能力在哪儿，企业的IT标准状态就在哪。
如果破解这种状态呢？
我个人的理解是：先自动化，再标准化；边自动化，边标准化；既自动化，又标准化。
简单来说，就是如果目前的日常运维管理操作能够满足应用和业务的支撑，那就可以理解为当前的操作和管理对于当前这个阶段是基本标准的；就可以使用自动化运维平台、自动化运维工具和自动化运维操作流程编排等将眼前的操作固化为一个标准的自动化操作流程。
一段时间之后，业务持续发展，当前的操作流程本身可能难以满足业务、应用和用户的支撑，那就适当修改操作流程，使之能够匹配当前的运维需求，并继续固化到自动化工具和自动化操作流程中去。
我们可以举个例子：比如下面是一个企业A某个应用的发布流程，他们在此之前就一直是这样发布的，并且也没有什么大的问题。
对此，就没有必要针对这个流程去做什么劳什子的标准化，直接利用自动化工具把这个流程固化成一个自动化的操作过程；日后，若这个流程某些步骤节点需要增、删、改，以便适应新的业务需求，直接调整流程或者创建一个新的流程即可。
上述自动化操作编排可以很容易通过比如蓝鲸的标准运维来实现和更改。
上述只是一个小例子，事实上，利用蓝鲸自动化运维平台，能够在企业IT运维管理的方方面面实现“先自动化，再标准化；边自动化，边标准化”的效果。并且由于这种标准化是从底层实际环境、人员组织、流程、运维事物“生长”起来的标准化，并且又得到了具体的运维平台、运维工具和运维流程的支撑，因此能够真正渗透到企业IT运维管理的日常中去。而不是一纸落满灰尘的文档。
这样，事实上，IT运维管理在当前阶段既可以实现一定的标准化，因为所有的操作都通过固化的自动化流程去实现，避免了每个人运维管理的随意性以及由此可能带来的问题；又可以实现操作的自动化，减少人去操作的时间成本等。并且随着业务发展，运维需求提升，人员和组织能力的强大，标准化和自动化会成螺旋状交替上升。
纵观国内的互联网巨头的运维能力演进，大体也是遵循这么一个路线。他们没有一上来就要建设一个大而全、全部标准化的运维体系，而是交替上升，逐步开拓运维新局面，到达新高度。直到今天，他们走在了中国乃至世界运维技术先进性和运维能力强大性的最前列，并且持续对外输出运维技术和能力。
以上内容仅代表个人观点，能力所限，偏颇和愚见难免；欢迎各位同学留言探讨与交流。
好
页:
[1]