618大促之一键扩容

作者：李彬，运维开发工程师，负责达达-京东到家应用运维以及运维开发工作

前言

从零进入业务高速发展期，大多数公司都会有个问题，就是运维能力滞后，进而留下技术债等待未来爆发，做过电商的童鞋都知道，每逢大促必搭压测环境必会扩容，那么下面的技术债就找上门来了。

对运维有一定了解的朋友，肯定会想到用“自动化”手段来解决上述问题，那自动化如何做呢？

2017年618大促时，单台扩容耗时在18分钟左右，多台扩容取决于交互系统信息录入手速以及环境是否标准(无标准，仅环境就能弄半天)。

历经去年618大促痛苦备战，我们进行了一些系统改造和优化工作，在今年618大促单/多台扩容仅需5分钟，对运维人员来说就是申请好机器加进去，喝着咖啡等待就行（很舒服）。

运维标准化

万丈高楼平地起，地基都没打好怎敢盖楼？运维也是，要想做自动化，必须标准化先行。

上述标准化规范是根据实际情况制定，详细内容我就不贴了，各家都不太一样。

着重讲下应用命名和日志标准化：

应用命名：从项目命名开始到代码仓库、CMDB、发布系统、服务注册名称等等都统一，不然系统对接时，应用名不一致很头疼
日志标准：和业务方约定好日志目录、文件命名以及输出内容格式，当应用在机器上运行起来，只要是按照约定输出就能自动采集(初始化时安装日志采集程序)送往ES集群，日常故障排查完全无须登陆机器

其实标准化识别、规范整理是个很枯燥无趣很难一下体现价值的事情，但是它值得我们为此付出，因为我们收获的远远大于付出。

公有云CMDB

标准化识别出来形成规范，就是我们开始建设CMDB的契机，用自动化和流程化的方式将标准化固化下来。

CMDB全称叫配置管理数据库，管理着运维对象(硬件、网络、应用)所需信息，这些信息支持其他系统(发布、监控、持续集成)流程运转，是运维体系里的“基石”。

达达-京东到家使用公有云并非IDC，这样的差异在建设CMDB时，会发生如下变化：

上述提到变化，其实最主要是第三点，公有云已经有完整数据记录了，还需要建设吗？

这是非常有必要的，随着服务化拆分，面对众多服务在效率、质量和管理等挑战上，运维人员不应当再以主机的角度去运维，而是以应用管理的角度。

虽然公有云管理后台有完整数据记录了，但呈现的数据还是以主机形态，而不是应用形态，基于此在公有云CMDB建设时，应当侧重应用管理，弱化资产块，资产块只需做到主机申请、主机下线场景即可。

应用管理建设思路：

应用创建阶段：

统一应用创建入口在CMDB中，这样周边系统：监控、发布、服务注册、LB也会生成对应应用，并且不会出现应用名适配问题。

应用元数据要能输出被利用，例如监控系统，在应用出现报警时可以定向发送给运维负责人和研发负责人，持续集成可以获取Git仓库地址做Build，代码合并时可以给CodeReview负责人发送提醒。

应用运行阶段(添加/扩容主机)：

输入对应IP点击确定，就会完成CMDB应用主机添加以及周边系统对应应用主机添加，不仅如此还会根据应用定义Playbook完成初始化操作，如果是扩容操作还会调用发布系统完成代码发布。

应用下线阶段(删除/缩容主机，应用下线)：

以上图为例，勾选对应主机点击删除按钮(有权限控制)，就会完成关联系统的应用主机解绑删除！应用下线目前还没做成按钮触发，需要人工二次确认。

自助代码发布

提了CMDB自然不能遗漏发布系统，毕竟效率两兄弟；在2017年618大促时，发布系统在节点录入、代码初始化、启用禁用节点上运维效率不是那么友好，为改善此现象以应对来年618大促。

我们做了如下工作：

现在日常发布：

点击变更按钮，根据本次想要做的变更操作（发布、回滚、重启）点击确定即可，如有权限就会开始变更，否则提示你需申请权限。

而大促扩容，只需在CMDB应用管理添加主机，就可以完成主机初始化、代码发布以及节点上线等操作，整个过程约五分钟（很舒适）。

总结

本次分享以运维效率展开，以CMDB为核心，串联各个系统之间交互来提升运维效率。

限于篇幅原因并未讲的很细致，接下来会有单个运维系统全面解析，敬请期待！！

从达达-京东到家6.18实践经验来看，只有当运维效率提升了，运维人员才能去做更多有价值的事情，例如，持续集成与交付、稳定性保障、成本优化与控制，而这些事情也能让运维人员在日常当中收获成就感与满足感。

本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请点击举报。