15-MySQL DBA笔记-运维管理

第15章 运维管理
随着各种技术的快速发展，现今的DBA可以比以前的DBA维护多得多的数据库实例。
DBA已经越来越像一个资源的管理者，而不是简单的操作步骤执行人。
本章将为读者介绍规模化运维之道。
首先，我们讲述规模化的相关知识，然后再简要介绍下服务器的采购，最后，笔者将分享一些运维管理规则，希望能起到抛砖引玉的作用。

15.1 规模化运维
对于机器比较少的公司，我们可能不需要太过关注一些规模化运维的原则，这个时候更值得优化的是人员成本。
而在拥有了大量机器之后，我们必须考虑如何高效地运维大规模的数据库主机，这里面有一些要点需要把握，
比如资源利用、资源隔离、虚拟化、标准化、自动化等，依据你的生产环境的实际情况，会有不同的侧重点。
本文主要是介绍一些思路，实际实现的方法大同小异，按照合适的方法论，你也完全可以构建自己的高效的自动化运维平台。

15.1.1 基础环境
运维有一定规模的数据库机器，需要做到软硬件基础环境的简单化和标准化。
拥有稳定的底层，才能确保数据库正常的运行。
我们的基础环境要满足一些要点，可以归纳为简单化、标准化、自动化、文档化。
这一系列要点有一个根本的目的，那就是尽可能高效地运维数据库机器。
我们需要首先从底层基础设施的标准化开始入手，这是基础，只有标准化了，我们才好做运维平台，开发运维工具。
有了标准化的数据，我们才能方便地构建性能模型和容量模型，才能在这个基础之上延伸更多的应用、使平台变得越来越智能，可以说，标准化是智能化的基础。
基础环境配置的标准化和统一，将给后续的运维带来便利，所以务必要在一开始就有步骤地进行实施，保证了基础环境的标准化，才能在后续实现大规模的自动化和信息收集。
基础环境中的一些注意事项如下。
（1）操作系统的版本要统一，不要追求操作系统的先进性
MySQL推荐运行于Linux下。据统计，90%的MySQL用户使用Linux做生产环境，80%的MySQL用户使用Linux做开发环境，大部分大网站也都使用Linux。
各大厂商都大力支持Linux，Linux同时也拥有成熟的开源社区，形成了良好的生态。
Linux系统的稳定性很好，各种主流数据库软件，也都在Linux系统上获得了长足的发展，尤其是MySQL。
Linux对比其他操作系统，能更快地反映出最新软硬件的发展，对于最新的硬件有更好的支持。
所以，如果没有什么特殊的更好的理由，建议大家也在 Linux下使用MySQL。
操作系统技术发展到现在，管理越来越简单，特性越来越丰富，但是核心的东西相对变得较少，
对于操作系统，笔者觉得应该保守些，我们的数据库服务器是面向企业的，面向海量用户的，上面运行的都是服务级别的应用，稳定性才是最值得看重的。
操作系统上自带的各种应用，如gcc、MySQL，都远远落后于最新的版本，这是一种自然的事情，因为它追求的是稳定性。
你可以安装那些新的应用，但这些新的版本可能并未经历相应操作系统版本的大量实际验证，可能还需要不断地修复一些Bug，或者稳定性还有待增强。
当然，服务器软件的版本比当前的稳定流行版本超前或滞后太多也可能会有隐患。
架构简单的一个重要前提是标准，应用程序/网络服务器软件使用相同的基础平台，而不是各种版本的操作系统都上。
操作系统的不统一将在未来使运维就得很复杂，因为哪怕是一点小小的不同，都可能造成系统管理员的困惑，
并不是每个软件的开发者都熟悉各种操作系统，熟悉各种不同版本的操作，并能够让自己的软件版本完美地运行于各种版本的操作系统之上。
为了兼容各种操作系统，你可能要进行许多特殊的处理，从而难以做到更完善的自动化，导致可维护性下降。
可维护性是一个重要的指标，降低了维护的难度，才能充分考虑扩展性和自动化，才能借助各种开源工具高效地管理服务器。
我们所使用的操作系统应该是应用得最广泛的，配置也应该是基于主流的基础设置，这样可以大大降低学习和维护的难度，学习新系统的也是需要成本的，
而且，对于数据库服务器来说，操作系统的各种新特性对于整体系统的性能优化影响并不大。
如果更改一个参数对于性能的改善并不是非常大，那么建议尽可能不要去动它。
（2）应该使用64位的操作系统
64位的操作系统对比32位的操作系统有许多的好处，一般情况下，它的兼容性更好、性能更好、资源利用率更好，
所以，建议在生产环境中，不是出于特殊的原因，都应该使用64位的。
（3）自动化你的部署
许多中小公司，在自动化运维没有发展之前，信息的组织依赖于许多表格，部署过程都是按文档的顺序逐步来进行的，
部署完一个服务后，还需要一个长长的检查列表来核对部署是否正确，由于检查列表往往是基于工程师经验的不断累积，是基于前任的经验，
由于技术或产品的不断更新，新的问题不断出现，所以这份检查列表（checklist）需要保持持续更新，
这些方式对于小规模的机器可能还比较适合，但对大规模的服务部署上下线，人工检查显然是不适合的，大规模的服务部署将需要自动化的检查手段。
规模化的运维，可以通过一些自动化手段，让部署、上下线操作变得更容易，基本上不需要你介入。
你能够通过自动检测、自动处理的方式上下线数据库资源。
我们可以定制操作系统、编写脚本，自动化部署各种操作，也有一些开源软件的方案，比如使用puppet进行配置管理。
一些公司，还专门设计了应用运维平台、数据库运维平台，在一个统一的平台上进行数据库生命周期内的各种工作。
总之，你在部署维护上所耗费的时间越少，你就越有时间针对性地进行系统架构的改造和前瞻性的规划。
（4）了解你的生产负荷，搭建监控平台，收集一切信息
我们应该熟悉服务是I/O密集型的、内存消耗型的，还是CPU密集型的，对于大规模部署的机器，越了解你的生产负荷，
你就越知道它适合部署在什么样的机器 上，应该如何充分利用资源，由于历史问题或时间精力的关系，
许多公司在最开始发展的时候，往往没有一个标准，针对特定的负荷选择硬件，更多地是凭着个人的经验去采购，
在到达一定规模后，逐渐构建了自己的生产负荷的模型，这个时候，采购硬件将更多地依据线上的生产负荷数据。
熟悉你的负荷，你才能提前升级硬件或扩容，对于数据库类的应用，要重点关注内存的资源瓶颈，
硬盘、CPU、网络等资源瓶颈往往只会使程序变得缓慢，这点也许能忍受，
但一旦出现内存瓶颈，就好比高速行驶的汽车撞上了一堵墙，你可能会碰到无法预料的严重后果，
所以，请务必关注内存瓶颈，某些情况下，I/O瓶颈比较突出，可能就是因为内存分配得不够所导致的。
我们应持续不间断地收集信息，在现有数据的基础上，分析趋势，构建模型。
有了数据，也方便我们进行性能调优，调整架构设计，从而验证程序变更的效果。
（5）不要在数据库机器上部署其他服务
复杂的环境将导致整体系统的不稳定性，导致复杂的诊断。
以上5点主要说明了运维数据库机器的一些关注点，这也是早期中小型公司可能犯的错误，
特别是最后一点，为了利用资源，在数据库机器上部署其他服务，往往会导致出现更多的问题。
有了好的基础，我们才能适应未来的真正的大规模的数据库主机运维。
当你的公司规模变得更大的时候，你的数据库运维成本不会增加太多。

15.1.2 虚拟化
在计算机技术中，虚拟化是一种资源管理技术，是将计算机的各种实体资源，如服务器、网络、内存及存储等，
予以抽象、转换然后呈现出来，打破实体结构间的不可切割的障碍，使用户可以用比原本的配置更好的方式来应用这些资源。
一般所指的虚拟化资源包括计算能力和数据存储。
虽然虚拟化在一些场景和一些应用中取得了成功，我们也总是说虚拟化节约了成本，
但我们有必要思考一下，真的是虚拟化节约了成本呢，还是有其他的因素帮助节约了成本？影响成本的因素有哪些？虚拟化是如何影响成本的？
计算服务器虚拟化的成本时需要考虑4个因素：硬件成本、能源成本、软件成本和人力成本。
你需要综合评估虚拟化改造对成本的影响。
市场上，有一种观点，认为虚拟化技术可以大大节省成本，其实，服务器虚拟化技术是否能够带来成本节约及节约多少都取决于自身的架构。
如果一台物理机上运行了多个虚拟机，但它的资源利用率并不高，那么其实每个虚拟机的成本也不低，
本质上，如果你的程序能够充分利用软硬件资源，那么服务器虚拟化在削减硬件成本方面的成效就不那么明显了。
你要确保，在主机上部署多个虚拟机时，增加虚拟机密度所消耗的成本不会超过所得到的收益。
那么，为什么还是有那么多公司宣称虚拟化节省了大量成本呢？
这是因为他们的机器规模已经很大了，但利用率的问题一直没有得到解决，软件程序架构一直无法充分利用资源，主要是CPU资源，
对于这些应用来说，通过部署大量虚拟机，确实很容易调节硬件的利用率。
然而，这并不是说虚拟机大大节省了成本，更准确的说法是，他们之前没有真正地关注服务器利用率的问题。
如果能够通过配置软硬件资源达到充分利用硬件资源，那么也许可以达到更好的性价比，毕竟虚拟机在程序和底层硬件中间增加了一个层次，多了一层转换的开销。
目前主要是应用服务器的虚拟化，而数据库的虚拟化还少有人做，原因在于数据库的高I/O负荷难以被隔离，且多个虚拟机对底层存储设备的操作效率不高。
另 一个需要考虑的因素是数据库的安全性比较高，如果一台普通的物理机宕机，可能会导致上面多个MySQL的数据丢失和损坏，这点是DBA不能接受的。
数据库可以虚拟化的一个场合是你存在大量的小数据库，数据库的QPS很小，没有什么读写，业务场景单一，这种情况下，使用虚拟机可以简化管理成本。

15.1.3 关于去IOE
去IOE是一个比较流行的说法，即去掉IBM、Oracle、EMC这些软硬件设备，以其他的解决方案来代替。
IBM的服务器+Oracle数据库+EMC存储是非常流行的组合，大量的企业都在使用这样的架构。
但是随着IT领域的不断发展，PC服务器、固态硬盘、开源数据库的推广，人们有了更多的选择，
这个时候一些公司开始尝试，替换掉自己企业内部的IOE的某一部分，甚至全部替换掉。
这方面比较典型的案例是阿里巴巴的“去IOE运动”。
支持或赞同去IOE的人都不在少数，我认为这个说法有些简单，“口号”可能掩盖了许多问题，传统领域和互联网领域的工作人员、软硬件的协同工作方式存在很大的不同。
对于互联网行业，往往一开始就是LAMP架构，使用相对廉价的PC来构建服务，所以这个去IOE的运动更多地是针对传统行业而言，
一些本身就属于互联网行业的公司，如果其使用了IOE，那么，可能会逐渐无法满足其不断增长的规模，
IBM、Oracle、微软这些大厂商，自身并没有运营大规模系统的经验，提供的解决方案，只适合中小型公司，
所以京东、阿里巴巴等公司才会不断地把数据迁移到大规模的MySQL集群上，如果非IOE的方案能够提供更低的成本，更好的性能，那么为什么不去尝试呢？
对于绝大部分传统行业，仍然要回归到商业的本质，你要满足什么要求，达到什么目的，不能为去IOE而去IOE。
如果你的系统已经很稳定了，你对自己的生产配置有信心，你的公司也需要稳健，
也许你应该再思考下，去IOE所带来的好处和坏处，你应该综合考虑成本，而不是简单地拒绝商业公司的软硬件产品。
使用IOE的好处是，当你的系统中某一环节出现问题时，你能迅速地向其他出现过类似问题的用户请教。
同时这三家厂商已经磨合得非常好了，在向他们寻求帮助的时候也更简单一些。
这样能够把出现错误的几率降到最低，同时为你节省大量的时间。
虽然开源解决方案似乎软件成本低，但是同时人员的成本也需要考虑， 你需要投入更多的人员培训成本，甚至雇佣一些专业的软件设计人员来解决问题，
同时，传统行业公司的业务可能是非常复杂的，开源数据库往往难以达到商业数据库所支持的强大的功能和丰富的特性。

15.1.4 资源利用和隔离
硬件的发展很快，目前单机的性能数据也在不断提升，固态硬盘已经在互联网公司获得大规模的使用，可以说，价格已经不成为问题，许多公司都配备了固态硬盘或FLASH卡，
相对于传统的机械硬盘，固态硬盘有一个数量级的性能提升，而FLASH卡有2~3个数量级的提升。
长期以来困扰DBA的I/O瓶颈问题得到了极大的缓解。
内存现在也很便宜，许多数据库主机的内存标准配置已经达到了128GB。
Intel的CPU性能也提升得很快，打开超线程后，可以拥有24个、48个甚至96个超线程。
为了充分利用多处理器/多核系统，程序需要有并行运行的能力，也就是说，可以同时在多颗CPU核上运行。
早期的官方MySQL版本由于使用了旧的InnoDB引擎，导致扩展性有限，难以充分利用CPU资源，Oracle收购MySQL之后，
新的版本MySQL 5.5、5.6和5.7都使用了新的InnoDB引擎，扩展性大大提高。
但由于存在一些限制，MySQL实例还是难以充分利用我们的硬件CPU资源。
由于在单机上仅仅部署一个MySQL已经无法充分利用机器了，所以我们往往在一台单机上部署多个MySQL实例以充分利用资源。
这样就可能出现各个实例资源争用的情况，因此我们有必要对主机上的MySQL实例做一定程度的隔离。
目前在业内推荐使用的资源隔离的方案是CGroup，它是Linux内核提供的一种资源隔离技术，可以对CPU、内存、I/O等资源进行隔离。
CPU和内存相对来说比较好隔离，磁盘I/O则不太好隔离，可以考虑在更上层做限制。
如果需要做数据库的云平台，CGroup技术是很实用的，它比基于虚拟机的资源隔离更高效，
由于CGroup对内核有要求，而且也比较复杂，所以许多公司并没有使用这项技术，但它已经在一些商用的云平台中得到了使用。
一些DBA使用的是更简单的绑定CPU的策略，通过numactl或task等命令把MySQL实例绑定到某颗CPU上，
绑定CPU不仅在一定程度上隔离了CPU资源，通常也能获得比较大的性能提升。
建议单机部署多个实例，除了资源利用，还有一个原因，MySQL对于多核CPU的利用率一直不佳。
对于官方版本MySQL 5.1，我在生产环境中很少看到能跑满6个核的，随着核数的增加，MySQL的吞吐并不能线性扩展，
虽然MySQL/InnoDB一直在改进这个问题，但在可以预计的相当长的一段时间内，MySQL将无法充分利用到目前的8核、12核的CPU，
所以我们需要提升MySQL对于CPU的利用率。
绑定CPU就是一种比较有效的手段，比如，我们可以使用如下 命令绑定mysqld到特定的CPU节点：
numactl --cpunodebind=0 --localalloc
绑定CPU，要注意冲突，如果你绑定了一颗本来就很繁忙的CPU，那么即使有空闲的CPU，你也利用不上它。
关于NUMA及numactl的详细介绍，请参考18.3.2节。
其他资源也可以进行适当的隔离，比如通过多个IP的方式，把MySQL绑定到不同的网卡上。
以上针对的主要是多实例的资源隔离，我们也可以在数据库上做一些资源限制，
MySQL支持对用户的简单的资源限制，比如允许一定时间内运行命令的次数、进行连接的次数，
但MySQL的资源管理相对于传统的商业数据库，比如Oracle，还是很粗陋的，没有充分反映连接用户所消耗的资源，
比如用户查询扫描的记录数就不知道，所以，仅仅适用于一些特定的场景，比如监控系统所使用的用户，就可以限制一下它的资源使用，以避免监控用户异常影响到生产负荷。
如果需要达到类似Oracle限制资源的功能，有如下两种策略，
一是改造MySQL，让MySQL收集用户的资源使用信息，在用户达到阈值时，自动限制用户对资源的使用，比如降低用户访问数据库的速度。
二是用户程序通过Proxy（中间件、代理）访问数据库，中间件收集资源的使用信息，对照用户的资源限制（连接数、QPS、流量等），对用户访问进行资源隔离，
比如中间件可以自动对访问量很大的业务进行限流。

15.1.5 关于备机、备份
对于应用服务器，在大量服务器下，更多的是考虑弹性扩展的能力，可以动态地添加计算资源，这比预留一些备用节点更适合。
而对于数据库机器，一般选择主从架构，留一个空闲的备机作备用。
在大批量机器下，许多人会怀疑保留一个完全空闲的备机的合理性。
我不确定以后随着技术的发展，是否会有一个很好的方案，可以用少得多的机器支撑业务。
但目前来说，对于绝大部分企业，使用主从架构，保留一个空闲的从库，是最简单、最稳健的方式。
我比较怀疑国内的公司是不是都严格遵守了“N+1”的策略。
一主一从的架构，如果严格执行，可能有许多备用服务器。
不过现在的数据库服务器都比较强劲，多实例下，已经节省了许多备用资源。
大量的节点，用于备份中心的投资自然就会很高，但一般来说，对数据进行备份的成本远远小于丢失数据带来的损失。
如果你考虑到这一点，那么你将没有理由削减备份的投资。
业内的数据库服务器一般在从库进行备份，但是随着数据越来越大，也需要留意大数据或大量节点下的一个趋势，数据使用副本，不需要定期备份也是可能的。

15.2 服务器采购
服务器采购需要在性能和成本之间做一个平衡，建议读者跟踪使用主流的配置，主流的硬件由于是大批量生产，因此更容易降低成本，
比如，我们倾向于使用普通的服务器，双路CPU就足够了，没有必要考虑昂贵得多的4路CPU；
再比如，内存条的选购，许多公司选购8GB，而如果是选购16GB一根的内存条，就会贵得多了。也许以后16GB会成为主流，那么8GB反而就不划算了。
SSD的大规模使用同样是一个成本不断降低的例子。你需要不断跟踪硬件的发展以挑选最划算的配置。
当我们采购硬件或部署新的系统时，我们可能被要求选择更经济的方式，以合理的成本实现目标的性能要求。
影响性能的因素有许多，比如CPU的个数、磁盘的个数、磁盘RAID级别、内存容量、Flash设备的使用方式及文件系统的设置等。
为了实现以最小的成本实现性能的需求，我们可能需要做许多测试和验证，因为我们需要组合许多不同的软硬件的搭配。
更具实践性的方式是，依据经验，选择测试某些组合下的性能，最终确定何种配置能够满足你的需求。
如果我们知道最大可能的硬件配置，那么可以按如下步骤选择配置。
1）测试所有组件都是最佳配置时候的性能。
2）逐个改变各个部件的配置，然后测试性能。
3）通过以上步骤，我们可以得出大致的结论，当我们使用更低的成本，减少某个部件的配置时，比如减少内存，我们的性能会损失多少。
4）然后，从最大配置开始，我们逐步调整各种部件的配置，最终得到一个组合，能尽可能以最小的成本实现性能的需求。
5）再次测试，验证这个配置是否满足需要。
每个公司所选择的标配服务器都不尽相同，因为需要契合自己的业务，考虑的角度就会不一样。
而且随着市场的变化，主流配置也许很快就过时了，在此就不列举服务器具体配置的例子了。
读者可以Google主流互联网公司的配置或和业内的同行进行交流。
没有哪一个技术人员可以说自己的配置是最优的，相比较选择最优的配置，如何充分利用现有资源、让硬件资源充分为业务服务才更具有实际意义。

15.3 运维规则
为什么我在基础知识里，增加了一项运维规则的介绍呢？
对于运维，除了平台、工具、知识、经验，意识也是非常重要的，有正确的认知、意识，就可以让运维数据库得心应手，
又稳又好地运行大规模的数据库集群离不开一些行之有效的规则，可以说，意识在某种程度上决定了我们的运维质量。
以下将重点介绍数据库运维的36条规则。
这些规则可能互相之间有冲突，不同的人，可能侧重点也不同，但总体目标是一致的，都是为了服务的质量。
读者也 可以跳过本节，待有一定的经验后再阅读本节收获会更大。

15.3.1 确保基础网络稳定可靠
因为网络在应用层软件和数据库软件的下一层，因此网络的不可靠，将直接影响到数据库服务器和应用服务器的稳定和性能，
网络的复杂性，也可能导致应用软件变得复杂，对此应该有清晰的认识，许多软件架构师或运维人员往往低估了网络对于系统的影响。
现实中，许多软件都是基于网络良好的情况下设计的，当碰到复杂的网络问题时，可用性将大大降低。

15.3.2 应构建性能模型，进行容量规划
一些较大的公司，可能有比较完善的性能模型，以尽可能地进行容量规划。
而小公司，可能更多地信任监控机制，并没有进行容量规划。
随着公司地不断发展，容量模型是需要逐步建立的，至于效果如何，也需要有清晰的认识，现实世界的生产可能比模型复杂多了。
传统行业的容量规划，往往比较固定，可以预知，因此按生产任务来安排即可。
而互联网行业有许多变数，业务的增长可能是爆炸式的，新增的业务，有时会资源紧张，有时资源又十分空闲。
如果不能从更高的规划角度去管理资源，可能会导致手足无措。
作为小的技术团队，可能不太了解高层的实际想法，但也应该尽可能地贯彻传达高层的一些想法、方向，避免导致资源浪费。
容量规划，应该提早发现是否需要扩容，要更主动。
需要留有一定的余量，这样才能心中有数、遇事不慌。
如果流量突然增长，可能会导致业务受到影响，甚至下线，我们可以理解这也是某种程度的单点，需要尽力避免。
应该把容量规划作为一个常规的工作定期检查。
如果有合适的预测模型会更好，但更多情况下可能仍然是基于自己的经验分析，对业务了解得越深，对性能的规划，就会更准确、更有前瞻性。

15.3.3 优先扩容，再考虑优化
尽量不要在容量和性能的高度压力下考虑优化，
先扩容，把危险症状降低下来，然后再考虑优化，往往是更靠谱的，
除非你有把握，能够在短时间内通过调整让性能瓶颈消失。

15.3.4 保持简单
生产中的异常往往是由复杂性导致的。我们要区分哪些复杂是必然的，哪些是由于“想当然的”或“错误的理解”导致的。
比如，跨IDC的网络复杂性就是必然的， 需要更复杂的处理策略。
而过多的程序数据流层次，就可能是不需要的，层次多了，再加上没有合适的协议约定，往往会导致连锁反应，使诊断困难、开发复杂化。
我们不要因为解决问题，而在你的架构中引入“新的问题”。
对于核心架构或算法的调整，往往会导致异常，“回归测试”可以发现一些问题，
但更多地依赖于研发人员对于风险的认识，应尽可能地解耦，否则调整的代价太大，引入的问题也会更多。

15.3.5 监控一切
监控一切，记录一切数据。当我们有了数据，才能验证自己的想法，才能辅助我们进行决策。
监控的不仅仅是性能数据，也包括了产品、运营、研发各个部门所关心的数据。
多记录一些数据，总不会有什么坏处，有时即使某些数据看起来似乎没有什么用，但在不久的将来，可能就会派上用场了。

15.3.6 处理监控报警
应该注意监控报警是能够采取措施的，或者说，能够找到合适的人来处理的。
我们在部署监控平台时，容易犯的一个错误是，报警太多，而有很多报警，却是不需要处理的，每个人每天关注事物的时间总是有限的，所以要注意报警规则的有效性。
一些不能处理，或者不需要及时处理的报警，往往属于趋势统计分析的范畴。
我们完全可以选择在其他时间段进行处理。
如果一个运维工程师频繁收到报警短信，可能就把真正值得关注的信息给忽略了，或者由于太多报警短信，导致他不再查看短信报警，以免严重影响自己的生活和工作。

15.3.7 不要重复“造轮子”
不要重复“造轮子”，也不要什么都从外部获取，如工具、代码、框架等。
需要考虑的是在合适的时间以合适的成本切入，投资回报率也是需要考虑的。
一般来说，每个公司都存在重复“造轮子”的现象，而且许多人都热衷于此，可能需要用这样的项目来证明自己。
但是，他们并没有考虑到一个重要的指标：投入/产出比。
如果能够充分利用社区的成果，利用公司已有的成熟框架，那么可以大大加快自己的项目进度，因此，为什么非要自己做一个呢？
也许，有些人考虑的是，重复造轮子，可以真正锻炼到团队，毕竟从头开始做一个东西，所累积的经验值可能比一般的项目多得多，往往有助于个人的成长和公司后续的项目。
对于开源产品应该尽量选择国外的产品，笔者这么说有些无奈，虽然国内有许多公司都在拥抱开源，但更多的是个人行为，
普遍来说，国内的开源产品，往往缺乏维护，缺乏更高层次的性能、架构和扩展意识，
在和国外的开源产品的竞争中，一般都会败下阵来，随着核心人员的流失，或者成员自己的KPI都难以保证，往往不能继续发展下去。
所以在使用其他公司的开源产品的时候，特别是缺乏社区参与的产品时，一定要谨慎，最好能够确保自己有足够的能力进行修改，有专门的源码研究人员，
否则一旦发生了生产事故，Debug本身也需要时间，更何况是不熟悉代码之下的Debug。

15.3.8 允许出错
允许出错的运维文化，传统的绩效考核（KPI）可能会对此形成不必要的桎梏。
人往往从错误中才能得到成长，所以犯一些错误都是可以理解的，关键是我们要建立一套机制，让错误能够尽可能快速地被修复，限制错误影响的范围，
并且我们需要能够总结归纳错误，从错误中得到成长，这不仅仅是个人的成长，也是组织成长的方式。
国内的现状，确实有些片面地放大了故障现象。
即使是Google、Facebook、Twitter、Amazon这样的公司，也会偶尔出故障，影响面不一定比国内的公司小。
这个世界上，只要存在着硬件载体，就必然伴随着各种各样的故障。
有时为了追求高可用性，设计复杂的架构，或者准备过多的冗余设施，往往会导致解决方案的成本剧增，而解决方案的复杂性，可能会增加维护成本和后期改造的难度。
国内的众多公司，真正需要99.99%的高可用的到底有多少呢？有多少不能承受的单点故障呢？
许多时候，产品才是王道，短期的失效，可能并不会影响到用户的流失。
我们应该对可用性进行管理，区别各种服务的等级，对可用性要求高的服务进行专门优化。
有时出现性能问题，往往是一件好事，因为这往往伴随着流量的巨大增长。
而在一定的时间内，问题总是可以解决的，我还从来没有碰到过用时间解决不了的技术问题，最重要的是经过问题的解决和总结，经验和技术都能够上一个台阶。
当然，我不是鼓励冒险主义，有计划的冒险才是可取的。
在不同的时间段，解决不同的技术问题，往往是对现实的反映。超前或滞后太多，也不可取。
生产环境应该允许犯错误，而且应该是建立在可控的前提下。备份、备份、再备份，保证可回滚，是一个好习惯。
重复性的失误，往往可以找到客观规律，然后用流程、规范和工具避免错误。
失误，往往还出现在周末，出现在非正常升级时间，在打破常规的情况下，在人的体力、智力处于低谷期的时候，将增加故障的概率，毕竟人不是机器，由于生理问题可能会导致出现错误。
所以，很多问题或故障的发生，表面上看是技术、经验问题，但更本质的还是属于人员组织的问题。
团队管理者需要知道组员能否适应需要，关注其成长，给予适当压力，但也别过度了，并且还要提供适当的支持。有句话说得好“让合适的人做合适的事”。

15.3.9 设置备用角色
备用角色的作用不容置疑。
有备用角色，才可以让我们的工作不被打断，当主要角色请假，或者因为过度劳累，备用角色可以马上启用。这样可以让我们的工作不会陷入被动。

15.3.10 仔细阅读产品文档
在进行任何操作之前，都建议详细阅读文档。
产品的说明手册，比如RAID卡的说明文档，就需要仔细阅读，以便选择合适的参数配置。
通常来说，默认的配置并不适合于生产环境，关于数据库的升级，网上可能有各种操作说明文档，但仍会遗漏许多细节，
而且在特定的生产环境中什么都有可能发生，因此，要详细阅读相关版本的升级帮助，甚至准备在必要的情况下进行降级的策略。

15.3.11 画数据流图和物理部署图
由于公司有分工，某些人往往只负责部分系统，缺乏对整体系统的把握。
有可能的话，应用系统运维工程师应该画出自己的物理部署图，从而了解自己的系统，对于数据流图，软件研发人员也应该将其画出，以便相关人员参考和诊断问题。
如果有可能的话，也可以画出整体网络的拓扑图让运维人员进行了解。
有了相关的网络、物理部署和数据流图，我们才能更准确地定位问题的所在。

15.3.12 要有版本控制
我们做的所有事情和变更，都应该尽可能地纳入版本管理。
文档、应用程序配置、监控配置这些都比较容易实现版本控制，版本管理系统容易管理文档和代码，
但其他类型的配置就不容易实现版本控制，比如交换机、路由器、防火墙、操作系统的配置等，我们应该尽可能地实现它们的版本控制。

15.3.13 解决问题要用合适的工具
有些工具比较通用，但对于特定的问题可能就会不适合，有些工具只针对特殊的场景，那么我们就要看，对我们是否真的有用。
一般来说，通用的工具只适合初期，到了规模庞大的时候，往往需要针对特定的需求选择特定的工具。
对于复杂的问题往往不能轻易确定应该如何选择工具，这个时候，你需要将这个问题分解为一系列的小问题，这样才能方便你选择合适的工具。
有些工具可能需要你自己开发，有些使用既有的工具即可，对此应该有一个衡量和评估的过程。

15.3.14 系统工程师要具备定位瓶颈的能力
我们需要监控一切，这样才能预先发现系统的瓶颈。对于一些资源的争用，通过监控系统就能够直观地反映出来。
而对于一些隐藏比较深的资源瓶颈和系统瓶颈，往往需要我们利用各种工具，靠经验去分析和判断。
我们需要有意识地尽可能地通过监控系统去发现问题，让监控系统变得越来越智能，越来越少地依赖于人的经验。
运维工程师要分清楚是哪些资源出现了瓶颈，不要混淆了现象和原因。没有足够经验的工程师经常会犯这个错误。
高级工程师和初级工程师有一个很大的区别，高级工程师知道如何去定位瓶颈所在。
他们不仅知道如何使用工具，还知道何时、何地、为什么去使用工具，这样，他才有可能在问题爆发之前，就定位到瓶颈所在。
那么作为运维工程师，就有必要去训练这种技能。自己测试和验证，然后通过Wiki分享或组内分享都是可以考虑的方式。
定位瓶颈，还需要了解较多的其他领域的知识，因为数据可能要经过很多环节，如本地电脑、浏览器、DNS服务、负载均衡设备、应用服务器等。
在自己熟悉的工具和领域之外，了解其他领域大概有一些什么方法和工具是很有帮助的。

15.3.15 确保无线网络的稳定
随着人们工作、生活的变迁，越来越多的人趋向于移动办公，在公司内部，很多人也是用笔记本接入无线网络的，所以需要保证办公无线网络的稳定、方便和 安全。

15.3.16 确保访问生产网络时有备用的访问方式
现在许多人是在家里办公或处理故障的，那么公司需要保证在非办公区也能够访问生产网络，
员工在外出或旅游的时候，应该带上电脑、上网卡等设备，保证在需要的时间内能够及时响应。
许多公司是使用VPN设备来远程访问生产网络的，VPN设备应该也部署在生产机房中，而不是放在办公网络里。
VPN设备不应该是唯一的访问方式，我们应该确保如果VPN设备发生故障，我们仍然能够访问到生产机房。

15.3.17 让优秀的人做工具/平台
许多互联网公司都有基础平台的技术部门，专门负责开发一些基础平台、工具和服务，提供给各个应用研发团队使用。
但这往往是一个短期内难以见到效益的事情，许多时候，业务的发展一般，对于一些实现，简单的三板斧就搞定了，自然不需要用到更高效、更具扩展性的产品，
所以，对于业务规模不大的公司来说， 更多的时候，是在做一些技术储备的事情。
基础平台部门往往是伴随着公司的高速发展而壮大的，研发出来的产品和服务如果没有人使用，自然就得不到改进，然后就更加没有人使用，这样可能会导致一个恶性循环。
这个时候往往是考验高层的决心的时候，是否坚持仍然保留适当比例的底层平台开发人员呢？
应用软件的研发与平台、工具的研发毕竟是不一样的。如果基础不牢，其实业务的风险更大。
集中人力和时间做一些平台和工具，其实是节省成本的。当然， 前提是，你确实有一批高素质的工程师。
我觉得关于这点，大家应该学一学硅谷的一些公司，让优秀的人去做平台和工具，并提供最好的待遇，给予足够的尊重，对于他们的衡量标准也应该不同。

15.3.18 要有分工，每个角色都很重要
实际的大规模数据库机器的运维，离不开训练有素的工程师，他们需要有许多知识、经验和技巧，也必然需要分工，
比如有开发数据库运维平台的、专门操作数据库的、专门进行调优的、专门进行源码优化的。
我们的团队可能还有项目经理、质量管控、文档工程师、成本分析、培训教育等各个专业领域的人。
他们的价值不能被低估，他们在自己专业领域发挥得越出色，团队的总产出就会越高，
为什么笔者在此要强调，他们的价值不能被低估呢，因为在现实中，一些非实际运维工作的角色往往不被看重，比如网络安全、质量管理、流程推进等，
但正是这些角色，一旦成为整个团队的瓶颈，将会极大地制约着整个团队的服务质量，在大规模化的运维中，他们的作用越显突出。
分工还有另外一层含义，所有需要了解的技术领域，都应该有相应的人在跟进，通过交流和分享，可以研究多得多的知识。

15.3.19 其他团队应能轻松获取生产环境信息
许多公司都存在的一些问题是，运维的生产系统管得太死，导致研发人员不能得知项目的实际运行情况，
运维人员的顾虑是，不能让研发直接访问生产环境， 如果给了研发人员生产服务器的权限，就会有隐患，
但这个问题其实也很好解决，现在的开源监控系统功能强大，一般情况下，是够用的，可以让研发也能通过数据库的监控工具、监控平台直观地看到生产服务器的运行情况。
对于生产环境的数据查询，如果有机密数据，那么经过一些处理，也是可以方便地进行访问的。
现实中，我们的运维数据，并不仅仅只是提供给研发和测试人员使用的，
实际上，我们可以将其转换成更适合其他角色理解的描述方式，让产品、运营等人员也能清楚地知道项目的整体情况，
比如服务器的利用率如何，还有多少扩容空间，新活动耗费了多少增加的资源，单台服务器允许多少人在线。
所有这些，都需要运维平 台越来越成熟。

15.3.20 由独立的系统处理代码性能问题
对于一些难以解决的架构和代码问题，我们需要一套独立的系统来跟踪和处理。因为运维故障处理系统记载的问题，很容易就会被遗忘了。

15.3.21 运维人员应介入产品开发的初期
运维人员应该从产品的设计阶段就跟进，这意味着从一开始就要考虑可靠性、扩展性、维护性和监控。
研发人员可能会更多地考虑到功能的扩展，运维人员可能会更偏向于多集群、冗余这些运维架构的考虑。
研发人员可能不熟悉硬件的性能或架构，从而导致过度设计，而运维人员熟悉硬件，可以给予研发人员更专业的意见。
运维人员要跟进机器的申请和采购，及时通知研发人员采购的进度。
任何服务在上线之前，都应该预先部署好监控，运维工程师可以协助研发人员设计监控接口或提供相应的规范让研发人员设计监控，
运维人员也要撰写相关的操作文档或向研发人员提供文档的规范。
通过运维人员介入软件生命周期的各个阶段，最终形成符合运维标准的文档和产品。

15.3.22 关注安全
初创小公司或中小公司，在安全上往往没有投入人力资源，而是更多地依赖于研发工程师或运维工程师的经验和习惯。
在没有独立安全团队的时候，我们要遵循一些安全的经验法则，比如配置文件的独立，研发人员不应该接触到生产环境的密码等机密信息，
研发人员也应该尽量避免直接介入生产环境的部署和调试。
要有良好的规范，要审查代码，避免给生产环境带来隐患。
运维人员应该关注安全方面的信息，在你的网站已经有了巨大商业价值的时候，更需要注重安全。

15.3.23 关注配置管理
配置管理是指对不断变化的软硬件资源进行识别、记录和管理。这方面的内容读者可以参考ITIL相关的图书。
现实中存在的一个问题是，许多公司存在信息孤岛，从而导致运维、研发等团队的信息不一致。
甚至运维部门内部也各自有各自的服务信息记录，无法对服务信息进行标准化和共享，这点将大大阻碍运维平台的建设。

15.3.24 对优先级进行管理
线上业务，应该是有优先级的。我们应该按照紧急程度和影响范围进行分级。
对于核心业务，应该有经验丰富的工程师进行管理。
如果核心业务发生故障，短时间内解决不了问题，那么我们可能要对事故处理进行“升级”，由经验更丰富的工程师进行处理或由更有权限、掌握更多资源信息的人进行处理。

15.3.25 不要为了优化而优化
不要为了优化而优化，如果不是必须要优化的，就不要去优化。
优化肯定要有目标，否则你无法衡量你的优化效果。
不要为优化而优化，这样可以减少成本， 避免问题的发生。

15.3.26 不要过早优化
过早优化是一切罪恶的根源。我们应该忽略一些微小的不足。
比如，对于Web服务器的响应，我们可能只需要关注99%的响应就可以了。对于其他的1%，你应该有一个意识，它可能是因为什么原因而产生的。
这样在问题被放大之前，你就能知道有什么办法可以去解决，现实中，知道什么时候优化属于过早优化是高级工程师和初级工程师的一个重要区别。

15.3.27 要有知识分享系统
虽然互联网上几乎有无穷无尽的知识，以及各种解决方案，但对于许多有价值的信息，需要在公司内部积累和分享。
比如一些故障处理过程和分析经验，一些公司内部项目的设计，以及新人如何逐步了解各种工作上的知识等。
Wiki为知识的积累和分享提供了一个极佳的形式，笔者曾经就在原公司内部撰写了许多文章。
通过撰写文档，可以大大提高分享的效率。
当然，有了Wiki，系统还需要进行推广使用，我们有必要鼓励内部员工进行文档的撰写和分享。
文档的目的是为了让信息流通更有效率，从而提高工作效率。
它应该属于一项需要不断提高的技能，比较常见的问题是，
如果业务发展很快，或者产品迭代开发频繁，那么文档往往就不是最新的，许多错误没有被修正，
久而久之，IT人员丧失了撰写文档的动力，这里面有工作压力的因素，也有自身技能的因素。
我们有必要训练撰写各种文档的技巧，比如，一些需要频繁修改且很容易过时的内容，也许不值得记录或选择另外的形式进行发布会更好。
阅读一份错漏百出的文档比没有文档的后果更严重。

15.3.28 参加业内技术论坛
应该多参与业内的交流，一些商业性质的数据库大会，都可以考虑参与。
不要惧怕分享自己的经验，对于一些方案，也许其他公司能有更好的解决方案，如果你分享了经验，同行们也会分享经验。
从某种角度上看，我们和同行也是竞争者的关系，但是如果你需要发展，就要看看业内的竞争对手在做什么？要跳出公司的格局去看待技术和管理问题。
参与业内的技术论坛，也是一种招聘的方式，通过认识更多人，扩大影响力，吸引更多人加入自己所在的公司。
参加各种技术论坛也是关注行业技术趋势的一种手段，运维人员应该清楚技术的走向，清楚什么样的产品组合、什么样的框架会更适合于公司的业务。
对于这些认识，肯定需要和行业内的人进行交流的。

15.3.29 必须开周会
许多管理者低估了周会和例会的重要性。
如果经常不重视周会，那么整个团队可能就会变得松散，没有凝聚力。
周会有一个重要的作用就是讨论分工。
随着机器规模的扩大，人员的增加，团队管理者需要分工明确，责任到人。
对于各种服务和机器，都能找到对应的负责人及后备的负责人。
周会也可以讨论彼此的工作进度，对于未达成或延迟的工作要一起交流对策。
了解小团队内部其他人的工作状态及其他团队的工作情况，传达一些上层的信息，这些都是非常重要的事情。
周会也可以用来探讨一些技术问题，交流彼此的研究方向，互相分享，日常的交流分享是不能替代在专门的会议上探讨问题的，
因为每个人的工作饱和度都不一样，个性也不一样，固定一段时间进行正式的交流并成为习惯是值得推荐的沟通方式。

15.3.30 积极支持队友，和团队一起成长
一些IT人员因为忙于自己的工作，当团队成员咨询问题或技术建议时，往往会不予理睬。
我能理解IT公司，特别是一些互联网公司，工作强度高的特点，但是如果想要以后工作得更轻松，更重要的是提高整个团队的输出。
资深的工程师有必要预留自己的时间用于指导初中级工程师，这也是工作的一部分。
如果一个团队， 每个人都能预留一定的时间用于内部支持，我相信团队会成长得更快。
毕竟每个人都是会互相影响的，在互相帮助的氛围下，工作也会更愉悦，更能够享受在团队工作的乐趣。

15.3.31 从公司的利益出发
我们在做选择和决策的时候，要考虑到公司的商业利益，要考虑到公司确实有这个需求，而不是为了丰富自己的履历，为了挑战自己。
简单地说，我们需要的是我们确实需要的，而不是自己想要的。
一些互联网公司，在早期使用了.NET的架构，而在发展过程中，发现LAMP的架构更适合企业的发展，
那么在选择新的平台、工具和开发方式的时候，也许不得不做一些残酷的选择，为了企业的利益，一些.NET的研发人员可能要面临转型或被淘汰。

15.3.32 确保每个人都是可以被替换的
要确保每个人都是可以被替代的。否则，因为意外变故，很可能会导致工作陷入被动。
这些需要文档、流程和规范的支持，需要培养备用角色，也需要持续招聘。
持续招聘，并不是意味着随时招人，而是需要做好准备，在要招人的时候，有各种渠道去招人。

15.3.33 不要受绩效束缚
关键绩效指标（KPI）是指用于评测组织中与关键目标或关键成功因素相关的那些指标，许多公司在到了一定的规模之后，都把KPI考核作为一项主要的管理工具。
一个事实是，绩效是一种工具，人却是复杂的，管理人是复杂的事情，需要考虑的事情很多，很难靠绩效这个工具来简化所有的问题。
我们知道，许多东西在量化之后，就显得比较好管理。
有一些职位，比如一些公司高层，或者销售人员，比较好量化一些指标，对于他们来说，量化指标，往往是看得见的数字，但对于一些其他职位，可能就很难量化指标了。
本质上，这是一个复杂的问题，仍然需要各种社会工程学的配合。
绩效的设计应该是帮助个人发展，帮助人赢得尊重的，而不是用于桎梏个人的。
有人也许会说个人的价值观和公司的价值观有冲突了怎么办？
但凡一个好的公 司，往往是具备包容性的，而员工如果发现个人的价值观和公司的价值观严重冲突，不能妥协的话，那么还是建议走人的好，继续在一起，对于双方都是损失。
绩效应该随需而变。绩效往往会演变为制定出来的计划。
既然是计划，那么就可能会因为市场的变化、竞争对手的变化，而不得不做修正，如果仍然固守旧有的指标，埋头苦干，那么可能会就陷入战略上的错误和方向错误，再怎么努力没有用。
推荐大家看一本书《赢》，看看通用的管理大师杰克·韦尔奇是如何看待绩效的。
虽然他运用了绩效造就了伟大的文化，但同样有一个不容忽视的背景是，他花了许多年创立了坦诚沟通的企业文化。
如果没有坦诚、没有沟通，绩效可能就会成为破坏企业文化的杀手。
我们在推动工作进展的时候，不是去考虑对公司是否真的有帮助，而是主要去考虑自己的绩效；自己现有的工作成果，工作输出，决定了自己后续的工作方向，这是一个非常不好的倾向。
有时人会有一种执念，自己付出了很多努力，在某件事情上付出了许多时间和人力，就会舍不得放弃，但这样完全没有必要，最好的选择是果断止损，
如果有成本更适合的、更有挑战性的、对企业更有效益的事情，那么应该马上换方向。

15.3.34 不断优化流程设计
应该有意识地优化流程设计以提高工作效率和服务质量。
随着公司业务的发展，运维部门的不断扩张，如果缺乏合理的流程或缺乏高层次的人才，那么往往会人数增多了，效率反而下降了。
为什么效率会下降，主要是因为随着公司规模的扩大，所管理和维护的资源急剧膨胀，
出于安全和其他的一些考虑，设计了各种各样的流程，以便得到正确的执行结果，
但其实这些流程往往会导致效率下降，部门内的沟通成本也会越来越高，这都需要我们对流程本身建立反馈和优化的机制， 有意识地不断优化流程。

15.3.35 要了解一些财务知识
许多运维人员不懂财务知识，甚至没有成本意识。这也是有原因的，公司并没有对他们进行一些基础培训，而且许多时候，他们也不清楚各种资源的成本。
但是如果你需要为公司谋取最大的利益，那么你就应该对于各种资源、产品和服务的成本有一个大概的认识。
管理者有必要让员工了解一些信息。
作为一家公司，特别是作为一家上市公司，获取利润是需要着重考虑的，对于成本的支出需要慎重。
对于成本的慎重也不是说一定要压缩和节省各种开支，而是说，对于成本的支出，你需要提供足够的数据支撑，并且能够跟随公司的业务发展做出调整和优化。
管理者需要会预算管理，公司的运维部门往往是公司最大的成本支出部门。
运维人员申请资源、编制预算的时候，更多地是从技术的角度来考虑，而管理决策层大都不太懂技术，他们更多地是从商务价值的角度去评估预算报告。
那么，运维团队的负责人应该使用公司决策层能够理解的语言编制预算报告，需要解释各种预算项目所带来的商务价值回报，IT预算应该服从于商务需求所驱动的费用增长。
IT部门不应该只是成本消耗的部门，它更应该是创造价值的部门。

15.3.36 了解其他领域
我们应该了解运维之外的领域，比如产品、运营和市场，了解了其他领域，更有利于和其他团队沟通，也有利于开拓自己的视野。
以前的公司、部门往往是按照功能垂直划分的，有时难以形成合力，
随着管理水平的提高，现代化的公司组织，往往更扁平化，更注重实效，更注重流程优化，决策权也被逐步授予低层次的员工，
这个时候，基层员工要有更全面的能力。
了解其他的领域，有助于你有更全面的视野，通盘考虑问题，进行流程优化，做出合理的决策。
互联网技术发展得很快，以前MySQL领域的人才很稀缺，但是这些年已经得到了很大的普及，各大公司的数据库运维发展得很快，以前一个人维护几十个库就够多的了，
但以现在的运维技术，可以让一个DBA维护上千台机器，上万个实例。
可以看到的是，数据增长得很快，但DBA的需求增长得相对更慢，每一个DBA所要负责的数据库越来越多。
MySQL的入门门槛不高，很容易就能熟悉，一般的中小项目的数据库，资深研发人员或高级运维工程师也可以兼任，所以许多公司并不需要一个专职的DBA，
而且许多项目从应用到后端，都托管在云上了，这进一步降低了数据库DBA的需求，未来DBA的重心应该是向开发倾斜，更多地与应用开发部门协作，
从后端为程序员提供帮助和指导，更多地向业务靠拢。
当然，首先你要确保数据库运维的标准化和自动化。

小结：
本章是运维篇的最后一章，讲述了规模化运维需要熟悉的一些知识，介绍了一些运维规则。
运维的管理是一个很广的范畴，所以我仅仅列举了一些和数据库运维更相关的值得遵循的规则，
任何管理都是相通的，如果大家希望了解更多的管理知识，可以找一些专门的管理领域的图书来阅读。