本节书摘来自华章计算机《DevOps实战：VMware管理员运维方法、工具及最佳实践》一书中的第1章，第1.2节，作者：小特雷弗 A. 罗伯茨（Trevor A. Roberts Jr.）乔希·阿特韦尔（Josh Atwell）埃格勒·西格勒（Egle Sigler）著，更多章节内容可以访问云栖社区“华章计算机”公众号查看
1.2 采用系统思维
系统思维意味着将涉及软件发行版本部署的所有团队当成一个紧密相连的单位，而不是日程安排相互冲突的多个分散团队。这些团队包括信息安全、运营、开发、质量保证（QA）、产品管理等。
在我们的讨论中所提到的系统指的是经历整个软件开发生命期（规划、开发、QA、部署和维护）的任何项目，不管这些项目是供内部还是外部消费的。
1.2.1 改变团队的互动方式
我们将焦点放在第一件应该做的事：成为开发团队的顾问。和负责定期规划会议的开发团队领导（在敏捷的术语中称为产品负责人和敏捷教练）对话，要求加入他们的一些回忆。主动倾听可能需要基础设施采购/部署的任何团队目标或者可交付成果。下面的几段强调来自开发团队的需求/规格示例，说明了在这种会议期间你所能提供的反馈/专业意见。
“我们需要用于客户源代码的长期数据存储。”
开发团队不一定直接说出他们需要一个新的磁盘阵列，甚至没有意识到需要采购存储设备。但是，对存储系统的认识会提示你，有必要和存储主题专家（SME）一起进行容量规划。
你还需要在开发人员讨论用户数据生命期管理时考虑不同的存储层次。
“我们需要在生产环境中运行独立于客户使用实例的Taao项目实例。”
这立即让你想起附加虚拟网络或者虚拟防火墙的需求，这能够使生产和客户数据流量与内部流量分隔开。你还需要咨询信息安全团队，了解提供客户数据分离保证的审计过程。
“在我们的最后一个发行周期中，代码在我的便携电脑上成功编译和运行，但是在部署到生产环境时崩溃。”
开发人员可能提出一个在之前的代码部署中遇到的问题，提交的代码在她的便携电脑上工作正常，但是在生产部署时发生故障。她的本地开发环境运行的是Ubuntu虚拟机（VM），和非军事区（DMZ）中的CentOS服务器上实施的安全补丁或者防火墙规则不匹配。所以，需要立即打补丁以满足最后限期（对于开发团队和运营团队都是一个漫长的夜晚）。你对Vagrant和Packer等环境构建工具和Puppet、Chef及Ansible等配置管理工具的认识，使你能够构建一个用于开发人员便携电脑且匹配生产服务器规格的标准测试环境。
由于开发团队领导了解了运营团队在发行周期早期为了缓解开发环境问题所做出的努力，你在协调与此努力相关的一些活动时就会更容易一些。首先，这意味着开发团队需要确保其成员不会将任务推给其他团队。（也就是说，“现在是周五下午5点了，我不知道代码能不能在生产环境中正常工作，但是无论如何，我都会把它提交到存储库！”）
某组织在最近的PuppetConf上发表讲话，分享其代码部署策略：当代码部署到生产环境时，编写代码的开发人员参与更改窗口期的轮班。这样，如果代码中出现任何复杂现象，他们可以立即协助运营团队查错和解决。坦率地说，这也使开发人员有动力编写更好的代码，避免在凌晨3点接到电话去修复缺陷。
在继续之前，对于可能阅读本书的经理，Jez Humble强烈建议：不要构建新的DevOps团队！雇用在DevOps方法学上有专业能力的开发人员、QA工程师、运营人员是个好主意，但是创建不同于组织其余团队的全新DevOps团队只会带来新的“竖井”，可能对你的目标造成反作用。相反，应该像前面提到的那样，继续更好地协调各个团队，使他们像一个团队那样思考和行动，而不是各自寻求自己的最大利益。
1.2.2 改变基础设施部署方法
数据中心的一些扰人而又常见的现象可能妨碍系统的进展：手工制作的“金映像”、雪花服务器和易碎箱。
服务器（不管是物理还是虚拟服务器）部署的常用方法是维护一组包含必要更新、补丁、设置等内容的操作系统配置，人工运用这些配置使系统立刻为部署做好准备。这些配置被称作“金映像”，传统上采用ISO形式，已经根据某个运行手册人工应用补丁。最近，金映像已经采用模板VM的形式保存。但是，老实说：金映像也可能生锈！
金映像本身没有什么问题。但是，构建它们的方式可能带来问题。如果人工构建，该过程可能是一个全职工作，必须跟踪模块更新、安全补丁等，然后重新配置ISO/模板VM供以后使用。必须有一种更有效的方法，也的确有！
使用第4～13章介绍的配置管理技术，可以自动构建映像。随着服务器配置更改并登记到Git（第3章中介绍）等存储库，Jenkins（参见第18章）等持续集成（CI）系统可以输出一个更新的金映像。CI系统可以使用Packer等工具生成用于Vagrant、虚拟化管理器和云提供商的模板VM。
Martin Fowler提出了“雪花服务器”的思路，雪花服务器是一台物理机器或者VM，最初是为了保持标准化的良好愿望。但是，不管是为了完成故障报告而进行快速修复、高管要求的特殊项目还是其他原因，这种服务器都变成高度定制的。这些特殊更改解决了短期问题，但是会造成长期的麻烦。当对这些服务器上的软件包升级时会发生什么？安全补丁甚至操作系统升级又会发生什么？
如何解决雪花服务器的问题？首先，我们通过登录到服务器命令行界面强制避免任何更改；不允许一次性执行前端和软件包更新工具或者更改配置文件。所有服务器更改都只能通过配置管理技术进行。
对于现有的雪花服务器，必须进行一些乏味而不必要的工作。首先，检查服务器配置，以便准确地知道需要修改的配置文件、需要安装的软件包和其他需要包含在配置管理脚本中的关键设置。多次迭代构建和测试服务器，每次都对配置管理脚本进行调整，直到测试环境与雪花服务器完全相同。将更改提交到源代码库，就可以拥有一个可在生产服务器无法恢复时使用的可重复构建过程。
易碎箱这一术语来源于Nassim Nicholas Taleb的《Antifragile》一书，描述了一台运行关键软件栈的物理或者虚拟服务器，每个人都害怕接触它，因为业务可能因此遭遇重大故障。通过许多支持电话/专业服务，这台服务器已经达到了一个稳定状态，糟糕的是，管理该服务器的SME离开了公司。
如果稳定性确实是个考虑因素，进行物理-虚拟转换或者虚拟-虚拟迁移到VMware vSphere平台是个好主意。这样，你可以利用分布式资源调度器（DRS）、存储DRS、高可用性（HA）等VMware基础设施可靠性机制。在服务器转换且拥有成功的业务持续性工作流（备份、快照）后，就可以考虑是否可以利用前面雪花服务器的弥补措施复制这一服务器。开发和QA工程师就可以很容易地构建一个测试环境而不接触易碎箱。
1.2.3 改变软件开发和部署方法
我们已经解决了基础设施部署的速度和质量问题，那么团队如何减少从开发、展示到生产阶段代码移动引起的缺陷？众所周知，在开发周期中越早发现缺陷，修复的代价就越低。这就是我们首先要有QA团队的原因。
但是，如果我们可以在代码移交给QA工程师之前就捕捉到缺陷，又会如何？这就是前面提到的持续集成系统的用途所在。我们后面会更详细地讨论CI，基本要点是，当你将源代码提交到存储库时，CI系统可以修改并设置为自动执行对提交代码的一系列单元测试。在过程结束时，可以构建一个软件包并自动分发给QA团队，实施他们的全面测试。
1.2.4 经常收集和响应有用的系统反馈并相应调整
系统思维的转变只有在有能力监控和分析系统性能时才能成功。业务的变化节奏似乎是指数级的，消费者对系统响应能力和正常运行时间有更高的预期，被动的问题解决方案不再成为选择；相反，你的团队必须在问题发生之前预测到它们，以维护系统稳定性。
日志分析可能是最重要的工具之一，尤其是在启用了二进制代码的调试选项时。如果你的环境由较多的服务器组成，就应该采用某种形式的自动化日志分析。这方面的选择很多，包括VMware vRealize Log Insight、Splunk甚至Logstash、Elasticsearch和Kibana等开源工具（第17章中介绍）。这些解决方案使系统管理员能够检查重复的事件与低下的性能关联。当团队更加熟悉这些工具，且更擅长识别问题时，系统的实用性就会提升。
