不仅是 Linux，盛大专家全面探究运维最佳实践

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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