谁拖了运维的后腿？

作者｜赵旻

编辑｜小智

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

本章为大家介绍运维平台中最为重要的两大系统 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 平台基础架构系统的建设、管理及运维工作，并醉心于运维产品的设计与体验。乐于在工作实践中分析问题、总结经验，具有持续优化的能力，属于主动管理型的工作者。资深面试官，产品设计评论人，《运维前线》联合作者，现专注于管理学、产品设计、基础架构运维等领域。