47 运维运营：如何运营好大规模商业化的消息队列集群？

你好，我是文强。

这节课我们来讲一下系统的运维运营。最近听到这么个说法：一个系统的核心竞争力是它的运维运营体系。在听到这句话的时候我有点意外，但一瞬间明白了对方的意思。

在做消息队列产品化这么多年中，有时候别人会问我，做得最有成就感的一个事情是什么。我第一反应就是我用 PHP 写的运营平台。平台本身没有什么技术含量，就是一个用Nginx + PHP搭建的运营系统。但为什么它让我觉得最有成就感呢？

因为这里面的功能都是我自己想出来的，做出来后团队的同学都认为很实用，能解决很多问题。而在这个过程中，我感觉到自己对系统的了解确实加深了很多。在这个过程中，不管是团队还是个人都很有收获。所以说一个好的运营系统，对于团队和个人来讲，都是很有价值的。

运营系统能够带来什么

具体能带来什么呢？

从功能上来看，运营系统可以简单分为运营类和排障类两类功能。

运营类功能 主要用来满足系统运维运营方面的需求，比如查看数据、查看监控信息、导出报表、管理资源、修改系统配置等等。需求主要来源于运营人员，主要收益就是减少人工操作的成本。

排障类功能 主要是在定位系统故障时，辅助我们定位排查问题，比如自动排障、指标自动分析、核心指标展示、某些故障CASE的定位等等。需求一般来源于研发、运维人员的经验以及历史的故障，主要收益就是减少故障定位、故障恢复的时间成本。

这两类功能的技术复杂度并不高。不过，如果我们只关注技术实现的复杂度，那么就没有找到这个事情的核心点。

从结果来看，一个好的运营系统对团队来讲，能够提高运营人员的工作效率，提升问题的定位解决速度，进而提升平台的口碑和收入。对个人来讲，能让研发人员对系统的了解更加体系和深入。

我们在第46讲讲过产品思维、客户成功思维等概念，本质上是为了更好地服务客户。而服务客户很重要的一个点就是，在系统出问题的时候，能够借助工具快速定位问题，而不是依赖某些专家的经验。所以思考开发哪些工具、怎么开发工具的这个过程，非常考验研发对系统的了解，以及对技术的理解。

在我看来， 只有真正了解系统、了解产品、了解客户的人，才能提出有用且有效的运营需求，而这类需求往往能带来非常大的收益。对运营人员来说是时间收益，对客户来说是服务质量的收益，对平台来讲是口碑和收入的收益。

那应该是谁来主导运营系统的开发呢？是产品经理、团队Leader，还是主要负责的运营同学？

谁来主导运营系统的设计

通常来说，团队里面一般有专门负责运营系统开发的同学，但是这些同学和负责系统内核开发的同学、日常运维运营系统的同学一般不是一起的。这会导致运营开发人员游离于系统之外，离系统底层和用户都很远，陷入为了做需求而做需求的状况。从而出现负责运营系统开发的同学积极性不高，导致无法做出好用的运营系统。

但是从合理性来说，主导运营系统开发的人应该很了解系统的底层原理，很了解客户遇到的问题，很了解现网运营情况，才能够判断哪些运营能力最能带来价值，投入开发的 ROI 最高。

从个人角度，我认为主导运维系统开发的人，首先需要认识到搭建复杂系统的运维运营体系并不是一个脏活累活，它是一个能够给平台和个人带来很大收益的事情。

从团队的角度，一般需要在团队里面找到愿意思考、愿意负责这个事情，并且想把产品做好的人。通过这个人去带动团队成员一起思考运营系统的设计搭建，从而打造出一个可以给团队带来收益的运营系统。

从团队的角度，还需要思考一个点，就是不能只让一个人或者几个人长期负责运营系统的开发，得让团队成员都参与进来，或者有一定的轮换机制。当某些同学成长到一定阶段后，就让他们负责更重要的工作。

不用担心，他们完全可以胜任，因为运营开发其实离内核很近。

运营开发离内核很近

如上图所示，一套商业化的基础软件产品，它是由内核、运营运维、产品化、商务售前四个部分组成。可以看到内核是基础，运维运营是内核和产品化之间的重要连接。有句话说， 系统是运营出来的，不是开发出来的。 说的就是系统要在运营中不断地去调整细节、调整架构、添加功能等等，从而完善系统，提升产品竞争力。

在实际的开发中，负责内核开发的同学很容易陷入技术细节，或者只关注局部某些模块。从而缺少从产品、用户视角出发的对系统的宏观理解。而运营开发可以接触到产品和用户，在宏观的角度会对系统有一个更深的认识。

讲到这里，我觉得还可以从运营开发的角度，迭代一下我在第45讲中分享的学习消息队列的六个步骤。看一看从一个运营开发成为一个消息队列专家，要经过哪些过程。

假如你被分配去负责某个产品的运营系统的开发，此时如果你对这个产品感兴趣，那就继续学习。如果你觉得挑战不大，建议换个岗位，因为只做运营开发，虽然有价值，但竞争力相对是较弱的。
如果你对这个产品感兴趣，则可以先去了解一下整个系统的全貌，比如系统架构、模块组成、运行原理等等。注意不要陷入代码细节，有个大致的了解即可。
接着去理解产品经理给你的需求，比如为什么需要这个功能，背后的诉求是什么。了解背后的诉求以后，结合你对底层架构的理解，再去分析这个需求有没有更好方式来满足，然后思考技术实现方案。
然后再去帮客户解决问题，看看客户都遇到什么问题。然后结合你对内核的理解，去判断客户的问题要怎么解决，内核还缺少什么能力等等。
通过 2~4 的过程，其实你对系统已经比较了解了。此时就得去翻看代码，也是注意不要陷入太多代码细节。只要结合对架构原理、模块组成的理解，对系统的核心流程代码有认识即可。
经过了2~5，你对系统架构已经了解较深了。此时最重要的就是想办法从运营开发转为内核开发。毕竟只有对系统有代码级的理解，才能走得更远。同时，因为开源社区很丰富，你转为内核开发不是说只能转为你当前团队的内核开发，还可以换个思路，成为社区这个方向的开源项目的内核开发成员，甚至可以跳槽成为其他公司这个方向的内核开发。而 2~5 过程中的积累，就是你的资本。
当完成1~6，其实你已经完成转型了。如果想往前走，那其实就是根据这个过程积累的心得体会去扩展行业、产品、技术的视野了。

以上作为建议，能不能走通还得结合你的实际情况去看一下，我身边有走完这个过程的同事，我还是很佩服的。

讲了一些运维运营的经验，最后我们看看这节课的核心，如何运营好大规模商业化的消息队列集群。

如何运营好大规模商业化的消息队列集群

那么什么叫“运营好”呢？我们先统一下认知。从我的经验来看，“运营好”主要是关注 稳定性 和成本两个方面。

稳定性是指系统要尽量保证稳定，比如一年的故障时间不超过多少。但是在实际的运营中，随着用户数量、节点数量的增长，出问题肯定不能避免，概率肯定会相应增加。所以，从运营的角度看，稳定性更关注的是出问题后能不能快速恢复。快速恢复还可以拆解为 定位问题的速度 和 解决问题的速度。

所以在稳定性方面，具体怎么做呢？因为不同的MQ，原理和架构不一样，需要关注的事情就不一样，但有三个设计点是可以抽象出来的。

围绕着能否在一个页面就可以看出系统是否有问题，能否有一个功能能够自动检查出问题，能够通过观察某些指标就知道系统是否有问题，这三个思路思考应该做哪些运营需求。
围绕着历史出现的故障和对内核的理解，推断出可能出哪些故障，来开发检查或自动恢复的工具，编写对应的SOP，来降低定位和恢复问题的时间。
通过制定判断系统异常的标准，制定基准的健康度指标，定时对系统进行健康度检测，来自动发现系统的问题。

成本方面，在 MQ 这种 PaaS 产品的集群中，主要就是关注系统的资源利用率。因为 MQ 的成本主要就是由节点和硬盘组成，此时资源利用率就是需要重点关注的指标。而如何动态调配资源利用率，就需要依赖自动化运营调度系统和内核提供的Serverless能力了。考验精细化的运营能力，技术上则是一些统计和分析的工作，难度会很大。

最后再补充一个拨测方面的内容。

在系统运营过程中，我们总是希望先客户一步，去发现问题、解决问题。此时我们可能会关注各种指标、配置告警等等，但是会存在误告警的问题，比如：

客户那边发生问题了，但告警没告。
告警告了，但是客户那边没发生问题。

根本原因是指标有异常不代表一定影响客户。而影响了客户，一定有哪些指标有问题，可能是我们没有监控到，或者监控到了没有及时关注到。所以每次出问题以后，都会增加一些指标告警。但是这就会出现需要关注的指标太多而疲于奔命的情况，反而处理得更不及时。

此时就需要考虑一个问题， 如何定义系统真的出问题？所以说，运营一款MQ系统的核心就是找到一个方法，判断系统是否真的出问题了。这里的实现方式可以参考我在第23讲讲到的RabbitMQ自带的拨测机制，或者可以通过 多维度交叉拨测 的实现来精准发现系统问题。

总结

如果我现在去接手一个我不了解的商业化的基础软件，我会先做两件事情：一个是高强度参与日常值班、日常客户的咨询、大大小小的问题处理；另一个就是深入了解他们的运营系统，参与到运营系统的开发中。

参与日常值班和客户问题处理，可以让我们快速地了解业务。参与运营系统的开发，可以让我们快速地了解系统是什么样的，客户需要什么，我们还缺什么。

在我看来，一个好的运营系统能够提高运营人员的效率，提高问题的定位解决速度，能让研发人员对系统的了解更加体系和深入。从结果看，只有愿意思考、愿意负责这个事情、想把产品做好的人，才能做好运营系统。而搭建一个好用的运营系统，是一个很有技术难度和挑战，且能让自己受益的事情。

运营好大规模商业化的MQ集群的核心，应该关注稳定性、成本，以及如何判断系统真的出现问题。

思考题

如果你是专门负责内部运营系统开发的同学，可能会有类似的困扰，觉得自己的工作技术含量不高，没有用到很复杂的高大上的技术。你是怎么看待这个问题的？

期待你与我交流，如果觉得有收获，也欢迎你把这节课分享给身边的朋友。我们下节课再见！

本节课思考闭环

在我看来，这个问题分两个方面看。

首先，如果你对这个产品或者这个方向没有深入了解的兴趣，那么运营运维开发本身的工作可能相对没有竞争力，所以要结合自己的实际情况，考虑是否换一个方向。

如果你认可这个产品、这个方向，或者因为一些原因还得继续这份工作，那么我建议你把重心放到认可这个工作内容可能会带来的收益上。然后抱着owner精神、客户成功思维去重新思考产品，思考做事的方式，最后可以尝试我分享的七步法从工作中找到价值。

上节课思考闭环

在实际的工作中，客户成功思维很容易变成“跪客户”，如何把握尺度呢？

我认为这个答案的核心是：敢于做自己，把产品做好，用口碑打动客户，不被外界影响带偏。

在理解产品、理解客户的基础上，合理地去做事情。合理思维并不是说做的事情一定是对的，而是抱着同理心，在产品思维、客户成功思维的基础上，找到一个合理的方式去解决客户问题。

可能客户的需求是不合理的，但是我们要找到不合理背后客户真正的需求。如果还是不合理，不符合产品发展的方向，就要果断拒绝了，不能无下限地妥协。

本质就是抱着服务和客户成功的理念，在认真做事的前提下，坚守底线，拒绝不合理诉求。