|
|
|
|
移动端

1.5 运维自动化的方法论

《运维前线:一线运维专家的运维方法、技巧与实践》本书共有14位作者,包含了在腾讯、YY语音、UC、京东、盛大游戏、金山西山居、猎豹移动、广发银行、优维科技等多家公司工作的实践经验,基本覆盖了互联网和传统行业运维的各个领域,估计这是迄今为止第一本由这么多资深运维专家联合写成的图书,也是第一本分享了众多一线运维专家亲身实践的图书。本节为大家介绍运维自动化的方法论。

作者:云技术社区来源:机械工业出版社|2017-04-22 15:22

开发者盛宴来袭!7月28日51CTO首届开发者大赛决赛带来技术创新分享

1.5 运维自动化的方法论

1.全局驱动

无论是全部自动化管理平台的规划,还是某个平台的规划,都希望大家能够找到一个全局的立足点。比如说我们当时成立持续部署服务平台的时候,大家把全局的目标对齐于提高产品交付的速度和质量,开发、测试、运维很快就达成共识了。目前这个平台建设完成之后,运维已经从发布变更流程中彻底退出了,真正实现了让运维变成审核者。

2.分而治之

从上面的几个维度中可以看到有很多系统,如果每个系统都要建设的话,那么周期和难度都将很大。所以需要分而治之,特别是线上架构组件的管理系统,更需要随着组件的交付一并交付运维管理能力,比如面向组件的自动化管理能力、运维的监控能力、运维的数据分析能力等。之前我也表达过类似的观点,所有只交付组件,不交付管理能力的研发都是耍流氓。因为从运维的角度来说,这样低价值的交付产品越多,越会导致运维不堪重负。而如果让运维从头去构建这个管理,则他们需要花费很多的时间去了解,从而导致系统建设周期拉长。举个例子,比如说某个分布式cache服务,做得不好的,是通过读取日志然后对其进行监控;做得好的,是给你开启一个管理端口,让你从端口中读取状态信息。这就大大降低了系统的复杂度(不用进行日志采集和处理组件了)。

分而治之,其实就是让不同的团队做不同的事情,不要将所有事情全部压给运维;其次不同的时期建设不同的系统,不要在同一时刻做很多系统,从而避免战线过长。当然如果有很多运维研发人员的话,就另当别论了。

3.自底向上

自底向上,其实是让大家找到一个更清晰更具体的系统建设目标来展开工作。从系统分解上,来让大家规避被一个庞大而模糊的目标带入歧途。如果一上来,我们就说要做一个全自动的运维管理系统,那样很容易就会让运维研发团队迷失方向。所以这里可以先设定全局和最终目标(全自动化),然后从底层逐步构建地基,做框架,最后再盖一个完整的房子,详见图1-1。

4.边界清晰

边界有两个维度,一个是管理边界;一个是职能边界。

首先是管理边界,其是从Owner的角度出发的,谁产生服务,谁就是Owner,管理统一都是运维。比如研发提供了一个统一的分布式消息队列服务,那么Owner就是研发,他应该对可运维性负第一责任,不要让运维去承担这个服务的WebAdmin管理系统建设任务。

其次是职能边界,深层次的理解是组件的功能范围。对运维架构师的考验也就在这儿,比如说让LVS去承担业务异常的容灾和容错切换是不合适的;让DNS跨过LVS层,负责后端服务异常的自动容错处理也是不合适的。如果不把职能界定清楚,将会导致系统做很多无用功,这会增加系统建设的复杂度。

5.插件化

插件化的思维无处不在,在面对纷繁复杂的管理对象时,我们进行抽象,提供管理模式,然后将具体的实现交给用户,这点在我们日常所见的运维系统中经常可以看到,比如说Nagios就是一种插件化的采集思路。对于配置管理来说,Puppet采用的也是这个思路。对于最上层的调度管理系统,可以让运维自己去编写执行器,特别是和业务紧密相关的,但最终运维整个控制权还是要交给平台。我的经验是,在应用服务层和架构服务层,不要引入插件化的管理方案,过多的插件化部署,会让生产环境的管理最终混乱不堪,甚至失控。所以提供类SSH界面的运维发布和部署平台,是没有任何运维价值的。

喜欢的朋友可以添加我们的微信账号:

51CTO读书频道二维码


51CTO读书频道活动讨论群:342347198

【责任编辑:book TEL:(010)68476606】

回书目   上一节   下一节
点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

网络技术应试辅导(三级)

本书根据教育部考试中心2004年最新发布的《全国计算机等级考试大纲》编写,针对计算机等级考试三级网络技术各方面的考点进行讲解和训练。本...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊