运维的瓶颈在哪里?

发表时间: 2018-07-02 13:41

作者|赵旻

编辑|小智

在撰写本章的时候,我偶然间看到了陈皓(左耳朵耗子)先生的一篇杂文——《拖累开发团队效率的困局与解决之道》。文章言语犀利、有话直说的风格是我所喜欢的。虽然我并不是专业的程序员,文章中所提到的一些观点和我竟有些不谋而合。其实运维和开发之间有很多地方都是相通的。文中所论之痛点,令同道中人会心一笑。尤其是那犀利的批判性言论,待到戳中问题要害之处,却也有一番快意恩仇的感觉。

本章为大家介绍运维平台中最为重要的两大系统 CMDB 和 Workflow。本章旨在谈论构建这两个系统的重要性,以及在构建过程中需要考虑的一些重要因素,并且通过一些故事或实际案例为读者分析构建过程中的一些误区。

当然,在剖析分析问题之前,我们还是老规矩——先讲两个小故事做药引子。

运维故事 1:审计总动员

今年是 Foo 公司创业的第三年。由于业务发展迅速,数据中心的服务器数量已经由原来的 300 台增长到了现在的 5000 台。这段期间,公司也发生了很多变化,组织架构调整了多次,人员变动也比较频繁。这不,今年刚刚走马上任的审计主管找到审计员小胖,要他负责检查公司的资产情况。结果这一查,却惹出了很多麻烦。

小胖到现场一检查就发现了问题——有 200 台服务器和资产提交的信息列表对不上。资产信息列表是在服务器入库时建立的,当时记录在案的信息都是正常的。而且,资产管理员茜茜很负责,每次设备入库时,她都对入库设备的信息进行核对和记录。然而,小胖在这次检查的过程中发现,资产信息列表上标明的部分主机现在已经不在当初记录的位置上了。出现这个问题是由于设备迁移导致的。迁移工作由业务需求方发起,每次迁移工作的内容都是通过电子邮件来传递,相关干系人也不是固定的。当迁移工作完成后,有些比较负责的人会把迁移信息通过邮件抄送给茜茜,让她完成信息的同步更新。但也有一些人没有这么做,所以导致一些设备做了迁移,但资产管理员这边根本不知道。

经核查,数据中心服务器的总数是对的。但是这种说法不符合审计的要求。所以,现在所有被查出问题的服务器,都必须一台一台地核对清楚。由于涉及到服务器的查找,茜茜先联系了 SE 协助核查。SE 根据问题地址进行核对时发现,有些地址根本 ping 不通。SE 联系了监控团队帮助确认,监控团队说这些问题地址已经不在线上运行了。于是 SE 又去找 PE 帮忙查询,PE 说这些问题地址的系统都已经下线了,而且服务器也已经退还了。

不过,他们不记录 SN 号,所以光凭 SN 没法找到新的地址。没办法,SE 只好抓取了所有能登录的服务器的 SN 号出来,整理了一张全新的数据给茜茜。但是根据 SN 号,SE 也只能找到新的业务 IP 地址和管理地址而已,并不能据此知晓解服务器的具体位置。查询历史邮件电子也很困难,有些邮件随着人员离职早就不知道哪里去了。没办法,茜茜还得联系 IDC 的人,通过带外管理地址(好在服务器都有可以看到带外管理地址的液晶显示屏)去核对机架的信息。一项审计工作,前后牵动了审计、资产、监控、SE、PE、IDC 六方共计十多个人。

谁拖了运维的后腿

故事讲完了,我们来看问题出在哪里?

首先,对于数据信息的存储和维护,完全依赖于 Excel 表格,而不是建立在数据库之上。

其次,业务变更通过邮件发起,涉及到的数据变更,是否会通知茜茜进行同步更新,全凭发起人的高度自觉性。没有数据库支持、没有标准规范、工作流程混乱、缺乏约束条件等各种因素导致了最终的悲剧。

虽然,这只是一个虚拟的故事。但是,这种场景对于读者朋友们来说,想必并不陌生,大家或多或少地都能感觉到一丝熟悉的味道。实际上,类似的问题一直在我们身边不断地发生着。

在企业生产经营当中,最为重要的就是数据信息。它为管理者在决策过程中提供了重要的参考依据,而数据缺失和数据失准又会给决策带来巨大的风险。管理者对于数据的价值与重要性非常清楚,但是从实际执行的表现来看,却并不尽如人意。就像一个人购买了一辆新车,车主很爱惜的贴了车膜,还购置了脚垫、座椅套等一大堆配件回来。可是,车却一直停在车库里,既不拿来开,也不去保养。等到真正需要用车的时候却发现——车,开不了了。

传统的 IT 办公系统多是面向单一业务的,没有过多考虑业务之间的联动关系。报销系统就只负责报销,打印系统就只负责打印。然而不幸的是,很多业务处理恰恰不是孤立的。一个业务的执行往往与其他部门、其他人或者其他事务有着很多关联,这就构成了一个复杂的业务流程。由于各个 IT 系统都是孤立的,当业务从一个环节流转到另外一个环节的时候,发现在 IT 系统层面上根本无路可走。业务流程在这种缺乏有效管理的情况下,各个系统之间的信息交换不得不依靠人工离线来完成。而在这个过程中,产生了大量的邮件、表格、会议和沟通等游离于系统之外的副产品,使得工作效率大打折扣。

运维故事 2:丛林野人

话说在一片古老而广阔的丛林中住着一群野人。在这片丛林最深处有一口清泉,这是丛林中唯一的饮水场所。幸运的是,他们居住的洞穴恰好位于这口清泉的旁边。喝水是不成问题的,野人们还需要填饱肚子。好在丛林里到处都长满了可以食用的野果,野人们就靠采集这些野果来充饥。

日子过得很幸福,野人族群渐渐兴旺发达了起来。慢慢地,大家发现,洞穴周边的野果子都被吃光了。于是他们不得不到更远的地方去找寻食物。随着时间的推移,探索的路越走越远,很多出去搜寻食物的人再也没有回来。倒不是他们贪玩迷失了方向,而是因为路途太远又没有水喝而渴死了。这就陷入了一个两难的境地,附近没有食物,远方又没有水。这该如何是好呢?身强力壮的野人们开始加强身体的锻炼,希望借此可以让自己走得更远一些。只有一个聪明的野人与众不同,他在空闲的日子里,借助原始工具去尝试着做一个木制的水壶。

又过了些日子,终于方圆五十里内的野果子都采光了,这已是野人们体力的极限了。这时候,那个聪明的野人已经成地完成了自己的作品。他背上一壶水,踏上了探索的征途,当徒步走了三天之后,他惊讶地发现,自己已经站在了丛林的边缘。而不远处是一片新的天地,那里有着丰富的食物和水。原来这片丛林并不像传说中的那么广阔,但是没人能在缺水的情况下,在丛林里熬过三天。

运维的困境就在于,没有提前做好面对质变的准备。团队疲于应付基于故障处理、基于业务需求的工作,完全没有时间,甚至没有意识就产品价值和用户价值去思考问题。一个开发项目成立的背景,大多是出于需要,而不是项目本身的价值。工作的目标过于功利,往往急于去解决某个具体问题,缺乏解决共性问题的意识。

忙,成为了一切拖延症的最佳理由。团队在事务优先排序上选错了度量工具,不用价值来衡量,却非要去和时间赛跑。不论是传统运维,还是互联网运维,错误的驱动原力都会让你的团队陷入一个明日复明日的怪圈。

注:本文节选自《IT 基础架构:系统运维实践》。

作者介绍

赵旻 ,《IT 基础架构:系统运维实践》作者,获得 RHCA/RHCSS/MCITP 认证,十年以上互联网金融、电信、政府等多领域背景的从业资历,曾参与中国国家电子政务多项重点工程的安全信任体系的建设工作,为中国移动、中国航空等大型企业提供技术支持。熟悉 x86 平台基础架构系统的建设、管理及运维工作,并醉心于运维产品的设计与体验。乐于在工作实践中分析问题、总结经验,具有持续优化的能力,属于主动管理型的工作者。资深面试官,产品设计评论人,《运维前线》联合作者,现专注于管理学、产品设计、基础架构运维等领域。