运维

全球说:要给 OneAlert 点100个赞

拥有回忆 提交于 2019-11-26 14:56:22
客户背景 「全球说」 Talkmate,是北京酷语时代教育科技有限公司(酷语科技)旗下产品,酷语科技是一家诞生于中国的语言技术公司,致力于为全球用户提供一个全新的多语言学习和社交网络平台 。 全球说是典型的快速发展初创企业,心怀理想,恰如其创始人温荣辉提到: 全球说希望带给用户的是文化、朋友和旅游的快乐,而不是让用户为了学习语言去学习语言。我们希望能把所有语言囊括进来,容纳世界各地的人。我们想成为一家「社会企业」。 丰满理想需要团队和 IT 系统的支撑,特别是全球说的用户群全球化特征, IT 支撑还是非常重要的。 OneAlert 也有幸和全球说运维负责人李云伟先生进行一次深入沟通。 面临挑战 全球说的 IT 应用主要是在线系统和移动 APP 为主。 Web 网站 移动 APP 调用 PHP 研发,提供相关 API 常见的中间件 MongoDB , Memcache 等 服务器规模: 20 台左右(随业务增长不断增加),分布式部署(国际服务器)。 使用流行的开源监控工具 Zabbix 。 全球说虽然作为初创公司,但是 IT 系统是五脏俱全,具备随着业务增长快速扩展的特性,同时运营支撑压力不小。 李云伟先生面临运维挑战是: 运维人员比较少的情况下如何在手机上能够快速获知当前 IT 告警,方便及时处理告警? 使用 Zabbix 的原有告警存在以下问题: 邮件通知需要搭建邮件服务

告警分析:如何帮助运维团队快速做出最佳决策?

天大地大妈咪最大 提交于 2019-11-26 14:56:01
「路漫漫其修远兮,吾将上下而求索」,「转身」不见得华丽,但我必须「转身」,不要安逸于现在的运维状况。 如果你运维一线人员,是否会遇到以下情况: 公司所有的服务器告警消息会塞满自己的整个邮箱,如果公司的运维团队有几个人到几十人不等,当你处理邮箱中的告警消息的时候,处理一半会发现问题已经解决了,这个现象很常见,会导致工作效率的下降。改善的方法有很多,比如团队内部多一些沟通,然而沟通的成本也是非常高的。解决问题应该从源头出发,治标不治本的方法还是应该适当采取。也许你在创业团队工作,团队中只有一个人,但是也希望你能读完本篇文章,等团队壮大之后也会有帮助! 单一的告警通知方式会麻木运维同学的工作思维,一天 24 小时接收的都是邮件或者短信的告警通知。我们更希望白天工作时间使用邮件、微信、APP 等轻量级的通知方式,晚上休息时间使用短信、电话等偏重的通知方式。这样不仅白天能够提高工作效率,而且能够晚上好好休息,不用担心告警疏漏。如果能有排班通知,那么就真正能「睡个好觉」了。 如果你是运维 Team Leader,是否会遇到以下情况: 如果你是团队的管理人员,是否会遇到以下情况: 团队一直在解决故障,但对系统性能没有整体的把握;你对团队、成员的工作量,工作效率没有全面的了解。你肯定不希望这样管理你的团队,不希望团队重复解决某些事情,更不希望因为这些问题让团队士气低落,觉得工作没有干劲。

中小企业 IT 运维福利:快速构建 on-call 机制

房东的猫 提交于 2019-11-26 14:55:30
大多 IT 运营支撑同学都有过深夜业务应用突然故障的经历,监控系统准确告警,但是白天筋疲力尽的运维同学在熟睡中,经常会遗漏告警提醒;往往是接到主管电话(用户投诉了)才处理。有什么办法解决该问题呢?大多人是这么做的: 建立7x24小时的一线值班团队,搞一个监控室,值班人员随时警备,负责告警响应和协调调度工作。一年至少花费:4人(2班)x15万/年=60万/年,也就土豪公司的可以搞搞,中小型公司肿么办? 我们部分赞同该思路: 建立7x24小时的 on-call 机制,随时响应解决,通过团队协作的机制来进行保障。 但在具体的方法和形式上,需要一个好的工具是可以支撑起7x24小时的 on-call 团队,重点之一是: 有效的告警通知,而且是通知必达(如主管电话)。 ##如何通知必达? OneAlert 之前已经支持了微信、短信、邮件、移动APP、页面级提醒,新版4.1.2.0新增电话通知,再也不怕深夜故障啦。 这次优化包括2部分: 新增电话提醒,智能语音播报告警内容,即使是深夜,你也能够及时唤醒,第一时间处理故障。避免手机网络不稳定引起的微信、邮件、移动 APP 不及时现象,基本上电话是不可抗拒的,除非关机。当然如果关机的话(7x24不允许关机),OneAlert 的升级分派策略会同时通知其他同学。 阶梯式延迟提醒通知。告警事件过来后,多个渠道可以延迟的方式通知

Mysql备份和恢复策略

守給你的承諾、 提交于 2019-11-26 12:26:38
在数据库表丢失或损坏的情况下,备份你的数据库是很重要的。如果发生系统崩溃,你肯定想能够将你的表尽可能丢失最少的数据恢复到崩溃发生时的状态。本文主要对MyISAM表做备份恢复。 备份策略一:直接拷贝数据库文件(不推荐) 备份策略二:使用mysqlhotcopy备份数据库(完全备份,适合小型数据库备份) 备份策略三:使用mysqldump备份数据库(完全+增量备份,适合中型数据库备份) 备份策略四:使用主从复制机制(replication)(实现数据库实时备份) 脚本下载地址:点击下载脚本 备份策略一、直接拷贝数据库文件 直接拷贝数据文件最为直接、快速、方便,但缺点是基本上不能实现增量备份。为了保证数据的一致性,需要在备份文件前,执行以下 SQL 语句: FLUSH TABLES WITH READ LOCK; 也就是把内存中的数据都刷新到磁盘中,同时锁定数据表,以保证拷贝过程中不会有新的数据写入。这种方法备份出来的数据恢复也很简单,直接拷贝回原来的数据库目录下即可。 备份策略二、使用mysqlhotcopy备份数据库 mysqlhotcopy 是一个 PERL 程序,最初由Tim Bunce编写。它使用 LOCK TABLES、FLUSH TABLES 和 cp 或 scp 来快速备份数据库。它是备份数据库或单个表的最快的途径,但它只能运行在数据库文件(包括数据表定义文件、数据文件