我在网易云信是如何做运维的

xinghe0

　　先介绍下网易云信运维工程师的主要职责，包括但不限于软硬件部署、网络管理、应用代码维护、安全漏洞修复、容量规划、故障处理、性能优化等。
　　云信的运维工程师们很相信一个神圣的定律——墨菲定律：事情如果有变坏的可能，不管这种可能性有多小，它总会发生（Anything that can go wrong will go wrong）。根据墨菲定律的推论，任何一个环节都不是100%靠谱的。而对于云信这样的及时通讯云平台来说，核心功能保证99.99%的可靠性，也就是说，一年不可用时长要小于52分钟。因此容灾是必不可少的，需要把容灾做到方方面面。
　　首先，硬件资源都是冗余的，主要包括以下几点：

• 服务器：双电源，双网卡bonding，系统盘raid10
  
• 机柜：双电路接入，电源容量充足
  
• 交换机：接入交换机堆叠并且单个交换机网卡bonding
  
• 网络：核心路由器/核心交换机冗余
  
• IDC：到各ISP的光纤要大于等于两条
  
• 运维人员：应用运维、系统运维、DBA所有角色一主一备。
  

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

• 接入层：云信使用了ospf+nginx做为了前端接入集群的负载均衡，所有nginx机器配置统一，upstream配置里添加了到后端服务器（大于1个）的健康检查
  
• 应用层：各集群服务器无单点，并且保证服务器分布在不同机柜，不同交换机
  
• 中间件：hbase本身就是分布式系统，其他中间件云信也做了高可用改造
  
• 数据库：做为架构中最核心的一环，数据库的容灾设计也是最完善的。数据库支持主从同步，主库挂了之后，可以1分钟内自动切到从库，并且能够保证数据一致性
  

　　最后，你会问我要是IDC机房挂了怎么办？运维人员如何做到业务运行状况了如指掌？
　　这个时候，就需要一个强大、好用的监控系统了，监控是稳定性建设的基石；网易IM云使用网易自研的哨兵监控系统，意指向哨兵一样迅速发现并相应异常状态。我们使用哨兵做了以下几个维度的监控：
　　一、在监控完整性方面，自上而下做了业务监控、应用监控、基础监控，相关监控项类型如下

https://pic3.zhimg.com/v2-e16a06c48d6e7cf6a373228672c76c3e_b.png

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

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

• 监控数据采集、数据上报有效：数据采集失败、数据不能上报监控agent的监控采集器每天以报表形式发送到运维负责人，运维负责人进行修改
  
• 报警发送方式（短信、邮件等）、报警接收人有效：每天统计短信、邮件及其他渠道的报警发送量，有异常变化（突增或者为0）以报表通知到运维负责人修改
  
• 报警1分钟内到达：对自身发送器进行监控，消息堆积时及时处理解决
  

　　三、是哨兵的报警收敛功能。哨兵通过增加报警重试次数，集群报警合并等手段进行报警收敛，有效的避免了服务器数量级达到一定程度后，过多的报警会让人麻痹，进而忽略掉了真正有效的报警。
　　然而，虽然做了以上的工作来预防故障、快速发现故障，但故障的发生还是在所难免的，一个合适的故障处理流程能够有效的缩短故障处理时长。现在来看看云信的故障处理流程：

https://pic4.zhimg.com/v2-530511da2101f784cdb927fa91d4a14b_b.png

　　为了避免在遇到故障时，故障处理人员手忙脚乱，相关人员配合不到位，加长故障时长，会定期进行故障演练；验证业务容灾能力，监控报警是否可达，人员应急处理能力。
　　一个产品随着业务的日益复杂，应用系统会变的错综复杂。所以产品的运维标准化是必须的。有人会问，1个人运维10台服务器和运维1000台服务器，哪个更难一些？如果监控方式、部署方式无任何规律，1个人要支撑10台服务器就已经疲于应付；相反，如果所有的服务，都是同样的监控方式、部署方式，那么1个人运维1000台服务器，也是轻松愉快的。所以当IM云的服务器数量达到一定规模时，为了提高运维效率，解决运维管理混乱的难题，我们制定了线上运维规范，包括但不限于以下几个方面：

• 应用部署规范：一台机器只部署一个应用；规范文件与目录结构，我们所有应用代码都在不同服务器的同一目录下，降低由于文件数量众多带来的运维风险，保证生产服务环境的整洁
  
• 日志运维规范：对日志输出目录、命名、格式、分割和归档进行了规范性约束。应用相关的日志统一存放在当前应用目录结构下面的logs目录。能够方便而有效地进行应用服务的多维度监控、应用日志分析，以及提升故障发现率。
  
• 代码发布规范：为减少代码上线引发的事故，提高代码上线效率。代码有固定的发布窗口，发布前必须进行发布审核，并且有完善且可执行的回滚方案
  
• 监控和报警规范：云信所有应用包含基础监控和应用监控；以及云信自身的业务指标监控。报警内容清晰明确，报警接收人有效且保证在两人以上
  
• 账号和权限规范：系统管理员使用root权限；代码发布使用公共账号权限；普通开发人员使用个人账号权限，个人账号权限不能在服务器上执行除家目录之外的写操作
  

　　无专职运维团队的企业，有哪些替代方案可以提高开发运维效率？
　　为了减少运维管理的成本，一定要做应用部署的隔离，有运维团队的公司会选择传统的虚拟化技术（kvm，lxc）对物理机进行初始化，现在业界比较流行的是物理机上运行Docker容器对服务进行隔离；也可以选择直接使用云计算公司提供的服务器资源。服务器的账号权限配置，软件环境配置等配置管理可以使用puppet来管理；代码部署方面可以使用gitlab+pipeline替代方案；监控系统业界比较常用的是开源的zabbix；持续集成通常使用jenkins；自动化运维工具比较流行的是使用ansible；提高应用的故障容错能力可使用Netflix Hystrix。以上部分工具，网易目前也同样在使用，而且很好用；关于工具的使用方式，google有比较成熟的文档，大家可以按需调研学习。
　　最后必须说一句：一个可运维、方便运维的产品，开发同学的投入功不可没。