运维行业思考:从黑盒运维到白盒运维的思路转变

运维小灰帽
很多企业的管理者通常会觉得运维部门是成本部门,只需要能支撑起业务就行。业务部门只负责提业务需求,开发部门只管做功能的开发,很多非功能性的需求问题长期无人重视,只能靠运维人员肩挑人扛到处救火,可以认为是运维部门靠自己的血肉之躯实现了业务部门和开发部门的信息化。

对于从事运维行业多年的小灰帽来看,在大多数企业中,运维部门的地位长期以来都是被边缘化的,不受公司和领导重视。

很多企业的管理者通常会觉得运维部门是成本部门,只需要能支撑起业务就行。业务部门只负责提业务需求,开发部门只管做功能的开发,很多非功能性的需求问题长期无人重视,只能靠运维人员肩挑人扛到处救火,可以认为是运维部门靠自己的血肉之躯实现了业务部门和开发部门的信息化。

在这样的背景下,不光企业的管理者不知道该如何评价运维的价值,甚至很多运维从业者都不知道自己除了到处救火外还应该去关注什么,当然也可能是因为没有时间和精力去思考。

“黑盒运维”&“白盒运维”

黑盒运维与白盒运维的灵感来自软件测试中的黑盒测试与白盒测试的概念,反映运维管理的工作模式和信息透明程度。

1.jpg

黑盒运维和白盒运维

“黑盒运维”

黑盒运维反映了运维的不成熟,表现为人肉运维和管理缺失的自动化。即需要运维人员加班加点依靠人力被动地满足业务部门的需求。欠缺标准化、规范化,基本顾不上运维的自动化改造和精细化管理,更加无法去了解自己所运维的业务。

2.png

传统运维

传统的运维人员实际上是所谓的“黑盒运维”,不断地去做重复性和繁琐性的操作,时间长了之后,只知道自己管理的服务器能正常对外服务,但是却不知道应用之间的依赖关系,哪些配置是有效配置、哪些配置是无效配置。只敢加配置,不敢删配置,不断累积,欠的技术债越来越多。在这样的背景下,当遇到业务系统崩溃等极端情况时,需要完整重建系统时候,就很容易一筹莫展,故障恢复时间长,进而给企业造成更大的损失。

为了彻底解决“黑盒运维”的困境,我认为真正有效的根源解决做法是:从“黑盒运维”走向“白盒运维”。

“白盒运维”

“白盒运维”即摆脱“黑盒运维”系统信息不透明,运行状态不可控的运维困境,基于配置管理,以构建IT系统的全息视图。使用户全面掌控IT系统的处理流程、架构蓝图、配置信息、运行状态、环境变化、演进趋势,配备各类自动化工具和处理手段,做到闭环管理、全面掌控、数字化运营。

3.jpg

自动化运维

运维的核心和难点其实是配置管理,运维人员只有真正的清楚所管理的系统的功能和配置,才能从根源上解决到处救火疲于奔命的情况,也才能真正的杜绝业务问题和运维事故的发生,从根本上解决运维的问题。

从黑盒运维走向白盒运维,再进一步实现devops(开发运维衔接)和软件定义数据中心,就是所谓的运维2.0了。很显然,这个单靠运维部门自身是做不到的,需要每一个企业的管理者、业务部门、开发部门去思考。因此,出现业务和运维问题时,我希望不要简单地让运维来背黑锅,而是让大家真正的从中得到教训和启示。

THEEND

最新评论(评论仅代表用户观点)

更多
暂无评论