运维前线:一线运维专家的运维方法、技巧与实践1.1 概述-阿里云开发者社区

开发者社区> 华章出版社> 正文

运维前线:一线运维专家的运维方法、技巧与实践1.1 概述

简介:

第1章

自动化运维之深度解码

作者简介

王津银,2005年硕士毕业,参与电信BOSS系统研发两年。而后于2007年进入腾讯公司接触运维,经历服务器从百到万的运维历程,先后在YY和UC参与不同业务形态的运维,期间带过前端运维、数据存储运维、YY语音、游戏运维、运维研发等多种运维团队,对运维有着全面的理解。极力倡导互联网价值的运维理念,即面向用户的价值是由自动化平台来交付和传递,同时由数据化来提炼和衡量的。“精益运维”理论的创始人。个人微信公众号“互联网运维杂谈”(waynewang_ops),粉丝2.5万人,现创办优维科技公司,旨在缩短企业到达互联网运维的路径。

自动化运维是一个人让人兴奋且容易失控的话题!兴奋是因为我想做一次尝试,把它的全貌和细节说清楚;容易失控是因为涉及点太多,一则怕遗漏,二则怕顾此失彼。带着这份复杂的心情,我们来一次自动化运维的解析之旅吧。说实话,一个运维团队的运维能力究竟如何,其实看一个自动化管理系统便可得知!


1.1 概述


作为开篇,首先让我们来熟悉一下运维全平台的规划体系吧,如图1-1所示。

很多人看到这样一个架构图,可能会纳闷,难道对于一个小型企业来说,也要实施如此复杂的运维自动化体系吗?其实,对于不同规模的企业来说,对运维自动化的诉求的确是不同的。对于大规模企业,如BAT,这些能力基本上都是必不可少的;而对于小型互联网企业,比如

 

图1-1 运维全平台规划体系

说App开发公司,则核心的自动化诉求可能更多的是配置管理工具,比如说Puppet、SaltStack或Jenkins+Rsync等。

我们不禁要问,有什么样的准则可以让我们作为依据来判断何时该如何导入自动化?应该导入自动化的哪些部分?当你需要持续、频繁地进行一些事情时,此时就需要引入自动化,比如说版本发布,如果这个时候你感觉到很痛苦,那么此时就需要引入自动化了。关于应该导入自动化的哪些部分,我个人的经验是根据角色去梳理他的工作现状(持续、频繁的工作),然后引入自动化的能力,再根据角色人数的多与少来确定事情的优先级,比如说系统管理和业务发布,很明显业务发布的优先级更高,因为它的自动化所带来的人力解放的收益更大。当然还有一种更理想的情况,那就是根据整体业务交付流来构建,以它的全流程自动化为目标,此时引入的是该交付链上所有的自动化能力,当然对于很多企业来说,这种自动化实现的代价很高,而得到的收益却很小。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

华章出版社

官方博客
官网链接