行业动态

“

明天给大家分享的主题是“去哪儿网应用运维的人工进化之路”。人工建立过程中遇到的障碍以及我们是如何克服这些障碍的，遇到了哪些坑，这些坑的过程如何填。

我于 2013 年加入去哪儿，目前仍在从事运维工作。去哪儿网具有运维开发的特点。所有开发人员都是PM和QA，没有后端工作和前端工作的区别。用当今流行的话说，我们都是全栈工程师。

加入去哪

综上所述，主要涉及主机管理、应用管理、监控、告警平台的设计、开发和运维。

简单介绍一下我们的运维团队：

去哪儿应用运维平台介绍

首先简单介绍一下去哪儿网的应用运维平台。

我们知道，一个应用从开发到上线运行，其生命周期主要涉及四个部分：

去哪儿的业务也在一步步发展。机器的数量从几十台增加到几万台。在开发过程中，我们遇到了很多问题，在不同的阶段提出了不同的解决方案。

去哪儿经历了四个阶段：

应用运维平台三大要点

在运维平台建设过程中，我们遇到了很多困难，遇到了很多陷阱。在这个难点中，我们可以总结出三个关键点：

主机管理

去哪儿的主机管理系统基于DNSDB，负责调度和创建虚拟机。 DNSDB 是一个域名管理系统。

通过DNSDB，我们可以将一台机器的名称、部门、用途和所在的机房组合成一个唯一的域名，我们用这个唯一的域名来识别这个主机。

在 DNSDB 之上，我们编写了大量的脚本文档和工具，我们将这些脚本文档和工具整理​​并封装到一个操作中，但我们为这些操作分配了一些相关的权限。

我们还将主机的信息、流通的管理、权限的配置、操作日志的查询等存储在日志库中。最后，我们将一个主机管理系统的接口暴露给运维人员，运维人员通过这个接口来管理我们的主机。

通过主机管理平台，运维人员可以轻松地在该平台上创建和销毁主机服务器运维，查看主机的相关信息，如主机配置、保外信息等。

p>

在添加每台机器的过程中，我们会默认为这台机器添加监控报告，当机器有报告时我们会通知相关负责人。

这样一来，还有一个很大的问题，就是我们的系统是怎么开发给运维人员使用的，开发者没有权限登录这个系统。

如果开发者提出请求，我想创建一个主机，我需要给 OPS 发送一条短信。 OPS在创建这个host的时候，虽然没有具体记录谁是负责人，但是他可能会写在笔记里，时间长了可能会变得不准确。

由于当时的负责人可能已经辞职或换工作，这种情况经常发生。

这台机器的负责部门没有很好的记录，因为这个部门很多只显示在主机的名字上，有可能这台机器在处理的过程中可能会转移到其他业务线利用。 ，所以我们收到的部门信息也是不准确的。

还有一个问题是DB系统只对运维人员开放，涉及的业务线很少，所以整个主机的相关信息显然不够准确。虽然 OPS 人员有限，但不可能非常准确地维护这些信息。

所以我们想出了一个解决方案，通过应用树来解决它。

去哪儿网根据职能领域将业务线定义到每个BU。应用树BU是第一层。它下面有部门，部门之下还有更小的部门。这个级别可能有多个。

最后一级是部门下的申请，申请是最后一级。我们把所有的层级看成一个节点，每个节点可以绑定一个主机，给节点增加一个负责人，给节点增加一个审批者。下面我来介绍一下审批者的权限和角色。

有了这个应用树，涉及到业务线的开发，涉及到主机的管理，他们的负责人和部门信息越来越准确。

一台机器出现异常，我觉得很容易很快找到机器负责人。

如果宿主机快过保修期了，我需要为前面的所有虚拟机找到这个虚拟机的负责人，并通知那些人进行相关的操作，比如虚拟机离线，应用离线，可以防止过多的运维主机造成的故障。

因为机器负责人比较准确，所以我们的报告通知会默认通知机器监控报告的相关负责人，负责人会处理机器相关的基础硬件报告.

每个季度也会统计资源消耗，并制定下一季度机器采购的计划和预算。

如果你得到一个更高级别的部门，例如你得到一个BU节点，你可以很容易地通过应用树得到这个部门有哪些机器。我们可以很容易地预测本月会下跌多少。我们每个季度需要购买的机器数量使得预算更加合理。

有了用户，负责人、部门、机器的关系比较清晰。

还有一个问题。申请资源的时候，OPS还是需要操作的，账户添加也是OPS负责的。开发者想要扩展机器或者给机器添加账号应该怎么做？

他需要给运营OPS的团队发短信，说我想把应用扩展到两个主机，或者在哪个主机上加个账号。

这样做有什么好处？首先，OPS不能实时在线，无法跟踪系统，所以OPS响应很慢，查邮件很不方便。但是，邮件可能会丢失很长时间，并且不容易定位问题。

如何解决这个问题？拿出来后服务器运维，我做了两个系统：第一个是主机应用系统，第二个是账户应用系统。

两个系统以主机管理、应用树和审批中心为基础，将主机管理、应用树和审批中心调用为，通过调用安排一些合理的主机申请和账号申请流程。

刚才讲宿主应用，谁有权限申请，应用树上每个节点的负责人都有权申请这个部门的宿主或者这个应用的宿主，审批人在节点是他，它有权批准该节点下的主机。

这样OPS就不用过多介入了，他们可以手动申请主机和账号。

最后我们做了一个接口，把这个接口暴露给开发者，他们可以申请主机和账号。

通过应用树、主机管理、主机应用、账号应用四个平台形成闭环。核心是应用树节点，应用树节点将四个部分串联起来。

应用程序树节点有什么问题，我们会改变它。比如一开始，一个应用是放在OPS开发下的。三天后，发现这个位置不对。需要直接放在OPS下。需要将运维开发连接到OPS底层。

还有一个，随着业务的下滑，应用越来越大，需要拆分成几个部分，比如需要拆分成-web和-api。这些树节点的变化会导致什么？

每个系统都记录应用树节点，每个应用树节点的变化都需要与每个系统同步，相当于分布式系统中有一个有状态的模块，就是这个模块的应用树节点。

它是有状态的，这让我们很难分发。如果我们想将应用树节点扩展到更多的系统，那将是特别困难的，并且我们将继续面临同步问题。

如何解决这个问题，比如对于一个普通公民来说，如何在各个系统之间共享数据，比如我在公安系统、户籍系统、建行系统等中如何独处系统等，如何分享我的信息。

其实有一个特别好的做法，就是使用身份证。 ID 卡具有唯一的 ID。通过这样一个唯一的ID，可以识别应用程序，但这个ID永远不会改变。

我们如何找到这样的ID，第一个解决方案是使用数据库中的自增ID或UUID来识别应用程序。

这样可以保证应用ID是唯一的，不会改变，而且由于自增ID和UUID在文中没有明确的含义，我们的开发者不容易记住这个ID并与之交流。

如果我想使用自增 ID 或 UUID，我需要使用另一个系统来查看我有多少这样的 ID。先找到这个ID，再与其他系统交互通信，非常不方便。

第二个方案，在身份证上画，用数字，比如110代表上海，前面代表县，代表出生日期。

利用 ID，我们使用称为 id 的方案来识别应用程序。基本上，它被一条下降的线分开。第一个是申请所在的部门，第二个是申请的描述。这个级别也可以很长。

使用这样的节点代替申请号节点，可以保证其唯一性和不可更改性，让你记忆和交流更方便。我们最终选择了第二套方案。

监控和报告

我们来看看我们是如何在运维平台上做监控和报告的。作为一家互联网公司，保证7x24小时服务是基本要求。我们如何保证 7x24 小时服务？

如果系统出现问题，我们可以及早发现，当系统真正出现问题时，我们可以及时发现。为了确保这两点，我们需要监控报告系统。

去哪儿网的监控和报告系统也经历了长期的斗争。一开始，每个部门都会维护自己的一套系统。一开始是由 Cacti 和这两个模块构建的。存在哪些问题？ ?

因为以前的系统没有很好的权限管理，所以这个系统只能由专人处理。由于放权给其他人是危险的，有些人可能会不小心操作某些东西，删除报告或更改报告配置，所以只有专人负责报告。

订购一个报告监控和沟通成本非常高，需要联系我们的相关负责人，然后去报告配置。

开发者觉得太麻烦，所以根本不做，或者做的很少，导致我们的监控不够。可能有一些异常甚至故障没有及时发现，效率比较低。

如何解决这个问题？我们建立了公司级统一监控和报告平台。

报告平台有几个目标：

简要介绍是基于深入开发。该平台支持基本的主机监控和报告，以及业务监控和报告，所有这些都在一个统一的平台上。开发人员可以在统一的界面上查看和配置监控和报告。 .

我是2014年左右开始做的，到现在已经两年了，在公司里推广的很好。

如今已经连接了1500多个应用程序，目前指标数已经超过2000万，报告病例数已经超过40万，连接基础监控的机器数已经超过4万台。

这么大的规模，我们用了什么样的框架？

这个架构图只是我们其中一个集群的架构图。当我们计数时，我们将区分每个指标将命中哪个集群。我们如何区分？

标记，例如所有测试数据和测试指标都以t开头，所有主机数据都以h开头。

我们用 s.flat 来代表机票部门。当机票部门的所有指标都统计完毕后，应该配置一台服务器。这个服务器也是用域名来表示的，它本身就代表了一个针对机票的监控和报告集群。 .

在集群照明的前面，底部的红色是原始组件。我们在原有组件的基础上开发了几个相关组件。

第一个是继电器。每个指标被调用后，我们通过 Relay 将指标分发到多台机器上。这是通过一致性哈希实现的。

我们拿到数字后，-api部分也是我们自己开发的。 -api 也具有相同的一致性哈希算法。通过这个算法，我们可以找到指标在这个集群中的哪台机器上，并调用这台机器上-web下的api，然后得到相关数据。

这是一个集群架构，我们有多个集群。做一个统一的界面，在这个界面上配置自己的监控的时候，选择好数据源，统计的人知道指标在哪里。

能不能做一个统一的数据源供用户使用，所以我们在组件中加入一个纯指标库。每次流量到来后，我们都会将这个指标的名称告诉我们的数据库。复制，同时将其记录在该集群中。

这样，我们就可以向外界报告一个统一的-api。如果我们要为一个指标启动s.flat-xx指标，首先是调用api查找指标s.flat-xx在哪些集群中，并找出在集群中，这个指标可以是通过一致的哈希删除。

第一部分

-api就是用这个来报案的。说完了整个结构，我们来看看主机监控是怎么做的？

首先，有一个硬件管理平台来维护有关主机监控的信息。

最重要的是安排代理，维护代理的版本配置，不断扫描主机，部署在主机上，定期检查指标是否采集。

如果这个主机指标有断点或者有问题，会上报case，检测是​​系统问题还是网络问题。

在每台主机上部署后，会根据不同的配置标记不同的指标，如CPU使用率、显存使用率、网络带宽使用率等。所有这些指标都被标记了。

每个主机的指标可能相同。如何区分不同主机的指标是根据主机的名称。访问后，我们就可以调用该api并对其进行调用。

业务监控类似。应用连接后，会暴露api。以上是应用最近1分钟的监控数据。每分钟，文件都会从所有机器中提取。文件取完后，会集中分析。 ，分析后做相应的处理。

例如对应用进行计数，将其作为指标来区分不同的指标，并将指标推送到。推送完成后，还可以查询监控，检测应用指标的健康状况。

数据交换

我们来说说我们是如何在整个运维平台上实现数据互通的。我们在监控报告和主机管理中提到了一个。什么是去哪儿？

虽然是唯一的标注应用，但是我们把一个应用可视化了，它的含义也变得更加笼统了。

任何应用程序都可以是 Web 服务、GPU 云实例、MySQL 实例，甚至是一组交换机或其他。

我们为什么要像这样可视化应用程序？可视化的用处在于我们不需要考虑服务和资源的具体细节，而是用一个App来表示一个服务或者一个资源。在可视化的过程中，不需要考虑服务做什么，资源长什么样。

定义通用应用的通用属性，包括应用负责人、应用权限、应用账单等。

有了这个共同的属性，我们可以跨多个系统扩展，跨系统分布数据来共享数据。这是做什么的？

有了这个，我们可以在我们的各种系统中生成一种通用语言，而这种通用语言就是。

通过这种通用语言，我们可以将各个系统之间的数据连接起来，最终实现一次数据交换。实现数据互操作有什么好处？

平台介绍

平台简介，目前正在开发中。

它是基础，各种运维系统都是在它的基础上连接起来的。

例如主机、账号、GPU云、ES云、应用注册、应用配置、应用中间件、环境配置、代码仓库、测试、发布、监控、告警、日志采集、故障管理等。

我们将此系统聚合到一个界面中，并将其公开给开发人员。进入该系统后，开发者可以一站式完成与应用相关的所有想做的事情。

数据通信的另一种用途就是谈论主机管理。宿主可能有不同的维度来说明宿主不一样。

例如对于应用发布，有发布的主机列表，计费时计费的主机列表，收集日志时的主机列表，收集监控报告的主机列表。

只要数据是通信的，我们就可以将这些数据串联起来。比如在我们的应用中，它的主机需要扩容，可以扩容两台主机。扩容后，我们可以根据应用负责人手动添加对应账号到主机。

这样，负责人就可以使用这个账号登录相应的系统，进行相应的操作了。

数据库还有IP白名单等其他限制。数据交换后，无需记录每个主机上某个应用的白名单配置，记录即可。

在CI/CD部分，应用发布的主机也与主机相关联，应用扩展后发布的主机也是同步的。选择本主机即可直接发布主机，无需自动填写本主机。列表。

监控分为两个方面，一是基础监控，二是业务监控。基础监控也是对相关主机的基础监控，可以通过维度查看。

对于业务监控的应用监控指标采集，也可以通过to获取其主机列表，手动将本机列表加入业务监控指标采集，添加后采集本应用相关主机的监控指标并记录。

报表系统有了之后，会对应一些常见的监控报表项，比如Java中的GC报表。

有了它之后，我们可以默认为每台机器上的所有机器添加一个 GC 报告。 GC 报告联系人是负责人。每台机器扩容后，会手动添加其GC报告。

日志收集也是如此。之前，我们可能还需要自动维护这个平台。一旦我们有了它，我们就可以同步这个列表。

数据共享还有另一种用途，然后我们可以轻松估算此应用程序的费用。为什么要为应用估算账单？

一方面，它可以让我们提高成本意识，这也是在选择过程中需要考虑的。

例如，一个业务线有一些数据需要记录。它可以选择任何系统，也可以选择数据库，也可以选择。

如果访问这个服务的频率很低，比如三天几次，或者十几次，那么记录这个数据是非常昂贵的。由于数据的巨大膨胀，选择数据库或日志更实惠。

其次，可以优化。如果你因为算法而使用大量机器资源，在有账单之后，他们会自觉节约成本。

有了成本意识，我们可以更合理地分配资源。比如有些申请本身不是很重要，申请了很多机器，机器的使用率不高。收到账单后，一个不重要的应用程序居然要花这么大的账单，他们以后会回收的。一些资源。

目前我们也在不断的访问各种应用账单，比如托管账单、网络带宽账单、监控报告、日志收集、海量存储、预估资源账单等。还有其他系列的法案会陆续进来。

总结

最后，让我总结一下。在去哪儿的人工运维过程中，我们经历了不同的阶段。

我们发现当应用扩展到一定规模时，需要对平台进行运维。手工或半手工的方法特别费力，但一般也会发现一些错误甚至失败。去哪儿的人工运维也做得非常好。如何展示？

我是2013年加入公司的，刚加入公司的时候，日常运维大概有五六个人。现在我们有六人日常运维。我们推出了运维机器人，运维第七人。 .

我们仍然保持六人的状态。我们的规模增长了很多倍，从一百到一万，规模扩大了数百倍，我们的日常运维人员没有减少。这是手动操作和维护平台。好处。

应用程序的可用性需要通过监控和报告系统来保证。基本上，在一个应用上线之前，它的所有关键报告和监控框架都会建立起来，这样如果应用出现问题，它会迅速回滚或调试。

因为我们有完善的监控和报告系统，所以去哪儿的故障相对较少。平均而言，三天内会出现两到三个故障。

但是，去哪儿的故障可能与其他故障不一样。去哪儿对故障的要求更加严格。我们会为每个网络故障记录成批的故障。

例如，监控系统不在画面中。已经超过5分钟了。我们可以考虑P1和P2的失败。

在这样严格的要求下，我们的失败率不会太高。加入公司四年以来，累计失败次数只有3000左右。

为了保证我们整个运维生态的发展，我们需要开放数据，开放需要给应用一个ID。有了这个ID，我们就可以在各种运维系统和平台上共享数据，形成良性的生态循环。