运维

运维

企业不同时期的运维规划

运维 OS小编 发表了文章 0 个评论 1418 次浏览 2020-11-02 22:32 来自相关话题

企业创业期企业创业初期,人员少,业务流量不大,服务器数量相对较少,系统复杂度不高。对于日常的业务管理操作,因人员少,吼一声,大家就登录服务器进行手工操作,属于各自为战,每个人都有自己的操作方式,权限管理混乱、编写代码的风格各异,缺少必要 ...查看全部

企业创业期

企业创业初期,人员少,业务流量不大,服务器数量相对较少,系统复杂度不高。对于日常的业务管理操作,因人员少,吼一声,大家就登录服务器进行手工操作,属于各自为战,每个人都有自己的操作方式,权限管理混乱、编写代码的风格各异,缺少必要的操作标准、流程机制,比如业务目录环境都是各式各样的。在这个阶段建议建立如下规范:


  • 统一权限管理:应用程序、操作员、管理员权限分离。
  • 制定完善的操作流程:先开发环境验证、测试环境验证、预生产环境、生产环境的基础操作流程,最小操作权限、最小化的目录权限为准则。
  • 制定代码发布流程和机制:以开发环境、测试环境发布为先,在预生产环境、生产环境发布制定相应的审核。
  • 制定代码编写规范:制定排版、注释、标识命名、异常处理等相关规范,避免出现个性化的代码。
  • 使用云商自有监控做基础监控,主要是cpu、内存、网络等。
  • 强化系统、业务基线安全。


企业高速发展期

在企业发展期,拿到融资后,业务快速发展,随着服务器规模、系统复杂度的增加,全人工的操作方式已经不能满足业务的快速发展需要。因此,运维人员逐渐开始使用批量化的操作工具,针对不同操作类型出现了不同的脚本程序。


但各团队都有自己的工具,每次操作需求发生变化时都需要调整工具。这主要是因为对于环境、操作的规范不够,导致可程序化处理能力较弱。此时,虽然效率提升了一部分,但很快又遇到了瓶颈。在这个阶段建议建立如下规范:


  • 制定运维相关脚本的编写标准:如统一相关备份空间、相关备份执行计划,制定相关脚本的执行人员、执行权限、执行时间。
  • 统一同类工具的使用:如数据连接工具、备份工具、数据同步工具等。
  • 确认相关的操作人,减少或者避免开发和测试在服务器上的相关操作。
  • 部署监控平台进一步的监管数据库、进程、日志等。
  • 使用第三方应用性能管理对应用性能做应用分析和优化。


企业稳定发展时期

在企业稳定期,在这个阶段,对于运维效率和误操作率有了更高的要求,我们决定开始建设运维平台,通过平台承载标准、流程,进而解放人力和提高质量。
这个时候对服务的变更动作进行了抽象,形成了操作方法、服务目录环境、服务运行方式等统一的标准。通过平台来约束操作流程。

在平台中强制需要运维人员填写相应的检查项,然后才可以继续执行后续的部署动作。在这个阶段建议建立如下运维平台:


  • 统一运维操作和管理平台:操作管理、权限管理、资源。
  • 统一日志平台:统一日志收集标准、日志收集接口,查询方式,查询授权。
  • 统一监控平台:强化监控,从系统、数据库、缓存、中间件、接口、业务性能等。
  • 统一发布平台:细化发布项目、发布权限、发布审核、回滚、备份等。
  • 加强安全防护:上线前做安全加固、安全评估、渗透测试等。
  • 统一开发规范:统一接口、数据库、配置文件等规范。


企业集团化、规模化发展时期

更大规模的服务数量、更复杂的服务关联关系、各个运维平台的林立,原有的将批量操作转化成平台操作的方式已经不再适合,需要对服务变更进行更高一层的抽象。比如智能告警、故障自愈、运营辅助决策等。


这个阶段需要大量的运维数据支持,做相应的数据分析、测试,才能使用,不然因误报或错误的故障自愈决策造成大规模的故障。


分享阅读原文: http://m6z.cn/6sGPLO

免费虚拟化OVM-V1.6版发布,新增虚拟机裸设备映射!

回复

大数据 maoliang 发起了问题 1 人关注 0 个回复 4026 次浏览 2017-05-04 14:26 来自相关话题

一个成熟的自动化运维系统应具备哪些功能?

运维 Nock 发表了文章 0 个评论 3428 次浏览 2017-04-15 16:47 来自相关话题

结合现在云计算和DevOps的发展趋势,我觉得一个成熟的自动化运维平台应该包括以下的特性: 一、支持混合云的CMDB​ 现在越来越多的服务器都转到了云上,而主流的公有云、私有云平台都拥有比较完备的资源管理的API,这些API也就是构建一 ...查看全部
结合现在云计算和DevOps的发展趋势,我觉得一个成熟的自动化运维平台应该包括以下的特性:
一、支持混合云的CMDB​
现在越来越多的服务器都转到了云上,而主流的公有云、私有云平台都拥有比较完备的资源管理的API,这些API也就是构建一个自动化CMDB的基础。

新一代的自动化运维平台应该是可以基于这些API来自动维护和管理相关的服务器、存储、网络、负载均衡的资源的。
通过API对资源的操作都应该被作为操作日志记录下来,以备作为后续操作审计的基础数据。

CMDB这个东西听上去是老生常谈,但这个确实是所有运维工具的基础设施。而基于开源工具做运维平台最大的麻烦,就是如何在各个工具之间把CMDB统一起来。CMDB不统一起来,就意味着一旦要增加一台服务器,可能要在各个运维工具里面都要同步一下,这个还是非常折腾滴。

二、比较完备的监控+应用性能分析(APM)
能支持对平台的可用性、服务器的性能、各种服务(web服务、应用服务、数据库服务)的性能进行监控。做的好一些应该能进行更深入、或者关联性的性能分析。

现在市面上一般都会将资源性能监控和应用性能监控(APM)混合着讲,这里面的产品确实也有很多都是重叠的,两方面都会涉及到。

开源的性能监控系统主流有的Zabbix、Nagios,国产的开源监控平台有小米OpenFalcon,但这些基本都只是做基本的资源监控(服务器,磁盘、网络等)和简单的服务软件的性能监控(中间件,数据库等)。

而市面上的APM系统更主打的功能是应用性能分析,比如能精确定位到某个应用的URL的访问速度快慢,某些SQL执行速度的快慢,这些对于开发人员和运维人员快速定位问题还是很有帮助的。

APM这方面的商业工具,国外比较主流的有New Reclic、Dynatrace,国内的也就是透视宝、Oneapm、听云等,他们也提供了API进行集成。

APM这方面的开源工具有pinpoint(一个韩国团队开源的),zipkin(twitter开源),cat(大众点评开源)。
 
三、有一个还不错UI的批量运维工具
在业务发展比较快的情况下,从几台服务器,到几十台服务器,再到几百台服务器,批量运维的需求很自然就产生了,老板也希望越少的人干越多的活。

现在也有不少开源的批量运维工具,也都比较成熟了,比如puppet、chef、ansible、saltstack。
puppet和chef都是ruby做的,实话实说,ruby的熟手市面上很少,比python不是难招一点。

我个人比较推荐使用ansible或者saltstack,这两个系统都是python写的,代码质量和社区活跃度都挺不错的。
ansible有官方的web ui——Tower,但实话实说不好用,所以我们也在重新做一套自己用起来更顺手的WEB UI。
 
四、日志集中分析工具
线上系统最常规的问题定位方式,就是日志分析了。
随着服务器的增多,日志的分析定位也成为一个难点和痛点(想象一下,系统出故障之后,要去几十甚至数百个节点去上去查日志,是有多折腾)。

国内有一家叫日志易的公司,是专门做日志分析方面的运维工具的。
另外还有一家log insight,也是做这个领域,但产品好像还处于beta阶段。

日志分析这个领域现在是一个热点,现在的开源方案也比较多了,比如著名的ELKStack,还有Flume+Kafka+Storm的体系。
上面这两个方案相对重一些,部署比较复杂,网上介绍的文章也不少。

比较轻量级的开源日志集中采集方案有python做的Sentry,他是通过改造各种语言的日志采集框架来实现日志的集中采集,各种主流的开发语言的日志框架都支持得很完整了,比如java的log4j和logpack。
 
Sentry的官网在此:Sentry - Track exceptions with modern error logging for JavaScript, Python, Ruby, Java, and Node.js.
 
五、持续集成和发布工具
这方面其实比较难有统一的需求,很多公司集成发布的做法都差异挺大的。持续集成方面,一般用jekins的比较多,这方面网上介绍的文章也很多。

而如何把打好的包发布至各台服务器,则可以通过批量运维工具或者脚本来完成了。版本发布的过程涉及到很多细节,包括了版本文件的上传、分发、版本管理、回滚等各种操作。

对于一般不太复杂的项目,我比较推荐的做法是把打包好的文件上传到svn or git上,然后通过脚本在各台服务器上进行发布操作就行了,这样其实是利用了SVN or GIT来完成文件的上传、分发、版本管理、回滚等各种操作。
 
六、安全漏洞扫描工具
现在一个稍微有点知名度的系统,都会遭受各种各样的安全攻击的折磨。

一般的公司不太可能请得起专职的安全工程师,所以运维工程师最好能自己借助一些安全扫描工具来发现自己系统的漏洞。

安全工具方面我了解不多,不太熟这个领域的开源工具。
 
之前乌云网推出过一个SaaS化的漏扫平台——唐朝巡航,有对外提供漏洞扫描的API,不过最近乌云网一直在升级,所以也就暂时无法调用了。个人觉得,如果上述功能都有了,基本上大部分中小规模企业的日常运维工作的高频操作都覆盖到了。

如果是比较大的互联网企业,或者还有一些特殊的业务需求,那就具体问题具体分析了。
作者:刀把五
链接:https://www.zhihu.com/question/23228213/answer/116940889  
来源:知乎

OVM混合虚拟化设计目标及设计思路

大数据 maoliang 发表了文章 0 个评论 2968 次浏览 2016-09-29 09:42 来自相关话题

1、OVM虚拟化的目标: OVM是要实现混合虚拟化,做一个大一统的资源管理和交付平台,纵观虚拟化市场,现在当属开源的KVM和Docker最火,我们工作过去有vmware,现在大量使用kvm,未来一定会考虑docker,但现有市场上的产 ...查看全部
1、OVM虚拟化的目标:

OVM是要实现混合虚拟化,做一个大一统的资源管理和交付平台,纵观虚拟化市场,现在当属开源的KVM和Docker最火,我们工作过去有vmware,现在大量使用kvm,未来一定会考虑docker,但现有市场上的产品要么架构太大,开发难度高,易用性不够强,要么就是单纯的虚拟化,类似vmware等。

新形式下,我们需要的产品要同时具备如下目标:

跨平台,支持KVM、Esxi和Docker容器

因为我们单位过去采用虚拟化技术混杂,上面又遗留很多虚拟机,这就要求我们新开发产品能够兼容不同hypervior,同时还能识别并管理原有hypervior上的虚拟机,能够识别并导入原数据库技术并不难,难的是导入后还能纳入新平台管理,这部分我们又研发了自动捕获技术,而不同混合虚拟化管理技术可以摆脱对底层Hypervisor的依赖,专心于资源的统一管理。

单独的用户自助服务门户

过去采用传统虚拟化时,解决了安装部署的麻烦,但资源的申请和扩容、准备资源和切割资源仍然没有变,还是要让我们做,占据了日常运维工作的大部分工作量,每天确实烦人,所以我们想而这部分工作是可以放给相关的部门Leader或者专员,来减少运维的工作量,所以我们希望新设计的OVM允许用户通过一个单独的Web门户来直接访问自己的资源(云主机、云硬盘、网络等),而且对自己的资源进行管理,而不需要知道资源的具体位置,同时用户的所有云主机都建立在高可用环境之上,也不必担心实际物理硬件故障引起服务瘫痪。

Opscode Chef自动化运维集成

实行自助服务后,有一个问题,就是软件不同版本部署不兼容,这就需要设计能够把操作系统、中间件、数据库、web能统一打包部署,减少自助用户哭天喊地甚至骂我们,我们通过对chef的集成,可以一键更新所有的虚拟机,在指定的虚拟机上安装指定的软件。有了chef工具,为虚拟机打补丁、安装软件,只需要几个简单的命令即可搞定。

可持续性

做运维不要故障处理办法是不行,而且还要自动化的,同时我们有vmware和kvm,就需要新平台能在esxi上(不要vcenter,要付钱的)和kvm同时实现ha功能

可运维性
一个平台再强大,技术再厉害,如果不可运维,那结果可想而知。因此我们希望OVM可以给用户带来一个稳定、可控、安全的生产环境

弹性伸缩
自助服务部门拿到资源后,通过对各项目资源的限额,以及对各虚拟机和容器性能指标的实时监控,可以实现弹性的资源伸缩,达到合理分配利用资源。

资源池化
将数据中心的计算、存储、网络资源全部池化,然后通过OVM虚拟化平台统一对外提供IaaS服务。

2、OVM设计思路

OVM架构选型一

我们觉得架构就是一个产品的灵魂所在,决定着产品日后的发展。

我们团队在产品选型初期,分别调研了目前比较热门的openstack,以及前几年的明星产品convirt、ovirt,这几个产品可谓是典型的代表。

Openstack偏重于公有云,架构设计的很不错,其分布式、插件式的模块化架构,可以有效避免单点故障的发生,从发布之初便备受推崇,但是其存在的问题也同样令人头疼目前使用Openstack的大多是一些有实力的IDC、大型的互联网公司在用。而对于一般的企业来说,没有强大的开发和维护团队,并不敢大规模的采用openstack,初期使用一段时间后我们放弃了OS。

而前几年的convirt,在当时也掀起了一股使用热潮,其简单化的使用体验,足以满足小企业的虚拟化需求,但是他的问题是架构采用了集中式的架构,而且对于上了规模之后,也会带来性能方面的瓶颈,除非是把数据库等一些组件松藕合,解决起来也比较麻烦,所以到了后期也是不温不火,官方也停止了社区的更新和维护。

OVM架构选型二

      通过对以上产品的优劣势分析,我们决定采用用分布式、松耦合的模块化插件架构,分布式使其可以规避单点故障,达到业务持续高可用,松耦合的模块化特点让产品在后期的扩展性方面不受任何限制,使其向下可以兼容数据中心所有硬件(通过OVM标准的Rest API接口),向上可以实现插件式的我们即将需要的工作流引擎、计费引擎、报表引擎、桌面云引擎和自动化运维引擎。

而目前阶段我们则专心于实现虚拟化的全部功能,发掘内部对虚拟化的需求,打造一款真正简单、易用、稳定、可运维的一款虚拟化管理软件,并预留向上、向下的接口留作后期发展。(架构图大家可以查看刚才上面发的图片)

虚拟化技术选择

    Docker当下很火,其轻量级、灵活、高密度部署是优点,但是大规模使用还未成熟。许多场景还是需要依赖传统的虚拟化技术。所以我们选择传统虚拟化技术KVM+Docker,确保线上业务稳定性、连续性的同时,开发、测试环境又可以利用到Docker的轻量级、高密度和灵活。

     另外很多用户的生产环境存在不止一种虚拟化技术,例如KVM+Esxi组合、KVM+XenServer组合、KVM+Hyper-V组合,而目前的虚拟化管理平台,大多都是只支持一种Hypervisor的管理,用户想要维护不同的虚拟化技术的虚拟机,就要反复的在不同环境之间切换。

    基于此考虑,我和团队内部和外部一些同行选择兼容(兼容KVM、Esxi,Docker),并自主打造新一代虚拟化管理平台——混合虚拟化。

网络  

 网络方面,我们对所有Hypervisor的虚拟机使用统一的网络管理(包括Docker容器),这样做的一个好处就是可以减少运维工作量,降低网络复杂性。初期我们只实现2层的虚拟网络管理,为虚拟机和容器提供Vlan隔离、DHCP分配网络,当然也可以手工为虚拟机挑选一个网络,这个可以满足一般的虚拟化需求,后期我们会在此基础上增加虚拟网络防火墙、负载均衡。

存储

存储上面我们采用本地存储+NFS两种方式,对于一般中小企业来说,不希望购买高昂的商业存储,直接使用本地存储虚拟机的性能是最好的,而且我们也提供了存储快照、存储热迁移、虚拟机的无共享热迁移来提升业务安全。此外NFS作为辅助,可以为一些高风险业务提供HA。后期存储方面我们会考虑集成Ceph和GlusterFS存储来提升存储管理。

镜像中心

顾名思义,镜像中心就是用来存放镜像的。传统虚拟化我们使用NFS来作为镜像中心,所有宿主机共享一个镜像中心,这样可以更方便的来统一管理镜像,而针对Docker容器则保留了使用Docker自己的私有仓库,但是我们在WEB UI的镜像中心增加了从Docker私有仓库下载模板这么一个功能,实现了在同一个镜像中心的管理,后期我们会着重打造传统虚拟化镜像与Docker镜像的相互转换,实现两者内容的统一。

HA

OVM 主机HA依然坚持全兼容策略,支持对可管理的所有Hypervisor的HA。

在启用HA的资源池,当检测到一个Hypervisor故障,创建和运行在该Hypervisor共享存储上的虚拟机将在相同资源池下的另外一个主机上重启。

具体工作流程为:

第一次检测到故障会将该故障主机标记;

第二次检测依然故障将启动迁移任务;

迁移任务启动后将在该故障主机所在的资源池寻找合适的主机;

确定合适主机后,会将故障主机上所有的虚拟机自动迁移到合适的主机上面并重新启动;

 

VM分配策略

负载均衡

PERFORMANCE(性能): 这条策略分配虚拟机到不同的主机上。它挑选一组中可用资源最多的主机来部署虚拟机。如果有多个主机都有相同的资源可用,它使用一个循环算法,每个虚拟机分配到一个不同的主机上。

PROGRESSIVE(逐行扫描): 这条策略意味着,所有虚拟机将被分配在同一个主机上,直到它的资源被用尽。此项策略将一个主机资源使用完,然后再切换到另一个主机。

负载均衡级别

所有资源池: 如果选定此选项,则负载均衡级别策略将适用于所选定数据中心的所有资源池中的主机。

所有主机: 该策略将适用于所选数据中心单个资源池的所有主机。

特定主机: 该策略仅适用于所选的特定主机。

 

VM设计一

VM是整个虚拟化平台的核心,我们开发了一个单独的模块来负责虚拟机的相关操作。其采用异步通信和独立的并行操作,提升了虚拟机性能、稳定性和扩展性。

可扩展性:独立、并发

可追溯性:错误信息和log、监控控制台、性能

非阻塞操作:稳定性、改进重新配置、改进回滚、标准、统一的hypervisor通信、自动化测试

 

VM设计二

我们设计基于vApp来部署虚拟机,一个vApp可包含N个虚拟机:

N 个虚拟机配置

N个开机请求

我们希望并行运行N个配置(要求资源允许),并在配置后每个虚拟机请求一个开机。这些操作都是并发和独立的。

 

平台设计

OVM产品目前由三大组件、七大模块组成。其中三大组件分别为OVM UI、OVM API和OVM数据中心组件。

OVM UI提供WEB自服务界面,OVM API负责UI和数据中心组件之间的交互,OVM数据中心组件分别提供不同的功能。七大模块分别负责不同的功能实现,和三大组件之间分别交互。

VDC资源限额

管理员可以为每个VDC设置资源限额,防止资源的过度浪费。

账户管理

OVM提供存储SDK、备份SDK,以及虚拟防火墙SDK,轻松与第三方实现集成

获得帮助

下载请访问OVM社区官网:51ovm.com

使用过程中遇到什么问题及获得下载密码,加入OVM社区qq官方交流群:22265939

“ 实践是检验真理唯一标准“,OVM社区视您为社区的发展动力,此刻,诚邀您参与我们的调查,共同做出一款真正解决问题、放心的产品,一起推动国内虚拟化的进步和发展。

填写调查问卷!只需1分钟喔!

免费OVM混合虚拟化震撼来袭,有奖征文活动正式启动 动感平衡代步车等你来拿!

科技前沿 maoliang 发表了文章 4 个评论 2487 次浏览 2016-08-16 11:43 来自相关话题

OVM是什么? 国内首款、永久免费、企业级混合虚拟化管理平台 不到2个月,OVM社区公众号关注超300人,qq群、微信群超350人,我们是,是是偶需要各位大神的呐喊 吐槽! 国内首款混合虚拟化OVM体验征文活动 ...查看全部
OVM是什么?
国内首款、永久免费、企业级混合虚拟化管理平台
不到2个月,OVM社区公众号关注超300人,qq群、微信群超350人,我们是,是是偶需要各位大神的呐喊 吐槽!

国内首款混合虚拟化OVM体验征文活动正式启动,你的想法有可能让中国的虚拟化技术迈进一大步!热邀各方狂人,爱好者免费体验,参与有奖征文,获惊喜大奖!

一等奖:价值近1500元电动智能体感代步车
二等奖:金士顿系列固态硬盘
三等奖:森泊保温杯金属创意蓝牙音响

更多请查阅附件,或者加入OVM社区qq交流群: 22265939  或者微信公众号:openvm
官网网站:51ovm.com
 

跨境电商Crazysales的高稳定性架构实践

运维 cloudwise 发表了文章 0 个评论 3724 次浏览 2016-05-13 11:55 来自相关话题

Crazysales是一家典型的跨境电商企业,以澳洲和英国作为主要目标市场,产品大多数由国内供应商提供。Crazysales不但是Amazon、eBay等大型电商平台上的大卖家,同时在澳洲、新西兰建设有自营电商网站,为广大用户提供完整的网购服务。  ...查看全部
Crazysales是一家典型的跨境电商企业,以澳洲和英国作为主要目标市场,产品大多数由国内供应商提供。Crazysales不但是Amazon、eBay等大型电商平台上的大卖家,同时在澳洲、新西兰建设有自营电商网站,为广大用户提供完整的网购服务。 
 
1.png



由于涉及跨国网络部署,不可避免地需要穿过“万里长城”,因此应用架构相对普通电商网站更加复杂,管理成本也自然提升,如何能够及时了解分布在中国、澳洲、英国等地不同业务系统的运行状态,是运维部门最关心的工作。

跨境电商的典型IT架构

Crazysales的核心业务系统及网店系统均搭建在Amazon的AWS平台之上,用Amazon CloudFront进行前端内容分发,而后端的数据维护平台因为供应商在国内,所以也在国内。 系统架构如下图:

2.png


目前,我们应用的技术都不是“高大上”的新技术,但稳定性得到很好的保证: 1.传统的PHP+LINUX+MYSQL,辅助数据的统计和分析应用mongoDB , 搜索引擎基于Solr。 系统架构做到前后低耦合,前端网站强依赖数据库转变成弱依赖。 2.MYSQL部署了两台slave 和定时静态备份数据,确保数据库的异地备份,和读写分离,为以后的无限扩展搭好基础。 3.通过每个应用层的监控,及时发现系统的瓶颈,针对性地优化。 整套系统都是我们团队经过多年合作开发逐步建立和维护的,所以很难保证统一的代码风格和代码水平,那是可遇不可求的。因此,必须建立合理的监控体系及时发现项目管理的漏洞、测试的漏洞、线上的性能瓶颈,这都让运维的工作在整个系统生命周期里更重要,这也是时下运维开发工程师的工作核心。

跨境电商的最佳监控解决方案

因为使用了Amazon的云服务,所以我们运维工程师不必花费大量时间维护基础硬件设施,而有更多的时间和精力来研究和优化我们的业务系统,其中监控体系是令我们为之骄傲的一部分。 

3.png


我们的自建监控系统能够及时、准确的发现部署在AWS上和国内的各个业务系统的运行状况,但对于通过CloudFront分发出去的前端内容,以及主要分布于英国、澳大利亚、新西兰等不同国家的用户的访问体验,则是自建监控系统很难准确感知的。另外我们的开发和运维团队主要在国内,因此需要一款既能准确感知海外用户访问Crazysales网站情况,又能通过手机短信、微信等手段给国内技术团队提供准确告警消息的监控工具。经过多方测试,我们最终采用云智慧的监控宝网站监控和网页性能监控功能,负责网站从CDN到前端浏览器环节的可用性监控。  

4.png

 
各个层级设不同的监控点

红色部分使用监控宝的监控系统,绿色是监控宝和自建监控系统混合使用 这是我们目前实施的监控架构: 通过脚本/自建监控系统 / 外部监控点(模拟真实客户访问) 多种实时监控数据来监测业务系统的运作状态,根据不同系统的特性来调整数据采样的频率,多维度的监控和及时的告警信息让维护人员及时知道系统的运作情况,保障系统的正常运作和提高异常处理的及时性,最终实现故障出现前预防和故障出现后及时解决的效果。 例如,我们的内部监控系统发现数据库在凌晨4点会出现服务很忙,同时监控宝监控数据显示前台出现等待时间过长(>10s),通过和我们的后台任务调度系统的运行时间进行对比,发现一个JOB需要大量SQL查询,导致数据库CPU占用过多,因此及时调整SQL的查询指向其它Slave,同时优化该SQL。 如下图,马上就看到优化后的效果了:  

5.png


监控宝遍布全球的分布式监测点能够模拟真实客户访问,及时了解客户遇到的问题,避免IT团队无法取到第一手材料导致丢失重现系统故障的机会,这是我们设置外部监控点的原因。如果自己购买服务器和节点进行部署的话,维护成本很高,也不专业。监控宝基于SaaS的服务和收费模式,很好的解决了成本和维护的问题,帮助我们掌握在澳洲,英国,中国大陆等地的访问速度,可用性等数据。 监控宝模拟客户端在各个监测点的数据采样频率最高可达到5分钟每次,不但能在第一时间发现故障并给予告警,而且能帮助我们掌握Web页面的性能表现,让开发人员可以针对性进行页面优化。而监控宝在全球范围内不断地增加的监测点数量,也和我们公司不断拓展英语国家业务的发展思路不谋而合。 最后说一下告警方式,众所周知,告警是监控的最后一步,大部分监控平台使用的是邮件和短信告警,但现在最流行的社交应用是微信,也是我们现在用得最多和最及时的平台。因此,我们将多种收集数据的介质通过监控宝转化到微信进行提示,基本上能做到故障发生半分钟内运维同事作出反应。

免费虚拟化OVM-V1.6版发布,新增虚拟机裸设备映射!

回复

大数据 maoliang 发起了问题 1 人关注 0 个回复 4026 次浏览 2017-05-04 14:26 来自相关话题

企业不同时期的运维规划

运维 OS小编 发表了文章 0 个评论 1418 次浏览 2020-11-02 22:32 来自相关话题

企业创业期企业创业初期,人员少,业务流量不大,服务器数量相对较少,系统复杂度不高。对于日常的业务管理操作,因人员少,吼一声,大家就登录服务器进行手工操作,属于各自为战,每个人都有自己的操作方式,权限管理混乱、编写代码的风格各异,缺少必要 ...查看全部

企业创业期

企业创业初期,人员少,业务流量不大,服务器数量相对较少,系统复杂度不高。对于日常的业务管理操作,因人员少,吼一声,大家就登录服务器进行手工操作,属于各自为战,每个人都有自己的操作方式,权限管理混乱、编写代码的风格各异,缺少必要的操作标准、流程机制,比如业务目录环境都是各式各样的。在这个阶段建议建立如下规范:


  • 统一权限管理:应用程序、操作员、管理员权限分离。
  • 制定完善的操作流程:先开发环境验证、测试环境验证、预生产环境、生产环境的基础操作流程,最小操作权限、最小化的目录权限为准则。
  • 制定代码发布流程和机制:以开发环境、测试环境发布为先,在预生产环境、生产环境发布制定相应的审核。
  • 制定代码编写规范:制定排版、注释、标识命名、异常处理等相关规范,避免出现个性化的代码。
  • 使用云商自有监控做基础监控,主要是cpu、内存、网络等。
  • 强化系统、业务基线安全。


企业高速发展期

在企业发展期,拿到融资后,业务快速发展,随着服务器规模、系统复杂度的增加,全人工的操作方式已经不能满足业务的快速发展需要。因此,运维人员逐渐开始使用批量化的操作工具,针对不同操作类型出现了不同的脚本程序。


但各团队都有自己的工具,每次操作需求发生变化时都需要调整工具。这主要是因为对于环境、操作的规范不够,导致可程序化处理能力较弱。此时,虽然效率提升了一部分,但很快又遇到了瓶颈。在这个阶段建议建立如下规范:


  • 制定运维相关脚本的编写标准:如统一相关备份空间、相关备份执行计划,制定相关脚本的执行人员、执行权限、执行时间。
  • 统一同类工具的使用:如数据连接工具、备份工具、数据同步工具等。
  • 确认相关的操作人,减少或者避免开发和测试在服务器上的相关操作。
  • 部署监控平台进一步的监管数据库、进程、日志等。
  • 使用第三方应用性能管理对应用性能做应用分析和优化。


企业稳定发展时期

在企业稳定期,在这个阶段,对于运维效率和误操作率有了更高的要求,我们决定开始建设运维平台,通过平台承载标准、流程,进而解放人力和提高质量。
这个时候对服务的变更动作进行了抽象,形成了操作方法、服务目录环境、服务运行方式等统一的标准。通过平台来约束操作流程。

在平台中强制需要运维人员填写相应的检查项,然后才可以继续执行后续的部署动作。在这个阶段建议建立如下运维平台:


  • 统一运维操作和管理平台:操作管理、权限管理、资源。
  • 统一日志平台:统一日志收集标准、日志收集接口,查询方式,查询授权。
  • 统一监控平台:强化监控,从系统、数据库、缓存、中间件、接口、业务性能等。
  • 统一发布平台:细化发布项目、发布权限、发布审核、回滚、备份等。
  • 加强安全防护:上线前做安全加固、安全评估、渗透测试等。
  • 统一开发规范:统一接口、数据库、配置文件等规范。


企业集团化、规模化发展时期

更大规模的服务数量、更复杂的服务关联关系、各个运维平台的林立,原有的将批量操作转化成平台操作的方式已经不再适合,需要对服务变更进行更高一层的抽象。比如智能告警、故障自愈、运营辅助决策等。


这个阶段需要大量的运维数据支持,做相应的数据分析、测试,才能使用,不然因误报或错误的故障自愈决策造成大规模的故障。


分享阅读原文: http://m6z.cn/6sGPLO

一个成熟的自动化运维系统应具备哪些功能?

运维 Nock 发表了文章 0 个评论 3428 次浏览 2017-04-15 16:47 来自相关话题

结合现在云计算和DevOps的发展趋势,我觉得一个成熟的自动化运维平台应该包括以下的特性: 一、支持混合云的CMDB​ 现在越来越多的服务器都转到了云上,而主流的公有云、私有云平台都拥有比较完备的资源管理的API,这些API也就是构建一 ...查看全部
结合现在云计算和DevOps的发展趋势,我觉得一个成熟的自动化运维平台应该包括以下的特性:
一、支持混合云的CMDB​
现在越来越多的服务器都转到了云上,而主流的公有云、私有云平台都拥有比较完备的资源管理的API,这些API也就是构建一个自动化CMDB的基础。

新一代的自动化运维平台应该是可以基于这些API来自动维护和管理相关的服务器、存储、网络、负载均衡的资源的。
通过API对资源的操作都应该被作为操作日志记录下来,以备作为后续操作审计的基础数据。

CMDB这个东西听上去是老生常谈,但这个确实是所有运维工具的基础设施。而基于开源工具做运维平台最大的麻烦,就是如何在各个工具之间把CMDB统一起来。CMDB不统一起来,就意味着一旦要增加一台服务器,可能要在各个运维工具里面都要同步一下,这个还是非常折腾滴。

二、比较完备的监控+应用性能分析(APM)
能支持对平台的可用性、服务器的性能、各种服务(web服务、应用服务、数据库服务)的性能进行监控。做的好一些应该能进行更深入、或者关联性的性能分析。

现在市面上一般都会将资源性能监控和应用性能监控(APM)混合着讲,这里面的产品确实也有很多都是重叠的,两方面都会涉及到。

开源的性能监控系统主流有的Zabbix、Nagios,国产的开源监控平台有小米OpenFalcon,但这些基本都只是做基本的资源监控(服务器,磁盘、网络等)和简单的服务软件的性能监控(中间件,数据库等)。

而市面上的APM系统更主打的功能是应用性能分析,比如能精确定位到某个应用的URL的访问速度快慢,某些SQL执行速度的快慢,这些对于开发人员和运维人员快速定位问题还是很有帮助的。

APM这方面的商业工具,国外比较主流的有New Reclic、Dynatrace,国内的也就是透视宝、Oneapm、听云等,他们也提供了API进行集成。

APM这方面的开源工具有pinpoint(一个韩国团队开源的),zipkin(twitter开源),cat(大众点评开源)。
 
三、有一个还不错UI的批量运维工具
在业务发展比较快的情况下,从几台服务器,到几十台服务器,再到几百台服务器,批量运维的需求很自然就产生了,老板也希望越少的人干越多的活。

现在也有不少开源的批量运维工具,也都比较成熟了,比如puppet、chef、ansible、saltstack。
puppet和chef都是ruby做的,实话实说,ruby的熟手市面上很少,比python不是难招一点。

我个人比较推荐使用ansible或者saltstack,这两个系统都是python写的,代码质量和社区活跃度都挺不错的。
ansible有官方的web ui——Tower,但实话实说不好用,所以我们也在重新做一套自己用起来更顺手的WEB UI。
 
四、日志集中分析工具
线上系统最常规的问题定位方式,就是日志分析了。
随着服务器的增多,日志的分析定位也成为一个难点和痛点(想象一下,系统出故障之后,要去几十甚至数百个节点去上去查日志,是有多折腾)。

国内有一家叫日志易的公司,是专门做日志分析方面的运维工具的。
另外还有一家log insight,也是做这个领域,但产品好像还处于beta阶段。

日志分析这个领域现在是一个热点,现在的开源方案也比较多了,比如著名的ELKStack,还有Flume+Kafka+Storm的体系。
上面这两个方案相对重一些,部署比较复杂,网上介绍的文章也不少。

比较轻量级的开源日志集中采集方案有python做的Sentry,他是通过改造各种语言的日志采集框架来实现日志的集中采集,各种主流的开发语言的日志框架都支持得很完整了,比如java的log4j和logpack。
 
Sentry的官网在此:Sentry - Track exceptions with modern error logging for JavaScript, Python, Ruby, Java, and Node.js.
 
五、持续集成和发布工具
这方面其实比较难有统一的需求,很多公司集成发布的做法都差异挺大的。持续集成方面,一般用jekins的比较多,这方面网上介绍的文章也很多。

而如何把打好的包发布至各台服务器,则可以通过批量运维工具或者脚本来完成了。版本发布的过程涉及到很多细节,包括了版本文件的上传、分发、版本管理、回滚等各种操作。

对于一般不太复杂的项目,我比较推荐的做法是把打包好的文件上传到svn or git上,然后通过脚本在各台服务器上进行发布操作就行了,这样其实是利用了SVN or GIT来完成文件的上传、分发、版本管理、回滚等各种操作。
 
六、安全漏洞扫描工具
现在一个稍微有点知名度的系统,都会遭受各种各样的安全攻击的折磨。

一般的公司不太可能请得起专职的安全工程师,所以运维工程师最好能自己借助一些安全扫描工具来发现自己系统的漏洞。

安全工具方面我了解不多,不太熟这个领域的开源工具。
 
之前乌云网推出过一个SaaS化的漏扫平台——唐朝巡航,有对外提供漏洞扫描的API,不过最近乌云网一直在升级,所以也就暂时无法调用了。个人觉得,如果上述功能都有了,基本上大部分中小规模企业的日常运维工作的高频操作都覆盖到了。

如果是比较大的互联网企业,或者还有一些特殊的业务需求,那就具体问题具体分析了。
作者:刀把五
链接:https://www.zhihu.com/question/23228213/answer/116940889  
来源:知乎

OVM混合虚拟化设计目标及设计思路

大数据 maoliang 发表了文章 0 个评论 2968 次浏览 2016-09-29 09:42 来自相关话题

1、OVM虚拟化的目标: OVM是要实现混合虚拟化,做一个大一统的资源管理和交付平台,纵观虚拟化市场,现在当属开源的KVM和Docker最火,我们工作过去有vmware,现在大量使用kvm,未来一定会考虑docker,但现有市场上的产 ...查看全部
1、OVM虚拟化的目标:

OVM是要实现混合虚拟化,做一个大一统的资源管理和交付平台,纵观虚拟化市场,现在当属开源的KVM和Docker最火,我们工作过去有vmware,现在大量使用kvm,未来一定会考虑docker,但现有市场上的产品要么架构太大,开发难度高,易用性不够强,要么就是单纯的虚拟化,类似vmware等。

新形式下,我们需要的产品要同时具备如下目标:

跨平台,支持KVM、Esxi和Docker容器

因为我们单位过去采用虚拟化技术混杂,上面又遗留很多虚拟机,这就要求我们新开发产品能够兼容不同hypervior,同时还能识别并管理原有hypervior上的虚拟机,能够识别并导入原数据库技术并不难,难的是导入后还能纳入新平台管理,这部分我们又研发了自动捕获技术,而不同混合虚拟化管理技术可以摆脱对底层Hypervisor的依赖,专心于资源的统一管理。

单独的用户自助服务门户

过去采用传统虚拟化时,解决了安装部署的麻烦,但资源的申请和扩容、准备资源和切割资源仍然没有变,还是要让我们做,占据了日常运维工作的大部分工作量,每天确实烦人,所以我们想而这部分工作是可以放给相关的部门Leader或者专员,来减少运维的工作量,所以我们希望新设计的OVM允许用户通过一个单独的Web门户来直接访问自己的资源(云主机、云硬盘、网络等),而且对自己的资源进行管理,而不需要知道资源的具体位置,同时用户的所有云主机都建立在高可用环境之上,也不必担心实际物理硬件故障引起服务瘫痪。

Opscode Chef自动化运维集成

实行自助服务后,有一个问题,就是软件不同版本部署不兼容,这就需要设计能够把操作系统、中间件、数据库、web能统一打包部署,减少自助用户哭天喊地甚至骂我们,我们通过对chef的集成,可以一键更新所有的虚拟机,在指定的虚拟机上安装指定的软件。有了chef工具,为虚拟机打补丁、安装软件,只需要几个简单的命令即可搞定。

可持续性

做运维不要故障处理办法是不行,而且还要自动化的,同时我们有vmware和kvm,就需要新平台能在esxi上(不要vcenter,要付钱的)和kvm同时实现ha功能

可运维性
一个平台再强大,技术再厉害,如果不可运维,那结果可想而知。因此我们希望OVM可以给用户带来一个稳定、可控、安全的生产环境

弹性伸缩
自助服务部门拿到资源后,通过对各项目资源的限额,以及对各虚拟机和容器性能指标的实时监控,可以实现弹性的资源伸缩,达到合理分配利用资源。

资源池化
将数据中心的计算、存储、网络资源全部池化,然后通过OVM虚拟化平台统一对外提供IaaS服务。

2、OVM设计思路

OVM架构选型一

我们觉得架构就是一个产品的灵魂所在,决定着产品日后的发展。

我们团队在产品选型初期,分别调研了目前比较热门的openstack,以及前几年的明星产品convirt、ovirt,这几个产品可谓是典型的代表。

Openstack偏重于公有云,架构设计的很不错,其分布式、插件式的模块化架构,可以有效避免单点故障的发生,从发布之初便备受推崇,但是其存在的问题也同样令人头疼目前使用Openstack的大多是一些有实力的IDC、大型的互联网公司在用。而对于一般的企业来说,没有强大的开发和维护团队,并不敢大规模的采用openstack,初期使用一段时间后我们放弃了OS。

而前几年的convirt,在当时也掀起了一股使用热潮,其简单化的使用体验,足以满足小企业的虚拟化需求,但是他的问题是架构采用了集中式的架构,而且对于上了规模之后,也会带来性能方面的瓶颈,除非是把数据库等一些组件松藕合,解决起来也比较麻烦,所以到了后期也是不温不火,官方也停止了社区的更新和维护。

OVM架构选型二

      通过对以上产品的优劣势分析,我们决定采用用分布式、松耦合的模块化插件架构,分布式使其可以规避单点故障,达到业务持续高可用,松耦合的模块化特点让产品在后期的扩展性方面不受任何限制,使其向下可以兼容数据中心所有硬件(通过OVM标准的Rest API接口),向上可以实现插件式的我们即将需要的工作流引擎、计费引擎、报表引擎、桌面云引擎和自动化运维引擎。

而目前阶段我们则专心于实现虚拟化的全部功能,发掘内部对虚拟化的需求,打造一款真正简单、易用、稳定、可运维的一款虚拟化管理软件,并预留向上、向下的接口留作后期发展。(架构图大家可以查看刚才上面发的图片)

虚拟化技术选择

    Docker当下很火,其轻量级、灵活、高密度部署是优点,但是大规模使用还未成熟。许多场景还是需要依赖传统的虚拟化技术。所以我们选择传统虚拟化技术KVM+Docker,确保线上业务稳定性、连续性的同时,开发、测试环境又可以利用到Docker的轻量级、高密度和灵活。

     另外很多用户的生产环境存在不止一种虚拟化技术,例如KVM+Esxi组合、KVM+XenServer组合、KVM+Hyper-V组合,而目前的虚拟化管理平台,大多都是只支持一种Hypervisor的管理,用户想要维护不同的虚拟化技术的虚拟机,就要反复的在不同环境之间切换。

    基于此考虑,我和团队内部和外部一些同行选择兼容(兼容KVM、Esxi,Docker),并自主打造新一代虚拟化管理平台——混合虚拟化。

网络  

 网络方面,我们对所有Hypervisor的虚拟机使用统一的网络管理(包括Docker容器),这样做的一个好处就是可以减少运维工作量,降低网络复杂性。初期我们只实现2层的虚拟网络管理,为虚拟机和容器提供Vlan隔离、DHCP分配网络,当然也可以手工为虚拟机挑选一个网络,这个可以满足一般的虚拟化需求,后期我们会在此基础上增加虚拟网络防火墙、负载均衡。

存储

存储上面我们采用本地存储+NFS两种方式,对于一般中小企业来说,不希望购买高昂的商业存储,直接使用本地存储虚拟机的性能是最好的,而且我们也提供了存储快照、存储热迁移、虚拟机的无共享热迁移来提升业务安全。此外NFS作为辅助,可以为一些高风险业务提供HA。后期存储方面我们会考虑集成Ceph和GlusterFS存储来提升存储管理。

镜像中心

顾名思义,镜像中心就是用来存放镜像的。传统虚拟化我们使用NFS来作为镜像中心,所有宿主机共享一个镜像中心,这样可以更方便的来统一管理镜像,而针对Docker容器则保留了使用Docker自己的私有仓库,但是我们在WEB UI的镜像中心增加了从Docker私有仓库下载模板这么一个功能,实现了在同一个镜像中心的管理,后期我们会着重打造传统虚拟化镜像与Docker镜像的相互转换,实现两者内容的统一。

HA

OVM 主机HA依然坚持全兼容策略,支持对可管理的所有Hypervisor的HA。

在启用HA的资源池,当检测到一个Hypervisor故障,创建和运行在该Hypervisor共享存储上的虚拟机将在相同资源池下的另外一个主机上重启。

具体工作流程为:

第一次检测到故障会将该故障主机标记;

第二次检测依然故障将启动迁移任务;

迁移任务启动后将在该故障主机所在的资源池寻找合适的主机;

确定合适主机后,会将故障主机上所有的虚拟机自动迁移到合适的主机上面并重新启动;

 

VM分配策略

负载均衡

PERFORMANCE(性能): 这条策略分配虚拟机到不同的主机上。它挑选一组中可用资源最多的主机来部署虚拟机。如果有多个主机都有相同的资源可用,它使用一个循环算法,每个虚拟机分配到一个不同的主机上。

PROGRESSIVE(逐行扫描): 这条策略意味着,所有虚拟机将被分配在同一个主机上,直到它的资源被用尽。此项策略将一个主机资源使用完,然后再切换到另一个主机。

负载均衡级别

所有资源池: 如果选定此选项,则负载均衡级别策略将适用于所选定数据中心的所有资源池中的主机。

所有主机: 该策略将适用于所选数据中心单个资源池的所有主机。

特定主机: 该策略仅适用于所选的特定主机。

 

VM设计一

VM是整个虚拟化平台的核心,我们开发了一个单独的模块来负责虚拟机的相关操作。其采用异步通信和独立的并行操作,提升了虚拟机性能、稳定性和扩展性。

可扩展性:独立、并发

可追溯性:错误信息和log、监控控制台、性能

非阻塞操作:稳定性、改进重新配置、改进回滚、标准、统一的hypervisor通信、自动化测试

 

VM设计二

我们设计基于vApp来部署虚拟机,一个vApp可包含N个虚拟机:

N 个虚拟机配置

N个开机请求

我们希望并行运行N个配置(要求资源允许),并在配置后每个虚拟机请求一个开机。这些操作都是并发和独立的。

 

平台设计

OVM产品目前由三大组件、七大模块组成。其中三大组件分别为OVM UI、OVM API和OVM数据中心组件。

OVM UI提供WEB自服务界面,OVM API负责UI和数据中心组件之间的交互,OVM数据中心组件分别提供不同的功能。七大模块分别负责不同的功能实现,和三大组件之间分别交互。

VDC资源限额

管理员可以为每个VDC设置资源限额,防止资源的过度浪费。

账户管理

OVM提供存储SDK、备份SDK,以及虚拟防火墙SDK,轻松与第三方实现集成

获得帮助

下载请访问OVM社区官网:51ovm.com

使用过程中遇到什么问题及获得下载密码,加入OVM社区qq官方交流群:22265939

“ 实践是检验真理唯一标准“,OVM社区视您为社区的发展动力,此刻,诚邀您参与我们的调查,共同做出一款真正解决问题、放心的产品,一起推动国内虚拟化的进步和发展。

填写调查问卷!只需1分钟喔!

免费OVM混合虚拟化震撼来袭,有奖征文活动正式启动 动感平衡代步车等你来拿!

科技前沿 maoliang 发表了文章 4 个评论 2487 次浏览 2016-08-16 11:43 来自相关话题

OVM是什么? 国内首款、永久免费、企业级混合虚拟化管理平台 不到2个月,OVM社区公众号关注超300人,qq群、微信群超350人,我们是,是是偶需要各位大神的呐喊 吐槽! 国内首款混合虚拟化OVM体验征文活动 ...查看全部
OVM是什么?
国内首款、永久免费、企业级混合虚拟化管理平台
不到2个月,OVM社区公众号关注超300人,qq群、微信群超350人,我们是,是是偶需要各位大神的呐喊 吐槽!

国内首款混合虚拟化OVM体验征文活动正式启动,你的想法有可能让中国的虚拟化技术迈进一大步!热邀各方狂人,爱好者免费体验,参与有奖征文,获惊喜大奖!

一等奖:价值近1500元电动智能体感代步车
二等奖:金士顿系列固态硬盘
三等奖:森泊保温杯金属创意蓝牙音响

更多请查阅附件,或者加入OVM社区qq交流群: 22265939  或者微信公众号:openvm
官网网站:51ovm.com
 

跨境电商Crazysales的高稳定性架构实践

运维 cloudwise 发表了文章 0 个评论 3724 次浏览 2016-05-13 11:55 来自相关话题

Crazysales是一家典型的跨境电商企业,以澳洲和英国作为主要目标市场,产品大多数由国内供应商提供。Crazysales不但是Amazon、eBay等大型电商平台上的大卖家,同时在澳洲、新西兰建设有自营电商网站,为广大用户提供完整的网购服务。  ...查看全部
Crazysales是一家典型的跨境电商企业,以澳洲和英国作为主要目标市场,产品大多数由国内供应商提供。Crazysales不但是Amazon、eBay等大型电商平台上的大卖家,同时在澳洲、新西兰建设有自营电商网站,为广大用户提供完整的网购服务。 
 
1.png



由于涉及跨国网络部署,不可避免地需要穿过“万里长城”,因此应用架构相对普通电商网站更加复杂,管理成本也自然提升,如何能够及时了解分布在中国、澳洲、英国等地不同业务系统的运行状态,是运维部门最关心的工作。

跨境电商的典型IT架构

Crazysales的核心业务系统及网店系统均搭建在Amazon的AWS平台之上,用Amazon CloudFront进行前端内容分发,而后端的数据维护平台因为供应商在国内,所以也在国内。 系统架构如下图:

2.png


目前,我们应用的技术都不是“高大上”的新技术,但稳定性得到很好的保证: 1.传统的PHP+LINUX+MYSQL,辅助数据的统计和分析应用mongoDB , 搜索引擎基于Solr。 系统架构做到前后低耦合,前端网站强依赖数据库转变成弱依赖。 2.MYSQL部署了两台slave 和定时静态备份数据,确保数据库的异地备份,和读写分离,为以后的无限扩展搭好基础。 3.通过每个应用层的监控,及时发现系统的瓶颈,针对性地优化。 整套系统都是我们团队经过多年合作开发逐步建立和维护的,所以很难保证统一的代码风格和代码水平,那是可遇不可求的。因此,必须建立合理的监控体系及时发现项目管理的漏洞、测试的漏洞、线上的性能瓶颈,这都让运维的工作在整个系统生命周期里更重要,这也是时下运维开发工程师的工作核心。

跨境电商的最佳监控解决方案

因为使用了Amazon的云服务,所以我们运维工程师不必花费大量时间维护基础硬件设施,而有更多的时间和精力来研究和优化我们的业务系统,其中监控体系是令我们为之骄傲的一部分。 

3.png


我们的自建监控系统能够及时、准确的发现部署在AWS上和国内的各个业务系统的运行状况,但对于通过CloudFront分发出去的前端内容,以及主要分布于英国、澳大利亚、新西兰等不同国家的用户的访问体验,则是自建监控系统很难准确感知的。另外我们的开发和运维团队主要在国内,因此需要一款既能准确感知海外用户访问Crazysales网站情况,又能通过手机短信、微信等手段给国内技术团队提供准确告警消息的监控工具。经过多方测试,我们最终采用云智慧的监控宝网站监控和网页性能监控功能,负责网站从CDN到前端浏览器环节的可用性监控。  

4.png

 
各个层级设不同的监控点

红色部分使用监控宝的监控系统,绿色是监控宝和自建监控系统混合使用 这是我们目前实施的监控架构: 通过脚本/自建监控系统 / 外部监控点(模拟真实客户访问) 多种实时监控数据来监测业务系统的运作状态,根据不同系统的特性来调整数据采样的频率,多维度的监控和及时的告警信息让维护人员及时知道系统的运作情况,保障系统的正常运作和提高异常处理的及时性,最终实现故障出现前预防和故障出现后及时解决的效果。 例如,我们的内部监控系统发现数据库在凌晨4点会出现服务很忙,同时监控宝监控数据显示前台出现等待时间过长(>10s),通过和我们的后台任务调度系统的运行时间进行对比,发现一个JOB需要大量SQL查询,导致数据库CPU占用过多,因此及时调整SQL的查询指向其它Slave,同时优化该SQL。 如下图,马上就看到优化后的效果了:  

5.png


监控宝遍布全球的分布式监测点能够模拟真实客户访问,及时了解客户遇到的问题,避免IT团队无法取到第一手材料导致丢失重现系统故障的机会,这是我们设置外部监控点的原因。如果自己购买服务器和节点进行部署的话,维护成本很高,也不专业。监控宝基于SaaS的服务和收费模式,很好的解决了成本和维护的问题,帮助我们掌握在澳洲,英国,中国大陆等地的访问速度,可用性等数据。 监控宝模拟客户端在各个监测点的数据采样频率最高可达到5分钟每次,不但能在第一时间发现故障并给予告警,而且能帮助我们掌握Web页面的性能表现,让开发人员可以针对性进行页面优化。而监控宝在全球范围内不断地增加的监测点数量,也和我们公司不断拓展英语国家业务的发展思路不谋而合。 最后说一下告警方式,众所周知,告警是监控的最后一步,大部分监控平台使用的是邮件和短信告警,但现在最流行的社交应用是微信,也是我们现在用得最多和最及时的平台。因此,我们将多种收集数据的介质通过监控宝转化到微信进行提示,基本上能做到故障发生半分钟内运维同事作出反应。
运维,这里指互联网运维,通常属于技术部门,与研发、测试、系统管理同为互联网产品技术支撑的4大部门,这个划分在国内和国外以及大小公司间都会多少有一些不同。