学习新知新具-阿里云开发者社区

开发者社区> 开发与运维> 正文

学习新知新具

简介: 360运维经验,将运维作成产品 。。。。。。。。。。。 在工具化过程中,我们秉着低成本、拿来即用的原则,借鉴业界成型的方案,同时将精力用在对开源软件的研究中,有开源工具就绝不自己凭空创造。初期,我们只围绕开源软件做周边脚本开发,不动核心代码,在实践中总结经验。

360运维经验,将运维作成产品

。。。。。。。。。。。

在工具化过程中,我们秉着低成本、拿来即用的原则,借鉴业界成型的方案,同时将精力用在对开源软件的研究中,有开源工具就绝不自己凭空创造。初期,我们只围绕开源软件做周边脚本开发,不动核心代码,在实践中总结经验。例如,在最基础的部署软件环境中,我们基于YUM搭建了自己的包管理系统,将常用软件打包,同时根据项目做成模板,这样无论是初始安装还是扩容都能在分分钟完成。配置文件管理利用Puppet完成,服务器批量操控依赖SaltStack。就这样我们的运维兵器谱在不断地丰富。

另外,运维工作离不开监控报警,这是一件让无数运维人苦不堪言的事情。而会休息才会工作,监控体系必须优化。

我们的监控大概分为系统级、应用级、项目逻辑和用户体验四部分。系统级主要监控硬件和网络等;应用级主要监控常用软件的健康状况;项目逻辑监控主要模拟用户行为探测项目功能点是否运行正常;用户体验监控主要联动博睿和基调等第三方监控一起优化用户体验。我们用过的工具很多,开源工具有Nagios、 Cacti、Ganglia、Zabbix等,同时自己也开发了一些针对项目场景的监控工具,但万变不离其宗,都是围绕上述几个维度进行监控,然后再进行分级预警和报警。

为了减少报警骚扰,我们分级处理,将报警分为邮件预警、短信报警和疯狂短信报警。以磁盘空间监控为例:每天下午6点,统计磁盘使用率超过80%的机器,发出邮件预警,下班前解决;在预警的基础上,超过85%触发短信报警;超过90%就要持续报警,避免事故的发生。此外,随着服务器数量的增多,硬件故障在所难免,架构设计需要考虑高可用方案,冗余范围内的服务器故障会以邮件预警的方式发出,避免对运维工程师的骚扰。

有了监控工具和分级机制,还需要有好的制度。为了大部分人可以安心休息,我们每天有专人负责处理常规报警,遇到无法解决的问题才要求他人协助。第二天的负责人要针对第一天的报警找出根本原因,并尽力解决,因为如果无法根治,困扰将持续发生。所谓线上无小事,实际工作中复杂场景引发的问题数不胜数,所以可以宽容第一次错误,但不能接受同样问题发生第二次,。。。。。。。。。。。

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

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章