中华万年历SR演进

image

如上图,2亿华人都在使用的日历-中华万年历,给大家提供了实用、方便的服务。
那又是怎样的技术团队,在给我们中华万年历提供技术支撑服务了?
答案就是我们的后台技术中心团队,主要包括开发团队和SR团队。
在这里重点介绍下我们的SR团队的演进过程以及dev和ops的合作。

在互联网公司都有运维团队,我们的SR其实主要包括运维和安全。
SR=site reliability=system reliability + service reliability + speed reliability + security reliability
(系统可靠、服务可靠、响应速度可靠、安全可靠)
SR的基本职责是:
确保站点的可靠性、可用性、安全;
确保系统、服务能正常、平稳、不间断的运营;
确保响应速度,在出现故障时能及时响应和处理;
确保服务、代码的上线、变更是受控的、能够及时的持续交付;
确保系统架构中各层级的安全性,特别是数据安全;
确保容量规划的合理性,满足业务成长的需要,尽力提升网络质量,提升服务器等设备的可用性和利用率。

阶段一(2012) no ops

image
中华万年历里程碑版本(云同步版本)上线的时候,跟server端有关的主要的功能模块:数据云同步,天气,记事。
server端项目比较少,主要包括zhwnl、weather、marketing
devops(no ops、only dev)
idc托管、淘宝淘服务器组装
软路由vytta转发
手工wget war单台发布
nagios+cacti监控

阶段二(2012-2014) all in one

image
在中华万年历用户暴增的情况下,系统架构没有太多更新,但是需要维护的项目、服务器节点也相应增多;
当时只有一个运维,所有大多时间是花在基础平台的维护和优化,以及业务运维。 感谢两位当时短暂加入的小伙伴。
主要的工作如下:
基础运维:网络优化,idc、cdn建设,硬件选型购买,接入层优化
应用运维:nginx、tomcat、redis、mysql的配置和优化
平台运维:发布系统、批量配置
安全:入口iptables 邮件系统、虚拟化

阶段三(2014-2016)人肉运维

主要还是人肉运维 项目增多,系统架构越来越复杂,接入大数据各种组件、中间件服务、基础组件 新知识太多,疲于业务需求和学习,没有时间来升级运维平台; 同时我们也在认真考虑在人手不足的情况下,如何解脱自己,如何和开发更高效的协作。

阶段四(2016-now) SR

仅从如下两图可以看到,我们的项目越来越多,用的服务也越来越多,我们遇到的问题也越来越多,急需解决。
2016年初,我们找来了一位很给力的应届生小伙伴;
2017年初,我们又找来一位很给力的应届生小伙伴;
在我们的小伙伴熟悉我们的基础架构以及业务后,我们开始尝试做更多的事情。
image image

先说下我们遇到的问题: 1. 传统idc运维,时间、人力成本高、idc本身限制的问题
2. 节日提醒ddos攻击问题
3. 故障预警、处理不及时、事故频发的问题
4. 团队建设的问题
5. devops的问题

传统idc运维,时间、人力成本高、idc本身限制的问题

节日提醒ddos攻击问题

以上两个问题有一定关联性,放在一起介绍下。

建设混合云数据中心

在最初公有云不是很火的时候,我们也是租用传统idc的机柜,自己买硬件设备,自己做虚拟化。
在这里我们遇到了一些问题: 最初选择的idc质量不佳,我们需要重新评估idc质量,选择更好的idc。
这时候你需要做一个工作,idc整体迁移到新的idc。
在2014年之前,我们花了接近半年时间,在保证我们线上所有服务不中断的情况下,把我们线上10多个项目,10多台物理服务器迁移到了最贵的idc,但是这种工作,会耗费大量的人力,时间。

但是紧接着,我们的产品和业务对我们提出了更高的要求,需要保证我们的app在我们节日提醒时候的可用率。
因为产品本身需求的原因,我们节日提醒时的带宽是平时的6倍左右,并发连接数是平时的25倍左右。 传统idc的带宽满足不了我们的扩容需求;在传统idc下,我们的系统架构,我们的费用预算也不能支撑这种级别的扩容需求,所以节日提醒的时候,我们带宽就会跑满,服务器负载也会暴增,服务可用率直线下降。

为了解决这些问题,在2016年前做了一些公有云的尝试后,在2016年,我们顺其自然地把所有服务迁移到了公有云上,建设了我们中华万年历的混合云数据中心。
混合云数据中心包括两部分:公有云和机柜托管区。
我们把原来自己的硬件服务器,放在了托管区。
公有云和托管区的网络是局域网可通信的,这样可以保证我们把计算节点放在公有云,把数据存储在自己托管区的服务器上。

自动扩容缩容平台

在Iaas支持带宽扩容、缩容,服务器按需计费的前提下,我们搭建了我们的自动化扩容缩容平台。
自动化扩容缩容平台两个核心组件:资源监控和自动扩容缩容。
资源监控主要是带宽和服务器负载,这些都可以通过监控中心api获得; 自动扩容缩容可以通过调用公有云的api来进行带宽和服务器的扩容缩容。
我们目前节日提醒的带宽一下子暴增到300M,并发连接数一下子暴增到140k,我们能保证和平时一样的可用率和响应时间。
节日提醒这个特殊场景的容量伸缩是我们已知的定时扩容缩容工作;在我们收到负载过高告警后,或者我们有一些临时扩容需求的时候,我们也提供了web化管理平台,可以很方便地扩容缩容。

同时,我们在客户端做了优化,把原来的10点集中访问,改成了10点前后10分钟左右分散访问。

同城双活
  1. 公有云同一可用区的不同数据中心,内网互通,比如我们的公有云有两个机房idc-b、idc-c;
  2. 我们的应用服务在上面的2个数据中心都会部署;
  3. 我们的数据存储(redis、mysql)如果把master部署idc-b,那么slave会部署在idc-c,保持数据同步;
  4. master-slave状态监控、master-slave自动切换(有确认机制)。

故障预警、处理不及时、事故频发的问题

故障不可怕,可怕的是你不能及时发现,及时恢复以及对故障不重视。针对这个问题,我们做了一下工作:
监控告警中心、事故管理平台、可用率保障小组。

监控告警中心

我们的监控中心包含了一下组件:

open-falcon:

这是我们监控告警的基础平台,所有服务器的基础指标监控,当然我们其他监控数据也会提交这里画图、告警。

应用进程监控:

我们有很多服务(nginx、tomcat、redis、mysql、大数据应用),我们有一个配置文件,上面记录所有主机上运行的应用、检测方法、异常处理方法;我们会把状态数据提交到open-falcon上展示和监控告警;同时会提交到数据库中存储,供我们的devops平台查询。

tomcat节点健康状态监控(我们的项目大部分是运行在tomcat上的java项目)

这里监控的不是进程也不是端口,这里是在内网直接通过curl tomcat node:port/url的方式来监控tomcat的上的java项目是否异常(因为有时候,tomcat 进程在,但是运行在上面的java项目异常了)

ELK

我们的ELK会收集nginx访问日志来统计分析和展示pv、uv等数据;
同时还会收集tomcat等错误日志,来告警和故障排查。

apm

这个主要是从公网不同的地方监测我们的url访问是否正常,来统计分析我们站点的可用率和响应时间。

链路追踪平台

基于设定的url,给每次访问打上一个traceId,我们把客户端提交上来的访问日志(http状态、响应时间、client的ip和运营商),nginx日志,tomcat日志提交到我们elastic,我们后端同事再统计分析展示在后台上;
我们在这个平台上,可以看到我们全国各地、不同运营商的client的真实访问情况;
也可以根据url,或者设备id来确定问题。

告警中心

open-falcon正常触发的告警我们会短信、邮件通知到处理人;白天一般看到就会处理了,不过晚上就不一定了,大家在睡大觉,有可能听不到告警短信,但是我们晚上没有专门的监控组,所以我们升级了告警机制;

告警升级机制:
加入电话语音告警;
在我们的open-falcon上会有所有未恢复的告警,
第一次告警我们会发到我们的ops组;
30min内没有处理,告警会发到CTO;
60min内没有处理,告警会发到CEO。

监控值班组:
建立晚上、节假日值班机制;
给我们运维同事配备了专门的值班电话,保证值班时段,电话畅通不静音。

事故管理平台

事故记录、总结;
事不过三。

可用率保障小组

我们的可用率kpi是ops和dev共同背的;
可用率kpi奖罚机制:
我们针对项目设定一个kpi对应的可用率;
同时设定一个奖励机制可用率;
超过kpi,触发了奖励机制可用率,我们有额外的奖励给到负责这个项目的可用率保障小组成员,跟kpi一样,按季度算。

应急小组

这里会包括各部门负责人,一起应对突发状况。

团队建设

  1. 我们SR和dev同属后台技术中心,共同负责项目的上线、发布、和可用性保障;
  2. 我们SR吸收有潜力、主动的应届生;
  3. 明确工作目标,突显工作价值;
  4. 保证日常工作和新技术的时间比。

devops的问题

上面简单介绍了下团队建设,主要是表达我们的dev和ops是一个部门;
但是我们还不是一个devops组织。
我们在落地devops的过程遇到了很多阻力:
一个最大的问题,就是dev不太懂ops,ops不太懂开发;
第二个问题,dev关注项目的上线变更速度,ops关注项目上线后的稳定性。

第二个问题,我们把dev、ops放到同一部门,共同背负kpi,共同实现价值。
第一个问题,我们整个技术后端,周期性的进行技术分享,共同学习,共同进步;
同时针对第一个问题我们在持续完善我们的devops平台,参考高效运维的devops全开源端到端部署流水线。

堡垒机

授权dev更简单、更安全的登入服务器进行一些非常规操作。

CMDB

开发自己的CMDB管理平台,并提供api给我们其他系统(ci、cd、job调度、批量配置中心等)

ci、cd持续构建、交付平台

我们用jekins搭建了ci持续构建平台,并连接了我们cd持续部署平台; dev可以不必等待ops来部署,dev可以自行发布到测试环境,发布到预发布环境、灰度发布、生产环境、回滚版本、重启指定服务、查看发布日志;
当然我们做了权限控制,保证必须发布到预发布通过后,才能发布到生产环境,同时发布到生产环境需要运维确认。

项目管理平台
  1. 项目配置中心:
    基于项目的配置中心,可以看到该项目的接入LB ip、nginx节点、tomcat节点、redis节点、mysql节点,dev同事可以很清晰地看到该项目对应的各应用节点;
    基于CMDB的nginx、tomcat等配置文件批量配置。
  2. 项目健康状态展示:
    上文提到的应用进程监控会提交健康状态到数据库,这里会去获取这些状态数据并在前台染色,健康标绿,故障标红
  3. 对接到监控平台,可以访问到具体的监控数据。
任务调度平台

我们把一些常用的功能模块化,比如我们的发布脚本、重启脚本、应用进程监控脚本等等;
在上面我们可以集中管理我们crontab定时任务;
也可以给不同的组别,授权可以执行的jobs。

最终阶段 no ops

不忘初心,我们最终的目标是回归到 no ops,我们在devops的路上。

作者介绍

Freed,随身云运维经理。从0到1创立了随身云运维团队,负责中华万年历、微历、快马小报等的运维、系统保障等工作。

微鲤技术团队

长期求Java研发、运维开发、数据挖掘工程师,可实习,简历发至hang@weli.cn。微鲤技术团队承担了中华万年历、微鲤看看、微历、快马小报高达3亿用户的产品研发工作,并构建了完备的大数据平台、基础研发框架、基础运维设施。践行数据驱动理念,相信技术改变世界。