网易即时通讯云平台99.99%可靠性的运维经验谈

本文源自11月10日『高效开发运维』微信群的在线分享活动总结，转载请在文章开头注明来自『高效开发运维』公众号。加群学习请关注『高效开发运维』公众号，并点击菜单中的“加群学习”或直接回复“加群”。

一句话背景介绍：网易即时通讯云平台，即网易云信，是网易集16年IM经验打造的即时通讯云服务（PaaS）。

运维解决方案及最终效果

一: 怎样做到99.99%，确保稳定性

在网易云信，运维工程师的主要职责包括但不限于软硬件部署、网络管理、应用代码维护、安全漏洞修复、容量规划、故障处理、性能优化等。

网易云信作为即时通讯云平台，核心功能保证99.99%的可靠性，也就是说一年不可用时长要小于52分钟，为何做到？概括为两个方面：第一，我们的开发团队有很高的运维意识，在开发设计时就注重应用的可用性和扩展性；第二，我们的运维团队很懂开发，通过专业的运维能力帮助开发规避风险；运维和开发相互合作，打造了云信的稳定。下面我和大家一起分析下网易云信的稳定性保障策略。

运维工程师们很相信一个神圣的定律——墨菲定律（Anything that can go wrong will go wrong）。根据墨菲定律的推论，任何一个环节都不是100%靠谱的；因此容灾是必不可少的，需要把容灾做到方方面面。

首先，硬件资源都是冗余的，主要包括以下几点：

1)    服务器：双电源，双网卡bonding，系统盘raid10

2)    机柜：双电路接入，电源容量充足

3)    交换机：接入交换机堆叠并且单个交换机网卡bonding

4)    网络：核心路由器/核心交换机冗余

5)    IDC：到各ISP的光纤要大于等于两条

6)    运维人员：应用运维、系统运维、DBA所有角色一主一备。

其次，整个应用架构的容灾，主要包含以下几个层次：

1）接入层：云信使用了ospf+Nginx做为了前端接入集群的负载均衡，所有Nginx机器配置统一，upstream配置里添加了到后端服务器（大于1个）的健康检查。

2）应用层：各集群服务器无单点，并且保证服务器分布在不同机柜，不同交换机。

3）中间件：HBase本身就是分布式系统，其他中间件云信也做了高可用改造。

4）数据库：做为架构中最核心的一环，数据库的容灾设计也是最完善的。数据库支持主从同步，主库挂了之后，可以1分钟内自动切到从库，并且能够保证数据一致性。

最后，万一IDC机房挂了怎么办？

我们业务基建稳定，多机房多活架构，并且做到业务无感知。

做为运维人员，如何可以做到业务运行状况了如指掌？这个时候，就需要一个强大、好用的监控系统了，监控是稳定性建设的基石；网易IM云使用网易自研的哨兵监控系统，意指向哨兵一样迅速发现并相应异常状态。我们使用哨兵做了以下几个维度的监控：

1）在监控完整性方面，自上而下做了业务监控、应用监控、基础监控，相关监控项类型如下 

如某业务指标的监控趋势图： 

2）在监控有效性方面，通过哨兵监控系统，报警有效性达到90%以上

• 监控数据采集、数据上报有效：数据采集失败、数据不能上报监控agent的监控采集器每天以报表形式发送到运维负责人，运维负责人进行修改

• 报警发送方式（短信、邮件等）、报警接收人有效：每天统计短信、邮件及其他渠道的报警发送量，有异常变化（突增或者为0）以报表通知到运维负责人修改

• 报警1分钟内到达：对自身发送器进行监控，消息堆积时及时处理解决

3）最后是哨兵的报警收敛功能。哨兵通过增加报警重试次数，集群报警合并等手段进行报警收敛，有效的避免了服务器数量级达到一定程度后，过多的报警会让人麻痹，进而忽略掉了真正有效的报警。

4）然而，虽然做了以上的工作来预防故障、快速发现故障，但故障的发生还是在所难免的，一个合适的故障处理流程能够有效的缩短故障处理时长。

网易云信的故障处理流程： 

为了避免在遇到故障时，故障处理人员手忙脚乱、相关人员配合不到位等原因造成的故障时长加长现象，我们会定期进行故障演练；验证业务容灾能力，监控报警是否可达，人员应急处理能力。

二：运维标准化，提升效率

下面谈一下我们产品的运维标准化之路。一个产品随着业务的日益复杂，应用系统会变的错综复杂。有人会问，1个人运维10台服务器和运维1000台服务器，哪个更难一些？如果监控方式、部署方式无任何规律，1个人要支撑10台服务器就已经疲于应付；相反，如果所有的服务，都是同样的监控方式、部署方式，那么1个人运维1000台服务器，也是轻松愉快的。所以当IM云的服务器数量达到一定规模时，为了提高运维效率，解决运维管理混乱的难题，我们制定了线上运维规范，包括但不限于以下几个方面：

1) 应用部署规范：一台机器只部署一个应用；规范文件与目录结构，我们所有应用代码都在不同服务器的同一目录下，降低由于文件数量众多带来的运维风险，保证生产服务环境的整洁。

2）日志运维规范：对日志输出目录、命名、格式、分割和归档进行了规范性约束。应用相关的日志统一存放在当前应用目录结构下面的logs目录。能够方便而有效地进行应用服务的多维度监控、应用日志分析，以及提升故障发现率。

3）代码发布规范：为减少代码上线引发的事故，提高代码上线效率。代码有固定的发布窗口，发布前必须进行发布审核，并且有完善且可执行的回滚方案。

4）监控和报警规范：云信所有应用包含基础监控和应用监控；以及云信自身的业务指标监控。报警内容清晰明确，报警接收人有效且保证在两人以上。

5）账号和权限规范：系统管理员使用root权限；代码发布使用公共账号权限；普通开发人员使用个人账号权限，个人账号权限不能在服务器上执行除家目录之外的写操作。

普适的运维方案和推荐工具

普通研发团队有什么方案和工具能帮助开发者达到大厂80%的效果？

为了减少运维管理的成本，一定要做应用部署的隔离，有运维团队的公司会选择传统的虚拟化技术（KVM，LXC）对物理机进行初始化，现在业界比较流行的是物理机上运行Docker容器对服务进行隔离；也可以选择直接使用云计算公司提供的服务器资源。

服务器的账号权限配置，软件环境配置等配置管理可以使用Puppet来管理；

代码部署方面可以使用GitLab+pipeline替代方案；

监控系统业界比较常用的是开源的Zabbix；

持续集成通常使用Jenkins；

自动化运维工具比较流行的是使用Ansible；

提高应用的故障容错能力可使用Netflix Hystrix。

以上部分工具，网易目前也同样在使用，而且很好用；关于工具的使用方式，Google有比较成熟的文档，大家可以按需调研学习。

系统设计及实现须顾及后期运维

以上是云信部分运维工作的介绍，但需要特别提一句，一个可运维、方便运维的产品，开发同学的投入功不可没。

1. 良好的系统架构是顺利开展运维工作的前提

在做系统架构设计时需要充分考虑功能模块的耦合性，尽量做到业务功能的独立解耦，降低互相之间的依赖；最差的情况就是所有的服务功能集中在一个进程中，一个挂，全部挂，一个升级全部受影响，这种系统设计对运维工作来说就是灾难；做好功能模块的划分和隔离，可以降低故障的影响范围，在升级等日常运维工作中也可以做更好的规划；

 2. 架构设计时将HA作为必须满足的非功能性指标

任何一个系统都会存在故障的可能，程序猿写的代码即时再好也有出bug的时候，即时程序不出bug，也还是逃不过机器宕机后者断电断网等各种意外情况的发生；所以设计者需要善于找到系统中存在的单点，并解决这些单点；高可用的特性并不是说要求程序一定不能挂，而是说从架构上允许故障的发生，任何一个节点的故障只能影响系统的整体处理性能，但是不会造成业务不可用；具体来说，如果是Web类的应用，可以使用Nginx等反向代理工具来搭建多个后端的业务集群，并在出口上做Keepalived等高可用的方案，对于一般的应用，设计时需要保证多实例可同时服务，多实例功能相互对等，任何一个实例的停服，其业务请求可以被其他实例来分担；做好了HA架构，我们在运维工作时才能更加从容，因为当运维报警发生时，我们知道当前业务处理能力虽然下降了，但是整个业务并不是不可用的状态，对用户来说不会产生直接的影响，运维人员可以从容得恢复故障节点即可；同时良好的HA架构也有助于业务扩张时的增强系统扩展性； 

3. 业务系统给运维系统提供更加友好的接口

运维平台的一个重要工作是从业务系统中提取到准确的指标，并针对这些指标来做线上的监控和预警；更加了解业务系统的还是开发人员，而非运维人员，所以开发人员需要在设计功能时同时兼顾到运维的需求，充分设计哪些指标需要被暴露出来，常见的比如当前系统的TPS(每秒的处理能力)，MRT(平均响应时间），系统的能力上限等，再结合如JVM内存使用情况，GC情况等基础数据，运维平台就能做出更加合理的监控支持，有了这些监控数据之后再制定更加科学的预警，可以在故障实际发生之前就做出预警（比如TPS达到系统容量的80%了），让运维人员提前做出扩容等应对，而不是等到功能不可用了才报警；从技术实现上来说，业务系统向外暴露接口的方式就非常多了，比如Java程序可以通过JMX来实现，通用的进程可以使用隐藏的Http接口等方式来实现；如果运维平台使用的是Ganglia等开源平台，也可以使用对应的客户端Agent来向运维平台暴露数据；

4. 规范的日志输出

很多开发者在实现业务系统的时候往往会忽略日志的作用，或者只把日志当做偶尔查查问问的工具，日志的输出内容往往是只有人来读取的非格式化内容；其实除了定位问题之外，日志还可以帮助我们做更多的事情，我们可以设计一个程序友好的日志格式，比如输出JSON格式的日志来记录每个业务请求的执行情况，如请求参数，处理时间和响应码，失败信息等；有了规范的日志之后，可以通过脚本的方式将日志中的信息提取成指标输入到运维平台中，可以对业务系统当前处理的成功率，响应时间等做更加细粒度监控和报警；

5. 善于利用功能测试框架

很多公司对开发人员的代码质量要求都很高，会要求在QA测试之前做到单元测试等工作，有些QA部门也会利用一些标准化的工具对线上流程做回归测试，比如Junit或者TestNG等；其实我们也可以充分利用这些资源来做线上的运维监控；我们退一万步来说，如果一个系统没有任何运维预警，那么如果线上发现问题的会是谁？这一定是用户，那么能不能有一个机器人用户来帮我们提前发现问题呢？这里我们就可以利用功能测试的成果了，将用作线上回归的TestNG代码用程序自动化的方式定期执行起来，并解析执行的结果，如果回归测试失败就立刻发报警出来，这种看起来很土的方法在实际操作中。

群友&嘉宾的问答实录

Q：非常感谢两位专家的分享。请问单元测试网易云信是做到什么程度，全部采用还是部分采用呢？        

A：单元测试对于保证线上服务的质量是非常重要的，我们对开发人员的要求是整体单元测试的代码覆盖率要达到80%以上，核心模块的覆盖率要100%，在每个版本的迭代中，都需要使用单元测试对老功能做回归。

Q：云信运维人员是否还会负责其他产品？比如同时负责云笔记、云信等B2C产品，又负责云笔记、云信大数据平台建设？ 

A：云信运维人员同时也会负责其他运维产品，比如我在负责网易云信的同时也会负责网易七鱼，我的同事在负责网易云音乐的同时会负责网易新闻客户端；虽然是不同产品，但架构大体是相同的，这个时候就体现出了运维标准化建设的重要性，否则运维成本将会很高

Q：代码发布频率达到一天一次？几天一次？还是一天多次？

A：网易云信的发布频率是一月一次，bug修复除外；发布次数主要看业务类型吧，比如金融类业务以稳定为主，发布频率较低；电商类业务会配合较多的运营活动，发布频率比较高；我认为不管什么业务，合理发布窗口和完善的发布回滚流程都可以有效的降低故障的发生

Q：请问两位老师 1.「通用的进程可以使用隐藏的Http接口等方式来实现」这个怎么理解？ 2.能简单说说发布过程及回滚方案是怎么样吗？ 谢谢。        

A： 1. 比如你的应用是一个web类的应用，前端肯定会有nginx之类的接口来控制可访问的接口范围，你可以把暴露监控指标的请求路径在nginx上做控制，对外不可见，仅对内网环境开放；这类接口对外部用户来说就是“隐藏”的；如果不是web类的应用，可以在进程中内置jetty等小型的web容器，来暴露一些控制和采集指标的接口； 2. 发布的过程需要制定详细的发布计划，控制涉及到的模块范围，做好回滚方案，这些也需要QA部门全程参与，因为QA需要针对升级的内容制定线上回归的用例；在升级操作时，需要做好线上业务的流量切换，对web类应用也可以在nginx等前端代理上有意识地切断心跳检查，使线上流量从即将升级的目标服务器上切走，再对这个目标节点升级，这种方式可以做到线上升级不停服的效果；

Q：raid10 /raid 5 如何进行选择？

A：网易目前一般用raid10，选择raid的类型主要从恢复成本、性能、经济成本几方面来考虑；从产品运维的角度来看，我觉得应用本身做好容灾，重要数据定期备份比纠结raid的选型更重要

Q：报警指标，频次，对象的选择，如何把握正确的度

A：我认为报警的完整性、有效性、及时性缺一不可，报警的频率取决于被添加应用的重要程度，比如云信的发消息最重要，那我认为1分钟发一次报警，并且为了防止漏接，使用电话报警是很有必要的；而对于一些后台应用，我认为频率三分钟1次，甚至更低也ok

Q：网易云信是使用了Docker吗？如果是的话，什么时候开始的，效率提升了多少？        

A：网易云旗下的IaaS产品叫蜂巢，就是Docker类云服务。这个服务在网易内部产品中已经得到了很广泛的应用，云信业务中也使用了蜂巢来承载一些业务功能；带来的好处就是通过节点复制等方式能快速实现业务扩容，提升运维的便捷性；另一个明显的好处就是极大提高了硬件资源的利用率，这也是云计算带来的最大的好处，我想大家对此都有相当的认识了，不用细说了；至于你说的效率提升了多少，很多是表现在人力的解放上面；比如原来我们运维人员需要花5个小时做的部署工作，现在也许半个小时就可以搞定了；

Q：对于错误解决方面，能否实现简单的自动解决模块，尽可能的减少人为动作了？

A：网易云信目前采用的方式是和监控系统联动来解决，当监控采集器触发报警表达式的时候，会调自动化工具来进行自动化处理，如果自动化处理失败，才会发报警出来，如删除日志等，具体看自动化工具是否强大

Q：贵公司在运维开发方面，是怎样实践的？ 比如哨兵监控系统，运维人员参与了多少？

A：我了解到的业界互联网公司的监控系统最初全部都是运维人员开发的，最起码也是运维人员参与设计的。因为监控系统最主要的使用者是运维人员，要想用的爽，还是要自己动手的。

Q：对于传统的系统，有cs架构和IIS 的web监控有什么建议吗？

A：对于cs的架构的系统，s端的监控是重点，监控的方法其实和bs的server端类似，而对于c端的监控，一般可以通过心跳的方式来实现，在s端检查c端心跳超时，再上报预警系统；IIS的web和其他的web也类似，基础的指标，如内存占用，cpu使用率等可以从操作系统层面来做采集和监控，而业务层的指标也可以使用对外暴露接口或者暴露日志来采集监控数据；

关于两位嘉宾

田浩然，网易云信运维负责人

2015年加入网易，参与网易杭研院核心产品监控方案的设计，监控有效性以及监控完整性的提高；参与网易云容灾架构设计；现作为云信运维负责人负责稳定性保障、成本控制、运维效率提升工作。2011年时就职阿里巴巴，负责阿里巴巴国际业务的运维工作，参与双十一活动的运维保障；参与国际业务异地多活架构设计。

周梁伟 网易云信首席架构师

2011年加入网易，涉猎范围包括：通用服务器后端开发，大数据统计分析，IM系统设计开发等方面。先后参与云存储系统开发；通用日志采集平台Datastream的设计和研发；通用网站数据分析平台；易信产品的服务器研发，易信WEB版长连接服务器；HBase集群搭建和运维；目前作为云信系统首席架构师负责平台的架构设计和服务器研发团队。

网易云信

云信是网易公司集16年IM经验打造的即时通讯云服务（PaaS），开发者通过集成客户端SDK和云端OPEN API，即可快速实现强大的IM功能，作为PaaS服务模式的网易云信全面支持Android、iOS、Web、PC等多平台。

还提供了高级通讯功能，包括实时音视频、互动直播、教学白板、专线电话、短信、专属云在内的独家功能以及更多其他服务。网易云信满足包括游戏、协同办公、在线医疗、在线客服、在线教育、娱乐、咨询、生活服务、物流、旅游、金融等各行业各种产品的即时通讯服务需求。

感谢为本次群分享做准备的网易云信两位嘉宾和一位工作人员，三人在会议室忙碌到晚上10点方离开返家。

同样感谢在双十一前夕忍住购物欲坚持学习、提问互动的群友。

本期群分享嘉宾周梁伟将在2016年12月2日-3日，ArchSummit全球架构师峰会进行专题演讲 :《如何支持过千万级高并发消息量——网易IM云服务架构设计与实践》。另外ArchSummit大会的运维专题信息如下：

点击阅读全文，移步ArchSummit 2016北京站官网。