从运维的意义谈起

上周五在北京，原本约了优诺的傲寒想找他去聊聊，然后再回家，因为临时有事未能前往。每次和傲寒聊聊都会有很多收获，这回没能见面聊一聊，觉得有些遗憾。不过在机场的时候看到了天旦的CEO Vader的《运维的意义》，看了以后深有同感，立即就转发到朋友圈了。文中谈到有些感悟也是和傲寒交流后有所悟。我想看到这篇文章，也可以弥补一些缺憾了吧。

我也是做了二十多年运维的人，对运维是什么也常有所思考，但是这些思考都是碎片化的，并没有真正的去理解与认知运维的意义。今天仔细想想发现我只是做了二十多年的运维“工作”，而做实际工作的人只是做惯某些事情，仅仅是做习惯了，并不会去深究你做这些工作的意义。因此虽然你在行业里很资深，很多问题还是看不明白的。就像前几天很热的《你怎么还在招聘DBA？》，正反方讨论的很热烈，看谁的观点似乎都有点道理，不过似乎都存在一定的偏见和执念，似乎在为某些事情代言。运维的意义到底是什么呢？不管企业的体系如何，管理制度如何，运维的意义应该是确保系统能够在满足SLA的前提下，以比较经济的成本运行。如果不是如此，那么运维工作和运维部门的存在意义就不大了。

有很多制造业企业，规模很大，但是IT运维并不是主业，因此很可能不常设运维人员，系统出了问题，花点钱找人搞定。如果这样成本低于常设运维部门，那么这种模式也未尝不可。有些企业从来不做数据备份和容灾，出问题花点钱折腾几下，实在不行重建数据库，丢失已有的数据。如果企业经营者认为这样更省钱，也是没有关系的。IT运维的最核心的价值应该就是辅助企业的生产与核心业务。

         

我们回过头来再来看运维的意义，而不过多的纠缠“信息化、数字化的意义”。最近我在写文章时候喜欢问问ChatGPT,这回它的回答和我的想法是基本一致的。运维的意义并不在于更快地发现问题，防患于未然等我们原本认为的事实。这些我们原本认为是运维的意义的东西实际上都是达成“运维的意义”所采取的手段。

实际上达成运维意义的手段不仅仅是运维人员所认知的那些，从业务部门优化业务开始，到系统设计，开发，IT基础设施建设，交付，运维，下线，整个过程中，在多个方面都可以确保运维意义的达成。不同的企业会在不同的阶段投入更大，而在某个阶段投入较少。如果你不想招聘DBA，那么大规模上云，并且在开发前期更多的减少运维的需求，花大价钱钱买RDS的各种运维服务，那么不招聘DBA也不是不可以的。

企业经营者根据自己的业务特点与IT系统的特点来算一算，哪种更划算就可以了。很多企业认为上云是最便宜的，不过也有一些上云的企业算了算下云更划算一些。我在MEDIUM上经常看到上云降本增效的例子，也能看到下云节约40%成本的真实故事。这些事情都是与企业的特点以及企业业务的特点相关的，并不能从一家企业的成功来否定别人的选择。

企业的IT运维有轻研发重运维、重研发轻运维和运维研发平衡等多种模式，不同模式的企业来看是否还需要招聘DBA的问题，有不同的看法那就很正常了，因此一些观点无所谓对错。

我十分认同Vader的观点，运维存在的原因是因为各种错误和故障的存在。我们总是为了系统能够更少故障的运行而在设计建设阶段付出了很多卓越的工作，总是希望能够研发出一套可以很好的运行的系统，但是我们想研发出完全不需要运维的系统的追求就像追求永动机一样希望飘渺。无论如何，运维总是存在的，哪怕我们不需要专门的运维部门而是由研发人员来做运维。再好的数据库也还有成筐的BUG呢，何况一群不那么优秀的码农写就的程序。号称坚固无比的公有云平台还架不住挖掘机来两下，设计再优秀的系统也无法避免理想模型与现实的差异。

从另一端来看，我们想通过运维来解决所有问题的目标也很难实现，就像阳明心学中所说的物本身和表象一样，如果运维部门总想看透系统的本质，并从根本上解决系统的问题，也是无法做到的。物本身是十分复杂的，连设计研发系统的人都无法预料到系统可能发生的一切，通过表象去运维系统的人就更无法让系统完全在自己预设好的场景中运行了。我们要想运维系统，就只能通过对表象的观察为基础来进行。以数据库为例，我们监控数据库的时候，最初级的只能通过现象来发现问题。而随着我们对数据库的认知加深，我们可以通过指标数据和日志等来发现并定位数据库的问题，故障的发现可以更早了，不需要现场出现就可以了。不过还是不够，我们还需要更高的运维能力，因此我们通过各种数学模型来发现与预测数据库可能发生的故障，了解数据库运行的现状与趋势。

实际上这些年我们做系统运维与优化的过程也正是这么一点点进步起来的，最初我们运维的时候，只能从现象去匹配已有的故障案例，从而找到类似的案例来照猫画虎的处置。随着能力的提升，我们可以建立各种运行基线，通过专家经验与指标基线来辅助分析，从而能从故障中发现更为细微的差别，更好地进行运维与优化。这样的模式我们使用了十多年，经验越来越丰富，处置的效率也越来越高，不过我们发现具有这样能力的专家数量太少，而IT系统越来越复杂，越来越多，因此我们又开始通过更易用的模型来解决这些问题。

为了让使用模型的门槛越来越低，我们总是在追求通过更优秀的模型与算法来实现对数据库运行的更精准的掌控，但是模型可以越来越精准，但是无法达到发现一切问题的层次，这是因为我们的一切判断的依据来自于数学模型，而数学模型可以很好的逼近事实，但是无法达到物本身。

实际上很多企业在IT管理上并没有真正的理解“运维的意义”，在需求、设计、研发、运行方面并没有考虑到成本最优的问题，因此在投资上的决策也偏离了本心，不过最终的决策是否合理，从不同的立场上看，可能也会有偏差。最后举个泛IT的案例，与运维不直接相关，不过也可以看出我这段话要表达的意思。

一个企业要替换ORACLE，他们有很多系统都是基于Oracle研发的，使用了大量的存储过程。在数据库选择上，我建议使用与Oracle语法兼容度较高的数据库去替代，比如达梦等国产数据库，应用几乎不需要做修改就可以迁移过去了。不过领导不同意，他认为达梦还要购买，他们的运维能力也不足，MySQL是开源的，不用花钱买许可证，自己的运维团队也有一定的经验，还是迁移到MySQL更划算。我给他算了笔账，买国产数据库只需要十来万 ，而把应用从Oracle存储过程迁移为MySQL要花上百万，迁移时间也要多花半年多，明显算着不划算啊。领导一笑，迁移虽然花钱更多，但是开发商是我们下属的三产公司，哪个更划算呢？