V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
neteaseim
V2EX  ›  推广

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

  •  
  •   neteaseim · 2016-12-02 10:28:44 +08:00 · 2553 次点击
    这是一个创建于 2905 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

    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 云使用网易自研的哨兵监控系统,意指向哨兵一样迅速发现并相应异常状态。我们使用哨兵做了以下几个维度的监控:

    首先,在监控完整性方面,自上而下做了业务监控、应用监控、基础监控,相关监控项类型如下:  bg2.jpg 如某业务指标的监控趋势图  bg2.jpg 其次,在监控有效性方面,通过哨兵监控系统,报警有效性达到 90%以上

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

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

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

    为了避免在遇到故障时,故障处理人员手忙脚乱,相关人员配合不到位,加长故障时长,会定期进行故障演练;验证业务容灾能力,监控报警是否可达,人员应急处理能力。

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

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

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

    目前尚无回复
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1911 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 16:35 · PVG 00:35 · LAX 08:35 · JFK 11:35
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.