运维技术干货：不仅是 Linux 运维最佳实践

本文由开源中国（OSChina）根据”第132期高手问答“整理而成，感谢开源中国提供了《Linux运维最佳实践》作者与读者互动交流的机会。

本文原文地址是 https://my.oschina.net/osccreate/blog/791601 （点击尾部阅读原文前往）

摘要: 盛大游戏资深运维专家带你深度探究 Linux 运维最佳实践。

我们面对的是一个不断变化的世界，业务需求在变，技术架构在变，开源工具与商业系统异构部署，新工具和技术概念层出不穷，唯有一套科学的技术方法论才能应对这些变化。很多时候，我们在面对新的问题时，会束手无措。因此，在 OSC 第 132 期高手问答中，我们策划了“Linux 运维最佳实践”的主题，并邀请了@xufengnju（胥峰）作为高手嘉宾。

@xufengnju（胥峰），资深运维专家，有 10 年运维经验，在业界颇具威望和影响力。也是盛大游戏高级研究员，2006 年毕业于南京大学，2011 年加入盛大游戏，工作至今，曾参与盛大游戏多款大型端游和手游的上线运维，主导运维自动化平台的功能设计和实施。拥有工信部认证高级信息系统项目管理师资格。

自动化运维在近几年一直都是很火热的话题，技术也一直在进步，因此对于技术人员来说，最重要的思维上、思想上的适应与转变。毕竟技术不是运维的终极追求，思想才是运维人员应该毕生修炼的目标！本次高手问答的高手嘉宾对运维服务体系有着深度的思考，因此问答中产生的内容也是十分有质量。

本文从多个角度整理了与运维相关的内容，包括工具的选择、运维中遇到的问题、自动化运维相关等等。

一、工欲善其事必先利其器，如何选择工具？

1、对服务器安全和监控，可以推荐一些开源工具吗？监控好像也就 nagios, cacti, zabbix，还有其他可以推荐的吗？安全方面如何监控？

监控工具各有侧重点，zabbix 同时支持 snmp 和自己的 agent，也支持自定义模板，在大部分场景下都是不错的选择。

另外，不要把 zabbix 视为只能监控服务器信息，通过自定义模板，也可以监控业务层面的指标。安全监控分为主动检测，如 Tenable Nessus，以及 IDS、IPS。

2、Linux 运维中，服务器版本都用什么版本？CentOS 5 还是 CentOS 6、Ubuntu？为什么选择这个版本？有做哪些测试？

目前我们以 CentOS6.X 为主。不同 Linux 分支各有特点，比如 Ubuntu 新版本发布较快，如果追求内核版本升级速度的话，可以考虑。CentOS 一直是我们的主要 Linux 发行版，主要是考虑到它的稳定性以及熟悉程度最高。

3、对于使用缓存有什么推荐吗？一般就 Redis, Codis。还有那些比较好用的开源软件？

对于类似 session-id 这样的可以非持久存储的数据，可以考虑 memcached，使用一致性哈希算法分布式存储。

4、做自动化发布，除了 Jenkins 持续集成工具，还有那些好用的工具呢？

目前我所知道的，一般都是 Hudson 或者 Jenkins，后者是前者分支出来的。这些工具都有丰富的插件，灵活使用这些插件是关键所在。

5、问个 MySQL 问题，三个版本（MySQL（官方版本）、Percona Server 、MariaDB）您建议使用哪个版本，原因是？

我们团队一般使用的是官方版本。主要是考虑到支持和生态。

6、服务器日志收集和分析有什么好工具推荐吗？ELK 貌似有点复杂，不太会用，有其他的推荐么？

ELK 确实是目前使用比较广泛的日志收集和分析的工具。虽然有些学习成本，但还是值得去研究和尝试的。

7、书里有开源出一些工具和脚本吗，哪里可以下载到？

书上的脚本我正在整理，其中一部分通过 git 可以下载 https://github.com/xufengnju/books.git。

8、请问你们现在运维都是基于 Ansible 吗？我们之前都是用 chef puppt 来管理。最近感觉 Ansible 很火，还没实践用过，请问这个用起来差别大吗？

请问你运维有实践过 IaaS 平台的吗，有没有一些经验交流？

1、各种不同的批量管理工具各具特点，根据自己的熟悉程度和实际业务需要选择一个完全掌握即可

2、目前 IaaS 平台是自研的，基于 KVM

二、绝知此事要躬行，运维中遇到问题？

1、LVS 和 HAPROXY 后端服务器规模可以到什么程度，比如有多少个应用，多少台后端服务器？

这个取决于应用的类型，在实际的业务场景下，需要关注 LVS 等负载均衡器本身的连接数、PPS 数据以及延迟。如果后端吞吐量比较大，可以考虑 LVS 的 DR 模式。一般情况下，负载均衡器不太会成为瓶颈。

负载均衡器本身的连接数、PPS 数据以及延迟如何进行计算和统计？

通过开源的 Zabbix 模板或者自定义模板，这些都不难实现。

有没有相关的命令集进行统计，或者详细的统计实例？

针对 HAProxy 建议参考咱们书中 P76 页最佳实践 29 HAProxy 监控的内容。Zabbix 模板技术，建议参考下咱们书中第 12 章的内容。可以使用的命令包括 ipvsadm，netstat 等。

2、对于涉及多个平台（Unix, Linux, Windows）的统一管理（认证，配置，服务）有什么好的解决方案或者思路么？

先说下认证这一块吧。Unix、Linux 都支持 OpenLDAP 认证，可以考虑，这个和 Windows 下的 AD 是兼容的。配置和服务可以考虑下开源的通用产品，比如 Ansible 或者 Salt。目前我们用的自研系统，思路和 Ansible 类似。

3、如何监控服务，业务运行状态监控你是怎么做的？

我们的监控系统是自研的，对游戏来说，很重要的一个业务指标是在线人数，它是通过监控系统周期性轮询游戏服务器来进行收集和绘制图表的。

4、你们是如何批量管理各个业务模块的机器系统及配置的。我们目录使用 Ansible 使用批量命令和脚本，业务上使用上线平台 SVN 管理业务程序及配置。是否开发了 CMDB 平台？

我们批量管理服务器的方式是 ssh，思路和 Ansible 类似。CMDB 提供基础数据的管理，是自研的。

5、请问有使用过流量镜像吗？就是把线上的流量镜像一份，引到测试环境，用真实的用户数据测试，想了解下从 0 开始实施的过程。

关于流量镜像的原理，可以参考《Linux 运维最佳实践》第 15 章中网卡混杂模式和 RawSocket 技术。看了这一部分后，你应该可以自己写一套。我没有亲自实践过，你可以自己关注下 tcpcopy 这个项目。

6、CentOS 6 要如何做系统和网络优化？/etc/sysctl.conf 中的这个参数

net.ipv4.tcp_max_tw_buckets = 6000

要如何设置，是越多越好吗？设置成 16000？

net.ipv4.tcp_max_tw_buckets = 16000

对于系统优化来说，要有针对性。tcp_max_tw_buckets 针对的是 time wait bucket，如系统中 timewait 状态较多，可以考虑 net.ipv4.tcp_tw_reuse 和 net.ipv4.tcp_tw_recycle 这 2 个值调整。另外，如果使用长连接对于减少该状态的连接数有效。

7、如果有 100 多台服务器，大部分都是在提供业务的服务器，如何升级呢？除了停机维护，现在有什么比较好的解决方案吗？

如果本身业务切分比较好，例如采用无状态的微服务等架构，可以通过前端负载均衡器进行灰度升级。如果应用做的不好，只有单台的这种，或者集中数据库，就比较麻烦了。

8、LVS 和 HAPROXY 分别能支持多少类似 FARM 的概念？

你说的 FARM 应该是某硬件负载均衡设备的专有名词，应该是负载均衡组的概念。在 LVS 和 HAProxy 里面，负载均衡组的数量上没有硬限制，但实践中一般不会配置太多，因为这涉及到维护成本以及 HA 环境下主备切换时的开销。

9、系统是 CentOS release 6.5 (Final)， 系统没有自动回收内存，16G，我自己写了个 Shell 脚本，每次执行判断小于 1G 的时候回收内存

可以关注下 sysctl 中 swap 以及 swappiness 的一些配置

10. 请问如果是有很多 ECS/VPS，系统一般是 CentOS。目前很多堡垒机也有类似的 SSH 同步密钥下发命令等功能，但是如果还有 Win的堡垒机支持很少。有别的开源工具或者办法来混合管理所有的 Linux, Windows 机器吗？ 

在我的这个演讲里面讲到了异构系统的批量管理方法，你可以参考下。

http://www.build.net/greatops/453250.html。另外，你可以参考下 Ansible 或者 salt。

三、自动化运维相关，工程师思维？

1、可以说下什么是自动化运维，如何才算服务器做了自动化运维？包括哪些？自动化发布，有问题可以回滚？

运维自动化是一个仁者见仁智者见智的概念。我的理解是，运维自动化要打通从代码开发完到正式上线的所有环节，包括版本构建、打通自动测试、自动化上线以及自动化监控。

在这个大命题下，可以根据自己工作环境和自动化水平的不同，选择一两个痛点开始进行自动化实践。最后形成完整体系。

2、想请问一下自动化运维怎么做的？需要从那些方面考虑？我所考虑到的有实施运维，日常巡检维护，以及故障自动化处理，和提醒。除了这些请问还要注意那些方面？另外，随着

IT 技术的日新月异，涌现了很多新的应用，请问该如果有一个基本的路子来做运维，或者规律，流程来达到运维需求？例如现在比较火的OpenStack Docker 大数据。这些技术实现功能只是很小的一步，更多的是上线后的运维。更多是想要一种思路，能列举大家遇到过的问题，以及问题如何处理？ 

你的问题很好，但这个话题比较大。我先说下我的理解吧。传统的运维服务流程 ITIL 还有一定的价值，但需要结合一些 DevOps 思想来进行适当的改造，融合两者的长处。从拥抱变化开始，以一种开放的态度来进行运维。但不变的一点是，以为业务创造价值为最终目标，这就是运维的目标。

3、实现运维自动化，最主要就是配置管理、状态管理和变更管理，其中配置管理要如何来做，有什么好的方法分享下吗？

对配置管理，我认为应该分为“基础架构资源配置管理”和“软件/应用配置管理”。

前者是一般意义上的 CMDB 的范畴，这个可以根据自己业务特点在开源 CMDB 方案的基础上做一定的适配；

对于后者，一方面是系统（例如版本控制系统的结合），一方面是流程（例如和变更管理挂钩）。在我们的实践中，这 2 个方面都有涉及。

4、请问你主导运维自动化平台的功能设计和实施，是通过 Python 开发管理工具吗？另外，你们是重新开发，还是根据 Saltstack 之类的进行二次开发。

底层使用 SSH 协议建立服务器管理通道，上层使用 PHP 开发管理界面以及封装一些常用操作，比如密码修改、脚本下发和执行等。完全自主开发。

四、做好安全措施很重要，安全相关的问题

1、运维离不开安全，服务器的安全也很重要，书中有讲运维安全这块吗，如何把控安全这块？

书中有安全主题。安全是一个庞大的体系，书中主要讲了保障 Linux 系统安全的一些措施。其他安全主题，比如社会工程和入侵检测，可能需要看更专业的书。你可以先看看咱们《Linux 运维最佳实践》是否能满足你的基本安全需求。谢谢支持。

2、Web 安全监控有开源解决方案吗，能否做到在接入层就把一些可能的漏洞拦掉？Suricata？

Suricata 没有研究和实践过。《Linux 运维最佳实践》中第 11 章 Web 服务器安全部分提到了几个工具，你可以参考下。但 ModSecurity 规则在上线前要进行严格详细测试，不要出现误判。另外，建议对生产环境进行定期的安全扫描，例如使用 Tenable Nessus 工具等。安全专家的人工渗透测试也是必须的。

五、Docker 很火热，在运维中结合使用？

1、在网易游戏运维中是否用到了最近很火的 Docker 技术以及应用在哪，存在什么问题，如何解决？

目前我们在调研 Docker 技术，只有少量游戏测试使用。需要根据不同的业务模型选择对应的网络模型和存储方案。Docker 技术会改变传统的运维方式，要考虑和原有运维系统整合以及运维习惯的调整所带来的挑战。另外，我不是网易公司的，我目前在盛大游戏工作。 

2、Docker 化对运维影响深远吗？

Docker 化对运维有影响，它带来的影响包括：持续交付、微服务以及 DevOps 理念的冲击。作为运维，我们要拥抱这个变化，通过不断学习和实践来迎接这些挑战。

3、为何国内没有一家成熟的 Docker 方案公布细节呢？

Docker 还是一个新生事物，各家使用的场景和模式有所不同，而且会有一些二次开发的管理系统和调度系统。

六、不是所有对比都会产生伤害，工程师想的只是最优方案

1、游戏服务器运维和网站服务器运维以及 APP 服务器运维，有哪些不同点和相同点？

这个问题很有代表性。不同点是，网站和 APP 运维接触的通用开源软件比较多，游戏运维接触的大部分都是自研的程序。

共同点是，都需要掌握操作系统知识、软件硬件以及网络知识，还有排查问题的思路和容量规划等。两者都需要引入运维自动化的思维和体系。《Linux 运维最佳实践》最后 2 章描述了游戏运维的相关体系和技术。

2、作为运维人员，Python 这样的脚本在进行系统管理和监控的时候相比 Shell 有怎样的优势呢？

作为高级编程语言，Python 有非常丰富的库，包括核心库和第三方库，很多时候不需要自己造轮子；

相比 Shell，它有更好的控制力、重试机制，比如对 Socket 设置超时等等。

3、CentOS 比起 Ubuntu 来说有啥优势？为什么服务器大多用 CentOS？

不同 Linux 分支各有特点，比如 Ubuntu 新版本发布较快，如果追求内核版本升级速度的话，可以考虑。CentOS 一直是我们的主要 Linux 发行版，稳定性以及熟悉程度最高。

选择某个发行版时，要考虑它的生态，比如上下游的支持，还有一点，就是运维人员招聘的方便程度，国内熟悉 CentOS 的稍多一些。

4、想问下只有一台服务器，有多个应用，是用 LVS 做负载好还是 Nginx？差别大吗？

你说的后端应用是基于 HTTP 或者 HTTPS 的吗？如果是的话，并且吞吐量不大的情况下，使用 Nginx 即可；如果非 HTTP 或者 HTTPS 的 TCP 应用，建议使用 LVS；如果 HTTP 或者 HTTPS 吞吐量特别大的情况下，使用 LVS DR 模式。

七、You Need Backup，与备份相关的一些问题

1、1000 台机器规模，备份系统应该要做到什么程度？

1000 台服务器，要区分业务类型，如果类型单一，备份就比较好做。如果类型多，那么要考虑的地方包括：数据库更新的频率（全备+增量备份？还是只使用全备）、数据备份的大小、数据集中归档的要求。

2、备份是怎么做的？上百 T 的图片、附件有什么高雅的备份方案？

在线备份这一块，可以考虑使用 erasure coding 算法，在增加一定可靠性的能力下，不至于导致备份存储的成本过高。同时要考虑离线备份，比如磁带。

八、路漫漫其修远兮，运维工程师的职业生涯

1、你觉得在未来，运维的核心会是什么，自动化，预判或是其他？

我觉得，未来的运维应该是智能化的。把现在需要人做的容量规划、扩缩容、排障全部实现智能化。运维的任务就是编程，把自己的能力灌输到机器上。当然，理想很丰满，现实很骨感。这需要我们的不懈努力。

2、作为工作 4 年多的测试工作者，在运维方面也是有一定的涉猎，在公司维护自己的测试环境，有时候也需要一定运维功底，从 

Windows Server 到 Linux，学习很多，也总结了很多。上家公司着手 Docker 部署的时候刚好离开公司了。真是有点遗憾，后续工作也没时间去实践，目前使用的是 ng 负载，采用 Tomcat 

部署方案，工作实在比较忙，很想在运维方面也有一定的提升！不知道从何入手好，求大神指教。

从你的描述来看，目前是兼职运维。我建议是否可以考虑，在搭建环境之外，多多研究下其中的原理，同时用自动化脚本维护这些环境呢。相信你也有一些编程经验，这些对于你后续实践运维也是有帮助的。另外，就是可以多看看别人总结的运维案例，少走一些弯路。

3、运维技术挺杂的，如何看待这种杂？给人感觉好像什么都会点，对于工作 5-6 年的运维来说，有什么好的学习建议？

如你所说，运维技术要求范围确实蛮广的。我觉得，对于工作了一定时间的运维同学来说，可以考虑的方向有以下几个：

1、DevOps 实践（加强自己的编程能力，系统学习一门高级编程语言，运维自动化）

2、对自己的技术薄弱点重点学习，比如系统学习网络知识

3、看一些比较好的运维技术书籍，学习别人的干货

4. 由于运维系统有全面的数据收集、自动处理、报警和自动恢复的机制，我们这里将运维和 BI 

结合在一起。扩展运维工具和架构，将已成熟的 BI 接入运维体系，解放业务专员的工作，常规的业务分析、报表、数据监控都可依赖这套运维系统。在我们这里，运维从一层平台逐渐变成一种框架，有需要的场景都可以套用。技术一直在变，但最重要的不是技术，而是用技术提供服务的思想。

除了和 BI 结合，运维思维还可以和哪些相关业务场景结合，可以在新的方向上产生价值呢？

我很赞同你的想法和实践，“用技术提供服务的思想”。我个人认为，运维的终极目标可能是“没有运维工程师的”自运维，或者叫智能运维，是 AI 在运维领域的深度融合和实践。容量规划算法的不断优化、基于公有云的资源自动调度都应该是智能化的。当然，实现这个目标还有很长的路要走。

5、Devops 对运维有那些改变，能简单说下嘛？

Devops 从概念提出到现在已经有一段比较长的时间了，总体来说，我认为它带来的变化是：持续交付能力需要打通研发、测试和部署运维的整个链路，它对运维自动化的能力要求更高了。我们必须通过掌握一些运维自动化框架加上一定的编程能力才能根据业务场景来应对这种变化。另外，对运维来说，就是要拥抱变化，以开放的态度进行协作。

6、现在哪个版本的 Linux 使用最广泛，还有 Linux 运维，我们需要学习一些语言吗，比如 Python 之类，这样才能算是一个真正的好运维？

不要犹豫了，立即开始学习编程吧，不管 Perl 还是 Python，熟悉哪一种都行。在这里，我不对比 Perl 和 Python 的优缺点。坚持用自己的代码（加上别人的框架和库）来解决重复的运维问题，你会成长的更快。CentOS 用的比较多。

《Linux 运维最佳实践》第 18 章是使用 Perl 进行系统自动化编程的内容，你可以先看看。如果感兴趣的话，立即开始吧。

7、请问您写书，是怎么坚持写下来的？是把平时工作重点的问题，记录下来，每天写一点，再总结吗？写书有什么工具软件吗，还是只是用 Word 来写？能分享下写运维书籍的方法吗？

这个问题非常好，也是我想分享的。写书的素材依赖于平时的积累，建议大家平时多写写标准的文档，word 格式可以参考咱们这本书的编排。比较重要的 3 点是：

1、visio 图要保留下来，不能只存图片，因为可能还要调整排版

2、有些故障现场，尽量记录详细，现象和分析过程、辅助的日志和抓包文件等，建议都保留下来

3、脚本按照分类保存下来，以便查找

●本文编号44，以后想阅读这篇文章直接输入 44即可。

●输入m可以获取到文章目录

推荐：《15个技术类公众微信》

涵盖：程序人生、算法与数据结构、黑客技术与网络安全、大数据技术、前端开发、Java、Python、Web开发、安卓开发、iOS开发、C/C++、.NET、Linux、数据库、运维等。