前言 从零进入业务高速发展期,大多数公司都会有个问题,就是运维能力滞后,进而留下技术债等待未来爆发,做过电商的童鞋都知道,每逢大促必搭压测环境必会扩容,那么下面的技术债就找上门来了。
对运维有一定了解的朋友,肯定会想到用“自动化”手段来解决上述问题,那自动化如何做呢? 2017年618大促时,单台扩容耗时在18分钟左右,多台扩容取决于交互系统信息录入手速以及环境是否标准(无标准,仅环境就能弄半天)。 历经去年618大促痛苦备战,我们进行了一些系统改造和优化工作,在今年618大促单/多台扩容仅需5分钟,对运维人员来说就是申请好机器加进去,喝着咖啡等待就行(很舒服)。 运维标准化 万丈高楼平地起,地基都没打好怎敢盖楼? 运维也是,要想做自动化,必须标准化先行。 上述标准化规范是根据实际情况制定,详细内容我就不贴了,各家都不太一样。 着重讲下应用命名和日志标准化:
其实标准化识别、规范整理是个很枯燥无趣很难一下体现价值的事情,但是它值得我们为此付出,因为我们收获的远远大于付出。 公有云CMDB 标准化识别出来形成规范,就是我们开始建设CMDB的契机,用自动化和流程化的方式将标准化固化下来。 CMDB全称叫配置管理数据库,管理着运维对象(硬件、网络、应用)所需信息,这些信息支持其他系统(发布、监控、持续集成)流程运转,是运维体系里的“基石”。 达达-京东到家使用公有云并非IDC,这样的差异在建设CMDB时,会发生如下变化:
上述提到变化,其实最主要是第三点,公有云已经有完整数据记录了,还需要建设吗? 这是非常有必要的,随着服务化拆分,面对众多服务在效率、质量和管理等挑战上,运维人员不应当再以主机的角度去运维,而是以应用管理的角度。 虽然公有云管理后台有完整数据记录了,但呈现的数据还是以主机形态,而不是应用形态,基于此在公有云CMDB建设时,应当侧重应用管理,弱化资产块,资产块只需做到主机申请、主机下线场景即可。 应用管理建设思路:
应用创建阶段: 统一应用创建入口在CMDB中,这样周边系统:监控、发布、服务注册、LB也会生成对应应用,并且不会出现应用名适配问题。 应用元数据要能输出被利用,例如监控系统,在应用出现报警时可以定向发送给运维负责人和研发负责人,持续集成可以获取Git仓库地址做Build,代码合并时可以给CodeReview负责人发送提醒。 应用运行阶段(添加/扩容主机): 输入对应IP点击确定,就会完成CMDB应用主机添加以及周边系统对应应用主机添加,不仅如此还会根据应用定义Playbook完成初始化操作,如果是扩容操作还会调用发布系统完成代码发布。 应用下线阶段(删除/缩容主机,应用下线): 以上图为例,勾选对应主机点击删除按钮(有权限控制),就会完成关联系统的应用主机解绑删除!应用下线目前还没做成按钮触发,需要人工二次确认。 自助代码发布 提了CMDB自然不能遗漏发布系统,毕竟效率两兄弟;在2017年618大促时,发布系统在节点录入、代码初始化、启用禁用节点上运维效率不是那么友好,为改善此现象以应对来年618大促。 我们做了如下工作:
现在日常发布: 点击变更按钮,根据本次想要做的变更操作(发布、回滚、重启)点击确定即可,如有权限就会开始变更,否则提示你需申请权限。 而大促扩容,只需在CMDB应用管理添加主机,就可以完成主机初始化、代码发布以及节点上线等操作,整个过程约五分钟(很舒适)。 总结 本次分享以运维效率展开,以CMDB为核心,串联各个系统之间交互来提升运维效率。 限于篇幅原因并未讲的很细致,接下来会有单个运维系统全面解析,敬请期待!! 从达达-京东到家6.18实践经验来看,只有当运维效率提升了,运维人员才能去做更多有价值的事情,例如,持续集成与交付、稳定性保障、成本优化与控制,而这些事情也能让运维人员在日常当中收获成就感与满足感。
|
|