网易云信运维工程师的主要职责,包括但不限于软硬件部署、网络管理、应用代码维护、安全漏洞修复、容量规划、故障处理、性能优化等。 网易的运维工程师们很相信一个神圣的定律——墨菲定律:事情如果有变坏的可能,不管这种可能性有多小,它总会发生( Anything that can go wrong will go wrong )。根据墨菲定律的推论,任何一个环节都不是 100%靠谱的。而对于云信这样的及时通讯云平台来说,核心功能保证 99.99%的可靠性,也就是说,一年不可用时长要小于 52 分钟。因此容灾是必不可少的,需要把容灾做到方方面面。
首先,硬件资源都是冗余的,主要包括以下几点:
其次,整个应用架构的容灾,主要包含以下几个层次:
最后, IDC 机房挂了怎么办?运维人员如何对业务运行了如指掌? 这个时候,就需要一个强大、好用的监控系统了,监控是稳定性建设的基石;网易 IM 云使用网易自研的哨兵监控系统,意指向哨兵一样迅速发现并相应异常状态。我们使用哨兵做了以下几个维度的监控:
首先,在监控完整性方面,自上而下做了业务监控、应用监控、基础监控,相关监控项类型如下:
最后是哨兵的报警收敛功能。哨兵通过增加报警重试次数,集群报警合并等手段进行报警收敛,有效的避免了服务器数量级达到一定程度后,过多的报警会让人麻痹,进而忽略掉了真正有效的报警。
然而,虽然做了以上的工作来预防故障、快速发现故障,但故障的发生还是在所难免的,一个合适的故障处理流程能够有效的缩短故障处理时长。现在来看看云信的故障处理流程:
为了避免在遇到故障时,故障处理人员手忙脚乱,相关人员配合不到位,加长故障时长,会定期进行故障演练;验证业务容灾能力,监控报警是否可达,人员应急处理能力。
一个产品随着业务的日益复杂,应用系统会变的错综复杂。所以产品的运维标准化是必须的。有人会问, 1 个人运维 10 台服务器和运维 1000 台服务器,哪个更难一些?如果监控方式、部署方式无任何规律, 1 个人要支撑 10 台服务器就已经疲于应付;相反,如果所有的服务,都是同样的监控方式、部署方式,那么 1 个人运维 1000 台服务器,也是轻松愉快的。所以当 IM 云的服务器数量达到一定规模时,为了提高运维效率,解决运维管理混乱的难题,我们制定了线上运维规范,包括但不限于以下几个方面:
无专职运维团队的企业,如何提高开发运维效率? 为了减少运维管理的成本,一定要做应用部署的隔离,有运维团队的公司会选择传统的虚拟化技术( kvm , lxc )对物理机进行初始化,现在业界比较流行的是物理机上运行 Docker 容器对服务进行隔离;也可以选择直接使用云计算公司提供的服务器资源。服务器的账号权限配置,软件环境配置等配置管理可以使用 puppet 来管理;代码部署方面可以使用 gitlab+pipeline 替代方案;监控系统业界比较常用的是开源的 zabbix ;持续集成通常使用 jenkins ;自动化运维工具比较流行的是使用 ansible ;提高应用的故障容错能力可使用 Netflix Hystrix 。 以上部分工具,网易目前也同样在使用,而且很好用;关于工具的使用方式, google 有比较成熟的文档,大家可以按需调研学习。 最后必须说一句:一个可运维、方便运维的产品,开发同学的投入功不可没。
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.